[Development] Qt Online Installer 4.0.1-1 released

[Tino Pyssysalo]

Hello,

I’m happy to announce that Qt Online Installer 4.0.1-1 has been released.

In this version, open-source users can select the mirror to download metadata 
and packages.
By default, the mirror is still selected automatically, but users can select 
another mirror in the command line.

In addition, UI fixes for the new UI style, introduced in 4.0.1, have been done.

Further details in the blog post 
https://www.qt.io/blog/qt-online-installer-4.0.1-1-released.
--
Tino Pyssysalo
The Qt Company
Installer PO

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

Re: [Development] CI just blew up

[Tony Sarajärvi]

Trying to restart the CI now. We had to reinstall OpenNebula and redeploy all 
hosts etc. Seemed like the quickest way to get things online today.

We don’t know what corrupted the SQL database, nor do we have anything to debug 
it with left after nuking it. Let’s just see if it happens again.

Tier2 images should be left, we did not wipe the NFS partition, so no 
provisioning storm should be needed.

Good luck! I’ll continue on this tomorrow

-Tony

From: Tony Sarajärvi
Sent: Thursday, January 28, 2021 3:59 PM
To: development@qt-project.org
Subject: RE: CI just blew up

Seems this isn’t repairable. The poo entangled itself so well into the fan, 
that I have to replace the whole fan now.

This could take a few hours...

-Tony

From: Tony Sarajärvi
Sent: Thursday, January 28, 2021 3:31 PM
To: development@qt-project.org
Subject: CI just blew up

Hi

Something blew up in the CI. Currently my finger is pointing towards 
OpenNebula’s SQL database blowing up. But that’s after 5 minutes of looking at 
logs... so let’s see.

In other words: working on it.

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

Re: [Development] Qt modules, API changes and Qt 6

[Volker Hilsheimer]

> On 22 Jan 2021, at 12:39, Oswald Buddenhagen  
> wrote:
> 
> On Thu, Jan 21, 2021 at 04:06:03PM +, Volker Hilsheimer wrote:
 Am 17.09.19 um 14:27 schrieb Oswald Buddenhagen:
> for example, the information that a build with updated dependencies is 
> required can be stored as an annotation in the commit message (that's 
> exactly what zuul does, afaik), and the incremental propagation of the 
> dependencies can be done in a "shadow" branch of the qt5 repository 
> (technically, that could be a single gerrit change that gets 
> progressively updated).
> [...]
>> 
>> Do I understand your proposals correctly:
>> 
>> Let’s say I make a change in qtdeclarative that depends on a merged change 
>> ‘shaA' in qtbase and on ’shaB’ in qtsvg, then I add something like
>> 
>> dependencies: qtbase:shaA qtsvg:shaB
>> 
>> (or whatever syntax we want) to my qtdeclarative commit message?
>> 
> yes.
> 
>> As for the shadow branch(es) in qt5.git or progressively moving gerrit 
>> change(es):
>> 
>> * change shaX in qtbase merges, breaks qtdeclarative
>> * bot updates shadow-branch's .gitmodules to point at qtbase:shaX; it’s now 
>> inconsistent (qtdeclarative doesn’t build or pass tests)
>> * coin keeps testing qtdeclarative changes against qtbase:shaX~1 (as per 
>> upstream .gitmodules), changes that don’t depend on shaX merge
>> * follow-up change shaY in qtdeclarative is staged, with above annotation 
>> asking for qtbase:shaX
>> * coin tests qtdeclarative with shaY against qtbase:shaX, as per the shadow 
>> branch’s .gitmodules. Tests pass, shaY merges, .gitmodules in shadow branch 
>> is updated to point at qtdeclarative:shaY
>> 
>> Once the round is complete for all sub modules, the existing git submodule 
>> update process updates .gitmodules in the proper branch, and reset the 
>> shadow-branch (I suppose).
>> 
>> Was that the idea, Ossi?
>> 
> i think so. ^^
> 
>> It puts some extra burden on contributors and reviewers (add commit footer 
>> with correct sha1,
>> 
> remember that this is only for the commits that explicitly ask for a dep 
> update, and they currently do that by modifying the yaml file.

So things either work, or they need some coordination of the change hat fixes, 
and the change that bumps the dependencies. Maybe we can simplify that whole 
thing:

* by default, there is no sha1 in the dependencies.yaml files

If there is none, assume HEAD of the corresponding branch.

With the big breakages for Qt 6 done, this should work for many modules, most 
of the time. Many of us are already building a large subset of Qt modules daily 
from HEAD of all of those modules.

* only pin the version if the latest HEAD doesn’t work

I.e. if current HEAD of qtdeclarative doesn’t pass against new HEAD of qtbase 
(during the dependency updating round), pin the last-working qtbase revision in 
qtdeclarative’s dependency.yaml file. I assume we can keep that history of 
“last sha1 of module that worked” in the CI system rather than in git; if 
nothing else, we can fall back to whatever is in qt5.git's .gitmodules

Once someone has followed up with a patch in qtdeclarative (or qtbase), remove 
that version pinning again.

Eventually, things will be consistent, and .gitmodules gets updated. We won’t 
have a complete record of all the different qtbase revision against which each 
qtdeclarative revision tested successfully in the past, but we don't have that 
that in Qt 5 anyway, and .gitmodules will have equivalent information, at 
larger intervals.

That should reduce the amount of git history noise substantially.


>> but it might be possible for Coin to try to move things  forward 
>> automatically, just as we do now with the dependency update bot.
>> 
> yes, of course. the mechanism would stay almost identical, only the state 
> would be keept in a different (more appropriate) place.

Storing the state outside of the relevant repository means that we have to 
stage changes in two repos for things to work again. That makes for a messy 
orchestration (still less messy than having to get the “proper” .gitmodules 
updated to a consistent set).


> On Thu, Jan 21, 2021 at 04:20:50PM +, Tor Arne Vestbø wrote:
>> This information does not belong in the commit message.
>> 
>> It belongs in dependencies.yaml,
>> 
> that's just something you're postulating, completely ignoring the points made 
> against the very existence of that file.


I think it makes sense to recognize that it has become a common practice to 
document the dependencies of a project in some sort of data file within that 
project. Wether requirements.txt, package.json, dependencies.yaml, or a 
“requires” in a conanfile.py.

.gitmodules might work for the Qt libraries that are directly under the Qt 
Project governance, but it won’t help 3rd party libraries. Perhaps there is 
value in having a more standardised process?


Cheers,
Volker



___
Development mailing list

Re: [Development] CI just blew up

[Tony Sarajärvi]

Seems this isn’t repairable. The poo entangled itself so well into the fan, 
that I have to replace the whole fan now.

This could take a few hours...

-Tony

From: Tony Sarajärvi
Sent: Thursday, January 28, 2021 3:31 PM
To: development@qt-project.org
Subject: CI just blew up

Hi

Something blew up in the CI. Currently my finger is pointing towards 
OpenNebula’s SQL database blowing up. But that’s after 5 minutes of looking at 
logs... so let’s see.

In other words: working on it.

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

[Development] CI just blew up

[Tony Sarajärvi]

Hi

Something blew up in the CI. Currently my finger is pointing towards 
OpenNebula’s SQL database blowing up. But that’s after 5 minutes of looking at 
logs... so let’s see.

In other words: working on it.

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