Bug#879123: glee: source for configure is missing

[Miriam Ruiz]

2018-01-10 17:26 GMT+01:00 Steve Cotton :
> I think the only solution is to port Fife and Sludge to use the khronos-api 
> package, and drop GLee completely.

Sounds like a suitable plan. It makes sense.

Greetings,
Miry

Bug#879123: glee: source for configure is missing

[Steve Cotton]

Although this GLee bug is fixable, there's another that isn't:

Bug#879905: glee: source for GLee.c and GLee.h is missing

I think the only solution is to port Fife and Sludge to use the khronos-api 
package, and drop GLee completely.

Steve

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 :
> 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
>


configure.ac
Description: Binary data

Bug#879123: glee: source for configure is missing

[Simon McVittie]

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

Bug#879123: glee: source for configure is missing

[Markus Koschany]

Am 20.10.2017 um 15:26 schrieb Simon McVittie:
> On Fri, 20 Oct 2017 at 14:36:06 +0200, Markus Koschany wrote:
>> If you insist on severity
>> serious for such a problem, then bug reports with the same severity
>> should be filed against packages
>>
>>  a) that do not recreate their build system at build time
>>  b) all packages that contain a prebuilt object without corresponding
>> source, even when they are not used to build the package, or used at
>> runtime (like .dll and .exe files)
> 
> I don't think those are the same thing at all, and I think trying to
> equate them clouds the issue.

Thanks for your reply. I think we are on the same page. My two points
were exaggerated on purpose meaning I also believe that this topic
deserves a more differentiated point of view which you delivered.

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.

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?

[...]
>>  b) all packages that contain a prebuilt object without corresponding
>> source, even when they are not used to build the package, or used at
>> runtime (like .dll and .exe files)
> 
> That's my (3.) above, and I think there is consensus that it is a
> release-critical bug. We remove these objects when we find them.
> 
> (If I am wrong about that, then I can stop repacking the Quake series of
> game engines to exclude prebuilt Windows DLLs... but I would not want
> to do that without approval from the ftp team, and the ftp team seem
> highly unlikely to give that approval.)

[...]

Just for clarification: I completely agree that we should remove those
files whenever we can. I have done the same in all of my packages and I
am even more picky when it comes to prebuilt jar files in my Java
packages because there is a real possibility that they are used by
accident during the build process. 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.

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.

And this is why it is frustrating for me to read bug reports like this
one, where we have just a modifiable text file but there are arguably
more severe issues right before our eyes. Therefore my plea to use
appropriate severity levels.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#879123: glee: source for configure is missing

[Simon McVittie]

On Fri, 20 Oct 2017 at 14:36:06 +0200, Markus Koschany wrote:
> If you insist on severity
> serious for such a problem, then bug reports with the same severity
> should be filed against packages
> 
>  a) that do not recreate their build system at build time
>  b) all packages that contain a prebuilt object without corresponding
> source, even when they are not used to build the package, or used at
> runtime (like .dll and .exe files)

I don't think those are the same thing at all, and I think trying to
equate them clouds the issue.

If we have a generated/derived file in source packages, there are three
possibilities:

1. Source code is provided, and we regenerate the generated file from it
   (for example, if the generated file is configure, we have configure.ac
   and we run dh-autoreconf; or if the generated file is a binary,
   we have the C/C++/etc. source code and we recompile it from source).
   For files that we actually use, this is the ideal case, and should
   happen if it's practical to do so (it isn't always).

2. Source code is provided, but we don't rebuild the derived file from
   it (for example, we have configure.ac, but we use the pre-generated
   configure script instead of running autoreconf to regenerate configure;
   or we have source code, but we use a prebuilt binary instead of
   rebuilding it). This is normally considered to be a bug, whose
   severity depends on the circumstances:

   - For prebuilt binary executables, this is usually RC, because we
 usually can't know whether the source actually corresponds to the
 binary, we can't meaningfully audit the binary, we can't fix its
 bugs if it has them, and if we can't audit the binary then we
 shouldn't trust it to be non-malicious.

   - For sort-of-human-readable and sort-of-bug-fixable derived files
 like configure, I think there's consensus that this is a bug, but
 usually not a release-critical one; and sometimes regenerating the
 generated file isn't not practical, so we tolerate that bug because
 the alternative (not shipping the software) would be worse.

3. We don't have the source code from which it was generated. I think
   there's consensus that this isn't DFSG-compliant, because DFSG §2
   says we will ship source code (for packages in main and contrib).
   The definition of source code sometimes gets very subjective, but
   Debian usually borrows the "preferred form for modification" concept
   from the GPL as a working definition of source code, and
   Autoconf-generated configure scripts are rarely that
   (more on that later).

Talking about whether or not dh-autoreconf is run is to do with the
difference between what I've called (1.) and (2.) above. I think
the objection that others are raising in this thread is more about
whether the source code is present *at all*, which is the difference
between (2.) and (3.).

>  a) that do not recreate their build system at build time

That's usually my (2.) above, and I think there is consensus
that this is normally a *non-release-critical* bug. We don't solve all
non-release-critical bugs, and software with non-release-critical bugs
can stay in Debian.

Running dh-autoreconf is best-practice (I wouldn't want to claim that
I can audit a generated configure script for malicious code, but if I
replace it with a re-generated version then I don't have to, so this
appeals to my sense of both responsibility and laziness). However, I
recognise that it isn't always feasible. I don't think any of the
participants in this thread are claiming that not running dh-autoreconf
is a RC bug. IMO it could be anywhere from wishlist to important,
depending on how much pain it's causing for continued maintenance.

>  b) all packages that contain a prebuilt object without corresponding
> source, even when they are not used to build the package, or used at
> runtime (like .dll and .exe files)

That's my (3.) above, and I think there is consensus that it is a
release-critical bug. We remove these objects when we find them.

(If I am wrong about that, then I can stop repacking the Quake series of
game engines to exclude prebuilt Windows DLLs... but I would not want
to do that without approval from the ftp team, and the ftp team seem
highly unlikely to give that approval.)

For a configure script, I agree that the situation is less clear-cut
than for a prebuilt binary object. A derived file can sometimes be *a*
preferred form for modification (for instance if a reasonable person could
be expected to generate a skeleton source file from a template once, but
subsequently edit the generated file and never regenerate it). However,
for Autoconf configure scripts, this would be an exceptional case:
Autoconf configure scripts are rarely modified directly, and much more
commonly re-generated from configure.ac or configure.in.

If there is evidence of the copyright holder treating the generated
configure script as the form to be modified (hand-editing it) 

Bug#879123: glee: source for configure is missing

[Markus Koschany]

Am 20.10.2017 um 06:42 schrieb Helmut Grohne:
> On Thu, Oct 19, 2017 at 10:52:41PM +0200, Markus Koschany wrote:
>> I am quoting:
>>
>> https://sources.debian.net/src/glee/5.4.0-2/configure/
>>
>> The license is very liberal. You can argue that it should be mentioned
>> in debian/copyright but that does not make the file non-free or
>> unsuitable for Debian main.
> 
> The license is a lie. It is clear that there is some source file that
> was used to generate configure. Thus configure is a derivative work of
> that file. As Adrian pointed out, very likely the FSF isn't the
> copyright holder for that source file and very likely this permissive
> "you can do anything" license does not apply to the source file.

How do you determine that this license is a "lie" without contacting the
copyright holder or upstream? Even without this information we can
faithfully assume that the FSF as the copyright holder of GNU Autoconf
are aware of any potential licensing issues with their software. They
have even created the "Autoconf Configure Script Exception". [1] Simply
put the upstream developer of glee is allowed to integrate this
configure script in any way he sees fit.

This is not a license issue.

> Saying that a generated configure script is free software is kinda
> stupid. The essence of free software is to provide users with the
> ability to modify it and this freedom is lost when all they have is the
> generated file.

It is stupid to say that you are unable to make modifications to the
package when you were the one who discovered that you don't even need
this file to build the package. How does the mere existence of a text
file impair your freedom in this case?

> 
>> This is not true. The configure file is human readable and the preferred
>> source of modification in this case. Please also note that the author of
>> glee licensed his work under the more liberal BSD-2-clause license. You
>> cannot compare two very distinct issues like minified JS files and
>> automake files and claim consensus has been reached already.
> 
> I have worked with *lots* of configure scripts and I can say that I
> never preferred modifying the generated script. Since configure scripts
> don't have reasonable indentation, the program structure is completely
> lost. Looking at them feels a lot like reading a binary disassembly. I
> contend that "human readable" is not a reasonable assessment either.
> 
>> Again quoted out of context and not relevant in this case. The source is
>> the configure script. Period. Please feel free to discuss this on
>> debian-devel or move it to the CTTE. I am willing to oppose this
>> nonsense and harmful misinterpretation of Debian's Policy whenever and
>> wherever I can.
> 
> If you insist on disucssing this in a larger scope, chances are a ftp
> master will notice and remove glee from stable (given Ximin's findings)
> as it is not clear whether glee is distributable at all.
> 
> Do you realize that my original motivation in reporting this bug was
> that I found a build issue with glee and wanted to write a patch? The
> absence of source makes that difficult and makes DFSG#3 rather
> theoretical. Why does DFGS#3 assure a "right to modify" when
> modification is often impratical? I start to wonder whether we should
> start a GR to clarify DFSG#3 that modification should be practical.
> 
> Helmut

I don't understand your technical problems at the moment. But I
understand that you have filed a serious bug against glee with the
justification that the configure script is not source. I have worked
with even more configure scripts and I also prefer modifying something
else. That does not mean it is not possible. I had to patch countless
configure files directly because dh-autoreconf or other means did not
work for me. Does that mean those packages have release critical bugs
now? I am not only disagreeing with you, I can prove you wrong. When I
can modify a configure file, you should be able to do it too.

Looking forward: I appreciate if you work on glee. If you remove the
file in this process and create your own build system, so be it. However
I cannot accept the severity and justification of this bug without
seeing the bigger picture because glee is not the only package which
contains such a file. There are packages which cannot recreate this file
out-of-the-box right now. If this is an RC bug, then all other affected
packages which are not auto-reconfigured at build time are RC too. That
would definitely need a clarification on debian-devel. I dispute your
assessment that shipping this file is a violation of DFSG 3 because

 a) the license grants you all the required freedoms. It is free
software.
 b) the file is sufficiently modifiable but not needed at all for
building the package

In consequence this is a minor issue at best. If you insist on severity
serious for such a problem, then bug reports with the same severity
should be filed against packages

 a) that do not recreate their build 

Bug#879123: glee: source for configure is missing

[Helmut Grohne]

On Thu, Oct 19, 2017 at 10:52:41PM +0200, Markus Koschany wrote:
> I am quoting:
> 
> https://sources.debian.net/src/glee/5.4.0-2/configure/
> 
> The license is very liberal. You can argue that it should be mentioned
> in debian/copyright but that does not make the file non-free or
> unsuitable for Debian main.

The license is a lie. It is clear that there is some source file that
was used to generate configure. Thus configure is a derivative work of
that file. As Adrian pointed out, very likely the FSF isn't the
copyright holder for that source file and very likely this permissive
"you can do anything" license does not apply to the source file.

Saying that a generated configure script is free software is kinda
stupid. The essence of free software is to provide users with the
ability to modify it and this freedom is lost when all they have is the
generated file.

> This is not true. The configure file is human readable and the preferred
> source of modification in this case. Please also note that the author of
> glee licensed his work under the more liberal BSD-2-clause license. You
> cannot compare two very distinct issues like minified JS files and
> automake files and claim consensus has been reached already.

I have worked with *lots* of configure scripts and I can say that I
never preferred modifying the generated script. Since configure scripts
don't have reasonable indentation, the program structure is completely
lost. Looking at them feels a lot like reading a binary disassembly. I
contend that "human readable" is not a reasonable assessment either.

> Again quoted out of context and not relevant in this case. The source is
> the configure script. Period. Please feel free to discuss this on
> debian-devel or move it to the CTTE. I am willing to oppose this
> nonsense and harmful misinterpretation of Debian's Policy whenever and
> wherever I can.

If you insist on disucssing this in a larger scope, chances are a ftp
master will notice and remove glee from stable (given Ximin's findings)
as it is not clear whether glee is distributable at all.

Do you realize that my original motivation in reporting this bug was
that I found a build issue with glee and wanted to write a patch? The
absence of source makes that difficult and makes DFSG#3 rather
theoretical. Why does DFGS#3 assure a "right to modify" when
modification is often impratical? I start to wonder whether we should
start a GR to clarify DFSG#3 that modification should be practical.

Helmut

Bug#879123: glee: source for configure is missing

[Paul Wise]

On Fri, Oct 20, 2017 at 4:52 AM, Markus Koschany wrote:

> This is not true. The configure file is human readable and the preferred
> source of modification in this case. Please also note that the author of
> glee licensed his work under the more liberal BSD-2-clause license. You
> cannot compare two very distinct issues like minified JS files and
> automake files and claim consensus has been reached already.
...
> Again quoted out of context and not relevant in this case. The source is
> the configure script. Period. Please feel free to discuss this on
> debian-devel or move it to the CTTE. I am willing to oppose this
> nonsense and harmful misinterpretation of Debian's Policy whenever and
> wherever I can.

The configure file is almost always generated from another file and
never modified, so it can never be the preferred form for
modification. This is obviously the case here. I don't understand your
reasoning, could you explain it?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#879123: glee: source for configure is missing

[Ximin Luo]

Ximin Luo:
> On Thu, 19 Oct 2017 22:52:41 +0200 Markus Koschany  wrote:
>> [..]  The configure file is human readable and the preferred
>> source of modification in this case. Please also note that the author of
>> glee licensed his work under the more liberal BSD-2-clause license. You
>> cannot compare two very distinct issues like minified JS files and
>> automake files and claim consensus has been reached already.
>>
> 
> With respect, can you point to any concrete evidence of this configure file 
> being "the preferred source of modification"? It is definitely *not* the case 
> for *most* configure files of this type, so you need to supply some evidence 
> if you're going to argue yours is special.
> 

Unfortunately we have a bigger problem:

-   rwxrwxr-x   1,105,245   GLee.c
-   rwxrwxr-x   955,258 GLee.h

* [This file was automatically generated by GLeeGen 7.0

These files are clearly not source code. But luckily it should be possible to 
regenerate them from the git repo I mentioned:

> [..] https://github.com/kallisti5/glee
> 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#879123: glee: source for configure is missing

[Ximin Luo]

On Thu, 19 Oct 2017 22:52:41 +0200 Markus Koschany  wrote:
> [..]  The configure file is human readable and the preferred
> source of modification in this case. Please also note that the author of
> glee licensed his work under the more liberal BSD-2-clause license. You
> cannot compare two very distinct issues like minified JS files and
> automake files and claim consensus has been reached already.
> 

With respect, can you point to any concrete evidence of this configure file 
being "the preferred source of modification"? It is definitely *not* the case 
for *most* configure files of this type, so you need to supply some evidence if 
you're going to argue yours is special.

Actually, screw it, no need to bother, upstream moved to CMake: 
https://github.com/kallisti5/glee

If you look through the log you'll notice upstream added the configure file in 
the very first commit, as GLeeScripts/linux/linuxfiles/configure

Then the next edit to it was commit 65df404ebdb253e0aa7429405196df4104dda9b6 
which deleted the file as being "unused".

So it looks like we'll never get the source code to the file (unless the author 
is still contactable and has it saved privately somewhere.) Anyway just update 
to the latest version (from 2011, lol) and use CMake.

To re-iterate my first point though, if in the future this issue crops up 
again, you need to supply evidence that ./configure is "preferred source of 
modification" because that contradicts all other experience of autotools files. 
A git history log of the author hand-editing the file *more times* than 
regenerating the file from configure.ac would suffice.

Also licenses are not relevant to *whether a file is actually source code or 
not*.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#879123: glee: source for configure is missing

[Markus Koschany]

Am 19.10.2017 um 22:34 schrieb Adrian Bunk:
> On Thu, Oct 19, 2017 at 08:23:24PM +0200, Markus Koschany wrote:
>> ...
>> In my opinion the configure script of glee is DFSG-compliant and
>> suitable for main. The license states:
>>
>> # Copyright (C) 2003 Free Software Foundation, Inc.
>> # This configure script is free software; the Free Software Foundation
>> # gives unlimited permission to copy, distribute and modify it.
> 
> According to debian/copyright the FSF is not a copyright holder of glee, 
> and the licence is likely not what you quote.
> 
> Whoever wrote the configure.{ac,in} would actually be relevant here.

I am quoting:

https://sources.debian.net/src/glee/5.4.0-2/configure/

The license is very liberal. You can argue that it should be mentioned
in debian/copyright but that does not make the file non-free or
unsuitable for Debian main.

> 
>> It is correct that configure scripts are usually auto-generated but we
>> have never treated the absence of those files as RC issues. In
>> consequence this means that all automake packages which cannot use
>> dh-autoreconf are unsuitable for main.
> 
> You are mixing two related but separate issues.
> 
> Problems when using dh-autoreconf are a grey area, but these are being 
> sorted out with autoreconf usually being used now (in earlier times 
> autoreconf was nearly never done in Debian).
> 
> No configure.{ac,in} at all is a pretty clear situation,
> and also very rare.

Nope, you are mixing two unrelated issues. dh-autoreconf is the default
with compat level 10 now. That does not mean at all, it would render
packages without dh-autoreconf or with earlier compat levels non
DFSG-compliant.

> 
>> Thus I believe the resolution of
>> this bug report would be of general importance to the Debian project and
>> should be discussed on debian-devel at least.
> 
> The topic has already been discussed there countless times,
> most recently for things like minified JavaScript.

This is not true. The configure file is human readable and the preferred
source of modification in this case. Please also note that the author of
glee licensed his work under the more liberal BSD-2-clause license. You
cannot compare two very distinct issues like minified JS files and
automake files and claim consensus has been reached already.

> 
>> However I am in favor of closing this bug report as "not-a-bug".
> 
> In NEW this bug alone would be sufficient for a direct reject[1]:
> 
> Source missing
> Your package contains files that need source but do not have it. These 
> include PDF and PS files in the documentation, or auto-generated files.
> 
> Source package missing source
> Source packages are part of the distribution. As such source must be 
> present for all files in the source package itself, ...

Again quoted out of context and not relevant in this case. The source is
the configure script. Period. Please feel free to discuss this on
debian-devel or move it to the CTTE. I am willing to oppose this
nonsense and harmful misinterpretation of Debian's Policy whenever and
wherever I can.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#879123: glee: source for configure is missing

[Adrian Bunk]

On Thu, Oct 19, 2017 at 08:23:24PM +0200, Markus Koschany wrote:
>...
> In my opinion the configure script of glee is DFSG-compliant and
> suitable for main. The license states:
> 
> # Copyright (C) 2003 Free Software Foundation, Inc.
> # This configure script is free software; the Free Software Foundation
> # gives unlimited permission to copy, distribute and modify it.

According to debian/copyright the FSF is not a copyright holder of glee, 
and the licence is likely not what you quote.

Whoever wrote the configure.{ac,in} would actually be relevant here.

> It is correct that configure scripts are usually auto-generated but we
> have never treated the absence of those files as RC issues. In
> consequence this means that all automake packages which cannot use
> dh-autoreconf are unsuitable for main.

You are mixing two related but separate issues.

Problems when using dh-autoreconf are a grey area, but these are being 
sorted out with autoreconf usually being used now (in earlier times 
autoreconf was nearly never done in Debian).

No configure.{ac,in} at all is a pretty clear situation,
and also very rare.

> Thus I believe the resolution of
> this bug report would be of general importance to the Debian project and
> should be discussed on debian-devel at least.

The topic has already been discussed there countless times,
most recently for things like minified JavaScript.

> However I am in favor of closing this bug report as "not-a-bug".

In NEW this bug alone would be sufficient for a direct reject[1]:

Source missing
Your package contains files that need source but do not have it. These 
include PDF and PS files in the documentation, or auto-generated files.

Source package missing source
Source packages are part of the distribution. As such source must be 
present for all files in the source package itself, ...

> Regards,
> 
> Markus

cu
Adrian

[1] https://ftp-master.debian.org/REJECT-FAQ.html

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#879123: glee: source for configure is missing

[Markus Koschany]

Am 19.10.2017 um 19:58 schrieb Helmut Grohne:
> Source: glee
> Version: 5.4.0-2
> Severity: serious
> Justification: missing source
> 
> The configure file claims that it was generated using autoconf. Yet the
> corresponding source configure.in or configure.ac is missing from the
> source package. This makes the package unsuitable for main in principle.
> 
> Fortunately, the packaging does not appear to be using configure. So
> repacking the tarball and removing configure looks like a viable option.
> 
> Helmut

Wow. Seriously? I am adding the debian-devel-games mailing list to CC in
case I have missed an important discussion and would like to ask other
team members for more input.

In my opinion the configure script of glee is DFSG-compliant and
suitable for main. The license states:

# Copyright (C) 2003 Free Software Foundation, Inc.
# This configure script is free software; the Free Software Foundation
# gives unlimited permission to copy, distribute and modify it.

It is correct that configure scripts are usually auto-generated but we
have never treated the absence of those files as RC issues. In
consequence this means that all automake packages which cannot use
dh-autoreconf are unsuitable for main. Thus I believe the resolution of
this bug report would be of general importance to the Debian project and
should be discussed on debian-devel at least.

However I am in favor of closing this bug report as "not-a-bug".

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#879123: glee: source for configure is missing

[Helmut Grohne]

Source: glee
Version: 5.4.0-2
Severity: serious
Justification: missing source

The configure file claims that it was generated using autoconf. Yet the
corresponding source configure.in or configure.ac is missing from the
source package. This makes the package unsuitable for main in principle.

Fortunately, the packaging does not appear to be using configure. So
repacking the tarball and removing configure looks like a viable option.

Helmut