Bug#879123: glee: source for configure is missing

[Miriam Ruiz]

The original configure.ac file seems to ve available in
http://elf-stone.com/downloads/GLee/GLee-3.03-redist.tar.gz

I am attaching it to this mail.

Greetings,
Miry


2017-10-20 17:24 GMT+02:00 Simon McVittie <smcv at debian.org>:
> On Fri, 20 Oct 2017 at 16:22:38 +0200, Markus Koschany wrote:
>> So you are basically saying that the situation for configure scripts is
>> less clear-cut and you tend to acknowledge that this is a bug but
>> usually not a release critical one and it also depends on how the
>> copyright holder is treating the generated file.
>
> I only partially agree with this summary; I think it's still in
> danger of conflating two issues.
>
> I think having both configure and configure.ac in the source tarball,
> using upstream's pre-generated configure without re-generating it, but
> having its source code present, is usually a bug but not a RC one.
> A concrete example from one of my packages: if I'm reading my old
> changelog correctly, dbus (<< 1.4.10-1) was buggy in this way, but I
> don't think that bug was RC.
>
> However, I think having configure but not configure.ac is usually
> a RC bug, due to DFSG §2. (Exceptional case: if upstream genuinely treats
> configure as though it was source - hand-editing it, etc. - then I
> would consider it to be technically misguided, but DFSG-compliant.)
>
>> What do you make of this specific case now, a modifiable but unused
>> configure file in a source package? Would you remove this file from one
>> of your packages given the same circumstances? Is this release-critical
>> for you?
>
> I would be annoyed to have to take action for something this trivial
> (so I can understand why you are annoyed), but yes, I think it's RC and
> requires a +dfsg1 tarball.
>
> I wouldn't be in any hurry to fix that bug for prior releases unless
> someone in the stable release team felt strongly about it, though -
> we shipped it already, and it isn't a copyright violation, only a
> DFSG violation (breaking the rules we set for ourselves, but not the law).
>
>> However I do not think the same
>> severity is appropriate for Windows files because they are platform
>> specific and usually are only there for the convenience of upstream's
>> windows users. They waste disk space but do not impair my freedom.
>
> This depends whether those Windows convenience files come with DFSG
> source code or not. If they do, fine, we can accept the "dead weight",
> just like we don't bother to remove the pre-generated configure from
> source packages where we are going to overwrite it with dh-autoreconf
> anyway.
>
> If there is no source code, my understanding is that derived files
> without source are equally forbidden by the ftp team regardless of
> whether they are used in building our binary packages or not. One
> justification for this position is that it is not just about your
> freedom to modify what will go into the binary package, but also about
> recipients of source code via Debian being able to be confident that
> everything they receive is equally DFSG-compliant (for example, in
> the past I've cross-compiled Debian's libexpat for Windows as part of
> a test environment for dbus). That's consistent with the requirement
> that we remove distributable-but-non-Free files like RFCs from source
> tarballs even if they aren't used in the binaries, which is another
> frequently-disagreed-with but consistently-applied policy.
>
> I personally think the project is sometimes too absolutist in its
> interpretation of DFSG §2, but I think I'd have trouble establishing
> consensus for any less draconian interpretation. Establishing consensus
> for "grey areas" is always difficult, because you get into questions
> about where to draw the line, and I don't have a good answer to those
> questions beyond "I know an (un)acceptable package when I see one",
> which is not particularly principled or defensible.
>
> It's entirely possible that an absolutist position is in fact the
> pragmatic thing to do, because establishing consensus about the right
> line to draw would be more effort than repacking some tarballs :-)
>
>> Looking at
>> https://lintian.debian.org/tags/source-contains-prebuilt-windows-binary.html
>> I can still see that we have more than 1000 source packages in the
>> archive that ship those files. So I think you are not correct if you
>> claim that we treat them as release-critical bugs at the moment
>> otherwise I would expect this Lintian tag to be an error not a pedantic
>> issue.
>
> I'm surprised this tag is so low-priority, to be honest: I would have
> expected the DFSG-maximalist faction among Debian contributors to have
> made it at least a warning. Presumably the assumption is that those
> prebuilt Windows binaries all come with source code, otherwise they would
> have been rejected at NEW time?
>
> Regards,
>     smcv
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac
Type: application/octet-stream
Size: 938 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20180110/38bfb5cd/attachment-0001.obj>