Bug#850457: pspp 0.10.2-1 FTBS randomly

[Friedrich Beckmann]

> Am 03.06.2017 um 14:10 schrieb John Darrington :
> 
> I presume this error is one that has just recently arisen?  and so far as I'm 
> aware, no uploads
> of pspp have recently occured in Debian (am I right Frederich?)   If so, then 
> I suggest that recent
> changes to other entities are investigated.
> 

pspp-0.10.2-1 is in testing since Oktober 2016. It was build again postgresql 
9.6.0-1
In march it was rebuild against postgresql 9.6.2-1 (PIE rebuild)

A first report of the postgresql related problems was from Santiago in January 
2017
with postgresql 9.6.1-2. The new report from Lucas on i386 is with postgresql 
9.6.3-3

Friedrich



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Friedrich Beckmann]

Hi Lucas,

I guess the regression failure for postgresql here

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863928

and for pspp here

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850457
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863933

which also fails when starting the psql server has probably the same reason
in the build environment. The error message in pspp indicates
a problem with the locale settings.

I could switch off the check of stderr in that specific test case
as John proposed which will make pspp pass again. Maybe some
investigation if this is related to the build system would be
more advisable.

Christoph cannot reproduce the postgresql regression failure
on his build system. I cannot reproduce the pspp failure
on my build system.

Note that Santiago found the problem as a random failure in stretch. He
put several buildlogs here:

https://people.debian.org/~sanvila/build-logs/pspp/

Lucas found the problem on stretch for i386 to be reproducable.

As Christoph already asked: Could you maybe check the locale
settings on your build system?

Regards

Friedrich

Bug#850457: pspp 0.10.2-1 FTBS randomly

[John Darrington]

Hi Christoph,


On Sat, Jun 03, 2017 at 12:27:12PM +0200, Christoph Berg wrote:
 Re: John Darrington 2017-06-03 <20170603061903.GA30068@jocasta.intra>
 > If I'm reading that log file correctly, the issue is simply that initdb 
is dumping that
 > message on stderr. Our test considers that a failure.  
 > 
 > This would seem to suggest a problem with debian's postgres package.
 
 Hi,
 
 this is not a PostgreSQL problem. Make sure the locale settings are
 valid in the build environment. (This is either a problem with the
 build daemon, or a problem with pspp's testsuite or debian/rules
 file.)

Pspp's testsuite sets its environment to LC_ALL=C overriding anything which 
might have been
previously set.   This should ensure the locale is always valid shouldn't it?

I presume this error is one that has just recently arisen?  and so far as I'm 
aware, no uploads
of pspp have recently occured in Debian (am I right Frederich?)   If so, then I 
suggest that recent
changes to other entities are investigated. 

Or we can just ignore stderr by using the workaround  I suggested earlier.

J'


-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Christoph Berg]

Re: John Darrington 2017-06-03 <20170603061903.GA30068@jocasta.intra>
> If I'm reading that log file correctly, the issue is simply that initdb is 
> dumping that
> message on stderr. Our test considers that a failure.  
> 
> This would seem to suggest a problem with debian's postgres package.

Hi,

this is not a PostgreSQL problem. Make sure the locale settings are
valid in the build environment. (This is either a problem with the
build daemon, or a problem with pspp's testsuite or debian/rules
file.)

>  I think the problem is due to locale settings in the environment. The
>  critical message is:
>  
>  +locale: Cannot set LC_MESSAGES to default locale: No such file or 
> directory

Christoph

Bug#850457: pspp 0.10.2-1 FTBS randomly

[John Darrington]

If I'm reading that log file correctly, the issue is simply that initdb is 
dumping that
message on stderr. Our test considers that a failure.  

This would seem to suggest a problem with debian's postgres package.

However I think we can safely ignore it by changing

 AT_CHECK([initdb -A trust], [0], [ignore])

to

 AT_CHECK([initdb -A trust], [0], [ignore], [ignore])


J'


On Sat, Jun 03, 2017 at 07:34:53AM +0200, Friedrich Beckmann wrote:
 Dear Adrian, dear Lucas,
 
 thanks for your reports. Maybe you can help me with the analysis as I have 
problems to reproduce it
 here locally. 
 
 As already reported in the bug log
 
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863933
 
 I think the problem is due to locale settings in the environment. The
 critical message is:
 
 +locale: Cannot set LC_MESSAGES to default locale: No such file or 
directory
 
 in test 247 (which starts a PSQL server). The problem happens when the 
psql server starts.
 
 It seems strange to me that this happens randomly. 
 
 Regards
 
 Friedrich
 
 
 
 ___
 pspp-dev mailing list
 pspp-...@gnu.org
 https://lists.gnu.org/mailman/listinfo/pspp-dev

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Bug#850457: pspp 0.10.2-1 FTBS randomly

[Friedrich Beckmann]

Dear Adrian, dear Lucas,

thanks for your reports. Maybe you can help me with the analysis as I have 
problems to reproduce it
here locally. 

As already reported in the bug log

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863933

I think the problem is due to locale settings in the environment. The
critical message is:

+locale: Cannot set LC_MESSAGES to default locale: No such file or directory

in test 247 (which starts a PSQL server). The problem happens when the psql 
server starts.

It seems strange to me that this happens randomly. 

Regards

Friedrich