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#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-04-12, at 19:50:58 +0800, Sean Whitton wrote: > On Fri 12 Apr 2024 at 12:44pm +01, Jeremy Sowden wrote: > > On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: > > > Do you have your 1.34 upload of buttercup in git, please? > > > > Yup, it's all on Salsa. > > Er. I got confused, then, didn't I? Should this RFS be closed? I uploaded 1.34, and that is what is currently in the emacsen-team repo. This bug is for 1.35, which is currently sitting in Xiyue's fork, by the looks of it. I haven't looked at this yet. I can pick it up over the week-end. J. signature.asc Description: PGP signature
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: > Do you have your 1.34 upload of buttercup in git, please? Yup, it's all on Salsa. J. > Xiyue, you need to merge in the 1.34 upload, either something from > Jeremy, or we can fall back to merging from dgit/sid. This has > happened a few times now -- please check whether you're missing > uploads before starting to work on top of the branch on salsa :) signature.asc Description: PGP signature
Bug#1068678: nftables: on sysvinit the init script does not start nftables at boot
On 2024-04-09, at 02:35:51 +0200, Davide Baldini wrote: > Package: nftables > Version: 1.0.6-2+deb12u2 > Severity: normal > > Dear Maintainer, > > the installation of nftables completed via apt from the stable repository > leads to the creation of the following init script on a system with sysvinit > without Systemd: > > /etc/init.d/nftables > > whose LSB section is: > > ### BEGIN INIT INFO > # Provides: nftables > # Required-Start:$local_fs $network > # Required-Stop: $local_fs $network > # Should-Start: > # Default-Start: S > # Default-Stop: 0 1 6 > # Short-Description: Loads nftables firewall rules > # Description: Loads nftables firewall rules > ### END INIT INFO > > The "Default-Start" tag is set to "S", which is problematic as it causes the > script to never run at boot. If "S" is replaced by "1 2 3" the script > instead runs at boot as intended. This seems to be a general problem with > all init scripts under Debian whose "Default-Start" tag is set to "S". The nftables package has not installed an init-script for many years. It provides an example script in /usr/share/doc/nftables/examples/sysvinit, along with a README file which reads in part: The file /usr/share/doc/nftables/examples/sysvinit/nftables.init is a typical sysvinit script for you to use as /etc/init.d/nftables. Given Debian default init system is systemd, I have no intention to support sysvinit apart of providing this example file. Read the script carefully before using it, as is just an example. You will likely require to manually edit and install the script in order to properly use it. If your system has an init script installed, then either it was left over when the nftables package stopped providing one, because it had been locally modified and so was not removed, or it was manually installed as described in the README. J. > For example, I created the test file > > /etc/init.d/test.sh > > with the following content: > > #!/bin/bash > > ### BEGIN INIT INFO > # Provides: test > # Required-Start: > # Required-Stop: > # Should-Start: > # Default-Start: S > # Default-Stop: 0 1 6 > # Short-Description: Test > # Description: Test > ### END INIT INFO > > echo $(date) "$@" >>/root/test.txt > > and I enable it with: > > update-rc.d test.sh defaults > > which results in these, and only these, rc symlinks being created: > > rc0.d/K01test.sh > rc1.d/K01test.sh > rc6.d/K01test.sh > rcS.d/S01test.sh > > After rebooting the system from an empty '/root/test.txt' file, the contents > of this file become: > > Tue Apr 9 01:26:50 CEST 2024 stop > > in which only one line is logged, corresponding to the time when I issued > the reboot command, with no follow-up lines after the reboot. > My sysvinit configuration is unremarkably default and I encountered this > problem on every Debian system under sysvinit. > > -- System Information: > Debian Release: 12.4 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to en_US.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) > LSM: AppArmor: enabled > > Versions of packages nftables depends on: > ii libc6 2.36-9+deb12u3 > ii libedit2 3.1-20221030-2 > ii libnftables1 1.0.6-2+deb12u2 > > Versions of packages nftables recommends: > ii netbase 6.4 > > Versions of packages nftables suggests: > pn firewalld > > -- Configuration Files: > /etc/nftables.conf changed [not included] > > -- no debconf information > signature.asc Description: PGP signature
Bug#1066033: RFS: galvani/0.34-1 [ITP] -- reads data from a device with graphical plots and evaluation
On 2024-03-27, at 10:48:45 +0100, Dr. Burkard Lutz wrote:
> Am Dienstag, dem 26.03.2024 um 17:03 + schrieb Jeremy Sowden:
> > [...]
> >
> > The following should suffice:
> >
> > export DH_VERBOSE = 1
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all
> > export DEB_LDFLAGS_MAINT_APPEND = -lstdc++fs
> >
> > %:
> > dh $@ --with autoreconf
> >
>
> So, this is exactly what I had initially.
>
> > Running the build one can see:
> >
> > g++ [...] -D_FORTIFY_SOURCE=2 [...]
> >
> > so the right argument is being passed to the compiler.
> > There is a list
> > of the functions that are fortified here:
> >
> >
> > https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html
> >
> > Does the software use any of these? If not, this is a false
> > positive.
> >
> > J.
>
> Galvani only uses "open" for file operations and "read" to read from
> usb devices.
>
> I'm a bit confused now. The output of "blhc galvani_0.34-1_amd64.build"
> is empty, but "hardening-check -vR /usr/bin/galvani" gives:
>
> /usr/bin/galvani:
> Position Independent Executable: yes
> Stack protected: yes
> Fortify Source functions: no, only unprotected functions found!
> unprotected: read
> unprotected: memcpy
> unprotected: readlink
> unprotected: vsnprintf
> unprotected: memset
> unprotected: memmove
> unprotected: realpath
> unprotected: getcwd
> Read-only relocations: yes
> Immediate binding: yes
> Stack clash protection: unknown, no -fstack-clash-protection
> instructions found
> Control flow integrity: no, not found!
> --
> followed by a long list.
I've take a closer look and I don't think you have anything to worry
about. Lintian's complaint relates to five unfortified function symbols
in the galvani binary:
getcwd
read
vsnprintf
realpath
readlink
hardening-check(1) lists an additional three. Of the eight, the galvani
source itself only includes one of them: read(2). The other are
presumably being pulled in via inline functions or templates from header
files or similar mechanisms. Furthermore, the hardening-check(1) man-
page explains that:
When an executable was built such that the fortified versions of the
glibc functions are not useful (e.g. use is verified as safe at
compile time, or use cannot be verified at runtime), this check will
lead to false alarms.
There is one read(2) call (in mess.cxx):
std::string Multimeter::readfrom_dmm ()
{
std::string mwert, extra_str;
std::string error_str;
char buffer[1024];
std::string poll;
if (scpi)
{
dmm_polling = true;
poll = "MEAS?";
}
else poll = "D";
if (usb)
{
if (dmm_polling) writeto_dmm (poll);
int result = read(usb_port, buffer, 1024);
and it is straightforward for the compiler to verify that it will not
overrun the buffer.
I believe your original rules file was fine. The correct hardening
flags were being passed. The fact that there were unfortified function
symbols in the resulting binary was down to the tool-chain and not
anything you were doing wrong.
J.
signature.asc
Description: PGP signature
Bug#1067809: maildir-utils: New upstream version 1.12.2 is available
On 2024-03-26, at 20:43:29 -0500, John Goerzen wrote: > Package: maildir-utils > Severity: wishlist > > Hi, > > A new upstream version is available. It would be nice to have it in Debian. > Thanks! I have already packaged it, but maildir-utils is involved in a couple of time_t transitions, so I've held off uploading it till they are complete. J. > -- System Information: > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-18-amd64 (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 > > Versions of packages maildir-utils depends on: > ii guile-3.0-libs 3.0.8-2 > ii libc6 2.36-9+deb12u4 > ii libgcc-s1 12.2.0-14 > ii libglib2.0-02.74.6-2 > ii libgmime-3.0-0 3.2.13+dfsg-2 > ii libstdc++6 12.2.0-14 > ii libxapian30 1.4.22-1 > > maildir-utils recommends no packages. > > maildir-utils suggests no packages. > > -- no debconf information 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#1067161: nftables: BUG: invalid mapping expression variable
On 2024-03-20, at 14:44:21 +0100, Daniel Gröber wrote: > On Tue, Mar 19, 2024 at 06:27:11PM +0000, Jeremy Sowden wrote: > > On 2024-03-19, at 16:00:28 +0100, Daniel Gröber wrote: > > > The nftables config below triggers a BUG. > > > > > > $ nft -f /etc/nftables.conf > > > BUG: invalid mapping expression variable > > > nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed. > > > Aborted > > > > > > Refactoring to using $srvaddr_map instead of having the anonymous > > > map inline made the bug trigger. > > > > That assertion has since been replaced upstream by a normal > > error-message: > > > > /space/azazel/tmp/ruleset.1067161.nft:6:58-69: Error: invalid mapping > > expression variable > > ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map > > $srvaddr_map > > ~~ > > > > Fair enough then. I do find this a bit of an arbitrary limitation > however. Agreed. > > Because of the way parsing works in nftables, one can't use a > > symbolic variable in that context. This, however, will work: > > Yup, that's what I'm doing now. I just keep running into these little > irritating limitations with nftables and wanted to at least document > this one somewhere. > > Do you think it's worth forwarding this report upstream anyway? I > would like to sand off sharp nftables edges such as this. Also agreed. Leave it with me. I'll send a patch or open a report in the upstream Bugzilla. > In case you're curios what I was working on: a generic way to have > isolated v6 service addressess for software that doesn't support > SO_BINDTODEV (*cough* syncthing *cough*) without hardcoding any > prefixes https://paste.debian.net/hidden/66c2ef6e/ J. signature.asc Description: PGP signature
Bug#1067028: RFS: emacs-buttercup/1.34-1 [Team] -- behaviour-driven testing for Emacs Lisp packages
On 2024-03-16, at 23:38:58 -0700, Xiyue Deng wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "emacs-buttercup": > > * Package name : emacs-buttercup >Version : 1.34-1 >Upstream contact : [fill in name and email of upstream] > * URL : https://github.com/jorgenschaefer/emacs-buttercup/ > * License : GFDL-1.2+ or CC-BY-SA-3.0, GPL-3+ > * Vcs : https://salsa.debian.org/emacsen-team/emacs-buttercup >Section : lisp > > The source builds the following binary packages: > > elpa-buttercup - behaviour-driven testing for Emacs Lisp packages > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/emacs-buttercup/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.34-1.dsc > > Changes since the last upload: > > emacs-buttercup (1.34-1) unstable; urgency=medium > . >* Team upload >* New upstream release >* Migrate to debhelper-compat version 13 LGTM. Will upload shortly. J. signature.asc Description: PGP signature
Bug#1067161: nftables: BUG: invalid mapping expression variable
On 2024-03-19, at 16:00:28 +0100, Daniel Gröber wrote:
> Package: nftables
> Version: 1.0.6-2+deb12u2
> Severity: normal
>
> Dear Maintainer,
>
> The nftables config below triggers a BUG.
>
> $ nft -f /etc/nftables.conf
> BUG: invalid mapping expression variable
> nft: evaluate.c:1797: expr_evaluate_map: Assertion `0' failed.
> Aborted
>
> Refactoring to using $srvaddr_map instead of having the anonymous map
> inline made the bug trigger.
That assertion has since been replaced upstream by a normal
error-message:
/space/azazel/tmp/ruleset.1067161.nft:6:58-69: Error: invalid mapping
expression variable
ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map
$srvaddr_map
~~
> -- Configuration Files:
> /etc/nftables.conf changed:
> flush ruleset
> define iid_mask6 = :::::
> define srvaddr_map = { ::8384 : 8384 }
> table inet filter {
> chain input {
> type filter hook input priority filter;
> }
> chain prerouting {
> type nat hook prerouting priority dstnat;
> ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map
> $srvaddr_map # s/ map.*/{ ::8384 : 8384 }/ works
> }
> chain forward {
> type filter hook forward priority filter;
> }
> chain output {
> type filter hook output priority filter;
> }
> }
Because of the way parsing works in nftables, one can't use a symbolic
variable in that context. This, however, will work:
define iid_mask6 = :::::
define srvaddr_map = { ::8384 : 8384 }
table inet filter {
map srvaddr_map {
typeof ip6 daddr : tcp dport;
elements = $srvaddr_map
}
chain prerouting {
type nat hook prerouting priority dstnat;
ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map @srvaddr_map
}
}
or more concisely:
define iid_mask6 = :::::
table inet filter {
map srvaddr_map {
typeof ip6 daddr : tcp dport;
elements = srvaddr_map = { ::8384 : 8384 }
}
chain prerouting {
type nat hook prerouting priority dstnat;
ip6 nexthdr tcp redirect to ip6 daddr & $iid_mask6 map @srvaddr_map
}
}
J.
signature.asc
Description: PGP signature
Bug#1063690: nftables: Segfault on named set or map definition in second table specification
Control: severity -1 normal
Control: tags -1 confirmed bullseye patch
On 2024-02-11, at 09:50:27 +0100, Einhard Leichtfuß wrote:
> Package: nftables
> Version: 0.9.8-3.1+deb11u2
> Severity: important
>
> Upon running `nft -f file.nft`, where `file.nft` specifies the same
> table at least twice, and a named set or map is defined in the second
> (or later) table specification, a segmentation fault is caused.
>
> The specified ruleset appears to be correctly applied regardless.
>
> Example `file.nft`:
> ---
> table inet t0 {
> }
>
> table inet t0 {
> set s0 {
> type inet_service
> elements = { 42 }
> }
> }
> ---
>
> Note that both a named set and a named map definition cause the
> segfault, while a (similarly simple) chain definition does not.
>
> The only error message printed is "Segmentation fault\n".
>
> Note that this causes nftables.service to fail if `/etc/nftables.conf`
> contains such configuration (but the ruleset appears to be applied).
>
> I cannot reproduce the bug with the preceding package version,
> 0.9.8-3.1+deb11u1, nor on Debian 12 Bookworm (nftables 1.0.6-2+deb12u2).
0.9.8-3.1+deb11u2 includes some cherry-picked patches from upstream to a
different bug (#1051592). Unfortunately, it turns out that they also
introduce the crash that you have observed.
The crash occurs when freeing resources after processing the file, so as
you note the commands in the file are successfully executed. The crash
can be avoided by making sure that the set definition is in the first
table block. For example, swapping:
table inet t0 {
set s0 {
type inet_service
elements = { 42 }
}
}
table inet t0 {
}
or just merging:
table inet t0 {
set s0 {
type inet_service
elements = { 42 }
}
}
should work around the problem. For these reasons I am lowering the
severity to "normal".
I have identified the underlying problem and I believe that only a small
code change is needed to fix it (patch attached). I'm going to get a
second opinion from upstream.
J.
From 45203fff06e15b97037e3c32e4c6256025a23d75 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Sat, 17 Feb 2024 14:58:23 +
Subject: [PATCH] evaluate: don't call `set_add_hash` for sets which are
already associated with a table
Signed-off-by: Jeremy Sowden
---
src/evaluate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/evaluate.c b/src/evaluate.c
index 232ae39020cc..c58e37e14064 100644
--- a/src/evaluate.c
+++ b/src/evaluate.c
@@ -3759,7 +3759,8 @@ static int set_evaluate(struct eval_ctx *ctx, struct set *set)
}
ctx->set = NULL;
- if (set_lookup(table, set->handle.set.name) == NULL)
+ if (set_lookup(table, set->handle.set.name) == NULL &&
+ list_empty(>list))
set_add_hash(set_get(set), table);
return 0;
--
2.43.0
signature.asc
Description: PGP signature
Bug#1061069: iptables FTCBFS: python3 dependency not installable for host
On 2024-01-17, at 10:43:07 +0100, Helmut Grohne wrote: > Source: iptables > Version: 1.8.10-2 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: cross-satisfiability > > iptables cannot be cross built from source, because it depends on > python3. More precisely, it depends on the host architecture Python > interpreter, which cannot be run and therefore cannot be installed. It > really needs Python as a tool during build rather than to link it or > integrate host code with and thus it should be annotated :any or > :native. It also only needs Python for testing and thus it should be > annotated . Doing so immediately fixes the cross build > failure. I'm attaching a patch for your convenience. > > Helmut > diff --minimal -Nru iptables-1.8.10/debian/changelog > iptables-1.8.10/debian/changelog > --- iptables-1.8.10/debian/changelog 2024-01-11 14:08:21.0 +0100 > +++ iptables-1.8.10/debian/changelog 2024-01-17 10:04:33.0 +0100 > @@ -1,3 +1,11 @@ > +iptables (1.8.10-2.1) UNRELEASED; urgency=medium > + > + * Non-maintainer upload. > + * Fix FTCBFS: Annotate python3 build dependency with :native and > . > +(Closes: #-1) > + > + -- Helmut Grohne Wed, 17 Jan 2024 10:04:33 +0100 > + > iptables (1.8.10-2) unstable; urgency=medium > >* [06f4121] d/control: use tracker.d.o address for `Maintainer:` > diff --minimal -Nru iptables-1.8.10/debian/control > iptables-1.8.10/debian/control > --- iptables-1.8.10/debian/control2023-12-13 14:22:25.0 +0100 > +++ iptables-1.8.10/debian/control2024-01-17 10:04:33.0 +0100 > @@ -11,7 +11,7 @@ > libnfnetlink-dev, > libnftnl-dev (>= 1.1.6), > netbase (>= 6.0), > - python3 > + python3:native > Standards-Version: 4.6.2 > Rules-Requires-Root: no > Homepage: https://www.netfilter.org/ Applied. Will upload shortly. J. 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#1060342: Please cherry-pick c1083acea707 ("ebtables: Fix corner-case noflush restore bug")
On 2024-01-09, at 21:55:13 +0100, Michael Biebl wrote:
> Package: iptables
> Version: 1.8.10-1
> Severity: normal
> Tags: patch
>
>
> Hi,
>
> firewalld fails to work with the current version of iptables in Debian.
> This is exemplified by the autopkgtest which recently has been made
> available in Debian (thanks elbrus):
> https://ci.debian.net/packages/f/firewalld/unstable/amd64/41650423/
>
> After contacting firewalld upstream in
> https://github.com/firewalld/firewalld/issues/1268
>
> it turns out this issue has already been fixed in
> etables (iptables-nft) commit c1083acea707 ("ebtables: Fix corner-case
> noflush restore bug").
>
> Cherry-picking this commit for iptables, makes the firewalld test suite
> pass. I'm attaching the commit as patch file.
>
> If you are busy, I can offer to NMU.
I'll take care of it.
J.
signature.asc
Description: PGP signature
Bug#1058522: (no subject)
On 2023-12-24, at 10:00:26 +0500, Lev Lamberov wrote: > Чт 21 дек 2023 @ 15:06 Jeremy Sowden: > > On 2023-12-21, at 11:21:48 +0000, Jeremy Sowden wrote: > >> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote: > >> > Since I cannot reproduce the bug, I'm downgrading the severity of > >> > this bug report. > >> > >> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and > >> reproduced it (log attached). I'll see if I can work out what's going > >> on. > > Thanks for your input. I double checked this bug report both under > git-pbuilder and sbuild. E. g., here is the sbuild environment: > > $ sudo sbuild-shell unstable > I: /bin/sh > # bash > (unstable-amd64-sbuild)root@shakva:/# du --version > du (GNU coreutils) 9.4 > Copyright (C) 2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <https://gnu.org/licenses/gpl.html>. > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Written by Torbjörn Granlund, David MacKenzie, Paul Eggert, > and Jim Meyering. > (unstable-amd64-sbuild)root@shakva:/# exit > > But I still cannot reproduce the bug. Don't know... First things first, do you see the following in your chroot? (unstable-amd64-sbuild)root@ulthar:~# d=$(mktemp -d) (unstable-amd64-sbuild)root@ulthar:~# du -sb $d 0 /tmp/tmp.qay80HZ09w This is the cause of the problem. If your du is not reporting zero size for an empty directory, that would explain the discrepancy and the rest of this e-mail is irrelevant. :) Now I'm going to walk through the test. The dired directory listings I quote below were got by running: # apt-get source dired-du # cd dired-du-0.5.2 # export TERM=rxvt # emacs -nw -l dired-du.el in an sbuild unstable chroot, entering extracts from the test source adapted to run in the *scratch* buffer and executing them, and observing the results in a dired buffer in the same frame. The test source begins: ;; Sort by size only supported in `ls-lisp'. (ert-deftest dired-du-sort-by-size () "Test ls-lisp sort by size with recursive size dir feature." (let* ((dir (make-temp-file "dired-du" 'dir)) (filled-subdir (expand-file-name "filled-subdir" dir)) (empty-subdir (expand-file-name "empty-subdir" dir)) (external-file (expand-file-name "external-file" dir)) (inner-file (expand-file-name "inner-file" filled-subdir)) We're going to create the following directory structure: dired-duXX/ | +-> empty-subdir/ | +-> external-file | +-> filled-subdir/ | +-> inner-file The test source continues: (ls-lisp-use-insert-directory-program nil) We force the use of ls-lisp. (orig-def-dir default-directory) (dired-listing-switches "-lS") We tell dired to sort by size. (buffers '()) mode-on) (unwind-protect (let (filled-subdir-size empty-subdir-size file-size) (make-directory filled-subdir) (make-directory empty-subdir) (setq default-directory dir) (add-to-list 'buffers (dired dir)) (dired dir) At this point we have created the two subdirectories and the dired buffer contains: /tmp/dired-duSKABAl: (557 GiB available) drwxr-xr-x 2 root root 4096 Dec 29 16:40 empty-subdir drwxr-xr-x 2 root root 4096 Dec 29 16:40 filled-subdir Note that the directory sizes come from opendir -> readdir -> fstat. In what follows, however, the recursive directory sizes are got by calling du. (setq empty-subdir-size (dired-du--get-recursive-dir-size "empty-subdir")) The test expects that the recursive size of "empty-subdir" will be some non-zero value, $x, like the 4kB reported by fstat above. (setq file-size (* empty-subdir-size 2)) (setq filled-subdir-size (+ empty-subdir-size file-size)) (dolist (file (list external-file inner-file)) (write-region (make-string file-size ?.) nil file)) 2 * $x bytes are written to "external-file" and "inner-file". At this point, the expectation is that "empty-subdir" has a recursive size $x, the two files have size 2 * $x, and "filled-subdir" has a recursive size $x + 2 * $x. However, because du now reports directories as having zero size, $x equals 0, the two files contain 0B, and the two directories have recursive sizes of 0B. (dired-revert) ; Revert to show external-file On running `M-x revert-buffer` in the dired buffer, it includes the empty "external-file": /tmp/dired-duSKABAl: (557 GiB available) drwxr-xr-x 2 root root 4096 Dec 29 16:40 empty-subdi
Bug#1058522: (no subject)
On 2023-12-21, at 11:21:48 +, Jeremy Sowden wrote:
> On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote:
> > Since I cannot reproduce the bug, I'm downgrading the severity of
> > this bug report.
>
> I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and
> reproduced it (log attached). I'll see if I can work out what's going
> on.
In testing:
$ du --version
du (GNU coreutils) 9.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, Paul Eggert,
and Jim Meyering.
$ du -sb /tmp/dired-du1wX4yG/empty-subdir
4096/tmp/dired-du1wX4yG/empty-subdir
In unstable:
$ schroot -c sid -- du --version
du (GNU coreutils) 9.4
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Torbjorn Granlund, David MacKenzie, Paul Eggert,
and Jim Meyering.
$ schroot -c sid -- du -sb /tmp/dired-du1wX4yG/empty-subdir
0 /tmp/dired-du1wX4yG/empty-subdir
This coreutils bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=61884
led to a change in behaviour such that `du -b`, which is equivalent to
`du --apparent --block-size=1`, reports directories as having zero size.
If we don't pass `--apparent` we restore the old output:
$ schroot -c sid -- du -s --block-size=1 /tmp/dired-du1wX4yG/empty-subdir
4096/tmp/dired-du1wX4yG/empty-subdir
I've attached a minimal patch that fixes the bug:
$ schroot -c sid -- emacs -batch -l dired-du.el -l dired-du-tests.el -eval
'(ert-run-tests-batch-and-exit "dired-du-sort-by-size")'
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Running 1 tests (2023-12-21 15:02:28+, selector
`"dired-du-sort-by-size"')
[...]
Test dired-du-sort-by-size condition:
(ert-test-failed
((should
(equal
'("filled-subdir" "external-file" "empty-subdir")
(dired-get-marked-files ...)))
:form
(equal
("filled-subdir" "external-file" "empty-subdir")
("filled-subdir" "empty-subdir" "external-file"))
:value nil :explanation
(list-elt 1
(arrays-of-different-length 13 12 "external-file"
"empty-subdir" first-mismatch-at 1
FAILED 1/1 dired-du-sort-by-size (0.392296 sec) at
dired-du-tests.el:237
Ran 1 tests, 0 results as expected, 1 unexpected (2023-12-21 15:02:29+,
0.712904 sec)
1 unexpected results:
FAILED dired-du-sort-by-size
$ cat debian/patches/du-dir-size-fix.patch
--- a/dired-du.el
+++ b/dired-du.el
@@ -185,7 +185,7 @@
(defcustom dired-du-used-space-program
(purecopy (let ((opts (if (string-prefix-p "gnu" (symbol-name
system-type))
-"-sb"
+"-sB1"
"-sk"))) ; -k overestimate used space\
; for files w/ size < 1024.
(cond ((executable-find "du") (list "du" opts))
$ dquilt push
Applying patch du-dir-size-fix.patch
patching file dired-du.el
Now at patch du-dir-size-fix.patch
$ schroot -c sid -- emacs -batch -l dired-du.el -l dired-du-tests.el -eval
'(ert-run-tests-batch-and-exit "dired-du-sort-by-size")'
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Running 1 tests (2023-12-21 15:02:51+, selector
`"dired-du-sort-by-size"')
[...]
passed 1/1 dired-du-sort-by-size (0.367606 sec)
Ran 1 tests, 1 results as expected, 0 unexpected (2023-12-21 15:02:51+,
0.367738 sec)
J.
--- a/dired-du.el
+++ b/dired-du.el
@@ -185,7 +185,7 @@
(defcustom dired-du-used-space-program
(purecopy (let ((opts (if (string-prefix-p "gnu" (symbol-name system-type))
-"-sb"
+"-sB1"
"-sk"))) ; -k overestimate used space\
; for files w/ size < 1024.
(cond ((executable-find "du") (list "du" opts))
signature.asc
Description: PGP signature
Bug#1058522: (no subject)
On 2023-12-21, at 11:10:28 +0500, Lev Lamberov wrote:
> Since I cannot reproduce the bug, I'm downgrading the severity of this
> bug report.
I cloned the git repo, ran `gbp buildpackage --git-pbuilder` and
reproduced it (log attached). I'll see if I can work out what's going
on.
J.
[azazel@ulthar:/space/azazel/work/git/repos/salsa/emacsen-team/dired-du
(master=)] $ gbp buildpackage --git-pbuilder
--git-pbuilder-options="--source-only-changes"
gbp:info: Building with (cowbuilder) for sid
gbp:info: Performing the build
Building with cowbuilder for distribution sid
I: using cowbuilder as pbuilder
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-fix-documentation.diff
dh clean --with elpa
dh_auto_clean
make -j1 clean
make[1]: Entering directory
'/space/azazel/work/git/repos/salsa/emacsen-team/dired-du'
rm -f *.elc
make[1]: Leaving directory
'/space/azazel/work/git/repos/salsa/emacsen-team/dired-du'
dh_clean
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building dired-du using existing ./dired-du_0.5.2.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building dired-du in dired-du_0.5.2-2.debian.tar.xz
dpkg-source: info: building dired-du in dired-du_0.5.2-2.dsc
I: Generated dsc will be overwritten by build result; not generating changes
file
dpkg-source: info: unapplying 0001-fix-documentation.diff
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.1422851
I: forking: cp -al /var/cache/pbuilder/base.cow
/var/cache/pbuilder/build/cow.1422851
I: removed stale ilistfile /var/cache/pbuilder/build/cow.1422851/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.1422851 cowdancer-ilistcreate
/.ilist 'find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a
-links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts --debbuildopts
--source-only-changes --buildplace /var/cache/pbuilder/build/cow.1422851
--buildresult /space/azazel/work/git/repos/salsa/emacsen-team --mirror
http://mirror.ox.ac.uk/debian --distribution sid --no-targz
--internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.1422851 cow-shell'
/space/azazel/work/git/repos/salsa/emacsen-team/dired-du_0.5.2-2.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Thu Dec 21 11:10:28 GMT 2023
I: pbuilder-time-stamp: 1703157028
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage for
details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying
[/space/azazel/work/git/repos/salsa/emacsen-team/dired-du_0.5.2-2.dsc]
I: copying
[/space/azazel/work/git/repos/salsa/emacsen-team/dired-du_0.5.2.orig.tar.gz]
I: copying
[/space/azazel/work/git/repos/salsa/emacsen-team/dired-du_0.5.2-2.debian.tar.xz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package (dired-du_0.5.2-2.dsc)
dpkg-source: info: extracting dired-du in dired-du-0.5.2
dpkg-source: info: unpacking dired-du_0.5.2.orig.tar.gz
dpkg-source: info: unpacking dired-du_0.5.2-2.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-fix-documentation.diff
I: Not using root during the build.
I: Installing the build-deps
-> Attempting to satisfy build-dependencies
-> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team
Description: Dummy package to satisfy dependencies with aptitude - created by
pbuilder
This package was created automatically by pbuilder to satisfy the
build-dependencies of the package being currently built.
Depends: debhelper-compat (= 13), dh-elpa
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 14872 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring
anyway as you requested:
pbuilder-satisfydepends-dummy depends on debhelper-compat (= 13); however:
Package debhelper-compat is not installed.
pbuilder-satisfydepends-dummy depends on dh-elpa; however:
Package dh-elpa is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
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#1056572: maildir-utils: please make the build reproducible
On 2023-11-23, at 10:34:50 +, Chris Lamb wrote: > Source: maildir-utils > Version: 1.10.8-1 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: timestamps > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0], we noticed that > maildir-utils could not be built reproducibly: > > ├── ./usr/share/man/man1/mu-add.1.gz > │ ├── mu-add.1 > │ │ @@ -85,15 +85,15 @@ > │ │ Dirk-Jan C. Binnema > │ │ > │ │ .SH "COPYRIGHT" > │ │ .PP > │ │ This manpage is part of \fBmu\fP 1.10.8. > │ │ > │ │ .PP > │ │ -Copyright © 2022-2024 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL > version 3 > │ │ +Copyright © 2022-2023 Dirk-Jan C. Binnema. License GPLv3+: GNU GPL > version 3 > │ │ or later \fIhttps://gnu.org/licenses/gpl.html\fP. This is free software: > you are Yes, I spotted this as well, and I have already pushed changes to the Salsa repo to fix it. 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#1055759: duplicate upstream bug report
Turns out I'm not the first person to have reported this. I've closed my ticket as a duplicate. The earlier one is: https://core.tcl-lang.org/tcltls/tktview/88c0c84969 J. signature.asc Description: PGP signature
Bug#1055759: tcl-tls: EOF's are sometimes treated as errors
On 2023-11-10, at 18:39:10 +, Jeremy Sowden wrote: > Package: tcl-tls > Version: 1.7.22-3+b1 > Severity: normal > Tags: patch upstream > > OpenSSL 3.0 introduced a new option `SSL_OP_IGNORE_UNEXPECTED_EOF`. If > this is not set, it handles unexpected EOF's as fatal errors. Since > TclTLS does not currently set it, some EOF's are treated as errors. I > have reported this upstream here: > > > https://core.tcl-lang.org/tcltls/tktview/c5811f0d433d34ca16ccecdec10fb61e2f3ba657 > > I've attached the patch I proposed in the upstream bug report. I'll add > some DEP-3 metadata and create an MR against the tcltls Salsa repo. Having given this a bit more thought (and looked into why openssl added this option), I think that the patch needs a bit more work. The openssl s_client command, for example, has a command-line option to control this behaviour. J. signature.asc Description: PGP signature
Bug#1055759: tcl-tls: EOF's are sometimes treated as errors
Package: tcl-tls Version: 1.7.22-3+b1 Severity: normal Tags: patch upstream OpenSSL 3.0 introduced a new option `SSL_OP_IGNORE_UNEXPECTED_EOF`. If this is not set, it handles unexpected EOF's as fatal errors. Since TclTLS does not currently set it, some EOF's are treated as errors. I have reported this upstream here: https://core.tcl-lang.org/tcltls/tktview/c5811f0d433d34ca16ccecdec10fb61e2f3ba657 I've attached the patch I proposed in the upstream bug report. I'll add some DEP-3 metadata and create an MR against the tcltls Salsa repo. -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (900, 'stable-updates'), (900, 'stable-security'), (900, 'stable-debug'), (900, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-debug'), (500, 'oldstable'), (99, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tcl-tls depends on: ii libc6 2.37-12 ii libssl3 3.0.11-1 ii libtcl8.6 [libtcl] 8.6.13+dfsg-2 tcl-tls recommends no packages. tcl-tls suggests no packages. -- no debconf information --- a/tls.c +++ b/tls.c @@ -1214,6 +1214,9 @@ SSL_CTX_set_app_data( ctx, (VOID*)interp); /* remember the interpreter */ SSL_CTX_set_options( ctx, SSL_OP_ALL); /* all SSL bug workarounds */ SSL_CTX_set_options( ctx, off);/* all SSL bug workarounds */ +#ifdef SSL_OP_IGNORE_UNEXPECTED_EOF +SSL_CTX_set_options( ctx, SSL_OP_IGNORE_UNEXPECTED_EOF); +#endif SSL_CTX_sess_set_cache_size( ctx, 128); if (ciphers != NULL)
Bug#1054054: shorewall-init: Please provide native NetworkManager hook scripts
On 2023-10-28, at 15:11:15 +0200, Michael Biebl wrote: > On Sat, 21 Oct 2023 11:44:25 +0100 Jeremy Sowden wrote: > > On 2023-10-21, at 11:53:54 +0300, Vincas Dargis wrote: > > > I've noticed NEWS after NetworkManager upgrade about no longer supporting > > > if-* scripts, and now `shorewall status` says `Shorewall is stopped` :/ . > > > > Any ideas how to "workaround" it? > > > > I am working on a fix atm. My plan is to add a dispatcher script for > > Shorwall that calls the ifupdown script to the shorewall-init package. > > The script installed by the package will go into: > > > > /usr/lib/NetworkManager/dispatcher.d > > > > If you choose to install one manually it goes into: > > > > /etc/NetworkManager/dispatcher.d > > > > The script will look something like the attached (currently untested). > > Please consider adding a native hook script and not simply calling the > if-up.d script from the NM hook script. This is no > > If there is shared functionality, this should be placed into a script in > /usr/lib/$pkg and be called from both if-up.d and the NM-dispatcher hook. As it happens, upstream installs the same ifupdown script in /usr/share/shorewall-init/ as well as /etc/network/if-*.d/. The Fedora and SUSE versions, which have been extended to allow them to be used as NM dispatcher scripts, are additionally installed in /etc/NetworkManger/dispatcher.d/. Lots of duplication. The refactoring you suggest would certainly be an improvement. The current solution, which does at least get the functionality working again, was uploaded this morning, but, as I say, your proposal makes sense, so I will come back to this when I get a moment. J. signature.asc Description: PGP signature
Bug#1054054: shorewall-init: Please provide native NetworkManager hook scripts
On 2023-10-21, at 19:16:15 +0300, Vincas Dargis wrote: > On Sat, 21 Oct 2023 13:27:46 +0100 Jeremy Sowden wrote: > > init.fedora.sh, on the other hand, is a System V init-script > > Oh, sorry, I've directed to the wrong file... > > Re-checked IRC logs, it was ifupdown.fedora.sh, not init.fedora.sh. > > I was said that ifupdown.fedora.sh is NetworkManager script. That makes more sense. :) I've compared the Debian and Fedora ifupdown scripts and the Fedora one does have some extra code to allow it to work as an NM dispatcher. How- ever, the Fedora script just starts or stops all the configured pro- ducts, whereas the Debian script checks for the `ADDRFAM` environment variable which ifupdown sets to `inet` or `inet6` in order to start or stop only the products which match the address family. The 01-ifupdown dispatcher script that has been removed from NetworkManager makes sure to set this variable appropriately before calling the ifupdown script, and the dispatcher script I proposed earlier does likewise. I have run some tests with it and it works, so I'm going to go with that. In summary, using the Fedora script will mostly work, the script I wrote will work better, and there should be a new shorewall-init package along in the not too distant future with my script in it. J. signature.asc Description: PGP signature
Bug#1054054: shorewall-init: Please provide native NetworkManager hook scripts
On 2023-10-21, at 13:27:47 +0100, Jeremy Sowden wrote:
> On 2023-10-21, at 14:39:51 +0300, Vincas Dargis wrote:
> > On Sat, 21 Oct 2023 11:44:25 +0100 Jeremy Sowden wrote:
> > > On 2023-10-21, at 11:53:54 +0300, Vincas Dargis wrote:
> > > > Any ideas how to "workaround" it?
> > >
> > > I am working on a fix atm.
> >
> > Thanks!
> >
> > But I was instructed in #shorewall that this is NetworkManager
> > script, it's just named "feroda":
> >
> >
> > https://gitlab.com/shorewall/code/-/blob/master/Shorewall/init.fedora.sh?ref_type=heads
> >
> > Or you feel that it's not usable for Debian?
>
> The problem you have is that Shorewall used to be started and stopped
> by NetworkManager, when it brought your network interface up and down,
> by running a script provided by the shorewall-init package for
> ifupdown, which is another tool for managing network interfaces.
> However, NetworkManager has stopped running ifupdown scripts because
> the interfaces for its own scripts and the ifupdown ones are not the
> same and the mismatch could lead to problems. As it happens,
> NetworkManager can safely run the Shorewall script, so I am in the
> process of adding an NetworkManager script that will run the ifupdown
> one.
>
> init.fedora.sh, on the other hand, is a System V init-script (it
> starts Shorewall when your system comes up and stops it when you shut
> down or reboot), and it's intended for Red Hat and Fedora. Sysvinit
> has been superseded in most distributions these days by Systemd. The
> Shorewall packages in Debian do include Systemd support, so if
> starting your firewall on boot is an option, you can do:
>
> # systemctl enable shorewall
>
> and (if you have configured Shorewall for ipv6):
>
> # systemctl enable shorewall6
>
> instead.
Actually, since you are using shorewall-init, which also has a service
file, you only need to do this:
# systemctl enable --now shorewall-init
The `--now` switch tells Systemd to start the service as well as
enabling it.
> If you do so, then set `IFUPDOWN` to zero in
> /etc/default/shorewall{,6}.
# sed -i -e 's/\(IFUPDOWN\)=1/\1=0/' /etc/default/shorewall-init
J.
signature.asc
Description: PGP signature
Bug#1054054: shorewall-init: Please provide native NetworkManager hook scripts
On 2023-10-21, at 14:39:51 +0300, Vincas Dargis wrote:
> On Sat, 21 Oct 2023 11:44:25 +0100 Jeremy Sowden wrote:
> > On 2023-10-21, at 11:53:54 +0300, Vincas Dargis wrote:
> > > Any ideas how to "workaround" it?
> >
> > I am working on a fix atm.
> Thanks!
>
> But I was instructed in #shorewall that this is NetworkManager script,
> it's just named "feroda":
>
>
> https://gitlab.com/shorewall/code/-/blob/master/Shorewall/init.fedora.sh?ref_type=heads
>
> Or you feel that it's not usable for Debian?
The problem you have is that Shorewall used to be started and stopped by
NetworkManager, when it brought your network interface up and down, by
running a script provided by the shorewall-init package for ifupdown,
which is another tool for managing network interfaces. However,
NetworkManager has stopped running ifupdown scripts because the
interfaces for its own scripts and the ifupdown ones are not the same
and the mismatch could lead to problems. As it happens, NetworkManager
can safely run the Shorewall script, so I am in the process of adding an
NetworkManager script that will run the ifupdown one.
init.fedora.sh, on the other hand, is a System V init-script (it starts
Shorewall when your system comes up and stops it when you shut down or
reboot), and it's intended for Red Hat and Fedora. Sysvinit has been
superseded in most distributions these days by Systemd. The Shorewall
packages in Debian do include Systemd support, so if starting your
firewall on boot is an option, you can do:
# systemctl enable shorewall
and (if you have configured Shorewall for ipv6):
# systemctl enable shorewall6
instead.
If you do so, then set `IFUPDOWN` to zero in /etc/default/shorewall{,6}.
J.
signature.asc
Description: PGP signature
Bug#1054054: shorewall-init: Please provide native NetworkManager hook scripts
On 2023-10-21, at 11:53:54 +0300, Vincas Dargis wrote: > I've noticed NEWS after NetworkManager upgrade about no longer supporting > if-* scripts, and now `shorewall status` says `Shorewall is stopped` :/ . > > Any ideas how to "workaround" it? I am working on a fix atm. My plan is to add a dispatcher script for Shorwall that calls the ifupdown script to the shorewall-init package. The script installed by the package will go into: /usr/lib/NetworkManager/dispatcher.d If you choose to install one manually it goes into: /etc/NetworkManager/dispatcher.d The script will look something like the attached (currently untested). J. #!/bin/sh if ! [ "$1" ] || [ "$1" = none ]; then exit 0 fi export IFACE="$1" case "$2" in up) export MODE="start" export PHASE="post-up" IFUPDOWN=/etc/network/if-up.d/shorewall ;; down) export MODE="stop" export PHASE="post-down" IFUPDOWN=/etc/network/if-post-down.d/shorewall ;; *) exit 0 ;; esac if [ "$IP4_NUM_ADDRESSES" ] && [ "$IP4_NUM_ADDRESSES" -gt 0 ]; then ADDRESS_FAMILIES="$ADDRESS_FAMILIES inet" fi if [ "$IP6_NUM_ADDRESSES" ] && [ "$IP6_NUM_ADDRESSES" -gt 0 ]; then ADDRESS_FAMILIES="$ADDRESS_FAMILIES inet6" fi [ "$ADDRESS_FAMILIES" ] || ADDRESS_FAMILIES="inet" for i in $ADDRESS_FAMILIES; do export ADDRFAM="$i" $IFUPDOWN done signature.asc Description: PGP signature
Bug#1053816: bullseye-pu: package nftables/0.9.8-3.1+deb11u2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nftab...@packages.debian.org,
Control: affects -1 + src:nftables
A version of this pu has already been accepted for Bookworm. I have cribbed
liberally from the bookworm-pu bug report.
nftables bug: https://bugs.debian.org/1051592
bookworm-pu bug: https://bugs.debian.org/1052021
[ Reason ]
Timo Sigurdsson reported after the release of DSA 5492-1 for linux that
in his case nftables rules were not loaded anymore.
This was tracked down to a Linux change, 0ebc1064e487 ("netfilter:
nf_tables: disallow rule addition to bound chain via
NFTA_RULE_CHAIN_ID"), which is to address CVE-2023-4147, but uncovered
an issue with nftables releases before v1.0.7 upstream. nftables
generates incorrect bytecode, which is affected by this new kernel check
that rejects adding rules to bound chains.
Following https://lore.kernel.org/stable/ZP+bUpxJiFcmTWhy@calendula/ and
further discussion on the Linux kernel mailing-lists it seemed that this
had to be addressed in nftables itself.
[ Impact ]
Users which have such rules, running unpatched nftables but updated
the linux kernel due to address security fixes (and later to be
included in the point release as well) are left without loaded
nftables rules.
[ Tests ]
Explicit tests with the rules provided by Timo to verify they
correctly get loaded with updated nftables userland and the updated
kernel.
[ Risks ]
Pablo Neira Ayuso provided the series of commits required to address
the issue. They apply cleanly for the bullseye version.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in oldstable
[x] the issue is verified as fixed in unstable
[ Changes ]
* New patches to fix the problem described above.
* I updated an existing patch to remove some fuzz (happy to drop this
if you prefer).
[ Other info ]
diff -Nru nftables-0.9.8/debian/changelog nftables-0.9.8/debian/changelog
--- nftables-0.9.8/debian/changelog 2022-09-04 09:34:11.0 +0100
+++ nftables-0.9.8/debian/changelog 2023-10-10 21:28:38.0 +0100
@@ -1,3 +1,18 @@
+nftables (0.9.8-3.1+deb11u2) bullseye; urgency=medium
+
+ * d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch: fix fuzz
+ * Fix incorrect bytecode generation hit with new kernel check that
+rejects adding rules to bound chains
+
+- cache: rename chain_htable to cache_chain_ht
+- src: split chain list in table
+- evaluate: init cmd pointer for new on-stack context
+- rule: add helper function to expand chain rules into commands
+- rule: expand standalone chain that contains rules
+- src: expand table command before evaluation
+
+ -- Jeremy Sowden Tue, 10 Oct 2023 21:28:38 +0100
+
nftables (0.9.8-3.1+deb11u1) bullseye; urgency=medium
* d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
diff -Nru
nftables-0.9.8/debian/patches/cache-rename-chain_htable-to-cache_chain_ht.patch
nftables-0.9.8/debian/patches/cache-rename-chain_htable-to-cache_chain_ht.patch
---
nftables-0.9.8/debian/patches/cache-rename-chain_htable-to-cache_chain_ht.patch
1970-01-01 01:00:00.0 +0100
+++
nftables-0.9.8/debian/patches/cache-rename-chain_htable-to-cache_chain_ht.patch
2023-10-10 21:28:38.0 +0100
@@ -0,0 +1,98 @@
+From 0a39091a75b6255422832126df4cbf73c86845cd Mon Sep 17 00:00:00 2001
+From: Pablo Neira Ayuso
+Date: Thu, 1 Apr 2021 22:18:29 +0200
+Subject: [PATCH nft 0.9.8] cache: rename chain_htable to cache_chain_ht
+
+upstream 3542e49cf539ecfcef6ef7c2d4befb7896ade2cd commit.
+
+Rename the hashtable chain that is used for fast cache lookups.
+
+Signed-off-by: Pablo Neira Ayuso
+---
+ include/rule.h | 4 ++--
+ src/cache.c| 6 +++---
+ src/rule.c | 6 +++---
+ 3 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/include/rule.h b/include/rule.h
+index 330a09aa77fa..43872db8947a 100644
+--- a/include/rule.h
b/include/rule.h
+@@ -154,7 +154,7 @@ struct table {
+ struct handle handle;
+ struct location location;
+ struct scopescope;
+- struct list_head*chain_htable;
++ struct list_head*cache_chain_ht;
+ struct list_headchains;
+ struct list_headsets;
+ struct list_headobjs;
+@@ -220,7 +220,7 @@ struct hook_spec {
+ */
+ struct chain {
+ struct list_headlist;
+- struct list_headhlist;
++ struct list_headcache_hlist;
+ struct handle handle;
+ struct location location;
+ unsigned intrefcnt;
+diff --git a/src/cache.c b/src/cache.c
+index ed2609008e22..7101b74160be 100644
+--- a/src/cache.c
b/src/cache.c
+@@ -194,7 +194,7 @@ static int chain_cache_cb(struct nftnl_chain *nlc, void
*arg)
+ if (ch
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#1050418: Conntrackd in Bookworm reverts byte order in src address sent by conntrackd in Bullseye
Control: tags -1 + patch
On 2023-08-24, at 20:33:13 +0100, Jeremy Sowden wrote:
> On 2023-08-24, at 12:55:30 +0200, Pavel Matěja wrote:
> > I'm upgrading our servers from Bullseye to Bookworm. Some of them
> > act as load balancers and they are using conntrackd to synchronize
> > TCP connection states using FTFW sync mode. I've noticed when I
> > have primary server running Bullseye (conntrack v1.4.6) and
> > secondary Bookworm (conntrack v1.4.7) I get
> >
> > bullseye:~$ sudo conntrack -L
> > ..
> > tcp 6 430554 ESTABLISHED src=x.y.49.137 dst=x.y.48.169
> > sport=35570 dport=636 src=10.170.0.153 dst=x.y.49.137
> > sport=636 dport=35570 [ASSURED] mark=0 use=1
> > ..
> >
> > bookworm:~$ sudo conntrack -L
> > ..
> > tcp 6 431388 ESTABLISHED src=x.y.49.137 dst=x.y.48.169
> > sport=35570 dport=636 src=153.0.170.10 dst=x.y.49.137
> > sport=636 dport=35570 [ASSURED] mark=0 use=1
> > ..
> >
> > Notice order of the 'src' address bytes.
> > When failover occures all TCP connections via secondary balancer are
> > broken as packets source addresses don't match those in conntrack
> > table anymore.
> >
> > [...]
> >
> > Core of this problem might be related to
> > https://git.netfilter.org/conntrack-tools/commit/?id=b55717d46ae3b7c3769192a66e565bc7c2d833a1
> > but I'm not familiar with conntrackd source code.
>
> I believe you are correct in identifying b55717d46ae3 ("conntrackd:
> fix endianness bug in IPv4 and IPv6 address").
>
> [...]
>
> I believe the upstream switch to NBO is correct, but I'm afraid that
> we in Debian didn't spot this consequence. I'll see about getting a
> notice added to the package documentation.
Something like this patch.
J.
From 04f032718c8ab3fcab7e101c988f67d2ebde5ab3 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Thu, 24 Aug 2023 21:03:57 +0100
Subject: [PATCH] d/NEWS: add notice about 1.4.6/1.4.7 little-endian
imcompatibility
Closes: #1050418
Signed-off-by: Jeremy Sowden
---
debian/NEWS | 16
1 file changed, 16 insertions(+)
create mode 100644 debian/NEWS
diff --git a/debian/NEWS b/debian/NEWS
new file mode 100644
index ..2b6e47aa77ad
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1,16 @@
+conntrack-tools (1:1.4.7-2) unstable; urgency=medium
+
+ 1.4.6 conntrackd instances runnning on little-endian hosts are not
+ compatible with 1.4.7 instances.
+
+ Before 1.4.7, when syncing, conntrackd instances communicated NAT IP
+ addresses in host byte-order. This meant that one could not run
+ instances on hosts of different endianness, because if the byte-orders
+ of the sending and receiving instances were different, the receiving
+ instance would get the addresses inverted: 10.0.0.1 -> 1.0.0.10.
+
+ In 1.4.7, conntrackd uses network byte-order. Since network byte-order
+ is big-endian, all 1.4.7 instances are incompatible with 1.4.6 little-
+ endian instances.
+
+ -- Jeremy Sowden Thu, 24 Aug 2023 20:41:50 +0100
--
2.40.1
signature.asc
Description: PGP signature
Bug#1050418: Conntrackd in Bookworm reverts byte order in src address sent by conntrackd in Bullseye
Control: tags -1 confirmed upstream
On 2023-08-24, at 12:55:30 +0200, Pavel Matěja wrote:
> Package: conntrackd
> Version: 1:1.4.7-1+b2
> Conntrackd package on Bullseye is 1:1.4.6-2.
>
> I'm upgrading our servers from Bullseye to Bookworm. Some of them act
> as load balancers and they are using conntrackd to synchronize TCP
> connection states using FTFW sync mode.
> I've noticed when I have primary server running Bullseye (conntrack
> v1.4.6) and secondary Bookworm (conntrack v1.4.7) I get
>
> bullseye:~$ sudo conntrack -L
> ..
> tcp 6 430554 ESTABLISHED src=x.y.49.137 dst=x.y.48.169 sport=35570
> dport=636 src=10.170.0.153 dst=x.y.49.137 sport=636 dport=35570 [ASSURED]
> mark=0 use=1
> ..
>
> bookworm:~$ sudo conntrack -L
> ..
> tcp 6 431388 ESTABLISHED src=x.y.49.137 dst=x.y.48.169 sport=35570
> dport=636 src=153.0.170.10 dst=x.y.49.137 sport=636 dport=35570 [ASSURED]
> mark=0 use=1
> ..
>
> Notice order of the 'src' address bytes.
> When failover occures all TCP connections via secondary balancer are
> broken as packets source addresses don't match those in conntrack
> table anymore.
>
> Downgrade of conntrack and conntrackd packages on Bookworm server
> solved this problem.
> I was unable to create 1.4.7 package for Bullseye.
> I'm not sure which version is considered to be acting correctly.
>
> Core of this problem might be related to
> https://git.netfilter.org/conntrack-tools/commit/?id=b55717d46ae3b7c3769192a66e565bc7c2d833a1
> but I'm not familiar with conntrackd source code.
I believe you are correct in identifying b55717d46ae3 ("conntrackd: fix
endianness bug in IPv4 and IPv6 address"). Before 1.4.7, conntrackd
sent IP addresses in host byte order. However, this prevented one from
running conntrackd instances on hosts of different endianness:
https://marc.info/?l=netfilter=161886262729364=2
This commit changes conntrackd to use network byte order instead. The
consequence, of course, is that little-endian 1.4.6 instances are not
compatible with little-endian 1.4.7 instances.
I believe the upstream switch to NBO is correct, but I'm afraid that we
in Debian didn't spot this consequence. I'll see about getting a notice
added to the package documentation.
J.
signature.asc
Description: PGP signature
Bug#1049304: maildir-utils: Fails to build source after successful build
On 2023-08-13, at 21:20:57 +0200, Lucas Nussbaum wrote: > Source: maildir-utils > Version: 1.8.14-3 > Severity: minor > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-sab-20230813 ftbfs-source-after-build > User: debian...@lists.debian.org > Usertags: qa-doublebuild > > Hi, > > This package fails to build a source package after a successful build > (dpkg-buildpackage ; dpkg-buildpackage -S). > > This is probably a clear violation of Debian Policy section 4.9 (clean > target), > but this is filed as severity:minor for now, because a discussion on > debian-devel showed that we might want to revisit the requirement of a working > 'clean' target. > > More information about this class of issues, included common problems and > solutions, is available at > https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild > > [...] > > The full build log is available from: > http://qa-logs.debian.net/2023/08/13/maildir-utils_1.8.14-3_unstable.log There are some Texinfo output files left over. I've pushed a fix to Salsa. J. signature.asc Description: PGP signature
Bug#1043314: libnftnl: please disable documentation build when not building -doc package
Control: tags -1 + pending On 2023-08-09, at 14:00:40 +0100, Jeremy Sowden wrote: > On 2023-08-09, at 00:12:00 +0100, Simon McVittie wrote: > > Source: libnftnl > > Version: 1.2.6-1 > > Severity: wishlist > > Tags: patch > > > > Similar to libnetfilter-conntrack, libnftnl only needs graphviz (and > > doxygen) for its API documentation, so an easy way to reduce > > dependency chains would be for libnetfilter-conntrack to only build > > its API documentation when "Architecture: all" packages are being > > built. > > > > Please consider the attached patch, with the "Closes" line amended > > to mention this bug report's bug number. I used diffoscope to > > confirm that this change does not alter the contents of either the > > _amd64 or _all binary packages. > > No problem. I'm working through the nf libs that I help maintain. > I'll do this one next. This is ready for upload when you have a minute, Arturo. J. signature.asc Description: PGP signature
Bug#1043314: libnftnl: please disable documentation build when not building -doc package
On 2023-08-09, at 00:12:00 +0100, Simon McVittie wrote: > Source: libnftnl > Version: 1.2.6-1 > Severity: wishlist > Tags: patch > > Similar to libnetfilter-conntrack, libnftnl only needs graphviz > (and doxygen) for its API documentation, so an easy way to reduce > dependency chains would be for libnetfilter-conntrack to only build its > API documentation when "Architecture: all" packages are being built. > > Please consider the attached patch, with the "Closes" line amended to > mention this bug report's bug number. I used diffoscope to confirm that > this change does not alter the contents of either the _amd64 or _all > binary packages. No problem. I'm working through the nf libs that I help maintain. I'll do this one next. J. signature.asc Description: PGP signature
Bug#1043268: libnetfilter-conntrack: please disable documentation build when not building libnetfilter-conntrack-doc
Control: tags -1 + pending On 2023-08-08, at 09:49:15 +0100, Simon McVittie wrote: > Source: libnetfilter-conntrack > Version: 1.0.9-3 > Severity: wishlist > Tags: patch > X-Debbugs-Cc: debian-ri...@lists.debian.org > > The riscv64 port is currently being bootstrapped, and I noticed that > packages like gtk4 are currently unbuildable because they are waiting > for src:systemd. Looking at the dependency chain for src:systemd, > it indirectly depends on libnetfilter-conntrack, which is currently > unbuildable because of a long dependency chain starting with graphviz > (and ending at abseil, which takes a long time to build on riscv64 and > failed several times with timeouts). > > libnetfilter-conntrack only needs graphviz (and doxygen) for its API > documentation, so an easy way to break this dependency chain would be > for libnetfilter-conntrack to only build its API documentation when > "Architecture: all" packages are being built. A side benefit is that > this would make official builds by the buildds a bit faster. > > Please consider applying the attached patch, with the "Closes" line > amended to mention this bug report's bug number. I used diffoscope to > confirm that this change does not alter the contents of either the _amd64 > or _all binary packages. Patch applied. I've added `nodoc` support too. J. signature.asc Description: PGP signature
Bug#1041605: Add Patch
Control: tags -1 + patch
Here's the patch I've sent upstream.
J.
From 3db79bde8fc235c07ae5b397605bd6d1eec1b844 Mon Sep 17 00:00:00 2001
From: Jeremy Sowden
Date: Fri, 21 Jul 2023 14:49:11 +0100
Subject: [PATCH ipset] bash-completion: fix syntax error
There is a syntax error in a redirection:
$ bash -x utils/ipset_bash_completion/ipset
+ shopt -s extglob
utils/ipset_bash_completion/ipset: line 365: syntax error near unexpected token `('
utils/ipset_bash_completion/ipset: line 365: `done < <(PATH=${PATH}:/sbin ( command ip -o link show ) )'
Move the environment variable assignment into the sub-shell.
Fixes: da6242e17583 ("Updated utilities")
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041605
Signed-off-by: Jeremy Sowden
---
utils/ipset_bash_completion/ipset | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils/ipset_bash_completion/ipset b/utils/ipset_bash_completion/ipset
index d258be234806..fc95d4043865 100644
--- a/utils/ipset_bash_completion/ipset
+++ b/utils/ipset_bash_completion/ipset
@@ -362,7 +362,7 @@ _ipset_get_ifnames() {
while read -r; do
REPLY="${REPLY#*: }"
printf "%s\n" ${REPLY%%:*}
-done < <(PATH=${PATH}:/sbin ( command ip -o link show ) 2>/dev/null)
+done < <(( PATH=${PATH}:/sbin command ip -o link show ) 2>/dev/null)
}
_ipset_get_iplist() {
--
2.40.1
signature.asc
Description: PGP signature
Bug#1041605: ipset: bash-completion doesn't work
Control: tags -1 confirmed upstream
On 2023-07-21, at 11:53:36 +0200, Slavko wrote:
> after upgrade to bookworm i noticed that bash-completion for ipset
> stops to work, after quick debug i found this:
>
> LANG=C bash -x /usr/share/bash-completion/completions/ipset
> + shopt -s extglob
> /usr/share/bash-completion/completions/ipset: line 363: syntax error near
> unexpected token `('
> /usr/share/bash-completion/completions/ipset: line 363: `done <
> <(PATH=${PATH}:/sbin ( command ip -o link show ) 2>/dev/null)'
>
> After removing the "()", it can be sourced and completion starts to
> work as expected. I am not bash guru, that i don't know what is
> problem, perhaps the nesting of "()" inside "<()".
I think it is supposed to be:
done < <( ( PATH=${PATH}:/sbin command ip -o link show ) 2>/dev/null)'
I.e., the environment variable should be inside the sub-shell.
I will report it upstream.
Thanks.
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#1040572: wmnut: broken symlink: /usr/share/doc/wmnut/README -> README.asciidoc
On 2023-07-07, at 19:43:23 +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships (or creates) > a broken symlink: > > 0m20.4s ERROR: FAIL: Broken symlinks: > /usr/share/doc/wmnut/README -> README.asciidoc (wmnut) Whoops. Thanks for the pointer. Will fix. J. signature.asc Description: PGP signature
Bug#940960: ITP: linenoise -- Minimal replacement for readline
On 2023-06-14, at 19:55:01 +0800, Blair Noctis wrote: > On 2023-06-12 05:55, Jeremy Sowden wrote: > > On 2023-05-21, at 18:00:45 +0800, Blair Noctis wrote: > >> On Wed, 17 May 2023 18:40:26 +0100 Jeremy Sowden wrote: > >>> It occurs to me that it might make more sense for you to take the lead > >>> in packaging linenoise since you have an interest in getting it into > >>> Debian. Would you like me to transfer ownership of the ITP bug to you? > >>> Happy to lend a hand if you need one. > >> > >> Hmm, can I ask for a review while I upload to mentors.d.n? Wanna make > >> sure I did it right. > > > > Yes, absolutely. Apologies for taking three weeks to reply. > > > > J. > > And I took two days ;) > > Here it goes: https://mentors.debian.net/package/linenoise/ You've gone a for a less elaborate build process for the shared library than I did: https://github.com/antirez/linenoise/pull/174/commits/ab860406520ad7fc5e7e8e91fcf60cdc43a786f0 but that's probably fine. I do have one observation, however. The shared library should be liblinenoise.so.0.0.0 and there should be two sym-links: liblinenoise.so.0, which is needed by the library's dependencies at run-time, and liblinenoise.so which is needed by its dependencies at build-time. I've attached a patch-series with some suggested changes. J. From f240c33394c7d387bc678b81eb0b75af8ee2ac18 Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sat, 17 Jun 2023 20:54:33 +0100 Subject: [PATCH 1/5] d/p/build-in-makefile.patch: get rid of phony `shlib` target We are making the shared library, so use that as the target. --- debian/patches/build-in-makefile.patch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/patches/build-in-makefile.patch b/debian/patches/build-in-makefile.patch index bc1a71598ec2..70e2a3d77b14 100644 --- a/debian/patches/build-in-makefile.patch +++ b/debian/patches/build-in-makefile.patch @@ -6,8 +6,8 @@ This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/Makefile +++ b/Makefile @@ -1,3 +1,6 @@ -+shlib: linenoise.c -+ $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -Wall -g -fPIC -shared -Wl,-soname,liblinenoise.so.0 -o liblinenoise.so.0 linenoise.c ++liblinenoise.so.0: linenoise.c ++ $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -Wall -g -fPIC -shared -Wl,-soname,liblinenoise.so.0 -o $@ $< + linenoise_example: linenoise.h linenoise.c -- 2.39.2 From fa8c5a2b8ea7b3a14b0a207b52b8c958848e73cc Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sat, 17 Jun 2023 20:28:23 +0100 Subject: [PATCH 2/5] d/p/build-in-makefile.patch: use full version number in library file-name A shared library file-name is usually qualified with a major, minor and patch version. * Updating the patch version indicates internal changes. * Updating the minor version indicates the addition of new interfaces to the ABI. * Updating the major version indicates the modification or removal of existing interfaces in the ABI. The SONAME only contains the major version, since this will be embedded in the binaries that depend on the library and updating the major version implies backwardly-incompatible changes. --- debian/patches/build-in-makefile.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/patches/build-in-makefile.patch b/debian/patches/build-in-makefile.patch index 70e2a3d77b14..392014e3e8ac 100644 --- a/debian/patches/build-in-makefile.patch +++ b/debian/patches/build-in-makefile.patch @@ -6,7 +6,7 @@ This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/Makefile +++ b/Makefile @@ -1,3 +1,6 @@ -+liblinenoise.so.0: linenoise.c ++liblinenoise.so.0.0.0: linenoise.c + $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -Wall -g -fPIC -shared -Wl,-soname,liblinenoise.so.0 -o $@ $< + linenoise_example: linenoise.h linenoise.c -- 2.39.2 From 9d0286cac79852d7c0477ef5d36a7d4cc4ad185f Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sat, 17 Jun 2023 21:09:47 +0100 Subject: [PATCH 3/5] d/p/build-in-makefile.patch: put `*FLAGS` variables last The variables should override any defaults. --- debian/patches/build-in-makefile.patch | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/patches/build-in-makefile.patch b/debian/patches/build-in-makefile.patch index 392014e3e8ac..a82b73e7b514 100644 --- a/debian/patches/build-in-makefile.patch +++ b/debian/patches/build-in-makefile.patch @@ -7,7 +7,7 @@ This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +++ b/Makefile @@ -1,3 +1,6 @@ +liblinenoise.so.0.0.0: linenoise.c -+ $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -Wall -g -fPIC -shared -Wl,-soname,liblinenoise.so.0 -o $@ $< ++ $(CC) -Wall -g -fPIC -shared -Wl,-soname,liblinenoise.so.0 $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -o $@ $< + linenoise_example: linenoise.h linenoise.c -- 2.39.2 From ac840a36
Bug#1038264: wmusic: fails to display remaining time for songs longer than 35 minutes
Control: tags -1 +upstream On 2023-06-16, at 21:47:12 +0200, Jan wrote: > Package: wmusic > Version: 2.1.0-2 > Severity: normal > > Dear Maintainer, > > When I play a song that's longer than 35 minutes, the remaining time > indicator fails to display correctly. This is because it overflows the > length field. Attached is a patch to fix the bug. Thanks for the report. The display of the remaining time does seem prone to misbehaving. I'll see about getting it fixed. J. signature.asc Description: PGP signature
Bug#755956: fixed
Control: fixed -1 1.2.3-1 Fixed upstream in 1.2.3: http://git.netfilter.org/libnftnl/commit/?id=84d12cfacf8ddd857a09435f3d982ab6250d250c J. signature.asc Description: PGP signature
Bug#1037991: iptables: LSB-Tags in /etc/init.d/iptables missing
On 2023-06-15, at 10:41:57 +0200, Manfred Brandl wrote: > Package: iptables > Version: 1.8.9-2 > Severity: normal > > Dear Maintainer, > > the last three lines of the output from "apt purge anacron" read: > --- > insserv: warning: script 'iptables' missing LSB tags > insserv: Default-Start undefined, assuming empty start runlevel(s) for script > `iptables' > insserv: Default-Stop undefined, assuming empty stop runlevel(s) for script > `iptables' > --- > > I asked ChatCPT and got the advice to include the following lines into > /etc/init.d/iptables > --- > ### BEGIN INIT INFO > # Provides: iptables > # Required-Start:$network > # Required-Stop: $network > # Default-Start: 2 3 4 5 > # Default-Stop: 0 1 6 > # Short-Description: Start iptables firewall > # Description: Start iptables firewall using saved configuration > ### END INIT INFO > --- > > May I suggest that these lines (or the correct version of them) to be > included in a following version of the package? The iptables package doesn't include an init-script and, TTBOMK, it never has. My guess is that it was installed manually. Does running `dpkg -S /etc/init.d/iptables` identify a package for it? What's in it? J. signature.asc Description: PGP signature
Bug#940960: ITP: linenoise -- Minimal replacement for readline
On 2023-05-21, at 18:00:45 +0800, Blair Noctis wrote: > On Wed, 17 May 2023 18:40:26 +0100 Jeremy Sowden wrote: > > It occurs to me that it might make more sense for you to take the lead > > in packaging linenoise since you have an interest in getting it into > > Debian. Would you like me to transfer ownership of the ITP bug to you? > > Happy to lend a hand if you need one. > > Hmm, can I ask for a review while I upload to mentors.d.n? Wanna make > sure I did it right. Yes, absolutely. Apologies for taking three weeks to reply. J. signature.asc Description: PGP signature
Bug#940960: ITP: linenoise -- Minimal replacement for readline
On 2023-05-14, at 15:00:06 +0800, Blair Noctis wrote: > On 2023/5/14 03:24, Jeremy Sowden wrote: > > I came across linenoise because of a request to support it in nftables. > > The request came from someone who wanted to install nftables in a > > resource-constrained environment where the existing libreadline support > > was too heavyweight. In the case of osquery, would it possible to go > > the other way? Do you think that upstream would be open to adding > > support for libreadline if we offered patches? > > Feasible on the resource level I think, it links to many libraries anyway. But > for using readline… they actually switched away from it in 2016: > https://github.com/osquery/osquery/pull/2613 > > Considering their rather radical approach of vendoring everything, I don't > have > too much hope for that. Ah, right. So much for that idea! It occurs to me that it might make more sense for you to take the lead in packaging linenoise since you have an interest in getting it into Debian. Would you like me to transfer ownership of the ITP bug to you? Happy to lend a hand if you need one. J. signature.asc Description: PGP signature
Bug#940960: ITP: linenoise -- Minimal replacement for readline
I came across linenoise because of a request to support it in nftables. The request came from someone who wanted to install nftables in a resource-constrained environment where the existing libreadline support was too heavyweight. In the case of osquery, would it possible to go the other way? Do you think that upstream would be open to adding support for libreadline if we offered patches? J. signature.asc Description: PGP signature
Bug#940960: ITP: linenoise -- Minimal replacement for readline
On 2023-05-01, at 04:09:16 +0800, Blair Noctis wrote: > It's been a few years since this ITP was filed. Do you still plan to > package it? I'm packaging osquery which depends on this. Happy to > help ;) Thanks for the offer. :) I've cloned the osquery repo and it appears to use the C++ Linenoise NG fork: https://github.com/arangodb/linenoise-ng not the C original: https://github.com/antirez/linenoise which is what I started packaging. The reason that I stopped work on it was that linenoise is intended to be used by adding the sources to the code-base of the application that wants the functionality. I created a PR to add support for building it as a shared library: https://github.com/antirez/linenoise/pull/174 and there has been no response (mind you, there are a lot of open PR's going back years), so I wasn't sure whether it was worth adding to Debian. I've had a quick look at the linenoise-ng repo and it appears to be API-compatible with the original and has a [c]make file, so it may be a better candidate for packaging -- particularly now that you have provided a use-case for it. I'll take a closer look and see how much of my work can be salvaged. J. 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#1032357: shorewall6: sysvinit script for Shorewall6 is broken
This has been fixed in the version of Shorewall in the upcoming release, Bookworm. 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#1030733: shorewall: "shorewall6 start" gives bash error message: "[: 64: unexpected operator" if "ip addr show" has "metric" information
Control: tags -1 confirmed patch upstream
On 2023-02-12, at 11:01:27 +0100, Romain Francoise wrote:
> On Sat, Feb 11, 2023 at 03:37:00PM +0000, Jeremy Sowden wrote:
> > My inclination is just to use awk to pick out the second field. For
> > example,
> >
> > $ ip -f inet6 addr show dev lo | awk '$1 == "inet6" { print $2 }'
> > ::1/128
>
> Yes.
Here's a patch that fixes the parsing that gave rise to this report and
a couple of other similar instances. I stopped at that point 'cause the
remaining instances, which involve picking out broadcast addresses will
still be brittle and complicated even with awk.
> Although all this parsing of `ip' output is fraught with danger,
> ideally Shorewall would use the JSON version (but that requires a
> dependency on `jq' or similar)...
--- a/shorewall/Perl/lib.runtime
+++ b/shorewall/Perl/lib.runtime
@@ -697,7 +697,7 @@
#
find_interface_addresses() # $1 = interface
{
-$IP -f inet addr show $1 2> /dev/null | grep inet\ | sed 's/\s*inet //;s/\/.*//;s/ peer.*//'
+$IP -f inet addr show $1 2> /dev/null | awk '$1 == "inet" { sub(/\/[[:digit:]]+$/, "", $2); print $2 }'
}
#
@@ -1131,7 +1131,7 @@
#
find_interface_addresses() # $1 = interface
{
-$IP -f inet6 addr show $1 2> /dev/null | grep 'inet6 2' | sed 's/\s*inet6 //;s/\/.*//;s/ peer [0-9a-f:]*//'
+$IP -f inet6 addr show $1 2> /dev/null | awk '$1 == "inet6 && $2 ~ /^2/ { sub(/\/[[:digit:]]+$/, "", $2); print $2 }'
}
#
@@ -1140,7 +1140,7 @@
find_interface_full_addresses() # $1 = interface
{
-$IP -f inet6 addr show $1 2> /dev/null | grep 'inet6 ' | sed 's/\s*inet6 //;s/ scope.*//;s/ peer [0-9a-f:]*//'
+$IP -f inet6 addr show $1 2> /dev/null | awk '$1 == "inet6" { print $2 }'
}
#
signature.asc
Description: PGP signature
Bug#1030733: shorewall: "shorewall6 start" gives bash error message: "[: 64: unexpected operator" if "ip addr show" has "metric" information
On 2023-02-12, at 11:01:27 +0100, Romain Francoise wrote:
> On Sat, Feb 11, 2023 at 03:37:00PM +0000, Jeremy Sowden wrote:
> > My inclination is just to use awk to pick out the second field. For
> > example,
> >
> > $ ip -f inet6 addr show dev lo | awk '$1 == "inet6" { print $2 }'
> > ::1/128
>
> Yes. Although all this parsing of `ip' output is fraught with danger,
> ideally Shorewall would use the JSON version (but that requires a
> dependency on `jq' or similar)...
Yes, I came to the same conclusion. My thinking was to broach the topic
upstream at some point in the not too distant future.
J.
signature.asc
Description: PGP signature
Bug#1030733: shorewall: "shorewall6 start" gives bash error message: "[: 64: unexpected operator" if "ip addr show" has "metric" information
On 2023-02-06, at 23:47:37 +0200, Samuli Suonpää wrote:
> Package: shorewall
> Version: 5.2.8-1
> Severity: important
> Tags: ipv6 patch security upstream
> X-Debbugs-Cc: Debian Security Team
>
> Starting ipv6 firewall gives an error message. The firewall still
> starts, though.
>
> $ sudo shorewall6 stop
> Stopping Shorewall6
> /var/lib/shorewall6/firewall: 776: [: 64: unexpected operator
> Preparing ip6tables-restore input...
> Running /sbin/ip6tables-restore --wait 60...
> done.
> $
>
> The problem is in /usr/share/shorewall/lib.runtime which compiles the script.
>
> The line that spills the error message is in funcion
> convert_to_anycast():
>
> while read address; do
> case $address in
> 2*|3*)
> vlsm=${address#*/}
> vlsm=${vlsm:=128}
>
> *** THIS ONE ***if [ $vlsm -le 120 ]; then
> #
> # Defines a viable subnet -- first get the subnet-router
> anycast address
> #
> host=$((128 - $vlsm))
>
> $address and therefore $vlsm should contain the ip address. However, in
> my case it ends up with
>
> 2001:abcd:1234:dead:beef:abcd:1234:/64 metric 256
>
> It seems that function find_interface_full_addresses() in lib.runtime
> expects the ip address in "ip addr show" always be followed by "scope
> global..." etc.
>
> In my case:
>
> $ ip addr show lan0 | grep inet6
> inet6 2001:abcd:1234:dead:beef:abcd:1234:/64 metric 256 scope global
> dynamic mngtmpaddr
>
> This patch should fix the problem. At least it seems to work here.
>
> Samuli
>
> *** 99_fix_find_interface_addresses.patch
> Fix sed inside function find_interface_full_addresses() to also clean up
> "metric" information from ip address.
>
> Pretty much untested and certainly unaudited!!!
> Index: shorewall-5.2.8/shorewall/Perl/lib.runtime
> ===
> --- shorewall-5.2.8.orig/shorewall/Perl/lib.runtime 2023-01-19
> 14:31:25.0 +0200
> +++ shorewall-5.2.8/shorewall/Perl/lib.runtime2023-02-05
> 00:24:17.42400 +0200
> @@ -1140,7 +1140,7 @@
>
> find_interface_full_addresses() # $1 = interface
> {
> -$IP -f inet6 addr show $1 2> /dev/null | grep 'inet6 ' | sed 's/\s*inet6
> //;s/ scope.*//;s/ peer [0-9a-f:]*//'
> +$IP -f inet6 addr show $1 2> /dev/null | grep 'inet6 ' | sed 's/\s*inet6
> //;s/ scope.*//;s/ peer [0-9a-f:]*//;s/ metric [0-9]*//'
> }
>
> #
>
Thanks for the report.
My inclination is just to use awk to pick out the second field. For
example,
$ ip -f inet6 addr show dev lo | awk '$1 == "inet6" { print $2 }'
::1/128
> -- System Information:
> Debian Release: bookworm/sid
> APT prefers testing
> APT policy: (110, 'testing'), (100, 'unstable'), (95, 'experimental'), (80,
> 'stable')
> Architecture: arm64 (aarch64)
>
> Kernel: Linux 6.1.0-3-arm64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_IE:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages shorewall depends on:
> ii bc 1.07.1-3
> ii init-system-helpers 1.65.2
> ii iproute2 6.1.0-1
> ii iptables 1.8.9-2
> ii perl 5.36.0-7
> ii shorewall-core 5.2.8-1
>
> Versions of packages shorewall recommends:
> ii libnetfilter-cthelper0 1.0.1-1
>
> Versions of packages shorewall suggests:
> ii make 4.3-4.1
> pn shorewall-doc
>
> -- Configuration Files:
> /etc/shorewall/conntrack [Errno 13] Permission denied:
> '/etc/shorewall/conntrack'
> /etc/shorewall/params [Errno 13] Permission denied: '/etc/shorewall/params'
> /etc/shorewall/shorewall.conf changed [not included]
>
> -- no debconf information
>
>
signature.asc
Description: PGP signature
Bug#992852: Patch available
Control: forwarded -1 https://gitlab.com/shorewall/code/-/merge_requests/11 Control: tags -1 patch confirmed upstream I've created a patch and sent it upstream. Upstream has not yet merged it, but the response has been positive. J. signature.asc Description: PGP signature
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#986152: Offer of help
On 2023-01-26, at 20:42:16 +0100, Romain Francoise wrote: > Now finally uploaded! (And it didn't go through NEW.) Cool. :) J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-21, at 20:00:05 +0100, Romain Francoise wrote:
> I noticed while testing that you removed the '--no-start' argument to
> dh_installinit calls in the unified package, and that's not right, as
> README.Debian documents.
>
> The situation is even a bit more complex:
>
> * shorewall.postinst and shorewall6.postinst source the config file in
>/etc/default and just exit if 'startup' is not 1. So the postinst bits
>added by debhelper don't get executed at all, even though they exist.
> * shorewall-init.postinst is fully generated by debhelper and does not
>have this logic, so it enables and starts the shorewall-init service
>which by default refuses to start ("ERROR: No products configured"),
>leaving a failed systemd service behind.
>
> I think we should call dh_installinit with '--no-enable --no-start'.
>
> Also, the systemd services don't honor the 'startup' variable in
> /etc/default/shorewall{,6} at all, so it feels wrong for the postinst
> scripts to act differently based on it.
Agreed. Not sure what the thinking was (those changes were initially
made in April, '21). I think we can then remove the shorewall.postinst
and shorewall6.postinst scripts completely.
J.
signature.asc
Description: PGP signature
Bug#986152: Offer of help
On 2023-01-21, at 10:00:33 +0100, Romain Francoise wrote: > On Fri, Jan 20, 2023 at 05:18:19PM -0500, Roberto C. Sánchez wrote: > > I think that the bug is actually assigned to the shorewall-doc binary > > package, not the shorewall-doc source package. Assuming that the > > shorewall source package will start to emit a shorewall-doc binary > > package, I think that the BTS will do the right thing and leaving the > > bug assigned to shorewall-doc is correct. > > That's my understanding as well. Cool. I'll leave it alone then. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-21, at 09:58:13 +0100, Romain Francoise wrote: > On Fri, Jan 20, 2023 at 11:59:44AM +0000, Jeremy Sowden wrote: > > The Developer's Reference, § 5.6.1, expresses the preference that > > when new binary packages are added to a source package, it should be > > uploaded to experimental, so I've updated the version and > > distribution in the change-log entry accordingly. > > But these are not *new* binary packages, so I don't think the upload > will go through NEW. In fact, I hope it won't because there's still > the freeze to consider and I'd really like the new package to be in > bookworm. Ah, right, understood. I'll revert that change then. :) J. signature.asc Description: PGP signature
Bug#588349: Supported in 5.2.7
Control: tags -1 - wontfix + pending Separate columns for sport and dport were introduced in 5.2.7. 5.2.8 will be uploaded in the no too distant future. J. signature.asc Description: PGP signature
Bug#661591: shorewall-init not affected
Control: affects -1 - shorewall-init Shorewall's script always returns zero, afaics. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote: > On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote: > > I've pushed all the work to my repo on Salsa: > > > > https://salsa.debian.org/azazel/shorewall > > > > Do you want to review it before I push to the shorewall-team repo? > > It all looks pretty good to me! In fact, it's a radical improvement > over the previous packaging with seven source packages. > > [...] > > I have not yet actually tested the packages in my lab but please feel > free to push your changes to the team repo, and I will do the final > testing and upload over the week-end. I can also take care of opening > the bugs to have the previous source packages removed from unstable. I was wondering about this shorewall-doc bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266957 Once 5.2.8 is uploaded there won't be a shorewall-doc source package. Shall I reassign it to shorewall? J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote: > On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote: > > I've pushed all the work to my repo on Salsa: > > > > https://salsa.debian.org/azazel/shorewall > > > > Do you want to review it before I push to the shorewall-team repo? > > It all looks pretty good to me! In fact, it's a radical improvement > over the previous packaging with seven source packages. > > I've been staring at the diffoscope output for a few hours and I was > wondering why /etc/network/if-down.d/shorewall seemed to disappear in > shorewall-init but that's actually an upstream change from > 5.2.5-beta1. All the other cleanups and changes look sensible to me, > especially the removal of the debconf bits. Cool. Must play with diffoscope. I was vaguely aware of it, but I don't think I've ever used it. I imagine it would have made comparing the old and new packages easier than the ad hoc methods I have been using. > I have not yet actually tested the packages in my lab but please feel > free to push your changes to the team repo, and I will do the final > testing and upload over the week-end. I can also take care of opening > the bugs to have the previous source packages removed from unstable. All pushed. I made one more change. The Developer's Reference, § 5.6.1, expresses the preference that when new binary packages are added to a source package, it should be uploaded to experimental, so I've updated the version and distribution in the change-log entry accordingly. > Thanks again for the huge amount of work you put in! No problem. I have been tinkering with this for eighteen months on and off, so it will be good to see it in the archive. :) > > The 5.2.8 source package closes the following bugs: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852 > > Awesome. > > > In addition, I think these are candidates for manual closure: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217 > > Yup. You already marked #928912 as fixed, so nothing more to do there. I'll start updating the others over the week-end. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-15, at 22:03:46 +0100, Romain Francoise wrote: > On Sun, Jan 15, 2023 at 10:38:43AM +0000, Jeremy Sowden wrote: > > I've managed to coax gbp into importing 5.2.8 into one upstream > > branch with each upstream tar-ball as a subdirectory. > > > > I'm currently working on merging the debian/ directories. > > Cool! Thanks for working on this. I created two new branches: debian/sid and upstream. The starting point for debian/sid was shorewall/debian/5.2.3.1-1; the upstream branch was empty. I updated debian/gbp.conf and debian/watch so that `gbp import-orig` would import all seven upstream tar-balls into the upstream branch, each unpacked into a separate subdirectory. I then copied the 5.2.3.1-1 packaging from the other six master branches into debian/sid, and applied all the 5.2.8 packaging updates. I've added a README.source and a paragraph in the change-log outlining the change of structure. At this point, I've got seven binary packages built from one source package. Everything's lintian-clean and the Salsa CI pipeline passes. I've pushed all the work to my repo on Salsa: https://salsa.debian.org/azazel/shorewall Do you want to review it before I push to the shorewall-team repo? The 5.2.8 source package closes the following bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852 In addition, I think these are candidates for manual closure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217 J. signature.asc Description: PGP signature
Bug#928912: README.Debian updated in 5.1.8.1-1
Control: fixed -1 shorewall/5.1.8.1-1 The explanation in README.Debian of how to enable shorewall on boot was updated to include systemd in 5.1.8.1-1. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-09, at 08:51:54 -0500, Roberto C. Sánchez wrote: > On Sat, Jan 07, 2023 at 12:48:08PM +0100, Romain Francoise wrote: > > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > > > I've imported my fork of Roberto's SF repo to Salsa: > > > > > > https://salsa.debian.org/azazel/shorewall > > > > > > I haven't touched it in 18 months, so I'll give it a polish when I > > > have some time, and perhaps we can use it as a starting point. > > > > Thanks. I created a Salsa team and repo here: > > https://salsa.debian.org/shorewall-team/shorewall and added you both > > as co-owners. > > > > I felt more comfortable using Roberto's original SF repo as a > > starting point, and merging in your changes after review. I can do > > that in the next few days, the freeze is coming up very soon and I > > would like to have the new upstream in bookworm. If you have further > > changes please push them to your repo. > > > > I'll also configure the CI on Salsa to have all the usual QA tools > > run automatically on each push. > > > > Did you find a practical way to do changes across all seven source > > packages at once? > > For a bit of historical context, the current multi-branch structure > from the SF repo is quite antiquiated. It is from a time before > debhelper supported multiple .orig.tar.gz components. It might make > sense to consider starting with a new repo, with a more sensible > branch structure (one that works more easily with tools like gbp), and > that makes use of the multi-tarball capabilities so that you have have > all the source packages in view at the same time. I've managed to coax gbp into importing 5.2.8 into one upstream branch with each upstream tar-ball as a subdirectory: [azazel@ulthar:/space/azazel/work/git/repos/salsa/azazel/shorewall (master>)] $ ls -1 debian/ shorewall/ shorewall6/ shorewall6-lite/ shorewall-core/ shorewall-docs-xml/ shorewall-init/ shorewall-lite/ I'm currently working on merging the debian/ directories. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-08, at 14:35:17 +, Jeremy Sowden wrote: > On 2023-01-07, at 12:48:08 +0100, Romain Francoise wrote: > > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > > > I've imported my fork of Roberto's SF repo to Salsa: > > > > > > https://salsa.debian.org/azazel/shorewall > > > > > > I haven't touched it in 18 months, so I'll give it a polish when I have > > > some time, and perhaps we can use it as a starting point. > > > > Thanks. I created a Salsa team and repo here: > > https://salsa.debian.org/shorewall-team/shorewall and added you both > > as co-owners. > > Thanks. I've created a Shorewall team on tracker.d.o and added you both > to it. > > > I felt more comfortable using Roberto's original SF repo as a starting > > point, and merging in your changes after review. I can do that in the > > next few days, the freeze is coming up very soon and I would like to > > have the new upstream in bookworm. If you have further changes please > > push them to your repo. > > Cool. I've started making a few more changes to my repo. I'll let you > know when I've pushed everything to Salsa. Should be later this week. I've pushed the recent changes. It's just mechanical updates and Lintian fixes. I haven't taken a proper look at bugs.debian.org yet. > > I'll also configure the CI on Salsa to have all the usual QA tools run > > automatically on each push. > > > > Did you find a practical way to do changes across all seven source > > packages at once? > > Not yet. Atm, I've just been updating the shorewall/master branch then > cherry-picking those commits into the other branches. Once 5.2.8-1 is > ready to go, perhaps we can come up with a way to get everything into > one source package with one master branch. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-07, at 12:48:08 +0100, Romain Francoise wrote: > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > > I've imported my fork of Roberto's SF repo to Salsa: > > > > https://salsa.debian.org/azazel/shorewall > > > > I haven't touched it in 18 months, so I'll give it a polish when I have > > some time, and perhaps we can use it as a starting point. > > Thanks. I created a Salsa team and repo here: > https://salsa.debian.org/shorewall-team/shorewall and added you both > as co-owners. Thanks. I've created a Shorewall team on tracker.d.o and added you both to it. > I felt more comfortable using Roberto's original SF repo as a starting > point, and merging in your changes after review. I can do that in the > next few days, the freeze is coming up very soon and I would like to > have the new upstream in bookworm. If you have further changes please > push them to your repo. Cool. I've started making a few more changes to my repo. I'll let you know when I've pushed everything to Salsa. Should be later this week. > I'll also configure the CI on Salsa to have all the usual QA tools run > automatically on each push. > > Did you find a practical way to do changes across all seven source > packages at once? Not yet. Atm, I've just been updating the shorewall/master branch then cherry-picking those commits into the other branches. Once 5.2.8-1 is ready to go, perhaps we can come up with a way to get everything into one source package with one master branch. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-03, at 22:06:03 +, Jeremy Sowden wrote: > On 2023-01-02, at 18:08:57 +0100, Romain Francoise wrote: > > [Cc'ing Roberto directly to make sure he's aware of this > > discussion.] > > > > I'm also a Shorewall[6] user and while the state of the package > > isn't really alarming right now, I need it to be properly maintained > > going forward. > > > > We could set up a pkg-shorewall team on Salsa and co-maintain the > > packages there. Jeremy, would that work for you? > > Absolutely. I've imported my fork of Roberto's SF repo to Salsa: https://salsa.debian.org/azazel/shorewall I haven't touched it in 18 months, so I'll give it a polish when I have some time, and perhaps we can use it as a starting point. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
On 2023-01-02, at 18:08:57 +0100, Romain Francoise wrote: > [Cc'ing Roberto directly to make sure he's aware of this discussion.] > > I'm also a Shorewall[6] user and while the state of the package isn't > really alarming right now, I need it to be properly maintained going > forward. > > We could set up a pkg-shorewall team on Salsa and co-maintain the > packages there. Jeremy, would that work for you? Absolutely. J. signature.asc Description: PGP signature
Bug#896716: Fix submitted upstream
I've sent a fix upstream. J. signature.asc Description: PGP signature
Bug#896716: Confirmed
Control: tag -1 confirmed I don't have a MIPS environment to hand, but I do have a Stretch s390x VM, so on the assumption that this is an endianness bug, I tried to replicate it there -- successfully. I manually added and removed an ICMP flow with conntrack: azazel@debian-s390x:~$ sudo conntrack -I --src 192.168.122.123 --dst 192.168.96.1 --protonum icmp --timeout 120 --icmp-type 8 --icmp-code 0 conntrack v1.4.4 (conntrack-tools): 1 flow entries have been created. azazel@debian-s390x:~$ sudo conntrack -D icmp 1 118 src=0.0.0.0 dst=0.0.0.0 type=0 code=0 id=0 [UNREPLIED] src=0.0.0.0 dst=0.0.0.0 type=0 code=0 id=0 mark=0 use=1 conntrack v1.4.4 (conntrack-tools): 1 flow entries have been deleted. and the test programme output the following: azazel@debian-s390x:~/tmp$ sudo ./ct_filter [UPDATE] icmp 1 120 src=0.0.0.0 dst=0.0.0.0 type=0 code=0 id=0 [UNREPLIED] src=0.0.0.0 dst=0.0.0.0 type=0 code=0 id=0 mark=0 [DESTROY] icmp 1 src=0.0.0.0 dst=0.0.0.0 type=0 code=0 id=0 [UNREPLIED] src=0.0.0.0 dst=0.0.0.0 type=0 code=0 id=0 By contrast, nothing was output when doing the same on an amd64 host. J. signature.asc Description: PGP signature
Bug#986152: Offer of help
Another ping. Offer still stands. J. signature.asc Description: PGP signature
Bug#965990: Won't fix
Control: tags -1 +wontfix The `export` command was removed in nftables v0.9.1. J. signature.asc Description: PGP signature
Bug#805940: Wrong diagnosis
Actually, the warning is still present, but I've got to the bottom of why it's occurring. Details in https://bugs.debian.org/731638. J. signature.asc Description: PGP signature
Bug#731638: Wrong diagnosis
Actually, I've just realized that we've all been barking up the wrong tree here. The problem has nothing to do with the transition from ulogd to ulogd2. For example, here's a fresh install of the package currently in testing: $ apt-cache policy ulogd2 ulogd2: Installed: (none) Candidate: 2.0.7-1+b3 Version table: 2.0.7-1+b3 990 990 http://mirror.ox.ac.uk/debian testing/main amd64 Packages 990 http://ftp.uk.debian.org/debian testing/main amd64 Packages 990 http://ftp.debian.org/debian testing/main amd64 Packages 99 http://mirror.ox.ac.uk/debian unstable/main amd64 Packages 99 http://ftp.uk.debian.org/debian unstable/main amd64 Packages 99 http://ftp.debian.org/debian unstable/main amd64 Packages 2.0.7-1+b1 900 900 http://mirror.ox.ac.uk/debian stable/main amd64 Packages 900 http://ftp.uk.debian.org/debian stable/main amd64 Packages 900 http://ftp.debian.org/debian stable/main amd64 Packages $ ls -ld /var/log/ulog ls: cannot access '/var/log/ulog': No such file or directory $ sudo apt-get install ulogd2 Reading package lists... Done Building dependency tree... Done Reading state information... Done Suggested packages: ulogd2-dbi ulogd2-json ulogd2-mysql ulogd2-pcap ulogd2-pgsql ulogd2-sqlite3 The following NEW packages will be installed: ulogd2 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/108 kB of archives. After this operation, 569 kB of additional disk space will be used. Selecting previously unselected package ulogd2. (Reading database ... 585103 files and directories currently installed.) Preparing to unpack .../ulogd2_2.0.7-1+b3_amd64.deb ... Unpacking ulogd2 (2.0.7-1+b3) ... Setting up ulogd2 (2.0.7-1+b3) ... adduser: Warning: The home dir /var/log/ulog you specified already exists. adduser: The home directory `/var/log/ulog' already exists. Not copying from `/etc/skel'. adduser: Warning: The home directory `/var/log/ulog' does not belong to the user you are currently creating. The problem is the source package lists /var/log/ulog in ulogd2.dirs, so dh_installdir creates it with ownership `root:root` and mode `u=rwx,go=rx` and it is present in the binary package: $ dpkg-deb --contents /var/cache/apt/archives/ulogd2_2.0.7-1+b3_amd64.deb | grep /var/log/ulog drwxr-xr-x root/root 0 2022-10-16 11:37 ./var/log/ulog/ On a fresh install, therefore, when the package is unpacked the directory is created with the wrong ownership and permissions. Thereafter, adduser runs and complains about it. However, since 2.0.5-5, the postinst script has called mkdir to create the directory again and then fixed up the ownership and permissions, so although the warning is still present, in the end the directory is correctly set up. J. signature.asc Description: PGP signature
Bug#805940: Proposal to close
If no one has any objections, I'm going to close this bug report for two reasons. Firstly, it relates to the transition from ulogd to ulogd2 which took place in Jessie, and so it shouldn't be relevant anymore. Additionally, I believe that it was fixed by this change: --- a/debian/ulogd2.postinst +++ b/debian/ulogd2.postinst @@ -17,5 +17,17 @@ if [ -x "/etc/init.d/ulogd" ]; then update-rc.d -f ulogd remove >/dev/null fi +case "$1" in +configure) + # Set ownership and permissions on /var/log/ulog for new installs or + # upgrades from << 2.0.5-5 + if dpkg --compare-versions "$2" lt '2.0.5-5~'; then + mkdir -p /var/log/ulog + chown ulog:adm /var/log/ulog + chmod u=rwx,g=rx,o= /var/log/ulog + fi + ;; +esac + #DEBHELPER# which was introduced in 2.0.5-5 to fix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846843 J. signature.asc Description: PGP signature
Bug#731638: Proposal to close
If no one has any objections, I'm going to close this bug report for two reasons. Firstly, it relates to the transition from ulogd to ulogd2 which took place in Jessie, and so it shouldn't be relevant anymore. Additionally, I believe that it was fixed by this change: --- a/debian/ulogd2.postinst +++ b/debian/ulogd2.postinst @@ -17,5 +17,17 @@ if [ -x "/etc/init.d/ulogd" ]; then update-rc.d -f ulogd remove >/dev/null fi +case "$1" in +configure) + # Set ownership and permissions on /var/log/ulog for new installs or + # upgrades from << 2.0.5-5 + if dpkg --compare-versions "$2" lt '2.0.5-5~'; then + mkdir -p /var/log/ulog + chown ulog:adm /var/log/ulog + chmod u=rwx,g=rx,o= /var/log/ulog + fi + ;; +esac + #DEBHELPER# which was introduced in 2.0.5-5 to fix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846843 J. signature.asc Description: PGP signature
Bug#916998: Mostly fixed upstream
The new 2.0.8 release includes an overhaul of the build-system which introduces pkg-config support for libpq and libmysqlclient, and replaces the previous fall-back code where pkg-config is not available. It should fix the cross-build problems, although I have just spotted a bug in the libpq implementation (thanks to this report) for which I have sent a patch (attached) upstream. J. From 981988f08864ae26b2e8c3993172ce68be2b84eb Mon Sep 17 00:00:00 2001 From: Jeremy Sowden Date: Sun, 11 Dec 2022 16:37:49 + Subject: [PATCH ulogd2] build: fix pgsql fall-back configuration of CFLAGS When using mysql_config and pcap_config to configure `CFLAGS`, one requests the actual flags: $mysql_config --cflags $pcap_config --cflags By constrast, when using pg_config, one requests the include-directory: $pg_config --includedir Therefore, the `-I` option has to be explicitly added. Signed-off-by: Jeremy Sowden --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 6ee29ce321d0..70eed9dc1745 100644 --- a/configure.ac +++ b/configure.ac @@ -92,7 +92,7 @@ AS_IF([test "x$enable_pgsql" != "xno"], [ AS_IF([command -v "$pg_config" >/dev/null], [ - libpq_CFLAGS="`$pg_config --includedir`" + libpq_CFLAGS="-I`$pg_config --includedir`" libpq_LIBS="`$pg_config --libdir` -lpq" AC_SUBST([libpq_CFLAGS]) -- 2.35.1 signature.asc Description: PGP signature
Bug#1017723: bullseye-pu: package nftables/0.9.8-3.2
On 2022-09-04, at 15:09:10 +0100, Jeremy Sowden wrote:
> On 2022-09-03, at 14:53:45 +0100, Adam D. Barratt wrote:
> > On Fri, 2022-08-19 at 16:05 +0100, Jeremy Sowden wrote:
> > > The related nftables bug is:
> > >
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017359
> > >
> > > [ Reason ]
> > > nftables uses a fixed-size array containing the locations of the
> > > expressions within each rule that it sends to the kernel to provide
> > > more informative error-reporting. If the rule is rejected by the
> > > kernel, the kernel will provide an ID for the expression which was
> > > responsible, and nftables will use this to highlight it when
> > > outputting the rule in the error message:
> > >
> > > # nft add rule t c iif lo reject with icmp 255
> > > Error: Could not process rule: Invalid argument
> > > add rule t c iif lo reject with icmp 255
> > > ^^
> > >
> > > There is an off-by-one error in the bounds-checking used before
> > > adding the details of an expression to this array. The result of
> > > this is that if a rule contains enough expressions, nftables will
> > > write past the end of the array leading to memory-corruption and
> > > possibly crashes.
> >
> > The debdiff is somewhat confusing.
> >
> > +nftables (0.9.8-3.2) unstable; urgency=medium
> >
> > This is an upload to bullseye, not unstable. Additionally, the version
> > should be 0.9.8-3.1+deb11u1.
> >
> > + -- Sven Auhagen Sat, 16 Jul 2022 11:29:27
> > +0200
> >
> > Who is this? It's obviously not you, but also doesn't appear to be
> > related to the nftables bug report you mentioned.
>
> Whoops. Silly mistakes. Still learning the ropes. I've amended the
> change-log entry.
>
> I've also added myself to `Uploaders` (I am already listed as one in
> testing and unstable).
>
> New debdiff attached.
Is there anything more I can to do to get a decision on this bug? Or do
I just need to be more patient? :)
J.
> diff -Nru nftables-0.9.8/debian/changelog nftables-0.9.8/debian/changelog
> --- nftables-0.9.8/debian/changelog 2021-07-20 09:01:47.0 +0100
> +++ nftables-0.9.8/debian/changelog 2022-09-04 09:34:11.0 +0100
> @@ -1,3 +1,14 @@
> +nftables (0.9.8-3.1+deb11u1) bullseye; urgency=medium
> +
> + * d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
> +It fixes a one off for the check for NFT_NLATTR_LOC_MAX
> +which leads to double free or corruption (out) error.
> +Thanks to Sven Auhagen for
> +suggesting the fix (closes: #1017359).
> + * d/control: add myself to uploaders.
> +
> + -- Jeremy Sowden Sun, 04 Sep 2022 09:34:11 +0100
> +
> nftables (0.9.8-3.1) unstable; urgency=medium
>
>* Non-maintainer upload.
> diff -Nru nftables-0.9.8/debian/control nftables-0.9.8/debian/control
> --- nftables-0.9.8/debian/control 2021-07-20 09:01:47.0 +0100
> +++ nftables-0.9.8/debian/control 2022-09-04 09:34:11.0 +0100
> @@ -2,7 +2,8 @@
> Section: net
> Priority: important
> Maintainer: Debian Netfilter Packaging Team
>
> -Uploaders: Arturo Borrero Gonzalez
> +Uploaders: Arturo Borrero Gonzalez ,
> + Jeremy Sowden
> Build-Depends: asciidoc-base,
> automake,
> bison,
> diff -Nru
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
>
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
> ---
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
> 1970-01-01 01:00:00.0 +0100
> +++
> nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
> 2022-09-04 09:26:53.0 +0100
> @@ -0,0 +1,32 @@
> +From 2d0a7a9adeb30708d6fbbee57476c0d4b9214dbd Mon Sep 17 00:00:00 2001
> +From: Phil Sutter
> +Date: Fri, 11 Jun 2021 17:08:34 +0200
> +Subject: rule: Fix for potential off-by-one in cmd_add_loc()
> +
> +Using num_attrs as index means it must be at max one less than the
> +array's size at function start.
> +
> +Fixes: 27362a5bfa433 ("rule: larger number of error locations")
> +Signed-off-by: Phil Sutter
> +---
> + src/rule.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +(limited to 'src/rule.c')
> +
> +diff --git a/src/rule.c b/src/rule.c
> +index dbbe744e..92daf2f3 100644
> +--- a/src/rule.c
> b/src/rule.c
> +@@ -1275,7 +1275,7 @@ struct cmd *cmd_alloc(enum cmd_ops op, enum cmd_obj
> obj,
> +
Bug#1018156: nftables: list ruleset shows negative ipv6 address
On 2022-08-25, at 23:14:12 -0500, Ross Johnson wrote:
> Package: nftables
> Version: 0.9.8-3.1
> Severity: normal
> X-Debbugs-Cc: r...@homemail.org
>
> Dear Maintainer,
>
> As shown below, I created a file call "junk" that makes a few simple nftables
> chains.
> When I list the chains, nftables shows what looks like a negative number in
> the last one.
> I would expect it to show the canonical form of ff00::/8 as given in the
> previous line.
> This simple example is extracted from a complex script to show the problem
> concisely.
>
> root@biden:/srv/nftables# cat junk
> #!/usr/sbin/nft -f
>
> flush ruleset
> table ip6 whatever {
> chain junk {
> ip6 saddr ff00::/8 drop
> ip6 saddr fe80::/10 drop
> ip6 saddr { ff00::/8, fe80::/10 } drop
> }
> }
> root@biden:/srv/nftables# /sbin/nft -f junk
> root@biden:/srv/nftables# /sbin/nft list ruleset
> table ip6 whatever {
> chain junk {
> ip6 saddr ff00::/8 drop
> ip6 saddr fe80::/10 drop
> ip6 saddr { fe80::/10,
> ff00::-::::::: } drop
> }
> }
> root@biden:/srv/nftables#
I've sent a patch upstream to fix this, but one thing to point out is
that what we see here is not a garbled address with a negative number
embedded in it, but a range (ff00:: to ::...:). It's more
obvious (to me at least) with an IPv4 prefix.
ip saddr { 10.0.0.0/8, 192.0.0.0/2 } drop
becomes:
ip saddr { 10.0.0.0/8, 192.0.0.0-255.255.255.255 } drop
J.
signature.asc
Description: PGP signature
Bug#1017723: bullseye-pu: package nftables/0.9.8-3.2
On 2022-09-03, at 14:53:45 +0100, Adam D. Barratt wrote:
> On Fri, 2022-08-19 at 16:05 +0100, Jeremy Sowden wrote:
> > The related nftables bug is:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017359
> >
> > [ Reason ]
> > nftables uses a fixed-size array containing the locations of the
> > expressions within each rule that it sends to the kernel to provide
> > more informative error-reporting. If the rule is rejected by the
> > kernel, the kernel will provide an ID for the expression which was
> > responsible, and nftables will use this to highlight it when
> > outputting the rule in the error message:
> >
> > # nft add rule t c iif lo reject with icmp 255
> > Error: Could not process rule: Invalid argument
> > add rule t c iif lo reject with icmp 255
> > ^^
> >
> > There is an off-by-one error in the bounds-checking used before
> > adding the details of an expression to this array. The result of
> > this is that if a rule contains enough expressions, nftables will
> > write past the end of the array leading to memory-corruption and
> > possibly crashes.
>
> The debdiff is somewhat confusing.
>
> +nftables (0.9.8-3.2) unstable; urgency=medium
>
> This is an upload to bullseye, not unstable. Additionally, the version
> should be 0.9.8-3.1+deb11u1.
>
> + -- Sven Auhagen Sat, 16 Jul 2022 11:29:27 +0200
>
> Who is this? It's obviously not you, but also doesn't appear to be
> related to the nftables bug report you mentioned.
Whoops. Silly mistakes. Still learning the ropes. I've amended the
change-log entry.
I've also added myself to `Uploaders` (I am already listed as one in
testing and unstable).
New debdiff attached.
Thanks for the pointers,
J.
diff -Nru nftables-0.9.8/debian/changelog nftables-0.9.8/debian/changelog
--- nftables-0.9.8/debian/changelog 2021-07-20 09:01:47.0 +0100
+++ nftables-0.9.8/debian/changelog 2022-09-04 09:34:11.0 +0100
@@ -1,3 +1,14 @@
+nftables (0.9.8-3.1+deb11u1) bullseye; urgency=medium
+
+ * d/p/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
+It fixes a one off for the check for NFT_NLATTR_LOC_MAX
+which leads to double free or corruption (out) error.
+Thanks to Sven Auhagen for
+suggesting the fix (closes: #1017359).
+ * d/control: add myself to uploaders.
+
+ -- Jeremy Sowden Sun, 04 Sep 2022 09:34:11 +0100
+
nftables (0.9.8-3.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru nftables-0.9.8/debian/control nftables-0.9.8/debian/control
--- nftables-0.9.8/debian/control 2021-07-20 09:01:47.0 +0100
+++ nftables-0.9.8/debian/control 2022-09-04 09:34:11.0 +0100
@@ -2,7 +2,8 @@
Section: net
Priority: important
Maintainer: Debian Netfilter Packaging Team
-Uploaders: Arturo Borrero Gonzalez
+Uploaders: Arturo Borrero Gonzalez ,
+ Jeremy Sowden
Build-Depends: asciidoc-base,
automake,
bison,
diff -Nru
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
---
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
1970-01-01 01:00:00.0 +0100
+++
nftables-0.9.8/debian/patches/rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
2022-09-04 09:26:53.0 +0100
@@ -0,0 +1,32 @@
+From 2d0a7a9adeb30708d6fbbee57476c0d4b9214dbd Mon Sep 17 00:00:00 2001
+From: Phil Sutter
+Date: Fri, 11 Jun 2021 17:08:34 +0200
+Subject: rule: Fix for potential off-by-one in cmd_add_loc()
+
+Using num_attrs as index means it must be at max one less than the
+array's size at function start.
+
+Fixes: 27362a5bfa433 ("rule: larger number of error locations")
+Signed-off-by: Phil Sutter
+---
+ src/rule.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+(limited to 'src/rule.c')
+
+diff --git a/src/rule.c b/src/rule.c
+index dbbe744e..92daf2f3 100644
+--- a/src/rule.c
b/src/rule.c
+@@ -1275,7 +1275,7 @@ struct cmd *cmd_alloc(enum cmd_ops op, enum cmd_obj obj,
+
+ void cmd_add_loc(struct cmd *cmd, uint16_t offset, const struct location *loc)
+ {
+- if (cmd->num_attrs > NFT_NLATTR_LOC_MAX)
++ if (cmd->num_attrs >= NFT_NLATTR_LOC_MAX)
+ return;
+
+ cmd->attr[cmd->num_attrs].offset = offset;
+--
+cgit v1.2.3
+
diff -Nru nftables-0.9.8/debian/patches/series
nftables-0.9.8/debian/patches/series
--- nftables-0.9.8/debian/patches/series2021-07-20 09:01:47.0
+0100
+++ nftables-0.9.8/debian/patches/series2022-09-04 09:26:53.0
+0100
@@ -1 +1,2 @@
payload-check-icmp-dependency-before-removing-previo.patch
+rule_fix_for_potential_off-by-one_in_cmd_add_loc.patch
signature.asc
Description: PGP signature
Bug#1018022: wmhdplop: FTBFS with imlib2 1.9.1
On 2022-08-24, at 13:04:32 +0200, Markus Koschany wrote: > Package: wmhdplop > Version: 0.9.11-3 > Severity: important > Tags: ftbfs sid bookwork > User: a...@debian.org > Usertags: imlib2-1.9.1 > X-Debbugs-Cc: a...@debian.org > > Dear maintainer, > > your package fails to build from source with imlib2 1.9.1 in > experimental. imlib2-config has been dropped by upstream in favor of > pkg-config. Please adjust your build system accordingly. I intend to > upload imlib2 1.9.1 to unstable in one or two months. Feel free to > reply to this bug report if you have any questions. I've sent some patches upstream. Once they've been reviewed and applied, I'll arrange a new upstream release. J. signature.asc Description: PGP signature
Bug#1018020: wmcoincoin: FTBFS with imlib2 1.9.1
On 2022-08-24, at 19:14:03 +0200, Andreas Metzler wrote: > On 2022-08-24 Jeremy Sowden wrote: > [...] > > I've added a couple of patches to use pkg-config in preference to > > imlib2-config. > > imlib2 in Debian even in oldoldstable ships a .pc file and looking at > the changelog is has done so for ages, it is mentioned in a entry > dating from 2003. Is there any value in prefering pkg-config instead > of using it *instead* of imlib2-config and simplifying the configure > scripts? My thinking was to create patches which could be sent upstream as-is, rather than specifically targetting Debian (which is why I split the changes into two). However, given that imlib2 has had pkg-config support since 2003, I can't imagine upstream will mind removing the imlib2-config stuff altogether. I am in the process of creating a patch-set to update the autotooling for upstream; I shall update it as you suggest, and then update the Debian patches. Thanks for the info. J. signature.asc Description: PGP signature
Bug#1018020: wmcoincoin: FTBFS with imlib2 1.9.1
On 2022-08-24, at 12:56:27 +0200, Markus Koschany wrote: > Package: wmcoincoin > Version: 2.6.5.git+23.411d4a3-1 > Severity: important > Tags: ftbfs sid bookworm > User: a...@debian.org > Usertags: imlib2-1.9.1 > X-Debbugs-Cc: a...@debian.org > > Dear maintainer, > > your package fails to build from source with imlib2 1.9.1 in > experimental. imlib2-config has been dropped by upstream in favor of > pkg-config. Please adjust your build system accordingly. I intend to > upload imlib2 1.9.1 to unstable in one or two months. Feel free to > reply to this bug report if you have any questions. I've added a couple of patches to use pkg-config in preference to imlib2-config. J. signature.asc Description: PGP signature
