[Development] Meeting minutes from Qt Release Team meeting 31.1.2023

2023-01-31 Thread Jani Heikkinen via Development 
Qt 6.5 status
- Qt 6.5 beta2 released, Qt 6.5 beta3 preparations to be started
- Target is to release Qt 6.3 beta3 ~mid February
- Qt 6.5 beta4 target is at the end of February
- Target is to branch from '6.5' to '6.5.0' at the beginning of March
- Qt 6.5.0 String Freeze will be in effect 23th February
- Qt 6.5 API Change review is still ongoing, see 
https://bugreports.qt.io/browse/QTBUG-109580
- Updating 3rd party components for Qt 6.5 is ongoing, see 
https://bugreports.qt.io/browse/QTBUG-110331

Qt 6.4 status
- Target is to release Qt 6.4.3 during February
   * Branching from '6.4' to '6.4.3' will happen ~mid February
   * Qt 6.4.3 will be the last release from the Qt 6.4 series

Next meeting Tue 7st February 2023 16:00 CET

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:37]  akseli: alblasch: carewolf: 
lars__:mapaaso_:The-Compiler:thiago: vladimir-minenko:vohi: ping
[17:00:44]  pong
[17:00:46]  vladimir-minenko: what compatilility issues?
[17:00:47]  jaheikki3_: pong?
[17:00:51]  -?
[17:01:02]  jaheikki3_: pong
[17:01:34]  Time to start qt release team meeting
[17:01:39]  On agenda today:
[17:01:45]  Qt 6.5 status
[17:01:48]  qt 6.4 status
[17:01:55]  thiago: https://paste.the-compiler.org/view/a16123a9 
- which sounded like qmake depending on glibc 2.34 which is too new for Ubuntu 
20.04
[17:01:57]  Any additional item to the agenda?
[17:02:13]  thiago: glibc in Ubuntu 20.04, for example
[17:03:17]  jaheikki3_: Maybe, declaring the missing dates in 
https://wiki.qt.io/Qt_6.5_Release some time soon... ;-) 
[17:04:04]  The-Compiler: thiago: npm: like vladimir-minenko 
already wrote this issue is because existing dev snapshot is done by using RHEL 
9 and it has too new glibc for Ubuntu 20.04. That will be "fixed" with the next 
snapshot which is build by using rhel8 again
[17:04:55]  Let's start from Qt 6.5 status
[17:05:11]  The-Compiler: yes, don't downgrade distros
[17:05:40]  Qt 6.5 beta2 released last friday
[17:05:49]  Qt 6.5 beta3 preparations to be started soon
[17:06:00]  Target is to release Qt 6.3 beta3 ~mid February
[17:06:18]  (and beta4 at the end of february)
[17:06:50]  Target is to branch from '6.5' to '6.5.0' beginning of 
march
[17:07:16]  given the current challenges with CI stability (most 
recently, lots of failing tests after upgrading the macOS ARM hosts), we need 
to keep an extra eye on cherry-picks making it into the 6.5 branch. Some of 
those address comments from header review and such.
[17:07:46]  That's true
[17:08:19]  Qt 6.5.0 string freeze will be in effect 23th february 
[17:08:39]  vladimir-minenko: I'll update these dates in the wiki 
soon...
[17:08:53]  Qt 6.5 API Change review still ongoing, see 
https://bugreports.qt.io/browse/QTBUG-109580
[17:09:16]  Updating 3rd party components for Qt 6.5 also ongoing, 
see status from https://bugreports.qt.io/browse/QTBUG-110331
[17:09:46]  That's all about qt6.5 status at this time. any 
comments or questions?
[17:10:05]  vohi: might be a good idea to paste the link to the 
"missing gems" again to the ML
[17:10:29]  yep, will do
[17:10:46]  jaheikki3_: do you plan to push another header review patch 
set?
[17:11:47]  vohi:do you mean updates to open ones? I can do that 
later this week
[17:12:38]  yep. thanks!
[17:13:02]  Ok, then quick Qt 6.4 status update
[17:13:33]  the plan is to release Qt 6.4.3 during February
[17:13:45]  so branching from '6.4' to '6.4.3' will happen ~mid 
February
[17:14:12]  And the target is that Qt 6.4.3 will be the last 
release from the Qt 6.4 series
[17:14:38]  that's all about 6.4 at this time. Any comments or 
questions?
[17:16:50]  sounds good
[17:17:02]  great, it was all at this time. Let's end this meeting 
now & have new one tue 7th February at this same time
[17:17:15]  thanks for your participation, bye!
[17:17:17]  
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

2023-01-31 Thread 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] Help requested: 32-bit and the year 2038

2023-01-31 Thread Thiago Macieira 
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.

-- 
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] Help requested: 32-bit and the year 2038

2023-01-31 Thread Thiago Macieira 
On https://codereview.qt-project.org/c/qt/qtbase/+/455491

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]). Bug report QTBUG-110429 says QMutex and QSemaphore don't work after the 
overflow, so I prepared the patch above.

It failed in the CI, in the QEMU emulation of ARMv7. The reporter however says 
that the patch works on real hardware (ARMv7 too).

I don't know if this is an emulation bug. It's likely. QEMU's emulation at 
that lower level is so riddled with bugs that every time a test fails under 
emulation, I consider it a QEMU fault until proven otherwise.

So this is a request for help: can someone who has an interest in 32-bit 
platforms take the patch forward? I am not that person and I don't even have a 
development environment for 32-bit.

If there's no action within one month, I'll abandon the patch, close the task 
as "Won't Do" and declare 32-bit Qt will not work past 2038.

[1] https://lwn.net/Articles/664800/
-- 
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] Qt Multimedia: proposing behavior change to QAudioSink::resume

2023-01-31 Thread Tor Arne Vestbø via Development 
Hi,

This does indeed look like an oversight, where the behavior was perhaps modeled 
under the assumption the buffers were empty at the time of suspend().

I would expect the state to return back to the same state the sink had when 
calling suspend().

Cheers,
Tor Arne

> On 30 Jan 2023, at 16:38, Volker Hilsheimer via Development 
>  wrote:
> 
> Hi,
> 
> 
> TL;DR: I’d like to change QAudioSink::resume() to always change the sink to 
> Active state, no matter how the sink was start()’ed.
> 
> 
> QAudioSink provides low-level access to an audio device, allowing 
> applications to provide PCM data.
> 
> The class operates in one of two modes: in pull mode, the application 
> provides a QIODevice when calling QAudioSink::start(QIODevice *), and the 
> sink will pull data from that devices as needed. In push mode, the QAudioSink 
> creates and returns a QIODevice from the other QAudioSink::start() overload. 
> Applications write PCM data into that device.
> 
> The problem is with QAudioSink::resume. The function is documented to 
> behavior differently depending on how start() was called:
> 
> /*!
>Resumes processing audio data after a suspend().
> 
>Sets error() to QAudio::NoError.
>Sets state() to QAudio::ActiveState if you previously called 
> start(QIODevice*).
>Sets state() to QAudio::IdleState if you previously called start().
>emits stateChanged() signal.
> */
> 
> QAudioSink::suspend() behaves the same way in both modes: audio stops 
> immediately, already buffered data is preserved.
> 
> This means that on a sink that has 10 seconds worth of data, calling 
> suspend() after 1 second, and then resume()’ing changes the state of a 
> push-mode audio sink to Idle, audio will play for 9 seconds while the sink 
> reports to be idle, and the sink doesn’t change to “really idle” when all the 
> audio data has been played.
> 
> This means also that applications have no way of knowing when it’s time to 
> write more data, as an underflow error is never reported - the sink is 
> already idle, there are no state changes. This is pretty broken IMHO making 
> the push-style API practically useless if suspend/resume are used. However, 
> the behavior is documented, and verified in tests.
> 
> A sane behavior would be to move the sink to Active after resume (and to 
> handle buffer under-runs as usual, resulting in Idle state with error).
> 
> I’m not sure yet that we can implement the sane behavior on all platforms. 
> Pull-mode evidently implements it, but I don’t know yet if we can inspect the 
> amount of data buffered by the underlying audio system. Before we start 
> investigating that - can anyone think of any particular reason why the 
> existing behavior is a good idea?
> 
> 
> Volker
> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )

2023-01-31 Thread Cristian Adam via Development 

On 01/16/2023 13:49, Friedemann Kleint via Development wrote:

Hi,

It is basically what webengine has been using for a long time: Source 
files are concatenated to jumbo files which are then compiled.


Back in August 2019 Chromium announced the removal of the jumbo build 
 
with the following rationale:


   /We have decided to remove support for the jumbo (aka unity) build
   configuration from the project.//
   //
   //We are very conscious of the fact that Chromium is very expensive
   and slow to compile, and that that represents a real barrier to
   contributing.//
   //
   //However, based on the experience we've gained with this
   configuration over the past many months it's been supported, we've
   reached the conclusion that the way jumbo is currently implemented,
   it interferes too much with the way people frequently write C++
   code; you have to work around jumbo-specific conflicts in a way that
   can be awkward, unnatural, or otherwise unnecessary. As a result, we
   feel that the cost to the project of maintaining jumbo is not worth
   the benefit it is providing./

Did they brought it back or is webengine maintaining a patch to support it?

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