Bug#1072673: qttools-opensource-src: uses LLVM 15 which is being removed
Hi Emilio! On Thu, Jun 06, 2024 at 09:58:19AM +0200, Emilio Pozuelo Monfort wrote: > Source: qttools-opensource-src > Version: 5.15.8-2 > Severity: important > > Hi, > > qttools-opensource-src is building with LLVM 15, which is going to be > removed soon. Please switch to a newer version (such as 17), or ideally > use the default version, which may be more suitable/stable these days. Unfortunately, qttools fails to build with newer LLVM, some qdoc-related tests fail [1]. In particular, it misinterprets typedefs as structs, as can be seen in the build log [2]. Upstream Qt 6 had a series of patches to fix build with LLVM 16/17, see the linked Gerrit Reviews in this bug [3]. However, most of these patches fail to apply cleanly to 5.15 branch, and based on patch descriptions I could not identify the patch which would fix these particular test failures. So I either need a help from LLVM expert who would explain this test failure, or we can ignore these tests, or we can drop qdoc in 5.15. The last option would mean dropping documentation for all of Qt 5, and also fixing at least kuserfeedback and quickflux. It is hard to identify the complete set of affected packages, because some packages can depend on qdoc-qt5 indirectly via qttools5-dev-tools. Maybe the set of affected packages will become smaller once Qt6-based KDE stack lands in unstable. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051883 [2]: https://buildd.debian.org/status/fetch.php?pkg=qttools-opensource-src=amd64=5.15.10-3%2Bb1=1694632815=0 [3]: https://bugreports.qt.io/browse/QTBUG-111580 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1071193: libqt6core6t64/experimental breaks ABI
Hi all, On Fri, May 17, 2024 at 01:07:31AM +0300, Adrian Bunk wrote: > Apparently the symbols were moved to PRIVATE_API: > _ZN5QUtf816convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE@@Qt_6_PRIVATE_API > _ZN5QUtf816convertToUnicodeEPDs14QByteArrayView@@Qt_6_PRIVATE_API > _ZN6QUtf1616convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API > _ZN6QUtf3216convertToUnicodeE14QByteArrayViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API > _ZN5QUtf818convertFromUnicodeE11QStringView@@Qt_6_PRIVATE_API > _ZN5QUtf818convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE@@Qt_6_PRIVATE_API > _ZN6QUtf1618convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API > _ZN6QUtf3218convertFromUnicodeE11QStringViewPN20QStringConverterBase5StateE14DataEndianness@@Qt_6_PRIVATE_API I suspect this may be related to a change in Qt 6.5 where they replaced Perl code to look for private classes (findclasslist.pl) with C++ code in syncqt [1][2]. These QUtf8 / QUtf16 / QUtf32 structs were always defined in a private header (qstringconverter_p.h), so marking them as private is correct. Maybe findclasslist.pl only looked at classes marked as Q_*_EXPORT, while these structs are not marked as such (individual members are marked instead). [1]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=5a5ad8c0029ef9f9 [2]: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=7f4aa1a3fa461064 > This is an upstream(?) ABI break, but since libqt6core5compat6 seems > to be the only affected package something like > Breaks: libqt6core5compat6 (<< 6.6) > might be the best available option to avoid issues when upgrading > from bookworm. I agree. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1070564: libqt5quick5-gles: attempt to upgrade to version 5.15.10+dfsg-3 tries to remove other packages
Hi Cristian! On Mon, May 06, 2024 at 04:18:32PM +0200, Cristian Ionescu-Idbohrn wrote: > Package: libqt5quick5-gles > Version: 5.15.10+dfsg-2+b3 > Severity: important > > Hi, > > I see this message: > > The following packages have been kept back: > libqt5quick5-gles I see you have installed libqt5quick5-gles and the non-GLES variant of libqt5gui5t64. But your hardware does not really use OpenGL ES, right? There was a period during the 64-bit time_t transition when apt could replace libqt5quick5 with libqt5quick5-gles. On March 30th I tigthened dependencies of libqt5quick5-gles to prevent that [1], but probably you upgraded your system before then. If my guess is right and you do not really need the GLES variant, the right thing to do will be to install libqt5quick5, which will remove libqt5quick5-gles and let the other packages be upgraded. Please try that and let me know if it helps. [1]: https://tracker.debian.org/news/1515848/accepted-qtdeclarative-opensource-src-gles-51510dfsg-3-source-into-unstable/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
On Tue, May 07, 2024 at 05:58:55PM +, Thorsten Glaser wrote:
> Dmitry Shachnev dixit:
>
> >Will you be able to forward your patch upstream when you finalize it?
>
> Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
> respond well if they want me to test things with vanilla upstream
> (instead of the packaging), or if they have requests I as a C (but
> not C++) developer don’t understand.
I also usually test with our packaging, not with vanilla upstream.
But with Qt 6.6 from experimental there should not be much difference:
we don't have any patches for this part of code, and we are lagging only
a few versions behind upstream.
And your test example compiles without changes with Qt 6, you just need
to call qmake6 instead of qmake.
> >> +static inline int roundForBbox(qreal v)
> >> +{
> >> +return (v < 0) ? floor(v) : ceil(v);
> >> +}
> >
> >I see you are passing negated values to this function, e.g. roundForBbox(-x).
>
> Not only them. And roundForBbox is basically just the canonical
> “round away from zero / towards ±infinity for integer results”.
>
> The negation in the callers is to convert *some* Qt coordinates
> to PS/PDF coordinates, but only for the Y axis, as the X axis is
> the same for them.
Okay, makes sense.
> >I see why you moved properties to the top, but is moving postscriptName
> >needed? Maybe leave it where it was to minimize the diff?
>
> It’s not. I moved the whole block to make it easier to read,
> but good point.
Thank you.
> >You are passing scalep pointer here only to multiply it by this value?
>
> Yes.
>
> >It looks like fontEngine is a public member of QFontSubset, so you can
> >do it in the calling code.
>
> Yes, except it’s the callee that determines the scaling factor,
> not the caller. By passing it back like this, nothing would have
> to change in the caller should the callee ever decide to not scale.
Valid point. Let's see if Qt developers like this approach with passing a
pointer. If they don't, maybe the same thing can be achieved differently,
e.g. by returning QPair.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
On Sun, May 05, 2024 at 08:45:25PM +, Thorsten Glaser wrote:
> Dixi quod…
>
> >correct… but it only changes the metrics in the head table, not
> >in the OS/2 or hhea tables (as can be seen when loading the font
> >from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
> >is constructed from the values from the original font.
>
> And Atril uses the values from the hhea table (found by hexediting).
>
> #define TO_TTF(x) qRound(x * 2048. / ppem)
>
> This is used in things like…
>
> font.hhea.maxAdvanceWidth = TO_TTF(fontEngine->maxCharWidth());
>
> … but not in…
>
> font.hhea.ascender = qRound(properties.ascent);
> font.hhea.descender = -qRound(properties.descent);
> font.hhea.lineGap = qRound(properties.leading);
>
> … and of course not when the OS/2 table is copied:
>
> if (!noEmbed) {
> QTtfTable os2;
> os2.tag = MAKE_TAG('O', 'S', '/', '2');
> os2.data = fontEngine->getSfntTable(os2.tag);
> if (!os2.data.isEmpty())
> tables.append(os2);
> }
>
> (all examples from stretch’s Qt, as the oldest I had at hand)
Actually, this code dates back to “Initial import from the monolithic Qt”
commit from 2011. The only thing that changed is that MAKE_TAG macro was
replaced with QFont::Tag class.
I checked Qt 4 history [1] and there this code dates back to “Long live Qt!”
commit from 2009. So it’s unlikely that we can find the original developer
and ask why it is like that and whether we actually need the OS/2 table.
Now that you dug so deeply, maybe you can try to replace qRound in those
three lines that you mentioned with TO_TTF, and check if it fixes the bug
(and does not break anything else)?
[1]: https://github.com/qt/qt/blame/4.8/src/gui/text/qfontsubset.cpp
--
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#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#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#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#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#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#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#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
Re: 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
Re: 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
Re: 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
Re: 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
Re: 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#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#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#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
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
Re: 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#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#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#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
Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency
Hi all, again. On Tue, Apr 25, 2023 at 05:56:36PM +0200, Steve Langasek wrote: > Dear maintainers, > > As part of an investigation to establish the feasibility of moving 32-bit > archs to 64-bit time_t, I am running an analysis of all header files in the > archive to determine which libraries' ABIs are affected. This requires the > headers in question to be compilable. > > qtbase5-private-dev ships header files which have includes that are not > satisfied by its dependencies. For my purposes, I've worked around these > unusable headers by adding quirks to my scripts, but it seems worth > reporting as a bug that headers are being shipped that aren't usable. > > - qt5/QtCore/5.15.8/QtCore/private/qcborcommon_p.h, which #includes cbor.h, > found in libcbor-dev; but does not provide the CborValue type Actually, Qt uses tinycbor [1], not libcbor. tinycbor is not packaged in Debian, and Qt doesn't have an option to build with system tinycbor anyway, so we are using the bundled version. [1]: https://github.com/intel/tinycbor > - qt5/QtCore/5.15.8/QtCore/private/qcfsocketnotifier_p.h, which #includes > CoreFoundation/CoreFoundation.h, not found in any package in the archive. > - qt5/QtGui/5.15.8/QtGui/private/qcoregraphics_p.h: same > - qt5/QtCore/5.15.8/QtCore/private/qcore_mac_p.h, same > - > qt5/QtFontDatabaseSupport/5.15.8/QtFontDatabaseSupport/private/qcoretextfontdatabase_p.h, > depends on the preceding > - > qt5/QtFontDatabaseSupport/5.15.8/QtFontDatabaseSupport/private/qfontengine_coretext_p.h: > same > - qt5/QtTest/5.15.8/QtTest/private/qappletestlogger_p.h: same These headers are macOS-specific, but the Qt build system installs all headers unconditionally. > - qt5/QtCore/5.15.8/QtCore/private/qcollator_p.h, which #includes > unicode/ucol.h, found in libicu-dev > - qt5/QtCore/5.15.8/QtCore/private/qdoublescanprint_p.h, which #includes > double-conversion/double-conversion.h, found in libdouble-conversion-dev > [...] I have added these two and the other packages you mentioned to Suggests. Thank you for providing such a list. As earlier discussed, I don't want to depend on 16 packages that most of qtbase5-private-dev users won't actually need. -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency
Hi all! On Tue, Apr 25, 2023 at 05:21:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > To the best of my knowledge Qt installs lots of really not-required headers > in > it's private stuff. If you ask them it's for the sake of simplicity, as you > are > not supposed to use private headers... > > The reason we export those private headers is because we build Qt by > submodules instead of a big huuuge build including webengine et all, and Qt > submodules do have internal private dependencies. > > So yes, it is a valid bug, but I am afraid that it will be too hard to get > that right. Non the less I really appreciate you filing this bug report, it > is > a good thing to have it around. > > @Dmitry: I would mark this as wontfix, what do you think? Well, if adding just one small dependency will make Steve's script happy, then I don't mind doing it. But if we are talking about a dozen of extra dependencies, I would rather not do it. Or maybe they should be Recommends or Suggests. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root
Hi Frederik and Samuel, On Thu, Apr 06, 2023 at 06:20:04PM +0200, Samuel Thibault wrote: > Oh, I didn't notice that there was a recorded test failure. > > I don't see how the failure can be related to the change... > > Cc-ing Frederik, in case he remembers / realizes something. I just want to add some context. We are talking about this change: https://codereview.qt-project.org/c/qt/qtbase/+/205196 Frederik, perhaps you can rebase and see if the tests still fail? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root
Hi Samuel!
On Thu, Apr 06, 2023 at 01:57:25AM +0200, Samuel Thibault wrote:
> Hello,
>
> Currently, qt5 applications, when run in sudo, are not accessible to
> screen readers. This is because the accessibility layer does not manage
> to connect to the accessibility bus to export the application content:
>
> https://bugreports.qt.io/browse/QTBUG-43674
>
> [...]
>
> This is particularly important because the calamares installer is based
> on qt5 and runs as root, and it currently is completely inaccessible to
> blind users, and this fix makes it possible for blind users to use it.
>
> I have confirmed that this fixes the issue for bookworm, would it be
> possible to upload to unstable? I'll then handle requesting the unblock
> from the release team.
I understand the importance of this patch, but I don't like that this change
has not been merged upstream because of test failures, and did not have any
activity for the last 5 years.
But I looked at the KDE branch, and the last three commits they have there [1]
seem to be related to the same problem. At least, the comment talks about the
the same thing as your description:
// Only connect on next loop run, connections to our enabled signal are
// only established after the ctor returns.
But these changes depend on AT_SPI_BUS_ADDRESS environment variable. Can we
rely on it in Debian? If yes, can you please check if those commits fix the
issue with calamares? I have attached them as a single patch for convenience.
[1]:
https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15/src/platformsupport/linuxaccessibility/dbusconnection.cpp
--
Dmitry Shachnev
diff --git a/src/platformsupport/linuxaccessibility/dbusconnection.cpp b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
index 45ddc8e496..cc734abc63 100644
--- a/src/platformsupport/linuxaccessibility/dbusconnection.cpp
+++ b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
@@ -69,6 +69,21 @@ QT_BEGIN_NAMESPACE
DBusConnection::DBusConnection(QObject *parent)
: QObject(parent), m_a11yConnection(QString()), m_enabled(false)
{
+// If the bus is explicitly set via env var it overrides everything else.
+QByteArray addressEnv = qgetenv("AT_SPI_BUS_ADDRESS");
+if (!addressEnv.isEmpty()) {
+// Only connect on next loop run, connections to our enabled signal are
+// only established after the ctor returns.
+QMetaObject::invokeMethod(
+this,
+[this, addressEnv] {
+m_enabled = true;
+connectA11yBus(QString::fromLocal8Bit(addressEnv));
+},
+Qt::QueuedConnection);
+return;
+}
+
// Start monitoring if "org.a11y.Bus" is registered as DBus service.
QDBusConnection c = QDBusConnection::sessionBus();
if (!c.isConnected()) {
signature.asc
Description: PGP signature
Bug#1033873: unblock: qbs/1.24.1+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: q...@packages.debian.org
Control: affects -1 + src:qbs
Dear Release team,
[ Reason ]
Please unblock qbs to fix a FTBFS bug present in the current version in
testing (#1033430).
Build failure is caused by qt6-base 6.4.2+dfsg-4 upload after which qmake
and qdoc binaries are no longer in the same directory, which qbs assumed.
I fixed this by using a proper way to find qdoc binary (Qt6::qdoc target)
instead of relying on qmake. My fix was also accepted by upstream developers.
Also, the new version in sid includes upstream patch release 1.24.1 but it
contains just a couple of fixes:
$ git diff v1.24.0 v1.24.1 --stat
CMakeLists.txt | 4 +++-
VERSION | 2 +-
changelogs/changes-1.24.1.md | 9 +
share/qbs/modules/cpp/iar.js | 2 ++
4 files changed, 15 insertions(+), 2 deletions(-)
Finally, I marked some symbols as optional to fix FTBFS when building with
-O3 optimization level (as seen in Ubuntu ppc64el).
[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
qbs will be auto-removed on May 7th, and that will cause the removal of
reverse dependencies: asyncfuture, dewalls, plotsauce, qmath3d.
[ Tests ]
(What automated or manual tests cover the affected code?)
We run the upstream test suite during build.
[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
I don't see any risks. The new version is in unstable for almost a month and
nobody complained.
[ 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 qbs/1.24.1+dfsg-2
--
Dmitry Shachnev
diff -Nru qbs-1.24.0+dfsg/changelogs/changes-1.24.1.md qbs-1.24.1+dfsg/changelogs/changes-1.24.1.md
--- qbs-1.24.0+dfsg/changelogs/changes-1.24.1.md 1970-01-01 03:00:00.0 +0300
+++ qbs-1.24.1+dfsg/changelogs/changes-1.24.1.md 2023-02-22 16:42:11.0 +0300
@@ -0,0 +1,9 @@
+# C/C++ Support
+Fix macros and include paths retrieval for IAR
+
+# Build System
+Add fix for cmake >= 3.18
+
+# Contributors
+* Denis Shienkov
+* Eike Ziller
diff -Nru qbs-1.24.0+dfsg/CMakeLists.txt qbs-1.24.1+dfsg/CMakeLists.txt
--- qbs-1.24.0+dfsg/CMakeLists.txt 2022-11-24 12:32:18.0 +0300
+++ qbs-1.24.1+dfsg/CMakeLists.txt 2023-02-22 16:42:11.0 +0300
@@ -45,7 +45,9 @@
if (Qt6_FOUND)
find_package(Qt${QT_VERSION_MAJOR} COMPONENTS Core5Compat REQUIRED)
if(NOT TARGET Qt6Core5Compat)
-set_property(TARGET Qt6::Core5Compat PROPERTY IMPORTED_GLOBAL TRUE) # hack for CMake < 1.18
+if(CMAKE_VERSION VERSION_LESS 3.18)
+set_property(TARGET Qt6::Core5Compat PROPERTY IMPORTED_GLOBAL TRUE) # hack for CMake < 3.18
+endif()
add_library(Qt6Core5Compat ALIAS Qt6::Core5Compat)
endif()
else()
diff -Nru qbs-1.24.0+dfsg/debian/changelog qbs-1.24.1+dfsg/debian/changelog
--- qbs-1.24.0+dfsg/debian/changelog 2023-01-02 02:39:26.0 +0300
+++ qbs-1.24.1+dfsg/debian/changelog 2023-03-05 20:28:50.0 +0300
@@ -1,3 +1,18 @@
+qbs (1.24.1+dfsg-2) unstable; urgency=medium
+
+ * Add a patch to find qdoc directly, to fix arch:all build.
+ * Prevent dh_compress from compressing qbs.qch.
+
+ -- Dmitry Shachnev Sun, 05 Mar 2023 20:28:50 +0300
+
+qbs (1.24.1+dfsg-1) unstable; urgency=medium
+
+ * New upstream bugfix release.
+ * Mark some symbols that disappear with -O3 as optional.
+ * Bump Standards-Version to 4.6.2, no changes needed.
+
+ -- Dmitry Shachnev Sat, 04 Mar 2023 21:02:25 +0300
+
qbs (1.24.0+dfsg-4) unstable; urgency=medium
[ Patrick Franz ]
diff -Nru qbs-1.24.0+dfsg/debian/control qbs-1.24.1+dfsg/debian/control
--- qbs-1.24.0+dfsg/debian/control 2023-01-01 16:06:51.0 +0300
+++ qbs-1.24.1+dfsg/debian/control 2023-03-05 20:28:50.0 +0300
@@ -17,7 +17,7 @@
qt6-base-private-dev,
qt6-declarative-dev,
qt6-tools-dev
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
Rules-Requires-Root: no
Homepage: https://wiki.qt.io/Qbs
Vcs-Git: https://salsa.debian.org/qt-kde-team/qt/qbs.git
diff -Nru qbs-1.24.0+dfsg/debian/copyright qbs-1.24.1+dfsg/debian/copyright
--- qbs-1.24.0+dfsg/debian/copyright 2022-12-31 02:10:04.0 +0300
+++ qbs-1.24.1+dfsg/debian/copyright 2023-03-05 20:28:50.0 +0300
@@ -671,7 +671,7 @@
License: BSD-2-clause
Files: debian/*
-Copyright: 2014-2022, Dmitry Shachnev
+Copyright: 2014-2023, Dmitry Shachnev
License: LGPL-3 or GPL-2
License: LGPL-2.1-or-3 with Qt-1.1 exception
diff -Nru qbs-1.24.0+dfsg/debian/libqbscore1.24.symbols qbs-1.24.1+dfsg/debian/libqbscore1.24.symbols
--- qbs-1.24.0+dfsg/debian/libqbscore1.24.symbols 2023-01-02 02:37:09.0 +030
Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa
Hi Helge! On Mon, Mar 13, 2023 at 09:58:21PM +0100, Helge Deller wrote: > Anyway, I installed the KDE packages today and the qtquickcontrols5-examples > you mentioned. > Attached is a screenshot, which shows some KDE programs (but not KWin/plasma > as I have problems with that with the built-in graphics card). > I started the quickcontrols-filesystembrowser too (lower mid part of > screen), but I assume it does not look like what it should? Thank you very much for testing this. I would say that there are some issues with styles (low contrast, some controls are missing or just not rendered properly), but other than that it works. I am attaching a screenshot of how it looks for me, for comparison. I have now committed the fix to our repository. For Bookworm 5.15.8-2 is probably the last upload, and it has already been built on a buildd. But this fix will make its way to Trixie. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa
Hi Helge! On Mon, Feb 06, 2023 at 10:12:37PM +0100, Helge Deller wrote: > Package: qtquickcontrols-opensource-src > Tags: ftbfs, hppa > Version: 5.15.8-2 > > qtquickcontrols-opensource-src FTBFS on hppa with this testcase failure: > FAIL! : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values > are not the same >Actual (): 0 >Expected (): 1 >Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)] > > see: > https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.8-2=1675556283=0 > > Looking at debian/rules file I see: > $(MAKE) install INSTALL_ROOT=$(CURDIR)/test_root > ifneq (,$(filter $(DEB_HOST_ARCH),mips mips64el mipsel powerpc ppc64 riscv64 > s390x)) > # mips*: segmentation fault, see #868745 > # powerpc, ppc64: some failures in extras::Tests_Picture and > extras::Tests_StatusIndicator > # riscv64: failure in > qtquickcontrols::Tests_TreeView::test_pressAndHold > # s390x: some failures in qtquickcontrols::Tests_TableView and > qtquickcontrols::Tests_TreeView > -xvfb-run -a -s "-screen 0 1024x768x24 +extension RANDR +extension > RENDER +extension GLX" \ > dh_auto_test --no-parallel -- > QML2_IMPORT_PATH=$(CURDIR)/test_root/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/qml > else > > so, "riscv64" fails the same testcase. > I don't know the backgrounds why riscv64 fails, but I assume adding "hppa" to > the ifneq() like this: > ifneq (,$(filter $(DEB_HOST_ARCH),mips mips64el mipsel powerpc ppc64 riscv64 > s390x hppa)) > might fix (or avoid) the FTBFS. I see that someone forced the package to build without the tests, so now it's available in the hppa archive. But have you checked that the produced package is usable? Does Qt QML engine work on hppa, or there are issues caused by stack growing up? If you think it works, then I will be happy to disable the tests there. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1029323: libqt5core5a: adequate reports broken-symlink
Hi Vincent! On Sat, Jan 21, 2023 at 12:17:23PM +0100, Vincent Smeets wrote: > Package: libqt5core5a > Version: 5.15.7+dfsg-2 > Severity: normal > X-Debbugs-Cc: vincent.vsme...@gmail.com > > The command "adequate libqt5core5a" reports a broken link. > > $ adequate libqt5core5a > libqt5core5a:amd64: broken-symlink > /usr/lib/x86_64-linux-gnu/qt-default/qtchooser/default.conf -> > ../../../../share/qtchooser/qt5-x86_64-linux-gnu.conf I think it is not a bug. The referenced file is shipped by qtchooser package. These symlinks are needed not by the library itself, but by packages containing Qt executables, e.g. qt5-qmake, qtbase5-dev-tools, qdbus-qt5, qdoc-qt5 and others. We cannot make each of these packages ship this symlink, because then they would conflict with each other. But we can make them depend on qtchooser individually, because libqt5core5a does not need that dependency. That's what we do. If you agree with my reasoning, please close this bug. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
On Sun, Feb 19, 2023 at 08:20:43PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev wrote:
> > What are these paths?
> >
> > I think one that Helmut mentioned is the most important and should cover
> > most
> > cases.
>
> Paths to uic. moc et all.
IIRC, uic and moc produce the same output on all architectures, so we do not
need cross wrappers for them.
So calling the native /usr/lib/qt6/bin/{uic,moc} should be absolutely fine.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
¡Hola Lisandro! On Sat, Feb 18, 2023 at 11:06:51AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > I do wonder if we could trick upstream to provide a solution that works for > everyone. qmake cross wrapper is a Debian invention, so it would be hard to explain to upstream what it is and why they should change their code to support it. On Sat, Feb 18, 2023 at 04:23:21PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > There seems to be many more paths that need adjustment... or at leats at a > quick glance. I'll need to find the necessary time to fix this. What are these paths? I think one that Helmut mentioned is the most important and should cover most cases. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1030916: Symbol diffs
Hi Eric! On Fri, Feb 10, 2023 at 02:56:46PM +0800, Eric Long wrote: > Attached is the generated symbol diffs using pkgkde-symbolshelper. Can you please give me the raw diff from the build log? Your current diff marks some symbols as missing. This is not true; they are present on all architectures except riscv64. Before running pkgkde-symbolshelper, you should have changed the "SymbolsHelper-Confirmed" lines to 5.15.12, and when it asks you for the version, you should have entered 5.15.12 too (without +dfsg suffix). Then pkgkde-symbolshelper would realize that these symbols are missing only on one architecture, not completely missing in a "new version". -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6
Hi all,
On Thu, Feb 09, 2023 at 11:59:43AM +0100, Helmut Grohne wrote:
> Hi,
>
> thanks for adding the -qmake6 wrapper. This piece seems to work
> fine. The next step is making packages actually use it and this is where
> it gets difficult.
>
> fcitx-qt6 extracts the Qt6::qmake IMPORTED_LOCATION and expects to find
> a working qmake there. What it gets is the build architecture qmake
> instead of our lovely wrapper. Bummer.
>
> I looked into how this could be fixed and got entangled in the mess of
> cmake files until I completely lost track. What I found is that the
> imported location is (wrongly) defined in
> /usr/lib//cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake as
> ${_IMPORT_PREFIX}/lib/qt6/libexec/qmake aka /usr/lib/qt6/libexec/qmake
> while it should be /usr/bin/-qmake6. Tracking down how this
> file is generated is where I failed. Would someone be available to
> support me with that task?
In Qt 5 I simply patch that file using sed after dh_auto_install:
https://salsa.debian.org/qt-kde-team/qt/qtbase/-/blob/debian/5.15.8+dfsg-2/debian/rules#L285-L286
So for Qt 6 something like this may work:
sed -i 's,lib/qt6/libexec/qmake,bin/$(DEB_HOST_GNU_TYPE)-qmake,' \
debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/Qt6CoreTools/Qt6CoreToolsTargets-none.cmake
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro
On Thu, Feb 02, 2023 at 10:14:42PM +1300, Michael Cree wrote: > You may forward the screenshot. Done. Thank you again! -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro
Hi Michael! On Thu, Feb 02, 2023 at 09:00:07PM +1300, Michael Cree wrote: > On Wed, Feb 01, 2023 at 09:13:09AM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > It's from Thiago MAciera, qtbase's maintainer. The text says: > > > > "Can I ask for a screenshot of a KDE or Qt-based application running on > > Alpha > > as proof that someone is actually using this?" > > > > Can you provide us that? That will definitely help us a lot. > > Like the attached which shows okular running on an Alpha running > largely up-to-date Debian unstable? This is perfect, thanks a lot! Do you have a Qt gerrit account? Or I can forward your screenshot? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1027679: qtimageformats-opensource-src: FTBFS with tiff 4.5.0+
Hi László! On Sun, Jan 01, 2023 at 08:20:00PM +0100, László Böszörményi wrote: > Hi, > > Your package fails to build with the new major tiff release. During > self-testing two tiff RGB tests fail, I think maybe due to broken > images. Fixing it is easy, just disable those two tests, patch is > attached. I don't think disabling the tests is the right fix. It looks like this test uncovered a real bug in libtiff, which is described here: https://gitlab.com/libtiff/libtiff/-/issues/505 -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
Hi all! (And sorry for the late response. debian-qt-kde@lists.debian.org is a list for bots, so I didn't get it in my inbox. It's better to use pkg-kde-t...@alioth-lists.debian.net or @packages.debian.org.) On Tue, Dec 13, 2022 at 10:43:06AM -0700, Soren Stoutner wrote: > Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of > either creating a meta package that depends on the most recent package > that includes qwebengine_convert_dict or creating an unversioned package > that installs qwebengine_convert_dict? Also, either having > qwebengine_convert_dict being installed in an unversioned location or > having a symlink that is unversioned? That would make it easier for > Hunspell language packages to build-depend on qwebengine_convert_dict and > wouldn’t require reworking all of those packages’ build scripts every time > the version of Qt in Debian changes. I think we can do this, but why do you think such tool should be provided by Qt WebEngine, not by Chromium itself? Chromium is the main upstream for convert_dict tool, while Qt WebEngine is one of several wrappers around it (e.g. another one is Electron). Also having it in Chromium will help to avoid the problem with versions, as there is always only one version of Chromium. Source code for convert_dict is present in the Chromium tarball [1], so it shouldn't be hard to provide a new binary package for it. (Maybe this was already discussed in the thread, but I did not read every message, please give me a link if it's the case.) [1]: https://sources.debian.org/src/chromium/108.0.5359.124-1/chrome/tools/convert_dict/ -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hi all,
as I was mentioned in this discussion...
On Mon, Dec 26, 2022 at 10:27:18AM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> I would very much prefer (a). Now, as you said, timing is important
> here. Do we need a pass through NEW? If that's the case then that will
> need to happen after the next transition, if time allows it. If it can
> be easily added to the existing packaging without the need of NEW then
> we might add it right now.
>
> Last time you did the packaging with DMitry, so I'm kind of lost here.
...I would also prefer if Qt 6 used a similar setup to Qt 5. This way the
transition from Qt 5 to Qt 6 would be more transparent for the reverse
dependencies. E.g. they will only need to replace ${DEB_HOST_GNU_TYPE}-qmake
with ${DEB_HOST_GNU_TYPE}-qmake6.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#938322: fixed in qtwebengine-opensource-src 5.15.11+dfsg-1
Hi Bastian! On Sun, Dec 04, 2022 at 12:15:04AM +0100, Bastian Germann wrote: > On Sun, 27 Nov 2022 10:00:56 + Debian FTP Masters > wrote: > >* Use Python 3 instead of Python 2 for building (closes: #938322). > > - Update build-dependency. > > - Add python3.patch, inspired by Arch Linux but using versioned > > python3. > > - Add chromium-python3.patch, copied from Arch Linux. > > This is now literally the last package that has build depends on python2 in > bookworm. > Is there a chance to move the experimental package to sid soon? Done! It requires binNMU of two reverse deps, that is tracked in #1025055. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1024976: Serious regression with window decorations under GNOME/Wayland
Hi Michael! On Mon, Nov 28, 2022 at 02:24:29AM +0100, Michael Biebl wrote: > Hi, > > after the lasted update of Qt5, the window decorations of KDE/Qt apps > look out-of place under GNOME/Wayland. > > I've attached a before and after the upgrade screenshot. > Keepassxc on the after screenshot doesn't use matching window > decorations anymore. This is caused by the change [1] that enabled native Wayland support on GNOME. Now we don't need XWayland which is a big improvement in my opinion. As a side effect, window decorations are now client-side (drawn by Qt itself), not server-side. There is a qgnomeplatform theme [2][3] which makes Qt draw decorations which look better in a GNOME environment. After installing, you can enable it by exporting QT_QPA_PLATFORMTHEME=gnome somewhere. Do you think there is anything else I can do to improve the situation? [1]: https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/7e0886e100cb79f5 [2]: https://github.com/FedoraQt/QGnomePlatform [3]: https://tracker.debian.org/pkg/qgnomeplatform -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1024215: libqt5opengl5 depends on: libqt5gui5, libqt5gui5 | libqt5gui5-gles
Hi Oliver! On Wed, Nov 16, 2022 at 04:53:15PM +1100, Oliver Borm wrote: > Package: libqt5opengl5 > Version: 5.15.6+dfsg-2+b1 > > Source: qtbase-opensource-src (5.15.6+dfsg-2) > Architecture: arm64 > Installed-Size: 582 > Depends: libc6 (>= 2.17), libqt5core5a (>= 5.15.1), libqt5gui5 (>= 5.1.0), > libqt5gui5 (>= 5.8.0) | libqt5gui5-gles (>= 5.8.0), > libqt5widgets5 (>= 5.9.0~beta), libstdc++6 (>= 5), qtbase-abi-5-15-6 > > libqt5opengl5 depends on libqt5gui5 and on libqt5gui5 or > libqt5gui5-gles. Thus, it will never be possible to have libqt5gui5-gles > installed as dependency, as libqt5gui5 is always pulled in. I intentionally did not include libqt5opengl5 library in the -gles packages, because that library is deprecated. Quoting the official documentation [1]: > Warning: This module should not be used anymore for new code. > Please use the corresponding OpenGL classes in Qt GUI. [1]: https://doc.qt.io/qt-5/qtopengl-index.html -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
Hi Carlos!
On Mon, Oct 31, 2022 at 06:55:49PM -0300, Carlos Henrique Lima Melara wrote:
> Took a little while, sorry. Last week was pretty busy. I managed to try
> it today. I will attach the terminal output in the end. So my feedback
> is below.
>
> 1. I wasn't able to reproduce the misplaced menus (QTBUG-68636) in
> unstable or experimental versions.
Me too, actually.
> 2. Your patch makes qt choose the wayland plugin on gnome's wayland
> session by default.
Good. It will reach unstable together with next transition, 5.15.7
or 5.15.8.
> 3. The only problem is that qtwayland5 wayland platform plugin is not
> installed by default in a clean install of debian so applications fail
> to run wayland natively (fallback to xcb).
>
> I think we would need the qtwayland5 installed by default when gnome is
> installed (since wayland is the default there). Do you know which
> package should Depends or Recommends qtwayland5 (maybe gnome-core or
> some other package)?
libqt5gui5 currently suggests it. Do you think it needs to be a
recommendation?
> The terminal output below shows 3 executions of kristall. The first was
> using the version from unstable. The second was using the experimental
> version - fallback to xcb because the wayland platform plugin wasn't
> installed. The third is using experimental's version after qtwayland5
> was installed.
>
> charles@debianSid-vm:~$ kristall
> Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use
> QT_QPA_PLATFORM=wayland to run on Wayland anyway.
> defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> charles@debianSid-vm:~$ kristall
> qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
> defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> charles@debianSid-vm:~$ kristall
> QSocketNotifier: Can only be used with threads started with QThread
> defaultServiceProvider::requestService(): no service found for -
> "org.qt-project.qt.mediaplayer"
> Loaded 79 bytes of type "text" / "gemini"
> ignoring 1 out of 1
> 2 0 "text/gemini"
> Loaded 1265 bytes of type "text" / "gemini"
> cache: pushing url QUrl("gemini://gemini.circumlunar.space/")
> ignoring 1 out of 1
> 2 0 "text/gemini"
> Loaded 350 bytes of type "text" / "gemini"
> cache: pushing url QUrl("gemini://gemini.circumlunar.space/news/")
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
> Loaded 79 bytes of type "text" / "gemini"
This is probably just debug output, does not indicate actual errors.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#954781: libqt5core5a: QT will not use Wayland on Gnome
Hi Charles! On Sun, Oct 16, 2022 at 02:04:14AM +, charlesmel...@riseup.net wrote: > Hi, Dmitry and other maintainers, > > I've came accross this problem a couple months ago because I maintain a > QT application (Kristall). It was pretty hard to pinpoint the need to > install qtwayland5 to make everything work when setting the variable. > Besides the message displayed when running the program via cli, it also > goes to journalctl if running via Icon so users might be worried. To try > to help them, I created a bug against kristall [1] and I'm going to ship > a debian/README to explain the situation. > [...] Can you please test the Qt version from experimental and check if it works good for you? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1016814: libqt5gui5:amd64: Conditional jump or move depends on uninitialised value(s)
Hi Thorsten! On Sun, Aug 07, 2022 at 10:37:45PM +0200, Thorsten Glaser wrote: > Package: libqt5gui5 > Version: 5.15.2+dfsg-9 > Severity: normal > X-Debbugs-Cc: t...@mirbsd.de > > Running a Qt application (musescore3) against Valgrind shows: > > ==27770== Conditional jump or move depends on uninitialised value(s) > ==27770==at 0x7470A2E: __vfprintf_internal (vfprintf-internal.c:1687) > ==27770==by 0x74839C5: __vsnprintf_internal (vsnprintf.c:114) > ==27770==by 0x7511D30: __snprintf_chk (snprintf_chk.c:38) > ==27770==by 0xB50DA79: ??? (in > /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2) > ==27770==by 0xB50F232: ??? (in > /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2) > ==27770==by 0xB50FC92: ??? (in > /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2) > ==27770==by 0xB50A403: > QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char > const*) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2) > ==27770==by 0xB50D112: QXcbIntegration::QXcbIntegration(QStringList > const&, int&, char**) (in /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2) > ==27770==by 0x485346E: ??? (in > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so) > ==27770==by 0x67438FB: > QGuiApplicationPrivate::createPlatformIntegration() (in > /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2) > ==27770==by 0x6744D4F: QGuiApplicationPrivate::createEventDispatcher() > (in /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2) > ==27770==by 0x6F86A55: QCoreApplicationPrivate::init() (in > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.2) > ==27770== Uninitialised value was created by a stack allocation > ==27770==at 0xB50E7A0: ??? (in > /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.2) > > I don’t always see this. In this example, $DISPLAY points to Xtightvnc > from tightvncserver (= 1:1.3.10-3). Does it still happen with the latest version of Qt (5.15.6)? If yes, can you please install libqt5gui5-dbgsym and generate a new stacktrace? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1021528: No update in GUI since upgrade
Control: reassign -1 psi-plus 1.4.554-5 Hi Klaus and Boris! On Mon, Oct 10, 2022 at 08:02:00AM +0100, Klaus Ethgen wrote: > Package: libqt5gui5 > Version: 5.15.6+dfsg-2 > Severity: important > > First, I do not know exactly /which/ qt5 package is the source of the > bug but GUI is the most likely. As the packages are not independent > upgradable, that is not easy to find out. > > Since the last upgrade of qt5 stack begin of month, I seen the following > problem in PSI+ (the only qt5 tool I use regulary): > When I start it and open *one* chat window, everything is normal. But > when I open a *second* chat window and close it afterwards, I do not see > what I type in the first chat window anymore. When I close the window > and reopen, I see what I typed (and sent) but still don't see what is > typed. > > To fix that (until again I open a second chat window) I have to restart > the whole application. > > So this bug renders (at least) PSI+ nearly unusable to talks to more > then one people. (The version of psi-plus is 1.4.554-5+b2.) Qt 5.15.6 is available in unstable for more than two weeks now, and I am not aware of such issues in any other Qt 5 application. So I lean towards thinking that this is an issue in PSI+, not in Qt. However, feel free to prove me wrong by providing a minimal reproducible example. Or if you can point to a particular change in Qt that broke PSI+, I would be happy to revert it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983597: Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Hi Dennis!
On Sat, Oct 15, 2022 at 01:51:16PM +0200, Dennis Filder wrote:
> Control: tag -1 + patch
>
> The attached patch fixed the crashes of Linphone for me.
Thank you for the patch. I let the upstream maintainers know about it
in https://bugreports.qt.io/browse/QTBUG-84858#comment-684786.
However, if you can make an account on Qt Gerrit [1][2] and submit your
patch there, it would speed up the review process.
I think there are some style issues with your patch: instead of using a
name starting with underscore and __attribute__((visibility("hidden"))),
it would be better to add a new method to QQuickItemPrivate class.
In that method, "this" instance would become what was "d", and if you use
Q_Q(QQuickItemPrivate), "q" object would become what was "this".
Our general policy is to get patches merged (or at least approved)
upstream, before including them into Debian.
[1]: https://codereview.qt-project.org/
[2]: https://wiki.qt.io/Setting_up_Gerrit
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1016277: qbs: FTBFS: ERROR: /usr/bin/ld: unrecognized option '-Wl,-s'
Control: fixed -1 qbs/1.23.0-1 Control: close -1 Control: merge 1013020 -1 On Fri, Jul 29, 2022 at 06:24:03PM +0200, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > 3: ERROR: /usr/bin/ld: unrecognized option '-Wl,-s' > > 3: /usr/bin/ld: use the --help option for usage information > > 3: collect2: error: ld returned 1 exit status No, the relevant part is this: > dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols > file: see diff output below So it is the same bug as #1013020, which is fixed in experimental. I hope I will upload it to unstable soon, but I need to find a workaround for #1016041. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io
On Mon, Jul 11, 2022 at 04:22:01PM -0400, Shmerl wrote: > I know Wayland Qt patches are critical for stable Plasma experience, > but I'm not an expert on all of these. Wayland patches are applied, as I said. > May be some communication between upstream KDE developers and Debian > team would be good here? Expecting users to know what patches are important > isn't a very reliable method. I expect users to complain if something doesn't work. Also note that now we get releases from Qt every couple of months, so sooner or later we will get most of the patches this way (and it will be easier to deal with the remaining ones). -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1014433: libqt5gui5 vs libqt5gui5-gles non-transition remnants
Hi Adam! On Tue, Jul 05, 2022 at 10:43:19PM +, Adam Katz wrote: > Package: libqt5gui5 > Version: 5.15.4+dfsg-3 > > This builds on bug 919218, "non-transition: libqt5gui5-gles", > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919218 > > There are still ~23 packages that are broken (forcibly uninstalled) > in response to installing libqt5gui5-gles, 7 by omitting the OpenGL > alternative and 16 by a dependency-listing bug. For most of these packages, this means that they use symbols that exist only in libqt5gui5 and not in libqt5gui5-gles, for example QOpenGLFunctions without _ES2 suffix. What you call "dependency-listing bug" is actually the way how symbols dependencies work: if a package uses some symbols that exist in both versions, and some symbols that exist only in one version, it will get an A | B dependency for the first group of symbols and just A for the second group. The way to make them compatible with both versions will be resolving the OpenGL version and required functions at runtime, but it will usually mean a major rewrite. > As an alternative to fixing all of these packages, you could rename > the current libqt5gui5 package as something like `libqt5gui5-nogles` > and then create a new `libqt5gui5` package that simply depends on > `libqt5gui5-nogles | libqt5gui5-gles`. It will be wrong. If a package depends on just libqt5gui5, it won't run with libqt5gui5-gles, even if you make the dependency satisfiable. > The rest of this post is about identifying those 7+16 broken packages. > [...] I took a few packages from your lists and looked at them: - elektra-qt-gui: FTBFS for many years so did not get the new dependency - mldemos: FTBFS for several years so did not get the new dependency - audacious-plugins: Uses QOpenGLFunctions_2_0 - cloudcompare: Uses QOpenGLFunctions_2_1 - colmap: Uses QOpenGLFunctions_3_2_Core I believe most of the other packages will fall into one of these two categories. Also, if a package build-depends on libqt5opengl5-desktop-dev, it is a good sign that it will work only with desktop OpenGL and not with OpenGL ES. > PS: What's the preferred wrapping scheme in Debian bugs? > I don't see a style guide beyond https://www.debian.org/Bugs/Reporting > and that's likely because I'm not using reportbug. I usually wrap at 78 characters, as recommended by RFC 2822. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1014153: libqt5gui5: cannot mouse over "grouped window" set to select -- lxqt panel task manager
Control: reassign -1 lxqt-panel 0.16.1-1 Hi! On Thu, Jun 30, 2022 at 07:45:28PM -0600, proctor wrote: > Package: libqt5gui5 > Version: 5.15.4+dfsg-3 > Severity: normal > X-Debbugs-Cc: damonswir...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? > panel crashed after clicking on okular grouped set of windows. > after panel reloaded the issue manifested. > i believe the crash/reload reloaded a new version (5.15.4+dfsg-3) and > that is where i think the problem may lie. > >* What exactly did you do (or not do) that was effective (or > ineffective)? > tried rebooting. (not work) > tried creating new user and logging in as them. (not work) > tried using lxde desktop environment (this works) > tried reinstalling lxqt. (not work) > >* What was the outcome of this action? > none of the troubleshooting produced a postitive result. > >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > this appears to be the exact same issue as reported here > https://github.com/lxqt/lxqt-panel/issues/1600 > which also seems to have a patch available. Right, but that patch is for lxqt-panel, not for Qt. So reassigning the bug. The patch is https://github.com/lxqt/lxqt-panel/commit/4c674608aaaac73d and it is present in versions ≥ 0.17.0. Debian currently has 0.16.1. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1013896: qtbase-opensource-src: Use KDE Qt as upstream instead of qt.io
Hi Shmerl! On Sun, Jun 26, 2022 at 06:13:09PM -0400, Shmerl wrote: > Source: qtbase-opensource-src > Version: 5.15.4+dfsg-3 > Severity: wishlist > X-Debbugs-Cc: shtetl...@gmail.com > > Dear Maintainer, > > KDE team maintains important patchset over official Qt that has a lot of bug > fixes especially for the Wayland session use case. Because KDE does not make any releases, and because some patches break ABI, we decided to cherry-pick only individual patches that our users request. However, we made an exception for Qt Wayland, and the current Qt Wayland package in testing includes all patches from KDE up to 2022-05-14. This should fix the issues with Wayland session. Are there any other patches you want to have? -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1004594: qtwebengine-opensource-src: FTBFS with ffmpeg 5.0
Control: forwarded -1 https://bugs.chromium.org/p/chromium/issues/detail?id=1251779 Hi Sebastian, and sorry for the long delay. On Wed, Feb 16, 2022 at 12:12:01AM +0100, Sebastian Ramacher wrote: > This came up on ffmpeg-devel [1]. Their suggestion is to keep track of > that value in chromium similar to [2]. That is: as long as the first DTS > was not store, take PTS from the first packet that has it and compute it > from PTS. > > Cheers > > [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2021-September/285401.html > [2] https://github.com/FFmpeg/FFmpeg/commit/ab4f299e23 I see there is an open Chromium bug which has a link to the same ffpmeg-devel email: https://bugs.chromium.org/p/chromium/issues/detail?id=1251779 I don't want to touch Chromium code, so I will build with bundled ffmpeg for now, and wait for that bug to be fixed. I see that our Qt 6 maintainer did the same in qt6-webengine. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1012793: libpyside2-py3-5.15 uninstallable on unstable: unsatisfiable Depends
Hi Julian! On Tue, Jun 14, 2022 at 08:37:38AM +0100, Julian Gilbey wrote: > Package: libpyside2-py3-5.15 > Version: 5.15.2-2.1 > Severity: serious > > This package depends on qtbase-abi-5-15-2 and > qtdeclarative-abi-5-15-2, but libqt5core5a now Provides: > qtbase-abi-5-15-4 and libqt5qml5 now Provides: > qtdeclarative-abi-5-15-4. The dependencies of this package need > updating to bring them into sync. We are now in a middle of Qt 5.15.4 transition [1][2]. Wait a couple of days, pyside2 will be rebuilt by the Release team. [1]: https://release.debian.org/transitions/html/qtbase-abi-5-15-4.html [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007170 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1011935: (no subject)
On Fri, May 27, 2022 at 10:58:24AM -0600, tsteven4 wrote: > Why do many qt6 packages have a dependency on qtchooser if you are not > supporting Qt6 with qtchooser? > > qt6-webengine-dev-tools > qt6-l10n-tools > qt6-documentation-tools > qt6-declarative-dev-tools > qt6-base-dev-tools > qmlscene-qt6 > qml-qt6 > assistant-qt6 > linguist-qt6 > designer-qt6 I discussed this with my co-maintainers, and we decided to remove these dependencies. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1011935: QtChooser is dead by choice upstream, no Qt6 Support
Hi Thomas! On Thu, May 26, 2022 at 09:58:36PM -0400, Thomas Ward wrote: > Source: qtchooser > Severity: wishlist > > It was determined from > https://salsa.debian.org/qt-kde-team/qt/qtchooser/-/merge_requests/2 and a > downstream Ubuntu bug on Qt6 not working that QtChooser is dead upstream on > purpose. > > If it is dead upstream on purpose and should NOT work with Qt6, could we add > a Breaks on qt6 and higher, since it is only kept around for Qt5 support and > not breaking Qt5 applications that rely on it? Therefore indicating that > Qt6 is not and *will* not be supported on the now-dead-upstream project? qtchooser is perfectly co-installable with Qt 6 libraries, and I don't see why we should disallow people to use qtchooser (for Qt 5) while also having Qt 6 installed. Eventually qtchooser will be removed, but the majority of Qt software is still using Qt 5 and not Qt 6, so it's still useful and it's very likely that users will have both Qt 5 and Qt 6 installed. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1001082: qtbase-opensource-src: segfault when closing one windows in a multi window QT application
Hi, On Thu, Feb 17, 2022 at 11:16:39AM -0500, theofficialgman wrote: > Thanks for pushing the fix to the buster git branch. Is this good to be > released or do we have to wait for some release timing before it is built > and published? I have just filed https://bugs.debian.org/1006182 which needs to be approved by the Release team. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1006009: qtimageformats-opensource-src: FTBFS on mipsel: test failure
Control: reassign -1 libwebp7 1.2.1-7 Control: affects -1 src:qtimageformats-opensource-src Hi Sebastian and libwebp maintainers! On Fri, Feb 18, 2022 at 10:39:23PM +0100, Sebastian Ramacher wrote: > Source: qtimageformats-opensource-src > Version: 5.15.2-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > qtimageformats-opensource-src FTBFS on mipsel: > > TIFFReadDirectory: Warning, Sum of Photometric type-related color channels > and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels > as ExtraSamples.. > TIFFReadDirectory: Warning, Sum of Photometric type-related color channels > and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels > as ExtraSamples.. > PASS : tst_qtiff::tiffGrayscale() > FAIL! : tst_qwebp::writeImage(kollada_noalpha-100) '!reread.isNull()' > returned FALSE. () >Loc: [tst_qwebp.cpp(174)] > PASS : tst_qwebp::cleanupTestCase() > Totals: 10 passed, 1 failed, 0 skipped, 0 blacklisted, 632ms > * Finished testing of tst_qwebp * > > See > https://buildd.debian.org/status/fetch.php?pkg=qtimageformats-opensource-src=mipsel=5.15.2-2%2Bb1=1645209225=0 It looks to me like a bug in new libwebp version: encoder generates broken webp files on mipsel. I can reproduce it without any Qt code by encoding the attached PNG file and then trying to decode it back: (sid_mipsel-dchroot)mitya57@eller:~$ cwebp kollada_noalpha.png -lossless -o kollada_noalpha.webp Saving file 'kollada_noalpha.webp' File: kollada_noalpha.png Dimension: 436 x 160 Output:37004 bytes (4.24 bpp) Lossless-ARGB compressed size: 37004 bytes * Header size: 636 bytes, image data size: 36342 * Precision Bits: histogram=3 transform=3 cache=1 (sid_mipsel-dchroot)mitya57@eller:~$ dwebp kollada_noalpha.webp Decoding of kollada_noalpha.webp failed. Status: 3(BITSTREAM_ERROR) I am also attaching the generated broken WEBP file. -- Dmitry Shachnev kollada_noalpha.webp Description: Binary data signature.asc Description: PGP signature
Bug#1001082: qtbase-opensource-src: segfault when closing one windows in a multi window QT application
Hi! On Wed, Feb 09, 2022 at 01:58:05PM -0500, theofficialgman wrote: > any updates on this? as referenced before, it should be fixable by picking > these two commits: > https://codereview.qt-project.org/c/qt/qtbase/+/264529 > https://codereview.qt-project.org/c/qt/qtbase/+/237817 > which were used to resolve this bug: > https://bugreports.qt.io/browse/QTBUG-68393 In your first message you mentioned these two commits: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=ca991ee22d3509f8 Segfault when the exiting the application under platform eglfs https://code.qt.io/cgit/qt/qtbase.git/commit/?id=e9e8d67e31b8b6a8 Fix segfault when closing widget and destroying window in QDialog::done But these two codereviews are completely different commits: https://code.qt.io/cgit/qt/qtbase.git/commit/?id=81e298a51d08c510 QWidget: fix setTabOrder for compound widgets https://code.qt.io/cgit/qt/qtbase.git/commit/?id=a7cbb8c639487edb QWidget: fix setTabOrder for compound widgets Can you please clarify which of the commits I should cherry-pick? Sorry for the delayed reply, our team has limited resources and we are mostly focused on the current stable release and the development release, your bug seems to affect only oldstable. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#1004594: qtwebengine-opensource-src: FTBFS with ffmpeg 5.0
Control: tags -1 - pending
Hi Sebastian!
On Sun, Jan 30, 2022 at 09:34:10PM +0100, Sebastian Ramacher wrote:
> qtwebengine-opensource-src FTBFS with ffmpeg 5.0 (available in
> experimental):
I backported some upstream commits which make it better, but not completely.
My current problem is that I don't see any replacement for this code in
Chromium's media/filters/ffmpeg_demuxer.cc:
if (stream->first_dts != kNoFFmpegTimestamp &&
stream->codecpar->codec_id != AV_CODEC_ID_HEVC &&
stream->codecpar->codec_id != AV_CODEC_ID_H264 &&
stream->codecpar->codec_id != AV_CODEC_ID_MPEG4) {
const base::TimeDelta first_pts =
ConvertFromTimeBase(stream->time_base, stream->first_dts);
if (first_pts < start_time)
start_time = first_pts;
}
Here stream is AVStream*. In FFmpeg 5, that class does not have first_dts
member. FFmpeg's own code uses ffstream() to cast such a pointer to FFStream*,
but both FFStream struct and ffstream() function are private API.
Upstream Chromium uses a bundled copy of FFMpeg and they patched it to add
av_stream_get_first_dts() function which exposes that member [1].
So my questions are:
- Do you know how to write equivalent code using only public API?
- If no, maybe you can add av_stream_get_first_dts() function so that Chromium
can use it? I can file a bug upstream asking to make it official for the next
release.
- Alternatively, maybe you can install libavutil's internal.h header, so I can
take FFStream and ffstream() definitions from there?
I hate both second and third solutions, but nothing better came to my mind.
[1]:
https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/refs/heads/master/libavformat/utils.c#95
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#1003249: libqt5webenginecore5: i386 baseline violation
Hi! On Fri, Jan 07, 2022 at 12:58:50AM +0100, NoSSE2 wrote: > Dear Maintainer, > > I tried to start Konqueror on a fresh install of Debian by typing konqueror > into LXTerminal, it doesn't start, just crashes all the time. > > It violates the i386 baseline by using SSE2 unconditionally, even if the host > CPU doesn't support it (tested on a downclocked Athlon XP). > > I suggest that https://wiki.debian.org/SIMDEverywhere might be helpful in > developing a patch, if it isn't just a compiler flag fix. > > If this issue/bug is unfixable, the package should depend on package > sse2-support (i386 only). Yes, it is unfixable. Qt WebEngine is based on Chromium which requires SSE2 since 2014 [1] and SSE3 since version 89 (2020) [2][3]. Qt WebEngine 5.15 is based on Chromium 87 so it does not require SSE3 yet, but definitely requires SSE2. I will add a dependency on sse2-support. [1]: https://codereview.chromium.org/197403004 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1123353 [3]: https://docs.google.com/document/d/1QUzL4MGNqX4wiLvukUwBf6FdCL35kCDoEJTm2wMkahw/edit?usp=sharing -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#998605: krita: FTBFS: sip: /usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23: syntax error
Hi, On Thu, Nov 04, 2021 at 08:49:47PM +0100, Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > sip: /usr/lib/python3/dist-packages/PyQt5/bindings/QtCore/QtCoremod.sip:23: > > syntax error It looks like a result of recent pyqt5 update — it broke compatibility with SIP 4. This issue was discussed on PyQt mailing list yesterday [1], but the upstream developer said he is not going to rush to fix this. I don't know what this means, but if there is a fix at least in upstream Vcs or snapshots, I will cherry-pick it. [1]: https://www.riverbankcomputing.com/pipermail/pyqt/2021-November/044346.html -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#995187: qtwebengine-opensource-src FTBFS on mips*: unistd_nr_{n32,n64,o32}.h no linger exported by the kernel
On Wed, Sep 29, 2021 at 08:03:37PM +0800, YunQiang Su wrote: > The 999u is due to that: > #if _MIPS_SIM == _MIPS_SIM_ABI32 > #define __NR_Linux 4000 > #endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */ > #if _MIPS_SIM == _MIPS_SIM_ABI64 > #define __NR_Linux 5000 > #endif /* _MIPS_SIM == _MIPS_SIM_ABI64 */ > #if _MIPS_SIM == _MIPS_SIM_NABI32 > #define __NR_Linux 6000 > #endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */ > > The o32/n64/n32 ABI is just from 4000/5000/6000. > > In the previous version of Linux kernel, it expose > __NR_64_Linux_syscalls > __NR_32_Linux_syscalls > __NR_N32_Linux_syscalls > for the real number of syscalls for the given Linux version. > While now, these macro has been tread as kernel internal values, > and cannot be get in userland. > > Since 4000/5000/6000, ≥ will be impossbile without huge rework for kernel. Thanks for the explanation! I added your patch and uploaded new version, let's see how it goes. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#995187: qtwebengine-opensource-src FTBFS on mips*: unistd_nr_{n32,n64,o32}.h no linger exported by the kernel
Hi YunQiang! On Wed, Sep 29, 2021 at 09:09:46AM +0800, YunQiang Su wrote: > Ohh, the new mips linux kernel removes some macros: so now we can use > the same code as x86: Thank you for the patch! What I don’t like is hard-coding of 999u. Do you know what is the actual number of syscalls? Is there a probability that it will be ≥ 1000 in the future? -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Proposal: drop Salsa CI testing for now
Hi all! On Sun, Aug 29, 2021 at 04:18:33PM +0900, Norbert Preining wrote: > Any, I have done the above now for frameworks and apps. > > I am interested to see the result. I want to share my experience with Salsa CI. I usually enable it for all my packages which have full source code in the repository (i.e. except Qt which has debian directory only). Most of the time it passes without issues. However when it fails, it is most likely a real bug somewhere, which I would otherwise not notice. Building all packages in a chroot before upload indeed helps you to catch some issues early, but Salsa CI does much more: it also builds on i386, runs the autopkgtests, runs Lintian etc. It is inconvenient to do all these things manually. And, for example, if the autopkgtests fail and you didn't know about that before uploading, then you will have to do another upload to let the package migrate to testing. Regarding the failures, the main source of problems for me was the reprotest. Sometimes it can be fixed with a small patch or tweaking of build flags. But in case it's hard to fix or you simply want to ignore reprotest, you can allow it to fail by adding these lines to gitlab-ci.yml: reprotest: allow_failure: true Or disable certain variations, like this (you can enable atomic reprotest to check which ones are problematic): variables: SALSA_CI_REPROTEST_ARGS: --variations=-locales Even if you disable half of the jobs (reprotest, blhc, something else), Salsa CI will be still useful to detect other problems (such as symbols errors on i386). -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#990129: libqt5core5a: breaks work of some QtWebEngine based programs
Hi Boris! On Mon, Jun 21, 2021 at 03:51:08PM +0300, Boris Pek wrote: > Hi, > > I use Debian 11 (Bullseye) on work PC to develop Qt based projects. All worked > fine until update of Qt packages last week: one of our QML based application > stopped showing maps without any errors in stdin/stdout. > > Today I spent few hours to find the root of problem. QtWebEngine is used for > displaying maps and it is quite problematic itself, but I was surprised to > find > what problem was caused by update in QtCore library: > libqt5core5a:amd64 (5.15.2+dfsg-5, 5.15.2+dfsg-6) > > And if I understand correctly here is the problematic patch: > https://salsa.debian.org/qt-kde-team/qt/qtbase/-/commit/5eaeb73 > > Could you revert it please? Can you please test if the .deb file attached to this message fixes the bug for you? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989744#37 In that file I reverted changes to src/corelib/mimetypes/qmimeprovider.cpp from that commit. These changes were not related to the main purpose of that commit, so this way we can still have the original bug fixed. -- Dmitry Shachnev
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi all, On Mon, Jun 14, 2021 at 09:41:13AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Now I understand your use case, but it really sounds more like a hack > than the proper way of doing things. > > In my point of view you should reach KDE devs, explain them why you > need this functionality and convince them to support it. My guess is > that a flag in dolphin's config in order to get you all the options > would be just enough. Following what Lisandro said, I will not upload the revert to unstable. Dennis, please contact the upstream Qt developers, and if they revert that part of the patch or change the code to make your use case work, I will be happy to backport those fixes to our package. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
On Sat, Jun 12, 2021 at 04:01:55PM +0200, Dennis Filder wrote: > > Please test the attached .deb file. I did not change the version number, > > to make it possible to install only libqt5core5a and not the whole qtbase > > stack. > > Thanks. That indeed brings the behaviour close enough to how it was > before that I would consider it a fix for this bug. Since the > remaining patch still changes the MIME type decision logic the > behaviour is still somewhat different though. However, it becomes > difficult for me to tell how different because remembering the exact > details of the previous (5.15.2+dfsg-5) behaviour is not easy as it > never quite worked consistently either. Thank you for testing! As it is better than the -6 and -7 versions in archive, I am going to upload this fix to unstable and ask the release team for an unblock. Lisandro, do you agree with that plan? > For example now with the glob pattern "*.*" added to "all/allfiles" a > C source code file "test.c" in Dolphin's list view is listed as being > of type "all files" and also all operations defined for "all/allfiles" > are listed in the context menu, but after selecting "Properties" in > Dolphin's context menu its "Contents" field shows "C source code" > (presumably because Dolphin uses magic-based fingerprinting). All > this despite the file /usr/share/mime/text/x-csrc.xml defining the > MIME type "text/x-csrc" with the glob pattern "*.c". I think it has > to do with how user-defined MIME type definitions from > ~/.local/share/mime are merged into the set of system-defined ones. > Since KDE System Settings does not allow you to specify a weight value > for your glob patterns (and most under /usr/share/mime/* don't specify > it either) the merging does not actually always yield sensible results > as almost all glob patterns end up having the default weight of 50. > And it also leads to behaviour that is difficult to reproduce across > setups. > > I just wished the KDE devs would actually try a little harder to make > all this MIME type handling more consistent (and easier to > investigate) and to make the MIME types "all/all" and "all/allfiles" > behave as you would expect. But I guess that belongs in a separate > bug report. Thanks for the very detailed explanation, but it will be much better if you send all these details to upstream Qt or KDE bugtrackers (and also mention the regression caused by the patch). We are just packagers, and I am really not an expert in mimetypes and the relevant code. If you do it, please let me know the bug URL, I will keep an eye on it and backport any fixes when/if they become available. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#989744: libqt5core5a: 5.15.2+dfsg-7 breaks MIME subclassing logic (which breaks some features in e.g. Dolphin)
Hi all, On Fri, Jun 11, 2021 at 02:12:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > This really sounds like a use case that was possible due to the bug, > and the fix broke that path. According to the patch: > > This change also optimizes QMimeBinaryProvider::addFileNameMatches > to have the same logic as xdgmime for glob matching: > literals > extensions > other globs Actually the patch I cherry-picked contains two parts that are not directly related to each other. If this bug is caused by the change to src/corelib/mimetypes/qmimeprovider.cpp then I think we should just remove that file from the patch. That change is not related to the main bug [1][2] that I was trying to get fixed. Dennis, is there any chance you can build qtbase with that part of the patch removed? Or maybe you can test a *.deb file I share with you? [1]: https://launchpad.net/bugs/1857824 [2]: https://bugs.kde.org/show_bug.cgi?id=411718 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#976389: libqt5quick5-gles: With libqt5quick5-gles KDE icons & widgets don't appear, with libqt5quick5 it works
On Fri, May 14, 2021 at 09:28:04PM +0300, Dmitry Shachnev wrote: > [...] > > So for people who had qt5-default installed, apt will try to replace the > normal Qt stack with -gles one to keep that dependency satisfied. Apparently > it will do it even if qt5-default will be eventually removed anyway. I am > attaching a log when this happens when trying to upgrade from an August 2020 > testing snapshot (with qt5-default installed) to the current testing. I forgot the file, really attaching it now. -- Dmitry Shachnev root@mitya57:/# apt -o Debug::pkgProblemResolver=yes install libqt5widgets5 Reading package lists... Done Building dependency tree Reading state information... Done Starting pkgProblemResolver with broken count: 2 Starting 2 pkgProblemResolver with broken count: 2 Investigating (0) qtbase5-dev:amd64 < 5.14.2+dfsg-5 -> 5.15.2+dfsg-5 @ii umU Ib > Broken qtbase5-dev:amd64 Depends on libqt5concurrent5:amd64 < 5.14.2+dfsg-5 | 5.15.2+dfsg-5 @ii umH > (= 5.15.2+dfsg-5) Considering libqt5concurrent5:amd64 -1 as a solution to qtbase5-dev:amd64 0 Re-Instated libqt5concurrent5:amd64 Re-Instated qt5-qmake-bin:amd64 Re-Instated qt5-qmake:amd64 Re-Instated qtbase5-dev:amd64 Investigating (0) qt5-default:amd64 < 5.14.2+dfsg-5 @ii mK Ib > Broken qt5-default:amd64 Depends on qtbase5-dev:amd64 < 5.14.2+dfsg-5 -> 5.15.2+dfsg-5 @ii umU > (= 5.14.2+dfsg-5) Considering qtbase5-dev:amd64 0 as a solution to qt5-default:amd64 -2 Broken qt5-default:amd64 Depends on qtbase5-gles-dev:amd64 < none | 5.15.2+dfsg-3 @un uH > (>= 5.14.2+dfsg) Considering qtbase5-gles-dev:amd64 -1 as a solution to qt5-default:amd64 -2 Try Installing qtbase5-gles-dev:amd64 < none | 5.15.2+dfsg-3 @un uH > before changing qt5-default:amd64 Or group remove for qt5-default:amd64 Done The following packages were automatically installed and are no longer required: libavahi-client3 libavahi-common-data libavahi-common3 libcups2 libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libedit2 libegl-dev libelf1 libgl-dev libgl1 libgl1-mesa-dev libgl1-mesa-dri libgles-dev libgles1 libglu1-mesa libglu1-mesa-dev libglvnd-dev libglx-dev libglx-mesa0 libglx0 libllvm10 libopengl-dev libopengl0 libpciaccess0 libpthread-stubs0-dev libqt5concurrent5 libqt5printsupport5 libqt5sql5 libqt5test5 libqt5xml5 libsensors-config libsensors5 libvulkan-dev libvulkan1 libx11-dev libxau-dev libxcb-glx0 libxcb1-dev libxdamage1 libxdmcp-dev libxext-dev libxext6 libxfixes3 libxxf86vm1 libz3-4 qt5-qmake qt5-qmake-bin qtbase5-dev-tools qtchooser x11proto-core-dev x11proto-dev x11proto-xext-dev xorg-sgml-doctools xtrans-dev Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5-gles libqt5network5 libqt5printsupport5 libqt5sql5 libqt5test5 libqt5xml5 libx11-6 libx11-dev libx11-xcb1 libxrender1 qt5-qmake qt5-qmake-bin qtbase5-dev-tools Suggested packages: libthai0 qt5-image-formats-plugins qtwayland5 libx11-doc Recommended packages: qttranslations5-l10n libqt5svg5 qt5-gtk-platformtheme libqt5sql5-sqlite | libqt5sql5-mysql | libqt5sql5-odbc | libqt5sql5-psql | libqt5sql5-tds | libqt5sql5-ibase The following packages will be REMOVED: libqt5gui5 qt5-default qtbase5-dev The following NEW packages will be installed: libqt5gui5-gles libxrender1 The following packages will be upgraded: libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5network5 libqt5printsupport5 libqt5sql5 libqt5test5 libqt5widgets5 libqt5xml5 libx11-6 libx11-dev libx11-xcb1 qt5-qmake qt5-qmake-bin qtbase5-dev-tools 15 upgraded, 2 newly installed, 3 to remove and 196 not upgraded. Need to get 3229 kB/12.9 MB of archives. After this operation, 13.7 MB disk space will be freed. Do you want to continue? [Y/n] signature.asc Description: PGP signature
Bug#976389: libqt5quick5-gles: With libqt5quick5-gles KDE icons & widgets don't appear, with libqt5quick5 it works
Control: reassign -1 libqt5gui5-gles 5.15.2+dfsg-3 Control: retitle -1 apt replaces libqt5gui5 with libqt5gui5-gles on upgrade On Fri, Dec 11, 2020 at 09:29:04PM +0300, Dmitry Shachnev wrote: > Thanks for the detailed bug report and the blog post link! > > If you are using amd64 desktop then you would almost never need > libqt5quick5-gles. These packages are mostly needed for ARM64 users, or for > users of video cards that support OpenGL ES but not desktop OpenGL. > > See my blog post for details: > > https://mitya57.me/weblog/2020/01/qt-opengl-es-packages-available.html > > However, it would be nice to know why users end up with the -gles packages > installed. Your case is not the only one, here is a similar story: > > https://www.reddit.com/r/debian/comments/jpm3bn/after_doing_a_distupgrade_i_no_longer_have_icons/ > > For the record, let me put together some links I found via your blog post: > > - https://askubuntu.com/q/1288506 > - > https://www.reddit.com/r/kde/comments/jhqbnz/kde_plasma_rendering_problem_black_squares/ > - https://ubuntuforums.org/showthread.php?t=2442842 > > All dependencies should be in a form like libqt5gui5 | libqt5gui5-gles, so > apt should fall back to the latter package only if the former is not available > for some reason. So I want to understand what that reason is. Thanks to the Ubuntu user who sent me their log, I think I finally found the cause of this bug. This cause is the qt5-default package. We removed it because it is no longer needed. But the latest version of that package that ever existed has this dependency: Depends: qtbase5-dev (= 5.14.2+dfsg-5) | qtbase5-gles-dev (>= 5.14.2+dfsg) The latest available version of qtbase5-dev cannot satisfy that dependency, but the latest version of qtbase5-gles-dev can! So for people who had qt5-default installed, apt will try to replace the normal Qt stack with -gles one to keep that dependency satisfied. Apparently it will do it even if qt5-default will be eventually removed anyway. I am attaching a log when this happens when trying to upgrade from an August 2020 testing snapshot (with qt5-default installed) to the current testing. As a solution to this problem, I will add “Breaks: qt5-default” to libqt5gui5-gles and to qtbase5-gles-dev. This should convince apt to not consider these packages as a way to satisfy qt5-default dependency. This bug should not affect upgrades from Buster to Bullseye, as the Buster version of qt5-default had a dependency on qtbase5-dev only. So it only affects upgrades from old (pre Oct 2020) testing/sid to modern testing/sid. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#987775: Re : Bug#987775: qdbus: Breaks libqt4-dbus
On Thu, Apr 29, 2021 at 07:26:41PM +0200, nicolas.patr...@gmail.com wrote: > OK but why apt did not propose me to upgrade qdbus and remove libqt4-dbus? I guess apt's dependency resolver is not smart enough. Anyway qdbus is a dummy transitional package, so it can also be safely removed. Use qdbus-qt5 instead. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#974091: This is really a libqt5opengl5 dependency issue
Hi Sebastian! On Thu, Apr 22, 2021 at 06:45:06PM +0200, Sebastian Spaeth wrote: > While this is filed against qtbase5-examples, the dependency issues are > really a problem of libqt5opengl5 and should thus be filed against this > package. > > libqt5gui5 (>= 5.1.0), libqt5gui5 (>= 5.12.5) | libqt5gui5-gles (>= > 5.12.5) > > essentially excludes libqt5gui5-gles. I experience this problem trying to > install qtgstreamer-plugins-qt5 which depends on libqt5opengl5 leading to > the same problems. On both the pinephone and the Librem5, the non-gles > versions lead to crashes. This is correct. libqt5opengl5 is a deprecated library [1] and we decided to not ship an OpenGL ES version of it. Packages that depend on libqt5opengl5 should be ported to modern API (e.g. QGLWidget → QOpenGLWidget), then they will not have this extra dependency. In Qt 6, the OpenGL library is removed completely. Speaking about qtgstreamer particularly, it is unmaintained [2] and the author suggests some alternatives which should be used instead. By the way, thanks for the feedback of using our packages on pinephone and Librem5. If there are any other issues, please do not hesitate to report them. [1]: https://doc.qt.io/qt-5/qtopengl-index.html [2]: https://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/README -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#986206: qmake drops options passed from QMAKE_CXXFLAGS_RELEASE and QMAKE_CXXFLAGS_DEBUG
Control: reassign -1 src:guymager 0.8.12-1 Control: severity -1 important Hi Matthias! On Wed, Mar 31, 2021 at 05:30:17PM +0200, Matthias Klose wrote: > seen when building guymager, adding to the rules file: > > export DEB_CXXFLAGS_MAINT_APPEND = --param ggc-min-expand=0 --param > ggc-min-heapsize=0 > > The generated Makefile isn't correctly generated. The "# Command" line shows > the > passed args, which are correct, however the "^CXXFLAGS" line shows that the > flags are expanded twice, and the first time, the second --param option is > omitted, but not the parameter following that option. This happens because guymager.pro line 150 has this: QMAKE_CXXFLAGS *= $$system(dpkg-buildflags --get CXXFLAGS) The *= operator is for adding unique values (as opposed to +=). The --param flag appears twice, so it keeps only the first instance: https://doc.qt.io/qt-5/qmake-language.html#adding-unique-values You can use --param=ggc-min-expand=0 --param=ggc-min-heapsize=0, then there will be no such problem. Also there is no need at all to call dpkg-buildflags from the .pro file. debhelper passes all needed flags via command line arguments. > Feel free to reassign to guymager and lowering the severity, if that is not > a generic qmake issue. Doing so. Dear guymager maintainer(s): please consider removing lines 150 and 151 from guymager.pro, or at least replacing *= with +=. -- Dmitry Shachnev
Bug#983025: libqt5widgets5: Segfault with QGLWidget class. Fixed Upstream
Control: reassign -1 libqt5opengl5 5.15.2+dfsg-4 On Sun, Mar 21, 2021 at 05:05:53PM +0100, Alejandro Lorenzo wrote: > If you want to reproduce the crash, you can use a very small concept > application i submitted to the original bug report upstream. It is a very > easily compiled application that will trigger the bug. > > If the question is about any other software that might trigger this that is > already in the repos i don't know of any from the top of my mind. No, I wanted not to reproduce the crash, but to assess the impact of this bug. If it happens just with your own application, then you should really port it away from QGLWidget. If it happened also with some package from Debian, we would have to fix either that package or Qt. By the way, QGLWidget is provided by Qt OpenGL module, not Qt Widgets, so I am also reassigning this bug. (Qt Widgets module has QOpenGLWidget which is the recommended replacement.) -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983025: libqt5widgets5: Segfault with QGLWidget class. Fixed Upstream
Control: severity -1 important Control: tags -1 - newcomer Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-86582 ¡Hola Alejandro! On Thu, Feb 18, 2021 at 11:59:56AM +0100, Alejandro Lorenzo wrote: > Package: libqt5widgets5 > Version: 5.15.2+dfsg-4 > Severity: critical > Tags: upstream newcomer > Justification: breaks unrelated software > > Dear Maintainer, > > Recently i found a bug in QGLWidget (one of the widgets included in > libqt5widgets5) that creates a segfault. This bug was accepted as upstream > bug 86582 > > (https://bugreports.qt.io/browse/QTBUG-86582) > > It was confirmed and fixed by the Qt people, unfortunately, it has been > committed to the 5.15 LTS branch of their development which is no longer > accessible to the OpenSource licensees > > QGLWidget has been a deprecated Widget for some time now, and many software > changed to QOpenGLWidget alternative, which does not exhibit this problem, > but other pieces of the debian system (e.g. libqtgstreamer; also deprecated > but still in debian repos) uses it. Can you please tell if any applications in Debian repos are affected by this bug? You mentioned libqtgstreamer but it's a library — do you know if there is a concrete application that can be used to reproduce that crash? It is unlikely that we will be able to fix it, provided that upstream patch is not publicly available. So I am downgrading severity to make this bug not block the release of Debian Bullseye. This bug does not satisfy the criteria for critical anyway, because not the whole libqt5widgets5 library is broken, but only a specific use-case of it (which is also a deprecated one). Also I am removing the newcomer tag — newcomers won't have enough knowledge to be able to fix it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Control: tags -1 -patch Hi Pino! On Fri, Mar 05, 2021 at 07:17:24PM +0100, Pino Toscano wrote: > Did you actually check that it fixes the problem for you? > The thing is, in C++ (at least since C++98) the delete operator is > defined to be a no-op for a null pointer, much like free() in C. > Hence, constructs like "if (foo) delete foo;" are essentially doing > null pointer checks twice, and with the same no-op result. > > A possible cause of the crash could be that the item being deleted was > already deleted, and thus there was a stale pointer somewhere. That is > my own speculation though. > > Because of this, I'm inclined to remove the "patch" tag from this bug; > I'd like to hear from Dmitry what he thinks about it (since he already > handled this bug). I agree with you, the patch is probably not going to work. Unfortunately, I did not have time to investigate this properly yet, but I answered some upstream's questions and I hope they will fix it. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-91437 Hi Dennis! On Fri, Feb 26, 2021 at 10:48:43PM +0100, Dennis Filder wrote: > The segfault happens > * both with and without a preexisting configuration, > * only if Orca is running in the same session. Without Orca the > segfault does not happen. > > Reproducer: > . Start Orca > . Start linphone > . If already configured: click "Assistant" (skip otherwise) > . Click "Use a SIP account" > . Enter as Username: a > . Enter as SIP Domain: b > . Enter as Password: c > . Click on "Use". > > [...] > > If you decide to use the attached patch, please put the bugnumber in > the Bug-Debian: field for me. Thanks for your bug and for the patch. As neither you nor me are sure that your patch is the correct fix, I decided to ask upstream before applying it. Let's wait for response on the bug I filed, then there is still time to get the patch included before freeze. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#983560: qdbus: not upgradable: no longer M-A:foreign
Hi Thorsten! On Fri, Feb 26, 2021 at 09:09:50AM +, Thorsten Glaser wrote: > The new qdbus arch:all package is no longer Multi-Arch:foreign, > making it uninstallable on, for example, an amd64 system which > has an i386 package with Depends: qdbus installed. > > Given qdbus 4:4.8.7+dfsg-20 (arch:any) was already M-A:foreign > it should be trivial to add. Ok, I will fix it, but nothing should really depend on qdbus because it's a transitional package. Please also fix your dependencies. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#973659: qtdeclarative5-dev-tools: qmlcachegen segfaults on hppa
On February 9, 2021 11:48:08 PM GMT+03:00, John David Anglin wrote: > Is there a public qtdeclarative repository that can be cloned with > git? Yes: https://code.qt.io/qt/qtdeclarative.git -- Dmitry Shachnev
Bug#973659: qtdeclarative5-dev-tools: qmlcachegen segfaults on hppa
Hi again! On Sat, Feb 06, 2021 at 12:28:42PM -0500, John David Anglin wrote: > There was a crashing bug patch in 5.11.3-4 that was removed in 5.12.2-1. > Code was changed. That's because the relevant code is no longer present in 5.12, see: https://codereview.qt-project.org/c/qt/qtdeclarative/+/254748 Also I checked the test that fails on s390x, and it turned out to be a problem in the test. I submitted a patch for it: https://codereview.qt-project.org/c/qt/qtdeclarative/+/333611 So the code is compatible with big endian, generally speaking. This means issues on hppa are probably related to stack or other hppa specifics, not to endianness. -- Dmitry Shachnev signature.asc Description: PGP signature
