mikelo2 reported a new issue against the project: `go-rpm-macros` that you are following: `` Currently there is no option to ship arched devel packages.
The ask is to have a macro, `%go_arched_devel` for example, to allow certain packages's devel package, `golang-x-crypto` for example, to be arched rather than noarch, so package depending on them can benefit from extra performance. The rest of the devel packages that don't declare the macro would be still noarch.
``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/50
jcajka added a new comment to an issue you are following: `` Could you please elaborate on the "golang-x-crypto for example, to be arched rather than noarch, so package depending on them can benefit from extra performance" part? ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/50
mikelo2 added a new comment to an issue you are following: `` My fault @jcajka , it's not the case of `golang-x-crypto`, I meant `golang-github-cloudflare-circl`. I created the ticket after the bi-weekly sig meeting in a rush.
Building `golang-github-cloudflare-circl` fails with the following error in Koji:
``` BuildError: The following noarch package built differently on different architectures: golang-github-cloudflare-circl-devel-1.2.0-1.fc38.noarch.rpm rpmdiff output was: added /usr/share/gocode/src/github.com/cloudflare/circl/dh/x25519/curve_amd64.h added /usr/share/gocode/src/github.com/cloudflare/circl/dh/x448/curve_amd64.h added /usr/share/gocode/src/github.com/cloudflare/circl/ecc/fourq/fp_amd64.h added /usr/share/gocode/src/github.com/cloudflare/circl/ecc/fourq/fq_amd64.h added /usr/share/gocode/src/github.com/cloudflare/circl/ecc/fourq/point_amd64.h added /usr/share/gocode/src/github.com/cloudflare/circl/math/fp25519/fp_amd64.h added /usr/share/gocode/src/github.com/cloudflare/circl/math/fp448/fp_amd64.h ```
``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/50
jcajka added a new comment to an issue you are following: `` @mikelo2 That looks to me more like the packaging issue, possibly issue with some parts of the Go's macros stack. IMHO those files should be include unconditionally on all architectures. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/50
decathorpe added a new comment to an issue you are following: ``
@mikelo2 That looks to me more like the packaging issue, possibly issue with some parts of the Go's macros stack. IMHO those files should be include unconditionally on all architectures.
I agree. This is also how Rust packaging works (i.e. `-devel` packages are truly architecture-independent and contain all source code regardless of the host architecture they were built on).
If that's not possible for Go, then the `-devel` packages should not be `noarch`. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/50
golang@lists.fedoraproject.org
-
Fabio Valentini -
Jakub Čajka
-
Mikel Olasagasti