Bug#1062725: 64-bit time_t transition in progress

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 8 Feb 2024 at 13:06, 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.

And any other thing using Qt, be it libraries or not.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1062725: 64-bit time_t transition in progress

[Lisandro Damián Nicanor Pérez Meyer]

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 Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Wed, 13 Dec 2023 at 15:04, Salvo Tomaselli  wrote:
>
> > This is also being used in src:explosive-c4 now and the approach breaks
> > cross compilation. Please stop doing this, we'll have to touch all of
> > these.
> >
> > Still the use case is real and we need a better way to build packages
> > with qmake6. I was talking with Sune and Lisandro on IRC and their
> > consensus seems to have been that qtchooser and QT_SELECT are dead and
> > should not be used for Qt6. They suggested that we add add a new
> > --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
> > have qmake6? While changing QT_SELECT from qt5 to qt6 would be
> > convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
> > no? The qmake6 build system can reuse qmake just like qmake_qt4 and
> > doing it that way immediately makes cross compilation just work (since
> > we already have -qmake6). Lisandro requested naming it qmake6
> > rather than qmake_qt6. Even though this breaks consistency with earlier
> > use in debhelper, the similarity to how upstream calls it more
> > important.
> >
> > Salvo and Alexandre, do you second this?
>
> It would be fine by me, I hope it should be cleaner than how it was to go from
> 4 to 5.

The cleanest way is to use CMake, as it can handle this directly in
code. And I guess qmake will probably not be a thing for Qt 7.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

[Lisandro Damián Nicanor Pérez Meyer]

Hi again,

On Mon, 11 Dec 2023 at 13:20, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
[snip]
> > Can I also get some ack from Qt maintainers such that we can move
> > forward in consensus?
>
>
> +1 from me. qtchooser is no longer supported for Qt >= 6, so going
> this way is just awesome.

Also worth to mention: this is something I should have done myself,
but I currently lack the needed time, so Helmut took over. Many thanks
to Helmut for this.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Mon, 11 Dec 2023 at 12:30, Helmut Grohne  wrote:
>
> Hi,
>
> On Mon, Dec 04, 2023 at 10:58:44AM +0100, Salvo Tomaselli wrote:
> > I use this in my rules when using qt6
> >
> >
> > %:
> > dh $@
> >
> > override_dh_auto_configure:
> > ln -s /usr/bin/qmake6 ./qmake
> > PATH=`pwd`:$(PATH) dh_auto_configure
> >
> > override_dh_auto_clean:
> > $(RM) qmake
> > dh_auto_clean
>
> This is also being used in src:explosive-c4 now and the approach breaks
> cross compilation. Please stop doing this, we'll have to touch all of
> these.
>
> Still the use case is real and we need a better way to build packages
> with qmake6. I was talking with Sune and Lisandro on IRC and their
> consensus seems to have been that qtchooser and QT_SELECT are dead and
> should not be used for Qt6. They suggested that we add add a new
> --buildsystem to debhelper. We already have qmake_qt4 and qmake, why not
> have qmake6? While changing QT_SELECT from qt5 to qt6 would be
> convenient, changing it to "dh $@ --buildsystem qmake6" is easy enough,
> no? The qmake6 build system can reuse qmake just like qmake_qt4 and
> doing it that way immediately makes cross compilation just work (since
> we already have -qmake6). Lisandro requested naming it qmake6
> rather than qmake_qt6. Even though this breaks consistency with earlier
> use in debhelper, the similarity to how upstream calls it more
> important.
>
> Salvo and Alexandre, do you second this?
>
> Can I also get some ack from Qt maintainers such that we can move
> forward in consensus?


+1 from me. qtchooser is no longer supported for Qt >= 6, so going
this way is just awesome.



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1057299: designer-qt6: is libqquickwidget.so part of the interface or an implementation detail?

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Sat, 2 Dec 2023 at 18:45, Helmut Grohne  wrote:
[snip]
> There also is a middle ground. Maybe designer-qt6 is really meant to be
> Multi-Arch: foreign. It is also possible to move libqquickwidget.so to a
> different package (that is not Multi-Arch: foreign) and have
> designer-qt6 depend on that extra package. Then designer-qt6 continues
> to work and Multi-Arch: foreign remains valid on it, but src:phonon must
> then Build-Depends on that new package.
>
> My impression is that the last of options is what really is meant here,
> but it requires restructuring packages and going through NEW. What do
> you think?

I think there is a huge chance that this will be fixed with 6.6, where
we passed some extra variables to let Qt stuff build without requiring
QML stuff. Might need an extra upload of phonon afterwards...

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1053917: libqt5gui5: Segfaults when starting QT application

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 24 Nov 2023 at 09:17, Lisandro Damián Nicanor Pérez Meyer
 wrote:

> Mmm, Gnome uses Wayland nowadays, and the segfault comes form libQt5XcbQpa,
> which is the lib that handles X stuff. It only happens before Gnome
> completely started,so I wonder if we have some race condition on which Qt 
> apps try to use

> X too soon in the process.
>
>
> But let's try this. Try starting your app on log by prepending
> QT_QPA_PLATFORM
>
>
> QT_QPA_PLATFORM=wayland /usr/bin/yourapp
>
>
> Or any other way that ensures that QT_QPA_PLATFORM=wayland is set as
> environment variable before starting the app.

Or try finding a way to start the apps once all the relevant Wayland
stuff is there, as clearly something is guiding Qt apps to use X
instead.

--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1053917: libqt5gui5: Segfaults when starting QT application

[Lisandro Damián Nicanor Pérez Meyer]

tag 1053917 moreinfo

thanks


Hi!


On 14/10/23 05:55, Patrik Svestka wrote:

Package: libqt5gui5
Version: 5.15.8+dfsg-11
Severity: important
X-Debbugs-Cc: patrik.sves...@gmail.com

Dear Maintainer,

* What led up to the situation?
Having CopyQ and KeePassXC QT applications autostarted

* What exactly did you do (or not do) that was effective (or
  ineffective)?
No interaction needed.  Just applications fail to autostart with the 
libQt5XcbQpa.so.5.15.8 segfaulting.  If both the applications are started 
**after** Gnome starts they start normally.



Mmm, Gnome uses Wayland nowadays, and the segfault comes form libQt5XcbQpa,

which is the lib that handles X stuff. It only happens before Gnome 
completely started,


 so I wonder if we have some race condition on which Qt apps try to use 
X too soon


in the process.


But let's try this. Try starting your app on log by prepending 
QT_QPA_PLATFORM



QT_QPA_PLATFORM=wayland /usr/bin/yourapp


Or any other way that ensures that QT_QPA_PLATFORM=wayland is set as 
environment variable before starting the app.

Re: Skanpage crashes due to a dependency error

[Lisandro Damián Nicanor Pérez Meyer]

Hi Alice!

On Tue, 14 Nov 2023 at 03:27, Alice Berg  wrote:
>
> Hello,
>
> There is a bug in skanpage on debian bookworm
> (https://packages.debian.org/bookworm/skanpage). If trying to use OCR
> without having a tesseract language package present (like
> tesseract-ocr-eng), the application crashes when trying to export the
> scan as pdf with the ocr option enabled.
>
> Installing the language package solves the problem. Adding the language
> package as mandatory or optional dependency of the package would solve
> the issue

Is there any chance you can file a bug like described at
https://www.debian.org/Bugs/Reporting.en.html ?

Thanks in advance!


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1030895: qt6-webengine: Enable riscv64 support

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On 21/11/23 06:06, Bo YU wrote:
[snip]

Let's start here again, okay? :)

I just refactor these patches, which should not affect building of 
other architectures except riscv64.


And still we have a 14k+ lines debdiff to apply. My apologies, this is a 
huge NACK. Get it supported by upstream first and then we can talk.

Re: QT ver. 5 vs 6 - vendors/renderers are different

[Lisandro Damián Nicanor Pérez Meyer]

Hi René!

On Sun, 10 Sept 2023 at 18:01,  wrote:
>
> Hi,
>
> I'd like to upgrade the Qt5 to Qt6 on my trixie debian. Unfortunately
> the version 6 is failing to create drawable (see bellow) and crashes.
>
> ERROR:gl_surface_glx_qt.cpp(157)] glXCreatePbuffer failed.
> ERROR:gpu_info_collector.cc(80)] gl::GLContext::CreateOffscreenGLSurface
> failed.
> ERROR:gpu_info_collector.cc(342)] Could not create surface for info
> collection.
>
> The difference between versions:
> Qt5:
> Vendor: NVIDIA Corporation
> Renderer: GeForce GT 240M/PCIe/SSE2
> Version: 3.3.0 NVIDIA 340.108
>
> Qt6:
> Vendor: Mesa
> Renderer: llvmpipe (LLVM 15.0.7, 128 bits)
> Version: 4.5 (Compatibility Profile) Mesa 23.1.6-1
>
> Is there any configuration (at least env. variable) or this is hardcoded
> in the built configuration?? Thanks

I sincerely don't understand where/how the data you are providing
comes from. I would need you to be more verbose.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Lacking dependencies for xcb QPA platform plugin on Debian.

[Lisandro Damián Nicanor Pérez Meyer]

Hi! Seems you sent this email as an HTML one and probaby not to the bug 
tracker, so it only made it to the mailing list.

El miércoles, 13 de septiembre de 2023 20:33:59 -03 i...@tutamail.com escribió:
> Package: libqt6widgets6 
> Version: 6.4.2+dfsg-10
> 
> Dear developers,
> 
> 
> I write you because of an issue around the xcb QPA platform plugin.
> 
> Looking at https://doc.qt.io/qt-5/linux-requirements.html and 
> https://doc.qt.io/qt-6.4/linux-requirements.html for Qt5 and Qt6 
> respectively, 
> I would understand that since xcb QPA "provides the basic functionality 
> needed by Qt GUI and Qt Widgets to run against X11", all its library 
> dependencies should be direct or indirect dependencies of the libraries 
> libqt5gui5 and libqt5widgets5 for Qt5 and qt6-qpa-plugins, libqt6gui6 and 
> libqt6widgets6 for Qt6 respectively.
> 
> However, I had in Debian 12 (and before also in Debian 10) those Qt6 and Qt5 
> libraries installed, while some of the xcb library dependencies were not 
> installed in my system. 
>
> That was the source of an issue with some software app developed with Qt, 
> which
> I could install on my system, but later it did not work (I'll spare you the 
> details for now, unless you ask me for them), since I did not have installed 
> some of those packages like libxcb-cursor0 (Debian 12 issue) or libxcb-util1 
> (Debian 10 issue, although in that case I had installed libxcb-util0, which 
> was
> the stable release, while I needed libxcb-util1, which was testing). And this 
> issue seems to be much more general, as there is this long discussion related 
> to it:
> https://forum.qt.io/topic/93247/qt-qpa-plugin-could-not-load-the-qt-platform-plugin-xcb-in-even-though-it-was-found

No, this is another issue. Let me explain by starting how the support is there. 
I will exemplify it with Qt 5, the logic should also apply to Qt 6.

First of all the package shipping X11 support is libqt5gui5:

```
$ dpkg -L libqt5gui5 | grep -i xcb
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15.10
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-egl-integration.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15
```

The libQt5Gui5.so.5.x.y library loads the libqxcb.so plugin listed above when 
it needs to do X11 rendering. In turn this plugin depends upon:

```
$ objdump -x /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so | grep 
NEEDED
  NEEDED   libQt5XcbQpa.so.5
  NEEDED   libQt5Gui.so.5
  NEEDED   libQt5Core.so.5
  NEEDED   libstdc++.so.6
  NEEDED   libc.so.6
```

And in turn libQt5XcbQpa.so.5:

```
$ objdump -x /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5.15 | grep NEEDED
  NEEDED   libfontconfig.so.1
  NEEDED   libfreetype.so.6
  NEEDED   libQt5Gui.so.5
  NEEDED   libQt5DBus.so.5
  NEEDED   libQt5Core.so.5
  NEEDED   libX11-xcb.so.1
  NEEDED   libxcb-icccm.so.4
  NEEDED   libxcb-image.so.0
  NEEDED   libxcb-shm.so.0
  NEEDED   libxcb-keysyms.so.1
  NEEDED   libxcb-randr.so.0
  NEEDED   libxcb-render-util.so.0
  NEEDED   libxcb-render.so.0
  NEEDED   libxcb-shape.so.0
  NEEDED   libxcb-sync.so.1
  NEEDED   libxcb-xfixes.so.0
  NEEDED   libxcb-xinerama.so.0
  NEEDED   libxcb-xkb.so.1
  NEEDED   libxcb-xinput.so.0
  NEEDED   libxcb.so.1
  NEEDED   libXrender.so.1
  NEEDED   libX11.so.6
  NEEDED   libSM.so.6
  NEEDED   libICE.so.6
  NEEDED   libxkbcommon-x11.so.0
  NEEDED   libxkbcommon.so.0
  NEEDED   libglib-2.0.so.0
  NEEDED   libstdc++.so.6
  NEEDED   libgcc_s.so.1
  NEEDED   libc.so.6
```

These are all the libraries required by the plugin + private library. If 
something else is missing is due to any of those dependencies not bringing in 
others. But no, that's not your problem.

Let's go back to the URL you sent:

https://forum.qt.io/topic/93247/qt-qpa-plugin-could-not-load-the-qt-platform-plugin-xcb-in-even-though-it-was-found

In there you can read:

```
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it 
was found.
```

Note the "even though it was found" last part. That normally means a broken 
installation, like having mixed Qt versions in paths (like, one from the Qt 
installer and one from the system), but could also be do to lack of proper 
support (headless PC and/or no running X, for example).

If this where a bug believe me that Qt would not be part of any Debian stable 
release :-D

Re: Who need to install qt-translation packages?

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El domingo, 17 de septiembre de 2023 04:01:24 -03 c.bu...@posteo.jp escribió:
> Hello,
> 
> I'm upstream maintainer of "backintime" but also interested in Debian
> specific packaging.
> 
> A question came up about dependencies in the context of the Qt
> translations.
> 
> If Qt is installed does it recognize the current systems locale and
> install the translations for it?

Yes and no. Translations _for_ Qt are shipped in either qttranslations5-l10n or 
qt6-translations-l10n.

Note this only ships translations for the strings that come in Qt Widgets by 
default, they will not cover your own application's translations. These you 
need to handle yourself.

> When having a package (e.g. "backintime-qt") using Qt translations
> (only for standard GUI elements like buttons) should this package
> depend on a qt-translation package? "backintime-qt" does directly
> depend on "python3-pyqt5".

More than a dependency they should be a Recommends. The reason is that some 
users might benefit from not installing translations, and Recommends are also 
installed by default on Debian systems.

For your application you normally ship translations in the same binary package 
(same ".deb") unless you have a good reason not to do so, like them taking lots 
of space.

> https://packages.debian.org/unstable/backintime-qt
> 
> Thanks for advice.
> Christian Buhtz


Hope that helps, Lisandro.


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1051326: systemsettings: A lot of icons are just black squares

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El miércoles, 6 de septiembre de 2023 07:15:26 -03 j...@mailb.org escribió:
> Tags: fixed
> 
> turns out the issue was libqt5quick5-gles everything looks correct after 
> installing libqt5quick5
> is there any way to avoid libqt5quick5-gles getting installed on desktops?


The question is: did you manually install any *-gles package yourself? They 
shouldn't be automatically installed, but we had issues like that before. If 
you have any dpkg/apt logs, the better.

Thanks

signature.asc
Description: This is a digitally signed message part.

Bug#1051267: gcompris-qt: Removing libqt5quick5-gles as potential GCompris dependency

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 5 de septiembre de 2023 14:15:32 -03 Johnny Jazeix escribió:
> Le mar. 5 sept. 2023 à 18:55, Lisandro Damián Nicanor Pérez Meyer
>  a écrit :
> >
> > forwarded 1051267 https://bugs.kde.org/show_bug.cgi?id=474095
> > thanks
> >
> > El martes, 5 de septiembre de 2023 12:46:19 -03 Johnny Jazeix escribió:
> > [snip]
> > > Hi,
> > > Thank you for opening the bug and the MR!
> >
> > My pleasure!
> >
> > > this code is used to set the graphicsApi to either Software or OpenGL
> > > (https://doc.qt.io/qt-5/qsgrendererinterface.html#GraphicsApi-enum)
> >
> > Mmm, according to the above:
> >
> > QSGRendererInterface::OpenGL2   OpenGL ES 2.0 or higher
> >
> > gles stands for OpenGL ES, so it should be working...
> >
> > > in
> > > the code 
> > > https://invent.kde.org/education/gcompris/-/blob/master/src/core/main.cpp?ref_type=heads#L292-305.
> >
> > I have the gut feeling that the code would simply work if you remove lines 
> > 299 to 305, ie, only switch to software if required, then let Qt "do the 
> > right thing". Or at leats the default :-D
> >
> 
> The default value is "auto" so it does not go inside any of this code
> and it lets Qt do as it wishes.

That gets even weirder then. It should be working, I don't see anything 
"special" :-/
[snip]
> 
> Thanks for the link and explanation :).

My pleasure!



signature.asc
Description: This is a digitally signed message part.

Bug#1051267: gcompris-qt: Removing libqt5quick5-gles as potential GCompris dependency

[Lisandro Damián Nicanor Pérez Meyer]

forwarded 1051267 https://bugs.kde.org/show_bug.cgi?id=474095
thanks

El martes, 5 de septiembre de 2023 12:46:19 -03 Johnny Jazeix escribió:
[snip] 
> Hi,
> Thank you for opening the bug and the MR!

My pleasure!

> this code is used to set the graphicsApi to either Software or OpenGL
> (https://doc.qt.io/qt-5/qsgrendererinterface.html#GraphicsApi-enum)

Mmm, according to the above:

QSGRendererInterface::OpenGL2   OpenGL ES 2.0 or higher

gles stands for OpenGL ES, so it should be working...

> in
> the code 
> https://invent.kde.org/education/gcompris/-/blob/master/src/core/main.cpp?ref_type=heads#L292-305.

I have the gut feeling that the code would simply work if you remove lines 299 
to 305, ie, only switch to software if required, then let Qt "do the right 
thing". Or at leats the default :-D

> We offered the switch for Desktop that did not have OpenGL, but in the
> issue we have, it works in opengl mode but only without
> libqt5quick5-gles (using software mode is a "degraded" mode). I'm not
> sure what are the differences between libqt5quick5 and
> libqt5quick5-gles to understand what could be different,

The difference is that libqt5[gui quick quickparticles]5-gles are compiled 
against OpenGL ES instead of "Desktop" (normal) OpenGL.

https://en.wikipedia.org/wiki/OpenGL_ES

Sadly on Linux you can't switch the OpenGL implementation at runtime, so one 
needs to compile against OpenGL or OpenGL ES (gles).



signature.asc
Description: This is a digitally signed message part.

Bug#1051267: gcompris-qt: Removing libqt5quick5-gles as potential GCompris dependency

[Lisandro Damián Nicanor Pérez Meyer]

tag 1051267 patch
submitter 1051267 jaz...@gmail.com
forwarded https://bugs.kde.org/show_bug.cgi?id=474095
thanks

I have just created

https://salsa.debian.org/qt-kde-team/extras/gcompris-qt/-/merge_requests/3

in order for the maintainer to take a look at.

@Johny: in CMakeLists.txt:154 I see

set(GRAPHICAL_RENDERER "auto" CACHE STRING "Policy for choosing the renderer 
backend [opengl|software|auto]")

If the code is not doing direct OpenGL calls then maybe it would be good if you 
could take a look, maybe there is a way for this to work on OpenGL-ES and let 
GCompris run on embedded devices without Desktop OpenGL support.

Cheers, Lisandro.

signature.asc
Description: This is a digitally signed message part.

Bug#1051267: gcompris-qt: Removing libqt5quick5-gles as potential GCompris dependency

[Lisandro Damián Nicanor Pérez Meyer]

Source: gcompris-qt
Version: 3.3-1
Severity: normal
X-Debbugs-Cc: jaz...@gmail.com, lisan...@debian.org

As per https://lists.debian.org/debian-qt-kde/2023/09/msg00017.html


Hi,

thank you for your work on packaging GCompris and other applications.

We had a second bug report
(https://invent.kde.org/education/gcompris/-/issues/31 then
https://bugs.kde.org/show_bug.cgi?id=474095) where some images were
not loaded.

Both were due to the fact that the GCompris package
(https://packages.debian.org/fr/sid/gcompris-qt) uses
libqt5quick5-gles instead of libqt5quick5. Both are marked as
compatible as dependency but the former one causes this issue.

Is it possible to mark libqt5quick5-gles as incompatible with GCompris
or do you see other reasons that we cannot do it?

Cheers,

Johnny



-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE=es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: Removing libqt5quick5-gles as potential GCompris dependency

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

Not the GCompris maintainer here, but one of Qt's ones.

El lunes, 4 de septiembre de 2023 14:35:18 -03 Johnny Jazeix escribió:
> Hi,
> 
> thank you for your work on packaging GCompris and other applications.
> 
> We had a second bug report
> (https://invent.kde.org/education/gcompris/-/issues/31 then
> https://bugs.kde.org/show_bug.cgi?id=474095) where some images were
> not loaded.
> 
> Both were due to the fact that the GCompris package
> (https://packages.debian.org/fr/sid/gcompris-qt) uses
> libqt5quick5-gles instead of libqt5quick5. Both are marked as
> compatible as dependency but the former one causes this issue.
>
> Is it possible to mark libqt5quick5-gles as incompatible with GCompris
> or do you see other reasons that we cannot do it?

Maybe GCompris is using Desktop OpenGL calls without using them from Qt? This 
is a totally valid use case, but one we can't automatically detect.

If this is the case:
- Yes, we can fix it by letting GCompris conflict with the GLES-enabled Qt.
- Please do add this information to your README. With Qt 6 this is a situation 
that (if someone steps up to provide the packages) will be even trickier to 
detect. Having it on the README would at least make the situation clear.

And thanks **a lot** for filing the bug. I'll prepare a merge request for the 
package maintainer to check.



signature.asc
Description: This is a digitally signed message part.

Re: Bug#1050313: kde-spectacle: crash because of missing dependencies

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 22 de agosto de 2023 20:34:09 -03 Alexandre Detiste escribió:
> Package: kde-spectacle
> Version: 23.04.2-2
> Severity: important
> 
> 
> specatecle needs "libqt5quickshapes5" & "qml-module-qtquick-shapes" installed.
> 
> without these it will crash:

This boils down to only the QML module.



signature.asc
Description: This is a digitally signed message part.

Re: network managed applet not seeing connections after suspend

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 20 de agosto de 2023 05:44:19 -03 Marc Haber escribió:
> On Sat, Aug 19, 2023 at 04:01:15PM +0200, Dietz Proepper wrote:
> > Am Montag, 14. August 2023, 13:46:52 CEST schrieb Marc Haber:
> > > I am running KDE on an X260. Since the latest updates, after suspending
> > > the machine, network-manager doesn't connect the network again and the
> > > taskbar applet says "no connections found". Logging out of the Plasma
> > > session and logging in again fixes the issue until next suspend.
> > > 
> > > Is anybody else seeing this behavior and has already debugged?
> > 
> > No, but the audio applet exposes funny behaviour here, too (audio sinks are 
> > displayed multiple times after resume or if I reconnect the dock, at least 
> > sometimes).
> > 
> > Restarting plasmashell only (killall plasmashell; plasmashell&) fixes at 
> > least 
> > that issue until next suspend/resume cycle (for me).
> 
> Restarting plasmashell doesn't help here. The nm applet seems to
> reconnect and shows the available connections, but clicking on one
> immediately yields a toast "Connection (name) deactivated" without even
> trying to conect. I didn't know that behavior before.

I have a similar issue... but in my case the connections are established but no 
packet goes out or in.
 
> Logout/Login => network fine.

Same here, but seems that I have less issues with WiFi rather than ethernet...


signature.asc
Description: This is a digitally signed message part.

Re: network managed applet not seeing connections after suspend

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 14 de agosto de 2023 08:46:52 -03 Marc Haber escribió:
> Hi,
> 
> I am running KDE on an X260. Since the latest updates, after suspending
> the machine, network-manager doesn't connect the network again and the
> taskbar applet says "no connections found". Logging out of the Plasma
> session and logging in again fixes the issue until next suspend.
> 
> Is anybody else seeing this behavior and has already debugged?

Mmm, that might bemy issue on my laptop... Does not happens on my desktop. I'll 
try to reproduce.


signature.asc
Description: This is a digitally signed message part.

Bug#1043424: plasma-desktop: Missing dependency on pipewire breaks screen sharing under Wayland

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 10 Aug 2023 at 19:21, Nazar Zhuk  wrote:
>
> On 8/10/23 14:45, Lisandro Damian Nicanor Perez Meyer wrote:
> > I can agree that something in Plasma should depend/recommend xdg-desktop-
> > portal-kde.  But neither KDE+Wayland nor pipewire are defaults for Debian, 
> > so
> > users wanting to use them are expected to do some work. Granted, it would be
> > just awesome if no action would be required, but that is sadly not the case
> > here. I am so downgrading this bug to normal.
>
> KDE is an option you can pick in the installer, which is what I did. It
> shouldn't require a user to know what other dependencies to install
> after with apt. Even if installing plasma-desktop later with apt it
> should have all the dependencies.

Right, but with that you should get X11 by default, not wayland.

> > I would argue that this bug should be retitled to only care about the xdg-
> > desktop-portal-kde package.
>
> xdg-desktop-portal-kde was originally installed. pipewire wasn't.

xdg-d-p-kde: cool! That's pretty good to read!
pipewire: expected, not the default sound subsystem for bookworm.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: kmenueditor segfaults

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 3 Aug 2023 at 15:56, Andreas v. Heydwolff  wrote:
>
> Hi all, just a brief note here -
>
> On bookworm, stock Plasma 5.27.5, Frameworks 5.103.0, Qt 5.15.8, X11,
> running VirtualBox, I created a new entry in kmenuedit by copying the
> application path of the *.desktop entry for starting a virtual machine
> into the command line for the new kmenu entry.
>
> The entry didn't work, for one, but I'm reporting this here because this
> part of the command
>
> #--comment "my-vbox" --startvm "{4b7f7ba2-fa98-43c9-a73b-1d24fbedaf7f}"
>
> caused kmenuedit to segfault when I right clicked on the kmenu entry in
> order to fix it, mostly even taking down plasmashell (which recovers).
> No traceback was created.
>
> I was able to add the entry to the favorites and then to the Desktop. On
> the Desktop right clicking on the file for looking at the "properties"
> also caused a plasmashell segfault. I could, however, open the entry
> with Kate (acutally a link to the kmenu entry), remove the culprit
> (maybe the curly brackets?). Only then could I delete the original entry
> in kmenueditor.
>
> Perhaps the brackets or other parts of the string from above could be
> caught/neutralized somewhere to avoid the crashes. Dunno if this is
> worth a bug report, and if so, where - upstream?

Yes, this is definitely an upstream issue.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)

[Lisandro Damián Nicanor Pérez Meyer]

Hi again!

On Mon, 7 Aug 2023 at 21:19, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Mon, 7 Aug 2023 at 12:45, John Paul Adrian Glaubitz
>  wrote:
> >
> > Source: qt6-base
> > Version: 6.4.2+dfsg-17
> > Severity: normal
> > User: debian-sup...@lists.debian.org
> > Usertags: sh4
> > X-Debbugs-Cc: debian-sup...@lists.debian.org
> >
> > Hello!
> >
> > For some reason, upstream disabled the platform detection for SuperH (sh4) 
> > in
> > src/corelib/global/qprocessordetection.h by simply commenting the 
> > corresponding
> > code out.
> >
> > As demanded by upstream in [1], I will provide a screenshot of Qt running 
> > on SH
> > later this week.
> >
> > Adrian
> >
> > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025823
>
> Yes please, and when you do please CCme, mention me (if you go trough
> a bug report) and/or add me as reviewer.

You are better off sending a patch that also set the byte order,
matching the patch you sent us here.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1043225: qt6-base: Please add patch to re-enable support for SuperH (sh4)

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 7 Aug 2023 at 12:45, John Paul Adrian Glaubitz
 wrote:
>
> Source: qt6-base
> Version: 6.4.2+dfsg-17
> Severity: normal
> User: debian-sup...@lists.debian.org
> Usertags: sh4
> X-Debbugs-Cc: debian-sup...@lists.debian.org
>
> Hello!
>
> For some reason, upstream disabled the platform detection for SuperH (sh4) in
> src/corelib/global/qprocessordetection.h by simply commenting the 
> corresponding
> code out.
>
> As demanded by upstream in [1], I will provide a screenshot of Qt running on 
> SH
> later this week.
>
> Adrian
>
> > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025823

Yes please, and when you do please CCme, mention me (if you go trough
a bug report) and/or add me as reviewer.

Bug#1042709: qt6-base FTCBFS: doesn't build sqlbrowser

[Lisandro Damián Nicanor Pérez Meyer]

tag 1042709 pending
thanks

On Sun, 30 Jul 2023 at 16:43, Helmut Grohne  wrote:
>
> Source: qt6-base
> Version: 6.4.2+dfsg-17
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> Hi,
>
> qt6-base fails to cross build again. This time, it misses building
> sqlbrowser. While fixing it, I noticed that the variable we are passing
> is deprecated and also update it. I'm attaching a patch for your
> convenience.

Thanks a lot for it! I just applied it to our master branch. I plan to
push this as soon as the current version in unstable migrates to
testing.

> Should we also
> s/QT_BUILD_TOOLS_WHEN_CROSSCOMPILING/QT_FORCE_BUILD_TOOLS/ across the
> rest of the qt6 packaging?

We should, although I think there are a handful of packages out of the
whole 30 something submodules.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1042297: qt6-virtualkeyboard: FTBFS: dh_missing: error: missing files, aborting

[Lisandro Damián Nicanor Pérez Meyer]

Version: 6.4.2+dfsg-3

Hi Lucas!

This was actually fixed already in the archive by version -3, so closing.

Thanks for your work, Lisandro.

El miércoles, 26 de julio de 2023 17:14:13 -03 Lucas Nussbaum escribió:
> Source: qt6-virtualkeyboard
> Version: 6.4.2+dfsg-2
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230726 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > # Reproducible builds: remove build paths from .prl files
> > sed -i -e '/^QMAKE_PRL_BUILD_DIR/d' 
> > debian/tmp/usr/lib/x86_64-linux-gnu/libQt6*.prl
> > make[1]: Leaving directory '/<>'
> >dh_install -O--buildsystem=cmake\+ninja
> >dh_installdocs -O--buildsystem=cmake\+ninja
> >dh_installchangelogs -O--buildsystem=cmake\+ninja
> >dh_installsystemduser -O--buildsystem=cmake\+ninja
> >dh_perl -O--buildsystem=cmake\+ninja
> >dh_link -O--buildsystem=cmake\+ninja
> >dh_strip_nondeterminism -O--buildsystem=cmake\+ninja
> >dh_compress -O--buildsystem=cmake\+ninja
> >dh_fixperms -O--buildsystem=cmake\+ninja
> >dh_missing -O--buildsystem=cmake\+ninja
> > dh_missing: warning: 
> > usr/lib/x86_64-linux-gnu/qt6/examples/virtualkeyboard/basic/basic exists in 
> > debian/tmp but is not installed to anywhere 
> > dh_missing: error: missing files, aborting
> > The following debhelper tools have reported what they installed (with 
> > files per package)
> >  * dh_install: libqt6hunspellinputmethod6 (2), libqt6virtualkeyboard6 
> > (2), qml6-module-qtquick-virtualkeyboard (71), qt6-virtualkeyboard-dev 
> > (56), qt6-virtualkeyboard-plugin (1)
> >  * dh_installdocs: libqt6hunspellinputmethod6 (0), 
> > libqt6virtualkeyboard6 (0), qml6-module-qtquick-virtualkeyboard (0), 
> > qt6-virtualkeyboard-dev (0), qt6-virtualkeyboard-plugin (0)
> > If the missing files are installed by another tool, please file a bug 
> > against it.
> > When filing the report, if the tool is not part of debhelper itself, 
> > please reference the
> > "Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
> > for debhelper (10.6.3+).
> >   (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
> > Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
> > when only a subset is built
> > If the omission is intentional or no other helper can take care of this 
> > consider adding the
> > paths to debian/not-installed.
> > 
> > Remember to be careful with paths containing "x86_64-linux-gnu", where 
> > you might need to
> > use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in 
> > debian/not-installed
> > to ensure it works on all architectures (see #961104).
> > make: *** [debian/rules:12: binary] Error 25
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2023/07/26/qt6-virtualkeyboard_6.4.2+dfsg-2_unstable.log
> 
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20230726;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20230726=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please mark it as 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
> 
> 



signature.asc
Description: This is a digitally signed message part.

Re: Bug#1042018: qt6-declarative: FTBFS on hppa - Segmentation fault in /usr/lib/qt6/bin/qsb

[Lisandro Damián Nicanor Pérez Meyer]

reassign 1042018 src:qt6-base 6.4.2+dfsg-1
thanks


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1042018: qt6-declarative: FTBFS on hppa - Segmentation fault in /usr/lib/qt6/bin/qsb

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 28 de julio de 2023 08:52:37 -03 John David Anglin escribió:
> On 2023-07-25 4:29 p.m., Patrick Franz wrote:
> > Due to the lack of resources, it's unlikely we'll even investigate this.
> > However, if you have a patch, I'm happy to apply it.
> The attached change fixes the reported segmentation fault in qsb. The change 
> is to
> src/3rdparty/forkfd/forkfd_linux.c in the qt6-base package. The problem is 
> the system_vforkfd
> routine assumes the stack direction is down, but on hppa the stack grows up. 
> This causes
> the childFn argument to be clobbered on the stack and the segmentation fault.
> 
> With this change to qt6-base, qt6-declarative builds successfully on hppa.  I 
> believe it will also fix the
> qt6-multimedia build as it appears to fail for the same reason.
> 
> Somehow, we need to get this installed in the 3rdparty forkfd source so all 
> packages that use it
> are fixed.
> 
> Regards,
> Dave Anglin

I'll be happy to apply this one.


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults

[Lisandro Damián Nicanor Pérez Meyer]

Hi Helmut!

El miércoles, 26 de julio de 2023 01:44:17 -03 Helmut Grohne escribió:
> Hi Lisandro,
> 
> On Tue, Jul 25, 2023 at 09:23:14PM -0300, Lisandro Damian Nicanor Perez Meyer 
> wrote:
> > As discussed on IRC I am hacking around this in qt6-virtualkeyboard 
> > 6.4.2+dfsg-3 so parallel is at least 2. I personally do not think this is 
> > an 
> > RC bug, but at least we have a way to avoid the FTBFS for the time being.
> 
> Let me clarify my view on this. I see a failure to build from source
> when passing parallel=1 as an RC bug.

To me RC means "not fit for releasing", including "does not build in our 
infra". The fact that using parallel >1 makes it work (we have a workaround) 
and that our infra does not suffers from this bug means, in my point of view, 
that it is not RC. The final result when built in our infra is still a 
perfectly usable piece of software.

> However, I do not see a failure to
> honour the requested parallelity as an important bug. When I request
> parallel=1 and your package successfully performs a parallel build,
> that's not an important bug in my view. There are a number of packages
> in the archive doing this. As long as your workaround does not cause
> random FTBFS (e.g. on slower buildds), I think it adequately addresses
> the issue I raised and I'm happy with you closing the bug.
> 
> Leaving that aside, an unexplained segfault during build is probably
> worth investigation (though not an RC bug either).
> 
> Is this something you can agree to?

Well, a segfault that only happens on certain conditions that are hard to 
replicate (I could not debug it, it only happened for me on sbuild) and come 
from parallelism _are_ important, but complicated to debug. Now at the same 
time I tried a 6.5.1 build with parallel=1 on sbuild (one I have for private 
purposes) and the build worked for me. So this seems to be an upstream bug that 
it is probably fixed by upstream already. At this point I prefer to simply use 
my scarce free time to try and package a newer Qt rather than trying to dig 
more into this issue.

So, I think that, for the time being, keeping the severity in important + 
checking that parallel >= 2 is a good compromise solution. Now if we can 
replicate this in Qt >= 6.5.x then something else is going on and requires 
further checking.

signature.asc
Description: This is a digitally signed message part.

Re: Bug#1041104: qt6-base: CVE-2023-38197

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 17 de julio de 2023 16:25:20 -03 Dmitry Shachnev escribió:
> ¡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.

Problem comes at build time on line 118 on the patch you attached :-/ In fact I 
needed to add a header to make it work in 6.4.2 :-/


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1041104: qt6-base: CVE-2023-38197

[Lisandro Damián Nicanor Pérez Meyer]

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 :-/


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1041300: qt6-base-dev: undeclared file conflict with libqt6opengl6-dev

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 17 de julio de 2023 01:31:04 -03 Helmut Grohne escribió:
> Package: qt6-base-dev
> Version: 6.4.2+dfsg-12
> Severity: serious
> 
> The recent upload makes qt6-base-dev include a fair number of files also
> contained in libqt6opengl6-dev. Is this some kind of packaging mistake?

yeap, somehow forgot to update B+R. On it now.


signature.asc
Description: This is a digitally signed message part.

Bug#1040700: kleopatra: Depends upon pinentry-qt instead of pinentry

[Lisandro Damián Nicanor Pérez Meyer]

Package: kleopatra
Version: 4:22.12.3-1
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi! kleopatra has a direct dependency on pinentry-qt instead of
pinentry. The problem with this is that people wanting to use any other
pinentry fronted are forced to install the Qt version.

The correct solution for this would be to replace the dependency with
pinentry and move pinentry-qt as Recommends, thus giving the Qt version
a chance but allowing users to use any other variant, like the curses or
gtk one.


-- System Information:
Debian Release: 12.0
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kleopatra depends on:
ii  dirmngr  2.2.40-1.1
ii  gnupg2.2.40-1.1
ii  gpgsm2.2.40-1.1
ii  libassuan0   2.5.5-5
ii  libc62.36-9
ii  libgcc-s112.2.0-14
ii  libgpg-error01.46-1
ii  libgpgme11   1.18.0-3+b1
ii  libgpgmepp6  1.18.0-3+b1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1
ii  libkf5codecs55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-22.12]  22.12.3-1
ii  libkf5itemmodels55.103.0-1
ii  libkf5libkleo5 [libkf5libkleo5-22.12]4:22.12.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-22  22.12.3-1
.12]
ii  libkf5mime5abi1 [libkf5mime5-22.12]  22.12.3-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5textwidgets5   5.103.0-1
ii  libkf5widgetsaddons5 5.103.0-1
ii  libkf5windowsystem5  5.103.0-1
ii  libkf5xmlgui55.103.0-1
ii  libqgpgme15  1.18.0-3+b1
ii  libqt5core5a 5.15.8+dfsg-12
ii  libqt5dbus5  5.15.8+dfsg-12
ii  libqt5gui5   5.15.8+dfsg-12
ii  libqt5network5   5.15.8+dfsg-12
ii  libqt5printsupport5  5.15.8+dfsg-12
ii  libqt5widgets5   5.15.8+dfsg-12
ii  libstdc++6   12.2.0-14
ii  paperkey 1.6-1
ii  pinentry-qt  1.2.1-1

Versions of packages kleopatra recommends:
ii  breeze-icon-theme  4:5.103.0-1

kleopatra suggests no packages.

-- no debconf information

Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults

[Lisandro Damián Nicanor Pérez Meyer]

Hi,


On Thu, 6 Jul 2023 at 14:30, Helmut Grohne  wrote:
>
> Source: qt6-virtualkeyboard
> Version: 6.4.2+dfsg-2
> Severity: serious
> Tags: ftbfs
>
> qt6-virtualkeyboard fails to build from source in unstable when passing
> DEB_BUILD_OPTIONS=parallel=1. A build ends as follows:

Interestingly enough I could only reproduce the issue by using sbuild.
If I hand compile it using dpkg-buildpackage directly on a clean
machine things just work.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1038693: qt6-declarative-dev: inappropriately included cmake file

[Lisandro Damián Nicanor Pérez Meyer]

As a workaround passing -DQT_SKIP_AUTO_PLUGIN_INCLUSION=ON solves this issue.

I need to check if we can propagate this variable from qtbase itself.

signature.asc
Description: This is a digitally signed message part.

Bug#1038872: qt6-shadertools-dev: Installs private headers when it shouldn't

[Lisandro Damián Nicanor Pérez Meyer]

Package: qt6-shadertools-dev
Version: 6.4.2-1
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

Hi! I just noticed the package is installing private headers when it
shouldn't.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qt6-shadertools-dev depends on:
ii  libqt6shadertools6  6.4.2-1
ii  qt6-shader-baker6.4.2-1

qt6-shadertools-dev recommends no packages.

qt6-shadertools-dev suggests no packages.

-- no debconf information

Bug#1038693: qt6-declarative-dev: inappropriately included cmake file

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 20 Jun 2023 at 09:42, Oswald Buddenhagen
 wrote:
>
> cmake files are necessary for static builds, because the "plugins"
> aren't actually plugins then. at least i'm assuming that this
> functionality wasn't lost during the cmake port ...
>
> plugins may also be listed as runtime dependencies for deployment.
> theoretically - whether that was actually implemented, i don't know.

Exactly, and these are not expected Debian targets...

> neither of these are immediately relevant for a regular desktop build,
> but you shouldn't be surprised when applications fail to build due to
> formally missing dependencies.

...but we already found a couple of examples on which they way the
CMake files are done you need to install them non the less. So ideally
we shouldn't ship the CMake files, but sometimes there is no way
around it :-/


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 7 Jun 2023 at 20:17, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Wed, 7 Jun 2023 at 14:15, Leonardo Held  wrote:
> >
> >
> > Hello again Lisandro,
> >
> > On 06.06.23 11:40 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > And at that point is where I'll personally say "no". I do not have
> > > enough free time to handle this, and that is in fact the reason I am
> > > maintaining Qt 6 mostly as team member (I am not listed in Uploaders
> > > on purpose).
> > That's completely understandable.
> > > This is specially true if your company uses Debian as a base for the
> > > containers shipped in your products (Leonardo: hint, hint).
> > I'll work a bit on this this week on our private Debian feed and then
> > start helping your team out, hopefully.
>
> Wonderful! I'll be delighted to help as I can!

Extra tip: you can take a look at the Qt 5 gles/* branches in salsa.
You don't need to rebuild **everything**, just the pieces required for
QtGui.

https://salsa.debian.org/qt-kde-team/qt/qtbase/-/tree/gles/master?ref_type=heads

Also feel free to email me.

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 7 Jun 2023 at 14:15, Leonardo Held  wrote:
>
>
> Hello again Lisandro,
>
> On 06.06.23 11:40 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> > And at that point is where I'll personally say "no". I do not have
> > enough free time to handle this, and that is in fact the reason I am
> > maintaining Qt 6 mostly as team member (I am not listed in Uploaders
> > on purpose).
> That's completely understandable.
> > This is specially true if your company uses Debian as a base for the
> > containers shipped in your products (Leonardo: hint, hint).
> I'll work a bit on this this week on our private Debian feed and then
> start helping your team out, hopefully.

Wonderful! I'll be delighted to help as I can!

> Should I keep in touch with your or Patrick Franz (listed as the
> uploader)? Do you guys have an IRC I can jump in to?

Yes, jump in #debian-qt-kde on OFTC. I currently have my bouncer down,
but I hope to have it back soon.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

El martes, 6 de junio de 2023 02:40:09 -03 Erik Inkinen escribió:
> Hi Lisandro,
> 
> I think I misunderstood the Qt documentation myself. It seems the
> dynamic GLES support is only available on Windows, but the changes in
> qt6 rendering would still minimize the requirements for rebuilt
> packages.
> 
> It seems that it is only necessary to rebuild libqt6gui6 with
> "-DINPUT_opengl=es2". Maybe you could make a new source package for
> Qt6 Base on GLES and make it build libqt6gui6 and only it.
> 
> For reference, you can take a look at
> https://github.com/cutie-shell/qt6-base/tree/feature/bookworm/gles_minimal/debian
> . Note that you would need to use a different package name like
> libqt6gui6-gles and it should provide and conflict with libqt6gui6.

And at that point is where I'll personally say "no". I do not have enough free 
time to handle this, and that is in fact the reason I am maintaining Qt 6 
mostly as team member (I am not listed in Uploaders on purpose).

There are at least two options:

1. Jump in to maintain it yourself. I'll be _more_than_happy_ to help as time 
allows it.
2. Find/Hire someone to do it.

This is specially true if your company uses Debian as a base for the containers 
shipped in your products (Leonardo: hint, hint).

Kinds regards, Lisandro.

signature.asc
Description: This is a digitally signed message part.

Re: Checksum error in some packages - found problem

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 24 May 2023 at 14:34, Antonio  wrote:
>
> The mystery was discovered: in subdir "/usr/share/doc/" there are
> symlink of different packages that aim for the same directory:

That explains it. Besides you where using experimental...
My gut feeling is: you might find this and many more issues if you use
experimental. Now if you find them in unstable then you should really
filea bug.

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 30 May 2023 at 17:12, Leonardo Held  wrote:
>
> Package: qt6-base-dev
> Followup-For: Bug #1035985
>
> Dear Maintainer,
>
> please consider bumping the severity level of #1035985, as it makes
> Debian unable to use qt on the many embedded platforms, and the next
> stable will be affected by this for a long time. Is it possible to
> include the `QT_FEATURE_opengles2` flag before the release? I'm
> willingly to send a patch if needed.

I am afraid it was discovered too late in the release process. My plan
is to test it as soon as Bookworm is released and hopefully get a
stable pu update. But I can't promise anything.

Bumping the severity for a feature not discovered in time is a non-go.

Re: Checksum error in some packages

[Lisandro Damián Nicanor Pérez Meyer]

Hi Antonio

El martes, 23 de mayo de 2023 05:55:33 -03 Antonio escribió:
> Hi Lisandro,
> 
> It is a problem related to the packages.
> 
> I give you an example to reproduce the problem on a package, but it 
> applies to everyone else at the end listed.

I can not reproduce any of he issues you mention. I suggest you check your 
system, most probably your hard drive health.

signature.asc
Description: This is a digitally signed message part.

Bug#1034457: libqt5quick5: Qt segfault on amd64

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 23 de mayo de 2023 03:41:43 -03 Julian escribió:
> Hello,
> 
> unfortunately I cannot provide such example code. I am neither an expert on 
> C++ nor on QML. This is why I included the core dump. It looked like all the 
> information needed to debug this was shown in KDevelop and exported to the 
> core dump.

That's totally fine.
 
> What *seems* to cause the issue is when a QML animation is being played and 
> then interrupted. Considering that it takes me up to 20 minutes to reproduce 
> the issue each time, I am not sure how accurate this is though.

Perfect, but you need to file the bug against the application that caused the 
crash and not the library.

signature.asc
Description: This is a digitally signed message part.

Bug#1035986: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damián Nicanor Pérez Meyer]

Hi Erik!

On Fri, 12 May 2023 at 05:51, Erik Inkinen  wrote:
>
> Package: qt6-base
> Severity: normal
>
> Qt5 packages had separate GLES versions packaged in Debian, but on Qt6
> the rendering backend was revamped by Qt so that the same binaries can
> support desktop GL and GLES.
>
> For some reason, the current Debian packaging does not include libGLES
> development headers in Build-Depends. When configuring the build, Qt
> will not be able to enable GLESv2 support. These packages then cannot be
> used to render anything on devices that do not support desktop GL, but
> have GLES support.
>
> I have confirmed that building with GLES packages indeed fixes the errors.

This is an interesting bug, thanks! Sadly it is too late in the
release process to tackle it, but I'll fix it after bookworm's release
and hopefully do a stable update.

Re: Checksum error in some packages

[Lisandro Damián Nicanor Pérez Meyer]

Hi Antonio!

On Tue, 2 May 2023 at 09:30, Antonio  wrote:
>
> Hello,
> can you check these packages?
>
> Periodic debsums return "checksum errors" for these files:
>
> $ debsums -c

This sounds like an issue on your system, except I am missing
something in debsums. But if something went wrong on Debian side it
should have been reported many times already.

Bug#1036564: unblock: qt6-base/6.4.2+dfsg-9

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qt6-b...@packages.debian.org, delta...@debian.org, 
lisan...@debian.org
Control: affects -1 + src:qt6-base

Please unblock package qt6-base

[ Reason ]
Fixes CVE-2023-32762 and CVE-2023-32763. One prevents a crash with SVG
(not related to the one in qtsvg-opensource-src) and the other one
related to a security heade parsing in the network module.

[ Impact ]
Lack of security fixes.

[ Tests ]
Tested by upstream, do not break API/ABI, seems safe.

[ Risks ]
None that I can think of.

[ 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 qt6-base/6.4.2+dfsg-9
diff --git a/debian/changelog b/debian/changelog
index b117abd..85ce31b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+qt6-base (6.4.2+dfsg-9) unstable; urgency=medium
+
+  * Team upload.
+  * Add a patch to fix CVE-2023-32762.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Mon, 22 May 
2023 11:40:45 -0300
+
+qt6-base (6.4.2+dfsg-8) unstable; urgency=medium
+
+  * Team upload.
+  * Add patch for solving CVE-2023-32763.
+  * Refresh patches.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Mon, 22 May 
2023 10:42:21 -0300
+
 qt6-base (6.4.2+dfsg-7) unstable; urgency=medium
 
   [ Patrick Franz ]
diff --git a/debian/patches/armel-noyield.patch 
b/debian/patches/armel-noyield.patch
index 37061fb..74b1ae2 100644
--- a/debian/patches/armel-noyield.patch
+++ b/debian/patches/armel-noyield.patch
@@ -1,8 +1,12 @@
 Description: Don't use yield on CPUs that might not support it
 
+---
+ src/corelib/global/qsimd_p.h |2 ++
+ 1 file changed, 2 insertions(+)
+
 --- a/src/corelib/global/qsimd_p.h
 +++ b/src/corelib/global/qsimd_p.h
-@@ -428,7 +428,9 @@ static inline void qYieldCpu()
+@@ -401,7 +401,9 @@ static inline void qYieldCpu()
   https://stackoverflow.com/a/70076751/134841
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105416
  */
diff --git 
a/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch 
b/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
index 2ab0f5e..bf93bca 100644
--- a/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
+++ b/debian/patches/build_path_embedded_qtbuildinternalsextra_cmake.patch
@@ -9,22 +9,18 @@ and causes reproducibility issues when built in different 
paths.
 
 https://reproducible-builds.org/docs/build-path/
 ---
- cmake/QtBuildInternalsExtra.cmake.in | 3 ---
+ cmake/QtBuildInternalsExtra.cmake.in |3 ---
  1 file changed, 3 deletions(-)
 
-diff --git a/cmake/QtBuildInternalsExtra.cmake.in 
b/cmake/QtBuildInternalsExtra.cmake.in
-index cbd70b1..23b2391 100644
 --- a/cmake/QtBuildInternalsExtra.cmake.in
 +++ b/cmake/QtBuildInternalsExtra.cmake.in
-@@ -53,9 +53,6 @@ endif()
+@@ -75,9 +75,6 @@ endif()
  set(QT_WILL_INSTALL @QT_WILL_INSTALL@ CACHE BOOL
  "Boolean indicating if doing a Qt prefix build (vs non-prefix build)." 
FORCE)
-
+ 
 -set(QT_SOURCE_TREE "@QT_SOURCE_TREE@" CACHE PATH
 -"A path to the source tree of the previously configured QtBase project." 
FORCE)
 -
  # Propagate decision of building tests and examples to other repositories.
  set(QT_BUILD_TESTS @QT_BUILD_TESTS@ CACHE BOOL "Build the testing tree.")
  set(QT_BUILD_EXAMPLES @QT_BUILD_EXAMPLES@ CACHE BOOL "Build Qt examples")
---
-2.35.1
diff --git a/debian/patches/cross.patch b/debian/patches/cross.patch
index 1a7ebd3..239c803 100644
--- a/debian/patches/cross.patch
+++ b/debian/patches/cross.patch
@@ -1,6 +1,11 @@
+---
+ cmake/QtBuildInternals/QtBuildInternalsConfig.cmake |2 --
+ src/tools/configure.cmake   |2 +-
+ 2 files changed, 1 insertion(+), 3 deletions(-)
+
 --- a/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake
 +++ b/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake
-@@ -146,8 +146,6 @@
+@@ -151,8 +151,6 @@ function(qt_build_internals_disable_pkg_
  set(FEATURE_pkg_config "${pkg_config_enabled}" CACHE STRING "Using 
pkg-config")
  if(NOT pkg_config_enabled)
  qt_build_internals_disable_pkg_config()
@@ -11,7 +16,7 @@
  
 --- a/src/tools/configure.cmake
 +++ b/src/tools/configure.cmake
-@@ -2,7 +2,7 @@
+@@ -2,7 +2,7 @@ qt_feature("androiddeployqt" PRIVATE
  SECTION "Deployment"
  LABEL "Android deployment tool"
  PURPOSE "The Android deployment tool automates the process of creating 
Android packages."
diff --git a/debian/patches/cve-2023-32762.diff 
b/debian/patches/cve-2023-32762.diff
new file mode 100644
index 000..92b76fa
--- /dev/null
+++ b/debian/patches/cve-2023-32762.diff
@@ -0,0 +1,15 @@
+---
+ src/network/access/qhsts.cpp |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/src/network/access/qhsts.cpp
 b/s

Bug#1036563: unblock: qt6-svg/6.4.2-2

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qt6-...@packages.debian.org, delta...@debian.org, 
lisan...@debian.org
Control: affects -1 + src:qt6-svg

Please unblock package qt6-svg

[ Reason ]
Fixes CVE-2023-32573.

[ Impact ]
This patch avoids a crash when parsing malformed/crafted SVG files.

[ Tests ]
Done by upstream, it basically makes sures a variable has a default
value.

[ Risks ]
None that I can think of.

[ 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 qt6-svg/6.4.2-2
diff --git a/debian/changelog b/debian/changelog
index 41242b5..78f7594 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+qt6-svg (6.4.2-2) unstable; urgency=medium
+
+  * Team upload.
+  * Add patch to solve CVE-2023-32573.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Mon, 22 May 
2023 10:48:50 -0300
+
 qt6-svg (6.4.2-1) unstable; urgency=medium
 
   [ Patrick Franz ]
diff --git a/debian/patches/cve-2023-32573.diff 
b/debian/patches/cve-2023-32573.diff
new file mode 100644
index 000..750f29e
--- /dev/null
+++ b/debian/patches/cve-2023-32573.diff
@@ -0,0 +1,37 @@
+---
+ src/svg/qsvgfont_p.h|5 ++---
+ src/svg/qsvghandler.cpp |2 +-
+ 2 files changed, 3 insertions(+), 4 deletions(-)
+
+--- a/src/svg/qsvgfont_p.h
 b/src/svg/qsvgfont_p.h
+@@ -38,6 +38,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 );
+@@ -50,9 +51,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_ascent;
+-qreal m_descent;
++qreal m_unitsPerEm = DEFAULT_UNITS_PER_EM;
+ qreal m_horizAdvX;
+ QHash m_glyphs;
+ };
+--- a/src/svg/qsvghandler.cpp
 b/src/svg/qsvghandler.cpp
+@@ -2622,7 +2622,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);
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..71efccf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+# Fixed in 6.5.
+cve-2023-32573.diff

Bug#1036562: unblock: qtbase-opensource-src/5.15.8+dfsg-10

[Lisandro Damián Nicanor Pérez Meyer]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: qtbase-opensource-...@packages.debian.org, mity...@debian.org, 
lisan...@debian.org
Control: affects -1 + src:qtbase-opensource-src

Please unblock package qtbase-opensource-src

[ Reason ]

This upload:
- Fixes CVE-2023-32762 and CVE-2023-32763. One prevents a crash with SVG
  (not related to the one in qtsvg-opensource-src) and the other one
  related to a security heade parsing in the network module.
- Adds a Break/Replaces in order to allow proper handling of systems
  that still had libqtcore4 around (#1035790).
- Backports a patch in order to solve an issue with KWin:
  - https://bugreports.qt.io/browse/QTBUG-98048
  - https://lists.debian.org/debian-kde/2022/11/msg00019.html

[ Impact ]

- Lack of security fixes.
- Breaks the bullseye → bookworm update on some systems.
- Nasty visual effects while drag and dropping.

[ Tests ]

All the patches have been tested by upstream.

The security patches are quite straightforward.
The B/R issue is also straightforward, with a specific Qt4 version
allowing users to keep libqt4 around if necessary.
Drag and dropping just works as expected.

[ Risks ]

Sincerely I don't think there are risks here.

[ 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-10
diff --git a/debian/changelog b/debian/changelog
index 8c172cff..1f5b73f0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+qtbase-opensource-src (5.15.8+dfsg-10) unstable; urgency=medium
+
+  * Add patches to fix CVE-2023-32762 and CVE-2023-32763.
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Mon, 22 May 
2023 11:31:55 -0300
+
+qtbase-opensource-src (5.15.8+dfsg-9) unstable; urgency=medium
+
+  * Backport upstream patch to fix laggy drag-and-drop with KWin. See:
+- https://bugreports.qt.io/browse/QTBUG-98048
+- https://lists.debian.org/debian-kde/2022/11/msg00019.html
+
+ -- Dmitry Shachnev   Sun, 21 May 2023 12:19:31 +0300
+
 qtbase-opensource-src (5.15.8+dfsg-8) unstable; urgency=medium
 
   * Add back Breaks/Replaces for libqtcore4 (closes: #1035790).
diff --git a/debian/patches/CVE-2023-32762.patch 
b/debian/patches/CVE-2023-32762.patch
new file mode 100644
index ..d0deff76
--- /dev/null
+++ b/debian/patches/CVE-2023-32762.patch
@@ -0,0 +1,17 @@
+---
+ src/network/access/qhsts.cpp |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/src/network/access/qhsts.cpp
 b/src/network/access/qhsts.cpp
+@@ -364,8 +364,8 @@ quoted-pair= "\" CHAR
+ bool QHstsHeaderParser::parse(const QList> 
)
+ {
+ for (const auto  : headers) {
+-// We use '==' since header name was already 'trimmed' for us:
+-if (h.first == "Strict-Transport-Security") {
++// We compare directly because header name was already 'trimmed' for 
us:
++if (h.first.compare("Strict-Transport-Security", Qt::CaseInsensitive) 
== 0) {
+ header = h.second;
+ // RFC6797, 8.1:
+ //
diff --git a/debian/patches/cve-2023-32763.diff 
b/debian/patches/cve-2023-32763.diff
new file mode 100644
index ..b74413dc
--- /dev/null
+++ b/debian/patches/cve-2023-32763.diff
@@ -0,0 +1,50 @@
+---
+ src/gui/painting/qfixed_p.h  |9 +
+ src/gui/text/qtextlayout.cpp |9 ++---
+ 2 files changed, 15 insertions(+), 3 deletions(-)
+
+--- a/src/gui/painting/qfixed_p.h
 b/src/gui/painting/qfixed_p.h
+@@ -54,6 +54,7 @@
+ #include 
+ #include "QtCore/qdebug.h"
+ #include "QtCore/qpoint.h"
++#include 
+ #include "QtCore/qsize.h"
+ 
+ QT_BEGIN_NAMESPACE
+@@ -182,6 +183,14 @@ Q_DECL_CONSTEXPR inline bool operator<(i
+ Q_DECL_CONSTEXPR inline bool operator>(const QFixed , int i) { return 
f.value() > i * 64; }
+ Q_DECL_CONSTEXPR inline bool operator>(int i, const QFixed ) { return i * 
64 > f.value(); }
+ 
++inline bool qAddOverflow(QFixed v1, QFixed v2, QFixed *r)
++{
++int val;
++bool result = add_overflow(v1.value(), v2.value(), );
++r->setValue(val);
++return result;
++}
++
+ #ifndef QT_NO_DEBUG_STREAM
+ inline QDebug <<(QDebug , const QFixed )
+ { return dbg << f.toReal(); }
+--- a/src/gui/text/qtextlayout.cpp
 b/src/gui/text/qtextlayout.cpp
+@@ -2150,11 +2150,14 @@ found:
+ eng->maxWidth = qMax(eng->maxWidth, line.textWidth);
+ } else {
+ eng->minWidth = qMax(eng->minWidth, lbh.minw);
+-eng->maxWidth += line.textWidth;
++if (qAddOverflow(eng->maxWidth, line.textWidth, >maxWidth))
++eng->maxWidth = QFIXED_MAX;
+ }
+ 
+-if (line.textWidth > 0 && item < eng->layoutData->items.size())
+-eng->maxWidth += lbh.spaceData.textWidth;
++if 

Bug#1035066: qt6-scxml-dev: Missing file

[Lisandro Damián Nicanor Pérez Meyer]

Hi Christian!

On Fri, 28 Apr 2023 at 14:54, Christian Marillat  wrote:
>
> Package: qt6-scxml-dev
> Version: 6.4.2-1
> Severity: grave
>
> Dear Maintainer,
>
> /usr/lib/x86_64-linux-gnu/cmake/Qt6Scxml/Qt6QScxmlEcmaScriptDataModelPluginTargets-none.cmake
> reference
> ${_IMPORT_PREFIX}/lib/x86_64-linux-gnu/qt6/plugins/scxmldatamodel/libqscxmlecmascriptdatamodel.so
>
> But this file is listed in debian/not-installed and thus missing in
> the packa

I'm afraid Qt 6 changed the behavior with respect some of these files
from Qt 5 and we are catching up. Thanks for the bug.

Would you mind sending the CMake line that triggered this?

Thanks in advance, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 25 Apr 2023 at 17:38, Dmitry Shachnev  wrote:
>
> 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.

Oh, I actually had my mind mostly on the dependencies that are
unsolvable on Debian. But yes, I agree with those.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency

[Lisandro Damián Nicanor Pérez Meyer]

Hi Steve!

El martes, 25 de abril de 2023 12:56:36 -03 Steve Langasek escribió:
> Package: qtbase5-private-dev
> Version: 5.15.8+dfsg-3
> Severity: minor
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu lunar
> 
> 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.

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?

signature.asc
Description: This is a digitally signed message part.

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Lisandro Damián Nicanor Pérez Meyer]

Hi again

And tip: have you noticed that the default web engine for Konqueror is
actually Qt5's webengine?

On Tue, 18 Apr 2023 at 04:30, Bernhard Reiter  wrote:
>
> Hi,
>
> Am Dienstag 18 April 2023 04:55:35 schrieb Lisandro Damián Nicanor Pérez
> Meyer:
> > On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter 
> wrote:
>
> > > Konqueror is advertised as web browser, which means it will (offer to)
> > > open URLs from different sources, e.g. when clicked from emails which
> > > means external URLs and data.
> >
> > Same goes with KMail too :-)
>
> not really, KMail protects against just displaying external HTML
> code from mails, you need to explicitely enable it, e.g. by clicking.

Well, you are supposed to know what you are doing if you open a web browser :-)

> > Whatever uses webengine/webkit/ has the same
> > issue. Well, for as long as they are a pile of embedded code, at least
> > to start with.
>
> Only if they are exposed to unfiltered external data and having active code
> elements enabled like 

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter  wrote:
>
> Hi Lisandro,
>
> thanks for your response!
>
> Am Samstag 15 April 2023 15:15:08 schrieben Sie:
> > On Thu, 13 Apr 2023 at 14:15, Bernhard Reiter 
> > >"qtwebengine-opensource-src No security support upstream and
> > >backports not feasible, only for use on trusted content"
>
> > If we follow that reasoning we shouldn't be shipping Plasma at all, as
> > many things use Qt5's webengine.
>
> Konqueror is advertised as web browser, which means it will (offer to)
> open URLs from different sources, e.g. when clicked from emails which means
> external URLs and data.

Same goes with KMail too :-)

> Other components from plasma may not share the same exposure to outside
> data, and thus would be less vulnerable. It seems that this would warrant
> some more examination.

Whatever uses webengine/webkit/ has the same
issue. Well, for as long as they are a pile of embedded code, at least
to start with.

> If it is true that other components show the same risks, then yes, I'd say
> that we should either get the security situation changed or really do not
> ship those components by default. They may risk systems like
> the dynamic loading of remote objects from java did which would be a problem
> for both Debian and upstream.

Same thing I said when I opposed packaging webengine, you see :-) But
now it is packaged, and here we are :)

> It seems to big a topic for this issue.
> What would be the right place in debian to bring this up?

Debian devel, maybe? But I did ask the same thing years ago. The reply
was "what is the difference with a PDF?" Whatever handles untrusted
code has the same issue. The only difference here is that we can not
really keep track of everything that goes on a web engine, so no
security support, which does not mean we try to apply patches if we
can.

But please feel free to do whatever you think is right. That's your
freedom, and that's good :)

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Lisandro Damián Nicanor Pérez Meyer]

Samuel: do you know if this bug is also applicable to Qt 6?




-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Postpone update

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

I have just uploaded qtbase-opensource-src again, this time with a
fixed patch. It should be accepted in some minutes and you will
probably have the binaries in the mirrors in a few hours. I have
tested the changes myself on my main system and everything looks good,
but please chime if something odd happens.

Thanks for your patience, we are dealing with a a11y (accessibility)
issue when Qt applications are being run as root.

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 12 Apr 2023 at 19:56, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Uups, I wrongly tested this without re enabling the patch, my bad!
> Building and testing again!

Patch tested, everything looks fine! I am now pushing the package to
the archive.

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Lisandro Damián Nicanor Pérez Meyer]

Uups, I wrongly tested this without re enabling the patch, my bad!
Building and testing again!

On Wed, 12 Apr 2023 at 19:50, Samuel Thibault  wrote:
>
> Lisandro Damián Nicanor Pérez Meyer, le mer. 12 avril 2023 19:49:00 -0300, a 
> ecrit:
> > In the meantime I'll be preparing the upload, if everything is OK I'll
> > push to the repo and upload the packages.
>
> Thanks for your patience on this!
>
> Samuel



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Lisandro Damián Nicanor Pérez Meyer]

Hi again,

On Wed, 12 Apr 2023 at 19:19, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi,
>
> On Wed, 12 Apr 2023 at 19:03, Samuel Thibault  wrote:
> >
> > And again it's posing problem. As advised by svuorela on irc, here is a
> > version that defers the trigger. This is probably even safer since
> > that's what is committed upstream for the AT_SPI_BUS_ADDRESS environment
> > variable case.
>
> It makes sense, let me try the patch.

krunner works as expected. I am now waiting for the automatic screen
locker to pop in and check it works as expected too (this were two
symptoms of his issue).

In the meantime I'll be preparing the upload, if everything is OK I'll
push to the repo and upload the packages.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Wed, 12 Apr 2023 at 19:03, Samuel Thibault  wrote:
>
> And again it's posing problem. As advised by svuorela on irc, here is a
> version that defers the trigger. This is probably even safer since
> that's what is committed upstream for the AT_SPI_BUS_ADDRESS environment
> variable case.

It makes sense, let me try the patch.



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 14 de marzo de 2023 12:21:42 -03 Dmitry Shachnev escribió:
> Hi Helge!
[snip] 
> 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.
 
This might probbly be because we have tons of Qt packages installed by 
default, specially QML ones. Examples do not ship all the required 
dependencies, which is probably just fine.

> 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.

ThanksDmitry!

signature.asc
Description: This is a digitally signed message part.

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

[Lisandro Damián Nicanor Pérez Meyer]

Hi Helge!

On Mon, 13 Mar 2023 at 17:58, Helge Deller  wrote:
>
> Hi Lisandro,
>
> On 3/12/23 23:05, Lisandro Damián Nicanor Pérez Meyer wrote:
> > On Sun, 12 Mar 2023 at 19:00, Helge Deller  wrote:
> >>
> >> On 3/12/23 22:40, Lisandro Damián Nicanor Pérez Meyer wrote:
> >>> I'm afraid we had similar problems before. Let's better wait for
> >>> someone to properly test that things are working.
> >>
> >> How should one test?
> >
> > Install
> >
> > https://packages.debian.org/sid/qtquickcontrols5-examples
> >
> > And then run and use, for example:
> >
> > /usr/lib/x86_64-linux-gnu/qt5/examples/quickcontrols/controls/filesystembrowser/filesystembrowser
> >
> > That alone is a good test. Extra points if you use KDE.
>
> Thanks for the instructions.
> I'm usually running my machines as server (build servers) only.
> 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).

Excellent! That's just great!

> I started the quickcontrols-filesystembrowser too (lower mid part of screen), 
> but I assume it
> does not look like what it should?

That might be some other qml module missing, but clearly stuff is
working here. I just noticed the bug was in tree view, but oh well, I
guess we can live with that unless a user files a bug.

I do not have access to the repo right now, but either Dmitry or I
will update the test.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Sun, 12 Mar 2023 at 19:00, Helge Deller  wrote:
>
> On 3/12/23 22:40, Lisandro Damián Nicanor Pérez Meyer wrote:
> > I'm afraid we had similar problems before. Let's better wait for
> > someone to properly test that things are working.
>
> Just out of couriosity:
> Do you know if someone tested on mips, mips64el, mipsel, powerpc, ppc64, 
> riscv64 or s390x ?

I know of people running KDE without issue on all of them except for
mips*. Those are official archs so I'll have to guess it has users and
it works. I know I can be wrong here.

> How should one test?

Install

https://packages.debian.org/sid/qtquickcontrols5-examples

And then run and use, for example:

/usr/lib/x86_64-linux-gnu/qt5/examples/quickcontrols/controls/filesystembrowser/filesystembrowser

That alone is a good test. Extra points if you use KDE.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1030730: qtquickcontrols-opensource-src FTBFS on hppa

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Sun, 12 Mar 2023 at 18:12, Helge Deller  wrote:
[snip]> > But have you checked that the produced package is usable?
>
> I'm not sure any longer if it was me or not.
> So, at least I did not check.
>
> > Does Qt QML engine work on hppa, or there are issues caused by stack
> > growing up?
>
> I can't easily test, as my machines run server builds.
>
> > If you think it works, then I will be happy to disable the tests there.
>
> If you look at the log
> https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src=hppa=5.15.8-2=1675556283=0
> the "qtquickcontrols::Tests_TreeView::test_pressAndHold()" test was the only 
> one which failed,
> same as on the other platforms. So I'd believe it works.

I'm afraid we had similar problems before. Let's better wait for
someone to properly test that things are working.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 patch

Hi!

I have just created 
https://salsa.debian.org/qt-kde-team/qt/qtlocation/-/merge_requests/3

I created a MR because I am not strictly sure we can push this now due to 
freeze.

Apart from that Salsa shows no diff for that MR, which is odd... so I guess one 
will have to compare the branches by hand :-/

signature.asc
Description: This is a digitally signed message part.

Re: Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El jue, 9 de mar. de 2023 18:18, Jon Beniston  escribió:

> Hi,
>
> >> It would be good if the serial NMEA plugin could be added
> (libqtposition_serialnmea.so), so serial port / USB GPS devices can be used
> directly
>
> >I remember looking into this when I've got to package it. Looking at the
> build log [1] I think it needs the Gypsy GPS Daemon, which I understand it
> is not packaged in Debian.
>
> The serial NMEA plugin doesn't need Gypsy GPS Demon. (The plugin is for
> directly accessing serial GPS devices). There is a separate plugin that
> uses
> Gypsy.
>
> It does require the qt serial port package though (libqt5serialport5), and
> I
> can't see being referenced in that build log. Does it need to be added as a
> dependency?



Yes, it is possible. Sadly we won't make it for the bullseye release :-( I
would be more than happy to add that feature as soon as possible

Re: Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El domingo, 5 de marzo de 2023 18:31:03 -03 Jon Beniston escribió:
> Package: libqt5positioning5-plugins
> Version: 5.15.2+dfsg-2
> Severity: wishlist
> X-Debbugs-Cc: j...@beniston.com
> 
> Dear Maintainer,
> 
> It would be good if the serial NMEA plugin could be added 
> (libqtposition_serialnmea.so), so serial port / USB GPS devices can be used 
> directly. (These don't appear to be supported by Geoclue).
> 
> (https://doc.qt.io/qt-5/position-plugin-serialnmea.html)

I remember looking into this when I've got to package it. Looking at the build
log [1] I think it needs the Gypsy GPS Daemon, which I understand it is not
packaged in Debian.


[1] 



signature.asc
Description: This is a digitally signed message part.

Re: Bug#1032512: Unneeded versioned dependency to libx11-xcb1

[Lisandro Damián Nicanor Pérez Meyer]

To the email I just sent I'll add one more thing:

El jueves, 9 de marzo de 2023 15:21:29 -03 Klaus Ethgen escribió:
[snip] 
> But the unneeded versioned dependency is in that package and is against
> the debian policy...

If there is a version there then it comes from the package's shlibs/symbols 
files, ie, totally external to Qt.


signature.asc
Description: This is a digitally signed message part.

Re: Debian Bullseye bpo libqt6svg6-dev broken dependency

[Lisandro Damián Nicanor Pérez Meyer]

Hi Maxime!

El jueves, 2 de marzo de 2023 04:44:38 -03 Maxime G. escribió:
> Hello, there is a broken dependency in backports for QT6:
> 
> Les paquets suivants contiennent des dépendances non satisfaites :
>  libqt6svg6-dev : Dépend: libqt6svg6 (= 6.3.1-2~bpo11+1) mais 6.4.2-1~bpo11+1 
> devra être installé
>   Dépend: libqt6svgwidgets6 (= 6.3.1-2~bpo11+1) mais ne sera 
> pas installé
> E: Impossible de corriger les problèmes, des paquets défectueux sont en mode 
> « garder en l'état ».

Sorry for the late reply, this should have been an email to me or a bug report.

You need to run apt update, Qt 6 on stable has been updated to 6.4.2.

Regards, Lisandro.


signature.asc
Description: This is a digitally signed message part.

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

El lun, 20 de feb. de 2023 04:49, Dmitry Shachnev 
escribió:

> 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.



Exactly, and that's what I'm trying to check

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

¡Hola Dmitry!

On Sun, 19 Feb 2023 at 16:59, Dmitry Shachnev  wrote:
>
> ¡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.

Perhaps not in that way, but they might be interested in such a
solution now that they should be able to cross compile Qt itself.

> 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.


Paths to uic. moc et all.

Helmul: is:

sbuild -host arm64 -sAd unstable some_qt6_app.dsc a good way to test this?

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

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.


signature.asc
Description: This is a digitally signed message part.

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 18 de febrero de 2023 11:04:45 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> El sábado, 11 de febrero de 2023 05:50:07 -03 Dmitry Shachnev escribió:
> > Hi all,
> 
> [snip]
> 
> > 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/
> 
> Trying this right now. What I really need to do is to remember to file a
> proper bug upstream.

Ah, it gets the build architecture path, which is currently OK... 
I do wonder if we could trick upstream to provide a solution that works for 
everyone.


signature.asc
Description: This is a digitally signed message part.

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

El sábado, 11 de febrero de 2023 05:50:07 -03 Dmitry Shachnev escribió:
> Hi all,
[snip] 
> 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/

Trying this right now. What I really need to do is to remember to file a proper 
bug upstream.


signature.asc
Description: This is a digitally signed message part.

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Sat, 11 Feb 2023 at 05:54, Dmitry Shachnev  wrote:
>
> 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

That's an excellent workaround, but shouldn't that path be different?
If so I can open a bug upstream.



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1031078: qt6-speech-dev: library libqtexttospeech_mock.so referenced but not provided

[Lisandro Damián Nicanor Pérez Meyer]

For the sake of completeness, here is the patch that fixes the missing 
find_package() calls.

Feel free to send it upstream, it's so simple it's not even copyrighteable.Description: Adds missing find_package() entries.
 The CMake builds links against Qt;;SerialPort and Qt::Sql on Linux, but never
 calls the relevant find_package() functions.
 .
 This patch simply adds them.
Author: Lisandro Damián Nicanor Pérez Meyer 
Bug-Debian: https://bugs.debian.org/973795
Forwarded: no

--- hyperborg-1.0.orig/node/CMakeLists.txt
+++ hyperborg-1.0/node/CMakeLists.txt
@@ -24,6 +24,8 @@ find_package(Qt6 COMPONENTS Widgets)
 find_package(Qt6 COMPONENTS Xml)
 find_package(Qt6 COMPONENTS Qml)
 find_package(Qt6 COMPONENTS Quick)
+find_package(Qt6 COMPONENTS SerialPort)
+find_package(Qt6 COMPONENTS Sql)
 
 qt_add_executable(hynode WIN32 MACOSX_BUNDLE
 ../common/buffer.cpp ../common/buffer.h


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1031078: marked as done (qt6-speech-dev: library libqtexttospeech_mock.so referenced but not provided)

[Lisandro Damián Nicanor Pérez Meyer]

reopen 1031078
thanks

> Oh, please ignore: I realize now that debhelper does not yet cover Qt6
> and the failure relates to upstream-shipped pre-generated CMakefiles,
> and I (until debhelper is improved) need to override dh_auto_configure
> to call qmake6.
>
> Closing this as a non-bug.

Actually this is a bug, a real bug, so re opening. Turns out that qmake does 
not has the ability to find plugins as CMake does. Debhelper does cover Qt 6 
with CMake, and actually is preferring CMake over qmake, which is the right 
thing to do. debhelper might need to learn about qt6, though.

signature.asc
Description: This is a digitally signed message part.

Re: Bug#1031078: qt6-speech-dev: library libqtexttospeech_mock.so referenced but not provided

[Lisandro Damián Nicanor Pérez Meyer]

Hi Jonas!

El sábado, 11 de febrero de 2023 06:15:04 -03 Jonas Smedegaard escribió:
> Package: qt6-speech-dev
> Version: 6.4.2-2
> Severity: grave
> Justification: renders package unusable
>
> When I try to build a project containing this line:
> 
>   find_package(Qt6 COMPONENTS TextToSpeech REQUIRED)
> 
> The configure fails like this:
> 
> CMake Error at
> /usr/lib/x86_64-linux-gnu/cmake/Qt6TextToSpeech/Qt6QTextToSpeechMockPluginT
> argets.cmake:96 (message): The imported target
> "Qt6::QTextToSpeechMockPlugin" references the file
> 
> 
> "/usr/lib/x86_64-linux-gnu/qt6/plugins/texttospeech/libqtexttospeech_mock.s
> o"
> 
>   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/Qt6TextToSpeech/Qt6QTextToSpeechMockPlugin
> Targets.cmake"
> 
>   but not all the files it references.
> 
> Call Stack (most recent call first):
>  
> /usr/lib/x86_64-linux-gnu/cmake/Qt6TextToSpeech/Qt6QTextToSpeechMockPluginC
> onfig.cmake:61 (include)
> /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtPublicPluginHelpers.cmake:439
> (include)
> /usr/lib/x86_64-linux-gnu/cmake/Qt6TextToSpeech/Qt6TextToSpeechPlugins.cmak
> e:5 (__qt_internal_include_plugin_packages)
> /usr/lib/x86_64-linux-gnu/cmake/Qt6TextToSpeech/Qt6TextToSpeechConfig.cmake
> :133 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167
> (find_package) plugins/speech/CMakeLists.txt:22 (find_package)

First of all, thanks for your bug report. Indeed some CMake files are being 
installed when they shouldn't be there. For the sake of completeness CMake 
files for plugins are used in order for the plugins to be found when packaging 
applications built with CMake, ie, in order to find where the plugin is and 
copy it somewhere else to ship it along the application. This is of course not 
a Debian use case so we remove those .cmake files.
 
> Concretely, the pacakge I try to build is hyperborg, available here:
> https://salsa.debian.org/tinker-team/hyperborg

Also thanks for this. After modifying the packaging (well, creating a chroot 
and removing the relevant .cmake files) I've got to build the package... with 
some modifications.

1. In the file node/CMakelists.txt you will need to add:

find_package(Qt6 COMPONENTS SerialPort) 
find_package(Qt6 COMPONENTS Sql)

around line 27. This is because around line 98 the system wants to link 
against them.

2. This is not strictly necessary but heavily recommended: please add qt6-
base-dev to your build dependencies. It is currently brought in by the other 
dependencies, and will always be there, but it's presence help us a lot to 
track symbols and packages using them.

I'll see to fix qtspeech and upload it ASAP.

Regards, Lisandro.


signature.asc
Description: This is a digitally signed message part.

Bug#1030895: Symbol diffs

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El sáb, 11 de feb. de 2023 09:53, Eric Long  escribió:

> Hi Lisandro,
>
> I changed SymbolsHelper-Confirmed header to "6.4.2 !riscv64" and
> managed to
> generate symbol files without MISSING. Please check if there are any
> errors.
>

Well, that's not the real solution ;-) The idea is that you manage those
symbols. It's not easy at first, but you get used to it.



> As for the upstream: Chromium's Linux build machines uses Debian stable
> (as can
> be seen in their build script [1]), so unless riscv64 makes it to
> Debian's
> release architectures, they are not willing to merge patches for riscv64
> support. Adding Chromium to Debian's riscv64 architecture would be a
> step
> forward ;)
>

Oh, I see. Chicken and egg problem. Ok, in this case we need to go forward
in some way.


> (I'm yet to submit the patch to Debian's chromium package because they
> also
> added patches for ppc64el support, which is similar to our situation. I
> may need
> to manually modify the macro conditions so that they work together)
>

Please do. I'll see to add the patch as soon as possible.


> Cheers,
> Eric
>

Thanks for your work Eric! Whenever I can, and if I do not forget, I'll
show you how to deal with symbols files



> [1]:
>
> https://source.chromium.org/chromium/chromium/src/+/main:build/linux/sysroot_scripts/sysroot-creator-bullseye.sh
>
>

Bug#1030895: Symbol diffs

[Lisandro Damián Nicanor Pérez Meyer]

Hi Eric!

On Fri, 10 Feb 2023 14:36:05 +0800 Eric Long  wrote:
> Attached is the generated symbol diff using pkgkde-symbolshelper.
> 
> Cheers,
> Eric
> 

The problem are these three symbols gone missing:

lisandro@gryffindor:/tmp/tmp.XxK8t7vqRk$ grep MISS * | grep -v optional
+#MISSING: 6.4.2+dfsg-0rc0-2# 
_ZTVSt15_Sp_counted_ptrIPSt6vectorIcSaIcEELN9__gnu_cxx12_Lock_policyE2EE@Base 
6.2.2
+#MISSING: 6.4.2+dfsg-0rc0-2# 
_ZTVSt15_Sp_counted_ptrIPSt6vectorIhSaIhEELN9__gnu_cxx12_Lock_policyE2EE@Base 
6.2.2
+#MISSING: 6.4.2+dfsg-0rc0-2# 
_ZTVSt19_Sp_counted_deleterIPcSt14default_deleteIA_cESaIvELN9__gnu_cxx12_Lock_policyE2EE@Base
 6.2.2

They are entries to the vtable which the compiler is free to generate and they 
should be marked as optional. NOn the less pkgkde-symbolshelper [1] should 
handle them, at very least marking them as not available on RISC-V.

That being said, what are the chances of those patches reaching upstream? I 
guess chrome upstreams would love to have such a patch for RISC-V.

[1] 

See if you can make sense of it, else feel free to contact me again, CCing me.

Kinds regards, Lisandro.


[1] https://qt-kde-team.pages.debian.net/symbolfiles.html


signature.asc
Description: This is a digitally signed message part.

Bug#1030980: Qt6::qmake IMPORTED_LOCATION points to build architecture qmake6

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 9 de febrero de 2023 07:59:43 -03 Helmut Grohne escribió:
> Package: qt6-base-dev
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> Control: affects -1 + src:fcitx-qt5
> 
> 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?

I can try... 


signature.asc
Description: This is a digitally signed message part.

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de febrero de 2023 05:00:07 -03 Michael Cree escribió:
> 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?
> 
> Cheers
> Michael.

The patch has been accepted upstream at commit 
eeb66b99df521c4a32b8eda1d889f615319355a6

So we still need to ship this in Debian until the next Qt release.


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1030546: qt6-base FTBFS on hppa

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 -patch 

El lunes, 6 de febrero de 2023 15:03:41 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> clone 1030546 -1
> reassign -1 src:libzstd 1.5.2+dfsg2-3
> severity -1 important
> retitle -1 libzstd: breaks detection using cmake?
> block 1030546 by -1
> thanks
> 
> El sábado, 4 de febrero de 2023 18:23:34 -03 Helge Deller escribió:
> > Package: qt6-base
> > Tags: patch, ftbfs, hppa
> > Version: 6.4.2+dfsg
> > 
> > The attached patch fixes this qt6-base "build-from-source" (FTBFS) failure
> > on hppa: /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o):
> > relocation R_PARISC_DPREL21L can not be used when making a shared object;
> > recompile with -fPIC
> > 
> > The problem is, that qt6-base suddenly tries to link against the static
> > library of libzstd.a, while in the past it did linked against the shared
> > library:
> > 
> > In current failing build (6.4.2+dfsg-1):
> > -- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required
> > is "1.3") Full log is here:
> > https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.
> > 2% 2Bdfsg-1=1675198832=0
> > 
> > while it worked in the past for qt6-base 6.4.2+dfsg~rc1-1
> > -- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable
> > version "1.5.2", minimum required is "1.3") Full log is here:
> > https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.
> > 2% 2Bdfsg%7Erc1-1=1672201686=0
> > 
> > The attached patch changes  WrapZSTD to prefer the dynamic library.
> 
> the source code between those two versions (and in fact between
> 6.4.2+dfsg~rc1-1 and 6.4.2+dfsg~rc1-2) did not change, so there must be
> something else, external, triggering the change here.
> 
> Look at this, on 6.4.2+dfsg~rc1-1 with libzstd 1.5.2+dfsg-1
> 
> -- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable
> version "1.5.2", minimum required is "1.3")
> 
> But on 6.4.2+dfsg~rc1-2, with 1.5.2+dfsg2-1:
> 
> -- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required
> is "1.3")
> 
> 
> libzstd maintainers: for some reason the libzstd detection changed between
> 1.5.2+dfsg-1 and 1.5.2+dfsg2-1.

Well, the clone failed, but maybe this is not necessary.

If I'm reading the code and the packaging changes correctly the change is that 
zstd changed from generating just pkgconfig files from also generating cmake 
files. In this case the cmake files take precedence, but neither 
zstd::libzstd_shared nor zstd::libzstd_static are being defined, and Helge's 
patch reverses the order, thus changing the default.

I'll open a bug upstream about this, in the meantime I'll create a derivative 
patch that forces using the shared library, ie , being more aggressive so it's 
understood.


signature.asc
Description: This is a digitally signed message part.

Re: Bug#1030546: qt6-base FTBFS on hppa

[Lisandro Damián Nicanor Pérez Meyer]

clone 1030546 -1
reassign -1 src:libzstd 1.5.2+dfsg2-3
severity -1 important
retitle -1 libzstd: breaks detection using cmake?
block 1030546 by -1
thanks

El sábado, 4 de febrero de 2023 18:23:34 -03 Helge Deller escribió:
> Package: qt6-base
> Tags: patch, ftbfs, hppa
> Version: 6.4.2+dfsg
> 
> The attached patch fixes this qt6-base "build-from-source" (FTBFS) failure
> on hppa: /usr/bin/ld: /usr/lib/hppa-linux-gnu/libzstd.a(error_private.o):
> relocation R_PARISC_DPREL21L can not be used when making a shared object;
> recompile with -fPIC
> 
> The problem is, that qt6-base suddenly tries to link against the static
> library of libzstd.a, while in the past it did linked against the shared
> library:
> 
> In current failing build (6.4.2+dfsg-1):
> -- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required
> is "1.3") Full log is here:
> https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.2%
> 2Bdfsg-1=1675198832=0
> 
> while it worked in the past for qt6-base 6.4.2+dfsg~rc1-1
> -- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable
> version "1.5.2", minimum required is "1.3") Full log is here:
> https://buildd.debian.org/status/fetch.php?pkg=qt6-base=hppa=6.4.2%
> 2Bdfsg%7Erc1-1=1672201686=0
> 
> The attached patch changes  WrapZSTD to prefer the dynamic library.

the source code between those two versions (and in fact between
6.4.2+dfsg~rc1-1 and 6.4.2+dfsg~rc1-2) did not change, so there must be
something else, external, triggering the change here.

Look at this, on 6.4.2+dfsg~rc1-1 with libzstd 1.5.2+dfsg-1

-- Found WrapZSTD: /usr/lib/hppa-linux-gnu/libzstd.so (found suitable version 
"1.5.2", minimum required is "1.3")

But on 6.4.2+dfsg~rc1-2, with 1.5.2+dfsg2-1:

-- Found WrapZSTD: 1.5.2 (found suitable version "1.5.2", minimum required is 
"1.3")


libzstd maintainers: for some reason the libzstd detection changed between 
1.5.2+dfsg-1 and 1.5.2+dfsg2-1.

signature.asc
Description: This is a digitally signed message part.

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Lisandro Damián Nicanor Pérez Meyer]

Wonderful, thanks a lot!

El jue, 2 de feb. de 2023 05:00, Michael Cree  escribió:

> 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?
>
> Cheers
> Michael.
>

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Lisandro Damián Nicanor Pérez Meyer]

El miércoles, 1 de febrero de 2023 05:42:30 -03 Michael Cree escribió:
[snip]
> > This really sounds like a patch that should go upstream. Normally such
> > patchs would need to be sent by the creator. Would you mind doing that?
> > Please ping me if you need help here.
> 
> There is already a patch upstream at:
> https://codereview.qt-project.org/c/qt/qtbase/+/437349
> 
> I have taken that and refreshed against Debian 6.4.2+dfsg-1 and
> attach here.
> 
> With that qt6-base 6.4.2+dfsg-1 builds to completion on Alpha.

Oh, and the patch comes from Pino.

Michael, here is one thing you could **really** help us with:



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.


signature.asc
Description: This is a digitally signed message part.

Re: Is 5.27 expected before freeze?

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Sun, 8 Jan 2023 at 18:39, Steven Robbins  wrote:
>
> Hello,
>
> My system is afflicted by the "monitor not enabled after hot-connect" bug 
> [BUG].
> This was previously discussed on Debian lists [DEBIAN].
>
> I have done a bit of debugging and applied a fix locally that simply sets the
> enabled flag to true on each connected display.  This completely resolves the
> issue for my case.  I reported this in the upstream bug report but there was
> no reaction.
>
> However, there was a note in the bug report stating that while no KDE
> developer has been able to reproduce the issue (!) but there was recently a
> "massive multiscreen overhaul" merged into upstream on 2022-12-15.

Indeed, see https://bugs.kde.org/show_bug.cgi?id=450068

>  My
> understanding is that this will be in the 5.27 release.

Exactly. But considering the type of change it wouldn't be strange if
after that something else needs to be changed too. But a much needed
fix non the less.

Bug#1029365: qt6-multimedia: Add Qt6 Quick 3D as build dependency

[Lisandro Damián Nicanor Pérez Meyer]

On Sat, 21 Jan 2023 at 18:06, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> This will add Quick3D spatial audio binaries.

Maybe we can try adding this and pushing to experimental, if we are
lucky it gets in time before the normal freeze.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1029365: qt6-multimedia: Add Qt6 Quick 3D as build dependency

[Lisandro Damián Nicanor Pérez Meyer]

Source: qt6-multimedia
Version: 6.4.2~rc1-2
Severity: normal
X-Debbugs-Cc: lisan...@debian.org

This will add Quick3D spatial audio binaries.


-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1029362: qt6-multimedia: 6.4.2 can make use of a new set of optional dependencies

[Lisandro Damián Nicanor Pérez Meyer]

Source: qt6-multimedia
Version: 6.4.2~rc1-2
Severity: normal
X-Debbugs-Cc: lisan...@debian.org, delta...@debian.org

>From the build log:

-- The following OPTIONAL packages have not been found:

 * Qt6QmlCompilerPlusPrivate
 * Qt6Quick3D (required version >= 6.4.2)
 * AVFoundation
 * MMRendererCore
 * MMRenderer
 * PulseAudio
 * WrapPulseAudio
 * WMF
 * FFmpeg
 * VAAPI

Patrick: I'll try adding them in a branch, and see what happens.


-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.1.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1027894: QAudioOutput crashes on Qt 6 (SIGSEGV)

[Lisandro Damián Nicanor Pérez Meyer]

tag 1027894 pending
thanks

On Sat, 21 Jan 2023 at 12:39, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> reassign 1027894 src:qt6-multimedia 6.4.1-1
> forwarded 1027894 https://bugreports.qt.io/browse/QTBUG-108221
> thanks
>
> Hi! Thanks for the bug report, I'll see if I can fix this then.



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Bug#1027894: QAudioOutput crashes on Qt 6 (SIGSEGV)

[Lisandro Damián Nicanor Pérez Meyer]

reassign 1027894 src:qt6-multimedia 6.4.1-1
forwarded 1027894 https://bugreports.qt.io/browse/QTBUG-108221
thanks

Hi! Thanks for the bug report, I'll see if I can fix this then.

Re: qt6-doc-html

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Thu, 5 Jan 2023 at 17:40, Gudjon I. Gudjonsson  wrote:
>
> Hi list
>
> I am searching for the qt6 sibling to the qt5-doc-html
> but I am unable to find it. Can anyone help me?

We are still not building the Qt 6 documentation, no one had the time
to create them yet I'm afraid.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Re: Debian Package Skanpage should finally be released

[Lisandro Damián Nicanor Pérez Meyer]

Hi Thomas,

Regarding your comments:

> > Dear maintainers,
> >
> > you know that the Debian package skanpage is due for a release for a long 
> > time.
> >
> > Its version should be: 22.12.0-x
> >
> > Please take care as maintainers.

And:

On Wed, 11 Jan 2023 at 10:39, Thomas Florek  wrote:
>
> Dear Maintainers,
>
> It seems to be very difficult to finally release skanpage on Debian.
>  From another trustworthy source well known to you, an out-of-date
> version has been installable for weeks.
> Your behaviour is incomprehensible, especially that you apparently
> prefer not to react to the mails.

1. We are all volunteers and no one is being paid for maintaining this
package. So please do not *demand* that we do something or not. You
can always kindly ask.
2. You can always contribute yourself a merge request updating the
package. This is highly welcomed and has higher chances of getting the
package up to date sooner.
3. You can find more contact info at:

IRC: #debian-kde at oftc.net
Mailing list: debian-...@lists.debian.org

These are listed in our web page, https://qt-kde-team.pages.debian.net/

Regards, Lisandro.

Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 pending

These are indeed implementation-private modules, adding them does not
requires the use of private headers. The fix has been implemented in
commit 5e44bf5ab207edfbe481090e75478a750271a548. I'll be pushing the
package ASAP.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 17 Jan 2023 at 14:15, Rodney Dawes  wrote:
>
> On Tue, 2023-01-17 at 13:43 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Yes, but still not using Qt 6, so no need on our side to create more
> > work for us while not yet there. It would be much much easier if they
> > just used _stable_ API. And that's where we get back to upstream,
> > plugins, etc. Create _stable_ API and everything goes smooth.
>
> Chicken, meet egg.

Yes :-)

> It would be much easier if Qt didn't require using private API to do
> anything useful at this level. But here we are.

Exactly.

> Of course maliit isn't using Qt6 *yet* because in trying to do so, I
> came across this issue already reported in Debian, which I use as my
> main platform, and which has never presented such problem when
> developing these projects before. Had the necessary private development
> files already been available, we wouldn't even be having this
> discussion, and I would already have maliit-framework building on Qt6
> (not least because I'm pretty sure I already did have it building as a
> quick experiment, but when revisiting this yesterday, discovered the
> private portion of qt6-wayland had been removed).


I can offer you two solutions:

1. Come aboard maintaining Qt 6. Once you get a pair of Qt upgrades
and you want to support private headers for the whole of the Qt 6
lifetime, you are welcome to add them and support them.
2. Break the chicken and egg issue by building your own Qt. You can
use the debian packages as a base.

Cheers, Lisandro.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1029098: qt6-wayland: Component WaylandClient requires private Qt6WaylandGlobalPrivate

[Lisandro Damián Nicanor Pérez Meyer]

Probably the "Private" name here is misleading: this might be a
private module but not directly related with public headers (ie, an
implementation detail).

Bug#1013222: Private headers

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Jan 2023 at 13:41, Rodney Dawes  wrote:
>
> And to add to the point, currently the qt6-wayland package is broken in
> Debian, even just trying to find it via CMake, because some of these
> files have been removed. The following error is from simply checking
> for the WaylandClient Qt component via:
>
> find_package(Qt6 6.2 REQUIRED COMPONENTS Core WaylandClient)

Thanks! I just filed a bug for that. Public modules should not require
private headers, not the first time we see this kind of issues.