Proposal: remove %ix86 from golang_arches for F37

[Robert-André Mauchin]

Hi,

So the change deadline is very soon, so I'd like a quick answer on this.

So Fedora is dropping i686 in the near future, only plsnning to support Wine related thingie 
as far as I know. Could we too make a move toward this by dropping %ix86 from our supported 
arches?

Most Go dev don't bother to do check build on 32 bits platforms and thus we find out many 
bugs when building on these arches. arm32 was dropped, now we only have i686 as the 
remaining 32 bits arch, removing it would reduce the time spent on bugs and failed builds.

What's your take on it Go Folks? Please answer relaively quickly as we don't have much time 
before changes deadline.

Best regards,

Robert-André

[Florian Weimer]

* Robert-André Mauchin:
> So Fedora is dropping i686 in the near future, only plsnning to
> support Wine related thingie as far as I know.

I don't think this is actually true.
> Could we too make a move toward this by dropping %ix86 from our
> supported arches?
>
> Most Go dev don't bother to do check build on 32 bits platforms and
> thus we find out many bugs when building on these arches. arm32 was
> dropped, now we only have i686 as the remaining 32 bits arch, removing
> it would reduce the time spent on bugs and failed builds.

Will the Go tools remain usable for building 32-bit programs?  Can we
still reproduce 32-bit bugs on Fedora after this change?

Thanks,
Florian

[Maxwell G]

On Wednesday, June 29, 2022 4:10:14 PM CDT Robert-André Mauchin wrote:
> Could we too make a move toward this by dropping %ix86 from our supported
> arches?

I think it's worthwhile to remove our go libraries and applications. They are not included included in multilib*, and Fedora is no longer released for 32-bit x86., so they are not actually included in the composed content.

My question is: How do we plan to go about this? Will we simply remove `%ix86` from `%golang_arches` right before the mass rebuild?

On Thursday, June 30, 2022 4:38:02 AM CDT Florian Weimer wrote:
> Will the Go tools remain usable for building 32-bit programs?  Can we
> still reproduce 32-bit bugs on Fedora after this change?

As I said, golang and the go libs/applications* aren't even shipped in composes. The only way to access these builds is through koji/the buildroot repo. However, go already has first class support for cross compiling built in, so the packages built for %ix86 aren't really needed for this purpose.

```
$ sudo dnf repoquery -q --repo=rawhide --arch=i686 | grep golang| wc -l
0

$ sudo dnf repoquery -q --repo rawhide,rawhide-source --whatrequires golang --recursive | grep '.src$' | pkgname | sort | uniq | xargs sudo dnf repoquery -q --repo rawhide --latest-limit 1 --arch=i686

deepin-pw-check-0:5.1.6-1.fc37.i686
graphviz-0:4.0.0-8.fc37.i686
```

* There are only two packages that buildrequire golang that are still shipped for multilib.

[Bob Mauchin]

On Sat, Jul 2, 2022, 01:58 Maxwell G  wrote:
> On Wednesday, June 29, 2022 4:10:14 PM CDT Robert-André Mauchin wrote:
> > Could we too make a move toward this by dropping %ix86 from our supported
> > arches?
>
> I think it's worthwhile to remove our go libraries and applications. They
> are not included included in multilib*, and Fedora is no longer released
> for 32-bit x86., so they are not actually included in the composed content.
>
> My question is: How do we plan to go about this? Will we simply remove
> `%ix86` from `%golang_arches` right before the mass rebuild?
>
> On Thursday, June 30, 2022 4:38:02 AM CDT Florian Weimer wrote:
> > Will the Go tools remain usable for building 32-bit programs?  Can we
> > still reproduce 32-bit bugs on Fedora after this change?
>
> As I said, golang and the go libs/applications* aren't even shipped in
> composes. The only way to access these builds is through koji/the buildroot
> repo. However, go already has first class support for cross compiling built
> in, so the packages built for %ix86 aren't really needed for this purpose.
> $ sudo dnf repoquery -q --repo=rawhide --arch=i686 | grep golang| wc -l
> 0
>
> $ sudo dnf repoquery -q --repo rawhide,rawhide-source --whatrequires
> golang --recursive | grep '\.src$' | pkgname | sort | uniq | xargs sudo dnf
> repoquery -q --repo rawhide --latest-limit 1 --arch=i686
>
> deepin-pw-check-0:5.1.6-1.fc37.i686
> graphviz-0:4.0.0-8.fc37.i686
> There are only two packages that buildrequire golang that are still
>
> shipped for multilib.
>
> --
> Thanks,
>
> Maxwell G (@gotmax23)
> Pronouns: He/Him/His

First the change window is closed. I'll ask if we indeed need a change for
that.
Second we can keep golang the package on i686 but drop all others golang
libraries and binaries?

Best regards,

Robert-André
>

[Maxwell G]

On Saturday, July 2, 2022 3:38:01 AM CDT Bob Mauchin wrote:
> First the change window is closed. I'll ask if we indeed need a change for
> that.

Are you talking about the F37 System-Wide Change deadline? I think it's still 
worth trying to get in, but we can always punt it to F38. We could propose it 
as a F37 self-contained Change. We still have until Tue 2022-07-19 for that.

I think we would need a Change proposal. This is more than just dropping a 
couple leaf packages. We'd be dropping the entire go stack.

I did some more repoquery'ing, and made a list of all (or at least most) of 
the affected runtime recursive dependents:

antlr4-cpp-runtime-0:4.10.1-2.fc37.i686 - antlr4-project-4.10.1-2.fc37.src.rpm
----------
antlr4-cpp-runtime-devel-0:4.10.1-2.fc37.i686

antlr4-cpp-runtime-devel-0:4.10.1-2.fc37.i686 - antlr4-
project-4.10.1-2.fc37.src.rpm
----------

deepin-pw-check-0:5.1.6-1.fc37.i686 - deepin-pw-check-5.1.6-1.fc37.src.rpm
----------
deepin-control-center-0:5.4.70-5.fc37.i686
deepin-control-center-devel-0:5.4.70-5.fc37.i686
deepin-dock-0:5.5.9-3.fc37.i686
deepin-dock-devel-0:5.5.9-3.fc37.i686
deepin-pw-check-devel-0:5.1.6-1.fc37.i686

deepin-pw-check-devel-0:5.1.6-1.fc37.i686 - deepin-pw-
check-5.1.6-1.fc37.src.rpm
----------

godep-unit-test-devel-0:62-16.fc36.i686 - godep-62-16.fc36.src.rpm
----------

gomtree-unit-test-devel-0:0.4.0-11.fc37.i686 - gomtree-0.4.0-11.fc37.src.rpm
----------

graphviz-0:4.0.0-8.fc37.i686 - graphviz-4.0.0-8.fc37.src.rpm
----------
ImageMagick-1:6.9.12.52-1.fc37.i686
ImageMagick-c++-1:6.9.12.52-1.fc37.i686
ImageMagick-c++-devel-1:6.9.12.52-1.fc37.i686
ImageMagick-devel-1:6.9.12.52-1.fc37.i686
ImageMagick-libs-1:6.9.12.52-1.fc37.i686
WINGs-devel-0:0.95.9-8.fc36.i686
WINGs-libs-0:0.95.9-8.fc36.i686
WindowMaker-0:0.95.9-8.fc36.i686
WindowMaker-devel-0:0.95.9-8.fc36.i686
a2ps-0:4.14-50.fc36.i686
autotrace-0:0.31.1-63.fc36.i686
autotrace-devel-0:0.31.1-63.fc36.i686
cutter-re-0:2.1.0-1.fc37.i686
cutter-re-devel-0:2.1.0-1.fc37.i686
digikam-devel-0:7.6.0-2.fc37.i686
digikam-libs-0:7.6.0-2.fc37.i686
eom-0:1.26.0-5.fc36.i686
eom-devel-0:1.26.0-5.fc36.i686
fawkes-core-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-devel-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-firevision-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-guis-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-lua-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-amcl-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-clips-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-execution-time-estimator-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-gazebo-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-navgraph-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-navgraph-generator-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-openni-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-rrd-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-skiller-0:1.3.1-0.36.f9f66dd.fc37.i686
fawkes-plugin-webview-0:1.3.1-0.36.f9f66dd.fc37.i686
flowcanvas-0:0.7.1-38.fc36.i686
flowcanvas-devel-0:0.7.1-38.fc36.i686
fontforge-0:20220308-2.fc37.i686
fontforge-devel-0:20220308-2.fc37.i686
freewrl-0:4.3.0-11.20200221gite99ab4a.fc36.i686
freewrl-devel-0:4.3.0-11.20200221gite99ab4a.fc36.i686
gazebo-0:10.1.0-30.fc37.i686
gazebo-devel-0:10.1.0-30.fc37.i686
gazebo-libs-0:10.1.0-30.fc37.i686
gazebo-ode-0:10.1.0-30.fc37.i686
gazebo-ode-devel-0:10.1.0-30.fc37.i686
graphviz-devel-0:4.0.0-8.fc37.i686
graphviz-devil-0:4.0.0-8.fc37.i686
graphviz-gd-0:4.0.0-8.fc37.i686
graphviz-gtk2-0:4.0.0-8.fc37.i686
iaito-0:5.6.0-0.5.20220303gitb8a42d8.fc37.i686
iaito-devel-0:5.6.0-0.5.20220303gitb8a42d8.fc37.i686
kgraphviewer-devel-0:2.4.3-8.fc36.i686
kgraphviewer-libs-0:2.4.3-8.fc36.i686
kscope-0:1.9.4-36.20170716git98db2b4.fc36.i686
kscope-devel-0:1.9.4-36.20170716git98db2b4.fc36.i686
libEAI-0:4.3.0-11.20200221gite99ab4a.fc36.i686
libEAI-devel-0:4.3.0-11.20200221gite99ab4a.fc36.i686
libyui-qt-devel-0:4.2.16-5.fc37.i686
libyui-qt-graph-0:4.2.16-5.fc37.i686
libyui-qt-graph-devel-0:4.2.16-5.fc37.i686
psiconv-0:0.9.8-37.fc36.i686
psiconv-devel-0:0.9.8-37.fc36.i686
pstoedit-0:3.78-4.fc37.i686
pstoedit-devel-0:3.78-4.fc37.i686
synfig-0:1.5.1-2.fc37.i686
synfig-devel-0:1.5.1-2.fc37.i686
synfigstudio-0:1.5.1-1.fc37.i686
synfigstudio-devel-0:1.5.1-1.fc37.i686
valadoc-0:0.56.1-1.fc37.i686
valadoc-devel-0:0.56.1-1.fc37.i686
wdune-0:1.958-7.fc35.i686
wdune-devel-0:1.958-7.fc35.i686
yosys-0:0.18-1.20220611gitb15a46c.fc37.i686
yosys-devel-0:0.18-1.20220611gitb15a46c.fc37.i686

graphviz-devel-0:4.0.0-8.fc37.i686 - graphviz-4.0.0-8.fc37.src.rpm
----------
valadoc-devel-0:0.56.1-1.fc37.i686

graphviz-devil-0:4.0.0-8.fc37.i686 - graphviz-4.0.0-8.fc37.src.rpm
----------
graphviz-devel-0:4.0.0-8.fc37.i686
valadoc-devel-0:0.56.1-1.fc37.i686

graphviz-gd-0:4.0.0-8.fc37.i686 - graphviz-4.0.0-8.fc37.src.rpm
----------
graphviz-devel-0:4.0.0-8.fc37.i686
valadoc-devel-0:0.56.1-1.fc37.i686

graphviz-gtk2-0:4.0.0-8.fc37.i686 - graphviz-4.0.0-8.fc37.src.rpm
----------
graphviz-devel-0:4.0.0-8.fc37.i686
valadoc-devel-0:0.56.1-1.fc37.i686

yggdrasil-devel-0:0.2.98^1.ffb580f-0.2.20220127gitffb580f.fc37.i686 - 
yggdrasil-0.2.98^1.ffb580f-0.2.20220127gitffb580f.fc37.src.rpm
----------

deepin-pw-check, godep, mtree, and yggdrasil BuildRequire other go libraries, 
while graphviz and antlr4 only need golang. The rest of the golang dependents 
are not shipped.
> Second we can keep golang the package on i686 but drop all others golang
> libraries and binaries?

It would be great if we could drop everything. If that's not feasible, we 
could change golang's ExclusiveArch directive to `ExclusiveArch: %
{golang_arches} %{ix86}` after we remove %ix86 from %golang_arches.

[Florian Weimer]

* Maxwell G.:
> On Thursday, June 30, 2022 4:38:02 AM CDT Florian Weimer wrote:
> > Will the Go tools remain usable for building 32-bit programs?  Can we
> > still reproduce 32-bit bugs on Fedora after this change?
>
> As I said, golang and the go libs/applications* aren't even shipped in
> composes. The only way to access these builds is through koji/the
> buildroot repo. However, go already has first class support for cross
> compiling built in, so the packages built for %ix86 aren't really
> needed for this purpose.

Hmm.  I was wondering if you could use GOARCH=i386 to build i386
binaries from the x86-64 compose, but apparently not.

Thanks,
Florian

[Maxwell G]

On Tuesday, July 5, 2022 5:37:21 AM CDT Florian Weimer wrote:
> Hmm.  I was wondering if you could use GOARCH=i386 to build i386
> binaries from the x86-64 compose, but apparently not.

It's GOARCH=386.

[Florian Weimer]

* Maxwell G.:
> On Tuesday, July 5, 2022 5:37:21 AM CDT Florian Weimer wrote:
> > Hmm.  I was wondering if you could use GOARCH=i386 to build i386
> > binaries from the x86-64 compose, but apparently not.
>
> It's GOARCH=386.

Ah, okay, and that works with the x86_64 packages, too.

Thanks,
Florian

[Alejandro Saez Morollon]

On Wed, Jun 29, 2022 at 11:10 PM Robert-André Mauchin  wrote:
> Hi,
>
> So the change deadline is very soon, so I'd like a quick answer on this.
>
> So Fedora is dropping i686 in the near future, only plsnning to support Wine related thingie
> as far as I know. Could we too make a move toward this by dropping %ix86 from our supported
> arches?
>
> Most Go dev don't bother to do check build on 32 bits platforms and thus we find out many
> bugs when building on these arches. arm32 was dropped, now we only have i686 as the
> remaining 32 bits arch, removing it would reduce the time spent on bugs and failed builds.
>
> What's your take on it Go Folks? Please answer relaively quickly as we don't have much time
> before changes deadline.

I'm totally ok with this.
> Best regards,
>
> Robert-André
> _______________________________________________
> 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 on the list, report it: https://pagure.io/fedora-infrastructure