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,
> 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 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 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
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,
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
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,
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
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 sch...@linux-m68k.org 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
Norbert Preining prein...@logic.at 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
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 hill...@web.de 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
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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?
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
=?utf-8?B?2KPYrdmF2K8g2KfZhNmF2K3ZhdmI2K/Zig==?= aelmahmo...@sabily.org 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
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
will
provide a solution for this latter.
Regards,
Sergey
From 9b10f09671e8498ee9862bd9190fc1fb324e35e7 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff g...@gnu.org.ua
Date: Mon, 24 May 2010 14:26:00 +0300
Subject: [PATCH] Speed up output procedure in dictorg.
Provide a general-purpose mechanism to address
Marc Dequènes (Duck) d...@duckcorp.org 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
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 g...@gnu.org.ua
Date: Sun, 23 May 2010 14:50:12 +0300
Subject: [PATCH
Marc Dequènes (Duck) d...@duckcorp.org 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
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 g...@gnu.org.ua
Date: Sun, 23 May 2010 14:52:13 +0300
Subject: [PATCH] Avoid using fixed-size buffer
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
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
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
Sergey Poznyakoff g...@gnu.org.ua ha escrit:
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
Marc Dequènes (Duck) d...@duckcorp.org 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
Marc Dequènes (Duck) d...@duckcorp.org 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
Marc Dequènes (Duck) d...@duckcorp.org ha escrit:
Same request with my server and the 2 patches from #582692 and #582708
applied:
http://dico.duckcorp.org/?q=Housedb=en-wikipediadefine=1
(but it gives the same result if i try house and click on any link
from the mediawiki backend)
= No
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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,
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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,
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) d...@duckcorp.org 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).
Marc Dequènes (Duck) d...@duckcorp.org 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
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
ãí¥ï ç¤¥í¥¨ïª aelmahmo...@sabily.org 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
Marc Dequènes (Duck) d...@duckcorp.org 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
Ahmed,
To begin with, please, send bug reports to the address bug-d...@gnu.org.ua!
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
Marc Dequènes (Duck) d...@duckcorp.org 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
Sergey Poznyakoff g...@gnu.org.ua 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
Clint Adams sch...@debian.org 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
Karl Berry k...@freefriends.org 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
Sylvain Beucler b...@gnu.org 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
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
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?
Phil Proudman p...@proudman51.freeserve.co.uk 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
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:
755c246588092d0b281cb610a8371c2c9b32de59 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff g...@gnu.org.ua
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
Carl Worth cwo...@cworth.org 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
Carl Worth cwo...@cworth.org 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
Clint Adams sch...@debian.org 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 sch...@debian.org 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
the attached patch.
Regards,
Sergey
From 5944f452b0e615a172a9f058877671ff6272abb8 Mon Sep 17 00:00:00 2001
From: Sergey Poznyakoff g...@gnu.org.ua
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
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
Jari Aalto [EMAIL PROTECTED] ha escrit:
New option
--include=GLOB
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,
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]
Dan Jacobson [EMAIL PROTECTED] ha escrit:
sends a big wad of binary junk.
One must use /dev/null instead to send an empty message.
(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,
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.
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.
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
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
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
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]
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
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
71 matches
Mail list logo
