Bug#1086783: kxmlrpcclient FTBFS with nocheck build profile: missing symbols
Source: kxmlrpcclient Version: 5.115.0-2 Severity: serious Justification: nocheck ftbfs is serious since trixie Tags: ftbfs trixie sid Hi, kxmlrpcclient fails to build from source in unstable when enabling the nocheck build profile due to missing symbols. A build ends as follows: |dh_makeshlibs -a -Xusr/lib/libkdeinit5_\* -O--buildsystem=kf5 | dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below | dpkg-gensymbols: warning: debian/libkf5xmlrpcclient5/DEBIAN/symbols doesn't match completely debian/libkf5xmlrpcclient5.symbols | --- debian/libkf5xmlrpcclient5.symbols (libkf5xmlrpcclient5_5.115.0-2_amd64) | +++ dpkg-gensymbolsl6KJyr 2024-11-05 19:33:33.408250206 + | @@ -1,14 +1,14 @@ | libKF5XmlRpcClient.so.5 libkf5xmlrpcclient5 #MINVER# | * Build-Depends-Package: libkf5xmlrpcclient-dev | - _ZN7KXmlRpc12QueryPrivate10markupCallERK7QStringRK5QListI8QVariantE@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate10slotResultEP4KJob@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate15isFaultResponseERK12QDomDocument@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate17isMessageResponseERK12QDomDocument@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate18parseFaultResponseERK12QDomDocument@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate20parseMessageResponseERK12QDomDocument@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate7marshalERK8QVariant@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate8slotDataEPN3KIO3JobERK10QByteArray@Base 5.36.0 | - _ZN7KXmlRpc12QueryPrivate9demarshalERK11QDomElement@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate10markupCallERK7QStringRK5QListI8QVariantE@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate10slotResultEP4KJob@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate15isFaultResponseERK12QDomDocument@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate17isMessageResponseERK12QDomDocument@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate18parseFaultResponseERK12QDomDocument@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate20parseMessageResponseERK12QDomDocument@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate7marshalERK8QVariant@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate8slotDataEPN3KIO3JobERK10QByteArray@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc12QueryPrivate9demarshalERK11QDomElement@Base 5.36.0 | _ZN7KXmlRpc5Query11qt_metacallEN11QMetaObject4CallEiPPv@Base 5.7.50 | _ZN7KXmlRpc5Query11qt_metacastEPKc@Base 5.7.50 | _ZN7KXmlRpc5Query16staticMetaObjectE@Base 5.7.50 | @@ -44,17 +44,17 @@ | _ZN7KXmlRpc6ClientD0Ev@Base 5.7.50 | _ZN7KXmlRpc6ClientD1Ev@Base 5.7.50 | _ZN7KXmlRpc6ClientD2Ev@Base 5.7.50 | - _ZN7KXmlRpc6ResultC1Ev@Base 5.36.0 | - _ZN7KXmlRpc6ResultC2Ev@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc6ResultC1Ev@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZN7KXmlRpc6ResultC2Ev@Base 5.36.0 | _ZNK7KXmlRpc5Query10metaObjectEv@Base 5.7.50 | _ZNK7KXmlRpc6Client10metaObjectEv@Base 5.7.50 | _ZNK7KXmlRpc6Client19isDigestAuthEnabledEv@Base 5.7.50 | _ZNK7KXmlRpc6Client3urlEv@Base 5.7.50 | _ZNK7KXmlRpc6Client9userAgentEv@Base 5.7.50 | - _ZNK7KXmlRpc6Result11errorStringEv@Base 5.36.0 | - _ZNK7KXmlRpc6Result4dataEv@Base 5.36.0 | - _ZNK7KXmlRpc6Result7successEv@Base 5.36.0 | - _ZNK7KXmlRpc6Result9errorCodeEv@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZNK7KXmlRpc6Result11errorStringEv@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZNK7KXmlRpc6Result4dataEv@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZNK7KXmlRpc6Result7successEv@Base 5.36.0 | +#MISSING: 5.115.0-2# _ZNK7KXmlRpc6Result9errorCodeEv@Base 5.36.0 | _ZTIN7KXmlRpc5QueryE@Base 5.7.50 | _ZTIN7KXmlRpc6ClientE@Base 5.7.50 | _ZTSN7KXmlRpc5QueryE@Base 5.7.50 | dh_makeshlibs: error: failing due to earlier errors | make: *** [debian/rules:6: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Helmut
Bug#1086784: imagemagick FTCBFS: multiple reasons
Source: imagemagick
Version: 8:7.1.1.39+dfsg1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs
Hi,
imagemagick fails to cross build from source for multiple reason.
The first stumbling block is the g++ dependency. Rather than figure out
why, I checked that it is satisfied in buster, so we can simply drop it.
It actually starts building then until it passes host architecture
compiler flags to the build archiecture compiler used for building
PerlMagick. For cross compiling Perl stuff, one should extend the Perl
include path with the cross configuration directory. This fixes the
PerlMagick part.
Then, converting the icons cache fails as the built convert cannot be
run. I propose adding a recursive build dependency conditional to cross
compilation and then using that rather than building imagemagick twice.
And with all of that, it actually cross builds. I'm attaching a patch
containing all of the mentioned changes for your convenience.
Helmut
diff --minimal -Nru imagemagick-7.1.1.39+dfsg1/debian/changelog
imagemagick-7.1.1.39+dfsg1/debian/changelog
--- imagemagick-7.1.1.39+dfsg1/debian/changelog 2024-10-27 19:45:43.0
+0100
+++ imagemagick-7.1.1.39+dfsg1/debian/changelog 2024-11-05 17:21:45.0
+0100
@@ -1,3 +1,13 @@
+imagemagick (8:7.1.1.39+dfsg1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: (Closes: #-1)
++ Drop versioned g++ dependency satisfied in buster.
++ Export PERL5LIB for cross building.
++ Use the installed convert for generating the icons cache.
+
+ -- Helmut Grohne Tue, 05 Nov 2024 17:21:45 +0100
+
imagemagick (8:7.1.1.39+dfsg1-1) unstable; urgency=medium
* New upstream version
diff --minimal -Nru imagemagick-7.1.1.39+dfsg1/debian/control
imagemagick-7.1.1.39+dfsg1/debian/control
--- imagemagick-7.1.1.39+dfsg1/debian/control 2024-10-19 17:16:30.0
+0200
+++ imagemagick-7.1.1.39+dfsg1/debian/control 2024-11-05 17:21:45.0
+0100
@@ -11,8 +11,6 @@
dpkg-dev (>= 1.22.5),
# for improving build
dh-exec,
-# ABI dump
- g++ (>= 4:7),
# for linking compiling ...
pkgconf, libltdl-dev,
# for libtool does not link to depends lib
@@ -40,7 +38,9 @@
# for libgomp symbols
dpkg-dev (>= 1.17.6),
# for perltest versioned due to name change
- fonts-tuffy (>= 20120614-3~)
+ fonts-tuffy (>= 20120614-3~),
+# for building icons cache
+ imagemagick ,
# for documentation
Build-Depends-Indep: doxygen, doxygen-latex, graphviz,
libxml2-utils,
diff --minimal -Nru imagemagick-7.1.1.39+dfsg1/debian/rules
imagemagick-7.1.1.39+dfsg1/debian/rules
--- imagemagick-7.1.1.39+dfsg1/debian/rules 2024-08-20 11:23:17.0
+0200
+++ imagemagick-7.1.1.39+dfsg1/debian/rules 2024-11-05 17:21:45.0
+0100
@@ -43,9 +43,19 @@
export MAGICK ?= ./magick.sh magick
export CONVERT ?= $(MAGICK) convert
VALGRIND_CONVERT ?= ./libtool --mode=execute valgrind $(CONVERT)
+ifneq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+CROSS_CONVERT = convert
+else
+CROSS_CONVERT = $(CONVERT)
+endif
CONVERT_FLAGS ?= -background none -define filter:blur=0.75 -filter Gaussian
# perl path
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+PERLVER := $(shell perl -MConfig -e 'print $$Config{version}')
+PERL5LIB := /usr/lib/$(DEB_HOST_MULTIARCH)/perl/cross-config-$(PERLVER)$(if
$(PERL5LIB),:$(PERL5LIB))
+export PERL5LIB
+endif
export DEB_PERL_ARCHLIB := $(shell perl -MConfig -e 'print
$$Config{vendorarch}')
@@ -493,7 +503,7 @@
mkdir -p
$(CURDIR)/debian/tmp-$*/usr/share/icons/hicolor/$$SIZE/apps/ ;\
cd $(CURDIR)/debian/build-quantum-$*; \
echo "Make icons for size $$SIZE..."; \
- $(CONVERT) $(CURDIR)/debian/display-im$(IMVERSION).svg \
+ $(CROSS_CONVERT) $(CURDIR)/debian/display-im$(IMVERSION).svg \
$(CONVERT_FLAGS) -resize $$SIZE \
-gravity center -extent $$SIZE \
+set date:create +set date:modify -define
png:exclude-chunk=time \
Bug#1086730: gsl FTCBFS: explicit toolchain dependencies not satisfiable
Hi Dirk, On Mon, Nov 04, 2024 at 04:26:23PM -0600, Dirk Eddelbuettel wrote: > On 4 November 2024 at 22:18, Helmut Grohne wrote: > | Source: gsl > | Version: 2.8+dfsg-4 > | Tags: patch > | User: debian-cr...@lists.debian.org > | Usertags: cross-satisfiability > | > | gsl cannot be cross built from source, because its dependencies on gcc > | and binutils cannot satisfied. They need "toolchain dependency cross > | translation" which has been unavailable until earlier this year. > > I read this paragraph three times and still do not understand. The > constraint was there for years, possibly a decade, and always satisfied. I vaguely feared that and tried to cut down unnecessary detail, but evidently went too far. > What does "toolchain dependency cross translation" mean? What does it > change? If you depend on a compiler (including binutils), you currently are not precise what architecture you are compiling for. This used to be fine when we did native builds only as the implied architecture simply was the native one. Now when cross building, you mostly want to compile for the machine you are cross compiling for and sometimes want to compile for the machine you are building on (in order to run something compiled during build). This is an extra bit of information that was not needed earlier. Therefore, we will have to touch each and every dependency on a compiler in the archive and change it expressing this extra information. Roughly speaking the way forward is to append "-for-host" to the compiler package name for the cross compiler and "-for-build" when you want to compile a build tool to be run during build. Let me know if you want more detail and I'll expand. > (I did see posts from you on debian-science but I haven't followed super > closely ...) That's quite related. It's a deep topic and d-science just happens to be affected early, but it really affects more of Debian, which is why I originally posted it to d-cross@l.d.o and d-toolchain@l.d.o only. I'm glad for feedback, but I also understand if you want to skip that part. > Thanks, I think I will fold it in. We can do with with the versioned depends. I hope this is a typo and you meant s/with/without/. Helmut
Bug#1086767: Should golang-github-jesseduffield-termbox-go be removed from unstable?
Source: golang-github-jesseduffield-termbox-go Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing golang-github-jesseduffield-termbox-go from Debian for the following reasons: * It accumulated one RC-bug: + #1032114: Don't release with bookworm Last modified: 1 year, 4 months * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: golang-github-jesseduffield-termbox-go -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:golang-github-jesseduffield-termbox-go Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082074: Proceeding with removal of swfmill
Control: severity 1082074 normal Control: retitle 1082074 RM: swfmill -- RoQA; rc-buggy Control: reassign 1082074 ftp.debian.org Control: affects 1082074 + src:swfmill Dear swfmill maintainer and ftp team, a month has passed since filing a suggestion to remove swfmill from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1019600: swfmill: CVE-2022-36139 CVE-2022-36144 Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086765: kdiagram FTBFS with the nocheck build profile: missing symbols
Source: kdiagram Version: 2.8.0-1 Severity: serious Justification: nocheck ftbfs is serious since trixie Tags: ftbfs trixie sid Hi, kdiagram fails to build from source when built with the nocheck build profile. A build ends as follows: |dh_makeshlibs -a | dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below | dpkg-gensymbols: warning: debian/libkgantt2/DEBIAN/symbols doesn't match completely debian/libkgantt2.symbols | --- debian/libkgantt2.symbols (libkgantt2_2.8.0-1_amd64) | +++ dpkg-gensymbolsWmP1Ng 2024-11-05 09:30:11.036325593 + | @@ -1,15 +1,15 @@ | libKGantt.so.2 libkgantt2 #MINVER# | * Build-Depends-Package: libkgantt-dev | - _ZN4KDAB8UnitTest12TestRegistry14deleteInstanceEv@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistry19registerTestFactoryEPKNS0_11TestFactoryEPKc@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistry5mSelfE@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistry8instanceEv@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistryC1Ev@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistryC2Ev@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistryD1Ev@Base 2.6.0 | - _ZN4KDAB8UnitTest12TestRegistryD2Ev@Base 2.6.0 | - _ZN4KDAB8UnitTest6RunnerD1Ev@Base 2.6.0 | - _ZN4KDAB8UnitTest6RunnerD2Ev@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistry14deleteInstanceEv@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistry19registerTestFactoryEPKNS0_11TestFactoryEPKc@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistry5mSelfE@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistry8instanceEv@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistryC1Ev@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistryC2Ev@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistryD1Ev@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest12TestRegistryD2Ev@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest6RunnerD1Ev@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZN4KDAB8UnitTest6RunnerD2Ev@Base 2.6.0 | _ZN6KGantt10Constraint10setDataMapERK4QMapIi8QVariantE@Base 2.6.0 | _ZN6KGantt10Constraint7setDataEiRK8QVariant@Base 2.6.0 | _ZN6KGantt10ConstraintC1ERK11QModelIndexS3_NS0_4TypeENS0_12RelationTypeERK4QMapIi8QVariantE@Base 2.6.0 | @@ -399,9 +399,9 @@ | _ZN6KGantt6LegendD0Ev@Base 2.6.0 | _ZN6KGantt6LegendD1Ev@Base 2.6.0 | _ZN6KGantt6LegendD2Ev@Base 2.6.0 | - _ZNK4KDAB8UnitTest12TestRegistry3runEPKc@Base 2.6.0 | - _ZNK4KDAB8UnitTest12TestRegistry3runEv@Base 2.6.0 | - _ZNK4KDAB8UnitTest6Runner3runEPKc@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZNK4KDAB8UnitTest12TestRegistry3runEPKc@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZNK4KDAB8UnitTest12TestRegistry3runEv@Base 2.6.0 | +#MISSING: 2.8.0-1# _ZNK4KDAB8UnitTest6Runner3runEPKc@Base 2.6.0 | _ZNK6KGantt10Constraint10startIndexEv@Base 2.6.0 | _ZNK6KGantt10Constraint12relationTypeEv@Base 2.6.0 | _ZNK6KGantt10Constraint14compareIndexesERKS0_@Base 2.6.0 | dh_makeshlibs: error: failing due to earlier errors | make: *** [debian/rules:6: binary] Error 25 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Helmut
Bug#1086766: kimap FTBFS with the nocheck build profile: missing files
Source: kimap Version: 22.12.3-1 Severity: serious Tags: ftbfs trixie sid Justification: nocheck ftbfs is serious since trixie Hi, kimap fails to build from source when enabling the nocheck build profile. A build ends as follows: |dh_install | dh_install: warning: Cannot find (any matches for) "usr/include/KF5/KIMAPTest/kimaptest/fakeserver.h" (tried in ., debian/tmp) | | dh_install: warning: libkf5imap-dev missing files: usr/include/KF5/KIMAPTest/kimaptest/fakeserver.h | dh_install: warning: Cannot find (any matches for) "usr/include/KF5/KIMAPTest/kimaptest/mockjob.h" (tried in ., debian/tmp) | | dh_install: warning: libkf5imap-dev missing files: usr/include/KF5/KIMAPTest/kimaptest/mockjob.h | dh_install: warning: Cannot find (any matches for) "usr/lib/*/libkimaptest.a" (tried in ., debian/tmp) | | dh_install: warning: libkf5imap-dev missing files: usr/lib/*/libkimaptest.a | dh_install: error: missing files, aborting | make: *** [debian/rules:11: binary] Error 255 | dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 I suspect that the upstream build system uses BUILD_TESTING (which is passed by debhelper) to conditionalize tests and has install rules in thus guarded files. Helmut
Bug#1086729: efivar FTCBFS: multiple reasons
Source: efivar
Version: 38-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
efivar fails to cross build from source for multiple, subtle reasons. It
basically has cross compilation support, but its use of variables is
very much unlike what dh_auto_build passes:
* The CC is expected to come without an architecture prefix as it wants
to prepend $(CROSS_COMPILE).
* What dpkg calls CC_FOR_BUILD is called HOSTCC.
* What dpkg calls CFLAGS_FOR_BUILD is called HOST_CFLAGS.
Beyond this, the upstream attempts to link util.o into both build
architecture and host architecture binaries. That doesn't work. Thus I
propose to rename "host" (in efivars terms, "build" in Debian terms)
objects to %.host.o to distinguish them from "normal" (untermed in
efivars, "host" in Debian terms) objects.
I agree that this is all very confusing, but I'm offering a working
patch for your convenience.
Helmut
diff --minimal -Nru efivar-38/debian/changelog efivar-38/debian/changelog
--- efivar-38/debian/changelog 2024-02-28 03:57:40.0 +0100
+++ efivar-38/debian/changelog 2024-11-04 15:35:27.0 +0100
@@ -1,3 +1,12 @@
+efivar (38-3.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTCBFS: (Closes: #-1)
++ Pass the right variables to make.
++ cross.patch: Use different names for build and host objects.
+
+ -- Helmut Grohne Mon, 04 Nov 2024 15:35:27 +0100
+
efivar (38-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru efivar-38/debian/patches/cross.patch
efivar-38/debian/patches/cross.patch
--- efivar-38/debian/patches/cross.patch1970-01-01 01:00:00.0
+0100
+++ efivar-38/debian/patches/cross.patch2024-11-04 15:35:27.0
+0100
@@ -0,0 +1,32 @@
+--- efivar-38.orig/src/Makefile
efivar-38/src/Makefile
+@@ -29,7 +29,7 @@
+ EFISECDB_OBJECTS = $(patsubst %.S,%.o,$(patsubst %.c,%.o,$(EFISECDB_SOURCES)))
+ GENERATED_SOURCES = include/efivar/efivar-guids.h guid-symbols.c
+ MAKEGUIDS_SOURCES = makeguids.c util.c
+-MAKEGUIDS_OBJECTS = $(patsubst %.S,%.o,$(patsubst
%.c,%.o,$(MAKEGUIDS_SOURCES)))
++MAKEGUIDS_OBJECTS = $(patsubst %.S,%.host.o,$(patsubst
%.c,%.host.o,$(MAKEGUIDS_SOURCES)))
+ MAKEGUIDS_OUTPUT = $(GENERATED_SOURCES) guids.lds
+
+ ALL_SOURCES=$(LIBEFISEC_SOURCES) $(LIBEFIBOOT_SOURCES) $(LIBEFIVAR_SOURCES) \
+--- efivar-38.orig/src/include/rules.mk
efivar-38/src/include/rules.mk
+@@ -58,12 +58,18 @@
+ %.static.o : %.c
+ $(CC) $(CFLAGS) -fPIE $(CPPFLAGS) -c -o $@ $(filter %.c %.o %.S,$^)
+
++%.host.o : %.c
++ $(HOSTCC) $(HOST_CFLAGS) -fPIE $(HOST_CPPFLAGS) -c -o $@ $(filter %.c
%.o %.S,$^)
++
+ %.o : %.S
+ $(CC) $(CFLAGS) -fPIC $(CPPFLAGS) -c -o $@ $(filter %.c %.o %.S,$^)
+
+ %.static.o : %.S
+ $(CC) $(CFLAGS) -fPIE $(CPPFLAGS) -c -o $@ $(filter %.c %.o %.S,$^)
+
++%.host.o : %.c
++ $(HOSTCC) $(HOST_CFLAGS) -fPIE $(HOST_CPPFLAGS) -c -o $@ $(filter %.c
%.o %.S,$^)
++
+ %.S: %.c
+ $(CC) $(CFLAGS) $(CPPFLAGS) -S $< -o $@
+
diff --minimal -Nru efivar-38/debian/patches/series
efivar-38/debian/patches/series
--- efivar-38/debian/patches/series 2023-11-29 15:23:32.0 +0100
+++ efivar-38/debian/patches/series 2024-11-04 15:35:27.0 +0100
@@ -1,2 +1,3 @@
0001-linux-handle-non-ACPI-systems-in-device_get.patch
0002_no_host_march.patch
+cross.patch
diff --minimal -Nru efivar-38/debian/rules efivar-38/debian/rules
--- efivar-38/debian/rules 2023-11-01 01:40:55.0 +0100
+++ efivar-38/debian/rules 2024-11-04 15:35:27.0 +0100
@@ -5,6 +5,7 @@
#export DH_OPTIONS=-V
include /usr/share/dpkg/default.mk
+include /usr/share/dpkg/buildtools.mk
ifeq ($(DEB_HOST_ARCH),amd64)
export DEB_CFLAGS_MAINT_APPEND+= -fcf-protection
@@ -14,11 +15,24 @@
%:
dh $@
+BUILD_SETTINGS := 'LIBDIR=$${PREFIX}/lib/$(DEB_HOST_MULTIARCH)'
+ifeq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+BUILD_SETTINGS += 'CC=$(CC)'
+else
+# Note that the build system overrides CC and prepends $(CROSS_COMPILE).
+BUILD_SETTINGS += \
+ 'CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)-' \
+ 'CC=$(subst $(DEB_HOST_GNU_TYPE)-,,$(CC))'
+endif
+BUILD_SETTINGS += \
+ 'HOSTCC=$(CC_FOR_BUILD)' \
+ 'HOST_CFLAGS=$(CFLAGS_FOR_BUILD)'
+
override_dh_auto_build:
- dh_auto_build -- LIBDIR=\$${PREFIX}/lib/$(DEB_HOST_MULTIARCH)
CROSS_COMPILE=$(DEB_HOST_GNU_TYPE)-
+ dh_auto_build -- $(BUILD_SETTINGS)
override_dh_auto_install:
- dh_auto_install -- LIBDIR=\$${PREFIX}/lib/$(DEB_HOST_MULTIARCH)
+ dh_auto_install -- $(BUILD_SETTINGS)
override_dh_auto_test:
dh_auto_test -- GRUB_PREFIX=grub
Bug#1086731: z3 FTCBFS: python3 dependency not installable
Source: z3
Version: 4.8.12-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
z3 cannot be cross built from source, because its python3 dependency
fails to install. A host architecture Python fails postinst, but it also
is not what z3 needs for building as it wants to run Python during
build.
In a divide and conquer approach, I first looked into adding support for
a nopython build profile such that the separate bindings could be
approached separately. Doing so, I recommend using dh-sequence-*
build-dependencies as they can be conditionalized using build profiles.
Likewise, I recommend installing the documentation symlink using
dh_installdocs --linkdoc, because it also handles build profiles at no
extra effort. While at it, I noticed that the libz3-java -> libz3-dev
dependency is not tight enough for using --linkdoc. Completely removing
Python dependencies happens to break the build, because even with
-DZ3_BUILD_PYTHON_BINDINGS=OFF Python and setuptools are being used, so
we need to depend on those without a profile.
It turns out that a nojava+nopython cross build just works. The z3
Python module is based on ctypes. From a packaging point of view, this
mostly means we can handle it as if it was a pure Python module. Hence,
annotating the python3 dependency with :any or :native is reasonable.
Once doing so, a nojava cross build also succeeds.
Cross building with java is a more distant topic not solved here. The
javahelper package is Arch:all and implicitly M-A:no. Any package
depending on it currently cannot satisfy its cross Build-Depends. This
is a problem that should be solved at the javahelper side rather than
here.
Given all of this, I am attaching a patch fixing all mentioned issues
but the javahelper one. Please let me know if this change is acceptable
or whether I should split it into smaller pieces for the individual
problems.
Helmut
diff --minimal -Nru z3-4.8.12/debian/changelog z3-4.8.12/debian/changelog
--- z3-4.8.12/debian/changelog 2023-02-01 13:06:03.0 +0100
+++ z3-4.8.12/debian/changelog 2024-11-04 16:15:47.0 +0100
@@ -1,3 +1,16 @@
+z3 (4.8.12-3.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Improve cross building. (Closes: #-1)
++ Multiarchify python3 dependency.
+ * Add nopython build profile.
++ Conditionalize debhelper addons via Build-Depends.
++ Let debhelper conditionalize --link-doc based on profiles.
++ Unconditional python3-setuptools dependency needed even with .
+ * Tighten libz3-java -> libz3-dev dependency for doc linking.
+
+ -- Helmut Grohne Mon, 04 Nov 2024 16:15:47 +0100
+
z3 (4.8.12-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff --minimal -Nru z3-4.8.12/debian/control z3-4.8.12/debian/control
--- z3-4.8.12/debian/control2023-02-01 13:01:38.0 +0100
+++ z3-4.8.12/debian/control2024-11-04 16:15:47.0 +0100
@@ -4,8 +4,9 @@
Maintainer: LLVM Packaging Team
Uploaders: Fabian Wolff
Build-Depends: debhelper-compat (= 13),
- dh-python, python3, cmake, libsimde-dev,
- javahelper [!hppa !hurd-i386 !m68k !sh4] ,
+ cmake, libsimde-dev, python3:any, python3-setuptools,
+ dh-sequence-python3 ,
+ dh-sequence-javahelper [!hppa !hurd-i386 !m68k !sh4] ,
default-jdk [!hppa !hurd-i386 !m68k !sh4]
Standards-Version: 4.6.0
Homepage: https://github.com/Z3Prover/z3
@@ -60,6 +61,7 @@
Package: python3-z3
Section: python
Architecture: any
+Build-Profiles:
Pre-Depends: ${misc:Pre-Depends}
Depends: libz3-dev (= ${binary:Version}),
python3-pkg-resources,
@@ -76,7 +78,7 @@
Build-Profiles:
Section: java
Architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc
ppc64el s390x alpha kfreebsd-amd64 kfreebsd-i386 powerpcspe riscv64 sparc64 x32
-Depends: libz3-jni (>= ${binary:Version}), libz3-jni (<<
${source:Version}.1~), libz3-dev, ${misc:Depends}, ${java:Depends}
+Depends: libz3-jni (>= ${binary:Version}), libz3-jni (<<
${source:Version}.1~), libz3-dev (= ${binary:Version}), ${misc:Depends},
${java:Depends}
Description: theorem prover from Microsoft Research - java bindings
Z3 is a state-of-the-art theorem prover from Microsoft Research. See the z3
package for a detailed description.
diff --minimal -Nru z3-4.8.12/debian/rules z3-4.8.12/debian/rules
--- z3-4.8.12/debian/rules 2023-02-01 13:04:59.0 +0100
+++ z3-4.8.12/debian/rules 2024-11-04 16:15:47.0 +0100
@@ -12,30 +12,26 @@
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-ifneq (,$(shell dh_listpackages -a | grep libz3-jni))
-WITH_JAVA ?= ON
-WITH_JAVAHELPER ?= ,javahelper
-else
-WITH_JAVA ?= OFF
-WITH_JAVAHELPER ?=
-endif
+DOPACKAGES := $(shell dh_listpackages)
+WITH_JAVA := $(if $(filter libz3-jni,$(DOPACKAGES)),ON,OFF)
+WITH_PYTHON := $(if $(filter python3-z3,$(DOPACKAGES)),ON,OFF)
export
Bug#1086732: libuv1 FTCBFS: sphinx dependency not satisfiable
Source: libuv1 Version: 1.48.0-6 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability libuv1 cannot be cross built from source, because its dependency on sphinx is not satisfiable. Rather than figure out a way to make this work, I observe that it is only needed for building libuv1-doc, which happens to be an Arch:all package and thus irrelevant to cross building. So the easier solution here is to move the sphinx dependencies to Build-Depends-Indep and that's all it takes to make libvu1 cross buildable. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru libuv1-1.48.0/debian/changelog libuv1-1.48.0/debian/changelog --- libuv1-1.48.0/debian/changelog 2024-09-04 17:11:33.0 +0200 +++ libuv1-1.48.0/debian/changelog 2024-11-04 10:23:40.0 +0100 @@ -1,3 +1,10 @@ +libuv1 (1.48.0-6.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Move sphinx dependencies to B-D-I. (Closes: #-1) + + -- Helmut Grohne Mon, 04 Nov 2024 10:23:40 +0100 + libuv1 (1.48.0-6) unstable; urgency=medium [ Olivier Valentin ] diff --minimal -Nru libuv1-1.48.0/debian/control libuv1-1.48.0/debian/control --- libuv1-1.48.0/debian/control2024-09-04 17:11:33.0 +0200 +++ libuv1-1.48.0/debian/control2024-11-04 10:23:02.0 +0100 @@ -6,10 +6,10 @@ Build-Depends: cmake, debhelper-compat (= 13), dh-exec, - dh-sequence-sphinxdoc , netbase, pkgconf, - sphinx +Build-Depends-Indep: dh-sequence-sphinxdoc , + sphinx , Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/debian/libuv1 Vcs-Git: https://salsa.debian.org/debian/libuv1.git diff --minimal -Nru libuv1-1.48.0/debian/rules libuv1-1.48.0/debian/rules --- libuv1-1.48.0/debian/rules 2024-09-04 17:11:33.0 +0200 +++ libuv1-1.48.0/debian/rules 2024-11-04 10:23:38.0 +0100 @@ -39,5 +39,5 @@ sphinx-build -D html_theme=default docs/src/ $(CURDIR)/debian/libuv1-doc/usr/share/doc/libuv1/html endif -execute_after_dh_installdocs: +execute_after_dh_installdocs-indep: rm -f $(CURDIR)/debian/libuv1-doc/usr/share/doc/libuv1-dev/code/.gitignore
Bug#1086730: gsl FTCBFS: explicit toolchain dependencies not satisfiable
Source: gsl Version: 2.8+dfsg-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability gsl cannot be cross built from source, because its dependencies on gcc and binutils cannot satisfied. They need "toolchain dependency cross translation" which has been unavailable until earlier this year. However, it turns out that these dependencies are always satisfied for native builds since at least buster, so we may just drop them instead. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru gsl-2.8+dfsg/debian/changelog gsl-2.8+dfsg/debian/changelog --- gsl-2.8+dfsg/debian/changelog 2024-10-29 00:21:35.0 +0100 +++ gsl-2.8+dfsg/debian/changelog 2024-11-04 22:04:01.0 +0100 @@ -1,3 +1,11 @@ +gsl (2.8+dfsg-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1), gcc (>= 4:4.0), binutils (>= 2.12.90.0.9) ++ Drop versioned gcc and binutils dependencies satisfied before buster. + + -- Helmut Grohne Mon, 04 Nov 2024 22:04:01 +0100 + gsl (2.8+dfsg-4) unstable; urgency=medium * siman/siman.c: Assert n_tries > 0 [CVE-2024-50610] (Closes: #1086206) diff --minimal -Nru gsl-2.8+dfsg/debian/control gsl-2.8+dfsg/debian/control --- gsl-2.8+dfsg/debian/control 2024-05-25 19:58:56.0 +0200 +++ gsl-2.8+dfsg/debian/control 2024-11-04 22:04:00.0 +0100 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Dirk Eddelbuettel Standards-Version: 4.7.0 -Build-Depends: gawk | awk, debhelper-compat (= 13), gcc (>= 4:4.0), binutils (>= 2.12.90.0.9) +Build-Depends: gawk | awk, debhelper-compat (= 13) Vcs-Browser: https://salsa.debian.org/edd/gsl Vcs-Git: https://salsa.debian.org/edd/gsl.git Homepage: https://www.gnu.org/software/gsl
Bug#1086690: lerc FTCBFS: python dependencies not satisfiable
Source: lerc Version: 4.0.0+ds-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability lerc cannot be cross built from source, because its python-related build dependencies cannot be satisfied. Turns out we don't have to think much about them, because python3-lerc is an architecture-independent package and by skipping it in an arch-only build, we can skip the problem. When doing so, tow minor complications arise. The clean target cannot be easily split, so cleaning the python module needs to be conditional to the presence of pybuild. For another, the python3-numpy dependency still is needed in an arch-only build for testing only. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru lerc-4.0.0+ds/debian/changelog lerc-4.0.0+ds/debian/changelog --- lerc-4.0.0+ds/debian/changelog 2023-12-03 17:46:30.0 +0100 +++ lerc-4.0.0+ds/debian/changelog 2024-11-03 22:05:08.0 +0100 @@ -1,3 +1,10 @@ +lerc (4.0.0+ds-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Demote python dependencies to B-D-I. (Closes: #-1) + + -- Helmut Grohne Sun, 03 Nov 2024 22:05:08 +0100 + lerc (4.0.0+ds-4) unstable; urgency=medium * New d/clean file. diff --minimal -Nru lerc-4.0.0+ds/debian/control lerc-4.0.0+ds/debian/control --- lerc-4.0.0+ds/debian/control2023-12-03 17:46:30.0 +0100 +++ lerc-4.0.0+ds/debian/control2024-11-03 22:05:08.0 +0100 @@ -7,14 +7,14 @@ Build-Depends: architecture-is-little-endian, cmake, debhelper-compat (= 13), - dh-python, - dh-sequence-numpy3, dh-sequence-pkgkde-symbolshelper, - dh-sequence-python3, + python3-numpy , pkg-kde-tools, - python3-all, - python3-numpy, - python3-setuptools +Build-Depends-Indep: dh-sequence-python3, + dh-sequence-numpy3, + python3-all, + python3-numpy, + python3-setuptools, Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/debian-gis-team/lerc Vcs-Git: https://salsa.debian.org/debian-gis-team/lerc.git diff --minimal -Nru lerc-4.0.0+ds/debian/rules lerc-4.0.0+ds/debian/rules --- lerc-4.0.0+ds/debian/rules 2023-12-03 17:46:30.0 +0100 +++ lerc-4.0.0+ds/debian/rules 2024-11-03 22:05:08.0 +0100 @@ -16,7 +16,7 @@ override_dh_auto_clean: dh_auto_clean dh_auto_clean --builddirectory build-static - dh_auto_clean --buildsystem=pybuild --sourcedirectory=OtherLanguages/Python + if command -v pybuild >/dev/null; then dh_auto_clean --buildsystem=pybuild --sourcedirectory=OtherLanguages/Python; fi override_dh_auto_configure: dh_auto_configure @@ -32,10 +32,11 @@ python3 -c "import lerc; assert lerc.test() == 0" endif -override_dh_auto_install: - dh_auto_install --buildsystem=pybuild -ppython3-lerc --sourcedirectory=OtherLanguages/Python +execute_after_dh_auto_install: dh_auto_install --builddirectory build-static - dh_auto_install + +override_dh_auto_install-indep: + dh_auto_install --buildsystem=pybuild -ppython3-lerc --sourcedirectory=OtherLanguages/Python # Ubuntu wants the build to fail when symbols disappear override_dh_makeshlibs:
Bug#1086689: tiff FTCBFS: sphinx dependency not satisfiable
Source: tiff Version: 4.5.1+git230720-5 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability tiff cannot be cross built from source, because its sphinx dependency is not satisfiable. In principle, sphinx can be used in architecture-dependent ways and therefore it is not marked Multi-Arch: foreign. Thus every consumer has to declare that it uses sphinx in an architecture-agnostic way if they do so. tiff happens to do so. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru tiff-4.5.1+git230720/debian/changelog tiff-4.5.1+git230720/debian/changelog --- tiff-4.5.1+git230720/debian/changelog 2024-08-15 18:04:20.0 +0200 +++ tiff-4.5.1+git230720/debian/changelog 2024-11-03 21:36:14.0 +0100 @@ -1,3 +1,10 @@ +tiff (4.5.1+git230720-5.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Annotate sphinx dependency :native. (Closes: #-1) + + -- Helmut Grohne Sun, 03 Nov 2024 21:36:14 +0100 + tiff (4.5.1+git230720-5) unstable; urgency=high * Backport security fix for CVE-2024-7006, NULL pointer dereference bug in diff --minimal -Nru tiff-4.5.1+git230720/debian/control tiff-4.5.1+git230720/debian/control --- tiff-4.5.1+git230720/debian/control 2024-08-15 18:04:20.0 +0200 +++ tiff-4.5.1+git230720/debian/control 2024-11-03 21:35:41.0 +0100 @@ -14,7 +14,7 @@ zlib1g-dev, libdeflate-dev, liblerc-dev [!s390x !hppa !powerpc !ppc64 !sparc64], - sphinx + sphinx:native Standards-Version: 4.6.2 Homepage: https://libtiff.gitlab.io/libtiff/ Rules-Requires-Root: no
Bug#1086688: coinutils FTCBFS: gfortran dependency not satisfiable
Source: coinutils Version: 2.11.11+ds-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability coinutils cannot be cross built from source, because its gfortran dependency is not satisfiable. It needs "toolchain dependency cross translation" which has been an unsolved problem for a long time, but since earlier this year, we may write "gfortran-for-host". Once doing so, coinutils fails building natively, because gfortran-for-host only provides an architecture-qualified gfortran. Thus exporting F77 is required for using this dependency. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru coinutils-2.11.11+ds/debian/changelog coinutils-2.11.11+ds/debian/changelog --- coinutils-2.11.11+ds/debian/changelog 2024-10-26 08:07:17.0 +0200 +++ coinutils-2.11.11+ds/debian/changelog 2024-11-03 21:24:25.0 +0100 @@ -1,3 +1,10 @@ +coinutils (2.11.11+ds-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Translate gfortran dependency to gfortran-for-host. (Closes: #-1) + + -- Helmut Grohne Sun, 03 Nov 2024 21:24:25 +0100 + coinutils (2.11.11+ds-1) unstable; urgency=medium * Move from experimental to unstable. diff --minimal -Nru coinutils-2.11.11+ds/debian/control coinutils-2.11.11+ds/debian/control --- coinutils-2.11.11+ds/debian/control 2024-10-26 08:07:17.0 +0200 +++ coinutils-2.11.11+ds/debian/control 2024-11-03 21:19:17.0 +0100 @@ -4,7 +4,7 @@ Section: science Priority: optional Build-Depends: debhelper-compat (= 13), - gfortran, + gfortran-for-host, libbz2-dev, liblapack-dev, zlib1g-dev, diff --minimal -Nru coinutils-2.11.11+ds/debian/rules coinutils-2.11.11+ds/debian/rules --- coinutils-2.11.11+ds/debian/rules 2024-10-26 08:07:17.0 +0200 +++ coinutils-2.11.11+ds/debian/rules 2024-11-03 21:24:25.0 +0100 @@ -4,10 +4,15 @@ include /usr/share/dpkg/architecture.mk +ifeq ($(origin F77),default) +F77 := $(DEB_HOST_GNU_TYPE)-gfortran +endif + %: dh $@ --without autoreconf override_dh_auto_configure: + F77='$(F77)' \ ./configure --prefix=/usr --libdir=/usr/lib/$(DEB_HOST_MULTIARCH) \ --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \ --enable-static --enable-dot --enable-dependency-linking
Bug#1086680: lapack FTCBFS: unsatisfiable gfortran+python3 dependencies
Source: lapack Version: 3.12.0-3 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability lapack cannot be cross built from source, because its dependency on gfortran is not satsifiable and its dependency on the host architecture python3 fails to install. It turns out that python3 is only used for testing, so we may simply annotate it . The gfortran dependency was an unsolved issue as it needs "toolchain dependency cross translation", but this has been solved earlier this year and we can now translate it to gfortran-for-host. Beware that gfortran-for-host does not provide a "gfortran" binary and requires the consumer to always call it architecture-qualified. This is what lapack already does by setting FC, but the use of gfortran-for-host turns this setting into a requirement. I hope this is ok. Also note that lapack will not actually cross build until gcc bug #1086679 is solved. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru lapack-3.12.0/debian/changelog lapack-3.12.0/debian/changelog --- lapack-3.12.0/debian/changelog 2024-02-07 12:30:40.0 +0100 +++ lapack-3.12.0/debian/changelog 2024-11-01 23:16:19.0 +0100 @@ -1,3 +1,12 @@ +lapack (3.12.0-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Translate gfortran dependency to gfortran-for-host. ++ Annotate test dependency python3 with the nocheck profile. + + -- Helmut Grohne Fri, 01 Nov 2024 23:16:19 +0100 + lapack (3.12.0-3) unstable; urgency=medium * Add Breaks of liblapacke against older liblapack.so.3 flavours. diff --minimal -Nru lapack-3.12.0/debian/control lapack-3.12.0/debian/control --- lapack-3.12.0/debian/control2024-02-07 10:56:36.0 +0100 +++ lapack-3.12.0/debian/control2024-11-01 23:16:19.0 +0100 @@ -6,8 +6,8 @@ Priority: optional Build-Depends: debhelper-compat (= 13), dh-exec -Build-Depends-Arch: gfortran, -python3 +Build-Depends-Arch: gfortran-for-host, +python3 Build-Depends-Indep: doxygen, graphviz, rename
Bug#1086679: gfortran-for-host should provide libgfortran.so on a default library path
Package: gfortran-14-for-host
Version: 14.2.0-7
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:lapack
Hi Matthias,
I looked into cross building lapack and that mostly works except that
dpkg-shlibdeps fails to find libgfortran.so. I looked and there is a
subtle cross/native difference at play here. The native
gfortran-PV-arch_gnusuffix built from gcc-PV depends on
libgfortran-PV-dev whereas the cross toolchain
gfortran-PV-arch_gnusuffix built from gcc-PV-cross depends on
libgfortran-PV-dev-ARCH-cross. I think this is right as the cross
toolchain cannot issue cross-architecture dependencies. Still this means
that when using a cross toolchain, libgfortran.so is placed in
/usr/triplet and not found by dpkg-shlibdeps. Really though when
depending on gfortran-for-host, I want to expect that dpkg-shlibdeps
just works on generated binaries. I propose that we duplicate the
libgfortran-PV-dev dependency issued from the native toolchain
gfortran-PV-arch_gnusuffix into the gfortran-PV-for-host package. In the
native case, it will be satisfied already and in the cross case it will
pull the library that makes dpkg-shlibdeps happy. I'm attaching the
obvious patch for your convenience.
Helmut
diff --minimal -Nru gcc-14-14.2.0/debian/changelog
gcc-14-14.2.0/debian/changelog
--- gcc-14-14.2.0/debian/changelog 2024-10-19 09:24:57.0 +0200
+++ gcc-14-14.2.0/debian/changelog 2024-11-03 19:29:38.0 +0100
@@ -1,3 +1,10 @@
+gcc-14 (14.2.0-7.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Let gfortran-PV-for-host depend on libgfortran-PV-dev. (Closes: #-1)
+
+ -- Helmut Grohne Sun, 03 Nov 2024 19:29:38 +0100
+
gcc-14 (14.2.0-7) unstable; urgency=medium
* Update to git 20241019 from the gcc-14 branch.
diff --minimal -Nru gcc-14-14.2.0/debian/control gcc-14-14.2.0/debian/control
--- gcc-14-14.2.0/debian/control2024-09-15 10:27:06.0 +0200
+++ gcc-14-14.2.0/debian/control2024-11-03 19:29:31.0 +0100
@@ -2980,7 +2980,8 @@
X-DH-Build-For-Type: target
Multi-Arch: same
Depends: gcc-14-base (= ${gcc:Version}), gfortran-14${target:suffix} (>=
${gcc:SoftVersion}),
- gcc-14-for-host (= ${gcc:Version}), ${misc:Depends}
+ gcc-14-for-host (= ${gcc:Version}), ${misc:Depends},
+ libgfortran-14-dev (= ${gcc:Version}),
Description: GNU Fortran compiler for the host architecture
This is the GNU Fortran compiler for the host architecture,
which compiles Fortran on platforms supported by the gcc compiler.
diff --minimal -Nru gcc-14-14.2.0/debian/control.m4
gcc-14-14.2.0/debian/control.m4
--- gcc-14-14.2.0/debian/control.m4 2024-08-02 02:50:33.0 +0200
+++ gcc-14-14.2.0/debian/control.m4 2024-11-03 19:29:02.0 +0100
@@ -2846,7 +2846,8 @@
TARGET_PACKAGE`'dnl
Multi-Arch: same
Depends: BASEDEP, gfortran`'PV`'${target:suffix} (>= ${gcc:SoftVersion}),
- gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends}
+ gcc`'PV`'-for-host (= ${gcc:Version}), ${misc:Depends},
+ libidevdep(gfortran`'PV-dev,,=),
BUILT_USING`'dnl
Description: GNU Fortran compiler for the host architecture
This is the GNU Fortran compiler for the host architecture,
Bug#1084924: The system-log-daemon virtual package
Hi Sean,
On Sun, Nov 03, 2024 at 03:20:43PM +0800, Sean Whitton wrote:
> Hello,
>
> On Mon 28 Oct 2024 at 11:04am +01, Helmut Grohne wrote:
>
> > Thank you for bringing this up. Despite the little confusion in the end
> > that Chris remarked, I think this practically covers the four cases.
> >
> > However, I think there is a fifth case that is becoming more and more
> > practically relevant. Both docker and podman now have a logging driver
> > called journald.
> >
> > https://docs.docker.com/engine/logging/drivers/journald/
> >
> > I'm not yet sure exactly how this works, but the context is "slim"
> > containers (i.e. those that do not run systemd as pid 1) and I very much
> > expect them to not run a journald from the container environment either.
> > Rather the container runtime essentially provides /dev/log and a
> > journald socket to the container in some (unspecified?) way.
> >
> > This kinda is similar to dbconfig where we have dbconfig-no-thanks. We'd
> > need another package syslog-no-thanks that would have the same provides
> > and conflicts but no systemd dependency now.
> >
> > Of course just adding such a package would result in apt selecting it
> > whenever systemd is difficult to install. In effect, adding such a
> > package would render dependencies on system-log-daemon meaningless and
> > we could just drop them - which is what has been happening and has
> > resulted in this bug.
> >
> > So now we're running in circles. Effectively, we must decide whether the
> > container use case is more important than the non-systemd case or the
> > other way round. I do not see a way to make both just work in a sane
> > way.
>
> I think I understand what you mean about why a syslog-no-thanks virtual
> package would not be helpful, but I don't understand how the journald
> driver option interacts with my four options.
>
> How do systemd and these journald drivers interact? Aren't we in case
> #1?
Admittedly, my understanding of this is quite shallow as well. Roughly
speaking when we talk about docker/podman we most often imply an
application container (i.e. one not running systemd as pid 1) rather
than a system container (where there are systemd and jounrnald proceses
inside the container). More specifically, if we were talking about
system containers, we could easily install your
systemd-journald-is-syslog package and no problem would arise.
Therefore, I assume we are talking about application containers only. An
application container will not have systemd-sysv and probably not even
systemd installed. As a consequence, systemd-journald-is-syslog cannot
be installed as it would have an unsatisfied dependency. Still the
docker/podman journald driver would ensure that /dev/log and
/run/systemd/journal/socket are present and usable. As such the syslog()
function will work in the sense that the log message will be recorded
somewhere. This is different from your #1 ("No logging facility"). No
installed package provides system-log-daemon even though the semantics
of system-log-daemon are provided by the container runtime. From a
satisfiability point of view, we certainly are in your #1 case, but we'd
like to assert to other packages, that system-log-daemon is available
and we cannot without a syslog-no-thanks package.
To put this another way, we need to gain more clarity about what
system-log-daemon actually means beyond what is recorded in policy:
| a daemon that provides a logging facility for other applications
If the focus of this description is on providing /dev/log as a means to
record log message, we can no longer express this in terms of package
relations, because we can run the same container image with or without
the journald driver and thus have this property differ. This is vaguely
similar to how we cannot depend on the availability of Linux kernel
features or CPU instruction set extensions (even though we do via
isa-support).
If the focus is on the exclusion of alternative logging mechanisms
rather than about the availability of a /dev/log listener, then removing
dependencies on this virtual package (as has been happening) is the
right way forward.
To me, this is a strong clue that we should be updating Debian policy in
some way as the current ambiguity is evidently resulting in incompatible
interpretations. Do you agree with this? If yes, would you clone a
policy bug asking to clarify the meaning of system-log-daemon?
Helmut
Bug#1086647: nmap FTCBFS: python3 build-depends not installable
Source: nmap
Version: 7.94+git20230807.3be01efb1+dfsg-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
X-Debbugs-Cc: st...@kali.org
Hi,
Steev noticed that nmap could not be cross built. While the initial
diagnosis was a zlib conflict, which is temporary in nature and caused
by the PAC/BTI rebuilds, there is a persistent issue with the python3
dependency. What is requested is the host architecture python3
interpreter and that fails to install if apt ever figures satisfying
depedencies.
Fortunately, we don't have to think much about what kind of Python
interpreter as the answer simply is "none". It is used to build ndiff
and zenmap both of which are Arch:all packages, so we can entirely
sidestep the problem by better separating the indep build from the
arch-only build.
I'm attaching a patch that performs this separation and thus moves
python3 and python3-gi to B-D-I. As a result, cross build depeneds
become satisfiable right now for e.g. amd64 -> ppc64el. It doesn't cross
build just yet, but one may now attempt building it. Please consider
applying the patch.
Helmut
diff --minimal -Nru nmap-7.94+git20230807.3be01efb1+dfsg/debian/changelog
nmap-7.94+git20230807.3be01efb1+dfsg/debian/changelog
--- nmap-7.94+git20230807.3be01efb1+dfsg/debian/changelog 2024-06-04
18:40:09.0 +0200
+++ nmap-7.94+git20230807.3be01efb1+dfsg/debian/changelog 2024-11-02
22:41:42.0 +0100
@@ -1,3 +1,10 @@
+nmap (7.94+git20230807.3be01efb1+dfsg-4.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Improve cross building: Demote python dependencies to B-D-I. (Closes: #-1)
+
+ -- Helmut Grohne Sat, 02 Nov 2024 22:41:42 +0100
+
nmap (7.94+git20230807.3be01efb1+dfsg-4) unstable; urgency=medium
[ Hilko Bengen ]
diff --minimal -Nru nmap-7.94+git20230807.3be01efb1+dfsg/debian/control
nmap-7.94+git20230807.3be01efb1+dfsg/debian/control
--- nmap-7.94+git20230807.3be01efb1+dfsg/debian/control 2024-06-04
18:40:09.0 +0200
+++ nmap-7.94+git20230807.3be01efb1+dfsg/debian/control 2024-11-02
22:41:42.0 +0100
@@ -15,14 +15,15 @@
libssh2-1-dev,
libssl-dev,
lua-lpeg-dev,
- python3,
- python3-gi,
gir1.2-gtk-3.0,
gir1.2-pango-1.0,
gir1.2-glib-2.0,
gir1.2-gdkpixbuf-2.0,
Build-Depends-Indep: default-jdk-headless,
- gcc-mingw-w64-i686
+ dh-sequence-python3,
+ gcc-mingw-w64-i686,
+ python3,
+ python3-gi,
Standards-Version: 4.6.2
Rules-Requires-Root: no
Homepage: https://nmap.org/
diff --minimal -Nru nmap-7.94+git20230807.3be01efb1+dfsg/debian/rules
nmap-7.94+git20230807.3be01efb1+dfsg/debian/rules
--- nmap-7.94+git20230807.3be01efb1+dfsg/debian/rules 2024-06-04
18:40:09.0 +0200
+++ nmap-7.94+git20230807.3be01efb1+dfsg/debian/rules 2024-11-02
22:41:42.0 +0100
@@ -3,7 +3,7 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
%:
- dh $@ --with=python3
+ dh $@
override_dh_auto_clean:
dh_auto_clean
@@ -19,13 +19,14 @@
--without-ndiff \
--enable-ipv6 \
STRIP=/bin/true
+
+execute_after_dh_auto_configure-indep:
dh_auto_configure --sourcedir=ndiff --buildsystem=pybuild
dh_auto_configure --sourcedir=zenmap --buildsystem=pybuild
mingw_CFLAGS = $(filter-out -mbranch-protection=standard,$(CFLAGS))
-override_dh_auto_build-indep:
- dh_auto_build
+execute_after_dh_auto_build-indep:
dh_auto_build --sourcedir=ndiff --buildsystem=pybuild
dh_auto_build --sourcedir=zenmap --buildsystem=pybuild
cd nselib/data/jdwp-class && /usr/lib/jvm/default-java/bin/javac *.java
@@ -33,12 +34,15 @@
i686-w64-mingw32-gcc ${CPPFLAGS} ${mingw_CFLAGS} -o
nmap_service.exe nmap_service.c && \
gzip -c -n9 nmap_service.exe | base64 | tac > nmap_service.ex_
-override_dh_auto_test:
+override_dh_auto_test-arch:
+
+override_dh_auto_test-indep:
dh_auto_test --sourcedir=ndiff --buildsystem=pybuild
dh_auto_test --sourcedir=zenmap --buildsystem=pybuild
-override_dh_auto_install:
- dh_auto_install
+execute_after_dh_auto_install-arch:
+ mv debian/tmp/usr/share/man/pt_PT debian/tmp/usr/share/man/pt
+
+execute_after_dh_auto_install-indep:
dh_auto_install --sourcedir=ndiff --buildsystem=pybuild
dh_auto_install --sourcedir=zenmap --buildsystem=pybuild
- mv debian/tmp/usr/share/man/pt_PT debian/tmp/usr/share/man/pt
Bug#1086592: libtool FTCBFS: unsatisfiable gfortran dependency
Hi Alastair, On Sat, Nov 02, 2024 at 05:29:18AM +, Alastair McKinstry wrote: > Have you tested whether the cross-built libtool then works on the target > archs? libtool is part of architecture cross bootstrap since a very long time. Since about 10 years, it is being cross build (with hacks) in https://wiki.debian.org/HelmutGrohne/rebootstrap. This patch is a step towards removing those hacks, so yes, this has been tested for a quite long time. > I was not aware of gfortran-for-host. I would like to explore this more > fully for dh-fortran-mod, but I will continue that in another thread. This is kinda expected. The whole *-for-host thing is quite recent in Debian timelines. The concept was first used by qt5-qmake (without the -for-host naming), later transferred to binutils, eventually reached pkgconf (without -for-host) and just this year reached gcc-VER and gcc-defaults. Please don't change dh-fortran-mod just yet. I also want to see it there, but we need to be more careful there as it is not as isolated as in libtool. Just days ago I started a discussion (https://lists.debian.org/debian-cross/2024/11/msg0.html) where I explored cross building fftw3 and quickly ended up at dh-fortran-mod and a non-trivial problem. I would very much welcome your input there. The underlying problem is of general nature and Fortran just happens to be affected earlier than others. Can you tell me what list I should have Cced for that discussion to reach you? Helmut
Bug#1079964: Proceeding with removal of guacamole-server
Control: severity 1079964 normal Control: retitle 1079964 RM: guacamole-server -- RoQA; rc-buggy Control: reassign 1079964 ftp.debian.org Control: affects 1079964 + src:guacamole-server Dear guacamole-server maintainer and ftp team, a month has passed since filing a suggestion to remove guacamole-server from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1005154: guacamole-server: frequent test failure on i386 Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082604: Proceeding with removal of syncmaildir
Control: severity 1082604 normal Control: retitle 1082604 RM: syncmaildir -- RoQA; rc-buggy Control: reassign 1082604 ftp.debian.org Control: affects 1082604 + src:syncmaildir Dear syncmaildir maintainer and ftp team, a month has passed since filing a suggestion to remove syncmaildir from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1000322: locking issues can lead to complete mail spool destruction Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086592: libtool FTCBFS: unsatisfiable gfortran dependency
Source: libtool Version: 2.4.7-7 Tags: patch User: debian-cr...@lists.debian.org Usertags: cross-satisfiability libtool cannot be cross built from source, because its gfortran dependency is not satisfiable. What is being requested here is a host architecture fortran compiler running on the host architecture. As it also depends on a C compiler (again for the host architecture) we arrive at a conflict with the build architecture C compiler implied in build-essential. The matter is fairly old and dubbed "toolchain dependency cross translation". After so many years, this has been solved in principle via introducing -for-host packages to gcc. In essence, we now annotated toolchain dependencies with a -for-build or -for-host suffix depending what we use them for. So we just replace gfortran with gfortran-for-host, right? Unfortunately, no. When we pull a -for-host package, cross building will work, because autotools prefixes host tools with a host triplet. Once attempting a native build, autotools will not do so and thus failing to find gfortran as gfortran-for-host only provides a triplet-prefixed name for gfortran and autotools does not attempt to use it by that name. We can fix this aspect by forcing a triplet-prefixed name. So that's what I propose. Actually go for gfortran-for-host and use -gfortran even for native builds. What do you think? Helmut diff --minimal -Nru libtool-2.4.7/debian/changelog libtool-2.4.7/debian/changelog --- libtool-2.4.7/debian/changelog 2023-07-17 17:03:58.0 +0200 +++ libtool-2.4.7/debian/changelog 2024-10-31 17:47:25.0 +0100 @@ -1,3 +1,11 @@ +libtool (2.4.7-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use gfortran-for-host. (Closes: #-1) ++ As a result gfortran must be triplet-prefixed even in native builds. + + -- Helmut Grohne Thu, 31 Oct 2024 17:47:25 +0100 + libtool (2.4.7-7) unstable; urgency=medium * Remove obsole Breaks: for oldstable , Provides: libltdl7-dev diff --minimal -Nru libtool-2.4.7/debian/control libtool-2.4.7/debian/control --- libtool-2.4.7/debian/control2023-07-17 17:03:58.0 +0200 +++ libtool-2.4.7/debian/control2024-10-31 17:47:13.0 +0100 @@ -1,7 +1,7 @@ Source: libtool Build-Depends: debhelper-compat (= 13), file, - gfortran | fortran95-compiler, + gfortran-for-host | fortran95-compiler, automake (>= 1:1.14.1-3), autoconf (>= 2.69-7), help2man, diff --minimal -Nru libtool-2.4.7/debian/rules libtool-2.4.7/debian/rules --- libtool-2.4.7/debian/rules 2023-07-17 17:03:58.0 +0200 +++ libtool-2.4.7/debian/rules 2024-10-31 17:47:25.0 +0100 @@ -15,6 +15,12 @@ include /usr/share/dpkg/buildflags.mk include /usr/share/dpkg/pkg-info.mk +# Always use triplet-prefixed tools with gfortran-for-host. +ifeq ($(origin FC),default) +export FC := $(DEB_HOST_GNU_TYPE)-gfortran +endif +export F77 ?= $(FC) + # libltdl needs to conform to policy ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s
Bug#1024925: libx11: support the noudeb build profile
Hi Julien, On Fri, Nov 01, 2024 at 03:47:23PM +0100, Julien Cristau wrote: > Can you explain what this would be useful for? The noudeb profile is a fairly generic build profile that inhibts building of components for the debian-installer. The main use is speeding up builds where the debian-installer artifacts are not required. rebootstrap uses it for that purpose. Ubuntu (which uses a different installer) sets the noudeb build profile for all builds. The change in the patch declares that when enabling the noudeb profile, libx11-6-udeb shall not be emitted and debhelper knows what to do in this case. The declaration is also embedded into the .dsc and signifies to builders that this profile is supported. Helmut
Bug#1086544: seccure FTCBFS: fails running tests despite DEB_BUILD_OPTIONS=nocheck
Source: seccure Version: 0.5-2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs seccure fails to cross build from source, because it fails running tests despite being passed DEB_BUILD_OPTIONS=nocheck. Support for the nocheck option is enabled by upgrading the debhelper compatibility level or applying the attached patch. Helmut diff --minimal -Nru seccure-0.5/debian/changelog seccure-0.5/debian/changelog --- seccure-0.5/debian/changelog2019-01-26 13:06:00.0 +0100 +++ seccure-0.5/debian/changelog2024-10-30 21:07:39.0 +0100 @@ -1,3 +1,10 @@ +seccure (0.5-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Support DEB_BUILD_OPTIONS=nocheck. (Closes: #-1) + + -- Helmut Grohne Wed, 30 Oct 2024 21:07:39 +0100 + seccure (0.5-2) unstable; urgency=medium * Fix insecure-copyright-format-uri diff --minimal -Nru seccure-0.5/debian/rules seccure-0.5/debian/rules --- seccure-0.5/debian/rules2018-01-02 14:38:59.0 +0100 +++ seccure-0.5/debian/rules2024-10-30 21:07:38.0 +0100 @@ -10,4 +10,6 @@ dh_installchangelogs HISTORY override_dh_auto_test: +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) cd test && make +endif
Bug#1085392: Should zmodemjs be removed from unstable?
Hi Daniel, On Wed, Oct 30, 2024 at 06:59:54PM +0100, Daniel Baumann wrote: > close 1085392 > thanks > > rational is the same as before: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082067#10 As noted in that earlier bug, just closing the removal suggestion is not a solution. In order to prevent the autoremover from refiling it, you need to take some other form of action in addition. Recognizing that you want zmodemjs to stay in Debian I ended up NMUing it to fix the lingering FTBFS. Hope that works for you. With the RC-bug gone, the autoremover will stop trying to remove it. Helmut
Bug#1086547: Should libgridxc be removed from unstable?
Source: libgridxc Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing libgridxc from Debian for the following reasons: * It accumulated one RC-bug: + #1055110: libgridxc builds with -march=native Last modified: 1 year, 1 day * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: libgridxc -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:libgridxc Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080407: Proceeding with removal of apertium-cy-en
Control: severity 1080407 normal Control: retitle 1080407 RM: apertium-cy-en -- RoQA; rc-buggy Control: reassign 1080407 ftp.debian.org Control: affects 1080407 + src:apertium-cy-en Dear apertium-cy-en maintainer and ftp team, a month has passed since filing a suggestion to remove apertium-cy-en from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1016320: apertium-cy-en: FTBFS: make[2]: *** [Makefile:816: en-cy.t2x.bin] Error 1 Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080501: Proceeding with removal of airport-utils
Control: severity 1080501 normal Control: retitle 1080501 RM: airport-utils -- RoQA; rc-buggy Control: reassign 1080501 ftp.debian.org Control: affects 1080501 + src:airport-utils Dear airport-utils maintainer and ftp team, a month has passed since filing a suggestion to remove airport-utils from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #414092: airport-utils: Tools start and quit immediately without working Last modified: 1 year, 3 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080507: Proceeding with removal of adacontrol
Control: severity 1080507 normal Control: retitle 1080507 RM: adacontrol -- RoQA; rc-buggy Control: reassign 1080507 ftp.debian.org Control: affects 1080507 + src:adacontrol Dear adacontrol maintainer and ftp team, a month has passed since filing a suggestion to remove adacontrol from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1008982: adacontrol: depends on unavailable asis Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080508: Proceeding with removal of anki
Control: severity 1080508 normal Control: retitle 1080508 RM: anki -- RoQA; rc-buggy Control: reassign 1080508 ftp.debian.org Control: affects 1080508 + src:anki Dear anki maintainer and ftp team, a month has passed since filing a suggestion to remove anki from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1053541: package contains license CC-BY-2.5 Last modified: 1 year, 27 days Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080502: Proceeding with removal of breezy-loom
Control: severity 1080502 normal Control: retitle 1080502 RM: breezy-loom -- RoQA; rc-buggy Control: reassign 1080502 ftp.debian.org Control: affects 1080502 + src:breezy-loom Dear breezy-loom maintainer and ftp team, a month has passed since filing a suggestion to remove breezy-loom from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #988156: breezy breaks breezy-loom autopkgtest: FAILED (failures=4) Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080054: Proceeding with removal of python-html-sanitizer
Control: severity 1080054 normal
Control: retitle 1080054 RM: python-html-sanitizer -- RoQA; rc-buggy
Control: reassign 1080054 ftp.debian.org
Control: affects 1080054 + src:python-html-sanitizer
Dear python-html-sanitizer maintainer and ftp team,
a month has passed since filing a suggestion to remove python-html-sanitizer
from Debian. It was suggested for removal due to not being part of bookworm
nor trixie and having accumulated a long-standing RC bug.
* #1008366: python-html-sanitizer: FTBFS: dh_auto_test: error: pybuild --test
-i python{version} -p 3.9 returned exit code 13
Last modified: 2 years
Since the suggestion bug was neither closed nor tagged in a month, silent
consent to proceed with removal is assumed.
Kind regards
A tool for automatically removing packages from unstable
This bug reply has been automatically sent with little human intervention.
If the filing is unclear or in error, don't hesitate to contact
Helmut Grohne for assistance.
Bug#1080047: Proceeding with removal of node-matrix-js-sdk
Control: severity 1080047 normal Control: retitle 1080047 RM: node-matrix-js-sdk -- RoQA; rc-buggy Control: reassign 1080047 ftp.debian.org Control: affects 1080047 + src:node-matrix-js-sdk Dear node-matrix-js-sdk maintainer and ftp team, a month has passed since filing a suggestion to remove node-matrix-js-sdk from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated 4 long-standing RC bugs. * #994213: node-matrix-js-sdk: CVE-2021-40823: E2EE vulnerability Last modified: 3 years * #1018970: node-matrix-js-sdk: CVE-2022-36059 Last modified: 2 years * #1021136: node-matrix-js-sdk: CVE-2022-39236 CVE-2022-39249 CVE-2022-39251 Last modified: 2 years * #1033621: node-matrix-js-sdk: CVE-2023-28427 Last modified: 1 year, 7 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1079966: Proceeding with removal of gigedit
Control: severity 1079966 normal Control: retitle 1079966 RM: gigedit -- RoQA; rc-buggy Control: reassign 1079966 ftp.debian.org Control: affects 1079966 + src:gigedit Dear gigedit maintainer and ftp team, a month has passed since filing a suggestion to remove gigedit from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #997203: gigedit: FTBFS: ../compat.h:194:21: error: âconst Pango::Alignment Pango::ALIGN_LEFTâ redeclared as different kind of entity Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086546: tor: moves systemd units from /usr/lib/systemd to /lib/systemd (DEP17)
Package: tor Version: 0.4.8.13-1 Severity: serious Justification: moving files from /usr to / is prohibited User: helm...@debian.org Usertags: dep17m2 Hi Peter, we're trying to complete the /usr-move transition. As part of that, we sent a bug #1073748, raised it to RC, and Chris Hofstaedler eventually NMUed tor/0.4.8.12-1.1. Unfortunately, your .13-1 upload fails to incorporate the NMU. As a result, it moves the systemd units and generator back to aliased paths. In the trixie release, we want to install no files below /lib in any package to eliminate the negative effects of aliasing. Please incorporate the NMU. Helmut
Bug#1079960: Proceeding with removal of fruit
Control: severity 1079960 normal Control: retitle 1079960 RM: fruit -- RoQA; rc-buggy Control: reassign 1079960 ftp.debian.org Control: affects 1079960 + src:fruit Dear fruit maintainer and ftp team, a month has passed since filing a suggestion to remove fruit from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1014187: fruit: Binary file without a source code Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086541: d52 FTCBFS: uses cdbs
Source: d52 Version: 3.4.1-1.3 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs d52 fails to cross build from source, because it uses cdbs and as a result uses the build architecture compiler. Cross building using cdbs isn't supported well, so I propose converting the package to debhelper. Once doing so, it just cross builds out of the box. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru d52-3.4.1/debian/changelog d52-3.4.1/debian/changelog --- d52-3.4.1/debian/changelog 2024-03-24 21:03:49.0 +0100 +++ d52-3.4.1/debian/changelog 2024-10-30 21:36:21.0 +0100 @@ -1,3 +1,10 @@ +d52 (3.4.1-1.4) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Convert to debhelper. (Closes: #-1) + + -- Helmut Grohne Wed, 30 Oct 2024 21:36:21 +0100 + d52 (3.4.1-1.3) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru d52-3.4.1/debian/dirs d52-3.4.1/debian/dirs --- d52-3.4.1/debian/dirs 2024-03-24 21:03:41.0 +0100 +++ d52-3.4.1/debian/dirs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/bin diff --minimal -Nru d52-3.4.1/debian/install d52-3.4.1/debian/install --- d52-3.4.1/debian/install1970-01-01 01:00:00.0 +0100 +++ d52-3.4.1/debian/install2024-10-30 21:35:33.0 +0100 @@ -0,0 +1,3 @@ +d52 usr/bin +d48 usr/bin +dz80 usr/bin diff --minimal -Nru d52-3.4.1/debian/rules d52-3.4.1/debian/rules --- d52-3.4.1/debian/rules 2024-03-24 21:03:49.0 +0100 +++ d52-3.4.1/debian/rules 2024-10-30 21:36:09.0 +0100 @@ -1,12 +1,6 @@ #!/usr/bin/make -f -DEB_MAKE_INSTALL_TARGET := - -include /usr/share/cdbs/1/rules/debhelper.mk -include /usr/share/cdbs/1/class/makefile.mk - -install/d52:: - install d52 debian/d52/usr/bin - install d48 debian/d52/usr/bin - install dz80 debian/d52/usr/bin +%: + dh $@ +override_dh_auto_install:
Bug#1086545: hyphen-show FTCBFS: hard codes the build architecture compiler
Source: hyphen-show Version: 2425-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs hyphen-show fails to cross build from source, because debian/rules hard codes the build architecture compiler as CC = gcc. The easiest way to obtain the correct toolchain in all cases is including dpkg's buildtools.mk. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru hyphen-show-2425/debian/changelog hyphen-show-2425/debian/changelog --- hyphen-show-2425/debian/changelog 2021-01-08 00:27:38.0 +0100 +++ hyphen-show-2425/debian/changelog 2024-10-31 14:25:36.0 +0100 @@ -1,3 +1,10 @@ +hyphen-show (2425-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk supply CC. (Closes: #-1) + + -- Helmut Grohne Thu, 31 Oct 2024 14:25:36 +0100 + hyphen-show (2425-4) unstable; urgency=medium * Switched to debhelper compatibility level 13. Closes: #965587 diff --minimal -Nru hyphen-show-2425/debian/rules hyphen-show-2425/debian/rules --- hyphen-show-2425/debian/rules 2014-09-16 01:23:08.0 +0200 +++ hyphen-show-2425/debian/rules 2024-10-31 14:25:31.0 +0100 @@ -2,10 +2,9 @@ DEB_CFLAGS_MAINT_APPEND = -Wall +include /usr/share/dpkg/buildtools.mk include /usr/share/dpkg/buildflags.mk -CC = gcc - .PHONY: build build: build-arch build-indep
Bug#1086543: morsegen FTCBFS: debian/rules hard codes the build architecture compiler gcc
Source: morsegen Version: 0.2.1-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs morsegen fails to cross build from source, because debian/rules hard codes the build architecture compiler (gcc). I'm attaching a patch to use the host one for your convenience. Helmut diff --minimal -Nru morsegen-0.2.1/debian/changelog morsegen-0.2.1/debian/changelog --- morsegen-0.2.1/debian/changelog 2022-01-18 15:37:00.0 +0100 +++ morsegen-0.2.1/debian/changelog 2024-10-30 15:31:03.0 +0100 @@ -1,3 +1,10 @@ +morsegen (0.2.1-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture compiler. (Closes: #-1) + + -- Helmut Grohne Wed, 30 Oct 2024 15:31:03 +0100 + morsegen (0.2.1-4) unstable; urgency=medium * adopted the package. Closes: #920109 diff --minimal -Nru morsegen-0.2.1/debian/rules morsegen-0.2.1/debian/rules --- morsegen-0.2.1/debian/rules 2022-01-18 15:37:00.0 +0100 +++ morsegen-0.2.1/debian/rules 2024-10-30 15:30:53.0 +0100 @@ -5,6 +5,8 @@ export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed +include /usr/share/dpkg/buildtools.mk + CFLAGS = $(shell dpkg-buildflags --get CFLAGS) CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS) LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS) @@ -13,7 +15,7 @@ $(MAKE) -C debian -f pod2man.mk PACKAGE=morsegen makeman override_dh_auto_build: man - gcc $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -o morsegen *.c + $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -o morsegen *.c %: dh $@
Bug#1086542: cycfx2prog FTCBFS: uses cdbs
Source: cycfx2prog Version: 0.47-1.2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs cycfx2prog fails to cross build from source, because it uses cdbs and as a result uses the build architecture compiler. Cross building with cdbs tends to not work well. I propose converting the package to debhelper. Doing so removes a lot of code and makes cross building just work. Please find a patch attached for your convenience. Helmut diff --minimal -Nru cycfx2prog-0.47/debian/changelog cycfx2prog-0.47/debian/changelog --- cycfx2prog-0.47/debian/changelog2024-03-24 20:53:34.0 +0100 +++ cycfx2prog-0.47/debian/changelog2024-10-30 21:19:13.0 +0100 @@ -1,3 +1,10 @@ +cycfx2prog (0.47-1.3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Convert to debhelper. (Closes: #-1) + + -- Helmut Grohne Wed, 30 Oct 2024 21:19:13 +0100 + cycfx2prog (0.47-1.2) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru cycfx2prog-0.47/debian/control cycfx2prog-0.47/debian/control --- cycfx2prog-0.47/debian/control 2024-03-24 20:53:13.0 +0100 +++ cycfx2prog-0.47/debian/control 2024-10-30 21:16:51.0 +0100 @@ -2,7 +2,7 @@ Section: electronics Priority: optional Maintainer: Uwe Hermann -Build-Depends: cdbs, debhelper (>= 9), libusb-dev +Build-Depends: debhelper (>= 9), libusb-dev Standards-Version: 3.9.8 Homepage: http://www.triplespark.net/elec/periph/USB-FX2/software/ diff --minimal -Nru cycfx2prog-0.47/debian/dirs cycfx2prog-0.47/debian/dirs --- cycfx2prog-0.47/debian/dirs 2024-03-24 20:53:13.0 +0100 +++ cycfx2prog-0.47/debian/dirs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -usr/bin diff --minimal -Nru cycfx2prog-0.47/debian/install cycfx2prog-0.47/debian/install --- cycfx2prog-0.47/debian/install 1970-01-01 01:00:00.0 +0100 +++ cycfx2prog-0.47/debian/install 2024-10-30 21:17:50.0 +0100 @@ -0,0 +1 @@ +cycfx2prog usr/bin diff --minimal -Nru cycfx2prog-0.47/debian/patches/series cycfx2prog-0.47/debian/patches/series --- cycfx2prog-0.47/debian/patches/series 1970-01-01 01:00:00.0 +0100 +++ cycfx2prog-0.47/debian/patches/series 2024-10-30 21:19:13.0 +0100 @@ -0,0 +1 @@ +fix-ftbfs-with-ls-as-needed.patch diff --minimal -Nru cycfx2prog-0.47/debian/rules cycfx2prog-0.47/debian/rules --- cycfx2prog-0.47/debian/rules2024-03-24 20:53:13.0 +0100 +++ cycfx2prog-0.47/debian/rules2024-10-30 21:19:13.0 +0100 @@ -1,17 +1,8 @@ #!/usr/bin/make -f - -# Note: The version number here must be increased with each upstream release! -CFLAGS = -O2 -fno-rtti -fno-exceptions -D'CYCFX2PROG_VERSION=\"0.47\"' -W \ --Wall -Wformat -LDFLAGS = -lusb - -include /usr/share/cdbs/1/rules/debhelper.mk -include /usr/share/cdbs/1/class/makefile.mk -include /usr/share/cdbs/1/rules/simple-patchsys.mk -binary-install/cycfx2prog:: - install cycfx2prog debian/cycfx2prog/usr/bin +%: + dh $@ -clean:: - rm -f cycfx2prog +override_dh_auto_clean: + dh_auto_clean -- distclean
Bug#1086540: algol68g FTCBFS: uses AC_RUN_IFELSE
Source: algol68g Version: 3.1.2-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs algol68g fails to cross build from source, because it uses a number of AC_RUN_IFELSE tests. That macro does not work for cross compilation as running is what does not work. However, many of them simply check for sizes of types (where AC_CHECK_SIZEOF can be used). It turns out that sufficiently many can be replaced that cross building algol68g becomes feasible. I'm attaching a patch for your convenience. Helmut --- algol68g-3.1.2.orig/configure.ac +++ algol68g-3.1.2/configure.ac @@ -340,11 +340,10 @@ # Test on gcc capabilities. # AC_MSG_CHECKING([__attribute__((aligned())) supported]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [typedef int aint __attribute__((aligned(8)));])], + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [typedef int aint __attribute__((aligned(8)));])], [AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no) - AC_MSG_FAILURE([stop -- C compiler does not support __attribute__aligned directive])], - []) + AC_MSG_FAILURE([stop -- C compiler does not support __attribute__aligned directive])]) AC_C_INLINE() # # Set -I/usr/local/include for *BSD @@ -609,31 +608,23 @@ AC_MSG_NOTICE([optional headers and libraries...]) if test "x$enable_standard_types" = "xyes"; then - AC_MSG_CHECKING([int is 32 bit]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (int) != 4;])], - [AC_MSG_RESULT(yes)], - [AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([unsigned is 32 bit]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (unsigned) != 4;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([double is 64 bit]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (double) != 8;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([uint64_t is 64 bit]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([#include ], [return sizeof (uint64_t) != 8;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_standard_types=no - enable_long_types=no], - []) + AC_CHECK_SIZEOF([int]) + if test "x$ac_cv_sizeof_int" != x4; then +enable_long_types=no + fi + AC_CHECK_SIZEOF([unsigned]) + if test "x$ac_cv_sizeof_unsigned" != x4; then +enable_long_types=no + fi + AC_CHECK_SIZEOF([double]) + if test "x$ac_cv_sizeof_double" != x8; then +enable_long_types=no + fi + AC_CHECK_SIZEOF([uint64_t],[],[#include ]) + if test "x$ac_cv_sizeof_uint64_t" != x8; then +enable_standard_types=no +enable_long_types=no + fi fi if test "x$enable_standard_types" = "xno"; then @@ -641,36 +632,28 @@ fi if test "x$enable_long_types" = "xyes"; then - AC_MSG_CHECKING([64-bit long long int is available]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (long long) != 8;])], - [AC_MSG_RESULT(yes)], - [AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([64-bit long long unsigned is available]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (long long unsigned) != 8;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([80-bit __float80 is available]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (__float80) != 16;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([80-bit __float80 has 64-bit mantissa]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([#include ], [return LDBL_MANT_DIG != 64;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_long_types=no], - []) - AC_MSG_CHECKING([128-bit __float128 is available]) - AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return sizeof (__float128) != 16;])], -[AC_MSG_RESULT(yes)], -[AC_MSG_RESULT(no) - enable_long_types=no], - []) + AC_CHECK_SIZEOF([long long]) + if test "x$ac_cv_sizeof_long_long" != x8; then +enable_long_types=no + fi + AC_CHECK_SIZEOF([long long unsigned]) + if test "x$ac_cv_sizeof_long_long_unsigned" != x8; then +enable_long_types=no + fi + AC_CHECK_SIZEOF([__float80]) + if test "x$ac_cv_sizeof___float80" != x8; then +enable_long_types=no + fi + AC_CACHE_CHECK([LDBL_MANT_DIG],[ac_cv_ldbl_mant_dig], +[AC_COMPUTE_INT([ac_cv_ldbl_mant_dig],[LDBL_MANT_DIG],[#include ])] + ) + if test "x$ac_cv_ldbl_mant_dig" != x64; then +enable_long_types=no + fi + AC_CHECK_SIZEOF([__float128]) + if test "x$ac_cv_sizeof___float128" != x16; then +enable_long_types=no + fi if test "x$enable_long_types" = "xyes"; then AC_DEFINE(HAVE_LONG_TYPES, 1, [Define this if a good INT*8/REAL*10/REAL*16 installation was detected]) fi
Bug#1080405: Proceeding with removal of apertium-mlt-ara
Control: severity 1080405 normal Control: retitle 1080405 RM: apertium-mlt-ara -- RoQA; rc-buggy Control: reassign 1080405 ftp.debian.org Control: affects 1080405 + src:apertium-mlt-ara Dear apertium-mlt-ara maintainer and ftp team, a month has passed since filing a suggestion to remove apertium-mlt-ara from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1016336: apertium-mlt-ara: FTBFS: make[1]: *** [Makefile:790: ara-mlt.t1x.bin] Error 1 Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086388: dhcp-helper FTCBFS: builds for the build architecture
Source: dhcp-helper Version: 1.2-3.2 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs dhcp-helper successfully cross builds a broken package, because it simply does not honour any DEB_HOST variables and builds for the build architecture instead. I'm attaching a patch to make it use cross tools. More generally, I recommend using debhelper which would make the bulk of this patch unnecessary. Helmut diff --minimal -Nru dhcp-helper-1.2/debian/changelog dhcp-helper-1.2/debian/changelog --- dhcp-helper-1.2/debian/changelog2024-02-09 14:16:21.0 +0100 +++ dhcp-helper-1.2/debian/changelog2024-10-30 06:20:28.0 +0100 @@ -1,3 +1,10 @@ +dhcp-helper (1.2-3.3) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Use cross tools. (Closes: #-1) + + -- Helmut Grohne Wed, 30 Oct 2024 06:20:28 +0100 + dhcp-helper (1.2-3.2) unstable; urgency=medium * Non-maintainer upload. diff --minimal -Nru dhcp-helper-1.2/debian/rules dhcp-helper-1.2/debian/rules --- dhcp-helper-1.2/debian/rules2024-02-09 14:16:21.0 +0100 +++ dhcp-helper-1.2/debian/rules2024-10-30 06:20:27.0 +0100 @@ -11,6 +11,8 @@ package=dhcp-helper +include /usr/share/dpkg/buildtools.mk + CFLAGS = $(shell export DEB_BUILD_OPTIONS=$(DEB_BUILD_OPTIONS); dpkg-buildflags --get CFLAGS) CFLAGS += $(shell dpkg-buildflags --get CPPFLAGS) CFLAGS += $(shell dpkg-buildflags --get LDFLAGS) @@ -19,7 +21,7 @@ build: $(checkdir) - make CC=gcc CFLAGS="$(CFLAGS)" + make 'CC=$(CC)' CFLAGS="$(CFLAGS)" touch build clean: @@ -49,7 +51,7 @@ install -m 755 debian/postinst debian/postrm debian/prerm debian/tmp/DEBIAN install -m 755 dhcp-helper debian/tmp/usr/sbin ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) - strip -R .note -R .comment debian/tmp/usr/sbin/dhcp-helper + $(STRIP) -R .note -R .comment debian/tmp/usr/sbin/dhcp-helper endif install -m 755 debian/init debian/tmp/etc/init.d/dhcp-helper install -m 644 debian/default debian/tmp/etc/default/dhcp-helper
Bug#1086390: mathtex FTCBFS: builds during make install for the build architecture
Source: mathtex
Version: 1.03-3
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Tags: patch upstream
mathtex fails to cross build from source, because it builds for the
build architecture as it builds during make install where
dh_auto_install does not pass cross tools. I've reworked the Makefile to
build during the build target and am attaching a patch for your
convenience.
Helmut
--- mathtex-1.03.orig/Makefile
+++ mathtex-1.03/Makefile
@@ -1,10 +1,16 @@
TARGET=$(DESTDIR)/usr/bin/mathtex
-all:
+all:mathtex
-install:
+mathtex:mathtex.c
+ $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -DLATEX=\"/usr/bin/latex\" -DDVIPNG=\"/usr/bin/dvipng\" $< -o $@
+
+install:all
mkdir -p $(DESTDIR)/usr/bin
- $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -DLATEX=\"/usr/bin/latex\" -DDVIPNG=\"/usr/bin/dvipng\" mathtex.c -o ${TARGET}
+ install -m755 mathtex $(TARGET)
clean:
- rm -f ${TARGET}
+ rm -f mathtex
+
+uninstall:
+ rm -f $(TARGET)
Bug#1086389: libpng1.6 FTBFS on ppc64: VSX support unavailable
Source: libpng1.6 Version: 1.6.44-2 Severity: important Tags: patch ftbfs libpng1.6 FTBFS on ppc64, because it attempts to use VSX / AltiVec and gcc happens to not enable that by default as doing so would violate the ppc64 baseline. I suggest overriding the detection in d/rules. Additionally, this is misdetected in a powerpc cross build, so I likewise suggest overriding it there. Attaching a patch for your convenience. Helmut diff --minimal -Nru libpng1.6-1.6.44/debian/changelog libpng1.6-1.6.44/debian/changelog --- libpng1.6-1.6.44/debian/changelog 2024-09-17 11:37:20.0 +0200 +++ libpng1.6-1.6.44/debian/changelog 2024-10-30 06:09:15.0 +0100 @@ -1,3 +1,10 @@ +libpng1.6 (1.6.44-2.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Disable VSX on legacy powerpc CPUs. (Closes: #-1) + + -- Helmut Grohne Wed, 30 Oct 2024 06:09:15 +0100 + libpng1.6 (1.6.44-2) unstable; urgency=low * Switch packaging to cmake diff --minimal -Nru libpng1.6-1.6.44/debian/rules libpng1.6-1.6.44/debian/rules --- libpng1.6-1.6.44/debian/rules 2024-09-17 11:37:20.0 +0200 +++ libpng1.6-1.6.44/debian/rules 2024-10-30 06:08:55.0 +0100 @@ -14,6 +14,13 @@ include /usr/share/dpkg/architecture.mk +ifneq (,$(filter $(DEB_HOST_ARCH_CPU),powerpc ppc64)) +# VSX is an extension of AltiVec, which is not part of the baseline. +# see https://wiki.debian.org/ArchitectureSpecificsMemo +override_dh_auto_configure: + dh_auto_configure -- -DPNG_POWERPC_VSX=off +endif + override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) dh_auto_test
Bug#1080408: Proceeding with removal of apertium-kaz-tat
Control: severity 1080408 normal Control: retitle 1080408 RM: apertium-kaz-tat -- RoQA; rc-buggy Control: reassign 1080408 ftp.debian.org Control: affects 1080408 + src:apertium-kaz-tat Dear apertium-kaz-tat maintainer and ftp team, a month has passed since filing a suggestion to remove apertium-kaz-tat from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1005670: apertium-kaz-tat: FTBFS: ERROR: Transducer contains epsilon transition to a final state. Aborting. Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1079958: Proceeding with removal of epigrass
Control: severity 1079958 normal Control: retitle 1079958 RM: epigrass -- RoQA; rc-buggy Control: reassign 1079958 ftp.debian.org Control: affects 1079958 + src:epigrass Dear epigrass maintainer and ftp team, a month has passed since filing a suggestion to remove epigrass from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated 2 long-standing RC bugs. * #995966: epigrass: epirunner and epidash fail to run due to missing dash modules Last modified: 1 year, 9 months * #998265: epigrass: autopkgtest regression: The 'panel' distribution was not found Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080509: Proceeding with removal of devpi-common
Control: severity 1080509 normal
Control: retitle 1080509 RM: devpi-common -- RoQA; rc-buggy
Control: reassign 1080509 ftp.debian.org
Control: affects 1080509 + src:devpi-common
Dear devpi-common maintainer and ftp team,
a month has passed since filing a suggestion to remove devpi-common
from Debian. It was suggested for removal due to not being part of bookworm
nor trixie and having accumulated a long-standing RC bug.
* #1030453: devpi-common: FTBFS: dh_auto_test: error: pybuild --test
--test-pytest -i python{version} -p 3.11 returned exit code 13
Last modified: 1 year, 4 months
Since the suggestion bug was neither closed nor tagged in a month, silent
consent to proceed with removal is assumed.
Kind regards
A tool for automatically removing packages from unstable
This bug reply has been automatically sent with little human intervention.
If the filing is unclear or in error, don't hesitate to contact
Helmut Grohne for assistance.
Bug#1080504: Proceeding with removal of crazydiskinfo
Control: severity 1080504 normal Control: retitle 1080504 RM: crazydiskinfo -- RoQA; rc-buggy Control: reassign 1080504 ftp.debian.org Control: affects 1080504 + src:crazydiskinfo Dear crazydiskinfo maintainer and ftp team, a month has passed since filing a suggestion to remove crazydiskinfo from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #997156: crazydiskinfo: FTBFS: main.cpp:217:18: error: format not a string literal and no format arguments [-Werror=format-security] Last modified: 1 year, 8 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080503: Proceeding with removal of backdoor-factory
Control: severity 1080503 normal Control: retitle 1080503 RM: backdoor-factory -- RoQA; rc-buggy Control: reassign 1080503 ftp.debian.org Control: affects 1080503 + src:backdoor-factory Dear backdoor-factory maintainer and ftp team, a month has passed since filing a suggestion to remove backdoor-factory from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1027037: backdoor-factory: Backdoor-factory isn't working after python3 transition Last modified: 1 year, 10 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080411: Proceeding with removal of apertium-sme-nob
Control: severity 1080411 normal Control: retitle 1080411 RM: apertium-sme-nob -- RoQA; rc-buggy Control: reassign 1080411 ftp.debian.org Control: affects 1080411 + src:apertium-sme-nob Dear apertium-sme-nob maintainer and ftp team, a month has passed since filing a suggestion to remove apertium-sme-nob from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1008348: apertium-sme-nob: FTBFS: semanticroles.cg3: Error: Expected set on line 4400 near `;ââTEMPLATE uniqueLO`! Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080410: Proceeding with removal of apertium-crh-tur
Control: severity 1080410 normal Control: retitle 1080410 RM: apertium-crh-tur -- RoQA; rc-buggy Control: reassign 1080410 ftp.debian.org Control: affects 1080410 + src:apertium-crh-tur Dear apertium-crh-tur maintainer and ftp team, a month has passed since filing a suggestion to remove apertium-crh-tur from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1016319: apertium-crh-tur: FTBFS: make[2]: *** [Makefile:890: crh-tur.t1x.bin] Error 1 Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1080075: Proceeding with removal of laminar
Control: severity 1080075 normal Control: retitle 1080075 RM: laminar -- RoQA; rc-buggy Control: reassign 1080075 ftp.debian.org Control: affects 1080075 + src:laminar Dear laminar maintainer and ftp team, a month has passed since filing a suggestion to remove laminar from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1019455: laminard: WebUI of laminar fails because newer incompatible version of Chart.js is included Last modified: 1 year, 11 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1079961: Proceeding with removal of leap-archive-keyring
Control: severity 1079961 normal Control: retitle 1079961 RM: leap-archive-keyring -- RoQA; rc-buggy Control: reassign 1079961 ftp.debian.org Control: affects 1079961 + src:leap-archive-keyring Dear leap-archive-keyring maintainer and ftp team, a month has passed since filing a suggestion to remove leap-archive-keyring from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #880220: should not install a globally valid trust anchor Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086219: policy-incompliant use of Conflicts
Hi Antoine,
On Tue, Oct 29, 2024 at 09:49:42AM -0400, Antoine Beaupré wrote:
> I think I understand where you're coming from, but I fail to find a
> reference in the Debian policy about this. Section 7.4 doesn't talk
> about incompatible APIs, for example.
Indeed, it's not that explicit in policy. Interpretation varies here.
Policy very explicitly discourages the use of Conflicts in your
situation (which is not the same as forbidding it).
> I was thinking of shipping python3-ulid's in a separate binary package
> ("python3-ulid-cli"?) to allow python3-ulid and ulid-cli to be installed
> in parallel, would that fix this bug for you?
>
> Otherwise how do you suggest we proceed here?
The common way to deal with this is to rename one or both
implementations.
> How different are the two interfaces anyways?
The tech-ctte had to discuss this for the case of rename vs rename.ul
and I think this transfers well to ulid. If you cannot access the core
functionality of the tool with both providers in a compatible way,
they're too different. In this case, the command line interface is
significantly different:
task | ulid-cli | python3-ulid | notes
-+---++-
generate | ulid | ulid build |
inspect | ulid ULID | ulid show ULID | output structure differs
There is no way of using these commands in a compatible way. If there
were, update-alternatives would be a reasonable tool.
So I recommend simply renaming it to ulid-python, because the majority
of users will use the Python module rather than the CLI. Maybe also talk
to upstream whether they want to make their their implementation
compatible with ulid-cli.
Helmut
Bug#1086329: mark libamdhip64-5 Multi-Arch: same
Package: libamdhip64-5,libhiprtc-builtins5,rocm-opencl-icd
Version: 5.7.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:aevol src:ampliconnoise src:colmap src:combblas
src:ectrans src:examl src:fdb src:ffindex src:flann src:form src:garli
src:gfsview src:gloo src:hpcc src:hyphy src:kokkos src:lrslib src:metkit
src:mfem src:molds src:mpi-defaults src:mrbayes src:mrmpi src:netcdf-parallel
src:odc src:openfoam src:otf src:phyml src:ray src:relion src:rocalution
src:spfft src:spooles src:tree-puzzle src:valgrind
The affected packages cannot satisfy their cross Build-Depends, because
their transitive dependency on libamdhip64-5 needs to be satisfied for
the build and host architecture simultaneously, but libamdhip64-5 is not
marked Multi-Arch: same and therefore does not allow coinstallation. Its
files are already laid out in a compatible way and the multiarch hinter
suggests that Multi-Arch: same is safe to add. I'm attaching a patch for
your convenience.
Helmut
diff --minimal -Nru rocm-hipamd-5.7.1/debian/changelog
rocm-hipamd-5.7.1/debian/changelog
--- rocm-hipamd-5.7.1/debian/changelog 2024-09-25 00:15:52.0 +0200
+++ rocm-hipamd-5.7.1/debian/changelog 2024-10-29 20:46:36.0 +0100
@@ -1,3 +1,11 @@
+rocm-hipamd (5.7.1-5.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Mark libamdhip64-5, libhiprtc-builtins5, and rocm-opencl-icd
+Multi-Arch: same (Closes: #-1)
+
+ -- Helmut Grohne Tue, 29 Oct 2024 20:46:36 +0100
+
rocm-hipamd (5.7.1-5) unstable; urgency=medium
* Source only upload for migration to testing.
diff --minimal -Nru rocm-hipamd-5.7.1/debian/control
rocm-hipamd-5.7.1/debian/control
--- rocm-hipamd-5.7.1/debian/control2024-09-24 23:05:58.0 +0200
+++ rocm-hipamd-5.7.1/debian/control2024-10-29 20:46:25.0 +0100
@@ -77,6 +77,7 @@
Package: libamdhip64-5
Section: libs
Architecture: amd64 arm64 ppc64el
+Multi-Arch: same
Depends: libamd-comgr2, ${misc:Depends}, ${shlibs:Depends}
Description: Heterogeneous Interface for Portability - AMD GPUs implementation
This package is central to the ROCm stack. It is at the exchange point between
@@ -103,6 +104,7 @@
Package: libhiprtc-builtins5
Section: libs
Architecture: amd64 arm64 ppc64el
+Multi-Arch: same
Depends: ${misc:Depends}, ${shlibs:Depends}
Description: HIP Run Time Compilation libraries
HIP allows one to compile kernels at runtime with its hiprtc* APIs. hipRTC
@@ -127,6 +129,7 @@
Package: rocm-opencl-icd
Section: libs
Architecture: amd64 arm64 ppc64el
+Multi-Arch: same
Provides: opencl-icd
Depends: ${misc:Depends}, ${shlibs:Depends}
# Either will trigger LLVM double load bug
Bug#1086236: bsdmainutils FTBFS on musl-linux-any: sys/cdefs.h does not exist
Source: bsdmainutils
Version: 12.1.8
Tags: ftbfs patch upstream
User: helm...@debian.org
Usertags: rebootstrap
bsdmainutils fails to build from source on musl-linux-any, because the
musl C library does not provide a sys/cdefs.h header. This header is
being included for using __FBSDID. However. the relevant Makefile also
adds "-include bsd/string.h" to the compiler flags and that happens to
provide a definition of __FBSDID. Therefore, we can delete sys/cdefs.h
at no loss of functionality and thus make the build pass. I'm attaching
a patch for your convenience.
Helmut
--- a/usr.bin/ncal/calendar.c
+++ b/usr.bin/ncal/calendar.c
@@ -26,7 +26,6 @@
* SUCH DAMAGE.
*/
-#include
#include
__FBSDID("$FreeBSD: head/lib/libcalendar/calendar.c 326219 2017-11-26 02:00:33Z pfg $");
--- bsdmainutils-12.1.8.orig/usr.bin/ncal/easter.c
+++ bsdmainutils-12.1.8/usr.bin/ncal/easter.c
@@ -26,7 +26,6 @@
* SUCH DAMAGE.
*/
-#include
__FBSDID("$FreeBSD: head/lib/libcalendar/easter.c 326219 2017-11-26 02:00:33Z pfg $");
#include "calendar.h"
--- bsdmainutils-12.1.8.orig/usr.bin/ncal/ncal.c
+++ bsdmainutils-12.1.8/usr.bin/ncal/ncal.c
@@ -26,7 +26,6 @@
* SUCH DAMAGE.
*/
-#include
__FBSDID("$FreeBSD: head/usr.bin/ncal/ncal.c 359419 2020-03-29 04:18:27Z grog $");
#include "calendar.h"
Bug#1086220: Should php-sabre-uri be removed from unstable?
Source: php-sabre-uri Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing php-sabre-uri from Debian for the following reasons: * It accumulated one RC-bug: + #882923: php-sabre-uri FTBFS with phpunit 6.4.4-2 Last modified: 1 year, 4 months * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: php-sabre-uri -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:php-sabre-uri Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086219: policy-incompliant use of Conflicts
Package: python3-ulid Version: 2.2.0-3 Severity: serious Justification: policy violation Conflicts must not be used to choose between incompatible APIs. Instead one or both implementations should be renamed. python3-ulid's ulid does not support the same syntax as ulid-cli's ulid. Helmut
Bug#1086133: [subject discarded as the bts seems to choke on it]
Hi Alastair, On Mon, Oct 28, 2024 at 06:47:52AM +, Alastair McKinstry wrote: > I think going with the Ubuntu solution for now looks like the most pragmatic > answer. I think the Ubuntu answer is a latent security issue. As noted on irc, it can be made safe by also adding a compile time assertion that sizeof(wchar_t) == sizeof(FriBidiChar). Consider also adding: typedef char static_assertion_wchar_size[(sizeof(wchar_t) == sizeof(FriBidiChar))?1:-1]; Once you do this, the cast can no longer cause an out-of-bounds access without failing compilation. Helmut
Bug#1084924: The system-log-daemon virtual package
Hi Sean, On Mon, Oct 28, 2024 at 04:37:06PM +0800, Sean Whitton wrote: > I think I see a way to distinguish these four cases in a way that gets > everyone what they want. > > systemd adds an *empty* binary package > Package: systemd-journald-is-syslog > Provides/Conflicts: system-log-daemon Thank you for bringing this up. Despite the little confusion in the end that Chris remarked, I think this practically covers the four cases. However, I think there is a fifth case that is becoming more and more practically relevant. Both docker and podman now have a logging driver called journald. https://docs.docker.com/engine/logging/drivers/journald/ I'm not yet sure exactly how this works, but the context is "slim" containers (i.e. those that do not run systemd as pid 1) and I very much expect them to not run a journald from the container environment either. Rather the container runtime essentially provides /dev/log and a journald socket to the container in some (unspecified?) way. This kinda is similar to dbconfig where we have dbconfig-no-thanks. We'd need another package syslog-no-thanks that would have the same provides and conflicts but no systemd dependency now. Of course just adding such a package would result in apt selecting it whenever systemd is difficult to install. In effect, adding such a package would render dependencies on system-log-daemon meaningless and we could just drop them - which is what has been happening and has resulted in this bug. So now we're running in circles. Effectively, we must decide whether the container use case is more important than the non-systemd case or the other way round. I do not see a way to make both just work in a sane way. Helmut
Bug#1086159: filament FTCBFS: missing include ImportExecutables-None.cmake
Source: filament Version: 1.9.25+dfsg3-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs filament fails to cross build from source. On the surface, CMake attempts to include a ImportExecutables-None.cmake and fails to find that. I guess the idea is that one first builds filament natively (thus generating this file) and then passes it to the cross build. However, here, we just install libfilament-tools from an earlier native build and it happens to include the requested file. Hence I suggest simply adding it to the debian directory. Inside, we simply declare the relevant executables to improt, which happens to be resgen at the moment. The file is only used for cross building (all includes are conditionalized with CMAKE_CROSSCOMPILING), so things should be all well. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru filament-1.9.25+dfsg3/debian/ImportExecutables-None.cmake filament-1.9.25+dfsg3/debian/ImportExecutables-None.cmake --- filament-1.9.25+dfsg3/debian/ImportExecutables-None.cmake 1970-01-01 01:00:00.0 +0100 +++ filament-1.9.25+dfsg3/debian/ImportExecutables-None.cmake 2024-10-27 19:51:55.0 +0100 @@ -0,0 +1,2 @@ +add_executable(resgen IMPORTED) +set_property(TARGET resgen PROPERTY IMPORTED_LOCATION /usr/bin/filament-resgen) diff --minimal -Nru filament-1.9.25+dfsg3/debian/changelog filament-1.9.25+dfsg3/debian/changelog --- filament-1.9.25+dfsg3/debian/changelog 2024-05-17 18:12:19.0 +0200 +++ filament-1.9.25+dfsg3/debian/changelog 2024-10-27 19:51:55.0 +0100 @@ -1,3 +1,11 @@ +filament (1.9.25+dfsg3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Add an ImportExecutables-None.cmake declaring resgen. +(Closes: #-1) + + -- Helmut Grohne Sun, 27 Oct 2024 19:51:55 +0100 + filament (1.9.25+dfsg3-1) unstable; urgency=medium * New upstream version 1.9.25+dfsg3
Bug#1086158: openscenegraph FTCBFS: uses CHECK_CXX_SOURCE_RUNS
Source: openscenegraph
Version: 3.6.5+dfsg1-8
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
openscenegraph fails to cross build from source, because it uses
CHECK_CXX_SOURCE_RUNS. The invocation around atomics is difficult to
avoid, but the one for poppler-glib is quite easy to avoid. Hence I'm
sending a patch for the latter to incrementally move things forward. We
may use CHECK_SYMBOL_EXISTS there instead.
Helmut
--- openscenegraph-3.6.5+dfsg1.orig/CMakeModules/FindPoppler-glib.cmake
+++ openscenegraph-3.6.5+dfsg1/CMakeModules/FindPoppler-glib.cmake
@@ -10,23 +10,12 @@
IF (POPPLER_FOUND)
-INCLUDE(CheckCXXSourceRuns)
+INCLUDE(CheckSymbolExists)
SET(CMAKE_REQUIRED_INCLUDES ${POPPLER_INCLUDE_DIRS})
# Do step by step checking,
-CHECK_CXX_SOURCE_RUNS("
-#include
-#include
-int main()
-{
-#ifdef POPPLER_HAS_CAIRO
- return EXIT_SUCCESS;
-#else
- return EXIT_FAILURE
-#endif
-}
-" POPPLER_HAS_CAIRO)
+CHECK_SYMBOL_EXISTS(POPPLER_HAS_CAIRO "poppler.h" POPPLER_HAS_CAIRO)
IF (NOT POPPLER_HAS_CAIRO)
SET(POPPLER_FOUND FALSE)
Bug#1086133: [subject discarded as the bts seems to choke on it]
On Sun, Oct 27, 2024 at 09:19:51AM +0100, Helmut Grohne wrote:
> | gcc -I/usr/include/tcl8.6 -g -O2 -Werror=implicit-function-declaration
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security -DMARCH=\"i386-linux-gnu\" -D_GNU_SOURCE -Wdate-time
> -D_FORTIFY_SOURCE=2 -c -o label.o label.c
> | newt.c: In function ‘wchar_to_textmod_visual’:
> | newt.c:304:17: error: passing argument 1 of ‘func_ptr’ from incompatible
> pointer type [-Wincompatible-pointer-types]
> | 304 | (*func_ptr)(in, len, base_dir, out, NULL, NULL, NULL);
> | | ^~
> | | |
> | | wchar_t * {aka long int *}
> | newt.c:304:17: note: expected ‘FriBidiChar *’ {aka ‘unsigned int *’} but
> argument is of type ‘wchar_t *’ {aka ‘long int *’}
> | make[2]: *** [: newt.o] Error 1
> | make[2]: *** Waiting for unfinished jobs
> | make[2]: Leaving directory '/<>'
> | dh_auto_build: error: make -j8 returned exit code 2
> | make[1]: *** [debian/rules:51: override_dh_auto_build] Error 25
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:14: build] Error 2
> | dpkg-buildpackage: error: debian/rules build subprocess returned exit
> status 2
I dug into this a little bit and got some conclusions.
in is a wchar_t array and constructed using mbstowcs.
FriBidiChar used to be wchar_t before fribidi 1.0.4 imported into Debian
in 2018. Since then, i386 produced a warning:
https://buildd.debian.org/status/fetch.php?pkg=newt&arch=i386&ver=0.52.24-2%2Bb1&stamp=1720822697&raw=0
| gcc -I/usr/include/tcl8.6 -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -DMARCH=\"i386-linux-gnu\" -D_GNU_SOURCE -Wdate-time
-D_FORTIFY_SOURCE=2 -c -o checkbox.o checkbox.c
| newt.c: In function ‘wchar_to_textmod_visual’:
| newt.c:304:17: warning: passing argument 1 of ‘func_ptr’ from incompatible
pointer type [-Wincompatible-pointer-types]
| 304 | (*func_ptr)(in, len, base_dir, out, NULL, NULL, NULL);
| | ^~
| | |
| | wchar_t * {aka long int *}
In some recent toolchain change, this warning has become an error
(probably gcc-14) and now it fails.
The wchar_t type is quite architecture dependent. It can be 16bit or
32bit. Its signedness should match that of char. On glibc architectures,
it is 32bit. This is why we are not seeing a failure on armel and armhf
where char is unsigned.
The function wchar_to_textmod_visual where this is happening is declared
static and only called two times. In both cases, a const char * string
is converted to wchar_t using mbstowcs.
Arguably, fribidi did an ABI break in 2018, but it is so long ago that
bumping soname no longer makes any sense. fribidi also did the right
thing and got rid of wchar_t as dealing with that type is very platform
dependent.
Ubuntu also encountered this bug
https://bugs.launchpad.net/ubuntu/+source/newt/+bug/2083549 and opted
for just casting the pointer. What could possibly go wrong?
Helmut
Bug#1086132: binutils-avr FTCBFS: hard codes the build architecture compiler
Source: binutils-avr Version: 2.43.1-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs binutils-avr fails to cross build from source, because debian/rules forces the use of the build architecture compiler where a host architecture compiler should be used. I'm attaching a patch to stop doing that. Helmut diff --minimal -Nru binutils-avr-2.43.1/debian/changelog binutils-avr-2.43.1/debian/changelog --- binutils-avr-2.43.1/debian/changelog2024-09-29 23:32:21.0 +0200 +++ binutils-avr-2.43.1/debian/changelog2024-10-27 08:55:55.0 +0100 @@ -1,3 +1,10 @@ +binutils-avr (2.43.1-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Don't force the build architecture compiler. (Closes: #-1) + + -- Helmut Grohne Sun, 27 Oct 2024 08:55:55 +0100 + binutils-avr (2.43.1-1) unstable; urgency=low * Switch to mainstream binutils (Closes: #855849) * Fix fail to build source after build (Closes: #1044001) diff --minimal -Nru binutils-avr-2.43.1/debian/rules binutils-avr-2.43.1/debian/rules --- binutils-avr-2.43.1/debian/rules2024-09-29 23:32:21.0 +0200 +++ binutils-avr-2.43.1/debian/rules2024-10-27 08:55:50.0 +0100 @@ -65,7 +65,7 @@ dh_update_autotools_config # Add here commands to configure the package. - cd $(BUILD_TREE) && env CC="gcc" CFLAGS="-Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter" CPPFLAGS="$(CPPFLAGS)" ../src/configure $(CONFARGS) + cd $(BUILD_TREE) && env CFLAGS="-Wno-error=unused-but-set-variable -Wno-error=unused-but-set-parameter" CPPFLAGS="$(CPPFLAGS)" ../src/configure $(CONFARGS) make -C $(BUILD_TREE) maybe-configure-bfd make -C $(BUILD_TREE)/bfd/ headers touch configure-stamp
Bug#1086133: newt FTBFS on i386 (and hppa, mipsel, m68k, sh4 and x32): newt.c:304:17: error: passing argument 1 of ‘func_ptr’ from incompatible pointer type [-Wincompatible-pointer-types]
Package: newt
Version: 0.52.24-2
Severity: serious
Tags: ftbfs
Justification: i386 still is a release architecture and it built there earlier
new fails to build from source in unstable on i386 (and hppa, mipsel,
m68k, sh4 and x32). A build log ends as follows:
| gcc -I/usr/include/tcl8.6 -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -DMARCH=\"i386-linux-gnu\" -D_GNU_SOURCE -Wdate-time
-D_FORTIFY_SOURCE=2 -c -o label.o label.c
| newt.c: In function ‘wchar_to_textmod_visual’:
| newt.c:304:17: error: passing argument 1 of ‘func_ptr’ from incompatible
pointer type [-Wincompatible-pointer-types]
| 304 | (*func_ptr)(in, len, base_dir, out, NULL, NULL, NULL);
| | ^~
| | |
| | wchar_t * {aka long int *}
| newt.c:304:17: note: expected ‘FriBidiChar *’ {aka ‘unsigned int *’} but
argument is of type ‘wchar_t *’ {aka ‘long int *’}
| make[2]: *** [: newt.o] Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory '/<>'
| dh_auto_build: error: make -j8 returned exit code 2
| make[1]: *** [debian/rules:51: override_dh_auto_build] Error 25
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:14: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
This failure is also seen by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/newt_0.52.24-2.rbuild.log.gz
Helmut
Bug#1081213: Proceeding with removal of eclipse-tracecompass
Control: severity 1081213 normal Control: retitle 1081213 RM: eclipse-tracecompass -- RoQA; rc-buggy Control: reassign 1081213 ftp.debian.org Control: affects 1081213 + src:eclipse-tracecompass Dear eclipse-tracecompass maintainer and ftp team, a month has passed since filing a suggestion to remove eclipse-tracecompass from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1010983: eclipse-tracecompass: Does not start Last modified: 2 years Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086129: Should irsim be removed from unstable?
Source: irsim Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing irsim from Debian for the following reasons: * It accumulated one RC-bug: + #997299: irsim: FTBFS: configure: error: cannot find required auxiliary files: install-sh config.guess config.sub Last modified: 1 year, 1 day * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: irsim -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:irsim Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086130: Should golang-github-jesseduffield-go-getter be removed from unstable?
Source: golang-github-jesseduffield-go-getter Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing golang-github-jesseduffield-go-getter from Debian for the following reasons: * It accumulated one RC-bug: + #1032107: Don't release with bookworm Last modified: 1 year, 3 days * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: golang-github-jesseduffield-go-getter -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:golang-github-jesseduffield-go-getter Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1081403: Proceeding with removal of profitbricks-sdk-python
Control: severity 1081403 normal Control: retitle 1081403 RM: profitbricks-sdk-python -- RoQA; rc-buggy Control: reassign 1081403 ftp.debian.org Control: affects 1081403 + src:profitbricks-sdk-python Dear profitbricks-sdk-python maintainer and ftp team, a month has passed since filing a suggestion to remove profitbricks-sdk-python from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1020092: profitbricks-sdk-python: FTBFS: make[1]: *** [debian/rules:12: override_dh_auto_test] Error 1 Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082606: Proceeding with removal of nautilus-scripts-manager
Control: severity 1082606 normal Control: retitle 1082606 RM: nautilus-scripts-manager -- RoQA; rc-buggy Control: reassign 1082606 ftp.debian.org Control: affects 1082606 + src:nautilus-scripts-manager Dear nautilus-scripts-manager maintainer and ftp team, a month has passed since filing a suggestion to remove nautilus-scripts-manager from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1033761: nautilus-scripts-manager: nautilus-script-manager throws exception under bookworm Last modified: 1 year, 6 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1081493: Proceeding with removal of nuitka
Control: severity 1081493 normal Control: retitle 1081493 RM: nuitka -- RoQA; rc-buggy Control: reassign 1081493 ftp.debian.org Control: affects 1081493 + src:nuitka Dear nuitka maintainer and ftp team, a month has passed since filing a suggestion to remove nuitka from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1030440: nuitka: FTBFS: make[1]: *** [debian/rules:47: override_dh_auto_test] Error 1 Last modified: 1 year, 7 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1086034: varnish-modules FTCBFS: uses the build architecture pkg-config
Source: varnish-modules Version: 0.25.0-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs varnish-modules fails to cross build from source, because it uses the build architecture pkg-config to query the host architecture varnishapi.pc and then passes an invalid include directory to aclocal. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru varnish-modules-0.25.0/debian/changelog varnish-modules-0.25.0/debian/changelog --- varnish-modules-0.25.0/debian/changelog 2024-10-21 23:47:07.0 +0200 +++ varnish-modules-0.25.0/debian/changelog 2024-10-24 10:30:47.0 +0200 @@ -1,3 +1,10 @@ +varnish-modules (0.25.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host arch pkg-config to look up varnishapi. (Closes: #-1) + + -- Helmut Grohne Thu, 24 Oct 2024 10:30:47 +0200 + varnish-modules (0.25.0-1) unstable; urgency=medium * New upstream release. diff --minimal -Nru varnish-modules-0.25.0/debian/rules varnish-modules-0.25.0/debian/rules --- varnish-modules-0.25.0/debian/rules 2024-10-21 23:47:07.0 +0200 +++ varnish-modules-0.25.0/debian/rules 2024-10-24 10:30:46.0 +0200 @@ -6,6 +6,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk +include /usr/share/dpkg/buildtools.mk P := \) @@ -16,7 +17,7 @@ cut -d ' ' -f 4 | \ tr -d '$(P)') -export VARNISHAPI_DATAROOTDIR = $(shell pkg-config varnishapi --variable=datarootdir) +export VARNISHAPI_DATAROOTDIR = $(shell $(PKG_CONFIG) varnishapi --variable=datarootdir) %: dh $@
Bug#1086017: zless: errors out with "less: not found" if less is not installed
Hi, On Thu, Oct 24, 2024 at 10:12:12PM -0500, Aaron Rainbolt wrote: > gzip is a package with priority "essential". It currently suggests the > "less" package, which has priority "important". less is a hard > dependency of zless - if it is not installed, zless will error out with > "exec: less: not found". Section 3.8 of the Debian Policy Manual states > "Packages may assume that functionality provided by essential packages > is always available without declaring explicit dependencies...". This > implies to me that essential packages must be fully functional in all > respects without the installation of any additional dependencies beyond > what the package itself declares, since this is the only way this > assumption can hold true. This bug was originally reported to #debian-devel and discussion continued there with kaol and elbrus. The term "functional provided by essential packages" leaves room for interpretation. In fact, what functionality is provided by a package is a very loosely defined concept in general and that very much is the reason why our policy still has no definition of what Multi-Arch: foreign means. The functionality of a package often is quite undefined unfortunately. Just because you happen to receive some functionality by depending on a package doesn't mean that you get the same functionality tomorrow and this fully accounts to implicit dependencies (such as the ones on essential packages). A very close example likely is `tar --zstd -c . >/dev/null`. It fails with `/bin/sh: 1: zstd: not found`. Likewise, tar is essential and zstd is not. Arguably, tar should suggest or recommend zstd though. Recommends and Suggests are a mechanism to express optional dependencies. For instance, diffoscope is a package excessively using these to avoid hard dependencies. You cannot assume that diffoscope produces a detailed diff just because your dependencies are satisfied. It may error out asking you to install another package. gzip suggests less indicating that some of its functionality is optional and that may include an entire command. A better example may be devscripts. It also uses Recommends excessively. For instance `cvs-debi` fails with `cvs-debi: need the cvs-buildpackage package installed to run this` and `archpath` fails with `/usr/bin/archpath: line 30: tla: command not found`. Neither devscripts or diffoscope are essential, but the underlying concept is that you can have optional functionality. The "always available" language refers to another aspect of packaging. The functionality is normally only required to be available when a package is configured. If it is deconfigured for upgrading, it may stop providing its functionality. Not so for essential packages. Their functionality must remain available even during upgrades. In essence, I argue that zless is optional functionality and not covered by the policy text. If it were, we'd quickly find a pile of other policy violations of the same kind hinting that maybe policy is not up to date with reality and this actually constitutes a bug in policy. > Either gzip should promote "less" to a dependency, or zless should be > split into a separate package that is not marked as essential. Given > that zless is already part of gzip's functionality, I do not believe > that splitting it out is an option because "any capability added to an > essential package ... creates an obligation to support that capability > as part of the Essential set in perpetuity." Splitting quite definitely is an option. I removed e2fsprogs from essential. It's a lot of work, but it is practically feasible. However, adding a zless package for a 2kb shell script may not be the best use of our resources as package metadata produces a cost to every installation. Paul and kaol pointed out that moving zless to the less package may be an option though. Given that less implicitly depends on gzip (due to essential), it would work whenever less is installed. I'm not convinced that actually constitutes a policy violation, but a move of zless from gzip to less still sounds plausible to me. Helmut
Bug#1086033: debci-worker: cron job runs when package is removed but not purged
Package: debci-worker
Version: 3.6
Tags: patch
Severity: wishlist
Control: found -1 debci/3.10
Hi,
I accidentally learned that the debci-worker daily cronjob actually runs
when debci-worker is removed but not purged. I don't think this is
intended. The cronjob source starts with:
| if ! dpkg-query --show debci-worker >/dev/null 2>&1; then
| exit
| fi
When debci-worker is removed, but not purged, dpkg-query succeeds. I
suggest changing this to:
| if test "$(dpkg-query --show --showformat '${db:Status-Status}' debci-worker
2>/dev/null)" != installed; then
| exit
| fi
A trivial workaround for this issue is purging debci-worker.
Helmut
Bug#1085868: Should monkeysphere be removed from unstable?
Source: monkeysphere Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing monkeysphere from Debian for the following reasons: * It accumulated one RC-bug: + #1011900: monkeysphere: FTBFS: ...Could not chdir to home directory /home/user42: No such file or directory Last modified: 1 year, 2 months * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: monkeysphere -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:monkeysphere Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1085867: Should php-sabre-event be removed from unstable?
Source: php-sabre-event Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing php-sabre-event from Debian for the following reasons: * It accumulated one RC-bug: + #882915: php-sabre-event FTBFS with phpunit 6.4.4-2 Last modified: 1 year, 4 months * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: php-sabre-event -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:php-sabre-event Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1085866: Should ruby-coffee-script be removed from unstable?
Source: ruby-coffee-script Severity: important User: helm...@debian.org Usertags: sidremove Dear maintainer, I suggest removing ruby-coffee-script from Debian for the following reasons: * It accumulated one RC-bug: + #1019927: Remove ruby-coffee-script - deprecated upstream Last modified: 1 year, 4 months * It is not part of bookworm or trixie and is not a key package. This bug serves as a pre-removal warning. After one month, the bug will be reassigned to ftp.debian.org to actually request removal of the package. In case the package should be kept in unstable, please evaluate each of the RC-bugs listed above. * If the bug is meant to permanently prevent the package from entering testing or a stable release, but this package should stay part of unstable, please add a usertag: user helm...@debian.org usertags NNN + sidremove-ignore * If the bug no longer applies, please close it. If it is closed, check whether the fixed version is correct and adjust if necessary. * Is the bug really release-critical? If not, please downgrade. * If the bug still applies, please send a status update at least once a year. Once all of the mentioned RC bugs have been acted upon in one way or another, please close this bug. In case the package should be removed from unstable, you may reassign this bug report: Control: severity -1 normal Control: retitle -1 RM: ruby-coffee-script -- RoM; rc-buggy Control: reassign -1 ftp.debian.org Control: affects -1 + src:ruby-coffee-script Alternatively, you may wait a month and have it reassigned. In case you disagree with the above, please add a wontfix tag to this bug. Control: tags -1 + wontfix Doing so will also prevent automatic reassignment. Kind regards A tool for automatically removing packages from unstable This bug report has been automatically filed with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1023744: meson: debcrossgen: should include cmake
Hi Simon, On Tue, Oct 22, 2024 at 02:41:45PM +0100, Simon McVittie wrote: > So to solve this, either the debcrossgen in Meson's Debian packaging > needs to use what is currently the MESON_USE_NEW_CROSSGEN=1 code path > by default (possibly with an opt-out to go back to the old behaviour if > we are concerned about regressions), or consumers of information from > debcrossgen (which I believe means debhelper and debputy but nothing else) > need to be updated to invoke `meson env2mfile` instead. A change to debhelper to make it use env2mfile is prepared at https://salsa.debian.org/debian/debhelper/-/merge_requests/127. We are waiting for green light from Jussi before merging. Helmut
Bug#1082329: Proceeding with removal of node-puppeteer
Control: severity 1082329 normal Control: retitle 1082329 RM: node-puppeteer -- RoQA; rc-buggy Control: reassign 1082329 ftp.debian.org Control: affects 1082329 + src:node-puppeteer Dear node-puppeteer maintainer and ftp team, a month has passed since filing a suggestion to remove node-puppeteer from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1026868: node-puppeteer: autopkgtest regression: 13 failing Last modified: 1 year, 9 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082332: Proceeding with removal of gnat-gps
Control: severity 1082332 normal Control: retitle 1082332 RM: gnat-gps -- RoQA; rc-buggy Control: reassign 1082332 ftp.debian.org Control: affects 1082332 + src:gnat-gps Dear gnat-gps maintainer and ftp team, a month has passed since filing a suggestion to remove gnat-gps from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated 2 long-standing RC bugs. * #936624: gnat-gps: Python2 removal in sid/bullseye Last modified: 1 year, 4 months * #979146: gnat-gps: FTBFS because BD can not be installed (gnat-9 vs 10) Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082331: Proceeding with removal of thawab
Control: severity 1082331 normal Control: retitle 1082331 RM: thawab -- RoQA; rc-buggy Control: reassign 1082331 ftp.debian.org Control: affects 1082331 + src:thawab Dear thawab maintainer and ftp team, a month has passed since filing a suggestion to remove thawab from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #990746: /usr/bin/thawab-gtk: thawab fails to start. Last modified: 1 year, 6 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082333: Proceeding with removal of libapache2-mod-defensible
Control: severity 1082333 normal Control: retitle 1082333 RM: libapache2-mod-defensible -- RoQA; rc-buggy Control: reassign 1082333 ftp.debian.org Control: affects 1082333 + src:libapache2-mod-defensible Dear libapache2-mod-defensible maintainer and ftp team, a month has passed since filing a suggestion to remove libapache2-mod-defensible from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated 2 long-standing RC bugs. * #965622: libapache2-mod-defensible: Removal of obsolete debhelper compat 5 and 6 in bookworm Last modified: 1 year, 4 months * #998981: libapache2-mod-defensible: missing required debian/rules targets build-arch and/or build-indep Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082330: Proceeding with removal of info-beamer
Control: severity 1082330 normal Control: retitle 1082330 RM: info-beamer -- RoQA; rc-buggy Control: reassign 1082330 ftp.debian.org Control: affects 1082330 + src:info-beamer Dear info-beamer maintainer and ftp team, a month has passed since filing a suggestion to remove info-beamer from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1004823: info-beamer: FTBFS with ffmpeg 5.0 Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1085407: Fwd: Bug#1085407: base-files: please provide versioned usr-is-merged
Control: reassign -1 dbus Control: affects -1 + base-files Control: tags -1 + pending Control: forwarded -1 https://salsa.debian.org/utopia-team/dbus/-/merge_requests/10 On Sun, Oct 20, 2024 at 04:30:54PM +0200, Santiago Vila wrote: > Ok: Michael, according to all the above, if you think a change in dbus > is better, then please feel free to reassign this bug, adding > whatever additional explanation you consider it fits. Given that > you are already one of the dbus maintainers, I hope the reassign > will not be controversial. Simon already merged it and that way agreed with the change. I don't think this is super urgent and the normal severity reflects that. dbus will likely be uploaded at least once before freezing. Helmut
Bug#1085389: [Debian-pan-maintainers] Bug#1085389: python3-pyvkfft-cuda has an undeclared file conflict on /usr/lib/python3/dist-packages/pyvkfft/cuda.py
Hi Roland, On Sun, Oct 20, 2024 at 02:23:51PM +0200, Roland Mas wrote: > I think this is a false positive; I added a versioned "Depends: > python3-pyvkfft (>= 2024.1.4+ds1-2)" in the latest python3-pyvkfft-cuda in > response to the previous bug (#1085049) to fix this very problem. I'll keep > this bug open for now so as to not have it be re-created automatically, but > I'll lower its severity so as to not block migration to testing. I believe you are in error here and the filing is correct. The dependency requires a python3-pyvkfft with a suitable version to be configured before python3-pyvkfft-cuda can be configured. However, Depends (unlike Pre-Depends) does not impose any restrictions on unpacks. Therefore python3-pyvkfft-cuda may still be unpacked (but not configured) with an old version of python3-pyvkfft still being unpacked. In this situation, you may see an error from dpkg. This problem may even occur in a practical setting during upgrades. The package manager may choose to unpack python3-pyvkfft-cuda before unpacking the upgrade of python3-pyvkfft. > Should I file an issue in https://salsa.debian.org/helmutg/dumat/-/issues ? I don't think this is necessary given the above. Helmut
Bug#1085507: cmake: fails to recognize multiarch libdir for musl-linux-any
Package: cmake Version: 3.30.5-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap Control: affects -1 + src:libpng1.6 While bootstrapping Debian for musl-linux-any, I noticed that cmake fails to consider /usr/lib/$DEB_HOST_MULTIARCH during a build of libpng1.6. After some debugging, it became clear that it would only recognize multiarch directories for glibc based systems and eventually, I found the culprint in Linux-Initialize.cmake. I'm attaching a patch that makes cmake recognize the multiarch directories for all Linux systems rather than just GNU/Linux ones. Helmut --- cmake-3.30.5.orig/Modules/Platform/Linux-Initialize.cmake +++ cmake-3.30.5/Modules/Platform/Linux-Initialize.cmake @@ -2,4 +2,4 @@ set(LINUX 1) set(UNIX 1) # Match multiarch library directory names. -set(CMAKE_LIBRARY_ARCHITECTURE_REGEX "[a-z0-9_]+(-[a-z0-9_]+)?-linux-gnu[a-z0-9_]*") +set(CMAKE_LIBRARY_ARCHITECTURE_REGEX "[a-z0-9_]+(-[a-z0-9_]+)?-linux-[a-z0-9_]*")
Bug#1082178: Proceeding with removal of mldemos
Control: severity 1082178 normal Control: retitle 1082178 RM: mldemos -- RoQA; rc-buggy Control: reassign 1082178 ftp.debian.org Control: affects 1082178 + src:mldemos Dear mldemos maintainer and ftp team, a month has passed since filing a suggestion to remove mldemos from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated 2 long-standing RC bugs. * #915711: mldemos FTBFS against opencv 3.4.4 in experimental Last modified: 1 year, 4 months * #922585: FTBFS against opencv 4.0.1 (exp) Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082177: Proceeding with removal of vlogger
Control: severity 1082177 normal Control: retitle 1082177 RM: vlogger -- RoQA; rc-buggy Control: reassign 1082177 ftp.debian.org Control: affects 1082177 + src:vlogger Dear vlogger maintainer and ftp team, a month has passed since filing a suggestion to remove vlogger from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #965867: vlogger: Removal of obsolete debhelper compat 5 and 6 in bookworm Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082174: Proceeding with removal of php-net-ipv6
Control: severity 1082174 normal Control: retitle 1082174 RM: php-net-ipv6 -- RoQA; rc-buggy Control: reassign 1082174 ftp.debian.org Control: affects 1082174 + src:php-net-ipv6 Dear php-net-ipv6 maintainer and ftp team, a month has passed since filing a suggestion to remove php-net-ipv6 from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1004531: php-net-ipv6: PHP Fatal error: Array and string offset access syntax with curly braces is no longer supported Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082176: Proceeding with removal of pyfr
Control: severity 1082176 normal Control: retitle 1082176 RM: pyfr -- RoQA; rc-buggy Control: reassign 1082176 ftp.debian.org Control: affects 1082176 + src:pyfr Dear pyfr maintainer and ftp team, a month has passed since filing a suggestion to remove pyfr from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #997427: pyfr: FTBFS: Could not import extension tikz (exception: cannot import name 'ENOENT' from 'sphinx.util' (/usr/lib/python3/dist-packages/sphinx/util/__init__.py)) Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082175: Proceeding with removal of php-sabre-xml
Control: severity 1082175 normal Control: retitle 1082175 RM: php-sabre-xml -- RoQA; rc-buggy Control: reassign 1082175 ftp.debian.org Control: affects 1082175 + src:php-sabre-xml Dear php-sabre-xml maintainer and ftp team, a month has passed since filing a suggestion to remove php-sabre-xml from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #882949: php-sabre-xml FTBFS with phpunit 6.4.4-2 Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082170: Proceeding with removal of ruby-yaml-db
Control: severity 1082170 normal Control: retitle 1082170 RM: ruby-yaml-db -- RoQA; rc-buggy Control: reassign 1082170 ftp.debian.org Control: affects 1082170 + src:ruby-yaml-db Dear ruby-yaml-db maintainer and ftp team, a month has passed since filing a suggestion to remove ruby-yaml-db from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1019679: ruby-yaml-db: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082173: Proceeding with removal of node-node-forge
Control: severity 1082173 normal Control: retitle 1082173 RM: node-node-forge -- RoQA; rc-buggy Control: reassign 1082173 ftp.debian.org Control: affects 1082173 + src:node-node-forge Dear node-node-forge maintainer and ftp team, a month has passed since filing a suggestion to remove node-node-forge from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1002861: node-node-forge: FTBFS with webpack5: Error: Configuration object don't match the API schema Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082172: Proceeding with removal of lives
Control: severity 1082172 normal Control: retitle 1082172 RM: lives -- RoQA; rc-buggy Control: reassign 1082172 ftp.debian.org Control: affects 1082172 + src:lives Dear lives maintainer and ftp team, a month has passed since filing a suggestion to remove lives from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1013421: lives FTBFS with ffmpeg 5.0.1 Last modified: 1 year, 5 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1082169: Proceeding with removal of opengrm-ngram
Control: severity 1082169 normal Control: retitle 1082169 RM: opengrm-ngram -- RoQA; rc-buggy Control: reassign 1082169 ftp.debian.org Control: affects 1082169 + src:opengrm-ngram Dear opengrm-ngram maintainer and ftp team, a month has passed since filing a suggestion to remove opengrm-ngram from Debian. It was suggested for removal due to not being part of bookworm nor trixie and having accumulated a long-standing RC bug. * #1019172: opengrm-ngram FTBFS against libfst 1.7.9 Last modified: 1 year, 4 months Since the suggestion bug was neither closed nor tagged in a month, silent consent to proceed with removal is assumed. Kind regards A tool for automatically removing packages from unstable This bug reply has been automatically sent with little human intervention. If the filing is unclear or in error, don't hesitate to contact Helmut Grohne for assistance.
Bug#1085503: libapache-mod-musicindex FTCBFS: multiple configure issues
Source: libapache-mod-musicindex
Version: 1.4.1-3.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
libapache-mod-musicindex fails to cross build from source for multiple
reasons, all of which relate to its configure script.
It determines the apache version by running a compiled C program. This
of course does not work at all for cross building. Fortunately, what it
needs here is the value of the MODULE_MAGIC_COOKIE macro and
AC_COMPUTE_INT can determine that in a cross setting. It then uses
apr1-config, which does not work for cross compilation. I suggest adding
an alternate path that queries apr-1.pc using pkg-config. Likewise,
mysql_config does not work and querying mysqlclient.pc using pkg-config
works. The resulting patch is a bit lengthy, but should improve the
situation in a generic way also applicable to distributions other than
Debian.
Helmut
--- libapache-mod-musicindex-1.4.1.orig/configure.ac
+++ libapache-mod-musicindex-1.4.1/configure.ac
@@ -85,75 +85,46 @@
AC_SUBST(APXS_INCLUDE)
AC_MSG_CHECKING([for which version of Apache we should build])
-
-
ac_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS $APXS_INCLUDE"
-cat >conftest.$ac_ext <<_ACEOF
-#include
-#include
-
-int main(void)
-{
-#if (MODULE_MAGIC_COOKIE == 0x41503133UL)
- printf("AP13\n");
-#elif (MODULE_MAGIC_COOKIE == 0x41503230UL)
- printf("AP20\n");
-#elif (MODULE_MAGIC_COOKIE == 0x41503232UL)
- printf("AP22\n");
-#elif (MODULE_MAGIC_COOKIE == 0x41503234UL)
- printf("AP24\n");
-#endif
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- apache_version=`./conftest$ac_exeext`
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-ac_cv_lib_mad_mad_bit_init=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
+AC_COMPUTE_INT([apache_version_magic],[MODULE_MAGIC_COOKIE],[#include ])
CFLAGS=$ac_save_CFLAGS
-
+
+AC_MSG_RESULT([:$apache_version_magic:])
+case "$apache_version_magic" in
+ 1095774515)
+apache_version=AP13
+ ;;
+ 1095774768)
+apache_version=AP20
+AC_DEFINE([AP20], [], ["AP20"])
+ ;;
+ 1095774770)
+apache_version=AP22
+AC_DEFINE([AP22], [], ["AP22"])
+ ;;
+ 1095774772)
+apache_version=AP24
+AC_DEFINE([AP24], [], ["AP24"])
+ ;;
+esac
AC_MSG_RESULT([${apache_version}])
+PKG_CHECK_MODULES([APR],[apr-1],[
+ AC_DEFINE([BUILD_FOR_APACHE2], [], ["apache2"])
+ AM_CONDITIONAL(BUILD_FOR_APACHE2, true)
+ APR_INCLUDE=
+ AC_SUBST(APR_INCLUDE)
+ APR_CPPFLAGS=
+ AC_SUBST(APR_CPPFLAGS)
+],[
if test x$apache_version = xAP20; then
AC_CHECK_PROG(APR_CONFIG, apr-config, apr-config, [], [], [exit1])
- AC_DEFINE([AP20], [], ["AP20"])
fi
-if test x$apache_version = xAP22; then
- AC_CHECK_PROG(APR_CONFIG, apr-1-config, apr-1-config, [], [], [exit1])
- AC_DEFINE([AP22], [], ["AP22"])
-fi
-
-if test x$apache_version = xAP24; then
+if test x$apache_version = xAP22 || test x$apache_version = AP24; then
AC_CHECK_PROG(APR_CONFIG, apr-1-config, apr-1-config, [], [], [exit1])
- AC_DEFINE([AP24], [], ["AP24"])
fi
if test "x$APR_CONFIG" != "x"; then
@@ -173,6 +144,7 @@
else
AM_CONDITIONAL(BUILD_FOR_APACHE2, false)
fi
+])
# Checks for libraries.
##
@@ -306,16 +278,20 @@
##
-#check if the user has a prefered mysql_config tool. by default, use mysql_config
+#check if the user has a prefered mysql_config tool. by default, use pkg-config
AC_ARG_WITH([mysql_config],
AC_HELP_STRING([--with-mysql_config=ARG], [mysql_config executable]),
[MYSQL_CONFIG="${withval}"],
- [MYSQL_CONFIG="mysql_config"])
+ [MYSQL_CONFIG="pkg-config"])
+
+AS_IF([test "x$MYSQL_CONFIG" = xpkg-config],[
+ PKG_CHECK_MODULES([MYSQL],[mysqlclient],[],[MYSQL_CONFIG="mysql_config"])
+])
#check if the mysql_config tool actually exists
-if test x$MYSQL_CONFIG != xnone; then
+AS_IF([test "x$MYSQL_CONFIG" != xnone && test "x$MYSQL_CONFIG" != xpkg-config],[
AC_PATH_PROG([MYSQL_CONFIG], [$MYSQL_CONFIG], [], [$PATH:/usr/sbin:/usr/local/bin])
-fi
+])
AC_ARG_ENABLE([mysqlcache],
AC_HELP_STRING([--disable-mysqlc
Bug#1085108: postgresql-client-17: wrongly marked Multi-Arch: foreign
Hi Christoph, On Mon, Oct 14, 2024 at 10:09:56PM +0200, Christoph Berg wrote: > Re: Helmut Grohne > > The other way is moving this file into an architecture-dependent > > package. Given its reliance on pg_config, why is it not part of > > libpq-dev in the first place? Is moving it there an option? Do you > > happen to know what would break if the file were moved? > > pg_config used to be in postgresql-server-dev-NN, but since PG > extension autopkgtests need $(shell pg_config --pgxs), I moved > pg_config and pgxs.mk into postgresql-client-NN so the tests don't > pull in postgresql-server-dev-NN with its clang dependencies. Also, it > seemed to be a good move in general to have pg_config available in the > default install on PG servers. I note that postgresql-server-dev-NN was not M-A:foreign. So the move that you describe here is what caused the bug report at hand (while at the same time improving other aspects). > It can't go into libpq-dev because libpq-dev is independent from the > PG major version. (There *is* a pg_config in libpq-dev, but it gets > dpkg-diverted away by postgresql-common, i.e. on server installs.) Thanks for clarifying. > Perhaps we could throw a 3rd copy of pg_config into > postgresql-server-dev-NN (which isn't MA) and prefer that over the one > from postgresql-client-NN? At this time, I'm not sure what the solution is, but I am pretty sure that pg_config should not be part of any package that is marked Multi-Arch: foreign. In the perl world, we were faced with a problem that looks vaguely related to me. What we ended up doing there was adding a virtual package perl-xs-dev. Then, we gradually switched over all source packages building perl architecture-dependent perl extension modules to build-depend on this. The take-away here is that the functionality required for building extensions is now captured in a separate name and allows reorganizing the perl source without incurring subsequent changes to all perl extensions. The addition of a virtual package (that may become real later) also means that we can make the transition soft for downstreams: Add the provides to postgresql-client now, transition rdeps, then reorganize without disrupting many consumers. > How much does cross-compiling PG things work if you fix the compiler > flag bit? My last info was that there were more bits missing. If this > is the last one, I'll gladly work on a fix. As far as I understand it, pg_config is very architecture-dependent. It isn't just one aspect and we'd be done. To make matters worse, pg_config also is an ELF executable. Hence we have a choice between producing results for the wrong architecture (status quo) and not being able to run it at all. My main approach for improving cross building of postgres reverse dependencies has been patching out uses of pg_config in favour of pkg-config (where feasible), but pg_config --pgxs doesn't work at similar ease. I have no solution to offer here. So as unfortunate as this may be, pg_config technically poses a violation of Multi-Arch: foreign. It should not reside in a package marked M-A:foreign and fixing this bug will likely not improve cross building in any practical way (except maybe for making it fail faster). A vague option I see on the horizon would be changing the pgxs.mk Makefile to prefer use of pkgconf over using pg_config. Then, a user may set the PKG_CONFIG variable to determine the host architecture and then include pgxs.mk picking up values for the desired architecture. However, the present libpq.pc does not answer all the questions that pg_config answers now (e.g. --mandir), so we're looking at a deeper rabbit hole. Helmut
Bug#1085490: net-acct FTCBFS: builds for the build architecture
Source: net-acct Version: 0.71-10 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs net-acct fails to cross build from source, because it builds for the build architecture using a bare $(MAKE) invocation. Subsequently, dh_auto_build is used, but it skips all runes (using the correct compiler) as the outputs are all there already. Eventually, dh_strip fails. I suggest removing the duplicate build instruction relying solely on dh_auto_build. Helmut diff --minimal -Nru net-acct-0.71/debian/changelog net-acct-0.71/debian/changelog --- net-acct-0.71/debian/changelog 2024-09-22 21:07:08.0 +0200 +++ net-acct-0.71/debian/changelog 2024-10-19 20:50:36.0 +0200 @@ -1,3 +1,10 @@ +net-acct (0.71-10.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Build only once. Closes: #-1. + + -- Helmut Grohne Sat, 19 Oct 2024 20:50:36 +0200 + net-acct (0.71-10) unstable; urgency=medium * Team upload of Debian team diff --minimal -Nru net-acct-0.71/debian/rules net-acct-0.71/debian/rules --- net-acct-0.71/debian/rules 2024-09-22 21:07:08.0 +0200 +++ net-acct-0.71/debian/rules 2024-10-19 20:50:33.0 +0200 @@ -8,7 +8,6 @@ dh $@ override_dh_auto_build: - $(MAKE) -C src MASQ=-DREMAP_MASQUERADE dh_auto_build --sourcedirectory=src -- MASQ=-DREMAP_MASQUERADE cp src/naccttab.sample debian/naccttab
Bug#1085407: Fwd: Bug#1085407: base-files: please provide versioned usr-is-merged
On Sat, Oct 19, 2024 at 11:14:04PM +0200, Santiago Vila wrote: > I received this report from the BTS, related with the usr-merge stuff. Thank you for forwarding. > There is also an alternate proposal to fix the problem, by modifying > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085407#10 It is correct that base-files does not provide perform versioned Provides of usr-is-merged and that as a result the real usr-is-merged package cannot be removed in many configurations as a result of versioned dependencies. At the time adding the provides, I carefully considered whether versioned provides made sense. I observed that usr-is-merged contains a pile of Conflicts and that versioned Depends could be used to enforce those Conflicts without duplicating them into other packages. As a result, I considered that adding versioned Provides would require base-files to also copy those Conflicts. It is known that Conflicts in essential packages can have bad effects for upgrades, so I opted for not copying them and - as a result - not adding versioned Provides. At this time, usr-is-merged has two reverse dependencies. One is init-system-helpers (unversioned, it could arguably drop it) and the other is dbus (versioned). This hints that my line of reasoning may not have been aligned with reality well. It also is difficult to judge how this facility may have been used in derivatives. The proposed dbus change has two benefits over modifying base-files here. For one thing, it clarifies the intention of the versioned dependency with dbus maintainers. For another, it avoids the risk of silently dropping Conflicts. I therefore recommend continuing that way and looking back here if that avenue proves unsuccessful. I earlier noticed that the usr-is-merged package could not be removed from an installation containing dbus. Given all the other workarounds and hacks around, I considered the presence of the usr-is-merged package a cosmetic detail. Do note that many of the workarounds use the usr-is-merged package name for setting up protective diversions. As a result, keeping this package has the benefit of avoiding unintentional reuse. I considered that removal of it could be reasonably be deferred into the forky cycle. Let me also use this opportunity to again express thanks to Chris and Michael. Even though I am able to spend significant amounts of time on this transition thanks to Freexian, it is no longer the case that I am the main driver of this transition. Many others and Chris and Michael in particular have expended a lot of effort into it and we have handled many recent decisions as more of a team seeking consensus from one another. I would appreciate if you (Santiago) could extend your trust regarding base-files/usr-merge matters that you place in me (thank you) to Chris and Michael as I am trusting both of them. Helmut
