Bug#1069759: alabaster: Please update to the latest upstream version
Source: alabaster Version: 0.7.12-1 Severity: wishlist Dear Maintainer, Sphinx now requires alabaster 0.7.14 or newer [1]. It would be nice if you packaged the latest version, which is 0.7.16 at the moment [2]. I can prepare a pull request if needed. [1]: https://github.com/sphinx-doc/sphinx/pull/11858 [2]: https://pypi.org/project/alabaster/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1069574: age-old and insecure webkit package
Hi again Hadmut, On Sun, Apr 21, 2024 at 08:25:23PM +0300, Hadmut Danisch wrote: > Hi Dmitry, > > > even their own website > > https://wkhtmltopdf.org/status.html > > says: > >*Do not use wkhtmltopdf with any untrusted HTML* – be sure to >sanitize any user-supplied HTML/JS, otherwise it can lead to >complete takeover of the server it is running on! Please consider >using a Mandatory Access Control system like AppArmor or SELinux, >see recommended AppArmor policy <https://wkhtmltopdf.org/apparmor.html>. > > Wouldn't it be more than enough or a reason to throw this out of > debian/ubuntu, until they fixed this? First, I am the wrong person to ask about this. I am CCing the wkhtmltopdf maintainer. Second, wkhtmltopdf is not a leaf package, there are other packages depending on it: Reverse-Recommends == * civicrm-common * python3-a38 Reverse-Depends === * odoo-16 * python3-django-wkhtmltopdf * python3-pdfkit -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1069574: age-old and insecure webkit package
Hi Hadmut! On Sat, Apr 20, 2024 at 09:23:37PM +0300, Hadmut Danisch wrote: > Package: libqt5webkit5 > > Version: 5.212.0~alpha4-30 > > > Hi, > > this was originally a bug report against Ubuntu 24.04 as 2061191, but since > the package is community maintained and not by Ubuntu, they asked me to > report it "upstreams". > > > Ubuntu 24.04 beta / Debian bookworm still use libqt5webkit5. > > It is not obvious, where it comes from, but the version is still an alpha4, > and the link in the README seems to suggest, that it still comes from > https://github.com/annulen/webkit, which redirects to > https://github.com/qtwebkit/qtwebkit, where the alpha4 tag is over 4 years > old. > > There, the latest README tells: > > Code in this repository is obsolete. If you are looking for up-to-date > QtWebKit use this fork: https://github.com/movableink/webkit > > https://github.com/movableink/webkit seems to be still maintained – more or > less. And calls itself "inofficial mirror" Unfortunately, movableink/webkit seems to be even less stable or ready than qtwebkit/qtwebkit. For example, it is known that PyQt5 cannot be built against it [1], and there are packages in Debian which need it: $ reverse-depends python3-pyqt5.qtwebkit Reverse-Recommends == * linuxcnc-uspace [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-ginga Reverse-Depends === * frescobaldi [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * manuskript * openshot-qt * python3-pyface * python3-qgis [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-qtpy * qutebrowser-qtwebkit * yade [amd64 arm64] > Have a look at > > https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/ > > which calls qtwebkit insecure, poorly maintained, and cites CVEs about > remote code execution (some of them would have to be fixed in the fork, but > probably not in the version here in ubuntu). > > The problem is, that tools like wkhtmltopdf do use this library and are > typically used to pull contents from a given URL, i.e. from foreign > websites. > > Processing foreign HTML and Javascript code in conjunction with > vulnerabilities to remote code execution, this is highly dangerous. I absolutely agree. Projects like wkhtmltopdf should stop using Qt WebKit and should be ported to Qt WebEngine or other alternatives [2]. Once they do that, we will be able to remove Qt WebKit from Debian. Any help with filing bugs, both upstream and here in Debian, is welcome. It is also worth noting that our Release Notes explicitly mention [3] that Qt WebKit is not covered by security support, thus anyone who uses it with untrusted input data does so on their own risk. [1]: https://github.com/movableink/webkit/issues/16 [2]: ideally, they should be also ported from Qt 5 to Qt 6 [3]: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1066320: astlib: FTBFS: PyWCSTools/wcssubs-3.9.5/wcscon_wrap.c:3533:3: error: implicit declaration of function ‘wcscon’; did you mean ‘wcstoq’? [-Werror=implicit-function-declaration]
Control: tags -1 + patch Hi, On Wed, Mar 13, 2024 at 12:47:51PM +0100, Lucas Nussbaum wrote: > Source: astlib > Version: 0.11.10-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240313 ftbfs-trixie ftbfs-impfuncdef > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > This is most likely caused by a change in dpkg 1.22.6, that enabled > -Werror=implicit-function-declaration. For more information, see > https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration I have created a MR on salsa which fixes this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066320 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1068038: FTBFS: error: ‘struct input_event’ has no member named ‘time’
Control: tags -1 + pending Hi, On Sat, Mar 30, 2024 at 02:10:56AM +0500, Andrey Rakhmatullin wrote: > Source: flightgear > Version: 1:2020.3.18+dfsg-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=flightgear=armhf=1%3A2020.3.18%2Bdfsg-1%2Bb2=1711729288=0 > > /<>/src/Input/FGLinuxEventInput.cxx: In member function ‘virtual > void FGLinuxInputDevice::Send(const char*, double)’: > /<>/src/Input/FGLinuxEventInput.cxx:418:7: error: ‘struct > input_event’ has no member named ‘time’ > 418 | evt.time.tv_sec = 0; > | ^~~~ > /<>/src/Input/FGLinuxEventInput.cxx:419:7: error: ‘struct > input_event’ has no member named ‘time’ > 419 | evt.time.tv_usec = 0; > | ^~~~ I have uploaded NMU which fixes this to DELAYED/2. The diff can be seen here: https://salsa.debian.org/debian/flightgear/-/merge_requests/3 It depends on my another NMU for simgear: unless simgear is rebuilt with the new time_t ABI, flightgear will fail to build with link failures. And simgear is a static library so we cannot just bump SONAME for it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060926: simgear: FTBFS: Compositor.hxx:137:34: error: field ‘_uniforms’ has incomplete type ‘simgear::compositor::Compositor::BuiltinUniforms’ {aka ‘std::array, 14>’}
Control: tags -1 + pending
Hi,
On Tue, Jan 16, 2024 at 08:36:13PM +0100, Lucas Nussbaum wrote:
> Source: simgear
> Version: 1:2020.3.18+dfsg-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> Relevant part (hopefully):
> > cd /<>/build/simgear && /usr/bin/c++ -DHAVE_CONFIG_H
> > -DHAVE_INTTYPES_H -I/<> -I/<>/build/simgear
> > -I/<>/build -I/usr/include/AL
> > -I/<>/simgear/canvas/ShivaVG/include
> > -I/<>/3rdparty/utf8/source -g -O2
> > -ffile-prefix-map=/<>=. -fstack-protector-strong
> > -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> > -Wdate-time -D_FORTIFY_SOURCE=2 -msse2 -mfpmath=sse -ftree-vectorize
> > -ftree-slp-vectorize -Wall -fPIC -Wno-unused-local-typedefs
> > -DBOOST_BIMAP_DISABLE_SERIALIZATION -DBOOST_NO_STDLIB_CONFIG -O3 -g
> > -DNDEBUG -msse2 -mfpmath=sse -ftree-vectorize -ftree-slp-vectorize
> > -std=gnu++11 -MD -MT
> > simgear/CMakeFiles/SimGearScene.dir/sound/xmlsound.cxx.o -MF
> > CMakeFiles/SimGearScene.dir/sound/xmlsound.cxx.o.d -o
> > CMakeFiles/SimGearScene.dir/sound/xmlsound.cxx.o -c
> > /<>/simgear/sound/xmlsound.cxx
> > In file included from
> > /<>/simgear/scene/viewer/Compositor.cxx:17:
> > /<>/simgear/scene/viewer/Compositor.hxx:137:34: error: field
> > ‘_uniforms’ has incomplete type
> > ‘simgear::compositor::Compositor::BuiltinUniforms’ {aka
> > ‘std::array, 14>’}
> > 137 | BuiltinUniforms _uniforms;
> > | ^
> > In file included from /usr/include/c++/13/bits/hashtable_policy.h:34,
> > from /usr/include/c++/13/bits/hashtable.h:35,
> > from /usr/include/c++/13/bits/unordered_map.h:33,
> > from /usr/include/c++/13/unordered_map:41,
> > from
> > /<>/simgear/scene/viewer/Compositor.hxx:20:
> > /usr/include/c++/13/tuple:2005:45: note: declaration of
> > ‘simgear::compositor::Compositor::BuiltinUniforms’ {aka ‘struct
> > std::array, 14>’}
> > 2005 | template struct array;
> > | ^
I have uploaded NMU which fixes this and another build failure to DELAYED/2.
The diff can be seen here:
https://salsa.debian.org/debian/simgear/-/merge_requests/1
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1068155: lmms: FTBFS on i386: dh_install: warning: Cannot find (any matches for) "usr/lib/*/lmms/libvestige.so" (tried in ., debian/tmp)
Control: reassign -1 libwine-dev 9.0~repack-4 Control: affects -1 + src:lmms Hi all, On Tue, Apr 02, 2024 at 12:16:09PM +0200, Andreas Beckmann wrote: > Comparing bookworm and sid buildlogs shows the following relevant > differences during cmake: > > -Setting up libwine-dev:i386 (8.0~repack-4) ...^M > +Setting up libwine-dev:i386 (9.0~repack-4+b1) ...^M > > --- Found Wine: /usr/lib/i386-linux-gnu/wine/libwine.so > +CMake Warning (dev) at cmake/modules/FindWine.cmake:20 (EXEC_PROGRAM): > + Policy CMP0153 is not set: The exec_program command should not be called. > + Run "cmake --help-policy CMP0153" for policy details. Use the cmake_policy > + command to set the policy and suppress this warning. > + > + Use execute_process() instead. > +Call Stack (most recent call first): > + CMakeLists.txt:462 (FIND_PACKAGE) > +This warning is for project developers. Use -Wno-dev to suppress it. > + > +-- Could NOT find Wine (missing: WINE_LIBRARIES) > > -* VST-instrument hoster : OK, with workaround linking > /usr/lib/i386-linux-gnu/wine/i386-unix/libwinecrt0.a/ > -* VST-effect hoster : OK, with workaround linking > /usr/lib/i386-linux-gnu/wine/i386-unix/libwinecrt0.a/ > +* VST-instrument hoster : not found, please install (lib)wine-dev (or > similar) - 64 bit systems additionally need gcc-multilib and g++-multilib > +* VST-effect hoster : not found, please install (lib)wine-dev (or > similar) - 64 bit systems additionally need gcc-multilib and g++-multilib This is actually a bug in libwine-dev: libwine.so is a broken symlink: # ls -l /usr/lib/i386-linux-gnu/wine/libwine.so lrwxrwxrwx 1 root root 22 Mar 12 18:22 /usr/lib/i386-linux-gnu/wine/libwine.so -> i386-unix/libwine.so.1 # ls -l $(realpath /usr/lib/i386-linux-gnu/wine/libwine.so) ls: cannot access '/usr/lib/i386-linux-gnu/wine/i386-unix/libwine.so.1': No such file or directory The problem is not specific to i386, the same thing is on amd64: # ls -l $(realpath /usr/lib/x86_64-linux-gnu/wine/libwine.so) ls: cannot access '/usr/lib/x86_64-linux-gnu/wine/x86_64-unix/libwine.so.1': No such file or directory It's just lmms uses wine only on i386. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1067326: mkdocstrings: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" returned exit code 13
Hi Carsten! On Wed, Mar 20, 2024 at 10:00:48PM +0100, Lucas Nussbaum wrote: > Source: mkdocstrings > Version: 0.24.1-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > [...] > > The full build log is available from: > http://qa-logs.debian.net/2024/03/19/mkdocstrings_0.24.1-1_unstable.log Upstream released 0.24.2 today, which should fix this failure [1]. [1]: https://github.com/mkdocstrings/mkdocstrings/commit/c0d009000678a2cc -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1068078: FTBFS on armel: shiboken2:smart::smart_pointer Newly detected Real test failure!
Hi, (CCing debian-arm@l.d.o. Please CC me back as I’m not subscribed.) On Sat, Mar 30, 2024 at 02:11:32PM +0500, Andrey Rakhmatullin wrote: > Source: pyside2 > Version: 5.15.12-6.1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/fetch.php?pkg=pyside2=armel=5.15.12-6.1=1711789575=0 > > RUN 2: Test project /<>/pyside3_build/py3.11-qt5.15.10-32bit- > relwithdebinfo/shiboken2 > RUN 2: Start 181: smart_smart_pointer > RUN 2: 1/1 Test #181: smart_smart_pointer ..***Failed0.23 sec > RUN 2: Running garbage collector for reference test > RUN 2: FFF > RUN 2: == > RUN 2: FAIL: testObjSmartPointer > (__main__.SmartPointerTests.testObjSmartPointer) > RUN 2: -- > RUN 2: Traceback (most recent call last): > RUN 2: File > "/<>/sources/shiboken2/tests/smartbinding/smart_pointer_test.py", > line 94, in testObjSmartPointer > RUN 2: self.assertEqual(integerCount(), 1) > RUN 2: AssertionError: 2 != 1 > [...] I tried to build pyside2 on two porterboxes, amdahl.d.o and abel.d.o, and on both it built successfully (in sid_armel-dchroot). I also ran the test manually several times after build, and it was successful too: (sid_armel-dchroot)mitya57@abel:~/pyside2-5.15.12/pyside3_build/py3.11-qt5.15.10-32bit-relwithdebinfo/shiboken2$ ctest --tests-regex '^(smart_smart_pointer)$' Test project /home/mitya57/pyside2-5.15.12/pyside3_build/py3.11-qt5.15.10-32bit-relwithdebinfo/shiboken2 Start 181: smart_smart_pointer 1/1 Test #181: smart_smart_pointer .. Passed0.48 sec 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 0.53 sec Does anyone have ideas why there may be such difference between the buildds (arm-conova-01, arm-arm-03) and the porter boxes? It’s worth noting that the armhf build ran on the same arm-conova-01, and it was successful. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060724: meteo-qt: Please remove python3-sip Depends
Control: tags -1 + pending Dear Maintainer, On Sat, Jan 13, 2024 at 03:13:33PM +0300, Dmitry Shachnev wrote: > Package: meteo-qt > Version: 3.3-2 > Severity: important > Usertags: sip6 > > Dear Maintainer, > > Your package depends on python3-sip, which belongs to the deprecated sip4 > source package. > > The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages > in Debian are built with that modern version. > > python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip, > so there is no need to depend on it explicitly. I have uploaded a trivial fix for this to DELAYED/5. The NMU diff is available here: https://salsa.debian.org/lxqt-team/meteo-qt/-/merge_requests/3 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Hi,
On Fri, Mar 22, 2024 at 03:30:55PM +0100, Holger Wansing wrote:
> Ok, I see.
> So, we will need to get sphinx-rtd-theme-common installed on all debian.org
> website mirrors, and it will just work (?) ...
From your earlier message it seemed to me like you are using the build
tree in your deploy process, not the built package.
That is why I suggested not running dh_sphinxdoc, however my suggestion
applied only to your deploy procedure. The package which is being uploaded
to Debian archive should still use dh_sphinxdoc.
If you are using the built package and installing it on the remote server,
then yes, install sphinx-rtd-theme-common and you should be good.
Actually, I would move ${sphinxdoc:Depends} from Recommends to Depends,
because the documentation is mostly unusable without the static files.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1064593: Bug#1066967: Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
On Fri, Mar 22, 2024 at 01:46:48PM +0100, Holger Wansing wrote: > [...] > Anyway, the symlink points to some path inside the package build path, here: > /srv/debian-policy/debian-policy-4.6.2.1/debian/debian-policy/usr/share/sphinx_rtd_theme_static/css/theme.css > > and that path does not exist. > Same in the debian-policy binary package. This is expected. The path in the build tree is relative in a way that when a package is built and installed, it becomes working. The symlink is generated relative per Policy 10.5. And I think that even if dh_sphinxdoc generated it as absolute, dh_link would later change it to relative. If you are trying to rely on something that is in the build directory, you have to turn relative symlinks into absolute ones on your own. Or just don't call dh_sphinxdoc, then you will get normal files. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1064593: Bug#1066967: dh_sphinxdoc: replaces files provided by read-the-doc theme by empty symlinks
Control: tags 1066967 +unreproducible
Hi Holger!
On Sat, Mar 16, 2024 at 09:52:54AM +0100, Holger Wansing wrote:
> Package: sphinx-common
> Severity: serious
>
> Hi,
>
> dh_sphinxdoc does not work well with read-the-doc theme, apparently.
> Debian policy document has switched to sphinx_rtd_theme recently (see
> https://salsa.debian.org/dbnpolicy/policy/-/commit/686622814018b5a121252b189d99c1968f332b78
> )
>
> However, the built document has a completely broken html layout, because
> many files under _static/ are empty (0B size), most noteably
> _static/css/theme.css.
>
> If I replace
> dh $@ --with sphinxdoc
> by
> dh $@
> (so do not use dh_sphinxdoc), I get a valid html file with the theme
> in use.
I cannot reproduce this. I downloaded debian-policy source package and built
it in an up-to-date sid chroot. And the built package has this:
$ dpkg-deb -c debian-policy_4.6.2.1_all.deb | grep theme.css
lrwxrwxrwx root/root 0 2024-02-24 15:39
./usr/share/doc/debian-policy/policy.html/_static/css/theme.css ->
../../../../../sphinx_rtd_theme/static/css/theme.css
So, it is a symlink, not an empty file. When resolving the relative path,
I get /usr/share/sphinx_rtd_theme/static/css/theme.css, and that file
exists in sphinx-rtd-theme-common and is non-empty.
The only issue I see is that sphinx-rtd-theme-common is in Recommends of
debian-policy, not in Depends. But that is because ${sphinxdoc:Depends}
was put there.
Am I doing something wrong?
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1067009: lomiri-ui-toolkit: FTBFS: 63 failures which MUST be fixed
Source: lomiri-ui-toolkit Version: 1.3.5012+dfsg-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Control: block 1061179 by -1 Dear Maintainer, As can be seen in [1], the package failed to build on buildds in unstable. The relevant part is: /<>/tests/checkresults.sh /<>/tests/*.xml || exit 1; 63 failures which MUST be fixed: tst_scrollbar.13.qml tst_scrollbar_header.13.qml tst_scrollview.13.qml The reasons why the tests failed can be found by searching for FAIL!. E.g., the first test failed with this error: FAIL! : components::Scrollbar::test_defaultStylingValues(vertical scrollbar) Uncaught exception: Cannot read property 'interactive' of null Loc: [/<>/tests/unit/visual/tst_scrollbar.13.qml(1187)] [1]: https://buildd.debian.org/status/package.php?p=lomiri-ui-toolkit -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059264: qbs: ftbfs on riscv64: test timeout
Hi! On Sun, Mar 03, 2024 at 03:14:58PM +0800, Bo YU wrote: > Due to 2.1.2-2.1 was t64 transition related, so I have to generate > debdiff based on 2.1.2-2. So please let me know if any issue. > > I should wait the 64 trsansition to finish but not sure how long it will > to achive this. Right. I committed the patch so it will be part of the next upload, but I am not uploading it until the current version migrates to testing. Also, our debian/rules includes /usr/share/dpkg/default.mk which in turn includes architecture.mk, so $(DEB_BUILD_ARCH_CPU) is defined and there is no need to call dpkg-architecture explicitly. I have updated the patch based on that. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1062946: 64-bit time_t transition in progress
Control: tags 1062723 -pending Control: tags 1062747 -pending Control: tags 1062749 -pending Control: tags 1062750 -pending Control: tags 1062751 -pending Control: tags 1062758 -pending Control: tags 1062759 -pending Control: tags 1062760 -pending Control: tags 1062762 -pending Control: tags 1062763 -pending Control: tags 1062764 -pending Control: tags 1062766 -pending Control: tags 1062940 -pending Hi all, On Thu, Feb 08, 2024 at 01:06:40PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! > > On Fri, 2 Feb 2024 at 13:22, Steve Langasek wrote: > > > > Dear developers, > > > > A number of you will have noticed already that the 64-bit time_t transition > > is now in progress in Debian experimental. > [snip] > > >qt6-virtualkeyboard > >qt-qml-models > > For all Qt packages, be it Qt 5 or 6, you only need to modify > libqtXcoreX. The rest of the packages will just follow suite, > **nothing** in Qt does not depends upon libQtCoreX. In fact I would > say that by doing that you get even the whole KDE stack in. Lisandro is right, it is enough to NMU only qtbase. All other Qt submodules depend on libqtXcoreX, so they just need to be binNMUed to rebuild against the new version, changing SONAMEs is not needed. So removing pending tags from Qt modules other than qtbase, to exclude them from upload list. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059264: qbs: ftbfs on riscv64: test timeout
Hi! On Fri, Dec 22, 2023 at 05:25:52PM +0800, Bo YU wrote: > Package: qbs > Version: 1.24.1+dfsg-2 > Severity: important > Tags: ftbfs patch > User: debian-ri...@lists.debian.org > Usertags: riscv64 > X-Debbugs-Cc: debian-ri...@lists.debian.org > > Dear Maintainer, > > qbs has ftbfs on riscv64 since 2.1.1-2(2023/08) on sid. The problem is > due to timeout on buildd machines for riscv64 now: > > [...] > > So we can see the timeout on tst_blackbox-qt suite mainly. But the > question is that failed test function cases are randomized. So I have > captured a few cases to temporarily skip over riscv64 buildd(holpe this > works). And I would like to suggest that we keep opening the reportbug > until we have more powerful buildd machines to close it as expected > it. I can build it on vf2 without any patch but it has not been tested > many times. > > So could you apply it on next upload or any ideas? I would prefer increasing the timeout to disabling the test. The blackbox tests start qbs in a subprocess and wait for it to finish in a reasonable time [1]. The value of testTimeoutInMsecs() can be configured by QBS_AUTOTEST_TIMEOUT environment variable, which specifies time in seconds and is 600 by default, which is 10 minutes. However, Qt test library has its own timeout: any test function call is interrupted in 5 minutes [2]. This can be configured by QTEST_FUNCTION_TIMEOUT variable, which is in milliseconds. It looks like this is the timeout that occurs in the log fragments you provided. Do you have any way to check if increasing QTEST_FUNCTION_TIMEOUT helps to get it built on slow riscv64 machines. And if yes, to what value it should be increased? [1]: https://sources.debian.org/src/qbs/2.1.2-2/tests/auto/blackbox/tst_blackboxbase.cpp/#L100 [2]: https://doc.qt.io/qt-6/qtest-overview.html#increasing-test-function-timeout -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
Hi James! On Thu, Feb 15, 2024 at 05:17:00PM +, James Addison wrote: > Source: lomiri-ui-toolkit > Followup-For: Bug #1060761 > X-Debbugs-Cc: sunwea...@debian.org, mity...@debian.org > > Hi Mike, Dmitry, > > Is the second patch here (to disable the failing unit test) likely to be > uploaded to unstable in the nearish future? > > I'm eager to see the results of some build reproducibility improvements in > qttools from 5.15.12 (#1059592, #1059631) and this is tagged as a blocker for > the relevant qtbase ABI migration. I don’t think the start of Qt transition is blocked by this bug. I rather think that there are many transition requests and mine waits in the queue. Because it is going to take longer than I expected, I have now uploaded the qttools patches to unstable. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1056419: Spinx help needed
Hi Andreas! On Thu, Feb 15, 2024 at 08:37:38AM +0100, Andreas Tille wrote: > Control: tags -1 pending > > Hi, > > I pushed fixes for #1056419 and #1058311 to Git and I think should be > fixed as well. The only remaining build problem is new and caused by > sphinx[1]: > > dh_sphinxdoc -i -O--buildsystem=pybuild > dh_sphinxdoc: error: > debian/python-lmfit-doc/usr/share/doc/python3-lmfit/html/search.html > top-level node does not have data-content_root attribute > > Unfortunately I have no idea how to fix this. Any ideas? lmfit-py ships a vendored copy of sphinx13 theme [1], which was copied from Sphinx source code with a minor modification in 2020 [2] and rebased in January 2022 [3]. However, there were more Sphinx releases since that month, and the theme needs to be updated for compatibility with them. In particular, the basic_layout.html file misses the change which was made in Sphinx commit [4], without which the search will not work. There is a comment under that commit which illustrates how exactly it will not work: contentRoot will be undefined, and the browser will attempt to make requests to a URL that has "undefined" in it. dh_sphinxdoc catches such issues and produces an error about them. So, to fix this issue, you should copy sphinx/themes/basic/layout.html from the latest stable version of Sphinx to lmfit-py's basic_layout.html, applying the one-line change which is described in [2] and [3]. [1]: doc/sphinx/theme/sphinx13/* [2]: https://github.com/lmfit/lmfit-py/commit/29e4712036606913149e16b246340a7fbedd8829 [3]: https://github.com/lmfit/lmfit-py/commit/e2418377c9870e02c820d0fe40d2232187864a81 [4]: https://github.com/sphinx-doc/sphinx/commit/8e730ae303ae686705ea12f44ef11da926a87cf5 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1050693: sphinx: unreproducible output if the same function has two entries in the table of contents
Hi Rebecca, and sorry for the late response! On Mon, Aug 28, 2023 at 11:39:05AM +0100, Rebecca N. Palmer wrote: > Package: python3-sphinx > Version: 5.3.0-7 > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: fileordering > > When the same function has two entries in the table of contents, that > function's documentation page may be generated with the table of contents > open to either of those two entries. (Probably based on filesystem order, > i.e. which entry gets processed first, but I don't actually know that.) > > For example, pandas DataFrame.to_* are listed in both reference/io.rst and > reference/frame.rst: > https://salsa.debian.org/science-team/pandas/-/jobs/4617327 In the log referenced by you there is indeed diff for /usr/share/doc/python-pandas-doc/html/reference/api/pandas.DataFrame.to_*.html files. However, I don't see any diff in the recent pandas reprotest logs, e.g. in these ones: - https://salsa.debian.org/science-team/pandas/-/jobs/5232189 - https://salsa.debian.org/science-team/pandas/-/jobs/5268239 - https://salsa.debian.org/science-team/pandas/-/jobs/5273611 There is no diff for /usr/share/doc/python-pandas-doc/html/reference/* at all. Maybe this bug no longer happens in Sphinx 7.2 (which was uploaded to unstable on 2023-11-05)? Or it just happens rarely and the CI can't always catch it? If we manage to reproduce it, the next step would be identifying whether this is a problem in autosummary extension, or can be reproduced without it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1063326: TypeError: first argument must be callable
Hi Frédéric! On Tue, Feb 06, 2024 at 09:32:45AM +0100, Picca Frédéric-Emmanuel wrote: > Package: python3-sphinx > Version: 5.3.0-4 > Severity: important > > Dear Maintainer, > > Hello, while preparing the new silx package, I got this error message from > sphinx when calling this command line > > [...] > > File "/usr/lib/python3/dist-packages/sphinx/registry.py", line 353, in > create_translator > setattr(translator, 'visit_' + name, MethodType(visit, translator)) > ^ > TypeError: first argument must be callable This is because sphinx-panels defines the handler for "fontawesome" role for manpage builder as (None, None): https://sources.debian.org/src/sphinx-panels/0.6.0-3/sphinx_panels/icons.py/#L144 While Sphinx expects at least the visit function (the first pair element) to be not None. However, sphinx-panels is dead, and upstream recommends to use sphinx-design instead. And in sphinx-design this bug is fixed: https://sources.debian.org/src/sphinx-design/0.5.0-2/sphinx_design/icons.py/#L42 https://github.com/executablebooks/sphinx-design/pull/88 If you want a fix in sphinx-panels, please reassign the bug. Otherwise, if you have found another solution, please close it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061206: Please upgrade to llvm-toolchain-17
Hi Sylvestre! On Sat, Jan 20, 2024 at 09:57:51PM +0100, Sylvestre Ledru wrote: > Source: pyside2 > Severity: important > > Dear Maintainer, > > As part of the effort to limit the number of llvm packages in the > archive, it would be great if you could upgrade to -17. > > This package depends on 15. It was not easy, but I backported 9 patches from upstream 6.x branch and added one my patch on top of them, and now pyside2 can build with LLVM 16 and LLVM 17. I did as you suggested and forced build with 17, and uploaded to unstable. However now it dep-waits on mips64el, because llvm-toolchain-17 failed to build there. Should I roll back to the default version (16) for now? Or this will be resolved somehow? I will need rebuilding pyside2 for Qt 5.15.12 transition soon, and if it does not build on mips64el, that will prevent Qt from migrating. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060761: fixed in lomiri-ui-toolkit 1.3.5012+dfsg-1
Control: reopen -1
Control: forwarded -1
https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
Hi Mike!
On Fri, Feb 02, 2024 at 12:34:40AM +, Debian FTP Masters wrote:
> Source: lomiri-ui-toolkit
> Source-Version: 1.3.5012+dfsg-1
> Done: Mike Gabriel
>
> We believe that the bug you reported is fixed in the latest version of
> lomiri-ui-toolkit, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
In the original bug report, I mentioned that there are two issues.
The new upstream release fixes the first one, but not the second one.
As a temporary measure until upstream fixes this properly, I can suggest
the attached patch that I applied in Ubuntu.
--
Dmitry Shachnev
Description: disable the test that fails with Qt 5.15.11
Author: Dmitry Shachnev
Forwarded: not-needed
Bug: https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
Last-Update: 2024-01-13
--- a/tests/unit/units/dpr1/tst_units.cpp
+++ b/tests/unit/units/dpr1/tst_units.cpp
@@ -41,6 +41,7 @@ private Q_SLOTS:
QCOMPARE(units.gridUnit(), 42.0f);
}
+#if QT_VERSION < QT_VERSION_CHECK(5, 15, 11)
void gridUnitEnvironmentVariable() {
QByteArray gridUnit = QString::number(11).toLocal8Bit();
qputenv("GRID_UNIT_PX", gridUnit);
@@ -48,6 +49,7 @@ private Q_SLOTS:
QCOMPARE(units.gridUnit(), 11.0);
qunsetenv("GRID_UNIT_PX");
}
+#endif
void dpGridUnitDefault() {
UCUnits units;
signature.asc
Description: PGP signature
Bug#1060802: stellarium: FTBFS on armel, ppc64el, s390x: unsatisfiable Build-Depends: qtwebengine5-dev (>= 5.15)
Hi James! On Wed, Jan 31, 2024 at 11:57:52PM +, James Addison wrote: > Source: stellarium > Followup-For: Bug #1060802 > X-Debbugs-Cc: tom...@debian.org, mity...@debian.org > > > stellarium 23.4-1 added a new build-dependency on qtwebengine5-dev, which > > prevents it from building on some release architectures (and all non-release > > ones). > > Would 'qtwebengine5-dev | libqt5webkit5-dev' provide an acceptable alternative > build dependency spec? > > Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913043;msg=10 Qt WebEngine and (deprecated) Qt WebKit are not compatible with each other, they provide different sets of classes. And it looks like upstream stellarium only supports Qt WebEngine, not WebKit. Good news is that Qt WebEngine support is optional and you can just build without it on architectures where it's not available. This can be achieved by limiting the build-dependency: qtwebengine5-dev (>= 5.15) [amd64 arm64 armhf i386 mips64el], I did that in Ubuntu [1] and the package built on all Ubuntu's architectures. [1]: https://launchpad.net/ubuntu/+source/stellarium/23.4-1ubuntu1 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060725: qutebrowser: Please remove python3-sip Depends
Hi Fritz! On Tue, Jan 30, 2024 at 11:12:28PM +0100, Fritz Reichwald wrote: > Hi Dimitry, > > thank you for the report. > I just uploaded a 2.5.4-2 without the dependency as it is no longer > needed as you already stated. Thank you for fixing this! -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061679: libqt5datavisualization5: Crashes in Q3DBars destructor on mips64el
Package: libqt5datavisualization5
Version: 5.15.10-2
X-Debbugs-Cc: m...@packages.debian.org, debian-m...@lists.debian.org
The following C++ program crashes on exit on mips64el:
#include
#include
#include
int main(int argc, char **argv) {
QApplication app(argc, argv);
QtDataVisualization::Q3DBars bars;
bars.show();
QTimer::singleShot(5000, app.quit);
return app.exec();
}
The stack trace is:
Thread 1 "test" received signal SIGABRT, Aborted.
0x00fff64599c4 in __pthread_kill_implementation (threadid=,
signo=, no_tid=) at pthread_kill.c:43
43 pthread_kill.c: No such file or directory.
(gdb) bt
#0 0x00fff64599c4 in __pthread_kill_implementation (threadid=, signo=, no_tid=) at pthread_kill.c:43
#1 0x00fff6403f48 in __GI_raise (sig=) at
../sysdeps/posix/raise.c:26
#2 0x00fff63ea8b4 in __GI_abort () at abort.c:79
#3 0x00fff6448b98 in __libc_message (fmt=) at
../sysdeps/posix/libc_fatal.c:150
#4 0x00fff6467804 in malloc_printerr (str=) at malloc.c:5658
#5 0x00fff646a11c in _int_free (av=0xfff65a0ad0 ,
p=0xaab7e352d0, have_lock=) at malloc.c:4584
#6 0x00fff646d014 in __GI___libc_free (mem=0xaab7e352e0) at malloc.c:3367
#7 0x00fff1c99d34 in _XShmDestroyImage (ximage=) at
../../src/XShm.c:265
#8 0x00fff1ddf014 in XCreateDrawable (pdp=0xaab6e5a5e0, shmid=-1,
dpy=0xaed340) at ../src/glx/drisw_glx.c:67
#9 0x00fff1ddfcec in swrastXPutImage (srcx=0, x=0, y=0, w=160,
h=, stride=640, shmid=, data=0xfff0804000
"\377\377\377", loaderPrivate=0xaab6e5a5e0,
op=, draw=, srcy=0) at
../src/glx/drisw_glx.c:197
#10 0x00fff09f5f68 in put_image2 (stride=, height=, width=, y=, x=,
data=,
drawable=) at ../src/gallium/frontends/dri/drisw.c:74
#11 drisw_put_image2 (drawable=, data=,
x=, y=, width=, height=, stride=)
at ../src/gallium/frontends/dri/drisw.c:174
#12 0x00fff112bd98 in dri_sw_displaytarget_unmap (ws=,
dt=0xadee30) at ../src/gallium/winsys/sw/dri/dri_sw_winsys.c:208
#13 0x00fff112df1c in softpipe_transfer_unmap (pipe=,
transfer=0xaab7e34d80) at ../src/gallium/drivers/softpipe/sp_texture.c:468
#14 0x00fff114d4b8 in sp_tile_cache_set_surface (tc=0xc8bab0, ps=0x0)
at ../src/gallium/drivers/softpipe/sp_tile_cache.c:179
#15 0x00fff1141150 in softpipe_set_framebuffer_state (pipe=0xb92da0,
fb=0xff2bf0) at ../src/gallium/drivers/softpipe/sp_state_surface.c:68
#16 0x00fff106a4e8 in cso_unbind_context (ctx=0xc24e30) at
../src/gallium/auxiliary/cso_cache/cso_context.c:456
#17 0x00fff106a6c0 in cso_destroy_context (ctx=0xc24e30) at
../src/gallium/auxiliary/cso_cache/cso_context.c:490
#18 0x00fff0ae67c8 in st_destroy_context_priv (st=0xc233d0,
destroy_pipe=true) at ../src/mesa/state_tracker/st_context.c:369
#19 0x00fff0ae856c in st_destroy_context (st=0xc233d0) at
../src/mesa/state_tracker/st_context.c:1018
#20 0x00fff09fc078 in dri_destroy_context (ctx=0xc8f0a0) at
../src/gallium/frontends/dri/dri_context.c:277
#21 0x00fff0a00cd4 in driDestroyContext (pcp=) at
../src/gallium/frontends/dri/dri_util.c:668
#22 0x00fff1ddecbc in drisw_destroy_context (context=0xc8ef20) at
../src/glx/drisw_glx.c:431
#23 0x00fff1de1ef0 in glXDestroyContext (ctx=0xc8ef20,
dpy=0xaed340) at ../src/glx/glxcmds.c:469
#24 glXDestroyContext (dpy=0xaed340, ctx=0xc8ef20) at
../src/glx/glxcmds.c:450
#25 0x00fff1e98c78 in QGLXContext::~QGLXContext (this=0xffec003120,
__in_chrg=) at qglxintegration.cpp:541
#26 QGLXContext::~QGLXContext (this=0xffec003120, __in_chrg=) at
qglxintegration.cpp:542
#27 0x00fff7162204 in QOpenGLContext::destroy (this=0xb65650) at
kernel/qopenglcontext.cpp:653
#28 0x00fff71626ac in QOpenGLContext::~QOpenGLContext (this=0xb65650,
__in_chrg=) at kernel/qopenglcontext.cpp:691
#29 0x00fff71626f8 in QOpenGLContext::~QOpenGLContext (this=0xb65650,
__in_chrg=) at kernel/qopenglcontext.cpp:696
#30 0x00fff6cc9c58 in QObjectPrivate::deleteChildren (this=0xb238d0) at
kernel/qobject.cpp:2137
#31 0x00fff6cdabe0 in QObject::~QObject (this=,
__in_chrg=) at kernel/qobject.cpp:1115
#32 0x00fff7107ad0 in QWindow::~QWindow (this=0xff3060,
__in_chrg=) at kernel/qwindow.cpp:227
#33 0x00fff7e87300 in
QtDataVisualization::QAbstract3DGraph::~QAbstract3DGraph (this=0xff3060,
__in_chrg=)
at /usr/include/mips64el-linux-gnuabi64/qt5/QtGui/qopenglfunctions.h:242
#34 0x00fff7e8b0d4 in QtDataVisualization::Q3DBars::~Q3DBars
(this=, __in_chrg=) at engine/q3dbars.cpp:120
#35 0x00aa992c in main (argc=1, argv=0xff3248) at
datavisualization_test.cpp:12
I was not able to analyze this problem with valgrind, as valgrind itself
crashes with SIGILL.
The problem does not happen on amd64, even if I force software rendering with
LIBGL_ALWAYS_SOFTWARE=1.
Any help with this is welcome.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1060741: ball: Please port from sip4 to sip6
Hi Andreas! On Sat, Jan 27, 2024 at 07:56:46AM +0100, Andreas Tille wrote: > I gave it a try by changing the Build-Depends first[1] and see what > happens[2]. I think the problem is caused by this Python file[3] where > I tried to replace > > import sipconfig > > by > > import sipbuild > > Since I'm lacking the knowledge about the new interface (and was not > able to find the solution after a *quick* search in sip6-doc) I gave up > here and ask for help. I could forward the issue upstream but I would > like to have a first idea about a patch. It is much more complicated than just changing the module name. SIP v4 (and v5, in compatibility mode) had a command-line tool that accepted all relevant details about project configuration as command-line arguments. In SIP v6, the project should have a pyproject.toml and, in most cases, project.py files for that purpose. See [1] and [2] for examples of such files. Sometimes, when the content of pyproject.toml can not be static, and it needs to be generated at build time. For example, krita [3] and QGIS [4] do that. If you want to see how a patch for porting to the new build system could look like, take a look at [5] or [6]. There is an alternative approach that involves using sipbuild API directly, without pyproject.toml file, however that API is poorly documented and can change between releases. But as porting is a major work (and sorry, I am more busy than I was in 2021 and I don't have time for that), I would recommend contacting upstream and providing this information to them first. If a project is active, they will have to do that anyway (SIP v4 does not support Python 3.11+). If the project is dead, maybe it's not worth it, and ball should be removed from Debian? [1]: https://github.com/frescobaldi/python-poppler-qt5/blob/master/pyproject.toml [2]: https://github.com/frescobaldi/python-poppler-qt5/blob/master/project.py [3]: https://invent.kde.org/graphics/krita/-/blob/master/cmake/modules/SIPMacros.cmake [4]: https://github.com/kadas-albireo/QGIS/blob/master/python/CMakeLists.txt [5]: https://github.com/GauiStori/PyQt-Qwt/pull/14 [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964127#51 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061454: python3-dput: Does not work with Python 3.12: 'ConfigParser' object has no attribute 'readfp'
Package: python3-dput Version: 1.37 Severity: important User: debian-pyt...@lists.debian.org Usertags: python3.12 Dear Maintainer, This module seems to be incompatible with Python 3.12: $ dput ftp-master sip6_6.8.2+dfsg-1_source.changes Traceback (most recent call last): File "/usr/bin/dput", line 129, in upload_package(changes, args) File "/usr/lib/python3/dist-packages/dput/uploader.py", line 274, in invoke_dput profile = dput.profile.load_profile(args.host) File "/usr/lib/python3/dist-packages/dput/profile.py", line 191, in load_profile _multi_config = MultiConfig() ^ File "/usr/lib/python3/dist-packages/dput/profile.py", line 85, in __init__ self.preload(configs) File "/usr/lib/python3/dist-packages/dput/profile.py", line 101, in preload classes[obj['type']]( File "/usr/lib/python3/dist-packages/dput/config.py", line 42, in __init__ self.preload(configs) File "/usr/lib/python3/dist-packages/dput/configs/dputcf.py", line 60, in preload parser.readfp(open(config, 'r')) ^ AttributeError: 'ConfigParser' object has no attribute 'readfp'. Did you mean: 'read'? Quoting Python 3.12 changes page: > Several names deprecated in the configparser way back in 3.2 have been > removed per gh-89336: > > [...] > - configparser.ConfigParser no longer has a readfp method. Use read_file() > instead. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1061179: transition: qtbase-abi-5-15-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 1060761 1060802 Dear Release team, I have skipped Qt 5.15.11 release and would like to upgrade to 5.15.12 which was published in December. Qt WebEngine will be upgraded from 5.15.15 to 5.15.16. The transition is prepared in experimental. There are two blockers, lomiri-ui-toolkit and stellarium, but I can NMU them. I have submitted a merge request with the ben file: https://salsa.debian.org/release-team/transition-data/-/merge_requests/47 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060802: stellarium: FTBFS on armel, ppc64el, s390x: unsatisfiable Build-Depends: qtwebengine5-dev (>= 5.15)
Source: stellarium Version: 23.4-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: ftbfs Dear Maintainer, stellarium 23.4-1 added a new build-dependency on qtwebengine5-dev, which prevents it from building on some release architectures (and all non-release ones). Upstream mentions [1] that Qt WebEngine build-dependency is optional and can be either detected automatically by the build system, or configured explicitly using -DENABLE_QTWEBENGINE=ON/OFF [2]. Qt WebEngine is available only amd64, arm64, armhf, i386 and mips64el, and it's unlikely that this set of architectures will be changed for Qt 5. So you can limit the build-dependency to these architectures. [1]: https://github.com/Stellarium/stellarium/blob/master/BUILDING.md#linux-without-qtwebengine [2]: https://github.com/Stellarium/stellarium/blob/master/BUILDING.md#supported-cmake-parameters -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1058371: python-cloup: FTBFS: make[1]: *** [Makefile:20: html] Error 2
Control: reassign -1 python3-astroid 2.15.6-1 Control: retitle -1 python3-astroid: incompatible with Python 3.12 (exception: 'TreeRebuilder' object has no attribute 'visit_typealias') Control: affects -1 + src:python-cloup src:sphinx-autoapi Control: block 1056529 1058408 by -1 Control: tags -1 + fixed-upstream Hi all, On Tue, Dec 12, 2023 at 09:27:12AM +0100, Lucas Nussbaum wrote: > Source: python-cloup > Version: 3.0.3-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20231212 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > make[1]: Entering directory '/<>/docs' > > Running Sphinx v7.2.6 > > making output directory... done > > /usr/lib/python3/dist-packages/autoapi/extension.py:137: > > RemovedInSphinx80Warning: Sphinx 8 will drop support for representing paths > > as strings. Use "pathlib.Path" or "os.fspath" instead. > > elif app.srcdir != os.getcwd(): > > /usr/lib/python3/dist-packages/autoapi/mappers/python/mapper.py:300: > > RemovedInSphinx80Warning: The alias 'sphinx.util.status_iterator' is > > deprecated, use 'sphinx.util.display.status_iterator' instead. Check > > CHANGES for Sphinx API modifications. > > for dir_root, path in sphinx.util.status_iterator( > > [2K[AutoAPI] Reading files... [ 4%] /<>/cloup/__init__.py > > [2K[AutoAPI] Reading files... [ 9%] /<>/cloup/_util.py > > [2K[AutoAPI] Reading files... [ 13%] /<>/cloup/_sections.py > > [2K[AutoAPI] Reading files... [ 17%] /<>/cloup/_commands.py > > > > Extension error (autoapi.extension): > > Handler for event 'builder-inited' > > threw an exception (exception: 'TreeRebuilder' object has no attribute > > 'visit_typealias') > > make[1]: *** [Makefile:20: html] Error 2 This is actually caused by astroid 2.15 being incompatible with Python 3.12. In upstream it was fixed in commit [1], which is part of a larger PR [2] that adds support for Python 3.12. These changes were included in astroid 3.0, so updating to that release should fix the problem. [1]: https://github.com/pylint-dev/astroid/commit/6d4f364a08289bf3 [2]: https://github.com/pylint-dev/astroid/pull/2219 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060761: lomiri-ui-toolkit: FTBFS with Qt ≥ 5.15.11: error: invalid use of non-static member function ‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
Source: lomiri-ui-toolkit
Version: 1.3.5010+dfsg-3
Severity: important
Tags: ftbfs upstream
Dear Maintainer,
lomiri-ui-toolkit fails to build with Qt ≥ 5.15.11. Currently there is version
5.15.12 available in experimental, but I would like to upload it to unstable
soon.
The first error is:
ucstylehints.cpp: In member function ‘void
UCStyleHintsParser::verifyProperty(const
QQmlRefPointer&, const
QV4::CompiledData::Binding*)’:
ucstylehints.cpp:54:23: error: invalid use of non-static member function
‘QV4::CompiledData::Binding::Type QV4::CompiledData::Binding::type() const’
54 | if (binding->type == QV4::CompiledData::Binding::Type_Object) {
| ~~^~
In file included from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qv4executablecompilationunit_p.h:54,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlcontext_p.h:69,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlproperty_p.h:60,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlbinding_p.h:59,
from
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qqmlcustomparser_p.h:55,
from ucstylehints_p.h:25,
from ucstylehints.cpp:19:
/usr/include/x86_64-linux-gnu/qt5/QtQml/5.15.12/QtQml/private/qv4compileddata_p.h:544:10:
note: declared here
544 | Type type() const { return Type(flagsAndType.get()); }
| ^~~~
This error is fixed by upstream pull request [1], however there is another
issue with tst_UCUnits::gridUnitEnvironmentVariable() test which is not yet
fixed upstream. Perhaps it can be disabled until upstream figures out what to
do with it.
[1]:
https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/merge_requests/63
[2]: https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1059648: sip4: autopkgtest failure with Python 3.12
On Sun, Jan 07, 2024 at 06:34:24PM +0300, Dmitry Shachnev wrote: > krita and pyqwt3d have open bugs to move to sip6, but I will need to file > bugs for the other packages too. All the missing bugs are filed now: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=mity...@debian.org;tag=sip6 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060745: openstructure: Please remove sip-dev from Build-Depends
Source: openstructure Version: 2.5.0-1 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on sip-dev, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. It looks like openstructure already uses SIP 6, so the left-over build- dependency on sip-dev can be dropped. I tried building without it, and the build succeeded. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060744: stimfit: Please port from sip4 to sip6
Source: stimfit Version: 0.16.0-1.2 Severity: important Usertags: sip6 Dear Maintainer, Your package currently builds with sip4, which is a deprecated version of SIP. The modern version of SIP is packaged as sip6. The documentation on how to use modern SIP is available in sip6-doc package, or on the SIP website [1]. It looks like stimfit only uses SIP by including . In SIP 6, it needs to be generated on the fly, by running a command like: sip-module PyQt5.sip --sip-h Where PyQt5.sip is the name of the run-time SIP module that you want to use, and sip-module(1) is provided by sip-tools package. SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed. Please port this package to SIP 6, and after that is done, remove the build- dependency on python3-sip-dev. [1]: https://www.riverbankcomputing.com/static/Docs/sip/ [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060742: guidata: Please remove python3-sip from Build-Depends
Source: guidata Version: 3.0.4+dfsg1-1 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on python3-sip-dev, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. I briefly looked at the code, and it looks like sip is only referenced in context of py2exe/cx_Freeze, which I believe are not used in Debian packaging. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060741: ball: Please port from sip4 to sip6
Package: ball Version: 1.5.0+git20180813.37fc53c-11 Severity: important Usertags: sip6 Dear Maintainer, Your package currently builds with sip4, which is a deprecated version of SIP. The modern version of SIP is packaged as sip6. The documentation on how to use modern SIP is available in sip6-doc package, or on the SIP website [1]. The recommended approach is using SIP's own PEP 517-compliant build system (i.e. pyproject.toml and project.py files), however some projects (e.g. krita upstream) have successfully integrated SIP 6 into their CMake-based build systems. SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed. Please port this package to SIP 6, and after that is done, remove the build- dependency on python3-sip-dev. [1]: https://www.riverbankcomputing.com/static/Docs/sip/ [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060739: geophar: Please remove python3-sip from Build-Depends and autopkgtest Depends
Source: geophar Version: 18.10+dfsg1-1 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on python3-sip, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. It looks like the sip import is used only in tools/test.py and there it is used for sip.setapi(*, 2) calls. Such calls are not needed at all with PyQt5. They were needed only with PyQt4 and Python 2. So it should be safe to remove them. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060736: eric: Please remove python3-sip-dev from Build-Depends-Indep
Source: eric Version: 23.2+ds1-2 Severity: important Usertags: sip6 Dear Maintainer, Your package build-depends on python3-sip-dev, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. As eric uses PyQt6, it should not need python3-sip-dev for build. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#964126: fixed in krita 1:5.2.2+dfsg-2
On Sat, Jan 13, 2024 at 01:36:54PM +, Debian FTP Masters wrote: > Source: krita > Source-Version: 1:5.2.2+dfsg-2 > Done: Pino Toscano > > We believe that the bug you reported is fixed in the latest version of > krita, which is due to be installed in the Debian FTP archive. > [...] That was fast! Appreciated. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060728: tulip: Please port from sip4 to sip6
Package: tulip Version: 5.4.0+dfsg-3 Severity: important Usertags: sip6 Dear Maintainer, Your package currently builds with sip4, which is a deprecated version of SIP. The modern version of SIP is packaged as sip6. The documentation on how to use modern SIP is available in sip6-doc package, or on the SIP website [1]. The recommended approach is using SIP's own PEP 517-compliant build system (i.e. pyproject.toml and project.py files), however some projects (e.g. krita upstream) have successfully integrated SIP 6 into their CMake-based build systems. SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed. Please port this package to SIP 6, and after that is done, remove build-dep on python3-sip-dev and runtime dependency on python3-sip. [1]: https://www.riverbankcomputing.com/static/Docs/sip/ [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#966055: vistrails: Uses old name of sip module
Control: severity -1 important
Hi,
On Wed, Jul 22, 2020 at 02:44:00PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> You are receiving this bug because your package seems to be using PyQt5
> and has Python files with "import sip" lines.
>
> With the latest version of PyQt5 in experimental, the private sip module
> used by PyQt5 is called "PyQt5.sip", not just "sip". I am going to upload
> this version to unstable around end of August.
>
> You may need to update your imports to do something like this:
>
> try:
> from PyQt5 import sip
> except ModuleNotFoundError:
> import sip
>
> Alternatively, you may import sip after importing PyQt5. So the following
> will work too:
>
> from PyQt5 import QtCore
> import sip
>
> Please see the following link for details:
>
> https://www.riverbankcomputing.com/static/Docs/PyQt5/incompatibilities.html#importing-the-sip-module
>
> If you use sip for reasons unrelated to PyQt5, you may leave the old import
> as is, but please bear in mind that sip4 is deprecated.
>
> Also, calls like "sip.setapi('QDate', 2)" are not needed at all with PyQt5.
> They were needed only with PyQt4 and Python 2. It is safe to delete them.
>
> For the actual documentation of sip module, see the following link:
>
> https://www.riverbankcomputing.com/static/Docs/PyQt5/api/sip/sip-module.html
It looks like the only file where sip is imported before PyQt5 is
vistrails/packages/CLTools/wizard.py, and it uses sip for setapi() calls
which are, as described in this bug report, no longer needed.
In addition to fixing that file, please also remove python3-sip dependency.
You may want to depend on python3-pyqt5 instead, as it is used in this
package.
I am bumping the severity to important because sip4 is RC-buggy [1] and I am
going to remove it from Debian.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1060727: python3-python-qt-binding: Please port from sip4 to sip6
Package: python3-python-qt-binding Version: 0.4.4-2 Severity: important Usertags: sip6 Dear Maintainer, Your package ships sip_configure.py and sip_helper.cmake which are designed to work with the old version of SIP, sip4. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. The documentation on how to use modern SIP is available in sip6-doc package, or on the SIP website [1]. The recommended approach is using SIP's own PEP 517-compliant build system (i.e. pyproject.toml and project.py files), however some projects (e.g. krita upstream) have successfully integrated SIP 6 into their CMake-based build systems. SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed. So, if the mentioned files are still needed, please port them to SIP 6, and drop dependencies on sip-dev and python3-sip-dev packages. [1]: https://www.riverbankcomputing.com/static/Docs/sip/ [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060725: qutebrowser: Please remove python3-sip Depends
Package: qutebrowser Version: 2.5.4-1 Severity: important Usertags: sip6 Dear Maintainer, Your package depends on python3-sip, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip, so there is no need to depend on it explicitly. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060724: meteo-qt: Please remove python3-sip Depends
Package: meteo-qt Version: 3.3-2 Severity: important Usertags: sip6 Dear Maintainer, Your package depends on python3-sip, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip, so there is no need to depend on it explicitly. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1060723: gnuradio: Please remove python3-sip Depends
Package: gnuradio Version: 3.10.9.1-1 Severity: important Usertags: sip6 Dear Maintainer, Your package depends on python3-sip, which belongs to the deprecated sip4 source package. The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages in Debian are built with that modern version. python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip, so there is no need to depend on it explicitly. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#964126: krita: Please switch from sip4 to sip5
Control: retitle -1 krita: Please switch from sip4 to sip6 Hi again! On Mon, Sep 21, 2020 at 02:24:04PM +0300, Dmitry Shachnev wrote: > I have an update on PyQt5 vs. SIP 5 status. > > Unfortunately, things got a bit more complicated recently. Upstream is > going to release SIP 6 in the beginning of next year, which will be not > co-installable together with SIP 5, and which will not have /usr/bin/sip5 > “legacy” script: > > https://www.riverbankcomputing.com/pipermail/pyqt/2020-September/043201.html > https://www.riverbankcomputing.com/pipermail/pyqt/2020-September/043162.html > > sip5 was a script to ease upgrades from SIP 4, and it has a set of options > similar to SIP 4's /usr/bin/sip. Upstream now recommends using their new > tools, sip-build and similar ones. See the documentation: > > https://www.riverbankcomputing.com/static/Docs/sip/ > > This means that next year we will have SIP 4 and SIP 6 in Debian, but not > SIP 5. My upstream work on Krita made use of /usr/bin/sip5, so it will need to > be ported to the new tools in order to support SIP 6 (and PyQt6). > > At the same time, upstream says that it will remain possible to compile > applications with SIP 4 even when PyQt5 uses newer SIP. So now I think the > best plan is: > > - Please keep using SIP 4 for Krita for now. > - Please test that it still works fine with PyQt5 in experimental. > - Ask upstream to migrate to the new tools to be prepared for SIP 6 / PyQt6. Another update on this. It looks like upstream integrated proper support [1] for SIP 5+ a couple of years ago, and a recent commit [2] indicates that it builds with the latest version, 6.8, too. So please switch from SIP 4 to SIP 6, maybe picking the needed commit(s) from upstream. From packaging standpoint that will mean: - Build-depending on sip-tools and python3-sipbuild instead of python3-sip-dev. - Dropping Recommends: python3-sip. Recommends already has python3-pyqt5, which ensures the presence of proper SIP runtime. SIP 4 has an RC bug related to Python 3.12 [3] and it's unlikely to be fixed. [1]: https://invent.kde.org/graphics/krita/-/commit/5bb4874ad04b771a0fec12827de748780b5b395b [2]: https://invent.kde.org/graphics/krita/-/commit/2d71c47661d43a4e3c1ab0c27803de980bdf2bb2 [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Hi James! On Tue, Jan 09, 2024 at 06:40:35PM +, James Addison wrote: > Followup-For: Bug #1059631 > X-Debbugs-Cc: mity...@debian.org > > Hi Dmitry - could you recommend whether there's anything I should do next for > this bug? > > As context: the patch was accepted upstream, but with modifications that make > it cleaner for Qt6.6 albeit in a non-5.15.x compatible way. I realize that > might not be ideal maintainence-wise; sorry about that. I'm a bit unclear on > the licensing status of 5.15.x and that's making me uncertain about whether to > offer another patch for that lineage upstream. > > My sense is that with the patch here and also the patch from #1059592 applied, > we would see at least eight qt-related packages in Debian building with more > reliable reproducibility. Not a huge number, but it's becoming rarer to find > fixups like this that benefit multiple dependent packages (a good thing). I was going to include these patches together with Qt 5.15.12 transition, which I am currently preparing. But if you want it in unstable sooner, I can do a new upload for 5.15.10 and then merge into my 5.15.12 branch. Just let me know if you need that. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1058945: python3-secretstorage: please do not depend on dbus package
On Sun, Jan 07, 2024 at 07:31:48PM +0100, Ansgar wrote: > > gnome-keyring | alternatives is in Recommends, not in Depends. > > > > The reason for that is because someone may want to use secretstorage > > with a different server that is not listed there, and we do not have a > > virtual package name that any such implementation can provide (like e.g. > > notification-daemon is provided by 14 different packages). > > So will you add a virtual package and a strict dependency? AFAIU it is > about as uesless without one of these providers as it is without Dbus. I think you really don't want it to be a strict dependency, do you? > > I can suggest two solutions: > > > > 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. > > 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage > > | python3-keyrings.alt. > > > > Will any of that work for you? > > I think that is still fundamentally wrong. > > A program X linking a library (classic C libraries or python3-* stuff; > implementation doesn't matter) will result in a relation "X depends > libY". > > But that doesn't say anything about if users actually will use "libY". > > For example, consider libY as a library speaking to Pulseaudio, libZ a > library speaking to jack2d. The application X now links libY and libZ > as it has support for audio output via libY or libZ; it can also output > audio via ALSA. > > Installing X thus installs libY and libZ. > > Clearly libY is useless without PA and libZ useless without Jack in the > same way as python3-keyring is useless without Dbus + Secret Service > backend. > > Should libY thus depend on Dbus + Pulseaudio and libZ depend on jackd? > That would result in a user wanting to install X having to install > Dbus, Pulseaudio and Jack. That is in particular two audio servers > that will then be enabled by default. > > As Debian tries to build packages with as much optional stuff as > possible enabled, this would happen very often (we have more sound > servers...). > > Is that useful? I think not and think libraries *must not* depend on > services for that reason. If soemthing explicitly depends on a service, > it should be an application, not some library. Your analogy doesn't 100% apply to Python world. In C, if you link to some library, your application won't start when that library is not installed. However, in Python, it's quite easy to make imports optional. And Keyring does exactly this, "import keyring" will not fail if python3-secretstorage is not installed. So, if some users of python3-keyring don't need python3-secretstorage, we can make it Recommends, not Depends. Similarly, I see that poetry imports keyring not on the top level, but in the code where it's actually needed [1], and poetry will start when keyring is not installed, so maybe poetry should Recommend python3-keyring, not depend on it. But anyway, if you insist that python3-secretstorage should not depend on dbus-related packages, I can demote that to Recommends. For most users that shouldn't make any difference because we have Recommends enabled by default. Will that work for you? [1]: https://sources.debian.org/src/poetry/1.7.1%2Bdfsg-1/src/poetry/utils/password_manager.py/#L48 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059648: sip4: autopkgtest failure with Python 3.12
Hi Gregor! On Sun, Jan 07, 2024 at 03:40:49PM +0100, Gregor Riepl wrote: > I can reproduce that, although I should mention that the segfault happens > during teardown, not when the module is loaded: > > >>> import sip > >>> print(sip) > '/usr/lib/python3/dist-packages/sip.cpython-312-x86_64-linux-gnu.so'> > >>> > > Program received signal SIGSEGV, Segmentation fault. > 0x00513a8d in PyMem_Free () > (gdb) bt > #0 0x00513a8d in PyMem_Free () > #1 0x7f73de6feaf9 in sip_api_free (mem=) at > ./siplib/siplib.c:2241 > #2 0x7f73de710c6d in sipOMFinalise (om=) at > ./siplib/objmap.c:69 > #3 0x7f73de6febaf in finalise () at ./siplib/siplib.c:2143 > #4 0x004591ab in ?? () > #5 0x00662d77 in Py_RunMain () > #6 0x006232eb in Py_BytesMain () > #7 0x7f73deba66ca in __libc_start_call_main (main=main@entry=0x623240, > argc=argc@entry=1, argv=argv@entry=0x7ffd043a59b8) at > ../sysdeps/nptl/libc_start_call_main.h:58 > #8 0x7f73deba6785 in __libc_start_main_impl (main=0x623240, argc=1, > argv=0x7ffd043a59b8, init=, fini=, > rtld_fini=, stack_end=0x7ffd043a59a8) > at ../csu/libc-start.c:360 > #9 0x00623171 in _start () Yes, I saw the same. In SIP 6, there were 3 commits to add support for Python 3.12, but the code diverged a lot so it's not trivial to backport them to SIP 4. > I'd also like to point out that SIP4 is no longer supported upstream. The > current version is 6.8.1, which is already packaged for Debian. > https://www.riverbankcomputing.com/software/sip/download > > > SIP v4 is no longer supported. This is the last release. > > sip-4.19.25.tar.gz > > Cura was made fit for PyQt6 and SIP6 in April 2022, and I think 5.0 has all > the needed changes. I will investigate if we can drop the dependency on > python3-sip-dev. As far as I can see, there are no other users of SIP4 in > Debian, so maybe it can be dropped completely after fixing Cura. Unfortunately there are other users: $ reverse-depends src:sip4 -r sid Reverse-Recommends == * krita [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] Reverse-Depends === * gnuradio [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * meteo-qt [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-pykdl [amd64 arm64 armel armhf i386 mips64el ppc64el s390x] * python3-python-qt-binding (for python3-sip-dev) * python3-python-qt-binding (for sip-dev) * qutebrowser (for python3-sip) * tulip [amd64 arm64 i386 mips64el ppc64el s390x] * vistrails (for python3-sip) $ reverse-depends -b src:sip4 -r sid Reverse-Testsuite-Triggers == * geophar (for python3-sip) Reverse-Build-Depends = * ball (for python3-sip-dev) * geophar (for python3-sip) * guidata (for python3-sip) * krita (for python3-sip-dev) * libarcus (for python3-sip-dev) * libsavitar(for python3-sip-dev) * openstructure (for sip-dev) * orocos-kdl(for python3-sip-dev) * pynest2d (for python3-sip-dev) * pyqwt3d (for python3-sip-dev) * stimfit (for python3-sip-dev) * tulip (for python3-sip-dev) Reverse-Build-Depends-Indep === * eric (for python3-sip-dev) krita and pyqwt3d have open bugs to move to sip6, but I will need to file bugs for the other packages too. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Hi Ansgar! On Sat, Jan 06, 2024 at 07:50:47PM +0100, Ansgar wrote: > That doesn't help much unless one takes special care. This is what > installing python3-poetry in a Podman container looks like: > [...] > > Now try not to install an init system, dbus, ... in a application > container wanting to use python3-poetry to install some Python > application. > > And this still doesn't ensure that: > 1. dbus is actually running in the context where python3-secretstorage is > used, > 2. the Dbus interface python3-secretstorage wants to talk to is actually > provided by a service > > (For 2. it doesn't even have a Depends: gnome-keyring | alternatives > either which is inconsistent with the dependency on Dbus...) gnome-keyring | alternatives is in Recommends, not in Depends. The reason for that is because someone may want to use secretstorage with a different server that is not listed there, and we do not have a virtual package name that any such implementation can provide (like e.g. notification-daemon is provided by 14 different packages). > Also it's unknown whether that is actually useful or not (as python3- > secretstorage is just a library that could not be relevant at all as > the application's user might not actually want to manage secrets via > keepassxc). > > It seems excessive to *always* require all of this to be installed for > *any* use of python3-poetry (which can optionally use python3- > secretstorage if that is even required). bash doesn't depend on gnome- > terminal either just because one needs some terminal to run it in ;-) I think python3-secretstorage is completely useless without D-Bus. So maybe this dependency chain should be cut at a higher level, e.g. between python3-keyring and python3-secretstorage. I am also the uploader of python3-keyring, so we can discuss it here. I can suggest two solutions: 1. Replace python3-keyring → python3-secretstorage Depends with Recommends. 2. Keep it Depends, but add some alternatives, e.g. python3-secretstorage | python3-keyrings.alt. Will any of that work for you? Some background: python3-keyring has different backends. In Debian, the following may be relevant: - The Secret Service backend (using python3-secretstorage). The major implementations of Secret Service interface are GNOME Keyring, KWallet and KeePassXC. - The legacy KWallet D-Bus backend (KWallet supports Secret Service in recent versions, so the usefulness of it is limited). - File-based backends provided by python3-keyrings.alt. The plain-text file backend is insecure and not recommended; the encrypted file backend is using getpass() to get the password so it can be used in CLI applications, but less useful in GUI ones. See also some related discussion in this Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/python-secretstorage/+bug/2041695 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1058945: python3-secretstorage: please do not depend on dbus package
Control: tags -1 +moreinfo Hi Ansgar! On Mon, Dec 18, 2023 at 08:14:55PM +0100, Ansgar wrote: > Package: python3-secretstorage > Version: 3.3.3-2 > Severity: normal > > Please do not depend on dbus. > > Currently installing anything depending on python3-secretstorage will > install dbus-user-session and with it systemd-sysv, for example: > python3-poetry -> python3-keyring -> poetry3-secretstorage -> dbus > > This is pretty useless in containers. So please do not force to > install it: it should be fine to just return an error in case the > secret storage service is not reachable, for example because there is > no dbus bus to use. > > If anything, only applications should require specific interfaces. A > library like python3-secretstorage cannot know whether its use is > essential (in which case dbus should probably be a dependency) or > totally optional (in which case dbus should be suggested/recommended). I am confused. In version 3.3.3-2, python3-secretstorage changed dependency from dbus to default-dbus-session-bus | dbus-session-bus. And you filed this bug against the new version, 3.3.3-2. Is that a mistake? Or the new dependency is still not good? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
On Sat, Dec 30, 2023 at 10:02:00PM +, James Addison wrote: > Package: qhelpgenerator-qt5 > Followup-For: Bug #1059631 > X-Debbugs-Cc: mity...@debian.org > Control: forwarded -1 https://codereview.qt-project.org/c/qt/qttools/+/527972 > > Hi Dmitry, > > On Sat, 30 Dec 2023 22:50:47, Dmitry wrote: > > Thank you for the patch! > > > > Any chance you can forward it to upstream Qt? See [1] for the details. > > Yep, certainly - done. Thanks! Thank you! +1 from me and added a couple of reviewers. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059631: qhelpgenerator-qt5: nearly-reproducible LastRegisterTime value in .qch files is not timezone-normalized
Hi James! On Sat, Dec 30, 2023 at 05:12:52PM +, James Addison wrote: > Package: qhelpgenerator-qt5 > Followup-For: Bug #1059631 > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > My apologies: I had indeed misdiagnosed the problem here. > > The code that inserts into the SettingsTable, where the problem reported here > manifests, is unrelated to the patch from bug #875847 - there is a separate > check for SOURCE_CODE_EPOCH in the src/assistant/qhelpgenerator/main.cpp file. > > To test a fix, I used the following commands to replicate the problem: > > $ SOURCE_DATE_EPOCH=1503951538 qhelpgenerator > examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o > foo.qch > $ TZ=GMT+8 SOURCE_DATE_EPOCH=1503951538 qhelpgenerator > examples/assistant/simpletextviewer/documentation/simpletextviewer.qhcp -o > bar.qch > > Please find attached a patch to address the problem. Note that I decided to > patch both SOURCE_CODE_EPOCH locations for consistency, despite the fact that > only the main.cpp code site was confirmed affected. Thank you for the patch! Any chance you can forward it to upstream Qt? See [1] for the details. I could forward it myself, but upstream requires signing the CLA so they will not always accept a patch which is forwarded not by its author. [1]: https://wiki.qt.io/Gerrit_Introduction -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1059621: sphinx-common: dh_sphinxdoc fails to run: "search.html does not load searchindex.js"
Hi Drew! On Fri, Dec 29, 2023 at 01:59:53PM +0100, Drew Parsons wrote: > Package: sphinx-common > Version: 7.2.6-3 > Severity: normal > > I'm trying to run dh_sphinxdoc on new docs generated for lammps. > But dh_sphinxdoc fails: > > $ dh_sphinxdoc > dh_sphinxdoc: error: debian/lammps-doc/usr/share/doc/lammps/html/search.html > does not load searchindex.js > > with exit code 255. > > Well no kidding, search.html really does not reference searchindex.js. > Why is this causing dh_sphinxdoc to fail? dh_sphinxdoc should be > replacing existing .js references in the html files, not complaining > about ones which are not there. > > Adding an -Xsearch.html option does not fix the problem. dh_sphinxdoc not only symlinks .js files, but also performs some sanity checks. In particular, it checks stuff related to searchindex, search page and _sources files. In lammps case, it looks like the search page is very unusual and relies on Google's Custom Search Engine. So, in fact, it searches not in the local documentation, but on docs.lammps.org website. This is exactly what Lintian warning privacy-breach-google-cse is about. I would recommend replacing upstream search.html with pristine version from sphinx-rtd-theme [1] (that lammps theme is based on). Sphinx's default search relies on source RST files (_sources), so you will also need to stop removing them in doc/Makefile. If you don't want to do that, then disabling dh_sphinxdoc is probably fine, because you don't need all of the Sphinx' JS functionality anyway. [1]: https://sources.debian.org/src/sphinx-rtd-theme/2.0.0%2Bdfsg-1/sphinx_rtd_theme/search.html/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057755: Qt WebEngine Security Support In Stable
Hi Soren, On Thu, Dec 21, 2023 at 12:48:44PM -0700, Soren Stoutner wrote: > On Thursday, December 21, 2023 3:00:23 AM MST Dmitry Shachnev wrote: > > Just one particular class (QQuickWebEngineDownloadItem) is private. My guess > > is that it’s upstream oversight, because upstream documentation even > > mentions > > that one needs to call QWebEngineDownloadRequest::accept() [1], yet calling > > that method is not possible without including a private header. > > > > [1]: https://doc.qt.io/qt-6/qquickwebengineprofile.html#downloadRequested > > There is both a public and a private version of the header for this class, > similar to a lot of classes in Qt WebEngine. > > The public versions of this header are contained in > `qquickwebengineprofile.h` > and `qwebenginedownloadrequest.h` in the qt6-webengine-dev package. No, they are both not of _this_ header. QQuickWebEngineProfile ≠ QQuickWebEngineDownloadRequest QWebEngineDownloadRequest ≠ QQuickWebEngineDownloadRequest Maybe my previous emails were not clear enough, let me try again. Qt has two different interface systems: Qt Widgets and Qt Quick. Qt Widgets can be used from C++ only. Qt Quick is intended for use from QML, but sometimes it can be controlled from C++ code, that's why there are C++ classes for it too. Many Qt modules, including Qt WebEngine, provide classes for both interface systems. For example, qt6-webengine source in Debian builds libqt6webenginewidgets6 and libqt6webenginequick6 binary packages. Angelfish is written in Qt Quick, unlike many other browsers which are using Qt Widgets. This is why it needs QQuick* classes, and the widgets classes can not be a replacement. > It isn’t clear to me why Qt feels the need to have private headers that > mirror > their public headers for many of their functions. This way you can easily change private ABI (e.g. add a new argument) without breaking the public interface. See https://wiki.qt.io/D-Pointer for details. > And there may be some way in which Qt borked their public QML implementation > of this particular class in such a way that one really does need to depend > on the private headers (in which case, as Dmitry has pointed out, they > would probably be very willing to fix it if it was reported to them). Probably. Feel free to create an upstream bug report, based on the analysis from my previous email. > But from what I can see by reviewing the code (without taking the time to > actually build a project and test it out myself) it ought to be possible for > Angelfish to just switch to using the public headers. As explained above, no, QQuickWebEngineDownloadRequest does not have a public header. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057755: Qt WebEngine Security Support In Stable
On Wed, Dec 20, 2023 at 02:06:28PM -0700, Soren Stoutner wrote: > I must admit that I have no personal experience with connecting QML and C++. I don’t have any personal experience with that too. > But it seems to me from the documentation Qt has produced there are several > ways to bridge the two without accessing private headers. > > https://doc.qt.io/qt-5/qtqml-cppintegration-overview.html > > Beyond what is written there, Angelfish deals with a lot of classes besides > WebEngineDownloadItem. Somehow, with all the others, they are able to do > what they need to do without accessing private headers, which would > indicate to me that there must be some way to do it in this case as well. I didn’t say that you need private headers for _any_ stuff like that. Just one particular class (QQuickWebEngineDownloadItem) is private. My guess is that it’s upstream oversight, because upstream documentation even mentions that one needs to call QWebEngineDownloadRequest::accept() [1], yet calling that method is not possible without including a private header. [1]: https://doc.qt.io/qt-6/qquickwebengineprofile.html#downloadRequested -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057755: Qt WebEngine Security Support In Stable
Hi Soren! On Wed, Dec 20, 2023 at 12:23:15PM -0700, Soren Stoutner wrote: > On Wednesday, December 20, 2023 7:01:47 AM MST Dmitry Shachnev wrote: > > Using a stub header results in dependency on private ABI just like including > > a normal header. > > I wonder if that just happens for the QML version of WebEngineDownloadItem. > > https://doc.qt.io/qt-5/qml-qtwebengine-webenginedownloaditem.html > > It doesn’t affect Privacy Browser, but I use the C++ version of > WebEngineDownloadItem. > > https://doc.qt.io/qt-5/qwebenginedownloaditem.html > > $ nm -D /usr/bin/privacybrowser | grep Qt_5_PRIVATE_API > $ Yes, it affects only the Qt Quick version. The C++ version is public: $ dpkg -L qtwebengine5-dev | grep -i downloaditem /usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets/QWebEngineDownloadItem /usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets/qwebenginedownloaditem.h $ dpkg -L qtwebengine5-private-dev | grep -i downloaditem /usr/include/x86_64-linux-gnu/qt5/QtWebEngine/5.15.15/QtWebEngine/private/qquickwebenginedownloaditem_p.h /usr/include/x86_64-linux-gnu/qt5/QtWebEngine/5.15.15/QtWebEngine/private/qquickwebenginedownloaditem_p_p.h /usr/include/x86_64-linux-gnu/qt5/QtWebEngineWidgets/5.15.15/QtWebEngineWidgets/private/qwebenginedownloaditem_p.h > > I think that angelfish developers should ask Qt upstream to make that class > > public, explaining how and why they use it. > > That makes sense to me. I have filed a Debian bug and an upstream bug > against Angelfish. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059164 > > https://bugs.kde.org/show_bug.cgi?id=478783 Small correction for your bug report. You write: “Qt 6 has a public version of this API: https://doc.qt.io/qt-6/qml-qtwebengine-webenginedownloadrequest.html” However, that link is for the QML interface documentation. But what angelfish actually does is using the Qt Quick class from the C++ code. As I understand, you have to do such things when you have mixed QML and C++ code, and want to interact with QML components from the C++ part. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057755: Qt WebEngine Security Support In Stable
On Mon, Dec 18, 2023 at 10:34:17AM -0700, Soren Stoutner wrote: > Adrian, > > On Sunday, December 17, 2023 3:11:10 AM MST Adrian Bunk wrote: > > I don't know what's going on with the headers, but there is a reason why > > the dependency gets generated: > > > > $ nm -D /usr/bin/angelfish-webapp | grep Qt_5_PRIVATE_API > > U > > _ZN22QQuickWebEngineProfile16downloadFinishedEP27QQuickWebEngineDownloadIte > > m@Qt_5_PRIVATE_API U > > _ZN22QQuickWebEngineProfile17downloadRequestedEP27QQuickWebEngineDownloadIt > > em@Qt_5_PRIVATE_API $ > > The public version of this class is found in: > > qquickwebengineprofile.h > > Which is part of the qtwebengine5-dev package. > > Private versions of this class can be found in: > > qquickwebengineprofile_p.h > qquickwebenginedownloaditem_p.h > > which are part of the qtwebengine5-private-dev package. > > This does beg the question of how angelfish builds against this private > header > without build-depending on qtwebengine5-private-dev. Perhaps that is an > answer that one of the angelfish maintainers, Pirate or Nilesh, can answer. QQuickWebEngineProfile is public. However, QQuickWebEngineDownloadItem, which is the argument of downloadFinished() and downloadRequested(), is private. In Qt 6 this class is renamed to QQuickWebEngineDownloadRequest, but it is still private for some reason. Angelfish includes the private header when building against Qt 6, and uses a stub header for Qt 5, as can be seen from the following code: #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0) #include "qquickwebenginedownloaditem.h" using DownloadItem = QQuickWebEngineDownloadItem; #else #include using DownloadItem = QQuickWebEngineDownloadRequest; #endif Using a stub header results in dependency on private ABI just like including a normal header. I think that angelfish developers should ask Qt upstream to make that class public, explaining how and why they use it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057755: Qt WebEngine Security Support In Stable
Hi Soren! On Sat, Dec 16, 2023 at 04:33:58PM -0700, Soren Stoutner wrote: > On Saturday, December 16, 2023 4:10:42 PM MST Adrian Bunk wrote: > > On Sat, Dec 16, 2023 at 01:22:13PM -0700, Soren Stoutner wrote: > > > Bookworm released with qtwebengine-opensource-src 5.15.8+dfsg-1, but > > > 5.15.13+dfsg-1~deb12u1 was later uploaded. > > > > That's not true, bookworm released with 5.15.13+dfsg-1~deb12u1. > > How does stable initially release with an ~deb12u1? I uploaded 5.15.13+dfsg-1 to experimental on 2023-03-19, when we were already a week into hard freeze, and I was not sure if the release team would approve an upload to unstable. They approved, but requested me to drop the pipewire enablement change (see #1032794), so I uploaded to unstable with a lower version number. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057357: qtremoteobjects-everywhere-src: FTBFS in bullseye and bookworm because of expired SSL certificates, will also FTBFS in trixie/sid eventually
Hi Santiago! On Sun, Dec 03, 2023 at 11:23:07PM +0100, Santiago Vila wrote: > [...] > > I'm attaching two patches to fix this. > > The first one modifies the script > tests/auto/external_IODevice/cert/generate.sh > so that certificates expire in ten years. > > The second patch is merely the result of running the script. Generally, we try to avoid including patches which have not been applied upstream. And upstream has solved this problem by simply regenerating the patches with the old configuration [1]. So I have forwarded your first patch to upstream [2] to give them chance to review it. If it's approved/merged, I will submit your second patch to regenerate the certificates again (I hope you don't mind). If there is no response from upstream, I will go ahead and make uploads with both patches in a week. [1]: https://code.qt.io/cgit/qt/qtremoteobjects.git/commit/?id=ac3b93c886c04bc1 [2]: https://codereview.qt-project.org/c/qt/qtremoteobjects/+/522923 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1057346: qt6-base-dev-tools is wrongly marked Multi-Arch: foreign
Hi Helmut and all!
On Sun, Dec 03, 2023 at 09:37:39PM +0100, Helmut Grohne wrote:
> [...]
>
> Assuming we're still on track, I think stuff comes out of ecm_query_qt,
> which is defined in modules/ECMQueryQt.cmake. This works differently for
> Qt5 and Qt6. For Qt5, it invokes Qt5::qmake -query. This is something we
> redirected to point at ${DEB_HOST_GNU_TYPE}-qmake and this generally
> gives the right variables. Getting there was a longer journey, but this
> now works neatly. What we're looking at here though is the Qt6 case and
> there we use Qt6::qtpaths. As far as I understand it, this is new in
> Qt6. While we did add a ${DEB_HOST_GNU_TYPE}-qmake6 wrapper script, I am
> not aware of any qtpaths6 wrapper. Running it like qtpaths6 --query
> QT_INSTALL_QML gives /usr/lib/x86_64-linux-gnu/qt6/qml here and that
> very plausibly explains the original failure.
Wrapping qtpaths6 should be possible. It accepts --qtconf option
just like qmake.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1042609: sphinxcontrib-mermaid: FTBFS with Sphinx 7.1, docutils 0.20: Could not import sphinx.util.SphinxParallelError (exception: No module named 'sphinx.util.SphinxParallelError')
Hi Faidon! On Mon, Nov 13, 2023 at 10:52:58AM +0200, Faidon Liambotis wrote: > Upstream commit 6f8de39¹, the only commit since 0.9.2, replaces > sphinx.util.SphinxParallelError by sphinx.util.DownloadFiles. > > I've verified that backporting this commit makes the package build > successfully in unstable, with Sphinx 7.2.6-2. > > However, the very same commit changes requirements.txt from > "Sphinx>=3.2.1" to "Sphinx<7". > > I'm not sure why. I'm not using, nor am I familiar with this plugin, so > I was hoping someone else that is could perhaps validate whether besides > being able to be built, the package actually works. > > 1: > https://github.com/mgaitan/sphinxcontrib-mermaid/commit/6f8de39a84fddc398542e9d4dc74ba55101e7d5e The SphinxParallelError class is defined in sphinx.errors module. It was available in sphinx.util because that module happened to import it from sphinx.errors, but that is no longer the case since Sphinx 6.1. Probably the author of the linked commit was testing with Sphinx 6.1 (or 6.2), but had different problems with early Sphinx 7 versions (only Sphinx 7.0.1 was available at that moment), so changed the dependency to <7. The change in README.rst looks trivial, so if it helps, I would go ahead and cherry-pick it to our packaging without the requirements.txt change. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Hi Nicholas! On Sun, Nov 12, 2023 at 03:36:20PM -0500, Nicholas D Steeves wrote: > > Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on > > Chromium codebase. > > > > Qt WebEngine user agents will look the following: > > > > Qt 5.15: > > Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > > QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36 > > So if we backport signon-ui's future Webkit -> WebEngine fix to > bookworm, Google might still blacklist bookworm kaccounts users for > having a user agent string that advertises an ancient browser? Yes, but I don't know Google's exact policy on this. But Chrome 87 is from 2020, which is much better than WebKit from 2016. > Chrome/87.0.4280.144 is pretty old. That said, I assume there are > security reasons why we should use WebEngine and not Webkit in bookworm? Yes. Qt WebKit has no security support at all, so many vulnerabilities discovered in WebKit since 2016 are likely present there. Qt WebEngine, on the contrary, backports security fixes from Chromium: https://sources.debian.org/src/qtwebengine-opensource-src/5.15.15%2Bdfsg-2/CHROMIUM_VERSION/ Unfortunately we do not have enough manpower to backport all these fixes to Debian stable releases, but Debian unstable has the latest Qt WebEngine most of the time (I'm speaking for 5.15 branch mostly, which I'm the maintainer of). That said, if signon-ui only loads one hardcoded website, and not random content, I don't think you need to worry much about security. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1054919: kaccounts-providers: google authentication hang after username entry
Hi everyone! Sorry for the late reply, but let me try to answer the questions which remain unanswered. On Sun, Oct 29, 2023 at 07:43:51PM +0100, Alexis Murzeau wrote: > I'm not sure how Qt webkit works, but I guess it behaves like a old > chrome browser. I don't know if it uses a different user agent, but > maybe Google doesn't recognize that it doesn't support newer web stuff. Qt WebKit does not identify itself like Chrome. It identifies itself like AppleWebKit and Safari, which makes sense because Safari is the most known browser based on WebKit engine. The current Qt WebKit user agent is: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/602.1 (KHTML, like Gecko) Qt/5.15.10 Version/10.0 Safari/602.1 The Qt/5.15.10 component may be replaced with name and version of the application. Indeed, this is an ancient version. I think 602.1 branch is from 2016. However, changing it to a newer version would be lying. Qt WebKit is not supported by upstream Qt since Qt 5.6, and the first community fork is also dead now. There is another fork, but I won't call it alive either. > Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead. > I guess signon-ui should move to QtWebEngine instead but sadly upstream > seems rather dead :(, the previous signon-ui release was more than 5 > years ago. Yes, Qt WebKit does not support Qt 6, so the only choice is to migrate to Qt WebEngine which is supported much better. I would recommend doing that even if you stay on Qt 5. Unlike Qt WebKit which is based on Apple WebKit, Qt WebEngine is based on Chromium codebase. Qt WebEngine user agents will look the following: Qt 5.15: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.15 Chrome/87.0.4280.144 Safari/537.36 Qt 6.4: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.4.2 Chrome/102.0.5005.177 Safari/537.36 Qt 6.6: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.6.0 Chrome/112.0.5615.213 Safari/537.36 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1055802: bookworm-pu: package qtbase-opensource-src/5.15.8+dfsg-11+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org
Control: affects -1 + src:qtbase-opensource-src
[ Reason ]
The main goal of the proposed update is to fix bug #1055280: broken Unicode
support in libqt5sql5-odbc because of patch for CVE-2023-24607.
Additionally, I backported fixes for three more CVEs which were discovered
in the meantime: CVE-2023-34410, CVE-2023-37369 and CVE-2023-38197.
[ Impact ]
The ODBC backend of Qt SQL is broken without this fix. In particular, it's
known to be broken when using it with Microsoft SQL server.
[ Tests ]
Unfortunately we do not run upstream testsuite in qtbase, due to known issues
with it. But all patches come from Qt upstream, where they have been tested of
course.
[ Risks ]
- The patches to fix Unicode regressions are quite trivial.
- The patch to fix CVE-2023-34410 is quite trivial too.
- This cannot be said about the remaining two patches (for CVE-2023-37369 and
CVE-2023-38197), however they are present in Debian unstable since version
5.15.10+dfsg-3 from 2023-07-27, and nobody has complained since then.
Also, all these CVE patches are present in KDE's Qt 5.15 branch. In fact,
our CVE-2023-37369.diff is based on the KDE's patch.
If you consider those last two patches risky, I will be happy to upload
without them, that is, with the regression fixes and CVE-2023-34410 only.
This way the upload will be equivalent to 5.15.8+dfsg-13 from 2023-07-05.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
* Backport upstream patches to fix regression caused by CVE-2023-24607.diff
(closes: #1055280).
* Backport fixes for three CVEs from Debian unstable:
- CVE-2023-34410: use of system CA certificates when not wanted
(closes: #1037210).
- CVE-2023-37369: potential buffer overflow in QXmlStreamReader.
- CVE-2023-38197: infinite loop in XML recursive entity expansion
(closes: #1041105).
[ Other info ]
See also the Security Tracker:
https://security-tracker.debian.org/tracker/source-package/qtbase-opensource-src
--
Dmitry Shachnev
diff --git a/debian/changelog b/debian/changelog
index 7215917..526e1c3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+qtbase-opensource-src (5.15.8+dfsg-11+deb12u1) UNRELEASED; urgency=medium
+
+ [ Alexander Volkov ]
+ * Backport upstream patches to fix regression caused by CVE-2023-24607.diff
+(closes: #1055280).
+
+ [ Dmitry Shachnev ]
+ * Backport fixes for three CVEs from Debian unstable:
+- CVE-2023-34410: use of system CA certificates when not wanted
+ (closes: #1037210).
+- CVE-2023-37369: potential buffer overflow in QXmlStreamReader.
+- CVE-2023-38197: infinite loop in XML recursive entity expansion
+ (closes: #1041105).
+
+ -- Debian Qt/KDE Maintainers Sun, 05 Nov 2023 18:18:43 +0300
+
qtbase-opensource-src (5.15.8+dfsg-11) unstable; urgency=medium
* Rename the patches for consistency and add DEP-3 headers.
diff --git a/debian/patches/CVE-2023-34410.diff b/debian/patches/CVE-2023-34410.diff
new file mode 100644
index 000..bc5e30d
--- /dev/null
+++ b/debian/patches/CVE-2023-34410.diff
@@ -0,0 +1,34 @@
+Description: Ssl: Copy the on-demand cert loading bool from default config
+ Otherwise individual sockets will still load system certificates when
+ a chain doesn't match against the configured CA certificates.
+ That's not intended behavior, since specifically setting the CA
+ certificates means you don't want the system certificates to be used.
+ .
+ This is potentially a breaking change because now, if you ever add a
+ CA to the default config, it will disable loading system certificates
+ on demand for all sockets. And the only way to re-enable it is to
+ create a null-QSslConfiguration and set it as the new default.
+Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=57ba6260c0801055
+Last-Update: 2023-06-08
+
+--- a/src/network/ssl/qsslsocket.cpp
b/src/network/ssl/qsslsocket.cpp
+@@ -2221,6 +2221,10 @@ QSslSocketPrivate::QSslSocketPrivate()
+ , flushTriggered(false)
+ {
+ QSslConfigurationPrivate::deepCopyDefaultConfiguration();
++// If the global configuration doesn't allow root certificates to be loaded
++// on demand then we have to disable it for this socket as well.
++if (!configuration.allowRootCertOnDemandLoading)
++allowRootCertOnDemandLoading = false;
+ }
+
+ /*!
+@@ -2470,6 +2474,7 @@ void QSslConfigurationPrivate::deepCopyD
+ ptr->sessionProtocol = global->sessionProtocol;
+ ptr->ciphers = global->ciphers;
+ ptr->caCertificates = global->caCertificates;
++ptr->allowRootCertOnDemandLoading = global->allowRootCertOnDemandLoading;
+ ptr->
Bug#1055574: nose is not ready for Python 3.12
Hi Matthias! On Fri, Nov 10, 2023 at 07:43:06AM +0100, Matthias Klose wrote: > Control: tags -1 + patch > > * Take the Fedora patch, but don't apply it (introduces a test regression). > * (Build-)depend on python3-zombie-imp. > * Fix more Python 3.12 deprecations. > > http://launchpadlibrarian.net/696912675/nose_1.3.7-11_1.3.7-11ubuntu1.diff.gz Nose is team-maintained, so please go ahead and upload this. Although, I won't add the Fedora patch if you solved the problem by using zombie-imp. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1055443: python3-streamlink-doc: Please rebuild against Sphinx ≥ 7.2
Hi Alexis! On Mon, Nov 06, 2023 at 08:42:55PM +0100, Alexis Murzeau wrote: > Sure I can do that. > > But what is a no-change upload ? > Just adding a version 6.3.1-2 to the changelog with a log message about this > is sufficient ? Yes, this is what I meant. On Mon, Nov 06, 2023 at 09:11:39PM +0100, Alexis Murzeau wrote: > I've uploaded a version 6.3.1-2 to mentors. > Here is the change I've made: > > https://salsa.debian.org/amurzeau/streamlink/-/commit/5bb9172891127bdf36d364db3669908f243df513 > > It is available here on mentors: > > dget -x > https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.3.1-2.dsc Thank you! Uploaded to Debian. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1055443: python3-streamlink-doc: Please rebuild against Sphinx ≥ 7.2
Package: python3-streamlink-doc Version: 6.3.1-1 Dear Maintainer, Currently streamlink autopkgtest is failing with Sphinx 7.2 [1], which was uploaded to unstable yesterday. The error is the following: Checking broken symlinks in /usr/share/doc/python3-streamlink/html /usr/share/doc/python3-streamlink/html/_static/_sphinx_javascript_frameworks_compat.js ERROR: There are broken symlinks It happens because Sphinx ≥ 6 no longer uses jQuery, and so the compatibility layer for jQuery was removed too. Please make a no-change upload building against Sphinx 7.2. Then this symlink will be no longer generated by dh_sphinxdoc. I can sponsor the upload if you prepare a commit. [1]: https://qa.debian.org/excuses.php?package=sphinx -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1042642: Why should a FTBFS against packages in experimental be serious?
Hello Martin! On Sat, Nov 04, 2023 at 05:13:04PM +0100, Martin Quinson wrote: > severity 1042642 important > thanks > > Hello Dmitry, > > I am wondering why you raised the severity of #1042642 to serious. Did I miss > the part of the policy document stating that packages *must* build correctly > against packages in experimental? Or is there anything else that I'm missing, > maybe? Please see my comment in the email that bumped severity [1]. It said that I was going to upload new Sphinx to unstable the next weekend. I bumped the severity a bit earlier to notify the maintainers about the upcoming upload and give them more chance to fix these bugs before the packages actually start to FTBFS. Now a week has passed, and I am going to upload sphinx tomorrow, 2023-11-05. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042642;msg=7 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1042668: Package builds fine
Control: tags -1 + patch Hi Thomas! On Mon, Oct 30, 2023 at 04:27:51PM +0100, Thomas Goirand wrote: > Tried rebuilding and it works. Closing... In fact, this package still FTBFS with new Sphinx. Backporting upstream commit [1] helps. I have created a merge request in salsa [2] to do that. I think ideally this bug should be re-opened and then closed from the changelog, but as you explicitly asked to not re-open bugs [3], I am not doing that. [1]: https://opendev.org/openstack/pbr/commit/47c5afe79aa334b3 [2]: https://salsa.debian.org/openstack-team/libs/python-pbr/-/merge_requests/4 [3]: https://lists.debian.org/debian-python/2023/10/msg00059.html -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1043075: Package builds fine
Hi Thomas! On Mon, Oct 30, 2023 at 04:35:22PM +0100, Thomas Goirand wrote: > I tried rebuilding, and it works. Closing this bug. This bug was not about python-openstackdocstheme itself failing to build, but about its reverse dependencies. As I mentioned in the bug description, during the test rebuild against new Sphinx, 104 packages failed to build with "dh_sphinxdoc: error: .../_static/underscore.js is missing" error [1]. This error is caused by outdated python3-openstackdocstheme. Please reopen this bug and upgrade to version 3.2.0, which will fix this. [1]: http://qa-logs.debian.net/2023/07/30/diff.txt -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1052759: qtremoteobjects-everywhere-src: FTBFS: qcontainerfwd.h:63:7: error: typedef redefinition with different types ('QList' vs 'QByteArrayList')
Control: retitle -1 qtremoteobjects-everywhere-src: FTBFS:
tst_usertypes::extraPropertyInQml2() fails
Control: severity -1 important
Control: tags -1 + unreproducible
Hi Lucas!
On Tue, Sep 26, 2023 at 02:38:35PM +0200, Lucas Nussbaum wrote:
> Source: qtremoteobjects-everywhere-src
> Version: 5.15.10-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230925 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
I have just built this package successfully two times in my sid chroot.
Also, it builds successfully in the reproducible builds environment [1].
[1]:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qtremoteobjects-everywhere-src.html
> Relevant part (hopefully):
> > make[6]: Entering directory '/<>/src/remoteobjects'
> > /usr/lib/qt5/bin/qtattributionsscanner /<> --filter
> > QDocModule=qtremoteobjects -o
> > /<>/src/remoteobjects/codeattributions.qdoc
> > /<>/src/remoteobjects/qdoc_wrapper.sh -outputdir
> > /<>/doc/qtremoteobjects -installdir /usr/share/qt5/doc
> > /<>/src/remoteobjects/doc/qtremoteobjects.qdocconf -prepare
> > -indexdir /usr/share/qt5/doc -no-link-errors -I. -I../../include
> > -I../../include/QtRemoteObjects -I../../include/QtRemoteObjects/5.15.10
> > -I../../include/QtRemoteObjects/5.15.10/QtRemoteObjects -I.
> > -I/usr/include/x86_64-linux-gnu/qt5
> > -I/usr/include/x86_64-linux-gnu/qt5/QtNetwork
> > -I/usr/include/x86_64-linux-gnu/qt5/QtCore/5.15.10
> > -I/usr/include/x86_64-linux-gnu/qt5/QtCore/5.15.10/QtCore
> > -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I.moc
> > -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -I/usr/include/c++/13
> > -I/usr/include/x86_64-linux-gnu/c++/13 -I/usr/include/c++/13/backward
> > -I/usr/lib/gcc/x86_64-linux-gnu/13/include -I/usr/local/include
> > -I/usr/include/x86_64-linux-gnu -I/usr/include
> > qt.qdoc: Start qdoc for QtRemoteObjects in dual process mode: prepare phase.
> > /usr/include/x86_64-linux-gnu/qt5/QtCore/qcontainerfwd.h:63:7: error:
> > typedef redefinition with different types ('QList' vs
> > 'QByteArrayList')
No, this is an error when generating documentation, but it does not make the
build fail.
The really relevant part is this one:
> > * Start testing of tst_usertypes *
> > Config: Using QtTest library 5.15.10, Qt 5.15.10 (x86_64-little_endian-lp64
> > shared (dynamic) release build; by GCC 13.1.0), debian unknown
> > PASS : tst_usertypes::initTestCase()
> > PASS : tst_usertypes::extraPropertyInQml()
> > QSYSTEM: tst_usertypes::extraPropertyInQml2() qt.remoteobjects: Listen
> > failed for URL: QUrl("local:test2")
> > QSYSTEM: tst_usertypes::extraPropertyInQml2() qt.remoteobjects:
> > QAbstractSocket::AddressInUseError
> > FAIL! : tst_usertypes::extraPropertyInQml2() Compared values are not the
> > same
> >Actual ((obj->property("hour").value())): 6
> >Expected (10) : 10
> >Loc: [tst_usertypes.cpp(106)]
Maybe this test is flaky, but as I said, it works for me.
Can you reproduce this error? Maybe there is some difference between our
setups that makes it fail?
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1051171: bookworm-pu: package qtlocation-opensource-src/5.15.8+dfsg-3+deb12u1
Hi Adam! On Sat, Sep 23, 2023 at 08:28:32PM +0100, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2023-09-03 at 22:29 +0300, Dmitry Shachnev wrote: > > This fixes bug which made applications using Qt Location freeze when > > trying to > > load the map tiles. > > > > Please go ahead. Thank you! Uploaded. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1043075: python3-openstackdocstheme: Incompatible with Sphinx 7
Hi, On Sat, Aug 05, 2023 at 09:48:50PM +0300, Dmitry Shachnev wrote: > Package: python3-openstackdocstheme > Version: 1.20.0-5 > Severity: important > Tags: upstream > > Dear Maintainer, > > When doing a rebuild of all reverse-dependencies against Sphinx 7.1 (which is > currently available in experimental), we noticed that 104 packages FTBFS with > "dh_sphinxdoc: error: .../_static/underscore.js is missing" error [1]. > > All of these packages build-depend on python3-openstackdocstheme (except for > masakari, which build-depends implicitly via python3-os-api-ref). > > The problem is that openstackdocstheme lists Sphinx' own JS files explicitly, > which may change from release to release. To fix this, please: > > 1. Upgrade to the latest upstream release (at least >= 2.3.0), that inherits >from basic/layout.html instead of doing an own HTML template from scratch. > > 2. Cherry-pick the change [2] that I have just submitted upstream, to stop >listing Sphinx JS files explicitly. There is a new release, 3.2.0, which includes my changes and another upstream change for Sphinx 7.2. Please upgrade to that release, it is the biggest remaining blocker for having Sphinx 7.x in unstable. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1051883: marked as pending in qttools-opensource-src
Hi Sebastian! On Sun, Sep 17, 2023 at 08:14:44PM +0200, Sebastian Ramacher wrote: > Control: reopen -1 > > On 2023-09-17 14:13:08 +0000, Dmitry Shachnev wrote: > > Control: tag -1 pending > > > > Hello, > > > > Bug #1051883 in qttools-opensource-src reported by you has been fixed in the > > Git repository and is awaiting an upload. You can see the commit > > message below and you can check the diff of the fix at: > > > > https://salsa.debian.org/qt-kde-team/qt/qttools/-/commit/c29ff951dc40dd804542a6dbbb9a32854e3087d8 > > > > > > Build with LLVM 15 for now. > > > > Closes: #1051883. > > The build fails with llvm-toolchain-15 in the same way. Looks like llvm > is not the cause of the FTBFS. No, it fails not in the same way. With llvm-toolchain-16 the failed tests were qdoc tests: tst_generatedOutput::webXmlFromCpp() and tst_generatedOutput::preparePhase(), which are directly related to LLVM (qdoc uses it to parse C++ code). I spent some time searching for an upstream fix, but with no luck (upstream does not support 5.15 branch officially anymore, and with 6.4.2 I get different failures in this test). Now, these two tests passed, but tst_QHelpEngineCore::setCollectionFile() failed, which is something new (it did not fail in my local build). I will investigate. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1051630: transition: qtwebengine-abi-5-15-15
On Sat, Sep 16, 2023 at 09:52:22AM +0200, Sebastian Ramacher wrote: > qtwebengine-opensource-src and binNMUs of the reverse dependencies > migrated. Closing. Thank you, Sebastian! -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1051630: transition: qtwebengine-abi-5-15-15
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: qtwebengine-opensource-...@packages.debian.org Control: affects -1 + src:qtwebengine-opensource-src Dear Release team, Qt WebEngine has a new patch release in 5.15 LTS branch, and as usual we change the ABI virtual package name, which requires a binNMU of two reverse dependencies: angelfish and qtwebview-opensource-src. The new version is prepared in experimental and built successfully. We no longer have mipsel architecture, so the problems from the previous transition should not repeat. Ben file: title = "qtwebengine-opensource-src"; is_affected = .depends ~ "qtwebengine-abi-5-15-14" | .depends ~ "qtwebengine-abi-5-15-15"; is_good = .depends ~ "qtwebengine-abi-5-15-15"; is_bad = .depends ~ "qtwebengine-abi-5-15-14"; -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1051171: bookworm-pu: package qtlocation-opensource-src/5.15.8+dfsg-3+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: qtlocation-opensource-...@packages.debian.org
Control: affects -1 + src:qtlocation-opensource-src
[ Reason ]
This fixes bug which made applications using Qt Location freeze when trying to
load the map tiles.
[ Impact ]
Some applications will be broken. I don't have a list of such applications,
but it can be reproduced with examples shipped in qtlocation5-examples.
[ Tests ]
It can be reproduced with minimal_map example from qtlocation5-examples
(e.g. /usr/lib/x86_64-linux-gnu/qt5/examples/location/minimal_map/minimal_map
on amd64). Without the fix only one tile loads and the application does not
respond to any events (e.g. dragging or scrolling). With the fix everything
works as expected.
[ Risks ]
The change is trivial (patch adding one character). It is applied both by
Qt upstream [1] and by KDE's Qt patch collection [2].
[1]: https://code.qt.io/cgit/qt/qtlocation.git/commit/?id=6cb20a08b65c73b4
[2]: https://invent.kde.org/qt/qt/qtlocation/-/commit/1c6a9479c9f5bf61
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
* Backport upstream patch to fix condition for appendChildNode() call
(closes: #1050240).
[ Other info ]
In unstable/testing, this bug was fixed in version 5.15.10+dfsg-3.
The debdiff against stable is attached.
--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qtlocation-opensource-src (5.15.8+dfsg-3+deb12u1) bookworm; urgency=medium
+
+ * Backport upstream patch to fix condition for appendChildNode() call
+(closes: #1050240).
+
+ -- Dmitry Shachnev Sun, 03 Sep 2023 21:57:28 +0300
+
qtlocation-opensource-src (5.15.8+dfsg-3) unstable; urgency=medium
* Let the system build the serial plugin by adding libqt5serialport5-dev as
--- /dev/null
+++ b/debian/patches/fix_appendChildNode_call.diff
@@ -0,0 +1,22 @@
+Description: fix appendChildNode() call
+ The QSGNode::appendChildNode() method checks that its parameter must
+ not have a parent. Before this patch we always called appendChildNode()
+ on a node that already had parent, which was always leading to ASSERT
+ in a debug build.
+ .
+ Seems that the right approach would be to call this method, if the
+ node *does not* have a parent.
+Origin: upstream, https://code.qt.io/cgit/qt/qtlocation.git/commit/?id=6cb20a08b65c73b4
+Last-Update: 2023-08-18
+
+--- a/src/location/labs/qsg/qgeomapobjectqsgsupport.cpp
b/src/location/labs/qsg/qgeomapobjectqsgsupport.cpp
+@@ -158,7 +158,7 @@ void QGeoMapObjectQSGSupport::updateMapO
+ if (!root)
+ return;
+
+-if (m_mapObjectsRootNode && m_mapObjectsRootNode->parent())
++if (m_mapObjectsRootNode && !m_mapObjectsRootNode->parent())
+ root->appendChildNode(m_mapObjectsRootNode.get());
+
+ if (!m_mapObjectsRootNode) {
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ use_system_dependencies.diff
hurd_geoclue.diff
mapboxgl_thread_portability.diff
opengl.diff
+fix_appendChildNode_call.diff
signature.asc
Description: PGP signature
Bug#1049364: transition: gnome-panel
Hi Graham! On Thu, Aug 24, 2023 at 06:01:27PM +, Graham Inggs wrote: > Control: tags -1 confirmed > > Hi Dmitry > > On Mon, 14 Aug 2023 at 18:27, Dmitry Shachnev wrote: > > gnome-panel has a new release, which bumped SONAME of the shared library. > > I packaged it in experimental and verified that all reverse > > build-dependencies > > (gnome-applets, gnome-flashback, sensors-applet, workrave) build fine with > > it. > > Please go ahead. Thank you. gnome-panel uploaded. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1049364: transition: gnome-panel
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: affects -1 + src:gnome-panel Dear Release team, gnome-panel has a new release, which bumped SONAME of the shared library. I packaged it in experimental and verified that all reverse build-dependencies (gnome-applets, gnome-flashback, sensors-applet, workrave) build fine with it. Ben file: title = "gnome-panel"; is_affected = .depends ~ "libgnome-panel0" | .depends ~ "libgnome-panel3"; is_good = .depends ~ "libgnome-panel3"; is_bad = .depends ~ "libgnome-panel0"; -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1043075: python3-openstackdocstheme: Incompatible with Sphinx 7
Package: python3-openstackdocstheme Version: 1.20.0-5 Severity: important Tags: upstream Dear Maintainer, When doing a rebuild of all reverse-dependencies against Sphinx 7.1 (which is currently available in experimental), we noticed that 104 packages FTBFS with "dh_sphinxdoc: error: .../_static/underscore.js is missing" error [1]. All of these packages build-depend on python3-openstackdocstheme (except for masakari, which build-depends implicitly via python3-os-api-ref). The problem is that openstackdocstheme lists Sphinx' own JS files explicitly, which may change from release to release. To fix this, please: 1. Upgrade to the latest upstream release (at least >= 2.3.0), that inherits from basic/layout.html instead of doing an own HTML template from scratch. 2. Cherry-pick the change [2] that I have just submitted upstream, to stop listing Sphinx JS files explicitly. Please let me know if you need my help with this. Another note: if you symlink jquery-3.2.1.js and jquery-3.2.1.min.js to the respective files in libjs-jquery package, dh_sphinxdoc should do the same in all reverse dependencies and generate a dependency on libjs-jquery. [1]: http://qa-logs.debian.net/2023/07/30/diff.txt [2]: https://review.opendev.org/c/openstack/openstackdocstheme/+/890587 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1041809: groff-base: man pages cause troff warning "cannot select font 'C'"
Control: forwarded -1 https://sourceforge.net/p/docutils/patches/205/
Hi all!
On Wed, Jul 26, 2023 at 05:08:44AM -0500, G. Branden Robinson wrote:
> # ``B`` bold, ``I`` italic, ``R`` roman should be available.
>
> Yes!
>
> # Hopefully ``C`` courier too.
>
> Yeah, no, that's never been true of groff (nor of mandoc(1)).
For some reason, with HTML output device the only way to produce a monospace
block ( or ) that I found is with ".ft C". The other options I tried
(".ft CR" and ".EX"/".EE") produce a paragraph with regular font ():
$ cat foo.1
.TH FOO 1
.SH DESCRIPTION
.ft C
A paragraph in C font.
.ft P
.ft CR
A paragraph in CR font.
.ft P
.EX
An example.
.EE
$ groff -man -Thtml < foo.1
[...]
A paragraph
in C font.
A paragraph in
CR font.
An example.
[...]
(Similar result with "man -Thtml -l foo.1".)
But I think rst2man users don't care about HTML output. If someone wanted
HTML, they would probably use rst2html.
> I have the following patch, which was super-straightforward:
>
> $ diff -u /usr/lib/python3/dist-packages/docutils/writers/manpage.py
> ATTIC/manpage.py
> --- /usr/lib/python3/dist-packages/docutils/writers/manpage.py 2019-12-30
> 10:32:00.0 -0600
> +++ ATTIC/manpage.py2023-07-26 04:41:54.933370003 -0500
> @@ -218,7 +218,7 @@
> 'definition_list_item': ('.TP', ''),
> 'field_name': ('.TP\n.B ', '\n'),
> 'literal': ('\\fB', '\\fP'),
> -'literal_block': ('.sp\n.nf\n.ft C\n', '\n.ft P\n.fi\n'),
> +'literal_block': ('.EX\n', '\n.EE\n'),
>
> 'option_list_item': ('.TP\n', ''),
>
> I'm not certain of it because I haven't yet figured out how to test it.
> (I have painful memories of "PYTHONPATH" and "virtualenv".)
I think we still need .sp, without that there is no blank line before the
example.
I have forwarded an updated patch upstream, see the Forwarded link. When it's
accepted by upstream developers, I will do a new upload.
> I see other things I'd like to improve in this man page writer (there
> are multiple mistaken claims in the comments, and some injected markup
> that _seems_ unnecessary), but one issue at a time...
That would be welcome. Please make contributions directly to upstream, they
have:
Bugs: https://sourceforge.net/p/docutils/bugs/
Patches: https://sourceforge.net/p/docutils/patches/
Mailing list: https://sourceforge.net/p/docutils/patches/
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1041104: qt6-base: CVE-2023-38197
¡Hola Lisandro! On Mon, Jul 17, 2023 at 03:49:13PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > El viernes, 14 de julio de 2023 18:38:45 -03 Moritz Mühlenhoff escribió: > > Source: qt6-base > > X-Debbugs-CC: t...@security.debian.org > > Severity: important > > Tags: security > > > > Hi, > > > > The following vulnerability was published for qt6-base. > > > > CVE-2023-38197[0]: > > I have just tried to backport the cherry-pick of 6.5 to 6.4 but without > success. It requires more time and C++ knowledge I have right now I'm afraid > :-/ c216c3d9859a20b3aeec985512e89316423fc3a8 cherry-picks to 6.4 with only one conflict, in tst_qxmlstream.cpp. We don't run tests anyway so you could just ignore it. Anyway, I rebased it and attaching a patch against 6.4 branch. -- Dmitry Shachnev From 60404b84c10e9cefad6ed31402a6d9f7fe5983e0 Mon Sep 17 00:00:00 2001 From: Axel Spoerl Date: Fri, 30 Jun 2023 12:43:59 +0200 Subject: [PATCH] QXmlStreamReader: Raise error on unexpected tokens QXmlStreamReader accepted multiple DOCTYPE elements, containing DTD fragments in the XML prolog, and in the XML body. Well-formed but invalid XML files - with multiple DTD fragments in prolog and body, combined with recursive entity expansions - have caused infinite loops in QXmlStreamReader. This patch implements a token check in QXmlStreamReader. A stream is allowed to start with an XML prolog. StartDocument and DOCTYPE elements are only allowed in this prolog, which may also contain ProcessingInstruction and Comment elements. As soon as anything else is seen, the prolog ends. After that, the prolog-specific elements are treated as unexpected. Furthermore, the prolog can contain at most one DOCTYPE element. Update the documentation to reflect the new behavior. Add an autotest that checks the new error cases are correctly detected, and no error is raised for legitimate input. The original OSS-Fuzz files (see bug reports) are not included in this patch for file size reasons. They have been tested manually. Each of them has more than one DOCTYPE element, causing infinite loops in recursive entity expansions. The newly implemented functionality detects those invalid DTD fragments. By raising an error, it aborts stream reading before an infinite loop occurs. Thanks to OSS-Fuzz for finding this. Fixes: QTBUG-92113 Fixes: QTBUG-95188 Change-Id: I0a082b9188b2eee50b396c4d5b1c9e1fd237bbdd Reviewed-by: Volker Hilsheimer (cherry picked from commit c4301be7d5f94852e1b17f2c2989d5ca807855d4) (cherry picked from commit c216c3d9859a20b3aeec985512e89316423fc3a8) --- src/corelib/serialization/qxmlstream.cpp | 145 +- src/corelib/serialization/qxmlstream_p.h | 11 ++ .../qxmlstream/tokenError/dtdInBody.xml | 20 +++ .../qxmlstream/tokenError/multipleDtd.xml | 20 +++ .../qxmlstream/tokenError/wellFormed.xml | 15 ++ .../qxmlstream/tst_qxmlstream.cpp | 39 + 6 files changed, 242 insertions(+), 8 deletions(-) create mode 100644 tests/auto/corelib/serialization/qxmlstream/tokenError/dtdInBody.xml create mode 100644 tests/auto/corelib/serialization/qxmlstream/tokenError/multipleDtd.xml create mode 100644 tests/auto/corelib/serialization/qxmlstream/tokenError/wellFormed.xml diff --git a/src/corelib/serialization/qxmlstream.cpp b/src/corelib/serialization/qxmlstream.cpp index 70e65df995..dbf95a8067 100644 --- a/src/corelib/serialization/qxmlstream.cpp +++ b/src/corelib/serialization/qxmlstream.cpp @@ -126,7 +126,7 @@ void reversed(const Range &&) = delete; addData() or by waiting for it to arrive on the device(). \value UnexpectedElementError The parser encountered an element -that was different to those it expected. +or token that was different to those it expected. */ @@ -263,13 +263,34 @@ QXmlStreamEntityResolver *QXmlStreamReader::entityResolver() const QXmlStreamReader is a well-formed XML 1.0 parser that does \e not include external parsed entities. As long as no error occurs, the - application code can thus be assured that the data provided by the - stream reader satisfies the W3C's criteria for well-formed XML. For - example, you can be certain that all tags are indeed nested and - closed properly, that references to internal entities have been - replaced with the correct replacement text, and that attributes have - been normalized or added according to the internal subset of the - DTD. + application code can thus be assured, that + \list + \li the data provided by the stream reader satisfies the W3C's + criteria for well-formed XML, + \li tokens are provided in a valid order. + \endlist + + Unless QXmlStreamReader raises an error, it guarantees the following: + \list + \li All tags are nested and closed properly. + \li References to internal entities have been replaced with the + correct replacement text. + \li Attributes have bee
Bug#1041250: Insufficient RAM?
Hi Soren! On Mon, Jul 17, 2023 at 08:40:14AM -0700, Soren Stoutner wrote: > Am I reading that error message correctly that it is failing to build from > source simply because the build machine doesn’t have enough RAM? No, we are limited not by physical RAM, but by address space which is just 2 GB on mipsel. See https://wiki.debian.org/MIPSPort#Generic_issues. However, as the latest version built fine on a porter box, I retried the last build on buildd. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1038402: openorienteering-mapper: FTBFS with Qt ≥ 5.15.9: QPainterTest failures
Control: tags -1 +pending
Hi,
On Sat, Jun 17, 2023 at 09:24:07PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
>
> openorienteering-mapper fails to build with Qt ≥ 5.15.9, which is currently
> available in experimental (but I am going to upload it to unstable soon).
>
> [...]
>
> I have created an upstream pull request that fixes this issue, see the
> Forwarded URL.
As Qt 5.15.10 is in unstable now and this package needs to be rebuilt against
the new private ABI, I have uploaded NMU to DELAYED/2.
The debdiff is attached. Also created a merge request on salsa:
https://salsa.debian.org/debian/openorienteering-mapper/-/merge_requests/2
--
Dmitry Shachnev
diff -Nru openorienteering-mapper-0.9.5/debian/changelog openorienteering-mapper-0.9.5/debian/changelog
--- openorienteering-mapper-0.9.5/debian/changelog 2021-12-28 12:45:41.0 +0300
+++ openorienteering-mapper-0.9.5/debian/changelog 2023-07-09 23:48:02.0 +0300
@@ -1,3 +1,11 @@
+openorienteering-mapper (0.9.5-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add a patch to make the QPainterTest pass with Qt 5.15.9
+(closes: #1038402).
+
+ -- Dmitry Shachnev Sun, 09 Jul 2023 23:48:02 +0300
+
openorienteering-mapper (0.9.5-3) unstable; urgency=medium
* Cherry-pick upstream commit updating expected
diff -Nru openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch
--- openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch 1970-01-01 03:00:00.0 +0300
+++ openorienteering-mapper-0.9.5/debian/patches/qt-5.15.9.patch 2023-07-09 23:48:02.0 +0300
@@ -0,0 +1,60 @@
+Description: make QPainterTest pass with Qt 5.15.9
+ https://bugreports.qt.io/browse/QTBUG-100327 was fixed in 5.15.9,
+ so now we have a good result from the beginning and don't need
+ ImageTransparencyFixup.
+Author: Dmitry Shachnev
+Forwarded: https://github.com/OpenOrienteering/mapper/pull/2156
+Last-Update: 2023-07-09
+
+--- a/src/core/image_transparency_fixup.h
b/src/core/image_transparency_fixup.h
+@@ -57,6 +57,9 @@ public:
+ *
+ * The image must be of QImage::Format_ARGB32_Premultiplied.
+ * It may be null.
++ *
++ * This fixup is needed for Qt5 < 5.15.9 and Qt6 < 6.2.4 which are
++ * affected by https://bugreports.qt.io/browse/QTBUG-100327.
+ */
+ inline ImageTransparencyFixup(QImage* image)
+ : dest(0), dest_end(0)
+@@ -81,11 +84,13 @@ public:
+ */
+ inline void operator()() const
+ {
++#if QT_VERSION < QT_VERSION_CHECK(5, 15, 9) || (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) && QT_VERSION < QT_VERSION_CHECK(6, 2, 4))
+ for (QRgb* px = dest; px < dest_end; px++)
+ {
+ if (*px == 0x0100) /* qRgba(0, 0, 0, 1) */
+ *px = 0x; /* qRgba(0, 0, 0, 0) */
+ }
++#endif
+ }
+
+ protected:
+--- a/test/qpainter_t.cpp
b/test/qpainter_t.cpp
+@@ -80,9 +80,10 @@ void QPainterTest::multiplyComposition()
+ QCOMPARE(compose(white_img, white_img, multiply).pixel(0,0), qRgba(255, 255, 255, 255));
+ QCOMPARE(compose(black_img, black_img, multiply).pixel(0,0), qRgba(0, 0, 0, 255));
+
++#if QT_VERSION < QT_VERSION_CHECK(5, 15, 9) || (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) && QT_VERSION < QT_VERSION_CHECK(6, 2, 4))
+ QEXPECT_FAIL("", "CompositionMode_Multiply incorrectly composes full transparency.", Continue);
++#endif
+ QCOMPARE(compose(trans_img, trans_img, multiply).pixel(0,0), qRgba(0, 0, 0, 0));
+- QCOMPARE(compose(trans_img, trans_img, multiply).pixel(0,0), qRgba(0, 0, 0, 1)); // This should fail!
+
+ // ImageTransparencyFixup fixes the particular issue.
+ QImage result = compose(trans_img, trans_img, multiply);
+@@ -107,9 +108,10 @@ void QPainterTest::darkenComposition()
+ QCOMPARE(compose(white_img, white_img, darken).pixel(0,0), qRgba(255, 255, 255, 255));
+ QCOMPARE(compose(black_img, black_img, darken).pixel(0,0), qRgba(0, 0, 0, 255));
+
++#if QT_VERSION < QT_VERSION_CHECK(5, 15, 9) || (QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) && QT_VERSION < QT_VERSION_CHECK(6, 2, 4))
+ QEXPECT_FAIL("", "CompositionMode_Darken incorrectly composes full transparency.", Continue);
++#endif
+ QCOMPARE(compose(trans_img, trans_img, darken).pixel(0,0), qRgba(0, 0, 0, 0));
+- QCOMPARE(compose(trans_img, trans_img, darken).pixel(0,0), qRgba(0, 0, 0, 1)); // This should fail!
+
+ // ImageTransparencyFixup fixes the particular issue.
+ QImage result = compose(trans_img, trans_img, darken);
diff -Nru openorienteering-mapper-0.9.5/debian/patches/series openorienteering-mapper-0.9.5/debian/patches/series
--- openorienteering-mapper-0.9.5/debian/patches/series 2021-12-28 12:06:01.0 +0300
+++ openorienteering-mapper-0.9.5/debian/patches/series 2023-07-09 23:48:02.0 +0300
@@ -1,3 +1,4 @@
fix-help-data-dir.patch
proj8.patch
proj8.2.0.patch
+qt-5.15.9.patch
signature.asc
Description: PGP signature
Bug#1039030: transition: qtbase-abi-5-15-10
Hi Sebastian! On Fri, Jul 07, 2023 at 10:29:41PM +0200, Sebastian Ramacher wrote: > Control: tags -1 confirmed > > Please go ahead. Qt is uploaded. Unfortunately, qtwebengine FTBFS on mipsel again. We are working on it together with Adrian Bunk (huge thanks to him for that). Other Qt packages seem to have built fine everywhere. Probably you can start doing some binNMUs. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1039030: transition: qtbase-abi-5-15-10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 1038402 1038737 Control: affects -1 + src:qtbase-opensource-src Dear Release team, We skipped Qt 5.15.9 release because of the freeze, so now I would like to upgrade from 5.15.8 to 5.15.10 — a version which was published on June 6th. Qt 5.15.10 is prepared in experimental. Also, there is a new Qt WebEngine release — 5.15.14. I have prepared a merge request with the ben file here: https://salsa.debian.org/release-team/transition-data/-/merge_requests/40 There are two known blockers, but I can NMU them if the maintainers don't act until the transition start. Also it makes sense to wait until the re2 transition migrates, because qtwebengine is involved there. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1038737: FTBFS on mips64el: Unable to import PyChromecast
Hi Adrian! On Wed, Jun 21, 2023 at 12:25:53PM +0300, Adrian Bunk wrote: > python3-pychromecast is also an unconditional runtime dependency, > so building on an architecture without it would anyway be pointless > (and for release architectures break testing migration). > > Trying on the porterbox for mips64el, I think the original problem was > just a timeout in the cmake "import pychromecast" test, the patch below > works for me. Indeed, your patch is the proper fix. Thank you! -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1038703: dtkcore: FTBFS: /usr/include/gtest/internal/gtest-port.h:270:2: error: #error C++ versions less than C++14 are not supported
Control: tags -1 + patch
On Tue, Jun 20, 2023 at 12:52:53PM +0300, Dmitry Shachnev wrote:
> [...]
>
> googletest 1.13 was uploaded to unstable recently, and it dropped support
> for C++ versions less than C++14:
>
> https://github.com/google/googletest/releases/tag/v1.13.0
>
> But dtkcore sets CONFIG += c++11 in its .pro files.
Attaching a patch that fixes the build failure.
--
Dmitry Shachnev
Description: don't force old C++ version for tests
Author: Dmitry Shachnev
Forwarded: no
Last-Update: 2023-06-20
--- a/tests/ddesktopentry/ddesktopentry.pro
+++ b/tests/ddesktopentry/ddesktopentry.pro
@@ -3,7 +3,6 @@ QT -= gui
TARGET = tst_ddesktopentrytest
TEMPLATE = app
-CONFIG += c++11
CONFIG -= app_bundle
!isEmpty(DTK_STATIC_LIB){
--- a/tests/dthreadutils/dthreadutils.pro
+++ b/tests/dthreadutils/dthreadutils.pro
@@ -2,7 +2,6 @@ QT += testlib concurrent
QT -= gui
TEMPLATE = app
-CONFIG += c++11
!isEmpty(DTK_STATIC_LIB){
DEFINES += DTK_STATIC_LIB
--- a/tests/dutils/dutils.pro
+++ b/tests/dutils/dutils.pro
@@ -2,7 +2,6 @@ QT += testlib dbus
QT -= gui
TEMPLATE = app
-CONFIG += c++11
!isEmpty(DTK_STATIC_LIB){
DEFINES += DTK_STATIC_LIB
--- a/tests/dvtablehook/dvtablehook.pro
+++ b/tests/dvtablehook/dvtablehook.pro
@@ -2,7 +2,6 @@ QT += testlib
QT -= gui
TEMPLATE = app
-CONFIG += c++11
# TODO: vtabhook release test failed
QMAKE_CXXFLAGS_RELEASE -= -O2
--- a/tests/tests.pro
+++ b/tests/tests.pro
@@ -1,6 +1,6 @@
TEMPLATE = app
QT += core dbus xml testlib concurrent
-CONFIG += thread c++11 link_pkgconfig
+CONFIG += thread link_pkgconfig
CONFIG -= app_bundle
QMAKE_LFLAGS += -Wl,--export-dynamic
signature.asc
Description: PGP signature
Bug#1038737: FTBFS on mips64el: Unable to import PyChromecast
Source: photoqt Version: 3.3+ds-1 Severity: serious Tags: ftbfs patch Justification: fails to build from source (but built successfully in the past) Dear Maintainer, The latest photoqt upload failed to build on mips64el, m68k and riscv64. mips64el is a release architecture, this I set severity to serious. The error is: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'pychromecast' CMake Error at CMakeLists.txt:386 (message): ** Unable to import PyChromecast, make sure it is installed. Enabling the CHROMECAST_PIPINSTALL option allows CMake to try to install it locally using pip. -- Configuring incomplete, errors occurred! I have attached a patch which should fix this problem. At least it seems to do so on riscv64. Also, I think with my change you can drop disable-pychromecast patch which is currently commented out anyway. -- Dmitry Shachnev --- photoqt-3.3+ds/debian/rules +++ photoqt-3.3+ds/debian/rules @@ -13,10 +13,7 @@ ifeq ($(DEB_BUILD_ARCH_OS),kfreebsd) MAGICK = -DGRAPHICSMAGICK=OFF -DIMAGEMAGICK=OFF endif -ifeq ($(DEB_BUILD_ARCH_OS),ia64) -CHROMECAST = -DCHROMECAST=OFF -endif -ifeq ($(DEB_BUILD_ARCH_OS),x86_64) +ifneq (,$(filter $(DEB_BUILD_ARCH),ia64 kfreebsd-amd64 kfreebsd-i386 sparc64 sh4 riscv64 m68k hppa mips64el)) CHROMECAST = -DCHROMECAST=OFF endif ifeq ($(DEB_BUILD_ARCH_OS),hppa) signature.asc Description: PGP signature
Bug#1038693: qt6-declarative-dev: inappropriately included cmake file
On Tue, Jun 20, 2023 at 10:09:13AM +0200, Oswald Buddenhagen wrote: > Package: qt6-declarative-dev > Version: 6.4.2+dfsg-1 > Severity: normal > > trying to build qt creator, i got this error message: > > === > CMake Error at > /usr/lib/x86_64-linux-gnu/cmake/Qt6QmlCompilerPrivate/Qt6QmlLintQuickPluginTargets.cmake:96 > (message): > The imported target "Qt6::QmlLintQuickPlugin" references the file > > "/usr/lib/x86_64-linux-gnu/qt6/plugins/qmllint/libquicklintplugin.so" > > but this file does not exist. Possible reasons include: > > * The file was deleted, renamed, or moved to another location. > > * An install or uninstall procedure did not complete successfully. > > * The installation package was faulty and contained > > > "/usr/lib/x86_64-linux-gnu/cmake/Qt6QmlCompilerPrivate/Qt6QmlLintQuickPluginTargets.cmake" > > but not all the files it references. > === > > installing qt6-qmllint-plugins fixes the issue. > i suppose you might need to split off qt6-qmllint-plugins-dev. I don't think we need to ship the cmake files for plugins at all. In Qt 5 they were only creating issues, so I didn't ship them. Nothing links against plugins, and Qt can find them without the need for cmake files. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1038132: qtwebengine-opensource-src: FTBFS: ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'
On Mon, Jun 19, 2023 at 01:24:50PM -0700, Gerardo Esteban Malazdrewicz wrote: > Please apply ffmpeg-remove-x86-optimization.patch to qtwebengine-opensource- > src-5.15.14 Done: https://tracker.debian.org/news/1436528/accepted-qtwebengine-opensource-src-51514dfsg-3-source-into-experimental/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036793: unblock: qtbase-opensource-src/5.15.8+dfsg-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org
Control: affects -1 + src:qtbase-opensource-src
Please unblock package qtbase-opensource-src.
[ Reason ]
One more CVE was published for qtbase, CVE-2023-33285 [1].
[ Impact ]
QDnsLookup has a buffer over-read via a crafted reply from a DNS server.
[ Tests ]
No automated tests are run for this package. But QDnsLookup is covered by
tests which are run as part of upstream CI:
tests/auto/network/kernel/qdnslookup/tst_qdnslookup.cpp.
[ Risks ]
This change passed the upstream tests, so it should be safe.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
Also I added DEP-3 headers to the patches from previous upload and renamed
them in a consistent way. This will not affect the binary packages in any way.
The reported piuparts regression is in piuparts itself [2].
unblock qtbase-opensource-src/5.15.8+dfsg-11
[1]: https://security-tracker.debian.org/tracker/CVE-2023-33285
[2]: https://salsa.debian.org/debian/piuparts/-/merge_requests/42
--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.15.8+dfsg-11) unstable; urgency=medium
+
+ * Rename the patches for consistency and add DEP-3 headers.
+ * Add a patch to fix buffer overflow in QDnsLookup (CVE-2023-33285).
+
+ -- Dmitry Shachnev Thu, 25 May 2023 13:45:05 +0300
+
qtbase-opensource-src (5.15.8+dfsg-10) unstable; urgency=medium
* Add patches to fix CVE-2023-32762 and CVE-2023-32763.
--- a/debian/patches/CVE-2023-32762.patch
+++ b/debian/patches/CVE-2023-32762.diff
@@ -1,6 +1,7 @@
- src/network/access/qhsts.cpp |4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
+Description: hsts: match header names case insensitively
+ Header field names are always considered to be case-insensitive.
+Origin: upstream, https://download.qt.io/official_releases/qt/5.15/CVE-2023-32762-qtbase-5.15.diff
+Last-Update: 2023-05-22
--- a/src/network/access/qhsts.cpp
+++ b/src/network/access/qhsts.cpp
--- a/debian/patches/cve-2023-32763.diff
+++ b/debian/patches/CVE-2023-32763.diff
@@ -1,7 +1,7 @@
- src/gui/painting/qfixed_p.h |9 +
- src/gui/text/qtextlayout.cpp |9 ++---
- 2 files changed, 15 insertions(+), 3 deletions(-)
+Description: fix buffer overflow in Qt SVG
+ Adds qAddOverflow and qMulOverflow definitions to QFixed.
+Origin: upstream, https://download.qt.io/official_releases/qt/5.15/CVE-2023-32763-qtbase-5.15.diff
+Last-Update: 2023-05-22
--- a/src/gui/painting/qfixed_p.h
+++ b/src/gui/painting/qfixed_p.h
--- /dev/null
+++ b/debian/patches/CVE-2023-33285.diff
@@ -0,0 +1,77 @@
+Description: QDnsLookup/Unix: make sure we don't overflow the buffer
+ The DNS Records are variable length and encode their size in 16 bits
+ before the Record Data (RDATA). Ensure that both the RDATA and the
+ Record header fields before it fall inside the buffer we have.
+ .
+ Additionally reject any replies containing more than one query records.
+Origin: upstream, https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7dba2c87619d558a
+Last-Update: 2023-05-25
+
+--- a/src/network/kernel/qdnslookup_unix.cpp
b/src/network/kernel/qdnslookup_unix.cpp
+@@ -227,7 +227,6 @@ void QDnsLookupRunnable::query(const int
+ // responseLength in case of error, we still can extract the
+ // exact error code from the response.
+ HEADER *header = (HEADER*)response;
+-const int answerCount = ntohs(header->ancount);
+ switch (header->rcode) {
+ case NOERROR:
+ break;
+@@ -260,18 +259,31 @@ void QDnsLookupRunnable::query(const int
+ return;
+ }
+
+-// Skip the query host, type (2 bytes) and class (2 bytes).
+ char host[PACKETSZ], answer[PACKETSZ];
+ unsigned char *p = response + sizeof(HEADER);
+-int status = local_dn_expand(response, response + responseLength, p, host, sizeof(host));
+-if (status < 0) {
++int status;
++
++if (ntohs(header->qdcount) == 1) {
++// Skip the query host, type (2 bytes) and class (2 bytes).
++status = local_dn_expand(response, response + responseLength, p, host, sizeof(host));
++if (status < 0) {
++reply->error = QDnsLookup::InvalidReplyError;
++reply->errorString = tr("Could not expand domain name");
++return;
++}
++if ((p - response) + status + 4 >= responseLength)
++header->qdcount = 0x; // invalid reply below
++else
++p += status + 4;
++}
++if (ntohs(header->qdcount) > 1) {
+ reply->error = QDnsLookup::InvalidReplyError;
+-reply->errorString = tr("Could not expand domain name");
++reply->errorString = t
Bug#1036745: unblock: qtbase-opensource-src-gles/5.15.8+dfsg-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtbase-opensource-src-g...@packages.debian.org
Control: affects -1 + src:qtbase-opensource-src-gles
Please unblock package qtbase-opensource-src-gles.
[ Reason ]
* Fixes for two CVEs (CVE-2023-24607 and CVE-2023-32763).
* Updated image_deletion_order.diff to fix dangling or incorrect
device pointers during handler destruction.
* Fix for cross-building (#1029082).
* Minor update for debian/libqt5gui5-gles.symbols.
[ Impact ]
Of these fixes, CVE-2023-32763 is the most important. It is possible to
trigger a buffer overflow when rendering SVG files.
[ Tests ]
No automated tests are run for this package. But patches that come from
upstream are covered by upstream tests.
[ Risks ]
I think the risk is low. Most of these fixes are already present in the
non-gles variant of the package in testing (5.15.8+dfsg-10) and have been
tested by many users. Except for the cross-build fix which is specific to
the -gles variant, but that fix is only applied when cross-building and
does not affect regular builds.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
(Anything else the release team should know.)
unblock qtbase-opensource-src-gles/5.15.8+dfsg-3
--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,28 @@
+qtbase-opensource-src-gles (5.15.8+dfsg-3) unstable; urgency=medium
+
+ * Add a patch to fix CVE-2023-32763: buffer overflow in Qt SVG
+(closes: #1036702).
+
+ -- Dmitry Shachnev Wed, 24 May 2023 20:52:26 +0300
+
+qtbase-opensource-src-gles (5.15.8+dfsg-2) unstable; urgency=medium
+
+ * Merge qtbase-opensource-src 5.15.8+dfsg-3 upload.
+ * Compare only upstream version of qt5-qmake-bin when cross-building
+(closes: #1029082).
+
+ -- Dmitry Shachnev Sat, 04 Mar 2023 14:39:27 +0300
+
+qtbase-opensource-src (5.15.8+dfsg-3) unstable; urgency=medium
+
+ * Use ${DEB_HOST_GNU_TYPE} substitution in debian/qt5-qmake.install.
+ * Add upstream patch to fix denial-of-service in Qt SQL ODBC plugin
+(CVE-2023-24607, closes: #1031872).
+ * Update debian/libqt5gui5.symbols from s390x build log.
+ * Amend image_deletion_order.diff from one more upstream commit.
+
+ -- Dmitry Shachnev Mon, 27 Feb 2023 11:28:53 +0300
+
qtbase-opensource-src-gles (5.15.8+dfsg-1) unstable; urgency=medium
* Merge qtbase-opensource-src 5.15.8+dfsg-2 upload.
--- a/debian/libqt5gui5-gles.symbols
+++ b/debian/libqt5gui5-gles.symbols
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 5.15.4 amd64 hppa powerpc ppc64 s390x sparc64
+# SymbolsHelper-Confirmed: 5.15.8 s390x
libQt5Gui.so.5 libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER#
| libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER#, qtbase-abi-5-15-8
| libqt5gui5 #MINVER#
@@ -1563,7 +1563,7 @@ libQt5Gui.so.5 libqt5gui5 #MINVER# | libqt5gui5-gles #MINVER#
_ZN16QDoubleValidatorD0Ev@Qt_5 5.0.2
_ZN16QDoubleValidatorD1Ev@Qt_5 5.0.2
_ZN16QDoubleValidatorD2Ev@Qt_5 5.0.2
- (optional=inline|arch=!hppa !ia64 !s390x)_ZN16QOpenGLFunctions17glBindFramebufferEjj@Qt_5 5.15.2
+ (optional=inline|arch=!hppa !ia64)_ZN16QOpenGLFunctions17glBindFramebufferEjj@Qt_5 5.15.2
_ZN16QOpenGLFunctions25initializeOpenGLFunctionsEv@Qt_5 5.0.2
_ZN16QOpenGLFunctionsC1EP14QOpenGLContext@Qt_5 5.0.2
_ZN16QOpenGLFunctionsC1Ev@Qt_5 5.0.2
--- /dev/null
+++ b/debian/patches/CVE-2023-24607.diff
@@ -0,0 +1,330 @@
+Description: Fix denial-of-service in Qt SQL ODBC driver plugin
+Origin: upstream, https://download.qt.io/official_releases/qt/5.15/CVE-2023-24607-qtbase-5.15.diff
+Last-Update: 2023-02-26
+
+--- a/src/plugins/sqldrivers/odbc/qsql_odbc.cpp
b/src/plugins/sqldrivers/odbc/qsql_odbc.cpp
+@@ -92,23 +92,39 @@ inline static QString fromSQLTCHAR(const
+ return result;
+ }
+
++template
++void toSQLTCHARImpl(QVarLengthArray , const QString ); // primary template undefined
++
++template
++void do_append(QVarLengthArray , const Container )
++{
++result.append(reinterpret_cast(c.data()), c.size());
++}
++
++template <>
++void toSQLTCHARImpl<1>(QVarLengthArray , const QString )
++{
++const auto u8 = input.toUtf8();
++do_append(result, u8);
++}
++
++template <>
++void toSQLTCHARImpl<2>(QVarLengthArray , const QString )
++{
++do_append(result, input);
++}
++
++template <>
++void toSQLTCHARImpl<4>(QVarLengthArray , const QString )
++{
++const auto u32 = input.toUcs4();
++do_append(result, u32);
++}
++
+ inline static QVarLengthArray toSQLTCHAR(const QString )
+ {
+ QVarLengthArray result;
+-result.resize(input.size());
+-switch(sizeof(SQLTCHAR)) {
+-case 1:
+-memcpy(result.data(), input.toUtf8().data(), input.size());
+-break;
+-case 2:
+-memcpy(result.data(), input.unicode(), input.size() * 2);
+
Bug#1036702: qtbase-opensource-src-gles: CVE-2023-32762
Control: retitle -1 qtbase-opensource-src-gles: CVE-2023-32763 On Wed, May 24, 2023 at 04:00:31PM +0200, Moritz Mühlenhoff wrote: > Confused the CVE IDs, this is for CVE-2023-32763, which is the SVG issue. > CVE-2023-32762 being about HSTS should not affect -gles. Right. Retitling accordingly. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036562: unblock: qtbase-opensource-src/5.15.8+dfsg-10
On Mon, May 22, 2023 at 01:58:03PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org, mity...@debian.org, > lisan...@debian.org > Control: affects -1 + src:qtbase-opensource-src > > Please unblock package qtbase-opensource-src > > [ Reason ] > > This upload: > - Fixes CVE-2023-32762 and CVE-2023-32763. One prevents a crash with SVG > (not related to the one in qtsvg-opensource-src) and the other one > related to a security heade parsing in the network module. > - Adds a Break/Replaces in order to allow proper handling of systems > that still had libqtcore4 around (#1035790). > - Backports a patch in order to solve an issue with KWin: > - https://bugreports.qt.io/browse/QTBUG-98048 > - https://lists.debian.org/debian-kde/2022/11/msg00019.html Actually, the fix for #1035790 has already migrated to testing. So just the first and third points are remaining. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036553: unblock: qtsvg-opensource-src/5.15.8-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtsvg-opensource-...@packages.debian.org
Control: affects -1 + src:qtsvg-opensource-src
Please unblock package qtsvg-opensource-src.
[ Reason ]
This fixes a security bug. See:
- https://security-tracker.debian.org/tracker/CVE-2023-32573
- https://www.qt.io/blog/security-advisory-qt-svg
[ Impact ]
Use of uninitialized variable which is undefined behavior, e.g. may lead to
division by zero.
[ Tests ]
The upstream test suite is run during build.
[ Risks ]
The change is quite trivial, it just initializes the variable and uses a
constant
to keep the value in one place.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock qtsvg-opensource-src/5.15.8-3
--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qtsvg-opensource-src (5.15.8-3) unstable; urgency=medium
+
+ * Backport upstream commit to initialize QSvgFont::m_unitsPerEm
+(CVE-2023-32573).
+
+ -- Dmitry Shachnev Sun, 21 May 2023 19:06:01 +0300
+
qtsvg-opensource-src (5.15.8-2) unstable; urgency=medium
* Upload to unstable.
--- /dev/null
+++ b/debian/patches/CVE-2023-32573.diff
@@ -0,0 +1,34 @@
+Description: QSvgFont: initialize m_unitsPerEm to fix undefined behavior
+Origin: upstream, https://download.qt.io/official_releases/qt/5.15/CVE-2023-32573-qtsvg-5.15.diff
+Last-Update: 2023-05-21
+
+--- a/src/svg/qsvgfont_p.h
b/src/svg/qsvgfont_p.h
+@@ -74,6 +74,7 @@ public:
+ class Q_SVG_PRIVATE_EXPORT QSvgFont : public QSvgRefCounted
+ {
+ public:
++static constexpr qreal DEFAULT_UNITS_PER_EM = 1000;
+ QSvgFont(qreal horizAdvX);
+
+ void setFamilyName(const QString );
+@@ -86,7 +87,7 @@ public:
+ void draw(QPainter *p, const QPointF , const QString , qreal pixelSize, Qt::Alignment alignment) const;
+ public:
+ QString m_familyName;
+-qreal m_unitsPerEm;
++qreal m_unitsPerEm = DEFAULT_UNITS_PER_EM;
+ qreal m_ascent;
+ qreal m_descent;
+ qreal m_horizAdvX;
+--- a/src/svg/qsvghandler.cpp
b/src/svg/qsvghandler.cpp
+@@ -2666,7 +2666,7 @@ static bool parseFontFaceNode(QSvgStyleP
+
+ qreal unitsPerEm = toDouble(unitsPerEmStr);
+ if (!unitsPerEm)
+-unitsPerEm = 1000;
++unitsPerEm = QSvgFont::DEFAULT_UNITS_PER_EM;
+
+ if (!name.isEmpty())
+ font->setFamilyName(name);
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
reject_oversize_svgs.diff
+CVE-2023-32573.diff
signature.asc
Description: PGP signature
Bug#1017144: gammaray: FTBFS: test failed
Control: severity -1 important On Sun, Aug 14, 2022 at 09:13:36AM +0200, Lucas Nussbaum wrote: > Source: gammaray > Version: 2.11.3-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220813 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > Start 2: connectiontest-preload-filter > > > [...] > > Injector error: Process crashed I acknowledge that a few tests are flaky, but it does not mean that this package fails to build completely. Since this bug was filed on 2022-08-14, it built successfully on amd64 buildds on 2022-10-01, 2022-12-21, 2022-12-24, 2023-01-15 and 2023-03-02. Downgrading severity to important so it doesn't block bookworm release. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1036058: unblock: qtbase-opensource-src/5.15.8+dfsg-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org
Control: affects -1 + src:qtbase-opensource-src
Please unblock package qtbase-opensource-src.
[ Reason ]
The new upload fixes bug #1035790 (missing Breaks+Replaces: libqtcore4).
[ Impact ]
Some Buster → Bullseye → Bookworm upgrades will fail with dpkg error about
overwriting files.
[ Tests ]
No tests, but the change is trivial and just partially reverts an older
change (where these Breaks/Replaces were removed).
[ Risks ]
Just adding Breaks/Replaces against an ancient package which is not even
present in stable. No risk.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock qtbase-opensource-src/5.15.8+dfsg-8
--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+qtbase-opensource-src (5.15.8+dfsg-8) unstable; urgency=medium
+
+ * Add back Breaks/Replaces for libqtcore4 (closes: #1035790).
+
+ -- Dmitry Shachnev Sat, 13 May 2023 14:12:14 +0300
+
qtbase-opensource-src (5.15.8+dfsg-7) unstable; urgency=medium
* Update a11y_root.diff. This time the code waits for Qt loop to process the
--- a/debian/control
+++ b/debian/control
@@ -89,6 +89,8 @@ Provides: qtbase-abi-5-15-8
Depends: shared-mime-info, ${misc:Depends}, ${shlibs:Depends}
Recommends: qttranslations5-l10n
Suggests: libthai0
+Breaks: libqtcore4 (<< 4:4.8.7+dfsg-20~)
+Replaces: libqtcore4 (<< 4:4.8.7+dfsg-20~)
Description: Qt 5 core module
Qt is a cross-platform C++ application framework. Qt's primary feature
is its rich set of widgets that provide standard GUI functionality.
signature.asc
Description: PGP signature
