Re: LTP failure
Bruce Dubbs wrote: I've been trying to figure out why the attached file fails on my LFS systems. It does not fail on FC or RHEL kernels. Neither mincore01 nor mincore02 fail on my (C)LFS system either. But it's not exactly LFS, so it's probably not a great test. It's a multilib x86-64 setup (with a 64-bit kernel, of course). Kernel version is 2.6.19.1 (which I need to upgrade one of these days). I wonder if there was maybe some different behavior added in the kernel since 2.6.16.27? Also, when I run your test program (after changing the (unsigned int) cast to an (unsigned long int) cast and changing the printf format specifier to match, since pointers on my setup are 64 bits wide), I don't get a failure whether I pass an argument to min or not. But again, this system is probably too different from standard LFS to be a great test. The 64-bit stuff especially seems like it'd affect this test, at least a bit. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
thunderbird + firefox: 1.5.0.9 - 1.5.0.10 (system_nss patch)
Hi out there. Due to the mozilla security announcements ( http://www.mozilla.org/security/announce/ ) concerning versions 1.5.0.9, I was inclined to upgrade both to 1.5.0.10. I had to recognize that, while the pago-patch from BLFS still applies, the system_nss patch didn't like to do so. (Upgraded nss to 3.11.5 [ ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_11_5_RTM/src/nss-3.11.5-with-nspr-4.6.5.tar.gz ] , too, by the way) I massaged the patches (for firefox as well as for thunderbird) to apply again, but I am not in a position to judge if I did it right, apart from both now applying and both apps compiling and running afterwards. If the actual maintainer of these patches might take a look at them and correcting eventual errors, the build instructions in the BLFS(-devel) would apply to (firefox-|thunderbird-)1.5.0.10 with working results, as far as I could see (changing the version-numbers as they appear explicitely would, of course, also be needed). You'll find the two changed patches attached to this message. Greets, Jens -- [EMAIL PROTECTED] 23.56...drifting By caffeine alone I set my mind in motion, By the beans of Java do thoughts acquire speed, hands acquire shaking, the shaking becomes a warning, By caffeine alone do I set my mind in motion Submitted By:Randy McMurchy randy_at_linuxfromscratch_dot_org Date:2006-01-20 Initial Package Version: 1.5 Upstream Status: In trunk and firefox-2.0 branch. Origin: https://bugzilla.mozilla.org/show_bug.cgi?id=255408 Description: Fixes the --use-system-nss and --with-nss-prefix switches so that they actually work. This patch allows the Mozilla products to use the system installed versions of NSS and NSPR. diff -Naur mozilla-orig/aclocal.m4 mozilla/aclocal.m4 --- mozilla-orig/aclocal.m4 2004-05-13 03:12:47.0 + +++ mozilla/aclocal.m4 2006-01-21 00:57:48.0 + @@ -8,6 +8,7 @@ builtin(include, build/autoconf/libIDL.m4)dnl builtin(include, build/autoconf/libIDL-2.m4)dnl builtin(include, build/autoconf/nspr.m4)dnl +builtin(include, build/autoconf/nss.m4)dnl builtin(include, build/autoconf/libart.m4)dnl builtin(include, build/autoconf/pkg.m4)dnl builtin(include, build/autoconf/freetype2.m4)dnl diff -Naur mozilla-orig/build/autoconf/nss.m4 mozilla/build/autoconf/nss.m4 --- mozilla-orig/build/autoconf/nss.m4 1970-01-01 00:00:00.0 + +++ mozilla/build/autoconf/nss.m4 2006-01-21 00:57:48.0 + @@ -0,0 +1,67 @@ +# -*- tab-width: 4; -*- +# Configure paths for NSS +# Public domain - Chris Seawood [EMAIL PROTECTED] 2001-04-05 +# Based upon gtk.m4 (also PD) by Owen Taylor + +dnl AM_PATH_NSS([MINIMUM-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]]) +dnl Test for NSS, and define NSS_CFLAGS and NSS_LIBS +AC_DEFUN(AM_PATH_NSS, +[dnl + +AC_ARG_WITH(nss-prefix, + [ --with-nss-prefix=PFX Prefix where NSS is installed], + nss_config_prefix=$withval, + nss_config_prefix=) + +AC_ARG_WITH(nss-exec-prefix, + [ --with-nss-exec-prefix=PFX + Exec prefix where NSS is installed], + nss_config_exec_prefix=$withval, + nss_config_exec_prefix=) + + if test -n $nss_config_exec_prefix; then + nss_config_args=$nss_config_args --exec-prefix=$nss_config_exec_prefix + if test -z $NSS_CONFIG; then + NSS_CONFIG=$nss_config_exec_prefix/bin/nss-config + fi + fi + if test -n $nss_config_prefix; then + nss_config_args=$nss_config_args --prefix=$nss_config_prefix + if test -z $NSS_CONFIG; then + NSS_CONFIG=$nss_config_prefix/bin/nss-config + fi + fi + + unset ac_cv_path_NSS_CONFIG + AC_PATH_PROG(NSS_CONFIG, nss-config, no) + min_nss_version=ifelse([$1], ,3.0.0,$1) + AC_MSG_CHECKING(for NSS - version = $min_nss_version (skipping)) + + no_nss= + if test $NSS_CONFIG = no; then + no_nss=yes + else + NSS_CFLAGS=`$NSS_CONFIG $nss_config_args --cflags` + NSS_LIBS=`$NSS_CONFIG $nss_config_args --libs` + + dnl Skip version check for now + nss_config_major_version=`$NSS_CONFIG $nss_config_args --version | \ + sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\1/'` + nss_config_minor_version=`$NSS_CONFIG $nss_config_args --version | \ + sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\2/'` + nss_config_micro_version=`$NSS_CONFIG $nss_config_args --version | \ + sed 's/\([[0-9]]*\).\([[0-9]]*\).\([[0-9]]*\)/\3/'` + fi + + if test -z $no_nss; then +
Re: LTP failure
Bryan Kadzban wrote: Bruce Dubbs wrote: I've been trying to figure out why the attached file fails on my LFS systems. It does not fail on FC or RHEL kernels. Neither mincore01 nor mincore02 fail on my (C)LFS system either. But it's not exactly LFS, so it's probably not a great test. It's a multilib x86-64 setup (with a 64-bit kernel, of course). Kernel version is 2.6.19.1 (which I need to upgrade one of these days). I wonder if there was maybe some different behavior added in the kernel since 2.6.16.27? Also, when I run your test program (after changing the (unsigned int) cast to an (unsigned long int) cast and changing the printf format specifier to match, since pointers on my setup are 64 bits wide), I don't get a failure whether I pass an argument to min or not. But again, this system is probably too different from standard LFS to be a great test. The 64-bit stuff especially seems like it'd affect this test, at least a bit. Thanks Bryan. It's still a mystery to me. I tried a 2.6.20.3 kernel last night and it still failed for me. Experimenting showed that the printf needs to be before the mmap function to make a difference, so I am hypothesizing that the issue is in mmap. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LTP failure
On Wed, Mar 21, 2007 at 10:31:29AM -0500, Bruce Dubbs wrote: Thanks Bryan. It's still a mystery to me. I tried a 2.6.20.3 kernel last night and it still failed for me. Well, I can try installing 2.6.20.3 to see if it also fails for me; perhaps 2.6.19.1 is an oddball? I know it has some other issues, so I should upgrade it anyway. However, I've done some other testing on a really-old LFS system (pre 6.2) that's still running kernel 2.4 (2.4.33.6 plus grsecurity), and it passes the test. I've also tested a Debian-testing box running kernel 2.6.18-1-686 (whatever that corresponds to), and it passes as well. Both of these machines run 32-bit kernels. Experimenting showed that the printf needs to be before the mmap function to make a difference, so I am hypothesizing that the issue is in mmap. Entirely possible; there have been a few issues with mmap over the past couple years that I can remember. Maybe one of the fixes broke this test? What happens if you lseek() back to the beginning of the file before calling mmap? I don't think that should matter, but who knows. pgpNOwhnNcYcQ.pgp Description: PGP signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.3 status update
El Miércoles, 21 de Marzo de 2007 02:05, Matthew Burgess escribió: Hi folks, Progress appears to being made toward a 6.3 release. We currently have 9 tickets to resolve before we can push another release out[0]. Great :-) I'm happy to postpone the rendering toolchain related bugs #1947 (fop-0.93) and its dependency of #1956 (docbook-xsl-1.72.1) if upstream aren't in a position to make a release in time. They are yet fixing bugs, the last one just 90 minutes ago. I'm thinking on creating the branch this weekend and start working based on the most current snapshot tarball available at that time #1893 (docbook-4.5) has a patch available so that's a no-brainer really. Looks like it is not installed yet on quantum :-? [EMAIL PROTECTED] ls /usr/share/xml/docbook/ . .. xml-dtd-4.4 xsl-stylesheets-1.69.1 [EMAIL PROTECTED] grep -l 4.4 /etc/xml/* /etc/xml/docbook [EMAIL PROTECTED] grep -l 4.5 /etc/xml/* [EMAIL PROTECTED] I will made the commit upgrade as soon docbook-4.5 will be properly installed on quantum. I'll be on holiday from 2007-03-23 to 2007-04-06 and am unlikely to be able to deal with any LFS issues during that time. That said, if anyone wants to try and find me in a bar in North Carolina, I might be persuaded to deal with LFS stuff, in exchange for a beer or 2 of course :-) Enjoy the holidays :-)) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.3 status update
On Wednesday 21 March 2007 17:57, M.Canales.es wrote: #1893 (docbook-4.5) has a patch available so that's a no-brainer really. Looks like it is not installed yet on quantum :-? Wow, sorry about that. I could have sworn I'd done that already. Anyway, it's done now. I will made the commit upgrade as soon docbook-4.5 will be properly installed on quantum. Great! Enjoy the holidays :-)) Thanks very much! Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-6.3 status update
El Miércoles, 21 de Marzo de 2007 19:09, Matthew Burgess escribió: Wow, sorry about that. I could have sworn I'd done that already. Anyway, it's done now. Verified and confirmed that the catalog resolution works. Thanks. Working on the commit now... -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Test Project
On Wednesday 21 March 2007 00:31, Bruce Dubbs wrote: Just a note to say I was trying out the LTP today on my 6.2 test system. http://ltp.sourceforge.net/ I ran the tests and got four failures: mincore01 FAIL 1 gf15 FAIL 1 gf17 FAIL 1 gf18 FAIL 1 On latest LFS (SVN-20070319 - jhalfs build) I get: mincore01 FAIL 1 sendmsg01 FAIL 2 The mincore01 gives: $ sudo ./mincore01 mincore011 PASS : expected failure: errno = 22 (Invalid argument) mincore012 PASS : expected failure: errno = 14 (Bad address) mincore013 FAIL : call succeeded unexpectedly mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory) Exactly the same results here. The sendmsg01 failure is caused by the test case trying to call `ifconfig' which no longer exists on an LFS system. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Linux Test Project
Matthew Burgess wrote: On Wednesday 21 March 2007 00:31, Bruce Dubbs wrote: Just a note to say I was trying out the LTP today on my 6.2 test system. http://ltp.sourceforge.net/ I ran the tests and got four failures: mincore01 FAIL 1 gf15 FAIL 1 gf17 FAIL 1 gf18 FAIL 1 On latest LFS (SVN-20070319 - jhalfs build) I get: mincore01 FAIL 1 sendmsg01 FAIL 2 The mincore01 gives: $ sudo ./mincore01 mincore011 PASS : expected failure: errno = 22 (Invalid argument) mincore012 PASS : expected failure: errno = 14 (Bad address) mincore013 FAIL : call succeeded unexpectedly mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory) Exactly the same results here. The sendmsg01 failure is caused by the test case trying to call `ifconfig' which no longer exists on an LFS system. Thanks Matt. I was beginning to think I was the only one. My sendmsg01 passed because I have net-tools on my systems. I'm asking around about the mincore01 problem. If I can't get an answer, I'm going to elevate the post to lkml. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LTP failure
results here from an older system (specifically an LFS dev version from around mar 2006) mincore011 PASS : expected failure: errno = 22 (Invalid argument) mincore012 PASS : expected failure: errno = 14 (Bad address) mincore013 FAIL : call succeeded unexpectedly mincore014 PASS : expected failure: errno = 12 (Cannot allocate memory) current kernel version is (recently rebuilt to add USB support): Linux lfsbuild 2.6.15.6-LFS #7 Fri Mar 2 00:55:33 NZDT 2007 i686 i686 i386 GNU/Linux On 3/21/07, Bruce Dubbs [EMAIL PROTECTED] wrote: I've been trying to figure out why the attached file fails on my LFS systems. It does not fail on FC or RHEL kernels. I'd appreciate it if some of you could run the attached program ans send me the results. You just run the binary. If you don't want to do that, the full source to is at http://prdownloads.sourceforge.net/ltp/ltp-full-20070228.tgz?download -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
