Bug#850955: libapache2-request-perl: description should include the names of the libraries

[Sebastiaan Couwenberg]

Control: tags -1 pending

This is fixed in git:


https://salsa.debian.org/debian/libapreq2/-/commit/b450debda66bcf40de4c1053da642a8bd972a973

Kind Regards,

Bas

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

Bug#1037458: RFS: python-jsbeautifier/1.14.8-1 -- JavaScript unobfuscator and beautifier

[Håvard F . Aasen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-jsbeautifier":

 * Package name : python-jsbeautifier
   Version  : 1.14.8-1
   Upstream contact : Liam Newman, Einar Lielmanis, et al. 
 * URL  : https://github.com/beautify-web/js-beautify
 * License  : MIT
 * Vcs  : https://salsa.debian.org/debian/python-jsbeautifier
   Section  : python

The source builds the following binary packages:

  python3-jsbeautifier - JavaScript unobfuscator and beautifier (python3)
  jsbeautifier - JavaScript unobfuscator and beautifier

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

  https://mentors.debian.net/package/python-jsbeautifier/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-jsbeautifier/python-jsbeautifier_1.14.8-1.dsc

Changes since the last upload:

 python-jsbeautifier (1.14.8-1) unstable; urgency=medium
 .
   * New upstream version 1.14.8
   * Rebase patches, drop 0002-Fix-test.patch, included upstream.
   * Add patch to fix 'brace-style' test
   * Update Standards-Version to 4.6.2, no changes needed.
   * d/copyright: Add the year 2023 to myself.
   * autopkgtest: Drop autodep8 test in favor of upstream test suites.

Regards,
Håvard

Bug#1036528: zutils: leftover conffiles

[Daniel Baumann]

found 1036528 1.12-1
notfound 1036528 1.12-2
close 1036528 1.12-2
thanks

Hi Christoph,

thank you for your report, this has been fixed in 1.12-2:

https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=4596dac645e794ca9153e92a99d176dfc357c2ce

I've confirmed that when upgrading from previous versions, with the
installation of zutils 1.12-2, /etc/zutils gets removed:

---snip---
daniel@daniel:~$ sudo apt install zutils
[...]
Reading changelogs... Done
(Reading database ... 277758 files and directories currently installed.)
Preparing to unpack .../zutils_1.12-2_amd64.deb ...
Unpacking zutils (1.12-2) over (1.8-3+b10) ...
Setting up zutils (1.12-2) ...
Removing obsolete conffile /etc/zutilsrc ...
Processing triggers for install-info (6.7.0.dfsg.2-6) ...
Processing triggers for man-db (2.11.2-2) ...
[...]
daniel@daniel:~$
---snap---

Regards,
Daniel

Bug#1031892: openjdk-21 should not be in stable releases for now

[Matthias Klose]

closing, OpenJDK 21 will be another LTS release.

Bug#1037457: bluetooth: Bluetooth does not work, command 0x2005 tx timeout

[Zach Berger]

Package: bluetooth
Severity: important
Tags: upstream
X-Debbugs-Cc: z...@zberger.com

Dear Maintainer,

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

   * What led up to the situation?

 Bluetooth has stopped working on my system. I have a ZEXMTE USB
 bluetooth adapter. It worked earlier in the bookworm release cycle
 but at somepoint it stopped working. 

 In the kernel logs I see: 

[  +1.306483] Bluetooth: hci0: command 0x2005 tx timeout
[  +0.003845] Bluetooth: hci0: Opcode 0x2005 failed: -110
[  +2.012181] Bluetooth: hci0: Opcode 0x2041 failed: -110
[  +0.14] Bluetooth: hci0: command 0x2041 tx timeout

In the kernel bug tracker this has been reported as well:
https://bugzilla.kernel.org/show_bug.cgi?id=215167

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

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

Versions of packages bluetooth depends on:
ii  bluez  5.66-1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
pn  bluez-cups   
pn  bluez-meshd  
pn  bluez-obexd  

Bug#1035820: 9base: leaves entries in /etc/shells after upgrade from bullseye

[Helmut Grohne]

Hi Andreas,

On Mon, Jun 12, 2023 at 07:40:32PM +0200, Andreas Beckmann wrote:
> > It's a 12 byte difference. That's not 9base's entries. What you see here
> > is "/usr/bin/sh\n". So this is a /usr-merge bug. We already know it.
> > Thus force-merging.
> 
> No, it's "/usr/bin/rc\n".

Huh! I stand corrected.

> # cat /usr/share/debianutils/shells.d/plan9
> /bin/rc
> /usr/lib/plan9/bin/rc
> 
> If I install 9base in an unmerged-/usr sid chroot, I get
> 
> # /etc/shells: valid login shells
> /bin/sh
> /bin/bash
> /bin/rbash
> /bin/dash
> /bin/rc
> /usr/lib/plan9/bin/rc
> /usr/lib/plan9/bin/rc
> 
> who is responsible for the duplicate entry?

This is caused by update-shells and the code it carries to support
/usr-merge. When it encounters /bin/rc, it canonicalizes it using
dpkg-realpath and adds it as well. So the first duplicate is the
canonicalization of /bin/rc and the second one is the actual entry.

In essence, the /usr-merge implementation in update-shells assumes that
any kind of symlinking for shells happens due to /usr-merge. This
assumption is false and violated by the use of update-alternatives.

In update-shells, we should not resolve the final link, but only
directory components as those are the ones that may lead to aliasing
effects. Instead of

realshell=$(dirname "$(dpkg-realpath --root "$ROOT" "$line")")/$(basename 
"$line")

we probably should have said

realshell="$(dpkg-realpath --root "$ROOT" "$(dirname "$line")")/$(basename 
"$line")"

and with that, we'd pass /bin rather than /bin/rc to dpkg-realpath and
avoid resolving the alternative.

> If I reconfigure usrmerge afterwards, I get
> 
> # /etc/shells: valid login shells
> /bin/sh
> /bin/bash
> /usr/bin/bash
> /bin/rbash
> /usr/bin/rbash
> /bin/dash
> /usr/bin/dash
> /usr/bin/sh
> /bin/rc
> /usr/lib/plan9/bin/rc
> /usr/lib/plan9/bin/rc
> /usr/bin/rc
> 
> Now we got the additional /usr/bin/rc entry

The entry is added by /usr/lib/usrmerge/convert-etc-shells (which is the
policy violation this bug has been merged into). The merging strategy
there is based on a knowledge of the symlinks that should exist rather
than looking them up in the filesystem.

So this is two distinct bugs actually. We also need to fix update-shells
to properly deal with update-alternatives using the patch above.

Thank you Andreas for your persistence on this.

Helmut

Bug#1037456: RFP: Publii -- Static CMS for privacy-focused, SEO-optimized websites

[Fernando C. Estrada]

Package: wnpp
Severity: wishlist

* Package name: Publii
  Version : 0.42.1
  Upstream Contact: TidyCustoms 
* URL : https://getpublii.com
* License : GPL-3.0
  Programming Lang: JavaScript
  Description : Static CMS for privacy-focused, SEO-optimized websites.

Unlike static-site generators that are often unwieldy and difficult to use,
Publii provides an easy-to-understand UI much like server-based CMSs such as
WordPress or Joomla!, where users can create posts and other site content, and
style their site using a variety of built-in themes and options. Users can
enjoy the benefits of a super-fast and secure static website, with all the
convenience that a CMS provides.

What makes Publii even more unique is that the app runs locally on your desktop
rather than on the site's server. Available for Windows, Mac, Linux once the
app has been installed you can create a site in minutes, even without internet
access; since Publii is a desktop app you can create, update and modify your
site offline, then upload the site changes to your server at the click of a
button. Publii supports multiple upload options, including standard HTTP/HTTPS
servers, Netlify, Amazon S3, GitHub Pages and Google Cloud or SFTP.

--
Fernando C. Estrada

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Salvatore Bonaccorso]

Hi Nicholas,

On Mon, Jun 12, 2023 at 07:44:52PM -0400, Nicholas D Steeves wrote:
> Control: block 1033341 by -1
> 
> Dear Salvatore and release team,
> 
> Salvatore Bonaccorso  writes:
> 
> > On Tue, Jun 06, 2023 at 11:00:14PM -0400, Nicholas D Steeves wrote:
> >> +org-mode (9.4.0+dfsg-1+deb11u1) bullseye-security; urgency=medium
> >> +
> >> +  * Fix Org Mode command injection vulnerability CVE-2023-28617 by 
> >> backporting
> >> +0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch like 
> >> src:emacs
> >> +did (Closes: #1033341).  Thanks to Rob Browning's work in that 
> >> package,
> >> +fixing org-mode was trivially easy!
> >> +
> >> + -- Nicholas D Steeves   Sun, 04 Jun 2023 13:26:52 -0400
> >
> > Small remark, for the bullseye pu update please target at 'bullseye'
> > not 'bullseye-security'.
> >
> 
> Done.  That was actually my first instinct, but I thought the existence
> of a CVE would destine the upload to the -security queue!  I was wrong,
> but this is a teaching/learning moment.
> 
> Is it as simple as: Use the -security queue when a DSA is needed,
> otherwise use the normal distribution code name and the foo-updates
> queue?  No need to explain if it's more complicated and if you're busy.
> (I couldn't find documentation of this in the Dev Ref)

What is as well different for the uploads is to which upload queue you
would upload in the end. ftp-master for the proposed-updates via point
release, security-master for the security uploads.

There are two good entry points about the uploads for stable:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#handling-security-related-bugs

Hope this helps!

Regards,
Salvatore

Bug#1037455: ITP: narcissus -- limited Java reflection library that bypasses security restrictions

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, 
tool.factory.he...@gmail.com, j...@nahmias.net

* Package name: narcissus
  Version : 1.0.7
  Upstream Contact: ToolFactory 
* URL : https://github.com/toolfactory/narcissus
* License : MIT
  Programming Lang: Java
  Description : limited Java reflection library that bypasses security 
restrictions

Narcissus is a JNI native code library that provides a small subset of the Java
reflection API, while bypassing all of Java's access/visibility checks,
security manager restrictions, and module strong encapsulation enforcement, by
calling methods and accessing fields through the JNI API. This allows code that
relies on reflective access to non-public classes, fields, and methods to keep
working even now that strong encapsulation is being enforced in JDK 16+.

Narcissus works on JDK 7+, however it is most useful for suppressing reflective
access warnings in JDK 9-15, and for circumventing strong encapsulation for JDK
16+, in order to keep legacy software running (for example, when legacy
software depends upon setAccessible to access a needed private field of a class
in some library).

Bug#1037454: zulucrypt autopkgtests fail

[Steve Langasek]

Source: zulucrypt
Version: 6.2.0-1
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic

Hi Marcio,

The zulucrypt autopkgtests are failing in Ubuntu with the following error:

[...]

create a luks type volume using a key: FAILED
ERROR: A non supported device encountered,device is missing or permission denied
Possible reasons for getting the error are:
1.Device path is invalid.
2.The device has LVM or MDRAID signature

autopkgtest [06:35:03]: test command1: ---]
command1 FAIL non-zero exit status 1
[...]

https://autopkgtest.ubuntu.com/results/autopkgtest-mantic/mantic/amd64/z/zulucrypt/20230506_063514_ac412@/log.gz

The test is skipped in Debian, because it requires machine-level isolation
and the Debian autopkgtest environment doesn't provide this.  So I don't
know if the tests would pass in a Debian VM, but in Ubuntu the tests have
regressed.

In the meantime, it's not a release-critical blocker in Debian, but could
still indicate a severe defect.

-- 
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#1037453: libmail-dmarc-perl: FTBFS with test failures when there's no network

[Steve Langasek]

Package: libmail-dmarc-perl
Version: 1.20211209-4
Severity: serious
Tags: patch
Justification: Policy 4.9
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Hi Noah,

libmail-dmarc-perl has yet to be included in an Ubuntu release because its
build-time tests depend on network access.  This is a fairly reasonable
thing to want to do in this package, to validate real-world DNS entries. 
However, it falls afoul of Launchpad's network policy, and is also AIUI a
violation of Policy 4.9.  It also represents an external dependency for the
package, which can result in regressions in buildability if in the future
the referenced domains change their DNS settings.

I've applied the attached (very dirty) patch to libmail-dmarc-perl in
Ubuntu, which is sufficient to let the package build in Launchpad.  Having
looked at some of the surrounding tests, I'm not sure this would let the
package build in a completely offline environment - I think Launchpad
provides name resolution of a limited subset of domains, so some tests which
pass in Launchpad may also fail when offline.

Thanks for considering,
-- 
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
diff -Nru libmail-dmarc-perl-1.20211209/debian/patches/series 
libmail-dmarc-perl-1.20211209/debian/patches/series
--- libmail-dmarc-perl-1.20211209/debian/patches/series 2023-01-28 
20:45:01.0 -0800
+++ libmail-dmarc-perl-1.20211209/debian/patches/series 2023-06-12 
18:30:18.0 -0700
@@ -1,2 +1,3 @@
 0001-pod-Fix-missing-and-malformed-NAME-headings.patch
 0005-recommend-system-psl.patch
+skip_network_tests.patch
diff -Nru libmail-dmarc-perl-1.20211209/debian/patches/skip_network_tests.patch 
libmail-dmarc-perl-1.20211209/debian/patches/skip_network_tests.patch
--- libmail-dmarc-perl-1.20211209/debian/patches/skip_network_tests.patch   
1969-12-31 16:00:00.0 -0800
+++ libmail-dmarc-perl-1.20211209/debian/patches/skip_network_tests.patch   
2023-06-12 18:43:32.0 -0700
@@ -0,0 +1,127 @@
+Description: skip tests that depend on network access
+Author: Steve Langasek 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2023606
+Last-Update: 2023-06-12
+Forwarded: no
+
+Index: libmail-dmarc-perl-1.20211209/t/04.PurePerl.t
+===
+--- libmail-dmarc-perl-1.20211209.orig/t/04.PurePerl.t
 libmail-dmarc-perl-1.20211209/t/04.PurePerl.t
+@@ -31,20 +31,20 @@
+ isa_ok( $dmarc, 'Mail::DMARC::PurePerl' );
+ 
+ test_get_from_dom();
+-test_fetch_dmarc_record();
++#test_fetch_dmarc_record();
+ test_get_organizational_domain();
+-test_exists_in_dns();
++#test_exists_in_dns();
+ test_is_spf_aligned();
+ test_is_dkim_aligned();
+ test_is_aligned();
+ test_is_whitelisted();
+-test_discover_policy();
++#test_discover_policy();
+ test_validate();
+-test_has_valid_reporting_uri();
++#test_has_valid_reporting_uri();
+ test_external_report();
+-test_verify_external_reporting( 'tnpi.net','theartfarm.com', 1 );
+-test_verify_external_reporting( 'cadillac.net','theartfarm.com', 1 );
+-test_verify_external_reporting( 'mail-dmarc.tnpi.net', 'theartfarm.com', 1 );
++#test_verify_external_reporting( 'tnpi.net','theartfarm.com', 1 );
++#test_verify_external_reporting( 'cadillac.net','theartfarm.com', 1 );
++#test_verify_external_reporting( 'mail-dmarc.tnpi.net', 'theartfarm.com', 1 );
+ _test_reason();
+ 
+ done_testing();
+@@ -77,11 +77,8 @@
+ ]);
+ 
+ my $policy = $dmarc->discover_policy;
+-ok( $policy, "discover_policy" );
+ my $result = $dmarc->validate($policy);
+ ok( ref $result, "result is a ref");
+-ok( $result->{result} eq 'pass', "result=pass");
+-ok( $result->{spf} eq 'pass', "spf=pass");
+ ok( $result->{disposition} eq 'none', "disposition=none");
+ 
+ $result->disposition('reject');
+@@ -91,7 +88,6 @@
+ ok( $result->reason( type => 'local_policy', comment => 'testing' ), 
"added reason 2" );
+ #warn Data::Dumper::Dumper($result->reason);
+ 
+-ok( $dmarc->save_aggregate(), "save aggregate");
+ }
+ 
+ sub test_verify_external_reporting {
+Index: libmail-dmarc-perl-1.20211209/t/06.Result.t
+===
+--- libmail-dmarc-perl-1.20211209.orig/t/06.Result.t
 libmail-dmarc-perl-1.20211209/t/06.Result.t
+@@ -17,7 +17,7 @@
+ isa_ok( $result, 'Mail::DMARC::Result' );
+ 
+ my $test_dom = 'tnpi.net';
+-test_published();
++#test_published();
+ test_no_policy();
+ test_disposition();
+ test_dkim();
+@@ -203,9 +203,7 @@
+ $pp->validate();
+ 
+ my $skip_reason;
+-if ( !$pp->result->reason ) {# typically a DNS failure,
+-$skip_reason = "look like DNS is not working";
+-  

Bug#1030129: ca-certificates-java - Fails to install with OpenJDK 21: Error loading java.security file

[Sebastiaan Couwenberg]

On 6/13/23 05:22, tony mancill wrote:

I am not able to reproduce the failure in a clean unstable
schroot with either openjdk-17 or openjdk-21 yet - for example:


I also had trouble reproducing the issue in a sid cowbuilder chroot.

This worked for me:

 apt install ca-certificates-java default-jdk openjdk-21-jdk

Just building osmpbf also triggered the issue yesterday, but now

 apt build-dep osmpbf

succeeds like it does for other Java packages. This suggests a race 
condition or apt package ordering issue.


Kind Regards,

Bas

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

Bug#1037452: clang-15: HIP search paths depend on os-release

[Cordell Bloor]

Package: clang-15
Version: 1:15.0.7-4
Severity: wishlist
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

The upstream LLVM project checks /etc/os-release to determine if it
should search for HIP in /usr and /usr/local. This is unfortunate
because it introduces unexpected differences in behaviour into
Debian-derived distros like Ubuntu [1].

This behaviour has been fixed upstream in later versions of clang [2].
Could you please backport the patch to clang-15 and clang-16? I've
requested upstream to backport it into an LLVM 16 patch release [3],
but the behaviour in LLVM 15 is specific to Debian as it was introduced
by d/p/amdgpu/usr-search-paths.patch.

[1]: https://launchpad.net/ubuntu/+builds?build_text=rocblas_state=all
[2]: 
https://github.com/llvm/llvm-project/commit/f8598357662dc8dd0f4400bcaeb48e8befe43ecc.patch
[3]: https://github.com/llvm/llvm-project/issues/62853

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages clang-15 depends on:
ii  binutils2.40.50.20230611-2
ii  libc6   2.36-9
ii  libc6-dev   2.36-9
ii  libclang-common-15-dev  1:15.0.7-4
ii  libclang-cpp15  1:15.0.7-4
ii  libclang1-151:15.0.7-4
ii  libgcc-12-dev   12.2.0-14
ii  libgcc-s1   13.1.0-5
ii  libllvm15   1:15.0.7-4
ii  libobjc-12-dev  12.2.0-14
ii  libstdc++-12-dev12.2.0-14
ii  libstdc++6  13.1.0-5
ii  llvm-15-linker-tools1:15.0.7-4

Versions of packages clang-15 recommends:
ii  llvm-15-dev  1:15.0.7-4
ii  python3  3.11.2-1+b1

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

-- no debconf information

Bug#1030129: ca-certificates-java - Fails to install with OpenJDK 21: Error loading java.security file

[tony mancill]

On Mon, Jun 12, 2023 at 06:55:49AM +0200, Sebastiaan Couwenberg wrote:
> On Tue, 31 Jan 2023 13:56:42 +0100 Bastian Blank  wrote:
> > | dpkg: error processing package openjdk-21-jdk:arm64 (--configure):
> > |  dependency problems - leaving unconfigured
> 
> It also fails to install with openjdk-17:
> 
> Setting up ca-certificates-java (20230103) ...
> Exception in thread "main" java.lang.InternalError: Error loading
> java.security file
> at java.base/java.security.Security.initialize(Security.java:106)
> at java.base/java.security.Security$1.run(Security.java:84)
> at java.base/java.security.Security$1.run(Security.java:82)
> at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at java.base/java.security.Security.(Security.java:82)
> at
> java.base/sun.security.jca.ProviderList.(ProviderList.java:178)
> at
> java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:96)
> at
> java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
> at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> at 
> java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:93)
> at java.base/sun.security.jca.Providers.(Providers.java:55)
> at
> java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156)
> at 
> java.base/java.security.cert.CertificateFactory.getInstance(CertificateFactory.java:193)
> at
> org.debian.security.KeyStoreHandler.(KeyStoreHandler.java:50)
> at
> org.debian.security.UpdateCertificates.(UpdateCertificates.java:65)
> at
> org.debian.security.UpdateCertificates.main(UpdateCertificates.java:51)

I am not able to reproduce the failure in a clean unstable
schroot with either openjdk-17 or openjdk-21 yet - for example:

$ sudo sbuild-createchroot --no-deb-src --chroot-mode=schroot 
--chroot-prefix=test --include=default-jdk unstable 
/data/chroot/test-amd64-sbuild  

$ schroot -c test-amd64-sbuild -u root --directory /tmp /bin/bash

(test-amd64-sbuild)root@lark:/tmp# dpkg -l | grep -E 
'openjdk|ca-cert|default-jdk'
ii  ca-certificates   20230311   all  Common CA 
certificates
ii  ca-certificates-java  20230103   all  Common CA 
certificates (JKS keystore)
ii  default-jdk   2:1.17-74  amd64Standard Java 
or Java compatible Development Kit
ii  default-jdk-headless  2:1.17-74  amd64Standard Java 
or Java compatible Development Kit (headless)
ii  openjdk-17-jdk:amd64  17.0.7+7-1 amd64OpenJDK 
Development Kit (JDK)
ii  openjdk-17-jdk-headless:amd64 17.0.7+7-1 amd64OpenJDK 
Development Kit (JDK) (headless)
ii  openjdk-17-jre:amd64  17.0.7+7-1 amd64OpenJDK Java 
runtime, using Hotspot JIT
ii  openjdk-17-jre-headless:amd64 17.0.7+7-1 amd64OpenJDK Java 
runtime, using Hotspot JIT (headless)

Maybe some environmental difference is causing the failure.  Could it be
that the java.security file has been modified on the systems where the
failure is occurring?  (Just a guess...)  If so, could someone share the
file from a system where the bug manifests?

Thanks,
tony

Bug#1037451: ITP: libjodycode -- shared lib for programs written by Jody Bruchon

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Jody Bruchon 

* Package name: libjodycode
  Version : 2.0.1
  Upstream Contact: Jody Bruchon 
* URL : https://github.com/jbruchon/libjodycode
* License : Expat
  Programming Lang: C
  Description : shared lib for programs written by Jody Bruchon

 libjodycode2 is a software code library containing code shared among several
 of the programs written by Jody Bruchon such as imagepile, jdupes, winregfs,
 and zeromerge. These shared pieces of code were copied between each program
 as they were updated. As the number of programs increased and keeping these
 pieces of code synced became more annoying, the decision was made to combine
 all of them into a single reusable shared library.

Bug#1029210: smartmontools.service fails since bookworm

[Alban Browaeys]

A way to avoid the smartmontools systemd service to fail is to switch
the Service type from notify to forking. This after adding the "-q
nodev0" flag to the /etc/default/smartmontools smart_options variable.

systemctl edit smartmontools
[Service]
Type=forking

then systemctl daemon-reload
and restart samrtmontools/

Why is smartd of type notify? Does it send notification to systemd via
sd_notify?

Cheers,
Alban


On Tue, 13 Jun 2023 03:15:06 +0200 Alban Browaeys
 wrote:
> 
> Even with "-q nodev0" the service ends up in a failed state (but now
> with an exit status of 0/SUCCESS)
> 
> sudo systemctl status smartmontools
> × smartmontools.service - Self Monitoring and Reporting Technology
(SMART) Daemon
>  Loaded: loaded (/lib/systemd/system/smartmontools.service;
enabled; preset: enabled)
>  Active: failed (Result: protocol) since Tue 2023-06-13 03:07:54
CEST; 2s ago
>    Docs: man:smartd(8)
>  man:smartd.conf(5)
> Process: 4072 ExecStart=/usr/sbin/smartd -n $smartd_opts
(code=exited, status=0/SUCCESS)
>    Main PID: 4072 (code=exited, status=0/SUCCESS)
>  Status: "No devices to monitor"
> CPU: 29ms
> 
> juin 13 03:07:54 hercule systemd[1]: Starting smartmontools.service -
Self Monitoring and Reporting Technology (SMART) Daemon...
> juin 13 03:07:54 hercule smartd[4072]: smartd 7.3 2022-02-28 r5338
[aarch64-linux-6.2.0-rc3-meson64] (local build)
> juin 13 03:07:54 hercule smartd[4072]: Copyright (C) 2002-22, Bruce
Allen, Christian Franke, www.smartmontools.org
> juin 13 03:07:54 hercule smartd[4072]: Opened configuration file
/etc/smartd.conf
> juin 13 03:07:54 hercule smartd[4072]: Drive: DEVICESCAN, implied '-
a' Directive on line 21 of file /etc/smartd.conf
> juin 13 03:07:54 hercule smartd[4072]: Configuration file
/etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
> juin 13 03:07:54 hercule smartd[4072]: In the system's table of
devices NO devices found to scan
> juin 13 03:07:54 hercule systemd[1]: smartmontools.service: Failed
with result 'protocol'.
> juin 13 03:07:54 hercule smartd[4072]: Unable to monitor any SMART
enabled devices. Try debug (-d) option. Exiting...
> juin 13 03:07:54 hercule systemd[1]: Failed to start
smartmontools.service - Self Monitoring and Reporting Technology
(SMART) Daemon.
> 
> My storage as of now is only EMMC and SD. Though at time I can have
> external USB HDDs to monitor with smartd.
> 
> Cheers,
> Alban
> 
> 
> On Mon, 10 Apr 2023 15:41:10 +0200 Christian Franke
>  wrote:
> > Possible fix for the package: Add '-q nodev0' or '-q never' to
> ExecStart 
> > in smartmontools.service.
> > 
> > Workaround for users: Add one of these to smartd_opts in 
> > /etc/default/smartmontools.
> > 
> > Option '-q nodev0' is available since smartmontools 7.3. Then
smartd 
> > will exit with status 0 instead of 17 (default '-q nodev') if there
> are 
> > no devices to monitor. Systemd should no longer report this as a
> failed 
> > service.
> > 
> > With '-q never', smartd will keep running and does nothing. This
was
> the 
> > default for '-q' in some previous versions of (only!) the Debian 
> > package. This Debian-specific patch was reverted later, see:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006630
> > 
> > Regards,
> > 
> > Christian
> > smartmontools.org
> > 

Bug#1011089: nfs-utils: old configs /etc/default/nfs-* should have warnings

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 16 May 2022 15:13:07 -0300 Andreas Hasenack
 wrote:
> Package: nfs-utils
> Version: 1:2.6.1-2
> Severity: Normal
> 
> Dear Maintainer,
> 
> the config files in /etc/default/nfs-* should have a warning at the
> top stating that they are left there only for SySV systems that do not
> use systemd. In other words, they are ignored when systemd is used,
> and the configuration should be done in /etc/nfs.conf in that case.
> Otherwise users might get confused because changes they make to those
> files are not reflected in the actual services.
> 
> Alternatively, but probably not feasible for Debian yet, is to remove
> /etc/default/nfs-* entirely.

I intend to remove support in the init scripts for setting command line
options through these config files, and to update the default config
accordingly.  However, the config files will still be needed by the
init scripts to control which daemons are started.

Will that address your concerns?

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Bug#1037450: procps: [pgrep] [regression]: >15 characters warning when long regex doesn't match

[Jan Braun]

Craig Small schrob:
>   I'm thinking of adding a quick and dirty check for a regex. A very quick
> set of characters to say "this is a regex" and suppress the warning.
> The first idea is just look for a '[' or a '|'. I think that covers most
> simple conditions. I'm not looking for some sort odd corner cases, just the
> main ones.

I agree. | and [ should catch the vast majority of regexes already, and
you'll always be able to add [] around a literal char just to disable the
warning in the remaining cases.

> I'm not even going to bother with checking if the regex is too long (e.g.
> somethingverylonghere|somethingelsethatisverylong) because this is a simple
> check.

Yes, you'd go mad trying to figure out things like
something(verylonghere|elsethatislong)
anyway. Better to just assume that people writing regexes know (or test)
what they're matching.

cheers,
Jan


signature.asc
Description: PGP signature

Bug#849942: rpc.svcgssd: systemd service file tests for wrong keytab

[Ben Hutchings]

Control: severity -1 wishlist
Control: tag -1 wontfix

This can be handled by adding a local systemd drop-in config file that
overrides the conditions:

[Unit]
ConditionPathExists=
ConditionPathExists=

Or you can symlink /etc/krb5.keytab to your actual keytab path.

Given that these options exist, I don't think it's worth the effort to
handle this in the package.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Bug#1037450: procps: [pgrep] [regression]: >15 characters warning when long regex doesn't match

[Craig Small]

Hi,
  I'm thinking of adding a quick and dirty check for a regex. A very quick
set of characters to say "this is a regex" and suppress the warning.
The first idea is just look for a '[' or a '|'. I think that covers most
simple conditions. I'm not looking for some sort odd corner cases, just the
main ones.
I'm not even going to bother with checking if the regex is too long (e.g.
somethingverylonghere|somethingelsethatisverylong) because this is a simple
check.

Probably just scan the string looking for those chars and its done.

 - Craig


On Tue, 13 Jun 2023 at 11:09, Jan Braun  wrote:

> Package: procps
> Version: 2:4.0.3-1
> Severity: normal
>
> Dear Maintainer,
> Bug #896062 has come back from the grave:
>
> | $ pgrep  "something|otherthing"
> | pgrep: pattern that searches for process name longer than 15 characters
> will result in zero matches
> | Try `pgrep -f' option to match against the complete command line.
> | $
>
> Note *the regex* is longer than 15 chars, what gets matched is shorter.
>
> The 2018 fix was "new kernels have 64 char process names anyway", so I'm
> surprised to see that I'm having process names limited to 15 chars in
> 2023. But regardless of the actual limit, the warning is bogus.
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896062 for full
> rationale; everything there applies again, including my offer to help.
>
> Thank you for maintaining procps,
> Jan
>
> -- System Information:
> Debian Release: 12.0
>   APT prefers stable-debug
>   APT policy: (800, 'stable-debug'), (800, 'stable'), (650,
> 'testing-debug'), (650, 'testing'), (550, 'unstable'), (10, 'experimental')
> Architecture: armel (armv5tel)
>
> Kernel: Linux 6.1.0-9-marvell (UP)
> Locale: LANG=C.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
>
> Versions of packages procps depends on:
> ii  init-system-helpers  1.65.2
> ii  libc62.36-9
> ii  libncursesw6 6.4-4
> ii  libproc2-0   2:4.0.3-1
> ii  libtinfo66.4-4
>
> Versions of packages procps recommends:
> ii  psmisc  23.6-1
>
> procps suggests no packages.
>
> -- no debconf information
>

Bug#1029210: smartmontools.service fails since bookworm

[Alban Browaeys]

Even with "-q nodev0" the service ends up in a failed state (but now
with an exit status of 0/SUCCESS)

sudo systemctl status smartmontools
× smartmontools.service - Self Monitoring and Reporting Technology (SMART) 
Daemon
 Loaded: loaded (/lib/systemd/system/smartmontools.service; enabled; 
preset: enabled)
 Active: failed (Result: protocol) since Tue 2023-06-13 03:07:54 CEST; 2s 
ago
   Docs: man:smartd(8)
 man:smartd.conf(5)
Process: 4072 ExecStart=/usr/sbin/smartd -n $smartd_opts (code=exited, 
status=0/SUCCESS)
   Main PID: 4072 (code=exited, status=0/SUCCESS)
 Status: "No devices to monitor"
CPU: 29ms

juin 13 03:07:54 hercule systemd[1]: Starting smartmontools.service - Self 
Monitoring and Reporting Technology (SMART) Daemon...
juin 13 03:07:54 hercule smartd[4072]: smartd 7.3 2022-02-28 r5338 
[aarch64-linux-6.2.0-rc3-meson64] (local build)
juin 13 03:07:54 hercule smartd[4072]: Copyright (C) 2002-22, Bruce Allen, 
Christian Franke, www.smartmontools.org
juin 13 03:07:54 hercule smartd[4072]: Opened configuration file 
/etc/smartd.conf
juin 13 03:07:54 hercule smartd[4072]: Drive: DEVICESCAN, implied '-a' 
Directive on line 21 of file /etc/smartd.conf
juin 13 03:07:54 hercule smartd[4072]: Configuration file /etc/smartd.conf was 
parsed, found DEVICESCAN, scanning devices
juin 13 03:07:54 hercule smartd[4072]: In the system's table of devices NO 
devices found to scan
juin 13 03:07:54 hercule systemd[1]: smartmontools.service: Failed with result 
'protocol'.
juin 13 03:07:54 hercule smartd[4072]: Unable to monitor any SMART enabled 
devices. Try debug (-d) option. Exiting...
juin 13 03:07:54 hercule systemd[1]: Failed to start smartmontools.service - 
Self Monitoring and Reporting Technology (SMART) Daemon.

My storage as of now is only EMMC and SD. Though at time I can have
external USB HDDs to monitor with smartd.

Cheers,
Alban


On Mon, 10 Apr 2023 15:41:10 +0200 Christian Franke
 wrote:
> Possible fix for the package: Add '-q nodev0' or '-q never' to
ExecStart 
> in smartmontools.service.
> 
> Workaround for users: Add one of these to smartd_opts in 
> /etc/default/smartmontools.
> 
> Option '-q nodev0' is available since smartmontools 7.3. Then smartd 
> will exit with status 0 instead of 17 (default '-q nodev') if there
are 
> no devices to monitor. Systemd should no longer report this as a
failed 
> service.
> 
> With '-q never', smartd will keep running and does nothing. This was
the 
> default for '-q' in some previous versions of (only!) the Debian 
> package. This Debian-specific patch was reverted later, see:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006630
> 
> Regards,
> 
> Christian
> smartmontools.org
> 
> 
> 

Bug#1037450: procps: [pgrep] [regression]: >15 characters warning when long regex doesn't match

[Jan Braun]

Package: procps
Version: 2:4.0.3-1
Severity: normal

Dear Maintainer,
Bug #896062 has come back from the grave:

| $ pgrep  "something|otherthing"
| pgrep: pattern that searches for process name longer than 15 characters will 
result in zero matches
| Try `pgrep -f' option to match against the complete command line.
| $

Note *the regex* is longer than 15 chars, what gets matched is shorter.

The 2018 fix was "new kernels have 64 char process names anyway", so I'm
surprised to see that I'm having process names limited to 15 chars in
2023. But regardless of the actual limit, the warning is bogus.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896062 for full
rationale; everything there applies again, including my offer to help.

Thank you for maintaining procps,
Jan

-- System Information:
Debian Release: 12.0
  APT prefers stable-debug
  APT policy: (800, 'stable-debug'), (800, 'stable'), (650, 'testing-debug'), 
(650, 'testing'), (550, 'unstable'), (10, 'experimental')
Architecture: armel (armv5tel)

Kernel: Linux 6.1.0-9-marvell (UP)
Locale: LANG=C.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages procps depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9
ii  libncursesw6 6.4-4
ii  libproc2-0   2:4.0.3-1
ii  libtinfo66.4-4

Versions of packages procps recommends:
ii  psmisc  23.6-1

procps suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1037449: colord[…]: failed to get edid data: EDID length is too small

[Al Ma]

Package: colord
Version: 1.4.6-2.2
Taking a look at the bootlog obtained from journalctl -b, I discovered a report 
of the following failure:
Jun 12 21:41:41 AnonymizedComputerName dbus-daemon[885]: [system] Activating 
via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' 
requested by ':1.14' (uid=0 pid=960 comm="/usr/sbin/cupsd -l")
Jun 12 21:41:41 AnonymizedComputerName systemd[1]: Starting colord.service - 
Manage, Install and Generate Color Profiles...
Jun 12 21:41:41 AnonymizedComputerName systemd[1]: Started ModemManager.service 
- Modem Manager.
Jun 12 21:41:41 AnonymizedComputerName kernel: NET: Registered PF_QIPCRTR 
protocol family
Jun 12 21:41:41 AnonymizedComputerName sshd[988]: Server listening on 0.0.0.0 
port 22.
Jun 12 21:41:41 AnonymizedComputerName sshd[988]: Server listening on :: port 
22.
Jun 12 21:41:41 AnonymizedComputerName systemd[1]: Started ssh.service - 
OpenBSD Secure Shell server.
Jun 12 21:41:41 AnonymizedComputerName udev-configure-printer[883]: device 
devpath is /devices/pci:00/:00:14.0/usb1/1-11
Jun 12 21:41:41 AnonymizedComputerName udev-configure-printer[883]: MFG:hp 
MDL:deskjet 5600 SERN:AnonymizedPrinterSerialNumber 
serial:AnonymizedPrinterSerialNumber
Jun 12 21:41:41 AnonymizedComputerName colord[990]: failed to get edid data: 
EDID length is too small
What is EDID?  Why is it too small and how big should it be, whatever it is? Is 
there a programming error anywhere?
The printer itself is powered, connected to the computer via a USB cable, and 
in a deep sleep with all LEDs off (but if you send a there document, it wakes 
up).
I use Debian stable “bookworm” with udev 252.6-1  and systemd 252.6-1.
Gratefully,
AlMa

Bug#1037448: /usr/share/bash-completion/completions/git: git checkout completion yields bogus output for refs with '=' in

[наб]

Package: git
Version: 1:2.39.2-1.1
Version: 1:2.40.1-1
Severity: normal
File: /usr/share/bash-completion/completions/git

Dear Maintainer,

Given
  $ git init brussy
  Initialized empty Git repository in /tmp/brussy/.git/
  $ cd brussy/
  $ > a
  $ git add a
  $ git commit -m q
  [trunk (root-commit) 0792f5c] q
   1 file changed, 0 insertions(+), 0 deletions(-)
   create mode 100644 a
  $ git checkout -b c=c,default=c.utf-8
  Switched to a new branch 'c=c,default=c.utf-8'
  $ git checkout trunk
  Switched to branch 'trunk'
  $ git checkout c=
what would you expect pressing  to yield?
Probably
  git checkout c=c,default=c.utf-8
which is the (embarrassingly very real) branch name, right?
Right, but it's actually
  git checkout c=c=c,default=c.utf-8

Bogus.

Best,
наб

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

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

Versions of packages git depends on:
ii  git-man  1:2.39.2-1.1
ii  libc62.36-9
ii  libcurl3-gnutls  7.88.1-10
ii  liberror-perl0.17029-2
ii  libexpat12.5.0-1
ii  libpcre2-8-0 10.42-1
ii  perl 5.36.0-7
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20230311
ii  less 590-2
ii  openssh-client [ssh-client]  1:9.2p1-2
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-12
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
pn  gitk  
pn  gitweb

-- no debconf information


signature.asc
Description: PGP signature

Bug#1037447: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?

[Al Ma]

Package: wireplumber
Version: 0.4.13-1
While examining the output of journalctl -b, I found the message “Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?” first bold and 
then yellow:
Jun 12 21:41:41 AnonymizedComputerName systemd[1]: Started user@119.service - 
User Manager for UID 119.
Jun 12 21:41:41 AnonymizedComputerName systemd[1024]: Started pipewire.service 
- PipeWire Multimedia Service.
Jun 12 21:41:41 AnonymizedComputerName systemd[1]: Started session-c1.scope - 
Session c1 of User Debian-gdm.
Jun 12 21:41:41 AnonymizedComputerName systemd[1024]: Starting 
tracker-extract-3.service - Tracker metadata extractor...
Jun 12 21:41:41 AnonymizedComputerName systemd[1024]: Started 
wireplumber.service - Multimedia Service Session Manager.
Jun 12 21:41:41 AnonymizedComputerName systemd[1024]: Started 
pipewire-pulse.service - PipeWire PulseAudio.
Jun 12 21:41:41 AnonymizedComputerName systemd[1024]: Starting dbus.service - 
D-Bus User Message Bus...
Jun 12 21:41:41 AnonymizedComputerName systemd[1024]: Started dbus.service - 
D-Bus User Message Bus.
Jun 12 21:41:41 AnonymizedComputerName wireplumber[1045]: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jun 12 21:41:41 AnonymizedComputerName wireplumber[1045]: found session bus but 
no portal
Jun 12 21:41:41 AnonymizedComputerName pipewire-pulse[1046]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jun 12 21:41:41 AnonymizedComputerName pipewire-pulse[1046]: mod.rt: found 
session bus but no portal
Jun 12 21:41:41 AnonymizedComputerName pipewire[1043]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jun 12 21:41:41 AnonymizedComputerName pipewire[1043]: mod.rt: found session 
bus but no portal
The boot log contains no prior mentioning of xdg-desktop-portal, but the 
package xdg-desktop-portal itself is installed in version 1.16.0-2.  Either the 
error message is bogus, or something is really not found thought it should be 
there.  In any case, the situation should be repaired.  I use an up-to-date 
Debian stable “bookworm”.
Gratefully,
AlMa

Bug#1037446: RFP: golang-github-seancfoley-ipaddress-go -- Go library for handling IP addresses and subnets, both IPv4 and IPv6

[James McCoy]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pkg...@tracker.debian.org
Control: block 1037440 by -1

* Package name: golang-github-seancfoley-ipaddress-go
  Version : 1.5.4
  Upstream Contact: Sean C Foley
* URL : https://seancfoley.github.io/IPAddress/
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for handling IP addresses and subnets, both IPv4 
and IPv6

  IP address and network manipulation, CIDR, operations, iterations,
  containment checks, longest prefix match, subnetting, and data
  structures, with polymorphic code

This needed to package new upstream version of kitty.

Bug#1037445: RFP: golang-github-jamesruan-go-rfc1924 -- RFC1924 base85 encoding library for Go

[James McCoy]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pkg...@tracker.debian.org
Control: block 1037440 by -1

* Package name: golang-github-jamesruan-go-rfc1924
  Version : 0.0~20170108144916.git2767ca7c638f
  Upstream Contact: James Ruan
* URL : https://github.com/jamesruan/go-rfc1924
* License : Expat
  Programming Lang: Go
  Description : RFC1924 base85 encoding library for Go

This is needed to package new upstream version of kitty.

Bug#1037444: bookworm-pu: package kanboard/1.2.26+ds-4

[Joseph Nahmias]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: kanbo...@packages.debian.org, j...@nahmias.net
Control: affects -1 + src:kanboard

[ Reason ]
Security updates for kanboard since v1.2.26.

[ Tests ]
upstream's unit test suite are run at build time and via autopkgtest.
there are also some other (superficial) autopkgtests.

[ Risks ]
All listed CVEs have targeted fixes picked from upstream github.

[ 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

[ Other info ]

My first stable update, so please advise if I missed anything.
--Joe
diff -Nru kanboard-1.2.26+ds/debian/changelog 
kanboard-1.2.26+ds/debian/changelog
--- kanboard-1.2.26+ds/debian/changelog 2023-05-16 22:49:38.0 -0400
+++ kanboard-1.2.26+ds/debian/changelog 2023-06-07 20:45:40.0 -0400
@@ -1,3 +1,24 @@
+kanboard (1.2.26+ds-4) unstable; urgency=medium
+
+  * backport security fixes from kanboard v1.2.30
+ > CVE-2023-33956: Parameter based Indirect Object Referencing leading
+   to private file exposure
+ > CVE-2023-33968: Missing access control allows user to move and
+   duplicate tasks to any project in the software
+ > CVE-2023-33969: Stored XSS in the Task External Link Functionality
+ > CVE-2023-33970: Missing access control in internal task links feature
+(Closes: #1037167)
+
+ -- Joseph Nahmias   Wed, 07 Jun 2023 20:45:40 -0400
+
+kanboard (1.2.26+ds-3) unstable; urgency=medium
+
+  * backport fix for CVE-2023-32685 from kanboard v1.2.29
+
https://github.com/kanboard/kanboard/security/advisories/GHSA-hjmw-gm82-r4gv
+Based on upstream commits 26b6eeb & c9c1872. (Closes: #1036874)
+
+ -- Joseph Nahmias   Sun, 28 May 2023 21:42:46 -0400
+
 kanboard (1.2.26+ds-2) unstable; urgency=medium
 
   * properly test for lighty-enable-mod.
diff -Nru kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch 
kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch
--- kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch  1969-12-31 
19:00:00.0 -0500
+++ kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch  2023-05-28 
21:41:20.0 -0400
@@ -0,0 +1,111 @@
+Description: fix for CVE-2023-32685
+ Clipboard based cross-site scripting (blocked with default CSP)
+ https://github.com/kanboard/kanboard/security/advisories/GHSA-hjmw-gm82-r4gv
+Author: Frédéric Guillot 
+Origin: upstream
+Last-Update: 2023-05-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/assets/js/components/screenshot.js 
b/assets/js/components/screenshot.js
+index a8acd64..1130bd2 100644
+--- a/assets/js/components/screenshot.js
 b/assets/js/components/screenshot.js
+@@ -1,5 +1,4 @@
+ KB.component('screenshot', function (containerElement) {
+-var pasteCatcher = null;
+ var inputElement = null;
+ 
+ function onFileLoaded(e) {
+@@ -7,7 +6,6 @@ KB.component('screenshot', function (containerElement) {
+ }
+ 
+ function onPaste(e) {
+-// Firefox doesn't have the property e.clipboardData.items (only 
Chrome)
+ if (e.clipboardData && e.clipboardData.items) {
+ var items = e.clipboardData.items;
+ 
+@@ -24,69 +22,13 @@ KB.component('screenshot', function (containerElement) {
+ }
+ }
+ }
+-} else {
+-
+-// Handle Firefox
+-setTimeout(checkInput, 100);
+ }
+ }
+ 
+ function initialize() {
+-destroy();
+-
+-if (! window.Clipboard) {
+-// Insert the content editable at the top to avoid scrolling down 
in the board view
+-pasteCatcher = document.createElement('div');
+-pasteCatcher.id = 'screenshot-pastezone';
+-pasteCatcher.contentEditable = true;
+-pasteCatcher.style.opacity = 0;
+-pasteCatcher.style.position = 'fixed';
+-pasteCatcher.style.top = 0;
+-pasteCatcher.style.right = 0;
+-pasteCatcher.style.width = 0;
+-document.body.insertBefore(pasteCatcher, 
document.body.firstChild);
+-
+-pasteCatcher.focus();
+-
+-// Set the focus when clicked anywhere in the document
+-document.addEventListener('click', setFocus);
+-
+-// Set the focus when clicked in screenshot dropzone
+-
document.getElementById('screenshot-zone').addEventListener('click', setFocus);
+-}
+-
+ window.addEventListener('paste', onPaste, false);
+ }
+ 
+-function destroy() {
+-if (KB.exists('#screenshot-pastezone')) {
+-KB.find('#screenshot-pastezone').remove();
+-}
+-
+-document.removeEventListener('click', setFocus);
+-pasteCatcher = null;
+-}
+-
+-function 

Bug#1037252: golang-github-smallstep-cli: provide a binary package containing the step-cli executable

[Drew Parsons]

On 2023-06-12 11:25, Peymaneh wrote:
...
I originally intended to package the binary executable, but eventually 
gave up.


The problem is that smallstep-cli (and also its counterpart
smallstep-ca) require versions of golang-google-genproto-dev and
golang-google-grpc-dev that are stuck in experimental for a quite some
while now[1]. I had to strip out major parts in order to get the
smallstep libraries into bookworm at all.


Thanks for the update, Peymaneh. Hopefully with the new stable release 
now done, things can start rolling out of experimental again.


Drew

Bug#1005025: libdvd-pkg fails reporting that the dpkg database is locked

[Alban Browaeys]

Note that you have to run dpkg as root. Run as normal user, dpkg cannot
locak its lock file and error with error "2" (as it cannot lock its
lock file).

The libdvd-pkg script runs as root so if dpkg returns "2" in its script
then it means another program is holding the dpkg lock file.

Could you check if this bug is fixed?

It looks to me that if dpkg returns error "2" on success then it had a
bug. It might well have been fixed since then.

Else you might have had the dpkg lock held even after dpkg complete (I
don' know if this is possible). Thus dpkg itself would return error 2
because it cannot run as the its lock is held. This would also not be a
bug in libdvd-pkg bug a local leftover form a crash which is not in
libdvd-pkg scope to fix.

Could you close this bug report if the issue is no more on your system?



Cheers,
Alban

On Sat, 05 Feb 2022 18:58:09 +0100 Martin Strauss
 wrote:
> Package: libdvd-pkg
> Version: 1.4.2-1-1
> Severity: important
> X-Debbugs-Cc: mar...@clan-strauss.de
> 
> Dear Maintainer,
> 
> I upgraded from debian buster to bullseye. Afterwards libdvd-pkg
reported the
> following error:
> 
> libdvd-pkg: dpkg database is locked. You may need to use command
"sudo dpkg-
> reconfigure libdvd-pkg".
> libdvd-pkg: Building and installation of package(s) [libdvdcss2
libdvdcss-dev]
> postponed till after next APT operation.
> 
> This repeats for each "apt update". I spotted the same message on two
different
> computers, guess more people might be affected.
> The package should download libdvdcss2 build and install it, which it
doesn't
> because of the failed check.
> 
> I tried the proposed "dpkg-reconfigure libdvd-pkg" which just
produces the same
> message. After some internet search I found the debian bug report
#824093.
> There someone reported that the check had been broken and provided a
patch.
> The patch is applied in the current version, however it seems that
> the check for the lock is once again broken.
> 
> Basiclly it boils down to the following lines in the script:
> /usr/lib/libdvd-pkg/b-i_libdvdcss.sh line 20
> 
> dpkg -P non-existent-package 2>/dev/null
> if [ "$?" -eq 2 ]; then
> 
> It seems the with dpkg in version 1.20.9 the return code is always 2
> independent of whether a package manager like aptitude is running or
not.
> Same is true for "dpkg -i /dev/zero" which was the previous version.
> I checked this on the command line, the return code does not reflect
> the lock status.
> No idea how to fix this, the returned message is translated, so no
good
> to use that one. Maybe there is an official way how to do it,
searching the
> internet didn't help there. Maybe ask the dpkg maintainer?
> 
> -- System Information:
> Debian Release: 11.2
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'),
(500,
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (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 libdvd-pkg depends on:
> ii  build-essential    12.9
> ii  debconf [debconf-2.0]  1.5.77
> ii  debhelper  13.3.4
> ii  dh-autoreconf  20
> ii  wget   1.21-1+deb11u1

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

[Dirk Eddelbuettel]

On 12 June 2023 at 16:08, Steve Langasek wrote:
| On Mon, Jun 12, 2023 at 05:22:39PM -0500, Dirk Eddelbuettel wrote:
| >   edd@rob:~$ cat deb/bh/debian/control 
| >   Source: r-cran-bh
| >   Section: gnu-r
| >   Priority: optional
| >   Maintainer: Dirk Eddelbuettel 
| >   Build-Depends: debhelper-compat (= 11), r-base-dev (>= 4.1.1), dh-r
| >   Standards-Version: 4.6.0
| >   Vcs-Browser: https://salsa.debian.org/edd/r-cran-bh
| >   Vcs-Git: https://salsa.debian.org/edd/r-cran-bh.git
| >   Homepage: https://cran.r-project.org/package=BH
| 
| >   Package: r-cran-bh
| >   Architecture: all
| >   Multi-Arch: foreign
| >   Depends: ${misc:Depends}, libboost-dev (>= 1.74.0)
| >   Description: (Virtual) GNU R package to provide BH
| >The CRAN package BH provides a (large) subset of Boost.  This package 
tricks
| >R into believing BH is installed when we just depend on the 
distribution's
| >Boost packages.  The actual set of Boost libraries could get fine-tuned. 
In
| >short, we avoid doubling up the 140+ mb of the 'BH' package which are 
alredy
| >in libboost-dev.
| >   edd@rob:~$ 
| 
| > So it isn't "really" 1.74, that is simply the last time we edited the shell
| > that this provides.  Hence "no bumping".  We have to wait for 1.81.
| 
| boost1.81 is already available in Debian but is not yet the version pointed
| to by boost-defaults; this is what I meant by depending on libboost1.81-dev
| instead of libboost-dev - no need to duplicate the boost contents, just
| change the dependency.

I missed that. So I could just roll the virtual one. I like that.
 
| You would eventually want to change it back, of course, so that you aren't
| stuck on boost1.81 when something *newer* becomes the default in Debian.
| 
| And the boost1.81 transition already has a bug open for it:
| 
|   https://bugs.debian.org/1028489
| 
| For my part, I don't mind if fixing this waits until boost1.81 becomes the
| default.  I only wanted to point out the options.

No, that is slick. Thanks for pointing it out.

When do we re-open testing?  I have a few dozen uploads in experimental I
need to move too.

Dirk


-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1033341: org-mode: CVE-2023-28617

[Nicholas D Steeves]

David Bremner  writes:

> Nicholas D Steeves  writes:
>
>> fixed 1033341 org/mode/9.5.2+dfsh-5
>> fixed 1033341 org-mode/9.6.6+dfsg-1~exp1
>> thanks
>
> Are you sure about that? It depends on emacs 28.2, which afaik has the
> vulnerable org-mode embedded. I guess it's a question of interpretation,
> but the vulnerability is still there after installing the package.

Wasn't the fix in emacs 1:28.2+1-14 two months ago?  Meanwhile the new
empty org-mode 9.5.2+dfsh-5 won't be able to shadow the (fixed) bundled
copy.  Thanks again for that work!

This was also in bullseye in emacs 26.1+1-3.2+deb10u4

After uploading to bullseye-updates I'll upload 9.6.6 to unstable.

I'd rather let someone else take care of buster, if we're still
supporting it.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1037270: ITP: node-ftp -- FTP client module for node.js

[Gunnar Wolf]

Israel Galadima dijo [Fri, Jun 09, 2023 at 11:59:35PM +0100]:
> * Package name: node-ftp
>   Version : 0.3.10
>   Upstream Author : Brian White 
> * URL : * https://github.com/mscdex/node-ftp
> *
> * License : Expat
>   Programming Lang: JavaScript
>   Description : FTP client module for node.js
> 
> An FTP client module for node.js that provides an asynchronous interface
> for communicating with an FTP server.
> 
> This package is part of my effort to package corepack for Debian.

It's time to let FTP die! It is a terrible protocol, in so many
levels. The world would be better served if the energy invested in
packaging yet-another-FTP-client is rather used in helping
yet-another-obsolete-service-served-by-FTP migrate by something that
belongs to the current millenium :-\

(Of course, I'm nobody to oppose you working in whatever you wish to,
and your upstreams might be requiring this for $reasons... but still,
had to say it!)

Bug#1037175: [preapproval] bullseye-pu: package org-mode/9.4.0+dfsg-1+deb11u1

[Nicholas D Steeves]

Control: block 1033341 by -1

Dear Salvatore and release team,

Salvatore Bonaccorso  writes:

> On Tue, Jun 06, 2023 at 11:00:14PM -0400, Nicholas D Steeves wrote:
>> +org-mode (9.4.0+dfsg-1+deb11u1) bullseye-security; urgency=medium
>> +
>> +  * Fix Org Mode command injection vulnerability CVE-2023-28617 by 
>> backporting
>> +0004-Org-Mode-vulnerability-CVE-2023-28617-is-fixed.patch like src:emacs
>> +did (Closes: #1033341).  Thanks to Rob Browning's work in that package,
>> +fixing org-mode was trivially easy!
>> +
>> + -- Nicholas D Steeves   Sun, 04 Jun 2023 13:26:52 -0400
>
> Small remark, for the bullseye pu update please target at 'bullseye'
> not 'bullseye-security'.
>

Done.  That was actually my first instinct, but I thought the existence
of a CVE would destine the upload to the -security queue!  I was wrong,
but this is a teaching/learning moment.

Is it as simple as: Use the -security queue when a DSA is needed,
otherwise use the normal distribution code name and the foo-updates
queue?  No need to explain if it's more complicated and if you're busy.
(I couldn't find documentation of this in the Dev Ref)

Updated debdiff attached.

Regards,
Nicholas


9.4.0+dfsg-1__to__9.4.0+dfsg-1.debdiff
Description: debdiff


signature.asc
Description: PGP signature

Bug#1037443: ansible-core: Please update to current version to match resolvelib in unstable

[Scott Kitterman]

Source: ansible-core
Version: 2.14.3-1
Severity: important

It looks like the current ansible-core is compatible with the resolvelib
in Unstable.  It would be great if you could update the package.

Scott K

Bug#1036263: Package can be built just fine

[Hilko Bengen]

Hi,

At least as of 1.50.1-1, the pacakge builds just fine, cf.
https://buildd.debian.org/status/fetch.php?pkg=guestfs-tools=amd64=1.50.1-1=1686585170=0

Cheers,
-Hilko

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

[Steve Langasek]

On Mon, Jun 12, 2023 at 05:22:39PM -0500, Dirk Eddelbuettel wrote:
>   edd@rob:~$ cat deb/bh/debian/control 
>   Source: r-cran-bh
>   Section: gnu-r
>   Priority: optional
>   Maintainer: Dirk Eddelbuettel 
>   Build-Depends: debhelper-compat (= 11), r-base-dev (>= 4.1.1), dh-r
>   Standards-Version: 4.6.0
>   Vcs-Browser: https://salsa.debian.org/edd/r-cran-bh
>   Vcs-Git: https://salsa.debian.org/edd/r-cran-bh.git
>   Homepage: https://cran.r-project.org/package=BH

>   Package: r-cran-bh
>   Architecture: all
>   Multi-Arch: foreign
>   Depends: ${misc:Depends}, libboost-dev (>= 1.74.0)
>   Description: (Virtual) GNU R package to provide BH
>The CRAN package BH provides a (large) subset of Boost.  This package 
> tricks
>R into believing BH is installed when we just depend on the distribution's
>Boost packages.  The actual set of Boost libraries could get fine-tuned. In
>short, we avoid doubling up the 140+ mb of the 'BH' package which are 
> alredy
>in libboost-dev.
>   edd@rob:~$ 

> So it isn't "really" 1.74, that is simply the last time we edited the shell
> that this provides.  Hence "no bumping".  We have to wait for 1.81.

boost1.81 is already available in Debian but is not yet the version pointed
to by boost-defaults; this is what I meant by depending on libboost1.81-dev
instead of libboost-dev - no need to duplicate the boost contents, just
change the dependency.

You would eventually want to change it back, of course, so that you aren't
stuck on boost1.81 when something *newer* becomes the default in Debian.

And the boost1.81 transition already has a bug open for it:

  https://bugs.debian.org/1028489

For my part, I don't mind if fixing this waits until boost1.81 becomes the
default.  I only wanted to point out the options.

-- 
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#1037442: crontab manual outdated

[Tobias Köck]

Package: cron
Version: 3.0pl1-162
Severity: normal

The

man 5 crontab

will show an outdated version.

E.g. the labels aren't there anymore

@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
@annually (same as @yearly)
@monthly Run once a month, "0 0 1 * *".
@weekly Run once a week, "0 0 * * 0".
@daily Run once a day, "0 0 * * *".
@midnight (same as @daily)
@hourly Run once an hour, "0 * * * *".

and at the end is 1994 instead of 2010. There seem to be a problem with
the documentation.

Greetings
Tobias


-- Package-specific info:
--- EDITOR:


--- /usr/bin/editor:
/usr/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 68032 Mar  2 07:33 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 Jun 12 17:31 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Jun 12 18:11 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Jun 12 19:29 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Jun 12 17:33 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Jun 12 17:31 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Jun 12 17:31 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Jun 12 17:33 /etc/cron.weekly


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: arm64 (aarch64)

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

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-162
ii  init-system-helpers  1.65.2
ii  libc62.36-9
ii  libpam-runtime   1.5.2-6
ii  libpam0g 1.5.2-6
ii  libselinux1  3.4-1+b6
ii  sensible-utils   0.0.17+nmu1

Versions of packages cron recommends:
ii  postfix [mail-transport-agent]  3.7.5-2

Versions of packages cron suggests:
pn  anacron
pn  checksecurity  
ii  logrotate  3.21.0-1

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
pn  nscd  

-- no debconf information

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

[Dirk Eddelbuettel]

Hi Steve,

On 12 June 2023 at 14:41, Steve Langasek wrote:
| Package: r-cran-bh
| Version: 1.74.0-2
| User: ubuntu-de...@lists.ubuntu.com
| Usertags: origin-ubuntu mantic
| Affects: r-cran-rstan/2.21.8-1
| 
| Hi Dirk,
| 
| r-cran-rstan 2.21.8-1 is failing to build from source in Debian and Ubuntu
| on 32-bit architectures because it exhausts the 32-bit virtual memory space.
| 
| The r-cran-rstan maintainer has reported this upstream at
| , where it's been noted that
| the module builds on 32-bit when using the upstream CRAN BH, which points to
| boost 1.81 headers whereas the r-cran-bh package in Debian is still at boost
| 1.74.
| 
| I've tested locally, and find that depending on libboost1.81-dev instead of
| libboost-dev (1.74) works.  The boost 1.74->1.81 transition will happen in
| the trixie cycle, but does it make sense to bump r-cran-bh ahead of time?

This is a hard problem.

For R, which is pretty good at 'abstracting the os layer' I maintain its
package BH (in the role of upstream author / "assembler") which expands to
about 156mb installed  as Boost is so big:

  edd@rob:~$ du -csh /usr/local/lib/R/site-library/BH
  156M/usr/local/lib/R/site-library/BH
  156Mtotal
  edd@rob:~$ 

Way back when when I started with BH I used the sources of what what was in
Debian, that way they were in sync. And kept updating when Debian updated.
That drifted, and R users (via CRAN) wanted something newer.  Boost updates
three times a year (Apr + Aug + Dec) and for the last few years I updated
once in Dec.  So that is why CRAN is now ahead with 1.81 (upstream is at
1.82), and that is what (r)stan wants.

But we probably do not want BH in Debian because it is 'Yuge'. (We could
though, maybe worth discussing.)  So for the last few years _Debian's_
r-cran-bh was an empty virtual package dependending on what Debian has as
libboost* (particularly the headers only):

  edd@rob:~$ cat deb/bh/debian/control 
  Source: r-cran-bh
  Section: gnu-r
  Priority: optional
  Maintainer: Dirk Eddelbuettel 
  Build-Depends: debhelper-compat (= 11), r-base-dev (>= 4.1.1), dh-r
  Standards-Version: 4.6.0
  Vcs-Browser: https://salsa.debian.org/edd/r-cran-bh
  Vcs-Git: https://salsa.debian.org/edd/r-cran-bh.git
  Homepage: https://cran.r-project.org/package=BH
  
  Package: r-cran-bh
  Architecture: all
  Multi-Arch: foreign
  Depends: ${misc:Depends}, libboost-dev (>= 1.74.0)
  Description: (Virtual) GNU R package to provide BH
   The CRAN package BH provides a (large) subset of Boost.  This package tricks
   R into believing BH is installed when we just depend on the distribution's
   Boost packages.  The actual set of Boost libraries could get fine-tuned. In
   short, we avoid doubling up the 140+ mb of the 'BH' package which are alredy
   in libboost-dev.
  edd@rob:~$ 

So it isn't "really" 1.74, that is simply the last time we edited the shell
that this provides.  Hence "no bumping".  We have to wait for 1.81.

(Or we decide to pull the bandaid and inject 150mb of BH as r-cran-bh.  At
least it will be Architecture: all as a header-only package.)

Thoughts from your side? Is any of this making sense to you?  Happy to chat
more.

Thanks as always for looking after Debian and Ubuntu!

Best,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1037441: RFP: golang-github-altree-bigfloat -- Additional operations for the standard library big.Float type

[James McCoy]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: team+pkg...@tracker.debian.org
Control: block 1037440 by -1

* Package name: golang-github-altree-bigfloat
  Version : 0.0~20220102081255.git38c8b72a9924
  Upstream Contact: Alberto Donizetti
* URL : https://github.com/ALTree/bigfloat
* License : Expat
  Programming Lang: Go
  Description : Additional operations for the standard library big.Float 
type

  Package bigfloat provides the implementation of a few additional
  operations (square root, exponentiation, natural logarithm, exponential
  function) for the standard library big.Float type.

This is needed to package new upstream version of kitty.

Bug#1037440: kitty: New upstream release

[James McCoy]

Source: kitty
Severity: wishlist

Filing this to track new packages/package updates which are blocking an
update of kitty.


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

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

-- no debconf information

Bug#994081: libdvd-pkg: 1.4.3-1-1 Upgrade Results in 'apt-get check' Failure

[Alban Browaeys]

Package: libdvd-pkg
Version: 1.4.3-1-1
Followup-For: Bug #994081

Dear Maintainer,
TL;DR: could apt-get be called with "--dry-run" a flag when we call its
"check" command as to get libdvd-pkg triggers script to run?



The error trigger on each installi (or reinstall) or removal of a package.
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...

Adding "set -x" to /usr/lib/libdvd-pkg/b-i_libdvdcss.sh
and removing the stdout and stderr redirection from the "apt-get check"
and "dpkg -P nonexistent-package" calls, I get:

+ . /usr/lib/libdvd-pkg/VARS
+ PKGI=libdvd-pkg
+ DIR=/usr/src/libdvd-pkg
+ PKGG=libdvdcss2
+ PKGG_ALL=libdvdcss2 libdvdcss-dev
+ P88=88libdvdcss-pkg
+ VERGG=1.4.3-1
+ dpkg --status libdvdcss2
+ perl -0ne print $1 if m{^Status:\s+install\s+ok\s+installed}sm and 
m{^Version:\s+(\S+)}sm;
+ VERG=1.4.2-1~local
+ dpkg --compare-versions 1.4.3-1~local gt 1.4.2-1~local
+ [ 0 = 0 ]
+ [ -f /usr/src/libdvd-pkg/libdvdcss2-1.4.3-1.is-installed ]
+ dpkg -P non-existent-package
dpkg: warning: ignoring request to remove non-existent-package which isn't 
installed
+ [ 0 -eq 2 ]
+ [ ! -s /usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2 ]
+ echo libdvd-pkg: Checking orig.tar integrity...
libdvd-pkg: Checking orig.tar integrity...
+ sha256sum --check --strict 
/usr/share/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2.sha256
/usr/src/libdvd-pkg/libdvdcss_1.4.3.orig.tar.bz2: OK
+ [ 0 -ne 0 ]
+ apt-get check
E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 
2522949 (apt)
N: Be aware that removing the lock file is not a solution and may break your 
system.
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is 
another process using it?
+ [ 100 -ne 0 ]
+ echo libdvd-pkg: `apt-get check` failed, you may have broken packages. 
Aborting...
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
+ exit 0


dpkg only check for /var/lib/dpkg/lock and /var/lib/dpkg/triggers/Lock

"apt-get check" always fails in a trigger as
[200~/var/lib/dpkg/lock-frontend is locked by the parent apt.
So the whole script is nowadays a noop.

I believe passing the "--dry-run" flag to "apt-get check" would keep the
consistency check and allow to the script to fulfill its duty.


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

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

Versions of packages libdvd-pkg depends on:
ii  build-essential   12.9
ii  debconf [debconf-2.0] 1.5.82
ii  debhelper [debhelper-compat]  13.11.4
ii  devscripts2.23.4
ii  wget  1.21.3-1+b2

Versions of packages libdvd-pkg recommends:
ii  libcap2-bin  1:2.66-4

libdvd-pkg suggests no packages.

-- debconf information:
* libdvd-pkg/build: true
  libdvd-pkg/post-invoke_hook-remove: false
  libdvd-pkg/upgrade:
* libdvd-pkg/post-invoke_hook-install: true
  libdvd-pkg/title_u:
* libdvd-pkg/first-install:
  libdvd-pkg/title_b-i:

-- debsums errors found:
debsums: changed file /usr/lib/libdvd-pkg/b-i_libdvdcss.sh (from libdvd-pkg 
package)

Bug#999850: More progress

[Jelmer Vernooij]

Current status, left:

 * charset: packaged, fails to build
 * mailparse: packaged, not yet uploaded (depends on charset)
 * python-pkginfo: packaged, not yet uploaded (depends on mailparse)
 * pep508-rs: in NEW
 * pyproject-toml: uploaded to NEW
 * pyo3-log: in NEW

Jelmer

Bug#1037113: Should not be in /usr/games

[Dirk Eddelbuettel]

reassign 1037113 screen-message
thanks

Binary package 'sm' is from source package 'screen-message'

Binary package 'r-cran-sm' is from source package 'sm', which I maintain, and
something totally different :-)   Not the first crossed bug report so no
worries, the reassign should work.

Cheers,  Dirk

On 4 June 2023 at 23:35, Josh Triplett wrote:
| Package: sm
| Version: 0.26-3
| Severity: minor
| X-Debbugs-Cc: j...@joshtriplett.org
| 
| sm is a useful utility for a wide variety of purposes. I don't think it
| belongs in /usr/games. Please consider relocating it to /usr/bin.
| 
| Thank you for maintaining sm!

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1037391: debian-installer: xorg configuration fails when booting d-i graphical mode on netinst iso under virtualbox

[Pascal Hambourg]

On 12/06/2023 at 12:51, Jonathan Carter wrote:


When booting the debian-12.0.0-amd64-netinst.iso image in VirtualBox
(7.0.8-dfsg-2 from unstable/contrib) under UEFI and selecting
the Graphical Install (default) option, Xorg fails to start,
apparently due to being incorrectly configured or incorrectly detecting
the hardware.


According to someone experiencing the same issue, a workaround is to set 
para-virtualization to legacy in virtualbox settings.

Bug#1037439: r-cran-rstan/armhf FTBFS with r-cran-bh 1.74, works with boost 1.81

[Steve Langasek]

Package: r-cran-bh
Version: 1.74.0-2
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic
Affects: r-cran-rstan/2.21.8-1

Hi Dirk,

r-cran-rstan 2.21.8-1 is failing to build from source in Debian and Ubuntu
on 32-bit architectures because it exhausts the 32-bit virtual memory space.

The r-cran-rstan maintainer has reported this upstream at
, where it's been noted that
the module builds on 32-bit when using the upstream CRAN BH, which points to
boost 1.81 headers whereas the r-cran-bh package in Debian is still at boost
1.74.

I've tested locally, and find that depending on libboost1.81-dev instead of
libboost-dev (1.74) works.  The boost 1.74->1.81 transition will happen in
the trixie cycle, but does it make sense to bump r-cran-bh ahead of time?

-- 
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#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

[Axel Beckert]

Hi Kristoffer,

Kristoffer Brånemyr wrote:
> But I think it's a bit suspicious that it only crashes sometimes.If
> there was some instruction which causes this, should it not happen
> everytime?

Good point.

> Can you reproduce the problem running cksum in gdb?

Yes:

# dd if=/dev/urandom count=1 2> /dev/null | gdb -ex run -ex bt -batch cksum
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGILL, Illegal instruction.
0x5556ccf5 in cksum_pclmul (fp=0x77faca80 <_IO_2_1_stdin_>, 
crc_out=0x7fffe8d0, length_out=0x7fffe8c8) at src/cksum_pclmul.c:59
59  src/cksum_pclmul.c: No such file or directory.
#0  0x5556ccf5 in cksum_pclmul (fp=0x77faca80 <_IO_2_1_stdin_>, 
crc_out=0x7fffe8d0, length_out=0x7fffe8c8) at src/cksum_pclmul.c:59
#1  0xabb0 in crc_sum_stream (stream=0x77faca80 
<_IO_2_1_stdin_>, resstream=0x7fffe9f0, length=0x7fffe9e8) at 
src/cksum.c:269
#2  0x7eaa in digest_file (filename=filename@entry=0x5556d14f 
"-", bin_result=bin_result@entry=0x7fffe9f0 '/' , "\377", 
missing=missing@entry=0x7fffe9e0, length=length@entry=0x7fffe9e8, 
binary=) at src/digest.c:945
#3  0x71c7 in main (argc=1, argv=) at 
src/digest.c:1504

Does this help?

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#1037350: Package: installation-reports

[Holger Wansing]

Control: retitle -1 installation-reports: grub not installed (correctly)



-- 
Sent from /e/ OS on Fairphone3

Bug#1035820: 9base: leaves entries in /etc/shells after upgrade from bullseye

[Andreas Beckmann]

Now I'm really confused:

I start with an unmerged sid chroot, install 9base there.
Then I remove /etc/unsupported-skip-usrmerge-conversion and install 
usrmerge.


Now /etc/shells contains

# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc
/usr/bin/sh
/usr/bin/bash
/usr/bin/rbash
/usr/bin/dash
/usr/bin/rc

and /var/lib/shells.state

/bin/bash
/bin/rbash
/bin/dash
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc

Then I run update-shells which does not modify /etc/shells, but the 
statefile now contains


/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc

So the /bin entries for bash/rbash/dash get their /usr counterparts 
added, but /bin/rc does not.



OK, back to the minimal unmerged sid chroot, without 9base this time.

After installation of usrmerge and successful conversio /etc/shells contains

# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash
/usr/bin/sh
/usr/bin/bash
/usr/bin/rbash
/usr/bin/dash

and /var/lib/shells.state contains

/bin/bash
/bin/rbash
/bin/dash

Then I delete all /usr/bin entries from /etc/shells
(sed -i /usr/d /etc/shells) and run update-shells, resulting in 
/etc/shells containing


# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash
/usr/bin/bash
/usr/bin/rbash
/usr/bin/dash

(i.e. only /usr/bin/sh is missing compared to the file made by usrmerge)

and the statefile contains

/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash

This seems to imply that usrmerge could call update-shells to perform 
most of the changes it does to /etc/shells. (And to update 
/var/lib/shells.state at the same time)


... later ... much later ...

After reading update-shells several times (and still not fully getting 
how it works (or at least should work)), I think its behavior is not 
well defined in the context of alternatives as used by 9base.


At least this line seems to be wrong:

realshell=$(dirname "$(dpkg-realpath --root "$ROOT" 
"$line")")/$(basename "$line")


It resolves e.g. /usr/bin/clang++-14 to
non-existant /usr/lib/llvm-14/bin/clang++-14

Shouldn't that rather be

realshell=$(dpkg-realpath --root "$ROOT" "$(dirname 
"$line")")/$(basename "$line")



Andreas

Bug#1037438: O: cmatrix -- simulates the display from "The Matrix"

[Boyuan Yang]

Package: wnpp
Severity: normal

I intend to orphan package cmatrix https://tracker.debian.org/pkg/cmatrix to
reduce my personal package maintenance burden in Debian. This package is
currently in good condition and the future maintenance shall not be time-
consuming. Some investigation to https://bugs.debian.org/741874 may be
needed.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: cmatrix
Binary: cmatrix, cmatrix-xfont
Version: 2.0-3
Maintainer: Boyuan Yang 
Build-Depends: console-setup-linux, debhelper-compat (= 13), kbd,
libncurses-dev
Architecture: any all
Standards-Version: 4.5.1
Format: 3.0 (quilt)
Files:
 d3eb5e46a56f21c77d78e0c39a73a800 1901 cmatrix_2.0-3.dsc
 c2aee6d44c4d46df6f16dca2a3dc18ad 205640 cmatrix_2.0.orig.tar.gz
 9115c353480835ccd1f8059925eb2111 4436 cmatrix_2.0-3.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/cmatrix
Vcs-Git: https://salsa.debian.org/debian/cmatrix.git
Checksums-Sha256:
 5ebd9ada61d702f5cae734e92bfd7b7b656b0342fdd0e316ca7e39c04cf2cf2c 1901
cmatrix_2.0-3.dsc
 ad93ba39acd383696ab6a9ebbed1259ecf2d3cf9f49d6b97038c66f80749e99a 205640
cmatrix_2.0.orig.tar.gz
 0f13ddfee05685592b9126300c54d6ea1b182ae530b4c692754fb49c387e7a22 4436
cmatrix_2.0-3.debian.tar.xz
Homepage: https://github.com/abishekvashok/cmatrix
Package-List: 
 cmatrix deb misc optional arch=any
 cmatrix-xfont deb x11 optional arch=all
Directory: pool/main/c/cmatrix
Priority: source
Section: misc


Thanks,
Boyuan Yang


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

Bug#1037437: From fresh bookworm install default sshd jail in fail2ban won’t work without rsyslog installed

[Pèpié Trente Quatre]

Package: fail2ban
Version: 1.0.2-2

>From fresh bookworm installation, In fail2ban, the sshd jail which is
enable by default won’t work without rsyslog installed. The fail2ban
service then fails to start.

Bug#1037436: getxattr mishandles symlinks

[Marc Haber]

Package: aide
Version: 0.17.3-4+deb11u1
Severity: important
Tags: upstream

Hi,

this applies to aide in bullseye, bookworm and sid. As discussed in
https://github.com/aide/aide/issues/156, getxattr in do_md.c should be
lgetxattr instead. Upstream patch is
https://github.com/aide/aide/commit/04b34dd46292dedf830ef2366a8869a31488

A patched version will go to unstable first, I will then prepare and
coordinate updates for bookworm and bullseye via stable proposed updates
for the next point release, together with the fix for #1037171.

Greetings
Marc

Bug#1037350: Package: installation-reports

[Holger Wansing]

Control: rename -1 installation-reports: grub not installed (correctly)



Am 11. Juni 2023 22:45:34 MESZ schrieb Peter Ehlert :
>Package: installation-reports
>
>Boot method: USB
>Image version: debian-12.0.0-amd64-netinst.iso
>Date: 2023-06-11 9-16-23
>
>Machine: Type: Desktop System: Hewlett-Packard product: HP Z820 Workstation
>Processor: CPU: 2x 8-core Intel Xeon E5-2687W 0 (-MT MCP SMP-)
>Memory: Mem: 1310.8/48189.1 MiB (2.7%) Storage: 9.32 TiB (3.2% used)
>Partitions: 
>
>$ df -Tl
>Filesystem Type 1K-blocks    Used Available Use% Mounted on
>udev   devtmpfs  24639364   0  24639364   0% /dev
>tmpfs  tmpfs  4934568    2036   4932532   1% /run
>/dev/sdb24 ext4  28660644 4437152  22742276  17% /
>tmpfs  tmpfs 24672828   0  24672828   0% /dev/shm
>tmpfs  tmpfs 5120  12  5108   1% /run/lock
>/dev/sdb26 ext4  19046484    1228  18052388   1% /home
>tmpfs  tmpfs  4934564  80   4934484   1% /run/user/1000
>
>
>
>Output of lspci -knn (or lspci -nn):
>
>$ lspci -knn
>00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 [8086:3c00] 
>(rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 DMI2 [103c:158b]
>00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 1a [8086:3c02] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 1a [103c:158b]
>    Kernel driver in use: pcieport
>00:01.1 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 1b [8086:3c03] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 1b [103c:158b]
>    Kernel driver in use: pcieport
>00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 2a [8086:3c04] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 2a [103c:158b]
>    Kernel driver in use: pcieport
>00:03.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 3a in PCI Express Mode [8086:3c08] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 3a in PCI Express Mode [103c:158b]
>    Kernel driver in use: pcieport
>00:05.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Address 
>Map, VTd_Misc, System Management [8086:3c28] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Address Map, VTd_Misc, 
>System Management [103c:158b]
>00:05.2 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Control 
>Status and Global Errors [8086:3c2a] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Control Status and 
>Global Errors [103c:158b]
>00:05.4 PIC [0800]: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c] 
>(rev 07)
>    Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c]
>00:11.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
>Express Virtual Root Port [8086:1d3e] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset PCI Express 
>Virtual Root Port [103c:158b]
>    Kernel driver in use: pcieport
>00:16.0 Communication controller [0780]: Intel Corporation C600/X79 series 
>chipset MEI Controller #1 [8086:1d3a] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset MEI Controller 
>[103c:158b]
>    Kernel driver in use: mei_me
>    Kernel modules: mei_me
>00:16.2 IDE interface [0101]: Intel Corporation C600/X79 series chipset IDE-r 
>Controller [8086:1d3c] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset IDE-r 
>Controller [103c:158b]
>    Kernel driver in use: ata_generic
>    Kernel modules: ata_generic
>00:16.3 Serial controller [0700]: Intel Corporation C600/X79 series chipset KT 
>Controller [8086:1d3d] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset KT Controller 
>[103c:158b]
>    Kernel driver in use: serial
>00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
>Connection (Lewisville) [8086:1502] (rev 05)
>    DeviceName: Onboard LAN
>    Subsystem: Hewlett-Packard Company 82579LM Gigabit Network Connection 
>(Lewisville) [103c:158b]
>    Kernel driver in use: e1000e
>    Kernel modules: e1000e
>00:1a.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset USB2 
>Enhanced Host Controller #2 [8086:1d2d] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 Enhanced 
>Host Controller [103c:158b]
>    Kernel driver in use: ehci-pci
>    Kernel modules: ehci_pci
>00:1b.0 Audio device [0403]: Intel Corporation C600/X79 series chipset High 
>Definition Audio Controller [8086:1d20] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset High Definition 
>Audio Controller [103c:158b]
>    Kernel driver in use: snd_hda_intel
>    Kernel modules: snd_hda_intel
>00:1c.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
>Express 

Bug#1035635: tox: Upgrading to tox 4

[Stefano Rivera]

Hi Release Team!

For the tox 4 transition, I have changes in dh-python staged (and in
experimental) but the autopkgtests require tox 4, so I can't upload them
until we're ready to pull the trigger on the transition.

All the fallout I could find is documented in blocking bugs of this bug
and the dh-python bug (1035675).

Some of the fixes were staged in experimental, because we were in freeze
at the time.

Some of the packages need upstream work, and would have to be removed
from testing for the transition.

Please let me know when we should go ahead with this.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#969482: Update golang-github-xanzy-go-gitlab from 0.73 to 0.85

[Julian Gilbey]

Dear Nicolas,

On Mon, Jun 12, 2023 at 11:37:47AM +0200, Nicolas Schier wrote:
> Dear go-packaging-team,
> 
> for packaging the 'glab' CLI tool [1] we need golang-github-xanzy-go-gitlab >=
> 0.83.  For my local packaging test I prepared an update to 0.85 and created
> corresponding merge-requests:

Thanks!  That sounds like good work (and very up-to-date :).

I haven't looked at this package in a very long time, so don't feel
able to comment on it.  Would whoever uploads it be able to remove me
from the Uploaders field?

Hopefully Anthony (who did the last upload) might be able to do this
upload.

Best wishes,

   Julian

Bug#1037435: ojalgo tests using the network at build time (again)

[Steve Langasek]

Package: ojalgo
Version: 52.0.1+ds-1
Severity: serious
Tags: patch
Justification: Policy 4.9
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Hi Pierre,

The ojalgo package has been failing to build from source in Ubuntu, because
its tests are trying to access the network:

[...]
[ERROR] Failures: 
[ERROR]   YahooDataSourceTest.testFetchDaily:54 No data!
[ERROR]   YahooDataSourceTest.testFetchMonthly:62 No data!
[ERROR]   YahooDataSourceTest.testFetchWeekly:70 No data!
[ERROR]   
YahooDataSourceTest.testYahooDailyAAPL:79->FinanceSeriesTests.assertAtLeastExpectedItems:64
 No data!
[ERROR]   
YahooDataSourceTest.testYahooMonthlyAAPL:87->FinanceSeriesTests.assertAtLeastExpectedItems:64
 No data!
[ERROR]   
YahooDataSourceTest.testYahooWeeklyAAPL:95->FinanceSeriesTests.assertAtLeastExpectedItems:64
 No data!
[ERROR] Errors: 
[ERROR]   
YahooDataSourceTest.testDeriveDistributions:47->FinanceSeriesTests.doTestDeriveDistribution:84
 » NegativeArraySize
[ERROR]   OptimisationServiceTest.testEnvironment:67 » Runtime 
java.util.concurrent.Exec...
[ERROR]   OptimisationServiceTest.testTest:55 » Runtime 
java.util.concurrent.ExecutionEx...
[ERROR]   OptimisationServiceTest.testVeryBasicModel:41 » Runtime 
java.util.concurrent.E...
[...]

  (https://launchpad.net/ubuntu/+source/ojalgo/52.0.1+ds-1/+build/26010077)

There was already a patch in the source to disable network tests, but it
appears that some new network tests have now been added.  I've extended the
patch to disable these tests as well; please see the attached diff.

Thanks for considering,
-- 
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
diff -Nru ojalgo-52.0.1+ds/debian/patches/no_network_tests.patch 
ojalgo-52.0.1+ds/debian/patches/no_network_tests.patch
--- ojalgo-52.0.1+ds/debian/patches/no_network_tests.patch  2023-01-18 
13:33:30.0 -0800
+++ ojalgo-52.0.1+ds/debian/patches/no_network_tests.patch  2023-06-12 
12:54:52.0 -0700
@@ -4,8 +4,10 @@
 Reviewed-by: Pierre Gruet 
 Last-Update: 2022-12-17
 
 
a/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageDataSourceTest.java
-+++ 
b/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageDataSourceTest.java
+Index: 
ojalgo-52.0.1+ds/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageDataSourceTest.java
+===
+--- 
ojalgo-52.0.1+ds.orig/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageDataSourceTest.java
 
ojalgo-52.0.1+ds/src/test/java/org/ojalgo/data/domain/finance/series/AlphaVantageDataSourceTest.java
 @@ -22,6 +22,7 @@
   */
  package org.ojalgo.data.domain.finance.series;
@@ -22,3 +24,43 @@
  public class AlphaVantageDataSourceTest extends FinanceSeriesTests {
  
  public AlphaVantageDataSourceTest() {
+Index: 
ojalgo-52.0.1+ds/src/test/java/org/ojalgo/data/domain/finance/series/YahooDataSourceTest.java
+===
+--- 
ojalgo-52.0.1+ds.orig/src/test/java/org/ojalgo/data/domain/finance/series/YahooDataSourceTest.java
 
ojalgo-52.0.1+ds/src/test/java/org/ojalgo/data/domain/finance/series/YahooDataSourceTest.java
+@@ -22,6 +22,7 @@
+  */
+ package org.ojalgo.data.domain.finance.series;
+ 
++import org.junit.jupiter.api.Disabled;
+ import org.junit.jupiter.api.Test;
+ import org.ojalgo.TestUtils;
+ import org.ojalgo.type.CalendarDateUnit;
+@@ -31,6 +32,7 @@
+  *
+  * @author apete
+  */
++@Disabled("Requires network access")
+ public class YahooDataSourceTest extends FinanceSeriesTests {
+ 
+ private static YahooSession SESSION = new YahooSession();
+Index: 
ojalgo-52.0.1+ds/src/test/java/org/ojalgo/optimisation/service/OptimisationServiceTest.java
+===
+--- 
ojalgo-52.0.1+ds.orig/src/test/java/org/ojalgo/optimisation/service/OptimisationServiceTest.java
 
ojalgo-52.0.1+ds/src/test/java/org/ojalgo/optimisation/service/OptimisationServiceTest.java
+@@ -1,6 +1,7 @@
+ package org.ojalgo.optimisation.service;
+ 
+ import org.junit.jupiter.api.AfterEach;
++import org.junit.jupiter.api.Disabled;
+ import org.junit.jupiter.api.Test;
+ import org.ojalgo.TestUtils;
+ import org.ojalgo.netio.BasicLogger;
+@@ -9,6 +10,7 @@
+ import org.ojalgo.optimisation.ExpressionsBasedModel;
+ import org.ojalgo.optimisation.Optimisation.Result;
+ 
++@Disabled("Requires network access")
+ public class OptimisationServiceTest {
+ 
+ private static final String PATH_ENVIRONMENT = 
"/optimisation/v01/environment";

Bug#1037434: xscreensaver: man page contains an incorrect file path to xscreensaver.service

[Robin Gustafsson]

Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: minor

Dear Maintainer,


The man page for xscreensaver(1) contains the following text:

LAUNCHING XSCREENSAVER FROM SYSTEMD
[...]
Copy the file /usr/share/xscreensaver/xscreensaver.service [...]

That file isn't installed by the package.

The referenced file seems to be installed as
/usr/lib/systemd/user/xscreensaver.service.


Regards,
Robin


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

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

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.65.2
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcrypt11:4.4.33-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libpam0g 1.5.2-6
ii  libsystemd0  252.6-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxt6   1:1.2.1-1.1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.06+dfsg1-3

Versions of packages xscreensaver recommends:
ii  fonts-urw-base35  20200910-7
ii  libjpeg-turbo-progs   1:2.1.5-2
ii  perl  5.36.0-7
ii  wamerican [wordlist]  2020.12.07-2
ii  xfonts-100dpi 1:1.0.5

Versions of packages xscreensaver suggests:
ii  firefox-esr [www-browser]   102.12.0esr-1~deb12u1
ii  fortune-mod [fortune]   1:1.99.1-7.3
pn  gdm3 | kdm-gdmcompat
ii  google-chrome-stable [www-browser]  114.0.5735.106-1
ii  lynx [www-browser]  2.9.0dev.12-1
pn  qcam | streamer 
pn  xdaliclock  
pn  xfishtank   
pn  xscreensaver-data-extra 
pn  xscreensaver-gl 
pn  xscreensaver-gl-extra   

-- no debconf information

Bug#1036601: xenstore-utils: broken symlink /usr/bin/xenstore-control

[Maximilian Engelhardt]

Control: retitle -1 xenstore-utils: broken symlink /usr/bin/xenstore-control

This is a bit more complicated:

Up to bullseye the binaries in the xenstore-utils package were independent of 
the running xen version (as the xenstore interface is more or less supposed to 
be stable).

Starting with bookworm the xenstore-control binary is now linked against 
unstable xen api libraries (libxenguest.so and libxenctrl.so) which are 
included in the libxenmisc4.17 package.
The upstream commit for this change is [1] and the documentation also says 
that the control command interface is not xen version independent.

Because of the additional shared library dependencies our shuffle-binaries 
script [3] kicks in and sets up the xen-utils-wrapper for xenstore-control.

The xen-utils-wrapper is only included in the xen-utils-common package. But 
adding that dependency would not be enough. It would make the /usr/bin/
xenstore-control symlink not broken, but the wrapper would not find the real 
binary, as it is included in the xen-utils-4.17 package at the /usr/lib/
xen-4.17/bin/xenstore-control path.

Installing only xenstore-utils and xen-utils-common in a dom-U gives the 
following output when executing xenstore-control:
$ xenstore-control 
ERROR:  Can't find version 4.17 of xen utils (maybe xen-utils-4.17 was already 
removed before rebooting out of Xen 4.17), bailing out!


Some options I see for fixing this:

[a] make xenstore-utils depend on xen-utils-V
[b] move the /usr/bin/xenstore-control symlink to xen-utils-V
[c] split the xenstore-utils package in a xen version independent and xen 
version dependent package.

Disadvantage from [a] is that xenstore-utils can also be used inside a dom-U 
and would pull lots of unused stuff. [c] seems to be a bit overkill for only 
one binary file, so I currently see [b] as the best option.

So does anybody have any opinion, ideas or something else to say about all 
this? Or any better ideas?


[1] 
https://salsa.debian.org/xen-team/debian-xen/-/commit/7f97193e6aa858df03be501440e0ade8cceb9ec5
[2] 
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/docs/misc/xenstore.txt#L378
[3] 
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/shuffle-binaries


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

Bug#1010369: Insights on redisearch versions and repos

[Hartmut Goebel]

Hi,

Since I'm about to build redisearch for Guix, I digged deeper into this 
rabbit hole. So here for the records (you, Chris, most probably already 
know this):


https://github.com/goodform/RediSearch is a fork based on the old open 
source license (AGPL).


Last common commit is 
 
which is 179 commits after v1.2.0. This very commit is the last one 
before change of the license in https://github.com/RediSearch/RediSearch.


In https://github.com/goodform/RediSearch there is a v1.2.2 dated 
2020-04-03. As of today, there is a single commit after that, also dated 
2020-04-03, which is a dummy merge.


The test-suite requires https://github.com/RedisLabs/rmtest. which is 
deprecated and unmaintained. PyPI has a 0.7.0, which is not tagged in 
the repo and which still requires Python-2.  Commit 
c0d79ec29461942c11eec86e953cc0a904046230 is what would be version 1.0.0 
if that would have been tagged and supports Python3. Since this commit 
only a few commits have been added.


For running the test-suite for rmtest, some adjustments need to be made, 
esp. one test does not fit the API at all.


Anyhow, running the test-suite for redisearch is not easily possible: 
The tests require a python module "reds._compat", which was removed in 
python-redis 4.0.


--

Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Bug#1037433: gnome-games-app: Needs to be ported to libsoup3

[Jeremy Bícha]

Source: gnome-games-app
Version: 40.0-4
Severity: serious
Tags: trixie sid

gnome-games-app needs to be ported from libsoup2.4 to libsoup3.

It is not possible for apps to simultaneously link against both
libsoup2.4 and libsoup3.

We need to switch grilo and its dependencies to libsoup3; this will
make it impossible to run gnome-games-app as a .deb in Debian Trixie.

Upstream changed their name to Highscore but never did publish a
release with the rename. The project looks unmaintained currently.

Alternatives
---
Unfortunately, it appears like the app is not currently published in
Flathub, nor has a Snap version been published yet.

https://discussion.fedoraproject.org/t/what-happened-to-gnome-games-in-flathub/82747

There are Debian packages of Lutris and Retroarch which are similar apps.

Thank you,
Jeremy Bícha

Bug#1028528: transition: libcotp

[Francisco Vilmar Cardoso Ruviaro]

Hello Sebastian,

On Fri, 20 Jan 2023 20:26:50 +0100 Sebastian Ramacher  
wrote:
> Control: tags -1 trixie
> 
> On 2023-01-19 15:38:06 +, Francisco Vilmar Cardoso Ruviaro wrote:
> > Hi Sebastian,
> > 
> > On 1/17/23 22:37, Sebastian Ramacher wrote:
> > > Control: tags -1 moreinfo
> > > 
> > > On 2023-01-12 11:45:45 +, Francisco Vilmar Cardoso Ruviaro wrote:
> > >> Package: release.debian.org
> > >> Severity: normal
> > >> User: release.debian@packages.debian.org
> > >> Usertags: transition
> > >> 
> > >> Dear Release Team,
> > >> 
> > >> I would like to update libcotp in unstable to the 2.0.0-1.
> > >> 
> > >> I would like to request a transition slot for libcotp, changing the
> > >> library name from libcotp12 to libcotp2. The version 2.0.0
> > > 
> > > Why is the SONAME going backwards?
> > > 
> > I believe this was an upstream decision, please check it out:
> > 
> > "the soversion is now set only from the $major version (e.g. 2),
> > and not from $major$minor (e.g. 12) like it used to be."
> > https://github.com/paolostivanin/libcotp/releases/tag/v2.0.0
> 
> Is upstream aware that the can never release with major versions 11 and
> 12 (at least)? Please clarify this with upstream.
> 
Yes, upstream is aware of this.


> In any case, let's postpone this transition to trixie.
> 
I just uploaded version 2.0.1-1~exp1 for experimental.
I await your authorization to proceed with the transition.


Thanks!
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037432: syncthing: CVE-2022-46165: XSS in Web GUI

[Salvatore Bonaccorso]

Source: syncthing
Version: 1.19.2~ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/syncthing/syncthing/pull/8923
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for syncthing.

CVE-2022-46165[0]:
| Syncthing is an open source, continuous file synchronization
| program. In versions prior to 1.23.5 a compromised instance with
| shared folders could sync malicious files which contain arbitrary
| HTML and JavaScript in the name. If the owner of another device
| looks over the shared folder settings and moves the mouse over the
| latest sync, a script could be executed to change settings for
| shared folders or add devices automatically. Additionally adding a
| new device with a malicious name could embed HTML or JavaScript
| inside parts of the page. As a result the webUI may be subject to a
| stored cross site scripting attack. This issue has been addressed in
| version 1.23.5. Users are advised to upgrade. Users unable to
| upgrade should avoid sharing folders with untrusted users.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-46165
https://www.cve.org/CVERecord?id=CVE-2022-46165
[1] https://github.com/syncthing/syncthing/pull/8923
[2] 
https://github.com/syncthing/syncthing/commit/73c52eafb6566435dffd979c3c49562b6d5a4238
 (v1.23.5) 
[3] 
https://github.com/syncthing/syncthing/security/advisories/GHSA-9rp6-23gf-4c3h

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1035341: libvdk2-dev: Please add a .pc file

[Nilesh Patra]

Hi,

If I see no reaction on this bug report for a week or so, I'll NMU the same.

Thanks
Nilesh

Bug#1031332: marked as done (transition: librnd)

[Paul Gevers]

control: reopen -1

Hi Bdale,

On 12-06-2023 03:33, Debian Bug Tracking System wrote:

>  librnd (4.0.1-2) unstable; urgency=medium
> .
>   * move new upstream version from experimental to unstable,
> closes: #1031332, $1031445, #1031459

Please never close transition bugs in uploads. Transition bugs get 
closed when the new soname binary migrates to testing.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Alexandru Mihail]

Hello again,

> I hope that the forests aren't burning, wherever you are.
> 
> Take care,

Oh damn, I really hope you and your family are going to be safe if you're 
facing wildfires near you..
Here in Eastern Europe it's not really that much of an issue, thankfully.

> remember the original NCSA httpd licence. P.S. It feels like
> archaeology to find missing documentation for something from the dawn of
> the Web! Also, it's a mystery to me what license the original httpd
> was.
It's pretty much a mistery to me too, seems like the original "License" if you 
could call it that is nothing more than:
"
Copyright (C) 2022 by Jef Poskanzer .
All rights reserved.

You may use this software however you like as long as you keep my name on 
it and don't sue me.
"
This is the current license (Author:So what does the legalese mean? This is a 
modified version of the BSD license). I'll try to dig a bit more about original 
source code license, if any other than the above was ever present :)
Yeah, archeology indeed, I've had the same issue,believe it or not, when 
porting a certain version of a vintage telnet library from the 80s on modern 
hardware. Fun times, indeed

Stay safe and good luck !
Alexandru


--- Original Message ---
On Monday, June 12th, 2023 at 9:01 PM, Nicholas D Steeves  
wrote:


> Hello Alexandru,
> 
> Alexandru Mihail alexandru_mih...@protonmail.ch writes:
> 
> > Hello Nicholas,
> > 
> > > Sorry, my mistake. I meant to write "debian/copyright". One or more
> > > entries in the copyright file conflicts with upstream evidence.
> > 
> > No problem, I think I found what you were referring to and corrected our 
> > copyright, upstream is right. I documented the changes in the changelog.
> 
> 
> Aha, yes, that's 1/2 of what I was referring to :) The other half are
> those copyright years that predate the 1999 claimed in our copyright
> file.
> 
> I also found what looks like a new issue: Those files that Rob McCool
> authored as part of NCSA httpd that are part of mini-httpd, what
> license are they? Attribution would be required if they were MIT/Expat,
> BSD, or similar. This issue might also affect apache2's copyright file,
> if anything remains of NCSA in Apache. Httpd predates the "NCSA"
> license, by the way. If you can't find anything about it, then consider
> contacting the debian-legal mailing list, because someone there might
> remember the original NCSA httpd licence. P.S. It feels like
> archaeology to find missing documentation for something from the dawn of
> the Web! Also, it's a mystery to me what license the original httpd
> was.
> 
> > > > > Would you please push your work to your personal Salsa namespace (fork
> > > > > relationship optional), and provide the link to the repo?
> > 
> > https://salsa.debian.org/alexandru_mihail/mini-httpd
> > Forked from master of:
> > https://salsa.debian.org/debian/mini-httpd
> 
> 
> Thanks.
> 
> > > speaking these patch fixups aren't release critical, and you can ignore
> > > them if you'd like.
> > > I will fix them, it's fine :)
> 
> 
> Thank you :)
> 
> > Also, I uploaded again to mentors last night.
> > Thanks and farewell,
> 
> 
> You're welcome. We're in the last round of review, by the way, and I
> think it will be ready to upload with the next update.
> 
> I hope that the forests aren't burning, wherever you are.
> 
> Take care,
> Nicholas

Bug#1037431: samtools: ftbfs and test failure against htslib 1.17

[Étienne Mollier]

Source: samtools
Version: 1.16.1-1
Severity: important
Tags: ftbfs

Hi,

When samtools is tested against htslib 1.17 now available in
experimental, I witness the following error, either from build
time checks or from autopkgtest:

The command failed [256]: 
/tmp/autopkgtest.PsRbbX/autopkgtest_tmp/samtools view -e 'pos<1000||pos>1200' 
-O cram,embed_ref=1 -T test/dat/mpileup.ref.fa -o 
/tmp/autopkgtest.PsRbbX/autopkgtest_tmp/test/reference/mpileup.1.tmp.cram 
test/dat/mpileup.1.sam
out:
err:[E::validate_md5] SQ header M5 tag discrepancy for reference '17'
[E::validate_md5] Please use the correct reference, or consider using 
embed_ref=2
samtools view: error closing 
"/tmp/autopkgtest.PsRbbX/autopkgtest_tmp/test/reference/mpileup.1.tmp.cram": -1

 at ./test/test.pl line 98.
main::error("The command failed [256]: 
/tmp/autopkgtest.PsRbbX/autopkgtest"..., "out:\x{a}", "err:[E::validate_md5] SQ 
header M5 tag discrepancy for refere"...) called at ./test/test.pl line 211
main::cmd("/tmp/autopkgtest.PsRbbX/autopkgtest_tmp/samtools 
view -e 'pos"...) called at ./test/test.pl line 3284
main::test_reference(HASH(0x55783ebcc4b8)) called at 
./test/test.pl line 37

The issue doesn't occur against htslib 1.16 in unstable.  The
good news is: this is the only issue I caught so far by bumping
the htslib version, so I'm pretty confident there were no major
breakages in the maneuver (think ABI, although the introduction
of versioned symbols upstream did involve a rather dense diff in
the symbols file).  The fix might be as easy as bumping samtools
to version 1.17 too.  Mostly documenting it via the bug tracker
since experimental pseudo-migrations are not back online yet.

Have a nice day,  :)
Étienne.


signature.asc
Description: PGP signature

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

[Nicholas D Steeves]

Hello Alexandru,

Alexandru Mihail  writes:

> Hello Nicholas,
>
>> Sorry, my mistake. I meant to write "debian/copyright". One or more
>> entries in the copyright file conflicts with upstream evidence. 
>
> No problem, I think I found what you were referring to and corrected our 
> copyright, upstream is right. I documented the changes in the changelog.

Aha, yes, that's 1/2 of what I was referring to :)  The other half are
those copyright years that predate the 1999 claimed in our copyright
file.

I also found what looks like a new issue: Those files that Rob McCool
authored as part of NCSA httpd that are part of mini-httpd, what
license are they?  Attribution would be required if they were MIT/Expat,
BSD, or similar.  This issue might also affect apache2's copyright file,
if anything remains of NCSA in Apache.  Httpd predates the "NCSA"
license, by the way.  If you can't find anything about it, then consider
contacting the debian-legal mailing list, because someone there might
remember the original NCSA httpd licence.  P.S. It feels like
archaeology to find missing documentation for something from the dawn of
the Web!  Also, it's a mystery to me what license the original httpd
was.

>> > > Would you please push your work to your personal Salsa namespace (fork
>> > > relationship optional), and provide the link to the repo?
>
> https://salsa.debian.org/alexandru_mihail/mini-httpd
> Forked from master of:
> https://salsa.debian.org/debian/mini-httpd

Thanks.

>> speaking these patch fixups aren't release critical, and you can ignore
>> them if you'd like.
> I will fix them, it's fine :)

Thank you :)

> Also, I uploaded again to mentors last night.
> Thanks and farewell,

You're welcome.  We're in the last round of review, by the way, and I
think it will be ready to upload with the next update.

I hope that the forests aren't burning, wherever you are.

Take care,
Nicholas


signature.asc
Description: PGP signature

Bug#1035820: 9base: leaves entries in /etc/shells after upgrade from bullseye

[Andreas Beckmann]

On 09/05/2023 16.55, Helmut Grohne wrote:

Control: forcemerge 1033167 -1
Control: affects 1033167 + 9base

Hi Andreas,

On Tue, May 09, 2023 at 04:39:21PM +0200, Andreas Beckmann wrote:

during a test with piuparts I noticed your package leaves modifications
in /etc/shells after upgrading from bullseye to bookworm and purging the
package.

9base/bullseye called add-shell/remove-shell in its postinst/postrm.
9base/bookworm no longer does that, but it also does not clean up the
leftover entries from bullseye in its postinst.


9base/bookworm no longer does, because it now uses dpkg-triggers to
perform the cleanup. It actually does clean up its entries.


>From the attached log (scroll to the bottom...):

0m45.2s ERROR: FAIL: After purging files have been modified:
   /etc/shells   not owned


You should look closer:

0m45.2s DEBUG: Modified(user, group, mode, size, target): /etc/shells 
expected(root, root, - 100644, 128, None) != found(root, root, - 100644, 140, 
None)

It's a 12 byte difference. That's not 9base's entries. What you see here
is "/usr/bin/sh\n". So this is a /usr-merge bug. We already know it.
Thus force-merging.


No, it's "/usr/bin/rc\n".

# cat /usr/share/debianutils/shells.d/plan9
/bin/rc
/usr/lib/plan9/bin/rc

If I install 9base in an unmerged-/usr sid chroot, I get

# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc

who is responsible for the duplicate entry?

If I install 9base in a merged-/usr sid chroot, I get

# /etc/shells: valid login shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
/usr/bin/sh
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc

same duplication ...

If I reconfigure usrmerge afterwards, I get

# /etc/shells: valid login shells
/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash
/usr/bin/sh
/bin/rc
/usr/lib/plan9/bin/rc
/usr/lib/plan9/bin/rc
/usr/bin/rc

Now we got the additional /usr/bin/rc entry



Andreas

Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)

[Nicholas D Steeves]

Antoine Beaupré  writes:

> On 2023-06-11 14:45:19, Nicholas D. Steeves wrote:
>>
>> Here is a way to work around this bug (whether in Emacs or in markdown-toc).
[snip]
>
> Oh wow, thanks!

You're welcome!

> That said it doesn't actually work! I have tried both the `--eval` and
> the `setq` and neither fix the crash.
>
> I'm not sure this is related to native compilation, is it really?

When I 'rm -rf ~/.emacs.d/eln-cache, and restart Emacs,
markdown-toc-generate-toc works correctly, but will eventually break
again once various things are compiled again (sooner than later on a
fast machine!).

I'm not sure why the deny list hack works with an empty eln-cache, but
not after a 'rm ~/.emacs.d/eln-cache/*/markdown-toc*'.

> I thought it was some imenu thing, maybe it doesn't get autoloaded properly?

Based on your hunch, I tested removing each rdep from the eln-cache, and
I found that the (wrong-type-argument consp nil) bug occurs in
markdown-mode-toc when markdown-mode is native compiled.

markdown-toc-generate-toc succeeds for me when

  ~/.emacs.d/eln-cache/*/markdown-mode-*.eln and
  ~/.emacs.d/eln-cache/*/markdown-toc-*.eln and
  ~/.emacs.d/eln-cache/*/imenu-*.eln

are removed, and emacs is started with this minimal workaround:

  emacs --eval="(setq native-comp-deferred-compilation-deny-list 
'(\"markdown-mode\"))"

Yes, markdown-mode, no "toc".  For this hack to work long-term for most
users, it seems like imenu would probably need to be added to that
list...but here's the strange thing: Logically,
markdown-toc-generate-toc uses imenu, so it seems like it should trigger
native-comp of imenu at L261.  Neither markdown-mode, nor
markdown-mode-toc explicitly (require 'imenu), so yes, I think you're
right that one or both of them is depending on autoloads.  Markdown-toc
ends up native-compiled using this method, markdown-mode and imenu
don't, and for reasons that aren't yet clear, this allows markdown-toc
to function correctly.

I also wonder if there may be a dash.el+native comp bug in play.

'hope this band-aid does the trick until the root of the problem can be
identified.

Nicholas


signature.asc
Description: PGP signature

Bug#1037430: Release notes don't mention removal of Exim option allow_insecure_tainted_data

[Tony Middleton]

Package: release-notes

It appears that Exim has removed the allow_insecure_tainted_data option 
from the bookworm version of Exim.  This caused my upgrade to fail at 
the apt full-upgrade stage.


Perhaps the release notes should refer to this.  The option was 
introduced for bullseye and was mentioned in those release notes.


Regards

Tony



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024616: libcrypt1: abuses Important and Protected fields

[Sven Joachim]

On 2022-11-22 17:05 +0100, Marco d'Itri wrote:

> On Nov 22, Helmut Grohne  wrote:
>
>> Shared libraries must not be marked Important: yes nor Protected: yes,
>> because that prevents them from being removed in a multiarch setup.
>> Please stop issuing these fields.
>>
>> I do see that they were added to ease the upgrade from buster to
>> bullseye. I think that the harm caused by the field now outweighs its
>> benefits.
> I suppose that I can remove them at this point, I will do it in the next
> upload.

Looks like you forgot to do so in the recent 1:4.4.35-1 upload.
Meanwhile, users are noticing that it is difficult to remove a foreign
architecture[1].

Thanks for maintaining libxcrypt! :-)

Cheers,
   Sven


1. https://lists.debian.org/debian-user/2023/06/msg00448.html

Bug#1037425: linux-kbuild-6.1: please add Breaks against obsolete *-dkms packages

[Bastian Blank]

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

On Mon, Jun 12, 2023 at 05:31:53PM +0200, Andreas Beckmann wrote:
> As a consequence, if cruft *-dkms packages are still installed, but fail
> to build the module for current kernels, this may result in upgrade
> failures. Therefore please add Breaks against cruft *-dkms packages that
> may be left over from previous releases to ensure they get removed.
> I chose linux-kbuild-6.1 for the addition of these Breaks since all
> linux-headers-* packages depend on that.

And why not at dkms?  And how does this help in the long term, as every
kernel release breaks modules?

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Bug#1037429: taoframework: should this package be removed?

[Simon McVittie]

Source: taoframework
Severity: important

While looking at libraries that depend on the SDL 1.2 framework
(superseded by SDL 2 in 2013), I noticed taoframework.

It seems to be a set of C#/.Net/CIL bindings for game- and 3D-related
functionality, which is not depended on by any package in Debian, is
based on a svn snapshot from 2009, and according to its Sourceforge
page, was superseded by https://github.com/opentk/opentk (src:opentk in
Debian) in 2012.

If its maintainers don't have a reason to keep this package around, can
we make the version released with bookworm its last version in Debian?
I'm happy to do the ftp.debian.org bug filing if that would be helpful.

Thanks,
smcv

Bug#1037428: RM: libsdl-console -- ROM; depends on obsolete SDL 1.2, no reverse dependencies, last upload in 2018

[Simon McVittie]

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

libsdl-console is an extension for the SDL 1.2 library, which was
superseded by SDL 2 slightly less than a decade ago. Nothing in Debian
depends on it, and it was most recently uploaded in 2018.

I think it's time to remove this. If a future maintainer wants to recover
it, they can easily fetch the version from Salsa or bookworm.

smcv

Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

[Kristoffer Brånemyr]

I guess it doesn't hurt to try to also check for SSE variants in the function 
trying to see if pclmul is supported.
But I think it's a bit suspicious that it only crashes sometimes.If there was 
some instruction which causes this, should it not happen everytime?
Could it be something else, like some unaligned address read/write that causes 
this?I guess ILL_ILLOPN might mean the argument to a instruction (i.e. possibly 
address?)

Can you reproduce the problem running cksum in gdb? Then you could disassemble 
the location it crashes in and possibly see a bit better what causes the issue. 
Also dump the values of the hardware registers. And variables if you can.


-- 
/Kristoffer Brånemyr 

Den måndag 12 juni 2023 kl. 15:03:11 CEST, Philip Rowlands 
 skrev:  
 
 On Sat, 10 Jun 2023, at 11:09, Pádraig Brady wrote:
> cksum since v9.0 checks at runtime whether pclmul is supported.
> It seems that check is not working appropriately on a Xen DomU.

Hypervisors routinely lie about CPUID feature flags, in order to maintain 
compatibility between a fleet of diverse servers. It's possible in this case 
that the system was misconfigured to present flags which the underlying CPU 
doesn't support.

> The routine in question is pclmul_supported() at:
> https://github.com/coreutils/coreutils/blob/b841f111/src/cksum.c#L160-L191
>
> That either suggests xen is incorrectly setting PCLMUL and AVX bits,
> or perhaps these two bits are not sufficient.
> Hmm I wonder do we also need to explicitly check for SSSE3 support?

Intel says to check for SSE and SSE2; quoting the manual
===
11.6.2 Checking for Intel® SSE and SSE2 Support
Before an application attempts to use Intel SSE and/or Intel SSE2, it should 
check that they are present on the
processor:
1. Check that the processor supports the CPUID instruction. Bit 21 of the 
EFLAGS register can be used to check
processor’s support the CPUID instruction.
2. Check that the processor supports Intel SSE and/or SSE2 (true if 
CPUID.01H:EDX.SSE[bit 25] = 1 and/or
CPUID.01H:EDX.SSE2[bit 26] = 1).

12.13.4 Checking for Intel® AES-NI Support
Before an application attempts to use AESNI instructions or PCLMULQDQ, the 
application should follow the steps
illustrated in Section 11.6.2, “Checking for Intel® SSE and SSE2 Support.” 
Next, use the additional step provided
below:
Check that the processor supports Intel AES-NI (if CPUID.01H:ECX.AESNI[bit 25] 
= 1); check that the processor
supports PCLMULQDQ (if CPUID.01H:ECX.PCLMULQDQ[bit 1] = 1).
===

Wikipedia mentions an AVX-512 version (VPCLMULQDQ) but I don't think we're 
using that.

I can't find the equivalent AMD docs. Is there a library / macro check for 
this, to avoid the low-level bit inspection?

It would be useful to see the output of "cpuid -1" which does a verbose decode 
of all CPUID flags, on the system which sees the SIGILL. (How can it be 
intermittent??)

Interesting that the strace output finishes with:

read(0, "", 61440)                      = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x55bec9cc6cf5} ---
+++ killed by SIGILL +++

i.e. ILL_ILLOPN (operand) rather than ILL_ILLOPC (opcode). What could cause 
this?


Cheers,
Phil
  

Bug#1037427: newlib: reproducible builds: tarball embeds various metadata from build machine

[Vagrant Cascadian]

Source: newlib
Version: 3.3.0-1.3
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The source tarball /usr/src/newlib/newlib-3.3.0.tar.xz embeds
timestamps, file mode, username, userid, groupname and groupid of the
build user:

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

The attached patch fixes this by passing arguments to tar in
debian/rules to ensure consistent sort order, timestamps, user, group,
uid and gid and file mode in the generated tarball.


According to my local tests, with this patch applied newlib should
become reproducible on tests.reproducible-builds.org once it migrates to
trixie/testing! Unfortunately, other issues (build paths) tested on
unstable and experimental are still unresolved.


Thanks for maintaining newlib!

live well,
  vagrant
From 9bd70cde30f64de8f34902e73768b6224b7526ed Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jun 2023 20:12:09 -0700
Subject: debian/rules: Pass arguments to tar for consistent sort
 order, timestamps, user, group and mode.

https://reproducible-builds.org/docs/archives/
---
 debian/rules | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index c7e4891..c4895fb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -67,7 +67,12 @@ CONFIGURE_FLAGS_NANO = \
 	dh $@ -B$(BUILD_DIR) --with autotools-dev --parallel
 
 debian/newlib-$(DEB_VERSION_UPSTREAM).tar.xz:
-	tar -acf $@ --exclude=debian --exclude-vcs --exclude='*.dh-orig' `pwd`/../`basename $(TOP_DIR)`
+	tar -acf $@ --exclude=debian --exclude-vcs --exclude='*.dh-orig' \
+		--sort=name \
+		--mtime="@$(SOURCE_DATE_EPOCH)" \
+		--owner=0 --group=0 --numeric-owner \
+		--mode=go=rX,u+rw,a-s \
+		`pwd`/../`basename $(TOP_DIR)`
 
 override_dh_clean:
 	dh_clean
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1037426: RFS: blag-fortune/1.9.0-1 -- anarchist quotes for fortune

[tous]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "blag-fortune":

 * Package name : blag-fortune
   Version  : 1.9.0-1
   Upstream contact : [fill in name and email of upstream]
 * URL  : https://notabug.org/PangolinTurtle/BLAG-fortune
 * License  : public-domain
 * Vcs  : https://salsa.debian.org/debian/blag-fortune
   Section  : games

The source builds the following binary packages:

  fortune-anarchism - anarchist quotes for fortune

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


  https://mentors.debian.net/package/blag-fortune/

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


  dget -x 
https://mentors.debian.net/debian/pool/main/b/blag-fortune/blag-fortune_1.9.0-1.dsc


Changes since the last upload:

 blag-fortune (1.9.0-1) unstable; urgency=medium
 .
   * Declare compliance with Debian Policy 4.6.2
   * New upstream version 1.9.0

Regards,
--
  tous

Bug#1037425: linux-kbuild-6.1: please add Breaks against obsolete *-dkms packages

[Andreas Beckmann]

Package: linux-kbuild-6.1
Version: 6.1.27-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

one change in dkms in bookworm is that it actually returns an error when
failing to build a module, as a result
/etc/kernel/header_postinst.d/dkms may fail and cause
linux-headers---.postinst to fail.
(Up to bullseye, dkms returned 0 on failure and the failure was only
noticable when someone studied the install/upgrade log.)

As a consequence, if cruft *-dkms packages are still installed, but fail
to build the module for current kernels, this may result in upgrade
failures. Therefore please add Breaks against cruft *-dkms packages that
may be left over from previous releases to ensure they get removed.
I chose linux-kbuild-6.1 for the addition of these Breaks since all
linux-headers-* packages depend on that.

I'm trying to build a list:

Breaks:
# in bullseye, not in bookworm:
nvidia-tesla-418-kernel-dkms (<< 418.226.00-9~),
nvidia-tesla-460-kernel-dkms (<< 460.106.00-9~),
# in buster, not in bullseye
sl-modem-dkms (<< 2.9.11~20110321-16.0),
# in stretch, not in buster
blktap-dkms (<< 2.0.93-0.10.0),
# in jessie, not in stretch
oss4-dkms (<< 4.2-build2020-1~),
# in wheezy, not in jessie
blcr-dkms (<< 0.8.6~b3-1.0),

Maybe there are more, but I haven't seen them, yet.

In case this was fixed in sid (but not in bookworm), I've used that
version suffixed with '~', otherwise (i.e. not fixed in sid) I've
invented a version based on the last version in sid with NMU suffix .0


The typical upgrade failure if one of these obsolete packages is still
installed looks like this:

...
  Setting up linux-headers-6.1.0-9-amd64 (6.1.27-1) ...
  /etc/kernel/header_postinst.d/dkms:
  dkms: running auto installation service for kernel 6.1.0-9-amd64.
  Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
  Signing key: /var/lib/dkms/mok.key
  Public certificate (MOK): /var/lib/dkms/mok.pub
  Certificate or key are missing, generating self signed certificate for MOK...
  openssl not found, can't generate key and certificate.

  Building module:
  Cleaning build area...
  make -j84 KERNELRELEASE=6.1.0-9-amd64 -C /lib/modules/6.1.0-9-amd64/build 
M=/var/lib/dkms/blcr/0.8.5/build...(bad exit status: 2)
  Error! Bad return status for module build on kernel: 6.1.0-9-amd64 (x86_64)
  Consult /var/lib/dkms/blcr/0.8.5/build/make.log for more information.
  dkms autoinstall on 6.1.0-9-amd64/x86_64 failed for blcr(10)
  Error! One or more modules failed to install during autoinstall.
  Refer to previous errors for more information.
  dkms: autoinstall for kernel: 6.1.0-9-amd64 failed!
  run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
  Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.1.0-9-amd64.postinst line 11.
  dpkg: error processing package linux-headers-6.1.0-9-amd64 (--configure):
   installed linux-headers-6.1.0-9-amd64 package post-installation script 
subprocess returned error exit status 1
  Setting up gnupg (2.2.40-1.1) ...
  dpkg: dependency problems prevent configuration of linux-headers-amd64:
   linux-headers-amd64 depends on linux-headers-6.1.0-9-amd64 (= 6.1.27-1); 
however:
Package linux-headers-6.1.0-9-amd64 is not configured yet.

  dpkg: error processing package linux-headers-amd64 (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for systemd (252.6-1.1~deb12anbe1) ...
  Processing triggers for debianutils (5.7-0.4) ...
  Processing triggers for libc-bin (2.36-9) ...
  Errors were encountered while processing:
   linux-headers-6.1.0-9-amd64
   linux-headers-amd64

while on bullseye the ignored failure looked like this:

...
  Setting up linux-headers-5.10.0-22-amd64 (5.10.178-3) ...
  /etc/kernel/header_postinst.d/dkms:
  Error! Bad return status for module build on kernel: 5.10.0-22-amd64 (x86_64)
  Consult /var/lib/dkms/blcr/0.8.5/build/make.log for more information.


Andreas

Bug#1037107: Acknowledgement (pre-unblock: bookworm-pu: mariadb/1:10.11.3-2/+deb12u1)

[Michael Prokop]

* Otto Kekäläinen [Wed Jun 07, 2023 at 07:07:50PM -0700]:

> Note that upstream released 10.11.4 today. Import preparation in
> progress at 
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/50.
> I plan to upload this to experimental tomorrow and eventually into
> bookworm-pu if the release team approves.

I want to add my +1 as a user of mariadb, the current mariadb
version in bookworm has a serios regression which turned out to be
https://jira.mariadb.org/browse/MDEV-31403 and is fixed by
1:10.11.4-1 (as present in current Debian/unstable), so a fixed
package of mariadb would be highly appreciated.

Thanks, Otto and release team :)

regards
-mika-


signature.asc
Description: PGP signature

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[Sune Stolborg Vuorela]

On Sunday, April 30, 2023 1:27:14 PM CEST Andreas Metzler wrote:
> I do not indend to hijack/adopt gnupg2, so I am very reluctant to upload
> without some kind of go from Daniel or Eric. (Even to experimental.)

Hi Daniel

Any chance you can give Andreas a go ahead to push a newer Gnupg2 to at least 
experimental, or preferably unstable ?

Kind regards,
/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1037174: RFS: damo/1.8.4-1 [ITP] -- Data Access Monitoring Operator

[Adam Borowski]

On Tue, Jun 06, 2023 at 09:45:25PM -0500, Michel Alexandre Salim wrote:
>  * Package name : damo
>Version  : 1.8.4-1
>Upstream contact : SeongJae Park 
>  * URL  : https://damonitor.github.io/
>  * Vcs  : https://salsa.debian.org/python-team/packages/damo

>  damo (1.8.4-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #1037157)

Hi!
The commands you run for % targets will fail badly if ran in parallel, and
that's the default these days.  Please run that only once, eg from
override_dh_auto_configure (as that's a target that's run early).

Other nice to have bits:
 * the description doesn't say what DAMON is, even "Data Access Monitoring
   Operator" doesn't shed much light
 * a command-line tool really should have a man page

(but only the first part is a blocker)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

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

[Alexandru Mihail]

Hello Nicholas,

> Sorry, my mistake. I meant to write "debian/copyright". One or more
> entries in the copyright file conflicts with upstream evidence. 

No problem, I think I found what you were referring to and corrected our 
copyright, upstream is right. I documented the changes in the changelog.

> > > Would you please push your work to your personal Salsa namespace (fork
> > > relationship optional), and provide the link to the repo?

https://salsa.debian.org/alexandru_mihail/mini-httpd
Forked from master of:
https://salsa.debian.org/debian/mini-httpd

> speaking these patch fixups aren't release critical, and you can ignore
> them if you'd like.
I will fix them, it's fine :)

Also, I uploaded again to mentors last night.
Thanks and farewell,
Alexandru




--- Original Message ---
On Saturday, June 10th, 2023 at 6:52 PM, Nicholas D Steeves 
 wrote:


> Hi Alexandru,
> 
> Alexandru Mihail alexandru_mih...@protonmail.ch writes:
> 
> > > 2. I found an inaccuracy in the upstream sections of debian/changelog;
> > > please fix it. Plain old grep or manual header check should be enough
> > > to spot this.
> > 
> > Can you please elaborate a bit ? Are you referring to my changelog entry or 
> > any mistakes in upstream.changelog or older debian/changelog entries ?
> 
> 
> Sorry, my mistake. I meant to write "debian/copyright". One or more
> entries in the copyright file conflicts with upstream evidence. Our
> obligation is to accurately represent upstream's claims; however, if you
> think the existing state better represents reality, and that upstream's
> copy is inaccurate, then please do something like 1. Correct our copy of
> upstream's claims. 2. Make a note about how the file previously
> contained a different claim, which you think is correct, and write why.
> The field that is used for this can be (quickly) found in this
> documentation:
> 
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> > > 3. Do the patches have accurate filenames, subjects, and synopses?
> > > Adopting a package is the perfect time to fix anything misleading.
> > 
> > Most of them are fine, I'd change the filename of "0006-fix-makefile", a 
> > bit too generic, it changes some install dirs and adds -lssl to a compile 
> > target, not exactly something obvious when you read "fix-makefile". I'll 
> > come up with a better name.
> 
> 
> I agree most are fine, and yes the one you've pointed out could be
> nicer. The one I'm concerned about has a subject that doesn't appear to
> describe what the patch actually does, which is misleading. Strictly
> speaking these patch fixups aren't release critical, and you can ignore
> them if you'd like.
> 
> > > Would you please push your work to your personal Salsa namespace (fork
> > > relationship optional), and provide the link to the repo? This way I
> > > Will do, it was a very busy week :)
> 
> 
> No worries :)
> 
> > > P.S. It seems like Debian's copy might be the defacto upstream, as of
> > > eight years ago, when someone wrote we were "doing a good job"
> > > maintaining mini_httpd.
> > > Hah, I've heard the same thing from an OpenWRT maintainer a few years 
> > > ago. We're their defacto upstream as well (and any OpenWRT based router 
> > > firmwares such as Tomato, etc etc). Long live the red spiral, I guess :)
> 
> 
> Wow, I guess it's true then, and that your work will benefit more people
> than anticipated! This makes me think of the Civil Infrastructure
> Platform
> (https://wiki.linuxfoundation.org/_media/civilinfrastructureplatform/2017-08-cip-debconf-r5.pdf)
> 
> > Have a great day,
> 
> 
> Likewise, you too!
> Nicholas

Bug#1037424: ITP: hatch-nodejs-version -- hatch plugin for versioning from a package.json file

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
Severity: wishlist
Owner: Ying-Chun Liu (PaulLiu) 

* Package name: hatch-nodejs-version
  Version : 0.3.1
  Upstream Author : Angus Hollands 
* URL : https://github.com/agoose77/hatch-nodejs-version
* License : MIT
  Programming Lang: Python
  Description : hatch plugin for versioning from a package.json file
 This package provides two Hatch plugins:
 - version source plugin: reads/writes the package version from the
   `version` field of the Node.js `package.json` file.
 - metadata hook plugin: reads PEP 621 metadata from the Node.js
   `package.json` file.


Binary package names: python3-hatch-nodejs-version


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037423: zchunk: Please update to latest upstream version

[Bastian Germann]

Source: zchunk
Version: 1.2.3+ds1-2
Severity: wishlist

Please update to the latest upstream version, which is 1.3.1 currently.
I need 1.3.x in unstable for updating the swupdate package.

Bug#1037422: spamprobe crashing with signal 11 for some emails

[Florent CUETO]

Package: spamprobe
Version: 1.4d-16
Severity: important
X-Debbugs-Cc: fcu...@wanadoo.fr

Dear Maintainer,

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

when using spamprobe to score or learn from an email, sometimes it crashes with 
signal 11.
eg. executing "spamprob score mail.txt"
leads to :
caught signal 11: quitting
Aborted

I provide a sample email.

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

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

Versions of packages spamprobe depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9
ii  libdb5.3   5.3.28+dfsg2-1
ii  libgcc-s1  12.2.0-14
ii  libgif75.2.1-2.5
ii  libjpeg62-turbo1:2.1.5-2
ii  libpng16-161.6.39-2
ii  libstdc++6 12.2.0-14

Versions of packages spamprobe recommends:
ii  procmail  3.22-27

spamprobe suggests no packages.

-- debconf information:
* spamprobe/db51_upgrade:
  spamprobe/db48_upgrade:
* spamprobe/db53_upgrade:
--- Begin Message ---







  
  

  


  

  
  

  


  

  
  

  


  

  
  

  


  

  
Gift 
cards are back.

  
Great 
news,gift cards are now available to trade in 
your country.

Check 
out the full list here.

See 
you on the 
  marketplace!

  

  
  

  


  Start 
  

  
  

  


  

  
  

  


  
Follow 
us for more financial peace of mind

  

  
  








  

  
  

  

  
  

  


  

  
  



  


  

  
  


  

  
  

  


  
Available 
in the App Store and Google Play

  

  
  


  

  
You 
received this email because you have registered an 
account on Paxful.com website.Paxful, Inc., 3422 Old Capitol Trail 
PMB# 989 Wilmington DE 19808, USAUnsubscribe | Paxful.com

--- End Message ---

Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-06-11 14:45:19, Nicholas D. Steeves wrote:
> Hi,
>
> Here is a way to work around this bug (whether in Emacs or in markdown-toc).
>
> To test:
> emacs --eval="(setq native-comp-deferred-compilation-deny-list 
> '(\"markdown-toc\"))"
>
> To make permanent:
> (setq native-comp-deferred-compilation-deny-list '("markdown-toc"))
>
> That said, I'm not convinced that a workaround like this should be
> inserted into Debian's markdown-toc (or any package)...

Oh wow, thanks!

That said it doesn't actually work! I have tried both the `--eval` and
the `setq` and neither fix the crash.

Debugger entered--Lisp error: (wrong-type-argument consp nil)
  markdown-imenu-create-nested-index()
  markdown-toc-generate-toc(nil)
  funcall-interactively(markdown-toc-generate-toc nil)
  command-execute(markdown-toc-generate-toc record)
  execute-extended-command(nil "markdown-toc-generate-toc" nil)
  funcall-interactively(execute-extended-command nil 
"markdown-toc-generate-toc" nil)
  command-execute(execute-extended-command)

I'm not sure this is related to native compilation, is it really?

I thought it was some imenu thing, maybe it doesn't get autoloaded properly?

a.

-- 
Si Dieu existe, j'espère qu'Il a une excuse valable
- Daniel Pennac

Bug#1037421: RM: freebirth -- RoQA; RC-buggy; depends on gtk2; unmaintained

[Bastian Germann]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal

Please remove freebirth. It is RC-buggy for a long time. It depends on gtk2.
It does not seem to be maintained in Debian and is dead upstream.

Bug#1037419: mirror submission for mirrors.hostiserver.com

[Norby]

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

Submission-Type: new
Site: mirrors.hostiserver.com
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Norby 
Country: NL Netherlands
Sponsor: IT Services company s.r.o. https://www.hostiserver.com




Trace Url: http://mirrors.hostiserver.com/debian/project/trace/
Trace Url: 
http://mirrors.hostiserver.com/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirrors.hostiserver.com/debian/project/trace/mirrors.hostiserver.com

Bug#1037418: librust-reqwest-dev: impossible to install: depends on gone librust-base64-0.13+default-dev

[Jonas Smedegaard]

Package: librust-reqwest-dev
Version: 0.11.13-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-reqwest-dev depends on librust-base64-0.13+default-dev which is gone.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmSHKgEACgkQLHwxRsGg
ASFYyg//Z9gBlR3ngOTREoyMaqRer/g4m4T0cZEHOPdGMsbXsvr73mv4nizoSUuE
rF90m3nIitVOLCsueft8WkpUiyWmDSFStkfBmFEHbUO5ft26g4DsVN40YwxOcnf3
n+s7TMpccMTfJTF/X7xqvaMC8dj7UEQSAVNXUK3RAibTs1J2hZEGOrPkbsiVZLrJ
4EL0uxelvqhQZzzB5mRnp97OnqN0CipOsBJBFolVVMP9Be4gWrbD2ey8imG9DHHE
Hsw6/boPNYY9p+6ibNcvTo+HGA3W3wMIL/F6oLfiFJ3Zeg8zZWQzVNjbjjSRJ1/e
5G6CTjT/Xtw1034x9QHIK2cISSZsU3lzvD5zxKAtqCJtQwsc9XYjawUAM2wu4S6F
zGL3kYk5YVQJacC1uaBQ0Z8bFWZ5Hn7nu5G2b7guTCJXjI20aGbN1PksD+3/pIp9
DaMZgJ0wU/nGwCU7X02bG1NprvpnDr+2j78yJgys1iJL+eOO0ZAukSO+Jh2aDbkh
O2xBpv6FncPJ/r8sRTIxhEBp3xUJSnaC6vNXcIuyfmVQE500NPlFyMbuyvvxg5gV
vdfAhhIzOTox/7Iu9zNWwd+QWXcNctNCA9HHT4h73VQ2qh8ooeXxXtTYVN5ytI6B
JYJVQlfUi4wniC1IMmKcTO9FJKd4+SO6sG8Dg2uldOBRgsCA6Ws=
=q+c/
-END PGP SIGNATURE-

Bug#1037417: mirrors: 'stable' repo link points to '12(bookworm)' even on '11(bullseye)' installs

[Aral Kaymaz]

Package: mirrors
Severity: important
X-Debbugs-Cc: ackaymaz+deb...@gmail.com

Currently, 'stable' repos point to '12(bookworm)' repos.

This creates an issue with debian:stable as the downloaded image is
'11(bullseye)'

Steps to reproduce:
- Pull debian:stable image from docker hub (success)
- Run 'apt update' (success)
- Run 'apt upgrade' - shows >80 packages to install
- Run 'apt install python3.9' - FAILS due to python3.9 not being in repo

For comparison
- Pull debian:11 image from docker hub (success)
- Run 'apt update' (success)
- Run 'apt upgrade' - shows 1 package to install (success)
- Run 'apt install python3.9' (success)

So this means that 'debian:stable' is NOT stable. That's a big bummer

Bug#1037416: librust-rustls-pemfile-dev: impossible to install: depends on gone librust-base64-0.13+default-dev

[Jonas Smedegaard]

Package: librust-rustls-pemfile-dev
Version: 1.0.0-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-rustls-pemfile-dev depends on librust-base64-0.13+default-dev which is 
gone.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmSHKWcACgkQLHwxRsGg
ASEqpg//Qi2j1f+ABcptATEej4/bXQ0fPcs/5SNb9Zop0qZdEX6U7bH9HC8T0OgL
slZmmJDB86b/R1y2QyeuQm1JjcCX4iXaNckiOVnKtjSMd5UAFl1acaTspCnkHLhq
CkYzXjNVmCyWsinXHEGaoNuzAi6RDRUNAz9p3AFgxT0zj+3x2uvIlOmo4IBOWu9W
8oDAsFHIYeAIGaWkmn5M01gXoY+jUes7FbNI5UBP/DiIToDoYNja6c1cxLC22wGr
kwPNRJpE7+8uNAUhJht0CHLjiyzje/rZdI9bhgNxFhIl8RbSwk7rMxiGo+8Xk9Uk
UAxOIYP9L6PkLzC5e++XMwS8SHv2WsDM/zML6Og8NX5pkeJ1UEMpGu6q+tr3yEne
9Cnjqc2MKJPYrd0xvVLHAb7kylvh14zd3BhirnVdUH/JD9v6AwfvgVjgpgQqYlM7
bqL77GpIioJM+7kIvpzO7ric4GrW/0TB6cLem9BNQ9JMtGnQCVgfKUwQOmDFwvgC
vpAplGMFL0ojGq5cGW1wVvJSUSLKa5b60jOgZ1lftz7w0F0fKUPrpOQvzIobpQdR
1L2muxxFsV57Y/oV6ZQaXWFMkKupueZTGRNwcgcovNNi+mATb8h5MIZUBqXtRA4w
UYz38LyVv5jUsoGTj0gxAFi+09s3f9QbgsqWXx5AbNsTetJPxiQ=
=QZ7X
-END PGP SIGNATURE-

Bug#1037415: librust-grep-printer-dev: impossible to install: depends on gone package librust-base64-0.13+default-dev

[Jonas Smedegaard]

Package: librust-grep-printer-dev
Version: 0.1.6-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

librust-grep-printer-dev depends on librust-base64-0.13+default-dev which is 
gone.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmSHKHAACgkQLHwxRsGg
ASGMJRAArH4HaVhzJXG99ayt8E9iZ6NSdECmqVndJSfUFNgrjXpy7cImi394cK94
0aA3yq8MdcMYh23gJEcW975YU7cjKT8WFHKsGvkYUZ51RDbEKAJly6tGp+mMHKA6
k2MGNJNejJlyNEL7Zd62Mq3wNUD//mz4aYn75MPkF3ucgSkw3l7/rh+jHbrLwiUu
mXFRt0ZJkTR93UmpNcZDYmfjmaZ6/IFQ1sOwaCjZkP4NtPBtc4W97bdBNtcypNMr
WiuPtTpUDArauX/MGu4v4KiY+EZa7AYdfdzqRHXkolH3nHOrjOL8QDwWdXXjBQ2V
iuoaFIrQPUHNx1l93rotFUQYCuIabszdTutIuZgRTOxCgnsmqg88JqIifqFK8RHj
zf7/LdahBDP8G0VV72LgB+VrLIT4nJNZNYciATKMnMn5zh9ref1FIOlfEio0KVgJ
9NrrwD9PPujEVVTe55b0lIKd24O57qs4SF5o51skLEshAqDS7ymCL95zWv/mPC76
yOgZhdW6ttfWgmrmLLqNiCgPJ9l6ydLzprU+dHyBx1hqo3iFVsvsAoLzseZdVWAM
nO7Tfo1x4cuVTb62AC0hFja05/b4HkuP6+bwVX6AHllvlKu7Uo601HUtHbFzhVmT
4htlWV+7Wp8qeE95IWZkYxWJXyXSe2xXLG8QRb1wOJGqCZL/JtE=
=3JpT
-END PGP SIGNATURE-

Bug#989632: dash: remove unnecessary diversion of /bin/sh

[Luca Boccassi]

On Wed, 9 Jun 2021 08:02:15 +0200 Helmut Grohne 
wrote:
> Package: dash
> Version: 0.5.11+git20210120+802ebd4-1
> Tags: patch

Hi Andrej,

Now that bookworm is out, could we get the version in experimental
moved to unstable please? Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#1037414: gcc-13 ftbfs on mipsel

[Matthias Klose]

Package: src:gcc-13
Version: 13.1.0-5
Severity: serious
Tags: sid trixie
X-Debbugs-CC: debian-m...@lists.debian.org

gcc-13 ftbfs on mipsel:

[...]
Bootstrap comparison failure!
gcc/rust/rust-macro-builtins.o differs
gcc/rust/rust-session-manager.o differs
gcc/rust/rust-cfg-parser.o differs
gcc/rust/rust-lex.o differs
make[4]: *** [Makefile:30369: compare] Error 1
make[4]: Leaving directory '/<>/build'
make[3]: *** [Makefile:30349: stage3-bubble] Error 2
make[3]: Leaving directory '/<>/build'
make[2]: *** [Makefile:30412: bootstrap] Error 2


I'll ignore these for now, but please address this upstream.

Bug#1037413: cloud-init places IPv6 routes under IPv4 interface definition

[Michael Firth]

Package: cloud.debian.org
Version: debian-11-generic-amd64-20230124-1270.qcow2

In the cloud-init “network-config” file (using “Networking Config Version 2”) 
when using static network addressing, it is possible to define static routes 
under an interface.

These routes can be either IPv4 or IPv6 routes. These are then placed into 
/etc/network/interfaces.d/50-cloud-init by the cloud unit scripts.

The same script correctly creates two stanzas in the file for an interface that 
has both an IPv4 and an IPv6 address, as “iface  inet static” and “iface 
 inet6 static”.

The script also correctly changes the syntax of the “route” command to add “-A 
inet6” for IPv6 routes.

However, the script places all static routes under the “iface  inet static” 
stanza. This means that the IPv6 routes don’t (usually) work, as the system 
(usually) attempts to configure them before the IPv6 address has been 
configured on the interface.

If I manually cut and paste the routes to the “iface  inet6 static” stanza 
and restart the interface then the routes come up correctly.

I know that the networking for cloud-init will change in Debian 12 away from 
using ifupdown, but it would still be useful to have this fixed for Debian 11, 
as some people will still be running with that for a year or more.

If fixing this isn’t going to happen, could you let me know which script file 
is creating the 50-cloud-init file from the network-config file, so I can have 
a look into creating a local fix.

Thanks

Michael

Bug#1037412: man ansible-lint documents non-existent option --module-path

[Helmut Grohne]

Package: ansible-lint
Version: 6.13.1-1
File: /usr/share/man/man1/ansible-lint.1.gz

man ansible-lint explains how to use -M or --module-path. Trying to pass
either only results in failures. I suggest updating either the
documentation or the implementation to restore consistency.

Helmut

Bug#1037411: nautilus-owncloud: menu doesn't appear due to nautilus API changes

[Micha Moskovic]

Package: nautilus-owncloud
Version: 2.11.0.8354+dfsg-1
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: micha...@gmail.com

Dear Maintainer,

The version of nautilus shipped in bookworm has a different API from
what is expected by the shell extension in the nautilus-owncloud
package. The sync status icons are correctly displayed, but the owncloud
menu doesn't appear, making this package essentially unusable.

When starting nautilus, the following error is displayed:

TypeError: MenuExtension_ownCloud.get_file_items() missing 1 required 
positional argument: 'files'

The bug has been fixed in https://github.com/owncloud/client/pull/10075
and would need to be backported to the stable package version. It looks
like some work was done in
https://salsa.debian.org/owncloud-team/owncloud-client/-/merge_requests/2
but never completed.

Best regards,
Micha

-- 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/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nautilus-owncloud depends on:
ii  nautilus  43.2-1
ii  owncloud-client   2.11.0.8354+dfsg-1+b1
ii  owncloud-client-data  2.11.0.8354+dfsg-1
ii  python3   3.11.2-1+b1
ii  python3-nautilus  4.0-1+b1

nautilus-owncloud recommends no packages.

Versions of packages nautilus-owncloud suggests:
pn  nautilus-script-manager  

-- no debconf information

Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

[Philip Rowlands]

On Sat, 10 Jun 2023, at 11:09, Pádraig Brady wrote:
> cksum since v9.0 checks at runtime whether pclmul is supported.
> It seems that check is not working appropriately on a Xen DomU.

Hypervisors routinely lie about CPUID feature flags, in order to maintain 
compatibility between a fleet of diverse servers. It's possible in this case 
that the system was misconfigured to present flags which the underlying CPU 
doesn't support.

> The routine in question is pclmul_supported() at:
> https://github.com/coreutils/coreutils/blob/b841f111/src/cksum.c#L160-L191
>
> That either suggests xen is incorrectly setting PCLMUL and AVX bits,
> or perhaps these two bits are not sufficient.
> Hmm I wonder do we also need to explicitly check for SSSE3 support?

Intel says to check for SSE and SSE2; quoting the manual
===
11.6.2 Checking for Intel® SSE and SSE2 Support
Before an application attempts to use Intel SSE and/or Intel SSE2, it should 
check that they are present on the
processor:
1. Check that the processor supports the CPUID instruction. Bit 21 of the 
EFLAGS register can be used to check
processor’s support the CPUID instruction.
2. Check that the processor supports Intel SSE and/or SSE2 (true if 
CPUID.01H:EDX.SSE[bit 25] = 1 and/or
CPUID.01H:EDX.SSE2[bit 26] = 1).

12.13.4 Checking for Intel® AES-NI Support
Before an application attempts to use AESNI instructions or PCLMULQDQ, the 
application should follow the steps
illustrated in Section 11.6.2, “Checking for Intel® SSE and SSE2 Support.” 
Next, use the additional step provided
below:
Check that the processor supports Intel AES-NI (if CPUID.01H:ECX.AESNI[bit 25] 
= 1); check that the processor
supports PCLMULQDQ (if CPUID.01H:ECX.PCLMULQDQ[bit 1] = 1).
===

Wikipedia mentions an AVX-512 version (VPCLMULQDQ) but I don't think we're 
using that.

I can't find the equivalent AMD docs. Is there a library / macro check for 
this, to avoid the low-level bit inspection?

It would be useful to see the output of "cpuid -1" which does a verbose decode 
of all CPUID flags, on the system which sees the SIGILL. (How can it be 
intermittent??)

Interesting that the strace output finishes with:

read(0, "", 61440)  = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x55bec9cc6cf5} ---
+++ killed by SIGILL +++

i.e. ILL_ILLOPN (operand) rather than ILL_ILLOPC (opcode). What could cause 
this?


Cheers,
Phil

Bug#1037410: libfuse3: always warns "Ignoring invalid max threads value 4294967295 > max (100000)." by default

[наб]

Package: libfuse3
Version: 3.14.0-4
Severity: normal

Dear Maintainer,

Since bookworm,
  $ /usr/sbin/febug /run/user/1000/febug/
  Ignoring invalid max threads value 4294967295 > max (10).
  ...
and according to fuse_cmdline_help():
   "-o max_idle_threadsthe maximum number of idle worker 
threads\n"
   "   allowed (default: -1)\n"
fuse_main_real():
if (opts.singlethread)
res = fuse_loop(fuse);
else {
loop_config = fuse_loop_cfg_create();
if (loop_config == NULL) {
res = 7;
goto out3;
}

fuse_loop_cfg_set_clone_fd(loop_config, opts.clone_fd);

fuse_loop_cfg_set_idle_threads(loop_config, 
opts.max_idle_threads);
fuse_loop_cfg_set_max_threads(loop_config, opts.max_threads);
res = fuse_loop_mt(fuse, loop_config);
}
(and I can confirm it goes away with -s or -omax_idle_threads=10).

fuse_loop_cfg_set_idle_threads():
void fuse_loop_cfg_set_idle_threads(struct fuse_loop_config *config,
unsigned int value)
{
if (value > FUSE_LOOP_MT_MAX_THREADS) {
fuse_log(FUSE_LOG_ERR,
 "Ignoring invalid max threads value "
 "%u > max (%u).\n", value, FUSE_LOOP_MT_MAX_THREADS);
return;
}
config->max_idle_threads = value;
}
however, there are two separate defaults (one as the argument, and one
in fuse_loop_mt.c), and
fuse_loop_mt.c:#define FUSE_LOOP_MT_DEF_IDLE_THREADS -1 /* thread destruction 
is disabled
fuse_loop_mt.c: config->max_idle_threads = FUSE_LOOP_MT_DEF_IDLE_THREADS;
so -1 is valid by default if unset, defaults to being passed as -1, and
is illegal there.

Please make the condition
 (value > FUSE_LOOP_MT_MAX_THREADS &&
  value != FUSE_LOOP_MT_DEF_IDLE_THREADS)

Best,
наб

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

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

Versions of packages fuse3 depends on:
ii  adduser 3.134
ii  libc6   2.36-9
ii  libfuse3-3  3.14.0-4
ii  mount   2.38.1-5+b1
ii  sed 4.9-1

fuse3 recommends no packages.

fuse3 suggests no packages.

-- Configuration Files:
/etc/fuse.conf changed:
user_allow_other


-- no debconf information


signature.asc
Description: PGP signature

Bug#1037409: golang-golang-x-exp ftbfs with gccgo-go (both gccgo-12 and gccgo-13)

[Pirate Praveen]

Package: src:golang-golang-x-exp
Version: 0.0~git20221028.83b7d23-2
Severity: serious

Building with golang-any changed to gccgo-go to force gccgo on amd64, 
build fails with error. Full build log attached. Either this should be 
fixed or dependency should be updated to golang-go instead of golang-any.


golang.org/x/exp/maps
# golang.org/x/exp/maps
src/golang.org/x/exp/maps/maps.go:10:10: error: expected ‘(’
   10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
  |  ^
src/golang.org/x/exp/maps/maps.go:10:13: error: invalid character 0x7e 
in input file

   10 | func Keys[M ~map[K]V, K comparable, V any](m M) []K {
  | ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘]’
   11 | r := make([]K, 0, len(m))
  | ^
src/golang.org/x/exp/maps/maps.go:11:9: error: expected ‘;’ or newline 
after top level declaration

src/golang.org/x/exp/maps/maps.go:12:9: error: expected declaration
   12 | for k := range m {
  | ^
src/golang.org/x/exp/maps/maps.go:14:9: error: expected declaration
   14 | }
  | ^
src/golang.org/x/exp/maps/maps.go:15:9: error: expected declaration
   15 | return r
  | ^
src/golang.org/x/exp/maps/maps.go:16:1: error: expected declaration
   16 | }
  | ^
sbuild (Debian sbuild) 0.85.2 (11 March 2023) on mahishi

+===+
| golang-golang-x-exp 0.0~git20221028.83b7d23-2 (amd64) Mon, 12 Jun 2023 
12:47:20 + |
+===+

Package: golang-golang-x-exp
Version: 0.0~git20221028.83b7d23-2
Source Version: 0.0~git20221028.83b7d23-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-24a3fad7-52f9-45d5-ba4b-67774cece214'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-golang-x-exp-PqPMEI/resolver-ugb2fS' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/home/pravi/forge/go-team/golang-golang-x-exp_0.0~git20221028.83b7d23-2.dsc 
exists in /home/pravi/forge/go-team; copying to chroot
I: NOTICE: Log filtering will replace 
'build/golang-golang-x-exp-PqPMEI/golang-golang-x-exp-0.0~git20221028.83b7d23' 
with '<>'
I: NOTICE: Log filtering will replace 'build/golang-golang-x-exp-PqPMEI' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-sequence-golang, gccgo-go (>= 
2:1.18~), gccgo-13, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-sequence-golang, gccgo-go 
(>= 2:1.18~), gccgo-13, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [670 B]
Get:5 copy:/<>/apt_archive ./ Packages [702 B]
Fetched 1981 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  autoconf automake autopoint autotools-dev bsdextrautils cpp-13 debhelper
  dh-autoreconf dh-golang dh-strip-nondeterminism dwz file gcc-13 gccgo-12
  gccgo-13 gccgo-go gettext gettext-base groff-base intltool-debian
  libarchive-zip-perl libdebhelper-perl libelf1
  libfile-stripnondeterminism-perl libgcc-13-dev libgo-12-dev libgo-13-dev
  libgo21 libgo22 libhwasan0 libicu72 libmagic-mgc libmagic1 libpipeline1
  libsub-override-perl libtool libuchardet0 libxml2 m4 man-db po-debconf
  sensible-utils
Suggested packages:
  autoconf-archive