Bug#1052404: RFP: axum -- web application framework that focuses on ergonomics and modularity

2023-10-06 Thread Jonas Smedegaard
Control: block -1 by 1043515
Control: owner -1 !

Quoting Reinhard Tartler (2023-09-21 14:30:23)
> Can someone please give me a hand with packaging these three crates so
> that they are built from a single debian source package?

As agreed at https://bugs.debian.org/1052431#22 I have now taken over
this bugreport.

This is blocked on fixing bug#1043515

 - Jonas

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

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

signature.asc
Description: signature


Bug#1053587: simple-revision-control: Fails when importing legacy RCS files with "description" content

2023-10-06 Thread RW Penney
Package: simple-revision-control
Version: 1.29-1
Severity: important
Tags: patch
X-Debbugs-Cc: rwpen...@users.sourceforge.net

Dear Maintainer,

When using simple-revision-control to import RCS histories, it appears
unable to handle RCS files that include a non-empty "description" field.
This seems to be because the "src" application treats this field
as JSON, which may be inconsistent with the RCS file format,
as well as the format used by the RCS tools currently in bookworm.

An example scenario is as follows:

$ mkdir RCS
$ echo "Interesting content" > file0.txt
$ ci -i -t-"A tiny file for testing" -m"Initial commit" file0.txt
RCS/file0.txt,v  <--  file0.txt
initial revision: 1.1
done

$ echo "Fascinating content" > file1.txt
$ ci -i -t-"" -m"Initial commit" file1.txt
RCS/file1.txt,v  <--  file1.txt
initial revision: 1.1
done

$ src srcify

$ src log file0.txt
= file0.txt
===
src: legacy data A tiny file for testing in description field
src: fatal exception in popen_or_die.

$ src log file1.txt
= file1.txt
===
1| 2023-10-07T05:14:35Z | trunk
Initial commit
---


It appears that current upstream versions of simple-revision-control do not
make any use of a JSON parser, and minor changes to a try/except block
near line 448 of /usr/bin/src will resolve this issue. Without such a change
it appears to be impossible to make simple-revision-control usable
with legacy RCS histories.


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

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

Versions of packages simple-revision-control depends on:
ii  python3  3.11.2-1+b1
ii  rcs  5.10.1-1

simple-revision-control recommends no packages.

Versions of packages simple-revision-control suggests:
pn  sccs  

-- no debconf information
--- src-orig2022-03-21 13:15:22.0 +
+++ src 2023-10-07 06:22:52.639950705 +0100
@@ -448,7 +448,7 @@
 # is not an issue.
 self.annotations = json.loads(self.description.strip())
 except ValueError as _e:
-croak("legacy data %s in description field" % self.description)
+announce("legacy data %s in description field" % 
self.description)
 def lift_headers(self):
 valid = ('author', 'author-date', 'committer', 'committer-date',
  'mark', 'parents')


Bug#1052404: RFP: axum -- web application framework that focuses on ergonomics and modularity

2023-10-06 Thread Jonas Smedegaard
[reposting to bugreport]

Quoting Reinhard Tartler (2023-09-21 18:55:44)
> interesting, thanks for pointing this out.
> 
> with this approach, how does one generate a debian/control file?

It is not auto-generated: You maintain that file by hand.

 - Jonas

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

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

signature.asc
Description: signature


Bug#1053586: src:mame: fails to migrate to testing for too long: FTBFS on armel

2023-10-06 Thread Paul Gevers

Source: mame
Version: 0.257+dfsg.1-1
Severity: serious
Control: close -1 0.258+dfsg.1-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:mame has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on armel.


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 trixie, 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/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=mame



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1053585: lintian-brush: many scripts fail

2023-10-06 Thread Martin-Éric Racine
Package: lintian-brush
Version: 0.151
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Some fixer scripts failed to run: ["debian-tests-control-autodep8-is-obsolete", 
"unused-override", "common-license", "vcs-field-mismatch", 
"invalid-standards-version", "upstream-metadata-invalid", "pkg-perl-vcs", 
"no-section-field", "initial-upload-closes-no-bugs", 
"debian-control-has-unusual-field-spacing", 
"debian-source-options-has-custom-compression-settings", 
"package-uses-deprecated-debhelper-compat-version", "unnecessary-team-upload", 
"wrong-section-according-to-package-name", "package-has-no-description", 
"public-upstream-key-binary", "no-maintainer-field", "upstream-metadata-file", 
"new-package-uses-date-based-version-number", "vcs-field-invalid-branch", 
"debian-rules-sets-dpkg-architecture-variable", 
"debian-rules-missing-recommended-target", 
"public-upstream-keys-in-multiple-locations", "pkg-perl-testsuite", 
"public-upstream-key-in-native-package", "no-copyright-file", 
"debian-watch-uses-insecure-uri", "built-using-for-golang", 
"binary-control-field-duplicates-source", "no-priority-field", "source-format", 
"rules-requires-root-missing", "uses-debhelper-compat-file", 
"dep5-file-paragraph-references-header-paragraph", 
"license-file-listed-in-debian-copyright", "no-homepage-field", 
"missing-prerequisite-for-pyproject-backend", "pubkey", 
"upstream-metadata-in-native-source", "debian-watch-file-is-missing", 
"vcs-field-bitrotted", "old-override-info-format", 
"package-needs-versioned-debhelper-build-depends", 
"debian-control-has-obsolete-dbg-package"]. Run with --verbose for details.

- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (x86_64)

Kernel: Linux 6.1.0-12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages lintian-brush depends on:
ii  devscripts   2.23.6
ii  libc62.37-12
ii  libgcc-s113.2.0-4
ii  liblzma5 5.4.4-0.1
ii  libpython3.113.11.6-1
ii  libssl3  3.0.11-1
ii  python3  3.11.4-5+b1
ii  python3-breezy   3.3.4-1
ii  python3-debian   0.1.49
ii  python3-debmutate0.68
ii  python3-distro-info  1.5
ii  python3-dulwich  0.21.6-1
ii  python3-iniparse 0.5-1
ii  python3-iso8601  1.0.2-1
ii  python3-levenshtein  0.12.2-2+b4
ii  python3-psycopg2 2.9.6-3
ii  python3-pyinotify0.9.6-2
ii  python3-ruamel.yaml  0.17.21-1
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.12.1-1
ii  python3-tqdm 4.64.1-1
ii  python3-upstream-ontologist  0.1.35-1

Versions of packages lintian-brush recommends:
ii  debhelper  13.11.6
pn  decopy 
pn  dos2unix   
ii  gpg2.2.40-1.1
ii  lintian2.116.3
pn  ognibuild  
ii  python3-bs44.12.2-2
ii  python3-debianbts  4.0.1
pn  python3-docutils   
ii  python3-lxml   4.9.3-1
pn  python3-markdown   

Versions of packages lintian-brush suggests:
pn  brz-debian 
ii  git-buildpackage   0.9.32
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
pn  postgresql-common  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmUg7ZcACgkQrh+Cd8S0
17a/0BAAum+tydrJmkvY9g/iE6WbSVgRbps5RVpOQ2XbDGvajMlM3JuhcRXObhR4
aIaaDX6zmlp9fIlnpZWyhLo9W+8X61x6Jef+/Qa07mA58wWB0XJOdgAwFaXxmoQ2
T2JFb7zYCLZXU9rAFjiHTXsHAMkSiCHpfq+XgIfdQYkHrthb+FFYZ/VKOmym+CbX
zkOmxthi4jyOGpo7eAMBJQdwTMszHkzr93mcbVtLwdawF3S5NjPKLbsVf6l2cA3B
+1Ak8PnDsUvV6N2B6amSvuErPUIgRMCh7a8y9eCKPftqryAmX94fr08D9/cJ6ka3
IsfyDCOeER6x8iMTnR8Jhjya0/0xsEIaN3NBpjQwvr1aDvYTmsOno3Ik31vX2G8F
SICI/cwgboUMKxhiysB/tz9ybzEQU6oFIdPNcbG8Uu2XPHUW3Ni8lEyfN/V+aaKh
KLNBT6WjnAlngBa2gr19/RjSPb31BQJRoG8ni+zILHEunh9XQ3YXCCyJDfMbqBOr
tFWVDwxswaagTubVxrdzIokouo0MGBmb2kp8LNof+C+fmmR9ey+E8pTbTnz5UwNB
9b4xFcyZ7pIdaRbE5cwVTZmq2pPLEYN6KYLBZp3eH95+TXypKUrQq/nAz0CJaHsz
9zWn9uvrq7gBh9o9dMXAg7HMPhqdzqf2oNR5qi58pGzLyR4TaBg=
=hhiS
-END PGP SIGNATURE-



Bug#1053584: xl2tpd: Disconnects when using IPv6 only addresses

2023-10-06 Thread Witold Baryluk
Package: xl2tpd
Version: 1.3.18-1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: witold.bary...@gmail.com

Tunnel itself is over IPv4.

But I have configured for the addresses to be only link-local IPv6.

Other side is another Debian with manually configured xl2tpd lns.

Client is using network manager with gnome plugin for configuring. IPv4
is disabled. IPv6 is link local. DNS and route propagation are all
disabled.

Server is 185.x.x.x
Client is NATed to 85.y.y.y

Connection is established, and works, but after 60 seconds it is
disconnected, with error claiming that connect did not succeed.

05:11:24 ian NetworkManager[3051788]:   [1696655484.6741] 
vpn[0x557b26806b80,5ecff92c-3d25-4c19-a7f5-5aee0337d3f7,"foobar"]: starting l2tp
05:11:24 ian NetworkManager[3051788]:   [1696655484.6746] audit: 
op="connection-activate" uuid="5ecff92c-3d25-4c19-a7f5-5aee0337d3f7" 
name="foobar" pid=1261326 uid=1000 result="success"
05:11:24 ian nm-l2tp-service[1447505]: Check port 1701
05:11:24 ian nm-l2tp-service[1447505]: Can't bind to port 1701
05:11:24 ian nm-l2tp-service[1447505]: xl2tpd started with pid 1447510
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Not looking for kernel 
SAref support.
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Using l2tp kernel 
support.
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: xl2tpd version 
xl2tpd-1.3.18 started on debian PID:1447510
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Written by Mark Spencer, 
Copyright (C) 1998, Adtran, Inc.
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Forked by Scott Balmos 
and David Stipp, (C) 2001
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Inherited by Jeff 
McAdams, (C) 2002
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Forked again by 
Xelerance (www.xelerance.com) (C) 2006-2016
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Listening on IP address 
0.0.0.0, port 34425
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Connecting to host 
185.x.x.x, port 1701
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Connection established 
to 185.x.x.x, 1701.  Local: 11106, Remote: 63049 (ref=0/0).
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Calling on tunnel 11106
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: Call established with 
185.x.x.x, Local: 19014, Remote: 81, Serial: 1 (ref=0/0)
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: start_pppd: I'm running:
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "/usr/sbin/pppd"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "plugin"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "pppol2tp.so"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "pppol2tp"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "7"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "passive"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "nodetach"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: ":"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: "file"
05:11:24 ian NetworkManager[1447510]: xl2tpd[1447510]: 
"/run/nm-l2tp-5ecff92c-3d25-4c19-a7f5-5aee0337d3f7/ppp-options"
05:11:24 ian pppd[1447511]: Plugin pppol2tp.so loaded.
05:11:24 ian pppd[1447511]: Plugin /usr/lib/pppd/2.4.9/nm-l2tp-pppd-plugin.so 
loaded.
05:11:24 ian pppd[1447511]: pppd 2.4.9 started by root, uid 0
05:11:24 ian pppd[1447511]: Using interface ppp0
05:11:24 ian pppd[1447511]: Connect: ppp0 <-->
05:11:24 ian pppd[1447511]: Overriding mtu 1500 to 1400
05:11:24 ian pppd[1447511]: Overriding mru 1500 to mtu value 1400
05:11:24 ian NetworkManager[3051788]:   [1696655484.7433] manager: 
(ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/17)
05:11:24 ian pppd[1447511]: Overriding mtu 1410 to 1400
05:11:24 ian pppd[1447511]: CHAP authentication succeeded: Access granted
05:11:24 ian pppd[1447511]: CHAP authentication succeeded
05:11:24 ian pppd[1447511]: local  LL address fe80::b97c:8b16:1d15:4290
05:11:24 ian pppd[1447511]: remote LL address fe80::4cf4:aed1:1b82:4b42




I can ping the remote LL address, responses come back. I see flow on ppp0 
(using tcpdump) on both sides. No issues.

60 seconds later:

05:12:25 ian NetworkManager[3051788]:   [1696655545.0670] 
vpn[0x557b26806b80,5ecff92c-3d25-4c19-a7f5-5aee0337d3f7,"foobar"]: connect 
timeout exceeded
05:12:25 ian nm-l2tp-service[1447505]: Connect timer expired, disconnecting.
05:12:25 ian NetworkManager[1447510]: xl2tpd[1447510]: death_handler: Fatal 
signal 15 received
05:12:25 ian NetworkManager[1447510]: xl2tpd[1447510]: Terminating pppd: 
sending TERM signal to pid 1447511
05:12:25 ian NetworkManager[1447510]: xl2tpd[1447510]: Connection 63049 closed 
to 185.x.x.x, port 1701 (Server closing)
05:12:25 ian pppd[1447511]: Terminating on signal 15
05:12:25 ian pppd[1447511]: Overriding mtu 1500 to 1400
05:12:25 ian pppd[1447511]: Overriding mru 1500 to mtu value 1400
05:12:25 ian pppd[1447511]: Connection terminated.
05:12:25 ian 

Bug#1052607: pxdvi can not use haranoaji fonts

2023-10-06 Thread Takeshi Soejima
I think the following patch will resolve the issue.

--- texk/xdvik/texmf/config.xdvi.orig
+++ texk/xdvik/texmf/config.xdvi
@@ -50,6 +50,8 @@
 % p psfonts.map
 r H   JIS-H
 r V   JIS-V
+r 2004-H  JIS-H
+r 2004-V  JIS-V
 r UniJIS-UTF16-H  Unicode-H
 r UniJIS-UTF16-V  Unicode-V
 r UniJIS-UCS2-H   Unicode-H

By the way, I noticed that even if configuring kanjix.map to use
haranoaji without jis2004 option, japanese characters are displayed in
jis2004 figure by xdvi. But I don't care it at this time.



Bug#1053583: network-manager-l2tp-gnome: Cannot connect to IPv6 gateway

2023-10-06 Thread Witold Baryluk
Package: network-manager-l2tp-gnome
Version: 1.20.8-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

When using literal IPv6 as an address of a gateway, It does not work:

Oct 07 04:20:15 debian NetworkManager[3051788]:   [1696652415.8499] 
vpn[0x557b26804680,5ecff92c-3d25-4c19-a7f5-5aee0337d3f7,"foobar"]: starting l2tp
Oct 07 04:20:15 debian NetworkManager[3051788]:   [1696652415.8504] 
audit: op="connection-activate" uuid="5ecff92c-3d25-4c19-a7f5-5aee0337d3f7" 
name="foobar" pid=1261326 uid=1000 result="success"
Oct 07 04:20:15 debian NetworkManager[3051788]:   [1696652415.8745] 
vpn[0x557b26804680,5ecff92c-3d25-4c19-a7f5-5aee0337d3f7,"foobar"]: failed to 
connect: 'couldn't look up L2TP VPN gateway IP address '


This is without ipsec or ppp.

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
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 network-manager-l2tp-gnome depends on:
ii  libc6 2.37-12
ii  libglib2.0-0  2.78.0-2
ii  libgtk-3-03.24.38-5
ii  libgtk-4-14.12.3+ds-1
ii  libnm01.44.2-1
ii  libnma-gtk4-0 1.10.6-1
ii  libnma0   1.10.6-1
ii  libsecret-1-0 0.21.1-1
ii  libssl3   3.0.11-1
ii  network-manager-l2tp  1.20.8-1

network-manager-l2tp-gnome recommends no packages.

network-manager-l2tp-gnome suggests no packages.

-- no debconf information



Bug#1053582: mtr: --order option is not supported

2023-10-06 Thread Witold Baryluk
Package: mtr
Version: 0.95-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

user@debian:~$ mtr  ‐-order "LSB" ::1
mtr: Failed to resolve host: ‐-order: Name or service not known
user@debian:~$ mtr ‐o "LSB" ::1
mtr: Failed to resolve host: ‐o: Name or service not known
user@debian:~$ 


This option is documented in --help and in manual page, but does not
appear to be supported.

Regards,
Witold


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
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 mtr depends on:
ii  libc62.37-12
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.78.0-2
ii  libgtk2.0-0  2.24.33-2
ii  libjansson4  2.14-2
ii  libncurses6  6.4+20230625-2
ii  libtinfo66.4+20230625-2

mtr recommends no packages.

mtr suggests no packages.

-- no debconf information


Bug#920523: Neverwinter Nights segfault

2023-10-06 Thread Antoine Le Gonidec

It took me a while to understand that, but the crash is actually due to a 
symbol conflict between the old game binaries and current libstdc++.so.6.

Patched binaries are available here: 
https://downloads.dotslashplay.it/games/neverwinter-nights-1/

And the explanation about how they have been patched:
"""
The original binaries nwmain and nwserver have a symbol conflict with modern 
libstdc++.so.6.
patchelf has been used to patch the binaries and rename the conflicting symbol 
(__dynamic_cast).

Big thanks to Phil Morrell, who used a similar method to patch Unreal 
Tournament libraries.
Without their work I would not have known how to fix this.
"""

I suggest closing this bug report, especially now that we know that this was 
not really related to libgl1-mesa-dri in the first place.


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1053445: Merge request regarding 'Please migrate Release Notes to reStructuredText'

2023-10-06 Thread James Addison
Package: www.debian.org
Followup-For: Bug #1053445
X-Debbugs-Cc: larj...@debian.org, debian-...@lists.debian.org, 
debian-...@lists.debian.org

> I think we should open an RT ticket to ask DSA to install several packages in 
> www-master that are needed now. From the info in the README file, these are 
> the 
> ones not present currently in www-master:
>
> - latexmk
> - python3-distro-info
> - python3-sphinx
> - python3-stemmer
> - tex-gyre
> - texinfo
>
> I'm trying a local build to see if any other package is also needed, and will 
> open an RT ticket later in the day or tomorrow, if nobody beats me to it.

It's possible/likely I'm stating the obvious, but just in case: this could also
be a good opportunity to remove (or plan to remove) packages that are no longer
necessary to build the old-style release notes.



Bug#1050185: rust-derive-builder-core - depends on old version of darling

2023-10-06 Thread Matthias Geiger

I take it this can be closed now that the semver packages were uploaded ?



Bug#1053581: clang: options not documented in the manpage

2023-10-06 Thread Thorsten Glaser
Package: clang-16
Version: 1:16.0.6-15
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

Even such trivial options such as -Wall and -Werror are not
documented, let alone others. A full list of options, like
in gcc-doc for GCC, is needed to be able to make use of it.


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

Kernel: Linux 5.10.0-26-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages clang-16 depends on:
ii  binutils2.41-5
ii  libc6   2.37-12
ii  libc6-dev   2.37-12
ii  libclang-common-16-dev  1:16.0.6-15
ii  libclang-cpp16  1:16.0.6-15
ii  libclang1-161:16.0.6-15
ii  libgcc-13-dev   13.2.0-4
ii  libgcc-s1   13.2.0-4
ii  libllvm16   1:16.0.6-15
ii  libobjc-13-dev  13.2.0-4
ii  libstdc++-13-dev13.2.0-4
ii  libstdc++6  13.2.0-4
ii  llvm-16-linker-tools1:16.0.6-15

Versions of packages clang-16 recommends:
pn  llvm-16-dev  
ii  python3  3.11.4-5+b1

Versions of packages clang-16 suggests:
pn  clang-16-doc  
pn  wasi-libc 

-- no debconf information



Bug#1053379: munin-node: logrotate.d/munin-node should call invoke-rc.d

2023-10-06 Thread Bob Proulx
Holger Levsen wrote:
> Bob Proulx wrote:
> > > where?
> > The /etc/logrotate.d/munin-node file contains TAB characters.
>
> yes, on purpose :)

Sure.  I use TABs all of the time.  I was only commenting on my email
describing the patch!

Bob



Bug#1053580: mirror submission for mirror.matnetwrk.net

2023-10-06 Thread Mathieu Mafille
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.matnetwrk.net
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el 
riscv64 s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mathieu Mafille 
Country: CH Switzerland
Location: Saint-Imier / Switzerland
Sponsor: MATNETWRK https://matnetwrk.net




Trace Url: http://mirror.matnetwrk.net/debian/project/trace/
Trace Url: 
http://mirror.matnetwrk.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.matnetwrk.net/debian/project/trace/mirror.matnetwrk.net



Bug#1053579: ITP: python3-jpegiptc -- extract IPTC data from images

2023-10-06 Thread Pedro Paulo
Package: jpegiptc
Severity: wishlist
Owner: Pedro Paulo 

* Package name: python3-jpegiptc
  Version : 1.5-1
  Upstream Author : Guillaume Degoulet
* URL : https://github.com/gdegoulet/JpegIPTC
* License : Artistic License, GNU General Public License (GPL)
  Programming Lang: Python3
  Description : extract IPTC data from images

Original image with IPTC tags --> thumbor transformation --> new image with
original IPTC tags.


Bug#1052969: yubikey-manager: FTBFS: dh_missing: error: missing files, aborting

2023-10-06 Thread Bastian Germann

Please just add a file debian/not-installed with:
usr/lib/python*/dist-packages/.pytest_cache



Bug#1053379: munin-node: logrotate.d/munin-node should call invoke-rc.d

2023-10-06 Thread Holger Levsen
On Thu, Oct 05, 2023 at 03:45:38PM -0600, Bob Proulx wrote:
> > where?
> The /etc/logrotate.d/munin-node file contains TAB characters.

yes, on purpose :)


-- 
cheers,
Holger

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

Make earth cool again.


signature.asc
Description: PGP signature


Bug#1053577: printer-driver-gutenprint: PPD files not updated during upgrade of printer-driver-gutenprint

2023-10-06 Thread Helmar Gerloni
Package: printer-driver-gutenprint
Version: 5.3.4.20220624T01008808d602-1
Severity: normal
X-Debbugs-Cc: hel...@gerloni.net

Error happend after upgrading from Bullseye to Bookworm. Similar to #918726 
(upgrade from Stretch to Buster).

- /var/log/dpkg.log:
2023-10-05 17:27:17 upgrade printer-driver-gutenprint:amd64 5.3.3-5 
5.3.4.20220624T01008808d602-1

- /var/log/cups/error_log:
D [06/Oct/2023:18:19:22 +0200] [Job 1260] Gutenprint: command line: 
Brother_HL-5150D_WLAN \'1260\' \'myuser\' \'mydoc.pdf\' \'1\' 
D [06/Oct/2023:18:19:22 +0200] [Job 1260] Gutenprint: using PPD file 
/etc/cups/ppd/Brother_HL-5150D_WLAN.ppd
D [06/Oct/2023:18:19:22 +0200] [Job 1260] Set job-printer-state-message to "The 
PPD version (5.3.3) is not compatible with Gutenprint 5.3.4.  Please run 
`/usr/sbin/cups-genppdupdate\' as administrator.", current level=ERROR

Fixed with:

root@mypc:~# /usr/sbin/cups-genppdupdate
Updated /etc/cups/ppd/Brother_HL-5150D_USB.ppd using 
gutenprint.5.3://brother-hl-5150d/expert
Updated /etc/cups/ppd/Brother_HL-5150D_WLAN.ppd using 
gutenprint.5.3://brother-hl-5150d/expert
Updated 2 PPD files, 2 skipped.  Restart cupsd for the changes to take effect.
root@mypc:~# systemctl restart cups

Probably the 'if ... lt-nl 5.3.1-7~; then' in postinst has to be updated or 
removed.

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

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

Versions of packages printer-driver-gutenprint depends on:
ii  cups 2.4.2-3+deb12u1
ii  cups-client  2.4.2-3+deb12u1
ii  cups-filters [ghostscript-cups]  1.28.17-3
ii  libc62.36-9+deb12u3
ii  libcups2 2.4.2-3+deb12u1
ii  libgutenprint9   5.3.4.20220624T01008808d602-1
ii  libusb-1.0-0 2:1.0.26-1
ii  zlib1g   1:1.2.13.dfsg-1

printer-driver-gutenprint recommends no packages.

Versions of packages printer-driver-gutenprint suggests:
pn  gutenprint-doc  
pn  gutenprint-locales  

-- no debconf information



Bug#1053576: rust-pin-project-lite: please update to v0.2.10

2023-10-06 Thread Jonas Smedegaard
Source: rust-pin-project-lite
Version: 0.2.9-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to (at least) newer upstream release v0.2.10.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUgYPwACgkQLHwxRsGg
ASFT1A/6A0Nyn9tVLWrYnjltjo5ToE5gVu0fCG8GOYkx+G8xuMzMPnsntAZxFyNo
HN11W58BEjsJngNGqyFyNgL1Ldl6dqqcif3Rjf+4IUK6d4xOIbXD7gAHPv+CP1qh
f15/6x8k2aoiyVmAMxUfhQSzqqvhFbnOVPVtVqt7se0AMPhqo85iHk23bLPGmCNm
UVRnLVfPpSTsEDfNBDidqDN7bg4PL2mDiyo1FsONpgHyNJkXq/CCuc6v1b1Nbw6h
2N6XFwtM3esJkE/FLoazGFnL76cFPpR28arlT1ifz72Ft4ZOlBmtJdeQqs4pM/oI
lFIy6Q7jM2ilCkQ5jV47s/6cC2Bc3NGapWF4BdbWfmcQNJBoJ/RWtHMOrGmtZaPc
1HSxHP9Fr3Gqlj10HN4LFLa4k/1nEYCqSUq8JjfKq29lZaau15P8wVX94uGya9gA
8Yx5Coc0hetZo92tKB6O6Yz3uechk2vbyCABjEZwe1SM3p1X7cUlJHK3IYg4SUGa
dBm6V9wM8YQvo3FyF1ksU4rY0gKOJN9kqqAbbdCdYHav3Fo3qGXK/L34DQmieYhZ
9QxgySeCXAxedzUNzTHsxlMZEfJ9Tus/A2+Og1pSzIb54N1R52qXj6DXwnCHbVSr
F1uvAx/51EMoyUzj6sqcIf85OHjahfWHN0hx14ECtM2br07wDIU=
=aFn9
-END PGP SIGNATURE-



Bug#1053575: RFS: ruby-mdl/0.13.0-1 -- Markdown lint tool

2023-10-06 Thread Norwid Behrnd
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ruby-mdl":

 * Package name : ruby-mdl
   Version  : 0.13.0-1
   Upstream contact : ["p...@ipom.com"]
 * URL  : https://github.com/markdownlint/markdownlint
 * License  : MIT
 * Vcs  : https://salsa.debian.org/nbehrnd/ruby-mdl
   Section  : text

The source builds the following binary packages:

  ruby-mdl - Markdown lint tool

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

  https://mentors.debian.net/package/ruby-mdl/

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

  dget -x
  https://mentors.debian.net/debian/pool/main/r/ruby-mdl/ruby-mdl_0.13.0-1.dsc

Changes since the last upload:

 ruby-mdl (0.13.0-1) unstable; urgency=medium
 .
   * New upstream version 0.13.0, i.e.
   * added SARIF output
   * fixed rules MD007, MD027
   * changed rules MD009, MD033
   * new rules MD055, MD056, MD057

Regards,



Bug#1053574: wlgreet: FTBFS with DEB_BUILD_OPTIONS=nocheck: does not perform the build

2023-10-06 Thread Jeremy Bícha
Source: wlgreet
Version: 0.4.1-2
Severity: serious
Justification: nocheck FTBFS is serious since trixie
Tags: ftbfs

wlgreet uses the same dh_auto_build override as greetd so please see
https://bugs.debian.org/1050769 for more details and a proposal to fix
this type of issue.

Thank you,
Jeremy Bícha



Bug#1053538: kexec-tools: kexec reboot even if "systemctl reboot" via initscripts - Debian stable and testing

2023-10-06 Thread Khalid Aziz

On 10/6/23 12:19 PM, Alban Browaeys wrote:

LOAD_KEXEC=true


With LOAD_KEXEC=true, the intent always has been for "reboot" and 
"systemctl reboot" to do a kexec reboot. That functionality has broken 
off and on over the last 3 years as new versions of systemd were 
released. I have now removed LOAD_KEXEC support because of it not being 
reliable due to changes happening in systemd.


So I would say "reboot" and "systemctl reboot" doing a kexec reboot with 
"LOAD_KEXEC=true" is expected behavior. If you are ok with it, I would 
like to close this bug.


Thanks,
Khalid



note that this is from a copy of the file I made yesterday, since then
I upgrade to the unstable kexec-tools.

I can confirm that this bug is not there with the unstable version
1:2.0.27-1 (as the initscripts are no more this was expected).

debconf entry:
* kexec-tools/load_kexec: true

Cheers,
Alban

Le vendredi 06 octobre 2023 à 10:01 -0600, Khalid Aziz a écrit :

On 10/5/23 3:05 PM, Alban Browaeys wrote:

Package: kexec-tools
Version: 1:2.0.25-3+b1
Severity: normal

Dear Maintainer,
When I call "reboot" or "systemctl reboot" I ends up with a kexec
reboot.

I expect a cold reboot.


What is the value for LOAD_KEXEC in /etc/default/kexec?

--
Khalid





I have enabled kexec-tools as it is a dependency of kdump-tools.
I supposed enabling a kexec kernel was a requirement to get kdump
tools
to dump to /var/crash. Maybe I misunderstood.

In the journal I get after systemd telling it is rebooting:
"
oct. 05 21:59:59 cyclope systemd-logind[1954]: The system will
reboot now!
(...)
oct. 05 21:59:59 cyclope systemd-logind[1954]: System is rebooting.
(...)
oct. 05 22:00:00 cyclope systemd[1]: Stopping kexec-load.service -
LSB: Load kernel image with kexec...
(...)
oct. 05 22:00:02 cyclope kexec-load[6144]: Loading new kernel image
into memory...done.
oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service:
Deactivated successfully.
oct. 05 22:00:02 cyclope systemd[1]: Stopped kexec-load.service -
LSB: Load kernel image with kexec.
oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Consumed
1.208s CPU time.
(...)
oct. 05 22:00:02 cyclope systemd[1]: Stopping kexec.service - LSB:
Execute the kexec -e command to reboot system...
(...)
oct. 05 22:00:02 cyclope kexec[6439]: Will now restart with kexec.
"

This even though the kexec-tools Debian REAME tells:
/usr/share/doc/kexec-tools/README.Debian
"reboot" command with ystemd will by default do a cold reboot. To
kexec
a new kernel with systemd, use "systemctl kexec".

I believe this is a new issue maybe from my upgrade in June of
kexec-tools
from 1:2.0.20-2.1, 1:2.0.25-3+b1.
That is I did not change my kexec-tools config and I believe
monthes ago
systemctl reboot gave me a cold reboot, not a kexec one.
Note that it does not means the setup was fine beforehand as I do
not
have a single kdump crash file in /var/crash.
I do not know if kexec reboot was even working with the previous
version. Now it kexec reboots fine ... but even when I ask
systemctl for
a default coldreboot.

I don't believe this affects unstable as kexec-tools 1:2.0.27-1
removed the
initscripts that are called by systemd at reboot.

Maybe this is expected behavior with systemd-sysv installed?


Cheers,
Alban


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

Kernel: Linux 6.5.0-1-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 kexec-tools depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.22.0
ii  libc6  2.37-12
ii  libxenmisc4.17 4.17.2-1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.08-1

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information:
* kexec-tools/load_kexec: true
    kexec-tools/use_grub_config: false






Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*

2023-10-06 Thread Salvatore Bonaccorso
Hi,

On Sun, Nov 20, 2022 at 09:11:09PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote:
> > Source: grub2
> > Version: 2.04-16
> > Severity: normal
> > X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org
> > 
> > grub2 currently uses grub-efi-signed-* as source package names for the
> > Secure Boot signed packages.  While releasing the last security update
> > we found a small issue with these names:
> > 
> > dak processes source packages in lexiographic order, so it would
> > process grub-efi-signed-* before grub2 when accepting all packages at
> > once from the "embargoed" policy queue.  But the grub-efi-signed-*
> > binary packages have Built-Using: grub2; as grub2 is not accepted from
> > embargoed at this point in time, the /binary/ uploads will be rejected
> > in this case.  (This problem exists in principle with all Built-Using
> > relations.)
> > 
> > We could avoid this particular problem if the source package names of
> > the signed packages sort after grub2, i.e., if they were named
> > grub2-signed-* or grub2-efi-signed-*.  With linux this is already the
> > case (src:linux and src:linux-signed-*).
> > 
> > (As a minor thing, I think the changelog entry in the signed packages
> > should also use the grub maintainer's name, not ftpmaster@ similar to
> > what src:linux-signed-* has, but that is just cosmetics.)
> > 
> > I've Cc'ed debian-release@ as it is already past soft freeze, but I
> > think just renaming the source packages would be unlikely to break
> > anything.
> 
> As we were hit by this issue in the last DSA (DSA 5280-1) again,
> should we attempt to have this changed at least for bookworm?

For DSA 5519-1 I fortunately remembered this bug and did install the
packages in two steps, first dak new-security-install grub2*.changes,
then the grub-efi*.changes.

I still think would be great if we can do the above mentioned renames,
to avoid this problem (or ist maybe realistic that we could tackle the
problem itself at dak level?).

Regards,
Salvatore



Bug#1050769: dh-cargo: should provide a build() method

2023-10-06 Thread Jeremy Bícha
Control: tags 1050769 +patch

> IMHO it is a dh-cargo bug (see #1053556[1]) which must be fixed before
> greetd's debian/rules can be updated to use dh_auto_build.

No, greetd needs to build itself correctly regardless of whether there
are helper functions available.

The 2 most common types of projects using dh-cargo are
1) Rust crates which are shipped as uncompiled source code
2) Rust apps which have their own build system, usually meson

In both those cases, dh_auto_build works correctly already.

greetd doesn't fall into those cases so needs to implement the build
and install steps itself. It already handles the install. And I've
submitted a merge proposal for it to handle the build.

https://salsa.debian.org/debian/greetd/-/merge_requests/4

Thank you,
Jeremy Bícha



Bug#1053573: libpython3.11-testsuite install fails due to syntax error: 'uft-8' in /usr/lib/python3.11/test/tokenizedata/bad_coding.py

2023-10-06 Thread Albedo Black
Package: libpython3.11-testsuite
Version: 3.11.6-2
Severity: serious
File: /usr/share/doc/libpython3.11-testsuite
Tags: ftbfs
Justification: makes the package in question unusable or mostly so

Dear Maintainer,

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

   * What led up to the situation?
  - Attempted to instally python3.11-full to leverage the
libpython3.11-testsuite library
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  - purged from system
  - cleared apt cache
  - updated and reattempted to install.
  - attempted installing from source
  - attempted debugging following the trace which led to secondary
issues:

```bash
$sudo dpkg --configure libpython3.11-testsuite
Setting up libpython3.11-testsuite (3.11.6-2) ...
File "/usr/lib/python3.11/test/tokenizedata/bad_coding.py", line 0
SyntaxError: unknown encoding: uft-8
dpkg: error processing package libpython3.11-testsuite
(--configure):
 installed libpython3.11-testsuite package post-installation script
subprocess returned error exit status 1
Errors were encountered while processing:
 libpython3.11-testsuite
```

fix appears to be correcting the typo in
`/usr/lib/python3.11/test/tokenizedata/bad_coding.py` adjusting "uft-8" to
"utf-8" which can be done via sed:

```bash
sudo sed -i 's/uft-8/utf-8/g'
/usr/lib/python3.11/test/tokenizedata/bad_coding.py
```

then removing the BOM from the start of the `bad_coding2.py` file at:

  `/usr/lib/python3.11/test/tokenizedata/bad_coding2.py`

```bash
sed '1s/^\xEF\xBB\xBF//'
/usr/lib/python3.11/test/tokenizedata/bad_coding2.py > /tmp/bad_coding2.py \
&& sudo mv /tmp/bad_coding2.py
/usr/lib/python3.11/test/tokenizedata/bad_coding2.py
```

   * What was the outcome of this action?
  - Successfully resolved configuration issue with package allowing
dpgk to finish its processes and complete
  installation. Recommend applying these changes to the package and
testing to validate.


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


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

Kernel: Linux 6.4.0-4-amd64 (SMP w/32 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 libpython3.11-testsuite depends on:
ii  net-tools   2.10-0.1
ii  python3.11  3.11.6-2

libpython3.11-testsuite recommends no packages.

Versions of packages libpython3.11-testsuite suggests:
ii  python3-gdbm  3.11.5-1
ii  python3-tk3.11.5-1

-- no debconf information


Bug#1053538: kexec-tools: kexec reboot even if "systemctl reboot" via initscripts - Debian stable and testing

2023-10-06 Thread Alban Browaeys
LOAD_KEXEC=true

note that this is from a copy of the file I made yesterday, since then
I upgrade to the unstable kexec-tools.

I can confirm that this bug is not there with the unstable version
1:2.0.27-1 (as the initscripts are no more this was expected).

debconf entry:
* kexec-tools/load_kexec: true

Cheers,
Alban

Le vendredi 06 octobre 2023 à 10:01 -0600, Khalid Aziz a écrit :
> On 10/5/23 3:05 PM, Alban Browaeys wrote:
> > Package: kexec-tools
> > Version: 1:2.0.25-3+b1
> > Severity: normal
> > 
> > Dear Maintainer,
> > When I call "reboot" or "systemctl reboot" I ends up with a kexec
> > reboot.
> > 
> > I expect a cold reboot.
> 
> What is the value for LOAD_KEXEC in /etc/default/kexec?
> 
> --
> Khalid
> 
> > 
> > 
> > 
> > I have enabled kexec-tools as it is a dependency of kdump-tools.
> > I supposed enabling a kexec kernel was a requirement to get kdump
> > tools
> > to dump to /var/crash. Maybe I misunderstood.
> > 
> > In the journal I get after systemd telling it is rebooting:
> > "
> > oct. 05 21:59:59 cyclope systemd-logind[1954]: The system will
> > reboot now!
> > (...)
> > oct. 05 21:59:59 cyclope systemd-logind[1954]: System is rebooting.
> > (...)
> > oct. 05 22:00:00 cyclope systemd[1]: Stopping kexec-load.service -
> > LSB: Load kernel image with kexec...
> > (...)
> > oct. 05 22:00:02 cyclope kexec-load[6144]: Loading new kernel image
> > into memory...done.
> > oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service:
> > Deactivated successfully.
> > oct. 05 22:00:02 cyclope systemd[1]: Stopped kexec-load.service -
> > LSB: Load kernel image with kexec.
> > oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Consumed
> > 1.208s CPU time.
> > (...)
> > oct. 05 22:00:02 cyclope systemd[1]: Stopping kexec.service - LSB:
> > Execute the kexec -e command to reboot system...
> > (...)
> > oct. 05 22:00:02 cyclope kexec[6439]: Will now restart with kexec.
> > "
> > 
> > This even though the kexec-tools Debian REAME tells:
> > /usr/share/doc/kexec-tools/README.Debian
> > "reboot" command with ystemd will by default do a cold reboot. To
> > kexec
> > a new kernel with systemd, use "systemctl kexec".
> > 
> > I believe this is a new issue maybe from my upgrade in June of
> > kexec-tools
> > from 1:2.0.20-2.1, 1:2.0.25-3+b1.
> > That is I did not change my kexec-tools config and I believe
> > monthes ago
> > systemctl reboot gave me a cold reboot, not a kexec one.
> > Note that it does not means the setup was fine beforehand as I do
> > not
> > have a single kdump crash file in /var/crash.
> > I do not know if kexec reboot was even working with the previous
> > version. Now it kexec reboots fine ... but even when I ask
> > systemctl for
> > a default coldreboot.
> > 
> > I don't believe this affects unstable as kexec-tools 1:2.0.27-1
> > removed the
> > initscripts that are called by systemd at reboot.
> > 
> > Maybe this is expected behavior with systemd-sysv installed?
> > 
> > 
> > Cheers,
> > Alban
> > 
> > 
> > -- System Information:
> > Debian Release: trixie/sid
> >    APT prefers testing-debug
> >    APT policy: (500, 'testing-debug'), (500, 'stable-updates'),
> > (500, 'stable-security'), (500, 'stable-debug'), (500, 'oldstable-
> > debug'), (500, 'oldoldstable'), (500, 'testing'), (500, 'stable'),
> > (90, 'unstable-debug'), (90, 'unstable'), (1, 'experimental-
> > debug'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 6.5.0-1-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 kexec-tools depends on:
> > ii  debconf [debconf-2.0]  1.5.82
> > ii  dpkg   1.22.0
> > ii  libc6  2.37-12
> > ii  libxenmisc4.17 4.17.2-1
> > ii  lsb-base   11.6
> > ii  sysvinit-utils [lsb-base]  3.08-1
> > 
> > kexec-tools recommends no packages.
> > 
> > kexec-tools suggests no packages.
> > 
> > -- debconf information:
> > * kexec-tools/load_kexec: true
> >    kexec-tools/use_grub_config: false
> 



Bug#1052720: polybar: FTBFS: control.h:417:47: error: ‘snd_ump_endpoint_info_t’ has not been declared

2023-10-06 Thread Mohd Bilal

Control: reassign -1 libasound2


On Tue, 26 Sep 2023 14:38:02 +0200 Lucas Nussbaum  wrote:

Source: polybar
Version: 3.6.3-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230925 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
> cd /<>/build/bin && /usr/bin/c++  -I/<>/include -I/<>/build/generated-sources -isystem /usr/include/cairo 
-isystem /usr/include/libpng16 -isystem /usr/include/freetype2 -isystem /usr/include/pixman-1 -isystem /<>/lib/xpp/include -isystem 
/<>/build/lib/xpp/generated-sources/include -isystem /<>/lib/i3ipcpp/3rd/auss/include -isystem /<>/lib/i3ipcpp/include 
-isystem /usr/include/jsoncpp -isystem /usr/include/libnl3 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++14 -Wall -Wextra -Wpedantic -Wsuggest-override -MD -MT bin/CMakeFiles/poly.dir/adapters/alsa/control.cpp.o -MF 
CMakeFiles/poly.dir/adapters/alsa/control.cpp.o.d -o CMakeFiles/poly.dir/adapters/alsa/control.cpp.o -c /<>/src/adapters/alsa/control.cpp
> In file included from /<>/include/adapters/alsa/generic.hpp:37,
>  from /<>/src/adapters/alsa/control.cpp:2:
> /usr/include/alsa/control.h:417:47: error: ‘snd_ump_endpoint_info_t’ has not 
been declared
>   417 | int snd_ctl_ump_endpoint_info(snd_ctl_t *ctl, snd_ump_endpoint_info_t 
*info);
>   |   ^~~
> /usr/include/alsa/control.h:418:44: error: ‘snd_ump_block_info_t’ has not 
been declared
>   418 | int snd_ctl_ump_block_info(snd_ctl_t *ctl, snd_ump_block_info_t 
*info);
>   |^~~~
> make[3]: *** [bin/CMakeFiles/poly.dir/build.make:1129: 
bin/CMakeFiles/poly.dir/adapters/alsa/control.cpp.o] Error 1



This seems to be a bug in alsa-lib package. Upstream has fixed this in 
https://github.com/alsa-project/alsa-lib/commit/fcce13a6726c52882bd8b7131c61c4eba308792c


I have created an MR importing the upstream patch to alsa-lib[1]. I was 
able to build polybar successfully with the updated alsa-lib package.


[1] - https://salsa.debian.org/alsa-team/alsa-lib/-/merge_requests/3


--
Mohammed Bilal
2D65 BC1E B966 5A6E 97F9 730A B3F5 9452 8521 9E1F



Bug#1053572: libosmgpsmap-1.0-1: libosmgpsmap and GeocodeGlib are incompatible and cannot be used together

2023-10-06 Thread Serge Noiraud
Package: libosmgpsmap-1.0-1
Version: 1.2.0-2
Severity: critical
Tags: d-i
Justification: breaks unrelated software
X-Debbugs-Cc: serge.noir...@free.fr

libosmgpsmap uses libsoup 2.4 and GeocodeGlin use libsoup 3.0
This occurs with the gramps application.
gramps stop then we have the following error:
(Gramps.py:3226): libsoup-ERROR **: 13:47:37.498: libsoup2 symbols detected.
Using libsoup2 and libsoup3 in the same process is not supported.
Trace/breakpoint trap


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

Kernel: Linux 6.1.0-12-amd64 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN, 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 libosmgpsmap-1.0-1 depends on:
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libsoup2.4-1 2.74.3-1

libosmgpsmap-1.0-1 recommends no packages.

libosmgpsmap-1.0-1 suggests no packages.

-- no debconf information



Bug#1053571: secnet ought to provide a logrotate.d snippet

2023-10-06 Thread Ian Jackson
Package: secnet
Version: 0.6.7

Many of my machines have this ad-hoc.  It ought to be in the package,
tested, etc.

-- 
Ian JacksonThese opinions are my own.  

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



Bug#1053552: gavodachs2-server: Error while setting up with postgresql 16

2023-10-06 Thread Markus Demleitner
On Fri, Oct 06, 2023 at 09:56:41AM +0200, Ole Streicher wrote:
> 108s   alter role untrusted set extra_float_digits=3
> 108s
> 108s The database engine reported:
> 108s
> 108s   ERROR:  permission denied to alter role
> 108s DETAIL:  Only roles with the CREATEROLE attribute and the ADMIN option
> 108s on role "untrusted" may alter this role.
>
> I don't think that has anything to do with the astropy update. This
> seems to be connected to Postgresql version (16.0-2); a similar install
> (with Postgresql 15.4-3) succeeded.

Oh bother.  Yeah, that's unrelated to astropy and absolutely related
to increasingly tight rules in postgres.  I'll think about a
workaround (to restore this workaround) on Monday.

-- Markus



Bug#1053538: kexec-tools: kexec reboot even if "systemctl reboot" via initscripts - Debian stable and testing

2023-10-06 Thread Khalid Aziz

On 10/5/23 3:05 PM, Alban Browaeys wrote:

Package: kexec-tools
Version: 1:2.0.25-3+b1
Severity: normal

Dear Maintainer,
When I call "reboot" or "systemctl reboot" I ends up with a kexec
reboot.

I expect a cold reboot.


What is the value for LOAD_KEXEC in /etc/default/kexec?

--
Khalid





I have enabled kexec-tools as it is a dependency of kdump-tools.
I supposed enabling a kexec kernel was a requirement to get kdump tools
to dump to /var/crash. Maybe I misunderstood.

In the journal I get after systemd telling it is rebooting:
"
oct. 05 21:59:59 cyclope systemd-logind[1954]: The system will reboot now!
(...)
oct. 05 21:59:59 cyclope systemd-logind[1954]: System is rebooting.
(...)
oct. 05 22:00:00 cyclope systemd[1]: Stopping kexec-load.service - LSB: Load 
kernel image with kexec...
(...)
oct. 05 22:00:02 cyclope kexec-load[6144]: Loading new kernel image into 
memory...done.
oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Deactivated 
successfully.
oct. 05 22:00:02 cyclope systemd[1]: Stopped kexec-load.service - LSB: Load 
kernel image with kexec.
oct. 05 22:00:02 cyclope systemd[1]: kexec-load.service: Consumed 1.208s CPU 
time.
(...)
oct. 05 22:00:02 cyclope systemd[1]: Stopping kexec.service - LSB: Execute the 
kexec -e command to reboot system...
(...)
oct. 05 22:00:02 cyclope kexec[6439]: Will now restart with kexec.
"

This even though the kexec-tools Debian REAME tells:
/usr/share/doc/kexec-tools/README.Debian
"reboot" command with ystemd will by default do a cold reboot. To kexec
a new kernel with systemd, use "systemctl kexec".

I believe this is a new issue maybe from my upgrade in June of kexec-tools
from 1:2.0.20-2.1, 1:2.0.25-3+b1.
That is I did not change my kexec-tools config and I believe monthes ago
systemctl reboot gave me a cold reboot, not a kexec one.
Note that it does not means the setup was fine beforehand as I do not
have a single kdump crash file in /var/crash.
I do not know if kexec reboot was even working with the previous
version. Now it kexec reboots fine ... but even when I ask systemctl for
a default coldreboot.

I don't believe this affects unstable as kexec-tools 1:2.0.27-1 removed the
initscripts that are called by systemd at reboot.

Maybe this is expected behavior with systemd-sysv installed?


Cheers,
Alban


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

Kernel: Linux 6.5.0-1-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 kexec-tools depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.22.0
ii  libc6  2.37-12
ii  libxenmisc4.17 4.17.2-1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.08-1

kexec-tools recommends no packages.

kexec-tools suggests no packages.

-- debconf information:
* kexec-tools/load_kexec: true
   kexec-tools/use_grub_config: false




Bug#1053570: haskell-config-value FTBFS with alex 3.3.0.0

2023-10-06 Thread Adrian Bunk
Source: haskell-config-value
Version: 0.8.3-2
Severity: serious
Tags: ftbfs patch
Forwarded: 
https://github.com/glguy/config-value/commit/c5558c8258598fab686c259bff510cc1b19a0c50

https://buildd.debian.org/status/fetch.php?pkg=haskell-config-value=loong64=0.8.3-2=1696604219=0
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/haskell-config-value.html

...
CallStack (from HasCallStack):
  withMetadata, called at 
libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:370:14 in 
Cabal-3.8.1.0:Distribution.Simple.Utils
Error: hlibrary.setup: The program 'alex' version ^>=3.2.4 is required but the
version found at /usr/bin/alex is version 3.3.0.0
...



Bug#1053535: Add support for timestamps with nanoseconds [patch]

2023-10-06 Thread Alexander Zangerl
severity 1053535 wishlist
tags 1053535 + moreinfo
thanks

On Thu, 05 Oct 2023 21:51:40 +0200, markus writes:
>here is a patch to add support for timestamps with nanoseconds for dump
>and restore
...
>As a consequence dumpfiles (or -tapes) from previous versions
>of dump are not compatible with the new version of restore.

i'm not at all convinced that this is a useful change, in particular
in a backup/restore tool.

please provide more information as to what benefits this change is
expected to provide, and how those benefits are supposed to outweight
the massive downside of complete incompatibility with existing backups.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + https://snafu.priv.at/
"Mary had a little key,/She kept it in escrow/And everything that Mary
sent/The Feds were sure to know." -- Sam Simpson


signature.asc
Description: Digital Signature


Bug#1052929: yasnippet: FTBFS: make: *** [debian/rules:4: binary] Error 25

2023-10-06 Thread Barak A. Pearlmutter
I pushed a quick update, it has a few test failures though.



Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)

2023-10-06 Thread sergio

Ok,

I'll be checking for the update on backports repo.

Regards.

El jue,  5 de oct de 2023 a las 16:54:36 PM, Alberto Garcia 
 escribió:

On Thu, Oct 05, 2023 at 01:45:13PM -0300, sergio wrote:
 Waiting until the package version it is upgradeed on the backports 
repo has

 sense ?
 Upgrading from stable warn me that i will need to update 27 other 
packages.


Hi,

if you're using stable then it's better that you don't install
WebKitGTK from unstable, I'll tell you when a backport is available.

Thanks,

Berto




Bug#1053568: ITP: python-lib25519 -- Python wrapper around lib25519 library

2023-10-06 Thread Jan Mojzis
Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Jan Mojzis 
Severity: wishlist

* Package name: python-lib25519
  Version : 20231006
  Upstream Contact: Jan Mojzis 
* URL : https://github.com/janmojzis/python-lib25519
* License : CC0
  Programming Lang: Python
  Description : Python wrapper around lib25519 library


lib25519 is a microlibrary for the X25519 encryption system and the Ed25519
signature system, both of which use the Curve25519 elliptic curve.

lib25519 has a very simple stateless API based on the SUPERCOP API, with
wire-format inputs and outputs, providing functions that directly match the
central cryptographic operations in X25519 and Ed25519:

lib25519.x25519.keypair(pk, sk): X25519 key generation
lib25519.x25519.dh(k, pk, sk): shared-secret generation
lib25519.ed25519.keypair(pk, sk): Ed25519 key generation
lib25519.ed25519.sign(sm, , m, mlen, sk): signing
lib25519.ed25519.open(m, , sm, smlen, pk): verification + message recovery

This package is related to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051553


I'm going to maintain the package using https://salsa.debian.org/
It is being prepared here: https://salsa.debian.org/janmojzis/python-lib25519
I need sponsor for the first upload (I'm DM).

Jan



Bug#1053569: ITP: python-mceliece -- Python wrapper around libmceliece library

2023-10-06 Thread Jan Mojzis
Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: Jan Mojzis 
Severity: wishlist

* Package name: python-mceliece
  Version : 20231006
  Upstream Contact: Jan Mojzis 
* URL : https://github.com/janmojzis/python-mceliece
* License : CC0
  Programming Lang: Python
  Description : Python wrapper around libmceliece library


libmceliece is a Classic McEliece microlibrary.
libmceliece has a very simple stateless API based on the SUPERCOP API,
with wire-format inputs and outputs, providing functions that directly match
the KEM operations provided by Classic McEliece, such as functions

mceliece6960119.keypair()
mceliece6960119.enc()
mceliece6960119.dec()
for the mceliece6960119 KEM

This package is related to: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050531

I'm going to maintain the package using https://salsa.debian.org/
It is being prepared here: https://salsa.debian.org/janmojzis/python-mceliece
I need sponsor for the first upload (I'm DM).

Jan



Bug#1040687:

2023-10-06 Thread Farid Cheraghi
I am experiencing this issue as well. thanks


Bug#1053566: known and fixed upstream

2023-10-06 Thread Rémi Letot
Hi,

just found it upstream:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2668

Apparently the fix is already merged in upstream gnome 45.

Thanks,
-- 
Rémi Letot



Bug#1053542: src/javax/annoation/* license

2023-10-06 Thread Taylor Smock
It looks like the only annotations we use are @Nonnull and @Nullable. We 
/could/ just strip the concurrent annotations out while we figure out 
what to do (hopefully none of the plugins depend on the 
javax.annotation.concurrent package).



The original problem was that /all/ javax.annotation.* files were marked 
as CC-BY-2.5. Which confused me, since the license of the jar file we 
are using was Apache 2.0.


On 10/6/23 6:49 AM, Sebastiaan Couwenberg wrote:

On 10/6/23 14:33, Taylor Smock wrote:
@Thorsten Alteholz: Can you please explain /why/ you think those 
files have the CC-BY-2.5 license?


All the javax.annotation.concurrent sources are CC-BY-2.5, see:


https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/GuardedBy.java/ 



https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/Immutable.java/ 



https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/NotThreadSafe.java/ 



https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/ThreadSafe.java/ 



These all have:

 /*
  * Copyright (c) 2005 Brian Goetz
  * Released under the Creative Commons Attribution License
  *   (http://creativecommons.org/licenses/by/2.5)
  * Official home: http://www.jcip.net
  */

Kind Regards,

Bas


Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."

2023-10-06 Thread Axel Beckert
Hi Emanuele,

Emanuele Rocca wrote:
> On 2023-05-04 11:53, Axel Beckert wrote:
> > Sure. I intend to run Debian Unstable on it anyway
> 
> Now you can. :-)

Hmmm, I tried a few days ago (October 1st) with the image from
https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/arm64/iso-cd/
and it hang with a message saying something about "generating empty
device tree" or so.

> https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s

Ah, I see, there's much more than just the installer image needed.
Thanks for that hint!

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



Bug#1053567: mhonarc: Please upgrade mhonarc to latest version

2023-10-06 Thread Luc Didry
Package: mhonarc
Version: 2.6.19-2.2
Severity: normal

Dear Maintainer,

Mhonarc is now maintained by Sympa community and has been updated 3 years early
(see https://github.com/sympa-community/MHonArc/tags or 
https://metacpan.org/dist/MHonArc/view/mhonarc).

Could you upgrade the Debian package, please?

Regards,

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/24 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)

Versions of packages mhonarc depends on:
ii  perl  5.36.0-9

Versions of packages mhonarc recommends:
ii  perl [libdigest-md5-perl]  5.36.0-9

mhonarc suggests no packages.



Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12

2023-10-06 Thread Pierre-Elliott Bécue
Please keep the bug report CC-ed.

Steven Verhulst  wrote on 06/10/2023 at 13:16:09+0200:

> Hi,
>
>  
>
> /etc/mysql/debian.cnf is a config file auto generated by some debian scripts.
>
> It contains host / user information for mysql connection.
>
> According to the contents this file is deprecated and should no longer be 
> used:
>
>  
>
> # THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE.
>
> # This file exists only for backwards compatibility for
>
> # tools that run '--defaults-file=/etc/mysql/debian.cnf'
>
> # and have root level access to the local filesystem.
>
> # With those permissions one can run 'mariadb' directly
>
> # anyway thanks to unix socket authentication and hence
>
> # this file is useless. See package README for more info.
>
> # THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE.
>
>  
>
>  
>
> “sed: -e expression #2, char 82: unterminated `s' command”
>
> Makes me believe that there is an issue with with one the sed
> expression in the post-installation script.

Yes, I am aware of your beliefs, and they're probably founded, but to be
able to dig in I need some context.

If you did not fix manually the issue, could you add "set -x" at the
beginning of /var/lib/dpkg/info/mailman3-web.postinst script and run a
dpkg --configure mailman3-web and give me the output?

If some passwords fall in the output, of course feel free to censor
them.

-- 
PEB


signature.asc
Description: PGP signature


Bug#1053502: Fwd: Re: Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12

2023-10-06 Thread Pierre-Elliott Bécue


Steven Verhulst  wrote on 06/10/2023 at 13:16:09+0200:

> Hi,
>
>  
>
> /etc/mysql/debian.cnf is a config file auto generated by some debian scripts.
>
> It contains host / user information for mysql connection.
>
> According to the contents this file is deprecated and should no longer be 
> used:
>
>  
>
> # THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE.
>
> # This file exists only for backwards compatibility for
>
> # tools that run '--defaults-file=/etc/mysql/debian.cnf'
>
> # and have root level access to the local filesystem.
>
> # With those permissions one can run 'mariadb' directly
>
> # anyway thanks to unix socket authentication and hence
>
> # this file is useless. See package README for more info.
>
> # THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE.
>
>  
>
>  
>
> “sed: -e expression #2, char 82: unterminated `s' command”
>
> Makes me believe that there is an issue with with one the sed expression in 
> the post-installation script. 
>
>  
>
> Kind regards,
>
>  
>
> Steven Verhulst
>
>  
>
>  
>
> On 05/10/2023, 16:23, "Pierre-Elliott Bécue"  wrote:
>
> tags 1053502 +moreinfo
>
> thanks
>
>  
>
> Hi,
>
>  
>
> Steven Verhulst  wrote on 05/10/2023 at 10:37:05+0200:
>
>  
>
>> Package: mailman3-web
>
>> Version: 0+20200530-2.1
>
>> Severity: important
>
>>
>
>  
>
>> Dear Maintainer,
>
>>
>
>  
>
>> When we upgraded our test mailingserver from Debian 11 to 12 we
>
>> noticed the following error:
>
>>
>
>  
>
>> Setting up mailman3-web (0+20200530-2.1) ...
>
>> Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts 
>> not equal).
>
>> dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
>
>> dbconfig-common: flushing administrative password
>
>> sed: -e expression #2, char 82: unterminated `s' command
>
>> dpkg: error processing package mailman3-web (--configure):
>
>> installed mailman3-web package post-installation script subprocess returned 
>> error exit status 1
>
>>
>
>  
>
>> From what I understand there seems to be an issue with the
>
>> post-installation script.
>
>>
>
>  
>
>> Since the post-installation script did not run it left us with a
>
>> broken listserver.  Further it is not possible to use APT to update
>
>> packages as it keep warning about mailman3-web package being broken.
>
>  
>
> When I read
>
>  
>
>> Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts 
>> not equal).
>
>> dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
>
>> dbconfig-common: flushing administrative password
>
>  
>
> I tend to think some weird stuff happened on your host.
>
>  
>
> But to try understanding further the issue, could you please give me
>
> some hints about what this file contains?



Bug#1053566: gnome-control-center: fails to add or edit vpn

2023-10-06 Thread Rémi Letot
Package: gnome-control-center
Version: 1:45.0-1
Severity: normal
X-Debbugs-Cc: hob...@poukram.net

Dear Maintainer,

when I try to add or edit a vpn in gnome-control-center, it does not save the 
new data. I have no error message, including in journalctl. Just the new data
is not saved.

I can however do so using nmcli, so it's a gnome issue.

Thanks,
-- 
Rémi

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

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

Versions of packages gnome-control-center depends on:
ii  accountsservice   23.13.9-4
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-3
ii  desktop-base  12.0.6+nmu1
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:45.0-1
ii  gnome-desktop3-data   44.0-2
ii  gnome-settings-daemon 45.0-1
ii  gsettings-desktop-schemas 45.0-1
ii  libaccountsservice0   23.13.9-4
ii  libadwaita-1-01.4.0-1
ii  libc6 2.37-12
ii  libcairo2 1.18.0-1
ii  libcolord-gtk4-1  0.3.0-4
ii  libcolord21.4.6-3
ii  libcups2  2.4.2-6
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.14.2-6
ii  libgcr-base-3-1   3.41.1-3
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.78.0-2
ii  libgnome-bg-4-2   44.0-2
ii  libgnome-bluetooth-ui-3.0-13  42.6-1
ii  libgnome-desktop-4-2  44.0-2
ii  libgnome-rr-4-2   44.0-2
ii  libgnutls30   3.8.1-4+b1
ii  libgoa-1.0-0b 3.48.0-2
ii  libgoa-backend-1.0-1  3.48.0-2
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.38-5
ii  libgtk-4-14.12.3+ds-1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0238-2
ii  libibus-1.0-5 1.5.29~rc1-1
ii  libkrb5-3 1.20.1-4
ii  libmalcontent-0-0 0.11.1-1
ii  libmm-glib0   1.20.6-2
ii  libnm01.44.2-1
ii  libnma-gtk4-0 1.10.6-1
ii  libpango-1.0-01.51.0+ds-2
ii  libpangocairo-1.0-0   1.51.0+ds-2
ii  libpolkit-gobject-1-0 123-1
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libpwquality1 1.4.5-1+b1
ii  libsecret-1-0 0.21.1-1
ii  libsmbclient  2:4.19.0+dfsg-1
ii  libsnapd-glib-2-1 1.63-5
ii  libudisks2-0  2.10.1-1
ii  libupower-glib3   1.90.2-5
ii  libwacom9 2.8.0-1
ii  libx11-6  2:1.8.7-1
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1.3
ii  tecla 45.0-1
ii  webp-pixbuf-loader0.2.4-2

Versions of packages gnome-control-center recommends:
ii  cracklib-runtime  2.9.6-5+b1
ii  cups-pk-helper0.2.6-1+b1
ii  fwupd 1.9.5-1
ii  gnome-bluetooth-sendto42.6-1
ii  gnome-online-accounts 3.48.0-2
ii  gnome-remote-desktop  44.2-6
ii  gnome-user-docs   45.0-1
ii  gnome-user-share  43.0-1
ii  iso-codes 4.15.0-1
ii  libcanberra-pulse 0.30-10
ii  libnss-myhostname 254.5-1
ii  libspa-0.2-bluetooth  0.3.80-2
ii  malcontent-gui0.11.1-1
ii  network-manager-gnome 1.34.0-1
ii  polkitd   123-1
ii  power-profiles-daemon 0.13-2
ii  realmd0.17.1-2
ii  rygel 0.42.4-1+b1
ii  rygel-tracker 0.42.4-1+b1
ii  system-config-printer-common  1.5.18-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   45.0-1
ii  gstreamer1.0-pulseaudio  1.22.6-1+b1
ii  pkexec   123-1
ii  x11-xserver-utils7.7+9+b1

-- no debconf information


Bug#1053565: RFS: openvpn3-client/20+dfsg-1 [ITP] -- virtual private network daemon (version 3)

2023-10-06 Thread Marc Leeman
Package: sponsorship-requests
Severity: wishlist

Dear Maintainer,


Dear mentors,

I am looking for a sponsor for my package "openvpn3-client":

 * Package name : openvpn3-client
   Version  : 20+dfsg-1
   Upstream contact : OpenVPN Solutions LLC 
 * URL  : https://openvpn.net/
 * License  : Gnu Affero General Public License 3
 * Vcs  : https://salsa.debian.org/televic-team/openvpn3-client
   Section  : net

The source builds the following binary packages:

  openvpn3-client - virtual private network daemon (version 3)

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

  https://mentors.debian.net/package/openvpn3-client/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/openvpn3-client/openvpn3-client_20+dfsg-1.dsc

Changes for the initial release:

 openvpn3-client (20+dfsg-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #904044)
   * d/control: do not depend on openvpn2 dev headers
   * d/postinst: create user before chown
   * d/README: add comment on lintian-warning unicode-impl.hpp
   * d/README: update dfsg motivation
   * remove sum files (see d/README.source)

Regards,

Additional discussion on the packaging with upstream can be found here:
https://github.com/OpenVPN/openvpn3-linux/issues/193

--
  Marc Leeman



Bug#1053564: nftables: nft freeze after some times, probably as a result of excessive use of named set

2023-10-06 Thread Daniel Haryo Sugondo
Package: nftables
Version: 1.0.6-2+deb12u1
Severity: normal

Dear Maintainer,

I'm trying to support our nftables to use FQDN (CDN). I wrote a shell script
to translate FQDN into ip(v4/v6) address and feed the results in nftables
"named set". The elements have a max. timeout from about 5 Min. I don't want
outdated entries on my sets. The script inserts and deletes the elements
periodically.

My script works flawlessly on Debian 11 and for the first hours on Debian 12
too, but ends on Debian 12 with [D]-state on "ps" output, after some hours,
and on dmesg you can see Call Traces from netlink modul.

I don't have any idea, why the behaviour on Debian 12 is different to the
previous version. Maybe you can take a look for this.

Further informations:
My named set on nftables for this purpose looks like:

table inet firewall {
set fq4-acc-o {
type ipv4_addr . inet_proto . inet_service
flags interval,timeout
timeout 5m15s
}

set fq6-acc-o {
type ipv6_addr . inet_proto . inet_service
flags interval,timeout
timeout 5m15s
}
...

Some examples, if nft crashs:

Oct 02 00:38:51 nftfqdn.sh[224817]: /dev/shm/fqdn.nft:42:39-86: Error: Could 
not process rule: File exists
Oct 02 00:38:51 nftfqdn.sh[224817]: add element inet firewall fq6-acc-o { 
2600:9000:2490:e000:3:db06:4200:93a1 . tcp . 443 }
Oct 02 00:38:51 nftfqdn.sh[224817]:   


Oct 03 04:13:04 nftfqdn.sh[203649]: /dev/shm/fqdn.nft:12:39-63: Error: Could 
not process rule: File exists
Oct 03 04:13:04 nftfqdn.sh[203649]: add element inet firewall fq4-acc-o { 
143.204.98.14 . tcp . 443 timeout 27s }
Oct 03 04:13:04 nftfqdn.sh[203649]:   
^

dmesg output

Oct 03 04:13:22 kernel: BUG: kernel NULL pointer dereference, address: 
0034
Oct 03 04:13:22 kernel: #PF: supervisor read access in kernel mode
Oct 03 04:13:22 kernel: #PF: error_code(0x) - not-present page
Oct 03 04:13:22 kernel: PGD 0 P4D 0
Oct 03 04:13:22 kernel: Oops:  [#1] PREEMPT SMP PTI
Oct 03 04:13:22 kernel: CPU: 2 PID: 203751 Comm: nft Not tainted 6.1.0-12-amd64 
#1  Debian 6.1.52-1
Oct 03 04:13:22 kernel: Hardware name: FUJITSU PRIMERGY RX1330 M2/D3375-A1, 
BIOS V5.0.0.11 R1.31.0 for D3375-A1x02/22/2023
Oct 03 04:13:22 kernel: RIP: 
0010:nft_setelem_data_deactivate.constprop.0.isra.0+0x40/0x80 [nf_tables]
Oct 03 04:13:22 kernel: Code: 36 0f b6 46 03 84 c0 74 15 8b 57 44 81 fa ff fe 
ff ff 76 0a 81 fa 00 ff ff ff 74 20 0f 0b 0f b6 46 09 84 c0 74 11 48 8b 14 06 
<8b> 42 34 8d 48 ff 89 4a 34 85 c0 74 27 c3 cc cc cc cc 48 01 f0 8b
Oct 03 04:13:22 kernel: RSP: 0018:c07fc315f6b8 EFLAGS: 00010202
Oct 03 04:13:22 kernel: RAX: 0038 RBX: c07fc315f898 RCX: 
0854c002
Oct 03 04:13:22 kernel: RDX:  RSI: 9c63c3bf9340 RDI: 
9c63c198f000
Oct 03 04:13:22 kernel: RBP: c07fc315f750 R08: 9c63d36c0e00 R09: 
0001
Oct 03 04:13:22 kernel: R10: 0020 R11: 0004 R12: 
9c63c198f000
Oct 03 04:13:22 kernel: R13: 9c63c3bf9340 R14: 9c63d36c0200 R15: 
9c63c198f000
Oct 03 04:13:22 kernel: FS:  7f0fe7262740() GS:9c6b0fc8() 
knlGS:
Oct 03 04:13:22 kernel: CS:  0010 DS:  ES:  CR0: 80050033
Oct 03 04:13:22 kernel: CR2: 0034 CR3: 000151c3e003 CR4: 
003706e0
Oct 03 04:13:22 kernel: DR0:  DR1:  DR2: 

Oct 03 04:13:22 kernel: DR3:  DR6: fffe0ff0 DR7: 
0400
Oct 03 04:13:22 kernel: Call Trace:
Oct 03 04:13:22 kernel:  
Oct 03 04:13:22 kernel:  ? __die_body.cold+0x1a/0x1f
Oct 03 04:13:22 kernel:  ? page_fault_oops+0xd2/0x2b0
Oct 03 04:13:22 kernel:  ? exc_page_fault+0x70/0x170
Oct 03 04:13:22 kernel:  ? asm_exc_page_fault+0x22/0x30
Oct 03 04:13:22 kernel:  ? 
nft_setelem_data_deactivate.constprop.0.isra.0+0x40/0x80 [nf_tables]
Oct 03 04:13:22 kernel:  nft_del_setelem+0x49b/0x510 [nf_tables]
Oct 03 04:13:22 kernel:  nf_tables_delsetelem+0x1f0/0x2e0 [nf_tables]
Oct 03 04:13:22 kernel:  ? __kmem_cache_alloc_node+0x139/0x2a0
Oct 03 04:13:22 kernel:  ? nfnetlink_rcv_batch+0x20a/0x9a0 [nfnetlink]
Oct 03 04:13:22 kernel:  nfnetlink_rcv_batch+0x5df/0x9a0 [nfnetlink]
Oct 03 04:13:22 kernel:  nfnetlink_rcv+0x175/0x193 [nfnetlink]
Oct 03 04:13:22 kernel:  netlink_unicast+0x23f/0x390
Oct 03 04:13:22 kernel:  netlink_sendmsg+0x250/0x4c0
Oct 03 04:13:22 kernel:  sock_sendmsg+0x5c/0x70
Oct 03 04:13:22 kernel:  sys_sendmsg+0x277/0x2f0
Oct 03 04:13:22 kernel:  ? copy_msghdr_from_user+0x7d/0xc0
Oct 03 04:13:22 kernel:  ___sys_sendmsg+0x9a/0xe0
Oct 03 04:13:22 kernel:  __sys_sendmsg+0x76/0xc0
Oct 03 04:13:22 kernel:  do_syscall_64+0x58/0xc0
Oct 03 04:13:22 kernel:  ? 

Bug#1052055: Webkit output fully white

2023-10-06 Thread Alberto Garcia
On Thu, Oct 05, 2023 at 02:18:39PM +0200, R Pi wrote:
> Unfortunately, I am still encountering the same issue.

Can you open webkit://gpu on the browser and send me the output?

You are using WebKitGTK 2.42.1-2, right ?

Berto



Bug#1053542: src/javax/annoation/* license

2023-10-06 Thread Sebastiaan Couwenberg

On 10/6/23 14:33, Taylor Smock wrote:
@Thorsten Alteholz: Can you please explain /why/ you think those files 
have the CC-BY-2.5 license?


All the javax.annotation.concurrent sources are CC-BY-2.5, see:


https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/GuardedBy.java/

https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/Immutable.java/

https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/NotThreadSafe.java/

https://sources.debian.org/src/josm/0.0.svn18822%2Bdfsg-1/src/javax/annotation/concurrent/ThreadSafe.java/

These all have:

 /*
  * Copyright (c) 2005 Brian Goetz
  * Released under the Creative Commons Attribution License
  *   (http://creativecommons.org/licenses/by/2.5)
  * Official home: http://www.jcip.net
  */

Kind Regards,

Bas

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



Bug#1053542: src/javax/annoation/* license

2023-10-06 Thread Taylor Smock
@Thorsten Alteholz: Can you please explain /why/ you think those files 
have the CC-BY-2.5 license?


We are currently using the JSR305 annotations ( 
https://mvnrepository.com/artifact/com.google.code.findbugs/jsr305 ) 
which has an Apache 2.0 license. What it /looks/ like to me is that 
someone decided that everything in the javax/annotation directory had a 
CC-BY-2.5 license. I wasn't able to find any information on that via a 
quick search, but maybe you have more context on that.



Thanks,

Taylor


Bug#1053516: catch2: new v3 upstream release available

2023-10-06 Thread Mathieu Mirmont
On Thu, Oct 05, 2023 at 04:03:47PM +0200, Drew Parsons wrote:
> 
> Could catch2 please be updated to the latest upstream release?

Sure. I wasn't planning on packaging the 3.x series initially because
they abandonned the header-only approach that got me interested in
catch2, but if there's demand for it then I can do that.

-- 
Mathieu Mirmont 



Bug#1053563: glueviz: doesn't start anymore

2023-10-06 Thread Ole Streicher

Package: glueviz
Version: 1.0.1+dfsg-2
Severity: serious

Dear maintainer,

when starting glue on Debian testing, I get a Python error:

$ glue
/usr/bin/glue:6: DeprecationWarning: pkg_resources is deprecated as an API. See 
https://setuptools.pypa.io/en/latest/pkg_resources.html
  from pkg_resources import load_entry_point
QSocketNotifier: Can only be used with threads started with QThread
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to 
disable this validation.
Traceback (most recent call last):
  File "/usr/bin/glue", line 11, in 
sys.exit(load_entry_point('glue_core==1.0.1', 'gui_scripts', 'glue')())
 ^
  File "/usr/lib/python3/dist-packages/glue/main.py", line 259, in main
start_glue(**kwargs)
  File "/usr/lib/python3/dist-packages/glue/main.py", line 156, in start_glue
load_plugins(splash=splash, require_qt_plugins=True)
  File "/usr/lib/python3/dist-packages/glue/main.py", line 347, in load_plugins
splash.set_progress(100. * iplugin / float(n_plugins))
  File "/usr/lib/python3/dist-packages/glue/app/qt/splash_screen.py", line 31, 
in set_progress
self.progress.setValue(value)
TypeError: setValue(self, value: int): argument 1 has unexpected type 'float'

Probably, it needs an update to the latest version.

Best

Ole



Bug#1053562: nvidia-driver: Please package version 535 (possibly solves issues with running Dota 2).

2023-10-06 Thread Sylvain BOILARD
Package: nvidia-driver
Version: 530.41.03-3
Severity: normal

Dear Maintainer,

Please consider packaging version 535 of the NVIDIA drivers as that
version seems to solve an issue with the game Dota 2 as is discussed
here: https://github.com/ValveSoftware/Dota-2/issues/2414 .

To briefly summarize the issue, the game freezes when drawing some
particle effects, and the following error appears in the system log:

[ 6398.284496] NVRM: GPU at PCI::01:00: 
GPU-5031fcee-5e0f-e0ab-2215-3b3790c16154
[ 6398.284518] NVRM: Xid (PCI::01:00): 32, pid=11430, name=dota2, Channel 
ID 0036 intr 0004
[ 6398.285005] NVRM: Xid (PCI::01:00): 32, pid=11430, name=dota2, Channel 
ID 0036 intr 0080

Some users report solving the issue by installing version 535 of the
NVIDIA drivers.

Cheers,

-- Package-specific info:
uname -a:
Linux naelys 6.5.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) 
x86_64 GNU/Linux

/proc/version:
Linux version 6.5.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 
13.2.0-4) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC 
Debian 6.5.3-1 (2023-09-13)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  530.41.03  Thu Mar 16 19:48:20 
UTC 2023
GCC version:  gcc version 13.2.0 (Debian 13.2.0-4) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 
1050] [10de:1c81] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Gigabyte Technology Co., Ltd GP107 [GeForce GTX 1050] 
[1458:3766]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Oct  6 12:02 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Oct  6 12:02 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Oct  6 12:02 /dev/nvidia-modeset
crw-rw-rw-  1 root root   241,   0 Oct  6 12:02 /dev/nvidia-uvm
crw-rw-rw-  1 root root   241,   1 Oct  6 12:02 /dev/nvidia-uvm-tools
crw-rw-rw-  1 root root   195,   0 Oct  6 12:02 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Oct  6 12:02 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Oct  6 12:02 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Oct  6 12:02 pci-:01:00.0-render -> ../renderD128

/dev/nvidia-caps:
total 0
cr 1 root root 244, 1 Oct  6 13:55 nvidia-cap1
cr--r--r-- 1 root root 244, 2 Oct  6 13:55 nvidia-cap2
video:x:44:boilard

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvidia-allocator.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-allocator.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-allocator.so.1
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-nvvm.so.4-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.4
  slave nvidia--libnvidia-nvvm.so.530.41.03-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-nvvm.so.530.41.03
  slave 

Bug#1052607: pxdvi can not use haranoaji fonts

2023-10-06 Thread Takeshi Soejima
Youhei SASAKI  writes:

>> If kanjix.map is generated to use haranoaji fonts (default) by
>> kanji-config-updmap, dvipdfmx works fine, but pxdvi can not display
>> japanese characters.
>
> I can't reproduce this bugs.
> Please send sample TeX file.

Sorry for not fully showing the situation. The status of updmap is:

  # kanji-config-updmap-sys status 
  CURRENT family for ja: haranoaji (variant: -04)
  Standby family : haranoaji
  Standby family : ipa

And a sample TeX file is:

  historia.tex

After receiving your reply, I tried haranoaji without jis2004 option.

  # kanji-config-updmap-sys status   
  CURRENT family for ja: haranoaji (variant: )
  Standby family : ipa

Then japanese characters are displayed correctly (of course with the old
style kanji figures)!

So the point is: pxdvi can not use haranoaji fonts following jis2004.
I'm afraid that any fonts following jis2004 may suffer from the issue.



historia.tex.gz
Description: application/gzip


Bug#1032396: build-rdeps does not work in bookworm

2023-10-06 Thread Gioele Barabucci

Control: tags -1 patch

A patch to fix this issue is available at:

https://salsa.debian.org/debian/devscripts/-/merge_requests/368

Regards,

--
Gioele Barabucci



Bug#1053561: ydotoold segfaults after a few mousemoves

2023-10-06 Thread Lucio Crusca
Package: ydotoold
Version: 0.1.8-3
Severity: important
X-Debbugs-Cc: lu...@sulweb.org

Dear Maintainer,

I've tried ydotool to simulate a few mouse movements and clicks.
Sometimes it works, sometimes ydotoold crashes.

I wonder if updating the package to the most recent upstream release
(1.0.4 as of this writing) could solve the problem with little effort,
since there is at least another report that suggests the problem might
have already been solved: https://github.com/ReimuNotMoe/ydotool/issues/201


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

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

-- no debconf information



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Alexey Kuznetsov
> Luckily we managed to fit most initrds into 4GB now so we're probably
> safe for now if you don't do crazy things like high-memory password
> hashing.

argon2id is memory dependent key. Recommended key size (memory
requirements, not the key it self) are 1GB in heap size.

Here is my desktop machine. Memory map using following script (it
showing blocks more then 1MB in size).

dmesg | awk '/usable/ && /BIOS-e820/ && match($0, /mem ([0-9a-z]+)-([0-
9a-z]+)/,aa){s=strtonum(aa[1]);e=strtonum(aa[2]);if(e-
s>1024*1024)printf("0x%x-0x%x %dGB\n",s,e,((e-s)/1024/1024/1024))}'

0x10-0x35f3cfff 0GB
0x1-0x4bfff 14GB

It is clear here is no space below 4GB. And argon2id will most likely
fail on that machine if here is no >4GB grub support.

> I have absolutely no idea what you're saying, but as you may have
seen
> by the recent CVE again, we have a lot of problem with code quality
and
> need to minimize the attack surface as much as reasonably possible.

I'm sorry. I should be more clear and polite here. I see that FDE (full
disk encryption) is more secure, since I do not have to deal with
signing kernels and init.rd data. Also having FDE reducing the EFI
partition size significantly. So, in ideal world here will be only LUKS
disk encryption, and EFI would support decryption of disk, which will
resolve all CVE grub related issues at once.



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Julian Andres Klode
On Fri, Oct 06, 2023 at 01:36:04PM +0300, Alexey Kuznetsov wrote:
> > Feel free to land the support upstream, but it's not something that
> > we should be shipping downstream.
> 
> I report upstream. But seems like it not going to be fixed anytime
> soon. So, I share my smartmem.patch here. But I have no idea how it
> works here at Debian. Maybe I better to keep it as is, rebuilding grub
> locally.

Regarding the memory allocation, it is much more complex than you think
it is. Unfortunately plenty of devices have broken firmware and will
fail to work with allocations over 4GB, some just DMA files to different
regions when you pass them high memory.

Luckily we managed to fit most initrds into 4GB now so we're probably
safe for now if you don't do crazy things like high-memory password
hashing.

> 
> > Going forward, for secure boot, our focus is not on adding things,
> but on removing
> > existing things like f2fs file support again. It stands to reason
> > that encrypted /boot should not be supported either as there is no
> > practical use case (it is security by obscurity) and you are better
> > served by an unencrypted boot with a pre-built signed initrd or
> > a MOK-signed initrd (or really UKI), and decrypting untrusted data
> > hence is unnecessary danger.
> > 
> 
> Saying things I put in my pocket are untrusted, but items gaven to me
> by other guys with sign, are trusted?! That how security treated here
> at debian from all members?

I have absolutely no idea what you're saying, but as you may have seen
by the recent CVE again, we have a lot of problem with code quality and
need to minimize the attack surface as much as reasonably possible.

> 
> Beside security point, having hudge many GB boot partition with all
> kernel installed is a pain. I keep my EFI under 50MB for binaries to
> boot.

In an optimal world, /boot would be a separate FAT partition (or well
the ESP directly) and kernels would be copied there [and would be UKI
with pre-built initrd] and we would not have any support for other
file systems or luks or crap. Heck optimally we'd not have any disk
drivers and file systems and just use the firmware implementations :D

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Alexey Kuznetsov
> Feel free to land the support upstream, but it's not something that
> we should be shipping downstream.

I report upstream. But seems like it not going to be fixed anytime
soon. So, I share my smartmem.patch here. But I have no idea how it
works here at Debian. Maybe I better to keep it as is, rebuilding grub
locally.

> Going forward, for secure boot, our focus is not on adding things,
but on removing
> existing things like f2fs file support again. It stands to reason
> that encrypted /boot should not be supported either as there is no
> practical use case (it is security by obscurity) and you are better
> served by an unencrypted boot with a pre-built signed initrd or
> a MOK-signed initrd (or really UKI), and decrypting untrusted data
> hence is unnecessary danger.
> 

Saying things I put in my pocket are untrusted, but items gaven to me
by other guys with sign, are trusted?! That how security treated here
at debian from all members?

Beside security point, having hudge many GB boot partition with all
kernel installed is a pain. I keep my EFI under 50MB for binaries to
boot.



Bug#1053560: meld: Search and replace pattern for newline differs when using replace vs replace all

2023-10-06 Thread Moritz Gericke
Package: meld
Version: 3.22.0-2
Severity: normal
X-Debbugs-Cc: xmoex...@gmail.com

Dear Maintainer,

   * What led up to the situation?
I was using meld and wanted to modify long lines via
meld's search-and-replace to be able to diff them
visually.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I entered the following line: xaxaxa
Then hit CTRL+H, entering a in the search field and \n
in the replace field. I checked the Regular expression
flag. Then I hit replace once and replace-all once.
   * What was the outcome of this action?
The text transformed in the following way:
x
x\nx\n

   * What outcome did you expect instead?
I expected the following:
x
x
x




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

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

Versions of packages meld depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtksource-4   4.8.4-4
ii  libgtk-3-0   3.24.37-2
ii  patch2.7.6-7
ii  python3  3.11.2-1+b1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1

Versions of packages meld recommends:
ii  yelp  42.2-1

meld suggests no packages.

-- no debconf information



Bug#1053559: Feature: argon2id support

2023-10-06 Thread Julian Andres Klode
Control: tag -1 wontfix upstream

On Fri, Oct 06, 2023 at 12:51:40PM +0300, Alexey Kuznetsov wrote:
> Package: grub-efi-amd64-bin
> 
> Dear Maintainer,
> 
> I managed to install argon2i patches from Arch repo and it works!
> But argon2 may fail on some system due to lack of memory error and
> makes some systems unbootable.
> 
> In short: grub2 by default on x64 machines only allocates memory only
> from first 4GB (0x1000) physical address to avoid EFI bugs (which
> are very common, when programmers EFI using 32bit register for pointers,
> which as result causing EFI to crash when system sends x64 bit pointers
> during IO proc calls). As result not every machines has enough (1GB
> continuous) memory for argon2id keys. So we need allocate memory from higher
> regions >4gb. I wrote a smartmem.patch (hack, since it need more work).
> 
> You need argon_*.patch:
> 
> * https://aur.archlinux.org/packages/grub-improved-luks2-git
> 
> smartmem.patch (allow to allocate >4gb if original allocation <4gb
> fails)
> 
> This is my original conversation (about smartmem.patch >4gb patch):
> 
> * https://savannah.gnu.org/bugs/index.php?64471

Feel free to land the support upstream, but it's not something that
we should be shipping downstream.

Going forward, for secure boot, our focus is not on adding things, but on 
removing
existing things like f2fs file support again. It stands to reason
that encrypted /boot should not be supported either as there is no
practical use case (it is security by obscurity) and you are better
served by an unencrypted boot with a pre-built signed initrd or
a MOK-signed initrd (or really UKI), and decrypting untrusted data
hence is unnecessary danger.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en



Bug#1041160: linux-image-6.3.0-2-amd64: no pairing with 6.3.0.1 possible

2023-10-06 Thread Dietmar Czekay

H Salvatore,

it seems to be an Debian configuration problem which still exist in 
kernel 6.5.


I checked the current Ubuntu Live version with success. Everything works 
as expected.


Maybe the Bluetooth configuration is buggy. A second problem I have is 
choppy sound with all of my bluetooth headphones (MM500 from Sennheiser 
- an old one) and Sony WH-1000XN3 (a newer one)



Dietmar

Am 24.07.23 um 21:40 schrieb Dietmar Czekay:


#1 SMP PREEMPT_DYNAMIC Debian 6.4.4-1 (2023-07-23) brings no change in 
the pairing behavior:



Jul 24 21:36:24 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:27 debian kernel: rtw_8821ce :03:00.0: failed to send 
h2c command
Jul 24 21:36:27 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0xfc19
Jul 24 21:36:27 debian kernel: Bluetooth: hci0: unexpected event for 
opcode 0x2016
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected cc 0x0c7c 
length: 1 < 3
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x06 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x07 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x08 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: Bluetooth: hci0: unexpected SMP command 
0x09 from d1:cf:2f:cf:76:28
Jul 24 21:36:28 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:32 debian bluetoothd[789]: src/service.c:service_accept() 
input-hog profile accept failed for D1:CF:2F:CF:76:28
Jul 24 21:36:33 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:36 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:39 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:41 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:46 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:48 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:51 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:52 debian plasmashell[2010]: kf.bluezqt: PendingCall 
Error: "Did not receive a reply. Possible causes include: the remote 
application did not send a reply, the message bus security policy 
blocked the reply, the reply timeout expired, or the network 
connection was broken."
Jul 24 21:36:53 debian kernel: rtw_8821ce :03:00.0: firmware 
failed to leave lps state
Jul 24 21:36:54 debian bluetoothd[789]: 
src/device.c:set_wake_allowed_complete() Set device flags return 
status: Invalid Parameters



I tested the new kernel with sid

On 24.07.23 10:16, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

Hi,

On Wed, Jul 19, 2023 at 10:26:30PM +0200, Dietmar Czekay wrote:

I checked different versions. Here are the results:

beginning right after clicking "add device" until the device manager says
"not able to pair"

Just Debian 6.1.37-1 works.

#1 SMP PREEMPT_DYNAMIC Debian 6.3.11-1 (2023-07-01)

6.4.4-1 was uploaded to unstable in meanwhile, you might be able to
check against the newer version as well?

Regards,
Salvatore


Bug#1053559: Feature: argon2id support

2023-10-06 Thread Alexey Kuznetsov

Package: grub-efi-amd64-bin

Dear Maintainer,

I managed to install argon2i patches from Arch repo and it works!
But argon2 may fail on some system due to lack of memory error and
makes some systems unbootable.

In short: grub2 by default on x64 machines only allocates memory only
from first 4GB (0x1000) physical address to avoid EFI bugs (which
are very common, when programmers EFI using 32bit register for pointers,
which as result causing EFI to crash when system sends x64 bit pointers
during IO proc calls). As result not every machines has enough (1GB 
continuous) memory for argon2id keys. So we need allocate memory from 
higher regions >4gb. I wrote a smartmem.patch (hack, since it need more 
work).


You need argon_*.patch:

* https://aur.archlinux.org/packages/grub-improved-luks2-git

smartmem.patch (allow to allocate >4gb if original allocation <4gb
fails)

This is my original conversation (about smartmem.patch >4gb patch):

* https://savannah.gnu.org/bugs/index.php?64471

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/luks / btrfs 
rw,noatime,ssd,discard,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p2 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 
0 0
/dev/sdb1 /media/axet/4GB btrfs 
rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/sda1 /media/axet/1TB btrfs 
rw,nosuid,nodev,relatime,space_cache,subvolid=5,subvol=/ 0 0

*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}

if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u 9aa58ce3e29149ccaa3ceb12a9f0af1c
set root='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c' 
92475bc2-c978-4f26-9e6b-7bc1dde85cd4

else
search --no-floppy --fs-uuid --set=root 92475bc2-c978-4f26-9e6b-7bc1dde85cd4
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u 9aa58ce3e29149ccaa3ceb12a9f0af1c
set root='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 
--hint='cryptouuid/9aa58ce3e29149ccaa3ceb12a9f0af1c' 
92475bc2-c978-4f26-9e6b-7bc1dde85cd4

else
search --no-floppy --fs-uuid --set=root 92475bc2-c978-4f26-9e6b-7bc1dde85cd4
fi
insmod png
if background_image 
/usr/share/desktop-base/emerald-theme/grub/grub-16x9.png; then

set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class 
gnu --class os $menuentry_id_option 
'gnulinux-simple-92475bc2-c978-4f26-9e6b-7bc1dde85cd4' {

load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod cryptodisk
insmod luks2
insmod gcry_rijndael
insmod gcry_rijndael
insmod gcry_sha256
insmod btrfs
cryptomount -u 9aa58ce3e29149ccaa3ceb12a9f0af1c
set 

Bug#1042670: flycheck: FTBFS with Sphinx 7.1, docutils 0.20: TypeError: not all arguments converted during string formatting

2023-10-06 Thread Xiyue Deng
Control: fixed -1 flycheck 33~git20230824.e56e30d-1
thanks

Hi,

Lucas Nussbaum  writes:

> Source: flycheck
> Version: 32~git.20200527.9c435db3-4
> Severity: important
> Tags: ftbfs
> User: python-modules-t...@lists.alioth.debian.org
> Usertags: sphinx7.1
>
> Hi,
>
> flycheck fails to build with Sphinx 7.1 and docutils 0.20, both of which
> are currently available in experimental.
>
> Relevant part (hopefully):
>> make[2]: Entering directory '/<>/doc'
>> sphinx-build -b html -d _build/doctrees -j4 . -Dflycheck_offline_html=1 
>> _build/html
>> Running Sphinx v7.1.1
>> making output directory... done
>> Building offline documentation without external resources!
>> building [mo]: targets for 0 po files that are out of date
>> writing output... 
>> building [html]: targets for 22 source files that are out of date
>> updating environment: [new config] 22 added, 0 changed, 0 removed
>> 
>> Sphinx parallel build error:
>> TypeError: not all arguments converted during string formatting
>> make[2]: *** [Makefile:90: html] Error 2
>
>
> The full build log is available from:
> http://qa-logs.debian.net/2023/07/30/exp/flycheck_32~git.20200527.9c435db3-4_unstable_sphinx-exp.log
>
> Please see [1] for Sphinx changelog and [2] for Docutils changelog.
>
> Also see [3] for the list of deprecated/removed APIs in Sphinx and possible
> alternatives to them.
>
> Some notable changes in Sphinx 6 and Sphinx 7:
>
> - Sphinx no longer includes jquery.js and underscore.js by default.
>   Please use python3-sphinxcontrib.jquery package if you are using a custom
>   template and it still needs jquery.
>
> - The setup.py build_sphinx command was removed. Please instead call
>   sphinx-build or "python3 -m sphinx" directly.
>
> - For packages using the extlinks extension, the caption should contain
>   exactly one "%s" placeholder (if caption is not None).
>
> In case you have questions, please Cc sph...@packages.debian.org on reply.
>
> [1]: https://www.sphinx-doc.org/en/master/changes.html
> [2]: 
> https://repo.or.cz/docutils.git/blob/refs/tags/docutils-0.20.1:/RELEASE-NOTES.txt
> [3]: 
> https://www.sphinx-doc.org/en/master/extdev/deprecated.html#dev-deprecated-apis
>
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=sphinx7.1;users=python-modules-t...@lists.alioth.debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=sphinx7.1=python-modules-t...@lists.alioth.debian.org=1=1=1=1#results
>
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
>

Didn't notice that the latest upstream snapshot which got packaged and
uploaded already fixed this issue, which I believe is from this
commit[1].  Also verified locally with experimental-enabled sbuild to be
working.  Marking as done with version.

[1] 
https://github.com/flycheck/flycheck/commit/646de81bfef309aeb3204992ef4d129e1cb53e14

-- 
Xiyue Deng



Bug#1052824: flycheck: FTBFS if gawk is installed

2023-10-06 Thread Xiyue Deng
Nicholas D Steeves  writes:

> Xiyue Deng  writes:
>
>> Indeed.  I've refinalized, recompiled, and reuploaded it to mentors[1].
>> PTAL.  Will create tag once it's uploaded to unstable.
>
> There was some undocumented churn with python3-sphinx, but this release
> isn't at fault, and it solves an RC bug, so I went ahead and uploaded.
> Please consider double checking for stuff like this in the future.  You
> can do this with something like
>
>   cd $project_root
>   git diff $latest_tagged_version_in_the_archive -- debian
>

Ah indeed current version based on upstream snapshot also fixes
bug#1042670[1], which is from this commit[2] I assume.  I verified
locally with experimental-enabled sbuild that it builds successfully.
Will close that bug with a version.

[1] https://bugs.debian.org/1042670
[2] 
https://github.com/flycheck/flycheck/commit/646de81bfef309aeb3204992ef4d129e1cb53e14

>>> Alternatively, if you're looking for off-team sponsors, then you should
>>> file an RFS in addition to uploading to mentors.
>>>
>>
>> Still prefer to let you sponsor here ;)
>
> Fine with me, but if no one on the team (including myself) has time,
> then please keep this in mind.
>
> Cheers,
> Nicholas
>

-- 
Xiyue Deng


signature.asc
Description: PGP signature


Bug#1053558: Impossible to add VPN connection or change settings of existing profiles

2023-10-06 Thread Daniel Leidert
Package: network-manager-openconnect-gnome
Version: 1.2.10-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I have existing network-manager profiles for openconnect (anyconnect) and I try
to create new ones.  If I want to create a new profile, the dialog appears, but
after adding the necessary informtion and hitting the "Apply" button, nothing
has been saved.  There is no new connection shown in the VPN settings page. I
also tried to add a route to an existing connection profile. While it seems to
save the setting for automatically/manually setting routes, the route itself is
also not saved.  Right now, I have to write the profiles by hand. I don't see
any errors in the logs (except for "openconnect[...]: Failed to open
/dev/vhost-net", which I think is irrelevant).

There might be some relevance in these reports, though:

https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/106
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2499

Regards, Daniel


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

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

Versions of packages network-manager-openconnect-gnome depends on:
ii  libc62.37-12
ii  libgcr-base-3-1  3.41.1-3
ii  libgcr-ui-3-13.41.1-3
ii  libglib2.0-0 2.78.0-2
ii  libgtk-3-0   3.24.38-5
ii  libgtk-4-1   4.12.2+ds-1
ii  libnm0   1.44.0-1
ii  libnma-gtk4-01.10.6-1
ii  libnma0  1.10.6-1
ii  libopenconnect5  9.12-1
ii  libsecret-1-00.21.1-1
ii  libsoup2.4-1 2.74.3-1
ii  libwebkit2gtk-4.0-37 2.42.1-1
ii  libxml2  2.9.14+dfsg-1.3
ii  network-manager-openconnect  1.2.10-1

network-manager-openconnect-gnome recommends no packages.

network-manager-openconnect-gnome suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmUf0vUACgkQS80FZ8KW
0F28BhAAyfR7dmdgjUZJQwiy0lzYZ3adDS6qqaE1yKh/20U0JamyOCMIaOx4a/gq
+EaRWLsQhqUEAgauTZovLrwMsqC3Xb7yKGNLwqYH8+kJqErmj2JjpjbRzJVgZLat
zuWl9yey1GlWYTbhSmNTBv6Vm+YbebSfAq6jblJZJuMwkBWG6JMa1RqeP4eXoS8Q
t/dcNIE0WW8rz78oJy+qYVGsRQBESiT+7/XRfPGjJIDbWqWysg3oeSMQmDlauiT3
09hQTF+m5vAMaKCE7Iu4SBlA717FmLS1iFB31BJ35gE7k4m+GF8D7uUQ1LQEaGHR
cSnGQMkumXp9Usa1QICgMGPmSF2GoFIzvIVV9Z35le2nPHuGKCEpbshrCV/6eBWr
j5wTc0aQ59w2ZQGYDtYc5RBfFLHoj/UVr7bwx1zspGNLTAZt3sYLBy9VfBMs27qf
6AQLEyLT3icgIwLIGT7tX+2ubusstgljTlnCWjDE+QDOzNm0kdO/I9sPfldsdPkh
kQk+YvZdmule00DcP1jV2ljwOSuATkdZ6Ky+YmYAK+SajSaPmjNd29W2jWK7oNjM
QBVh9O/WP0Gnaot39Nr2oSaDy+98mKYy8ZOrxPmXWKNqP3O2njjhMdJI/T/HlGNL
hzHuj0GigyJ1FvI0kEmEYdnShkT4/MXLNcYZGdms0AST/2GiMKI=
=EkRK
-END PGP SIGNATURE-



Bug#1050769: greetd FTBFS with DEB_BUILD_OPTIONS=nocheck: does not perform the build

2023-10-06 Thread Arnaud Ferraris

Hi,

On Sun, 27 Aug 2023 19:56:50 +0200 Helmut Grohne  wrote:

Justification: nocheck FTBFS is serious since trixie

greetd fails to build from source, when DEB_BUILD_OPTIONS contains
nocheck. A build ends as follows:

[...]

Note that nothing is ever built. debian/rules suggests that it attempts
to build using dh_auto_test, but given a high enough compatibility level
dh_auto_test honours DEB_BUILD_OPTIONS=nocheck. You probably need to run
dh_auto_build at some point.


This packages uses dh-cargo, which doesn't implement a build() method, 
making dh_auto_build a noop for us.


IMHO it is a dh-cargo bug (see #1053556[1]) which must be fixed before 
greetd's debian/rules can be updated to use dh_auto_build.


Regards,
Arnaud

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



Helmut





OpenPGP_0xD3EBB5966BB99196.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1053557: squid: Squid autopkgtest failures prevents squid from entering testing

2023-10-06 Thread Jan Wagner

Source: squid
Version: 6.3-1
Severity: normal
X-Debbugs-Cc: w...@cyconet.org

Hi there,

looking at https://ci.debian.net/packages/s/squid/testing/amd64/ the 
autopkgtest (upstream-test-suite) fails:


154s make: Entering directory 
'/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src/test-suite'
154s make  ESIExpressions mem_node_test mem_hdr_test splay 
syntheticoperators VirtualDeleteOperator
154s make[1]: Entering directory 
'/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src/test-suite'
154s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 
-DDEFAULT_SQUID_CONFIG_DIR=\"/etc\"   -I.. -I../include -I../lib 
-I../src -I../include  -isystem /usr/include/mit-krb5   -I. 
-I/usr/include/libxml2  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wimplicit-fallthrough=5 -Wpointer-arith -Wwrite-strings -Wcomments 
-Wshadow -Wmissing-declarations -Woverloaded-virtual -Werror -pipe 
-D_REENTRANT -I/usr/include/p11-kit-1-g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -march=native -c -o test_tools.o 
test_tools.cc
154s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 
-DDEFAULT_SQUID_CONFIG_DIR=\"/etc\"   -I.. -I../include -I../lib 
-I../src -I../include  -isystem /usr/include/mit-krb5   -I. 
-I/usr/include/libxml2  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wimplicit-fallthrough=5 -Wpointer-arith -Wwrite-strings -Wcomments 
-Wshadow -Wmissing-declarations -Woverloaded-virtual -Werror -pipe 
-D_REENTRANT -I/usr/include/p11-kit-1-g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -march=native -c -o 
stub_cbdata.o stub_cbdata.cc
154s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 
-DDEFAULT_SQUID_CONFIG_DIR=\"/etc\"   -I.. -I../include -I../lib 
-I../src -I../include  -isystem /usr/include/mit-krb5   -I. 
-I/usr/include/libxml2  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wimplicit-fallthrough=5 -Wpointer-arith -Wwrite-strings -Wcomments 
-Wshadow -Wmissing-declarations -Woverloaded-virtual -Werror -pipe 
-D_REENTRANT -I/usr/include/p11-kit-1-g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -march=native -c -o 
stub_MemBuf.o stub_MemBuf.cc
154s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 
-DDEFAULT_SQUID_CONFIG_DIR=\"/etc\"   -I.. -I../include -I../lib 
-I../src -I../include  -isystem /usr/include/mit-krb5   -I. 
-I/usr/include/libxml2  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wimplicit-fallthrough=5 -Wpointer-arith -Wwrite-strings -Wcomments 
-Wshadow -Wmissing-declarations -Woverloaded-virtual -Werror -pipe 
-D_REENTRANT -I/usr/include/p11-kit-1-g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -march=native -c -o stub_SBuf.o 
stub_SBuf.cc
155s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 
-DDEFAULT_SQUID_CONFIG_DIR=\"/etc\"   -I.. -I../include -I../lib 
-I../src -I../include  -isystem /usr/include/mit-krb5   -I. 
-I/usr/include/libxml2  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wimplicit-fallthrough=5 -Wpointer-arith -Wwrite-strings -Wcomments 
-Wshadow -Wmissing-declarations -Woverloaded-virtual -Werror -pipe 
-D_REENTRANT -I/usr/include/p11-kit-1-g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -march=native -c -o stub_tools.o 
stub_tools.cc
155s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 
-DDEFAULT_SQUID_CONFIG_DIR=\"/etc\"   -I.. -I../include -I../lib 
-I../src -I../include  -isystem /usr/include/mit-krb5   -I. 
-I/usr/include/libxml2  -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wimplicit-fallthrough=5 -Wpointer-arith -Wwrite-strings -Wcomments 
-Wshadow -Wmissing-declarations -Woverloaded-virtual -Werror -pipe 
-D_REENTRANT -I/usr/include/p11-kit-1-g -O2 
-ffile-prefix-map=/tmp/autopkgtest-lxc.mpw063si/downtmp/build.lxu/src=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -march=native -c -o stub_fatal.o 
stub_fatal.cc
156s g++ -std=c++17 -DHAVE_CONFIG_H 
-DDEFAULT_CONFIG_FILE=\"/etc/squid.conf\" 
-DDEFAULT_SQUID_DATA_DIR=\"/usr/share\" 

Bug#1053556: dh-cargo: should provide a build() method

2023-10-06 Thread Arnaud Ferraris
Package: dh-cargo
Version: 30
Severity: important
X-Debbugs-Cc: aferra...@debian.org

Dear Maintainer,

dh-cargo currently only provides the configure(), test(), clean() and install()
methods. As a consequence, building a package requires calling dh_auto_test,
which is a noop when DEB_BUILD_OPTIONS include "nocheck"[1].

This causes problems when packaging applications (i.e. not crates), as it then
leads to build failures in this specific case (see #1050769[2] for example).

As a consequence, it would be helpful to split the current test() method into
build() and test() so dh_auto_build can be used to build the package, and
dh_auto_test can be used only for executing tests (building those in the
process if needed).

Regards,
Arnaud

[1] https://salsa.debian.org/debian/debhelper/-/blob/main/dh_auto_test#L58
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050769


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

Kernel: Linux 6.4.0-3-amd64 (SMP w/16 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 dh-cargo depends on:
ii  cargo  0.66.0+ds1-1
ii  debhelper  13.11.6
ii  perl   5.36.0-9
ii  python33.11.4-5+b1

dh-cargo recommends no packages.

dh-cargo suggests no packages.

-- no debconf information



Bug#1053243: prometheus-alertmanager: Please package the gui

2023-10-06 Thread Daniel Swarbrick

Hi Bastien,

Although the Elm compiler is now in Debian, the issue preventing the 
packaging of the Alertmanager web UI is the lack of the Elm dependencies 
used by the UI (see ui/app/elm.json in the Alertmanager source). This 
problem also afflicts the Prometheus package, where we are unable to 
include the modern React UI, for essentially the same reason.


Note that the generate-ui.sh script that is bundled with 
prometheus-alertmanager does at least now use the elm-compiler provided 
by Debian, rather than fetching it from Github (see 
https://salsa.debian.org/go-team/packages/prometheus-alertmanager/-/commit/51802d88957fc08bf13daab426e59718fadcf66e)


Regards,
Daniel Swarbrick



OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1053519: Fix available upstream

2023-10-06 Thread Simon Richter

Hi,

this bug is known upstream, and a patch already exists. Would it be 
possible to apply this so ghdl can be compiled on arm64?


   Simon



Bug#1053553: please remove me from Uploaders

2023-10-06 Thread Simon Richter
Package: clinfo
Version: 3.0.23.01.25-1
Severity: wishlist
X-Debbugs-Cc: s...@debian.org

Hi,

as the last copy of the clinfo program that I wrote years ago has left
the archive and I've not been involved with packaging the replacement, I
think there is no good reason for me to stay on the Uploaders list.

   Simon

-- Package-specific info:
Installed ICDs:
/etc/OpenCL/vendors/:
total 4
-rw-r--r-- 1 root root 22 Mar 29  2023 nvidia.icd

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

Kernel: Linux 6.1.0-12-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 clinfo depends on:
ii  libc62.36-9+deb12u3
ii  ocl-icd-libopencl1 [libopencl1]  2.3.1-1

clinfo recommends no packages.

clinfo suggests no packages.

Versions of packages clinfo is related to:
ii  nvidia-opencl-icd [opencl-icd]  525.125.06-1~deb12u1

-- no debconf information



Bug#1053555: openssh-server: DebianBanner setting not shown in configuration dump

2023-10-06 Thread Rasmus Villemoes
Package: openssh-server
Version: 1:8.4p1-5+deb11u1
Severity: minor

Dear Maintainer,

'sshd -T', and since v9.3 also 'sshd -G', is supposed to print the
full, effective configuration. However, debian-banner.patch neglects
to update dump_config(), so there's no line showing the effective
value of the debianbanner setting.

I think the fix is as simple as adding

  dump_cfg_fmtint(sDebianBanner, o->debian_banner);

somewhere appropriate in dump_config().

IOW,

  sshd -T | grep ^debianbanner

produces nothing, but I'd expect it (in the default Debian
configuration) to print

  debianbanner yes

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

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

Versions of packages openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.12
ii  libaudit1  1:3.0-2
ii  libc6  2.31-13+deb11u7
ii  libcom-err21.46.2-2
ii  libcrypt1  1:4.4.18-4
ii  libgssapi-krb5-2   1.18.3-6+deb11u3
ii  libkrb5-3  1.18.3-6+deb11u3
ii  libpam-modules 1.4.0-9+deb11u1
ii  libpam-runtime 1.4.0-9+deb11u1
ii  libpam0g   1.4.0-9+deb11u1
ii  libselinux13.1-3
ii  libssl1.1  1.1.1n-0+deb11u5
ii  libsystemd0247.3-7+deb11u4
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  openssh-client 1:8.4p1-5+deb11u1
ii  openssh-sftp-server1:8.4p1-5+deb11u1
ii  procps 2:3.3.17-5
ii  runit-helper   2.10.3
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2+deb11u2

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  247.3-7+deb11u4
ii  ncurses-term 6.2+20201114-2+deb11u1
pn  xauth

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded



Bug#1053554: cecil: Missing licenses/copyright in debian/copyright

2023-10-06 Thread Bastian Germann

Source: cecil
Version: 0.9.5+dfsg-5
Severity: serious

cecil's debian/copyright is missing at least the following licenses and 
copyright info:

The embedded Test/libs/nunit-2.4.8's zlib license. Better repack and use the 
nunit Debian package.

The Ms-Pl of symbols/pdb/Microsoft.Cci.Pdb.



Bug#1053552: gavodachs2-server: Error while setting up with postgresql 16

2023-10-06 Thread Ole Streicher

Package: gavodachs2-server
Version: 2.8+dfsg-3
Severity: serious

Hi Markus,

While running the migration test for astropy 5.3.4-1, the installation
of gavodachs2-server failed. Relevant lines from the log:

103s Setting up gavodachs2-server (2.8+dfsg-3) ...
103s Created symlink /etc/systemd/system/multi-user.target.wants/dachs.service 
→ /lib/systemd/system/dachs.service.
103s info: Selecting GID from range 1000 to 5 ...
103s info: Adding group `gavo' (GID 1001) ...
103s info: The home dir /nonexistent you specified can't be accessed: No such 
file or directory
103s
103s info: Selecting UID from range 100 to 999 ...
103s
103s info: Adding system user `gavo' (UID 103) ...
103s info: Adding new user `gavo' (UID 103) with group `gavo' ...
103s info: Not creating `/nonexistent'.
103s info: Adding user `dachsroot' ...
103s info: Selecting UID from range 1000 to 5 ...
103s
103s info: Adding new user `dachsroot' (1001) with group `gavo (1001)' ...
103s info: Creating home directory `/home/dachsroot' ...
103s info: Copying files from `/etc/skel' ...
103s info: Adding new user `dachsroot' to supplemental / extra groups `users' 
...
103s info: Adding user `dachsroot' to group `users' ...
108s *** Error: While executing DB query:
108s
108s   alter role untrusted set extra_float_digits=3
108s
108s The database engine reported:
108s
108s   ERROR:  permission denied to alter role
108s DETAIL:  Only roles with the CREATEROLE attribute and the ADMIN option
108s on role "untrusted" may alter this role.
108s
108s dpkg: error processing package gavodachs2-server (--configure):
108s  installed gavodachs2-server package post-installation script subprocess 
returned error exit status 1
108s dpkg: dependency problems prevent configuration of autopkgtest-satdep:
108s  autopkgtest-satdep depends on gavodachs2-server; however:
108s   Package gavodachs2-server is not configured yet.
108s
108s dpkg: error processing package autopkgtest-satdep (--configure):
108s  dependency problems - leaving unconfigured
108s Errors were encountered while processing:
108s  gavodachs2-server

Full log here: 
https://ci.debian.net/data/autopkgtest/testing/amd64/g/gavodachs/38631770/log.gz

I don't think that has anything to do with the astropy update. This
seems to be connected to Postgresql version (16.0-2); a similar install
(with Postgresql 15.4-3) succeeded.



Bug#1053550: IKEv2 regression when IP address changes behind NAT-T

2023-10-06 Thread Herbert Xu
Package: libreswan
Version: 4.10-2+deb12u1

When the IP address of a host behind NAT changes, libreswan fails
to respond correctly when IKEv2 is used.  This is a regression from
IKEv1 as libreswan will correctly shut down the existing connection
and initiate a new one when DPD kicks in.

Let the host behind NAT be A, and the server be B.  When A's IP
address changes, its data connection to B will be broken.  However,
B continues to respond to A's liveliness messages thus preventing
A from tearing the broken connection down.  This will only resolve
itself when A's SA eventually times out and is rekeyed.

Here is a packet dump on B's side showing this:

A's old address: XXX.XXX.107.30.15410
A's new address: XXX.XXX.212.186.25610
B: XXX.XXX.189.96.4502

07:17:42.939963 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 140

Packet is sent from A's new address.  It is correctly processed
by the kernel (Linux ignores the source address on inbound packets).

07:17:42.940182 IP XXX.XXX.189.96.4502 > XXX.XXX.107.30.15410: UDP-encap: 
ESP(spi=0xd4b2be8b,seq=0x1), length 140

Packet is sent back to A's old address, because libreswan has
not updated the outbound SA to use the new address.  This is
suboptimal but not a regression as libreswan never had code to
deal with this case.  With IKEv1, DPD would eventually kick in
and reestablish the connection.  However, with IKEv2 we instead
see this:

07:18:02.690370 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 1
07:18:22.687887 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 1
07:18:26.793134 IP XXX.XXX.212.186.25610 > XXX.XXX.189.96.4502: UDP, length 61
07:18:26.793398 IP XXX.XXX.189.96.4502 > XXX.XXX.212.186.25610: UDP, length 61
07:18:26.793439 IP XXX.XXX.189.96.4502 > XXX.XXX.212.186.25610: UDP, length 61

As you can see from this, libreswan on B responds to A's new IP
address, making A think that the connection is still alive.  This
does not happen with IKEv1.  B should either not respond to the
packet from the new address, or it should tear down the old SAs
and create new ones with the new address.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt



Bug#1053551: ftbfs on amd64 when building binary-arch

2023-10-06 Thread Simon Richter
Package: gcc-12
Version: 12.3.0-9
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: s...@debian.org

Hi,

I just built arch:all and arch:amd64 packages separately in pbuilder,
and got a reproducible build failure while building amd64 with
--binary-arch. Normal severity because building both arch-dependent and
arch-independent packages together works fine.

/build/gcc-12-12.3.0/build/./prev-gcc/xg++ 
-B/build/gcc-12-12.3.0/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ 
-nostdinc++ -B/build/gc
c-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/src/.libs 
-B/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/libsupc++
/.libs  
-I/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu
  -I/build/gcc-12-12.3.0/build/prev-x86_
64-linux-gnu/libstdc++-v3/include  
-I/build/gcc-12-12.3.0/src/libstdc++-v3/libsupc++ 
-L/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/
libstdc++-v3/src/.libs 
-L/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs 
 -fno-PIE -c -g   -g -O2 -fno-che
cking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual  
  -DHAVE_CONFIG_H -I. -Im2/gm2-gcc -I../../src/gcc -I../../src/gcc/m2/gm2-gcc 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/inclu
de -I../../src/gcc/../libcody  -I../../src/gcc/../libdecnumber 
-I../../src/gcc/../libdecnumber/bid -I../libdecnumber -I../../src/gcc/../
libbacktrace   -I. -Im2/gm2-gcc -I../../src/gcc -I../../src/gcc/m2/gm2-gcc 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../../src/gcc/../libcody  -I../../src/gcc/../libdecnumber 
-I../../src/gcc/../libdecnumber/bid -I../libdecnumber -I../../src/gcc/../lib
backtrace  ../../src/gcc/m2/gm2-gcc/m2type.cc -o m2/gm2-gcc/m2type.o
[...]
In file included from ./tm.h:26,
 from ../../src/gcc/backend.h:28,
 from ../../src/gcc/m2/gm2-gcc/gcc-consolidation.h:26,
 from ../../src/gcc/m2/gm2-gcc/m2type.cc:22:
../../src/gcc/config/i386/i386.h:2374:10: fatal error: insn-attr-common.h: No 
such file or directory
 2374 | #include "insn-attr-common.h"
  |  ^~~~
compilation terminated.

A lot of the other M2 sources are also affected.

   Simon

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

Kernel: Linux 6.1.0-12-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 gcc-12 depends on:
ii  binutils   2.40-2
ii  cpp-12 12.2.0-14
ii  gcc-12-base12.2.0-14
ii  libc6  2.36-9+deb12u3
ii  libcc1-0   12.2.0-14
ii  libgcc-12-dev  12.2.0-14
ii  libgcc-s1  12.2.0-14
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libisl23   0.25-1
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.0-1
ii  libstdc++6 12.2.0-14
ii  libzstd1   1.5.4+dfsg2-5
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gcc-12 recommends:
ii  libc6-dev  2.36-9+deb12u3

Versions of packages gcc-12 suggests:
pn  gcc-12-doc   
pn  gcc-12-locales   
pn  gcc-12-multilib  

-- no debconf information



Bug#1053549: Create a Debian theme for documentation based in Sphinx (reStructuredText)

2023-10-06 Thread Laura Arjona Reina

Package: www.debian.org
Severity: normal
User: debian-...@lists.debian.org
Usertags: design
X-Debbugs-CC: 
debian-...@lists.debian.org,design-de...@alioth-lists.debian.net.


Dear website, documentation and design teams,

Several documentation manuals are being generated now using 
ReStructuredText and Sphinx, and it would be nice that a Debian theme in 
Sphinx is created and used to match our docs appearance with the Debian 
website colours etc.


Currently in the website we publish, at least:

* Debian Policy: https://www.debian.org/doc/debian-policy/
* Debian Developers Reference: 
https://www.debian.org/doc/manuals/developers-reference/index.en.html
* Testing Release notes: currently in 
https://www.debian.org/releases/testing/release-notes/ but that may change


The upstream documentation about theming is here:
 http://www.sphinx-doc.org/en/stable/theming.html

Please take into account that currently the machine www-master where the 
website is built runs bullseye (sphinx version: 3.4.3-2, but at some 
time it will be upgraded to bookworm (sphinx version: 5.3.0-4).


Kind regards
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona



Bug#1053548: check-patroni: does not work well with current Patroni

2023-10-06 Thread Michael Banck
Package: check-patroni
Version: 1.0.0-1
Severity: normal
Tags: patch

Hi,

since version 3.0.4, Patroni displays "streaming" as state if a node is
actually replicating from its leader. This is taken into account by
check-patroni 1.0.0 (see https://github.com/dalibo/check_patroni/pull/30). 

However, the way 1.0.0 handles this is suboptimal: It accepts both
"running" and "streaming" as valid states; however, a state of "running"
for Patroni 3.0.4 and up means broken replication and check-patroni
should not consider this as OK.

This is being worked on upstream as
https://github.com/dalibo/check_patroni/pull/54.

I found another issue however: The streaming state for Standby leaders
was not included in PR#30, so the cluster_has_leader check returns
CRITICAL for standby clusters. This has been filed as
https://github.com/dalibo/check_patroni/issues/58.

I'm attaching two patches for your consideration - the first one is the
draft PR#54 and the second a fix for issue #58, which however will
likely not work well with older Patroni versions, so not sure whether
this is something you want to include at this point.

Actually, I did not realize you had uploaded check-patroni and
independently packaged it for the pkg-postgres team here:
https://salsa.debian.org/postgresql/check-patroni

I'll drop that once check-patroni in unstable works fine with current
Patroni.


Cheers,

Michael

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

Kernel: Linux 4.19.0-22-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 341ac64702569cf68ebe29053c0d076e409fc72f Mon Sep 17 00:00:00 2001
From: benoit 
Date: Wed, 27 Sep 2023 16:37:40 +0200
Subject: [PATCH 1/5] cluster_has_replica: fix the way a healthy replica is
 detected

For patroni >= version 3.0.4:
* the role is replica or sync_standby
* the state is streaming
* the lag is lower or equal to max_lag

For prio versions:
* the role is replica or sync_standby
* the state is running and with the same timeline has the leader
* the lag is lower or equal to max_lag
---
 CHANGELOG.md |  2 ++
 README.md|  3 ++-
 check_patroni/cli.py |  3 ++-
 check_patroni/cluster.py | 51 ++--
 4 files changed, 50 insertions(+), 9 deletions(-)

Index: check-patroni/CHANGELOG.md
===
--- check-patroni.orig/CHANGELOG.md
+++ check-patroni/CHANGELOG.md
@@ -6,6 +6,8 @@
 
 ### Fixed
 
+* Fix what `cluster_has_replica` deems a healthy replica. (#50, reported by 
@mbanck)
+
 ### Misc
 
 ## check_patroni 1.0.0 - 2023-08-28
Index: check-patroni/README.md
===
--- check-patroni.orig/README.md
+++ check-patroni/README.md
@@ -170,8 +170,9 @@ Usage: check_patroni cluster_has_replica
   Check if the cluster has healthy replicas and/or if some are sync standbies
 
   A healthy replica:
-  * is in running or streaming state (V3.0.4)
   * has a replica or sync_standby role
+  * is in running state with the same timeline has the leader (patroni < 
V3.0.4)
+  * is in streaming state (patroni >= V3.0.4)
   * has a lag lower or equal to max_lag
 
   Check:
@@ -182,8 +183,9 @@ Usage: check_patroni cluster_has_replica
   Perfdata:
   * healthy_replica & unhealthy_replica count
   * the number of sync_replica, they are included in the previous count
-  * the lag of each replica labelled with  "member name"_lag
-  * a boolean to tell if the node is a sync stanbdy labelled with  "member 
name"_sync
+  * the lag of each replica labelled with "member name"_lag
+  * the timeline of each replica labelled with "member name"_timeline
+  * a boolean to tell if the node is a sync stanbdy labelled with "member 
name"_sync
 
 Options:
   -w, --warning TEXTWarning threshold for the number of healthy replica
Index: check-patroni/check_patroni/cli.py
===
--- check-patroni.orig/check_patroni/cli.py
+++ check-patroni/check_patroni/cli.py
@@ -343,8 +343,9 @@ def cluster_has_replica(
 
 \b
 A healthy replica:
-* is in running or streaming state (V3.0.4)
 * has a replica or sync_standby role
+* is in running state with the same timeline has the leader (patroni < 
V3.0.4)
+* is in streaming state (patroni >= V3.0.4)
 * has a lag lower or equal to max_lag
 
 \b
@@ -357,8 +358,9 @@ def cluster_has_replica(
 Perfdata:
 * healthy_replica & unhealthy_replica count
 * the number of sync_replica, they are included in the previous count
-* the lag of each replica labelled with  "member 

Bug#1052929: yasnippet: FTBFS: make: *** [debian/rules:4: binary] Error 25

2023-10-06 Thread Xiyue Deng
Nicholas D Steeves  writes:

> Control: forwarded -1 https://github.com/joaotavora/yasnippet/issues/1173
> Control: tag -1 upstream fixed-upstream
>
> Lucas Nussbaum  writes:
>
>> Source: yasnippet
>> Version: 0.14.0+git20200603.5cbdbf0d-2
>> Severity: serious
>> Justification: FTBFS
>> Tags: trixie sid ftbfs
>> User: lu...@debian.org
>> Usertags: ftbfs-20230925 ftbfs-trixie
>
> This looks like it's probably fixed upstream, and I've requested a new
> tagged release there.  Also, the last time either of the existing
> Uploaders worked on this package was 2016, so they should be dropped at
> this time.  I've CCed everyone involved.
>
> Aymeric and Xiyue Deng, would you to take responsibility for this
> package?
>

Glad to, or co-maintain if Aymeric is also onboard.  Will take a look
later this week.

-- 
Xiyue Deng


signature.asc
Description: PGP signature