Re: Debuild cant find upstream source for repackaged PPA
On 2020-03-18, at 13:49:29 -0400, Calum McConnell wrote:
> So, I was looking at repackaging Yannubuntu/boot-repair for Sid
> because when I first set up my debian dual-boot, I had to use to to
> actually dual boot. I followed the instructions in the wiki for
> repackaging PPA's, and added a new changelog entry (as well as
> changing the package to be a quilt instead of a native package: I
> tried both ways). I incremented the version to be 4ppa69-1 instead of
> 4ppa69, in case I needed to make further changes. However, when I
> tried to run debuild, I got the attached text file as the output.
>
> What is going on here? The upstream tarball clearly exists, but
> debuild doesnt see it?
> calum@CalumsDebianSupreme:~/package/boot-repair/boot-repair_4ppa69-1$ ls
> boot-repair_4ppa69.orig.tar.gz debian docs etc po usr
$ mv boot-repair_4ppa69.orig.tar.gz ..
> calum@CalumsDebianSupreme:~/package/boot-repair/boot-repair_4ppa69-1$ debuild
> This package has a Debian revision number but there does not seem to be
> an appropriate original tar file or .orig directory in the parent directory;
> (expected one of boot-repair_4ppa69.orig.tar.gz,
> boot-repair_4ppa69.orig.tar.bz2,
> boot-repair_4ppa69.orig.tar.lzma, boot-repair_4ppa69.orig.tar.xz or
> boot-repair_4ppa69-1.orig)
> continue anyway? (y/n) y
> dpkg-buildpackage -us -uc -ui
> dpkg-buildpackage: info: source package boot-repair
> dpkg-buildpackage: info: source version 4ppa69-1
> dpkg-buildpackage: info: source distribution UNRELEASED
> dpkg-buildpackage: info: source changed by Calum McConnell
>
> dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
> fakeroot debian/rules clean
> dh clean
>dh_clean
> dpkg-source -b .
> dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream
> tarball found at ../boot-repair_4ppa69.orig.tar.{bz2,gz,lzma,xz}
> dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 25
> debuild: fatal error at line 1182:
> dpkg-buildpackage -us -uc -ui failed
J.
signature.asc
Description: PGP signature
Re: Autoconf issue in mpqc
On 2020-04-05, at 08:18:30 +0200, Andreas Tille wrote: > while Nilesh has fixed the MPI-3.0 issue of mpqc in Git[1] the package > does not build any more due to an autoconf issue: > > ... > configure.in:1802: error: possibly undefined macro: AC_CHECK_CCA > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.in:1833: error: possibly undefined macro: AC_DEFINE_DIR > autoreconf: /usr/bin/autoconf failed with exit status: 1 > ... > > The macro AC_CHECK_CCA is defined in > >lib/autoconf/cca.m4 > > but it seems it is not found any more by recent autotools. > > Any help would be appreciated. > > Kind regards > > Andreas. > > [1] https://salsa.debian.org/debichem-team/mpqc Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch attached). J. diff --git a/configure.in b/configure.in index ee82977e4931..d615d3854a6c 100644 --- a/configure.in +++ b/configure.in @@ -9,6 +9,7 @@ AC_INIT(src/lib/util/ref/ref.h) AC_PREREQ(2.55) AC_CONFIG_HEADER(src/lib/scconfig.h) AC_CONFIG_AUX_DIR(bin) +AC_CONFIG_MACRO_DIR([lib/autoconf]) AC_CANONICAL_SYSTEM signature.asc Description: PGP signature
Re: Autoconf issue in mpqc
On 2020-04-05, at 12:45:47 +0200, Andreas Tille wrote: > Hi Jeremy, > > On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote: > > > Any help would be appreciated. > > > > > > [1] https://salsa.debian.org/debichem-team/mpqc > > > > Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it (patch > > attached). > > Thanks a lot for the promising patch I have commited to Git[1]. > Unfortunately the build does not yet succeed in a pbuilder chroot. > I've attached the part or the build log that seems to be autoconf > relevant. I admit I'm a bit astonished since I can only see > warnings but no error ... Here's a patch that fixes the autoheader warnings. autoreconf is still failing. J. > [...] > autoheader: warning: missing template: ALWAYS_USE_MPI > autoheader: Use AC_DEFINE([ALWAYS_USE_MPI], [], [Description]) > autoheader: warning: missing template: CXX_RESTRICT > autoheader: warning: missing template: DEFAULT_ARMCI > autoheader: warning: missing template: DEFAULT_MPI > autoheader: warning: missing template: DEFAULT_MTMPI > autoheader: warning: missing template: DEFAULT_SC_MEMORY > autoheader: warning: missing template: EXPLICIT_TEMPLATE_INSTANTIATION > autoheader: warning: missing template: HAVE_ARMCI > autoheader: warning: missing template: HAVE_BACKTRACE > autoheader: warning: missing template: HAVE_CCA_CHEM_HEADERS > autoheader: warning: missing template: HAVE_CCA_SPEC_BABEL_HEADERS > autoheader: warning: missing template: HAVE_FCHDIR > autoheader: warning: missing template: HAVE_IOS_FMTFLAGS > autoheader: warning: missing template: HAVE_ISNAN > autoheader: warning: missing template: HAVE_LIBDERIV > autoheader: warning: missing template: HAVE_LIBINT > autoheader: warning: missing template: HAVE_LIBR12 > autoheader: warning: missing template: HAVE_LONG_LONG > autoheader: warning: missing template: HAVE_MPI > autoheader: warning: missing template: HAVE_MPIIO > autoheader: warning: missing template: HAVE_MPIPP > autoheader: warning: missing template: HAVE_MPI_INIT_THREAD > autoheader: warning: missing template: HAVE_NIAMA > autoheader: warning: missing template: HAVE_PERF > autoheader: warning: missing template: HAVE_PTHREAD > autoheader: warning: missing template: HAVE_PUBSEEKOFF > autoheader: warning: missing template: HAVE_SCALABLE_BLAS > autoheader: warning: missing template: HAVE_SEEKOFF > autoheader: warning: missing template: HAVE_SGETN > autoheader: warning: missing template: HAVE_SIDL_HEADERS > autoheader: warning: missing template: HAVE_SYSV_IPC > autoheader: warning: missing template: HAVE_TYPENAME > autoheader: warning: missing template: HOST_ARCH > autoheader: warning: missing template: INSTALLED_SCLIBDIR > autoheader: warning: missing template: REF_OPTIMIZE > autoheader: warning: missing template: SCDATADIR > autoheader: warning: missing template: SC_BUILDID > autoheader: warning: missing template: SC_MAJOR_VERSION > autoheader: warning: missing template: SC_MICRO_VERSION > autoheader: warning: missing template: SC_MINOR_VERSION > autoheader: warning: missing template: SC_MPI_THREAD_LEVEL > autoheader: warning: missing template: SC_VERSION > autoheader: warning: missing template: SEMCTL_REQUIRES_SEMUN > autoheader: warning: missing template: SIGHASELLIP > autoheader: warning: missing template: SRC_SCLIBDIR > autoheader: warning: missing template: TARGET_ARCH > autoheader: warning: missing template: USING_NAMESPACE_STD > autoheader: warning: missing template: WORDS_BIGENDIAN > autoreconf: /usr/bin/autoheader failed with exit status: 1 > [...] diff --git a/configure.in b/configure.in index ee82977e4931..5a77f343331e 100644 --- a/configure.in +++ b/configure.in @@ -9,7 +9,9 @@ AC_INIT(src/lib/util/ref/ref.h) AC_PREREQ(2.55) AC_CONFIG_HEADER(src/lib/scconfig.h) AC_CONFIG_AUX_DIR(bin) AC_CONFIG_MACRO_DIR([lib/autoconf]) + +AC_DEFINE_HEADER_TEMPLATES AC_CANONICAL_SYSTEM diff --git a/lib/autoconf/templates.m4 b/lib/autoconf/templates.m4 new file mode 100644 index ..693d54289326 --- /dev/null +++ b/lib/autoconf/templates.m4 @@ -0,0 +1,50 @@ +AC_DEFUN([AC_DEFINE_HEADER_TEMPLATES],[ +AH_TEMPLATE([ALWAYS_USE_MPI], []) +AH_TEMPLATE([CXX_RESTRICT], []) +AH_TEMPLATE([DEFAULT_ARMCI], []) +AH_TEMPLATE([DEFAULT_MPI], []) +AH_TEMPLATE([DEFAULT_MTMPI], []) +AH_TEMPLATE([DEFAULT_SC_MEMORY], []) +AH_TEMPLATE([EXPLICIT_TEMPLATE_INSTANTIATION], []) +AH_TEMPLATE([HAVE_ARMCI], []) +AH_TEMPLATE([HAVE_BACKTRACE], []) +AH_TEMPLATE([HAVE_CCA_CHEM_HEADERS], []) +AH_TEMPLATE([HAVE_CCA_SPEC_BABEL_HEADERS], []) +AH_TEMPLATE([HAVE_FCHDIR], []) +AH_TEMPLATE([HAVE_IOS_FMTFLAGS], []) +AH_TEMPLATE([HAVE_ISNAN], []) +AH_TEMPLATE([HAVE_LIBDERIV], []) +AH_TEMPLATE([HAVE_LIBINT], []) +AH_TEMPLATE([HAVE_LIBR12], []) +AH_TEMPLATE([HAVE_LONG_LONG],
Re: Autoconf issue in mpqc
On 2020-04-05, at 12:13:45 +0100, Jeremy Sowden wrote: > On 2020-04-05, at 12:45:47 +0200, Andreas Tille wrote: > > On Sun, Apr 05, 2020 at 10:14:58AM +0100, Jeremy Sowden wrote: > > > > Any help would be appreciated. > > > > > > > > [1] https://salsa.debian.org/debichem-team/mpqc > > > > > > Adding AC_CONFIG_MACRO_DIR to configure.in appears to fix it > > > (patch attached). > > > > Thanks a lot for the promising patch I have commited to Git[1]. > > Unfortunately the build does not yet succeed in a pbuilder chroot. > > I've attached the part or the build log that seems to be autoconf > > relevant. I admit I'm a bit astonished since I can only see > > warnings but no error ... > > Here's a patch that fixes the autoheader warnings. Whoops. That version doesn't seem to apply. The patch I've attached to this message I have actually tested properly. > autoreconf is still failing. That's not quite right: "autoreconf" fails, but "autoreconf -f -i" (which is what dh_autoreconf does) succeeds. Now dh_auto_configure fails. J. diff --git a/debian/patches/autoheader.patch b/debian/patches/autoheader.patch new file mode 100644 index ..f00d772e29ef --- /dev/null +++ b/debian/patches/autoheader.patch @@ -0,0 +1,69 @@ +diff --git a/configure.in b/configure.in +index 99a09d38b3c2..c183ac3ef252 100644 +--- a/configure.in b/configure.in +@@ -11,6 +11,8 @@ AC_CONFIG_HEADER(src/lib/scconfig.h) + AC_CONFIG_AUX_DIR(bin) + AC_CONFIG_MACRO_DIR([lib/autoconf]) + ++AC_DEFINE_HEADER_TEMPLATES ++ + AC_CANONICAL_SYSTEM + + AC_DEFINE_UNQUOTED(HOST_ARCH, "$host") +diff --git a/lib/autoconf/templates.m4 b/lib/autoconf/templates.m4 +new file mode 100644 +index ..693d54289326 +--- /dev/null b/lib/autoconf/templates.m4 +@@ -0,0 +1,50 @@ ++AC_DEFUN([AC_DEFINE_HEADER_TEMPLATES],[ ++AH_TEMPLATE([ALWAYS_USE_MPI], []) ++AH_TEMPLATE([CXX_RESTRICT], []) ++AH_TEMPLATE([DEFAULT_ARMCI], []) ++AH_TEMPLATE([DEFAULT_MPI], []) ++AH_TEMPLATE([DEFAULT_MTMPI], []) ++AH_TEMPLATE([DEFAULT_SC_MEMORY], []) ++AH_TEMPLATE([EXPLICIT_TEMPLATE_INSTANTIATION], []) ++AH_TEMPLATE([HAVE_ARMCI], []) ++AH_TEMPLATE([HAVE_BACKTRACE], []) ++AH_TEMPLATE([HAVE_CCA_CHEM_HEADERS], []) ++AH_TEMPLATE([HAVE_CCA_SPEC_BABEL_HEADERS], []) ++AH_TEMPLATE([HAVE_FCHDIR], []) ++AH_TEMPLATE([HAVE_IOS_FMTFLAGS], []) ++AH_TEMPLATE([HAVE_ISNAN], []) ++AH_TEMPLATE([HAVE_LIBDERIV], []) ++AH_TEMPLATE([HAVE_LIBINT], []) ++AH_TEMPLATE([HAVE_LIBR12], []) ++AH_TEMPLATE([HAVE_LONG_LONG], []) ++AH_TEMPLATE([HAVE_MPI], []) ++AH_TEMPLATE([HAVE_MPIIO], []) ++AH_TEMPLATE([HAVE_MPIPP], []) ++AH_TEMPLATE([HAVE_MPI_INIT_THREAD], []) ++AH_TEMPLATE([HAVE_NIAMA], []) ++AH_TEMPLATE([HAVE_PERF], []) ++AH_TEMPLATE([HAVE_PTHREAD], []) ++AH_TEMPLATE([HAVE_PUBSEEKOFF], []) ++AH_TEMPLATE([HAVE_SCALABLE_BLAS], []) ++AH_TEMPLATE([HAVE_SEEKOFF], []) ++AH_TEMPLATE([HAVE_SGETN], []) ++AH_TEMPLATE([HAVE_SIDL_HEADERS], []) ++AH_TEMPLATE([HAVE_SYSV_IPC], []) ++AH_TEMPLATE([HAVE_TYPENAME], []) ++AH_TEMPLATE([HOST_ARCH], []) ++AH_TEMPLATE([INSTALLED_SCLIBDIR], []) ++AH_TEMPLATE([REF_OPTIMIZE], []) ++AH_TEMPLATE([SCDATADIR], []) ++AH_TEMPLATE([SC_BUILDID], []) ++AH_TEMPLATE([SC_MAJOR_VERSION], []) ++AH_TEMPLATE([SC_MICRO_VERSION], []) ++AH_TEMPLATE([SC_MINOR_VERSION], []) ++AH_TEMPLATE([SC_MPI_THREAD_LEVEL], []) ++AH_TEMPLATE([SC_VERSION], []) ++AH_TEMPLATE([SEMCTL_REQUIRES_SEMUN], []) ++AH_TEMPLATE([SIGHASELLIP], []) ++AH_TEMPLATE([SRC_SCLIBDIR], []) ++AH_TEMPLATE([TARGET_ARCH], []) ++AH_TEMPLATE([USING_NAMESPACE_STD], []) ++AH_TEMPLATE([WORDS_BIGENDIAN], []) ++]) diff --git a/debian/patches/series b/debian/patches/series index d700ae497e80..db79d4fb8ff5 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -11,3 +11,4 @@ g++6-constexpr.patch Fix_mpi.patch autoconf.patch +autoheader.patch signature.asc Description: PGP signature
Re: Autoconf issue in mpqc
On 2020-04-05, at 14:32:16 +0200, Andreas Tille wrote: > On Sun, Apr 05, 2020 at 12:34:55PM +0100, Jeremy Sowden wrote: > > > > I've attached the part or the build log that seems to be > > > > autoconf relevant. I admit I'm a bit astonished since I can > > > > only see warnings but no error ... > > > > > > Here's a patch that fixes the autoheader warnings. > > > > Whoops. That version doesn't seem to apply. The patch I've > > attached to this message I have actually tested properly. > > > > > autoreconf is still failing. > > > > That's not quite right: "autoreconf" fails, but "autoreconf -f -i" > > (which is what dh_autoreconf does) succeeds. Now dh_auto_configure > > fails. > > I confirm it fails with > > ... > checking if semctl requires semun... no > checking if fortran compiler works... no > configure: error: in `/build/mpqc-2.3.1': > configure: error: fortran compiler does not work > > > I've updated Git with your patch - thanks a lot so far. In my case, the problem was: ./configure: line 4287: mpicc: command not found IOW, missing build-deps. Once I installed those, dh_auto_configure was happy, but there were compilation failures because autoheader clobbered src/lib/scconfig.h.in. I've attached two patches which fix those. J. From 179ea7ad88afe65c49976fe713e7e061692d51cf Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 5 Apr 2020 20:22:51 +0100 Subject: [PATCH 1/2] shmtype fix. --- debian/patches/series| 1 + debian/patches/shmtype.patch | 45 2 files changed, 46 insertions(+) create mode 100644 debian/patches/shmtype.patch diff --git a/debian/patches/series b/debian/patches/series index db79d4fb8ff5..c5ef93ff27ed 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -12,3 +12,4 @@ g++6-constexpr.patch Fix_mpi.patch autoconf.patch autoheader.patch +shmtype.patch diff --git a/debian/patches/shmtype.patch b/debian/patches/shmtype.patch new file mode 100644 index ..0a8273be680a --- /dev/null +++ b/debian/patches/shmtype.patch @@ -0,0 +1,45 @@ +diff --git a/src/lib/scconfig.h.in b/src/lib/scconfig.h.in +index 81510ae39834..8ca70c95073d 100644 +--- a/src/lib/scconfig.h.in b/src/lib/scconfig.h.in +@@ -156,10 +156,6 @@ + /* Define to the type used for shared memory. */ + /* #undef SHMTYPE */ + +-#ifndef SHMTYPE +-#define SHMTYPE char* +-#endif +- + /* Define if you have the header file. */ + #undef HAVE_FCNTL_H + +diff --git a/src/lib/util/group/memshm.cc b/src/lib/util/group/memshm.cc +index 91964682b7f0..1314e43f01ec 100644 +--- a/src/lib/util/group/memshm.cc b/src/lib/util/group/memshm.cc +@@ -41,6 +41,10 @@ + using namespace std; + using namespace sc; + ++#ifndef SHMTYPE ++#define SHMTYPE char* ++#endif ++ + #ifndef SHMMAX + // glibc 2.0.3 isn't defining SHMMAX so make set it here + # ifdef __linux__ +diff --git a/src/lib/util/group/messshm.cc b/src/lib/util/group/messshm.cc +index f07fe1a79fde..34ee31e1ddbf 100644 +--- a/src/lib/util/group/messshm.cc b/src/lib/util/group/messshm.cc +@@ -40,6 +40,10 @@ + using namespace std; + using namespace sc; + ++#ifndef SHMTYPE ++#define SHMTYPE char* ++#endif ++ + //#define DEBUG + + #ifndef SEM_A -- 2.25.1 From 4d6bd8fc829d385bc05d696780429a03d915b18f Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 5 Apr 2020 20:58:57 +0100 Subject: [PATCH 2/2] restrictxx fix. --- debian/patches/restrictxx.patch | 102 debian/patches/series | 1 + 2 files changed, 103 insertions(+) create mode 100644 debian/patches/restrictxx.patch diff --git a/debian/patches/restrictxx.patch b/debian/patches/restrictxx.patch new file mode 100644 index ..e86d7d1a95e3 --- /dev/null +++ b/debian/patches/restrictxx.patch @@ -0,0 +1,102 @@ +diff --git a/src/lib/scconfig.h.in b/src/lib/scconfig.h.in +index 81510ae39834..3eaea90920ab 100644 +--- a/src/lib/scconfig.h.in b/src/lib/scconfig.h.in +@@ -14,12 +14,6 @@ + /* Define if the C++ restrict keyword extension exists. */ + #undef CXX_RESTRICT + +-#ifdef CXX_RESTRICT +-#define restrictxx restrict +-#else +-#define restrictxx +-#endif +- + #endif + + /* Define if you want to optimize the reference counting code. */ +diff --git a/src/lib/chemistry/qc/intv3/build2e.cc b/src/lib/chemistry/qc/intv3/build2e.cc +index 1179f9dcb6d2..fec356986d33 100644 +--- a/src/lib/chemistry/qc/intv3/build2e.cc b/src/lib/chemistry/qc/intv3/build2e.cc +@@ -36,6 +36,12 @@ + #include + #include + ++#ifdef CXX_RESTRICT ++#define restrictxx restrict ++#else ++#define restrictxx ++#endif ++ + using namespace std; + using namespace sc; + +diff --git a/src/lib/chemistry/qc/intv3/shift2e.cc b/src/lib/chemistry/qc/intv3/shift2e.cc +index 97d9f24df6a0..5a01bff73
Re: [covid-19] Help with r-bioc-rgadem needed
On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote: > since I did not got any response from r-pkg team yet I guess nobody > has a clue about this autoconf issue. So I'd like to forward this > question here to finalise a package which is relevant for our COVID-19 > Biohackathon. > > I injected r-bioc-rgadem[1] but the build ends in: > >dh_autoreconf -O--buildsystem=R > autoheader: warning: missing template: HAVE_OPENMP > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description]) > autoreconf: /usr/bin/autoheader failed with exit status: 1 > dh_autoreconf: error: autoreconf -f -i returned exit code 1 > make: *** [debian/rules:4: binary] Error 25 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 > > > Any hint would be welcome Similar to some of the problems with mpqc yesterday. Patch attached. J. diff --git a/configure.ac b/configure.ac index 0b7e8d793a31..aef047400685 100755 --- a/configure.ac +++ b/configure.ac @@ -39,6 +39,7 @@ Use --disable-parallel (or ARG=no) to keep the code sequential even if GCD or Op # As recommended by Simon Urbanek on R-Devel AC_DEFUN([AC_CHECK_PKG_OPENMP], [dnl +AH_TEMPLATE([HAVE_OPENMP],[]) AC_MSG_CHECKING([whether OpenMP will work in a package]) ac_pkg_openmp=no AS_IF( signature.asc Description: PGP signature
Re: [covid-19] Autoconf solved but now there is a C issue (Was: Help with r-bioc-rgadem needed)
On 2020-04-06, at 20:32:12 +0200, Andreas Tille wrote:
> Hi Jeremy,
>
> On Mon, Apr 06, 2020 at 05:34:23PM +0100, Jeremy Sowden wrote:
> > On 2020-04-06, at 17:59:05 +0200, Andreas Tille wrote:
> > >dh_autoreconf -O--buildsystem=R
> > > autoheader: warning: missing template: HAVE_OPENMP
> > > autoheader: Use AC_DEFINE([HAVE_OPENMP], [], [Description])
> > > autoreconf: /usr/bin/autoheader failed with exit status: 1
> > > dh_autoreconf: error: autoreconf -f -i returned exit code 1
> > > make: *** [debian/rules:4: binary] Error 25
> > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit
> > > status 2
> >
> > Similar to some of the problems with mpqc yesterday. Patch attached.
>
> Thanks a lot for your patch (commited to Git[1]) which solved the
> autoconf issue. Unfortunately there is another issue now:
>
>
> ecking for stdint.h... yes
> checking for unistd.h... yes
> checking dispatch/dispatch.h usability... no
> checking dispatch/dispatch.h presence... no
> checking for dispatch/dispatch.h... no
> checking whether OpenMP will work in a package... yes
> configure: creating ./config.status
> config.status: creating src/Makevars
> config.status: creating src/config.h
> ** libs
> make[1]: Entering directory '/build/r-bioc-rgadem-2.34.1/src'
> gcc -std=gnu99 -I"/usr/share/R/include" -DNDEBUG-fopenmp -fpic -g -O2
> -fdebug-prefix-map=/build/r-base-j1tBvV/r-base-3.6.3=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -g -c Gadem_Analysis.c -o Gadem_Analysis.o
> Gadem_Analysis.c: In function 'GADEM_Analysis':
> Gadem_Analysis.c:618:7: warning: implicit declaration of function 'DO_APPLY'
> [-Wimplicit-function-declaration]
> 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
> | ^~~~
> Gadem_Analysis.c:618:16: error: invalid use of void expression
> 618 | DO_APPLY(populationCalculation(maxSeqLen, numEM, fitness+ii,
> |^~~
> 619 | startPWMfound, minminSites,
> maxpFactor[ii],
> |
> ~~~
> 620 | numSeq, numSeqEM, seq, rseq,
> seqLen, Iseq,
> |
> ~~
> 621 | bfreq0, posWeight, weightType,
> | ~~
> 622 | pvalueCutoff, emSeqLen,
> | ~~~
> 623 | pwm[ii], pwmLen[ii], epwm[ii],
> opwm[ii],
> |
>
> 624 | pwmConsensus[ii],
> scoreCutoff+ii, sdyad[ii], ii),
> |
>
> make[1]: *** [/usr/lib/R/etc/Makeconf:168: Gadem_Analysis.o] Error 1
>
>
> Thanks a lot for your help anyway
Patch attached.
J.
From d3b5c1358bcf8463719c0175d759f74819e74f8e Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Mon, 6 Apr 2020 20:41:54 +0100
Subject: [PATCH] The definition of DO_APPLY in src/config.h.in is clobbered by
autoheader, so add it in Gadem_Analysis.c where it is used.
---
src/Gadem_Analysis.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/Gadem_Analysis.c b/src/Gadem_Analysis.c
index a604afeb0479..0e868b56918a 100755
--- a/src/Gadem_Analysis.c
+++ b/src/Gadem_Analysis.c
@@ -25,6 +25,32 @@
#include "config.h"
+#ifdef HAVE_DISPATCH_DISPATCH_H
+ #include
+ #define DO_APPLY(task, n_times, counter_name) \
+R_CheckUserInterrupt(); \
+dispatch_apply(n_times, \
+ dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), \
+ ^(size_t counter_name) { task; });
+
+#else // not HAVE_DISPATCH_DISPATCH_H
+ #ifdef HAVE_OPENMP
+#include
+#define DO_APPLY(task, n_times, counter_name) \
+ R_CheckUserInterrupt(); \
+ _Pragma("omp parallel for") \
+ for (int counter_name = 0; counter_name < n_times; ++counter_name) { \
+task; \
+ }
+ #else // not HAVE_OPENMP
+#define DO_APPLY(task, n_times, counter_name) \
+ for (int counter_name = 0; counter_name < n_times; ++counter_name) { \
+R_CheckUserInterrupt(); \
+task; \
+ }
+ #endif // HAVE_OPENMP
+#endif // HAVE_DISPATCH_DISPATCH_H
+
/*---
// v1.3.1: last modifications 5/14/2011
// added user-input background model
--
2.25.1
signature.asc
Description: PGP signature
Re: Autoconf issue in mpqc
On 2020-04-05, at 22:38:39 +0100, Jeremy Sowden wrote: > On 2020-04-05, at 14:32:16 +0200, Andreas Tille wrote: > > On Sun, Apr 05, 2020 at 12:34:55PM +0100, Jeremy Sowden wrote: > > > > > I've attached the part or the build log that seems to be > > > > > autoconf relevant. I admit I'm a bit astonished since I can > > > > > only see warnings but no error ... > > > > > > > > Here's a patch that fixes the autoheader warnings. > > > > > > Whoops. That version doesn't seem to apply. The patch I've > > > attached to this message I have actually tested properly. > > > > > > > autoreconf is still failing. > > > > > > That's not quite right: "autoreconf" fails, but "autoreconf -f > > > -i" (which is what dh_autoreconf does) succeeds. Now > > > dh_auto_configure fails. > > > > I confirm it fails with > > > > ... > > checking if semctl requires semun... no > > checking if fortran compiler works... no > > configure: error: in `/build/mpqc-2.3.1': > > configure: error: fortran compiler does not work > > > > > > I've updated Git with your patch - thanks a lot so far. > > In my case, the problem was: > > ./configure: line 4287: mpicc: command not found > > IOW, missing build-deps. Once I installed those, dh_auto_configure > was happy, but there were compilation failures because autoheader > clobbered src/lib/scconfig.h.in. I've attached two patches which fix > those. Having re-read the autoconf and autoheader doc's this evening, I think the attached fixes are an improvement over yesterday's. J. From cb556d820337b9e2b24cdc70049e9bca1967c7af Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 5 Apr 2020 20:22:51 +0100 Subject: [PATCH v2 1/2] shmtype fix. --- debian/patches/series| 1 + debian/patches/shmtype.patch | 21 + 2 files changed, 22 insertions(+) create mode 100644 debian/patches/shmtype.patch diff --git a/debian/patches/series b/debian/patches/series index db79d4fb8ff5..c5ef93ff27ed 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -12,3 +12,4 @@ g++6-constexpr.patch Fix_mpi.patch autoconf.patch autoheader.patch +shmtype.patch diff --git a/debian/patches/shmtype.patch b/debian/patches/shmtype.patch new file mode 100644 index ..273b16a9dec6 --- /dev/null +++ b/debian/patches/shmtype.patch @@ -0,0 +1,21 @@ +diff --git a/configure.in b/configure.in +index 8ebd2fa89c95..96e7fb7039da 100644 +--- a/configure.in b/configure.in +@@ -8,6 +8,7 @@ define([AC_CACHE_SAVE], )dnl for debugging configure.in + AC_INIT(src/lib/util/ref/ref.h) + AC_PREREQ(2.55) + AC_CONFIG_HEADER(src/lib/scconfig.h) ++AH_BOTTOM([#include "shm_type.h"]) + AC_CONFIG_AUX_DIR(bin) + AC_CONFIG_MACRO_DIR([lib/autoconf]) + +diff --git a/src/lib/shm_type.h b/src/lib/shm_type.h +new file mode 100644 +index ..8c62fb392b34 +--- /dev/null b/src/lib/shm_type.h +@@ -0,0 +1,3 @@ ++#ifndef SHMTYPE ++#define SHMTYPE char* ++#endif -- 2.25.1 From 758970c9d0b5928b60b000acd3485cc666827591 Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 5 Apr 2020 20:58:57 +0100 Subject: [PATCH v2 2/2] restrictxx fix. --- debian/patches/restrictxx.patch | 27 +++ debian/patches/series | 1 + 2 files changed, 28 insertions(+) create mode 100644 debian/patches/restrictxx.patch diff --git a/debian/patches/restrictxx.patch b/debian/patches/restrictxx.patch new file mode 100644 index ..3730918e8701 --- /dev/null +++ b/debian/patches/restrictxx.patch @@ -0,0 +1,27 @@ +diff --git a/configure.in b/configure.in +index 96e7fb7039da..040b475941c7 100644 +--- a/configure.in b/configure.in +@@ -8,7 +8,10 @@ define([AC_CACHE_SAVE], )dnl for debugging configure.in + AC_INIT(src/lib/util/ref/ref.h) + AC_PREREQ(2.55) + AC_CONFIG_HEADER(src/lib/scconfig.h) +-AH_BOTTOM([#include "shm_type.h"]) ++AH_BOTTOM([ ++#include "shm_type.h" ++#include "restrictxx.h" ++]) + AC_CONFIG_AUX_DIR(bin) + AC_CONFIG_MACRO_DIR([lib/autoconf]) + +diff --git a/src/lib/restrictxx.h b/src/lib/restrictxx.h +new file mode 100644 +index ..cacfea3b7db5 +--- /dev/null b/src/lib/restrictxx.h +@@ -0,0 +1,5 @@ ++#ifdef CXX_RESTRICT ++#define restrictxx restrict ++#else ++#define restrictxx ++#endif diff --git a/debian/patches/series b/debian/patches/series index c5ef93ff27ed..9662a2c679b6 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -13,3 +13,4 @@ Fix_mpi.patch autoconf.patch autoheader.patch shmtype.patch +restrictxx.patch -- 2.25.1 signature.asc Description: PGP signature
Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")
On 2023-08-25, at 18:29:34 +0200, Niels Thykier wrote: > Nilesh Patra: > > On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote: > > > [...] > > > > I had figured out this already, but conffile.lex.c does not exist in the > > project, it is generated as a part of the lexer output. In particular: > > > > Ok, apologies it was not clear to me from your opening email, where you were > stuck. I incorrectly assumed it was an an earlier stage than you are, so my > input was not useful to you. > > I checked the source of `conffile.l` and it need already has to runes to > include config.h where I would have assumed you needed to > (https://salsa.debian.org/med-team/eegdev/-/blob/master/src/core/conffile.l#L24). > > A bit of searching found the following flex upstream bug: > > * https://github.com/westes/flex/issues/564 > > Which seems related. Hopefully, it can help you. Another possibility would be just not to use gnulib. Debian is a GNU system, so it shouldn't be needed. If one removes the dh_autoreconf override and just lets dh_autoreconf do its thing, the package builds successfully. J. signature.asc Description: PGP signature
Bug#1067028: RFS: emacs-buttercup/1.34-1 [Team] -- behaviour-driven testing for Emacs Lisp packages
On 2024-03-16, at 23:38:58 -0700, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "emacs-buttercup": > > * Package name : emacs-buttercup >Version : 1.34-1 >Upstream contact : [fill in name and email of upstream] > * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > * License : GFDL-1.2+ or CC-BY-SA-3.0, GPL-3+ > * Vcs : https://salsa.debian.org/emacsen-team/emacs-buttercup >Section : lisp > > The source builds the following binary packages: > > elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/emacs-buttercup/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.34-1.dsc > > Changes since the last upload: > > emacs-buttercup (1.34-1) unstable; urgency=medium > . >* Team upload >* New upstream release >* Migrate to debhelper-compat version 13 LGTM. Will upload shortly. J. signature.asc Description: PGP signature
Bug#1066033: RFS: galvani/0.34-1 [ITP] -- reads data from a device with graphical plots and evaluation
On 2024-03-26, at 17:20:10 +0100, Dr. Burkard Lutz wrote: > Am Samstag, dem 16.03.2024 um 11:06 +0100 schrieb Bastian Germann: > > On Mon, 11 Mar 2024 14:20:25 +0100 "Dr. Burkard Lutz" > > wrote: > > > Changes for the initial release: > > > > > > galvani (0.34-1) unstable; urgency=medium > > > . > > > * Initial release. > > > > You are not referring to any ITP. Please file one on the wnpp pseudo > > package. > > > > > > > > My /debian/rules contains: > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > > > Nevertheless I always get the lintian error "hardening-no-fortify- > > > functions" > > > How can I fix that? > > > > By making sure that LDFLAGS, CPPFLAGS and CFLAGS set by dpkg are used > > in to your build. > > > I uploaded a new version to mentors.debian.net/package/galvani. > Changes since the last upload: > - ITP (wnpp): (Closes: #1067096) > - debian/upstream: added sining-key-asc > - debian/upstream/metadata: added repository: > https://gitlab.com/b.lutz1/galvani > - debian/control: added homepage field > - new debian/copyright > - new debian/watch > - debian/rules: added dpkg-buildflags > > I tried to fix the linitan error "hardening-no-fortify-functions" > I'm using anjuta as IDE. In the project options I added CFLAGS, > CPPFLAGS, CXXFLAGS and LDFLAGS (output of dpkg-buildflags). > My debian/rules is now: > --- > #!/usr/bin/make -f > > LDFLAGS :=$(shell dpkg-buildflags --get LDFLAGS) > > export DH_VERBOSE = 1 > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic > > export DEB_LDFLAGS_MAINT_APPEND = -lstdc++fs > > DPKG_EXPORT_BUILDFLAGS = 1 > include /usr/share/dpkg/buildflags.mk > CFLAGS += $(CPPFLAGS) > > %: > dh $@ --with autoreconf > > But I got still the same linitan error. > What is wrong and what can I do to fix the error? The following should suffice: export DH_VERBOSE = 1 export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_LDFLAGS_MAINT_APPEND = -lstdc++fs %: dh $@ --with autoreconf Running the build one can see: g++ [...] -D_FORTIFY_SOURCE=2 [...] so the right argument is being passed to the compiler. There is a list of the functions that are fortified here: https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html Does the software use any of these? If not, this is a false positive. J. signature.asc Description: PGP signature
Bug#1066033: RFS: galvani/0.34-1 [ITP] -- reads data from a device with graphical plots and evaluation
On 2024-03-27, at 10:48:45 +0100, Dr. Burkard Lutz wrote:
> Am Dienstag, dem 26.03.2024 um 17:03 + schrieb Jeremy Sowden:
> > [...]
> >
> > The following should suffice:
> >
> > export DH_VERBOSE = 1
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> > export DEB_LDFLAGS_MAINT_APPEND = -lstdc++fs
> >
> > %:
> > dh $@ --with autoreconf
> >
>
> So, this is exactly what I had initially.
>
> > Running the build one can see:
> >
> > g++ [...] -D_FORTIFY_SOURCE=2 [...]
> >
> > so the right argument is being passed to the compiler.
> > There is a list
> > of the functions that are fortified here:
> >
> >
> > https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html
> >
> > Does the software use any of these? If not, this is a false
> > positive.
> >
> > J.
>
> Galvani only uses "open" for file operations and "read" to read from
> usb devices.
>
> I'm a bit confused now. The output of "blhc galvani_0.34-1_amd64.build"
> is empty, but "hardening-check -vR /usr/bin/galvani" gives:
>
> /usr/bin/galvani:
> Position Independent Executable: yes
> Stack protected: yes
> Fortify Source functions: no, only unprotected functions found!
> unprotected: read
> unprotected: memcpy
> unprotected: readlink
> unprotected: vsnprintf
> unprotected: memset
> unprotected: memmove
> unprotected: realpath
> unprotected: getcwd
> Read-only relocations: yes
> Immediate binding: yes
> Stack clash protection: unknown, no -fstack-clash-protection
> instructions found
> Control flow integrity: no, not found!
> --
> followed by a long list.
I've take a closer look and I don't think you have anything to worry
about. Lintian's complaint relates to five unfortified function symbols
in the galvani binary:
getcwd
read
vsnprintf
realpath
readlink
hardening-check(1) lists an additional three. Of the eight, the galvani
source itself only includes one of them: read(2). The other are
presumably being pulled in via inline functions or templates from header
files or similar mechanisms. Furthermore, the hardening-check(1) man-
page explains that:
When an executable was built such that the fortified versions of the
glibc functions are not useful (e.g. use is verified as safe at
compile time, or use cannot be verified at runtime), this check will
lead to false alarms.
There is one read(2) call (in mess.cxx):
std::string Multimeter::readfrom_dmm ()
{
std::string mwert, extra_str;
std::string error_str;
char buffer[1024];
std::string poll;
if (scpi)
{
dmm_polling = true;
poll = "MEAS?";
}
else poll = "D";
if (usb)
{
if (dmm_polling) writeto_dmm (poll);
int result = read(usb_port, buffer, 1024);
and it is straightforward for the compiler to verify that it will not
overrun the buffer.
I believe your original rules file was fine. The correct hardening
flags were being passed. The fact that there were unfortified function
symbols in the resulting binary was down to the tool-chain and not
anything you were doing wrong.
J.
signature.asc
Description: PGP signature
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: > Do you have your 1.34 upload of buttercup in git, please? Yup, it's all on Salsa. J. > Xiyue, you need to merge in the 1.34 upload, either something from > Jeremy, or we can fall back to merging from dgit/sid. This has > happened a few times now -- please check whether you're missing > uploads before starting to work on top of the branch on salsa :) signature.asc Description: PGP signature
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-04-12, at 19:50:58 +0800, Sean Whitton wrote: > On Fri 12 Apr 2024 at 12:44pm +01, Jeremy Sowden wrote: > > On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: > > > Do you have your 1.34 upload of buttercup in git, please? > > > > Yup, it's all on Salsa. > > Er. I got confused, then, didn't I? Should this RFS be closed? I uploaded 1.34, and that is what is currently in the emacsen-team repo. This bug is for 1.35, which is currently sitting in Xiyue's fork, by the looks of it. I haven't looked at this yet. I can pick it up over the week-end. J. signature.asc Description: PGP signature
Re: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
On 2024-04-13, at 09:31:07 +0200, Andreas Tille wrote:
> Control: tags -1 help
> thanks
>
> Hi,
>
> while I was able to fix the origininal cause of the failure I'm now blocked by
> some issue that cython seems to miss adding some
>#include
> but I have no idea how to accomplish this. The Salsa CI build log[1] says:
>
> ...
> y.tab.c: In function 'yyparse':
> y.tab.c:1409:16: error: implicit declaration of function 'yylex'
> [-Werror=implicit-function-declaration]
> y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you
> mean 'YYerror'? [-Werror=implicit-function-declaration]
> In file included from aqlparse.y:335:
> aqlparse.l: In function 'yylex':
> ...
>
> Any help would be welcome
> Andreas.
You are missing declarations:
* `yylex` - this needs to be added to the yacc source
* `yyerror` - this is present but hidden by a CPP conditional
* `yywrap` - this is not needed (grep for "YY_SKIP_YYWRAP") and can be
disabled
Patch attached.
You can find more info about all three in the flex and bison manuals.
J.
diff --git a/waql/aql_.h b/waql/aql_.h
index cde94a97896b..dd3b89116280 100644
--- a/waql/aql_.h
+++ b/waql/aql_.h
@@ -448,7 +448,7 @@ char* aqlNodeTypeName (AqlNodeType inType);
char* aqlOpTypeName (AqlOpType inType);
char* aqlLocSourceTypeName (AqlLocSourceType inType);
-#if defined(IBM)
+#if defined(IBM) || defined(LINUX)
/* predeclare lex.yy.c fns */
void yyerror (char *s);
#endif
diff --git a/waql/aqlparse.l b/waql/aqlparse.l
index 313375027957..bc232e0a4c48 100644
--- a/waql/aqlparse.l
+++ b/waql/aqlparse.l
@@ -102,6 +102,8 @@
%}
+%option noyywrap
+
letter [A-Za-z]
digit [0-9]
id {letter}({letter}|{digit}|"_")*
diff --git a/waql/aqlparse.y b/waql/aqlparse.y
index 9989831a4838..975ae325c14c 100644
--- a/waql/aqlparse.y
+++ b/waql/aqlparse.y
@@ -77,6 +77,8 @@ static int tokPos[1024];
/**/
+int yylex(void);
+
%}
%union {
signature.asc
Description: PGP signature
Re: cython/bison issue (Was: acedb: FTBFS: acein.c:2045:15: error: implicit declaration of function ‘add_history’ [-Werror=implicit-function-declaration])
On 2024-04-13, at 21:48:10 +0100, Jeremy Sowden wrote: > On 2024-04-13, at 09:31:07 +0200, Andreas Tille wrote: > > Control: tags -1 help > > thanks > > > > Hi, > > > > while I was able to fix the origininal cause of the failure I'm now blocked > > by > > some issue that cython seems to miss adding some > >#include > > but I have no idea how to accomplish this. The Salsa CI build log[1] says: > > > > ... > > y.tab.c: In function 'yyparse': > > y.tab.c:1409:16: error: implicit declaration of function 'yylex' > > [-Werror=implicit-function-declaration] > > y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you > > mean 'YYerror'? [-Werror=implicit-function-declaration] > > In file included from aqlparse.y:335: > > aqlparse.l: In function 'yylex': > > ... > > > > Any help would be welcome > > Andreas. > > You are missing declarations: > > * `yylex` - this needs to be added to the yacc source > * `yyerror` - this is present but hidden by a CPP conditional > * `yywrap` - this is not needed (grep for "YY_SKIP_YYWRAP") and can be >disabled > > Patch attached. I attach a fix for the next error: gcc -g -Wall -DACEDB4 `../w3rdparty/include-config glib-2.0 gtk+-2.0` -I.. -I../wh -I../wstaden -DACEDB_GTK -DLINUX -c -o sigsubs.o sigsubs.c sigsubs.c: In function 'getSignalText': sigsubs.c:486:30: error: '_sys_siglist' undeclared (first use in this function) 486 | char **signal_textlist = &(_sys_siglist[0]) ; | ^~~~ sigsubs.c:486:30: note: each undeclared identifier is reported only once for each function it appears in The one after this looks like a GTK problem, and that's the point at which I bow out. J. diff --git a/w4/sigsubs.c b/w4/sigsubs.c index 2fd0c6ce9155..9d2942df1642 100644 --- a/w4/sigsubs.c +++ b/w4/sigsubs.c @@ -467,6 +467,10 @@ static char *getSignalText(int sig_num) return "unknown"; +#elif defined(LINUX) + + return strsignal(sig_num); + #else char *sig_text = NULL ; @@ -485,7 +489,7 @@ static char *getSignalText(int sig_num) char **signal_textlist = &(_sys_siglist[0]) ; -#if defined(LINUX) || defined(OPTERON) || defined(HP) +#if defined(OPTERON) || defined(HP) int signal_max= _NSIG ; #else int signal_max= _sys_nsig ; signature.asc Description: PGP signature
Re: poblem with dh-autoreconf ?
On 2024-04-19, at 14:27:40 +0200, PICCA Frederic-Emmanuel wrote:
> Hello,
>
> In this build, I do not see a call to dh_autoreconf_clean
>
> https://buildd.debian.org/status/fetch.php?pkg=hkl&arch=amd64&ver=5.0.0.3434-1&stamp=1713518550&raw=0
>
> this package override_dh_clean like this
>
> override_dh_clean:
> rm -f Documentation/api/hkl-docs.sgml
> dh_clean
>
> so my question is: is it normal or a bug in dh-autoreconf ?
This is normal. du_autoreconf_clean exits without doing anything unless
debian/autoreconf.before and debian/autoreconf.after exist.
To use a different package that I happen to have to hand as an example:
$ git status
On branch master
Your branch is up to date with 'debian/master'.
nothing to commit, working tree clean
$ schroot -r -c sid-conntrack-tools -- dpkg-source --before-build .
$ schroot -r -c sid-conntrack-tools -- fakeroot debian/rules clean binary
dh clean
dh_clean
rm -f debian/debhelper-build-stamp
rm -rf debian/.debhelper/
rm -f -- debian/conntrack.substvars debian/conntrackd.substvars
debian/nfct.substvars debian/files
rm -fr -- debian/conntrack/ debian/tmp/ debian/conntrackd/
debian/nfct/
find . \( \( \
\( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o
-path .\*/.hg -o -path .\*/CVS -o -path .\*/.pc -o -path .\*/_darcs \) -prune
-o -type f -a \
\( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
-o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
-o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
-o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
\) -exec rm -f {} + \) -o \
\( -type d -a \( -name autom4te.cache -o -name __pycache__ \)
-prune -exec rm -rf {} + \) \)
dh binary
dh_update_autotools_config
[...]
$ schroot -r -c sid-conntrack-tools -- fakeroot debian/rules clean
dh clean
dh_auto_clean
make -j1 distclean
[...]
make[1]: Leaving directory
'/space/azazel/work/git/repos/salsa/pkg-netfilter-team/pkg-conntrack-tools'
dh_autoreconf_clean
rm -f -- ./Makefile.in ./configure ./autom4te.cache/output.2
./autom4te.cache/requests ./autom4te.cache/output.0 ./autom4te.cache/traces.1
./autom4te.cache/traces.2 ./autom4te.cache/output.1 ./autom4te.cache/traces.0
./extensions/Makefile.in ./m4/lt\~obsolete.m4 ./m4/ltsugar.m4 ./m4/libtool.m4
./m4/ltversion.m4 ./m4/ltoptions.m4 ./src/Makefile.in ./src/helpers/Makefile.in
./configure\~ ./build-aux/ar-lib ./build-aux/compile ./build-aux/missing
./build-aux/ltmain.sh ./build-aux/ylwrap ./build-aux/depcomp ./aclocal.m4
./include/Makefile.in ./include/helpers/Makefile.in ./include/linux/Makefile.in
./include/linux/netfilter/Makefile.in
rm -f debian/autoreconf.before debian/autoreconf.after
dh_clean
[...]
The first time `debian/rules clean` runs, dh_autoreconf has not run, so
dh_autoreconf_clean has nothing to do and is silent. The second time,
after dh_autoreconf has run, you can see it doing stuff.
J.
signature.asc
Description: PGP signature
Re: Help required: riseup-vpn
On 2024-05-04, at 17:56:06 +0530, Nilesh Patra wrote:
> I am trying to update riseup-vpn to its latest version. I am seeing
> some confused mix of qt5 and qt6 - not really sure how qt updates for
> applications work. I tried to replace qt5 packages (builddeps) with
> its qt6 equivalents but I end up with:
>
> | ==BUILD GUI===
> | TARGET: bitmask-vpn
> | VENDOR_PATH: providers
> | [build.sh] VENDOR_PATH = providers
> | [+] Building BitmaskVPN
> | lrelease: could not find a Qt installation of ''
> | make[2]: *** [Makefile:151: build_gui] Error 1
> | make[2]: Leaving directory
> '/<>/_build/src/0xacab.org/leap/bitmask-vpn'
>
> I was getting a different error with qt5:
>
> | /usr/lib/qt5/bin/qmlcachegen
> --resource=/tmp/riseup-vpn_/_build/src/0xacab.org/leap/bitmask-vpn/gui/gui.qrc
> -o release/gui_main_qml.cpp ../../gui/main.qml
> | Error compiling qml file: ../../gui/main.qml:0: error: Library import
> requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
> | ../../gui/main.qml:0: error: Library import requires a version
>
> But given that the readme says to use qt6, I should not be using qt5
> here. The versions from the qml file have been omitted in this
> release.
>
> I am also puzzled with different paths for the same binaries across qt
> versions for instance qmlcachegen is:
>
> qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen
> qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen
>
> Why is that?
Presumably so one can co-install the dev tools for multiple releases
of QT.
> In any case, I am not sure how to proceed from here (the error with
> lrelease). Can anyone help out, please? My changes are available in
> salsa at: https://salsa.debian.org/go-team/packages/riseup-vpn
>
> I'd appreciate any pointers.
You can tell the GUI build script to use the qt6 lrelease and qmake
binaries:
diff --git a/debian/rules b/debian/rules
index 0e587fbc94d5..31656e0ad777 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,8 @@ export DH_GOLANG_INSTALL_EXTRA=Makefile gui tests
vendor/modules.txt branding pr
export BUILDDIR=_build/src/0xacab.org/leap/bitmask-vpn/
export GOPATH = ${CURDIR}/_build:/usr/share/gocode
export GO111MODULE := off
+export LRELEASE := /usr/lib/qt6/bin/lrelease
+export QMAKE := qmake6
include /usr/share/dpkg/pkg-info.mk
@@ -24,7 +26,7 @@ override_dh_auto_build:
override_dh_auto_test:
ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
# Qmake test
- cd $(BUILDDIR) && qmake test.pro -o tests/Makefile.test && \
+ cd $(BUILDDIR) && $(QMAKE) test.pro -o tests/Makefile.test && \
cd tests && $(MAKE) -f Makefile.test && $(MAKE) -f
Makefile.test clean
# Golang test
DH_GOLANG_EXCLUDES=gui dh_auto_test
You can also drop the build-dep on qtchooser, 'cause it only work with
qt4 and qt6, I believe.
J.
signature.asc
Description: PGP signature
Bug#1055431: Simpler fix for #1052917
This error:
> debian/rules clean
> dh clean --with elpa
>dh_auto_clean
> make -j8 clean
> make[1]: Entering directory '/<>'
> End of file during parsing
> rm -f *.elc .latest-* autoloads.el scala-mode- Error: end-of-file nil
> mapbacktrace(#f(compiled-function (evald func args flags) # 0x943b01ebae87e2>)) debug-early-backtrace() debug-early(error
> (end-of-file)) read(#) (nth 2 (read (find-file
> "./scala-mode-pkg.el"))) (format "%s\n" (nth 2 (read (find-file
> "./scala-mode-pkg.el" (princ (format "%s\n" (nth 2 (read (find-file
> "./scala-mode-pkg.el") command-line-1(("-L" "." "--eval" "(princ
> (format \"%s\\n\" (nth 2 (read (find-file \"./scala-mode-pkg.el\")"))
> command-line() normal-top-level().tar
> /bin/sh: 1: Syntax error: "(" unexpected
> make[1]: *** [Makefile:55: clean] Error 2
occurs because the Makefile does this (trimmed):
VERSION := $(shell ${ELISP_COMMAND} $(ELISP_OPTIONS) --eval
'(princ (format "%s\n" (nth 2 (read (find-file "$(PKG_FILE)")')
MODE_NAME_VERSION = $(MODE_NAME)-$(VERSION)
clean:
$(RM) *.elc .latest-* autoloads.el $(MODE_NAME_VERSION).tar
It tries to use Emacs to get the version from the scala-mode-pkg.el
file, but that doesn't exist, so the output from the `$(shell)` command
is a stack-trace, not a version number.
Make prefers variable definitions given as arguments at the command line
to those defined in the Makefile, so if `VERSION=X.Y.Z` is passed to
`make clean`:
override_dh_autoclean:
dh_auto_clean -- VERSION=X.Y.Z
Emacs isn't called, and the error goes away. I will push this change
and review the rest of this (lengthy :)) report.
J.
signature.asc
Description: PGP signature
Bug#1055431: Simpler fix for #1052917
On 2024-07-26, at 16:24:52 -0400, Nicholas D Steeves wrote:
> Jeremy Sowden writes:
> > This error:
> >> debian/rules clean
> >> dh clean --with elpa
> >>dh_auto_clean
> >>make -j8 clean
> >> make[1]: Entering directory '/<>'
> >> End of file during parsing
> >> rm -f *.elc .latest-* autoloads.el scala-mode- Error: end-of-file nil
> >> mapbacktrace(#f(compiled-function (evald func args flags) # >> 0x943b01ebae87e2>)) debug-early-backtrace() debug-early(error
> >> (end-of-file)) read(#) (nth 2 (read
> >> (find-file "./scala-mode-pkg.el"))) (format "%s\n" (nth 2 (read
> >> (find-file "./scala-mode-pkg.el" (princ (format "%s\n" (nth 2 (read
> >> (find-file "./scala-mode-pkg.el") command-line-1(("-L" "." "--eval"
> >> "(princ (format \"%s\\n\" (nth 2 (read (find-file
> >> \"./scala-mode-pkg.el\")")) command-line() normal-top-level().tar
> >> /bin/sh: 1: Syntax error: "(" unexpected
> >> make[1]: *** [Makefile:55: clean] Error 2
> >
> > occurs because the Makefile does this (trimmed):
> >
> > VERSION := $(shell ${ELISP_COMMAND} $(ELISP_OPTIONS)
> > --eval '(princ (format "%s\n" (nth 2 (read (find-file "$(PKG_FILE)")')
> > MODE_NAME_VERSION = $(MODE_NAME)-$(VERSION)
> >
> > clean:
> > $(RM) *.elc .latest-* autoloads.el $(MODE_NAME_VERSION).tar
> >
> > It tries to use Emacs to get the version from the scala-mode-pkg.el
> > file, but that doesn't exist, so the output from the `$(shell)` command
> > is a stack-trace, not a version number.
> >
> > Make prefers variable definitions given as arguments at the command line
> > to those defined in the Makefile, so if `VERSION=X.Y.Z` is passed to
> > `make clean`:
> >
> > override_dh_autoclean:
> > dh_auto_clean -- VERSION=X.Y.Z
> >
> > Emacs isn't called, and the error goes away.
Actually, it turns out that emacs _is_ called:
dh clean --with elpa
debian/rules override_dh_auto_clean
make[1]: Entering directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
dh_auto_clean -- VERSION=1.1.0
make -j16 clean VERSION=1.1.0
make[2]: Entering directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
End of file during parsing
^^
but the stack-trace doesn't get assigned to the variable, and the build
continues successfully:
rm -f *.elc .latest-* autoloads.el scala-mode-1.1.0.tar
[ ! -d scala-mode-1.1.0 ] || rm -f scala-mode-1.1.0/*
[ ! -d scala-mode-1.1.0 ] || rmdir scala-mode-1.1.0
make[2]: Leaving directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
make[1]: Leaving directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
> Thank you, yes, this is one of the right ways to solve this issue, and I
> hope it's evident to everyone following this thread why this is the
> case. :)
>
> Please use Xiyue Deng (manphiz)'s work on SUBSTVARS for "VERSION=X.Y.Z",
> and feel free to apply any fixups; I seem to remember that there's
> something like a fragile regex.
This?
BASE_UPSTREAM_VERSION=$(shell echo ${DEB_VERSION_UPSTREAM} | sed
"s/\+git.*//")
I replaced it with:
BASE_UPSTREAM_VERSION = $(word 1,$(subst +git, ,$(DEB_VERSION_UPSTREAM)))
> > I will push this change and review the rest of this (lengthy :))
> > report.
>
> Rather than reading this mentoring thread--long form for educational
> value--it's probably faster to review d/changelog, diff
> debian/20111005-2.1, and check for consistency.
>
> P.S. did you forget to push?
Indeed. Now done.
J.
signature.asc
Description: PGP signature
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "emacs-buttercup": > > * Package name : emacs-buttercup >Version : 1.36-1 >Upstream contact : Jorgen Schaefer > * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 > * Vcs : https://salsa.debian.org/emacsen-team/emacs-buttercup >Section : lisp > > The source builds the following binary packages: > > elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/emacs-buttercup/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.36-1.dsc > > Changes since the last upload: > > emacs-buttercup (1.36-1) unstable; urgency=medium > . >* New upstream release This doesn't work: >* Drop override_dh_auto_test to use default dh_elpa_test dh_elpa_test only runs a package's test-suite if the package build- depends on elpa-buttercup. Since this is the source package for elpa-buttercup, that is not the case, and dh_elpa_test exits without doing anything. Because we can't use dh_elpa_test, we also can't do this: >* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the > default As it happens, the existing dh_auto_test override doesn't actually work any more: the upstream code has changed sufficiently that it just loads tests/test-buttercup.el without actually running any tests. However, the default make target, "all", has no rules and one dependency on a target that _does_ run the full test-suite, so dh_auto_build has been running it instead by accident. My suggestion, therefore, is to skip dh_auto_build, remove the dh_auto_test override, and let dh_auto_test just run `make check`. I have pushed a branch to Salsa that implements this and makes a few other changes: https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads Seem reasonable? >* Update d/watch with filenamemangle for generating sane package name >* Update Standards-Version to 4.7.0; no change needed J. signature.asc Description: PGP signature
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-09-10, at 23:07:28 -0700, Xiyue Deng wrote: > Xiyue Deng writes: > > Jeremy Sowden writes: > >> On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: > >>> Package: sponsorship-requests > >>> Severity: normal > >>> > >>> Dear mentors, > >>> > >>> I am looking for a sponsor for my package "emacs-buttercup": > >>> > >>> * Package name : emacs-buttercup > >>>Version : 1.36-1 > >>>Upstream contact : Jorgen Schaefer > >>> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > >>> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 > >>> * Vcs : > >>> https://salsa.debian.org/emacsen-team/emacs-buttercup > >>>Section : lisp > >>> > >>> The source builds the following binary packages: > >>> > >>> elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > >>> > >>> To access further information about this package, please visit the > >>> following URL: > >>> > >>> https://mentors.debian.net/package/emacs-buttercup/ > >>> > >>> Alternatively, you can download the package with 'dget' using this > >>> command: > >>> > >>> dget -x > >>> https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.36-1.dsc > >>> > >>> Changes since the last upload: > >>> > >>> emacs-buttercup (1.36-1) unstable; urgency=medium > >>> . > >>>* New upstream release > >> > >> This doesn't work: > >> > >>>* Drop override_dh_auto_test to use default dh_elpa_test > >> > >> dh_elpa_test only runs a package's test-suite if the package build- > >> depends on elpa-buttercup. Since this is the source package for > >> elpa-buttercup, that is not the case, and dh_elpa_test exits without > >> doing anything. > >> > >> Because we can't use dh_elpa_test, we also can't do this: > >> > >>>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the > >>> default > >> > >> As it happens, the existing dh_auto_test override doesn't actually work > >> any more: the upstream code has changed sufficiently that it just loads > >> tests/test-buttercup.el without actually running any tests. However, > >> the default make target, "all", has no rules and one dependency on a > >> target that _does_ run the full test-suite, so dh_auto_build has been > >> running it instead by accident. My suggestion, therefore, is to skip > >> dh_auto_build, remove the dh_auto_test override, and let dh_auto_test > >> just run `make check`. I have pushed a branch to Salsa that implements > >> this and makes a few other changes: > >> > >> > >> https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads > >> > >> Seem reasonable? > > > > Thanks for checking and the fixes! I have removed the package on > > mentors to prevent any premature sponsoring/uploading. > > > > One small suggestion: instead of using a comment, add @echo with the > > message in override_dh_auto_build so that we get this info in the build > > log. > > > > Please feel free to merge to debian/master. > > > > I took the liberty and merged your branch, as well as the small > suggestion from my other email. Thanks again for the fix. > > BTW, will you do the uploading? In which case I'll avoid re-uploading > to mentors. Thanks in advance! Yup. J. signature.asc Description: PGP signature
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-09-11, at 18:29:51 +0100, Jeremy Sowden wrote: > On 2024-09-10, at 23:07:28 -0700, Xiyue Deng wrote: > > Xiyue Deng writes: > > > Jeremy Sowden writes: > > >> On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: > > >>> Package: sponsorship-requests > > >>> Severity: normal > > >>> > > >>> Dear mentors, > > >>> > > >>> I am looking for a sponsor for my package "emacs-buttercup": > > >>> > > >>> * Package name : emacs-buttercup > > >>>Version : 1.36-1 > > >>>Upstream contact : Jorgen Schaefer > > >>> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > > >>> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 > > >>> * Vcs : > > >>> https://salsa.debian.org/emacsen-team/emacs-buttercup > > >>>Section : lisp > > >>> > > >>> The source builds the following binary packages: > > >>> > > >>> elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > > >>> > > >>> To access further information about this package, please visit the > > >>> following URL: > > >>> > > >>> https://mentors.debian.net/package/emacs-buttercup/ > > >>> > > >>> Alternatively, you can download the package with 'dget' using this > > >>> command: > > >>> > > >>> dget -x > > >>> https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.36-1.dsc > > >>> > > >>> Changes since the last upload: > > >>> > > >>> emacs-buttercup (1.36-1) unstable; urgency=medium > > >>> . > > >>>* New upstream release > > >> > > >> This doesn't work: > > >> > > >>>* Drop override_dh_auto_test to use default dh_elpa_test > > >> > > >> dh_elpa_test only runs a package's test-suite if the package build- > > >> depends on elpa-buttercup. Since this is the source package for > > >> elpa-buttercup, that is not the case, and dh_elpa_test exits without > > >> doing anything. > > >> > > >> Because we can't use dh_elpa_test, we also can't do this: > > >> > > >>>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is > > >>> the > > >>> default > > >> > > >> As it happens, the existing dh_auto_test override doesn't actually work > > >> any more: the upstream code has changed sufficiently that it just loads > > >> tests/test-buttercup.el without actually running any tests. However, > > >> the default make target, "all", has no rules and one dependency on a > > >> target that _does_ run the full test-suite, so dh_auto_build has been > > >> running it instead by accident. My suggestion, therefore, is to skip > > >> dh_auto_build, remove the dh_auto_test override, and let dh_auto_test > > >> just run `make check`. I have pushed a branch to Salsa that implements > > >> this and makes a few other changes: > > >> > > >> > > >> https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads > > >> > > >> Seem reasonable? > > > > > > Thanks for checking and the fixes! I have removed the package on > > > mentors to prevent any premature sponsoring/uploading. > > > > > > One small suggestion: instead of using a comment, add @echo with the > > > message in override_dh_auto_build so that we get this info in the build > > > log. > > > > > > Please feel free to merge to debian/master. > > > > > > > I took the liberty and merged your branch, as well as the small > > suggestion from my other email. Thanks again for the fix. > > > > BTW, will you do the uploading? In which case I'll avoid re-uploading > > to mentors. Thanks in advance! > > Yup. Done. J. signature.asc Description: PGP signature
Re: How to delete from DELAYED queue
On 2024-09-11, at 22:55:32 +0200, Andreas Tille wrote: > I made some mistake when uploading cal_4.1-1_source.changes to > DELAYED=10 and tried to delete it from the queue. I was following > `man dcut` from dput-ng and did: > > $ dcut rm --searchdirs -f cal_4.1-1_source.changes > Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) > Expanding package list for removals to: cal_4.1-1_source.changes, > cal_4.1-1_amd64.buildinfo, cal_4.1-1.debian.tar.xz, cal_4.1.orig.tar.xz, > cal_4.1-1.dsc > Uploading andreas-1726085916.commands to ftp-master > > > This led to the response: > > Log of processing your commands file /andreas-1726085916.commands: > > > rm --searchdirs cal_4.1-1.dsc > cal_4.1-1.dsc did not match anything > No files to delete > > rm --searchdirs cal_4.1.orig.tar.xz > cal_4.1.orig.tar.xz did not match anything > No files to delete > > rm --searchdirs cal_4.1-1.debian.tar.xz > cal_4.1-1.debian.tar.xz did not match anything > No files to delete > > rm --searchdirs cal_4.1-1_amd64.buildinfo > cal_4.1-1_amd64.buildinfo did not match anything > No files to delete > > rm --searchdirs cal_4.1-1_source.changes > cal_4.1-1_source.changes did not match anything > No files to delete > > Greetings, > > Your Debian queue daemon (running on host usper.debian.org) > > > Any idea how I can successfully remove this package from the queue? > Its really there[1]. `dcut cancel -f cal_4.1-1_source.changes`, I think. J. signature.asc Description: PGP signature
Bug#1081570: RFS: luit/2.0.20240910-1 -- locale and ISO 2022 support for Unicode terminals
On 2024-09-14, at 06:52:31 -0400, Thomas Dickey wrote: > On Sat, Sep 14, 2024 at 02:08:44AM +0100, Phil Wyett wrote: > > Control: tags -1 +moreinfo > > > > Thomas, > > > > Many thanks for addressing some of the issues raised. > > > > One lintian issue remains. > > > > I: luit source: unused-override no-debian-changes [debian/source/lintian- > > overrides:2] > > On removing that file, I get this warning (and by the way do not see the > warning which you report): > > > run-lintian luit_2.0.20240910-1.dsc luit_2.0.20240910-1_amd64.buildinfo > > luit_2 > .0.20240910-1_amd64.changes > N: > W: luit source: no-debian-changes > N: > N: This non-native package makes no changes to the upstream sources in the > N: Debian-related files. > N: > N: Maybe a mistake was made when the upstream tarball was created, or maybe > N: this package is really a native package but was built non-native by > N: mistake. > N: > N: Debian packaging is sometimes maintained as part of upstream, but that is > N: not recommended as best practice. Please make this package native, if the > N: software is only for Debian. Otherwise, please remove the debian > directory > N: from upstream releases and add it in the Debian packaging. > N: > N: Format 1.0 packages are subject to the restriction that the diff cannot > N: remove files from the debian directory. For Format 3.0 packages, the > N: debian directory is automatically purged during unpacking. > N: > N: Visibility: warning > N: Show-Always: no > N: Check: files/artifact > N: Renamed from: empty-debian-diff > N: I've just cloned g...@salsa.debian.org:debian/luit, added the missing upstream/2.0.20240910 tag, and built the package using gbp-buildpackage. I got two lintian warnings: $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit 0 W: luit source: orig-tarball-missing-upstream-signature luit_2.0.20240910.orig.tar.gz I: luit source: unused-override no-debian-changes [debian/source/lintian-overrides:2] N: 0 hints overridden; 1 unused override I deleted d/s/lintian-overrides, built the package again and got just one: $ schroot -c sid -- lintian --display-info --pedantic --tag-display-limit 0 W: luit source: orig-tarball-missing-upstream-signature luit_2.0.20240910.orig.tar.gz Do you have local changes that you haven't pushed? J. signature.asc Description: PGP signature
Re: [Help] Re:input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
On 2024-09-16, at 12:32:59 +0200, Andreas Tille wrote:
> Control: tags -1 help
> Control: tags -1 confirmed
> Thanks
>
> Hi,
>
> since input-utils showed up as Bug of the Day[1] I worked down the list
> of bugs including upgrading to latest upstream. Unfortunately the FTBFS
> for several 32bit architectures (not only armhf) remains[2].
>
> Since I have no experience with these architectures I'd kindly ask for
> help here.
>
> Kind regards
> Andreas.
>
> [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
> [2] https://buildd.debian.org/status/package.php?p=input-utils
Try this patch.
J.
--- a/input.c
+++ b/input.c
@@ -209,9 +209,9 @@
char ts[32];
time_t t;
- t = event->time.tv_sec;
+ t = event->input_event_sec;
strftime(ts,sizeof(ts),"%H:%M:%S",localtime(&t));
- printf("%s.%06ld: %s",ts,event->time.tv_usec,
+ printf("%s.%06ld: %s",ts,event->input_event_usec,
EV_NAME[event->type]);
switch (event->type) {
case EV_KEY:
--- a/input-send.c
+++ b/input-send.c
@@ -73,8 +73,8 @@
print_event(ev);
/* convert to network byte order ... */
- ev->time.tv_sec = htonl(ev->time.tv_sec);
- ev->time.tv_usec = htonl(ev->time.tv_usec);
+ ev->input_event_sec = htonl(ev->input_event_sec);
+ ev->input_event_usec = htonl(ev->input_event_usec);
ev->type = htons(ev->type);
ev->code = htons(ev->code);
ev->value= htonl(ev->value);
signature.asc
Description: PGP signature
Re: Help for wget2 update needed
On 2024-09-16, at 16:16:10 +0200, Andreas Tille wrote: > I intend to try the latest version of wget2. To build it I've created a > fork but it does not build as you can see in Salsa CI[1]. I fiddled > around with some patches for automake but obviously with no success. > > Any help would be welcome. > > Kind regards > Andreas. > > [1] https://salsa.debian.org/tille/wget2/-/jobs/6290074 wget2 seems to rely heavily on gnulib, so you'll need a build-dep on that. It includes a bootstrap script which pulls in the code it requires from gnulib and needs to be run before dh_autoreconf. Patch attached. J. diff --git a/debian/control b/debian/control index 7547381ba08b..c6f93dd051f5 100644 --- a/debian/control +++ b/debian/control @@ -1,7 +1,7 @@ Source: wget2 Priority: optional Maintainer: Noël Köthe -Build-Depends: debhelper-compat (= 13), pkg-config, doxygen, pandoc, gettext, zlib1g-dev, liblzma-dev, libbz2-dev, libzstd-dev, libbrotli-dev, libpcre2-dev, libgnutls28-dev, libidn11-dev, libidn2-dev, flex, libpsl-dev, automake, dh-strip-nondeterminism, gnulib, libnghttp2-dev, graphviz, libgpgme-dev, texinfo +Build-Depends: debhelper-compat (= 13), pkg-config, doxygen, pandoc, gettext, gnulib, zlib1g-dev, liblzma-dev, libbz2-dev, libzstd-dev, libbrotli-dev, libpcre2-dev, libgnutls28-dev, libidn11-dev, libidn2-dev, flex, libpsl-dev, automake, dh-strip-nondeterminism, gnulib, libnghttp2-dev, graphviz, libgpgme-dev, texinfo Standards-Version: 4.7.0 Section: web Homepage: https://gitlab.com/gnuwget/wget2 diff --git a/debian/rules b/debian/rules index 9cdea694dc3f..fc86a1c265f3 100755 --- a/debian/rules +++ b/debian/rules @@ -8,5 +8,8 @@ %: dh $@ +execute_before_dh_autoreconf: + ./bootstrap --gnulib-srcdir=/usr/share/gnulib + override_dh_condfigure: dh_configure -- --enable-fsanitize-ubsan=no signature.asc Description: PGP signature
Re: [Help] Re: input-utils: FTBFS on armhf: input.c:146:18: error: ‘struct input_event’ has no member named ‘time’
On 2024-09-16, at 15:18:27 +0200, Andreas Tille wrote:
> Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> > Try this patch.
>
> Works.
>
> Thanks a lot for the quick help
A quick follow-up now I have more time. The definition of `struct
input_event` in /usr/include/linux/input.h looks like this:
/*
* The event structure itself
* Note that __USE_TIME_BITS64 is defined by libc based on
* application's request to use 64 bit time_t.
*/
struct input_event {
#if (__BITS_PER_LONG != 32 || !defined(__USE_TIME_BITS64)) &&
!defined(__KERNEL__)
struct timeval time;
#define input_event_sec time.tv_sec
#define input_event_usec time.tv_usec
#else
__kernel_ulong_t __sec;
#if defined(__sparc__) && defined(__arch64__)
unsigned int __usec;
unsigned int __pad;
#else
__kernel_ulong_t __usec;
#endif
#define input_event_sec __sec
#define input_event_usec __usec
#endif
__u16 type;
__u16 code;
__s32 value;
};
The ifdeffery is to support 64-bit `time_t`. The patch I gave you
replaces direct references to the `struct timeval time` member, which is
not defined on some 32-bit architectures, with the `input_event_[u]sec`
macros.
J.
signature.asc
Description: PGP signature
Re: dpkg-shlibdeps: error: cannot find library (Was: Bug#977308: shasta: hardcoded dependencies on boost 1.71)
On 2020-12-18, at 15:32:01 +0100, Andreas Tille wrote:
> I tried no override_dh_shlibdeps in shasta debian/rules, which has
> lead to:
>
> dpkg-shlibdeps: error: cannot find library
> /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so
> needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64'
> abi: '0201003e'; RPATH: '')
> dpkg-shlibdeps: error: cannot continue due to the error above Note:
> libraries are not searched in other binary packages that do not have
> any shlibs or symbols file. To help dpkg-shlibdeps find private
> libraries, you might need to use -l.
> dh_shlibdeps: error: dpkg-shlibdeps -Tdebian/shasta.substvars
> debian/shasta/usr/bin/shasta returned exit code 2
> dh_shlibdeps: error: Aborting due to earlier error
>
> and in the pbuilder chroot I also tried the there commands I added to
> the comment in
>
>
> https://salsa.debian.org/med-team/shasta/-/commit/366edd672be428cc553b34b99bc614aa698175d6
>
> with no success - dpkg-shlibdeps simply did not found the shared
> library which exists at the said place. I wonder what might be wrong
> here and how to fix this.
If you haven't got this sorted yet, try the attached patch. It also
corrects the SONAME of shasta.so. It does mean there's an RPATH in the
executable, however.
The problem with the previous solution is that it sets the NEEDED value
in the executable to the absolute path of the shared library, instead of
the SONAME, so it didn't matter what directory was passed,
dpkg-shlibdeps wouldn't find a library with the right SONAME.
J.
diff --git a/debian/rules b/debian/rules
index 0e286eb38f66..f1593bfc0179 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,7 @@ include /usr/share/dpkg/default.mk
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+MULTIARCH_SONAME = shasta.cpython-$(shell py3versions -vd | sed 's/\.//')-$(DEB_HOST_MULTIARCH).so
%:
dh $@ --with python3,sphinxdoc
@@ -24,22 +25,23 @@ override_dh_auto_build:
find . -name "shasta.so" -exec cp {} docs/PythonApi/ \;
PYTHONPATH=docs/PythonApi/ python3 -m sphinx -N -bhtml docs/PythonApi/ build/html # HTML generator
+override_dh_python3:
+ dh_python3
+ patchelf \
+ --set-soname $(MULTIARCH_SONAME) \
+ $(CURDIR)/debian/python3-shasta/usr/lib/python3/dist-packages/$(MULTIARCH_SONAME)
+
override_dh_install-arch:
dh_install -a
# Rename shastaDynamic to shasta for ease
mv debian/shasta/usr/bin/shastaDynamic debian/shasta/usr/bin/shasta
# The library is in a more unusual place (nested within /usr/lib), so modify
# the ELF
- chrpath -d debian/shasta/usr/bin/shasta
- patchelf --replace-needed shasta.so /usr/lib/python3/dist-packages/shasta.cpython-`py3versions -vd | sed 's/\.//'`-${DEB_HOST_MULTIARCH}.so \
+ chrpath -r /usr/lib/python3/dist-packages \
+ debian/shasta/usr/bin/shasta
+ patchelf \
+ --replace-needed shasta.so $(MULTIARCH_SONAME) \
debian/shasta/usr/bin/shasta
-
-override_dh_shlibdeps:
- # Tried:
- #dh_shlibdeps -v -Lpython3-shasta
- #dh_shlibdeps -v -l/usr/lib/python3/dist-packages
- #dh_shlibdeps -v -l$(CURDIR)/debian/python3-shasta/usr/lib/python3/dist-packages
- # but all failed :-(
override_dh_missing:
# No need to install docker files
signature.asc
Description: PGP signature
Re: r-cran-ncdf4: ftbfs with autoconf 2.70
On 2021-09-08, at 16:06:34 +0200, Andreas Tille wrote:
> Control: tags -1 help
>
> Hi,
>
> I need to admit that from my naive perspective this is a bug in
> autoconf. In the log that is provided in the bug report[1] you can see
> this here:
>
>dh_autoreconf -O--buildsystem=R
> configure.ac:44: warning: AC_OUTPUT should be used without arguments.
> configure.ac:44: You should run autoupdate.
> configure.ac:44: warning: AC_OUTPUT should be used without arguments.
> configure.ac:44: You should run autoupdate.
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> cd tools && ./regenerate
> rm: cannot remove '../Makefile': No such file or directory
> rm: cannot remove '../src/Makevars': No such file or directory
> configure.ac:44: warning: AC_OUTPUT should be used without arguments.
> configure.ac:44: You should run autoupdate.
> configure.ac:44: warning: AC_OUTPUT should be used without arguments.
> configure.ac:44: You should run autoupdate.
>
>
> This results later in:
>
>
> ** using staged installation
> configure.ac: starting
> ./configure: line 1764: syntax error near unexpected token `;;'
> ./configure: line 1764: ` as_dir=./ ;;'
> ERROR: configuration failed for package ‘ncdf4’
>
>
>
> I checked the resulting configure file and the part in question looks like:
>
>
> echo "configure.ac: starting"
>
> as_dir=./ ;;
> */) ;;
> *) as_dir=$as_dir/ ;;
> esac
> for ac_exec_ext in '' $ac_executable_extensions; do
> if as_fn_executable_p "$as_dir$ac_word$ac_exec_ext"; then
> ac_cv_prog_HAS_NC_CONFIG="yes"
> printf "%s\n" "$as_me:${as_lineno-$LINENO}: found
> $as_dir$ac_word$ac_exec_ext" >&5
> break 2
> fi
> done
>
>
> It looks like a case statement intended but not injected by autoconf. I
> have no idea how this can be influenced by some configure.ac statement.
>
> Kind regards
>
>Andreas.
>
> [1] https://bugs.debian.org/978891
Try this patch.
J.
From 2e5bda24d3b2799d21b5342290fbeed54cf83101 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Wed, 8 Sep 2021 14:50:40 +
Subject: [PATCH] Quote allowed M4 pattern.
Signed-off-by: Jeremy Sowden
---
tools/configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/configure.ac b/tools/configure.ac
index 7d781c514c2e..16579d35a8ab 100644
--- a/tools/configure.ac
+++ b/tools/configure.ac
@@ -2,7 +2,7 @@ AC_INIT(src/Makevars.in)
echo "configure.ac: starting"
-m4_pattern_allow(AC_PATH_NETCDF)
+m4_pattern_allow([AC_PATH_NETCDF])
: ${R_HOME=`R RHOME`}
if test -z "${R_HOME}"; then
--
2.33.0
signature.asc
Description: PGP signature
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On 2021-12-07, at 11:49:32 -0500, Tong Sun wrote: > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a > warning? > > Aren't we supposed to use dpkg-maintscript-helper in maintainer > scripts? At least I was told to do so. > > I tried to add `dpkg-maintscript-helper rm_conffile` in my .postrm > file for my dbab package, and now I'm getting the above warning > message. > > How can I fix the situation? Have a look at the dh_installdeb man-page. J. signature.asc Description: PGP signature
Re: combining pybuild and cmake
On 2022-08-07, at 14:26:07 +0200, Ole Streicher wrote: > I am working on a package > (https://salsa.debian.org/debian-astro-team/sep), that needs a > two-stage build: First, a library is built with cmake/make, and then a > Python (wrapper) package is built the usual way. > > I tried to just have two commands in d/rules: > > ---8<-- > %: > dh $@ --buildsystem=cmake > PYBUILD_NAME=sep dh $@ --with python3 --buildsystem=pybuild > ---8<-- > > however this seems to completely confuse the whole build system: it > somehow re-executes the cmake build in the second step, doesn't call > setup.py at all, and then doesn't find files to put into the package. > > What is the proper way to do this? Don't know whether it the proper way to do it, but this: $ cat debian/rules #!/usr/bin/make -f #export DH_VERBOSE=1 %: dh $@ --with python3 override_dh_auto_clean: dh_auto_clean -O--buildsystem=cmake dh_auto_clean -O--buildsystem=pybuild override_dh_auto_configure: dh_auto_configure -O--buildsystem=cmake dh_auto_configure -O--buildsystem=pybuild override_dh_auto_build: dh_auto_build -O--buildsystem=cmake dh_auto_build -O--buildsystem=pybuild override_dh_auto_install: dh_auto_install -O--buildsystem=cmake dh_auto_install -O--buildsystem=pybuild appears to put the right files in debian/tmp: $ find debian/tmp/ debian/tmp/ debian/tmp/usr debian/tmp/usr/lib debian/tmp/usr/lib/python3.10 debian/tmp/usr/lib/python3.10/dist-packages debian/tmp/usr/lib/python3.10/dist-packages/sep-1.2.1.egg-info debian/tmp/usr/lib/python3.10/dist-packages/sep-1.2.1.egg-info/top_level.txt debian/tmp/usr/lib/python3.10/dist-packages/sep-1.2.1.egg-info/requires.txt debian/tmp/usr/lib/python3.10/dist-packages/sep-1.2.1.egg-info/PKG-INFO debian/tmp/usr/lib/python3.10/dist-packages/sep-1.2.1.egg-info/dependency_links.txt debian/tmp/usr/lib/python3.10/dist-packages/sep.cpython-310-x86_64-linux-gnu.so debian/tmp/usr/lib/x86_64-linux-gnu debian/tmp/usr/lib/x86_64-linux-gnu/libsep.so debian/tmp/usr/lib/x86_64-linux-gnu/libsep.so.0 debian/tmp/usr/lib/x86_64-linux-gnu/libsep.so.0.6.0 debian/tmp/usr/include debian/tmp/usr/include/sep.h J. signature.asc Description: PGP signature
Re: Need some help understanding compiler-flags-hidden lintian warning
On 2022-09-18, at 20:35:37 -0400, Aaron Boxer wrote: > https://qa.debian.org/bls/packages/l/libgrokj2k.html > > >From the build logs, I am unable to find which compiler flags are hidden. > What's the best way of getting more information about the warning ? Running blhc on a couple of the build-logs yields this warning: LDFLAGS missing (-Wl,-z,now): /usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -shared -Wl,-soname,libgrokj2k_plugin.so.1 -o ../../../bin/libgrokj2k_plugin.so.10.0.2 CMakeFiles/grokj2k_plugin.dir/Plugin.cpp.o J. signature.asc Description: PGP signature
Re: Add documentation regarding `-1` argument
On 2024-09-23, at 10:36:43 -0700, Soren Stoutner wrote: > On Monday, September 23, 2024 9:34:30 AM MST Jeroen Ploemen wrote: > > > I gather from context that the "-1" here refers to the bug that > > > the email is being sent to, and indeed I use this in my Control: > > > header above to remove the moreinfo tag as you requested, but > > > despite searching all over for the life of me I can't find where > > > this fact is explicitly documented anywhere. Do you happen to > > > know? > > > > Not really, only seems to be mentioned in an example at [1]. > > > > [1]https://www.debian.org/Bugs/server-control#clone > > Would somebody who has access to edit > https://www.debian.org/Bugs/server-control please add documentation > for the `-1` argument. It's mentioned in the "Control Commands" of https://www.debian.org/Bugs/Reporting J. signature.asc Description: PGP signature
Bug#1055431: Simpler fix for #1052917
On 2024-09-21, at 21:15:50 -0700, Xiyue Deng wrote: > This RFS has been open for a while, and I believe most of the comments > have been addressed. > > Can Nicholas or Jeremy help sponsor the uploading? Or if you have > more comments I'll try to address them as well. I'll take another look. J. signature.asc Description: PGP signature
Bug#1055431: Simpler fix for #1052917
On 2024-09-22, at 22:18:03 +0100, Jeremy Sowden wrote: > On 2024-09-21, at 21:15:50 -0700, Xiyue Deng wrote: > > This RFS has been open for a while, and I believe most of the comments > > have been addressed. > > > > Can Nicholas or Jeremy help sponsor the uploading? Or if you have > > more comments I'll try to address them as well. > > I'll take another look. LGTM. Will upload. J. signature.asc Description: PGP signature
Re: Help for wget2 update needed
On 2024-09-16, at 21:49:23 +0200, Andreas Tille wrote: > Am Mon, Sep 16, 2024 at 04:17:10PM +0100 schrieb Jeremy Sowden: > > > > wget2 seems to rely heavily on gnulib, so you'll need a build-dep on > > that. It includes a bootstrap script which pulls in the code it > > requires from gnulib and needs to be run before dh_autoreconf. > > > > Patch attached. > > That patch (as well as the hint from Santiago) helped definitely to some > progress. However, I'm now blocked by > > config.status:3707: creating include/wget/wgetver.h > config.status:3707: creating po/Makefile.in > config.status:3693: error: cannot find input file: 'Makefile.in' > > as you can see in Salsa CI[1]. > > Any further hints? > > Kind regards > Andreas. > > [1] https://salsa.debian.org/tille/wget2/-/jobs/6291380#L11850 Drop the three autotools patches: no_parallel_tests.patch fixme.patch no_gnulib.mk.patch That should get you as far as dh_install. J. signature.asc Description: PGP signature
Re: How to force build to use LANG=C.UTF-8?
On 2025-04-11, at 09:56:28 +0800, Bo YU wrote:
On Fri, Apr 11, 2025 at 7:52 AM Soren Stoutner wrote:
> The Redmine package includes a test run at build time that checks for
> a list of particular response values. The problem is that these
> values are translated. Running the build in a different language
> causes the test to fail.
>
> Failure:
> ProjectAdminQueryTest#test_project_statuses_values_should_return_all_statuses
> [test/unit/project_admin_query_test.rb:99]:
> --- expected
> +++ actual
> @@ -1 +1 @@
> -[["active", "1"], ["closed", "5"], ["archived", "9"], ["scheduled for
> deletion", "10"]]
> +[["actif", "1"], ["fermé", "5"], ["archivé", "9"], ["planifié pour
> suppression", “10”]]
>
> https://tests.reproducible-builds.org/debian/rb-pkg/trixie/arm64/redmine.html
>
> Setting "export LANG=C.UTF-8” does not prevent this test from running
> in a foreign language.
>
> https://salsa.debian.org/ruby-team/redmine/-/jobs/7360518#L3871
I remember there was a fix[0] for this problem. In other words, this
variable needs to be passed when calling test. Hope this helps.
[0]:
https://salsa.debian.org/debian-mate-team/onboard/-/blob/master/debian/rules?ref_type=heads#L45
I've did something similar for magit:
https://salsa.debian.org/emacsen-team/magit/-/commit/2371b4f9cd51742c196400d14b95aebc75859791
However, I don't _think_ the solution here is to set "LANG" (or
"LC_ALL"). I would expect exporting "LANG=C.UTF-8" to work, if it were.
I just tried to reproduce the test failure by explicitly setting
"LC_ALL=it_IT.UTF-8" and was unable to do so.
I am not familiar with Ruby and how it does i18n, but based on a quick
bit of research, I _suspect_ that there may be a concurrency bug in the
test-suite. The tests are run in a non-deterministic order and some of
them change the locale. Therefore, I think what is happening is that a
test runs before the failing one which changes the locale (to "pt" or
"fr", for example) causing the test to fail. The failing test is:
def test_project_statuses_values_should_return_all_statuses
q = ProjectAdminQuery.new
assert_equal [
["active", "1"],
["closed", "5"],
["archived", "9"],
["scheduled for deletion", "10"]
], q.project_statuses_values
end
Compare this to a similar test in the same file:
def test_project_statuses_filter_should_return_project_statuses
set_language_if_valid 'en'
query = ProjectAdminQuery.new(:name => '_')
query.filters = {'status' => {:operator => '=', :values => []}}
values = query.available_filters['status'][:values]
assert_equal ['active', 'closed', 'archived', 'scheduled for deletion'],
values.map(&:first)
assert_equal ['1', '5', '9', '10'], values.map(&:second)
end
In the latter test, the locale is explicitly set to "en". I think this
should be done in the former test too.
J.
signature.asc
Description: PGP signature
Re: Bug#1104244: RFS: foomuuri/0.28-1 [ITA] -- multizone bidirectional nftables firewall
On 2025-04-27, at 20:08:43 +0300, Kim B. Heino wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "foomuuri": * Package name : foomuuri Version : 0.28-1 Upstream contact : Kim B. Heino * URL : https://github.com/FoobarOy/foomuuri * License : GPL-2+ * Vcs : https://salsa.debian.org/kimheino/foomuuri Section : net I'll pick this up. I'm a member of the Shorewall team and I have been informed that the Foomuuri maintainer (formerly of the SW team) has put the package up for adoption. I created a fork because I don't have commit access to original vcs: https://salsa.debian.org/debian/foomuuri The source builds the following binary packages: foomuuri - multizone bidirectional nftables firewall foomuuri-firewalld - multizone bidirectional nftables firewall - firewalld emulation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/foomuuri/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/f/foomuuri/foomuuri_0.28-1.dsc Changes since the last upload: foomuuri (0.28-1) unstable; urgency=medium . * New upstream release. * New maintainer (Closes: #1095472) Regards, -- Kim B. Heino J. signature.asc Description: PGP signature
Re: Python dependency when building
On 2025-04-16, at 14:07:46 +0200, Hilmar Preusse wrote:
I hope this question is easy to answer, maybe I'm on the wrong list.
The lintian report for package asymptote-x11 says:
E: asymptote-x11: python3-script-but-no-python3-dep python3 (does not satisfy
python3:any | python3-minimal:any) [usr/share/asymptote/GUI/xasy.py]
N:
N:
N: If you are using debhelper, adding ${python3:Depends} to the Depends field
N: and ensuring dh_python3 is run during the build should take care of adding
N: the correct dependency.
N:
The debian/control of the source package reads:
Package: asymptote-x11
Architecture: all
Depends: ${misc:Depends},
${python3:Depends},
asymptote (>= ${binary:Version}),
and the d/rules uses the dh sequencer: dh $@ --with python3
Looking at the build log I see that dh_python3 is called, nevertheless
dpkg-gencontrol reports:
dpkg-gencontrol: warning: Depends field of package asymptote-x11: substitution
variable ${python3:Depends} used, but is not defined.
The python related BD's of the source package are dh-python & python3.
I replaced the "#!/usr/bin/env python3" shebang in the script by
"#!/usr/bin/python3", but this did not solve the issue.
What am I missing? Many thanks!
From the dh_python3 man-page:
private dirs
/usr/share/foo, /usr/share/games/foo, /usr/lib/foo and
/usr/lib/games/foo private directories are scanned for Python
files by default (where foo is bi‐ nary package name). If your
package ships Python files in some other directory, add another
dh_python3 call in debian/rules with directory name as an
argument - you can use different set of options in this call. If
you need to change options (f.e. a list of supported Python 3
versions) for a private directory that is checked by default,
invoke dh_python3 with --skip-private option and add another call
with a path to this directory and new options.
I've attached a patch.
J.
diff --git a/debian/rules b/debian/rules
index 0ce2ee396331..4387ffd436d4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,8 @@
# Avoid unneeded library dependencies reported by dpkg-shlibdeps.
DEB_LDFLAGS_MAINT_APPEND := -Wl,--as-needed
DEB_BUILD_MAINT_OPTIONS := hardening=+all
+
+include /usr/share/dpkg/architecture.mk
include /usr/share/dpkg/buildflags.mk
include /usr/share/dpkg/pkg-info.mk
@@ -40,6 +42,10 @@ override_dh_auto_install:
#override_dh_auto_test:
# : do nothing here, otherwise make tries to compile prc/test.cc
+override_dh_python3:
+ dh_python3 -Nasymptote-x11
+ dh_python3 -pasymptote-x11 /usr/share/asymptote/GUI
+
override_dh_compress:
dh_compress -X.pdf
signature.asc
Description: PGP signature
Bug#1104244: RFS: foomuuri/0.28-1 [ITA] -- multizone bidirectional nftables firewall
On 2025-05-06, at 07:23:48 +0300, Kim B. Heino wrote: Have you had time to look at Foomuuri package yet? Can I help you in any way? There is also an update to bookworm-backports waiting in my repo. What is the correct procedure for it? I took a brief look at the beginning of this week. I'm planning on doing a proper review over the week-end. J. signature.asc Description: PGP signature
Bug#1104244: RFS: foomuuri/0.28-1 [ITA] -- multizone bidirectional nftables firewall
On 2025-04-27, at 20:33:34 +0100, Jeremy Sowden wrote: On 2025-04-27, at 20:08:43 +0300, Kim B. Heino wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "foomuuri": > > * Package name : foomuuri > Version : 0.28-1 > Upstream contact : Kim B. Heino > * URL : https://github.com/FoobarOy/foomuuri > * License : GPL-2+ > * Vcs : https://salsa.debian.org/kimheino/foomuuri > Section : net I'll pick this up. I'm a member of the Shorewall team and I have been informed that the Foomuuri maintainer (formerly of the SW team) has put the package up for adoption. > I created a fork because I don't have commit access to original vcs: > > https://salsa.debian.org/debian/foomuuri > > The source builds the following binary packages: > > foomuuri - multizone bidirectional nftables firewall > foomuuri-firewalld - multizone bidirectional nftables firewall - > firewalld emulation > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/foomuuri/ > > Alternatively, you can download the package with 'dget' using this > command: > > dget -x > https://mentors.debian.net/debian/pool/main/f/foomuuri/foomuuri_0.28-1.dsc > > Changes since the last upload: > > foomuuri (0.28-1) unstable; urgency=medium > . > * New upstream release. > * New maintainer (Closes: #1095472) Mostly looks good. The only problem I see is that, because foomuuri is being back-ported to Bookworm, the systemd files cannot be unconditio- nally installed into /usr/lib/systemd: dh-sequence-movetousr needs to be retained. How do you want to proceed? Did you create the ITA bug report because you do want to become the foomuuri package maintainer, or because it had been orphaned and you wanted to make sure that somebody was looking after it? My suggestion would be to create a foomuuri team with both of us as members (despite my somewhat tardy answers over the last month or so, I am usually more responsive :)). I can give you commit priv's to the repo and do the uploads. As Phil Wyett (thanks for your tireless work on debian-mentors, btw) pointed out earlier, Trixie is currently frozen, so the new upload will have to wait till Trixie is released, but we can get everything set up and ready to go once the time comes. J. signature.asc Description: PGP signature
Bug#1104244: RFS: foomuuri/0.28-1 [ITA] -- multizone bidirectional nftables firewall
On 2025-06-07, at 10:29:41 +0300, Kim B. Heino wrote: It's been a month. Any progress? Apologies. The day job has been unusually busy over the last month, and I've been distracted. I will get back to you properly this week-end. Promise! :) J. signature.asc Description: PGP signature
