<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>severity 867058 serious<br>
severity 867059 serious<br>
severity 867062 serious<br>
thanks<br>
<br>
Hi golang maintainers.</p>
<p>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.<br>
<br>
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.<br>
<br>
Therefore golang maintainers you have two choices.<br>
<br>
1. Accept John's changes so that your package can be built on
mips*.<br>
2. File a removal request for the binaries uploaded by John<br>
<br>
The remainder of this mail addresses some questions asked by John
in response to statements from James Cowgill
<blockquote type="cite">
<pre class="message">> 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.</pre>
</blockquote>
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.</p>
<p>Whether to take on that burden should be a decision for the
maintainers of the package, not for some flyby contributer.</p>
<p>
<blockquote type="cite">
<pre class="message">> 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?
</pre>
</blockquote>
</p>
<p>We are happy that you are working on getting packages ported to
your architecture.</p>
<p>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.</p>
<p><br>
</p>
</body>
</html>