Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-05 Thread Ben Pfaff
Loïc Minier <[EMAIL PROTECTED]> writes:

>  All I want is that Debian's NEWS (which is presented to the end-user /
>  end-developer on upgrades) warns of important changes, and when a nice
>  document such as upstream's NEWS is already available, I consider that
>  all that is needed is a pointer to this document or a summary of the
>  most important issues.

Do I have to install anything special or tweak a setting to be
presented NEWS.Debian on upgrades?  I've never seen that happen
on my installs.
-- 
Peter Seebach on managing engineers:
"It's like herding cats, only most of the engineers are already
 sick of laser pointers."



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-05 Thread Ralf Wildenhues
Hi Loïc,

* Loïc Minier wrote on Mon, Jun 05, 2006 at 10:43:06AM CEST:
> 
>  I also had the feeling you were frustrated that I didn't see the NEWS
>  document prior to reporting this bug.  I'm sorry that you spent extra
>  effort in properly documenting this, I should have checked NEWS and
>  requested a pointer to NEWS from our NEWS.Debian in the first place.

Don't worry, you're all doing fine, I should be sorry for my
inappropriate tone.

Note to self: even if you're in a bad mood, make extra sure to not let
beta testers know this; they are out to help you...

Cheers,
Ralf



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-05 Thread Ralf Wildenhues
* Loïc Minier wrote on Mon, Jun 05, 2006 at 10:51:03AM CEST:
> On Sun, Jun 04, 2006, Paul Eggert wrote:
> 
> > First, Autoconf is supposed to warn about the suspicious usage of
> > datadir without defining datarootdir.  Did the warning not work for
> > you?  If so, can you show us how to reproduce the problem easily?
> 
>  Autoconf first warned of the non-handling of datarootdir in my
>  Makefiles when I tried to only update ./configure, and didn't complain
>  anymore when I updated **/Makefile.in, but the problem lies in a m4
>  macro which runs at configure time, and has nothing to do with
>  datarootdir in Makefiles IMO.

And right you are.  I'll make sure the 2.59d announcement will be more
general in this respect.

Thanks again,
Ralf



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-05 Thread Stepan Kasal
Hello,

On Sun, Jun 04, 2006 at 11:36:17AM -0700, Ben Pfaff wrote:
> Gnome packages will break with the introduction of ${datarootdir}.
...
>  The problem is in AM_GLIB_DEFINE_LOCALEDIR from
>  m4macros/glib-gettext.m4 [...]
> 

I added an example to this bug.

Actually, I think that Gnome should phase out glib-gettext and use
GNU gettext instead.  I filed this suggestion as
 

Have a nice day,
Stepan Kasal


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-05 Thread Loïc Minier
Hi,

On Sun, Jun 04, 2006, Ralf Wildenhues wrote:
> > However, I wonder whether it's worth mentioning breakage of
> > important software like Gnome in Autoconf's NEWS (or elsewhere),
> > and I told Loïc that I'd make that suggestion here.  Consider it
> > made :-)
> I wonder what's necessary to make the NEWS item explicit enough:
> - it's the single biggest item in the NEWS entries since 2.59.
> - it's one of the two items that I've explicitly hinted at as well
>   in the 2.59c release notes.

 I want to make it clear here: I didn't check Autoconf's NEWS because it
 isn't presented to me automatically on package upgrades, I expected a
 NEWS.Debian to warn me of anything to take care of.
   When I installed the CVS snapshot of autoconf on my Debian box, I
 expected some problems to pop up with various software, but I didn't
 see any backward incompatibility warnings.  Strictly speaking, none of
 what I reported against the Debian autoconf package was a backward
 incompatibility or upstream regression, yet it would affect so many
 software packages that it was worth highlighting and warning about.

 All I want is that Debian's NEWS (which is presented to the end-user /
 end-developer on upgrades) warns of important changes, and when a nice
 document such as upstream's NEWS is already available, I consider that
 all that is needed is a pointer to this document or a summary of the
 most important issues.
   It seems Ben already proposed a NEWS.Debian which outlines the
 problems I encountered, and that completely addresses my wish that a
 big warning pops up when you upgrade your autoconf package (thanks
 Ben!).

> I will mention it prominently again for 2.59d, and of course for 2.60.
> Please tell me what else is necessary.  Please consider making this item
> and the exit(3) one part of a NEWS.Debian, if NEWS isn't read enough.
> http://lists.gnu.org/archive/html/autoconf/2006-04/msg00085.html

 I'm afraid "NEWS" is not presented automatically on upgrades, probably
 because it isn't easily machine-readable, and because it doesn't take
 Debian specificities into account.

 I also had the feeling you were frustrated that I didn't see the NEWS
 document prior to reporting this bug.  I'm sorry that you spent extra
 effort in properly documenting this, I should have checked NEWS and
 requested a pointer to NEWS from our NEWS.Debian in the first place.

 Thanks for following this and sorry for requesting documentation of
 things already clearly documented upstream.

   Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-05 Thread Loïc Minier
On Sun, Jun 04, 2006, Paul Eggert wrote:
> Well, the general topic is already in NEWS.  I doubt whether the
> Autoconf maintainers can keep track of which versions of which other
> packages will run into problems with the datarootdir change (not to
> mention half a dozen similar changes :-).

 (Yes, but NEWS doesn't pop up automatically on Debian upgrades.  My bug
 report was incorrect in this respect and should have requested a
 warning in NEWS.Debian that end-users / end-developers should read NEWS
 because of important changes.)

> First, Autoconf is supposed to warn about the suspicious usage of
> datadir without defining datarootdir.  Did the warning not work for
> you?  If so, can you show us how to reproduce the problem easily?

 Autoconf first warned of the non-handling of datarootdir in my
 Makefiles when I tried to only update ./configure, and didn't complain
 anymore when I updated **/Makefile.in, but the problem lies in a m4
 macro which runs at configure time, and has nothing to do with
 datarootdir in Makefiles IMO.

> Second, that promiscuous 'eval' can lead to trouble.  First, it
> assumes that exactly one level of indirection will be right, which is
> not portable to future versions of Autoconf.  Second, if localedir
> contains special characters they can cause arbitrary shell code to be
> executed.

 I can only agree with you and cry of despair to see dangerous "eval"
 calls like the one I pointed out.  You reach the same conclusion than I
 do, and that is that the macro was completely broken in the first
 place.

> Something like this code (which I haven't tested) would be safer:
> for i in . . . . . . . . . . . . X; do
>   test $i = X && AC_MSG_ERROR([too many levels of indirection in localedir])
>   case $localedir in
> *'"'* | *'`'* | *'\'* | *'$('*)
>   AC_MSG_ERROR([invalid character sequence in localedir]);;
> *\$*) eval "localedir=\"$localedir\"" ||
>   AC_MSG_ERROR([invalid variable in localedir]);;
> *) break;;
>   esac
> done

 This looks like a workaround to me and could help for the interim where
 I want that macro to continue working while we sort out all Makefile.am
 from various software relying on the macro to use a future-proof method
 of passing a directory.

> Kind of a hassle, huh?  But this sort of hassle is inevitable once you
> start using 'eval' with uncontrolled input.

 Agreed, thanks for the snipset.

   Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-04 Thread Ralf Wildenhues
Hello Paul, Ben,

* Paul Eggert wrote on Sun, Jun 04, 2006 at 11:05:31PM CEST:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
> 
> >  The problem is in AM_GLIB_DEFINE_LOCALEDIR from
> >  m4macros/glib-gettext.m4 which hardcodes a double shell expansion:
> >localedir=`eval echo "${datadir}/locale"`

> First, Autoconf is supposed to warn about the suspicious usage of
> datadir without defining datarootdir.  Did the warning not work for
> you?  If so, can you show us how to reproduce the problem easily?

The warnings that have been put into place cannot work for these cases.
Even if we tried to warn about strings containing `${datarootdir}' in
config headers (which we don't, and can't easily do without risking
false positives), even then, we would not have caught this issue.
I don't see any reasonable way we can warn about this case.  At least
it usually causes non-silent breakage, thus is usually found quickly.

> Second, that promiscuous 'eval' can lead to trouble.  First, it
> assumes that exactly one level of indirection will be right, which is
> not portable to future versions of Autoconf.  Second, if localedir
> contains special characters they can cause arbitrary shell code to be
> executed.

Yes.

> Something like this code (which I haven't tested) would be safer:

Please don't recommend such code.  We have a FAQ entry (Ben already
quoted it) which shows how to deal with directory variables in a future-
proof way.  Let's just recommend that.

> for i in . . . . . . . . . . . . X; do
>   test $i = X && AC_MSG_ERROR([too many levels of indirection in localedir])
>   case $localedir in
> *'"'* | *'`'* | *'\'* | *'$('*)

I'm think this will break with some old shell.  I'd use backslash-
escaping only within case patterns, because of the comment to some
respective code we eliminated from Autoconf not so long ago:
  *\"* | *\`* | *\\* | *\$\(* )

(I meant to dig out the actual errors and document them at some
point...)

Cheers,
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-04 Thread Ralf Wildenhues
Hi Ben,

* Ben Pfaff wrote on Mon, Jun 05, 2006 at 12:10:32AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > I wonder what's necessary to make the NEWS item explicit enough:

> You sound a little frustrated.  I hope I'm not causing that.

No, you are not causing any frustration.  You are helping, and that
is very good!  I guess I need to work on the wording for the next
release message, though.  (The "if not using Automake" part was
obviously wrong, for example".)

> But I like the suggestion of adding this in NEWS.Debian.  I just
> did so.  Here is what I put in it.  If you have suggestions for
> improvement, please pass them along.

Looks good to me, and thank you very much for referring to the FAQ
entry!

Cheers,
Ralf


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-04 Thread Ben Pfaff
Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> I wonder what's necessary to make the NEWS item explicit enough:
> - it's the single biggest item in the NEWS entries since 2.59.
> - it's one of the two items that I've explicitly hinted at as well
>   in the 2.59c release notes.
>
> I will mention it prominently again for 2.59d, and of course for 2.60.
> Please tell me what else is necessary.  Please consider making this item
> and the exit(3) one part of a NEWS.Debian, if NEWS isn't read enough.
> http://lists.gnu.org/archive/html/autoconf/2006-04/msg00085.html

You sound a little frustrated.  I hope I'm not causing that.

But I like the suggestion of adding this in NEWS.Debian.  I just
did so.  Here is what I put in it.  If you have suggestions for
improvement, please pass them along.






NEWS for Debian packaging of Autoconf
-
  
This is the Debian packaged version of a CVS snapshot of Autoconf.  It
is close to what will ultimately be Autoconf 2.60.  I have introduced
it into Debian in pre-release to try to help upstream ferret out bugs
in advance.

This CVS snapshot should be largely compatible with older Autoconf
releases back to 2.50, and especially with 2.59.  Please read NEWS for
details.

Two changes bear especial emphasis.  First, quoting from the upstream
NEWS:

--
** Directory variables adjusted to recent changes in the GNU Coding Standards.
  The following directory variables are new:

datarootdir   read-only architecture-independent data root [PREFIX/share]
localedir locale-specific message catalogs [DATAROOTDIR/locale]
docdirdocumentation root [DATAROOTDIR/doc/PACKAGE]
htmldir   html documentation [DOCDIR]
dvidirdvi documentation [DOCDIR]
pdfdirpdf documentation [DOCDIR]
psdir ps documentation [DOCDIR]

  The following variables have new default values:

datadir   read-only architecture-independent data [DATAROOTDIR]
infodir   info documentation [DATAROOTDIR/info]
mandirman documentation [DATAROOTDIR/man]

  This means that if you use any of [EMAIL PROTECTED]@', [EMAIL PROTECTED]@', or
  [EMAIL PROTECTED]@' in a file, you will have to ensure `${datarootdir}' is
  defined in this file.  As a temporary measure, if any of those are
  found but no mention of `datarootdir', the substitutions will be
  replaced with values that do not contain `${datarootdir}', and a
  warning will be issued.
--

This has proven to be a problem in some cases where the advice in the
manual is not followed.  Please refer to the "Defining Directories"
node in the manual, titled "How do I `#define' Installation
Directories?", for more details.  (The manual can be obtained by
installing the "autoconf-doc" package from the non-free distribution
that accompanies Debian.)

Here is a second item that bears mention, again from upstream NEWS:

--
** AC_PROG_CC, AC_PROG_CXX
  No longer automatically arrange to declare the 'exit' function of C,
  when a C++ compiler is used.  Standard Autoconf macros no longer use
  'exit', so this is no longer an issue for them.  If you use C++, and
  want to call 'exit', you'll have to arrange for its declaration
  yourself.  But we now suggest you return from 'main' instead.
--

-- 
Ben Pfaff 
email: [EMAIL PROTECTED]
web: http://benpfaff.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-04 Thread Paul Eggert
Ben Pfaff <[EMAIL PROTECTED]> writes:

> However, I wonder whether it's worth mentioning breakage of
> important software like Gnome in Autoconf's NEWS (or elsewhere),

Well, the general topic is already in NEWS.  I doubt whether the
Autoconf maintainers can keep track of which versions of which other
packages will run into problems with the datarootdir change (not to
mention half a dozen similar changes :-).

>  The problem is in AM_GLIB_DEFINE_LOCALEDIR from
>  m4macros/glib-gettext.m4 which hardcodes a double shell expansion:
>localedir=`eval echo "${datadir}/locale"`
>
>  this results in a config.h with:
>  #define GNOMELOCALEDIR "${prefix}/share/locale"
>  which will obviously break at runtime.
>
>  I verified that adding another level of expansion:
>  localedir=`eval echo "${localedir}"`
>  fixes the problem.

First, Autoconf is supposed to warn about the suspicious usage of
datadir without defining datarootdir.  Did the warning not work for
you?  If so, can you show us how to reproduce the problem easily?

Second, that promiscuous 'eval' can lead to trouble.  First, it
assumes that exactly one level of indirection will be right, which is
not portable to future versions of Autoconf.  Second, if localedir
contains special characters they can cause arbitrary shell code to be
executed.

Something like this code (which I haven't tested) would be safer:

for i in . . . . . . . . . . . . X; do
  test $i = X && AC_MSG_ERROR([too many levels of indirection in localedir])
  case $localedir in
*'"'* | *'`'* | *'\'* | *'$('*)
  AC_MSG_ERROR([invalid character sequence in localedir]);;
*\$*) eval "localedir=\"$localedir\"" ||
  AC_MSG_ERROR([invalid variable in localedir]);;
*) break;;
  esac
done

Kind of a hassle, huh?  But this sort of hassle is inevitable once you
start using 'eval' with uncontrolled input.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-04 Thread Ralf Wildenhues
* Ben Pfaff wrote on Sun, Jun 04, 2006 at 08:36:17PM CEST:
> Loïc Minier reported in the Debian package's bug system that
> Gnome packages will break with the introduction of
> ${datarootdir}.  It looks to me like the real problem is really
> in the macro used by Gnome, and I've suggested that they fix it
> using what the Autoconf manual suggests in the Defining
> Directories node.
> 
> However, I wonder whether it's worth mentioning breakage of
> important software like Gnome in Autoconf's NEWS (or elsewhere),
> and I told Loïc that I'd make that suggestion here.  Consider it
> made :-)

I wonder what's necessary to make the NEWS item explicit enough:
- it's the single biggest item in the NEWS entries since 2.59.
- it's one of the two items that I've explicitly hinted at as well
  in the 2.59c release notes.

I will mention it prominently again for 2.59d, and of course for 2.60.
Please tell me what else is necessary.  Please consider making this item
and the exit(3) one part of a NEWS.Debian, if NEWS isn't read enough.
http://lists.gnu.org/archive/html/autoconf/2006-04/msg00085.html

I don't see how we can do more.
  
Cheers,
Ralf



Bug#370282: Worth mentioning that Gnome needs a fix for newer Autoconf?

2006-06-04 Thread Ben Pfaff
Loïc Minier reported in the Debian package's bug system that
Gnome packages will break with the introduction of
${datarootdir}.  It looks to me like the real problem is really
in the macro used by Gnome, and I've suggested that they fix it
using what the Autoconf manual suggests in the Defining
Directories node.

However, I wonder whether it's worth mentioning breakage of
important software like Gnome in Autoconf's NEWS (or elsewhere),
and I told Loïc that I'd make that suggestion here.  Consider it
made :-)

 Start of forwarded message 
Subject: Bug#370282: Introduction of datarootdir causes regression in macros 
expecting double-expansion to work
Reply-To: Loïc Minier <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Resent-From: Loïc Minier <[EMAIL PROTECTED]>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Ben Pfaff <[EMAIL PROTECTED]>
Resent-Date: Sun, 04 Jun 2006 14:48:13 UTC
Resent-Message-ID: <[EMAIL PROTECTED]>
Date: Sun, 4 Jun 2006 15:47:55 +0200
From: Loïc Minier <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Package: autoconf
Version: 2.59.cvs.2006.06.02-2
Severity: normal

Hi,

 (This probably ain't an autoconf bug, but I'm filing it here because it
 is exposed by the introduction of datarootdir in newer autoconf and
 will hit the non-negligible number of applications using the
 "AM_GLIB_DEFINE_LOCALEDIR" macro...)

 In short, old autoconf:
   --prefix=PREFIX install architecture-independent files in PREFIX
   --datadir=DIR  read-only architecture-independent data [PREFIX/share]

 new autoconf:
   --prefix=PREFIX install architecture-independent files in PREFIX
   --datarootdir=DIR  read-only arch.-independent data root [PREFIX/share]
   --datadir=DIR  read-only architecture-independent data [DATAROOTDIR]

 The problem is in AM_GLIB_DEFINE_LOCALEDIR from
 m4macros/glib-gettext.m4 which hardcodes a double shell expansion:
   localedir=`eval echo "${datadir}/locale"`

 this results in a config.h with:
 #define GNOMELOCALEDIR "${prefix}/share/locale"
 which will obviously break at runtime.

 I verified that adding another level of expansion:
 localedir=`eval echo "${localedir}"`
 fixes the problem.

 I doubt you will want to revert that autoconf change, and I don't know
 whether other macros are affected by this change, but I thought the bug
 tracker should see this bug.  In the end, you might want to document
 this incompatibility in some upgrading documentation.

 I've reported the problem of the AM_GLIB_DEFINE_LOCALEDIR macro at:

 feel free to subscribe upstream to follow the discussion.

 Right now, all I can think of to workaround the problem is to add
 another level of expansion in all cases in the macro, or to pass
 at least datarootdir or datadir to configure flags.  I would be glad if
 you can provide some help in handling this large breakage though.

   Bye,
-- 
Loïc Minier <[EMAIL PROTECTED]>

 End of forwarded message 

-- 
"Ho ho ho. I _so_ enjoy making a fool out of myself."
--Linus, on Christmas Day, 2000