Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)

[Kai Wasserbäch]

I did manage do get a full back trace for man:

$ gdb --args man apt-get
GNU gdb (Debian 13.2-1) 13.2
[...]
Reading symbols from man...
Reading symbols from 
/usr/lib/debug/.build-id/70/bd707aa6a7ea95d80aaa2933e2d49f1cc56c5f.debug...

(gdb) r
Starting program: /usr/bin/man apt-get
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7f557d18ff36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt full
#0  0x7f557d18ff36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7f557d15dd49 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x7f557d15f26d in fnmatch () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x5586d79b6a49 in match_wildcard_in_directory 
(path=0x5586d99f4460 "/usr/share/man/man8", pattern=0x5586d99ecea0 
"apt-get.8*", opts=, matched=0x5586d99ea4d0, 
cache=0x5586d99ece80) at ../../../src/globbing.c:273

flags = 16
pattern_start = {pattern = 0x5586d9a1bf60 "apt-get.8", len = 
}

bsearched = 
i = 22
#4  0x5586d79b7042 in look_for_file (hier=hier@entry=0x5586d99f0140 
"/usr/share/man", sec=sec@entry=0x5586d99e7a70 "8", 
unesc_name=unesc_name@entry=0x7ffef1c470b2 "apt-get", 
cat=cat@entry=false, opts=opts@entry=0) at ../../../src/globbing.c:343

dirs_node = 0x1
dirs_iter = {vtable = 0x5586d79cb500 
, list = 0x5586d99f3400, count = 1, p = 
0x5586d99f01e8, q = 0x5586d99f01e8, i = 0, j = 0}

dirs = 0x5586d99f3400
dir = 0x5586d99f4460 "/usr/share/man/man8"
matched = 0x5586d99ea4d0
pattern = 0x5586d99ecea0 "apt-get.8*"
path = 0x0
layout = 1
name = 0x5586d99e7fd0 "apt-get"
__PRETTY_FUNCTION__ = "look_for_file"
MPI_LABEL_4_break_340 = 
#5  0x5586d79ba18c in try_section (cand_head=0x7ffef1c46038, 
name=0x7ffef1c470b2 "apt-get", sec=0x5586d99e7a70 "8", 
path=0x5586d99f0140 "/usr/share/man") at ../../../src/man.c:3172

found = 0
lff_opts = 0
names = 0x0
cat = 0 '\000'
MPI_LABEL_4_break_3197 = 
found_name = 0x5586d99e80c8 " utility -- command-line interface"
found = 
names = 
found_name = 
cat = 
lff_opts = 
MPI_LABEL_1_body_3197 = 
MPI_LABEL_1_done_3197 = 
MPI_LABEL_2_body_3197 = 
MPI_LABEL_2_done_3197 = 
MPI_LABEL_4_body_3197 = 
MPI_LABEL_4_break_3197 = 
MPI_LABEL_4_finish_3197 = 
names_iter = 
names_node = 
info = 
ult = 
f = 
#6  locate_page (candidates=0x7ffef1c46038, name=0x7ffef1c470b2 
"apt-get", sec=0x5586d99e7a70 "8", manpath=0x5586d99f0140 
"/usr/share/man") at ../../../src/man.c:3613

found = 
db_ok = 
found = 
db_ok = 
#7  locate_page_in_manpath (page_section=, 
page_name=page_name@entry=0x7ffef1c470b2 "apt-get", 
candidates=candidates@entry=0x7ffef1c46038, 
found=found@entry=0x7ffef1c460f4) at ../../../src/man.c:3971

manpathlist_node = 0x2
manpathlist_iter = {vtable = 0x5586d79cb500 
, list = 0x5586d99e7e30, count = 2, p = 
0x5586d99f0130, q = 0x5586d99f0130, i = 0, j = 0}

mp = 0x5586d99f0140 "/usr/share/man"
MPI_LABEL_1_done_3970 = 
MPI_LABEL_2_done_3970 = 
MPI_LABEL_4_break_3970 = 
#8  0x5586d79bd29b in man (name=0x7ffef1c470b2 "apt-get", 
found=0x7ffef1c460f4) at ../../../src/man.c:4003

section_list_node = 0x4
section_list_iter = {vtable = 0x5586d79cb500 
, list = 0x5586d99e57a0, count = 17, p = 
0x5586d99e7cd0, q = 0x5586d99e7d38, i = 0, j = 0}

sec = 0x5586d99e7a70 "8"
page_name = 
page_section = 
candidates = 0x0
cand = 
candnext = 
MPI_LABEL_1_done_4002 = 
MPI_LABEL_2_done_4002 = 
MPI_LABEL_4_break_4002 = 
#9  0x5586d79b5786 in main (argc=, argv=out>) at ../../../src/man.c:4385

found_subpage = 
status = 
found = 0
maybe_section = false
nextarg = 0x7ffef1c470b2 "apt-get"
argc_env = 
exit_status = 0
argv_env = 
tmp = 
__PRETTY_FUNCTION__ = "main"
(gdb) info registers
rax0x7f557cc84e98  140005142449816
rbx0x7ffef1c45940  140732954597696
rcx0x7f557cc84e98  140005142449816
rdx0x3048
rsi0x2010201   33620481
rdi0x6197
rbp0x100x10
rsp0x7ffef1c42be8  0x7ffef1c42be8
r8 0x1016
r9 0x0 0
r100x7ffef1c45310  140732954596112
r110x7ffef1c45940  140732954597696
r120x7ffef1c45530  140732954596656
r130x61

Bug#1000113: kodi: depends on obsolete pcre3 library

[Vasyl Gello]

Dear Nicholas,

Yes I definitely see the bug. However, Kodi extensively uses pcrecpp and the 
only replacement I see for pcre2 is jpcre2 [1]
There is an ITP bug about it since 2017 but no package.

Matthew, from your experience, is jpcre2 the only C++ wrapper for pcre2 or 
there is something more recommended / maintainable?
I did the search but found only jpcre2.

[1] https://github.com/jpcre2/jpcre2

-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

Bug#1040452: libc6: upgrading libc6 to version 2.37-3 break almost every program (especially in a shell)

[Kai Wasserbäch]

Package: libc6
Version: 2.37-3
Severity: important

Dear maintainers,
I've just upgraded to libc6 2.37-3 and now I have an almost broken 
system. But broken in a very weird way: the graphical user interface 
(KDE Plasma) is coming up, I can start big programs like Firefox, 
Thunderbird, etc., but as soon as I go to a shell — it doesn't matter if 
I'm inside or outside the graphical session, ie. tty2 vs. tty3 — I can 
execute almost no program. ldd works, surprisingly gdb works as well, 
but eg. man or apt-get or perl do not. They all end with


$ man apt-get
Segmentation fault (core dumped)

Since gdb is working, I got a backtrace, even though that is not that 
helpful, I fear.


$ gdb --args man apt-get
GNU gdb (Debian 13.2-1) 13.2
[...]
Reading symbols from man...
(No debugging symbols found in man)
(gdb) r
Starting program: /usr/bin/man apt-get
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7ffa2b4f8f36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt full
#0  0x7ffa2b4f8f36 in towlower () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7ffa2b4c6d49 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x7ffa2b4c826d in fnmatch () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x561538c0ca49 in ?? ()
No symbol table info available.
#4  0x561538c0d042 in ?? ()
No symbol table info available.
#5  0x561538c1018c in ?? ()
No symbol table info available.
#6  0x561538c1329b in ?? ()
No symbol table info available.
#7  0x561538c0b786 in ?? ()
No symbol table info available.
#8  0x7ffa2b4136ca in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#9  0x7ffa2b413785 in __libc_start_main () from 
/lib/x86_64-linux-gnu/libc.so.6

No symbol table info available.
#10 0x561538c0bca1 in ?? ()
No symbol table info available.
(gdb) info registers
rax0x7ffa2b084e98  140712440516248
rbx0x7ffca64594a0  140723098064032
rcx0x7ffa2b084e98  140712440516248
rdx0x3048
rsi0x2010201   33620481
rdi0x6197
rbp0x100x10
rsp0x7ffca6456748  0x7ffca6456748
r8 0x1016
r9 0x0 0
r100x7ffca6458e70  140723098062448
r110x7ffca64594a0  140723098064032
r120x7ffca6459090  140723098062992
r130x6197
r140x1016
r150x7ffca6459094  140723098062996
rip0x7ffa2b4f8f36  0x7ffa2b4f8f36 
eflags 0x10246 [ PF ZF IF RF ]
cs 0x3351
ss 0x2b43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0

Perl was failing with a call to towupper().

The KDE session is also incomplete, eg. audio devices are no longer found.

During the update I saw errors towards the end (post-install scripts) 
for libc6 (and some others, which should not matter here). Ie. the 
post-install script could not be executed with the core 
dumped/segmentation fault.


It also doesn't matter what shell I use, I've tried bash and dash.

This might be related to #1040140

reportbug is not working either, so you have to do without the 
automatically generated system information, but I do try to reproduce it 
here as close as I can.


Now I will try to downgrade my system and get it fully functional again.

Cheers,
Kai


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 
(2023-06-12) x86_64 GNU/Linux

Locale: LANG=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1040451: schleuder: incompatible with newer ruby-mail

[Gianfranco Costamagna]

Source: schleuder
Version: 4.0.3-9
Severity: serious

Hello, the last ruby-mail upload broke this package autopkgtests, please see 
e.g.
340s GEM_PATH= ruby3.1 -e gem\ \"schleuder\"
340s /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in block 
in activate_dependencies': Could not find 'mail' (~> 2.7.1) among 126 total 
gem(s) (Gem::MissingSpecError)
340s Checked in 
'GEM_PATH=/root/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/arm-linux-gnueabihf/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/arm-linux-gnueabihf/rubygems-integration/3.1.0'
 at: 
/usr/share/rubygems-integration/all/specifications/schleuder-4.0.3.gemspec, 
execute `gem env` for more information
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in `block 
in activate_dependencies'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`block in gem'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
340sfrom -e:1:in `'
340s /usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': Could not 
find 'mail' (~> 2.7.1) - did find: [mail-2.8.1] (Gem::MissingSpecVersionError)
340s Checked in 
'GEM_PATH=/root/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/arm-linux-gnueabihf/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/arm-linux-gnueabihf/rubygems-integration/3.1.0'
 , execute `gem env` for more information
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in `block 
in activate_dependencies'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`block in gem'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
340sfrom /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`gem'
340sfrom -e:1:in `'
340s abbrev (default: 0.1.0)
340s activemodel (6.1.7.3)

Can you please have a look?

thanks

Gianfranco



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040437: zypper: new upstream release

[Mike Gabriel]

Hi Luca,

On  Mi 05 Jul 2023 23:53:54 CEST, Luca Boccassi wrote:


Source: zypper
Version: 1.14.42-2

Dear Maintainer,

I'd like to have the new upstream versions of libsolv/libzypp/zypper in
Debian. I have prepared the updates and tested them, and if there are
no objections I intend to upload to DELAYED/3 tomorrow.
The packages are marked LowNMU but given it's new versions rather than
individual bugfixes I'm opening a bug and using the delayed upload
anyway.

--
Kind regards,
Luca Boccassi


Please go ahead and consider adding yourself as uploader (instead of  
NMUing). Thanks!


Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpcbwLWsBYkl.pgp
Description: Digitale PGP-Signatur

Bug#1040449: bookworm-pu: package smarty4/4.3.0-1+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: smar...@packages.debian.org
Control: affects -1 + src:smarty4

[ Reason ]
Resolve CVE-2023-28447 for smarty4 in bookworm.

[ Impact ]
Closure of vulnerability to execute arbitrary JavaScript code in the
context of the user's browser session.

[ Tests ]
Smoketest on system running GOsa² (smarty4 consumer).

[ Risks ]
Breakage of web packages in Debian that use smarty4.

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

[ Changes ]

+  * debian/patches:
++ Add CVE-2023-28447.patch. Prohibit execution of arbitrary JavaScript code
+  in the context of the user's browser session. (Closes: #1033965,
+  CVE-2023-28447).

[ Other info ]
None.
diff -Nru smarty4-4.3.0/debian/changelog smarty4-4.3.0/debian/changelog
--- smarty4-4.3.0/debian/changelog  2023-01-14 23:22:18.0 +0100
+++ smarty4-4.3.0/debian/changelog  2023-07-06 06:04:52.0 +0200
@@ -1,3 +1,12 @@
+smarty4 (4.3.0-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add CVE-2023-28447.patch. Prohibit execution of arbitrary JavaScript code
+  in the context of the user's browser session. (Closes: #1033965,
+  CVE-2023-28447).
+
+ -- Mike Gabriel   Thu, 06 Jul 2023 06:04:52 +0200
+
 smarty4 (4.3.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru smarty4-4.3.0/debian/patches/CVE-2023-28447.patch 
smarty4-4.3.0/debian/patches/CVE-2023-28447.patch
--- smarty4-4.3.0/debian/patches/CVE-2023-28447.patch   1970-01-01 
01:00:00.0 +0100
+++ smarty4-4.3.0/debian/patches/CVE-2023-28447.patch   2023-07-06 
06:01:34.0 +0200
@@ -0,0 +1,81 @@
+From e75165565e9e5956a73365c24d650ba40570ae72 Mon Sep 17 00:00:00 2001
+From: Simon Wisselink 
+Date: Fri, 24 Mar 2023 12:19:34 +0100
+Subject: [PATCH] Implement fix and tests
+
+---
+ libs/plugins/modifier.escape.php  |  4 +++-
+ libs/plugins/modifiercompiler.escape.php  |  4 +++-
+# .../PluginModifierEscapeTest.php  | 21 +++
+ .../Operators/templates_c/.gitignore  |  2 ++
+ 4 files changed, 29 insertions(+), 2 deletions(-)
+ create mode 100644 
tests/UnitTests/TemplateSource/ValueTests/Operators/templates_c/.gitignore
+
+diff --git a/libs/plugins/modifier.escape.php 
b/libs/plugins/modifier.escape.php
+index 11e44682e..e168679c3 100644
+--- a/libs/plugins/modifier.escape.php
 b/libs/plugins/modifier.escape.php
+@@ -115,7 +115,9 @@ function smarty_modifier_escape($string, $esc_type = 
'html', $char_set = null, $
+ // see 
https://html.spec.whatwg.org/multipage/scripting.html#restrictions-for-contents-of-script-elements
+ 

Bug#1040448: bookworm-pu: package autofs/5.1.8-2+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: aut...@packages.debian.org
Control: affects -1 + src:autofs

[ Reason ]
Fix hang on kerberos authenticated ldap. (See #1039967).

[ Impact ]
Autofs mounts hang autofs obtains its mounting rules from
kerberos-authenticated LDAP.

[ Tests ]
Tested by bug submitter, patch also applied in Ubuntu, no local instance
for fully testing this change, unfortunately. Patch sanctioned by upstream.

Ubuntu maintainer has also provided an autopkgtest rule to check this
issue in CI.
https://salsa.debian.org/debian/autofs/-/merge_requests/4

[ Risks ]
Users with autofs using kerberos-authenticated LDAP might observe regressions.

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

[ Changes ]

+  * debian/patches:
++ Add fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch. Fix missing unlock
+  in sasl_do_kinit_ext_cc(). (Closes: #1039967).

[ Other info ]
None.
diff -Nru autofs-5.1.8/debian/changelog autofs-5.1.8/debian/changelog
--- autofs-5.1.8/debian/changelog   2023-05-19 10:25:31.0 +0200
+++ autofs-5.1.8/debian/changelog   2023-07-05 11:56:29.0 +0200
@@ -1,3 +1,11 @@
+autofs (5.1.8-2+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch. Fix missing unlock
+  in sasl_do_kinit_ext_cc(). (Closes: #1039967).
+
+ -- Mike Gabriel   Wed, 05 Jul 2023 11:56:29 +0200
+
 autofs (5.1.8-2) unstable; urgency=medium
 
   [ Mike Gabriel ]
diff -Nru 
autofs-5.1.8/debian/patches/fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch 
autofs-5.1.8/debian/patches/fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch
--- 
autofs-5.1.8/debian/patches/fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch
1970-01-01 01:00:00.0 +0100
+++ 
autofs-5.1.8/debian/patches/fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch
2023-07-05 11:56:18.0 +0200
@@ -0,0 +1,45 @@
+From b2571ed0df973a6dc6a8e661874655fa7cecdc37 Mon Sep 17 00:00:00 2001
+From: James Dingwall 
+Date: Wed, 20 Jul 2022 13:22:38 +0800
+Subject: autofs-5.1.8 - fix missing unlock in sasl_do_kinit_ext_cc()
+
+There is a missing mutex unlock in function sasl_do_kinit_ext_cc(),
+fix it.
+
+Signed-off-by: James Dingwall 
+Signed-off-by: Ian Kent 
+---
+# CHANGELOG| 1 +
+ modules/cyrus-sasl.c | 4 
+ 2 files changed, 5 insertions(+)
+
+#diff --git a/CHANGELOG b/CHANGELOG
+#index 1f7c93a..e0b285d 100644
+#--- a/CHANGELOG
+#+++ b/CHANGELOG
+#@@ -27,6 +27,7 @@
+# - add autofs_strerror_r() helper for musl.
+# - update configure.
+# - handle innetgr() not present in musl.
+#+- fix missing unlock in sasl_do_kinit_ext_cc().
+# 
+# 19/10/2021 autofs-5.1.8
+# - add xdr_exports().
+diff --git a/modules/cyrus-sasl.c b/modules/cyrus-sasl.c
+index ae046e0..738e363 100644
+--- a/modules/cyrus-sasl.c
 b/modules/cyrus-sasl.c
+@@ -721,6 +721,10 @@ sasl_do_kinit_ext_cc(unsigned logopt, struct 
lookup_context *ctxt)
+ 
+   debug(logopt, "Kerberos authentication was successful!");
+ 
++  status = pthread_mutex_unlock(_mutex);
++  if (status)
++  fatal(status);
++
+   return 0;
+ 
+ out_cleanup_def_princ:
+-- 
+cgit 
+
diff -Nru autofs-5.1.8/debian/patches/series autofs-5.1.8/debian/patches/series
--- autofs-5.1.8/debian/patches/series  2023-05-19 10:20:51.0 +0200
+++ autofs-5.1.8/debian/patches/series  2023-07-05 11:56:18.0 +0200
@@ -10,3 +10,4 @@
 fix-lookup-ldap-crash.patch
 fix-nfs4-mounts-in-auto-net.patch
 fix-nfs4-only-mounts-should-not-use-rpcbind.patch
+fix-missing-unlock-in-sasl-do-kinit-ext-cc.patch

Bug#1040411: cloudpickle: implicitly depends on python3-py

[Diane Trout]

Thanks for the heads up.

It should be fixed now

On Wed, 2023-07-05 at 18:33 +0200, Timo Röhling wrote:
> Source: cloudpickle
> Version: 2.2.0-1
> Severity: serious
> 
> Dear maintainer,
> 
> your package implicitly depends on python3-py for its autopkgtest,
> which used
> to be provided by python3-pytest. However, pytest has dropped that
> dependency,
> breaking your autopkgtest and possibly your package.
> 
> 
> Cheers
> Timo
> 
> Relevant excerpt from
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cloudpickle/35335619/log.gz
> 
>  57s === FAILURES
> ===
>  57s __ CloudPickleTest.test_dynamic_pytest_module
> __
>  57s 
>  57s self =  testMethod=test_dynamic_pytest_module>
>  57s 
>  57s def test_dynamic_pytest_module(self):
>  57s # Test case for pull request
> https://github.com/cloudpipe/cloudpickle/pull/116
>  57s import py
>  57s 
>  57s def f():
>  57s s = py.builtin.set([1])
>  57s return s.pop()
>  57s 
>  57s # some setup is required to allow pytest apimodules to
> be correctly
>  57s # serializable.
>  57s from cloudpickle import CloudPickler
>  57s from cloudpickle import cloudpickle_fast as cp_fast
>  57s >   CloudPickler.dispatch_table[type(py.builtin)] =
> cp_fast._module_reduce
>  57s E   AttributeError: module 'py' has no attribute 'builtin'
>  57s 
>  57s tests/cloudpickle_test.py:1511: AttributeError
>  57s _
> Protocol2CloudPickleTest.test_dynamic_pytest_module __
>  57s 
>  57s self =  testMethod=test_dynamic_pytest_module>
>  57s 
>  57s def test_dynamic_pytest_module(self):
>  57s # Test case for pull request
> https://github.com/cloudpipe/cloudpickle/pull/116
>  57s import py
>  57s 
>  57s def f():
>  57s s = py.builtin.set([1])
>  57s return s.pop()
>  57s 
>  57s # some setup is required to allow pytest apimodules to
> be correctly
>  57s # serializable.
>  57s from cloudpickle import CloudPickler
>  57s from cloudpickle import cloudpickle_fast as cp_fast
>  57s >   CloudPickler.dispatch_table[type(py.builtin)] =
> cp_fast._module_reduce
>  57s E   AttributeError: module 'py' has no attribute 'builtin'
>  57s 
>  57s tests/cloudpickle_test.py:1511: AttributeError
> 
> 
> 



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

Bug#1038203: iptables-netflow-dkms: module fails to build for Linux 6.4: error: implicit declaration of function 'register_sysctl_paths'

[Axel Beckert]

Control: forwarded -1 https://github.com/aabc/ipt-netflow/issues/220

Hi Andreas,

Andreas Beckmann wrote:
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function 
> 'ipt_netflow_init':
> /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:5688:33: error: implicit 
> declaration of function 'register_sysctl_paths'; did you mean 
> 'register_sysctl_table'? [-Werror=implicit-function-declaration]
>  5688 | netflow_sysctl_header = 
> register_sysctl_paths(netflow_sysctl_path, netflow_sysctl_table);

register_sysctl_paths has been removed from the kernel:
https://github.com/torvalds/linux/commit/0199849acd07d07e2a8e42757653ca8b14a122f5

Based on
https://github.com/kalamlacki/ipt-netflow/commit/2a1d250a701405b81fdf3548b4b9c12bf266a306
and
https://github.com/kalamlacki/ipt-netflow/commit/373b58781a0fc99fcb354ea3b5e4f3a006a71ab6
I've created a patch which does not hardcode the new variant but which
is backwards compatible. Will push and upload soon.

Thanks for the bug report.

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#894013: iptables -> nftables

[Aleksi Suhonen]

Hi,

Some water has passed under the bridge, and I feel the whole thing 
should be rewritten as nftables rules instead of iptables rules now.


As a bonus, we could combine filters for mac spoofing and ip spoofing in 
one neat package.


--
Aleksi Suhonen / TREX Regional Exchanges Oy

`What I need,' shouted Ford, by way of clarifying his
previous remarks, `is a strong drink and a peer-group.'
   -- Douglas Adams, Life the Universe and Everything

Bug#1032834: freecad: Segmentation fault while redoing

[Petter Reinholdtsen]

Is there any chance you can recreate the crash with debug symbols
installed using valgrind?  It would provide more information about
exactly why it crashes.

-- 
Happy hacking
Petter Reinholdtsen

Bug#860789: freecad: import of openscad file turns "differences" into "unions"

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/FreeCAD/FreeCAD/issues/9877

I created a github issue for the problem, and tracked down that the fix
for it is already upstream, and should show up in version 0.21 of
FreeCAD.

The github issue got links to the fixes and test case, if someone want
to backport a fix for this.  I do not see the point myself, as it is
trivial to remove the problematic 'union();' parts from a OpenSCAD file.

-- 
Happy hacking
Petter Reinholdtsen

Bug#923908: new upstream version available (9.2)

[Antoine Beaupré]

On 2023-07-05 18:04:46, Nicholas D. Steeves wrote:

[...]

> Bastien  writes:
>
>> Hi all,
>>
>> I'm not sure if this is the right place to announce this, but here it
>> goes: Org 9.4 is out.
>
> That's a good question!  Yes, I believe that filing a "new upstream
> version" bug is likely to reduce the latency between when you release,
> and when this release is imported into Debian.  With a Debian system,
> this is achieved with the following command:
>
>   reportbug org-mode

I do not believe it is necessary to open a new "new upstream release"
bug report, we have this one, it can just be retitled.

a.
-- 
L'adversaire d'une vraie liberté est un désir excessif de sécurité.
- Jean de la Fontaine

Bug#1040380: ITP: spike -- Spike RISC-V ISA Simulator

[Jax Young]

On Thurs, Jul 06, 2023 at 07:33, Jessica Clarke  wrote:

> > I disagree. Spike exists to be an easy simulator for people extending

> > the RISC-V ISA to hack on, and to give software developers something to

> > start testing their code on as extensions are in-flight (both of which

> > are also served by the Sail model, which is technically the official

> > golden model, even if many still prefer to use Spike). However, if

> > you're not using the latest version, any draft extension specifications

> > implemented by it have likely moved on in the meantime to newer

> > incompatible drafts, rendering them obsolete, and any frozen (or even

> > ratified) specifications are likely to be implemented by QEMU. Plus QEMU

> > will be much, much faster thanks to its JIT approach, and has a rich set

> > of devices available, unlike Spike which has just a UART last I checked,

> > not even any form of storage, meaning it can only run basic binaries or

> > boot kernels with an in-memory filesystem.

> >

> > I therefore do not see any point in shipping some old version of Spike
> in Debian. What is your use case for having it?

I just want to provide a way to get pre-built Spike for people who may
need that. As you say, it's useless for people who need hacking Spike.
Also for people who just want to run RISC-V binary. I will use a unofficial
way like PPA for this. So you can close this bug.

Thanks for your explanation. Sorry for bothering.

Bug#1025268: Should mozjs102 in bookworm use the system icu?

[Jeremy Bícha]

On Thu, 01 Dec 2022 at 20:38:26 +0200, Adrian Bunk wrote:
> The system icu 72 is no longer older than the icu 71 vendored
> in mozjs102, should mozjs102 in bookworm use the system icu?

I guess we can close this bug now?

Thank you,
Jeremy Bicha

Bug#1040447: odbc-mariadb cannot set up odcb-mariadb

[John Covici]

Package: odbc-mariadb
Version: 3.1.15-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation? upgraded from bullseye
   * What exactly did you do (or not do) that was effective (or
 ineffective)? tried to install the package during the upgrade 
   * What was the outcome of this action? Got the following error:
   * odbcinst: SQLInstallDriverEx failed with Unable to find component name.
   * What outcome did you expect instead?odbc-mariadb to properly install



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

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

Versions of packages odbc-mariadb depends on:
ii  libc6 2.36-9
ii  libmariadb3   1:10.11.3-1
ii  libodbcinst2  2.3.11-2+deb12u1
ii  odbcinst  2.3.11-2+deb12u1

odbc-mariadb recommends no packages.

odbc-mariadb suggests no packages.

-- no debconf information

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Bug#1040446: nut-server: failed after upgrade - upscode2: Missing UPCL after UPCL error

[Karl Schmidt]

Package: nut-server
Version: 2.7.4-13
Severity: normal

Upgrade to bookworm broke things with the new nut-server pkg

The error is misleading - it has to do with some debug code. 

Some details on the mailing list at:
https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-July/013366.html

The jist of it - the driver upscode2 works with debug=3 - but not without - some
bug was just fixed that probably cures this according to the mailing list.

I didn't sucseed in creating a new pkg from the github sources so I downgraded 
to the 
old version to keep things working.

There is a new version upstream - would love to test it once in a deb package.


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

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

Versions of packages nut-server depends on:
ii  adduser3.134
ii  init-system-helpers1.65.2
ii  libc6  2.36-9
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libnutscan12.7.4-13
ii  libupsclient4  2.7.4-13
ii  libusb-0.1-4   2:0.1.12-32
ii  libwrap0   7.6.q-32
ii  lsb-base   11.6
hi  nut-client 2.7.4-13
ii  sysvinit-utils [lsb-base]  3.06-4
ii  udev   252.11-1

nut-server recommends no packages.

Versions of packages nut-server suggests:
pn  nut-cgi   
pn  nut-ipmi  
pn  nut-snmp  
pn  nut-xml   

-- Configuration Files:
/etc/nut/ups.conf changed:
[malaysia]
driver = upscode2
port = /dev/ttyUSB0
desc = "NetUPS SE"

/etc/nut/upsd.conf changed:
LISTEN 127.0.0.1 3493

/etc/nut/upsd.users changed:
[root]
password = ups
instcmds = ALL
actions = SET FSD

[monuser]
password  = ups
upsmon master



-- no debconf information

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Alexandru,

Alexandru Mihail  writes:

> After yet some more software archaeology, I've uncovered some more
> rusty HTML 1.0 documents which are of interest to our dilemma.
> Apparently, NCSA HTTPd Acknowledgements as of 7-14-95 state:
> "Thanks to:
> Robert McCool
> For developing NCSA HTTPd till version 1.3 and this documentation."
>
> https://web.archive.org/web/20090416132804/http://hoohoo.ncsa.uiuc.edu/docs/acknowledgement.html
>
> This is the time Robert left the project and the date (and license
> release - 1.3) probably aligns best with the code we have in mini-
> httpd. After extensive googling, it seems to me that the original mini-
> httpd-1.0.0.tar.gz source is lost to time, or at least is buried beyond
> my reach.

That's ok, you don't need to find the original version.  Remember that
it's a fork and child relationship, so anyone, today, can fork httpd
(1.1-1.3, 1.4-1.14, 1.15, etc.) under the license terms specific to a
particular release.  So, for a hypothetical case where the file[s] in
question are identical for the following versions ..:

  1.1-1.3: "Do what you want but only on continental landmasses" license
  || \\
  ||  \=Possible fork point.  If discriminating against islanders
  ||is important, then fork from this point.
  \/
  1.4-1.14: "Non-commercial use only, except for fishermen" license
  || \\
  ||  \=Possible fork point.  If privileging fishermen and 
  ||discriminate against everyone else is important, then fork
  ||from this point.
  \/
  1.15: GPL3+
 \\
  \=Possible fork point.  Only discriminates against those who
wish to keep their source private while also distributing their
fork.  Fork from this point if that's important.

...then if httpd 1.15 is older then mini-httpd 1.30, you must choose
1.15.  Meanwhile, Robert McCool's copyright still exists in 1.15 even if
he hasn't made a contribution since 1.3.

P.S. Please acknowledge: Have you read the DFSG yet, and do you
understand why it's important?
https://wiki.debian.org/DebianFreeSoftwareGuidelines

> I transitioned all debian mail-related services to Google, and am using
> a good MUA now (PGP signing properly). (BTW, does everything look all
> right on your end?)

I confirm receipt of your mail, and I see an attached signature.  Where
can I download your public key?

> I've committed to salsa and uploaded to mentors a new .changes which
> reflects the change in Maintainer's E-Mail. Naturally, I changed the
> key and updated the changelog.

Thanks!  

> Thanks and have a great day/night !

You too! :)


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1040443: wajig crashes on listhold

[Karl Schmidt]

Package: wajig
Version: 4.0.3
Severity: normal


# wajig listhold
Traceback (most recent call last):
  File "/usr/bin/wajig", line 33, in 
 sys.exit(load_entry_point('wajig==4.0.3', 'console_scripts', 'wajig')())
   ^^
  File "/usr/lib/python3/dist-packages/wajig/__init__.py", line 1209, in 
main
 result.func(result)
File "/usr/lib/python3/dist-packages/wajig/commands.py", line 632, in 
listhold
  perform.execute("dpkg --get-selections | grep -E 'hold$' | cut -f1", 
teach=args.teach, noop=args.noop)

^^
  AttributeError: 'Namespace' object has no attribute 'teach'


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

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

Versions of packages wajig depends on:
ii  apt  2.6.1
ii  aptitude 0.8.13-5
ii  dpkg 1.21.22
ii  python3  3.11.2-1+b1
ii  python3-apt  2.6.0
ii  python3-distro   1.8.0-1
ii  python3-fuzzywuzzy   0.18.0-4
ii  python3-levenshtein  0.12.2-2+b4

wajig recommends no packages.

Versions of packages wajig suggests:
ii  alien  8.95.6
ii  apt-file   3.3
ii  apt-move   4.2.27-6
ii  apt-show-versions  0.22.13+nmu1
pn  chkconfig  
ii  dctrl-tools2.24-3+b1
ii  debconf1.5.82
ii  deborphan  1.7.35
ii  debsums3.0.2.1
ii  debtags2.1.5
ii  dpkg-dev   1.21.22
ii  dpkg-repack1.52
ii  fakeroot   1.31-1.2
ii  locales2.36-9
ii  netselect-apt  0.3.ds1-30.1
ii  reportbug  12.0.0
ii  sudo   1.9.13p3-1
ii  vrms   1.33

-- no debconf information

Bug#1038882: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Santiago Ruano Rincón]

El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> >  wrote:
> > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > Greetings,
> > > >
> > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > > > good time to re-visit Debian's choice of standard DHCP client shipping
> > > > with priority:important.
> > > >
> > > > I hereby propose bin:dhcpcd-base:
> > > >
> > > > 1) already supported by ifupdown.
> > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege 
> > > > separation.
> > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > > configure both stacks.
> > > ...
> > >
> > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for
> > > the moment, and I'll make the relevant changes in ifupdown as soon as I
> > > can. Josué, any thoughts?
> > 
> > 1) As someone pointed out in the thread, the reason why
> > isc-dhcp-client had priority:important probably was to ensure that
> > debootstrap would pull it, since debootstrap ignores Recommends and
> > packages with a priority lower than standard.
> > 
> > 2) However, as long as ifupdown explictly depends on a package, it can
> > also pull dependencies with a lower priority. Right now ifupdown
> > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would
> > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead.
> > 
> > 3) At that point, swapping the priority of isc-dhcp-client and
> > dhcpcd-base merely becomes "nice to have". Heck, the priority of both
> > could, in principle, be optional, just as long as ifupdown explicitly
> > Depends on a DHCP client, and the first alternative is a real package.
> 
> I was about to bump dhcpcd-base as ifupdown dependency, but... if
> isc-client-dhcp is a Recommends, is because not all users want a dhcp
> client installed, where all the ipv4 is handled statically, and ipv6 is
> done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the
> next upgrade.
> 
> So I'd prefer to go forward with the steps proposed by Simon, and
> s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends:
> Unless there is a strong objection, I'll file the override bug report.

(sorry for taking so long to come back to this)

For the moment, ifupdown is still installed by the debian-installer as
default network interfaces manager. And after sleeping over it, and
discussing with debian fellows, I would like to call for consensus to
rise Priority: Important to dhcpcd-base (as initially requested in
#1038882), and switch to Recommends: dhcpcd-base | dhcp-client.

This addresses two scenarios: keep some systems as small as possible
(ifupdown users can remove dhcpcd if they want) and having a useful dhcp
client available after installing/bootstrapping.

So I would like to retitle #1038882 back as originally reported. (Sorry
for going back and forth) Objections?

The situation regarding the default network interfaces manager could
change, even in the short term. But that could be discussed in another
thread.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1040380: ITP: spike -- Spike RISC-V ISA Simulator

[Jessica Clarke]

On Wed, Jul 05, 2023 at 05:17:29PM +0800, Jax Young wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jax Young 
> X-Debbugs-Cc: debian-de...@lists.debian.org, jaxvany...@gmail.com
>
> * Package name: spike
>   Version : 1.1.0
>   Upstream Author : Andrew Waterman 
> * URL : https://github.com/riscv-software-src/riscv-isa-sim
> * License : Custom license
>   Programming Lang: C, C++
>   Description : Spike RISC-V ISA Simulator
>
> Spike has been published for several years, with the development of
> RISC-V, I think it should be included in Debian packages.
>  - Spike is developed by the official RISC-V organization. It is a good
>reference for RISC-V ISA Simulator, and it has 1.8K stars on GitHub.
>  - QEMU also supports RISC-V ISA simulation, but it acts more for
>virtual environment. Spike focus on RISC-V, and it is more for
>developing.
>  - I am new to package maintenance, so I need a sponsor. Spike's API is
>fairly stable, the last version was released on Dec 17, 2021. But the
>development is still ongoing. So the maintenance should be easy for a
>noob like me.
>

I disagree. Spike exists to be an easy simulator for people extending
the RISC-V ISA to hack on, and to give software developers something to
start testing their code on as extensions are in-flight (both of which
are also served by the Sail model, which is technically the official
golden model, even if many still prefer to use Spike). However, if
you're not using the latest version, any draft extension specifications
implemented by it have likely moved on in the meantime to newer
incompatible drafts, rendering them obsolete, and any frozen (or even
ratified) specifications are likely to be implemented by QEMU. Plus QEMU
will be much, much faster thanks to its JIT approach, and has a rich set
of devices available, unlike Spike which has just a UART last I checked,
not even any form of storage, meaning it can only run basic binaries or
boot kernels with an in-memory filesystem.

I therefore do not see any point in shipping some old version of Spike
in Debian. What is your use case for having it?

Jess

Bug#1000113: kodi: depends on obsolete pcre3 library

[Nicholas D Steeves]

Dear Vasyl,

Have you seen this RC bug yet?

On Thu, 18 Nov 2021 11:49:04 + Matthew Vernon  wrote:
> Source: kodi
> Severity: important
> User: matthew-pcre...@debian.org
> Usertags: obsolete-pcre3
> 
> Dear maintainer,
> 
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the release of Bookworm.
> 
> The newer PCRE2 library was first released in 2015, and has been in
> Debian since stretch. Upstream's documentation for PCRE2 is available
> here: https://pcre.org/current/doc/html/
> 
> Many large projects that use PCRE have made the switch now (e.g. git,
> php); it does involve some work, but we are now at the stage where
> PCRE3 should not be used, particularly if it might ever be exposed to
> untrusted input.
> 
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00176.html
> 
> Regards,
> 
> Matthew [0] Historical reasons mean that old PCRE is packaged as
> pcre3 in Debian 

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1040442: RM: goldendict-ng [mips64el mipsel] -- ANAIS; Architecture unsupported by build-dep

[Boyuan Yang]

Package: ftp.debian.org
Control: affects -1 + src:goldendict-ng
X-Debbugs-Cc: goldendict...@packages.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: by...@debian.org
Severity: normal

Dear Debian FTP Masters,

Please remove binary package goldendict-ng on mips64el and mipsel.

With package goldendict-ng now being built using Qt6, its
build-dependencies do not support mips64el and mipsel.
The old binary packages will need to get removed in order
for the current goldendict-ng to migrate to Debian Testing.

Thanks,
Boyuan Yang


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

Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here

[Nicholas D Steeves]

Hi Max,

Max Nikulin  writes:

> Thank you for fixing of the https://bugs.debian.org/1035650 bug that was 
> a duplicate of this one. I am glad to see that a dummy elpa-org package 
> has been landed to bookworm.
>
> Have you decided to keep this issue open to package Org-9.6 and to 
> implement emacs-pkg-* provides or it was just forgotten in the changelog 
> message and it should be closed?

Fixed in experimental, and the bug will be closed when an updated
version of org-mode is uploaded to unstable.  At this time, "and to
implement emacs-pkg-* provides" is not part of importing a new upstream
release of Org.

As for all the other ideas about how things can be done better?  Debian
is a do-ocracy.  Anyone who cares enough to invest their time to
maintain a solution in the long-term is welcome to upgrade the status
quo :)  "long-term" is key, because a drive-by set of changes that makes
things maintenance more labour-intensive is unlikely to be seen in a
favourable light.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.

[Nicholas D Steeves]

Hi H.-Dirk, and anyone else reading this,

I just found this draft from 3 June, and am sending it now:

"H.-Dirk Schmitt"  writes:

> For myself I have deinstalled elpa-org for the moment.

That makes sense.  There's a parallel discussion at #1035650, btw, and
the current package in both sid and testing [now bookworm/stable]
has no lisp files.

> But this mitigation – or the suggested changing of the load-path –
> introducing unnecessary modifications, which will – Murphy's Law – become 
> persistent.
>
> A „clean solution“ should avoid duplicated distribution of the same 
> functionality – especially if one „shadows“ the other.

Can upstream be convinced of this „clean solution“?  If so, then Debian
would inherit it; however, I suspect they'll reply with something like the
following:

  -- Why?  Emacs with bundled org-mode works fine with org-mode
 installed from GNU ELPA.  Also, Emacs is, by-design a distribution
 of various useful libraries.

> I suggest strongly to drop the duplicated parts from the main emacs-el and 
> either only distribute as 'elpa' or move to distinct packages setting 
> conflicts against the elpa version (and vice versa!) .

Sorry, I don't understand what you mean by "or move to distinct
packages".  I'll discuss the Breaks Provides case below.

> The problem of the duplicated 'elpa-org' distribution applies also to – on my 
> system – to 'elpa-seq' and 'elpa-let-alist'.

Duplication is arguably an aesthetic concern; however, I agree with you
100% that it's a serious problem when an older version of elpa-foo
functionally shadows the Emacs built-in version.  That said, aesthetic
concerns have value--sometimes great value.  Is this an important enough
issue to you that you're willing to invest a significant amount of time
into continuously unbundling (within a Debian context) anything that is
added to Emacs, for the foreseeable future?  You'd also need to convince
the other Debian Emacs maintainers of why this is important.

There are a couple of alternative solutions that I think ought to be
discussed.  For example a script that parses our Emacs' built-in
version, and that files release critical bugs against an elpa-foo
package when it's older than the Emacs built-in version.

If a package hasn't been updated between the point when Emacs is
uploaded to Debian (before the freeze) and the point in the freeze that
"no rentry into testing" becomes enforced, then I think it's fair to say
that the package may be so insufficiently maintained that it shouldn't
be part of the upcoming release.

It's also worth considering whether this can be solved using Debian
dependencies, without making disruptive unbundling changes.  Ie emacs-el
would declare breaks against things like elpa-org (<< x.y.z).  In this
case, it would need a "Provides: elpa-org (x.y.z)" to not break packages
that have a hard dependency on elpa-org.  I don't think it would be safe
to use unversioned Provides.  A script to maintain these would need to
be written and integrated into src:emacs's build process, and the parser
for this would necessarily be similar to the RC bug filing one; It seems
like there is an opportunity for code reuse here.  I wonder if having a
package with a huge list of Breaks and Provides would reveal
corner-case bugs in things like aptitude?

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#979337: pinball-table-gnu: Please confirm if bug is still present

[Philippe Coval]

Please confirm if bug is still present on current release:

https://tracker.debian.org/news/1440698/accepted-pinball-table-gnu-0020230219-1-source-into-unstable/

Regards

Bug#1040144: Bisect ongoing

[Jérôme]

Narrowing down the issue... It seems the first 6.x version work fine.

KO
--

6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2~bpo11+1
(2023-04-23) x86_64 GNU/Linux


OK
--

6.0.0-trunk-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0-1~exp1
(2022-10-09) x86_64 GNU/Linux

-- 
Jérôme

Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package

[Nicholas D Steeves]

Hi Dhavan,

I'm forwarding this to your new email address, so there will be a record
about how to contact you:

Nicholas D Steeves  writes:

> Source: modus-themes
> Version: 1.0.2-1
> Severity: normal
> X-Debbugs-Cc: Dhavan Vaidya 
>
> Hi Dhavan,
>
> I hope this email finds you in good health.  Are you still interested
> in maintaining modus-themes?  The repository hasn't seen any activity
> since 2021, the current stable upstream version is now 4.2.0, and this
> makes it look like the package is effectively unmaintained.

Please note that modus-themes is currently a salvaging candidate:

  https://wiki.debian.org/PackageSalvaging

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1040441: adduser: [INTL:pt] Updated Portuguese translation - PROGRAM messages

[Américo Monteiro]

Package: adduser
Version: 3.137
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for  adduser's messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


adduser_3.137_pt.po.gz
Description: application/gzip

Bug#1037135: please update to latest upstream version and confirm intent to maintain package

[Nicholas D Steeves]

Nicholas D Steeves  writes:

> Source: modus-themes
> Version: 1.0.2-1
> Severity: normal
> X-Debbugs-Cc: Dhavan Vaidya 
>
> Hi Dhavan,
>
> I hope this email finds you in good health.  Are you still interested
> in maintaining modus-themes?  The repository hasn't seen any activity
> since 2021, the current stable upstream version is now 4.2.0, and this
> makes it look like the package is effectively unmaintained.
>
> Regards,
> Nicholas

Bug#1040440: groff: new upstream version 1.23.0 available

[G. Branden Robinson]

Package: groff
Version: 1.22.4-10
Severity: normal

[Bertrand has tagged and uploaded groff 1.23.0 as of an hour or so ago,
and reported it to the groff development list, but not as of this
writing, yet announced it to info-gnu.  I'm filing this report on my own
initiative as an impatient Debian-using jerk.]  The following text is an
announcement based on the "ANNOUNCE" file in groff's Git repository but
will only resemble, and not be identical to, Bertrand's official
announcement.]

We are pleased to announce the availability of groff 1.23.0.  Obtain it
from the GNU mirror network,

  https://ftpmirror.gnu.org/groff/groff-1.23.0.tar.gz

or, if the network is for some reason inoperative, directly from GNU.

  https://ftp.gnu.org/gnu/groff/groff-1.23.0.tar.gz

Ensure the integrity of your download by checking this source code
archive's cryptographic signature; see "Obtaining groff" below.

What is groff?
==

groff (GNU roff) is a typesetting system that reads plain text input
files that include formatting commands to produce output in PostScript,
PDF, HTML, or DVI formats or for display to a terminal.  Formatting
commands can be low-level typesetting primitives, macros from a
supplied package, or user-defined macros.  All three approaches can be
combined.

A reimplementation and extension of the typesetter from AT Unix, groff
is present on most POSIX systems owing to its long association with Unix
manuals (including man pages).  It and its predecessor are notable for
their production of several best-selling software engineering texts.
groff is capable of producing typographically sophisticated documents
while consuming minimal system resources.

  https://www.gnu.org/software/groff/

Changes
===

Changes since the most recent release candidate, 1.23.0.rc4, comprise
about 200 commits' worth of changes to documentation, including over
1,000 lines of updates to each of doc/groff.texi (our Texinfo manual)
and the man pages groff_mm(7) and eqn(1).

Since groff 1.22.4 was released in December 2018, 28 people have made a
total of over 4,500 commits.

$ git shortlog --summary 1.22.4..1.23.0
14  Bertrand Garrigues
14  Bjarni Ingi Gislason
 2  Bruno Haible
 6  Colin Watson
 1  Cynthia A. E. Livingston
 1  Damian McGuckin
31  Dave Kemper
29  Deri James
 2  Dorai Sitaram
 1  Edmond Orignac
 1  Eric Allman
  4778  G. Branden Robinson
 1  George HELFFRICH
33  Ingo Schwarze
 1  John Gardner
 4  Keith Bostic
25  Keith Marshall
 2  Michael J. Karels
 1  Nate Bargmann
 3  Nikita Ivanov
 1  Paul Eggert
71  Peter Schaffter
 1  Samanta Navarro
 1  T. Kurt Bond
 3  Tadziu Hoffmann
 1  Thomas Dupond
 2  ivan tkachenko
 1  наб

(Some possibly surprising names in the above are due to a rebase of
groff me(7) against 4.4BSD.)

Headline features nominated by our development community include:
  * a new 'man' macro, "MR", for formatting man page cross references;
  * hyperlinked text in terminals via the ECMA-48 OSC 8 escape sequence;
  * a new 'rfc1345' macro package, contributed by Dorai Sitaram,
enabling use of RFC 1345 mnemonics as groff special characters;
  * a new 'sboxes' macro package, contributed by Deri James, enabling
'ms' documents to place shaded and/or bordered rectangles underneath
any groff page elements (PDF output only);
  * 'mom' 2.5, a macro package contributed by Peter Schaffter;
  * the 'ms' package's new strings to assist subscripting;
  * Italian localization, including hyphenation patterns and macro
package string translations, thanks to Edmond Orignac; and
  * new hyphenation patterns for English.

For more on these and other feature changes, see "News" below.

Much attention has been given to fixing bugs, improving diagnostic
messages, and correcting and expanding documentation.  The previous
release shipped with three automated unit tests; this one ships with
over 160 unit and regression tests.

As of this writing, per the GNU Savannah bug tracker, the groff project
has resolved 431 problems as fixed for the 1.23.0 release.  Some of the
bugs we've corrected were over 30 years old.

Classifying these issues by type and the component of the project to
which they apply, we find the following.

  Type  Component
    -
  Build/installation   39   Core  102
  Crash/unresponsive   11   Driver: grohtml 7
  Documentation   111   Driver: gropdf 10
  Feature change   41   Driver: grops   2
  Incorrect behavior  131   Driver: grotty  4
  Lint 15   Driver: others/general  7
  Rendering/cosmetics  10   Font: devpdf1
  Test  6   Font: devps 3
  Warning/suspicious behavior  67   

Bug#1040435: Unstable fix uploaded

[Scott Kitterman]

Fix is now also uploaded to Unstable.

Scott K

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

Bug#1040439: sudo: /etc/sudoers.d/README contains nonsensical text

[patricia]

Package: sudo
Version: 1.9.13p3-1
Severity: normal

Dear Maintainer,

The file /etc/sudoers.d/README contains the following block of text:

# Note also, that because sudoers contents can vary widely, no attempt is
# made to add this directive to existing sudoers files on upgrade.  Feel free
# to add the above directive to the end of your /etc/sudoers file to enable
# this functionality for existing installations if you wish! Sudo
# versions older than the one in Debian 11 (bullseye) require the
# directive will only support the old syntax #includedir, and the current
# sudo will happily accept both @includedir and #includedir

Notice the last sentence:
"Sudo versions older than the one in Debian 11 (bullseye) require the directive 
will only support the old syntax #includedir, and the current sudo will happily 
accept both @includedir and #includedir"

has very broken english. Please fix and release the fix into bookworm because 
documentation should be clear.


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

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

Versions of packages sudo depends on:
ii  init-system-helpers  1.65.2
ii  libaudit11:3.0.9-1
ii  libc62.36-9
ii  libpam-modules   1.5.2-6
ii  libpam0g 1.5.2-6
ii  libselinux1  3.4-1+b6
ii  zlib1g   1:1.2.13.dfsg-1

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

Bug#1036350: I intend to adopt the gcc-msp430

[Thiago Marques]

retitle 1036350 ITA: gcc-msp430 -- GNU C compiler (cross compiler for MSP430)


Hi,
I saw that the package is orphan, I'd like to adopt.
Regards,


--
*   Thiago Marques.*

Bug#1036349: I intend to adopt the gdb-msp430

[Thiago Marques]

retitle 1036349 ITA: gdb-msp430 -- The GNU debugger for MSP430


Hi,
I saw that the package is orphan, I'd like to adopt.
Regards,


--
*   Thiago Marques.*

Bug#1040438: libmail-dkim-perl: missing dependency on libgetopt-long-descriptive-perl

[Colin Watson]

Package: libmail-dkim-perl
Version: 1.20230212-1
Severity: serious
Justification: Policy 3.5

  $ dkimproxy-verify
  Can't locate Getopt/Long/Descriptive.pm in @INC (you may need to install the 
Getopt::Long::Descriptive module) (@INC contains: /etc/perl 
/usr/local/lib/x86_64-linux-gnu/perl/5.36.0 /usr/local/share/perl/5.36.0 
/usr/lib/x86_64-linux-gnu/perl5/5.36 /usr/share/perl5 
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.36 
/usr/share/perl/5.36 /usr/local/lib/site_perl) at /usr/bin/dkimproxy-verify 
line 13.
  BEGIN failed--compilation aborted at /usr/bin/dkimproxy-verify line 13.

Installing libgetopt-long-descriptive-perl fixes it, but this should
clearly be in Depends.

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

Kernel: Linux 6.1.0-8-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 libmail-dkim-perl depends on:
ii  libcrypt-openssl-rsa-perl   0.33-3+b1
ii  liberror-perl   0.17029-2
ii  libmail-authenticationresults-perl  2.20230112-1
ii  libmailtools-perl   2.21-2
ii  libnet-dns-perl 1.36-1
ii  perl [libdigest-sha-perl]   5.36.0-7

libmail-dkim-perl recommends no packages.

libmail-dkim-perl suggests no packages.

-- no debconf information

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#923908: new upstream version available (9.2)

[Nicholas D Steeves]

Hi Bastien,

Reply follows inline.

Bastien  writes:

> Hi all,
>
> I'm not sure if this is the right place to announce this, but here it
> goes: Org 9.4 is out.

That's a good question!  Yes, I believe that filing a "new upstream
version" bug is likely to reduce the latency between when you release,
and when this release is imported into Debian.  With a Debian system,
this is achieved with the following command:

  reportbug org-mode

> We plan to remove the contrib/ directory from org-mode.git for either
> Org 9.5 or Org 9.6.
>
> We will provide another way to install contribs, surely as a Org ELPA
> package.  I will let you know the details.

Thank you for the notification, and sorry for the unfortunate state of
Org mode in Debian 12 (bookworm).  A variety of factors intersected to
generate this outcome, and I wish we, as a team, had been able to do
better.

As for dependency packages that ensure a smooth transition: For Debian
12 (bookworm), unfortunately neither org-drill nor org-contrib are
installed by default when org-mode is installed.  I believe org-drill
should have been, but I'm not sure sure about org-contrib, given its
status as a kind of unmaintained orphanage area.  Do you think that
org-contrib should be installed alongside Org by default?  I believe in
"better late than never", so would like to fix these issues for Debian
13 (trixie), as well as for users who will manually install the latest
available Debian org-mode package onto older releases.

Also, is there something we should consider automatically parsing for
notice of these kinds of changes?

Regards,
Nicholas

Bug#1040437: zypper: new upstream release

[Luca Boccassi]

Source: zypper
Version: 1.14.42-2

Dear Maintainer,

I'd like to have the new upstream versions of libsolv/libzypp/zypper in
Debian. I have prepared the updates and tested them, and if there are
no objections I intend to upload to DELAYED/3 tomorrow.
The packages are marked LowNMU but given it's new versions rather than
individual bugfixes I'm opening a bug and using the delayed upload
anyway.

-- 
Kind regards,
Luca Boccassi


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

Bug#923908: new upstream version available (9.2)

[Nicholas D Steeves]

Hi,

Sebastien Delafond  writes:

> On 15/03 22:45, Nicholas D Steeves wrote:
>> While triaging bugs I just noticed this one is marked fixed but is
>> still open.  Was it left open as a reminder to backport bullseye's
>> org-mode?
>
> I believe that was the rationale at the time.
>
>> Does arch:all elpa-org-mode need a formal bpo, or will adding testing
>> or sid apt source in combination with pinning work well enough?
>
> Package pinning should work fine, but if enough users request a proper
> stable backport I guess it could also be maintained.

Bookworm has been released, which means bullseye-backports will probably
be winding down in a year.  Meanwhile, no one requested an org-mode
formal backport in three years, so I think it's safe to close this bug.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1040436: pev: confusing comments in autopkgtests

[Sam Hartman]

Source: pev
Version: 0.81-9
Severity: minor


While reviewing pev, I noticed that  some of the comments in 
debian/tests/test-runs are inaccurate

I think the following patch is sufficient
diff --git a/debian/tests/test-runs b/debian/tests/test-runs
index 675d4ec..9fe48fd 100755
--- a/debian/tests/test-runs
+++ b/debian/tests/test-runs
@@ -1,14 +1,11 @@
 #!/bin/sh
 #
-# Try to build and run the example code.  Provide input on both stdin
-# and as first argument as the programs seem to handle either or both.
-# The goal is to verify that it is possible to link with the libvorbis
-# library and run the resulting binaries.
+
+# Some simple tests of pev against windows gzip executable
 
 set -e
 
 retval=0
-#cd $AUTOPKGTEST_TMP
 
 # We don't want plugins from the build directory for the
 # installed package.
@@ -37,9 +34,9 @@ else
 fi
 
 if $VALGRIND pehash "$TESTEXE" | grep sha256:; then
-echo "success: pehash reported ASLR status"
+echo "success: pehash reported correct hash status"
 else
-echo "error: pehash did not report ASLR status"
+echo "error: pehash did not report hash"
 retval=1
 fi
 

Bug#1040435: bookworm-pu: package postfix/3.7.4-2

[Scott Kitterman]

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

[ Reason ]
This is a regression relative to old stable on something that is
critical for a subset of postfix users.  Apparently, when I was updating
the package from postfix 3.6 to 3.7 I "temporarily" removed these
patches and then forgot to add them back in "later".  See #1040329.

I guess "now" is "later".

[ Impact ]
For most users, no impact, but for the subset of users that need to be
able to run postfix set-permissions, the package is unusable.

[ Tests ]
I did test this manually and also modified the autopkgtest to fail if
set-permissions fail to catch this in the future.

[ Risks ]
Risk is trivial.  This doesn't affect anyone who doesn't run
set-permissions and for those that do, the package is already broken.
For them, there's no real alternative.

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

[ Changes ]
Updated and added back in the patches that update the files that
set-permissions looks for to match what Debian installs.

Updated the autopkgtest

[ Other info ]
There is already a stable-update pending, so the debdiff is relative to
that (and there's no overlap between it and this change).  Unstable is
not fixed yet.  Given the nearness of the point release and the impact
on stable users, I opted to git it sorted in stable first.  I will have
it uploaded to Unstable shortly.
diff -Nru postfix-3.7.6/debian/changelog postfix-3.7.6/debian/changelog
--- postfix-3.7.6/debian/changelog  2023-06-17 13:34:11.0 -0400
+++ postfix-3.7.6/debian/changelog  2023-07-05 17:18:24.0 -0400
@@ -1,3 +1,13 @@
+postfix (3.7.6-0+deb12u2) bookworm; urgency=medium
+
+  * Correct regression that caused postfix set-permissions to fail (Closes:
+#1040329)
+- Restore and update debian/patches/05_debian_manpage_differences.diff
+- Restore and update debian/patches/05_debian_readme_differences.diff
+  * Update autopkgtest to test postfix set-permissions
+
+ -- Scott Kitterman   Wed, 05 Jul 2023 17:18:24 -0400
+
 postfix (3.7.6-0+deb12u1) bookworm; urgency=medium
 
   [Scott Kitterman]
diff -Nru postfix-3.7.6/debian/patches/05_debian_manpage_differences.diff 
postfix-3.7.6/debian/patches/05_debian_manpage_differences.diff
--- postfix-3.7.6/debian/patches/05_debian_manpage_differences.diff 
1969-12-31 19:00:00.0 -0500
+++ postfix-3.7.6/debian/patches/05_debian_manpage_differences.diff 
2023-07-05 16:51:05.0 -0400
@@ -0,0 +1,159 @@
+Index: postfix-dev/conf/postfix-files
+===
+--- postfix-dev.orig/conf/postfix-files2019-03-01 11:07:21.045697994 
-0500
 postfix-dev/conf/postfix-files 2019-03-01 11:17:55.721711534 -0500
+@@ -166,79 +166,81 @@
+ #$config_directory/postfix-script-sgid:f:root:-:755:o
+ #$config_directory/postfix-script-nosgid:f:root:-:755:o
+ $config_directory/post-install:f:root:-:755:o
+-$manpage_directory/man1/mailq.1:f:root:-:644
+-$manpage_directory/man1/newaliases.1:f:root:-:644
+-$manpage_directory/man1/postalias.1:f:root:-:644
+-$manpage_directory/man1/postcat.1:f:root:-:644
+-$manpage_directory/man1/postconf.1:f:root:-:644
+-$manpage_directory/man1/postdrop.1:f:root:-:644
+-$manpage_directory/man1/postfix-tls.1:f:root:-:644
+-$manpage_directory/man1/postfix.1:f:root:-:644
+-$manpage_directory/man1/postkick.1:f:root:-:644
+-$manpage_directory/man1/postlock.1:f:root:-:644
+-$manpage_directory/man1/postlog.1:f:root:-:644
+-$manpage_directory/man1/postmap.1:f:root:-:644
+-$manpage_directory/man1/postmulti.1:f:root:-:644
+-$manpage_directory/man1/postqueue.1:f:root:-:644
+-$manpage_directory/man1/postsuper.1:f:root:-:644
+-$manpage_directory/man1/sendmail.1:f:root:-:644
+-$manpage_directory/man5/access.5:f:root:-:644
+-$manpage_directory/man5/aliases.5:f:root:-:644
+-$manpage_directory/man5/body_checks.5:f:root:-:644
+-$manpage_directory/man5/bounce.5:f:root:-:644
+-$manpage_directory/man5/canonical.5:f:root:-:644
+-$manpage_directory/man5/cidr_table.5:f:root:-:644
+-$manpage_directory/man5/generics.5:f:root:-:644:o
+-$manpage_directory/man5/generic.5:f:root:-:644
+-$manpage_directory/man5/header_checks.5:f:root:-:644
+-$manpage_directory/man5/ldap_table.5:f:root:-:644
+-$manpage_directory/man5/lmdb_table.5:f:root:-:644
+-$manpage_directory/man5/master.5:f:root:-:644
+-$manpage_directory/man5/memcache_table.5:f:root:-:644
+-$manpage_directory/man5/mysql_table.5:f:root:-:644
+-$manpage_directory/man5/socketmap_table.5:f:root:-:644
+-$manpage_directory/man5/sqlite_table.5:f:root:-:644
+-$manpage_directory/man5/nisplus_table.5:f:root:-:644
+-$manpage_directory/man5/pcre_table.5:f:root:-:644
+-$manpage_directory/man5/pgsql_table.5:f:root:-:644

Bug#1037136: dpkg-buildflags: 64-bit time_t by default

[Steve Langasek]

Hi,

I wanted to check in on the status of this.

On Fri, Jun 09, 2023 at 03:56:28AM +0200, Guillem Jover wrote:
> On Mon, 2023-06-05 at 21:18:10 -0700, Steve Langasek wrote:
> > Package: dpkg-dev
> > Version: 1.21.22
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu mantic patch

> > The discussion on debian-devel around 64-bit time_t has died down, so I
> > figure it's time to propose some patches to implement what's been discussed
> > there.

> Yeah, I'm not sure whether it has died off or it's just being slow.

> > I'm not sure whether you were persuaded that i386 should stay with the
> > current ABI, but anyway thought I would propose the patches and we could
> > discuss further if necessary.

> In any case I've tried to reply there. Also my impression was that
> there was still some analysis pending (perhaps that was a wrong
> impression though)?

There is analysis pending, unfortunately 90% of the -dev packages have been
analyzed leaving 90% to go (~1600 -dev packages that require fixes to be
compilable and therefore analyzable).  I don't have any answer yet from the
Release Team, so I'm not sure if we need this analysis to be completely done
before starting the transition or if we can leave the long tail of packages
with 1 or 2 reverse-build-dependencies to be figured out later.

> Thanks for the patches!

> > From 5a861d19b1610ae82bf95e6c5142a3365436fbd2 Mon Sep 17 00:00:00 2001
> > From: Steve Langasek 
> > Date: Fri, 2 Jun 2023 14:30:20 +
> > Subject: [PATCH 1/3] lfs and time64 are no longer "future", call them
> >  "feature" instead

> Ah, I actually had implemented locally the alias with your original
> suggestion of "abi"! :) Using "feature" here seems would be rather
> more confusing as these are called feature flags, and feature areas.

> I'll try to push the stuff I've got queued locally during the weekend,
> then I can rebase these patches on a branch or similar.

As far as I can tell, this hasn't been pushed anywhere yet?

> > From 7eff8f89b32b6921a0d86c50c6c62154c6ddc96e Mon Sep 17 00:00:00 2001
> > From: Steve Langasek 
> > Date: Fri, 2 Jun 2023 16:30:19 +
> > Subject: [PATCH 3/3] Also emit -Werror=implicit-function-declaration for
> >  feature=+time64
> > 
> > Per https://lists.debian.org/debian-devel/2023/05/msg00262.html et al.,
> > missing glibc includes can cause packages to link to the wrong symbols,
> > potentially causing crashes or misbehavior.  Since functions that use
> > time_t are fairly ubiquitous, there's a high risk of this happening for
> > *some* package in Debian.  Better to make all software with missing
> > function declarations fail to build now, than to spend all cycle tracking
> > down runtime bugs.
> > ---
> >  scripts/Dpkg/Vendor/Debian.pm | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
> > index 20d77fea1..803949024 100644
> > --- a/scripts/Dpkg/Vendor/Debian.pm
> > +++ b/scripts/Dpkg/Vendor/Debian.pm
> > @@ -400,6 +400,8 @@ sub _add_build_flags {
> >  
> >  if ($flags->use_feature('feature', 'time64')) {
> >  $flags->append('CPPFLAGS', '-D_TIME_BITS=64');
> > +$flags->append('CFLAGS', '-Werror=implicit-function-declaration');
> > +$flags->append('CXXFLAGS', 
> > '-Werror=implicit-function-declaration');
> >  }

> I'm not sure I like intermingling the different semantics here, if
> necessary I'd rather make time64 forcibly enable another feature flag,
> like it is done for lfs.

> As I mentioned on the recent thread about the modern C stuff, I do
> have a branch that adds these as part of a new qa=+c99 feature, but
> that's too broad. :/

>   
> 

> Maybe I could add a new feature area instead and add the flags
> individually, and then make time64 also enable that other specific
> feature. Hmmm.

Did you reach a decision here?  Anything you'd like from me to move this
forward?

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


signature.asc
Description: PGP signature

Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive

[Manuel A. Fernandez Montecelo]

Hi,

On Wed, 29 Mar 2023 at 17:48, Manuel A. Fernandez Montecelo
 wrote:
>
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: aure...@debian.org, m...@debian.org
>
> Hello FTP team,
>
> We had conversations requesting different teams (FTP, Release, DSA) their
> opinion about adding riscv64 [1] as a new architecture in the main
> infrastructure and all teams gave their provisional approval, so we are
> submitting this to track progress on this task.
>
> Could you please tells us if there's any blocker or something else that we
> should do?
>
>
> Cheers.
>
>
> [1] https://wiki.debian.org/Ports/riscv64

Gentle ping?

We'd like to start with this when possible, the rebuilding of the
whole archive will take a while and this is a good moment for us.

If there's any blocker, please let us know.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#1040434: RM: crtmpserver -- RoQA; Unmaintained, RC-buggy, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: crtmpser...@packages.debian.org
Control: affects -1 + src:crtmpserver

Please remove crtmpserver. It's RC-buggy and dropped from testing for over
three years no (and missed two stable releases), it's dead upstream and
has only been maintained via NMUs since 2013.

Bug#1040433: RFA: anki - flashcard learning program, has migrated to Rust/Python/JavaScript combination

[Julian Gilbey]

Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-r...@lists.debian.org

Anki is a superb flashcard system for learning anything.  It used to
be a straightforward Python package with some JavaScript for the front
end.  But over the last couple of years, it has migrated to a
combination of Rust, Python and JavaScript (using node).  (It went via
the unpackaged Bazel package building system, but it's now migrated
away from that.)

I do not have the capacity to maintain this lovely package now that it
has become significantly more complex.  It is currently in unstable at
version 2.1.15, which was a Python-only version (plus a bit of
JavaScript).  It no longer builds on testing, and did not make it into
bookworm; upstream is now at 2.1.65.

I have had several requests to update the package and bring it back
into Debian, both via the BTS and via personal emails.

If anyone would like to pick up where I left off, please do let me
know.  I'd be happy to share with you what I learnt from the Python
version, but how relevant that will be for the new
Rust/Python/JavaScript incarnation, I do not know.  (And I don't know
how many other dependencies will need to be packaged from scratch,
unfortunately.  And one further complication is that Cargo.toml also
lists three forked crates)

Many thanks!

   Julian

Bug#1040432: ical2html: man pages for ical2html binaries contain "./binary: unrecognized option '--help'"

[Carles Pina i Estany]

Package: ical2html
Version: 3.0-1
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?

Reading the manual: "man ical2html"

Each of the manual pages (man ical2html, icalfilter and icalmerge)
contain a line: ./ical2html: unrecognized option '--help'

I'm sending the bugreport from an oldstable (see "System Information")
but I've verified this from a stable version (latest ical2html package).

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


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

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

Versions of packages ical2html depends on:
ii  libc6 2.31-13+deb11u6
ii  libical3  3.0.9-2

ical2html recommends no packages.

ical2html suggests no packages.

-- no debconf information

Bug#1040297: gnome: Gnome fails to start on login and falls back to GDM3

[Bastian Venthur]

[Apologies for sending this twice, my original mail did not make it to 
the bug tracker.]


Hi Simon,

here's the additional info you've asked for. The excerpt from 
history.log for the software I've installed on the day the system broke, 
and two outputs of coredumlpctl:


Start-Date: 2023-07-03  09:06:13
Requested-By: venthur (1000)
Install: libavtp0:amd64 (0.2.0-1+b1, automatic), 
libheif-plugin-libde265:amd64 (1.16.2-1, automatic), 
libheif-plugin-aomdec:amd64 (1.16.2-1, automatic), 
libheif-plugin-x265:amd64 (1.16.2-1, automatic), 
libheif-plugin-aomenc:amd64 (1.16.2-1, automatic), libsframe1:amd64 
(2.40.50.20230630-1, automatic), libheif-plugin-dav1d:amd64 (1.16.2-1, 
automatic)
Upgrade: libsynctex2:amd64 (2022.20220321.62855-6, 
2022.20220321.62855-7), openjdk-11-jre:amd64 (11.0.19+7-1, 11.0.20~7-1), 
libedata-book-1.2-27:amd64 (3.48.3-1, 3.48.4-1), libebook-1.2-21:amd64 
(3.48.3-1, 3.48.4-1), libyajl2:amd64 (2.1.0-3, 2.1.0-3.1), 
libgomp1:amd64 (13.1.0-6, 13.1.0-7), libecal-2.0-2:amd64 (3.48.3-1, 
3.48.4-1), libedataserver-1.2-27:amd64 (3.48.3-1, 3.48.4-1), udev:amd64 
(253-4, 253.5-1), evolution-data-server:amd64 (3.48.3-1, 3.48.4-1), 
openjdk-11-jre-headless:amd64 (11.0.19+7-1, 11.0.20~7-1), g++-12:amd64 
(12.3.0-4, 12.3.0-5), gstreamer1.0-plugins-ugly:amd64 (1.22.3-2, 
1.22.4-1), gcc-12:amd64 (12.3.0-4, 12.3.0-5), libctf-nobfd0:amd64 
(2.40.50.20230625-1, 2.40.50.20230630-1), libtsan2:amd64 (13.1.0-6, 
13.1.0-7), libnss-myhostname:amd64 (253-4, 253.5-1), libtexluajit2:amd64 
(2022.20220321.62855-6, 2022.20220321.62855-7), libtexlua53-5:amd64 
(2022.20220321.62855-6, 2022.20220321.62855-7), 
evolution-data-server-common:amd64 (3.48.3-1, 3.48.4-1), 
texlive-binaries:amd64 (2022.20220321.62855-6, 2022.20220321.62855-7), 
systemd-timesyncd:amd64 (253-4, 253.5-1), libtinfo6:amd64 (6.4-4, 
6.4+20230625-1), libtinfo6:i386 (6.4-4, 6.4+20230625-1), 
libtasn1-6:amd64 (4.19.0-2, 4.19.0-3), gir1.2-gstreamer-1.0:amd64 
(1.22.3-2, 1.22.4-1), libsrt1.5-gnutls:amd64 (1.5.1-1, 1.5.2-1), 
libpam-systemd:amd64 (253-4, 253.5-1), libdebuginfod-common:amd64 
(0.188-2.1, 0.189-3), openjdk-17-jre:amd64 (17.0.8~6-2, 17.0.8~6-3), 
libheif1:amd64 (1.15.1-1, 1.16.2-1), locate:amd64 (4.9.0-4, 4.9.0-5), 
libkpathsea6:amd64 (2022.20220321.62855-6, 2022.20220321.62855-7), 
libbinutils:amd64 (2.40.50.20230625-1, 2.40.50.20230630-1), 
i2c-tools:amd64 (4.3-2+b3, 4.3-3), libgfortran5:amd64 (13.1.0-6, 
13.1.0-7), libsystemd0:amd64 (253-4, 253.5-1), libi2c0:amd64 (4.3-2+b3, 
4.3-3), binutils-x86-64-linux-gnu:amd64 (2.40.50.20230625-1, 
2.40.50.20230630-1), libnss-systemd:amd64 (253-4, 253.5-1), 
evolution-plugins:amd64 (3.48.3-1, 3.48.4-1), debianutils:amd64 
(5.7-0.4, 5.7-0.5), libjsoncpp25:amd64 (1.9.5-4, 1.9.5-5), 
libevolution:amd64 (3.48.3-1, 3.48.4-1), libgegl-common:amd64 
(1:0.4.44-3, 1:0.4.46-1), libdebuginfod1:amd64 (0.188-2.1, 0.189-3), 
libcc1-0:amd64 (13.1.0-6, 13.1.0-7), python3-pyparsing:amd64 (3.0.9-1, 
3.1.0-1), libgegl-0.4-0:amd64 (1:0.4.44-3, 1:0.4.46-1), 
libcamel-1.2-64:amd64 (3.48.3-1, 3.48.4-1), 
libedataserverui4-1.0-0:amd64 (3.48.3-1, 3.48.4-1), gcc-9-base:amd64 
(9.5.0-3, 9.5.0-3+b1), systemd:amd64 (253-4, 253.5-1), libudev1:amd64 
(253-4, 253.5-1), libudev1:i386 (253-4, 253.5-1), systemd-dev:amd64 
(253-4, 253.5-1), libptexenc1:amd64 (2022.20220321.62855-6, 
2022.20220321.62855-7), libebook-contacts-1.2-4:amd64 (3.48.3-1, 
3.48.4-1), libc6:amd64 (2.36-9, 2.37-3), libc6:i386 (2.36-9, 2.37-3), 
locales:amd64 (2.36-9, 2.37-3), libasan8:amd64 (13.1.0-6, 13.1.0-7), 
libedataserverui-1.2-4:amd64 (3.48.3-1, 3.48.4-1), 
libgstreamer-plugins-bad1.0-0:amd64 (1.22.3-2, 1.22.4-1), 
evolution-plugin-pstimport:amd64 (3.48.3-1, 3.48.4-1), libctf0:amd64 
(2.40.50.20230625-1, 2.40.50.20230630-1), ncurses-base:amd64 (6.4-4, 
6.4+20230625-1), evolution-plugin-bogofilter:amd64 (3.48.3-1, 3.48.4-1), 
findutils:amd64 (4.9.0-4, 4.9.0-5), evolution:amd64 (3.48.3-1, 
3.48.4-1), libgstreamer1.0-0:amd64 (1.22.3-2, 1.22.4-1), cpp-12:amd64 
(12.3.0-4, 12.3.0-5), binutils-common:amd64 (2.40.50.20230625-1, 
2.40.50.20230630-1), python3-dotenv-cli:amd64 (3.1.1-1, 3.2.0-1), 
libitm1:amd64 (13.1.0-6, 13.1.0-7), python3-protobuf:amd64 (3.21.12-3, 
3.21.12-5), gnome-pkg-tools:amd64 (0.22.7, 0.22.9), libc-dev-bin:amd64 
(2.36-9, 2.37-3), python3-exceptiongroup:amd64 (1.1.0-1, 1.1.1-1), 
postgresql-client-common:amd64 (248, 252), libc-l10n:amd64 (2.36-9, 
2.37-3), gir1.2-gst-plugins-bad-1.0:amd64 (1.22.3-2, 1.22.4-1), 
libc-bin:amd64 (2.36-9, 2.37-3), libsystemd-shared:amd64 (253-4, 
253.5-1), libopenmpt0:amd64 (0.7.1-1, 0.7.2-1), libc-devtools:amd64 
(2.36-9, 2.37-3), libedata-cal-2.0-2:amd64 (3.48.3-1, 3.48.4-1), 
libgprofng0:amd64 (2.40.50.20230625-1, 2.40.50.20230630-1), 
postgresql-client:amd64 (15+248, 15+252), libc6-dbg:amd64 (2.36-9, 
2.37-3), libc6-dev:amd64 (2.36-9, 2.37-3), libksba8:amd64 (1.6.3-2, 
1.6.4-2), libquadmath0:amd64 (13.1.0-6, 13.1.0-7), libprotobuf32:amd64 
(3.21.12-3, 3.21.12-5), systemd-sysv:amd64 (253-4, 253.5-1), 

Bug#1040431: user-mode-linux: build dependency missing in testing: linux-source-6.1

[Paul Gevers]

Source: user-mode-linux
Version: 6.1um4
Severity: serious
User: debian...@lists.debian.org
Usertag: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting issues with your packages. Normally your build 
dependencies shouldn't be removed from testing without removal all 
reverse build dependencies too, nor should a package be allowed to 
migrate unless all build dependencies are candidate for migration too. 
However, somehow we ended up in the current state and your source 
package is missing some Build-Depends for some while now. Not being able 
to build from source in a suite is an RC bug in that suite.


Can you please solve the situation?

Paul

[1] https://qa.debian.org/dose/debcheck/src_testing_main/index.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040430: ddclient: Upstream is unmaintained

[Reuben Thomas]

Package: ddclient
Version: 3.9.1-7
Severity: important
Tags: upstream

As of yesterday, upstream has marked the project unmaintained and archived the 
GitHub project. See https://github.com/ddclient/ddclient/

I and at least one other person offered to take over the project;
unfortunately, since the GitHub project has been archived and hence the
issue trackers cannot now be updated, it’s hard for those of us interested
in continuing the project to coordinate.

I have therefore unilaterally announced my intention to maintain the project
at least for the immediate future.

My announcement is here: https://github.com/rrthomas/ddclient/issues/1

I am filing an issue in the BTS about this to let the Debian maintainer and
users know. I am a long-time user of ddclient in Debian/Ubuntu; I’m a DM;
and I’m upstream for many Debian packages (in particular, many mature
packages whose previous maintainers handed them over to me).

Therefore, Debian may be interested in using my fork as upstream.

There don’t seem to be many outstanding bugs in the BTS for this package,
and no serious ones. I don’t propose to make major changes to the package,
though I do plan to remove some code (see my announcement).

I welcome input from the Debian community.

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-76-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddclient depends on:
ii  debconf [debconf-2.0] 1.5.79ubuntu1
ii  init-system-helpers   1.62
ii  libdata-validate-ip-perl  0.30-1
ii  lsb-base  11.1.0ubuntu4
ii  perl  5.34.0-3ubuntu1.2

Versions of packages ddclient recommends:
ii  libdigest-sha-perl   6.02-1build4
ii  libio-socket-inet6-perl  2.73-1
ii  libio-socket-ssl-perl2.074-2
ii  perl [libjson-pp-perl]   5.34.0-3ubuntu1.2

ddclient suggests no packages.

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/sbin/ddclient (from ddclient package)

Bug#1040429: python3-mechanicalsoup: please package new version 1.3.0 ...

[Alexandre Detiste]

Package: python3-mechanicalsoup
Version: 0.10.0-6
Severity: normal
User: python3-...@packages.debian.org
Usertags: python3-six-removal

... and drop obsolete dependency on python3-six

:-)

Greetings,


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
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)

Versions of packages python3-mechanicalsoup depends on:
ii  python3   3.11.2-1+b1
ii  python3-bs4   4.12.2-2
ii  python3-lxml  4.9.2-1+b1
ii  python3-requests  2.28.1+dfsg-1
ii  python3-six   1.16.0-4

python3-mechanicalsoup recommends no packages.

python3-mechanicalsoup suggests no packages.

Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons

[Thorsten Glaser]

On Wed, 5 Jul 2023, g...@libero.it wrote:

>But [o-s-s] should also invoke-rc.d  try-restart, for perfection.

I don’t think so. I think the postinst of the services in question
restart the service, and that ought to “just work”, independent of
the init system in use, as long as an initsystem-compatible service
initscript is present (no matter whether it’s in the package itself
or in a separate one).

After all, not all packages restart services on upgrade; some pak‐
kages contain more than one service, not all of which are restarted
always, etc.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1040417: docker-compose V1 is depreciated

[Peter Allebone]

Thank you for your time, it is appreciated.

P

On Wed, Jul 5, 2023 at 3:45 PM Leandro Cunha 
wrote:

> Hi,
>
> On Wed, Jul 5, 2023 at 4:38 PM Peter Allebone  wrote:
> >
> > Hi Leandro,
> >
> > Thank you for this information. Hopefully it can be updated sometime,
> for now what do you suggest users of Debian do as V1 is depreciated now?
> Must we compile on our own?
> >
> > Kind regards
> > Peter
> >
> > On Wed, Jul 5, 2023 at 3:35 PM Leandro Cunha 
> wrote:
> >>
> >> Hi,
> >>
> >> At the moment it would not be possible to update to the latest version
> >> of docker compose version 2, due to the lack of dependencies for
> >> building the package and there is a staff taking care of it. About the
> >> deprecation, I think Andrej knows this and the whole Docker Compose
> >> Team. I'm not part of this team, but I use the package frequently.
> >>
> >> --
> >> Cheers,
> >> Leandro Cunha
>
> I think it's possible to wait. Despite being deprecated, it is still
> possible to use. I'll check in with the folks who are packaging the
> dependencies for version 2 to see if I can help with anything.
>
> --
> Cheers,
> Leandro Cunha
>

Bug#1039967:

[Andreas Hasenack]

Hi,

On Wed, Jul 5, 2023 at 6:54 AM Mike Gabriel
 wrote:
>
> Hi Andreas,
>
> On  Fr 30 Jun 2023 14:12:01 CEST, Andreas Hasenack wrote:
>
> > We have that patch[1] in Ubuntu, and also DEP8 tests that use autofs
> > with kerberos and sasl authentication mechanisms[2] (and patches for
> > problems in that area: autofs 5.1.8 was a bit disruptive). Note these
> > tests require a VM, like the other existing DEP8 tests, but I can
> > prepare a PR for this new one if the maintainer is willing to consider
> > it.
> >
> > 1.
> > https://git.launchpad.net/ubuntu/+source/autofs/tree/debian/patches/autofs-5.1.8-ldap-kerberos-leads-to-automount-hang-p.patch
> > 2.
> > https://git.launchpad.net/ubuntu/+source/autofs/tree/debian/tests/ldap-map-sasl-auth
>
> An MR for the autopkgtesting would be much appreciated. I have just
> uploaded the referenced upstream patch as autofs 5.1.8-3, but having
> the autopkgtest in addition would be good.

Done:
https://salsa.debian.org/debian/autofs/-/merge_requests/4

We can discuss changes in the PR.

Bug#1040401: dkms: forgets to rebuild all kernel modules when autoinstall_all_kernels=1

[Vincent Lefevre]

On 2023-07-05 17:21:04 +0200, Andreas Beckmann wrote:
> On 05/07/2023 16.17, Vincent Lefevre wrote:
> > I have autoinstall_all_kernels="1" in /etc/dkms/framework.conf
> > so that all kernel modules are rebuilt when some dependency
> > changes.
> 
> Does that at least cause a rebuild if the linux-headers-* package gets
> updated? IIRC as long as KVERS does not change, dkms does not rebuild
> modules on header change.
> 
> More general: if linux-headers-* gets updated but the ABI does not change
> (and the ABI is not 0), does dkms have to rebuild the modules? Why?

I'm quoting what you said in bug 1040178:

| This needs to be fixed before linux 6.3.0-2-* can migrate to testing,
| otherwise it will break dkms module building for everyone still having
| linux-headers-6.3.0-1-* installed (which is probably for the currently
| running kernel).

Though I track unstable instead of testing, the issue is basically
the same (I'm concerned now instead of later, if nothing is changed).

What you said is that the upgrade to 6.3.0-2-* is expected to break
dkms module building for everyone still having linux-headers-6.3.0-1-*
installed (which is exactly my case), and 6.3.0-1 was indeed the
currently running kernel in my case.

This means that you expect the upgrade to 6.3.0-2-* to rebuild the
kernel modules for 6.3.0-1 (otherwise, i.e. if the 6.3.0-1 modules
are not rebuilt, there are no bugs at all). But this is not what
happened.

And it doesn't seem that autoinstall_all_kernels actually matters.

> from dkms(8):
> > .B $autoinstall_all_kernels
> > Used by the common postinst for DKMS modules. It controls if the build
> > should be done for all installed kernels or only for the current and
> > latest installed kernel. It has no command
> > line equivalent.
> 
> So that flag is not doing what you expected. And I think on Debian it is
> ignored and we always build for all kernels. But only on new header
> installation or on dkms module update. Not on header update.

Yes, it is probably a different matter. I now remember that
autoinstall_all_kernels is not sufficient as the ABI may change
without being announced. See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856355#54

This is crap (I had written a workaround in /etc/kernel/postinst.d,
and I've just noticed that it got broken after an upgrade 3 years
ago), but this is unrelated to the above issue.

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

Bug#1040428: gcalcli: please remove extraneous dependency on python3-six

[Alexandre Detiste]

Package: gcalcli
Version: 4.3.0-1
Severity: normal
User: python3-...@packages.debian.org
Usertags: python3-six-removal

Hi,

Usage of python3-six was already gone at the time
of the 4.3.0 release.

$ grep six /usr/lib/python3/dist-packages/gcalcli -r
$ grep six /usr/bin/gcalcli
$ grep six /usr/lib/python3/dist-packages/gcalcli-4.3.0.egg-info/ -r

Please remove the extraneous dependency.

Greetings,



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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
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)

Versions of packages gcalcli depends on:
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-googleapi  1.7.12-1
ii  python3-httplib2   0.20.4-3
ii  python3-oauth2client   4.1.3-3
ii  python3-parsedatetime  2.6-3
ii  python3-six1.16.0-4

Versions of packages gcalcli recommends:
pn  python3-vobject  

gcalcli suggests no packages.

-- no debconf information

Bug#1040417: docker-compose V1 is depreciated

[Leandro Cunha]

Hi,

On Wed, Jul 5, 2023 at 4:38 PM Peter Allebone  wrote:
>
> Hi Leandro,
>
> Thank you for this information. Hopefully it can be updated sometime, for now 
> what do you suggest users of Debian do as V1 is depreciated now? Must we 
> compile on our own?
>
> Kind regards
> Peter
>
> On Wed, Jul 5, 2023 at 3:35 PM Leandro Cunha  
> wrote:
>>
>> Hi,
>>
>> At the moment it would not be possible to update to the latest version
>> of docker compose version 2, due to the lack of dependencies for
>> building the package and there is a staff taking care of it. About the
>> deprecation, I think Andrej knows this and the whole Docker Compose
>> Team. I'm not part of this team, but I use the package frequently.
>>
>> --
>> Cheers,
>> Leandro Cunha

I think it's possible to wait. Despite being deprecated, it is still
possible to use. I'll check in with the folks who are packaging the
dependencies for version 2 to see if I can help with anything.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1039941: debhelper: intermittent dh_missing error

[Sven Joachim]

Control: tags -1 - unreproducible

On 2023-07-01 17:18 +0200, Sven Joachim wrote:

> Control: tags -1 + unreproducible
>
> On 2023-06-29 21:06 +0200, Sven Joachim wrote:
>
>> Package: debhelper
>> Version: 13.11.4
>> Severity: normal
>>
>> In the Salsa CI for ncurses a rather strange failure happens in the
>> reprotest job[1]:
>>
>> ,
>> | dh_missing -i --fail-missing
>> | dh_missing: warning: usr/lib32/libncurses.so exists in debian/tmp but is 
>> not installed to anywhere (related file: 
>> "debian/tmp/usr/lib/x86_64-linux-gnu/libncurses.so")
>> | dh_missing: warning: usr/lib32/libncursesw.so exists in debian/tmp but is 
>> not installed to anywhere (related file: 
>> "debian/tmp/usr/lib/x86_64-linux-gnu/libncursesw.so")
>> | dh_missing: error: missing files, aborting
>> `
>>
>> I recall that I had seen this error occasionally in my local builds, but
>> was (and still am) not able to reproduce it :-(.  Maybe there is also an
>> error in the ncurses package that I do not see.  Any help is appreciated.
>
> Small update: the reprotest job in ncurses failed four times on 2023-06-29, I
> rescheduled the last one (for commit 1c832772[1]) on 2023-06-30 and it
> succeeded.  Commit 78b0c63b[2] should sidestep this problem in the
> future.

That was successful, but after some changes to ncurses' debian/rules
today I got another dh_missing failure in the reprotest job[1].

> Clearly there is some kind of race condition involved here, but I have
> not been able to figure out what it is, and will probably not spend more
> time on it unless somebody gives me a hand.

I think I am beginning to understand where the race condition is.  In
full builds of ncurses it is possible for 'make' to process the
install-arch and binary-indep targets in parallel, which can cause new
files to appear in debian/tmp after "dh_missing -i" has processed the
debian/.debhelper/generated/*/installed-by-* files, but before it
actually reads the contents of debian/tmp.  Those files will then be
falsely reported as not installed.

Probably such a situation is relatively unusual, and I guess dh_missing
has not been designed to handle it.  Will see how best to work around it
in ncurses.

Sven


1. https://salsa.debian.org/debian/ncurses/-/jobs/4400129

Bug#1040417: docker-compose V1 is depreciated

[Peter Allebone]

Hi Leandro,

Thank you for this information. Hopefully it can be updated sometime, for
now what do you suggest users of Debian do as V1 is depreciated now? Must
we compile on our own?

Kind regards
Peter

On Wed, Jul 5, 2023 at 3:35 PM Leandro Cunha 
wrote:

> Hi,
>
> At the moment it would not be possible to update to the latest version
> of docker compose version 2, due to the lack of dependencies for
> building the package and there is a staff taking care of it. About the
> deprecation, I think Andrej knows this and the whole Docker Compose
> Team. I'm not part of this team, but I use the package frequently.
>
> --
> Cheers,
> Leandro Cunha
>

Bug#1040427: speedometer: please package v2.9

[Alexandre Detiste]

Package: speedometer
Version: 2.8-3
Severity: normal
User: python3-...@packages.debian.org
Usertags: python3-six-removal


v2.9 is available here:
   https://github.com/wardi/speedometer/tags

I see thaht debian/watch hes been automatically fixed
on Salsa by the lintian-brush tool. Great.



Can you also please remove the now extraneous python3-six
dependency ?


Greetings,





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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
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)

Versions of packages speedometer depends on:
ii  python3 3.11.2-1+b1
ii  python3-psutil  5.9.4-1+b1
ii  python3-setuptools  67.8.0-1
ii  python3-six 1.16.0-4
ii  python3-urwid   2.1.2-4+b1

speedometer recommends no packages.

speedometer suggests no packages.

-- no debconf information

Bug#1040417: docker-compose V1 is depreciated

[Leandro Cunha]

Hi,

At the moment it would not be possible to update to the latest version
of docker compose version 2, due to the lack of dependencies for
building the package and there is a staff taking care of it. About the
deprecation, I think Andrej knows this and the whole Docker Compose
Team. I'm not part of this team, but I use the package frequently.

-- 
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#1040426: FreeCAD Path: Generate dangeruos first G-code move while G49 is active

[Petter Reinholdtsen]

Package: freecad
Version: 0.20.2+dfsg1-4
Severity: important
Forwarded: https://github.com/FreeCAD/FreeCAD/issues/9866
Tags: patch

I created a FreeCAD model and generated some Path Jobs to mill it out,
and was very surprised when the generated G-code ended up digging the
first cutter straight into the work table. This is using the linuxcnc
post processor, but is unrelated to the postprocessor used.

The model is available from
https://codeberg.org/pere/thinkpad-x230-dc-socket-bracket >. I
used the G-code in the subdirectory linuxcnc-jobs in commit
ff248e59b7c44bda3e6320e6499ee9c240156dae for this failure.

I tracked this down to the first move in the generated in the G-code
file, which is a "G0 Z", which is no longer safe when the
15 cm tool height compensation has been wiped out with the G49 in the
preamble.

This is the generated G-code:

(Exported by FreeCAD)
(Post Processor: linuxcnc_post)
(Output Time:2023-07-03 14:24:06.190303)
(begin preamble)
G17 G54 G40 G49 G80 G90
G21
(begin operation: G54)
(machine units: mm/min)
G54 
G0 Z19.000 ; < This one is dangerous while G49 is active
(finish operation: G54)
(begin operation: 6mm-endmill001)
(machine units: mm/min)
(6mm-endmill001) 
M5
M6 T3 
G43 H3 
M3 S2500 
(finish operation: 6mm-endmill001)
(begin operation: MillFace)
(machine units: mm/min)
(MillFace) 
G0 Z19.000 

I see from https://forum.freecad.org/viewtopic.php?t=37839 > the
issue has been known since 2019, and was even mentioned as an issue when
the introduction of G43 was discussed in
https://forum.freecad.org/viewtopic.php?t=27180 >.  The dangerous
code is only generated when splitting the G-code into separate files per tool.

It is unclear to me why the G49 is used in the preamble to begin with.
Is it not better to put it just before the G43, and avoid any G0 move
before G43 has been used to load the correct tool height compensation?

I had used the automatic tool height measurement in the machine to set
the correct tool height compensation for the tool holder and bit in
question, and was very surprised to see that it dived straight down as
the first move. Was not able to stop it quickly enough to avoid damage.

I believe the following patch will fix the issue.  It is already sent
upstream.  I recommend considering it for the Debian package too.

commit d8f2f87130b28a769e91fe20ffad885feecf381d
Author: Petter Reinholdtsen 
Date:   Mon Jul 3 16:42:58 2023 +0200

Avoid dagerous move without tool height compensation after setting first 
fixture

The issue only happen when splitting jobs on tools (orderby == Tool), and 
when
USE_TLO was active and the preamble include G49.  The first move is then 
done
before tool height is set, and can cause damage if the existing tool height 
is set
to more than the gap between the spindle and the table or work piece, when 
the machine
take a sudden dive straight down.

Removed move between G49 and first G43, to ensure all moves are done after 
G43
correctly set tool height compensation.

Rewrote code to introduce new method fixtureSetup() to ensure all orderby 
alternatives
behave the same way.

Fixes #9866.

diff --git a/src/Mod/Path/Path/Post/Command.py 
b/src/Mod/Path/Path/Post/Command.py
index 9393e7282f..d1f0635cf5 100644
--- a/src/Mod/Path/Path/Post/Command.py
+++ b/src/Mod/Path/Path/Post/Command.py
@@ -252,6 +252,33 @@ def resolveFileName(job, subpartname, sequencenumber):
 return fullPath
 
 
+def fixtureSetup(order, fixture, job):
+"""Convert a Fixure setting to _TempObject instance with a G0 move to a
+safe height every time the fixture coordinate system change.  Skip
+the move for first fixture, to avoid moving before tool and tool
+height compensation is enabled.
+
+"""
+
+fobj = _TempObject()
+c1 = Path.Command(fixture)
+fobj.Path = Path.Path([c1])
+# Avoid any tool move after G49 in preamble and before tool change
+# and G43 in case tool height compensation is in use, to avoid
+# dangerous move without tool compesation.
+if order != 0:
+c2 = Path.Command(
+"G0 Z"
++ str(
+job.Stock.Shape.BoundBox.ZMax
++ job.SetupSheet.ClearanceHeightOffset.Value
+)
+)
+fobj.Path.addCommands(c2)
+fobj.InList.append(job)
+return fobj
+
+
 def buildPostList(job):
 """Takes the job and determines the specific objects and order to
 postprocess  Returns a list of objects which can be passed to
@@ -269,20 +296,7 @@ def buildPostList(job):
 currTool = None
 for index, f in enumerate(wcslist):
 # create an object to serve as the fixture path
-fobj = _TempObject()
-c1 = Path.Command(f)
-fobj.Path = Path.Path([c1])
-if index != 0:
-c2 = Path.Command(
-"G0 Z"
-+ str(
-

Bug#1040407: linux-image-6.3.0-1-amd64: X1 Carbon 9th gen, docked, external display stops working after suspend and there are kernel traces in the logs

[Claudio Saavedra]

> That commit is part of 6.4-rc7 and Experimental currently has 6.4.1-1
> so it 
> should be fixed with that kernel.
> Verification whether that's indeed the case would be appreciated.

According to
https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.3.11+1_changelog
it's also part of 6.3.11, so it should be fixed in unstable too. Sorry
that I didn't check beforehand.

Claudio

Bug#1040425: python3-boto3: please remove obsolete dependency on python3-six

[Alexandre Detiste]

Package: python3-boto3
Version: 1.26.155+dfsg-1
Severity: normal
User: python3-...@packages.debian.org
Usertags: python3-six-removal

Hi,

python3-boto3 doesn't use python3-six for a while,
please remove the now extraneous dependency.

   https://github.com/boto/boto3/commit/e2d0e64905fab77dbfe8443dabcd50606b641c4d

Greetings,


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
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)

Versions of packages python3-boto3 depends on:
ii  python3 3.11.2-1+b1
ii  python3-botocore1.29.155+repack-1
ii  python3-jmespath1.0.1-1
ii  python3-requests2.28.1+dfsg-1
ii  python3-s3transfer  0.6.0-1
ii  python3-six 1.16.0-4

python3-boto3 recommends no packages.

python3-boto3 suggests no packages.

-- no debconf information

Bug#1040424: python-pytest-random-order: implicitly depends on python3-py

[Timo Röhling]

Source: python-pytest-random-order
Version: 1.1.0-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package implicitly depends on python3-py for its autopkgtest, which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest and possibly your package.


Cheers
Timo

Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pytest-random-order/35336221/log.gz

 40s  ERRORS 

 40s _ ERROR at setup of test_it_works_with_actual_tests[class-2-5] 
_
 40s 
 40s testdir = 
 40s 
 40s @pytest.fixture
 40s def tmp_tree_of_tests(testdir):
 40s """
 40s Creates a directory structure:
 40s tmpdir/
 40s shallow_tests/
 40s test_a.py 2 passing, 1 failing
 40s deep_tests/
 40s test_b.py 2 passing, 1 failing
 40s test_c.py 1 passing
 40s test_d.py 2 passing
 40s test_e.py a class, 2 passing, 1 failing
 40s 
 40s If module name doesn't start with "test_", it isn't picked up by 
runpytest.
 40s """
 40s 
 40s sup = testdir.mkpydir('shallow_tests')
 40s 
 40s >   sup.join('test_a.py').write(py.code.Source("""
 40s def test_a1():
 40s assert False
 40s def test_a2():
 40s assert True
 40s def test_a3():
 40s assert True
 40s """))
 40s E   AttributeError: module 'py' has no attribute 'code'
 40s 
 40s 
/tmp/autopkgtest-lxc.hl72zszt/downtmp/build.oRr/src/tests/test_actual_test_runs.py:27:
 AttributeError
 40s  ERROR at setup of test_it_works_with_actual_tests[module-2-5] 
_
 40s 
 40s testdir = 
 40s 
 40s @pytest.fixture
 40s def tmp_tree_of_tests(testdir):
 40s """
 40s Creates a directory structure:
 40s tmpdir/
 40s shallow_tests/
 40s test_a.py 2 passing, 1 failing
 40s deep_tests/
 40s test_b.py 2 passing, 1 failing
 40s test_c.py 1 passing
 40s test_d.py 2 passing
 40s test_e.py a class, 2 passing, 1 failing
 40s 
 40s If module name doesn't start with "test_", it isn't picked up by 
runpytest.
 40s """
 40s 
 40s sup = testdir.mkpydir('shallow_tests')
 40s 
 40s >   sup.join('test_a.py').write(py.code.Source("""
 40s def test_a1():
 40s assert False
 40s def test_a2():
 40s assert True
 40s def test_a3():
 40s assert True
 40s """))
 40s E   AttributeError: module 'py' has no attribute 'code'
 40s 
 40s 
/tmp/autopkgtest-lxc.hl72zszt/downtmp/build.oRr/src/tests/test_actual_test_runs.py:27:
 AttributeError
 40s  ERROR at setup of test_it_works_with_actual_tests[package-2-5] 

 40s 
 40s testdir = 
 40s 
 40s @pytest.fixture
 40s def tmp_tree_of_tests(testdir):
 40s """
 40s Creates a directory structure:
 40s tmpdir/
 40s shallow_tests/
 40s test_a.py 2 passing, 1 failing
 40s deep_tests/
 40s test_b.py 2 passing, 1 failing
 40s test_c.py 1 passing
 40s test_d.py 2 passing
 40s test_e.py a class, 2 passing, 1 failing
 40s 
 40s If module name doesn't start with "test_", it isn't picked up by 
runpytest.
 40s """
 40s 
 40s sup = testdir.mkpydir('shallow_tests')
 40s 
 40s >   sup.join('test_a.py').write(py.code.Source("""
 40s def test_a1():
 40s assert False
 40s def test_a2():
 40s assert True
 40s def test_a3():
 40s assert True
 40s """))
 40s E   AttributeError: module 'py' has no attribute 'code'
 40s 
 40s 
/tmp/autopkgtest-lxc.hl72zszt/downtmp/build.oRr/src/tests/test_actual_test_runs.py:27:
 AttributeError
 40s  ERROR at setup of test_it_works_with_actual_tests[global-2-5] 
_
 40s 
 40s testdir = 
 40s 
 40s @pytest.fixture
 40s def tmp_tree_of_tests(testdir):
 40s """
 40s Creates a directory structure:
 40s tmpdir/
 40s shallow_tests/
 40s test_a.py 2 passing, 1 failing
 40s deep_tests/
 40s test_b.py 2 passing, 1 failing
 40s test_c.py 1 passing
 40s test_d.py 2 passing
 40s test_e.py a class, 2 passing, 1 failing
 

Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork

[Jonas Smedegaard]

Quoting Christopher Obbard (2023-07-05 18:16:45)
> On Tue, 2023-07-04 at 17:06 +0200, Jonas Smedegaard wrote:
> > Since none of these forks apparently is actively developed, I suggest to
> > not take any strong action like introducing an epoch, but instead simply
> > add a + to indicate that current situation is a mess - which it is:
> > 
> >   1.32+pine64.20210904
> 
> Right, I have done this and pushed my (unreleased) changes to 
> https://salsa.debian.org/debian/rkdeveloptool/-/commits/wip%2Fobbardc%2Fpine64
> 
> Lintian complains about the following in my unstable pbuilder:
> E: rkdeveloptool: non-standard-toplevel-dir [rules.d/]
> W: rkdeveloptool: file-in-unusual-dir [rules.d/99-rk-rockusb.rules]
> 
> I think it is because in meson.build udev.get_pkgconfig_variable is returning 
> false for udevdir, and the
> udev rules aren't being installed into the correct location.
> 
> udev_rules_dir = udev.get_pkgconfig_variable('udevdir') + '/rules.d'
> 
> 
> Did you have this issue? Do you have any hints, maybe you could add a fix 
> into your patches file?
Oh, indeed, there is a shitty file at the root of the filesystem.

Looks like the packaging already installs another file with different
access rights, and the upstream udev file should be ignored - so perhaps
my patch is wrong and instead (assuming from the comment above it) that
whole section should simply be removed or commented out instead.


> > Also, I do not recommend to include a git hash, because that is not
> > sortable like a date is.  If you ever need to release twice on same day
> > then simply add a .1 suffix.
> 
> I think the git hash is quite nice as it shows where the upstream source 
> actually
> came from. This seems to be a standard all around Debian, is there any 
> official
> notes/guidance you can point me to or is this mainly down to developer choice?
> 
> In any case, for this package, I doubt that upstream will release twice on 
> the same
> day, given that there hasn't been much movement since 2021 ;-). I will be 
> careful to
> make sure I consider this in future.

A version number is for aligning releases on a timeline.  A git hash
serves a different purpose.  Please do not bloat version strings by
adding useless vanity strings to it - mention in the changelog entry
which git hash a new snapshot corresponds to, but avoid embedding it in
the version number.

Others in Debian use vanity strings as well (and I've done so in the
past too), but I disagree that it is standard.
If you really think that it is standard* to include git hash in version
strings, then please point to where that standard is defined.  

I don't think we have strict rules about this, but did find this which
agrees with me in advicing against including git hash in version string:
https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#name-version


> If upstream [...] uses [...] a VCS hash value as part of the version,
> make sure to remove them from the upstream version. Such information
> can be recorded in the debian/changelog file. If you need to invent a
> version string, use the MMDD format such as 20110429 as upstream
> version. This ensures that the dpkg command interprets later versions
> correctly as upgrades. If you need to ensure a smooth transition to a
> normal version scheme such as 0.1 in the future, use the 0~YYMMDD
> format such as 0~110429 as upstream version, instead.


> Would you be able to start another email thread about [rockusb]
> (possibly in a new WNPP bug?) to not pollute this bug.

Sure.

 - 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#1040179: rmlint-gui: invalid Python version number breaks other packages

[Julian Gilbey]

Hi Carlos,

A quick update: I have uploaded 2.9.0-2.4 to DELAYED/7-days.  The
debdiff between -2.3 and -2.4 is attached.

Best wishes,

   Julian

On Tue, Jul 04, 2023 at 04:47:29PM +0100, Julian Gilbey wrote:
> Hi Carlos,
> 
> This package has a grave bug against it as it breaks other packages.
> I'll do an NMU in the next couple of days (uploading to the delayed
> queue) unless you would like to do it yourself.
> 
> Please do let me know!
> 
> Best wishes,
> 
>Julian
> 
> On Tue, Jul 04, 2023 at 10:23:09AM +0100, Julian Gilbey wrote:
> > reassign 1040179 rmlint-gui
> > severity 1040179 grave
> > retitle 1040179 rmlint-gui: invalid Python version number breaks other 
> > packages
> > thanks
> > 
> > On Mon, Jul 03, 2023 at 08:03:58PM -0400, mhaag85893 wrote:
> > > Hi, Julian
> > > 
> > > That worked! Here's the output:
> > 
> > Hi Mike,
> > 
> > Fantastic, thanks!
> > 
> > > Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
> > > Type "help", "copyright", "credits" or "license()" for more 
> > > information.
> > > 
> > > == RESTART: /home/mike/Downloads/check_version_info.py
> > > =
> > > Info file 
> > > /usr/lib/python3/dist-packages/Shredder-2.9.0.Odd.Olm.egg-info has
> > > invalid version  2.9.0 Odd Olm
> > > 
> > > I apt purged rmlint and rmlint-gui followed by an apt autoremove. Then,
> > > restarted Spyder and the error message did not appear.
> > > 
> > > To verify, I reinstalled rmlint and rmlint-gui. Then, restarted Spyder 
> > > which
> > > reproduced the error message.
> > > [...]
> > 
> > OK, so you've located the culprit - thank you for doing this.
> > 
> > > If you want me to try something else, let me know, but it sure looks like 
> > > the
> > > 1040179 bug report can be closed.
> > 
> > No, I won't close it, as it is a major bug in the rmlint-gui package.
> > I'll reassign it there.  Since rmlint has no active maintainer, I'll
> > deal with this myself in the next couple of days.
> > 
> > Best wishes,
> > 
> >Julian
diff -Nru rmlint-2.9.0/debian/changelog rmlint-2.9.0/debian/changelog
--- rmlint-2.9.0/debian/changelog	2021-04-15 22:03:37.0 +0100
+++ rmlint-2.9.0/debian/changelog	2023-07-05 09:31:46.0 +0100
@@ -1,3 +1,11 @@
+rmlint (2.9.0-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix error in other packages caused by invalid python package version
+number (cherry-picking upstream patch; closes: #1040179)
+
+ -- Julian Gilbey   Wed, 05 Jul 2023 09:31:46 +0100
+
 rmlint (2.9.0-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
--- rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch	2020-12-01 18:56:33.0 +
+++ rmlint-2.9.0/debian/patches/0001-fix-link-error-on-compilers-with-fno-common-enabled.patch	2023-07-05 09:31:46.0 +0100
@@ -10,11 +10,9 @@
  lib/config.h.in | 62 ++---
  1 file changed, 33 insertions(+), 29 deletions(-)
 
-diff --git a/lib/config.h.in b/lib/config.h.in
-index 44d7e5d9..d9fdeabd 100644
 --- a/lib/config.h.in
 +++ b/lib/config.h.in
-@@ -121,9 +121,13 @@
+@@ -123,9 +123,13 @@
  #  define N_(String) gettext_noop (String)
  #endif
  
@@ -30,7 +28,7 @@
  
  typedef guint64 RmOff;
  
-@@ -150,33 +154,33 @@ typedef guint64 RmOff;
+@@ -152,33 +156,33 @@
  
  ///
  
@@ -91,6 +89,3 @@
  
  /* Domain for reporting errors. Needed by GOptions */
  #define RM_ERROR_QUARK (g_quark_from_static_string("rmlint"))
--- 
-2.20.1
-
diff -Nru rmlint-2.9.0/debian/patches/python-version-number.patch rmlint-2.9.0/debian/patches/python-version-number.patch
--- rmlint-2.9.0/debian/patches/python-version-number.patch	1970-01-01 01:00:00.0 +0100
+++ rmlint-2.9.0/debian/patches/python-version-number.patch	2023-07-05 09:31:46.0 +0100
@@ -0,0 +1,17 @@
+From: Cebtenzzre
+Subject: gui: use PEP 440-compliant version number
+Origin: upstream, https://github.com/sahib/rmlint/commit/b5a6d9b359b1fc1ea75bdb6c1ae6cbdc0a304ecf
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040179
+
+--- a/gui/setup.py
 b/gui/setup.py
+@@ -14,7 +14,8 @@
+ with open('../.version', 'r') as handle:
+ version_string = handle.read()
+ 
+-return version_string.strip()
++version_numbers, _ = version_string.split(' ', 1)
++return version_numbers
+ 
+ 
+ def get_prefix():
diff -Nru rmlint-2.9.0/debian/patches/series rmlint-2.9.0/debian/patches/series
--- rmlint-2.9.0/debian/patches/series	2021-04-15 22:03:37.0 +0100
+++ rmlint-2.9.0/debian/patches/series	2023-07-05 09:31:46.0 +0100
@@ -8,3 +8,4 @@
 glib-2_62.patch
 0001-fix-link-error-on-compilers-with-fno-common-enabled.patch
 0010-apply-upstream-fix-for-data-loss-bug.patch

Bug#1040423: golang-yaml.v2: Build (tests) fail on 32-bit arch

[Roberto C. Sanchez]

Source: golang-yaml.v2
Version: 2.2.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In working on golang-yaml.v2 for an LTS update, I noticed that the build
fails on 32-bit arch (i386 and armhf, in this specific case).

https://salsa.debian.org/lts-team/packages/golang-yaml.v2/-/pipelines/548358

The specific failure is:

   dh_auto_test -O--buildsystem=golang
cd obj-i686-linux-gnu && go test -vet=off -v -p 2 gopkg.in/yaml.v2
# gopkg.in/yaml.v2_test [gopkg.in/yaml.v2.test]
src/gopkg.in/yaml.v2/decode_test.go:134:33: constant -9223372036854775808 
overflows int
FAILgopkg.in/yaml.v2 [build failed]

The source lines in that vicinity are:

}, {
"bin: 
-0b1000",
map[string]interface{}{"bin": -9223372036854775808},
}, {

The source is the same in the latest version (on the debian/sid branch).

It seems like since the binary packages in this source package are
"Architecture: all" and that since the buildds selected to build
"Architecture: all" packages are 64-bit systems, that this failure is
not one that is encountered in practice for official Debian builds.

However, it might be good to detect when the build is running on a
32-bit system and either not run the tests, or conditionally patch the
source to exclude that particular overflow problem.

Regards,

- -Roberto

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmSlt6UACgkQldFmTdL1
kUK1aBAAxLomEtEKbZN0JlMA0U3BJVBdNpnD+jfyjeVfIJU//mQoWYQKv7JDWh2x
MCC+HmMZ7wgWNdzNR0/VE2BRqTamIYrgmF1gZ7QhiUIZ4UYt+TmNbyK6kb716trO
u4exL5v8r0d7yCdvHgm/GWElg5GlzXz66TEQTOswibRdluTrf6t8441lCZDTGCNE
XZq045nYHSa9NG1HgSbkTlAyzGwZnD2vgxLk27JIEoy8T3zVLP5495NmSkiuK+ig
tnBCyX65POpUa3WFy5XvyxNPjrfv1gNkBhQIRCvRDqt3f04rtNlXPfF0QghWZkC4
CQVGnNA8U1YyUwCQq+TQ/eAxRRVsgJ0Az+gkCtF5iitutnlurLL+QgcTuz6EfKKs
j9NUJzuY8gr71z2Bv+WWRcqwIVlK5+X83Tj3GwfJF8lbpiNib9vqJzo3lLqJU9TS
bw2BgkxZ9SsEZj1U/0NCca6fdHOeRHZpVDBWlB4vpKIwkzNNZVGciAQ1Z79YrFrl
xGqbXJQO2FdF+hh3gDfwlfaMsUMKaJz6hPoHIOC3NBKmCJi6R2hPF+HYmgpVb5cr
C/F9lgO8+N8V6azeU2LO+HDZjV1HQI6T9A2c5gp5NfE8ZNupzSnLC1OUdrJXY36J
t0afOewuYoBC8mGDDZ9TJMV+9DmCsyqwSK3KRANpP1EtsaKW/GQ=
=Waos
-END PGP SIGNATURE-

Bug#1037192: sd: version is lower than in squeeze

[Blair Noctis]

On Wed, 07 Jun 2023 14:12:08 +0200 Andreas Beckmann  wrote:
> Package: sd
> Version: 0.7.6-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> squeeze had a sd binary package built from (unrelated) src:sd at
> version 0.74-1 while bookworm has one built from src:rust-sd at
> version 0.7.6-1 which is lower, violating the archive property of
> monotonically increasing version numbers.
> 
> The highest version of src:sd ever seen in the archive seems to be
> 0.75-1.
> 
> Andreas
> 
> 
Hi Andreas,

TIL about that. Do you think I can use epoch here? Or should I change its name?

(Sorry about the late reply, the email didn't reach me.)

Control: owner -1 !

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040422: RFS: odr-audioenc/3.3.1-1 [ITP] -- DAB and DAB+ encoder that integrates into the ODR-mmbTools

[Robin ALEXANDER]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "odr-audioenc".This is 1 of
the 4 components of the Opendigitalradio DAB broadcasting chain:

 * Package name : odr-audioenc
   Version  : 3.3.1-1
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/mmbtools
 * License  : Apache-2.0, Fraunhofer-FDK-AAC-for-Android,
Expat, GPL-2+ with Autoconf-data exception, GPL-3+ with Autoconf-
2.0~Archive exception, GPL-3.0+, FSFAP, apple-free, LGPL-2.1+, GPL-2.0+
 * Vcs  :
https://github.com/opendigitalradio/debian-audioenc
   Section  : contrib/hamradio

The source builds the following binary packages:

  odr-audioenc - DAB and DAB+ encoder that integrates into the ODR-
mmbTools

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

  https://mentors.debian.net/package/odr-audioenc/

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

  dget -x
https://mentors.debian.net/debian/pool/contrib/o/odr-audioenc/odr-audioenc_3.3.1-1.dsc

Changes for the initial release:

 odr-audioenc (3.3.1-1) unstable; urgency=medium
 .
   * Initial release. Closes: #1008124

Regards,



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

Bug#1040420: RFS: odr-padenc/3.0.0-2 -- This is an encoder for Programme Associated Data

[Robin ALEXANDER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "odr-padenc".This is 1 of the
4 components of the Opendigitalradio DAB broadcasting chain:

 * Package name : odr-padenc
   Version  : 3.0.0-2
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/Mmbtools
 * License  : GPL-3.0+ with autoconf exception, BSL-1.0, GPL-
3.0+, FSFAP, GPL-2+ with Autoconf-data exception
 * Vcs  : https://salsa.debian.org/ralex/odr-padenc
   Section  : hamradio

The source builds the following binary packages:

  odr-padenc - This is an encoder for Programme Associated Data

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

  https://mentors.debian.net/package/odr-padenc/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-padenc/odr-padenc_3.0.0-2.dsc

Changes since the last upload:

 odr-padenc (3.0.0-2) unstable; urgency=low
 .
   * Fix lintian issues

Regards,



smime.p7s
Description: S/MIME cryptographic signature

Bug#1040421: RFS: odr-dabmux/4.4.0-1 -- Digital Audio Broadcasting multiplexer compliant to ETSI EN 300 401

[Robin ALEXANDER]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "odr-dabmux".This is 1 of the
4 components of the Opendigitalradio DAB broadcasting chain:

 * Package name : odr-dabmux
   Version  : 4.4.0-1
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/Mmbtools
 * License  : LGPL-2.1, GPL-3.0+ with autoconf exception,
Apache-2.0, Expat, BSL-1.0, GPL-3.0+, FSFAP, GPL-2.0+
 * Vcs  : https://salsa.debian.org/ralex/odr-dabmux
   Section  : hamradio

The source builds the following binary packages:

  odr-dabmux - Digital Audio Broadcasting multiplexer compliant to ETSI
EN 300 401

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

  https://mentors.debian.net/package/odr-dabmux/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-dabmux/odr-dabmux_4.4.0-1.dsc

Changes since the last upload:

 odr-dabmux (4.4.0-1) unstable; urgency=low
 .
   [ Robin Alexander ]
   * New upstream version 4.4.0

Regards,



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

Bug#1040419: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401

[Robin ALEXANDER]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "odr-dabmod".This is 1 of the
4 components of the Opendigitalradio DAB broadcasting chain:

 * Package name : odr-dabmod
   Version  : 2.6.0-1
   Upstream contact : Matthias P. Braendli 
 * URL  : https://www.opendigitalradio.org/mmbtools
 * License  : GPL-3.0+ with autoconf exception, LGPL-3, Apache-
2.0, EXPAT, BSD-3-Clause, Expat, GPL-3.0+, FSFAP, GPL-2+ with Autoconf-
data exception, GPL-2.0+
 * Vcs  : https://salsa.debian.org/ralex/odr-dabmod
   Section  : hamradio

The source builds the following binary packages:

  odr-dabmod - DAB modulator compliant to ETSI EN 300 401

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

  https://mentors.debian.net/package/odr-dabmod/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-dabmod/odr-dabmod_2.6.0-1.dsc

Changes for the initial release:

 odr-dabmod (2.6.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #1007104

Regards,



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

Bug#1037996: Info received (Bug#1037996: Acknowledgement (xfce4: xfce-Desktop will be crashed at start and than black Desktop))

[Dr. Hanisch]

Hello,
  It doesn’t seem to be working properly/right in Xfce and also in 
KDE-Plasma. I think the problem is in compiz.



with regards
Ch. Hanisch

--
Mein öffentlicher Schlüssel ist auf dem Keyserver 'https://keys.openpgp.org' 
unterch-hani...@t-online.de  (E53DF487)

Bug#1040418: nmu: libheif_1.16.2-1

[Pino Toscano]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: libh...@packages.debian.org, ba...@struktur.de, 
sramac...@debian.org
Control: affects -1 + src:libheif

nmu libheif_1.16.2-1 . ANY . unstable . -m "rebuild on buildd"

Please rebuild libheif (on all architectures, as it has M-A:same
binaries), so it can migrate to testing; kimageformat will need it
soon.

Thanks,
-- 
Pino

Bug#1040417: docker-compose V1 is depreciated.

[Peter Allebone]

Package: docker-compose
Version: 1.29.2-3

As per https://www.docker.com/blog/new-docker-compose-v2-and-v1-deprecation/

Docker V1 is depreciated.
This is still in Sid:
https://tracker.debian.org/pkg/docker-compose

Also this issue is present:
Problems while searching for a new upstream version high
uscan had problems while searching for a new upstream version:

In debian/watch no matching files for watch line
  https://github.com/docker/compose/tags .*/v?(1\S*)\.tar\.gz

Problem is v1 is no longer supported, so v2 should be compiled and used
instead as there is no support from docker-compose developers anymore, yet
latest version (Bookworm) of Debian still uses it.

Is this a problem?

Kind regards

Pete

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Ferenc Wágner]

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

Dear Stable Release Team,

[ Reason ]
Shortly after the release of bookworm we got a report that Pacemaker
regressed in certain migration scenarios when compared to the bullseye
version.  Upstream identified the cause (a bug already fixed in 2.1.6),
and after backporting the fix the submitter acknowledged that they can't
reproduce the bug anymore with the proposed packages.
https://bugs.clusterlabs.org/show_bug.cgi?id=5521
Pacemaker package bug opened after discussion on the mailing list:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040165

[ Impact ]
Core HA functionality is impacted, there's no easy way to work around
the problem.  Pacemaker 2.1.5-1 is unsuitable for big portion of its
intended applications.

[ Tests ]
The submitter tested and confirmed the fix.

[ Risks ]
The patch is small but the backport wasn't trivial due to extensive
refactorings meanwhile.  I asked upstream to sanity-check it, but
haven't got a reply yet.

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

$ debdiff pacemaker_2.1.5-1.dsc pacemaker_2.1.5-1+deb12u1.dsc
diff -Nru pacemaker-2.1.5/debian/changelog pacemaker-2.1.5/debian/changelog
--- pacemaker-2.1.5/debian/changelog2023-01-22 16:38:34.0 +0100
+++ pacemaker-2.1.5/debian/changelog2023-07-02 21:39:59.0 +0200
@@ -1,3 +1,11 @@
+pacemaker (2.1.5-1+deb12u1) bookworm; urgency=medium
+
+  * [20411a8] New patch: Fix: scheduler: handle cleaned migrate_from history
+correctly.
+Thanks to Ken Gaillot (Closes: #1040165)
+
+ -- Ferenc Wágner   Sun, 02 Jul 2023 21:39:59 +0200
+
 pacemaker (2.1.5-1) unstable; urgency=medium

   * [5792d59] Work around lazy loading of GitHub release pages in watch file
diff -Nru pacemaker-2.1.5/debian/gbp.conf pacemaker-2.1.5/debian/gbp.conf
--- pacemaker-2.1.5/debian/gbp.conf 2023-01-22 13:10:39.0 +0100
+++ pacemaker-2.1.5/debian/gbp.conf 2023-07-02 21:39:59.0 +0200
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/bookworm
 upstream-branch = upstream/latest

 [import-orig]
diff -Nru 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
--- 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  1970-01-01 01:00:00.0 +0100
+++ 
pacemaker-2.1.5/debian/patches/Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
  2023-07-02 21:39:59.0 +0200
@@ -0,0 +1,30 @@
+From: Ken Gaillot 
+Date: Wed, 1 Feb 2023 17:12:13 -0600
+Subject: Fix: scheduler: handle cleaned migrate_from history correctly
+
+Fixes T623
+---
+ lib/pengine/unpack.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/lib/pengine/unpack.c b/lib/pengine/unpack.c
+index 5fcba3b..abfd06f 100644
+--- a/lib/pengine/unpack.c
 b/lib/pengine/unpack.c
+@@ -2920,6 +2920,16 @@ unpack_migrate_to_success(pe_resource_t *rsc, pe_node_t 
*node, xmlNode *xml_op,
+ }
+
+ } else { // Pending, or complete but erased
++
++/* If there is no history at all for the resource on an online 
target, then
++ * it was likely cleaned. Just return, and we'll schedule a probe. 
Once we
++ * have the probe result, it will be reflected in target_newer_state.
++ */
++if ((target_node != NULL) && target_node->details->online
++&& unknown_on_node(rsc->id, target, data_set)) {
++return;
++}
++
+ /* If the resource has newer state on the target, this migrate_to no
+  * longer matters for the target.
+  */
diff -Nru pacemaker-2.1.5/debian/patches/series 
pacemaker-2.1.5/debian/patches/series
--- pacemaker-2.1.5/debian/patches/series   2023-01-22 13:31:42.0 
+0100
+++ pacemaker-2.1.5/debian/patches/series   2023-07-02 21:39:59.0 
+0200
@@ -5,3 +5,4 @@
 Shipping-the-CTS-is-not-useful.patch
 Always-run-Inkscape-under-the-C.UTF-8-locale.patch
 Fix-typos-resouce-resource.patch
+Fix-scheduler-handle-cleaned-migrate_from-history-correct.patch
diff -Nru pacemaker-2.1.5/debian/salsa-ci.yml 
pacemaker-2.1.5/debian/salsa-ci.yml
--- pacemaker-2.1.5/debian/salsa-ci.yml 2023-01-22 13:10:39.0 +0100
+++ pacemaker-2.1.5/debian/salsa-ci.yml 2023-07-02 21:39:59.0 +0200
@@ -5,6 +5,7 @@

 variables:
   SALSA_CI_REPROTEST_ENABLE_DIFFOSCOPE: 1
+  RELEASE: bookworm

 autopkgtest:
   extends: .test-autopkgtest
-- 
Thanks,
Feri.

Bug#1034348: at: autopkgtest regression on arm64

[Johannes Christ]

Dear maintainer(s),

I saw the autoremoval notice for 11th July on the Debian Package
Tracker. Hope this is the right place to respond.

I use `at` regularly and would be sad to see it being removed from the
Debian repositories. Unfortunately I have not been able to reproduce
this issue locally via `autopkgtest` via `qemu`, because `autopkgtest`
fails to start with ARM64 architecture. For my native architecture, it
passes. I receive the following output:

$ autopkgtest-build-qemu stable stable --architecture arm64
[...]
$ autopkgtest -B . -- qemu stable --qemu-architecture arm
autopkgtest [18:53:51]: starting date and time: 2023-07-05 18:53:51+0200
autopkgtest [18:53:51]: version 5.28
autopkgtest [18:53:51]: host box; command line: /usr/bin/autopkgtest -B . 
-- qemu stable --qemu-architecture arm
qemu-system-arm: terminating on signal 15 from pid 115560 (/usr/bin/python3)
: failure: timed out waiting for 'login prompt on serial 
console'
autopkgtest [18:54:52]: ERROR: testbed failure: unexpected eof from the 
testbed

Is there another way to reproduce this issue? I would be happy for any
pointers as I'd like to help keep `at` in the Debian repositories.


Thank you
Johannes Christ

Bug#1040371: bind9 exits with ABRT/dumps core during/after AXFR

[Sean Brackeen]

Hello, this was an end user configuration issue and is not a bug and may be 
closed. Apologies


Sean Brackeen 

-Original Message-
From: Ondřej Surý  
Sent: Tuesday, July 4, 2023 10:35 PM
To: Sean Brackeen ; 1040...@bugs.debian.org
Subject: Re: Bug#1040371: bind9 exits with ABRT/dumps core during/after AXFR

Sean,

can you report this to upstream (gitLab.isc.org)? This would be better handled 
there. Open a new issue, mark it as confidential and we will need at least a 
coredump. Reproducer would be even better.

Ondřej
--
Ondřej Surý  (He/Him)

> On 5. 7. 2023, at 6:36, Sean Brackeen  wrote:
> 
> This is now affecting both slave servers. [ESXi 8 and a server at a cloud 
> hosting provider] I tried turning off extra options [stats, dnssec] and 
> removing recently created zones, with no change. I also tried setting the 
> slaves to write the zone files as text instead of binary with no change. 
> 
> 
> Sean Brackeen
> Sr. Systems Engineer
> +1 (858) 257-0164 (office)
> +1 (619) 534-5789 (mobile)
> 
> Robbins Research International
> 5230 Carroll Canyon Rd. Suite 306, San Diego, CA 92121 "It’s not the 
> events of your life that determine how you feel, but the way you 
> interpret those experiences."  -Tony Robbins
> 
> -Original Message-
> From: sean.brackeen 
> Sent: Tuesday, July 4, 2023 7:58 PM
> To: Debian Bug Tracking System 
> Subject: Bug#1040371: bind9 exits with ABRT/dumps core during/after 
> AXFR
> 
> Package: bind9
> Version: 1:9.18.16-1~deb12u1
> Severity: important
> X-Debbugs-Cc: sean.brack...@tonyrobbins.com
> 
> Dear Maintainer,
> 
> 
>   * What led up to the situation?
> Configured a new set of bind9 servers accepting AXFR transfers from a main 
> server
>   * What exactly did you do (or not do) that was effective (or
> ineffective)?
> Started adding additional domains to the server from the master, as they 
> started syncing this server suddenly dumped core as it started accepting AXFR 
> transfers from upstream
>   * What was the outcome of this action?
> The bind9 daemon crashes repeatedly when you start it or restart the server
>   * What outcome did you expect instead?
> BIND should be able to accept zone transfers reliably.
> 
> Platform is VMware ESXi, 8.0.1, 21495797 - No exceptions float up to 
> the VM itself or the VM host - The master server on ESXi 7 does not 
> abrt
> 
> Jul 04 19:33:22 fmt2-ns2 named[1330]: transfer of 'snip' from snip: Transfer 
> status: success Jul 04 19:33:22 fmt2-ns2 named[1330]: transfer of 'snip' from 
> snip: Transfer completed: 1 messages, 15 records, 495 bytes, 0.012 secs 
> (41250 bytes/sec) (serial 2023070401) Jul 04 19:33:22 fmt2-ns2 named[1330]: 
> zone snip: sending notifies (serial 2023070401) Jul 04 19:33:22 fmt2-ns2 
> systemd[1]: Created slice system-systemd\x2dcoredump.slice - Slice 
> /system/systemd-coredump.
> Jul 04 19:33:22 fmt2-ns2 systemd[1]: Started 
> systemd-coredump@0-1338-0.service - Process Core Dump (PID 1338/UID 0).
> Jul 04 19:33:22 fmt2-ns2 systemd-coredump[1339]: [] Process 1330 (named) of 
> user 102 dumped core.
> 
> Module libnss_systemd.so.2 
> from deb systemd-252.6-1.amd64
> Module libsystemd.so.0 from 
> deb systemd-252.6-1.amd64
> Stack trace of thread 1331:
> #0  0x7faebe4fdccc n/a 
> (libc.so.6 + 0x8accc)
> #1  0x7faebe4aeef2 raise 
> (libc.so.6 + 0x3bef2)
> #2  0x7faebe499472 abort 
> (libc.so.6 + 0x26472)
> #3  0x7faebf85a195 n/a 
> (libuv.so.1 + 0x9195)
> #4  0x7faebe500e37 n/a 
> (libc.so.6 + 0x8de37)
> #5  0x7faebf86de49 
> uv_once (libuv.so.1 + 0x1ce49)
> #6  0x7faebf85c521 
> uv_queue_work (libuv.so.1 + 0xb521)
> #7  0x7faebf22646e 
> isc_nm_work_offload (libisc-9.18.16-1~deb12u1-Debian.so + 0x2646e)
> #8  0x7faebee86c88 n/a 
> (libdns-9.18.16-1~deb12u1-Debian.so + 0x86c88)
> #9  0x7faebf2588e3 
> isc_task_run (libisc-9.18.16-1~deb12u1-Debian.so + 0x588e3)
> #10 0x7faebf226c92 n/a 
> (libisc-9.18.16-1~deb12u1-Debian.so + 0x26c92)
> #11 0x7faebf227317 n/a 
> (libisc-9.18.16-1~deb12u1-Debian.so + 0x27317)
> #12 0x7faebf227e53 n/a 
> (libisc-9.18.16-1~deb12u1-Debian.so + 0x27e53)
> #13 0x7faebf86009d n/a 
> (libuv.so.1 + 

Bug#1039872: Improve firmware package inclusion

[Pascal Hambourg]

On 05/07/2023 at 17:55, Steve McIntyre wrote:

On Wed, Jul 05, 2023 at 08:30:03AM +0200, Pascal Hambourg wrote:


As mentioned in #1032071, AFAICS firmware-ti-connectivity also contains
ARM-only firmware.


Hmmm, OK. The description isn't 100% clear here.


Indeed. I came to this conclusion after checking that the modules 
mentioned in the description were present only in ARM kernel-image packages.

Bug#1040140: libc6: upgrade libc6 to version 2.37-3 break plasma desktop (X11/Wayland)

[Aurelien Jarno]

Hi,

On 2023-07-05 12:55, Antonio wrote:
> Hi,
> 
> I tried the workarounds: they work, however I had left the system with
> overcommit memory 0 (default), since it seemed to be resolved.
> 
> This morning, however, I detected a problem relating to memory (the first
> time I see an OOM-Killer recall process) following an extreme slowdown in
> the system; and I think it could be related to this problem.
> 
> lug 05 12:35:27 kernel: kswapd0 invoked oom-killer:
> gfp_mask=0xcc0(GFP_KERNEL), order=0, oom_score_adj>
> lug 05 12:35:27 kernel: Hardware name: Dell Inc. Precision T1600/06NWYK,
> BIOS A10 02/21/2012
> lug 05 12:35:27 kernel: Mem-Info:
> lug 05 12:35:27 kernel: active_anon:2283373 inactive_anon:768638
> isolated_anon:0
>  active_file:5800 inactive_file:5241
> isolated_file:0
>  unevictable:39 dirty:52 writeback:0
>  slab_reclaimable:17302
> slab_unreclaimable:55651
>  mapped:10150 shmem:3002 pagetables:19384
>  sec_pagetables:0 bounce:0
>  kernel_misc_reclaimable:0
>  free:34007 free_pcp:109 free_cma:0
> lug 05 12:35:27 kernel: Node 0 active_anon:9133492kB inactive_anon:3074552kB
> active_file:23200kB inact>
> lug 05 12:35:27 kernel: DMA free:13312kB boost:0kB min:60kB low:72kB
> high:84kB reserved_highatomic:0KB>
> lug 05 12:35:27 kernel: lowmem_reserve[]: 0 3133 15872 15872
> lug 05 12:35:27 kernel: DMA32 free:64276kB boost:0kB min:13328kB low:16660kB
> high:19992kB reserved_hig>
> lug 05 12:35:27 kernel: lowmem_reserve[]: 0 0 12739 12739

Are you sure this is related? From what I have seen the issue increases
the *virtual* memory consumption, but no the memory consumption, so I
don't think that it should trigger the oom killer.

> In my opinion, to avoid stability problems, I think it is preferable to
> perform the revert of the indicated commit, until all any repercussions are
> clarified (rather than configuring the desktops with overrtcommit memory 1).
> 
> What do you think?

There is a patch being discussed upstream [1], the plan is to include it
once it is committed upstream. I also have to check with the release
team if we should delay the transition to testing with another upload,
or upload the fix just after it got migrated.

Regards
Aurelien

[1] https://marc.info/?l=glibc-alpha=168849505714289=3

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

Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons

[g1pi]

On Wed, Jul 05, 2023 at 06:36:23PM +0200, Thorsten Glaser wrote:
> On Wed, 5 Jul 2023, g...@libero.it wrote:
> 
> This is bad. Let’s ask the debhelper maintainers why this
> is no longer present, as the absence breaks orphan-sysvinit-scripts.
> 

I'm not sure that breaks o-s-s.

o-s-s has a trigger on /lib/systemd/system/rsyslog.service, therefore it
gets triggered when the package is upgraded to do its stuff w.r.t. the
init script, if necessary.

But it should also invoke-rc.d  try-restart, for perfection.

Bug#1040357: conky-all: Stack trace of thread 4760

[Tim McConnell]

On Wed, 2023-07-05 at 08:22 -0700, Vincent Cheng wrote:
> On Tue, Jul 4, 2023 at 12:51 PM Tim McConnell
>  wrote:
> > 
> > Package: conky-all
> > Version: 1.18.3-1
> > Severity: normal
> > 
> > Stack trace of thread 4760:
> > 
> >   #0 
> > 0x7f2a0c8a2ccc
> > __pthread_kill_implementation (libc.so.6 + 0x8accc)
> >   #10
> > 0x565224f2323a n/a
> > (conky + 0x8423a)
> >   #1 
> > 0x7f2a0c853ef2
> > __GI_raise (libc.so.6 + 0x3bef2)
> >   #11
> > 0x565224f24abf n/a
> > (conky + 0x85abf)
> >   #12
> > 0x565224f24e35 n/a
> > (conky + 0x85e35)
> >   #13
> > 0x565224f28275 n/a
> > (conky + 0x89275)
> >   #14
> > 0x565224f06897 n/a
> > (conky + 0x67897)
> >   #15
> > 0x565224f074af n/a
> > (conky + 0x684af)
> >   #16
> > 0x565224ecf1bc n/a
> > (conky + 0x301bc)
> >   #17
> > 0x565224ebdb74 main
> > (conky + 0x1eb74)
> >   #18
> > 0x7f2a0c83f18a
> > __libc_start_call_main (libc.so.6 + 0x2718a)
> >   #19
> > 0x7f2a0c83f245
> > __libc_start_main_impl (libc.so.6 + 0x27245)
> >   #20
> > 0x565224ec4261 n/a
> > (conky + 0x25261)
> >   #2 
> > 0x7f2a0c83e472
> > __GI_abort (libc.so.6 + 0x26472)
> >   #3 
> > 0x565224f23497 n/a
> > (conky + 0x84497)
> >   #4 
> > 0x7f2a0d7a699b
> > _XError (libX11.so.6 + 0x4699b)
> >   #5 
> > 0x7f2a0d7a3607 n/a
> > (libX11.so.6 + 0x43607)
> >   #6 
> > 0x7f2a0d7a36a5 n/a
> > (libX11.so.6 + 0x436a5)
> >   #7 
> > 0x7f2a0d7a47fd
> > _XReply (libX11.so.6 + 0x447fd)
> >   #8 
> > 0x7f2a0d78a8eb
> > _XGetWindowAttributes (libX11.so.6 + 0x2a8eb)
> >   #9 
> > 0x7f2a0d78aa49
> > XGetWindowAttributes (libX11.so.6 + 0x2aa49)
> >   ELF object binary
> > architecture: AMD x86-64
> > I'm happy to give additional information just ask and give clear
> > directions.
> 
> Please report this directly to upstream's bug tracker at
> https://github.com/brndnmtthws/conky/issues, thanks!
> 
> Regards,
> Vincent

GITHUB Bug # Stack trace of thread 4760 #1586 

Bug#1040414: RM: python3-instagram -- ROM; archived upstream, dead, depends on proprietary API

[Alexandre Detiste]

Package: ftp.debian.org
Severity: normal
User: python3-...@packages.debian.org
Usertags: python3-six-removal
X-Debbugs-Cc: python-instag...@packages.debian.org, Petter Reinholdtsen 

Control: affects -1 + src:python-instagram


Please now remove the package as proposed by maintainer in #1031258.

Greetings

> [Ross Gammon]
> > Thanks for doing this. Removal from unstable is the right thing to do
> > I think.
>
> No-one objected so far, so I guess that is the way we play it.  Some
> time after 2023-03-14 someone should file for removal unless a new
> maintainer (and perhaps a new upstream) show up very soon.
>
> --
> Happy hacking
> Petter Reinholdtsen

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

Bug#1040413: dumb-init: implicitly depends on python3-py

[Timo Röhling]

Source: dumb-init
Version: 1.2.5-2
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package implicitly depends on python3-py for its autopkgtest, which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest and possibly your package.


Cheers
Timo


Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dumb-init/35335671/log.gz

 26s  ERRORS 

 26s  ERROR collecting tests/child_processes_test.py 

 26s ImportError while importing test module 
'/tmp/autopkgtest-lxc.1lxwtg1o/downtmp/build.ufI/src/tests/child_processes_test.py'.
 26s Hint: make sure your test modules/packages have valid Python names.
 26s Traceback:
 26s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
 26s return _bootstrap._gcd_import(name[level:], package, level)
 26s tests/child_processes_test.py:10: in 
 26s from testing import is_alive
 26s testing/__init__.py:11: in 
 26s from py._path.local import LocalPath
 26s E   ModuleNotFoundError: No module named 'py._path'; 'py' is not a package
 26s  ERROR collecting tests/proxies_signals_test.py 

 26s ImportError while importing test module 
'/tmp/autopkgtest-lxc.1lxwtg1o/downtmp/build.ufI/src/tests/proxies_signals_test.py'.
 26s Hint: make sure your test modules/packages have valid Python names.
 26s Traceback:
 26s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
 26s return _bootstrap._gcd_import(name[level:], package, level)
 26s tests/proxies_signals_test.py:7: in 
 26s from testing import NORMAL_SIGNALS
 26s testing/__init__.py:11: in 
 26s from py._path.local import LocalPath
 26s E   ModuleNotFoundError: No module named 'py._path'; 'py' is not a package
 26s ___ ERROR collecting tests/shell_background_test.py 

 26s ImportError while importing test module 
'/tmp/autopkgtest-lxc.1lxwtg1o/downtmp/build.ufI/src/tests/shell_background_test.py'.
 26s Hint: make sure your test modules/packages have valid Python names.
 26s Traceback:
 26s /usr/lib/python3.11/importlib/__init__.py:126: in import_module
 26s return _bootstrap._gcd_import(name[level:], package, level)
 26s tests/shell_background_test.py:6: in 
 26s from testing import print_signals
 26s testing/__init__.py:11: in 
 26s from py._path.local import LocalPath
 26s E   ModuleNotFoundError: No module named 'py._path'; 'py' is not a package
 26s === warnings summary 
===
 26s 
../../../../../usr/lib/python3/dist-packages/_pytest/config/__init__.py:1373
 26s   /usr/lib/python3/dist-packages/_pytest/config/__init__.py:1373: 
PytestConfigWarning: Unknown config option: timeout
 26s   
 26s self._warn_or_fail_if_strict(f"Unknown config option: {key}\n")
 26s 
 26s -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
 26s === short test summary info 

 26s ERROR tests/child_processes_test.py
 26s ERROR tests/proxies_signals_test.py
 26s ERROR tests/shell_background_test.py
 26s !!! Interrupted: 3 errors during collection 

 26s = 1 warning, 3 errors in 0.11s 
=
 26s autopkgtest [13:22:51]: test command1: ---]
 26s autopkgtest [13:22:51]: test command1:  - - - - - - - - - - results - - - 
- - - - - - -
 26s command1 FAIL non-zero exit status 2
 27s autopkgtest [13:22:52]:  summary


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSlnK0ACgkQ+C8H+466
LVlaGQv/dl6NFSQQThyjeBbXQTOPl/bNYSI/Z5zidx0bwYqdVvMixMthSD4SFSwB
ZlTG8UuXeGtanlu9M92HvYNnhM8632BFgaJih7LUSi1Po0Su5sJ23o25CTXXng8S
+XnarYW2ObjF7Q+HO3ImnIVekA7pcvMkXD1DZVwQGUK2/kuhxWGP/aV+2r02ttY0
t5XTS0aUF8iK9bzMs/aGf0QAygUKGfV11u23O8+VMacdycyfWrkZF1uqfAv+3IgN
WSmEAAum5ckQwXYCQiOcmzGODVSHypBSnAZ47CV65iBSb/vK62+1ktW7CBRdyNEj
sOwNaIXq00ZCbyV2N2gMPb4Ye/x8FLgZpXDGegkdcJ746lcQSaKFJ1H5VXOTPjCS
TyYt7v5KmxKrIB41Z4N1g8PCCXGeq59e14mQ6RbAfinjnnm2jTt7hMtLklcvndRA
27bb+VSJBKtcVMIEPIZfhFvF8acHHhy6/gOfRF6YGWV/2KSD8RYsXzrG/ydRwaWi
eHYohOPv
=nA09
-END PGP SIGNATURE-

Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons

[Thorsten Glaser]

On Wed, 5 Jul 2023, g...@libero.it wrote:

>The section
>
>> # Automatically added by dh_installinit/13.3.4
>> if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
>> "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
>> if [ -x "/etc/init.d/rsyslog" ]; then
>> update-rc.d rsyslog defaults >/dev/null
>> if [ -n "$2" ]; then
>> _dh_action=restart
>> else
>> _dh_action=start
>> fi
>> invoke-rc.d --skip-systemd-native rsyslog $_dh_action || 
>> exit 1
>> fi
>> fi
>
>which used to restart the daemon on package upgrade in bullseye/sysvinit,
>disappeared from rsyslog.postinst in bookworm.  Therefore, no restart
>happens unless systemd is in control.

This is bad. Let’s ask the debhelper maintainers why this
is no longer present, as the absence breaks orphan-sysvinit-scripts.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1040412: django-q: implicitly depends on python3-pkg-resources

[Timo Röhling]

Source: django-q
Version: 1.3.9-4
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package implicitly depends on python3-pkg-resources for its autopkgtest, 
which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest and possibly your package.


Cheers
Timo


Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/d/django-q/35335654/log.gz

 29s autopkgtest [13:19:54]: test python3-django-q: [---
 30s Traceback (most recent call last):
 30s   File "", line 198, in _run_module_as_main
 30s   File "", line 88, in _run_code
 30s   File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 5, in 

 30s raise SystemExit(pytest.console_main())
 30s  ^
 30s   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 
189, in console_main
 30s code = main()
 30s^^
 30s   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 
147, in main
 30s config = _prepareconfig(args, plugins)
 30s  ^
 30s   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 
328, in _prepareconfig
 30s config = pluginmanager.hook.pytest_cmdline_parse(
 30s  
 30s   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in 
__call__
 30s return self._hookexec(self.name, self.get_hookimpls(), kwargs, 
firstresult)
 30s

 30s   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in 
_hookexec
 30s return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
 30s^
 30s   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 55, in 
_multicall
 30s gen.send(outcome)
 30s   File "/usr/lib/python3/dist-packages/_pytest/helpconfig.py", line 103, 
in pytest_cmdline_parse
 30s config: Config = outcome.get_result()
 30s  
 30s   File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 60, in 
get_result
 30s raise ex[1].with_traceback(ex[2])
 30s   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39, in 
_multicall
 30s res = hook_impl.function(*args)
 30s   ^
 30s   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 
1075, in pytest_cmdline_parse
 30s self.parse(args)
 30s   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 
1425, in parse
 30s self._preparse(args, addopts=addopts)
 30s   File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 
1327, in _preparse
 30s self.hook.pytest_load_initial_conftests(
 30s   File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in 
__call__
 30s return self._hookexec(self.name, self.get_hookimpls(), kwargs, 
firstresult)
 30s

 30s   File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in 
_hookexec
 30s return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
 30s^
 30s   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 60, in 
_multicall
 30s return outcome.get_result()
 30s
 30s   File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 60, in 
get_result
 30s raise ex[1].with_traceback(ex[2])
 30s   File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39, in 
_multicall
 30s res = hook_impl.function(*args)
 30s   ^
 30s   File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 353, 
in pytest_load_initial_conftests
 30s _setup_django()
 30s   File "/usr/lib/python3/dist-packages/pytest_django/plugin.py", line 236, 
in _setup_django
 30s django.setup()
 30s   File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in 
setup
 30s apps.populate(settings.INSTALLED_APPS)
 30s   File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 91, 
in populate
 30s app_config = AppConfig.create(entry)
 30s  ^^^
 30s   File "/usr/lib/python3/dist-packages/django/apps/config.py", line 124, 
in create
 30s mod = import_module(mod_path)
 30s   ^^^
 30s   File "/usr/lib/python3.11/importlib/__init__.py", line 126, in 
import_module
 30s return _bootstrap._gcd_import(name[level:], package, level)
 30s
 30s   File "", line 1204, in _gcd_import
 30s   File "", line 1176, in _find_and_load
 30s   File "", line 1147, in 

Bug#1040411: cloudpickle: implicitly depends on python3-py

[Timo Röhling]

Source: cloudpickle
Version: 2.2.0-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package implicitly depends on python3-py for its autopkgtest, which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest and possibly your package.


Cheers
Timo

Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cloudpickle/35335619/log.gz

 57s === FAILURES 
===
 57s __ CloudPickleTest.test_dynamic_pytest_module 
__
 57s 
 57s self = 
 57s 
 57s def test_dynamic_pytest_module(self):
 57s # Test case for pull request 
https://github.com/cloudpipe/cloudpickle/pull/116
 57s import py
 57s 
 57s def f():
 57s s = py.builtin.set([1])
 57s return s.pop()
 57s 
 57s # some setup is required to allow pytest apimodules to be correctly
 57s # serializable.
 57s from cloudpickle import CloudPickler
 57s from cloudpickle import cloudpickle_fast as cp_fast
 57s >   CloudPickler.dispatch_table[type(py.builtin)] = 
cp_fast._module_reduce
 57s E   AttributeError: module 'py' has no attribute 'builtin'
 57s 
 57s tests/cloudpickle_test.py:1511: AttributeError
 57s _ Protocol2CloudPickleTest.test_dynamic_pytest_module 
__
 57s 
 57s self = 
 57s 
 57s def test_dynamic_pytest_module(self):
 57s # Test case for pull request 
https://github.com/cloudpipe/cloudpickle/pull/116
 57s import py
 57s 
 57s def f():
 57s s = py.builtin.set([1])
 57s return s.pop()
 57s 
 57s # some setup is required to allow pytest apimodules to be correctly
 57s # serializable.
 57s from cloudpickle import CloudPickler
 57s from cloudpickle import cloudpickle_fast as cp_fast
 57s >   CloudPickler.dispatch_table[type(py.builtin)] = 
cp_fast._module_reduce
 57s E   AttributeError: module 'py' has no attribute 'builtin'
 57s 
 57s tests/cloudpickle_test.py:1511: AttributeError


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSlm24ACgkQ+C8H+466
LVlU6Av+KKawZFAKAKDGrioumWCdsqdisVQ/md2t2b66xX8RPhpZS4ZEHGqZ7uPM
oJiBT0VU6HgrNyqC3P1strL+25tHTvf+9f9phcfew+tYM8EtiIcOjXZI3MeloAYN
TVJ3dhrua1UCpmTMlBgBbRYH3BWn5bUs6SY9hNmPUaZCeqIdoTmDb8RseGVJuYIo
Q+y/NB40znT9NFKrYxaPI1jg1deDmh3pjXTjFm6K6MuCAEq4iq3f3NhjcgLEOTkg
x7gdOv95uu5ne54Tdvj1YsVxgaKvKv+UHv4SGDMZsR7PKt8aHOsWWXWpUjSVMwEt
hi0fgUbs0I8MBO8OjZSh8WYbPG/utaTNwZDytm24ESeH4TcLRRB9HSN+tpLxNR7v
5JW1YwMESn6QBddQYR4LW29rIQ0Nd1azFLs9/tsKRS2nGYIXLXD24SunO8ruf18S
53SD8ms7B5kCH+WQZ7Js+oFtAe38phDCjtLKHYgbxEn6Vl++3inIOiWjZiKnj2Cq
Gnc1dGVe
=IgN6
-END PGP SIGNATURE-

Bug#1040234: Acknowledgement (plasma-systemmonitor: graphical artefacts with nouveau kernel module)

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=471979

Bug#1040410: apipkg: implicitly depends on python3-py

[Timo Röhling]

Source: apipkg
Version: 3.0.1-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package implicitly depends on python3-py for its autopkgtest, which used
to be provided by python3-pytest. However, pytest has dropped that dependency,
breaking your autopkgtest and possibly your package.


Cheers
Timo


Relevant excerpt from
https://ci.debian.net/data/autopkgtest/testing/amd64/a/apipkg/35335565/log.gz

 48s  test_get_distribution_version 
_
 48s 
 48s def test_get_distribution_version():
 48s assert apipkg.distribution_version("setuptools") is not None
 48s assert apipkg.distribution_version("email") is None
 48s >   assert apipkg.distribution_version("py") is not None
 48s E   AssertionError: assert None is not None
 48s E+  where None = ('py')
 48s E+where  = 
apipkg.distribution_version
 48s 
 48s test_apipkg.py:835: AssertionError
 48s === short test summary info 

 48s FAILED test_apipkg.py::test_get_distribution_version - AssertionError: 
assert...
 48s !! stopping after 1 failures 
!!



-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSlmqgACgkQ+C8H+466
LVnKvwwAoNfshLm6xFRosI5K+BnlvoaJWF2oZ//PQ2q/fE74lILhxpnX3tpFZC8F
cWSl2tpACHNdbZKA/Urmw+Bd9bkezOY4j3cQSerGQOyXujIhM1CRawMy2lpR6r9Y
jPTWlzCWkOdswDaHhxG3IKK07qh6tN7uCd36N/2x4+GKPyXrBRROsrQb/VcdVWwl
nCFhEAydrc8fBb/VMbeFGzPVL96ckkeGKbE7mOKzEK9gFu6R0rz3+ry0Cgu5CHi8
b8VqcA0pV7AK397oHQiTXmFTxdfOSHsXhMfdtJOXVwgUYPYjfl1KOynsoHDz9f1k
q6sgygJbrQW4s9I6UtMqlhAsp+C7S1Jxn/TknBDPJjaod0tMFNG+awXgPYmQCNXy
1iqBDkbYZWhQrfEi8GslKAI/bJw8ePF0eJFAJwUgorE5FOhZbN93ftbbaYJY3mqK
BaQ+8cWQyuALT5Wnmx0fXamAuykuBGKIOYEFZnUU1UANTlZFFvgBL6UST3JefxBe
3YHj8qZf
=ciOV
-END PGP SIGNATURE-

Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons

[g1pi]

On Wed, Jul 05, 2023 at 04:39:33PM +0100, Matthew Vernon wrote:
>
> I'd normally expect a package postinst to
> invoke-rc.d or similar.
> 

Me too.  But Bookworm disagrees.  Release Notes don't even mention that
rsyslogd does not start at boot anymore unless you use systemd.

The section

> # Automatically added by dh_installinit/13.3.4
> if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
> "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
> if [ -x "/etc/init.d/rsyslog" ]; then
> update-rc.d rsyslog defaults >/dev/null
> if [ -n "$2" ]; then
> _dh_action=restart
> else
> _dh_action=start
> fi
> invoke-rc.d --skip-systemd-native rsyslog $_dh_action || exit 
> 1
> fi
> fi

which used to restart the daemon on package upgrade in bullseye/sysvinit,
disappeared from rsyslog.postinst in bookworm.  Therefore, no restart
happens unless systemd is in control.

Rsyslog's maintainer has dropped support for sysvinit and I'm afraid he is
not going to reconsider any time soon (see #1037039).

Since o-s-s already handles start of the daemon and log rotation, it might
the right package to also handle upgrades, at least for selected daemons.

Best regards,
g.b.

Bug#1039724: gpgme: building underbookworm fails with no matches in python3-gpg.install

[Andreas Metzler]

On 2023-07-04 Ted  wrote:
> The only software which has ever run here is from a bookworm or vscodim
> repo so i will just wait for bookworm to stabilize and hope i can abandon
> the workarounds in the future.

Hello,

You were right all the time. python3-setuptools is the culprit,
installing it breaks the build.

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

Bug#1040032: rkdeveloptool: please switch to newer Pine64 fork

[Christopher Obbard]

Hi Jonas,

On Tue, 2023-07-04 at 17:06 +0200, Jonas Smedegaard wrote:
> Hi Cristopher,
> 
> Quoting Christopher Obbard (2023-07-04 16:01:19)
> > On Sat, 2023-07-01 at 11:07 +0200, Jonas Smedegaard wrote:
> > > I own a PineNote, and use rkdeveloptool for flashing software onto it,
> > > but have found the code in Debian to be inferior for that use.
> > > 
> > > Please consider switching to the (slightly) newer fork done by Pine64,
> > > which fixes some bugs and improves the user interface, while seemingly
> > > fully preserving backwards compatibility:
> > > https://gitlab.com/pine64-org/quartz-bsp/rkdeveloptool
> > > 
> > > What I use now is a fork of this package, maintained here:
> > > https://salsa.debian.org/js/rkdeveloptool
> > > 
> > > If you like, I can push that into the official Salsa packaging git -
> > > or you can cherry-pick the bits you like from it, of course. :-)
> > 
> > I'm fine with picking your patches to the packaging and changing the
> > upstream source to this (backwards-compatible) version & uploading a new
> > version.
> > 
> > One question is what do we do about the version? Currently we are tracking
> > the upstream source from rockchip 
> > https://github.com/rockchip-linux/rkdeveloptool which
> > is at version 1.32+git20210408.46bb4c0 but the Pine64 version is at 
> > currently tagged at
> > version 1.1.0 which is much lower. I wonder if I should do something like 
> > tag the new
> > upstream source version with an epoch, like 2:1.1.0 ?
> > 
> > The policy states that prepending an epoch to a pacakge version needs some
> > additional consensus from debian-devel:
> > > You should not change the epoch, even in experimental, without getting
> > > consensus on debian-devel first.
> > 
> > so I have therefore CC the list to this bug, to see if my thinking is 
> > correct :-)
> 
> Since none of these forks apparently is actively developed, I suggest to
> not take any strong action like introducing an epoch, but instead simply
> add a + to indicate that current situation is a mess - which it is:
> 
>   1.32+pine64.20210904

Right, I have done this and pushed my (unreleased) changes to 
https://salsa.debian.org/debian/rkdeveloptool/-/commits/wip%2Fobbardc%2Fpine64

Lintian complains about the following in my unstable pbuilder:
E: rkdeveloptool: non-standard-toplevel-dir [rules.d/]
W: rkdeveloptool: file-in-unusual-dir [rules.d/99-rk-rockusb.rules]

I think it is because in meson.build udev.get_pkgconfig_variable is returning 
false for udevdir, and the
udev rules aren't being installed into the correct location.

udev_rules_dir = udev.get_pkgconfig_variable('udevdir') + '/rules.d'


Did you have this issue? Do you have any hints, maybe you could add a fix into 
your patches file?


> Also, I do not recommend to include a git hash, because that is not
> sortable like a date is.  If you ever need to release twice on same day
> then simply add a .1 suffix.

I think the git hash is quite nice as it shows where the upstream source 
actually
came from. This seems to be a standard all around Debian, is there any official
notes/guidance you can point me to or is this mainly down to developer choice?

In any case, for this package, I doubt that upstream will release twice on the 
same
day, given that there hasn't been much movement since 2021 ;-). I will be 
careful to
make sure I consider this in future.

> 
> > Note that also we have written a replacement tool in Rust called rockusb
> > (which allows you to write an image with holes to the device, which can
> > speed up the flashing), packaging this in Debian is also on my the wishlist:
> > https://github.com/collabora/rockchiprs/tree/main
> 
> Ohh, that looks very nice!
> 
> D you prefer to package that yourself?  I am on a
> package-cool-rust-stuff frenzy and can offer to do the packaging of that
> tool if you like.  Then we can maintain it together, but easiest for me
> is that I simply do the bootstrapping myself.

I would love to do more Rust packaging in Debian, but I really am out of time
to do that work currently. I looked at the dependency tree and it seems like
it would be a number of packages.

I am able to help maintain the additional package(s).

Would you be able to start another email thread about that (possibly in a new
WNPP bug?) to not pollute this bug.


Thanks!

Chris

Bug#1040407: linux-image-6.3.0-1-amd64: X1 Carbon 9th gen, docked, external display stops working after suspend and there are kernel traces in the logs

[Diederik de Haas]

On Wednesday, 5 July 2023 17:54:00 CEST Claudio Saavedra wrote:
> According to https://www.spinics.net/lists/linux-usb/msg242489.html
> this seems to be fixed by
> https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git/comm
> it/?h=fixes=9f9666e65359d5047089aef97ac87c50f624ecb0
> 
> I don't have the bandwidth to check this further, so I don't know if
> this is already in an already released kernel or one already in sid or
> experimental, but hopefully this helps.

That commit is part of 6.4-rc7 and Experimental currently has 6.4.1-1 so it 
should be fixed with that kernel.
Verification whether that's indeed the case would be appreciated.

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

Bug#1040001: transition: r-base

[Graham Inggs]

Hi Andreas

On Wed, 5 Jul 2023 at 15:51, Andreas Tille  wrote:
> the just uploaded r-base 4.3.1-2 implements r-graphics-engine-* which is
> respected by dh-r 20230705 (also just uploaded).  It would be great if
> you could setup transition tracker.

I don't think it's possible to set up a tracker for this first
"transition", as no packages currently depend on r-graphics-engine-*.

> Am I understanding things correctly that I can now start uploading those
> r-cran-* packages featuring bugs
>autopkgtest failure with r-base (4.3.1-1)
> even if the tracker is not yet setup?

Please wait until r-base and dh-r are built and in the installed state
on all architectures.

Regards
Graham

Bug#1040409: aapt: unaligned memory access

[Mattia Rizzolo]

Package: aapt
Version: 1:10.0.0+r36-10
Severity: important

This has been noticed on Ubuntu, on a armhf container running on arm64.


root@optimum-quagga:~/diffoscope# gdb --args aapt2 dump resources 
/tmp/tmpntfkh146/out.apk
GNU gdb (Ubuntu 13.2-1ubuntu1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from aapt2...
Reading symbols from 
/usr/lib/debug/.build-id/08/4ab3c604520da0c8ff77de341641ed94213b9d.debug...
(gdb) r
Starting program: /usr/bin/aapt2 dump resources /tmp/tmpntfkh146/out.apk
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
android::ResTable_config::copyFromDeviceNoSwap (this=0xfffee6b0, o=...) at 
./libs/androidfw/ResourceTypes.cpp:1838
1838 ./libs/androidfw/ResourceTypes.cpp: No such file or directory.
(gdb) bt
#0 android::ResTable_config::copyFromDeviceNoSwap (this=0xfffee6b0, o=...) at 
./libs/androidfw/ResourceTypes.cpp:1838
#1 android::ResTable_config::copyFromDtoH (this=0xfffee6b0, o=...) at 
./libs/androidfw/ResourceTypes.cpp:1911
#2 0x004b4a28 in aapt::BinaryResourceParser::ParseType 
(this=this@entry=0xfffeed58, package=package@entry=0x5bc8a8, chunk=0xf7fcf709) 
at ./tools/aapt2/format/binary/BinaryResourceParser.cpp:352
#3 0x004b3928 in aapt::BinaryResourceParser::ParsePackage 
(this=this@entry=0xfffeed58, chunk=) at 
./tools/aapt2/format/binary/BinaryResourceParser.cpp:241
#4 0x004b2ff4 in aapt::BinaryResourceParser::ParseTable 
(this=this@entry=0xfffeed58, chunk=) at 
./tools/aapt2/format/binary/BinaryResourceParser.cpp:156
#5 0x004b2914 in aapt::BinaryResourceParser::Parse (this=0xfffeed58) at 
./tools/aapt2/format/binary/BinaryResourceParser.cpp:109
#6 0x00511054 in aapt::LoadedApk::LoadBinaryApkFromFileCollection (source=..., 
collection=std::unique_ptr = {...}, 
diag=diag@entry=0xfffef338) at ./tools/aapt2/LoadedApk.cpp:168
#7 0x00510844 in aapt::LoadedApk::LoadApkFromPath (path=..., diag=0xfffef338) 
at ./tools/aapt2/LoadedApk.cpp:87
#8 0x00428b18 in aapt::DumpApkCommand::Action (this=0x5ba290, args=...) at 
tools/aapt2/cmd/Dump.h:72
#9 0x00413440 in aapt::Command::Execute (this=0x5ba290, args=..., 
out_error=) at ./tools/aapt2/cmd/Command.cpp:250
#10 0x00413548 in aapt::Command::Execute (this=0x5b7eb8, args=..., 
out_error=) at ./tools/aapt2/cmd/Command.cpp:200
#11 0x00413548 in aapt::Command::Execute (this=0x5b5a40, args=..., 
out_error=) at ./tools/aapt2/cmd/Command.cpp:200
#12 0x00552dd0 in MainImpl (argc=, argv=) at 
./tools/aapt2/Main.cpp:177
#13 0xf7a5b7da in __libc_start_call_main (main=main@entry=0x552e44 , argc=argc@entry=4, argv=0xfffef534, argv@entry=0xf7b4d000) at 
../sysdeps/nptl/libc_start_call_main.h:58
#14 0xf7a5b87e in __libc_start_main_impl (main=0x552e44 , 
argc=4, argv=0xf7b4d000, init=, fini=0x0, rtld_fini=0xf7fd5539 
<_dl_fini>, stack_end=0xfffef534) at libc-start.c:360
#15 0x00411ab0 in _start ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) disassemble
Dump of assembler code for function 
_ZN7android15ResTable_config12copyFromDtoHERKS0_:
   0xf7eb95c4 <+0>: push {r4, r5, r6, r7, r8, lr}
   0xf7eb95c8 <+4>: ldr r5, [r1]
   0xf7eb95cc <+8>: mov r8, r0
   0xf7eb95d0 <+12>: cmp r5, #64 @ 0x40
   0xf7eb95d4 <+16>: bcc 0xf7eb95f4 
<_ZN7android15ResTable_config12copyFromDtoHERKS0_+48>
=> 0xf7eb95d8 <+20>: ldm r1!, {r2, r3, r4, r5, r6}
   0xf7eb95dc <+24>: stmia r0!, {r2, r3, r4, r5, r6}
   0xf7eb95e0 <+28>: ldm r1!, {r2, r3, r4, r5, r6}
   0xf7eb95e4 <+32>: stmia r0!, {r2, r3, r4, r5, r6}
   0xf7eb95e8 <+36>: ldm r1, {r2, r3, r4, r5, r6, r7}
   0xf7eb95ec <+40>: stm r0, {r2, r3, r4, r5, r6, r7}
   0xf7eb95f0 <+44>: b 0xf7eb960c 
<_ZN7android15ResTable_config12copyFromDtoHERKS0_+72>
   0xf7eb95f4 <+48>: mov r2, r5
   0xf7eb95f8 <+52>: bl 0xf7e990dc 
   0xf7eb95fc <+56>: add r0, r8, r5
   0xf7eb9600 <+60>: rsb r2, r5, #64 @ 0x40
   0xf7eb9604 <+64>: mov r1, #0
   0xf7eb9608 <+68>: bl 0xf7e98c8c 
   0xf7eb960c <+72>: mov r0, #64 @ 0x40
   0xf7eb9610 <+76>: str r0, [r8]
   0xf7eb9614 <+80>: pop {r4, r5, r6, r7, r8, pc}
End of assembler dump.
(gdb)



More: https://bugs.launchpad.net/ubuntu/+source/diffoscope/+bug/2026151

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More 

Bug#1032071: ARM firmware packages included in amd64 installation images

[Steve McIntyre]

On Mon, Feb 27, 2023 at 12:36:22PM +0100, Pascal Hambourg wrote:
>Package: debian-cd
>Version: 3.2.0
>Severity: minor
>
>debian-bookworm-DI-alpha2-amd64-netinst.iso includes firmware packages for
>ARM platforms:
>
> firmware-qcom-soc
> firmware-samsung
> firmware-ti-connectivity
> raspi-firmware

Now all filtered in debian-cd unless we have an arm* architecture for
the build.

>These packages add 34 MB to the ISO image, which is not negligible.
>
>Additionally, IIUC the installer only needs firmware for storage,
>network/wireless and sound devices. It uses generic graphic drivers for
>display so it does not need GPU firmware. The netinst image includes firmware
>packages which do not seem to be needed by the installer:
>
> bluez-firmware (Bluetooth)
> dahdi-firmware-nonfree (VoIP)
> firmware-amd-graphics (GPU)
> firmware-ast (GPU)
> firmware-ivtv (MPEG codec)
> firmware-realtek-rtl8723cs-bt (Bluetooth)
> firmware-siano (TV receiver)
> hdmi2usb-fx2-firmware (?)
>
>Among them, firmware-amd-graphics takes 12 MB.
>Is it useful to include these packages in the netinst image ?
>Couldn't they be downloaded from a mirror like other ordinary packages when
>needed ?

I'm not currently filtering by build type, so I'm leaving these in.

>Note: it also includes firmware-linux-nonfree which is a meta-package not
>containing any firmware file.

That's been fixed separately by other changes - we now check the
contents of the firmware .debs too.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Bug#1040407: linux-image-6.3.0-1-amd64: X1 Carbon 9th gen, docked, external display stops working after suspend and there are kernel traces in the logs

[Claudio Saavedra]

According to https://www.spinics.net/lists/linux-usb/msg242489.html
this seems to be fixed by
https://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt.git/commit/?h=fixes=9f9666e65359d5047089aef97ac87c50f624ecb0

I don't have the bandwidth to check this further, so I don't know if
this is already in an already released kernel or one already in sid or
experimental, but hopefully this helps.

Bug#1039872: Improve firmware package inclusion

[Steve McIntyre]

On Wed, Jul 05, 2023 at 08:30:03AM +0200, Pascal Hambourg wrote:
>On 05/07/2023 at 00:50, Steve McIntyre wrote:
>> 
>> I think that's quite a result! Comparing the ISOs, the differences are
>> just 5 missing firmware debs:
>> 
>> firmware-nvidia-gsp_525.116.04-1_amd64.deb
>> firmware-nvidia-tesla-gsp_525.105.17-2_amd64.deb
>> firmware-qcom-soc_20230515-2_all.deb
>> firmware-samsung_20230515-2_all.deb
>> raspi-firmware_1.20220830+ds-1_all.deb
>
>As mentioned in #1032071, AFAICS firmware-ti-connectivity also contains
>ARM-only firmware.

Hmmm, OK. The description isn't 100% clear here. I'll filter it now
for non-arm as well.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Bug#1035972: isc-dhcp EOL'ed

[Holger Levsen]

On Wed, Jul 05, 2023 at 12:41:05PM -0300, Santiago Ruano Rincón wrote:
> El 05/07/23 a las 10:26, Moritz Muehlenhoff escribió:
> https://salsa.debian.org/debian/debian-security-support/-/merge_requests/16
> 
> I hope the above mentioned MR reflects the thread consensus. It is been
> a long time since I haven't made any change to debian-security-support,
> please review it, in case I am doing some stupidity.

thanks, the MR looks fine and you're one of the isc-dhcp maintainers, so
the content is also fine.

will merge after sending this email :)


-- 
cheers,
Holger

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

Change is coming whether you like it or not.


signature.asc
Description: PGP signature

Bug#1040408: mirror submission for repo.jing.rocks

[Jing Luo]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: repo.jing.rocks
Type: leaf
Archive-architecture: amd64 arm64
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Jing Luo 
Country: JP Japan
Location: Tokyo
Comment: ipv6: yes
 rsync: yes
 https: yes




Trace Url: http://repo.jing.rocks/debian/project/trace/
Trace Url: http://repo.jing.rocks/debian/project/trace/ftp-master.debian.org
Trace Url: http://repo.jing.rocks/debian/project/trace/repo.jing.rocks