... in sci-geosciences/qmapshack, several commits starting with d6fed8734eddc1c87e78a0b13cd994f4f7e394d6, which even has this in git message: > sci-geosciences/qmapshack: An experimental Qt6 port > Translations and the help system are broken The latest incarnation of this is pointing to the head commit of an upstream "porting_qt6" branch. ... in x11-wm/lumina, starting with 4e1496105854f27dd632ebad1f03712e0cc99a27 which also says this in git message: > x11-wm/lumina: experimental port qmake -> cmake Only, in the ebuild we learn that this is actually pointing to SRC_URI="https://github.com/andreygrozin/lumina", and looking at the repository, it appears to fork upstream with a pending PR on top. Do you consider yourself to be new upstream, and will that end up in a Qt6-based release, I imagine to be no mean feat? Andrey, do you really believe such ebuilds should have ~arch keywords? Would you consider e.g. sci-geosciences/qmapshack-1.17.1_p602 to be stable material? Did the switch to cmake build system merit a lumina "patch release"? If you want to track upstream development, why not simply provide those as -9999 instead, improve packaging, and maybe finally spin a matured snapshot, if necessary, or better, release once available upstream? See $URL for proper snapshot ebuild format.
I use lumina as my desktop environment, and I like it. I don't want it to disappear from Gentoo. The speed of unstream development seems to be 0. I'm in email contact with one of the upstream developers. Actually, the qmake -> cmake transition is not quite trivial. Most of the work has been done in the upstream branch cmakify-all-the-things (last commit 2 years ago). Of course, I merged this brunch to my fork. But it did not work. I had to do quite a number of further changes. Now it works; I use 1.6.2_p1 as my everyday desktop. I am ready to stabilize it after the standard 1 month. About porting to Qt6 - I want to try it (using cmake is a prerequisite, of course). But it is a large work. I cannot promise that I'll be able to do it during some fixed time scale. I also use qmapshack rather regularly, but it is not so vital for me. Here too the speed of development seems to be 0. After my emails to the qmaphack mailing list, somebody did a Qt6 port in a fork, and then it was added to the main repository a a brunch. I18n was done in the main codebase in some not-quite-standard way (this code is rather old), and in the Qt6 port it does not work. The help system also does not work. Stabilizing 1.17.1_p602 seems therefore meaningless. But, as far as I understand, there is a great pressure to clean qtwebengine:5, and hence qmapshack-1.17.1. OK, then qmapshack will have no stable version. I use ~amd64, for me this is not important. And I don't really need translations and the help system. But I understand that some users may need them.
Another one: app-text/qpdfview-0.5_p2-r1 > REVISION=2162 > SRC_URI="https://bazaar.launchpad.net/~adamreichold/${PN}/trunk/tarball/${REVISION} ... even though Fedora manage to package this as Qt6-based even with 0.5 and no patching? https://src.fedoraproject.org/rpms/qpdfview/blob/rawhide/f/qpdfview.spec Again, you didn't answer any of this: (In reply to Andreas Sturmlechner from comment #0) > Andrey, do you really believe such ebuilds should have ~arch keywords? Would > you consider e.g. sci-geosciences/qmapshack-1.17.1_p602 to be stable > material? Did the switch to cmake build system merit a lumina "patch > release"? > > If you want to track upstream development, why not simply provide those as > -9999 instead, improve packaging, and maybe finally spin a matured snapshot, > if necessary, or better, release once available upstream? Wrt lumina, you are describing *upstream* work, not anything that should be exposed to users in ~arch.
Andrey?
In all 3 cases, the speed of the upstream development is very close to 0. The qpdfview snapshot contains some (small) improvements as compared to the pure 0.5 release. Do you want all the users to wait for these improvements for another year or two when 0.5.1 will (I hope) appear? In the case of qmapshack: the 1.17.1 release depends on qtwebengine:5, which will be removed soon. So, qmapshack-1.17.1 will have to be removed, too. Do you want to wait until the patches in the 1.17.1_p6* series will be included in some future release? (my guess is: never). If you remove qtwebengine:5 before this hypothetical release in the distant future, there will be no qmapshack in Gentoo at all, and it is a useful program. In the case of lumina: 1.6.2_p1 differs from 1.6.2 only by the build system, there are no changes visible to the users. I can remove 1.6.2_p1, this will make no difference for anybody except myself - let it live in my provate overlay.
I unterstand your intentions, they need no rehashing. - Do you understand my technical objections? What file naming will you choose on your next addition of a snapshot? - Do you acknowledge that bumping a package in ~arch, to a new "upstream" even, with no practical changes other than "experimental port to new build system", introducing 3 new bugs of which 2 remain unfixed, is a net negative? ~arch testing means *package* testing, it is not an upstream testing ground.
Don't get me wrong, working towards getting rid of Qt5(WebEngine in particular) is appreciated, and that's already more than some other maintainers are doing, but it does not mean that we sacrifice quality. The dependency wheel of fortune in bug 926676 e.g. is not confidence inspiring either.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=99d49fffaf1e46764053308968e6f6960e4377fd commit 99d49fffaf1e46764053308968e6f6960e4377fd Author: Andrey Grozin <grozin@gentoo.org> AuthorDate: 2025-03-02 04:58:39 +0000 Commit: Andrey Grozin <grozin@gentoo.org> CommitDate: 2025-03-02 04:58:39 +0000 x11-wm/lumina: remove 1.6.2_p1 Closes: https://bugs.gentoo.org/743094 Closes: https://bugs.gentoo.org/948431 Bug: https://bugs.gentoo.org/948589 Signed-off-by: Andrey Grozin <grozin@gentoo.org> x11-wm/lumina/Manifest | 1 - x11-wm/lumina/lumina-1.6.2_p1.ebuild | 82 ------------------------------------ 2 files changed, 83 deletions(-)
Live ebuilds are non-reproducible: something can change in the upstream vcs at a random moment, and the ebuild will not compile. I only use snapshot ebuilds. Citing https://devmanual.gentoo.org/ebuild-writing/file-format/index.html: When packaging a snapshot of a source repository, there are two commonly used formats. The first treats the snapshot as a patch to the previous version, and so the ebuild version is in the format $(last-released-version)_pYYYYMMDD. Alternatively, the snapshot may be treated as a pre-release to an upcoming version, usually used when a release is anticipated but not out yet. The format for this is $(upcoming-version)_preYYYYMMDD. In the case of qpdfview, before 0.5 appeared, I made several snapshot 0.5_pre<something> ebuilds. Now we are several commits after 0.5; so, it's natural to call such snapshot ebuild 0.5_p<something>. It is trivial to make such a snapshot ebuild not mentioning any upstream vcs commit number. I can download the desired snapshot, diff it against the last official release, and distribute the patch from dev.gentoo.org/~grozin/. It will look as any typical p_<something> ebuild. But this will be cheating, of course. I see no reason to do so. In the case of qmapshack, I call these Qt6-port ebuilds 1.17.1_p6xx. There was _p600, _p601, now _p602. If any further prograss in this Qt6 port will appear (which I strongly doubt), it will become _p603. I don't plan to work on reparing the help system and translations in this Qt6 port myself; the only hope is that somebody else might possibly do it. I am simply very much afraid that qmapshack will completely disappear from Gentoo soon.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e661a82050459785243374e1aa5dc21308cc33f3 commit e661a82050459785243374e1aa5dc21308cc33f3 Author: Andrey Grozin <grozin@gentoo.org> AuthorDate: 2025-03-02 05:47:02 +0000 Commit: Andrey Grozin <grozin@gentoo.org> CommitDate: 2025-03-02 05:47:02 +0000 app-text/qpdfview: pure 0.5 version for Qt6 Bug: https://bugs.gentoo.org/948589 Signed-off-by: Andrey Grozin <grozin@gentoo.org> app-text/qpdfview/qpdfview-0.5-r1.ebuild | 88 ++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+)
(In reply to Andrey Grozin from comment #8) > In the case of qpdfview, before 0.5 appeared, I made several snapshot > 0.5_pre<something> ebuilds. Now we are several commits after 0.5; so, it's > natural to call such snapshot ebuild 0.5_p<something>. *How* can you read the preceding paragraph, then come away with _p"<something>"? Don't you see the date format convention given there? (In reply to Andrey Grozin from comment #8) > It is trivial to make such a snapshot ebuild not mentioning any upstream vcs > commit number. I can download the desired snapshot, diff it against the last > official release, and distribute the patch from dev.gentoo.org/~grozin/. It > will look as any typical p_<something> ebuild. But this will be cheating, of > course. I see no reason to do so. That would absolutely be the wrong takeaway from this bug, and considering how I phrased $summary, I'm wondering if there is a serious language barrier here that makes this all seem so complicated to communicate. Clearly, picking important bugfixes only, and leaving feature commits alone, makes for a legitimate revbump to an existing version. A snapshot, however, will always contain *all* development since that last release, not just bug fixes, raising the potential for new bugs, and that's why maintainers should hesitate to just go package random states of a repository. I see you've revbumped app-text/qpdfview-0.5-r1 now, so the packaging situation presents itself like that, right now: > $ eshowkw qpdfview > Keywords for app-text/qpdfview: > | | u | > | a a p s a l r | n | > | m r h p p l o m i s m | e u s | r > | d a m p p c a x p o i s 3 6 | a s l | e > | 6 r 6 p p 6 r 8 h n p c 9 8 | p e o | p > | 4 m 4 a c 4 c 6 a g s v 0 k | i d t | o > ----------+-----------------------------+-------+------- > 0.5 | + ~ ~ o o ~ o + o o o ~ o o | 8 o 0 | gentoo > 0.5-r1 | ~ ~ ~ o o ~ o ~ o o o ~ o o | 8 # | gentoo > 0.5_p2-r1 | ~ ~ ~ o o ~ o ~ o o o ~ o o | 8 o | gentoo You will probably know that our stabilisation policy says to do so after 30 days with no bugs in ~arch. In theory that is 30 days from now. However, how many ~arch users do you think will have tested 0.5-r1 *in practice* until then, considering above output? Will that have been a legitimate testing period at all?
> how many ~arch users do you think will have tested 0.5-r1 *in practice* until > then, considering above output? Will that have been a legitimate testing > period at all? I use 0.5_p2-r1 many times every day. Haven't seen a slightest glitch.
OK. Tomorrow I'll remove myself from the maintainers' lists of these 3 packages. You may do whatever you want with them. I'll continue to maintain them in the overlay in my local computer, doing whatever I (as an end-user of these packages) consider reasonable.
There is no need for that. But why do you continue to evade my questions?
(In reply to Andreas Sturmlechner from comment #13) > But why do you continue to evade my questions? Because I see no questions. I see only statements that everything I do is wrong. You are welcome to do better.
How do we continue here? You surely haven't missed the question marks in my messages, usually indicating questions. A normal discussion would imply to respond to those. Where I think there has been a misunderstanding [of the devmanual or my observations], I gave more detailed explanations. I've expressed my appreciation for actually contributing towards the resolution of the overarching Qt5* removal tracker(s). But it must be possible to talk about technical room for improvement.
(In reply to Andrey Grozin from comment #11) > > how many ~arch users do you think will have tested 0.5-r1 *in practice* until > > then, considering above output? Will that have been a legitimate testing > > period at all? > I use 0.5_p2-r1 many times every day. Haven't seen a slightest glitch. That's good. But also not what I was asking about, again. I was alluding to the 0.5-r1 revbump [that no one forced you to do] getting virtually no testing at all since immediately being overshadowed by 0.5_p2-r1, hence being *practically* difficult to fulfill any testing period for stabilisation, if that was your goal. If 0.5_p2-r1 works well, then stabilisation would be fine after fixing bug 950349. Does it fix the other currently pending bugs against qpdfview as well?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=021d1a4f5c30949b848d45ca7626fff9c2a0716d commit 021d1a4f5c30949b848d45ca7626fff9c2a0716d Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-03-30 21:28:30 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-03-30 21:30:59 +0000 app-text/qpdfview: drop 0.5-r1, 0.5_p2-r1 Bug: https://bugs.gentoo.org/948589 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-text/qpdfview/qpdfview-0.5-r1.ebuild | 88 -------------------------- app-text/qpdfview/qpdfview-0.5_p2-r1.ebuild | 95 ----------------------------- 2 files changed, 183 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=11aeb5e257591091fa8f944d0e3108b728d1dd3a commit 11aeb5e257591091fa8f944d0e3108b728d1dd3a Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2025-03-30 21:22:11 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2025-03-30 21:30:51 +0000 app-text/qpdfview: add 0.5_p20240423, fix IUSE fitz, dependencies - reuse 0.5_p2 tarball - drop unused dev-qt/qtbase:6[xml] dependency - drop bogus dev-qt/qttools[dbus], add missing dev-qt/qtbase[dbus?] instead - fix IUSE fitz by passing FITZ_PLUGIN_LIBS="-lmupdf" to qmake - sort dependencies Bug: https://bugs.gentoo.org/948589 Closes: https://bugs.gentoo.org/697720 Closes: https://bugs.gentoo.org/709472 Closes: https://bugs.gentoo.org/818457 Closes: https://bugs.gentoo.org/950349 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> app-text/qpdfview/qpdfview-0.5_p20240423.ebuild | 93 +++++++++++++++++++++++++ 1 file changed, 93 insertions(+)
First, thank you for your efforts porting these packages to qt6! I have a question: sci-geosciences/qmapshack-1.17.1_p602 references commit 23d6fe3e11bd251f123fdba1f1cf2ac8170d4f83, which seems to be in detached HEAD state, see https://github.com/Maproom/qmapshack/commit/23d6fe3e11bd251f123fdba1f1cf2ac8170d4f83 This commit is not part of the "porting_qt6" branch you mentioned. Could you clarify where it comes from, and maybe update the ebuild to reference an existing branch?
I guess that qmapshack branch is rebasing. You can view it here https://github.com/Maproom/qmapshack/commit/23d6fe3e11bd251f123fdba1f1cf2ac8170d4f83 and clone it with git clone https://github.com/Maproom/qmapshack/ cd qmapshack git fetch origin 23d6fe3e11bd251f123fdba1f1cf2ac8170d4f83 and then tag it or check it out to see it i.e. in gitk but far from ideal. After the removal of the qt5 version i contributed xdg desktop file support, which was already merged. And some bits for the missing translations. Which should have been the final known open problems before a merge, and later hopefully stable shas or even tags and releases.
That "porting_qt6" branch is in fact not super long. One could "git format-patch" it into FILESDIR/patches to get qmapshack out of this bug and in the same intermediate form still in the tree
Again on qmapshack. Andrey let me know how i can help. I was happy to at least find a working ~amd64 instead of just 9999, so thanks for that. But i was also a bit surprised when i saw what that ebuild does and that it basically is a 9999 with a fixed sha and weird patchlevel. Anyhow, the progress of that qt6 effort is >0. As the dangling sha even proves, so that is good news but also proves the point of Andreas. I can i.e. offer to add a 9999 and convert p602 into something using patches in tree. And with the xdg-desktop issue fixed and translations maybe around the corner, i will stay in touch with upstream and ask for a tag/release after qt6 is merged.
I opened https://github.com/gentoo/gentoo/pull/41447 in which sci-geosciences/qmapshack-1.17.1_p602 is updated to p20250403 (using another upstream commit as well). The patches are pulled into the tree. The size causes pkgcheck warnings. But if the general approach seems acceptable the patches could be hosted by Andrey maybe. I am not a dev and can not zip them up somewhere acceptable. I did not send a 9999 yet, but would be happy to do that as well. Let me know what you think. Best (also) here because Andrey does not seem to be on github.
