Your message dated Fri, 20 Jun 2025 06:45:36 +0200
with message-id <20250620044536.ga2591...@subdivi.de>
and subject line Re: Bug#1104092: libftdi1 reduce Build-Depends for 
architecture bootstrap
has caused the Debian Bug report #1104092,
regarding libftdi1 reduce Build-Depends for architecture bootstrap
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1104092: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104092
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: libftdi1
Version: 1.5-10
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Aurelien,

I learned that libftdi1 technically became part of the architecture
cross bootstrap set and that results in severe constraints about what it
can depend on. The root cause is the addition of libtss2-dev to gnupg's
Build-Depends from from libftdi1 via boost it goes really bad. Some
package will have to get a build profile.

As part of this, I've looked into libftdi1 and tried reducing its
dependencies. I see three main opportunities.
 * We can turn libboost-test-dev optional via <!nocheck>, but we retain
   libboost-dev for libftdipp.
 * We can make all that Python stuff optional via <!nopython> and that
   works really well, because py3vers returns an empty sequence when
   missing and that makes stuff mostly just work. The exception here is
   override_dh_auto_install-arch, because the last installed version
   "wins". To make things reproducible, the main build needs to be
   installed last.
 * Making libftdipp (and thus boost) optional is difficult, because the
   CMake files installed into libftdi1-dev contain information about
   libftdipp1-dev and that goes missing if you -DFTDIPP:BOOL=OFF, so
   it'd be unreproducible.

I'm attaching a patch for the first two items as those feel like fairly
direct improvements with little downsides. Would you agree to merge
them?

What I still needs is getting boost out of the cross bootstrap set. I'll
be looking into adding a profile to gnupg next, but I still appreciate
if you happen to see a way of reasonably building libftdi1 without
boost.

Helmut
diff --minimal -Nru libftdi1-1.5/debian/changelog libftdi1-1.5/debian/changelog
--- libftdi1-1.5/debian/changelog       2025-04-08 22:40:49.000000000 +0200
+++ libftdi1-1.5/debian/changelog       2025-04-23 21:21:26.000000000 +0200
@@ -1,3 +1,10 @@
+libftdi1 (1.5-10.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce build-depends via build profiles. (Closes: #-1)
+
+ -- Helmut Grohne <hel...@subdivi.de>  Wed, 23 Apr 2025 21:21:26 +0200
+
 libftdi1 (1.5-10) unstable; urgency=medium
 
   * Build documentation in a separate pass and move some Build-
diff --minimal -Nru libftdi1-1.5/debian/control libftdi1-1.5/debian/control
--- libftdi1-1.5/debian/control 2025-04-08 22:40:49.000000000 +0200
+++ libftdi1-1.5/debian/control 2025-04-23 21:21:26.000000000 +0200
@@ -3,13 +3,14 @@
 Priority: optional
 Maintainer: Aurelien Jarno <aure...@debian.org>
 Build-Depends: debhelper-compat (= 13), cmake, libusb-1.0-0-dev, pkgconf
-Build-Depends-Arch: dh-sequence-python3,
-                    libboost-test-dev,
+Build-Depends-Arch: dh-sequence-python3 <!nopython>,
+                    libboost-dev,
+                    libboost-test-dev <!nocheck>,
                     libconfuse-dev,
-                    libpython3-all-dev,
-                    python3-all:any,
-                    python3-setuptools,
-                    swig
+                    libpython3-all-dev <!nopython>,
+                    python3-all:any <!nopython>,
+                    python3-setuptools <!nopython>,
+                    swig <!nopython>,
 Build-Depends-Indep: doxygen
 Rules-Requires-Root: no
 Standards-Version: 4.7.2
@@ -101,6 +102,7 @@
 Package: python3-ftdi1
 Section: python
 Architecture: any
+Build-Profiles: <!nopython>
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Provides: ${python3:Provides}
 Description: Python module to control and program the FTDI USB controllers
diff --minimal -Nru libftdi1-1.5/debian/rules libftdi1-1.5/debian/rules
--- libftdi1-1.5/debian/rules   2025-04-08 22:40:49.000000000 +0200
+++ libftdi1-1.5/debian/rules   2025-04-23 21:21:26.000000000 +0200
@@ -11,7 +11,7 @@
 
 override_dh_auto_configure-arch:
        dh_auto_configure --builddirectory=build-main -- \
-               -DBUILD_TESTS=ON \
+               -DBUILD_TESTS=$(if $(filter nocheck,$(DEB_BUILD_OPTIONS) 
$(DEB_BUILD_PROFILES)),OFF,ON) \
                -DDOCUMENTATION:BOOL=OFF \
                -DEXAMPLES:BOOL=OFF \
                -DFTDIPP:BOOL=ON \
@@ -22,7 +22,7 @@
                        -DBUILD_TESTS=OFF \
                        -DDOCUMENTATION:BOOL=OFF \
                        -DEXAMPLES:BOOL=OFF \
-                       -DFTDIPP:BOOL=ON \
+                       -DFTDIPP:BOOL=OFF \
                        -DFTDI_EEPROM:BOOL=OFF \
                        -DPYTHON_BINDINGS:BOOL=ON \
                        -DLINK_PYTHON_LIBRARY:BOOL=OFF \
@@ -36,11 +36,11 @@
        done
 
 override_dh_auto_install-arch:
-       dh_auto_install --builddirectory=build-main
        for v in $(PY3VERS) ; do \
                dh_auto_install --builddirectory=build-python$$v -- 
CMAKE_INSTALL_ALWAYS=1; \
                mv $(CURDIR)/debian/tmp/usr/lib/python3 
$(CURDIR)/debian/tmp/usr/lib/python$$v ; \
        done
+       dh_auto_install --builddirectory=build-main
 
 override_dh_auto_test-arch:
        dh_auto_test --builddirectory=build-main

--- End Message ---
--- Begin Message ---
On Thu, Jun 19, 2025 at 10:53:16PM +0200, Aurelien Jarno wrote:
> The boost change will be in the next upstream release anyway (so for 
> forky), so I guess closing the bug as "not needed" is the best option. 
> It's always possible to reopen it later in case 

Closing for now.

Helmut

--- End Message ---

Reply via email to