Bug#1080486: python-google-api-core: Please package new upstream release 2.19.2
On Thu, Oct 10, 2024, Boyuan Yang wrote: > X-Debbugs-CC: adrien.na...@canonical.com > > On Thu, 10 Oct 2024 18:48:47 +0200 Adrien Nader > wrote: > > Hi, > > > > Apologies for not answering the initial report. > > > > Upstream does a release every few days which makes tracking their > > versions impossible. For that reason and generally speaking, update > > requests should come with an explanation of why an update will be > > useful. > > > > The reason for this package was to be able to move forward with dropping > > python-oauth2client in favor of maintained libraries initially because > > oauth2client uses APIs removed from pyopenssl and later on because that > > helps with authentication in gcalcli, mutt/neomutt, and others. > > > > The package itself is present purely as a dependency of python-googleapi > > and I'm not sure it has another use than that. > > I wasn't around in August so I couldn't follow up with that > > unfortunately but I never intended to hold tight on the package due to > > all of the above. At the moment, I'm not entirely clear on the course of > > action to have it inside the DPT however. > > People care this package due to its importance, even if only as a dependency > package. > If you are willing to have it team-maintained under Debian Python Team > as shown on https://wiki.debian.org/Teams/PythonTeam , please just let us > know. > All relevant necessary one-time tasks (creating git packaging repo under the > team, > updating metadata) can be done soon with your permission. After that, you can > still > maintain this package in Debian as usual, while other team members can also > handle > Python-related tasks together on this package. I think team maintenance will be best for the package so please go ahead and let me know if there is something I can do to help. Thanks. -- Adrien
Bug#1080486: python-google-api-core: Please package new upstream release 2.19.2
Hi, Apologies for not answering the initial report. Upstream does a release every few days which makes tracking their versions impossible. For that reason and generally speaking, update requests should come with an explanation of why an update will be useful. The reason for this package was to be able to move forward with dropping python-oauth2client in favor of maintained libraries initially because oauth2client uses APIs removed from pyopenssl and later on because that helps with authentication in gcalcli, mutt/neomutt, and others. The package itself is present purely as a dependency of python-googleapi and I'm not sure it has another use than that. I wasn't around in August so I couldn't follow up with that unfortunately but I never intended to hold tight on the package due to all of the above. At the moment, I'm not entirely clear on the course of action to have it inside the DPT however. -- Adrien
Bug#1079767: test_suite still present in setup.py (minor issue)
Hi Colin, While working on this issue in parallel for Ubuntu, I noticed that setup.py contains a "test_suite" argument that affects the build. I have not noticed an actual issue due to that, only non-fatal errors in the build log. I've opened a PR upstream: https://github.com/byllyfish/precis_i18n/pull/38 . It can be nice to have but I also don't think there is a need for a new version solely for that but wanted to supplement the bug report (NB: the patch would need minor changes due to upstream having used black since their last release). -- Adrien
Bug#1076444: beancount: oauth2client has been deprecated for seven years
Source: beancount Version: 2.3.5-2build1 Severity: normal Beancount 2.3.6-1 introduced a dependency on python3-oauth2client which has unfortunately been deprecated for 7 years now. Unsurprisingly, there are more and more issues popping up which is why I'm working on removing it (especially from Ubuntu as it breaks with new pyopenssl versions and prevents it from migrating). The current use seems to be solely upload-to-sheets (calling sheets_upload.py). Note that in the recently-released beancount 3, this binary has been moved in another package. I've opened https://github.com/beancount/beancount/issues/837 but as mentioned above, upload-to-sheets has been removed from beancount 3 anyway. I don't know if upstream has short-terms plans to update script. I think it makes sense to drop the dependency on python3-oauth2client for now and possibly re-introduce it once things have settled down. -- Adrien
Bug#1057382: Certbot 2.10.0 and 2.11.0 releases are signed
Hi, For the record, the latest releases now include signatures and 2.11.0 is available: https://github.com/certbot/certbot/releases/tag/v2.11.0 Note that I was initially interested in newer released in order to be able to remove dependency on python-oauth2client from https://github.com/certbot/certbot/commit/b0d0a832772bc7747f65c2c2c90d0f790fa40f8a#diff-6d0d0d0e6b37c647ff94c0cb9b4333aafb7ae686e8746eec1ed9151be92f5807 By the way, do you know if there is extra work required with updating to one of the latest releases? -- Adrien
Bug#1029032: Package (almost) ready
HI László, Apologies, I was busy on other topics and I had gotten some initial comments on the packaging too (d/copyright needing tweaks). I can't upload and would appreciate sponsoring. I've updated the packaging in the git repository: https://salsa.debian.org/adrien-n/python-google-api-core/-/tree/sid?ref_type=heads I've updated d/copyright and the packaging is lintian-clean. Julian has also tested the package and confirmed it working with new python-googleapi versions. Thanks, -- Adrien
Bug#1072828: Work-around is ineffective on !amd64
I found https://tug.org/svn/texlive?revision=71214&view=revision this morning. It only touches the win32 implementations however. I did something similar for the non-win32 implementation and it fixed the issue for me: https://git.launchpad.net/~adrien/ubuntu/+source/texlive-bin/commit/?id=ccb9edaa83fe517936416ab24476351e3ad7 While the issue is fixed, my confidence in the change is average at best as there could be many side effects. I would prefer to have something from upstream. I'm currently testing the change through a PPA but builds take time and I'll hit a dpkg issue which happens at roughly the same time as the tex one. It should be enough to act as a confirmation though. On Tue, Jun 18, 2024, Preuße, Hilmar wrote: > > I'll stop there as now I'm definitely out of time for today. > > > I'll stop here too, maybe simply removing the --output-dir statement > from the CMakeLists.txt solves the issue. I'll test ASAP. If yes, we > don't look at a general issue, which needs to be solved on TL side. I noticed that statement too on yesterday and I'm curious about your results. Did it manage to avoid the issue? -- Adrien
Bug#1072828: Work-around is ineffective on !amd64
Hi Hilmar,
You're absolutely right, thanks for having a look and sorry for the
noise. Trying to go too fast was a bad idea yet another time. :)
I've straced the build and the file seems generated and I see some
interesting things. I've heavily edited the output because the original
is already 11M.
Command:
strace --decode-fds=all --no-abbrev --decode-pids=all -tt -f -o log -s 4096
ninja
> execve("/usr/bin/mkdir", ["mkdir", "/tmp/mt646779.tmp"],
> 0x5ff64b6b9298 /* 36 vars */) = 0
> [...]
> execve("/usr/bin/mf-nowin", ["mf-nowin", "-progname=mf",
> "\\mode:=ljfour;", "mag:=1+0/600;", "nonstopmode;", "input", "logo10"],
> ["MAKETEX_MAG=1+0/600",
> "KPSE_DOT=/build/therion-oW9QKw/therion-6.2.1/thbook",
> "TEXINPUTS=/build/therion-oW9QKw/therion-6.2.1/build/thbook;.", "USER=root",
> "MAKETEX_MODE=/", "KPATHSEA_DPI=600", "SHLVL=1", "KPATHSEA_FORMAT=pk",
> "HOME=/sbuild-nonexistent",
> "OLDPWD=/build/therion-oW9QKw/therion-6.2.1/thbook",
> "MT_MKTEX_CNF=/etc/texmf/web2c/mktex.cnf",
> "SCHROOT_CHROOT_NAME=oracular-amd64", "APT_CONFIG=/var/lib/sbuild/apt.conf",
> "MT_MKTEXUPD=/usr/share/texlive/texmf-dist/web2c/mktexupd",
> "FORCE_SOURCE_DATE=1", "SCHROOT_UID=1000", "LOGNAME=root",
> "_=/usr/bin/strace", "SELFAUTOLOC=/usr/bin", "MT_VARTEXFONTS=/tmp/texfonts",
> "SELFAUTODIR=/usr", "SELFAUTOPARENT=/",
> "PATH=/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
> "MT_MKTEXNAM_OPT=/usr/share/texlive/texmf-dist/web2c/mktexnam.opt",
> "SCHROOT_COMMAND=/bin/sh -c bash -i /dev/tty 2>/dev/tty",
> "SCHROOT_SESSION_ID=oracular-amd64-d07c1014-b360-465a-91e8-3cc500813699",
> "engine=pdftex", "SCHROOT_ALIAS_NAME=oracular-amd64", "LANG=en_US.UTF-8",
> "MT_TEXMFMAIN=/usr/share/texlive/texmf-dist",
> "MT_MKTEXDIR_OPT=/usr/share/texlive/texmf-dist/web2c/mktexdir.opt",
> "SCHROOT_GROUP=adrien", "SCHROOT_USER=adrien", "SHELL=/bin/sh",
> "TEXMF_OUTPUT_DIRECTORY=/build/therion-oW9QKw/therion-6.2.1/build/thbook",
> "SELFAUTOGRANDPARENT=/", "KPATHSEA_NAME=logo10", "LC_ALL=C",
> "PWD=/tmp/mt646779.tmp",
> "MT_MKTEXNAM=/usr/share/texlive/texmf-dist/web2c/mktexnam",
> "MAKETEX_BASE_DPI=600",
> "MT_MKTEX_OPT=/usr/share/texlive/texmf-dist/web2c/mktex.opt",
> "SCHROOT_GID=1000", "progname=mktexpk",
> "MT_MKTEXDIR=/usr/share/texlive/texmf-dist/web2c/mktexdir"]
> [...]
> openat(AT_FDCWD,
> "/build/therion-oW9QKw/therion-6.2.1/build/thbook/logo10.600gf",
> O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8
> [...]
>
> write(8,
> "\367\203 METAFONT output 2024.06. ..
>
> close(8) = 0
> [...]
> faccessat2(AT_FDCWD, "logo10.600gf", R_OK,
> AT_EACCESS) = -1 ENOENT (No such file or directory)
> [...]
> write(1, "mktexpk: `mf-nowin -progname=mf
> \\mode:=ljfour; mag:=1+0/600; nonstopmode; input logo10' failed to make
> logo10.600pk.\n", 117) = 117
The file is created and written to but it's in
"/build/therion-oW9QKw/therion-6.2.1/build/thbook" rather than
"/tmp/mt646779.tmp" where mktexpk expects it to be.
Note that while running the commands directly myself, it seems I managed
to generate the file in an expected location and I was getting an error
about logo10.720gf rather than .600gf.
Several environment variables refer to the first directory: KPSE_DOT,
TEXINPUTS, OLDPWD, TEXMF_OUTPUT_DIRECTORY.
For TEXMF_OUTPUT_DIRECTORY, I've found the following:
https://tug.org/pipermail/tex-live-commits/2024-February/028329.html
> Modified: trunk/Build/source/texk/kpathsea/NEWS
> ===
> --- trunk/Build/source/texk/kpathsea/NEWS 2024-02-05 00:43:32 UTC (rev
> 69710)
> +++ trunk/Build/source/texk/kpathsea/NEWS 2024-02-05 17:23:27 UTC (rev
> 69711)
> @@ -2,11 +2,12 @@
> This file records noteworthy changes. (Public domain.)
>
> 6.4.0 (for TeX Live 2024)
> -* Support an extended check for safe filenames, also allowing
> +* Support an extended check for safe filenames which also allows
>TEXMF[SYS]VAR, for Lua(La)TeX; new functions and corresponding
>kpsewhich options.
> -* Allow the new variable TEXMF_OUTPUT_DIRECTORY (as well as TEXMFOUTPUT),
> - so that subprograms can have access to an --output-directory setting.
> +* Support a new variable TEXMF_OUTPUT_DIRECTORY (alongside the
> + traditional TEXMFOUTPUT), so that subprograms can have access to an
> + --output-directory setting in an engine invocation.
I'll stop there as now I'm definitely out of time for today.
--
Adrien
Bug#1072828: Work-around is ineffective on !amd64
Hi, I hit that issue while working on the vtk9 9.3 transition in Ubuntu and I also tried to add 'texlive-fonts-recommended' as a dependency (at least temporarily so that the transition can finish). Unfortunately it only works on amd64. On arm64, armhf, ppc64el and s390x, the error is still present (see https://launchpad.net/~adrien/+archive/ubuntu/oracular-gdcm-ftbfs-vtk-9.3/+sourcepub/16226649/+listing-archive-extra ) I didn't investigate further. -- Adrien
Bug#1073793: camitk FTBFS with VTK 9.3
Source: camitk Version: 5.2.0-1 Severity: serious Tags: ftbfs upstream Justification: fails to build from source (but built successfully in the past) While working on the vtk9 9.3 transition in Ubuntu, I found that the package does not build with VTK 9.3 (at least one incompatibility was introduced with VTK 9.2). I've opened a bug report on the upstream bug tracker: https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/193 and I'm copying the contents here for convenience: > I found several issues while trying to build camitk for VTK 9.3 in > Ubuntu/Debian. > > In sdk/components/vtkimage/RawDataDialog.cpp, vtkConfigure.h is not > packaged anymore and vtkType.h should be included instead > > In sdk/actions/mesh/basicmesh/MeshQuality.cpp, VTK 9.2 has renamed > SetHexQualityMeasureToMaxEdgeRatios and > SetQuadQualityMeasureToMaxEdgeRatios: the trailing 's' is removed > > In sdk/actions/mesh/basicmesh/MeshQuality.cpp, VTK 9.2 "vtkMeshQuality > and vtkCellQuality [...] no longer supports the AspectBeta tetrahedron > metric", and I'm not sure what to do as this could impact the library's > API. The last issue means that API of the package would likely break which means it would be better to have a new upstream version. -- Adrien
Bug#1072822: Patch available
Hi,
I've prepared a fixed version in Ubuntu and Graham uploaded it. There is
another issue than this SPDX one.
I'm attaching the patch and won't paraphrase it.
--
Adrien
diff --git a/debian/changelog b/debian/changelog
index d155039..da50cb1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+gdcm (3.0.24-1ubuntu1) oracular; urgency=medium
+
+ * VTK 9.3 compatibility (LP: #2069612):
+- d/p/vtk-9.3-compat.patch
+- d/p/cmake-include-gnuinstalldirs.patch: include(GNUInstallDirs) in
+ order to define CMAKE_INSTALLDIR_INCLUDE
+- install usr/include/vtkgdcmpython.h
+
+ -- Adrien Nader Fri, 14 Jun 2024 17:04:24 +0200
+
gdcm (3.0.24-1build1) oracular; urgency=medium
* Rebuild against new libvtk9.3.
diff --git a/debian/control b/debian/control
index 648e47f..56a43dc 100644
--- a/debian/control
+++ b/debian/control
@@ -1,5 +1,6 @@
Source: gdcm
-Maintainer: Debian Med Packaging Team
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian Med Packaging Team
Uploaders: Steve M. Robbins ,
Sébastien Jodogne ,
Gert Wollny
diff --git a/debian/control.in b/debian/control.in
index 5f7b1f0..77a795d 100644
--- a/debian/control.in
+++ b/debian/control.in
@@ -1,5 +1,6 @@
Source: gdcm
-Maintainer: Debian Med Packaging Team
+Maintainer: Ubuntu Developers
+XSBC-Original-Maintainer: Debian Med Packaging Team
Uploaders: Steve M. Robbins ,
Sébastien Jodogne ,
Gert Wollny
diff --git a/debian/patches/cmake-include-gnuinstalldirs.patch b/debian/patches/cmake-include-gnuinstalldirs.patch
new file mode 100644
index 000..2163cb0
--- /dev/null
+++ b/debian/patches/cmake-include-gnuinstalldirs.patch
@@ -0,0 +1,19 @@
+Subject: Use default "GNU" installation directories
+Author: Adrien Nader
+Forwarded: https://sourceforge.net/p/gdcm/bugs/563/
+Last-Update: 2024-06-14
+Applied-Upstream: no
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 38c65d11..d0d77d7d 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -187,6 +187,8 @@ macro(CHECK_INCLUDE_FILE_CONCAT FILE VARIABLE)
+ endif()
+ endmacro()
+
++include(GNUInstallDirs)
++
+ #include(${GDCM_SOURCE_DIR}/CMake/gdcmPlatformCxxTests.cmake)
+ #
+ #GDCM_PLATFORM_CXX_TEST(GDCM_CXX_HAS_FUNCTION
diff --git a/debian/patches/series b/debian/patches/series
index 20a1fa9..66ebc2a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,5 @@ rename-pdf.patch
03_linkvtkdoc.patch
04_multiarch.patch
dircos_rev.patch
+vtk-9.3-compat.patch
+cmake-include-gnuinstalldirs.patch
diff --git a/debian/patches/vtk-9.3-compat.patch b/debian/patches/vtk-9.3-compat.patch
new file mode 100644
index 000..a5cc411
--- /dev/null
+++ b/debian/patches/vtk-9.3-compat.patch
@@ -0,0 +1,96 @@
+Subject: Compatibility with VTK 9.3
+Author: Nicklas Larsson
+Forwarded: https://sourceforge.net/p/gdcm/bugs/552/#9e8f
+Applied-Upstream: no
+Last-Update: 2023-12-05
+Bug: https://sourceforge.net/p/gdcm/bugs/552/
+
+--- gdcm.orig/CMakeLists.txt.orig
gdcm/CMakeLists.txt
+@@ -698,6 +698,7 @@
+ HEADERS_DESTINATION "${GDCM_INSTALL_INCLUDE_DIR}/vtk${vtk_version_suffix}"
+ CMAKE_DESTINATION "${GDCM_INSTALL_PACKAGE_DIR}"
+ LICENSE_DESTINATION "${GDCM_INSTALL_DATA_DIR}/vtkgdcm-${GDCM_SHORT_VERSION}"
++SPDX_DESTINATION "${GDCM_INSTALL_DATA_DIR}/vtkgdcm-${GDCM_SHORT_VERSION}"
+ HIERARCHY_DESTINATION "${GDCM_INSTALL_LIB_DIR}/vtk${vtk_version_suffix}/hierarchy/vtkgdcm"
+ LIBRARY_NAME_SUFFIX "${vtkgdcm_library_suffix}"
+ VERSION "${GDCM_VERSION}"
+
+
+--- gdcm.orig/Utilities/VTK/vtkImageColorViewer.h.orig
gdcm/Utilities/VTK/vtkImageColorViewer.h
+@@ -199,22 +199,6 @@
+ virtual int GetOffScreenRendering();
+ vtkBooleanMacro(OffScreenRendering,int);
+
+- // Description:
+- // @deprecated Replaced by vtkImageColorViewer::GetSliceMin() as of VTK 5.0.
+- VTK_LEGACY(int GetWholeZMin());
+-
+- // Description:
+- // @deprecated Replaced by vtkImageColorViewer::GetSliceMax() as of VTK 5.0.
+- VTK_LEGACY(int GetWholeZMax());
+-
+- // Description:
+- // @deprecated Replaced by vtkImageColorViewer::GetSlice() as of VTK 5.0.
+- VTK_LEGACY(int GetZSlice());
+-
+- // Description:
+- // @deprecated Replaced by vtkImageColorViewer::SetSlice() as of VTK 5.0.
+- VTK_LEGACY(void SetZSlice(int));
+-
+ protected:
+ vtkImageColorViewer();
+ ~vtkImageColorViewer();
+
+
+
+--- gdcm.orig/Utilities/VTK/vtkImageColorViewer.cxx.orig
gdcm/Utilities/VTK/vtkImageColorViewer.cxx
+@@ -919,34 +919,6 @@
+ }
+
+ //
+-#ifndef VTK_LEGACY_REMOVE
+-int vtkImageColorViewer::GetWholeZMin()
+-{
+- VTK_LEGACY_REPLACED_BODY(vtkImageColorViewer::GetWholeZMin, "VTK 5.0",
+- vtkImageColorViewer::GetSliceMin);
+- r
Bug#1029032: Package (almost) ready
Hi, I hadn't spotted your ITP until I had prepared https://salsa.debian.org/adrien-n/python-google-api-core and was filling an ITP myself. Since it's ready and passing, I'd like to more forward with this. Do you have any objection? Thanks, -- Adrien
Bug#1062770: Headers still prevent dumps; worked around
Hi, I attempted to dump the ABIs with a-c-c and the current script around it but couldn't do so. The compiler complains that there is a type definition inside sizeof() which is pretty accurate. This happens through the following: > RAFT__ASSERT_COMPATIBILITY(RAFT__RESERVED, RAFT__EXTENSIONS); In order to analyze the package, I had to: - delete that macro (it doesn't change the library ABI AFAICT), - skip raft/fixture.h, - include raft.h first (I don't think that was necessary but it's probably cleaner that way anyway). I published an updated consolidated report this morning. As you can see, there is an ABI change due to LFS in raft/uv.h https://adrien.dcln.fr/misc/armhf-time_t/2024-02-22T10%3A55%3A00/compat_reports/libraft-dev/base_to_lfs/compat_report.html It is possible some API is not supposed to be exposed or does not appear in a shared library or something else, and it would therefore be safe to ignore an ABI change that abi-compliance-checker reports. Since I don't have specific experience with this package, I can't take such decisions and it is ultimately your call. -- Adrien
Bug#1061341: Some headers are still unusable
On Fri, Feb 16, 2024, Adrien Nader wrote: > I was able to analyze the library after modifying auth.h (actually > cyrus/*.h) to use cyrus/strarray.h and skipping bitvector.h. The > analysis returns that the library is both time_t and LFS sensitive. I > will publish a report soon (hopefully this evening but I can't > guarantee it). I've pushed updated results. You can find the ones for cyrus-dev at https://adrien.dcln.fr/misc/armhf-time_t/2024-02-16T21%3A19%3A00/compat_reports/cyrus-dev/ -- Adrien
Bug#1061341: Some headers are still unusable
Hi, I am trying to update the time_t analysis and I'm seeing a couple issues in headers. Note that I may also be doing something wrong and/or stupid since I'm approaching this through a-c-c rather than as a regular user. The two issues: - at least auth.h (IIRC) refers to lib/strarray.h but the headers might rather be cyrus/strarray.h, - cyrus/bitvector.h uses config.h which isn't shipped. I was able to analyze the library after modifying auth.h (actually cyrus/*.h) to use cyrus/strarray.h and skipping bitvector.h. The analysis returns that the library is both time_t and LFS sensitive. I will publish a report soon (hopefully this evening but I can't guarantee it). -- Adrien
Bug#1062057: updated analysis results (ABI is unaffected)
Hi, I just ran the analysis again: the ABI was dumped without requiring any quirk. After diff, the result is that the ABI is not affected by either time_t or LFS. :) I don't publish results after every update as that would be overwhelming but I should do so by friday evening. -- Adrien
Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition
On Fri, Feb 09, 2024, Christoph Berg wrote: > Re: Adrien Nader > > I think the most recent version of that script would be in my > > repository: https://salsa.debian.org/adrien-n/armhf-time_t/ > > Hi Adrien, > > I actually got the script running, I think. I pushed a few > https://salsa.debian.org/vorlon/armhf-time_t/-/merge_requests/132 that > have not been merged yet, though. Nice! Watch out though if you don't use a container: the script can change your system. You also need to run it on armhf to have the correct machine definitions. Steve's repository and mine have diverged because it takes time to review and merge. I plan to get them in sync next week, at which point I will be able to look at these changes and integrate them. > I guess when it says "Compatibility: 100%", everything is ok? I got > that on libpq-dev. There are two ABI tests: one for LFS and one for time_t (64-bit time_t on 32-bit arches implies LFS with glibc). Once you have the dumps, you should diff that with diff_package.sh "$foo" and it will report on stdout whether the package is LFS- or time_t-sensitive. Additionally, a few files will be created, among which: - compat_reports/libpq-dev/lfs_to_time_t/compat_report.html - compat_reports/libpq-dev/base_to_lfs/compat_report.html On libpq-dev, I see that there is no LFS effect (abi-compliance-checker reports 100% compat) but there is a time_t one. Looking at the HTML reports, the cause is: pqWaitTimed ( int forRead, int forWrite, PGconn* conn, long finish_time ) The ABI is therefore time_t-dependant. With an insider POV, you can maybe find reasons this doesn't matter; that's not something I can do however. > What I'm completely missing is an overview which *source* packages are > affected. I really want to avoid having postgresql-16 included in this > transition, and I am not yet sure if it's considered to be affected or > not. It was being included by default due to failing to build too. Since I've made this work for libpq-query-dev (more on that below), postgresql-server-dev-16 should be easier now but there are errors of its own. [it's being worked on; I don't have the results yet but I expect they will cover at least the same ones as libpg-query-dev which I detail below] > > I'll probably give it a quick shot again today but I don't have much > > time; unless errors are few and obvious, it's unlikely that I will make > > much progress on it though. > > On libpg-query-dev, the problem is that the script puts some > windows-only headers into the include path that then shadow a system > header that should actually be used: > > The GCC parameters: > gcc -fdump-lang-raw -fkeep-inline-functions -c -x c++ -fpermissive -w > "/tmp/8yhLzFzeyA/dump1.h" -I/usr/include/pg_query/postgres > -I/usr/include/pg_query/postgres/utils > -I/usr/include/pg_query/postgres/port/win32_msvc > -I/usr/include/pg_query/postgres/port/win32 > > In file included from > /usr/include/pg_query/postgres/port/win32/netinet/tcp.h:5, > from /usr/include/pg_query/postgres/libpq/libpq-be.h:26, > from /usr/include/pg_query/postgres/libpq/auth.h:17, > from /tmp/8yhLzFzeyA/dump1.h:174: > /usr/include/pg_query/postgres/port/win32/sys/socket.h:14:10: fatal error: > winsock2.h: No such file or directory >14 | #include > | ^~~~ > compilation terminated. > > > This -I/usr/include/pg_query/postgres/port/win32 should not be there. I did the work on libpq-query-dev; there were quite a few things to change. The way the script works is by trying to build all headers from a given package: this is why it tried to build files from port/win32. In addition to that, abi-compliance-checker has a number of heuristics which are not always helpful. This is why this -I flag was present. Anyway, as I said and after many quirks, I got it to dump and diff: the ABI of libpg-query-dev is affected by both LFS and time_t. NB: I think a-c-c reports symbol changes as removal + addition You can review the change summary below. Maybe some symbols are internal-only, or not actually visible in normal usage, or definitions of symbols that are not in the package's libs (could be libc for instance: we can't map symbols from headers to shared objects shipped by the corresponding library package). Big wall of text below. For time_t: Problems with Data Types, Low Severity 1
Bug#1062567: libpg-query: NMU diff for 64-bit time_t transition
Hi Christoph, The automated assessment uses a script which in turns uses abi-compliance-checker. I think the most recent version of that script would be in my repository: https://salsa.debian.org/adrien-n/armhf-time_t/ The README.md file describes it (it doesn't describe other tools in that repo though). There is definitely a high setup cost unfortunately: from setting up containers, to reading the results, understanding errors and finally being able to create appropriate quirks. I spent some time on the analysis of libpq-query-dev earlier this week. Unfortunately, a recent change to the package (namely adding postgresql headers) has greatly expanded the API/ABI surface; btw, the package these headers come from cannot be analyzed either. I'll probably give it a quick shot again today but I don't have much time; unless errors are few and obvious, it's unlikely that I will make much progress on it though. -- Adrien
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
Hi Helmut, Thanks for identifying and raising this issue. After Graham mentioned this to me, I also looked at the reports and came to the same conclusion: the change is actually LFS due to ino_t in matchpathcon_filespec_add(). Providing two APIs makes me quite uneasy due to having core components that would behave differently from the rest of the distribution. It sounds like something that will come back to bite for a long time. I checked on codesearch.d.n and there are very few users on this API; actually, none I think. Per https://codesearch.debian.net/search?q=matchpathcon_filespec_add&literal=1&perpkg=1 - box64 mentions that API but the "code" is commented-out, - busybox uses it in the "setfiles" applet which isn't built, - android-platform-external-libselinux has it in headers but also has its own implementation That should hopefully give more freedom although I'm not sure what would be the preferred route. -- Adrien
Bug#1051348: Acknowledgement (svt-av1: Please package gstreamer element)
I had a look at this and it appears that you can't build the gstreamer element along the rest of the sources: you need to install svt-av1 first. It doesn't look easy to integrate this into the current build unfortunately. It might be better to create a separate package. Do you have any thought on this? -- Adrien
Bug#1054402: sslscan: Please update to latest sslscan version (currently 2.1.1)
Package: sslscan Version: 2.0.16-1~ppa1 Severity: wishlist Hi, Can you update sslscan to the latest version? I have tried doing it myself and it required no change. I didn't try to include a patch here due to how simple the update actually is. I also notice that you haven't updated the package in close to three years. Can you let us know about your intents wrt maintenance going forward? I'd be willing to help or handle the package. Thanks, -- Adrien -- System Information: Debian Release: bookworm/sid APT prefers lunar-updates APT policy: (500, 'lunar-updates'), (500, 'lunar-security'), (500, 'lunar'), (100, 'lunar-backports') Architecture: amd64 (x86_64) Kernel: Linux 6.2.0-33-generic (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sslscan depends on: ii libc62.37-0ubuntu2.1 ii libssl3 3.0.8-1ubuntu1.2 sslscan recommends no packages. sslscan suggests no packages. -- no debconf information
Bug#844025: sslscan does not rely on openssl for ssl/tls anymore
Hi, Ssslcan does not use openssl for the ssl/tls protocols anymore. It still uses it for some things but not for the protocols themselves. This is explained by the following in README.md: > sslscan version 2 has now been released. This includes a major rewrite > of the backend scanning code, which means that it is no longer reliant > on the version of OpenSSL for many checks. This means that it is > possible to support legacy protocols (SSLv2 and SSLv3), as well as > supporting TLSv1.3 - regardless of the version of OpenSSL that it has > been compiled against. As such, a) the issue reported is fixed, b) there should be no future discussions about statically linking openssl. I've also closed the three or four bug reports in Ubuntu that were related to this. -- Adrien
Bug#1051348: svt-av1: Please package gstreamer element
Source: svt-av1 Version: 1.4.1+dfsg-1 Severity: wishlist Hi, There is a gstreamer element in the "gstreamer-plugin" directory. Can you package it? At the moment the only gstreamer element available to encode using AV1 is libaom. Thanks.
Bug#1038450: patch probably available
On Wed, Jun 21, 2023, julien.pu...@gmail.com wrote: > Le mardi 20 juin 2023 à 22:38 +0200, Adrien Nader a écrit : > > > > > > The patch seems to fix the issue. I say "seem" because the build > > compiled the file that was failing to build but the build is not done > > yet: emulated armhf isn't fast. :) > > > > But since I reprocued the build failure before, I am fairly confident > > this build will succeed. > > I took the commit and added it to the Debian packaging ; I now have a > 20230420-4 almost ready for upload. > > I'm waiting for two feedbacks before I do so : > > 1. yours so I trust it fixes the 32-bit issue ; > > 2. the sbuild I started on my box to check the patch on more usual > architectures. > > Thanks for your help! My build just finished. It only took 27 hours. It failed at the lintian step but that was due to network issues.
Bug#1038450: patch probably available
On Tue, Jun 20, 2023, julien.pu...@gmail.com wrote: > Hi, > > Le mardi 20 juin 2023 à 15:35 +0200, Adrien Nader a écrit : > > I was looking at the migration for coq on Ubuntu and a build failure > > on armhf is preventing it. > > > > I expect that this issue is fixed by the following commit: > > > > https://github.com/UniMath/UniMath/commit/1716c078b00c18dcabf63f671e414d7ba33cb23c > > > > Split the proof of associators_equiv to make sure it fits inside 32 > > b… > > > > …its (#1687) > > > > This is necessary to create a jscoq addon for UniMath > > (https://github.com/UniMath/UniMath-jsCoq). > > > > I haven't tried the patch yet and wanted to ask first if you're > > interested in restoring support for 32-bit arches. I honestly don't > > know > > if there's a lot of users on these (except maybe for JS). > > If you can confirm that commit solves the issue, I'll add it as a patch > to the Debian packaging and drop my latest change. I'm interested in > having different platforms to detect subtle breakages. > > Notice that I also reported to Coq upstream: > https://github.com/coq/coq/issues/17749 The patch seems to fix the issue. I say "seem" because the build compiled the file that was failing to build but the build is not done yet: emulated armhf isn't fast. :) But since I reprocued the build failure before, I am fairly confident this build will succeed. -- Adrien
Bug#1038725: gnustep-base: NSURL tests can fail due to httpbin.org being unreliable
Source: gnustep-base Version: 1.29.0-4 Severity: normal Tags: patch upstream Hi, While working on Ubuntu's migrations, I noticed gnustep-base would FTBFS due to network tests failing. There's an upstream commit to improve this: https://github.com/gnustep/libs-base/commit/7e14fd1979963cf413a231ef6e9deefad89f233e Change NSURL tests to use example.com httpbin.org has lately been unreliable, leading to spurious test failures on CI. While the package for unstable built successfully and the issues with httpbin.org seem fixed, I still wanted to report this since it is possible you encounter the issue with a future upload. If this happens more frequently, maybe a solution would be to use a debian hostname since they should not be failing when the CI is working. -- Adrien
Bug#1038450: patch probably available
Hi, I was looking at the migration for coq on Ubuntu and a build failure on armhf is preventing it. I expect that this issue is fixed by the following commit: https://github.com/UniMath/UniMath/commit/1716c078b00c18dcabf63f671e414d7ba33cb23c Split the proof of associators_equiv to make sure it fits inside 32 b… …its (#1687) This is necessary to create a jscoq addon for UniMath (https://github.com/UniMath/UniMath-jsCoq). I haven't tried the patch yet and wanted to ask first if you're interested in restoring support for 32-bit arches. I honestly don't know if there's a lot of users on these (except maybe for JS). -- Adrien
Bug#1026728: Update to 2.4.0 should fix FTBFS
Hi, I was looking at this FTBFS in Ubuntu and noticed that upstream has migrated to github, away from bitbucket. You can see a link from the current upstream page to pypi and then land on github. It is not the same person though but both of them are listed on the pypi page. I'm going to email the original author and ask for some clarifications. Anyway, upstream doesn't seem to have the same FTBFS. Please note that I didn't try to update the package and I can't tell how much work this needs but updating looks like the better path for maintenance. -- Adrien
Bug#1028587: datefudge: 64-bit time_t functions are not implemented/exposed
Package: datefudge Version: 1.24 Severity: important Dear Maintainer, When updating coreutils to version 9.1 in Ubuntu, we noticed that datefudge autopkgtests started failing on armhf. As far as I can tell, the reason is that coreutils now uses a 64-bit time_t and functions with a "64" suffix. Datefudge however does not expose nor implement such functions. The error probably only appears on armhf because other Ubuntu architectures are 64-bit. I think the latest coreutils version in Debian should trigger the same issue. Reproducing is fairly easy. Get and extract the corresponding deb and run something like the following (taken from the package tests): a='2019-07-31 23:01:12'; datefudge -s "$a" $(pwd)/bin/date '+%F %T' Best, -- Adrien
