>
> Sorry for the late replies, I've been busier than expected last week.
>
> For that error I found that Brad already hit the same issue in
> https://github.com/cri-o/cri-o/issues/8860#issuecomment-2558287657 and
> fixed by applying "%global __golang_extldflags -Wl,-z,undefs" after
> %build in
Mikel,
I am still experimenting with building a Hugo package using
go-vendor-tools. I have had some success, but the
github.com/tetratelabs/wazero dependency is causing problems.
Looking at the wazero .spec, the build has some special requirements,
but I do not know how to apply these to wazero as
> 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 packa
> 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
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
Thank you for the heads up. I fixed the Hugo package, and I proposed a
patch upstream:
https://github.com/gohugoio/hugo/pull/13285
--
Mike
:wq
--
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@l
>> I have some review requests for Go packages that are required for Hugo
>> 0.140.1:
>> https://bugzilla.redhat.com/show_bug.cgi?id=2334845
> Needs some changes.
Revision published to original bug report.
Thank you for the quick work! The Hugo 0.140.2 package is ready, pending
me completing th
I have some review requests for Go packages that are required for Hugo
0.140.1:
https://bugzilla.redhat.com/show_bug.cgi?id=2334845
https://bugzilla.redhat.com/show_bug.cgi?id=2334847
https://bugzilla.redhat.com/show_bug.cgi?id=2334848
Additionally, I have a merge request pending for the gitmap p
The latest version of golang-modernc-libc requires
"golang(github.com/ncruces/go-strftime)" on architectures other
than md64, arm64, and loong64. I have a package proposal for
golang-github-ncruces-strftime here:
https://bugzilla.redhat.com/show_bug.cgi?id=2290418
This is a go2rpm package, so it
I have some review requests for Go packages that are required for Hugo
0.124.0:
https://bugzilla.redhat.com/show_bug.cgi?id=2269893
https://bugzilla.redhat.com/show_bug.cgi?id=2269901
Once these are approved, I will update our Hugo package to 0.124.0.
I am working through updating the existing pa
>> I have two questions related to Go package updates-devel:
>>
>> (1) The goipath github.com/bep/clock is now github.com/bep/clocks, as of
>> clock version 0.5.0 (note the plural clocks in the later goipath). How
>> should I handle this? Does this warrant a new package request?
> The correct thi
> With the new naming schema the "-2" is dropped in favour of just "2".
> You can check with the following command:
>
> $ go2rpm github.com/bep/godartsass/v2 -f
> https://github.com/bep/godartsass -v 2.0.0
> golang-github-bep-godartsass2.spec
>
> You need to rename the BZ to have the new name.
O
I have two questions related to Go package updates-devel:
(1) The goipath github.com/bep/clock is now github.com/bep/clocks, as of
clock version 0.5.0 (note the plural clocks in the later goipath). How
should I handle this? Does this warrant a new package request?
(2) I have the following updates
> Can you use go2rpm-1.10 to generate the specs?
I regenerated each package using go2rpm. This left
golang-github-bep-godartsass with a -2.0.0 suffix, which I thought too
exclusive when compared to -2. Is this right?
--
Mike
:wq
--
___
golang mailing
My Hugo package continues to gobble up more dependencies. The following
are available for review, and they are required before I can package
Hugo 0.121.1:
golang-github-tj-spin:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2256316
golang-github-tj-kinesis:
https://bugzilla.redhat.com/bug
> I created 17 review requests and a PR to split current
> golang-cloud-google into modules. This is required in order to update
> other packages required by Google's SDK.
>
> The plan is:
>
> 1) have all this reviewed & approved
> 2) build all modules in bootstrap mode to avoid cyclic dependenci
>> I recently finished packaging the dependencies for golang-modernc-sqlite,
>> and so I am trying to build golang-modernc-sqlite using "fedpkg build". I
>> received an error that I am not familiar with:
>>
>> 107041465 build (rawhide,
>> /rpms/golang-modernc-sqlite.git:4e124a5404385a63af99570ce90c
I recently finished packaging the dependencies for golang-modernc-sqlite,
and so I am trying to build golang-modernc-sqlite using "fedpkg build". I
received an error that I am not familiar with:
107041465 build (rawhide,
/rpms/golang-modernc-sqlite.git:4e124a5404385a63af99570ce90cbaa7bdf4c722): o
I have submitted a number of Go package for review, with the aim of
eventually updating other packages that now require them, such as
golang-github-azure-sdk and golang-cloud-google. Of these, strutil and
sortutil are un-retire requests.
golang-github-jwt-5:
https://bugzilla.redhat.com/bugzilla/s
Someone just orphaned the golang-cloud-google package package. I am
interested in this package because it appears to be an indirect
dependency for Hugo. The note at
https://src.fedoraproject.org/rpms/golang-cloud-google states:
"Orphaned for: Other -- Updates to this package have a cascading list
Did something big happen to the Rawhide golang packages?
I received a series of emails indicating that the dependencies for many
of my packages failed to resolve. I also tried to build my hugo package
using mock, and I received this:
Error:
Problem 1: package golang-gocloud-devel-0.24.0-4.fc38~
>> I would like to see golang-github-bep-godartsass updated so that I can
>> update Fedora's Hugo package to the latest release. Would anyone be
>> willing to help with this? I have submitted a merge request, but it is
>> sitting idle:
>>
>> https://src.fedoraproject.org/rpms/golang-github-bep-goda
I would like to see golang-github-bep-godartsass updated so that I can
update Fedora's Hugo package to the latest release. Would anyone be
willing to help with this? I have submitted a merge request, but it is
sitting idle:
https://src.fedoraproject.org/rpms/golang-github-bep-godartsass/pull-reque
> I have two packages for which I'd like to offer to swap reviews:
>
> 1) Bug 2135036 - Review Request: golang-github-sajari-fuzzy
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2135036
>
> This is a new dependency blocking an update to one of my existing (Go)
> packages. Autogenerated sp
I maintain a number of Go packages for Fedora, including Hugo. I find that
the default use of -x and -v when running "go build" makes it difficult to
diagnose compile problems. A compile error does not necessarily terminate
the Go build process, and with -x and -v the error message is quickly
lost
25 matches
Mail list logo