Re: Rubygems and trouble with rdoc node renumbering
On Sat, 26.04.2008 at 00:18:25 +0200, Henrik Brix Andersen wrote: > On Fri, Apr 25, 2008 at 09:59:33PM +0200, Ulrich Spoerlein wrote: > > I'm trying to update rubygem-rgl and the rdoc part is giving me a > > headache, as the rdoc will obviously use readdir() only to walk the > > directory tree *but* gives each of its HTML pages a unique number. > > > > The upshot is, that my pkg-plist is changing every time I install the > > port. That's a big problem since the rdoc is also run on do-install and > > I'm not sure I could generate the pkg-plist dynamically *after* that > > step. > > Just out of curiousity - what type of filesystem is WRKDIRPREFIX > pointed at? ZFS? Heh, well, that's exactly what I thought about, 5 minutes after sending that email! Yes, I'm running /usr and the WRKDIRPREFIX on ZFS. I haven't compared, if it is responsible for shuffling around the order in which directories are written (or read). Anyway, this means that almost all rdoc ports will break their pkg-plist when you compile/create them on an ZFS system. I will test with UFS today and also run some other rdoc-using ports on my ZFS to see if this is general problem or only specific to my port. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: long descriptions in OPTIONS
On 4/25/08, Wesley Shields <[EMAIL PROTECTED]> wrote:
> Based upon an idea in an earlier thread on this list[1] I came up with
> two ways of adding an extended description to our existing OPTIONS
> framework.
>
> 1: Extend the OPTIONS to be 4 fields instead of the current 3 fields.
> The 4th field would be the long description - providing more detailed
> information about what this option does or supports. In order to
> distinguish between a port with 4 OPTIONS without the long description
> (12 fields) and a port with 3 OPTIONS with the long description (also 12
> fields) the patch requires the port to turn on a knob (OPTIONS_DESC)
> when using the long field. The idea is that over time this will become
> the default and can eventually be removed.
>
> 2: Leave OPTIONS as is but support a DESC_FOO variable for each OPTION.
> This variable would be the long description field, and if it doesn't
> exist a default message indicating such would be displayed.
>
> Both of these methods are displayed to the user when '?' or F1 is
> pressed during the dialog screen. In the case of (1) the extra dialog
> is only shown if the port supports it. In the case of (2) the extra
> dialog is always available since we have a default message to display.
> I suppose a third way would be to use a default message when the knob is
> not set for (1), which would probably simplify things slightly.
>
Couple of suggestions:
- OPTION_DESC (choice 1) or DESC_FOO (choice 2) not defined, then use
field 2 as the long description along with "[NO EXTENDED DESCRIPTION
DEFINED]" appended.
- Remove "Contact the maintainer to fix this" from choice 2, as some
maintainers may resent being contacted by users to add extended
descriptions to their ports.
- Use OPTION_DESC_FOO instead of DESC_FOO (choice 2).
- add support for ${PORTSDIR}/MK/bsd.optiondescription.mk, This file
holds a list of standard extended option descriptions, for example:
_STD_DESC_A4SIZE= "Sets the default paper size used by ${PORTNAME} -
A4 (210 mm × 297 mm) or Letter (8½ in × 11 in, 215.9 mm × 279.4 mm)"
The following code, should accomplish the above for choice 2:
LONGDESC=$$(cd ${.CURDIR} && ${MAKE} ${__softMAKEFLAGS} -V OPTION_DESC_$$1); \
if [ "x$${LONGDESC}" = "x" ] ; then \
LONGDESC=$$(cd ${.CURDIR} && ${MAKE} ${__softMAKEFLAGS} -V
_STD_DESC_$${1}); \
if [ "x$${LONGDESC}" = "x" ]; then \
LONGDESC="$$2 [NO EXTENDED DESCRIPTION DEFINED]" ; \
fi ; \
fi ; \
${ECHO_CMD} $$1: $${LONGDESC} | fmt >> $${TMPOPTIONDESCFILE}; \
${ECHO_CMD} >> $${TMPOPTIONDESCFILE}; \
Scot
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help requested with fixing after ImageMagick update
On Sat, 26 Apr 2008 01:39:00 +0200 Pav Lucistnik <[EMAIL PROTECTED]> wrote: > Hi folks, > > we had a rather intrusive ImageMagick update recently, which left some > ports broken. Since it's quite a task for a single guy to fix them > all, I'd like to ask you folks to help out with this. > > This is a list of known breakages: > > science/gnudatalanguage > textproc/htmltolatex > graphics/kallery > graphics/php-magickwand > lang/q > graphics/reallyslick > graphics/ruby-rmagick Usually, I have no major problems updating ports. I use 'portupgrade' as my usually ports maintenance tool. However, in case like this I prefer 'portmanager'. It seems to correct problems with dependencies much better than 'portupgrade'. I would recommend that you do something like this: 1) If portmanager is not installed, install it. 2) Update your ports tree 3) Run: portmanager -u -l -p -y That should update all of your ports and force a rebuild of any port using an old or out dated dependency. It will also create a log file in: '/var/log/portmanager.log'. This usually works for me. Good luck! -- Gerard [EMAIL PROTECTED] Most people in this society who aren't actively mad are, at best, reformed or potential lunatics. Susan Sontag signature.asc Description: PGP signature
Re: help requested with fixing after ImageMagick update
Gerard wrote: On Sat, 26 Apr 2008 01:39:00 +0200 Pav Lucistnik <[EMAIL PROTECTED]> wrote: Hi folks, we had a rather intrusive ImageMagick update recently, which left some ports broken. Since it's quite a task for a single guy to fix them all, I'd like to ask you folks to help out with this. This is a list of known breakages: science/gnudatalanguage textproc/htmltolatex graphics/kallery graphics/php-magickwand lang/q graphics/reallyslick graphics/ruby-rmagick Usually, I have no major problems updating ports. I use 'portupgrade' as my usually ports maintenance tool. However, in case like this I prefer 'portmanager'. It seems to correct problems with dependencies much better than 'portupgrade'. I would recommend that you do something like this: 1) If portmanager is not installed, install it. 2) Update your ports tree 3) Run: portmanager -u -l -p -y That should update all of your ports and force a rebuild of any port using an old or out dated dependency. It will also create a log file in: '/var/log/portmanager.log'. This usually works for me. Good luck! Portmanager cannot work around changed library names either. The ports have to be fixed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Building new port, don't want to run as root
Hi all, I'm working on a patch to upgrade a port I maintain, however the new version (smartly) refuses to be run by root. I fished through the Porter's Handbook a bit but was unable to find anything in particular on running the port as another user. Can anyone point me in the right direction? Thanks... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mailman2.1.x and python2.5 in a jail
Helmut Schneider wrote:
[EMAIL PROTECTED] ~]# chroot -u root /home/python25/
/usr/local/mailman/bin/mailmanctl
Traceback (most recent call last):
File "/usr/local/mailman/bin/mailmanctl", line 107, in
from Mailman import Utils
File "/usr/local/mailman/Mailman/Utils.py", line 32, in
import sha
File "/usr/local/lib/python2.5/sha.py", line 6, in
from hashlib import sha1 as sha
File "/usr/local/lib/python2.5/hashlib.py", line 133, in
md5 = __get_builtin_constructor('md5')
File "/usr/local/lib/python2.5/hashlib.py", line 60, in
__get_builtin_constructor
import _md5
ImportError: No module named _md5
[EMAIL PROTECTED] ~]#
you would need all libraries required by
/usr/local/lib/python2.5/lib-dynload/*.so available in the jail too.
$ ldd /usr/local/lib/python2.5/lib-dynload/*.so | grep -v ^/ | cut -d '
' -f 3 | sort -u
/lib/libcrypt.so.3
/lib/libcrypto.so.4
/lib/libm.so.4
/lib/libncurses.so.6
/lib/libreadline.so.6
/lib/libz.so.3
/usr/lib/libbz2.so.2
/usr/lib/libpanel.so.3
/usr/lib/libssl.so.4
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
lzma: invalid option -- s
This might be interesting to multiple ports: 7.0-R, fresh portsnap. # portmaster -bad ... ===>>> Gathering dependency list for graphics/ImageMagick from ports ===>>> Starting dependency check ===>>> The dependency for archivers/lzma seems to be handled by lzmautils-4.32.5 ... ===> Extracting for ImageMagick-nox11-6.4.0.7 => MD5 Checksum OK for ImageMagick-6.4.0-7.tar.lzma. => SHA256 Checksum OK for ImageMagick-6.4.0-7.tar.lzma. ===> ImageMagick-nox11-6.4.0.7 depends on executable: lzma - found ===> ImageMagick-nox11-6.4.0.7 depends on file: /usr/local/bin/perl5.8.8 - found /usr/local/bin/lzma: invalid option -- s ^ Replacing lzmautils-4.32.5 with archivers/lzma fixes this. regards, Hans Lambermont ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
www/linuxpluginwrapper on FreeBSD 7.x
G'day, I notice that linuxpluginwrapper is marked as IGNORE on FreeBSD 7.x (and later) because it does not support ELF symbol versioning. Can you please advise what is involved in correcting this and whether you have any plans to update this port. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpVlPX4sRTpW.pgp Description: PGP signature
Re: www/linuxpluginwrapper on FreeBSD 7.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 27, 2008 at 06:45:22AM +1000, Peter Jeremy wrote: > G'day, > > I notice that linuxpluginwrapper is marked as IGNORE on FreeBSD 7.x > (and later) because it does not support ELF symbol versioning. Can > you please advise what is involved in correcting this and whether > you have any plans to update this port. Please use www/nspluginwrapper. - - Martin > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. - -- +---+---+ | PGP: 0x05682353 | Jabber : miwi(at)BSDCrew.de | | ICQ: 169139903 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIE5gSFwpycAVoI1MRArcxAJ0dBYeFsNViMU1U5+vcLWXI1ZGOUwCfRN37 7jv8Xj1pbQPYQkOVilx1RKM= =sIlR -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dns/nss_mdns: getaddrinfo() doesn't return IPv6 address on getaddrinfo()
Hi,
Whenever I execute getaddrinfo() function from libc with a 'hostname.local'
address as an argument and AF_INET6 as ai.ai_family, I get an IPv4
address, even when 'avahi-resolve-host-name -6 hostname.local' returns
an IPv6 address.
I've written a test program getaddrinfo.c[1] which does a
getaddrinfo() function call and prints the result on the terminal.
Following is the patch to port dns/nss_mdns which will fix this issue:
>8>8-
diff -urN /usr/ports/dns/nss_mdns/Makefile nss_mdns/Makefile
--- /usr/ports/dns/nss_mdns/Makefile2008-01-03 17:53:37.0 +0530
+++ nss_mdns/Makefile 2008-04-27 01:22:10.0 +0530
@@ -7,7 +7,7 @@
PORTNAME= nss_mdns
PORTVERSION= 0.9
-PORTREVISION= 5
+PORTREVISION= 6
CATEGORIES=dns ipv6
MASTER_SITES= http://0pointer.de/lennart/projects/nss-mdns/
DISTNAME= nss-mdns-${PORTVERSION}
diff -urN /usr/ports/dns/nss_mdns/files/patch-src__bsdnss.c
nss_mdns/files/patch-src__bsdnss.c
--- /usr/ports/dns/nss_mdns/files/patch-src__bsdnss.c 2007-04-12
16:13:15.0 +0530
+++ nss_mdns/files/patch-src__bsdnss.c 2008-04-27 01:19:18.0 +0530
@@ -197,7 +197,7 @@
+ * 2. Map hostent to addrinfo.
+ * 3. Hand-off buffer to libc.
+ */
-+ status = _nss_mdns_gethostbyname_r(name, hp, buffer, mbuflen,
++ status = _nss_mdns_gethostbyname2_r(name, pai->ai_family, hp, buffer,
mbuflen,
+ &_errno, &_h_errno);
+ status = __nss_compat_result(status, _errno);
+
8<8<
If required I'll submit a PR for this.
References:
[1] - http://pastebin.com/f20d45049
Thanks
--
Ashish Shukla आशीष शुक्ल http://wahjava.wordpress.com/
·-- ·- ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
pgpR2xVXUou89.pgp
Description: PGP signature
Re: www/linuxpluginwrapper on FreeBSD 7.x
On Sat, Apr 26, 2008 at 11:01:07PM +0200, Martin Wilke wrote: >On Sun, Apr 27, 2008 at 06:45:22AM +1000, Peter Jeremy wrote: >> I notice that linuxpluginwrapper is marked as IGNORE on FreeBSD 7.x >> (and later) because it does not support ELF symbol versioning. Can >> you please advise what is involved in correcting this and whether >> you have any plans to update this port. > >Please use www/nspluginwrapper. As far as I can tell, nspluginwrapper only builds/installs libxpcom.so and npwrapper.so. Based on the description, this port is solely designed to support Netscape plugins. linuxpluginwrapper provides more general plugin support. I my case, I needs pips.so to support print/pips-scx3500_3600s - this doesn't appear to be possible using nspluginwrapper. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgp1JUvvHOxfI.pgp Description: PGP signature
