FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/audacious-crossfade broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=audacious-crossfade portname: audio/ecamegapedal broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ecamegapedal portname: audio/lmms broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=lmms portname: chinese/chinput3 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=chinput3 portname: comms/asmodem broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=asmodem portname: comms/ltmdm broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=ltmdm portname: comms/yawmppp broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=yawmppp portname: databases/p5-sqlrelay broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=p5-sqlrelay portname: devel/ace+tao broken because: Does not compile on FreeBSD = 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ace%2Btao portname: devel/fampp broken because: FAM system mismatch: gamin is installed, while desired FAM system is fam build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=fampp portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=gcvs portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=linuxthreads portname: devel/ngpt broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=ngpt portname: devel/p5-ORBit broken because: Does not compile with GCC 4.2 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=p5-ORBit portname: editors/ved broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=ved portname: emulators/p-interp broken because: size mismatch build errors: none. overview:
FreeBSD ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as broken in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/audacious-crossfade broken because: Does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=audacious-crossfade portname: audio/aureal-kmod broken because: doesn't build on RELENG_8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=aureal-kmod portname: audio/ecamegapedal broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ecamegapedal portname: audio/ecawave broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=ecawave portname: audio/emu10kx broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=emu10kx portname: audio/gmpc-mserver broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gmpc-mserver portname: audio/lmms broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=lmms portname: audio/muse broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=muse portname: benchmarks/polygraph broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/polygraph-3.0.6_1.log (_Mar_21_01:42:24_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarksportname=polygraph portname: benchmarks/polygraph31 broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/polygraph31-3.1.5_1.log (_Mar_21_01:42:25_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarksportname=polygraph31 portname: cad/alliance broken because: incomplete plist build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=alliance portname: cad/tclspice broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cadportname=tclspice portname: chinese/chinput3 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=chinput3 portname: comms/asmodem broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=asmodem portname: comms/hcfmdm broken because: Does not compile at 7.x or higher build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=commsportname=hcfmdm portname: comms/hso-kmod broken because: does not build with USB2, please try comms/uhso-kmod instead build errors:
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: archivers/py-tarfile description:Python library for reading and writing tarballs maintainer: po...@freebsd.org deprecated because: all development activity in this port has been merged into mainline python after 2.4 expiration date:2010-08-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=py-tarfile portname: graphics/lphoto description:A complete desktop solution for digital photo management maintainer: po...@freebsd.org status: IGNORE deprecated because: broken expiration date:2010-03-30 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=lphoto portname: mail/ngmp description:A full AJAX based web app for messaging and collaboration maintainer: po...@freebsd.org status: BROKEN deprecated because: does not compile and no longer supported by upstream expiration date:2010-08-18 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mailportname=ngmp portname: net-mgmt/net-snmp4 description:An extendable SNMP implementation maintainer: po...@freebsd.org status: BROKEN deprecated because: Use net-mgmt/net-snmp port instead expiration date:2009-07-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmtportname=net-snmp4 portname: net-p2p/javadc description:Open source Java DirectConnect (TM) command-line client maintainer: po...@freebsd.org status: IGNORE deprecated because: is ancient, unmaintained, works only with JDK 1.3, no master site expiration date:2010-08-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-p2pportname=javadc portname: net/pathchar description:LBNL Internet path characterization tool maintainer: po...@freebsd.org status: IGNORE deprecated because: has been broken for 2+ years, no sources available expiration date:2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=netportname=pathchar portname: sysutils/aaccli description:Adaptec SCSI RAID administration tool maintainer: po...@freebsd.org deprecated because: see sysutils/arcconf instead, no longer maintained by Adaptec expiration date:2010-05-11 build errors: http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20100305224420/aaccli-1.0.log.bz2 (_Feb_23_14:20:04_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=sysutilsportname=aaccli portname: textproc/py-xmltools description:High level XML tools for Python maintainer: po...@freebsd.org status: BROKEN deprecated because: has been broken for 4 months expiration date:2010-01-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=textprocportname=py-xmltools portname: www/linux-nvu description:A complete Web Authoring System maintainer: po...@freebsd.org deprecated because: NVU 1.0, released June 2005, is the last official release of NVU. Kompozer has picked up where NVU has left off. Please consider using /home/linimon/ports/www/kompozer instead expiration date:2010-08-05 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=wwwportname=linux-nvu ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: archivers/py-tarfile description:Python library for reading and writing tarballs maintainer: po...@freebsd.org deprecated because: all development activity in this port has been merged into mainline python after 2.4 expiration date:2010-08-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=archiversportname=py-tarfile portname: devel/p5-P4-Client description:P4::Client - Perl extension for the Perforce API maintainer: to...@freebsd.org status: BROKEN deprecated because: has been broken for 11 months expiration date:2010-01-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=p5-P4-Client portname: editors/koffice-kde4-l10n-fy description:Frisian messages and documentation for KOffice2 maintainer: k...@freebsd.org status: IGNORE deprecated because: expiration date:2010-08-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=koffice-kde4-l10n-fy portname: editors/koffice-kde4-l10n-hne description:Chhattisgarhi messages and documentation for KOffice2 maintainer: k...@freebsd.org status: IGNORE deprecated because: expiration date:2010-08-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=koffice-kde4-l10n-hne portname: editors/koffice-kde4-l10n-wa description:Walloon Bokmaal messages and documentation for KOffice2 maintainer: k...@freebsd.org status: IGNORE deprecated because: expiration date:2010-08-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=editorsportname=koffice-kde4-l10n-wa portname: graphics/lphoto description:A complete desktop solution for digital photo management maintainer: po...@freebsd.org status: IGNORE deprecated because: broken expiration date:2010-03-30 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=lphoto portname: graphics/xaralx description:Top-tier vector/general purpose graphics program (recommended version) maintainer: v...@freebsd.org status: IGNORE deprecated because: Does not compile with png-1.4 and latest version is from Aug 2006 expiration date:2010-06-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=xaralx portname: graphics/xaralx-devel description:Top-tier vector/general purpose graphics program (development version) maintainer: v...@freebsd.org status: IGNORE deprecated because: Does not compile with png-1.4 and latest version is from Aug 2006 expiration date:2010-06-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=xaralx-devel portname: japanese/samba3 description:Japanese Samba maintainer: kuriy...@freebsd.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date:2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=samba3 portname: java/eclipse-emf description:Eclipse Modeling Framework maintainer: freebsd-ecli...@freebsd.org deprecated because: This plugin can be installed from within eclipse via the updater expiration date:2010-01-19 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=javaportname=eclipse-emf portname: java/eclipse-gef description:Graphical Editing Framework for the Eclipse IDE maintainer: freebsd-ecli...@freebsd.org deprecated because: This plugin can be installed from within eclipse via
FreeBSD unmaintained ports which are currently marked forbidden
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=miscportname=compat3x ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports which are currently marked forbidden
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: databases/gnats forbidden because: Security issues build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=gnats portname: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=miscportname=compat3x ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LICENSE_FILE=${WRKSRC}/LICENSE
ash...@freebsd.org (Ashish SHUKLA) writes:
Anonymous writes:
ash...@freebsd.org (Ashish SHUKLA) writes:
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/146513
Why do you need to copy license file in post-extract?
I added because specifying '${WRKSRC}/LICENSE' as 'LICENSE_FILE' results in
a conflict because License infrastructure in ports system also creates a
file
named LICENSE. So, I'm just copying it to some name other than LICENSE, and
than mentioning that in the LICENSE_FILE.
Ah, so you're referring to _LICENSE_REPORT that's created in_LICENSE_DIR.
It's not just the case of a single license file named `LICENSE' but multiple
licenses with same filename but in different directories are affected as
well.
Does the following diff fixes it for you?
Yes, the following diff works fine and I don't have to rename LICENSE file
anymore.
[...]
I've filed ports/148808 for the sweeping change so it's not forgotten
after 8.1-RELEASE is out.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LICENSE_FILE=${WRKSRC}/LICENSE
Anonymous writes:
ash...@freebsd.org (Ashish SHUKLA) writes:
Anonymous writes:
ash...@freebsd.org (Ashish SHUKLA) writes:
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/146513
Why do you need to copy license file in post-extract?
I added because specifying '${WRKSRC}/LICENSE' as 'LICENSE_FILE' results in
a conflict because License infrastructure in ports system also creates a
file
named LICENSE. So, I'm just copying it to some name other than LICENSE, and
than mentioning that in the LICENSE_FILE.
Ah, so you're referring to _LICENSE_REPORT that's created in_LICENSE_DIR.
It's not just the case of a single license file named `LICENSE' but multiple
licenses with same filename but in different directories are affected as
well.
Does the following diff fixes it for you?
Yes, the following diff works fine and I don't have to rename LICENSE file
anymore.
[...]
I've filed ports/148808 for the sweeping change so it's not forgotten
after 8.1-RELEASE is out.
Great :)
--
Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0
freebsd.org!ashish | http://people.freebsd.org/~ashish/
“Will this gun not make war more terrible? No, it will make war
impossible.” (Hudson Maxim, inventor of the machine gun, 1893)
pgppwmIYiwFjN.pgp
Description: PGP signature
Re: FreeBSD ports Problem Reports for ports you maintain
lini...@freebsd.org writes: Hello, The PRs are listed below. PR number: 87397 PR title: [patch] incorrect use of PAPERSIZE make variable in some ports category: print portname: lpr-wrapper submitter: ga...@zahemszky.hu arrival date: 2005-10-13 20:40:18 PR state: open URL:http://www.FreeBSD.org/cgi/query-pr.cgi?pr=87397 A followup has been submitted to the PR. Regards Eric Masson -- Mettre d'un coté ceux qui nous pompent l'air, de l'autre ceux qui brassent du vent. Nous obtiendrons un Usenet climatisé, c'est ça le génie français. Ca risque même d'être un peu trop ventilé. -+- MP in http://www.le-gnu.net : Clim et châtiment -+- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: moinmoin-1.9.2_3
Hi, this is a problem.
a standalone server should start with
$MOINDEST/server/moin server standalone
I will modify Makefile to fit this changes.
Thanks
On Wed, Jun 30, 2010 at 4:40 PM, Stephen Morton tungolcra...@gmail.com wrote:
The current version of the moinmoin port seems to be pretty broken when it
comes to running it as a standalone thing. 'make instance' tries to copy a
file that doesn't exist:
sudo make MOINTYPE=STANDALONE MOINDEST=/usr/local/www/wiki instance
Set MOINTYPE=(CGI|FCGI|WSGI|STANDALONE) to define
type of installation. Default is CGI.
Use MOINDEST=/path to modify installation destination.
Default value for MOINDEST is /usr/local/www/wiki.
To get correct permissions, please set CGIUSER, CGIGROUP
per default it is set to www:www.
Creating a new wiki instance in /usr/local/www/wiki.
install: /usr/local/share/moin/server/wikiserver.py: No such file or directory
*** Error code 71
and the instructions for package install specify a different file that
doesn't exist: ${MOINDIR}/server/moin.py
I suspected that wikiserver.py is the proper file, and I copied it over from
the initial tarball and got everything to run, but then I run into the
problem of config. The file server/wikiserverconfig.py should get copied over
as well, although I can't seem to make the server respect all the options I
set. In particular, I could get it to change port and to drop root
privileges, but it wouldn't bind to something besides localhost. I don't know
what was going on there.
Additionally, dropping root privileges seemed to happen at the wrong time,
because if I told it to run on port 80 and drop off of root, it seems to drop
root before it binds to the port, and so fails to do so. I'm getting the same
behavior out of running straight from the tarball though, so that's probably
something I'm doing wrong.
Anyway, thought I'd let you know. I'm running python from the python
metaport, uname -a
FreeBSD [hostname removed] 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21
15:02:08 UTC 2009 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
Any other information you'd like, just ask.
--
A man live in jail and want to break.
http://blog.khsing.net
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Wordpress outputs an empty page after ports upgrade
- Original Message - From: Yuri y...@rawbw.com No, look at ports-mgmt/portupgrade, it is capable of upgrading ports in-place quite happily in most cases. With the caveat that there might be some special steps that need to be taken not covered by port itself. This usually happens when dependencies split or being renamed or some other wild change that isn't covered by the standard process. But in the case of wordpress no special record has been placed into /usr/ports/UPDATING, which means that portupgrade should be sufficient. I'm sorry but your wrong, as you can clearly see from the port Makefile. Yes /usr/ports/UPDATING can be helpful but in this case the warning is presented by the pre-everything target which you will likely miss if your using portupgrade. All portupgrade does is manage the process of uninstalling the old version and installing the new version. So its generally fine for binary only packages but for those that include data which needs special handling on upgrade such as wordpress, perl, mysql etc you still need to do those processes manually. I'd suggest restoring you pre-upgrade backup of both files and db and perform a manual upgrade as per the wordpress guide. http://codex.wordpress.org/Upgrading_WordPress This is quite unpractical with many packages installed on the system. Also WP has an embedded DB update process that is activated automatically when you first run after system upgrade. This makes manual upgrade redundant (at least theoretically). Absolutely not, ALWAYS backup your data before each upgrade, its the only way to be sure you don't loose things if something goes wrong. In addition be especially careful with major version upgrades like 2.9 - 3.0 as they often have additional caveats. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: opera-10.10.20091120_2
Good morning, is there a plan to upgrade the FreeBSD Opera port to the latest version (10.60)? Yours sincerely -- Marco Alberoni ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [new port] usage of shar command
The major problems with backticks is that they tend to be inconspicuous (and easily confused with bits of dust or fly-droppings) and are often difficult to distinguish from quotes. Rather than write `find port_dir` (note the backticks), IMO, it is far easier to write $(find port_dir) - which is syntactically the same but visually more obvious. That's a fair point. Do you think that the text as it currently exists is sufficiently clear, or do you think that it still needs the modification you're suggesting? I'm happy to make the change (or someone else can if they so desire) if that's what people thing is the right way to go. Doug The text as its currently exists is a long way from being clear to a first timer. And I am talking about the new change that just went in. shar `find port_dir` (note the backticks), or shar $(find port_dir) both address the problem nicely. By all means go and make the correction. I'd second making it clearer, certainly: shar `find port_dir` threw me when I first started writing ports and was looking to submit my work. I think part of the issue was just I'd never used the shell archive command before so I had no idea quite what 'shar' actually was. Perhaps adding a one liner to explain what is actually going to happen and why your doing it might be useful? Personally I think the second suggestion of shar $(find port_dir) is the better one, it's far less likely to get mangled by font display and I expect it's easier for people to located $() on their keyboards than ` (backtick) Regards Eric ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 21/07/2010 03:07, Wesley Shields wrote: Dan, my initial testing indicates that this allows the port to build. I'd appreciate another set of eyeballs on it though. Please let me know if you would like me to commit this patch or not. http://people.freebsd.org/~wxs/bacula-unbreak.diff -- WXS I applied the patch on a couple of VMs I'm using as a dev system, and it's been chugging away happily all morning. Looks good. Cheers Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
Il 07/19/10 12:33, Matthew Seaman ha scritto: Would it be sensible to make either WITH_POSTGRESQL or WITH_MYSQL the default options setting for this port rather than WITH_SQLITE? In my experience for backing up any reasonably sized system, you do need a fully competent RDBMS for the bacula catalog. Also, please, another request: out of the box, there are no options for the query command (/usr/local/share/bacula/query.sql is empty); the manual suggests examples/sample-query.sql to start with, but this is not installed. Could it be? bye Thanks av. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: opera-10.10.20091120_2
Marco Alberoni writes: Good morning, is there a plan to upgrade the FreeBSD Opera port to the latest version (10.60)? Ask the maintainer. :-) Robert Huff ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: opera-10.10.20091120_2
On Wed, 21 Jul 2010 13:42:52 +0200, Robert Huff roberth...@rcn.com wrote: Marco Alberoni writes: Good morning, is there a plan to upgrade the FreeBSD Opera port to the latest version (10.60)? Ask the maintainer. :-) He already did :). The PR for the port is under evaluation. Arjan -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
Sure, with the caveat that it could be the totally wrong fix for this
problem. ;)
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [new port] usage of shar command
On 21/07/2010 04:40, Joe wrote: Doug Barton wrote: On Wed, 21 Jul 2010, Peter Jeremy wrote: The major problems with backticks is that they tend to be inconspicuous (and easily confused with bits of dust or fly-droppings) and are often difficult to distinguish from quotes. Rather than write `find port_dir` (note the backticks), IMO, it is far easier to write $(find port_dir) - which is syntactically the same but visually more obvious. That's a fair point. Do you think that the text as it currently exists is sufficiently clear, or do you think that it still needs the modification you're suggesting? I'm happy to make the change (or someone else can if they so desire) if that's what people thing is the right way to go. Doug The text as its currently exists is a long way from being clear to a first timer. And I am talking about the new change that just went in. shar `find port_dir` (note the backticks), or shar $(find port_dir) This one doesn't work in (t)csh, the backticks do. both address the problem nicely. By all means go and make the correction. Object! Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
security/hydra and www/hydra
Good day!
We now have two ports with name 'hydra' in the tree, one in security
category, and one in www.
Both installs file ${PREFIX}/bin/hydra.
I firstly think about asking for add CONFLICTS line, but then come up
to ports tree should not have
two ports with same name.
What you think about this?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 7/21/2010 8:20 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
Sure, with the caveat that it could be the totally wrong fix for this
problem. ;)
I will consider that soon... However, this recent part is interesting:
http://marc.info/?l=bacula-develm=127971346713102w=2
In general, as far as I can tell, this occurs because you have
explicitly added /usr/local/lib to an environment variable that you feed
to the ./configure script. This should not really be necessary, because
if you let the configure figure out the libraries itself (aside from
the ones like postgres or mysql that you specify on a ./configure
option), it works on all other systems, and never experience this problem.
Do you think perhaps this is the culprit?
# make -V LDFLAGS
-L/usr/local/lib
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On Wed, Jul 21, 2010 at 09:09:22AM -0400, Dan Langille wrote:
On 7/21/2010 8:20 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
Sure, with the caveat that it could be the totally wrong fix for this
problem. ;)
I will consider that soon... However, this recent part is interesting:
http://marc.info/?l=bacula-develm=127971346713102w=2
In general, as far as I can tell, this occurs because you have
explicitly added /usr/local/lib to an environment variable that you feed
to the ./configure script. This should not really be necessary, because
if you let the configure figure out the libraries itself (aside from
the ones like postgres or mysql that you specify on a ./configure
option), it works on all other systems, and never experience this problem.
Do you think perhaps this is the culprit?
# make -V LDFLAGS
-L/usr/local/lib
Yes, but that is set in bsd.database.mk I believe.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [new port] usage of shar command
On 21/07/2010, at 10:56 PM, Dominic Fandrey wrote: On 21/07/2010 04:40, Joe wrote: Doug Barton wrote: On Wed, 21 Jul 2010, Peter Jeremy wrote: The major problems with backticks is that they tend to be inconspicuous (and easily confused with bits of dust or fly-droppings) and are often difficult to distinguish from quotes. Rather than write `find port_dir` (note the backticks), IMO, it is far easier to write $(find port_dir) - which is syntactically the same but visually more obvious. That's a fair point. Do you think that the text as it currently exists is sufficiently clear, or do you think that it still needs the modification you're suggesting? I'm happy to make the change (or someone else can if they so desire) if that's what people thing is the right way to go. Doug The text as its currently exists is a long way from being clear to a first timer. And I am talking about the new change that just went in. shar `find port_dir` (note the backticks), or shar $(find port_dir) This one doesn't work in (t)csh, the backticks do. both address the problem nicely. By all means go and make the correction. Object! find port_dir -print0 | xargs -0 -x shar Though it doesn't help when you've got too many files. Then you're probably better off with the tar command to generate shar files. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [new port] usage of shar command
On 21/07/2010 15:31, Sean wrote: On 21/07/2010, at 10:56 PM, Dominic Fandrey wrote: On 21/07/2010 04:40, Joe wrote: Doug Barton wrote: On Wed, 21 Jul 2010, Peter Jeremy wrote: The major problems with backticks is that they tend to be inconspicuous (and easily confused with bits of dust or fly-droppings) and are often difficult to distinguish from quotes. Rather than write `find port_dir` (note the backticks), IMO, it is far easier to write $(find port_dir) - which is syntactically the same but visually more obvious. That's a fair point. Do you think that the text as it currently exists is sufficiently clear, or do you think that it still needs the modification you're suggesting? I'm happy to make the change (or someone else can if they so desire) if that's what people thing is the right way to go. Doug The text as its currently exists is a long way from being clear to a first timer. And I am talking about the new change that just went in. shar `find port_dir` (note the backticks), or shar $(find port_dir) This one doesn't work in (t)csh, the backticks do. both address the problem nicely. By all means go and make the correction. Object! find port_dir -print0 | xargs -0 -x shar Though it doesn't help when you've got too many files. Then you're probably better off with the tar command to generate shar files. I know how to use shar. :) But I think the Handbook should have examples that work in the default shell. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [new port] usage of shar command
Sean s...@gothic.net.au writes: The text as its currently exists is a long way from being clear to a first timer. And I am talking about the new change that just went in. shar `find port_dir` (note the backticks), or shar $(find port_dir) This one doesn't work in (t)csh, the backticks do. both address the problem nicely. By all means go and make the correction. Object! find port_dir -print0 | xargs -0 -x shar Though it doesn't help when you've got too many files. Then you're probably better off with the tar command to generate shar files. BTW, do we still have *supported* release where tar(1) can't create shar archives? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster packages and perl upgrade
On Tue, 20 Jul 2010 14:45:18 PDT, Doug Barton wrote: soo ... is the blob that gets added to make.conf after you install ports-mgmt/portconf in both make.conf files? Yes. I'm thinking that packages/Latest/perl is stale. Can you check it? If it is stale, updating it should do the trick. If it's not, then there is more debugging to do. Thank you for that! After changing from... /usr/ports/packages/Latest/perl.tbz - ../All/perl-5.10.1_2.tbz to... /usr/ports/packages/Latest/perl.tbz - ../All/perl-5.12.1.tbz all works fine. I presume this is due to... ~/ports grep LATEST lang/perl5.*/Makefile lang/perl5.10/Makefile:LATEST_LINK= perl lang/perl5.12/Makefile:NO_LATEST_LINK= yes lang/perl5.8/Makefile:NO_LATEST_LINK= yes Thanks very much for portmaster! cheers, doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 7/21/2010 9:16 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 09:09:22AM -0400, Dan Langille wrote:
On 7/21/2010 8:20 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
Sure, with the caveat that it could be the totally wrong fix for this
problem. ;)
I will consider that soon... However, this recent part is interesting:
http://marc.info/?l=bacula-develm=127971346713102w=2
In general, as far as I can tell, this occurs because you have
explicitly added /usr/local/lib to an environment variable that you feed
to the ./configure script. This should not really be necessary, because
if you let the configure figure out the libraries itself (aside from
the ones like postgres or mysql that you specify on a ./configure
option), it works on all other systems, and never experience this problem.
Do you think perhaps this is the culprit?
# make -V LDFLAGS
-L/usr/local/lib
Yes, but that is set in bsd.database.mk I believe.
Recent posts to the thread pasted above indicate that is the cause of
the problem. Perhaps bsd.database.mk is 'the root of all evil'?
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
cvs-src writes:
Good day!
We now have two ports with name 'hydra' in the tree, one in security
category, and one in www.
Both installs file ${PREFIX}/bin/hydra.
I firstly think about asking for add CONFLICTS line, but then come up
to ports tree should not have
two ports with same name.
What you think about this?
In case of multiple ports installing files with same name at same path, then
one of them needs to alter the file names by using suffix or prefix, like GNU
projects do when they collide with BSD equivalents by using 'g' as prefix.
HTH
--
Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0
freebsd.org!ashish | http://people.freebsd.org/~ashish/
“Does history record any case in which the majority was right?”
(Robert A. Heinlein, 1973)
pgpgLYL7oGVvR.pgp
Description: PGP signature
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On Wed, Jul 21, 2010 at 12:37:29PM -0400, Dan Langille wrote:
On 7/21/2010 9:16 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 09:09:22AM -0400, Dan Langille wrote:
On 7/21/2010 8:20 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
Sure, with the caveat that it could be the totally wrong fix for this
problem. ;)
I will consider that soon... However, this recent part is interesting:
http://marc.info/?l=bacula-develm=127971346713102w=2
In general, as far as I can tell, this occurs because you have
explicitly added /usr/local/lib to an environment variable that you feed
to the ./configure script. This should not really be necessary, because
if you let the configure figure out the libraries itself (aside from
the ones like postgres or mysql that you specify on a ./configure
option), it works on all other systems, and never experience this problem.
Do you think perhaps this is the culprit?
# make -V LDFLAGS
-L/usr/local/lib
Yes, but that is set in bsd.database.mk I believe.
Recent posts to the thread pasted above indicate that is the cause of
the problem. Perhaps bsd.database.mk is 'the root of all evil'?
Yes, but it is needed so that we can link with the necessary libraries.
I took a quick glance through the thread and it doesn't look like there
are major objections to this patch, just that they don't want to include
it upstream, which is understandable. This fix can be maintained by the
ports community until it is no longer needed (if ever). I'd like to
commit this patch so we can get upgrades working for people who use
postgres. Do you have any issues with me committing this?
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: sysytils/bacula-server link failures WITH_POSTGRESQL
On 7/21/2010 12:53 PM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 12:37:29PM -0400, Dan Langille wrote:
On 7/21/2010 9:16 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 09:09:22AM -0400, Dan Langille wrote:
On 7/21/2010 8:20 AM, Wesley Shields wrote:
On Wed, Jul 21, 2010 at 07:57:46AM -0400, Dan Langille wrote:
On 7/20/2010 10:07 PM, Wesley Shields wrote:
On Mon, Jul 19, 2010 at 11:33:48AM +0100, Matthew Seaman wrote:
Dear port maintainer,
Since version 5.0.2 was committed over the weekend, if you select
WITH_POSTGRESQL in the config dialogue for sysutils/bacula-server, it
fails to link:
Linking bacula-dir ...
/usr/ports/sysutils/bacula-server/work/bacula-5.0.2/libtool --silent
--tag=CXX --mode=link /usr/bin/c++ -L/usr/local/lib -L../lib -L../cats
-L../findlib -o bacula-dir dird.o admin.o authenticate.o autoprune.o
backup.o bsr.o catreq.o dir_plugins.o dird_conf.o expand.o fd_cmds.o
getmsg.o inc_conf.o job.o jobq.o migrate.o mountreq.o msgchan.o
next_vol.o newvol.o pythondir.o recycle.o restore.o run_conf.o
scheduler.o ua_acl.o ua_cmds.o ua_dotcmds.o ua_query.o ua_input.o
ua_label.o ua_output.o ua_prune.o ua_purge.o ua_restore.o ua_run.o
ua_select.o ua_server.o ua_status.o ua_tree.o ua_update.o vbackup.o
verify.o -lbacfind -lbacsql -lbacpy -lbaccfg -lbac -lm
-L/usr/local/lib -lpq -lcrypt -lpthread -lintl -lwrap
/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -Wl,-rpath
-Wl,/usr/local/lib -lssl -lcrypto
/usr/local/lib/libbacsql.so: undefined reference to
`rwl_writelock(s_rwlock_tag*)'
*** Error code 1
This seems to be autoconf / libtool flail: removing -L/usr/local/lib
from LDFLAGS in ${WRKSRC}/src/dird/Makefile,
${WRKSRC}/src/stored/Makefile and ${WRKSRC}/src/tools/Makefile allows
linking to work correctly.
# diff -u Makefile{~,}
--- Makefile~2010-07-19 10:33:43.0 +0100
+++ Makefile2010-07-19 10:40:07.0 +0100
@@ -84,7 +84,7 @@
CFLAGS = -O2 -pipe -fno-strict-aliasing
CPPFLAGS = -I/usr/local/include
-LDFLAGS = -L/usr/local/lib
+LDFLAGS =
TTOOL_LDFLAGS =
#DEFS = -DHAVE_CONFIG_H
LIBS = -lpthread -lintl
This isn't a problem in the WITH_SQLITE or WITH_MYSQL cases -- neither
of those result in LDFLAGS being set in referenced Makefiles.
After talking to Dan briefly this is a known problem with upgrades. It
looks like the build process looks in /usr/local/lib instead of using
the libraries it just built when it does the linking. It finds the old
library, which is missing the newer symbols, and fails to link. By
pushing /usr/local/lib after the rest of the -L arguments in the
necessary places this appears to build properly now. I'd appreciate
further testing of the patch. Your initial patch is only applicable
after the Makefiles have been generated by configure.
Dan, my initial testing indicates that this allows the port to build.
I'd appreciate another set of eyeballs on it though. Please let me know
if you would like me to commit this patch or not.
http://people.freebsd.org/~wxs/bacula-unbreak.diff
I'd like to pass this URL on to the bacula-devel mailing list please.
That OK with you?
Sure, with the caveat that it could be the totally wrong fix for this
problem. ;)
I will consider that soon... However, this recent part is interesting:
http://marc.info/?l=bacula-develm=127971346713102w=2
In general, as far as I can tell, this occurs because you have
explicitly added /usr/local/lib to an environment variable that you feed
to the ./configure script. This should not really be necessary, because
if you let the configure figure out the libraries itself (aside from
the ones like postgres or mysql that you specify on a ./configure
option), it works on all other systems, and never experience this problem.
Do you think perhaps this is the culprit?
# make -V LDFLAGS
-L/usr/local/lib
Yes, but that is set in bsd.database.mk I believe.
Recent posts to the thread pasted above indicate that is the cause of
the problem. Perhaps bsd.database.mk is 'the root of all evil'?
Yes, but it is needed so that we can link with the necessary libraries.
I took a quick glance through the thread and it doesn't look like there
are major objections to this patch, just that they don't want to include
it upstream, which is understandable. This fix can be maintained by the
ports community until it is no longer needed (if ever). I'd like to
commit this patch so we can get upgrades working for people who use
postgres. Do you have any issues with me committing this?
Go for it. :)
--
Dan Langille - http://langille.org/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
21.07.2010 20:47, Ashish SHUKLA пишет: In case of multiple ports installing files with same name at same path, then one of them needs to alter the file names by using suffix or prefix, like GNU projects do when they collide with BSD equivalents by using 'g' as prefix. I don't think that prefixing gnu tools is good example. For example we have native make in /usr/bin and gmake in /usr/local/bin.And native make is in base system, and gmake is a port. So why CONFLICTS needed then for? And is this ok to have two ports with the same name. I've searched Porters Handbook for this, but found nothing (i think it pretty obvious to mention it in docs). What if want to remove one of then, or update. Which one will be removed/updated? Please don't get me wrong, just curious. -- Regards, Ruslan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster packages and perl upgrade
On Wed, 21 Jul 2010, Douglas Berry wrote: On Tue, 20 Jul 2010 14:45:18 PDT, Doug Barton wrote: soo ... is the blob that gets added to make.conf after you install ports-mgmt/portconf in both make.conf files? Yes. I'm thinking that packages/Latest/perl is stale. Can you check it? If it is stale, updating it should do the trick. If it's not, then there is more debugging to do. Thank you for that! After changing from... /usr/ports/packages/Latest/perl.tbz - ../All/perl-5.10.1_2.tbz to... /usr/ports/packages/Latest/perl.tbz - ../All/perl-5.12.1.tbz all works fine. Ok, that's good news! :) I presume this is due to... ~/ports grep LATEST lang/perl5.*/Makefile lang/perl5.10/Makefile:LATEST_LINK= perl lang/perl5.12/Makefile:NO_LATEST_LINK= yes lang/perl5.8/Makefile:NO_LATEST_LINK= yes Yeah, looks like I need to change that logic for local packagedirs a bit. Thanks very much for portmaster! You're welcome. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
Ruslan Mahmatkhanov writes: 21.07.2010 20:47, Ashish SHUKLA пишет: In case of multiple ports installing files with same name at same path, then one of them needs to alter the file names by using suffix or prefix, like GNU projects do when they collide with BSD equivalents by using 'g' as prefix. I don't think that prefixing gnu tools is good example. For example we have native make in /usr/bin and gmake in /usr/local/bin.And native make is in base system, and gmake is a port. So why CONFLICTS needed then for? IMHO, CONFLICTS are suited for ports which represent same project or forks or with different options which install files at same places thus can't be installed side-by-side. e.g. irc/bitlbee and irc/bitlbee-otr, editors/emacs* ports etc., thats purely my observation. And is this ok to have two ports with the same name. I've searched Porters Handbook for this, but found nothing (i think it pretty obvious to mention it in docs). What if want to remove one of then, or update. Which one will be removed/updated? Well, I don't think its good to have two ports with same name, esp. when they result in same PKGNAME. To distinguish between similar named ports add a prefix or suffix to them. Please don't get me wrong, just curious. No problems. % echo 'pkill cat' curiosity -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Keep your BitTorrent clients running and make the world a better place to live in.” (Sir Debarshi Ray, .signature, 2010) pgpMGVS4wJuFT.pgp Description: PGP signature
Re: security/hydra and www/hydra
21.07.2010 20:47, Ashish SHUKLA ??: In case of multiple ports installing files with same name at same path, then one of them needs to alter the file names by using suffix or prefix, like GNU projects do when they collide with BSD equivalents by using 'g' as prefix. I don't think that prefixing gnu tools is good example. For example we have native make in /usr/bin and gmake in /usr/local/bin.And native make is in base system, and gmake is a port. So why CONFLICTS needed then for? It's needed here because both ports install into the same file. But you are absolutly right, two ports with the same name (hydra) are also bad. One of the should be changed, e.g. to hydra-webserver. And is this ok to have two ports with the same name. No, it's bad and should be avoided. I'm pretty sure some portupgrade tool will break. -- p...@opsec.eu+49 171 310137210 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OPTIONS and dynamic PKGNAMPREFIX, e.g. {APACHE, PYTHON, ETC}_PKGNAMEPREFIX (Was: ports/148637 ...)
On 19/07/2010 21:05, Anonymous wrote:
Christopher Keycj...@cam.ac.uk writes:
A crude survey shows several ports with this problem, listed below.
...
If you can suggest which is the
preferred solution, I'll put together a patch.
I don't know what workaround is preferred but I'd suggest
UNIQUENAME. It's easier to type and has same dependency on
PKGNAMEPREFIX.
Attached.
Index: audio/mpdbrowser/Makefile
===
RCS file: /home/ncvs/ports/audio/mpdbrowser/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- audio/mpdbrowser/Makefile 31 May 2010 01:57:29 - 1.5
+++ audio/mpdbrowser/Makefile 21 Jul 2010 20:20:16 -
@@ -28,6 +28,9 @@
OPTIONS= MPD Install Music Player Daemon on
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if defined (WITH_MPD)
Index: devel/py-gdata/Makefile
===
RCS file: /home/ncvs/ports/devel/py-gdata/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- devel/py-gdata/Makefile 22 May 2010 15:49:30 - 1.24
+++ devel/py-gdata/Makefile 21 Jul 2010 20:20:16 -
@@ -25,6 +25,9 @@
EXAMPLESDIR= ${PREFIX}/share/examples/py-${PORTNAME}
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if ${PYTHON_REL} 250
Index: devel/py-twisted/Makefile
===
RCS file: /home/ncvs/ports/devel/py-twisted/Makefile,v
retrieving revision 1.37
diff -u -r1.37 Makefile
--- devel/py-twisted/Makefile 7 Feb 2010 09:34:25 - 1.37
+++ devel/py-twisted/Makefile 21 Jul 2010 20:20:16 -
@@ -36,6 +36,9 @@
do-install:
${DO_NADA}
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if !defined(WITHOUT_CONCH)
Index: graphics/py-pycha/Makefile
===
RCS file: /home/ncvs/ports/graphics/py-pycha/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- graphics/py-pycha/Makefile 29 Mar 2010 08:36:05 - 1.4
+++ graphics/py-pycha/Makefile 21 Jul 2010 20:20:16 -
@@ -19,6 +19,9 @@
OPTIONS= CAIRO Add support for py-cairo On
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if !defined(WITHOUT_CAIRO)
Index: news/py-pynzb/Makefile
===
RCS file: /home/ncvs/ports/news/py-pynzb/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- news/py-pynzb/Makefile 13 Jun 2010 12:41:32 - 1.2
+++ news/py-pynzb/Makefile 21 Jul 2010 20:20:16 -
@@ -22,6 +22,9 @@
OPTIONS= LXMLAdd support for py-lxml Off \
ELEMENTTREE Add support for py-elementtree Off
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if !defined(WITHOUT_LXML)
Index: security/py-keyring/Makefile
===
RCS file: /home/ncvs/ports/security/py-keyring/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- security/py-keyring/Makefile21 Nov 2009 15:48:35 - 1.3
+++ security/py-keyring/Makefile21 Jul 2010 20:20:16 -
@@ -25,6 +25,9 @@
OPTIONS= GNOME_KEYRING GNOME Keyring backend Off \
KDE_KWALLET KDE KWallet backend Off
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if defined(WITH_GNOME_KEYRING)
Index: www/mod_accounting/Makefile
===
RCS file: /home/ncvs/ports/www/mod_accounting/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- www/mod_accounting/Makefile 7 Jun 2010 03:43:54 - 1.23
+++ www/mod_accounting/Makefile 21 Jul 2010 20:20:16 -
@@ -23,6 +23,9 @@
USE_APACHE=13
MAKE_ARGS+=APXS=${APXS}
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.options.mk
.if defined(WIT_PGSQL)
Index: www/mod_dav/Makefile
===
RCS file: /home/ncvs/ports/www/mod_dav/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- www/mod_dav/Makefile25 May 2010 20:17:29 - 1.24
+++ www/mod_dav/Makefile21 Jul 2010 20:20:16 -
@@ -39,6 +39,9 @@
--includedir=${LOCALBASE}/${APACHEINCLUDEDIR} \
--with-apxs=${APXS}
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if defined(WITHOUT_APACHE_EXPAT)
CONFIGURE_ARGS+= --with-expat=${LOCALBASE}
Index: www/mod_limitipconn/Makefile
===
RCS file: /home/ncvs/ports/www/mod_limitipconn/Makefile,v
retrieving revision 1.12
diff -u
Re: OPTIONS and dynamic PKGNAMPREFIX, e.g. {APACHE, PYTHON, ETC}_PKGNAMEPREFIX (Was: ports/148637 ...)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/21/10 20:30, Christopher Key wrote:
On 19/07/2010 21:05, Anonymous wrote:
Christopher Keycj...@cam.ac.uk writes:
A crude survey shows several ports with this problem, listed below.
...
If you can suggest which is the
preferred solution, I'll put together a patch.
I don't know what workaround is preferred but I'd suggest
UNIQUENAME. It's easier to type and has same dependency on
PKGNAMEPREFIX.
The mod_* ports should not be py-* prefixed.
If you're going to do it, they should he ap${APACHE_VERSION}- prefixed.
Several ports show examples of this already. Also, AP_FAST_BUILD does
this for you.
- --
-
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer,FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iD8DBQFMR1nmdbiP+9ubjBwRAkAAAKCBUzmWCcvji68JW8jInXEe+lFwIgCfbEfT
WdFLDLv4vO/18qvF2NuAqzg=
=PHi+
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OPTIONS and dynamic PKGNAMPREFIX, e.g. {APACHE, PYTHON, ETC}_PKGNAMEPREFIX (Was: ports/148637 ...)
On 21/07/2010 21:34, Philip M. Gollucci wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/21/10 20:30, Christopher Key wrote:
On 19/07/2010 21:05, Anonymous wrote:
Christopher Keycj...@cam.ac.uk writes:
A crude survey shows several ports with this problem, listed below.
...
If you can suggest which is the
preferred solution, I'll put together a patch.
I don't know what workaround is preferred but I'd suggest
UNIQUENAME. It's easier to type and has same dependency on
PKGNAMEPREFIX.
The mod_* ports should not be py-* prefixed.
If you're going to do it, they should he ap${APACHE_VERSION}- prefixed.
Several ports show examples of this already. Also, AP_FAST_BUILD does
this for you.
Sorry, the attached should be a little more sane. The reason that this
needs to be done manually, and that ${APACHE_VERSION} or
${APACHE_PKGNAMEPREFIX} can't be used is that the options are read
before bsd.apache.mk is included.
Kind regards,
Christopher Key.
Index: audio/mpdbrowser/Makefile
===
RCS file: /home/ncvs/ports/audio/mpdbrowser/Makefile,v
retrieving revision 1.5
diff -u -r1.5 Makefile
--- audio/mpdbrowser/Makefile 31 May 2010 01:57:29 - 1.5
+++ audio/mpdbrowser/Makefile 21 Jul 2010 21:47:52 -
@@ -28,6 +28,9 @@
OPTIONS= MPD Install Music Player Daemon on
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if defined (WITH_MPD)
Index: devel/py-gdata/Makefile
===
RCS file: /home/ncvs/ports/devel/py-gdata/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
--- devel/py-gdata/Makefile 22 May 2010 15:49:30 - 1.24
+++ devel/py-gdata/Makefile 21 Jul 2010 21:47:52 -
@@ -25,6 +25,9 @@
EXAMPLESDIR= ${PREFIX}/share/examples/py-${PORTNAME}
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if ${PYTHON_REL} 250
Index: devel/py-twisted/Makefile
===
RCS file: /home/ncvs/ports/devel/py-twisted/Makefile,v
retrieving revision 1.37
diff -u -r1.37 Makefile
--- devel/py-twisted/Makefile 7 Feb 2010 09:34:25 - 1.37
+++ devel/py-twisted/Makefile 21 Jul 2010 21:47:52 -
@@ -36,6 +36,9 @@
do-install:
${DO_NADA}
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if !defined(WITHOUT_CONCH)
Index: graphics/py-pycha/Makefile
===
RCS file: /home/ncvs/ports/graphics/py-pycha/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- graphics/py-pycha/Makefile 29 Mar 2010 08:36:05 - 1.4
+++ graphics/py-pycha/Makefile 21 Jul 2010 21:47:52 -
@@ -19,6 +19,9 @@
OPTIONS= CAIRO Add support for py-cairo On
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if !defined(WITHOUT_CAIRO)
Index: news/py-pynzb/Makefile
===
RCS file: /home/ncvs/ports/news/py-pynzb/Makefile,v
retrieving revision 1.2
diff -u -r1.2 Makefile
--- news/py-pynzb/Makefile 13 Jun 2010 12:41:32 - 1.2
+++ news/py-pynzb/Makefile 21 Jul 2010 21:47:52 -
@@ -22,6 +22,9 @@
OPTIONS= LXMLAdd support for py-lxml Off \
ELEMENTTREE Add support for py-elementtree Off
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if !defined(WITHOUT_LXML)
Index: security/py-keyring/Makefile
===
RCS file: /home/ncvs/ports/security/py-keyring/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- security/py-keyring/Makefile21 Nov 2009 15:48:35 - 1.3
+++ security/py-keyring/Makefile21 Jul 2010 21:47:52 -
@@ -25,6 +25,9 @@
OPTIONS= GNOME_KEYRING GNOME Keyring backend Off \
KDE_KWALLET KDE KWallet backend Off
+# bypass infrastructure bug
+UNIQUENAME=py-${PORTNAME}
+
.include bsd.port.pre.mk
.if defined(WITH_GNOME_KEYRING)
Index: www/mod_accounting/Makefile
===
RCS file: /home/ncvs/ports/www/mod_accounting/Makefile,v
retrieving revision 1.23
diff -u -r1.23 Makefile
--- www/mod_accounting/Makefile 7 Jun 2010 03:43:54 - 1.23
+++ www/mod_accounting/Makefile 21 Jul 2010 21:47:52 -
@@ -23,6 +23,9 @@
USE_APACHE=13
MAKE_ARGS+=APXS=${APXS}
+# bypass infrastructure bug
+UNIQUENAME=ap-${PORTNAME}
+
.include bsd.port.options.mk
.if defined(WIT_PGSQL)
Index: www/mod_dav/Makefile
===
RCS file: /home/ncvs/ports/www/mod_dav/Makefile,v
retrieving revision 1.24
diff -u -r1.24 Makefile
---
Re: security/hydra and www/hydra
On Wed, Jul 21, 2010 at 10:21:11PM +0200, Kurt Jaeger wrote: And is this ok to have two ports with the same name. No, it's bad and should be avoided. I'm pretty sure some portupgrade tool will break. No, they actually handle it ok. It _is_ confusing to the users, however (and, if you go through a raw list of package binaries, You Just Have To Know which one's which.) mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[patch] Integration between portconf and port options
At present, the interaction between portconf and port options is
somewhat confusing. Firstly, the output of make showconfig and the
defaults displayed by make config are unaffected by anything set in
ports.conf. Secondly, its quite easy to unexpectedly end up having both
WITH_XXX and WITHOUT_XXX defined.
Consider devel/binutils:
#v+
# cd /usr/ports/devel/binutils
# make rmconfig
# make showconfig
=== The following configuration options are available for
binutils-2.20.1_3:
NLS=off (default) Enable National Language Support
=== Use 'make config' to modify these settings
# make -V WITH_NLS
# make -V WITHOUT_NLS
true
#v-
i.e. one option defaulting to off. We can switch it on with ports.conf:
#v+
# make -DWITH_NLS -VWITH_NLS
1
# make -DWITH_NLS -VWITHOUT_NLS
#v-
however, if options get set then things get confusing:
#v+
# make config
# make showconfig
=== The following configuration options are available for
binutils-2.20.1_3:
NLS=off Enable National Language Support
=== Use 'make config' to modify these settings
# make -V WITH_NLS
# make -V WITHOUT_NLS
true
# make -DWITH_NLS -VWITH_NLS
1
# make -DWITH_NLS -VWITHOUT_NLS
true
#v-
Just by accepting the defaults, we've suddenly got both WITH_NLS and
WITHOUT_NLS defined. In this case, the port checks for WITH_NLS, and
the build will be unaffected. In general, the port must check for
WITH_XXX if the default option value is off (and for WITHOUT_XXX if the
default value is on) in order to avoid the build changing as a result of
accepting the default configuration presented by make config. This
seems rather fragile, and is clearly susceptible to problems should the
default option values get changed.
The attached patch reworks the options framework slightly to try resolve
these two problems.
When a port is being built, each option defined in OPTIONS can be on or
off, and exactly one of WITH_XXX and WITHOUT_XXX will be defined after
including bsd.port.options.mk.
There are three locations from which an option can take its value: (in
decreasing order of priority)
1) /var/db/ports/*/options
2) ports.conf, make.conf and command line arguments - for now termed
environment, although a more descriptive term is desired.
3) default values from OPTIONS
When make config is run, the values displayed will be the values of the
options seen by the port when building. Typically, this would means
that when make config is first run, the values presented would be the
defaults (but would reflect anything set in ports.conf too). Subsequent
runs would then show the values saved by the last invocation of make config.
When make showconfig, the options displayed will again be the values
seen by the port when building. It also displays the location from
which the option value came from (i.e. config, environment or default).
As both /var/db/ports/*/options and ports.conf etc are stored as lists
of WITH_XXX and WITHOUT_XXX variables, it is possible for both WITH_XXX
and WITHOUT_XXX to be defined simultaneously in one location. If both
are defined in one location, then WITHOUT_XXX takes priority. If both
are defined, but only in different locations, the the first location on
the list takes priority.
For example, if /var/db/port/*/options had WITH_XXX set and ports.conf
had WITHOUT_XXX set, then the option would be on (and only WITH_XXX
would be defined after bsd.port.options.mk), because .../options takes
priority. However, if nothing was set in .../options, and ports.conf
set both WITH_XXX and WITHOUT_XXX then the option would be off (and only
WITHOUT_XXX would be defined after bsd.port.option.mk) because
WITHOUT_XXX takes priority.
Feedback would be very much appreciated.
Kind regards,
Christopher Key
Index: Mk/bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.643
diff -u -r1.643 bsd.port.mk
--- Mk/bsd.port.mk 15 Jul 2010 14:48:50 - 1.643
+++ Mk/bsd.port.mk 21 Jul 2010 20:31:25 -
@@ -1291,43 +1291,88 @@
.endif
OPTIONSFILE?= ${PORT_DBDIR}/${UNIQUENAME}/options
.if defined(OPTIONS)
-# include OPTIONSFILE first if exists
+
+_OPTIONS_LIST=${OPTIONS:C/.*//g:S/on//:S/off//}
+
+# Firstly, get an on/off value for each option defined by make.conf,
ports.conf, -D...
+# Also undef the corresponding WITH_XXX, WITHOUT_XXX so that we can see what
we read in
+# from our config file. We'll restore them later.
+. for OPT in ${_OPTIONS_LIST}
+. if defined(WITH_${OPT}) || defined(WITHOUT_${OPT})
+. if defined(WITHOUT_${OPT}) # always check WITHOUT_XXX before WITH_XXX
to give WITHOUT_XXX priority
+_OPTION_VAL_${OPT}=off
+. else
+_OPTION_VAL_${OPT}=on
+. endif
+_OPTION_SRC_${OPT}?= environment
+. undef WITH_${OPT}
+. undef WITHOUT_${OPT}
+. endif
+. endfor
+
+# Include OPTIONSFILE if exists
. if exists(${OPTIONSFILE}) !make(rmconfig)
.
Re: OPTIONS and dynamic PKGNAMPREFIX, e.g. {APACHE, PYTHON, ETC}_PKGNAMEPREFIX (Was: ports/148637 ...)
Philip M. Gollucci pgollu...@p6m7g8.com writes:
On 07/21/10 20:30, Christopher Key wrote:
On 19/07/2010 21:05, Anonymous wrote:
Christopher Keycj...@cam.ac.uk writes:
A crude survey shows several ports with this problem, listed below.
...
If you can suggest which is the
preferred solution, I'll put together a patch.
I don't know what workaround is preferred but I'd suggest
UNIQUENAME. It's easier to type and has same dependency on
PKGNAMEPREFIX.
The mod_* ports should not be py-* prefixed.
Agree. They should have constant ap-* prefix. The one you suggest below
has uncertain value.
If you're going to do it, they should he ap${APACHE_VERSION}- prefixed.
Did you actually test it? After setting
UNIQUENAME = ap${APACHE_VERSION}-${PORTNAME}
and selecting MP4 in www/mod_musicindex it still thinks WITH_MP4 is not
defined.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OPTIONS and dynamic PKGNAMPREFIX, e.g. {APACHE, PYTHON, ETC}_PKGNAMEPREFIX (Was: ports/148637 ...)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/21/10 22:06, Anonymous wrote:
UNIQUENAME = ap${APACHE_VERSION}-${PORTNAME}
and selecting MP4 in www/mod_musicindex it still thinks WITH_MP4 is not
defined.
I haven't tried this, but thats a much better attempt then the py- version.
- --
-
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354
VP Apache Infrastructure; Member, Apache Software Foundation
Committer,FreeBSD Foundation
Consultant, P6M7G8 Inc.
Sr. System Admin, Ridecharge Inc.
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iD8DBQFMR2/fdbiP+9ubjBwRAvy/AJ0UCQ0UbvB1NUbWMzLfQElqGb9nhgCfUtSX
WFLEJv0PoPS6/lZob2PYCAU=
=5tQu
-END PGP SIGNATURE-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
Mark Linimon lini...@lonesome.com writes: On Wed, Jul 21, 2010 at 10:21:11PM +0200, Kurt Jaeger wrote: And is this ok to have two ports with the same name. No, it's bad and should be avoided. I'm pretty sure some portupgrade tool will break. No, they actually handle it ok. It _is_ confusing to the users, however (and, if you go through a raw list of package binaries, You Just Have To Know which one's which.) So, which package the following command will install? $ pkg_add -r hydra ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
Anonymous swel...@gmail.com writes: Mark Linimon lini...@lonesome.com writes: On Wed, Jul 21, 2010 at 10:21:11PM +0200, Kurt Jaeger wrote: And is this ok to have two ports with the same name. No, it's bad and should be avoided. I'm pretty sure some portupgrade tool will break. No, they actually handle it ok. It _is_ confusing to the users, however (and, if you go through a raw list of package binaries, You Just Have To Know which one's which.) So, which package the following command will install? $ pkg_add -r hydra Ah, it uses NO_LATEST_LINK. So the answer is `none'. Sorry. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
On Thu, Jul 22, 2010 at 02:18:36AM +0400, Anonymous wrote: Ah, it uses NO_LATEST_LINK. So the answer is `none'. Sorry. Yeah, but I had to look it up myself. Do you know of any other examples that are missing either CONFLICTS or NO_LATEST_LINK? mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/hydra and www/hydra
Mark Linimon lini...@lonesome.com writes: On Thu, Jul 22, 2010 at 02:18:36AM +0400, Anonymous wrote: Ah, it uses NO_LATEST_LINK. So the answer is `none'. Sorry. Yeah, but I had to look it up myself. Do you know of any other examples that are missing either CONFLICTS or NO_LATEST_LINK? I'm not sure what you mean by `either ... or' here but I don't think you can substitute CONFLICTS with NO_LATEST_LINK. As for missing CONFLICTS there are too many to check, I've stopped after finding following net/ttt, games/ttt - both install bin/ttt but only games/ttt has CONFLICTS chinese/vflib, japanese/vflib - have similar PLIST and no CONFLICTS lang/gawk, japanese/gawk - bin/gawk, no CONFLICTS math/surf, www/surf - bin/surf, no CONFLICTS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OPTIONS and dynamic PKGNAMPREFIX, e.g. {APACHE, PYTHON, ETC}_PKGNAMEPREFIX (Was: ports/148637 ...)
if USE_APACHE=13 you can write ap13 you know what APACHE_VERSION will evaluate too. Its only vague in the case of a '+' -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: General note on rc scripts and daemonizing
Hey, On Tue, 20 Jul 2010 17:25:03 -0700 Doug Barton do...@freebsd.org wrote: On 07/20/10 16:46, Jos Backus wrote: Fwiw, I would much prefer FreeBSD ship with some sort of process supervisor a la daemontools. That's an interesting idea, but until we have someone willing to actually do that work we need to deal with what we have. I wrote one. It's in the latest status report that, I gues, will be released soon. :) -- Tom Rhodes ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: sympa-5.4.7_1
On Wed, 2010-07-21 at 00:40:43 +0200, Olivier Girard (neuf) wrote: got no spare time to work on sympa actualy. My boss as decided that this is not an issue for us and prefer me to work on other projects. Maybe later this summer when i'm out of office but i really don't know. Olivier has graciously agreed to hand over this port to someone who has time to maintain it. Any takers before we reset to po...@? -- Sahil Tandon sa...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
gdc 0.24_6
Dear all, This is now under active development again. The new website is http://bitbucket.org/goshawk/gdc/wiki/Home. Could someone be kind enough as to update this port? Best, Quyen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
