[Development] IPv6 support is required (but QNX gets a pass)

[Thiago Macieira]

In trying to fix something in the CMake files, it turns out that we had 
accidentally disabled a part of our IPv6 support on some platforms. I'm trying 
to fix it with
https://codereview.qt-project.org/c/qt/qtbase/+/499560
https://codereview.qt-project.org/c/qt/qtbase/+/499601
https://codereview.qt-project.org/c/qt/qtbase/+/499549

This may take a few days, but at the end of it I plan to have it back to 
working order in all platforms (except the untestable ones).

IPv6 support is mandatory for Qt in any and all OSes that support IPv6. And 
since we are right now in 2023, which is 12.5 years after IANA ran out of 
blocks to allocate to the local registries, and nearly 4 years since RIPE NCC 
(the registry for Europe) ran completely out, If you live in Europe and you 
want an IPv4 block, you have to wait for some company to return some or go 
bankrupt. I wouldn't touch with a long pole any OS that fails that, if I were 
making an application.

I've already found failures for QNX and Android.

For Android, it appears we have a defective support in QNetworkInterface. 
Linux does have a proper API for querying and getting IPv6 addresses out of 
the interfaces, which we have in Qt (qnetworkinterface_linux.cpp), but Android 
has decided to block us from it (see QTBUG-96974). That being an OS policy, 
there's nothing I can do about it. If there's another way to get to those 
addresses, I don't know about it and don't plan on investigating anyway.

However, Android does support IPv6. It just lacks proper QNetworkInterface 
support to detect the addresses that the system may have. The tests seem to be 
otherwise passing.

Then there's QNX. It not only seems to have the same QNetworkInterface 
shortcoming, but some QUdpSocket and QTcpSocket tests fail, though not all so 
it seems the IPv6 stack is there. Whatever the problem is, it's not apparent 
from the logs. Debugging this via the CI is time-consuming and frustrating, so 
I won't do any more of that. And since there's no SDK I can use, I won't fix 
this at all. I've just added a "return false" to QtNetworkSettings::hasIPv6().

No other OSes should be allowed this exception. This means INTEGRITY and 
VxWorks: the former is supported by Qt but not tested in the CI, whereas the 
latter is being re-added. They will need to fix the issues, not add more 
exceptions.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] CI failing due to ASan tst_selftest

[Thiago Macieira]

See https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1698516419

Two separate sets of changes are running into this problem, which means 
neither can be at fault. Tthis must be some other configuration that changed in 
the CI. The file in qt5.git that seems to control this build hasn't changed 
recently, so the change must not be in the Git repositories.

It did find a real leak, which I fixed in 
https://codereview.qt-project.org/c/qt/qtbase/+/499608. All the rest seem to 
be false leaks (i.e., memory in use at the end of the program) and moreover we 
have no control over, like:

   ==19383==ERROR: LeakSanitizer: detected memory leaks
 Direct leak of 48 byte(s) in 2 object(s) allocated from:
   #0 0x7f26aec7ae48 in __interceptor_malloc (/usr/lib64/libasan.so.
5+0x109e48)
   #1 0x7f26a8bcbc50  (/usr/lib64/libfontconfig.so.1+0xbc50)
   #2 0x3d4c4c415f434bff  ()

So it appears that whatever change this was, it made ASan's Leak Checker 
actually work, whereas before it was passing but not doing its job. 
Unfortunately, we're not clean of leaks, at least not of those in third-party 
libs.

That means we have two possible actions to take:
* turn off ASan
* turn on the proper suppressions for ASan


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtFluentMQ

[team fluentmq]

Hello,

Thanks for welcoming the project everybody.

> AFAIR we haven't bike shedded over the commercial value of a new repository, 
> the architecture of the code it shall hold, or its licensing before. I don't 
> think we need to.
To be fair, while we're Qtifying our API to give back to the community as Qt 
has been good for us for a long time going, we're also looking forward to 
acheive framework community grade robustness through a Qt integration as this 
is the most sensitive part of our product designed for (extra) large scale 
distributions. We did ask for an intent of integration had the project held its 
ground in term of compatibility with the Qt project for us to allocate the 
ressources for that which is why Volker mentioned the need for internal 
discussions. Using the playground as an assessment buffer for the integration 
sounds like a party !

> You should fill in at least the basic information, though: name and 
> description, responsible person, and desired location.

name: QtFluentMQ
description:

The "QtFluentMQ" project aims to create a user-friendly and versatile message 
queue (MQ) client using the Qt 6 framework. This client seamlessly handles 
communication with major MQ platforms. The first release would implement the 
AMQP protocol thus supporting RabbitMQ, ActiveMQ, Apollo, Artemis, IBM MQ, 
Amazon MQ and more. It will also migrate the existing Kafka implementation to 
Qt to support the Kafka platform as well, the current MQ market leader.

At its core, the project involves a top-layer abstraction called QMQInstance. 
This layer acts as a bridge between the application and various MQ platforms. 
Within this layer, there are two main components: QConsumer and QProducer, 
which can also be referred to as QQmlConsumer and QQmlProducer when working 
with QML.

QMQInstance provides a unified QMessage Interface that simplifies the process 
of sending and receiving data to and from different MQ brokers. This uniform 
interface streamlines the interaction with multiple MQ platforms, making it 
easier for developers to integrate messaging functionality into their 
applications.

One of the standout features of this project is its dynamic configurability. 
The client can be configured through a JSON input. This flexibility allows 
developers to adapt the client's behavior to specific use cases and 
requirements without significant code changes.

Additionally, the project supports queues context switching. This means that 
the client can seamlessly switch between different queues or channels within 
the MQ platforms. This feature is particularly useful for managing multiple 
communication channels efficiently and ensuring the smooth flow of data.

Finally, the QtFluentMQ actively supports open-source initiatives like 
Plumber, a versatile CLI tool for 
seamless interaction with various messaging systems, including Kafka and 
RabbitMQ. By collaborating with projects like Plumber, Fluent MQ enhances the 
CI/CD process by offering an all-in-one tooling package that streamlines 
operations and simplifies integration tasks."

In summary, QtFluentMQ project offers a comprehensive and easy-to-use solution 
for interacting with various MQ platforms. Its abstraction layer, dynamic 
configurability, and support for queues context switching contribute to a 
seamless messaging experience for developers working with Qt 6 applications.

responsible person:  George Ransdall

desired location: Playground

 Br
QtFluentMQ Team



From: Volker Hilsheimer 
Sent: Saturday, August 26, 2023 11:34 AM
To: Ulf Hermann ; development@qt-project.org 

Subject: Re: [Development] QtFluentMQ

> On 26 Aug 2023, at 10:09, Ulf Hermann via Development 
>  wrote:
>
> Hi,
>
> The usual way to request a repository, playground or not, is a mail like this:
>
> https://lists.qt-project.org/pipermail/development/2022-August/042900.html
>
> If the request is not totally outlandish it's usually granted, possibly after 
> some bike shedding over the name and location.
>
> AFAIR we haven't bike shedded over the commercial value of a new repository, 
> the architecture of the code it shall hold, or its licensing before. I don't 
> think we need to.
>
> You should fill in at least the basic information, though: name and 
> description, responsible person, and desired location.
>
> At least sometimes, we have used the lazy consensus mechanism for repository 
> requests in the past. This seems a good idea to me. I will +1 this one if the 
> (still missing) basics are reasonable.
>
> We can still discuss the way to integrate with the rest of Qt once we can see 
> some code.


It’s good to understand the ambitions and state of the project when deciding 
the location of the repo, hence my questions. From what I read about the state 
in particular, a repository in the playground/ namespace seems to make more 
sense than starting under qt/ and 

Re: [Development] QtFluentMQ

[Volker Hilsheimer via Development]

> On 26 Aug 2023, at 10:09, Ulf Hermann via Development 
>  wrote:
> 
> Hi,
> 
> The usual way to request a repository, playground or not, is a mail like this:
> 
> https://lists.qt-project.org/pipermail/development/2022-August/042900.html
> 
> If the request is not totally outlandish it's usually granted, possibly after 
> some bike shedding over the name and location.
> 
> AFAIR we haven't bike shedded over the commercial value of a new repository, 
> the architecture of the code it shall hold, or its licensing before. I don't 
> think we need to.
> 
> You should fill in at least the basic information, though: name and 
> description, responsible person, and desired location.
> 
> At least sometimes, we have used the lazy consensus mechanism for repository 
> requests in the past. This seems a good idea to me. I will +1 this one if the 
> (still missing) basics are reasonable.
> 
> We can still discuss the way to integrate with the rest of Qt once we can see 
> some code.


It’s good to understand the ambitions and state of the project when deciding 
the location of the repo, hence my questions. From what I read about the state 
in particular, a repository in the playground/ namespace seems to make more 
sense than starting under qt/ and adding this to the qt5.git super repository 
immediately, as our wiki page suggests it should.

So if team QtFluentMQ can provide the missing bits of information, then we can 
just go ahead with this if no-one objects.


Cheers,
Volker


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

Re: [Development] On the use of the inline keyword

[Volker Hilsheimer via Development]

> On 25 Aug 2023, at 14:20, Ahmad Samir  wrote:
> 
> On 25/8/23 14:11, Cristian Adam via Development wrote:
>> The other way of fixing this is by using ... macros. The article at c++ - 
>> Importing inline functions in MinGW - Stack 
>> Overflow
>>   mentions using inline in the class declaration.
>> Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is 
>> also fine:
>> #ifdef _WIN32
>> #define Q_EXPORT_INLINE inline
>> #else
>> #define Q_EXPORT_INLINE
>> #endif
>> class __declspec(dllimport) MyClass {
>> public:
>> Q_EXPORT_INLINE int myFunc2();
>> Q_EXPORT_INLINE int myFunc1();
>> };
>> inline int MyClass::myFunc2(void) {
>> return myFunc1();
>> }
>> inline int MyClass::myFunc1(void) {
>> return 0;
>> }
> 
> [...]
> 
> The main deterrent to not fix it like the qstring.h patch[1] is the churn 
> caused by changing many lines, in many files, right?
> 
> But if affected code is going to be changed anyway to fix it with macros, it 
> makes more sense to fix it like [1]; if you're changing those lines, may as 
> well adhere to more standard guidelines: inline keyword is only used on 
> function declaration and _not_ the definition.
> 
> 
> My 2p's.
> 
> [1] https://codereview.qt-project.org/c/qt/qtbase/+/498739


Yes, if we have to change the code to fix the warnings, then the way Marc 
proposes, and how it has now been done for qstring.h, seems to be the way to go.

But yes, my concern is the work (I expect this can be easily automated with 
clazy, but still need to be reviewed), and the code churn that goes with it 
(the impact on `git blame`, and the inevitable conflicts when cherry-picking).

It seems to be a rare issue, triggered by specific circumstances. With the 
knowledge that we have now, we can fix issues when they arise, and don’t have 
to change all the problematic use right now.

That’s my understanding at least; I might be wrong, but we have been building 
Qt for a few decades on MinGW without this constantly blocking us.

Volker


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

Re: [Development] QtFluentMQ

[Ulf Hermann via Development]

Hi,

The usual way to request a repository, playground or not, is a mail like 
this:


https://lists.qt-project.org/pipermail/development/2022-August/042900.html

If the request is not totally outlandish it's usually granted, possibly 
after some bike shedding over the name and location.


AFAIR we haven't bike shedded over the commercial value of a new 
repository, the architecture of the code it shall hold, or its licensing 
before. I don't think we need to.


You should fill in at least the basic information, though: name and 
description, responsible person, and desired location.


At least sometimes, we have used the lazy consensus mechanism for 
repository requests in the past. This seems a good idea to me. I will +1 
this one if the (still missing) basics are reasonable.


We can still discuss the way to integrate with the rest of Qt once we 
can see some code.


best regards,
Ulf Hermann
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development