Bug#1066944: FTBFS on 32-bit arches with 64-bit time_t

[Amin Bandali]

Source: ulfius
Version: 2.7.15-2.1
Severity: serious
Tags: ftbfs patch upstream fixed-upstream
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=ulfius=armel=2.7.15-2.1=1709168616=0

/<>/src/u_websocket.c: In function ‘ulfius_websocket_wait_close’:
/<>/src/u_websocket.c:2316:28: error: conversion from ‘long long 
int’ to ‘long int’ may change value [-Werror=conversion]
 2316 | abstime.tv_nsec += (((time_t)timeout%1000) * 100);
  |^

>From 9457809a5321ca4a87f19fdc3f7f4af68e72afa8 Mon Sep 17 00:00:00 2001
From: Nicolas Mora 
Date: Wed, 28 Feb 2024 20:36:03 -0500
Subject: [PATCH] Fix timespec.tv_nsec value conversion

---
 src/u_websocket.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/u_websocket.c b/src/u_websocket.c
index efca309..771f872 100644
--- a/src/u_websocket.c
+++ b/src/u_websocket.c
@@ -2322,7 +2322,7 @@ int ulfius_websocket_wait_close(struct _websocket_manager * websocket_manager, u
   if (timeout) {
 clock_gettime(CLOCK_REALTIME, );
 abstime.tv_sec += ((time_t)timeout / 1000);
-abstime.tv_nsec += (((time_t)timeout%1000) * 100);
+abstime.tv_nsec += long int)timeout)%1000) * 100);
 if (abstime.tv_nsec > 9) {
   abstime.tv_nsec %= 10;
   abstime.tv_sec ++;
-- 
2.43.0

Bug#1066905: FTBFS on 32-bit arches with 64-bit time_t

[Amin Bandali]

Control: tags -1 patch

Please find attached the debdiff for the incoming NMU for this.
diff -Nru lirc-0.10.2/debian/changelog lirc-0.10.2/debian/changelog
--- lirc-0.10.2/debian/changelog2024-02-28 16:15:12.0 -0500
+++ lirc-0.10.2/debian/changelog2024-03-15 06:21:53.0 -0400
@@ -1,3 +1,12 @@
+lirc (0.10.2-0.8) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/fix-ftbfs-32bit-arches-64bit-time_t.patch: Add
+upstream patch to fix FTBFS on 32-bit arches with 64-bit time_t.
+(Closes: #1066905)
+
+ -- Amin Bandali   Fri, 15 Mar 2024 06:21:53 -0400
+
 lirc (0.10.2-0.7) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lirc-0.10.2/debian/patches/fix-ftbfs-32bit-arches-64bit-time_t.patch 
lirc-0.10.2/debian/patches/fix-ftbfs-32bit-arches-64bit-time_t.patch
--- lirc-0.10.2/debian/patches/fix-ftbfs-32bit-arches-64bit-time_t.patch
1969-12-31 19:00:00.0 -0500
+++ lirc-0.10.2/debian/patches/fix-ftbfs-32bit-arches-64bit-time_t.patch
2024-03-15 05:59:32.0 -0400
@@ -0,0 +1,71 @@
+From c23dd2512a4dbb3944f5494d26b40d6f25a27faf Mon Sep 17 00:00:00 2001
+From: Rudi Heitbaum 
+Date: Wed, 20 Jul 2022 07:36:38 +
+Subject: [PATCH] migrate struct input_event.time to .input_event_sec and
+ .input_event_usec
+
+This allows compiling lircd as 32-bit userland with the Y2038 safe
+options - -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
+
+ref: https://lkml.org/lkml/2018/1/6/324
+
+struct timeval is not y2038 safe.
+All usage of timeval in the kernel will be replaced by
+y2038 safe structures.
+The change is also necessary as glibc is introducing support
+for 32 bit applications to use 64 bit time_t. Without this
+change, many applications would incorrectly interpret values
+in the struct input_event.
+More details about glibc at
+https://sourceware.org/glibc/wiki/Y2038ProofnessDesign .
+
+struct input_event maintains time for each input event.
+Real time timestamps are not ideal for input as this
+time can go backwards as noted in the patch a80b83b7b8
+by John Stultz. Hence, having the input_event.time fields
+only big enough for monotonic and boot times are
+sufficient.
+
+The change leaves the representation of struct input_event as is
+on 64 bit architectures. But uses 2 unsigned long values on 32 bit
+machines to support real timestamps until year 2106.
+This intentionally breaks the ABI on 32 bit architectures and
+compat handling on 64 bit architectures.
+This is as per maintainer's preference to introduce compile time errors
+rather than run into runtime incompatibilities.
+
+The change requires any 32 bit userspace utilities reading or writing
+from event nodes to update their reading format to match the new
+input_event. The changes to the popular libraries will be posted once
+we agree on the kernel change.
+---
+ plugins/devinput.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/plugins/devinput.c b/plugins/devinput.c
+index 70220483..e6bd335d 100644
+--- a/plugins/devinput.c
 b/plugins/devinput.c
+@@ -51,6 +51,10 @@
+ #define LONG(x) ((x) / BITS_PER_LONG)
+ #define test_bit(bit, array)((array[LONG(bit)] >> OFF(bit)) & 1)
+ 
++#ifndef input_event_sec
++#define input_event_sec time.tv_sec
++#define input_event_usec time.tv_usec
++#endif
+ 
+ static const logchannel_t logchannel = LOG_DRIVER;
+ 
+@@ -458,7 +462,7 @@ char* devinput_rec(struct ir_remote* remotes)
+   return 0;
+   }
+ 
+-  log_trace("time %ld.%06ld  type %d  code %d  value %d", 
event.time.tv_sec, event.time.tv_usec, event.type,
++  log_trace("time %ld.%06ld  type %d  code %d  value %d", 
event.input_event_sec, event.input_event_usec, event.type,
+ event.code, event.value);
+ 
+   value = (unsigned)event.value;
+-- 
+2.43.0
+
diff -Nru lirc-0.10.2/debian/patches/series lirc-0.10.2/debian/patches/series
--- lirc-0.10.2/debian/patches/series   2024-01-17 08:21:20.0 -0500
+++ lirc-0.10.2/debian/patches/series   2024-03-15 06:03:52.0 -0400
@@ -7,3 +7,4 @@
 0013-drop-ubuntu-hack.patch
 0014-fix-zotac-poll.patch
 include_media_lirc.h.diff
+fix-ftbfs-32bit-arches-64bit-time_t.patch

Bug#1066905: FTBFS on 32-bit arches with 64-bit time_t

[Amin Bandali]

Source: lirc
Version: 0.10.2-0.7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

In file included from ../lib/lirc_driver.h:18,
 from devinput.c:42:
devinput.c: In function ‘devinput_rec’:
devinput.c:461:70: error: ‘struct input_event’ has no member named ‘time’
  461 | log_trace("time %ld.%06ld  type %d  code %d  value %d", 
event.time.tv_sec, event.time.tv_usec, event.type,
  |  ^

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Amin Bandali]

Hi,

On Mon, Mar 11, 2024 at 05:55:31PM +0100, Sebastian Andrzej Siewior wrote:
> On 2024-03-11 00:05:54 [+], Amin Bandali wrote:
> > Hi Sebastian, all,
> Hi,
> 
> > Will this fix be enough for addressing all cases, though?
> 
> I think so. Do you have a test case for me to check?

Not about pristine-xz specifically; I meant more in the context of
other devel tools like gbp et al.

> > I'm thinking specifically of cases where tarball repacking
> > is involved, for example when using git-buildpackage's
> > "gbp import-orig --uscan" where uscan is used to download and
> > repack the upstream tarball, because the package at hand has
> > a Files-Excluded field in its debian/copyright header stanza.
> > As far as I can tell, Devscripts::Compression would need to be
> > updated to specify -T1 for xz compressions.
> > 
> > I believe there are also some cases where git-buildpackage
> > itself does repacking, so we'd probably want to update its
> > gbp.pkg.compressor's Opts to pass in -T1 for xz.
> 
> Who is handling the compression in the first place here?

In the case of "gbp import-orig --uscan", gbp invokes uscan, part of
the devscripts package which has several perl modules including
Devscripts::Compression which is a sort of a wrapper around dpkg's
Dpkg::Compression, which will ultimately run the 'xz' executable.

In some other cases like "gbp import-orig --filter" mentioned by
Andrey, gbp does the compression itself.  Which is why I suggested
that 'Opts' in gbp.pkg.compressor may need to be updated to add '-T1'
for calls to 'xz'.

> The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's
> delta information. If the -T argument then everything keeps working
> as-is. If you use gbp to repack the tar archive then I would recommend
> to no pass -T1 and to use multi-threaded compression. pristine-tar
> will recongnise this and record this information.

Sorry I don't think I fully understood this bit.  Could you please
explain again, perhaps a bit more verbosely?

To clarify, the use-cases described earlier involving gbp and
devscripts aren't necessarily related to pristine-xz, used for
regenerating pristine xz files; rather, about the generation or
repacking of xz files *before* they are handed to pristine-xz for
processing and storage in the repo.  I was trying to imply that
similarly to how you sent patches for pristine-tar to adapt it for
changes in xz-utils, that similar patches are probably also needed
for gbp and devscripts.  Does that make sense?

> Sebastian
> 

Thanks,
-amin

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Amin Bandali]

Hi Sebastian, all,

Will this fix be enough for addressing all cases, though?

I'm thinking specifically of cases where tarball repacking
is involved, for example when using git-buildpackage's
"gbp import-orig --uscan" where uscan is used to download and
repack the upstream tarball, because the package at hand has
a Files-Excluded field in its debian/copyright header stanza.
As far as I can tell, Devscripts::Compression would need to be
updated to specify -T1 for xz compressions.

I believe there are also some cases where git-buildpackage
itself does repacking, so we'd probably want to update its
gbp.pkg.compressor's Opts to pass in -T1 for xz.

Thanks,
-a

Bug#1059422: sdbus-cpp: pkgconfig fails to resolve systemd dependency

[Amin Bandali]

Source: sdbus-cpp
Version: 1.4.0-1
Severity: serious
Justification: causes dependent packages to fail to build from source
Tags: patch upstream

Dear maintainer,

The upstream sdbus-cpp 1.4.0 release shipped with a problematic
sdbus-c++.pc pkgconfig file that causes dependent packages that
use it to fail to build from source.  For example:

https://buildd.debian.org/status/fetch.php?pkg=ring=amd64=20230922.0%7Eds2-1%2Bb1=1701601320=0

The issue was reported[1] and fixed[2] upstream already, but
there hasn't been a new release as of yet.  Given the severity
of the issue, please consider doing an upload with the attached
patch for the time being, until upstream releases a new version
with the fix included.

I'd look to do an NMU with the patch in the next week or two if you
may be unavailable/busy, so as to unbreak dependent packages' build.

Thanks,
-a

[1] https://github.com/Kistler-Group/sdbus-cpp/issues/377
[2] https://github.com/Kistler-Group/sdbus-cpp/pull/378

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2803722..7d29973 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -12,7 +12,8 @@ include(GNUInstallDirs) # Installation directories for `install` command and pkg
 # PERFORMING CHECKS & PREPARING THE DEPENDENCIES
 #---
 
-set(LIBSYSTEMD "systemd")
+set(LIBSYSTEMD_IMPL "systemd")
+set(LIBSYSTEMD_LIB "libsystemd")
 
 option(BUILD_LIBSYSTEMD "Build libsystemd static library and incorporate it into libsdbus-c++" OFF)
 
@@ -23,13 +24,15 @@ if(NOT BUILD_LIBSYSTEMD)
 message(WARNING "libsystemd not found, checking for libelogind instead")
 pkg_check_modules(Systemd IMPORTED_TARGET GLOBAL libelogind>=236)
 if(TARGET PkgConfig::Systemd)
-set(LIBSYSTEMD "elogind")
+set(LIBSYSTEMD_IMPL "elogind")
+set(LIBSYSTEMD_LIB "libelogind")
 string(REPLACE "." ";" VERSION_LIST ${Systemd_VERSION})
 list(GET VERSION_LIST 0 Systemd_VERSION)
 	else()
 message(WARNING "libelogind not found, checking for basu instead")
 pkg_check_modules(Systemd IMPORTED_TARGET GLOBAL basu)
-set(LIBSYSTEMD "basu")
+set(LIBSYSTEMD_IMPL "basu")
+set(LIBSYSTEMD_LIB "basu")
 # https://git.sr.ht/~emersion/basu/commit/d4d185d29a26
 set(Systemd_VERSION "240")
 endif()
@@ -125,8 +128,8 @@ add_library(sdbus-c++-objlib OBJECT ${SDBUSCPP_SRCS})
 target_compile_definitions(sdbus-c++-objlib PRIVATE
 BUILD_LIB=1
 LIBSYSTEMD_VERSION=${LIBSYSTEMD_VERSION}
-SDBUS_${LIBSYSTEMD}
-SDBUS_HEADER=<${LIBSYSTEMD}/sd-bus.h>)
+SDBUS_${LIBSYSTEMD_IMPL}
+SDBUS_HEADER=<${LIBSYSTEMD_IMPL}/sd-bus.h>)
 target_include_directories(sdbus-c++-objlib PUBLIC $
$)
 if(BUILD_SHARED_LIBS)
@@ -236,6 +239,7 @@ if(BUILD_SHARED_LIBS AND (BUILD_LIBSYSTEMD OR Systemd_LINK_LIBRARIES MATCHES "/l
 else()
 set(PKGCONFIG_REQS "")
 endif()
+set(PKGCONFIG_DEPS ${LIBSYSTEMD_LIB})
 configure_file(pkgconfig/sdbus-c++.pc.in pkgconfig/sdbus-c++.pc @ONLY)
 install(FILES ${CMAKE_CURRENT_BINARY_DIR}/pkgconfig/sdbus-c++.pc
 DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig COMPONENT dev)
diff --git a/pkgconfig/sdbus-c++.pc.in b/pkgconfig/sdbus-c++.pc.in
index 07034769..1e17f33d 100644
--- a/pkgconfig/sdbus-c++.pc.in
+++ b/pkgconfig/sdbus-c++.pc.in
@@ -5,7 +5,7 @@ includedir=@CMAKE_INSTALL_FULL_INCLUDEDIR@
 
 Name: @PROJECT_NAME@
 Description: C++ library on top of sd-bus, a systemd D-Bus library
-Requires@PKGCONFIG_REQS@: @LIBSYSTEMD@
+Requires@PKGCONFIG_REQS@: @PKGCONFIG_DEPS@
 Version: @SDBUSCPP_VERSION@
 Libs: -L${libdir} -l@PROJECT_NAME@
 Cflags: -I${includedir}
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
index 56c48528..85abf97e 100644
--- a/tests/CMakeLists.txt
+++ b/tests/CMakeLists.txt
@@ -106,7 +106,7 @@ include_directories(${CMAKE_CURRENT_SOURCE_DIR})
 add_executable(sdbus-c++-unit-tests ${UNITTESTS_SRCS})
 target_compile_definitions(sdbus-c++-unit-tests PRIVATE
 LIBSYSTEMD_VERSION=${LIBSYSTEMD_VERSION}
-SDBUS_HEADER=<${LIBSYSTEMD}/sd-bus.h>)
+SDBUS_HEADER=<${LIBSYSTEMD_IMPL}/sd-bus.h>)
 target_link_libraries(sdbus-c++-unit-tests sdbus-c++-objlib GTest::gmock)
 
 add_executable(sdbus-c++-integration-tests ${INTEGRATIONTESTS_SRCS})

Bug#1054798: opendht: FTBFS: dh_missing: error: missing files, aborting

[Amin Bandali]

Control: merge 1054359 1054798
Control: tags -1 pending
X-Debbugs-CC: Tobias Frost 

Hi Lucas,

Thanks for the bug report.  However, this is a duplicate of #1054359,
so I'm merging the two.  I have an upload[1,2] pending review and
sponsoring by Tobi - the AM for my DD process - to fix the FTBFS and
address the longstanding #866075 as well.  I hope Tobi can review and
sponsor it through NEW soon.

Thanks,
-a

[1] https://salsa.debian.org/debian/opendht
[2] https://mentors.debian.net/package/opendht/

Bug#1002527: milter-greylist -u user does not correctly ensure user can update greylist.db

[Amin Bandali]

Control: severity -1 important
Control: tags -1 pending
X-Debbugs-CC: t...@debian.org, m...@renich.org, b...@debian.org, 
t...@zhadum.org.uk

Hi again folks,

Per suggestion from Tobi, I'm reducing the severity of this bug from
'critical' (RC) to 'important', since the default configuration works
fine out of the box on a Debian system (with systemd).

Thanks to Tobi adding me to the ACL for salsa:debian/milter-greylist,
I went ahead and pushed my proposed change to the repo, also attached
as a patch for your convenience.

https://salsa.debian.org/debian/milter-greylist/-/commit/d118c24c45674fe8ae75ae96b318a4cb1320

Tobi, if there are still no objections in the coming days, I'd
appreciate it if you'd please sponsor this to unstable for me.

Thanks,
-a

>From d118c24c45674fe8ae75ae96b318a4cb1320 Mon Sep 17 00:00:00 2001
From: Amin Bandali 
Date: Tue, 24 Oct 2023 19:54:36 -0400
Subject: [PATCH] Set user greylist in greylist.conf instead of
 milter-greylist.service

---
 debian/changelog   | 11 +++
 debian/milter-greylist.service |  2 +-
 debian/patches/conf-dumpfreq   |  6 +++---
 debian/patches/greylist.conf   | 19 ---
 4 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 32f3de6..8832c9a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+milter-greylist (4.6.4-3) UNRELEASED; urgency=medium
+
+  * QA upload.
+  * Set user greylist in the configuration file rather than as a
+command-line option in the service file (which always takes
+precedence) to allow easier customization. (Closes: #1002527)
+- debian/milter-greylist.service
+- debian/patches/greylist.conf
+
+ -- Amin Bandali   Tue, 24 Oct 2023 19:49:53 -0400
+
 milter-greylist (4.6.4-2) unstable; urgency=medium
 
   [ Ondřej Surý ]
diff --git a/debian/milter-greylist.service b/debian/milter-greylist.service
index b5a6e80..bcef86f 100644
--- a/debian/milter-greylist.service
+++ b/debian/milter-greylist.service
@@ -5,7 +5,7 @@ Before=postfix.service
 
 [Service]
 Type=forking
-ExecStart=/usr/sbin/milter-greylist -u greylist
+ExecStart=/usr/sbin/milter-greylist
 Restart=on-failure
 PrivateTmp=true
 
diff --git a/debian/patches/conf-dumpfreq b/debian/patches/conf-dumpfreq
index 5400f40..a0de3db 100644
--- a/debian/patches/conf-dumpfreq
+++ b/debian/patches/conf-dumpfreq
@@ -8,11 +8,11 @@ Index: milter-greylist-4.3.5/greylist.conf
 --- milter-greylist-4.3.5.orig/greylist.conf	2010-03-15 14:48:16.0 +
 +++ milter-greylist-4.3.5/greylist.conf	2010-03-15 14:48:48.732009554 +
 @@ -7,7 +7,7 @@
- 
  pidfile "/var/run/milter-greylist.pid"
+ socket "/var/run/milter-greylist/milter-greylist.sock"
  dumpfile "/var/lib/milter-greylist/greylist.db" 600
 -dumpfreq 1
 +dumpfreq 10m
+ user "greylist"
  
- # For sendmail use the following two lines
- socket "/var/run/milter-greylist/milter-greylist.sock"
+ # If using Postfix rather than Sendmail, uncomment the following
diff --git a/debian/patches/greylist.conf b/debian/patches/greylist.conf
index 6e1d33d..216aae9 100644
--- a/debian/patches/greylist.conf
+++ b/debian/patches/greylist.conf
@@ -8,23 +8,28 @@ Index: milter-greylist-4.5.11/greylist.conf
 ===
 --- milter-greylist-4.5.11.orig/greylist.conf	2014-07-30 09:29:48.543484591 +0100
 +++ milter-greylist-4.5.11/greylist.conf	2014-07-30 09:29:48.539484522 +0100
-@@ -6,11 +6,17 @@
+@@ -6,11 +6,21 @@
  #
  
  pidfile "/var/run/milter-greylist.pid"
 -socket "/var/milter-greylist/milter-greylist.sock"
 -dumpfile "/var/milter-greylist/greylist.db" 600
++socket "/var/run/milter-greylist/milter-greylist.sock"
 +dumpfile "/var/lib/milter-greylist/greylist.db" 600
  dumpfreq 1
-+
-+# For sendmail use the following two lines
-+socket "/var/run/milter-greylist/milter-greylist.sock"
- user "smmsp"
+-user "smmsp"
++user "greylist"
  
-+# For Postfix uncomment the following two lines and comment out the
-+# sendmail ones above.
++# If using Postfix rather than Sendmail, uncomment the following
++# socket and user settings and comment out the socket and user above.
 +#socket "/var/run/milter-greylist/milter-greylist.sock" 660
 +#user "postfix"
++
++# If using a chrooted Postfix, you might want to use something like
++# the following instead (where "/var/spool/postfix" is the Postfix
++# chroot):
++#socket "/var/spool/postfix/milter-greylist/milter-greylist.sock" 660
++#user "greylist:postfix"
  
  # Log milter-greylist activity to a file
  #stat ">>/var/milter-greylist/greylist.log" \
-- 
2.39.2

Bug#1002527: "milter-greylist -u user" considered harmful

[Amin Bandali]

X-Debbugs-CC: m...@renich.org, b...@debian.org, t...@zhadum.org.uk, 
t...@debian.org

Hello,

How do folks feel about the attached patch (against
https://salsa.debian.org/debian/milter-greylist)?  It implements
Matthias's proposal of allowing the use of a user (and/or group)
other than 'greylist' for systemd users as well.

I understand it may not be a 100% "solution" that everyone would be
happy with (e.g. postinst configure still sets 'greylist' as the owner
user and group for /var/lib/milter-greylist), but I think it's an
improvement over the current situation, as it makes milter-greylist
respect the corresponding setting in its configuration file, and also
adds an example of more suitable 'socket' and 'user' settings values
to the configuration file for use with a chrooted Postfix.

I'd appreciate any comments/feedback on this, but if there aren't any,
I'd ask Tobi to sponsor it to unstable for me.

Thanks,
-a

>From cbfdd5fb0dcc45639b313eea5cdf2f580be18f52 Mon Sep 17 00:00:00 2001
From: Amin Bandali 
Date: Fri, 13 Oct 2023 01:28:35 -0400
Subject: [PATCH] Set user greylist in greylist.conf instead of
 milter-greylist.service

---
 debian/changelog   | 12 
 debian/milter-greylist.service |  2 +-
 debian/patches/greylist.conf   | 19 ---
 3 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 3a05494..f36f77a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+milter-greylist (4.6.4-1.2) unstable; urgency=medium
+
+  * QA upload.
+  * Non-maintainer upload.
+  * Set user greylist in the configuration file rather than as a
+command-line option in the service file (which always takes
+precedence) to allow easier customization. (Closes: #1002527)
+- debian/milter-greylist.service
+- debian/patches/greylist.conf
+
+ -- Amin Bandali   Fri, 13 Oct 2023 18:43:39 -0400
+
 milter-greylist (4.6.4-1.1) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/milter-greylist.service b/debian/milter-greylist.service
index b5a6e80..bcef86f 100644
--- a/debian/milter-greylist.service
+++ b/debian/milter-greylist.service
@@ -5,7 +5,7 @@ Before=postfix.service
 
 [Service]
 Type=forking
-ExecStart=/usr/sbin/milter-greylist -u greylist
+ExecStart=/usr/sbin/milter-greylist
 Restart=on-failure
 PrivateTmp=true
 
diff --git a/debian/patches/greylist.conf b/debian/patches/greylist.conf
index 6e1d33d..216aae9 100644
--- a/debian/patches/greylist.conf
+++ b/debian/patches/greylist.conf
@@ -8,23 +8,28 @@ Index: milter-greylist-4.5.11/greylist.conf
 ===
 --- milter-greylist-4.5.11.orig/greylist.conf	2014-07-30 09:29:48.543484591 +0100
 +++ milter-greylist-4.5.11/greylist.conf	2014-07-30 09:29:48.539484522 +0100
-@@ -6,11 +6,17 @@
+@@ -6,11 +6,21 @@
  #
  
  pidfile "/var/run/milter-greylist.pid"
 -socket "/var/milter-greylist/milter-greylist.sock"
 -dumpfile "/var/milter-greylist/greylist.db" 600
++socket "/var/run/milter-greylist/milter-greylist.sock"
 +dumpfile "/var/lib/milter-greylist/greylist.db" 600
  dumpfreq 1
-+
-+# For sendmail use the following two lines
-+socket "/var/run/milter-greylist/milter-greylist.sock"
- user "smmsp"
+-user "smmsp"
++user "greylist"
  
-+# For Postfix uncomment the following two lines and comment out the
-+# sendmail ones above.
++# If using Postfix rather than Sendmail, uncomment the following
++# socket and user settings and comment out the socket and user above.
 +#socket "/var/run/milter-greylist/milter-greylist.sock" 660
 +#user "postfix"
++
++# If using a chrooted Postfix, you might want to use something like
++# the following instead (where "/var/spool/postfix" is the Postfix
++# chroot):
++#socket "/var/spool/postfix/milter-greylist/milter-greylist.sock" 660
++#user "greylist:postfix"
  
  # Log milter-greylist activity to a file
  #stat ">>/var/milter-greylist/greylist.log" \
-- 
2.39.2

Bug#942501: src:milter-greylist: please drop libbind-dev build dependency, it's not in use and libbind-dev is going away

[Amin Bandali]

Control: tags -1 pending
X-Debbugs-CC: Tobias Frost 

Tobi, would you please sponsor this to unstable?

https://salsa.debian.org/debian/milter-greylist

I'll start work on #1002527 shortly.

Thanks,
-a

Bug#1051364: nvi uses Conflicts in violation of policy 10.1

[Amin Bandali]

X-Debbugs-CC: Tobias Frost 

Dear Tobi, all,

I've prepared a patch + QA upload for unstable to address this.

The upload is on mentors.debian.net:

https://mentors.debian.net/package/nvi/

And the patch against the https://salsa.debian.org/debian/nvi
repo is attached.

I plan on preparing a separate QA upload for some other small
improvements, like updating the debian/watch file to point to
the git repo on repo.or.cz rather than the current broken page.
Or if you prefer, I can amend this change and do these as part
of this one.

>From d625f9ea73c9957cc479d13e985565d4e703c563 Mon Sep 17 00:00:00 2001
From: Amin Bandali 
Date: Sun, 1 Oct 2023 23:16:05 -0400
Subject: [PATCH] debian/control: Remove 'Conflicts: nex' (Closes: #1051364)

---
 debian/changelog | 8 
 debian/control   | 1 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 67be40cf..d54e939c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+nvi (1.81.6-19) unstable; urgency=medium
+
+  * QA upload.
+  * debian/control: Remove 'Conflicts: nex' to comply with
+Debian Policy section 10.1. (Closes: #1051364)
+
+ -- Amin Bandali   Sun, 01 Oct 2023 23:12:24 -0400
+
 nvi (1.81.6-18) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/control b/debian/control
index 45b12a9b..d64d8550 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,6 @@ Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Recommends: nvi-doc
-Conflicts: nex
 Description: 4.4BSD re-implementation of vi
  Vi is the original screen based text editor for Unix systems.
  It is considered the standard text editor, and is available on
-- 
2.39.2

Bug#942501: src:milter-greylist: please drop libbind-dev build dependency, it's not in use and libbind-dev is going away

[Amin Bandali]

Dear Ondřej,

I just saw you had prepared an NMU version 4.6.4-1.1 for unstable
for this bug per [1,2] but it seems it was never actually uploaded.

I was wondering if there's any particular reason for that, or
if you would consider uploading it, if there's no reason not to?

Thanks,
-a

[1] 
https://salsa.debian.org/debian/milter-greylist/-/commit/825fc531d0e80789cdb3d44fd080ac34871beb73
[2] 
https://salsa.debian.org/debian/milter-greylist/-/commit/c6956d89c182f12db71f29d41fd052542b2c941a

Bug#1042038: mfem: FTBFS: hash.hpp:1001:39: error: ISO C++ forbids declaration of ‘type name’ with no type [-fpermissive]

[Amin Bandali]

Please find attached a patch with an upstream patch to fix this.

Related: https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes

>From b07acda4afb3056040bd2b07d209b76bec90a988 Mon Sep 17 00:00:00 2001
From: Amin Bandali 
Date: Fri, 1 Sep 2023 21:11:04 -0400
Subject: [PATCH] Add upstream patch to fix FTBFS with gcc-13 (Closes:
 #1042038)

---
 debian/changelog  |  7 
 debian/patches/fix-ftbfs-gcc-13.patch | 53 +++
 debian/patches/series |  1 +
 3 files changed, 61 insertions(+)
 create mode 100644 debian/patches/fix-ftbfs-gcc-13.patch

diff --git a/debian/changelog b/debian/changelog
index 7d95e4c1e..e30df4c4d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mfem (4.5.2+ds-2) UNRELEASED; urgency=medium
+
+  * Add upstream patch to fix FTBFS with gcc-13 (Closes: #1042038)
+- debian/patches/fix-ftbfs-gcc-13.patch
+
+ -- Amin Bandali   Fri, 01 Sep 2023 21:10:21 -0400
+
 mfem (4.5.2+ds-1) unstable; urgency=medium
 
   * Initial release. (Closes: #1023223)
diff --git a/debian/patches/fix-ftbfs-gcc-13.patch b/debian/patches/fix-ftbfs-gcc-13.patch
new file mode 100644
index 0..5d202ab25
--- /dev/null
+++ b/debian/patches/fix-ftbfs-gcc-13.patch
@@ -0,0 +1,53 @@
+From 314a32af2ee80af8c9af7d8ad71babd51851154c Mon Sep 17 00:00:00 2001
+From: David Dement 
+Origin: https://github.com/mfem/mfem/commit/314a32af2ee80af8c9af7d8ad71babd51851154c
+Date: Thu, 27 Apr 2023 10:33:51 -0400
+Subject: [PATCH] Fixes comilation errors when compiling with gcc-13 on Fedora
+ 38
+
+When compiling with gcc-13, types such as uint64_t are not defined.
+It is likely that  is included implicitly with older compiler
+versions.
+---
+ general/hash.hpp| 1 +
+ general/mem_manager.cpp | 1 +
+ mesh/vtk.hpp| 2 ++
+ 3 files changed, 4 insertions(+)
+
+diff --git a/general/hash.hpp b/general/hash.hpp
+index 86d987d8029..288d51288df 100644
+--- a/general/hash.hpp
 b/general/hash.hpp
+@@ -16,6 +16,7 @@
+ #include "array.hpp"
+ #include "globals.hpp"
+ #include 
++#include 
+ 
+ namespace mfem
+ {
+diff --git a/general/mem_manager.cpp b/general/mem_manager.cpp
+index 416a6ac6203..37b80c878ad 100644
+--- a/general/mem_manager.cpp
 b/general/mem_manager.cpp
+@@ -16,6 +16,7 @@
+ #include  // std::memcpy, std::memcmp
+ #include 
+ #include  // std::max
++#include 
+ 
+ // Uncomment to try _WIN32 platform
+ //#define _WIN32
+diff --git a/mesh/vtk.hpp b/mesh/vtk.hpp
+index a59bed27592..50eeea5bc78 100644
+--- a/mesh/vtk.hpp
 b/mesh/vtk.hpp
+@@ -12,6 +12,8 @@
+ #ifndef MFEM_VTK
+ #define MFEM_VTK
+ 
++#include 
++
+ #include "../fem/geom.hpp"
+ #include "../general/binaryio.hpp"
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 6f0d8f01a..d42e867b3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 static-no-shared-yes
 not-makefile
+fix-ftbfs-gcc-13.patch
-- 
2.39.2

Bug#1037841: restinio: ftbfs with GCC-13

[Amin Bandali]

Dear Matthias, Felix,

Please find attached a patch that should fix this.

Would one of you please upload it as well?

Thanks,
-a

Description: Fix FTBFS with GCC-13
 For more details, see:
 https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
Author: Amin Bandali 

diff --git a/dev/test/router/cmp_router_bench/route_parser.hpp b/dev/test/router/cmp_router_bench/route_parser.hpp
index cfbe981a..4d874cc7 100644
--- a/dev/test/router/cmp_router_bench/route_parser.hpp
+++ b/dev/test/router/cmp_router_bench/route_parser.hpp
@@ -1,5 +1,6 @@
 #pragma once
 
+#include 
 #include 
 
 enum class entity_type_t : std::uint8_t

Bug#1030855: ring_20230206.0~ds1-2_amd64-buildd.changes REJECTED

[Amin Bandali]

Hello,

Aurelien Jarno writes:

> Source: ring
> Version: 20230206.0~ds1-2
> Severity: serious
>
> On 2023-02-08 08:40, Debian FTP Masters wrote:
>> jami_20230206.0~ds1-2_amd64.deb: has 5 file(s) with a timestamp too far in 
>> th=
>> e past:
>>   usr/share/applications/jami.desktop (Thu Jan  1 00:00:01 1970)  
>> usr/share/i=
>> cons/hicolor/scalable/apps/jami.svg (Thu Jan  1 00:00:01 1970)  
>> usr/share/jam=
>> i/jami.desktop (Thu Jan  1 00:00:01 1970)  
>> usr/share/metainfo/jami.appdata.xm=
>> l (Thu Jan  1 00:00:01 1970)  usr/share/pixmaps/jami.xpm (Thu Jan  1 
>> 00:00:01=
>>  1970)
>> 
>> 
>> 
>> =3D=3D=3D
>> 
>> Please feel free to respond to this email if you don't understand why
>> your files were rejected, or if you upload new files which address our
>> concerns.

Yes please, I'd like to understand why timestamps in the far past are
a 'serious' bug and warrant a rejection.  Upstream Jami project has
worked on making various aspects of the release and build processes of
Jami reproducible over the years, including Jami's release tarballs.
The release tarballs are generated with a few additional options[1] to
aide reproducibility, including setting '--mtime=@1' to use the epoch
as the timestamp for all the files included in the release tarballs.
This is quite close to the archive recommendations[2] by the
reproducible builds project.

So, why would this be considered an issue?

[1] 
https://git.jami.net/savoirfairelinux/jami-client-qt/-/blob/010930febe2c28374c65e25c3147f08bdc2efecc/extras/packaging/gnu-linux/Makefile#L67
[2] https://reproducible-builds.org/docs/archives/

Bug#1030222: [DSE-Dev] Bug#1030222: selint: please restrict check only where valgrind is available

[Amin Bandali]

Amin Bandali writes:

> Hello there,
>
> You might find it more convenient to depend on 'valgrind-if-available'
> rather than 'valgrind' itself, per the attached patch.  It also skips
> tests that need valgrind, for problematic arches.  What do you think?

To be fully clear, by "it" in "it also skips" I was referring to my
attached patch, not the act of depending on valgrind-if-available.

Bug#1030222: [DSE-Dev] Bug#1030222: selint: please restrict check only where valgrind is available

[Amin Bandali]

Hello there,

You might find it more convenient to depend on 'valgrind-if-available'
rather than 'valgrind' itself, per the attached patch.  It also skips
tests that need valgrind, for problematic arches.  What do you think?

diff --git a/debian/control b/debian/control
index 44fca69..a130223 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: autoconf-archive,
libconfuse-dev,
pkg-config,
uthash-dev,
-   valgrind 
+   valgrind-if-available 
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://github.com/SELinuxProject/selint
diff --git a/debian/rules b/debian/rules
index 3a18158..2409916 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all optimize=+lto
 
 ifneq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
@@ -14,6 +16,10 @@ override_dh_auto_configure:
 	dh_auto_configure -- --enable-werror $(CONFIGURE_ARGS)
 
 execute_after_dh_auto_test:
+ifneq (,$(filter $(DEB_HOST_ARCH), mips64el mipsel))
+# Skip the tests requiring valgrind on problematic architectures
+	sed -i '/^@test "\(valgrind\|Broken config\)" {/a \	skip' end-to-end.bats
+endif
 	cd tests/functional/ && bats end-to-end.bats
 
 ifneq (, $(filter cross, $(DEB_BUILD_PROFILES)))