Re: Non-daemon programs requiring kernel modules
Quoting Andrew Pantyukhin [EMAIL PROTECTED] (from Sun, 28 Jan 2007 21:58:28 +0300): On 1/28/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Andrew Pantyukhin [EMAIL PROTECTED] (Sun, 28 Jan 2007 18:35:30 +0300): I'm porting a simple util requiring aio(4). My plan is to install a wrapper script which includes rc.subr(8) and uses its required_modules mechanism. If anyone has a better idea, please tell me. Just tell at port/package install time the requirement. Every linux program needs the linux module or the corresponding kernel option. If the code is not available at runtime, the user will get an error. Unix is not for dumb people, so I don't think we need this low-level hand-holding. That's one opinion. But Unix is also not about dumb developers. As a ports developer, my job is to make it easier for users to run third-party software and that's just what I'm trying to do to the extent of my skills and motivation... I agree, but if you are interested in a general solution, how do you want to apply it to the linux stuff? I see the problem, that if you try to do a generic solution, users want it for the linux stuff too. There's not problem with such a request from a high level point of view, but technically I don't see how this can be done in a reasonable way for the linux stuff. For acroread or skype, we could do it very easy (there are already FreeBSD shell scripts as wrappers, so we could check with kldstat -v | grep linux), but users would expect something like this in a lot more places then. In some places you just can not do it, because those programs are also used by linux stuff internally or can be used in a chroot. It's like using a program which issues some ioctls which are valid for SCSI devices, but not ata devices (or vice versa). Or if you want to use SYSVSHM and it isn't available in the kernel. The user will get an error message because he did the wrong thing. I think it is more POLA to keep it this way, instead of doing it for some stuff but not all stuff. If we are able to do it for all stuff, great, go ahead, but in this case I don't think it is a good idea. You can bail out in the port/package if aio is not available. You can parse the output of kldstat -v and determine if aio is compiled into the kernel or loaded as a module. If it is loaded as a module, check if it is enabled in loader.conf. If this is not the case, fail to install/build with a suitable message. This is (more or less) how we do it in the linux ports. Bye, Alexander. -- Some primal termite knocked on wood. And tasted it, and found it good. And that is why your Cousin May Fell through the parlor floor today. -- Ogden Nash http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Current unassigned ports problem reports
Current FreeBSD problem reports
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including experimental
development code and obsolete releases.
Bugs can be in one of several states:
o - open
A problem report has been submitted, no sanity checking performed.
a - analyzed
The problem is understood and a solution is being sought.
f - feedback
Further work requires additional information from the
originator or the community - possibly confirmation of
the effectiveness of a proposed solution.
p - patched
A patch has been committed, but some issues (MFC and / or
confirmation from originator) are still open.
r - repocopy
The resolution of the problem report is dependent on
a repocopy operation within the CVS repository which
is awaiting completion.
s - suspended
The problem is not being worked on, due to lack of information
or resources. This is a prime candidate
for somebody who is looking for a project to do.
If the problem cannot be solved at all,
it will be closed, rather than suspended.
c - closed
A problem report is closed when any changes have been integrated,
documented, and tested -- or when fixing the problem is abandoned.
Critical problems
Serious problems
S Tracker Resp. Description
o ports/82759 devel/sourcenav: Source navigator installs in wrong di
o ports/107178[PATCH] sysutils/eiciel: [SUMMARIZE CHANGES]
o ports/107229sysutils/coreutils: gcp fails to set default ACL which
o ports/107536editors/scite: Can't write on SciTE text editor
o ports/107990net-mgmt/zabbix agentd not running in a jail
f ports/108077www/linux-flashplugin9 crashes linux-firefox
f ports/108149dar 2.3.2 port install failure
o ports/108182dns/powerdns: fix building issues with gpgsql backend
f ports/108413net/vnc does not works.
o ports/108414net/tighvnc does not works.
o ports/108428[maintainer update] comms/obexapp: fix conflict with m
o ports/108430[patch] RIP is broken in quagga
o ports/108439irc/ctrlproxy fails to bind to port, invalid argument
o ports/108502[maintainer] textproc/sphinxsearch -- run as unprivile
o ports/108505linux-js appears broken
15 problems total.
Non-critical problems
S Tracker Resp. Description
s ports/57502 ports that define USE_* too late
s ports/59254 ports that write something after bsd.port.mk
s ports/89098 security/dsniff does not build
s ports/95733 security/dsniff ports kit does not compile
f ports/95990 New Port: emulators/xjoypad
s ports/96731 textproc/docbook-utils doesn`t build
s ports/97257 security/dsniff doesn't build when net/libpcap is inst
f ports/100650audio/moc dumps core when detach/quit
o ports/100896[new ports] emulators/vmware-server-guestd1 emulators/
f ports/102093new port (restoring from Attic): fix games/myth2_demo
s ports/102448new port: x11/xcb-demo, X protocol C-language Binding
s ports/102449new port: x11/xcb-util, X protocol C-language Binding
o ports/103395security/gnome-ssh-askpass interferes with gnome-scree
o ports/104560[patch] x11-toolkits/py-gtk2 does not configure with p
s ports/104725request new port: x11/nvidia-driver-devel
o ports/105473ports/sysutils/cpdup -o doesn't work as advertised
f ports/105716textproc/lemmatizer: Update to version 1.2
o ports/106134[patch] www/mod_backhand: Memory size incorrectly show
o ports/106932chinese/scim-pinyin: libtool - pthread problem with
f ports/107336Port Update: database/grass
o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM
f ports/107675security/vpnc suggest rc.d script
f ports/107832upgrading sysutils/dar fails because of library search
f ports/107874port databases/freetds: fix for MSSQL 7
f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut
f ports/108132[update] www/zope-zwiki update to 0.58.0
f ports/108144[update] www/plone update to 2.5.2
f ports/108176graphics/gnash: change ${PREFIX} to ${LOCALBASE}
f ports/108194ports/lang/gauche doesn't install docs properly
o ports/108292metis and metis-edf install files into the same place
f ports/108339[fix] security/tor and security/tor-devel use pre-inst
f ports/108357Update port: emulators/zsnes to 1.51
o ports/108412lack of CONFLICTS about vnc
Re: Non-daemon programs requiring kernel modules
On 1/29/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Andrew Pantyukhin [EMAIL PROTECTED] (from Sun, 28 Jan 2007 21:58:28 +0300): On 1/28/07, Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Andrew Pantyukhin [EMAIL PROTECTED] (Sun, 28 Jan 2007 18:35:30 +0300): I'm porting a simple util requiring aio(4). My plan is to install a wrapper script which includes rc.subr(8) and uses its required_modules mechanism. If anyone has a better idea, please tell me. Just tell at port/package install time the requirement. Every linux program needs the linux module or the corresponding kernel option. If the code is not available at runtime, the user will get an error. Unix is not for dumb people, so I don't think we need this low-level hand-holding. That's one opinion. But Unix is also not about dumb developers. As a ports developer, my job is to make it easier for users to run third-party software and that's just what I'm trying to do to the extent of my skills and motivation... I agree, but if you are interested in a general solution, how do you want to apply it to the linux stuff? See my original message. grep /etc/rc.d for required_modules. Should we remove all that and just fail when needed modules are not present? The solution is not general, but it helps. I'm always more interested in a small step forward we make than a big leap we discuss. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Non-daemon programs requiring kernel modules
Quoting Andrew Pantyukhin [EMAIL PROTECTED] (from Mon, 29 Jan 2007 14:53:41 +0300): On 1/29/07, Alexander Leidinger [EMAIL PROTECTED] wrote: I agree, but if you are interested in a general solution, how do you want to apply it to the linux stuff? See my original message. grep /etc/rc.d for required_modules. Should we remove all that and just fail when needed modules are not present? The solution is not general, but it helps. I'm always more interested in a small step forward we make than a big leap we discuss. Any stuff in /usr/local/etc/rc.d/ should be disabled by default and enabled only if requested by the user. But requiring the user to put foo_enable=yes into rc.conf is not different from requiring the user to add bar_load=yes into loader.conf. So it doesn't make sense for me. Specially if you think about a fileserver which provides a customized /compat/linux to several machines but doesn't run any linux program itself (and thus doesn't need the linux stuff in the kernel). Bye, Alexander. -- The only really masterful noise a man makes in a house is the noise of his key, when he is still on the landing, fumbling for the lock. -- Colette http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: postgresql's 502.pgsql periodic script and passwords
In response to George Hartzell [EMAIL PROTECTED]: I'm curious how other freebsd postgresql users handle databases with passwords and running the 502.pgsql periodic script. I've solved the problem by creating a ~pgsql/.pgpass file with the pgsql users password. Is there a better way? Depends. Do you allow untrusted users to log in to that machine? If so, then you've probably got the best approach. Make sure that .pgpass file is chmoded 600 -- Bill Moran Collaborative Fusion Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: plone-2.5.1_1: Help: not working on FreeBSD 6
Filippo, none of the source links can be accessed from a Unix server for this port. I have downloaded directly plone 2.5.2.1 from plone.org, but it isn't working. There are some changes necessary. Can you help me ? This is what my event log says: 2007-01-29T20:22:09 WARNING Init Class Products.ATContentTypes.content.base.ATCTFolderMixin has a security declaration for nonexistent method 'manage_copyObjects' -- 2007-01-29T20:22:10 ERROR Zope Could not import Products.ATContentTypes Further, it tells me the Marshall handlers cannot find libxml (on my FreeBSD v6 they are called libxmal2-2.6). Do you have any reference to these issues ? I have already tried the irc #plone but no one has experience with plone on FreeBSD Kindly advise if you could help Regards Luis ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: squirrelmail-1.4.9a - missing strings.php?
Hi, I've just upgraded my squirrelmail port to 1.4.9a, and I believe there's a problem with the upgrade. Perhaps it was caused by me not upgrading for several months I missed a release. In any event, it's no longer possible to log in to my Squirrelmail; the login page gives the error PHP Fatal error: Call to undefined function sqm_baseuri() in /usr/local/www/squirrelmail/src/login.php on line 44 I believe this is because the sqm devel team moved this function into include/strings.php in 1.4.6, and the port does not update the strings.php file. My version of strings.php is from the 1.4.5 release, and there doesn't seem to be a strings.php in /usr/ports/mail/squirrelmail/work/squirrelmail-1.4.9a/include/ Installing the 1.4.9a strings.php in the appropriate place seems to solve the problem. Hope this is useful, PLMK if there is something different I should have done, and thanks for maintaining the port. Yours, Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: FreeBSD Port: squirrelmail-1.4.9a - missing strings.php?
That's probably it. I did portupgrade the compatibility plugin, but obviously that wasn't sufficient. Thanks for your help, Yours, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Wittig Sent: 29 January 2007 22:05 To: Mark Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: FreeBSD Port: squirrelmail-1.4.9a - missing strings.php? Hello I'm not sure if this is the source of your problem, but do you also have mail/squirrelmail-compatibility-plugin installed? If so, you have to reinstall it after you upgrade squirrelmail because the compatibility plugin patches strings.php of the original squirrelmail installation. If you install another version of squirrelmail over it, it will override the patched files. Hope that helps, Alexander Wittig Mark wrote: Hi, I've just upgraded my squirrelmail port to 1.4.9a, and I believe there's a problem with the upgrade. Perhaps it was caused by me not upgrading for several months I missed a release. In any event, it's no longer possible to log in to my Squirrelmail; the login page gives the error PHP Fatal error: Call to undefined function sqm_baseuri() in /usr/local/www/squirrelmail/src/login.php on line 44 I believe this is because the sqm devel team moved this function into include/strings.php in 1.4.6, and the port does not update the strings.php file. My version of strings.php is from the 1.4.5 release, and there doesn't seem to be a strings.php in /usr/ports/mail/squirrelmail/work/squirrelmail-1.4.9a/include/ Installing the 1.4.9a strings.php in the appropriate place seems to solve the problem. Hope this is useful, PLMK if there is something different I should have done, and thanks for maintaining the port. Yours, Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: squirrelmail-1.4.9a - missing strings.php?
Hello I'm not sure if this is the source of your problem, but do you also have mail/squirrelmail-compatibility-plugin installed? If so, you have to reinstall it after you upgrade squirrelmail because the compatibility plugin patches strings.php of the original squirrelmail installation. If you install another version of squirrelmail over it, it will override the patched files. Hope that helps, Alexander Wittig Mark wrote: Hi, I've just upgraded my squirrelmail port to 1.4.9a, and I believe there's a problem with the upgrade. Perhaps it was caused by me not upgrading for several months I missed a release. In any event, it's no longer possible to log in to my Squirrelmail; the login page gives the error PHP Fatal error: Call to undefined function sqm_baseuri() in /usr/local/www/squirrelmail/src/login.php on line 44 I believe this is because the sqm devel team moved this function into include/strings.php in 1.4.6, and the port does not update the strings.php file. My version of strings.php is from the 1.4.5 release, and there doesn't seem to be a strings.php in /usr/ports/mail/squirrelmail/work/squirrelmail-1.4.9a/include/ Installing the 1.4.9a strings.php in the appropriate place seems to solve the problem. Hope this is useful, PLMK if there is something different I should have done, and thanks for maintaining the port. Yours, Mark ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vertical split patch in sysutils/screen
In message [EMAIL PROTECTED], Jeremie Le Hen wr ites: Hi Cy, On Mon, Jan 29, 2007 at 08:04:09AM -0800, Cy Schubert wrote: A couple of comments. Something like this should be integrated into the base screen software. [EMAIL PROTECTED] or screen-users@gnu.org might be a good place to start. That is the preferred approach. If the greater screen community does not feel this additional functionality is necessary and if we the FreeBSD community feel it is, I believe we could implement this. For something like this we should approach the GNU screen developers first. If we as a FreeBSD community decide to implement this outside of the GNU screen development community, I'd like to spend some time testing it. People are free to test it and let me know what they think. Firstly though, we should submit this to [EMAIL PROTECTED] I would like to be in the loop when you do submit it to them. Yes, I know the principle of upstream sources and I perfectly agree with you. However, I think the patch have already been brought to ^ Is it possible they have not looked at it yet? attention of [EMAIL PROTECTED] The problem is that this patch breaks some features, as described in the Bugs section of its webpage [1] and have this not been adopted. Would you have a PR number or something that I can follow up on at gnu.org? Even better would be if someone could point me to any correspondence about this on the screen-devel mailing list archvies. The Bugs section concerns me. I fully understand you don't want to break screen. However I am a user of this patch and I don't care about the broken features, and so does a friend of mine. I supposes there might be other users in this case, so I've made the patch. I'm sure others might be concerned about breakage even if you are not. I would understand if you didn't want to commit this. However if you agree to commit it with a bug warning message, I can correct my patch to add this message in which I will detail the broken features. Please, let me know about your decision. I would rather not commit anything that would break the software, even if the user has the option of knowingly and intentionally breaking it through an option I provide. I don't know if the screen developers at gnu.org are unwilling to incorporate the patch in the base software. I'm not enamoured with the proposed patch. Unless the Bugs can be addressed I don't think it should be committed. -- Cheers, Cy Schubert [EMAIL PROTECTED] FreeBSD UNIX: [EMAIL PROTECTED] Web: http://www.FreeBSD.org e**(i*pi)+1=0 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: postgresql's 502.pgsql periodic script and passwords
On Mon, Jan 29, 2007 at 09:23:52AM -0500, Bill Moran wrote: In response to George Hartzell [EMAIL PROTECTED]: I've solved the problem by creating a ~pgsql/.pgpass file with the pgsql users password. Is there a better way? Depends. Do you allow untrusted users to log in to that machine? If so, then you've probably got the best approach. Make sure that .pgpass file is chmoded 600 Another possibility would be to use the ident method over a local (i.e., Unix-domain) socket. You'd be authenticating via SO_PEERCRED; no .pgpass file would be necessary. -- Michael Fuhr ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Adopting a port
Hi I would like to be the maintainer of the following port: fluxconf 0.9.9_1* *Is there anything else I should do for that? Thanks Alfredo* * ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adopting a port
On Mon, Jan 29, 2007 at 08:45:38PM -0500, Alfredo Perez wrote: Hi I would like to be the maintainer of the following port: You are now! Please read the Porters Handbook at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/ for all the nasty details on the ports system, Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD ports that you maintain which are currently marked broken
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we are attempting to notify maintainers 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 gcc3.4, which is much stricter about such things as function declarations, literal strings constants that continue over several physical lines, and forcing the deprecation of antique header files such as varargs.h (we should now be using stdargs.h). 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. If you need help in one or more build environments that you do not have access to, please ask for help on the freebsd-ports mailing list. 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 4.x/5.x/6.x 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: chinese/gbfs broken because: fails to patch - Included patches are broken build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=gbfs portname: chinese/xemacs broken because: Does not build even with fix for -lxpg4 build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.5.2007010723/zh-xemacs-20.4_2.log (Jan 13 01:26:59 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=chineseportname=xemacs portname: devel/cl-asdf-cmucl broken because: does not build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.5.2007012206/cl-asdf-cmucl-2003.05.16.log.bz2 (Sep 26 05:10:12 UTC 2006) http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.4.2006123004/cl-asdf-cmucl-2003.05.16.log.bz2 (Jul 14 12:12:35 GMT 2006) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=cl-asdf-cmucl portname: devel/php-dbg broken because: Does not compile build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.4.2006111318/php-dbg-2.11.30.log (Nov 19 00:06:42 GMT 2006) overview: http://portsmon.FreeBSD.org/portoverview.py?category=develportname=php-dbg portname: games/hlserver-cs broken because: Incomplete fetch instructions build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=hlserver-cs portname: games/hlserver-dod broken because: Incomplete fetch instructions build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=gamesportname=hlserver-dod portname: graphics/flphoto broken because: Does not compile build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.7.2006122818/flphoto-1.2_1.log (Jan 15 21:37:20 UTC 2007) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=flphoto portname: japanese/gnomelibs broken because: Does not compile on FreeBSD 5.X and above build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=gnomelibs portname: japanese/lookup-xemacs broken because: Does not install build errors: http://pointyhat.FreeBSD.org/errorlogs/sparc64-errorlogs/e.5.2006091522/ja-lookup-xemacs21-mule-1.4_1.log (Oct 6 23:11:44 UTC 2006) overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=lookup-xemacs portname: japanese/lynx broken because: Leaves behind config file on deinstall build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japaneseportname=lynx portname: japanese/ptex broken because: Does not build (uses DESTDIR internally) build errors: none. overview:
FreeBSD ports that you maintain which are currently marked forbidden
Dear FreeBSD port maintainer: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we are attempting to notify maintainers of 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 the port, including errors seen on the build farm, is included below. portname: irc/sircd forbidden because: Multiple vulnerabilities. build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ircportname=sircd 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 If this problem is one that you are already aware of, please accept our apologies and ignore this message. On the other hand, if you no longer wish to maintain this port (or ports), please reply with a message stating that, and accept our thanks for your efforts in the past. Thanks for your efforts to help improve FreeBSD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
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, the ports will be deleted. The goal of this posting is to make this process much more visible to the wider FreeBSD community. portname: audio/gstreamer-plugins-a52dec80 description:Gstreamer a52dec plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-a52dec80 portname: audio/gstreamer-plugins-artsd80 description:Gstreamer artsd plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-artsd80 portname: audio/gstreamer-plugins-audiofile80 description:Gstreamer audiofile plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-audiofile80 portname: audio/gstreamer-plugins-cdaudio80 description:Gstreamer cdaudio plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-cdaudio80 portname: audio/gstreamer-plugins-cdparanoia80 description:Gstreamer cdparanoia plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-cdparanoia80 portname: audio/gstreamer-plugins-esound80 description:Gstreamer esound plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-esound80 portname: audio/gstreamer-plugins-faac80 description:Gstreamer faac plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-faac80 portname: audio/gstreamer-plugins-faad80 description:Gstreamer faad plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-faad80 portname: audio/gstreamer-plugins-flac80 description:Gstreamer flac plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-flac80 portname: audio/gstreamer-plugins-gsm80 description:Gstreamer gsm plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-gsm80 portname: audio/gstreamer-plugins-ivorbis80 description:Gstreamer ivorbis plugin maintainer: [EMAIL PROTECTED] deprecated because: Obsolete version, use gstreamer 0.10 instead expiration date:2007-05-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audioportname=gstreamer-plugins-ivorbis80 portname: audio/gstreamer-plugins-jack80 description:Gstreamer jack plugin maintainer:
