After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 66155 - intltool-update hack to figure out package name fails for gconf, other packages
intltool-update hack to figure out package name fails for gconf, other packages
Status: RESOLVED FIXED
Product: intltool
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
: 65988 70371 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-12-04 15:20 UTC by Carlos Perelló Marín
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix the ggv's .pot name (1.08 KB, patch)
2002-03-03 13:09 UTC, Carlos Perelló Marín
none Details | Review
Patch I just described (2.04 KB, patch)
2002-05-01 09:33 UTC, Abel Cheung
none Details | Review
Enhanced patch that fixes both #66155 and #78926 (2.48 KB, patch)
2002-05-01 12:14 UTC, Abel Cheung
none Details | Review
Patch fixing bad regex I introduced (1.62 KB, patch)
2002-05-02 01:50 UTC, Abel Cheung
none Details | Review

Description Carlos Perelló Marín 2001-12-04 15:20:53 UTC
If you use intltool-update -P at gconf/po directory (branch gconf-1-0) It
creates the gconf$MAJOR_VERSION.pot file because this (from configure.in):

<configure.in>

dnl used to rename everything and support simultaneous installs.
dnl not incremented for bugfix or unstable releases.
MAJOR_VERSION=1
AC_SUBST(MAJOR_VERSION)

GETTEXT_PACKAGE=gconf$MAJOR_VERSION
AC_SUBST(GETTEXT_PACKAGE)
AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,"$GETTEXT_PACKAGE")

</configure.in>

I don't know if this could be fixed.
Comment 1 Carlos Perelló Marín 2001-12-04 15:42:22 UTC
Pan has a similar problem. you get AC_PACKAGE_NAME.pot instead of
pan.pot. It uses:

<configure.in>

dnl init autoconf
AC_INIT([pan],[0.11.0.93],[http://bugzilla.gnome.org/enter_bug.cgi?product=Pan])AC_PREREQ(2.50)
AC_CONFIG_SRCDIR(pan/pan.c)


dnl init automake
AM_INIT_AUTOMAKE(AC_PACKAGE_NAME,AC_PACKAGE_VERSION)

</configure.in>
Comment 2 Darin Adler 2001-12-04 16:12:57 UTC
*** Bug 65988 has been marked as a duplicate of this bug. ***
Comment 3 Carlos Perelló Marín 2001-12-04 16:59:27 UTC
gaby module has a similar problem like previous ones, but also it use
only a configure.ac file instead of configure.in then intltool does
not know how use this package (It looks only for configure.in or
Makefile but it does not look for configure.ac).

Should I add a new bug report?
Comment 4 Darin Adler 2001-12-04 17:02:30 UTC
I think the fix here is going to be to add a package name
parameter to intltool-update, for use in cases where it doesn't
correctly guess the package name by parsing the configure.in file.
Comment 5 Kenneth Rohde Christiansen 2002-02-21 09:58:26 UTC
What happened with this? What did we agree on with havoc?
Comment 6 Darin Adler 2002-02-25 17:25:58 UTC
*** Bug 70371 has been marked as a duplicate of this bug. ***
Comment 7 Carlos Perelló Marín 2002-03-03 13:09:41 UTC
Created attachment 6944 [details] [review]
Fix the ggv's .pot name
Comment 8 Carlos Perelló Marín 2002-03-03 13:10:43 UTC
Here you have a patch to get the name from packages that use AC_INIT
to give the package name.


I have only use cut && paste and it have a problem ;-(

It works for ggv that use:
AC_INIT(ggv, 1.99.0, http://bugzilla.gnome.org/enter_bug.cgi?product=ggv)

but with Pan:

AC_INIT([pan],[0.11.90],[http://bugzilla.gnome.org/enter_bug.cgi?product=Pan])

I don't know how should I remove the [] chars and I get a [pan].pot
file :-(
Comment 9 Kenneth Rohde Christiansen 2002-03-03 19:48:37 UTC
I will find you on irc and help out
Comment 10 Carlos Perelló Marín 2002-03-03 20:09:39 UTC
Fixed with kenneth's help ;-)

Here is the correct line:

$name = $1 if $conf_source =~ /^AC_INIT\(\[?(\w+)/m;


Could I commit this change?

With this change, I think that we only have the gconf problem.
Comment 11 Kenneth Rohde Christiansen 2002-03-03 22:00:31 UTC
Yes, please commit and then close this bug report afterwards

Thanks!
Comment 12 Kenneth Rohde Christiansen 2002-03-03 22:02:28 UTC
Sorry don't close, this bug report is also about gconf :(
Comment 13 Abel Cheung 2002-05-01 09:32:15 UTC
Hopefully the patch below can be the ultimate patch that covered all
of the possible problems discussed in this thread. It incorporates
Carlos' unapplied patch too.
Comment 14 Abel Cheung 2002-05-01 09:33:19 UTC
Created attachment 8090 [details] [review]
Patch I just described
Comment 15 Abel Cheung 2002-05-01 09:37:25 UTC
#78926 is very similar to this report.
Comment 16 Abel Cheung 2002-05-01 12:14:30 UTC
Created attachment 8093 [details] [review]
Enhanced patch that fixes both #66155 and #78926
Comment 17 Kenneth Rohde Christiansen 2002-05-02 00:30:13 UTC
I'll look at the patch tomorrow and most possibly apply it
Comment 18 Abel Cheung 2002-05-02 01:26:36 UTC
Just discovered some last-minute bug I introduced after intltool
bumped version, too bad.
The regular expression to extract variable is too strict, it
doesn't allow any non-'\w' and non-'$' character to go through.
That means "GETTEXT_PACKAGE=gimp-plugin-template" will be
extract as "GETTEXT_PACKAGE=gimp".

Perhaps need to replace [\$\w] into [^,\)\s\]] in a few
places. Patch following.

Kenneth, can you please reopen this bug for now?
Comment 19 Abel Cheung 2002-05-02 01:50:14 UTC
Created attachment 8109 [details] [review]
Patch fixing bad regex I introduced
Comment 20 Christian Rose 2002-05-03 08:35:46 UTC
Does this also fix the problems with sawfish? Or does that have
nothing to do with this problem?
Comment 21 Abel Cheung 2002-05-03 08:56:22 UTC
I'm not quite sure what you mean about sawfish. But if
you mean that sawfish pot file can't be generated by
intltool, then this has nothing to do with intltool.
Sawfish has it's own method to generate pot, similar
to what gimp-perl does.
Comment 22 Christian Rose 2002-05-03 09:03:48 UTC
Ok. But intltool could be extended with some weird hackery to support
that format, no? But I guess that request should go into a bug report
of its own, and I'm not sure it's even worth it since it's a minor
inconvenience and since we might go with Metacity as official GNOME wm
in the future.