Bug#867058: [pkg-golang-devel] Bug#867058: golang-1.8 and mips*

[Michael Hudson-Doyle]

On 27 October 2017 at 22:38, James Cowgill  wrote:

> Hi,
>
> On 26/10/17 20:33, John Paul Adrian Glaubitz wrote:
> > On 10/26/2017 07:12 PM, peter green wrote:
> >> Therefore golang maintainers you have two choices.
> >>
> >> 1. Accept John's changes so that your package can be built on mips*.
> >> 2. File a removal request for the binaries uploaded by John
> >
> > I assume that gccgo on mips is still broken as this situation hasn't
> changed,
> > so I would suggest removing the packages again. I can file a bug for that
> > since I am the one who is responsible that these packages are there in
> the
> > first place.
>
> gccgo was fixed in gcc-7 a few weeks ago and I've filed a bug against
> golang-1.9 already. Since golang-defaults already points to golang-1.9
> in unstable, I am guessing that older versions are now irrelevant for mips.
>
> I suggest:
> - Apply the patch in #879764 to golang-1.9.
>

LGTM.


> - Remove the mips binaries from golang-1.8 (or remove 1.8 entirely).
>

I think we should remove the mips binaries.


> - Enable mips in golang-defaults.
>

+1


> A reply from the golang maintainers would be very helpful in all of this...
>

Sorry for the lack of response. I have to admit that I've found the whole
issue very confusing to follow but I'm very grateful to the people who've
put the effort in to make the simple patch attached to #879764 all that is
required!

Cheers,
mwh

Bug#867058: golang-1.8 and mips*

[James Cowgill]

Hi,

On 26/10/17 20:33, John Paul Adrian Glaubitz wrote:
> On 10/26/2017 07:12 PM, peter green wrote:
>> Therefore golang maintainers you have two choices.
>>
>> 1. Accept John's changes so that your package can be built on mips*.
>> 2. File a removal request for the binaries uploaded by John
> 
> I assume that gccgo on mips is still broken as this situation hasn't changed,
> so I would suggest removing the packages again. I can file a bug for that
> since I am the one who is responsible that these packages are there in the
> first place.

gccgo was fixed in gcc-7 a few weeks ago and I've filed a bug against
golang-1.9 already. Since golang-defaults already points to golang-1.9
in unstable, I am guessing that older versions are now irrelevant for mips.

I suggest:
- Apply the patch in #879764 to golang-1.9.
- Remove the mips binaries from golang-1.8 (or remove 1.8 entirely).
- Enable mips in golang-defaults.

A reply from the golang maintainers would be very helpful in all of this...

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#867058: golang-1.8 and mips*

[John Paul Adrian Glaubitz]

On 10/26/2017 07:12 PM, peter green wrote:
> Therefore golang maintainers you have two choices.
> 
> 1. Accept John's changes so that your package can be built on mips*.
> 2. File a removal request for the binaries uploaded by John

I assume that gccgo on mips is still broken as this situation hasn't changed,
so I would suggest removing the packages again. I can file a bug for that
since I am the one who is responsible that these packages are there in the
first place.

>> > I was under the impression that the golang maintainers want all 
>> > architectures
>> > bootstrapped from gccgo? This was the reason mips64el support was not in 
>> > stretch despite upstream support for it. If a normal bootstrap would have 
>> > been acceptable,
>> > I would have done it ages ago.
>>
>> Why? What difference does it make? If a different bootstrapping compiler
>> results in a different golang compiler after a second rebuild, there is
>> something wrong with the compiler anyway.
> Self-bootstrapping compilers create a maintenance burden. When things go
> wrong they sometimes can't be fixed through source package changes alone.

Correct me if I'm wrong, but most compilers I know of in Debian are self-
bootstrapping. I recently started working on rustc and that one needs itself
to be built, the same applies for fpc - which you co-maintain - GHC, and 
OpenJDK,
for example. So, I am confident to say that the build system for the golang
packages is not the norm but an exception.

Also, since gccgo is apparently known to produce broken code, I am not sure
I would consider it a good idea to use it as the compiler to build the golang
packages.

> Porterboxes are also of limited utility because you can't install non-archive
> packages on them.

That's correct. But you are forgetting that there is the possibility that
compilers can be cross-compiled on amd64 and for most compilers, that
works pretty well. In fact, there are efforts by people like Helmut Grohne,
whom I support in this effort, to make Debian as a whole more cross-buildable.

> Then there are derivatives to consider, if a self-bootstrapping compiler
> gets broken in a derivative that rebuilds everything then finding someone
> who can un-jam it can be a pain.

I'm not really sure whether I want to accept this argument. I am developing
for Debian and in Debian and I don't see why my work should be limited by
any derivative.

> Whether to take on that burden should be a decision for the maintainers of
> the package, not for some flyby contributer.

That "flyby contributor" you are talking about is maintaining most ports
architectures and has already fixed tons of issues on the various architectures
in Debian. So while I sometimes make mistakes like these, my net contributions
to Debian are hugely positive.

And, as we say in German, "Wo gehobelt wird, da fallen Späne" or, as you
would say in English, "You can't make an omelette without breaking eggs".

In short, if you are touching lots of things in Debian and helping out
at many fronts, you will make such mistakes from time to time. I admit
it was a mistake and I apologize for that. But that still doesn't give
you the right to call me a "flyby contributor".

>> Odd. Last time I did this for fpc [1], you were actually very happy. Now
>> you're getting upset despite the only changes actually necessary are
>> two lines changed in debian/control.in and debian/helpers/goenv.sh.
>>
>> What's the difference now?
> 
> We are happy that you are working on getting packages ported to your 
> architecture.

Who is "we"?

> What we are not happy about is how you are doing it. You need to ensure
> that source goes to the archive either before or at the same time as the 
> binaries and
> you need to either coordinate with maintainers or (if the maintainers are 
> unresponsive)
> follow the normal NMU guidelines.

If it wasn't for me, FPC would still probably not bootstrapped on mips* and m68k
yet and FPC upstream wouldn't have had the possibility to work on the SPARC64
port which they did on hardware that I helped to provide. Again, I am doing so
much for Debian, that I find it a bit unfair that you are preaching me like 
this.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#867058: golang-1.8 and mips*

[peter green]

severity 867058 serious
severity 867059 serious
severity 867062 serious
thanks

Hi golang maintainers.

Some time ago John Paul Adrian Glaubitz uploaded some golang binaries for mips, 
mipsel and mips64el to the Debian archive which were not built from slightly 
modified Debian source packages. At the same time he posted a description of 
the changes needed (but no actual machine-readable patches) he used as bug 
reports. These bug reports received no maintainer response. His binaries 
migrated to testing.

Having binaries that were not built from the unmodified Debian sources is a 
serious policy violation. Furthermore these now-outdated binaries are 
preventing any newer versions of the golang-1.8 package migrating to testing.

Therefore golang maintainers you have two choices.

1. Accept John's changes so that your package can be built on mips*.
2. File a removal request for the binaries uploaded by John

The remainder of this mail addresses some questions asked by John in response 
to statements from James Cowgill


> I was under the impression that the golang maintainers want all architectures 
bootstrapped from gccgo? This was the reason mips64el support was not in
> stretch despite upstream support for it. If a normal bootstrap would have 
been acceptable, I would have done it ages ago.

Why? What difference does it make? If a different bootstrapping compiler
results in a different golang compiler after a second rebuild, there is
something wrong with the compiler anyway.

Self-bootstrapping compilers create a maintenance burden. When things go wrong 
they sometimes can't be fixed through source package changes alone. Porterboxes 
are also of limited utility because you can't install non-archive packages on 
them. Then there are derivatives to consider, if a self-bootstrapping compiler 
gets broken in a derivative that rebuilds everything then finding someone who 
can un-jam it can be a pain.

Whether to take on that burden should be a decision for the maintainers of the 
package, not for some flyby contributer.


> Please can you actually discuss this with the package maintainers and mips 
porters _before_ you do anything like this again. You should also read the mips
> related go bugs filed against various golang packages.

Odd. Last time I did this for fpc [1], you were actually very happy. Now
you're getting upset despite the only changes actually necessary are
two lines changed in debian/control.in and debian/helpers/goenv.sh.

What's the difference now?


We are happy that you are working on getting packages ported to your 
architecture.

What we are not happy about is how you are doing it. You need to ensure that 
source goes to the archive either before or at the same time as the binaries 
and you need to either coordinate with maintainers or (if the maintainers are 
unresponsive) follow the normal NMU guidelines.