Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 943527 - dev-qt/qtdeclarative-6.8.0-r1: Broken patch breaks QtQuick ListViews
Summary: dev-qt/qtdeclarative-6.8.0-r1: Broken patch breaks QtQuick ListViews
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-11-15 04:21 UTC by Nicolas Werner
Modified: 2024-11-15 13:16 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Werner 2024-11-15 04:21:32 UTC
In https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fdb02a790eb6d83107b919fece7a199b7e1ae00f a patch was added to fix QTBUG-125053. The patch for that does not seem to match the upstream diff linked on the Qt Gerrit (and I haven't found any revision, that it does match yet).

This patch is problematic, since it removes any handling for QAbstractItemModel::layoutChanged which causes broken rendering for list views, that rely on that behaviour. This is not a problem with the upstream build of Qt6.8.0 and similar.

Originally I assumed this was an upstream bug and you can find an example project to reproduce the issue there: https://bugreports.qt.io/browse/QTBUG-131289

I personally found this when trying out qt 6.8.0 on Gentoo.

Reproducible: Always

Steps to Reproduce:
1.Download example project from https://bugreports.qt.io/browse/QTBUG-131289
2.Build the project (meson setup builddir, meson compile -C builddir)
3.Run ./builddir/listviewfilterproxy
4.If you click the button at the top it will fail to update the listview properly
Actual Results:  
ListView in example does not update the row movement

Expected Results:  
ListView updates the row movement properly

The patch should probably be replaced with https://codereview.qt-project.org/c/qt/qtdeclarative/+/595358

However I don't know how it ended up like that in the first place!
Comment 1 Ionen Wolkens gentoo-dev 2024-11-15 06:15:46 UTC
We have the same changes, but the patch also includes the revert that the commit message mentions or else it does not apply.

Aka, you can recreate the patch we're applying by reverting 6.7 branch's [1], then applying [2] that you linked
(the latter does not apply without reverting the first)

The question is however, is the fix correct for 6.7 branch? It may be missing something, like another commit.

6.8.0 still has its share of regressions too (tons of patches and missing some), and was planning to wait until 6.8.1 to unleash it + stable later.

Guess the ideal may have been to just stick to 6.7.2, albeit at this point it'd be hard to go back.

[1] https://github.com/qt/qtdeclarative/commit/dd7d8f38b5e
[2] https://codereview.qt-project.org/c/qt/qtdeclarative/+/595358
Comment 2 Ionen Wolkens gentoo-dev 2024-11-15 06:39:04 UTC
At a glance, the 6.7 branch v1 is different than the 6.8 v1, and so the 6.8 revert keeps a few things -- guess I could experiment around there.
Comment 3 Ionen Wolkens gentoo-dev 2024-11-15 06:55:50 UTC
fwiw, at least I don't think the patch we currently use is introducing a regression to 6.7.3.

With or without the patch, the example application behaves the same way -- it just means that we're not truly fixing the regression that exists in 6.7.3.
[+] Comment 4 Ionen Wolkens gentoo-dev 2024-11-15 07:05:47 UTC Comment hidden (obsolete)
Comment 5 Ionen Wolkens gentoo-dev 2024-11-15 07:37:54 UTC
Actually, maybe there's a misunderstanding here.

Are *both* patched 6.7.3 and 6.8.0 misbehaving for you? Or are you *assuming* they're both broken because they use the same patch?

I'm not sure which is the correct behavior but:

With 6.7.3 (with or without the patch): "FFFF" goes down the list as I click the button
With 6.8.0: it doesn't, instead just the number does (is this wrong?)

So my understanding now is that you're using the masked 6.8.0 (that most users aren't using), and seeing the bad behaviour *only* with that one.

I guess the 6.7 version of the patch is just bad for 6.8 and I'd need to use the different revert.
Comment 6 Ionen Wolkens gentoo-dev 2024-11-15 07:39:06 UTC
Probably not so major given 6.8 is masked, but I'll have a look.
Comment 7 Ionen Wolkens gentoo-dev 2024-11-15 08:01:11 UTC
Yeah, all makes more sense now.. I kept only testing 6.7.3 given I thought it was affected too, and it made me wonder what I was supposed to see that's wrong :)

Dropping 6.7 from summary, the patch is correct there. Pushing a new one for 6.8 in a sec which makes "FFFF" go down the list like 6.7.3.
Comment 8 Larry the Git Cow gentoo-dev 2024-11-15 08:04:47 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=07424846a2e87d58e386a16f3d3d279ed5ed7385

commit 07424846a2e87d58e386a16f3d3d279ed5ed7385
Author:     Ionen Wolkens <ionen@gentoo.org>
AuthorDate: 2024-11-15 07:45:10 +0000
Commit:     Ionen Wolkens <ionen@gentoo.org>
CommitDate: 2024-11-15 08:02:45 +0000

    dev-qt/qtdeclarative: fix 6.8.0's QTBUG-125053 patch
    
    The version for 6.7.3 seems correct but sharing it with 6.8.0 was not,
    thankfully 6.8.0 is masked so this didn't affect many people.
    
    Closes: https://bugs.gentoo.org/943527
    Signed-off-by: Ionen Wolkens <ionen@gentoo.org>

 .../files/qtdeclarative-6.8.0-QTBUG-125053.patch   | 258 +++++++++++++++++++++
 ...8.0-r5.ebuild => qtdeclarative-6.8.0-r6.ebuild} |   2 +-
 2 files changed, 259 insertions(+), 1 deletion(-)
Comment 9 Nicolas Werner 2024-11-15 13:16:27 UTC
Yes, sorry, I assumed 6.7.3 was also affected because of the same patch, but had only tested 6.8.0. Thank you for the quick fix (even though the package is masked)!