On 22/07/2016 09:02, Daniel Iancu wrote:
> Package: sed
> Version: 4.2.2-4+b1
> Severity: normal
>
> Sed silently fails when -n option is specified first and leaves
> the file blank. Thus resulting in the loss of the file contents.
> Example:
> # cd /tmp
> echo 'foo' > test
> sed
On 18/05/2015 03:54, Josh Triplett wrote:
On Thu, May 14, 2015 at 05:04:19PM +0200, Paolo Bonzini wrote:
OVMF used to place page tables in ROM, which works on real hardware,
and also works on VMs except:
- on AMD systems
- on Intel systems, if you have EPT page tables with A/D bits
On 14/05/2015 16:47, Josh Triplett wrote:
On Thu, May 14, 2015 at 10:40:34AM +0200, Paolo Bonzini wrote:
On 13/05/2015 22:15, j...@joshtriplett.org wrote:
Leaving aside the why KVM is in emulation mode, though, shouldn't
emulation mode support finit?
Yes, it should strive to support all
On 13/05/2015 22:15, j...@joshtriplett.org wrote:
On Wed, May 13, 2015 at 12:18:12PM +0200, Paolo Bonzini wrote:
On Mon, 11 May 2015 09:09:08 -0700 Josh Triplett j...@joshtriplett.org
wrote:
Decoding that instruction stream (either from those bytes, or via the
'x' command in the qemu
On Mon, 11 May 2015 09:09:08 -0700 Josh Triplett j...@joshtriplett.org
wrote:
Decoding that instruction stream (either from those bytes, or via the
'x' command in the qemu console) shows (starting with the failing
instruction):
0: 9b db e3finit
finit indeed is not
://bugs.debian.org/778737 -- at least debian can
be installed in x32 kvm.
And we don't lose anything really because it is a new arch.
That's why it was Cc'd -trivial.
Acked-by: Paolo Bonzini pbonz...@redhat.com
... but I'm not going to test it.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs
On 02/03/2015 16:22, Philippe Teuwen wrote:
It appears that I was wrong, it's not related to the version of sed but
to the terminal configuration:
echo '=abcABC[]\\_='|LANG=en_US.utf8 sed 's/[A-z]/*/g'
sed: -e expression #1, char 11: Invalid range end
echo '=abcABC[]\\_='|LANG=C sed
Il 03/10/2013 01:44, Gabriele Giacone ha scritto:
Package: sed
Version: 4.2.2-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
hurd doesn't define PATH_MAX and upstream decided not to set it themself
anymore
since 4.2.2. See
Il 16/06/2013 02:25, Stefan Pietsch ha scritto:
Bisecting leads to
git bisect bad 378a8b099fc207ddcb91b19a8c1457667e0af398
git bisect good 007a3b547512d69f67ceb9641796d64552bd337e
git bisect good 1f3141e80b149e7215313dff29e9a0c47811b1d1
git bisect good
Il 13/06/2013 07:57, Stefan Pietsch ha scritto:
git bisect tells me:
79fd50c67f91136add9726fb7719b57a66c6f763 is the first bad commit
This is an s390 commit, so the bisect somehow went wrong. Can you
confirm that 3.7 works and 3.8 doesn't?
Please check these pairs:
9e2d59a and
Il 13/06/2013 09:42, Paolo Bonzini ha scritto:
Il 13/06/2013 07:57, Stefan Pietsch ha scritto:
git bisect tells me:
79fd50c67f91136add9726fb7719b57a66c6f763 is the first bad commit
This is an s390 commit, so the bisect somehow went wrong. Can you
confirm that 3.7 works and 3.8 doesn't
Il 17/05/2013 16:57, Ralf Treinen ha scritto:
This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS
There are patches for these in the upstream sed repository.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Il 12/05/2012 22:39, majkls ha scritto:
Package: sed
Version: 4.2.1-7
Severity: important
This bactrace appeared repeately during update of texlive package however is
from sed:
Please reassign to glibc, it is the same bug as
https://bugzilla.redhat.com/show_bug.cgi?id=730952 (the
On 01/20/2012 11:45 AM, Vincent Lefevre wrote:
sed is inefficient on a regexp starting with (.*:
$ time sed -n s/\(.*49026\)/\1/p ChangeLog
2012-01-12 23:39:18 (rev 49026, vinc17/xvii)
4.62s user 0.00s system 99% cpu 4.637 total
Compare to the equivalent:
$ time sed -n s/^\(.*49026\)/\1/p
On 11/11/2011 10:28 PM, Regid Ichira wrote:
I expected sed -i '$p;$d' to output the last line, 2 in this case;
and to delete that line from the file.
No, the output of p goes directly to the output file even with sed
-i. You should use $w/dev/stdout instead of $p.
Paolo
--
To
On 11/12/2011 04:09 AM, Regid Ichira wrote:
$ sed -i '$w/dev/stdout;$d' testFile
sed: couldn't open file /dev/stdout;$d: Permission denied
Oops, sorry:
sed -i -e '$w/dev/stdout' -e '$d' testFile
Regardless, I am not sure whether one, who is fluent in the sed
language, should be
On 11/10/2011 06:55 PM, Regid Ichira wrote:
Package: sed
Version: 4.2.1-9
Severity: normal
I expected sed -i '$p;$d' to work. It doesn't.
sed -n '$p;$p' does work.
The result is correct, but you're not saying what you expect so we
cannot help.
Paolo
--
To UNSUBSCRIBE, email to
Applied upstream, thanks (commit dd275ee12aa73447748f269df2c899635a43e15b).
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
* src/dfa.c (setbit_case_fold): Remove, replace with...
(setbit_wc, setbit_c, setbit_case_fold_c): ... these.
(parse_bracket_exp): Use setbit_case_fold_c when iterating over
single-byte sequences. Use setbit_wc for multi-byte character sets,
and setbit_case_fold_c for single-byte character sets.
On Sat, Jun 4, 2011 at 09:48, Jim Meyering j...@meyering.net wrote:
The b2 == EOF part is required for the somewhat similar bug I fixed
a month ago:
fix a bug whereby echo c|grep '[c]' would fail for any c in 0x80..0xff
8da41c930e03a8635cbd8c89e3e591374c232c89
The corresponding test
On 06/02/2011 11:08 PM, Jim Meyering wrote:
#if MBS_SUPPORT
- int b2 = wctob ((unsigned char) b);
- if (b2 == EOF || b2 == b)
+ /* Below, note how when b2 != b and we have a uni-byte locale
+ (MB_CUR_MAX == 1), we set b = b2. I.e., in a uni-byte locale,
+ we can
On Fri, Jun 3, 2011 at 19:09, Jim Meyering j...@meyering.net wrote:
The b2 == EOF part is required for the somewhat similar bug I fixed
a month ago:
fix a bug whereby echo c|grep '[c]' would fail for any c in 0x80..0xff
8da41c930e03a8635cbd8c89e3e591374c232c89
Wouldn't that be covered
On 04/06/2011 09:28 PM, codeh...@debian.org wrote:
gnu-smalltalk appears in this list as a source package because one or
more of the binary packages (usually -dev packages) contain .la
files.
I believe this is just the libc.la which is not a normal .la file and
should not be removed.
Paolo
On 04/07/2011 12:17 PM, Thomas Girard wrote:
Hello,
Le 07/04/2011 09:10, Paolo Bonzini a écrit :
On 04/06/2011 09:28 PM, codeh...@debian.org wrote:
gnu-smalltalk appears in this list as a source package because one or
more of the binary packages (usually -dev packages) contain .la
files.
I
Yes, that's by design. Semicolons in filenames are valid (newlines
are too, but that would make it impossible to use the r command and
-f together).
The manual mentions: Commands within a script or script-file can be
separated by semicolons (;) or newlines (ASCII 10). Some commands, due
to their
Fixed in 3.2.4-1, please close.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 10/23/2010 09:49 AM, Kai YU wrote:
Hi, recently I noticed the Debain Bug #532541(
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532541). The problem
reported still exists in grep-2.7. I debugged the program, and found it was
introduce by the change of grep-2.5.3(
On 09/05/2010 05:28 PM, Alan W. Irwin wrote:
Issue: the p command prints out a pattern consisting of the matched line
as well as the next one.
DTH3 ADD_DATE=1278709936 LAST_MODIFIED=1283531292
PERSONAL_TOOLBAR_FOLDER=trueBookmarks Toolbar/H3
+DTH3 ADD_DATE=1278709936
upstream release 3.2.1 added a 1-minute timeout to all tests. This will
at the very least change the infinite loop into a failure and will
possibly show other failures.
The relevant commit is 06d7a0f2b5faea40ea8701b8772d8ef0841766bd.
On 06/06/2010 04:46 PM, Clint Adams wrote:
On Sun, Jun 06, 2010 at 12:08:59PM +0200, Josselin Mouette wrote:
Since it doesn’t seem to be trivially reproducible, I’d appreciate if
you could obtain a backtrace of the crashing sed process. See
http://wiki.debian.org/HowToGetABacktrace
Also
checkbashisms' output:
possible bashism in ./usr/share/gnu-smalltalk/vfs/urar line 73 ($RANDOM):
dir=tmpdir.${RANDOM}
possible bashism in ./usr/share/gnu-smalltalk/vfs/uzip line 94 ($RANDOM):
dir=$TMPDIR/uzip$$-$RANDOM
These are not needed for correctness. In particular, the
On 04/15/2010 10:06 AM, Lucas Nussbaum wrote:
Source: gnu-smalltalk
Version: 3.1-3
Severity: serious
Tags: squeeze sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20100415 qa-ftbfs
Justification: FTBFS on amd64
Hi,
During a rebuild of all packages in sid, your package failed to build
Could someone please try to reproduce the bug above with grep 2.6.
Fixed in grep git.
$ for i in '' -i -F -Fi; do ./grep -q $i foobar /tmp/test ; echo $?; done
0
0
0
0
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Not sure if I shouldn't have set severity to wishlist. Isn't now days, the
aggregated -in command line switches expected to get interpreted equivalently
to
-i -n ?
No, -i has an optional argument which is the backup file suffix, just
like -en != -e -n.
Paolo
--
To UNSUBSCRIBE, email to
121: Sport FAILED (testsuite.at:159)
122: Swazoo FAILED (testsuite.at:160)
Fixed by upstream patches
482e75acb44fcf652f29f21bb541e4b00ad5ba52
3d09834cf13e5b21b99e53c18bdac6806de9f4ab
ssed was a kind of experimentation ground for what became sed 4.0. If
you want to drop it altogether fine, but if not the NMU should really be
done to close this release criteria bug.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
4.2.1 copies ACL and security contexts, and provides a --follow-symlinks
option that can be used when breaking symbolic links is incorrect.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I don't recall if I already posted this; fixed upstream by commit 232557c9.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 12/08/2009 11:12 AM, Patrick Schoenfeld wrote:
if sed is used to in-place edit a*symlink* it is replacing
the symlink with a regular file. Thats probably okay (other tools
like perl do it the same way) but it could cause some problems.
For example if people who are not aware of that fact use
On 12/07/2009 08:15 AM, Clint Adams wrote:
Paolo,
We are suggesting the change below since SELinux will apparently be useless if
is_selinux_enabled() returns -1, and the warnings in that case are not clearly
helpful.
I'll take a look at coreutils but yes, I agree.
Paolo
--
To UNSUBSCRIBE,
If you fix the vulnerability please also make sure to include the
CVE id in your changelog entry.
fixed by the upstream patch 232557c9e5a24f5dbd18ad9a2106cafb74e4e0cf
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
On 12/07/2009 10:16 AM, Paolo Bonzini wrote:
On 12/07/2009 08:15 AM, Clint Adams wrote:
Paolo,
We are suggesting the change below since SELinux will apparently be
useless if is_selinux_enabled() returns -1, and the warnings in
that case are not clearly helpful.
I'll take a look at coreutils
On 11/25/2009 10:48 PM, Jeronimo Pellegrini wrote:
Package: gnu-smalltalk
Version: 3.0.3-2
Severity: normal
Hello,
GNU Smalltalk segfaults if I try to set the 100-th bit of
a number (maybe it could print an error message and fail
gracefully):
st 0 bitAt: 100 put: 1
The memory
In my opinion, the proper solution for sed would be:
1. --binary option should throw sed in a true binary mode without any
knowledge of UTF-8 or any other multibyte encodings. This would allow
to process binary files without any UTF-8 logic. And this would allow
direct manipulation of
From http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html
A period ( '.' ), when used outside a bracket expression, is a BRE
that shall match any character in the supported character set except
NUL.
My point here is that current implementation of regexes makes '.' NOT
Can the patch be applied as NMU?
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 10/15/2009 02:41 PM, WANG Yunfeng wrote:
Package: sed
Version: 4.2.1-3
Severity: critical
Justification: breaks unrelated software
I applied the patch upstream, thanks.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
This was bug 9697 in glibc's bugzilla, and is fixed by the patch at git
diff 4c2a6f3d 37bdc055ce^ in git://sources.redhat.com/git/glibc.git
(gitweb interface at http://repo.or.cz/w/glibc.git).
Another regex bug (bug 697 in glibc's bugzilla), by the way, is fixed by
the patch at git diff 37bdc055^
thomas wrote:
2008/12/30 Paolo Bonzini bonz...@gnu.org:
I don't think so, because the bug does not happen with sed from the
heirloom toolchest.
It probably implements its own regex matcher instead of using libc's.
Maybe. But two other GNU programs which probably use libc's regex
matcher
Something is strange: sed behaves correctly when the pattern begins
with an usual character. Look at this:
~$ sed 's/a[^a-z]/ax/g' a˚b# correct
axb
~$ sed 's/[^a-z]/x/g' a˚b# wrong
a˚b
I hope this last example helps.
Yes, it will help tracking down the bug (which is in libc,
Thomas wrote:
Package: sed
Version: 4.1.5-6
Severity: normal
For instance, take U+02E2 MODIFIER LETTER SMALL S:
$ echo ˢ | sed -r 's/[a-z]|[^a-z]//'
ˢ
Expected output: nothing.
Sed does not handle “ˢ” (U02E2) as a letter (in [a-z]) nor as a
“non-letter” (in [^a-z]).
The problem
I don't think so, because the bug does not happen with sed from the
heirloom toolchest.
It probably implements its own regex matcher instead of using libc's.
Paolo
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
It's already fixed in the git repository. *Could* be commit 7f53c1c but
I've not bisected it. In addition, commit 220e0fb adds the submitted
Cyrillic tests and a couple more.
I think sed 4.2 is no more than a couple of months away, so you can
wait. :-)
Paolo
--
To UNSUBSCRIBE, email to
Sed silently ignores (or what it does? - no info) invalid
multibyte sequences in the input: no halt, no message,
no false exit-code.
This is unfortunate but expected. . does not match a bad sequence,
see the fast path for UTF-8 in lib/regexec.c's check_node_accept_bytes:
returning 0 means
Johannes Wiedersich wrote:
[sorry, the previous mail was apparently truncated by a bug of my MUA.]
I'd suggest treating this bug as a documentation bug. sed's man page claims:
/---
-i[SUFFIX], --in-place[=SUFFIX]
edit files in place (makes backup if extension
I cannot reproduce the cobjects.st failure using the included libffi.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Oops, sorry, I was using a -O0 binary. I can reproduce it now. The fix
will go upstream.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Reduced testcase (reproducing on testdrive):
Object extend [
breakIt: anInteger [
category: 'instance creation'
1 to: anInteger do: [ :each | String new: each ].
]
]
#(4450 2) do: [:each | self breakIt: each].
Can you confirm? (Just do ./gst foo.st where foo.st is the
It's a dangling pointer that for no reason should show up rarely, and
for no reason should show up only on ia64, but it does.
Anyway the attached patch, which I'll commit upstream after some more
testing, fixes it. The idea is that a nomemory hook is now able to
divert the allocation to another
-result = 7.70
+result = 2305843009213693952.00
Will try to make a standalone testcase.
./testsuite.at:159: exit code was 139, expected 0
Can you get a backtrace (e.g. from a coredump)?
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Philipp Kern wrote:
On Fri, Sep 19, 2008 at 04:01:04PM +0200, Paolo Bonzini wrote:
-result = 7.70
+result = 2305843009213693952.00
Will try to make a standalone testcase.
./testsuite.at:159: exit code was 139, expected 0
Can you get a backtrace (e.g. from a coredump)?
If you tell
Philipp Kern wrote:
On Fri, Sep 19, 2008 at 05:58:39PM +0200, Paolo Bonzini wrote:
./libtool *copy_arguments_from_above* gdb --args gst -f scripts/Test.st
-vp Swazoo
gdb refuses to provide a backtrace, sadly:
what about a core dump (ulimit -c unlimited, then tests/gst -f
scripts/Test.st -vp
Petr Salinger wrote:
found 497033 3.1~rc3-2
thanks
Hi,
the builds fails with
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libgst -I../../lib-src -Wall -g
-O2 -Wall -Wdeclaration-after-statement -Wno-format -Wpointer-arith
-Wno-pointer-sign -Wwrite-strings -Wno-strict-aliasing -Wno-switch
The problem is obsolete config.h.in - it does not contain
/* Define to 1 if `sa_len' is member of `struct sockaddr'. */
#undef HAVE_STRUCT_SOCKADDR_SA_LEN
It have to be regenerated by debian/rules autotools.
Oops, that must be it. Is it okay if we wait for some buildd results
for alpha
With ./configure --disable-generational-gc only
117: Sport test fails.
Thanks. Can you remind me of what is the host triplet for GNU/kFreeBSD?
IMHO, failure in 117 is due to different
struct sockaddr_in between linux and BSDs.
In packages/tcp/IPSocketImpl.st, there is
Eval [
sa_len was always 0, but sa_family was set correctly. On little-endian
systems it's the other way round, and sa_family is set incorrectly to 0.
I'm now always passing to C sockaddrs with sa_len, and removing the
sa_len on platforms that do not have it.
2008-08-29 Paolo Bonzini [EMAIL PROTECTED
fixed in glibc upstream, see also bug 475474
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I stated in the beginning that it was too aggressive for \ as in the
sources, characters other than numbers fall into a default in a switch
statement without taking \ or into account, as I remember.
Is my understanding of the spec correct and is this indeed a bug of the
--posix option ?
Fixed by commit 4c4207c in the upstream git repository.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Paolo Bonzini wrote:
Fixed by commit 4c4207c in the upstream git repository.
Sorry -- by commit f11ba2ae
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Thomas Girard wrote:
Hello,
Le mardi 22 avril 2008 à 13:15 +0200, Paolo Bonzini a écrit :
It might be that rebuilding fixes the failure. I saw random failures of
Swazoo here too, it might be a race condition or something like that.
Paolo, could this error be fixed by the patch[1]?
Regards
It might be that rebuilding fixes the failure. I saw random failures of
Swazoo here too, it might be a race condition or something like that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is it about how you do recognize last line before script gets to
the end, i.e. '$' is next-to-last read() without EOF?
Yes. And that next-to-last bit is what forces sed to do its lookahead.
In the corner case if the line was read and then
network connection was dropped
... you don't care,
Oleg Verych wrote:
Package: sed
Version: 4.1.5-1
Severity: normal
Example: 'cycle 3' == 'first address 3' is lost:
Not a bug. sed starts a one-line lookahead behavior when $ is used.
You're right this is unnecessary for ADDR1,$ but it does not cause wrong
behavior -- the output is correct.
This is patch e022 from upstream:
2007-01-26 Paolo Bonzini [EMAIL PROTECTED]
* sed/compile.c (check_final_program): Don't set text if the
pending_text is initialized but empty.
* sed/execute.c (output_line): Don't print text if it is NULL.
diff --git a/sed/compile.c b
This is fixed in CVS sed.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The '/^$/' thing generally slows down processing very much. But it
should IMHO speed it up, because it skips empty lines before any
processing in particular part of the script.
Yes, this is a bug. The check that speeds up anchored search misdetects
/^$/ as a not-necessarily-anchored search.
'if EOF || Error' or 'if ! read-is-OK'
Latter applies for ordinary files also, no? No need of look ahead.
This is the next-to-last line, not the last line. sed does test for it,
but because the result would be off-by-one, it has to look ahead one line.
in interactive or line-by-line
patch sent upstream
http://lists.gnu.org/archive/html/bug-gnulib/2008-04/msg00097.html
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Lucas Nussbaum wrote:
Package: ssed
Version: 3.62-6.2
Severity: normal
Tags: patch
Hi,
Attached is the diff for my ssed 3.62-6.3 NMU.
I can confirm that the sed.sf.net site is the new home of ssed.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Bastian Blank wrote:
Package: gnu-smalltalk
Version: 2.3.3-3
Severity: important
There was an error while trying to autobuild your package:
I have a fix for it that I'm pushing right now to the arch repository.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
This is [EMAIL PROTECTED]/smalltalk--stable--2.3--patch-37
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
| config.status: linking ./src/ia64/ffitarget.h to include/ffitarget.h
| config.status: error: ./src/ia64/ffitarget.h: file not found
| configure: error: ./configure failed for libffi
| make: *** [configure-stamp] Error 1
The libffi/src/ia64/ffitarget.h is indeed missing in the smalltalk
The sed y command does not support character classes
(unlike tr); doing so would go against POSIX in ways that
cannot be reconciled.
Since both
echo Bübü Übü | LC_COLLATE=en_US.UTF-8 sed 's/[[:lower:]]/X/g'
and
echo Bübü Übü | LC_COLLATE=en_US.UTF-8 sed 'y/Ü/ü/'
should work in sed, this
In the build process of a different software sed is used like:
echo $version | sed 's/[\.\-_]/ /g'
but the build fails with:
sed: -e Ausdruck #1, Zeichen 13: Das Ende des angegebenen
Intervalls ist nicht gültig
The compilation scripts should set LANG=C. This is
Sed seems to be unable to handle the program /foo/i\\, interpreted
as a C string (that is, the two last characters of the program are i
and backslash; there's no newline).
Thanks, I'm committing a patch upstream.
Paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
can you test if this alternative patch works as well?
--- orig/pcre/regexec.c
+++ mod/pcre/regexec.c
@@ -1739,7 +1739,7 @@ pcre_exec (re, extra, subject, length, s
const uschar *bmtable = NULL;
const uschar *start_match;
const uschar *end_subject;
- const uschar *req_char_ptr =
Matthew Hooker wrote:
Package: gnu-smalltalk
Version: 2.1.8-2
Blox does not get built on non i386 architectures,
I'm trying to use it on powerpc. I have checked
the buildd logs and I can't see that it gets built
on anything other than i386.
The i386 version that gets built on buildd is
The binary for i386 does have blox-tk so gst-blox
works, I'll wade through the make files to see if I
can
locate what is preventing any actions in the blox-tk
directory.
There's something weird in detectinc TCL configuration from tclConfig.sh
file in 2.1.8-2, that has been fixed in
Justin Pryzby wrote:
Package: sed
Version: 4.1.2-8
Severity: minor
File: /usr/share/man/man1/sed.1.gz
Tags: patch
$ whatis awk sed
awk (1) - pattern scanning and processing language
sed (1) - manual page for sed version 4.1.2
It should probably be changed to
If I use sed -i to attempt to operate on a symlink in place, sed breaks
the symlink and creates a new file. I believe it should instead follow
the
symlink and edit the target file in place. After all, the man page
says:
No, this is intended behavior.
perl -i will work the same; also, not
See the attachment.
Paolo
--- orig/sed/regexp.c
+++ mod/sed/regexp.c
@@ -113,7 +113,7 @@ compile_regex_1 (new_regex, needed_sub)
{
char buf[200];
sprintf(buf, _(invalid reference \\%d on `s' command's RHS),
- needed_sub);
+ needed_sub - 1);
93 matches
Mail list logo
