... 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.
