El Wed, 13 Mar 2024 18:08:04 +
Stuart Henderson escribió:
> On 2024/03/13 13:33, Jose Maldonado wrote:
> >
> > Hi list!
> >
> > I've seen a new update to fast_float (library required for the new
> > libplacebo and mpv) that could affect the 7.5 and -current package
> > builds due to a change in the project's Github.
>
> Unimportant for release, it's on the bulk build machines already, and
> is on one of the fallback distfiles sites.
Excellent!
>
> > The change has been added through a commit [1] that fixes a typo in
> > the version of the project in CmakeList.txt, but from upstream
> > instead of creating a new version (6.1.1), they have decided to
> > include the change and keep calling the version as 6.1.0, breaking
> > the old distinfo.
>
> That's a nuisance, it would be helpful if projects wouldn't do that.
It seems like a mistake to me, they should have made a version 6.1.1,
marking the correction with it.
>
> That's not the only change - float_common.h was modified too, so it
> will also need a REVISION bump.
>
> https://github.com/fastfloat/fast_float/commit/55a5b3c8e136a6f55cbb13829f284bdc7150567c
> #include
> #include
> #ifdef __has_include
> - #if __has_include()
> + #if __has_include() && (__cplusplus > 202002L ||
> _MSVC_LANG > 202002L) #include
>#endif
> #endif
>
Sorry, I had not seen such a change in the source.
> > This patch solves the problem and unlocks the port build.
>
> The distfile needs to be renamed via the filename{url}sufx mechanism
> if the contents have changed. Builds are done from machines with
> varying states of the ports tree (it's common to have the build
> machine for one arch on one ports checkout and another on a newer one
> - except for the special case of release builds, this is the normal
> situation). For the main build machines there's a common distfiles
> directory shared over NFS, so it's a problem if one machine fetches a
> new file to match what it needs, while another is still building and
> expecting an old version.
>
> A diff something like this will work, though if there's a new version
> upstream before we're ready to reopen commits we might as well just
> change to that instead.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/fast-float/Makefile,v
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 13 Feb 2024 19:45:52 - 1.1.1.1
> +++ Makefile 13 Mar 2024 18:00:59 -
> @@ -2,9 +2,11 @@ COMMENT =fast and exact implementation
>
> V = 6.1.0
> PKGNAME =fast-float-${V}
> +REVISION = 0
> GH_TAGNAME = v${V}
> GH_ACCOUNT = fastfloat
> GH_PROJECT = fast_float
> +DISTFILES = fast_float-{v}${V}-0.tar.gz
>
> CATEGORIES = devel
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/fast-float/distinfo,v
> diff -u -p -r1.1.1.1 distinfo
> --- distinfo 13 Feb 2024 19:45:52 - 1.1.1.1
> +++ distinfo 13 Mar 2024 18:00:59 -
> @@ -1,2 +1,2 @@
> -SHA256 (fast_float-6.1.0.tar.gz) =
> qcjKjKfWjC27E0Q0BE+cZs/Uw4PV6Fw2twTTD2voJQY= -SIZE
> (fast_float-6.1.0.tar.gz) = 95974 +SHA256 (fast_float-6.1.0-0.tar.gz)
> = WmKeHxjwN60AFsQerWMOpHHMy832AjntNGbEkdjnyQg= +SIZE
> (fast_float-6.1.0-0.tar.gz) = 96104
>
Thanks for the explanation @sthen. Regarding the possibility of a new
version of fast_float before the new version of 7.5 comes out, this is
unlikely, and we should stick to v6.1.0.
In any case, my initial concern was the fact that the builds packages
would have some problem downloading the distfile and will encounter an
error due to the change of the file, and that this will block the
construction of the packages dependent on it.
Your explanation of how build packages work eliminates this problem,
but leaves us with the problem of package evolution and its strange
decisions when listing versions.
I have tried the change you have made, all work without problem.
--
*
Dios en su cielo, todo bien en la Tierra
