Bug#1018950: Fwd: Bug#1018950: gettext-el: warnings when po-mode.el is compiled with GNU Emacs 28

[Bruno Haible]

Hello Santiago, Vincent,

> Here are the details of the warnings (note that the compilation of
> the other .el files does not yield any warning; this is specific
> to po-mode.el):
> 
> In toplevel form:
> po-mode.el:180:2: Warning: custom-declare-variable `po-highlight-face' 
> docstring has wrong usage of unescaped single quotes (use \= or different 
> quoting)

This type of warning will not be fixed. It's explained in


that to fix this, every ' needs to be replaced with a quadrigraph \\=' .
The point of this warning is to make the doc string ugly in the source file
so that it becomes pretty when displayed in a certain way in Emacs.

However, for po-mode.el, *no one* views these doc strings in Emacs.
The maintainer — that's me — views them in the source code, outside Emacs.
Therefore it would be a disgrace to make the doc strings more ugly in the
source code.

> In po-mode:
> po-mode.el:1068:14: Warning: ‘write-contents-hooks’ is an obsolete variable 
> (as of 22.1); use ‘write-contents-functions’ instead.

Fixed through
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=7793b37d96e1e343585fd37c19612fcffa3aa035

> In po-set-msgstr-form:
> po-mode.el:2114:13: Warning: (lambda nil \...) quoted with ' rather than with 
> #'

Referring to , the point of
this warning is to allow the Emacs compiler to compile this lambda.
But this is not necessary here, since it's a hook function (rarely invoked)
and may invoke functions that are not present at compile-time.

> In po-show-source-context:
> po-mode.el:2570:4: Warning: ‘goto-line’ is for interactive use only; use 
> ‘forward-line’ instead.

According to 
  "the reason why goto-line should not be a frequently used command
   is that normally there's no reason to want to get to line number N
   unless you have a program that told you there's something interesting
   on that line."
But that's precisely the case here: The PO file contains a reference
to source line number N. Therefore goto-line is the right thing here.

> In po-tags-search:
> po-mode.el:2639:10: Warning: ‘tags-loop-continue’ is an obsolete function (as 
> of 27.1); use ‘fileloop-continue’ instead.
> po-mode.el:2643:8: Warning: ‘tags-loop-continue’ is an obsolete function (as 
> of 27.1); use ‘fileloop-continue’ instead.

fileloop-continue does not exist in Emacs 26 or older. However, po-mode supports
Emacs 22 or newer. Therefore nothing to be done here.

> In po-tags-loop-operate:
> po-mode.el:2703:12: Warning: Use ‘with-current-buffer’ rather than 
> save-excursion+set-buffer
> 
> In po-mark-found-string:
> po-mode.el:2724:6: Warning: Use ‘with-current-buffer’ rather than 
> save-excursion+set-buffer

The Emacs documentation at
https://www.gnu.org/software/emacs/manual/html_node/elisp/Current-Buffer.html
does not state that there would any problem with 'set-buffer'. It just presents
'with-current-buffer' as an alternative.

As long as it's not broken, I won't change it.

> In end of data:
> po-mode.el:2110:4: Warning: the function ‘ediff-quit’ is not known to be 
> defined.

False alarm. 'ediff-quit' is only used once ediff mode is entered.

Bruno

Bug#1077059: Fwd: Bug#1077059: gettext: xgettext complains about missing charset header when using the exclude option

[Bruno Haible]

Hello Santiago,

Thanks for the forward.

It's fixed through
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=d64216aecaf15883c944539657562127b10d0e1a

As this was a regression in version 0.22, I encourage you to apply the fix
(attached) in Debian.

Bruno

>From d64216aecaf15883c944539657562127b10d0e1a Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sat, 27 Jul 2024 21:05:27 +0200
Subject: [PATCH] xgettext: PO: Fix error when a --exclude-file option is
 present (regression 2023-03-10).

Reported by Nicolas Peugnet  via Santiago Vila
at <https://lists.gnu.org/archive/html/bug-gettext/2024-07/msg00030.html>.

* gettext-tools/src/x-po.c (extract_add_message): If the message is the header
entry and is among the messages to exclude, save the header charset from it
before discarding it.
---

diff --git a/gettext-tools/src/x-po.c b/gettext-tools/src/x-po.c
index 740aa3d89..a91564535 100644
--- a/gettext-tools/src/x-po.c
+++ b/gettext-tools/src/x-po.c
@@ -1,5 +1,5 @@
 /* xgettext PO, JavaProperties, and NXStringTable backends.
-   Copyright (C) 1995-1998, 2000-2003, 2005-2006, 2008-2009, 2014, 2018, 2020, 2023 Free Software Foundation, Inc.
+   Copyright (C) 1995-2024 Free Software Foundation, Inc.
 
This file was written by Peter Miller 
 
@@ -65,10 +65,6 @@ extract_add_message (default_catalog_reader_ty *this,
  char *prev_msgid_plural,
  bool force_fuzzy, bool obsolete)
 {
-  /* See whether we shall exclude this message.  */
-  if (exclude != NULL && message_list_search (exclude, msgctxt, msgid) != NULL)
-goto discard;
-
   /* If the msgid is the empty string, it is the old header.  Throw it
  away, we have constructed a new one.  Only remember its charset.
  But if no new one was constructed, keep the old header.  This is useful
@@ -111,6 +107,10 @@ extract_add_message (default_catalog_reader_ty *this,
   return;
 }
 
+  /* See whether we shall exclude this message.  */
+  if (exclude != NULL && message_list_search (exclude, msgctxt, msgid) != NULL)
+goto discard;
+
   /* Invoke superclass method.  */
   default_add_message (this, msgctxt, msgid, msgid_pos, msgid_plural,
msgstr, msgstr_len, msgstr_pos,

Bug#752135: git-merge-changelog: Overstates the need for .gitattributes

[Bruno Haible]

Hi Samuel and Simon,

> I believe you are right, and I
> suggest the patch below.  Bruno, what do you think?

Yes, you are right. I have a package with a .gitattributes at the
top-level and a src/ChangeLog, and the .gitattributes file has the
desired effect. (Things may well have been different 16 years ago.
But what matters are the 'git' versions in use today.)

> Maybe today it is
> more fashionable to use top-level .gitattributes and not bother with
> per-directory files that feels like a CVS idiom.

Absolutely. I'm committing this:


2024-07-02  Bruno Haible  

git-merge-changelog: Simplify installation instructions.
Reported by Samuel Bronson  via Simon Josefsson in
<https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00014.html>.
* lib/git-merge-changelog.c: Suggest creating a .gitattributes file only
at the top-level.

diff --git a/lib/git-merge-changelog.c b/lib/git-merge-changelog.c
index 3cffe1fd2f..60754c8367 100644
--- a/lib/git-merge-changelog.c
+++ b/lib/git-merge-changelog.c
@@ -1,5 +1,5 @@
 /* git-merge-changelog - git "merge" driver for GNU style ChangeLog files.
-   Copyright (C) 2008-2021 Bruno Haible 
+   Copyright (C) 2008-2024 Bruno Haible 
 
This file is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
@@ -55,8 +55,8 @@
   name = GNU-style ChangeLog merge driver
   driver = /usr/local/bin/git-merge-changelog %O %A %B
 
- - In every directory that contains a ChangeLog file, add a file
-   '.gitattributes' with this line:
+ - Add to the top-level directory of the checkout a file '.gitattributes'
+   with this line:
 
   ChangeLogmerge=merge-changelog
 
@@ -77,12 +77,12 @@
Additionally, for hg users:
  - Add to your $HOME/.hgrc the lines
 
-[merge-patterns]
-ChangeLog = git-merge-changelog
+  [merge-patterns]
+  ChangeLog = git-merge-changelog
 
-[merge-tools]
-git-merge-changelog.executable = /usr/local/bin/git-merge-changelog
-git-merge-changelog.args = $base $local $other
+  [merge-tools]
+  git-merge-changelog.executable = /usr/local/bin/git-merge-changelog
+  git-merge-changelog.args = $base $local $other
 
See <https://www.selenic.com/mercurial/hgrc.5.html> section merge-tools
for reference.

Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test

[Bruno Haible]

Santiago Vila wrote:
> The message about jobserver disappeared when I disabled parallel build.
> I guess it is some kind of Makefile bug.

The message was:
  warning: jobserver unavailable: using -j1.

To me, this sounds like 'make' could not create a jobserver, because the
jobservers rely on named pipes [1] and the reporter says he's in a chroot.
Some file names may not be allowed in a chroot, or some directory may be
missing.

I don't see this as a Makefile bug, but rather as a limitation of the
specific chroot environment.

Bruno

[1] https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html

Bug#1057120: Fwd: Bug#1057120: gettext: FTBFS on amd64 in sid chroot due to failing autopoint-3 test

[Bruno Haible]

Santiago Vila wrote:
> FAIL: autopoint-3
> =
> 
> make[7]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> : error: macro names must be identifiers

To analyze this error, I would add a 'set -x' command in line 2
of gettext-tools/tests/autopoint-3, and retry the build.

> hello.c: In function 'main':
> hello.c:31:63: warning: implicit declaration of function 'getpid' 
> [-Wimplicit-function-declaration]
> 31 |   printf (_("This program is running as process number %d."), getpid 
> ());
>|   ^~

This warning was fixed by the gettext-tools/examples/hello-c/hello.c change in
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=eb0ded32dbcd7bf6ccffc038509983ccca52631b

Bruno

Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes

[Bruno Haible]

Zebediah Beck,

You haven't read my bug report.

Bruno

Bug#1056357: general: Command line of any program invocation is limited to less than 3544 bytes

[Bruno Haible]

Package: general
Severity: important
X-Debbugs-Cc: br...@clisp.org

I'm using Debian GNU/Linux on hppa, in a virtual machine emulated by QEMU
8.0.2.
$ uname -srm
Linux 6.3.0-2-parisc parisc

In this machine, for the invocation of any program, the length of the command
line (= all arguments together) is limited to less than 3544 bytes.

How to reproduce:

In bash:
$ /bin/echo `seq 913`
-bash: /bin/echo: Argument list too long

In dash:
$ /bin/echo `seq 913`
dash: 1: /bin/echo: Argument list too long

I also see this while doing "make check" of packages that have more than 1000
tests. So, it appears to be a general problem.

The values returned by getconf don't match the reality:
$ getconf ARG_MAX
2097152
$ getconf _POSIX_ARG_MAX
2097152

I have looked at the values of several files in /sys/kernel and
/proc/sys/kernel, without finding the cause.

For comparison, in a different VM, running "Linux 6.3.7-t2 parisc" (from the
T2-SDE distribution), I don't observe this bug. Both machines have the same
amount of "physical" RAM: 256 MiB.

The ulimit values don't appear to be the cause, because they are similar in
the two machines:
In the Debian VM (with the bug):
$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 849
max locked memory   (kbytes, -l) 65536
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 849
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited
In the T2-SDE machine, with no bug:
$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size  (blocks, -c) 1048575
data seg size   (kbytes, -d) unlimited
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 909
max locked memory   (kbytes, -l) 8192
max memory size (kbytes, -m) unlimited
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 8192
cpu time   (seconds, -t) unlimited
max user processes  (-u) 909
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Bug#1032010: gettext: binary in /usr/lib should move to libexec

[Bruno Haible]

Hi,

Bastien Roucariès wrote in
:

> /usr/lib/x86_64-linux-gnu/gettext/cldr-plurals
> /usr/lib/x86_64-linux-gnu/gettext/hostname
> /usr/lib/x86_64-linux-gnu/gettext/project-id
> /usr/lib/x86_64-linux-gnu/gettext/urlget
> /usr/lib/x86_64-linux-gnu/gettext/user-email
> should go to:
> /usr/libexec/x86_64-linux-gnu/gettext/cldr-plurals
> /usr/libexec/x86_64-linux-gnu/gettext/hostname
> /usr/libexec/x86_64-linux-gnu/gettext/project-id
> /usr/libexec/x86_64-linux-gnu/gettext/urlget
> /usr/libexec/x86_64-linux-gnu/gettext/user-email

Upstream, this will be fixed in the next release, through
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=43a4b5eeecaf9805064ec718755d0a033e8f2f9b

But upstream, the file names before and after are these:

before:
 /usr/lib/gettext/cldr-plurals
 /usr/lib/gettext/hostname
 /usr/lib/gettext/project-id
 /usr/lib/gettext/urlget
 /usr/lib/gettext/user-email
after:
 /usr/libexec/gettext/cldr-plurals
 /usr/libexec/gettext/hostname
 /usr/libexec/gettext/project-id
 /usr/libexec/gettext/urlget
 /usr/libexec/gettext/user-email

IMO, there's no point in having a per-architecture subdir under /usr/libexec.
You don't have one under /bin either. This means, a user can't install the
32-bit binaries and the 64-binaries or the x32 binaries of the gettext-tools
package together; they conflict with each other.

Bruno

Bug#786885: Broken gettext check in the build system of bison

[Bruno Haible]

The issue was fixed through
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=b67399b40bc5bf3165b09e6a095ec941d4b30a97
and is thus contained in gettext-0.19.8 and newer.

The *gettext functions in musl libc work seamlessly with .mo files
produced by msgfmt 0.22 or newer, except for the 'I' flag in format
strings, that musl libc does not support.

Bruno

Bug#1032011: Fwd: Bug#1032011: gettext: Private library should go to private subdir under lib

[Bruno Haible]

Santiago Vila wrote:
>  Mensaje reenviado 
> Asunto: Bug#1032011: gettext: Private library should go to private subdir 
> under lib
> Fecha: Sun, 26 Feb 2023 14:57:45 +
> De: Bastien Roucariès 
> Responder a: Bastien Roucariès , 1032...@bugs.debian.org
> Para: Debian Bug Tracking System 
> 
> Package: gettext
> Version: 0.21-11
> Severity: minor
> Tags: upstream
> 
> Dear Maintainer,
> 
> Private library /libgettextsrc-0.21.so and libgettextlib-0.21.so should go to
> private sudbir aka:
> usr/lib/x86_64-linux-gnu/gettext/libgettextsrc-0.21.so
> and
> usr/lib/x86_64-linux-gnu/gettext/libgettextlib-0.21.so
> 
> This is an upstream bug that should be reported

Summary:

- Doing so upstream would violate both the GNU Coding Standards and the
  File system Hierarchy Standard.

- You can do such things at the distro level, if you make sure that the
  dynamic linker will find the libraries there.

Details:

Upstream, I have to respect two standards:

  * The GNU Coding Standards [1] say that ${libdir) is "The directory for
object files and libraries of object code." Very simple and unambiguous.

  * The File system Hierarchy Standard [2] gives me the choice between
installing in /usr/lib or /usr/lib/gettext.
But what you proposed is not /usr/lib/gettext, it is a subdirectory of
/usr/lib/x86_64-linux-gnu !

At the distro level, the distro decides where to put things. But if you
put shared libraries in /usr/lib/x86_64-linux-gnu/gettext/ you will
either have to make sure that this directory is known to ld.so (via
ld.so.conf, I guess), or use RPATH headers in the binaries (which many
distributions don't like to do).

Note that in future gettext versions, libgettextlib may be integrated
into libgettextsrc. So, we would be talking about a subdirectory for just
a single library.

Bruno

[1] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s06.html

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

[Bruno Haible]

Santiago Vila wrote:
> And yes, I assume it already works in maintainer mode, but only if mcs is in 
> PATH.

The point of distributing the csharpexec-test.exe as a binary is to
be able to have C# support in 'msgunfmt' even when the environment
contains a C# execution engine but no C# compiler.

Bruno

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

[Bruno Haible]

Santiago Vila wrote:
> For completeness: Would it make sense to add an indication, somewhere, about 
> the way
> to create the .exe from the .cs? This is something that surely everybody using
> mono knows, but I had to search for it. I guess this would be correct:
> 
> mcs -out:csharpexec-test.exe csharpexec-test.cs

That's how one would do it today, yes, if one were to modify csharpexec-test.cs.
But the way I did it in 2005, IIRC, was to use the Pnet C# compiler:

  cscc -o csharpexec-test.exe csharpexec-test.cs

since, at that time, this was the only way to create a .exe that worked with
both ilrun (pnet) and mono. The Pnet C# tools, by now, are long gone from
Debian...

> I don't think a Makefile is required for that, but if it's done in a Makefile,
> it would help if it's not triggered by automake maintainer's mode (not sure if
> that's possible), as I'm currently running autoreconf and this would force me
> to add an extra build-dependency just for a single file.

No, you shouldn't rebuild that file, because when you use mcs version X to
build it, it will not be able run with mono versions Y, for Y < X. _If_ you
want to rebuild it, you should use a very old mcs version for doing that.

Bruno

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

[Bruno Haible]

Adrian Bunk wrote:
> In practice the main usecase for Mono on Linux is porting of 
> proprietary Windows programs to Linux.
> 
> > and also isn't it useful for building mobile apps [2]?
> 
> "Build cross-platform Android & iOS apps using C# and .NET in Visual 
>  Studio on Windows and macOS."[3]
> ...
> [3] https://learn.microsoft.com/en-us/xamarin/?WT.mc_id=dotnet-35129-website

Oh, that's a pity. I thought that there were free-software uses of C#
on Linux, but it appears that MonoDevelop is dead [4][5] and thus most
of it is gone or pointless. Also, Tomboy [6] has left the C# world.

Thanks for having put the record straight, Adrian!

Bruno

[4] https://en.wikipedia.org/wiki/MonoDevelop
[5] https://github.com/mono/monodevelop
[6] https://en.wikipedia.org/wiki/Tomboy_(software)

Bug#1031952: Fwd: Bug#1031952: gettext: Missing source for an installed windows binary

[Bruno Haible]

Santiago Vila wrote:
> Summary: There is no source for gettext-tools/m4/csharpexec-test.exe.

Fixed through 
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=1bda6586b87f7e258c16bd0dca5c43048b9920a9

Thanks for the report.

> Note: The Debian package disabled the mono stuff in version 0.17-7 (dated 
> 2009-08-17)

That's a pity. Isn't GNOME using C# [1], and also isn't it useful for building
mobile apps [2]?

Bruno

[1] https://www.mono-project.com/docs/gui/gtksharp/
[2] https://dotnet.microsoft.com/en-us/apps/xamarin

Bug#314832: Fwd: Bug#314832: unzip: does not respect umask

[Bruno Haible]

Santiago Vila wrote:
> If you want to follow Bruno's suggestion that unzip is secure by default 
> (which I would support), I guess it would not be a lot of work, because, 
> once that there is already a new command line option for that, it would 
> be just a matter of reversing its logic (i.e. instead of 
> -k/--keep-permissions we could have another option which does the opposite).

The -k/--keep-permissions already implements the "secure by default" principle.
It is documented like this in the unzip610c.ann file:

  - New -k/--keep-permissions option controls how permissions are restored
on Unix and VMS systems.  The default behavior has changed to apply
Unix umask or VMS default protection to the archive permissions.  With
-k, the archive permissions are restored, ignoring the Unix umask or
VMS default protection (the old default behavior).  With -k-, the
archive permissions are ignored, and the Unix umask or VMS default
protection determines the permissions.

and like this in the History.610 file:

  - Added option -k/--keep-permissions on AtheOS, BeOS, Unix, and VMS, to
control how archived permissions or protections are determined on
extracted files and directories.  The default behavior has changed
from previous UnZip versions.  Now, by default, on AtheOS, BeOS, and
Unix, the current umask value is applied (to the normal
user/group/other permissions).

Bruno

Bug#314832: unzip: does not respect umask

[Bruno Haible]

Package: unzip
Version: 6.0
Severity: normal

I still see this bug in version 6.0 (6.0-26ubuntu3, to be precise).

It's a security issue (because it allows other users on the same machine to
overwrite the extracted files, if they know the file names).

As such:
  * It should be treated with severity at least 'normal', per [1].
  * Secure behaviour should be the default, not just enabled by an option.
Even if it breaks backward compatibility!

[1] https://www.debian.org/Bugs/Developer.en.html#severities

Bug#978315: xgettext complains about UTF conformance of strings not marked for translation

[Bruno Haible]

Hi Santiago, Samuel,

> The upload of gettext 0.21 for Debian unstable has made package "dasher",
> maintained by Samuel Thibault (in Cc), not to build anymore, as reported here
> by Lucas Nussbaum:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978315
> 
> We are not sure where is exactly the problem (either "dasher" or "gettext").
> 
> In short: xgettext seems to parse and complain about UTF conformance
> of strings even if they are not marked for translation.
> 
> Here is a minimal test case provided by Samuel:
> 
> - Begin forwarded message -
> 
> € cat test.c
> 
> #include 
> 
> void f(const wchar_t *str) { }
> 
> void g(void) {
>   f(L"\xABCDFF");
> }
> 
> 
> € xgettext test.c
> xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
> UNICODE_VALUE (c) < 0x11' failed.
> 
> Samuel
> 
> - End forwarded message -

This behaviour was introduced in gettext 0.20, with the ability to grok
C11 and C++11 string literals.

In the next gettext release, functions like 'f' (which take a 'const wchar_t *'
argument) can be designated as gettext-like functions, for which the argument
needs to be extracted and put into the POT file. For this, it must be possible
to convert it to UTF-8.

The assertion could be converted to a reasonable error message, sure.

Having a reasonable error message (with line number) *and* emitting this error
message only when the string actually gets extracted would make xgettext more
complex.

Since Samuel says:

  ... the file that poses problem is Testing/gtest/test/gtest_unittest.cc
  This is not something that contains anything to be translated, we'd need
  some option to just ignore Testing/ entirely.

this looks like the better option.

Bruno

Bug#968437: xindy-rules: Incorrect Norwegian sorting of č and š

[Bruno Haible]

Hi Norbert,

>From your description, it looks like an issue in xindy, not in GNU clisp
on which xindy is based in TeX Live.

Therefore the proper place to report this issue is with the xindy
developer Joachim Schrod. Probably at https://github.com/jschrod/xindy.ctan .

Bruno

Bug#507091: xgettext: fails to detect 'gettext -e' and 'eval_gettext -e' strings

[Bruno Haible]

I wrote:
> This is now fixed:
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=7643c58c13761bf0062c73d3114d4243250e8be9
> 
> The fix will be contained in the next release.

The fix is contained in gettext 0.20.2.

Bruno

Bug#925129: ffcall failed to build mips64 R6 version due to Illegal instruction

[Bruno Haible]

Hi,

In  you reported
a problem with the use of the 'jr $25' instruction on MIPS32R6. Thanks for
this report.

I've changed the code to use the new opcode (previously written as
'jal $0,$25') always, since this opcode is supported since the earliest
MIPS ISAs.

https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=commitdiff;h=5f801d3d01a079c49c1e84b02ab5a153efd5c428

Bruno

Bug#764483: gettext: Please support setting COPYRIGHT_HOLDER from an autoconf variable (fwd)

[Bruno Haible]

Hi Santiago,

Re 
   

> For dpkg, which uses muliple po directories, I'd like to be able to
> set the COPYRIGHT_HOLDER variable centrally, instead of having to set
> it on each po/Makevars file, and possibly having to keep it in sync.
> 
> It would be nice if gettext supported setting it from an autoconf
> variable (with AC_SUBST), in the same way MSGID_BUGS_ADDRESS falls
> back to use PACKAGE_BUGREPORT when MSGID_BUGS_ADDRESS is empty.
> 
> This might require setting something like:
> 
>   PACKAGE_COPYRIGHT_HOLDER = @PACKAGE_COPYRIGHT_HOLDER@
> 
> in Makefile.in.in, and making the code fallback to use that if
> COPYRIGHT_HOLDER is not set.

This would be a useful feature for packages with more than 10 'po'
directories.

But given that
  - Most packages have not more than 2 'po' directories,
  - Even dpkg has only 4 'po' directories [1],
  - The copyright holder typically does not change more frequently
than once in 10 years,
this feature does not seem worth the added complexity in the
documentation. Namely, the current state [2] is that
  - customizations for the build process go in configure.ac,
  - customizations for the 'po' directories go in po/Makevars and
po/LINGUAS and po/POTFILES.in.
The suggested feature would blur this simple rule.

So, it's declined.

Bruno

[1] git clone https://git.dpkg.org/git/dpkg/dpkg.git
[2] https://www.gnu.org/software/gettext/manual/html_node/Adjusting-Files.html

Bug#507091: xgettext: fails to detect 'gettext -e' and 'eval_gettext -e' strings

[Bruno Haible]

Hi,

Eugene V. Lyubimkin wrote in
:

> While 'gettext "abcde"' in shell script is well recognizeable,
> 'gettext -e "abcde"' is not recognizeable at all.

This is now fixed:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=7643c58c13761bf0062c73d3114d4243250e8be9

The fix will be contained in the next release.

> Similar with 'eval_gettext'.

eval_gettext does not support a '-e' option. See the documentation:
https://www.gnu.org/software/gettext/manual/html_node/eval_005fgettext-Invocation.html

Thanks for the report.

Bruno

Bug#920824: libunistring: please disable --as-needed

[Bruno Haible]

> Maybe eventually Debian will use --as-needed by default too

In this case, I would suggest to apply the fix that has been done
upstream:
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=cca32830b57e91f837c01d15b8732f23ff97fc36

Bruno

Bug#910246: [ebo...@apache.org: Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro]

[Bruno Haible]

Hi Emmanuel,

> Out of curiosity, why is such a sophisticated Java version detection
> logic necessary? As far as I know it's rather unique. If gettext only
> needs a Java 1.4 compiler any version of Java released in the past 15
> years is suitable anyway.

The 'javacomp' macro and module are made for packages that install
compiled Java code (.jar files), which may be run by a different Java
version than the one that compiled it.

1) Due to the bytecode format, code compiled by java version X (without
   particular options) cannot be run by java version Y, where Y < X.
   This is not a problem for distros, because distros know which is their
   minimum supported Java version, but is a problem when users compile
   a package on their own. So, the need arises to use the '-target' option.
   But not all javac versions support the '-target' option; GCJ had a
   different but similar option. So one needs to look carefully at the
   javac compiler version...

2) The Java language evolves. Code that was correct in the past may not
   compile with newer Java versions, without particular options. For
   example, code that defines a method named 'assert' or 'var'. So, one
   needs to use the '-source' option. Again, this option depends on the
   compiler brand and version.

Additionally, the two are intertwined, because you cannot use the
'-target' option without the '-source' option...

Bruno

Bug#910246: [ebo...@apache.org: Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro]

[Bruno Haible]

Hi Santiago,

> Dear gettext maintainers:
> 
> I have received this report from the Debian bug system.
> 
> A problem like this was already reported by Emmanuel and fixed in git,
> from where I took the fix for the Debian package, but Java keeps
> evolving all the time and the fix from March is not enough anymore.

So I assume you already incorporated the 3 patches from March 2018:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2d3dd35cb263f6566b2924a2adae99385c440f46
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=e6cf0b3040eb5d77eb1c03a7f8231a65a1f11e16
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=8e33103c084e5c7714e821f5fae592b9cbbb4781

Then, please apply the 2 patches from September 2018:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=bd09403f71a792b4e5c482c7ebb29d26c129dbe6
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=0782fa4dc036a709d5501a8712c5331489c28be9

Note: There are multiple copies of the relevant files in the gettext
tarball; the patches needs to be applied to each.

$ find . -name javacomp.m4
./gettext-tools/gnulib-m4/javacomp.m4
./gettext-runtime/gnulib-m4/javacomp.m4
$ find . -name javacomp.h
./gettext-tools/gnulib-lib/javacomp.h
$ find . -name javacomp.c
./gettext-tools/gnulib-lib/javacomp.c
$ find . -name javaversion.h
./gettext-tools/gnulib-lib/javaversion.h

Yes, Java keeps evolving. The last among the mentioned patches ought
to keep things working when Java 12 is released in 6 months, Java 13
in 12 months, etc. until Java 17. Let's see whether it works out...

Bruno

Bug#886986: please remove bump-fasl-loader-version.patch

[Bruno Haible]

Sébastien Villemot wrote:
> >   1) Will the package manager report a conflict?
> 
> Yes.
> 
> >   2) Will the package manager propose, as solution of this conflict, to 
> > install
> >  another binary package for xindy? Or will it only propose to remove 
> > xindy?
> 
> Only two options will be available:
> 1) either upgrade clisp and xindy together
> 2) or do not upgrade any of them
> 
> In the case where an update of clisp is available, but that xindy has not been
> recompiled, only 2) will be available. But this will be a temporary situation,
> and it will only happen in the unstable suite of Debian (it will never happen
> in the stable or testing suites, because by construction they don't allow such
> broken dependencies).

Good. That's what I wanted to hear :-), before I implement the new command-line
options.

Bruno

Bug#886986: please remove bump-fasl-loader-version.patch

[Bruno Haible]

Norbert Preining wrote:
> this is the way the build process is set up by the upstream author, and
> rewritting the whole build and distribution process *independently* from
> upstream xindy is not an option

AFAIU, the "virtual package with a hash code in its name" concept, proposed
by Sébastien, is something that is specific to Debian. No upstream package
will include such a thing in its Makefiles and "make install" targets. IMO
this is something that belongs in the Debian packaging.

Bruno

Bug#886986: please remove bump-fasl-loader-version.patch

[Bruno Haible]

Sébastien Villemot wrote:
> The right solution would be to extract the
> hash for the .mem format when compiling clisp, and then turn it into a virtual
> package (like "clisp-mem-", pretty much like we do for FASL version
> format). Then, when xindy is compiled, it would acquire the dependency on that
> virtual package, with the exact same hash.

OK, I can implement this. It would be two command-line options:
  clisp [-K linkingset] --mem-hash  Prints the expected hash of mem 
files
  clisp [-K linkingset] --mem-hash-of MEM-FILE  Prints the hash of the 
particular mem file

> Bruno, you said in you first message that clisp "does not currently provide a
> hash code". Does that mean that the information is somewhere but not exposed 
> in
> a friendly way?

I meant that these command-line options are not yet implemented.

However, we need to think through the whole user experience.

> When a new version of clisp is
> uploaded, if the .mem format changes for whatever reason, then we would know
> that xindy needs to be recompiled (because the dependency would be broken).

What if a user has installed xindy, with clisp as dependency, and then upgrades
clisp to a different version, with a different mem-hash?
  1) Will the package manager report a conflict?
  2) Will the package manager propose, as solution of this conflict, to install
 another binary package for xindy? Or will it only propose to remove xindy?

Bruno

Bug#886986: please remove bump-fasl-loader-version.patch

[Bruno Haible]

Hi Norbert,

> thanks for your email and your explanations. I am not clisp packager,
> but TeX Live (upstream and Debian) maintainer and thus also xindy
> maintainer.

I appreciate this work that you do. Nevertheless, your view of clisp .mem
file does not match reality:

1) The error "initialization file `lispinit.mem' was not created by this
   version of CLISP runtime" is UNRELATED to fas file versions.
   Here we are talking about the interface between the clisp (lisp.run)
   executable and the .mem file.

   Once you have a pair lisp.run and .mem files that matches, and you start
   using LOAD (of .fas files) and COMPILE-FILE, *then* the fas version
   becomes relevant as well. But simple applications (xindy is probably also
   in this category) don't use LOAD and COMPILE-FILE, they use just what
   is in the heap (= .mem file).

2) Mem file versioning does not work like version numbers that you can compare
   with >= or <=. It works like a number (hash code) that has to match via
   equality.

   For example, if in lisp.run the integer 5 is represented by the bit pattern
   0x1005, and in the .mem file the integer 5 is represented by the bit
   pattern 0xC014, then the two will be incompatible. This is what
   the check is about (and about the set of add-on modules and their symbols).

   See also section "Image Portability" in
   https://clisp.sourceforge.io/impnotes/image.html#image-portability

3) 
> If the fasl-loader version is not the correct information, then clisp
> should provide a way to distinguish updates that are harmless (without
> changes to the internal representation) and those that are harmfull.

   As I said in the previous mail, this is not only about updates. It is also
   about which configuration flags (--enable-portability or not) were used
   to build clisp.

4)
> > Rule:
> >   When xindy is already installed on a user's machine and a newer clisp 
> > build
> >   gets installed that has a different .mem file format, the .mem file must
> >   be regenerated.
> 
> But this is completely unfeasable.

If you don't like this rule, or it cannot be implemented in Debian, then don't
use .mem files for packages other than clisp itself.

> Think about an API bump of the libc,
> shoud *ALL* programs be recompiled *on*the*users*computers*? No, of
> course not.

Linux distros runs ldconfig each time a new shared library gets installed.
Rebuilding .mem files is a similar concept.

> So the correct solution is as far as I see:
> * clisp provides some kind of API version that get *always* bumped when
>   incompatible changes to the representation etc (as you listed above)
>   occur.
> * xindy depends on exactly one of the API version, the one it was built
>   with. As long as there are updates to clisp without API changes the
>   mem file can be loaded and all is fine.
> * if there is an API change then there will be the usual transition of
>   APIs, that is all depending programs need to be rebuilt and
>   re-uploaded. That is complete standard in Debian
>   (see https://release.debian.org/transitions/ for current ones)

> it would be the easiest and most clean,
> and most common in general development practice, to have some kind of
> API version that is bumped.

This is wishful thinking. .mem files don't work like that.

> I am strongly opposing a solution that requires that the complete source
> of a package needs to be available on all users' computers

I did not say "the source". I said "the fas files".

If a package, such as xindy, did not use a .mem file, but instead xindy
was a wrapper script that first loads a bunch of fas files and then executes
some action based on the command-line arguments, you would be in the same
situation: you would have to ship the fas files of xindy on the users'
computers.

.mem files are really only an optimization of the startup time. It allows
to reduce the startup time from something like 0.1 sec ... 1.0 sec to
the range 0.001 sec ... 0.1 sec.

Bruno

Bug#876498: [bug-gettext] Bug#876498: gettext: msgunfmt: heap corruption

[Bruno Haible]

Hi Daiki,

> Running msgunfmt under valgrind might give you more hints.  Anyway, I am
> suspecting this is caused by a missing NUL termination in
> get_sysdep_string in read-mo.c, which should be fixed by the attached patch.

Yes, the valgrind run points into this direction:
#CHECKER = valgrind --tool=memcheck 
--suppressions=$(abs_srcdir)/../gnulib-lib/malloca.valgrind 
--suppressions=$(abs_srcdir)/../gnulib-lib/libunistring.valgrind 
--num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes
#CHECKER = valgrind --tool=massif --format=html --depth=10 --alloc-fn=xmalloc 
--alloc-fn=xrealloc --stacks=no

Invalid read of size 1
   at 0x4C30A20: __GI_strchr (in 
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x404DC1: read_mo_file (read-mo.c:374)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)
 Address 0x5955ee2 is 0 bytes after a block of size 2 alloc'd
   at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x44C5D4: xmalloc (xmalloc.c:65)
   by 0x4046F6: get_sysdep_string (read-mo.c:197)
   by 0x404DA6: read_mo_file (read-mo.c:372)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)

Invalid read of size 1
   at 0x4C30F74: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x404E8D: read_mo_file (read-mo.c:392)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)
 Address 0x5955ee2 is 0 bytes after a block of size 2 alloc'd
   at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x44C5D4: xmalloc (xmalloc.c:65)
   by 0x4046F6: get_sysdep_string (read-mo.c:197)
   by 0x404DA6: read_mo_file (read-mo.c:372)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)

Invalid read of size 1
   at 0x4138D9: format_parse_entrails (format-c-parse.h:199)
   by 0x413CB4: format_parse (format-c.c:68)
   by 0x413D59: format_c_parse (format-c.c:84)
   by 0x404F73: read_mo_file (read-mo.c:414)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)
 Address 0x5955ee2 is 0 bytes after a block of size 2 alloc'd
   at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x44C5D4: xmalloc (xmalloc.c:65)
   by 0x4046F6: get_sysdep_string (read-mo.c:197)
   by 0x404DA6: read_mo_file (read-mo.c:372)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)

Invalid read of size 1
   at 0x4C30F74: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x404FA1: read_mo_file (read-mo.c:411)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)
 Address 0x5955ee2 is 0 bytes after a block of size 2 alloc'd
   at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x44C5D4: xmalloc (xmalloc.c:65)
   by 0x4046F6: get_sysdep_string (read-mo.c:197)
   by 0x404DA6: read_mo_file (read-mo.c:372)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)

Invalid read of size 1
   at 0x4138D9: format_parse_entrails (format-c-parse.h:199)
   by 0x413CB4: format_parse (format-c.c:68)
   by 0x413D59: format_c_parse (format-c.c:84)
   by 0x405044: read_mo_file (read-mo.c:432)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)
 Address 0x5956760 is 0 bytes after a block of size 2,096 alloc'd
   at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x44C5D4: xmalloc (xmalloc.c:65)
   by 0x4046F6: get_sysdep_string (read-mo.c:197)
   by 0x404E70: read_mo_file (read-mo.c:388)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)

Invalid read of size 1
   at 0x4C30F74: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x405072: read_mo_file (read-mo.c:429)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)
 Address 0x5956760 is 0 bytes after a block of size 2,096 alloc'd
   at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x44C5D4: xmalloc (xmalloc.c:65)
   by 0x4046F6: get_sysdep_string (read-mo.c:197)
   by 0x404E70: read_mo_file (read-mo.c:388)
   by 0x404076: read_one_file (msgunfmt.c:555)
   by 0x403AF8: main (msgunfmt.c:401)

However, I don't agree with the patch. The detailed description of the .mo file
format in gmo.h says:

/* Descriptor for system dependent string.  */
struct sysdep_string
{
  /* Offset of static string segments in file.  */
  nls_uint32 offset;
  /* Alternating sequence of static and system dependent segments.
 The last segment is a static segment, including the trailing NUL.  
<== */
  struct segment_pair segments[1];
};

So, the last static segment of a system dependent string must end in a NUL
byte. If this NUL byte is present, you don't need to allocate an additional
NUL after it. And if the NUL byte is no

Bug#853649: gnulib intprops.h build error with gcc 7

[Bruno Haible]

Adrian Bunk wrote:
> For reproducing and my tiny testcase I was using
>   gcc (Debian 7.1.0-13) 7.1.0
> from Debian unstable - that is GCC 7.2 release candidate 2
> with minimal Debian patching.

OK thanks.

Now about your test case: It is not valid C to try to compile just an
expression.

   a + b

is not a valid C compilation unit either. Can you submit a small test case
that
1) makes use of the intprops.h file from gnulib as a whole,
2) compiles with gcc 6 or earlier?

Bruno

Bug#853649: gnulib intprops.h build error with gcc 7

[Bruno Haible]

Hi Adrian,

Could you please give the complete output of "gcc --version"?

Given that [1] references an URL that contains the string
'gcc7-20170126' whereas gcc 7 was released on 2017-05-02 [2],
it could be that the report is about a gcc prerelease that
came 3 months before the gcc 7 release.

Bruno

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853649
[2] https://gcc.gnu.org/

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

[Bruno Haible]

Santiago Vila wrote:
> But so far, the non-reproducible Debian packages using gettext I've
> seen fail to be reproducible because maintainers insist on
> regenerating a .pot file at build time and performing msgmerge on all
> the .po files with the newly generated .pot file "just in case", or
> doing similar things.

Have you included the support for reproducible builds [1] in the
Debian package of gettext?

If not, that's what you need to do. Debian and the GNU project are in
favour of reproducible builds, but no gettext release is planned for the next
few months. So please help out by pulling this patch.

"Regenerating a .pot file at build time" and "performing msgmerge on all
the .po files with the newly generated .pot file just in case" are not
a problem. They take a couple of CPU cycles, but they do not introduce
non-reproducibility - assuming you use patch [1].

If yes, then please show me a package that still is non-reproducible because
of gettext.

> IMHO, that's clearly a task that would be better done before build time
> (i.e. taken out from the build process), much like upstream authors call
> autoconf before creating the final tarball when making a release.

Different package maintainers do it differently, and there are good arguments
for doing it either way. There are plans to improve this situation [2].

Bruno

[1] 
http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=d13f165b83701dffc14f7151419e0c00c00c0d1b
[2] https://savannah.gnu.org/bugs/?50910

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

[Bruno Haible]

Daniel Shahaf wrote:
> > it's plain text, and it's a small diff.
> 
> This doesn't scale.  (For example, in my use-case, I'm dealing with a
> 5000-line unified diff full of one-line changes in date strings and C
> comments and any number of other things. My goal is to get the number of
> lines down to zero.)

Then you will have to filter out the one-line changes that are not
important to you.

The purpose of tarballs is distribution to developers, translators,
and distros.

The purpose of Makefile.in.in rules that generate .pot files is:
The .pot files are the starting point for translators (or for the
Translation Project, which extracts the .pot files and makes them
easily accessible to the translators).
The date of the POT file is important info for the translators.

This is the main workflow. It allows for reproducible builds (through
the timestamp filtering now built into msgfmt).

> So: should po file generation allow the caller to control the timestamp
> that would be embedded?

No, that would be a regression for the translators.

> I am asserting that there is another workflow which would be simpler if
> .po file headers were also reproducible.

You'll have to adapt. Accept the main workflow as it is.

Bruno

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

[Bruno Haible]

Hello,

Daniel Shahaf wrote:
> Putting the fix into msgfmt is an option when the .mo file needs to be
> reproducible

Yes, .mo files are binary files, installed on the end users' systems. Therefore
we've made .mo files reproducible [1].

> but I'm facing an issue where I'd like the .pot file
> generated by xgettext to be reproducible as well.
> 
> I'm looking at a build process that generates a tar.gz from an svn tag.
> The build process generates a .pot file from the tag and adds it to the
> tar.gz.  The .pot file embeds the current time, which makes the tar.gz
> unreproducible.  ...
> One way to make the tar.gz reproducible would be ...

There is no point in making a source tarball (.tar.gz) reproducible.
Read the first two paragraphs of [2].
  1) A .pot file does not get installed on the end users' systems.
  2) A .pot file is plain text, and the diffs between one version and another
 version are of reasonable size.

For example, the recursive diff between libidn2-0.15 and libidn2-0.16 contains
this hunk:

diff -r -u libidn2-0.15/po/libidn2.pot libidn2-0.16/po/libidn2.pot
--- libidn2-0.15/po/libidn2.pot 2017-01-14 16:09:47.0 +0100
+++ libidn2-0.16/po/libidn2.pot 2017-01-16 09:13:10.0 +0100
@@ -6,9 +6,9 @@
 #, fuzzy
 msgid ""
 msgstr ""
-"Project-Id-Version: libidn2 0.15\n"
+"Project-Id-Version: libidn2 0.16\n"
 "Report-Msgid-Bugs-To: bug-libi...@gnu.org\n"
-"POT-Creation-Date: 2017-01-14 16:09+0100\n"
+"POT-Creation-Date: 2017-01-16 09:13+0100\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"

But SO WHAT? It does not get installed on the end user's system. it's plain
text, and it's a small diff.

Bruno

[1] 
http://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=d13f165b83701dffc14f7151419e0c00c00c0d1b
[2] https://reproducible-builds.org/

Bug#859869: unhelpful completion of file name that contains equals sign and space

[Bruno Haible]

Package: bash-completion
Version: 1:2.1-4.2ubuntu1.1

Hi,

Using bash 4.3.46 (Ubuntu package version 4.3-14ubuntu1.1) and bash-completion
(Ubuntu package version 1:2.1-4.2ubuntu1.1).

In the current directory I have just one file:

$ ls -1
vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=48200-Hits of the 90's.ts

When I type

  mv vlc

it completes to

  mv vlc-record-2017-03-28-02h03m23s-dvb-t___frequency\=48200-Hits\ of\ 
the\ 90\'s.ts 

which is OK. But when I type

  mv vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=482

it completes to

  mv 
vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=vlc-record-2017-03-28-02h03m23s-dvb-t___frequency\=48200-Hits\
 of\ the\ 90\'s.ts 

which no longer matches the file name. Likewise with 'vlc' instead of 'mv'.

Somehow the bash completion inserts the up to the equals sign, which makes
no sense for the programs 'mv' and 'vlc'.

The workaround is to type an extra double-quote [1]:

  mv "vlc-record-2017-03-28-02h03m23s-dvb-t___frequency=482

but *this should not be necessary*.

Bruno

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742126

Bug#858752: w_scan does not find the German DVB-T2 HD channels

[Bruno Haible]

Package: w-scan
Version: 20141122-1

On an Ubuntu 2016.04 LTS system, with a TechnoTrend CT2-4400 TV tuner stick,
I compare the results of different versions of w-scan (in Frankfurt am Main,
Germany, using the command "w_scan -c DE"):

1) Version 20141122-1, included in Ubuntu,
2) Version 20161022-1, downloaded from https://packages.debian.org/sid/w-scan
3) Upstream version 20170107, downloaded from
   http://wirbel.htpc-forum.de/w_scan/index2.html and compiled myself.

Result:
1) finds 41 channels
2) finds 21 channels
3) finds 47 channels

In particular, the most interesting HD (High Definition) channels are only found
by version 3).

Please upgrade to the newer version soon!

w_scan -c DE 
w_scan version 20141122 (compiled for DVB API 5.10)
using settings for GERMANY
DVB aerial
DVB-T Europe
scan type TERRESTRIAL, channellist 4
output format vdr-2.0
output charset 'UTF-8', use -C  to override
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> TERRESTRIAL "Silicon Labs Si2168": very 
good :-))

Using TERRESTRIAL frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_ 
Using DVB API 5.10
frontend 'Silicon Labs Si2168' supports
DVB-T2
INVERSION_AUTO
QAM_AUTO
TRANSMISSION_MODE_AUTO
GUARD_INTERVAL_AUTO
HIERARCHY_AUTO
FEC_AUTO
FREQ (55.00MHz ... 862.00MHz)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ 
Scanning DVB-T...
Scanning 7MHz frequencies...
177500: (time: 00:00.016) 
184500: (time: 00:02.048) 
191500: (time: 00:04.084) 
198500: (time: 00:06.120) 
205500: (time: 00:08.140) 
212500: (time: 00:10.172) 
219500: (time: 00:12.196) 
226500: (time: 00:14.228) 
Scanning 8MHz frequencies...
474000: (time: 00:16.252) 
482000: (time: 00:18.284) signal ok:QAM_AUTO f = 482000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:514)
QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 (0:0:514) : updating 
network_id -> (0:12290:514)
QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 (0:12290:514) : 
updating original_network_id -> (8468:12290:514)
updating transponder:
   (QAM_AUTO f = 482000 kHz I999B8C999D999T999G999Y999 
(8468:12290:514)) 0x
to (QAM_16   f = 482000 kHz I999B8C23D0T8G4Y0 (8468:12290:514)) 0x405A
49: (time: 00:26.368) 
498000: (time: 00:28.396) 
506000: (time: 00:30.424) 
514000: (time: 00:32.452) 
522000: (time: 00:34.484) 
53: (time: 00:36.512) 
538000: (time: 00:38.528) 
546000: (time: 00:40.564) 
554000: (time: 00:42.588) 
562000: (time: 00:44.616) 
57: (time: 00:46.636) 
578000: (time: 00:48.660) signal ok:QAM_AUTO f = 578000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:8706)
QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 (0:0:8706) : 
updating network_id -> (0:12322:8706)
QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 (0:12322:8706) : 
updating original_network_id -> (8468:12322:8706)
updating transponder:
   (QAM_AUTO f = 578000 kHz I999B8C999D999T999G999Y999 
(8468:12322:8706)) 0x
to (QAM_16   f = 578000 kHz I999B8C23D0T8G4Y0 (8468:12322:8706)) 0x405A
586000: (time: 00:55.056) 
594000: (time: 00:59.596) 
602000: (time: 01:04.076) signal ok:QAM_AUTO f = 602000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:38912)
QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:0:38912) : 
updating network_id -> (0:12440:38912)
QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 (0:12440:38912) : 
updating original_network_id -> (8468:12440:38912)
updating transponder:
   (QAM_AUTO f = 602000 kHz I999B8C999D999T999G999Y999 
(8468:12440:38912)) 0x
to (QAM_16   f = 602000 kHz I999B8C23D0T8G4Y0 (8468:12440:38912)) 0x405A
61: (time: 01:10.716) 
618000: (time: 01:12.752) signal ok:QAM_AUTO f = 618000 kHz 
I999B8C999D999T999G999Y999 (0:0:0)
QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 (0:0:0) : updating 
transport_stream_id: -> (0:0:17920)
QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 (0:0:17920) : 
updating network_id -> (0:12358:17920)
QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 (0:12358:17920) : 
updating original_network_id -> (8468:12358:17920)
updating transponder:
   (QAM_AUTO f = 618000 kHz I999B8C999D999T999G999Y999 
(8468:12358:17920)) 0x
to (QAM_16   f = 618000 kHz I999B8C23D0T8G4Y0 (8468:12358:17920)) 0x405A
626000: (time: 01:17.648) 
634000: (time: 01:19.676) 
642000: (time: 01:21.692) 
65: (time: 01:23.728) 
658000: (time: 01:25.764) 
666000: (time: 01:27.800) 
674000: (time: 01:29.820) 
682000: (time: 01:34.360) 
69: (time: 01:36.392) 
698000: (time: 01:38.424) 

Bug#457930: [bug #22095] Possibly wrong code on hppa/ia64

[Bruno Haible]

Update of bug #22095 (project libffcall):

  Status:None => Not a Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thank you for the notice.

It may be true that on HPPA, there exists two kinds of function pointers:
pointers to code, marked with a bit 1 set, and pointer to a two-word
structure, marked with bit 1 clear.

But the alloc_trampoline_r function allocates one of the first kind; therefore
it is sufficient to test for a function pointer of the first kind in
is_trampoline_r.

If a bug in this area would show up, the unit test would show it. "make check"
would fail.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#451356: [bug #22436] callback/minitests fails on x86_64

[Bruno Haible]

Update of bug #22436 (project libffcall):

  Status:None => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

This is a duplicate of bug #32466.
It is fixed now.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

Bug#792687: [Reproducible-builds] Bug#792687: gettext: please support timestamps from environment

[Bruno Haible]

A bug has been opened in the Gettext bug tracker about this issue:
https://savannah.gnu.org/bugs/?49654

In my opinion (as former Gettext maintainer) the fix ought to go into
msgfmt, not xgettext.

The gettext.diff.txt patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792687
is therefore the wrong approach, IMO.

Bruno

Bug#671257: gettext: msgfmt output format prevents multiarch migration (fwd)

[Bruno Haible]

Santiago Vila wrote:
> I remember well the bug by Neil Williams:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209
> 
> where he asked --endianness to be documented, as he was thinking about
> using it in his embedded projects to override the current msgfmt default of
> always creating little endian .mo files.

Let me repeat: The default is that msgfmt creates .mo files in the endianness
of the platform where 'msgfmt' runs. (Otherwise, Paul Martin would not
have found a multi-arch problem.)

Neil Williams's motivation were cross-compiling situations (from x86 to
mips systems, for example). He wanted to make 'msgfmt' aware of the
target system's endianness. This has a negligible impact and is not a
good enough rationale for adding one more option to the manual.

But I find Paul Martin's rationale convincing. So I'm adding the
documentation.

Now, how to use this in the Debian build system, is your turn.

> The opinion of people in charge of multiarch is that in the long run,
> it would be much better if msgfmt's default changed in gettext to be
> little endian again.

I don't agree. Users of PowePC systems have the same right to optimized
MO files as users of x86 systems. Therefore I would like to have the
issue solved in Debian's build system. Let me know if you would need
additional targets or variables in Makefile.in.in (on top of the configure
option that I already mentioned).

Bruno




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671044: install-reloc is invoked with too many arguments

[Bruno Haible]

Hi Sylvain,

> I received the bug report below when compiling GNU FreeDink on
> Debian/kFreeBSD and Debian/Hurd.
> 
> It seems that there's an issue with install-reloc:
> https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=kfreebsd-amd64&ver=1.08.20120427-1&stamp=1335561117
> https://buildd.debian.org/status/fetch.php?pkg=freedink&arch=hurd-i386&ver=1.08.20120427-1&stamp=133752
> 
>   RELOC_LIBRARY_PATH_VAR=LD_LIBRARY_PATH RELOC_LIBRARY_PATH_VALUE= 
> RELOC_PREFIX=/usr 
> RELOC_DESTDIR=/build/buildd-freedink_1.08.20120427-1-kfreebsd-amd64-I0HlF8/freedink-1.08.20120427/debian/freedink-engine
>  RELOC_COMPILE_COMMAND=gcc -g -O2 -Wall -std=c99 -I/usr/include/SDL 
> -D_GNU_SOURCE=1 -D_REENTRANT  RELOC_SRCDIR=../gnulib/lib 
> RELOC_BUILDDIR=../gnulib/lib RELOC_CONFIG_H_DIR=.. RELOC_EXEEXT= 
> RELOC_STRIP_PROG=: RELOC_INSTALL_PROG=/usr/bin/install -c 
> ../autotools/install-reloc freedink freedinkedit 
> '/build/buildd-freedink_1.08.20120427-1-kfreebsd-amd64-I0HlF8/freedink-1.08.20120427/debian/freedink-engine/usr/games'
>   Usage: ../autotools/install-reloc library_path_var library_path_value 
> prefix destdir compile_command srcdir builddir config_h_dir exeext 
> strip_command install_command... destprog
> 
> AFAICS 'install-reloc', when run with environment variables, expects
> exactly:
> - 1 executable
> - 1 destprog dir
> 
> In this case, the relocatable-prog macros invokes install-reloc with:
> - 2 executables (freedink, freedinkedit)
> - 1 destprog dir

Indeed, when invoked with RELOC_* environment variables, 'install-reloc'
was meant to install one program only. This was how it was meant to be
invoked from Automake. But this changed in Automake on 2008-09-07, see
http://git.savannah.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=4295fe33eb23fb9440ee6a7404ec064067266372

Can you please try this modified 'install-reloc' program instead?
Save it and do a "chmod +x install-reloc" before you can use it.
Does it help on hurd-i386 (or on kFreeBSD as well, without the other patch)?

Bruno



install-reloc
Description: application/shellscript

Bug#671044: freedink: FTBFS[!linux]: too many args to install-reloc

[Bruno Haible]

Steven Chamberlain wrote:
> > It seems that there's an issue with install-reloc:
> 
> Yes there is, but what is its purpose anyway?

install-reloc is used when --enable-relocatable is used. The purpose of
this option is to give the installer the ability to install binaries at
any location in the file system, and move them around when needed. Or
to give a distributor of a package (e.g. videolan.org) the ability to
distribute binaries that users can unpack and run, without having root
permissions.

I think Debian answers this use-case for 'sudoable' users through the
concept of third-party package repositories. But for users with no
extra permissions and who want to download binaries from trusted sources,
--enable-relocatable is the only choice AFAIK.

> For Linux builds it is
> not used so maybe it shouldn't be used either on kFreeBSD or Hurd?

Linux is not the same as kFreeBSD or Hurd.

> With the attached patch it builds just fine on kfreebsd-i386 and I think
> the change would also help fix this on hurd-*.

The $ORIGIN support depends on a file 'dl-origin.c' in the glibc source
tree. But such a file exists only for Linux and kFreeBSD:

$ cd glibc
$ find . -name dl-origin.c
./elf/dl-origin.c
./sysdeps/unix/sysv/linux/dl-origin.c

For kFreeBSD you find it in
<http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/kfreebsd/local-sysdeps.diff?revision=5197&view=markup>
and it should normally work, says
<http://lists.debian.org/debian-bsd/2011/08/msg00161.html>.

For the Hurd, a patch has been proposed:
  <http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00052.html>
but it has apparently not been integrated into glibc so far.

I'm applying this patch. Please let me know if this fixes the Freedink
builds on GNU/kFreeBSD or not.


2012-05-01  Bruno Haible  

relocatable-prog: Enable ELF ORIGIN trick also on GNU/kFreeBSD.
* m4/relocatable.m4 (gl_RELOCATABLE_BODY): Treat kFreeBSD like Linux.
* build-aux/reloc-ldflags: Likewise.
Suggested by Steven Chamberlain .

--- build-aux/reloc-ldflags.origWed May  2 02:43:45 2012
+++ build-aux/reloc-ldflags Wed May  2 02:41:45 2012
@@ -54,7 +54,7 @@
 esac
 
 case "$host_os" in
-  linux*) # Supported since Linux 2.1 and glibc 2.1.
+  linux* | kfreebsd*)
 rpath=
 save_IFS="$IFS"; IFS=":"
 for dir in $library_path_value; do
--- m4/relocatable.m4.orig  Wed May  2 02:43:45 2012
+++ m4/relocatable.m4   Wed May  2 02:42:57 2012
@@ -1,4 +1,4 @@
-# relocatable.m4 serial 17
+# relocatable.m4 serial 18
 dnl Copyright (C) 2003, 2005-2007, 2009-2012 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -41,7 +41,7 @@
 AC_CHECK_FUNCS([_NSGetExecutablePath])
 case "$host_os" in
   mingw*) is_noop=yes ;;
-  linux*) use_elf_origin_trick=yes ;;
+  linux* | kfreebsd*) use_elf_origin_trick=yes ;;
 esac
 if test $is_noop = yes; then
   RELOCATABLE_LDFLAGS=:




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#641371: xgettext -k_ hello.scm fails if block-comment are used inside a function (fwd)

[Bruno Haible]

Hello,

David Pirotte wrote:
> I found that
> xgettext will properly work until it reaches a block-comment inside a
> scheme function [as opposed to a toplevel block-comment which xgettext
> appears to propely manage.
> 
> On the modified hello.scm below, if you run:
> 
>xgettext -k_ -o hello.pot hello.scm
> 
> and cat hello.pot, you'll see that xgettext 'stopped' working properly
> after extracting "let's see: xgettext 1". In case you could not
> reproduce exactly, I'll also attach the hello.pot I got here.
> 
> ;; hello.scm [modified] starts here
> #!@GUILE@ -s
> !#
> ;;; Example for use of GNU gettext.
> ;;; This file is in the public domain.
> 
> ;;; Source code of the GNU guile program.
> 
> (use-modules (ice-9 format))
> 
> (catch #t (lambda () (setlocale LC_ALL "")) (lambda args #f))
> (textdomain "hello-guile")
> (bindtextdomain "hello-guile" "@localedir@")
> (define _ gettext)
> 
> (display (_ "Hello, world!"))
> (newline)
> (format #t (_ "This program is running as process number ~D.") (getpid))
> (newline)
> 
> #!
> this toplevel block-comment does seem to confuse ngettext
> (_ "this first string should not be extracted")
> !#
> 
> (define (further-testing-xgettext)
>   (_ "let's see: xgettext 1")
>   #!
>   then for some reason, i'v noticed that xgettext gets confused if
>   block-comment is used inside a function, unlike @ toplevel
>   (_ "this second string should not be extracted")
>   !#
>   (_ "let's see: xgettext 2"))
> 
> (display (_ "let's see: xgettext 3"))
> ;; hello.scm [modified] ends here

Thank you. It is perfectly reproducible.

The point is that you are using a syntax which is valid in guile-2.0
but not in guile-1.6.4 or guile-1.7.1. In these older versions, the
!#
had to come on a line of its own, without spaces.

I'm applying this patch to teach xgettext the newer (relaxed)
syntax for the end of block comments.


2011-10-04  Bruno Haible  

xgettext for Scheme: Understand guile 2.0 comment syntax, part 1.
* x-scheme.c (read_object): Understand !# as a block comment terminator
even when not surrounded by newlines.
Reported by David Pirotte 
via Santiago Vila .

--- gettext-tools/src/x-scheme.c.orig   Tue Oct  4 22:58:49 2011
+++ gettext-tools/src/x-scheme.cTue Oct  4 22:20:11 2011
@@ -1,5 +1,5 @@
 /* xgettext Scheme backend.
-   Copyright (C) 2004-2009 Free Software Foundation, Inc.
+   Copyright (C) 2004-2009, 2011 Free Software Foundation, Inc.
 
This file was written by Bruno Haible , 2004-2005.
 
@@ -40,7 +40,7 @@
 
 
 /* The Scheme syntax is described in R5RS.  It is implemented in
-   guile-1.6.4/libguile/read.c.
+   guile-2.0.0/libguile/read.c.
Since we are interested only in strings and in forms similar to
 (gettext msgid ...)
or   (ngettext msgid msgid_plural ...)
@@ -60,7 +60,7 @@
- The syntax code assigned to each character, and how tokens are built
  up from characters (single escape, multiple escape etc.).
 
-   - Comment syntax: ';' and '#! ... \n!#\n'.
+   - Comment syntax: ';' and '#! ... !#'.
 
- String syntax: "..." with single escapes.
 
@@ -935,12 +935,10 @@
 }
 
   case '!':
-/* Block comment '#! ... \n!#\n'.  We don't extract it
+/* Block comment '#! ... !#'.  We don't extract it
because it's only used to introduce scripts on Unix.  */
 {
-  int last1 = 0;
-  int last2 = 0;
-  int last3 = 0;
+  int last = 0;
 
   for (;;)
 {
@@ -948,12 +946,9 @@
   if (c == EOF)
 /* EOF is not allowed here.  But be tolerant.  */
 break;
-  if (last3 == '\n' && last2 == '!' && last1 == '#'
-  && c == '\n')
+  if (last == '!' && c == '#')
 break;
-  last3 = last2;
-  last2 = last1;
-  last1 = c;
+  last = c;
 }
   continue;
 }



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#548493: test-yesno.sh failure

[Bruno Haible]

Jim Meyering wrote:
>  # Test with seekable stdin; the followon process must see remaining data.
> -cat < ${p}in.tmp
> +cat < ${p}in.tmp

This can be simplified to:

  tr @ '\177' < ${p}in.tmp

Bruno



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#538150: gettext: autopoint does not see additional po/ directories (fwd)

[Bruno Haible]

Guillem Jover wrote:
> > autopoint does it automatically. It infers the list of po/ dirs.
> > Just try it.
> 
> I've done that in the past, and before filing the bug, I've prepared now
> a small test case

Thanks for the test case. I was wrong again, and your testcase helped me
clear up all the confusion.

> Attached the test case (similar to the current dpkg setup). After
> unpacking the tarball and then running “autoreconf -f -i” (autopoint
> should be called by autoreconf itself), there's at least ‘Makfile.in.in’
> and ‘remove-potcdate.sin’ missing from «a/po/» and «b/po», which are
> the minimum files to be able to build it.

I reproduce, thank you very much. Find attached the fix (which will be
contained in the next gettext release).

Bruno

*** gettext-tools/misc/ChangeLog.orig	2009-08-09 16:07:14.0 +0200
--- gettext-tools/misc/ChangeLog	2009-08-09 16:05:06.0 +0200
*******
*** 1,3 
--- 1,13 
+ 2009-08-09  Bruno Haible  
+ 
+ 	Add support for multiple PO directories to autopoint.
+ 	* autopoint.in (sed_extract_config_files, configfiles,
+ 	sed_remove_Makefile_in, podirs): New variables.
+ 	(func_destfile): Set allpodirs.
+ 	When allpodirs is set, loop over $podirs.
+ 	Reported by Guillem Jover 
+ 	via Santiago Vila .
+ 
  2008-12-07  Bruno Haible  
  
  	* autopoint.in (func_version): Bump copyright year.
*** gettext-tools/misc/autopoint.in.orig	2009-08-09 16:07:14.0 +0200
--- gettext-tools/misc/autopoint.in	2009-08-09 15:58:03.0 +0200
***
*** 1,6 
  #! /bin/sh
  #
! # Copyright (C) 2002-2008 Free Software Foundation, Inc.
  #
  # This program is free software: you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
--- 1,6 
  #! /bin/sh
  #
! # Copyright (C) 2002-2009 Free Software Foundation, Inc.
  #
  # This program is free software: you can redistribute it and/or modify
  # it under the terms of the GNU General Public License as published by
***
*** 375,380 
--- 375,408 
  omitintl=`cat "$configure_in" | grep '^AM_GNU_GETTEXT' | sed -n -e 's/^AM_GNU_GETTEXT(\([^(),]*\).*$/\1/p' | sed -e 's/^\[\(.*\)\]$/\1/' | sed -e 1q`
  omitintl=`if test 'external' = "$omitintl"; then echo yes; fi`
  
+ # Check in which directory or directories the po/* infrastructure belongs.
+ sed_extract_config_files='s,#.*$,,
+ s,^dnl .*$,,
+ s, dnl .*$,,
+ /AC_CONFIG_FILES(/ {
+   ta
+   :a
+ s/)/)/
+ tb
+ s/\\$//
+ N
+ ba
+   :b
+   s,^.*AC_CONFIG_FILES([[ ]*\([^]"$`\\)]*\).*$,\1,p
+ }'
+ configfiles=`cat "$configure_in" | sed -n -e "$sed_extract_config_files"`
+ # PO directories have a Makefile.in generated from Makefile.in.in.
+ # Treat a directory as a PO directory if and only if it has a
+ # POTFILES.in file. This allows packages to have multiple PO
+ # directories under different names or in different locations.
+ sed_remove_Makefile_in='s,/Makefile\.in$,,'
+ podirs=`for f in $configfiles; do case "$f" in */Makefile.in) echo $f;; esac; done | sed -e "$sed_remove_Makefile_in"`
+ if test -z "$podirs"; then
+   # If we cannot get the list of PO directories from configure.ac, assume the
+   # common default.
+   podirs="po"
+ fi
+ 
  # Set up a temporary CVS repository and a temporary checkout directory.
  # We need the temporary CVS repository because any checkout needs write
  # access to the CVSROOT/history file, so it cannot be under $gettext_dir.
***
*** 448,453 
--- 476,482 
  #   empty if the file shall be omitted
  # - sharedowner yes if the file is not only owned by GNU gettext but may
  #   be installed by automake or other tools, otherwise empty
+ # - allpodirs   yes if the file is to be installed in every dir in $podirs
  func_destfile ()
  {
# There are five categories of files:
***
*** 455,462 
# config.rpath mkinstalldirs -> $auxdir
# m4/* -> $m4dir/
# intl/* -> intl/
!   # po/* -> po/
sharedowner=
case `echo "$1" | sed -e 's,[^/]*$,,'` in
  "" )
case "$1" in
--- 484,492 
# config.rpath mkinstalldirs -> $auxdir
# m4/* -> $m4dir/
# intl/* -> intl/
!   # po/* -> 
sharedowner=
+   allpodirs=
case `echo "$1" | sed -e 's,[^/]*$,,'` in
  "" )
case "$1" in
***
*** 467,472 
--- 497,503 
;;
  m4/ ) destfile=`echo "$1" | sed -e "s,^m4/,$m4dir/,"` ;;
  intl/ ) if test -n "$omitintl"; then destfile=""; else destfile="$1"; fi ;;
+ po/ ) destfile=`echo "$1" | sed -e "s,^po/,,"` allpodirs=yes ;;
  * 

Bug#538150: gettext: autopoint does not see additional po/ directories (fwd)

[Bruno Haible]

Guillem Jover wrote:
> > > getttextize used to support more than one podir
> > 
> > No, gettextize always only supported one podir.
> I can see gettextize's --po-dir option which can be
> specified several times

Oops, you are right. I was wrong. Since version 0.17, gettextize *does*
support multiple --po-dir options.

> But cannot find any option in the info docs, nor
> anything in autopoint's code which would seem to support several po/
> dirs. So I'm a bit confused now

autopoint does it automatically. It infers the list of po/ dirs.
Just try it.

> Or better yet, add it to the docs?

What should I add to the docs, if a feature is automatic?

If you want to reopen this bug report, please provide a test case
(configure.ac, Makefile.am etc. with several po/ directories) and
a sequence of commands, including an autopoint invocation, that
supports your claim.

Bruno



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#521737: Segfault in memchr when called via strstr

[Bruno Haible]

The Austin group has clarified in
  
the specification of memchr:

  "Implementations shall behave as if they read the memory byte by byte
   from the beginning of the bytes pointed to by s and stop at the first
   occurrence of c."

So passing a too large size to memchr() is ok. The bug in is memchr().

Bruno



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#480774: diff -y in UTF-8: bad alignment

[Bruno Haible]

Vincent Lefevre reported in
  :
> When "diff -y" in run on files that contain multibyte characters (in
> UTF-8), the alignment is incorrect in the output.

This is fixed upstream, in the CVS version of diffutils at
  https://savannah.gnu.org/cvs/?group=diffutils

It is not fixed in version 2.8.7 on alpha.gnu.org.

FYI, OpenSUSE 11 ships with the newest diffutils from the CVS.

Thanks for the report.

Bruno



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#491978: gettext: error in Plural-Forms documentation - an old version of docs perhaps?

[Bruno Haible]

> The plural forms listed
> for Slovak and Czech are
>
>   Plural-Forms: nplurals=3; \
>   plural=n==1 ? 0 : \
>  n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;
>
> while the correct form is:
>
>   Plural-Forms: nplurals=3; \
>   plural=((n==1) ? 0 : \
>  (n>=2 && n<=4) ? 1 : 2);\n

You are right. It's already corrected in gettext 0.17 and on the web:
  http://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html

The gettext-tools/doc/ChangeLog has these entries:

2004-08-30  Bruno Haible  <[EMAIL PROTECTED]>

* gettext.texi (Plural forms): Czech is now like Slovak.
Reported by Stepan Kasal <[EMAIL PROTECTED]>.

2003-05-27  Bruno Haible  <[EMAIL PROTECTED]>

* gettext.texi (Plural forms): Correct formula for Slovak.
Reported by Marcel Telka <[EMAIL PROTECTED]>.

Bruno




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

Bug#468209: msgfmt: no documentation of the --endianness option

[Bruno Haible]

Hi,

While reading
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468209
I have to agree with most of what Santiago said.

Neil Williams said:
> On big endian systems, the CPU wastes time converting the endianness at
> loadtime which is important for embedded devices.

Do you have any figures? In my opinion, the non-native endianness costs a
few CPU cycles at every non-cached gettext() invocation, but nothing at load
time. The thing that costs at load time is when the locale encoding and the
PO file encoding don't match: e.g. if the PO file was in ISO-8859-2 and the
.mo file is used in an UTF-8 locale.

> Please document this in the manpage and ask upstream if it can also be
> output in the --help output.
> ...
> No, I don't see that this needs to be forwarded upstream, this is an
> issue within Debian - primarily within the manpage as far as this bug
> report is concerned.

It would be wrong to document some option in Debian that is not documented
upstream. The upstream maintainer can at any moment withdraw this option,
change its syntax, make it dump core etc., without notice (no word about it
in the NEWS file).

Bruno




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

Bug#474901: build failure when gcj is present

[Bruno Haible]

Ralf Wildenhues wrote:
> Have you tried './configure GCJ=none'?
> 
> BTW, it would be nice if gt_GCJ used or accepted 'no' instead of 'none'
> as special value.  The former is recognized e.g. in Libtool GCJ macros,

Both uses that you mention are undocumented. If someone wants to disable
the use of GCJ (other than through documented configure options), he should
use a program that does not exist or always fail. 'GCJ=false' for example.

Bruno




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

Bug#474901: build failure when gcj is present

[Bruno Haible]

Santiago Vila wrote:
> Maybe --disable-native-java is what I need?

Yes. You hit the nail on the head.

Bruno




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

Bug#482364: gettext-el: patch for po-mode to save buffer when PO-Revision-Date is hold

[Bruno Haible]

Kobayashi Noritada wrote on 2008-05-22:
> po-mode provides po-auto-replace-revision-date, an option for users to
> decide whether PO-Revision-Date field in the header should be
> automatically updated or not.  However, when users choose holding that
> field, by setting that variable to "ask" and answering "n" to "May I set
> PO-Revision-Date? (y or n) " or by setting that variable to "nil", the
> field is not updated AND THE BUFFER IS NOT SAVED.  I've confirmed that
> this issue represents in Emacs 21 and Emacs 22.
> 
> This may be a bug due to a fact[1] that Emacs considers the buffer is
> saved when a hook in write-contents-hooks returns non-nil.  So, I've
> created a patch to fix the issue.  Could you please apply it?

Thank you. Indeed this is a documented behaviour of Emacs:
  http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_383.html

I have applied your patch. Many thanks!

Bruno




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

Bug#404364: Various typos in manpages

[Bruno Haible]

Hello Michael,

> I'm not so sure of the details here, but maybe you are, since it relates to 
> iconv stuff.  Can you confirm/disconfirm the
> correctness of this part of the patch below:
> 
> > -values are listed by the \fBiconv \-\-list\fP command, and all combinations
> > +values are listed by the \fBiconv \-\-list\fP command, but not all 
> > combinations
> ?

Glad that you ask. The patch is wrong; the text is correct as written years
ago.

> > For iconv_open.3, I had a look at the libc6 source code.
> > The find_derivation function which is responsible for finding a path from
> > the /from/ encoding to the /to/ encoding does not exclude that such
> > a path does not exist, which back up the statement from `iconv --list`:
> > 
> >   The following list contain all the coded character sets known.  This does
> >   not necessarily mean that all combinations of these names can be used for
> >   the FROM and TO command line parameters.  One coded character set can be
> >   listed with several different names (aliases).

Looking at the find_derivation function is fine, but you also need to look at
the gconv-modules file. POSIX says that, *in general*, specific pairs (from, to)
can be unsupported although 'from' and 'to' are supported. Here, we are
talking about "For the GNU C library". And in the GNU C library, an encoding
called "INTERNAL" is used as a pivot encoding: For all encodings, there
is a converter from INTERNAL to the encoding and a converter in the opposite
direction. This architecture guarantees that all combinations are supported.

In fact, if someone would attempt to write an iconv module that "defines"
an encoding by registering converters from/to another encoding, say, UTF-8
or GB18030, rather than INTERNAL, some features of iconv and multibyte
processing would not work. Look at glibc's iconv/skeleton.c and you will
understand.

Bruno



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

Bug#385005: gettext-el: po-mode inserts header if buffer is narrowed (fwd)

[Bruno Haible]

Hello,

Sven Joachim wrote:
> Surely.  Open some PO file (in po-mode).  Type 'E' and confirm that
> you want to edit the whole file.  Narrow the buffer so that the PO
> header is not visible (e.g. go to the last msgid string, then press
> M-> and C-x n n).  Type M-x po-mode.  Now Emacs will insert a standard
> header at the beginning of the (narrowed) buffer.

Thank you. I can reproduce it. Your fix works fine in this case, and also
works fine in the case when a header entry has to be inserted outside the
narrowed region. I have applied it. Thanks!

Bruno



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

Bug#385005: gettext-el: po-mode inserts header if buffer is narrowed (fwd)

[Bruno Haible]

Sven Joachim wrote:
> There is a small bug in the function po-check-file-header.  If the
> buffer is narrowed, M-x po-mode can insert a header even if the buffer
> already has one in its not currently visible part.

Can you please describe more in detail how to reproduce it? Ideally in a
step-by-step procedure. I cannot reproduce it with Emacs 21.3 nor 22.1.

Bruno



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

Bug#400187: gettext: xgettext segfaults on .lisp files (fwd)

[Bruno Haible]

Martin Pitt wrote:
> That bug has already been closed and the patch applied, so that's not
> it (I just checked the package to verify this). So it must be
> something else.

But with this additional patch, it will work.

Alternatively - since your code appears to be Scheme, not Lisp, anyway -
you can use the xgettext option "-L Scheme" and profit from the 384698 bug fix.

Bruno


*** gettext-tools/src/x-lisp.c.bak  2006-04-03 13:17:56.0 +0200
--- gettext-tools/src/x-lisp.c  2006-11-28 00:57:21.0 +0100
***
*** 1087,1093 
else
  {
/* These are the argument positions.  */
!   if (inner.type == t_string)
  arglist_parser_remember (argparser, arg,
   string_of_object (&inner),
   inner_context,
--- 1087,1093 
else
  {
/* These are the argument positions.  */
!   if (argparser != NULL && inner.type == t_string)
  arglist_parser_remember (argparser, arg,
   string_of_object (&inner),
   inner_context,



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

Bug#330990: iso-codes .pot msgid strings contain non-ASCII characters

[Bruno Haible]

Paul Eggert wrote:
> the GNU gettext manual says:
>
>   Note that the MSGID argument to `gettext' is not subject to
>character set conversion.  Also, when `gettext' does not find a
>translation for MSGID, it returns MSGID unchanged - independently of
>the current output character set.  It is therefore recommended that all
>MSGIDs be US-ASCII strings.

This recommendation is directed to the "normal" use of xgettext, i.e.
extraction of the msgids from source code. The other issue - not mentioned
in the GNU gettext manual, but quite important - is that source code should
be viewable in different encodings, and when you convert some source code
from ISO-8859-1 to UTF-8 (or vice versa), the behaviour of the program
should remain the same.

The situation for iso-codes is different, because
  - It is not extracted from source code; the use of XML files for the
list of country/location names greatly reduces the possible problems
when these files would be stored in a different encoding (thanks to
the encoding declaration present in XML files).
  - There are quite a number of languages/countries/locations in the world
which cannot be written in ASCII, such as Norwegian Bokmål, Côte
d'Ivoire, etc.

Therefore I think it's actually OK for iso-codes to use UTF-8 as encoding
of the msgids.

The only remaining problem is in the C code: A program running in, say, an
EUC-JP locale, needs to be a little careful when accessing the message
catalog: not just

  country_translation = dgettext ("iso-codes", country_english_utf8);

but

  country_translation = dgettext ("iso-codes", country_english_utf8);
  if (country_translation == country_english_utf8)
{
  /* Not found in the message catalog. Use the English name, converted
 to the correct encoding.  */
  country_translation =
iconv_string (country_translation, "UTF-8", locale_charset ());
}

You find code that is a little better than this one (cares about 
transliteration,
non-canonicalized locale_charset() result etc.) in propername.c at

  
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gettext-tools/lib/propername.c?content-type=text%2Fplain&rev=1.1&root=gettext

In other words, UTF-8 is the current de-facto standard encoding. I would leave
the iso-codes PO files in that encoding, and keep the support of other encodings
purely in the C code that uses the ,mo files.

> Can the format of the XML country list be extended to contain two
> spellings, one in UTF-8, one ASCII-ized?  Then the algorithm wouldn't
> need to transcode.

The transliteration in glibc and libiconv is good enough.

Bruno

Bug#244215: gettext: /usr/bin/msginit reports java error (fwd)

[Bruno Haible]

Santiago Vila wrote:
> configure:3190: checking for Java to native code compiler
> configure:3213: found /usr/bin/gcj
> configure:3254: gcj  conftest.java --main=conftest -o conftest
> gcj: libgcj.spec: No such file or directory
>
> Ok, libgcj.spec is in libgcj4-dev, which I will have to install as well.

This looks like a bug in the Debian packaging of GCJ, that ought to be
reported. It makes no sense to install a /usr/bin/gcj program that is
not functional.

Bruno



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

Bug#244215: gettext: /usr/bin/msginit reports java error (fwd)

[Bruno Haible]

Santiago Vila wrote:
> Correction: gnu.gettext.GetURL does not seem to be created at all.
>
> I have put the build log here:
>
> http://people.debian.org/~sanvila/gettext/build.log.gz
>
> and this is the list of files installed to debian/tmp when
> I do "make install DESTDIR=`pwd`/debian/tmp":
>
> http://people.debian.org/~sanvila/gettext/manifest.gz
>
> No traces of gnu.gettext.GetURL.

Your log contains
checking for Java to native code compiler... none
This is the m4/gcj.m4 test. It is unusual that this fails when gcj is present.
You need to look in the gettext-tools/config.log in order to see why it failed.

Bruno



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

Bug#244215: gettext: /usr/bin/msginit reports java error (fwd)

[Bruno Haible]

Santiago Vila wrote:
> It seems that I forgot two important things:
>
> * Really put gnu.gettext.GetURL in the package (!).
> * Run dpkg-shlibdeps on it.

This explains everything.

> Perhaps I was reading the PACKAGING file in verbatim mode.

PACKAGING recommends to install $prefix/lib/gettext/*; this includes
$prefix/lib/gettext/gnu.gettext.GetURL.

> Would be possible to say something about gnu.gettext.GetURL somewhere in the
> PACKAGING file?

Yes, it will be.

Bruno



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

Bug#244215: #244215: gettext: /usr/bin/msginit reports java error (fwd)

[Bruno Haible]

Santiago Vila wrote:
> I plan to create the Debian gettext
> package using this call to the configure script:
>
> JAVAC=jikes-classpath ./configure --prefix=/usr --disable-csharp

Looks good, yes. (Except for the --disable-csharp: do you have problems
with pnet?)

> By "if gcj is present, gettext will install an executable which does
> not need a jar", do you mean that I should better keep gcj as a
> build-dependency even if I already have jikes-classpath?

That depends how you wish to have the runtime dependencies. If you have
gcj in the PATH during the build, the package will need /usr/lib/libgcj.so.3
at runtime. If you don't have gcj in the PATH during the build, the package
will need a JVM at runtime (e.g. gij + /usr/share/java/libgcj-3.4.3.jar).

> Will jikes-classpath be enough to generate the .jar's?

I hope so, yes.

> Will they be correct for all architectures?

Yes. jars are architecture independent.

> In case I need it, what would be the most simple way to check that the
> created .jar's are ok? [ I would like not to repeat the mistake of
> providing a .jar which does not work ].

You can check the libintl.jar by configuring and running the installed
examples/hello-java/ sample.

If a gettext.jar is generated, you can check it by looking at the testsuite
result of gettext-tools/tests/msgunfmt-java-1.

Bruno



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