Bug#1060130: bullseye-pu: package libmateweather/1.24.1-1+deb11u1

2024-01-05 Thread Mike Gabriel

Hi,

unfortunately, this mail left my system before it was complete. See below.

On  Sa 06 Jan 2024 08:36:21 CET, Mike Gabriel wrote:


Please unblock the recent bullseye-pu upload of libmateweather.

[ Reason ]
Main reason for providing the pu is that Aviation Weather changed their
data server URL for retrieving weather information from their servers.

While at it, more data changes have been cherry-picked from upstream (see
below).

[ Impact ]
If this pu does not get accepted, Debian users will have a broken
weather-applet on MATE desktop. No weather information can be retrieved.

[ Tests ]
Manually installed the new .deb version and tested the MATE weather applet
regarding the introduced changes (on a Debian (Edu) bullseye system).

[ Risks ]
Regressions are always possible. MATE users will be affected. Esp. when using
weather reports on their desktop.

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



[ Changes ]

+  * debian/patches: Cherry-pick upstream fixes from libmateweather  
1.24 branch:

++ add 0001_add-two-brazilian-cities.patch
++ add 0002_remove-Berlin-Tegel.patch
+  * debian/patches: Cherry-pick upstream fixes from libmateweather  
1.26 branch:

++ add (and comment out) 0011_Kyiv-timezone.patch (tzdata in bullseye
+  still uses the old Europe/Kiew
++ add city: 0012_add-San-Miguel-de-Tucuman-Argentina.patch
++ update Chicago area codes: 0013_Chicago-area-updates.patch
++ update data server URL: 0014_data-server-url-changed.patch (Closes:
+  #1054248, #1054268)
++ typo fixes in location names: 0005_fix-some-location-names.patch
++ new Tbilisi airport code: 0006_tbilisi-IATA-airport-code-changed.patch
++ Add follow-up patch  
0014b_The-url-with-www.-is-a-permanent-redirect-308-

+  to-the.patch. The url with 'www.aviationweather.gov' is a permanent
+  redirect (308) to the url without 'www.'.

[ Other info ]
This bullseye-pu brings libmateweather onto a similar level as  
libmateweather in bookworm after the bookworm-pu 1.26.0-1.1+deb12u2  
(2!) has been accepted (see #1060129).


light+love,
Mike


--

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

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



pgpSYvCt8lgCU.pgp
Description: Digitale PGP-Signatur


Bug#1060130: bullseye-pu: package libmateweather/1.24.1-1+deb11u1

2024-01-05 Thread Mike Gabriel
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libmateweat...@packages.debian.org
Control: affects -1 + src:libmateweather

Please unblock the recent bullseye-pu upload of libmateweather.

[ Reason ]
Main reason for providing the pu is that Aviation Weather changed their
data server URL for retrieving weather information from their servers.

While at it, more data changes have been cherry-picked from upstream (see
below).

[ Impact ]
If this pu does not get accepted, Debian users will have a broken
weather-applet on MATE desktop. No weather information can be retrieved.

[ Tests ]
Manually installed the new .deb version and tested the MATE weather applet
regarding the introduced changes (on a Debian (Edu) bullseye system).

[ Risks ]
Regressions are always possible. MATE users will be affected. Esp. when using
weather reports on their desktop.

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

[ Changes ]


[ Other info ]
(Anything else the release team should know.)
diff -Nru libmateweather-1.24.1/debian/changelog 
libmateweather-1.24.1/debian/changelog
--- libmateweather-1.24.1/debian/changelog  2020-08-21 23:20:54.0 
+0200
+++ libmateweather-1.24.1/debian/changelog  2023-12-13 14:48:25.0 
+0100
@@ -1,3 +1,23 @@
+libmateweather (1.24.1-1+deb11u1) bullseye; urgency=medium
+
+  * debian/patches: Cherry-pick upstream fixes from libmateweather 1.24 branch:
++ add 0001_add-two-brazilian-cities.patch
++ add 0002_remove-Berlin-Tegel.patch
+  * debian/patches: Cherry-pick upstream fixes from libmateweather 1.26 branch:
++ add (and comment out) 0011_Kyiv-timezone.patch (tzdata in bullseye
+  still uses the old Europe/Kiew
++ add city: 0012_add-San-Miguel-de-Tucuman-Argentina.patch
++ update Chicago area codes: 0013_Chicago-area-updates.patch
++ update data server URL: 0014_data-server-url-changed.patch (Closes:
+  #1054248, #1054268)
++ typo fixes in location names: 0005_fix-some-location-names.patch
++ new Tbilisi airport code: 0006_tbilisi-IATA-airport-code-changed.patch
++ Add follow-up patch 0014b_The-url-with-www.-is-a-permanent-redirect-308-
+  to-the.patch. The url with 'www.aviationweather.gov' is a permanent
+  redirect (308) to the url without 'www.'.
+
+ -- Mike Gabriel   Wed, 13 Dec 2023 14:48:25 +0100
+
 libmateweather (1.24.1-1) unstable; urgency=medium
 
   [ Martin Wimpress ]
diff -Nru 
libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch 
libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch
--- libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch
1970-01-01 01:00:00.0 +0100
+++ libmateweather-1.24.1/debian/patches/0001_add-two-brazilian-cities.patch
2023-12-13 14:48:25.0 +0100
@@ -0,0 +1,47 @@
+From 90cc76a2b0e8d57ec17a5ca81d00fa7e6808076a Mon Sep 17 00:00:00 2001
+From: raveit65 
+Date: Wed, 7 Apr 2021 21:41:14 +0200
+Subject: [PATCH] add 2 brazil cities
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+- Joinville and São Bento do Sul
+- fixes https://github.com/mate-desktop/libmateweather/issues/94
+---
+ data/Locations.xml.in | 22 ++
+ 1 file changed, 22 insertions(+)
+
+diff --git a/data/Locations.xml.in b/data/Locations.xml.in
+index a80dacd1..19b61c00 100644
+--- a/data/Locations.xml.in
 b/data/Locations.xml.in
+@@ -9787,6 +9787,28 @@
+ -27.67 -48.55
+   
+ 
++
++  
++  Joinville
++  -26.30444 -48.84556
++  
++Joinville Airport
++SBJV
++America/Sao_Paulo
++-26.22444 -48.79722
++  
++
++
++  
++  São Bento do Sul
++  -26.25028 -49.37861
++  
++São Bento do Sul
++SBSB
++America/Sao_Paulo
++-26.25028 -49.37861
++  
++
+   
+   
+ 
diff -Nru libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch 
libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch
--- libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch 
1970-01-01 01:00:00.0 +0100
+++ libmateweather-1.24.1/debian/patches/0002_remove-Berlin-Tegel.patch 
2023-12-13 14:48:25.0 +0100
@@ -0,0 +1,30 @@
+From 74c7f241a34e85b1aa33daa9fd595b17b65756c1 Mon Sep 17 00:00:00 2001
+From: Benjamin Valentin 
+Date: Tue, 6 Jul 2021 15:50:47 +0200
+Subject: [PATCH] locations: drop Berlin Tegel
+
+Berlin Tegel Airport shut down on 4th of May 2021 and will be converted
+into the 'Urban Tech Republic' quarters.
+
+It currently serves as a COVID-19 vaccination center, it 

Bug#1060129: bookworm-pu: package libmateweather/1.26.0-1.1+deb12u2

2024-01-05 Thread Mike Gabriel
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libmateweat...@packages.debian.org
Control: affects -1 + src:libmateweather

A minor fix has been released as libmateweather 1.26.3 which shall be
cherry-picked into the libmateweather version in Debian bookworm.

[ Reason ]
It turned out that the updated URL used for accessing the
aviationweather.gov service was permanent redirect. This shall be
amended with the next point release.

[ Impact ]
Minimal, mostly an issue for the service provider of aviationweather.gov
(as all Debian stable versions of libmateweather will access their
permanent redirect rather than the real target URL).

[ Tests ]
Manually.

[ Risks ]
Very low.

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

[ Changes ]

+  * debian/patches:
++ Add follow-up patch 0004b_The-url-with-www.-is-a-permanent-redirect-308-
+  to-the.patch. The url with 'www.aviationweather.gov' is a permanent
+  redirect (308) to the url without 'www.'. (Cherry-picked from v1.26.3).

[ Other info ]
This is a direct follow-up for libmateweather 1.26.0-1.1+deb12u1.
diff -Nru libmateweather-1.26.0/debian/changelog 
libmateweather-1.26.0/debian/changelog
--- libmateweather-1.26.0/debian/changelog  2023-10-31 08:25:09.0 
+0100
+++ libmateweather-1.26.0/debian/changelog  2024-01-06 08:27:01.0 
+0100
@@ -1,3 +1,12 @@
+libmateweather (1.26.0-1.1+deb12u2) bookworm; urgency=medium
+
+  * debian/patches:
++ Add follow-up patch 0004b_The-url-with-www.-is-a-permanent-redirect-308-
+  to-the.patch. The url with 'www.aviationweather.gov' is a permanent
+  redirect (308) to the url without 'www.'. (Cherry-picked from v1.26.3).
+
+ -- Mike Gabriel   Sat, 06 Jan 2024 08:27:01 +0100
+
 libmateweather (1.26.0-1.1+deb12u1) bookworm; urgency=medium
 
   * debian/patches: Cherry-pick (and re-arrange) upstream fixes.
diff -Nru 
libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch
 
libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch
--- 
libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libmateweather-1.26.0/debian/patches/0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch
   2024-01-06 08:23:50.0 +0100
@@ -0,0 +1,27 @@
+From 5b068a6e73e96db512ca8c60a11d31c068a5375f Mon Sep 17 00:00:00 2001
+From: Olivier Gagnon 
+Date: Sun, 19 Nov 2023 13:47:25 -0500
+Subject: [PATCH] The url with 'www.' is a permanent redirect (308) to the url
+ without it
+
+Signed-off-by: Mike Gabriel 
+---
+ libmateweather/weather-metar.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/libmateweather/weather-metar.c b/libmateweather/weather-metar.c
+index 0ae2cbb..7bc24fc 100644
+--- a/libmateweather/weather-metar.c
 b/libmateweather/weather-metar.c
+@@ -550,7 +550,7 @@ metar_start_open (WeatherInfo *info)
+ }
+ 
+ msg = soup_form_request_new (
+-"GET", "https://www.aviationweather.gov/cgi-bin/data/dataserver.php;,
++"GET", "https://aviationweather.gov/cgi-bin/data/dataserver.php;,
+ "dataSource", "metars",
+ "requestType", "retrieve",
+ "format", "xml",
+-- 
+2.39.2
+
diff -Nru libmateweather-1.26.0/debian/patches/series 
libmateweather-1.26.0/debian/patches/series
--- libmateweather-1.26.0/debian/patches/series 2023-10-31 08:17:48.0 
+0100
+++ libmateweather-1.26.0/debian/patches/series 2024-01-06 08:25:04.0 
+0100
@@ -2,5 +2,6 @@
 0002_add-San-Miguel-de-Tucuman-Argentina.patch
 0003_Chicago-area-updates.patch
 0004_data-server-url-changed.patch
+0004b_The-url-with-www.-is-a-permanent-redirect-308-to-the.patch
 0005_fix-some-location-names.patch
 0006_tbilisi-IATA-airport-code-changed.patch


Bug#1060128: ITP: python-sphinxcontrib-github-alt -- Sphinx extension for easy GitHub links

2024-01-05 Thread Dale Richards
Package: wnpp
Severity: wishlist
Owner: Dale Richards 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dalerichards.net

* Package name: python-sphinxcontrib-github-alt
  Version : 1.2
  Upstream Contact: Jupyter Development Team 
* URL : https://github.com/jupyter/sphinxcontrib_github_alt
* License : BSD 2-clause
  Programming Lang: Python
  Description : Sphinx extension for easy GitHub links

 Link to GitHub issues, pull requests, commits and users for a particular
 project.

I intend to maintain this package within the Debian Python Team.



Bug#1060127: radare2: Add basic support for LoongArch

2024-01-05 Thread Zhang Na
Source: radare2
Version: 5.5.0+dfsg-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  Add basic support for LoongArch, without this patch, building on LoongArch 
will fail.
  https://github.com/radareorg/radare2/pull/19505, the PR has been merged.



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 2fcdd59ed81bd016ca9a43529f082feac0277bfe Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Sat, 6 Jan 2024 07:01:31 +
Subject: [PATCH] add loongarch support

---
 libr/core/cconfig.c   |  2 +-
 libr/debug/p/debug_native.c   |  4 ++
 libr/debug/p/native/linux/linux_debug.c   |  2 +
 libr/debug/p/native/linux/linux_debug.h   |  6 ++
 .../p/native/linux/reg/linux-loongarch64.h| 66 +++
 .../r_jemalloc/internal/jemalloc_internal.h   |  3 +
 libr/include/r_types.h|  4 ++
 libr/include/r_util/r_sys.h   |  2 +
 8 files changed, 88 insertions(+), 1 deletion(-)
 create mode 100644 libr/debug/p/native/linux/reg/linux-loongarch64.h

diff --git a/libr/core/cconfig.c b/libr/core/cconfig.c
index e995238..4ac8560 100644
--- a/libr/core/cconfig.c
+++ b/libr/core/cconfig.c
@@ -3668,7 +3668,7 @@ R_API int r_core_config_init(RCore *core) {
r_config_set_getter (cfg, "dbg.swstep", 
(RConfigCallback)__dbg_swstep_getter);
 
 // TODO: This should be specified at first by the debug backend when attaching
-#if __arm__ || __mips__
+#if __arm__ || __mips__ || __loongarch__
SETICB ("dbg.bpsize", 4, _dbgbpsize, "Size of software breakpoints");
 #else
SETICB ("dbg.bpsize", 1, _dbgbpsize, "Size of software breakpoints");
diff --git a/libr/debug/p/debug_native.c b/libr/debug/p/debug_native.c
index bd7c686..bcfe04a 100644
--- a/libr/debug/p/debug_native.c
+++ b/libr/debug/p/debug_native.c
@@ -1622,6 +1622,10 @@ RDebugPlugin r_debug_plugin_native = {
.bits = R_SYS_BITS_32 | R_SYS_BITS_64,
.arch = "mips",
.canstep = false,
+#elif __loongarch
+   .bits = R_SYS_BITS_32 | R_SYS_BITS_64,
+   .arch = "loongarch",
+   .canstep = false,
 #elif __powerpc__
 # if __powerpc64__
.bits = R_SYS_BITS_32 | R_SYS_BITS_64,
diff --git a/libr/debug/p/native/linux/linux_debug.c 
b/libr/debug/p/native/linux/linux_debug.c
index 569aa71..34700bc 100644
--- a/libr/debug/p/native/linux/linux_debug.c
+++ b/libr/debug/p/native/linux/linux_debug.c
@@ -39,6 +39,8 @@ char *linux_reg_profile (RDebug *dbg) {
} else {
 #  include "reg/linux-mips64.h"
}
+#elif __loongarch__
+#  include "reg/linux-loongarch64.h"
 #elif (__i386__ || __x86_64__)
if (dbg->bits & R_SYS_BITS_32) {
 #if __x86_64__
diff --git a/libr/debug/p/native/linux/linux_debug.h 
b/libr/debug/p/native/linux/linux_debug.h
index 55cebb6..0f2f882 100644
--- a/libr/debug/p/native/linux/linux_debug.h
+++ b/libr/debug/p/native/linux/linux_debug.h
@@ -105,6 +105,12 @@ struct powerpc_regs_t {
 #include 
 typedef ut64 mips64_regs_t [274];
 #define R_DEBUG_REG_T mips64_regs_t
+
+#elif __loongarch__
+
+#include 
+typedef ut64 la_regs_t [274];
+#define R_DEBUG_REG_T la_regs_t
 #endif
 #endif
 
diff --git a/libr/debug/p/native/linux/reg/linux-loongarch64.h 
b/libr/debug/p/native/linux/reg/linux-loongarch64.h
new file mode 100644
index 000..ae85d66
--- /dev/null
+++ b/libr/debug/p/native/linux/reg/linux-loongarch64.h
@@ -0,0 +1,66 @@
+#if 0
+   reg  nameusage
+   ---+---+-
+   0zero   always zero
+   1 rareturn address
+   2 tpTLS
+   3 spstack pointer
+   4-11  a0-a7 argument
+   4-5   v0-v1 return value
+   12-20 t0-t8 temp
+   21x reserved
+   22fpframe point
+   23-31 s0-s8 subroutine registe variables
+#endif
+
+   return strdup (
+   "=PCpc\n"
+   "=SPsp\n"
+   "=BPfp\n"
+   "=A0a0\n"
+   "=A1a1\n"
+   "=A2a2\n"
+   "=A3a3\n"
+   "=A4a0\n"
+   "=A5a1\n"
+   "=A6a2\n"
+   "=A7a3\n"
+   "gprzero.64 0   0\n"
+   "gprra  .64 8   0\n"
+   "gprtp  .64 16  0\n"
+   "gprsp  .64 24  0\n"
+   /* args */
+   "gpra0  .64 32  0\n"
+   "gpra1  .64 40  0\n"
+   /*FIXME v0 v1 and a0 a1 are overlapping*/
+   "gpra2  .64 48  0\n"
+   "gpra3  .64 56  0\n"
+   "gpra4  

Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

2024-01-05 Thread Johannes Schauer Marin Rodrigues
Quoting Paul Gevers (2024-01-05 20:15:22)
> Thanks for reaching out.

Thank Helmut for poking me in #debian-apt :)

> For britney2, the Sources stanza would also be needed; then we could use this
> to generate britney2 testcases. I created 10 of those yesterday by hand [1].
> 
> The simplest for of tests is a tree with
> var/data/unstable/Sources
> # i386 is the default archive of the testsuite, which can be overruled
> # if that makes sense
> var/data/unstable/Packages_i386
> var/data/testing/Sources (may be empty)
> var/data/testing/Packages_i386
> expected
> 
> expected is in Heidi format (if I understand correctly) of what britney2 
> will allow to be in testing after the run, it will only migrate packages 
> that are installable.
> 
> Would it make sense to you to generate a branch in that archive with a bunch
> of tests that you know the answer too?

I think it's a bit more complicated than that. Currently, the tool creates 8624
package relationships. If I remember correctly, britney is unable to analyze
cross-architecture relationships? In that case that number goes down to 2352.
One could reduce that number even further and only check those cases where apt,
dpkg and dose3 agree on a solution but that would then rather be a
documentation of the status quo than a list of the intended ground truth. Maybe
it would make sense to analyze the archive and only add those cases that
currently exist as real package relationships?

What the tool never received since its inception was somebody to look over
these cases and write down what the ground-truth actually is supposed to look
like. For the britney tests you likely want some kind of ground-truth and I
fear that tool can give you the status quo but not necessarily the truth as
intended by the spec.

If that is fine for you, do you still want to add thousands of test-cases? Or
do you want to hand-pick them?

Thanks!

cheers, josch

signature.asc
Description: signature


Bug#1058924: gnome-software: does not list or find any apt package

2024-01-05 Thread Matthias Klumpp
Am Fr., 5. Jan. 2024 um 18:20 Uhr schrieb Jeremy Bícha
:
>
> On Fri, Jan 5, 2024 at 11:08 AM Matthias Klumpp  wrote:
> > I do recall something being fixed on that front months ago, but I
> > couldn't find  the patch (so maybe testing with 46.beta is a good
> > plan, to see if that one resolves the issue).
>
> GNOME Software 46 Alpha was released today. I installed it and it
> didn't fix my problem. I guess I could upload it to Unstable or
> Experimental.

Sorry, I got a bit confused since my local Git copy showed 46 Beta ^^
I poked it a bit and it looks like
https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1862
fixes the issue completely for me and OS applications show up again.
So, this would be a MIME detection issue, unless it's a combination of
separate problems that we are dealing with.

Cheers,
Matthias

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



Bug#1060126: ITP: golang-github-azuread-microsoft-authentication-extensions-for-go -- Microsoft Authentication Library (MSAL) Extensions for Go (library)

2024-01-05 Thread Maytham Alsudany
Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1059083 by -1

* Package name: 
golang-github-azuread-microsoft-authentication-extensions-for-go
  Version : 0.0~git20231002.7e3b8e2
  Upstream Contact: 
https://github.com/AzureAD/microsoft-authentication-extensions-for-go/issues
* URL : 
https://github.com/AzureAD/microsoft-authentication-extensions-for-go
* License : Expat
  Programming Lang: Go
  Description : Microsoft Authentication Library (MSAL) Extensions for Go 
(library)

 This package contains extension modules for Microsoft Authentication Library
 (MSAL) for Go.

Needed for new version of golang-github-azure-azure-sdk-for-go

Will be maintained within the Go team, and will need a sponsor.

--
Kind regards,
Maytham Alsudany


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


Bug#1060125: qemu-web-desktop: Please add loong64 binary output

2024-01-05 Thread yalingfang

Source: qemu-web-desktop
Version: 23.06.22+ds1-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64


Dear Maintainer,
     Currently no loong64 binary output for mindthegap in Loongarch env.
The buildd link is following:

https://buildd.debian.org/status/package.php?p=qemu-web-desktop=sid

I have verified and compiled pass by adding loong64 to debian/control 
file in my local env(Currently no pandoc related).

Attach the control patch.


Please add support for it. Thanks!
Any question, contact me!


add_loong64_binary_output.patch
Description: Binary data


Bug#1060124: ITP: golang-github-azure-go-amqp -- aMQP 1.0 client library for Go (library)

2024-01-05 Thread Maytham Alsudany
Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
Control: block 1059083 by -1

* Package name: golang-github-azure-go-amqp
  Version : 1.0.2
  Upstream Contact: https://github.com/Azure/go-amqp/issues
* URL : https://github.com/Azure/go-amqp
* License : Expat
  Programming Lang: Go
  Description : aMQP 1.0 client library for Go (library)

 The amqp module is an AMQP 1.0 client implementation for Go.
 .
 AMQP 1.0 is not compatible with AMQP 0-9-1 or 0-10.

Needed for new version of golang-github-azure-azure-sdk-for-go

--
Kind regards,
Maytham Alsudany


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


Bug#1055550: Removal of Python3 package of redland-bindings breaks mozilla-devscripts

2024-01-05 Thread Andreas Tille
Hi Doko,

thanks for working on the QA upload to fix #100 and #1056518 of
redland-bindings by simply removing the Python3 support.  Unfortunately
it breaks mozilla-devscripts and thus it cant migrate to testing[1].

Kind regards
Andreas.


[1] https://qa.debian.org/excuses.php?package=redland-bindings

-- 
http://fam-tille.de



Bug#1054152: rasdaemon: frequent crashes of rasdaemon

2024-01-05 Thread Taihsiang Ho (tai271828)
Hi piorunz,

Thanks for testing. I will work on bug 1059484 first, and don't have
ETA of the backport. Feel free to send me a patch of the backport if
you are interested.

-tai

On Mon, Dec 11, 2023 at 8:26 PM piorunz  wrote:
>
> On 11/12/2023 14:20, Russell Coker wrote:
> > We have 2 different issues here.  The first one is a SEGV related to sqlite,
> > that might be a sqlite bug.  Have you tried writing a simple sqlite program 
> > or
> > using a sqlite utility to see if it also crashes?
>
> Sorry, I have no ability to write such a program.
>
> > The issue being discussed now is separate.  As most of this bug report is 
> > now
> > about the other issue could you file a different bug just about the sqlite
> > side of things and we can then reassign it to sqlite if appropriate?
>
> SIGBUS problem will go away in no time, as this has not come back since
> I installed patch earlier today. Looks like this fixes it.
> Tai, please import this 1 line change to Debian Stable, that would be
> awesome if you could.
>
> And now we can come back to the issue from my original report.
> I am waiting for another crash to give you more information.
>
> --
> With kindest regards, Piotr.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄
>



Bug#1060123: knot: Please update libknot14.symbols.loong64

2024-01-05 Thread yalingfang

Source:  knot
Version: 1.4.0-1
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear Maintainer,

     The symbols error happens when build knot in Loongarch.

The error message is following:

dh_makeshlibs: error: failing due to earlier errors
make: *** [debian/rules:51: binary] Error 255

I have compiled and all cases passed  in my local env.

Attach the symbols patch.
Please add support for it. Thanks!
Any question, contact me!


libknot14.symbols.loong64.diff
Description: Binary data


Bug#1060122: bookworm-pu: package atril/1.26.0-2+deb12u1

2024-01-05 Thread Mike Gabriel
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: at...@packages.debian.org
Control: affects -1 + src:atril

While preparing a new upstream release upload of atril 1.26.1-1 to
unstable (already some days ago), a bookwork-pu upload has (now) also
been prepared.

[ Reason ]
Upstream fixed two issues regarding epub file opening robustness in
v1.26.1. Also, one patch could be cherry-picked from a bug report in
Debian BTS (#972715).

Additionally, the 'Hide sidebar' button was lacking a11y text which has
also now been added.

[ Impact ]
Impact of rejecting this bookworm-pu is low. Outcome: Less epub
robustness, a11y text for 'Hide sidebar' remains missing.

[ Tests ]
Manually (build and test on local bookworm system).

[ Risks ]
Regressions are always possible. Atril is used as PDF reader in MATE and
Xfce4, so those users will be affected.

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

[ Changes ]

+  * debian/patches:
++ Add 1002-avoid-crash-on-certain-epub-files.patch. Avoid crashes when
+  opening certain epub files. (Closes: #972715).
++ Add 0001-Accessibility-add-button-description.patch. Accessibility: add
+  'Hide sidebar' button description. (Cherry-picked from v1.26.1).
++ Add 0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch. Fix
+  index loading for certain epub documents. (Cherry-picked from v1.26.1).
++ Add 0004-epub-add-fallback-for-malformed-epub-files-in-check_.patch. 
epub:
+  add fallback for malformed epub files in check_mime_type. (Cherry-picked 
from
+  v1.26.1).

[ Other info ]
None.
diff -Nru atril-1.26.0/debian/changelog atril-1.26.0/debian/changelog
--- atril-1.26.0/debian/changelog   2022-10-27 11:00:10.0 +0200
+++ atril-1.26.0/debian/changelog   2024-01-06 07:18:28.0 +0100
@@ -1,3 +1,18 @@
+atril (1.26.0-2+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 1002-avoid-crash-on-certain-epub-files.patch. Avoid crashes when
+  opening certain epub files. (Closes: #972715).
++ Add 0001-Accessibility-add-button-description.patch. Accessibility: add
+  'Hide sidebar' button description. (Cherry-picked from v1.26.1).
++ Add 0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch. Fix
+  index loading for certain epub documents. (Cherry-picked from v1.26.1).
++ Add 0004-epub-add-fallback-for-malformed-epub-files-in-check_.patch. 
epub:
+  add fallback for malformed epub files in check_mime_type. (Cherry-picked 
from
+  v1.26.1).
+
+ -- Mike Gabriel   Sat, 06 Jan 2024 07:18:28 +0100
+
 atril (1.26.0-2) unstable; urgency=medium
 
   [ Mike Gabriel ]
diff -Nru 
atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch 
atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch
--- atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch 
1970-01-01 01:00:00.0 +0100
+++ atril-1.26.0/debian/patches/0001-Accessibility-add-button-description.patch 
2024-01-06 07:18:28.0 +0100
@@ -0,0 +1,47 @@
+From 9a981607b36488ea5d2ce8646540b1545e35ecd5 Mon Sep 17 00:00:00 2001
+From: Valentin Villenave 
+Date: Tue, 26 Oct 2021 19:29:01 +0200
+Subject: [PATCH 01/10] Accessibility: add button description
+
+Signed-off-by: Mike Gabriel 
+---
+ po/POTFILES.in | 1 +
+ shell/ev-sidebar.c | 3 +++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/po/POTFILES.in b/po/POTFILES.in
+index 02b9435..08ab5ec 100644
+--- a/po/POTFILES.in
 b/po/POTFILES.in
+@@ -67,6 +67,7 @@ shell/ev-password-view.c
+ shell/ev-properties-dialog.c
+ shell/ev-properties-fonts.c
+ shell/ev-properties-license.c
++shell/ev-sidebar.c
+ shell/ev-sidebar-annotations.c
+ shell/ev-sidebar-attachments.c
+ shell/ev-sidebar-bookmarks.c
+diff --git a/shell/ev-sidebar.c b/shell/ev-sidebar.c
+index b9173cd..0cdb6be 100644
+--- a/shell/ev-sidebar.c
 b/shell/ev-sidebar.c
+@@ -26,6 +26,8 @@
+ 
+ #include 
+ 
++#include 
++#include 
+ #include 
+ #include 
+ 
+@@ -362,6 +364,7 @@ ev_sidebar_init (EvSidebar *ev_sidebar)
+   g_signal_connect (close_button, "clicked",
+ G_CALLBACK (ev_sidebar_close_clicked_cb),
+ ev_sidebar);
++  gtk_widget_set_tooltip_text (close_button, _("Hide sidebar"));
+ 
+   image = gtk_image_new_from_icon_name ("window-close",
+ GTK_ICON_SIZE_MENU);
+-- 
+2.39.2
+
diff -Nru 
atril-1.26.0/debian/patches/0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch
 
atril-1.26.0/debian/patches/0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch
--- 
atril-1.26.0/debian/patches/0003-epub-Fix-index-loading-for-certain-documents-look-fo.patch
 1970-01-01 

Bug#989998: Fixed upstream: need help ?

2024-01-05 Thread Salvatore Bonaccorso
Hi,

On Fri, Jan 05, 2024 at 10:25:34PM +, Bastien Roucariès wrote:
> Hi,
> 
> I have just fix this CVE for buster and I want to know if you need help to 
> release a fix for unstable ?
> 
> The LTS fix are here https://salsa.debian.org/lts-team/packages/keystone/

AFAICS this issue has been fixed upstream in 23.0.0.0rc1 and included
the first time in Debian with the experimental upload of
2:23.0.0~rc1-1 (and in unstable with 2:23.0.0-3)

Thomas, can you double check if this is correct and then update the
Debian bug metadata accordingly?

Regards,
Salvatore



Bug#1052652: ghostscript: eps2write fails on test file

2024-01-05 Thread Steven Robbins
tags 1052652 upstream
forwarded 1052652 https://bugs.ghostscript.com/show_bug.cgi?id=707368
thanks


On Mon, 25 Sep 2023 20:05:27 +0200 Roland Rosenfeld  wrote:
> Package: ghostscript
> Version: 10.02.0~dfsg-2
> Severity: important
> 
> Dear Maintainer,
> 
> upgrading ghostscript from 10.01.2~dfsg-1 to 10.02.0~dfsg-2 triggers a
> regression in the testsuite of fig2dev.

Reproduced with ghostscript 10.02.1.

> By trial-and-error I found out, that removing the option
> "-sPageList=1" avoids the error, but this may result in other side
> effects in fig2dev, since the above commend only wants to convert the
> first page of the document.

Thanks!  This looks like the upstream bug https://bugs.ghostscript.com/
show_bug.cgi?id=707368

-Steve


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


Bug#965275: atril: slow scrolling for large documents

2024-01-05 Thread Mike Gabriel

Control: fixed -1 1.26.0-1

On  Sa 06 Jan 2024 07:08:41 CET, Mike Gabriel wrote:


Control: fixed 1.26.0-1

Resending with hopefully more correct closure control command.


Sigh... (amending fixed control command).


--

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

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



pgpFMHjCwq9F2.pgp
Description: Digitale PGP-Signatur


Bug#965275: atril: slow scrolling for large documents

2024-01-05 Thread Mike Gabriel

Control: close -1
Control: fixed 1.26.0-1

On  Sa 06 Jan 2024 06:56:21 CET, Mike Gabriel wrote:


Close: -1
Version: 1.26.0-1


Resending with hopefully more correct closure control command.
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpsDU5da3eGR.pgp
Description: Digitale PGP-Signatur


Bug#1000877: atril: scrolling is sometimes slow, as if the Shift key were pressed

2024-01-05 Thread Mike Gabriel

Hi Vincent,

On  Di 30 Nov 2021 16:33:38 CET, Vincent Lefevre wrote:


Package: atril
Version: 1.24.0-1+b1
Severity: minor

When I scroll a document by dragging the scrollbar thumb with the
mouse, scrolling is sometimes slow, as if the Shift key were pressed.
This seems to occur when I press the thumb, then move it only once it
is disappearing (but this is not always reproducible); note that if I
wait a bit too long, I can no longer scroll at all (see bug 1000874).


Could you check if the above problem still occurs with atril 1.26.x as  
found in Debian bookworm/trixie?


I assume that this has been resolved via  
https://github.com/mate-desktop/atril/commit/50d0b23c608020dd1da3fb3e13883941182ec89e


Thanks for your feedback,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpLCezpDZ2n7.pgp
Description: Digitale PGP-Signatur


Bug#939269: atril: please provide a version of atril without webkit dependencies

2024-01-05 Thread Mike Gabriel

Close: -1
Tags: wontfix

On  Mo 02 Sep 2019 19:31:11 CEST, Rogério Brito wrote:


Package: atril
Version: 1.22.1-1
Severity: wishlist

Hi. Thanks for packaging atril in Debian.

For those people that don't use atril for epubs or for those that want a
lighter installation, can a version of atril be provided without all the
webkit support?

This would really help keeping systems leaner.


Thanks,

Rogério Brito.


We will not provide two versions of atril. Closing with tag "wontfix".

Mike
--

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

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



pgpmu6RsDD5Rx.pgp
Description: Digitale PGP-Signatur


Bug#965275: atril: slow scrolling for large documents

2024-01-05 Thread Mike Gabriel

Close: -1
Version: 1.26.0-1

On  Fr 04 Dez 2020 13:07:43 CET, Fabio Fantoni wrote:


If this patch is still not applied upstream I think is good do a PR to
have it in next versions.


This issue has been resolved by upstream in atril 1.26.0. Thus,  
closing this issue.


I will post-upload add the bug closure to d/changelog of the 1.26.0-1 upload.

Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpoi4GctwVHc.pgp
Description: Digitale PGP-Signatur


Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
On Fri, Jan 05, 2024 at 05:36:10PM +0100, Rene Engelhard wrote:
> > My strawman proposal is to give this thread 2 weeks from today for feedback
> > and further refinement, and also to further reduce the number of
> > false-positives included in the transition.  Then, starting on Jan 18:

> > - dpkg will be uploaded to experimental with 64-bit time_t in the default
> >flags

> I  think at that point in time one should know what breaks and whatnot.
> Archive rebuild?

> (Probably in stages)

What kind of breakage are you looking to avoid here?  As mentioned in other
points in the thread, regressions as a result of this change should be rare
and easy to fix.  I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.

> > - the source packages which need an ABI change
> >("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to

> I get that you probably want NMUs for not needing to ping every maintainer,
> but this is bad.

> That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
> when tagged end of next week to not have this caught in the transition. (see
> also below for the comment about new upstream versions in experimental.)

What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?

libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.

I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern.  It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.

> >experimental with the new binary package names in order to clear binary
> >NEW, in coordination

> And what about skipped ones?  When will those be tried?

What do you mean here by "skipped ones"?

-- 
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#819914: imagemagick: please honour SOURCE_DATE_EPOCH

2024-01-05 Thread James Addison
Followup-For: Bug #819914
X-Debbugs-Cc: p...@passoire.fr
Control: forwarded -1 https://github.com/ImageMagick/ImageMagick/pull/1496
Control: tags -1 fixed-upstream
Control: fixed -1 imagemagick/8:6.9.11.24+dfsg-1
Control: close -1

Handling of SOURCE_DATE_EPOCH has been implemented by upstream, and no more
reproducibility failures appear due to imagemagick timestamps in PDFs in the
reproducible build tests[1] (this ref is to unstable, but I've checked all
suites).

(I admit I mentioned PDF there, not postscript -- if I'm mistaken about this
bug being closable, please re-open and let me know)

[1] - 
https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_pdf_generated_by_imagemagick_issue.html



Bug#1059904: mariadb autopkgtest "upstream" is flaky, time sink

2024-01-05 Thread Otto Kekäläinen
New 1:10.116-2 uploaded, looking good so far at
https://tracker.debian.org/pkg/mariadb:

autopkgtest for mariadb/1:10.11.6-2: amd64: Pass, arm64: Pass, armel:
Pass, armhf: Pass, i386: Pass, ppc64el: Test in progress, s390x: Pass



Bug#1052838: [debian-mysql] Bug#1052838: mariadb: FTBFS: make[1]: *** [debian/rules:161: override_dh_auto_test] Error 1

2024-01-05 Thread Otto Kekäläinen
> > The ci.debian.net results for mariadb seem to be very flaky lately (on
> > amd64 they fail roughly 9/10) since version 1:10.11.6-1. Might be
> > related (although the failure is different). i386 and arm64 seem to be
> > exceptions.
>
> No - the current CI failures for MariaDB are unrelated and not due to
> this local port issue.
>
> (Current MariaDB failures are partly due to OpenSSL API text change in
> https://github.com/openssl/openssl/commit/81b741f68984 and partfly due
> to upstream bug https://jira.mariadb.org/browse/MDEV-32843 - both
> issues has known fixes, just a matter of dev time to commit and push)

New 1:10.116-2 uploaded with the two fixes above, looking good so far
at https://tracker.debian.org/pkg/mariadb:

autopkgtest for mariadb/1:10.11.6-2: amd64: Pass, arm64: Pass, armel:
Pass, armhf: Pass, i386: Pass, ppc64el: Test in progress, s390x: Pass

The 'reserved port' issue has not been fixed, or at least I am not
aware of any fix. However the issue was sporadic and I have not seen
it in late 2023 or 2024 on any buildd or ci.debian.org log.



Bug#1058671: [debian-mysql] Bug#1058671: mariadb-server: [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.

2024-01-05 Thread Otto Kekäläinen
> Thanks Daniel Lewart!
>
> I filed your submission at
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61
> for review/testing/feedback.

The Salsa-CI autopkgtests shows that this change affects the default
mariadbd server command-line parameters:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/61

Hence I did not merge this and it is not included in 1:10.11.6-2



Bug#1060121: mdadm: Value "basecamp:0" cannot be set as name. Reason: Not POSIX compatible. Value ignored.

2024-01-05 Thread Olaf Meeuwissen
Package: mdadm
Version: 4.2+20231121-1devuan1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Upgrading mdadm to the indicated version (or starting from
4.2+20230901-1).q

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I did not do anything other than upgrade.

   * What was the outcome of this action?

The mdadm periodic job to check for degraded arrays started issuing
the warning message in the subject.

Just running `mdadm --detail /dev/md0` produces the same message.

   * What outcome did you expect instead?

No warning message from mdadm command invocations.


The /etc/mdadm/mdadm.conf file was created by the installer and never
modified afterwards.  FYI, it includes the following comment

  # This configuration was auto-generated on Sat, 06 Aug 2022 12:36:25 +0900 by 
mkconf

which corresponds to the time I installed the system.  The installer
put mdadm 4.1-11 on the system, in case that matters.  I have been
tracking "testing" since.

On another system running "stable", I have mdadm 4.2-5 which does not
produce this warning.  That system has a similar mdadm.conf, only the
UUID and hostname differ.

The warning was introduced upstream on 2023-06-01 in e2eb503b which
would indicate it first entered Debian with version 4.2+20230901-1 of
the package.

The POSIX compatible character set does not include the `:` which is
why the warning triggers.  After some searching on how to get rid of
the warning, I am not sure if I should or even can as the hostname
seems to get included automatically.

If so, perhaps the POSIX check should skip the hostname and `:`?  Or
should a postinst somehow rename the (live) array (and rebuild the
initramfs) to adjust to the upstream change, seeing that I never made
any changes since I installed the system?

# Note, my array contains /.

BTW, my initrd is compressed by zstd.  I've checked that it has no
/conf/conf.d/md.  It does contain a copy of /etc/mdadm/mdadm.conf.
Also, I only have NVMe disks.

It looks like /usr/share/bug/mdadm/script needs to catch up with new
technology.

Hope this helps,

-- Package-specific info:
--- mdadm.conf
HOMEHOST 
MAILADDR root
ARRAY /dev/md/0  metadata=1.2 UUID=7de21d27:72412544:e86f4f1e:b4e1487d 
name=basecamp:0

--- /etc/default/mdadm
AUTOCHECK=true
AUTOSCAN=true
START_DAEMON=true
DAEMON_OPTIONS="--syslog"
VERBOSE=false

--- /proc/mdstat:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10] 
md0 : active raid1 nvme1n1p2[1] nvme0n1p2[0]
  249401664 blocks super 1.2 [2/2] [UU]
  bitmap: 1/2 pages [4KB], 65536KB chunk

unused devices: 

--- /proc/partitions:
major minor  #blocks  name

 2590  250059096 nvme0n1
 2591 524288 nvme0n1p1
 2592  249533767 nvme0n1p2
 2593  250059096 nvme1n1
 2594 524288 nvme1n1p1
 2595  249533767 nvme1n1p2
   90  249401664 md0
 2530   29294592 dm-0
 2531   97652736 dm-1

--- LVM physical volumes:
LVM does not seem to be used.
--- mount output
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=32594668k,nr_inodes=8148667,mode=755,inode64)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=6522772k,mode=755,inode64)
/dev/mapper/basecamp-root on / type ext4 (rw,relatime,errors=remount-ro)
tmpfs on /run/lock type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
pstore on /sys/fs/pstore type pstore (rw,relatime)
none on /sys/firmware/efi/efivars type efivarfs (rw,relatime)
tmpfs on /dev/shm type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=13045540k,inode64)
/dev/nvme1n1p1 on /boot/efi type vfat 
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
/dev/mapper/basecamp-home on /home type ext4 (rw,relatime)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
/etc/autofs/nas.conf on /srv/nas type autofs 
(rw,relatime,fd=6,pgrp=1593,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=12446)
/dev/mapper/basecamp-root on /var/lib/docker type ext4 
(rw,relatime,errors=remount-ro)
cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=6522768k,nr_inodes=1630692,mode=700,uid=1000,gid=1000,inode64)

--- initrd.img-6.5.0-5-amd64:

gzip: /boot/initrd.img-6.5.0-5-amd64: not in gzip format
cpio: premature end of archive

--- initrd's /conf/conf.d/md:
no conf/md file.

--- /proc/modules:
raid10 77824 0 - Live 0xc1582000
raid456 200704 0 - Live 0xc1541000
libcrc32c 12288 3 nf_conntrack,nf_tables,raid456, Live 0xc1537000
async_raid6_recov 20480 1 raid456, Live 

Bug#1060120: freebsd-glue: modify gcc version for build

2024-01-05 Thread Zhang Na
Source: freebsd-glue
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
 
  Please modify gcc version for build, thanks! 
  I think the gcc version should not be fixed, but should be greater
  than a certain version, unless the required features only exist on a
  specific version.

  example:

  - gcc-9,
  + gcc (>= 9),



-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 8ffd030b321a6c602cb91c60df5241b46ce7bc10 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Sat, 6 Jan 2024 03:44:19 +
Subject: [PATCH] modify gcc version for build

---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 1699ffe..87faabe 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Uploaders:
  Steven Chamberlain ,
 Build-Depends:
  debhelper (>= 8.0),
- gcc-9,
+ gcc (>= 9),
  kfreebsd-kernel-headers (>= 10.0~3) [kfreebsd-any],
  freebsd-mk,
  bmake,
diff --git a/debian/rules b/debian/rules
index b11b752..503ee26 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,7 @@ DEB_HOST_ARCH_OS?= $(shell dpkg-architecture 
-qDEB_HOST_ARCH_OS)
 # Determine host architecture compiler
 DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 ifeq ($(origin CC),default)
-CC := $(DEB_HOST_GNU_TYPE)-gcc-9
+CC := $(DEB_HOST_GNU_TYPE)-gcc
 endif
 
 # Determine build architecture compiler
-- 
2.43.0



Bug#1060084: [Pkg-puppet-devel] Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

2024-01-05 Thread Antoine Beaupré
On 2024-01-05 19:02:38, Will Partain wrote:
> Package: puppet-agent
> Version: 7.23.0-1
> Severity: important
>
> Dear Maintainer,
>
> (This is a more detailed version of 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054664 )

Is there any specific reason why you feel this should be adressed in a
different bug report than the above?

Otherwise those two reports should just be merged, but in any case,
thanks for the extra information! :)

a.
-- 
Being cynical is the only way to deal with modern civilization — you
can't just swallow it whole.
- Frank Zappa



Bug#1060119: python-vulndb: please patch-out dependency on python3-future

2024-01-05 Thread Alexandre Detiste
Source: python-vulndb
Severity: important


python3-future is RC buggy and won't be ported to Python3.12

please patch-out it's usage in setup.py & 
vulndb/tests/test_load_all_json.py

Greetings,

Alexandre

diff --git a/debian/control b/debian/control
index 30afc26..dfc385a 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: python
 Priority: optional
 Maintainer: Debian Security Tools 
 Uploaders: Gianfranco Costamagna 
-Build-Depends: debhelper-compat (= 12), dh-python, python3, python3-future, 
python3-setuptools, python3-setuptools-git
+Build-Depends: debhelper-compat (= 12), dh-python, python3, 
python3-setuptools, python3-setuptools-git
 Standards-Version: 4.6.2
 Homepage: https://github.com/vulndb/python-sdk/
 Vcs-Git: https://salsa.debian.org/pkg-security-team/python-vulndb.git
diff --git a/setup.py b/setup.py
index dfffe22..79b2914 100644
--- a/setup.py
+++ b/setup.py
@@ -27,7 +27,7 @@ setup(
 # With setuptools_git we make sure that the contents of vulndb/db/ , which
 # are non source code files, get copied too
 setup_requires=['setuptools_git >= 1.1',
-'future'],
+   ],
 zip_safe=False,
 
 # https://pypi.python.org/pypi?%3Aaction=list_classifiers
diff --git a/vulndb/tests/test_load_all_json.py 
b/vulndb/tests/test_load_all_json.py
index 3f57c5a..55f542a 100644
--- a/vulndb/tests/test_load_all_json.py
+++ b/vulndb/tests/test_load_all_json.py
@@ -1,4 +1,4 @@
-from past.builtins import basestring
+basestring = str
 import unittest
 import types
 import os



Bug#1060118: pyicloud: please remove obsolete dependency on python3-future

2024-01-05 Thread Alexandre Detiste
Source: pyicloud
Severity: important

The library python3-future is not compatible with Python3.12
and will soon be removed from the archive.

Please remove the one stale ref. in debian/control.

Greetings,


$ grep -e past -e future -r
->  debian/control: , python3-future
debian/changelog:  * debian/control: add dependency for python3-future
$

Alexandre

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

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



Bug#1060117: pass-otp: oathtool safety: avoid argument splitting, send secrets via stdin instead of arguments

2024-01-05 Thread Paul Wise
Package: pass-otp
Version: 1.2.0-9
Severity: normal
Tags: security patch
Forwarded: https://github.com/tadfisher/pass-otp/issues/167 
https://github.com/tadfisher/pass-otp/pulls/182
X-Debbugs-Cc: Debian Security Team 

Since upstream seems to be undermaintained, could you add the attached
patches to the Debian package for slightly more oathtool safety?

The first one uses bash arrays to separate command-line arguments,
instead of fragile shell string splitting.

The second one passes OTP secrets to oathtool on stdin instead
of command-line arguments, when it is new enough to support that.

These have been backported from my pull request linked above
and resolve the upstream bug report linked above. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 41c60cb5a128da006a8b474b58550a95aa4b33a8 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Fri, 12 May 2023 13:39:53 +0800
Subject: [PATCH 1/2] Use bash arrays to separate arguments to oathtool and
 otptool

Also use long version of oathtool -b/--base32 option.
---
 otp.bash | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/otp.bash b/otp.bash
index d4c7756..7702c07 100755
--- a/otp.bash
+++ b/otp.bash
@@ -334,18 +334,19 @@ cmd_otp_code() {
   local cmd
   case "$otp_type" in
 totp)
-  cmd="$OATH -b --totp"
-  [[ -n "$otp_algorithm" ]] && cmd+=$(echo "=${otp_algorithm}"|tr "[:upper:]" "[:lower:]")
-  [[ -n "$otp_period" ]] && cmd+=" --time-step-size=$otp_period"s
-  [[ -n "$otp_digits" ]] && cmd+=" --digits=$otp_digits"
-  cmd+=" $otp_secret"
+  cmd=("$OATH" --base32)
+  [[ -z "$otp_algorithm" ]] && cmd+=(--totp)
+  [[ -n "$otp_algorithm" ]] && cmd+=(--totp="$(echo "${otp_algorithm}"|tr "[:upper:]" "[:lower:]")")
+  [[ -n "$otp_period" ]] && cmd+=(--time-step-size="$otp_period"s)
+  [[ -n "$otp_digits" ]] && cmd+=(--digits="$otp_digits")
+  cmd+=("$otp_secret")
   ;;
 
 hotp)
   local counter=$((otp_counter+1))
-  cmd="$OATH -b --hotp --counter=$counter"
-  [[ -n "$otp_digits" ]] && cmd+=" --digits=$otp_digits"
-  cmd+=" $otp_secret"
+  cmd=("$OATH" --base32 --hotp --counter="$counter")
+  [[ -n "$otp_digits" ]] && cmd+=(--digits="$otp_digits")
+  cmd+=("$otp_secret")
   ;;
 
 *)
@@ -353,7 +354,7 @@ cmd_otp_code() {
   ;;
   esac
 
-  local out; out=$($cmd) || die "$path: failed to generate OTP code."
+  local out; out=$("${cmd[@]}") || die "$path: failed to generate OTP code."
 
   if [[ "$otp_type" == "hotp" ]]; then
 # Increment HOTP counter in-place
-- 
2.43.0

From cff06cc3abf97665e5997a41c0aab26808ad3ad8 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Fri, 12 May 2023 14:14:04 +0800
Subject: [PATCH 2/2] Send secrets to oathtool via stdin instead of
 command-line arguments

Check if the oathtool version supports this first.

Fixes: https://github.com/tadfisher/pass-otp/issues/167
---
 otp.bash | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/otp.bash b/otp.bash
index 7702c07..86344aa 100755
--- a/otp.bash
+++ b/otp.bash
@@ -331,6 +331,12 @@ cmd_otp_code() {
 fi
   done < <(echo "$contents")
 
+  # Check oathtool for stdin secrets feature
+  OATH_SAFE_VERSION=2.6.5
+  OATH_VERSION=$("$OATH" --version | head -n1 | tr ' ' '\n' | tail -n1)
+  printf -v OATH_VERSIONS '%s\n%s' "$OATH_SAFE_VERSION" "$OATH_VERSION"
+  [[ "$OATH_VERSIONS" = "$(sort -n <<< "$OATH_VERSIONS")" ]] && OATH_SAFE=1
+
   local cmd
   case "$otp_type" in
 totp)
@@ -339,14 +345,22 @@ cmd_otp_code() {
   [[ -n "$otp_algorithm" ]] && cmd+=(--totp="$(echo "${otp_algorithm}"|tr "[:upper:]" "[:lower:]")")
   [[ -n "$otp_period" ]] && cmd+=(--time-step-size="$otp_period"s)
   [[ -n "$otp_digits" ]] && cmd+=(--digits="$otp_digits")
-  cmd+=("$otp_secret")
+  if [[ -n "$OATH_SAFE" ]] ; then
+cmd+=(-) # secrets on stdin
+  else
+cmd+=("$otp_secret")
+  fi
   ;;
 
 hotp)
   local counter=$((otp_counter+1))
   cmd=("$OATH" --base32 --hotp --counter="$counter")
   [[ -n "$otp_digits" ]] && cmd+=(--digits="$otp_digits")
-  cmd+=("$otp_secret")
+  if [[ -n "$OATH_SAFE" ]] ; then
+cmd+=(-) # secrets on stdin
+  else
+cmd+=("$otp_secret")
+  fi
   ;;
 
 *)
@@ -354,7 +368,12 @@ cmd_otp_code() {
   ;;
   esac
 
-  local out; out=$("${cmd[@]}") || die "$path: failed to generate OTP code."
+  local out
+  if [[ -n "$OATH" && -n "$OATH_SAFE" ]] ; then
+out=$("${cmd[@]}" <<< "$otp_secret") || die "$path: failed to generate OTP code."
+  else
+out=$("${cmd[@]}") || die "$path: failed to generate OTP code."
+  fi
 
   if [[ "$otp_type" == "hotp" ]]; then
 # Increment HOTP counter in-place
-- 
2.43.0



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


Bug#859572: docbook-xsl: randomly adds ???TITLE??? to title

2024-01-05 Thread James Addison
Followup-For: Bug #859572
X-Debbugs-Cc: solo-debianb...@goeswhere.com, 
bugs-debian-20170...@james-ross.co.uk
Control: reassign -1 libxml2
Control: affects -1 libxslt1.1 xsltproc
Control: forwarded -1 https://gitlab.gnome.org/GNOME/libxslt/-/issues/37
Control: tags -1 fixed-upstream
Control: fixed -1 libxml2/2.9.12+dfsg-1
Control: close -1

This doesn't appear reproducible anymore, and after tracing back to figure
out when the fix for it landed, it was somewhere between bookworm and bullseye.

That helped to narrow down the behaviour to indeed something in xsltproc (as
James suspected) or libxslt, and then to between[1] versions 1.1.34 and 1.1.35
of the latter.

>From there, a commit to add test coverage[2] looked relevant, and sure enough,
the referenced commit[3] in libxml2 linked to a report[4] exhibiting this same
problem.

[1] - https://gitlab.gnome.org/GNOME/libxslt/-/compare/v1.1.34...v1.1.35

[2] - 
https://gitlab.gnome.org/GNOME/libxslt/-/commit/ea1c27fca299f4f29d8bd1e29ac2ad21aea81bcc

[3] - 
https://gitlab.gnome.org/520zym/libxml2/-/commit/9f42f6baaa91b6461ddfce345c174ea5f1ee73c3

[4] - https://gitlab.gnome.org/GNOME/libxslt/-/issues/37



Bug#829444: Use DEP14 branch layout by default

2024-01-05 Thread Otto Kekäläinen
Thanks Guido of for the inside about backwards compatibility issues. I did
not realize that git-buildpackage doesn't have way did is distinguish when
it is running on an existing repository and when on a 'fresh' repository.

Maybe we can engineer something to give it that capability automatically,
without any new 'layout' config flags?

Following DEP14 is just an aesthetic issue - I'd prefer to not have it if
the cost is that some existing repositories need a manual gbp.conf update
to continue to build down the road.


Bug#1060073: RM: fheroes2-pkg -- ROM; obsolete downloader in contrib, replaced by fheroes2 in main

2024-01-05 Thread Dmitry Smirnov
On Saturday, 6 January 2024 3:17:38 AM AEDT Alexandre Detiste wrote:
> Dear FTP Masters,
> 
> "fheroes2" has just been accepted.
> 
> Thanks !

Thanks!


> fheroes2-pkg was needed before the complete rewrite of the AI included in
> fheroes2
> 
> It can now be removed.

I originally make/introduced "fheroes2-pkg" and I also think that it can be
removed now. "fheroes2" is good enough, or better, replacement.

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

No political ritual can alter morality. No election can make an evil act
into a good act. If it is bad for you to do something, then it is bad for
those in "government" to do it.
 -- Larken Rose, The Most Dangerous Superstition


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


Bug#1060111: libmd0:i386: Fail to upgrade with an overwrite error

2024-01-05 Thread Guillem Jover
Control: reassign -1 debhelper
Control: forcemerge 1059395 -1

Hi!

On Sat, 2024-01-06 at 01:25:34 +0100, Christian Marillat wrote:
> Package: libmd0
> Version: 1.1.0-1
> Severity: normal

> Strange error. 'sudo apt-get -f install' is unable to solve this issue.
> 
> ,
> | Preparing to unpack .../libmd0_1.1.0-1+b2_i386.deb ...
> | Unpacking libmd0:i386 (1.1.0-1+b2) over (1.1.0-1) ...
> | dpkg: error processing archive 
> /var/cache/apt/archives/libmd0_1.1.0-1+b2_i386.deb (--unpack):
> |  trying to overwrite shared '/usr/share/doc/libmd0/changelog.Debian.gz', 
> which is different from other instances of package libmd0:i386
> | Errors were encountered while processing:
> |  /var/cache/apt/archives/libmd0_1.1.0-1+b2_i386.deb
> `
> 
> ,
> | $ dpkg -l|grep libmd0 
> | iU  libmd0:amd64 1.1.0-1+b2 amd64 message digest functions from BSD systems 
> - shared library
> | ii  libmd0:i386 1.1.0-1 i386 message digest functions from BSD systems - 
> shared library
> `

I've uploaded a new libmd package to resync the versions across arches
as a workaround, but this is a bug in debhelper. Reassigned and merged.

Thanks,
Guillem



Bug#1059657: circuits: autopkgtest failure with Python 3.12

2024-01-05 Thread Yogeswaran Umasankar

Hi,
Made a patch to fix the autopkgtest issue with Py 3.12. Attaching the
debdiff file.
Cheers!
diff -Nru circuits-3.2.2/debian/changelog circuits-3.2.2/debian/changelog
--- circuits-3.2.2/debian/changelog 2022-12-14 16:15:09.0 +
+++ circuits-3.2.2/debian/changelog 2024-01-06 01:27:18.0 +
@@ -1,3 +1,11 @@
+circuits (3.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer/Team upload. (Closes: #1059657)
+  * Included a patch for /circuits/core/utils.py to replace
+deprecated imp with importlib to fix autopkgtest in Py3.12.
+
+ -- Yogeswaran Umasankar   Sat, 06 Jan 2024 01:27:18 +
+
 circuits (3.2.2-1) unstable; urgency=medium
 
   * New upstream version 3.2.2 (Closes: #1024860)
diff -Nru circuits-3.2.2/debian/patches/06_replace-imp-with-importlib.patch 
circuits-3.2.2/debian/patches/06_replace-imp-with-importlib.patch
--- circuits-3.2.2/debian/patches/06_replace-imp-with-importlib.patch   
1970-01-01 00:00:00.0 +
+++ circuits-3.2.2/debian/patches/06_replace-imp-with-importlib.patch   
2024-01-06 01:21:32.0 +
@@ -0,0 +1,27 @@
+Description: Implemented importlib to fix autopkgtest failure with Python 3.12.
+Author: Yogeswaran Umasankar 
+Last-Update: 2024-01-06
+
+--- a/circuits/core/utils.py
 b/circuits/core/utils.py
+@@ -3,7 +3,7 @@
+ This module defines utilities used by circuits.
+ """
+ import sys
+-from imp import reload
++import importlib
+ 
+ 
+ def flatten(root, visited=None):
+@@ -53,9 +53,9 @@ def safeimport(name):
+ modules = sys.modules.copy()
+ try:
+ if name in sys.modules:
+-return reload(sys.modules[name])
++return importlib.reload(sys.modules[name])
+ else:
+-return __import__(name, globals(), locals(), [""])
++return importlib.import_module(name)
+ except Exception:
+ for name in sys.modules.copy():
+ if name not in modules:
diff -Nru circuits-3.2.2/debian/patches/series 
circuits-3.2.2/debian/patches/series
--- circuits-3.2.2/debian/patches/series2022-12-14 16:15:09.0 
+
+++ circuits-3.2.2/debian/patches/series2024-01-06 01:15:42.0 
+
@@ -2,3 +2,4 @@
 03_disable-address-check.patch
 04_remove-google-adsense.patch
 05_remove-privacy-breach-badges.patch
+06_replace-imp-with-importlib.patch


signature.asc
Description: PGP signature


Bug#1060115: vcswatch: look for changelog in debian/experimental branch

2024-01-05 Thread Martin
Package: qa.debian.org
Severity: wishlist
Tags: patch
X-Debbugs-Cc: m...@debian.org

Useful for packages only in debian/experimental.

diff --git a/data/vcswatch/vcswatch b/data/vcswatch/vcswatch
index bb20d156..2d8491cc 100755
--- a/data/vcswatch/vcswatch
+++ b/data/vcswatch/vcswatch
@@ -330,7 +330,7 @@ sub process_package ($) {
my $changelog;
if ($pkg->{vcs} eq 'Git') {
# look for changelog in some locations and branches
-   my @branch_list = qw(HEAD debian debian/master debian/sid 
debian/latest master);
+   my @branch_list = qw(HEAD debian debian/master debian/sid 
debian/latest debian/experimental master);
unshift @branch_list, $branch if ($branch); # $branch = 
hardcoded -b in url
my @clpaths = $pkg->{debian_dir} ? qw(debian/changelog 
changelog) :
qw(changelog debian/changelog);

Thanks for considering!



Bug#1059936: tons of them

2024-01-05 Thread Dan Jacobson
update-initramfs: Generating /boot/initrd.img-6.6.9-amd64
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead



Bug#1060116: wfuzz: please remove python3-future build-dependency

2024-01-05 Thread Alexandre Detiste
Source: wfuzz
Severity: important

This library is obsolete, RC buggy &
is being removed now from Debian.



Upstream has removed it's usage a long time ago.

https://github.com/xmendez/wfuzz/commit/f6ae03858228ea314003120d2eb41c70bf5bf98f

diff --git a/debian/control b/debian/control
index 396b9bc..68501d8 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,6 @@ Build-Depends: debhelper-compat (= 13),
python3,
python3-setuptools,
python3-chardet,
-   python3-future,
python3-pycurl,
python3-pyparsing,
python3-six,




Usage of python3-six should be removed too,
... another day.

Greetings



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

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



Bug#1060114: python-txaio: please remove extraneous dependency on python3-six

2024-01-05 Thread Alexandre Detiste
Source: python-txaio
Severity: normal
Forwarded: https://github.com/crossbario/txaio/pull/186

six is an obsolete Python2+3 compatibility layer
that was used by this project ... before.

Please apply the patch in attachmnent



Another up PR has been sent upstream to clean up requirements.txt


Greetings


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/control b/debian/control
index d86fdc1..dcbff35 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,6 @@ Build-Depends-Indep:
  python3-packaging,
  python3-pytest,
  python3-setuptools,
- python3-six,
  python3-sphinx-rtd-theme,
  python3-twisted,
  python3-zope.interface,
@@ -63,7 +62,6 @@ Depends:
  python3-incremental,
  python3-packaging,
  python3-setuptools,
- python3-six,
  python3-twisted,
  python3-zope.interface,
  ${misc:Depends},


Bug#1060060: libclipboard-perl: 'clipbrowse' from Debian package libclipboard-perl executing clipboard contents

2024-01-05 Thread Florian Schlichting
On Sat, Jan 06, 2024 at 12:18:20AM +0100, gregor herrmann wrote:
> Just a short note: I had a very quick look this afternoon, and when I
> added the quotes, clipbrowse simply didn't work anymore (it opened a
> new firefox window (not a tab as without the quotes) with an empty
> address bar and an obviously empty page)). I didn't have the time for
> further investigation but my impression was that simply adding back
> the quotes was not enough.

I must admit I did not test this with firefox (only google-chrome), but
I have done some testing now with "export BROWSER=firefox" set.

In my testing both work fine when the clipboard contains just a proper URL.

Newlines seem to be ignored / removed, and the second line concatenated
to the first. This might be useful in case the MUA broke a long URL.

Firefox will display a new empty window when the clipboard contains a
blank, while chrome changes that blank to %20 and displays the resulting
URL in a new tab. Chrome on the other hand will display a new empty
window when the clipboard contains a pipe.

IMHO both failure modes are acceptable, as in those cases the clipboard
doesn't just contain a URL but some other garbage as well. Apparently
the "I'm feeling lucky" part mentioned in the clipbrowse manpage is no
longer implemented in Firefox. And there's clipjoin, which will remove
some whitespace and pipe characters...

Florian



Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys

2024-01-05 Thread Paul Szabo
Dear Otto,

Thanks for your quick reply.

MDEV-33187 is "new".

MDEV-30259 is only year old, though the issue seems ten years old:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735014

Thanks, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics   University of SydneyAustralia



Bug#1060113: ITP: debgpt -- Chatting LLM with Debian-Specific Knowledge

2024-01-05 Thread M. Zhou
Package: wnpp
Severity: wishlist
Owner: Mo Zhou 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: debgpt
  Version : ? (CLI not yet stablized)
  Upstream Contact: me
* URL : https://salsa.debian.org/deeplearning-team/debgpt
* License : MIT/Expat
  Programming Lang: python
  Description : Chatting LLM with Debian-Specific Knowledge

This tool is still under development. I may not upload it very soon,
but an ITP number helps me silent lintian. I will not upload untill
I finish the CLI re-design, and finish the documentation parts.

There are some interesting findings while experimenting. For instance,
I find this rather convenient:

$ debgpt -HQ --cmd 'git diff --staged' -A 'Briefly describe the change as a git 
commit message.'

So I further wrapped the git commit command into

$ debgpt git commit

which automatically generates a description for staged changes and commit them 
for you.

Currently, some of the code of debgpt is written by debgpt, some of
the git commit messages are written by `debgpt git commit`. I will
try to explore more possibilities and add them in future releases.


The only missing dependency before uploaindg this is only src:python-openai,
which awaits in NEW as the time of writing.


The following is the full package description:

Large language models (LLMs) are newly emerged tools, which are capable of
handling tasks that traditional software could never achieve, such as writing
code based on the specification provided by the user. In this tool, we
attempt to experiment and explore the possibility of leveraging LLMs to aid
Debian development, in any extent.

Essentially, the idea of this tool is to gather some pieces of
Debian-specific knowledge, combine them together in a prompt, and then send
them all to the LLM. This tool provides convenient functionality for
automatically retrieving information from BTS, buildd, Debian Policy, system
manual pages, tldr manuals, Debian Developer References, etc. It also provides
convenient wrappers for external tools such as git, where debgpt can
automatically generate the git commit message and commit the changes for you.

This tool supports multiple frontends, including OpenAI and ZMQ.
The ZMQ frontend/backend are provided in this tool to make it self-contained.



Thank you for using reportbug



Bug#1060112: RFS: tractor/4.3.0-1 -- Setup an onion routing proxy

2024-01-05 Thread Danial Behzadi

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "tractor":

* Package name : tractor
  Version  : 4.3.0-1
  Upstream contact : Danial Behzadi 
* URL  : 
* License  : GPL-3+
* Vcs  : 
  Section  : net

The source builds the following binary packages:

 tractor - Setup an onion routing proxy

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


 

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


 dget -x 



Changes since the last upload:

tractor (4.3.0-1) unstable; urgency=medium
.
  * New upstream version 4.3.0

Regards,
--
Danial Behzadi




Bug#1060111: libmd0:i386: Fail to upgrade with an overwrite error

2024-01-05 Thread Christian Marillat
Package: libmd0
Version: 1.1.0-1
Severity: normal

Dear Maintainer,

Strange error. 'sudo apt-get -f install' is unable to solve this issue.

,
| Preparing to unpack .../libmd0_1.1.0-1+b2_i386.deb ...
| Unpacking libmd0:i386 (1.1.0-1+b2) over (1.1.0-1) ...
| dpkg: error processing archive 
/var/cache/apt/archives/libmd0_1.1.0-1+b2_i386.deb (--unpack):
|  trying to overwrite shared '/usr/share/doc/libmd0/changelog.Debian.gz', 
which is different from other instances of package libmd0:i386
| Errors were encountered while processing:
|  /var/cache/apt/archives/libmd0_1.1.0-1+b2_i386.deb
`

,
| $ dpkg -l|grep libmd0 
| iU  libmd0:amd64 1.1.0-1+b2 amd64 message digest functions from BSD systems - 
shared library
| ii  libmd0:i386 1.1.0-1 i386 message digest functions from BSD systems - 
shared library
`

Christian


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

Kernel: Linux 6.6.10-1-custom (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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)

Versions of packages libmd0:i386 depends on:
ii  libc6  2.37-13

libmd0:i386 recommends no packages.

libmd0:i386 suggests no packages.

-- no debconf information



Bug#1060110: FTBFS: buffer overflow in test

2024-01-05 Thread Heinrich Schuchardt
Package: socat
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

A buffer overrun in msg2() was observed when executing the HOSTNAMEOVFL
test:

https://launchpadlibrarian.net/704617807/buildlog_ubuntu-noble-ppc64el.socat_1.8.0.0-3_BUILDING.txt.gz

  * Fix memory overflow (LP: #2048408)
d/p/error.c-buffer-overflow-in-msg2.patch

Thanks for considering the patch.

Best regards

Heinrich
diff -Nru socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch 
socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch
--- socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch  
1970-01-01 01:00:00.0 +0100
+++ socat-1.8.0.0/debian/patches/error.c-buffer-overflow-in-msg2.patch  
2024-01-06 00:03:50.0 +0100
@@ -0,0 +1,35 @@
+From: Heinrich Schuchardt 
+Date: Fri, 5 Jan 2024 21:20:26 +
+Subject: [PATCH 1/1] error.c: buffer overflow in msg2()
+
+A buffer overrun in msg2() was observed when executing the HOSTNAMEOVFL
+test.
+
+If strncpy() truncates a string it does not append a terminating NUL
+character. Insert a NUL character after the destination area.
+This ensures that strchr() will stop at the end of the string.
+
+Fixes: 9be423ceea3c ("Improved handling of very long host or program names, or 
no strftime")
+Signed-off-by: Heinrich Schuchardt 
+
+Forwarded: yes
+Last-Update: 2024-01-05
+---
+ error.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/error.c b/error.c
+index d0a2a9e..3435046 100644
+--- a/error.c
 b/error.c
+@@ -404,6 +404,7 @@ void msg2(
+if (bufp < buff+MSGLEN)
+   *bufp++ = ' ';
+strncpy(bufp, text, MSGLEN-(bufp-buff));
++   bufp[MSGLEN-(bufp-buff)] = 0;
+bufp = strchr(bufp, '\0');
+strcpy(bufp, "\n");
+_msg(level, buff, syslp);
+-- 
+2.43.0
+
diff -Nru socat-1.8.0.0/debian/patches/series 
socat-1.8.0.0/debian/patches/series
--- socat-1.8.0.0/debian/patches/series 2023-12-21 13:58:31.0 +0100
+++ socat-1.8.0.0/debian/patches/series 2024-01-06 00:04:02.0 +0100
@@ -5,3 +5,4 @@
 07-compat-define-PATH_MAX.patch
 08-test.sh-fixes.patch
 09-xioinitialize.c.patch
+error.c-buffer-overflow-in-msg2.patch


Bug#1060109: apt - Please support new kernel release test

2024-01-05 Thread Bastian Blank
Package: apt
Version: 2.7.7
Severity: wishlist

As discussed around #1040901, we need an alternative way to correlate
between package and kernel.  In apt this directly affects how
APT::VersionedKernelPackages works, which cares about which package
could match the current running kernel.

How it should look like is still undecided.  The initial idea does:

  Kernel-Release: linux 6.6.1-

Aka $(uname -m), lower cased and only [a-z0-9-].  And a prefix of
$(uname -r).

But for some reason I'm now at:

  Kernel-Provides: linux (~~ 6.6.1-)

Same semantic, re-using dependencies parser with a not yet used
operation.

Bastian

-- 
Change is the essential process of all existence.
-- Spock, "Let That Be Your Last Battlefield", stardate 5730.2



Bug#1060108: xbase-clients: should not depend (not even recommend) xinit

2024-01-05 Thread Vincent Lefevre
Package: xbase-clients
Version: 1:7.7+23
Severity: normal

The xbase-clients package is there to provide only X clients, not
an X server.

This package currently depends on xinit, which has the effect to
install an X server. The goal of xinit is to start an X server;
this utility is not an X client. So xbase-clients should not depend
(not even recommend) xinit.

Note: a typical use of X clients without a local X server is via ssh.

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

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

Versions of packages xbase-clients depends on:
ii  x11-apps   7.7+11
ii  x11-session-utils  7.7+6
ii  x11-utils  7.7+6
ii  x11-xkb-utils  7.7+8
ii  x11-xserver-utils  7.7+10
ii  xauth  1:1.1.2-1
ii  xinit  1.4.2-1

xbase-clients recommends no packages.

Versions of packages xbase-clients suggests:
pn  x11-xfs-utils  

-- no debconf information

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



Bug#1057717: cmake ftbfs on ppc64el (and ppc64)

2024-01-05 Thread Timo Röhling

Control: severity -1 normal
Control: affects -1 + src:cmake
Control: reassign -1 libuv1 1.46.0-2


The ppc64 related segfaults seems to have suddenly vanished again 
with libuv1 1.46.0-3.


After some discussion and bug hunting with upstream [1], which could 
not reproduce the bug on their end, I think this was either caused 
by a tainted ppc64el build of libuv1 in Debian, or this points to a 
very well hidden bug in libuv1 that needs very specific conditions 
to trigger.


In either case, I find it justified to lower the severity and 
reassign the bug to libuv1. I suggest we keep this bug open for now, 
in case the problem resurfaces on our buildds.



Cheers
Timo

[1] https://gitlab.kitware.com/cmake/cmake/-/issues/25500


On Thu, 7 Dec 2023 15:02:33 +0100 Matthias Klose  
wrote:

Package: src:cmake
Version: 3.28.0-1
Severity: serious
Tags: sid trixie

cmake ftbfs on ppc64el (and ppc64):

[...]
99% tests passed, 5 tests failed out of 697

Label Time Summary:
CMake  = 1205.59 sec*proc (290 tests)
CUDA   =  90.91 sec*proc (11 tests)
HIP=  17.89 sec*proc (6 tests)
ISPC   =  60.92 sec*proc (6 tests)
Label1 =   0.06 sec*proc (1 test)
Label2 =   0.06 sec*proc (1 test)
Qt5= 678.18 sec*proc (49 tests)
command=   6.93 sec*proc (23 tests)
policy =  81.42 sec*proc (42 tests)
run= 1198.66 sec*proc (267 tests)

Total Test time (real) = 436.62 sec

The following tests FAILED:
108 - LibName (SEGFAULT)
241 - CMakeCommands.add_link_options (SEGFAULT)
264 - CTestTestDepends (Failed)
393 - RunCMake.FPHSA (SEGFAULT)
467 - RunCMake.cmake_path (SEGFAULT)
Errors while running CTest
make[2]: *** [Makefile:94: test] Error 8
make[2]: Leaving directory '/<>/Build'




--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature


Bug#1060060: libclipboard-perl: 'clipbrowse' from Debian package libclipboard-perl executing clipboard contents

2024-01-05 Thread gregor herrmann
On Sat, 06 Jan 2024 00:00:19 +0100, Florian Schlichting wrote:

> Hi Sebastiaan,
> thank you for bringing this to our attention.

+ 1

> > This results in the browser opening the requested URL in the foreground, 
> > while
> > simultaneous running the specified command in the background.
> indeed :-(

Same here.

> I'm going to upload a new version which adds the missing quotes in that
> line 

Thanks for handling this issue!

Just a short note: I had a very quick look this afternoon, and when I
added the quotes, clipbrowse simply didn't work anymore (it opened a
new firefox window (not a tab as without the quotes) with an empty
address bar and an obviously empty page)). I didn't have the time for
further investigation but my impression was that simply adding back
the quotes was not enough.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature


Bug#1060060: libclipboard-perl: 'clipbrowse' from Debian package libclipboard-perl executing clipboard contents

2024-01-05 Thread Florian Schlichting
Hi Sebastiaan,

thank you for bringing this to our attention.

> Example: Copy the following 2 lines present into the clipboard, then run the
> 'clipbrowse' command:
> 
> https://www.example.com
> echo echo p0wned | sh
> 
> This results in the browser opening the requested URL in the foreground, while
> simultaneous running the specified command in the background.

indeed :-(

> I believe the cause of this is by not enclosing a variable with doublequotes:
> 
> The original sourcecode (
> https://github.com/shlomif/Clipboard/blob/master/scripts/clipbrowse ) has
> doublequotes around the variable %s
>   my $browser = $ENV{BROWSER} || 'chromium-browser "%s"';
> And performs some string sanitizing in other lines.
> 
> The Debian version does not have these quotes, making the string sanitizing
> ineffective:
> '/usr/bin/clipbrowse' contains the following line:
>   my $browser = $ENV{BROWSER} || 'sensible-browser %s';
> 
> I have not checked if other packages that have been changed to use sensible-
> browser have the same issue.

I'm going to upload a new version which adds the missing quotes in that
line as well for the case where the user specifies BROWSER without
including a %s. I've opened a PR upstream to fix that second case.

I'm unsure if that's sufficient, or if we should work to get the fix
into (old-)stable versions of Debian as well. What do other Perl team
members think?

Florian



Bug#1060107: urweb: FTBFS: http.c:119:32: error: pointer ‘buf’ may be used after ‘realloc’

2024-01-05 Thread Sebastian Ramacher
Source: urweb
Version: 20170720+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=urweb=ppc64el=20170720%2Bdfsg-2%2Bb1=1704495164=0

/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../../include/urweb  -I./../../include/urweb -I/usr/include -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wimplicit -Wall -Werror -Wno-deprecated-declarations  -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fno-code-hoisting -c -o static.lo static.c
http.c: In function ‘worker’:
http.c:119:32: error: pointer ‘buf’ may be used after ‘realloc’ 
[-Werror=use-after-free]
  119 | back = new_buf + (back - buf);
  |  ~~^~
http.c:111:19: note: call to ‘realloc’ here
  111 | new_buf = realloc(buf, new_buf_size);
  |   ^~
http.c:184:32: error: pointer ‘buf’ may be used after ‘realloc’ 
[-Werror=use-after-free]
  184 |   s = new_buf + (s - buf);
  | ~~~^~
http.c:173:25: note: call to ‘realloc’ here
  173 |   new_buf = realloc(buf, new_buf_size);
  | ^~
http.c:183:38: error: pointer ‘buf’ may be used after ‘realloc’ 
[-Werror=use-after-free]
  183 |   body = new_buf + (body - buf);
  |~~^~
http.c:173:25: note: call to ‘realloc’ here
  173 |   new_buf = realloc(buf, new_buf_size);
  | ^~
http.c:182:38: error: pointer ‘buf’ may be used after ‘realloc’ 
[-Werror=use-after-free]
  182 |   back = new_buf + (back - buf);
  |~~^~
http.c:173:25: note: call to ‘realloc’ here
  173 |   new_buf = realloc(buf, new_buf_size);
  | ^~

Cheers
-- 
Sebastian Ramacher



Bug#1060106: astc-encoder: FTBFS on i386: failed tests

2024-01-05 Thread Sebastian Ramacher
Source: astc-encoder
Version: 4.5.0+ds-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=astc-encoder=i386=4.5.0%2Bds-2%2Bb1=1704479091=0

./Source/UnitTest/test_simd.cpp:976: Failure
Value of: any(r2 == vfloat4(l0 + l1 + l2 + l3))
  Actual: true
Expected: false

[  FAILED  ] vfloat4.dot (0 ms)
[ RUN  ] vfloat4.dot_s
./Source/UnitTest/test_simd.cpp:1001: Failure
Expected: (r2) != (l0 + l1 + l2 + l3), actual: 1.24359033e+11 vs 1.24359033e+11

[  FAILED  ] vfloat4.dot_s (0 ms)

Cheers
-- 
Sebastian Ramacher



Bug#1060105: pcl: FTBFS on i386: failed tests

2024-01-05 Thread Sebastian Ramacher
Source: pcl
Version: 1.13.0+dfsg-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=pcl=i386=1.13.0%2Bdfsg-3%2Bb1=1704477640=0


Total Test time (real) = 255.84 sec

The following tests FAILED:
 18 - common_eigen (Failed)
 98 - a_octree_test (Failed)
Errors while running CTest
Output from these tests are in: 
/<>/obj-i686-linux-gnu/test/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.

Cheers
-- 
Sebastian Ramacher



Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)

2024-01-05 Thread Sebastian Ramacher
Source: dcmtk
Version: 3.6.7-9
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=dcmtk=armel=3.6.7-9%2Bb1=1704494616=0

[ 90%] Building CXX object dcmpstat/libsrc/CMakeFiles/dcmpstat.dir/dcmpstat.cc.o
cd /<>/obj-arm-linux-gnueabi/dcmpstat/libsrc && /usr/bin/c++ 
-DDCMTK_BUILD_IN_PROGRESS -DDCMTK_HAVE_POLL=1 -DUSE_NULL_SAFE_OFSTRING 
-D_REENTRANT -Ddcmpstat_EXPORTS 
-I/<>/obj-arm-linux-gnueabi/config/include 
-I/<>/ofstd/include -I/<>/oflog/include 
-I/<>/dcmdata/include -I/<>/dcmimgle/include 
-I/<>/dcmimage/include -I/<>/dcmjpeg/include 
-I/<>/dcmjpls/include -I/<>/dcmtls/include 
-I/<>/dcmnet/include -I/<>/dcmsr/include 
-I/<>/dcmsign/include -I/<>/dcmwlm/include 
-I/<>/dcmqrdb/include -I/<>/dcmpstat/include 
-I/<>/dcmrt/include -I/<>/dcmiod/include 
-I/<>/dcmfg/include -I/<>/dcmseg/include 
-I/<>/dcmtract/include -I/<>/dcmpmap/include 
-I/<>/dcmect/include -I/usr/include/libxml2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-DENABLE_DCMJPLS_INTERLEAVE_NONE -Wdate-time -D_FORTIFY_SOURCE=2 
-fvisibility=hidden -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE=500 -D_BSD_SOURCE 
-D_DEFAULT_SOURCE -D_BSD_COMPAT -D_OSF_SOURCE -D_POSIX_C_SOURCE=199506L 
-std=gnu++17 -fPIC -Wall -MD -MT 
dcmpstat/libsrc/CMakeFiles/dcmpstat.dir/dcmpstat.cc.o -MF 
CMakeFiles/dcmpstat.dir/dcmpstat.cc.o.d -o 
CMakeFiles/dcmpstat.dir/dcmpstat.cc.o -c 
/<>/dcmpstat/libsrc/dcmpstat.cc
/tmp/ccm0eYhx.s: Assembler messages:
/tmp/ccm0eYhx.s:537: Error: bad immediate value for offset (4100)
make[4]: *** [dcmrt/tests/CMakeFiles/drttest.dir/build.make:79: 
dcmrt/tests/CMakeFiles/drttest.dir/drttest.cc.o] Error 1
make[4]: Leaving directory '/<>/obj-arm-linux-gnueabi'
make[3]: *** [CMakeFiles/Makefile2:5064: 
dcmrt/tests/CMakeFiles/drttest.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs
[ 90%] Building CXX object dcmpstat/libsrc/CMakeFiles/dcmpstat.dir/dviface.cc.o

Cheers
-- 
Sebastian Ramacher



Bug#1060103: transition: imagemagick7

2024-01-05 Thread Bastien Roucariès
Package: release.debian.org
Severity: important
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: ftpmas...@debian.org

Imagemagick will need a new major bump

I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).

Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.
- upload to experimental a version with perl and without legacy name
- migrate perl and versioned package
- add to experimental libmakickgwand-dev libmagick++-dev  libmagickcore-dev
- migrate package that depends on libmakickgwand-dev libmagick++-dev
libmagickcore-dev (every thing that build against imagemagick) to imagemagick7
- add to experimental imagemagick package
- migrate imagemagick package to unstable

What do you think of this plan ? From a security point of view it is better to
go to imagemagick7 (so important severity)

I expect breakage only on the last step. See
https://imagemagick.org/script/porting.php

ftpmaster it need more work because it will need three manual step.

Bastien

*  perlmagick, libmagickcore-dev, libmakickgwand-dev libmagick++-dev,
imagemagick, libimage-magick-perl libimage-magick-q16-perl libimage-
magick-q16hdri-perl


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


Bug#1060102: boost1.74: do not release with trixie

2024-01-05 Thread Sebastian Ramacher
Source: boost1.74
Version: 1.74.0+ds1-23
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

With boost 1.83 now as default, let's release trixie without boost 1.74.

The current list of blockers is:

Checking reverse dependencies...
# Broken Depends:
cctbx: libcctbx0 [amd64 arm64 ppc64el s390x]
   python3-cctbx [amd64 arm64 ppc64el s390x]
ceph: ceph-common
  ceph-mgr
  ceph-mon
  ceph-osd
  librados-dev
  librados2
  librgw2
  radosgw
fenics-dolfinx: libdolfinx-complex0.7 [amd64 arm64 mips64el ppc64el s390x]
libdolfinx-real0.7 [amd64 arm64 mips64el ppc64el s390x]
freecad: libfreecad-python3-0.20
gnuradio: gnuradio
  gnuradio-dev
  libgnuradio-audio3.10.8
  libgnuradio-blocks3.10.8
  libgnuradio-iio3.10.8
  libgnuradio-network3.10.8
  libgnuradio-runtime3.10.8
  libgnuradio-uhd3.10.8
gr-gsm: gr-gsm [armhf]
graph-tool: python3-graph-tool [amd64 arm64 ppc64el s390x]
gyoto: gyoto-bin
   libgyoto8
i2pd: i2pd
lomiri-thumbnailer: liblomiri-thumbnailer-qt1.0 [mips64el]
lomiri-thumbnailer-service
macaulay2: macaulay2
pcl: libpcl-io1.13 [i386]
 libpcl-outofcore1.13 [i386]
 libpcl-recognition1.13 [i386]
 libpcl-visualization1.13 [i386]
 pcl-tools [i386]
pycuda/contrib: python3-pycuda [amd64 arm64 ppc64el]
pytango: python3-tango [amd64 arm64 armel armhf i386 mips64el ppc64el]

# Broken Build-Depends:
brewtarget: libboost1.74-dev
dmrgpp: libboost1.74-dev

Cheers
-- 
Sebastian Ramacher



Bug#989998: Fixed upstream: need help ?

2024-01-05 Thread Bastien Roucariès
Hi,

I have just fix this CVE for buster and I want to know if you need help to 
release a fix for unstable ?

The LTS fix are here https://salsa.debian.org/lts-team/packages/keystone/

Thanks

Bastien

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


Bug#1060093: lirc: FTBFS on hurd-i386

2024-01-05 Thread Samuel Thibault
Svante Signell, le ven. 05 janv. 2024 23:20:54 +0100, a ecrit:
> On Fri, 2024-01-05 at 21:58 +0100, Samuel Thibault wrote:
> > Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit:
> > > --- a/debian/rules  2023-12-16 18:35:11.0 +0100
> > > +++ b/debian/rules  2024-01-02 12:49:12.0 +0100
> > > @@ -4,7 +4,14 @@
> > >  include /usr/share/dpkg/pkg-info.mk
> > >  
> > >  export DEB_BUILD_MAINT_OPTIONS  = hardening=+all
> > > -export
> > > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > > B_HOST_MULTIARCH)
> > > +
> > > +ifeq ($(DEB_HOST_ARCH_OS), hurd)
> > > +#FIXME: Replace gnu0 with either gnu or hurd in python3.11!
> > > +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386-
> > > gnu.cpython-311.pyc
> > > +   export
> > > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARC
> > > H)
> > > +else
> > > +   export
> > > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > > B_HOST_MULTIARCH)
> > 
> > Probably better just ask python itself:
> > 
> > export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c
> > 'import os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH)
> 
> Why does the os.sys.platform report gnu0? It should be gnu or
> preferrably hurd??

Well, here this question does not matter: it reports what it should
report, i.e. what is used to name the sysconfig data file.

If the string should be changed, that should be discussed with upstream
python, not this package in particular (and this package should just
adapt to whatever os.sys.platform comes to expose).

> > > @@ -33,7 +40,7 @@
> > >  else
> > > dh_auto_configure -- \
> > >     SH_PATH=/bin/sh \
> > > -   MODINFO=/sbin/modinfo \
> > > +   MODINFO= \
> > >     --disable-uinput --disable-devinput
> > 
> > We do want modinfo on the linux platform, please make this os-
> > specific.
> 
> Note the else:
> ifeq ($(DEB_HOST_ARCH_OS), linux)
> dh_auto_configure -- \
> SH_PATH=/bin/sh \
> MODINFO=/sbin/modinfo \
> --enable-uinput --enable-devinput
> else
> dh_auto_configure -- \
> SH_PATH=/bin/sh \
> MODINFO= \
> --disable-uinput --disable-devinput
> endif

Ah, ok, I didn't have the broader context in the patch.

Samuel



Bug#967565: [Pkg-electronics-devel] Bug#967565: lepton-eda: depends on deprecated GTK 2

2024-01-05 Thread Bdale Garbee
Bastian Germann  writes:

> With both autotools and meson buildsystems, the gtksheet-4.0/gtksheet
> include path is intentional.

Then why does

 pkg-config --cflags "gtksheet-4.0 >= 4.0.0"
 
not include -I/usr/include/gtksheet-4.0 as one of the returned elements?

It appears to me that this is what the lepton-eda configure expects to
correctly return a path element for the includes.  Calling pkg-config
with --libs correctly adds -lgtksheet-4.0, so maybe there's something
not-quite-right with the info the gtksheet packaging delivers for use by
pkg-config --cflags?

Bdale


signature.asc
Description: PGP signature


Bug#1059339: nv-codec-headers: Version mismatch with nvidia-driver package

2024-01-05 Thread Sebastian Ramacher
Control: reassign -1 src:nvidia-graphics-drivers 525.147.05-4
Control: retitle -1 nvidia-graphics-driver: please upgrade to 535.x in unstable

On 2023-12-22 20:59:22 +0100, Tim H. wrote:
> Source: nv-codec-headers
> Version: 12.1.14.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> After I updated FFmpeg to version 7:6.1-5 hardware accelerated encoding
> via h264_nvenc stopped working.
> 
> FFmpeg reports:
> Driver does not support the required nvenc API version. Required: 12.1
> Found: 12.0
> 
> [1] states that the minimum required nvidia driver version to support
> nvenc 12.1 is 530.41.03 or higher. Yet the most recent version
> available in trixie is currently 525.147.05-1.

Taking the nvidia driver from experimental would also work. Andreas,
could you upload the driver from experimental to unstable?

Cheers

> 
> I managed to compile FFmpeg against an older version (12.0.16.1) of the
> headers which fixed the bug for me. Please note that my graphics card
> is quite old (NVIDIA Corporation GM206 [GeForce GTX 960]), so I'm not
> sure if this bug affects people with more up to date cards.
> 
> ~ Tim
> 
> [1]: 
> https://docs.nvidia.com/video-technologies/video-codec-sdk/12.1/read-me/index.html
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'oldoldstable'), (500,
> 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64) Foreign Architectures: i386
> 
> Kernel: Linux 6.1.68-1 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE
> not set Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> 

-- 
Sebastian Ramacher



Bug#1060093: lirc: FTBFS on hurd-i386

2024-01-05 Thread Svante Signell
On Fri, 2024-01-05 at 21:58 +0100, Samuel Thibault wrote:
> Hello,
> 
> Thanks for your patches.
> 
> Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit:
> > --- a/debian/rules  2023-12-16 18:35:11.0 +0100
> > +++ b/debian/rules  2024-01-02 12:49:12.0 +0100
> > @@ -4,7 +4,14 @@
> >  include /usr/share/dpkg/pkg-info.mk
> >  
> >  export DEB_BUILD_MAINT_OPTIONS  = hardening=+all
> > -export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > B_HOST_MULTIARCH)
> > +
> > +ifeq ($(DEB_HOST_ARCH_OS), hurd)
> > +#FIXME: Replace gnu0 with either gnu or hurd in python3.11!
> > +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386-
> > gnu.cpython-311.pyc
> > +   export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARC
> > H)
> > +else
> > +   export
> > _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DE
> > B_HOST_MULTIARCH)
> 
> Probably better just ask python itself:
> 
> export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c
> 'import os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH)

Why does the os.sys.platform report gnu0? It should be gnu or
preferrably hurd??

> > @@ -33,7 +40,7 @@
> >  else
> > dh_auto_configure -- \
> >     SH_PATH=/bin/sh \
> > -   MODINFO=/sbin/modinfo \
> > +   MODINFO= \
> >     --disable-uinput --disable-devinput
> 
> We do want modinfo on the linux platform, please make this os-
> specific.

Note the else:
ifeq ($(DEB_HOST_ARCH_OS), linux)
dh_auto_configure -- \
SH_PATH=/bin/sh \
MODINFO=/sbin/modinfo \
--enable-uinput --enable-devinput
else
dh_auto_configure -- \
SH_PATH=/bin/sh \
MODINFO= \
--disable-uinput --disable-devinput
endif



Bug#1059216: Problem configuring polkitd after upgrade

2024-01-05 Thread Adamo Reggiani

Hi Michael,
please see the output here.

# SYSTEMD_LOG_LEVEL=debug systemd-sysusers polkitd.conf
SELinux enabled state cached to: disabled
Creating group 'polkitd' with GID 997.
Creating user 'polkitd' (polkit) with UID 997 and GID 997.
Failed to add existing group "tty" to temporary gshadow file: Invalid 
argument


Regards,
Adamo

On 21/12/23 18:25, Michael Biebl wrote:

SYSTEMD_LOG_LEVEL=debug systemd-sysusers polkitd.conf

Bug#1060101: boost1.81: do not release with trixie

2024-01-05 Thread Sebastian Ramacher
Source: boost1.81
Version: 1.81.0-7
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

With boost 1.83 now as the default, let's try get boost 1.81 out of
trixie.

Current blockers are:

Checking reverse dependencies...
# Broken Depends:
r-cran-bh: r-cran-bh

# Broken Build-Depends:
filezilla: libboost-regex1.81-dev
pbcopper: libboost1.81-dev
r-cran-openmx: libboost-system1.81-dev

Cheers
-- 
Sebastian Ramacher



Bug#1056576: u-boot: Consider building apple/asahi variant

2024-01-05 Thread Vagrant Cascadian
On 2024-01-05, Vagrant Cascadian wrote:
> On 2023-11-23, Andreas Henriksson wrote:
>> On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote:
>>> On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote:
>>> > On 2023-11-23, Andreas Henriksson wrote:
> ...
>>> > > 3/ do we include patches?
>>> > > 3.1/ No patches. If this is the desired path I can volunteer
>>> > >  to test that it boots on my M1 machine. Other machines
>>> > >  should probably be considered unsupported for now,
>>> > >  even though they might have limited usefulness.
>>> > > 3.2/ Minimal set of patches. We identify what we consider
>>> > >  crutial only patches and recruit volunteers to test.
>>> > >  M2 keyboard? USB? etc...
>>> > > 3.3/ All asahi patches. We consider it simpler to just sync all patches
>>> > >  with the asahi fork (even though some are even unused, like the
>>> > >  devicetree patches). We trust the Asahi Linux project in their
>>> > >  quest to upstream all their work and that they will rebase on newer
>>> > >  releases and make our job easy.
>>> > 
>>> > I am inclined towards starting with no patches or a minimal set of
>>> > patches. The asashi folks do seem to generally do a good job of
>>> > upstreaming, so support should improve over time.
>>
>> I'm not against going this route, my only concern is using the asahi
>> name while shipping an "inferior" variant (no patches). The Asahi Linux
>> people have been very good at being end-user focused, fixing all kind of
>> bugs and really go above and beyond to not compromise on end user
>> experience. Not sure they'd appreciate us shipping it under their name
>> while exposing "already fixed" bugs but what do I know.
>> We can always add patches later I guess. The Trixie freeze is not
>> happening soon and we're not providing any installer yet, so it should
>> just be a few #debian-bananas people trying this out for a while still
>> I guess.
>
> This seems like the main blocker at this point; I am hoping to upload at
> least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once
> it releases), and it would be nice to include a u-boot variant
> supporting these boards, but I am nervous about shipping patches.  As
> you pointed out an unpatched version with asashi in the name might not
> be appreciated... but ... uh, er. Hrm. I would really like to get this
> in!

I guess we could include a note in the description? Something like:

  This package does not include all patches shipped by the asahi project,
  only patches that have been merged in mainline u-boot.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

2024-01-05 Thread Georg Faerber
On 24-01-05 21:15:52, Georg Faerber wrote:
> On bullseye, I had to install the 'cron' package on the machine
> running the agent. I'm not sure if it works with other cron
> implementations as well.

The above comment was not about bullseye, but bookworm.



Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

2024-01-05 Thread Georg Faerber
Hi Will,

On 24-01-05 19:02:38, Will Partain wrote:
> Invoked puppet-agent against a "legacy" server:
> 
>/usr/bin/puppet agent --server parple-pup1.parple.org --test 
> --certname=parple-pup2.parple.org --environment=prodnew --diff_args=-U1 
> --noop --debug
> 
> It received "work" from the server, and started doing things, until it
> needed 'Cron'... (the debugging log just before that...):
> 
>   Debug: /Package[apticron]: Provider apt does not support features 
> install_only; not managing attribute install_only
>   Debug: /Package[logrotate]: Provider apt does not support features 
> targetable; not managing attribute command
>   Debug: /Package[logrotate]: Provider apt does not support features 
> install_only; not managing attribute install_only
>   Error: Failed to apply catalog: Resource type 'Cron' was not found

On bullseye, I had to install the 'cron' package on the machine running
the agent. I'm not sure if it works with other cron implementations as
well.

Maybe this helps,
all the best,
Georg



Bug#1060099: telegram-desktop: FTBFS on mips64el: ./obj-mips64el-linux-gnuabi64/Telegram/./obj-mips64el-linux-gnuabi64/Telegram/gen/scheme.cpp:16435:(.text+0x1600a0): relocation truncated to fit: R_MI

2024-01-05 Thread Sebastian Ramacher
Source: telegram-desktop
Version: 4.13.1+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=telegram-desktop=mips64el=4.13.1%2Bds-1=1703877441=0

100%] Linking CXX executable ../telegram-desktop
cd /<>/obj-mips64el-linux-gnuabi64/Telegram && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/Telegram.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security 
-ftemplate-backtrace-limit=0 -Wdate-time -D_FORTIFY_SOURCE=2 
-Werror=invalid-pch -Wl,-z,relro -Wl,-z,now -Wno-alloc-size-larger-than 
-Wno-stringop-overflow -Wno-odr -Wno-inline -pthread -Wl,--as-needed 
CMakeFiles/Telegram.dir/Telegram_autogen/mocs_compilation.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_attached_stickers.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_authorizations.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_blocked_peers.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_bot.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_chat_filters.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_chat_invite.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_chat_participants.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_cloud_password.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_common.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_confirm_phone.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_editing.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_global_privacy.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_hash.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_invite_links.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_media.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_messages_search.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_messages_search_merged.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_peer_colors.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_peer_photo.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_polls.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_premium.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_premium_option.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_report.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_ringtones.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_self_destruct.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_send_progress.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_sending.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_sensitive_content.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_single_message_search.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_statistics.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_text_entities.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_toggling_media.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_transcribes.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_unread_things.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_updates.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_user_names.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_user_privacy.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_views.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_websites.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/api/api_who_reacted.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/filters/edit_filter_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/filters/edit_filter_chats_list.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/filters/edit_filter_links.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/add_bot_to_chat_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/add_participants_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/choose_peer_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_contact_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_forum_topic_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_linked_chat_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_members_visible.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_participant_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_participants_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_color_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_info_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_invite_link.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_invite_links.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_permissions_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_reactions.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_requests_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_type_box.cpp.o 
CMakeFiles/Telegram.dir/SourceFiles/boxes/peers/edit_peer_usernames_list.cpp.o 

Bug#1060100: r-cran-rstanarm: FTBFS: Error: segfault from C stack overflow

2024-01-05 Thread Sebastian Ramacher
Source: r-cran-rstanarm
Version: 2.26.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=r-cran-rstanarm=mips64el=2.26.1-2=1704150178=0

"/usr/lib/R/bin/Rscript" -e "source(file.path('..', 'tools', 'make_cc.R')); 
make_cc(commandArgs(TRUE))" stan_files/jm.stan
code for methods in class "Rcpp_model_base" was not checked for suspicious 
field assignments (recommended package 'codetools' not available?)
code for methods in class "Rcpp_model_base" was not checked for suspicious 
field assignments (recommended package 'codetools' not available?)
code for methods in class "Rcpp_stan_fit" was not checked for suspicious field 
assignments (recommended package 'codetools' not available?)
code for methods in class "Rcpp_stan_fit" was not checked for suspicious field 
assignments (recommended package 'codetools' not available?)
Error: segfault from C stack overflow
Execution halted
make[1]: *** [Makevars:24: stan_files/jm.cc] Error 1

Cheers
-- 
Sebastian Ramacher



Bug#1060005: cifs-utils: Copy file with cp, hangs with a kernel NULL pointer dereference.

2024-01-05 Thread Salvatore Bonaccorso
Hi,

On Fri, Jan 05, 2024 at 01:52:30PM +0300, Michael Tokarev wrote:
> Control: reassign -1 src:linux 6.1.69+1
> 
> 04.01.2024 18:52, Eduardo Nunes:
> > Package: cifs-utils
> > Version: 2:7.0-2
> > Severity: normal
> > X-Debbugs-Cc: eduardo.david.nu...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > 
> > When copying a file between directories on same mount, the operation hangs 
> > with:
> > BUG: kernel NULL pointer dereference, address: 
> > in RIP: 0010:cifs_flush_folio+0x3f/0x100 [cifs]
> > 
> > Debian12 6.1.0-17-amd run as guest in VirtualBox 7.0.12 and the mounted 
> > share is on the host (Windows 10).
> > Works as expected in the same configuration but with Debian11 
> > 5.10.0-27-amd64 as guest.
> 
> It looks like we've regression in 6.1.69 (6.1.0-17) kernel update.
> 
> There's at least one more report like this:
> https://forum.manjaro.org/t/manjaro-vmware-guest-copying-in-thunar-to-cifs-mounted-windows-locations-fails/153942/2
> which also mentions 6.1.69 (and an update to 6.6+ fixed the issue).
> 
> 6.1.69 had at least 3 cifs-related changes, and two of them look
> very interesting in this context:
> 
>   - cifs: Fix flushing, invalidation and file size with copy_file_range()
>   - cifs: Fix flushing, invalidation and file size with FICLONE
> 
> That's copy operation which fails now.
> 
> Reassigning to linux package for now..

It's

https://lore.kernel.org/linux-cifs/afbccb0c466888faa0e4753094e8ba09ed16dc51.ca...@amazon.com/

But I fear that will be lost due to missing CC's to others. So have
just replied with regressions list as wel in

https://lore.kernel.org/regressions/zzhrpnj3zxmr8...@eldamar.lan/

As this does not happen with upper stable series, I guess some
requisite commit is missing.

The mentioned commit from 6.7-rc5 was backported to 6.6.7 and 6.1.68,
but it does not happen in current 6.6.9-1 as in unstable.

Regards,
Salvatore



Bug#1059801: click: autopkgtests are failing

2024-01-05 Thread Adrian Bunk
Control: tags -1 ftbfs trixie sid
Control: severity -1 serious

On Mon, Jan 01, 2024 at 11:18:20AM -0500, Jeremy Bícha wrote:
> Source: click
> Version: 0.5.0-9
> Severity: important
> 
> The autopkgtests for click have recently begun failing.
> 
> https://ci.debian.net/packages/c/click/unstable/amd64/
> 
> https://autopkgtest.ubuntu.com/packages/click/noble/amd64

This is also a FTBFS:
https://buildd.debian.org/status/logs.php?pkg=click=0.5.0-9%2Bb1

> Thank you,
> Jeremy Bícha

cu
Adrian



Bug#1060098: qbs: FTBFS on mips64el: FAIL! : TestBlackbox::pluginDependency() qbs did not run correctly

2024-01-05 Thread Sebastian Ramacher
Source: qbs
Version: 2.1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=qbs=mips64el=2.1.2-2=1704035753=0

3: QDEBUG : TestBlackbox::pluginDependency() Restoring build graph from disk
3: Building for configuration default
3: /usr/bin/g++ -g -O0 -Wall -Wextra -pipe -fexceptions -fvisibility=default 
-fPIC -DUSING_HELPER2 -o 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/3a52ce780950d4d9/helper1.cpp.o
 -c 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/helper1.cpp
3: /usr/bin/g++ -g -O0 -Wall -Wextra -pipe -fexceptions -fvisibility=default 
-fPIC -DUSING_HELPER2 -o 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/myapp.94e7d341/3a52ce780950d4d9/main.cpp.o
 -c 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/main.cpp
3: /usr/bin/g++ -Wl,-soname=libhelper1.so,--as-needed -shared -o 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/libhelper1.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/3a52ce780950d4d9/helper1.cpp.o
3: /usr/bin/g++ -o 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/myapp.94e7d341/myapp
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/myapp.94e7d341/3a52ce780950d4d9/main.cpp.o
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/plugin4.bc129f88/libplugin4.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/plugin3.eea51762/libplugin3.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/libhelper1.so
3: Build done for configuration default.
3: 
3: QDEBUG : TestBlackbox::pluginDependency() Restoring build graph from disk
3: Resolving project for configuration default
3: Building for configuration default
3: Build done for configuration default.
3: 
3: QDEBUG : TestBlackbox::pluginDependency() Restoring build graph from disk
3: Building for configuration default
3: /usr/bin/g++ -o 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/myapp.94e7d341/myapp
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/myapp.94e7d341/3a52ce780950d4d9/main.cpp.o
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/plugin4.bc129f88/libplugin4.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/plugin3.eea51762/libplugin3.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/plugin2.35094eff/libplugin2.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/libhelper1.so
3: Build done for configuration default.
3: 
3: QDEBUG : TestBlackbox::pluginDependency() Restoring build graph from disk
3: Resolving project for configuration default
3: Building for configuration default
3: /usr/bin/g++ -Wl,-soname=libhelper1.so,--as-needed -shared -o 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/libhelper1.so
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper1.da71a942/3a52ce780950d4d9/helper1.cpp.o
 
/<>/obj-mips64el-linux-gnuabi64/tests/auto/blackbox/testWorkDir/plugin-dependency/default/helper2.e2ec051f/libhelper2.so
3: Build done for configuration default.
3: 
3: QDEBUG : TestBlackbox::pluginDependency() Restoring build graph from disk
3: Cleaning up for configuration default
3: 
3: FAIL!  : TestBlackbox::pluginDependency() qbs did not run correctly
3:Loc: [./tests/auto/blackbox/tst_blackboxbase.cpp(103)]

Cheers
-- 
Sebastian Ramacher



Bug#1060093: lirc: FTBFS on hurd-i386

2024-01-05 Thread Samuel Thibault
Hello,

Thanks for your patches.

Svante Signell, le ven. 05 janv. 2024 21:14:19 +0100, a ecrit:
> --- a/debian/rules2023-12-16 18:35:11.0 +0100
> +++ b/debian/rules2024-01-02 12:49:12.0 +0100
> @@ -4,7 +4,14 @@
>  include /usr/share/dpkg/pkg-info.mk
>  
>  export DEB_BUILD_MAINT_OPTIONS  = hardening=+all
> -export 
> _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)
> +
> +ifeq ($(DEB_HOST_ARCH_OS), hurd)
> +#FIXME: Replace gnu0 with either gnu or hurd in python3.11!
> +#/usr/lib/python3.11/__pycache__/_sysconfigdata__gnu0_i386-gnu.cpython-311.pyc
> + export 
> _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__gnu0_$(DEB_HOST_MULTIARCH)
> +else
> + export 
> _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata__$(DEB_HOST_ARCH_OS)_$(DEB_HOST_MULTIARCH)

Probably better just ask python itself:

export _PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__$(shell python3 -c 'import 
os; print(os.sys.platform)')_$(DEB_HOST_MULTIARCH)


> @@ -33,7 +40,7 @@
>  else
>   dh_auto_configure -- \
>   SH_PATH=/bin/sh \
> - MODINFO=/sbin/modinfo \
> + MODINFO= \
>   --disable-uinput --disable-devinput

We do want modinfo on the linux platform, please make this os-specific.

Samuel



Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

2024-01-05 Thread Paul Gevers

Control: tags -1 pending

Hi,

On 03-01-2024 20:40, Paul Gevers wrote:

On 03-01-2024 20:22, Simon McVittie wrote:

I think all of those are correct?


I think that if apt allows you to install it, chances are that it's a 
britney2 bug. I'll try to debug it tomorrow.


I have a first proposal for a fix in 
https://salsa.debian.org/release-team/britney2/-/merge_requests/89


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1051187: [Pkg-zfsonlinux-devel] Bug#1051187: Avoid building module for kernels that have appropriate zfs-modules- package installed

2024-01-05 Thread Andras Korn
On Fri, Jan 05, 2024 at 07:04:02AM +, 陈 晟祺 wrote:

Hi,

> > zfs-dkms is the failsafe in case the zfs-modules- package is 
> > *not* installed
> > (for example, because this is the first slow box I'm installing this kernel 
> > or this version of
> > zfs-dkms on and I don't yet have a corresponding zfs-modules package).
> 
> Let's imagine you install modules pkg first, then dkms pkg, which skips 
> building because you have
> "same" modules installed. After some days you accidentally uninstalled the 
> modules pkg, then how
> would the dkms pkg know and start the building? There is no such mechanism 
> according to my knowledge.

I'd like to start by saying that installing a zfs-modules- 
package is something only few people would probably do, people who have good 
reasons for going off the beaten path.

I submit that it's not unreasonable to expect such people to be extra careful 
and be aware of the risks inherent in what they are doing.

That said, I suppose a dpkg trigger could be used; or the postrm script of the 
zfs-modules- package could trigger the module build if zfs-dkms 
is installed. But frankly, I'm a great believer in allowing people to shoot 
themselves in the foot if they so desire. Expert features (which this would be) 
don't call for nanny automation.

> Even though such mechanism can be implemented by dkms, let's dig deeper into 
> details: how would dkms
> know that your prebuilt version and dkms source files are "the exact same" 
> and decide to skip? Designing
> such a mechanism would be either cumbersome for developers, or confusing for 
> users, I suppose.

I don't think it needs to do that. If the zfs-modules- package 
is installed, that means the admin is taking care of things.

If they have outdated kernel modules installed, it's their problem and not up 
to dkms or zfs-dkms maintainers to fix for them. You don't have to do 
everything for everyone.

I'd say it would be sufficient to document that installing a 
zfs-modules- package is not officially supported, and has the 
following consequences:

 1. zfs-dkms won't build a new module for ;
 2. if you subsequently remove zfs-modules-, you'll be left 
without a zfs module for  unless you trigger a zfs-dkms build 
yourself.

FWIW, you could also look at it from a green angle: building the modules when 
it's not necessary consumes extra electricity and is thus wasteful.

Best regards,

András

-- 
  I break into song if I can't find the key.



Bug#1058887: issue persists with kernel 6.6.8

2024-01-05 Thread Jean-Marc

Upgrading linux kernel to 6.6.9-1 does not solve the issue.

--
Jean-Marc



Bug#1060097: pytorch: FBFS: /<>/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp:249:103: error: cannot convert ‘dnnl::memory::data_type’ to ‘const ideep::dims&’ {aka ‘const std::ve

2024-01-05 Thread Sebastian Ramacher
Source: pytorch
Version: 2.0.1+dfsg-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=pytorch=amd64=2.0.1%2Bdfsg-5%2Bb1=1704146824=0

[589/1843] /usr/bin/c++ -DAT_PER_OPERATOR_HEADERS -DFMT_HEADER_ONLY=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 
-DONNX_NAMESPACE=onnx -DUSE_C10D_GLOO -DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC 
-DUSE_RPC -DUSE_TENSORPIPE -D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS 
-I/<>/build/aten/src -I/<>/aten/src 
-I/<>/build -I/<> 
-I/<>/cmake/../third_party/benchmark/include 
-I/<>/debian/foxi -I/<>/build/debian/foxi 
-I/<>/torch/csrc/api -I/<>/torch/csrc/api/include 
-I/<>/caffe2/aten/src/TH 
-I/<>/build/caffe2/aten/src/TH 
-I/<>/build/caffe2/aten/src 
-I/<>/build/caffe2/../aten/src -I/<>/torch/csrc 
-I/<>/third_party/miniz-2.1.0 
-I/<>/debian/kineto/libkineto/include 
-I/<>/debian/kineto/libkineto/src 
-I/<>/aten/../third_party/catch/single_include 
-I/<>/aten/src/ATen/.. -I/<>/c10/.. 
-I/<>/aten/src/ATen/native/quantized/cpu/qnnpack/include 
-I/<>/aten/src/ATen/native/quantized/cpu/qnnpack/src 
-I/<>/aten/src/ATen/native/quantized/cpu/qnnpack/deps/clog/include 
-I/<>/third_party/flatbuffers/include -isystem 
/<>/build/third_party/gloo -isystem 
/<>/cmake/../third_party/gloo -isystem 
/<>/cmake/../third_party/googletest/googlemock/include -isystem 
/<>/cmake/../third_party/googletest/googletest/include -isystem 
/usr/include/opencv4 -isystem /usr/include/eigen3 -isystem 
/<>/caffe2 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-gsplit-dwarf -Wno-dangling-reference  -I/usr -D_GLIBCXX_USE_CXX11_ABI=1 
-Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -DUSE_KINETO 
-DLIBKINETO_NOCUPTI -DLIBKINETO_NOROCTRACER -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK 
-DSYMBOLICATE_MOBILE_DEBUG_HANDLE -O2 -fPIC -Wall -Wextra -Werror=return-type 
-Werror=non-virtual-dtor -Werror=range-loop-construct -Werror=bool-operation 
-Wnarrowing -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds 
-Wno-unknown-pragmas -Wunused-local-typedefs -Wno-unused-parameter 
-Wno-unused-function -Wno-unused-result -Wno-strict-overflow 
-Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow 
-Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls 
-Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new 
-Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno 
-fno-trapping-math -Werror=format -Werror=cast-function-type 
-Wno-stringop-overflow -DHAVE_AVX512_CPU_DEFINITION -DHAVE_AVX2_CPU_DEFINITION 
-O2 -g -DNDEBUG -std=gnu++17 -fPIC -DCAFFE2_USE_GLOO -DTH_HAVE_THREAD -Wall 
-Wextra -Wno-unused-parameter -Wno-unused-function -Wno-unused-result 
-Wno-missing-field-initializers -Wno-write-strings -Wno-unknown-pragmas 
-Wno-type-limits -Wno-array-bounds -Wno-sign-compare -Wno-strict-overflow 
-Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-missing-braces 
-Wno-maybe-uninitialized -fvisibility=hidden -O2 -DCAFFE2_BUILD_MAIN_LIB 
-fopenmp -Wno-deprecated-declarations -MD -MT 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
 -MF 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o.d
 -o 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
 -c /<>/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp
FAILED: 
caffe2/CMakeFiles/torch_cpu.dir/__/aten/src/ATen/native/quantized/cpu/qlinear_prepack.cpp.o
 
/usr/bin/c++ -DAT_PER_OPERATOR_HEADERS -DFMT_HEADER_ONLY=1 
-DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_MMAP=1 -DHAVE_SHM_OPEN=1 -DHAVE_SHM_UNLINK=1 
-DMINIZ_DISABLE_ZIP_READER_CRC32_CHECKS -DONNXIFI_ENABLE_EXT=1 -DONNX_ML=1 
-DONNX_NAMESPACE=onnx -DUSE_C10D_GLOO -DUSE_DISTRIBUTED -DUSE_EXTERNAL_MZCRC 
-DUSE_RPC -DUSE_TENSORPIPE -D_FILE_OFFSET_BITS=64 -Dtorch_cpu_EXPORTS 
-I/<>/build/aten/src -I/<>/aten/src 
-I/<>/build -I/<> 
-I/<>/cmake/../third_party/benchmark/include 
-I/<>/debian/foxi -I/<>/build/debian/foxi 
-I/<>/torch/csrc/api -I/<>/torch/csrc/api/include 
-I/<>/caffe2/aten/src/TH 
-I/<>/build/caffe2/aten/src/TH 
-I/<>/build/caffe2/aten/src 
-I/<>/build/caffe2/../aten/src -I/<>/torch/csrc 
-I/<>/third_party/miniz-2.1.0 
-I/<>/debian/kineto/libkineto/include 
-I/<>/debian/kineto/libkineto/src 
-I/<>/aten/../third_party/catch/single_include 
-I/<>/aten/src/ATen/.. -I/<>/c10/.. 
-I/<>/aten/src/ATen/native/quantized/cpu/qnnpack/include 
-I/<>/aten/src/ATen/native/quantized/cpu/qnnpack/src 
-I/<>/aten/src/ATen/native/quantized/cpu/qnnpack/deps/clog/include 
-I/<>/third_party/flatbuffers/include -isystem 
/<>/build/third_party/gloo -isystem 
/<>/cmake/../third_party/gloo 

Bug#1060096: hiredes: FTBFS: #118 Returns I/O error on socket timeout: ␛[0;32mPAShiredis-test: test.c:2199: test_async_polling: Assertion `c->err == 0' failed.

2024-01-05 Thread Sebastian Ramacher
Source: hiredis
Version: 1.2.0-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=hiredis=amd64=1.2.0-5=1704389545=0

Testing against Unix socket connection 
(/tmp/tmp.L5kzBjtVQg/hiredis-test-redis.sock): 
#95 Is able to deliver commands: ␛[0;32mPASSED␛[0;0m
#96 Is a able to send commands verbatim: ␛[0;32mPASSED␛[0;0m
#97 %s String interpolation works: ␛[0;32mPASSED␛[0;0m
#98 %b String interpolation works: ␛[0;32mPASSED␛[0;0m
#99 Binary reply length is correct: ␛[0;32mPASSED␛[0;0m
#100 Can parse nil replies: ␛[0;32mPASSED␛[0;0m
#101 Can parse integer replies: ␛[0;32mPASSED␛[0;0m
#102 Can parse multi bulk replies: ␛[0;32mPASSED␛[0;0m
#103 Can handle nested multi bulk replies: ␛[0;32mPASSED␛[0;0m
#104 Send command by passing argc/argv: ␛[0;32mPASSED␛[0;0m
#105 Can pass NULL to redisGetReply: ␛[0;32mPASSED␛[0;0m
#106 We set a default RESP3 handler for redisContext: ␛[0;32mPASSED␛[0;0m
#107 We don't set a default RESP3 push handler for redisAsyncContext: 
␛[0;32mPASSED␛[0;0m
#108 Our REDIS_OPT_NO_PUSH_AUTOFREE flag works: ␛[0;32mPASSED␛[0;0m
#109 We can use redisOptions to set a custom PUSH handler for redisContext: 
␛[0;32mPASSED␛[0;0m
#110 We can use redisOptions to set a custom PUSH handler for 
redisAsyncContext: ␛[0;32mPASSED␛[0;0m
#111 We can use redisOptions to set privdata: ␛[0;32mPASSED␛[0;0m
#112 Our privdata destructor fires when we free the context: ␛[0;32mPASSED␛[0;0m
#113 Successfully completes a command when the timeout is not exceeded: 
␛[0;32mPASSED␛[0;0m
#114 Does not return a reply when the command times out: ␛[0;32mPASSED␛[0;0m
#115 Reconnect properly reconnects after a timeout: ␛[0;32mPASSED␛[0;0m
#116 Reconnect properly uses owned parameters: ␛[0;32mPASSED␛[0;0m
#117 Returns I/O error when the connection is lost: ␛[0;32mPASSED␛[0;0m
#118 Returns I/O error on socket timeout: ␛[0;32mPAShiredis-test: test.c:2199: 
test_async_polling: Assertion `c->err == 0' failed.
Aborted
make[2]: *** [Makefile:271: check] Error 134

Cheers
-- 
Sebastian Ramacher



Bug#1058713: ITP: picom-conf -- Configuration editor for Picom

2024-01-05 Thread Aaron Rainbolt
The packaging has been finished and a Salsa repo containing the upstream 
code and packaging can now be found at 
https://salsa.debian.org/ArrayBolt3/picom-conf. Ready for review.


Copying Simon in on this since I'm hoping he'll review it for me.

--
Aaron Rainbolt
Lubuntu Developer
Matrix: @arraybolt3:matrix.org
IRC: arraybolt3 on irc.libera.chat
GitHub: https://github.com/ArrayBolt3



Bug#1060095: python-sure: please remove python3-usage using provided patch

2024-01-05 Thread Alexandre Detiste
Source: python-sure
Severity: normal

mock is now part of the standard library under the name unittest.mock


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

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



Bug#967851: gtkextra: unmaintained upstream since 2018

2024-01-05 Thread Bastian Germann

Control: severity -1 serious

On Tue, 4 Aug 2020 12:41:32 +0100 Simon McVittie  wrote:

The only package in Debian that depends on it appears to be gpsim.


It is now lepton-eda, which is also available for GTK-3 without gtkextra.
So, gtkextra should definitly leave Debian.



Bug#618429: ncurses-doc: no 3x man pages in /usr/share/man/man3

2024-01-05 Thread Sven Joachim
On 2011-03-17 18:05 -0400, Thomas Dickey wrote:

> On Wed, 16 Mar 2011, Sven Joachim wrote:
>
>> On 2011-03-15 03:54 +0100, Vincent Lefevre wrote:
>>
>>> Package: ncurses-doc
>>> Version: 5.8+20110307-1
>>
>> Note that none of this is new, the same problem exists in the
>> libncurses5-dev package in squeeze and lenny which held the
>> documentation before I split it out to ncurses-doc.
>>
>>> ncurses-doc has /usr/share/doc/ncurses-doc/html/man/*.3x.html files,
>>> but not the corresponding man pages in /usr/share/man/man3.
>>
>> More exactly, the manpages are there, but not under the same names.
>> This is because they are renamed (see man/man_db.renames in the ncurses
>> source tree), while the HTML documentation does not receive such
>> treatment.
>>
>> I don't know why this setup with renaming manpages exists, but it has
>> been around at least since ncurses 4.1, released 1997.
>
> Before that - man_db.renames was added in October 1995.  At that point,
> only the files were renamed (no link-fixes), and I added the edit_man.sh
> script in mid-1996 (I seem to recall that was to obsolete some scripting
> in the Debian package - or perhaps I'm recalling some later refinement).
>
> My understanding was that it was done that way to follow some Debian
> guideline.

There is an old thread about that topic from 1996 on debian-devel[1].
The main reason for renaming the manpages has been stated by Richard
Kettlewell[2] and confirmed by Ian Jackson[3]:

,
| Isn't it a good thing that you can say man  and get the
| right man page, rather than having to say man curs_,
| though?
`

>>> Note that some other man pages, e.g. reset(1), have references to
>>> such man pages in the "SEE ALSO" section, so that it is annoying
>>> not to have access to these man pages with "man".
>>
>> This is a fallout from the following change mentioned in NEWS:
>>
>> ,
>> | 20061230
>> |  [...]
>> |+ used linklint to verify links in the HTML documentation, made fixes
>> |  to manpages as needed.
>> `
>>
>> That change fixed the links in the HTML documentation, but broke the
>> references in the manpages themselves.

There have been more of such issues, for instance #1004901 and #1057651.
However, thanks to Branden Robinson's work on the manpages in recent
months, all but one reference should be fixed in the latest patchlevel.
I just sent a patch upstream for the last one[4].

> The html documentation _could_ be generated to be consistent with the
> manpages, but that would complicate the Debian package...

Apparently we would need to package or vendor your version of man2html
and run it with suitable options on the installed manpages.  There does
not seem to be a dedicated target in the Makefiles to regenerate the
HTML documentation, if I understand correctly this is done as part of
"make dist".

Certainly that is not impossible, but it is also something I am not
exactly keen on.

Cheers,
   Sven


1. https://lists.debian.org/debian-devel/1996/06/threads.html#00281
2. https://lists.debian.org/debian-devel/1996/06/msg00364.html
3. https://lists.debian.org/debian-devel/1996/06/msg00393.html
4. https://lists.gnu.org/archive/html/bug-ncurses/2024-01/msg1.html



Bug#1060094: python-thinc: remove usage of python3-mock

2024-01-05 Thread Alexandre Detiste
Source: python-thinc
Severity: normal


Please apply this patch to remove usage of old python3-mock
and use unittest.mock from the standard library instead.

Greetings


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/debian/control b/debian/control
index 6b924ba..d5ba177 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,6 @@ Build-Depends: cython3,
python3-cytoolz,
python3-dill,
python3-hypothesis,
-   python3-mock,
python3-msgpack,
python3-msgpack-numpy,
python3-murmurhash,
diff --git a/requirements.txt b/requirements.txt
index 112e535..a68b66e 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -22,7 +22,6 @@ hypothesis>=3.27.0,<7.0.0
 pytest>=5.2.0,!=7.1.0
 pytest-cov>=2.7.0,<5.0.0
 coverage>=5.0.0,<8.0.0
-mock>=2.0.0,<3.0.0
 flake8>=3.5.0,<3.6.0
 mypy>=0.990,<0.1000; python_version >= "3.7"
 types-mock>=0.1.1
diff --git a/thinc/tests/layers/test_linear.py 
b/thinc/tests/layers/test_linear.py
index 2362b55..2e5602f 100644
--- a/thinc/tests/layers/test_linear.py
+++ b/thinc/tests/layers/test_linear.py
@@ -1,5 +1,5 @@
 import pytest
-from mock import MagicMock
+from unittest.mock import MagicMock
 from hypothesis import given, settings
 import numpy
 from numpy.testing import assert_allclose
diff --git a/thinc/tests/layers/test_with_debug.py 
b/thinc/tests/layers/test_with_debug.py
index 679c1f2..d4bdbee 100644
--- a/thinc/tests/layers/test_with_debug.py
+++ b/thinc/tests/layers/test_with_debug.py
@@ -1,4 +1,4 @@
-from mock import MagicMock
+from unittest.mock import MagicMock
 from thinc.api import with_debug, Linear
 
 


Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Paul Gevers

Hi Steve,

On 05-01-2024 17:36, Rene Engelhard wrote:
Also a problem is that experimental also might already contain totally 
unrelated updates like new upstream versions...


I share this worry. Have you thought about how to handle the cases where 
you don't have experimental to upload to? How big is this problem?


Another worry, how will you provide the required changes to the 
maintainers of the packages? Via BTS? For those working on salsa: MR? 
Both? Something else? Obviously we should not end in the situation that 
a new upload goes back to the old name (or are the ftp-masters so keen 
on this transition that that won't happen? But what about newer versions 
with the old name already in experimental, conform the former worry?). 
I've seen NMU's being ignored by subsequent uploads by the maintainer, 
even when they fixed RC issues which were then reintroduced.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1060093: lirc: FTBFS on hurd-i386

2024-01-05 Thread Svante Signell
Source: lirc
Version: 0.10.2-0.2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hi,

lirc FTBFS on hurd-i386. (Built in the past, last successful build
version was 0.10.1-5.2)

This is due to usage of __u32 (and __u16,__u64) in
include/media/lirc.h, which is not defined on GNU/Hurd. Additionally
inclusion of header files is ifdef-ed and config.h is included.

Moreover, MODINFO is not available on GNU/Hurd since Hurd does not use
modules at all. This change is reflected in the second patch for
debian/rules.

The two patches enabling a successful build on GNU/Hurd (and
GNU/Linux)are attached in next mail:
- include/media/lirc.h
- debian_rules.patch.

I'm sending this bug report to Debian instead of upstream since this
package has been NMU-ed several times, and the second patch is Debian-
specific.

Thanks!

Index: lirc-0.10.2/include/media/lirc.h
===
--- lirc-0.10.2.orig/include/media/lirc.h
+++ lirc-0.10.2/include/media/lirc.h
@@ -6,8 +6,27 @@
 #ifndef _LINUX_LIRC_H
 #define _LINUX_LIRC_H
 
+#include "config.h"
+
+#ifdef HAVE_STDINT_H
+#include 
+#endif
+
+#ifdef HAVE_LINUX_TYPES_H
 #include 
+#endif
+
+#ifdef HAVE_LINUX_IOCTL_H
 #include 
+#endif
+
+#ifdef HAVE_SYS_IOCTL_H
+#include 
+#endif
+
+#ifdef __GNU__
+#include 
+#endif
 
 #define PULSE_BIT   0x0100
 #define PULSE_MASK  0x00FF
@@ -93,55 +112,55 @@
 
 /*** IOCTL commands for lirc driver ***/
 
-#define LIRC_GET_FEATURES  _IOR('i', 0x, __u32)
+#define LIRC_GET_FEATURES  _IOR('i', 0x, uint32_t)
 
-#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, __u32)
-#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, __u32)
-#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, __u32)
+#define LIRC_GET_SEND_MODE _IOR('i', 0x0001, uint32_t)
+#define LIRC_GET_REC_MODE  _IOR('i', 0x0002, uint32_t)
+#define LIRC_GET_REC_RESOLUTION_IOR('i', 0x0007, uint32_t)
 
-#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, __u32)
-#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, __u32)
+#define LIRC_GET_MIN_TIMEOUT   _IOR('i', 0x0008, uint32_t)
+#define LIRC_GET_MAX_TIMEOUT   _IOR('i', 0x0009, uint32_t)
 
 /* code length in bits, currently only for LIRC_MODE_LIRCCODE */
-#define LIRC_GET_LENGTH_IOR('i', 0x000f, __u32)
+#define LIRC_GET_LENGTH_IOR('i', 0x000f, uint32_t)
 
-#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, __u32)
-#define LIRC_SET_REC_MODE  _IOW('i', 0x0012, __u32)
+#define LIRC_SET_SEND_MODE _IOW('i', 0x0011, uint32_t)
+#define LIRC_SET_REC_MODE  _IOW('i', 0x0012, uint32_t)
 /* Note: these can reset the according pulse_width */
-#define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, __u32)
-#define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, __u32)
-#define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, __u32)
-#define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, __u32)
+#define LIRC_SET_SEND_CARRIER  _IOW('i', 0x0013, uint32_t)
+#define LIRC_SET_REC_CARRIER   _IOW('i', 0x0014, uint32_t)
+#define LIRC_SET_SEND_DUTY_CYCLE   _IOW('i', 0x0015, uint32_t)
+#define LIRC_SET_TRANSMITTER_MASK  _IOW('i', 0x0017, uint32_t)
 
 /*
  * when a timeout != 0 is set the driver will send a
  * LIRC_MODE2_TIMEOUT data packet, otherwise LIRC_MODE2_TIMEOUT is
  * never sent, timeout is disabled by default
  */
-#define LIRC_SET_REC_TIMEOUT   _IOW('i', 0x0018, __u32)
+#define LIRC_SET_REC_TIMEOUT   _IOW('i', 0x0018, uint32_t)
 
 /* 1 enables, 0 disables timeout reports in MODE2 */
-#define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, __u32)
+#define LIRC_SET_REC_TIMEOUT_REPORTS   _IOW('i', 0x0019, uint32_t)
 
 /*
  * if enabled from the next key press on the driver will send
  * LIRC_MODE2_FREQUENCY packets
  */
-#define LIRC_SET_MEASURE_CARRIER_MODE	_IOW('i', 0x001d, __u32)
+#define LIRC_SET_MEASURE_CARRIER_MODE	_IOW('i', 0x001d, uint32_t)
 
 /*
  * to set a range use LIRC_SET_REC_CARRIER_RANGE with the
  * lower bound first and later LIRC_SET_REC_CARRIER with the upper bound
  */
-#define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, __u32)
+#define LIRC_SET_REC_CARRIER_RANGE _IOW('i', 0x001f, uint32_t)
 
-#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, __u32)
+#define LIRC_SET_WIDEBAND_RECEIVER _IOW('i', 0x0023, uint32_t)
 
 /*
  * Return the recording timeout, which is either set by
  * the ioctl LIRC_SET_REC_TIMEOUT or by the kernel after setting the protocols.
  */
-#define LIRC_GET_REC_TIMEOUT	   _IOR('i', 0x0024, __u32)
+#define LIRC_GET_REC_TIMEOUT	   _IOR('i', 0x0024, uint32_t)
 
 /**
  * struct 

Bug#1060092: python-datacache: remove usage of old python3-mock

2024-01-05 Thread Alexandre Detiste
Source: python-datacache
Severity: normal

Dear Maintainers,

Please apply this patch to remove usage of old python3-mock.

Instead we can use the new 'mock' from the standard library.

Greetings,


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff --git a/datacache.egg-info/requires.txt b/datacache.egg-info/requires.txt
index 729452b..64389c1 100644
--- a/datacache.egg-info/requires.txt
+++ b/datacache.egg-info/requires.txt
@@ -3,4 +3,3 @@ appdirs>=1.4.0
 progressbar33>=2.4
 requests>=2.5.1
 typechecks>=0.0.2
-mock
diff --git a/debian/control b/debian/control
index 586d058..eaa2421 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,6 @@ Build-Depends: debhelper-compat (= 13),
python3-appdirs,
python3-biopython ,
python3-typechecks ,
-   python3-mock ,
 Standards-Version: 4.6.2
 Homepage: https://github.com/openvax/datacache
 Vcs-Browser: https://salsa.debian.org/med-team/python-datacache
diff --git a/setup.py b/setup.py
index da61f78..82d172f 100644
--- a/setup.py
+++ b/setup.py
@@ -58,7 +58,6 @@ if __name__ == "__main__":
 "progressbar33>=2.4",
 "requests>=2.5.1",
 "typechecks>=0.0.2",
-"mock",
 ],
 long_description=readme_markdown,
 long_description_content_type='text/markdown',
diff --git a/test/test_cache_object.py b/test/test_cache_object.py
index fd6e4cb..544a270 100644
--- a/test/test_cache_object.py
+++ b/test/test_cache_object.py
@@ -1,6 +1,6 @@
 from os import remove
 from os.path import exists
-from mock import patch
+from unittest.mock import patch
 
 from datacache import Cache
 


Bug#1060091: chasquid: v1.11.1 with backported SMTP smuggling fix was released, will this be released in debian stable?

2024-01-05 Thread Matěj Volf

Package: chasquid
Version: 1.11-2+b2
Severity: normal

Hi all,

you might have heard about the latest SMTP smuggling vulnerability. 
Author of chasquid responsed by releasing 1.13 and 1.11.1 
() with the 
backported fix. From , I 
understand that 1.13 was automatically accepted into testing, but I 
didn't notice anything happening regarding 1.11.1 (my server is on 
Debian stable, which only has 1.11), so I wanted to politely ask if this 
could be processed as well.


I have very little knowledge about the Debian packaging and release 
process, so please correct if I have any major misunderstanding of the 
process and what I'm asking is unreasonable.


Thank you for your work.
Best
Matej


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-cloud-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chasquid depends on:
ii  libc6  2.36-9+deb12u3

chasquid recommends no packages.

chasquid suggests no packages.

-- Configuration Files:
/etc/chasquid/certs/README.certs [Errno 2] No such file or directory: 
'/etc/chasquid/certs/README.certs'

/etc/chasquid/chasquid.conf changed [not included]
/etc/chasquid/hooks/post-data changed [not included]

-- no debconf information



Bug#1060090: Consider excluding vendored nanosvg copy

2024-01-05 Thread Matthias Geiger
Package: fuzzel
Version: 1.9.2-1
Severity: normal
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,
as of now, futtel still includes nanosvg as vendored library under the
3rdparty folder. nanosvg itself was recently uploaded to the archive
though [0]. Please look into building fuzzel with the debian nanosvg
copy so we can minimize vendoring and duplicated code/headers.

best,

werdahias

[0] https://tracker.debian.org/pkg/nanosvg


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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages fuzzel depends on:
ii  libc6   2.37-13
ii  libcairo2   1.18.0-1
ii  libfcft43.1.7-1
ii  libfontconfig1  2.14.2-6
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-3
ii  libwayland-client0  1.22.0-2.1
ii  libwayland-cursor0  1.22.0-2.1
ii  libxkbcommon0   1.6.0-1

Versions of packages fuzzel recommends:
ii  hicolor-icon-theme  0.17-2

fuzzel suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWYX5AVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1ep8P/j4xsbPDRSzTdOcwlPhOo12i4iYD
BKjd/fD++hpyXPbpVY3uH88cLiX0D6RpYXe+Wz29qb3uIjCQ4j8e8KN9naNknzEq
im9+F26a/xjfWTOZ8fNZdTQEx1eK2q88DuDSOgiNQP0mqlVkMcxfGbApTftcCu67
xe2HXkm5yLY/BBLIJiJgfMwlwoJSleNjfA1jS6L38xmYsuMxnvHg0S7euYwVvelE
npKp9Msv9rnMzsiIrqI36GwKxqBfx/RQMN8d1DFJaxk0sz656UHqbzqcDCI2gNCG
8uqRHtbVmtVOtvWY5QkAeL/wKQPeyibwe9oB/8rqvPoMXvY0NgLEY9IXFqLSp9W1
4p40lI5oAW9XJpQPY1ZRtyPWVDBCP/S59V+phXQERBKNkDttsiIBqdhbyoUo/rsJ
QVyusoxIzoj1k/qdcLdIA25+ppc/n26wa+Z80BqM5DkGqgKuZ8/aJMHvXtJZR8gH
OpBDoUIDQacwnY6JCDFffxc62cko5vyeMnsPZqM0hSVstEtLGCf9zh+SKR+DOYvk
YlYLyqJJN+AG3Bp+7gywuC+WG6aFhSrWPmEmhfjmH2p35Sb7eCArGUaR7ajJksLB
C2cCQySiyTbEBcP0k6poPiP5dGGdI8TnCarURfea5G1CiEQ10gILizBE5QKMe6qP
0ku9cxj8lZqJjFKh
=opJk
-END PGP SIGNATURE-



Bug#1060089: isc-dhcp: install dhclient into /usr/sbin, with DEP17 M18 diversions

2024-01-05 Thread Chris Hofstaedtler
Source: isc-dhcp
Version: 4.4.3-P1-4
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17p3

isc-dhcp-client and isc-dhcp-client-ddns both install
/sbin/dhclient, with the latter diverting it. The diversions become
ineffective when one of them moves to /usr/sbin/dhclient.

I'm attaching a patch that moves /sbin/dhclient and applies the
required workarounds for diversions ("DEP17 M18").

Getting this right is hard. I would welcome additional testing and
reviews.

I would also advise uploading to experimental first. Please do so
soon, so we can all check the result (again).

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru isc-dhcp-4.4.3-P1/debian/changelog isc-dhcp-4.4.3-P1/debian/changelog
--- isc-dhcp-4.4.3-P1/debian/changelog	2023-10-20 14:16:37.0 +0200
+++ isc-dhcp-4.4.3-P1/debian/changelog	2024-01-04 19:40:32.0 +0100
@@ -1,3 +1,10 @@
+isc-dhcp (4.4.3-P1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move dhclient to /usr/sbin and add duplicated diversions (DEP17 P3 M18)
+
+ -- Chris Hofstaedtler   Thu, 04 Jan 2024 19:40:32 +0100
+
 isc-dhcp (4.4.3-P1-4) unstable; urgency=low
 
   [ Athos Ribeiro ]
diff -Nru isc-dhcp-4.4.3-P1/debian/control isc-dhcp-4.4.3-P1/debian/control
--- isc-dhcp-4.4.3-P1/debian/control	2023-09-15 18:19:55.0 +0200
+++ isc-dhcp-4.4.3-P1/debian/control	2024-01-04 19:40:32.0 +0100
@@ -107,6 +107,8 @@
  isc-dhcp-client-ddns,
 Provides:
  dhcp-client,
+Conflicts:
+ isc-dhcp-client-ddns (<< 4.4.3-P1-4.1),
 Description: DHCP client for automatically obtaining an IP address
  This is the Internet Software Consortium's DHCP client.
  .
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install	2022-02-23 10:28:51.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install	2024-01-04 19:40:32.0 +0100
@@ -1 +1 @@
-client/dhclient sbin
+client/dhclient usr/sbin
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst	1970-01-01 01:00:00.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst	2024-01-04 19:40:32.0 +0100
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -e
+
+# DEP17 M18: Duplicate diversion in aliased location /sbin.
+
+if [ "$1" = "configure" ]; then
+	# Remove diversion in aliased path, which is only needed for upgrades.
+	dpkg-divert --package isc-dhcp-client-ddns --remove --no-rename --divert /sbin/dhclient-noddns.usr-is-merged /sbin/dhclient
+fi
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm	2022-02-23 10:28:51.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm	2024-01-04 19:40:32.0 +0100
@@ -3,8 +3,8 @@
 set -e 
 
 if [ "$1" = "remove" -o "$1" = "abort-install" -o "$1" = "disappear" ]; then
-dpkg-divert --package isc-dhcp-client-ddns --remove \
-		--rename --divert /sbin/dhclient-noddns /sbin/dhclient
+	dpkg-divert --package isc-dhcp-client-ddns --remove \
+		--rename --divert /usr/sbin/dhclient-noddns /usr/sbin/dhclient
 fi
 
 #DEBHELPER#
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst	2022-02-23 10:28:51.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst	2024-01-04 19:40:32.0 +0100
@@ -2,9 +2,33 @@
 
 set -e 
 
-if [ "$1" != "upgrade" ]; then
-	dpkg-divert --package isc-dhcp-client-ddns --add --rename \
-		--divert /sbin/dhclient-noddns /sbin/dhclient
-fi
+# DEP17 M18: Duplicate diversion in aliased location /sbin.
+
+case "$1" in
+	install)
+		# canonical path; the one we are using going forward.
+		dpkg-divert --package isc-dhcp-client-ddns --add --rename \
+			--divert /usr/sbin/dhclient-noddns /usr/sbin/dhclient
+		# aliased path, for upgrades. postinst will --remove it.
+		dpkg-divert --package isc-dhcp-client-ddns --add --rename \
+			--divert /sbin/dhclient-noddns.usr-is-merged /sbin/dhclient
+
+		;;
+
+	upgrade)
+		dpkg-divert --package isc-dhcp-client-ddns --add --no-rename --divert /usr/sbin/dhclient-noddns /usr/sbin/dhclient
+
+		# convert a pre-existing, aliased diversion. postinst will remove it.
+		TRUENAME=$(dpkg-divert --truename /sbin/dhclient)
+		if test "$TRUENAME" != "/sbin/dhclient-noddns.usr-is-merged" -a "$TRUENAME" != "/sbin/dhclient"; then
+			dpkg-divert --package isc-dhcp-client-ddns --remove --no-rename /sbin/dhclient
+			dpkg-divert --package isc-dhcp-client-ddns --add --no-rename --divert /sbin/dhclient-noddns.usr-is-merged /sbin/dhclient
+			if test -e "$DPKG_ROOT$TRUENAME" -o -h "$DPKG_ROOT$TRUENAME"; then
+mv "$DPKG_ROOT$TRUENAME" 

Bug#1056576: u-boot: Consider building apple/asahi variant

2024-01-05 Thread Vagrant Cascadian
On 2023-11-23, Andreas Henriksson wrote:
> On Thu, Nov 23, 2023 at 08:16:43PM +0100, Tobias Heider wrote:
>> On Thu, Nov 23, 2023 at 10:51:04AM -0800, Vagrant Cascadian wrote:
>> > On 2023-11-23, Andreas Henriksson wrote:
...
>> > > 3/ do we include patches?
>> > > 3.1/ No patches. If this is the desired path I can volunteer
>> > >  to test that it boots on my M1 machine. Other machines
>> > >  should probably be considered unsupported for now,
>> > >  even though they might have limited usefulness.
>> > > 3.2/ Minimal set of patches. We identify what we consider
>> > >  crutial only patches and recruit volunteers to test.
>> > >  M2 keyboard? USB? etc...
>> > > 3.3/ All asahi patches. We consider it simpler to just sync all patches
>> > >  with the asahi fork (even though some are even unused, like the
>> > >  devicetree patches). We trust the Asahi Linux project in their
>> > >  quest to upstream all their work and that they will rebase on newer
>> > >  releases and make our job easy.
>> > 
>> > I am inclined towards starting with no patches or a minimal set of
>> > patches. The asashi folks do seem to generally do a good job of
>> > upstreaming, so support should improve over time.
>
> I'm not against going this route, my only concern is using the asahi
> name while shipping an "inferior" variant (no patches). The Asahi Linux
> people have been very good at being end-user focused, fixing all kind of
> bugs and really go above and beyond to not compromise on end user
> experience. Not sure they'd appreciate us shipping it under their name
> while exposing "already fixed" bugs but what do I know.
> We can always add patches later I guess. The Trixie freeze is not
> happening soon and we're not providing any installer yet, so it should
> just be a few #debian-bananas people trying this out for a while still
> I guess.

This seems like the main blocker at this point; I am hoping to upload at
least 2024.01-rc6 to experimental shortly (and 2024.01 to unstable once
it releases), and it would be nice to include a u-boot variant
supporting these boards, but I am nervous about shipping patches.  As
you pointed out an unpatched version with asashi in the name might not
be appreciated... but ... uh, er. Hrm. I would really like to get this
in!

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1060088: python-telegram-bot: please remove extraneous build-dep on python3-future

2024-01-05 Thread Alexandre Detiste
Source: python-telegram-bot
Version: 20.7-1
Severity: important

Hi,

python3-future is being removed soon from archive

please remove it from "Build-Depends:",
the package doesn't need this library.

Greetings


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

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



Bug#1060087: qemu: move mount unit into /usr

2024-01-05 Thread Chris Hofstaedtler
Source: qemu
Version: 1:8.2.0+ds-4
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Your package installs /lib/systemd/system/run-qemu.mount. For the
ongoing Debian UsrMerge effort [1] this file should move to /usr in
the trixie cycle.

I'm attaching a patch to use dh_movetousr to move it. The patch
should also work on bookworm and earlier, and silently do nothing.

Might still be worth a trip through experimental, to get this
checked by dumat. If after a few days you got no new bugs from
dumat, please upload to unstable.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru qemu-8.2.0+ds/debian/changelog qemu-8.2.0+ds/debian/changelog
--- qemu-8.2.0+ds/debian/changelog	2024-01-04 20:47:59.0 +0100
+++ qemu-8.2.0+ds/debian/changelog	2024-01-05 19:33:51.0 +0100
@@ -1,3 +1,11 @@
+qemu (1:8.2.0+ds-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use dh_movetousr to move mount unit into /usr/lib.
+Should backport cleanly to older releases. 
+
+ -- Chris Hofstaedtler   Fri, 05 Jan 2024 19:33:51 +0100
+
 qemu (1:8.2.0+ds-4) unstable; urgency=medium
 
   * d/rules: fix "tail -20" usage
diff -Nru qemu-8.2.0+ds/debian/rules qemu-8.2.0+ds/debian/rules
--- qemu-8.2.0+ds/debian/rules	2024-01-04 20:43:38.0 +0100
+++ qemu-8.2.0+ds/debian/rules	2024-01-05 19:33:51.0 +0100
@@ -734,6 +734,7 @@
 binary: install-arch install-indep binary-helper
 binary: a=
 binary-helper:
+	if command -v dh_movetousr; then dh_movetousr $a; fi
 	dh_installdeb $a
 	dh_gencontrol $a
 	dh_md5sums $a


Bug#1060086: RFS: fweb/1.62-14.1 [NMU] [RC] -- literate-programming tool for C/C++/Fortran/Ratfor

2024-01-05 Thread Hilmar Preusse
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "fweb":

 * Package name : fweb
   Version  : 1.62-14.1
   Upstream contact : John A. Krommes.
 * URL  : http://w3.pppl.gov/~krommes/
 * License  : GPL-2
 * Vcs  : 
   Section  : devel

The source builds the following binary packages:

  fweb - literate-programming tool for C/C++/Fortran/Ratfor
  fweb-doc - Documentation for literate-programming tool Fweb

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

  https://mentors.debian.net/package/fweb/

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

  dget -x https://mentors.debian.net/debian/pool/main/f/fweb/fweb_1.62-14.1.dsc

Changes since the last upload:

 fweb (1.62-14.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Fix FTBFS with TeXinfo 7.x (Closes: #1030350).

Regards,
--
  Hilmar Preusse


signature.asc
Description: PGP signature


Bug#1059891: linux-image-6.1.0-17-amd64: netfilter (nftables) breaks since bookworm

2024-01-05 Thread Salvatore Bonaccorso
Control: tags -1 + moreinfo

On Wed, Jan 03, 2024 at 07:35:23AM +0100, Daniel Haryo Sugondo wrote:
> Package: src:linux
> Version: 6.1.69-1
> Severity: normal
> 
> Dear Maintainer,
> 
> since Debian 12 (Bookworm) the nft with named set ends with kernel trace and 
> the
> nft stalled (D)
> # ps aux
> root   82373  0.0  0.0  0 0 ?DJan02   0:00 [nft]
> 
> The message looks like:
> [ 3566.525419] [ cut here ]
> [ 3566.525424] kernel BUG at mm/slub.c:419!
> [ 3566.529834] invalid opcode:  [#1] PREEMPT SMP PTI
> [ 3566.535474] CPU: 19 PID: 8146 Comm: kworker/19:0 Not tainted 
> 6.1.0-17-amd64 #1  Debian 6.1.69-1
> [ 3566.545182] Hardware name:  /0X3D66, BIOS 2.2.2 01/16/2014
> [ 3566.551304] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
> [ 3566.558609] RIP: 0010:__slab_free+0x118/0x2d0
> [ 3566.563474] Code: 74 35 49 8b 06 48 89 4c 24 20 48 c1 e8 36 4c 8b a4 c3 d8 
> 00 00 00 4c 89 e7 e8 74 6a 71 00 48 8b 4c 24 20 48 89 44 24 18 eb 8f <0f> 0b 
> f7 43 08 00 0d 21 00 75 cd eb c6 80 4c 24 53 80 e9 75 ff ff
> [ 3566.584431] RSP: 0018:a76066effdb0 EFLAGS: 00010246
> [ 3566.590262] RAX: 95430ba21930 RBX: 952b80043300 RCX: 
> 802a001a
> [ 3566.598223] RDX: a76066effdd8 RSI: eed9a22e8840 RDI: 
> a76066effe18
> [ 3566.606189] RBP: 95430ba21900 R08: 0001 R09: 
> c0d89ecc
> [ 3566.614152] R10: 0013 R11: 0001 R12: 
> a76066effe50
> [ 3566.622114] R13: 95430ba21900 R14: eed9a22e8840 R15: 
> 95430ba21900
> [ 3566.630079] FS:  () GS:955a9fa4() 
> knlGS:
> [ 3566.639107] CS:  0010 DS:  ES:  CR0: 80050033
> [ 3566.645518] CR2: 7f255e9eb3d8 CR3: 002a6d410006 CR4: 
> 001706e0
> [ 3566.653479] Call Trace:
> [ 3566.656210]  
> [ 3566.658552]  ? __die_body.cold+0x1a/0x1f
> [ 3566.662928]  ? die+0x2a/0x50
> [ 3566.666144]  ? do_trap+0xc5/0x110
> [ 3566.669848]  ? __slab_free+0x118/0x2d0
> [ 3566.674029]  ? do_error_trap+0x6a/0x90
> [ 3566.678211]  ? __slab_free+0x118/0x2d0
> [ 3566.682393]  ? exc_invalid_op+0x4c/0x60
> [ 3566.686676]  ? __slab_free+0x118/0x2d0
> [ 3566.690857]  ? asm_exc_invalid_op+0x16/0x20
> [ 3566.695529]  ? nf_tables_trans_destroy_work+0x1cc/0x250 [nf_tables]
> [ 3566.702532]  ? __slab_free+0x118/0x2d0
> [ 3566.706714]  ? obj_cgroup_uncharge_pages+0xd0/0xd0
> [ 3566.712066]  nf_tables_trans_destroy_work+0x1cc/0x250 [nf_tables]
> [ 3566.718874]  process_one_work+0x1c7/0x380
> [ 3566.723351]  worker_thread+0x4d/0x380
> [ 3566.727436]  ? rescuer_thread+0x3a0/0x3a0
> [ 3566.731908]  kthread+0xda/0x100
> [ 3566.735417]  ? kthread_complete_and_exit+0x20/0x20
> [ 3566.740763]  ret_from_fork+0x22/0x30
> [ 3566.744759]  
> [ 3566.747195] Modules linked in: xt_conntrack xt_MASQUERADE 
> nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter 
> bridge 8021q garp stp mrp llc overlay bonding tls nft_nat nft_chain_nat 
> nf_nat nft_log qrtr nft_limit nft_ct nf_conntrack nf_defrag_ipv6 
> nf_defrag_ipv4 nf_tables libcrc32c nfnetlink_log nfnetlink binfmt_misc 
> intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal 
> intel_powerclamp nls_ascii nls_cp437 coretemp kvm_intel vfat fat kvm 
> ipmi_ssif irqbypass ghash_clmulni_intel sha512_ssse3 sha512_generic 
> sha256_ssse3 sha1_ssse3 aesni_intel crypto_simd cryptd ipmi_si iTCO_wdt rapl 
> intel_pmc_bxt ipmi_devintf joydev intel_cstate iTCO_vendor_support 
> ipmi_msghandler sg acpi_power_meter watchdog intel_uncore mei_me mei pcspkr 
> evdev parport_pc ppdev lp parport efi_pstore dm_mod fuse loop configfs 
> efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic 
> hid_generic usbhid hid sr_mod cdrom sd_mod t10_pi crc64_rocksoft crc64 
> crc_t10dif
> [ 3566.747268]  crct10dif_generic mgag200 i2c_algo_bit drm_shmem_helper ahci 
> drm_kms_helper libahci ehci_pci ehci_hcd libata crct10dif_pclmul megaraid_sas 
> drm crct10dif_common crc32_pclmul crc32c_intel usbcore tg3 scsi_mod lpc_ich 
> libphy usb_common scsi_common wmi button
> [ 3566.870202] ---[ end trace  ]---
> [ 3566.878075] RIP: 0010:__slab_free+0x118/0x2d0
> [ 3566.882954] Code: 74 35 49 8b 06 48 89 4c 24 20 48 c1 e8 36 4c 8b a4 c3 d8 
> 00 00 00 4c 89 e7 e8 74 6a 71 00 48 8b 4c 24 20 48 89 44 24 18 eb 8f <0f> 0b 
> f7 43 08 00 0d 21 00 75 cd eb c6 80 4c 24 53 80 e9 75 ff ff
> [ 3566.903925] RSP: 0018:a76066effdb0 EFLAGS: 00010246
> [ 3566.909772] RAX: 95430ba21930 RBX: 952b80043300 RCX: 
> 802a001a
> [ 3566.917752] RDX: a76066effdd8 RSI: eed9a22e8840 RDI: 
> a76066effe18
> [ 3566.925747] RBP: 95430ba21900 R08: 0001 R09: 
> c0d89ecc
> [ 3566.933714] R10: 0013 R11: 0001 R12: 
> a76066effe50
> [ 3566.941694] R13: 95430ba21900 R14: eed9a22e8840 R15: 
> 95430ba21900
> [ 3566.949670] FS:  () 

Bug#1060084: puppet-agent: Resource type 'Cron' was not found, even after puppet-module-puppetlabs-cron-core installed

2024-01-05 Thread Will Partain
Package: puppet-agent
Version: 7.23.0-1
Severity: important

Dear Maintainer,

(This is a more detailed version of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054664 )

Did: apt install puppet-agent puppetserver puppetdb

Ended up with, inter alia:

ii  puppet-agent7.23.0-1   
ii  puppet-module-puppetlabs-augeas-core1.1.2-1
ii  puppet-module-puppetlabs-cron-core  1.1.0+dfsg1-1  
ii  puppet-module-puppetlabs-host-core  1.1.0-1
ii  puppet-module-puppetlabs-mount-core 1.0.4+dfsg1-2  
ii  puppet-module-puppetlabs-selinux-core   1.2.0-1
ii  puppet-module-puppetlabs-sshkeys-core   2.3.0-1
ii  puppetdb7.12.1-3   
ii  puppetserver7.9.5-2

Invoked puppet-agent against a "legacy" server:

   /usr/bin/puppet agent --server parple-pup1.parple.org --test 
--certname=parple-pup2.parple.org --environment=prodnew --diff_args=-U1 --noop 
--debug

It received "work" from the server, and started doing things, until it needed 
'Cron'... (the debugging log just before that...):

  Debug: /Package[apticron]: Provider apt does not support features 
install_only; not managing attribute install_only
  Debug: /Package[logrotate]: Provider apt does not support features 
targetable; not managing attribute command
  Debug: /Package[logrotate]: Provider apt does not support features 
install_only; not managing attribute install_only
  Error: Failed to apply catalog: Resource type 'Cron' was not found

The full debugging info gives no hint of what it is failing to find, or what 
might not be working like expected.  Puppet without 'cron' resources is of, uh, 
limited value.

Thanks for your help, or any insight.

Will

-- System Information:
Debian Release: 12.4
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.2.0-39-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages puppet-agent depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  facter 4.3.0-2
ii  hiera  3.10.0-1
ii  init-system-helpers1.65.2
ii  ruby   1:3.1
ii  ruby-augeas1:0.5.0+gem-1
ii  ruby-concurrent1.1.6+dfsg-5
ii  ruby-deep-merge1.1.1-2
ii  ruby-semantic-puppet   1.0.4-1
ii  ruby-shadow2.5.1-1
ii  ruby-sorted-set1.0.3-3

Versions of packages puppet-agent recommends:
ii  augeas-tools   1.14.0-1
ii  debconf-utils  1.5.82
ii  lsb-release12.0-1
ii  ruby-selinux   3.4-1+b6

Versions of packages puppet-agent suggests:
pn  hiera-eyaml
ii  puppet-module-puppetlabs-augeas-core   1.1.2-1
ii  puppet-module-puppetlabs-cron-core 1.1.0+dfsg1-1
ii  puppet-module-puppetlabs-host-core 1.1.0-1
ii  puppet-module-puppetlabs-mount-core1.0.4+dfsg1-2
ii  puppet-module-puppetlabs-selinux-core  1.2.0-1
ii  puppet-module-puppetlabs-sshkeys-core  2.3.0-1
pn  puppet-module-puppetlabs-stdlib
ii  ruby-hocon 1.3.1-2
pn  ruby-msgpack   

-- debconf information excluded



Bug#1060085: cpio: install programs into /usr/bin

2024-01-05 Thread Chris Hofstaedtler
Source: cpio
Version: 2.14+dfsg-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

cpio installs its programs into /bin. For the ongoing Debian
UsrMerge effort [1] these should move to /usr/bin in the trixie
cycle.

I'm attaching a relatively trivial patch. Please apply it at your
earliest convenience.
I don't expect any problems with it, feel free to upload it directly
to unstable.

If during the trixie cycle your package will undergo structural
changes or any other file moves, please see the wiki and upload to
experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru cpio-2.14+dfsg/debian/changelog cpio-2.14+dfsg/debian/changelog
--- cpio-2.14+dfsg/debian/changelog	2023-12-22 06:38:54.0 +0100
+++ cpio-2.14+dfsg/debian/changelog	2024-01-05 20:13:43.0 +0100
@@ -1,3 +1,10 @@
+cpio (2.14+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install programs into /usr. (Closes: #-1)
+
+ -- Chris Hofstaedtler   Fri, 05 Jan 2024 20:13:43 +0100
+
 cpio (2.14+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru cpio-2.14+dfsg/debian/rules cpio-2.14+dfsg/debian/rules
--- cpio-2.14+dfsg/debian/rules	2023-12-22 06:32:40.0 +0100
+++ cpio-2.14+dfsg/debian/rules	2024-01-05 20:13:40.0 +0100
@@ -33,7 +33,7 @@
 	cd obj && ../configure $(shell dpkg-buildflags --export=configure) --prefix=/usr --enable-mt $(CROSS) \
 	   --mandir=/usr/share/man \
 	   --infodir=/usr/share/info \
-	   --bindir=/bin \
+	   --bindir=/usr/bin \
 	   --libexecdir=/usr/sbin
 
 	touch tests/testsuite tests/package.m4
@@ -73,19 +73,19 @@
 		debian/prerm debian/tmp/DEBIAN/.
 # Install directories
 	$(INSTALL_DIR) 	\
-		debian/tmp/bin	\
+		debian/tmp/usr/bin	\
 		debian/tmp/usr/share/man/man1	\
 		debian/tmp/usr/share/info
 # Install files
 	$(MAKE) -C obj install DESTDIR=$(CURDIR)/debian/tmp
 	rm -rf debian/tmp/usr/libexec
 	rm -rf debian/tmp/usr/share/man/man8/rmt.8
-	mv debian/tmp/bin/mt debian/tmp/bin/mt-gnu
+	mv debian/tmp/usr/bin/mt debian/tmp/usr/bin/mt-gnu
 	mv debian/tmp/usr/share/man/man1/mt.1 \
 	  debian/tmp/usr/share/man/man1/mt-gnu.1
 # Strip binaries (including hack by policy wonks)
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-	$(STRIP) -R.note -R.comment debian/tmp/bin/*
+	$(STRIP) -R.note -R.comment debian/tmp/usr/bin/*
 endif
 	rm -rf debian/tmp/usr/sbin
 # Install documentation
@@ -100,7 +100,7 @@
 	rm -rf debian/tmp/usr/share/info
 	install -m 644 debian/copyright debian/tmp/usr/share/doc/$(package)/.
 # Determine shared library dependencies
-	dpkg-shlibdeps debian/tmp/bin/cpio debian/tmp/bin/mt-gnu
+	dpkg-shlibdeps debian/tmp/usr/bin/cpio debian/tmp/usr/bin/mt-gnu
 
 # Generate md5sums
 	cd debian/tmp && find * -type f ! -regex '^DEBIAN/.*' -print0 | LC_ALL=C sort -z | xargs -r0 md5sum > DEBIAN/md5sums


Bug#1059929: release.debian.org: gobject-introspection_1.78.1-9 is said to have an unsatisfiable dependency

2024-01-05 Thread Paul Gevers

Hi,

Thanks for reaching out.

On 05-01-2024 07:45, Johannes Schauer Marin Rodrigues wrote:

It would generate the following two stubs (shortened here for brevity):

Package: pkga
Version: 1
Architecture: amd64
Depends: pkgc:any
Multi-Arch: no

Package: pkgb
Version: 1
Architecture: amd64
Provides: pkgc
Multi-Arch: allowed


For britney2, the Sources stanza would also be needed; then we could use 
this to generate britney2 testcases. I created 10 of those yesterday by 
hand [1].


The simplest for of tests is a tree with
var/data/unstable/Sources
# i386 is the default archive of the testsuite, which can be overruled
# if that makes sense
var/data/unstable/Packages_i386
var/data/testing/Sources (may be empty)
var/data/testing/Packages_i386
expected

expected is in Heidi format (if I understand correctly) of what britney2 
will allow to be in testing after the run, it will only migrate packages 
that are installable.


Would it make sense to you to generate a branch in that archive with a 
bunch of tests that you know the answer too?


Paul

[1] 
https://salsa.debian.org/debian/britney2-tests/-/commit/5ab98de685e15a654227e9b188a48e44857f9d11


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#967565: [Pkg-electronics-devel] Bug#967565: lepton-eda: depends on deprecated GTK 2

2024-01-05 Thread Bastian Germann

With both autotools and meson buildsystems, the gtksheet-4.0/gtksheet include 
path is intentional.
Mageia is the only other Linux system that I found a gtksheet package on
and they also install the files as intended by the build system, so we should 
rather not deviate.



Bug#877016: Time to drop cpufrequtils?

2024-01-05 Thread Moritz Mühlenhoff
Am Fri, Jan 05, 2024 at 12:08:54PM +0100 schrieb Chris Hofstaedtler:
> On Sun, Sep 03, 2023 at 08:26:00PM +0200, Moritz Mühlenhoff wrote:
> > severity 877016 serious
> > thanks
> > 
> > Am Thu, Sep 28, 2017 at 06:51:30AM -0700 schrieb Mattia Dongili:
> > > On Wed, Sep 27, 2017 at 03:16:52PM -0400, Phil Susi wrote:
> > > > Package: cpufrequtils
> > > > Version: 008-1
> > > ...
> > > > is the case, should cpufrequtils not be removed now?
> > > 
> > > Yes, indeed it should. Thanks for nagging.
> > 
> > Bumping the severity to RC to move forward with this for trixie.
> > 
> 
> $ dak rm -nR cpufrequtils
> Will remove the following packages from unstable:
> 
> cpufrequtils |  008-2 | source, amd64, arm64, armel, armhf, i386, 
> mips64el, s390x
> libcpufreq-dev |  008-2 | amd64, arm64, armel, armhf, i386, mips64el, 
> ppc64el, s390x
> libcpufreq-dev |   008-2+b1 | riscv64
> libcpufreq0 |  008-2 | amd64, arm64, armel, armhf, i386, mips64el, 
> ppc64el, s390x
> libcpufreq0 |   008-2+b1 | riscv64
> 
> Maintainer: Seunghun Han 
> 
> --- Reason ---
> 
> --
> 
> Checking reverse dependencies...
> No dependency problem found.
> 
> Seems like it's good to go?

Given the original bug to suggest it's removal is from 2017, I think it's safe 
to
say that anyone had a chance to object to it's removal :-)

Cheers,
Moritz



  1   2   3   >