New version of Hugo, new dependencies

[W. Michael Petullo]

I have some review requests for Go packages that are required for Hugo
0.147.3:

https://bugzilla.redhat.com/show_bug.cgi?id=2366312
https://bugzilla.redhat.com/show_bug.cgi?id=2366320

I have COPR builds of all of this, including the new Hugo package and
an update to the existing golang-github-bep-godartsass2 package:

https://copr.fedorainfracloud.org/coprs/mikep/golang/builds/

[Mikel Olasagasti]

Hi Mike,

FYI, members of Go-SIG plan to propose vendoring dependencies as the
default method to package Golang packages.

This is the draft of the document:
https://fedoraproject.org/wiki/Changes/GolangPackagesVendoredByDefault

Being Hugo a complex package it's safe to start using go-vendor-tools
as is done with other complex packages like moby-engine or helm right
now.

If you prefer to keep Hugo with the current method I can review those two BZs.

Best regards,
Mikel

Hau idatzi du W. Michael Petullo via golang
([e-mail]) erabiltzaileak (2025 mai. 14(a), az.
(23:05)):
> I have some review requests for Go packages that are required for Hugo
> 0.147.3:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2366312
> https://bugzilla.redhat.com/show_bug.cgi?id=2366320
>
> I have COPR builds of all of this, including the new Hugo package and
> an update to the existing golang-github-bep-godartsass2 package:
>
> https://copr.fedorainfracloud.org/coprs/mikep/golang/builds/
>
> --
> Mike
> :wq
>
> golang mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[W. Michael Petullo]

> FYI, members of Go-SIG plan to propose vendoring dependencies as the
> default method to package Golang packages.
>
> This is the draft of the document:
> https://fedoraproject.org/wiki/Changes/GolangPackagesVendoredByDefault

I would like to experiment with go2rpm's vendor profile. I am trying to
use it to build a Hugo package with vendored dependencies. I think I
have figured out how to "correct" licenses the tool does not autodetect.
However, one of the required modules, github.com/gohugoio/testmodBuilder,
does not contain a license file at all, at least in the version go2rpm
grabs.

How do I handle this?

Running this:

go_vendor_license --config go-vendor-tools.toml explicit --f vendor/github.com/gohugoio/testmodBuilder/mods/COPYING MIT

seems to complain that vendor/github.com/gohugoio/testmodBuilder/mods/COPYING does not exist.
(It does not.)

[Alejandro Saez Morollon]

On Thu, May 15, 2025 at 12:51 AM W. Michael Petullo via golang <
[e-mail]> wrote:
> > FYI, members of Go-SIG plan to propose vendoring dependencies as the
> > default method to package Golang packages.
> >
> > This is the draft of the document:
> > https://fedoraproject.org/wiki/Changes/GolangPackagesVendoredByDefault
>
> I would like to experiment with go2rpm's vendor profile. I am trying to
> use it to build a Hugo package with vendored dependencies. I think I
> have figured out how to "correct" licenses the tool does not autodetect.
> However, one of the required modules, github.com/gohugoio/testmodBuilder,
> does not contain a license file at all, at least in the version go2rpm
> grabs.
>
> How do I handle this?
>
> Running this:
>
> go_vendor_license --config go-vendor-tools.toml explicit --f vendor/
> http://github.com/gohugoio/testmodBuilder/mods/COPYING
> github.com/gohugoio/testmodBuilder
> http://github.com/gohugoio/testmodBuilder/mods/COPYING/mods/COPYING
> http://github.com/gohugoio/testmodBuilder/mods/COPYING MIT
>
> seems to complain that vendor/
> github.com/gohugoio/testmodBuilder/mods/COPYING does not exist.
> (It does not.)

In this case, I think you should point to the LICENSE file at the top level
of the project ->
https://github.com/gohugoio/testmodBuilder/blob/master/LICENSE
> --
> Mike
> :wq
>
> golang mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[W. Michael Petullo]

> In this case, I think you should point to the LICENSE file at the top level
> of the project ->
> https://github.com/gohugoio/testmodBuilder/blob/master/LICENSE

This file is not in the version of the repository pulled by go2rpm.
However, I figured out that I can place it in the root of the package
directory (not in the -vendor tarball) and reference it from there.

Should the license field in the .spec file contain the license for hugo's
source code or should it contain the union of all of the licenses found
across all of the imported packages? The non-vendor-versioned form of
the hugo package used the former.

Now I am stuck on github.com/tetratelabs/wazero, which presently has
a "proper" package. Building wazero using the vendor-versioned process
fails. This raises the point that things are occasionally difficult to
package (e.g., many of the modernc.org packages), and this trouble will
be duplicated in each vendor-versioned package. Is there a way to tell
go2rpm to use a few external packages by exception?

Not another question, but a point: I suspect that license checking
and intellectual property matters will be difficult. For example, some
of the modernc.org packages are open source but contain example files
that Fedora cannot include. Figuring this out and pulling those example
files from the package takes care. This care will have to be duplicated
when building vendor-versioned packages. (Of course, the difficultly of
properly packaging each dependency might exceed this work.)

[Brad Smith]

Greetings

On Thu, May 15, 2025 at 6:51 AM W. Michael Petullo via golang
 wrote:
> Should the license field in the .spec file contain the license for hugo's
> source code or should it contain the union of all of the licenses found
> across all of the imported packages? The non-vendor-versioned form of
> the hugo package used the former.

The union is what I do. See, for example,  the docker-buildx spec file
at https://src.fedoraproject.org/rpms/docker-buildx/blob/rawhide/f/docker-build....
Buildx uses the Apache-2.0 license itself and the license expression
for the package is the union.

I also find for a vendored package like docker-buildkit that some of
the golang test files will fail as the test might try a network
access, for example. Check the docker-buildkit spec file
(https://src.fedoraproject.org/rpms/docker-buildkit/blob/rawhide/f/docker-bui...)
for a mechanism to skip specific tests and well as the gocheck flags
to skip directories or directory trees.

Brad