Index | Thread | Search

From:
Brad Smith <brad@comstyle.com>
Subject:
Re: dist tuple support for code.videolan.org
To:
Thomas Frohwein <tfrohwein@fastmail.com>
Cc:
ports@openbsd.org
Date:
Wed, 14 Oct 2026 21:20:36 -0400

Download raw body.

Thread
On 2026-10-14 9:07 p.m., Thomas Frohwein wrote:
> On Wed, 14 Oct 2026 19:10:41 -0400
> Brad Smith <brad@comstyle.com> 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 ?= \
>>>    	<account>-<project>-{~<account>/<project>/archive/}<id>${EXTRACT_SUFX.srht}
>>> +
>>> +TEMPLATE_DISTFILES.videolan ?= \
>>> +
>>> <account>-<project>-{<account>/<project>/-/archive/}<id>${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