ing that I got a
> non-zero return code, which caused my build to stop.
>
> On the face of it, the commands which were run all succeeded (114
> in tests, 29 in root-tests), but at the start of root-tests I also
> got the following message:
>
> /tools/bin/make -C test/ root-tes
ode, which caused my build to stop.
On the face of it, the commands which were run all succeeded (114
in tests, 29 in root-tests), but at the start of root-tests I also
got the following message:
/tools/bin/make -C test/ root-tests
make[1]: Entering directory '/building/attr-2.4.47/test'
Not
On Mar 19, 2014, at 10:30 PM, Insidious wrote:
> Bah. Unfortunately after that, the checks for chapter 6 binutils
> cause kernel panics in the host system. No idea why, the error
> messages aren't particularly instructive, and switching to an
> earlier kernel doesn't help. Giving up for now
Bah. Unfortunately after that, the checks for chapter 6 binutils cause
kernel panics in the host system. No idea why, the error messages aren't
particularly instructive, and switching to an earlier kernel doesn't help.
Giving up for now, but it was fun while it lasted.
On Wed, Mar 19, 2014 at 8:2
Alright, results of the make check after linking /lib64 to /lib, /usr/lib64
to /usr/lib, and /usr/local/lib64 to /usr/local/lib, cleaning, rebuilding,
and then checking:
make[2]: *** [/sources/glibc-build/libio/tst-ftell-partial-wide.out] Error 1
make[1]: *** [libio/tests] Error 2
make[2]: *** [/s
Did that and am running a make clean, make, and another check. Will come
back with results when it finishes
On Wed, Mar 19, 2014 at 2:39 PM, William Harrington
wrote:
>
> On Mar 19, 2014, at 1:30 PM, Insidious wrote:
>
> > I had a thought, since my linker reports itself to be in /tools/
> > lib6
On Mar 19, 2014, at 1:30 PM, Insidious wrote:
> I had a thought, since my linker reports itself to be in /tools/
> lib64, perhaps I should make a link from /usr/lib64 to /usr/lib?
> since no /usr/lib64 directory exists.
That is correct.
For some of the commands that pertain to x86_64 in the
Sorry about the mess, I had Digest Mode on for some silly reason.
Anyway, this is the output of ls -l /usr/lib
root:/sources/glibc-build# ls -l /usr/lib
total 4
lrwxrwxrwx 1 root root 22 Mar 18 20:25 libgcc_s.so ->
/tools/lib/libgcc_s.so
lrwxrwxrwx 1 root root 24 Mar 18 20:25 libgcc_s.so.1 ->
/
On 03/19/14 13:44, Insidious wrote:
> When following LFS-7.5 on my iMac G5, a powerpc64 system, I had great
> success until I got to chapter 6 glibc. It compiled correctly but when
> running the check a number of failures, only a small percentage of which
> are listed under "expected failures", wer
When following LFS-7.5 on my iMac G5, a powerpc64 system, I had great
success until I got to chapter 6 glibc. It compiled correctly but when
running the check a number of failures, only a small percentage of which
are listed under "expected failures", were reported.
These are the errors reported:
Ident((char*)malloc(size))[-1] = 0 output pattern test, should match
> is located 1 bytes to the left of 2726297600-byte
>
Ken,
I had a similar FAILED test to your #2. When running the test for
gcc-4.8.1 (in Section 6.17).
I'm also following LFS-7.4rc1 "by the book&quo
On Thu, Aug 22, 2013 at 01:13:45AM +0100, Ken Moffat wrote:
> On Wed, Aug 21, 2013 at 06:01:49PM -0500, Bruce Dubbs wrote:
> > Ken Moffat wrote:
> >
> > > 4. inetutils -
> > > Failed at pinging ::1.
> >
> > Do you have IPv6 enabled in the running kernel?
> >
> Not sure. I'll need to check and
On Thu, 2013-08-22 at 01:13 +0100, Ken Moffat wrote:
> On Wed, Aug 21, 2013 at 06:01:49PM -0500, Bruce Dubbs wrote:
> > Ken Moffat wrote:
> >
> > > 5. texinfo.
> > > FAIL: test_scripts/formatting_unknown_nodes_renamed.sh
> > >
> > > Not sure if Matt's patch fixes this.
> >
> > Don't know, but I
k log appears to have ended ok.
> > 2. gcc
> > Running /building/gcc-4.8.1/gcc/testsuite/g++.dg/asan/asan.exp ...
> > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest
> > Ident((char*)malloc(size))[-1] = 0 output pattern test, should match
> > is located
f all tests.
> 2. gcc
> Running /building/gcc-4.8.1/gcc/testsuite/g++.dg/asan/asan.exp ...
> FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest
> Ident((char*)malloc(size))[-1] = 0 output pattern test, should match
> is located 1 bytes to the left of 2726297600-b
..
FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest
Ident((char*)malloc(size))[-1] = 0 output pattern test, should match
is located 1 bytes to the left of 2726297600-byte
and
Running
/building/gcc-4.8.1/libmudflap/testsuite/libmudflap.c++/c++frags.exp
...
FAIL: libmudflap.c++/pas
Billy O'Connor wrote:
> Bruce Dubbs writes:
>
>> I've finally figured out what is making the mangle33.C program fail. It
>> is an arbitrary limitation in tcl. This particular gcc test creates a
>> c++ namespace *name* of 4044 characters in length. It turns o
Aleksandar Kuktin wrote:
>> On Sat, 30 Mar 2013 16:23:43 -0500
>> Bruce Dubbs wrote:
>>
>> I've finally figured out what is making the mangle33.C program fail.
>> It is an arbitrary limitation in tcl. This particular gcc test
>> creates a c++ namespace
Bruce Dubbs writes:
> I've finally figured out what is making the mangle33.C program fail. It
> is an arbitrary limitation in tcl. This particular gcc test creates a
> c++ namespace *name* of 4044 characters in length. It turns out that
> there is a value buried deep in
>On Sat, 30 Mar 2013 16:23:43 -0500
>Bruce Dubbs wrote:
>
> I've finally figured out what is making the mangle33.C program fail.
> It is an arbitrary limitation in tcl. This particular gcc test
> creates a c++ namespace *name* of 4044 characters in length. It
> turns
I've finally figured out what is making the mangle33.C program fail. It
is an arbitrary limitation in tcl. This particular gcc test creates a
c++ namespace *name* of 4044 characters in length. It turns out that
there is a value buried deep in tcl code (generic/regc_
Hi,
When building the systemd branch of LFS, one of the coreutils
tests fails:
FAIL: tests/df/skip-rootfs.sh
That test is skipped if `df' exits with nonzero code. This is
what happens on trunk LFS, because /etc/mtab is empty.
Now, on systemd branch, /etc/mtab is a symbolic link to
/proc
Ken Moffat wrote:
> On Thu, Feb 28, 2013 at 05:51:30PM -0600, Bruce Dubbs wrote:
>>
>> I'm not sure. The base code has:
>>
>> set pmap "${topdir}pmap"
>> set pmap_initname "1:\\s+\\S+\[^\\r\]+\\s+"
>> ...
>> set test &quo
ror 1 from
nptl/test-getpid2.out
and
rt/tst-cputimer1.out
and they both escalated to Error 2,
also posix/annexc.out and conform/run-conformtest.out which were
'(ignored)' as I expected.
For gcc I continue to get a lot of failures in gcc.c-torture which
seems normal for me, maybe it'
On Thu, Feb 28, 2013 at 05:51:30PM -0600, Bruce Dubbs wrote:
>
> I'm not sure. The base code has:
>
> set pmap "${topdir}pmap"
> set pmap_initname "1:\\s+\\S+\[^\\r\]+\\s+"
> ...
> set test "pmap X with unreachable process"
> spawn $pm
; ERROR: can't read "tty": no such variable
>>
>> I've seen this if trying in chroot without /dev mounted. It needs /proc
>> too.
>
> Just to confirm (finishing up the build-itself test at the moment),
> that I didn't get these two this time,
o such variable
>
> I've seen this if trying in chroot without /dev mounted. It needs /proc
> too.
Just to confirm (finishing up the build-itself test at the moment),
that I didn't get these two this time, but I did get the ERRORs for
kill and as you say, we suppress th
Hi,
When I build in a linux virtual console, one of the coreutils tests fails:
FAIL: tests/misc/stty-pairs.sh
It does not fail when building in an X terminal (xterm or konsole).
The reason is that some commands like:
stty parodd cs8
are performed, and the virtual console returns:
$ stty parodd
On Thu, Feb 28, 2013 at 03:08:18AM +, Ken Moffat wrote:
>
> - not my main problem at the moment - I'm now running it, but nfs
> (with updates) isn't working. Adding an /etc/netconfig (!) sort of
> helps, but rpcbind still isn't working. I'm seeing
> rpcinfo: can't contact portmapper: RPC: U
-e. Gave it what I thought
> > might be a fix (|| true), sailed through. Only later did I find
> > other tests failing (e.g. ld because of no static libs) and discover
> > that my attempted fix was ineffective ( set +e ... set -e works if
> > you want to save $? to record it in
; other tests failing (e.g. ld because of no static libs) and discover
> that my attempted fix was ineffective ( set +e ... set -e works if
> you want to save $? to record it in the logs or stamps ) and
> therefore the second run had not hit the same failure. I guess I'm
> incr
f no static libs) and discover
that my attempted fix was ineffective ( set +e ... set -e works if
you want to save $? to record it in the logs or stamps ) and
therefore the second run had not hit the same failure. I guess I'm
increasingly inclined to disregard the tests - sometimes they show a
Matt Burgess wrote:
> On Mon, 2012-08-20 at 19:18 -0500, Bruce Dubbs wrote:
>
>> That's the difference between Europeans and Americans. Americans only
>> speak/understand one language.
>
> And even then they don't speak it very well, unlike their British
> counterparts :-)
Our language, our rules
On 2012-08-21 08:06, Matt Burgess wrote:
> On Mon, 2012-08-20 at 19:18 -0500, Bruce Dubbs wrote:
>
>> That's the difference between Europeans and Americans. Americans
>> only
>> speak/understand one language.
>
> And even then they don't speak it very well, unlike their British
> counterparts :-)
On 8/21/2012 12:06 AM, Matt Burgess wrote:
> On Mon, 2012-08-20 at 19:18 -0500, Bruce Dubbs wrote:
>
>> That's the difference between Europeans and Americans. Americans only
>> speak/understand one language.
>
> And even then they don't speak it very well, unlike their British
> counterparts :-)
>
On Mon, 2012-08-20 at 19:18 -0500, Bruce Dubbs wrote:
> That's the difference between Europeans and Americans. Americans only
> speak/understand one language.
And even then they don't speak it very well, unlike their British
counterparts :-)
Matt.
--
http://linuxfromscratch.org/mailman/listi
Fernando de Oliveira wrote:
> Em 14-08-2012 22:31, Bruce Dubbs escreveu:
>
> Sometime before, Ken escreveu:
>
>>>Bryan, you were perspicacious. I've just spent a few hours
>>> re-energising my limited perl knowledge. First, to try to
>
>
>>
>> BTW, I had to look up perspicacious.
> Funny, th
Em 14-08-2012 22:31, Bruce Dubbs escreveu:
Sometime before, Ken escreveu:
>> Bryan, you were perspicacious. I've just spent a few hours
>> re-energising my limited perl knowledge. First, to try to
>
> BTW, I had to look up perspicacious.
>
>-- Bruce
>
Funny, this was the easiest pa
Bruce Dubbs wrote these words on 08/20/12 17:41 CST:
> I think we've got it fixed. Mailman issue. Thanks for the test.
I'm seeing almost instantaneous response now. Thanks for fixing the
problem, Bruce.
--
Randy
rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC)
Kevin Lyda wrote:
> On Mon, Aug 20, 2012 at 5:20 PM, Bruce Dubbs wrote:
>> My ping time from Texas to Canada is about 100ms. Could someone from
>> Europe test the response? (IP 216.171.237.234)
>
>>From a UPC cable connection in Ireland:
> ping -c 3 216.171.237
On Mon, Aug 20, 2012 at 5:20 PM, Bruce Dubbs wrote:
> My ping time from Texas to Canada is about 100ms. Could someone from
> Europe test the response? (IP 216.171.237.234)
>From a UPC cable connection in Ireland:
ping -c 3 216.171.237.234
PING 216.171.237.234 (216.171.237.234): 56 d
On Mon, 20 Aug 2012, Matt Burgess wrote:
> On Mon, 2012-08-20 at 16:21 -0500, Bruce Dubbs wrote:
>>
>> I think it's fixed.
> Yep, looks good from here too.
+1
Uwe
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above informa
ime from Texas to Canada is about 100ms. Could someone from
>> Europe test the response? (IP 216.171.237.234)
> Sure. From Germany I get:
> 175 ms from a dialup connection (1MBit/s)
> 181 ms from a hoster (100MBit/s)
Posted 165 minutes ago (18:44:59 UTC, successfully to 216.171.23
Matt Burgess wrote:
> On Mon, 2012-08-20 at 11:20 -0500, Bruce Dubbs wrote:
>> Bruce Dubbs wrote:
>>> Sending at 11:10 CDT (GMT+5)
>>
>> The parent message is in the mailman archives at 11:11. I emptied the
>> mailq before the test. The load on the system is
Matt Burgess wrote these words on 08/20/12 15:04 CST:
> Pings are about right here ~300ms. That said, I was checking my email
> this morning using the web client on quantum and it saw the same delay.
>
> Odd. I'll see how things go tonight. Thanks for taking a look!
FWIW, I have been seeing in
On Mon, 2012-08-20 at 11:20 -0500, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> > Sending at 11:10 CDT (GMT+5)
>
> The parent message is in the mailman archives at 11:11. I emptied the
> mailq before the test. The load on the system is 0.10.
>
> My ping time from Texas
verstating it. I looked at fedora - they
install with:
make install_root=$RPM_BUILD_ROOT install
and using install_root causes test-installation.pl to be ignored.
I guess it's just a hangover from the days when updating glibc was
shrouded in mystery.
Unless something comes back from bug 14476, I'
Bruce Dubbs wrote:
> Sending at 11:10 CDT (GMT+5)
The parent message is in the mailman archives at 11:11. I emptied the
mailq before the test. The load on the system is 0.10.
My ping time from Texas to Canada is about 100ms. Could someone from
Europe test the response? (IP 216.171.237.
Sending at 11:10 CDT (GMT+5)
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Ken Moffat wrote:
> On Sat, Aug 18, 2012 at 04:57:03PM +0100, Ken Moffat wrote:
>> On Sat, Aug 18, 2012 at 07:34:04AM +0200, g@free.fr wrote:
>>>
>>> I am with glibc-2.11 with chroot /etc/localtime as a copy of real
>>> /etc/localtime.
>>>
>>
On Sat, Aug 18, 2012 at 04:57:03PM +0100, Ken Moffat wrote:
> On Sat, Aug 18, 2012 at 07:34:04AM +0200, g@free.fr wrote:
> >
> > I am with glibc-2.11 with chroot /etc/localtime as a copy of real
> > /etc/localtime.
> >
> > I don't see test failures in s
Paul Eggert wrote:
> On 08/16/2012 10:30 PM, Bruce Dubbs wrote:
>> When we run the tests, we can change our procedures to set any TZ needed.
>
> Could you please try it with TZ='EST5EDT,M3.2.0,M11.1.0'?
> If that works, we can change the test program to use that
>
ably be a sed. This is really a complex mechanism, and fixing the
> generation of soversions.mk really isn't necessary if we just delete the
> unneeded call to test-installation.pl (as done now in svn). I don't see
> any other use of soversions.mk in the code.
>
> Anoth
the current glibc build,
either 32 or 64.
$$lib (translated to $lib) is set in the environment and is defined at
line 832 from the read of soversions.i as 'ld'. Likewise $$number is
'ld.so.1' from the same read. Translating, we get:
echo "$$lib.so-version=\$$(if
\$$(
Bruce Dubbs wrote:
> Ken Moffat wrote:
>> On Wed, Aug 15, 2012 at 04:56:06PM +0100, Ken Moffat wrote:
>>> For the moment, please don't treat this as a priority. I've been
>>> distracted by other things today and am nowhere near confirming that
>>> it is indeed a perl-5.16 problem. If it isn't c
On Wed, 2012-08-15 at 17:54 -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> > On Wed, Aug 15, 2012 at 04:56:06PM +0100, Ken Moffat wrote:
> >> For the moment, please don't treat this as a priority. I've been
> >> distracted by other things today and am nowhere near confirming that
> >> it is ind
t
> why packages are now using gnulib instead of our headers (the gets
> seds). At the moment, I'm out of my depth.
How long have these packages been using their own version of gnulib? As
a developer, I can see why they might want to have control over that
package by including their o
ate for this
version of glibc. So, it removes much of the purpose in running the
testsuites. Perhaps it's a similar issue to Bryan's question about
why packages are now using gnulib instead of our headers (the gets
seds). At the moment, I'm out of my depth.
In passing, I was
7;s an environment variable
> >> and is incompatible with the perl script. That's why we remove it with
> >> a sed expression.
> >>
> > Are we at cross-purposes ?
>
> I don't think so. Am I missing something?
>
I read your reply as &
with
>> a sed expression.
>>
> Are we at cross-purposes ?
I don't think so. Am I missing something?
> All I can see, as of about 24 hours
> ago, is a sed to ensure that the Makefile line to run
> test-installation.pl is deleted.
Right. Because it doesn't
poses ? All I can see, as of about 24 hours
ago, is a sed to ensure that the Makefile line to run
test-installation.pl is deleted.
Anyway, I forgot to note which previous sed I'm using for the successful
run -
DL=$(readelf -l /bin/sh | sed -n 's@.*interpret.*/tools\(.*\)]$
> Bryan, you were perspicacious. I've just spent a few hours
> re-energising my limited perl knowledge. First, to try to
> instrument test-installation.pl, then to understand what is
> happening.
>
> When the ld.so regexp triggers on x86_64, the line contains:
> l
On Sun, Jul 01, 2012 at 11:21:44AM -0700, Bryan Kadzban wrote:
> Fun fun fun. :-)
>
> Andrew Benton wrote:
> > test-installation.pl failed with an error:
> >
> > root:/sources/glibc-2.16.0# CC="gcc" /usr/bin/perl
> > scripts/test-installation.pl /so
ut
>> others built it from different base systems.
>
> Thanks.
>
> Was that lfs-7.0/linux-3.0.4 on bare-metal?
Yes.
> And, did you notice the same readlink issue with gettext (see prev)?
http://www.linuxfromscratch.org/lfs/build-logs/7.1/core2duo/test-logs/
Yes.
-- Bru
On Mar 10, 2012, at 7:29 AM, Bruce Dubbs wrote:
> Qrux wrote:
>
>> Bruce, et al, was the 7.1-release built from 7.0-release on bare-metal? VM?
>> Non-LFS host?
>
> My particular 7.1 system was built on 7.0 with a 3.0.4 kernel, but
> others built it from different base systems.
Thanks.
Was
Qrux wrote:
> Bruce, et al, was the 7.1-release built from 7.0-release on bare-metal? VM?
> Non-LFS host?
My particular 7.1 system was built on 7.0 with a 3.0.4 kernel, but
others built it from different base systems.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
On Mar 10, 2012, at 1:45 AM, Pierre Labastie wrote:
> Le 10/03/2012 09:57, Pierre Labastie a écrit :
>> Sorry, I really meant the tests pass. I didn't send the
>> not-so-informative result of the test:
>> PASS: test-readlink.
>>
>> Whatever I do, I never se
Le 10/03/2012 09:57, Pierre Labastie a écrit :
> Sorry, I really meant the tests pass. I didn't send the
> not-so-informative result of the test:
> PASS: test-readlink.
>
> Whatever I do, I never see an error. Even with the 3.2.6 kernel built
> with LFS. I used 7.1, bu
re using
>> openSUSE-12.1, you should see this error if you run the tests for m4--I did.
>>
> Sorry, I really meant the tests pass. I didn't send the
> not-so-informative result of the test:
> PASS: test-readlink.
Not at all--I was just trying to clarify my own position
r m4--I did.
>
Sorry, I really meant the tests pass. I didn't send the
not-so-informative result of the test:
PASS: test-readlink.
Whatever I do, I never see an error. Even with the 3.2.6 kernel built
with LFS. I used 7.1, but without the patch, of course... Maybe it is
because everythin
On Mar 9, 2012, at 8:21 PM, Bruce Dubbs wrote:
> Qrux wrote:
>> Howdy.
>>
>> In trying to build LFS-7.0 with LFS-7.0, I'm getting this error:
>>
>> FAIL: test-readlink (exit: 134) ===
>
> Did you see: http://lists.gnu.o
Qrux wrote:
> Howdy.
>
> In trying to build LFS-7.0 with LFS-7.0, I'm getting this error:
>
> FAIL: test-readlink (exit: 134) ===
>
> test-readlink.h:41: assertion failed
>
> It seems to be a fairly well-known issue:
>
> http:
On Mar 9, 2012, at 6:25 AM, g@free.fr wrote:
>> sed -i -e '41s/ENOENT/& || errno == EINVAL/' tests/test-readlink.h
>>
>> OOH, it doesn't appear to be a "huge issue", so the sed is
>> nice...OTOH, it's still a red flag be
Le 09/03/2012 14:53, Qrux a écrit :
> 1) Does anyone else see this in either 7.0 or 7.1 when building LFS from
> their host platform?
no
> 2) Does anyone see this when building 7.0 (or 7.1) from 7.0?
not tried
> 3) Does anyone see this when building 7.1 from 7.1?
no. I just tried buiding m4 from 7
Le 09/03/2012 14:53, Qrux a écrit :
> Howdy.
>
> In trying to build LFS-7.0 with LFS-7.0, I'm getting this error:
>
> FAIL: test-readlink (exit: 134)
> ===
> [...]
> OOH, it doesn't appear to be a "huge issue", so
- Mail original -
> De: "Qrux"
> À: "LFS Developers Mailinglist"
> Envoyé: Vendredi 9 Mars 2012 14:53:02
> Objet: [lfs-dev] m4 test error
>
> Howdy.
>
> In trying to build LFS-7.0 with LFS-7.0, I'm getting this
Howdy.
In trying to build LFS-7.0 with LFS-7.0, I'm getting this error:
FAIL: test-readlink (exit: 134)
===
test-readlink.h:41: assertion failed
It seems to be a fairly well-known issue:
http://old.nabble.com/test-readlink-fa
On Wed, 22 Feb 2012 10:02:24 +0100, Pierre Labastie
wrote:
> Should be corrected in current upstream patch list. Do not know
> if you LFS devs think it is a big issue (having math.h needlessly
> included when ncurses C++ bindings are used). I suggest
> waiting for the next release of ncurses.
Y
Le 21/02/2012 21:51, Andrew Benton a écrit :
> On Tue, 21 Feb 2012 09:47:00 +0100
> Pierre Labastie wrote:
>
>> Hi,
>>
>> I have done a test of LFS-7.1-rc1. ICA went OK, except the
>> already reported problem with ld.so.cache (ldconfig still missing
>> s
On Tue, 21 Feb 2012 09:47:00 +0100
Pierre Labastie wrote:
> Hi,
>
> I have done a test of LFS-7.1-rc1. ICA went OK, except the
> already reported problem with ld.so.cache (ldconfig still missing
> somewhere), which is not a big issue. In case somebody else
> does ICA, there
On Tue, 21 Feb 2012 09:47:00 +0100
Pierre Labastie wrote:
> Hi,
>
> I have done a test of LFS-7.1-rc1. ICA went OK, except the
> already reported problem with ld.so.cache (ldconfig still missing
> somewhere), which is not a big issue. In case somebody else
> does ICA, there
Hi,
I have done a test of LFS-7.1-rc1. ICA went OK, except the
already reported problem with ld.so.cache (ldconfig still missing
somewhere), which is not a big issue. In case somebody else
does ICA, there is this difference in etip.h between ICA
iterations 1 and 2
On Thu, 2012-01-26 at 03:17 -0700, Matthew Burgess wrote:
> On Thu, 26 Jan 2012 10:11:26 +, Firerat wrote:
> > Hi
> > I noticed a small problem with kmod-4 in the current svn ( 9714 )
> > the book details
> >
> > ./test/test-loaded
> >
> >
On Thu, 26 Jan 2012 10:11:26 +, Firerat wrote:
> Hi
> I noticed a small problem with kmod-4 in the current svn ( 9714 )
> the book details
>
> ./test/test-loaded
>
> to perform tests, however for me this fails ( no file found )
> if I instead do
>
>
Hi
I noticed a small problem with kmod-4 in the current svn ( 9714 )
the book details
./test/test-loaded
to perform tests, however for me this fails ( no file found )
if I instead do
make check
the tests are performed
--
Firerat
Talented, Witty And Thoughtful .. is how most describe
at the ulimit-s 16384 is not enough for passing the tests
> with the current version of gcc. See
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827#c11.
Sine the issues appear to be fixed and these are only test issues, I
think we should just wait for the next version of glibc.
-
Hi,
Regarding the "posix/bug-regex32"error in glibc tests, I found
http://sourceware.org/bugzilla/show_bug.cgi?id=13118
Maintainer says he has applied the patch, but I checked that Glibc-2.14.1
tarball still lacks the correction.
Not sure it is worth considering including the patch (or adding a
about committing it, but I'd rather wait to find
> > out if it is needed, or if is highlighting an environmental problem.
> > Earlier parts of the test program spewed out variosu locale names
> > when I defined DEBUG, although LOCALE_ZH_CN was shown as 'none'.
> &
s highlighting an environmental problem.
> Earlier parts of the test program spewed out variosu locale names
> when I defined DEBUG, although LOCALE_ZH_CN was shown as 'none'.
> I've installed all the locales, hopefully that doesn't make a
> difference to this particula
On Mon, Nov 21, 2011 at 11:43:45AM -0600, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >
> > Fortunately, google knew about this - it's an error in the test
> > handling of daylight saving time, which has been fixed in gnulib
> > and pulled into upstream coreutils.
Ken Moffat wrote:
> During my build of a 7.0 system, coreutils failed the test of
> test-parse-datetime and stopped my build (assertion failure in line
> 142 of the .c file - result did not match expected value). I never
> did manage to find out what result it got, setting
During my build of a 7.0 system, coreutils failed the test of
test-parse-datetime and stopped my build (assertion failure in line
142 of the .c file - result did not match expected value). I never
did manage to find out what result it got, setting DEBUG in the
environment dumped some information
Small bug due to new kernels (since 2.6.39.1) where the m4 'make
check' has a test failure in test-readlink. Apparently the newer
kernels are returning EINVAL when readlink() is called with a null
string "". The previous behavior was returning ENOENT.
According to the se
>> paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir runcon
>> seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep
>> sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr
>> true truncate tsort tty uname unexpand uniq unlink
seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep
> sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr
> true truncate tsort tty uname unexpand uniq unlink users vdir wc who
> whoami yes
> \ No newline at end of file
Cool, so that has accurately
n
logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc od
paste pathchk pinky pr printenv printf ptx pwd readlink rm rmdir runcon
seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep
sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr
true trunc
Matthew Burgess wrote:
> Thanks for the reports guys. Would you mind running the following script
> for me please and let me know what you get? On my builds, all 10 of the
> no-patch builds produce the correct built-programs, and all 10 of the
> patch builds produce the incorrect built-programs.
On Tue, 19 Apr 2011 07:44:07 -0500, DJ Lucas wrote:
> On 04/18/2011 07:56 PM, Bruce Dubbs wrote:
>> Matthew Burgess wrote:
>>> On Mon, 18 Apr 2011 12:56:42 -0600 (MDT), matt...@linuxfromscratch.org
> wrote:
>>>
Log:
Upgrade to Coreutils-8.11. Fixes #2858.
>>> Note that I'm currently tryi
On 04/18/2011 07:56 PM, Bruce Dubbs wrote:
> Matthew Burgess wrote:
>> On Mon, 18 Apr 2011 12:56:42 -0600 (MDT), matt...@linuxfromscratch.org wrote:
>>
>>> Log:
>>> Upgrade to Coreutils-8.11. Fixes #2858.
>> Note that I'm currently trying to figure out what broke 2 tests with this
>> upgrade. misc
Matthew Burgess wrote:
> On Mon, 18 Apr 2011 12:56:42 -0600 (MDT), matt...@linuxfromscratch.org wrote:
>
>> Log:
>> Upgrade to Coreutils-8.11. Fixes #2858.
>
> Note that I'm currently trying to figure out what broke 2 tests with this
> upgrade. misc/help-version and misc/invalid-opt are failing
1 - 100 of 324 matches
Mail list logo
