pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Debian test errors


From: John Darrington
Subject: Debian test errors
Date: Tue, 28 Feb 2012 14:54:20 +0000
User-agent: Mutt/1.5.18 (2008-05-17)

bojo42 writes: 


    
    armel: 184 308
    armhf: 184 308
    mipsel: 184 308

184 is the postgres test, discussed below.

308 is 'lexer properly reports scan errors' and it seems to be segfaulting.  
  I've no idea where or why. Ben?
    
    ia64: 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
    58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
    82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 99 100 101 102 103 104
    105 106 107 108 109 110 111 112 115 116 117 118 119 120 121 122 123 145
    146 147 148 149 150 184 194 196 197 206 207 208 209 210 211 212 213 228
    229 237 238 239 240 246 259 262 345 346 347 348 543 544 917 918 919 921
    922 923 925 926 927

Most of these seem to be related to the sysfile reader.  Odd that they appear
on ia64 but not on amd64.  What is the difference?
    
    mips: 184 308 439 440 837 922
    powerpc: 184 439 440 837 922
    s390: 184 439 440 837 922
    sparc: 184 439 440 837 922

439 and 440 are just things being reported in a different order (iterating 
through an unsorted hash). Should not be too difficult to fix.
922 is a similar problem.

I'm not too sure about 837 - I think it must be a problem with the test program
rather than the functionality it's testing - otherwise we would have seen a lot
more failures.  The test prog could certainly use a few more diagnostic 
messages.
I can only suggest that we add those and send it back for another shot.

    
    For the postgresql issue please see:
    
https://buildd.debian.org/status/fetch.php?pkg=pspp&arch=amd64&ver=0.7.9%2Bgit20120219-1&stamp=1330358053

The problematic part seems to be starting the postgres server:

stdout:
waiting for server to start......LOG:  could not translate service 
"/build/buildd-pspp_0.7.9+git20120219-1-amd64-O7Y1R3/pspp-0.7.9+git20120219/tests/testsuite.dir/184/.s.PGSQL.6543"
 to address: Non-recoverable failure in name resolution
WARNING:  could not create Unix-domain socket

The message "Non-recoverable failure in name resolution" 
corresponds to the EIA_FAIL code, which seems to be simply an
"other" error code.

I chatted briefly with #postgres on IRC.  Nobody could give any 
definite answer, but suggestions are:

* The 
path"/build/buildd-pspp_0.7.9+git20120219-1-amd64-O7Y1R3/pspp-0.7.9+git20120219/tests/testsuite.dir/184/.s.PGSQL.6543"
 
  is too long.  If this is true, then I consider it a bug in postgres.  
  But perhaps we should try it with something shorter, just to see.

* Perhaps the filesystem doesn't support Unix Domian Sockets or has been 
  mounted with an option which disallows their creation.

Do you think the Debian maintainers of Postgres might be able to help?

    
    The other issue in Debian is related to the icon installation as PSPP
    installs /usr/share/icons/hicolor/icon-theme.cache and there are some
    other packages which also ship that file. Probably no package should
    really ship it at all, as this is a very general location.

Yes.  It should not be shipped if it already exists.  Instead it should be 
updated in the post-inst stage

    Would be also
    great if we can stop installing the 16x16 icons
    under /usr/share/icons/16x16/pspp as this is quite a uncommon place for
    package specific icons. Do you think you can fix that in Git?

Where would be a common place to put them?
    
J'
    

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://keys.gnupg.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]