gotmax23 reported a new issue against the project: `go-rpm-macros` that you are
following:
``
Instead of
```
%files
%license vendor/modules.txt
```
we should allow something like
```
%files
%go_vendor_file vendor/modules.txt
```
where `%go_vendor_file` just expands to `%license`. This way,
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
rpmname: fix use_new_versioning regex
``
https://pagure.io/go-rpm-macros/pull-request/67
--
___
golang mailing list --
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
rpmname: fix use_new_versioning regex
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/67
--
gotmax23 reported a new issue against the project: `go-rpm-macros` that you are
following:
``
Migrate the repo to the fedora/sigs/go gitlab.com namespace like we have for
go2rpm and go-vendor-tools.
``
To reply, visit the link below or just reply to this email
On 3/25/24 18:17, Maxwell G wrote:
I propose we start with fully vendoring the Docker stack. As I said,
parts of moby-engine are already bundled, and so are podman,
kubernetes, cri-o, containernetworking-plugins, and other applications
in the written-in-Go containerization stack. I have been
On Tue Apr 2, 2024 at 17:16 +0200, Dan Čermák wrote:
> Hi Maxwell & Go SIG,
Hi Dan,
Thank you for reaching out!
> we have recently started working on introducing a bundled() provides
> generator for golang in openSUSE and found a very simple solution using
> the output of `go version -m
gotmax23 added a new comment to an issue you are following:
``
Recent versions of the macros are available in EPEL 9
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/2
--
___
golang mailing list --
The status of the issue: `EPEL availability ` of project: `go-rpm-macros` has
been updated to: Closed by gotmax23.
https://pagure.io/go-rpm-macros/issue/2
--
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
gotmax23 added a new comment to an issue you are following:
``
The recommended approach to automatically apply patches is now
```
%goprep -A
%autopatch -p1
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/3
--
The status of the issue: `%goprep should apply patches automatically` of
project: `go-rpm-macros` has been updated to: Closed by gotmax23.
https://pagure.io/go-rpm-macros/issue/3
--
___
golang mailing list -- golang@lists.fedoraproject.org
To
gotmax23 added a new comment to an issue you are following:
``
This is covered by
https://pagure.io/go-rpm-macros/c/bc7e5cc55c4709e8ea56f832d04c3235a25ebf00?branch=master.
At some point, we can completely remove the fallback to the non-`GO_` prefixed
variables and stop disabling
gotmax23 added a new comment to an issue you are following:
``
This should be covered by the the new `%{gobuildflags_shescaped}` macro.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/46
--
___
golang
The status of the issue: `%gobuildflags missing double quotation marks` of
project: `go-rpm-macros` has been updated to: Closed by gotmax23.
https://pagure.io/go-rpm-macros/issue/46
--
___
golang mailing list -- golang@lists.fedoraproject.org
To
The status of the issue: `%license LICENSE vendor/modules.txt fails with
certain module.txt files` of project: `go-rpm-macros` has been updated to:
Closed by gotmax23.
https://pagure.io/go-rpm-macros/issue/64
--
___
golang mailing list --
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
go_mod_vendor.prov: handle local replace directives
``
https://pagure.io/go-rpm-macros/pull-request/65
--
___
golang mailing list --
On Wed Mar 27, 2024 at 16:53 +0100, Mikel Olasagasti wrote:
> Hi Maxwell,
Hi Mikel!
> One doubt about other packages that currently depend on any of the
> packages you list to be vendored.
Yes, that's a good point. Thank you for raising it!
> Checking your containerd spec[1] I see the only the
On Tue Mar 26, 2024 at 21:28 +, Sérgio Basto wrote:
> On Mon, 2024-03-25 at 23:34 +, Sérgio Basto wrote:
> > On Mon, 2024-03-25 at 18:17 -0500, Maxwell G wrote:
> > > I propose we start with fully vendoring the Docker stack. As I
> > > said, parts of moby-engine
://fedora.gitlab.io/sigs/go/go-vendor-tools/
[4]
https://fedora.gitlab.io/sigs/go/go-vendor-tools/scenarios/#security-updates
[5] https://gitlab.com/fedora/sigs/go/go2rpm/-/merge_requests/4
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
golang mailing list
gotmax23 added a new comment to an issue you are following:
``
https://pagure.io/go-rpm-macros/pull-request/65
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/64
--
___
golang mailing list --
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
go_mod_vendor.prov: handle local replace directives
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/65
--
gotmax23 commented on the pull-request: `Use $SOURCE_DATE_EPOCH instead of
random bytes` that you are following:
``
Thanks!
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/63
--
___
golang
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Use $SOURCE_DATE_EPOCH instead of random bytes
``
https://pagure.io/go-rpm-macros/pull-request/63
--
___
golang mailing list --
gotmax23 commented on the pull-request: `Use $SOURCE_DATE_EPOCH instead of
random bytes` that you are following:
``
Cool. Thanks! Can you please rebase this now that other PR has been merged?
This flag has no moved to the `%gobuild_ldflags` definition.
``
To reply, visit the link below or just
gotmax23 commented on the pull-request: `Use $SOURCE_DATE_EPOCH instead of
random bytes` that you are following:
``
Cool. Thanks! Can you please rebase this now that other PR has been merged?
This flag has no moved to the `%gobuild_ldflags` definition.
``
To reply, visit the link below or just
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Add additional gobuildflags macros
``
https://pagure.io/go-rpm-macros/pull-request/62
--
___
golang mailing list --
gotmax23 commented on the pull-request: `Add additional gobuildflags macros`
that you are following:
``
Okay, I did my normal build a hundred random Go packages that currently build
successfully according to Koschei routine in
gotmax23 commented on the pull-request: `Add additional gobuildflags macros`
that you are following:
``
`-trimpath` apparently breaks debuginfo collection, so I'll drop that commit...
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/62
gotmax23 commented on the pull-request: `Use $SOURCE_DATE_EPOCH instead of
random bytes` that you are following:
``
Is it possible for `$SOURCE_DATE_EPOCH` to be undefined? Should this have a
fallback or at least change to `${SOURCE_DATE_EPOCH-}` (in case a packager uses
`set -u` or such)?
``
gotmax23 commented on the pull-request: `Add additional gobuildflags macros`
that you are following:
``
@ngompa, PTAL
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/62
--
___
golang mailing
gotmax23 commented on the pull-request: `Use $SOURCE_DATE_EPOCH instead of
random bytes` that you are following:
``
@alexsaezm, @jcajka, PTAL
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/63
--
gotmax23 commented on the pull-request: `Use $SOURCE_DATE_EPOCH instead of
random bytes` that you are following:
``
This PR and https://pagure.io/go-rpm-macros/pull-request/62 conflict, so one of
them will have to be rebased.
``
To reply, visit the link below or just reply to this email
gotmax23 commented on the pull-request: `Add additional gobuildflags macros`
that you are following:
``
> You mean `$GO_LDFLAGS`?
Yes. Thanks!
> Does this supersede #41?
I think so. I really want to avoid pushing breaking changes to macros without a
deprecation period.
``
To reply, visit
gotmax23 added a new comment to an issue you are following:
``
See https://pagure.io/go-rpm-macros/pull-request/62.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/46
--
___
golang mailing list --
gotmax23 commented on the pull-request: `Add additional gobuildflags macros`
that you are following:
``
See https://src.fedoraproject.org/rpms/aerc/pull-request/6 for example usage.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/62
--
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Add additional gobuildflags macros
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/62
--
___
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
%goprep: allow using %autosetup for automatic source unpacking
``
https://pagure.io/go-rpm-macros/pull-request/61
--
___
golang
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
go_mod_vendor: use raw string for regex
``
https://pagure.io/go-rpm-macros/pull-request/60
--
___
golang mailing list --
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
%goprep: allow using %autosetup for automatic source unpacking
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/61
--
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
go_mod_vendor: use raw string for regex
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/60
--
On Tue Jan 9, 2024 at 17:30 +, Maxwell G wrote:
> Hi everyone,
>
> RPM has deprecated the `%patchN` syntax in favor of `%patch -PN` where
> `N` is the patch number. See the RPM documentation for more information
> [1]. In current RPM versions, this syntax only emits a deprec
commit/afd352481bacea521ce5ba01e989866478278532
[3]
https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/new_patch_syntax.sh
[4]
https://git.sr.ht/~gotmax23/fedora-scripts/tree/main/item/go-sig/new_patch_syntax/packages
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
golang m
eam settings as comments.
Ah, now I see what you mean. Yes, we should definitely update those comments.
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email
B, and it's
lacking clear instructions about how to change the values back to
defaults.
[1]:
https://src.fedoraproject.org/rpms/golang/blob/rawhide/f/0001-Modify-go.env.patch
[2]:
https://developer.fedoraproject.org/tech/languages/go/go-installation.html#fedora-specific-notes
--
Maxwell G (@gotmax
y data to Google without explicit
opt-in. We can highlight in the documentation how to re-eanble GOPROXY
and GOSUMDB if necessary.
--
Maxwell G (@gotmax23)
Pronouns: He/They
--
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an
gotmax23 commented on the pull-request: `[go-rpm-macros-epel] Add
macros.go-compilers-golang override` that you are following:
``
Building go-rpm-macros-epel-3.3.0.4-1.el9 for epel9-candidate
Created task: 110526094
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=110526094
``
To
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
[go-rpm-macros-epel] Add macros.go-compilers-golang override
``
https://pagure.io/go-rpm-macros/pull-request/59
--
___
golang mailing
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
[go-rpm-macros-epel] Add macros.go-compilers-golang override
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/59
--
The status of the issue: `exclude md files from install` of project: `golist`
has been updated to: Closed as Fixed by gotmax23.
https://pagure.io/golist/issue/32
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
Ack. Let's ship it!
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/56
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
Thanks @eclipseo for all your work on this! I'm good with this approach. I have
some comments about the go2rpm side, but I think we can merge and release the
go-rpm-macros
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
> > Also, this is a breaking change that I would not feel comfortable
> > backporting to stable branches, whether Fedora or (EP)EL.
>
> I don't understand why for stable
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
> The exception should be the incorrect behavior, not the correct. I dont want
> to add yet another flag to gometa that could be easily forgotten while it
> should be the
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
See my (only lightly tested) suggestion in
https://pagure.io/fork/gotmax23/go-rpm-macros/commits/alt_fix_goname.
``
To reply, visit the link below or just reply to this
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
> Also, it'd be better to add an argument to the rpmname over using an RPM
> macro for this.
Hmm, that's not as easy as it looks. This would also require passing the flag
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
To copy what I wrote on Matrix:
> eclipseo: on mobile, but I think it should be the other way around. the old
> behavior should stay to preserve backwards compatibility.
>
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
I'd add a new flag to configure whether or not to use the new naming scheme and
remove the hardcoded list.
``
To reply, visit the link below or just reply to this email
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
> - @tibbs won't approve package with -version anymore
That's not exactly how I interpreted that comment. I left
gotmax23 commented on the pull-request: `Fix goname generation to match
versioning guildelines` that you are following:
``
> Won't this break existing packages that use %{goname} for the name of the
> source package?
Yeah, I was about to write the same thing.
We cannot change this without
e, AFAIK.
I think someone will have to write a script to generate a custom archive
without any BUSL code in it like we do for non-free/patent encumbered
code in ffmpeg.
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
golang mailing list -- golang@
gotmax23 reported a new issue against the project: `go-rpm-macros` that you are
following:
``
`%gopkginstall` creates a `.goipath` file in
`%{buildroot}%{gopath}/%{goipath}/.goipath` that contains some metadata that's
used by the RPM generators later in the build process. These are not needed
as a dependency for a project you're working on packaging or
have another valid reason to opt out a package.
Thanks!
On Sat Feb 18, 2023 at 21:01 +, Maxwell G wrote:
> Hi Fedorians,
>
> Changes/Mass_Retire_Golang_Leaves [1] has been approved by FESCo. As
> part of this Change, all Go libr
sk info: https://koji.fedoraproject.org/koji/taskinfo?taskID=98095101
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedorapro
gotmax23 added a new comment to an issue you are following:
``
Can you please provide the full specfile? We can't do anything if we can't
reproduce your issue.
``
To reply, visit the link below or just reply to this email
https://pagure.io/golist/issue/31
a PR. I've merged
and built this for rawhide.
--
Maxwell G (@gotmax23)
Pronouns: He/They
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://d
y-maintainer
Thank you for your cooperation,
--
Maxwell G (@gotmax23)
Pronouns: He/They
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.
On Fri Feb 3, 2023 at 01:42 +, Maxwell G wrote:
> (see the attachment)
Here it is!
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
diff --git a/blocker.patch b/blocker.patch
new file mode 100644
index 000..76999f4
--- /dev/null
+++ b/blocker.patch
@@ -0,0 +1,24 @@
+F
ackage to the
buildroot doesn't work. I also built a modified go-rpm-macros to ensure
that blocker is pulled in (see the attachment); %gometa explicitly adds
`BuildRequires: blocker` to specfiles and every go-rpm-macros subpackage
has `Requires: blocker`. I already found a couple false positives.
--
gotmax23 added a new comment to an issue you are following:
``
You cannot cannot set arbitrary RPM tags.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/issue/51
___
golang mailing list --
On Wed Jan 11, 2023 at 13:58 +0100, Miro Hrončok wrote:
> golang-github-d2g-dhcp4servereclipseo, go-sig
I need a package review to fix this:
https://bugzilla.redhat.com/show_bug.cgi?id=2160202
--
Maxwell G (@gotmax23)
Pronouns: He/Him/
/#_bundled_or_unbundled
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
golang mailing list -- golang@lists.fedoraproject.org
To unsubscribe send an email to golang-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US
On Fri Sep 2, 2022, Maxwell G via devel wrote:
>
> Sep 2, 2022 5:36:41 AM Fabio Valentini :
>
> > Does anybody know whether olem still wants to maintain their Fedora
> > packages?
> I'm fairly sure that they no longer wish to maintain Fedora packages. I
> reached ou
} --whatrequires
golang-github-containerd-cri-devel
(nothing)
[1]: https://github.com/containerd/cri/blob/release/1.4/README.md
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/Him/His
signature.asc
Description: PGP signature
___
golang mailing list -- golang
gotmax23 closed without merging a pull-request against the project:
`go-rpm-macros` that you
are following.
Closed pull-request:
``
Use Fedora's build flags for cgo.
``
https://pagure.io/go-rpm-macros/pull-request/47
___
golang mailing list --
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Add RPM generator for bundled Provides
``
https://pagure.io/go-rpm-macros/pull-request/49
___
golang mailing list --
gotmax23 commented on the pull-request: `Add RPM generator for bundled
Provides` that you are following:
``
I will plan to merge this tomorrow if nobody has any other comments. I am also
working on creating an go-rpm-macros-epel package that contains certain macro
backports to EPEL. This will
gotmax23 commented on the pull-request: `Add RPM generator for bundled
Provides` that you are following:
``
cc @decathorpe. The modifications are licensed under the same license as the
project. I can keep it under the UNLICENSE if you really want.
``
To reply, visit the link below or just
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Add RPM generator for bundled Provides
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/49
___
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Introduce %golang_arches_future and stop using %go_arches
``
https://pagure.io/go-rpm-macros/pull-request/48
___
golang mailing list
gotmax23 commented on the pull-request: `Introduce %golang_arches_future and
stop using %go_arches` that you are following:
``
> lgtm, although, won't we need to go back to all the -f created once we are
> out of ix86 completely?
That or make it no-op and print deprecation warnings. I think we
gotmax23 commented on the pull-request: `Introduce %golang_arches_future and
stop using %go_arches` that you are following:
``
> lgtm, although, won't we need to go back to all the -f created once we are
> out of ix86 completely?
That or make it no-op and print deprecation warnings. I think we
gotmax23 commented on the pull-request: `Introduce %golang_arches_future and
stop using %go_arches` that you are following:
``
> lgtm, although, won't we need to go back to all the -f created once we are
> out of ix86 completely?
That or make it no-op and print deprecation warnings. I think we
gotmax23 commented on the pull-request: `Introduce %golang_arches_future and
stop using %go_arches` that you are following:
``
Related PRs:
- distgit repo: https://src.fedoraproject.org/rpms/go-rpm-macros/pull-request/8
- go2rpm: https://pagure.io/GoSIG/go2rpm/pull-request/21
``
To reply,
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Introduce %golang_arches_future and stop using %go_arches
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/48
gotmax23 commented on the pull-request: `Use Fedora's build flags for cgo.`
that you are following:
``
> I rebuilt all go packages that contain binaries (generated in the same way
> that I used for the CVE rebuilds) with this applied to go-rpm-macros in
>
gotmax23 commented on the pull-request: `Use Fedora's build flags for cgo.`
that you are following:
``
This part needs to be fixed
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/47
___
golang
gotmax23 commented on the pull-request: `Use Fedora's build flags for cgo.`
that you are following:
``
I rebuilt all go packages that contain binaries (generated in the same way that
I used for the CVE rebuilds) in
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Use Fedora's build flags for cgo.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/47
___
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
srpm/go.lua meta: Set `%gourl` after `forge.meta` call
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/45
gotmax23 commented on the pull-request: `rpm/macros.d: use linkmode=external`
that you are following:
``
@ngompa. are you still planning to merge this?
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/43
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Stop using deprecated %__global_ldflags macro.
``
https://pagure.io/go-rpm-macros/pull-request/44
___
golang mailing list --
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Stop using deprecated %__global_ldflags macro.
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/44
gotmax23 commented on the pull-request: `[RFC] rpm/macros.d: use
linkmode=external` that you are following:
``
@alexsaezm and @jcajka, is there any reason that we shouldn't add this to
Fedora? It looks it's already present in the c9s go-rpm-macros package.
``
To reply, visit the link below or
gotmax23 commented on the pull-request: `Undefine _auto_set_build_flags in
%gocheck definition` that you are following:
``
I am creating a new release with this change along with the `Add missing
expand` commit cherry-picked from your PR.
``
To reply, visit the link below or just reply to this
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Undefine _auto_set_build_flags in %gocheck definition
``
https://pagure.io/go-rpm-macros/pull-request/42
___
golang mailing list --
gotmax23 commented on the pull-request: `Try again to fix failures with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck` that you are
following:
``
> It seems that this is failing on packages that contain `%gocheck` but not
> `%gobuild`, because `%undefine
gotmax23 opened a new pull-request against the project: `go-rpm-macros` that
you are following:
``
Undefine _auto_set_build_flags in %gocheck definition
``
To reply, visit the link below or just reply to this email
https://pagure.io/go-rpm-macros/pull-request/42
gotmax23 commented on the pull-request: `Try again to fix failures with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck` that you are
following:
``
It seems that this is failing on packages that contain `%gocheck` but not
`%gobuild`, because `%undefine _auto_set_build_flags` is
gotmax23 commented on the pull-request: `Try again to fix failures with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck` that you are
following:
``
Are you sure that you're using the latest version of `go-rpm-macros` that I
pushed to Rawhide in your copr? I did not see this
gotmax23 merged a pull-request against the project: `go-rpm-macros` that you
are following.
Merged pull-request:
``
Try again to fix failures with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
``
https://pagure.io/go-rpm-macros/pull-request/40
gotmax23 commented on the pull-request: `Try again to fix failures with
https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck` that you are
following:
``
This looks good to me. I tested it on copr and confirmed that it works properly.
``
To reply, visit the link below or just reply
1 - 100 of 104 matches
Mail list logo
