http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24338 <pre>forcemerge 11470 11494 thanks On 05/16/2012 04:48 PM, Ivan Vilata i Balaguer wrote: Thanks for the report; however, you're the fifth person to report this in 48 hours, and it has already been fixed in current git: http://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e2bd5cda0a34 </pre> Eric Blake 2012-05-16T23:10:13 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24337 <pre>Hi, in coreutils 8.17 (and in current git), `fmt.c` contains the following help line: -g, --goal=WIDTH goal width (default of 93% of width) The percent is interpreted (at least by `msgfmt`) as the start of a `%o` format string, thus translations are forced to have an "o" after `93%` which makes things quite difficult. ;) Changing `93%` by `93%%` should do the job. Thanks, </pre> Ivan Vilata i Balaguer 2012-05-16T22:48:37 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24336 <pre>merge 11486 11487 tag 11487 notabug close 11487 thanks On 05/16/2012 07:25 AM, Marsaleix Thomas wrote: Glad to hear you figured it out, and that it is not a bug. I'm closing this report. As a side note, 'echo -n' is not portable. You should really get in the habit of using 'printf' instead. </pre> Eric Blake 2012-05-16T16:32:21 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24335 <pre>rehello, That's ok, my problem come from new line. echo "è" | base64 is: "è\n" | base64 and:echo -n "è" | base64 works better. base64 (GNU coreutils) 8.5 Thanks Thomas. </pre> Marsaleix Thomas 2012-05-16T13:25:26 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24334 <pre>Hello, Base64 encode 'è' with '6Ao='. After différents test I find '6A==', In base16, 'è'==E8. in binary string, 'è'=11101000 (== 256) 111010=(decimal:) 58=(base64:)6 000000=(decimal:) 0=(base64:)0 base64 (GNU coreutils) 8.5 Cordialement Thomas. </pre> Marsaleix Thomas 2012-05-16T12:58:35 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24333 <pre> Thanks for all the replies and for merging those, Eric. I wrote the patch. As expected, it was more work to collect and insert names in THANKS.in than to make the actual change ;-) Note that Göran's name is already in the generated THANKS file, so I didn't add it below. If anyone listed prefers a different spelling of name or email, just let us know. From 54be50197b47ba9200a1c3e48847fa959d4f5bfd Mon Sep 17 00:00:00 2001 From: Jim Meyering &lt;meyering&lt; at &gt;redhat.com&gt; Date: Wed, 16 May 2012 07:26:36 +0200 Subject: [PATCH] maint: tell xgettext that fputs arg "93% of..." is not a C format string MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * src/fmt.c (usage): Add a comment to tell xgettext that the "% o" in fputs argument string of "...93% of..." is not a C format string. Reported by Toomas Soome, Göran Uddeborg, Petr Pisar, Primoz PETERLIN and Chusslove Illich via http://bugs.gnu.org/11470 --- THANKS.in | 4 ++++ src/fmt.c | 2 ++ 2 files changed, 6 insertions(</pre> Jim Meyering 2012-05-16T05:33:00 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24332 <pre>merge 11470 11483 thanks On 05/15/2012 03:14 PM, Chusslove Illich wrote: This is the fourth report of the same issue within 48 hours, and second mention of the solution, but still no one has submitted the solution as an actual patch. We will get the problem fixed, but an actual patch would make it easier. </pre> Eric Blake 2012-05-16T04:17:02 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24331 <pre>Hello, Coreutils 8.17 introduced a small change in the message catalogue which causes considerable problems to translators. The part which causes problems is: #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" msgstr "" Apparently, msgfmt interprets "% o" in the help text of the --goal option as a format specifier. This means that the translations will be rejected unless the translation also contains the same sequence: % being followed by a space, being followed by a small o. All the best, Primož </pre> Primoz PETERLIN 2012-05-15T19:57:07 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24330 <pre> When that happens, you add such a comment line just before the problematic gettext call: /* xgettext: no-c-format */ gettext("...93% of width...") The extracted message will then have no-c-format flag instead of c-format, thus not triggering format validation. This is documented in section 4.6 of Gettext manual. </pre> Chusslove Illich 2012-05-15T21:14:53 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24329 <pre> Pushed. http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c25bdb http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commit;h=b1fac3 http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=0863f01 thanks again, Pádraig. </pre> Pádraig Brady 2012-05-15T23:50:52 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24328 <pre> Yes, that works nicely. # src/stat -f ~/tmp/mnt File: "/home/nikratio/tmp/mnt" ID: 0 Namelen: 0 Type: fuseblk Block size: 8192 Fundamental block size: 4096 Blocks: Total: 268435456 Free: 268435456 Available: 268435456 Inodes: Total: 1000000 Free: 999997 # /usr/bin/stat -f ~/tmp/mnt File: "/home/nikratio/tmp/mnt" ID: 0 Namelen: 0 Type: fuseblk Block size: 8192 Fundamental block size: 8192 Blocks: Total: 268435456 Free: 268435456 Available: 268435456 Inodes: Total: 1000000 Free: 999997 Best, -Nikolaus </pre> Nikolaus Rath 2012-05-15T22:45:52 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24327 <pre> Works great. Thanks for doing this. </pre> Rich Burridge 2012-05-15T21:04:57 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24326 <pre> Hi Rich, If you can confirm that the following incremental patch is enough to inform parfait that there's no real problem in this part of fmt.c, I'll push the full patch below. diff --git a/src/fmt.c b/src/fmt.c index 308b645..e0c04cb 100644 --- a/src/fmt.c +++ b/src/fmt.c &lt; at &gt;&lt; at &gt; -20,6 +20,7 &lt; at &gt;&lt; at &gt; #include &lt;stdio.h&gt; #include &lt;sys/types.h&gt; #include &lt;getopt.h&gt; +#include &lt;assert.h&gt; /* Redefine. Otherwise, systems (Unicos for one) with headers that define it to be a type get syntax errors for the variable declaration below. */ &lt; at &gt;&lt; at &gt; -610,6 +611,11 &lt; at &gt;&lt; at &gt; get_paragraph (FILE *f) while (same_para (c) &amp;&amp; in_column == other_indent) c = get_line (f, c); } + + /* Tell static analysis tools that word_limit[-1] is ok. + word_limit is guaranteed to have been incremented by get_line. */ + assert (word &lt; word_limit); + (word_limit - 1)-&gt;period = (word_limit - 1)-&gt;final = true; next_char = c; return true; From 5917d6365e03eee7c28c4add3acf79e9f473d703 Mon Sep 17 00:00:00 2001 From: Jim</pre> Jim Meyering 2012-05-15T20:33:23 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24325 <pre>Hi, [Resending message cc'ed to 9500&lt; at &gt;debbugs.gnu.org as requested.] On Fri, May 11, 2012 21:36, Pádraig Brady wrote: relevant, the partition I tested on was ~1.7TB ext4 on an external USB 2.0 space spread all over the disk in thousands of small chunks. ext4 seems to be pretty slow at allocating space in that case. Unfortunately I have freed up a lot of space on the partition in question, but I did some testing with a new small empty test partition, see below. failure require a significant amount of disk access... non-hole parts within the fallocate() region would reduce the amount of additional space required for fallocate() to succeed. So it's not as simple as comparing length of fallocate() region with amount of free space... enough. (In fact, cp could do that anyway in most cases I think?) Yes. From the filesystem's perspective it could easily immediately fail fallocate() in some cases. When fallocate() is called, the approximate space needed for success is (length of region passed to fallocate</pre> Mark 2012-05-15T11:44:54 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24324 <pre> Yes this is messy. Note even though STAT_STATVFS is now true since Paul's gnulib change, stat(1) wants access to the f_type member which is not available in the statvfs structure. However frsize is available in the statfs structure since kernel 2.6, so we can use that where available. Nikolaus, could you try the stat command again with the following? If it works I'll submit to coreutils, with a NEWS update also mentioning Paul's gnulib fix. cheers, Pádraig. diff --git a/m4/stat-prog.m4 b/m4/stat-prog.m4 index 30bacb4..ff59a28 100644 --- a/m4/stat-prog.m4 +++ b/m4/stat-prog.m4 &lt; at &gt;&lt; at &gt; -72,8 +72,8 &lt; at &gt;&lt; at &gt; AC_INCLUDES_DEFAULT [AC_DEFINE([STRUCT_STATVFS_F_FSID_IS_INTEGER], [1], [Define to 1 if the f_fsid member of struct statvfs is an integer.])]) else - AC_CHECK_MEMBERS([struct statfs.f_namelen, struct statfs.f_type],,, - [$statfs_includes]) + AC_CHECK_MEMBERS([struct statfs.f_namelen, struct statfs.f_type, + struct statfs.f_frsize],,, [$statfs_includes]) if t</pre> Pádraig Brady 2012-05-15T10:10:05 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24323 <pre> Actually, it is. The format is 'o' with a space flag. Andreas. </pre> Andreas Schwab 2012-05-14T22:41:25 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24322 <pre>merge 11470 11472 thanks On 05/14/2012 01:27 PM, Petr Pisar wrote: Thanks. You're the third person to report this today, but the first to provide a potential patch. Are you comfortable submitting that fix in 'git format-patch' form with a proper commit message? If not, we will probably do it on your behalf in the next 24 hours or so. </pre> Eric Blake 2012-05-14T22:03:08 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24321 <pre>Hello, coreutils-8.17 contains this message: #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" The message is detected by xgettext as C formatted string because of the percentage character. The problem is such string does not pass through msgfmt tool while compiling the catalog because the '% ' is not a valid printf sequence. Solution is to suppress the auto-detection by adding /*xgettext:no-c-format*/ before the fputs() line in the source code. </pre> Petr Pisar 2012-05-14T19:27:42 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24320 <pre>merge 11470 11471 thanks On 05/14/2012 12:15 PM, Göran Uddeborg wrote: Yep, you're the second person to report that today. </pre> Eric Blake 2012-05-14T18:36:24 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24319 <pre>This message in the 8.17 message file is written using fputs(), but it is anyway marked as c-format. This is a problem since the % sign in the description of --goal is taken as a formatting directive (of an unsigned int written in octal, with the "space" flag). This causes problems when translating. The effect of the validation of the translation complains if the word following the percent sign doesn't start with an "o", or other letter which is "compatible" in printf's sense. (And in Swedish I would like it to start with an "a".) #: src/fmt.c:285 #, c-format msgid "" " -t, --tagged-paragraph indentation of first line different from second\n" " -u, --uniform-spacing one space between words, two after sentences\n" " -w, --width=WIDTH maximum line width (default of 75 columns)\n" " -g, --goal=WIDTH goal width (default of 93% of width)\n" </pre> Göran Uddeborg 2012-05-14T18:15:59 http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/24318 <pre> Thanks for the report. However, looking at format.c, we are printing this string via fputs(), and not fprintf(), so it is _not_ an unescaped %. Apparently, the '#, c-format' marking in the .pot file is the real bug, and we should figure out why xgettext put it there. </pre> Eric Blake 2012-05-14T17:55:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gnu.core-utils.bugs