Bug#617931: gmsh: multiple licensing issues

[Adam D. Barratt]

On Thu, 2012-09-20 at 00:47 +0200, Francesco Poli wrote:
> On Wed, 19 Sep 2012 23:19:07 +0100 Adam D. Barratt wrote:
> 
> > On Tue, 2012-09-18 at 19:48 +0200, Francesco Poli wrote:
> > > I think that this part of the issue will be relevant for the m68k
> > > architecture, as long as gmsh is still distributed for that unofficial
> > > architecture.
> > > Something that is *not* legally distributable does *not* magically
> > > become distributable, just because the architecture is not officially
> > > supported by the Debian Project...
> > 
> > m68k is not just "unofficial" or "not officially supported".  It's not
> > been part of Debian, nor hosted on debian.org systems, since sarge was
> > archived.  Debian is not distributing any packages on m68k and what
> > others might be doing on that architecture is not relevant to RC bugs in
> > Debian.
[...]
> I thought that ftp.debian-ports.org was an official Debian Project
> service for unsupported architectures:
> http://ftp.debian-ports.org/debian/pool-m68k/main/g/gmsh/
> includes
> http://ftp.debian-ports.org/debian/pool-m68k/main/g/gmsh/gmsh_2.3.0.dfsg-1_m68k.deb

I'm not arguing that the package isn't on debian-ports.  I'm arguing
that said fact is irrelevant in the context of this bug report.

> That's why I claimed that the Debian Project is still distributing
> gmsh/2.3.0.dfsg-1 built for the m68k architecture...

To the best of my knowledge, debian-ports is not a Debian project
service.  It's run by a Debian Developer but that's not quite the same.
I assume there's a reason that it's still debian-ports.org (on
a .debian.net machine) and not X.debian.org.  I'm happy to be corrected
though.

In any case, that's beside the point.  The Debian BTS exists to track
the status of bugs in the official Debian archive, as defined by
ftp-master.  Bugs in packages on backports.d.o, security.d.o or
debian-ports are not tracked there (there's a reasonable argument that
at least some of them should be, but the fact is that they're not).

The BTS is also perfectly capable of tracking where within the official
archive a bug has been resolved - even if m68k were still hosted on
ftp-master, once the bug had been closed by the upload of an updated
package then the next relevant action would be to ensure that the
package were either built or removed on m68k.  Neither of those courses
of action requires the bug to be re-opened, nor would doing so be
appropriate.

Similarly, if the bug exist(s|ed) in stable, there'd be no need to
re-open the bug as the BTS would already be aware that stable still
contained the issue.

Regards,

Adam