Re: [Development] BC/SC in patch releases

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 24 de agosto de 2023 13:09:18 -03 Giuseppe D'Angelo via Development 
escribió:
> On 24/08/2023 17:36, Volker Hilsheimer wrote:
> > 
> > On platforms where Qt is a system library, being able to at least launch 
> > your application if the system has a lower patch level than what the binary 
> > was built against sounds nice. But in practice, it’s rolling dice - the 
> > application might work fine; or it might get fatally hit by one of the 
> > not-yet-fixed bugs.
> 
> I'm kind of sceptical that this actually happens in practice. If I 
> distribute a Qt application with the idea that an user can run it using 
> their distribution-provided Qt, I'd just use the same distribution to 
> compile the application to begin with (= the very same version for Qt) 
> or an earlier release of the distribution (= earlier minor version of Qt).
> 
> It seems very unlikely that one would end up building for Qt x.y.z and 
> then have their users on Qt x.y.(w

signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Timeouts on download.qt.io

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 5 Jul 2023 at 17:43, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi,
>
> On Wed, 5 Jul 2023 at 03:40, Christian Stenger  
> wrote:
> >
> > Hi,
> >
> > Having trouble as well - starting with the main page: request -> reply 
> > seems to take almost 5min.
> > Navigation into subfolders has varying results 30s up to 5min (only tried 
> > the snapshots area)
> > Downloading works, but download rates are varying quite a lot while 
> > downloading.
>
> Same here. I only get consistent downloads when my DNS gets a download
> from an african server.

Worth to mention: i tested that like 6 hours ago, then I did not test anymore.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Timeouts on download.qt.io

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Wed, 5 Jul 2023 at 03:40, Christian Stenger  wrote:
>
> Hi,
>
> Having trouble as well - starting with the main page: request -> reply seems 
> to take almost 5min.
> Navigation into subfolders has varying results 30s up to 5min (only tried the 
> snapshots area)
> Downloading works, but download rates are varying quite a lot while 
> downloading.

Same here. I only get consistent downloads when my DNS gets a download
from an african server.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 3 de julio de 2023 11:47:44 -03 Lisandro Damián Nicanor Pérez Meyer 
escribió:
[snip] 
> So far it has worked, but of course I'll have more feedback later on :-)


I just built 5.6.1 as shared libraries and all the ".a" files created are 
libraries and not plugins (the file you mentioned is not even there). So far 
that's just safe.



signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 3 de julio de 2023 10:49:43 -03 Alexandru Croitor escribió:
> 
> > On 3. Jul 2023, at 15:29, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
> > 
> > Hi!
> > 
> > El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió:
> >>> On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer 
> >>>  wrote:
> > [snip]
> >>> I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and 
> >>> QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined.
> >>> 
> >>> If I understand correctly the CMake file for searching for plugins are 
> >>> there because:
> >>> 
> >>> - One needs to find them when doing a static build in order to add them 
> >>> to the final static object.
> >>> - One might use it to find the plugins and copy them when bundling 
> >>> applications.
> >> 
> >> That's right.
> >> 
> >> For static plugins, the loading of plugin Config files and the 
> >> availability of the cmake targets is needed for final linking purposes and 
> >> also at configure time for running qmlimportscanner, and other qml tooling.
> >> For shared plugins, the targets are needed for deployment / bundling 
> >> purposes (so runtime deps).
> >> 
> >> One particular case which I'm not sure if it's used right now, but was 
> >> brought up in various (private) discussions, is creating static qt plugins 
> >> in a shared qt build. 
> >> In a more recent discussion, it was about providing a static plugin 
> >> containing just image assets.
> > 
> > Perfect, so my understanding was more or less correct. So far none of the 
> > above are use cases expected for a distro build.
> > 
> >> Depending on what the plugin is linked to in the end, for example a qt 
> >> tool in another repo, the plugin target would need to exist at build time, 
> >> and thus the config files loaded.
> >> In this case, even a distro would have to load the file. 
> > 
> > And that would be a runtime dependency the tool has on the plugin, which is 
> > just OK. If done properly that plugin will be installed due to packaging 
> > dependencies.
> > 
> 
> I don't think that's a runtime dependency, it's a build time dependency, 
> hence the Config files need to be loaded.
> 
> To summarize the hypothetical case:
> 
> qtbase is shared Qt build, so libQt6Gui.so, etc
> 
> qtbase/src/plugins/icons/libqicons.a is a static qt plugin, even though Qt is 
> a shared build. It belongs to the Gui module.
> 
> qttools/src/tools/designer is an app. It needs to link to libqicons.a at 
> build time. 
> 
> The qttools/src/tools/designer/CMakeLists.txt will refer to it via a CMake 
> Target name e.g Qt6::QIconsPlugin, hence the Qt6IconsPluginConfig.cmake 
> package needs to be found and loaded. 
> That would usually be done automatically via the find_package(Qt6 COMPONENTS 
> Gui) call because the default is to load all plugin config files.

Well, any static file (*.a) created as part of a shared lib build is considered 
a development file, thus packages into qt--dev. In this case qtbase, 
so qt6-base-dev, which will be installed for any submodule requiring to build 
with Qt, so the file will be present.

Now the question is: is the CMake file used to only check for it's presence or 
will designer fail to load the static file?

> I suppose if the automatic loading is disabled, we can be explicit and add a 
> find_package(Qt6 COMPONENTS IconsPlugin) in 
> qttools/src/tools/designer/CMakeLists.txt and it would still work in your 
> distro case.

That would actually be ideal, because it decouples a _real_ build dependency 
with just the fact of checking a plugin is there.
 
> So TLDR, should be safe for your to disable the automatic loading of plugins 
> during a shared Qt distro build atm.

So far it has worked, but of course I'll have more feedback later on :-)


signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El lunes, 3 de julio de 2023 05:26:11 -03 Alexandru Croitor escribió:
> > On 30. Jun 2023, at 20:04, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
[snip]
> > I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and 
> > QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined.
> > 
> > If I understand correctly the CMake file for searching for plugins are 
> > there because:
> > 
> > - One needs to find them when doing a static build in order to add them to 
> > the final static object.
> > - One might use it to find the plugins and copy them when bundling 
> > applications.
> 
> That's right.
> 
> For static plugins, the loading of plugin Config files and the availability 
> of the cmake targets is needed for final linking purposes and also at 
> configure time for running qmlimportscanner, and other qml tooling.
> For shared plugins, the targets are needed for deployment / bundling purposes 
> (so runtime deps).
> 
> One particular case which I'm not sure if it's used right now, but was 
> brought up in various (private) discussions, is creating static qt plugins in 
> a shared qt build. 
> In a more recent discussion, it was about providing a static plugin 
> containing just image assets.

Perfect, so my understanding was more or less correct. So far none of the above 
are use cases expected for a distro build.

> Depending on what the plugin is linked to in the end, for example a qt tool 
> in another repo, the plugin target would need to exist at build time, and 
> thus the config files loaded.
> In this case, even a distro would have to load the file. 

And that would be a runtime dependency the tool has on the plugin, which is 
just OK. If done properly that plugin will be installed due to packaging 
dependencies.

> And there's no infrastructure yet to split loading static / shared plugin 
> Config files.

Nor I think it will be needed, at least in the current status quo.

> > Turns out that both the above use cases make no sense in Qt distro builds 
> > like Debian, **especially** when compiling (in other words, they are not 
> > build time dependencies, just run time dependencies).
> > 
> > So I would __love__ to make those two variables enforced by qtbase itself. 
> > Granted, I could just patch out the required files in qtbase/cmake/ and 
> > check if the variable is defined. If it is, use it, else switch it to ON. 
> > But before going that route I would love to see if there is a more elegant, 
> > upstream-provided or upstream-guided way of doing it, like "send us a patch 
> > to do exactly that an we will take it". In this case please how I should 
> > achieve that, taking into account that I want this to be an opt-out, not an 
> > opt-in as currently is.
> 
> In the context of distros, while it might not make sense to load the plugin 
> config files during a shared library qt build  (aside from the more involved 
> use case above), those are still needed for end user-projects.

But only at runtime, not build time (with the direct-dependency exception I 
mentioned above, but again, that's expected and handled).

Yes, there _might_ be some project that requires finding the plugin... if there 
is one they can easily switch the variable on on that specific case. But on a 
distro they will still need to add the package with the required plugin(s) as a 
build dependency, and normally that's just enough.

As another data point: we in Debian/Ubuntu have been removing plugins' CMake 
files for Qt 5 without a single issue neither for Qt nor all the rest of the  
huge set of applications/libraries using it.

> So we can't skip including the files by default, the decision whether to load 
> the files depends on the intent / where the config files need to be used.
> 
> A possible approach could be to detect if we are doing a qt build, in which 
> case QT_SKIP_AUTO_PLUGIN_INCLUSION would be considered TRUE.
> Because find_package calls are done very early in every cml.txt, we usually 
> detect that it's done for a qt build by checking for the existence of 
> QT_REPO_MODULE_VERSION in .cmake.conf files that are included before the 
> find_package.
>
> Also, because i don't feel safe doing this for all qt builds (there might be 
> other reasons the qt build might want to know about plugin targets in the 
> future, outside the context of distro builds), i would protect such logic 
> behind a new option, something like QT_BUILDING_DISTRO.
> 
> But at that point if distros have to set that, it's the same as setting 
> QT_SKIP_AUTO_PLUGIN_INCLUSION to TRUE themselves.
> 
> And the only gain would be centralising distro-specific behaviors by keeping 
> such logic behind a QT_BUILDING_DISTRO check dire

[Development] Enorcing QT_SKIP_AUTO_[QML_]PLUGIN_INCLUSION

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

I recently noted the CMake variables QT_SKIP_AUTO_PLUGIN_INCLUSION and 
QT_SKIP_AUTO_QML_PLUGIN_INCLUSION, which default to undefined.

If I understand correctly the CMake file for searching for plugins are there 
because:

- One needs to find them when doing a static build in order to add them to the 
final static object.
- One might use it to find the plugins and copy them when bundling applications.

Am I missing some other case here?

Turns out that both the above use cases make no sense in Qt distro builds like 
Debian, **especially** when compiling (in other words, they are not build time 
dependencies, just run time dependencies).

So I would __love__ to make those two variables enforced by qtbase itself. 
Granted, I could just patch out the required files in qtbase/cmake/ and check 
if the variable is defined. If it is, use it, else switch it to ON. But before 
going that route I would love to see if there is a more elegant, 
upstream-provided or upstream-guided way of doing it, like "send us a patch to 
do exactly that an we will take it". In this case please how I should achieve 
that, taking into account that I want this to be an opt-out, not an opt-in as 
currently is.

Kinds regards, Lisandro.

signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Timeouts on download.qt.io

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

I am currently experiencing random timeouts on download.qt.io. Sometimes it 
works fine, sometimes not. The rest of my connections are stable as usual, so 
at least for me it seems a problem on the server side.

signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Timeouts on download.qt.io

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 30 de junio de 2023 14:23:02 -03 Lisandro Damián Nicanor Pérez 
Meyer escribió:
> Hi!
> 
> I am currently experiencing random timeouts on download.qt.io. Sometimes it 
> works fine, sometimes not. The rest of my connections are stable as usual, so 
> at least for me it seems a problem on the server side.

And https://lists.qt-project.org/ seems to be having an SSL issue too, so maybe 
it's all related.


signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Can't get review for more than two years

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 20 Jun 2023 at 02:41, Ilya Fedin  wrote:
>
> Hi,
>
> I have a change[1] I made two years ago. People were adding another
> people to reviewers as no one of them had knowledge to review the
> change. Since some time people has just started ignoring pings. More
> than two years has passed but the change is still there, with no votes
> nor clear explanation of what blocks it. It's the most terrible
> contributing experience I've ever had.
>
> [1] https://codereview.qt-project.org/c/qt/qtbase/+/343628

The patch you proposed has comments and NACKs.

I'll add more info: the problem you are trying to solve **might** be
easily solved by installing xdg-desktop-portal and/or some other
portal like the gtk and kde ones.

My 2c, Lisandro


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unable to use lupdate(qt tools) in yocto sdk due to incorrect paths

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Fri, 2 Jun 2023 at 06:24, arslan.ahmad--- via Development
 wrote:
>
> >  Changing Prefix to be a relative path would then break all qmake builds.
>
> do you see any possible workaround for this?

Switching to CMake should do the trick I guess.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Quick report on loading Qt 5 and 6 in the same process

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 16 de mayo de 2023 16:12:36 -03 Thiago Macieira escribió:
> On Monday, 15 May 2023 21:23:21 PDT Thiago Macieira wrote:
> > We still don't know why this happened because all our attempts
> > to find out why cause the problem to disappear.
> 
> BTW, we found that the user's application was linking against 
> libKF5NetworkManagerQt, not KF6, because they were using an intermediary 
> version of that library, between the addition of the support for Qt 6, but 
> before the library renaming. So when the process was launched in production, 
> it found the system libKF5NetworkManagerQt and that loaded Qt 5.
> 
> Clearly there were more changes than just the QProcess launch and the problem 
> disappearing with any environment variable being set. That "launch in 
> production" was an important part of the symptom that the reported neglected 
> to mention for three days...

I just noticed this patch from Suse which mangles Qt 6 symbols:

https://build.opensuse.org/package/view_file/openSUSE:Factory/qt6-base/0001-Tell-the-truth-about-private-API.patch?expand=1

I still have not yet compared it with the qtbase repo, but...


signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Quick report on loading Qt 5 and 6 in the same process

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 16 de mayo de 2023 16:12:36 -03 Thiago Macieira escribió:
> On Monday, 15 May 2023 21:23:21 PDT Thiago Macieira wrote:
> > We still don't know why this happened because all our attempts
> > to find out why cause the problem to disappear.
> 
> BTW, we found that the user's application was linking against 
> libKF5NetworkManagerQt, not KF6, because they were using an intermediary 
> version of that library, between the addition of the support for Qt 6, but 
> before the library renaming. So when the process was launched in production, 
> it found the system libKF5NetworkManagerQt and that loaded Qt 5.
> 
> Clearly there were more changes than just the QProcess launch and the problem 
> disappearing with any environment variable being set. That "launch in 
> production" was an important part of the symptom that the reported neglected 
> to mention for three days...

Thanks for this Thiago, this might probe helpful in the future.


signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

[Lisandro Damián Nicanor Pérez Meyer]

For the sake of correctness...

On Sat, 6 May 2023 at 12:12, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> - meta-qt6 is still buggy. Note I am not talking about boot2qt but
> just using the Qt 6 layer in a normal Yocto way. Example:
> QTBUG-113372: QT_HOST_PATH not set in SDK.

This last part is my bad. Although maybe a room for improvement, but
considering the current state of afairs, my bad.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 5 May 2023 at 07:19, Ville Voutilainen
 wrote:
>
[snip]
> I don't see any of these as worth breaking embedded users who want new
> Qt versions but don't yet
> have the compilers that can give them these facilities.

Well, my experience with Yocto and Qt 6 has so far been:

- A pain that you can't mix meta-qt5 and meta-qt6. You wouldn't
imagine how that could have helped speed up things. Why? If you want
to try both you need to have separate images for each of them, so
either having two boards or reflashing one for each version. And two
separate Yocto builds.
- meta-qt6 is still buggy. Note I am not talking about boot2qt but
just using the Qt 6 layer in a normal Yocto way. Example:
QTBUG-113372: QT_HOST_PATH not set in SDK.



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] KDE ColorScheme change notifications on DBus

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 25 de abril de 2023 05:20:16 -03 Axel Spoerl via Development 
escribió:
> Good morning,
> 
> this is a call to KDE experts on this line.
> 
> In order to react to KDE color scheme changes, Qt listens to DBus for changes 
> (under more) of the keys
> 
>   *   "ColorScheme" in org.kde.kdeglobals.General
>   *   "widgetStyle" in org.kde.kdeglobals.KDE
> 
> A DBus signal correctly received and processed by Qt would look like that:
> 
> ---snip---
> method return time=1682062165.741561 sender=org.freedesktop.DBus -> 
> destination=:1.87 serial=50 reply_serial=89
> signal time=1682062165.742192 sender=:1.28 -> destination=(null destination) 
> serial=38 path=/org/freedesktop/portal/desktop; 
> interface=org.freedesktop.impl.portal.Settings; member=Setting
> Changed
>   string "org.kde.kdeglobals.General"
>   string "ColorScheme"
>   variant   string "BreezeLight"
> ---snap---
> 
> On some systems, however, none of signals mentioned gets emitted. As a 
> consequence, Qt doesn't notify its applications: 
> https://bugreports.qt.io/browse/QTBUG-103093
> => I fail to reproduce the bug, so I can only assume that it a local 
> configuration issue (e.g. Plasma only installation).
> => OTOH I can't find the spot in the KDE documentaiton, where it is defined 
> how to reliably subscribe to changes of color scheme, widget style and the 
> like.
> 
> Questions:
> a) In which cases are the mentioned DBus emitted or not?
> b) Could you point me at the respective spot in the KDE documentation?

Worth to mention: the same code compiled with Qt 5 just works :-/


signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTBUG-111740 - MIPS DSP or DSPv2 verification needed

[Lisandro Damián Nicanor Pérez Meyer]

El domingo, 5 de marzo de 2023 14:36:55 -03 Thiago Macieira escribió:
> https://bugreports.qt.io/browse/QTBUG-111740
> 
> The reporter is saying that the QString::fromLatin1 function generates 
> corrupt 
> translation when the 8-bit char input is not aligned to 2 bytes (which it 
> doesn't have to be, it's char).
> 
> I don't expect anyone to be able to review and fix the MIPS DSP / DSPv2 code, 
> so the only option here is to disable and delete it, making MIPS use the 
> compiler-generated translation only. But I'd like to get a confirmation from 
> someone who can. I think I see a QEMU MIPS stage in COIN, but please note 
> that 
> DSP and DSPv2 code might be different, so both need to be tested.
> 
> In 2 weeks time, I'll disable the DSP version that didn't get a fix or 
> "cannot 
> reproduce".
> 
> 

Is this easily testable? I have access to MIPS porterbox in Debian.




signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Trying to debug dissapearing mouse on iMX8

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

I would like to debug https://bugreports.qt.io/browse/QTBUG-110080 but
I sincerely have no idea where to start. Is there any debug command I
can use for this? Should I enable something?

Any hints will be highly welcomed.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Creator: how to search for qdoc

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

In Qt Creator qdoc is being searched by assuming that it is in the same 
directory as qmake:

https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/cmake/QtCreatorDocumentation.cmake?h=9.0#n54
 

Now this is totally reasonable, but (there is always one) it kinds of steps 
onto the changes we made in Debian in order to be able to cross build Qt 
applications by the usage of MultiArch [1].

I propose a change: we now have $QT_INSTALL_BINS available. By switching the 
HINT in the line above to it things go as smooth as usual for everyone, 
including our use case, which I hope to clean up and explain hopefully soon [2].

Would that be considered a valid change? Is there any reason why it would be 
preferred to use qmake's base dir instead of QT_INSTALL_BINS?

[1]  between others.
[2] My plan is to find a common ground in which Qt is not really affected by 
this and, at the same time, we keep our delta as small as possible.

Kinds regards, Lisandro.




-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Warnign when building qtbase: -Walloc-size-larger-than

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 6 Feb 2023 at 19:28, Thiago Macieira  wrote:
>
> On Monday, 6 February 2023 11:37:07 PST Thiago Macieira wrote:
> > On Monday, 6 February 2023 11:21:13 PST Lisandro Damián Nicanor Pérez Meyer
[snip]
> > No. It's a false positive. The value that GCC is reporting is also
> > impossible:
> >
> > size_t nSpans = numBuckets >> SpanConstants::SpanShift;
> > spans = new Span[nSpans];
> >
> > numBuckets is a size_t, so shifting it right will shift 7 (SpanShift) zeroes
> > in. That means the maximum value that nSpans could assume is 2^(64-7) - 1.
> >
> > If you multiply that value by sizeof(Span) == 144, that would overflow the
> > size_t though.
>
> Actually, maxNumBuckets is wrong, allowing bucketsForCapacity to overflow. But
> in practice this will only affect you after the QHash has grown to more than
> half the virtual memory size (which can only happen on 32-bit systems today).
>
> Working on a fix right now. Will push soon.

Thanks!

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Warnign when building qtbase: -Walloc-size-larger-than

[Lisandro Damián Nicanor Pérez Meyer]

When building qtbase 6.4.2 on Debian I see:

In member function ‘__ct ’,
inlined from ‘detached’ at 
./obj-x86_64-linux-gnu/include/QtCore/../../../src/corelib/tools/qhash.h:575:20,
inlined from ‘detach’ at 
./obj-x86_64-linux-gnu/include/QtCore/../../../src/corelib/tools/qhash.h:1501:75:
./obj-x86_64-linux-gnu/include/QtCore/../../../src/corelib/tools/qhash.h:559:17:
 warning: argument 1 value ‘18446744073709551615’ exceeds maximum object size 
9223372036854775807 [-Walloc-size-larger-than=]
/usr/include/c++/12/new: In member function ‘detach’:
/usr/include/c++/12/new:128:26: note: in a call to allocation function 
‘operator new []’ declared here
  128 | _GLIBCXX_NODISCARD void* operator new[](std::size_t) _GLIBCXX_THROW 
(std::bad_alloc)

Is this something to be worried about?

signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Help requested: 32-bit and the year 2038

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 31 de enero de 2023 21:31:55 -03 usted escribió:
> El martes, 31 de enero de 2023 20:21:47 -03 Thiago Macieira escribió:
> > On Tuesday, 31 January 2023 15:00:07 PST Thiago Macieira wrote:
> > > As most of you are aware, a signed 32-bit time_t overflows in 2038.
> > > Linux
> > > has recently deployed "time64_t" (by certain values of "recently", as in
> > > 2015, see [1])
> > > 
> > > I don't know if this is an emulation bug. It's likely.
> > 
> > Ah, it looks like the kernel side of this didn't get merged until Linux
> > 5.1
> > (2019), with commit 48166e6ea47d23984f0b481ca199250e1ce0730a. A quick look
> > at QEMU sources shows it did get support for those system calls in 2020.
> > That means that the QEMU in the Ubuntu 20.04 in the CI is probably too old
> > to emulate the system call.
> > 
> > While I will be asking for an update in the infra there, that brings the
> > question up: is it acceptable to require Linux 5.1 or later for 32-bit
> > deployments of Qt? If not for 6.6, when would it be?
> > 
> > If it's not going to be in the near future, I *can* modify the patch to
> > detect that the new system call is not implemented and then fall back to
> > the old one. That would mean that every contended mutex or semaphore will
> > incur two system calls instead of 1 on Linux 5.0 or older (which I find
> > acceptable; just upgrade to regain performance).
> > 
> > Let me know what the community prefers. I don't have an opinion.
> 
> Some data:
> 
> - Debian 10 "buster", currently oldstable, has 5.10.

My apologies, that seems ot be only in special cases. It's bullseye , Debian 
11 and current stable the one shipping a kernel >= 5.1.

signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Help requested: 32-bit and the year 2038

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 31 de enero de 2023 20:21:47 -03 Thiago Macieira escribió:
> On Tuesday, 31 January 2023 15:00:07 PST Thiago Macieira wrote:
> > As most of you are aware, a signed 32-bit time_t overflows in 2038. Linux
> > has recently deployed "time64_t" (by certain values of "recently", as in
> > 2015, see [1])
> > 
> > I don't know if this is an emulation bug. It's likely.
> 
> Ah, it looks like the kernel side of this didn't get merged until Linux 5.1
> (2019), with commit 48166e6ea47d23984f0b481ca199250e1ce0730a. A quick look
> at QEMU sources shows it did get support for those system calls in 2020.
> That means that the QEMU in the Ubuntu 20.04 in the CI is probably too old
> to emulate the system call.
> 
> While I will be asking for an update in the infra there, that brings the
> question up: is it acceptable to require Linux 5.1 or later for 32-bit
> deployments of Qt? If not for 6.6, when would it be?
> 
> If it's not going to be in the near future, I *can* modify the patch to
> detect that the new system call is not implemented and then fall back to
> the old one. That would mean that every contended mutex or semaphore will
> incur two system calls instead of 1 on Linux 5.0 or older (which I find
> acceptable; just upgrade to regain performance).
> 
> Let me know what the community prefers. I don't have an opinion.

Some data:

- Debian 10 "buster", currently oldstable, has 5.10.
- For a Variscite VAR-SOM-MX8M-NANO SoM the [wiki] lists Yocto Zeus as the 
first BSP with a kernel >= 5.1. According to the [Yocto releases] page that's 
behind two LTS releases. And the board is 64-bit capable, but anyways...

I would say Qt 6.6 could easily require a kernel >= 5.1. Of course if someone 
has data saying otherwise...

[wiki] 
[Yocto releases] 

signature.asc
Description: This is a digitally signed message part.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released

[Lisandro Damián Nicanor Pérez Meyer]

On Thu, 8 Sept 2022 at 18:39, Thiago Macieira  wrote:
>
> On Thursday, 8 September 2022 14:30:36 PDT Albert Astals Cid wrote:
> > Oh, sorry for the noise.
>
> No need to apologise. Better to have more a false alarm so we can be sure,
> then allow a problem to linger. More eyes on the problem.

Ditto. Normally that kind of thing ought to be checked when doing the
Debian packaging (the build will fail), but we are all humans and we
might easily confuse something...

We haven't done 5.15.6 yet, of course.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to add (CPU) architecture maintainers

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Wed, 3 Aug 2022 at 12:01, Allan Sandfeld Jensen  wrote:
[snip]
> Yeah most of the architectures except x86_64, aach64, armhf and wasm are all
> effectively unmaintained. I doubt we could find maintainers. The only frequent
> and reliable user I know of of the uncommon archs is Debian, and that is
> basically just compile testing it and opening bugs if it doesnt compile, and
> only for mips*, ppc64 and s390x. I have previously fixed fatal bugs in big
> endian handling, that nobody had reported for years.

Well, for Qt 5 we did have some tests working, but definitely not in
QtBase. For Qt 6 the current maintainer [0] is not yet there. Ideally
we could have them but... man power :-(

On the other hand many endianess issues were catched in Qt 5 times,
and most of that code I believe is still there.

[0] Yep, bus factor too close to 1. Still hat tip to Patrick Franz for the work.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QMediaDevices::videoInputs() and libcamera

[Lisandro Damián Nicanor Pérez Meyer]

Forget that, found the bug:-)

El lun, 13 de jun. de 2022 22:28, Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> escribió:

> tl;dr: Qt (at least 6.2.4) can't find cameras when libcamera is
> installed, as reported in https://bugreports.qt.io/browse/QTBUG-104226
>
> I am bringing the issue here because I want to take a deeper look at
> the issue, and maybe someone here can shed some light before I plunge
> into the code. So, if anyone has a clue and can share it, I'll be happ
> to try and see what can be done.
>
> Thanks!
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> https://perezmeyer.com.ar/
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QMediaDevices::videoInputs() and libcamera

[Lisandro Damián Nicanor Pérez Meyer]

tl;dr: Qt (at least 6.2.4) can't find cameras when libcamera is
installed, as reported in https://bugreports.qt.io/browse/QTBUG-104226

I am bringing the issue here because I want to take a deeper look at
the issue, and maybe someone here can shed some light before I plunge
into the code. So, if anyone has a clue and can share it, I'll be happ
to try and see what can be done.

Thanks!

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Switching to SPDX license expressions

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 23 May 2022 at 19:12, Aleix Pol  wrote:
>
> On Mon, May 23, 2022 at 9:24 AM Jörg Bornemann  wrote:
> >
> > Hi,
> >
> > just a heads-up, because we never announced this on this mailing list:
> > we're in the process of switching Qt sources from traditional license
> > headers to much more concise SPDX license expressions.
> >
> > Longer story here: https://www.qt.io/blog/switching-to-spdx

I'll try to participate in the summit slot for this. Maybe we can
reuse Debian's DEP5 files?
And webengine is... a pain. But I guess you know that already.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Linker script / symbols versions for private entries in Qt 6, regression from Qt 5?

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 19 Apr 2022 at 10:32, Kevin Kofler via Development
 wrote:
>
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > The only patch I found is
> >
> > https://build.opensuse.org/package/view_file/KDE:Qt:6.2/qt6-base/0001-Tell-the-truth-about-private-API.patch?expand=1
> >
> > which changes the symbol to have the full major.minor.patch version on
> > it.
>
> FYI, Fedora also carries that patch:
> https://src.fedoraproject.org/rpms/qt6-qtbase/blob/rawhide/f/qtbase-tell-truth-about-private-api.patch
> and, as already mentioned, also for Qt 5:
> https://src.fedoraproject.org/rpms/qt5-qtbase/blob/rawhide/f/tell-the-truth-about-private-api.patch

Found the issue and it was definitely on our side. We happen to have a
tool that simplifies symbols handling and a new (for me) feature was
being used.

Sorry for the noise  and thanks for your wisdom!

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Linker script / symbols versions for private entries in Qt 6, regression from Qt 5?

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 19 Apr 2022 at 09:00, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> > > The point of those private APIs is that they change at every new version, 
> > > so
> > > you want to require rebuilding stuff built with private APIs of the wrong
> > > version. If the symbol versioning does not ensure that, it is essentially
> > > useless.
> >
> > Yes and that's very useful for Linux distributions. That patch should be
> > upstreamed and enabled by default... but there should be an opt-out for
> > developers. Those of us who recompile Qt often and do regression testing may
> > need to run code across the version change boundaries without recompiling.
>
> ACK, I'll see what I can do.

The only patch I found is

https://build.opensuse.org/package/view_file/KDE:Qt:6.2/qt6-base/0001-Tell-the-truth-about-private-API.patch?expand=1

which changes the symbol to have the full major.minor.patch version on
it. That and the output of Thiago's eu-readelf makes me think
something is wrong on my side, as the code seems to be there.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Linker script / symbols versions for private entries in Qt 6, regression from Qt 5?

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 18 Apr 2022 at 22:17, Thiago Macieira  wrote:
>
> On Monday, 18 April 2022 16:37:00 PDT Kevin Kofler via Development wrote:
> > Lisandro Damián Nicanor Pérez Meyer wrote:
> > > Sorry, that should have been
> > >
> > > _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6_PRIVATE_API
>
> That's what I have here:
>
> $ eu-readelf --dyn-syms lib/libQt6Widgets.t.so | grep
> _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget
> 11644: 0063bb88114 FUNCGLOBAL DEFAULT   15
> _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@@Qt_6_PRIVATE_API

$ eu-readelf --dyn-syms libQt6Widgets.so | grep
_ZN10QTableViewC2ER17QTableViewPrivateP7QWidget
5503: 0049c000 43 FUNCGLOBAL DEFAULT   13
_ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@@Qt_6

Not marked as private :-/

> Can you confirm that *17QTableViewPrivate* appears in your src/widgets/
> Widgets.version?

At least for 6.2.2 the tarball does not seems to ship that file. If
it's created at build time I would need to build it (just ping, I'll
happily do it).

> > That should really be
> > _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6.3.0_PRIVATE_API
> > (or whatever exact version you are building), as in the openSUSE patch to Qt
> > 5 that Fedora and some other distributions are also carrying.
> >
> > The point of those private APIs is that they change at every new version, so
> > you want to require rebuilding stuff built with private APIs of the wrong
> > version. If the symbol versioning does not ensure that, it is essentially
> > useless.
>
> Yes and that's very useful for Linux distributions. That patch should be
> upstreamed and enabled by default... but there should be an opt-out for
> developers. Those of us who recompile Qt often and do regression testing may
> need to run code across the version change boundaries without recompiling.

ACK, I'll see what I can do.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Linker script / symbols versions for private entries in Qt 6, regression from Qt 5?

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 18 Apr 2022 at 20:38, Kevin Kofler via Development
 wrote:
>
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > Sorry, that should have been
> >
> > _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6_PRIVATE_API
>
> That should really be
> _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6.3.0_PRIVATE_API
> (or whatever exact version you are building), as in the openSUSE patch to Qt
> 5 that Fedora and some other distributions are also carrying.
>
> The point of those private APIs is that they change at every new version, so
> you want to require rebuilding stuff built with private APIs of the wrong
> version. If the symbol versioning does not ensure that, it is essentially
> useless.

Oh, on Qt 5 we did get the same net result just by knowing which
symbols are private. I'll take a look at the OpenSuse patch, thanks
for the pointer!


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Linker script / symbols versions for private entries in Qt 6, regression from Qt 5?

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 18 Apr 2022 at 19:41, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> While reviewing a Qt 6 build I found out that it seems that Qt 6 is
> not adding the right [symbols versioning] to the private symbols as Qt
> 5 used to do... or maybe I'm missing something?
>
> [symbols versioning]
> <https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/c_Using_LD/ldLinker_scripts.html#VERSION_command>
>
> As an example let's take
>
> QTableView::QTableView(QTableViewPrivate&, QWidget*)
>
> aka
>
> _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6 6.1.2
>
> This ought to be marked as
>
> _ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@

Sorry, that should have been

_ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6_PRIVATE_API
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Linker script / symbols versions for private entries in Qt 6, regression from Qt 5?

[Lisandro Damián Nicanor Pérez Meyer]

While reviewing a Qt 6 build I found out that it seems that Qt 6 is
not adding the right [symbols versioning] to the private symbols as Qt
5 used to do... or maybe I'm missing something?

[symbols versioning]
<https://users.informatik.haw-hamburg.de/~krabat/FH-Labor/gnupro/5_GNUPro_Utilities/c_Using_LD/ldLinker_scripts.html#VERSION_command>

As an example let's take

QTableView::QTableView(QTableViewPrivate&, QWidget*)

aka

_ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@Qt_6 6.1.2

This ought to be marked as

_ZN10QTableViewC2ER17QTableViewPrivateP7QWidget@

This is a really important behavior required to be able to easily
track those private symbols and be able to know what really needs to
be rebuilt on distributions, at very least on Debian/Ubuntu.

Is there something I am missing?

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Updating x86 SIMD support in Qt

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 19 Jan 2022 at 14:50, Allan Sandfeld Jensen  wrote:
[snip]
> I have a ~10 year old Phenom II that I use as a media server, it also lacks
> SSE4 (only having AMDs so-called SSE4a). With 3 cores and 4GB of memory it
> runs a modern Qt5 based Linux desktop just fine, even if I don't regularly use
> it as such. So while it is no great loss for me if I needed to replace it with
> a 200€ NUC, it is certainly plausible people have such working old machines. I
> think it is fine to let the default not work on such machines, and let the
> distros that want to support it use v1.

I'm actually replying to this thread using a very alike machine, a
Core 2 Duo T7250 with just ss3, using (almost) latest Plasma and used
as media center, kid's playground, checking email in non office
time...

Keeping the distros able to use whatever baseline is indeed a first
good step, but I'm also thinking about proprietary apps that might be
using tQtC's build for their offerings. We used this very same machine
with Zoom meetings for our kids' school meetings while they couldn't
go to school due to COVID. It proved very useful.

I don't know if the linker capability in using the right library
version can be used in these specific cases, but if somehow it could
be done it would be just wonderful.


-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Do we need version tags in released src packages?

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 13 Aug 2021 at 04:20, Jani Heikkinen  wrote:
>
> Hi!
>
> We are planning to simplify our packaging and releasing scripts and one thing 
> which would simplify our scripts is removal of version tag parsing for src 
> (and example) packages. So the question is if we can remove version tag 
> (-alpha, -beta1 etc) from our src and exmple packages?
>
> In my opinion we don't need those; packages are always released in proper 
> release folder (like 
> https://download.qt.io/development_releases/qt/6.2/6.2.0-beta2/) and so on it 
> should be quite obvious in which pre-release packages belongs to. Official 
> release are already without any version tag so removing those from 
> development releases shouldn't matter either. But does someone disagree and 
> if yes why?

I'm afraid it won't work. There will be a number of users downloading
the wrong tarball. Also having the tag in the tarball means you can
still know what it is in your downloads folder, where you already lost
the version.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Mirror IRC channels on KDE's Matrix Instance

[Lisandro Damián Nicanor Pérez Meyer]

Totally +1.

On Mon, 28 Jun 2021 at 07:53, Cristián Maureira-Fredes
 wrote:
>
> Hello everyone,
>
> Context
> ---
>
> After the "Improve the contributor experience" session at the past Qt
> Contributors Summit, many ideas came out related to an overall
> improvement to the contribution experience, mainly focused on new
> people joining the Qt Project.
>
> One of the topics was Communication,
> from which we (qt project people) discussed together with some KDE folks
> and agreed that bringing the Qt and KDE communities closer was a good
> idea, mainly based on the good experience KDE has currently on the
> platform.
>
> We have a good opportunity to do this via a bridge from our newly
> created Libera.chat IRC channels, to KDE's Matrix Instance.
>
> During the QtCS,
> we tried this out, and mirrored the #qt-cs IRC channel
> to Matrix: https://go.kde.org/matrix/#/#qt-cs:kde.org
> and according to the people that participated in the session the
> experience was nice, and it might be worth to bridge all the other
> #qt-* channels on IRC.
>
> Read more about Matrix: https://matrix.org/
> Read more about KDE's Matrix Instance: https://community.kde.org/Matrix
>
>
> Implications
> 
>
> If you prefer IRC, it's totally fine,
> this change would only imply that you will get more people
> on IRC to interact with.
>
> If you want to move to Matrix completely, this change will enable
> you to stay in touch with folks on the IRC channels.
>
> Permissions work different on Matrix than IRC,
> but with the current list of moderators in the #qt- domain
> we can easily assign permissions to people on the Matrix
> channels accordingly.
>
> Let's keep the discussion of other communication platforms
> outside this thread, while they might be valid, it's
> out of the scope of this proposal.
>
> Question
> 
>
> I would like to ask the Qt Project if you agree or disagree
> with the proposal to mirror all the #qt-* channels from Libera.chat
> to KDE's Matrix Instance.
>
> If we don't have unresolved disagreements, I'd say we can
> proceed with the mirroring Monday next week, but if there are
> concerns, I would prefer to address them first.
>
> Cheers
>
>
>
> --
> Dr. Cristián Maureira-Fredes
> R Manager
>
> The Qt Company GmbH
> Erich-Thilo-Str. 10
> D-12489 Berlin
>
> Geschäftsführer: Mika Pälsi,
> Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development



-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Freenode's IRC

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 19 May 2021 at 12:30, Jason H  wrote:
>
> Aren't all the kids these days moving to Discord?

Discord is not free software, so it does not align well with a free
software project.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Freenode's IRC

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 19 May 2021 at 11:18, Giuseppe D'Angelo via Development
 wrote:
>
> Hi,
>
> Freenode, the network that hosts our IRC communities, is in the middle
> of some important community changes. TL;DR: most of the volunteer staff
> resigned in protest with what looks like a sell-out of the network and
> its user data.
>
>
> You can read some more details here:
>
> https://www.kline.sh/
> https://coevoet.fr/freenode.html
> https://mniip.com/freenode.txt
>
>
> While Freenode won't shut down tomorrow morning, this still raises some
> questions whether Qt wants to keep its community there or move to
> another network.

Personally I would move to aother network.

> (The ex-staff has founded another network, libera,
> where most people are moving.)

*Just to mention* another network that hosts many other communities
there is OFTC. I don't currently have any opinion on whether we should
move to one or the other.

> Who's in charge of the online Qt communities? What's the process to
> decide about this?

Ditto.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Fri, 26 Feb 2021 at 10:24, Kai Köhne  wrote:
> > -Ursprüngliche Nachricht-
> > Von: Development  Im Auftrag von
> > Joerg Bornemann
> > Gesendet: Freitag, 26. Februar 2021 13:36
> > An: Elvis Stansvik 
> > Cc: Macieira, Thiago ; Qt development mailing
> > list 
> > Betreff: Re: [Development] Qt 6 co-installability with Qt 5
> >
> > On 2/24/21 8:54 AM, Elvis Stansvik wrote:
> >
> > > I guess it rules out installing to e.g. a FAT-formatted USB-stick, but
> > > I don't know if that's a thing. Could be considered an edge case and
> > > documented not to work.
> >
> > With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is made
> > if a hard-link cannot be created.
>
> Right, but that is at configure time, this doesn’t help with the online 
> installer.
>
> If we go down this route, we should arguably check in the online installer 
> whether the target folder is on an NTFS partition, and back out if not. One 
> more complication ... :/

Then just rename the binaries, update docs and everything goes smooth ;-)


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 17 Feb 2021 at 13:13, Kai Köhne  wrote:
[snip]
> > In fact the most difficult people to convince are within tqtc. And no, we 
> > have been asking for this change, specifically for qt6,
> > since at very least 2019. And they where no small threads.
>
> That might have less to do with the fact we work for The Qt Company, but more 
> with the fact that a) you ask us to do the work, and b) to maintain it

For (a) I can feel some guilt, but sadly having to get the paycheck
has become more important nowadays :-/ For (b): the renaming, at very
least on Linux (although Homebrew really needs it too), no matter the
source of the binaries, is just the right thing to do.

> Anyhow, now that we've been both venting our frustration a bit: As Joerg 
> already pointed out, I'm completely fine with the patch he has prepared, and 
> certainly do hope that distributions make use of it. I'm just disagreeing 
> with the request that the Qt documentation need also state 'qmake6' 
> everywhere, and that the Qt SDK (as provided by the online installer) needs 
> to contain 'qmake6', too.

Well, it seems we will keep disagreeing for quite some time then :-)

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mié., 17 feb. 2021 05:33, Joerg Bornemann 
escribió:

>
>
> On 2/17/21 12:47 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
>  > Kai: we the maintainers have been asking for the right solution since
> the Qt3 to Qt4 switch.
>
> Obviously not with enough fervor to convince people and in the case of
> Qt6 mch too late in the release process.



In fact the most difficult people to convince are within tqtc. And no, we
have been asking for this change, specifically for qt6, since at very least
2019. And they where no small threads.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Kai.

On Tue, 16 Feb 2021 at 10:34, Kai Köhne  wrote:
[snip]
> To be honest, the whole discussion feels to me that we are being held hostage 
> right now for the fraction of Linux users that cannot use update-alternatives 
> (because they are not administrators). If having different names of tools is 
> such a big problem, why wasn't this addressed by now in Linux itself?

With my maintainer hat on: part of the duty of a maintainer is to
solve issues in the right place. Sometimes is downstreams, in
distributions, and sometimes is directly in the distro.

For this case, as you have seen in other replies, update-alternatives
is just not the right place. And we distribution maintainers have been
trying to solve it at the right place: here, in upstream's code. For
more than a decade now.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 16 Feb 2021 at 11:37, Ville Voutilainen
 wrote:
>
> On Tue, 16 Feb 2021 at 15:35, Kai Köhne  wrote:
> > And again, this is not something limited to Qt. Last time I checked, the 
> > executable to run Python 3 on Windows is python.exe, not python3.exe. On 
> > Debian at least it's python3. This hasn't blocked Python from being 
> > perceived as overall beginner friendly ...
>
> Uh.. that seems like an apples-and-oranges comparison. On linux, it's
> expected and conventional that if you install both
> python 3 and python 2, both are available in the usual PATH, neither
> eclipses the other, and you can cd between python 2
> and python 3 projects and run both, without switching environments or
> alternatives in between.

Exactly, and that's because you have both python2 and python3
executables on path.

> On windows, I don't know what's conventional. In many cases, a
> shortcut is used that launches a command prompt
> with the right environment, and using two versions in the same command
> prompt just isn't done.

And again, exactly. So comparing against Python on Windows is, as you
say, and apples-and-oranges comparison.

> > So, I would stick to qmake as canonical name, also in the documentation. We 
> > can mention that it's sometimes called qmake6 on Linux. But forcing 
> > everyone to change their habit and scripts just for the sake of consistency 
> > with a fraction of the users that use a global installation on Linux, and 
> > do not use update-alternatives, is IMO not a good move.
>
> update-alternatives is a long-term system-wide configuration change.
> Changing PATH is a shorter-term user-specific one. That's how I switch
> between compilers, and I wouldn't dream of using update-alternatives
> to switch between them. Especially not
> on multi-user systems, where it's none of my business to change the
> alternative used for a system compiler
> for other people. I *can't* do an update-alternatives on a build
> server, and I *shouldn't*. That doesn't mean that
> a build server installation couldn't have both qt 5 and qt 6 installed
> in a system-wide location.
>
> Switching between qt 5 and qt 6 via update-alternatives is Just Wrong.
> If our approach requires it, our approach
> is broken.

And in fact we can use python (again) as a good example: let the
user-facing binaries have the major version in them. And this time the
comparison is on Linux, where it belongs.

Kai: we the maintainers have been asking for the right solution since
the Qt3 to Qt4 switch. For a developer having to add the "6" after the
tool, while it might be a change, it will pretty sure be
straightforward. And by doing this we fix the issue not only for this
release but for every major release here upon.

Tip: many Linux users expect qmake6 or some other variant to call
qmake. Now it's time to make it official *and* consistent for
everyone.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 12 Feb 2021 at 06:22, Joerg Bornemann  wrote:
>
> Hi,
>
> here comes an update on the status of co-installability of Qt5 and Qt6.
>
> For the main issue QTBUG-89170, I've created
> https://codereview.qt-project.org/c/qt/qtbase/+/334054
> Package maintainers, please review this patch.
>
> Let me paste parts of the commit message to fill you in what this is about.

great!

>
> Apart from that, we still plan to move the non-user-facing tools to
> libexec. QTBUG-88791 tracks this.
> Patch is here: https://codereview.qt-project.org/c/qt/qtbase/+/331332

Looking at the comments in there: installing to libexec instead of
bindir by default is, in my point of view, a good idea.

Thanks a lot!
-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.1 Feature Freeze is getting closer; your actions is needed

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 15 Jan 2021 at 16:40, Joerg Bornemann  wrote:
>
> On 1/11/21 6:20 PM, Thiago Macieira wrote:
> > On Monday, 11 January 2021 02:45:13 PST Jani Heikkinen wrote:
> >> Qt 6.1 Feature Freeze will be effect at the end of January so there is only
> >> 3 weeks left to implement new features for Qt 6.1!
> >
> > Where's the tool renaming changes in the CMakeLists.txt? It's mandatory for
> > 6.1.
>
> First of all, there has been no agreement on renaming the tools.
> The latest proposal is at https://bugreports.qt.io/browse/QTBUG-89170
>
> Second, it's not a feature.

I disagree, *it's* a feature, a much needed and awaited feature.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 10 Dec 2020 at 13:13, Kai Köhne  wrote:

>
>
> > -Original Message-
> > From: Development  On Behalf Of
> > Thiago Macieira
> > Sent: Thursday, December 10, 2020 3:48 PM
> > To: development@qt-project.org
> > Subject: Re: [Development] Qt 6 co-installability with Qt 5
> >
> > On Wednesday, 9 December 2020 23:24:00 PST Kai Köhne wrote:
> > > Consistency is important, but is it really so that people struggle
> > > with realizing that 'linguist' is 'linguist6' in their local Linux
> installation?
> > >
> > > If this is really a problem we can consider just mentioning both names
> > > in the documentation.
> >
> > We should mention only one: linguist6.
>
> I disagree.
>

I agree with Thiago. Having both Qt 5 and Qt 6 versions installed at the
same time will be a common thing for most users, and we will receive lots
of "bugs" due to that. The documentation then need to call the right tool.
And yes, I have seen that before lots of times (remember -qt5 in qtchooser?)

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 8 Dec 2020 at 10:51, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
[snip]
> We do that already, it's just not enough for user-facing applications. I'll 
> be more verbose on the bug report if needed.

The problem of options 2 and 3 are that they do not talk about
documentation. Documentation should call user-facing tools with the 6
prefix too. That also means that it will change in other operative
systems, so symlinks might not be the real cross platform solution.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mar., 8 dic. 2020 08:23, Alexandru Croitor 
escribió:

> Hi,
>
> Please check the following comment on JIRA
>
> https://bugreports.qt.io/browse/QTBUG-89170?focusedCommentId=541242
>
> And whether the proposed "approach 3" suits you.
>
> It seems to work already for Christophe's packages as they commented on
> the issue.
>
> The remaining part would be providing the reference shell script that
> creates the symlinks.
>


We do that already, it's just not enough for user-facing applications. I'll
be more verbose on the bug report if needed.

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El lun., 7 dic. 2020 16:52, Joerg Bornemann 
escribió:

> On 10/27/20 5:34 PM, Thiago Macieira wrote:
>
> > Have we fixed it?
>
> The discussion apparently petered out as everytime this came up - or
> maybe I just missed that we now have consensus on how to name things and
> where to put stuff?
>
> Kai created https://bugreports.qt.io/browse/QTBUG-89170 to track this.
>
> Please make sure that it is sound and suits your needs.
>


If I remember correctly Thiago proposed a QUIP. I just couldn't even start
one because end of year + deadlines under COVID circumstances didn't left
me more time left.

But thanks a lot for the pointer!!!

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How to build 32-bit Qt with Qt6/CMake

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 25 Nov 2020 at 12:23, Thiago Macieira  wrote:
>
> On Wednesday, 25 November 2020 05:16:58 PST Joerg Bornemann wrote:
> > This looks correct so far. A small improvement would be to put all this
> > into a CMake toolchain file and additionally do
> >  set(CMAKE_SYSTEM_NAME Linux)
> >
> > Then you can cross-build with -DCMAKE_TOOLCHAIN_FILE=x86-toolchain.cmake
> >
> > In a perfect world, your distro would have provided this file.
>
> I checked both distros I use and neither does. I suppose CMake itself should
> create the toolchain file for multilib builds on Linux if this is a common
> occurrence, but seems not to be the case.

Just for the record some time ago I've added
/usr/share/cmake/debtoolchainfilegen to cmake (see below). Yes, it's
just a distrospecific thing sadly :-/

$ /usr/share/cmake/debtoolchainfilegen arm64
dpkg-architecture: warning: specified GNU system type
aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
setting a correct CC environment variable
dpkg-architecture: warning: specified GNU system type
aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
setting a correct CC environment variable
# Use it while calling CMake:
#   mkdir build; cd build
#   cmake -DCMAKE_TOOLCHAIN_FILE="/path/to/cmake_toolchain_.cmake" ../
#
set(CMAKE_SYSTEM_NAME "Linux")
set(CMAKE_SYSTEM_PROCESSOR "aarch64")
set(CMAKE_C_COMPILER "aarch64-linux-gnu-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-gnu-g++")
set(PKG_CONFIG_EXECUTABLE "aarch64-linux-gnu-pkg-config")
set(PKGCONFIG_EXECUTABLE "aarch64-linux-gnu-pkg-config")
set(QMAKE_EXECUTABLE "aarch64-linux-gnu-qmake")





-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 13:45, Thiago Macieira  wrote:
>
> On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez >
> > So basically:
> >
> > - Move out of $prefix/bin (and thus out of $PATH) every developer-oriented
> > tool.
> > - Ensure that user-facing applications will be backwards compatible
> > with Qt 5 for all the Qt 6 timeline.
>
> I don't think that will work for qmake6 (see below). I am willing to accept
> this for all other (developer) tools.
>
> As for user-facing, here's the litmus test: the application can be moved out
> of the Qt repositories into one of its own. And then we do exactly that.
> Preferably also removing the use of private API in the process.

That would be simply awesome.

> We've long had the question about translators wanting to install Linguist, but
> the only installation we have of it is the full Qt, which requires a compiler
> to also be present. Instead, we should provide translators with an installable
> Linguist using the Installer Framework for Windows, a macdeployqt bundle in a
> .dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux.
>
> > But then I wonder if designer shouldn't stay on $PATH or not. Because
> > even if it's a developer tool it's one expected to be on $PATH much
> > like Qt Creator. The developer tools that can stay out of $PATH are
> > the ones that can be easily callable from within toolchains (qmake,
> > cmake, etc). But then again we distros could simply make a
> > $prefix/bin/designer6 symlink. Telling our users "just use designer6"
> > it's really not a big deal, even if the docs just say "designer".
>
> That's not an option. The docs must say either:
> a) "run designer6"
> or
> b) "run /bin/designer"

In that case I would prefer (a) because it's situation is almost the
same as the qmake one you describe below.

> > > qmake6 entry point for building qmake-based applications,
> > > situation
> > >
> > >similar to /usr/bin/python (see [1])
> > >
> > > I am not yet 100% convinced it is. This is a build tool after all, and
> > > even changes with minor versions of Qt. I know Linux distributions do
> > > only ship one minor version, but many of our users have to manage
> > > multiple minor versions of Qt as well. And renaming qmake with every
> > > minor version is a no-go.
> > Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> > times. qmake needed to be on path in order to be able to query it for
> > some paths. But if that's no longer the case then yes, it can stay
> > away.
>
> qmake6 needs to be on PATH because that's how we will tell people how to build
> their applications. Telling users to go discover where their Linux
> distributions installed Qt6 is not acceptable, in my point of view.

Agreed, that's why I followed my initial mail comparing it to CMake,
I've just realized it later.

And I think a tool like designer should follow the same path.

> In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm
> in having qmake6 too.
>
> > > qml6   I don't understand why, but I'm told it's necessary
> > >
> > >
> > > It’s a runtime for running qml files without a C++ entry point. But we can
> > > actually decide that this is a developer oriented tool and not have it
> > > linked into /usr/bin.
> > Still a tool that is expected to be called by humans though. And then
> > again we could easily keep a $prefix/bin/qml6 link.
>
> I don't care enough. I'm sure I haven't run this tool in 3 years. I even
> thought "qmlscene" was the one we were supposed to run since 5.0...
>
> I'm just following what has been said in this thread that some people do run
> it.
>
> > > All of those are developer facing tools and shouldn’t be in /usr/bin at
> > > all IMO.
> > And again, they could be easily symlinked with a prefix if needed.
>
> I'd like to come to a consensus so that every installation follows procedure
> and is supported by docs. I'd rather Linux distributions didn't feel the need
> to start adding more symlinks.

Right.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 11:04, Tor Arne Vestbø  wrote:
[snip]
>> qdbus can be called by an app ran by an end-user.
> That sounds like a deployment issue. If the app needs qdbus, it needs to 
> bundle it, or make sure it knows the full path to it (but that sounds like a 
> fragile thing to rely on).

Embedding is something that distributions avoid. Getting the full path
is possible if exposed somehow (like a CMake variable that holds the
path), but it also means the developer must do "the right thing".

> Besides, shouldn’t an app using dbus use 
> https://doc.qt.io/qt-5/qtdbus-index.html and not an external binary?

Maybe, but there seems to be use cases:

https://sources.debian.org/src/plasma-workspace/4:5.19.5-5/wallpapers/image/wallpaper.knsrc.cmake/?hl=49#L49

just to name one.

> So (#1) is mostly (fully?) cleared, then we still have (#2.1).
>
>
> Okey, good to get #1 out of the way first. Thanks!

Thanks to you! This really helps everyone discuss the issue!


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 10:16, Tor Arne Vestbø  wrote:
>
>
>
> > On 18 Nov 2020, at 14:01, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
> >
> > On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> > [snip]
> >> Let’s clarify this, so we’re talking about the same thing:
> >>
> >> 1. Application end-users
> >> 2. Application developers using Qt
> >> 3. Qt developers
> >
> > Let me expand it:
> >
> > 1. Application end-users
> > 2.1. Application developers using Qt as provided by distro.
> > 2.2. Application developers using more than one Qt major/minor version.
> > 3. Qt developers.
> >
> >> #3 develops Qt for use by #2 to produce applications for #1
> >>
> >> When you are talking about end users, which one of these do you refer to?
> >
> > 1 and 2.1.
>
> The application end user (#1) shouldn’t need access to any of Qt’s binaries 
> AFAIK. What’s there for us to fix for them?

qdbus can be called by an app ran by an end-user. Yes, it's a
backwards-compatible tool so nothing to worry with that specific tool
(in fact this thread helped to clear down the tools that need to be
backwards compatible).

So (#1) is mostly (fully?) cleared, then we still have (#2.1).


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 10:01, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
> [snip]
> > Let’s clarify this, so we’re talking about the same thing:
> >
> >  1. Application end-users
> >  2. Application developers using Qt
> >  3. Qt developers
>
> Let me expand it:
>
> 1. Application end-users
> 2.1. Application developers using Qt as provided by distro.
> 2.2. Application developers using more than one Qt major/minor version.
> 3. Qt developers.

Maybe worth mentioning: 2.2 should probably be "more than one minor
version", I am assuming that 2.1 covers both Qt 5 and 6.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 09:58, Tor Arne Vestbø  wrote:
[snip]
> Let’s clarify this, so we’re talking about the same thing:
>
>  1. Application end-users
>  2. Application developers using Qt
>  3. Qt developers

Let me expand it:

1. Application end-users
2.1. Application developers using Qt as provided by distro.
2.2. Application developers using more than one Qt major/minor version.
3. Qt developers.

> #3 develops Qt for use by #2 to produce applications for #1
>
> When you are talking about end users, which one of these do you refer to?

1 and 2.1.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Wed, 18 Nov 2020 at 09:34, Lisandro Damián Nicanor Pérez Meyer
 wrote:
[snip]
> > Then there's the question of which tools we recommend be in $PATH with a
> > suffix (list (b)). Please expand on this list if necessary, with a reason.
> > Here's the minimum list:
> >
> > qmake6 entry point for building qmake-based applications, situation
> >similar to /usr/bin/python (see [1])
> >
> >
> > I am not yet 100% convinced it is. This is a build tool after all, and even 
> > changes with minor versions of Qt. I know Linux distributions do only ship 
> > one minor version, but many of our users have to manage multiple minor 
> > versions of Qt as well. And renaming qmake with every minor version is a 
> > no-go.
>
> Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0
> times. qmake needed to be on path in order to be able to query it for
> some paths. But if that's no longer the case then yes, it can stay
> away.

...but using the same rationale that would also mean that tools like
cmake shouldn't be on path, which is not true. And yes, we could
simply symlink qmake6 but I think that, for this very specific tool,
the name should be qmake6 in docs too, at least on Linux.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 18 Nov 2020 at 08:58, Tor Arne Vestbø  wrote:
>
>
> On 18 Nov 2020, at 12:11, Tor Arne Vestbø  wrote:
>
> What we need is a command line tool for doing the same. That’s how other 
> project solve things too (nvm, rvm, pyenv, etc)
>
>
> For some context:
>
> https://github.com/nvm-sh/nvm
> https://rvm.io/
> https://github.com/rbenv/rbenv/
> https://github.com/pyenv/pyenv
> https://doc.rust-lang.org/edition-guide/rust-2018/rustup-for-managing-rust-versions.html
> https://github.com/kylef/swiftenv
>
> Some of these tools modify PATH on behalf of the user, while others add a 
> custom directory to the PATH where they then swap symlinks around (which is 
> how qtchooser works as far as I know?).
>
> They also allow per project (local) version pinning, which can be useful.

Right, and this are all developer's tools. End users shouldn't care
nor even know about them. Remember, we are talking about
distribution-provided binaries.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Tor!

On Wed, 18 Nov 2020 at 08:13, Tor Arne Vestbø  wrote:
>
> Morning,
>
> IMHO, suffixing our binaries is a kludge. It “solves” the major version 
> transition, but not any of the other use cases such as minor version 
> upgrades, different builds of the same Qt version, etc.

It's only about solving the major version, ie, the end-users version
provided by distributions. The cases you mention are mostly
developer-oriented.

> Qt Creator already provides a way to manage and switch Qt versions: 
> https://doc.qt.io/qtcreator/creator-project-qmake.html

Not everyone uses Creator.

> What we need is a command line tool for doing the same. That’s how other 
> project solve things too (nvm, rvm, pyenv, etc). And we already have a tool 
> for that, qtchooser. If maintenance of that is an issue, then let’s solve 
> that.
>
> Why is that not an acceptable solution for distros?

Because it breaks things:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=qtchooser and form
that list specially
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712264 which is a
per-design bug, ie, it can't be solved.

That doesn't means developers can still use it though.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

don't know how it's being used.
>
> - qtwaylandscanner: same as above.
>
> - tracegen: same as above
>
> - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> represented by the local Bluetooth device." Sounds like a user-facing app.
>
>
> All of those are developer facing tools and shouldn’t be in /usr/bin at all 
> IMO.

And again, they could be easily symlinked with a prefix if needed.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 18 Nov 2020 at 06:02, Joerg Bornemann  wrote:
>
> On 11/18/20 12:49 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
> >> You need to have a host Qt installed, including qmake.
> >> The cross-built Qt's qmake is a wrapper script that calls the host Qt's
> >> qmake and passes a qt.conf file, adjusting qmake's properties.
> >> This wrapper script in the cross-built Qt is currently named "qmake" and
> >> currently lives in $prefix/bin.
> >
> > Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
> > script that calls the host's qmake installed in $bindir except when
> > passed the right qt.conf file. Would that work? That would also mean
> > avoiding installing the real qmake in $prefix/bin and it's prefix.
>
> $prefix/bin/qmake6 can also be a wrapper script, sure.
> What would be the advantage of not installing the actual qmake binary there?

None, I've realized it after sending the mail.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Nov 2020 at 21:13, Thiago Macieira  wrote:
>
> On Tuesday, 17 November 2020 15:41:10 PST Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > - qtplugininfo: I sincerely don't know how it's being used.
>
> I was going to suggest it, but I ended up thinking it was obscure enough that
> for anyone who really needs it, they can use
>
> `qtpaths6 --binaries-dir`/qtplugininfo
>
> > - qtwaylandscanner: same as above.
> >
> > - tracegen: same as above
>
> Ditto and even less likely to be used.
>
> > - sdpscanner: "Performs an SDP scan on remote device, using the SDP server
> > represented by the local Bluetooth device." Sounds like a user-facing app.
>
> True, but it also sounds very limited. It sounds like an example application
> that is quite useful for the limited scenarios where it can be used. Like my
> cbordump tool too. Ditto for pixeltool.

Totally sensible.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Nov 2020 at 17:31, Joerg Bornemann  wrote:
>
> On 11/17/20 6:07 PM, Thiago Macieira wrote:
>
> > 3) there's a question of cross-compilation relating to qmake and host tools,
> > which I have not followed and do not understand the current state of. Need
> > input here.
>
> The situation is as follows for the cross-building case:
>
> You need to have a host Qt installed, including qmake.
> The cross-built Qt's qmake is a wrapper script that calls the host Qt's
> qmake and passes a qt.conf file, adjusting qmake's properties.
> This wrapper script in the cross-built Qt is currently named "qmake" and
> currently lives in $prefix/bin.

Sounds like $prefix/bin/qmake6 is feasible, even maybe *always* a
script that calls the host's qmake installed in $bindir except when
passed the right qt.conf file. Would that work? That would also mean
avoiding installing the real qmake in $prefix/bin and it's prefix.

By the way this is more or less how cross compiling Qt 5 apps with
Debian's multiarch was achieved: we use a generic mkspec but
automatically-generated qt.conf files.

Anyways this is a really interesting thing to consider as it might
make cross compiling easier within distributions that can co-install
the necessary stuff.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

On Tue, 17 Nov 2020 at 14:09, Thiago Macieira  wrote:
>
> On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote:
> > Have we fixed it?
> >
> > I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any
> > binary with the same name as Qt 5 did.
>
> Lars and I just had a quick discussion on IRC about this and here's what we
> propose. Ground rules and caveats:
>
> 1) MOST tools do not need to be in $PATH for most users. We developers are not
> most users. For us, setting PATH is acceptable. We're also likely the only
> audience to have more than one 5.x or 6.x Qt version installed.
>
> 2) This recommendation need not be supported by the buildsystem in time for
> 6.0.0, but needs to be as early as possible and by 6.1 at the latest. This
> recommendation allows Linux distributions to apply workarounds meanwhile,
> other buildsystems to adjust (read: Meson), and for us to write docs and QUIP.
>
> 3) there's a question of cross-compilation relating to qmake and host tools,
> which I have not followed and do not understand the current state of. Need
> input here.
>
> With that in mind, our recommendation is as follows:
>
> a) ALL tools be installed to a binary directory that is not $prefix/bin
> b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix
>   (we recommend a simple "6" instead of "-qt6")
> c) ADDITIONALLY, some further tools can be present unsuffixed
>
> The question is what tools are those in lists (b) and (c). Starting with the
> easiest (c):
>  - linguist
>  - qdbus
>  - qdbusviewer
>
> Those are user-facing tools that definitely do not depend on Qt version. It's
> up to the implementer to decide which Qt version they want these tools to be
> and any choice is fine. My guess is that for two of the three, it will depend
> mostly on Look-and-Feel with the desktop. But since these are an implementer's
> choice, Qt installation never installs those tools with the unsuffixed names
> by default.

Agreed to all above.

> Then there's the question of which tools we recommend be in $PATH with a
> suffix (list (b)). Please expand on this list if necessary, with a reason.
> Here's the minimum list:
>
>  qmake6 entry point for building qmake-based applications, situation
> similar to /usr/bin/python (see [1])
>  qml6   I don't understand why, but I'm told it's necessary
>  qtdiag6entry point for debugging problems with Qt 6
>  qtpaths6   because knowing the path in order to run the tool to get
> paths sounds weird. Having this in $PATH allows us to
> help users get to the other, debugging tools (qtplugininfo,
> qmlplugindump, etc.)
>
> Possibly also:
>
>  assistant6 for reading Qt 6 help files when not using Qt Creator
>  designer6  for those not using Qt Creator and needing to use Qt 6 plugins

Also agreed. I would consider assistant6 and designer6 to be included
in list (b) due to past experience.

Tools I don't know if they should or shouldn't be in this list:

- pixeltool: it's a screen magnifier, never used it before, but
clearly not something used at build time. Sounds like a user-facing
app for me.

- qtplugininfo: I sincerely don't know how it's being used.

- qtwaylandscanner: same as above.

- tracegen: same as above

- sdpscanner: "Performs an SDP scan on remote device, using the SDP server
represented by the local Bluetooth device." Sounds like a user-facing app.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 17 Nov 2020 at 12:31, Kai Köhne  wrote:
>
> > -Original Message-
> > From: Development  On Behalf Of
> > Thiago Macieira
> >> On Tuesday, 17 November 2020 00:46:32 PST Joerg Bornemann wrote:
> >> It is certainly possible to add a further configure option a la
> >>  -qt-executable-suffix -qt6
> >> to move the burden from the packagers to Qt's build system and ensure
> >> consistent Qt installation layouts across distributions.> That's a good 
> >> solution, so long as the packages built from qt.io also use it.
> > Can we count on that?
>
> Why should the packages in the online installer change? They are hardly ever 
> installed into some general directory.

Because it sets precedence. This way tools will expect the prefix on Linux.

> Also, this most likely will set us back in the release process. Doing 
> large-scale renames at RC time is just asking for trouble. Let's consider 
> this in time for Qt 7.

And then someone will push the topic again and Qt fails to "see  it"
again, thus delayed to Qt 8.

Come on Kai, please realize it is **not** a new issue. In fact I
pushed this exact thing **two** years ago and then insisted on it
exactly to avoid this resolution.

If you (Qt company) do not really like it, then go ahead and say"we
don't care about distributions". Or just bite the bullet and do the
right thing: get those binaries renamed (or a method to do it).



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 17 Nov 2020 at 08:43, Kevin Kofler via Development
 wrote:
>
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > I've discussed this with Dmitry Shachnev and the simplest way to
> > "solve" this would be to ship binaries in /usr/lib/qt6/bin/foo and
> > have /usr/bin/foo-qt6 symlinks to those.
>
> I have not yet talked to those who will likely be the maintainers of Qt 6 in
> Fedora, but this is almost exactly how things already work in Fedora for Qt
> 4 and 5 (except that we use hardlinks instead of symlinks due to multilib
> issues, as I explained elsewhere in this thread), so I think that is the
> most likely setup for Qt 6 as well (but Fedora will probably continue to use
> hardlinks).

ACK, I did contact Rex Dieter on IRC, so we have an agreement here.
The links being hard/soft are just a packaging detail in this case.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi Joerg!

On Tue, 17 Nov 2020 at 05:49, Joerg Bornemann  wrote:
>
> On 11/13/20 8:24 PM, Sune Vuorela wrote:
>
> > Oh. And I'm surprised by the Qt-people sudden love of QtChooser
> There's no sudden love. Just surprise that all of a sudden, shortly
> before the release, the established solution for co-installability must
> be changed.

I have brought this issue at very least two years ago:

https://development.qt-project.narkive.com/l84BEF6M/qt6-qt5-coinstallability-linux-distributions

And I'm pretty sure I did revive the topic at least one or two more
times, so no, there is nothing new here.

> It is certainly possible to add a further configure option a la
>  -qt-executable-suffix -qt6
> to move the burden from the packagers to Qt's build system and ensure
> consistent Qt installation layouts across distributions.
>
> However, simply changing the executable names won't cut it.
> I expect breakages, esp. in the qmake support. Therefore, this won't
> happen for 6.0.0.
>
> Please come up with a proposal that fits the packagers needs for the
> different distros, and we'll see how we can incorporate that into the
> build system.

Provide user-facing applications with a suitable prefix. That's all
that's needed. Tools that are only used at build time do not need the
prefix.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 12 Nov 2020 at 20:29, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi!
>
> On Wed, 11 Nov 2020 at 12:55, Thiago Macieira  
> wrote:
> >
> > On Monday, 9 November 2020 09:57:13 PST Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> > > Seriously, we have discussed this before, and we kind of agreed that
> > > user-facing applications should either be really backwards compatible
> > > or should have the tool suffixed with the qt version. Whatever other
> > > option is just pain for maintainers, be it trough qtchooser or by
> > > letting us renaming tools ourselves.
> >
> > Lisandro, Kevin, other packagers in the list:
> >
> > May I suggest you get together and make a proposal? If you can get a patch
> > into Gerrit, great. If not, then post the cmake command-line that Linux
> > distributions will use. We need the distributions to be consistent with each
> > other.
> >
> > Post to this list what the Qt 6 Linux distributions packages will install 
> > and
> > what the layout will be. Whether the default builds do the same or not is
> > irrelevant. It's your choice and can go against the default build.
> >
> > This is important for KDE Frameworks 6 and other software that mostly builds
> > from distro packages will likely adopt for its reference documentation.
>
> I like the idea. I have not touched Qt 6 yet (I'm very sadly not going
> to be able to maintain it) but I think this is actually a nice thing
> to do. I'll reach my co-maintainers and ask there. Kevin: can you do
> the same?

I've discussed this with Dmitry Shachnev and the simplest way to
"solve" this would be to ship binaries in /usr/lib/qt6/bin/foo and
have /usr/bin/foo-qt6 symlinks to those.

Projects using CMake to build will have no issues at all. If KDE
people need to call a user-facing application they might get the path
from CMake too.

Note that I used the -qt6 suffix here because I think that's what most
distros have been doing, but we have no opposition to any other suffix
scheme if necessary.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Wed, 11 Nov 2020 at 12:55, Thiago Macieira  wrote:
>
> On Monday, 9 November 2020 09:57:13 PST Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Seriously, we have discussed this before, and we kind of agreed that
> > user-facing applications should either be really backwards compatible
> > or should have the tool suffixed with the qt version. Whatever other
> > option is just pain for maintainers, be it trough qtchooser or by
> > letting us renaming tools ourselves.
>
> Lisandro, Kevin, other packagers in the list:
>
> May I suggest you get together and make a proposal? If you can get a patch
> into Gerrit, great. If not, then post the cmake command-line that Linux
> distributions will use. We need the distributions to be consistent with each
> other.
>
> Post to this list what the Qt 6 Linux distributions packages will install and
> what the layout will be. Whether the default builds do the same or not is
> irrelevant. It's your choice and can go against the default build.
>
> This is important for KDE Frameworks 6 and other software that mostly builds
> from distro packages will likely adopt for its reference documentation.

I like the idea. I have not touched Qt 6 yet (I'm very sadly not going
to be able to maintain it) but I think this is actually a nice thing
to do. I'll reach my co-maintainers and ask there. Kevin: can you do
the same?


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi again!

On Mon, 9 Nov 2020 at 15:51, Shawn Rutledge  wrote:
>
>
>
> > On 9 Nov 2020, at 19:27, Shawn Rutledge  wrote:
> >
> >
> >> On 2 Nov 2020, at 17:15, Thiago Macieira  wrote:
> >> ]qml is like Python: because of plugins, it's tied to the Qt version.
> >> Therefore, it fails the requirement for supporting everything the old 
> >> version
> >> supported.
> >
> > Well if you were using modules that are no longer supported, or you run 
> > into some little incompatibility; but we have been trying to avoid API 
> > breaks.  QML files that begin with “import QtQuick 2.0” still work fine so 
> > far; also Controls, Layouts etc.  So IMO it’s less onerous than the python 
> > upgrade.
>
> … but your point was not about QML file compatibility but about the mere fact 
> that we have a BC break, so users need two versions of the qml interpreter 
> installed at the same time, right?  And I still rather like the idea of just 
> installing them in different
> places, and having a symlink to point to the one you want to use.  If distro 
> maintainers insist that /usr/bin/qml must be an executable and not a symlink, 
> then I guess it should be the Qt 6 version, to go along with the fact that 
> we’re pushing the open source
> community pretty hard to upgrade as soon as it’s released.

If the qml binary is **only** used at build time then yes, it can be
hidden. If it's used as a script interpreter then you need to provide
both at the same time, because even in the fastest Qt 6 adoption times
you will have to support both Qt 5 and 6 versions for at very least 6
years. Believe me, I did that with Qt 4 and 5 :-)



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 9 Nov 2020 at 15:28, Shawn Rutledge  wrote:
>
>
> > On 2 Nov 2020, at 17:15, Thiago Macieira  wrote:
> > ]qml is like Python: because of plugins, it's tied to the Qt version.
> > Therefore, it fails the requirement for supporting everything the old 
> > version
> > supported.
>
> Well if you were using modules that are no longer supported, or you run into 
> some little incompatibility; but we have been trying to avoid API breaks.  
> QML files that begin with “import QtQuick 2.0” still work fine so far; also 
> Controls, Layouts etc.  So IMO it’s less onerous than the python upgrade.I 
> *think* that in this point we are talking about plugins within QML modules. 
> Can a Qt6 QML module be used in a Qt 5 application or the other way around? I 
> think the answer is no. And if the answer is no you need to be able to co 
> install this two different versions.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 2 Nov 2020 at 13:17, Thiago Macieira  wrote:
>
> On Monday, 2 November 2020 06:21:49 PST Shawn Rutledge wrote:
> > Sorry for snipping so much, but it seems like all your arguments are about
> > tools that are used to build software (qmake, moc etc.).  And you have a
> > point there.
>
> > But I don’t see the point of renaming user-facing tools like assistant, qml,
> > qtdiag and pixeltool.   So I hope at least those will be spared.
>
> I made a list of which tools are user-facing and which ones are development.
> Of those in your list, I only agree with for assistant. And I add qdbus and
> qdbusviewer. A requirement for "user-facing" implies that the tool performs
> the same task without loss of functionality if it was upgraded.

I remember Kevin saying something about tools that use plugins too,
IIRC designer, but there might be other tools to consider in this
respect.
[snip]
> > When it comes to the actual suffix to add, why use -qt6 instead of just 6?
>
> KDE Frameworks 5 tools added just a "5" so it's fine:

In fact yes, distros added -qt6 but -6 or just 6 could work too. I
think users might get it easier to understand with -qt6, but I lack
any serious data for that, just my ideas of maintaining Qt within
Debian.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 2 Nov 2020 at 10:09, Lars Knoll  wrote:
>
> I honestly don't think renaming all our binaries is an option, certainly not 
> that late in the process. We’ve had Qt 4 and Qt 5 co-installed for a long 
> time as well and while that might not be perfect it was working.
>
> And qtchooser has been working nicely for me (Ubuntu at least uses it).
>

With all due respect, this is a *huge* sigh for me. I have been trying
to explain endless times why this is *not* true. If it works it's
because we maintainers have been doing quite a lot of hacks to let
things "work".

Seriously, we have discussed this before, and we kind of agreed that
user-facing applications should either be really backwards compatible
or should have the tool suffixed with the qt version. Whatever other
option is just pain for maintainers, be it trough qtchooser or by
letting us renaming tools ourselves.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype and classes working with QStrings or QList

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mié., 26 ago. 2020 16:59, Scott Bloom  escribió:

> From: Development  On Behalf Of Ville
> Voutilainen
> Sent: Wednesday, August 26, 2020 12:08 AM
> To: Lars Knoll 
> Cc: Qt development mailing list 
> Subject: Re: [Development] qsizetype and classes working with QStrings or
> QList
>
> On Wed, 26 Aug 2020 at 09:39, Lars Knoll  wrote:
> > > QtGui:
> > > * QTextCursor
> > > * QTextDocument (find offset, character{At,Count})
> > > * QTextLayout
> > > * QValidator and subclasses (validate offset)
> >
> > These here are questionable. Editing a text file with more than 2G
> characters? Sounds unlikely.
>
> Disagree here.  There is good reason many in my industry (Electronic
> design automation) use the Scintilla editor widget inside Qt apps.
> Specifically to handle extremely large, in both line count and column
> count, files.
>
> Many of the text files we work with, are generated library definitions for
> silicon definitions.  A 5+ gb file is not uncommon.  Or files with a truth
> table definition with 5000-1000 columns.  I kid you not.
>
> Its one thing to not handle it, and say "too big to open" its another to
> attempt to and crash because the internal integers cant handle it.
>
> Scintilla handles these massive files relatively easily.
>

Yes, this files terms to be huge and are a valid case after all.

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt 6 will need Debian maintainers

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone! I just wanted to notice that Qt 6 will need new Debian
maintainers, see
https://perezmeyer.blogspot.com/2020/08/stepping-down-as-qt-6-maintainers.html

I'm posting this here for two reasons:

- I sincerely want to thank you all for the help you gave us during this time.
- Who knows, maybe someone reads this and considers stepping up to do
the packaging :-)

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWayland Compositor and marketplace

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Fri, 24 Jul 2020 at 09:10, Pier Luigi Fiorini
 wrote:
>
> Il giorno gio 16 lug 2020 alle ore 10:11 Shawn Rutledge 
>  ha scritto:
>>
>>
>> > On 2020 Jul 6, at 18:57, Pier Luigi Fiorini  
>> > wrote:
>> >
>> > Hi,
>> >
>> > I noticed that some modules are going into the marketplace, for example Qt 
>> > Multimedia.
>> > Would you consider doing so for QtWayland Compositor?
>> >
>> > The compositor API would surely benefit from a faster release cycle.
>> >
>> > Getting new protocols and updates sooner instead of every 6 months would 
>> > be great.
>> >
>> > Thoughts?
>>
>> I’m dubious about whether the release cycle would really be faster that way. 
>>  Continuing to include it in the release every 6 months probably adds more 
>> motivation to keep fixing things regularly, rather than slowing it down.
>>
>> Otherwise, do you have examples of ongoing changes that really shouldn’t 
>> wait until the next release?
>>
>> It’s currently possible to build from git.  (And I hope it remains that 
>> way.)  “Releases” are artificial flag days, from one side; in practice, 
>> Linux distros tend to wait for them, but it doesn’t have to be that way.

At least on Debian: it is *not* the release tag but the fact of no BC
for private stuff. And many packages use Qt's private headers. And
rebuilding them is a pain, even if you have the beefiest machines
around. Thiago explained it quite clearly in a recent mail.

And yes, that's exactly why we do our best to keep the amount of
private headers available as low as possible, ideally only the ones
needed to build Qt submodules themselves.

A wish for Qt 6 (too late for that I guess): do not require private
headers in order for Plasma o LXDE to provide their own theming.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QProperty and library coding guide

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

With my Debian Qt maintainer hat on: I want to stress everything that
Thiago mentioned in the cited below mail. Rebuilding the entire Qt
world in a distribution is a tremendous huge task. I'm afraid I can't
express the pain it is specially for libraries as popular as Qt... try
it yourself maybe? Change the SONAME and restart building Debian
unstable. Don't forget that that means the whole set of architectures
too. Oh, and that needs to be as fast as possible, Qt is so central in
many things that other stuff will end up waiting for it to finish.
Example: poppler can't be updated in the meantime. And that's just
poppler.

On Thu, 23 Jul 2020 at 19:11, Thiago Macieira  wrote:
[snip]
> > In any case, I don't think either use case is an absolute reason for keeping
> > BC.
>
> It's a choice.
>
> But I warn against choosing to break too often.
>
> A few years ago, Gtk threatened to do that starting with Gtk 4:
> https://lwn.net/Articles/691131/
> https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
> https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/
>
> They changed their minds.

When those news arose we Qt maintainers felt really really happy that
we maintain Qt, and that's because of BC.

Qt is already too big to maintain, especially if you are not being
paid for it. Break BC often and finding distro maintainers will be the
hardest thing to do.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] How do I fix a vulnerability in Qt. I forward the question to someone, or should I write the code myself?

[Lisandro Damián Nicanor Pérez Meyer]

Hi Bruno!

On Thu, 9 Jul 2020 at 15:11, Bruno Crocamo  wrote:
>
> Thank u, Eddy.
>
> Lars, in my first message I mentioned a link: 
> https://github.com/wkhtmltopdf/qt/pull/47.
>
> Here you can see the changes I made: 
> https://github.com/wkhtmltopdf/qt/pull/47/commits/5d639d9c04dbc644875e913cf0a6f5f54abcbf75

I'm afraid you need to send the changes to gerrit in order for the
relevant people to take a look at. That ensures you accepted the CLA.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using dwz on Qt

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 14 May 2020 at 19:49, Thiago Macieira  wrote:
>
> On Thursday, 14 May 2020 13:24:06 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > > I recently discovered there is a binutils tools for size optimizing dwarf
> > > debug symbols, and it really works. When applied to Qt debug symbol
> > > binaries it makes them about 25% smaller on average (some up to 40%
> > > smaller). And that is just the simple optimization. We can save more by
> > > combining duplicates from multiple debug symbol binaries into one shared
> > > one, but that would change the files we ship.
> >
> > For what is worth Debian packages have been doing this with Qt without
> > issues (of course as a post process after building Qt and before
> > packaging them).
>
> No distro relies on Qt's stripping routines. They all build with -no-strip and
> then figure out themselves using their own techniques.

Indeed, I only meant to say: it works fine, it seems a good idea.
Sorry if I wasn't clear on that.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using dwz on Qt

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 14 May 2020 at 07:33, Allan Sandfeld Jensen  wrote:
>
> Hi Qt
>
> I recently discovered there is a binutils tools for size optimizing dwarf
> debug symbols, and it really works. When applied to Qt debug symbol binaries
> it makes them about 25% smaller on average (some up to 40% smaller). And that
> is just the simple optimization. We can save more by combining duplicates from
> multiple debug symbol binaries into one shared one, but that would change the
> files we ship.

For what is worth Debian packages have been doing this with Qt without
issues (of course as a post process after building Qt and before
packaging them).

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt and Qt Creator's documentation and GFDL

[Lisandro Damián Nicanor Pérez Meyer]

I was pointed out that the invariant sections are opt-in, so clearly
the doc has no invariant sections. This should solve the issue.

On Sat, 18 Apr 2020 at 19:07, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> Hi! While reviewing the Qt and Qt Creator's licensing while packaging
> them for Debian I've noticed that documentation is under the GNU Free
> Documentation License, but nowhere in the files nor in the tarballs
> says it has no invariant sections.
>
> I would like to know if this is because:
> 1) It does not has invariant sections, so it was omitted
> 2) It does has invariante sections.
>
> If the answer is 1, would it be possible to make it explicit somewhere?
>
> Thanks, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt and Qt Creator's documentation and GFDL

[Lisandro Damián Nicanor Pérez Meyer]

Hi! While reviewing the Qt and Qt Creator's licensing while packaging
them for Debian I've noticed that documentation is under the GNU Free
Documentation License, but nowhere in the files nor in the tarballs
says it has no invariant sections.

I would like to know if this is because:
1) It does not has invariant sections, so it was omitted
2) It does has invariante sections.

If the answer is 1, would it be possible to make it explicit somewhere?

Thanks, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using SSE/NEON in Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Thu, 6 Feb 2020 at 14:14, Kevin Kofler  wrote:
>
> Lisandro Damián Nicanor Pérez Meyer wrote:
> > At least in Debian we do this for qtbase on i386, and have different
> > versions of corelib and gui (the only ones which where directly affected
> > by this).
>
> FYI, QtWebEngine is pretty much unfixably screwed on non-SSE2. The last
> version that was reasonably workable (still with heavy patching, mind you)
> was 5.9:
> https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/f25/f/qtwebengine-opensource-src-5.9.1-no-sse2.patch
>
> After that, Chromium dropped the V8 x87 backend, and since V8 has no
> interpreter fallback, the SSE2 one is the only option left. I was able to
> forward-port the x87 backend to 5.10, with minimal, emulator-only testing
> (WARNING: huge patch):
> https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/f27/f/qtwebengine-everywhere-src-5.10.1-no-sse2.patch
>
> Forward-porting that patch to current Chromium (anything ≥ QtWebEngine 5.11)
> is a lot of work, you basically have to track all the changes to the
> x86/SSE2 V8 backend and port them to the x87 backend included in the patch.
> I stopped working on that when it became too much work for me and when
> Fedora decided to drop support for non-SSE2 x86 anyway (though it officially
> was only for Fedora ≥ 29, but QtWebEngine already stopped supporting it in
> Fedora 28 updates).
>
> Blame Google for that.

Thanks, and yes, we are aware of that. But people tend to understand
that for huge beasts like web engines, not for the whole Qt stuff.
Anyways I think SSE2 should be now a good default. But that's my
personal opinion.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using SSE/NEON in Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On 20/02/06 02:00, Lars Knoll wrote:
> > On 6 Feb 2020, at 14:36, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
> > 
> > On 20/02/06 11:45, Lars Knoll wrote:
> >> Hi,
> >> 
> >> We’ve seen that in a couple of places things like matrix operations are a 
> >> CPU bottleneck. Being able to provide SSE/NEON optimised versions of some 
> >> of those operations could help significantly. 
> >> 
> >> On x86/x64, we require SSE2 already anyway, so we should be able to use 
> >> those unconditionally. On ARM, we can make this a compile time option with 
> >> a C implementation as the fallback.
> >> 
> >> One problem is, that we can only get full benefit out of those if we can 
> >> offer them inline. That would basically imply making our qsimd_p.h header 
> >> public and including that one from qvectornd.h and qmatrixnxn.h (so that 
> >> we can implement the operations using the SSE/NEON intrinsics). If we do 
> >> that, we could e.g. implement QVector4D holding a __m128 value (and the 
> >> neon equivalent on ARM).
> >> 
> >> I personally don’t think including qsimd.h (and implicitly immintrin.h) 
> >> from our public headers would be a problem, but I’d be happy to hear 
> >> arguments for/against it.
> > 
> > That might work as long as it's compile-time optional. Let's split both 
> > cases here:
> 
> Well, the idea would be that you could do a build without any SIMD 
> instructions if you configure Qt that way. But for the use cases I have in 
> mind, doing some runtime detection and different code paths would probably 
> kill most of the benefit.
> > 
> > # SSEn
> > 
> > SSEn is not present on all architectures. Not all i386 machines support 
> > SSE2 for
> > example, and some amd64 do not support more than SSE2 (read below).
> 
> Correct, but CPUs not supporting SSE2 are by now at least 15 years old.

Well, believe it or not last year there where still industrial 32 bits CPUs
being made without SSE2. That of course does not means they are dissapearing.

> > If some of this becomes mandatory then distributions will certainly not be 
> > able
> > to ship Qt 6. On the other hand if it can be decided at built time we could 
> > do a
> > double build and ship a non-optimized library in /usr/lib/ and an optimized
> > version in /usr/lib/sse2, /usr/lib/sse4, etc., as the linker knows what to 
> > do in
> > those cases.
> 
> SSE2 should not really be a problem, as it’s available on all 64bit capable 
> CPUs.
> > 
> > At least in Debian we do this for qtbase on i386, and have different 
> > versions of
> > corelib and gui (the only ones which where directly affected by this).
> 
> Are you also doing this for QtQml? Because we completely disable the QML JIT 
> if the platform doesn’t support SSE2.

Actually no, thanks for the pointer, I have just filed a bug so we can check
this.

> > Of course this might not go well with inlining.
> > 
> > # NEON
> > 
> > On Debian we have arm64, armel and armhf as arm-based supported 
> > architectures.
> > The only arch that can support NEON is arm64. It never existed for armel and
> > NEON was optional for µP builders on armhf.
> > 
> > I don't know if one ould do the /usr/lib/neon/ linker trick here.
> > 
> > # If we go the linker path route...
> > 
> > If this case is taken then it would be *awesome* to know exactly which 
> > libraries
> > do really get a benefit from this, so we only ship those with a double 
> > build.
> > 
> > # Other solutions?
> > 
> > If some other solution like the linker path is possible we can definitely
> > discuss it :-)
> 
> You’re looking at this very much from the perspective of a Linux distributor 
> (understandably). Many of our users however specifically build Qt and their 
> application for a certain hardware. So a compile time detection and usage of 
> NEON instructions should not be a problem at all there.

Of course not!

> 
> If you want a generic build that works everywhere, the only choice is of 
> course to turn them off for things that are inline.

A specific switch for inline stuff will certainly do it here.

> > 
> >> As a side note: SSE 4.1 offers some nice additional instructions that 
> >> would simplify some of the operations. Should we keep the minimum 
> >> requirement for SSE at version 2, or can we raise it to 4.1?
> > 
> > Well, I'm currently running KDE on my machine which only supports SSE2. 10yo
> > machine,: yes. But I could not afford a new one so far 

Re: [Development] Using SSE/NEON in Qt 6

[Lisandro Damián Nicanor Pérez Meyer]

On 20/02/06 11:45, Lars Knoll wrote:
> Hi,
> 
> We’ve seen that in a couple of places things like matrix operations are a CPU 
> bottleneck. Being able to provide SSE/NEON optimised versions of some of 
> those operations could help significantly. 
> 
> On x86/x64, we require SSE2 already anyway, so we should be able to use those 
> unconditionally. On ARM, we can make this a compile time option with a C 
> implementation as the fallback.
> 
> One problem is, that we can only get full benefit out of those if we can 
> offer them inline. That would basically imply making our qsimd_p.h header 
> public and including that one from qvectornd.h and qmatrixnxn.h (so that we 
> can implement the operations using the SSE/NEON intrinsics). If we do that, 
> we could e.g. implement QVector4D holding a __m128 value (and the neon 
> equivalent on ARM).
> 
> I personally don’t think including qsimd.h (and implicitly immintrin.h) from 
> our public headers would be a problem, but I’d be happy to hear arguments 
> for/against it.

That might work as long as it's compile-time optional. Let's split both cases 
here:

# SSEn

SSEn is not present on all architectures. Not all i386 machines support SSE2 for
example, and some amd64 do not support more than SSE2 (read below).

If some of this becomes mandatory then distributions will certainly not be able
to ship Qt 6. On the other hand if it can be decided at built time we could do a
double build and ship a non-optimized library in /usr/lib/ and an optimized
version in /usr/lib/sse2, /usr/lib/sse4, etc., as the linker knows what to do in
those cases.

At least in Debian we do this for qtbase on i386, and have different versions of
corelib and gui (the only ones which where directly affected by this).

Of course this might not go well with inlining.

# NEON

On Debian we have arm64, armel and armhf as arm-based supported architectures.
The only arch that can support NEON is arm64. It never existed for armel and
NEON was optional for µP builders on armhf.

I don't know if one ould do the /usr/lib/neon/ linker trick here.

# If we go the linker path route...

If this case is taken then it would be *awesome* to know exactly which libraries
do really get a benefit from this, so we only ship those with a double build.

# Other solutions?

If some other solution like the linker path is possible we can definitely
discuss it :-)

> As a side note: SSE 4.1 offers some nice additional instructions that would 
> simplify some of the operations. Should we keep the minimum requirement for 
> SSE at version 2, or can we raise it to 4.1?

Well, I'm currently running KDE on my machine which only supports SSE2. 10yo
machine,: yes. But I could not afford a new one so far (and this one still works
pretty fine).


# On a related note

So far my impression as a distro maintainer is that people where way more eager
to switch from qt4 to qt5 than from qt5 to qt6. If somehow the barrier gets even
higher we will have a hard time in making people to do the switch. Mind you, we
removed qt4 from Debian testing just some weeks ago...

Regards, Lisandro.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] I do not know

[Lisandro Damián Nicanor Pérez Meyer]

El vie., 31 ene. 2020 14:14, Karen  escribió:

> What this is and do not want these e-mails.  Please remove my name for
> this site.



For what it's worth: when I replied Thiago in the CVEs thread I also got
another mail from someone saying "I'm not Thiago". According to the headers
the mail was received trough the mailing list... Is there any chance that
someone started subscribing random people?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt vulnerabilities

[Lisandro Damián Nicanor Pérez Meyer]

Hi Thiago!

On Wed, 29 Jan 2020 at 22:19, Thiago Macieira  wrote:
[snip]
> Issue 2) CVE-2020-0570
> Score: 7.3 (High) - CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C
> * Vendor: Qt Project
> * Product: Qt
> * Versions affected: 5.12.0 through 5.14.0

I actually found that the patch applies to 5.7, and even qt4 with the
proper modifications. Is there something else in the code that limits
the affected version or maybe it does affects older versions too?

Cheers, Lisandro.


-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

On 20/01/29 04:02, Volker Hilsheimer wrote:
[snip]

> I wonder where all this love for the Qt installer comes from. I personally 
> consider “sudo apt-get install -y qtcreator” or “brew install qt-creator” or 
> “choco install qtcreator" to be vastly superior to using the installer UI, 
> and very easily integrated in VM provisioning. Any energy spent on making 
> sure that the versions we get from those package repos is up-to-date would be 
> worth a lot more (to me) than building another installer.

Being one of the maintainers in the options above, a huge *thank you* for that.
It really feels well :-)

P.S.: I've always wanted to produce Qt backports for Debian stable, but
time/need to get a paycheck doesn't currently allows it (it needs to be pseudo
official, can't go into Debian's backports for $reasons).
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

On 20/01/29 10:39, ekke wrote:
> Am 29.01.20 um 09:57 schrieb Cristián Maureira-Fredes:
> > 
> > I really want to believe that the new startup price is the beginning
> > of having ad-hoc pricing for everyone, and hopefully in the future
> > we can also see "medium-size company prices" or
> > "freelancer developer licenses", but such decisions cannot be made
> > at the same time.
> > 
> > Once the new startup pricing is out, the company will analyze if it was
> > a good move, and evaluate special future offerings,
> 
> the new pricing will only fit to very very small business or single
> developers, so I imagine that there won't be so many licenses sold.
> analyzing this one year later could give the answer "it doesn't work - let
> us stop it".
> 
> would be much better to change the limitations (increase max revenue) to get
> a larger amount of new devs using this
> 
> also it would be a good idea to have license prices for medium sized
> businesses, so everyone starting with small-biz-license knows what to pay if
> he/she has success and grows with Qt.
> 
> I know some features are missing, but over all Qt is such a great platform
> for mobile apps. Since QQC2 you can create cool and performant mobile apps.
> (Looking forward to Qt6/QML3 where all is compiled to C++)
> 
> I'm speaking on dev conferences, demonstrating apps at conferences and
> customers, writing articles for magazines. Licensing costs always was the
> barrier for other devs to jump on Qt. Now with $499/year it's much better to
> argument against usw of Xamarin, Flutter, ReactNative
> 
> Hope TQC will adjust definition of small business and also provide license
> for medium business.

Again, a full +1 from my side on this. ekke is hitting just the right spot here.

And I also think the minimal license should be 300US$/year.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

El mar., 28 ene. 2020 10:46, Bogdan Vatra  escribió:

> În ziua de marți, 28 ianuarie 2020, la 15:26:34 EET, Lisandro Damián
> Nicanor
> Pérez Meyer a scris:
> > Hi!
> >
> > On 20/01/27 06:18, Thiago Macieira wrote:
> > > On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich
> wrote:
> > > > I would expect a significant negative effect on the quality of Qt
> > > > shipped in Linux distributions and thus negative effect on the
> > > > Qt-based applications and Qt reputation.
> > >
> > > That is debatable since most Linux distributions do not align with the
> Qt
> > > LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid,
> but
> > > for all other LTSes, open source Linux distros seem to choose whichever
> > > version was latest at the time they reached feature-freeze.
> > >
> > > Current versions in:
> > > * Debian stable: 5.11.3
> > > * Debian oldstable: 5.7.1
> > > * Fedora 31: 5.12.5
> > > * Fedora 30: 5.12.1
> > > * Fedora 29: 5.11.1
> > > * Fedora 28: 5.10.1
> > > * CentOS 8.1: 5.11.1
> > > * openSUSE 15: 5.9.4 (15.1 now has 5.9.7)
> > > * openSUSE 42.3: 5.6.2
> > > * openSUSE 42.2: 5.6.1
> > > * (K)Ubuntu 19.10: 5.12.4
> > > * Ubuntu 18.10: 5.11.1
> > > * Ubuntu 18.04 LTS: 5.9.5
> > > * Ubuntu 16.04 LTS: 5.5.1
> > > * KDE Neon: 5.13.2
> > > * Manjaro 18.1.0: 5.13.0
> > >
> > > There are a couple of alignments with Qt LTS above but they could be
> > > coincidences. openSUSE 15 was released around 6 months after the 5.10.0
> > > release (and less than 3 after 5.10.1, which is when they seem to make
> > > upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought
> > > Fedora 31 was trying to align, but then I went to search for the
> current
> > > version and F32-in-development has already upgraded out of the LTS to
> > > 5.13.2.
> > >
> > > Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only
> > > legitimate, intentional alignment on a Qt LTS. If that's confirmed, it
> > > would be the first, after 4 years of having LTS releases.
> >
> > I confirm that because one of their maintainers is also a team mate in
> > Debian, read below.
> >
> > > So it's completely understandable to have concluded that the LTS
> releases
> > > weren't useful to Linux distributions.
> >
> > With my Debian maintainer hat on: exactly as Thiago said. But with a
> note:
> > we have always tried to ship a version as close to an LTS as we could
> (and
> > I know the same goes for Ubuntu, as one of my team mates prepares
> Ubuntu's
> > Qt packages from what we do in Debian). This is because it's normally
> > easier to get the patches from a LTS. But the point remains the same.
>
>   What happens when Qt 6 will be out and TQC closes 5.15 branch and you'll
> have to maintain Qt 5 for a couple of years without any bug fixes from
> upstream? As I pointed in my previous mails, the major risk here is that
> there
> will be a Qt 5.15 fork after the 5.15 branch is closed ... and nobody wins
> from such a scenario.
>

They (QtC) get this solved or they will loose lots of open source traction.

>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

On 20/01/27 02:34, Lars Knoll wrote:
> Hi all,
[snip]
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).

I want to make a note here. I have been maintaining Qt in Debian since the last
days of Qt4. I have been proxying stuff and people from one world to the other
for more than 7 years already.

Note that I fully understand and agree to the fact that an account is needed
because of the CLA, and that this is needed by the Qt company to remain healthy
too. But it is also the greatest barrier for lots of contributors.

We have already lost lots of opportunities due to this. Again, I understand that
this is necessary, but thinking that the proposed change will help into getting
more Open Source contributions is sadly a misguided concept.

What would help here is being more ubiquitous: better widget handling, better
open source integration (hello users of unstable private API outside of Qt
itself, or people needing to use private API to provide... themes!),
and maybe even the commercial proposal many of us did in previous mails.

But then again, the fact of forcing more accounts and hoping to have more open
source contributions is... flaky to say the least.

Cheers, Lisandro.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On 20/01/27 06:18, Thiago Macieira wrote:
> On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich wrote:
> > I would expect a significant negative effect on the quality of Qt
> > shipped in Linux distributions and thus negative effect on the
> > Qt-based applications and Qt reputation.
> 
> That is debatable since most Linux distributions do not align with the Qt 
> LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but for 
> all other LTSes, open source Linux distros seem to choose whichever version 
> was latest at the time they reached feature-freeze.
> 
> Current versions in:
> * Debian stable: 5.11.3
> * Debian oldstable: 5.7.1
> * Fedora 31: 5.12.5
> * Fedora 30: 5.12.1
> * Fedora 29: 5.11.1
> * Fedora 28: 5.10.1
> * CentOS 8.1: 5.11.1
> * openSUSE 15: 5.9.4 (15.1 now has 5.9.7)
> * openSUSE 42.3: 5.6.2
> * openSUSE 42.2: 5.6.1
> * (K)Ubuntu 19.10: 5.12.4
> * Ubuntu 18.10: 5.11.1
> * Ubuntu 18.04 LTS: 5.9.5
> * Ubuntu 16.04 LTS: 5.5.1
> * KDE Neon: 5.13.2
> * Manjaro 18.1.0: 5.13.0
> 
> There are a couple of alignments with Qt LTS above but they could be 
> coincidences. openSUSE 15 was released around 6 months after the 5.10.0 
> release (and less than 3 after 5.10.1, which is when they seem to make 
> upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought 
> Fedora 
> 31 was trying to align, but then I went to search for the current version and 
> F32-in-development has already upgraded out of the LTS to 5.13.2.
> 
> Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only 
> legitimate, intentional alignment on a Qt LTS. If that's confirmed, it would 
> be the first, after 4 years of having LTS releases.

I confirm that because one of their maintainers is also a team mate in Debian,
read below.
 
> So it's completely understandable to have concluded that the LTS releases 
> weren't useful to Linux distributions.

With my Debian maintainer hat on: exactly as Thiago said. But with a note: we
have always tried to ship a version as close to an LTS as we could (and I know
the same goes for Ubuntu, as one of my team mates prepares Ubuntu's Qt packages
from what we do in Debian). This is because it's normally easier to get the
patches from a LTS. But the point remains the same.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

On 20/01/27 03:00, Tuukka Turunen wrote:
> 
> Hi Ekke,
> 
> Currently Qt MQTT is not part of Qt for Device Creator or Application 
> Development product, see: https://www.qt.io/features 
> 
> Huge amount of other libraries are included, but unfortunately MQTT is only 
> available as part of the Qt for Automation. 

I suggest you to reconsider this, specially in the light of my proposal in my 
last mail.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Lisandro Damián Nicanor Pérez Meyer]

On 20/01/28 01:51, coroberti . wrote:
> On Tue, Jan 28, 2020 at 1:01 PM ekke  wrote:
> >
> > Am 28.01.20 um 11:14 schrieb coroberti .:
> > > On Tue, Jan 28, 2020 at 11:55 AM Konstantin Shegunov
> > >  wrote:
> > >> 
> > >>
> > >>> The third change is that The Qt Company will in the future also offer a 
> > >>> lower priced product for small businesses. That small business product 
> > >>> is btw not limited to mobile like the one Digia had some years ago, but 
> > >>> covers all of Qt for Device Creation.
> > >>
> > >> I see a couple of issues here. Firstly, 100k/year *turnover* isn't a 
> > >> small business, that's a nano-company (i.e. 1-2 devs max) and if they're 
> > >> providing a device alongside the software that 100k is going to be eaten 
> > >> in no time. Notice we are not talking profit here, but raw revenue. 
> > >> Whoever from sales came up with that number, really did a botched up job 
> > >> with it. On that note, even if we accept that it's applicable, the 
> > >> straightforward math shows you want to bill 0.5% - 2.5% of the total 
> > >> turnover, so while this sounds good initially it really isn't that shiny 
> > >> when you crunch the numbers. That offering is stillborn from my point of 
> > >> view.
> > > Agree with Konstantin that the definition of a small business isn't 
> > > realistic.
> > > The realistic one is up to 5 developers and up 500k/year USD sales.
> > >
> > > ...
> > >
> > > So, hello, Qt-company, and consider to make something really friendly
> > > for small businesses ...
> >
> > +1 Konstantin and coroberti

+1 from me too. I was going to write something alone the very same lines when
they did it before me.

> > I'm only a single mobile app developer and for me it is ok with 100k and
> > $499/year
> >
> > but I know many developers from small businesses (2-5 devs) and it's
> > really not realistic to think they have less 100k sales total per year ;-)
> >
> > coroberti's idea (up 500k sales per year) covers the target (StartUp,
> > Small Business) much better and is something making it easier to
> > motivate mobile app devs to use Qt instead of Flutter, Xamarin, React or so.
> >
> > please rethink your definition of StartUp / SmallBusiness to make this
> > license a success for Qt

Let alone markets in which those amounts are really insane. I'm also using only
the LGPL parts of Qt because current licensing scheme is just too expensive.

> 
> Thanks, Ekke,
> 
> And several more params not to miss for a small license:
> 
> - think how to be customer friendly and not red tape;
> - charge once a year or monthly - by user selection;
> - provide a guarantee of not increasing charges for least for 5 years;
> - provide guarantee of not changing the model for a while.
> 
> Perhaps, this is not your major market, but you can really get some income 
> here.
> At the end of the day, you are not providing support and all your income
> is a pure profit unless you screw matters and push people out.

Another idea in this camp: I think many of us in the "embedded" world [1] would 
benefit
from a license "exemption" more or less in this way:

- Users will use the open source part for developing.
- Users will not get support unless they pay for it.
- Users pay a very minimal amount of money (possibly per device) for using
  normally LGPL3/GPL[2 3] code as if it where LGPL2, ie:
  - dynamic linking required.
  - app should make explicit that it's using a special license for this.
  - Qt patches should be made open source.

Let's say you can add ~0.50 US$/device/qt submodule. So if I use widgets (LGPL
already), virtualkeyboard and the serialbus submodules then I would be paying
1 US$/device.

This also has another side benefit for users: they can use a distro and build
upon it.

[1] I would like to emphasize the difference between an "embedded device"
commercial license and the fact that as long as someone is follwoing the LGPL
can dispatch devices with proprietary code properly linked against Qt core, for
example. I am writing this because some years ago I was contacted by the latin
american sales manager and he simply mixed those things a lot. I don't know if
it was because of a misundertanding on his side or because he wanted to sell
stuff. Let's say it was the first thing ;-)

Kinds regards, Lisandro.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.14.0 and Qt Creator 4.11.0 released

[Lisandro Damián Nicanor Pérez Meyer]

Hi Oleg!

On Thu, 12 Dec 2019 at 20:26, Oleg Shalnev  wrote:

> Ladies and gentlemen! I have no idea what's going on with QtCreator 4.11.
>

I can't reproduce this issue using Debian's builds (I've uploaded it
yesterday). So maybe it's an issue with whichever method you used to
install it? It might deserve a bug report.

Note for the random reader: currently Debian's qtcreator does not
recommends clang-tidy, so it needs to be manually installed. It is already
fixed for the next upload.

Cheers, Lisandro.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Any history on why "qtmultimedia5-private-dev" was removed.

[Lisandro Damián Nicanor Pérez Meyer]

Hi again!

On Mon, 2 Dec 2019 at 16:41, Paul Knopf  wrote:
>
> I'm not arguing with that logic.
>
> What that said, what is the Debian policy with regard to what dev packages 
> should be added/removed to the official distro?
>
> From what I'm hearing, I gather it's something like "Debian supports end-user 
> commands/services/applications and the support libraries needed to run them, 
> as well as the dev packages needed to that end."

This is off topic here, but: we strongly support stable API/ABI.
Libraries not shipping stable API/ABI are mostly up to the maintainer.
In this case we ship the minimum necessary parts of private headers.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Any history on why "qtmultimedia5-private-dev" was removed.

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

Being the one who removed the package...

On Fri, 29 Nov 2019 at 05:22, Paul Knopf  wrote:
>
> Yeah, I understand the reasoning, because of lack of ABI compat with minor 
> updates/patches, etc.

...exactly. Private API is one of the reasons we don't update Qt more often.

> However, our proprietary GUI needs it. I'll work on recompiling that module 
> with private headers and deploy the deb within our own internal apt-feed.

Remember that multimedia is under both LGPL-3 and GPL3. Depending on
the usage you give it you might (or not) need a commercial license.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Creatror can require a patched Clang build?

[Lisandro Damián Nicanor Pérez Meyer]

On 19/09/10 11:59, Eike Ziller wrote:
> 
> 
> > On 10. Sep 2019, at 13:18, Lisandro Damián Nicanor Pérez Meyer 
> >  wrote:
> > 
> > Hi! Let me put some other perspective into this.

[snip]

> > - Every message should be clear on why something is not working. In
> > this specific case it is not "just" that the libFormat library is not
> > the right one, it's because it needs a *patched*, non-official version
> > of it.
> 
> Sure, error messages can be improved.
> 
> > - This kinds of things should happen at build time with a proper test
> > disabling building the plugin while clearly explaining whoever builds
> > creator which is the underlying issue.
> 
> That would be preferable, yes.

Actually I do see some value in letting the plugin be compiled as a dummy one.
If the error message is clear enough it would help both users and distro
maintainers in knowing that a certain feature which should be available
according to the release notes/blog it is not, and why. In that way users that
really need the feature can consider using precompiled binaries directly from
you. Users that prefer to stick with distro-packeges will just accept it and
move forward. Or even maybe help the patches become upstreamed :-) (it has
happened before).
 
> > Don't get me wrong: I see your intention. But if we all play as a team
> > we get to our users with the best experience possible. Having them
> > filing bugs because of supposedly working functionality is not the
> > right way forward. Let's just be clear and upfront and everything will
> > work better.
> 
> It certainly was not the intention that an unofficial patch would be needed 
> longer term.

Right, and seeing that you agree with the above I think this can be made
something of a rule (is quip used for this?). Something like:

  If some part needs a special feature/code/patch create explicit messages to be
  shown both at build and run time. Ideally add the long explanation in the
  README file.

If this is added right from the start the worst case scenario is that it might
become no longer true and it deserves a patch.

I'm working on this in the current proposed patch, build-testing right now.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Creatror can require a patched Clang build?

[Lisandro Damián Nicanor Pérez Meyer]

And by the way, is there any tag to relate a patch to the bug but not
close it if it gets accepted?

On Tue, 10 Sep 2019 at 08:41, Lisandro Damián Nicanor Pérez Meyer
 wrote:
>
> On Mon, 9 Sep 2019 at 18:20, Thiago Macieira  
> wrote:
> >
> > On Monday, 9 September 2019 14:07:59 PDT Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> > > Is this acceptable? I really think it is not, but...
> >
> > It's not. Requiring people to build LLVM + Clang, whcih is huge, is not
> > something we should do.
> >
> > Please work around.
>
> In the meantime I propose this:
> https://codereview.qt-project.org/c/qt-creator/qt-creator/+/273375
> In this way our users will know that the plugin needs a specific patch
> in clang. But better if we didn't. Or at very least the plugin wasn't
> build at all, with a proper warning at build time.



-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Creatror can require a patched Clang build?

[Lisandro Damián Nicanor Pérez Meyer]

On Mon, 9 Sep 2019 at 18:20, Thiago Macieira  wrote:
>
> On Monday, 9 September 2019 14:07:59 PDT Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > Is this acceptable? I really think it is not, but...
>
> It's not. Requiring people to build LLVM + Clang, whcih is huge, is not
> something we should do.
>
> Please work around.

In the meantime I propose this:
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/273375
In this way our users will know that the plugin needs a specific patch
in clang. But better if we didn't. Or at very least the plugin wasn't
build at all, with a proper warning at build time.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development