Re: c32width gives incorrect return values in C locale

2023-11-18 Thread Patrice Dumas
On Sun, Nov 19, 2023 at 12:26:02AM +0100, Patrice Dumas wrote:
> On Sat, Nov 18, 2023 at 09:10:09PM +, Gavin Smith wrote:
> > On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote:
> > > On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote:
> > > > On 2023-11-13 01:28, Patrice Dumas wrote:
> > > > > According to your mail
> > > > > https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html
> > > > > 
> > > > > char32_t is less portable
> > > > 
> > > > That should be OK, if Gnulib provides a char32_t substitute that works 
> > > > well
> > > > enough. The mail you refer to merely says that literals like U'x' don't
> > > > work, but this is not a show-stopper for char32_t.
> > > 
> > > Indeed, the solaris10 automatic build now compiles ok with char32_t with
> > > Gnulib uchar after the changes Gavin made.
> > 
> > Is this the OpenCSW buildbot?
> 
> Yes.
> 
> >  How are you checking this?
> > 
> > Everytime I have checked
> > 
> > https://buildfarm.opencsw.org/buildbot/waterfall?tag=texinfo
> > 
> > recently, I have a page with a bunch of error messages on it:
> 
> At some point it worked again (presumably on the 15 of october), and I
> could see that tests passed.

15 of November, not October...

-- 
Pat



Re: c32width gives incorrect return values in C locale

2023-11-18 Thread Patrice Dumas
On Sat, Nov 18, 2023 at 09:10:09PM +, Gavin Smith wrote:
> On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote:
> > On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote:
> > > On 2023-11-13 01:28, Patrice Dumas wrote:
> > > > According to your mail
> > > > https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html
> > > > 
> > > > char32_t is less portable
> > > 
> > > That should be OK, if Gnulib provides a char32_t substitute that works 
> > > well
> > > enough. The mail you refer to merely says that literals like U'x' don't
> > > work, but this is not a show-stopper for char32_t.
> > 
> > Indeed, the solaris10 automatic build now compiles ok with char32_t with
> > Gnulib uchar after the changes Gavin made.
> 
> Is this the OpenCSW buildbot?

Yes.

>  How are you checking this?
> 
> Everytime I have checked
> 
> https://buildfarm.opencsw.org/buildbot/waterfall?tag=texinfo
> 
> recently, I have a page with a bunch of error messages on it:

At some point it worked again (presumably on the 15 of october), and I
could see that tests passed.

But now I get only errors again, same as you do.

-- 
Pat



Re: c32width gives incorrect return values in C locale

2023-11-18 Thread Gavin Smith
On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote:
> On Wed, Nov 15, 2023 at 12:22:24AM -0800, Paul Eggert wrote:
> > On 2023-11-13 01:28, Patrice Dumas wrote:
> > > According to your mail
> > > https://lists.gnu.org/archive/html/bug-libunistring/2023-11/msg0.html
> > > 
> > > char32_t is less portable
> > 
> > That should be OK, if Gnulib provides a char32_t substitute that works well
> > enough. The mail you refer to merely says that literals like U'x' don't
> > work, but this is not a show-stopper for char32_t.
> 
> Indeed, the solaris10 automatic build now compiles ok with char32_t with
> Gnulib uchar after the changes Gavin made.

Is this the OpenCSW buildbot?  How are you checking this?

Everytime I have checked

https://buildfarm.opencsw.org/buildbot/waterfall?tag=texinfo

recently, I have a page with a bunch of error messages on it:


web.Server Traceback (most recent call last):
twisted.internet.defer.FirstError: FirstError[#0, [Failure instance: Traceback: 
: (OperationalError) unable to open 
database file None None /opt/csw/lib/python2.7/threading.py:774:__bootstrap 
/opt/csw/lib/python2.7/threading.py:801:__bootstrap_inner 
/opt/csw/lib/python2.7/threading.py:754:run ---  --- 
/opt/csw/lib/python2.7/site-packages/twisted/python/threadpool.py:191:_worker 
/opt/csw/lib/python2.7/site-packages/twisted/python/context.py:118:callWithContext
 
/opt/csw/lib/python2.7/site-packages/twisted/python/context.py:81:callWithContext
 /opt/csw/lib/python2.7/site-packages/buildbot/db/pool.py:185:__thd 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/engine/threadlocal.py:61:contextual_connect
 /opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:272:connect 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:431:__init__ 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:867:_do_get 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:225:_create_connection 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:318:__init__ 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:379:__connect 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/engine/strategies.py:80:connect 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/engine/default.py:283:connect ]]
twisted.internet.defer.FirstError: FirstError[#0, [Failure instance: Traceback: 
: (OperationalError) unable to open 
database file None None /opt/csw/lib/python2.7/threading.py:774:__bootstrap 
/opt/csw/lib/python2.7/threading.py:801:__bootstrap_inner 
/opt/csw/lib/python2.7/threading.py:754:run ---  --- 
/opt/csw/lib/python2.7/site-packages/twisted/python/threadpool.py:191:_worker 
/opt/csw/lib/python2.7/site-packages/twisted/python/context.py:118:callWithContext
 
/opt/csw/lib/python2.7/site-packages/twisted/python/context.py:81:callWithContext
 /opt/csw/lib/python2.7/site-packages/buildbot/db/pool.py:185:__thd 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/engine/threadlocal.py:61:contextual_connect
 /opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:272:connect 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:431:__init__ 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:867:_do_get 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:225:_create_connection 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:318:__init__ 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/pool.py:379:__connect 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/engine/strategies.py:80:connect 
/opt/csw/lib/python2.7/site-packages/sqlalchemy/engine/default.py:283:connect ]]







nan, snan tests: Don't include these tests by default

2023-11-18 Thread Bruno Haible
The *printf-posix tests depend on the 'nan' and 'snan' modules. The unit
tests of these modules, in turn, depend on several fenv-* and fpe-tracking
modules, which are CPU dependent. I don't think it's wise to include these
tests in tarballs of arbitrary packages like coreutils or gettext:
Tarballs may be in use 5 or 10 years from now, and when they contain
these tests, they may well fail on CPUs that do not exist yet.

Therefore, here it a patch that cuts the module dependency chain at the
'nan' and 'snan' tests.


2023-11-18  Bruno Haible  

nan, snan tests: Don't include these tests by default.
* modules/nan-tests (Status): Mark the test as unportable.
* modules/snan-tests (Status): Likewise.

diff --git a/modules/nan-tests b/modules/nan-tests
index ec549b8919..9229a9467c 100644
--- a/modules/nan-tests
+++ b/modules/nan-tests
@@ -3,6 +3,9 @@ tests/test-nan-1.c
 tests/test-nan-2.c
 tests/macros.h
 
+Status:
+unportable-test
+
 Depends-on:
 fenv-exceptions-tracking-c99
 fpe-trapping
diff --git a/modules/snan-tests b/modules/snan-tests
index 6779f6c0bf..1c373ccac7 100644
--- a/modules/snan-tests
+++ b/modules/snan-tests
@@ -5,6 +5,9 @@ tests/test-snan-2.c
 tests/macros.h
 m4/math_h.m4
 
+Status:
+unportable-test
+
 Depends-on:
 fenv-exceptions-tracking-c99
 fpe-trapping