date:20240323


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru bitlbee-3.6/debian/changelog bitlbee-3.6/debian/changelog
--- bitlbee-3.6/debian/changelog2024-03-23 21:10:13.0 +
+++ bitlbee-3.6/debian/changelog2024-03-23 21:05:25.0 +
@@ -1,3 +1,10 @@
+bitlbee (3.6-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1064217)
+
+ -- Bastian Germann   Sat, 23 Mar 2024 21:05:25 +
+
 bitlbee (3.6-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru bitlbee-3.6/debian/source/format bitlbee-3.6/debian/source/format
--- bitlbee-3.6/debian/source/format2024-03-23 21:10:13.0 +
+++ bitlbee-3.6/debian/source/format2024-03-23 21:05:25.0 +
@@ -1 +1 @@
-1.0
+3.0 (quilt)
diff -Nru bitlbee-3.6/debian/source/options bitlbee-3.6/debian/source/options
--- bitlbee-3.6/debian/source/options   2024-03-23 21:10:13.0 +
+++ bitlbee-3.6/debian/source/options   1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
---diff-ignore='(^|/)\.git'

Bug#1060407: gtkwave: diff for NMU version 3.3.118-0.1

2024-03-23 Thread Adrian Bunk

Control: tags 1060407 + patch
Control: tags 1060407 + pending

Dear maintainer,

I've prepared an NMU for gtkwave (versioned as 3.3.118-0.1) and uploaded 
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diffstat for gtkwave-3.3.116 gtkwave-3.3.118

 ChangeLog|   44 
 LICENSE.TXT  |2 
 configure|   20 +-
 configure.ac |2 
 contrib/bundle_for_osx/Info-gtkwave.plist|6 
 contrib/xml2stems/xml2stems.cc   |   20 +-
 debian/changelog |   30 +++
 share/appdata/Makefile.am|2 
 share/appdata/Makefile.in|2 
 share/appdata/gtkwave.appdata.xml|   20 --
 share/appdata/io.github.gtkwave.GTKWave.metainfo.xml |  143 ++
 src/debug.c  |   39 +++
 src/debug.h  |3 
 src/extload.c|6 
 src/globals.h|2 
 src/helpers/evcd2vcd.c   |   14 +
 src/helpers/fst/fstapi.c |  189 +--
 src/helpers/lxt2_read.c  |   96 +
 src/helpers/vcd2fst.c|   47 
 src/helpers/vcd2lxt.c|   69 ++
 src/helpers/vcd2lxt2.c   |   69 ++
 src/helpers/vcd2vzt.c|   69 ++
 src/helpers/vzt_read.c   |  109 ++
 src/libghw.c |3 
 src/liblzma/LzmaLib.c|   37 +++
 src/main.c   |4 
 src/ptranslate.c |2 
 src/savefile.c   |4 
 src/ttranslate.c |2 
 src/vcd.c|   17 +
 src/vcd_partial.c|   17 +
 src/vcd_recoder.c|   15 +
 32 files changed, 1000 insertions(+), 104 deletions(-)

diff -Nru gtkwave-3.3.116/ChangeLog gtkwave-3.3.118/ChangeLog
--- gtkwave-3.3.116/ChangeLog	2023-07-23 03:37:07.0 +0300
+++ gtkwave-3.3.118/ChangeLog	2023-12-31 23:11:04.0 +0200
@@ -1843,3 +1843,47 @@
 		Add GDK_WINDOWING_WAYLAND check for gdkwayland.h header usage.
 		Changed	sprintf	to snprintf in fstapi.c.
 		Fix init crash on show_base_symbols enabled.
+3.3.117	08aug23	Fix stems reader processing code broken in 3.3.114.
+3.3.118 17dec23 Update xml2stems to handle newer "loc" vs "fl" xml tags.
+		Change preg_regex_c_1 decl to use regex_t* as datatype.
+		Move gtkwave.appdata.xml to 
+		io.github.gtkwave.GTKWave.metainfo.xml.
+		Fixed popen security advisories:
+		TALOS-2023-1786
+		Fixed FST security advisories:		
+		TALOS-2023-1777
+		TALOS-2023-1783
+		TALOS-2023-1785
+		TALOS-2023-1789
+		TALOS-2023-1790
+		TALOS-2023-1791
+		TALOS-2023-1792
+		TALOS-2023-1793
+		TALOS-2023-1797
+		TALOS-2023-1798
+		Fixed evcd2vcd security advisories:
+		TALOS-2023-1803
+		Fixed VCD security advisories:
+		TALOS-2023-1804
+		TALOS-2023-1805
+		TALOS-2023-1806
+		TALOS-2023-1807
+		Fixed VZT security advisories:
+		TALOS-2023-1810
+		TALOS-2023-1811
+		TALOS-2023-1812
+		TALOS-2023-1813
+		TALOS-2023-1814
+		TALOS-2023-1815
+		TALOS-2023-1816
+		TALOS-2023-1817
+		Fixed LXT2 security advisories:		
+		TALOS-2023-1818
+		TALOS-2023-1819
+		TALOS-2023-1820
+		TALOS-2023-1821
+		TALOS-2023-1822
+		TALOS-2023-1823
+		TALOS-2023-1824
+		TALOS-2023-1826
+		TALOS-2023-1827
diff -Nru gtkwave-3.3.116/configure gtkwave-3.3.118/configure
--- gtkwave-3.3.116/configure	2023-07-23 03:37:07.0 +0300
+++ gtkwave-3.3.118/configure	2023-12-31 23:11:03.0 +0200
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for gtkwave-gtk3 3.3.116.
+# Generated by GNU Autoconf 2.69 for gtkwave-gtk3 3.3.118.
 #
 # Report bugs to .
 #
@@ -580,8 +580,8 @@
 # Identity of this package.
 PACKAGE_NAME='gtkwave-gtk3'
 PACKAGE_TARNAME='gtkwave-gtk3'
-PACKAGE_VERSION='3.3.116'
-PACKAGE_STRING='gtkwave-gtk3 3.3.116'
+PACKAGE_VERSION='3.3.118'
+PACKAGE_STRING='gtkwave-gtk3 3.3.118'
 PACKAGE_BUGREPORT='byb...@rocketmail.com'
 PACKAGE_URL=''
 
@@ -1395,7 +1395,7 @@
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures gtkwave-gtk3 3.3.116 to adapt to many kinds of systems.
+\`configure' configures gtkwave-gtk3 3.3.118 to adapt to many kinds of systems.

Bug#1067572: rust-parsec-tool

2024-03-23 Thread Sebastian Andrzej Siewior

Package: rust-parsec-tool
Version: 0.7.0-3
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2

The testsuite fails with openssl 3.2. Please find attached upstream
commit 8948077e106a0 ("parsec-cli-tests.sh: adapt to new serialNumber
output") which fixes the issue.

Sebastian
From: Mikko Rapeli 
Date: Wed, 3 Jan 2024 12:30:38 +
Subject: [PATCH] parsec-cli-tests.sh: adapt to new serialNumber output

openssl 3.2.0 from yocto prints serialNumber to output
without spaces so support both that and the old with
spaces output to pass the test. Not using regular
expressions to work on simpler grep implementations.

Signed-off-by: Mikko Rapeli 
---
 tests/parsec-cli-tests.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/parsec-cli-tests.sh b/tests/parsec-cli-tests.sh
index 91ec321ca0598..3fbb961ec2400 100755
--- a/tests/parsec-cli-tests.sh
+++ b/tests/parsec-cli-tests.sh
@@ -231,7 +231,7 @@ test_csr() {
 run_cmd $OPENSSL req -text -noout -verify -in ${MY_TMP}/${KEY}.csr >${MY_TMP}/${KEY}.txt
 debug cat ${MY_TMP}/${KEY}.txt
 
-if ! cat ${MY_TMP}/${KEY}.txt | grep "Subject:" | grep "serialNumber = ${TEST_SERIAL}"; then
+if ! cat ${MY_TMP}/${KEY}.txt | grep "Subject:" | grep -e "serialNumber = ${TEST_SERIAL}" -e "serialNumber=${TEST_SERIAL}"; then
 echo "Error: The CSR does not contain the serialNumber field of the Distinguished Name"
 EXIT_CODE=$(($EXIT_CODE+1))
 fi
-- 
2.43.0

Bug#1067571: anope: suspended users can reset their passwords

2024-03-23 Thread Dominic Hargreaves

Package: anope
Version:  2.0.12-1
Severity: important
Tags security pending

A security issue was fixed in the most recent 2.0.15 release:
IRC users can evade account suspensions by resetting their password.

Bug#1007440: bfbtester: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.diff -Nru bfbtester-2.0.1/debian/changelog bfbtester-2.0.1/debian/changelog
--- bfbtester-2.0.1/debian/changelog2024-03-23 21:00:29.0 +
+++ bfbtester-2.0.1/debian/changelog2024-03-23 20:49:08.0 +
@@ -1,3 +1,11 @@
+bfbtester (2.0.1-7.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007440)
+  * d/copyright: Convert to machine-readable format.
+
+ -- Bastian Germann   Sat, 23 Mar 2024 20:49:08 +
+
 bfbtester (2.0.1-7.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru bfbtester-2.0.1/debian/copyright bfbtester-2.0.1/debian/copyright
--- bfbtester-2.0.1/debian/copyright2024-03-23 21:00:29.0 +
+++ bfbtester-2.0.1/debian/copyright2024-03-23 20:49:08.0 +
@@ -1,42 +1,39 @@
-This package was debianized by Karl Soderstrom  on
-Tue, 23 Jan 2001 14:56:14 +0100.
-
-The current Debian maintainer is Uwe Hermann .
-
-It was downloaded from: http://bfbtester.sourceforge.net
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Comment:
+ This package was debianized by Karl Soderstrom  on
+ Tue, 23 Jan 2001 14:56:14 +0100.
+Source:
+ http://bfbtester.sourceforge.net
 
+Files: *
 Copyright: 2000 Mike Heffner 
-
-License:
-
+License: GPL-2+
 This program is free software; you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation; either version 2 of the License, or
 (at your option) any later version.
-
+ .
 This program is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
-
+ .
 You should have received a copy of the GNU General Public License
 along with this program; if not, write to the Free Software
 Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
-
-Note:
-
+Comment:
 The code contains the above license note, but the COPYING file is
 actually a copy of LGPL license (not the GPL). I'll try to clarify
 this with the author.
-
-On Debian systems, the complete text of the GNU General
-Public License can be found in `/usr/share/common-licenses/GPL'.
-
-On Debian systems, the complete text of the GNU Lesser General
-Public License can be found in `/usr/share/common-licenses/LGPL'.
-
-Debian packaging copyright:
-
+ .
+ On Debian systems, the complete text of the GNU General
+ Public License v2 can be found in `/usr/share/common-licenses/GPL-2'.
+ .
+ On Debian systems, the complete text of the GNU Library General
+ Public License v2 can be found in `/usr/share/common-licenses/LGPL-2'.
+
+Files: debian/*
+Copyright: Uwe Hermann
+License: public-domain
The packaging done by Uwe Hermann  is hereby
released as public domain.
-
diff -Nru bfbtester-2.0.1/debian/source/format 
bfbtester-2.0.1/debian/source/format
--- bfbtester-2.0.1/debian/source/format1970-01-01 00:00:00.0 
+
+++ bfbtester-2.0.1/debian/source/format2024-03-23 20:49:08.0 
+
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1066983: monopd: Fails to start monopd.service

2024-03-23 Thread Sylvain Rochet

Hi Shriram,

On Sat, Mar 16, 2024 at 08:03:02PM +0530, Shriram Ravindranathan wrote:
> Package: monopd
> Version: 0.10.2-6+b2
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: s...@ters.dev
> 
> Dear Maintainer,
> 
> monopd.service fails to start (could not bind port 1234), rendering the 
> package unusable.
> 
> Mar 16 19:25:02 think182 sudo[4410]:  shriram : TTY=pts/0 ; PWD=/home/shriram 
> ; USER=root ; COMMAND=/usr/bin/apt install monopd
> Mar 16 19:25:02 think182 sudo[4410]: pam_unix(sudo:session): session opened 
> for user root(uid=0) by (uid=1000)
> Mar 16 19:25:03 think182 systemd[1]: Reloading.
> Mar 16 19:25:04 think182 systemd[1]: Reloading.
> Mar 16 19:25:04 think182 systemd[1]: Starting monopd.service - game server 
> for board games like GtkAtlantic...
> Mar 16 19:25:04 think182 systemd[1]: Listening on monopd.socket - monopd 
> listening socket.
> Mar 16 19:25:04 think182 monopd[4512]: monopd 0.10.2 started
> Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: 
> game=[Atlantic]
> Mar 16 19:25:04 think182 monopd[4512]: loaded game configuration: 
> game=[Monopoly]
> Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed to parse ERRNO= 
> field value '-2' in notification message: Numerical result out of range
> Mar 16 19:25:04 think182 monopd[4512]: could not bind port 1234, exiting
> Mar 16 19:25:04 think182 systemd[1]: monopd.service: Main process exited, 
> code=exited, status=254/n/a
> Mar 16 19:25:04 think182 systemd[1]: monopd.service: Failed with result 
> 'exit-code'.
> Mar 16 19:25:04 think182 systemd[1]: Failed to start monopd.service - game 
> server for board games like GtkAtlantic.
> Mar 16 19:25:05 think182 sudo[4410]: pam_unix(sudo:session): session closed 
> for user root

That might be related to the latest change "Add a service template for 
compatibility reasons with monopd.socket.".

Masking socket activation and enabling the service worked for me:

# systemctl stop monopd@*.service
# systemctl stop system-monopd.slice
# systemctl stop monopd.socket
# systemctl mask monopd.socket
# systemctl enable monopd.service
# systemctl start monopd.service

Kind regards,
Sylvain


signature.asc
Description: Digital signature

Bug#1007045: libmad: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru libmad-0.15.1b/debian/changelog libmad-0.15.1b/debian/changelog
--- libmad-0.15.1b/debian/changelog 2024-03-23 20:36:40.0 +
+++ libmad-0.15.1b/debian/changelog 2024-03-23 20:30:30.0 +
@@ -1,3 +1,10 @@
+libmad (0.15.1b-10.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0. (Closes: #1007045)
+
+ -- Bastian Germann   Sat, 23 Mar 2024 20:30:30 +
+
 libmad (0.15.1b-10.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libmad-0.15.1b/debian/control libmad-0.15.1b/debian/control
--- libmad-0.15.1b/debian/control   2024-03-23 20:36:40.0 +
+++ libmad-0.15.1b/debian/control   2024-03-23 20:29:43.0 +
@@ -1,7 +1,7 @@
 Source: libmad
 Priority: optional
 Section: sound
-Build-Depends: debhelper (>= 8.1.3~), gettext, cdbs (>= 0.4.93~), 
autotools-dev, quilt, dh-autoreconf
+Build-Depends: debhelper (>= 8.1.3~), gettext, cdbs (>= 0.4.93~), 
autotools-dev, dh-autoreconf
 Maintainer: Kurt Roeckx 
 Standards-Version: 3.7.3
 
diff -Nru libmad-0.15.1b/debian/rules libmad-0.15.1b/debian/rules
--- libmad-0.15.1b/debian/rules 2024-03-23 20:36:40.0 +
+++ libmad-0.15.1b/debian/rules 2024-03-23 20:29:59.0 +
@@ -9,7 +9,6 @@
 include /usr/share/dpkg/architecture.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/autotools.mk
-include /usr/share/cdbs/1/rules/patchsys-quilt.mk
 include /usr/share/cdbs/1/rules/autoreconf.mk
 
 export AUTOMAKE = automake --foreign
diff -Nru libmad-0.15.1b/debian/source/format 
libmad-0.15.1b/debian/source/format
--- libmad-0.15.1b/debian/source/format 1970-01-01 00:00:00.0 +
+++ libmad-0.15.1b/debian/source/format 2024-03-23 20:29:26.0 +
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1067350: asterisk-prompt-fr-armelle: FTBFS: cp: cannot stat './.pc/fr': No such file or directory


This was caused by my last NMU so I am fixing this with another NMU.
debdiff attached.diff -Nru asterisk-prompt-fr-armelle-20070613/debian/changelog 
asterisk-prompt-fr-armelle-20070613/debian/changelog
--- asterisk-prompt-fr-armelle-20070613/debian/changelog2024-02-17 
22:59:47.0 +
+++ asterisk-prompt-fr-armelle-20070613/debian/changelog2024-03-23 
20:17:25.0 +
@@ -1,3 +1,10 @@
+asterisk-prompt-fr-armelle (20070613-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Exclude .pc directory from find. (Closes: #1067350)
+
+ -- Bastian Germann   Sat, 23 Mar 2024 20:17:25 +
+
 asterisk-prompt-fr-armelle (20070613-2.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru asterisk-prompt-fr-armelle-20070613/debian/rules 
asterisk-prompt-fr-armelle-20070613/debian/rules
--- asterisk-prompt-fr-armelle-20070613/debian/rules2024-02-17 
22:59:37.0 +
+++ asterisk-prompt-fr-armelle-20070613/debian/rules2024-02-17 
22:59:47.0 +
@@ -29,7 +29,7 @@
dh_installdocs
 
cp -R $(LNG) debian/$(PKG_NAME)/usr/share/asterisk/sounds/
-   set -e; find . -mindepth 1 -maxdepth 1 -type d -not -name debian 
$(NO_DISTRIB_FIND_EXPR) -not -name $(LNG) | while read d; do cp -R $${d}/$(LNG) 
debian/$(PKG_NAME)/usr/share/asterisk/sounds/$(LNG)/$${d}; done
+   set -e; find . -mindepth 1 -maxdepth 1 -type d -not -name debian -not 
-name .pc $(NO_DISTRIB_FIND_EXPR) -not -name $(LNG) | while read d; do cp -R 
$${d}/$(LNG) debian/$(PKG_NAME)/usr/share/asterisk/sounds/$(LNG)/$${d}; done
 
set -e; \
( cd debian/$(PKG_NAME)/usr/share/asterisk/sounds/$(LNG)/; \

Bug#1054900: libunity: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru libunity-7.1.4+19.04.20190319/bindings/python/scope-runner-dbus.py 
libunity-7.1.4+19.04.20190319/bindings/python/scope-runner-dbus.py
--- libunity-7.1.4+19.04.20190319/bindings/python/scope-runner-dbus.py  
2024-03-23 20:02:02.0 +
+++ libunity-7.1.4+19.04.20190319/bindings/python/scope-runner-dbus.py  
2019-03-19 10:17:56.0 +
@@ -1,4 +1,4 @@
-#!/usr/bin/python2
+#!/usr/bin/python
 
 # Copyright (C) 2013 Canonical
 #
diff -Nru libunity-7.1.4+19.04.20190319/debian/changelog 
libunity-7.1.4+19.04.20190319/debian/changelog
--- libunity-7.1.4+19.04.20190319/debian/changelog  2024-03-23 
20:02:02.0 +
+++ libunity-7.1.4+19.04.20190319/debian/changelog  2024-03-23 
18:57:44.0 +
@@ -1,3 +1,14 @@
+libunity (7.1.4+19.04.20190319-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Do not mark libunity9 as Multi-Arch: same (Closes: #1037202)
+  * Drop B-D autotools-dev, dh-autoreconf (implied by debhelper compat)
+  * Move from pkg-config to pkgconf
+  * d/copyright: Use standard format specifier
+  * Convert to source format 3.0 (Closes: #1054900)
+
+ -- Bastian Germann   Sat, 23 Mar 2024 18:57:44 +
+
 libunity (7.1.4+19.04.20190319-6) unstable; urgency=medium
 
   * debian/control:
diff -Nru libunity-7.1.4+19.04.20190319/debian/clean 
libunity-7.1.4+19.04.20190319/debian/clean
--- libunity-7.1.4+19.04.20190319/debian/clean  1970-01-01 00:00:00.0 
+
+++ libunity-7.1.4+19.04.20190319/debian/clean  2024-03-23 18:57:44.0 
+
@@ -0,0 +1,8 @@
+examples/launcher.c
+extras/UnityExtras-7.0.gir
+extras/unity-extra-preview-player-client.c
+extras/unity-extra-utils.c
+extras/unity-extras-internal.h
+extras/unity-extras-internal.vapi
+extras/unity-extras.h
+extras/unity-extras.vapi
diff -Nru libunity-7.1.4+19.04.20190319/debian/control 
libunity-7.1.4+19.04.20190319/debian/control
--- libunity-7.1.4+19.04.20190319/debian/control2024-03-23 
20:02:02.0 +
+++ libunity-7.1.4+19.04.20190319/debian/control2024-03-23 
18:57:44.0 +
@@ -3,12 +3,9 @@
 Priority: optional
 Maintainer: Ayatana Packagers 
 Build-Depends: debhelper-compat (= 12),
-   dh-autoreconf,
dh-python,
gnome-common,
-   quilt,
-   autotools-dev,
-   pkg-config,
+   pkgconf,
intltool,
valac (>= 0.31.1),
libglib2.0-dev (>= 2.32.1),
@@ -31,7 +28,6 @@
 Package: libunity9
 Section: libs
 Architecture: any
-Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends},
  ${misc:Depends},
diff -Nru libunity-7.1.4+19.04.20190319/debian/copyright 
libunity-7.1.4+19.04.20190319/debian/copyright
--- libunity-7.1.4+19.04.20190319/debian/copyright  2024-03-23 
20:02:02.0 +
+++ libunity-7.1.4+19.04.20190319/debian/copyright  2024-03-23 
18:57:44.0 +
@@ -1,4 +1,4 @@
-Format: http://dep.debian.net/deps/dep5/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: libunity
 Source: https://launchpad.net/libunity/+download
 
diff -Nru libunity-7.1.4+19.04.20190319/debian/patches/debian.patch 
libunity-7.1.4+19.04.20190319/debian/patches/debian.patch
--- libunity-7.1.4+19.04.20190319/debian/patches/debian.patch   1970-01-01 
00:00:00.0 +
+++ libunity-7.1.4+19.04.20190319/debian/patches/debian.patch   2024-03-23 
18:57:44.0 +
@@ -0,0 +1,153 @@
+--- libunity-7.1.4+19.04.20190319.orig/extras/Makefile.am
 libunity-7.1.4+19.04.20190319/extras/Makefile.am
+@@ -24,6 +24,7 @@ libunity_extras_la_VALAFLAGS = \
+   --library unity-extras \
+   --internal-vapi=unity-extras-internal.vapi \
+   --internal-header=unity-extras-internal.h \
++  --shared-library=libunity-extras.so.9 \
+   --thread \
+   --use-header \
+   --vapidir $(top_srcdir)/vapi \
+@@ -82,7 +83,6 @@ $(libunity_la_GENERATED): libunity_la_va
+ 
+ libunity_extras_la_vala.stamp: $(libunity_extras_la_VALASOURCES)
+   $(AM_V_GEN) $(VALAC) $(libunity_extras_la_VALAFLAGS) $^
+-  @sed -i -e 's///g' 
UnityExtras-@GIR_VERSION@.gir
+   @sed -i -e 's/"Extras/"/g;s/"extras_/"/' UnityExtras-@GIR_VERSION@.gir
+   @sed -i -e 's/https://bugzilla.gnome.org/show_bug.cgi?id=642576
+-#
+-# The second is there because forced cname in Vala is not properly propagated
+-# into the gir file. Need https://bugzilla.gnome.org/show_bug.cgi?id=681356
+-#
+-# And the third because we need to specify scope manually.
+-#
+ libunity_la_vala.stamp: $(libunity_la_VALASOURCES)
+   $(AM_V_GEN) $(VALAC) $(libunity_la_VALAFLAGS) $^
+-  @sed -i -e 's///g' 
Unity-@GIR_VERSION@.gir
+-  @sed -i -e 's/emit_preview_ready/preview_ready/g' 
Unity-@GIR_VERSION@.gir
+-  @sed -i -e 's///;s///' Unity-@GIR_VERSION@.gir
+   @touch $@
+ 
+ BUILT_SOURCES +=

Bug#1066694: netdiag: FTBFS: getservent.c:121:38: error: implicit declaration of function ‘atoi’ [-Werror=implicit-function-declaration]

2024-03-23 Thread Micha Lenk


Dear maintainer of netdiag,

I tried to fix the build failures introduced by the recently by-default 
enabled compile flag -Werror=implicit-function-declaration.


All build errors inside the statnet sub project could be fixed by the 
attached patch statnet_fix_implicit_function_declarations.patch, 
including the implicit declaration of function `atoi`.


Unfortunately the build fails in the netwatch sub project too. Initial 
attempts to fix that can be found in the attached patch 
netwatch_fix_implicit_declarations.patch. However, for the implicitly 
declared function `uthread_wait` I have no clue what it refers to. So, I 
am stuck with the following build failure now:


make[1]: Entering directory 
'/home/micha/src/netdiag/pkg.git/netwatch-1.3.1-2'
x86_64-linux-gnu-gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/home/micha/src/netdiag/pkg.git/netwatch-1.3.1-2=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -ggdb -O0 -Wl,-z,relro 
-Wl,-z,now -c  dispdata.c

dispdata.c: In function 'dispdata':
dispdata.c:740:7: error: implicit declaration of function 
'uthread_wait'; did you mean 'pthread_exit'? 
[-Werror=implicit-function-declaration]

  740 |   uthread_wait(1000);
  |   ^~~~
  |   pthread_exit
dispdata.c:1357:48: warning: '%s' directive writing up to 511 bytes into 
a region of size 509 [-Wformat-overflow=]

 1357 | sprintf (_lines[3][3], "%s", ttt);
  |^~   ~~~
dispdata.c:1357:17: note: 'sprintf' output between 1 and 512 bytes into 
a destination of size 509

 1357 | sprintf (_lines[3][3], "%s", ttt);
  | ^~~~
cc1: some warnings being treated as errors
make[1]: *** [Makefile:40: dispdata.o] Error 1
make[1]: Leaving directory 
'/home/micha/src/netdiag/pkg.git/netwatch-1.3.1-2'

make: *** [debian/rules:36: build-stamp] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit 
status 2



A solution could be to selectively disable the 
-Werror=implicit-function-declaration option again, but having seen this 
error I don't feel comfortable moving forward in that direction.


I'll stop here, sharing the changes for how far I got already in the 
hope it is useful to any more skilled or more patient developer.


Kind regards,
MichaAuthor: Micha Lenk 

diff --git a/statnet-3.8/getservent.c b/statnet-3.8/getservent.c
index 1ee6e5e..d99874b 100644
--- a/statnet-3.8/getservent.c
+++ b/statnet-3.8/getservent.c
@@ -42,6 +42,8 @@
 static char sccsid[] = "@(#)getservent.c	8.1 (Berkeley) 6/4/93";
 #endif /* LIBC_SCCS and not lint */
 
+#include 
+
 #include "inetprivate.h"
 
 #define	MAXALIASES	35
diff --git a/statnet-3.8/itstime.c b/statnet-3.8/itstime.c
index 9cace01..ca8ecd5 100644
--- a/statnet-3.8/itstime.c
+++ b/statnet-3.8/itstime.c
@@ -8,6 +8,7 @@
 #include "stat.h"
 #include 
 #include 
+#include 
 
 extern struct StatMemStruct *StatMem;	/* pointer to shared memory segment */
 
diff --git a/statnet-3.8/stat.h b/statnet-3.8/stat.h
index 6686048..19bd2f7 100644
--- a/statnet-3.8/stat.h
+++ b/statnet-3.8/stat.h
@@ -40,6 +40,7 @@
 #define SN_PROT_PPP		163	/* Pseudo protocol for PPP */
 #define SN_PROT_LOOP		164	/* Pseudo protocol for Loopback */
 
+#include 
 #include 
 #include 
 
@@ -197,9 +198,7 @@ void set_null ( struct StatMemStruct *StatMem );
 void services ();
 void stat_delta ( struct StatMemStruct *New, struct StatMemStruct *Prev, struct StatMemStruct *Delta );
 void usage (char *arg);
-#ifdef WINDOW
-void win_show_stat( WINDOW *win, int X, int Y, int noframes, struct Tally *Now_ts, struct Tally *Prev_ts, struct Tally *Delta_ts, short rewrite_labels, short *update_labels, void *show_labels );
-#endif
+void win_show_stat( WINDOW *win, int X, int Y, int noframes, struct Tally *Now_ts, struct Tally *Prev_ts, struct Tally *Delta_ts, short rewrite_labels, short *update_labels, void *show_labels() );
 
 void tally_delta ( struct Tally *New_t, 
 	struct Tally *Prev_t, 
@@ -226,10 +225,9 @@ void tally_ntoh ( int bytecode,
 struct Tally *New_t, 
 struct Tally *Prev_t );
 
-#ifdef WINDOW
 void tally_label ( struct Tally *Now_ts, WINDOW *win, int width, int height );
-#endif
 
+int tally (int type_wanted, struct Tally *tally);
 
 /* Now some redefinitions of  stuff.  With the Berkeley notice... */
 
diff --git a/statnet-3.8/win_show_stat.c b/statnet-3.8/win_show_stat.c
index b7981b5..041a23c 100644
--- a/statnet-3.8/win_show_stat.c
+++ b/statnet-3.8/win_show_stat.c
@@ -4,6 +4,7 @@
 /* 05FEB98: Scot E. Wilcoxon (sewi...@fieldday.mn.org)  */
 
 #include 
+#include 
 #include "stat.h"
 #include "curs.h"
 
Author: Micha Lenk 

diff --git a/netwatch-1.3.1-2/netwatch.h b/netwatch-1.3.1-2/netwatch.h
index c2fd4b7..7d46b3a 100644
--- a/netwatch-1.3.1-2/netwatch.h
+++ b/netwatch-1.3.1-2/netwatch.h
@@ -214,10

Bug#1067568: emacs-pdf-tools: [time_t] Remove hardcoded dependency on libpoppler-glib8

2024-03-23 Thread Jeremy Sowden

On 2024-03-23, at 20:22:53 +0100, Julian Andres Klode wrote:
> Package: emacs-pdf-tools
> Version: 1.1.0-1
> Severity: serious
> Tags: patch
> X-Debbugs-Cc: juli...@ubuntu.com
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu noble ubuntu-patch
> 
> *** /tmp/tmpjxu2sdja/bug_body
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Remove hardcoded libpoppler-glib8 dependency
> 
> libpoppler-glib8 becomes libpoppler-glib8t64, and the dependency is no
> longer needed.
> 
> Thanks for considering the patch.
> 
> *** /tmp/tmpjxu2sdja/emacs-pdf-tools_1.1.0-1ubuntu1.debdiff
> diff -Nru emacs-pdf-tools-1.1.0/debian/control 
> emacs-pdf-tools-1.1.0/debian/control
> --- emacs-pdf-tools-1.1.0/debian/control  2024-02-29 07:25:51.0 
> +0100
> +++ emacs-pdf-tools-1.1.0/debian/control  2024-03-23 20:19:34.0 
> +0100
> @@ -1,8 +1,7 @@
>  Source: emacs-pdf-tools
>  Section: editors
>  Priority: optional
> -Maintainer: Ubuntu Developers 
> -XSBC-Original-Maintainer: Debian Emacsen team 
> 
> +Maintainer: Debian Emacsen team 
>  Uploaders: Rémi Vanicat ,
>   Aymeric Agon-Rambosson ,
>  Build-Depends: debhelper-compat (= 13),
> @@ -30,7 +29,7 @@
>  
>  Package: elpa-pdf-tools-server
>  Architecture: any
> -Depends: libpoppler-glib8 (>= 20.09.0~), ${misc:Depends}, ${shlibs:Depends}
> +Depends: ${misc:Depends}, ${shlibs:Depends}
>  Description: server for Emacs's pdf-tools
>   This package contain the server needed by elpa-pdf-tools to transform
>   pdf into png to be displayed by Emacs.

Makes sense.  Will apply and upload.

J.

> -- System Information:
> Debian Release: trixie/sid
>   APT prefers noble
>   APT policy: (500, 'noble'), (500, 'mantic-security')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#1067570: freeipa: [time_t] Replace hardcoded librpm9 depends

Package: freeipa
Version: 4.10.2-2
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch


*** /tmp/tmpy02tel37/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Replace hardcoded librpm9 depends

This is librpm9t64 now, and this makes the package binNMUable (well
don't know if Arch: all is binNMUable, anyway, this is better than
hardcoding)

Thanks for considering the patch.

*** /tmp/tmpy02tel37/freeipa_4.10.2-2ubuntu1.debdiff
diff -Nru freeipa-4.10.2/debian/control freeipa-4.10.2/debian/control
--- freeipa-4.10.2/debian/control   2024-03-04 18:55:50.0 +0100
+++ freeipa-4.10.2/debian/control   2024-03-23 20:45:20.0 +0100
@@ -1,8 +1,7 @@
 Source: freeipa
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian FreeIPA Team 

+Maintainer: Debian FreeIPA Team 
 Uploaders: Timo Aaltonen 
 Standards-Version: 4.5.0
 Vcs-Git: https://salsa.debian.org/freeipa-team/freeipa.git
@@ -23,6 +22,7 @@
  libldap2-dev,
  libnspr4-dev,
  libpopt-dev,
+ librpm-dev,
  libsasl2-dev,
  libssl-dev,
  libtalloc-dev,
@@ -172,7 +172,6 @@
  gpg,
  gpg-agent,
  keyutils,
- librpm9,
  python3-cffi,
  python3-cryptography,
  python3-dbus,
@@ -194,6 +193,7 @@
  ${misc:Depends},
  ${python3:Depends},
  ${shlibs:Depends},
+ ${lib:Depends},
 Description: FreeIPA centralized identity framework -- shared Python3 modules
  FreeIPA is an integrated solution to provide centrally managed Identity
  (machine, user, virtual machines, groups, authentication credentials), Policy
diff -Nru freeipa-4.10.2/debian/rules freeipa-4.10.2/debian/rules
--- freeipa-4.10.2/debian/rules 2023-10-18 11:46:40.0 +0200
+++ freeipa-4.10.2/debian/rules 2024-03-23 20:45:18.0 +0100
@@ -126,6 +126,11 @@
chmod 0700 $(CURDIR)/debian/freeipa-server/var/lib/ipa/backup; \
fi
 
+override_dh_gencontrol:
+   dh_gencontrol -- \
+ -Vlib:Depends=$(shell dpkg-query -W -f '$${Depends}' librpm-dev \
+   | sed -E 's/.*(librpm[[:alnum:].-]+).*/\1/')
+
 %:
dh $@ --with python3
 #  --builddirectory=build


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

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

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

Bug#1067569: RFS: libsmb2/4.0.0-1 [ITP]-- SMB2/3 client library

2024-03-23 Thread Joe Mondloch

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package “libsmb2":

* Package name : libsmb2
   Version  : 4.0.0-1
   Upstream contact : Ronnie Sahlberg https://github.com/sahlberg/libsmb2
* License  : LGPL-2.1+
* Vcs  : https://mentors.debian.net/package/libsmb2/
   Section  : libs

The source builds the following binary packages:

  libsmb2 - SMB2/3 client library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libs/libsmb2/libsmb2_4.0.0-1.dsc

Changes since the last upload:

Regards,
Joe

Bug#1067175: exaile: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

Package: exaile
Followup-For: Bug #1067175
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch




*** /tmp/tmpzxivfv1g/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Drop hardcoded libgtk-3-0 dependency; gir1.2-gtk-3.0 gets the right one


Thanks for considering the patch.

*** /tmp/tmpzxivfv1g/exaile_4.1.3+dfsg-2ubuntu1.debdiff
diff -Nru exaile-4.1.3+dfsg/debian/control exaile-4.1.3+dfsg/debian/control
--- exaile-4.1.3+dfsg/debian/control2024-03-19 07:09:54.0 +0100
+++ exaile-4.1.3+dfsg/debian/control2024-03-23 20:30:18.0 +0100
@@ -1,8 +1,7 @@
 Source: exaile
 Section: sound
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: luzip665 
+Maintainer: luzip665 
 Build-Depends: debhelper-compat (= 13), python3 (>= 3.6), python3-sphinx (>= 
1.6), python3-gi-cairo (>=3.26), help2man
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
@@ -13,7 +12,6 @@
 Depends:
  python3 (>= 3.6),
  python3-bsddb3 (>=6.1),
- libgtk-3-0 (>= 3.22),
  gstreamer1.0-plugins-good (>=1.14),
  python3-mutagen (>=1.38),
  python3-gi-cairo (>=3.26),


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

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

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

Bug#1067568: emacs-pdf-tools: [time_t] Remove hardcoded dependency on libpoppler-glib8

Package: emacs-pdf-tools
Version: 1.1.0-1
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmpjxu2sdja/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove hardcoded libpoppler-glib8 dependency

libpoppler-glib8 becomes libpoppler-glib8t64, and the dependency is no
longer needed.

Thanks for considering the patch.

*** /tmp/tmpjxu2sdja/emacs-pdf-tools_1.1.0-1ubuntu1.debdiff
diff -Nru emacs-pdf-tools-1.1.0/debian/control 
emacs-pdf-tools-1.1.0/debian/control
--- emacs-pdf-tools-1.1.0/debian/control2024-02-29 07:25:51.0 
+0100
+++ emacs-pdf-tools-1.1.0/debian/control2024-03-23 20:19:34.0 
+0100
@@ -1,8 +1,7 @@
 Source: emacs-pdf-tools
 Section: editors
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Emacsen team 
+Maintainer: Debian Emacsen team 
 Uploaders: Rémi Vanicat ,
  Aymeric Agon-Rambosson ,
 Build-Depends: debhelper-compat (= 13),
@@ -30,7 +29,7 @@
 
 Package: elpa-pdf-tools-server
 Architecture: any
-Depends: libpoppler-glib8 (>= 20.09.0~), ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: server for Emacs's pdf-tools
  This package contain the server needed by elpa-pdf-tools to transform
  pdf into png to be displayed by Emacs.


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

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

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

Bug#1067567: dhcp-probe: [time_t] Remove hardcoded dependencies on libpcap0.8, libnet, shlibs takes care of them

Package: dhcp-probe
Version: 1.3.0-10.1
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmp9u3imu66/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove hardcoded libpcap0.8, libnet1 dependencies; shlibs adds right ones

libpcap0.8 becomes libpcap0.8t64, hence it fails to install and the
package is not binNMUable.

Thanks for considering the patch.

*** /tmp/tmp9u3imu66/dhcp-probe_1.3.0-10.1ubuntu1.debdiff
diff -Nru dhcp-probe-1.3.0/debian/control dhcp-probe-1.3.0/debian/control
--- dhcp-probe-1.3.0/debian/control 2018-04-03 14:19:19.0 +0200
+++ dhcp-probe-1.3.0/debian/control 2024-03-23 20:16:10.0 +0100
@@ -1,15 +1,14 @@
 Source: dhcp-probe
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Laurent Guignard 
+Maintainer: Laurent Guignard 
 Build-Depends: debhelper (>= 7), quilt, autotools-dev, libpcap-dev (>= 0.9), 
libnet1-dev (>= 1.1.2.1-3), dpkg-dev (>=1.15.4), dh-autoreconf
 Standards-Version: 3.9.2
 Homepage: http://www.net.princeton.edu/software/dhcp_probe/
 
 Package: dhcp-probe
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, libpcap0.8 (>= 0.9), libnet1 
(>= 1.1.2.1-3), net-tools
+Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, net-tools
 Description: network DHCP or BootP server discover
  dhcp_probe attempts to discover DHCP and BootP servers on a directly-attached
  Ethernet network. A network administrator can use this tool to locate un-


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

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

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

Bug#1067566: Do not hardcode dependency on libhamlib4

Package: cqrlog
Version: 2.5.2-3
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmpb0h60c58/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Don't hardcode libhamlib4 dependency, determine from libhamlib-dev

As libhamlib4 becomes libhamlib4t64 in the time_t transition, and we
want this package to become binNMUable.

Thanks for considering the patch.

*** /tmp/tmpb0h60c58/cqrlog_2.5.2-3ubuntu1.debdiff
diff -Nru cqrlog-2.5.2/debian/control cqrlog-2.5.2/debian/control
--- cqrlog-2.5.2/debian/control 2024-03-08 05:08:51.0 +0100
+++ cqrlog-2.5.2/debian/control 2024-03-22 16:53:55.0 +0100
@@ -1,8 +1,7 @@
 Source: cqrlog
 Section: hamradio
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Hamradio Maintainers 

+Maintainer: Debian Hamradio Maintainers 
 Uploaders:
  Petr Hlozek ,
 Build-Depends:
@@ -36,9 +35,9 @@
  default-mysql-client-core | virtual-mysql-client-core,
  default-mysql-server-core | virtual-mysql-server-core,
  libhamlib-utils,
- libhamlib4,
  libmariadb-dev-compat,
  ${misc:Depends},
+ ${lib:Depends},
  ${shlibs:Depends},
 Breaks: cqrlog-data (<< 2.5.2-2)
 Replaces: cqrlog-data (<< 2.5.2-2)
diff -Nru cqrlog-2.5.2/debian/rules cqrlog-2.5.2/debian/rules
--- cqrlog-2.5.2/debian/rules   2022-09-07 11:59:57.0 +0200
+++ cqrlog-2.5.2/debian/rules   2024-03-22 16:53:55.0 +0100
@@ -2,3 +2,10 @@
 
 %:
dh $@
+
+
+override_dh_gencontrol:
+   dh_gencontrol -- \
+ -Vlib:Depends=$(shell dpkg-query -W -f '$${Depends}' 
libhamlib-dev \
+   | sed -E 's/.*(libhamlib[[:alnum:].-]+).*/\1/')
+


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

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

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

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

2024-03-23 Thread Carsten Schoenert


Am 23.03.24 um 18:29 schrieb Matthias Geiger:

I agree that packaging all themes is doable. However, how would I create
a src: package with different upstream tarballs? I could use some help
with that. Providing a virtual package for all themes is also a good idea.


To me you don't need multiple tarballs to archive the goal, you could 
add all the various sources into one tarball. Using so called component 
tarballs brings no gain to me, the usage of them also have 
disadvantages. How these tarballs are getting used did Raphael Herzog 
explain in one of his blog posts [1].


I think you can go like this, arrange the folders and finally create a 
tarball of the top folder.



.
├── kicad-theme1
├── kicad-theme2
├── kicad-theme3
└── kicad-theme...


The creation of this tarball can be done by a script living in the 
debian/ folder. Adding later another theme is simply adding one more 
folder and adjusting d/rules, d/copyright and sequencers maybe.


If you want to create various binary packages adding a new themes will 
require a new binary upload to NEW then. This is no issue, such uploads 
get processed much quicker than a complete new src package.



Would you be ok with this package being maintained under the Electronics
Team ?


Sure, why not. Would be quite logical to place it here.

[1] 
https://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/


--
Regards
Carsten

Bug#1067174: cpupower-gui: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

Package: cpupower-gui
Followup-For: Bug #1067174
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch




*** /tmp/tmpedc6k3en/bug_body

In Ubuntu, the attached patch was applied to achieve the following:


  * Drop unnecessary libgtk-3-0 dependency, gir1.2-gtk-3.0 pulls it in.


Thanks for considering the patch.

*** /tmp/tmpedc6k3en/cpupower-gui_0.7.2-2.1ubuntu1.debdiff
diff -Nru cpupower-gui-0.7.2/debian/control cpupower-gui-0.7.2/debian/control
--- cpupower-gui-0.7.2/debian/control   2024-03-19 07:08:56.0 +0100
+++ cpupower-gui-0.7.2/debian/control   2024-03-23 19:59:13.0 +0100
@@ -1,8 +1,7 @@
 Source: cpupower-gui
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Evangelos Rigas 
+Maintainer: Evangelos Rigas 
 Build-Depends: debhelper-compat (= 12),
  meson (>= 0.50.0),
  ninja-build,
@@ -20,7 +19,7 @@
 
 Package: cpupower-gui
 Architecture: any
-Depends: libgtk-3-0, gir1.2-gtk-3.0, python3-gi, hicolor-icon-theme,
+Depends: gir1.2-gtk-3.0, python3-gi, hicolor-icon-theme,
  policykit-1, python3-dbus, ${misc:Depends}, ${python3:Depends}
 Suggests: policykit-1-gnome, lxqt-policykit, mate-polkit, lxsession
 Description: GUI utility to change the CPU frequency


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

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

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

Bug#1067173: clearlooks-phenix-theme: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

Package: clearlooks-phenix-theme
Followup-For: Bug #1067173
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch


*** /tmp/tmpsylwqvoq/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove unneccessary libgtk-3-0 depends. This should have been a Breaks
of the old unsupported version instead...


Thanks for considering the patch.

*** /tmp/tmpsylwqvoq/clearlooks-phenix-theme_7.0.1-3ubuntu1.debdiff
diff -Nru clearlooks-phenix-theme-7.0.1/debian/control 
clearlooks-phenix-theme-7.0.1/debian/control
--- clearlooks-phenix-theme-7.0.1/debian/control2024-03-19 
07:08:49.0 +0100
+++ clearlooks-phenix-theme-7.0.1/debian/control2024-03-23 
19:56:31.0 +0100
@@ -1,8 +1,7 @@
 Source: clearlooks-phenix-theme
 Section: gnome
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Desktop Theme Team 

+Maintainer: Debian Desktop Theme Team 

 Uploaders: Jeremy Bicha 
 Standards-Version: 4.2.1
 Build-Depends: debhelper (>= 11)
@@ -12,7 +11,7 @@
 
 Package: clearlooks-phenix-theme
 Architecture: all
-Depends: libgtk-3-0 (>= 3.20), ${misc:Depends}
+Depends: ${misc:Depends}
 Recommends: gtk2-engines
 Description: GTK3 port of Clearlooks theme
  Clearlooks-Phénix is a GTK3 theme which is a port of Clearlooks, the


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

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

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

Bug#1007086: pentaho-reporting-flow-engine: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 with the attached changes applied in order 
to fix this.diff -Nru pentaho-reporting-flow-engine-0.9.4/debian/README.source 
pentaho-reporting-flow-engine-0.9.4/debian/README.source
--- pentaho-reporting-flow-engine-0.9.4/debian/README.source2024-03-23 
18:27:37.0 +
+++ pentaho-reporting-flow-engine-0.9.4/debian/README.source1970-01-01 
00:00:00.0 +
@@ -1,9 +0,0 @@
-Patch System
-
-
-This package uses quilt to manage all modifications to the upstream
-source. Changes are stored in the source package as diffs in
-debian/patches and applied during the build.
-
-See /usr/share/doc/quilt/README.source for a detailed explanation.
-
diff -Nru pentaho-reporting-flow-engine-0.9.4/debian/changelog 
pentaho-reporting-flow-engine-0.9.4/debian/changelog
--- pentaho-reporting-flow-engine-0.9.4/debian/changelog2024-03-23 
18:27:37.0 +
+++ pentaho-reporting-flow-engine-0.9.4/debian/changelog2024-03-23 
18:23:01.0 +
@@ -1,3 +1,11 @@
+pentaho-reporting-flow-engine (0.9.4-5.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Convert to source format 3.0 (closes: #1007086)
+  * Apply formerly ignored quilt series (closes: #1022105)
+
+ -- Bastian Germann   Sat, 23 Mar 2024 18:23:01 +
+
 pentaho-reporting-flow-engine (0.9.4-5.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru pentaho-reporting-flow-engine-0.9.4/debian/control 
pentaho-reporting-flow-engine-0.9.4/debian/control
--- pentaho-reporting-flow-engine-0.9.4/debian/control  2024-03-23 
18:27:37.0 +
+++ pentaho-reporting-flow-engine-0.9.4/debian/control  2024-03-23 
18:21:41.0 +
@@ -24,8 +24,7 @@
  docbook-xml,
  libbase-java,
  libcommons-logging-java,
- javahelper,
- quilt
+ javahelper
 Standards-Version: 3.9.8
 Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-java/pentaho-reporting-flow-engine.git
 Vcs-Git: 
https://anonscm.debian.org/git/pkg-java/pentaho-reporting-flow-engine.git
diff -Nru pentaho-reporting-flow-engine-0.9.4/debian/source/format 
pentaho-reporting-flow-engine-0.9.4/debian/source/format
--- pentaho-reporting-flow-engine-0.9.4/debian/source/format1970-01-01 
00:00:00.0 +
+++ pentaho-reporting-flow-engine-0.9.4/debian/source/format2024-03-23 
18:22:10.0 +
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#1007672: poe.app: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru poe.app-0.5.1/debian/README.source poe.app-0.5.1/debian/README.source
--- poe.app-0.5.1/debian/README.source  2024-03-23 18:14:40.0 +
+++ poe.app-0.5.1/debian/README.source  1970-01-01 00:00:00.0 +
@@ -1,8 +0,0 @@
-This package uses quilt (in a fairly standard/straightforward way) to
-manage all modifications to the upstream source.  Please see
-
-  /usr/share/doc/quilt/README.source and quilt(1)
-
-for further instructions.
-
- -- Yavor Doganov , Thu,  1 Jul 2010 13:01:27 +0300
diff -Nru poe.app-0.5.1/debian/changelog poe.app-0.5.1/debian/changelog
--- poe.app-0.5.1/debian/changelog  2024-03-23 18:14:40.0 +
+++ poe.app-0.5.1/debian/changelog  2024-03-23 18:11:15.0 +
@@ -1,3 +1,10 @@
+poe.app (0.5.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to source format 3.0 (Closes: #1007672).
+
+ -- Bastian Germann   Sat, 23 Mar 2024 18:11:15 +
+
 poe.app (0.5.1-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru poe.app-0.5.1/debian/control poe.app-0.5.1/debian/control
--- poe.app-0.5.1/debian/control2024-03-23 18:14:40.0 +
+++ poe.app-0.5.1/debian/control2024-03-23 18:09:00.0 +
@@ -4,7 +4,6 @@
 Maintainer: Debian GNUstep maintainers 

 Uploaders: Yavor Doganov 
 Build-Depends: debhelper (>= 11),
-  quilt,
   libgnustep-gui-dev,
   libvorbis-dev,
   imagemagick
diff -Nru poe.app-0.5.1/debian/rules poe.app-0.5.1/debian/rules
--- poe.app-0.5.1/debian/rules  2024-03-23 18:14:40.0 +
+++ poe.app-0.5.1/debian/rules  2024-03-23 18:09:34.0 +
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 #export DH_VERBOSE=1
 
-include /usr/share/quilt/quilt.make
 include /usr/share/GNUstep/debian/config.mk
 
 export GNUSTEP_MAKEFILES := $(GS_MAKE_DIR)
@@ -13,7 +12,7 @@
 optim := debug=yes
 endif
 
-build: patch build-stamp
+build: build-stamp
 
 build-stamp:
dh_testdir
@@ -21,9 +20,7 @@
convert Resources/GNUstep/Poe.tiff -resize 32x32 Poe.xpm
touch $@
 
-clean: clean-patched unpatch
-
-clean-patched:
+clean:
dh_testdir
dh_testroot
$(MAKE) distclean
diff -Nru poe.app-0.5.1/debian/source/format poe.app-0.5.1/debian/source/format
--- poe.app-0.5.1/debian/source/format  2024-03-23 18:14:40.0 +
+++ poe.app-0.5.1/debian/source/format  2024-03-23 18:10:16.0 +
@@ -1 +1 @@
-1.0
+3.0 (quilt)

Bug#1067547: FTBFS: "vsnprintf is so broken we can't compensate. Sorry."

2024-03-23 Thread anomie

The check for whether snprintf and vsnprintf honors its length argument
was failing due to the use of -Werror=implicit-function-declaration in
Debian's builds now.

https://sourceforge.net/p/wmweatherplus/git/ci/393394818cf4aa9b34071297a6947409cb19d74b/
should fix it for you.

Bug#1067562: FTBFS: missing symbols on 32-bit architectures

2024-03-23 Thread Thomas Orgis

Am Sat, 23 Mar 2024 21:59:54 +0500
schrieb Andrey Rakhmatullin :

> Source: mpg123
> Version: 1.32.5-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=mpg123=armel=1.32.5-1%2Bb1=1711185338=0

This is being discussued in

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

The build log shows this:

largefile sensitive . no
default offsets . 64

The new 64 bit time_t setup also fixes off_t to be 64 bits and so the
mpg123 build figures that you don't need 32 bit offset symbols. Also
the non-suffixed functions now work with 64 bit offsets, where they
formerly worked with 32 bit off_t arguments. This could be considered
ABI breakage, too.

We should figure out what the desired state is here. Should the ABI
stay the same as before? Then the _FILE_OFFSET_BITS=64 needs to be ignored
for the libmpg123 build.

Also, I notice this: Why do you have --with-cpu=generic_fpu there? You
really should either use one of

arm_fpu Pack neon and generic[[_dither]] decoders, for ARM
processors with FPU and/or NEON
arm_nofpuUse code optimized for ARM processors with fixed point
arithmetic

for 32 bit ARM and

aarch64 Pack neon64 and generic[[_dither]] decoders, for 64bit
ARM processors

for 64 bit ARM.

http://mpg123.org/benchmark/mpg123-1.23.8_arm_fpu_BananaPi_Allwinner_H3@1200MHz_bananian-jessie.txt
#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
NEON18.06 21.54
generic 35.10 32.39
generic_dither 35.98 33.30

http://mpg123.org/benchmark/mpg123-1.23.8_arm_nofpu_BananaPi_Allwinner_H3@1200MHz_bananian-jessie.txt
#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
ARM 36.02 34.32

With NEON, you got a factor of two for 16 bit output. Hm. Generic
with FPU doesn't look that bad compared to the plain ARM assembly. But when we
are talking about ARMs with NEON, one really should use that. Hm I also have

http://mpg123.org/benchmark/mpg123-r3525_Raspberry-Pi_raspian.txt
#mpg123 benchmark (user CPU time in seconds for decoding)
#decodert_s16/s t_f32/s
ARM 86.26 90.66
generic 102.80 100.06
generic_dither 121.10 100.84

So this nofpu build still shows some benefit from the plain ARM
assembly, too.

Is there a special reason why Debian avoids using the optimized decoders on ARM?

Alrighty then,

Thomas

Bug#1067565: ITP: debian-package-book - How to package for Debian

2024-03-23 Thread Mechtilde Stehmann


Package: wnpp
Severity: wishlist

* Package name : debian-package-book
  Version : x.y.zMechtilde Stehmann ymechti...@debian.org>
* URL : http://www.example.org/
* License : (CC by-sa GPLv3)
  Programming Lang: (Bash, LaTeX)
  Description :  How to package for Debian

The information in this book is of particular interest to users of the 
script. But also people who are generally interested in packaging for a 
distribution will find information in this book.


This book does not want to be a “textbook” for building Debian packages. 
It is more of an experience report, where the experiences have been 
“moulded into code”.


The book describes how Debian packages are created using a git 
repository with the programs from the package git-buildpackage [3] and 
other useful commands. Afterwards, the reader should be able to use the 
program as shown and the descriptions of the individual steps to build 
“production quality” Debian packages.




* Why is this package useful/relevant?
- It is a compendium how to package for the Debian repo
* Is it a dependency for another package? No
* Do you use it yourself? Yes
* If there are other packages providing similar functionality,
  how does it compare? There is no other similar package
* How do you plan to maintain it? Do you plan to maintain it
  inside a packaging team? I maintain it inside the Documentation Team
  (check list at https://wiki.debian.org/Teams)
* Are you looking for co-maintainers? Do you need a sponsor?

...--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067564: bookworm-pu: package cpu/1.4.3-14~deb12u1

2024-03-23 Thread Andreas Beckmann

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: block 1067439 withh -1
Control: affects -1 + src:cpu

[ Reason ]
The last QA upload four years ago fixed a FTBFS (multiple definitions of
a global variable) by replacing that variable with an extern declaration
and zero definitions. This didn't result in a linker error (missing
symbol) because it happens in a plugin library and thus is only detected
at runtime when the plugin gets loaded (i.e. always).
So let's ship the plugin with *one* definition of the global variable
;-)

[ Impact ]
cpu stays unusable, but nobody noticed that for the last 4 years and two
stable releases ...

[ Tests ]
Added a smoke test autopkgtest that detects the current failure.

[ Risks ]
We can't make the current situation much worse ;-)

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

[ Changes ]
  * Actually provide a definition of globalLdap.  (Closes: #1067439)

[ Other info ]
n/a

Andreas
diff --git a/debian/changelog b/debian/changelog
index ec0f291..a5aa4a2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+cpu (1.4.3-14~deb12u1) bookworm; urgency=medium
+
+  * QA upload.
+  * Rebuild or bookworm.
+
+ -- Andreas Beckmann   Sat, 23 Mar 2024 18:03:59 +0100
+
+cpu (1.4.3-14) unstable; urgency=medium
+
+  * QA upload.
+  * Actually provide a definition of globalLdap.  (Closes: #1067439)
+  * Add smoke test.
+
+ -- Andreas Beckmann   Sat, 23 Mar 2024 14:39:06 +0100
+
 cpu (1.4.3-13) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/gbp.conf b/debian/gbp.conf
new file mode 100644
index 000..9048820
--- /dev/null
+++ b/debian/gbp.conf
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = main
diff --git a/debian/patches/14_use-extern.patch 
b/debian/patches/14_use-extern.patch
index 774b581..26b0b19 100644
--- a/debian/patches/14_use-extern.patch
+++ b/debian/patches/14_use-extern.patch
@@ -1,10 +1,11 @@
 Description: Fix ftbfs with GCC-10
 
 Bug-Debian: https://bugs.debian.org/957106
+Bug-Debian: https://bugs.debian.org/1067439
 ---
 
 cpu-1.4.3.orig/src/include/plugins/ldap/ldap.h
-+++ cpu-1.4.3/src/include/plugins/ldap/ldap.h
+--- a/src/include/plugins/ldap/ldap.h
 b/src/include/plugins/ldap/ldap.h
 @@ -106,7 +106,7 @@ typedef struct CPU_ldap {
Parser * parse;
  } CPU_ldap;
@@ -14,3 +15,14 @@ Bug-Debian: https://bugs.debian.org/957106
  
  int parseCommand(int argc, char *argv[]);
  void printHelp(int op);
+--- a/src/plugins/ldap/ldap.c
 b/src/plugins/ldap/ldap.c
+@@ -26,6 +26,8 @@
+ #include 
+ #include "plugins/ldap/ldap.h"
+ 
++CPU_ldap * globalLdap;
++
+ int verbose;
+ int operation;
+ 
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..7633658
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,8 @@
+Test-Command: /usr/sbin/cpu || /usr/sbin/cpu 2>&1 | grep ^usage:
+Features: test-name=smoketest
+Depends:
+ cpu,
+Restrictions:
+ superficial,
+ needs-root,
+ allow-stderr,

Bug#1067563: FTBFS on 32-bit time64 architectures: KTimeZone-related symbols missing

Source: kdelibs4support
Version: 5.107.0-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=kdelibs4support=armhf=5.107.0-4=1711178743=0

--- debian/libkf5kdelibs4support5t64.symbols
(libkf5kdelibs4support5t64_5.107.0-4_armhf)
+++ dpkg-gensymbolsoyN9xR   2024-03-23 07:25:36.539192732 +
@@ -2591,7 +2591,7 @@
  _ZN9KTimeZone10TransitionD1Ev@Base 4.96.0
  _ZN9KTimeZone10TransitionD2Ev@Base 4.96.0
  _ZN9KTimeZone10TransitionaSERKS0_@Base 4.96.0
- _ZN9KTimeZone10fromTime_tEl@Base 5.107.0
+#MISSING: 5.107.0-4# _ZN9KTimeZone10fromTime_tEl@Base 5.107.0
  (subst|arch=!i386)_ZN9KTimeZone10fromTime_tE{int64_t}@Base 5.107.0
  _ZN9KTimeZone10updateBaseERKS_@Base 4.96.0
  _ZN9KTimeZone11LeapSecondsC1ERK9QDateTimeiRK7QString@Base 4.96.0
@@ -3191,9 +3191,9 @@
  _ZNK16KTimeZoneBackend16offsetAtZoneTimeEPK9KTimeZoneRK9QDateTimePi@Base
4.96.0
  _ZNK16KTimeZoneBackend4typeEv@Base 4.96.0
  _ZNK16KTimeZoneBackend5cloneEv@Base 4.96.0
- _ZNK16KTimeZoneBackend5isDstEPK9KTimeZonel@Base 5.107.0
+#MISSING: 5.107.0-4# _ZNK16KTimeZoneBackend5isDstEPK9KTimeZonel@Base 5.107.0
  (subst|arch=!i386)_ZNK16KTimeZoneBackend5isDstEPK9KTimeZone{int64_t}@Base
5.107.0
- _ZNK16KTimeZoneBackend6offsetEPK9KTimeZonel@Base 5.107.0
+#MISSING: 5.107.0-4# _ZNK16KTimeZoneBackend6offsetEPK9KTimeZonel@Base 5.107.0
  (subst|arch=!i386)_ZNK16KTimeZoneBackend6offsetEPK9KTimeZone{int64_t}@Base
5.107.0
  _ZNK17KFadeWidgetEffect10metaObjectEv@Base 4.96.0
  _ZNK17KFileMetaInfoItem10isEditableEv@Base 4.96.0
@@ -3252,9 +3252,9 @@
_ZNK22KSystemTimeZoneBackend16offsetAtZoneTimeEPK9KTimeZoneRK9QDateTimePi@Base
4.96.0
  _ZNK22KSystemTimeZoneBackend4typeEv@Base 4.96.0
  _ZNK22KSystemTimeZoneBackend5cloneEv@Base 4.96.0
- _ZNK22KSystemTimeZoneBackend5isDstEPK9KTimeZonel@Base 5.107.0
+#MISSING: 5.107.0-4# _ZNK22KSystemTimeZoneBackend5isDstEPK9KTimeZonel@Base
5.107.0
(subst|arch=!i386)_ZNK22KSystemTimeZoneBackend5isDstEPK9KTimeZone{int64_t}@Base
5.107.0
- _ZNK22KSystemTimeZoneBackend6offsetEPK9KTimeZonel@Base 5.107.0
+#MISSING: 5.107.0-4# _ZNK22KSystemTimeZoneBackend6offsetEPK9KTimeZonel@Base
5.107.0
(subst|arch=!i386)_ZNK22KSystemTimeZoneBackend6offsetEPK9KTimeZone{int64_t}@Base
5.107.0
  _ZNK22KTzfileTimeZoneBackend14hasTransitionsEPK9KTimeZone@Base 4.96.0
  _ZNK22KTzfileTimeZoneBackend4typeEv@Base 4.96.0
@@ -3677,11 +3677,11 @@
  _ZNK9KTimeZone5Phase7commentEv@Base 4.96.0
  _ZNK9KTimeZone5Phase9utcOffsetEv@Base 4.96.0
  _ZNK9KTimeZone5PhaseeqERKS0_@Base 4.96.0
- _ZNK9KTimeZone5isDstEl@Base 5.107.0
+#MISSING: 5.107.0-4# _ZNK9KTimeZone5isDstEl@Base 5.107.0
  (subst|arch=!i386)_ZNK9KTimeZone5isDstE{int64_t}@Base 5.107.0
  _ZNK9KTimeZone5parseEv@Base 4.96.0
  _ZNK9KTimeZone5toUtcERK9QDateTime@Base 4.96.0
- _ZNK9KTimeZone6offsetEl@Base 5.107.0
+#MISSING: 5.107.0-4# _ZNK9KTimeZone6offsetEl@Base 5.107.0
  (subst|arch=!i386)_ZNK9KTimeZone6offsetE{int64_t}@Base 5.107.0
  _ZNK9KTimeZone6phasesEv@Base 4.96.0
  _ZNK9KTimeZone6sourceEv@Base 4.96.0


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad


Am 23.03.24 um 17:53 schrieb Carsten Schoenert:

Hello Matthias,

Am 23.03.24 um 17:40 schrieb Matthias Geiger:

Hi Carsten,

thanks for maintaining KiCad. What you mentioned is true for Kicad <=
7.0. With 8.0 a change landed enabling installation of colorthemes
system-wide  (see https://gitlab.com/kicad/code/kicad/-/issues/15920).

I already created a package and installed it and it works as intended.
Since this does not touch user files this conforms to Debian policy.
The plugin manager does not show this scheme as installed since it only
looks for user themes.


nice, o.k., then upstream has still some work to do. :-)

Would it not better creating one src:package which would package the 
various themes all together that are out there? e.g. named kicad-themes


I dislike a bit multiple packages that a user needs to know (and to 
install then) if all could get packaged into one.
There could be of course also a virtual package kicad-themes which 
pulls in the installation of all the real other theme packages.


Most of the other themes are not under heavy development and will only 
change randomly.
Downside otoh is you will need to run a own scripting to detect 
changes. Is also not that complicated.


But that's up to you if you can agree on my ideas.

I agree that packaging all themes is doable. However, how would I create 
a src: package with different upstream tarballs? I could use some help 
with that. Providing a virtual package for all themes is also a good idea.


Would you be ok with this package being maintained under the Electronics 
Team ?


best,

--
Matthias Geiger 
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067562: FTBFS: missing symbols on 32-bit architectures

Source: mpg123
Version: 1.32.5-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=mpg123=armel=1.32.5-1%2Bb1=1711185338=0

Symbols marked (arch-bits=32|arch=!x32) disappeared on armel/armhf/powerpc,
probably because of time_t changes?


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067561: FTBFS: Error: symbol `open64' is already defined

Source: lightdm
Version: 1.32.0-4
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=lightdm=armel=1.32.0-4%2Bb3=1711185127=0

/bin/bash ../../libtool  --tag=CC   --mode=link gcc -Wall
-Wstrict-prototypes  -Wnested-externs
-Werror=missing-prototypes  -Werror=implicit-function-
declaration  -Werror=pointer-arith
-Werror=init-self  -Werror=format-security
-Werror=format=2  -Werror=missing-include-dirs
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include -pthread
-I/usr/include/libmount -I/usr/include/blkid  -I/usr/include/gio-unix-2.0
-I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include -pthread
-I/usr/include/libmount -I/usr/include/blkid  -g -O2 -Werror=implicit-function-
declaration -ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -O0  -Wl,-z,relro
-Wl,-z,now -Wl,-O1 -o Xvnc Xvnc-Xvnc.o Xvnc-x-authority.o Xvnc-x-common.o Xvnc-
x-server.o Xvnc-status.o -lgobject-2.0 -lglib-2.0  -lglib-2.0  -lgio-2.0
-lgobject-2.0 -lglib-2.0  -lgio-2.0 -lgobject-2.0 -lglib-2.0
/tmp/ccCHYR2t.s: Assembler messages:
/tmp/ccCHYR2t.s:2779: Error: symbol `open64' is already defined
/tmp/ccCHYR2t.s:3181: Error: symbol `creat64' is already defined
/tmp/ccCHYR2t.s:3508: Error: symbol `__stat64_time64' is already defined


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

2024-03-23 Thread Carsten Schoenert


Hello Matthias,

Am 23.03.24 um 17:40 schrieb Matthias Geiger:

Hi Carsten,

thanks for maintaining KiCad. What you mentioned is true for Kicad <=
7.0. With 8.0 a change landed enabling installation of colorthemes
system-wide  (see https://gitlab.com/kicad/code/kicad/-/issues/15920).

I already created a package and installed it and it works as intended.
Since this does not touch user files this conforms to Debian policy.
The plugin manager does not show this scheme as installed since it only
looks for user themes.


nice, o.k., then upstream has still some work to do. :-)

Would it not better creating one src:package which would package the 
various themes all together that are out there? e.g. named kicad-themes


I dislike a bit multiple packages that a user needs to know (and to 
install then) if all could get packaged into one.
There could be of course also a virtual package kicad-themes which pulls 
in the installation of all the real other theme packages.


Most of the other themes are not under heavy development and will only 
change randomly.
Downside otoh is you will need to run a own scripting to detect changes. 
Is also not that complicated.


But that's up to you if you can agree on my ideas.

--
Regards
Carsten

Bug#1067560: FTBFS on 32-bit time64 architectures: cannot convert ‘long int’ to ‘const time_t’ {aka ‘const long long int*’}

Source: deepin-log-viewer
Version: 5.9.7+ds1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=deepin-log-
viewer=armel=5.9.7%2Bds1-2%2Bb2=1711175532=0

/<>/application/wtmpparse.cpp: In function ‘char*
show_end_time(long int)’:
/<>/application/wtmpparse.cpp:183:19: error: cannot convert ‘long
int*’ to ‘const time_t*’ {aka ‘const long long int*’}
  183 | t = localtime();
  |   ^~~~
  |   |
  |   long int*
In file included from /usr/include/features.h:490,
 from /usr/include/fcntl.h:25,
 from /<>/application/wtmpparse.h:25,
 from /<>/application/wtmpparse.cpp:22:
/usr/include/time.h:141:19: note:   initializing argument 1 of ‘tm*
localtime(const time_t*)’
  141 | extern struct tm *__REDIRECT_NTH (localtime, (const time_t *__timer),
  |   ^~


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067559: nmu: roc-toolkit_0.3.0+dfsg-7

2024-03-23 Thread Simon McVittie

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: roc-tool...@packages.debian.org, debian-...@lists.debian.org
Control: affects -1 + src:roc-toolkit
User: release.debian@packages.debian.org
Usertags: binnmu

Another binNMU suggestion for the 64-bit time_t transition. This one
would partially unblock pipewire.

(It could be rebuilt across all architectures if you prefer to keep them
in sync.)

nmu roc-toolkit_0.3.0+dfsg-7 . armel armhf . unstable . -m "rebuild against 
libuv1t64"

Thanks,
smcv

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad


Am 23.03.24 um 17:23 schrieb Carsten Schoenert:

Hello Matthias,

Am 23.03.24 um 16:51 schrieb Matthias Geiger:

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, werdah...@riseup.net

* Package name    : kicad-gruvbox-theme
   Version : 1.1.0
   Upstream Contact: Alexander Brevig
* URL : 
https://github.com/AlexanderBrevig/kicad-gruvbox-theme

* License : MIT
   Programming Lang: n/a
   Description : Gruvbox colorscheme for KiCadi

A simple gruvbox colorscheme for the EESchema and PCBNew editors within
KiCad. KiCad 8 allows for the system-wide installation of
colorschemes, thus ITP'ing now.


how is this system wide installation intended to work.

Even the upstream project site states the installation needs to happen 
into ~/.config/kicad/colors or ~/.config/kicad/6.0/colors (besides it 
uses the older version 6.0 as user folder)


As long as I follow this feature I'm not aware that any system wide 
installation of themes is now possible.


Given it is possible, how the internal Plugin and Content Management 
will handle this?



Hi Carsten,

thanks for maintaining KiCad. What you mentioned is true for Kicad <= 
7.0. With 8.0 a change landed enabling installation of colorthemes 
system-wide  (see https://gitlab.com/kicad/code/kicad/-/issues/15920).


I already created a package and installed it and it works as intended. 
Since this does not touch user files this conforms to Debian policy.  
The plugin manager does not show this scheme as installed since it only 
looks for user themes.


best,

--
Matthias Geiger 
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067558: pipewire: consider building with reduced features during 64-bit time_t transition

2024-03-23 Thread Simon McVittie

Source: pipewire
Version: 1.0.4-2
Severity: wishlist
Tags: patch

The attached patches, also available as
,
temporarily disable some optional features on the 32-bit non-x86
architectures (armel, armhf and some -ports architectures) to make
pipewire buildable on those architectures again.

I've confirmed on a porterbox that this should make pipewire buildable
on armhf immediately, and armel soon.

The first commit (limiting Snap support to the architectures supported by
Snap upstream) might remain useful after this transition has finished.
The others should be reverted after the relevant libraries become available
on the affected architectures.

smcv
>From c1de62b3c7b48f64df8f6c69ab9cb35fa9e775b8 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 22 Mar 2024 10:56:02 +
Subject: [PATCH 1/4] Only build Snap integration on supported architectures

According to Snap documentation, only these architectures are supported,
so enabling the others is unlikely to be particularly useful. Reducing the
architecture list reduces the impact of any non-portability in snapd-glib.

Reference: https://snapcraft.io/docs/reference-architectures#heading--supported-architectures
---
 debian/control | 2 +-
 debian/rules   | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 294002dd4..b6412b35f 100644
--- a/debian/control
+++ b/debian/control
@@ -32,7 +32,7 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
libroc-dev (>= 0.3.0+dfsg-3),
libsbc-dev,
libsdl2-dev ,
-   libsnapd-glib-dev [linux-any],
+   libsnapd-glib-dev [amd64 arm64 armhf i386 powerpc ppc64el riscv64 s390x],
libsndfile1-dev,
libssl-dev,
libsystemd-dev [linux-any],
diff --git a/debian/rules b/debian/rules
index fe1d68b74..7979ec2fb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -48,15 +48,19 @@ LIBFFADO=enabled
 endif
 
 ifneq (,$(filter hurd-amd64 hurd-i386,$(DEB_HOST_ARCH)))
-SNAP=disabled
 UDEVRULESDIR=
 else
 export UDEVRULESDIR=/usr/lib/udev/rules.d
-SNAP=enabled
 # For pre-Trixie releases udev rules should go in:
 # export UDEVRULESDIR=/lib/udev/rules.d
 endif
 
+ifneq (,$(filter amd64 arm64 armhf i386 powerpc ppc64el riscv64 s390x,$(DEB_HOST_ARCH)))
+SNAP=enabled
+else
+SNAP=disabled
+endif
+
 override_dh_auto_configure:
 	dh_auto_configure -- \
 		-Daudiotestsrc=enabled \
-- 
2.43.0

>From f6ecc89c51e6684fddb89135a4acdbf705965176 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 23 Mar 2024 10:22:04 +
Subject: [PATCH 2/4] Temporarily disable Snap integration on 32-bit non-x86

snapd-glib has not yet been rebuilt for the 64-bit time_t transition.
This change should be reverted after snapd-glib is rebuilt.
---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index b6412b35f..a21e1ae08 100644
--- a/debian/control
+++ b/debian/control
@@ -32,7 +32,7 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
libroc-dev (>= 0.3.0+dfsg-3),
libsbc-dev,
libsdl2-dev ,
-   libsnapd-glib-dev [amd64 arm64 armhf i386 powerpc ppc64el riscv64 s390x],
+   libsnapd-glib-dev [amd64 arm64 i386 ppc64el riscv64 s390x],
libsndfile1-dev,
libssl-dev,
libsystemd-dev [linux-any],
diff --git a/debian/rules b/debian/rules
index 7979ec2fb..ba039fd3e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -55,7 +55,7 @@ export UDEVRULESDIR=/usr/lib/udev/rules.d
 # export UDEVRULESDIR=/lib/udev/rules.d
 endif
 
-ifneq (,$(filter amd64 arm64 armhf i386 powerpc ppc64el riscv64 s390x,$(DEB_HOST_ARCH)))
+ifneq (,$(filter amd64 arm64 i386 ppc64el riscv64 s390x,$(DEB_HOST_ARCH)))
 SNAP=enabled
 else
 SNAP=disabled
-- 
2.43.0

>From ff854d2be60964d75a57ed64f5a161a55ef38ee9 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 23 Mar 2024 10:42:29 +
Subject: [PATCH 3/4] Temporarily disable libffado integration on 32-bit
 non-x86

libffado has not yet been rebuilt for the 64-bit time_t transition.
This change should be reverted after it is rebuilt.
---
 debian/control | 2 +-
 debian/rules   | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index a21e1ae08..1632c8e62 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
libbluetooth-dev [linux-any],
libcamera-dev (>= 0.2.0) [!m68k !hurd-any],
libdbus-1-dev,
-   libffado-dev,
+   libffado-dev [!armel !armhf !hppa !m68k !powerpc !sh4],
libfreeaptx-dev,
libglib2.0-dev,
libgstreamer-plugins-base1.0-dev,
diff

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

2024-03-23 Thread Carsten Schoenert


Hello Matthias,

Am 23.03.24 um 16:51 schrieb Matthias Geiger:

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, werdah...@riseup.net

* Package name: kicad-gruvbox-theme
   Version : 1.1.0
   Upstream Contact: Alexander Brevig
* URL : https://github.com/AlexanderBrevig/kicad-gruvbox-theme
* License : MIT
   Programming Lang: n/a
   Description : Gruvbox colorscheme for KiCadi

A simple gruvbox colorscheme for the EESchema and PCBNew editors within
KiCad. KiCad 8 allows for the system-wide installation of
colorschemes, thus ITP'ing now.


how is this system wide installation intended to work.

Even the upstream project site states the installation needs to happen 
into ~/.config/kicad/colors or ~/.config/kicad/6.0/colors (besides it 
uses the older version 6.0 as user folder)


As long as I follow this feature I'm not aware that any system wide 
installation of themes is now possible.


Given it is possible, how the internal Plugin and Content Management 
will handle this?


--
Regards
Carsten

Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks

2024-03-23 Thread Holger Wansing

Hi,

Dmitry Shachnev  wrote (Fri, 22 Mar 2024 18:46:25 +0300):
> On Fri, Mar 22, 2024 at 03:30:55PM +0100, Holger Wansing wrote:
> > Ok, I see.
> > So, we will need to get sphinx-rtd-theme-common installed on all debian.org
> > website mirrors, and it will just work (?) ...
> 
> From your earlier message it seemed to me like you are using the build
> tree in your deploy process, not the built package.
> 
> That is why I suggested not running dh_sphinxdoc, however my suggestion
> applied only to your deploy procedure. The package which is being uploaded
> to Debian archive should still use dh_sphinxdoc.
> 
> If you are using the built package and installing it on the remote server,
> then yes, install sphinx-rtd-theme-common and you should be good.

While working on adapting the parts/7doc script (from Debian Webmaster
Team's 'cron' repo), I realized that this is not going to work out of the
box: while the concept of the symlinks mentioned above is working fine,
when the debian-policy document is installed on a machine as usual
(means it recides in the same path as in the binary deb package, aka
/usr/share/doc/debian-policy/policy.html), we have the docs for the website
on the debian.org website machine in another path. That is in
/srv/www.debian.org/www/doc/debian-policy/.

That means the (relative) symlinks will not resolve!
Therefore I think the best solution here is, to change the relative
symlinks into absolute ones, on the debian.org website machine.

I have worked out the needed changes for cron/parts/7doc to deal with all
this (it works fine here locally). The debian-policy package could stay
unchanged.
I attach the patch here just for reference; will apply it, as soon as
sphinx-rtd-theme-common gets installed on wolkenstein
(working on a bugreport to DSA to get this done).

Closing #1066967 against sphinx-common/dh_sphinxdoc now.
Thanks python people for your help!

> Actually, I would move ${sphinxdoc:Depends} from Recommends to Depends,
> because the documentation is mostly unusable without the static files.

Ok. I will leave this mostly to Debian Policy maintainers.



Greetings
Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/parts/7doc b/parts/7doc
index b079aea..5a358d7 100755
--- a/parts/7doc
+++ b/parts/7doc
@@ -260,22 +260,24 @@ if [ "$lang" = "en" ]; then
 			install -p -m 664 `readlink -f $page` $destdir/Common_Content/images/$(basename $page)
 		fi
 	done
 fi
 }
 
 #
 
 mvhtml_sphinx()
 {
-# Copy of mvhtml(), modified so it copies the _images and _static subfolders too
-# This is needed by debian-policy since they moved to reStructuredText and Sphinx
+# Copy of mvhtml(), modified so it copies the _images, _sources, _static, _static/css
+# and _static/fonts subfolders too.
+# This is needed by some manuals which moved to reStructuredText and Sphinx
+# (like debian-policy and developers-reference) and use an html theme from read-the-docs.
 # This is probably uncomplete, since the _static folder contains symlinks to
 # some javascript that probably will not work.
 
 namedest=$1# destdir directory:  maint-guide
 basedir=$2 # binary package data dir.: usr/share/doc/maint-guide-fr/html
 addlang=${3:-NO} # $lang in filename: NO | ADD | YES
  # NO:  without $lang and leave it so
  # ADD: without $lang and add it (make link for en) (internal URL conversion)
  # YES: with$lang and leave it so (make link for en)
 lang=${4:-en}  # language name: en (default), fr, ...
@@ -317,20 +319,36 @@ for page in $pagepattern; do
 done
 
 if [ "$lang" = "en" ]; then
 	pagepattern="$basedir/_static/*"
 	for page in $pagepattern; do
 		if [ -f "`readlink -f $page`" ]; then
 			mkdirp $destdir/_static
 			install -p -m 664 `readlink -f $page` $destdir/_static/$(basename $page)
 		fi
 	done
+	pagepattern="$basedir/_static/css/*"
+	for page in $pagepattern; do
+		if [ -d "$basedir/_static/css" ]; then
+	# Replace all existing relative symlinks in css by absolute symlinks to the correct place.
+			mkdirp $destdir/_static/css
+			ln -sf /usr/share/sphinx_rtd_theme/static/css/$(basename $page) $destdir/_static/css/$(basename $page)
+		fi
+	done
+	pagepattern="$basedir/_static/fonts/*"
+	for page in $pagepattern; do
+		if [ -d "$basedir/_static/fonts" ]; then
+	# Replace all existing relative symlinks in fonts by absolute symlinks to the correct place.
+			mkdirp $destdir/_static/fonts
+			ln -sf /usr/share/sphinx_rtd_theme/static/fonts/$(basename $page) $destdir/_static/fonts/$(basename $page)
+		fi
+	done
 	pagepattern="$basedir/_images/*"
 	for page in $pagepattern ; do
 		if [ -f "`readlink -f $page`" ]; then
 			mkdirp $destdir/_images
 			install -p -m 664 `readlink -f $page` $destdir/_images/$(basename $page)
 		fi
 	done
 pagepattern="$basedir/_sources/*"
 for page in $pagepattern ; do
 if [ -f "`readlink -f $page`" ]; then

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

2024-03-23 Thread Tobias Frost

Control: tags -1 moreinfo

The source package name is still being renamed, and the source package
rename is not explictly stated in the changelog.

(I think this renane shouldn't be done, to keep the history of the
package, not only the tracker but also the BTS and all the other
services working on source packages.)

(You should also bump the timestamp in the d/changelog, when uploading a
new package to mentors.)

The patch in package should be fowarded; as it only changes *comments*,
consider dropping it completly.

--
tobi

On Thu, 14 Mar 2024 22:25:04 -0300 Lucas Castro 
wrote:
> 
> Em 06/03/2024 05:49, Daniel Gröber escreveu:
> > Hi Lucas,
> >
> > On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote:
> >>> Are you sure you want to change the source package name? Doing so
fractures
> >>> the history of the package on tracker.d.o and it's not really
necessary.
> >> The upstream has changed software name but it's a good point about
> >> tracker.d.o.
> > Right, so users will try to `apt install foolsm` in the future, but
the
> > source package name is largeley irellevant to them.
> >
> >>> Quick package review:
> >>>
> >>>    - d/postinst: I don't think it's useful to print the message
about editing
> >>>  the config. I've only seen packages do that in special
circumstances, do
> >>>  you have a justification for it being necessary here?
> >> Really, really not. I really would like improve that, I guess to
write good
> >> doc and manual pages is enough.
> > I would argue users (sysadmins in this case) are going to be
familiar with
> > the concept of having to configure a package before it becomes
useful and
> > while the daemon not being started at package installation is
> > unconventional in Debian automatic config reloading is by far not
universal
> > so any config change to make lsm useful is going to elicit a restart
> > anyway.
> >
> > So I just don't see why we'd want a conspicuous message telling
people what
> > they already know :)
> >
> >>>    - You declare Replaces+Conflicts on lsm but you don't seem to
take any
> >>>  care for the new binary package to actually be compatible
with the old
> >>>  one since the config location changed.
> >> I'm in doubt, when the old config exist, if set dpkg to copy the
old config
> >> from old location to the new one or if I just print/show up a
message to
> >> users notifying about path update requirement.
> > I think an automatic upgrade is the way to go in this case as long
as the
> > config format is still fully compatible to the old lsm-1.0.4, but
since
> > copying will leave cruft behind for the user to cleanup manually I
think we
> > should mv the config.
> >
> >> If it's good/allowed do the copy, it could be applied in postinst.
I think
> >> print/show up message is rightest way.
> > Consider that people upgrade Debian systems for many, many years
without
> > reinstalling. So every bit of cruft we leave behind due to
transitions such
> > as this accumulates. I don't see a technical need for not doing so
in this
> > case so I think we should clean up behind ourselves and move the
config to
> > the new location.
> >
> > You should then absoluteley print a message in the log to note this
fact,
> > but perhaps not as conspicuously as you're printing the "configure
me"
> > message. Something like "Moving $OLD_PATH to $NEW_PATH" should
suffice
> > since the package(s) involved should be obvious from the filenames.
> 
> Just uploaded to mentors again, now the update occur smoothly.
> 
> 
> >
> > --Daniel
> 
> Thanks for taking time on testing update.

Bug#1059532: abseil:riscv64: uses privileged rdcycle instruction

2024-03-23 Thread Aurelien Jarno

control: tag -1 + fixed-upstream
control: tag -1 + patch
control: forwarded -1 
https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4

Hi Benjamin,

On 2023-12-27 12:45, Benjamin Barenblat wrote:
> Source: abseil
> Version: 20220623.1-1
> Severity: normal
> Tags: upstream
> Control: forwarded -1 https://github.com/abseil/abseil-cpp/pull/1550
> 
> On RISC-V, Abseil's cycle counter uses the rdcycle instruction, which is
> a privileged instruction when running on Debian's Linux kernels. This
> causes some widely used Abseil functions (e.g., certain member functions
> on absl::Mutex) to crash with a SIGILL.

This has finally been fixed upstream, please pull the following patch to
fix this issue:
https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4

In addition it is not necessary anymore to run the testsuite with
--no-parallel, the problem was linked to the use of the rdcycle
instruction which jumps when the process is rescheduled on another CPU.
I have tested the following patch with the above upstream commit:


diff -Nru abseil-20230802.1/debian/rules abseil-20230802.1/debian/rules
--- abseil-20230802.1/debian/rules  2023-09-07 19:11:48.0 +0200
+++ abseil-20230802.1/debian/rules  2024-03-23 16:56:20.0 +0100
@@ -28,12 +28,6 @@
 ABSL_RUN_TESTS=ON
 endif
 
-# Debian's RISC-V builders don't have enough resources to run tests in 
parallel.
-# See https://bugs.debian.org/1025221.
-ifneq ($(filter $(DEB_HOST_ARCH),riscv64),)
-ABSL_TEST_EXTRA_ARGS=--no-parallel
-endif
-
 %:
dh $@

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

2024-03-23 Thread Daniel Gröber

Hi Lucas,

On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote:
> > Are you sure you want to change the source package name? Doing so fractures
> > the history of the package on tracker.d.o and it's not really necessary.
> 
> The upstream has changed software name but it's a good point about
> tracker.d.o.

Right, so users will try to `apt install foolsm` in the future, but the
source package name is largeley irellevant to them.

> > Quick package review:
> > 
> >   - d/postinst: I don't think it's useful to print the message about editing
> > the config. I've only seen packages do that in special circumstances, do
> > you have a justification for it being necessary here?
> Really, really not. I really would like improve that, I guess to write good
> doc and manual pages is enough.

I would argue users (sysadmins in this case) are going to be familiar with
the concept of having to configure a package before it becomes useful and
while the daemon not being started at package installation is
unconventional in Debian automatic config reloading is by far not universal
so any config change to make lsm useful is going to elicit a restart
anyway.

So I just don't see why we'd want a conspicuous message telling people what
they already know :)

> >   - You declare Replaces+Conflicts on lsm but you don't seem to take any
> > care for the new binary package to actually be compatible with the old
> > one since the config location changed.
> 
> I'm in doubt, when the old config exist, if set dpkg to copy the old config
> from old location to the new one or if I just print/show up a message to
> users notifying about path update requirement.

I think an automatic upgrade is the way to go in this case as long as the
config format is still fully compatible to the old lsm-1.0.4, but since
copying will leave cruft behind for the user to cleanup manually I think we
should mv the config.

> If it's good/allowed do the copy, it could be applied in postinst. I think
> print/show up message is rightest way.

Consider that people upgrade Debian systems for many, many years without
reinstalling. So every bit of cruft we leave behind due to transitions such
as this accumulates. I don't see a technical need for not doing so in this
case so I think we should clean up behind ourselves and move the config to
the new location.

You should then absoluteley print a message in the log to note this fact,
but perhaps not as conspicuously as you're printing the "configure me"
message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice
since the package(s) involved should be obvious from the filenames.

--Daniel

signature.asc
Description: PGP signature

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

2024-03-23 Thread Lucas Castro



Em 06/03/2024 05:49, Daniel Gröber escreveu:

Hi Lucas,

On Tue, Mar 05, 2024 at 03:29:49PM -0300, Lucas Castro wrote:

Are you sure you want to change the source package name? Doing so fractures
the history of the package on tracker.d.o and it's not really necessary.

The upstream has changed software name but it's a good point about
tracker.d.o.

Right, so users will try to `apt install foolsm` in the future, but the
source package name is largeley irellevant to them.


Quick package review:

   - d/postinst: I don't think it's useful to print the message about editing
 the config. I've only seen packages do that in special circumstances, do
 you have a justification for it being necessary here?

Really, really not. I really would like improve that, I guess to write good
doc and manual pages is enough.

I would argue users (sysadmins in this case) are going to be familiar with
the concept of having to configure a package before it becomes useful and
while the daemon not being started at package installation is
unconventional in Debian automatic config reloading is by far not universal
so any config change to make lsm useful is going to elicit a restart
anyway.

So I just don't see why we'd want a conspicuous message telling people what
they already know :)


   - You declare Replaces+Conflicts on lsm but you don't seem to take any
 care for the new binary package to actually be compatible with the old
 one since the config location changed.

I'm in doubt, when the old config exist, if set dpkg to copy the old config
from old location to the new one or if I just print/show up a message to
users notifying about path update requirement.

I think an automatic upgrade is the way to go in this case as long as the
config format is still fully compatible to the old lsm-1.0.4, but since
copying will leave cruft behind for the user to cleanup manually I think we
should mv the config.


If it's good/allowed do the copy, it could be applied in postinst. I think
print/show up message is rightest way.

Consider that people upgrade Debian systems for many, many years without
reinstalling. So every bit of cruft we leave behind due to transitions such
as this accumulates. I don't see a technical need for not doing so in this
case so I think we should clean up behind ourselves and move the config to
the new location.

You should then absoluteley print a message in the log to note this fact,
but perhaps not as conspicuously as you're printing the "configure me"
message. Something like "Moving $OLD_PATH to $NEW_PATH" should suffice
since the package(s) involved should be obvious from the filenames.


Just uploaded to mentors again, now the update occur smoothly.




--Daniel


Thanks for taking time on testing update.


Lucas Castro.



OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064297: RFS: foolsm/1.0.21-1 -- Link connectivity monitor tool

2024-03-23 Thread Lucas Castro



Em 05/03/2024 08:09, Daniel Gröber escreveu:

Hi Lucas,

On Mon, Feb 19, 2024 at 04:50:27PM -0300, Lucas Castro wrote:

  * Package name : foolsm

Are you sure you want to change the source package name? Doing so fractures
the history of the package on tracker.d.o and it's not really necessary.


The upstream has changed software name but it's a good point about 
tracker.d.o.


I'll take a look at some project that has changed the name too, BTW I 
already looked at some of them but not checked the source package name.




Quick package review:

  - d/postinst: I don't think it's useful to print the message about editing
the config. I've only seen packages do that in special circumstances, do
you have a justification for it being necessary here?
Really, really not. I really would like improve that, I guess to write 
good doc and manual pages is enough.

  - You declare Replaces+Conflicts on lsm but you don't seem to take any
care for the new binary package to actually be compatible with the old
one since the config location changed.


I'm in doubt, when the old config exist, if set dpkg to copy the old 
config from old location to the new one or if I just print/show up a 
message to users notifying about path update requirement.


If it's good/allowed do the copy, it could be applied in postinst. I 
think print/show up message is rightest way.



  - d/foolsm.init: Still has the old $CONFIG path

That's true, I'll update and re-upload.


--Daniel


OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066194: nstreams: FTBFS: parse_tcpdump.c:262:50: error: implicit declaration of function ‘int2proto’ [-Werror=implicit-function-declaration]


A fix for this was uploaded to DELAYED/10. See #1007384.

Bug#1007384: nstreams: please consider upgrading to 3.0 source format


I have uploaded a NMU to DELAYED/10 with the changes in the attached debdiff.diff -Nru nstreams-1.0.4/Makefile nstreams-1.0.4/Makefile
--- nstreams-1.0.4/Makefile 2024-03-23 15:45:41.0 +
+++ nstreams-1.0.4/Makefile 2000-07-26 16:18:01.0 +
@@ -4,21 +4,21 @@
 
 nstreams : 
cd src && ${MAKE}
-
+   
 clean : 
cd src && ${MAKE} clean
 
 
 install : all
-   $(INSTALL) -m 0755 -d ${DESTDIR}/${prefix}/bin
-   $(INSTALL) -m 0755 src/nstreams ${DESTDIR}${prefix}/bin  
-   $(INSTALL) -m 0755 -d ${DESTDIR}${prefix}/share/man
-   $(INSTALL) -m 0755 -d ${DESTDIR}${prefix}/share/man/man1
-   $(INSTALL) -m 0444 docs/nstreams.1 ${DESTDIR}${prefix}/share/man/man1/
-   if [ -f ${DESTDIR}/${sysconfdir}/nstreams-services ]; then mv 
${DESTDIR}${sysconfdir}/nstreams-services 
${DESTDIR}${sysconfdir}/nstreams-services.old;fi
-   $(INSTALL) -m 0644 docs/nstreams-services 
${DESTDIR}${sysconfdir}/nstreams/nstreams-services
-   $(INSTALL) -m 0644 docs/nstreams-networks 
${DESTDIR}${sysconfdir}/nstreams/nstreams-networks
-
+   $(INSTALL) -m 0755 -d ${prefix}/bin
+   $(INSTALL) -m 0755 src/nstreams ${prefix}/bin  
+   $(INSTALL) -m 0755 -d ${prefix}/man
+   $(INSTALL) -m 0755 -d ${prefix}/man/man1
+   $(INSTALL) -m 0444 docs/nstreams.1 ${prefix}/man/man1/
+   if [ -f ${prefix}/etc/nstreams-services ]; then mv 
${prefix}/etc/nstreams-services ${prefix}/etc/nstreams-services.old;fi
+   $(INSTALL) -m 0644 docs/nstreams-services 
${prefix}/etc/nstreams-services
+   $(INSTALL) -m 0644 docs/nstreams-networks 
${prefix}/etc/nstreams-networks.sample
+   
 distclean : clean
rm -f includes/config.h config.cache config.status config.log 
nstreams.tmpl
-
+   
diff -Nru nstreams-1.0.4/configure nstreams-1.0.4/configure
--- nstreams-1.0.4/configure2024-03-23 15:45:41.0 +
+++ nstreams-1.0.4/configure2000-08-01 09:57:19.0 +
@@ -117,7 +117,6 @@
   *=*) ;;
   *) ac_optarg=yes ;;
 esac
-
 eval "enable_${ac_feature}='$ac_optarg'" ;;
 
   -exec-prefix | --exec_prefix | --exec-prefix | --exec-prefi \
@@ -523,7 +522,7 @@
 fi
 
 
-# From configure.in Revision: 1.7 ac_aux_dir=
+# From configure.in Revision: 1.1.1.1 ac_aux_dir=
 for ac_dir in $srcdir $srcdir/.. $srcdir/../..; do
   if test -f $ac_dir/install-sh; then
 ac_aux_dir=$ac_dir
@@ -1134,13 +1133,13 @@
 
 
 test "$prefix" = NONE && prefix=/usr/local
-#sysconfdir=${prefix}/etc
+sysconfdir=${prefix}/etc
 cat >> confdefs.h <> confdefs.h <  Sat, 23 Mar 2024 14:59:32 +
+
 nstreams (1.0.4-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru nstreams-1.0.4/debian/patches/debian.patch 
nstreams-1.0.4/debian/patches/debian.patch
--- nstreams-1.0.4/debian/patches/debian.patch  1970-01-01 00:00:00.0 
+
+++ nstreams-1.0.4/debian/patches/debian.patch  2024-03-23 14:59:32.0 
+
@@ -0,0 +1,84 @@
+--- nstreams-1.0.4.orig/Makefile
 nstreams-1.0.4/Makefile
+@@ -4,17 +4,17 @@ all : nstreams
+ clean : 
+   cd src && ${MAKE} clean
+ 
+ 
+ install : all
+-  $(INSTALL) -m 0755 -d ${prefix}/bin
+-  $(INSTALL) -m 0755 src/nstreams ${prefix}/bin  
+-  $(INSTALL) -m 0755 -d ${prefix}/man
+-  $(INSTALL) -m 0755 -d ${prefix}/man/man1
+-  $(INSTALL) -m 0444 docs/nstreams.1 ${prefix}/man/man1/
+-  if [ -f ${prefix}/etc/nstreams-services ]; then mv 
${prefix}/etc/nstreams-services ${prefix}/etc/nstreams-services.old;fi
+-  $(INSTALL) -m 0644 docs/nstreams-services 
${prefix}/etc/nstreams-services
+-  $(INSTALL) -m 0644 docs/nstreams-networks 
${prefix}/etc/nstreams-networks.sample
+-  
++  $(INSTALL) -m 0755 -d ${DESTDIR}/${prefix}/bin
++  $(INSTALL) -m 0755 src/nstreams ${DESTDIR}${prefix}/bin  
++  $(INSTALL) -m 0755 -d ${DESTDIR}${prefix}/share/man
++  $(INSTALL) -m 0755 -d ${DESTDIR}${prefix}/share/man/man1
++  $(INSTALL) -m 0444 docs/nstreams.1 ${DESTDIR}${prefix}/share/man/man1/
++  if [ -f ${DESTDIR}/${sysconfdir}/nstreams-services ]; then mv 
${DESTDIR}${sysconfdir}/nstreams-services 
${DESTDIR}${sysconfdir}/nstreams-services.old;fi
++  $(INSTALL) -m 0644 docs/nstreams-services 
${DESTDIR}${sysconfdir}/nstreams/nstreams-services
++  $(INSTALL) -m 0644 docs/nstreams-networks 
${DESTDIR}${sysconfdir}/nstreams/nstreams-networks
++
+ distclean : clean
+   rm -f includes/config.h config.cache config.status config.log 
nstreams.tmpl
+   
+--- nstreams-1.0.4.orig/configure.in
 nstreams-1.0.4/configure.in
+@@ -30,8 +30,8 @@ AC_CHECK_LIB(pcap, pcap_open_live,,AC_ER
+ 
+ test "$prefix" = NONE && prefix=/usr/local
+ sysconfdir=${prefix}/etc
+-AC_DEFINE_UNQUOTED(ETC_NSTREAMS_NETWORKS, "${prefix}/etc/nstreams-networks")
+-AC_DEFINE_UNQUOTED(ETC_NSTREAMS_SERVICES, "${prefix}/etc/nstreams-services")
++AC_DEFINE_UNQUOTED(ETC_NSTREAMS_NETWORKS, 
"${sysconfdir}/nstreams/nstreams-networks")

Bug#1067557: ITP: kicad-gruvbox-theme -- Gruvbox colorscheme for KiCad

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: kicad-gruvbox-theme
  Version : 1.1.0
  Upstream Contact: Alexander Brevig
* URL : https://github.com/AlexanderBrevig/kicad-gruvbox-theme
* License : MIT
  Programming Lang: n/a
  Description : Gruvbox colorscheme for KiCadi

A simple gruvbox colorscheme for the EESchema and PCBNew editors within
KiCad. KiCad 8 allows for the system-wide installation of
colorschemes, thus ITP'ing now.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmX++pEVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1ALsP+wZaCyJ09gu+5b3dDFtz4mpYlZ43
VCAt6Jk9AL/19TLhgqx8cLWAXLltsTbmptRfI5po0InQVux3iS8s7DdvqyQ25z3A
JKEAmQuWWWP7FaQ6GqZmUbcLVXC7lts0tLHfBj71TI8LpQn0aeoBKByvfEu30tcX
taZ9pEig/cpp4L2w6Ew7Zhbpb5rSoOwVoISVlB5/w+tihGotyqKd7B+/rVjYyqo+
y2fnRPBDsA/k/H6zPxUPJNp4TR+nebcl9JmWoxwDwQ2RyLxpYEoYyDZw7fryCUIv
TO7uaDfiXBdVAq+zvAYC6fki3MVuShNqHQHDbbWDD/IPi3zlccUkZxc4d0PFsMEo
o8kNsZwNxrQotWV06p3q4ciD62vAbaBimvD0twYSe3RALrcg4FVY6D8VL1A+Ug2l
Yb/p/rzdzneZx6Sw7emoTYnBOLqkuWxV+6QHrE0O5RUt4xYj+OWb/2mXhrLHk8kC
jo47JQJjx06tFZYB8WRWTdDhGYtovFm4ac/ByhFmqwF134eGal48P6O7fJZArckf
8TVeYZT0HgS2v25ITx5rv4gt3fyxli2rjnFH3SKpfE01Mmyeta0ArHIRVj39Nilm
zLAwyal1zuZuQSVp7GWdxptVGTSAURvVI5RFwf9AtNJsNJO2Feg9Sa3GxNl1hphF
cmJqrvQ3sNqCSfny
=ed5N
-END PGP SIGNATURE-

Bug#1067127: marked as done (RFS: emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake sources)

2024-03-23 Thread Tobias Frost

Control: reopen -1
Control: retitle -1 RFS: emacs-cmake-mode/3.29.0+ds-1 [Team] -- Emacs major 
mode for editing CMake sources
Control: forcemerge -1 1067530

> Date: Sat, 23 Mar 2024 00:15:55 -0700
> From: Xiyue Deng 
> To: 1067127-d...@bugs.debian.org
> Subject: Re: Bug#1067127: Acknowledgement (RFS:
>  emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake
>  sources)
> User-Agent: Gnus/5.13 (Gnus v5.13)
> 
> 3.29.0 has just been released.  Will send a new RFS.

Please do not open new RFS when the old one has not been sponsored.
Instead, use the old one and update it accordingly.

Thanks!

> -- 
> Xiyue Deng

Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

2024-03-23 Thread Dima Kogan

> You wrote: "- Each release of "galvani" should have a git tag". Does
> that mean, that every file in the release should have a tag "v_0.34"
> or similar?

Tags apply to the whole repository, not to individual files.

I'm still confused, though. Are you the author of this software? Is
there version control somewhere? You're packaging version 0.34; is there
a version 0.33? Where is it? What are the differences between the two?
What about version 0.35? Is it going to be developed? Where are those
commits going to go?

I'm guessing your development happens in some non-public place, and this
is the first public releaes. Is there a non-public version control? or a
non-public place to download this software? If so, can that version
control (or the release tarballs) be made public as well?

I think there are some (mostly older) Debian packages where upstream
develops behind closed doors, and releases a tarball to the public
periodically. It's unideal, but you can do that too, if that's what you
want.

Whatever we're doing, there has to be a clear idea of where upstream
lives.

Sorry to be a pain, you're just trying to do something nonstandard, and
I don't know what specifically to suggest, yet.

Bug#1067556: nmu: parted_3.6-3.1

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: par...@packages.debian.org
Control: affects -1 + src:parted
User: release.debian@packages.debian.org
Usertags: binnmu

nmu parted_3.6-3.1 . armel armhf . unstable . -m "Rebuild for time_t"

Bug#1067095: Patch for prerelease version of KeePassX 2.7.7 with passkey support enabled

2024-03-23 Thread Guenther Brunthaler

Dear Maintainer,

I created a patch for the most current 2.7.6 version from "sid" to
2.7.7 which compiled fine on a Raspberry Pi 4. It also seemed to work
fine, but I did not yet have time to thoroughly test it.

It works for the upstream source archive which has been downloaded from
[ https://keepassxc.org/download/#code ] as of 2024-03-22.

I enabled passkey support because this was the feature I was interested
in.

Do what you want with it. I don't mind if my ChangeLog entry will be
edited or removed.


Thanks and keep up the good work!

Here is the patch - Hopefully it might save you some work:

 changelog |7 +++
 control   |2 ++
 rules |1 +
 3 files changed, 10 insertions(+)
=
diff -Naur keepassxc-2.7.6/debian/changelog keepassxc-2.7.7/debian/changelog
--- keepassxc-2.7.6/debian/changelog2024-01-04 12:44:35.0 +
+++ keepassxc-2.7.7/debian/changelog2024-03-23 08:07:12.0 +
@@ -1,3 +1,10 @@
+keepassxc (2.7.7+dfsg.1-1~pre1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Pre-release new upstream version with passkey support enabled.
+
+ -- Guenther Brunthaler   Sat, 23 
Mar 2024 09:07:12 +0100
+
 keepassxc (2.7.6+dfsg.1-1) unstable; urgency=medium

   * New upstream version 2.7.6+dfsg.1 (Closes: #1041248)
diff -Naur keepassxc-2.7.6/debian/control keepassxc-2.7.7/debian/control
--- keepassxc-2.7.6/debian/control  2024-01-04 12:44:35.0 +
+++ keepassxc-2.7.7/debian/control  2024-03-23 08:07:12.0 +
@@ -9,6 +9,7 @@
libargon2-dev | libargon2-0-dev,
libbotan-2-dev,
libcurl4-gnutls-dev,
+   libkeyutils-dev,
libminizip-dev,
libpcsclite-dev,
libqrencode-dev,
@@ -16,6 +17,7 @@
libqt5x11extras5-dev,
libreadline-dev,
libusb-1.0-0-dev,
+   libxi-dev,
libxtst-dev,
libzxcvbn-dev,
qtbase5-dev,
diff -Naur keepassxc-2.7.6/debian/rules keepassxc-2.7.7/debian/rules
--- keepassxc-2.7.6/debian/rules2024-01-04 12:44:35.0 +
+++ keepassxc-2.7.7/debian/rules2024-03-23 08:07:12.0 +
@@ -17,6 +17,7 @@
if [ -e src/zxcvbn/ ]; then rm -r src/zxcvbn/ ; fi
dh_auto_configure --  -DWITH_TESTS=$(WITH_TESTS) \
  -DWITH_GUI_TESTS=$(WITH_TESTS) \
+ -DWITH_XC_BROWSER_PASSKEYS=ON \
  -DWITH_XC_UPDATECHECK=OFF \
  -DWITH_XC_ALL=ON

=

Bug#1067555: O: ffmpegthumbnailer -- fast and lightweight video thumbnailer

2024-03-23 Thread Boyuan Yang

Package: wnpp
Control: affects -1 + src:ffmpegthumbnailer
X-Debbugs-Cc: ffmpegthumbnai...@packages.debian.org
Severity: normal

I intend to orphan the ffmpegthumbnailer package. I no longer use this package
anymore. Its upstream is still active though the pace of releasing new versions
is slow.

The package description is:
 FFmpegthumbnailer is a lightweight video thumbnailer that can be used by file
 managers to create thumbnails for your video files. The thumbnailer uses ffmpeg
 to decode frames from the video files, so supported videoformats depend on the
 configuration flags of ffmpeg.

Thanks,
Boyuan Yang


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

Bug#1037521: false positive NONVERBOSE BUILD for rust code in Python modules


Control: retitle -1 False positive NONVERBOSE BUILD for rust code

thanks

On Tue, 13 Jun 2023 18:59:57 +0100 Jelmer =?utf-8?Q?Vernoo=C4=B3?= 
 wrote:


> Package: blhc
> Severity: minor
>
> blhc reports false positives when analyzing build logs for Python
> modules that include rust code.
>
> Example:
>
> $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS} 
${WORKING_DIR}/*.build || [ $? -eq 1 ]

> 75:NONVERBOSE BUILD: Compiling autocfg v1.1.0
> 76:NONVERBOSE BUILD: Compiling proc-macro2 v1.0.60
> 79:NONVERBOSE BUILD: Compiling target-lexicon v0.12.3
> 82:NONVERBOSE BUILD: Compiling unicode-ident v1.0.0
> 84:NONVERBOSE BUILD: Compiling quote v1.0.27
> 90:NONVERBOSE BUILD: Compiling syn v1.0.109
> 92:NONVERBOSE BUILD: Compiling pyo3-build-config v0.19.0
> 98:NONVERBOSE BUILD: Compiling once_cell v1.17.0
> 101:NONVERBOSE BUILD: Compiling libc v0.2.146
> 104:NONVERBOSE BUILD: Compiling serde_derive v1.0.152
> 108:NONVERBOSE BUILD: Compiling pyo3-ffi v0.19.0
> 110:NONVERBOSE BUILD: Compiling lock_api v0.4.9
> 112:NONVERBOSE BUILD: Compiling parking_lot_core v0.9.3
> 114:NONVERBOSE BUILD: Compiling serde v1.0.152
> 116:NONVERBOSE BUILD: Compiling ryu v1.0.2
> 123:NONVERBOSE BUILD: Compiling memoffset v0.6.5
> 125:NONVERBOSE BUILD: Compiling indexmap v1.9.2
> 127:NONVERBOSE BUILD: Compiling smallvec v1.9.0
> 129:NONVERBOSE BUILD: Compiling cfg-if v1.0.0
> 131:NONVERBOSE BUILD: Compiling scopeguard v1.1.0
> 138:NONVERBOSE BUILD: Compiling pyo3-macros-backend v0.19.0
> 141:NONVERBOSE BUILD: Compiling pyo3 v0.19.0
> 143:NONVERBOSE BUILD: Compiling serde_json v1.0.87
> 145:NONVERBOSE BUILD: Compiling hashbrown v0.12.3
> 148:NONVERBOSE BUILD: Compiling unindent v0.1.8
> 150:NONVERBOSE BUILD: Compiling linked-hash-map v0.5.6
> 152:NONVERBOSE BUILD: Compiling yaml-rust v0.4.5
> 154:NONVERBOSE BUILD: Compiling indoc v1.0.4
> 159:NONVERBOSE BUILD: Compiling pyo3-macros v0.19.0
> 162:NONVERBOSE BUILD: Compiling parking_lot v0.12.1
> 166:NONVERBOSE BUILD: Compiling itoa v1.0.1
> 170:NONVERBOSE BUILD: Compiling serde_yaml v0.8.26
> 172:NONVERBOSE BUILD: Compiling lintian-brush v0.148.0 
(/builds/jelmer/lintian-brush/debian/output/source_dir)
> 174:NONVERBOSE BUILD: Compiling lintian-brush-py v0.0.0 
(/builds/jelmer/lintian-brush/debian/output/source_dir/lintian-brush-py)

>
> https://salsa.debian.org/jelmer/lintian-brush/-/jobs/4307243
>

This  holds true  for all rust based projects. See 
https://salsa.debian.org/debian/greetd/-/jobs/4488272 for instance. I 
disabled blhc for all rust projects I maintain for the Salsa CI, but it 
would be nice if that wasn't a hard error.


best,


--
Matthias Geiger 
Debian Maintainer



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

2024-03-23 Thread Thomas Orgis

Hi Sebastian,


Am Sat, 23 Mar 2024 10:40:43 +0100
schrieb Sebastian Ramacher : 

> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_feedseek_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# 
> (arch-bits=32|arch=!x32)mpg123_framebyframe_decode_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_framelength_32@Base 
> 1.23.8
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_framepos_32@Base 1.14.0
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_index_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_length_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_fd_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_fixed_32@Base 
> 1.26.0
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_open_handle_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_position_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_replace_reader_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# 
> (arch-bits=32|arch=!x32)mpg123_replace_reader_handle_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_seek_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_seek_frame_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_set_filesize_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_set_index_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_tell_32@Base 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_tell_stream_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_tellframe_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)mpg123_timeframe_32@Base 
> 1.13.7
> +#MISSING: 1.32.5-1+b1# 
> (arch-bits=32|arch=!x32)syn123_resample_intotal_32@Base 1.26.2
> +#MISSING: 1.32.5-1+b1# (arch-bits=32|arch=!x32)syn123_resample_total_32@Base 
> 1.26.2
> Do you know what's happenig here?

This looks just like the list of wrapper functions offered for
applications that do not enable LFS (_FILE_OFFSET_BITS unset or 32).

Steve mentioned this:

> (you can't enable 64-bit time_t compatibility to use the other
> libraries it calls, without also turning on LFS).

So I take it you build mpg123 with enforced LFS so that the build does
not detect ambiguity in off_t and hence doesn't offer 32 bit wrappers.

I recently took pains to make the actual library code independent of
LFS choice, using explicit 64 bit API. But If you build with
-D_FILE_OFFSET_BITS=64 enforced, mpg123's configure will _not_ set

  lfs_sensitive=yes
  AC_DEFINE(LFS_SENSITIVE, 1, [ System redefines off_t when defining 
_FILE_OFFSET_BITS to 64. ])

as defining the offset bits to 64 doesn't change the size of off_t, so
it looks like a pure 64 bit offset system. But this doesn't control the
symbols, only usage of libmpg123 API by the mpg123 application.

That happens in src/libmpg123/lfs_wrap.c:

off_t attribute_align_arg mpg123_tell(mpg123_handle *mh)
{
int64_t pos = mpg123_tell64(mh);
OFF_RETURN(pos, mh)
}

#if SIZEOF_OFF_T == 4

int attribute_align_arg mpg123_open_32(mpg123_handle *mh, const char *path)
{
return mpg123_open(mh, path);
}

#endif

#if defined(LFS_LARGEFILE_64) || (SIZEOF_OFF_T == 8)

#ifdef LFS_LARGEFILE_64
#define OFF64 off64_t
#else
#define OFF64 off_t
#endif

OFF64 attribute_align_arg mpg123_tell_64(mpg123_handle *mh)
{
return mpg123_tell64(mh);
}

#endif

So, there is the new portable mpg123_tell64 which works with int64_t,
always. There is a 'native' off_t wrapper over this with no suffix. If 
the 'native' off_t is 32 bits, an _32 alias to that is added. If
the 'native' off_t is 64 bits, or if off64_t is available, a _64 alias
is created with _64 suffix.

The changed Debian build seems to trigger the case of 'native 64 bit
off_t'. Is that really an issue if you rebuild all software with that
setting? It should only ever use the _64 symbols. Should we explicitly
add 32 bit wrappers that nobody needs?

What compatibility considerations do you have for that transition? Is
it expected to possibly break user-compiled software that now sees a
changed ABI that that is why all time_t-affected libs get an soname
change?

Do I need to add a

./configure --enable-off_t-is-really-32-bits-please-add-wrappers

?

I could forcibly undef _FILE_OFFSET_BITS in the build to get at the
truth, but since you set that (I presume), my build script should
honour that you do not want to deal with 32 bit off_t. So … does Debian
_want_ 32 bit off_t ABI at all in the 64 bit time_t world?

Or can we just disable that for libmpg123 as time_t is an internal
detail?

Glancing at


https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html

suggests

Bug#1067554: ITP: golang-github-ibm-sarama -- Client library for Apache Kafka

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-ibm-sarama
  Version : 1.43.0-1
  Upstream Author : IBM Corporation
* URL : https://github.com/IBM/sarama
* License : Expat
  Programming Lang: Go
  Description : Client library for Apache Kafka

 sarama is a pure Go client library for dealing with Apache Kafka
 (versions 0.8 and later). It includes a high-level API for easily
 producing and consuming messages, and a low-level API for controlling
 bytes on the wire when the high-level API is insufficient.

This is a new dependency required to update golang-github-openzipkin-
zipkin-go and will be team-maintained within the Go Packaging Team.


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

Bug#1067553: ITP: golang-github-eapache-go-resiliency -- Resiliency patterns for golang (library)

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-eapache-go-resiliency
  Version : 1.6.0-1
  Upstream Author : Evan Huus
* URL : https://github.com/eapache/go-resiliency
* License : Expat
  Programming Lang: Go
  Description : Resiliency patterns for golang (library)

 Resiliency patterns for golang. Based in part on Hystrix, Semian, and
 others. Currently implemented patterns include:
 .
  * circuit-breaker
  * semaphore
  * deadline/timeout
  * batching
  * retriable

This is a new dependency required to update golang-github-openzipkin-
zipkin-go and will be team-maintained within the Go Packaging Team.


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

Bug#1067552: ITP: golang-github-zitadel-schema -- Library to fill a struct with form values

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-zitadel-schema
  Version : 1.3.0-1
  Upstream Author : ZITADEL
* URL : https://github.com/zitadel/schema
* License : BSD-3-Clause
  Programming Lang: Go
  Description : Library to fill a struct with form values

 Package zitadel/schema converts structs to and from form values. This
 is a maintained fork of gorilla/schema.

This is a new dependency required to update golang-github-zitadel-oidc
and will be team-maintained within the Go Packaging Team.


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

Bug#1067551: ITP: golang-github-zitadel-logging -- Logging extension library

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-zitadel-logging
  Version : 0.6.0-1
  Upstream Author : ZITADEL
* URL : https://github.com/zitadel/logging
* License : Apache-2.0
  Programming Lang: Go
  Description : Logging extension library

 Golang logging extension library used by other zitadel projects.

This is a new dependency required to update golang-github-zitadel-oidc
and will be team-maintained within the Go Packaging Team.


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

Bug#1067550: pytest-sourceorder: please consider upgrading to 3.0 source format


Source: pytest-sourceorder
Version: 0.5.1-1
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.

Bug#1001788: neovim: undoing changes results in a mix of old and new text

2024-03-23 Thread James McCoy

On Sat, Jul 16, 2022 at 10:53:01PM -0400, James McCoy wrote:
> On Tue, Mar 01, 2022 at 05:45:35PM +0100, Nicolas Évrard wrote:
> > * James McCoy  [2021-12-17 22:31 +0100]:
> > > On Thu, Dec 16, 2021 at 10:28:18AM +0100, Nicolas Évrard wrote:
> > > > I am sorry for this bug report because it occurs on some rare occurence 
> > > > and I
> > > > don't have a scenario to reproduce it. Yet it's annoying enough to 
> > > > deserve a
> > > > bug report. Feel free to close it as unreproduceable ;).
> > > > 
> > > > With the arrival of LSP I switched my configuration from ALE to the 
> > > > builtin LSP
> > > > for linting and so on. I made this switch some days after the release 
> > > > of neovim
> > > > 0.5.0 ; since that time I have remarked that sometimes (I'd say 2 or 3 
> > > > times a
> > > > month), when I undo my changes (not just one press of 'u' multiple 
> > > > presses), it
> > > > results in a mix of old and new changes.
> > > 
> > > There were a number of fixes in the LSP stuff for 0.6.0, so can you let
> > > me know if you see this again after upgrading to that?
> > 
> > Hello,
> > 
> > So after a while I thought that it had indeed disappeared but I had it twice
> > today :(. It seems to be a problem with the virtual text and treesitter.
> > 
> > Here's a screenshot of the error in action.
> 
> If you encounter this again, can you see if running ":redraw!" fixes it?
> That would help confirm whether it's just a display issue or the buffer
> is actually in a bad state.

Is this something you're still running into?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1007284: searchandrescue: please consider upgrading to 3.0 source format


I am uploading a NMU to DELAYED/10 in order to fix this.
The debdiff is attached.diff -Nru searchandrescue-1.5.0/debian/SearchAndRescue.xpm 
searchandrescue-1.5.0+dfsg/debian/SearchAndRescue.xpm
--- searchandrescue-1.5.0/debian/SearchAndRescue.xpm2024-03-23 
14:21:20.0 +
+++ searchandrescue-1.5.0+dfsg/debian/SearchAndRescue.xpm   1970-01-01 
00:00:00.0 +
@@ -1,268 +0,0 @@
-/* XPM */
-static char *SearchAndRescue[] = {
-/* columns rows colors chars-per-pixel */
-"32 32 230 2",
-"   c #17051486167C",
-".  c #1A81167D1694",
-"X  c #38371703153B",
-"o  c #322B1C31160C",
-"O  c #19C31DA4217D",
-"+  c #2B241DD4213B",
-"@  c #1C942089235D",
-"#  c #22F8215C2528",
-"$  c #2566255D299B",
-"%  c #2A8731F12703",
-"&  c #322032982BE2",
-"*  c #2E7C2C983236",
-"=  c #2C5B320D3712",
-"-  c #31E433463575",
-";  c #38C7350837A3",
-":  c #378936553C95",
-">  c #370A382338DD",
-",  c #3BC13DDA3CFC",
-"<  c #43901BF413F0",
-"1  c #54CC1DFE157A",
-"2  c #743C040900E7",
-"3  c #7B091744092F",
-"4  c #6A5B26A81B08",
-"5  c #71B521241994",
-"6  c #5089261F25A8",
-"7  c #5B34340A2B88",
-"8  c #4CDC3D4A3AED",
-"9  c #56F2337831BA",
-"0  c #78211FBA223E",
-"q  c #777B2F432599",
-"w  c #77033BEF2F30",
-"e  c #68353B3D32A1",
-"r  c #77624717364E",
-"t  c #1B7637BD514D",
-"y  c #1C1A3CF658D0",
-"u  c #2E183B464B22",
-"i  c #39263B9B44F2",
-"p  c #285D3F865719",
-"a  c #5DB13EFC4B05",
-"s  c #377C424A4C64",
-"d  c #2E7742095581",
-"f  c #2BCC44B75C82",
-"g  c #1CD944846C76",
-"h  c #1DDB4ACD7396",
-"j  c #23DF44FC6675",
-"k  c #2DE9478A63C2",
-"l  c #2F204A40642A",
-"z  c #2C2A4B6F6B86",
-"x  c #33A54BE36308",
-"c  c #39234D3161AD",
-"v  c #30984DCE6AE4",
-"b  c #3A384FAE6A07",
-"n  c #369454516F7D",
-"m  c #25624E6574E0",
-"M  c #28284D8C763C",
-"N  c #22844ECA795B",
-"B  c #256B50FB76D3",
-"V  c #2CFE55177682",
-"C  c #24D9530A7C78",
-"Z  c #29C454717D24",
-"A  c #23AC57F77E17",
-"S  c #289857DF7E72",
-"D  c #39325864765D",
-"F  c #3335560A79E4",
-"G  c #34725AE979A0",
-"H  c #3B7B59077B2B",
-"J  c #3CA2620E7E3C",
-"K  c #41C3421442E3",
-"L  c #436047344B5F",
-"P  c #5B5E552C4FEF",
-"I  c #510E53345D48",
-"U  c #6F1D44744BB7",
-"Y  c #791B4A7243DE",
-"T  c #6312529D4E6E",
-"R  c #707E519C4BBB",
-"E  c #610B449E51AB",
-"W  c #6DC8478B4FE7",
-"Q  c #79364F9856D2",
-"!  c #74CC5464567E",
-"~  c #50F753C969E5",
-"^  c #5CE7593C6949",
-"/  c #44335B107228",
-"(  c #4D355F987012",
-")  c #64DC5C6E6604",
-"_  c #61895C0271B7",
-"`  c #4955620C6086",
-"'  c #4C1A65BE6AAB",
-"]  c #497765597DD6",
-"[  c #56CB637B715E",
-"{  c #5113660F7910",
-"}  c #51D368067CDD",
-"|  c #637D63F774A7",
-" . c #6AD064C37293",
-".. c #7B1E640371DB",
-"X. c #66C171DC794A",
-"o. c #81A80E4F0602",
-"O. c #94F615D606D7",
-"+. c #91001DB60F4D",
-"@. c #A6210CD1031E",
-"#. c #B1B91A460C9D",
-"$. c #9FD1282D1788",
-"%. c #90F22E4F1E35",
-"&. c #8BDF347D1F4E",
-"*. c #9BF137091BEB",
-"=. c #B55B245911E6",
-"-. c #B5EC35DB1C80",
-";. c #BB9D311417B9",
-":. c #97D6364D2549",
-">. c #9A99311B1FFB",
-",. c #935D3E212940",
-"<. c #8B95314E34C3",
-"1. c #91EF3DA034B6",
-"2. c #A85132B52025",
-"3. c #A59F35F6282D",
-"4. c #AFD33C5A2AA0",
-"5. c #BF5B35FA2540",
-"6. c #B7503A292157",
-"7. c #C9F41D580A57",
-"8. c #C31C25420B89",
-"9. c #C217271C10B8",
-"0. c #CAE22C6E17D7",
-"q. c #DB8021CC0FC0",
-"w. c #DAF92A9F1646",
-"e. c #C86236C31DC2",
-"r. c #EAE938261E57",
-"t. c #AEFE4706315D",
-"y. c #D8A3416728A1",
-"u. c #DD124A832E6D",
-"i. c #D91A474E31EC",
-"p. c #D7CE48BA347B",
-"a. c #8C1D52C2487C",
-"s. c #82154D2151F2",
-"d. c #95C85DA45879",
-"f. c #A8D34C2A4411",
-"g. c #B15D586F4DD9",
-"h. c #BF6C5B2F4D0B",
-"j. c #A0EC57145246",
-"k. c #ACFB657C5F88",
-"l. c #A0815DCE669D",
-"z. c #890668E965F7",
-"x. c #89E064FE6F14",
-"c. c #9711606E6354",
-"v. c #925B6A166469",
-"b. c #83816A557855",
-"n. c #9BA768BD7232",
-"m. c #8A517C037A39",
-"M. c #A4136FC0",
-"N. c #A4DD775E74AF",
-"B. c #DF2A59C04238",
-"V. c #D55B680553B0",
-"C. c #D9557247586D",
-"Z. c #F73C62014BCA",
-"A. c #DE2F726063AF",
-"S. c #BB7681B77B90",
-"D. c #26D3572380C2",
-"F. c #2999570E8167",
-"G. c #276F5962827F",
-"H. c #2C385B7984C9",
-"J. c #2E5D5E9D8925",
-"K. c #30D95DAF85A9",
-"L. c #30BA5F61896E",
-"P. c #2F6E605C86D8",
-"I. c #2F0361AB8A58",
-"U. c #33EA602885A3",
-"Y. c #3AE7630885EE",
-"T. c #333C63668C3D",
-"R. c #382665C18C58",
-"E. c #36E868D78ED7",
-"W. c #3BA569E68E54",
-"Q. c #2F89674F9097",
-"!. c #35D7668A90B7",
-"~. c #386467AF9136",
-"^. c #362C6AE29323",
-"/. c #3AB56C61947A",
-"(. c #3F746F6698D3",
-"). c #3D5E70C4972F",
-"_. c #3D9F735C9AB5",
-"`. c #444761AC810D",
-"'. c #4625686C8637",
-"]. c #4ABD6DA9878F",
-"[. c #44DE6D828D24",
-"{. c #49BF6B528C81",
-"}. c #525F6AF58433",
-"|. c #52886DED8E16",
-" X c #495471818F61",
-".X c #599475058AB3",
-"XX c #41E66ED7948B",
-"oX c #409C6EB498D7",
-"OX c #420D71FE953D",
-"+X c #420975239C99",
-"@X c #4A27740A9856",
-"#X c #446579099F60",
-"$X c #4D337A339BD7",
-"%X c #53857A629AA4",
-" c #5A747C1C9963",

Bug#1067549: Support arithmetic-encoded JPEGs

2024-03-23 Thread Al Ma

Package: firefox-esr
Version: 115.9.0esr-1~deb12u1
Severity: wishlist
In the upstream issue report on this, 
https://bugzilla.mozilla.org/show_bug.cgi?id=680385 
https://bugzilla.mozilla.org/show_bug.cgi?id=680385, the last statement 38 
contains “webp probably compresses just as well if not better”. This is 
extremely wrong in my tests for a file of mine. As I don't have sufficient 
rights in bugzilla, I ask someone who has sufficient rights to comment there 
and, if possible, reopen the upstream issue report.
Here's my test. My original file, a nonpublic (sorry about that) portrait 
photograph, is of size 1483651 bytes. The goal was to compress it as much as 
possible with GIMP in 1 pass such that the face is still recognizable; we allow 
color artifacts and a heavily rasterized image. Here are the test results (the 
first column is the size in bytes, the second column is the format and the 
settings used for saving):
35623 JPEG, 4:2:0 subsampling, integers
35619 JPEG, 4:2:0 subsampling, float-point numbers
35618 JPEG, 4:2:0 subsampling, fast integers
35254 JPEG, 4:2:0 subsampling, full aliasing, integers
35252 JPEG, 4:2:0 subsampling, full aliasing, float-point numbers
35248 JPEG, 4:2:0 subsampling, full aliasing, fast integers
25656 WEBP, Photo
25484 WEBP, Picture
25364 WEBP, Default
25342 WEBP, Drawing
20720 WEBP, Icon
20720 WEBP, Text
7892 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, integers
7891 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, 
floating-point numbers
7879 JPEG, arithmetic encoding, 4:2:0 subsampling, full aliasing, fast integers
Of course, we used quality 0 in all places.
As we see, the smallest JPEG file created with the arithmetic encoding blows
- the smallest file created with a WEBP encoding by a factor of around 2.6 and
- the smallest JPEG file created without the arithmetic encoding by a factor of 
around 4.5.
Also, both epiphany-browser and chromium do show this smallest file created 
with the arithmetic encoding (and the face on the compressed image is still 
recognizable).
In my view, both news together (astonishing file-size ratios and support in 
other browsers) is sufficient at least to reopen the issue report closed 4 
years ago (regardless of how to resolve this and who would do this).

Bug#1067496: Vertical splits no longer delineated by default

2024-03-23 Thread James McCoy

On Fri, Mar 22, 2024 at 01:42:41PM +, Josh Triplett wrote:
> After upgrading to the new version of neovim, the highlight
> `WinSeparator` (which links to `VertSplit`) no longer has any visible
> setting by default. In previous versions, there was an inverse-video bar
> between windows; now there's only a black bar the same color as normal
> text background, which makes the windows blend together.

Do you see the same issue if you run "nvim --clean"?  Could you include
some screenshots to help show what you're seeing?

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1067416: libglfw3: New upstream version 3.4

2024-03-23 Thread Michel Le Bihan


Hello,

I prepared an update in https://salsa.debian.org/mimi8/glfw3/ . 
Could you please consider using it to update the package?


Michel Le Bihan

On Thu, 21 Mar 2024 11:02:53 +0100 Michel Le Bihan  
wrote:


> Package: libglfw3
> Version: 3.3.10-1
>
> Hello,
>
> A new version on GLFW was released. Version 3.4 added support for 
fractional scaling of window contents on Wayland. Since I'm using 
Wayland on a HiDPI display with fractional scaling enabled, this update 
if important for me. Currently all GLFW windows are blurry and this 
update fixes that.

Bug#1067548: python-netsnmpagent hard codes shared library name

2024-03-23 Thread Matthias Klose


Package: src:python-netsnmpagent
Version: 0.6.0-2
Severity: serious
Tags: sid trixie patch

python-netsnmpagent hard codes shared library name, that name is just 
changed for the t64 time transitions.


patch at
http://launchpadlibrarian.net/720820884/python-netsnmpagent_0.6.0-2build1_0.6.0-2ubuntu1.diff.gz

Bug#1067547: FTBFS: "vsnprintf is so broken we can't compensate. Sorry."

Source: wmweather+
Version: 2.19~alpha+ds-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=wmweather%2B=amd64=2.19%7Ealpha%2Bds-1%2Bb1=1710656065=0

gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/include
-I/usr/include -I/usr/include  -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-
protection -Wformat -Werror=format-security -fcf-protection -Wall   -c -o
vsnprintf.o vsnprintf.c
vsnprintf.c:93:3: error: #error "vsnprintf is so broken we can't compensate.
Sorry."
   93 | # error "vsnprintf is so broken we can't compensate. Sorry."
  |   ^


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067546: FTBFS: ‘struct input_event’ has no member named ‘time’

Source: kluppe
Version: 0.6.20-1.2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=kluppe=armel=0.6.20-1.2%2Bb1=1711015610=0


shuttle.c: In function ‘shuttle_poll’:
shuttle.c:143:48: error: ‘struct input_event’ has no member named ‘time’
  143 | tv = ev.time;
  |^


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067545: FTBFS on 32-bit time64 arches: cannot convert ‘long int’ to ‘time_t’ {aka ‘long long int*’}

Source: klatexformula
Version: 4.1.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=klatexformula=armel=4.1.0-1%2Bb2=1711185211=0

/<>/src/main.cpp: In function ‘void signal_act(int)’:
/<>/src/main.cpp:278:10: error: cannot convert ‘long int*’ to
‘time_t*’ {aka ‘long long int*’}
  278 | time();
  |  ^~~~
  |  |
  |  long int*
In file included from /usr/include/features.h:490,
 from /usr/include/arm-linux-gnueabi/bits/libc-header-
start.h:33,
 from /usr/include/stdio.h:27,
 from /<>/src/main.cpp:24:
/usr/include/time.h:86:15: note:   initializing argument 1 of ‘time_t
time(time_t*)’
   86 | extern time_t __REDIRECT_NTH (time, (time_t *__timer), __time64);
  |   ^~



`curtime` here is explicitly `long`, it should probably just be `time_t`? Same
for `last_sigint_time`.


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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1067512: libglfw3-wayland is practically not installable

2024-03-23 Thread James Cowgill

Control: severity -1 wishlist

Hi Michel,

On 22/03/2024 19:34, Michel Le Bihan wrote:
> Package: libglfw3-wayland
> Version: 3.3.10-1
> 
> Hello,
> 
> I noticed that libglfw3-wayland conflicts with libglfw3. That makes perfect 
> sense since both packages provide the same .so files. However, most packages 
> in Debian depend only on libglfw3. Take pink-pony as an example. It's not 
> possible to have both pink-pony and libglfw3-wayland installed on the same 
> system.

Yes this is the way the packaging is designed and it's intentional. You
can read the reasons I gave many moons ago here:
https://bugs.debian.org/827125

But it boils down to the fact that glfw exports some X11 symbols and if
your application uses some of these functions then it would crash if you
switched to the wayland library. At the time I didn't try working out
another solution and just made both packages conflict with each other.

> I think that either libglfw3 should be a virtual package that depends on 
> libglfw3-wayland or libglfw3-x11 or that libglfw3
> should have both backends enabled.

Now that glfw 3.4 has runtime backend selection, yes we should be able
to fix this fairly easily by turning both backends on at the same time
when we update to 3.4. This isn't an option in 3.3 though.

James

Bug#1065961: [Debian-med-packaging] Bug#1065961: sra-sdk: Please drop dependencies on python3-distutils

2024-03-23 Thread Graham Inggs

Hi Aaron

On Thu, 14 Mar 2024 at 02:03, Aaron M. Ucko  wrote:
> I hear you, but can't readily determine whether any additional changes
> would be in order until dh-python drops or downgrades its distutils
> dependency, which I called out just now:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066833

For what it's worth, sra-sdk was able to build in Ubuntu, where
python3-distutils is already gone from dh-python, after only dropping
the build-dependency in sra-sdk.

Even if this were not the case, I'd say it is safe to drop the
build-dependency now, because if additional changes were required, it
would be detected in the test rebuild following the Python 3.12
transition.

Regards
Graham

Bug#1063909: grub_plugin.py: fails to install grub-ieee1275 on sparc64

2024-03-23 Thread Lars Wirzenius

FYI: I've applied the patch upstream and the test suite passes.
However, I'm not sure the test suite tests vmdb2 in a way that this
patch would affect.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#1067544: bullseye-pu: libmicrohttpd/0.9.72-2+deb11u1.debdiff

2024-03-23 Thread Thorsten Alteholz


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


The attached debdiff for libmicrohttpd fixes CVE-2023-27371 in Bullseye. 
It is marked as no-dsa by the security team.


The fix was uploaded to Buster about a year ago and nobody complained yet.
For whatever reason, the upload to Bullseye was forgotten back then, so I 
catch up on this now.


  Thorsten
diff -Nru libmicrohttpd-0.9.72/debian/changelog 
libmicrohttpd-0.9.72/debian/changelog
--- libmicrohttpd-0.9.72/debian/changelog   2021-02-27 06:47:48.0 
+0100
+++ libmicrohttpd-0.9.72/debian/changelog   2024-03-23 12:03:02.0 
+0100
@@ -1,3 +1,12 @@
+libmicrohttpd (0.9.72-2+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2023-27371
+parsing crafted POST requests result in an out of bounds read, which
+might cause a DoS (Denial of Service)
+
+ -- Thorsten Alteholz   Sat, 23 Mar 2024 12:03:02 +0100
+
 libmicrohttpd (0.9.72-2) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru libmicrohttpd-0.9.72/debian/patches/CVE-2023-27371.patch 
libmicrohttpd-0.9.72/debian/patches/CVE-2023-27371.patch
--- libmicrohttpd-0.9.72/debian/patches/CVE-2023-27371.patch1970-01-01 
01:00:00.0 +0100
+++ libmicrohttpd-0.9.72/debian/patches/CVE-2023-27371.patch2023-03-29 
19:22:12.0 +0200
@@ -0,0 +1,23 @@
+From e0754d1638c602382384f1eface30854b1defeec Mon Sep 17 00:00:00 2001
+From: Christian Grothoff 
+Date: Sun, 26 Feb 2023 17:51:24 +0100
+Subject: fix parser bug that could be used to crash servers using the
+ MHD_PostProcessor
+
+---
+ src/microhttpd/postprocessor.c |  2 +-
+ 1 file changed, 1 insertions(+), 1 deletions(-)
+
+Index: libmicrohttpd-0.9.72/src/microhttpd/postprocessor.c
+===
+--- libmicrohttpd-0.9.72.orig/src/microhttpd/postprocessor.c   2023-03-29 
19:22:08.888629726 +0200
 libmicrohttpd-0.9.72/src/microhttpd/postprocessor.c2023-03-29 
19:22:08.884629728 +0200
+@@ -321,7 +321,7 @@
+   return NULL; /* failed to determine boundary */
+ boundary += MHD_STATICSTR_LEN_ ("boundary=");
+ blen = strlen (boundary);
+-if ( (blen == 0) ||
++if ( (blen < 2) ||
+  (blen * 2 + 2 > buffer_size) )
+   return NULL;  /* (will be) out of memory or invalid 
boundary */
+ if ( (boundary[0] == '"') &&
diff -Nru libmicrohttpd-0.9.72/debian/patches/series 
libmicrohttpd-0.9.72/debian/patches/series
--- libmicrohttpd-0.9.72/debian/patches/series  1970-01-01 01:00:00.0 
+0100
+++ libmicrohttpd-0.9.72/debian/patches/series  2023-03-29 19:21:28.0 
+0200
@@ -0,0 +1 @@
+CVE-2023-27371.patch

Bug#1067543: RFS: miniflux/2.1.1-1 -- minimalist and opinionated feed reader

2024-03-23 Thread Maytham Alsudany

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: jvalle...@mailbox.org

Dear mentors,

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

 * Package name : miniflux
   Version  : 2.1.1-1
   Upstream contact : https://github.com/miniflux/v2/issues
 * URL  : https://miniflux.app
 * License  : Expat, Apache-2.0
 * Vcs  : https://salsa.debian.org/go-team/packages/miniflux
   Section  : web

The source builds the following binary packages:

  miniflux - minimalist and opinionated feed reader

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/miniflux/miniflux_2.1.1-1.dsc

Changes since the last upload:

 miniflux (2.1.1-1) UNRELEASED; urgency=medium
 .
   * New upstream version 2.1.1
   * Fixup scripts, use debconf to prompt user for new admin account credentials
   * Override lintian source-is-missing error for testdata

Regards,
-- 
  Maytham Alsudany

Bug#1007663: searchandrescue-data: please consider upgrading to 3.0 source format