Bug#1056351: dicod: wrong quotes in MediaWiki snippets in `/etc/dicod.conf`

[Sergey Poznyakoff]

That's an error in /etc/dicod.conf shipped with debian package.  The
dicod manual says clearly that:

  The default pp-setup file changes quote characters to â[ and â],
  and renames all m4 built-in macros so they all start with the prefix
  m4_.

See https://www.gnu.org.ua/software/dico/manual/html_node/Preprocessor.html

Regards,
Sergey

Bug#991917: python3-wikitrans: Wiki 2 html conversion errors

[Sergey Poznyakoff]

Hi Erich,

Thanks for your report.

> 1. This upstream patch should be included in the package:
> 
> https://git.gnu.org.ua/wikitrans.git/commit/?id=c785e3ad767b12a13ae75a3513ec88a4d1144210

Sure.  It will be included when new version is released.

> 2. A wrong variable name is used here:
> File "/usr/lib/python3/dist-packages/wikitrans/wikimarkup.py", line 662, in
> parse_ref
> list.append(self.parse_tag(tok))
> TypeError: descriptor 'append' for 'list' objects doesn't apply to a
> 'HtmlTagNode' object

That's definitely a copy-paste error.  I've pushed the following patch
https://git.gnu.org.ua/wikitrans.git/commit/?id=90a9ed7108e45fa8c2d0300e1308a99171240255

> 3. WikiDelimNodes (generated by wikimarkup: ''Example'') cause raw
> JSON to be
> inserted in the HTML:

Can you give more detail, please?

Regards,
Sergey

Bug#941412: CVE-2019-14866

[Sergey Poznyakoff]

Hi Ola,

> Hi Sergey
> 
> I can see that the fix is quite different from the one Thomas proposed. Do
> I understand correctly that this fix go around the problem in a different
> way?

Not quite so.  It takes basically the same approach as the fix Thomas
proposed, but also removes unnecessary code duplication and ensures
informative error diagnostics.

> I do not see any explicit value > 0 check.

See the return from the to_ascii function.

> it looks like the fix allows larger file sizes

No, of course all size limits remain the same,

Regards,
Sergey

Bug#941412: CVE-2019-14866

[Sergey Poznyakoff]

Hi Ola & Thomas,

> I have been preparing fixes for CVE-2019-14866 for Debian oldstable

Thank you.  The issue has been fixed in commit 7554e3e4 [1].

Regards,
Sergey

[1] 
http://git.savannah.gnu.org/cgit/cpio.git/commit/?id=7554e3e42cd72f6f8304410c47fe6f8918e9bfd7

Bug#918806: [bug-mailutils] version 3.5: mail/mailx discard message body when attachment is supplied

[Sergey Poznyakoff]

Hi Daniel,

> Are you aware of this report in debian about mail discarding stdin when
> being used to send an e-mail with an attachment?
> 
> https://bugs.debian.org/918806

Thanks for reporting. I fixed it in 43214185092e714e0c233bf196f571bba5c17be0.

Meanwhile, you can use the --mime option as a workaround:

 echo "body text" | /usr/bin/mail --mime -s "some subject" -A "somefile.csv" 
m...@email.com

Regards,
Sergey

Bug#923609: Binary incompatibility in libgdbm6

[Sergey Poznyakoff]

Hi Dmitry,

> Thank you, Sergey. Does incompatibility goes other way too, that version
> without LFS support is incapable of reading file, created with LFS
> version?

Yes, as the accompanying NOTE-WARNING file says:

 Gdbm files have never been `portable' between different operating
 systems, system architectures, or potentially even different compilers.
 Differences in byte order, the size of file offsets, and even structure
 packing make gdbm files non-portable.

(btw, this file seems not to be included in the Debian package, perhaps
it makes sense to do so).

> I consider providing statically-linked, LFS-disabled version of
> gdbm_{load,dump,tool}, so user with database, created on stretch could
> do `gdbm_dump old.gdbm | gdbm_load new.gdbm'. Opinions?

That's nice idea. I'm all for it.

Best regards,
Sergey

Bug#923609: Binary incompatibility in libgdbm6

[Sergey Poznyakoff]

Hello,

Investigation of the attached file has shown that it has been created
by gdbm 1.8.3 compiled without large file support (sizeof(off_t) == 4).
In contrast, gdbm 1.18.1 was compiled with large file support enabled,
which naturally lead to the observed behavior. Recompile it with the
--disable-largefile flag and it will be able to read the file.

Regards,
Sergey

Bug#904366: mailutils-config and the mailutils tool are unusable in 1:3.4-1

[Sergey Poznyakoff]

Package: libmailutils-dev
Version: 1:3.4-1
Severity: serious

Hello,

Invoking mailutils-config with any argument results in:

$ mailutils-config --info
/usr/bin/mailutils-config: 115: /usr/bin/mailutils-config: mailutils: not found

This script is in fact a wrapper around the 'mailutils' tool, but the
tool itself is included in another packet, mailutils. Now, installing
mailutils doesn't make the situation any better:

$ mailutils-config --info
mailutils: don't know what info is

This is because the mailutils tool is a dispatcher command that calls
one of the specific standalone binaries from the pkglibexecdir to
perform the requested action (see the commit 444d20f3,
http://git.savannah.gnu.org/cgit/mailutils.git/commit/?id=444d20f3c).
Now, none of these binaries is included in the package (nor in any other
sub-package of mailutils, for that matter).

The script mailutils-config is used by the AM_MAILUTILS macro, defined in
/usr/share/aclocal/mailutils.m4. This means that this bug makes it
impossible to build any projects that depend on Mailutils and use this
macro in configure.ac to detect its presence. Therefore I qualified it
as serious.

To fix this, I would suggest to move usr/bin/mailutils from package
'mailutils' to 'libmailutils-dev' and to add all mailutils-*
binaries from the pkglibexecdir directory. The proposed patch is
attached.

The patch fixes the reported bug, yet reveals another (minor)
one. Please note the 'usr/lib/mailutils/mailutils/' path in the resulting
libmailutils-dev.install file. This is because
/usr/share/cdbs/1/class/autotools-vars.mk from cdbs sets the
DEB_CONFIGURE_LIBEXECDIR variable to "\$${prefix}/lib/$(DEB_SOURCE_PACKAGE)",
thereby defeating the purpose of libexecdir, for which GNU standards say
that this is

  [t]he directory for installing executable programs to be run by other
  programs rather than by users. 
  [...]
  The definition of 'libexecdir' is the same for all packages

This looks like yet another instance of the bug fixed long ago in debhelper:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541458. Perhaps it's
worth reporting to cdbs hackers. Anyway, adding

   DEB_CONFIGURE_LIBEXECDIR = \$${prefix}/lib

to the debian/rules will fix this as well (obviously the paths in the
attached file should be changed accordingly).

Best regards,
Sergey

diff -pur debian-orig/libmailutils-dev.install debian/libmailutils-dev.install
--- debian-orig/libmailutils-dev.install	2018-07-23 13:54:47.755922366 +
+++ debian/libmailutils-dev.install	2018-07-23 13:58:06.908660263 +
@@ -1,4 +1,6 @@
 usr/bin/mailutils-config
+usr/bin/mailutils
+usr/lib/mailutils/mailutils/mailutils-*
 usr/include/mailutils/*
 usr/lib/*/lib*.so
 usr/share/aclocal/mailutils.m4
diff -pur debian-orig/mailutils.install debian/mailutils.install
--- debian-orig/mailutils.install	2018-07-23 13:54:47.758922443 +
+++ debian/mailutils.install	2018-07-23 13:58:44.483808011 +
@@ -1,7 +1,6 @@
 usr/bin/dotlock.mailutils
 usr/bin/frm.mailutils
 usr/bin/from.mailutils
-usr/bin/mailutils
 usr/bin/mail.mailutils
 usr/bin/messages.mailutils
 usr/bin/mimeview

Bug#815965: [Bug-cpio] cpio: reads out-of-bounds with cpio 2.11

[Sergey Poznyakoff]

Hi Petter,

> I notice there is a new upstream version 2.12 available.  The problem seem to
> exist also there:

Thanks for reporting.  I've fixed it in the repository.

Regards,
Sergey

Bug#816072: [patch #8925] Support --clamp-mtime for binary reproducibility

[Sergey Poznyakoff]

Update of patch #8925 (project tar):

  Status:None => Done   
 Assigned to:None => gray   

___

Follow-up Comment #1:

The patch is incorporated into Git repository (commit
13d04fe6ae5a343415299359944382f7a6d37816). It will appear in the next stable
release of GNU tar (v.1.29). Thank you!

___

Reply to this item at:

  

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

Bug#733505: CVE-2013-6889: Allows reading arbitrary files

[Sergey Poznyakoff]

Hello,

Thanks for noticing.  The bug is fixed in the rush repository (commit
00bdccd4).

Regards,
Sergey


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

Bug#700354: info: segfault on tab completion on large terminals

[Sergey Poznyakoff]

Andreas Schwab  ha escrit:

> There is no garantee that input is zero-terminated.

Fixed that too.  Thanks a lot!

Regards,
Sergey


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

Bug#700354: info: segfault on tab completion on large terminals

[Sergey Poznyakoff]

Hi,

> Sergey, if you have a chance to try to track it down

Sure, I've fixed it.

> P.S. Independent of all these settings and input, valgrind reports:
> 
> ==5435== Conditional jump or move depends on uninitialised value(s)
> ==5435==at 0x4006A97: strlen (mc_replace_strmem.c:275)

That looks rather a valgrind quirk.  All values are definitely
initialized.  From the formal point of view, endp may point to
uninitialized memory, but the C standard explicitly allows that.

Regards,
Sergey


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

Bug#656659: info not showing anything with certain build flags

[Sergey Poznyakoff]

Norbert Preining  wrote:

>   footnotes.c: In function ‘info_show_footnotes’:
>   footnotes.c:258:11: error: format not a string literal and no format 
> arguments [-Werror=format-security]
>   footnotes.c:262:11: error: format not a string literal and no
>   format arguments [-Werror=format-security]

It is intended (see the comment in info.c:692-695, for the reason of
it). I'll see if this can be rewritten some other way to pacify gcc, but
for the time being you'll have to drop that `-Werror' option.

Regards,
Sergey



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

Bug#598932: info crashes when selecting a node inside of an info file

[Sergey Poznyakoff]

Hilmar Preusse  ha escrit:

> Many thanks! Could you sent the patch to us?

Here it goes.

Regards,
Sergey

Index: info/nodes.c
===
RCS file: /cvsroot/texinfo/texinfo/info/nodes.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -p -u -r1.14 -r1.15
--- info/nodes.c	17 Mar 2010 22:01:05 -	1.14
+++ info/nodes.c	7 Oct 2010 12:24:07 -	1.15
@@ -1,5 +1,5 @@
 /* nodes.c -- how to get an Info file and node.
-   $Id: nodes.c,v 1.14 2010/03/17 22:01:05 pertusus Exp $
+   $Id: nodes.c,v 1.15 2010/10/07 12:24:07 gray Exp $
 
Copyright (C) 1993, 1998, 1999, 2000, 2002, 2003, 2004, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
@@ -946,6 +946,7 @@ info_node_of_file_buffer_tags (FILE_BUFF
   for (i = 0; (tag = file_buffer->tags[i]); i++)
 if (strcmp (nodename, tag->nodename) == 0)
   {
+	NODE *node;
 FILE_BUFFER *subfile = info_find_file_internal (tag->filename,
 INFO_NO_TAGS);
 if (!subfile)
@@ -960,98 +961,97 @@ info_node_of_file_buffer_tags (FILE_BUFF
 
 /* If we were able to find this file and load it, then return
the node within it. */
-{
-  NODE *node = xmalloc (sizeof (NODE));
-  node->filename= subfile->fullpath;
-  node->parent  = NULL;
-  node->nodename= tag->nodename;
-  node->contents= subfile->contents + tag->nodestart;
-  node->display_pos = 0;
-  node->flags   = 0;
-
-  if (file_buffer->flags & N_HasTagsTable)
-{
-  node->flags |= N_HasTagsTable;
-
-  if (file_buffer->flags & N_TagsIndirect)
-{
-  node->flags |= N_TagsIndirect;
-  node->parent = file_buffer->fullpath;
-}
-}
-
-  if (subfile->flags & N_IsCompressed)
-node->flags |= N_IsCompressed;
-
-  /* If TAG->nodelen hasn't been calculated yet, then we aren't
- in a position to trust the entry pointer.  Adjust things so
- that ENTRY->nodestart gets the exact address of the start of
- the node separator which starts this node, and NODE->contents
- gets the address of the line defining this node.  If we cannot
- do that, the node isn't really here. */
-  if (tag->nodelen == -1)
-{
-  int min, max;
-  char *node_sep;
-  SEARCH_BINDING node_body;
-  char *buff_end;
-
-  min = max = DEFAULT_INFO_FUDGE;
-
-  if (strict_node_location_p)
-{
-  min = 0;
-  max = 2;
-}
-
-  if (tag->nodestart < min)
-min = tag->nodestart;
-
-  if (max >
-  (subfile->filesize - tag->nodestart))
-max = subfile->filesize - tag->nodestart;
-
-  /* NODE_SEP gets the address of the separator which defines
- this node, or NULL if the node wasn't found.
- NODE->contents is side-effected to point to right after
- the separator. */
-  node_sep = adjust_nodestart (node, min, max);
-  if (node_sep == NULL)
-{
-  free (node);
-  return NULL;
-}
-  /* Readjust tag->nodestart. */
-  tag->nodestart = node_sep - subfile->contents;
-
-  /* Calculate the length of the current node. */
-  buff_end = subfile->contents + subfile->filesize;
-
-  node_body.buffer = node->contents;
-  node_body.start = 0;
-  node_body.end = buff_end - node_body.buffer;
-  node_body.flags = 0;
-  tag->nodelen = get_node_length (&node_body);
-  node->nodelen = tag->nodelen;
-}
+	if (!(tag->nodestart >= 0 && tag->nodestart < subfile->filesize))
+	  return NULL;
 
-  else if (tag->nodelen == 0) /* anchor, return containing node */
-{
-  free (node);
-  node = find_node_of_anchor (file_buffer, tag);
-}
+	node = xmalloc (sizeof (NODE));
+	node->filename= subfile->fullpath;
+	node->parent  = NULL;
+	node->nodename= tag->nodename;
+	node->contents= subfile->contents + tag->nodestart;
+	node->display_pos = 0;
+	node->flags   = 0;
+	
+	if (file_buffer->flags & N_HasTagsTable)
+	  {
+	node->flags |= N_HasTagsTable;
+	
+	if (file_buffer->flags & N_TagsIndirect)
+	  {
+		node->flags |= N_TagsIndirect;
+		node->parent = file_buffer->fullpath;
+	  }
+	  }
+	
+	if (subfile->flags & N_IsCompressed)
+	  node->flags |= N_IsCompressed;
+	
+	/* If TAG->nodelen hasn't been calculated yet, then we aren't
+	   in a position to trust the entry pointer.  Adjust things so
+	   

Bug#598932: info crashes when selecting a node inside of an info file

[Sergey Poznyakoff]

Hi Hilmar,

Thans for the report.  Your suggestion to check for nodestart bounds
is correct.  I have installed a corresponding patch to CVS.

I must say that this info file is terribly malformed.  None of its
6 nodes points to the right place, and the last three actually point
far outside the EOF.  How did you create it?

Regards,
Sergey



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

Bug#592220: [Bug-dico] mediawiki: crash while searching a simple string

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> What does that diff do ?

It speaks clearly for itself, I believe.

> Is it related to UTF8 issue ?

Of course, not.

Regards,
Sergey



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

Bug#592220: [Bug-dico] mediawiki: crash while searching a simple string

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> I thought that you first reverted those lines, because this is not a 
> right thing to do in python

It is questionable. I don't care whether it is right or wrong
from the point of view of Python purists. The truth is that this is
the only approach that works.

Regards,
Sergey



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

Bug#592220: [Bug-dico] mediawiki: crash while searching a simple string

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> I applied the patch from git commit 
> c4db582a8c59cabec8632c7f1f79bd79f47ab9d3, yet when testing it I get the 
> following error:

Thanks for reporting. That commit fails, indeed. I have reverted it.
Please pull.

Regards,
Sergey



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

Bug#582799: [Bug-dico] Bug#582799: dicod: the 'all' strategy is dangerous for a production server !

[Sergey Poznyakoff]

=?utf-8?B?2KPYrdmF2K8g2KfZhNmF2K3ZhdmI2K/Zig==?=  ha 
escrit:

> The packages of the other modules do depend on the dicod package. But I 
> separated them, as it may occur that a user may not want to install them 
> (especially that some of them pulls some dependencies).

I certainly agree with this sort of policy for modules requiring extra
dependencies. But (1) neither of the modules in question requires
anything, and (2) the overall size of the two modules together is 6K,
which is ridiculous for a separate module.

Regards,
Sergey



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

Bug#582799: [Bug-dico] Bug#582799: dicod: the 'all' strategy is dangerous for a production server !

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> Especially I need your opinion regarding install substr & 
> stratall modules in dicod package, instead of creating separate packages 
> for them.

In my opinion they defininitely *do not* qualify for separate packages,
just as the rest of modules for dicod.  They are part of the server and
should be distributed with it,

Regards,
Sergey



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

Bug#582799: [Bug-dico] Bug#582799: dicod: the 'all' strategy is dangerous for a production server !

[Sergey Poznyakoff]

Hi Marc,

Some time ago I wrote:

> > On the other hand, I agree that a mechanism for disabling arbitrary
> > strategies is needed (both on database level and globally). I will
> > provide a solution for this latter.

It took me a little longer than expected. I have moved the `all'
strategy into a loadable module, so that it is not enabled unless
the admin explicitly loads it in the configuration file.  Please,
try this tarball:

  ftp://download.gnu.org.ua/pub/alpha/dico/dico-2.0.91.tar.gz

Apart from this changes, this version also implements the
`substr' strategy, which matches a substring anywhere in the
headword.  This, too, is implemented as a module.

As usual, your feedback is welcome.

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> Looking at the fd-tur-eng index, i can find these entries, but is
> seems it is then missing from the dict.dz, if i understand the format
> well. I made a few other searches, and was not capable to reproduce
> with another search pattern on several other database. I'll have a
> better look tomorrow before perhaps bugging the dict-freedict-tur-eng
> package.

The problem with that database is that its index uses strange collating
order. Take a look at lines 2102 and below. You'll see:

ahfat   DkphC6
ahitDEKZCA
ahitJ7du/
ahize   LlZ6Eo
ahkâmı diniye   B5fqGK

Then, look at line 2289. There we have:

ahır/Ih D/
ahırDI15Dp
ahırNmBhCT

Now, the collating order in Turkish is:

  abcçdefgğhıij...

As you see the index file is ordered improperly. The proper ordering
would be

ahfat
ahır
...
ahit

That's why you cannot get the definition. To fix this add sort[1]
to the loading sequence in fd-tur-eng database:

database {
  name "fd-tur-eng";
  handler "dictorg sort database=/usr/share/dictd/freedict-tur-eng";
}

Regards,
Sergey

[1] http://dico.prog.gnu.org.ua/manual/html_node/Dictorg.html#IDX148



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

Bug#582799: [Bug-dico] Bug#582799: dicod: the 'all' strategy is dangerous for a production server !

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> I've already used this setting. It works well if you search across
> *all* databases, but if you specify one, the search goes on and
> displays the whole database content after several minutes hanging the
> machine (please don't experiment with my server).

I see your point, but what you report is another bug, not related to
that particular search strategy. It becomes prominent when "all" is
used (because of a huge number of elements involved), but it affects
other searches as well.

Please apply the attached patch. It will fix the response procedure
for all types of the queries (both "match" and "define") in dictorg
databases. This will make single-database "all" matches feasible in
terms of time usage. 

On the other hand, I agree that a mechanism for disabling arbitrary
strategies is needed (both on database level and globally). I will
provide a solution for this latter.

Regards,
Sergey

>From 9b10f09671e8498ee9862bd9190fc1fb324e35e7 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff 
Date: Mon, 24 May 2010 14:26:00 +0300
Subject: [PATCH] Speed up output procedure in dictorg.

Provide a general-purpose mechanism to address iterators by item
number in O(|n-pos|) time.

* include/dico/list.h (dico_iterator_prev)
(dico_iterator_item, dico_iterator_position): New prototypes.
* lib/list.c (list_entry) : New member.
(iterator) : New member.
(dico_iterator_position): New function.
(_iterator_increase_pos): New static.
(dico_iterator_first): Initialize pos to 0.
(dico_iterator_next): Increase pos.
(dico_iterator_prev,dico_iterator_item): New function.
(_dico_list_append): Initialize ep->prev.
(_dico_list_prepend): Initialize ep->prev. Call
_iterator_increase_pos to tell iterators to update their recorded positions.
(_dico_list_remove): Rewrite removal code using next & prev pointers.
(_dico_list_insert_sorted): Update next & prev pointers.
Call _iterator_increase_pos.
* modules/dict.org/dictorg.h (result) : New member.
* modules/dict.org/dictorg.c (common_match)
(suffix_match, _match_all): Initialize itr.
(mod_output_result): Use iterator to avoid rescanning the list
on each call.
(mod_free_result): Destroy the iterator.

* lib/utf8.c (utf8_strcasecmp, utf8_strncasecmp): Break the loop if
alen or blen is zero. This means that one of the operands is not
utf8, but try to return meaningful value anyway.
---
 include/dico/list.h|3 +
 lib/list.c |  126 +++-
 lib/utf8.c |8 +++
 modules/dict.org/dictorg.c |   14 +-
 modules/dict.org/dictorg.h |1 +
 5 files changed, 126 insertions(+), 26 deletions(-)

diff --git a/include/dico/list.h b/include/dico/list.h
index 8f5419d..4ca5d40 100644
--- a/include/dico/list.h
+++ b/include/dico/list.h
@@ -64,6 +64,9 @@ dico_iterator_t dico_list_iterator(dico_list_t list);
 void dico_iterator_destroy(dico_iterator_t *ip);
 void *dico_iterator_first(dico_iterator_t ip);
 void *dico_iterator_next(dico_iterator_t ip);
+void *dico_iterator_prev(dico_iterator_t ip);
+void *dico_iterator_item(dico_iterator_t ip, size_t n);
+size_t dico_iterator_position(dico_iterator_t ip);
 
 int dico_iterator_remove_current(dico_iterator_t ip, void **pptr);
 void dico_iterator_set_data(dico_iterator_t ip, void *data);
diff --git a/lib/list.c b/lib/list.c
index 309369c..9d1da6b 100644
--- a/lib/list.c
+++ b/lib/list.c
@@ -23,7 +23,7 @@
 #include 
 
 struct list_entry {
-struct list_entry *next;
+struct list_entry *next, *prev;
 void *data;
 };
 
@@ -42,6 +42,7 @@ struct iterator {
 dico_list_t list;
 struct list_entry *cur;
 int advanced;
+size_t pos;
 };
 
 static int
@@ -120,13 +121,22 @@ dico_iterator_current(dico_iterator_t ip)
 return ip->cur ? ip->cur->data : NULL;
 }
 
+size_t
+dico_iterator_position(dico_iterator_t ip)
+{
+if (!ip)
+   return 0;
+return ip->pos;
+}
+
 static void
 dico_iterator_attach(dico_iterator_t itr, dico_list_t list)
 {
 itr->list = list;
-itr->cur = NULL;
+itr->cur = list->head;
 itr->next = list->itr;
 itr->advanced = 0;
+itr->pos = 0;
 list->itr = itr;   
 }
 
@@ -178,6 +188,26 @@ dico_iterator_destroy(dico_iterator_t *ip)
 *ip = NULL;
 }

+static void
+_iterator_increase_pos(dico_iterator_t ip, size_t after)
+{
+for (; ip; ip = ip->next) {
+   if (ip->pos > after)
+   ip->pos++;
+}
+}
+
+static void
+_iterator_advance(dico_iterator_t ip, struct list_entry *e)
+{
+for (; ip; ip = ip->next) {
+   if (ip->cur == e) {
+   ip->cur = e->next;
+   ip->advanced++;
+   }
+}
+}
+
 void *
 dico_iterator_first(dico_iterator_t ip)
 {
@@ -185,6 +215,7 @@ dico_iterator_first(dico_iterator_t ip)
return NULL;
 ip->cur = ip->list->head;
 ip->advance

Bug#582799: [Bug-dico] Bug#582799: dicod: the 'all' strategy is dangerous for a production server !

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> How can we limit in non-default searches ?

I described this in my previous post. Add the following to your config
file:

strategy all {
   deny-all yes;
}

This disables it for all searches.

Regards,
Sergey
   



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

Bug#582799: [Bug-dico] Bug#582799: dicod: the 'all' strategy is dangerous for a production server !

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> > The "Match everything (experimental)" strategy is not suited for
> > production servers, as its name says, and consume all CPU, leading
> > to an easy DOS attack method.

Any implementation of "match everything" strategy is potentially harmful
and certainly not suited for production servers. I thought it was obvious.

> There is no way to deactivate it,

No, there is:

strategy all {
  deny-all yes;
}

See the manual, section 3.3.12 "Strategies and Default Searches" [1]

Regards,
Sergey

[1] http://dico.prog.gnu.org.ua/manual/html_section/Configuration.html#SEC29



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

Bug#582695: [Bug-dico] Bug#582695: dicoweb: crash while displaying a definition

[Sergey Poznyakoff]

Fixed in commit ceeec5623dbf19d8c96cd1187c5f17ed362cb5fe [1]

Regards,
Sergey

[1] 
http://git.gnu.org.ua/cgit/dico.git/patch/?id=ceeec5623dbf19d8c96cd1187c5f17ed362cb5fe



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> And now getting the definition for each one:
> koruma -> No match
> kurama -> OK
> kurma -> OK
> kurum -> No match
> kuruma -> OK
> kurumak -> No match
> kurutma -> No match

Very strange. I cannot reproduce this. With 2.0.90 I get definitions for
each one of them.

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

Marc Dequ�nes (Duck)  ha escrit:

> Installed on dico.duckcorp.org, but does not fix this bug (tested both
> web and cli).

Here's what I get when talking to dico.duckcorp.org:

$ telnet dico.duckcorp.org dict
Trying 193.200.42.177...
Connected to dico.duckcorp.org (193.200.42.177).
Escape character is '^]'.
220 Toushirou.duckcorp.org dicod (GNU dico 2.0.90) 

 <24097.1274635...@toushirou.duckcorp.org>
define fd-deu-eng "kurkuma"

define fd-deu-eng "kurkuma"

150 1 definitions found: list follows
151 "kurkuma" fd-deu-eng ""
Kurkuma [kurkuːmaː] (n) , s.(n )
   turmeric


.
250 Command complete [d/m/c = 1/0/15 0.001r 0.000u 0.000s]

Regards,
Sergey



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

Bug#582671: [Bug-dico] Bug#582671: dicoweb: configuration provided as data (fwd)

[Sergey Poznyakoff]

Commit 96770e6e7026ccb54c53c904bb9a3e37102098db renames
settings.py to settings-sample.py. Will it help?

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> Do you consider it to be stable enough for release ? Or is it just for 
> testing ?

It is definitely more stable than 2.0 after applying patches, because
it ensures that no changes would get lost in between.

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> Actually the original version of this patch did not apply cleanly, there 
> were two or three hunks, and then I refreshed the patch.

That's because of that 15 patches in between. Ahmed, perhaps you can
use 2.0.90 for the debian package?

Regards,
Sergey



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

Bug#582694: [Bug-dico] Bug#582694: dicoweb: links to external databases are useless

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> Same request with my server and the 2 patches from #582692 and #582708
> applied:
>   http://dico.duckcorp.org/?q=House&db=en-wikipedia&define=1
> (but it gives the same result if i try "house" and click on any link
> from the mediawiki backend)
> => "No match", sorry :-/

The result may be cached by the python backend (see CACHE_BACKEND
in your settings.py).

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> 
> Perhaps another buffer problem. I'm using a lot of databases on my
> config (74 to be precise), so perhaps this is a problem.

Strange, I have installed the same set of databases on my box (except for
english-german and german-english which I was unable to find) and still
get a result. There were some 15 commits after 2.0 (apart from those of
today), which may well affect the case. To make sure we are using the
same codebase, please try this version:

  ftp://download.gnu.org.ua/pub/alpha/dico/dico-2.0.90.tar.gz

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> Using 0003-Avoid-using-fixed-size-buffer-in-dictorg.c.patch, i still
> get a no match. Try this to see by yourself:
>   dico --host=dico.duckcorp.org -a kurutma
> ("kurutma" being one of the found entries for the same "kuruma" search)

Yes, when querying your server I do get a "No match" answer. However,
trying on my box I get a definition. Are you sure the patch has applied
cleanly?

Regards.
Sergey



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

Bug#582697: [Bug-dico] Bug#582697: dicoweb: should display a fallback name for database without description

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

> Actually those databases do have a description field already, seems that 
> this is actually a bug in dict.org module.
>
> For example, look at "vera" dictionary database.

It does not contain neither info, nor a description, nor any
other service fields. What it has in index is:

00databasealphabet  Ci7Pl
00databasedictfmt11011  A   c
00databaseinfo  CJ  Ve
00databaseshort 2   BT
00databaseurl   c   a

Whereas, according to the dict format, these entries must be:

00-database-alphabet
00-database-dict-fmt
00-database-info
00-database-short
00-database-url

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

Sergey Poznyakoff  ha escrit:

> ãí¥ï ç¤¥í¥¨ïª  ha escrit:
> 
> >   This patch does not fix that one gets duplicates, is it intended to 
> >   be this way ?
> 
[...]
> This will require a bit more work, though.

The attached patch coalesces multiple matches into one entry.
Please give it a try and let me know if it works for you.

Regards,
Sergey

diff --git a/include/dico/list.h b/include/dico/list.h
index f816362..8f5419d 100644
--- a/include/dico/list.h
+++ b/include/dico/list.h
@@ -22,12 +22,18 @@
 
 /* Lists */
 
+#define DICO_LIST_COMPARE_HEAD 0x01
+#define DICO_LIST_COMPARE_TAIL 0x02
+
 typedef int (*dico_list_iterator_t)(void *item, void *data);
 typedef int (*dico_list_comp_t)(const void *, void *);
 
 dico_list_t dico_list_create(void);
 void dico_list_destroy(dico_list_t *list);
 int dico_list_clear(struct dico_list *list);
+int dico_list_set_flags(struct dico_list *list, int flags);
+int dico_list_get_flags(struct dico_list *list);
+
 int dico_list_set_free_item(struct dico_list *list,
 			dico_list_iterator_t free_item, void *data);
 dico_list_comp_t dico_list_set_comparator(dico_list_t list,
diff --git a/lib/list.c b/lib/list.c
index cae8f83..d15de44 100644
--- a/lib/list.c
+++ b/lib/list.c
@@ -30,6 +30,7 @@ struct list_entry {
 struct dico_list {
 size_t count;
 struct list_entry *head, *tail;
+int flags;
 struct iterator *itr;
 dico_list_comp_t comp;
 dico_list_iterator_t free_item;
@@ -56,6 +57,7 @@ dico_list_create()
 if (p) {
 	p->count = 0;
 	p->head = p->tail = NULL;
+	p->flags = 0;
 	p->itr = NULL;
 	p->comp = cmp_ptr;
 	p->free_item = NULL;
@@ -266,6 +268,26 @@ dico_list_set_comparator(struct dico_list *list, dico_list_comp_t comp)
 return prev;
 }
 
+int
+dico_list_set_flags(struct dico_list *list, int flags)
+{
+   if (!list) {
+   errno = EINVAL;
+   return 1;
+   }
+   list->flags = flags;
+   return 0;
+}
+
+int
+dico_list_get_flags(struct dico_list *list)
+{
+   if (list)
+   return list->flags;
+   return 0;
+}
+
+
 dico_list_comp_t
 dico_list_get_comparator(struct dico_list *list)
 {
@@ -285,6 +307,9 @@ dico_list_append(struct dico_list *list, void *data)
 	errno = EINVAL;
 	return 1;
 }
+if ((list->flags & DICO_LIST_COMPARE_TAIL) && list->comp
+	&& list->tail && list->comp(list->tail->data, data) == 0)
+	return EEXIST;
 ep = malloc(sizeof(*ep));
 if (!ep)
 	return 1;
@@ -308,6 +333,9 @@ dico_list_prepend(struct dico_list *list, void *data)
 	errno = EINVAL;
 	return 1;
 }
+if ((list->flags & DICO_LIST_COMPARE_HEAD) && list->comp
+	&& list->head && list->comp(list->head->data, data) == 0)
+	return EEXIST;
 ep = malloc(sizeof(*ep));
 if (!ep)
 	return 1;
diff --git a/modules/dict.org/dictorg.c b/modules/dict.org/dictorg.c
index 909a15d..4d638db 100644
--- a/modules/dict.org/dictorg.c
+++ b/modules/dict.org/dictorg.c
@@ -536,8 +536,26 @@ register_strategies(void)
 }
 
 static int
+compare_entry(const void *a, const void *b)
+{
+const struct index_entry *epa = a;
+const struct index_entry *epb = b;
+compare_count++;
+return utf8_strcasecmp(epa->word, epb->word);
+}
+
+static int
+compare_entry_ptr(const void *a, const void *b)
+{
+const struct index_entry *epa = *(const struct index_entry **)a;
+const struct index_entry *epb = *(const struct index_entry **)b;
+return compare_entry(epa, epb);
+}
+
+static int
 common_match(struct dictdb *db, const char *word,
-	 int (*compare) (const void *, const void *), struct result *res)
+	 int (*compare) (const void *, const void *),
+	 int unique, struct result *res)
 {
 struct index_entry x, *ep;
 
@@ -561,6 +579,12 @@ common_match(struct dictdb *db, const char *word,
 	memerr("common_match");
 	return 0;
 	}
+	if (unique) {
+	dico_list_set_comparator(res->list,
+ (int (*)(const void *, void *))
+  compare_entry);
+	dico_list_set_flags(res->list, DICO_LIST_COMPARE_TAIL);
+	}
 	for (p++; p < ep; p++) 
 	if (!RESERVED_WORD(db, p->word))
 		dico_list_append(res->list, p);
@@ -572,26 +596,9 @@ common_match(struct dictdb *db, const char *word,
 
 
 static int
-compare_entry(const void *a, const void *b)
-{
-const struct index_entry *epa = a;
-const struct index_entry *epb = b;
-compare_count++;
-return utf8_strcasecmp(epa->word, epb->word);
-}
-
-static int
-compare_entry_ptr(const void *a, const void *b)
-{
-const struct index_entry *epa = *(const struct index_entry **)a;
-const struct index_entry *epb = *(const struct index_entry **)b;
-return compare_entry(epa, epb);
-}
-
-static int
 exact_match(struct dictdb *db, const char *word, struct result *res)
 {
-return common_match(db, word, compare_entry, res);
+return common_match(db, word, compare

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

>   This patch does not fix that one gets duplicates, is it intended to 
>   be this way ?

The patch was not intended to change this particular behavior. Since the
database does contain several entries with the same key, displaying
them all is correct, at least according to the standard. However,
I agree that it would be logical and more practical to compress them
all into one. This will require a bit more work, though.

Regards,
Sergey




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

Bug#582697: [Bug-dico] Bug#582697: dicoweb: should display a fallback name for database without description

[Sergey Poznyakoff]

> Many databases have no description at all (like english-german for
> example), and even if it is a probably bug in these databases (not
> sure it is compulsory in the DICT format), it renders the database
> selection in the form quite difficult to use because we get empty
> names. It really should fallback to the database name in this case.

Use the `description' statement in your database configuration:

database {
 name "english-german";
 description <

Bug#582694: [Bug-dico] Bug#582694: dicoweb: links to external databases are useless

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

>   This gave the results:
>   * en-wiktionary: house, House, household, houses, housewife, House of 
> Lords, housefly, House of Commons, housekeeper, housework
> 
>   Clicking on any of those gives a page with "No match"

That's related to the two recent patches. After applying them:

 http://dicoweb.gnu.org.ua/?q=House&db=en-wikipedia&define=1

Regards,
Sergey



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

Bug#582708: [Bug-dico] Bug#582708: dico: cannot fetch a definition

[Sergey Poznyakoff]

ãí¥ï ç¤¥í¥¨ïª  ha escrit:

>   1. I confirm that I get duplicates too, the reason as I see, is that 
> the matching word has several definitions in that dictionary.

Yes, that's right.

> dico --host=localhost -m kuruma
> 
> I got:
> 
> fd-deu-eng "kurkuma"
> 
> Which does have a definition indeed.

That's a bug. A fix is attached. Thank you.

Regards,
Sergey

>From 956846d3d1b5e35d9012be97b33066e480669dc1 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff 
Date: Sun, 23 May 2010 14:52:13 +0300
Subject: [PATCH] Avoid using fixed-size buffer in dictorg.c.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Fixes bug reported by Marc Dequènes (debian #582708).

* modules/dict.org/dictorg.c (read_index): Use dico stream instead
of FILE to avoid using fixed-size buffer.
---
 modules/dict.org/dictorg.c |   28 +---
 1 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/modules/dict.org/dictorg.c b/modules/dict.org/dictorg.c
index 7b040cd..17a310f 100644
--- a/modules/dict.org/dictorg.c
+++ b/modules/dict.org/dictorg.c
@@ -232,10 +232,9 @@ static int
 read_index(struct dictdb *db, const char *idxname, int tws)
 {
 struct stat st;
-FILE *fp;
-char buf[512]; /* FIXME: fixed size */
 int rc;
 dico_list_t list;
+dico_stream_t stream;
 
 if (stat(idxname, &st)) {
 	dico_log(L_ERR, errno, _("open_index: cannot stat `%s'"), idxname);
@@ -246,11 +245,21 @@ read_index(struct dictdb *db, const char *idxname, int tws)
 		 idxname);
 	return 1;
 }
-fp = fopen(idxname, "r");
-if (!fp) {
-	dico_log(L_ERR, errno, _("open_index: cannot open `%s'"), idxname);
+
+
+stream = dico_mapfile_stream_create(idxname, DICO_STREAM_READ);
+if (!stream) {
+	dico_log(L_ERR, errno,
+		 _("cannot create stream `%s'"), idxname);
 	return 1;
 }
+rc = dico_stream_open(stream);
+if (rc) {
+	dico_log(L_ERR, 0,
+		 _("cannot open stream `%s': %s"),
+		 idxname, dico_stream_strerror(stream, rc));
+	dico_stream_destroy(&stream);
+}
 
 list = dico_list_create();
 if (!list) {
@@ -260,17 +269,21 @@ read_index(struct dictdb *db, const char *idxname, int tws)
 	dico_iterator_t itr;
 	size_t i;
 	struct index_entry *ep;
+	char *buf = NULL;
+	size_t bufsize = 0;
+	size_t rdsize;
 
 	rc = 0;
 
 	i = 0;
-	while (fgets(buf, sizeof(buf), fp)) {
+	while (!dico_stream_getline(stream, &buf, &bufsize, &rdsize)) {
 	i++;
 	dico_trim_nl(buf);
 	rc = parse_index_entry(idxname, i, list, buf, tws);
 	if (rc)
 		break;
 	}
+	free(buf);
 	if (rc) {
 	dico_list_set_free_item(list, free_index_entry, NULL);
 	} else {
@@ -288,7 +301,8 @@ read_index(struct dictdb *db, const char *idxname, int tws)
 	dico_list_destroy(&list);
 }
 
-fclose(fp);
+dico_stream_close(stream);
+dico_stream_destroy(&stream);
 return rc;
 }
 
-- 
1.6.0.3

Bug#582692: [Bug-dico] Bug#582692: dicod: failure when no match found

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> I found another command giving the same problem:
>   dict -D dict://dico.duckcorp.org

It is the same as what you reported above. The patch I sent you should
fix this as well.

> The dico counterpart:
>  dico -D --host=dico.duckcorp.org
>
> Gives no entry in /var/log/dico/access.log (i guess this is a bug too).

No, it is not. Access log lists only MATCH and DEFINE requests.

> But uses:
>  SHOW DATABASES
> (seen with tshark)

FWIW, you don't need to use tshark for that. To get a detailed session
transcript use the following options:

* For dico: -t (--transcript)
* For dict: -r (--raw)

Regards,
Sergey



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

Bug#582692: [Bug-dico] Bug#582692: dicod: failure when no match found

[Sergey Poznyakoff]

Hi Marc,

Thanks for the additional information. It did help to locate the bug.
Please apply the attached patch.

Regards,
Sergey

>From aa2df3934c858977cd9033af2345f3566d136bd7 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff 
Date: Sun, 23 May 2010 14:50:12 +0300
Subject: [PATCH] Fix improper handling of conversion errors in levenshtein.c (debian #582692)

* include/dico/utf8.h (utf8_mbstr_to_wc)
(utf8_mbstr_to_norm_wc): Change signature.
* lib/utf8.c (utf8_mbstr_to_wc)
(utf8_mbstr_to_norm_wc): Take additional return argument.
Return error code. All callers updated.
* lib/levenshtein.c (dico_levenshtein_distance): conv
returns non-zero (not necessarily negative) value on errors.
---
 include/dico/utf8.h |4 ++--
 lib/levenshtein.c   |6 +++---
 lib/utf8.c  |   44 +++-
 3 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/include/dico/utf8.h b/include/dico/utf8.h
index 1f24b78..3462443 100644
--- a/include/dico/utf8.h
+++ b/include/dico/utf8.h
@@ -54,8 +54,8 @@ size_t utf8_wc_hash_string (const unsigned *ws, size_t n_buckets);
 int utf8_wc_strcmp (const unsigned *a, const unsigned *b);
 int utf8_wc_to_mbstr(const unsigned *wordbuf, size_t wordlen, char **sptr);
 
-int utf8_mbstr_to_wc(const char *str, unsigned **wptr);
-int utf8_mbstr_to_norm_wc(const char *str, unsigned **nptr);
+int utf8_mbstr_to_wc(const char *str, unsigned **wptr, size_t *plen);
+int utf8_mbstr_to_norm_wc(const char *str, unsigned **nptr, size_t *plen);
 
 int utf8_quote (const char *str, char **sptr);
 unsigned *utf8_wc_quote (const unsigned *s);
diff --git a/lib/levenshtein.c b/lib/levenshtein.c
index 366df04..125756f 100644
--- a/lib/levenshtein.c
+++ b/lib/levenshtein.c
@@ -42,12 +42,12 @@ dico_levenshtein_distance(const char *astr, const char *bstr, int flags)
 unsigned *row[3];
 int i, j, idx, nrows;
 int dist;
-int (*conv) (const char *, unsigned **) =
+int (*conv) (const char *, unsigned **, size_t *) =
 	(flags & DICO_LEV_NORM) ? utf8_mbstr_to_norm_wc : utf8_mbstr_to_wc;
 
-if (conv(astr, &a) < 0) 
+if (conv(astr, &a, NULL))
 	return -1;
-if (conv(bstr, &b) < 0) {
+if (conv(bstr, &b, NULL)) {
 	free(a);
 	return -1;
 }
diff --git a/lib/utf8.c b/lib/utf8.c
index 105cef6..bfe9951 100644
--- a/lib/utf8.c
+++ b/lib/utf8.c
@@ -1992,33 +1992,33 @@ utf8_wc_to_mbstr(const unsigned *wordbuf, size_t wordlen, char **sptr)
 }
 
 int
-utf8_mbstr_to_wc(const char *str, unsigned **wptr)
+utf8_mbstr_to_wc(const char *str, unsigned **wptr, size_t *plen)
 {
-  size_t sc = strlen(str);
-  size_t len, i;
-  unsigned *w = calloc(sizeof(w[0]), sc+1);
+ssize_t sc = strlen(str);
+size_t len, i;
+unsigned *w = calloc(sizeof(w[0]), sc+1);
 
-  if (!w)
-return -1;
-  for (i = 0, len = strlen(str); len; i++)
-{
-  int rc = utf8_mbtowc (w + i, (unsigned char *)str, len);
-  if (rc <= 0)
-	{
-	  free(w);
-	  return -1;
+if (!w)
+	return -1;
+for (i = 0, len = strlen(str); len; i++) {
+	int rc = utf8_mbtowc (w + i, (unsigned char *)str, len);
+	if (rc <= 0) {
+	free(w);
+	return -1;
 	}
-  str += rc;
-  len -= rc;
+	str += rc;
+	len -= rc;
 }
-  *wptr = w;
-  return sc;
+*wptr = w;
+if (plen)
+	*plen = sc;
+return 0;
 }
 
 #define ISWS(c) ((c)==' '||(c)=='\t'||(c)=='\n')
 
 int
-utf8_mbstr_to_norm_wc(const char *str, unsigned **nptr)
+utf8_mbstr_to_norm_wc(const char *str, unsigned **nptr, size_t *plen)
 {
 int inws = 0;
 size_t len = strlen(str);
@@ -2032,7 +2032,7 @@ utf8_mbstr_to_norm_wc(const char *str, unsigned **nptr)
 	unsigned wc;
 	int rc = utf8_mbtowc(&wc, (unsigned char *)str, len);
 	if (rc <= 0)
-	return 1;
+	return -1;
 	str += rc;
 	len -= rc;
 	if (rc == 1 && ISWS(wc)) {
@@ -2047,6 +2047,8 @@ utf8_mbstr_to_norm_wc(const char *str, unsigned **nptr)
 }
 base[i++] = 0;
 *nptr = realloc(base, i * sizeof(base[0]));
+if (plen)
+  *plen = i;
 return 0;
 }
 
@@ -2056,8 +2058,8 @@ utf8_quote (const char *str, char **sptr)
   int rc;
   unsigned *ws, *ret;
   
-  rc = utf8_mbstr_to_wc (str, &ws);
-  if (rc < 0)
+  rc = utf8_mbstr_to_wc (str, &ws, NULL);
+  if (rc)
 return rc;
   ret = utf8_wc_quote (ws);
   if (ret)
-- 
1.6.0.3

Bug#582692: dicod: failure when no match found

[Sergey Poznyakoff]

Sergey Poznyakoff  ha escrit:

> You can easily reproduce this by connecting to dico.duckcorp.org:2628
> and issuing the latter command. 

To be precise, I meant this:

MATCH * . "kuruma"

Regards,
Sergey



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

Bug#582692: dicod: failure when no match found

[Sergey Poznyakoff]

Marc Dequènes (Duck)  ha escrit:

> No, you're wrong, this is the right place to send a bug, so that the
> maintainer can check if it relevant,

You did not get the point: it's not about bugs.debian.org. It's about
the proper address to report Dico-related bugs to. The proper place
to report these bugs is to  *not* to
.

> But you're right, i should have tested this problem with the dico
> client instead. That's another good reason to filter reports before
> sending them to the author directly. I'm then reassigning this bug to
> the dict package, as it is not reproducible with the dico client
> ("dico --host=dico.duckcorp.org --noauth -m kuruma" works).

I see now. The report was worded such that it was unclear to me
that they were having the problem with their *server*, not the client
program. There's no use reassigning this bug, as `dict' client has
indeed nothing to do with it. The difference between operation of
`dict' and `dico' is that the former by default issues

 MATCH * . "kuruma"

whereas the latter issues

 MATCH ! . "kuruma"

You can easily reproduce this by connecting to dico.duckcorp.org:2628
and issuing the latter command. It will disconnect silently.

To handle this I need additional information, namely: any log messages
issued by dicod at dico.duckcorp.org and exact contents of the
configuration file that is used there. 

> or wait for the Debian maintainer to forward you the relevant bugs.

Once again, let me underline that any bug reports should be forwarded not
to "me", but to . Thank you.

Regards,
Sergey



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

Bug#582692: dicod: failure when no match found

[Sergey Poznyakoff]

Ahmed,

To begin with, please, send bug reports to the address !

Now to the matter:

> Using my dicod server:
> # dict dict://dico.duckcorp.org/m:kuruma
> dict (client_read_status): Error reading from socket
> client_read_status: Connection reset by peer

GNU Dico contains no program called "dict". Moreover, none of its
sources contain a symbol "client_read_status". Are you sure this
report is about GNU Dico???

Regards,
Sergey



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

Bug#576637: [Bug-cpio] Re: Bug#576637: cpio: FTBFS: multiple definition of `fatal_exit'

[Sergey Poznyakoff]

Clint Adams  ha escrit:

> The mt man page suggests that a fatal error should exit with a 2;
> mt's fatal_exit exits with a 1 (MT_EXIT_INVOP).
> 
> What is truly intended here?

The former: it shoud exit with code 2.  Thanks for reporting.

Regards,
Sergey



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

Bug#564181: Gnulib TP template out of date?

[Sergey Poznyakoff]

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" target, or something?

I've got a script I used to prepare previous versions. It is somewhat
raw to be included in gnulib right now. Allow me some time to
polish it:)

Regards,
Sergey





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

Bug#566752: [Bug-cpio] mt: setting data compression / datcompression - do you accept patches?

[Sergey Poznyakoff]

Sylvain Beucler  ha escrit:

> What is your (Sergey?) opinion on this patch?

Apart from some minor issues, it is OK. However, to
use a patch of that size I will need a FSF copyright assignment from
its author. Is it possible?

Regards,
Sergey



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

Bug#564259: [Bug-cpio] Re: Bug#564259: cpio: Cpio core dumps

[Sergey Poznyakoff]

Hi Nigel,

> No - I also use the v option:
> 
> find `cat usr/local/lib/dirs/usb` -mtime -7 -print | cpio -pvdu
> media/8313e1a8-e5d9-4e37-8bfb-f69dcb0af44c/

Thanks. Two more questions: does coredump occur always on the same
file? How many files/bytes (approximately) are archived before it
happens?

Regards,
Sergey



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

Bug#564259: [Bug-cpio] Re: Bug#564259: cpio: Cpio core dumps

[Sergey Poznyakoff]

Hi Clint,

> Sergey, Nigel is having a problem with cpio -pdu over NFS.

Thanks for the dump. Are -pdu the only options given to cpio?

Regards,
Sergey



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

Bug#221482: [Bug-tar] Faster excludes

[Sergey Poznyakoff]

Phil Proudman  ha escrit:

> From my point of view it passes all of the exclusion tests that I added
> in the tests directory (exclude01.at to exclude05.at), and it runs a bit
> quicker on my machine too, so cool!

Great, then. I'll push these changes to the new release, which is to
appear within 3-4 weeks. Many thanks for the idea and inspiration!

Regards,
Sergey




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

Bug#221482: [Bug-tar] Faster excludes

[Sergey Poznyakoff]

Hello,

I have re-implemented exclude support using a different algorithm.
It is slightly more compact and faster (on exclude05 test it showed
a gain of 12% execution time compared to the proposed patch), and
works correctly with multibyte file names.
Please try this snapshot:

   ftp://download.gnu.org.ua/pub/alpha/tar/tar-1.22.90-fe.tar.bz2

Any feedback will be much appreciated.

Regards,
Sergey




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

Bug#411485: [Bug-tar] Avoid undefined behavior of passing NULL to strcmp

[Sergey Poznyakoff]

Carl Worth  ha escrit:

> As it turns out, the bug may or may not a segmentation fault. To be
> precise, the code is passing a NULL pointer to strcmp,

Are you sure this applies to tar 1.21? I don't see any way how
the code in update_argv might result in NULL entries being
inserted in argv.

Regards,
Sergey



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

Bug#313237: [Bug-tar] Preserve timestamp of symlinks when extracting (if utimensat available)

[Sergey Poznyakoff]

Carl Worth  ha escrit:

> I've attached a patch that fixes the bug when utimensat is available,
> and should have no effect when the function is not available,

Thanks a lot. I'll need some time to test it.

Regards,
Sergey



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

Bug#221482: [Bug-tar] Faster excludes

[Sergey Poznyakoff]

Carl, Phil,

Thanks for the updated patch. After a quick glance I seem to have
fund some potential problems, but these could be easily fixed. I'll try
to come out with something definite by this weekend.

Regards,
Sergey



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

Bug#508199: [Bug-tar] --backup can destroy an extracted member when followed by an existing directory

[Sergey Poznyakoff]

Carl Worth  ha escrit:

> I've traced through the code a bit and the problem is due to the
> handling of directory entries in extract.c:extract_archive().

Thanks for the in-depth analysis. I have applied the attached patch.

Regards,
Sergey

>From 755c246588092d0b281cb610a8371c2c9b32de59 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff 
Date: Wed, 5 Aug 2009 10:38:50 +0300
Subject: [PATCH] Fix backup handling and restoring file modes of existing 
directories

* NEWS, THANKS: Update
* src/extract.c (extract_dir): reset status to 0 if the
directory already exists.
* src/misc.c (maybe_backup_file): Assign before_backup_name
and clear after_backup_name before checking if we really need
to backup the file.
* tests/backup01.at: New testcase.
* tests/extrac08.at: New testcase.
* tests/Makefile.am, tests/testsuite.at: Add extrac08.at and
backup01.at
---
 NEWS   |8 +++-
 THANKS |1 +
 src/extract.c  |1 +
 src/misc.c |   17 +
 tests/Makefile.am  |2 ++
 tests/backup01.at  |   49 +
 tests/extrac08.at  |   51 +++
 tests/testsuite.at |3 +++
 8 files changed, 123 insertions(+), 9 deletions(-)
 create mode 100644 tests/backup01.at
 create mode 100644 tests/extrac08.at

diff --git a/NEWS b/NEWS
index e9a31ca..9c15ad7 100644
--- a/NEWS
+++ b/NEWS
@@ -1,4 +1,4 @@
-GNU tar NEWS - User visible changes. 2009-05-25
+GNU tar NEWS - User visible changes. 2009-08-05
 Please send GNU tar bug reports to 
 
 
@@ -10,6 +10,12 @@ When listing or extracting archives, the actual record size 
is
 reported only if the archive is read from a device (as opposed
 to regular files and pipes).
 
+* Bugfixes
+** Fix handling of hard link targets by -c --transform.
+** Fix hard links recognition with -c --remove-files.
+** Fix restoring files from backup (debian bug #508199).
+** Correctly restore modes and permissions on existing directories.
+
 
 version 1.22 - Sergey Poznyakoff, 2009-03-05
 
diff --git a/THANKS b/THANKS
index dbb64d2..9d918ba 100644
--- a/THANKS
+++ b/THANKS
@@ -70,6 +70,7 @@ Burkhard Plache   pla...@krusty.optimax.ns.ca
 Calvin Cliff   cl...@trifid.astro.ucla.edu
 Cameron Elliottc...@mvbms.mvbms.com
 Carl Streeter  stree...@cae.wisc.edu
+Carl Worth  cwo...@cworth.org
 Carsten Heyl   h...@nads.de
 Catrin Urbanneck   c...@gppc.de
 Cesar Romani   rom...@ifm.uni-hamburg.de
diff --git a/src/extract.c b/src/extract.c
index 63f3525..5361506 100644
--- a/src/extract.c
+++ b/src/extract.c
@@ -682,6 +682,7 @@ extract_dir (char *file_name, int typeflag)
}
  if (S_ISDIR (st.st_mode))
{
+ status = 0;
  mode = st.st_mode;
  break;
}
diff --git a/src/misc.c b/src/misc.c
index 951449e..b609b86 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -417,6 +417,15 @@ maybe_backup_file (const char *file_name, bool 
this_is_the_archive)
 {
   struct stat file_stat;
 
+  assign_string (&before_backup_name, file_name);
+
+  /* A run situation may exist between Emacs or other GNU programs trying to
+ make a backup for the same file simultaneously.  If theoretically
+ possible, real problems are unlikely.  Doing any better would require a
+ convention, GNU-wide, for all programs doing backups.  */
+
+  assign_string (&after_backup_name, 0);
+
   /* Check if we really need to backup the file.  */
 
   if (this_is_the_archive && _remdev (file_name))
@@ -438,14 +447,6 @@ maybe_backup_file (const char *file_name, bool 
this_is_the_archive)
   && (S_ISBLK (file_stat.st_mode) || S_ISCHR (file_stat.st_mode)))
 return true;
 
-  assign_string (&before_backup_name, file_name);
-
-  /* A run situation may exist between Emacs or other GNU programs trying to
- make a backup for the same file simultaneously.  If theoretically
- possible, real problems are unlikely.  Doing any better would require a
- convention, GNU-wide, for all programs doing backups.  */
-
-  assign_string (&after_backup_name, 0);
   after_backup_name = find_backup_file_name (file_name, backup_type);
   if (! after_backup_name)
 xalloc_die ();
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 2001834..64b1730 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -52,6 +52,7 @@ TESTSUITE_AT = \
  append.at\
  append01.at\
  append02.at\
+ backup01.at\
  chtype.at\
  comprec.at\
  delete01.at\
@@ -67,6 +68,7 @@ TESTSUITE_AT = \
  extrac05.at\
  extrac06.at\
  extrac07.at\
+ extrac08.at\
  gzip.at\
  grow.at\
  incremental.at\
diff --git a/tests/backup01.at b/tests/backup01.at
new file mode 100644
index 000..538dd3d
--- /dev/null
+++ b/tests/backup01.at
@@ -0,0 +1,49 @@
+# Process this file with autom4te to create testsuite. -*- Autotest -*-
+
+# Test suite fo

Bug#325989: [Bug-cpio] Re: Bug#325989: cpio: -iv reports filename when "newer or same age version exists"

[Sergey Poznyakoff]

Clint Adams  ha escrit:

> > With 2.5-1.2 and before, the line "foo" was not present.  Only
> > files actually copied should be reported.

This behavior is consistent with that of GNU tar.

Regards,
Sergey



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

Bug#458079: [Bug-cpio] Re: Bug#458079: cpio 2.9.90-2

[Sergey Poznyakoff]

Clint Adams  ha escrit:

> This behavior also applies to cpio 2.10

Fixed in the repository.

Regards,
Sergey



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

Bug#188663: [Bug-tar] tar fails to preserve hard links with --remove-files

[Sergey Poznyakoff]

Carl Worth  ha escrit:

> A user of Debian noticed that tar (1.22) does not always preserve hard
> links when creating an archive with the --remove-files option.

Thanks for reporting.

> On Sun, 13 Apr 2003 15:45:27 -0400, Theodore Ts'o  wrote:
> > I'm pretty sure, by the way, that the problem is that tar is keying
> > off of the st_nlink to decide whether or not to do hard link
> > processing as an optimization.

Yes, that's right.

> I've attached two patches to fix this bug. The first implements Ted's
> suggestion, (using the hard links hash table for all files when the
> --remove-files option is in effect, regardless of the value of
> st_nlink).

This one is mostly OK, except that I don't see any reason to test the
remove_files_option value in file_count_links. This will unnecessarily
inflate the link_table and slow down archive creation.

I have installed the attached patch.

Regards,
Sergey

>From 5944f452b0e615a172a9f058877671ff6272abb8 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff 
Date: Thu, 30 Jul 2009 23:48:04 +0300
Subject: [PATCH] Fix hard links recognition with -c --remove-files

* src/create.c (dump_hard_link): Always look up in the link table
if remove_files_option is set. Patch suggested by Theodore Ts'o
.
(check_links): Remove extra newline from the warning message.
* tests/link02.at, tests/link03.at: New testcases.
* tests/Makefile.am (TESTSUITE_AT): Add link02.at and link03.at
* tests/testsuite.at: Include link02.at and link03.at
---
 src/create.c   |4 +-
 tests/Makefile.am  |2 +
 tests/link01.at|4 +-
 tests/link02.at|   52 
 tests/link03.at|   56 
 tests/testsuite.at |2 +
 6 files changed, 116 insertions(+), 4 deletions(-)
 create mode 100644 tests/link02.at
 create mode 100644 tests/link03.at

diff --git a/src/create.c b/src/create.c
index 245b6c3..1031cc2 100644
--- a/src/create.c
+++ b/src/create.c
@@ -1377,7 +1377,7 @@ static Hash_table *link_table;
 static bool
 dump_hard_link (struct tar_stat_info *st)
 {
-  if (link_table && st->stat.st_nlink > 1)
+  if (link_table && (st->stat.st_nlink > 1 || remove_files_option))
 {
   struct link lp;
   struct link *duplicate;
@@ -1468,7 +1468,7 @@ check_links (void)
 {
   if (lp->nlink)
{
- WARN ((0, 0, _("Missing links to %s.\n"), quote (lp->name)));
+ WARN ((0, 0, _("Missing links to %s."), quote (lp->name)));
}
 }
 }
diff --git a/tests/Makefile.am b/tests/Makefile.am
index da6cf0d..2001834 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -77,6 +77,8 @@ TESTSUITE_AT = \
  indexfile.at\
  ignfail.at\
  link01.at\
+ link02.at\
+ link03.at\
  listed01.at\
  listed02.at\
  long01.at\
diff --git a/tests/link01.at b/tests/link01.at
index 2bec558..5faf42e 100644
--- a/tests/link01.at
+++ b/tests/link01.at
@@ -1,7 +1,7 @@
 # Process this file with autom4te to create testsuite. -*- Autotest -*-
 
 # Test suite for GNU tar.
-# Copyright (C) 2004, 2007 Free Software Foundation, Inc.
+# Copyright (C) 2004, 2007, 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
@@ -31,7 +31,7 @@
 # http://lists.gnu.org/archive/html/bug-tar/2004-07/msg9.html
 
 AT_SETUP([link count gt 2])
-AT_KEYWORDS([link01])
+AT_KEYWORDS([hardlinks link01])
 
 AT_TAR_CHECK([
 mkdir directory
diff --git a/tests/link02.at b/tests/link02.at
new file mode 100644
index 000..756d48f
--- /dev/null
+++ b/tests/link02.at
@@ -0,0 +1,52 @@
+# Process this file with autom4te to create testsuite. -*- Autotest -*-
+
+# Test suite for GNU tar.
+# Copyright (C) 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
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+# Tar 1.22 failed to recognize last hard link when creating an archive with
+# the --remove-files option.
+#
+# Reported by: "Theodore Y. Ts'o" ,
+#  Carl Worth 
+# References:
+#   
+#   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=188663
+#   <1248955024.1545.1.ca...@yoom.home.cworth.org>
+#   http://lists

Bug#514936: [Bug-cpio] Re: Bug#514936: cpio does not use error codes on exit

[Sergey Poznyakoff]

Hi Clint,

Thanks for reminding me. I'll apply this patch.

Regards,
Sergey



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

Bug#440170: [Bug-tar] Bug#440170: tar: add new option --include (to complement --exclude)

[Sergey Poznyakoff]

Jari Aalto <[EMAIL PROTECTED]> ha escrit:

> Please read the whole mail carefully. The case is presented there.

It does not seem clear to me.

Regards,
Sergey


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

Bug#440170: [Bug-tar] Bug#440170: tar: add new option --include (to complement --exclude)

[Sergey Poznyakoff]

Jari Aalto <[EMAIL PROTECTED]> ha escrit:

> New option
> 
>   --include=
> 
> Would behave like the GLOB were attached to the end of command (filespec)

I don't see how using

  tar -cf archive --include='*.c'

would differ from

  tar -cf archive *.c

Regards,
Sergey



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

Bug#426802: [bug-mailutils] Bug#426802: mail $USER <&- sends junk

[Sergey Poznyakoff]

Dan Jacobson <[EMAIL PROTECTED]> ha escrit:

> sends a big wad of binary junk.
> 
> One must use  
> (I thought I reported this but cannot find it.)

Yes, you did.  I was unable to reproduce the bug on the CVS version,
though.  Have you tried it?

Regards,
Sergey


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

Bug#416701: [Bug-cpio] Bug#416701: cpio -tv vs. UTF-8 filenames

[Sergey Poznyakoff]

Dan Jacobson <[EMAIL PROTECTED]> wrote:

> With -t, adding -v causes one's UTF-8 filenames to become octal _with
> no switch available to correct the situation!_

Thanks for reporting. I'll fix it.

Regards,
Sergey


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

Bug#402179: [Bug-tar] Race condition in GNU tar test-suite

[Sergey Poznyakoff]

Alex Owen <[EMAIL PROTECTED]> wrote:

> The Debian Project seems to have found a bug in the tar test suite.
> The bug appears to be a race condition in tests/append02.at

It was fixed in version 1.16.1

Regards,
Sergey


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

Bug#373942: [Bug-cpio] Bug#373942: cpio: [L10N:DE] German PO file update

[Sergey Poznyakoff]

Holger Wansing <[EMAIL PROTECTED]> wrote:

> attached you find an updated german po file for cpio.

Thank you, the German localization of GNU cpio indeed requires an update.
However, as a GNU maintainer, I can only accept localizations
coming from an authorized source, which is the Free
Translation Project (http://www.iro.umontreal.ca/translation/HTML/).

Please, send your translation to their mailing list
<[EMAIL PROTECTED]> and ask them to incorporate
it to the TP.  You will find more information about the German
localization, including contact address of the latest translator, on
their page at http://www.iro.umontreal.ca/translation/registry.cgi?team=de

If you don't get a reply from the list or from the translator
himself, please contact the Team Leader Karl Eichwalder, whose address
you will find on the team page.

> Additionally I added a patch to the cpio.pot file which changes the
> postal address of the FSF to the new one.

This has already been updated in main.c

Thanks again for your work.

Regards,
Sergey


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

Bug#361077: [Bug-tar] Bug#361077: tar -x without -p of 777 directory alternately sets wrong mode

[Sergey Poznyakoff]

Ian Jackson <[EMAIL PROTECTED]> wrote:

> Attached is the patch which I have applied to Ubuntu's tar to fix the
> problem.  I'm pretty confident it's correct and you should probably
> apply it to Debian's GNU tar, and upstream GNU tar, too.

Thank you.
 
> Also, I noticed that if you attempt to extract a tarfile (at least,
> one which contains directories and files inside them) as non-root
> without -p with a umask which excludes 0100 or 0200, tar falls over
[...]
> However, I'm not
> sure whether this should be considered a bug or even a misfeature - a

I'd rather say it's a user problem.

Regards,
Sergey


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

Bug#335580: [Bug-cpio] cpio: checksum error on 64-bit machines

[Sergey Poznyakoff]

Clint Adams <[EMAIL PROTECTED]> wrote:

> Then I would suggest something like this, though it could be made more
> efficient.

Yes, I was thinking about a similar approach.

Thank you.

Regards,
Sergey


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

Bug#335580: [Bug-cpio] cpio: checksum error on 64-bit machines

[Sergey Poznyakoff]

Clint Adams <[EMAIL PROTECTED]> wrote:

> Is the objective to have 'crc' be 32-bit on all platforms?

The header stores only 4 bytes for crc, so it is quite reasonable.

Regards,
Sergey


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

Bug#309391: [bug-mailutils] Bug#309391: /etc/mail.rc: show CC by default

[Sergey Poznyakoff]

Jordi Mallach <[EMAIL PROTECTED]> wrote:

> On Wed, May 18, 2005 at 12:20:01PM +0300, Sergey Poznyakoff wrote:
> > > > # Display only these headers:
> > > > retain from to subject reply-to date
> > There is no such file in GNU mailutils distribution.
> 
> It was added by me in Debian as the default configuration for GNU mail.
> I think I got the example from this list a while ago.

Ah, OK.
 
> > > Segmentation fault
> > Try using recent version of mailutils.
> 
> I get this too with 1.6.1. Do you mean CVS?

Yes, I mean 0.6.90 (released today).

Regards,
Sergey


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

Bug#309391: [bug-mailutils] Bug#309391: /etc/mail.rc: show CC by default

[Sergey Poznyakoff]

Dan Jacobson <[EMAIL PROTECTED]> wrote:

> Package: mailutils
> Version: 1:0.6.1-1
> Severity: normal
> File: /etc/mail.rc
> > # Display only these headers:
> > retain from to subject reply-to date

There is no such file in GNU mailutils distribution.
 
> P.S., I see "[EMAIL PROTECTED]" on the Info page "program index".

Could you provide more detail, please?
 
> P.S. look what happens here:
> & !
> Segmentation fault

Try using recent version of mailutils.

Regards,
Sergey


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