Re: ImageMagick fails to install
On 08/19/2011 16:40, Doug Barton wrote: This is on 7.x i386. Builds fine, and passes all self-tests. Thanks, Doug ( cd PerlMagick gmake CC='cc -std=gnu99 -std=gnu99' \ gmake CC='cc -std=gnu99 -std=gnu99' install ) gmake[3]: Entering directory `/usr/local/tmp/usr/ports/graphics/ImageMagick-nox11/work/ImageMagick-6.7.0-10/PerlMagick' cp Magick.pm blib/lib/Image/Magick.pm AutoSplitting blib/lib/Image/Magick.pm (blib/lib/auto/Image/Magick) /usr/local/bin/perl5.12.4 /usr/local/lib/perl5/site_perl/5.12.4/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.12.4/ExtUtils/typemap Magick.xs Magick.xsc mv Magick.xsc Magick.c Could not find a typemap for C type 'Image::Magick' in Magick.xs, line 2404 gmake[3]: *** [Magick.c] Error 1 gmake[3]: Leaving directory `/usr/local/tmp/usr/ports/graphics/ImageMagick-nox11/work/ImageMagick-6.7.0-10/PerlMagick' gmake[2]: *** [install-exec-perl] Error 2 I have this same issue, created a post on this list a few days ago. I'm running 8.2-RELEASE-p2 amd64. -- Andre Goree an...@drenet.info ___ 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/158501: [patch] multimedia/mplayer: faad dependency problem [was] Re: [patch] mplayer and faad PR still not committed
On 20 August 2011 08:25, Thomas Zander ri...@rrr.de wrote: On Fri, Aug 19, 2011 at 22:19, Christian Weisgerber na...@freebsd.org wrote: I mean just add an unconditional CONFIGURE_ARGS+=--disable-faad instead of yet another option nobody needs. I agree. There is no reason to pull in external dependencies for codecs covered by ffmpeg. Yup, that's fine. Testing now... Chris ___ 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: sysutils/diskcheckd needs fixing and a maintainer
On 20 August 2011 05:47, per...@pluto.rain.com wrote: I've been running it for a little less than two days now, on a drive which contains a gmirror, and have yet to see it misbehave. (The HDD indicator does stay on, but this is not surprising given that, as noted above, diskcheckd is expected to run continuously.) Thank you very much for taking the time to investigate. Do we need a think twice before adding a port habit? Yes. Of course, these aren't pointless ports however; while still developed and maintained they were once useful. IIUC, diskcheckd started out in base and was later moved to ports (for reasons that are not obvious). I can't see that it is any less useful now than when first developed, or when moved from base to ports. It's time to go when they break and bitrot. For some definition of break and bitrot. Again, I haven't seen any actual breakage. diskcheckd could use a little tweaking, e.g. diskcheckd.conf.sample contains a stale reference to the diskcheckd.conf(5) manual page which was presumably missed when diskcheckd was moved to ports; it should now be the diskcheckd(8) manual page. BTW how does one go about fixing a FreeBSD-native port like this? Since we are the upstream, it would make more sense to revise the distfile than to add a patch in the port. I didn't find any mention of this in the Porter's Handbook. This is an unusual case where the sources are kept in the files/ subdir of the port's directory-- nowadays we'd put it in a separate distfile. However, for this case please feel free to submit a diff to the sources there and they can stay as long as the port remains useful. If you can't reproduce the problem I'll ask the submitter of ports/143566 if he still can. Is it logging to syslog? Also, would you be happy to take maintainership of this port? Chris -- Chris Rees | FreeBSD Developer cr...@freebsd.org | http://people.freebsd.org/~crees ___ 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
[Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
Hi,
I would like to propose a change to bsd.port.mk which, similarly to
obtaining the OSVERSION, checks if the system on which a port is being
built is a jailed environment.
This change can allow port maintainers to mark ports that do not run in
jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user
of special conditions or changes that will be needed to run a port from
within a jail. One particular example of the latter is
databases/postgresql*-server, where the user must enable
security.jail.sysvipc_allowed. I am sure this feature could expand to
other cases I have not considered yet, as well.
I have included three patches:
0-Mk-bsd.port.mk.txt - the proposed change to bsd.port.mk
1-ircservices-Makefile.txt - an example usage of disallowing a port from
being built within a jail
2-sshguard-Makefile.txt - an example usage of disabling a port from
being built within a jail conditionally (in this example, it is assumed
security/sshguard-pf is the target port)
Comments, etc, are welcome.
Regards,
Glen
--
Glen Barber | g...@freebsd.org
FreeBSD Documentation Project
--- bsd.port.mk.orig2011-08-12 12:39:23.0 -0400
+++ bsd.port.mk 2011-08-20 06:15:19.644576050 -0400
@@ -46,6 +46,7 @@
#FreeBSD, NetBSD, or OpenBSD as
appropriate.
# OSREL- The release version (numeric) of the
operating system.
# OSVERSION- The value of __FreeBSD_version.
+# JAILED - The system is a FreeBSD jail.
#
# This is the beginning of the list of all variables that need to be
# defined in a port, listed in order that they should be included
@@ -1196,6 +1197,11 @@
.endif
.endif
+# Check if the system is a jail
+.if !defined(JAILED)
+JAILED!= ${SYSCTL} -n security.jail.jailed
+.endif
+
MASTERDIR?=${.CURDIR}
.if ${MASTERDIR} != ${.CURDIR}
--- Makefile.orig 2009-08-31 09:50:55.0 -0400
+++ Makefile2011-08-20 06:14:04.987796133 -0400
@@ -27,6 +27,10 @@
.include bsd.port.pre.mk
+.if ${JAILED}
+IGNORE=Does not run from within a jail
+.endif
+
.if ${OSVERSION} 700042
CFLAGS+= -fno-stack-protector
.endif
--- Makefile.orig 2011-07-24 14:16:29.0 -0400
+++ Makefile2011-08-20 06:14:24.513106022 -0400
@@ -40,6 +40,9 @@
CONFIGURE_ARGS+= --mandir=${MANPREFIX}/man
.if ${SSHGUARDFW} == pf
+. if ${JAILED}
+IGNORE=Cannot use with pf within a jail
+. endif
PKGMSG_FWBLOCK= To activate or configure PF see
http://sshguard.sf.net/doc/setup/blockingpf.html;
.elif ${SSHGUARDFW} == ipfw
PKGMSG_FWBLOCK= Verify that IPFW is active with \ipfw show\.
signature.asc
Description: OpenPGP digital signature
Re: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On Sat, Aug 20, 2011 at 07:09:49AM -0400, Glen Barber wrote: Hi, I would like to propose a change to bsd.port.mk which, similarly to obtaining the OSVERSION, checks if the system on which a port is being built is a jailed environment. This change can allow port maintainers to mark ports that do not run in jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user of special conditions or changes that will be needed to run a port from within a jail. One particular example of the latter is databases/postgresql*-server, where the user must enable security.jail.sysvipc_allowed. I am sure this feature could expand to other cases I have not considered yet, as well. I do not think this is good idea. The machine or environment where the port is built sometimes (or, in my setups, quite often) is not the same as where it is run. Your proposal gives a tool to tightly tie the ports to build environments, that is detrimental for some setups, and also diminish the value of packaging. IMHO. pgpUm2qVh9JvO.pgp Description: PGP signature
Re: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On 8/20/11 7:52 AM, Kostik Belousov wrote:
On Sat, Aug 20, 2011 at 07:09:49AM -0400, Glen Barber wrote:
Hi,
I would like to propose a change to bsd.port.mk which, similarly to
obtaining the OSVERSION, checks if the system on which a port is being
built is a jailed environment.
This change can allow port maintainers to mark ports that do not run in
jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user
of special conditions or changes that will be needed to run a port from
within a jail. One particular example of the latter is
databases/postgresql*-server, where the user must enable
security.jail.sysvipc_allowed. I am sure this feature could expand to
other cases I have not considered yet, as well.
I do not think this is good idea. The machine or environment where
the port is built sometimes (or, in my setups, quite often) is not
the same as where it is run. Your proposal gives a tool to tightly
tie the ports to build environments, that is detrimental for some
setups, and also diminish the value of packaging. IMHO.
Hi Kostik,
Thank you for the comments.
I had neglected that some package building environments are jails with
the intent to install the packages on physical hardware or other
non-jailed environment, so this change would break those environments.
I had only tested the patches in a tinderbox environment.
One thing I can think of off-hand to fix this in that case is setting a
local environment variable to disable a check for security.jail.jailed.
Would this be an ok solution for those cases? If not, I happily agree
that this change should not be made then.
I have an updated patch to bsd.port.mk that looks for a local
environment variable, PKGJAIL - if it is set, then JAILED is unset.
Would this be acceptable?
Regards,
Glen
--
Glen Barber | g...@freebsd.org
FreeBSD Documentation Project
--- bsd.port.mk.orig2011-08-12 12:39:23.0 -0400
+++ bsd.port.mk 2011-08-20 08:07:12.656834897 -0400
@@ -46,6 +46,7 @@
#FreeBSD, NetBSD, or OpenBSD as
appropriate.
# OSREL- The release version (numeric) of the
operating system.
# OSVERSION- The value of __FreeBSD_version.
+# JAILED - The system is a FreeBSD jail.
#
# This is the beginning of the list of all variables that need to be
# defined in a port, listed in order that they should be included
@@ -1196,6 +1197,15 @@
.endif
.endif
+# Check if the system is a jail
+.if !defined(JAILED)
+. if !defined(PKGJAIL)
+JAILED!= ${SYSCTL} -n security.jail.jailed
+. else
+JAILED=
+. endif
+.endif
+
MASTERDIR?=${.CURDIR}
.if ${MASTERDIR} != ${.CURDIR}
signature.asc
Description: OpenPGP digital signature
Re: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On Sat, Aug 20, 2011 at 08:16:09AM -0400, Glen Barber wrote:
On 8/20/11 7:52 AM, Kostik Belousov wrote:
On Sat, Aug 20, 2011 at 07:09:49AM -0400, Glen Barber wrote:
Hi,
I would like to propose a change to bsd.port.mk which, similarly to
obtaining the OSVERSION, checks if the system on which a port is being
built is a jailed environment.
This change can allow port maintainers to mark ports that do not run in
jailed environments as IGNORE, or adjust PKG_MESSAGE to inform the user
of special conditions or changes that will be needed to run a port from
within a jail. One particular example of the latter is
databases/postgresql*-server, where the user must enable
security.jail.sysvipc_allowed. I am sure this feature could expand to
other cases I have not considered yet, as well.
I do not think this is good idea. The machine or environment where
the port is built sometimes (or, in my setups, quite often) is not
the same as where it is run. Your proposal gives a tool to tightly
tie the ports to build environments, that is detrimental for some
setups, and also diminish the value of packaging. IMHO.
Hi Kostik,
Thank you for the comments.
I had neglected that some package building environments are jails with
the intent to install the packages on physical hardware or other
non-jailed environment, so this change would break those environments.
I had only tested the patches in a tinderbox environment.
One thing I can think of off-hand to fix this in that case is setting a
local environment variable to disable a check for security.jail.jailed.
Would this be an ok solution for those cases? If not, I happily agree
that this change should not be made then.
I have an updated patch to bsd.port.mk that looks for a local
environment variable, PKGJAIL - if it is set, then JAILED is unset.
Would this be acceptable?
The change would require user to do a configuration for a thing that
previously just worked. What is the point ?
Right solution for the ports you provided as examples in your original
mail, IMO, is to check and provide a diagnostic at runtime. In fact, I do
not see a need in any special diagnostic, e.g. the lack of /dev/pf or
lack of permissions to open /dev/pf is enough to refuse to work for
program that depends on ability to modify pf configuration.
Also, if pf(4) is implemented properly, then jails _can_ modify filter
rules if configured so by administrator. Similarly, postgres just work
in a properly configured jail.
Regards,
Glen
--
Glen Barber | g...@freebsd.org
FreeBSD Documentation Project
--- bsd.port.mk.orig 2011-08-12 12:39:23.0 -0400
+++ bsd.port.mk 2011-08-20 08:07:12.656834897 -0400
@@ -46,6 +46,7 @@
# FreeBSD, NetBSD, or OpenBSD as
appropriate.
# OSREL - The release version (numeric) of the
operating system.
# OSVERSION - The value of __FreeBSD_version.
+# JAILED - The system is a FreeBSD jail.
#
# This is the beginning of the list of all variables that need to be
# defined in a port, listed in order that they should be included
@@ -1196,6 +1197,15 @@
.endif
.endif
+# Check if the system is a jail
+.if !defined(JAILED)
+. if !defined(PKGJAIL)
+JAILED!= ${SYSCTL} -n security.jail.jailed
+. else
+JAILED=
+. endif
+.endif
+
MASTERDIR?= ${.CURDIR}
.if ${MASTERDIR} != ${.CURDIR}
pgp0XtSfOp5tb.pgp
Description: PGP signature
Re: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On 8/20/11 8:44 AM, Kostik Belousov wrote: One thing I can think of off-hand to fix this in that case is setting a local environment variable to disable a check for security.jail.jailed. Would this be an ok solution for those cases? If not, I happily agree that this change should not be made then. I have an updated patch to bsd.port.mk that looks for a local environment variable, PKGJAIL - if it is set, then JAILED is unset. Would this be acceptable? The change would require user to do a configuration for a thing that previously just worked. What is the point ? I suppose the specific problem I am trying to solve is a case where a user builds a port within a jail with the expectation that the port will in fact run within the jail with little or no changes. Perhaps security/sshguard-pf and databases/postgresql*-server are not the most ideal examples of where this would be relevant. I agree that a configuration change for something that worked before is not the best solution. So, I retract this change proposal. Again, thank you for the feedback and pointing out that this would have had negative impact on those using jails for package building. Regards, Glen -- Glen Barber | g...@freebsd.org FreeBSD Documentation Project ___ 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: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On 8/20/11 8:44 AM, Kostik Belousov wrote: One thing I can think of off-hand to fix this in that case is setting a local environment variable to disable a check for security.jail.jailed. Would this be an ok solution for those cases? If not, I happily agree that this change should not be made then. I have an updated patch to bsd.port.mk that looks for a local environment variable, PKGJAIL - if it is set, then JAILED is unset. Would this be acceptable? The change would require user to do a configuration for a thing that previously just worked. What is the point ? I suppose the specific problem I am trying to solve is a case where a user builds a port within a jail with the expectation that the port will in fact run within the jail with little or no changes. Perhaps security/sshguard-pf and databases/postgresql*-server are not the most ideal examples of where this would be relevant. I agree that a configuration change for something that worked before is not the best solution. So, I retract this change proposal. Again, thank you for the feedback and pointing out that this would have had negative impact on those using jails for package building. Regards, Glen I, myself, have not installed or built enough packages in jails to find this issue, however I am using tinderbox for maintaining my ports, submitting ports, or patches, as well as maintaining a local ports tree. In doing this, and maintaining our operational environment, I am finding may conditions where you may want to do one thing or another, and the possibilities I have found can be endless, so it could be argued to not introduce global functionality for the X number of ports/packages that need it, however to code the port to be aware of these conditions in the packaging scripts. For example, you could test for values of sysctl, or another condition. Based on the result, perform X action. Although, I haven't done this specifically for a jail, I don't see why the same practice couldn't be exercised. These, I believe, can all be take taken advantage of in subsequent pkg-* files. Just a thought. Thanks, Jason ___ 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: [Request for Comments] Adding a JAILED meta-variable to bsd.port.mk
On 20 August 2011 18:46, Jason Helfman jhelf...@e-e.com wrote: On 8/20/11 8:44 AM, Kostik Belousov wrote: One thing I can think of off-hand to fix this in that case is setting a local environment variable to disable a check for security.jail.jailed. Would this be an ok solution for those cases? If not, I happily agree that this change should not be made then. I have an updated patch to bsd.port.mk that looks for a local environment variable, PKGJAIL - if it is set, then JAILED is unset. Would this be acceptable? The change would require user to do a configuration for a thing that previously just worked. What is the point ? I suppose the specific problem I am trying to solve is a case where a user builds a port within a jail with the expectation that the port will in fact run within the jail with little or no changes. Perhaps security/sshguard-pf and databases/postgresql*-server are not the most ideal examples of where this would be relevant. I agree that a configuration change for something that worked before is not the best solution. So, I retract this change proposal. Again, thank you for the feedback and pointing out that this would have had negative impact on those using jails for package building. Regards, Glen I, myself, have not installed or built enough packages in jails to find this issue, however I am using tinderbox for maintaining my ports, submitting ports, or patches, as well as maintaining a local ports tree. In doing this, and maintaining our operational environment, I am finding may conditions where you may want to do one thing or another, and the possibilities I have found can be endless, so it could be argued to not introduce global functionality for the X number of ports/packages that need it, however to code the port to be aware of these conditions in the packaging scripts. For example, you could test for values of sysctl, or another condition. Based on the result, perform X action. Although, I haven't done this specifically for a jail, I don't see why the same practice couldn't be exercised. These, I believe, can all be take taken advantage of in subsequent pkg-* files. Hm, not a fan of getting output of sysctl for many ports -- that'd take forever in INDEX generation for example. Perhaps we could just introduce a JAILED variable and leave it at that? Chris ___ 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: chromium-13.0.782.112
On Fri, Aug 19, 2011 at 2:39 AM, Patrick Ian pransp...@gmail.com wrote: Hey, I would like to use the chromedriver target from the chromium port. However, I do not know how to add that target to my local ports chromium configuration. How do I make the chromedriver target? -- -Patrick Ranspach- Hello, Do a make patch in the port's directory, set GYP_DEFINES* and then you can cd into work/chromium-version directory and play with gmake target -jx. I believe that the makefiles are created automatically if they don't exist but if you have problems run the following : python ./build/gyp_chromium chrome/chrome.gyp --depth . I haven't heard of chromedriver before but please report your findings back so we can work on a port option. * setenv GYP_DEFINES use_system_libxml=1 use_system_ffmpeg=0 use_system_yasm=1 python_ver=2.7 ffmpeg_branding=Chrome use_gconf=1 use_system_vpx=1 disable_nacl=1 use_ibus=0 linux_use_heapchecker=1 linux_link_gsettings=1 linux_link_gnome_keyring=1 use_gnome_keyring=1 Regards, George ___ 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: sysutils/diskcheckd needs fixing and a maintainer
Chris Rees utis...@gmail.com wrote: Is it logging to syslog? I haven't seen anything in /var/log/messages or on ttyv0, but this may be a matter of configuration rather than a problem with diskcheckd. * I'm running diskcheckd as a normal user, not as root. (The user is in the operator group and does have read access to the disks. There's no obvious reason to give diskcheckd full root access since it does not need -- and should not be allowed -- to write to the disks.) * diskcheckd passes LOG_CONS|LOG_PID, and LOG_DAEMON, to openlog(3), and -- for the one message that should actually be logged absent failures -- LOG_INFO to syslog(3). * My syslog configuration is whatever 8.1-RELEASE provides as shipped. I have not tried to figure out whether that combination _should_ produce anything in /var/log/messages or on ttyv0. Also, would you be happy to take maintainership of this port? Not at this point, given that I would be taking on maintainance not only of the port but also of the application itself. I'm not at all sure that I understand it well enough for that, yet. (So far I have built it, read _part_ of the code, hacked in some additional debug, and run it :) ___ 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: sysutils/diskcheckd needs fixing and a maintainer
On Fri, Aug 19, 2011 at 09:47:33PM -0700, per...@pluto.rain.com wrote: If it's OK to close a PR without fixing it, because no one seems interested, maybe we should just close 143566 and be done with it No, we're really not trying to do that. I keep trying to communicate to PR submitters that there are committers who _do_ care about these things. But, realistically, look at the numbers: several dozen PRs come in a day, and the ports count is nearing 24k. Not everything is going to get done, so things tend to depend on individual committer interests. There seems to be some disagreement on how broken this port exactly is. I'd be glad to see someone take it over and make it 100% working, but it's not the type of thing that I can do myself. Not all of those 24k ports are going to be working at any given time (not even close). It's just a numbers game. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
