From: Brad Smith Subject: Re: dist tuple support for code.videolan.org To: Thomas Frohwein Cc: ports@openbsd.org Date: Wed, 14 Oct 2026 21:20:36 -0400 On 2026-10-14 9:07 p.m., Thomas Frohwein wrote: > On Wed, 14 Oct 2026 19:10:41 -0400 > Brad Smith wrote: > >> ping. >> >> On 2026-09-26 6:43 p.m., Brad Smith wrote: >>> Here is an inital attempt at adding dist tuple support for >>> code.videolan.org. >>> >>> I also have a port pending for librist. >>> >>> Which uses `DIST_TUPLE= videolan rist librist v0.2.20 .` >>> >>> The dist-tuple.port.mk part is to deal with the tarball >>> provided by Gitlab as it adds a Git hash to the wrkdist >>> directory. >>> > In principle yes, but can this wait a little longer as forthcoming > update to DIST_TUPLE when ready should especially simplify the > post-extract stuff rather than adding more custom cases. > > Comments below, but unless there is urgency to this switch for > multimedia/x264, can this wait for DIST_TUPLE update? x264 is just an example of another port that could use the dist tuple so I can use the proper upstream instead of the Github mirror I made. The port I'm waiting for this for I mentioned above. > >>> Before: >>> drwxr-xr-x 11 brad brad 512 Jul 29 23:39 >>> librist-v0.2.20-4f45ef8f78983892d52ccd52d9f675435b23738f >>> >>> After: >>> drwxr-xr-x 11 brad brad 512 Jul 29 23:39 librist-0.2.20 >>> >>> >>> Index: infrastructure/db/dist-tuple.pattern >>> =================================================================== >>> RCS file: /cvs/ports/infrastructure/db/dist-tuple.pattern,v >>> retrieving revision 1.13 >>> diff -u -p -u -p -r1.13 dist-tuple.pattern >>> --- infrastructure/db/dist-tuple.pattern 16 Jan 2026 >>> 06:12:28 -0000 1.13 +++ >>> infrastructure/db/dist-tuple.pattern 26 Sep 2026 20:13:09 >>> -0000 @@ -6,6 +6,7 @@ SITES.gitlab ?= https://gitlab.com/ >>> SITES.kde ?= https://invent.kde.org/ SITES.srht ?= >>> https://git.sr.ht/ SITES.gnome ?= https://gitlab.gnome.org/ >>> +SITES.videolan ?= https://code.videolan.org/ >>> >>> # set EXTRACT_SUFX.x if different from TEMPLATE_EXTRACT_SUFX >>> TEMPLATE_EXTRACT_SUFX ?= .tar.gz >>> @@ -35,6 +36,9 @@ TEMPLATE_DISTFILES.kde ?= \ >>> >>> TEMPLATE_DISTFILES.srht ?= \ >>> --{~//archive/}${EXTRACT_SUFX.srht} >>> + >>> +TEMPLATE_DISTFILES.videolan ?= \ >>> + >>> --{//-/archive/}${EXTRACT_SUFX.videolan} >>> # template for HOMEPAGE; same substitutions as for DISTFILES.x >>> # Defaults to TEMPLATE_HOMEPAGE. Set TEMPLATE_HOMEPAGE.x to use >>> different pattern. Index: infrastructure/mk/dist-tuple.port.mk >>> =================================================================== >>> RCS file: /cvs/ports/infrastructure/mk/dist-tuple.port.mk,v >>> retrieving revision 1.22 >>> diff -u -p -u -p -r1.22 dist-tuple.port.mk >>> --- infrastructure/mk/dist-tuple.port.mk 1 Apr 2026 15:14:57 >>> -0000 1.22 +++ infrastructure/mk/dist-tuple.port.mk >>> 26 Sep 2026 20:13:09 -0000 @@ -47,6 +47,11 @@ >>> MODDIST-TUPLE_post-extract += \ t=${WRKDIST}/${_targetdir}; [[ -d >>> $$t ]] && rmdir $$t \ || mkdir -p `dirname $$t` ; \ >>> mv ${WRKDIR}/${_project:T} $$t; >>> +. elif "${_subdir}" == "refs/tags/" && "${_template}" == >>> "videolan" +MODDIST-TUPLE_post-extract += \ > Not sure about the origin of this logic. These post-extract additions > are generally for when there is a targetdir (so not '.'), but yours is > for when there is a tagname (not commit hash) as id. Yes, Gitlab appends a Git hash to the tagname dir which the infrastructure doesn't know how to deal with. > > >>> + t=${WRKDIST}; [[ -d $$t ]] && rmdir $$t \ >>> + || mkdir -p `dirname $$t` ; \ >>> + mv ${WRKDIR}/${_project:T}-${_id}-* $$t; >>> . elif "${_targetdir}" != "." >>> MODDIST-TUPLE_post-extract += \ >>> t=${WRKDIST}/${_targetdir}; [[ -d $$t ]] && rmdir $$t \ >>> Index: multimedia/x264/Makefile >>> =================================================================== >>> RCS file: /cvs/ports/multimedia/x264/Makefile,v >>> retrieving revision 1.73 >>> diff -u -p -u -p -r1.73 Makefile >>> --- multimedia/x264/Makefile 11 Feb 2026 20:59:39 >>> -0000 1.73 +++ multimedia/x264/Makefile 26 Sep 2026 >>> 20:13:09 -0000 @@ -1,9 +1,8 @@ >>> COMMENT= free H.264/MPEG-4 AVC encoder >>> >>> -DISTNAME= x264-20250909 >>> -GH_ACCOUNT= brad0 >>> -GH_PROJECT= x264 >>> -GH_COMMIT= 0480cb05fa188d37ae87e8f4fd8f1aea3711f7ee >>> +DIST_TUPLE= videolan videolan x264 >>> 0480cb05fa188d37ae87e8f4fd8f1aea3711f7ee . +PKGNAME= > Your example doesn't use a tagname id, and it doesn't use a targetdir. > I think above, you probably mean to use the other logic > ("${_targetdir}" != "."). I anticipate your proposed diff breaks when > using videolan with a tagname id. I mentioned it at the top. No, it works just fine. That's what I added it for. > >>> x264-20250909 +REVISION= 0 >>> CATEGORIES= multimedia >>> >>> SHARED_LIBS= x264 26.0 >>> Index: multimedia/x264/distinfo >>> =================================================================== >>> RCS file: /cvs/ports/multimedia/x264/distinfo,v >>> retrieving revision 1.30 >>> diff -u -p -u -p -r1.30 distinfo >>> --- multimedia/x264/distinfo 11 Feb 2026 20:59:39 >>> -0000 1.30 +++ multimedia/x264/distinfo 26 Sep 2026 >>> 20:13:09 -0000 @@ -1,2 +1,2 @@ >>> -SHA256 (x264-20250909-0480cb05.tar.gz) = >>> 0JZ6E0jIXf3jY7tSYQQDvomBcUkxAFYe+g3QXV/RrlA= -SIZE >>> (x264-20250909-0480cb05.tar.gz) = 1040667 +SHA256 >>> (videolan-x264-0480cb05fa188d37ae87e8f4fd8f1aea3711f7ee.tar.gz) = >>> 0JZ6E0jIXf3jY7tSYQQDvomBcUkxAFYe+g3QXV/RrlA= +SIZE >>> (videolan-x264-0480cb05fa188d37ae87e8f4fd8f1aea3711f7ee.tar.gz) = >>> 1040667