I need someone to help resolve the problem below that I reported several
days ago and leaves rpm packaging broken on at least Fedora 18.
== Packaging pcp, log is in /home/kenj/src/pcp-dev/Logs/pcp
Packaging failed, see log in /home/kenj/src/pcp-dev/Logs/pcp
Appending installation info to
/tmp/pcp-build-32533/home/kenj/perl5/lib/perl5/x86_64-linux-thread-multi/perllocal.pod
Arrgh ... no files to include in package via ../../../perl-pcp-pmda.list
So far ... rpm packaging is broken here:
vm03 3.8.0 x86_64 Fedora 18 (Spherical Cow)
but works here:
vm02 3.8.0 i686 openSUSE 12.1 (Asparagus)
vm04 3.8.0 i586 CentOS 5.9 (Final)
vm14 3.8.0 x86_64 CentOS 6.3 (Final)
vm12 3.7.2 i686 Fedora 17 (Beefy Miracle)
vm19 3.8.0 x86_64 openSUSE 12.2 (Mantis)
grundy 3.8.0 ia64 SUSE SLES11 SP1
I have even tried cloning a new official pcp tree from oss.sgi.com, but
same result on vm03.
I cannot make much progress on this complete list of QA issues as they
come from the Fedora 18 host, but let me pick up a few of the issues ...
On 10/05/13 09:10, Nathan Scott wrote:
...
OK, here's my notes from looking through these failures. I've
came back later and put a note with each as to who I think is/
might want to look further.
024 - mmv pmda coming & going ... think this is as a result of
the earlier attempts to get consistent pmda setups for all
tests? can we force mmv to always be there? (and dso)
[at this stage, I've been assuming kenj'll tackle this]
Fixed with a recent commit of mine ... cause is subtle and only
peripherally related to consistent pmda setups.
051 - looks like fallout from the wildcard changes? specific to
either your network or non-secure sockets though, as its
passing for me? I'll do a non-secure-socket QA run today
and send further mail as to which it is.
[one for kenj/brolley to nut out?]
Not sure on this one, I have a mixture of passes and fails ... no clear
picture yet.
...
359 - pmdasystemd failure - all metrics getting illegal pmid
(this is notrun for me, I have no QA hosts sufficiently modern
as yet - on the todo list, but wont happen overnight)
[fche? - see test 652 as well, looks related]
Is being run and passing on other hosts, so not sure about this one.
367 - hmm, test has linked the wrong .out file ... should be using
the exercising the auth PDU on PCP_380, which the test did,
but compared to pre-3.8.0 .out file (367.out.1) - could be a
bad localconfig here? passes for me.
[setup issue - kenj?]
Not a setup issue. There is a typo in 367 re authenticate vs
authentication ...
authenticate=false
eval `pmconfig -L 2>/dev/null`
rm -f $seq.out $seq.full
if $authentication ; then
but that's not the problem. On several hosts I have
authentication=false from pmconfig -L, but the .bad file seems to match
367.out.2
Should the guard be checking PCP_VER or are there 3 possible output
files expected? pre-3.8.0, 3.8.0 with authentication, 3.8.0 without
authentication?
371 - ...
[nathans]
Passing now on all recently tested platforms, thanks.
374 - the .bad file you sent matches the expected output - this looks
like it might be another case of localconfig not being correct?
Not a config problem on another host with the same symptom. Seems like
this commit 0df386edf0d94119d46ee849ccc91a82d6911e33 changed the pmns
for the pmcd PMDA, but some consequential change is needed for the QA test.
375 - ditto
Seems to be passing now.
513 - and again (exercised the new auth PDU, but compared to older
version of expected output)
[setup issue - kenj?]
Not a setup issue. Same as 367 (but no typo this time).
532 - pmlogger_daily - somehow a temp file not created (/tmp/pid.out.1)
and several cascading errors resulted? passes for me though.
Seems to be passing now.
652 - another systemd failure - oh, looks like the metrics changed (ISTR
suggesting this) and perhaps the test was not updated? Lets prod
Frank for his verdict, but this looks to me like a bad .out file.
[fche - possibly just a qa/remake needed by kenj?]
Can't test due to rpm build issue above. Not obviously run elsewhere.
|