Re: Debian test errors

[bojo42]

Am Dienstag, den 28.02.2012, 14:54 +0000 schrieb John Darrington:
> 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.

I would vote for this one, as it would also explain my unability to
reproduce the failure and it's . When i compare my own build logs
(pbuilder) with those from Debian's autobuilder network the build
directory path is quite longer:

/build/buildd-pspp_0.7.9+git20120214-1-amd64-znUmhA/pspp-0.7.9
+git20120214

vs

/tmp/buildd/pspp-0.7.9+git20120214

But i don't see how we can do something much shorter as most of the path
comes from the autobuilders itself and they surely won't let us touch
them ;) But couldn't you use a relative path when calling postgres?

> 
> * 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?

Probably, but this might be a bigger undertaking, because even if it is
a bug over there we need a new version in Debian and also in every
derivat before we can work further on PSPP. Therefore i would prefer a
change in the testsuite, so we're more independent and faster on finally
getting a proper package in Debian.

> 
>     
>     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

I am taking a look into that, cause there should already be a common
method to do so in Debian. But isn't there a way that benifits other
distro in generell and am i right that you just use it to speed up the
UI menu?

> 
>     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?

/usr/share/pspp/icons

or 

/usr/share/pspp/icons/hicolor/16x16/actions (or status, ...)

Like above: they're just used inside the UI, right?

>     
> J'
>     
>