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 PROTECT
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? Contac
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
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.
&
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"
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". Tr
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
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
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
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-bug
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 [-Werr
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
Update of patch #8925 (project tar):
Status:None => Done
Assigned to:None => gray
___
Follow-up Comment #1:
The patch is incorpora
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/htm
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 [EMA
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
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, em
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]
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-fil
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
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 "
32de59 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
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
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
w
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.
Regard
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.gn
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
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 ext
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
ãí¥ï ç¤¥í¥¨ïª 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 p
=?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 thi
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
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..
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"
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
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
w
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 impro
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
rkuma"
>
> 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
ãí¥ï ç¤¥í¥¨ïª 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
> 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 shoul
ãí¥ï ç¤¥í¥¨ïª 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
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.
ãí¥ï ç¤¥í¥¨ïª 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
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
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 fin
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",
ãí¥ï ç¤¥í¥¨ïª 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 UNSUB
ãí¥ï ç¤¥í¥¨ïª 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-
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
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 characte
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 the
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 list
ãí¥ï ç¤¥í¥¨ïª 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
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-r
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.
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
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
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.
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
dif
ãí¥ï ç¤¥í¥¨ïª 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-
ãí¥ï ç¤¥í¥¨ïª 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,
ãí¥ï ç¤¥í¥¨ïª 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...@l
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
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
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
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 "/
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
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
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, syst
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 a
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
72 matches
Mail list logo
