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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1026628: pyro4: FTBFS: AssertionError: must fail
Control: tags -1 +pending Hi, On Mon, Jan 2, 2023 at 4:15 PM Bo YU wrote: > Although skip failed test cases are not perfect solution to fix such > issues, but upstream has decided to end pyro4's life on python3.10. I > think it is ok to skip these failed test cases on python 3.10. There is > no sense to patch test files if in order to pass these failed cases. If > to fix pyro4's core code, I am not sure if how many work need to be > finished. Just confirmed, your patch fixes this issue. Thanks for your contribution! > PS: I would like to package pyro5 if it makes sense.:) Do you have packaging experience? Can you do it in a day or two? Regards, Laszlo/GCS
Bug#1027017: pillow: FTBFS docs/_build/html not present
Source: pillow Version: 9.2.0-1.1 Severity: serious Justification: FTBFS Usertags: tiff4_5 Tags: sid bookworm ftbfs Hi, During a rebuild of your package, pillow fails to build due to: dh_installdocs -i dh_installdocs -ppython-pil-doc docs/_build/html dh_installdocs: warning: Cannot auto-detect main package for python-pil-doc. If the default is wrong, please use --doc-main-package cp: cannot stat 'docs/_build/html': No such file or directory dh_installdocs: error: cp --reflink=auto -a docs/_build/html debian/python-pil-doc/usr/share/doc/python-pil-doc returned exit code 1 make: *** [debian/rules:126: binary-indep] Error 25 Please take care of it soon as the Bookworm freeze is approaching. Regards, Laszlo/GCS
Bug#1026044: libodsstream-dev: FTBFS for other packages
Source: libodsstream Version: 0.9.0-1 Severity: serious Justification: breaks unrelated software Usertags: tiff4_5 Tags: sid bookworm ftbfs Control: affects -1 src:beads Hi, During a rebuild of beads I realised it fails to build due to: [ 64%] Building CXX object src/CMakeFiles/beads.dir/beads.cpp.o cd beads-1.1.20/obj-x86_64-linux-gnu/src && /usr/bin/c++ -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_XML_LIB -I"beads-1.1.20/src/\$beads-1.1.20/src/cimg" -I/usr/include/include/libpng -I/usr/lib/x86_64-linux-gnu -Ibeads-1.1.20/src/cimg -isystem /usr/include/odsstream -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -g -O2 -ffile-prefix-map=beads-1.1.20=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Dcimg_use_tiff -Dcimg_use_jpeg -Dcimg_use_zlib -Dcimg_use_png -Dcimg_use_tiff -Dcimg_use_jpeg -Dcimg_use_zlib -Dcimg_use_png -fPIC -std=gnu++17 -MD -MT src/CMakeFiles/beads.dir/beads.cpp.o -MF CMakeFiles/beads.dir/beads.cpp.o.d -o CMakeFiles/beads.dir/beads.cpp.o -c beads-1.1.20/src/beads.cpp [...] In file included from beads-1.1.20/src/beads.cpp:22: /usr/include/odsstream/odsdocwriter.h:26:10: fatal error: quazip/quazip.h: No such file or directory 26 | #include | ^ compilation terminated. Quick check shows your package build depends on libquazip1-qt6-dev and indeed it uses that headers and libraries. But your libodsstream-dev package doesn't pull in that library development package to build with for other packages. Then the include will still fail due to using quazip/quazip.h as the include path when it's QuaZip-Qt6-1.3/quazip/quazip.h (i.e. one more directory deep). Regards, Laszlo/GCS [1] https://salsa.debian.org/debichem-team/libodsstream/-/blob/master/debian/control#L11
Bug#1024674: libphonenumber8: breaks Evolution
On Wed, Nov 23, 2022 at 6:52 AM tony mancill wrote: > This issue goes away for me after a rebuild of src:evolution-data-server > and installing the freshly rebuilt libebook-contacts-1.2-4. > > Maybe we can kick off a rebuild via the transition. If not that, would > you be willing to do a sourceful upload Jeremy? Just for the record, he asked for a evolution-data-server binNMU [1] for this issue. No sourceful upload will be needed. Regards, Laszlo/GCS [1] https://bugs.debian.org/1024726
Bug#1023963: protobuf FTBFS with Python 3.11 as supported version
Control: tags -1 -experimental Hi, On Sun, Nov 13, 2022 at 10:45 AM Adrian Bunk wrote: > Source: protobuf > Version: 3.12.3-2 > Severity: serious > Tags: ftbfs Thanks for the heads-up. Package in experimental is fixed, hopefully its transition [1] will happen soon. Regards, Laszlo/GCS [1] https://bugs.debian.org/1023535
Bug#1021790: src:graphicsmagick: fails to migrate to testing for too long: FTBFS on mips64el
Hi, On Sat, Oct 15, 2022 at 10:15 PM Marti Maria wrote: > Final 2.14 release is expected on end of October-22. I moved from November > to October because the Debian maintainer request. For the record, someone found the real reason. As I understand it, it was a GCC 11 miscompilation of lcms2. Someone in the background scheduled it to rebuild with the message: "Rebuild with GCC 12 for apparent misbuild on mips64el with GCC 11". Then the build of GraphicsMagick was successful even on mips64el with the now GCC 12 built lcms2. In short, there's no rush to release lcms2 v2.14 soon anymore. Thanks to everyone involved, Laszlo/GCS
Bug#1021790: src:graphicsmagick: fails to migrate to testing for too long: FTBFS on mips64el
Hi Paul, Marti, On Fri, Oct 14, 2022 at 9:09 PM Paul Gevers wrote: > The Release Team considers packages that are out-of-sync between testing > and unstable for more than 60 days as having a Release Critical bug in > testing [1]. Your package src:graphicsmagick has been trying to migrate > for 61 days [2]. Hence, I am filing this bug. Your package failed to > build from source on mip64el while it built successfully there in the past. It's 'only' 37 days, but that's long enough even. > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. I totally agree. Then of course I've already gone on and investigated this issue with its upstream developer. Turns out it's a regression in src:lcms2 and already fixed in its Git HEAD. Its upstream developer (Cc-d) noted there might be a new release soon. How do you see it now Marti? Do you know which commit might it be so I can ask the lcms2 maintainer to backport it to the Debian package instead? Thanks, Laszlo/GCS
Bug#1021622: libwxsqlit3-3.0-dev: not coinstallable
On Wed, Oct 12, 2022 at 10:36 PM Olly Betts wrote: > On Tue, Oct 11, 2022 at 11:28:53PM +0200, Sebastian Ramacher wrote: > > The following packages have unmet dependencies: > > libwxsqlite3-3.2-dev : Breaks: libwxsqlite3-3.0-dev but 3.4.1~dfsg-8 is to > > be installed > > E: Unable to correct problems, you have held broken packages > > The problem here is due to this in debian/control in the source package: [...] > (We've also resolved the only such package in Debian already, but this > may be relevant for downstream distros such as Ubuntu if they have > packages we don't.) [...] > Happy to NMU a fix for this. Thanks, but libwxsqlite3-3.0-dev is about to stay for a little longer. Then a fixed package is already uploaded and waiting to be accepted. Thanks, Laszlo/GCS
Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25
On Tue, Sep 20, 2022 at 7:26 PM Bill Deegan wrote: > Not sure I entirely understand. > Are you saying that SCons 4.4.0 is installing something in /usr/local/bin > instead of /usr/bin/ ? Yes, all executables go to /usr/local/bin directory. > What command are you using to install SCons which is causing this? I downloaded the Git tag 4.4.0 from GitHub. Then: $ tar zxf 4.4.0.tar.gz $ cd scons-4.4.0/ $ touch scons.1 sconsign.1 scons-time.1 $ mkdir out/ $ python3 setup.py install --prefix=/usr --install-data=/usr/share/man/man1/ --root=out/ Output ends with: reating out/usr/share creating out/usr/share/man creating out/usr/share/man/man1 copying scons.1 -> out/usr/share/man/man1/. copying scons-time.1 -> out/usr/share/man/man1/. copying sconsign.1 -> out/usr/share/man/man1/. running install_egg_info Copying SCons.egg-info to out/usr/local/lib/python3.10/dist-packages/SCons-4.4.0-py3.10.egg-info running install_scripts Installing scons script to out/usr/local/bin Installing scons-configure-cache script to out/usr/local/bin Installing sconsign script to out/usr/local/bin Additional info: python3 --version Python 3.10.7 Currently I don't know where the additional local subdirectory comes from. Regards, Laszlo/GCS
Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25
On Sun, Sep 18, 2022 at 6:42 PM Bill Deegan wrote: > SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python 3.10. > The latest SCons 4.4.0 is available and works fine with Python 3.10 Actually it's not a compatibility issue, but a behaviour change with Python 3.10 as I know. It (or some module) now installs binaries into /usr/local/bin instead of the normal /usr/bin path. Packaged SCons 4.4.0 and it fails the same way due to installing binaries under /usr/local/bin directory. For the moment I don't know how to skip 'local' from the installation path, but will move back binaries directly after installation. Regards, Laszlo/GCS
Bug#1020082: scons: FTBFS: make: *** [debian/rules:10: binary] Error 25
Control: tags -1 +pending On Sun, Sep 18, 2022 at 6:42 PM Bill Deegan wrote: > SCons 4.0.1 is fairly old and doesn't seem to be compatible with Python 3.10. > The latest SCons 4.4.0 is available and works fine with Python 3.10 Indeed, the update is long overdue. Will try to do that tomorrow. Regards, Laszlo/GCS
Bug#1019158: graphicsmagick breaks gnudatalanguage autopkgtest: undefined symbol: _ZN6Magick5Image12colorMapSizeEv
On Tue, Sep 6, 2022 at 2:06 AM Bob Friesenhahn wrote: > Mercurial changeset 16739:a152f76afeab restores non-const > Image::colorMapSize() while still providing the new const version. Confirmed, this fixes the current ABI breakage. > I think that this should solve the problem. Please let me know if it > doesn't or there is some new problem. I'm going to upload this Mercurial snapshot and will see how it builds and works. Thanks, Laszlo/GCS
Bug#1019158: graphicsmagick breaks gnudatalanguage autopkgtest: undefined symbol: _ZN6Magick5Image12colorMapSizeEv
On Mon, Sep 5, 2022 at 4:09 PM Bob Friesenhahn wrote: > On Sun, 4 Sep 2022, Paul Gevers wrote: > > gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: > > undefined symbol: _ZN6Magick5Image12colorMapSizeEv > > This issue is caused by Mercurial changeset 16712:acb5f7fa99cf: > > "colorMapSize() method for returning the number of colormap entries > should be a const method." > > Apparently this change impacts the ABI. How do you plan to solve this problem? Seems you either revert it or the library needs a soname bump. Regards, Laszlo/GCS
Bug#1019158: graphicsmagick breaks gnudatalanguage autopkgtest: undefined symbol: _ZN6Magick5Image12colorMapSizeEv
On Sun, Sep 4, 2022 at 10:27 PM Paul Gevers wrote: > With a recent upload of graphicsmagick the autopkgtest of > gnudatalanguage fails in testing when that autopkgtest is run with the > binary packages of graphicsmagick from unstable. I will check this and see what may cause it. > I copied some of the output at the bottom of this report. It looks like > graphicsmagick dropped a symbol that was actually used. Was that a mistake? According to my double check, no symbol was removed. Quite the opposite, one (IsEventLogged@Base) was added. > Currently this regression is blocking the migration of graphicsmagick to > testing [1]. Can you please investigate the situation? Nope, at least the first reason it's not migrating its FTBFS on mips64el. Already contacted upstream and it's not yet known what causes it. Might be some floating point issue on that architecture. > gdl: symbol lookup error: /lib/x86_64-linux-gnu/libgnudatalanguage.so.0: > undefined symbol: _ZN6Magick5Image12colorMapSizeEv Strange, I might think it's somehow related to GCC 12 changes. Regards, Laszlo/GCS
Bug#864423: Software RAID is not activated at boot time
On Wed, Aug 3, 2022 at 1:44 AM Chris Hofstaedtler wrote: > * Holger Wansing [220802 23:37]: > > I have merged the merge requests filed by Chris (partman-base, partman-auto, > > hw-detect, grub-installer). > > > > The packages build fine with those changings. > > And a locally built mini.iso with those changings in local udebs also > > installs fine (default install) in QEMU VM. Cool! > I'm attaching a draft patch to drop udebs from src:dmraid. Maybe you > want to use this as a starting point, László? Thanks. While I can remove udebs myself, let's speed up and I'll upload your changes immediately. Regards, Laszlo/GCS
Bug#864423: Software RAID is not activated at boot time
Hi all, On Sat, Jul 30, 2022 at 1:50 PM Chris Hofstaedtler wrote: > whats the status of dmraid? Do you have dmraid hardware or is this > merely on life-support? Please note dmraid upstream is dead for more than ten years. I might find an old i386 hardware that needs it. But yes, it's only on life-support. > * Paul Gevers : > > What would you say about this? Even if d-i would not need it anymore, we > > would need work to drop the dependency chain via > > libblockdev/udisks2/gnome-control-center. Do these have real use of dmraid, tested from time to time at least? > I'm wondering if we should remove dmraid support from the d-i as a > first step. AFAICT Intel Software RAID is supported by mdraid, not > sure if the other RAID platforms are still sold. Sounds like a good idea. This will show users early Debian doesn't plan to ship it anymore. > If its gone from di-i, at least no new installs can spring into > existence "by accident", i.e. where mdraid would have been the > better choice. Exactly. Regards, Laszlo/GCS
Bug#1010821: pypdf2 breaks xml2rfc autopkgtest: lxml.etree.XMLSyntaxError: PCDATA invalid Char value 1
Version: 2.6.0-1 On Tue, May 10, 2022 at 9:57 PM Paul Gevers wrote: > With a recent upload of pypdf2 the autopkgtest of xml2rfc fails in > testing when that autopkgtest is run with the binary packages of pypdf2 > from unstable. This was fixed in the recent pypdf2 upload, but forgot to close this bug report. Laszlo/GCS
Bug#1015191: vice: FTBFS against ffmpeg 5
Control: severity -1 important Hi Andreas, On Sun, Jul 17, 2022 at 2:39 PM Andreas Beckmann wrote: > vice FTBFS against ffmpeg 5: Indeed. Upstream says there will be no support for two FFmpeg releases. Until 4.3.x+ is alive and well, there will be no 5.y support. Thus already uploaded a vice update which disables FFmpeg support, not to fail with 5.y until then. I let this bug report open until the support lands for that. Regards, Laszlo/GCS
Bug#1015098: nng: FTBFS: Errors while running CTest
Control: tags -1 +moreinfo +unreproducible Control: severity -1 important Hi Lucas, On Sat, Jul 16, 2022 at 4:03 PM Lucas Nussbaum wrote: > Source: nng > > During a rebuild of all packages in sid, your package failed to build > on amd64. Unfortunately I can't reproduce it. Tried in several ways. Do you have time to repeat your build process and see if it builds this time? Thanks, Laszlo/GCS
Bug#1013877: Bug#1012825: Removed symbol without major SONAME bump
Control: merge 1013877 1013878 On Sun, Jun 26, 2022 at 2:18 PM László Böszörményi (GCS) wrote: > See the attached patch, basically it's a one liner. Sergei just needs > to add it to the libtk-img package source. Then it's just one bug, sorry for the duplication. As soon as Sergei uploads this fix, linuxcnc will work again as well. Just a note that tiff will no longer export its private functions, breaking libtk-img entirely. Of course, tiff upstream reported it for libtk-img. See its bug tracker [1]. Hope this helps, Laszlo/GCS [1] https://sourceforge.net/p/tkimg/bugs/109/
Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump
Control: tags 1012825 -patch
Control: clone 1012789 -1
Control: reassign -1 libtk-img
Control: retitle -1 libtk-img: add _TIFFsetString to its internal tiff library
Control: tags -1 +patch
On Sat, Jun 25, 2022 at 5:07 PM Petter Reinholdtsen wrote:
> While it might sound sensible on the surface, the realities is that the
> libraries binary interface (aka ABI) changed, removing a public symbol
> from the library. Such API change require a no major SONAME number to
> avoid breaking programs using the library.
You are right that removing public symbols from a library interface
is an ABI break and requires a SONAME change. Per coding standards
function names starting with underscore are part of the private API
and a) not to be used outside of the library, b) if used nevertheless,
it's accepted that the other code can break anytime.
> It is not linuxcnc-uspace that is using it. It is the tcl/tk Img
> library. To test for yourself, try running 'wish' and give it the
> 'package require Img' command to load the Img library. linuxcnc do the
> equivalent loading, but using the python Tk library.
Yup, I was tricked by the bug reports. . In this case, the Python Tk
library must follow the internal change of tiff.
> Removing the symbol without bumping the SONAME made it impossible for
> programs using the symbol to keep the old working library version. This
> was the ratinale for my severity setting critical. Given that the
> symbol removal without bumping SONAME broken libtk-img and linuxcnc,
> what is your argument for lowering the severity to normal?
First of all, critical is used for several issues like making the
system unbootable or causing huge data loss. That's not the case. Then
as noted above, projects using others internal structures and/or
functions must follow that when the latter changes.
What you proposed is to diverge from tiff upstream and adding back the
mentioned function, then forcing a SONAME change, doing a transition
with over two hundred code rebuilds on fourteen architectures. This
makes no sense.
As noted above, the Python Tk library copies an internal tiff function
and probably not just one but a whole set of those (just check its
compat/libtiff/libtiff source directory). It must accept to follow
tiff development and act on such changes. Especially that the
mentioned removed function is a one liner, being a wrapper for another
function. If libtk-img needs that function, right. Copy it to their
code like it copied others already.
See the attached patch, basically it's a one liner. Sergei just needs
to add it to the libtk-img package source.
Regards,
Laszlo/GCS
Description: add _TIFFsetString function for being removed from tiff
The _TIFFsetString private function was internal of tiff and removed in
tiff 4.4.0+ versions. As Tk library used it in its source, copy the function
to its source.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-06-25
---
--- libtk-img-1.4.13+dfsg.orig/compat/libtiff/libtiff/tif_unix.c
+++ libtk-img-1.4.13+dfsg/compat/libtiff/libtiff/tif_unix.c
@@ -352,6 +352,12 @@ _TIFFmemcmp(const void* p1, const void*
return (memcmp(p1, p2, (size_t) c));
}
+void
+_TIFFsetString(char** cpp, char* cp)
+{
+ _TIFFsetByteArray((void**) cpp, (void*) cp, strlen(cp)+1);
+}
+
static void
unixWarningHandler(const char* module, const char* fmt, va_list ap)
{
Bug#1012789: Bug#1012825: Removed symbol without major SONAME bump
Control: tags 1012825 patch Control: severity 1012825 normal Control: unblock 1012789 by 1012825 On Fri, Jun 24, 2022 at 11:57 AM Petter Reinholdtsen wrote: > Until upstream decide to reinsert the symbol or bump the SONAME, I > suggest to carry this patch. It should get the broken packages in > Debian working again. As noted by libtiff upstream as well, this function was internal of tiff and its declaration was in a header file that was not installed publicly. They could change that without prior notice. If linuxcnc-uspace still wants to use it, then copy that function[1] and its details to their source tree. They already done copying with the _TIFFsetString() function declaration. Then I can add a break for its older versions for tiff. Regards, Laszlo/GCS [1] https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tif_dir.c#L43
Bug#1012804: rocksdb: Please build against liblz4-dev
Control: reassign 1012629 rocksdb Control: found 1012629 7.2.2-3 Control tags -1 -patch Control: merge -1 1012629 On Tue, Jun 14, 2022 at 3:33 PM Benjamin Drung wrote: > The autopkgtest for balboa fails against rocksdb 7.2.2-3 with: > > rocksdb_open() failed: `Invalid argument: Compression type LZ4 is not > linked with the binary.` Thanks, but it's a duplicated bug report. I'm going to fix this soon. Regards, Laszlo/GCS
Bug#1011416: freeimage: FTBFS with tiff 4.4.0+
Source: freeimage
Version: 3.18.0+ds2-6
Severity: serious
Justification: FTBFS
Tags: ftbfs upstream bookworm sid
Hi,
With the upcoming release (4.4.0) of tiff your package FTBFS due to
using tiff internal API:
Source/Metadata/XTIFF.cpp:745:38: error: '_TIFFDataSize' was not
declared in this scope; did you mean 'TIFFDataType'?
745 |
if((unsigned)_TIFFDataSize(tif_tag_type) !=
FreeImage_TagDataWidth(tag_type)) {
| ^
| TIFFDataType
Reason is that tiff internal is changed [1] and _TIFFDataSize() became
a public API but with a different function signature. It's now
TIFFFieldSetGetSize(const TIFFField* fip).
It seems your upstream is dead, but try to get it fixed.
Regards,
Laszlo/GCS
[1]
https://gitlab.com/libtiff/libtiff/-/commit/11f3f279608ae9e68f014717393197f430f9be58
Bug#1011242: thrift: No depends on libssl after rebuild against OpenSSL 3.0
Control: tags -1 +unreproducible On Wed, May 18, 2022 at 7:39 PM Kurt Roeckx wrote: > It seems that thrift does not depend on libssl after being rebuild > against OpenSSL 3.0, but did depend on libssl1.1. Are you sure? Which architecture did you check? I just checked amd64 [1], mipsel [2] and armel [3]. All three shows: libthrift-0.16.0_0.16.0-5_[architecture].deb Depends: [...] libqt5network5 (>= 5.0.2), libssl3 (>= 3.0.0), libstdc++6 (>= 12.1.0-2), [...] and libthrift-c-glib0_0.16.0-5_[architecture].deb Depends: [...] libglib2.0-0 (>= 2.37.3), libssl3 (>= 3.0.0), [...] Regards, Laszlo/GCS [1] https://buildd.debian.org/status/fetch.php?pkg=thrift=amd64=0.16.0-5=1652635345=0 [2] https://buildd.debian.org/status/fetch.php?pkg=thrift=mipsel=0.16.0-5=1652668192=0 [3] https://buildd.debian.org/status/fetch.php?pkg=thrift=armel=0.16.0-5=1652637646=0
Bug#1006245: libwebsockets: FTBFS with OpenSSL 3.0
On Tue, May 10, 2022 at 2:00 AM Bastian Germann wrote: > Upstream's changelog says in v4.2.0: > "prepared for openssl v3 compatibility, for main function and GENCRYPTO" > > So please import that or a later version. While that may provide OpenSSL 3.0+ support, 'prepared' doesn't mean (for me at least) that it's finished work. Most importantly please note that 4.1.6 (already in experimental) needs a transition on its own and while I've packaged 4.3.0 locally that means a package split. Meaning uploading the latter would need sourceful upload for its reverse dependencies (adopt for the new packages). As I don't want to delay the OpenSSL transition, I am going to fix the building of the Sid (4.0.20) version. Then will do the 4.3.1 transition. Regards, Laszlo/GCS
Bug#1010118: qtwebkit-opensource-src FTBFS with ICU 71.1
Control: tags -1 +patch
On Sun, Apr 24, 2022 at 10:18 PM Adrian Bunk wrote:
> Source: qtwebkit-opensource-src
> Version: 5.212.0~alpha4-14
> Severity: serious
> Tags: ftbfs
>
> In file included from
> /<>/Source/WebCore/platform/text/TextAllInOne.cpp:31:
> /<>/Source/WebCore/platform/text/TextCodecICU.cpp: In member
> function ‘void WebCore::TextCodecICU::createICUConverter() const’:
> /<>/Source/WebCore/platform/text/TextCodecICU.cpp:311:42: error:
> ‘TRUE’ was not declared in this scope
> 311 | ucnv_setFallback(m_converterICU, TRUE);
> | ^~~~
> ...
My bad, submitting the required patch only now.
Regards,
Laszalo/GCS
Description: replace old ICU TRUE / FALSE constants
For some time ICU (since 68.1+ for sure) no longer specify nonstandard
TRUE / FALSE constants. Use UBool(1) and UBool(0) instead.
Author: Laszlo Boszormenyi (GCS)
Bug-Debian: https://bugs.debian.org/1010118
Forwarded: no
Last-Update: 2022-04-24
---
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WebCore/platform/text/TextCodecICU.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WebCore/platform/text/TextCodecICU.cpp
@@ -308,7 +308,7 @@ void TextCodecICU::createICUConverter()
m_converterICU = ucnv_open(m_canonicalConverterName, );
ASSERT(U_SUCCESS(err));
if (m_converterICU)
-ucnv_setFallback(m_converterICU, TRUE);
+ucnv_setFallback(m_converterICU, UBool(1));
}
int TextCodecICU::decodeToBuffer(UChar* target, UChar* targetLimit, const char*& source, const char* sourceLimit, int32_t* offsets, bool flush, UErrorCode& err)
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WebCore/platform/text/icu/UTextProvider.h
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WebCore/platform/text/icu/UTextProvider.h
@@ -80,12 +80,12 @@ inline bool uTextAccessInChunkOrOutOfRan
// Ensure chunk offset is well formed if computed offset exceeds int32_t range.
ASSERT(offset < std::numeric_limits::max());
text->chunkOffset = offset < std::numeric_limits::max() ? static_cast(offset) : 0;
-isAccessible = TRUE;
+isAccessible = UBool(1);
return true;
}
if (nativeIndex >= nativeLength && text->chunkNativeLimit == nativeLength) {
text->chunkOffset = text->chunkLength;
-isAccessible = FALSE;
+isAccessible = UBool(0);
return true;
}
} else {
@@ -94,12 +94,12 @@ inline bool uTextAccessInChunkOrOutOfRan
// Ensure chunk offset is well formed if computed offset exceeds int32_t range.
ASSERT(offset < std::numeric_limits::max());
text->chunkOffset = offset < std::numeric_limits::max() ? static_cast(offset) : 0;
-isAccessible = TRUE;
+isAccessible = UBool(1);
return true;
}
if (nativeIndex <= 0 && !text->chunkNativeStart) {
text->chunkOffset = 0;
-isAccessible = FALSE;
+isAccessible = UBool(0);
return true;
}
}
--- qtwebkit-opensource-src-5.212.0~alpha4.orig/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp
+++ qtwebkit-opensource-src-5.212.0~alpha4/Source/WebCore/platform/text/icu/UTextProviderLatin1.cpp
@@ -100,23 +100,23 @@ static UBool uTextLatin1Access(UText* uT
if (index < uText->chunkNativeLimit && index >= uText->chunkNativeStart) {
// Already inside the buffer. Set the new offset.
uText->chunkOffset = static_cast(index - uText->chunkNativeStart);
-return TRUE;
+return UBool(1);
}
if (index >= length && uText->chunkNativeLimit == length) {
// Off the end of the buffer, but we can't get it.
uText->chunkOffset = static_cast(index - uText->chunkNativeStart);
-return FALSE;
+return UBool(0);
}
} else {
if (index <= uText->chunkNativeLimit && index > uText->chunkNativeStart) {
// Already inside the buffer. Set the new offset.
uText->chunkOffset = static_cast(index - uText->chunkNativeStart);
-return TRUE;
+return UBool(1);
}
if (!index && !uText->chunkNativeStart) {
// Already at the beginning; can't go any farther.
uText->chunkOffset = 0;
-return FALSE;
+return UBool(0);
}
}
@@ -144,7 +144,7 @@ static UBool uTextLatin1Access(UText* uT
uText->nativeIndexingLimit = uText->chunkLength;
-return TRUE;
+return UBool(1);
}
static int32_t uTextLatin1Extract(UText* uText, int64_t start, int64_t limit, UChar* dest, int32_t
Bug#1008810: thrift: FTBFS with Python 3.10
Control: tags -1 +pending On Sat, Apr 2, 2022 at 12:27 AM Stefano Rivera wrote: > Source: thrift > Version: 0.13.0-7 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > I see that thrift FTBFS now that Python 3.10 is default. > > GOPATH=`pwd`/gopath /usr/bin/go test thrift tests dontexportrwtest With all due respect, it's a Golang FTBFS and not a Python one. Already reported [1] and fixed in experimental. Waiting for the ACK on my transition request [2]. Hope it will be allowed soon and will close this bug report when I upload thrift to Sid. Regards, Laszlo/GCS [1] https://bugs.debian.org/1008458 [2] https://bugs.debian.org/1008823
Bug#1008150: libgrpc-dev: library name conflict with libupb-dev: libupb.so*
Control: tags -1 +pending On Wed, Mar 23, 2022 at 10:57 AM Andreas Beckmann wrote: > during a test with piuparts I noticed your package failed to install > because it tries to overwrite other packages files. [...] > upb and grpc seem to be two unrelated projects, unfortunately > grpc/experimental started to use a library name already used by upb. > They use different SOVERSIONs right now, so the conflict is only > on the .so link. Indeed, these are different projects. > Adding mutual Conflicts is not a valid solution here! For the moment, it will be my option. :-/ It seems upb is not fully mature and recently I can't install it with cmake. Might be the reason gRPC started to bundle upb and build with that exact snapshot version. Regards, Laszlo/GCS
Bug#1006110: graphicsmagick: FTBFS on mipsel: test failure
Control: reassign -1 libwebp7 1.2.1-7 Control: affects -1 src:graphicsmagick Control: tags -1 +bookworm +patch +sid +upstream Control: forwarded -1 https://bugs.chromium.org/p/webp/issues/detail?id=558 On Sat, Feb 19, 2022 at 10:51 AM Sebastian Ramacher wrote: > graphicsmagick FTBFS on mipsel: For a bug in src:libwebp which is filed and has an upstream fix. Diff is at: https://chromium.googlesource.com/webm/libwebp/+/e4cbcdd2b5ff33a64f97fe49d67fb56f915657e8%5E%21/ Hope the package maintainer will apply it soon. Laszlo/GCS
Bug#1006666: emacsql-sqlite3: FTBFS with SQLite3 3.38.0+
Source: emacsql-sqlite3 Version: 1.0.2-1 Severity: serious Tags: bookworm sid ftbfs patch Hi, Your package fails to build with SQLite 3.38.0; the reason is simple. The output for creating an already existing table changed from 'Error:' to 'Parse error'. The attached patch updates the source accordingly. Regards, Laszlo/GCS Description: fix build with SQLite3 3.38.0+ It changed the error message for creating an already existing table. Forwarded: no Author: Laszlo Boszormenyi (GCS) Last-Update: 2022-03-01 --- --- emacsql-sqlite3-1.0.2.orig/emacsql-sqlite3.el +++ emacsql-sqlite3-1.0.2/emacsql-sqlite3.el @@ -214,7 +214,7 @@ each arg will be quoted first." (cl-defmethod emacsql-parse ((conn emacsql-sqlite3-connection)) (with-current-buffer (emacsql-buffer conn) (goto-char (point-min)) -(if (looking-at (rx "Error: " (group (1+ any)) eol)) +(if (looking-at (rx "Parse error " (group (1+ any)) eol)) (signal 'emacsql-error (list (match-string 1))) (cl-macrolet ((sexps-in-line! () `(cl-loop until (looking-at "\n")
Bug#1006374: graphicsmagick breaks ruby-mini-magick autopkgtest: Failure/Error: expect(subject["EXIF:Flash"]).to eq "0"
On Sat, Feb 26, 2022 at 4:56 PM Bob Friesenhahn wrote: > I believe that the problem is that mini-magick is retrieving EXIF > attributes in 'ping' mode but the changeset which caused the problem > only returns the attributes if the image data was read. The solution > was just to move some code. Indeed, that was it. Packaged and going to upload the package soon. > The purpose of 'ping' mode is to avoid expensive operations while > retrieving basic properties. In this particular case, the harm would > already have been done even in 'ping' mode so returning the profiles > does not incur any additional cost. Thanks for the explanation and for the fix itself. Regards, Laszlo/GCS
Bug#1006374: graphicsmagick breaks ruby-mini-magick autopkgtest: Failure/Error: expect(subject["EXIF:Flash"]).to eq "0"
On Fri, Feb 25, 2022 at 4:35 PM Bob Friesenhahn wrote: > On Fri, 25 Feb 2022, László Böszörményi (GCS) wrote: > > Wild guess only, as I'm away from home right now. But that image can > > be exif.jpg [1] or any other from the 'fixtures' directory. > > [1] > > https://salsa.debian.org/ruby-team/ruby-mini-magick/-/blob/master/spec/fixtures/exif.jpg > > This is what I get from 'gm identify -verbose exif.jpg' for the above > file on my system. Is the output different/failing on the targets > with the problem? This should be it. Is your GM the latest version from Mercurial? > Image: /home/bfriesen/src/minimagick.git/spec/fixtures/exif.jpg > Exif Version: 0220 > Date Time Original: 2016:11:12 09:17:56 > Flash: 0 Package ruby-mini-magick check tree values: EXIF:Flash, DateTimeOriginal and ExifVersion. With GM 1.3.37 it succeeds and gets real values in order 0, a string and 0220 just like in your dump. But with the mentioned GM commit the results are in order "", nil and nil. Maybe the GM output or its variable types changed somehow and now ruby-mini-magick can't parse that? Needs more investigation. I think tomorrow in the evening (CET) I will arrive back home and will try to support you with more details. Regards, Laszlo/GCS
Bug#1006374: graphicsmagick breaks ruby-mini-magick autopkgtest: Failure/Error: expect(subject["EXIF:Flash"]).to eq "0"
On Fri, Feb 25, 2022 at 3:45 PM Bob Friesenhahn wrote: > On Thu, 24 Feb 2022, Dan Bungert wrote: > > I investigated debbug 1006374 today and found that revision > > 16603:ba930c1fc380 > > of graphicsmagick appears to be causing the regression to ruby-mini-magick. > > A > > rebuild of graphicsmagick minus this commit allows ruby-mini-magick to pass > > autopkgtest. I did my testing against Ubuntu but expect the same results > > for > > Debian. [...] > What is the minimum that I need to do to reproduce the issue in > GraphicsMagick? > > Is the specific JPEG file which caused the issue available? Wild guess only, as I'm away from home right now. But that image can be exif.jpg [1] or any other from the 'fixtures' directory. Hope this helps, Laszlo/GCS [1] https://salsa.debian.org/ruby-team/ruby-mini-magick/-/blob/master/spec/fixtures/exif.jpg
Bug#1006219: new expat causes regressions in the python autopkg tests
Control: tags -1 +confirmed Hi Matthias, On Mon, Feb 21, 2022 at 2:57 PM Matthias Klose wrote: > The new expat causes regressions in the python autopkg tests. I also see there > is a new upstream 2.4.6. Didn't check that yet. Basically 2.4.5-2 and 2.4.6 should be identical. I can package the latter for you if you want. Will contact upstream about this and see what he finds. Regards, Laszlo/GCS
Bug#1006162: expat: autopkgtest regressions (from CVE-2022-25313 fix)
Control: tags -1 +confirmed Hi Salvatore, On Sun, Feb 20, 2022 at 8:15 AM Salvatore Bonaccorso wrote: > There appears to be regressions from the CVE-2022-25313 fix in 2.4.5. > They are known already upstream, cf. > https://github.com/NixOS/nixpkgs/pull/160826#issuecomment-1046074523 > > I will hold of the planned expat security release until this is > addressed. ACK, watching this GitHub issue and will update the package accordingly. Thanks, Laszlo/GCS
Bug#1005622: [Pkg-utopia-maintainers] Bug#1005622: libblockdev: FTBFS: dpkg-gensymbols: error: some new symbols appeared in the symbols file: see diff output below
Hi, Sorry for the symlink breakage. On Mon, Feb 14, 2022 at 6:54 PM Michael Biebl wrote: > While speaking of getting rid off unnecessary complexity: Is the > separate udeb build still needed? This is what I sometimes decide to evaluate, but then time goes on something else. :( Now I'm going to upload Helmut's fix, thanks for that! Regards, Laszlo/GCS
Bug#1003678: sqlite3 breaks crowdsec autopkgtest: invalid type \"INTEGER\" for column
Control: reassign -1 src:golang-github-facebook-ent
Control: found -1 0.5.4-2
Control: tags -1 +patch
Hi Paul,
On Thu, Jan 13, 2022 at 3:54 PM Paul Gevers wrote:
> With a recent upload of sqlite3 the autopkgtest of crowdsec fails in
> testing when that autopkgtest is run with the binary packages of sqlite3
> from unstable.
[...]
> Currently this regression is blocking the migration of sqlite3 to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
SQLite3 used to store column data types as text with the same case it
was created. So it could have been 'integer', 'INTEGER' or even
'IntEGEr'. But with 3.37.0 and onwards it's now stored as an
enumerated value [1] and always translated to uppercase column type
[2].
Then golang-github-facebook-ent only checks for lowercase [3] values.
Meaning it was wrong for previous SQLite3 versions even.
The attached patch fixes this.
Hope this helps,
Laszlo/GCS
[1] https://github.com/sqlite/sqlite/blob/version-3.37.0/src/global.c#L388
[2] https://github.com/sqlite/sqlite/blob/version-3.37.0/src/global.c#L396
[3] https://github.com/ent/ent/blob/v0.5.4/dialect/sql/schema/sqlite.go#L284
Description: SQLite3 3.37.0+ use uppercase column tupe names
Starting with SQLite3 3.37.0 it stores column type names as a value and
always displayed in uppercase letters.
Previously it stored type names as text with the same case as it was given.
This breaks testing where the column type is defined in lowercase and
expects it to be given back as-is.
Fix this with using type names in uppercase.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-13
---
--- golang-github-facebook-ent-0.5.4.orig/dialect/sql/schema/sqlite.go
+++ golang-github-facebook-ent-0.5.4/dialect/sql/schema/sqlite.go
@@ -281,7 +281,7 @@ func (d *SQLite) scanColumn(c *Column, r
if err != nil {
return err
}
- switch parts[0] {
+ switch strings.ToLower(parts[0]) {
case "bool", "boolean":
c.Type = field.TypeBool
case "blob":
Bug#1003345: ruby-sqlite3: FTBFS with SQLite3 3.37.0+
Source: ruby-sqlite3
Version: 1.4.2-3
Severity: serious
Tags: patch
Hi,
SQLite3 3.37.0 and onwards changed its inner working. Now table column
data types are stored as a value and always returned as uppercase
text. This breaks your package as it relies on the old behavior, when
this was stored as text and returned in a case it was defined.
As I broke it, I've created a fix for you, patch is attached.
Sorry for the inconvenience,
Laszlo/GCS
Description: SQLite3 3.37.0+ use uppercase column tupe names
Starting with SQLite3 3.37.0 it stores column type names as a value and
always displayed in uppercase letters.
Previously it stored type names as text with the same case as it was given.
This breaks testing where the column type is defined in lowercase and
expects it to be given back as-is.
Fix this with using type names in uppercase.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-08
---
--- ruby-sqlite3-1.4.2.orig/test/test_database.rb
+++ ruby-sqlite3-1.4.2/test/test_database.rb
@@ -268,12 +268,12 @@ module SQLite3
def test_table_info
db = SQLite3::Database.new(':memory:', :results_as_hash => true)
- db.execute("create table foo ( a integer primary key, b text )")
+ db.execute("create table foo ( a INTEGER primary key, b TEXT )")
info = [{
"name" => "a",
"pk" => 1,
"notnull"=> 0,
-"type" => "integer",
+"type" => "INTEGER",
"dflt_value" => nil,
"cid"=> 0
},
@@ -281,7 +281,7 @@ module SQLite3
"name" => "b",
"pk" => 0,
"notnull"=> 0,
-"type" => "text",
+"type" => "TEXT",
"dflt_value" => nil,
"cid"=> 1
}]
--- ruby-sqlite3-1.4.2.orig/test/test_integration.rb
+++ ruby-sqlite3-1.4.2/test/test_integration.rb
@@ -34,11 +34,11 @@ class TC_Database_Integration < SQLite3:
def test_table_info_without_defaults_for_version_3_3_8_and_higher
@db.transaction do
- @db.execute "create table no_defaults_test ( a integer default 1, b integer )"
+ @db.execute "create table no_defaults_test ( a INTEGER default 1, b INTEGER )"
data = @db.table_info( "no_defaults_test" )
- assert_equal({"name" => "a", "type" => "integer", "dflt_value" => "1", "notnull" => 0, "cid" => 0, "pk" => 0},
+ assert_equal({"name" => "a", "type" => "INTEGER", "dflt_value" => "1", "notnull" => 0, "cid" => 0, "pk" => 0},
data[0])
- assert_equal({"name" => "b", "type" => "integer", "dflt_value" => nil, "notnull" => 0, "cid" => 1, "pk" => 0},
+ assert_equal({"name" => "b", "type" => "INTEGER", "dflt_value" => nil, "notnull" => 0, "cid" => 1, "pk" => 0},
data[1])
end
end
--- ruby-sqlite3-1.4.2.orig/test/test_integration_resultset.rb
+++ ruby-sqlite3-1.4.2/test/test_integration_resultset.rb
@@ -4,7 +4,7 @@ class TC_ResultSet < SQLite3::TestCase
def setup
@db = SQLite3::Database.new(":memory:")
@db.transaction do
- @db.execute "create table foo ( a integer primary key, b text )"
+ @db.execute "create table foo ( a INTEGER primary key, b TEXT )"
@db.execute "insert into foo ( b ) values ( 'foo' )"
@db.execute "insert into foo ( b ) values ( 'bar' )"
@db.execute "insert into foo ( b ) values ( 'baz' )"
@@ -118,7 +118,7 @@ class TC_ResultSet < SQLite3::TestCase
end
def test_types
-assert_equal [ "integer", "text" ], @result.types
+assert_equal [ "INTEGER", "TEXT" ], @result.types
end
def test_columns
Bug#1003344: restfuldb: FTBFS with SQLite3 3.37.0+
Source: restfuldb
Version: 0.15.2+dfsg-2
Severity: serious
Tags: patch
Hi,
SQLite3 3.37.0 and onwards changed its inner working. Now table column
data types are stored as a value and always returned as uppercase
text. This breaks your package as it relies on the old behavior, when
this was stored as text and returned in a case it was defined.
As I broke it, I've created a fix for you, patch is attached. Couldn't
make it work with older SQLite3 versions thus you will need to build
depend on SQLite3 3.37.0 and newer.
Sorry for the inconvenience,
Laszlo/GCS
Description: SQLite3 3.37.0+ use uppercase column tupe names
Starting with SQLite3 3.37.0 it stores column type names as a value and
always displayed in uppercase letters.
Previously it stored type names as text with the same case as it was given.
This breaks testing where the column type is defined in lowercase and
expects it to be given back as-is.
Fix this with using type names in uppercase.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-08
---
--- restfuldb-0.15.2+dfsg.orig/tests/cases/Database.pm_007.sh
+++ restfuldb-0.15.2+dfsg/tests/cases/Database.pm_007.sh
@@ -31,8 +31,8 @@ trap "exit 1" HUP INT QUIT TERM
TMP_DB_MAIN="${TMP_DIR}/test.db"
-sqlite3 ${TMP_DB_MAIN} "create table parent(id int, name text)"
-sqlite3 ${TMP_DB_MAIN} "create table child(id int, parent_id int, FOREIGN KEY(parent_id) REFERENCES parent(id))"
+sqlite3 ${TMP_DB_MAIN} "create table parent(id INT, name TEXT)"
+sqlite3 ${TMP_DB_MAIN} "create table child(id INT, parent_id INT, FOREIGN KEY(parent_id) REFERENCES parent(id))"
sqlite3 ${TMP_DB_MAIN} "insert into parent values (1, 'first entry')"
sqlite3 ${TMP_DB_MAIN} "insert into parent values (2, 'second entry')"
sqlite3 ${TMP_DB_MAIN} "insert into child values (1, 1)"
--- restfuldb-0.15.2+dfsg.orig/tests/outputs/Database.pm_001.out
+++ restfuldb-0.15.2+dfsg/tests/outputs/Database.pm_001.out
@@ -1,11 +1,11 @@
$VAR1 = {
- 'image' => 'blob'
+ 'image' => 'BLOB'
};
$VAR1 = {
- 'caption' => 'text',
- 'description' => 'text',
- 'id' => 'integer',
- 'image' => 'blob'
+ 'caption' => 'TEXT',
+ 'description' => 'TEXT',
+ 'id' => 'INTEGER',
+ 'image' => 'BLOB'
};
-
$VAR1 = {
@@ -13,10 +13,10 @@ $VAR1 = {
'authors' => 'varchar',
'cdate' => 'date',
'ctime' => 'time',
- 'id' => 'integer',
- 'revision_id' => 'integer',
- 'title' => 'text',
- 'year' => 'integer'
+ 'id' => 'INTEGER',
+ 'revision_id' => 'INTEGER',
+ 'title' => 'TEXT',
+ 'year' => 'INTEGER'
};
$VAR1 = {
'PublicID' => '12',
--- restfuldb-0.15.2+dfsg.orig/tests/outputs/Database.pm_007.out
+++ restfuldb-0.15.2+dfsg/tests/outputs/Database.pm_007.out
@@ -5,7 +5,7 @@ $VAR1 = [
'coltype' => 'id',
'length' => undef,
'resolver' => undef,
-'sqltype' => 'int',
+'sqltype' => 'INT',
'value' => 1
},
'parent_id' => {
@@ -29,14 +29,14 @@ $VAR1 = [
'coltype' => 'id',
'length' => undef,
'resolver' => undef,
- 'sqltype' => 'int',
+ 'sqltype' => 'INT',
'value' => 1
},
'name' => {
'coltype' => undef,
'length' => undef,
'resolver' => undef,
- 'sqltype' => 'text',
+ 'sqltype' => 'TEXT',
'value' => 'first entry'
}
},
@@ -66,7 +66,7 @@ $VAR1 = [
},
'length' => undef,
'resolver' => undef,
-'sqltype' => 'int',
+'sqltype' => 'INT',
'value' => 1
}
},
@@ -89,7 +89,7 @@ $VAR1 = [
'coltype' => 'id',
'length' => undef,
'resolver' => undef,
-'sqltype' => 'int',
+'sqltype' => 'INT',
'value' => 1
},
'parent_id' => {
@@ -109,7 +109,7 @@ $VAR1 = [
}, 'Database::ForeignKey' ),
'length' => undef,
'resolver' => undef,
-'sqltype' => 'int',
+'sqltype' => 'INT',
'value' => 2
}
},
--- restfuldb-0.15.2+dfsg.orig/tests/outputs/Database.pm_012.out
+++ restfuldb-0.15.2+dfsg/tests/outputs/Database.pm_012.out
@@ -12,28 +12,28 @@ $VAR1 = [
'coltype' => 'id',
'length' => undef,
'resolver' => undef,
-'sqltype' => 'integer',
+'sqltype' => 'INTEGER',
'value' => 1
},
'locality' => {
'coltype' => undef,
'length' => undef,
'resolver' => undef,
-'sqltype' => 'text',
+'sqltype' => 'TEXT',
'value' => 'New Caledonia'
},
'mine' => {
Bug#998553: RC bug in libdbi-drivers
Hi Thorsten, On Wed, Jan 5, 2022 at 1:09 PM Thorsten Alteholz wrote: > are you already working on an upload of libdbi-drivers? Or do you need some > help? Did a quick check back then, but couldn't find the root cause. I couldn't devote more time to this issue since then. Maybe tomorrow I can check it. But of course, any help is appreciated. Regards, Laszlo/GCS
Bug#1002551: sqlite3-tools: missing Breaks+Replaces: sqlite3 (<< 3.37.0)
Control: tags -1 +confirmed +pending On Fri, Dec 24, 2021 at 1:09 AM Andreas Beckmann wrote: > during a test with piuparts I noticed your package fails to upgrade from > 'sid' to 'experimental'. [...] > The existing B+R: 'sqlite3 (<< 3.17.0)' have the wrong version number. Indeed, a bad typo went in finally. Thanks for catching that. Cheers, Laszlo/GCS
Bug#1001995: libcrypto++: ftbfs on armhf
Control: tags -1 +confirmed Control: forwarded -1 https://github.com/weidai11/cryptopp/issues/1094 Hi Steve, On Mon, Dec 20, 2021 at 1:03 AM Steve Langasek wrote: > Libcrypto++ is failing to build on armhf because gcc there defaults to an > implied -mfloat-abi=hard, which conflicts with -march=armv7-a because > armv7-a does not guarantee floating-point support, and libcrypto++ > hard-codes -march=armv7-a in its makefile: Thanks, confirmed the problem and the fix as well on armhf in a Sid chroot. Still need to check it on armel. Cheers, Laszlo/GCS
Bug#996885: grpc: FTBS: third_party/protobuf/src - No such file or directory
Control: severity -1 important On Sat, Nov 13, 2021 at 9:12 AM László Böszörményi (GCS) wrote: > Control: tags -1 important Right, important is a bug severity. Sorry for the noise.
Bug#996885: grpc: FTBS: third_party/protobuf/src - No such file or directory
Control: tags -1 important Hi Rob, On Wed, Oct 20, 2021 at 11:09 AM Rob Shearman wrote: > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) [...] > grpc fails to build from source from a clean directory: > > rob@graph-dev:~/grpc ((debian/1.30.2-3))$ git clean -xdf > rob@graph-dev:~/grpc ((debian/1.30.2-3))$ gbp buildpackage -uc -us > gbp:info: Performing the build Please note it's a Git tree and not the package source you can get by 'apt source grpc'. While I merged your update, the original problem is probably gbp. It didn't check in the empty directory of third_party/protobuf which otherwise exists in the source tarball. Decreasing the severity and will investigate the possibility to fix the Git tree and its tags to include the mentioned empty directory. Regards, Laszlo/GCS
Bug#996486: bitcoind also needs RTTI support in leveldb
Control: tags -1 +pending Hi Thomas, On Mon, Nov 1, 2021 at 10:33 AM Thomas Goirand wrote: > Laszlo, this affects both bitcoind and Ceph. I'm currently stuck not > being able to build Ceph because of this (and there's currently opened > RC bug on Ceph, only addressed in that latest version I would like to > build). If you don't have time to address this RC bug, would you allow > an NMU to fix this, as per the debdiff at [1] ? I will arrive home in a few hours. Going to do a normal package update immediately. Regards, Laszlo/GCS
Bug#994835: vice: Fails to build -- missing JPEG support
Control: reassign -1 libjpeg62-turbo-dev
Control: tags -1 +patch
Control: affects -1 vice
Hi Alastair,
On Tue, Sep 21, 2021 at 6:00 PM Alastair McKinstry wrote:
> checking for jpeglib.h... no
> configure: error: JPEG support is missing
> make[1]: *** [debian/rules:18: override_dh_auto_configure] Error 1
The reason is simple, src:libjpeg-turbo started to use FILE in its
jpeglib.h header without including stdio.h first. See the minimal
reproducer (similar to what vice configure script tries to find out if
jpeglib.h is present) below.
-- jpegtest.c --
#include
#include
int main(void) {
return 0;
}
-- jpegtest.c --
When you try to compile it with 'gcc -Wall jpegtest.c -o jpegtest' you get:
In file included from jpegtest.c:2:
/usr/include/jpeglib.h:916:52: error: unknown type name ‘FILE’
916 | EXTERN(void) jpeg_stdio_dest(j_compress_ptr cinfo, FILE *outfile);
|^~~~
/usr/include/jpeglib.h:32:1: note: ‘FILE’ is defined in header
‘’; did you forget to ‘#include ’?
31 | #include "jmorecfg.h" /* seldom changed options */
+++ |+#include
32 |
/usr/include/jpeglib.h:917:53: error: unknown type name ‘FILE’
917 | EXTERN(void) jpeg_stdio_src(j_decompress_ptr cinfo, FILE *infile);
| ^~~~
/usr/include/jpeglib.h:917:53: note: ‘FILE’ is defined in header
‘’; did you forget to ‘#include ’?
If I put '#include ' into jpeglib.h after the JPEGLIB_H
definition (ie, to line twenty) that fixes this problem.
Regards,
Laszlo/GCS
Bug#994104: odb: BD on non-default GCC
Control: tags -1 +pending On Sat, Sep 11, 2021 at 10:51 PM Sebastian Ramacher wrote: > #986519 is now fixed, so please switch back to the default GCC. gcc-9 is > about to be removed from testing. I don't know what #986519 (a nheko FTBFS bug) goes with odb, but that's indeed fixed. Going to use GCC 10 for odb soon. Cheers, Laszlo/GCS
Bug#992008: ruby-google-protobuf: Missing lib/google/protobuf directory and fails require
Control: tags -1 +pending Hi Pirate, On Mon, Aug 9, 2021 at 8:51 PM Pirate Praveen wrote: > Can you upload this change? Or if you are okay with this change, I can > upload it as well. Once this is fixed, I can switch back to the > packaged version (currently using gem install google-protobuf as work > around). Sure, I can. Will do it soon. > I had seen this bug earlier > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989774 but I thought > it was something similar/related to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966653 (between, this > bug also seems to be fixed with newer protobuf/grpc versions in > experimental). You know, my question is, how and why it was and still working for 3.12.4 but nor for 3.17.3? Regards, Laszlo/GCS
Bug#989929: Suddenly restarting fetchmail started to fail with error about its global pidfile
Control: tags -1 +pending moreinfo On Wed, Jun 16, 2021 at 10:00 AM Francesco P. Lovergine wrote: > This is currently run on testing since ages. I had to restart due to a changed > fingerprint and the global service started to fail with: [...] > giu 16 08:07:28 klecker fetchmail[846499]: fetchmail: lock creation failed, > pidfile "/run/fetchmail/fetchmail.pid": File o directory non esistente Thanks for the report and the proposed fix! Can you please check if the updated package[1] is fine for you now? Cheers, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/fetchmail_6.4.16-2.dsc
Bug#986523: odb: FTBFS: i386.h:2500:10: fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory
On Wed, Apr 14, 2021 at 9:18 PM Andreas Beckmann wrote: > On Wed, 7 Apr 2021 08:32:20 +0200 Lucas Nussbaum wrote: > > > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h:2500:10: > > > fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory > > This is fixed in gcc-10 10.3 in experimental, according to doko the > workaround is to build with g++-9 for bullseye. (#986519) Meaning GCC 10 is still broken on amd64, its gcc-10-plugin-dev has a regression for Bullseye over GCC 9. But OK, not my business. Will build odb with GCC 9. Regards, Laszlo/GCS
Bug#980609: odb: FTBFS: i386.h:2500:10: fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory
Control: reassign -1 src:gcc-10 Control: retitle -1 missing i386-cpuinfo.h Control: affects -1 src:odb On Wed, Jan 20, 2021 at 9:33 PM Lucas Nussbaum wrote: > Source: odb > Version: 2.4.0-13 > Severity: serious [...] > > In file included from > > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/tm.h:26, > > from > > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/backend.h:28, > > from > > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/gcc-plugin.h:30, > > from ../odb/gcc.hxx:48, > > from cxx-lexer.cxx:5: > > /usr/lib/gcc/x86_64-linux-gnu/10/plugin/include/config/i386/i386.h:2500:10: > > fatal error: common/config/i386/i386-cpuinfo.h: No such file or directory > > 2500 | #include "common/config/i386/i386-cpuinfo.h" > > | ^~~ > > compilation terminated. It's an overlook in src:gcc-10 as it adds the pr95842.diff patch which contains common/config/i386/i386-cpuinfo.h and noted as a "new file" [1][2]. Also noted that i386.h is going to include it [3][4], but it's not installed in the gcc-10-plugin-dev package. Regards, Laszlo/GCS [1] https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L23 [2] https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L394 [3] https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L33 [4] https://sources.debian.org/src/gcc-10/10.2.1-6/debian/patches/pr95842.diff/#L981
Bug#980423: 3.12.4 makes several packages FTBFS
On Mon, Jan 18, 2021 at 10:24 PM Laurent Bigonville wrote: > Several packages FTBFS since 3.12.4 > > The autopkgtest catched ignition-msgs and ignition-transport, see > https://packages.qa.debian.org/p/protobuf.html > > I can see that evolution-data-server also FTBFS [...] > This is a bit unfortunate that it's happening so late in the developpement > cycle. Indeed, my fault. Investigating. Hope this can be resolved easily. Thanks, Laszlo/GCS
Bug#978071: entropybroker FTBFS with Crypto++ 8.3.0
Control: severity -1 serious On Fri, Dec 25, 2020 at 2:39 PM László Böszörményi (GCS) wrote: > Crypto++ 8.3.0 transition will happen (hopefully) soon. Your package > fails to build with this version. Your upstream has the fix [1], > please be prepared to apply it to the packaging. Transition is ongoing, your package now fails to build on all architectures. Regards, Laszlo/GCS
Bug#976838: librocksdb.so: missing libdl linkage
Control: tags -1 +confirmed On Tue, Dec 8, 2020 at 1:39 PM Adrian Bunk wrote: > Package: librocksdb6.11 > Version: 6.11.4-2 [...] > https://buildd.debian.org/status/fetch.php?pkg=rocksdb=amd64=6.11.4-2=1607384772=0 [...] > dpkg-shlibdeps: warning: symbol dlopen used by > debian/librocksdb6.11/usr/lib/librocksdb.so.6.11.4 found in none of the > libraries [...] > https://buildd.debian.org/status/fetch.php?pkg=balboa=amd64=2.0.0%2Bds-3%2Bb1=1607421100=0 > gcc -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong > -Wformat -Werror=format-security -pipe -Ofast -flto -s -fwhole-program > -fmax-errors=3 -D__GCC__ -std=c11 -Wall -Wextra -D_GNU_SOURCE -D__TRACE__ > -DNDEBUG -I. -I../lib -DMPACK_HAS_CONFIG ../lib/trace.c ../lib/daemon.c > ../lib/protocol.c ../lib/engine.c ../lib/mpack.c rocksdb-impl.c main.c -o > build/balboa-rocksdb -Wl,-z,relro -Wl,-z,now -lrocksdb -pthread -latomic > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/librocksdb.so: > undefined reference to `dlopen' > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/librocksdb.so: > undefined reference to `dlclose' > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/librocksdb.so: > undefined reference to `dlerror' > /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/librocksdb.so: > undefined reference to `dlsym' > collect2: error: ld returned 1 exit status Strange. Build tested balboa at least twice on pbuilder with the new rocksdb version and it was compiled correctly. Going to look into it and fix this soon. Regards, Laszlo/GCS
Bug#925818: rocksdb: ftbfs with GCC-9
On Mon, Dec 7, 2020 at 1:00 PM Paul Gevers wrote: > On 07-12-2020 08:11, László Böszörményi (GCS) wrote: > > Yeah, it's a bit confusing why someone tagged this as affecting > > experimental. > > That's because you fixed this bug in experimental. So the BTS apparently > that's part of where the bug is relevant. The version in experimental is > marked as fixed, so everything's fine. Ah, got where the misunderstanding is between us. I talk about #975848 [1] while you are not. > > I could _not_ confirm that the FTBFS happens there. > > Neither did the person that set that tag. Otherwise he would have also > used "reopen" too. Take a look at the top right version plot in the BTS. As noted, there are two GCC FTBFS bugs and the latter set as affecting experimental for no known reason. Regards, Laszlo/GCS [1] https://bugs.debian.org/975848
Bug#925818: rocksdb: ftbfs with GCC-9
Hi Paul, On Sun, Dec 6, 2020 at 9:27 PM Paul Gevers wrote: > On Wed, 27 Mar 2019 19:47:52 + Matthias Klose wrote: > > The package fails to build in a test rebuild on at least amd64 with > > gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The > > severity of this report will be raised before the bullseye release, > > so nothing has to be done for the buster release. > > Do you intend to fix this soon in unstable too? The freeze of bullseye > is near and we'd want to have this bug fixed. Yeah, it's a bit confusing why someone tagged this as affecting experimental. I could _not_ confirm that the FTBFS happens there. Currently this goes in three paths. Try to find a patch for the Sid version of RocksDB, file a transition request for the experimental version (this would be the best ATM). Then I've patched and packaged the new upstream version, but as it switches to CMake build system it needs more testing. Cheers, Laszlo/GCS
Bug#973472: fetchmail: Fails to connect using SSL
On Wed, Nov 11, 2020 at 9:23 PM Kurt Roeckx wrote: > On Tue, Nov 10, 2020 at 08:54:22PM +0100, László Böszörményi (GCS) wrote: > > Thanks for possibly the best solution. Meanwhile OpenSSL 1.1.1h-1 > > migrated to testing; closing this bug report. > > That is not a fix. Fetchmail should not be checking the version. > > The libssl1.1 package will ensure that the correct versioned > depenencies are there. You are right, that's what soname for - define the used and compatible library dependencies. Matthias, what's your intention with the forced OpenSSL library check? Do you plan to remove that upstream or should I comment that out? Regards, Laszlo/GCS
Bug#974167: fetchmail: OpenSSL reported error: key too small
Control: severity -1 normal On Tue, Nov 10, 2020 at 10:30 PM Francesco Potortì wrote: > fetchmail can no longer download mail from some servers. In the logfile > it reports: > > fetchmail: OpenSSL reported: error:141A318A:SSL > routines:tls_process_ske_dhe:dh key too small > fetchmail: SSL connection failed. > fetchmail: socket error while fetching from addr...@server.org > fetchmail: Query status=2 (SOCKET) > fetchmail: Server certificate verification error: Hostname mismatch > fetchmail: OpenSSL reported: error:141A318A:SSL > routines:tls_process_ske_dhe:dh key too small Please note what the log says. It comes from OpenSSL and _not_ from fetchmail. This is for your safety. SHA-1 algorithm is no longer supported for key signatures, RSA and DHE keys shorter than 2048 bits are no longer considered safe. The servers you get this log for fail with one or both the mentioned cases. Ask the system administrators of those servers to upgrade the used keys and signatures. I think this level of checking was first introduced with OpenSSL 1.1.1f and all applications will refuse to work if compiled with this or newer version (for example curl). If you don't mind sending your login information on an now unsecure channel, you can restore the previous behaviour. You need to edit /etc/ssl/openssl.cnf and set "CipherString = DEFAULT@SECLEVEL=2" to one instead. But then again, it's definitely NOT recommended for your security. Regards, Laszlo/GCS
Bug#969538: vips/ruby-vips: autopkgtest regression on arm64 and ppc64el
On Wed, Oct 7, 2020 at 3:39 PM Gianfranco Costamagna wrote: > According to upstream, this might fix the issue I'm not sure if Kleis Auke is part of upstream. But testing his fix on ARM64 - please give me some time as it's just an emulation for me and not very fast. Going to upload the fixed package if that works. Regards, Laszlo/GCS
Bug#936309: closure-linter: Python2 removal in sid/bullseye
Control: severity -1 normal Control: reassign -1 ftp.debian.org Control: retitle -1 RM: closure-linter -- RoM; deprecated upstream, Python 2 only On Wed, Aug 5, 2020 at 10:42 PM Moritz Mühlenhoff wrote: > the upstream homepage now states: > > | Closure Linter is deprecated > | > | As the syntax of JavaScript has continued to evolve, with ES2015 and > | beyond, it has become increasingly difficult to keep Closure Linter > | up to date. It is unstaffed, unmaintained, and deprecated. Most > | projects at Google have migrated to the new linter. > | > | For teams using the Closure tools, we recommend they use the new > | linter based on the Closure Compiler instead. > > Given that closure-compiler is already packaged, let's simply remove > closure-linter? You are right as always. Reassigning this as a removal bug as no reason to keep this package around. Thanks, Laszlo/GCS
Bug#969218: proposed-RM: paxctld -- RoQA; no longer useful
Control: severity -1 normal Control: reassign -1 ftp.debian.org Control: retitle -1 RM: paxctld -- RoM; no longer useful On Sat, Aug 29, 2020 at 2:39 PM Ansgar wrote: > as far as I understand, paxctld is only useful with the semi-proprietary > GRsec kernel patches. As these are now more or less proprietary, > paxctld doesn't seem useful in Debian. Ansgar is right. This package is a tool for GRSec kernel patches that no longer open source. Hence I don't see the reason to maintain and keep it in the archives. Thanks, Laszlo/GCS
Bug#966653: Any progress?
Hi Thomas, On Wed, Sep 9, 2020 at 8:42 AM Thomas Goirand wrote: > On 9/8/20 5:20 PM, László Böszörményi (GCS) wrote: > > I even suspect the real bug is in GitLab itself, it > > may not (correctly) handle the new gRPC version. > > If so, can we lower the severity of the bug to important? It's about GitLab so Pirate should be in charge here. On the other hand, as I see he can't provide a small reproduction case and as GitLab is a Sid only package (due to other reasons) I would say go ahead and lower the severity. Cheers, Laszlo/GCS
Bug#966653: Any progress?
Hi Thomas, On Tue, Sep 8, 2020 at 1:27 PM Thomas Goirand wrote: > I'm not seeing any progress on this bug. Is anyone working on this? The bug report is too wide, "GitLab can't start" doesn't help to narrow it down. I even suspect the real bug is in GitLab itself, it may not (correctly) handle the new gRPC version. > Without any action, this going to trigger the removal of most of > OpenStack from testing... :/ For some weeks I don't have time to learn GitLab and its internals to find out where and why it fails with gRPC 1.30.2 version. In the long run it might be the best to drop Ruby support from src:grpc and let Pirate maintain that from a separate source tree. Cheers, Laszlo/GCS
Bug#964682: icu: FTBFS: dh_auto_test: error: cd source && make -j4 check VERBOSE=1 returned exit code 2
Control: tags -1 +confirmed Hi, I'm looking for advice here on what would be the best move. On Thu, Jul 9, 2020 at 1:36 PM Lucas Nussbaum wrote: > Source: icu > Version: 67.1-2 > Severity: serious > Justification: FTBFS on amd64 > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > dh_auto_test: error: cd source && make -j4 check VERBOSE=1 returned exit > > code 2 This is confirmed and happens due to a regression in make-dfsg while fixing #963335 [1]. File descriptors are no longer passed to forked makes when building recursively or building parallel. Those can't output to stdout and the output of the first make (entering the top level source directory) is not flushed. Normally it's not a problem, but an ICU self-test from 'make check' executes 'make -f source/config/Makefile.inc SELFCHECK=1 selfcheck' directly. With make-dfsg 4.3-3 the previous makes output already flushed and the mentioned test returns 'passed' as supposed to. But with make-dfsg 4.3-4 the output is delayed and only flushed with this test which then will have the output like this: "make[3]: Entering directory 'icu-67.1/source' passed make[3]: Leaving directory 'icu-67.1/source'". That is, it gets polluted by the output of the main make. I can workaround this by setting no parallel to the tests, which in turn will run slower on multicore processors but will pass. Then Manoj can revert the mentioned bad fix of make-dfsg while upstream will work on a better one. Another way is to report this misbehaviour to GNU to fix. Which way to go first? Regards, Laszlo/GCS [1] https://bugs.debian.org/963335
Bug#765854: eCryptfs in Buster / Bullseye (bug #765854, #936465)
Hi, On Mon, Apr 27, 2020 at 9:21 AM Daniel Lange wrote: > we have the issue that eCryptfs has not made it into Buster and has > fallen out of testing due to bug #765854. Indeed, it hurts our users. :( > To me it seems the most easy solution is from > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854#107 > as non-interactive logins don't have any passphrase to unlock an > encrypted home dir anyways. I've updated packaging[1] and my testing shows it works now. > Additionally we have #936465 now (Python2 dependency). > This is tracked upstream at > https://bugs.launchpad.net/ecryptfs/+bug/1871236 Sorry, the Python 2 part is going to be removed. As I see, no plans to make it work with Python 3. > So questions: > > @Martin, Dustin: > Is there still upstream support for eCryptfs? > I.e. will you resolve the LP bug linked above? I may think there's no more development of eCryptfs. I don't know alternatives at the moment. > libecryptfs.py is just a SWIG generated wrapper. > So this probably trivial. But somebody that actually uses the > python-bindings would be needed to test. Do you know use cases for the Python wrapper? > @Laszlo, Julian: > Do we want to get eCryptfs back into Bullseye so Stretch users can > upgrade there (or may be document a work-around with testing packages, > or we do a stable update for these folks)? > I'd really like to offer a solution to users of eCryptfs in Debian. I don't think it can be reintroduced to stable, but backports would be possible. First if you can, please test the new package revision and report back how it works. Regards, Laszlo/GCS [1] dget -x https://people.debian.org/~gcs/ecryptfs-utils_111-5.dsc
Bug#938314: qpid-python: Python2 removal in sid/bullseye
Control: severity -1 normal Control: reassign -1 ftp.debian.org Control: retitle -1 RM: qpid-python -- RoM; deprecated upstream, no reverse-dependencies On Tue, Jun 9, 2020 at 8:00 PM Moritz Mühlenhoff wrote: > On Fri, Aug 30, 2019 at 07:49:29AM +, Matthias Klose wrote: > http://qpid.apache.org/releases/qpid-python-1.37.0/index.html states > that qpid python only supports Python 2 and > > "NOTE: Look to Qpid Proton for Python 3 and AMQP 1.0 support." > > Given that src:qpid-proton is packaged separately and that no > reverse deps exist for python-qpid, let's remove? (Along with > python-qpid-extras-qmf) Indeed, it should have been removed already.
Bug#902351: linux-user-chroot: Should this package be removed?
Control: severity -1 normal Control: reassign -1 ftp.debian.org Control: retitle -1 RM: linux-user-chroot -- RoM; deprecated upstream, no reverse-dependencies On Thu, Jun 25, 2020 at 1:42 PM Simon McVittie wrote: > On Mon, 25 Jun 2018 at 13:16:20 +0100, Simon McVittie wrote: > I don't think an unmaintained setuid program should be in the next stable > release, so I'm escalating this to RC to get it out of testing - I hope > that's OK. Indeed, it should be removed.
Bug#936465: Remove python-ecryptfs?
Control: tags -1 +pending On Mon, Jun 15, 2020 at 10:18 PM Moritz Mühlenhoff wrote: > On Thu, May 14, 2020 at 04:56:01PM -0400, Scott Talbert wrote: > > Does it make sense to just remove the python-ecrpyptfs bindings? They don't > > seem to have any reverse dependencies and popcon is very low. > > Patch attached. Thanks, this is now pending.
Bug#942980: cvs2svn: Python2 removal in sid/bullseye
Hi Moritz, On Sat, Jun 6, 2020 at 4:33 PM Moritz Mühlenhoff wrote: > On Wed, Oct 23, 2019 at 02:33:21AM +, mo...@debian.org wrote: > > Source: cvs2svn > > Usertags: py2removal [...] > http://cvs2svn.tigris.org/ vanished off the net and > https://pypi.org/project/cvs2svn > shows the last release from 2009. Indeed, the official page is taken down. > Let's remove? If there's really anyone who wants to migrate an old CVS repo > to SVN, > they can still do it in a VM using an older release. I got a promise from one of its developers that development will continue and it will be Python 3-ified. Its source was moved (mirrored) to GitHub [1] and it might have unreleased changes already. Still, I don't see any attempt to make it work with Python 3 so you are probably correct. If anyone wanted to migrate their CVS tree to Subversion or Git already had years for that. Going to ask for its removal. Regards, Laszlo/GCS [1] https://github.com/mhagger/cvs2svn
Bug#962265: patch for sword ICU 67.1 detection
Control: tags -1 +patch Hi, It seems your upstream is inactive. It was me who patched sword for ICU 63.1 and here is the patch for the ICU 67.1 version. Please apply this soon. Thanks, Laszlo/GCS Description: fix ICU checking Let still search for icu-config but use pkg-config method after that. Forwarded: no Author: Laszlo Boszormenyi (GCS) Last-Update: 2020-06-05 --- --- sword-1.8.1+dfsg.orig/configure.ac +++ sword-1.8.1+dfsg/configure.ac @@ -238,9 +238,19 @@ if test x$with_icu = xyes; then AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_" AM_CFLAGS="$AM_CFLAGS -D_ICU_" else - echo "*** The icu-config script installed by icu could not be found" - echo "*** compiling without ICU support" - with_icu=no + PKG_CHECK_MODULES([ICU], [icu-i18n >= 63.1], [found_icu=yes]) + if test "$found_icu" = "yes"; then + PKG_CHECK_MODULES([ICU_IO], [icu-io >= 63.1]) + ICU_IOLIBS="$ICU_IO_LIBS" + with_icu=yes + LIBS="$LIBS $ICU_LIBS $ICU_IOLIBS" + AM_CXXFLAGS="$AM_CXXFLAGS -D_ICU_" + AM_CFLAGS="$AM_CFLAGS -D_ICU_" + else + echo "*** The icu-config script installed by icu could not be found" + echo "*** compiling without ICU support" + with_icu=no + fi fi fi
Bug#962131: sqlite3 breaks python3.8 autopkgtest: CheckFuncDeterministic (sqlite3.test.userfunctions.FunctionTests)
Control: notfound -1 sqlite3/3.32.1-2 Control: retitle -1 bad SQLite deterministic check in self-tests On Wed, Jun 3, 2020 at 5:09 PM Paul Gevers wrote: > With a recent upload of sqlite3 the autopkgtest of python3.8 fails in > testing when that autopkgtest is run with the binary packages of sqlite3 > from unstable. [...] > Currently this regression is blocking the migration of sqlite3 to > testing [1]. Due to the nature of this issue, I filed this bug report > against both packages. Can you please investigate the situation and > reassign the bug to the right package? Some background information. In SQLite you can tag functions as deterministic, meaning it will always give back the same result on the same input values. Python 3.8+ test it with: 'select deterministic() = deterministic()' and think it will be called once as its assert is the following: 'self.assertEqual(mock.call_count, 1)'. This is wrong, as deterministic doesn't mean it will be called once for the left side of the equality then filled out on the right side just because it's the same function call. The query planner can and will call it again since SQLite version 3.15.0, as you could see the called number is 2 in the build failure. That means it's a bad SQLite check implementation in Python 3.8+ which was already reported to them as Issue 40784 [1]. They fixed it on their Git master branch and of course backported for the 3.8 release of Python [2]. Tested to be sure and it fixes the issue. Hopefully Matthias will add it to its packaging soon. Regards, Laszlo/GCS [1] https://bugs.python.org/issue40784 [2] https://github.com/python/cpython/commit/c610d970f5373b143bf5f5900d4645e6a90fb460
Bug#961940: libsqlite3-0:i386: trying to overwrite shared '/usr/share/doc/libsqlite3-0/changelog.gz', which is different […]
Control: tags -1 +pending On Sun, May 31, 2020 at 9:45 PM Thorsten Glaser wrote: > On Sun, 31 May 2020, Thorsten Glaser wrote: > > These files indeed differ: > > > > - a. Extending FTS5 → requires sqlite3_bind_pointer() to find the > > + a. Extending FTS5 -> requires sqlite3_bind_pointer() to find the Ouch. Didn't expect character set conversion. First, locale setting should be the same on all buildds and lynx should only dump the text. > Fix looks trivial: adding… > > export LC_ALL:=C.UTF-8 > > … after the first two lines of debian/rules ought to do the trick. I did local builds for i386 and amd64 to test if the generated changelog - those were same. But it seems some buildds may use somewhat different locale setting. Strange. Thanks for the help, Laszlo/GCS
Bug#959675: libgrpc++1: endless looping with default settings
Control: tags -1 +pending On Wed, May 27, 2020 at 4:42 PM Thomas Goirand wrote: > Any progress on this? I've been watching this bug activity, and > nothing's happening. I'm worried for my packages removal in Bullseye > (ie: most of OpenStack...). Quoting the package tracker: "grpc is marked for autoremoval from testing on 2020-06-23" which is almost a month away. Then Benjamin uploaded Abseil and it's in NEW [1] and I've updated gRPC and it's also in NEW [2] waiting for Abseil at first. Hope FTP Masters will clear both packages soon to the archives. In short, don't worry for the time being. Regards, Laszlo/GCS [1] https://ftp-master.debian.org/new/abseil_0~20200225.2-1.html [2] https://ftp-master.debian.org/new/grpc_1.29.1-1.html
Bug#960241: FTBFS: the taglist extension is not safe for parallel reading
Source: mongo-c-driver
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs patch
Hi,
During a test recompilation with the new ICU release I've realized
your package FTBFS in Sid due to a possible behavior change of Sphinx.
The relevant output is:
[ 0%] Building HTML documentation with Sphinx
[...]
Warning, treated as error:
the taglist extension is not safe for parallel reading
The following patch fixes this, please apply it as time permits:
--- mongo-c-driver-1.16.1.orig/build/cmake/SphinxBuild.cmake
+++ mongo-c-driver-1.16.1/build/cmake/SphinxBuild.cmake
@@ -40,7 +40,7 @@ function (sphinx_build_html target_name
${CMAKE_COMMAND} -E env
"PYTHONDONTWRITEBYTECODE=1"
${SPHINX_EXECUTABLE}
- -j ${NPROCS} -qEW -b html
+ -j 1 -qEW -b html
-c "${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_SOURCE_DIR}"
"${SPHINX_HTML_DIR}"
@@ -133,7 +133,7 @@ function (sphinx_build_man target_name)
${CMAKE_COMMAND} -E env
"PYTHONDONTWRITEBYTECODE=1"
${SPHINX_EXECUTABLE}
- -j ${NPROCS} -qEW -b man
+ -j 1 -qEW -b man
-c "${CMAKE_CURRENT_SOURCE_DIR}"
"${CMAKE_CURRENT_SOURCE_DIR}"
"${SPHINX_MAN_DIR}"
Regards,
Laszlo/GCS
