Re: bsd.licenses.mk: where is or any later version construct?
Alberto Villa wrote: On Thursday 10 June 2010 17:39:52 Anonymous wrote: IANAL, but I think LGPL3 is applicable here, too. So, I've tried to set LICENSE= LGPL21+ but it doesn't work. I've figured this will work LICENSE= LGPL21 LGPL3 LICENSE_COMB= dual Is this correct usage or I'm missing smth? that's what you're supposed to do, as far as i understand This doesn't seem right: LGPL21 or any later version is very different from LGPL21 or LGPL3. Also, how should one describe the difference between a GPL3 and a GPL3 or any later version licence? There might not be a newer version right now, but there will be in the future and it would be rather annoying if we'd have to check all the software licences again when this version is released. We'd then have to change the licence registration for each such port, even though neither the software nor its licence text has changed - but only because of limitations of our framework. Since this is a very common practice with GPL and LGPL licences, imho it seems sensible to make this distinction right from the start and use different keywords for software with/without the or any later version clause. Regards, Johan pgpy9I2ra2YbF.pgp Description: PGP signature
Re: amavisd-new does not compile because of db42
Gabor Kovesdan wrote: ===Running ldconfig /sbin/ldconfig -m /usr/local/lib ===Registering installation for db42-4.2.52_5 ===Returning to build of amavisd-new-2.6.4_6,1 Error: shared library db-4.2.2 does not exist *** Error code 1 Stop in /usr/ports/security/amavisd-new. *** Error code 1 It seems that it cannot find the library but amavisd-new uses the USE_BDB know from bsd.databases.mk just like quite a bunch of other ports, so the dependency definition is obviously correct. I don't know what causes this error and I haven't got any more PRs from other users. Soon, I'll bump the required version again because after the last change I got some mails that say newer versions operate even better with amavisd-new. I'll just talk to the developer to see, which version would be the optimal one or we can just pull in the latest bdb version. I'd say let's wait for that update and hopefully that will also solve your problem. # make clean === Cleaning for amavisd-new-2.6.4_6,1 # env make depends === amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - found [...] # env make depends -DWITH_RAR === amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - not found [...] # I then commented out IA32_BINARY_PORT=yes from the WITH_RAR section in the Makefile and guess what?! :) # env make depends -DWITH_RAR === amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - found [...] # portupgrade -N amavisd-new\* [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 224 packages found (-0 +1) . done] [Gathering depends for security/amavisd-new .. done] --- Installing 'amavisd-new-2.6.4_6,1' from a port (security/amavisd-new) --- Building '/usr/ports/security/amavisd-new' with make flags: -DWITH_BDB -DWITH_SNMP -DWITH_POF -DWITH_RAR -DWITH_UNRAR -DWITH_UNARJ -DWITH_NOMARCH -DWITH_UNZOO -DWITH_TNEF === Cleaning for amavisd-new-2.6.4_6,1 cd /usr/ports/security/amavisd-new make config; [...] === amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - found [...] # Does that help? :) -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn ___ 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
Data files and ports
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. Thanks. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Thanks. Hi Jesse, Welcome to the fray, and I'm glad to hear that you're learning how to develop FreeBSD ports! To answer your question - your port Makefile can download multiple distribution files from the upstream download site. For a couple of examples, see these Makefiles: #1 - www/zend-framework: http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/zend-framework/Makefile?rev=1.48;content-type=text%2Fplain Note the DISTFILES value and how it is affected by setting NOPORTDOCS. You can show the different values like so: cd /usr/ports/www/zend-framework make -V DISTFILES make NOPORTDOCS=yes -V DISTFILES The ZF port is a little different than yours because the distribution files do change at each release, but the idea is the same. #2 - lang/gcc45: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/gcc45/Makefile?rev=1.444;content-type=text%2Fplain This example is somewhat more complicated. I recently worked with gerald@ to include support for the GNU Java Compiler (gcj) in the gcc45 port. Search for WITHOUT_JAVA in the file, and you can see some use of additional distribution files, including the use of tagging (http://www.freebsd.org/doc/en/books/porters-handbook/makefile-distfiles.html#PORTING-MASTER-SITES-N) and preventing some distribution files from being automatically extracted. If you have any further questions about your new port or the examples above, please post back to the list. Hope that helps, Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMEkWK0sRouByUApARAi2RAJ9BsjY6G/uCNpjo5Hb3hMr0my+18gCgzO/N 1zbqQjs5FbBshIvSnYboHn0= =RUVI -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Data files and ports
On Fri, 11 Jun 2010 10:58:50 -0300 Jesse Smith jessefrgsm...@yahoo.ca wrote: 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? I think it depends on how the data is versioned. If it has a version number in the filename that's the same as the executable, then a single port is best. If they have separate version numbers, then go with two ports. If the data is not versioned at all, it might be best to create a data port that uses a snapshot that you host separately. ___ 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 Fri, Jun 11, 2010 at 10:17:46AM -0400, Greg Larkin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Thanks. Hi Jesse, Welcome to the fray, and I'm glad to hear that you're learning how to develop FreeBSD ports! To answer your question - your port Makefile can download multiple distribution files from the upstream download site. For a couple of examples, see these Makefiles: [snip] All good points, and good examples. However... :) Well, I do believe that if the Data package rarely changes, then it would be unnecessary not only to distribute it each time as a port's source distfile, but also to include it (unchanged) in different releases of the *packages* that the port builds. Thus, IMHO it would be best to make a separate port for the data file and have the main program (port) depend on it. This would make sure that not only people who build the port by hand do not download the data file more often than necessary, but also the people who use packages do not download needlessly big packages for each program update with no data change. Hope that came out clear enough; I know I'm not thinking straight today. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 signature.asc Description: Digital signature
Re: Data files and ports
--On Friday, June 11, 2010 10:58:50 -0300 Jesse Smith jessefrgsm...@yahoo.ca 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
Re: amavisd-new does not compile because of db42
On Fri, Jun 11, 2010 at 4:08 AM, Helmut Schneider jumpe...@gmx.de wrote:
Gabor Kovesdan wrote:
=== Running ldconfig
/sbin/ldconfig -m /usr/local/lib
=== Registering installation for db42-4.2.52_5
=== Returning to build of amavisd-new-2.6.4_6,1
Error: shared library db-4.2.2 does not exist
*** Error code 1
Stop in /usr/ports/security/amavisd-new.
*** Error code 1
It seems that it cannot find the library but amavisd-new uses the
USE_BDB know from bsd.databases.mk just like quite a bunch of other
ports, so the dependency definition is obviously correct. I don't
know what causes this error and I haven't got any more PRs from other
users. Soon, I'll bump the required version again because after the
last change I got some mails that say newer versions operate even
better with amavisd-new. I'll just talk to the developer to see,
which version would be the optimal one or we can just pull in the
latest bdb version. I'd say let's wait for that update and hopefully
that will also solve your problem.
# make clean
=== Cleaning for amavisd-new-2.6.4_6,1
# env make depends
=== amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - found
[...]
# env make depends -DWITH_RAR
=== amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - not
found
[...]
#
I then commented out IA32_BINARY_PORT=yes from the WITH_RAR section
in the Makefile and guess what?! :)
# env make depends -DWITH_RAR
=== amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - found
[...]
# portupgrade -N amavisd-new\*
[Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 224
packages found (-0 +1) . done]
[Gathering depends for security/amavisd-new
.. done]
--- Installing 'amavisd-new-2.6.4_6,1' from a port
(security/amavisd-new)
--- Building '/usr/ports/security/amavisd-new' with make flags:
-DWITH_BDB -DWITH_SNMP -DWITH_POF -DWITH_RAR -DWITH_UNRAR -DWITH_UNARJ
-DWITH_NOMARCH -DWITH_UNZOO -DWITH_TNEF
=== Cleaning for amavisd-new-2.6.4_6,1
cd /usr/ports/security/amavisd-new make config;
[...]
=== amavisd-new-2.6.4_6,1 depends on shared library: db-4.2.2 - found
[...]
#
Does that help? :)
The use as defined in bsd.port.mk for the IA32_BINARY_PORT variable is
incorrectly being used in the amavisd-new port:
# IA32_BINARY_PORT
# - Set this instead of ONLY_FOR_ARCHS if the
given port
# fetches and installs compiled i386 binaries.
When this variable is set it changes how ldconfig searches for
libraries by setting the -32 to ldconfig. This prevents the port from
properly detecting any 64bit libraries and only looks for 32bit
libraries. The reason that only db42 is being affected is because
most of the ports dependancies are RUN_DEPENDS.
The correct way to the amavisd-new port would be to change this:
.if defined(WITH_RAR)
IA32_BINARY_PORT= yes
RUN_DEPENDS+= ${LOCALBASE}/bin/rar:${PORTSDIR}/archivers/rar
.endif
To this:
.if defined(WITH_RAR)
# support for archivers/rar is broken on ia64
.if ${ARCH} ==i386 || ${ARCH} == amd64
RUN_DEPENDS+= ${LOCALBASE}/bin/rar:${PORTSDIR}/archivers/rar
.else
IGNORE= archviers/rar is a 32-bit binary port and is not compatible with ${ARCH}
.endif
.endif
Note: This may need to be moved after the bsd.port.pre.mk.
Scot
___
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
portmaster: problem with --packages-build?
hi doug and list! while upgrading libogg and libao (portmaster -x virtualbox -Rr libogg libao) i've seen that some ports, which were already installed, got reinstalled with a package. they're build dependencies of a port which was upgraded, but they're also run dependencies of another one, so they should be built from sources, given my portmaster.rc: ALWAYS_SCRUB_DISTFILES=dopt LOCAL_PACKAGEDIR=/usr/ports/packages MAKE_PACKAGE=gopt PM_DEL_BUILD_ONLY=pm_dbo PM_INDEX=pm_index PM_PACKAGES_BUILD=pmp_build maybe they will also be deinstalled at the end, along with other build dependencies... i'll see and report -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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
deskutils/alexandria - why does it create a world readable and writable directory?
Hei, I just found deskutils/alexandria (0.6.5_3) and installed it. A very nice program. I have just one question: why does it create a directory (~/.alexandria) with 777 permissions? Wouldn't it be more correct to use something like 740 or even 750? Note: all subdirectories of said directory have 755 permissions too. -- Regards, Torfinn Ingolfsen ___ 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
-Original Message- From: Peter Pentchev r...@ringlet.net To: Greg Larkin glar...@freebsd.org Cc: Jesse Smith jessefrgsm...@yahoo.ca, freebsd-ports freebsd-ports@FreeBSD.org Subject: Re: Data files and ports Date: Fri, 11 Jun 2010 17:41:45 +0300 On Fri, Jun 11, 2010 at 10:17:46AM -0400, Greg Larkin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. Thanks. Hi Jesse, Welcome to the fray, and I'm glad to hear that you're learning how to develop FreeBSD ports! To answer your question - your port Makefile can download multiple distribution files from the upstream download site. For a couple of examples, see these Makefiles: [snip] All good points, and good examples. However... :) Well, I do believe that if the Data package rarely changes, then it would be unnecessary not only to distribute it each time as a port's source distfile, but also to include it (unchanged) in different releases of the *packages* that the port builds. Thus, IMHO it would be best to make a separate port for the data file and have the main program (port) depend on it. This would make sure that not only people who build the port by hand do not download the data file more often than necessary, but also the people who use packages do not download needlessly big packages for each program update with no data change. Hope that came out clear enough; I know I'm not thinking straight today. G'luck, Peter --- Thanks to everyone who replied. There were some good points made all around. Let's say that I do decide to go with the idea of making the Data files a separate port. How do I tell the Ports system not to try to build the data file and instead just install the files to a location of my choosing? Usually a project's Makefile decides what gets built and where items go, but data packages are... dumb, they're just files. My thought is to create a patch which adds a Makefile to the work directory after the archive is untarred, which would handle the make and make install commands. Would that be an acceptable practise? Jesse ___ 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
qt4-moc link failure
FYI, I'm using gcc 4.5.1, the binutils port, and I did reinstall libtool after gcc. I'm on -current from April (r207134), and rebuilding qmake worked fine. However the next qt4 port in line is qt4-moc, and it fails: g++ -Wl,-rpath-link,/usr/local/tmp/usr/local/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.6.3/lib -pthread -Wl,-rpath,/usr/local/lib/qt4 -Wl,-rpath,/usr/local/lib/qt4 -o ../../../bin/moc-qt4 debug-shared/moc.o debug-shared/preprocessor.o debug-shared/generator.o debug-shared/parser.o debug-shared/token.o debug-shared/main.o-L/usr/local/lib/qt4 -L/usr/local/lib -L/usr/local/tmp/usr/local/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.6.3/src/tools/bootstrap -lbootstrap -L/usr/local/lib/qt4 -L/usr/local/lib -lz local symbol 0: discarded in section `.text._Z7qt_noopv' from debug-shared/preprocessor.o ... local symbol 1554: discarded in section `.text._ZN5QListI10QByteArrayE9node_copyEPNS1_4NodeES3_S3_' from /usr/local/tmp/usr/local/ports/devel/qt4-moc/work/qt-everywhere-opensource-src-4.6.3/src/tools/bootstrap/libbootstrap.a(qsimplecodec.o) *** Error code 1 1 error Full log is at http://people.freebsd.org/~dougb/qt4-moc.log -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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 Fri, 11 Jun 2010 16:29:18 -0300Fri, 11 Jun 2010 17:41:45 +0300, Jesse Smith wrote: Thanks to everyone who replied. There were some good points made all around. Let's say that I do decide to go with the idea of making the Data files a separate port. How do I tell the Ports system not to try to build the data file and instead just install the files to a location of my choosing? Usually a project's Makefile decides what gets built and where items go, but data packages are... dumb, they're just files. My thought is to create a patch which adds a Makefile to the work directory after the archive is untarred, which would handle the make and make install commands. from bsd.port.mk: # NO_BUILD - Use a dummy (do-nothing) build target. # NO_INSTALL- Use a dummy (do-nothing) install target. COPYTREE_SHARE macro which copies the directory entire with its subtree and sets correct permissions can be useful for your port as well. Max ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: php5-mysqli-5.3.2_1
Dear php5-mysqli port Maintainer, I don't know whether you are aware of this .. and in case you are not - I'd like to report that I cannot compile php5-mysqli-5.3.2_1 with the most recent portsnap fetch update on my FreeBSD box. If I choose mysqli extension and want to compile the php5-extension port, I get the following: [r...@php53 /usr/ports/lang/php5-extensions]# make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Found saved configuration for php5-extensions-1.4 === Extracting for php5-extensions-1.4 === Patching for php5-extensions-1.4 === php5-extensions-1.4 depends on file: /usr/local/include/php/main/php.h - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/bz2.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/curl.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/dom.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/fileinfo.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/ftp.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/iconv.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/imap.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/json.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/ldap.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/mbstring.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/mysql.so - found === php5-extensions-1.4 depends on file: /usr/local/lib/php/20090626/mysqli.so - not found ===Verifying install for /usr/local/lib/php/20090626/mysqli.so in /usr/ports/databases/php5-mysqli === Patching for php5-mysqli-5.3.2_1 === Applying FreeBSD patches for php5-mysqli-5.3.2_1 1 out of 1 hunks failed--saving rejects to mysqli.c.rej = Patch patch-mysqli.c failed to apply cleanly. *** Error code 1 Stop in /usr/ports/databases/php5-mysqli. *** Error code 1 Stop in /usr/ports/lang/php5-extensions. *** Error code 1 Stop in /usr/ports/lang/php5-extensions. # uname -a FreeBSD php53 6.2-RELEASE-p12 FreeBSD 6.2-RELEASE-p12 #0: Sat Nov 29 06:44:51 CET 2008 r...@d04.tronix.com.pl:/usr/obj/usr/src/sys/DEDYK_XEON amd64 Hope you can fix it. Thank you and best regards Norbert Neubauer ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: problem with --packages-build?
On 06/11/10 10:52, Alberto Villa wrote: hi doug and list! while upgrading libogg and libao (portmaster -x virtualbox -Rr libogg libao) i've seen that some ports, which were already installed, got reinstalled with a package. they're build dependencies of a port which was upgraded, but they're also run dependencies of another one, The build-onlyness of a port is calculated per portmaster run, so your results are not unexpected, even if they are not desirable. What needs to be done is to add code that tests whether ports marked build only for a given portmaster run are also listed as dependencies in an already installed port, but that's a non-trivial issue and my time right now is dominated by trying to find work, which unfortunately leaves little time available for portmaster hacking. My only suggestion (which admittedly is inadequate) is to apply the --delete-build-only knob on a case by case basis rather than having it in portmaster.rc. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster: problem with --packages-build?
On Friday 11 June 2010 22:45:26 Doug Barton wrote: The build-onlyness of a port is calculated per portmaster run, so your results are not unexpected, even if they are not desirable. What needs to be done is to add code that tests whether ports marked build only for a given portmaster run are also listed as dependencies in an already installed port, i would suggest just checking if the port is already installed but that's a non-trivial issue and my time right now is dominated by trying to find work, which unfortunately leaves little time available for portmaster hacking. My only suggestion (which admittedly is inadequate) is to apply the --delete-build-only knob on a case by case basis rather than having it in portmaster.rc. don't worry! thank you for the answer, and keep focusing on your life ;) -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla What do you have when you have six lawyers buried up to their necks in sand? Not enough sand. signature.asc Description: This is a digitally signed message part.
Re: FreeBSD Port: python26-2.6.5
On Tue, Jun 1, 2010 at 02:45, Bernardo Maciel bernardo.mac...@gmail.com wrote: On Mon, May 31, 2010 at 23:59, Garrett Cooper yanef...@gmail.com wrote: On Mon, May 31, 2010 at 9:49 AM, Bernardo Maciel bernardo.mac...@gmail.com wrote: Hello, I recently ran into a problem when compiling python 2.6.5 under FreeBSD 8.0-p2 . I searched around, asked in FreeBSD forums ( http://forums.freebsd.org/showthread.php?t=14268 ) and then e-mailed the python-help mailing list. The problem isn't yet solved. My problem is that when I compile python 2.6.5, I get a sem_init: No space left on device message when the script is building the _ssl extension: ... Increase the value of the kern.ipc.shmall sysctl because you have other applications eating up POSIX shmem in the background. HTH, -Garrett Hello again, Thank you for your reply. I increased the values of kern.ipc.shmall and kern.ipc.shmmax but still no luck. I have 256MB RAM and 256MB of swap space, so I searched around and chose 450MB for kern.ipc.shmmax, which gives a value of 115200 for kern.ipc.shmall, since hw.pagesize is 4096. The limit on kern.ipc.shmmax is RAM + swap, right? Here is the kern.ipc sysctl: -- FPserver# sysctl kern.ipc kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 124 kern.ipc.nmbjumbo16: 1096 kern.ipc.nmbjumbo9: 2192 kern.ipc.nmbjumbop: 4384 kern.ipc.nmbclusters: 8768 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 36864 kern.ipc.maxpipekva: 4169728 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 136 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 115200 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 471859200 kern.ipc.maxsockets: 8768 kern.ipc.numopensockets: 11 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 4 kern.ipc.nsfbufs: 2448 -- I still get the same message when the script is building the _ssl extension. Can you help? Best regards, -- Bernardo After messing around with kern.ipc sysctls without any luck, I ended up resorting to pkg_add . Thanks for your help. Best regards, -- Bernardo ___ 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
