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' > > _______________________________________________ pspp-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/pspp-dev
