Re: Is an autogenerated configure shell script non-editable source

[Paul Wise]

On Sun, 2022-12-11 at 16:47 +0100, Andreas Tille wrote:

> Could you give some arguents for your feeling.

See the posts I made in this and earlier threads:

https://lists.debian.org/msgid-search/4363a2435e61bf351c7d3605136c3652118eae2f.ca...@debian.org
https://lists.debian.org/msgid-search/50184a59271c953a3f9a3c99bb193dc05e61f2aa.ca...@debian.org

> what does this mean for other packages where configure.ac is missing?

That should be decided on a case-by-case basis, since not every
configure is generated from a configure.ac and not every instance of
configure.ac being missing is due to it being withheld from view,
some instances could be due to it genuinely no longer existing,
although that is very unlikely. In the case where it genuinely doesn't
exist, I would still regard that as an important bug, to fix upstream.

> I think the fact whether a fix is simple or not does not matter for the
> severity of a bug.  Unfortunately the solution is not as simple as
> described (as I wrote in response to the said mail).

Agreed in general, in this case it did turn out to be simple though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source

[Simon Richter]

Hi,

On 12/11/22 16:47, Andreas Tille wrote:


May be I interpreted
posts in this thread wrongly but I read it like serious is a to high
severity.  Moreover what does this mean for other packages where
configure.ac is missing?


It depends on the licence, to some extent.

The GPL's definition of "source code" is:

The “source code” for a work means the preferred form of the work for 
making modifications to it. “Object code” means any non-source form of a 
work.


So for GPL'd software, shipping a configure script without its 
configure.ac is a case of missing source code.


   Simon

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Philip Rinn]

Hi Andreas,


Hi Andreas,

Am Sat, Dec 10, 2022 at 11:41:11AM +0100 schrieb Andreas Metzler:


I have given this a a little bit of time. This seems to work:

1. Copy configure.ac from upstream's 2.3.2h2 branch.


Seems in tag 2.3.2h2 happened what I tried with 2.3.2[1] at least
the resulting configure.ac is identical after
autoupdate && autoreconf -f -i


2. Add 'export AUTOHEADER = true' to debian/rules.


I tried this, but the build fails for me and Salsa CI[2] with

  configure.ac:479: the top level
  sh: 1: Syntax error: Unterminated quoted string
  autoreconf: error: true' failed with exit status: 2

I admit I can't find that unterminated quoted string near line 479.



that's not surprising as you indeed have an unterminated "'" in 
https://salsa.debian.org/med-team/hmmer2/-/blob/master/debian/rules#L12


Best regards
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Am Sun, Dec 11, 2022 at 10:43:37AM -0500 schrieb Boyuan Yang:
> 
> Not sure if it is the root cause, but there's an obvious typo with quote at
> L12:
> https://salsa.debian.org/med-team/hmmer2/-/blob/423388accbb8c622edb663c845f1f5a6336256e1/debian/rules#L12
> .

Ahhh, thanks - I was seeking for the quoting issue inside configure.ac!

Thanks a lot
   Andreas.

-- 
http://fam-tille.de

Re: Is an autogenerated configure shell script non-editable source

[Andreas Tille]

Hi Paul,

Am Sun, Dec 11, 2022 at 12:21:18PM +0800 schrieb Paul Wise:
> > So far for the actual case (bug report in CC).
> > 
> > For the general case I somehow understand the consensus here on the list
> > that a missing configure.ac can be considered a bug but the severity
> > serious is not really rectified.  If I understood this correctly I would
> > reset the severity to important at the beginning of next week.
> 
> Personally I feel that severity serious is the correct one,

Could you give some arguents for your feeling.  May be I interpreted
posts in this thread wrongly but I read it like serious is a to high
severity.  Moreover what does this mean for other packages where
configure.ac is missing?  I'm 100% sure that we have quite some packages
where this is the case.  I admit I'm not motivated to seek for these
and file a MBF but if there is some consensus about this we should act
accordingly.  On the other hand if we have no consensus it should not
be of RC critical severity.

> but it sounds like the fix for the bug is quite simple:
> 
> https://lists.debian.org/msgid-search/y5rir8qidvj4r...@argenau.bebt.de

I think the fact whether a fix is simple or not does not matter for the
severity of a bug.  Unfortunately the solution is not as simple as
described (as I wrote in response to the said mail).

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Boyuan Yang]

Hi,

在 2022-12-11星期日的 16:35 +0100，Andreas Tille写道：
> Hi Andreas,
> 
> Am Sat, Dec 10, 2022 at 11:41:11AM +0100 schrieb Andreas Metzler:
> > 
> > I have given this a a little bit of time. This seems to work:
> > 
> > 1. Copy configure.ac from upstream's 2.3.2h2 branch.
> 
> Seems in tag 2.3.2h2 happened what I tried with 2.3.2[1] at least
> the resulting configure.ac is identical after
>     autoupdate && autoreconf -f -i
> 
> > 2. Add 'export AUTOHEADER = true' to debian/rules.
> 
> I tried this, but the build fails for me and Salsa CI[2] with
> 
>   configure.ac:479: the top level
>   sh: 1: Syntax error: Unterminated quoted string
>   autoreconf: error: true' failed with exit status: 2
> 
> I admit I can't find that unterminated quoted string near line 479.

Not sure if it is the root cause, but there's an obvious typo with quote at
L12:
https://salsa.debian.org/med-team/hmmer2/-/blob/423388accbb8c622edb663c845f1f5a6336256e1/debian/rules#L12
.



> Thanks for the attempt to help anyway
> 
>     Andreas.
> 
> [1]
> https://salsa.debian.org/med-team/hmmer2/-/blob/master/debian/rules#L25-L26 
> [2] https://salsa.debian.org/med-team/hmmer2/-/jobs/3642966#L917

Thanks,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Hi Andreas,

Am Sat, Dec 10, 2022 at 11:41:11AM +0100 schrieb Andreas Metzler:
> 
> I have given this a a little bit of time. This seems to work:
> 
> 1. Copy configure.ac from upstream's 2.3.2h2 branch.

Seems in tag 2.3.2h2 happened what I tried with 2.3.2[1] at least
the resulting configure.ac is identical after
autoupdate && autoreconf -f -i

> 2. Add 'export AUTOHEADER = true' to debian/rules.

I tried this, but the build fails for me and Salsa CI[2] with

  configure.ac:479: the top level
  sh: 1: Syntax error: Unterminated quoted string
  autoreconf: error: true' failed with exit status: 2

I admit I can't find that unterminated quoted string near line 479.

Thanks for the attempt to help anyway

Andreas.

[1] https://salsa.debian.org/med-team/hmmer2/-/blob/master/debian/rules#L25-L26 
[2] https://salsa.debian.org/med-team/hmmer2/-/jobs/3642966#L917

-- 
http://fam-tille.de

Bug#1025739: Info received (Is an autogenerated configure shell script non-editable source)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Med Packaging Team 

If you wish to submit further information on this problem, please
send it to 1025...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
1025739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025739
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Is an autogenerated configure shell script non-editable source

[Paul Wise]

On Sat, 2022-12-10 at 10:28 +0100, Andreas Tille wrote:

> So far for the actual case (bug report in CC).
> 
> For the general case I somehow understand the consensus here on the list
> that a missing configure.ac can be considered a bug but the severity
> serious is not really rectified.  If I understood this correctly I would
> reset the severity to important at the beginning of next week.

Personally I feel that severity serious is the correct one,
but it sounds like the fix for the bug is quite simple:

https://lists.debian.org/msgid-search/y5rir8qidvj4r...@argenau.bebt.de


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source

[Russ Allbery]

Andreas Tille  writes:

> For the general case I somehow understand the consensus here on the list
> that a missing configure.ac can be considered a bug but the severity
> serious is not really rectified.  If I understood this correctly I would
> reset the severity to important at the beginning of next week.

I think that seems fine baesd on my reading of the thread, although since
we have now found the configure.ac, I would also stuff that in the Debian
package somewhere so that all the pieces are available to someone who has
the Debian source package.

-- 
Russ Allbery (r...@debian.org)  

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Metzler]

On 2022-12-09 Andreas Tille  wrote:
[...]
> Thanks to Alexander Sulfrian who pointed out the Git repository
> featuring old tags that were obviously taken over from SVN I was proven
> wrong with the statement that there is no configure.ac any more.

> Unfortunately this is no simple drop-in with modern autoconf tools
> and my weak attempt in Git to use this failed.[1]
[...]

Hello,

I have given this a a little bit of time. This seems to work:

1. Copy configure.ac from upstream's 2.3.2h2 branch.
2. Add 'export AUTOHEADER = true' to debian/rules.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Is an autogenerated configure shell script non-editable source

[Andreas Tille]

Am Fri, Dec 09, 2022 at 11:58:56AM -0800 schrieb Russ Allbery:
> The real problem in this case is less about the DFSG and more about the
> practical problems of maintaining Debian as a software distribution: if we
> can't regenerate configure using software in Debian, there are a lot of
> porting tasks and some bug-fixing tasks that we can't do, and that's a
> problem for us.  But I'm dubious that it's a *software freedom* problem;
> it's more of a *software maintenance* problem, and thus the bug severity
> should be based on how much of a problem that is in practice.

The situation of hmmer2 is that upstream went to hmmer3 which is despite
its same name something different.  The Debian Med team keeps on
maintaining that old code since scientists need this to have comparable
results with former research.  I guess its simple enough to even craft a
new configure.ac (or backport the one for hmmer3) if needed and the fact
that Helmit stumbled upon it to enhance pkg-config compatibility is a
good reason for a bug report with severity somewhere between wishlist
and important.  We try to fix any bug (no matter what severity) and in
the current Debian Med Advent bug squashing party we try to approach
this.

However, since we can not guarantee that the bug is solved quickly a
serious bug might have the consequence that the package might not be
shipped with bookworm which is definitely not in the interest of our
users.

So far for the actual case (bug report in CC).

For the general case I somehow understand the consensus here on the list
that a missing configure.ac can be considered a bug but the severity
serious is not really rectified.  If I understood this correctly I would
reset the severity to important at the beginning of next week.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Paul Wise]

On Fri, 2022-12-09 at 13:14 +0100, Andreas Tille wrote:

> Is an autogenerated configure shell script non-editable source

[Short-winded way of saying something similar to Russ]

In general I don't think such a situation meets DFSG item 2 nor the
GPL "preferred form for modification", for the reasons outlined here:

https://lists.debian.org/msgid-search/50184a59271c953a3f9a3c99bb193dc05e61f2aa.ca...@debian.org

In this case, it does seem like a DFSG violation that the source file
(configure.ac) is not available in Debian but is available upstream.

Once the configure.ac is included, the current lack of ability to
rebuild configure from it would probably cause an FTBFS bug too,
since by default debhelper will automatically run autoreconf.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is an autogenerated configure shell script non-editable source

[Bart Martens]

On Fri, Dec 09, 2022 at 11:58:56AM -0800, Russ Allbery wrote:
> Bart Martens  writes:
> 
> > That file may be available online for this particular software. The
> > debate is about whether such configure.ac file must be included in the
> > distributed package for making the package dfsg. And more in general,
> > about where to draw the line on how easily editable (think: time well
> > spent) the included source code must be for making the package dfsg. In
> > my opinion there is no sharp line, and ftpmaster is well positioned for
> > making fair choices in a +/- uniform way for all packages. And there is
> > always be room for questioning those choices and allowing the meaning of
> > dfsg evolve over time. Back to configure.ac, I'd support a choice of
> > making a missing configure.ac an 'important' bug, and not enough for
> > rejecting the package as non-dfsg.
> 
> The general rule of thumb that I've followed in similar situations in the
> past (PDF files where the original source has been completely lost, for
> example) is that the underlying purpose of the DFSG source provision and
> of free software in general is to ensure that the recipient of the
> software is not at a disadvantage.  In other words, the distributor isn't
> allowed to hold back pieces that make it harder for the recipient to
> modify the software (within the general definition of "source," of
> course).
> 
> Therefore, it matters what the distributor has.  If they have the true
> source used to generate the file but are keeping it secret, then to me
> that's a violation of the DFSG and we shouldn't participate (even if their
> actions aren't technically a violation of the license since if they own
> the copyright they don't need a license).  This is creating that
> disadvantage for the recipient that free software is designed to prevent.
> But if the original source has been lost, then everyone is on an equal
> footing, and I don't think there's a DFSG violation.  We may not have the
> true source in the intended sense, but *no one* has the source, and
> therefore everyone is on an equal footing and has equal ability to modify
> the software.

Interesting angle. It illustrates indeed what Free Software is meant for.
Still, dfsgness should be evaluated on what's in the package, not on someone
holding back some (easier modifiable) source code or their motive for that.

> 
> There is a different wrinkle in this specific case: we may have the source
> but not the software that was used to generate the file from the source.
> In this case, it sounds like an old version of Autoconf was used, and we
> don't package that version of Autoconf any more, so while the source is
> present in one sense, one can't regenerate the file.  I'm not sure the
> DFSG is the most useful framework for analyzing that situation, since to
> me it feels more practical than freedom-based.  Everyone is still in
> basically the same situation: the source is available to everyone, but
> some work may be required to go hunt up the old tool and regenerate the
> file.  (This assumes a case like Autoconf where the old releases of the
> tool are readily available and not kept secret, but may be hard to get
> working.)

Well, if Debian says that the lack of the old Autoconf makes a software
non-dfsg, then Debian can still choose to keep that software dfsg by still
shipping that old Autoconf along with that software. My point is that it
matters what is provided together, not what is in one technical package.

> 
> The real problem in this case is less about the DFSG and more about the
> practical problems of maintaining Debian as a software distribution: if we
> can't regenerate configure using software in Debian, there are a lot of
> porting tasks and some bug-fixing tasks that we can't do, and that's a
> problem for us.  But I'm dubious that it's a *software freedom* problem;
> it's more of a *software maintenance* problem, and thus the bug severity
> should be based on how much of a problem that is in practice.

I think that the easiness/difficulty of modifying some form of source code is
about dfsgness on the one end and about maintainability on the other, without a
sharp line between them. Just to name two extremes: One could argue that any
binary is editable after using a disassembler. Someone else might argue that
nowadays C source code should be regeneratable from some newer language.

> 
> (I think this is mostly a long-winded way of saying the same thing Marco
> said.)
> 
> -- 
> Russ Allbery (r...@debian.org)  
> 

Re: Is an autogenerated configure shell script non-editable source

[The Wanderer]

On 2022-12-09 at 14:58, Russ Allbery wrote:

> Bart Martens  writes:
> 
>> That file may be available online for this particular software.
>> The debate is about whether such configure.ac file must be included
>> in the distributed package for making the package dfsg. And more in
>> general, about where to draw the line on how easily editable
>> (think: time well spent) the included source code must be for
>> making the package dfsg. In my opinion there is no sharp line, and
>> ftpmaster is well positioned for making fair choices in a +/-
>> uniform way for all packages. And there is always be room for
>> questioning those choices and allowing the meaning of dfsg evolve
>> over time. Back to configure.ac, I'd support a choice of making a
>> missing configure.ac an 'important' bug, and not enough for 
>> rejecting the package as non-dfsg.
> 
> The general rule of thumb that I've followed in similar situations in
> the past (PDF files where the original source has been completely
> lost, for example) is that the underlying purpose of the DFSG source
> provision and of free software in general is to ensure that the
> recipient of the software is not at a disadvantage.  In other words,
> the distributor isn't allowed to hold back pieces that make it harder
> for the recipient to modify the software (within the general
> definition of "source," of course).
> 
> Therefore, it matters what the distributor has.  If they have the
> true source used to generate the file but are keeping it secret, then
> to me that's a violation of the DFSG and we shouldn't participate
> (even if their actions aren't technically a violation of the license
> since if they own the copyright they don't need a license).  This is
> creating that disadvantage for the recipient that free software is
> designed to prevent. But if the original source has been lost, then
> everyone is on an equal footing, and I don't think there's a DFSG
> violation.  We may not have the true source in the intended sense,
> but *no one* has the source, and therefore everyone is on an equal
> footing and has equal ability to modify the software.
> 
> There is a different wrinkle in this specific case: we may have the
> source but not the software that was used to generate the file from
> the source. In this case, it sounds like an old version of Autoconf
> was used, and we don't package that version of Autoconf any more, so
> while the source is present in one sense, one can't regenerate the
> file.  I'm not sure the DFSG is the most useful framework for
> analyzing that situation, since to me it feels more practical than
> freedom-based.  Everyone is still in basically the same situation:
> the source is available to everyone, but some work may be required to
> go hunt up the old tool and regenerate the file.  (This assumes a
> case like Autoconf where the old releases of the tool are readily
> available and not kept secret, but may be hard to get working.)
> 
> The real problem in this case is less about the DFSG and more about
> the practical problems of maintaining Debian as a software
> distribution: if we can't regenerate configure using software in
> Debian, there are a lot of porting tasks and some bug-fixing tasks
> that we can't do, and that's a problem for us.  But I'm dubious that
> it's a *software freedom* problem; it's more of a *software
> maintenance* problem, and thus the bug severity should be based on
> how much of a problem that is in practice.
> 
> (I think this is mostly a long-winded way of saying the same thing
> Marco said.)

(Sorry for not snipping; I couldn't find any part that seemed more worth
omitting than any other.)

I tend to agree, on your parenthetical last statement. I was not
persuaded by Marco's own post, but your more long-winded version has
convinced me, I think.

I would just like to also note two potentially-relevant questions, in
making the analysis - both to do with the possibility of making changes
to the file, and both of which are likely to have the same answer:

* If upstream were going to change the configure process, what file
would they edit?

* If you wanted to make changes to the configure process and submit them
to upstream for possible inclusion, which file would upstream want the
patch with the changes to be against?

By the "preferred form for modification" definition, whichever file that
is is likely to be the one that is considered the source.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Is an autogenerated configure shell script non-editable source

[Russ Allbery]

Bart Martens  writes:

> That file may be available online for this particular software. The
> debate is about whether such configure.ac file must be included in the
> distributed package for making the package dfsg. And more in general,
> about where to draw the line on how easily editable (think: time well
> spent) the included source code must be for making the package dfsg. In
> my opinion there is no sharp line, and ftpmaster is well positioned for
> making fair choices in a +/- uniform way for all packages. And there is
> always be room for questioning those choices and allowing the meaning of
> dfsg evolve over time. Back to configure.ac, I'd support a choice of
> making a missing configure.ac an 'important' bug, and not enough for
> rejecting the package as non-dfsg.

The general rule of thumb that I've followed in similar situations in the
past (PDF files where the original source has been completely lost, for
example) is that the underlying purpose of the DFSG source provision and
of free software in general is to ensure that the recipient of the
software is not at a disadvantage.  In other words, the distributor isn't
allowed to hold back pieces that make it harder for the recipient to
modify the software (within the general definition of "source," of
course).

Therefore, it matters what the distributor has.  If they have the true
source used to generate the file but are keeping it secret, then to me
that's a violation of the DFSG and we shouldn't participate (even if their
actions aren't technically a violation of the license since if they own
the copyright they don't need a license).  This is creating that
disadvantage for the recipient that free software is designed to prevent.
But if the original source has been lost, then everyone is on an equal
footing, and I don't think there's a DFSG violation.  We may not have the
true source in the intended sense, but *no one* has the source, and
therefore everyone is on an equal footing and has equal ability to modify
the software.

There is a different wrinkle in this specific case: we may have the source
but not the software that was used to generate the file from the source.
In this case, it sounds like an old version of Autoconf was used, and we
don't package that version of Autoconf any more, so while the source is
present in one sense, one can't regenerate the file.  I'm not sure the
DFSG is the most useful framework for analyzing that situation, since to
me it feels more practical than freedom-based.  Everyone is still in
basically the same situation: the source is available to everyone, but
some work may be required to go hunt up the old tool and regenerate the
file.  (This assumes a case like Autoconf where the old releases of the
tool are readily available and not kept secret, but may be hard to get
working.)

The real problem in this case is less about the DFSG and more about the
practical problems of maintaining Debian as a software distribution: if we
can't regenerate configure using software in Debian, there are a lot of
porting tasks and some bug-fixing tasks that we can't do, and that's a
problem for us.  But I'm dubious that it's a *software freedom* problem;
it's more of a *software maintenance* problem, and thus the bug severity
should be based on how much of a problem that is in practice.

(I think this is mostly a long-winded way of saying the same thing Marco
said.)

-- 
Russ Allbery (r...@debian.org)  

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Bart Martens]

On Fri, Dec 09, 2022 at 04:07:30PM +0100, Alexander Sulfrian wrote:
> Hi,
> 
> On Fri, Dec 09, 2022 at 01:14:40PM +0100, Andreas Tille wrote:
> > I would consider asking upstream about this for sure but the code is in
> > maintenance mode and there is no Git repository to step back in history.
> > The only way to go would be to take configure.ac from a later version
> > and find out how it can be tweaked to create some working configure
> > file from it.  I do not consider my time well spent in doing so except
> > if there is some consensus here on the list that configure files without
> > configure.ac are "missing source".
> 
> isn't the matching configure.ac available here?
> 
> https://github.com/MichiganTech/hmmer/blob/2.3.2/configure.ac
> 
> This repository is at least referenced in debian/upstream/metadata and
> the package version seems to match the git tag.

That file may be available online for this particular software. The debate is
about whether such configure.ac file must be included in the distributed
package for making the package dfsg. And more in general, about where to draw
the line on how easily editable (think: time well spent) the included source
code must be for making the package dfsg. In my opinion there is no sharp line,
and ftpmaster is well positioned for making fair choices in a +/- uniform way
for all packages. And there is always be room for questioning those choices and
allowing the meaning of dfsg evolve over time. Back to configure.ac, I'd
support a choice of making a missing configure.ac an 'important' bug, and not
enough for rejecting the package as non-dfsg.

> 
> 
> Alex
> 

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Hi Marco

Am Fri, Dec 09, 2022 at 03:33:38PM +0100 schrieb Marco d'Itri:
> On Dec 09, Andreas Tille  wrote:
> 
> > I would consider asking upstream about this for sure but the code is in
> > maintenance mode and there is no Git repository to step back in history.
> > The only way to go would be to take configure.ac from a later version
> > and find out how it can be tweaked to create some working configure
> > file from it.  I do not consider my time well spent in doing so except
> > if there is some consensus here on the list that configure files without
> > configure.ac are "missing source".
> If there is no surviving configure.ac which can generate the current 
> configure file then it is quite obvious that this is not a DFSG issue, 
> because no such source exists.

Thanks to Alexander Sulfrian who pointed out the Git repository
featuring old tags that were obviously taken over from SVN I was proven
wrong with the statement that there is no configure.ac any more.

Unfortunately this is no simple drop-in with modern autoconf tools
and my weak attempt in Git to use this failed.[1]

> But if your package contains a manually edited configure file then this
> is a bad practice, and experience shows that sooner or later you will 
> have to deal with the resulting bugs.

I have no reasons to assume that the provided configure was manually
edited.  Its definitely created by old Autoconf (2.57) and can't be
recreated with recent autoconf tools.  But the build works fine with the
configure that is provided.

> Clearly, the severity of these bugs is different, at least as long as 
> your package builds.

This is actually my main point.  Helmut and I have obviously different
opinions about the relevance of the problem regarding DFSG and the
resulting implication for the severity of the bug.  Helmut have stated
good reasons why a recent configure.ac is helpful / important for him
(injecting PKG_CHECK_MODULES) and I would agree with severity important
(to get progress ongoing).  However, waving with the big club DFSG is
IMHO a bit too much in the case of a shell script (no matter how badly
it is written for the intended purpose).

I moved the discussion to debian-devel not primarily for this specific
case (which I intend to fix no matter what severity this bug might
have).  My main point is that we should find some consensus about the
severity of this bug to be clear in other cases we definitely have in
our archive.

Kind regards
   Andreas.

[1] 
https://salsa.debian.org/med-team/hmmer2/-/commit/d1f5b3d08391efd66b69090e544803d6bd0f6638

-- 
http://fam-tille.de

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Alexander Sulfrian]

Hi,

On Fri, Dec 09, 2022 at 01:14:40PM +0100, Andreas Tille wrote:
> I would consider asking upstream about this for sure but the code is in
> maintenance mode and there is no Git repository to step back in history.
> The only way to go would be to take configure.ac from a later version
> and find out how it can be tweaked to create some working configure
> file from it.  I do not consider my time well spent in doing so except
> if there is some consensus here on the list that configure files without
> configure.ac are "missing source".

isn't the matching configure.ac available here?

https://github.com/MichiganTech/hmmer/blob/2.3.2/configure.ac

This repository is at least referenced in debian/upstream/metadata and
the package version seems to match the git tag.


Alex

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Marco d'Itri]

On Dec 09, Andreas Tille  wrote:

> I would consider asking upstream about this for sure but the code is in
> maintenance mode and there is no Git repository to step back in history.
> The only way to go would be to take configure.ac from a later version
> and find out how it can be tweaked to create some working configure
> file from it.  I do not consider my time well spent in doing so except
> if there is some consensus here on the list that configure files without
> configure.ac are "missing source".
If there is no surviving configure.ac which can generate the current 
configure file then it is quite obvious that this is not a DFSG issue, 
because no such source exists.

But if your package contains a manually edited configure file then this
is a bad practice, and experience shows that sooner or later you will 
have to deal with the resulting bugs.

Clearly, the severity of these bugs is different, at least as long as 
your package builds.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Helmut Grohne]

Hi Andreas,

On Fri, Dec 09, 2022 at 01:14:40PM +0100, Andreas Tille wrote:
> This "prominent" example was heavily discussed and IMHO its not really
> an example for the current case.  If you look at the configure file of
> hmmer2[1] it surely claims that it is autogenerated.  However, its
> perfectly simple and straightforward shell text with sensibly named
> variables so it is editable code.  Calling this piece of shell source
> code "missing source" is IMHO an over-interpretation of the letters of
> DFSG.

Unsurprisingly, I respectfully disagree. A typical change you'd want to
do to configure is replace a bare pkg-config invocation with
PKG_CHECK_MODULES. Doing this to your configure script is quite similar
in experience to patching a binary. Another very common task is updating
macros from old version, because they contain bugfixes. Being macros,
you'd be chasing down every single interpolation.

Your comparison to compressed javascript (in your earlier reply) is also
interesting. A major aspect of minification is removal of spaces.
Looking into the generated configure script, indentation is total
garbage. Then minification tends to mangle variables. While configure
doesn't really have mangled variables, it only has global variables and
since it doesn't use functions, it establishes scope using *_save
variables. The resulting mess of variables isn't any better than that in
compressed javascript.

So yeah, maybe the comparison to binary is not exactly right, but
comparing it to disassembly certainly is. If you were to ship an
assembly file compiled from a C file without the C source, that would
quite certainly count as missing source.

And then, we also have DFSG #3, which primarily talks about the license
allowing derivative works, but if the "source" renders derivative works
infeasible, then having a license to do so is kinda useless.

Helmut

Is an autogenerated configure shell script non-editable source (Was: Bug#1025739: hmmer2: missing source for configure)

[Andreas Tille]

Hi Helmut,

IMHO this should be discussed more widely.

Am Thu, Dec 08, 2022 at 08:09:22PM +0100 schrieb Helmut Grohne:
> Control: tags -1 - moreinfo
> 
> On Thu, Dec 08, 2022 at 05:56:18PM +0100, Andreas Tille wrote:
> > I agree that this configure script looks auto generated but IMHO it can
> > be considered machine readable and editable with some effort.  I could
> > imagine that it is hard to edit for your cross-building effort.
> > However, this is the first time a FTBFS bug is filed for the lack of
> > some configure.ac file.  Am I missing something our should this be
> > discussed on debian-devel list first since this might end up in a MBF.
> 
> This is not a FTBFS bug. It's a DFSG bug.

Sorry for the typo.  I've got that you claim its DFSG.

> Packages are so frequently rejected from NEW for this reason that it
> made it to the reject FAQ:
> 
> https://ftp-master.debian.org/REJECT-FAQ.html -> "Source missing"

I've seen rejections for compressed JS scripts so far and this item is
not unknown.

> I think the most prominent example is #762638.

This "prominent" example was heavily discussed and IMHO its not really
an example for the current case.  If you look at the configure file of
hmmer2[1] it surely claims that it is autogenerated.  However, its
perfectly simple and straightforward shell text with sensibly named
variables so it is editable code.  Calling this piece of shell source
code "missing source" is IMHO an over-interpretation of the letters of
DFSG.

I would consider asking upstream about this for sure but the code is in
maintenance mode and there is no Git repository to step back in history.
The only way to go would be to take configure.ac from a later version
and find out how it can be tweaked to create some working configure
file from it.  I do not consider my time well spent in doing so except
if there is some consensus here on the list that configure files without
configure.ac are "missing source".

Kind regards
Andreas.

[1] https://salsa.debian.org/med-team/hmmer2/-/blob/master/configure

-- 
http://fam-tille.de