On 06/03/13 20:15, Nathan Scott wrote:
On comma 3.6.11 i386 Darwin 10.8.0, the build of the logger PMDA
fails
Fixed now (dev 76becf8).
Confirmed, thanks.
On vm18 3.6.11 x86_64 LinuxMint 12 (lisa) the build dies a horrible
death in the python code with ...
I *think* this is from pyversions -nr returning more versions of
python than are installed on the machine. I think in turn this
is because the build dependency is not ensuring python2.6 is there.
I've attempted a fix: dev b8f72f3 not 100% certain though - seems
like it might work.
OK this is more broken than I thought ... pyversions -vr (no -n) returns
as follows:
LinuxMint _sometimes_
2.6 2.7
but most of time
pyversions: error parsing Python-Version attribute
On all the other Debian and Ubuntu systems the answer is
pyversions: error parsing Python-Version attribute
_if_ it returns "2.6 2.7" the build breaks, otherwise the for loop in
debian/rules is not run (which also seems bad).
This is not doing anything to make we want to learn python!
...
lock.c:94:12: warning: ignoring return value of âstrerror_râ,
declared with attribute warn_unused_result [-Wunused-result]
Need to be careful here - strerror_r on Mac OS X returns int,
but char* on Linux. These could be replaced with pmErrStr()
calls perhaps?
Yep, I'll change these to use pmErrStr_r() which will work just fine in
this context.
On vm04 3.7.0 i586 CentOS 5.9 (Final)
>> ...
the linux pmda
pmda.c:732: warning: ârightnowâ may be used uninitialized in this
function
Fixed. (dev 083a173)
Confirmed, thanks.
On vm05 3.7.0 i486 Gentoo 2.0.3 pmcd dies
Starting pmcd ...
[Wed Mar 6 16:13:51] pmcd(1293) Error: OpenRequestSocket(44321,
INADDR_ANY) __pmCreateSocket: Address family not supported by
protocol
[Wed Mar 6 16:13:51] pmcd(1293) Error: pmcd: can't open any request
ports, exiting
[Wed Mar 6 16:13:51] pmcd(1293) Error: pmcd not started due to
errors!
Hmm, this is probably the most concerning. What does ifconfig on
this host report? This looks like it might be an IPv6-related
regression, possibly, Dave?
Nothing obviously interesting from ifconfig ...
kenj@vm05:~$ /sbin/ifconfig -a
eth0 Link encap:Ethernet HWaddr 52:54:00:73:7d:3a
inet addr:192.168.1.205 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:15213 errors:0 dropped:0 overruns:0 frame:0
TX packets:480 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2225766 (2.1 MiB) TX bytes:78938 (77.0 KiB)
Interrupt:11
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:12 errors:0 dropped:0 overruns:0 frame:0
TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:600 (600.0 B) TX bytes:600 (600.0 B)
And detailed diags are not helping (hint, hint, ...)
kenj@vm05:~/src/pcp/src/pmcd/src$ ./pmcd -Dall -f
AddRequestPort: INADDR_ANY port 44321
__pmSetSocketIPC: fd=3
IPC table fd(PDU version):
pmGetConfig: PCP_TMP_DIR=/var/tmp
[Thu Mar 7 06:57:01] pmcd(1699) Error: OpenRequestSocket(44321,
INADDR_ANY) __pmCreateSocket: Address family not supported by protocol
I'd like to get back to a point where we get some Windows servers
into the mix, somehow, but really don't have a good way to reach
that point (licensing issues, packaging issues, etc). Perhaps we
could approach the Aconex folks for assistance with getting a
licensed VM into the farm? (and then just keep git builds rolling
forward until an opportunity to tackle packaging next presents).
I have a Windows 8 VM there with a pre-release developer licence (that
may or may not still work), but the biggest obstacle is there is no
reliable recipe for creating a build environment with MSYS et al to
create installable packages.
|