[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debian test errors
From: |
bojo42 |
Subject: |
Re: Debian test errors |
Date: |
Tue, 28 Feb 2012 17:05:53 +0100 |
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'
>
>