From brian at FreeBSD.org Sun Jul 5 06:32:51 2009 From: brian at FreeBSD.org (brian@FreeBSD.org) Date: Sun Jul 5 06:32:57 2009 Subject: standards/129554: lp(1) [patch] Implement -m and -t options Message-ID: <200907050632.n656WoZ1049988@freefall.freebsd.org> Synopsis: lp(1) [patch] Implement -m and -t options State-Changed-From-To: patched->closed State-Changed-By: brian State-Changed-When: Sun Jul 5 06:32:25 UTC 2009 State-Changed-Why: Fix merged to stable/7 - r195349 http://www.freebsd.org/cgi/query-pr.cgi?pr=129554 From bugmaster at FreeBSD.org Mon Jul 6 11:07:08 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 6 11:09:41 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200907061107.n66B779g010944@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/135307 standards Boot Loader problem on Acer Aspire 5735 o stand/130067 standards Wrong numeric limits in system headers? o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 48 problems total. From bms at incunabulum.net Mon Jul 6 14:06:00 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Jul 6 14:06:07 2009 Subject: Boost.Math svn/branches/release regressions flagged Message-ID: <4A5200CF.600@incunabulum.net> Hi guys, Just doing a Boost regression run... Any ideas? 4 fails, in computing float distance, over type double, with a large exponent. Details here: http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_next-test-gcc-4-2-1-debug.html is linked off: http://www.boost.org/development/tests/release/developer/math.html See test_next link in left column of math.html, for affected code. All other failures in Boost.Math, including this one, are down to lacking gmpfrxx, or lacking long double support in FreeBSD: http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_tr1_long_double-test-gcc-4-2-1-debug-build-no.html This is not a prerequisite in the Boost port, and we don't package gmpfrxx anywhere, so the concept checks fail. cheers, BMS P.S. Boost has a fairly rich exposure to the platform, perhaps we can get FreeBSD project resources for some occasional test coverage? P.P.S The IPv6 multicast failures in Boost.ASIO are due to the test machine having no v6 addresses other than ::1 (and no candidate default route). That's the module I'm most concerned with right at this moment. From bms at incunabulum.net Mon Jul 6 20:55:39 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Mon Jul 6 20:55:46 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <20090706205409.GA25996@zim.MIT.EDU> References: <4A5200CF.600@incunabulum.net> <20090706205409.GA25996@zim.MIT.EDU> Message-ID: <4A5264C0.1050509@incunabulum.net> David Schultz wrote: > What architecture is this, and how new is the regression? > This is i386, RELENG_7, tracking the Boost release branch (with their regression test run.py script) as of yesterday. From das at FreeBSD.ORG Mon Jul 6 21:23:23 2009 From: das at FreeBSD.ORG (David Schultz) Date: Mon Jul 6 21:23:29 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <4A5200CF.600@incunabulum.net> References: <4A5200CF.600@incunabulum.net> Message-ID: <20090706205409.GA25996@zim.MIT.EDU> What architecture is this, and how new is the regression? On Mon, Jul 06, 2009, Bruce Simpson wrote: > Hi guys, > > Just doing a Boost regression run... Any ideas? 4 fails, in computing > float distance, over type double, with a large exponent. > > Details here: > http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_next-test-gcc-4-2-1-debug.html > > is linked off: > http://www.boost.org/development/tests/release/developer/math.html > See test_next link in left column of math.html, for affected code. > > All other failures in Boost.Math, including this one, are down to > lacking gmpfrxx, or lacking long double support in FreeBSD: > http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_tr1_long_double-test-gcc-4-2-1-debug-build-no.html > > This is not a prerequisite in the Boost port, and we don't package > gmpfrxx anywhere, so the concept checks fail. > > cheers, > BMS > > P.S. Boost has a fairly rich exposure to the platform, perhaps we can > get FreeBSD project resources for some occasional test coverage? > > P.P.S The IPv6 multicast failures in Boost.ASIO are due to the test > machine having no v6 addresses other than ::1 (and no candidate default > route). That's the module I'm most concerned with right at this moment. From das at FreeBSD.ORG Mon Jul 6 21:51:55 2009 From: das at FreeBSD.ORG (David Schultz) Date: Mon Jul 6 21:52:01 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <4A5264C0.1050509@incunabulum.net> References: <4A5200CF.600@incunabulum.net> <20090706205409.GA25996@zim.MIT.EDU> <4A5264C0.1050509@incunabulum.net> Message-ID: <20090706215227.GA26491@zim.MIT.EDU> I will try to take a look when I have time. I'd be somewhat surprised if this is a regression in FreeBSD, though, since nothing that test_next or float_distance depend on (namely frexp and ldexp) have changed recently. On Mon, Jul 06, 2009, Bruce Simpson wrote: > David Schultz wrote: > >What architecture is this, and how new is the regression? > > > > This is i386, RELENG_7, tracking the Boost release branch (with their > regression test run.py script) as of yesterday. > _______________________________________________ > freebsd-standards@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-standards > To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.org" From alexanderchuranov at gmail.com Tue Jul 7 16:16:00 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Tue Jul 7 16:16:07 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <20090706215227.GA26491@zim.MIT.EDU> References: <4A5200CF.600@incunabulum.net> <20090706205409.GA25996@zim.MIT.EDU> <4A5264C0.1050509@incunabulum.net> <20090706215227.GA26491@zim.MIT.EDU> Message-ID: <3cb459ed0907070851p772c39c5u9514d9ce3d73766d@mail.gmail.com> Guys, Please note that though testing boost using tools supplied by boost.org can reveal actual issues in FreeBSD, this does not mean that users of FreeBSD ports system will encounter all of them. Boost ports contain patches that cut functionality that is not present in all supported FreeBSD versions. Perhaps, this may seriously downgrade issue severity. For details, see http://wiki.freebsd.org/BoostPortingProject , section "Known Issues". I hope this information is useful. Sincerely, Alexander Churanov, maintainer of devel/boost-* ports 2009/7/7 David Schultz : > I will try to take a look when I have time. ?I'd be somewhat > surprised if this is a regression in FreeBSD, though, since > nothing that test_next or float_distance depend on (namely frexp > and ldexp) have changed recently. > > On Mon, Jul 06, 2009, Bruce Simpson wrote: >> David Schultz wrote: >> >What architecture is this, and how new is the regression? >> > >> >> This is i386, RELENG_7, tracking the Boost release branch (with their >> regression test run.py script) as of yesterday. >> _______________________________________________ >> freebsd-standards@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-standards >> To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.org" > From brde at optusnet.com.au Tue Jul 7 20:26:34 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Tue Jul 7 20:26:48 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <4A5200CF.600@incunabulum.net> References: <4A5200CF.600@incunabulum.net> Message-ID: <20090708041419.K45178@delplex.bde.org> On Mon, 6 Jul 2009, Bruce Simpson wrote: > Just doing a Boost regression run... Any ideas? 4 fails, in computing float > distance, over type double, with a large exponent. Is this the bug fixed by gcc change 129199? If not, it might be a gcc bug or the test assuming that extra precision is available. You can probably eliminate precision bugs (including gcc bugs related to precision) by testing on amd64. The tests seemed to be compiled with -O0, so maybe they are avoiding some precision bugs intentionally. I sometimes need more than -O0 to avoid precision bugs. > Details here: > http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_next-test-gcc-4-2-1-debug.html > > is linked off: > http://www.boost.org/development/tests/release/developer/math.html > See test_next link in left column of math.html, for affected code. I couldn't see exactly what it is doing (does it call any libm functions?) and would find it too hard to build the whole tests. > All other failures in Boost.Math, including this one, are down to lacking > gmpfrxx, or lacking long double support in FreeBSD: > http://www.boost.org/development/tests/release/developer/output/bms-freebsd-gcc-boost-bin-v2-libs-math-test-test_tr1_long_double-test-gcc-4-2-1-debug-build-no.html > > This is not a prerequisite in the Boost port, and we don't package gmpfrxx > anywhere, so the concept checks fail. Looks like most things pass, but how much does leaving out long double tests lose? Bruce From mailing at gaturkey.com Thu Jul 9 20:22:24 2009 From: mailing at gaturkey.com (Global Access Travel) Date: Thu Jul 9 20:22:36 2009 Subject: Fam Trip to TURKEY for $999 (Refundable) Message-ID: <5a0b82db3ed35d212d964e2b984d7d0c@localhost.localdomain> [http://www.turkeycallingus.com/] Exclusive Boutique Enterprise Turkey FAM ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI 9 Nights / 11 Days $999 ? 5 Continents ? 150 Countries Worldwide ? 100.000 Hotels ? Instant Confirmation [http://www.turkeycallingus.com] [http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm] Global Access proudly presents the biggest FAM Trip of the year, teaming with Turkish Airlines and Turkish Ministry of Tourism and Culture. As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey is likely to be the one of the most popular destinations in 2010. Those who act early and get to know this beautiful country better will be able to give a better insight to their clients and secure more bookings. Our specially selected travel agents will stay in best hotels in each town, be escorted by professional, top tour guides, taste exceptionally good examples of Turkish Cuisine, and get to know Turkey in elegant way. Join us for a luxury FAM adventure and be our special guest in our beautiful country! COMBINE WITH World Travel Market! One of the biggest travel shows of Europe and the world, WTM, will be held in London between 9-12 November 2009. Combine your London trip with Turkey and benefit from great agent rates to see one of the most popular tourist destinations from USA and Canada. WE WILL REFUND YOUR MONEY BACK ! Upon booking your 20th passenger on a Global Access Travel Service, we will refund you the whole tour price that you?ve paid for the FAM Trip. If you book 20 or more people on a Global Access Travel Service before the FAM Trip starts, then you will travel for free! About Us Global Access Travel (GA) was founded in Turkey by a group of tourism professionals and marketing experts who recognized the needs to offer online services for accommodations, car rentals, and other travel related services to travel agencies. Through its sophisticated online reservation services, GA offers more than 100,000 hotels, motels, resorts, clubs and apartments all around the world. Other services of GA include car rentals, transfers, special tours, luxury services, city breaks, flight tickets and other services such as tailor made tour packages, exhibition organizations, incentives and other travel related services around the globe at competitive rates. [http://www.TurkeyCallingus.com] www.TurkeyCalling.us [http://www.turkeycallingus.com/turkey-calling-contact-us.htm] Global Access Travel Tel: +90 212 258 58 29 Fax: +90 212 258 34 47 E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com Website: [http://www.turkeycallingus.com/] www.TurkeyCalling.Us This message was sent by: FamTrit turkey, N?zhetiye Cad., istanbul, besiktas 34357, Turkey To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=47131455&l=82243&s=LUW4&m=578549&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=578549&s=47131455&c=LUW4&cid=305227 From bms at incunabulum.net Fri Jul 10 21:44:08 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Jul 10 21:44:15 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <3cb459ed0907070851p772c39c5u9514d9ce3d73766d@mail.gmail.com> References: <4A5200CF.600@incunabulum.net> <20090706205409.GA25996@zim.MIT.EDU> <4A5264C0.1050509@incunabulum.net> <20090706215227.GA26491@zim.MIT.EDU> <3cb459ed0907070851p772c39c5u9514d9ce3d73766d@mail.gmail.com> Message-ID: <4A57B5E8.4000803@incunabulum.net> JFYI: The HEAD/amd64 regression run was fubar -- got bitten by this issue: http://lists.boost.org/boost-build/2008/10/20471.php I've manually patched it and am re-running the test on ref8.freebsd.org now. cheers, BMS From bugmaster at FreeBSD.org Mon Jul 13 11:07:08 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 13 11:09:49 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200907131107.n6DB77gI040796@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/135307 standards Boot Loader problem on Acer Aspire 5735 o stand/130067 standards Wrong numeric limits in system headers? o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 48 problems total. From bugmaster at FreeBSD.org Mon Jul 20 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 20 11:09:45 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200907201107.n6KB74Dt002452@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/135307 standards Boot Loader problem on Acer Aspire 5735 o stand/130067 standards Wrong numeric limits in system headers? o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 48 problems total. From bms at incunabulum.net Tue Jul 21 14:47:43 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Jul 21 14:47:50 2009 Subject: Boost.Math svn/branches/release regressions flagged In-Reply-To: <20090708041419.K45178@delplex.bde.org> References: <4A5200CF.600@incunabulum.net> <20090708041419.K45178@delplex.bde.org> Message-ID: <4A65D50C.4040207@incunabulum.net> Bruce Evans wrote: > On Mon, 6 Jul 2009, Bruce Simpson wrote: > >> Just doing a Boost regression run... Any ideas? 4 fails, in computing >> float distance, over type double, with a large exponent. > > Is this the bug fixed by gcc change 129199? No, this GCC bug was related to some global 'using' declarations. I have a patch and am awaiting clearance from re@ to commit it. Only a few of the tests in an otherwise clean run on FreeBSD 7.2/i386 are affected by this, and the bug is part of the prior GCC 4.2.1 train. It's a one line fix for the DWARF output module. > > If not, it might be a gcc bug or the test assuming that extra > precision is > available. You can probably eliminate precision bugs (including gcc bugs > related to precision) by testing on amd64. The tests seemed to be > compiled > with -O0, so maybe they are avoiding some precision bugs > intentionally. I > sometimes need more than -O0 to avoid precision bugs. We've got other problems on FreeBSD with Boost right now. At the moment. the Boost.Build GCC glue is assuming that it can put lib32 into the link line, and rtld paths. Obviously, our runtime linker hates this, which is why we have lots of FAIL for amd64. I will be working with the Boost people to get the change which caused this backed out, as it seems that it isn't needed anywhere else, either. Until we get this resolved, it's difficult to test w/o --disable-long-double and on i386. > > I couldn't see exactly what it is doing (does it call any libm > functions?) > and would find it too hard to build the whole tests. Yes, Boost.Math is using libm extensively. thanks, BMS From bugmaster at FreeBSD.org Mon Jul 27 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 27 11:09:51 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200907271107.n6RB72cu019112@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/135307 standards Boot Loader problem on Acer Aspire 5735 o stand/130067 standards Wrong numeric limits in system headers? o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 48 problems total. From akosela at andykosela.com Mon Jul 27 13:30:02 2009 From: akosela at andykosela.com (Andy Kosela) Date: Mon Jul 27 13:30:12 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907271326.n6RDQOWF044267@www.freebsd.org> >Number: 137173 >Category: standards >Synopsis: `uname -n` incorrect behavior >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Mon Jul 27 13:30:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Andy Kosela >Release: >Organization: >Environment: FreeBSD plotinus.lan 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Sat Jun 6 15:21:16 CEST 2009 akosela@plotinus.lan:/usr/obj/usr/src/sys/GENERIC amd64 >Description: Currently `uname -n` prints the name of the system (FQDN) to standard output. I believe this is incorrect behavior according to IEEE Std 1003.1. -n Write the name of this node within an implementation-defined communications network. On the other hand though HP-UX, AIX, Solaris, Linux seems to conform to IEEE Std 1003.1 in this aspect and print only the hostname (without the domain name). This feature of uname(1) is important for some of us who rely on `uname -n` in PS1. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From sp at m.davydov.spb.su Mon Jul 27 19:30:04 2009 From: sp at m.davydov.spb.su (Valentin Davydov) Date: Mon Jul 27 19:30:10 2009 Subject: bin/25542: sh(1) null char in quoted string Message-ID: <200907271930.n6RJU3VS005183@freefall.freebsd.org> The following reply was made to PR bin/25542; it has been noted by GNATS. From: Valentin Davydov To: bug-followup@FreeBSD.org, sp@m.davydov.spb.su Cc: Jilles Tjoelker Subject: Re: bin/25542: sh(1) null char in quoted string Date: Mon, 27 Jul 2009 22:50:54 +0400 (MSD) At Sat, 4 Apr 2009 14:41:43 +0200, Jilles Tjoelker wrote: >Considering that fixing this would be a lot of work and cannot be done >completely (for example, argument strings and environment variables >cannot contain '\0'), I think it is best to close this. I think, at least documentation issue mentioned in the original PR 25542 can be corrected easy. Here is the patch: --- src/bin/sh/sh.1.orig 2007-12-05 17:29:07.000000000 +0300 +++ src/bin/sh/sh.1 2009-07-27 22:36:39.000000000 +0400 @@ -2381,4 +2381,6 @@ .Sh BUGS The .Nm -utility does not recognize multibyte characters. +utility does not recognize multibyte characters. +ASCII character in input strings, parameters etc. can be mishandled by +.Nm . From jilles at stack.nl Mon Jul 27 21:40:03 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Mon Jul 27 21:40:09 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907272140.n6RLe2gh004541@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, akosela@andykosela.com Cc: Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Mon, 27 Jul 2009 23:31:56 +0200 I understand that `uname -n`'s behaviour may be inconvenient to you, but I do not see why it is not compliant. An FQDN seems a valid "name of this node within an implementation-defined communications network". You can use shell-specific prompt expansions that generate the hostname without domain, or myhost=`uname -n`; myhost=${myhost%%.*}. -- Jilles Tjoelker From wollman at csail.mit.edu Mon Jul 27 21:50:11 2009 From: wollman at csail.mit.edu (Garrett Wollman) Date: Mon Jul 27 21:50:20 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907272150.n6RLo8TS011707@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Garrett Wollman To: Andy Kosela Cc: freebsd-gnats-submit@freebsd.org Subject: standards/137173: `uname -n` incorrect behavior Date: Mon, 27 Jul 2009 17:19:36 -0400 < said: > Currently `uname -n` prints the name of the system (FQDN) to standard output. I believe this is incorrect behavior according to IEEE Std 1003.1. > -n > Write the name of this node within an implementation-defined communications network. What makes you think that the behavior of "uname -n" does not match this description? -GAWollman From akosela at andykosela.com Tue Jul 28 08:40:04 2009 From: akosela at andykosela.com (Andy Kosela) Date: Tue Jul 28 08:40:10 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907280840.n6S8e33A050121@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Andy Kosela To: wollman@csail.mit.edu Cc: freebsd-gnats-submit@freebsd.org Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Tue, 28 Jul 2009 10:17:29 +0200 Garrett Wollman wrote: > < said: > > > Currently `uname -n` prints the name of the system (FQDN) to standard output. I believe this is incorrect behavior according to IEEE Std 1003.1. > > > -n > > Write the name of this node within an implementation-defined communications network. > > What makes you think that the behavior of "uname -n" does not match > this description? Hi Garrett, All UNIX systems I got access to prints only hostname without the domain information (same as 'hostname -s'). Is this some historical peculiarity of FreeBSD? I see it uses KERN_HOSTNAME which is indeed FQDN. On top of that common sense tells me that "node within an implementation-defined communications network" is just a node name, and not a full domain name information. What you think? --Andy From wollman at csail.mit.edu Tue Jul 28 20:30:05 2009 From: wollman at csail.mit.edu (Garrett Wollman) Date: Tue Jul 28 20:30:12 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907282030.n6SKU4h6098789@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Garrett Wollman To: Andy Kosela Cc: freebsd-gnats-submit@freebsd.org Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Tue, 28 Jul 2009 16:29:07 -0400 < said: > All UNIX systems I got access to prints only hostname without the domain > information (same as 'hostname -s'). Legacy Unix implementations used the UUCP name, which was completely unconnected to any other notion of the host's name. Few people use UUCP any more, and in any case, they are free to set their hostname to something other than an FQDN if they want. > On top of that common sense tells me that "node within an > implementation-defined communications network" is just a node name, and > not a full domain name information. What you think? In what way is an FQDN not a node name? -GAWollman From jhein at timing.com Tue Jul 28 20:50:04 2009 From: jhein at timing.com (John Hein) Date: Tue Jul 28 20:50:10 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907282050.n6SKo45Z015671@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: John Hein To: bug-followup@FreeBSD.org, akosela@andykosela.com Cc: Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Tue, 28 Jul 2009 14:16:17 -0600 It seems at least part of this report is inaccurate. I tested on linux (Fedora 10) and it seems to behave the same as freebsd... [root@foo ~]# hostname foo.example.com [root@foo ~]# uname -n foo.example.com From akosela at andykosela.com Wed Jul 29 07:10:03 2009 From: akosela at andykosela.com (Andy Kosela) Date: Wed Jul 29 07:10:08 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907290710.n6T7A2TF095212@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Andy Kosela To: jhein@timing.com, bug-followup@FreeBSD.org Cc: Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Wed, 29 Jul 2009 09:00:52 +0200 John Hein wrote: > It seems at least part of this report is inaccurate. > I tested on linux (Fedora 10) and it seems to behave > the same as freebsd... > > [root@foo ~]# hostname > foo.example.com > [root@foo ~]# uname -n > foo.example.com I tested it on SLES and Debian only. You are right, RedHat behaves differently. It seems there is no consensus about -n behavior even in the Linux camp. --Andy From akosela at andykosela.com Wed Jul 29 07:40:09 2009 From: akosela at andykosela.com (Andy Kosela) Date: Wed Jul 29 07:40:20 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907290740.n6T7e9uf045645@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Andy Kosela To: wollman@csail.mit.edu Cc: freebsd-gnats-submit@freebsd.org Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Wed, 29 Jul 2009 09:32:53 +0200 Garrett Wollman wrote: > In what way is an FQDN not a node name? Yes, 'uname -n' comes from UUCP times. I think our discussion boils down to nodename vs hostname, which in legacy UNIX can have different values. For me it seems natural that nodename (coming from old UUCP) should be identical to hostname without the full domain name information. Is out there some standard defining it and explaining how nodename (UUCP) convention should be applied to hostname (ARPA, NFS) convention? --Andy From wollman at csail.mit.edu Wed Jul 29 16:00:19 2009 From: wollman at csail.mit.edu (Garrett Wollman) Date: Wed Jul 29 16:00:26 2009 Subject: standards/137173: `uname -n` incorrect behavior Message-ID: <200907291600.n6TG0J12044489@freefall.freebsd.org> The following reply was made to PR standards/137173; it has been noted by GNATS. From: Garrett Wollman To: Andy Kosela Cc: freebsd-gnats-submit@freebsd.org Subject: Re: standards/137173: `uname -n` incorrect behavior Date: Wed, 29 Jul 2009 11:52:34 -0400 < said: > information. Is out there some standard defining it and explaining how > nodename (UUCP) convention should be applied to hostname (ARPA, NFS) > convention? No, that's why the POSIX specification leaves it completely implementation-defined. You have to remember that this value originally came from a "struct utsname" which had fixed-length (eight?-byte) fields, and the name was compiled into the kernel. (Hence UUCP names like "ihnp4", "mhuxu", and so on.) -GAWollman