Bug#1067853: kanshi(1) refers to kanshictl(1), but no kanshictl is not shipped (neither manpage or executable)
Hi, For the record, the absence of kanshictl was previously raised in https://bugs.debian.org/1026463 but self-closed with a comment about varlink possibly not being in the best shape for inclusion in Debian. I'm personally not decided for or against packaging varlink in Debian at this point. I think I might try following up with kanshi and/or varlink upstream to inquire more about the situation. I'll look into either packaging varlink and adding kanshictl, or otherwise amending man kanshi(1) to drop references to kanshictl(1) to avoid confusion. Also FWIW, per https://todo.sr.ht/~emersion/kanshi/104 upstream kanshi didn't seem interested in exploring other options in place of varlink.
Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded
Hi Carsten, all, On Fri Mar 22, 2024 at 11:22 AM EDT, Carsten Schoenert wrote: [...] > > Thanks a lot for the follow up. Carsten can you confirm with TB if this > > works as > > expected? > > I need to check this again and in detail, because I had recently some > issues as the expected hash ids were different while working with gbp > import and later gbp buildpackage on some package from the kicad > universe. But I think these problems are currently related to the t64 > transition. [...] I'd run into a similar issue with gbp and I, too, initially suspected t64, but I believe it was actually an issue with pristine-tar, that Sebastian has sinced fixed, per https://bugs.debian.org/1065751. I haven't had the chance to specifically try reproducing it with pristine-tar 1.50+nmu2, but per Sebastian and my colleague Jeremy it should now be fixed with that version of pristine-tar. Otherwise if you can still reproduce it please open a bug against pristine-tar and let Sebastian know. Thanks, -a
Bug#1066944: FTBFS on 32-bit arches with 64-bit time_t
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
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
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#1013210: O: nsync -- C library that exports various synchronization primitives
Hello there, Since nsync doesn't seem especially science-specific, and it is now orphaned, would you consider moving its repo from the 'science-team' group on Salsa to the 'debian' group? That way any DD who happens to do work on the package or wants to adopt it could easily push their changes to the git repo. Thanks in advance, -a
Bug#1066810: libdmtx: NMU diff for removing remaining reference to libdmtx0b
Control: tags -1 patch Please find the debdiff attached. diff -Nru libdmtx-0.7.7/debian/changelog libdmtx-0.7.7/debian/changelog --- libdmtx-0.7.7/debian/changelog 2024-02-28 05:45:56.0 -0500 +++ libdmtx-0.7.7/debian/changelog 2024-03-13 15:28:28.0 -0400 @@ -1,3 +1,11 @@ +libdmtx (0.7.7-1.2) unstable; urgency=medium + + * Non-maintainer upload. + * Change the leftover reference to libdmtx0b to libdmtx0t64 in +debian/rules. (Closes: #1066810) + + -- Amin Bandali Wed, 13 Mar 2024 15:28:28 -0400 + libdmtx (0.7.7-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libdmtx-0.7.7/debian/rules libdmtx-0.7.7/debian/rules --- libdmtx-0.7.7/debian/rules 2019-04-12 15:26:32.0 -0400 +++ libdmtx-0.7.7/debian/rules 2024-03-13 15:09:57.0 -0400 @@ -3,6 +3,6 @@ export DH_OPTIONS export DEB_BUILD_MAINT_OPTIONS = hardening=+all override_dh_installdocs: - dh_installdocs --link-doc=libdmtx0b + dh_installdocs --link-doc=libdmtx0t64 %: dh $@
Bug#1066810: libdmtx: NMU diff for removing remaining reference to libdmtx0b
Source: libdmtx Version: 0.7.7-1.1 Severity: important Dear maintainer, I'll be uploading an NMU to unstable to change the remaining reference to libdmtx0b in debian/rules to libdmtx0t64, relating to the time_t transition. The diff will be like so: --- libdmtx-0.7.7/debian/rules 2019-04-12 15:26:32.0 -0400 +++ libdmtx-0.7.7/debian/rules 2024-03-13 15:08:05.0 -0400 @@ -3,6 +3,6 @@ export DH_OPTIONS export DEB_BUILD_MAINT_OPTIONS = hardening=+all override_dh_installdocs: - dh_installdocs --link-doc=libdmtx0b + dh_installdocs --link-doc=libdmtx0t64 %: dh $@ Best -a
Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2
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
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#1058646: ITP: qbe -- Small embeddable C compiler backend
Hi Miguel, On Thu, Feb 22, 2024 at 09:23:20PM +, Miguel Landaeta wrote: > On Thu, Feb 22, 2024 at 02:19:21AM +0000, Amin Bandali wrote: > > Hi Miguel, > > > > I'm interested in helping with this. Do you have the current state > > of your work available on Salsa or elsewhere that I could pull in > > and work on? Otherwise I'll just start with a repo under my own > > account and we could later transfer it to the 'debian' group or > > elsewhere. > > Hi Amin, thanks for reaching out. > > I'll push my repo tomorrow or during the weekend to salsa and > update this thread with the link. > > I started to work on this package a few weeks ago but I decided to > wait for qbe 1.2 before uploading a package and I just noticed > it finally happened this week so I was planning to resume my work > on it. > > I don't have time to work on it this weekend but I'll publish it > in a few hours to unblock you and other folks interested in > collaborating. Sounds great, thanks in advance! FWIW I was browsing Hare's website again earlier, and saw this bit on https://harelang.org/installation: Step 0: Pre-requisites [...] QBE (the latest version on the git master branch, not the latest versioned release) Though I think/hope that that's a remnant from earlier times before Hare's first versioned release. Hare's new release policy at https://git.sr.ht/~sircmpwn/hare/tree/master/item/docs/release.md is more reassuring: The Hare toolchain's chief dependency is qbe. Each Hare version is pinned to a specific qbe release, which is documented in the release notes corresponding to that Hare version. So I'm hopeful that at this point and onwards, Hare would depend on tagged release versions of qbe rather than git trunk commits. > If you want, I can add you as co-maintainer. > > Cheers, > Miguel. Sure, that would be great - many thanks. :-) Best, -amin
Bug#1058645: ITP: hare -- Hare is a systems programming language designed to be simple, stable, and robust.
X-Debbugs-Cc: martin.quin...@ens-rennes.fr, cla...@gmail.com Hi all, I too am interested in working on getting hare packaged and uploaded. I also just sent a reply on https://bugs.debian.org/1058646 asking if Miguel has a WIP repo for QBE packaging up on Salsa somewhere that I could pull in and work on, otherwise I'll just start with a repo under my account and later transfer it elsewhere (e.g. to 'debian'). We also need to package harec, the Hare bootstrap compiler, which at the moment is a separate repo https://git.sr.ht/~sircmpwn/harec but I believe upstream has plans to merge it into the hare repo: https://lists.sr.ht/~sircmpwn/hare-rfc/%3CZdYKdoIWSUUpDeIX%40xha.li%3E I'm not sure exactly how far into the future this will be though. One of the main Hare developers said it will probably be done before the next 0.24.1 release, but not sure. Still, I held off on filing a separate ITP for harec for now, to see if Drew chimes in with a more concrete plan/timeline over the next day or two perhaps. If there's no further feedback/timeline on the plans for the proposed merge of the harec and hare repos, I plan on filing an ITP for harec so we could go ahead with a separate harec source package for now corresponding to the current repo structures, until if/when upstream merges the two repos and we would re-evaluate our options then. Any thoughts/feedback appreciated and welcome. :-) Thanks, -a
Bug#1058646: ITP: qbe -- Small embeddable C compiler backend
Hi Miguel, I'm interested in helping with this. Do you have the current state of your work available on Salsa or elsewhere that I could pull in and work on? Otherwise I'll just start with a repo under my own account and we could later transfer it to the 'debian' group or elsewhere. Thanks, -a
Bug#1063927: xpdf: FTBFS with poppler 24.02.0
Source: xpdf
Version: 3.04+git20240124-1
Severity: important
Tags: ftbfs patch upstream fixed-upstream
X-Debbugs-Cc: band...@debian.org
Dear Maintainer,
I recently uploaded new poppler 24.02.0 to experimental, and xpdf is
one of the affected packages that fails to build from source with it.
Please consider cherry-picking upstream commit
0698734c46d6414c5285d9fa985c3bd4e380aaa8 (also attached to this bug
report for your convenience) to fix the build with the new poppler.
Thanks,
-a
>From 0698734c46d6414c5285d9fa985c3bd4e380aaa8 Mon Sep 17 00:00:00 2001
From: Adam Sampson
Date: Fri, 2 Feb 2024 13:58:46 +
Subject: [PATCH] OutlineItem's title is a vector in Poppler 24.02.
---
configure.ac | 3 +++
xpdf/XPDFViewer.cc | 12 +---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index d591291..d7d6ad2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -69,6 +69,9 @@ PKG_CHECK_EXISTS([poppler >= 22.05.0], [
PKG_CHECK_EXISTS([poppler >= 23.06.0], [
AC_DEFINE([ADDFONTFILE_STRING])
])
+PKG_CHECK_EXISTS([poppler >= 24.02.0], [
+ AC_DEFINE([OUTLINEITEM_TITLE_VECTOR])
+])
AC_SEARCH_LIBS([XmDropDownGetArrow], [Xm], [], [
AC_MSG_ERROR([Motif >= 2.3 is required])
diff --git a/xpdf/XPDFViewer.cc b/xpdf/XPDFViewer.cc
index c191931..e34a657 100644
--- a/xpdf/XPDFViewer.cc
+++ b/xpdf/XPDFViewer.cc
@@ -2623,7 +2623,7 @@ void XPDFViewer::setupOutlineItems(PCONST OutlineItemList *items,
Widget label;
Arg args[20];
XmString s;
- int i, j, n;
+ int i, n;
for (i = 0; i < (int)items->getOILSize(); ++i) {
#ifdef NO_GOOLIST
@@ -2636,9 +2636,15 @@ void XPDFViewer::setupOutlineItems(PCONST OutlineItemList *items,
std::string title;
mbstate_t state;
memset(, 0, sizeof state);
-for (j = 0; j < item->getTitleLength(); ++j) {
+#ifdef OUTLINEITEM_TITLE_VECTOR
+for (auto ch : item->getTitle()) {
+#else
+for (int j = 0; j < item->getTitleLength(); ++j) {
+ Unicode ch = item->getTitle()[j];
+#endif
+
char buf[8];
- n = wcrtomb(buf, (wchar_t)item->getTitle()[j], );
+ n = wcrtomb(buf, (wchar_t)ch, );
if (n == -1) {
// unmappable character
title.push_back(' ');
--
2.43.0
Bug#1063926: gambas3: FTBFS with poppler 24.02.0
Source: gambas3
Version: 3.18.4-3
Severity: important
Tags: ftbfs patch upstream
X-Debbugs-Cc: band...@debian.org
Dear Maintainer,
I recently uploaded new poppler 24.02.0 to experimental, and gambas3
is one of the affected packages that fails to build from source with
it. Please find attached a patch to fix the build, forwarded upstream
as well.
>From f5177f706b71a0ef918021c95ace9f60c0754313 Mon Sep 17 00:00:00 2001
From: Amin Bandali
Date: Wed, 14 Feb 2024 09:56:10 -0500
Subject: [PATCH] make 'gb.pdf' compile with poppler 24.02.0
Forwarded: https://gitlab.com/gambas/gambas/-/merge_requests/330
---
gb.pdf/configure.ac | 2 ++
gb.pdf/src/CPdfDocument.cpp | 21 +
2 files changed, 23 insertions(+)
diff --git a/gb.pdf/configure.ac b/gb.pdf/configure.ac
index 6931e2c48..6e612e40a 100644
--- a/gb.pdf/configure.ac
+++ b/gb.pdf/configure.ac
@@ -34,6 +34,8 @@ if test "$have_poppler" = "yes"; then
AC_DEFINE_UNQUOTED(POPPLER_VERSION_21_06_0, $((1-$?)), Poppler version >= 21.06.0)
$PKG_CONFIG --atleast-version=22.06.0 poppler
AC_DEFINE_UNQUOTED(POPPLER_VERSION_22_06_0, $((1-$?)), Poppler version >= 22.06.0)
+ $PKG_CONFIG --atleast-version=24.02.0 poppler
+ AC_DEFINE_UNQUOTED(POPPLER_VERSION_24_02_0, $((1-$?)), Poppler version >= 24.02.0)
fi
AC_CONFIG_FILES([\
diff --git a/gb.pdf/src/CPdfDocument.cpp b/gb.pdf/src/CPdfDocument.cpp
index 8f4aac7fb..5dfbfefc1 100644
--- a/gb.pdf/src/CPdfDocument.cpp
+++ b/gb.pdf/src/CPdfDocument.cpp
@@ -102,6 +102,22 @@ END_PROPERTY
/
+#if POPPLER_VERSION_24_02_0
+static void return_unicode_string(const std::vector )
+{
+ GooString gstr;
+ char buf[8]; /* 8 is enough for mapping an unicode char to a string */
+ int n;
+
+ const UnicodeMap *uMap = globalParams->getUtf8Map();
+ for (const auto : unicode) {
+ n = uMap->mapUnicode(c, buf, sizeof(buf));
+ gstr.append(buf, n);
+ }
+
+ GB.ReturnNewZeroString(gstr.getCString());
+}
+#else
static void return_unicode_string(const Unicode *unicode, int len)
{
GooString gstr;
@@ -128,6 +144,7 @@ static void return_unicode_string(const Unicode *unicode, int len)
GB.ReturnNewZeroString(gstr.getCString());
}
+#endif
static void aux_return_string_info(void *_object, const char *key)
@@ -776,7 +793,11 @@ END_PROPERTY
BEGIN_PROPERTY(PDFINDEX_title)
OutlineItem *item = CPDF_index_get(THIS->currindex);
+#if POPPLER_VERSION_24_02_0
+ return_unicode_string(item->getTitle());
+#else
return_unicode_string(item->getTitle(), item->getTitleLength());
+#endif
END_PROPERTY
--
2.43.0
Bug#1059422: sdbus-cpp: pkgconfig fails to resolve systemd dependency
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
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#1053931: restinio: [src:restinio] Uses embedded code copies
Hi Tobi, Thanks for the report. :-) I just uploaded 0.6.19+ds-1 to unstable, repacking the orig upstream tarball to remove several embedded copies; namely: - dev/asio/* - dev/fmt/* - dev/nodejs/http_parser/* - dev/rapidjson/* - dev/restinio/third_party/zlib/* I believe none of these were actually being used, but as you said, it's good to remove them to be sure of that. dev/catch2/ is a bit more tricky, because restinio is currently only compatible with the v2 series, whereas catch2 has released their v3 series (packaged in unstable as well), which appears to be backward incompatible with v2. Per restinio developers[1], adapting restinio to catch2 v3 may be a non-trivial effort, and will have to wait until they start work on their next major series. As such, it seems we'll have to continue including dev/catch2/ for a while longer until restinio developers get around to porting restinio to catch v3. So, I didn't close this bug in the changelog entry for 0.6.19+ds-1, but will keep an eye on the situation for when restinio is ported to catch2, at which point I'd make the change to exclude it from the tarball as well and use the system package. Best, -a [1] https://github.com/Stiffstream/restinio/issues/158
Bug#1002527: milter-greylist -u user does not correctly ensure user can update greylist.db
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#866075: [dhtnode] ship http_server.py and a systemd associated service
Control: tags -1 pending X-Debbugs-CC: Tobias Frost Hello, Apologies this took *a while* to get to, but it's [nearly] here, at last: I've added an opendht-tools package as part of the upcoming 3.0.0-4 upload, which among other tools packages python/tools/http_server.py as /usr/bin/dhtnode-http with a corresponding dhtnode-http.service and configuration file at /etc/default/dhtnode-http. Hope this helps. Tobi, would you please sponsor opendht 3.0.0-4 for me? Since it has a new binary package, I believe it will have to pass through NEW. https://mentors.debian.net/package/opendht/ Thanks, -a
Bug#869510: dhtnode: please handle connection problems gracefully
Hello, Aaron M. Ucko writes: > Petter Reinholdtsen writes: > >> I guess someone should test and figure out what the status is. The >> latest opendht is in Debian unstable and testing now. > > As of 2.4.10-1, it no longer floods logs, but it doesn't seem to have > found anything either: > > $ dhtnode > OpenDHT node [...] running on port [...] >(type 'h' or 'help' for a list of possible commands) > > >> ll > OpenDHT node [...] running on port [...] > >> 1 ongoing operations > Storage has 0 values, using 0 KB > IPv4 stats: > Known nodes: 0 good, 0 dubious, 0 incoming. > 0 searches, 0 total cached nodes > > IPv6 stats: > Known nodes: 0 good, 0 dubious, 0 incoming. > 0 searches, 0 total cached nodes > > Meanwhile, all I see in the log is > > dhtnode[...]: Bootstrap: bootstrap.ring.cx > > Thanks for asking! Have you tried specifying a bootstrap node explicitly with '-b'? bandali@sid:~$ dhtnode -b bootstrap.jami.net Bootstrap: bootstrap.jami.net OpenDHT node 7b6381a7314777d658e17e9cbd3938453a340294 running on port 47742 (type 'h' or 'help' for a list of possible commands) >> ll >> OpenDHT node 7b6381a7314777d658e17e9cbd3938453a340294 running on port 47742 1 ongoing operations Storage has 28 values, using 47 KB IPv4 stats: Known nodes: 10 good, 8 dubious, 1 incoming. 1 searches, 50 total cached nodes Routing table depth: 3 Network size estimation: 64 nodes IPv6 stats: Known nodes: 0 good, 7 dubious, 0 incoming. 0 searches, 8 total cached nodes Considering the various connectivity improvements in the recent and earlier releases since this bug was originally filed, and also that the forwarded copy of the was closed upstream, I suggest we close this bug here on the BTS as well. Best, -a
Bug#1002527: "milter-greylist -u user" considered harmful
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#1041293: elpa-boxquote: New upstream release 2.3
Control: tags -1 pending X-Debbugs-CC: Tobias Frost Hi Xiyue, Xiyue Deng writes: > Hi Amin, > > Amin Bandali writes: > >> Hey Manphiz, >> >> Thanks for the patch! >> >> However, looking at https://salsa.debian.org/emacsen-team/boxquote-el >> I see we have an 'upstream' branch in the repo, for tracking latest >> upstream commits. But it appears that for your MR you essentially >> cherry-picked the commits from the upstream repo, resulting in >> different commit hashes. >> >> But we'd like to preserve the original upstream commits, including >> in the 'master' branch where we have the 'debian' packaging directory. >> So, you'd want to add to your local clone of the boxquote-el repo a >> new remote pointing to the upstream repo residing on GitHub, fetch the >> remote, pull from its 'main' branch into our 'upstream', then merge >> the 'v2.3' tag (now the tip of 'upstream') into our 'master' branch: >> >> cd boxquote-el >> git checkout upstream >> git remote add upstreamvcs https://github.com/davep/boxquote.el.git >> git fetch upstreamvcs >> git pull upstreamvcs main >> git checkout master >> git merge v2.3 >> # followed by the rest of your changes (to the debian/ dir) >> >> You may be able to use tooling to automate this (e.g. using 'gbp' from >> the 'git-buildpackage' package), or do it manually as shown above. >> >> It's a bit inconvenient since you're not [yet] a member of the Emacsen >> team or the repository itself, so you won't be able to do this in the >> emacsen-team/boxquote-el repo itself just yet. Please do this in your >> own fork - push your updated 'master' and 'upstream' branches and the >> new 'v2.3' tag - and let me know. I'll then pull your changes from >> your fork into emacsen-team/boxquote-el. >> >> Lastly, once ready, would you like to try uploading your changes to >> mentors.debian.net and open an RFS (Request for Sponsorship) bug for >> this? It might be a useful exercise for your future contributions >> as well. :-) (ref: https://mentors.debian.net/sponsors/rfs-howto/) >> >> Please let me know if anything's unclear or if you have any questions >> or comments. >> >> Thanks, >> -a >> > > Thanks for the detailed instructions! This was one of the early > packaging works and I didn't really understand the workflow back then. > Glad to have your help! I've now reworked the merge request[1] and sync > an upstream branch in my repo, also opened another merge request[2] for > updating the upstream branch in the team repo. I've also built the > package using gbp and uploaded to mentors[3]. I didn't create a tag as > I don't think gitlab support merge requests for tags. Also I didn't > file a separate RFS bug yet as I may have to update the changelog to > close that bug again, or maybe I can just manually close that later. > Anyway, would be great to have your suggestions again. > > Thanks again, and PTAL. > > [1] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/3 > [2] https://salsa.debian.org/emacsen-team/boxquote-el/-/merge_requests/4 > [3] https://mentors.debian.net/package/boxquote-el/ Cheers, and thanks for the quick update. Looks good to me. I've merged both your MRs, though I did so directly, by pulling from your fork and pushing to the corresponding branch of the main repo under emacsen-team, to avoid merge commits (particularly important for the 'upstream' branch where we want our history to exactly match that of upstream repo's main branch). I also added an annotated, signed 'debian/2.3-1' tag pointing to the latest commit, since like you said you couldn't do that at the moment. And yeah we don't really *need* an RFS bug here, since I'm asking Tobi to sponsor the upload for us. Tobi, would you please sponsor the upload from mentors to unstable? https://mentors.debian.net/package/boxquote-el/ Thanks, -a
Bug#942501: src:milter-greylist: please drop libbind-dev build dependency, it's not in use and libbind-dev is going away
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#1041293: elpa-boxquote: New upstream release 2.3
Hey Manphiz, Thanks for the patch! However, looking at https://salsa.debian.org/emacsen-team/boxquote-el I see we have an 'upstream' branch in the repo, for tracking latest upstream commits. But it appears that for your MR you essentially cherry-picked the commits from the upstream repo, resulting in different commit hashes. But we'd like to preserve the original upstream commits, including in the 'master' branch where we have the 'debian' packaging directory. So, you'd want to add to your local clone of the boxquote-el repo a new remote pointing to the upstream repo residing on GitHub, fetch the remote, pull from its 'main' branch into our 'upstream', then merge the 'v2.3' tag (now the tip of 'upstream') into our 'master' branch: cd boxquote-el git checkout upstream git remote add upstreamvcs https://github.com/davep/boxquote.el.git git fetch upstreamvcs git pull upstreamvcs main git checkout master git merge v2.3 # followed by the rest of your changes (to the debian/ dir) You may be able to use tooling to automate this (e.g. using 'gbp' from the 'git-buildpackage' package), or do it manually as shown above. It's a bit inconvenient since you're not [yet] a member of the Emacsen team or the repository itself, so you won't be able to do this in the emacsen-team/boxquote-el repo itself just yet. Please do this in your own fork - push your updated 'master' and 'upstream' branches and the new 'v2.3' tag - and let me know. I'll then pull your changes from your fork into emacsen-team/boxquote-el. Lastly, once ready, would you like to try uploading your changes to mentors.debian.net and open an RFS (Request for Sponsorship) bug for this? It might be a useful exercise for your future contributions as well. :-) (ref: https://mentors.debian.net/sponsors/rfs-howto/) Please let me know if anything's unclear or if you have any questions or comments. Thanks, -a
Bug#1053654: ITP: erc -- powerful, modular, and extensible IRC client for Emacs
X-Debbugs-CC: Tobias Frost , David Bremner Dear Tobi, This is now ready for review and hopefully upload through NEW. :-) https://mentors.debian.net/package/erc/ https://salsa.debian.org/emacsen-team/erc Thanks in advance, -a P.S. I checked with David about (re)using the existing 'erc' source package name for my packaging, especially considering it's been unused and not part of any releases for years.
Bug#1053654: ITP: erc -- powerful, modular, and extensible IRC client for Emacs
Package: wnpp Severity: wishlist Owner: band...@gnu.org X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emac...@lists.debian.org * Package name: erc Version : 5.5 Upstream Contact: Amin Bandali , F. Jason Park * URL : https://www.gnu.org/software/emacs/erc.html * License : GPL-3+ Programming Lang: Emacs Lisp Description : powerful, modular, and extensible IRC client for Emacs ERC is a powerful, modular, and extensible Internet Relay Chat (IRC) client distributed with GNU Emacs since version 22.1. ERC comes with the following capabilities enabled by default: - Timestamps - Flood control - Join channels automatically - Buttonized URLs, nicknames, and other text - Wrap long lines - Highlight or remove IRC control characters - Highlight pals, fools, and other keywords - Detect netsplits - Complete nicknames and commands in a programmable fashion - Make displayed lines read-only - Input history - Track channel activity in the mode-line Since ERC is currently developed and maintained as a 'core' package in emacs.git (the GNU Emacs source tree), and GNU Emacs release timings may not always align nicely with Debian releases, having a standalone ERC package would enable users to have an up-to-date version of ERC independently of the Emacs version. I am one of the upstream maintainers of ERC, I use it regularly, and I plan to maintain this package as part of the Debian Emacsen team.
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
Control: tags -1 pending Hey Manphiz, Manphiz writes: > Hi Amin, > > Amin Bandali writes: > >> Hiya, >> >> Manphiz writes: >> >>> Manphiz writes: >>> >>>> Another finding is that in 28.x, if the term buffer have any further >>>> questions to ask, debian-bug seems to consider the process stuck and >>>> would just ignore everything and proceed. In 29.x however, the term >>>> buffer seems to be able to accept user input and can process the output >>>> accordingly - even if the script requires sudo and prompt for password, >>>> and debian-bug can properly include the output in the generated email >>>> for bug report. So with the merge request[4] it would instead skip all >>>> potential additional information unfortunately. >>>> >>> >>> Actually 28.x also works for user inputs if running term-exec without my >>> problematic hooks so yeah! >>> >>>> As we do want to handle process termination better, while trying to keep >>>> process from failing, I think temporarily disable term-exec-hook when >>>> processing the output and restore after the report is generated should >>>> probably work in most cases. Just wondering whether this is acceptable >>>> in the process of debian-bug? >>>> >>> >>> Forgot to mention that this is implemented as the 2nd commit in the >>> MR[4] and tested on bookworm and trixie to be working. >>> >>>> [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11 >> >> Thank you for the patch. :-) This seems like a reasonable fix to me, >> and if David has no comments or objections I'd be happy to merge it >> in the coming days. >> >> Quick request: would you please amend your patch/MR to add a >> debian/changelog entry for the change(s)? It would be good to >> do a new upload soon, and it'd be nice to have debian/changelog >> in tiptop shape for that. >> >> Thanks, >> -a > > Thanks for the review! I've pushed another commit adding the changelog > entries, and changed some of the commit message to be consistent, so > please force pull if you want to test again. Would definitely look > forward to hearing from David as well. Cheers; and thanks, I've merged the MR now! > P.S. I'm also testing some patches to fix the comp warnings and > hopefully can be included in the next upload. Will send another merge > request when ready. ACK, I'll rebase and review that one as well. Thanks, -a signature.asc Description: PGP signature
Bug#858421: ITP: delight -- Emacs utility to customise the mode line
X-Debbugs-CC: Tobias Frost Dear Tobi, This is now ready for review and hopefully upload through NEW. :-) https://mentors.debian.net/package/delight/ https://salsa.debian.org/emacsen-team/delight Thanks, -a
Bug#1053296: RFS: kcollectd/0.12.1-1 -- simple collectd graphing front-end for KDE
X-Debbugs-CC: Tobias Frost Hello Antonio, Antonio Russo writes: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "kcollectd": > > * Package name : kcollectd >Version : 0.12.1-1 >Upstream contact : Antonio Russo > * URL : https://www.antonioerusso.com/projects/kcollectd > * License : GFDL-1.3+, PUBLIC-DOMAIN, GPL-3+ > * Vcs : https://salsa.debian.org/qt-kde-team/extras/kcollectd >Section : utils > > The source builds the following binary packages: > > kcollectd - simple collectd graphing front-end for KDE > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/kcollectd/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/k/kcollectd/kcollectd_0.12.1-1.dsc > > Changes since the last upload: > > kcollectd (0.12.1-1) unstable; urgency=medium > . >* New upstream release 0.12.1. > - Align translations with source code (Closes: #1048793) >* Bump Standards-Version to 4.6.2, no changes required. > > Best, > Antonio Russo > > Thank you, looks good to me. I've tested and I confirm that I can't reproduce #1048793 with kcollectd 0.12.1-1. Small feedback: please consider updating debian/copyright with the current information/years in one of your future uploads. :-) Tobi, would you please sponsor this to unstable? Thanks in advance. -a signature.asc Description: PGP signature
Bug#1050685: elpa-debian-el: Error when using debian-bug on certain binary package: (wrong-type-argument processp nil)
Hiya, Manphiz writes: > Manphiz writes: > >> Another finding is that in 28.x, if the term buffer have any further >> questions to ask, debian-bug seems to consider the process stuck and >> would just ignore everything and proceed. In 29.x however, the term >> buffer seems to be able to accept user input and can process the output >> accordingly - even if the script requires sudo and prompt for password, >> and debian-bug can properly include the output in the generated email >> for bug report. So with the merge request[4] it would instead skip all >> potential additional information unfortunately. >> > > Actually 28.x also works for user inputs if running term-exec without my > problematic hooks so yeah! > >> As we do want to handle process termination better, while trying to keep >> process from failing, I think temporarily disable term-exec-hook when >> processing the output and restore after the report is generated should >> probably work in most cases. Just wondering whether this is acceptable >> in the process of debian-bug? >> > > Forgot to mention that this is implemented as the 2nd commit in the > MR[4] and tested on bookworm and trixie to be working. > >> [4] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/11 Thank you for the patch. :-) This seems like a reasonable fix to me, and if David has no comments or objections I'd be happy to merge it in the coming days. Quick request: would you please amend your patch/MR to add a debian/changelog entry for the change(s)? It would be good to do a new upload soon, and it'd be nice to have debian/changelog in tiptop shape for that. Thanks, -a
Bug#1051364: nvi uses Conflicts in violation of policy 10.1
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#1052481: ITP: libgedit-gtksourceview -- Gedit's fork of gtksourceview4
Package: wnpp Severity: wishlist Owner: Amin Bandali * Package name: libgedit-gtksourceview Version : 299.0.4 Upstream Contact: Sébastien Wilmet * URL : https://github.com/gedit-technology/libgedit-gtksourceview * License : LGPL-2.1+ Programming Lang: C Description : libgedit-gtksourceview is a library that extends GtkTextView, the standard GTK widget for multiline text editing libgedit-gtksourceview is a library that extends GtkTextView, the standard GTK widget for multiline text editing. This library adds support for syntax highlighting, undo/redo, file loading and saving, search and replace, a completion system, printing, displaying line numbers, and other features typical of a source code editor. gedit 45.0 and later depend on libgedit-gtksourceview instead of GtkSourceView, thus this package is needed for packaging newer versions of gedit. This package will be maintained as part of the Debian GNOME team.
Bug#1042038: mfem: FTBFS: hash.hpp:1001:39: error: ISO C++ forbids declaration of ‘type name’ with no type [-fpermissive]
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
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#1031100: ring: diff for NMU version 20230206.0~ds1-4.2
Adrian Bunk writes: > On Sat, Feb 11, 2023 at 11:47:30PM -0500, Amin Bandali wrote: >>... >> For future changes, if you like, you're also welcome to send patches >> against the package's git repo, either as merge requests on GitLab, >> or as "git format-patch"es here on the BTS per usual. > > That's what I would usually do, I am only this aggressive with uploading > when last-minute fixes are required for getting a package into a release > before a freeze deadline. > >> thanks, >> -a >>... > > cu > Adrian > Ack, makes sense. thanks again, -a
Bug#1030855: ring_20230206.0~ds1-2_amd64-buildd.changes REJECTED
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 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
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)))
Bug#1030161: roundcube: Fix short date test before and after ICU 72.1
Source: roundcube
Version: 1.6.0+dfsg-1
Severity: normal
Tags: patch
Hello there,
Would you please consider adopting the attached patch (also forwarded
and applied upstream) for fixing the test suite breakage both before
and after ICU 72.1? Though Debian unstable and testing already have
ICU 72.1, Ubuntu lunar (devel) is still on 71.1, and it would be great
if this failure was fixed such that roundcube would build with ICU
both older or newer than 72.1.
Thanks,
amin
>From 65c93a6d80218b288e5178ba2692da563bb5015e Mon Sep 17 00:00:00 2001
From: Amin Bandali
Date: Tue, 31 Jan 2023 11:08:23 -0500
Subject: [PATCH] Fix broken short date test with ICU >= 72.1
Forwarded: https://github.com/roundcube/roundcubemail/pull/8904
Applied-Upstream: 5d99ffb766bdb49efb2a8fe9d611f02d5776d0f2
Last-Update: 2023-01-31
* tests/Rcmail/Rcmail.php (test_format_date): Starting with ICU 72.1,
a NARROW NO-BREAK SPACE (NNBSP) is used instead of an ASCII space
before the meridian. So, check for an NNBSP when using ICU >= 72.1.
References:
* https://icu.unicode.org/download/72
* https://cldr.unicode.org/index/downloads/cldr-42
* https://github.com/unicode-org/icu/pull/2103
---
tests/Rcmail/Rcmail.php | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/Rcmail/Rcmail.php b/tests/Rcmail/Rcmail.php
index 48879b3a7..4a16b38d4 100644
--- a/tests/Rcmail/Rcmail.php
+++ b/tests/Rcmail/Rcmail.php
@@ -279,7 +279,14 @@ class Rcmail_Rcmail extends ActionTestCase
$this->assertSame(' Mon', $rcmail->format_date($date, ' D'));
$this->assertSame('D Monday', $rcmail->format_date($date, '\\D l'));
$this->assertSame('Jun June', $rcmail->format_date($date, 'M F'));
-$this->assertSame('6/1/20, 12:20 PM', $rcmail->format_date($date,
'x'));
+$date_x = '6/1/20, 12:20 PM';
+if (defined('INTL_ICU_VERSION')
+ && version_compare(INTL_ICU_VERSION, '72.1', '>=')) {
+// Starting with ICU 72.1, a NARROW NO-BREAK SPACE (NNBSP)
+// is used instead of an ASCII space before the meridian.
+$date_x = '6/1/20, 12:20 PM';
+}
+$this->assertSame($date_x, $rcmail->format_date($date, 'x'));
$this->assertSame('1591014030', $rcmail->format_date($date, 'U'));
$this->assertSame('2020-06-01T12:20:30+00:00',
$rcmail->format_date($date, 'c'));
}
--
2.37.2
Bug#1024670: tiff: CVE-2022-2519 CVE-2022-2520 CVE-2022-2521 CVE-2022-2953
Source: tiff Version: 4.4.0-5 Severity: important Tags: security Hello, The following vulnerabilities had been published for tiff: CVE-2022-2519[0]: | There is a double free or corruption in rotateImage() at | tiffcrop.c:8839 found in libtiff 4.4.0rc1 https://gitlab.com/libtiff/libtiff/-/issues/423 https://gitlab.com/libtiff/libtiff/-/merge_requests/378 https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba CVE-2022-2520[1]: | A flaw was found in libtiff 4.4.0rc1. There is a sysmalloc assertion | fail in rotateImage() at tiffcrop.c:8621 that can cause program crash | when reading a crafted input. https://gitlab.com/libtiff/libtiff/-/issues/424 https://gitlab.com/libtiff/libtiff/-/merge_requests/378 https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba CVE-2022-2521[2]: | It was found in libtiff 4.4.0rc1 that there is an invalid pointer free | operation in TIFFClose() at tif_close.c:131 called by tiffcrop.c:2522 | that can cause a program crash and denial of service while processing | crafted input. https://gitlab.com/libtiff/libtiff/-/issues/422 https://gitlab.com/libtiff/libtiff/-/merge_requests/378 https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba CVE-2022-2953[3]: | LibTIFF 4.4.0 has an out-of-bounds read in extractImageSection in | tools/tiffcrop.c:6905, allowing attackers to cause a denial-of-service | via a crafted tiff file. For users that compile libtiff from sources, | the fix is available with commit 48d6ece8. https://gitlab.com/libtiff/libtiff/-/issues/414 https://gitlab.com/libtiff/libtiff/-/commit/8fe3735942ea1d90d8cef843b55b3efe8ab6feaf https://gitlab.com/libtiff/libtiff/-/commit/bad48e90b410df32172006c7876da449ba62cdba I saw they are marked as "unimportant" in Debian's security tracker, but I thought I would file this bug report anyway. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-2519 https://www.cve.org/CVERecord?id=CVE-2022-2519 [1] https://security-tracker.debian.org/tracker/CVE-2022-2520 https://www.cve.org/CVERecord?id=CVE-2022-2520 [2] https://security-tracker.debian.org/tracker/CVE-2022-2521 https://www.cve.org/CVERecord?id=CVE-2022-2521 [3] https://security-tracker.debian.org/tracker/CVE-2022-2953 https://www.cve.org/CVERecord?id=CVE-2022-2953 Please adjust the affected versions in the BTS as needed. Best, amin
Bug#1016489: opendht: Prepare for new upstream version 2.4.9
Source: opendht
Version: 2.3.1-1
Severity: important
Tags: patch
Hello,
Please find attached the patch for preparing for new upstream version
2.4.9. Please pull in the latest release after merging this.
>From 19922ba06d462b6af7873f8889ec39a41d99b857 Mon Sep 17 00:00:00 2001
From: Amin Bandali
Date: Mon, 1 Aug 2022 12:29:29 -0400
Subject: [PATCH] Prepare for new upstream version 2.4.9
* d/watch: Tweak opts to use newly-suggested format in the current
uscan(1) manual for GitHub repositories, helping correctly detect
the new 2.4.9 release.
* d/patches: Refresh pkgconfig-static.patch for latest upstream
release.
---
debian/changelog | 14 ++
debian/patches/pkgconfig-static.patch | 2 +-
debian/watch | 4 ++--
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index e8d06fe..46925d8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+opendht (2.4.9-1) UNRELEASED; urgency=medium
+
+ [ Amin Bandali ]
+ * d/watch: Tweak opts to use newly-suggested format in the current
+uscan(1) manual for GitHub repositories, helping correctly detect
+the new 2.4.9 release.
+ * d/patches: Refresh pkgconfig-static.patch for latest upstream
+release.
+
+ [ Alexandre Viau ]
+ * New upstream version.
+
+ -- Alexandre Viau Mon, 01 Aug 2022 12:12:12 -0500
+
opendht (2.3.1-1) unstable; urgency=medium
[ Amin Bandali ]
diff --git a/debian/patches/pkgconfig-static.patch b/debian/patches/pkgconfig-static.patch
index 9955b84..ff82a1b 100644
--- a/debian/patches/pkgconfig-static.patch
+++ b/debian/patches/pkgconfig-static.patch
@@ -8,7 +8,7 @@ Author: Alexandre Viau
+++ b/opendht.pc.in
@@ -5,7 +5,7 @@
Name: OpenDHT
- Description: C++14 Distributed Hash Table library
+ Description: C++17 Distributed Hash Table library
Version: @VERSION@
-Libs: -L${libdir} -lopendht
+Libs: -L${libdir} -lopendht -lnettle -lgnutls -largon2 -lhttp_parser
diff --git a/debian/watch b/debian/watch
index b42aa67..31ca925 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
version=4
-opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*@ARCHIVE_EXT@)%@PACKAGE@-$1%" \
https://github.com/savoirfairelinux/opendht/tags \
- (?:.*?/)?@ANY_VERSION@@ARCHIVE_EXT@
+ (?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@
--
2.36.1
Bug#979492: jami: Package description should be improved
Hi Bruno, :-) Thank you for your patch. I've opened a merge request with improvements to both the package description and the appstream metadata: https://salsa.debian.org/pkg-voip-team/ring/-/merge_requests/5 Alexandre, would you please merge this? Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#980571: jami-daemon: [patch] Get SIP calls to Zoom working
Hello and thanks to you both. :-) I opened a merge request adding this patch to d/patches for now: https://salsa.debian.org/pkg-voip-team/ring/-/merge_requests/6 Alexandre, would you please merge this MR? Also, once this and the other MR are merged, let's do a new upload that would hopefully make it into testing on time before the freeze. Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#980571: please forward to upstream
Petter Reinholdtsen writes: > Control: forwarded -1 > https://git.jami.net/savoirfairelinux/ring-daemon/-/issues/406 > > The SIP patch was applied to upstream master branch three days ago, > https://git.jami.net/savoirfairelinux/ring-daemon/-/commit/27504587e5dafadf986796f5ce0b1f065a3800bc > >. > > The FFMPEG patch has been included in the Debian package in bullseye > since 2021-01-29. Thanks for the update. Alexandre, since we are likely not pulling in a new upstream release for Debian testing last minute (there have been a few large upstream changes over the past ~2 weeks), let's apply this patch here on the Debian side. Also, I'll open an MR against the repo with a slightly revised patch for #979492, and once we've merged these two changes let's do a new upload to unstable asap so that hopefully it can make it into testing in time before the freeze next week. Best, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#912173: ring FTCBFS: multiple reasons
Hi Helmut, Helmut Grohne writes: > Hi Amin, > > On Wed, Dec 30, 2020 at 11:30:48AM -0500, Amin Bandali wrote: >> I'm inclined to close this since Jami builds fine now. > > Doesn't look like that to me: > > http://crossqa.debian.net/build/ring_20201217.1.80217fa%7Eds1-2_arm64_20201229181656.log > > Did you try applying my patch? > > Helmut > Whoops, you're quite right, sorry! I somehow misread/misunderstood the report. I have not tried your patch yet. Would you please share the exact series of commands used to attempt the above build, so I could try and do some digging locally? Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#912173: ring FTCBFS: multiple reasons
I'm inclined to close this since Jami builds fine now. Alexandre? -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#978562: opendht: FTBFS on riscv64, linked with -lpthread instead of -pthread
Hello, Aurelien Jarno writes: > Hi, > > On 2020-12-28 18:01, Amin Bandali wrote: >> Hello Alexandre, Aurelien, >> >> Thanks for the patch. I don't have access to any riscv64 machines to >> test this. However if you confirm that it fixes the build on riscv64 >> and introduces no regressions on any arches then I'll ask for it to be >> applied upstream. > > I have tested it on riscv64, and I confirm it builds fine. As for > regression on other architectures, I have also tested this patch on > amd64 and i386. By experience, I doubt it will create any regression. I see, thank you! opendht 2.1.10 [0] has just been released including the proposed change. :-) [0]: https://github.com/savoirfairelinux/opendht/releases/tag/2.1.10 Alexandre, let's bump Debian's opendht and upload it to unstable. > Aurelien Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#978562: opendht: FTBFS on riscv64, linked with -lpthread instead of -pthread
Hello Alexandre, Aurelien, Thanks for the patch. I don't have access to any riscv64 machines to test this. However if you confirm that it fixes the build on riscv64 and introduces no regressions on any arches then I'll ask for it to be applied upstream. Thanks, -- Amin Bandali Free Software Consultant Savoir-faire Linux jami:bandali
Bug#950198: Fixing build with jami_20191214.1.07edb5e
Alexandre Viau writes: > Hello! > > Thank you very much for helping! > Cheers! > > It looks like you made your changes alongside updates to the upstream > source. > > Sadly I won't merge any changes to the upstream sources. I'll handle > these myself with git-buildpackage. > Indeed. I now know better for future changes. :-) > > Can you please submit your opendht changes again, this time only > including the changes in the debian/ folder? > Sure, here we go: - Tweaks for building more recent versions of Jami with <https://salsa.debian.org/debian/opendht/-/merge_requests/6> > > Then, we will move on to Jami. > Sounds good. > > Cheers, > Best, -- Amin Bandali Free Software Consultant Savoir-faire Linux GNU Jami: bandali
Bug#950198: Fixing build with jami_20191214.1.07edb5e
Hello Alexandre, all, I recently joined the Jami team at SFL, and I'm also the newly-appointed GNU (co)maintainer for Jami. I would like to help improve the situation with the Jami package in the official Debian repositories however I can. I think the first step would be getting more recent versions of the Jami Debian package to build. I opened a number of merge requests against Debian's package sources for OpenDHT and Jami, including changes with which I've been able to build the WIP update to the jami_20191214.1.07edb5e version. The merge requests are as follows: - New upstream version 2.1.6: https://salsa.debian.org/debian/opendht/-/merge_requests/3 - pristine-tar data for opendht_2.1.6.orig.tar.gz: https://salsa.debian.org/debian/opendht/-/merge_requests/4 - Update to new upstream version 2.1.6, along with tweaks useful for building newer versions of jami: https://salsa.debian.org/debian/opendht/-/merge_requests/5 - Fix build with jami_20191214.1.07edb5e: https://salsa.debian.org/pkg-voip-team/ring/-/merge_requests/2 In essence, I pulled the latest version of OpenDHT into the Debian source repo for it, and tweaked the CONFIGURE_FLAGS and the Libs link flags in pkgconfig-static.patch to make the package useful for linking and building newer Jami against. On the Jami side, I updated the file name for the jami-gnome manpage, and also changed some (non-existent) 'distclean' instances to 'clean' so that the build wouldn't fail with a non-clean tree. I'd appreciate it if y'all would take my changes for a spin and see if you're able to build jami_20191214.1.07edb5e with them. If yes, and if everyone's happy with the changes and they're merged, next we could try building the most recent version of Jami and see how that goes. Best, -- Amin Bandali Free Software Consultant Savoir-faire Linux GNU Jami: bandali
