• Re: Help with complicated go port update (multimedia/navidrome)

    From Kevin Bowling@kevin.bowling@kev009.com to muc.lists.freebsd.ports on Sun Aug 24 10:14:14 2025
    From Newsgroup: muc.lists.freebsd.ports

    On Sat, Aug 23, 2025 at 10:50rC>PM Matthias Fechner <mfechner@freebsd.org> wrote:

    Hi Kevin,

    Am 23.08.2025 um 09:48 schrieb Kevin Bowling:
    I am bumping up against some limits in the ports Go support and
    wondering if anyone can point me in the right direction. I get into
    an unbuildable situation when updating multimedia/navidrome to the
    latest release. I suspect it is modules2tuple needing some
    maintenance as I'm already accumulating some oddities like needing to maintain a "slow porting method" and a modules.txt file outside the
    build.

    I have not checked what you already did, but I also maintain a lot of
    ports that are build with go.

    go.mk can handle all for you, there is no need to use modules2tuple anymore. go.mk will take care to download the dependencies in the fetch phase automatically, you just need the go.mod.
    Hi Matthias,
    I have tried the "fast porting" method and never could get that to
    work here. When you have some time I'd like to take a look at this
    port with you.

    Maybe read the go.mk and/or check ports that I maintain for examples.
    I think it was define the name of the go module, enable go usage of
    modules and maybe some other parameters you must define (please check Mk/Uses/go.mk).

    Sry that I cannot give you a more detailed answer, but my time will be
    the next weeks very limited.

    Hope that helps you.


    Gru|f
    Matthias

    --

    "Programming today is a race between software engineers striving to
    build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." --
    Rich Cook

    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From =?UTF-8?Q?Jes=C3=BAs_Daniel_Colmenares_Oviedo?=@dtxdf@freebsd.org to muc.lists.freebsd.ports on Sun Aug 24 15:23:45 2025
    From Newsgroup: muc.lists.freebsd.ports

    Hi Kevin,

    I have updated Navidrome in my personal tree. You can see the diff here
    [1], however, as you can see, there are things that may not make sense
    to you, such as MASTER_SITES and DISTFILES. This is how I prefer to
    generate assets [2] (so I don't use the Makefile to generate the assets either, which is why I've removed those parts), but you can change it according to your preferences.

    As you can see, GO_MODULE takes on most of the responsibility, which
    greatly simplifies porting. You only need to be aware of the go.mod
    file. Occasionally, you may encounter a project with an outdated go.mod
    file when proxy.golang.org is used. In such cases, you will need to
    retrieve it from the most up-to-date location, such as the upstream repository. See also net/dataplaneapi for an example.

    Just one last note: BROKEN_arm64 seems to be a typo, so I renamed it to BROKEN_aarch64 and portclippy no longer complains. However, reading the reason, perhaps generating the assets outside the ports framework on a compatible arch could help. This might make sense if the assets are just static files.


    [1] https://people.freebsd.org/~dtxdf/patches/navidrome-0.58.0.diff

    [2] https://github.com/DtxdF/port-assets-makejails/blob/main/navidrome/Makejail#L13



    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Adam Weinberger@adamw@adamw.org to muc.lists.freebsd.ports on Sun Aug 24 16:51:49 2025
    From Newsgroup: muc.lists.freebsd.ports


    --Apple-Mail-52884A5F-84AD-4D79-94F1-517486183815
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    It=E2=80=99s been educational watching this thread.=20

    Doing it the Uses/go.mk way is correct. modules2tuples is outdated and doesn= =E2=80=99t produce working output in all cases. It either needs to be improv= ed or to go away completely.=20

    I think we also need better instructions. The section in the PHB (https://do= cs.freebsd.org/en/books/porters-handbook/uses/#uses-go) has great info on th=
    e what, but not the how. If somebody wants to take a whack at improving it, i= t=E2=80=99d make a real difference.=20

    Also, we need an easy way to say =E2=80=9Cuse this go.mod=E2=80=9D (say in $= FILESDIR) and have it DTRT. If somebody wants to look at that, that=E2=80=99=
    d be a huge improvement for go.mk.


    =E2=80=94
    Adam Weinberger
    adamw@adamw.org
    https://www.adamw.org

    On Aug 24, 2025, at 15:23, Jes=C3=BAs Daniel Colmenares Oviedo <dtxdf@free=
    bsd.org> wrote:
    =20
    =EF=BB=BFHi Kevin,
    =20
    I have updated Navidrome in my personal tree. You can see the diff here [1=
    ], however, as you can see, there are things that may not make sense to you,=
    such as MASTER_SITES and DISTFILES. This is how I prefer to generate assets=
    [2] (so I don't use the Makefile to generate the assets either, which is wh=
    y I've removed those parts), but you can change it according to your prefere= nces.
    =20
    As you can see, GO_MODULE takes on most of the responsibility, which great=
    ly simplifies porting. You only need to be aware of the go.mod file. Occasio= nally, you may encounter a project with an outdated go.mod file when proxy.g= olang.org is used. In such cases, you will need to retrieve it from the most=
    up-to-date location, such as the upstream repository. See also net/dataplan= eapi for an example.
    =20
    Just one last note: BROKEN_arm64 seems to be a typo, so I renamed it to BR=
    OKEN_aarch64 and portclippy no longer complains. However, reading the reason=
    , perhaps generating the assets outside the ports framework on a compatible a= rch could help. This might make sense if the assets are just static files.
    =20
    =20
    [1] https://people.freebsd.org/~dtxdf/patches/navidrome-0.58.0.diff
    =20
    [2] https://github.com/DtxdF/port-assets-makejails/blob/main/navidrome/Mak=
    ejail#L13
    =20

    --Apple-Mail-52884A5F-84AD-4D79-94F1-517486183815
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= utf-8"></head><body dir=3D"auto">It=E2=80=99s been educational watching this=
    thread.&nbsp;<div><br></div><div>Doing it the Uses/go.mk way is correct. mo= dules2tuples is outdated and doesn=E2=80=99t produce working output in all c= ases. It either needs to be improved or to go away completely.&nbsp;</div><d= iv><br></div><div>I think we also need better instructions. The section in t= he PHB (<a href=3D"https://docs.freebsd.org/en/books/porters-handbook/uses/#= uses-go">https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-go</a= >) has great info on the what, but not the how. If somebody wants to take a w= hack at improving it, it=E2=80=99d make a real difference.&nbsp;</div><div><= br></div><div>Also, we need an easy way to say =E2=80=9Cuse this go.mod=E2=80= =9D (say in $FILESDIR) and have it DTRT. If somebody wants to look at that, t= hat=E2=80=99d be a huge improvement for go.mk.</div><div><br></div><div><br i= d=3D"lineBreakAtBeginningOfSignature"><div dir=3D"ltr">=E2=80=94<div>Adam We= inberger</div><div>adamw@adamw.org</div><div>https://www.adamw.org</div></di= v><div dir=3D"ltr"><br><blockquote type=3D"cite">On Aug 24, 2025, at 15:23, J= es=C3=BAs Daniel Colmenares Oviedo &lt;dtxdf@freebsd.org&gt; wrote:<br><br><= /blockquote></div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<span>= Hi Kevin,</span><br><span></span><br><span>I have updated Navidrome in my pe= rsonal tree. You can see the diff here [1], however, as you can see, there a= re things that may not make sense to you, such as MASTER_SITES and DISTFILES=
    . This is how I prefer to generate assets [2] (so I don't use the Makefile t=
    o generate the assets either, which is why I've removed those parts), but yo=
    u can change it according to your preferences.</span><br><span></span><br><s= pan>As you can see, GO_MODULE takes on most of the responsibility, which gre= atly simplifies porting. You only need to be aware of the go.mod file. Occas= ionally, you may encounter a project with an outdated go.mod file when proxy= .golang.org is used. In such cases, you will need to retrieve it from the mo= st up-to-date location, such as the upstream repository. See also net/datapl= aneapi for an example.</span><br><span></span><br><span>Just one last note: B= ROKEN_arm64 seems to be a typo, so I renamed it to BROKEN_aarch64 and portcl= ippy no longer complains. However, reading the reason, perhaps generating th=
    e assets outside the ports framework on a compatible arch could help. This m= ight make sense if the assets are just static files.</span><br><span></span>= <br><span></span><br><span>[1] https://people.freebsd.org/~dtxdf/patches/nav= idrome-0.58.0.diff</span><br><span></span><br><span>[2] https://github.com/D= txdF/port-assets-makejails/blob/main/navidrome/Makejail#L13</span><br><span>= </span><br></div></blockquote></div></body></html>=

    --Apple-Mail-52884A5F-84AD-4D79-94F1-517486183815--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2