Bug#1071363: snappy-tools: FTBFS: snappy.cpp:575:51: error: call of overloaded ‘Compress({anonymous}::fd_source*, {anonymous}::FILE_sink*)’ is ambiguous
On Sat, May 18, 2024 at 12:29 AM наб wrote: > But a fixed patch, would be much easier to produce: This is correct, thanks. > I also see [...] > which should've gotten a similar treatment, > or actually no treatment at all, because RawCompressFromIOVec() is new in 1.2 > (but AFAICT calling RawCompressFromIOVec() will fail on overload resolution > like Compress()). Nope, it was added in v1.1.10 and it was part of the archive [1], version 1.2.0 changed the function signature as the others [2] added CompressionOptions. Regards, Laszlo/GCS [1] https://tracker.debian.org/news/1445402/accepted-snappy-1110-1-source-into-unstable/ [2] https://github.com/google/snappy/commit/766d24c95e345d4d06bfd3cc5787c2da3e025fab#diff-ec7058c429b88797a43d7c3ef3a244980e46f8219844cd2550eaf4bcdc36e961L85
Bug#1070977: transition: snappy
On Mon, May 13, 2024 at 2:04 PM Emilio Pozuelo Monfort wrote: > Why is there a libsnappy1v5 transitional package? Serves several purposes. As noted, upstream soname is _not_ changed, so I can't let the old library package be present as it would contain the same named library file conflicting with the one in the new, normally named library package name. In short, I must do a file move between packages. Then the old libsnappy1v5 package has a conflict with the then old libsnappy1 package name. Thus this conflict needs to be removed. > Also has upstream been contacted in order to do a proper SONAME bump? > Otherwise > libsnappy1 will have to conflict with libsnappy1v5, and that will make both > the > transition and upgrades harder, as they have to be done in lockstep. If they > broke the ABI, then a SONAME bump is in order, and that will make it easier > for > us too. Yup, in such cases a soname bump is needed. Then upstream is Google and as I remember years back I had a somewhat similar problem with one of their library package. If I'm correct, I got a similar answer that in such cases they just recompile the dependent sources and don't change the soname. Then the public source tree is hosted on GitHub [1] without the issues (report) area enabled. The AUTHORS file contains a general email address (opensou...@google.com) [2] meaning I'm not sure if I get any answer or I will get one soon. But I can try it if you insist. Regards, Laszlo/GCS [1] https://github.com/google/snappy [2] https://github.com/google/snappy/blob/1.2.0/AUTHORS
Bug#1070977: transition: snappy
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:snappy Hi RMs, Upstream of snappy changed function signatures [1] breaking other applications with the 1.2.0 release. I've added back the original function signatures calling the new ones to restore the immediate problem, to restore the ABI. But then this creates ambiguity in the Compress method signatures [2] making (only) ceph FTBFS. While it can be patched to avoid it, a proper transition should be done. I've renamed back the library name which was done due to the C++11 ABI change with g++ 5.0 back in 2015. Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1070217 [2] https://bugs.debian.org/1070785
Bug#1070785: libsnappy-dev: Ambiguity in Compress method signatures causes FTBFS in ceph
Hi James,
On Thu, May 9, 2024 at 9:03 AM James Page wrote:
cd > The patch added to restore older API signatures to resolve Bug 1070217
> creates ambiguity in the method signatures resulting in FTBFS in at
> least the ceph package:
[...]
> The compression options parameter which was added for >= 1.2 of snappy
> provides a default, so the added method with no options creates this
> ambiguity.
For the time being ceph might patch to call directly the new API with
changing line 78 of SnappyCompressor.h:
snappy::Compress(, );
to
snappy::Compress(, , {});
I can't test it myself as in my test environment ceph can't even
configure due to:
-- crypto soname: libcrypto.so.3
CMake Error at
/usr/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230
(message):
Could NOT find Python3 (missing: Python3_LIBRARY Python3_INCLUDE_DIR
Development) (found suitable exact version "3.10.13")
But indeed, I should do a transition of snappy with a prepared new library name.
Regards,
Laszlo/GCS
Bug#758985: libsqlite3-0: Please support 'icu' and 'unicode61' tokenizers
Hi Mike, On Mon, May 6, 2024 at 10:27 PM Mike Gabriel wrote: > Find attached a .debdiff patch that fixes bug #758985 by building > sqlite3 with SQLITE_ENABLE_ICU. I think there was a time when it was already enabled. Caused some problems, but so late I can't remember exactly. > Please consider enabling the ICU extension and making sqlite3 i18n > capable for languages using regional fonts etc. If this change is not > acceptable, please also let me know. I'm going to upload it to experimental as it will help to test it easily first. Would it pull in too many extra dependencies with ICU? Need to be checked as well. > Maybe it could be an approach to upload an ICU-enabled version of > sqlite3 to experimental and ask people to test their > services/applications with the new-featured sqlite3. I can help with > communications if needed. Please let me know. Do you have a list of people, projects that will be affected by this change? Sure, it would help to reach them for comments. Regards, Laszlo/GCS
Bug#1070401: sqlite3 breaks tracker autopkgtest: killed by signal 6 SIGABRT
Hi Paul, On Sat, May 4, 2024 at 10:27 PM Paul Gevers wrote: > With a recent upload of sqlite3 the autopkgtest of tracker fails in > testing when that autopkgtest is run with the binary packages of sqlite3 > from unstable. [...] > The new version of tracker in unstable also fails in unstable, but that > already has bug 1068468 (which *may* be the same). It _is_ the same bug. But start from the beginning. SQLite3 only got bug fixes between the current testing (3.45.1-1) and unstable (3.45.3-1) package versions [1]. All other packages build and autopkgtest successfully with the SQLite3 version in Sid. Even tracker (current Sid version, 3.7.3-1) itself was compiled and succeeded to self-test with SQLite3 3.4.3-1 [2], see the build log parts: dbus-run-session -- dh_auto_test --no-parallel -- --timeout-multiplier 5 cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=1 meson test --timeout-multiplier 5 19/41 tracker:fts / fts OK 0.46s 25/41 tracker:core / service OK 12.03s Installed-Build-Depends: libsqlite3-0 (= 3.45.3-1), While the autopkgtest results: 87s 8/29 tracker:fts / fts FAIL 0.22s killed by signal 6 SIGABRT In short, how come that while building with SQLite3 version 3.45.3 it works, but autopkgtest with the same version fails? Your mentioned autopkg log spills out a lot of "ambiguous column name: ROWID" as well. It seems the test environment setup is failing somehow. The upstream maintainer of tracker also notes it [3]: -- cut -- Looking at the configuration at https://salsa.debian.org/gnome-team/tracker/-/blob/debian/latest/debian/tests/unit-tests, this looks fishy: [...] I see some issues with this: These loadable modules are not interchangeable with other versions, the internal API may change between minor releases. The libtracker-http-soup3.so is installed in that location, but is not related and does not belong in the src/libtracker-common path. These .so files are not expected in LD_LIBRARY_PATH, they are dlopened from specific locations. The library and test suite will already open the in-tree .so modules, while run through ninja/meson test. The build environment does not need any fooling to do the right thing (i.e. test in-tree code), things might just work if you don't fight it :). -- cut -- Then a quick summary. As I see the autopkgtest configure the build tree and copies installed libraries to it and as such the tests are failing. If I do the same manually from simple CLI then indeed the self testing fails. Still the same environment, still from the same directory if I issue dh_auto_build after the dh_auto_configure and then execute the same "dbus-run-session -- dh_auto_test --no-parallel -- --timeout-multiplier 5": all tests pass. The only difference is that every built binary is in place, not just two libraries copied into the source tree missing something else. This is what SIGABRT suggests, probably some binary or library can't be dlopen-ed as it's (those are) not copied over. It's the tracker autopkg testing that needs fixing. Regards, Laszlo/GCS [1] https://sqlite.org/releaselog/3_45_3.html [2] https://buildd.debian.org/status/fetch.php?pkg=tracker=amd64=3.7.3-1=1714672833=0 [3] https://gitlab.gnome.org/GNOME/tracker/-/issues/434#note_2077470
Bug#1070266: nmu: chromium_124.0.6367.118-1
Control: tags -1 +moreinfo On Fri, May 3, 2024 at 12:57 AM Andres Salomon wrote: > Snappy 1.2.0-1 was uploaded with broken symbols (see > https://bugs.debian.org/1070217). This is fixed in snappy 1.2.0-2, but > chromium in sid had already built against the broken version of snappy. Nope, the symbols were _not_ broken, some were missing as of the 1.1.10-1 version. I have added those back in the 1.2.0-2 package version. > Please rebuild chromium against snappy 1.2.0-2 to fix its broken symbol > dependencies. Because this chromium release has CVE fixes (and there's > 20-something pending CVEs in trixie already that would be fixed by > chromium migration), I'm filing this with a higher severity than usual. It is _not_ needed. the ABI of 1.2.0-1 is not changed in 1.2.0-2, I've even installed the new snappy library version and can still use chromium without problems. Do you experience any odd behaviour? Regards, Laszlo/GCS
Bug#979617: tcplay: VeraCrypt support
On Mon, Apr 22, 2024 at 8:33 PM Daniel Kahn Gillmor wrote: > On Sun 2024-04-21 15:44:12 +0200, László Böszörményi (GCS) wrote: > > I prefer communication first. :) Currently I'm travelling so I can > > only check it on Tuesday. > > That's why i uploaded to DELAYED/15 :) thanks for offering to take a > look at it later this week, László! I meant to reach a consensus first and then do the upload. There's no point in an upload that needs to be cancelled. Best, Laszlo/GCS
Bug#979617: tcplay: VeraCrypt support
Hi, On Sun, Apr 21, 2024 at 9:06 AM Daniel Kahn Gillmor wrote: > I've just confirmed what Johannes said about tcplay 3.3 building easily > on debian. I uploaded 3.3-0.1 to unstable as an NMU to DELAYED/15, > after cleaning up the packaging a little bit. [...] > Hopefully this NMU is welcomed in the helpful spirit i intended with it! > But if you think it's a bad idea, I don't mind it being NACK'ed. In the > course of doing the cleanup i noticed a few weird things about the > packaging for libtcplay, that i wasn't sure how to best fix, so i just > recorded them in the BTS. I prefer communication first. :) Currently I'm travelling so I can only check it on Tuesday. > I've also tested a backported version of 3.3-0.1 to debian stable, and > it seems to work fine to create an interoperable VeraCrypt volume > (methodology described below). There were some license problems in the past at least, which prevented packaging. I will check the current situation. Regards, Laszlo/GCS
Bug#1067407: graphviz: diff for NMU version 2.42.2-8.1
Control: tags -1 +moreinfo On Thu, Mar 21, 2024 at 12:39 PM Gianfranco Costamagna wrote: > I've prepared an NMU for graphviz (versioned as 2.42.2-8.1) and > uploaded it to DELAYED/2. Please feel free to cancel it directly if you want > to do a maintainer upload. I do not see the point of this. Can you please recheck the current graphviz package state and report back to me? Regards, Laszlo/GCS
Bug#1067407: graphviz: FTBFS due to -Wimplicit-declaration gcc flag
Hi Gianfranco, On Thu, Mar 21, 2024 at 9:09 AM Gianfranco Costamagna wrote: > Hello, looks like the package will FTBFS due to newly introduced > implicit-declaration flag > I did cherry-pick two upstream patches and the package now build successfully. When that '-Wimplicit-declaration' is going to be set? I'm a bit confused, you may mix it with '-Werror=implicit-function-declaration' which was already patched five days ago. Can you recheck your findings and add more information? Thanks, Laszlo/GCS
Bug#1062465: ivykis: NMU diff for 64-bit time_t transition
Hi Graham, On Thu, Feb 1, 2024 at 5:03 PM Graham Inggs wrote: > Source: ivykis > Version: 0.42.4-1 [...] > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. My only question is if it would be OK for you if I package the new ivykis upstream release to experimental as 0.43-1~exp1 over your changes of course? Regards, Laszlo/GCS
Bug#1060753: exiftags: CVE-2023-50671
Hi Salvatore, On Sat, Jan 13, 2024 at 5:51 PM Salvatore Bonaccorso wrote: > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. I have fixed some issues, but as I see, not the root causes. Then with my fixes I found that the reproducers may crash exiftags later by other issues. Contacted upstream if he plans to fix these by himself. Waiting for his reply. Regards, Laszlo/GCS
Bug#1027876: protobuf: package is missing CMake files
On Wed, Jan 4, 2023 at 11:36 AM André Apitzsch wrote: > CMake has difficulties to keep up compatibility with the CMake files > provided by Protobuf, therefore it is considered to deprecate > FindProtobuf in CMake [1] in favor of CMake files provided by Protobuf. Thanks for the previous work on this. > One way to add the CMake files could be to switch from Autotools to > CMake or Bazel. These tools are recommended to build Protobuf from > source [2]. The instructions to build Protobuf with Autotools have been > removed [3]. Yup, that's true and the new Protobuf package, currently in 'experimental' is now built with CMake. Please check if it meets your requirements. It will take a while to make it to Sid, but please report back if you find any issues. Regards, Laszlo/GCS
Bug#1058099: pyro4: FTBFS: AttributeError: 'CoreTests' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'? debdiff for NMU
Hi Thomas, On Thu, Jan 11, 2024 at 4:57 PM Thomas Goirand wrote: > Please see attached diff to fix the issue. It's kind of trivial to fix, > as you may see... Could you please upload it to unstable ASAP, or allow > me to NMU this fix? I'll upload it ASAP. But what's your intention with keeping pyro4 in the archives? It is no longer developed and superseded with pyro5. Should be removed sooner than later. Regards, Laszlo/GCS
Bug#1060225: protobuf: Install proto_api.h
Control: forwarded -1 https://github.com/protocolbuffers/protobuf/issues/9464 Hi, On Sun, Jan 7, 2024 at 9:42 PM Kari Pahula wrote: > For some reason, protobuf doesn't apparently install > python/google/protobuf/proto_api.h anywhere. For example > https://github.com/pybind/pybind11_protobuf uses it with an #include > which it assumes to find under "python" directory after fetching it > with cmake. For packaging use that won't work and it'd help to have > it available in protobuf's packages. It has been left out since at least 3.14 on purpose. See the issue this report is forwarded to. I do not plan to force install it for the package. Regards, Laszlo/GCS
Bug#1059161: RFA: pypdf -- Pure-Python library built as a PDF toolkit (Python 3)
Package: wnpp Control: affects -1 + src:pypdf X-Debbugs-Cc: py...@packages.debian.org X-Debbugs-Cc: Daniel Kahn Gillmor Severity: normal I request an adopter for the pypdf package. The package description is: A Pure-Python library built as a PDF toolkit. It is capable of: - extracting document information (title, author, ...), - splitting documents page by page, - merging documents page by page, - cropping pages, - merging multiple pages into a single page, - encrypting and decrypting PDF files. . By being Pure-Python, it should run on any Python platform without any dependencies on external libraries. It can also work entirely on StringIO objects rather than file streams, allowing for PDF manipulation in memory. It is therefore a useful tool for websites that manage or manipulate PDFs. . This is the Python 3 version of the package.
Bug#1059160: RFA: pypdf2 -- Pure-Python library built as a PDF toolkit (Python 3)
Package: wnpp Control: affects -1 + src:pypdf2 X-Debbugs-Cc: pyp...@packages.debian.org X-Debbugs-Cc: Daniel Kahn Gillmor Severity: normal I request an adopter for the pypdf2 package. The package description is: A Pure-Python library built as a PDF toolkit. It is capable of: - extracting document information (title, author, ...), - splitting documents page by page, - merging documents page by page, - cropping pages, - merging multiple pages into a single page, - encrypting and decrypting PDF files. . By being Pure-Python, it should run on any Python platform without any dependencies on external libraries. It can also work entirely on StringIO objects rather than file streams, allowing for PDF manipulation in memory. It is therefore a useful tool for websites that manage or manipulate PDFs. . This is the Python 3 version of the package.
Bug#1059026: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Hi RMs, Small transition of RocksDB to the 8.9.1 release, available from experimental. Affected packages are balboa, oxigraph and sortmerna. While oxigraph is Sid only currently, all three build fine with this version of RocksDB as well. Thanks for considering, Laszlo/GCS
Bug#1057889: graphviz_10.0.0~git231209-1_riscv64-buildd.changes REJECTED
Control: tags -1 +confirmed pending On Sun, Dec 10, 2023 at 10:33 AM Aurelien Jarno wrote: > On 2023-12-10 07:05, Debian FTP Masters wrote: > > graphviz-tools_10.0.0~git231209-1_riscv64.deb: has 1 file(s) with a > > timestamp= > > too far in the past: > > usr/share/doc/graphviz-tools/copyright (Thu Jan 1 00:01:00 1970) Seems I updated my Bookworm system too soon and hit the ext4 corruption bug in the kernel as noted in #1057843. Luckily an fsck corrected my filesystem and package update is in progress. Regards, Laszlo/GCS
Bug#1055944: bookworm-pu: package vips/8.14.1-3+deb12u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm Severity: normal Control: affects -1 + src:vips Hi RMs, [ Reason ] A specially crafted SVG input can cause libvips versions 8.14.3 or earlier to segfault when attempting to parse a malformed UTF-8 character. It is considered a security issue and has the CVE-2023-40032 identifier. [ Impact ] It is an application crash and can't be used for more. Hence the Security Team decided it doesn't get a DSA. But it would be nice to get the package updated. [ Tests ] Upstream testsuite and Sid update doesn't report any regressions. [ Risks ] The proposed change has very little risk of side-effects. [ Checklist ] [x] *all* changes are documents in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in bookworm [x] the issue is verified as fixed in unstable Thanks for considering, Laszlo/GCS diff -Nru vips-8.14.1/debian/changelog vips-8.14.1/debian/changelog --- vips-8.14.1/debian/changelog 2023-02-13 10:48:58.0 +0100 +++ vips-8.14.1/debian/changelog 2023-11-14 16:05:39.0 +0100 @@ -1,3 +1,10 @@ +vips (8.14.1-3+deb12u1) bookworm; urgency=medium + + * Backport upstream security fix for CVE-2023-40032: svgload: fix +null-pointer dereference. + + -- Laszlo Boszormenyi (GCS) Tue, 14 Nov 2023 16:05:39 +0100 + vips (8.14.1-3) unstable; urgency=medium * Double self-testing timeout on mips64el and mipsel architectures. diff -Nru vips-8.14.1/debian/patches/CVE-2023-40032.patch vips-8.14.1/debian/patches/CVE-2023-40032.patch --- vips-8.14.1/debian/patches/CVE-2023-40032.patch 1970-01-01 01:00:00.0 +0100 +++ vips-8.14.1/debian/patches/CVE-2023-40032.patch 2023-11-14 16:05:39.0 +0100 @@ -0,0 +1,71 @@ +From e091d65835966ef56d53a4105a7362cafdb1582b Mon Sep 17 00:00:00 2001 +From: Kleis Auke Wolthuizen +Date: Sun, 13 Aug 2023 15:48:54 +0200 +Subject: [PATCH] svgload: fix null-pointer dereference (#3604) + +`g_utf8_find_next_char()` might return NULL when called with a +non-NULL second argument, indicating that the end of the string +has been reached. +--- + ChangeLog | 4 + libvips/foreign/svgload.c | 18 +++--- + 2 files changed, 19 insertions(+), 3 deletions(-) + +diff --git a/ChangeLog b/ChangeLog +index e47ee86bb4..b7544219e5 100644 +--- a/ChangeLog b/ChangeLog +@@ -1,3 +1,7 @@ ++TBD 8.14.4 ++ ++- fix null-pointer dereference during svgload [kleisauke] ++ + TBD 8.14.2 + + - dedupe FITS header write [ewelot] +diff --git a/libvips/foreign/svgload.c b/libvips/foreign/svgload.c +index 94072581d4..aefd412ed2 100644 +--- a/libvips/foreign/svgload.c b/libvips/foreign/svgload.c +@@ -145,7 +145,7 @@ vips_foreign_load_svg_zfree( void *opaque, void *ptr ) + /* Find a utf-8 substring within the first len_bytes (not characters). + * + * - case-insensitive +- * - needle must be zero-terminated, but hackstack need not be ++ * - needle must be zero-terminated, but haystack need not be + * - haystack can be null-terminated + * - if haystack is shorter than len bytes, that'll end the search + * - if we hit invalid utf-8, we return NULL +@@ -191,11 +191,14 @@ vips_utf8_strcasestr( const char *haystack_start, const char *needle_start, + b == (gunichar) -2 ) + return( NULL ); + +-/* End of haystack. There can't be a complete needle +- * anywhere. ++/* Disallow codepoint U+ as it's a nul byte. ++ * This is redundant with GLib >= 2.63.0, see: ++ * https://gitlab.gnome.org/GNOME/glib/-/merge_requests/967 + */ ++#if !GLIB_CHECK_VERSION( 2, 63, 0 ) + if( a == (gunichar) 0 ) + return( NULL ); ++#endif + + /* Mismatch. + */ +@@ -205,6 +208,15 @@ vips_utf8_strcasestr( const char *haystack_start, const char *needle_start, + haystack_char = + g_utf8_find_next_char( haystack_char, + haystack_start + len_bytes ); ++ ++/* End of haystack. There can't be a complete needle ++ * anywhere. ++ */ ++if( haystack_char == NULL ) ++return( NULL ); ++ ++/* needle_char will never be NULL. ++ */ + needle_char = + g_utf8_find_next_char( needle_char, NULL ); + } diff -Nru vips-8.14.1/debian/patches/series vips-8.14.1/debian/patches/series --- vips-8.14.1/debian/patches/series 2023-02-12 08:52:21.0 +0100 +++ vips-8.14.1/debian/patches/series 2023-11-14 16:05:39.0 +0100 @@ -1,2 +1,3 @@ dedupe_fits_header.patch fix_target_pnm_write.patch +CVE-2023-40
Bug#1055762: ITP: botan3 -- multiplatform crypto library (3.x version)
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: botan Version : 3.2.0 Upstream Author : The Botan Authors * URL : https://botan.randombit.net/ * License : BSD-2-clause Programming Lang: C++ Description : multiplatform crypto library (3.x version) Botan is a C++ library which provides support for many common cryptographic operations, including encryption, authentication, and X.509v3 certificates and CRLs. A wide variety of algorithms is supported, including RSA, DSA, DES, AES, MD5, and SHA-1.
Bug#1055222: fuse: backport unprivileged usage via /dev/fd/N to support usage in namespaces
Hi Helmut, On Mon, Nov 6, 2023 at 11:28 AM Helmut Grohne wrote: > On Sun, Nov 05, 2023 at 02:19:18PM +0100, László Böszörményi (GCS) wrote: > > Yes, it makes upstreams more easily staying with the FUSE 2 API. > > Making the switch to the FUSE 3 API more difficult. But OK, let it go. > > I'm preparing the upload. > > Thank you. Just for the record, the change broke self-testing of gphotofs big on all architectures. It fails with: autopkgtest: test command1: [ "$(./gphotofs 2>&1)" == 'fuse: missing mountpoint parameter' ] 165s command1 FAIL non-zero exit status 1 Will try to check and fix it. Regards, Laszlo/GCS
Bug#1055456: pyutilib: port to Pyro5
Source: pyutilib Version: 6.0.0-1 Severity: important Tags: trixie Usertags: pyro4-rm Control: affects -1 + src:pyro4 Hi, The development of Pyro4 has ended [1]. As I see, your upstream is also dead. Please port the source to Pyro5 [2], already packaged for Debian. If you don't have the skills for the port, at least remove your 'recommends' on Pyro4 - as I understand your package will still have functionality. Regards, Laszlo/GCS [1] https://github.com/irmen/Pyro4/commit/8ec0db055d76ae1512239710b1e30883ee6bd74b [2] https://pyro5.readthedocs.io/en/latest/
Bug#1055457: pyxrd: port to Pyro5
Source: pyxrd Version: 0.8.4-3 Severity: important Tags: trixie Usertags: pyro4-rm Control: affects -1 + src:pyro4 Hi, The development of Pyro4 has ended [1]. As I see, your upstream is also dead. Please port the source to Pyro5 [2], already packaged for Debian. Otherwise as Pyro4 can break anytime with newer Python versions, you risk your package being removed from the archives. Regards, Laszlo/GCS [1] https://github.com/irmen/Pyro4/commit/8ec0db055d76ae1512239710b1e30883ee6bd74b [2] https://pyro5.readthedocs.io/en/latest/
Bug#1042648: pyro4: FTBFS with Sphinx 7.1, docutils 0.20: rm: cannot remove '/<>/debian/pyro4-doc/usr/share/doc/pyro4-doc//html/_static/underscore.js': No such file or directory
Hi Thomas, On Mon, Nov 6, 2023 at 2:27 PM Thomas Goirand wrote: > FYI, simply removing from d/rules: [...] > fixes the build. Can this be done and uploaded ASAP please? Or > alternatively, is this OK for an NMU? I'm going to fix this right now. On the other hand, why is it so important for you? Pyro4 is dead for a while. Last update was for Python 3.10 (the archive has the default of 3.11). See upstream note that development halted, repository is archived [1]. Regards, Laszlo/GCS [1] https://github.com/irmen/Pyro4/commit/8ec0db055d76ae1512239710b1e30883ee6bd74b
Bug#1055222: fuse: backport unprivileged usage via /dev/fd/N to support usage in namespaces
Hi Helmut, On Thu, Nov 2, 2023 at 12:15 PM Helmut Grohne wrote: > I have a slightly unusual request. I know libfuse 2.x is a legacy in > maintenance mode slated for removal eventually. Unfortunately, 2/3 of > fuse users still use the 2.x branch so it seems like we will have to > support it a bit longer than expected. I think distributions should do the opposite, somehow enforce projects to migrate to the new, supported FUSE version. Basically it is deprecated since 2018 and as 2024 is approaching it means for six years. > Unfortunately, this currently requires fuse >= 3.3 and e.g. fuse2fs from > e2fsprogs still uses fuse 2.x. Last time Ted Ts'o was inquired about > porting to 3.x, he was unenthusiastic and when I spent a look, it is > quite non-trivial as the API changed a lot. It's not just fuse2fs that > is affected but still 2/3 of drivers. [...] > So I think we should backport this into fuse 2.x. This is not to say > that we should stop porting drivers to the 3.x API. It also slightly > improves compatibility between 2.x and 3.x, so that seems like a sane > trade-off to me. Do you agree? Yes, it makes upstreams more easily staying with the FUSE 2 API. Making the switch to the FUSE 3 API more difficult. But OK, let it go. I'm preparing the upload. Regards, Laszlo/GCS
Bug#1054806: git-cola: FTBFS: sed: can't read /<>/debian/git-cola/usr/lib/python3*/site-packages/cola/widgets/spellcheck.py: No such file or directory
Hi David, On Sat, Oct 28, 2023 at 6:39 AM David Aguilar wrote: > This step in the build log looks suspicious: > > sed -i 's|env python|env python3|' \ > > /<>/debian/git-cola/usr/lib/python3*/site-packages/cola/widgets/spellcheck.py Yes, this is the culprit and already fixed locally. > Another note is that 3.12.0 is a very old version. Newer versions have > the python3 shebangs. That's probably related. Then newer versions also have a new dependency that is not (yet) packaged for Debian. I don't have time for that as if I remember correctly it is something uncommon. I think I will let git-cola go. Regards, Laszlo/GCS
Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps
Hi Daniel, On Wed, Oct 18, 2023 at 10:09 PM Daniel Gröber wrote: > Seems -Tpdf doesn't work for with 9.0 some reason, is a configure option > for that missing perhaps?: You need to install the libgvplugin-pango as well. Please do it and test your case again. But my own testing shows CreationDate is still embedded in PDF files generated by graphviz. Cheers, Laszlo/GCS
Bug#1054170: graphviz: dot generates unreproducible pdfs with embedded timestamps
Hi Daniel, On Wed, Oct 18, 2023 at 5:45 PM Daniel Gröber wrote: > dot appears to embed CreationDate in the pdf and this cannot be > controlled with SOURCE_DATE_EPOCH. Can you please test it with the Graphviz version 9.0 in experimental? I don't expect it to be different, but I would like to be sure. Thanks, Laszlo/GCS
Bug#1053663: libraft2: Consider switching upstream to cowsql/raft
Hi Free, On Sat, Oct 14, 2023 at 11:30 AM Free Ekanayaka wrote: > Am I missing something? If there's consenus about this, I'd finalize the > changelog and start uploading raft-0.17.7-1. Looks OK to me. Just a question if you tested building of raft with pbuilder. I've packaged your raft version 0.17.6 locally and it still hangs with the last output of 'PASS: test/unit/uv' when tried building with pbuilder. Cheers, Laszlo/GCS
Bug#1053692: [graphicsmagick:discussion] Re: Any plans to add HEIC format?
Control: forwarded -1 https://github.com/strukturag/libheif/issues/974 Hi, On Sun, Oct 8, 2023 at 10:09 PM Dan Jacobson wrote: > Hello. The viewnior and gpicview packages support heic, so should gm. > On 2023-10-08 08:08, Bob Friesenhahn wrote: > > On Sat, 7 Oct 2023, Dan Jacobson wrote: > >> $ gm convert -list formats |fgrep -i heif > >> AVIF P r-- HEIF Image Format (heif v16.2.0) > >> HEIC P r-- HEIF Image Format (heif v16.2.0) > >> HEIF P r-- HEIF Image Format (heif v16.2.0) > >> $ gm convert -debug coder,exception C001.heic info:- > >> 18:35:16 0:0.002526 0.000u 3249 constitute.c/ReadImage/1676/Coder: > >> Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0 > >> 18:35:16 0:0.010894 0.010u 3249 heif.c/ReadHEIFImage/571/Coder: > >> Geometry: 1280x720 > >> 18:35:16 0:0.011036 0.010u 3249 heif.c/ReadHEIFImage/573/Coder: > >> Matte: False > >> 18:35:16 0:0.011135 0.010u 3249 heif.c/ReadHEIFImage/650/Coder: > >> heif_decode_image() reports error "Unsupported feature: Unsupported > >> codec" > > > > From the above, I deduce that libheif from Debian Sid does not support > > HEIC, or a sub-feature of HEIC. It is possible that Debian Sid > > binaries do not include support for HEIC at all. It's up to the new HEIF library which broke other packages including GM, GIMP, etc. See the relevant bug report in Debian [1]. Its upstream stated to solve this, but it seems not the case [2]. That's why GM and others can't use the mentioned display formats. Regards, Laszlo/GCS [1] https://bugs.debian.org/1041242 [2] https://github.com/strukturag/libheif/issues/974
Bug#1053663: libraft2: Consider switching upstream to cowsql/raft
Hi Free, On Sun, Oct 8, 2023 at 12:09 PM Free Ekanayaka wrote: > The canonical/dqlite and canonical/raft projects on GitHub have also > been forked into cowsql/cowsql and cowsql/raft respectively: [...] > I'm the original upstream author of dqlite and its C raft library, and > after having left Canonical I tried for quite some time to collaborate > with them on dqlite, but I always felt there was not much interest in > having it be a real "community" project, so after LXD was forked I > decided to fork dqlite too. Bit strange, I heard good things about Canonical and I respect their work. OK, currently I can't build 'raft' on Debian, a bug is reported [1] and upstream working on it. Fedora has a patch, which I haven't tried yet. > While I could not keep the name "dqlite" (which is a trademark of > Canonical), the name "raft" is just the name of an algorithm, so it I > haven't changed it. > > I'm also a Debian Developer, and I'd like to propose to switch the > upstream of the libraft package from canonical/raft to cowsql/raft, > instead of having to upload a separate package with a different name or > alternatively vendoring cowsql/raft into cowsql/cowsql. I would be happier if you two can join forces - software development is a long task, you need to take care of it for years to come. I'm open to switching to cowsql/raft as you are the original upstream author. Hope you will find long term contributors to the project. > The cowsql/raft library is compatible with canonical/raft so there would > be no disruption for users and for reverse dependencies. I don't expect > this compatibilty to be an issue for the forseeble future (e.g. during > the Trixie cycle). That's a good promise, I say let's go with it then. > I'd also like to help with maintainership of both src:dqlite and the > re-upstreamed src:raft in Debian, making sure that things work as > expected. This is also accepted, you can open a project on Salsa and either start a project group or just make yourself the maintainer and me as an uploader. But the former might be better as I think Mathias might like to join. Cheers, Laszlo/GCS
Bug#1053608: bullseye-pu: zeromq3/4.3.4-1+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: sdu...@centreon.com Control: affects -1 + src:zeromq3 Hi RMs, [ Reason ] I got a bug report that fork() is not detected correctly for zeromq3 when GCC 7 or 8 is used [1]. [ Impact ] For some workflows it causes an assertion which was reported upstream [2] and fixed [3]. The fix is applied and a package update is prepared, debdiff is attached to this email. [ Tests ] Upstream testsuite still works. The build log now contains the positive changelog message that fork() is now detected correctly. [ Risks ] Very little as the change is not a source change but a configure check fix. With newer GCC versions (ie Bookworm and later) the configure check works and fork() is used as expected. [ Checklist ] [x] *all* changes are documents in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in bullseye [x] the issue is verified as fixed in unstable Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1053448 [2] https://github.com/zeromq/libzmq/issues/3313 [3] https://github.com/zeromq/libzmq/commit/5a9c174dab9f8f7cd675360db2af302cb48d961a diff -Nru zeromq3-4.3.4/debian/changelog zeromq3-4.3.4/debian/changelog --- zeromq3-4.3.4/debian/changelog 2021-02-03 08:46:36.0 +0100 +++ zeromq3-4.3.4/debian/changelog 2023-10-07 11:22:30.0 +0200 @@ -1,3 +1,9 @@ +zeromq3 (4.3.4-1+deb11u1) bullseye; urgency=medium + + * Apply fix for fork() detection on GCC 7 (closes: #1053448). + + -- Laszlo Boszormenyi (GCS) Sat, 07 Oct 2023 11:22:30 +0200 + zeromq3 (4.3.4-1) unstable; urgency=medium * New upstream release. diff -Nru zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch --- zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch 1970-01-01 01:00:00.0 +0100 +++ zeromq3-4.3.4/debian/patches/fix_fork_detection_with_gcc_7.patch 2023-10-07 11:22:30.0 +0200 @@ -0,0 +1,85 @@ +From 240e36af4e0300a529c99b0a05c4bf391bbcd6f5 Mon Sep 17 00:00:00 2001 +From: David Gloe +Date: Tue, 23 Nov 2021 15:39:42 + +Subject: [PATCH 1/2] Problem: Fix fork detection on gcc 7 + +Solution: When compiling with gcc 7 and newer, the program produced by +AC_CHECK_FUNCS(fork) produces a warning, which results in configure +incorrectly disabling fork support. Fix the issue by using an +AC_COMPILE_IFELSE which correctly detects fork availability. +Tested by running configure and make check on a system with gcc 7 +installed, and verifying that HAVE_FORK was defined correctly. + +See issue #3313. +--- + configure.ac | 19 --- + 1 file changed, 16 insertions(+), 3 deletions(-) + +diff --git a/configure.ac b/configure.ac +index 227e37b488..1a571291eb 100644 +--- a/configure.ac b/configure.ac +@@ -771,9 +771,24 @@ AC_LANG_POP([C++]) + + # Checks for library functions. + AC_TYPE_SIGNAL +-AC_CHECK_FUNCS(perror gettimeofday clock_gettime memset socket getifaddrs freeifaddrs fork mkdtemp accept4) ++AC_CHECK_FUNCS(perror gettimeofday clock_gettime memset socket getifaddrs freeifaddrs mkdtemp accept4) + AC_CHECK_HEADERS([alloca.h]) + ++# AC_CHECK_FUNCS(fork) fails on gcc 7 ++AC_MSG_CHECKING([whether fork is available]) ++AC_COMPILE_IFELSE( ++ [AC_LANG_PROGRAM( ++ [[#include ]], ++ [[return fork();]]) ++ ],[ ++ AC_MSG_RESULT([yes]) ++ AC_DEFINE(HAVE_FORK, [1], [fork is available]) ++ AM_CONDITIONAL(HAVE_FORK, true) ++ ],[ ++ AC_MSG_RESULT([no]) ++ AM_CONDITIONAL(HAVE_FORK, false) ++]) ++ + # string.h doesn't seem to be included by default in Fedora 30 + AC_MSG_CHECKING([whether strnlen is available]) + AC_COMPILE_IFELSE( +@@ -971,8 +986,6 @@ LIBZMQ_CHECK_GETRANDOM([ + [Whether getrandom is supported.]) + ]) + +-AM_CONDITIONAL(HAVE_FORK, test "x$ac_cv_func_fork" = "xyes") +- + if test "x$cross_compiling" = "xyes"; then + # Enable draft by default when cross-compiling + defaultval=yes + +From 72b5359049664458e117f2609d174dc5213fc19b Mon Sep 17 00:00:00 2001 +From: David Gloe +Date: Tue, 23 Nov 2021 16:27:52 + +Subject: [PATCH 2/2] Problem: Missing relicense statement for dgloe-hpe + +Solution: Add new author to the existing HPE relicense statement. +--- + RELICENSE/hewlett_packard_enterprise.md | 6 -- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/RELICENSE/hewlett_packard_enterprise.md b/RELICENSE/hewlett_packard_enterprise.md +index 9a0741984d..067ce39cbc 100644 +--- a/RELICENSE/hewlett_packard_enterprise.md b/RELICENSE/hewlett_packard_enterprise.md +@@ -5,9 +5,11 @@ that grants permission to relicense its copyrights in the libzmq C++ + library (ZeroMQ) under the Mozilla Public License v2 (MPLv2). + + A portion of the commits made by the Github handle "brc859844", with +-commit author "Brett Cameron &
Bug#1052026: transition: thrift
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:thrift Hi RMs, Small transition to 0.19.0 release of thrift. The only reverse dependency is gnuradio which builds fine with the new thrift release. There are two things to consider. First is that gnuradio is also involved in the fmtlib, qwt and boost1.81 transitions as well. Then it is scheduled to be removed from testing on 14th of October due to depending on bladerf which has an open RC bug [1].with a patch since the end of August. Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1050943
Bug#1050676: enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph: Assertion `np->cells[0]' failed.
Hi Andreas, On Sun, Sep 10, 2023 at 9:21 PM Andreas Metzler wrote: > I tried to do a test build of enblend against graphviz 8.1.0 from > experimental. I had no luck, since dot seems to be built without support > for png output: Please try graphviz 9.0.0 from experimental. > /usr/bin/m4 --fatal-warnings --prefix-builtins --synclines > --define='dot_output_type=png' ../../doc/uml-dot.m4 > ../../doc/external-mask-workflow.dot | \ > /usr/bin/dot -Tpng -Gbgcolor=transparent -Gresolution=600 | \ > /usr/bin/convert png:- -transparent white -resize $(( ((96 * > 1000) / 600) / 10 ))% external-mask-workflow.png > Format: "png" not recognized. Use one of: canon cmap cmapx cmapx_np dot > dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov > ps ps2 svg svgz tk xdot xdot1.2 xdot1.4 xdot_json > convert: improper image header > `/dev/shm/magick-u_9y0p39jcrUpQwvjHcDxiLBtxK8jlEu' @ > error/png.c/ReadPNGImage/4107. There's still a font issue, you will get something like: fontconfig: Didn't find expected font family. Perhaps URW Type 1 fonts need installing? I don't know why this is happening, as if I check the intermediate dot file then only the node font settings cause this error. Other uses of the Helvetica font are fine. As per source change, you will need this patch for enblend-enfuse. Please check if the resulting package works as you expected or not and report back your findings. Regards, Laszlo/GCS Description: use Times font instead of Helvetica for testing For testing the font Helvetica used. This is fine, but for some reason recently fontconfig can't find it as URW Type 1 font for dot nodes. For other uses, Helvetica font is found by the way. Author: Laszlo Boszormenyi (GCS) Forwarded: no Last-Update: 2023-09-15 --- --- enblend-enfuse-4.2.orig/doc/uml-dot.m4 +++ enblend-enfuse-4.2/doc/uml-dot.m4 @@ -10,7 +10,7 @@ m4_dnl (`uml_'), we treat only `Activit m4_dnl need more for the Enblend/Enfuse documentation. -m4_define(`uml_font', `Helvetica') +m4_define(`uml_font', `Times') m4_dnl Graph Attributes
Bug#1051515: raft: New version available
On Mon, Sep 11, 2023 at 6:40 PM Mathias Gibbens wrote: > I spent some time looking at this over the weekend, and apparently > there's some issue(s) running the integration/uv tests within a > continer(-ish) environment. While I may copy your report to an upstream bugreport, it's not my work. Would you please file an upstream issue yourself? I hope it will be an easy fix for them and raft can be updated soon in Debian. Thanks, Laszlo/GCS
Bug#1050676: enblend-enfuse: FTBFS: dot: maze.c:311: chkSgraph: Assertion `np->cells[0]' failed.
Hi, On Sun, Sep 10, 2023 at 9:21 PM Andreas Metzler wrote: > I tried to do a test build of enblend against graphviz 8.1.0 from > experimental. I had no luck, since dot seems to be built without support > for png output: It is/was due to another issue which is just fixed. But it is still a work in progress, not fully ready for user consumption. enblend-enfuse will still not build. Please give me some time to clear all graphviz issues. Regards, Laszlo/GCS
Bug#1051515: raft: New version available
Hi Mathias, On Sat, Sep 9, 2023 at 3:45 AM Mathias Gibbens wrote: > A new version of raft is available -- when able, could you please > upload the latest version to sid? Well, my constant problem is that I can't run its tests and can't find out the reason. If I build in a chroot then I get: Error: test/unit/test_uv_fs.c:320: assertion failed: rv_ == RAFT_IOERR (0 == 18) If I build it with pbuilder, then the last line I get is: PASS: test/unit/core but the build / testing never (at least not in a hour) finished (tried on two different machines). > Also, if you'd like I would be happy to help co-maintain this package > as an uploader, since it's a dependency of lxd. If you have time, please check the proposed package [1]. You may have more insights on what's the problem. Regards, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/raft_0.17.1-1.dsc
Bug#1034668: Please update to new upstream release 3.22.3 in experimental
On Thu, Sep 7, 2023 at 7:24 PM Benjamin Barenblat wrote: > I will do an upload of 20230802.0 to experimental today, but I don’t > think it fixes this issue. scoped_mock_log depends on symbols in > GoogleMock, but there’s no good way to express those dependencies in a > hypothetical libabsl_scoped_mock_log.so since libgmock.so doesn’t exist. Thanks for the upload and the information. I'm going to check it soon. > The way upstream (Google) intends for all this to work is for protobuf > to link its Abseil and GoogleMock dependencies statically. Is that > possible? It is possible, but not recommended. If abseil gets (security) fixes, protobuf will not get it like in the case of loading fresh shared libraries. Also it seems protobuf configure process looks for shared version of abseil. Need to double check. > If not, I have some alternative ideas (like building a > libabsl_scoped_mock_log.so without a DT_NEEDED entry for GoogleMock), > but they all seem like hacks. I’m also open to other ideas if anybody > has them. I'm not sure how to handle this properly for everyone. I think I will solve this on the protobuf side. Use static linking with abseil and record with the build process which version was used. The hard way would be to bundle an abseil source tarball with protobuf and use its shared version of libraries from a private location only for protobuf. The first should get precedence for which abseil should export static linking possibilities of scoped_mock_log in its cmake files. Regards, Laszlo/GCS
Bug#1012864: graphviz: new upstream version 7.0.0 is available
Control: severity 1012864 normal Control: merge 1012864 1051351 Hi, On Wed, Aug 9, 2023 at 12:55 AM László Böszörményi (GCS) wrote: > On Tue, Aug 8, 2023 at 6:30 PM Benjamin Redelings > wrote: > > Perhaps an upload to experimental could be done? Then people could use > > that while you are getting advice from upstream on packaging 8.1. > Indeed, that's the plan. I need some days for further testing. This will happen in minutes. Please note it needs manual acceptance from the FTP Masters which may take a while. Regards, Laszlo/GCS
Bug#1051351: graphviz: Please package a new upstream version
Hi Eugene, On Wed, Sep 6, 2023 at 8:36 PM Eugene Toder wrote: > It appears that the upstream version of graphviz was last updated in > September 2019, i.e. almost 4 years ago. Several new versions were > released since then with many bug fixes. Please package a new version. I've already received several reports of this. As noted in these, I've the newest package version v8.1.0 ready [1]. As it's a big upstream release and I've split the original; packages to several others it needs testing. Some of it is already done, but I look forward your findings if any. In short, I think I should upload it to experimental to make it more visible for you, end users. Regards, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/graphviz_8.1.0-1.dsc
Bug#1034668: Please update to new upstream release 3.22.3 in experimental
Hi Nilesh, Benjamin, On Sat, Jul 22, 2023 at 5:06 AM Nilesh Patra wrote: > On Thu, 27 Apr 2023 19:59:38 +0530 Pirate Praveen > wrote: > > Target "tests" links to: > > > >absl::scoped_mock_log > > > > but the target was not found. Possible reasons include: The reason is that it and protobuf 3.24.2 need abseil 20230125.0 or newer. While it is available in experimental, it doesn't export scoped_mock_log targets for cmake. Hence it is not found, I don't know if newer versions like 20230802.0 fix this issue or not. Can you comment on this Benjamin and if you are going to package it soon and/or accept someone as a co-maintainer for abseil? It seems abseil 20230802.0 became available and should be packaged. > Now, the release of abseil in experimental seems to be doing that, but > only for the static library and not the shared library, because it needs > googltest for the same, and googletest does not vendor any shared > library because the SO lib is not maintained properly upstream[2] [...] [...] > This was straightforward was to add "-Dprotobuf_BUILD_TESTS=OFF" to > configure options. Building without tests are always a bad idea. > PS: Sponsor me a party/dinner when? If you are at DebConf, we may talk and eat together. Regards, Laszlo/GCS
Bug#1051380: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Hi RMs, Small transition of rocksdb as only two packages are affected: balboa and sortmerna. Both build fine with the 8.5.3 version of rocksdb already in experimental. Only thing to mention is that the testing version of sortmerna doesn't build with the new rocksdb version - but as I know it doesn't cause any issue as binNMUs happen in unstable. Thanks for considering, Laszlo/GCS
Bug#1051325: sortmerna: FTBFS: concurrentqueue.h: No such file or directory
Source: sortmerna Version: 4.3.6-2 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs Hi, During a rebuild of your package for RocksDB transition your package fails to build on amd64. Relevant lines: In file included from /build/sortmerna-4.3.6/src/sortmerna/paralleltraversal.cpp:57: /build/sortmerna-4.3.6/include/readsqueue.hpp:49:12: fatal error: concurrentqueue/concurrentqueue.h: No such file or directory 49 | # include |^~~ compilation terminated. make[3]: *** [src/sortmerna/CMakeFiles/smr_objs.dir/build.make:233: src/sortmerna/CMakeFiles/smr_objs.dir/paralleltraversal.cpp.o] Error 1 make[3]: *** Waiting for unfinished jobs In file included from /build/sortmerna-4.3.6/src/sortmerna/output.cpp:49: /build/sortmerna-4.3.6/include/readsqueue.hpp:49:12: fatal error: concurrentqueue/concurrentqueue.h: No such file or directory 49 | # include |^~~ compilation terminated. make[3]: *** [src/sortmerna/CMakeFiles/smr_objs.dir/build.make:205: src/sortmerna/CMakeFiles/smr_objs.dir/output.cpp.o] Error 1 In file included from /build/sortmerna-4.3.6/src/sortmerna/kseq_load.cpp:39: /build/sortmerna-4.3.6/include/kseq_load.hpp:63:12: error: 'uint64_t' has not been declared 63 |uint64_t number_total_read, |^~~~ /build/sortmerna-4.3.6/src/sortmerna/kseq_load.cpp:53:12: error: 'uint64_t' has not been declared 53 |uint64_t number_total_read, |^~~~ It seems the mentioned header moved to /usr/include/concurrentqueue/moodycamel/concurrentqueue.h ; please update your package. Regards, Laszlo/GCS
Bug#1050937: protobuf: FTBFS: ModuleNotFoundError: No module named 'tzdata'
Hi, On Sat, Sep 2, 2023 at 10:33 AM Gianfranco Costamagna wrote: > Hello, probably tzdata split in legacy made this package FTBFS. Seems to be the case. > Solutions are: > 1) fix the test to work with main tzdata It's Python 3.11 itself which can't handle tzdata related things. It has a proposed patch applied for the Debian package [1] but seems not fully tested / complete. > 2) add dependency on tzdata-legacy package No, it's Python which tries to import a module that doesn't exist. Static data has nothing to do with it. Will test with the mentioned patch removed Python package version. Regards, Laszlo/GCS [1] https://tracker.debian.org/news/1458326/accepted-python311-3115-3-source-into-unstable/
Bug#1050636: graphviz: Update to lua5.3
Control: tags -1 +pending On Sun, Aug 27, 2023 at 1:09 PM Bastian Germann wrote: > Please update your package to build with lua5.3 so we can drop v5.2 from the > archive. > The build system supports lua5.3 as well. I can build it with Lua 5.4 even, any reason not to use that? Regards, Laszlo/GCS
Bug#1050195: libwebsockets: Unfortunately the change from #977637 has been lost
Hi Joachim, On Mon, Aug 21, 2023 at 9:03 PM Joachim Zobel wrote: > Unfortunately the change that sets LWS_WITH_EXTERNAL_POLL to ON has been lost > together with the changelog entry for 4.0.20-2. Indeed, it's not enabled anymore. It's still don't recommended by its developers, the option itself states: option(LWS_WITH_EXTERNAL_POLL "Support external POLL integration using callback messages (not recommended)" OFF) I'm going to re-enable it, but you should refactor your code in the long run not to depend on it. Regards, Laszlo/GCS
Bug#1049383: google-perftools: please don't ship pprof from gperftools anymore
Hi Aliaksei, On Tue, Aug 15, 2023 at 4:33 AM Aliaksei Kandratsenka wrote: > please, note, that gperftools has old and unmaintained perl version of > pprof tool. We intend to drop it entirely in couple releases. Please > consider packaging much much improved version written in Go from > https://github.com/google/pprof Thanks for the heads-up. To help my work, please tag releases of the Go pprof tool for: - let me know how mature it is, - which commits are considered stable enough to package and distribute. Thanks, Laszlo/GCS
Bug#1043506: libvips-tools: vipsthumbnail makes black thumbnails or says "Unsupported codec"
Control: tags -1 +confirmed Control: reassign -1 libheif On Sat, Aug 12, 2023 at 9:12 AM Michael Moore wrote: > vipsthumbnail was working for me at least until the Bookworm release, it now > generates solid black thumbnails or an empty file. I don't know exactly when > it stopped working. > > The commands below are failing for all HEIC files I have tested with, > including files which I had previously generated thumbnails for, using > vipsthumbnail. > > You can get a sample image here: http://stuporglue.org/downloads/pie.HEIC Tested the following scenarios. 1) Backport vips from Sid to Bookworm and it still produced a good thumbnail. 2) Downgraded libheif in Sid to its Bookworm version and vips still produced a good thumbnail. Please note that libheif went from 1.15.1 to 1.16.2 and it was modularized. But even if I install all libheif1-plugin-* packages, vipsthumbnail can't get the image data from libheif. Seems it is already reported [1] or might be a bit different. Anyway, it seems libheif was not loading plugins in all cases. This is fixed in its upstream [2] and hopefully will be integrated into its packaging soon. Regards, Laszlo/GCS [1] https://bugs.debian.org/1041242 [2] https://github.com/strukturag/libheif/issues/914
Bug#1042025: thrift: FTBFS: dh_auto_test: error: make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2
Control: forwarded -1 https://issues.apache.org/jira/browse/THRIFT-5680 Hi Christoph, On Wed, Aug 9, 2023 at 8:27 PM Christoph Berg wrote: > > > (./testapplicationexception:892843): GLib-CRITICAL **: 07:16:59.134: Did > > > not see expected message GLib-GObject-WARNING **: value*out of range*type* > > > not ok /testapplicationexception/Properties/test - > > > GLib-GObject-FATAL-CRITICAL: value "-1" of type 'gint' is invalid or out > > > of range for property 'type' of type 'gint' > > > Bail out! [...] > Fwiw, there is a new 0.18.1 upstream version. Perhaps that works > better. It is already packaged for experimental and has the same build problem. Upstream knows this bug [1], assigned major priority to it but has not touched the issue since february. Regards, Laszlo/GCS [1] https://issues.apache.org/jira/browse/THRIFT-5680
Bug#1012864: graphviz: new upstream version 7.0.0 is available
Hi, On Tue, Aug 8, 2023 at 6:30 PM Benjamin Redelings wrote: > I tried running the following command, and it looks like there's an issue > where libtool has just recently removed a "Provides: libltdl7-dev" from > libtldl-dev. [...] > I was able to get around this problem by downgrading libltdl-dev and libltdl7 > from 2.4.7-7 to 2.4.7-5, but then I got some errors about usr/bin/smyrna > being missing. These are addressed in the upcoming 8.1.0 [1] update. Please note it's not yet finished, still addresses the above, contains upstream recommendations and a huge package split. > Perhaps an upload to experimental could be done? Then people could use that > while you are getting advice from upstream on packaging 8.1. Indeed, that's the plan. I need some days for further testing. Regards, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/graphviz_8.1.0-1.dsc
Bug#1012864: graphviz: new upstream version 7.0.0 is available
Hi, On Mon, Aug 7, 2023 at 4:39 PM Bo YU wrote: > I'm currently experiencing a demand from Debian users who > would like to upgrade this package. Really the upstream become very > active. Do you have plan to upgrade the package recently? I've already updated the package to 8.0.5 [1] to be exact. Going to further update it to 8.1.0 and accept upstream development advice. At this point I'm not looking for co-maintainers. Regards, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/graphviz_8.0.5-1.dsc
Bug#1041776: transition: libwebsockets
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:libwebsockets Hi RMs, This transition missed Bookworm, but now I would like to start it. All reverse dependencies are built correctly on amd64. I'm going to test i386 as well, but I do not expect any failure. Thanks for considering, Laszlo/GCS
Bug#1041511: ntfs-3g: Undocumented dependency on libbrotli-dev
Control: tags -1 +unreproducible +wontfix Control: severity -1 normal On Thu, Jul 20, 2023 at 3:57 AM Theodoric Stier wrote: > Source: ntfs-3g > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) [...] > This package build fails during the configure step if libbrotli-dev is not > installed. > It appears to be missing from BuildDep. It has nothing to do with ntfs-3g. I see three things: 1) You are changing the package to be non-official: -- cut -- dpkg-buildpackage: info: source package ntfs-3g dpkg-buildpackage: info: source version 1:2022.10.3-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Theodoric Stier -- cut -- 2) The package does not need and doesn't check for brotli. Your build log clearly show this: -- cut -- configure:14736: checking for gnutls >= 1.4. configure:14743: $PKG_CONFIG --exists --print-errors "gnutls >= 1.4.4" Package libbrotlienc was not found in the pkg-config search path. Perhaps you should add the directory containing `libbrotlienc.pc' to the PKG_CONFIG_PATH environment variable Package 'libbrotlienc', required by 'gnutls', not found Package 'libbrotlidec', required by 'gnutls', not found Package 'libzstd', required by 'gnutls', not found configure:14746: $? = 1 configure:14760: $PKG_CONFIG --exists --print-errors "gnutls >= 1.4.4" Package libbrotlienc was not found in the pkg-config search path. Perhaps you should add the directory containing `libbrotlienc.pc' to the PKG_CONFIG_PATH environment variable Package 'libbrotlienc', required by 'gnutls', not found Package 'libbrotlidec', required by 'gnutls', not found -- cut -- It is gnutls which needs brotli, not ntfs-3g. 3) Official gnutls28 packages don't build with brotli so it seems you have an unofficial one or you tampered with that as well. Regards, Laszlo/GCS
Bug#1040945: tiff: CVE-2023-3618
Hi Salvatore, On Thu, Jul 13, 2023 at 8:42 PM Salvatore Bonaccorso wrote: > On Wed, Jul 12, 2023 at 10:12:50PM +0200, László Böszörményi wrote: > > In short, it seems: > > - it's a non-dsa as only a crash in a CLI tool (which has end of life now), > > - doesn't affect the library, > > - while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable, > > 4.5.1-1 fixed this issue. > > > > But you may find it otherwise, I do not alter this report in the BTS. [...] > For about having the issue fixed: The problem I have is that upstream > has not yet closed the issue. Is it completely fixed and what is the > fixing commit? https://gitlab.com/libtiff/libtiff/-/issues/529 is > slight unhelpful on that front. Reason is simple. Upstream was fixing issues and probably was doing as they wanted. That is, there's another SIGSEGV issue [1] and it's in tiffcrop as well. Upstream fixed it and was going on with other fixes. Then maybe they couldn't reproduce the mentioned CVE issue and went on releasing v4.5.1 with several other CVE fixes [2]. There Timothy Lyanguzov commented that bug#529 probably will get a CVE id too, but he couldn't reproduce it with that Git HEAD. Answer is simple, the other SIGSEGV issue [1] fix solved this issue as well. As upstream probably didn't recognize and couldn't reproduce this SIGSEGV (anymore), it remained open. > Are you able to identify the fixing commit confirming it is done in > 4.5.1-1? Indeed, it is fixed for 4.5.1 and the fixing commit is b5c7d4c4e0ac16b5cfb11acaaeaa493334f8 [3]. Hope this clear things up, Laszlo/GCS [1] https://gitlab.com/libtiff/libtiff/-/issues/553 [2] https://gitlab.com/libtiff/libtiff/-/issues/533 [3] https://gitlab.com/libtiff/libtiff/-/commit/b5c7d4c4e0ac16b5cfb11acaaeaa493334f8
Bug#1040945: tiff: CVE-2023-3618
Hi Salvatore, On Wed, Jul 12, 2023 at 9:39 PM Salvatore Bonaccorso wrote: > Source: tiff > Version: 4.5.1-1 > CVE-2023-3618[0]: > | A flaw was found in libtiff. A specially crafted tiff file can lead > | to a segmentation fault due to a buffer overflow in the Fax3Encode > | function in libtiff/tif_fax3.c, resulting in a denial of service. [...] > Please adjust the affected versions in the BTS as needed. Done my quick testing. My experience is the following. 1) libtiff6 and libtiff-tools are both 4.5.1-1 (ie, Trixie): the tool reports several warnings, exists with 1 (non-zero) but doesn't segfault. Even tried with valgrind, still no segfault. 2) libtiff6 is 4.5.1-1 backported to Bookworm and libtiff-tools are not, ie it's 4.5.0-6 : the tool reports the same warnings like above, but this time it _does_ segfault. 3) If libtiff-tools also updated to 4.5.1-1 on Bookworm: it's like the first case, several warnings, non-zero exit code without a segfault. In short, it seems: - it's a non-dsa as only a crash in a CLI tool (which has end of life now), - doesn't affect the library, - while 4.5.0-6 (and in fact, at least from 4.5.0-1) is vulnerable, 4.5.1-1 fixed this issue. But you may find it otherwise, I do not alter this report in the BTS. Regards, Laszlo/GCS
Bug#1040609: traceroute.db.1: some remarks and editorial fixes for the manual
Hi Bjarni, On Fri, Jul 7, 2023 at 11:03 PM Bjarni Ingi Gislason wrote: > Package: traceroute > Version: 1:2.1.2-1 > Severity: minor > Tags: patch [...] > here are some notes and fixes for the man page. Thanks for all your work. Can you please: 1) Send your patch to traceroute upstream[1]? 2) Alternatively send me the patch as an attachment (do not paste it inline the email) and I will send your fixes upstream. Thanks, Laszlo/GCS [1] https://sourceforge.net/p/traceroute/patches/
Bug#1040639: transition: rocksdb
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:rocksdb Control: forwarded -1 https://release.debian.org/transitions/html/auto-rocksdb.html Hi RMs, Small transition for RocksDB as only two reverse dependencies are in the archives: balboa and sortmerna. Both build fine with the rocksdb 8.3.2-1 version already in experimental. The only thing you might wait for is that it's not yet started to build on mips64el. I don't expect any failure as it was built fine on other release architectures. Regards, Laszlo/GCS
Bug#1039521: Summarizing my proposed changes about the Java part of protobuf
On Thu, Jun 29, 2023 at 9:15 PM Pierre Gruet wrote: > Le 29/06/2023 à 18:41, László Böszörményi (GCS) a écrit : > > Do you have your proposed package somewhere? I would also like to > > check it with the updated protobuf package before uploading. > You can find it in the public repo > https://salsa.debian.org/pgt/protobuf Your package = genomicsdb but I guess it's in the med-team repo [1]. Cheers, Laszlo/GCS [1] https://salsa.debian.org/med-team/genomicsdb
Bug#1039521: Summarizing my proposed changes about the Java part of protobuf
Hi Pierre, On Wed, Jun 28, 2023 at 4:39 PM Pierre Gruet wrote: > - removing j2objc from the pom.xml so that rdeps don't look for this > Debian-unpackaged artifact (touches d/p/no_j2objc.patch); Thanks for all of your work on this! I see you added this as a patch, but not included in the series file. Meaning it will not be applied. It's just an oversight I guess. Other than that it looks good. Do you have your proposed package somewhere? I would also like to check it with the updated protobuf package before uploading. Thanks, Laszlo/GCS
Bug#918075: Some patches for dar
Hi John, On Mon, Jun 5, 2023 at 10:12 PM John Goerzen wrote: > If you are open to me taking over dar at this time, I would go ahead and > upload 2.7.9 (with my updates above) with the maintainer changed to me. I just ask for one thing. Please wait until Bookworm is released - probably this or next week. Then go ahead and take over dar. Regards, Laszlo/GCS
Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak
Hi, On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn wrote: > I am definitely able to confirm that memory consumption builds due to > invoking GetImageDepth() via a POSIX thread. The rate that it builds > is image sensitive since some images cause GetImageDepth() to perform > more OpenMP loops. Unfortunately I can not reproduce. My processor is an Intel K variant CPU, six cores and twelve threads, 64 Gb of RAM. GM is 1.3.40 with two security fixes backported, compiled with GCC v12.2.0. Tried with three PNG images, all memory consumption is static from the beginning. Do I need some special case of PNG files to experience this issue? > My own testing is under Ubuntu 20.04 using GCC 10. Do you think it might be a problem with another system component, a GCC optimization or this is fixed meanwhile? At least I do wonder why this issue is CPU / machine dependent. Regards, Laszlo/GCS
Bug#1019717: Display of an SVG file broken due to gsfonts transition
On Tue, May 23, 2023 at 9:45 PM Albrecht Dreß wrote: > I added the attached patch file to the Debian patches and re-build the > package, which now processes SVG files as expected, so this seems to be a fix. > > Also attached is the *very* ugly Python script I used to extract the URW font > paths from the Ghostscript config and to modify type-ghostscript.mgk.in - > maybe it is helpful. These fixes [1] you submitted look OK, let's loop-in the upstream developer. Thanks, Laszlo/GCS [1] https://bugs.debian.org/1019717#20
Bug#1019717: Display of an SVG file broken due to gsfonts transition
Hi Albrecht, Bob, [Written a day ago, forgot to send.] On Mon, May 22, 2023 at 6:51 PM Albrecht Dreß wrote: > The issue is still present in libgraphicsmagick-q16-3 v. 1.4+really1.3.40-4 > and makes using the library with the standard config files somehow unusable > as soon as any SVG with a "text" container is involved. It would be great if > a fix would be available before the final Bookworm release. It's an upstream bug; there was a gsfonts -> fonts-urw-base35 transition which resulted in different font files. But GM has the font names hardcoded. The default seems to be n019003l.pfb [1] and font variants are also hardcoded [2]. But the package fonts-urw-base35 has none of these pfb files. Not sure what to do at this point. Alter the font names in GM or ship the hardcoded fonts? Regards, Laszlo/GCS [1] http://hg.graphicsmagick.org/hg/GraphicsMagick/file/c41d8933edef/magick/nt_base.c#l1713 [2] http://hg.graphicsmagick.org/hg/GraphicsMagick/file/c41d8933edef/wmf/src/font.h#l82 [3] https://packages.debian.org/bookworm/all/fonts-urw-base35/filelist
Bug#1036449: unblock: vice/3.7.1+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 + src:vice Hi RMs, [ Reason ] My bad was still using non-official categories in desktop files. Now this is corrected. [ Impact ] Find shortcuts to emulation binaries in the right place finally for Bookworm. [ Tests ] Local check was made and already in Sid for a week. [ Risks ] None. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock vice/3.7.1+dfsg1-2 Thanks for considering, Laszlo/GCS diff -Nru vice-3.7.1+dfsg1/debian/changelog vice-3.7.1+dfsg1/debian/changelog --- vice-3.7.1+dfsg1/debian/changelog 2023-04-29 10:58:51.0 +0200 +++ vice-3.7.1+dfsg1/debian/changelog 2023-05-14 07:41:04.0 +0200 @@ -1,3 +1,10 @@ +vice (3.7.1+dfsg1-2) unstable; urgency=medium + + * Use valid Freedesktop.org categories for desktop files +(closes: #626518, #958959). + + -- Laszlo Boszormenyi (GCS) Sun, 14 May 2023 07:41:04 +0200 + vice (3.7.1+dfsg1-1) unstable; urgency=medium * Remove mps803.bin printer ROM from source (closes: #1035079). diff -Nru vice-3.7.1+dfsg1/debian/desktop/x128.desktop vice-3.7.1+dfsg1/debian/desktop/x128.desktop --- vice-3.7.1+dfsg1/debian/desktop/x128.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/x128.desktop 2023-05-13 23:20:01.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/c128icon-32x28.xpm Exec=/usr/bin/x128 Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/x64.desktop vice-3.7.1+dfsg1/debian/desktop/x64.desktop --- vice-3.7.1+dfsg1/debian/desktop/x64.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/x64.desktop 2023-05-13 23:20:07.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/c64icon-32x28.xpm Exec=/usr/bin/x64sc Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop --- vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xcbm2.desktop 2023-05-13 23:20:12.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/cbm2icon-32x28.xpm Exec=/usr/bin/xcbm2 Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xpet.desktop vice-3.7.1+dfsg1/debian/desktop/xpet.desktop --- vice-3.7.1+dfsg1/debian/desktop/xpet.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xpet.desktop 2023-05-13 23:20:16.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/peticon-32x28.xpm Exec=/usr/bin/xpet Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop --- vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xplus4.desktop 2023-05-13 23:20:32.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/plus4icon-32x28.xpm Exec=/usr/bin/xplus4 Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator; diff -Nru vice-3.7.1+dfsg1/debian/desktop/xvic.desktop vice-3.7.1+dfsg1/debian/desktop/xvic.desktop --- vice-3.7.1+dfsg1/debian/desktop/xvic.desktop 2022-02-02 17:44:26.0 +0100 +++ vice-3.7.1+dfsg1/debian/desktop/xvic.desktop 2023-05-13 23:20:35.0 +0200 @@ -63,4 +63,4 @@ Icon=/usr/share/pixmaps/vic20icon-32x28.xpm Exec=/usr/bin/xvic Terminal=false -Categories=Application;X-Debian-Applications-Emulators; +Categories=Game;Emulator;
Bug#1035556: expat: Generalize libbsd-dev build-dep on freebsd & hurd
Control: tags -1 +confirmed Hi, On Fri, May 5, 2023 at 1:39 PM Samuel Thibault wrote: > debian/rules is passing --with-libbsd for all kfreebsd & hurd ports, > debian/control should thus enable the build-dep for all of them, as the > attached patch does. This fixes building on hurd-amd64. Patch is correct, thanks for it. How soon do you need it? Current release is in freeze and hurd-amd64 is not even a port architecture for Debian. As such I don't think it will be allowed for Bookworm. Regards, Laszlo/GCS
Bug#1035339: unblock: vice/3.7.1+dfsg1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Control: affects -1 + src:vice Hi RMs, [ Reason ] Upstream source contains several ROM files for Commodore machines and floppy drives, including printers. All these have a size of 2k and multiples. A script under debian/ directory called mangle-source.sh remove those. There's a printer ROM file which turned out to be an exception to this size rule. Meaning this non-free file slipped to the source tree and to the package itself. This is filed as a serious bug [1] already. I've fixed it by removing the file and updating the removal script. [ Impact ] It will make the package DFSG free and users can still have it in Bookworm. [ Tests ] This file is unused for package build and only needed if someone would like to emulate the Commodore printer. That is, no extra tests are required. [ Risks ] Nothing. The change is only a file removal, replace it with the text 'dummy' and a source repack shell script update. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Uploaded, built on all architectures and package is working. unblock vice/3.7.1+dfsg1-1 Thanks for considering, Laszlo/GCS [1] https://bugs.debian.org/1035079 Binary files /tmp/Vc_Z6BwILs/vice-3.7.1+dfsg/data/PRINTER/mps803.bin and /tmp/e6SEihfSew/vice-3.7.1+dfsg1/data/PRINTER/mps803.bin differ diff -Nru vice-3.7.1+dfsg/debian/changelog vice-3.7.1+dfsg1/debian/changelog --- vice-3.7.1+dfsg/debian/changelog 2023-02-17 21:06:12.0 +0100 +++ vice-3.7.1+dfsg1/debian/changelog 2023-04-29 10:58:51.0 +0200 @@ -1,3 +1,9 @@ +vice (3.7.1+dfsg1-1) unstable; urgency=medium + + * Remove mps803.bin printer ROM from source (closes: #1035079). + + -- Laszlo Boszormenyi (GCS) Sat, 29 Apr 2023 10:58:51 +0200 + vice (3.7.1+dfsg-2) unstable; urgency=medium * Clarify license of CBM.ttf (closes: #1029260). diff -Nru vice-3.7.1+dfsg/debian/mangle-source.sh vice-3.7.1+dfsg1/debian/mangle-source.sh --- vice-3.7.1+dfsg/debian/mangle-source.sh 2023-01-14 20:56:30.0 +0100 +++ vice-3.7.1+dfsg1/debian/mangle-source.sh 2023-04-29 10:58:51.0 +0200 @@ -24,6 +24,9 @@ echo dummy > $FILE fi done + # non-standard size + rm data/PRINTER/mps803.bin + echo dummy > data/PRINTER/mps803.bin # replace non-free font echo replace font 1>&2 rm data/common/C64_Pro_Mono-STYLE.ttf 1>&2
Bug#1034646: [pre-approval] unblock: fuse3/3.14.0-4
Control: tags -1 -moreinfo On Thu, Apr 27, 2023 at 7:56 AM Paul Gevers wrote: > Please go ahead and remove the moreinfo tag once the upload happens. Thanks, uploaded and built on all architectures. Piuparts and package tests are done as well. Cheers, Laszlo/GCS
Bug#1034753: RM: paxctl -- RoM; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:paxctl Hi FTP Masters, Please remove src:paxctl as it's an old, outdated project in our archives. I've no intentions to keep it in Sid nor ship it with Bookworm. Thanks, Laszlo/GCS
Bug#1034646: [pre-approval] unblock: fuse3/3.14.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: Cyril Brulebois Control: affects -1 + src:fuse3 Hi RMs, Two issues in src:fuse3 I would like to have fixed for Bookworm. [ Reason ] There's a memory leak in the high level API [1] and the fuse CLI doesn't propagate the allowed maximum threads to use [2]. [ Impact ] In special cases like fuse3 would get a signal during its start it would leak some memory. Users can't set usage constraints in terms of threads (CPU) usage. These are not common situations but would be better to handle these. [ Tests ] Upstream test suite. Tested and built correctly in experimental. Waiting for your permission to upload to Sid. [ Risks ] Minimal, the fixes are small and very targeted. Should not affect the installer creation (as it uses the fuse3 udeb), but kibi is also pinged for an extra check. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock fuse3/3.14.0-4 Thanks for considering, Laszlo/GCS [1] https://github.com/libfuse/libfuse/pull/781 [2] https://github.com/libfuse/libfuse/pull/742 diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog --- fuse3-3.14.0/debian/changelog 2023-03-17 20:51:05.0 +0100 +++ fuse3-3.14.0/debian/changelog 2023-04-18 23:07:15.0 +0200 @@ -1,3 +1,11 @@ +fuse3 (3.14.0-4) unstable; urgency=medium + + * Backport upstream fixes: +- fix max_threads command line parameter propagation, +- fix memory leak in high level API. + + -- Laszlo Boszormenyi (GCS) Tue, 18 Apr 2023 23:07:15 +0200 + fuse3 (3.14.0-3) unstable; urgency=medium [ Helge Deller ] diff -Nru fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch --- fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch 1970-01-01 01:00:00.0 +0100 +++ fuse3-3.14.0/debian/patches/Fix-max_threads-command-line-parameter-propagation.patch 2023-04-17 21:34:29.0 +0200 @@ -0,0 +1,24 @@ +From ab5ca07af03b7dbb33193666c13b938534bde0e4 Mon Sep 17 00:00:00 2001 +From: Sarath Lakshman +Date: Sat, 11 Mar 2023 16:58:31 +0530 +Subject: [PATCH] Fix max_threads command line parameter propagation + +The fuse_main_real() method doesn't apply the max_threads parameter +parsed through the commandline arguments. This commit fixes the wiring +of max_threads argument. +--- + lib/helper.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/lib/helper.c b/lib/helper.c +index 35c6a98c..14a0df33 100644 +--- a/lib/helper.c b/lib/helper.c +@@ -377,6 +377,7 @@ int fuse_main_real(int argc, char *argv[], const struct fuse_operations *op, + fuse_loop_cfg_set_clone_fd(loop_config, opts.clone_fd); + + fuse_loop_cfg_set_idle_threads(loop_config, opts.max_idle_threads); ++ fuse_loop_cfg_set_max_threads(loop_config, opts.max_threads); + res = fuse_loop_mt(fuse, loop_config); + } + if (res) diff -Nru fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch --- fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch 1970-01-01 01:00:00.0 +0100 +++ fuse3-3.14.0/debian/patches/Fix_memory_leak_in_high_level_API.patch 2023-04-17 21:34:29.0 +0200 @@ -0,0 +1,66 @@ +From fcd293f675fc7bfa0522186c5d68ef932eec6945 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Matthias=20G=C3=B6rgens?= +Date: Fri, 14 Apr 2023 19:19:03 +0800 +Subject: [PATCH] Fix memory leak in high level API (#781) + +Previously, in the high level API if we received a signal between +setting up signal handlers and processing INIT, we would leak + +``` +$ ./example/hello -s -d -f mountpoint/ +[9/9] Linking target example/hello_ll +FUSE library version: 3.14.1 +nullpath_ok: 0 + += +==178330==ERROR: LeakSanitizer: detected memory leaks + +Direct leak of 352 byte(s) in 1 object(s) allocated from: +#0 0x7fbb19abf411 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77 +#1 0x7fbb1a0efd3b in fuse_fs_new ../lib/fuse.c:4814 +#2 0x7fbb1a0f02b5 in fuse_new_31 ../lib/fuse.c:4913 +#3 0x7fbb1a10ec5e in fuse_main_real ../lib/helper.c:345 +#4 0x5625db8ab418 in main ../example/hello.c:176 +#5 0x7fbb1983c78f (/usr/lib/libc.so.6+0x2378f) + +SUMMARY: AddressSanitizer: 352 byte(s) leaked in 1 allocation(s). +``` + +That's because `fuse_lowlevel.c`s `fuse_session_destroy` would only call +the user supplied `op.destroy`, if INIT had been processed, but the high +level API relied on `op.destroy` to free `f->fs`. + +This patch moves the freeing into `fuse_destroy` that will always be +called by our high-level API. +--- + lib/fuse.c | 3 +-- + 1 file changed
Bug#1034645: unblock: graphicsmagick/1.4+really1.3.40-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:graphicsmagick
Hi RMs,
Two security fixes were added to graphicsmagick and I would like to
get those to Bookworm.
[ Reason ]
It was found that the MIFF reader was somehow able to provide
attribute data in a way which resulted in a heap overflow. There is
also a memory leak fix.
[ Impact ]
The heap overflow was detected by ASAN, meaning it might be
exploitable. The memory leak is in the handling of the
EXIF:Orientation key, common in images.
[ Tests ]
Upstream test suite.
[ Risks ]
Minimal but if there would be any issue upstream is quick to address them.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock graphicsmagick/1.4+really1.3.40-4
Thanks for considering,
Laszlo/GCS
diff -Nru graphicsmagick-1.4+really1.3.40/debian/changelog graphicsmagick-1.4+really1.3.40/debian/changelog
--- graphicsmagick-1.4+really1.3.40/debian/changelog 2023-01-19 19:44:45.0 +0100
+++ graphicsmagick-1.4+really1.3.40/debian/changelog 2023-04-17 19:17:10.0 +0200
@@ -1,3 +1,19 @@
+graphicsmagick (1.4+really1.3.40-4) unstable; urgency=medium
+
+ * Remove development ifdef from memory leak fix.
+
+ -- Laszlo Boszormenyi (GCS) Mon, 17 Apr 2023 19:17:10 +0200
+
+graphicsmagick (1.4+really1.3.40-3) unstable; urgency=high
+
+ * Backport security fixes:
+- MIFF reader able to provide attribute data in way which results in
+ a heap overflow,
+- SetImageAttribute(): eliminate memory leak when handling attribute
+ with key "EXIF:Orientation".
+
+ -- Laszlo Boszormenyi (GCS) Sun, 16 Apr 2023 14:21:32 +0200
+
graphicsmagick (1.4+really1.3.40-2) unstable; urgency=medium
* Don't force tiff dependency, let shlibs handle it (closes: #1029212).
diff -Nru graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch
--- graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch 1970-01-01 01:00:00.0 +0100
+++ graphicsmagick-1.4+really1.3.40/debian/patches/eliminate_memory_leak_when_handling_EXIFOrientation.patch 2023-04-17 19:17:10.0 +0200
@@ -0,0 +1,115 @@
+
+# HG changeset patch
+# User Bob Friesenhahn
+# Date 1681598921 18000
+# Node ID 3ce01217413bb5b476460bbc8ab11020205eeda0
+# Parent 8bec800dbaef2d72da0e7e997ad45bece0e95893
+SetImageAttribute(): Eliminate memory leak when handling attribute with key "EXIF:Orientation"
+
+diff -r 8bec800dbaef -r 3ce01217413b ChangeLog
+--- a/ChangeLog Sat Apr 08 18:31:31 2023 -0500
b/ChangeLog Sat Apr 15 17:48:41 2023 -0500
+@@ -1,3 +1,9 @@
++2023-04-15 Bob Friesenhahn
++
++ * magick/attribute.c (SetImageAttribute): Eliminate memory leak
++ when handling attribute with key "EXIF:Orientation". (SourceForge
++ issue #707 "memory leaks in gm").
++
+ 2023-04-08 Bob Friesenhahn
+
+ * coders/mpc.c (ReadMPCImage): If an attribute appears multiple
+diff -r 8bec800dbaef -r 3ce01217413b coders/miff.c
+--- a/coders/miff.c Sat Apr 08 18:31:31 2023 -0500
b/coders/miff.c Sat Apr 15 17:48:41 2023 -0500
+@@ -761,6 +761,8 @@ SetNewImageAttribute(Image *image,const
+ MagickPassFail
+ status;
+
++ status = SetImageAttribute(image,key,value);
++
+ if (GetImageAttribute(image,key) == (const ImageAttribute *) NULL)
+ status = SetImageAttribute(image,key,value);
+ else
+diff -r 8bec800dbaef -r 3ce01217413b magick/attribute.c
+--- a/magick/attribute.c Sat Apr 08 18:31:31 2023 -0500
b/magick/attribute.c Sat Apr 15 17:48:41 2023 -0500
+@@ -3178,9 +3178,6 @@
+ register ImageAttribute
+ *p;
+
+- int
+-orientation;
+-
+ /*
+ Initialize new attribute.
+ */
+@@ -3271,6 +3268,9 @@
+
+ if (LocaleCompare(attribute->key,"EXIF:Orientation") == 0)
+ {
++ int
++orientation = 0;
++
+ /*
+ Special handling for EXIF orientation tag.
+ If new value differs from existing value,
+@@ -3278,17 +3278,19 @@
+ is valid. Don't append new value to existing value,
+ replace it instead.
+ */
+- orientation = MagickAtoI(value);
+- if (orientation > 0 || orientation <= (int)LeftBottomOrientation)
+-SetEXIFOrientation(image, orientation);
+-
+- /* Replace current attribute with new one */
+- attribute->next = p->next;
+- if (p->previous == (ImageAttribute *) NULL)
+-image->attributes=attribute;
+- else
+-p->previous->next = attribute;
+-
Bug#1034330: unblock: protobuf/3.21.12-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: affects -1 + src:protobuf
Hi RMs,
Please unblock package protobuf. It's running build time tests with those fixes.
[ Reason ]
It was discovered late that build time tests are not run [1] and the
fix is easy. Reporter stated firmly that he is even going to NMU the
package in unstable and/or stable to fix this issue. My bad that I
thought this change was fully tested and I only checked it on amd64.
Then it turned out build time tests are broken on 32 bit platforms [2].
[ Impact ]
I took my time and fixed build tests. On hppa I had to extend the
ignorance of a static_assert() due to over alignment on this platform.
Now it has a working self-check on package changes including security
ones during Bookworm lifecycle.
[ Tests ]
Upstream test suite. Done build tests with the following rdeps:
clementine and grpc on both i386 and amd64 including tests of those
packages. Those worked without a hitch.
Package tests for migration also worked.
[ Risks ]
Low, the changes are pretty straightforward and only affects the
self-testing parts of the package.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Uploaded four days ago, built on all previous architectures and no new
bug reports are filed.
unblock protobuf/3.21.12-3
Thanks for considering,
Laszlo/GCS
[1] https://bugs.debian.org/1033989
[2] https://bugs.debian.org/1033998
diff -Nru protobuf-3.21.12/debian/changelog protobuf-3.21.12/debian/changelog
--- protobuf-3.21.12/debian/changelog 2022-12-17 09:18:06.0 +0100
+++ protobuf-3.21.12/debian/changelog 2023-04-09 07:50:55.0 +0200
@@ -1,3 +1,16 @@
+protobuf (3.21.12-3) unstable; urgency=medium
+
+ * Fix build-time tests on 32 bit architectures (closes: #1033998).
+
+ -- Laszlo Boszormenyi (GCS) Sun, 09 Apr 2023 05:50:55 +
+
+protobuf (3.21.12-2) unstable; urgency=medium
+
+ [ Helmut Grohne ]
+ * Reenable build-time testing (closes: #1033989).
+
+ -- Laszlo Boszormenyi (GCS) Wed, 05 Apr 2023 21:57:20 +0200
+
protobuf (3.21.12-1) unstable; urgency=medium
* New upstream release.
diff -Nru protobuf-3.21.12/debian/elpa-test protobuf-3.21.12/debian/elpa-test
--- protobuf-3.21.12/debian/elpa-test 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.21.12/debian/elpa-test 2023-04-05 21:57:20.0 +0200
@@ -0,0 +1 @@
+disable=please_do_run_dh_auto_test
diff -Nru protobuf-3.21.12/debian/patches/build_32_bit_tests.patch protobuf-3.21.12/debian/patches/build_32_bit_tests.patch
--- protobuf-3.21.12/debian/patches/build_32_bit_tests.patch 1970-01-01 01:00:00.0 +0100
+++ protobuf-3.21.12/debian/patches/build_32_bit_tests.patch 2023-04-05 21:57:20.0 +0200
@@ -0,0 +1,140 @@
+From 01c340d0bb9abb2654554afc732df2c89774ce81 Mon Sep 17 00:00:00 2001
+From: Mike Kruskal <62662355+mkruskal-goo...@users.noreply.github.com>
+Date: Mon, 19 Sep 2022 09:50:19 -0700
+Subject: [PATCH] Adding full build to 32 bit tests (#10589)
+
+* Adding full build to 32 bit tests
+
+* Running C++ tests in 32 bit builds
+
+* Patching static assert test failure
+
+* Test fixes for 32-bit architectures
+
+* Cleanup after CMake build
+
+* Save protoc before cleanup
+
+* Route protoc better
+---
+ .../compiler/cpp/message_size_unittest.cc | 2 +-
+ src/google/protobuf/extension_set_unittest.cc | 6 ++--
+ .../protobuf/io/zero_copy_stream_unittest.cc | 3 ++
+ .../protobuf/repeated_field_unittest.cc | 4 +--
+ src/google/protobuf/util/time_util_test.cc| 28 +++
+ 8 files changed, 42 insertions(+), 20 deletions(-)
+
+diff --git a/src/google/protobuf/compiler/cpp/message_size_unittest.cc b/src/google/protobuf/compiler/cpp/message_size_unittest.cc
+index a75d77a70cb..ed4a90e223f 100644
+--- a/src/google/protobuf/compiler/cpp/message_size_unittest.cc
b/src/google/protobuf/compiler/cpp/message_size_unittest.cc
+@@ -139,9 +139,9 @@ TEST(GeneratedMessageTest, OneStringSize) {
+
+ TEST(GeneratedMessageTest, MoreStringSize) {
+ struct MockGenerated : public MockMessageBase { // 16 bytes
+-int has_bits[1]; // 4 bytes
+ int cached_size; // 4 bytes
+ MockRepeatedPtrField data; // 24 bytes
++// + 4 bytes padding
+ };
+ GOOGLE_CHECK_MESSAGE_SIZE(MockGenerated, 48);
+ EXPECT_EQ(sizeof(protobuf_unittest::MoreString), sizeof(MockGenerated));
+diff --git a/src/google/protobuf/extension_set_unittest.cc b/src/google/protobuf/extension_set_unittest.cc
+index 8b436bc20c9..84da3c5465a 100644
+--- a/src/google/protobuf/extension_set_unittest.cc
b/src/google/protobuf/extension_set_unittest.cc
+@@ -852,8 +852,10 @@ TEST(ExtensionSetTest, SpaceUsedExcludingSelf) {
+ const size_t old_ca
Bug#1034309: RM: gradm2 -- RoM; obsolete
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove Control: affects -1 + src:gradm2 Hi FTP Masters, Please remove src:gradm2 from unstable - and from Bookworm as well if a separate 'dak rm' is needed. It is an outdated, obsolete package version that should not be part of our next stable release nor be part of the project anymore. Thanks, Laszlo/GCS
Bug#1033989: protobuf: does not run any build-time tests anymore
On Wed, Apr 5, 2023 at 9:27 PM Helmut Grohne wrote: > Please let me know if you want to handle this. I'll treat the absence of > a response as being ok with me NMUing the attached patch and filing the > unblock request. Updated package is uploaded. > I also intend to NMU protobuf in stable (fixing more issues). Feel free to ping me before that. I'm always open to learning from my mistakes - and I'm alive and well. Regards, Laszlo/GCS
Bug#988948: CVE-2019-11939
Hi, On Fri, Mar 17, 2023 at 7:54 PM László Böszörményi (GCS) wrote: > On Thu, Mar 16, 2023 at 11:15 PM Moritz Mühlenhoff wrote: > > Am Fri, May 21, 2021 at 09:46:31PM +0200 schrieb Moritz Muehlenhoff: > > > CVE-2019-11939: > > > https://github.com/facebook/fbthrift/commit/483ed864d69f307e9e3b9dadec048216100c0757 > > is this fixed in Bookworm? > I let the Security Team decide how this should be treated. I will try > to describe it in full and short. Friendly ping, how the Security Team sees this issue. I've provided insights [1] and tend to think it's safe for Bullseye and later. Regards, Laszlo/GCS [1] https://bugs.debian.org/988948#17
Bug#1033203: unblock: fuse3/3.14.0-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Cyril Brulebois
Control: affects -1 + src:fuse3
Hi RMs,
[ Reason ]
The self-testing of fuse3 only works on little-endian machines. I've
already disabled it on big-endian release architectures. Missed hppa
which is not added to the list.
Compiling examples didn't work due to outdated Makefile and using an
outdated header name in one of the files.
[ Impact ]
With the changes fuse3 is compiled on hppa now. As the installer needs
its udeb it can be created on that architecture as well from now on.
One of the example files was patched to use the current header file
name and now compiles with all of the other example files.
[ Tests ]
I've tested the examples compilation and those are OK now. Compilation
on hppa is now working as can be seen in the buildd logs [1].
[ Risks ]
None of the changes affect the working of the package itself.
As fuse3 has an udeb I put kibi to the loop if extra ACK is needed.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock fuse3/3.14.0-3
Thanks for considering,
Laszlo/GCS
[1] https://buildd.debian.org/status/logs.php?pkg=fuse3=hppa
diff -Nru fuse3-3.14.0/debian/changelog fuse3-3.14.0/debian/changelog
--- fuse3-3.14.0/debian/changelog 2023-02-18 07:22:30.0 +0100
+++ fuse3-3.14.0/debian/changelog 2023-03-17 20:51:05.0 +0100
@@ -1,3 +1,15 @@
+fuse3 (3.14.0-3) unstable; urgency=medium
+
+ [ Helge Deller ]
+ * Add the big-endian hppa platform to the disabled self-testing list
+(closes: #1032187).
+
+ [ Laszlo Boszormenyi (GCS) ]
+ * Update fuse header name in examples.
+ * Fix Makefile for examples (closes: #1031544).
+
+ -- Laszlo Boszormenyi (GCS) Fri, 17 Mar 2023 20:51:05 +0100
+
fuse3 (3.14.0-2) unstable; urgency=medium
* Revert upgrade of fuse_kernel.h for not being upstreamed yet
diff -Nru fuse3-3.14.0/debian/examples/Makefile fuse3-3.14.0/debian/examples/Makefile
--- fuse3-3.14.0/debian/examples/Makefile 2014-06-20 08:23:50.0 +0200
+++ fuse3-3.14.0/debian/examples/Makefile 2023-03-17 20:51:05.0 +0100
@@ -1,12 +1,16 @@
-CFLAGS := -Wall $(shell pkg-config fuse --cflags)
-LDFLAGS := $(shell pkg-config fuse --libs)
+CFLAGS := -Wall $(shell pkg-config fuse3 --cflags)
+LDFLAGS := $(shell pkg-config fuse3 --libs)
-targets = fusexmp fusexmp_fh hello hello_ll null
+targets = cuse cuse_client hello hello_ll \
+ invalidate_path ioctl ioctl_client \
+ notify_inval_entry notify_inval_inode notify_store_retrieve \
+ null passthrough passthrough_fh passthrough_ll \
+ poll poll_client printcap
-all: $(targets)
+%: %.c
+ $(CC) $(CFLAGS) $< -o $@ $(LDFLAGS)
-fusexmp_fh: fusexmp_fh.c
- $(CC) $(CFLAGS) $(LDFLAGS) -lulockmgr $< -o $@
+all: $(targets)
clean:
rm -f *.o
diff -Nru fuse3-3.14.0/debian/patches/series fuse3-3.14.0/debian/patches/series
--- fuse3-3.14.0/debian/patches/series 2023-02-18 07:22:30.0 +0100
+++ fuse3-3.14.0/debian/patches/series 2023-03-17 20:51:05.0 +0100
@@ -1 +1,2 @@
revert_upgrade_of_fuse_kernel.h.patch
+update_header_name.patch
diff -Nru fuse3-3.14.0/debian/patches/update_header_name.patch fuse3-3.14.0/debian/patches/update_header_name.patch
--- fuse3-3.14.0/debian/patches/update_header_name.patch 1970-01-01 01:00:00.0 +0100
+++ fuse3-3.14.0/debian/patches/update_header_name.patch 2023-03-17 20:51:05.0 +0100
@@ -0,0 +1,21 @@
+Description: use new header name of fuse
+ Just rename fuse_config.h to libfuse_config.h
+Author: Laszlo Boszormenyi (GCS)
+Bug-Debian: https://bugs.debian.org/1031544
+Forwarded: no
+Last-Update: 2023-03-17
+
+---
+
+
+--- fuse3-3.14.0.orig/example/poll_client.c
fuse3-3.14.0/example/poll_client.c
+@@ -19,7 +19,7 @@
+ * \include poll_client.c
+ */
+
+-#include
++#include
+
+ #include
+ #include
diff -Nru fuse3-3.14.0/debian/rules fuse3-3.14.0/debian/rules
--- fuse3-3.14.0/debian/rules 2023-01-22 08:17:08.0 +0100
+++ fuse3-3.14.0/debian/rules 2023-03-17 20:51:05.0 +0100
@@ -54,7 +54,7 @@
override_dh_auto_test:
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
-ifeq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x))
+ifeq (,$(findstring $(DEB_BUILD_ARCH),powerpc ppc64 sparc64 s390x hppa))
(cd obj-${DEB_HOST_GNU_TYPE}; python3 -m pytest test/) \
|| true
endif
Bug#1033197: unblock: sqlite3/3.40.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Cyril Brulebois
Control: affects -1 + src:sqlite3
Hi RMs,
[ Reason ]
Cyril Brulebois (kibi) who is the maintainer of crowdsec found out
that partial upgrade of Bullseye to Bookworm may render it unable to
start. Reason is, sqlite3 with 3.37.0-1 changed its internal
table_info representation. Previously the column types were in
lowercase letters and from this version these are using uppercase
letters - confusing the Bullseye version of crowdsec. With the version
in Bookworm it is already fixed.
[ Impact ]
Upgrading only libsqlite3-0 but not crowdsec makes the latter unusable
as it will not start. To prevent such situations I've added breaks on
old crowdsec versions.
[ Tests ]
Kibi did the testing [1] and the fix only prevents incompatible
versions of the mentioned packages to be installed.
[ Risks ]
Basically nothing.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
unblock sqlite3/3.40.1-2
Thanks for consideration,
Laszlo/GCS
[1] https://bugs.debian.org/1033029
diff -Nru sqlite3-3.40.1/debian/changelog sqlite3-3.40.1/debian/changelog
--- sqlite3-3.40.1/debian/changelog 2022-12-31 09:41:40.0 +0100
+++ sqlite3-3.40.1/debian/changelog 2023-03-16 19:54:28.0 +0100
@@ -1,3 +1,12 @@
+sqlite3 (3.40.1-2) unstable; urgency=medium
+
+ [ Cyril Brulebois ]
+ * Add Breaks against crowdsec as found in bullseye, as it relies on a
+particular table_info format, which changes between 3.36.0 and 3.37.0
+(closes: #1033029).
+
+ -- Laszlo Boszormenyi (GCS) Thu, 16 Mar 2023 19:54:28 +0100
+
sqlite3 (3.40.1-1) unstable; urgency=medium
* New upstream release.
diff -Nru sqlite3-3.40.1/debian/control sqlite3-3.40.1/debian/control
--- sqlite3-3.40.1/debian/control 2022-12-31 09:41:40.0 +0100
+++ sqlite3-3.40.1/debian/control 2023-03-16 19:54:28.0 +0100
@@ -52,7 +52,7 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Breaks: python-migrate (<< 0.11.0-4~), python3-migrate (<< 0.11.0-4~)
+Breaks: python-migrate (<< 0.11.0-4~), python3-migrate (<< 0.11.0-4~), crowdsec (<< 1.4)
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Description: SQLite 3 shared library
Bug#988948: CVE-2019-11939
On Fri, Mar 17, 2023 at 7:54 PM László Böszörményi (GCS) wrote: > Thrift was developed by Facebook, open sourced and later donated to > the Apache Software Foundation. Missed the whole point: packaging done from the ASF source tree of Thrift. Cheers, Laszlo/GCS
Bug#988948: CVE-2019-11939
Hi Moritz, On Thu, Mar 16, 2023 at 11:15 PM Moritz Mühlenhoff wrote: > Am Fri, May 21, 2021 at 09:46:31PM +0200 schrieb Moritz Muehlenhoff: > > CVE-2019-11939: > > https://github.com/facebook/fbthrift/commit/483ed864d69f307e9e3b9dadec048216100c0757 > is this fixed in Bookworm? I let the Security Team decide how this should be treated. I will try to describe it in full and short. Thrift was developed by Facebook, open sourced and later donated to the Apache Software Foundation. Meaning that it's a real open source project, it's not supervised by the company. That is, there are two source trees; one from Facebook itself [1] and the one from ASF [2]. These diverged and the vulnerability is found only in the source tree of Facebook [3]: "Golang Facebook Thrift servers would not error [...]". Sure, with Jaeger Agent [4] large memory allocation was found in the Golang binding of the Apache source tree. It was filed as THRIFT-5322 [5] and was fixed for 0.14.0 [6]. This vulnerability is referenced with this issue as well. But I think the upcoming issue is more relevant with it, as with other circumates Jaeger Agent still caused huge allocations and the fix is more similar to the fix used by Facebook. This issue is filed as THRIFT-5369 [7] and was fixed for 0.14.2 and 0.15.0 [8]. Bookworm has version 0.17.0 of Apache Thrift so at least the two mentioned memory allocation problems in Golang bindings are fixed in it. But the referenced CVE vulnerability is officially not referenced with the Apache source tree. I'm looking for advice from the Security Team on how this is considered. Cheers, Laszlo/GCS [1] https://github.com/facebook/fbthrift [2] https://github.com/apache/thrift [3] https://nvd.nist.gov/vuln/detail/CVE-2019-11939 [4] https://www.jaegertracing.io/ [5] https://issues.apache.org/jira/browse/THRIFT-5322 [6] https://github.com/apache/thrift/commit/37c2ceb737cb40377346c63a05f407da1c119ba0 [7] https://issues.apache.org/jira/browse/THRIFT-5369 [8] https://github.com/apache/thrift/commit/6583f4e52345c3b05a76f0b188836599628356e8
Bug#918075: Some patches for dar
Hi John, On Wed, Mar 8, 2023 at 2:47 PM John Goerzen wrote: > I had thought that I'd be able to get by without the delta-diff > features, but due to some changes over here, they would save me multiple > GBs per day. So I am happy to dive in to work on dar. Sounds good. > I have submitted an ITP for libthreadar, which will allow multithreaded > compression/encryption as well as enable remote repository support. I > have also uploaded a backport of librsync to bullseye-backports to > enable a future dar backport to bullseye with binary delta support. Where can I check the libthreadar packaging? > Would you like me to take over maintaining dar? Or would you like to > apply the patch (with appropriate changelog updates) and upload it? Or > I could upload it and leave the maintainers line alone? It's a release freeze for Bookworm. I'm asking for approval and will do it once it is allowed. I am open to giving the package to you during the Trixie release cycle. Regards, Laszlo/GCS
Bug#1032526: [pre-approval] unblock: dar/2.7.8-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: jgoer...@complete.org
Control: affects -1 + src:dar
Hi RMs,
Please pre-approve a feature enabled version of dar.
[ Reason ]
John Goerzen updated build dependencies to reflect the libext2fs-dev
rename, added delta changes support with rsync (previously I've not
enabled it as it didn't have the static library to use with
dar-static) and use Linux capabilities support.
[ Impact ]
Users will get a more feature rich version of dar.
[ Tests ]
The delta changes testing done by John, I did only build and basic testing.
[ Risks ]
I don't know any. No code change, only enable features that are
present in the source code already.
[ Checklist ]
[X] all changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in testing
Thanks for consideration,
Laszlo/GCS
diff -Nru dar-2.7.8/debian/changelog dar-2.7.8/debian/changelog
--- dar-2.7.8/debian/changelog 2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/changelog 2023-03-08 18:14:41.0 +0100
@@ -1,3 +1,17 @@
+dar (2.7.8-2) unstable; urgency=medium
+
+ [ John Goerzen ]
+ * Support delta changes via librsync.
+ * Update dep on e2fslibs-dev to new name libext2fs-dev
+ * Add dep on libcap-dev to eneable proper capability handling.
+ * Add build-dependency on dot to ensure figures for docs are always
+built.
+
+ [ Laszlo Boszormenyi (GCS) ]
+ * Build depend on libcap-dev only on Linux architectures.
+
+ -- Laszlo Boszormenyi (GCS) Wed, 08 Mar 2023 18:14:41 +0100
+
dar (2.7.8-1) unstable; urgency=medium
* New upstream release.
diff -Nru dar-2.7.8/debian/control dar-2.7.8/debian/control
--- dar-2.7.8/debian/control 2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/control 2023-03-08 18:14:41.0 +0100
@@ -3,9 +3,11 @@
Priority: optional
Maintainer: Laszlo Boszormenyi (GCS)
Build-Depends: debhelper-compat (= 13), pkg-config, zlib1g-dev, libbz2-dev,
- libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, e2fslibs-dev,
- libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev, doxygen, groff
-Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev, librsync-dev
+ libzstd-dev, liblzo2-dev, liblzma-dev, liblz4-dev, libext2fs-dev,
+ libgcrypt20-dev, libgpgme-dev, libassuan-dev, libargon2-dev,
+ librsync-dev, libcap-dev [linux-any],
+ doxygen, groff, graphviz
+Build-Conflicts: libcurl4-gnutls-dev, libcurl4-openssl-dev
Standards-Version: 4.6.1
Rules-Requires-Root: no
Homepage: http://dar.linux.free.fr/
diff -Nru dar-2.7.8/debian/rules dar-2.7.8/debian/rules
--- dar-2.7.8/debian/rules 2022-12-04 15:57:33.0 +0100
+++ dar-2.7.8/debian/rules 2023-03-08 18:14:41.0 +0100
@@ -4,13 +4,18 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
+DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS)
+
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
DEB_CONFIGURE_EXTRA_FLAGS := --disable-upx --disable-python-binding \
--enable-mode=64
DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
-BUILT_USING_PACKAGES = libc-dev-bin libattr1-dev libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev
+BUILT_USING_PACKAGES = libc-dev-bin libbz2-dev libgcrypt20-dev libgpgme-dev liblzo2-dev zlib1g-dev libzstd-dev liblz4-dev libargon2-dev libassuan-dev librsync-dev libext2fs-dev
+ifeq ($(DEB_HOST_ARCH_OS), linux)
+BUILT_USING_PACKAGES += libcap-dev
+endif
BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' -W $(BUILT_USING_PACKAGES))
Bug#1031716: python3-protobuf: Do reverse dependencies need stricter version constraints?
On Tue, Feb 21, 2023 at 1:27 PM Adrian Bunk wrote: > Looking at #1028371, should generated dependencies on python3-protobuf be > python3-protobuf (>= 3.21), python3-protobuf (<< 3.22) You mean on python3-bernhard, right? > to ensure that the binary package is used with the same version > as the protobuf-compiler used during the build? Then what? It would become uninstallable when a new protobuf version (3.22 next time) is uploaded and built. > If yes, are other language bindings also affected by this problem? I still don't get your point. How does a language binding package version relate to the protobuf-compiler version? I don't follow the internals of Protobuf, but I would say it's more related to the library soname and its provided API version. Regards, Laszlo/GCS
Bug#1031632: tiff: CVE-2023-0795 CVE-2023-0796 CVE-2023-0797 CVE-2023-0798 CVE-2023-0799 CVE-2023-0800 CVE-2023-0801 CVE-2023-0802 CVE-2023-0803 CVE-2023-0804
Hi Salvatore, On Sun, Feb 19, 2023 at 4:39 PM Salvatore Bonaccorso wrote: > The following vulnerabilities were published for tiff. Strictly > speaking it might be disputed to fill this as RC level, though would > be good to have those as well addressed before the bookworm release. Aren't these the issues I've fixed earlier today [1] with two additional security related fixes? You even handled these with commit 919f8c7bc3305adea4835ca0a7b24a48e592ec25 via our security tracker. Unfortunately I still don't get any emails from it. :( However I'm sure I'm subscribed to the tracker-commits. Regards, Laszlo/GCS [1] https://tracker.debian.org/news/1422194/accepted-tiff-450-5-source-into-unstable/
Bug#1029260: vice: missing font license in d/copyright
Control: found -1 2.1.dfsg-1 Control: severity -1 important On Sun, Jan 29, 2023 at 4:03 PM Bastian Germann wrote: > So if that font is not GPL-compibly licensed, CBM cannot be GPL licensed. It's mentioned as '100% free' and was added to the VICE project in its 1.22.9 release. The first package version uploaded with it is 2.1.dfsg-1 from March, 2009. Cheers, Laszlo/GCS
Bug#1031394: Please re-enable RTTI support in Sid/Bookworm, needed by at least Ceph
Control: tags -1 +moreinfo Dear Thomas, On Thu, Feb 16, 2023 at 1:51 PM Thomas Goirand wrote: > During my tests with Ceph, I noticed a grave regression: Ceph OSD (the process > that does the actual storage for Ceph) cannot use Snappy anymore, because it > can't find one symbole related to RTTI. Isn't that because the upgrade path is not correct? New Ceph binaries should handle this path. > The consequence is that it cannot load and use Snappy. This may be ok for > newer > clusters, but when upgrading from a cluster let's say in Bullseye, this may be > desastrous: data wont be able to be unpacked, which means data loss. I don't see it as a data loss, but a data access issue. > Moving forward, what I propose is probably the easiest way forward, at least > for Ceph. Doing extra patching of the Ceph would be a way more hazardous. I'm quite surprised this was realized so late. You are probably not the only person using Ceph. How others can use, how they upgraded their Ceph clusters? Regards, Laszlo/GCS
Bug#1029944: neon27 FTBFS on IPV6-only buildds
Hi,
On Sat, Feb 11, 2023 at 7:48 PM Andreas Henriksson wrote:
> If replacing "127.0.0.1" with "localhost" does not work the attached
> (completely untested) patch might be an option instead (simply skip the
> test on EAFNOSUPPORT).
I don't have access to an IPv6 host to test on, so I just think it
would not work.
> (Sorry if the patch is completely broken, but I hope you get the
> idea...)
This is broken for sure as some tests create a server socket (get the
'Address family for hostname not supported' error) and then next tests
would like to connect to it ('request failed: Could not connect to
proxy server: Connection refused' error) or simply get an other error
('request failed with 5 not NE_ERROR' message). While your patch would
skip the former, the latter would still be a problem.
I can remove the IPv4 only tests that are detected on buildds, but
there's at least one which hangs ('Build killed with signal TERM after
150 minutes of inactivity').
Any IPv6 porterbox available?
Regards,
Laszlo/GCS
Bug#1029260: vice: missing font license in d/copyright
On Sun, Jan 29, 2023 at 4:03 PM Bastian Germann wrote: > I have tracked down the origin to > https://sourceforge.net/projects/diskimagery64. > This is a GPL-2 project so one could assume the font is GPL-2 as well. > However, README.txt claims the following: > > "The fonts were not created totally by myself. I had a scalable commodore > TrueType font lying around on on my hard disk and I used it as a starting > point. The existing font told me its origins in the header: based on a font by > Devin D. Cook with fixes from Chris McBride." Yes, the font was made by Devin D. Cook back in 2003/2004 or even earlier and he further updated it around 2010. > So if that font is not GPL-compibly licensed, CBM cannot be GPL licensed. He only states '100% Free' [1]. Will try to get to him for a longer explanation. > In any way, please also include the source files for the font from the > referenced project. Err, what do you mean source files for a font? Regards, Laszlo/GCS [1] https://www.dafont.com/commodore-64-pixelized.font
Bug#1029260: vice: missing font license in d/copyright
Control: tags -1 +moreinfo On Fri, Jan 20, 2023 at 1:36 PM Bastian Germann wrote: > Please include the CBM.ttf font license. I cannot find it on the > web with any free software license so it might be non-free. Thanks for taking care of this. Let me ask you, did you find it anywhere, especially with a non-free licence? Regards, Laszlo/GCS
Bug#1012864: graphviz: new upstream version 2.44.0 is available
On Sat, Jan 28, 2023 at 10:27 PM Antoine Beaupré wrote: > It seems that this bug report is not quite up to date. According to the > upstream changelog I could find, 7.0.0 has been out since January: Indeed, upstream got moving quite fast even with breaking changes. > Are we all looking at the same upstream here? :) With me at least. I know that upstream has become quite active. Even packaged (I believe) 6.0 back then which needed several new binary packages, reorganization of files, etc. Then I didn't have time to do all the test rebuilds of packages that use it as build dependency. My plan is to do it early for Trixie with an updated upstream release. Regards, Laszlo/GCS
Bug#1029944: neon27 FTBFS on IPV6-only buildds
Control: tags -1 +confirmed On Sun, Jan 29, 2023 at 12:33 PM Adrian Bunk wrote: > https://buildd.debian.org/status/logs.php?pkg=neon27=amd64 > > ... > auth.. 3/20 FAIL - retries (line 311: HTTP error: > Could not resolve hostname `127.0.0.1': Address family for hostname not > supported) Is there a way to detect such buildds as a maintainer? What can I do except notifying upstream and / or disable such tests? Cheers, Laszlo/GCS
Bug#1029444: dmraid: remove force_load dm-raid45 not shipped by Debian
On Sun, Jan 22, 2023 at 5:57 PM Alban Browaeys wrote: > Package: dmraid > Version: 1.0.0.rc16-8+b1 [...] > on each Debian box with dmraid installed (here by suggestion from gparted), > one gets a message at boot (from initrd stage): > modprobe: module dm-raid45 not found in modules.dep It has been fixed long time ago for Bookworm. For me it seems you are using Bullseye. > it has been 15 years since the issue has been reported and it was told to > patch the kernel with alpha > code in Debian bug #411172 . (there was also a patch included in the debian > package to > translate raid-45 calls to raid456 which is in the Debian kernel but it is > told not to work in htis bug report > - was dmraid 1.0.0.rc14-1). > > Is there any reason to ship an initramfs that request an out-of-tree module > for all Debian users with dmraid installted ? > > May I request that the call to force_load dm-raid45 be removed for now and > replaced by a force_load raid456 > when support is implemented? Can you confirm that when you have _up-to-date Bookworm_ running you have this message? Regards, Laszlo/GCS
Bug#1029213: libgraphicsmagick-q16-3 has a hardcoded dependency on libtiff5
Control: merge -1 1029212
On Thu, Jan 19, 2023 at 7:15 PM Adrian Bunk wrote:
> libgraphicsmagick-q16-3 has a hardcoded dependency on the cruft libtiff5:
> https://sources.debian.org/src/graphicsmagick/1.4%2Breally1.3.40-1/debian/control/#L44
>
> Please drop this, ${shlibs:Depends} already generates a correct dependency
> on libtiff6.
Indeed and already reported. Will fix this shortly.
Regards,
Laszlo/GCS
Bug#1029032: ITP: python-google-api-core -- Google API client core library
Package: wnpp Severity: wishlist Owner: Laszlo Boszormenyi (GCS) * Package name: python-google-api-core Version : 1.34.0 Upstream Author : 2014- Google Inc. * URL : https://github.com/googleapis/python-api-core * License : Apache-2.0 Programming Lang: Python Description : Google API client core library This library is not meant to be stand-alone. Instead it defines common helpers used by all Google API clients.
Bug#1009879: security update needed for pypdf2 in bullseye (CVE-2022-24859)?
Hi Daniel,
On Mon, Jan 16, 2023 at 6:38 AM Salvatore Bonaccorso wrote:
> On Sun, Jan 15, 2023 at 04:57:24PM -0500, Daniel Kahn Gillmor wrote:
> > I was looking into CVE-2022-24859 and pypdf2, and trying to figure out
> > whether the version in bullseye is still vulnerable, as it appears to be
> > according to the security tracker:
[...]
> It is still unfixed in bullseye TTBOMK, but would not warrant a DSA.
Indeed, it's not yet fixed for Bullseye and doesn't warrant a DSA as
the max impact is an infinite loop in the user's own process.
> Can you propose a fix for it with cherry-picking the pull request
> changes for the next bullseye point release?
Correct, it needs to go via Bullseye point update. I attached the
short change which has the original commit as Salvatore noted.
Sorry for the noise,
Laszlo/GCS
diff -Nru pypdf2-1.26.0/debian/changelog pypdf2-1.26.0/debian/changelog
--- pypdf2-1.26.0/debian/changelog 2020-01-19 09:08:58.0 +0100
+++ pypdf2-1.26.0/debian/changelog 2023-01-16 07:22:11.0 +0100
@@ -1,3 +1,10 @@
+pypdf2 (1.26.0-4+deb11u1) bullseye; urgency=high
+
+ * Backport fix for CVE-2022-24859: manipulated inline images can cause
+infinite loop (closes: #1009879).
+
+ -- Laszlo Boszormenyi (GCS) Mon, 16 Jan 2023 07:22:11 +0100
+
pypdf2 (1.26.0-4) unstable; urgency=medium
* Remove Python 2 from build dependencies (closes: #937505).
diff -Nru pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch
--- pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch 1970-01-01 01:00:00.0 +0100
+++ pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch 2023-01-16 00:10:42.0 +0100
@@ -0,0 +1,64 @@
+From d71fb3e6249a07682e8ebc456e26499923ff9031 Mon Sep 17 00:00:00 2001
+From: Sebastian Krause
+Date: Fri, 15 Apr 2022 13:55:29 +0200
+Subject: [PATCH] SEC/PERF: ContentStream_readInlineImage (#740)
+
+Closes #329 - potential infinite loop (SEC)
+Closes #330 - performance issue of ContentStream._readInlineImage (PERF)
+---
+ PyPDF2/pdf.py | 32 ++--
+ 1 file changed, 22 insertions(+), 10 deletions(-)
+
+diff --git a/PyPDF2/pdf.py b/PyPDF2/pdf.py
+index 5bd4b7968..6d1824384 100644
+--- a/PyPDF2/pdf.py
b/PyPDF2/pdf.py
+@@ -2723,11 +2723,25 @@ def _readInlineImage(self, stream):
+ # left at beginning of ID
+ tmp = stream.read(3)
+ assert tmp[:2] == b_("ID")
+-data = b_("")
++data = BytesIO()
++# Read the inline image, while checking for EI (End Image) operator.
+ while True:
+-# Read the inline image, while checking for EI (End Image) operator.
+-tok = stream.read(1)
+-if tok == b_("E"):
++# Read 8 kB at a time and check if the chunk contains the E operator.
++buf = stream.read(8192)
++# We have reached the end of the stream, but haven't found the EI operator.
++if not buf:
++raise utils.PdfReadError("Unexpected end of stream")
++loc = buf.find(b_("E"))
++
++if loc == -1:
++data.write(buf)
++else:
++# Write out everything before the E.
++data.write(buf[0:loc])
++
++# Seek back in the stream to read the E next.
++stream.seek(loc - len(buf), 1)
++tok = stream.read(1)
+ # Check for End Image
+ tok2 = stream.read(1)
+ if tok2 == b_("I"):
+@@ -2744,14 +2758,12 @@ def _readInlineImage(self, stream):
+ stream.seek(-1, 1)
+ break
+ else:
+-stream.seek(-1,1)
+-data += info
++stream.seek(-1, 1)
++data.write(info)
+ else:
+ stream.seek(-1, 1)
+-data += tok
+-else:
+-data += tok
+-return {"settings": settings, "data": data}
++data.write(tok)
++return {"settings": settings, "data": data.getvalue()}
+
+ def _getData(self):
+ newdata = BytesIO()
diff -Nru pypdf2-1.26.0/debian/patches/series pypdf2-1.26.0/debian/patches/series
--- pypdf2-1.26.0/debian/patches/series 2016-09-05 19:14:14.0 +0200
+++ pypdf2-1.26.0/debian/patches/series 2023-01-16 00:13:06.0 +0100
@@ -1 +1,2 @@
Prevent_infinite_loop_in_readObject.patch
+CVE-2022-24859.patch
Bug#1028027: vice: contains non-free font file
Hi Bastian, On Fri, Jan 6, 2023 at 3:00 AM Bastian Germann wrote: > The package includes C64_Pro_Mono-STYLE.ttf which has a non-free license. > So please repack to get rid of it. As your package is in contrib, you can > easily extract it to a new non-free package and depend on it. I have to check if a contrib package can or should depend on a non-free one. At the moment I don't like the idea and switch back to the previous free one instead. Thanks for the note anyway, Laszlo/GCS
Bug#1028559: pypdf2: replace with pypdf
Hi Daniel, On Fri, Jan 13, 2023 at 1:36 AM Daniel Kahn Gillmor wrote: > looks like PyPDF2 2.12.1 is the last version before a major > (backward-incompatible) change in 3.0.0. and PyPDF2 3.0.0 itself > indicates that it is deprecated in favor of pypdf 3.x Indeed, that's the last backward compatible release. > I've prepared some packaging for PyPDF2 2.12.1-0.1 and put it in salsa > at https://salsa.debian.org/debian/pypdf Cool! But I still haven't checked. Hopefully I will check tomorrow morning. > If that's someplace that you'd be up for collaborating, i'd be happy to > help out on it with you there. I'm not sure if we know each other, but I have the knowledge that you are a nice guy. Sure, I'm open to collaboration and Salsa is a good place to start. > We can probably also use the same repository (just different branches) > for packaging pypdf, since i would expect that packaging to just inherit > directly from the pypdf2 packaging, and it can be nice to have the > history in the same location. I'm not sure what would be the best practices for this case, but definitely a continued packaging is preferred from my side. > Let me know if that's something you'd be up for collaboratong on, > László! I'm even open to you taking over the package and making me an uploader. > If you don't like it, i'm also happy to remove the repo from salsa. I > defer to you as the maintainer here. To be honest, I was going to look for an adopter for this package this summer, probably after migrating it to src:pypdf. If you are interested, even contributed already to the project then you are the best candidate. As noted, you can take over immediately while leaving me as an uploader for a while. Best, Laszlo/GCS
Bug#1027283: transition: tiff
On Tue, Jan 10, 2023 at 10:32 PM Sebastian Ramacher wrote: > On 2023-01-08 09:07:37 +0100, László Böszörményi wrote: > > Transition can start anytime upon RM decision. > > Please go ahead. Thanks, uploaded yesterday evening. Almost all builds are already done. Cheers, Laszlo/GCS
Bug#1027283: transition: tiff
On Sat, Dec 31, 2022 at 1:04 PM Sebastian Ramacher wrote: > On 2022-12-29 18:19:58 +0100, László Böszörményi wrote: > > As tiff is used commonly and has security issues from time to time it > > would be good to have its latest release in Debian. I don't know if > > the old version will get any fixes or not. > > Understood. Please let us know once you're done with the test rebuilds > and have filed all bugs. The situation has improved: gtk4 has been fixed and I've provided drop-in patches for the other two, qtimageformats-opensource-src and hylafax. Transition can start anytime upon RM decision. Regards, Laszlo/GCS
Bug#1028118: transition: rocksdb
On Sat, Jan 7, 2023 at 11:53 AM Sebastian Ramacher wrote: > On 2023-01-07 08:42:37 +0100, László Böszörményi wrote: > > I hope this transition gets green light despite this dependency > > problem that needs to be resolved anyway. Main reason is a specific > > memory corruption error fix in the 7.8.1 version of RocksDB. > > Please go ahead. Thanks, uploaded and just got accepted. Cheers, Laszlo/GCS
