savannah gnuploads (was [PATCH] gnupload: corrected SFTP connection URL)

Hi Bruno, While at it, I wonder if the following two upload targets in gnupload are still valid: savannah.gnu.org:DIRECTORY savannah.nongnu.org:DIRECTORY First, both of them cause anonymous ftp uploads whereas neither host listens on ftp port. Secondly, the savannah.nongnu.org docs [1]

Re: [PATCH] gnupload: corrected SFTP connection URL

Hi Bruno, > Can you please review this proposed patch? Yes, the patch is correct. Please apply it. > - The documentation of this script says that download.gnu.org.ua is > supported, but the actual upload happens to puszcza.gnu.org.ua. To make the long story short, the two names used to p

Re: [PATCH] gendocs.sh: don't overwrite existing index.html

Hi Bernhard, > If the point is to avoid a dangling symlink, then shouldn't this > (also) check for "${PACKAGE}.html"? Actually, the main point is to avoid destroying the existing file with a meaningless dangling symlink. That being said, I have nothing against checking for existence of "${PACKAG

[PATCH] gendocs.sh: don't overwrite existing index.html

When generating html output, texi2html 5.0 creates index.html file, instead of $PORJECT.html. Don't overwrite it with dangling symlink. --- build-aux/gendocs.sh | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/build-aux/gendocs.sh b/build-aux/gendocs.sh index 1872de9..082

parse-datetime.y reports integer overflow when compiled with gcc 5.5.0

Hello, With recent gnulib (v0.1-4336-gbdae9a5), attempting to compile parse-datetime.c fails with: $ make -k parse-datetime.o V=1 gcc -DHAVE_CONFIG_H -I. -I.. -Wall -ggdb -MT parse-datetime.o -MD -MP -MF .deps/parse-datetime.Tpo -c -o parse-datetime.o parse-datetime.c In file included from p

Re: argp failure on macOS

Hi Bruno, > Do you have time to look into this? Sure. I'll take a look. Regards, Sergey

Re: Would timevar be accepted in gnulib?

Paul Eggert ha escrit: > It might be helpful to have it, though I don't offhand know of > programs other than Bison and GCC that use that sort of thing. GNU dico is another one (although it uses its own implementation). Regards, Sergey

git-log-fix is missing

Hello, It has been reported that the commit 1589a8ab broke bootstrapping of the projects that use the gitlog-to-changelog module, because git-log-fix file listed in its module file is not present anywhere in the repository: http://lists.gnu.org/archive/html/bug-tar/2014-03/msg00082.html Regar

exclude: support posix regexps

sting API, so that the module can be used by existing code without modifications. Is it OK to push? Regards, Sergey >From 8341b9150246b1a6dfcf71946fa701294f0e3ada Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Sat, 15 Feb 2014 19:21:04 +0200 Subject: [PATCH] exclude: add support f

Re: [PATCH] savedir: optionally produce ordered directory list

Hi, Any objections to pushing the latest version of this patch to git head? Regards, Sergey

Re: [PATCH] savedir: optionally produce ordered directory list

Hi Ludovic, > FWIW I think it’s very important that tar --sort=name remains the > default, as it guarantees that archive production is deterministic. Actually, the default is not to sort directory entries at all: tar stores them in the same order as returned by the underlying system calls. I don'

Re: [PATCH] savedir: optionally produce ordered directory list

iteration over the entries array. The attached patch implements that idea and shows a slight improvement in the speed. Regards, Sergey diff --git a/ChangeLog b/ChangeLog index 96c544e..5aba801 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,21 @@ +2014-02-11 Sergey Poznyakoff + Pa

[PATCH] savedir: optionally produce ordered directory list

rom 92ddbfb74f05e5cded933f760cddd0ce007001ae Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Tue, 11 Feb 2014 10:52:44 +0200 Subject: [PATCH] savedir: optionally produce ordered directory list New function streamsavedir_ordered returns directory entries ordered by names or inode numbers. This

Re: [Bug-tar] [PATCH 0/1] Notes for wordsplit (was: Allow tar to usecommand for compressing consisiting of multiple words.)

Hi Paul, > Developers are assumed to have up-to-date systems where -Werror is > appropriate. Frankly, I cannot imagine a situation where treaing a warning as an error can be appropriate. That's why I consider it unfortunate. > I'm surprised you didn't run into this. That's quite simple. Confi

Re: [Bug-tar] Documentation bug

Jim Meyering ha escrit: > (BTW, the second sentence seems incorrect: > I saw no makefile rule for "ChangeLog" in tar.) It is in Make.rules, which is imported from Paxutils. Regards, Sergey

Re: [bug-inetutils] inetutils-1.8: ftp build error

Alfred M. Szmidt ha escrit: > This is a known bug, the reason if I recall is that readline exports > xmalloc and xrealloc is to allow programs to hook their own version > into readline. So the readline maintainer has declined any fixes for > this. This is a severe bug. It makes readline useless

Re: [Bug-tar] exclude wildcards with backslash

Eric Blake ha escrit: > This doesn't handle: []\a] as the set that recognizes '\\', 'a', or ']'. > Should it? No, it should not. This function is applied to strings that failed the fnmatch_pattern_has_wildcards test, i.e. which are not (valid) globbing patterns. Your example, however, is a va

Re: [Bug-tar] exclude wildcards with backslash

atch. Regards, Sergey >From abe9c758009394a09d0cb84cdaae37e5752953f2 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Thu, 6 May 2010 23:18:34 +0300 Subject: [PATCH] exclude: Unescape hashed patterns in wildcard mode. * lib/exclude.c (add_exclude): Unescape the pattern before adding it to the

Christian Weisgerber: [Bug-tar] 1.23: FreeBSD 7 bug affects GNU tar

Hello, Here's a report from one of GNU tar users. Regards, Sergey --- Forwarded message Date: Mon, 29 Mar 2010 22:12:02 +0200 From: Christian Weisgerber To: bug-...@gnu.org Message-ID: <20100329201202.ga28...@lorvorc.mips.inka.de> Subject: [Bug-tar] 1.23: FreeBSD 7 bug affects GNU tar Ther

Re: Petr Sumbera: [Bug-tar] tar 1.23 + verify() macro vs old compiler

Jim Meyering ha escrit: > However, it'd be slightly better not to separate the declaration > of "p" and that first use, so please move it one line higher, > so that the verify stmt is the first in the block. That's what I thought. Pushed. Regards, Sergey

Petr Sumbera: [Bug-tar] tar 1.23 + verify() macro vs old compiler

Hello, Forwarded is a user report and a proposed patch. OK to apply? Regards, Sergey --- Forwarded message Date: Mon, 15 Mar 2010 16:37:00 +0100 From: Petr Sumbera To: bug-...@gnu.org This is a multi-part message in MIME format. - --Boundary_(ID_saQ6xP8Er0Imd0fVVI/0wQ) Content-type: text

Re: Gnulib TP template out of date?

Karl Berry ha escrit: > Gnulib folks -- perhaps we should set up a cron job to update it > monthly, or some such? Nice idea. In the meantime I will submit the new potfile tomorrow. > Unfortunately I don't know how the previous pot was generated. Maybe > a Makefile could be supplied with a "pot

Re: Argp fix

Simon Josefsson ha escrit: > Ouch. Should this be reported to glibc as well? Yes, I'll do it. Regards, Sergey

Argp fix

ION_ALIAS }, both --peer and -p failed to work. I have installed the attached fix. Regards, Sergey >From 11fbc57405a118e6ec9a3ebc19bbf5ececdae4d6 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Fri, 5 Feb 2010 13:33:15 +0200 Subject: [PATCH] Argp: fix recognition of short alias option

Re: canonicalize_filename_mode memory usage

Eric Blake ha escrit: > Who do we use as --author and/or reporter in the git commit? The patch > first> appeared on the tar list in an email by Solar Designer, but it is not > clear > whether he wrote it, or whether we should attribute yet some other > person. It was reported by Solar Design

canonicalize_filename_mode memory usage

Hello, A user of tar reported a suboptimal memory usage by the canonicalize_filename_mode. Attached is the patch he proposed. Any comments? Regards, Sergey This patch corrects highly non-optimal memory allocation by canonicalize_filename_mode(), which got exposed with: 2009-08-07 Sergey

Re: chown, cpio: proposed change for userspec handling of USER:

Jim Meyering ha escrit: > Since the above behavior is not specified by POSIX, and > is IMHO, counter-intuitive, I propose to change it. However, > it is documented both in coreutils and in cpio's manuals. I'm not particularly bound to this feature, but it was here for such a long time that remo

Re: [PATCH] exclude: avoid an unwarranted warning

Eric Blake ha escrit: > Like this? Yes, it was one of the ways Jim suggested earlier. See http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00435.html Regards, Sergey

Re: getopt.h broken on FreeBSD

Hi Jim, > How about just using flex's %top directive? Hm, I overlooked that. Thanks for the suggestion! Regards, Sergey

getopt.h broken on FreeBSD

Hi, We've got one more problem with getopt.h. It manifests itself when compiling lex-generated parsers on FreeBSD. What happens is the following: the system getopt.h defines getopt_long, struct option and the accompanying stuff, but does not define __need_getopt. Consequently, gnulib's getopt.h in

Re: the signature of getopt, and getopt_long

Hi Lorenzo, > the > > char * const *argv > > libc declaration of getopt_long (which looks wrong, since argv might > be changed during the parsing, right?) Yes, it is wrong because argv might be permuted by getopt_long. And that's why gnulib's implementation uses __getopt_argv_const in the decla

Re: argp warnings

Eric Blake ha escrit: > OK to commit this patch? Sure! Please, do. Regards, Sergey

Re: getopt broken

Eric Blake ha escrit: > It turned out there is a much simpler fix. Since glibc #define's > _GETOPT_H, our replacement thought it had already been > included, and short-circuited. If we use a different name, then > everything works out. I'm pushing this: Yes, indeed. Thanks for the fix! Regar

Re: getopt broken

Eric Blake ha escrit: > But I doubt that interface has ever changed signature in glibc, and is not > available anywhere else. There are too many possibilities here. E.g. the function takes as its last argument a struct _getopt_data, which is declared in getopt_int.h This structure in libc may ha

Re: getopt broken

Eric Blake ha escrit: > Maybe the trick is to check whether _getopt_long_only_r is present to the > linker, in which case we can provide our own declaration of it Yes, but we cannot guarantee our declaration matches the actual function definition. Regards, Sergey

Re: getopt broken

Eric Blake ha escrit: > Oh, I see. getopt in isolation passes, but getopt in combination with > argp causes the failure you are seeing. I guess it's because the argp > module wants to use lower-level hooks from getopt1.c than what getopt.h > normally exposes. Yes, that's it. Argp uses _getopt_

getopt broken

Hello, The latest changes to getopt (commit 6471b462, "getopt: fix inclusion guards for cygwin") break compilation of getopt1.c on GNU/Linux: GENconfigmake.h CC getopt1.o getopt1.c:42: error: syntax error before '*' token getopt1.c: In function `getopt_long': getopt1.c:44: error: number o

Re: lib/exclude.c calls towlower() without checking for wideline support

Bruno Haible ha escrit: > Like Solaris 2.5.1 and IRIX 5.3, you mean? This should do it. Thanks, Bruno! Regards, Sergey

Re: lib/exclude.c calls towlower() without checking for wideline support

Hi Alan, > Sorry to ping again, but because coreutils 7.5 has the newer version of > gnulib it's blocking me from upgrading. Sorry for the delay: I was busy with other projects. I will provide a patch during this weekend. Stay in touch. Regards, Sergey

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > Yes, but I get this > > nm exclude.o | grep towlower > U _towlower > > And my libc doesn't define towlower() either. I see. Perhaps it is defined elsewhere? Could you please check? The gnulib's wchar.h does not provide a wrapper for it, unfortunately.

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > exclude.c: In function 'string_hasher_ci': > exclude.c:167: warning: implicit declaration of function 'towlower' > exclude.c:167: warning: incompatible implicit declaration of built-in > function 'towlower' These are warnings, not errors. What errors do you get? Pleas

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > Not sure this is right, but it works Surely it is not right. And it does not work, either: it does not correctly lower the case of the input string. Have you tried the patch I sent? Regards, Sergey

Re: lib/exclude.c calls towlower() without checking for wideline support

Alan Hourihane ha escrit: > As the subject line says, and I end up with an unresolved symbol. Please try this patch: diff --git a/lib/exclude.c b/lib/exclude.c index 32f2a0a..00f3891 100644 --- a/lib/exclude.c +++ b/lib/exclude.c @@ -31,6 +31,7 @@ #include #include #include +#include

Re: [PATCH] progname: also set global program_invocation_name, when possible

Hi Jim, > I have no control over glibc's error, and it uses program_invocation_name, > not program_invocation_short_name, so in order to make diagnostics appear like > > program_name: > > rather than > > /abs/dir.../.libs/lt-program_name: > > the set_program_name function mus

Re: [PATCH] progname: also set global program_invocation_name, when possible

Hello, > +#if HAVE_DECL_PROGRAM_INVOCATION_NAME > + program_invocation_name = (char *) argv0; > +#endif In my opinion, that's not correct. Libc (and gnulib's argp, FWIW) uses two variables: program_invocation_name, which points to the full program name as obtained from argv[0], and program_inv

Re: gl_GETOPT_SUBSTITUTE gone

Bruno Haible ha escrit: > Oops, I did not see this dependency. I'm restoring it now, as it's better > if most getopt related stuff stays in the same file getopt.m4. Thank you! Regards, Sergey

gl_GETOPT_SUBSTITUTE gone

Bruno, The recent removal of gl_GETOPT_SUBSTITUTE broke argp.m4. Argp depends on GNU getopt internals, so it is safer to always include gnulib's version of getopt even if libc's one behaves identically to GNU. Will it suffice to do this: diff --git a/m4/argp.m4 b/m4/argp.m4 index 7263a56..aeb2aeb

Re: Minor fix to gitlog-to-changelog

Jim Meyering ha escrit: > That's fine, as long as you also add a line or two in --help output. Sure. I have installed the following patch: >From 2ae2a816e734b0332eac67b07e184589e9b5957e Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Wed, 12 Aug 2009 19:48:51 +0300 Subj

Re: Minor fix to gitlog-to-changelog

Jim Meyering ha escrit: > I prefer the existing style, so how about making that format string an > option? That's reasonable. Something like that, then: diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog index 1cc53eb..677e5f6 100755 --- a/build-aux/gitlog-to-changelog +

Minor fix to gitlog-to-changelog

Hello, In the output of gitlog-to-changelog, subject lines are not separated from the body. This fix adds an extra newline and fixes this. Any objections to push it? Regards, Sergey diff --git a/build-aux/gitlog-to-changelog b/build-aux/gitlog-to-changelog index 1cc53eb..a4a0c1d 100755 --- a/bui

Re: [PATCH] Exclude optimization

Sergey Poznyakoff ha escrit: > It may, in same cases, incorrectly recognize the former to be the I wanted to say "in some cases", of course. Regards, Sergey

Re: [PATCH] Exclude optimization

Hi Ralf, > This would seem to still mis-characterizes patterns such as 'foo]'. Yes, of course. But this function is by no means thought to correctly catch all possible variations of wildcard patterns (one would have to duplicate fnmatch for that). Its purpose is to give a rough estimate on whethe

Re: [PATCH] Exclude optimization

ERR=0 at the beginning, while > test-exclude[167].sh don't? I've forgotten to set it there :) Fixed as well. Here goes the updated patch: >From c531a900bf4e62d0d6675a9133d6ccde972dc29d Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Tue, 11 Aug 2009 18:23:23 +0300 Subject

Re: [PATCH] Exclude optimization

nstant if FNM_NOESCAPE is on. Fixed both. > I would like to see some unit tests committed to this module before the > big optimization. Here they go: >From a83b74985b2226b74e23e9b2d6c32cd8037f3c80 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Tue, 11 Aug 2009 15:47:45 +0300 Su

Re: [PATCH] Exclude optimization

Bruno Haible ha escrit: > Why does it not fit into two regexes / DFAs? Yes, it would, provided that we translate fnmatch patterns to regexps. > EXCLUDE_WILDCARDS on: 'a?b*' -> 'a.b.*' > EXCLUDE_WILDCARDS off: 'a?b*' -> 'a[?]b[*]' > EXCLUDE_ANCHORED on: 'a?b' -> '^a.b$' >

Re: [PATCH] Exclude optimization

Hi Bruno, > 'is_fnmatch_pattern' is probably a misnomer, because its argument is > by definition already an fnmatch pattern. What the function is testing is > whether it contains wildcard characters Yes, indeed. > Btw, this function does not handle multiple adjacent backslashes correctly, > i.e.

[PATCH] Exclude optimization

Hello, The proposed patch considerably speed-ups the exclude module for large exclusion lists of non-wildcard patterns. Ok to push? >From 5421774438de3a67d89f988a0cd735e19a4cafd4 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Mon, 10 Aug 2009 00:14:45 +0300 Subject: [PATCH] Optim

Re: test-argp-version-etc

Hi Simon, > the self test fails like this when used in a project: Thanks for noticing. > How about this patch? Nice, please push it. Regards, Sergey

Re: New module argp-version-etc

Eric Blake ha escrit: > And introduced a bug to plain version_etc clients in the process, with the > potential to make --version segfault. Sorry for not spotting it before you > committed: Oops, it's me who should apologize for not spotting it! > I will be checking in this patch, if no one e

Re: New module argp-version-etc

Bruno Haible ha escrit: > typo:assumed [..] > A dependency to 'version-etc' is missing. It leads to this error: Thanks, Bruno. I've fixed it. > $ ./gnulib-tool --test argp-version-etc I ran ./gnulib-tool --test --with-tests argp-version-etc, and it pulled the missing dependency via module

Re: New module argp-version-etc

Hi Jim, > Another issue: consistency. With Bruno's approach, a public function must > have *no* spec just before its definition, while each private one does. > I think we all agree that duplicating the spec (before definition and in > the .h file) is not maintainable. Unfortunately your mail arr

Re: New module argp-version-etc

Hello, I have fixed the issues Bruno pointed out in his posting, and committed the following changes. Regards, Sergey >From 3457fcf5632d0411821c6ca61b09c945da9b1063 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Thu, 25 Jun 2009 10:31:56 +0300 Subject: [PATCH] Provide additio

Re: New module argp-version-etc

Bruno Haible ha escrit: > - Do you really need *two* array-taking functions? Yes, I believe so. I could remove one of them, but that would make the interface more awkward. E.g. retaining only version_etc_ar would mean extra iteration when called from version_etc_va. On the other hand, retainin

Re: New module argp-version-etc

Eric Blake ha escrit: > One alternative is to massage the actual output through sed to match the > expected output, regardless of the year from version-etc.c. Such as: > > ./test-ave --version | sed 's/(C) [0-9][0-9][0-9][0-9]/(C) 2009/' \ > | diff -c $TMP - || ERR=1 That's exactly what I

Re: New module argp-version-etc

Here's the updated patch. It swaps the n_authors and authors arguments, provides additional comments, removes the year-dependency from the test case and adds a call to va_end in version_etc. Regards, Sergey 2009-06-24 Sergey Poznyakoff Provide additional interfaces for version-etc m

Re: New module argp-version-etc

Eric Blake ha escrit: > Why'd you drop the comments describing what the method does? I did not. I simply retained the original comment before version_etc_va. I should have supplied comments before the two new functions, that's true. I'll fix this. > I'd like to see the arguments reversed: > >

New module argp-version-etc

functionality requires some minor changes to the existing version-etc module (patch 1). Opinions? Regards, Sergey 2009-06-24 Sergey Poznyakoff Provide additional interfaces for version-etc module. * lib/version-etc.c (version_etc_arn, version_etc_ar): New

Re: dropping setuid/setgid privileges

Bruno Haible ha escrit: > What is the use-case that you are considering? A setuid/setgid executable, > or an executable run by root? I was considering an executable run by root. > And what task does it do, related to the user's data and devices? Retaining supplementary is often necessary for t

Re: dropping setuid/setgid privileges

James Youngman ha escrit: > It's possible that one of the process's supplementary groups is > privileged. So we may also need to do something like this: > > #if HAVE_SETGROUPS > /* Use of setgroups() is restricted to root only. */ > if (0 =3D=3D geteuid()) > { > /* We're either r

Re: [PATCH] Add optional silent-rules support

Ralf Wildenhues ha escrit: > Not as far as I can see. Solaris /bin/awk doesn't have the match and > sub functions, and has several other limitations over POSIX awk. Ah, I see. > On Solaris, you should be able to use nawk or /usr/xpg4/bin/awk. OK, then using ${AWK-awk} should do to help in thi

Re: [PATCH] Add optional silent-rules support

Ralf Wildenhues ha escrit: > - the awk script won't detect if there are already $(AM_V_...) variables > present in the rules, Yes, that's intended. It was supposed that silent-rules variables can not appear in the input. Regards, Sergey

Re: [PATCH] Add optional silent-rules support

Hi Ralf, > Can gnulib-tool create > target1 target2 ... \ > targetN : prereq1 ... \ > prereqN ; rule-command > > rules? Well, quick grep through modules/* shows that so far no module generates such rules. But in theory it is possible. I'll take it into account, then. > Sho

[PATCH] Add optional silent-rules support

Hello, How about the following patch, which adds support for `silent-rules' mode introduced in Automake 1.11: * build-aux/bootstrap (slurp): Add silent rule support to $gnulib_mk, if required by the configure.ac. --- build-aux/bootstrap | 49 + 1

Re: open_safer on amd64

Eric Blake ha escrit: > In earlier versions of POSIX, the intent was that mode_t could > be narrower than int, and that all programmers had to use only symbolic > constants in that argument. As a side note, on that particular architecture, mode_t is indeed narrower than int. Regards, Sergey

Re: open_safer on amd64

Bruno Haible ha escrit: > You can ignore this warning. The code is fine. Ah, OK. Thank you. Perhaps it merits mentioning in the docs, to avoid further reports of this kind? Regards, Sergey

open_safer on amd64

Hello, When trying to compile open-safer.c on amd64 I get: open-safer.c: In function 'open_safer': open-safer.c:46: warning: 'mode_t' is promoted to 'int' when passed through '...' open-safer.c:46: warning: (so you should pass 'int' not 'mode_t' to 'va_arg') open-safer.c:46: note: if this code is

Re: gnulib.pot versioning scheme

Bruno Haible ha escrit: > >gnulib-1836.86a37.1.1 > > If you do this, you can never again switch to a different versioning > scheme. Not quite so. What I meant is that the part between `-' and `1.1' is to be ignored (it cannot be used for ordering anyway). In this case I see no difficulty in

Re: gnulib.pot versioning scheme

Bruno Haible ha escrit: > How about changing the versioning scheme to > gnulib-1.1.2009.03.26 > or > gnulib-1.1.1836.86a37 It would be better to place "TP version" at the end, as in: gnulib-1836.86a37.1.1 This should work with the TP software. > Could you also generate and publish a

Re: gnulib.pot versioning scheme

Sergey Poznyakoff wrote: > I am going to submit the updated gnulib.pot to TP. Before this, > I'd like to change its versioning scheme so that it coincides with the > version reported by `gnilib-tool --version'. E.g. this potfile will be > named gnulib-0.0.1991-dbebf.pot.

gnulib.pot versioning scheme

Hello, I am going to submit the updated gnulib.pot to TP. Before this, I'd like to change its versioning scheme so that it coincides with the version reported by `gnilib-tool --version'. E.g. this potfile will be named gnulib-0.0.1991-dbebf.pot. Does it seem a good idea? Regards, Sergey

Re: [Translation-team-de] German translations for man-db and gnulib

Colin Watson ha escrit: > Indeed, http://translationproject.org/POT-files/gnulib-1.1.pot is > looking a bit stale. Could somebody on bug-gnulib update the POT file > held by the TP, please? That's my fault. I'll update it today. Regards, Sergey

Re: [PATCH] Specify archive suffixes to announce-gen

Jim Meyering ha escrit: > Sure, that looks fine. > But please remove the trailing blanks first. Done. Regards, Sergey

[PATCH] Specify archive suffixes to announce-gen

Hello, The enclosed patch add to announce-gen a new option, --archive-suffix, which allows to specify new archive suffixes. For example: announce-gen --archive-suffix cpio.gz --archive-suffix shar.gz It is useful for such projects as GNU tar, which is distributed in a wider set of archive form

Re: url's in --help output

Ben Asselstine ha escrit: > On Sat, Jan 31, 2009 at 5:22 PM, Karl Berry wrote: > >The <...> markup is helpful when the URL is broken into two lines, > > > > Let's not forget about argp. Here's a patch to sync it to the new > format. That would break too many existing programs. I'd rather

Re: [gnu-prog-discuss] url's in --help output

Simon Josefsson ha escrit: > Ah, interesting, I wasn't aware of this feature. Do I as maintainer of > projects using gnulib have to do anything special to make this usable > for translators? Nothing special, only make sure the files imported from gnulib are listed in your po/POTFILES.in. Regar

Re: [gnu-prog-discuss] url's in --help output

Karl Berry ha escrit: > However, as far as I know there isn't a gnulib translation domain that > > There actually is, although I admit I don't know how the messages get > integrated into the gnulib-using packages: > http://translationproject.org/domain/gnulib.html It is a "compendium" domai

set_program_name behavior

Hello, The behavior of set_program_name differs depending on whether argv[0] refers to a libtool script (*/.libs/lt-*) or to a usual binary. In the first case, the function strips off all directory components and the `lt-' prefix, and assigns the result to program_name. In the second case, however

Re: Alan Hourihane: [bug #24687] implicit usage of mbsinit & mbrtowc

Bruno Haible ha escrit: > This is done. Thanks, Bruno! Regards, Sergey

Re: Alan Hourihane: [bug #24687] implicit usage of mbsinit & mbrtowc

Hi Bruno, > The problem is that texinfo's info.h includes mbiter.h unconditionally, > whereas the module description in gnulib specifies this: Ah, that's my fault. > Now I see that you have 9 functions in > texinfo/info/{display.c,session.c,window.c} which use the mbiter > facility unconditiona

Alan Hourihane: [bug #24687] implicit usage of mbsinit & mbrtowc

Hello, A user of Texinfo reported this: > URL: > > > Summary: implicit usage of mbsinit & mbrtowc > Project: texinfo - GNU documentation system [...] > Details: > > In texinfo 4.13 the files gnulib/lib/mbuiter.h and gnuli

bootstrap for SVN

Hello, I have installed the following change to make bootstrap work better with SVN repositories: diff --git a/build-aux/bootstrap b/build-aux/bootstrap index cf6b73b..1a24e82 100755 --- a/build-aux/bootstrap +++ b/build-aux/bootstrap @@ -415,6 +415,8 @@ version_controlled_file() { g

Minor change to m4/argp.m4

Hello, I have installed the following patch: 2008-02-29 Sergey Poznyakoff <[EMAIL PROTECTED]> * m4/argp.m4 (gl_ARGP): Use AC_TRY_LINK to test if program_invocation_name and program_invocation_short_name are present. diff --git a/m4/argp.m4 b/m4/argp.m4 index 7

Re: Configurable source_base et al. in bootstrap

Hello, In the absense of any objections, I have installed the following changes: 2008-02-28 Sergey Poznyakoff <[EMAIL PROTECTED]> * build-aux/bootstrap (source_base, m4_base) (doc_base, tests_base): New variables. (gnulib_tool_options): Do not hardcod

Configurable source_base et al. in bootstrap

Hello, Some projects place gnulib sources into a directory named other than `lib'. Therefore, I propose the following changes (m4_base and others are added for the sake of completeness): diff --git a/build-aux/bootstrap b/build-aux/bootstrap index 6fa1553..87a2798 100755 --- a/build-aux/bootstrap

Re: [Bug-tar] Wildcards do not match invalid characters

jlh <[EMAIL PROTECTED]> ha escrit: > Ok, here's an update. I could track down the cause of this > problem. In order to match file names to patterns, tar uses the > fnmatch(3), which is provided by glibc. This happens in > lib/exclude.c:149:exclude_fnmatch(). fnmatch() is documented to > return

bootstrap: copy failure

Bootstrap reports cp: cannot create regular file `lib/uniwidth/cjk.h-t': No such file or directory The following patch fixes it: diff --git a/build-aux/bootstrap b/build-aux/bootstrap index 0e2bd34..278c10b 100755 --- a/build-aux/bootstrap +++ b/build-aux/bootstrap @@ -366,6 +367,11 @@ cp_mark_a

Bootstrap and 4-argument AC_INITs

Hello, The following fixes package name extraction from 4-argument AC_INIT invocations: diff --git a/build-aux/bootstrap b/build-aux/bootstrap index 0e2bd34..1034ca3 100755 --- a/build-aux/bootstrap +++ b/build-aux/bootstrap @@ -77,9 +77,10 @@ po_download_command_format=\ extract_package_name=

Re: bootstrap sync from coreutils

Jim Meyering <[EMAIL PROTECTED]> ha escrit: > + * build-aux/bootstrap: Sync from coreutils: > + 2007-10-24 Jim Meyering <[EMAIL PROTECTED]> > + Get gnulib from the git repository, not from an obsolete cvs one. There are some cvs leftovers, though: diff --git a/build-aux/bootstrap b

Re: new gnulib admin?

Bruno Haible <[EMAIL PROTECTED]> ha escrit: > I propose to make Eric Blake an admin of the gnulib project at > http://savannah.gnu.org/projects/gnulib. Agreed. Regards, Sergey

Re: POTFILES.in updates?

Eric Blake <[EMAIL PROTECTED]> ha escrit: > Not to mention that not all of gnulib's uses occur with the _ macro - for > example, xstrtol.h currently calls gettext directly, rather than going > through a macro, so that it won't pollute the user's namespace with a > conflicting _ macro. Yes, indeed

  1   2   >