How do I include two patches for the same file?
I'm the maintainer for security/sancp. Recently a new patch was released that patches the decode.cc file. A previous, still valid, patch, *also* patches the decode.cc file. If I include both patches, the make fails with an error about decode.cc decode.cc: In function `void decode(cnx*, int, const u_char*)': decode.cc:74: error: 'struct os_info' has no member named 'wscale' *** Error code 1 Stop in /usr/ports/security/sancp/work/sancp-1.6.1. *** Error code 1 Stop in /usr/ports/security/sancp. How do I include both patches so that they are both applied? Here's the relevant section of the Makefile: Old Makefile: PATCH_SITES=http://sancp.sourceforge.net/ PATCHFILES= sancp-1.6.1.fix200511.a.patch \ sancp-1.6.1.fix200511.b.patch PATCH_DIST_STRIP=-p1 New Makefile: PATCH_SITES=http://sancp.sourceforge.net/ PATCHFILES= sancp-1.6.1.fix200511.a.patch \ sancp-1.6.1.fix200511.b.patch \ sancp-1.6.1.fix200601.c.patch \ sancp-1.6.1.fix200606.d.patch PATCH_DIST_STRIP=-p1 -- Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ smime.p7s Description: S/MIME Cryptographic Signature
Checksum mismatch for print/teTeX-texmf
Running portupgrade with current ports from cvs, I got this failure - print/teTeX-texmf (teTeX-texmf-3.0_3) (checksum mismatch). I also had checksum mismatchs for multimedia/mplayer-skins, but I was able to get past that by rm'ing the config and using only the default skin. Anyone know anything about these two problems? Have the maintainers been informed? -- Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Checksum mismatch for print/teTeX-texmf
Brooks Davis wrote: On Wed, Jul 26, 2006 at 10:24:17AM -0500, Paul Schmehl wrote: Running portupgrade with current ports from cvs, I got this failure - print/teTeX-texmf (teTeX-texmf-3.0_3) (checksum mismatch). I also had checksum mismatchs for multimedia/mplayer-skins, but I was able to get past that by rm'ing the config and using only the default skin. Anyone know anything about these two problems? Have the maintainers been informed? I've often had problems with the teTeX-texmf dist files. Deleting and redownloading them usually works (as annoying as that is.) Thanks, Brooks. This worked for me as well. -- Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ smime.p7s Description: S/MIME Cryptographic Signature
pr95018
Has anyone looked at this? -- Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas http://www.utdallas.edu/ir/security/ smime.p7s Description: S/MIME Cryptographic Signature
Problems with perl upgrade
I'm preparing to upgrade two servers. I decided to upgrade perl to 5.10.0 before doing anything else (I've done this before on other systems), but I ran into a problem. Per /usr/ports/UPDATING # portupgrade -o lang /perl5.10 -f perl-5.8.\*** There are errors in a meta info for perl-5.8.9 ** Run 'pkgdb -F' to interactively fix them. But when I run pkgdb: # pkgdb -F---> Checking the package registry database Checking /usr/local/lib/perl5, I have two directories; 5.8.8 and 5.8.9. How do I solve this problem? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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: perl upgrade problems
Ignore my last message, just like I ignored the space between lang and /. Sorry to bother the list. Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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"
Nessus 4.0.1 for FreeBSD
Has anyone downloaded this binary distro and gotten it working on FreeBSD? I tried it recently, with disasterous results. It not only didn't work, but it blew up my port install, which now refuses to update the plugins. If someone knows how to get 4.0.1 working on FreeBSD, I'd sure appreciate a brief tutorial. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** Check the headers before clicking on Reply. ___ 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: Nessus 4.0.1 for FreeBSD
--On Tuesday, June 16, 2009 13:17:52 -0500 Paul Schmehl wrote: Has anyone downloaded this binary distro and gotten it working on FreeBSD? I tried it recently, with disasterous results. It not only didn't work, but it blew up my port install, which now refuses to update the plugins. If someone knows how to get 4.0.1 working on FreeBSD, I'd sure appreciate a brief tutorial. Apparently persistence pays off. After installing (using pkg_add), and had to run nessusd -R twice to fix the plugins dbs so that the daemon would start and run properly. So anyone who's trying to do this, after registering and fetching the plugins, run nessusd -R twice (if it craters the first time, as it did for me) before starting the daemon. After that everything should work as expected. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** Check the headers before clicking on Reply. ___ 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"
Question about a failure report
I just got a failure report for one of my ports: security/barnyard-squil. That port is a slave port to security/barnyard. The error is: ** ERROR: unable to find mysql headers (mysql.h) checked in the following places /mysql.h ** This is what I have in the Makefile of security/barnyard: .if defined(WITH_MYSQL) USE_MYSQL= yes CONFIGURE_ARGS+=--enable-mysql .endif How do I fix this since I'm using the builtin macro? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** Check the headers before clicking on Reply. ___ 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: Question about a failure report
--On Friday, July 03, 2009 14:16:05 -0500 Alex Goncharov wrote: ,--- You/Paul (Fri, 03 Jul 2009 18:18:02 +) * | I just got a failure report for one of my ports: | security/barnyard-squil. That port is a slave port to | security/barnyard. | | ** | ERROR: unable to find mysql headers (mysql.h) | checked in the following places | /mysql.h | ** | | How do I fix this since I'm using the builtin macro? If you don't want to use MySQL, run `make config' in `security/barnyard', and uncheck MySQL. But if you want to use MySQL (which is more likely), add MySQL to barnyard-sguil's BUILD_DEPENDS and RUN_DEPENDS. I can't do that, because the port can be built to support either mysql or postgresql, so both are OPTIONS. Mysql is selected by default, and postgresql is not, but that's up to the port builder. Since mysql is preselected, the port *should* install mysql if it's not installed. For some reason, The error report is coming from here: The Restless Daemon identified a makefile error while trying to build: barnyard-sguil-0.2.0_5 maintained by pa...@utdallas.edu Makefile ident: $FreeBSD: ports/security/barnyard-sguil/Makefile,v 1.4 2008/05/09 21:33:40 itetcu Exp $ Since it's a tinderbox, does it ignore OPTIONS and not install dependent ports? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** Check the headers before clicking on Reply. ___ 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: Question about a failure report
--On Friday, July 03, 2009 15:08:31 -0500 Alex Goncharov wrote: ,--- You/Paul (Fri, 03 Jul 2009 19:56:48 +) * | Since mysql is preselected, the port *should* install mysql if it's | not installed. For some reason, If MySQL is in BUILD or LIB _DEPENDS . | Since it's a tinderbox, does it ignore OPTIONS and not install | dependent ports? Options decide the settings of make variables. With the default options, your WITH_MYSQL gets set to 'true' -- in this case, MYSQL should be listed as a dependency in your Makefile, which it is not. So I need to add BUILD_DEPENDS= yes to the OPTION? I'm not quite sure how to do this. I thought that's what USE_MYSQL did. -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: Question about a failure report
--On Friday, July 03, 2009 14:57:52 -0500 Sahil Tandon wrote:
On Fri, 03 Jul 2009, Paul Schmehl wrote:
I just got a failure report for one of my ports: security/barnyard-squil.
s/squil/sguil/ :-)
That port is a slave port to security/barnyard.
The error is:
**
ERROR: unable to find mysql headers (mysql.h)
checked in the following places
/mysql.h
**
The configure script needs some direction.
This is what I have in the Makefile of security/barnyard:
.if defined(WITH_MYSQL)
USE_MYSQL= yes
CONFIGURE_ARGS+=--enable-mysql
.endif
How do I fix this since I'm using the builtin macro?
In security/barnyard/Makefile, try:
CONFIGURE_ARGS+= --enable-mysql \
--with-mysql-includes=${LOCALBASE}/include/mysql \
--with-mysql-libraries=${LOCALBASE}/lib/mysql
I *thought* that was what USE_MYSQL meant. The CONFIGURE_ARGS I'm using are
for barnyard. It then looks for the mysql header file, which it should find if
mysql is installed. USE_MYSQL=yes means (if I understand the bsd.database.mk
file)
BUILD_DEPENDS+=
${LOCALBASE}/lib/mysql/libmysqld.a:${PORTSDIR}/databases/mysql${MYSQL_VER}-client
(see lines 142ff in bsd.database.mk.)
If I can build barnyard-sguil (and really barnyard since the former is a slave
port) by selecting that OPTION *and* the OPTION Is preselected, why does the
build fail when run on tinderbox? Unless I'm totally misunderstanding what
USE_MYSQL means, the BUILD_DEPENDS is included if mysql is selected. Adding
CONFIGURE_ARGS for includes and libraries should only be necessary if those are
in a non-standard location *or* the software simply refuses to build without
specifying them. It does not.
Again, I'm confused. I don't understand why the build fails in tinderbox.
Hopefully someone with knowledge of that process can point out the error of my
ways.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
Check the headers before clicking on Reply.
___
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: can you PLEASE _read_ the QAT mails? (was: Re: Question about a failure report)
--On July 5, 2009 11:15:32 AM +0300 Ion-Mihai Tetcu wrote: Paul, I'm not picking on you, it's just that it's the 4th mail I get in the last days showing the same thing. Sigh, at lest this one was a question, not trying to convince me QATty setup is wrong because we don't support non-default configs. For short, your port's configure script fails to search for mysql headers in the right place; QATty has LOCALBASE and PREFIX set to /usr/PPP. If you can't sorted out in a few days drop me an email and I'll take a look. No offense taken. The thing that confused me is that I always build my ports in /tmp/portname when testing, but barnyard still managed to find mysql headers when building. So I didn't understand why it was failing in QAT. I followed all the links in the email and read the materials, but I still didn't understand why the build failed in QAT. I didn't want to make a change to the port unless the problem really was with the port. That's why I asked the question. Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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: Multiple instances of Mailman on FreeBSD
--On Wednesday, August 12, 2009 13:55:18 -0500 Jeffrey Goldberg wrote: I'm posting this to both the mailman-users list and the freebsd-ports list. I realize that not all follow-up will make it to both lists. I would like to set up multiple instances of Mailman on a FreeBSD 7- STABLE system with using Postfix. Looking at the ports Makefile, it appears that if I set MM_DIR=mailman/vhosts/domain-for-this-instance everything should work file (plus add FORCE_PACKAGE_REGISTER allow this second instance to be installed.) But when I do % cd /usr/ports/mail/mailman % sudo make -DMM_DIR=mailman/vhosts/lists.wilson-pta.org - DFORCE_PKG_REGISTER install It just installs in the default location, /usr/local/mailman And this paradoxical report of various settings $ sudo make MM_DIR=mailman/vhosts/lists.wilson-pta.org - This could be a really stupid question (because I've never tried to do what you're doing), but shouldn't the above line be: $ sudo make MM_DIR=/mailman/vhosts/lists.wilson-pta.org In other words, don't you have to provide the *absolute* patch to the install location? In addition, I would think you would need to change PREFIX as well for the port to install where you want it to. So, ISTM, you should be doing this: $ sudo make PREFIX=/usr/local/mailman/vhost/lists.wilson-pta.org -DFORCE_PKG_REGISTER install rather than trying to set MM_DIR. Note you may *also* have to set MM_DIR, but I'm almost certain you need to set PREFIX if you want the port to install there instead of /usr/local/mailman. The problem is, I'm not exactly sure *where* you want mailman to install, so it's hard to be correct without more information. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: Migration to new SourceForge url scheme now inevitable, solution
--On Wednesday, August 19, 2009 23:08:04 -0500 "Philip M. Gollucci" wrote: Dmitry Marakasov wrote: [1] http://people.freebsd.org/~amdmi3/sf.pl.txt Awesome. Rewriting this: my $portname = `make -VPORTNAME`; chomp $portname; my $portname_lc = lc($portname); my $portversion = `make -VPORTVERSION`; chomp $portversion; Like this, will help substantially by reducing make spawns by 1/2, you'll notice the ports tinderbox code does this too :) my @lines = lc `make -V PORTNAME -V PORTVERSION`; my $portname = $lines[0]; chomp $portname; my $portversion = $lines[1]; chomp $portversion; (untested) [2] http://people.freebsd.org/~amdmi3/sourceforge-subdirs.txt [3] http://people.freebsd.org/~amdmi3/sourceforge-subdirs-top.txt I've been following this discussion closely since several of my ports fetch from Sourceforge. Is it safe to assume that some global solution will be applied to the ports tree? Or are we maintainers going to need to submit PRs for affected ports once a solution is agreed upon? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: Migration to new SourceForge URL scheme part 2, SFE and some statistics
--On Wednesday, September 02, 2009 04:05:08 -0500 Ion-Mihai Tetcu wrote: In my case, over a few retries, switch is the fastest, followed by surfnet. heatnet is only somewhere between 500-700K. dfn, garr: and ovh fail. It might be way too much work for very little benefit, but network latencies being what they are, perhaps there should be a routine that runs periodically and adjusts the list according to some connectivity parameters? (Yeah, I know, easy for me to say. I don't have to write the code.) -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
net-im/pidgin-sipe won't build
I'm trying to install this port but it fails consistently with the following error. py25-cairo-1.8.8 needs Python 2.6 at least. But you specified 2.5. I ran upgrade-site-packages (per /usr/ports/UPDATING) and got this error: ** Port marked as IGNORE: graphics/py-cairo: needs Python 2.6 at least. But you specified 2.5 I uninstalled and reinstalled graphics/py-cairo, and I *still* get the error, even though py-cairo *says* it's py26. /usr/ports/net-im/pidgin-sipe]# pkg_info -a | grep py | grep cairo py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Information for py26-cairo-1.8.8: py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Where the heck is the IGNORE coming from? It's not in /etc/make.conf. It's not in /usr/local/etc/pkgtools.conf. Any useful advice would be appreciated. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: net-im/pidgin-sipe won't build
Bueller Anyone --On Wednesday, September 16, 2009 18:04:14 -0500 Paul Schmehl wrote: I'm trying to install this port but it fails consistently with the following error. py25-cairo-1.8.8 needs Python 2.6 at least. But you specified 2.5. I ran upgrade-site-packages (per /usr/ports/UPDATING) and got this error: ** Port marked as IGNORE: graphics/py-cairo: needs Python 2.6 at least. But you specified 2.5 I uninstalled and reinstalled graphics/py-cairo, and I *still* get the error, even though py-cairo *says* it's py26. /usr/ports/net-im/pidgin-sipe]# pkg_info -a | grep py | grep cairo py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Information for py26-cairo-1.8.8: py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Where the heck is the IGNORE coming from? It's not in /etc/make.conf. It's not in /usr/local/etc/pkgtools.conf. Any useful advice would be appreciated. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: net-im/pidgin-sipe won't build
--On Thursday, September 17, 2009 12:05:03 -0500 Lowell Gilbert wrote: Paul Schmehl writes: Bueller Anyone --On Wednesday, September 16, 2009 18:04:14 -0500 Paul Schmehl wrote: I'm trying to install this port but it fails consistently with the following error. py25-cairo-1.8.8 needs Python 2.6 at least. But you specified 2.5. I ran upgrade-site-packages (per /usr/ports/UPDATING) and got this error: ** Port marked as IGNORE: graphics/py-cairo: needs Python 2.6 at least. But you specified 2.5 I uninstalled and reinstalled graphics/py-cairo, and I *still* get the error, even though py-cairo *says* it's py26. /usr/ports/net-im/pidgin-sipe]# pkg_info -a | grep py | grep cairo py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Information for py26-cairo-1.8.8: py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Where the heck is the IGNORE coming from? It's not in /etc/make.conf. It's not in /usr/local/etc/pkgtools.conf. Any useful advice would be appreciated. There's nothing obvious; I can't find the IGNORE either, although obviously my ports tree may not match yours exactly. The code for the upgrade-site-packages target is not completely clear to me. Do you have any python-related variables in make.conf? Is there anything bogus looking in /usr/local/lib/python*? /etc/make.conf OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_BASE_PORT=f8 OVERRIDE_LINUX_NONBASE_PORTS=f8 # added by use.perl 2009-07-11 15:13:00 PERL_VERSION=5.10.0 /usr/local/lib/phython* # grep -ri cairo /usr/local/lib/python2.* Binary file /usr/local/lib/python2.6/site-packages/cairo/_cairo.so matches /usr/local/lib/python2.6/site-packages/cairo/_cairo.la:# _cairo.la - a libtool library file /usr/local/lib/python2.6/site-packages/cairo/_cairo.la:dlname='_cairo.so' /usr/local/lib/python2.6/site-packages/cairo/_cairo.la:library_names='_cairo.so _cairo.so _cairo.so' /usr/local/lib/python2.6/site-packages/cairo/_cairo.la:dependency_libs=' -L/usr/local/lib /usr/local/lib/libcairo.la -pthread /usr/local/lib/libpixman-1.la /usr/local/lib/libfontconfig.la /usr/local/lib/libfreetype.la /usr/local/lib/libexpat.la -lpng /usr/local/lib/libxcb-render-util.la /usr/local/lib/libxcb-render.la /usr/local/lib/libXrender.la /usr/local/lib/libX11.la /usr/local/lib/libxcb.la /usr/local/lib/libXau.la /usr/local/lib/libXdmcp.la -lrpcsvc -lz -lm' /usr/local/lib/python2.6/site-packages/cairo/_cairo.la:# Version information for _cairo. /usr/local/lib/python2.6/site-packages/cairo/_cairo.la:libdir='/usr/local/lib/python2.6/site-packages/cairo' /usr/local/lib/python2.6/site-packages/cairo/__init__.py:from _cairo import * Binary file /usr/local/lib/python2.6/site-packages/cairo/__init__.pyc matches Binary file /usr/local/lib/python2.6/site-packages/cairo/__init__.pyo matches I am at a loss to know where this error is coming from. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
multimedia/py-gstreamer fails to build
to new API See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors Warning: Constructor for GstNetClientClock needs to be updated to new API See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors Warning: Constructor for GstNetTimeProvider needs to be updated to new API See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors Warning: Constructor for GstController needs to be updated to new API See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors Warning: Constructor for GstDataQueue needs to be updated to new API See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors ***INFO*** The coverage of global functions is 86.41% (159/184) ***INFO*** The coverage of methods is 90.07% (490/544) ***INFO*** The coverage of virtual proxies is 86.76% (59/68) ***INFO*** The coverage of virtual accessors is 87.67% (64/73) ***INFO*** The coverage of interface proxies is 100.00% (5/5) CCgst.o gst.c: In function 'pygst_register_classes': gst.c:27079: error: 'GST_TYPE_BUFFER_LIST' undeclared (first use in this function) gst.c:27079: error: (Each undeclared identifier is reported only once gst.c:27079: error: for each function it appears in.) gmake[3]: *** [_gst_la-gst.lo] Error 1 gmake[2]: *** [all-recursive] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/multimedia/py-gstreamer. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: net-im/pidgin-sipe won't build
--On Thursday, September 17, 2009 12:05:03 -0500 Lowell Gilbert wrote: Paul Schmehl writes: Bueller Anyone --On Wednesday, September 16, 2009 18:04:14 -0500 Paul Schmehl wrote: I'm trying to install this port but it fails consistently with the following error. py25-cairo-1.8.8 needs Python 2.6 at least. But you specified 2.5. I ran upgrade-site-packages (per /usr/ports/UPDATING) and got this error: ** Port marked as IGNORE: graphics/py-cairo: needs Python 2.6 at least. But you specified 2.5 I uninstalled and reinstalled graphics/py-cairo, and I *still* get the error, even though py-cairo *says* it's py26. /usr/ports/net-im/pidgin-sipe]# pkg_info -a | grep py | grep cairo py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Information for py26-cairo-1.8.8: py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 py26-cairo-1.8.8 Where the heck is the IGNORE coming from? It's not in /etc/make.conf. It's not in /usr/local/etc/pkgtools.conf. Any useful advice would be appreciated. There's nothing obvious; I can't find the IGNORE either, although obviously my ports tree may not match yours exactly. The code for the upgrade-site-packages target is not completely clear to me. Do you have any python-related variables in make.conf? Is there anything bogus looking in /usr/local/lib/python*? I managed to resolve the problem by uninstalling python25 and running pkgdb -F to remove all the stale, irrelevant dependencies. Then I ran make install -DFORCE_PKG_REGISTER and the install completed successfully. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: multimedia/py-gstreamer fails to build
--On September 17, 2009 6:26:54 PM -0500 Koop Mast wrote: On Thu, 2009-09-17 at 22:01 +, Paul Schmehl wrote: i386 Intel, FreeBSD 7.2-STABLE, freshly csup'd ports tree, python 2.6 is the default version. Maybe the upgrade to python 2.6 broke this port? Compiles fine here, are your installed gstreamer ports up to date? Yes. I ran portupgrade -a on that server just last week. I managed to get the port installed by editing the Makefile to revert to 0.10.15. Got lots of INFO errors, but it compiled successfully. Is there something in particular I can do to test the other gstreamer ports to verify? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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: multimedia/py-gstreamer fails to build
--On Friday, September 18, 2009 04:02:28 -0500 Koop Mast wrote: Is there something in particular I can do to test the other gstreamer ports to verify? Make sure you got gstreamer 0.10.24. Your build of py-gstreamer breaks because of the lack of GST_TYPE_BUFFER_LIST. This was introduced in that version of gstreamer. That was the issue. I portupgraded all the gstreamer ports, then forced an upgrade of the py26-gstreamer port, and it built fine. Still through a bunch of warning and INFO messages, but it built successfully. Thanks for your help. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
lsof won't build
I'm getting this error when trying to install sysutils/lsof: /usr/src/sys/vm/vm.h:64:24: error: machine/vm.h: No such file or directory Shouldn't machine be some sort of macro that points at the ARCH of the system lsof is being installed on? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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: lsof won't build
--On September 19, 2009 1:58:32 PM -0400 Robert Huff wrote: Paul Schmehl writes: I'm getting this error when trying to install sysutils/lsof: /usr/src/sys/vm/vm.h:64:24: error: machine/vm.h: No such file or directory Shouldn't machine be some sort of macro that points at the ARCH of the system lsof is being installed on? Having experienced this recently: The usual casue of this is the installed kernel(+world ??) being out of sync with the contents of /usr/src. The solution is to rebuild/reinstall kernel(+world ??). Perosnally I think it's bad programming also ... but then I'm not the one writing the code. That doesn't make sense to me. vm.h is a src file. My src files are updated daily. Even if I rebuilt the kernel (this one has been recompiled twelve times already), the src files wouldn't change. The build error is complaining about not being able to find the header file for (I'm assuming) my architecture, not for some binary compiled during the kernel build. Are you saying you rebuilt kernel and lsof built fine afterwards? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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: lsof won't build
--On September 19, 2009 6:16:22 PM -0400 Lowell Gilbert wrote: Robert Huff writes: Paul Schmehl writes: > The usual casue of this is the installed kernel(+world ??) > being out of sync with the contents of /usr/src. That doesn't make sense to me. vm.h is a src file. I have not read the code ... but as I understnd it, the build process draws on header files from both /usr/include and /usr/src. If the two disagree - . Not exactly. Buildworld first builds the toolchain from the source tree, then uses that toolchain to build the rest of the system. lsof isn't part of the system build; it comes from the ports system. Are you saying you rebuilt kernel and lsof built fine afterwards? Right. lsof needs to look at kernel structures, so it has to be built from the same headers that the kernel was, or it won't know how to interpret the data it retrieves. Thanks, Lowell. That makes sense. Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** WARNING: Check the headers before replying ___ 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: policy-weight -spawn $csock error after power out reboot
--On Saturday, October 17, 2009 05:15:30 -0500 David Southwell wrote: Hi FreeBSD dns1.vizion2000.net 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #0: Thu Aug 20 12:54:34 BST 2009 da...@dns1.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 [on intel quad] Following an abrupt power system failure and a system reboot this server now gets this error in maillog: postfix/policyd-weight[9622]: warning: cache_query: $csock couln't be created: connect: No such file or directory, calling spawn_cache() No other problems. Just in case it was due to a retained. pid I deleted the .pid file followed by a normal shutdown and reboot - but am still getting the same problem. Thanks in advance for any guidance It doesn't look like anyone has answered this. That warning message is normal to see at startup but should not persist. The solution is to rm -fr /tmp/.policyd-weight, then restart policyd-weight. Policyd-weight will then recreate that dir and recreate its socket as well as the other files and dirs that go there. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
install-sh - permission denied
I'm working on a new port, and I'm getting this error during make install: test -z "/usr/local/bin" || .././install-sh -c -d "/usr/local/bin" .././install-sh: Permission denied Can anyone tell me why I'm getting this? My system is 7.2 STABLE 7.2-STABLE FreeBSD 7.2-STABLE #13: Thu Sep 24 09:02:53 CDT 2009 Ports are csuped daily. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: install-sh - permission denied
--On Tuesday, October 20, 2009 12:31:43 -0500 Matthew Seaman wrote: Paul Schmehl wrote: I'm working on a new port, and I'm getting this error during make install: test -z "/usr/local/bin" || .././install-sh -c -d "/usr/local/bin" .././install-sh: Permission denied Can anyone tell me why I'm getting this? My system is 7.2 STABLE 7.2-STABLE FreeBSD 7.2-STABLE #13: Thu Sep 24 09:02:53 CDT 2009 Ports are csuped daily. At a guess, it's because you don't have sufficient permissions to run .././install-sh with the arguments shown. Now, one fairly obvious reason why this wouldn't work is that .././install-sh isn't marked executable for your UID. Judging by the file name, this is a shell script, so also check that your UID has sufficient permissions to run the shell on the #! line of the script too. I can't really tell just by looking at the command names, but I'm guessing that this command creates /usr/local/bin as a directory if it doesn't already exist. Basically an obscurantist and over-engineered way of running a simple: # mkdir -p /usr/local/bin This is entirely unnecessary when dealing with the ports. You may take it as read that the basic layout of directories under /usr/local will have been created for you by using mtree(8) and /etc/mtree/BSD.local.dist The problem is, I'm doing this as root. :-( -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: install-sh - permission denied
--On Tuesday, October 20, 2009 11:49:49 -0500 Paul Schmehl wrote: I'm working on a new port, and I'm getting this error during make install: test -z "/usr/local/bin" || .././install-sh -c -d "/usr/local/bin" .././install-sh: Permission denied Can anyone tell me why I'm getting this? My system is 7.2 STABLE 7.2-STABLE FreeBSD 7.2-STABLE #13: Thu Sep 24 09:02:53 CDT 2009 Ports are csuped daily. As a followup - I doing all of this after suing to root, so it's hard to understand why permissions would be a problem. This is only happening in this new port I'm trying to develop, which seems even stranger, because this is an exact copy of an existing port that I maintain (which builds fine - I checked just a few minutes ago), which some editing done to the Makefile to download and build a new version of the same software. There's no NFS mounts involved. All partitions are mounted normally. # mount /dev/ad8s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad8s1f on /tmp (ufs, local, soft-updates) /dev/ad8s1d on /usr (ufs, local, soft-updates) /dev/ad8s1e on /var (ufs, local, soft-updates) /dev/ad10s1d on /data (ufs, local, soft-updates) Perms on /usr/local are "standard". # ls -lsa /usr/local/ total 196 2 drwxr-xr-x 22 root wheel512 Sep 19 12:11 . 2 drwxr-xr-x 19 root wheel512 Feb 20 2008 .. 38 drwxr-xr-x6 root wheel 38912 Oct 20 12:43 bin 2 drwxr-xr-x3 root wheel512 Feb 22 2008 com 2 drwxr-xr-x9 root wheel512 Sep 18 22:20 diablo-jdk1.6.0 2 drwxr-xr-x7 root wheel512 Sep 18 22:15 diablo-jre1.6.0 2 drwxr-xr-x2 root wheel512 Feb 21 2008 env 4 drwxr-xr-x 40 root wheel 2560 Oct 20 12:43 etc 34 drwxr-xr-x 210 root wheel 34816 Oct 9 13:05 include 4 drwxr-xr-x3 root wheel 2560 Sep 24 16:07 info 78 drwxr-xr-x 83 root wheel 78848 Oct 9 13:05 lib 2 drwxr-xr-x8 root wheel512 Jul 11 14:37 libdata 2 drwxr-xr-x 10 root wheel 2048 Sep 24 16:07 libexec 2 drwxr-xr-x 33 root wheel 1024 Oct 10 09:42 man 2 drwxr-xr-x 11 root wheel512 Jun 16 16:39 nessus 2 drwxr-xr-x2 pgsql pgsql512 Apr 11 2009 pgsql 4 drwxr-xr-x2 root wheel 3072 Sep 24 15:09 sbin 4 drwxr-xr-x 156 root wheel 3072 Sep 24 16:06 share 2 drwxr-xr-x4 root wheel512 Sep 18 22:14 src 2 drwxr-xr-x2 root wheel512 Aug 6 12:57 translations 2 drwxr-xr-x4 root wheel512 Feb 22 2008 var 2 drwxr-xr-x3 root wheel512 Sep 19 11:58 www -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: install-sh - permission denied
--On Tuesday, October 20, 2009 13:35:57 -0500 Scott Lambert wrote: wrote: I'm working on a new port, and I'm getting this error during make install: test -z "/usr/local/bin" || .././install-sh -c -d "/usr/local/bin" .././install-sh: Permission denied Is the execute bit set on ../install.sh? Bingo! No, it's not. Now the question is - why isn't it? What controls the perms on that? I just made clean and the made extract. The file is set to rw-r--r-- root wheel. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: install-sh - permission denied
--On Tuesday, October 20, 2009 13:59:54 -0500 Scot Hetzel wrote: On Tue, Oct 20, 2009 at 1:55 PM, Paul Schmehl wrote: --On Tuesday, October 20, 2009 13:35:57 -0500 Scott Lambert wrote: wrote: I'm working on a new port, and I'm getting this error during make install: test -z "/usr/local/bin" || .././install-sh -c -d "/usr/local/bin" .././install-sh: Permission denied Is the execute bit set on ../install.sh? Bingo! No, it's not. Now the question is - why isn't it? What controls the perms on that? I just made clean and the made extract. The file is set to rw-r--r-- root wheel. Either it is not set in the tar file or your umask is blocking the setting of the execute bit. Thanks, Scot. It's not set in the tarfile. Appreciate the help. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
Need advice from maintainers
I am the maintainer for security/barnyard2. This is an updated version of security/barnyard, which I also maintain. The version of my port is the current release version, but it has a really irritating problem that is fixed in the current beta version. Barnyard2 is a program that parses snort logs and inserts them into a database (mysql or postgresql). It is supposed to create a placemarker file (called a waldo file) that maintains a record of what logs it has already parsed. (This is only one way of using the program. There are others as well.) The problem in the release version is that it does not read the waldo file when the program is restarted. So every time you restart barnyard2, it reinserts into the database every alert you still have log files for. The beta version fixes this problem. I have created a port for the beta version and am using it myself, but I know that using beta versions of software is frowned upon. Should I go ahead and submit this port because it solves this problem? If I do, my thinking is that I should adjust the pkg-message file in the existing port to warn the user about the problem and note that the beta version solves it so they might want to consider using that instead. Also, if I do submit the port, should it be named barnyard2-beta? Or barnyard2-devel? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: Need advice from maintainers
--On Wednesday, October 21, 2009 10:31:21 -0500 Bill Moran wrote: In response to Paul Schmehl : I am the maintainer for security/barnyard2. This is an updated version of security/barnyard, which I also maintain. The version of my port is the current release version, but it has a really irritating problem that is fixed in the current beta version. Barnyard2 is a program that parses snort logs and inserts them into a database (mysql or postgresql). It is supposed to create a placemarker file (called a waldo file) that maintains a record of what logs it has already parsed. (This is only one way of using the program. There are others as well.) The problem in the release version is that it does not read the waldo file when the program is restarted. So every time you restart barnyard2, it reinserts into the database every alert you still have log files for. The beta version fixes this problem. I have created a port for the beta version and am using it myself, but I know that using beta versions of software is frowned upon. Should I go ahead and submit this port because it solves this problem? If I do, my thinking is that I should adjust the pkg-message file in the existing port to warn the user about the problem and note that the beta version solves it so they might want to consider using that instead. An option that you did not mention is to take the patch that fixes that single problem and include as a patch file for barnyard2. That way it's not a true beta, it just has that single patch to fix a known problem. For me, I think that would be the preferred method in this case. I *might* be able to do that, if I can figure out where in the code the problem is fixed. I've had two semesters of C++, but I am not a programmer and consider myself the rankest of novices wrt code. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
Need help with a port
I'm the port maintainer for security/barnyard2. I submitted a port
upgrade a while ago, but the committer asked me to make a change before he
would approve it. I'm not sure what to do.
The source code, when it's extracted, sets the perms on install-sh to
r--r--r. This causes an error during the build. The way I tried to
resolve the issue was by adding this to the Makefile:
+pre-install:
+${CHMOD} 744 ${WRKSRC}/install-sh
+
The committer said that was the wrong way to do it, that I should edit the
configure file. But the configure file doesn't do anything to the
install-sh file at all.
Is there some other way to resolve this problem? I'd like to get this
update completed and approved.
This is the PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/140393
Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
**
WARNING: Check the headers before replying
___
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: Need help with a port
--On Thursday, December 17, 2009 23:48:08 -0600 Nikola Lečić
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On Wed, 16 Dec 2009 21:58:21 -0600
Paul Schmehl wrote:
I'm the port maintainer for security/barnyard2. I submitted a port
upgrade a while ago, but the committer asked me to make a change
before he would approve it. I'm not sure what to do.
The source code, when it's extracted, sets the perms on install-sh to
r--r--r. This causes an error during the build. The way I tried to
resolve the issue was by adding this to the Makefile:
+pre-install:
+${CHMOD} 744 ${WRKSRC}/install-sh
+
The committer said that was the wrong way to do it, that I should
edit the configure file. But the configure file doesn't do anything
to the install-sh file at all.
I think this should actually be ${CHMOD} ${BINMODE}. I have a similar
thing in one of my ports: textproc/teckit. Besides install-sh, the
permissions of configure script itself had to be altered.
A simple grep for CHMOD and WRKSRC reveals a heap of ports doing such
things in ${WRKSRC}...
I see that now:
# grep -r install-sh * | grep "WRKSRC" | grep "CHMOD"
grep: security/base/work/base-php4/signatures: No such file or directory
archivers/par2cmdline-tbb/Makefile: @${CHMOD} u+x ${WRKSRC}/install-sh
audio/mhwaveedit/Makefile: @${CHMOD} +x ${WRKSRC}/install-sh
audio/gbemol/Makefile: @${CHMOD} a+x ${WRKSRC}/install-sh
biology/phyml/Makefile: ${CHMOD} a+x ${WRKSRC}/install-sh
chinese/fcitx/Makefile: @${CHMOD} 0755 ${WRKSRC}/install-sh
converters/libticonv/Makefile: @${CHMOD} 755 ${WRKSRC}/install-sh
deskutils/google-gadgets/Makefile: @cd ${WRKSRC} && ${CHMOD} +x
autotools/install-sh
devel/acovea-gtk/Makefile: ${CHMOD} 755 ${WRKSRC}/install-sh
devel/rudeconfig/Makefile: ${CHMOD} 744 ${WRKSRC}/install-sh
devel/bennugd-core/Makefile:@${CHMOD} a+x ${WRKSRC}/configure
${WRKSRC}/install-sh
devel/bennugd-modules/Makefile: @${CHMOD} a+x ${WRKSRC}/configure
${WRKSRC}/install-sh
emulators/tiemu3/Makefile: ${CHMOD} +x ${WRKSRC}/install-sh
games/brutalchess/Makefile: ${CHMOD} 0755 ${WRKSRC}/install-sh
games/crossfire-server/Makefile:@${CHMOD} a+x ${WRKSRC}/utils/install-sh
games/daimonin-client/Makefile: @${CHMOD} a+x ${WRKSRC}/configure
${WRKSRC}/make_utils/install-sh
games/libfov/Makefile: @${CHMOD} ${BINMODE} ${WRKSRC}/install-sh
games/numptyphysics/Makefile: @${CHMOD} a+x ${WRKSRC}/install-sh
games/pipewalker/Makefile: @${CHMOD} a+x ${WRKSRC}/install-sh
japanese/mecab/Makefile:${CHMOD} a+x ${WRKSRC}/install-sh
math/pgcalc/Makefile: @${CHMOD} 755 ${WRKSRC}/skins/HP49G+
${WRKSRC}/admin/install-sh
misc/hello/Makefile:${CHMOD} a+x ${WRKSRC}/build-aux/install-sh
misc/talkfilters/Makefile: @${CHMOD} +x ${WRKSRC}/install-sh
multimedia/flvmeta/Makefile:${CHMOD} a+x ${WRKSRC}/install-sh
net/grsync/Makefile:@${CHMOD} u+x ${WRKSRC}/install-sh
net-im/trix/Makefile: ${CHMOD} 744 ${WRKSRC}/install-sh
net-p2p/dclib/Makefile: ${CHMOD} 0755 ${WRKSRC}/admin/install-sh
print/texinfo/Makefile: ${CHMOD} 755 ${WRKSRC}/build-aux/install-sh
security/barnyard2/patch-Makefile:+ ${CHMOD} 744 ${WRKSRC}/install-sh
security/barnyard2-devel.shar:X ${CHMOD} a+x ${WRKSRC}/install-sh
sysutils/duff/Makefile: ${CHMOD} +x ${WRKSRC}/install-sh
textproc/teckit/Makefile: ${CHMOD} ${BINMODE} ${WRKSRC}/configure
${WRKSRC}/install-sh
www/suphp/Makefile: @${CHMOD} 755 ${WRKSRC}/config/install-sh
x11/alltray/Makefile: @${CHMOD} +x ${WRKSRC}/install-sh
x11-wm/openbox/Makefile:@${CHMOD} +x ${WRKSRC}/install-sh
Two questions come to mind. 1) Is there any standardized way to do this?
(It's obvious it's not being done in a standard way) 2) Is there anyone with
the authority to tell me don't/do do it this way and not that way?
It looks like ${CHMOD} ${BINMODE} ${WRKSRC}/install-sh is the "right" way to do
it, but can someone confirm that? And can I finally get my update committed?
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
___
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: Need help with a port
--On December 18, 2009 5:10:39 PM -0600 Greg Larkin
wrote:
Hi Paul,
"make -V BINMODE" returns "555", so as long as you're OK with those
permissions, I would say using the ${BINMODE} macro is preferable.
Otherwise, there's no issue with you using the correct permissions value
(755, +x, etc.) for your situation.
If you're having difficulty getting your port committed because you have
a construct that is used in many other ports, I think you can ask for
portmgr's opinion. They will certainly resolve the issue for you.
IMHO, I don't see any problem with what you're doing.
If your committer has not responded to you in some number of weeks, you
can also ask portmgr to reassign the port back to the pool or to another
willing committer.
My committer asked:
Why is necessary chmod to 755? Why need it?
I answered:
Because the install-sh script has incorrect permissions and generates an
error if you don't set them correctly.
The committer submitted my response to another person who wrote:
I'm sorry that's the wrong way to fix that, the premission problem come
from the configure script, run in the same problem a year ago. Check
games/wormux-devel there is a fix for the same problem maybe you can
take the same way.
I asked for clarification about a month ago. I looked at the port he
referred to, but I don't see how it applies to my situation. So I stated
that and asked for help. None has been forthcoming, but I haven't pushed
it either. I know everyone is busy. I certainly am. And we're all
volunteers as well. So, I'm not complaining. I just want to understand
what the right way is to solve this particular problem and get the port
committed.
I've cc'd both of them as well as portmgr. I'll do whatever I'm told to
do.
Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
**
WARNING: Check the headers before replying
___
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"
Problems with the security/snort port
For some reason, since the upgrade of snort, the rc.d script does not work properly. The start process remains running and never releases th binary to run in the background as a daemon. As a result, I have to background the start process each time I start snort. # ps -auxw | grep snort root14387 28.1 1.9 26096 9468 p0 R 5:53PM 0:04.27 /usr/local/bin/snort -u snort -g snort -Dq -i sis0 -c /usr/local/et root14333 0.0 1.6 10064 8192 ?? Ss5:50PM 0:00.05 /usr/local/bin/barnyard2 -D -d /var/log/snort -f snort.u2 -w /var/l root14380 0.0 0.3 3464 1348 p0 S 5:53PM 0:00.01 /bin/sh /usr/local/etc/rc.d/snort start As you can see, snort is being started with the -D switch, but the commandline to start the daemon is still running. If I don't background it, and I hit control C to get back to a prompt, snort closes "normally", as though I had hit stop. Has anyone else seen this? Any idea what the problem might be? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
Can someone explain this? (portupgrade of textproc/p5-Perl-Critic
010 10:42:44 -0500 (consumed 00:00:05) ---> Installation of textproc/p5-Perl-Critic started at: Wed, 09 Jun 2010 10:42:44 -0500 ---> Installing the new version via the port ===> Building for p5-Perl-Critic-1.10.6 Building Perl-Critic Can't locate B/Keywords.pm in @INC (@INC contains: inc /usr/local/lib/perl5/5.10.1/BSDPAN /usr/local/lib/perl5/site_perl/5.10.1/mach /usr/local/lib/perl5/site_perl/5.10.1 /usr/local/lib/perl5/5.10.1/mach /usr/local/lib/perl5/5.10.1 .) at t/Variables/RequireLocalizedPunctuationVars.run.PL line 16. BEGIN failed--compilation aborted at t/Variables/RequireLocalizedPunctuationVars.run.PL line 16. t/Variables/RequireLocalizedPunctuationVars.run.PL failed at /usr/local/lib/perl5/site_perl/5.10.1/Module/Build/Base.pm line 2803. *** Error code 2 Stop in /usr/ports/textproc/p5-Perl-Critic. *** Error code 1 Stop in /usr/ports/textproc/p5-Perl-Critic. ===> Cleaning for p5-Perl-Critic-1.10.6 ---> Removing temporary files and directories ---> Removing old package' ---> Installation of textproc/p5-Perl-Critic ended at: Wed, 09 Jun 2010 10:42:46 -0500 (consumed 00:00:02) ---> Cleaning out obsolete shared libraries ---> Upgrade of textproc/p5-Perl-Critic ended at: Wed, 09 Jun 2010 10:42:49 -0500 (consumed 00:00:16) ---> ** Upgrade tasks 1: 1 done, 0 ignored, 0 skipped and 0 failed ---> Listing the results (+:done / -:ignored / *:skipped / !:failed) + textproc/p5-Perl-Critic (p5-Perl-Critic-1.09.0) ---> Packages processed: 1 done, 0 ignored, 0 skipped and 0 failed ---> Session ended at: Wed, 09 Jun 2010 10:42:52 -0500 (consumed 00:00:39) First it checks for prereqs and finds them all. Then it checks for prereqs and says they're missing. Then it generates three stops due to errors, and at the end it says the upgrade was successful??? WTF??? And it *is not* installed. I'm still working to get all the prereqs installed, even though they already were. What exactly is the problem with this port? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: Data files and ports
--On Friday, June 11, 2010 10:58:50 -0300 Jesse Smith wrote: I'm trying to teach myself how to build a FreeBSD port and, with a lot of help from the manual, it's going well. I have a question though concerning policy/style. I'm trying to port a program which is distributed in two separate packages from the upstream project. One package contains the executable program and the other contains data files. The Data package rarely changes. The idea being packaging them together would use up a lot of extra bandwidth. Which brings me to the question: Since the executable relies on the data files being in place before it's run, how should I handle that in the port? Should I just get the executable to install and let the user manually get the data files? Should I create a second port for the data package? Or should I find some way of making the executable's makefile download and unpack the data package? My instinct is to create a separate port for the Data package and list it as a dependency for the Executable port. I'd appreciate some guidance. I think your instinct is correct. You *could* put logic into the Makefile of a single port to verify that the data files are the most recent ones, but having a second port makes a great deal more sense to me, especially since the executables will be updating on a more frequent basis than the data files. Just make the data file port a RUN_DEPENDS of the executable port. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
This construction doesn't work
I'm working on a port update for one of the ports that I maintain, and I've run
into a problem that I can't seem to solve.
I use this construction to ensure that the port doesn't overwrite the conf
file, if one exists:
.for f in barnyard2.conf
${INSTALL_DATA} ${WRKSRC}/etc/${f} ${PREFIX}/etc/${f}-sample
[ -f ${PREFIX}/etc/${f} ] || \
${INSTALL_DATA} ${WRKSRC}/etc/${f} ${PREFIX}/etc/${f}
.endfor
But it gets overwritten anyway. What am I doing wrong? I thought this worked
before, but I can't be sure. Testing proves that it does not work now. I
tried to changing to an if [ ! -f construction, but that didn't do a thing.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
___
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: This construction doesn't work
--On Tuesday, June 29, 2010 09:02:35 -0500 Scot Hetzel
wrote:
On Tue, Jun 29, 2010 at 1:34 AM, Darren Pilgrim wrote:
Paul Schmehl wrote:
I'm working on a port update for one of the ports that I maintain, and
I've run into a problem that I can't seem to solve.
I use this construction to ensure that the port doesn't overwrite the conf
file, if one exists:
.for f in barnyard2.conf
${INSTALL_DATA} ${WRKSRC}/etc/${f} ${PREFIX}/etc/${f}-sample
[ -f ${PREFIX}/etc/${f} ] || \
${INSTALL_DATA} ${WRKSRC}/etc/${f} ${PREFIX}/etc/${f}
.endfor
But it gets overwritten anyway. What am I doing wrong? I thought this
worked before, but I can't be sure. Testing proves that it does not work
now. I tried to changing to an if [ ! -f construction, but that didn't do
a thing.
The above may be working properly, the problem could be that the
sources have code in them that installs barnyard2.conf to PREFIX/etc/.
Check the sources Makefile to see if they are installing this file.
If they are, patch them to install the file as the *-sample.
Instead of doing this in Makefile, do it in pkg-plist:
@unexec if cmp -s %D/etc/barnyard2.conf.sample %D/etc/barnyard2.conf; then
rm -f %D/etc/barnyard2.conf; fi
etc/barnyard2.conf.sample
@exec if [ ! -f %D/etc/barnyard2.conf ] ; then cp -p %D/%F
%D/etc/barnyard2.conf && chmod 600 %D/etc/barnyard2.conf; fi
Relevant section of the Porter's Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/plist-config.html
While this works when installing a package, you still need code in the
Makefile to install barnyard2.conf if it doesn't exist when installing
the port.
You nailed it Scott. The problem was with the Makefile.in in the /etc
directory. It's been fixed, and the port upgrade has been submitted.
Thanks for the tipoff.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
___
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"
Virtualbox consuming wcpu
I recently upgraded to the new port version of virtualbox - 3.2.6. After completing the upgrade, I'm seeing a massive amount of wcpu consumption (145%) with virtualbox when I use the vm to rdp to a different windows box. As long as I'm not using rdp, it works fine. When I first start the rdp, wcpu is fine, but it increases over time (20-30 minutes) until it's consuming cpu to the point where the host becomes very sluggish. Has anyone else experienced this? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
kdepim4-runtime fails to build
Building CXX object agents/ontologies/CMakeFiles/niefast.dir/nmo.o Linking CXX static library ../../lib/libniefast.a [ 40%] Built target niefast gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/deskutils/kdepim4-runtime. I've read UPDATING and made the change to libassuan-1, but this port will not build. Anyone have an idea where to go to fix the problem? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: kdepim4-runtime fails to build
--On Thursday, July 08, 2010 15:39:09 -0500 Paul Schmehl wrote: Building CXX object agents/ontologies/CMakeFiles/niefast.dir/nmo.o Linking CXX static library ../../lib/libniefast.a [ 40%] Built target niefast gmake: *** [all] Error 2 *** Error code 1 Stop in /usr/ports/deskutils/kdepim4-runtime. I've read UPDATING and made the change to libassuan-1, but this port will not build. Anyone have an idea where to go to fix the problem? I fixed the problem by deselecting kde pim. I don't use it anyway. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
Sourceforge has changed?
I'm trying to update a port that I maintain, but the download is failing. Here's the actual path of the download: http://nchc.dl.sourceforge.net/projects/afterglow/files/AfterGlow%201.x/1.6/ But the macro has SF/project/, so the download fails. Did Sourceforge just change their downloads path? It sure looks like it. If true, I imagine a bunch of ports are now "broken". -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
How do I solve this WRKDIR problem?
I'm trying to update the devel/byaccj port, which I maintain. The new version
has made some subtle changes in naming, which have thrown me for a loop;
PORTNAME= byaccj
PORTVERSION= 1.15
DISTFILES= byaccj1.15_src.tar.gz
WRKDIR is work/byaccj1.15 when the files are extracted.
If I don't define WRKSRC, it's byaccj-1.15. If I define it as
${PORTNAME}${PORTVERSION}, it's still byaccj-1.15. Hardcoding it doesn't seem
like the right answer, but what is?
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
___
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: Sourceforge has changed?
--On Thursday, July 22, 2010 21:27:29 + "B. Estrade" wrote: On Thu, Jul 22, 2010 at 04:24:22PM -0500, Paul Schmehl wrote: I'm trying to update a port that I maintain, but the download is failing. Here's the actual path of the download: http://nchc.dl.sourceforge.net/projects/afterglow/files/AfterGlow%201.x/1.6/ But the macro has SF/project/, so the download fails. Did Sourceforge just change their downloads path? It sure looks like it. If true, I imagine a bunch of ports are now "broken". I recently had the same issue, but it turns out I was trying to test the port as an unprivileged user. Try testing the build with sudo or as root. I am root. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: How do I solve this WRKDIR problem?
--On Thursday, July 22, 2010 18:00:32 -0400 Greg Larkin
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Schmehl wrote:
I'm trying to update the devel/byaccj port, which I maintain. The new
version has made some subtle changes in naming, which have thrown me for
a loop;
PORTNAME= byaccj
PORTVERSION= 1.15
DISTFILES= byaccj1.15_src.tar.gz
WRKDIR is work/byaccj1.15 when the files are extracted.
If I don't define WRKSRC, it's byaccj-1.15. If I define it as
${PORTNAME}${PORTVERSION}, it's still byaccj-1.15. Hardcoding it
doesn't seem like the right answer, but what is?
Hi Paul,
I didn't have a problem downloading the 1.15 distfile from SF (ref: your
other message) nor setting WRKSRC to the correct value. Please check my
Makefile diff here, and let me know if it works for you or not.
http://people.freebsd.org/~glarkin/diffs/byaccj-Makefile.diff
The build immediately fails, though, because the distro Makefile has
some MacOSX-specific stuff in it. I presume that's what you're working
on fixing in the port update.
Thanks to your help I spotted my error and fixed it. I'm about ready to submit
the update. It's amazing how often I can look at something and not see it. :-(
The Sourceforge situation is a mess, though. I'm going to have to wait for
that to get fixed in the macros before I can proceed with afterglow.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
___
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: Sourceforge has changed?
--On Thursday, July 22, 2010 21:49:26 -0400 Sahil Tandon wrote: On Thu, 2010-07-22 at 16:24:22 -0500, Paul Schmehl wrote: I'm trying to update a port that I maintain, but the download is failing. Here's the actual path of the download: http://nchc.dl.sourceforge.net/projects/afterglow/files/AfterGlow%201.x/1.6/ That's the wrong path. Try: -PORTVERSION= 1.6 +PORTVERSION= 1.6.0 But the macro has SF/project/, so the download fails. Did Sourceforge just change their downloads path? SF/project/ continues to work just fine: % fetch http://heanet.dl.sourceforge.net/project/afterglow/AfterGlow%201.x/1.6.0/afte rglow-1.6.0.tar.gz afterglow-1.6.0.tar.gz100% of 72 kB 82 kBps Sorry for the noise. :-( -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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"
DEPRECATE and a master/slave port
I want to DEPRECATE security/barnyard. It's a master port. The slave is security/barnyard-sguil. Is it sufficient to DEPRECATE and EXPIRE the master? Or do I need to do that to the slave as well? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: DEPRECATE and a master/slave port
--On Friday, August 13, 2010 20:37:30 -0400 Wesley Shields wrote: On Fri, Aug 13, 2010 at 01:25:09PM -0500, Paul Schmehl wrote: I want to DEPRECATE security/barnyard. It's a master port. The slave is security/barnyard-sguil. Is it sufficient to DEPRECATE and EXPIRE the master? Or do I need to do that to the slave as well? Master should be enough. Thank you, Wesley. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: DEPRECATE and a master/slave port
--On Monday, August 16, 2010 14:09:29 -0700 Doug Barton wrote: On 8/13/2010 11:25 AM, Paul Schmehl wrote: I want to DEPRECATE security/barnyard. It's a master port. The slave is security/barnyard-sguil. Is it sufficient to DEPRECATE and EXPIRE the master? Or do I need to do that to the slave as well? The simplest and best way to answer this question is to test it. Make your changes in the master, then go into the slave port and type make. Thanks, Doug. That confirms for me that the slave port is deprecated automatically when its master port is deprecated. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: It's annoying when something other than rsyncd listens on tco/873
--On Monday, August 16, 2010 20:20:31 -0400 jhell wrote: On 08/16/2010 01:49, David Wolfskill wrote: My build machine is noisy & generates heat, so I leave it powered off when it's not actively in use. As a consequence, it gets rebooted rather often. It is configured to run rsyncd(8) so I can update my laptop's local mirror of the FreeBSD SVN repository. A couple of mornings ago, I woke up, ready to start my daily builds (on the laptop & build machine), but noticed that the SVN mirror on the laptop hadn't been updated. Eventually, I discovered that the reason was that amd(8) [on the build machine] was listening on 873/tcp, which is the port for rsync. I restarted amd(8); it happened to get other ports, so I restarted rsyncd(8), and was able to perfomr the mirroring. Mind, that was the first time since around February that I've had a problem with using rsyncd(8) in this fashion. Since then, I've become a bit ... sensitized to the issue, so a quick "sockstat -4l" immediately after powering it on helps avoid ths sort of thing. So this evening, such a check showed that ypbind(8) was listening on 873/tcp. The most straightforward way to make this a non-issue (it seems to me) would be to start rsyncd(8) before other services that grab arbitrary ports; however, the start-up script for rsyncd s[ecifies: # PROVIDE: rsyncd # REQUIRE: LOGIN # BEFORE: securelevel # KEYWORD: shutdown and both amd & ypbind specify # BEFORE: DAEMON so that approach doesn't seem to quite work out. (I note that I recently stopped tracking stable/7 on the build machine, so I now boot into stable/8; perhaps something changed between stable/7 and stable/8 that inicreases the probability of such an unfortunate collsion.) Also, rsyncd(8) doesn't appear to consider this a condition worthy of note -- at least, I wasn't able to find any whines, and the daemon was still running. Anyone have suggestions for avoiding a recurrence (vs. working around the coiindition should one occur)? I have been at this point once or twice and it always boiled down to rpcbind in my situation on a few NIS+ boxen. The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents so adding the BEFORE to the rsync start script would not help or didn't at that time. One thing that comes to mind is that script that Jeremy? posted for waiting for the network a certain period of time before initializing services. Maybe this could also play a role in a situation to have a services script that could be controlled by rc.conf(5) to wait for a service to come up before continuing its own operation. And of course it should continue no matter what in either case but would allow you to introduce possibly needed delays in the rc. Here is a slightly modified version of Jeremy's script that I use. http://bit.ly/cpbrlm The IP_PORTRANGE value, which is used by ypbind and amd to select a port, is adjustable according to your needs. man (4) ip "IP_PORTRANGE_DEFAULT use the default range of values, normally IPPORT_HIFIRSTAUTO through IPPORT_HILASTAUTO. This is adjustable through the sysctl setting: net.inet.ip.portrange.first and net.inet.ip.portrange.last." Note that the man page is incorrect for FreeBSD 8. # uname -r 8.1-PRERELEASE # sysctl net | grep portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 1 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 So set net.inet.ip.portrange.lowlast to 874. That should keep rsyncd's port from being grabbed, unless I'm misunderstanding this, in which case Matthew or someone else will correct me. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson ___ 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: Ports system quality and trolling
--On August 28, 2011 6:40:58 PM -0400 Jerry wrote: I have no problem with that. No one should be forced to update their system if they choose not to. However, to carry your statement to its logical conclusion, you should issue a warning that attempting to update your system carries dire risks since the updates have not been properly tested. For the record, users knew exactly why the were updating "ruby", they wanted to. If it was not to be used, then why release it? What they did not know was that it was going to bite them in the ass, like so many other updates (cups+gnutls) have lately. If it had been failing on a few obscure programs, then I could probably say it was an unfortunate oversight. When it starts failing on major applications used by a large number of FreeBSD users, then it should be labels what it is, incompetency. Opps, did I hurt someone's feeling? Well, you screwed up my system and wasted hours of my valuable time, so now we are even. My advice? Go find yourself a better OS and quit bitching about the one you obviously no longer like. Your complaints might be legitimate, but your tone, words and attitude stink. Ooops, did I hurt your feelings? Paul Schmehl, If it isn't already obvious, my opinions are my own and not those of my employer. ** "When intelligence argues with stupidity and bias, intelligence is bound to lose; intelligence has limits, but stupidity and bias have none." ___ 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: A maintainers question: how to create a user?
--On December 15, 2011 7:16:09 PM -0500 Aryeh Friedman
wrote:
See subject for the main question... the details: I am the maintainer of
devel/aegis and the final installation step typically (linux RPM's for
example) is to create a user to hold the baselines (in svn/cvs/csup speak
the project's repo) of the varioous projects managed by aegis...
customerly this is MUST be a non-logginable (you MUST [requirements
document meaning of upper case MUST/SHOULD/MAY {NOT}) but allow for su
from either root or via sudo a member of "wheel")... it is a standard
account in all other respects for example I typically set it to tcsh but
the port might want to make that an make time option... what is the best
way of setting this all up (both the no options and the options based
versions)
Look at USERS and GROUPS in /usr/ports/Mk/bsd.port.mk
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
___
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: How to detect the version of a installed perl module during portbuild
--On January 3, 2012 9:52:15 PM +0100 Olli Hauer wrote:
Hi,
I'm searching a solution to detect the version of p5-JSON-RPC during
build time.
JSON-RPC-1.01 is *not* backward compatible to 0.96 so I have to apply a
fix to the port only if JSON-RPC > 0.96 is installed.
From http://cpansearch.perl.org/src/DMAKI/JSON-RPC-1.01/Changes
1.00_01 2011 Nov 16
- If you are using old JSON::RPC code (up to 0.96), DO NOT EXPECT
YOUR CODE TO WORK. THIS VERSION IS BACKWARDS *INCOMPATIBLE*
...^^
This returns the installed package:
pkg_info -qa | grep "p5-JSON-RPC" | sort | uniq
so maybe you could do something like?
JSON_VER=`pkg_info -qa | grep "p5-JSON-RPC" | sort | uniq | cut -d'-' -f4`
.if ${JSON_VER} >= 1
do this
.else
do this
.endif
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
___
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: How to detect the version of a installed perl module during portbuild
--On January 4, 2012 8:59:12 AM + Matthew Seaman wrote: On 03/01/2012 23:41, Paul Schmehl wrote: This returns the installed package: pkg_info -qa | grep "p5-JSON-RPC" | sort | uniq Woah! Try it like this: pkg_info -Ex p5-JSON-RPC I bow to the master. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: linux-f10-nss_ldap: my first port - be gentle :)
--On January 5, 2012 12:22:45 PM +1000 Da Rock wrote: Ok. I've been working through the handbook step by step, and I'm stuck at checksums so I probably haven't yet reached that part yet. I'll check it out now To get the checksums, type make fetch to download the packages and then make makesum to get the checksums. This is a critical step for a port. You need to make sure the checksum matches what the site says it should be, because everyone who builds that port will be expecting that to be correct. They're counting on that checksum to ensure that they don't download a compromised copy of the software. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: linux-f10-nss_ldap: my first port - be gentle :)
--On January 9, 2012 3:55:48 PM +1000 Da Rock wrote: I just need to work out how to check the checksum against a linux source. I haven't found that yet. My brief search was unsuccessful as well. Is it really possible that the LInux community has abandoned providing checksums for RPM packages? If so, that boggles the mind. Surely they don't believe their repositories are unassailable? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: define issue - linux-f10-nss_ldap: my first port - be gentle :)
--On January 10, 2012 10:52:32 AM +1000 Da Rock
wrote:
I'm having some trouble using knobs and "defined" in the Makefile. It
keeps complaining about the unexpected.
I've tried .if defined(WITH_PAM) and .ifdefined(WITH_PAM) and it
complains about an unexpected "(" in the first, and an unexpected word in
the second.
How do I conditionally handle the knobs?
You need an if - endif for each knob. Something like this.
.if defined(WITH_PAM)
CONFIGURE_ARGS+=--with-pam
PLIST_SUB+= PAM=""
.else
CONFIGURE_ARGS+=--without-pam
PLIST_SUB+= PAM="@comment not installed: "
.endif
___
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"
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
___
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: linux-f10-nss_ldap: my first port - be gentle :)
--On January 10, 2012 10:11:15 PM +0100 Alexander Leidinger
wrote:
On Mon, 09 Jan 2012 15:55:48 +1000 Da Rock
wrote:
Now my Makefile looks like this:
# New ports collection makefile for:linux-f10-nss_ldap
# Date created: 2012-01-04
# Whom: da porta
port_maintai...@herveybayaustralia.com.au
#
# $FreeBSD$
#
PORTNAME=nss_ldap
PORTVERSION=0.01
The PORTVERSION looks a little bit off to me. I would use something
like ${NSS_LDAP_VERSION} or ${NSS_LDAP_VERSION}.${RPMVERSION} (the
later may look a little bit strange... or not) to make it easy to
compare what is installed on a system with what is available on linux.
CATEGORIES=net linux
MASTER_SITES=
ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/update
s/testing/10/i386/ \
http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/10/E
verything/i386/os/Packages/ \
http://herveybayaustralia.com.au/ports/distfiles/
I can't remember if we have the fedora archives in bsd.sites.mk (if
not, it would be worth to add it), and I'm too lazy ATM to search for
it. If we have them (and they are OK), it would be better to use the
bsd.sites.mk shortcodes for them. This would change automatically the
master sites for this port if they are changed/improved in bsd.sites.mk.
Too lazy to do this?
# grep FEDORA /usr/ports/Mk/bsd.*
/usr/ports/Mk/bsd.linux-rpm.mk:MASTER_SITES=
${MASTER_SITE_FEDORA_LINUX}
/usr/ports/Mk/bsd.sites.mk:.if !defined(IGNORE_MASTER_SITE_FEDORA_LINUX)
/usr/ports/Mk/bsd.sites.mk:MASTER_SITE_FEDORA_LINUX+= \
PKGNAMEPREFIX=linux-f10-
DISTNAME=${PORTNAME}-${NSS_LDAP_VERSION}-${RPMVERSION}
MAINTAINER=port_maintai...@herveybayaustralia.com.au
COMMENT=RFC 2307 NSS Module (Linux Fedora 10)
LICENSE=GPLv2
NSS_LDAP_VERSION=264
USE_LINUX_RPM= yes
USE_LINUX_PREFIX=yes
Hmmm... I would expect that USE_LINUX_RPM automatically sets
USE_LINUX_PREFIX... to be verified.
USE_LINUX_RPM implies the inclusion of bsd.linux-rpm.mk. bsd.linux-rpm.mk
includes USE_LINUX= yes and USE_LINUX_PREFIX= yes. So putting
USE_LINUX_PREFIX in the Makefile is redundant.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
___
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: linux-f10-nss_ldap: my first port - be gentle :)
--On January 11, 2012 10:44:11 AM +1000 Da Rock
wrote:
My last problem is with the define knobs. I have an .if defined(WITH_PAM)
.else ... .endif statement, but it keeps giving me trouble. I can't quite
figure what I've got wrong. The statement looks like this:
post-extract:
.if defined(WITH_PAM)
PLIST_FILES+=lib/security/pam_ldap.so
.else
@if [ -f ${WRKDIR}/lib/security/pam_ldap.so ]; then \
${RM} ${WRKDIR}/lib/security/pam_ldap.so
${DIRRM} ${WRKDIR}/lib/;
fi
^
This is what's wrong. In port Makefiles, it's .if, .else, .endif not fi.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
___
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: MASTER_SITE_FEDORA_LINUX in bsd.sites.mk
--On January 18, 2012 9:09:10 PM + Chris Rees wrote: I worry about the ethics of 'stealing' Fedora's bandwidth with other people's ports; we should only be using their mirrors if it's explicitly developed by Fedora. I'm not sure I follow. If Fedora is making an rpm available for download, how is it "stealing" their bandwidth to download the rpm from there? Wouldn't be equally "stealing" to download it from anywhere else? -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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"
Master Site problem
I'm trying to create a new port for a Perl module: CIF::Client. You can find it here: <http://search.cpan.org/~saxjazman/CIF-Client-0.05/lib/CIF/Client.pm> I can't figure out how to define the Master Site so this thing will download. Hopefully one of you perl cpan gurus can help. -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/infosecurity/ ___ 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: Master Site problem
--On March 27, 2012 12:04:31 PM -0500 Chris Rees wrote: On 27 March 2012 16:53, Paul Schmehl wrote: I'm trying to create a new port for a Perl module: CIF::Client. You can find it here: <http://search.cpan.org/~saxjazman/CIF-Client-0.05/lib/CIF/Client.pm> I can't figure out how to define the Master Site so this thing will download. Hopefully one of you perl cpan gurus can help. MASTER_SITES= CPAN MASTER_SITE_SUBDIR= CPAN:SAXJAZMAN/cif Thanks Chris. That did the trick. -- Paul Schmehl (pa...@utdallas.edu) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/infosecurity/ ___ 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"
Elegant way to update a port
A while ago someone posted a url to a website that explained, step by step, how to update a port using cvs and a temporary directory for the updated port. My google foo apparently isn't very good, because I can't seem to find it, and I forgot to bookmark it. Does anyone know what I'm referring to? I really like that way of updating my ports. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: Elegant way to update a port
--On January 26, 2011 8:18:18 PM +0200 Ion-Mihai Tetcu wrote: On Wed, 26 Jan 2011 10:32:51 -0600 Paul Schmehl wrote: A while ago someone posted a url to a website that explained, step by step, how to update a port using cvs and a temporary directory for the updated port. My google foo apparently isn't very good, because I can't seem to find it, and I forgot to bookmark it. Does anyone know what I'm referring to? I really like that way of updating my ports. http://ionut.tetcu.info/FreeBSD//How-to-submit-a-diff.txt Maybe this one? Yes! That was it. And thank for the wonderful resource. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: deprecated ports
--On March 16, 2011 6:15:11 AM + "b. f." wrote: That said, I think that un-deprecating these ports just because someone can find a distfile somewhere is the wrong approach. bapt has been very careful to only deprecate ports that are on the absolute bottom of the pile. They are unmaintained, and unfetchable. That's not completely accurate. Some ports were deprecated because their distfiles had been moved, sometimes to another directory on the same server, but this went unnoticed because the distfiles were mirrored locally. I think the point is that if the ports were maintained properly, those changes would not go unnoticed. For example, I maintain a port named security/chaosreader. Recently it failed to build, after which I promptly got an email notification. I quickly figured out that one of the files that needs to be downloaded had been moved to a different uri on sourceforge, updated the port and submitted a PR. That's how it's *supposed* to work. When a port become unmaintained, that doesn't happen. While it's true that some "good" ports might get caught in the sweep, the reality is that if someone was maintaining them they wouldn't get deprecated. The ports system depends on active maintainers and breaks down when maintainers are inactive. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: How are [MAINTAINER] patches handled and why aren't PRs FIFO?
--On April 28, 2011 10:52:32 PM +0200 Matthias Andree wrote: Am 28.04.2011 21:07, schrieb Chip Camden: Correct me if I'm wrong, but as I understand it committers have commit privilege for all ports. What if certain qualified port maintainers who aren't committers were nevertheless given commit access for only the leaf ports that they maintain? Wouldn't that speed up the overall process? It looks like you're asking for a technical solution to a non-technical problem. Chris Rees has posted an archive link, and my take is that we're already trying to ask such "qualified port maintainers" to become ports committers and not care too much about how fine-grained ports access is. I personally think it's a bad idea for a port maintainer to be the committer for their own ports. Getting even minor changes committed to the tree should require two independent sets of eyes. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: Deprecation campaign
--On May 1, 2011 7:34:06 AM -0400 Jerry wrote: On Sun, 1 May 2011 09:40:21 +0100 Chris Rees articulated: On 1 May 2011 08:31, "mato" wrote: > There are usually many users but only a few are ready to become maintainers (for whatever reasons). So no one stepping up does not really mean no one uses a port. But ok, I'll try to see what I can do for ports I might care about.. > They could always pay someone. You do realize that many here would consider that blasphemy. While it might be advantageous, like so many other capitalistic concepts, it is not likely to get a foothold in this galère. I think there was a greater underlying point. FreeBSD is a volunteer project. Lots of people would like to have all sorts of functionality that isn't presently available or save things that aren't maintained. Yet few want to volunteer to do the work. (In my experience that is normal human nature.) So I took Chris' response to mean, step up and take responsibility if you don't want it to go away. I became a port maintainer because there were things I needed that weren't available. Rather than asking someone else to do it, I took on the responsibility myself. That's how it's *supposed* to work. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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"
Anoncvs not working?
I'm using this command to checkout a port for updating purposes: cvs -d anon...@anoncvs1.freebsd.org:/home/ncvs co barnyard2 I'm getting access denied: # cvs -d anon...@anoncvs1.freebsd.org:/home/ncvs co barnyard2 ssh: connect to host anoncvs1.FreeBSD.org port 22: Connection refused cvs [checkout aborted]: end of file from server (consult above messages if any) Did something change? This has worked for me in the past. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ 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: mod_security2-2.1.3
--On Sunday, November 11, 2007 13:55:42 -0200 Marcelo Araujo <[EMAIL PROTECTED]> wrote: Grant Peel wrote: Hello, mod_security seems to have a problem with the MAC Safari browser using some post statements. Accoring the the developers, these problems should be fixed in 2.1.4. Are there any plans to upgrade the port anytime soon? -Grant Hey Grant, After freeze, I should work to do a upgrade on mod_security2 to new version. Thanks a lot for the reporting. Best Regards. Please be sure to add notes to UPDATING. The change to version 2 of mod_security is a dramatic change that renders older versions obsolete. Folks who are using mod_security (includes me) need to know that they will have to completely rewrite their rules to use the new syntax. (In fact, you may want to keep the older version in mod_security-1.3 or something like that to allow folks who don't want to make the change right away to continue to use the old port.) -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
--On Monday, December 03, 2007 11:38:33 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Coding before the problem is well understood is the worst of all possible solutions... specifically in many ways thats how to the port system got into such a bad state I've run just about every *nix version imaginable - a number of Linuxes (Red Hat, Fedora, Ubuntu, Gentoo, Debian, Slackware, and others) and FreeBSD, OpenBSD, Solarix, AIX, just to name a few. I've used apt-get, yum, rpm, et. al. IMNSHO the ports system is by far the best system I've ever used WRT installing/deinstalling software **and solving problems with dependencies**. I have *never* had a problem with the ports system that couldn't be easily solved by 1) reading /usr/ports/UPDATING or 2) deinstalling and reinstalling a port or ports and 3) running pkgdb -F and fixing dependency problems. I can't say the same for any of the other systems, which is why I use FreeBSD exclusively where I can (which is almost everywhere now.) Before you waste any more time, why don't you get very specific about what you think the "bad state" of the ports system is. "I don't like it" doesn't qualify nor does "ports freezes suck". Oddly enough, the ports systems works perfectly for me, with only a very occasional problem encountered. I maintain a few (8) ports myself, so I'm quite familiar with how they work as well. Perhaps your "problem" is a lack of familiarity? -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
--On Monday, December 03, 2007 13:53:06 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Have you ever attempted to install the individual ports of a mega metaport? Of course I have. And I haven't run into any problems that weren't solvable. Before you waste any more time, why don't you get very specific about what you think the "bad state" of the ports system is. "I don't like it" doesn't qualify nor does "ports freezes suck". I never asked or said any of those... the original thread was started when I asked how long the port freeze would last... others turned it into a referendum on the ports system... once the thread had been transformed I ventured some of my own ideas. The "bad state" quote is directly from you. Since you made the statement, I simply asked for some concrete examples of what you think "bad state" means. You used the term. Surely you have some idea what you meant by it? I have 4 ports awaiting inclusion in the ports tree after the freeze is over (I am willing to wait but I think the fact that there was a ports freeze in the first place points to some underlaying flaws which I cited in the original thread) What would those flaws be? You have a system that is entirely volunteer. Expecting the same performance that you get from a paid system is unrealistic. Sometimes maintainers are very busy and can't commit changes as rapidly as others would like. The solution? Submit your own patches to the port and they will most likely get approved. Sometimes committers are very busy and can't get to your port right away. The solution? Ask a different committer to take a look. Or become a committer yourself. Short of hiring professionals to do this work on a fulltime basis, what would you propose that would improve the system? According to your sig you're a developer, so I'm certain you understand what library incompatibilities are. Given that, how would you propose to not freeze ports while the base system is being prepared for release? -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
--On Monday, December 03, 2007 14:20:16 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Try this as a challenge then install xdm cleanly on the first try without having to install any additional ports from the command line (what it drags in is fine) [EMAIL PROTECTED] make deinstall distclean ===> Deinstalling for x11/xdm ===> Deinstalling xdm-1.1.6_2 pkg_delete: package 'xdm-1.1.6_2' is required by these other packages and may not be deinstalled (but I'll delete it anyway): krdesktop-1.8_5 xorg-7.3_1 xorg-apps-7.3 ===> Cleaning for xdm-1.1.6_2 ===> Deleting distfiles for xdm-1.1.6_2 [EMAIL PROTECTED] make install clean => xdm-1.1.6.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/xorg/app. => Attempting to fetch from ftp://ftp.gwdg.de/pub/x11/x.org/pub/individual/app/. xdm-1.1.6.tar.bz2 100% of 384 kB 149 kBps ===> Extracting for xdm-1.1.6_2 => MD5 Checksum OK for xorg/app/xdm-1.1.6.tar.bz2. => SHA256 Checksum OK for xorg/app/xdm-1.1.6.tar.bz2. ===> xdm-1.1.6_2 depends on file: /usr/local/sbin/pkg_info - found ===> Patching for xdm-1.1.6_2 ===> Applying FreeBSD patches for xdm-1.1.6_2 skip lots of programming stuff. install -o root -g wheel -m 555 -s chooser /usr/local/lib/X11/xdm/chooser /bin/cp -n /usr/local/share/examples/xdm/GiveConsole /usr/local/lib/X11/xdm/GiveConsole /bin/cp -n /usr/local/share/examples/xdm/TakeConsole /usr/local/lib/X11/xdm/TakeConsole /bin/cp -n /usr/local/share/examples/xdm/Xaccess /usr/local/lib/X11/xdm/Xaccess /bin/cp -n /usr/local/share/examples/xdm/Xreset /usr/local/lib/X11/xdm/Xreset /bin/cp -n /usr/local/share/examples/xdm/Xresources /usr/local/lib/X11/xdm/Xresources /bin/cp -n /usr/local/share/examples/xdm/Xservers /usr/local/lib/X11/xdm/Xservers /bin/cp -n /usr/local/share/examples/xdm/Xsession /usr/local/lib/X11/xdm/Xsession /bin/cp -n /usr/local/share/examples/xdm/Xsetup_0 /usr/local/lib/X11/xdm/Xsetup_0 /bin/cp -n /usr/local/share/examples/xdm/Xstartup /usr/local/lib/X11/xdm/Xstartup /bin/cp -n /usr/local/share/examples/xdm/Xwilling /usr/local/lib/X11/xdm/Xwilling /bin/cp -n /usr/local/share/examples/xdm/xdm-config /usr/local/lib/X11/xdm/xdm-config ===> Compressing manual pages for xdm-1.1.6_2 ===> Registering installation for xdm-1.1.6_2 ===> SECURITY REPORT: This port has installed the following files which may act as network servers and may therefore pose a remote security risk to the system. /usr/local/bin/xdm If there are vulnerabilities in these programs there may be a security risk to the system. FreeBSD makes no guarantee about the security of ports included in the Ports Collection. Please type 'make deinstall' to deinstall the port if this is a concern. ===> Cleaning for xdm-1.1.6_2 What was I supposed to find? Here's a hint that would help a *ton* of users. Don't try to install a port until your ports tree is up to date. Completely up to date - as is, run portsnap or cvs or cvsup *first*, *then* try to install your port. I have several possible solutions (contact me privately if you want more detail) but am purposely not stating them publically so as not to taint the survey any more then it needs to be. This is the part I don't get. If you have suggestions, post them. Post the code that implements your suggestions. *Then* people can evaluate whether or not your suggestions add value to the ports system. Why the silly games? As I read them, this seems to be the primary objection of all the people responding who have @freebsd.org in their email address. They've heard it all before, but they know that actions speak much louder than words. If you say "the implementation of foo is flawed", and then you post code that, IYO, improves it, people with experience and knowledge can review it and say, "Hey, nice idea" or "sorry, your code would break ports and here's why". Without the code, all the surveys and gesticulations in this tread accomplish little except to irritate people. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
--On Monday, December 03, 2007 17:15:10 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: ===> Cleaning for xdm-1.1.6_2 What was I supposed to find? Did you actually run xdm or just assume because it compiled that it was installed the same way in all cases... No, I didn't run xdm, because that wasn't the parameters of your test. You insisted it wouldn't install at all. Now you've changed the rules. In order for me to run xdm, I'd have to edit /etc/ttys and then restart X so that I'm using xdm instead of kdm. I'm not too excited about doing that given the fact that you'll most likely change the rules again, after it works successfully. hint: the visual appearance varies signficiantly depending on what method you use.XDM is no not unique in this either just off the top of my head I can name the following ports that demostrate different behaviour depending on what order the are installed: First, I find it hard to believe anyone would even bother to test this. You must have lots of time on your hands. Second, I would imagine the results would vary based on the system you have, the video card you're using and the ports you have installed. If it works, I think that's about all you can expect from ports. Ports only install and deinstall software. They don't configure it, and they don't adjust for errors in the software. gnome-office abiword boost openoffice-2 the entire set of jdk's perl (what is the difference between the 5.8.8 in the base system and the one in ports?!?!?!?) What version are you running? Perl hasn't been in the base for some time now. It's installed by default when you install FreeBSD, but it's a port. The reasons for that are far too long to go into here. these are just the ones I have found after installing 2 mega metaports and the java stuff... god knows what is lurking out there Here's a hint that would help a *ton* of users. Don't try to install a port until your ports tree is up to date. Completely up to date - as is, run portsnap or cvs or cvsup *first*, *then* try to install your port. I use the following "script" (i.e. by hand) installing a new port (might be overkill): cd /usr/ports/ cvsup /usr/share/examples/cvsup/ports-supfile (I actually use a local cvs repo but this is clearer) You don't need to cd to /usr/ports to run cvsup if you're cvsupfile was done correctly. portupgrade -a make uninstall distclean install This will certainly get you in trouble. Make uninstall in /usr/ports? What made you think that was a wise thing to do? If that doesn't guerntee upto date ports nothing will That will guarantee problems for sure. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC/P] Port System Re-Engineering
--On Monday, December 03, 2007 22:03:50 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: It was one of several examples... jesus how I wish I could post some of the private replies I got so people could see the amount of frustration out there with the current system but that would color other replies so I will wait until I don't get any new survey replies for 24 hrs then I will post a summary and verbatum the ones the orginal authors let me do this with. Well, that does it for me. You're the first person ever in this list to go into my killfile. The last thing I want is to sit here and read carping and bitching from people who think the ports system is f'd up but have no intention of getting off their butts and writing code to "fix" it. Feel free to respond. I won't see it. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: java/jdk15
--On Thursday, December 06, 2007 10:08:22 -0700 Joshua Tinnin <[EMAIL PROTECTED]> wrote: "Due to licensing restrictions, certain files must be fetched manually. "Please open http://download.java.net/tiger/ in a web browser. "Download the Update 13 Source, jdk-1_5_0_13-fcs-src-b05-jrl-25_sep_2007.jar" The source has been updated and is Update 14 now. According to the site, it was updated November 13, 2007. Getting the source from java.net won't work, and I don't think the source for update 13 is available anymore. Workaround: Download 14. Rename it 13. Install. That's what I did, and it worked fine. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HELP needed by experienced porter for simple review
--On Thursday, December 06, 2007 13:34:05 +0100 GP <[EMAIL PROTECTED]> wrote: rc.conf It's a shame that I can't use a script placed in /files to change rc.conf during install/ deinstall. I really liked that. But i guess I will settle with a dull pkg-message at the end, like the rest of you... Well, no, it's not a shame. The last thing we want to do as a community is enable all sorts of daemons that users don't know they have enabled. It's up to the owner of a box to enable a daemon **in the way** that they want it enabled. For example, *none* of the daemons on my workstation listen for connections on its IP address - only on localhost. If you enabled the daemon by default while installing the script, and I didn't have time to config it the way I wanted, and it got started (either by accident or by reboot) I would be pissed (not to mention possibly hacked.) As porters our job is to make the software available for install *not* decide how or when it will be used. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (Very) bogus package dependencies
--On December 6, 2007 10:32:51 PM -0500 Alex Goncharov
<[EMAIL PROTECTED]>, Alex Goncharov <[EMAIL PROTECTED]>
wrote:
|
| It looks like an ordinary indirect dependency.
| The drivers as well as the xorg-server all require 'hal'.
Yes:
$ pkg_info -r xf86-video-radeonhd-*
Dependency: hal-0.5.8.20070909
Dependency: xorg-server-1.4_3,1
| 'hal' depends on 'cdrtools'. (It may be that the drivers only
| depend on xorg-server,
| As for why 'hal' requires 'cdrtools' I have no idea, but there is
| probably some reason for it.
And this is precisely the second of the two questions I have in mind:
1. (Purely technical): Where is this originally recorded?
I don't see anything applicable in the port's directory:
# find /usr/ports/sysutils/hal -type f| wc -l
567
# find /usr/ports/sysutils/hal -type f -exec grep -Hn 'cdrtools' {} \;|
# wc -l
0
That's because you're not looking in the right place. Open the Makefile
for hal and you find:
USE_CDRTOOLS= yes
Now, why cdrtools is required to build the port is a question that is
answered by going to /usr/ports/Mk/bsd.port.mk and reading the section on
USE_CDRTOOLS. Then continue to trace from there, and you will find that
hal won't build without some file or files that are installed by cdrecord.
(No, I'm not going to do that for you.)
But I do see it in `/var/db/pkg':
# find /var/db/pkg/hal-0.5.8.20070909/ -type f -exec grep -Hn 'cdrtools'
# {} \;
/var/db/pkg/hal-0.5.8.20070909/+CONTENTS:187:@pkgdep cdrtools-2.01_6
/var/db/pkg/hal-0.5.8.20070909/+CONTENTS:188:@comment
DEPORIGIN:sysutils/cdrtools
So, is it that a port maintainer creates `/var/db/pkg/PKG/*' files
by hand? Based on individual ideas? Not on really "must-to-have"
things, like dependencies on shared libraries?
Absolutely not! /var/db/pkg/portname is built by the ports system based
upon how the port is built. Most maintainers (including me!) would have
no clue what's in the CONTENTS page without looking at it, because we have
"nothing" to do with its creation (other than the fact that we created the
port.)
2. (Conceptual): How reasonable are these dependencies?
I doubt seriously any port maintainer just picks dependencies willy-nilly.
They're chosen because the source code docs cite them as requirements
and/or because the port won't build without them.
In this case, `/usr/sbin/burncd' is all I need to burn CD's. I
have no practical reason to have `cdrtools' on my computer.
Of course you do. Otherwise it wouldn't be there.
Why would the "Hardware Abstraction Layer for simplifying device
access" depend on a specific set of "CD/CD-R[W] and ISO-9660 image
creation and extraction tools" -- on this set and not on another?
It most likely doesn't. It depends upon a file or files that are
installed by cdrtools.
Look at one of my ports, security/barnyard. It depends on snort. Why?
Because that's the only thing it's designed to work with. Without snort,
there's no reason to have barnyard on your system. Another port,
devel/byacc, has no dependencies at all. Another one,
security/sguil-server, has multiple dependencies, some because they're
required for proper operation, others because the port won't build without
those libraries.
If you want to spend time figuring all that out, be my guest, but the
maintainers have already done all that work for you, and the committers
have verified that it's required and that it works as expected.
That's the beauty of ports.
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (Very) bogus package dependencies
--On Friday, December 07, 2007 00:18:15 -0500 Alex Goncharov <[EMAIL PROTECTED]>, Alex Goncharov <[EMAIL PROTECTED]> wrote: I won't dispute the word "beauty" here -- I like the system very much. But coming from some eight years of using Debian, I am still mystified about the underling mechanics of ports. Your answers definitely help -- thank you! Any time you see USE_FOO= bar in a Makefile, the answer to what does that mean will be in /usr/ports/Mk/ somewhere. So grep USE_FOO in /usr/ports/Mk/* and you'll find where it appears. Then you can read the file and usually figure out what that means. You may then have to go read Makefiles for the ports to which it refers (in the case of cdrtools, cdrecord) and try to figure out why *that* port is required for "your" port to build. As maintainers, the first thing we have to do is read the requirements for the software and make sure those dependencies are built as well. So, for example, if a new port I'm working on requires that libdir is installed, I have to figure out whether it is or not, and if not, how I get it installed. Whenever possible, we try to use the port macros (USE_FOO), but if not, we have to use BUILD_DEPENDS to require that some other port is installed before ours begins the build. There are some wonderfully talented and highly knowledgeable people working behind the scenes to make sure all this stuff works in harmony, so I don't ask why, I just make sure my ports work as expected. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (Very) bogus package dependencies
--On Monday, December 10, 2007 16:33:20 +0200 Andriy Gapon <[EMAIL PROTECTED]> wrote: From a small research it seems that the only thing needed from cdrtools is isoinfo utility which gets called in FreeBSD-specific code (hald/freebsd/probing/probe-volume.c) like follows: isoinfo -p -i %s And it seems that its only usage is to detect presence of directories named 'VIDEO_TS|VCD|SVCD', so that properties like volume.disc.is_videodvd could be set. Maybe there is a way to write code for this functionality that could be included into hal source code or as a port patch, so that hal doesn't have to depend on cdrtools. While I have no objections to this particular suggestion, my question would be - where do you stop? You could easily do this for hundreds (if not thousands of ports) that depend upon some other port because of one piece of code. In general. port maintainers follow the guidelines of the software developer. If the developer states that the software depends upon cdrtools, then the maintainer is going to include that dependency in the port. Many of us don't have sufficient skill to audit code and determine where a dependency could be replaced by some additional code. So, while this might make sense in isolated cases, I don't think it scales well. Furthermore, modern machines generally have enough disc space that the addition of a few "unused" ports to include necessary code is a small price to pay to distribute the load of providing ports over a larger population of volunteers. (And yes, I know not everyone has a modern machine or large discs to work with.) -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: results of ports re-engineering survey
--On Wednesday, December 12, 2007 04:38:39 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: ..while I still want to gather more data to pin down the exact requirements Don't you get it? You're not GATHERING DATA. You're eliciting responses from a TINY percentage of the people who use FreeBSD and ports and *extrapolating* from that tiny sample that 1) something is wrong with ports and 2) something actually needs to be done about it. You haven't even BEGUN to gather data. Yet you're already moving on to your "second phase"! Furthermore, you take it upon yourself to insult the very people who actually *do* write the code and make this thing work while polluting this list (and several others as well) with stuff that *very few* (very few is defined as less than 1% of the readership which represents perhaps 1% of the total users of FreeBSD) people care about. And you wonder why others' patience grows short? Have you even noticed that the sharpest criticism of your "ideas" has all come from people with "@freebsd.org" in their email address? Do you know what it takes to get one of those? Please, please, spare us all the pain. Go write some code. Submit a PR. Then argue the validity of your code on the developer's list. You're already in my killfile. I'm about to put you in /dev/null. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem to reach a maintainer
--On Thursday, December 13, 2007 10:17:43 -0500 [EMAIL PROTECTED] wrote: Dear I try to send a bug report to: [EMAIL PROTECTED] for tclhttpd-3.5.1_2 but ÉI got this error VotreFreeBSD Port: tclhttpd-3.5.1_2 document : n'a pas été [EMAIL PROTECTED] distribué à : Motif : Router: Failed to connect to SMTP host ALDAN.ALGEBRA.COM because : The server is not responding. The server may be down or you may be experiencing network problems. Contact your system administrator if this problem persists. Dig shows a resolvable host and dig -t MX shows a correctly configured MTA. Try again. It's likely exactly what the error message says - network problems or the server was down. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ion3 removal (Re: Ion3 license violation)
--On Thursday, December 13, 2007 10:17:16 + Tuomo Valkonen <[EMAIL PROTECTED]> wrote: On 2007-12-13, Mark Linimon <[EMAIL PROTECTED]> wrote: On Thu, Dec 13, 2007 at 08:30:06AM +, Tuomo Valkonen wrote: The copyright holder reserves the right to refine the definition of significant changes on a per-case basis. In other words, a moving target -- which implies, to me, that to be legally in the clear, that we would first have to vet every possible change or modification, including patches. Notice the "a priori": it means you're allowed to do that without legal threat until further notice to the contrary. ^^^ Geez, IANAL, nor do I have a dog in this fight, but if *you* can't see that the underlined phrase places the object of the clause in constant and persistent legal jeopardy, then perhaps *you* need to hire a lawyer. Let me see if I can boil this down to simple English. The license is what is is, unless and until I say it's not. Therefore, you can use it, for now, but you need to pay close attention because I might change it at some point in the future and *then* you will be liable. Yeah, I'm going to sign up for that one. While watching this thread, I at first thought the decision to remove your software was a bit arbitrary. You have convinced me otherwise. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
--On Friday, December 14, 2007 12:19:06 + RW <[EMAIL PROTECTED]> wrote: On Thu, 13 Dec 2007 22:34:58 -0500 "Aryeh M. Friedman" <[EMAIL PROTECTED]> wrote: Namely if I build abc with options 123 and 345 and def with 345 and 678 then 345 will be cached for def since we already set it for abc. How do you know the user wants 345 set on both ports? It might be a useful stable feature on "abc", but causes lock-ups on "def" SInce I've already killfiled Aryeh, I can only infer what you are responding to and respond to him. But let me state this emphatically in the hopes it will get through his thick skull. IT IS NOT THE JOB OF PORTS TO MAKE DECISIONS FOR USERS. Please repeat that one hundred times until it gets through. No port should *ever* make decisions on a users behalf. Suggestions, yes (e.g. OPTIONS that are enabled by default.) Decisions, no. If you depend on another port *and* on certain knobs in that dependency being enabled, then *tell* the user that during your port's install and let them decide how to handle it. DO NOT enable those knobs yourself, no matter how tempting it may be. It is beyond impossible for anyone to know what every user who is installing ports already has on their boxes or what they might want to add or ***what you might break***. Once you begin making decisions for them, you could well stomp all over something that was functioning perfectly normally and break a critical box. DON'T DO IT. That is so Microsoftian it's not funny. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
--On December 14, 2007 5:21:02 PM -0800 Brian <[EMAIL PROTECTED]> wrote: Information does indeed need to be gathered, and while even the ports list will only grab a small percentage of FreeBSD users, other options would likely grab a lot less. Plus, most of the users here are knowledgeable enough to give decent input. For those of you that don't like change may I suggest the book that led to http://www.whomovedmycheese.com/. It is really in all of our best interest to have the product evolve, the alternative is much worse. This really is getting quite irritating. Not one person on this list has *ever* said they don't want to entertain new ideas for ports. Not one person on this list has said they don't like change. *All* of the complaints have been along the lines of "go write some code and stop filling up this list with posts". And that is *precisely* the point. Yet the proponents of the Aryeh bandwagon keep throwing up this straw man that those of us who have tired of the useless back and forth are refusing to listen and uninterested in change, when *nothing* could be further from the truth. ports@ is *not* a development list. Its purpose is to provide news about ports, discuss problems with ports, get advice on porting and so forth. Or, to quote its charter, "Discussions concerning FreeBSD's “ports collection” (/usr/ports), ports infrastructure, and general ports coordination efforts. This is a technical mailing list for which strictly technical content is expected." Get that? "Strictly technical". "How do you feel about the present design" or "what don't you like about the present design" or "if you could change something about ports, what would it be" are *not* appropriate discussions for this list. It's time to move this "discussion" to some place where those that *care* about coding and/or redesigning the ports system can participate and discuss code and return this list to its original purpose. The only FreeBSD list that would be appropriate (if that - it's not really) would be arch, which is for architecture and design discussions. This thread is a design discussion and does not belong here. Please move it to a more appropriate place and leave this list alone. Ask the FreeBSD maintainers to create a new list "ports-design@" if you like, but please stop the discussions here. They are inappropriate for this list. And stop lying about the motivations of the many talented people who have asked, politely and otherwise, to stop. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Limitations of Ports System
--On December 14, 2007 7:51:14 PM -0500 Garance A Drosehn <[EMAIL PROTECTED]> wrote: At 10:08 AM -0600 12/14/07, Paul Schmehl wrote: SInce I've already killfiled Aryeh, I guess we should all killfile you, too. Be my guest. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mailer question #2
--On December 17, 2007 11:28:30 PM -0500 Chuck Robey <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, assuming that I can't get enigmail-seamonkey fixed up, I was wondering if I could get a recommendation about a mailer. This following is my list of requirements, so please don't lets open up a mailer free-for-all (I like the ACME mailer!) unless it has what I'm after, ok? Seeing as I initially liked Seamonkey, it should surprise noone that I want a graphical UI (no ascii interface, please, I don't care how much you like it) and it works with the latest version of the gnupg port (version 2.04) and not the older gnupg1 port, so I can use my present keys to sign/encrypt stuff. Lastly, I has to allow for an imap interface to the mail. That's all: GUI, GNUpg-2.04, and IMAPv4 mail/mulberry The best MUA I've ever used, and it meets all three of your requirements easily. The one complaint users consistently have (but not me!) about it is that it doesn't "do" HTML email (meaning that it won't display the images inline and won't run scripts.) It's the geek's email client, loaded with useful features such as a single "new mail" folder that displays *all* new mail regardless of account or folder (so you seldom have to expand your account folders), multiple identities, the ability to "lock" accounts to specific signatures, identities and smtp servers so replies are "automatically" correct, unlimited accounts with no sharing of inboxes or other folders, effortless handling of both POP and IMAP4 regardless of folder size and/or message size, and, well, I could go on and on but I won't. Mulberry *was* closed source but is now open source and is actively developed. It handles iCal, WebDav Cal, IMSP, ACAP and LDAP addressbooks and several other protocols including Sieve filtering. I use it to access Exchange (IMAP), Cyrus IMAP, Courier IMAP and two different POP accounts. You might love it. You might hate it. But you should definitely try it. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Optional patching
Is there a way to include a patch as an option to a port? I maintain the security/barnyard port. There's a patch that is necessary for barnyard to work correctly on a 64bit system. I'm wondering if I can use OPTIONS to make this patch optional if the system is 64 bit, but I'm not sure what the syntax would be inside the if statement. .if defined(WITH_64BIT) do-patch: patchname .endif I assume the patch would have to be in the filesdir but could not be named "patch-foo" or it would always be applied, correct? -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Optional patching
--On Wednesday, December 19, 2007 16:59:37 +0100 Pietro Cerutti <[EMAIL PROTECTED]>
wrote:
Paul Schmehl wrote:
Is there a way to include a patch as an option to a port? I maintain
the security/barnyard port. There's a patch that is necessary for
barnyard to work correctly on a 64bit system. I'm wondering if I can
use OPTIONS to make this patch optional if the system is 64 bit, but I'm
not sure what the syntax would be inside the if statement.
.if defined(WITH_64BIT)
do-patch: patchname
.endif
I would do something like (please check the list of 64 bits platforms)
.if ${ARCH} == "amd64" || ${ARCH} == "ia64" || ${ARCH} == "sparc64"
# apply the patch here
.endif
I assume the patch would have to be in the filesdir but could not be
named "patch-foo" or it would always be applied, correct?
Please check the reply from pav@ for this ;-)
That brings up an interesting question. Which would be the preferred method?
To use an OPTION knob? Or simply apply the patch if the arch matches? I'm
thinking the latter. I've tested the former method, and it works fine. Does
it matter which method I use?
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Optional patching
--On Wednesday, December 19, 2007 15:53:40 -0500 Wesley Shields
<[EMAIL PROTECTED]> wrote:
On Wed, Dec 19, 2007 at 08:13:16PM +, RW wrote:
On Wed, 19 Dec 2007 14:13:06 -0500
Wesley Shields <[EMAIL PROTECTED]> wrote:
> I don't think it matters really, but is probably a matter of personal
> preference. The only problem with using an option that I see is that
> if the user has no idea if (s)he is on a 64bit platform and turns the
> option off. It's for this reason I'd suggest using the .if ${ARCH}
> approach.
I would have thought that the ".if ${ARCH}" method was the only
sensible way of doing it. Packages are built without any options set.
They are built using the default OPTIONS in the Makefile - ie: those
that are specified as "on". If what you say is true then one of my
ports would not build properly - it requires at least one of a few
options to be on.
Another reason not to put it in as an OPTION is that if the option
defaults to off the package will fail to build on 64bit platforms.
I completely agree. I just submitted a PR to update the port using .if ${ARCH}
==
Selecting the correct architechture should not be something the user has to do
when installing a port.
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [RFC] Automated generation of /etc/resolv.conf from the rc.d script
--On Thursday, December 20, 2007 16:44:59 + Roy Marples <[EMAIL PROTECTED]> wrote: On another note, what is the preferred means of getting something into ports? I also have dhcpcd [1] and a ports Makefile for it (dhcpcd is a DHCP client) 1) Create the port [1] 2) Submit it to the ports group [2] Thanks Roy PS - not currently subscribed to ports@ - should I be for this discussion? You should if you're going to be a port maintainer. [1] <http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/> [2] <http://www.freebsd.org/send-pr.html> or man (1) send-pr -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Opinion on cross-port OPTIONS CONFLICTS
--On December 22, 2007 12:07:45 AM +0100 Danny Pansters <[EMAIL PROTECTED]> wrote: I like the idea to do something with options. Optionifying ports is all nice and well, but to make it meaningful, ports should be able to know about each other's options. I actually have been working a bit on a proposal that was similar (it remained in brainstorm phase though ;-). How about e.g. LIB_DEPENDS=artsdsp:/usr/portss/[EMAIL PROTECTED] to squash two flies at once. Another way to address this would be to create a fourth "tuple". Right now the convention is file:portdir:target. Why not have file:portdir:target:option. The problem with this whole subject is, what do you do if a port depends on another port *and* requires that _more_than_one_option be true? My idea doesn't solve that *unless* you allow a comma separated list or something similar. I think, if you're going to make ports OPTIONS aware, you *must* be able to both determine if a port is already installed with or without the option *and* install it with the necessary options if it's not already installed. The idea being that if the port is not installed it yet, it could be built with make WITHOUT_NAS=1 automagically. Something like this is more pressing when you need to have a non-default option set in a port you depend on. However, you should be very careful to not decide things on the users behalf in a port. Consistancy, pola, all that... OTOH, if you can't build your port without a dependency including an option, why not mark the port as BROKEN unless the correct file is in place? The first tuple already checks for that, right? So, instead of checking for the default file, check for something the OPTION would install. So: LIB_DEPENDS=ldap.so:net/openldap for without the OPTION or LIB_DEPENDS=ldapfoo.so:net/openldap for with the OPTION That doesn't solve *installing* the dependency correctly without some other construct such as the fourth tuple though. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updating 'mail/freepops' port
--On December 23, 2007 7:04:08 AM -0500 Gerard <[EMAIL PROTECTED]> wrote: Seriously though, the only thing I have written are a few bash scripts. I guess I could attempt to work on this though. I'll download the Porters Hand book and start from there. Just a suggestion. It occurred to me that having a compressed copy of the Porters Hand book for downloading would be a good idea. I just checked, and it is something like 150 pages or so to download and print out. If you keep your docs up to date, it's already on your harddrive. /usr/doc/en_US.ISO8859-1/books/porters-handbook BTW, who do I contact if (when) I need assistance? This list. Someone will help you. Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (Very) bogus package dependencies
--On December 24, 2007 4:23:15 PM +0200 Andriy Gapon <[EMAIL PROTECTED]> wrote: And a practical thought: it seems that in recent FreeBSD versions system tar can work rather well with the ISO CD9660 FS, so it should be enough to list directories in an image. What I am trying to say: before adding a dependency examine your options and choose the best one. In principle that is good practice, but how many port maintainers are knowledgeable enough of programming to make those choices? I suspect quite a few are but not all. I'm certainly not. Perhaps this is an issue that the committers would be more suited to address? (I get the impression that most, if not all, of them are programmers or at least very knowledgeable of programming.) Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Suggested improvements for ports
Some of this has been discussed ad infinitum, but, in an off-list conversation,
I came up with this list of suggested improvements for port. I'd like to see
these things done, but I'm not sure how. Improve the docs? Create a checklist?
1) You can't build a dependent port and first set the config for the options
that you want. So, when you select sasl in postfix, you never get the chance
to check the saslauthd option, for example.
2) There's no standard for some of the details of port building. So, it's
entirely up to the port maintainer and the committer to decide how to build the
port. The postfix port maintainer *could* include a dependency for saslauthd.
He chose not to. He *could* include a note in pkg-message that warns you that
saslauthd needs to be installed as well. He chose not to. His choices are
both reasonable and customary, but they don't serve the customer well.
3) There's no standard for the format of pkg-plist, pkg-message or pkg-descr,
so port maintainers are free to put whatever they want in there. There's a
customary way of doing it, but it's not set in stone and variations are found
throughout ports.
4) There's no standard for config files. Do you overwrite? Do you ignore? Do
you create port.conf-sample? port.conf-dist? port.conf-example? Do you check
to see if port.conf is there, and, if not, copy it to ${LOCALBASE}/etc?
${PREFIX}/etc?
5) There's no standard for pkg-plist. When is it required? When is it not?
(IOW, what's the maximum number of files you can put in Makefile so you don't
have to create a pkg-plist? Do you use unexec always? Or only when you
want/decide to? Do you just ignore the conf file and not uninstall it?
I don't know the right answer to these questions, but I think they need to be
answered. I'm willing to volunteer to do some work if someone will tell me
what that work is. Docs? A committee?
Suggestions welcomed.
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
--On Friday, January 11, 2008 10:34:15 -0600 Scot Hetzel <[EMAIL PROTECTED]>
wrote:
n 1/11/08, Paul Schmehl <[EMAIL PROTECTED]> wrote:
Some of this has been discussed ad infinitum, but, in an off-list
conversation, I came up with this list of suggested improvements for port.
I'd like to see these things done, but I'm not sure how. Improve the docs?
Create a checklist?
:
3) There's no standard for the format of pkg-plist, pkg-message or pkg-descr,
so port maintainers are free to put whatever they want in there. There's a
customary way of doing it, but it's not set in stone and variations are found
throughout ports.
There is a standard format for pkg-plist. Which is documented in the
port's handbook.
Is there a description of when to use unexec and when not to? Is there an
explanation of what to do with conf files? (Do you leave them alone? Compare
them to the sample file and delete only if they're the same? Delete always?)
What's the limit on the number of files you can put in PLIST_FILES?
Directories in PLIST_DIRS? Is there any requirement to use pkg-plist?
When do you use @dirrm as opposed to @dirrmtry? How are conditionals handled
in pkg-plist?
pkg-descr does have a standard format:
WWW:
What content goes in pkg-descr? Is it required? Optional? Is WWW: required?
Optional?
pkg-message format is left to the maintainer.
The only requirement for pkg-descr and pkg-message is that it should
be able to display on an 80 column screen without the lines wrapping.
Yes, but is it required? Not required? What content goes in it? These are
all questions left to the maintainer, and a brief analysis of ports shows a
great deal of inconsistency in their usage. Many ports have no pkg-message at
all. Is it optional? If an OPTION must be set on a dependency port, are you
required to mention that in pkg-message? What information is required? What
is optional?
4) There's no standard for config files. Do you overwrite? Do you ignore?
Do you create port.conf-sample? port.conf-dist? port.conf-example? Do you
check to see if port.conf is there, and, if not, copy it to ${LOCALBASE}/etc?
${PREFIX}/etc?
There is a standard for config files, and is documented in the porters
handbook.
The port maintainer should install configuration files so that they
don't overwrite existing configuration files.
And name them now? -sample? -dist? -example? -orig? And what about
removal? When you deinstall the port, do you remove the conf file? Remove
only if it's unaltered? Ignore it entirely?
The way that most ports take is by patching the src to install the
standard config files with an extension (currently we use -sample,
-dist, -orig, or -example). Then the port should check for the
existance of the config file, and install one if it doesn't exist.
When the port is uninstalled, it compares the config file with the
default config file, and only removes the config file if they are the
same.
NOTE: should standardize a default extension.
Precisely.
When there are a large number of configuration files, a few ports
install the default configuration files into an alternate directory
(i.e PREFIX/share/example/), and then copy them to
PREFIX/etc when they don't exist. On deinstall, they compare the
config file with the default config file, and only remove the config
files if they are the same.
Is this how it should always be done?
This is my point. On many of these criteria there is an uncomfortable amount
of "squishyness" so that port maintainers, *especially* new ones, are unsure
what the "right" thing to do is. The porters handbook seems written from the
standpoint of a guide more than a manual. IOW, it advises rather than
instructs. I think that needs to change, because it would bring more
consistency to bear on ports and eliminate some of the questions that get
repeatedly asked because folks are unsure of the answer.
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggested improvements for ports
--On Friday, January 11, 2008 12:23:31 -0600 Mark Linimon <[EMAIL PROTECTED]> wrote: On Fri, Jan 11, 2008 at 11:10:45AM -0600, Paul Schmehl wrote: The porters handbook seems written from the standpoint of a guide more than a manual. That's something that I was going to work on, um, last year :-) We need both. Right now we have this hybrid which isn't a completely satisfactory solution for either one. This is historical; it kind of grew out of an initial short how-to document, then, as new things were stuffed into the ports infrastructure, there was no better place to document them. The "quick porting" text should turn into a "guide"; the "slow porting" text should become the reference. I like this idea. The problem for new porters is that a brief skim of the "how to" leaves out a lot of details that become important once you actually start creating that first port. Perhaps the right way to approach this is a guide that links to a reference doc? The guide covers the basic "rules" (if you're going to do this, do it this way, if you're not going to do that, you need to do this instead) and then the reference provides both links and examples to show how something is done. I agree we shouldn't formalize it too much, but I *do* think some things should be standardized. For example, the default conf file should have a standardized name throughout, either -sample or -dist or -example or something, and that should be followed throughout. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
