Qt 5.15.16 is in tree now, but dev-python/pyside2-5.15.14 is precluding the upgrade. Please bump.
Please don't spam us with versiom bump requests after such a short amount of time. I'll bump it in a couple of days.
(In reply to Nowa Ammerlaan from comment #1) > short amount of time 5.15.16 had been out for a week before I opened this bug. I appreciate that you are a volunteer, and I do thank you for your work, but by being the maintainer of this package, you have taken on a responsibility to your users to keep it updated in a timely manner and especially not to block updates of other major libraries, which is what is happening here due to PySide2's pinning a singular version of the Qt5 libraries. Anyone with dev-python/pyside2 installed is now seeing the following when they do 'emerge -u @world' (after an extremely long time to calculate dependencies due to all the backtracking that is triggered): !!! The following update(s) have been skipped due to unsatisfied dependencies !!! triggered by backtracking: dev-qt/qtx11extras:5 dev-qt/qtwidgets:5 dev-qt/qtdeclarative:5 dev-qt/linguist-tools:5 dev-qt/qtwayland:5 dev-qt/qtsvg:5 dev-qt/qtquickcontrols:5 dev-qt/qtprintsupport:5 dev-qt/qtmultimedia:5 dev-qt/designer:5 dev-qt/qttranslations:5 dev-qt/qtgraphicaleffects:5 dev-qt/qtquickcontrols2:5 dev-qt/qtscript:5 dev-qt/qtdbus:5 dev-qt/qtwaylandscanner:5 dev-qt/qtconcurrent:5 dev-qt/qtsql:5 dev-qt/qtxml:5 dev-qt/qttest:5 > Please don't spam us Opening a bug to track this outstanding task that needs completing hardly constitutes spamming.
(In reply to Matt Whitlock from comment #2) > (In reply to Nowa Ammerlaan from comment #1) > > short amount of time > > 5.15.16 had been out for a week before I opened this bug. I appreciate that It was added to ::gentoo at Thu Nov 21 21:38:31 UTC 2024, and pyside2 couldn't have been bumped before then. This bug was opened barely ~26 hours after that, can say it's nearly a day 0 request.
> Opening a bug to track this outstanding task that needs completing hardly constitutes spamming. It is when it happens again and again, about an issue that I am well aware of. The pinning is annoying, if you want to complain about it then please complain upstream.
(In reply to Nowa Ammerlaan from comment #4) > it happens again and again That's a sign that there's something unexpectedly suboptimal about the way that this continues to be handled. Shouldn't this package be considered "part of Qt" and be bumped atomically at the same time as all of the rest of Qt? It is, after all, the official Python binding of Qt, released in lockstep with the rest of Qt by Trolltech themselves (or whatever they're calling themselves these days). I assume that the Gentoo maintainer of the Qt packages isn't interested in maintaining this binding alongside them, which is unfortunate but is their prerogative. (In reply to Ionen Wolkens from comment #3) > [5.15.16] was added to ::gentoo at Thu Nov 21 21:38:31 UTC 2024, and pyside2 > couldn't have been bumped before then. Maybe it could have been. Could new versions of pyside2 be added in a masked state (listed in profiles/base/package.mask) ahead of the related bumps of the Qt packages? Then all the Qt maintainer would need to do would be to drop the mask at the same time as introducing the new Qt version. If the Qt maintainer won't do even that simple step, then at least trigger happy users like me would be able to unmask the new version ourselves, and you wouldn't get as much "bug spam." (I wouldn't have filed this bug if I could have simply unmasked the new pyside2 version when I started seeing the blockers in my Portage output.) > This bug was opened barely ~26 hours after that, can say it's nearly a day 0 > request. Well, sure. That's because it nearly constitutes a tree breakage. If I didn't have a high --backtrack setting in my default emerge arguments, I'm not sure Portage would even be able to resolve my world set with the tree in its present state. Blockers on core libraries should be addressed with high priority, don't you think? Is there some amount of time that I'm expected to wait patiently before reporting a bug?
We've had this discussion before, qt often does not release pyside at the same time as the rest of qt and so it cannot be bumped at the same time. Hence it is more productive to complain upstream, if I could have improved the situation I already would have.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=862181cf33a86bd6f11a4ea7c34cee76f9807732 commit 862181cf33a86bd6f11a4ea7c34cee76f9807732 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2024-11-23 18:00:55 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2024-11-23 19:39:24 +0000 profiles: Mask dev-python/pyside2 and friends for removal Others being: dev-python/pyside2-tools dev-python/shiboken2 Bug: https://bugs.gentoo.org/944511 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
By the way, if anyone find this annoying, may want to use stable. At *least" we do stabilize pyside6 and Qt6 together. Either way, glad that we're done with pyside2. (In reply to Nowa Ammerlaan from comment #6) > We've had this discussion before, qt often does not release pyside at the > same time as the rest of qt and so it cannot be bumped at the same time. > Hence it is more productive to complain upstream, if I could have improved > the situation I already would have. fwiw, we're now planning to mask new major .0 of Qt when we add them, and wait a bit before unmasking them (if ever, we didn't with 6.8.0 due to too many regressions) -- and during that period, pyside6 could be bumped before the unmask (in fact, the 6.8.0 mask had a preemptive =pyside6-6.8.0* mask). Albeit no such plan for .1/.2/.3 versions of Qt (aka 6.8.1 soon), so this wouldn't work out unless can make pyside6 no longer pin to minor versions. Aka similarly to PyQt6 which "typically" only breaks on major versions. It does sometime break on minor versions, it's been rare and fixes were simple when it happens (afaik this used to work out fine for pyside6 too, it'd be a shame that a rare issue introduced permanent minor version pinning).
Removed per de107c3b46750f6af55f9526d9f7042dfe6a9246
