According to the Change for F27 [0], all golang packages have been rebuilt
against golang 1.9beta2. In the meantime, go 1.9 stable has been released
upstream (Aug. 24, 2017) [1].
I suspect that some of the issues I am having with go / my golang packages
in fedora would be fixed by the update to the final release, since upstream
test suites targeting go 1.9 stable in travis aren't hitting any of those
issues.
What's the plan for rebasing golang to the stable release? The src.fd.org
repository of golang [2] hasn't been touched since the F27 Mass Rebuilds,
and the final update to 1.9 stable isn't mentioned in the Change page at
all ... additionally, the F27 release cycle is progressing more quickly
than I realized (and I suspect some people might not have realized yet
either).
Fabio
[0]: https://fedoraproject.org/wiki/Changes/golang1.9
[1]: https://golang.org/doc/devel/release.html#go1.9
[2]: https://src.fedoraproject.org/rpms/golang/commits/master

According to the Change for F27 [0], all golang packages have been rebuilt against golang
1.9beta2. In the meantime, go 1.9 stable has been released upstream (Aug. 24, 2017) [1].
I suspect that some of the issues I am having with go / my golang packages in fedora
would be fixed by the update to the final release, since upstream test suites targeting go
1.9 stable in travis aren't hitting any of those issues.
What's the plan for rebasing golang to the stable release? The src.fd.org repository
of golang [2] hasn't been touched since the F27 Mass Rebuilds, and the final update to
1.9 stable isn't mentioned in the Change page at all ... additionally, the F27 release
cycle is progressing more quickly than I realized (and I suspect some people might not
have realized yet either).

I believe Jakub is going to finish up the rebase this week. He's been
out for a bit.
josh

From: "Fabio Valentini" <decathorpe(a)gmail.com&gt;
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
Sent: Wednesday, September 13, 2017 8:29:24 PM
Subject: Any plans for completing the go 1.9 rebase (to stable 1.9)?
According to the Change for F27 [0], all golang packages have been rebuilt
against golang 1.9beta2. In the meantime, go 1.9 stable has been released
upstream (Aug. 24, 2017) [1].
I suspect that some of the issues I am having with go / my golang packages in
fedora would be fixed by the update to the final release, since upstream
test suites targeting go 1.9 stable in travis aren't hitting any of those
issues.

Please report those with more details in to BZ or to this list directly, with out report
we can't find the causes and fixed them and anybody hitting them in future will not be
able to avoid or quickly fix them.

What's the plan for rebasing golang to the stable release? The src.fd.org
repository of golang [2] hasn't been touched since the F27 Mass Rebuilds,
and the final update to 1.9 stable isn't mentioned in the Change page at all
... additionally, the F27 release cycle is progressing more quickly than I
realized (and I suspect some people might not have realized yet either).
Fabio

Hi,
BTW I have a set of Go packages I was preparing for inclusion that build fine with Go 1.8
in Epel 7 but not with Go 1.9 in rawhide.
Is there a way to check if it's a problem with the future Go 1.9 toolchain or a
problem in the upstream code? I haven't have the time to investigate yet.
Regards,
--
Nicolas Mailhot

From: "nicolas mailhot"
<nicolas.mailhot(a)laposte.net&gt;
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org&gt;
Sent: Tuesday, October 3, 2017 11:41:09 AM
Subject: Re: Any plans for completing the go 1.9 rebase (to stable 1.9)?
Hi,
BTW I have a set of Go packages I was preparing for inclusion that build fine
with Go 1.8 in Epel 7 but not with Go 1.9 in rawhide.
Is there a way to check if it's a problem with the future Go 1.9 toolchain or
a problem in the upstream code? I haven't have the time to investigate yet.
Regards,
--
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org

It could be literaly anything as EPEL(read also as RHEL 7) and Fedora(27/Rawhide) are
quite different distributions(looking at packages available and their versions).
If you can share build output (and spec file), we should be able to tell more. From big GC
changes(that should be observable at build time) only parallel compilation pops on my mind
as significant change between 1.8 and 1.9, apart of move to Power8+ as minimum
supported(more at https://tip.golang.org/doc/go1.9), but it shouldn't have significant
side effects.
JC

It could be literaly anything as EPEL(read also as RHEL 7) and
Fedora(27/Rawhide) are quite
different distributions(looking at packages available and their versions).

Well I had to package most of the first-level deps myself, and rebuilt the next-level deps
in EPEL to rawhide's level, though I'm sure I missed some bits and didn't have
the time yet to verify all the deps are at the same level.
I tested once or twice by wiping everything but the spec files, spectooling sources, and
rebuilding everything from scratch. So the specs should be sufficient by themselves to
reproduce.

If you can share build output (and spec file), we should be able to
tell more.

No problem, here they are. The aim of the pile of packages is to build the prometheus snmp
exporter. It works flawlessly in EPEL/7 but fails in rawhide with
./main.go:120:14: cannot use kingpin.CommandLine (type *kingpin.Application) as type
*flag.FlagSet in argument to "github.com/prometheus/common/log".AddFlags
WARNING 1
The specs depend on custom macros because I was sick to death of the boilerplate in Fedora
Go spec files (too error-prone for my fat fingers). That makes the specs easier to read
but not to build right now. I hoped to play a little more with the macros before
submitting them to public review. So happy review, I hope you like the result:).
You can not build the packages if the srpm macros are not available when the build system
first reads the spec file. For my needs I just add the package name to the
config_opts['chroot_setup_cmd'] = 'install @buildsys-build'
mock line, I didn't check how to do it in koji yet.
The right way to do this would be to merge the macros in the golang package, make it
export an srpm-macros subpackage, and add the subpackage to the buildsys-build group. That
would also gift you the maintainership of the result in my so cunning plan, sorry about
the surprise, I did expect to introduce you the idea some other way :).
WARNING 2
There is a dependency loop in the set, golang-github-sirupsen-logrus needs building with
bootstrap the first time (I hope I got the Fedora bootstraping conventions right)
All tips, remarks and technical criticism are welcome.
WARNING 3
There are some common_description remnants in the specs. They serve no particular purpose.
They are leftovers from the time I created unit test subpackages, before I decided I
wanted to run the tests in check but not to ship the unit test files once the build is
done.
Regards,
PS
It would be nice if the golang packages were published in a centos or epel repo. Right now
you have to fish them directly from the centos koji instance. And yes I also have access
to paid-for RHEL7 packages.
--
Nicolas Mailhot

Ok, I've found the root problem, there are some obsolete golang packages in rawhide
that override mine (that's the problem when upstream does not version, all the
packages are at version 0, and old code that had its release bumped multiple time during
mass rebuilds takes precedence over newer git commits with a lower release number).
I didn't see the problem in epel 7 because the old code is too new to have propagated
to EL 7.
So I take back the alert over the go 1.9 release. You can still take a look at the go
packaging macros though.
Regards,
--
Nicolas Mailhot

----- Original Message -----
> From: "Fabio Valentini" <decathorpe(a)gmail.com&gt;
> To: "Development discussions related to Fedora" <
devel(a)lists.fedoraproject.org&gt;
> Sent: Wednesday, September 13, 2017 8:29:24 PM
> Subject: Any plans for completing the go 1.9 rebase (to stable 1.9)?
>
> According to the Change for F27 [0], all golang packages have been
rebuilt
> against golang 1.9beta2. In the meantime, go 1.9 stable has been released
> upstream (Aug. 24, 2017) [1].
>
> I suspect that some of the issues I am having with go / my golang
packages in
> fedora would be fixed by the update to the final release, since upstream
> test suites targeting go 1.9 stable in travis aren't hitting any of those
> issues.
Please report those with more details in to BZ or to this list directly,
with out report we can't find the causes and fixed them and anybody hitting
them in future will not be able to avoid or quickly fix them.

I would have done so, but it turned out that the bug / test failure I was
encountering was caused by an old snapshot of "golang.org/x/net" that
wasn't yet compatible with go 1.9 (it's all good now).

>
> What's the plan for rebasing golang to the stable release? The
src.fd.org
> repository of golang [2] hasn't been touched since the F27 Mass Rebuilds,
> and the final update to 1.9 stable isn't mentioned in the Change page at
all
> ... additionally, the F27 release cycle is progressing more quickly than
I
> realized (and I suspect some people might not have realized yet either).
>
> Fabio
As basically it hangs on me and I have been out for over a month it
stalled.
It is done by now(actually in middle of Sep).

I noticed, and I already pushed all the necessary changes to my fedora
packages.
Thanks for your hard work!
Fabio
JC