L-Breeder is currently marked unfetchable:
http://people.freebsd.org/~fenner/portsurvey/biology.html#L-Breeder
So I tried to investigate the problem and I'm now submitting
my homework so it doesn't get lost.
This is what I noticed:
i) L-Breeder upstream sources have "stagnated for some time,
but now a new simplified version is available" (sic, from
the web site)
So, the fetch issue is resolved. And the pkg-descr is also
updated to reflect the new home page. However:
ii) L-Breeder is now called LBreeder. I have changed PORTNAME
to reflect this, although I don't know if this is the right
thing to do. Should the port be moved to biology/LBreeder?
Or perhaps just leaving PORTNAME pointing to the old name
and then work inside the Makefile to point the build/install
to the correct name?
iii) the sources have been reorganized so I have to update
the port's Makefile to reflect this. The attached patch
works for me under FreeBSD-4.11 (although it's possible
that I may have missed a dependency if I already have a
required library installed in my box. Sorry, I don't have
a tinderbox-like setup to test builds)
iv) the program does not have a version number, nor did I
find one by looking inside the sources. To avoid changing
too much the port I just left PORTVERSION at 1.0 and bumped
PORTREVISION to 6
Finally, do note that I am not a user of LBreeder, so I
cannot test the program myself. I just noticed that by
calling the executable I get a black X screen, that I can
quit by pressing 'q' as documented in Readme.txt, but I
can't tell myself if this is the expected behaviour. Nor
do I know how to use the example files. Caveat emptor.
PR: ports/90073
Submitted by: Fernan Aguero <fernan@iib.unsam.edu.ar>
Approved by: maintainer timeout
Nepenthes can determine the malware activity on a network
by deploying a nepenthes sensor (i.e. honey pot). The
programm emulates different well known vulnerabilities
waiting for malicious connections trying to exploit them.
WWW: http://nepenthes.sourceforge.net
PR: ports/90062
Submitted by: ryo <ryo@aquahill.net>
devel/ode and devel/ode-devel ports are marked broken on
non-i386 archs (i.e. amd64, ia64), because ode fail to build
on these systems with following errors:
c++ -Iinclude -c -fno-exceptions -fomit-frame-pointer -O -pipe -I/usr/X11R6/include
+-DdNODEBUG -o ode/src/timer.o ode/src/timer.cpp
{standard input}: Assembler messages:
{standard input}:62: Error: `(%esi)' is not a valid 64 bit base/index expression
{standard input}:63: Error: `4(%esi)' is not a valid 64 bit base/index expression
{standard input}:86: Error: `(%esi)' is not a valid 64 bit base/index expression
{standard input}:87: Error: `4(%esi)' is not a valid 64 bit base/index expression
{standard input}:172: Error: `(%esi)' is not a valid 64 bit base/index expression
{standard input}:173: Error: `4(%esi)' is not a valid 64 bit base/index expression
{standard input}:194: Error: `(%esi)' is not a valid 64 bit base/index expression
{standard input}:195: Error: `4(%esi)' is not a valid 64 bit base/index expression
{standard input}:234: Error: `(%esi)' is not a valid 64 bit base/index expression
{standard input}:235: Error: `4(%esi)' is not a valid 64 bit base/index expression
gmake: *** [ode/src/timer.o] Error 1
*** Error code 2
Stop in /usr/ports/devel/ode.
After some investigation, I think I've solved the problem,
and it would be great to unbreak ode at last.
The build on 64 bit platforms fails because some 32 bit
assembly gets included in the ode/src/timer.cpp file.
That, on it's turn, happens because ode's configurator
(simple configure analogue written in C) has too weak
checking for `pentium compatibility' of host system - it
just tries to compile following assembly code: `mov $0,
%eax' as a test. That compiles well on 64 bit platforms,
but because addressing scheme is now 64bit, above-mentioned
errors occur when compiling ode's source itself.
The fix is to add a patch to configurator.c that makes
`pentium compatibility' test more strict. Thus, test will
fail on 64 bit ystems and i386 assembly won't be used (ode
will use more portable routines instead).
This patch is not well tested, as I myself have no 64 bit
machines in the vicinity, but it surely doesn't break ode
on x86 :)
I've mailed it to ode author, it's now also in ODE's CVS.
PR: ports/90077
Submitted by: Dmitry Marakasov <amdmi3@mail.ru>
Approved by: maintainer timeout
Upgrade to the latest, 0.8, version. I've removed the patch
because it's already commited to this version by the vendor.
PR: ports/90208
Submitted by: Denis Shaposhnikov <dsh@vlink.ru>
Approve by: maintainer timeout
one or more memcached servers. Apart from being very similar to the API
of Cache::Memcached, the Cached::Memcached::Managed API allows for
management of groups of values, for simplified key generation and expiration,
as well as version and namespace management and a few other goodies.
WWW: http://search.cpan.org/dist/Cache-Memcached-Managed/
PR: ports/91203
Submitted by: Lars Balker Rasmussen <lars@balker.dk>
Thank you for reporting. I also discovered this problem a few hours ago.
The source of this trouble is that the following line exists in MOVED,
lang/php4|lang/php4|2003-05-22|re-separated from www/mod_php4
where "moved from" and "moved to" is the same, but portupgrade
does not check this case and infinite loop occurs.
Fix to this problem will be in the next portupgrade release,
but in the meanwhile, whould you commit the following patch,
please?
PR: ports/91209
Submitted by: KOMATSU Shinichiro <koma2@lovepeers.org>
Add following install time options for update.sh
- Whether or not /var/log/cvsup.log is rotated when update.sh
is invoked.
- Maximum number of log files.
- Wheter or not old log file is gzipped after rotated.
PR: ports/81598
Submitted by: KIMURA Yasuhiro <yasu@utahime.org>
Not objected by: jdp@FreeBSD.org
John Walker's moontool for the X11 desktop. It shows a
real-time picture of the moon phases and displays some
related astronomical data about the moon and the sun. --
This version of the program uses the Motif toolkit.
WWW: http://www.fourmilab.ch/nav/topics/astrospace.html
PR: ports/91187
Submitted by: Frank W. Josellis <frank@dynamical-systems.org>
When I ported this I added amd64 to give the "benefit of
doubt" however I had the chance top test it but it doesn't
work, it coredumps.
PR: ports/91188
Submitted by: Pedro F. Giffuni <giffunip@asme.org>
