Upstream in 2023: "No port to Qt6 planned, yet." Clearly needs more prodding.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d6fed8734eddc1c87e78a0b13cd994f4f7e394d6 commit d6fed8734eddc1c87e78a0b13cd994f4f7e394d6 Author: Andrey Grozin <grozin@gentoo.org> AuthorDate: 2024-09-08 05:47:51 +0000 Commit: Andrey Grozin <grozin@gentoo.org> CommitDate: 2024-09-08 05:47:51 +0000 sci-geosciences/qmapshack: An experimental Qt6 port Translations and the help system are broken Bug: https://bugs.gentoo.org/926676 Signed-off-by: Andrey Grozin <grozin@gentoo.org> sci-geosciences/qmapshack/Manifest | 1 + .../qmapshack/qmapshack-1.17.1_p600.ebuild | 38 ++++++++++++++++++++++ 2 files changed, 39 insertions(+)
(In reply to Larry the Git Cow from comment #1) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=d6fed8734eddc1c87e78a0b13cd994f4f7e394d6 > Your ebuild doesn't need dev-qt/qtbase? How can you depend on dev-libs/quazip:0=[qt6(+)] when qt6 is *missing* in earlier versions?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f54768366733f56fa8fd78989e00d88f6554afd commit 3f54768366733f56fa8fd78989e00d88f6554afd Author: Andrey Grozin <grozin@gentoo.org> AuthorDate: 2024-09-18 16:19:47 +0000 Commit: Andrey Grozin <grozin@gentoo.org> CommitDate: 2024-09-18 16:19:47 +0000 _p600: list of dependencies improved Bug: https://bugs.gentoo.org/926676 Signed-off-by: Andrey Grozin <grozin@gentoo.org> .../qmapshack/qmapshack-1.17.1_p600-r1.ebuild | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+)
I am not really sure that all flags in [...] in Qt6 dependencies are necessary. I am more or less sure that they are sufficient.
Just use lddtree? And if you have trouble associating .so files to USEdeps, ask around in #gentoo-qt? Also: https://wiki.gentoo.org/wiki/Project:Qt/Qt6_migration_notes Committing random deps is unacceptable.
Haven't tried to build this, but at a "glance" at the CMakeLists.txt the dev-qt/* bits should be: RDEPEND=" ... dev-qt/qt5compat:6 dev-qt/qtbase:6[dbus,gui,network,sql,widgets,xml] dev-qt/qtdeclarative:6 dev-qt/qttools:6[help,widgets] dev-qt/qtwebengine:6[widgets] ... " DEPEND="${RDEPEND}" BDEPEND=" dev-qt/qttools:6[linguist] " (dbus could potentially be made optional but it's default ON and I don't think it's worth worrying about) Please verify & update+revbump not to have many unnecessary USEdeps. linguist should also be in BDEPEND. Per the link asturm posted, Qt6UiTools is qttools[widgets] btw, the old ebuild depended on designer because it was providing Qt5UiTools back then. Qt6Qml is from qtdeclarative, seem doubtful need USE=qml on qtwebengine at a peek.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9990525b532a9ac0ecc3f339e2d5882640c060e4 commit 9990525b532a9ac0ecc3f339e2d5882640c060e4 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-04-01 22:11:38 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-04-01 22:12:05 +0000 sci-geosciences/qmapshack: drop 1.17.1 Closes: https://bugs.gentoo.org/926676 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> sci-geosciences/qmapshack/Manifest | 1 - sci-geosciences/qmapshack/qmapshack-1.17.1.ebuild | 45 ----------------------- 2 files changed, 46 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f3aa41ee7ae41682c1c07a702a5d520279fa667 commit 5f3aa41ee7ae41682c1c07a702a5d520279fa667 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-04-01 22:10:35 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-04-01 22:12:05 +0000 profiles: Mask sci-geosciences/qmapshack-1.17.1 for destabilisation Bug: https://bugs.gentoo.org/926676 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
Was it not 30 days instead of 30 seconds between mask and remove. And that after explaining all the rules to others.
(In reply to Henning Schild from comment #8) > Was it not 30 days instead of 30 seconds between mask and remove. And that > after explaining all the rules to others. What are you talking about? 30 days thing is for last-rite and this wasn't one, and it also hasn't been removed (only the stable version was, and mask is there to inform of the destabilization change).
(In reply to Ionen Wolkens from comment #9) > What are you talking about? 30 days thing is for last-rite and this wasn't > one, and it also hasn't been removed (only the stable version was, and mask > is there to inform of the destabilization change). My bad. Sorry! Just from a user perspective i think i never saw a package do that transition so quickly. But luckily there was an ~amd64.
(In reply to Henning Schild from comment #10) > Just from a user perspective i think i never saw a package do that > transition so quickly. But luckily there was an ~amd64. If you haven't seen it, then only because in the past no one went through the trouble of informing you via package.mask and just dropped it silently, anyway.
