On 1 April 2014 14:03, Armin K. wrote:
> On 04/01/2014 02:11 PM, Robin wrote:
>>>From nohup.log:
>> + test -w /dev/full
>> + test -c /dev/full
>> + exec
>> ./tests/misc/nohup.sh: line 66: /dev/tty: No such device or address
>> + fail=1
>>
>>
On 04/01/2014 02:11 PM, Robin wrote:
>>From nohup.log:
> + test -w /dev/full
> + test -c /dev/full
> + exec
> ./tests/misc/nohup.sh: line 66: /dev/tty: No such device or address
> + fail=1
>
> Found discussion at
> https://lists.gnu.org/archive/html/guix-devel
>From nohup.log:
+ test -w /dev/full
+ test -c /dev/full
+ exec
./tests/misc/nohup.sh: line 66: /dev/tty: No such device or address
+ fail=1
Found discussion at
https://lists.gnu.org/archive/html/guix-devel/2014-03/msg00017.html
Patch discussed
http://lists.gnu.org/archive/html/bug-coreutils/2
Ronnie van Aarle wrote:
> Hello Support,
>
> I just compiled bc but after 'make' there still is no 'bc' binary
> executable in ./bc
> after make install the tests run, but not before.
Did you log the install? It should have:
/usr/bin/install -c 'bc' '/usr/bin/bc'
That's what installs bc.
-
Hello Support,
I just compiled bc but after 'make' there still is no 'bc' binary
executable in ./bc
after make install the tests run, but not before.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above informati
Bernard Hurley wrote:
>
> Hi all,
>
> Perl fails one test in the test suite. The output form:
>
> $ ./perl -MTestInit dist/IO/t/io_udp.t
>
> is:
>
> ==snip
> 1..7
> ok 1
> ok 2
> ok 3
> ok 4
> not ok 5
> # Failed
Hi all,
Perl fails one test in the test suite. The output form:
$ ./perl -MTestInit dist/IO/t/io_udp.t
is:
==snip
1..7
ok 1
ok 2
ok 3
ok 4
not ok 5
# Failed test 5 - at dist/IO/t/io_udp.t line 64
ok 6
ok 7
==snip
I after running
`/sources/binutils-build/ld'
> make[2]: Leaving directory `/sources/binutils-build/ld'
> make[2]: Entering directory `/sources/binutils-build/libiberty'
> make[3]: Entering directory `/sources/binutils-build/libiberty/testsuite'
> ./test-demangle < ../../../binuti
g directory `/sources/binutils-build/ld'
make[2]: Leaving directory `/sources/binutils-build/ld'
make[2]: Entering directory `/sources/binutils-build/libiberty'
make[3]: Entering directory `/sources/binutils-build/libiberty/testsuite'
./test-demangle < ../../../binutils-2.23
t;>
>>
>> That is interesting. And very puzzling. For me, I don't shut down
>> networking on the host (why would anyone do that ?), but I think that
>> test has always failed for me since it was introduced - it's fairly
>> recent.
>
>Right. The
hat machine with me here at work - so I will
>> check later.
>>
>
> That is interesting. And very puzzling. For me, I don't shut down
> networking on the host (why would anyone do that ?), but I think that
> test has always failed for me since it was introduced -
ill
> check later.
>
That is interesting. And very puzzling. For me, I don't shut down
networking on the host (why would anyone do that ?), but I think that
test has always failed for me since it was introduced - it's fairly
recent.
Similarly, I get an ignored Error for posix
On Mon, 28/10/13, Ken Moffat wrote:
> >
> > I have inferred from the book that 'cputimer1' and 'run-conformtest' might
> > be 'acceptable' failures, but I was surprised that the test suite ended
> > mid-way.
> >
>
> Why
n the glibc fall into the acceptable variety or not.
>
> glibc appeared to build well enough. Having tried the test suites (with
> TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with:
>
> AWK='gawk' scripts/check-local-headers.sh \
> "/
On Mon, 28/10/13, Bruce Dubbs wrote:
>
> > I have inferred from the book that 'cputimer1' and 'run-conformtest'
> > might be 'acceptable' failures, but I was surprised that the test
> > suite ended mid-way.
>
> It didn't. It finish
ety or not.
>
> glibc appeared to build well enough. Having tried the test suites
> (with TIMEOUTFACTOR=16 - this is a humble machine), the make - k
> check ends with:
> /source/glibc-build/begin-end-check.out make[1]: Target `check' not
> remade because of errors. make[1]: Leavi
Le 28/10/2013 14:07, Richard a écrit :
> [...]
>
> Any advice would be welcome.
I cannot tell you much about what the tests. Are you sure they did not
run to completion?
>
> I am also assuming that glibc is one of the packages that can safely be
> installed to a fake root - then tarballed 'slackw
. Having tried the test suites (with
TIMEOUTFACTOR=16 - this is a humble machine), the make - k check ends with:
AWK='gawk' scripts/check-local-headers.sh \
"/usr/include" "/source/glibc-build/" >
/source/glibc-build/check-local-headers.out
/usr/bin/perl scrip
ld.conf file called
check_commands, but that shouldn't make any difference--I think.
Now that I think about it, the test suite didn't run for very long.
Maybe 1/2-3/4 hr. I was doing something else. I was really surprised
when I found the file I make from grepping glibc-check-log
On Oct 23, 2013, at 6:24 PM, Dan McGhee wrote:
> make -k check 2>&1 | tee glibc-check-log
> grep Error glibc-check-log
What as the output when running make -k check?
Sincerely,
William Harrington
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/l
at shouldn't make any difference--I think.
Now that I think about it, the test suite didn't run for very long.
Maybe 1/2-3/4 hr. I was doing something else. I was really surprised
when I found the file I make from grepping glibc-check-log empty. Yup,
no info. And the glibc
Liam Fleming wrote:
> after a thorough search online I have not managed to find any other
> instance of this problem, but when I run the testsuite for
> Binutils-2.23.1 I recieve a single unexpected failure on gas/i386/rept
> due to a timeout, here is the relevant log entry:
>
> ../as-new -o dump
after a thorough search online I have not managed to find any other
instance of this problem, but when I run the testsuite for
Binutils-2.23.1 I recieve a single unexpected failure on gas/i386/rept
due to a timeout, here is the relevant log entry:
../as-new -o dump.o /sources/binutils-2.23.1/gas
Hi all,
I have failure on inetutil test which I have not found in the archives:
* lfs book V7.3
* host distribution: CentOS 6.2 minimal (+ few trivial packages)
* if needed i will send separately the host packages version
* the failed is on the test suite of inetutil-1.9.1
* i didn't c
Philippe Delavalade wrote:
> Hi all.
>
> In chapter 6 when building gcc, to have a view from the test suite, it is
> said to issue
> ../gcc-4.8.0/contrib/test_summary | grep -A7 Summ
>
> My problem is that it is too large for the screen and less or more are not
> installed
Le jeudi 06 juin à 16:03, William Harrington a écrit :
>
> On Jun 6, 2013, at 7:45 AM, Philippe Delavalade wrote:
>
> > Hi all.
> >
> > In chapter 6 when building gcc, to have a view from the test suite,
> > it is
> > said to issue
> > ../g
On Jun 6, 2013, at 7:45 AM, Philippe Delavalade wrote:
> Hi all.
>
> In chapter 6 when building gcc, to have a view from the test suite,
> it is
> said to issue
> ../gcc-4.8.0/contrib/test_summary | grep -A7 Summ
>
> My problem is that it is too large for the screen
Hi all.
In chapter 6 when building gcc, to have a view from the test suite, it is
said to issue
../gcc-4.8.0/contrib/test_summary | grep -A7 Summ
My problem is that it is too large for the screen and less or more are not
installed.
It's easy to go on another console and use the less o
Le 30/04/2013 18:23, Bruce Dubbs a écrit :
> Steve Crosby wrote:
>> Just an FYI - This test fails for me (and looking at the archives at
>> least one other recently), and looking at the logs, it's because it's
>> attempting to create 200,000 small files - that ex
Steve Crosby wrote:
> Just an FYI - This test fails for me (and looking at the archives at
> least one other recently), and looking at the logs, it's because it's
> attempting to create 200,000 small files - that exceeds the inode
> count on the seperate 2GB ext3 filesystem
Just an FYI - This test fails for me (and looking at the archives at
least one other recently), and looking at the logs, it's because it's
attempting to create 200,000 small files - that exceeds the inode
count on the seperate 2GB ext3 filesystem I created for sources.
e.g.
+ expensi
On Sun, 2013-04-07 at 14:55 -0500, Bruce Dubbs wrote:
>
> gcc uses a lot of space. Allocate about 2G of swap and it should be OK,
> but slow.
>
>-- Bruce
>
Working. THX...
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Uns
loki wrote:
> On Tue, 2013-03-19 at 17:38 -0500, Bruce Dubbs wrote:
>
>
>
>> I took a look and the file you want is
>> binutils-build/gas/testsuite/gas.log. I can't reproduce your failure,
>> so you need to look. What I have is:
>
>
> Have the same problem.
>
> Here's the relevant part:
>
> PASS:
On Tue, 2013-03-19 at 17:38 -0500, Bruce Dubbs wrote:
> I took a look and the file you want is
> binutils-build/gas/testsuite/gas.log. I can't reproduce your failure,
> so you need to look. What I have is:
Have the same problem.
Here's the relevant part:
PASS: i386 space1
../as-new -o
Emerson Yesupatham gmail.com> writes:
>
>
> Hi Team,
>
> I am seeing a test fauilure in LFS-Boot-7.0, Section 6.22 (E2fsprogs-1.41.14).
>
> Out of 107 tests, 1 test got failed.
>
> I have checked the reference test logs present at
http://www.linuxfrom
Samir Seth wrote:
> Hi
>
> Following LFS 7.3 instructions. I am logged in with user "foo", and the su
> into lfs user for the LFS build instructions.
>
> While building CoreUtils 8.21 i see one test failure. On debugging, i find
> that the failure is that getlo
Hi
Following LFS 7.3 instructions. I am logged in with user "foo", and the su
into lfs user for the LFS build instructions.
While building CoreUtils 8.21 i see one test failure. On debugging, i find
that the failure is that getlogin() is returning "foo", while
getenv("LO
Srdan Dukic wrote:
> Hi,
>
>>> I'm afraid I don't recall seeing that before. Is that the only error?
> Yes, that is the only error in the test suite.
>>> Try to find something like rept.log.
> Is this file meant to be in the build directory? I can't
Hi,
>> I'm afraid I don't recall seeing that before. Is that the only error?
Yes, that is the only error in the test suite.
>> Try to find something like rept.log.
Is this file meant to be in the build directory? I can't seem to find it.
>> Are all the v
Srdan Dukic wrote:
> Hi,
>
> I'm working through the latest LFS book and am at chapter 6.13 (
> http://www.linuxfromscratch.org/lfs/view/stable/chapter06/binutils.html).
> The compilation on that page does not throw any errors, however when I run
> the test suite with "
Hi,
I'm working through the latest LFS book and am at chapter 6.13 (
http://www.linuxfromscratch.org/lfs/view/stable/chapter06/binutils.html).
The compilation on that page does not throw any errors, however when I run
the test suite with "make check" one of the tests fails. Specifi
Pierre Labastie wrote:
> Le 02/03/2013 18:56, Niels Terp a écrit :
>> But in my case I get:
>>
>> root:/sources/gcc-build# grep -B4 '^ /usr/include' dummy.log
>>
>> #include <...> search starts here:
>>
>> /usr/lib/gcc/i686-pc-linux-gnu/4.7.2/include
>> /usr/local/include
>> /usr/lib/gcc/i686-pc-l
Le 02/03/2013 18:56, Niels Terp a écrit :
>
> Hi,
>
> I’m doing the newly released version 7.3 on a OpenSuSE 12.3 host (32 bit).
>
> In this chapter I get some of the output right, but in the wrong sequence:
>
> The command*grep -B4 '^ /usr/include' dummy.log*
>
> Should give this output:
>
> #incl
Hi,
On Sat, Mar 02, 2013 at 06:56:29PM +0100, Niels Terp wrote:
>Hi,
>I'm doing the newly released version 7.3 on a OpenSuSE 12.3 host (32 bit).
>In this chapter I get some of the output right, but in the wrong sequence:
> The command grep -B4 '^ /usr/include' dummy.log
>Should gi
Dana 2.3.2013 18:56, Niels Terp je napisao:
> Hi,
>
> I’m doing the newly released version 7.3 on a OpenSuSE 12.3 host (32 bit).
>
> In this chapter I get some of the output right, but in the wrong sequence:
>
> The command*grep -B4 '^ /usr/include' dummy.log*
>
> Should give this output:
>
> #incl
Hi,
I'm doing the newly released version 7.3 on a OpenSuSE 12.3 host (32 bit).
In this chapter I get some of the output right, but in the wrong sequence:
The command grep -B4 '^ /usr/include' dummy.log
Should give this output:
#include <...> search starts here:
/usr/local/incl
Niels Terp wrote:
> Tnkx for your quick reply ! The rest of the installation of gcc went on
> flawless, including all the sanity checks in the end. So I guess you are
> right, this error should just be ignored.
>
> By the way, thank you for pointing me to the archive lists. I had been
> looking fo
-Oprindelig meddelelse-
Fra: lfs-support-boun...@linuxfromscratch.org
[mailto:lfs-support-boun...@linuxfromscratch.org] På vegne af Bruce Dubbs
Sendt: 27. februar 2013 21:15
Til: LFS Support List
Emne: Re: [lfs-support] Failing test of gcc
Niels Terp wrote:
> I'm new here - have b
locale/time_get/get_weekday/char/38081-1.cc execution test
> Can anybody help me with this ? I don't have much experience with linux, but
> I'm trying to learn !
Yes, I get that too. So do a lot of others. Check out
http://gcc.gnu.org/ml/gcc-testresults/
I suggest ignoring
081-1.cc execution test
--
My host system is OpenSuSE 12.1 32 bit on a AMD processor.
Can anybody help me with this ? I don't have much experience with linux, but
I'm trying to learn !
Thanks in advance !
Niels
--
http://linuxfromscratch.org/mailman/listinfo/lfs-su
On Sun, 2013-01-06 at 14:56 -0600, Bruce Dubbs wrote:
> binutils is critical. I wouldn't want to try to use a system with these
> errors. I suggest starting over.
That, and after installing binutils next time, check for the existence
of /tools/tools thing, make sure you've not made the same mis
On Sun, Jan 6, 2013 at 3:56 PM, Bruce Dubbs wrote:
> matthew gruda wrote:
>
> >> What is the result of:
> >>
> >> $ find /tools -name ld\* -type f -exec ls -l {} \;
>
> > i got :
> > root:/# find /tools -name ld\* -type f -exec ls -l {} \;
> > -rwxr-xr-x 159442 Jan 6 01:39 /tools/lib/ld-2.16.so
matthew gruda wrote:
>> What is the result of:
>>
>> $ find /tools -name ld\* -type f -exec ls -l {} \;
> i got :
> root:/# find /tools -name ld\* -type f -exec ls -l {} \;
> -rwxr-xr-x 159442 Jan 6 01:39 /tools/lib/ld-2.16.so
> -rwxr-xr-x 915560 Jan 6 01:40 /tools/sbin/ldconfig
> -rw-r--r--
On Sun, Jan 6, 2013 at 1:57 PM, Bruce Dubbs wrote:
> matthew gruda wrote:
>
> We prefer you not top post.
>
> > $ cat `dirname $(gcc --print-libgcc-file-name)`/specs:
>
> That looks OK.
>
> > On Sun, Jan 6, 2013 at 12:57 PM, Bruce Dubbs
> wrote:
>
> >> Lets break this down:
> >>
>
> >>> LIBRAR
matthew gruda wrote:
We prefer you not top post.
> $ cat `dirname $(gcc --print-libgcc-file-name)`/specs:
That looks OK.
> On Sun, Jan 6, 2013 at 12:57 PM, Bruce Dubbs wrote:
>> Lets break this down:
>>
>>> LIBRARY_PATH=/tools/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/:
>>> /usr/lib/../lib64/
$ cat `dirname $(gcc --print-libgcc-file-name)`/specs:
*asm:
%{m32:--32} %{m32|mx32:;:--64} %{mx32:--x32}
%{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}
*asm_debug:
%{!g0:%{gstabs*:--gstabs}%{!gstabs*:%{g*:--gdwarf2}}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
*asm_final:
On Sun, Jan 06, 2013 at 11:57:41AM -0600, Bruce Dubbs wrote:
> First add a subject
>
> matthew gruda wrote:
> > now i got up to 6.10 and i tried:
> > echo 'main(){}' > dummy.c
> > cc dummy.c -v -Wl, --verbose
> >
> > and got:
>
> Lets break this down:
>
> > GNU assembler version 2.22 (x86_64-unk
First add a subject
matthew gruda wrote:
> now i got up to 6.10 and i tried:
> echo 'main(){}' > dummy.c
> cc dummy.c -v -Wl, --verbose
>
> and got:
Lets break this down:
> GNU assembler version 2.22 (x86_64-unknown-linux-gnu) using BFD version
> (GNU Binutils) 2.22
> COMPILER_PATH=/tools/libex
But, I think that *Errors* in chapter 6 tests (other than the
> toolchain - or at least least gcc), often benefit from being
> mentioned
We do mention that there are example logs on the web site. The only
places FAIL occurs in the 7.2 tests are:
079-gcc:FAIL: libmudflap.c++/pass55-frag.
Automake 1.12.4
>
> # TOTAL: 2880
> # PASS: 2756
> # SKIP: 86
> # XFAIL: 38
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
>
> This is not in a Chapter 6 environment, but has python and a lot of BLFS
> packages (about 260) installed. I think any errors in
On Sun, Sep 30, 2012 at 01:34:45PM +0100, Richard Melville wrote:
> On Sun, Sep 30, 2012 at 12:32:22AM +0100, Ken Moffat wrote:
> > >
> > > and I'll open a ticket for this possible fix to
> > > t/python-missing.sh. Normally, I'd just upload the patch, but I'd
> > > prefer to get confirmation that
ut 260) installed. I think any errors in Chapter 6 can be
ignored as test construction errors.
Some of the skipped tests are due to missing Microsoft C compiler(4),
MinGW(1), vala(7), etags(2), emacs, f77(4), etc.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: htt
> # TOTAL: 2852
> # PASS: 2648
> # SKIP: 164
> # XFAIL: 40
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
> ==
I don't recall automake-1.12.2, but we are looking at automake-1.12.4.
There was also an intermediate automake-
On Sun, Sep 30, 2012 at 12:32:22AM +0100, Ken Moffat wrote:
> >
> > and I'll open a ticket for this possible fix to
> > t/python-missing.sh. Normally, I'd just upload the patch, but I'd
> > prefer to get confirmation that it fixes the problem. More on -dev
> > when I've created a ticket.
> >
>
On Sun, Sep 30, 2012 at 12:32:22AM +0100, Ken Moffat wrote:
>
> and I'll open a ticket for this possible fix to
> t/python-missing.sh. Normally, I'd just upload the patch, but I'd
> prefer to get confirmation that it fixes the problem. More on -dev
> when I've created a ticket.
>
Forget that
=
make[2]: Leaving directory `/building/automake-1.12.3'
make[1]: Leaving directory `/building/automake-1.12.3'
root in chroot /building/automake-1.12.3#
Unfortunately, the bug report shows the problem was a race, and I'm
not yet convinced that the reported bug was necessarily the
configuration options and had set --
disable-uuid instead of --disable-uuidd
(2 d-s at the end) while configuring.
Correcting this removed the test failures.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information
Khoa Nguyen wrote:
> Hi all,
>
> I'm facing with a problem when i'm installing Coreutils-8.19 ( LFS 7.2 ).
> When i make a test , unfortunately, it fail a test case.
> Detail in gnulib-tests/test-suite.log
>
> FAIL: test-getlogin
> ===
>
&
On Sep 13, 2012, at 22:37 PM, Khoa Nguyen wrote:
>
> Hi all,
>
> I'm facing with a problem when i'm installing Coreutils-8.19 ( LFS
> 7.2 ).
> When i make a test , unfortunately, it fail a test case.
>
>
> FAIL: test-getlogin
> ===
Hi all,
I'm facing with a problem when i'm installing Coreutils-8.19 ( LFS 7.2 ).
When i make a test , unfortunately, it fail a test case.
The detail of problem :
Testsuite summary for GNU core
On Tue, Aug 21, 2012 at 10:13:04AM +0100, Richard Melville wrote:
> >
> > Thanks, but perhaps not necessary - it seems to be a problem at my
> > end (see Bruce's response, and my reply to that). In particular,
> > the "run as a regular user" seems NOT to be the key.
> >
> > ?en
> > --
> > das ei
>
> Thanks, but perhaps not necessary - it seems to be a problem at my
> end (see Bruce's response, and my reply to that). In particular,
> the "run as a regular user" seems NOT to be the key.
>
> ?en
> --
> das eine Mal als Trag?die, das andere Mal als Farce
>
>
Probably not of much use to you
On Fri, Aug 17, 2012 at 02:48:30PM +0100, Ken Moffat wrote:
> On Fri, Aug 17, 2012 at 11:42:26AM +0300, Markku Pesonen wrote:
> >
> > I think the problem may lie in the way LFS installs the tzdata package.
> > Glibc 2.15 (and earlier) installed timezone data without leap second
> > information in
t;> Unfortunately, this was unlogged and scrolled out of my
>>>>>> term's buffer - it then died with an EPERM trying to create
>>>>>> test-suite.log.tmp so I've now started it again, after chown me
>>>>>> ../automake-1.12.3.
&g
On Mon, Aug 20, 2012 at 10:19:42AM -0500, Eleanore Boyd wrote:
> On 8/20/2012 9:09 AM, Ken Moffat wrote:
> If running as a regular user isn't the key, and no one else is getting
> anywhere with it, them maybe it's a bug in Perl itself? What if they
> need to change how they read timezones, and ho
gt;>>>> term's buffer - it then died with an EPERM trying to create
>>>>> test-suite.log.tmp so I've now started it again, after chown me
>>>>> ../automake-1.12.3.
>>>>So, in effect that is chown -R some-normal-user ../automake-
- it then died with an EPERM trying to create
>>>> test-suite.log.tmp so I've now started it again, after chown me
>>>> ../automake-1.12.3.
>>> So, in effect that is chown -R some-normal-user ../automake-1.12.x
>>>
>>> If you are intereste
On Mon, Aug 20, 2012 at 12:56:56PM +0100, Richard Melville wrote:
> On Mon, Aug 20, 2012 at 12:04:49AM +0100, Ken Moffat wrote:
> > > Unfortunately, this was unlogged and scrolled out of my
> > > term's buffer - it then died with an EPERM trying to create
> >
On Mon, Aug 20, 2012 at 12:04:49AM +0100, Ken Moffat wrote:
> > Unfortunately, this was unlogged and scrolled out of my
> > term's buffer - it then died with an EPERM trying to create
> > test-suite.log.tmp so I've now started it again, after chown me
> > ../a
>
> Richard Melville wrote:
> > Failed 2 tests out of 2202, 99.91% okay.
> > ../cpan/IO-Compress/t/105oneshot-zip-only.t
> > ../cpan/Time-Local/t/Local.t
> >
> > I'm guessing that this is not a problem. Any views appreciated.
>
> That's a problem we are working right now. It's a timezon
led (it's my bootable system, back in chroot). My other two
were t/lex-clean-cxx and t/lex-depend-cxx : both undefined reference
to `yylex'.
I suppose those lex tests are SKIP for you, because LFS has not
installed flex when automake is built.
Retried 1.12.2 as a user, with a more mini
Ken Moffat wrote:
> In this case, I'd appreciate your comments (this list will do) on
> automake (if you are testing it) - on a completed system, 1.12 and
> later give me about 4 errors as a regular user (I'd still like to
> get to grips with those, one day). In a system which boots, but
> whe
On Mon, Aug 20, 2012 at 12:04:49AM +0100, Ken Moffat wrote:
> Unfortunately, this was unlogged and scrolled out of my
> term's buffer - it then died with an EPERM trying to create
> test-suite.log.tmp so I've now started it again, after chown me
> ../automake-1.12.3.
appropriate for .3) - it had a few errors,
but all the instspc.tap tests look as if they either PASSed of
XFAILed. Unfortunately, this was unlogged and scrolled out of my
term's buffer - it then died with an EPERM trying to create
test-suite.log.tmp so I've now started it again, after c
Richard Melville wrote:
> Failed 2 tests out of 2202, 99.91% okay.
> ../cpan/IO-Compress/t/105oneshot-zip-only.t
> ../cpan/Time-Local/t/Local.t
>
> I'm guessing that this is not a problem. Any views appreciated.
That's a problem we are working right now. It's a timezone installation
i
Failed 2 tests out of 2202, 99.91% okay.
../cpan/IO-Compress/t/105oneshot-zip-only.t
../cpan/Time-Local/t/Local.t
I'm guessing that this is not a problem. Any views appreciated.
Richard
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs
Bruce Dubbs wrote:
> Lewis Pike wrote:
>> Digging a bit deeper into the test suits logs does indeed reveal a
>> difference of 18 seconds on the time stamps. I checked and 18 leap
>> seconds did occur between the aforementioned dates.
>>
>> I tried duplicatin
Ken Moffat wrote:
> On Fri, Aug 17, 2012 at 10:51:06AM -0500, Bruce Dubbs wrote:
>>
>> On a fresh LFS svn system, I can do
>>
>> $ TZ=EST date;date;date -u
>> Thu Aug 16 23:56:26 EST 2012
>> Fri Aug 17 04:56:26 GMT 2012
>> Fri Aug 17 04:56:51 UTC 2012
>>
>> My understanding is that POSIX ignores le
On Fri, Aug 17, 2012 at 10:51:06AM -0500, Bruce Dubbs wrote:
>
> On a fresh LFS svn system, I can do
>
> $ TZ=EST date;date;date -u
> Thu Aug 16 23:56:26 EST 2012
> Fri Aug 17 04:56:26 GMT 2012
> Fri Aug 17 04:56:51 UTC 2012
>
> My understanding is that POSIX ignores leap seconds, and TZ setting
Ken Moffat wrote:
> On Fri, Aug 17, 2012 at 11:42:26AM +0300, Markku Pesonen wrote:
>>
>> I think the problem may lie in the way LFS installs the tzdata package.
>> Glibc 2.15 (and earlier) installed timezone data without leap second
>> information in /usr/share/zoneinfo and /usr/share/zoneinfo/pos
On Fri, Aug 17, 2012 at 11:42:26AM +0300, Markku Pesonen wrote:
>
> I think the problem may lie in the way LFS installs the tzdata package.
> Glibc 2.15 (and earlier) installed timezone data without leap second
> information in /usr/share/zoneinfo and /usr/share/zoneinfo/posix (why
> two copies of
Lewis Pike wrote:
> Digging a bit deeper into the test suits logs does indeed reveal a
> difference of 18 seconds on the time stamps. I checked and 18 leap
> seconds did occur between the aforementioned dates.
>
> I tried duplicating the test errors by building and testing
> e
n Sep 20 03:26:36 1993)
>> +File /lost+found (inode #11, mod time Mon Sep 20 03:26:18 1993)
>>
>> Notice the time difference of 18 seconds? I think that's the number
>> of leap seconds between Jan 1 1970 and September 1993.
>
> Digging a bit deeper into the test suit
nd (inode #11, mod time Mon Sep 20 03:26:18 1993)
>
> Notice the time difference of 18 seconds? I think that's the number
> of leap seconds between Jan 1 1970 and September 1993.
Digging a bit deeper into the test suits logs does indeed reveal a
difference of 18 seconds on the time s
Lewis Pike wrote:
> I'm getting some failures during the e2fsprogs test suite in part 3 of
> LFS Version SVN-20120806; revision 9930, to be exact.
>
> This seems related to ticket #3146 [1] in the bug reports. The report
> indicates that the issue has been fixed in svn r9926 w
I'm getting some failures during the e2fsprogs test suite in part 3 of
LFS Version SVN-20120806; revision 9930, to be exact.
This seems related to ticket #3146 [1] in the bug reports. The report
indicates that the issue has been fixed in svn r9926 with the upgrade
to e2fsprogs-1.42.5.
I
Emerson Yesupatham wrote:
> Hi Team,
>
> I am seeing a test fauilure in LFS-Boot-7.0, Section 6.22
> (E2fsprogs-1.41.14).
>
> Out of 107 tests, 1 test got failed.
>
> I have checked the reference test logs present at
> http://www.linuxfromscratch.org/lfs/build-logs
Hi Team,
I am seeing a test fauilure in LFS-Boot-7.0, Section 6.22
(E2fsprogs-1.41.14).
Out of 107 tests, 1 test got failed.
I have checked the reference test logs present at
http://www.linuxfromscratch.org/lfs/build-logs/7.0/core2duo/test-logs/085-e2fsprogs,
all the 107 tests are passed here
From: bl8r1...@tut.by
Date: Wed, 16 May 2012 14:33:12 +0300
To: lfs-support@linuxfromscratch.org
Subject: Re: [lfs-support] LFS-7.1: 6.37. Automake-1.11.3 (TEST FAILURE)!
> I expect every chip has its peculiarities, and my CPUs are not an exception.
>I failed to build LFS-6.8 (if I re
other hand, almost all software after binutils-gcc-glibc builds in a
matter of minutes anyway, mostly under one minute, not counting the test
suites. And tests as we see from reports are better run with j1. Good time
for brushing up on man pages while waiting, I think.
In BLFS all packages except gli
1 - 100 of 412 matches
Mail list logo
