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
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=amd64=5.0.0.3434-1=1713518550=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: 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: 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
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
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#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#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#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
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
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: 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: 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: 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: 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: 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: [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: [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: 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..5a01bff73894 100644 +--- a/src/lib/chemistry/qc/intv3/shift
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 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], []) +AH_TEMPLA
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: 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
