The package doesn't build properly on kfreebsd-amd64 due to #570719
in librep-dev causing libtool errors [1] and generating empty results.

Hi,

It is the problem that happened because /bin/sh became dash as for this.
This problem will be fix by binNMU.

Best regards,
  Nobuhiro

severity 570719 serious
reassign 570723 libtool
severity 570723 wishlist
retitle 570723 libtool should set -e
affects 570723 rep-gtk
thanks

I have looked at why rep-gtk's build system did not fail when #570719
occurred; it can happen on plain amd64 as well.  The problem is that
libtool did not exit with an error code, so there is really nothing
rep-gtk could have done.

I almost just closed #570723 - but I'll reassign to libtool, because
maybe it should 'set -e' or something (unless that's not portable).

To compensate for the downgrade, I guess #570719 must now be considered
serious.  I think it should have been from the start, really.

So we need a new librep-dev upload, and maybe a binNMU for rep-gtk on
some architectures.

* Tim Retout wrote on Thu, Oct 14, 2010 at 09:36:07AM CEST:

Issues such as this:

| eval: 1: libtool_args+=: not found
| eval: 1: libtool_args+=: not found

typically come from configure running the tests under a different shell
than libtool.  This is often because the configure.ac messes with $SHELL
and/or $CONFIG_SHELL, or CONFIG_SHELL is set in the environment.

The build log referenced looks like it ran under bash:

| checking whether the shell understands some XSI constructs... yes
| checking whether the shell understands "+="... yes

yet make uses /usr/lib/rep/x86_64-pc-kfreebsd-gnu/libtool which doesn't
seem to have been created by configure.  I suspect that
/usr/lib/rep/x86_64-pc-kfreebsd-gnu/libtool assumes /bin/sh is bash,
because at the time and on the system it was created it was bash.

In all likelihood, this is not a Libtool bug.

Cheers,
Ralf

 2010 09:11, Ralf Wildenhues <Ralf.Wildenhues@gmx.de> wrote:

Yep, this specific problem is with librep-dev not setting CONFIG_SHELL
explicitly, and I'll fix that in #570719.  But the bug I wanted to
raise was that this general class of errors - running the libtool
script with the wrong shell - does not cause a bad error code.  If
'set -e' were added at the top of libtool, it would fail early. Feel
free to 'wontfix' if that's not possible to do.

tags 570723 + upstream
thanks

[ http://bugs.debian.org/570723 ]

* Tim Retout wrote on Thu, Oct 14, 2010 at 10:26:00AM CEST:
[...]

Good point.  Tagging this bug as upstream one.  Sorry for misreading
your bug report at first.

Indeed.  However, libtool is currently not 'set -e' clean, in the sense
that several code pieces expect to continue if some unchecked code fails
(either they are meant to ignore failure, or $? is checked afterwards).
Examples include func_show_eval in general.m4sh, basically all code
pieces in ltmain.m4sh that reference $?, and probably some system-
specific code snippets in libtool.m4.

I'm sure improving things on this front would help as cleanup, but there
are several portability warts that other shells have with 'set -e' code
(esp. with loop constructs) that outright enabling it doesn't seem
helpful to me except for bug hunting.

Well, it is certainly possible to guard against this specific bug, esp.
since it is still a fairly common one to happen, let's keep it open for
now.

Thanks,
Ralf