Bug#1074868: Wrong package?
I think this is actually a bug in Rapid JSON:
$ cat test.cc
#include
int
main(void)
{
return 0;
}
$ g++-14 -g -O2 -o test test.cc
In file included from test.cc:1:
/usr/include/rapidjson/document.h: In member function
‘rapidjson::GenericStringRef&
rapidjson::GenericStringRef::operator=(const
rapidjson::GenericStringRef&)’:
/usr/include/rapidjson/document.h:319:82: error: assignment of read-only
member ‘rapidjson::GenericStringRef::length’
319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s =
rhs.s; length = rhs.length; }
|
J.
signature.asc
Description: PGP signature
Bug#1075650: Patch
Control: tags -1 patch
Here's a patch that fixes the errors. I will create a merge request.
J.
Author: Jeremy Sowden
Last-Update: 2024-07-26
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075650
Description: fix gcc-14 FTBFS caused by incompatible pointer types
`XawListChange` declares the type of its second parameter as `_Xconst
char **`. However, xawtv passes `str_list`, which is declared as
`String *`, or `` which is declared as `char *`. With gcc 14,
these result in incompatible-pointer errors:
.
x11/propwatch.c: In function 'RebuildList':
x11/propwatch.c:319:43: error: passing argument 2 of 'XawListChange' from incompatible pointer type [-Wincompatible-pointer-types]
319 | XawListChange(bl,str_count ? str_list : ,
| ~^~~~
| |
| char **
In file included from x11/propwatch.c:28:
/usr/include/X11/Xaw/List.h:170:27: note: expected 'const char **' but argument is of type 'char **'
170 | _Xconst char **list,
| ^
x11/propwatch.c: In function 'ProcessPropertyChange':
x11/propwatch.c:498:34: error: passing argument 2 of 'XawListChange' from incompatible pointer type [-Wincompatible-pointer-types]
498 | XawListChange(bl,str_list,str_count,1000,1);
| ^~~~
| |
| char **
/usr/include/X11/Xaw/List.h:170:27: note: expected 'const char **' but argument is of type 'char **'
170 | _Xconst char **list,
| ^
.
Both variables are only used as arguments to `XawListChange`, so change
their types to match its expectations.
--- a/x11/propwatch.c
+++ b/x11/propwatch.c
@@ -58,8 +58,8 @@
"WM_COMMAND",
};
-static String *str_list;
-static int str_count;
+static const char **str_list;
+static int str_count;
static void AddWatch(Display *dpy, Window win, int i);
static void DeleteWatch(Window win);
@@ -306,13 +306,13 @@
static void
RebuildList(void)
{
-static char *empty = "empty";
+static const char *empty = "empty";
int i;
struct WATCHLIST *this;
if (str_list)
free(str_list);
-str_list = malloc(str_count*sizeof(String));
+str_list = malloc(str_count*sizeof(*str_list));
for (i=0, this=watchlist; this!=NULL; i++, this=this->next)
str_list[i] = this->text;
qsort(str_list,str_count,sizeof(char*),cmp);
signature.asc
Description: PGP signature
Bug#1073560: Reverting "xshared: Print protocol numbers if --numeric was given" breaks firewalld autopkgtest
On 2024-06-17, at 15:57:05 +0200, Michael Biebl wrote:
> Source: iptables
> Version: 1.8.10-4
> Severity: serious
>
>
> The cherry-pick of the commit 34f085b1607364f4eaded1140060dcaf965a2649
> Revert "xshared: Print protocol numbers if --numeric was given" breaks
> firewalld, as seen in
> https://ci.debian.net/packages/f/firewalld/testing/amd64/47810213/
>
> firewalld is very susceptible to changes of the output and command
> line interface of iptables. See an older issue
> https://github.com/firewalld/firewalld/issues/1112
>
> Filing with RC severity, so the package doesn't migrate to testing
> (the debci results should prevent that, but this is just to make
> doubly sure)
>
> This change of iptables afaics has landed in a stable release
> (bookworm). Do we really want to revert it again and make all users of
> --numeric have to update again?
Hi. Let me explain my understanding of the current situation. I appre-
ciate that you probably know most of this already, but I just want to
avoid any confusion.
Upstream made a change that affected the output of protocols in listings
in the presence of the `--numeric` flag. Previously, they were still
output by name, after the change they were output by number. This was
released upstream in 1.8.9 and made its way into Bookworm.
This change broke stuff. As a result of a bug-report:
https://bugzilla.netfilter.org/show_bug.cgi?id=1729
upstream reverted the change in commit 34f085b16073 ("Revert "xshared:
Print protocol numbers if --numeric was given""). This is where things
currently stand upstream: in the next release (1.8.11), the original
behaviour will be restored.
A report was also created in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067733
In response, I applied the upstream commit and uploaded it to unstable.
I have a draft bookworm-pu bug-report that I had intended to send
requesting that this change go into Bookworm to minimize the time before
the old behaviour is restored. Obviously, I will hold off while we
discuss this. :)
What do you propose? The firewalld test-suite was updated to work with
the new output; however, other tools were not, and upstream reverted the
change because there were no compelling reasons for it and it had caused
breakage in those tools. As things stand, the old behaviour will be re-
stored. Would you rather wait for the next upstream release? Are you
suggesting that we ask upstream to revert 34f085b16073? Or do you have
something else in mind?
J.
> -- System Information:
> Debian Release: trixie/sid
> APT prefers unstable
> APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.8.12-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
signature.asc
Description: PGP signature
Bug#1067547: wmweather+: diff for NMU version 2.19~alpha+ds-1.1
[Cc'ing t...@debian.org as I probably should have done with the nmudiff.
Apologies]
On 2024-04-18, at 21:37:40 +0100, Jeremy Sowden wrote:
> Control: tags 1067547 + patch
> Control: tags 1067547 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for wmweather+ (versioned as 2.19~alpha+ds-1.1) and
> am going to upload it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
I've forked the Salsa repo and pushed the changes to my fork:
https://salsa.debian.org/azazel/wmweather-plus
I note that 2.17-2 and 2.18-1 were not committed to master, and
2.19~alpha+ds-1 wasn't in the repo at all. I merged the older releases
to master and then used gbp-import-dsc to import 2.19~alpha+ds-1. Does
this look all right? May I push?
J.
> diff -Nru wmweather+-2.19~alpha+ds/debian/changelog
> wmweather+-2.19~alpha+ds/debian/changelog
> --- wmweather+-2.19~alpha+ds/debian/changelog 2022-09-06 22:02:18.0
> +0100
> +++ wmweather+-2.19~alpha+ds/debian/changelog 2024-04-18 21:14:57.0
> +0100
> @@ -1,3 +1,10 @@
> +wmweather+ (2.19~alpha+ds-1.1) UNRELEASED; urgency=medium
I fixed this before uploading.
> +
> + * Non-maintainer upload.
> + * d/patches: add patch to fix FTBFS (Closes: #1067547)
> +
> + -- Jeremy Sowden Thu, 18 Apr 2024 21:14:57 +0100
> +
> wmweather+ (2.19~alpha+ds-1) unstable; urgency=medium
>
>* Bump standards version to 4.6.1.
> diff -Nru wmweather+-2.19~alpha+ds/debian/patches/series
> wmweather+-2.19~alpha+ds/debian/patches/series
> --- wmweather+-2.19~alpha+ds/debian/patches/series1970-01-01
> 01:00:00.0 +0100
> +++ wmweather+-2.19~alpha+ds/debian/patches/series2024-04-18
> 21:14:57.0 +0100
> @@ -0,0 +1 @@
> +update-snprintf-and-vsnprintf-checks.patch
> diff -Nru
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
>
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
> ---
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
> 1970-01-01 01:00:00.0 +0100
> +++
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
> 2024-04-18 21:14:57.0 +0100
> @@ -0,0 +1,80 @@
> +Description: update snprintf and vsnprintf checks for
> + -Werror=implicit-function-declaration
> + .
> + This is the upstream fix.
> +Author: Brad Jorsch
> +Last-Update: 2024-03-23
> +Forwarded: not-needed
> +Applied-upstream: commit:393394818cf4aa9b34071297a6947409cb19d74b
> +Bug-Debian: https://bugs.debian.org/1067547
> +
> +---
> + m4/snprintf.m4 | 6 +++---
> + m4/vsnprintf.m4 | 6 +++---
> + 2 files changed, 6 insertions(+), 6 deletions(-)
> +
> +diff --git a/m4/snprintf.m4 b/m4/snprintf.m4
> +index 03567bc5931e..1131e93ce206 100644
> +--- a/m4/snprintf.m4
> b/m4/snprintf.m4
> +@@ -24,7 +24,7 @@ int snprintf(char *str, size_t size, const char *format,
> ...);
> + #endif
> + ]],
> + [[char foo[]="ABC"; snprintf(foo, 2, "%d", 12);
> +-exit((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> ++return ((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> + [x_cv_func_snprintf_size=yes],
> + [x_cv_func_snprintf_size=no],
> + [x_cv_func_snprintf_size=no])])
> +@@ -52,7 +52,7 @@ AC_CACHE_CHECK([if snprintf return value is sane],
> x_cv_func_snprintf_retval,
> + int snprintf(char *str, size_t size, const char *format, ...);
> + #endif
> + ]],
> +-[[char foo[10]; exit((snprintf(foo, 1, "%d", 9876)==4)?0:1);]])],
> ++[[char foo[10]; return ((snprintf(foo, 1, "%d", 9876)==4)?0:1);]])],
> + [x_cv_func_snprintf_retval=yes],
> + [x_cv_func_snprintf_retval=no],
> + [x_cv_func_snprintf_retval=no])])
> +@@ -79,7 +79,7 @@ AC_CACHE_CHECK([if snprintf(NULL, 0, ...) works],
> x_cv_func_snprintf_null_ok,
> + int snprintf(char *str, size_t size, const char *format, ...);
> + #endif
> + ]],
> +-[int r=snprintf(NULL, 0, "%d", 100); exit((r==3 || r==-1)?0:1);])],
> ++[int r=snprintf(NULL, 0, "%d", 100); return ((r==3 || r==-1)?0:1);])],
> + [x_cv_func_snprintf_null_ok=yes],
> + [x_cv_func_snprintf_null_ok=no],
> + [x_cv_func_snprintf_null_ok=no])])
> +diff --git a/m4/vsnprintf.m4 b/m4/vsnprintf.m4
> +index a5de274cfc00..b580f46d2fcc 100644
> +--- a/m4/vsnprintf.m4
> b/m4/vsnprintf.m4
> +@@ -37,7 +37,7 @@ int doit(char *str, size_t size, const char *format, ...){
> + }
> + ]],
> + [[char foo[]="ABC"; doit(foo, 2, "%d", 12);
> +-exit((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> ++return ((foo[0]=='1' && foo[1]=='\0' &am
Bug#1067547: wmweather+: diff for NMU version 2.19~alpha+ds-1.1
Control: tags 1067547 + patch
Control: tags 1067547 + pending
Dear maintainer,
I've prepared an NMU for wmweather+ (versioned as 2.19~alpha+ds-1.1) and
am going to upload it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
J.
diff -Nru wmweather+-2.19~alpha+ds/debian/changelog wmweather+-2.19~alpha+ds/debian/changelog
--- wmweather+-2.19~alpha+ds/debian/changelog 2022-09-06 22:02:18.0 +0100
+++ wmweather+-2.19~alpha+ds/debian/changelog 2024-04-18 21:14:57.0 +0100
@@ -1,3 +1,10 @@
+wmweather+ (2.19~alpha+ds-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * d/patches: add patch to fix FTBFS (Closes: #1067547)
+
+ -- Jeremy Sowden Thu, 18 Apr 2024 21:14:57 +0100
+
wmweather+ (2.19~alpha+ds-1) unstable; urgency=medium
* Bump standards version to 4.6.1.
diff -Nru wmweather+-2.19~alpha+ds/debian/patches/series wmweather+-2.19~alpha+ds/debian/patches/series
--- wmweather+-2.19~alpha+ds/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ wmweather+-2.19~alpha+ds/debian/patches/series 2024-04-18 21:14:57.0 +0100
@@ -0,0 +1 @@
+update-snprintf-and-vsnprintf-checks.patch
diff -Nru wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
--- wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch 1970-01-01 01:00:00.0 +0100
+++ wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch 2024-04-18 21:14:57.0 +0100
@@ -0,0 +1,80 @@
+Description: update snprintf and vsnprintf checks for
+ -Werror=implicit-function-declaration
+ .
+ This is the upstream fix.
+Author: Brad Jorsch
+Last-Update: 2024-03-23
+Forwarded: not-needed
+Applied-upstream: commit:393394818cf4aa9b34071297a6947409cb19d74b
+Bug-Debian: https://bugs.debian.org/1067547
+
+---
+ m4/snprintf.m4 | 6 +++---
+ m4/vsnprintf.m4 | 6 +++---
+ 2 files changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/m4/snprintf.m4 b/m4/snprintf.m4
+index 03567bc5931e..1131e93ce206 100644
+--- a/m4/snprintf.m4
b/m4/snprintf.m4
+@@ -24,7 +24,7 @@ int snprintf(char *str, size_t size, const char *format, ...);
+ #endif
+ ]],
+ [[char foo[]="ABC"; snprintf(foo, 2, "%d", 12);
+-exit((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
++return ((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
+ [x_cv_func_snprintf_size=yes],
+ [x_cv_func_snprintf_size=no],
+ [x_cv_func_snprintf_size=no])])
+@@ -52,7 +52,7 @@ AC_CACHE_CHECK([if snprintf return value is sane], x_cv_func_snprintf_retval,
+ int snprintf(char *str, size_t size, const char *format, ...);
+ #endif
+ ]],
+-[[char foo[10]; exit((snprintf(foo, 1, "%d", 9876)==4)?0:1);]])],
++[[char foo[10]; return ((snprintf(foo, 1, "%d", 9876)==4)?0:1);]])],
+ [x_cv_func_snprintf_retval=yes],
+ [x_cv_func_snprintf_retval=no],
+ [x_cv_func_snprintf_retval=no])])
+@@ -79,7 +79,7 @@ AC_CACHE_CHECK([if snprintf(NULL, 0, ...) works], x_cv_func_snprintf_null_ok,
+ int snprintf(char *str, size_t size, const char *format, ...);
+ #endif
+ ]],
+-[int r=snprintf(NULL, 0, "%d", 100); exit((r==3 || r==-1)?0:1);])],
++[int r=snprintf(NULL, 0, "%d", 100); return ((r==3 || r==-1)?0:1);])],
+ [x_cv_func_snprintf_null_ok=yes],
+ [x_cv_func_snprintf_null_ok=no],
+ [x_cv_func_snprintf_null_ok=no])])
+diff --git a/m4/vsnprintf.m4 b/m4/vsnprintf.m4
+index a5de274cfc00..b580f46d2fcc 100644
+--- a/m4/vsnprintf.m4
b/m4/vsnprintf.m4
+@@ -37,7 +37,7 @@ int doit(char *str, size_t size, const char *format, ...){
+ }
+ ]],
+ [[char foo[]="ABC"; doit(foo, 2, "%d", 12);
+-exit((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
++return ((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
+ [x_cv_func_vsnprintf_size=yes],
+ [x_cv_func_vsnprintf_size=no],
+ [x_cv_func_vsnprintf_size=no])])
+@@ -74,7 +74,7 @@ int doit(char *str, size_t size, const char *format, ...){
+ return r;
+ }
+ ]],
+-[[char foo[10]; exit((doit(foo, 1, "%d", 9876)==4)?0:1);]])],
++[[char foo[10]; return ((doit(foo, 1, "%d", 9876)==4)?0:1);]])],
+ [x_cv_func_vsnprintf_retval=yes],
+ [x_cv_func_vsnprintf_retval=no],
+ [x_cv_func_vsnprintf_retval=no])])
+@@ -110,7 +110,7 @@ int doit(char *str, size_t size, const char *format, ...){
+ return r;
+ }
+ ]],
+-[int r=doit(NULL, 0, "%d", 100); exit((r==3 || r==-1)?0:1);])],
++[int r=doit(NULL, 0, "%d", 100); return ((r==3 || r==-1)?0:1);])],
+ [x_cv_func_vsnprintf_null_ok=yes],
+ [x_cv_func_vsnprintf_null_ok=no],
+ [x_cv_func_vsnprintf_null_ok=no])])
+--
+2.43.0
+
signature.asc
Description: PGP signature
Bug#1066334: 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
Bug#1066334: 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#1068869: mu4e: Cannot open load file: No such file or directory, mu4e
On 2024-04-12, at 10:58:59 -0700, Xiyue Deng wrote: > Jeremy Sowden writes: > > Control: tags -1 confirmed > > > > On 2024-04-12, at 16:56:25 +0200, Clément Calmels wrote: > >> Package: mu4e > >> Version: 1.12.3-2 > >> Severity: grave > >> Justification: renders package unusable > >> > >> Dear Maintainer, > >> > >> I upgraded my Sid machine with the latest mu4e and maildir-utils > >> packages : 1.12.3-2. Emacs isn't able to find the mu4e command > >> anymore. From *Messages*: "Cannot open load file: No such file or > >> directory, mu4e" when trying to load the mu4e library (using > >> use-package). > >> > >> It seems that some files are missing (mu4e.el at least). > > > > Confirmed. Will get this fixed ASAP. Thanks for the report. > > I made a MR[1] with a potential fix. There is an alternative way to > do this (where I left a comment[2]) so would like to hear your opinion > before merging. Thanks! D'oh! Somehow I missed the fact that meson was installing the .el files, which is why I was copying them from the build directory. Thank you for your fresh eyes. :) I pushed a different fix, so I will revert that and merge yours. J. signature.asc Description: PGP signature
Bug#1068869: mu4e: Cannot open load file: No such file or directory, mu4e
Control: tags -1 confirmed On 2024-04-12, at 16:56:25 +0200, Clément Calmels wrote: > Package: mu4e > Version: 1.12.3-2 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > I upgraded my Sid machine with the latest mu4e and maildir-utils > packages : 1.12.3-2. Emacs isn't able to find the mu4e command > anymore. From *Messages*: "Cannot open load file: No such file or > directory, mu4e" when trying to load the mu4e library (using > use-package). > > It seems that some files are missing (mu4e.el at least). Confirmed. Will get this fixed ASAP. Thanks for the report. J. > Package version 1.12.3-2: > $ dpkg -L mu4e > /. > /usr > /usr/lib > /usr/lib/emacsen-common > /usr/lib/emacsen-common/packages > /usr/lib/emacsen-common/packages/compat > /usr/lib/emacsen-common/packages/compat/mu4e > /usr/lib/emacsen-common/packages/install > /usr/lib/emacsen-common/packages/install/mu4e > /usr/lib/emacsen-common/packages/remove > /usr/lib/emacsen-common/packages/remove/mu4e > /usr/share > /usr/share/doc > /usr/share/doc/mu4e > /usr/share/doc/mu4e/NEWS.Debian.gz > /usr/share/doc/mu4e/changelog.Debian.gz > /usr/share/doc/mu4e/copyright > /usr/share/emacs > /usr/share/emacs/site-lisp > /usr/share/emacs/site-lisp/elpa-src > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.12.3 > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.12.3/mu4e-autoloads.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.12.3/mu4e-config.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.12.3/mu4e-pkg.el > /usr/share/info > /usr/share/info/mu4e.info.gz > /usr/share/doc/mu4e/NEWS.org > /usr/share/doc/mu4e/README.org.gz > /usr/share/doc/mu4e/TODO.gz > /etc/emacs/site-start.d/50mu4e.el > > Package version 1.10.8-2: > $ dpkg -L mu4e > /. > /usr > /usr/lib > /usr/lib/emacsen-common > /usr/lib/emacsen-common/packages > /usr/lib/emacsen-common/packages/compat > /usr/lib/emacsen-common/packages/compat/mu4e > /usr/lib/emacsen-common/packages/install > /usr/lib/emacsen-common/packages/install/mu4e > /usr/lib/emacsen-common/packages/remove > /usr/lib/emacsen-common/packages/remove/mu4e > /usr/share > /usr/share/doc > /usr/share/doc/mu4e > /usr/share/doc/mu4e/NEWS.Debian.gz > /usr/share/doc/mu4e/changelog.Debian.gz > /usr/share/doc/mu4e/changelog.gz > /usr/share/doc/mu4e/copyright > /usr/share/emacs > /usr/share/emacs/site-lisp > /usr/share/emacs/site-lisp/elpa-src > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8 > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-actions.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-autoloads.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-bookmarks.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-compose.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-config.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-contacts.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-context.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-contrib.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-draft.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-folders.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-headers.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-helpers.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-icalendar.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-lists.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-main.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-mark.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-message.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-modeline.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-notification.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-obsolete.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-org.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-pkg.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-query-items.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-search.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-server.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-speedbar.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-update.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-vars.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-view.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e-window.el > /usr/share/emacs/site-lisp/elpa-src/mu4e-1.10.8/mu4e.el > /usr/share/info > /usr/share/info/mu4e.info.gz > /usr/share/doc/mu4e/NEWS.org > /usr/share/doc/mu4e/README.org.gz > /usr/share/doc/mu4e/TODO.gz > /etc/emacs/site-start.d/50mu4e.el > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.7.9-amd64 (SMP w/24 CPU threads; PREEMPT) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to
Bug#1068030: FTBFS on armel: undefined reference to `__atomic_load_8'
On 2024-04-09, at 15:24:28 +0100, Jeremy Sowden wrote:
> On 2024-03-30, at 02:03:57 +0500, Andrey Rakhmatullin wrote:
> > Source: maildir-utils
> > Version: 1.10.8-2
> > Severity: serious
> > Tags: ftbfs
> >
> > https://buildd.debian.org/status/fetch.php?pkg=maildir-utils=armel=1.10.8-2%2Bb2=1711722478=0
> >
> > /usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function
> > `std::__atomic_base::store(long long, std::memory_order)':
> > /usr/include/c++/13/bits/atomic_base.h:481:(.text+0xb14): undefined
> > reference
> > to `__atomic_store_8'
> > /usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function
> > `std::__atomic_base::load(std::memory_order) const':
> > /usr/include/c++/13/bits/atomic_base.h:505:(.text+0x1384): undefined
> > reference
> > to `__atomic_load_8'
>
> This is a 64-bit time_t bug. Will investigate.
gcc includes a library, libatomic.so, which supplies implementations of
atomic operations which cannot be implemented by native instructions.
On armel, this is required for 64 bit types:
$ cat test.cc
#include
#include
using namespace std;
int
main(void)
{
atomic_llong x(0);
long long y = 123;
x.store(y);
cout << x << endl;
}
$ g++ test.cc -o test
/usr/bin/ld: /tmp/ccVWAQDN.o: in function `main':
test.cc:(.text+0xe0): undefined reference to `__atomic_store_8'
/usr/bin/ld: /tmp/ccVWAQDN.o: in function `std::__atomic_base::operator long long() const':
test.cc:(.text._ZNKSt13__atomic_baseIxEcvxEv[_ZNKSt13__atomic_baseIxEcvxEv]+0x98):
undefined reference to `__atomic_load_8'
collect2: error: ld returned 1 exit status
$ g++ test.cc -o test -latomic
$ ./test
123
Thus it is now required for 64-bit `time_t`.
This doesn't appear to be documented anywhere apart from other bug
reports. May be worth broaching with upstream.
J.
signature.asc
Description: PGP signature
Bug#1068030: FTBFS on armel: undefined reference to `__atomic_load_8'
On 2024-03-30, at 02:03:57 +0500, Andrey Rakhmatullin wrote: > Source: maildir-utils > Version: 1.10.8-2 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=maildir-utils=armel=1.10.8-2%2Bb2=1711722478=0 > > /usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function > `std::__atomic_base::store(long long, std::memory_order)': > /usr/include/c++/13/bits/atomic_base.h:481:(.text+0xb14): undefined reference > to `__atomic_store_8' > /usr/bin/ld: lib/index/libmu-index.a.p/mu-indexer.cc.o: in function > `std::__atomic_base::load(std::memory_order) const': > /usr/include/c++/13/bits/atomic_base.h:505:(.text+0x1384): undefined reference > to `__atomic_load_8' This is a 64-bit time_t bug. Will investigate. J. > -- System Information: > Debian Release: trixie/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, > 'unstable'), (500, 'testing'), (101, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1067568: emacs-pdf-tools: [time_t] Remove hardcoded dependency on libpoppler-glib8
On 2024-03-23, at 20:22:53 +0100, Julian Andres Klode wrote:
> Package: emacs-pdf-tools
> Version: 1.1.0-1
> Severity: serious
> Tags: patch
> X-Debbugs-Cc: juli...@ubuntu.com
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu noble ubuntu-patch
>
> *** /tmp/tmpjxu2sdja/bug_body
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
> * Remove hardcoded libpoppler-glib8 dependency
>
> libpoppler-glib8 becomes libpoppler-glib8t64, and the dependency is no
> longer needed.
>
> Thanks for considering the patch.
>
> *** /tmp/tmpjxu2sdja/emacs-pdf-tools_1.1.0-1ubuntu1.debdiff
> diff -Nru emacs-pdf-tools-1.1.0/debian/control
> emacs-pdf-tools-1.1.0/debian/control
> --- emacs-pdf-tools-1.1.0/debian/control 2024-02-29 07:25:51.0
> +0100
> +++ emacs-pdf-tools-1.1.0/debian/control 2024-03-23 20:19:34.0
> +0100
> @@ -1,8 +1,7 @@
> Source: emacs-pdf-tools
> Section: editors
> Priority: optional
> -Maintainer: Ubuntu Developers
> -XSBC-Original-Maintainer: Debian Emacsen team
>
> +Maintainer: Debian Emacsen team
> Uploaders: Rémi Vanicat ,
> Aymeric Agon-Rambosson ,
> Build-Depends: debhelper-compat (= 13),
> @@ -30,7 +29,7 @@
>
> Package: elpa-pdf-tools-server
> Architecture: any
> -Depends: libpoppler-glib8 (>= 20.09.0~), ${misc:Depends}, ${shlibs:Depends}
> +Depends: ${misc:Depends}, ${shlibs:Depends}
> Description: server for Emacs's pdf-tools
> This package contain the server needed by elpa-pdf-tools to transform
> pdf into png to be displayed by Emacs.
Makes sense. Will apply and upload.
J.
> -- System Information:
> Debian Release: trixie/sid
> APT prefers noble
> APT policy: (500, 'noble'), (500, 'mantic-security')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> --
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer i speak de, en
signature.asc
Description: PGP signature
Bug#1060707: dh-make-elpa: autopkgtest failure with Perl 5.38: smartmatch is deprecated
On 2024-01-13, at 13:12:20 +0200, Niko Tyni wrote: > Package: dh-make-elpa > Version: 0.19.2 > Severity: serious > User: debian-p...@lists.debian.org > Usertags: perl-5.38-transition > > This package fails its autopkgtest checks with Perl 5.38 > (currently in unstable.) > > autopkgtest [11:06:58]: test test-dh-make-elpa: ---] > autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - > results - - - - - - - - - - > test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at > /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. > autopkgtest [11:06:58]: test test-dh-make-elpa: - - - - - - - - - - stderr > - - - - - - - - - - > Smartmatch is deprecated at /usr/share/perl5/DhMakeELPA/Command/make.pm > line 99. > autopkgtest [11:06:58]: summary > test-dh-make-elpaFAIL stderr: Smartmatch is deprecated at > /usr/share/perl5/DhMakeELPA/Command/make.pm line 99. I've pushed a fix to Salsa: https://salsa.debian.org/emacsen-team/dh-make-elpa/-/commit/b6840bdc3b2a02ca07a2a601deff2a3947001368 J. signature.asc Description: PGP signature
Bug#1058284: wmtv: FTBFS: configure: error: Package requirements (libv4l1) were not met
Control: reassign -1 v4l-utils On 2023-12-12, at 11:27:09 +, Jeremy Sowden wrote: > On 2023-12-12, at 09:40:04 +0100, Lucas Nussbaum wrote: > > During a rebuild of all packages in sid, your package failed to build > > on amd64. > > > > Relevant part (hopefully): > > > checking for xext... yes > > > checking for xpm... yes > > > checking for xxf86dga... yes > > > checking for xxf86vm... yes > > > checking for libv4l1... no > > > configure: error: Package requirements (libv4l1) were not met > > > > > > Package 'libjpeg', required by 'libv4lconvert', not found > > > > > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > > > installed software in a non-standard prefix. > > > > > > Alternatively, you may set the environment variables libv4l1_CFLAGS > > > and libv4l1_LIBS to avoid the need to call pkg-config. > > > See the pkg-config man page for more details. > > > tail -v -n \+0 config.log > > Not sure this is in fact a bug in wmtv: > > * wmtv requires libv4l1 > * libv4l1 privately requires libv4l2 > * libv4l2 privately requires libv4lconvert > * libv4lconvert privately requires libjpeg > > I think libv4l-dev should depend on libjpeg-dev. Will do some testing > before I reassign the bug. Yes, installing libjpeg-dev satisfies pkgconf and the wmtv build succeeds. libdvbv5-dev is also missing a dependency on libudev-dev, I believe. I've created a merge-request to add them both. Reassigning the bug to v4l-utils. J. signature.asc Description: PGP signature
Bug#1058284: wmtv: FTBFS: configure: error: Package requirements (libv4l1) were not met
On 2023-12-12, at 09:40:04 +0100, Lucas Nussbaum wrote: > Source: wmtv > Version: 0.6.7-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231212 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > checking for xext... yes > > checking for xpm... yes > > checking for xxf86dga... yes > > checking for xxf86vm... yes > > checking for libv4l1... no > > configure: error: Package requirements (libv4l1) were not met > > > > Package 'libjpeg', required by 'libv4lconvert', not found > > > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > > installed software in a non-standard prefix. > > > > Alternatively, you may set the environment variables libv4l1_CFLAGS > > and libv4l1_LIBS to avoid the need to call pkg-config. > > See the pkg-config man page for more details. > > tail -v -n \+0 config.log Not sure this is in fact a bug in wmtv: * wmtv requires libv4l1.pc * libv4l1.pc privately requires libv4l2.pc * libv4l2.pc privately requires libv4lconvert.pc * libv4lconvert.pc privately requires libjpeg.pc I think libv4l-dev should depend on libjpeg-dev. Will do some testing before I reassign the bug. J. signature.asc Description: PGP signature
Bug#1055981: wmforecast: Does not retrieve data; shows error
Control: reassign -1 libgweather4
On 2023-11-15, at 11:57:30 +0200, Yavor Doganov wrote:
> Package: wmforecast
> Version: 1.9.0-1
> Severity: grave
> X-Debbugs-Cc: Yavor Doganov
>
> Since some time (about 2 weeks, but I'm not entirely sure) wmforecast
> displays an image with a question mark along with the text "ERROR". The
> following message(s) appear on the console:
>
> $ LC_ALL=C wmforecast
> GWeather-Message: 11:51:41.964: Failed to get weather.gov point data:
> [status: 404] Not Found
> GWeather-Message: 11:52:41.353: Failed to get weather.gov point data:
> [status: 404] Not Found
> GWeather-Message: 11:53:41.349: Failed to get weather.gov point data:
> [status: 404] Not Found
>
> (process:179771): GWeather-WARNING **: 11:54:40.649: Failed to get METAR
> data: HTTP/2 Error: NO_ERROR
>
> My ~/GNUstep/Defaults/wmforecast:
> ,
> | {
> | longitude = "27,91108";
> | interval = 60;
> | text = "#20b2aa";
> | icondir = "/usr/share/wmforecast";
> | units = c;
> | background = "#00";
> | latitude = "43,211375";
> | }
> `
This is not a bug in wmforecast per se. It uses libgweather4 to
retrieve forecasts are retrieved by libgweather4 from weather.gov, and
it appears that 404's are being returned for some locations.
The example given in the API doc's at
https://www.weather.gov/documentation/services-web-api succeeds:
GET /points/39.7456,-97.0892 HTTP/1.1
Host: api.weather.gov
Accept: application/geo+json
User-Agent: (azazel.net, jer...@azazel.net)
HTTP/1.1 200 OK
Server: nginx/1.20.1
Content-Type: application/geo+json
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-Correlation-Id, X-Request-Id, X-Server-Id
X-Request-ID: 08058eeb-9934-448a-bb4d-da9735491564
X-Correlation-ID: 9922208
X-Server-ID: vm-bldr-nids-apiapp1.ncep.noaa.gov
Cache-Control: public, max-age=85382, s-maxage=120
Expires: Thu, 16 Nov 2023 12:41:45 GMT
Date: Wed, 15 Nov 2023 12:58:43 GMT
Content-Length: 3096
Connection: keep-alive
X-Edge-Request-ID: b07ff2
Vary: Accept,Feature-Flags,Accept-Language
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
{
"@context": [
"https://geojson.org/geojson-ld/geojson-context.jsonld;,
...
However, if I send your latitude and longitude, I get a 404:
GET /points/43.2113,27.911 HTTP/1.1
Host: api.weather.gov
Accept: application/geo+json
User-Agent: (azazel.net, jer...@azazel.net)
HTTP/1.1 404 Not Found
Server: nginx/1.20.1
Content-Type: application/problem+json
X-Request-ID: 2f158817-e80e-40b1-bcb0-1ef801e85f04
X-Correlation-ID: 3db7f703
X-Server-ID: vm-bldr-nids-apiapp12.ncep.noaa.gov
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: X-Correlation-Id, X-Request-Id, X-Server-Id
Pragma: no-cache
Content-Length: 304
Cache-Control: private, must-revalidate, max-age=86353
Expires: Thu, 16 Nov 2023 12:55:30 GMT
Date: Wed, 15 Nov 2023 12:56:17 GMT
Connection: keep-alive
X-Edge-Request-ID: afdb0d
Vary: Accept,Feature-Flags,Accept-Language
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload
{
"correlationId": "3db7f703",
"title": "Data Unavailable For Requested Point",
"type": "https://api.weather.gov/problems/InvalidPoint;,
"status": 404,
"detail": "Unable to provide data for requested point 43.2113,27.911",
"instance": "https://api.weather.gov/requests/3db7f703;
}
I am going to reassign this bug to libgweather4.
J.
signature.asc
Description: PGP signature
Bug#1029944: A couple of patches
Control: tags -1 upstream fixed-upstream On 2023-03-26, at 20:51:50 +0100, Jeremy Sowden wrote: > Actually, it wasn't much more work to get all the failing tests to > pass. Version 2 of the patches attached. Merged upstream: https://github.com/notroj/neon/pull/114 J. signature.asc Description: PGP signature
Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable
On 2023-09-25, at 10:31:57 +0200, Arturo Borrero Gonzalez wrote: > On 9/24/23 13:48, Salvatore Bonaccorso wrote: > > The work for bookworm has been done, but for bullseye: would you be > > able to help here and prepare the fixes? Unfortunatlly the fixes will > > not apply cleanly. If we fear to much breakage, maybe upstream can be > > convinced to help? > > > > Hi Salvatore, > > I don't think I will have a lot of time to work on this in the next few weeks. > > I'm sorry :-( I can pick it up. I took a look at the patches yesterday evening and it wasn't much work to fix them up for Bullseye. I'll run the test-suites and check for regressions. J. signature.asc Description: PGP signature
Bug#1042124: 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#1041271: maildir-utils: public shared library shipped in maildir-utils binary package
On 2023-07-16, at 20:11:30 +0100, Jeremy Sowden wrote:
> On 2023-07-16, at 13:59:43 -0300, David Bremner wrote:
> > I think that libguile-mu.* need to be either moved to a private
> > directory or to their own packages. I don't know enough about guile to
> > say which is better.
>
> I think it probably wants to go into Guile's extensions directory:
> /usr/lib/${DEB_HOST_MULTIARCH}/guile-3.0/extensions.
>
> For 1.8, I believe that will require something along the lines of:
>
> diff --git a/configure.ac b/configure.ac
> index 5e44d5d168f9..f99a5cf5c169 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -211,6 +211,7 @@ AS_IF([test "x$enable_guile" != "xno"],[
> GUILE_PKG([3.0 2.2])
> GUILE_PROGS
> GUILE_FLAGS
> + GUILE_SITE_DIR
> AC_DEFINE_UNQUOTED([GUILE_BINARY],"$GUILE",[guile binary])
> vsnarf=guile-snarf${GUILE_EFFECTIVE_VERSION}
> AC_CHECK_PROGS(GUILE_SNARF,[${vsnarf} guile-snarf], [no])
> diff --git a/guile/Makefile.am b/guile/Makefile.am
> index dd911087ded7..992e929c1fdc 100644
> --- a/guile/Makefile.am
> +++ b/guile/Makefile.am
> @@ -42,7 +42,8 @@ AM_CXXFLAGS= \
> -Wno-missing-declarations \
> -Wno-suggest-attribute=noreturn
>
> -lib_LTLIBRARIES= \
> +guile_extensionsdir = $(GUILE_EXTENSION)
> +guile_extensions_LTLIBRARIES = \
> libguile-mu.la
>
>libguile_mu_la_SOURCES=\
>
> I'll create another MR once I've tested it.
https://salsa.debian.org/emacsen-team/maildir-utils/-/merge_requests/3
J.
signature.asc
Description: PGP signature
Bug#1041271: maildir-utils: public shared library shipped in maildir-utils binary package
On 2023-07-16, at 13:59:43 -0300, David Bremner wrote:
> Package: maildir-utils
> Version: 1.8.14-2
> Severity: serious
> Justification: violates policy 8.1
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I think that libguile-mu.* need to be either moved to a private
> directory or to their own packages. I don't know enough about guile to
> say which is better.
I think it probably wants to go into Guile's extensions directory:
/usr/lib/${DEB_HOST_MULTIARCH}/guile-3.0/extensions.
For 1.8, I believe that will require something along the lines of:
diff --git a/configure.ac b/configure.ac
index 5e44d5d168f9..f99a5cf5c169 100644
--- a/configure.ac
+++ b/configure.ac
@@ -211,6 +211,7 @@ AS_IF([test "x$enable_guile" != "xno"],[
GUILE_PKG([3.0 2.2])
GUILE_PROGS
GUILE_FLAGS
+ GUILE_SITE_DIR
AC_DEFINE_UNQUOTED([GUILE_BINARY],"$GUILE",[guile binary])
vsnarf=guile-snarf${GUILE_EFFECTIVE_VERSION}
AC_CHECK_PROGS(GUILE_SNARF,[${vsnarf} guile-snarf], [no])
diff --git a/guile/Makefile.am b/guile/Makefile.am
index dd911087ded7..992e929c1fdc 100644
--- a/guile/Makefile.am
+++ b/guile/Makefile.am
@@ -42,7 +42,8 @@ AM_CXXFLAGS= \
-Wno-missing-declarations \
-Wno-suggest-attribute=noreturn
-lib_LTLIBRARIES= \
+guile_extensionsdir = $(GUILE_EXTENSION)
+guile_extensions_LTLIBRARIES = \
libguile-mu.la
libguile_mu_la_SOURCES=\
I'll create another MR once I've tested it.
J.
signature.asc
Description: PGP signature
Bug#1037765: maildir-utils: ftbfs with GCC-13
On 2023-07-15, at 12:19:47 +0100, Jeremy Sowden wrote: > On 2023-07-15, at 07:29:54 -0300, David Bremner wrote: > > Matthias Klose writes: > > > Package: src:maildir-utils > > > Version: 1.8.14-1 > > > Severity: normal > > > Tags: sid trixie > > > User: debian-...@lists.debian.org > > > Usertags: ftbfs-gcc-13 > > > > > > [This bug is targeted to the upcoming trixie release] > > > > > > Please keep this issue open in the bug tracker for the package it > > > was filed for. If a fix in another package is required, please > > > file a bug for the other package (or clone), and add a block in > > > this package. Please keep the issue open until the package can be > > > built in a follow-up test rebuild. > > > > I suspect we should probably move to a new upstream version rather > > than adding yet another patch. > > I did start looking at what would be involved and the new upstream > version 1.10 has removed the deprecated autootools-based > [build-system] which is used in the 1.8 package, so I decided to leave > alone. :) > > > However, if for some reason we want to stay with 1.8.14, it looks > > like this specific issue is fixed by upstream commit > > > >ce9446465260bd108bcf554cf503f72304f4276b > > The diff in that commit is: > > diff --git a/lib/utils/mu-error.hh b/lib/utils/mu-error.hh > index 55a8002c71e2..6472ce83b4d4 100644 > --- a/lib/utils/mu-error.hh > +++ b/lib/utils/mu-error.hh > @@ -22,6 +22,7 @@ > >#include >#include > +#include > >#include "mu-utils-format.hh" >#include > > which is all that is needed to fix the FTBFS. > > > I attach a version with conflicts resolved (although I don't know the > > codebase well enough to say if my resolution is correct). With that > > patch the code builds, but the build still fails with mu4e.info and > > mu4e-guile.info not being installed. > > > > dh_missing: warning: usr/share/info/mu-guile.info exists in debian/tmp > > but is not installed to anywhere > > dh_missing: warning: usr/share/info/mu4e.info exists in debian/tmp but > > is not installed to anywhere > > dh_missing: error: missing files, aborting > > The following debhelper tools have reported what they installed > > (with files per package) > > * dh_elpa: maildir-utils (0), mu4e (25) > > * dh_install: maildir-utils (6), mu4e (0) > > * dh_installdocs: maildir-utils (3), mu4e (0) > > * dh_installman: maildir-utils (0), mu4e (0) > > The source package in the archive contains a couple of files which are > missing from the Salsa repo: > > [azazel@ulthar:/space/azazel/tmp/maildir-utils-1.8.14] $ cat > debian/maildir-utils.info > usr/share/info/mu-* > [azazel@ulthar:/space/azazel/tmp/maildir-utils-1.8.14] $ cat > debian/mu4e.info > usr/share/info/mu4e* > > I'll create a PR to add a patch and the missing .info files. https://salsa.debian.org/emacsen-team/maildir-utils/-/merge_requests/2 J. signature.asc Description: PGP signature
Bug#1037765: maildir-utils: ftbfs with GCC-13
On 2023-07-15, at 07:29:54 -0300, David Bremner wrote:
> Matthias Klose writes:
>
> > Package: src:maildir-utils
> > Version: 1.8.14-1
> > Severity: normal
> > Tags: sid trixie
> > User: debian-...@lists.debian.org
> > Usertags: ftbfs-gcc-13
> >
> > [This bug is targeted to the upcoming trixie release]
> >
> > Please keep this issue open in the bug tracker for the package it
> > was filed for. If a fix in another package is required, please
> > file a bug for the other package (or clone), and add a block in this
> > package. Please keep the issue open until the package can be built in
> > a follow-up test rebuild.
>
> I suspect we should probably move to a new upstream version rather than
> adding yet another patch.
I did start looking at what would be involved and the new upstream
version 1.10 has removed the deprecated autootools-based which is used
in the 1.8 package, so I decided to leave alone. :)
> However, if for some reason we want to stay with 1.8.14, it looks like
> this specific issue is fixed by upstream commit
>
>ce9446465260bd108bcf554cf503f72304f4276b
The diff in that commit is:
diff --git a/lib/utils/mu-error.hh b/lib/utils/mu-error.hh
index 55a8002c71e2..6472ce83b4d4 100644
--- a/lib/utils/mu-error.hh
+++ b/lib/utils/mu-error.hh
@@ -22,6 +22,7 @@
#include
#include
+#include
#include "mu-utils-format.hh"
#include
which is all that is needed to fix the FTBFS.
> I attach a version with conflicts resolved (although I don't know the
> codebase well enough to say if my resolution is correct). With that
> patch the code builds, but the build still fails with mu4e.info and
> mu4e-guile.info not being installed.
>
> dh_missing: warning: usr/share/info/mu-guile.info exists in debian/tmp
> but is not installed to anywhere
> dh_missing: warning: usr/share/info/mu4e.info exists in debian/tmp but is
> not installed to anywhere
> dh_missing: error: missing files, aborting
> The following debhelper tools have reported what they installed
> (with files per package)
> * dh_elpa: maildir-utils (0), mu4e (25)
> * dh_install: maildir-utils (6), mu4e (0)
> * dh_installdocs: maildir-utils (3), mu4e (0)
> * dh_installman: maildir-utils (0), mu4e (0)
>
>
The source package in the archive contains a couple of files which are
missing from the Salsa repo:
[azazel@ulthar:/space/azazel/tmp/maildir-utils-1.8.14] $ cat
debian/maildir-utils.info
usr/share/info/mu-*
[azazel@ulthar:/space/azazel/tmp/maildir-utils-1.8.14] $ cat debian/mu4e.info
usr/share/info/mu4e*
I'll create a PR to add a patch and the missing .info files.
J.
> From: =?utf-8?q?Arsen_Arsenovi=C4=87?=
> Date: Sat, 21 Jan 2023 19:39:09 +0100
> Subject: mu-error: Add missing include
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
>
> GCC 13s libstdc++ reduced its dependency on some headers like , so
> it's
> no longer transitively included through various headers. Include it
> explicitly.
>
> See also: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
>
> ../lib/utils/mu-error.hh:36:26: error: ‘uint32_t’ does not name a type
> 36 | static constexpr uint32_t SoftError = 1 << 23;
> | ^~~~
> ---
> lib/utils/mu-error.hh | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/lib/utils/mu-error.hh b/lib/utils/mu-error.hh
> index c67fc5a..d3e2fc4 100644
> --- a/lib/utils/mu-error.hh
> +++ b/lib/utils/mu-error.hh
> @@ -21,8 +21,10 @@
> #define MU_ERROR_HH__
>
> #include
> +#include
> +#include
> +
> #include "mu-utils-format.hh"
> -#include "mu-util.h"
> #include
>
> namespace Mu {
> @@ -160,11 +162,18 @@ struct Error final : public std::exception {
>* @param err GError** (or NULL)
>*/
> void fill_g_error(GError **err) const noexcept{
> - g_set_error(err, MU_ERROR_DOMAIN, static_cast(code_),
> + g_set_error(err, error_quark(), static_cast(code_),
> "%s", what_.c_str());
> }
>
> private:
> + static inline GQuark error_quark (void) {
> + static GQuark error_domain = 0;
> + if (G_UNLIKELY(error_domain == 0))
> + error_domain = g_quark_from_static_string("mu-error-quark");
> + return error_domain;
> + }
> +
> const Code code_;
> std::string what_;
> };
signature.asc
Description: PGP signature
Bug#1034704: xtables-addons-dkms fails to build
Control: severity -1 wishlist Control: tags -1 + wontfix - ftbfs On 2023-04-22, at 04:08:29 +, Bruce Mitchell wrote: > root@sondetracker:/etc/init.d# apt-get install xtables-addons-dkms > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > Recommended packages: > linux-headers > The following NEW packages will be installed: > xtables-addons-dkms > 0 upgraded, 1 newly installed, 0 to remove and 66 not upgraded. > Need to get 66.4 kB of archives. > After this operation, 316 kB of additional disk space will be used. > Get:1 http://deb.debian.org/debian bullseye/main armel xtables-addons-dkms > all 3.13-1+deb11u1 [66.4 kB] > Fetched 66.4 kB in 0s (212 kB/s) > Selecting previously unselected package xtables-addons-dkms. > (Reading database ... 41444 files and directories currently installed.) > Preparing to unpack .../xtables-addons-dkms_3.13-1+deb11u1_all.deb ... > Unpacking xtables-addons-dkms (3.13-1+deb11u1) ... > Setting up xtables-addons-dkms (3.13-1+deb11u1) ... > Loading new xtables-addons-3.13 DKMS files... > Building for 6.2.7-kirkwood-tld-1 > Building initial module for 6.2.7-kirkwood-tld-1 > Error! Build of xt_ACCOUNT.ko failed for: 6.2.7-kirkwood-tld-1 (armv5tel) > Make sure the name of the generated module is correct and at the root of the > build directory, or consult make.log in the build directory > /var/lib/dkms/xtables-addons/3.13/build/ for more information. > dpkg: error processing package xtables-addons-dkms (--configure): > installed xtables-addons-dkms package post-installation script subprocess > returned error exit status 7 > Errors were encountered while processing: > xtables-addons-dkms > E: Sub-process /usr/bin/dpkg returned an error code (1) The version of xtables-addons in Bullseye (3.13-1+deb11u1) is not compatible with linux 6.2, so DKMS fails when it tries to compile the kernel modules for your kernel version (6.2.7-kirkwood-tld-1). Since that is not an official Debian Bullseye kernel package, I'm going to tag the bug-report "wontfix" and close it. Support for 6.2 was added to xtables-addons in a later version and will be available in the next Debian release, Bookworm. J. signature.asc Description: PGP signature
Bug#1029944: A couple of patches
Actually, it wasn't much more work to get all the failing tests to
pass. Version 2 of the patches attached.
J.
From 1f6b8e55807794c2466603116ae8ba9e6a50919a Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Sun, 26 Mar 2023 14:49:09 +0100
Subject: [PATCH v2 1/2] Use ipv6 lookback address if ipv4 is not available
Note that the `bind_local` parameter of `spawn_server_addr` is now
ignored. It wasn't actually possible to set `hn_addr`, so passing `0`
would never have worked anyway.
---
test/common/child.c | 160 +---
test/common/child.h | 4 ++
test/utils.c| 5 +-
3 files changed, 143 insertions(+), 26 deletions(-)
diff --git a/test/common/child.c b/test/common/child.c
index 872fbdaddf4f..5c480def6c44 100644
--- a/test/common/child.c
+++ b/test/common/child.c
@@ -43,6 +43,10 @@
#include
#include
+#include
+#include
+#include
+
#include "ne_socket.h"
#include "ne_utils.h"
#include "ne_string.h"
@@ -50,14 +54,23 @@
#include "tests.h"
#include "child.h"
+#ifndef NI_MAXHOST
+#define NI_MAXHOST 1025
+#endif
+
static pid_t child = 0;
int clength;
-static struct in_addr lh_addr, hn_addr;
-
static int have_lh_addr;
+static union {
+ struct sockaddr_in in;
+ struct sockaddr_in6 in6;
+} lh_sockaddr;
+static int lh_family = AF_UNSPEC;
+static char lh_name[NI_MAXHOST];
+
const char *want_header = NULL;
got_header_fn got_header = NULL;
char *local_hostname = NULL;
@@ -72,13 +85,98 @@ char *local_hostname = NULL;
int lookup_localhost(void)
{
-/* this will break if a system is set up so that `localhost' does
- * not resolve to 127.0.0.1, but... */
-lh_addr.s_addr = inet_addr("127.0.0.1");
+struct ifaddrs *ifaddr;
+
+if (have_lh_addr)
+return OK;
+
+if (getifaddrs() == -1)
+goto err_use_ipv4;
+
+for (struct ifaddrs *ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
+if (ifa->ifa_addr == NULL)
+continue;
+
+if (strcmp(ifa->ifa_name, "lo") != 0)
+continue;
+
+if (ifa->ifa_addr->sa_family != AF_INET &&
+ifa->ifa_addr->sa_family != AF_INET6)
+continue;
+
+if (getnameinfo(ifa->ifa_addr,
+ifa->ifa_addr->sa_family == AF_INET
+? sizeof(struct sockaddr_in)
+: sizeof(struct sockaddr_in6),
+lh_name, sizeof lh_name,
+NULL, 0,
+NI_NUMERICHOST))
+continue;
+
+memcpy(_sockaddr, ifa->ifa_addr,
+ ifa->ifa_addr->sa_family == AF_INET
+ ? sizeof(lh_sockaddr.in)
+ : sizeof(lh_sockaddr.in6));
+
+lh_family = ifa->ifa_addr->sa_family;
+
+if (lh_family == AF_INET)
+break;
+}
+
+freeifaddrs(ifaddr);
+
+err_use_ipv4:
+
+if (lh_family == AF_UNSPEC) {
+lh_family = AF_INET;
+strcpy(lh_name, "127.0.0.1");
+lh_sockaddr.in.sin_family = lh_family;
+lh_sockaddr.in.sin_addr.s_addr = inet_addr(lh_name);
+}
+
have_lh_addr = 1;
return OK;
}
+int
+get_lh_family(void)
+{
+if (!have_lh_addr)
+lookup_localhost();
+
+return lh_family;
+}
+
+const char *
+get_lh_addr(void)
+{
+if (!have_lh_addr)
+lookup_localhost();
+
+return lh_name;
+}
+
+ne_inet_addr *
+get_lh_inet_addr(void)
+{
+ne_iaddr_type type;
+unsigned char *raw;
+
+if (!have_lh_addr)
+lookup_localhost();
+
+if (lh_family == AF_INET) {
+type = ne_iaddr_ipv4;
+raw = (unsigned char *) _sockaddr.in.sin_addr.s_addr;
+} else {
+type = ne_iaddr_ipv6;
+raw = lh_sockaddr.in6.sin6_addr.s6_addr;
+}
+
+return ne_iaddr_make(type, raw);
+}
+
int lookup_hostname(void)
{
char buf[BUFSIZ];
@@ -101,19 +199,26 @@ int lookup_hostname(void)
return OK;
}
-static int do_listen(struct in_addr addr, int port)
+static int do_listen(int port)
{
-int ls = socket(AF_INET, SOCK_STREAM, 0);
-struct sockaddr_in saddr = {0};
+int ls = socket(lh_family, SOCK_STREAM, 0);
+struct sockaddr *saddr;
+socklen_t saddrlen;
int val = 1;
setsockopt(ls, SOL_SOCKET, SO_REUSEADDR, (void *), sizeof(int));
-
-saddr.sin_addr = addr;
-saddr.sin_port = htons(port);
-saddr.sin_family = AF_INET;
-if (bind(ls, (struct sockaddr *), sizeof(saddr))) {
+if (lh_family == AF_INET) {
+ lh_sockaddr.in.sin_port = htons(port);
+ saddr = (struct sockaddr *) _sockaddr.in;
+ saddrlen = sizeof(lh_sockaddr.in);
+} else {
+ lh_sockaddr.in6.sin6_port = htons(port);
+ saddr = (struct sockaddr *) _sockaddr.in6;
+ saddrlen = sizeof(lh_sockaddr.in6);
+}
+
+if (bind(ls, saddr, saddrlen)) {
printf("bind failed: %s\n&qu
Bug#1029944: A couple of patches
9 passed
string-tests.. 31/32 SKIPPED - strhash_sha_512_256 (SHA-2-512/256 not
supported)
string-tests.. 31/32 passed (1 skipped)
socket 10/47 SKIPPED - addr_connect
socket 11/47 SKIPPED - addr_peer
socket 36/47 SKIPPED - prebind
socket 44/47 passed (3 skipped)
session... 8/ 8 passed
request... 82/92 SKIPPED - local_addr
request... 84/92 SKIPPED - addrlist
request... 90/92 passed (2 skipped)
auth.. 9/21 SKIPPED - digest_sha512_256 (SHA-512/256 not
supported)
auth.. 20/21 passed (1 skipped)
basic. 11/11 passed
stubs. 1/ 1 passed
redirect.. 6/ 6 passed
socket-ssl 11/48 SKIPPED - addr_connect
socket-ssl 12/48 SKIPPED - addr_peer
socket-ssl 37/48 SKIPPED - prebind
socket-ssl 45/48 passed (3 skipped)
ssl... 13/63 WARNING: no friendly name given
ssl... 62/63 WARNING: NSS required for PKCS#11 testing
ssl... 62/63 SKIPPED - pkcs11
ssl... 63/63 WARNING: NSS required for PKCS#11 testing
ssl... 63/63 SKIPPED - pkcs11_dsa
ssl... 61/63 passed (2 skipped) (3 warnings)
compress.. 22/22 passed
xml... 5/ 5 passed
xmlreq 3/ 3 passed
oldacl 4/ 4 passed
acl3744... 4/ 4 passed
props. 7/ 7 passed
lock.. 16/16 passed
make[2]: Leaving directory
'/space/azazel/tmp/neon27/debian/build-tree/neon-gnutls/test'
[...]
J.
From aaa0f2d4f6f50878e9320c29a920ae2aa4830b76 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Sun, 26 Mar 2023 14:49:09 +0100
Subject: [PATCH 1/2] Use ipv6 lookback address if ipv4 is not available
Note that the `bind_local` parameter of `spawn_server_addr` is now
ignored. It wasn't actually possible to set `hn_addr`, so passing `0`
would never have worked anyway.
---
test/common/child.c | 134
test/common/child.h | 3 +
test/utils.c| 5 +-
3 files changed, 116 insertions(+), 26 deletions(-)
diff --git a/test/common/child.c b/test/common/child.c
index 872fbdaddf4f..7ff7ba8fe67a 100644
--- a/test/common/child.c
+++ b/test/common/child.c
@@ -43,6 +43,10 @@
#include
#include
+#include
+#include
+#include
+
#include "ne_socket.h"
#include "ne_utils.h"
#include "ne_string.h"
@@ -50,14 +54,23 @@
#include "tests.h"
#include "child.h"
+#ifndef NI_MAXHOST
+#define NI_MAXHOST 1025
+#endif
+
static pid_t child = 0;
int clength;
-static struct in_addr lh_addr, hn_addr;
-
static int have_lh_addr;
+static union {
+ struct sockaddr_in in;
+ struct sockaddr_in6 in6;
+} lh_sockaddr;
+static int lh_family = AF_UNSPEC;
+static char lh_name[NI_MAXHOST];
+
const char *want_header = NULL;
got_header_fn got_header = NULL;
char *local_hostname = NULL;
@@ -72,13 +85,72 @@ char *local_hostname = NULL;
int lookup_localhost(void)
{
-/* this will break if a system is set up so that `localhost' does
- * not resolve to 127.0.0.1, but... */
-lh_addr.s_addr = inet_addr("127.0.0.1");
+struct ifaddrs *ifaddr;
+
+if (getifaddrs() == -1)
+ goto err_return_ipv4;
+
+for (struct ifaddrs *ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
+ if (ifa->ifa_addr == NULL)
+ continue;
+
+ if (strcmp(ifa->ifa_name, "lo") != 0)
+ continue;
+
+ if (ifa->ifa_addr->sa_family != AF_INET &&
+ ifa->ifa_addr->sa_family != AF_INET6)
+ continue;
+
+ if (getnameinfo(ifa->ifa_addr,
+ ifa->ifa_addr->sa_family == AF_INET
+ ? sizeof(struct sockaddr_in)
+ : sizeof(struct sockaddr_in6),
+ lh_name, sizeof lh_name,
+ NULL, 0,
+ NI_NUMERICHOST))
+ continue;
+
+ memcpy(_sockaddr, ifa->ifa_addr,
+ ifa->ifa_addr->sa_family == AF_INET
+ ? sizeof(lh_sockaddr.in)
+ : sizeof(lh_sockaddr.in6));
+
+ lh_family = ifa->ifa_addr->sa_family;
+
+ if (lh_family == AF_INET)
+ break;
+}
+
+freeifaddrs(ifaddr);
+
+err_return_ipv4:
+
+if (lh_family == AF_UNSPEC) {
+ lh_family = AF_INET;
+ strcpy(lh_name, "127.0.0.1");
+ lh_sockaddr.in.sin_family = lh_family;
+ lh_sockaddr.in.sin_addr.s_addr = inet_addr(lh_name);
+}
+
have_lh_addr = 1;
return OK;
}
+const char *
+get_lo_addr(void)
+{
+if (!have_lh_addr)
+ lookup_localhost();
+
+return lh_name;
+}
+
+int
+get_lo_family(void)
+{
+return lh_family;
+}
+
int lookup_hostname(void)
{
char buf[BUFSIZ];
@@ -101,19 +173,26 @@ int lookup_hostname(void)
return OK;
}
-static int do_listen(struct in_addr addr, int port)
+static int do_listen(int port)
{
-int ls = socke
Bug#1031943: [pkg-netfilter-team] Bug#1031943: Should we do something?
On 2023-03-23, at 15:58:45 +0100, Alberto Molina Coballes wrote: > I agree with Arturo, the proposed change should be harmless, but we > were not able to reproduce the issue in any of the test performed so I > was thinking to lower the severity and apply the patch but don't ask > to be included in bookworm. Sounds good to me. J. signature.asc Description: PGP signature
Bug#1031943: ebtables: symlink removal removal code in the postinst does not seem to be working
On 2023-02-25, at 20:17:34 +0200, Adrian Bunk wrote: > Package: ebtables > Version: 2.0.11-5 > Severity: serious > > ... > Setting up ebtables (2.0.11-5) ... > update-alternatives: using /usr/sbin/ebtables-legacy to provide > /usr/sbin/ebtables (ebtables) in auto mode > update-alternatives: error: cannot stat file '/usr/sbin/ebtables': Too many > levels of symbolic links > dpkg: error processing package ebtables (--configure): > ... > > > This is due to (with merged /usr): > lrwxrwxrwx 1 root root 18 Apr 6 2022 /sbin/ebtables -> /usr/sbin/ebtables > lrwxrwxrwx 1 root root 26 Apr 6 2022 /sbin/ebtables-restore -> > /usr/sbin/ebtables-restore > lrwxrwxrwx 1 root root 23 Apr 6 2022 /sbin/ebtables-save -> > /usr/sbin/ebtables-save > > > Adding "set -x" in /var/lib/dpkg/info/ebtables.postinst shows: > ... > + LIST=ebtables ebtables-save ebtables-restore > + [ -e /sbin/ebtables ] > + [ -e /sbin/ebtables-save ] > + [ -e /sbin/ebtables-restore ] > + [ configure = configure ] > ... > > Using -h instead of -e works: > ... > + LIST=ebtables ebtables-save ebtables-restore > + [ -h /sbin/ebtables ] > + readlink /sbin/ebtables > + [ /usr/sbin/ebtables = /usr/sbin/ebtables ] > + rm /sbin/ebtables > + [ -h /sbin/ebtables-save ] > + readlink /sbin/ebtables-save > + [ /usr/sbin/ebtables-save = /usr/sbin/ebtables-save ] > + rm /sbin/ebtables-save > + [ -h /sbin/ebtables-restore ] > + readlink /sbin/ebtables-restore > + [ /usr/sbin/ebtables-restore = /usr/sbin/ebtables-restore ] > + rm /sbin/ebtables-restore > + [ configure = configure ] > ... Thanks for the report. I've no objection to changing the `-e` test to `-h`, but I should like to understand what is going wrong, and I haven't been able to reproduce it. I believe that the postinst `-e` tests ought only to fail if the sym-links are broken. In conjunction with the fact that update-alternatives was complaining about not being able to stat /usr/sbin/ebtables, this suggests to me that the failing tests are symptomatic of another underlying problem. Given that the postinst script was trying and failing to remove existing sym-links, I take it that you already had ebtables installed and were upgrading to 2.0.11-5. Here's what I see in after initially installing ebtables (2.0.11-4+b1) in a Bullseye chroot without merged /usr: $ ls -l /etc/alternatives/ebtables* /sbin/ebtables* /usr/sbin/ebtables* lrwxrwxrwx 1 root root25 Feb 26 09:14 /etc/alternatives/ebtables -> /usr/sbin/ebtables-legacy* lrwxrwxrwx 1 root root33 Feb 26 09:14 /etc/alternatives/ebtables-restore -> /usr/sbin/ebtables-legacy-restore* lrwxrwxrwx 1 root root30 Feb 26 09:14 /etc/alternatives/ebtables-save -> /usr/sbin/ebtables-legacy-save* lrwxrwxrwx 1 root root18 Feb 26 09:14 /sbin/ebtables -> /usr/sbin/ebtables* lrwxrwxrwx 1 root root26 Feb 26 09:14 /sbin/ebtables-restore -> /usr/sbin/ebtables-restore* lrwxrwxrwx 1 root root23 Feb 26 09:14 /sbin/ebtables-save -> /usr/sbin/ebtables-save* lrwxrwxrwx 1 root root26 Feb 26 09:14 /usr/sbin/ebtables -> /etc/alternatives/ebtables* -rwxr-xr-x 1 root root 14600 Jun 6 2020 /usr/sbin/ebtables-legacy* -rwxr-xr-x 1 root root 14784 Jun 6 2020 /usr/sbin/ebtables-legacy-restore* -rwxr-xr-x 1 root root 1677 Jun 6 2020 /usr/sbin/ebtables-legacy-save* lrwxrwxrwx 1 root root34 Feb 26 09:14 /usr/sbin/ebtables-restore -> /etc/alternatives/ebtables-restore* lrwxrwxrwx 1 root root31 Feb 26 09:14 /usr/sbin/ebtables-save -> /etc/alternatives/ebtables-save* -rwxr-xr-x 1 root root 14800 Jun 6 2020 /usr/sbin/ebtablesd* -rwxr-xr-x 1 root root 14672 Jun 6 2020 /usr/sbin/ebtablesu* This includes the three sym-links from /sbin to /usr/sbin you list above and they resolve correctly. For example: * /sbin/ebtables -> /usr/sbin/ebtables * /usr/sbin/ebtables -> /etc/alternatives/ebtables * /etc/alternatives/ebtables -> /usr/sbin/ebtables-legacy With merged /usr (whether by creating the chroot with `debootstrap --merged-usr`, installing the usrmerge package before installing ebtables, or installing usrmerge after ebtables), I see the following: $ ls -l /etc/alternatives/ebtables* /sbin /sbin/ebtables* /usr/sbin/ebtables* lrwxrwxrwx 1 root root25 Feb 26 09:14 /etc/alternatives/ebtables -> /usr/sbin/ebtables-legacy* lrwxrwxrwx 1 root root33 Feb 26 09:14 /etc/alternatives/ebtables-restore -> /usr/sbin/ebtables-legacy-restore* lrwxrwxrwx 1 root root30 Feb 26 09:14 /etc/alternatives/ebtables-save -> /usr/sbin/ebtables-legacy-save* lrwxrwxrwx 1 root root 8 Feb 26 09:17 /sbin -> usr/sbin/ lrwxrwxrwx 1 root root26 Feb 26 09:14 /sbin/ebtables -> /etc/alternatives/ebtables* -rwxr-xr-x 1 root root 14600 Jun 6 2020 /sbin/ebtables-legacy* -rwxr-xr-x 1 root root 14784 Jun 6 2020 /sbin/ebtables-legacy-restore* -rwxr-xr-x 1 root root 1677 Jun 6 2020 /sbin/ebtables-legacy-save* lrwxrwxrwx 1 root root34 Feb 26 09:14
Bug#973990: recap
On 2023-02-01, at 20:04:22 +0200, Vincas Dargis wrote: > On Tue, 31 Jan 2023 23:41:54 +0000 Jeremy Sowden wrote: > > However, Vincas Dargis, the reporter, observed that shorewall worked > > with Linux 5.8 and did not with 5.9 and proposed #972454 as the culprit: > > I completely forgot that I wrote that bug in 2020... > > Anyway, shorewall works now: > > ``` > $ LC_ALL=C sudo shorewall status > Shorewall 5.2.8 Status at vinco - Wed Feb 1 20:01:08 EET 2023 > > Shorewall is running > State:Started Wed Feb 1 19:57:54 EET 2023 from /etc/shorewall/ > (/var/lib/shorewall/firewall compiled 2023 m. vasario 01 d. 19:56:59 EET by > Shorewall version 5.2.8 > ``` Cool. I shall close the bug then. J. signature.asc Description: PGP signature
Bug#973990: #973990: recap
I think there may be some confusion about where the problem lies with this bug. Let me summarize my understanding. The original bug-report was created against shorewall because shorewall had stopped working: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973990#5 However, Vincas Dargis, the reporter, observed that shorewall worked with Linux 5.8 and did not with 5.9 and proposed #972454 as the culprit: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973990#15 On that basis, I reassigned the report to xtables-addons and closed it, since Linux 5.9 support was added in a later version of xtables-addons: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973990#26 However, the bug was reopened by Vincas because even with the latest version of xtables-addons (3.23-1), shorewall is still not working correctly. I believe, therefore, that the failure of xtables-addons to build with Linux 5.9 was merely coincidental, and so we can rule out it as the cause of the bug and should assign the bug back to shorewall. J. signature.asc Description: PGP signature
Bug#1012613: nftables: upgrade stops but does not start service
On 2022-06-19, at 13:48:59 +0200, Arturo Borrero Gonzalez wrote:
> On Fri, 10 Jun 2022 12:21:37 +0200 Christian Göttsche wrote:
> > Package: nftables
> > Version: 1.0.4-1
> > Severity: serious
> >
> > Dear Maintainer,
> >
> > upgrades of nftables stop the service but do not start it (even if the
> > service is actually enabled).
> > This can lead to lockouts, e.g. when using special rules for ssh access.
> >
> >
> > nft.preinst:
> >
> > #!/bin/sh
> > set -e
> > # Automatically added by dh_installsystemd/13.7.1
> > if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d
> > /run/systemd/system ] ; then
> >deb-systemd-invoke stop 'nftables.service' >/dev/null || true
> > fi
> > # End automatically added section
> >
> >
> > nft.postinst:
> >
> > #!/bin/sh
> > set -e
> > # Automatically added by dh_installsystemd/13.7.1
> > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
> > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
> >if deb-systemd-helper debian-installed 'nftables.service'; then
> ># This will only remove masks created by d-s-h on package
> > removal.
> >deb-systemd-helper unmask 'nftables.service' >/dev/null ||
> > true
> >
> >if deb-systemd-helper --quiet was-enabled
> > 'nftables.service'; then
> ># Create new symlinks, if any.
> >deb-systemd-helper enable 'nftables.service'
> > >/dev/null || true
> >fi
> >fi
> >
> ># Update the statefile to add new symlinks (if any), which need to
> > be cleaned
> ># up on purge. Also remove old symlinks.
> >deb-systemd-helper update-state 'nftables.service' >/dev/null || true
> > fi
> > # End automatically added section
>
> I confirmed this can be a problem:
>
> [...]
>
> @Alberto, @Jeremy,
>
> It seems to me like we need to play with the dh_installsystemd
> --no-restart-after-upgrade option, but don't have time to figure out the
> right logic.
>
> I'm currently unable to handle this. Could you please take a look?
Passing `--restart-after-upgrade` does the trick:
diff -u nftables_1.0.4-1/postinst nftables_1.0.4-2/postinst
--- nftables_1.0.4-1/postinst 2022-06-07 23:59:59.0 +0100
+++ nftables_1.0.4-2/postinst 2022-06-19 18:04:19.0 +0100
@@ -17,3 +17,13 @@
deb-systemd-helper update-state 'nftables.service' >/dev/null || true
fi
# End automatically added section
+# Automatically added by dh_installsystemd/13.7.1
+if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
+ if [ -z "${DPKG_ROOT:-}" ] && [ -d /run/systemd/system ]; then
+ systemctl --system daemon-reload >/dev/null || true
+ if [ -n "$2" ]; then
+ deb-systemd-invoke try-restart 'nftables.service'
>/dev/null || true
+ fi
+ fi
+fi
+# End automatically added section
I've pushed that and a few other changes to Salsa.
J.
signature.asc
Description: PGP signature
Bug#1012613: nftables: upgrade stops but does not start service
On 2022-06-19, at 13:48:59 +0200, Arturo Borrero Gonzalez wrote:
> On Fri, 10 Jun 2022 12:21:37 +0200 Christian Göttsche wrote:
> > Package: nftables
> > Version: 1.0.4-1
> > Severity: serious
> >
> > Dear Maintainer,
> >
> > upgrades of nftables stop the service but do not start it (even if the
> > service is actually enabled).
> > This can lead to lockouts, e.g. when using special rules for ssh access.
> >
> >
> > nft.preinst:
> >
> > #!/bin/sh
> > set -e
> > # Automatically added by dh_installsystemd/13.7.1
> > if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d
> > /run/systemd/system ] ; then
> >deb-systemd-invoke stop 'nftables.service' >/dev/null || true
> > fi
> > # End automatically added section
> >
> >
> > nft.postinst:
> >
> > #!/bin/sh
> > set -e
> > # Automatically added by dh_installsystemd/13.7.1
> > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
> > "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
> >if deb-systemd-helper debian-installed 'nftables.service'; then
> ># This will only remove masks created by d-s-h on package
> > removal.
> >deb-systemd-helper unmask 'nftables.service' >/dev/null ||
> > true
> >
> >if deb-systemd-helper --quiet was-enabled
> > 'nftables.service'; then
> ># Create new symlinks, if any.
> >deb-systemd-helper enable 'nftables.service'
> > >/dev/null || true
> >fi
> >fi
> >
> ># Update the statefile to add new symlinks (if any), which need to
> > be cleaned
> ># up on purge. Also remove old symlinks.
> >deb-systemd-helper update-state 'nftables.service' >/dev/null || true
> > fi
> > # End automatically added section
>
> I confirmed this can be a problem:
>
> [...]
>
> @Alberto, @Jeremy,
>
> It seems to me like we need to play with the dh_installsystemd
> --no-restart-after-upgrade option, but don't have time to figure out the
> right logic.
>
> I'm currently unable to handle this. Could you please take a look?
Yup.
J.
signature.asc
Description: PGP signature
Bug#1009403: pmacct: FTBFS: configure: error: Package requirements (libnetfilter_log >= 1) were not met
On 2022-05-11, at 16:46:22 +0300, Adrian Bunk wrote: > On Tue, Apr 12, 2022 at 08:23:12PM +0200, Lucas Nussbaum wrote: > > Source: pmacct > > Version: 1.7.6-2 > > Severity: serious > > Justification: FTBFS > > Tags: bookworm sid ftbfs > > User: lu...@debian.org > > Usertags: ftbfs-20220412 ftbfs-bookworm > > > > Hi, > > > > During a rebuild of all packages in sid, your package failed to build > > on amd64. > > > > > > Relevant part (hopefully): > > > checking for uint32_t... yes > > > checking for uint16_t... yes > > > checking for uint8_t... yes > > > checking whether to enable NFLOG support... yes > > > checking for libnetfilter_log >= 1... no > > > configure: error: Package requirements (libnetfilter_log >= 1) were not > > > met > > > > > > Package 'libnfnetlink', required by 'libnetfilter_log', not found > >... > > This is caused by a regression in libnetfilter-log-dev, which lost the > dependencies on the packages needed for its pkg-config file: > > $ pkg-config --cflags libnetfilter_log > Package libnfnetlink was not found in the pkg-config search path. > Perhaps you should add the directory containing `libnfnetlink.pc' > to the PKG_CONFIG_PATH environment variable > Package 'libnfnetlink', required by 'libnetfilter_log', not found Whoops. Mea culpa. I will restore the dependencies. J. signature.asc Description: PGP signature
Bug#997281: Fixed Upstream
This was fixed in the xawtv4 code-base earlier this year. The commit,
rebased on to the xawtv3 code-base, is attached.
J.
From 4bf2b3966eecad32b47472065706560f31314a92 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab
Date: Tue, 17 Aug 2021 10:46:22 +0200
Subject: [PATCH] Replace sys_siglist with strsignal
This is needed in order to compile with newer glibc versions.
Signed-off-by: Mauro Carvalho Chehab
---
console/fbtools.c | 2 +-
console/record.c | 2 +-
x11/rootv.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/console/fbtools.c b/console/fbtools.c
index 9f876df32dac..07739ff687ec 100644
--- a/console/fbtools.c
+++ b/console/fbtools.c
@@ -520,6 +520,6 @@ fb_catch_exit_signals(void)
/* cleanup */
fb_cleanup();
-fprintf(stderr,"Oops: %s\n",sys_siglist[termsig]);
+fprintf(stderr,"Oops: %s\n",strsignal(termsig));
exit(42);
}
diff --git a/console/record.c b/console/record.c
index 685221b4b5ae..90f0c852bb08 100644
--- a/console/record.c
+++ b/console/record.c
@@ -429,7 +429,7 @@ ctrlc(int signal)
{
if (verbose)
fprintf(stderr,"\n%s - exiting\n",
- sys_siglist[signal]);
+ strsignal(signal));
stop = 1;
}
diff --git a/x11/rootv.c b/x11/rootv.c
index 60a840641e33..4bf458b227a0 100644
--- a/x11/rootv.c
+++ b/x11/rootv.c
@@ -133,7 +133,7 @@ catch_sig(int signal)
termsig = signal;
if (verbose)
fprintf(stderr,"received signal %d [%s]\n",
- termsig,sys_siglist[termsig]);
+ termsig,strsignal(termsig));
}
static void usage(FILE *fp)
@@ -422,7 +422,7 @@ main(int argc, char *argv[])
}
if (verbose && termsig)
fprintf(stderr,"exiting on signal %d [%s]\n",
- termsig,sys_siglist[termsig]);
+ termsig,strsignal(termsig));
if (do_mute && have_mute)
XvSetPortAttribute(dpy,port,XV_MUTE,1);
XvStopVideo(dpy,port,win);
--
2.33.0
signature.asc
Description: PGP signature
Bug#984260: Fixed upstream
Upstream has removed all the dynamic exception specfications. I've created a merge-request to add the upstream patch to the Debian Salsa repo. J. signature.asc Description: PGP signature
Bug#978891: 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
Bug#977308: 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
Bug#975376: [pkg-netfilter-team] Bug#975376: Fails to build with Linux 5.9.9 because of change in ip_route_me_harder()
On 2020-11-21, at 11:23:36 +0100, Sven Hartge wrote: > Package: xtables-addons-dkms > Version: 3.11-1 > Severity: grave > > Hi! > > Kernel 5.9.9 changes ip_route_me_harder() with commit > 46d6c5ae953cc0be38efd0e469284df7c4328cf8 causing a build failure for > xtables-addons-dkms: > > , > | In file included from > /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245, > | from > /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_DELUDE.c:20: > | /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:74: > note: expected ‘struct sk_buff *’ but argument is of type ‘unsigned int’ > |19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct > sk_buff *skb, unsigned addr_type); > | | > ^~~ > | /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_DELUDE.c:125:6: > error: too few arguments to function ‘ip_route_me_harder’ > | 125 | if (ip_route_me_harder(net, nskb, addr_type)) > | | ^~ > | In file included from > /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245, > | from > /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_DELUDE.c:20: > | /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:5: > note: declared here > |19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct > sk_buff *skb, unsigned addr_type); > | | ^~ > | /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c: In function > ‘echo_tg4’: > | /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:195:39: error: > passing argument 2 of ‘ip_route_me_harder’ from incompatible pointer type > [-Werror=incompatible-pointer-types] > | 195 | if (ip_route_me_harder(par_net(par), newskb, RTN_UNSPEC) != 0) > | | ^~ > | | | > | | struct sk_buff * > | In file included from > /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245, > | from > /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:16: > | /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:54: > note: expected ‘struct sock *’ but argument is of type ‘struct sk_buff *’ > |19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct > sk_buff *skb, unsigned addr_type); > | | ~^~ > | /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:195:6: error: > too few arguments to function ‘ip_route_me_harder’ > | 195 | if (ip_route_me_harder(par_net(par), newskb, RTN_UNSPEC) != 0) > | | ^~ > | In file included from > /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter/x_tables.h:245, > | from > /var/lib/dkms/xtables-addons/3.11/build/extensions/xt_ECHO.c:16: > | /usr/src/linux-headers-5.9.0-3-common/include/linux/netfilter_ipv4.h:19:5: > note: declared here > |19 | int ip_route_me_harder(struct net *net, struct sock *sk, struct > sk_buff *skb, unsigned addr_type); > | | ^~ > ` > > This has been fixed upstream with 3.12 and 3.13 respectively. Yes, I just noticed the new releases. I'm in the process of packaging 3.13 now. J. signature.asc Description: PGP signature
Bug#962221: Fixes for CVE-2020-13696 (#962221)
On 2020-07-06, at 19:11:09 +, Vasyl Gello wrote:
> July 6, 2020 6:58:05 PM UTC, Mattia Rizzolo написав(-ла):
> > On Mon, Jul 06, 2020 at 05:10:30AM +, Vasyl Gello wrote:
> > > Thanks for contributing the security release! I checked your
> > > changes and pushed them to the team repo. I do not have an upload
> > > rights, so CCing Sebastian and Mattia.
> >
> > Also, the commit adding the CVE patch mentions "partial fix", as
> > does the sec-tracker page. Can anybody explain shortly what's with
> > that, where is the full fix (if there is), and how come the LTS
> > upload claims this to be fully fixed instead (CCing the LTS team and
> > the uploader for this).
>
> By partial I understood that upstream fixed the core part but the
> Debian patch sjould have been adapted to reflect new changes.
>
> Jeremy, can you please correct me if I am wrong?
v4l-conf is seteuid-root and is intended to be used to probe video
devices under /dev. The path is given as a command-line argument and
the only validation that used to be done was a check that it began with
"/dev". This means an unprivileged user could test for the existence of
arbitrary files outside /dev and open them:
$ v4l-conf -f -c /dev/../root/.bashrc
VT_GETSTATE is not supported: Inappropriate ioctl for device
mode: 0x0, depth=0, bpp=0, bpl=0, base=unknown
/dev/../root/.bashrc: wrong device
$ v4l-conf -f -c /dev/../root/.abshrc
VT_GETSTATE is not supported: Inappropriate ioctl for device
mode: 0x0, depth=0, bpp=0, bpl=0, base=unknown
can't open /dev/../root/.abshrc: No such file or directory
The new upstream release added extra checks to ensure that the object at
the end of the path is a device file of the right sort before opening
it:
/* First check if the device is really a devnode of the right type */
if (-1 == stat(device, )) {
fprintf(stderr, "stat(%s): %s\n", device, strerror(errno));
exit(1);
}
if (!S_ISCHR(stb.st_mode) || (major(stb.st_rdev) != major)) {
fprintf(stderr, "%s: wrong device\n", device);
exit(1);
}
However, the error messages still leak information, allowing the user to
test for the existence of arbitrary files:
$ v4l-conf -f -c /dev/../root/.bashrc
VT_GETSTATE is not supported: Inappropriate ioctl for device
mode: 0x0, depth=0, bpp=0, bpl=0, base=unknown
/dev/../root/.bashrc: wrong device
$ v4l-conf -f -c /dev/../root/.abshrc
VT_GETSTATE is not supported: Inappropriate ioctl for device
mode: 0x0, depth=0, bpp=0, bpl=0, base=unknown
stat(/dev/../root/.abshrc): No such file or directory
The patch changes the error messages to prevent this:
$ v4l-conf -f -c /dev/../root/.bashrc
VT_GETSTATE is not supported: Inappropriate ioctl for device
mode: 0x0, depth=0, bpp=0, bpl=0, base=unknown
/dev/../root/.bashrc: invalid path or file is not of the right type
$ v4l-conf -f -c /dev/../root/.abshrc
VT_GETSTATE is not supported: Inappropriate ioctl for device
mode: 0x0, depth=0, bpp=0, bpl=0, base=unknown
/dev/../root/.abshrc: invalid path or file is not of the right type
J.
signature.asc
Description: PGP signature
Bug#951999: 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
Bug#951999: 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
Bug#951999: 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
Bug#951999: 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
Bug#951999: 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
