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 <s...@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 >
configure.ac
Description: Binary data
