Bug#1073918: Multitouch gestures does not work.
More digging: Seems this issue really is about revisiting https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020640. wxGLCanvas EGL was deemed as not ready for prime time some 18 months ago. Is it now?
Bug#1073918: Multitouch gestures does not work.
Package: wxwidgets3.2 Version: 3.2.2+dfsg-2 Working with the opencpn package we have discovered that multitouch gestures does not work using the wxWidgets package[1] However, the gestures do work when using Wayland and EGL. This has been shown using locally built wxWidgets packages without the Debian patch and also without --disable-glcanvasegl. So the solution is basically #1057478 [1] https://github.com/OpenCPN/OpenCPN/issues/2057
Bug#1070256: closed by Debian FTP Masters (reply to Alec Leamas ) (Bug#1070256: fixed in libcxx-serial 1.2.1-6)
On Thu, 23 May 2024 21:19:14 +0300 Adrian Bunk wrote: Control: reopen -1 On Sun, May 12, 2024 at 07:09:07PM +, Debian Bug Tracking System wrote: >... > Changes: > libcxx-serial (1.2.1-6) trixie; urgency=medium > . >* Avoid crash when running with nocheck profile. Closes: #1070256 >... 1.2.1-7 does still FTBFS: https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial=sh4=1.2.1-7=1715548569=0 ifeq (,$(findstring nocheck,$(DEB_BUILD_PROFILES))) ENABLE_TESTS := ON else ENABLE_TESTS := OFF endif This should be DEB_BUILD_OPTIONS, not DEB_BUILD_PROFILES. I can see the build log, but have problems reproducing the problem. In short, I do $ export DEB_BUILD_OPTIONS=nobench nocheck parallel=2 $ dpkg-buildpackage --sanitize-env -us -uc -B -rfakeroot which configures and builds successfully. Attaching the build log. Have you any hint about what's going on? Cheers! --alec dpkg-buildpackage: info: source package libcxx-serial dpkg-buildpackage: info: source version 1.2.1-7 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Alec Leamas dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 0001-build-Fix-packaging-issues.patch dpkg-source: info: applying 0002-Avoid-using-v8stdint.h-if-not-required.patch dpkg-source: info: applying 0003-on-Linux-use-CLOCK_MONOTONIC-for-clock_gettime.patch dpkg-source: info: applying 0004-resource-leak-if-exception-in-SerialImpl-constructor.patch dpkg-source: info: applying 0005-Support-500kbps-serial-ports.-167.patch dpkg-source: info: applying 0006-Fix-memory-leak-when-exception-is-thrown-by-impl-cla.patch dpkg-source: info: applying 0007-tests-CMakeLists-avoid-crash-w-disabled-tests.patch dpkg-source: info: applying 0008-Make-sure-package.xml-is-installed.patch debian/rules clean echo foobar foobar echo DEB_BUILD_PROFILES: DEB_BUILD_PROFILES: echo ENABLE_TESTS: ON ENABLE_TESTS: ON dh clean --buildsystem=cmake dh_auto_clean -O--buildsystem=cmake dh_autoreconf_clean -O--buildsystem=cmake dh_clean -O--buildsystem=cmake debian/rules binary-arch echo foobar foobar echo DEB_BUILD_PROFILES: DEB_BUILD_PROFILES: echo ENABLE_TESTS: ON ENABLE_TESTS: ON dh binary-arch --buildsystem=cmake dh_update_autotools_config -a -O--buildsystem=cmake dh_autoreconf -a -O--buildsystem=cmake debian/rules override_dh_auto_configure make[1]: Entering directory '/home/mk/cxx-serial/cxx-serial' dh_auto_configure -- \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DCATKIN_ENABLE_TESTING=ON cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run -DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_VERBOSE_MAKEFILE=ON -DCATKIN_ENABLE_TESTING=ON .. -- The C compiler identification is GNU 13.2.0 -- The CXX compiler identification is GNU 13.2.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Using CATKIN_DEVEL_PREFIX: /home/mk/cxx-serial/cxx-serial/obj-x86_64-linux-gnu/devel -- Using CMAKE_PREFIX_PATH: CMake Warning (dev) at /usr/share/catkin/cmake/python.cmake:7 (find_package): Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules are removed. Run "cmake --help-policy CMP0148" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): /usr/share/catkin/cmake/all.cmake:164 (include) /usr/share/catkin/cmake/catkinConfig.cmake:20 (include) tests/CMakeLists.txt:9 (find_package) This warning is for project developers. Use -Wno-dev to suppress it. -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.11.6", minimum required is "3") -- Using PYTHON_EXECUTABLE: /usr/bin/python3 -- Using Debian Python package layout -- Using empy: /usr/bin/empy -- Using CATKIN_ENABLE_TESTING: ON -- Call enable_testing() -- Using CATKIN_TEST_RESULTS_DIR: /home/mk/cxx-serial/cxx-serial/obj-x86_64-linux-gnu/test_results -- GTest is available -- GMock is available -- Using Python nosetests: /usr/bin/nosetests -- Found Threads: TRUE -- catkin 0.8.10 -- BUILD_SHARED_LIBS is on -- Found
Bug#1053446: xdg-email portal unavailable after default install
Package: flatpak Version: 1.14.3-1 After a default install + installing flatpak the xdg-email portal does not work. The reason is that the native xdg-email application is not available, it is part of the xdg-utils package which not is pulled in by the flatpak package. According to the descripion, the flatpak package "contains the services and executables needed to install and launch sandboxed applications, and the portal services needed to provide limited access to resources outside the sandbox." Since the xdg-email portal requires xdg-utils, the flatpak package IMHO thus should add a "Depends: xdg-utils" or possibly "Recommends", either directly in the flatpak package or indirectly in for example xdg-desktop-portal.
Bug#1051759: opencpn/5.8.4+dfsg-1~bpo12+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my backport of the package "opencpn". This is a clean rebuild of the package in sid. I have DM rights for opencpn. However, this does not allow me to even upload for review by ftp-masters so I need some DD help to enter the NEW queue. Details: * Package name : opencpn Version : 5.8.4+dfsg-1~bpo12+1 Upstream contact : Dave S. Register * URL : https://opencpn.org * License : SGI-B-2.0, SGI-B-1.1, GPL-2, Expat, public-domain, GPL-2+, LGPL-2+, Khronos, BSD-3-clause, wxWidgets, GPL-3+, GPL-3, Expat or GPL-2+ * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.8.4+dfsg-1~bpo12+1.dsc Changes since the last upload: opencpn (5.8.4+dfsg-1~bpo12+1) bookworm-backports; urgency=medium . * New upstream release * Rebuilt for bookworm-backports. Regards, -- Alec Leamas
Bug#1042006: RFS: opencpn/5.8.4+dfsg-1~bpo11+1 -- Open Source Chartplotter and Marine GPS navigation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn". I have DM upload permissions for this package, but needs help to get the first bullseye-sloppy to enter the NEW queue (!) * Package name : opencpn Version : 5.8.4+dfsg-1~bpo11+1 Upstream contact : Dave S. Register * URL : https://opencpn.org * License : SGI-B-2.0, SGI-B-1.1, GPL-2, Expat, public-domain, GPL-2+, LGPL-2+, Khronos, BSD-3-clause, wxWidgets, GPL-3+, GPL-3, Expat or GPL-2+ * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.8.4+dfsg-1~bpo11+1.dsc Changes since the last upload: opencpn (5.8.4+dfsg-1~bpo11+1) bullseye-backports-sloppy; urgency=medium . * New upstream-release * Rebuilt for bullseye-backports-sloppy. Regards, -- alec leamas
Bug#1025939: opencpn: crashes upon starting
On Sun, 5 Mar 2023 11:55:55 +0100 Alec Leamas wrote: Simply stated, I cannot reproduce this, and we have not other reports like this one. My conclusion is that this is something related to your specific setup. The first test would be to move your .opencpn directory to another location before starting opencpn. This forces a clean, default setup. If this does not help, the next step would be to create a stack trace. Is this something you know how to do? Ping? Any news here?
Bug#1027015: fixed in wxwidgets3.2 3.2.1+dfsg-4
I can work around this in the OpenCPN package using patch below, which
solves my immediate problem
However, it seems that the upstream solution to 22790 just does not
compile in Debian, so this is still a bug IMHO. A little unsure if this
then is a new bug, but since I already have reopened this and the
issues are tightly coupled I leave it this way.
--
diff --git a/include/bbox.h b/include/bbox.h
index e7feeb9..79f1fb0 100644
--- a/include/bbox.h
+++ b/include/bbox.h
@@ -6,6 +6,12 @@
#include "wx/wx.h"
#endif
+// work around wxWidgets #22790 follow-up bug.
+
+#ifndef WXDLLIMPEXP_CORE
+#define WXDLLIMPEXP_CORE __attribute__(visibility("default"))
+#endif
+
#include "wx/matrix.h"
#include "wx/geometry.h"
On Mon, 6 Mar 2023 12:09:31 +0100 Alec Leamas wrote:
This has resurfaced in 3.2.2, it seems that the upstream bug is still
not fixed.
This leads to FTBFS errors for openpcn like below, so important to me.
Investigating.
---
In file included from /usr/include/wx-3.2/wx/defs.h:550,
from /usr/include/wx-3.2/wx/wxprec.h:12,
from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:27:
/usr/include/wx-3.2/wx/matrix.h:44:1: error: expected identifier before
‘__attribute__’
44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject
| ^~~~
In file included from /home/mk/OpenCPN/OpenCPN/include/bbox.h:9,
from /home/mk/OpenCPN/OpenCPN/include/s52s57.h:31,
from /home/mk/OpenCPN/OpenCPN/include/s52plib.h:31,
from /home/mk/OpenCPN/OpenCPN/include/chartsymbols.h:28,
from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:36:
/usr/include/wx-3.2/wx/matrix.h:44:35: error: expected initializer
before ‘:’ token
44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject
Bug#1027015: fixed in wxwidgets3.2 3.2.1+dfsg-4
This has resurfaced in 3.2.2, it seems that the upstream bug is still not fixed. This leads to FTBFS errors for openpcn like below, so important to me. Investigating. --- In file included from /usr/include/wx-3.2/wx/defs.h:550, from /usr/include/wx-3.2/wx/wxprec.h:12, from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:27: /usr/include/wx-3.2/wx/matrix.h:44:1: error: expected identifier before ‘__attribute__’ 44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject | ^~~~ In file included from /home/mk/OpenCPN/OpenCPN/include/bbox.h:9, from /home/mk/OpenCPN/OpenCPN/include/s52s57.h:31, from /home/mk/OpenCPN/OpenCPN/include/s52plib.h:31, from /home/mk/OpenCPN/OpenCPN/include/chartsymbols.h:28, from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:36: /usr/include/wx-3.2/wx/matrix.h:44:35: error: expected initializer before ‘:’ token 44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject
Bug#1025939: opencpn: crashes upon starting
On Mon, 12 Dec 2022 09:40:44 + Laurent Savaete wrote: > Package: opencpn > Version: 5.6.2+dfsg-2 > Severity: important > > Dear Maintainer, > > Simply starting opencpn from either start menu or command line (with `opencpn`), > the program starts, sometimes displays the main window with the map for about > half a seconds, then crashes with "Segmentation fault". Hi, Sorry for late reply. > This is from a simple `apt install opencpn` setup. Indeed. Simply stated, I cannot reproduce this, and we have not other reports like this one. My conclusion is that this is something related to your specific setup. The first test would be to move your .opencpn directory to another location before starting opencpn. This forces a clean, default setup. If this does not help, the next step would be to create a stack trace. Is this something you know how to do?
Bug#1032370: long delays when exiting
Package: opencpn Version: 5.6.2+dfsg-1 When exiting, opencpn over time makes a long delay (minutes) before all related activities are completed. The problem is not present direct after installation, it surfaces after having exited opencpn several times. Each time opencpn is exited, the problem gets worse. This is upstream bughttps://github.com/OpenCPN/OpenCPN/issues/3042. The core reason is a line in the config file which gets duplicated, one more line for each exit. When reported, the exit delay was > 10 minutes(!)
Bug#1032296: long delays when exiting
Package: opencpn Version: 5.6.2+dfsg-1~bpo11+2 When exiting, opencpn over time makes a long delay (minutes) before all related activities are completed. The problem is not present direct after installation, it surfaces after having exited opencpn several times. Each time opencpn is exited, the problem gets worse. This is upstream bug https://github.com/OpenCPN/OpenCPN/issues/3042. The core reason is a line in the config file which gets duplicated, one more line for each exit. When reported, the exit delay was > 10 minutes(!)
Bug#1027015: matrix.h: Compilation failure.
Package: libwxgtk3.2-dev
Version: 3.2.1+dfsg-1
When including the file /usr/include/wx-3.2/wx/matrix.h compilation
fails. Example output from compiling opencpn below.
This is upstream bug
https://github.com/wxWidgets/wxWidgets/issues/22790. The bug is
acknowledged and a fix is under way for 3.2.2 or 3.2.3.
Attaching a patch based in the already merged fixes upstream. The
original fixes are quite complex since they have to deal with all sorts
of configurations not available on Debian. The patch is simplified, just
aiming top solve the actual problem in Debian until next upstream
release is available.
[ 11%] Building CXX object
libs/gdal/CMakeFiles/GDAL.dir/src/ogrfeaturedefn.cpp.o
cd /home/mk/OpenCPN/OpenCPN/obj-x86_64-linux-gnu/libs/gdal &&
/usr/bin/g++-10 -DHAVE_WEBVIEW -DHAVE_WX_GESTURE_EVENTS -DWXUSINGDLL
-D_FILE_OFFSET_BITS=64 -D__WXGTK__ -DocpnUSE_GL -DocpnUSE_SVG
-DwxUSE_WEBVIEW=1 -I/home/mk/OpenCPN/OpenCPN/libs/gdal/include/gdal
-I/home/mk/OpenCPN/OpenCPN/libs/gdal/include -isystem
/usr/lib/x86_64-linux-gnu/wx/include/gtk3-unicode-3.2 -isystem
/usr/include/wx-3.2 -g -O2 -ffile-prefix-map=/home/mk/OpenCPN/OpenCPN=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -pthread -O2 -g -DNDEBUG-DPREFIX=\"/usr\"
-fvisibility=hidden -Wall -Wno-unused -fexceptions -rdynamic
-fno-strict-aliasing -Wno-deprecated-declarations -std=gnu++11 -MD -MT
libs/gdal/CMakeFiles/GDAL.dir/src/ogrfeaturedefn.cpp.o -MF
CMakeFiles/GDAL.dir/src/ogrfeaturedefn.cpp.o.d -o
CMakeFiles/GDAL.dir/src/ogrfeaturedefn.cpp.o -c
/home/mk/OpenCPN/OpenCPN/libs/gdal/src/ogrfeaturedefn.cpp
In file included from /usr/include/wx-3.2/wx/defs.h:550,
from /usr/include/wx-3.2/wx/wxprec.h:12,
from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:27:
/usr/include/wx-3.2/wx/matrix.h:44:1: error: expected identifier before
‘__attribute__’
44 | WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject
| ^~~~
In file included from /home/mk/OpenCPN/OpenCPN/include/bbox.h:9,
from /home/mk/OpenCPN/OpenCPN/include/s52s57.h:31,
from /home/mk/OpenCPN/OpenCPN/include/s52plib.h:31,
from /home/mk/OpenCPN/OpenCPN/include/chartsymbols.h:28,
from /home/mk/OpenCPN/OpenCPN/src/chartsymbols.cpp:36:
/usr/include/wx-3.2/wx/matrix.h:44:35: error: expected initializer
before ‘:’ tokenFrom 03eca5af92d4a395efc65dd8a6e936e33293f5b8 Mon Sep 17 00:00:00 2001
From: Alec Leamas
Date: Mon, 21 Nov 2022 14:20:15 +0100
Subject: [PATCH] matrix.h: Patch attributes handling (wxwidgets#22790).
Bug: https://github.com/wxWidgets/wxWidgets/issues/22790
Forwarded: not-needed
---
defs.h | 21 +
matrix.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/defs.h b/defs.h
index e048cb7..d491939 100644
--- a/defs.h
+++ b/defs.h
@@ -169,6 +169,27 @@
#else /* !g++ */
# define wxSUPPRESS_GCC_PRIVATE_DTOR_WARNING(name)
#endif
+/*
+Some gcc versions choke on __has_cpp_attribute(gnu::visibility) due to the
+presence of the colon, but we only need this macro in C++ code, so just
+don't define it when using C.
+ */
+
+#ifdef __cplusplus
+
+/*
+Special macro used for the classes that are exported and deprecated.
+It exists because standard [[deprecated]] attribute can't be combined with
+legacy __attribute__((visibility)), but we can't use [[visibility]] instead
+of the latter because it can't be use in the same place in the declarations
+where we use WXDLLIMPEXP_CORE. So we define this special macro which uses
+the standard visibility attribute just where we can't do otherwise.
+
+Heavily simplified for wxWidgets and gcc -- Alec Leamas
+ */
+#define wxDEPRECATED_EXPORT_CORE(msg) \
+ __attribute__((visibility("default")))
+#endif
/*
Clang Support
diff --git a/matrix.h b/matrix.h
index d18a0d2..a3392b5 100644
--- a/matrix.h
+++ b/matrix.h
@@ -41,7 +41,8 @@ class
#ifndef WXBUILDING
wxDEPRECATED_MSG("use wxAffineMatrix2D instead")
#endif
-WXDLLIMPEXP_CORE wxTransformMatrix: public wxObject
+wxDEPRECATED_EXPORT_CORE("use wxAffineMatrix2D instead")
+wxTransformMatrix: public wxObject
{
public:
wxTransformMatrix();
--
2.30.2
Bug#1024853: RFS: wxsvg/2:1.5.24+dfsg-1 [RC] -- Development files for wxSVG
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name : wxsvg Version : 2:1.5.24+dfsg-1 Upstream contact : Alex Thuering * URL :http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs :https://salsa.debian.org/multimedia-team/wxsvg Section : libs The source builds the following binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG Further information onhttps://mentors.debian.net/package/wxsvg/ or using dget -xhttps://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.24+dfsg-1.dsc Changes since the last upload: wxsvg (2:1.5.24+dfsg-1) unstable; urgency=medium . * New upstream release * Relinked to wxWidgets 3.2 Closes: #1019765. * Drop patch for building against ffmpeg5. * Fix renamed tag in lintian overrides. * Fix d/copyright and an override, lintian warnings.
Bug#1022527: ddupdate: diff for NMU version 0.6.6-1.2
Hi again, On Sun, 13 Nov 2022 09:47:03 +0100 Alec Leamas wrote: Thanks for taking care of this! That said, could you please delay this a little longer so I can make a regular release instead, avoiding an in my eyes somewhat painful NMU? I have committed your patch upstream in your name [1], I hope it's ok. New release is pending on mentors [2] --alec [1] https://github.com/leamas/ddupdate/commit/a480bd9e5cdae [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024025
Bug#1024025: RFS: ddupdate/0.6.6-2 [RC] -- Tool updating DNS data for dynamic IP addresses
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "ddupdate": * Package name : ddupdate Version : 0.6.6-2 Upstream contact : https://github.com/leamas/ddupdate/issues * URL : https://github.com/leamas/ddupdate * License : Expat * Vcs : https://gitlab.com/leamas/ddupdate Section : net The source builds the following binary package: ddupdate - Tool updating DNS data for dynamic IP addresses More info at https://mentors.debian.net/package/ddupdate/ or using 'dget' with this command: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.6-2.dsc Changes since the last upload: ddupdate (0.6.6-2) unstable; urgency=medium . [Stefano Rivera] * New patch for bundled distutils in setuptools. Closes: #1022527 [Alec Leamas] * Move packaging to separate repo at gitlab This is a RC bugfix release on a straight-forward python package, nothing strange. On a sidenote, I would appreciate if someone who reviews and eventually uploads this package also perhaps could sponsor me so I could get package upload rights (have for some others). -- Alec Leamas
Bug#1022527: ddupdate: diff for NMU version 0.6.6-1.2
Hi Stefano, On Sun, 13 Nov 2022 10:17:11 +0200 Stefano Rivera wrote: Control: tags 1022527 + patch Control: tags 1022527 + pending Dear maintainer, I've prepared an NMU for ddupdate (versioned as 0.6.6-1.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. SR Thanks for taking care of this! That said, could you please delay this a little longer so I can make a regular release instead, avoiding an in my eyes somewhat painful NMU? Cheers! --alec
Bug#1019765: wxsvg: Please transition to wxwidgets3.2
On Wed, 14 Sep 2022 15:42:16 -0400 s...@techie.net wrote: Source: wxsvg Severity: normal Control: block 1019416 by -1 Hi, Please transition wxsvg from wxwidgets3.0 to wxwidgets3.2. wxsvg is basically a dependency of opencpn, I'm not aware of any other package depending on it. As such, the transition to using wxWidgets 3.2 is handled in the opencpn context as discussed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=101976; can we keep the discussion in that bug? --alec
Bug#1019769: opencpn: Please transition to wxwidgets3.2
On Wed, 26 Oct 2022 11:57:36 +0200 Alec Leamas wrote: > Please transition opencpn from wxwidgets3.0 to wxwidgets3.2. Indeed. For now, assuming that this is about the version in testing/Bookworm Opencpn has a plugin universe. For that reason, we cannot just update the existing version 5.6.2 to wxWidgets 3.2 since it would break the plugin ABI. The plan is to update the wxWidget version when packaging the upcoming version 5.8.0. This is slated for bookworm, and should be uploaded before Christmas. Any problems with this plan? --alec
Bug#1019769: opencpn: Please transition to wxwidgets3.2
On Wed, 14 Sep 2022 15:42:16 -0400 s...@techie.net wrote: so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. I assume you mean Bookworm rather that Bullseye since the latter is already released? --alec
Bug#907333: ITP: libnmea0183: C++ library for decoding NMEA0183 data
On Fri, 13 May 2022 10:58:00 +0200 Bastian Germann wrote: The fork does not exist any longer and opencpn has arrived with vendored nmea0183. Do you still want to package this? If not, please close the bug. No, this should not be packaged, the code on opencpn is too heavily modified
Bug#1014946: RFS: wxsvg/2:1.5.23+dfsg-2 [RC] -- Development files for wxSVG
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name: wxsvg Version : 2:1.5.23+dfsg-2 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs : https://salsa.debian.org/multimedia-team/wxsvg Section : libs The source builds the following binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG More info on https://mentors.debian.net/package/wxsvg/ or using dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.23+dfsg-2.dsc Changes since the last upload: wxsvg (2:1.5.23+dfsg-2) unstable; urgency=medium . * New patch for ffmpeg-5 FTBFS. Closes: #1004632. * d/control: Standards-version: 4.6.0 -> 4.6.1, no changes. Regards, -- Alec Leamas
Bug#1012274: Please don't use Recommends: lirc
Package: vdr Version: 2.6.0-1 Currently, vdr seems to have a Recommends dependency on lirc. As a consequence, lirc is pulled in automatically for users installing vdr. Historically, this has been the right choice. However, these days this does not work that well. One reason is that most users uses the kernel IR decoding that does not require lirc. Such users will then start a large server running as root for no purpose. Another aspect is that lirc in many situations requires manual configuration. This is basically OK, lirc is an extremely powerful tool aimed for power users. However, users which gets lirc as an dependency sometimes runs into troubles as described in [1]. I suggest that the current "Recommends: lirc" is replaced with a weaker "Suggests: lirc". This will avoid that lirc is installed as a dependency while still giving a hint it could be useful for power users. Regards --alec leamas [1] https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/1768291
Bug#1010905: RFS: lirc/0.10.1-7 [RC] -- Infra-red remote control support - daemons and utils
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lirc": * Package name: lirc Version : 0.10.1-7 Upstream Author : Alec Leamas * URL : https://sf.net/p/lirc * License : MIT, GPL-2.0+ * Vcs : https://gitlab.com/leamas/lirc Section : utils The source builds the following binary packages: lirc - Infra-red remote control support - daemons and utils lirc-doc - Infra-red remote control support - website and manual docs liblirc0 - Infra-red remote control support - Run-time libraries liblircclient0 - Transitional placeholder for obsoleted liblircclient0 liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev liblirc-dev - Infra-red remote control support - development files liblirc-client0 - infra-red remote control support - client library lirc-x - infra-red remote control support - X utilities More info on https://mentors.debian.net/package/lirc/ or using: dget -x https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.1-7.dsc Changes since the last upload: lirc (0.10.1-7) unstable; urgency=medium . * Add patch from Fedora for failing tests. Closes: #1009389 * Add patch avoiding build path in docs. Closes: #961954 Regards, -- Alec Leamas
Bug#1010865: RFS: opencpn/5.6.2+dfsg-1~bpo11+2 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo11+2 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, GPL-3+, wxWidgets, Expat or GPL-2+, SGI-B-1.1, GPL-3, Expat, SGI-B-2.0, LGPL-2+, public-domain, BSD-3-clause * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo11+2.dsc This is a pretty urgent bugfix release for the existing Bullseye backport. Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo11+2) bullseye-backports; urgency=medium . * Add patch fur unusable buildd version. Closes: #1010860 Regards, -- Alec Leamas
Bug#1010860: Wrong plugin compatibility setting
Package: opencpn Version: 5.6.2+dfsg-1~bpo11+1 The plugin compatibility version should be 11, but is actually buildd-unstable. This make plugins invisible. Upstream bug: https://github.com/OpenCPN/OpenCPN/discussions/26780
Bug#1010540: RFS: opencpn/5.6.2+dfsg-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo10+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds the following two packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo10+1.dsc Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo10+1) buster-backports-sloppy; urgency=medium . * Initial buster backport of 5.6.2+dfsg2. * Rebase and renumber patches. * Add 1.2M patch restoring bundled wxsvg library since system libwxsvg is not available on buster (handled by repacking in 5.6.0). Regards, -- Alec Leamas
Bug#1009701: opencpn: Wrong gtk linkage causes plugin incompatibility
Fixed in 5.6.0+dfsg0-1~bpo10+2
Bug#1010223: RFS: opencpn/5.6.2+dfsg-1~bpo11+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1~bpo11+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo11+1.dsc This is a backport to Bullseye. The sid version builds more or less out of the box, the delta is minimal. Changes since the last upload: opencpn (5.6.2+dfsg-1~bpo11+1) bullseye-backports; urgency=medium . * Initial bullseye backport of 5.6.2+dfsg-1 Regards, -- Alec Leamas
Bug#1010187: RFS: opencpn/5.6.2+dfsg-1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.2+dfsg-1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1.dsc This is a bugfix upstream release, basically without any new functionality. Changes since the last upload: opencpn (5.6.2+dfsg-1) unstable; urgency=medium . * New upstream release. * Remove upstream debian packaging in source tarball. * Add patch for wrong desktop filename (tracker.debian.org warning). * d/rules: Add explicit CMAKE_BUILD_TYPE setting (upstream discussion in https://github.com/OpenCPN/OpenCPN/issues/2612) * d/watch: dfsg1 -> dfsg (lintian warning) * d/control: Add missing -b branch to Vcs-Git: * d/control: Make opencpn-data Multi-arch: foreign (tracker.debian.org warning). * d/copyright: Remove unused GPL-2 license. Regards, -- Alec Leamas
Bug#1009723: RFS: opencpn/5.6.0+dfsg0-1~bpo10+2 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg0-1~bpo10+2 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-3+, public-domain, SGI-B-1.1, BSD-3-clause, GPL-3, GPL-2+, Expat or GPL-2+, LGPL-2+, wxWidgets, Expat, SGI-B-2.0 * Vcs : https://gitlab.com/leamas/opencpn Section : misc The source builds the two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info on https://mentors.debian.net/package/opencpn/ or using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg0-1~bpo10+2.dsc This is a bugfix update of an existing sloppy backport. Changes since the last upload: opencpn (5.6.0+dfsg0-1~bpo10+2) buster-backports-sloppy; urgency=medium . * Link to gtk2 instead of gtk3 to match available plugins. Closes: #1009701 * Add upstream patches to make it possible to define the target as a compile time constant. * Add patch to avoid getting multiple possible plugins to load besides the Debian version. Regards, -- Alec Leamas
Bug#1009701: opencpn: Wrong gtk linkage causes plugin incompatibility
Upstream bug: https://github.com/OpenCPN/OpenCPN/issues/2612
Bug#1009701: opencpn: Wrong gtk linkage causes plugin incompatibility
Package: opencpn Version: 5.6.0+dfsg0-1~bpo10+1 Severity: important Being a simple backport, current buster-sloppy version is linked against gtk3 exactly as more recent versions. However, plugins which are available for Buster are linked against gtk2. This causes bad crashes when trying to load any plugin using available GUI mechanisms. Trimming down the dependency list since the culprit is known. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster Architecture: armv7l Kernel: Linux 5.10.103-v7l+ (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages opencpn depends on: [...] ii libwxbase3.0-0v5 3.0.4+dfsg-8 ii libwxgtk-webview3.0-gtk3-0v5 3.0.4+dfsg-8 ii libwxgtk3.0-gtk3-0v5 3.0.4+dfsg-8 [...] ~
Bug#1004632: wxsvg: FTBFS with ffmpeg 5.0
On Sun, 30 Jan 2022 23:00:52 +0100 Sebastian Ramacher wrote: > wxsvg FTBFS using ffmpeg 5.0 from experimental Right. I suppose this is the start of a process leading to ffmpeg becomes part of regular bookworm. Questions: - Will ffmpeg 4.x go away when 5.0 arrives? - Is there any estimated ETA for the 5.0 arrival? cheers, --alec
Bug#1004134: RFS: ddupdate/0.6.6-1 -- Tool updating DNS data for dynamic IP addresses
On Sat, 22 Jan 2022 14:41:09 +0100 Bastian Germann wrote: > On Fri, 21 Jan 2022 16:08:31 +0100 Alec Leamas wrote: > > Changes since the last upload: > > > > ddupdate (0.6.6-1) unstable; urgency=medium > > . > > * New upstream bugfix release > > * Drop upstreamed FTBFS setup.py patch > > > > This is minor update to a standard python package, nothing complicated. > > Thanks for providing this update! > On 22/01/2022 16:12, Bastian Germann wrote: > Am 22.01.22 um 15:36 schrieb Debian FTP Masters: >> Version check failed: >> Your upload included the source package ddupdate, version 0.6.6-1, >> however unstable already has version 0.6.6-1. >> Uploads to unstable must have a higher version than present in unstable. > > Adam was faster than me... Thanks to all of you for uploading! Cheers! --alec
Bug#1004134: RFS: ddupdate/0.6.6-1 -- Tool updating DNS data for dynamic IP addresses
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate": * Package name: ddupdate Version : 0.6.6-1 Upstream Author : https://github.com/leamas/ddupdate/issues * URL : https://github.com/leamas/ddupdate * License : Expat * Vcs : https://github.com/leamas/ddupdate/tree/debian Section : net It builds one binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses More info at https://mentors.debian.net/package/ddupdate/ or using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.6-1.dsc Changes since the last upload: ddupdate (0.6.6-1) unstable; urgency=medium . * New upstream bugfix release * Drop upstreamed FTBFS setup.py patch This is minor update to a standard python package, nothing complicated. Regards, -- Alec Leamas
Bug#1003214: RFS: opencpn/5.6.0+dfsg0-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, On Thu, 06 Jan 2022 16:59:00 +0100 Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Alec, > if you dont remove it using Files-Excluded, you need to document libwxsvg's > copyright in d/copyright... > Indeed, good catch! I have uploaded a new build to mentors. Cheers! --alec
Bug#1003214: RFS: opencpn/5.6.0+dfsg0-1~bpo10+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg0-1~bpo10+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, public-domain, GPL-3+, SGI-B-1.1, SGI-B-2.0, Expat, GPL-3, LGPL-2+, Expat or GPL-2+, BSD-3-clause, wxWidgets * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds two binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ or using dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg0-1~bpo10+1.dsc Changes since last upload: opencpn (5.6.0+dfsg0-1~bpo10+1) buster-backports-sloppy; urgency=medium . * Rebuild for buster-backports-sloppy. * Update VCS urls and gbp.conf default branch * Downgrade debhelper compat, 13 -> 12 * Drop libwxsvg build dep * Don't strip libwxsvg in d/copyright, repack sources with bundled library in place. Use dfsg0 to make it precede dfsg1 in bullseye. Regards, -- Alec Leamas
Bug#1002992: sub...@bugs.debian.org
Made a new upload to mentors after syncing my git tree with salsa. Basically means that the VCS headers which was broken now should be OK --alec
Bug#1002992: sub...@bugs.debian.org
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name: wxsvg Version : 2:1.5.23+dfsg-1 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs : https://salsa.debian.org/multimedia-team/wxsvg Section : libs It builds those binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG This is a minor update triggered by a new upstream version. More info: https://mentors.debian.net/package/wxsvg/ or using dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.23+dfsg-1.dsc Changes since the last upload: wxsvg (2:1.5.23+dfsg-1) unstable; urgency=medium . * New upstream version * d/watch: dfsg.1 -> dfsg (lintian warning) * d/control: Allow builds against wxWidgets 3.1 * d/control: Standards-version: 4.5.0 -> 4.6.0, no changes. * Add patch for separate -latomic library causing sh4 build errors.
Bug#1002719: RFS: opencpn/5.6.0+dfsg1-1~bpo11+1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg1-1~bpo11+1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, public-domain, GPL-3+, SGI-B-1.1, SGI-B-2.0, Expat, GPL-3, LGPL-2+, Expat or GPL-2+, BSD-3-clause, wxWidgets * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds those binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) This is about backporting 5.6.0 which was recently accepted into sid. It's my first attempt on backporting, so all sorts of mistakes are possible. The backport checklist: - Package has a substantial user base. However, most of them are using the Ubuntu package sine the Debian packaging historically has been missing or outdated. - 5.6.o is a major update. - Package is accepted into sid and migrated to testing/Bookworm. - Package builds with a small delta (below). - I also did the work with the Sid version. More info: https://mentors.debian.net/package/opencpn/ or dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg1-1~bpo11+1.dsc Changes since the last upload: opencpn (5.6.0+dfsg1-1~bpo11+1) bullseye-backports; urgency=medium . * Rebuild for bullseye-backports. * Changes to Vcs-git in control and default branch in gbp.conf. Regards, -- Alec Leamas
Bug#1001494: RFS: opencpn/5.6.0+dfsg1-1 -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Bastian, Just a ping. Any chance we can push things forward here? Happy Xmas! --alec
Bug#1001494: RFS: opencpn/5.6.0+dfsg1-1 -- Open Source Chartplotter and Marine GPS Navigation Software
CC: to bug as well to keep discussion visible On 12/12/2021 11:16, Bastian Germann wrote: Copy to make sure you have received the remarks. d/changelog === Please remove the 5.2.4.210213gitcad0d456+dfsg1-1 entry. It was never uploaded to the archive. Done, finally d/copyright === There are four debian/opencpn* files listed. This does not make sense. Please list the source files, e.g. data/tcdata/harmonics-dwf-20210110-free.tcd instead of debian/opencpn-data/DEBIAN/md5sums with a line referring to usr/share/doc/opencpn-data/harmonics-dwf-20210110-free.tcd.gz. Having debian/opencpn-data/ files in d/copyright is of course not only wrong but stupid. These are generated and not part of the source package "ashamed". Why do these things show up in your new version? They are not in the 5.2.4+dfsg-1. Because I used cme to update the copyright which I suppose basically is fine. However, what I missed was to make at least a superficial review of the changes. Also, I obviously ran cme on a tree which wasn't clean, shouldn't do that. The core problem is that I just don't do these things often enough to not make simple mistakes like these. Control: tags -1 moreinfo Please untag moreinfo when you have provided a fixed version. Done, at least I hope so. Again, I'm no debian packaging wizard, for sure. Thanks for your patience! --alec
Bug#1001494: RFS: opencpn/5.6.0+dfsg1-1 -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "opencpn": * Package name: opencpn Version : 5.6.0+dfsg1-1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+, public-domain, GPL-3+, SGI-B-1.1, SGI-B-2.0, Expat, GPL-3, LGPL-2+, Expat or GPL-2+, GPL-2, BSD-3-clause, wxWidgets * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds those binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) More info: https://mentors.debian.net/package/opencpn/ Or using dget: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.0+dfsg1-1.dsc This is a maintenance release. Changes since the last upload: opencpn (5.6.0+dfsg1-1) unstable; urgency=medium . * New upstream release * Drop upstreamed patches * Update standards-version to 4.6.0, no changes. * Drop repck suffix, dfsg1 -> dfsg * Update compat-level to 13, drop override_dh_missing from rules. * Drop walk-around for #831870 using zip download, clean up d/rules and d/watch Regards, -- Alec Leamas
Bug#997793: RFS: libcxx-serial/1.2.1-5 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libcxx-serial": * Package name: libcxx-serial Version : 1.2.1-5 Upstream Author : wjww...@gmail.com * URL : http://wjwwood.io/serial/ * License : Expat, BSD-3-clause * Vcs : https://gitlab.com/leamas/cxx-serial Section : libs It builds two binary packages: libcxx-serial-dev - Cross-platform, Serial Port library written in C++ (devel) libcxx-serial1 - Cross-platform, Serial Port library written in C++ (runtime) More info at: https://mentors.debian.net/package/libcxx-serial/ or using dget -x https://mentors.debian.net/debian/pool/main/libc/libcxx-serial/libcxx-serial_1.2.1-5.dsc Changes since the last upload: libcxx-serial (1.2.1-5) unstable; urgency=medium . * Handle uninstalled cmake configuration files. Closes: #997732 This is simple, bugfix release. Regards, -- Alec Leamas
Bug#982837: wx-common: binaries installed in multiarch package
package: wxwidgets3.0 version: 3.0.5.1+dfsg-2 As heading says: The wx-common package installs the /usr/bin/wxrc binary which is an -- wx-common is a multi-arch package assumed to be installable in parallel for different arches. The error is indeed flagged as such by lintian. I see no reason to handle this before the upcoming upstream 3.2 release. I understand that this could have been filed against the wx-common package. Choosing the source package since I guess the solution is about updating d/control somehow.
Bug#973112: libcxx-serial: FTBFS: make[5]: *** No rule to make target 'tests/gmock/libgmock.a', needed by 'devel/lib/cxx-serial/cxx-serial-test'. Stop.
On Tue, 27 Oct 2020 18:06:31 +0100 Lucas Nussbaum wrote: > Source: libcxx-serial > Version: 1.2.1-3 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201027 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Ack, I can reproduce it. This might trigger a major update if I cannot find a simple solution. Back later
Bug#961954: lirc: Disable embedding of build path in documentation
On Sun, 31 May 2020 20:21:58 -0700 Vagrant Cascadian wrote: > The build path is embedded in the generated documentation, which breaks > reproducibility when built from a different path. Fixed in git repo, will not make a release for this issue only.
Bug#860300: lircmd does not work
On Wed, 28 Jun 2017 10:53:12 +0200 Alec Leamas wrote: > On Wed, 21 Jun 2017 09:44:28 +0200 Alec Leamas > wrote: > > This is tracked in upstream bug > https://sourceforge.net/p/lirc/tickets/295/ > > > > --alec > > > Fixed upstream and in experimental. Thanks for reporting and debugging! > And in 0.10.0, closing
Bug#890374: Aw: Re: bug in lirc - 'post' and 'pre' not sent
On Wed, 14 Feb 2018 14:02:55 +0100 Alec Leamas wrote: > > Best regards > > > > Andreas > > > Thanks for filing. That said, I'm moving this bug upstream to > https://sf.net/p/lirc/tickets/319/. In that bug I have also repeated my > reply, which basically requests some feedback from you. Let's keep > discussion in the upstream bug, it really belongs there. I honestly don't know what to do here. But in any case, this is not a packaging problem, it's an upstream one. Leaving bug open for now.
Bug#860551: fixed in lirc 0.10.0~rc3-1
This bug is reopened without any further information. I'm closing it again, assuming it was some kind of mistake. If not, please re-open and add some info.
Bug#872985: [Pkg-lirc-maint] Bug#872985: [lirc] postinst of lirc fails if systemd is not installed
On Wed, 30 Aug 2017 14:34:47 +0200 Alec Leamas wrote: > The package description for systemd-shim says: "This package emulates > the systemd function that are required to run the systemd helpers > without using the init service" > > So, this looks more like a systemd-shim bug to me. > > Thoughts? The state of sysV init scripts is basically "patches welcome". And since there is no patch, or even reply here I'm closing this bug. --alec
Bug#923397: known issue with upstream bug report
On Mon, 11 Mar 2019 09:28:03 +0100 =?UTF-8?Q?Tycho_L=c3=bcrsen?= wrote: > Hi, as the subject says, this is a known issue ( see > https://bugzilla.redhat.com/show_bug.cgi?id=1652992 ) > > and it has a upstream bugreport ( see > https://sourceforge.net/p/lirc/tickets/341/ ) > > Hope that helps. > > Regards, Tycho On current sid, using lirc 0.10.1-6.2 I cannot reproduce this, lirc-setup starts without problems. Closing --alec
Bug#872375: lirc: irrecord segfaults when recording a button
On Tue, 13 Feb 2018 21:54:19 +0100 Alec Leamas wrote: > > This message really says it all: using irrecord with the devinput > driver is a useless and dangerous idea. See my other replies in the bug > for more. > > This is bug is outdated and partly off-topic. Closing. That is not to say that irrecord works for all input devices -- it doesn't. It also occasionally segfaults, I have not been able to find the reason.
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
On 24/09/2020 10:34, Tobias Frost wrote: > Control: tags -1 moreinfo > Control: reopen -1 > > On Thu, Sep 24, 2020 at 09:29:58AM +0200, Alec Leamas wrote: >> Hi again, >> >> On 24/09/2020 09:07, Alec Leamas wrote: > (Looking at the -dev package: they use a quite common filename (serial.h) > without subdirectory in /usr/include. I wonder if there are collisions > in the archvie…) If not, it would be because other packages are sane. This one is certainly not in this sense. Needs to be fixed (see below) > - Typo in d/changelog: s/FTBS/FTBFS/ Fixed. That was actually no typo, for some reason I have always used FTBS although it's obviously wrong. > - Please add the patch I sent in #970712#39… /me wants back to Fedora, where the only way to change a package is a commit in the dist-git repo. NMUs and free-running patches, I miss them all. OTOH, now I have now learnt and it will never happen again. "cough" New package on mentors: #4, timestamp:2020-09-24 11:08 There is a need for a bigger rewrite: - Refactor the cmake patch(es) - Add a doc subpackage. - Don't install serial.h directly under /usr/include. Please feel free to file a bug or two; I'm on it anyway (although perhaps not exact now). Cheers! --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi again, On 23/09/2020 11:27, Alec Leamas wrote libcxx-serial_1.2.1-3 is uploaded to mentors, available Real Soon (tm). In haste, --alec Too much haste, new version uder way, need to wait for mentors to settle. Correct fix is available in my gitlab repo. In even more haste, --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi Gianfranco,
On 23/09/2020 10:59, Gianfranco Costamagna wrote:
Hello,
just FYI, the upload fails on i386
https://buildd.debian.org/status/fetch.php?pkg=libcxx-serial=i386=1.2.1-2=1600846376=0
Due to a difference between i686 and i386
The change in gst-omx might fix this problem
gst-omx (1.18.0-2) unstable; urgency=low
.
* debian/gst-omx-listcomponents.install and debian/rules:
Use ${DEB_HOST_GNU_TYPE} instead of ${DEB_HOST_MULTIARCH} to fix FTBFS
on i386.
HTH
libcxx-serial_1.2.1-3 is uploaded to mentors, available Real Soon (tm).
In haste,
--alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
On 22/09/2020 13:52, Tobias Frost wrote: > Uploading right after this mail with this cosmetic change: > > l-1.2.1_orig/debian/changelog libcxx-serial-1.2.1/debian/changelog > --- libcxx-serial-1.2.1_orig/debian/changelog 2020-09-22 13:46:47.366672711 > +0200 > +++ libcxx-serial-1.2.1/debian/changelog 2020-09-22 13:50:03.325964836 > +0200 > @@ -13,7 +13,6 @@ >* Fix lingering templates in d/watch. >* New local patches: > - Drop v8stdint.h header (above) > - - Make build verbose. >* Cherry-picked upstream bugfix patches: > - Fix SerialImpl constructor resource leak. > - Handle 500kpbs serial ports. > > > As always, thanks for your contributions! And thanks for your thoughtful review, uploading and not least fixing my last nitpicks! Cheers! --alec
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi again, On 22/09/2020 12:51, Alec Leamas wrote: > Cannot upload to mentors: > > $ dput -f mentors ../libcxx-serial_1.2.1-2_source.changes > Checking signature on .changes > gpg: ../libcxx-serial_1.2.1-2_source.changes: Valid signature from > 0A1DA7134E068B4C > Checking signature on .dsc > gpg: ../libcxx-serial_1.2.1-2.dsc: Valid signature from 0A1DA7134E068B4C > Uploading to mentors (via ftp to mentors.debian.net): > Uploading libcxx-serial_1.2.1-2.dsc: 553 Could not create file. > Leaving existing libcxx-serial_1.2.1-2.dsc on the server and continuing Some kind of transient error. A new upload is available, timestamp on mentors: 2020-09-22 11:08 (#4) Cheers! --alec
Bug#970712: tags 970712 - moreinfo
tags 970712 - moreinfo
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Hi, On 22/09/2020 11:47, Tobias Frost wrote: > Control: tags -1 moreinfo Cleared > On Tue, Sep 22, 2020 at 10:58:26AM +0200, Alec Leamas wrote: > > Hi Alec, > > To avoid confustion, I'm comparing the version in the archive (1.2.1-1.1) with > yours, in case you missed the NMU. Which is exactly what I did... > - d/changelog you need to include the changelog of the NMU in your > changelog. Done > - d/copyright: Can you add the upstream contact? Done > You probably also want to update the years on the debian section. Done > - d/control: you re-adding python-catkin-pkg as B-D. Is it needed? > (asking, as #943082 says no) Indeed. Dropped. > - d/rules: in the dh_override_auto_configure: you don't need to repeat > the buildsystem parameter. Done. > - (not required for upload) > not sure if you really need the 0007 patch; verbose builds should be > enabled automatically. (If not, you probably want to pass > -DCMAKE_VERBOSE_MAKEFILE=On the dh_override_auto_configure > (patches patching CMakeLists.txt will break on every upstream release, >in my experience. Or TL;DL: It's PITA). Silly one, this. Of course it should be done using a parameter to cmake rather than a patch. Fixed. I need to upstream the CMake changes, there is actually a lot. But it's a bit complicated, need to refactor the first patch into separate, manageable ones. OTOH, upstream doesn't seem to release that often. > For later (as this requires a trip though NEW), maybe you want to put > the doxygen documentation on a arch:all -doc package? Hm... I know I actually considered this. On Fedora, the separate -doc package is a nobrainer. However, I have understood that on Debian "too" small packages are not really welcome. Here, the docs are about 450K in 40 files. Is this enough for a package to not be too small? What is really "small" in this context? > Only minor changes required ;-) Good job! hmpf. Missing the NMU wasn't minor, for sure. "depressed" Cannot upload to mentors: $ dput -f mentors ../libcxx-serial_1.2.1-2_source.changes Checking signature on .changes gpg: ../libcxx-serial_1.2.1-2_source.changes: Valid signature from 0A1DA7134E068B4C Checking signature on .dsc gpg: ../libcxx-serial_1.2.1-2.dsc: Valid signature from 0A1DA7134E068B4C Uploading to mentors (via ftp to mentors.debian.net): Uploading libcxx-serial_1.2.1-2.dsc: 553 Could not create file. Leaving existing libcxx-serial_1.2.1-2.dsc on the server and continuing And now, what? "confused" Many thanks for reviewing! Cheers! --alec PS: As long as it is possible in any way, I'm avoiding the NEW queue. Have been waiting there more than a year... DS
Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "libcxx-serial": * Package name: libcxx-serial Version : 1.2.1-2 Upstream Author : William Woodall wjww...@gmail.com * URL : https://github.com/wjwwood/serial * License : Expat, BSD-3-clause * Vcs : https://gitlab.com/leamas/cxx-serial Section : libs It builds two binary packages: libcxx-serial1 - Cross-platform, Serial Port library written in C++ (runtime) libcxx-serial-dev - Cross-platform, Serial Port library written in C++ (devel) More info: https://mentors.debian.net/package/libcxx-serial/ Or, using dget: dget -x https://mentors.debian.net/debian/pool/main/libc/libcxx-serial/libcxx-serial_1.2.1-2.dsc Changes since the last upload: libcxx-serial (1.2.1-2) unstable; urgency=medium . * Drop v8stdint.h header (not used in Debian). Closes: #921697 * Update python-catkin-pkg BR to python3. * Standards-version -> 4.5.0, no changes. * Update dephelper-compat -> 12 * Set Rules-Requires-Root * Add d/upstream/metadata * Handle DEB_BUILD_OPTIONS when overriding test target. * Clean up test target in d/rules, * Simplify d/rules using --buildsystem=cmake. * Reorganize repo branches according to dep-14. * Fix lingering templates in d/watch. * New local patches: - Drop v8stdint.h header (above) - Make build verbose. * Cherry-picked upstream bugfix patches: - Fix SerialImpl constructor resource leak. - Handle 500kpbs serial ports. - Plug memory leak in exceptions. - Use MONOTONIC clock. See also separate question on local build paths in the debug info: https://lists.debian.org/debian-mentors/2020/09/msg00243.html Regards, --Alec Leamas
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Sun, 13 Sep 2020 15:27:24 +0200 Tobias Frost wrote: > On Sun, Sep 13, 2020 at 02:50:43PM +0200, Tobias Frost wrote: > > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > More stuff. Lintian this time. > > - Lintian overrides > Lintian overrides should only be used if Lintian is wrong, not to silence problems > (even if the problems are not actionable right now, like patches not yet forwarded) > So time to clean those up… > > As a bonus, after cleaning those will be fixed: > E: opencpn source: malformed-override Unknown tag testsuite-autopkgtest-missing in line 2 > P: opencpn source: renamed-tag send-patch => patch-not-forwarded-upstream in line 14 > > This override should not be using a wildcard, but exactly match the false postive only. > # False positive from translations. > spelling-error-in-binary usr/bin/opencpn * Done, as well as some general cleanup. Nothing about patches is overridden, things became so much easier after updating sid thus getting rid of what might have been multiple lintian bugs.Still overriding warnings about get-orig-source and doc files used in runtime. Personally, I find the comments used in the override files a nice way to document things which looks peculiar in the package. In the end it's a choice, I guess. > You should looking into setting up sbuild, pbuilder or some of that kind tools: > This will allow you to build in a clean enviornment without the need to have I'm using cowbuilder. But then again, it must also be updated. I'm probably damaged by my Fedora roots, where corresponding tools just sort of works. Need to learn. Uploading a new version. Timestamp at mentors: 2020-09-14 07:53 Cheers! --alec
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi, On Sun, 13 Sep 2020 15:27:24 +0200 Tobias Frost wrote: > On Sun, Sep 13, 2020 at 02:50:43PM +0200, Tobias Frost wrote: > > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > > So far for now… > > More stuff. Lintian this time. > > - Lintian overrides > Lintian overrides should only be used if Lintian is wrong, not to silence > problems > (even if the problems are not actionable right now, like patches not yet > forwarded) > So time to clean those up… What does "being wrong" mean in this context? Just false positives? Or also situations like the get-orig-source or "there is no checksums"? > As a bonus, after cleaning those will be fixed: > E: opencpn source: malformed-override Unknown tag > testsuite-autopkgtest-missing in line 2 I have been a too lazy human being and not not updated my sid host. After doing so I see the same messages as you. This helps, but see my question above. Cheers! --alec
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi, On Sun, 13 Sep 2020 15:27:24 +0200 Tobias Frost wrote: > On Sun, Sep 13, 2020 at 02:50:43PM +0200, Tobias Frost wrote: > > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > Ah, regarding my remark for NSIS.template.in: > After thinking about it: This is probably an upstream bug… CMake does > out-of-tree builds > and therefore one should not have the need to modify a file in-tree. (Ok for > this RFS, Indeed. Filed upstream bug https://github.com/OpenCPN/OpenCPN/issues/2044. Thanks! Cheers! --alec
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On 13/09/2020 14:50, Tobias Frost wrote: > On Sun, Sep 13, 2020 at 01:23:41PM +0200, Alec Leamas wrote: > > (snipping stuff that is done or settled … Its getting a long mail) > > (regarding the transitinal package and Replace/Breaks versioning) >> OK, will do (unless not done in a MR)> > MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/2) Applied. > For the readers: > - Replace/Break on << 4.8.8~. The ~ ensures that it matches everything that > had > 4.8.8 in it. (where the change happened) > - The transistional package will no longer be built. > > Note that I did not add d/changelog entries; left to you; no need to mention > me. > >> d/rules: (...) > MR sent. (https://gitlab.com/leamas/opencpn/-/merge_requests/1) Applied, but... this was an insane can of worms. As you noted, basically everything under doc/opencpn was removed. However, this was a plain bug. I have patched the installation files to install the required stuff. > The MR tidies up d/rules (removing the need for override_dh_auto_install) by > replacing > the logic with declratavie syntax: > - installing the manpages not via dh_install but with dh_installman. > - using dh_link to build the symlinks to the GPL licenses needed by the > programm. > - be more accurate in d/*install what to install > - use the possiblity to move files around in d/*install > - specify the files not to be installed. (d/not-installed) Thanks for this crash-course in the possibilities using dh_install and friends! Much appreciated. > Regarding the licenses symlinked: Are they acutally used. grep did find > nothing for me… > In this case, the file d/opencpn.links should be removed The license files are linked for formal reasons besides license.txt which is used in runtime (the About dialog). > Please review the changes to the (not-)installed (especially > d/opencpn-dat.ionstall as > you know whether the programm expect those. (After a simply grep I assumed it > does not.) Done, see above. > Please note that there will be an build error I left intentionally: > It does not install CoC-909_2013-InlandECDIS_20170308s.pdf because this file > is a file > - without source (and so also not built from source) > - unclear license (I don't think that is under a DFSG license… Is it > distributeable?) > atm it looks like it needs to be removed via Files-Excluded. Indeed. File dropped, we have a new tag 5.2.00+dfsg1 + a new build patch. > Also no d/changelog entries; left for you to be done… (I do _not_ need credit > for those!) Well, if you don't want credits in the changelog please accept them here: thanks for some really, really useful input which I think has made me a better packager. A new version is uploaded on mentors. Cheers! --alec PS: Every time I upload a new version I get a mail from mentors with a subject line like "opencpn_5.2.0+dfsg1-1: ACCEPTED into unstable". This is definitely wrong, and should perhaps be filed somewhere (?) DS
Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, Here we go: On 12/09/2020 16:28, Tobias Frost wrote: > Control: owner -1 ! > > Two remarks: > - d/changelog You could bumpt the timestamp on the changelog from time to > time, though > ;-): dch -r "" is a nice trick ;-) Indeed, thanks! Tried now, will need to to it again. > - (nitpick) d/changelog Please be consitent on the Closes: Stancas > - Line 2 says Closes: 948702, line 3 says Closes #962213. Please use > either with '#' or without '#' … just for my eyes to relief… Fixed > d/control: > - you can drop opencpn-plugins; I guess this is for people who > installed before Debian had the package. Not really. It's about an old version which seemingly has existed in Debian about 2015 (I find the traces in the salsa git log for opencpn. Still drop? (leaving for now) > OK to keep the > Break/Replace until opencpn has been released with a Debian stable > release. (I cant check if the version constraint is right, because "<<" > is strictly earlier, that means 4.8.6~20180801.8d20a06+dfsg.1 was the > first version with an empty plugins package?; It would be safe to us << > 4.8.8~, though. Update: #917561 seems to indicate that this change was > actually introduced in 4.8.8+dsfg.1-1 -- so the above restriction would > be too old…) Again, this is (was?) about the traces I found in the salsa log. Shall we drop the Breaks/Replaces? Or update to the correct value << 5.0.0+dfsg? Certainly happy to drop, these things are messy and nice to get rid of. Your thoughts? (leaving for now) > - is wx3.0-i18n really required to run opencpn? Maybe Recommends is > enough? Recommends: is indeed enough. Fixed (*how* did you catch that one? Tooling? Experience?) > - opencpn recommends binutils. Can you say why, its a bit unusual for > non-development applications. It's about some built-in crash-reporting stuff which uses addr2line. > d/opencpn.install and d/rules… > There are some issues, I'll follow up later on those, > probably with a patch/MR (hint to update salsa, see below). OK. > d/clean > - NSIS.template.in is appearantly recreated during build, it should be > deleted via d/clean. (Then debuild twice will work, too) Indeed, thanks! Fixed. > d/rules: > In the override > - instead of making the links to the licenses, you could use > dh_links(1) Problems: $ man dh_links No manual entry for dh_links $ apt-cache search dh_links $ Google doesn't give anything meaningful either. > multiarch: > - the plugin *.so are not installed in an multiarch aware path. This is actually on purpose. I read the multiarch docs like multiarch paths are only applicable to libraries i. e., there are no multiarch applications. opencpn is an application, we cannot have multiple architectures in $PATH, and hence the plugins which are an integrated part of the application lives in /usr/lib/opencpn rather than the multiarch path. Or? > nitpicks: > - theres a trailing space in README.source (use wrap-and-sort(1) ;-)) Fixed (using vim...) > Wishlist: > (wishlist items related to README.Debian) > - I see docs are not packaged for privacy reasons. Could they be when > the docs being patches (not an unseen in Debian)? > (e.g I hate it if the docs are not matching the version I have > installed, as often the docs for the newer version won't apply well > enough) I don't follow you here... This should really be fixed upstream, by an easy-to-use option for users to download the docs (the download is available upstream). However, I don't think it's reasonable to fix it downstream. Basic problem is that the docs are generated using a wiki system which just havn't (and cannot have) sources which are public. Please don't ask me why this system is used... > - (as you are upstream-involved, this is probably easy to fix on your > side:) The plugin code could also look into alternative directories… It actually already does. It's perfectly possible to create .deb-packaged plugins, and there are plenty around -- this is the way plugins have been packaged for Debian/ubuntu since long. In the upstream bugs (which you seem to have skimmed to in some cases?), these are referred to as legacy plugins. > - The /usr/share/ hierachicy is reserved for packaged stuff, so > encouraging users to copy stuff there is a bit meeeh; it can > create problems when e.g a new package provides this file. > - So probably /usr/local/… or /opt/… would be a better > recommendation. > - Additionally, when users should be able to install plugins without > being root, something like $HOME/.local/… (not sure if this is > consenus in Debian, though) There are just so many problem here. In Fedora, packages are explicitly forbidden to write anything under /home for good reasons. I don't think Debian is or should be different. But, see above, .deb packages work out of the box. I have pushed a new version to mentors, with fixes above. The patches and d/copyright are fixed to
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Thu, 10 Sep 2020 05:12:34 -0400 The Wanderer wrote: > On 2020-09-10 at 01:45, Tobias Frost wrote: > > > On Wed, Sep 09, 2020 at 10:53:37PM +0200, Alec Leamas wrote: > > > > Well, actually, all those lines probably should be removed: > > debian/changelog is intended to record changes to the packaging part > > only, it is not to record changes made upstream; more generally: Only > > stuff that changes files in the debian directory should be mentioned > > in d/changelog. (See > > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog > > for some better/more accurate wording in the Policy) > > I'm not sure I read that section as meaning that. Could you point more > specifically to the exact wording there which you understand as > reflecting this rule? > > Regardless, I'm fairly sure there are exceptions to this in practice. > For example, if a new upstream release includes a change which closes an > open Debian bug report or fixes a particular CVE, a notation in the > changelog recording that fact seems to be de rigueur, and in fact as I > understand matters the tooling recognizes and parses notes such as > "Closes: #123456" or "CVE-1000-123-1234" to auto-close the given bug > report or to mark a newly-packaged version as unaffected by the given > CVE. > > For that matter, look at the Linux kernel packages > (linux-image-VERSION-ARCH, among others). They don't seem to ship a > changelog.Debian.gz, but the changelog.gz which they do ship seems to be > This seems to be a Deep Philosophical Discussion between Debian Developers. I should thus basically stay quiet, but I feel the discussion is a little bit off in this case. I'm working tight with upstream, so the upstream/downstream boundaries are a little obscured. The references was a result (all cases) of a workflow like - Packaging, I find a bug and make a patch in d/patches - The bug is filed upstream. - The patch is converted to an upstream PR. - The PR is merged on upstream master branch, to be included in next release. - The patch in d/patches is updated with DEP-5 info (yes, did that). - The line in the changelog is (was) updated with the upstream bug #. So, these references stem from my downstream work. They do (did) *not* reference anything in the release tag, only changes after that. Having these lines, with or without upstream references is no big thing, at least not for me. Just trying to clarify Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, On Thu, 10 Sep 2020 08:06:10 +0200 Tobias Frost wrote: > On Wed, Sep 09, 2020 at 11:08:53PM +0200, Alec Leamas wrote: > > On Wed, 9 Sep 2020 22:53:37 +0200 Alec Leamas wrote: > > Dammit. There's still one copyright for src/gshhs.cpp to fix. I'm on it, > > but holding next upload until I hear from you. > > PS: Hints to make your life easier: > - there are tools that might help https://wiki.debian.org/CopyrightReviewTools > (probably you know already, as some lines look tool-generated ;-) Yes, as Fedora packager I've been using licensecheck since too many years. And once you have been able to set up cme it's a great tool. However, current fixes is basically wrapping up after some cme wrongdoing. To maintain a copyright file like this manually would be , well, interesting... [snip] > Hope that helps a bit. It does (thanks!), taking it with me to next release. However, keeping delta small at this point. Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Thu, 10 Sep 2020 07:46:32 +0200 Tobias Frost wrote: > On Wed, Sep 09, 2020 at 11:08:53PM +0200, Alec Leamas wrote: > > On Wed, 9 Sep 2020 22:53:37 +0200 Alec Leamas wrote: > just go ahead and update the package on mentors. Done. --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Wed, 9 Sep 2020 18:44:17 +0200 Tobias Frost wrote: > On Wed, Sep 09, 2020 at 07:39:38AM +0200, Alec Leamas wrote: > > > Now, this should not really change anything. OpenCPN is perfectly usable > > without any plugins, and builds fine on all Debian core platforms (sic!) > > Sounds good ;-) > > (And it can happen that someone is showing up later and packaging the > plugins for Debian, > who knows that in a volunteer project :-D) > > When your package is ready, don't forget to remove the moreinfo tag! Sorry, I missed your reply and sent two messages out of sync. I have removed the moreinfo tag (that interface *is* arcane!) As you should be aware, there is a new upload with an error I spotted. Can you see anything else, or should I just fix that and make a new round? Cheers! --alec PS: My Englisch is not what it should be, and if you have a better proposal for the message in the 0008-... patch I would certainly prefer to use that... DS
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Wed, 9 Sep 2020 22:53:37 +0200 Alec Leamas wrote: > Hi, > > A new version is uploaded to mentors. Time to reset the history. Changes > since last round: ... Dammit. There's still one copyright for src/gshhs.cpp to fix. I'm on it, but holding next upload until I hear from you. "Annoyed" --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi, A new version is uploaded to mentors. Time to reset the history. Changes since last round: - New warning dialog for downloading binary plugin content (patch). - Spelling error fixed - Removed references to upstream bugs. I think it's a pity, the references linked patches in d/patches to upstream bugs. - Fixed the d/copyright mess. - Left compat level at 12 according to discussion. Thoughts? Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 21:01:47 +0200 Tobias Frost wrote: > On Tue, Sep 08, 2020 at 08:10:48PM +0200, Alec Leamas wrote: >> On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: >> All this said: do you think it's motivated to make such a patch? > > I guess. (Again being Debianite ;-)) OK, will do. Being Debianite is your role here, right?! > Debianites are generally very sensitive about privacy, so any feature that > "calls home"* feature is usually frowned upon; And this is kind of a side > effect of a plugin manager that pulls stuff from the Internet… I see the arguments and concur. >> The plugins uses a CI build chain which supports the core architectures. >> Plugins are built and uploaded automatically. They become available to >> users when url and metadata is included in the catalog -- this is >> semi-automatic process ending up in a PR against the catalog. > > For Debian core architecures means > https://wiki.debian.org/DebianBuster#Architectures Just after pushing the Send button I knew that referring to Debian core architectures was wrong. Our users basically either uses a PC or some raspberry device; we support x86_64 and armhf when it comes to plugins. Now, this should not really change anything. OpenCPN is perfectly usable without any plugins, and builds fine on all Debian core platforms (sic!) Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: > > Not really. Do you think a patch is motivated? If so, for each and every > > plugin, or just for the first one? > > I'm not sure how plugins are installed. If there is an UI, the warning > could be presented in that gui. The basic workflow is similar to the browsers: User sees a list of possible plugins, points to plugin to install, it's downloaded and installed. It is certainly possible to patch this with a dialog showing some info, for example for the first installed plugin. I know the code good enough to make such a patch. All this said: do you think it's motivated to make such a patch? > I meant with Man in the Middle: There would be many possiblities for attacks… > If they are not protected by e.g a checksum, Malice one could > replace them, either in the repo or in transit. There is no gurantee > that binaries match the sources, as well, if not build in trusted enviorments > or somehow signed. … Checksum/signing is definitely on the agenda, the plugin system is still not mature. That said, as of today I think an attack needs to hijack either a github url (for the catalog) or some url on the cloudsmith deployment server. While certainly possible, it's probably not trivial To be honest, this is probably not the biggest attack surface on opencpn > "tight control upstream" somehow sounds that you control what plugins > can be installed. Just to make sure that we cover all those freedoms > we care about: I can have my own plugin installed, right? Yes, using an import function any plugin can be installed from disk. > OK, maybe, I'm not a user, so I can't tell. > However, you don't likely need _all_ plugins packaged… Focusing on the other aspect: the workflow (think of the browser's plugin systems) is really hard to implement when installation requires root privileges. Thinking about it, it might be possible to install from a .deb package, basically "downloading" from /usr/lib instead of an url. Might be worth an upstream bug. Not sure how much user-value this would add, though. Will file upstream bug. > Packaged plugins have advantages too, because > the packaging system can be your friend: We have had these discussions in depth. Also, as you might noticed, I'm not completely new to packaging. Yes, they have advantages. But in the opencpn context the cons weighs more. It's the combination of user experience, the need to install as a regular user, multiple linux distros and administrative work. It's certainly not a binary black and white decision. But, it is a decision. > How are you planning to support all the architecures Debian supports? The plugins uses a CI build chain which supports the core architectures. Plugins are built and uploaded automatically. They become available to users when url and metadata is included in the catalog -- this is semi-automatic process ending up in a PR against the catalog. > Welcome, and sorry for being too Debianite ;-) No need for apologies, discussions are always good. If I required an apology for these remarks I should probably not be in this business...:) As a result I will file two upstream bugs. And perhaps make a patch, if you deem it motivated. All good things. > Your plugin approach is not how we usually do things here… I know. But still not unheard of, the browsers comes to mind. Now, I need to do some work. Will unfortunately not happen today, need to prepare for work tomorrow. Cheers! --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, Thanks for taking some time for this! On 08/09/2020 16:29, Tobias Frost wrote: > a short review: > > * New upstream release including plugin downloader. Closes: 948702 > > It is a privacy violation to download stuff. Do you inform your user about it? Not really. Do you think a patch is motivated? If so, for each and every plugin, or just for the first one? > Are the downloads somehow validated that it won't execute malicious / (MITM) > modified code? I'm fairly active upstream where these plugins are created. They all live on github, and the sources are available. The actual list of downloadable plugins (the plugin catalog) is kept under tight control upstream. > (It would be better if plugins of relevance would be packaged.) It's just not feasible. There are some 20 plugins, and just the administrative work is IMHO prohibitive. Also, the user experience is built around a workflow which does not fly using packaged plugins. > Consistency: in other changelog entries you write a #bugnumber, here only > bugnumer… > > * Add two plugin compatiblity patches (#1997). The lower numbers are upstream bugs. Sort of obvious, but only for me... Should the notation opencpn#1997 work? > Spelling error: > W: opencpn-plugins: spelling-error-in-changelog compatiblity compatibility Agreed, will fix > - d/copyright has some todos: "blushes" Will fix. > - compat-level is still at 12. Actually on purpose to make ubuntu backports somewhat easier. I could certainly upgrade if you feel that this is the correct decision. Sending this reply now so I hopefully can get some more input before doing real work. Again: thanks for reviewing! Cheers! --alec
Bug#962213: package ftbfs on arm64 and armhf
On Mon, 20 Jul 2020 12:38:36 +0200 Alec Leamas wrote: > I have not been able to test the arm builds, taking your word that > lindrm-dev should fix it. ubuntu test builds at https://launchpad.net/~leamas-alec/+archive/ubuntu/opencpn/+sourcepub/11570928/+listing-archive-extra The package builds ok on armhf and arm64. Now, the question is just about a reviewer... --alec
Bug#962213: package ftbfs on arm64 and armhf
On Thu, 4 Jun 2020 17:24:54 +0200 Matthias Klose wrote: > The package ftbfs on arm64 and armhf, trying to link with -ldrm. Apparently > libdrm-dev is an implicit b-d for x86 targets, but used explicitly. Fixed by > b-d on libdrm-dev everywhere. Thanks for a very nice bug report! Submitted an update on mentors at https://mentors.debian.net/package/opencpn. We'll see if/when someone has time to review. I have not been able to test the arm builds, taking your word that lindrm-dev should fix it. --alec
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "opencpn" * Package name: opencpn Version : 5.2.0+dfsg-1 Upstream Author : Dave S. Register * URL : https://opencpn.org * License : GPL-2+ * Vcs : https://gitlab.com/leamas/opencpn Section : misc It builds those binary packages: opencpn - Open Source Chartplotter and Marine GPS Navigation Software opencpn-data - Open Source Chartplotter and Marine GPS Navigation Software (data) opencpn-plugins - Open Source Chartplotter and Marine GPS Navigation Software (transition) To access further information about this package see https://mentors.debian.net/package/opencpn Alternatively, one can download the package with dget: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.2.0+dfsg-1.dsc Changes since the last upload: * New upstream release * Closes: #962213 * Update debian/copyright due to new upstream source layout. * Bump Standards-Version to 4.5.0, no changes. * Drop upstreamed patches. Regards, -- Alec Leamas
Bug#962714: RFS: ddupdate/0.6.5-1 -- Tool updating DNS data for dynamic IP addresses
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.5-1 Upstream Author : https://github.com/leamas/ddupdate/issues * URL : https://github.com/leamas/ddupdate * License : Expat * Vcs : https://github.com/leamas/ddupdate/tree/debian Section : net It builds the single, standard python package: ddupdate - Tool updating DNS data for dynamic IP addresses This is a bugfix upstream release. More info is available at https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.5-1.dsc Changes since the last upload: * New upstream release. * Bump debhelper from old 11 to 12. * Set debhelper-compat version in Build-Depends. * Set field Upstream-Contact in debian/copyright. * Set upstream metadata fields: Bug-Submit, Repository. * Remove obsolete fields Contact, Name from debian/upstream/metadata (already present in machine-readable debian/copyright). * Update standards version to 4.5.0, no changes needed. * Fix error running ddupdate-config (#41) * New plugin domains.google.com * Multiple python 3.9 fixes. Regards, -- Alec Leamas
Bug#948702: opencpn: Opencpn package is incomplete, adding external plugins is blocked
On Sat, 22 Feb 2020 21:14:27 +0100 Alec Leamas wrote: > On Sun, 12 Jan 2020 11:37:30 +0100 Huub Reuver > wrote: > > > > > > A minimal configuration for opencpn includes at least the following > > plugins: > > - opencpn-plugin-objsearch > > - oesenc-pi > > - opencpn-plugin-draw > > > > I need charts, I need to notate and I need to find unknown locations. > > Without these opencpn is plainly useless. > > > > Those plugin packages are not available from Debian. > > First problem is gshhs dependency (there might be more). > > Is this a static, package dependency? I cannot reproduce any such > problems on sid using: OTOH, plugins does not work since they are linked against gtk2; opencpn is linked against gtk3. The net result is the same: the solution is the upstream plugin installer, under way but not ready as of now. --alec
Bug#948702: opencpn: Opencpn package is incomplete, adding external plugins is blocked
On Sun, 12 Jan 2020 11:37:30 +0100 Huub Reuver wrote: > > > A minimal configuration for opencpn includes at least the following > plugins: > - opencpn-plugin-objsearch > - oesenc-pi > - opencpn-plugin-draw > > I need charts, I need to notate and I need to find unknown locations. > Without these opencpn is plainly useless. > > Those plugin packages are not available from Debian. > First problem is gshhs dependency (there might be more). Is this a static, package dependency? I cannot reproduce any such problems on sid using: $ sudo apt install opencpn $ sudo apt install oesenc-pi opencpn-plugin-draw \ opencpn-plugin-objsearch opencpn-sglock-amd64 and a ppa line in sources.list like: deb [trusted=yes] http://ppa.launchpad.net/opencpn/opencpn/ubuntu \ bionic main So, could you please expand a little on the problem? --alec
Bug#948702: opencpn: Opencpn package is incomplete, adding external plugins is blocked
On Sun, 12 Jan 2020 11:37:30 +0100 Huub Reuver wrote: > Package: opencpn > Version: 5.0.0+dfsg-1 > Severity: important > The need to use plugins is obvious, and I agree that the current package is incomplete in this sense. We are currently addressing this upstream by implementing a plugin downloader/installer similar to e. g., the browsers. Once this is completed plugins will be available without being packaged. For this reason I don't plan to package any plugins for Debian but rather make them available in the new installer. That said, this will take some time and if someone steps up and packages plugins it would of course be nice. Also, most plugins are possible to rebuild from source and be used that way. --alec
Bug#946115: uninstallable deps in sid
Package: libwxgtk3.0-dev Version: 3.0.4+dfsg-14 Trying to install said package I get the following error (also tried in a clean chroot): # apt install libwxgtk3.0-dev Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libwxgtk3.0-dev : Depends: wx3.0-headers (= 3.0.4+dfsg-14) but 3.0.4+dfsg-15 is to be installed Depends: libwxbase3.0-dev (= 3.0.4+dfsg-14) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Regards, --alec leamas
Bug#931582: RFS: ddupdate/0.6.4-1
package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" Package name: ddupdate Version : 0.6.4-1 Upstream Author : Alec Leamas leamas.alecgmail.com URL : https://github.com/leamas/ddupdate License : MIT It builds the single binary package: ddupdate - Tool updating DNS data for dynamic IP addresses More info: https://mentors.debian.net/package/ddupdate or: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.4-1.dsc Changes since the last upload: ddupdate (0.6.4-1) sid; urgency=medium * New upstream release * Drop global systemd/system units in favor of systemd/user ones. Regards, Alec Leamas
Bug#930485: A patch for LIRC with kernel 4.19 and gpio-ir
On 03/07/2019 11:52, Gianfranco Costamagna wrote: Hello Takashi, I'm happy to upload if Alec (upstream) is willing to accept the patch! thanks for the nice contribution! I'm on holidays. When back, I think this patch belongs to upstream. I see no problem making a temporary upload with the patch applied. --alec
Bug#930461: RFS: ddupdate/0.6.3-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.3-1 Upstream Author : Alec leamas * URL : https://github.com/leamas/ddupdate * License : MIT Section : net It builds those binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses To access further information about this package, please visit: https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.3-1.dsc More info: https://github.com/leamas/ddupdate Changes since the last upload: ddupdate (0.6.3-1) sid; urgency=medium * New upstream release * Bump Standards-Version -- Alec Leamas
Bug#927062: ddupdate: autoupdate shouldn't be systemd-only
On 14/04/2019 21:22, Adam Borowski wrote: > On Sun, Apr 14, 2019 at 08:02:45PM +0200, Alec Leamas wrote: >> No. ddupdate uses systemd --user to setup and run the service without >> root permissions. So it's not comparable in this respect. > > It is called by the main blob itself, which runs as root, and sheds > permissions only to execute user services. Indeed. Stili, ddupfdate users can setuo and run their service without root permissions; IIRC cron et. el. does not offer this option. >>> You have two timers: one every 1h (the usual cron way), and another 2min >>> after boot. What's the point of the second if you already have an oneshot >>> service? Because it's very likely you have a new address after boot which need to be registered > But today, any consumer ISP at any of three places I have non-hosted > machines at doesn't even support inbound IPv4 anymore, making tunnels > the way to go for me. Well, that's you. Other users have inbound connections for various reasons. > A "must" requirement of the policy: > §9.11: > # [...] any package integrating with other init systems > # must also be backwards-compatible with sysvinit by providing a SysV- > # style init script with the same name as and equivalent functionality > # to any init-specific job, as this is the only start-up configuration > # method guaranteed to be supported by all init implementations. It's interesting -- but it does not take the fact that systemd is the default init system into account (per TC decision etc, you know this better than me I guess). The Debian wiki [1] tells us: # Since jessie, only systemd is fully supported; sysvinit is mostly # supported, but Debian packages are not required to provide sysvinit # start scripts. I will not take part in any systemd war here. Given the complete context, I think this is an RFE. --alec [1] https://wiki.debian.org/Init
Bug#927062: ddupdate: autoupdate shouldn't be systemd-only
Hi again, one more thing: On 14/04/2019 20:02, Alec Leamas wrote: > > Hi again, > [lot's of stuff] BTW: Given that the systemd stuff is part of the upstream package, on what grounds could you state that "autoupdate shouldn't be systemd-only"? Is there a Debian policy or something similar I have missed? TL;DR Isn't this a plain RFE? --alec
Bug#927062: ddupdate: autoupdate shouldn't be systemd-only
Hi again, On 14/04/2019 18:49, Adam Borowski wrote: > On Sun, Apr 14, 2019 at 05:20:08PM +0200, Alec Leamas wrote: >> On 14/04/2019 16:22, Adam Borowski wrote: >>> Hi! >>> The auto-update functionality is for some reason systemd only, despite not >>> actually using any systemd features. This makes it broken on any other >>> init/rc system for no gain. >>> >>> Could you please convert the .service/.timer to a init script and/or cron >>> job? >>> >> Anything is possible but... in this case ddupdate installs as a user program >> without anything running as root. Things like cron or init scripts are >> requires root permissions > > It's same as for systemd, which also runs as root -- only the syntax is > different. There's "runuser"; on a default install exim4 and popcon use it. No. ddupdate uses systemd --user to setup and run the service without root permissions. So it's not comparable in this respect. >> And, cron jobs are nowhere as flexible as systemd timers. > > You have two timers: one every 1h (the usual cron way), and another 2min > after boot. What's the point of the second if you already have an oneshot > service? It's about having a dynamic (e. g., dhcp) address which could change anytime. That's why services like this kind periodically checks if the address has changed and updates the involved DNS entry if so. >> OTOH, it would of course be possible to add alternative solutions like cron >> jobs to the package. This would requires patches to ddupdate-config, but >> should otherwise be trivial. But to be honest, I'm more in a "patches >> welcome" state on this -- I'm just not motivated to make such fixes myself. > > I don't use ddupdate myself anymore (I don't even remember if I used > ddupdate or one of the alternatives), thus it might be more for an actual > user. You have probably never used it then, it's a pretty new tool. You might, however, have used ddclient which is sort of similar (and widespread). > thus it might be more for an actual user. Agreed.
Bug#927062: ddupdate: autoupdate shouldn't be systemd-only
Hi Adam, On 14/04/2019 16:22, Adam Borowski wrote: Package: ddupdate Version: 0.6.2-1 Severity: normal Hi! The auto-update functionality is for some reason systemd only, despite not actually using any systemd features. This makes it broken on any other init/rc system for no gain. Could you please convert the .service/.timer to a init script and/or cron job? Anything is possible but... in this case ddupdate installs as a user program without anything running as root. Things like cron or init scripts are requires root permissions, which IMHO is bad enough to not convert current timer etc. And, cron jobs are nowhere as flexible as systemd timers. OTOH, it would of course be possible to add alternative solutions like cron jobs to the package. This would requires patches to ddupdate-config, but should otherwise be trivial. But to be honest, I'm more in a "patches welcome" state on this -- I'm just not motivated to make such fixes myself. --alec
Bug#926715: RFS: ddupdate/0.6.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "ddupdate" * Package name: ddupdate Version : 0.6.2-1 Upstream Author : Alec Leamas * URL : https://github.com/leamas/ddupdate * License : Expat Section : net It builds those binary packages: ddupdate - Tool updating DNS data for dynamic IP addresses For more information on this package see https://mentors.debian.net/package/ddupdate Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/d/ddupdate/ddupdate_0.6.2-1.dsc More information about ddupdate: https://github.com/leamas/ddupdate Changes since the last upload: * New upstream release. Regards, -- Alec Leamas
Bug#921697: libcxx-serial-dev: /usr/include/v8stdint.h is already provided by libv8-dev
On 08/02/19 02:01, Andreas Beckmann wrote: > Package: libcxx-serial-dev > Version: 1.2.1-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files. > > trying to overwrite '/usr/include/v8stdint.h', which is > also in package libv8-dev Thanks, good catch! Will look into it. Cheers! --alec
Bug#917531: ITP: libcxx-serial: Cross-platform c++ serial ports library
On Fri, 28 Dec 2018 10:41:09 +0100 Alec Leamas wrote: > This is a dependency for opencpn, #907065, new for 4.8.8. It turns out that the preferred way to build opencpn in 4.8.8 is without this library. It will still be used in 5.0.0, fingers crossed. So: - This request is still valid, although with even lower priority than general wishlist bugs. - For me, #907065 is more important.
Bug#872749: [Pkg-lirc-maint] Bug#872749: lircd logs all messages twice
On Sat, 29 Sep 2018 10:14:33 +0200 Tobias Frost wrote: > Regarding the reported issue, at the BSP in Chemnitz, helmut looked at > his (stretch) installation and also saw the duplicated lines. > I've also debootstraped an sid chroot, systemd-nspawn'ed it and could > also see duplicated log lines. Hm... I have had problems (besides ENOTIME) to duplicate this. However, it turns out that some users have had problems with the lircd-uinput service. This used to be enabled by default (which in hindsight was wrong). Could anyone having this problem: - Report the output from 'systemctl status lircd-uinput.service'? - Check if 'systemctl disable --now lircd-uinput.service' removes the duplicated messages? Cheers! --alec
Bug#917561: RFS: opencpn/4.8.8+dfsg.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "opencpn" * Package name: opencpn Version : 4.8.8+dfsg.1-1 Upstream Author : Dave Register * URL : https://www.opencpn.org * License : GPL2+ Section : misc It builds those binary packages: opencpn- Chartplotter and Marine GPS Navigation Software opencpn-data - Chartplotter and Marine GPS Navigation Software (data) opencpn-plugins - Chartplotter and Marine GPS Navigation Software (transitional) To access further information about this package, please visit https://mentors.debian.net/package/opencpn Alternatively, one can download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_4.8.8+dfsg.1-1.dsc More information about opencpn can be obtained from https://www.opencpn.org. Changes since the last upload: opencpn (4.8.8+dfsg.1-1) unstable; urgency=medium * New upstream version * Fix ITP bugs. (closes: #907065, closes: #538067). * README.harmonics: dropped, we now use the opencpn data. * README.lucid: dropped, outdated. * Drop all existing patches (outdated). * compat level bumped to 9. * The copyright file is updated and now also supports the repacked source, but #831870 makes it necessary to use get-orig-source. * Add 14 patches (0001..0014) backported from current upstream/master, mostly build fixes. * Add two patches currently in an upstream PR (0015, 0016). * Add one downstream patch 0017. * Patching includes flexible freedesktop plugin paths, see new manpage. * The manpage which used to be a debian patch is upstreamed. * The -doc package is dropped in favor of downloading the manual from the opencpn website. Downstream patch provides HTML pointer-to-docs page. * A large number of new build dependencies. * The -plugins package is dropped, opencpn is not usable without the default, limited set of plugins. * A debian/upstream/metadata file is added. Regards, Alec Leamas
Bug#917531: ITP: libcxx-serial: Cross-platform c++ serial ports library
Package: wnpp Severity: wishlist Owner: Alec Leamas * Package name: cxx-serial Version : 1.2.1 Upstream Author : William Goodall * URL : http://wjwwood.io/serial/ * License : Expat Programming Lang: C++ Description : C++, cross-platform serial communications library This is a dependency for opencpn, #907065, new for 4.8.8. The name is somewhat ad-hoc, upstream name is serial. However, libserial is already in debian using another upstream.
Bug#911541: RFS: wxsvg/2:1.5.15+dfsg.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wxsvg" * Package name: wxsvg Version : 2:1.5.15+dfsg.2-1 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : GPL-2+ and wxWindows Section : libs It builds those binary packages: libwxsvg-dev - Development files for wxSVG libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg3 - SVG library for the wxWidgets toolkit To access further information about this package, please visit https://mentors.debian.net/package/wxsvg Or, download the package with dget using: dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.15+dfsg.2-1.dsc The package has an ongoing but stalled review, see the mentors comment dated 2018-10-19 15:18. Changes since the last upload: * Re-introduce wxsvg to Debian, latest upstream release. * New -tools package with svgview viewer. * Update dfsg versioning scheme. * Drop get-orig-source in favor of regular uscan download. * Add hardening build flags. * Move to libwxsvg3 to match soname. * Add rudimentary d/upstream/metadata. * Bump Standards-Version. * Add libexif build dependency. * Drop libav10 patch * Drop --with-scour build dependency. * Drop bundled but generated files from package. * Drop obsolete version requirement on libpango1.0-dev. * Drop obsolete g++ and dh_autoreconf dependencies. Regards, Alec Leamas
Bug#911038: sysconfig: inconsistent sitelib path
Package: python3.6
Version: 3.6.7~rc1-1
On 3.7, the python.m4 automake macro reports the site path as
./usr/lib/x86_64-linux-gnu/python3.6/site-packages. This causes all
sorts of interesting installation issues.
Looking into the situation the python.m4 macro uses
if can_use_sysconfig:
sitedir = sysconfig.get_path('purelib',
vars={'base':'$am_py_prefix'})
else:
from distutils import sysconfig
sitedir = sysconfig.get_python_lib(0, 0, prefix='$am_py_prefix')
Now, sysconfig seems to be broken:
>>> import sysconfig
>>> sysconfig.get_path('purelib', vars={'base':'/usr/local'})
'/usr/local/lib/python3.6/site-packages'
while distutils.sysconfig actually is fine:
>>> from distutils import sysconfig
>>> sysconfig.get_python_lib(0, 0, prefix='/usr/local')
'/usr/local/lib/python3/dist-packages'
Since I cannot see that python.m4 does anything wrong here I file the
issue against python.
Regards,
Alec Leamas
Bug#910895: RFS: lirc/0.10.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lirc" * Package name: lirc Version : 0.10.1-1 Upstream Author : Christoph Bartelmus l...@sf.net * URL : http://sf.net/p/lirc * License : GPL-2+ Section : utils It builds those binary packages: liblirc-client0 - infra-red remote control support - client library liblirc-dev - Infra-red remote control support - development files liblirc0 - Infra-red remote control support - Run-time libraries liblircclient-dev - Transitional placeholder for obsoleted liblircclient-dev liblircclient0 - Transitional placeholder for obsoleted liblircclient0 lirc - Infra-red remote control support - daemons and utils lirc-doc - Infra-red remote control support - website and manual docs lirc-x - infra-red remote control support - X utilities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lirc Or, download the package with dget: dget -x https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.1-1.dsc More information about lirc can be obtained from http://lirc.org. Changes since the last upload: - Updated to latest upstream bugfix release - Fixed a crash when starting lirc-setup(1). - Dropped an upstreamed build patch. - Update to version 4.2.1, compat level 11 (systemd fixes). Regards, Alec Leamas
