[PATCH] fix build error with automake-1.14, dnl comment need start at newline

[Marc Lehmann]

On Mon, Dec 23, 2013 at 12:49:01PM +0800, "Dennis Lan (dlan)" <dennis.yxun at gmail.com> wrote:
> > debug hacked libev versions in distros if you silently modify libev, you
> > are on your own).
> 
> Since this is a build error(which I think it's trivial), so we fix it
> *first* instead of discussing with upstream

The problem is when a) your fix is broken and b) the error is never
reported upstream, as in this case (so far, the only thing reported
upstream was that your fix is indeed broken, we still don't know *why* you
think you needed that hack).

> (i personally don't think keeping bugs open and affect many users would
> be a good idea).

I agree, but never reporting the problem upstream in the first place,
as in this case, probably affects even more users - not everybody uses
gentoo.

(added after completely reading your mail: I see now, you didn't fix
anything, the bug you are talking about doesn't even exist. So why all
this fuzzy talk about bugs when the original reason for your broken fix
wasn't even a bug, but maintainer-hubris? you are just confusing the issue
- be honest and at least acknowledge that there never was a bug to fix to
begin with).

> But I'm always open to cooperate with upstream to find better
> solution,  that's why I sent this patch.

If you tell us the original problem that caused you to break the configure
script, we would have something to discuss, yes. So far, you have broken
configure and sent a patch upstream that fixes your bug - upstream was
never affected with that bug to begin with - it was introduced in gentoo
without ever discussing it upstream.

If there is another bug that requires the change to configure, then now
would be the time to mention it.

> I do *not* want to maintain patches which won't be accepted by upstream,
> and try my best to avoid this.
> 
> for why we need to re-generate configure file, because we carry libev
> pkg patch (which I sent patch before and been rejected). I'm trying to
> upstream patches first, but if fail, then we fall back to carry
> ourselves.

Since you just said you don't want that patch, and given that this patch
is bad for users and breaks things, who or what forces you to carry that
patch yourself? It should be absolutely within the possibilities of a
package maintainer to avoid forking in this case, so what are the reasons?

And after all, all your talk about bugfixes above do not even apply -
gentoo simply forked libev without stating any reasons, without discussing
this with upstream, without any need, and then sends bugfixes that only
apply to their version to upstream.

I am sorry, but thats exactly what I was talking about, and thats why
libev has a bad maintainer in gentoo - it's not the distros job to
"improve" an upstream package, especially given that distro maintainers
generally suck at this - their job is to package, not apply unneeded
patches that make gentoo incompatible to other distros on the maintainers
whim.

Can you at least see that forking libev, introducing bugs and then sending
fixes upstream is somehow wrong? We don't maintain gentoos broken fork
- if gentoo insists on forking libev, they are also responsible for at
least thoroughly checking their bugreports against the pristine version,
to avoid bogus reports.

In addition, it is a great disservice to gentoo users to package willfully
incompatible versions, because a maintainer thinks he can do the job better
than upstream. Gentoo should at least rename libev, so it is clear that it is
forked and not pristine.

Of course, the license doesn't require this, but accountability towards
users certainly does.

> yes, this is indeed introduced by automake-1.14, changes to AM_INIT_AUTOMAKE
> but, for information why dnl discard the newline, refer  this [1]

I know why dnl dicards newlines, but I don't know why that would be
relevant. The autoconf documentation is clear in this matter, and unless
it has changed, this is a bug in autoconf or automake (that doesn't affect
libev, of course, only the gentoo fork).

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\