Update of bug #27740 (project gettext):
Status: Fixed => None
Open/Closed: Closed => Open
___
Follow-up Comment #5:
Reopening.
pful backtrace:
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.
Regards,
--
Daiki Ueno
>From 3c66e050e344ec890f0c1e467753c2ed46bc7bb8
ttp://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=2bad4d89684303fe884410ab0ae53770df6a6093
Although it was reported against an unreleased version, can we have a
test case for this to prevent similar issue happening in the future?
Regards,
--
Daiki Ueno
>From 01d82c6ed523b0c44ad4a
n the same po directory.
Footnotes:
[1] http://lists.gnu.org/archive/html/bug-gettext/2015-06/msg6.html
Regards,
--
Daiki Ueno
POTFILES.in.
This way, you wouldn't need to wait another gettext release.
Regards,
--
Daiki Ueno
Update of bug #46111 (project gettext):
Status:None => Duplicate
Open/Closed:Open => Closed
___
Follow-up Comment #2:
Closing this as
Follow-up Comment #2, bug #50408 (project gettext):
The gettext-provided file is solely for compatibility reasons: it is there not
to break the applications that expect the previous behavior, implementation in
C.
Shouldn't we suggest to install appstream instead?
used by GNOME; you can see the list of such modules
(search with "JavaScript"):
https://git.gnome.org/browse/
Regards,
--
Daiki Ueno
Update of bug #49809 (project gettext):
Status:None => Need Info
___
Follow-up Comment #1:
Sorry, you provide too little information. I can't reproduce it with:
cat > a.sh
sed -e
atable.c (relocate): Do not touch pathname
> if it is started with '/@unixroot'.
> ---
> gettext-runtime/intl/bindtextdom.c | 6 ++
> gettext-runtime/intl/relocatable.c | 12
> 2 files changed, 18 insertions(+)
Thanks for the patch. I have pushed it.
Regards,
--
Daiki Ueno
Update of bug #49540 (project gettext):
Status:None => Fixed
Assigned to:None => haible
Open/Closed:Open => Closed
y advantages of debbugs:
>
> 1) It has a full-text search engine.
2) It can be accessed through the Emacs interface:
http://elpa.gnu.org/packages/debbugs.html
It works pretty nicely and could address some of your concerns.
I actually don't have strong opinion here. However, having seen quite a
few people being confused that we have multiple places to report bugs
(this list and the tracker) and that discussions often scatter across
those places, I am wondering if we could unify them.
Regards,
--
Daiki Ueno
libtool do. Though I haven't used it much, it apparently has a
concept of "user tags" which could be used as categories.
Regards,
--
Daiki Ueno
Update of bug #49677 (project gettext):
Status:None => Duplicate
Open/Closed:Open => Closed
___
Follow-up Comment #1:
This apparently is
Follow-up Comment #4, bug #49654 (project gettext):
I too fully agree with Bruno's suggestion. It sounds like a good idea to
strip the timestamp when producing .mo files. Bruno, are you willing to
provide a patch for this?
On the other hand, I think it could also be worked around by disabling
Update of bug #49598 (project gettext):
Status:None => Not a Bug
Assigned to:None => haible
Open/Closed:Open => Closed
Follow-up Comment #2, bug #49497 (project gettext):
> It'd be nice if `autogen.sh` would fail with a verbose error message and
give a hint that automake 1.13 needs to be installed rather than just complain
about the missing macro.
I thought it would be achieved by the AM_INIT_AUTOMAKE invocation
ettext.c#n637
I'm not sure but it looks like a typo: s/tmp_dirname/resolved_dirname/.
Do you see a compile error caused by this?
Regards,
--
Daiki Ueno
Update of bug #48684 (project gettext):
Status:None => Duplicate
Open/Closed:Open => Closed
___
Reply to this item at:
Follow-up Comment #3, bug #48481 (project gettext):
Yes, that's what I understand from your code, and I wonder if it is a
reasonable behaviour; shouldn't it signal an error or stop processing when it
sees a '@' twice?
By the way, I think there should be a reliable conversion between CLDR locale
Follow-up Comment #1, bug #48481 (project gettext):
Thank you for the patch, it makes sense.
Regarding the implementation, though I haven't tested the patch, I wonder if
it accepts bogus locales like: foo@bar@baz? Also doesn't it stop at the
second '-' if the locale looks like: it-IT.UTF-8?
I
.in.in never added support for it.
>
> Use msgmerge --previous as default on all systems with gettext >= 0.16.
>
> ---
> NEWS | 3 +++
> gettext-runtime/po/Makefile.in.in | 16 ++--
> 2 files changed, 13 insertions(+), 6 deletions(-)
Thanks, applied.
Regards,
--
Daiki Ueno
be generated
> -# by automake.
I was pondering on this part; is the above comment no longer true with
the latest automake? If so, do you know which automake version fixed
the issue?
> po-gram-gen.h: po-gram-gen.c
> +cldr-plural.h: cldr-plural.c
This part looks correct.
Regards,
--
Daiki Ueno
Follow-up Comment #1, bug #48384 (project gettext):
Which gettext version did you use for testing? The line numbers shown in the
log indicates that you are still using 0.19.7 or earlier.
___
Reply to this item at:
gettext as a compatible implementation.
Thanks,
--
Daiki Ueno
signature.asc
Description: PGP signature
. It was a
regression since 0.19.5.
- The AM_GNU_GETTEXT macro can now detect musl-libc's gettext
implementation.
Regards,
--
Daiki Ueno
Daiki Ueno <u...@gnu.org> writes:
> So, I would propose:
For what it's worth I have filed a bug at glibc bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=20184
Let's see how they think about it.
Regards,
--
Daiki Ueno
Follow-up Comment #3, bug #46844 (project gettext):
Thanks for the analysis and the patch. I have pushed it as:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=7a8f93d8de8f24a303c5aec30ceb696700a503ec
___
Reply to this item at:
Update of bug #38941 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #1:
I consider this as
Update of bug #44098 (project gettext):
Status: In Progress => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #10:
This was added in
Update of sr #10 (project gettext):
Status:None => Done
Open/Closed:Open => Closed
___
Follow-up Comment #1:
It was fixed in
Update of bug #46436 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #2:
Update of bug #47991 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #2:
Thanks for
Daiki Ueno <u...@gnu.org> writes:
> To do that, I think we need a good name of the public header.
After some considerations, I came up with , because those
functions are about user configuration of languages.
I also do not really like the name {set,get}_i18n_language(), because:
Update of bug #47123 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks for the
ds a bit ambiguous to
me. Do you have any suggestions?
Also, splitting libgnuintl.in.h is a bit of a task since it requires to
copy all the helper macros (for redefining functions) into the new file.
Regards,
--
Daiki Ueno
Update of bug #45405 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #3:
Closing this, as
Update of bug #45305 (project gettext):
Status: In Progress => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #10:
Closing this, as
Michael Pyne <mp...@kde.org> writes:
> On Wed, May 11, 2016 11:32:29 Daiki Ueno wrote:
>> Michael Pyne <mp...@kde.org> writes:
>> > This is important because 6.2.4 specifies that the value of a pointer is
>> > only valid as long as the lifetime of the
c systems,
> using gnulibology patterns.
>
> But adding yet another call from layer (B) to layer (C) is even more of a
> hack.
Yes. The intention of this hack was to save existing programs without
modification (for the new API). However, for the majority of programs,
it could be mitigated in a general-purpose library like GLib, by calling
set_i18n_language() during initialization of the library.
Regards,
--
Daiki Ueno
er variable
(i.e. TYPE **ptr, not TYPE *ptr) to properly invalidate the pointer
variable.
Regards,
--
Daiki Ueno
Michael Pyne <mp...@kde.org> writes:
> On Mon, May 9, 2016 08:51:56 Daiki Ueno wrote:
>> Follow-up Comment #3, bug #47847 (project gettext):
>>
>> Thanks for the comment, Bruno.
>>
>> The reasoning sounds convincing, but I'm a bit confused that there
Update of bug #47697 (project gettext):
Status:None => Duplicate
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks for the
Follow-up Comment #1, bug #47674 (project gettext):
I'd expect it will be fixed once the next version of grep is released, with a
fix in gnulib incorporated:
https://lists.gnu.org/archive/html/bug-gnulib/2016-04/msg9.html
We would better wait it rather than adding a workaround relying on the
supported in musl?
After briefly checking Solaris 11 variants have:
#define __GNU_GETTEXT_SUPPORTED_REVISION(m) \
m) == 0) || ((m) == 1)) ? 1 : -1)
Regards,
--
Daiki Ueno
configuration (Debian).
So I suppose the only feasible option here is to somehow whitelist the
implementations by checking macros or symbols. Does musl provides
anything like that[1]?
Regards,
Footnotes:
[1] https://sourceforge.net/p/predef/wiki/Libraries/
--
Daiki Ueno
Update of bug #47531 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks, I have
mat directive.
> msgfmt: found 1 fatal error
Thanks for the report. I didn't realize that PEP3101 allows such
"chained" invocations of '.' and '[..]'. I have pushed the attached
patch to fix this.
Regards,
--
Daiki Ueno
>From b4220c509a90186931a69575981c1b0e80ffc1f6 Mon Sep
e removed from directory %$1s",
> "%$2d files removed from directory %$1s",
> n),
> dir, n);
Thank you. I have fixed it in git:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=009c1218593a5f5a6d132b3694e4e679572eff9f
Regards,
--
Daiki Ueno
Update of bug #44588 (project gettext):
Status:None => Fixed
Open/Closed:Open => Closed
___
Follow-up Comment #1:
Thanks Geert for
Update of bug #47484 (project gettext):
Status:None => Need Info
___
Follow-up Comment #2:
I'm a bit confused that you mention "gettext 0.19.7" in the first comment and
"git clone" in
port.
>
> IMO invoking the ACL tests should not have happened.
Actually, the ACL tests are skipped. From your log:
> SKIP: test-file-has-acl.sh
> SKIP: test-file-has-acl-1.sh
> SKIP: test-file-has-acl-2.sh
> ../../build-aux/test-driver: line 107: 21788 Abort trap
> (core dumped) "$@" >$log_file 2>&1
> FAIL: test-float
The failing test is test-float.
Regards,
--
Daiki Ueno
t supported
yet, but I guess it wouldn't be a problem for gettext as it is ignored
at extraction phase and 'javascript-format' flag is not emitted.
Regards,
--
Daiki Ueno
e for DLLs on OS/2
Thanks, merged them. Sorry for the delay.
Regards,
--
Daiki Ueno
Follow-up Comment #1, bug #46844 (project gettext):
Thanks for reporting that. We should probably make the libxml2 check tighter,
so that it fails when the required functions are not compiled in the library.
Anyway, I guess a work around would be adding --with-included-libxml to
configure.
/usr/bin/xgettext: warning: file '../src/roxterm-config.glade'
> extension 'glade' is unknown; will try C
This is a packaging problem; the gettext package now needs to install
version specific data files from /usr/share/gettext-0.19.7 directory,
like the attached patch.
Regards,
--
Daiki Ueno
diff
t know, but some other projects (e.g. coreutils) also ships a copy
of help2man for some reasons.
Regards,
--
Daiki Ueno
is needed.
It is merely needed to distinguish user-supplied *.its files, which
shall be installed in /usr/share/gettext/its, from our own.
This is analogous to the use of /usr/share/aclocal-VERSION in Automake
or /usr/share/vala-VERSION/vapi in Vala.
Regards,
--
Daiki Ueno
, GSettings, and AppData) are
rewritten using ITS. In addition, msgfmt now has --xml option to
merge translations back to the original XML document.
* Portability:
- Improve OS/2 kLIBC support (still not complete)
- Remove dependency on expat
Thanks,
--
Daiki Ueno
signature.asc
Description
Update of bug #46756 (project gettext):
Status:None => Confirmed
___
Follow-up Comment #1:
Yes, this is certainly a regression and the character escapes should be
converted before
g/cgit/gettext.git/commit/?id=8054ef11
Unless there is any major problem, I will release it as 0.19.7 in a few
days.
Regards,
--
Daiki Ueno
ls: Use a short name for DLLs on OS/2
+AM_CONDITIONAL([OS2], [test "${host_os#os2}" != "${host_os}"])
I guess it would be a little more portable to use a 'case "$host_os"
...' statement (like WOE32), instead of ${VAR#WORD} substitution.
Regards,
--
Daiki Ueno
Assaf Gordon <assafgor...@gmail.com> writes:
> On 12/14/2015 12:44 AM, Daiki Ueno wrote:
>> I have updated the included libxml2 to the latest release 2.9.3 and
>> uploaded a new tarball:
>> http://alpha.gnu.org/gnu/gettext/gettext-0.19.6.44-a2e0a.tar.xz
>> http://
://alpha.gnu.org/gnu/gettext/gettext-0.19.6.44-a2e0a.tar.xz
http://alpha.gnu.org/gnu/gettext/gettext-0.19.6.44-a2e0a.tar.xz.sig
Thanks,
--
Daiki Ueno
dependency on expat
Thanks,
--
Daiki Ueno
ted for libgettexpo for
some reasons (copyright, etc).
Regards,
--
Daiki Ueno
egally-Significant
I will let you know if the paperwork is necessary.
Regards,
--
Daiki Ueno
xpat dependencies with libxml2 (for tools) and a hand written XML
parser (for libgettextpo, maybe ported from GLib's gmarkup.c). So this
shouldn't be necessary.
Regards,
--
Daiki Ueno
7642183
> Is there somewhere where I can get the "original source" of the
> documentation, make fixes, and provide the changed file back for
> review?
The source of the gettext manual resides in gettext-tools/doc/ in
Texinfo format (*.texi). Further corrections would be greatly
appreciated.
Regards,
--
Daiki Ueno
ea which
symbols or macros can be used for the check. It would be helpful if
musl people could chime in and give us a hint.
Regards,
--
Daiki Ueno
Jakub Wilk <jw...@jwilk.net> writes:
> There are some duplicated words in the copying permission statements
> in gettext-runtime/m4/*.m4:
>
> ... This file can can be used ...
> ... gettext package package is covered ...
Thanks, fixed.
Regards,
--
Daiki Ueno
there any chances that it will be fixed?
Please go ahead and describe the issue. We will try to fix it if it is
a real bug.
Regards,
--
Daiki Ueno
gic ain't working string"
msgstr ""
Regards,
--
Daiki Ueno
Daiki Ueno <u...@gnu.org> writes:
> Just wanted to notice that I have removed all ChangeLog files (except
> the ones in "intl" and "po") from the repository. From now on, a
> top-level ChangeLog file is generated from the commit logs, at "make
nu.org/cgit/gettext.git/commit/?id=614ff78d
Thanks,
--
Daiki Ueno
t do not provide langinfo.h.
>
> * gettext-runtime/intl/localename.c: Wrap langinfo.h include with same
> ifdefs used in the source later on.
Thanks, applied the patch.
Regards,
--
Daiki Ueno
HTML tag "
msgstr ""
If not, could you provide a concrete example so we can reproduce the
issue?
Regards,
--
Daiki Ueno
IX, right?
Thanks,
--
Daiki Ueno
Follow-up Comment #9, bug #45305 (project gettext):
In wip/ueno/its2 branch, I implemented the merge functionality in msgfmt as
--xml option, which can be used just like msgfmt --desktop:
https://git.gnome.org/browse/gnome-characters/tree/data/Makefile.am?h=wip/dueno/gettext#n28
Update of bug #45305 (project gettext):
Status: Fixed => In Progress
Open/Closed: Closed => Open
___
Follow-up Comment #8:
> ...and
duced AM_GNU_GETTEXT_REQUIRE_VERSION macro).
> For instance, I ran into it with GNU cpio 2.12.
That's unfortunate. I'm adding the cpio maintainer to Cc, to notify
this issue.
Maybe the next gettext release should really fix the build
infrastructure of 0.19 in archive.dir.tar*.
Regards,
--
Daiki Ueno
Follow-up Comment #1, sr #108887 (project gettext):
According to the specification, the Icon key is really translatable:
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
Maybe it is to allow applications to have locale-dependent icons?
header comments.
* Bug fixes:
- Fix mishandling of gettext version numbers for minor releases, in
po-mode.el and gettextize.
- Fix build with --enable-relocatable.
Regards,
--
Daiki Ueno
signature.asc
Description: PGP signature
ame1.policy:42
msgid "Authentication is required to set local machine information."
msgstr ""
At the moment, the implementation lacks many features (and tests), but I
would like to gather opinions before going further.
Comments appreciated!
Regards,
--
Daiki Ueno
Follow-up Comment #1, bug #45846 (project gettext):
Question: does it tries to implement inexisting functions? or add something
to existing functions?
Yes, that is how gnulib (which is copied into the gettext source tree) works
to replace broken or incomplete implementation of those functions:
for some use-cases,
e.g., FSF-copyrighted packages (like coreutils, gettext), where
translations are also attributed to the same copyright holder. In that
case, it is natural to leave the responsibility to rewrite YEAR to the
translators.
Regards,
--
Daiki Ueno
Paul Eggert egg...@cs.ucla.edu writes:
* loadmsgcat.c (_nl_load_domain):
Free data after a read failure. See:
https://sourceware.org/bugzilla/show_bug.cgi?id=18871
Thanks, applied.
Regards,
--
Daiki Ueno
, as in en@quot rules
- having multiple --copyright-foo options doesn't seem to play nicely
with the feature supplying COPYRIGHT_HOLDER from autoconf (bug 764483)
- that fits better in the Unix philosophy, which suggests to accomplish
larger tasks by combining small tools
Regards,
--
Daiki Ueno
are supplied, and (2) is a bit heuristic.
So, I prefer (3) or (4), as both of them could allow users to specify it
through po/Makevars, though (3) is a bit too specific.
Suggestions would be appreciated.
Regards,
--
Daiki Ueno
the multiple --copyright-holder
change, as I am reluctant to add new option to xgettext, which already
has too many options.
Regards,
--
Daiki Ueno
From c8f8099dca7976fa26d7ac671446144f1fe044c9 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@gnu.org
Date: Tue, 25 Aug 2015 11:47:20 +0900
Subject: [PATCH
Daiki Ueno u...@gnu.org writes:
By the way, after looking into the history and the documentation more
closely, I realized that my argument on copyright notice was pointless.
I'm sorry. I'm now in favor of adding support for multiple copyright
holders, like the attached patch, which makes
Update of bug #45305 (project gettext):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #7:
Merged as:
Daiki Ueno u...@gnu.org writes:
I'm still not very happy with the name AM_GNU_GETTEXT_PREREQ and having
a separate macro in the first place, but I couldn't think of any better
way to implement the functionality without breaking compatibility.
I've merged this after renaming
of gettext-tools/gnulib-tests/test-suite.log.
Regards,
--
Daiki Ueno
Update of bug #45765 (project gettext):
Status:None = Duplicate
Open/Closed:Open = Closed
___
Follow-up Comment #3:
Check out 0.19.5.1:
Follow-up Comment #1, sr #108864 (project gettext):
Couldn't it also be fixed by removing the last semicolon of:
__libc_lock_define_initialized_recursive (static, lock);
?
It is possible that the extra semicolon expands to an empty statement, which
pre-C99 compilers complain of.
When i
/bug-gettext/2015-07/msg00016.html
Regards,
--
Daiki Ueno
invalid, as there is an extra /project at
the end of file.
You might want to file a report at:
https://issues.sonatype.org/projects/MVNCENTRAL
Regards,
--
Daiki Ueno
in the file.
This is an expected behavior. msgcat (like other gettext commands)
wraps lines at a certain width, regardless of that the lines are
comments or msgid/msgstr.
Regards,
--
Daiki Ueno
Daiki Ueno u...@gnu.org writes:
Roumen Petrov bugtr...@roumenpetrov.info writes:
[...]
If understand idea is new archive to contain only recent versions.
Lets version 0.20.* not not add drastic change. Lest first drastic
version is 0.21.
Would you like to distribute archive with following
1 - 100 of 279 matches
Mail list logo
