Created attachment 252177 [details] update mvdsv to 1.00 The projects were separated and located in different repositories: https://github.com/QW-Group/mvdsv https://github.com/QW-Group/qwdtools If you don't mind, I would ask you to allow me to become their maintainer.
Created attachment 252178 [details] update qwdtools to last git commit - 0.34.20220906
Created attachment 252208 [details] update mvdsv to 1.00 v2 Cleanup Makefile: - Remove USES=localbase:ldflags - Remove USE_GITHUB=nodefault and GH_ACCOUNT=QW-Group - Add LICENSE_FILE=${WRKSRC}/LICENSE.md
Created attachment 252209 [details] update qwdtools to last git commit - 0.34.20220906 v2 Add LICENSE_FILE=${WRKSRC}/LICENSE.md
Also I'm working on new port games/ktx [1] now and it require recent mvdsv. [1] Kombat Teams eXtreme: https://github.com/QW-Group/ktx
Created attachment 252304 [details] update mvdsv to 1.00 v3 Fix PR2 segfault when compiling with clang and -O2: https://github.com/QW-Group/mvdsv/pull/143
Holy fsck! You're actually VVD <vvd@quakeworld.ru> whom I've talked to about MVDSV back in 2004 on several occasions, one of the main developers? > If you don't mind, I would ask you to allow me to become their maintainer. Yeah, I guess it makes sense, given the above, I'll take a closer look at the patches shortly, but at a quick glance: > -SIZE (deurk-mvdsv-0.34_GH0.tar.gz) = 597476 > +SIZE (mvdsv-source-with-submodules-1.00.zip) = 6882290 Since you guys are preparing and uploading your own releases, why not simply name them sanely (e.g. mvdsv-$version.tar.bz2) and avoid ugly name and setting WRKSRC? Also, new size is eleven times bigger, what had happened, is this correct? > The projects were separated and located in different repositories: This is a bit unfortunate, as having master-slave relationship was convenient so the tools port automatically follows updates of the server one.
(In reply to Alexey Dokuchaev from comment #6) Yes, it's me! :-o 20 years ago… > Since you guys are preparing and uploading your own releases, why not simply name them sanely (e.g. mvdsv-$version.tar.bz2) and avoid ugly name and setting WRKSRC? Also, new size is eleven times bigger, what had happened, is this correct? I haven't been actively involved in the project for a several years now, just sending small patches from time to time. The not very smart current developers added .git to the release: 304368 03-10-24 09:33 mvdsv-source-1.0.0/.git/objects/pack/pack-1a4d480e0e6f990429411e7ca477b9f22861f050.idx 5953365 03-10-24 09:33 mvdsv-source-1.0.0/.git/objects/pack/pack-1a4d480e0e6f990429411e7ca477b9f22861f050.pack :-D I have passed these questions on to the current developers.
(In reply to Vladimir Druzenko from comment #7) > The not very smart current developers added .git to the release: [...] > I have passed these questions on to the current developers. Thanks. Meanwhile, I think we can use GitHub's generated tarballs while developers fix their release process. No need to resend the patch, the change should be rather trivial.
(In reply to Alexey Dokuchaev from comment #8) It don't have submodule, but this file have it.
Created attachment 252495 [details] update mvdsv to 1.00 v3 Add EXTRACT_AFTER_ARGS, PORTDOCS, man and logo.
(In reply to Alexey Dokuchaev from comment #8) Can I commit?
(In reply to Vladimir Druzenko from comments #9 and #11) > It don't have submodule, but this file have it. It is not (and never was) a problem, the framework handles these cases just fine. > Can I commit? Well, as I don't quite agree with the patch, I'd rather handle it myself (it's in the queue).
(In reply to Alexey Dokuchaev from comment #12) > It is not (and never was) a problem, the framework handles these cases just fine. A crutch in the form of GH_TUPLE? I prefer to avoid using it. > Well, as I don't quite agree with the patch, I'd rather handle it myself (it's in the queue). But what about "take maintainership"? :-(
ping
(In reply to Vladimir Druzenko from comment #13) > A crutch in the form of GH_TUPLE? I prefer to avoid using it. I also do not like GH_TUPLE and use it only for Golang-written ports, for simple cases like this one I'd typically add GH_{PROJECT,TAGNAME,SUBDIR} group. Arguably, it's still not very pretty, but it can stay until we get correctly generated and named distfile (I've noticed that size is sane now, but the name is still bogus because it doesn't have embedded version number). > But what about "take maintainership"? My intention hasn't changed, I'll try to speed myself up, sorry for delay.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ac2f7978633151f9dae784e3041bd774fc5ee9e7 commit ac2f7978633151f9dae784e3041bd774fc5ee9e7 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2024-09-21 13:37:08 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2024-09-21 13:37:08 +0000 games/qwdtools: emancipate the port and update to the latest commit - QWDtools now live in their own upstream GitHub repository, contrary to being part of the MVDSV before, and build themselves using CMake - Assign maintainership to vvd@ who has better knowledge of this code and more tight connections with other developers PR: 280374 games/qwdtools/Makefile | 23 +++++++++++++++-------- games/qwdtools/distinfo (new) | 3 +++ 2 files changed, 18 insertions(+), 8 deletions(-)
Created attachment 257233 [details] update mvdsv to 1.00 v5 Tarball updated - .git removed from tarball!
Created attachment 257604 [details] update mvdsv to 1.10 v1 New version released 1.10: https://github.com/QW-Group/mvdsv/releases/tag/v1.10
ping! I just added ktx to ports: https://cgit.freebsd.org/ports/commit/?id=6bb96dba53ce7ddf66061facefa348cbd0f27022 It require recent mvdsv to work.
(In reply to Vladimir Druzenko from comment #17) > Tarball updated Could you ask your release engineer to prepare *conventionally named* source tarball? E.g., ${PORTNAME}-${PORTVERSION}.tar.bz2 or something similar, but with embedded version, so distfiles for different versions can coexist and be cacheable? > .git removed from tarball! Then why the need for EXTRACT_AFTER_ARGS hack? :) But anyway, this had been cooking for too long, I don't want to delay it further and would commit something tonight, given it's now required by the KTX.
(In reply to Alexey Dokuchaev from comment #20) > Could you ask your release engineer to prepare *conventionally named* source tarball? They are not mine. :-D I don't take part in development. I only occasionally send small patches for detected bugs. > E.g., ${PORTNAME}-${PORTVERSION}.tar.bz2 or something similar, but with embedded version, so distfiles for different versions can coexist and be cacheable? I'll ask. > Then why the need for EXTRACT_AFTER_ARGS hack? :) As in the joke: "Just in case, and there are different cases." :-o But you can delete it now.
1.11 already released - I have patch…
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=942e4eb666ff86f08f699b17a812f98f77a6a754 commit 942e4eb666ff86f08f699b17a812f98f77a6a754 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2025-03-05 16:48:04 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2025-03-05 16:48:04 +0000 games/mvdsv: belatedly update the port to version 1.11 - The project was moved under QW-Group GitHub account - Chase commit ac2f79786331 and drop now needless ?= conditional assignments; transfer maintainership - Builds itself with CMake now, hence GC the patches, outdated knobs and options - Install the manual page and some documentation files PR: 280374 Submitted by: vvd games/mvdsv/Makefile | 48 ++++++++++---------- games/mvdsv/distinfo | 6 +-- games/mvdsv/files/patch-Makefile.BSD (gone) | 50 -------------------- ...patch-tools_qwdtools_source_Makefile.BSD (gone) | 53 ---------------------- 4 files changed, 28 insertions(+), 129 deletions(-)
(In reply to Vladimir Druzenko from comment #22) > 1.11 already released Yeah, I've noticed. And now the distfile is more or less sanely named, although it's still rather unconventional, lacks subdirectory (hence NO_WRKSUBDIR) and was apparently prepared under Wind0ze, judging by the line endings. Hopefully, the release process would be further improved. Appreciate your patience, and sorry it took me so long. :-(