Re: [51915] trunk/dports/lang
On Jun 6, 2009, at 04:08, t...@macports.org wrote: Revision: 51915 http://trac.macports.org/changeset/51915 Author: t...@macports.org Date: 2009-06-06 02:08:48 -0700 (Sat, 06 Jun 2009) Log Message: --- SnowLeopard default was set back to gcc-4.2, no need to explicitly force it The default for Snow Leopard in the currently-released version of MacPorts is still llvm-gcc-4.2. The change to gcc-4.2 was only made on trunk. So maybe these statements are still necessary in the python ports until MacPorts 1.8.0 is released? I'm not sure, I have no access to Snow Leopard and no familiarity with the differences between gcc and llvm-gcc. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: fail2ban
On Jun 6, 2009, at 15:28, Jeremy Lavergne wrote: On Jun 6, 2009, at 1:09 PM, Bradley Giesbrecht wrote: What is the macports way to get python26 into my paths? python2.6 installed by MacPorts is already in your path. To get a symlink called python pointing to it, use python_select as Jeremy said: You need python_select -- it allows you to change which python you use. But note that while python_select can be convenient if you want to use python on the command line, IMHO no port should require that the user use python_select. Any port that requires Python should never attempt to use a binary called python; it should always use the versioned binary installed by the corresponding port, for example the binary python2.6 installed by the python26 port. You may need to add some patches and/or reinplaces to your port to get the software you're porting to do this. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: creating two launchd items
On Jun 7, 2009, at 03:03, Joshua Root wrote: On 2009-6-7 17:43, Bryan Blackburn wrote: Looks like /Library is considered to be not a violation, so no need for destroot.violate_mtree. This will be changing in 1.8, however. I noticed your recent commit that removed this exemption. So how will this work as of 1.8? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Sip 4.8 / PyQt 4.5
On Jun 6, 2009, at 13:43, vincent habchi wrote: For those who are in a hurry, here are Portfiles corresponding to the brand new releases of Sip (first file) and PyQt – the latter at last compatible with qt 4.5.1. Universal builds are supported, though of course Sip must be built universal in order for PyQt to be. Please test before commiting ;) New portfiles should typically be contributed by filing a ticket in the issue tracker and attaching the new portfile there. http://guide.macports.org/#project.tickets ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
--On 6 June 2009 12:43:36 -0700 Jordan K. Hubbard j...@apple.com wrote: and if there are no users of a port to report errors, then who really cares if it's broken? All the users who come to MacPorts, give it a go, then go away without reporting the errors that cause them to give up. It's probably better to be missing a port than to have potential users wasting time with a broken port. Why don't they report the problems? Well, perhaps because they need to install the software today, they've wasted time already, they need to move on. Or perhaps they don't understand, or even know about the reporting process. Or perhaps they think they have nothing useful to say; they don't know why the port failed, and assume someone else must already be onto it. There's no easy way to tell whether the problem has already been reported. So, and automated test suite would (a) get errors diagnosed and fixed quicker, (b) reduce the number of errors as a result, and (c) give us a way of flagging them before a user starts a 20 minute build process. -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Sip 4.8 / PyQt 4.5
Hi Ryan, New portfiles should typically be contributed by filing a ticket in the issue tracker and attaching the new portfile there. http://guide.macports.org/#project.tickets Ok, I'll do that. Sorry for the noise. Also, as soon as the software are released, I'll be adding a couple of new ports. Cheers Vincent ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [51915] trunk/dports/lang
On Jun 8, 2009, at 12:26 AM, Ryan Schmidt wrote: On Jun 6, 2009, at 04:08, t...@macports.org wrote: Revision: 51915 http://trac.macports.org/changeset/51915 Author: t...@macports.org Date: 2009-06-06 02:08:48 -0700 (Sat, 06 Jun 2009) Log Message: --- SnowLeopard default was set back to gcc-4.2, no need to explicitly force it The default for Snow Leopard in the currently-released version of MacPorts is still llvm-gcc-4.2. The change to gcc-4.2 was only made on trunk. So maybe these statements are still necessary in the python ports until MacPorts 1.8.0 is released? I'm not sure, I have no access to Snow Leopard and no familiarity with the differences between gcc and llvm-gcc. Anyone running SnowLeopard should be using trunk, because 1.7.1 does not work very well... hopefully we'll have 1.8 out in time. - Toby ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: creating two launchd items
On 2009-6-9 02:03, Blair Zajac wrote: On Jun 8, 2009, at 3:01 AM, Joshua Root wrote: On 2009-6-8 19:01, Ryan Schmidt wrote: On Jun 7, 2009, at 03:03, Joshua Root wrote: On 2009-6-7 17:43, Bryan Blackburn wrote: Looks like /Library is considered to be not a violation, so no need for destroot.violate_mtree. This will be changing in 1.8, however. I noticed your recent commit that removed this exemption. So how will this work as of 1.8? /Library as a whole will not be allowed, but only the specific subdirs that the startupitem code installs into. Java JNI bindings are also installed /Library/Java/Extensions, such as subversion-javahlbindings. Then they should use 'destroot.violate_mtree yes'. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Sip 4.8 / PyQt 4.5
On Jun 8, 2009, at 14:54, vincent habchi wrote: thank you for all your advice. I clearly copied the portfile of the old versions, converted them to my own conventions (e.g. tabs instead of spaces) and then tested them. They were by no means meant to be drop-in replacement for the old Portfiles, but just transitory files for those eager to upgrade by a semi-official way. Note that for MacPorts we have standardized on spaces instead of tabs, so a commit to reverse that would not be ideal. Many ports were written before this policy went into effect, which is why you still see ports with tabs in the tree, but if anything we should be changing tabs to spaces, not the other way around. I'm a bit baffled that saispo is not the maintainer of py26-sip since I did not alter that line in any way. :) In the case of py26-sip it was easy to check, since there has only been one version of the port. http://trac.macports.org/log/trunk/dports/python/py26-sip The two additional commits were by me and were just to set svn properties that were forgotten initially. I have some new ports ready, but they are based on SVN versions. Shall I commit them anyway? If they are your ports, or openmaintainer or nomaintainer ports, then by all means yes! But do keep in mind the rule of one logical change per commit. If they are not your ports and are not openmaintainer, then file a ticket, assign it to the maintainer, and attach your proposed changes. If the maintainer does not respond within 72 hours you can commit your changes. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On Jun 6, 2009, at 15:36, Jeremy Lavergne wrote: http://portmill.florianebeling.com/ is doing a default build for all ports if I'm not mistaken. I'm just getting back to this thread. Thank you for your work on this, Florian! Some friendly criticism: I imagine you've been working on this for awhile, and since this is an open source project, it would have been nice to know you were working on this, and to have the code in the MacPorts repository (the users area would have been a good place for it during development). You said you wrote this with Rails and CouchDB. While I understand the desire to write using technologies you're familiar with, MacPorts is written in Tcl, and the main MacPorts web site is written in PHP and MySQL, and it would be nice to not introduce new technologies if possible, so as to lower the barrier to entry for other developers. It's easy for me to say, since I am very familiar with PHP and MySQL, and do not know and had not planned to know Rails and CouchDB. In fact I would rather not have yet another hostname and yet another disjoint part of the MacPorts web experience, but rather integrate this content into the existing www.macports.org web site, or into the new port pages planned with #19300: http://trac.macports.org/ticket/19300 I notice it flagged the mldonkey build as failed, but in fact it was one of mldonkey's dependencies which failed. Perhaps there is a way that could be made more clear in the interface. Juan (jmpp) had always said that a prerequisite for a build/test system was implementing the port logging proposal: http://trac.macports.org/wiki/LoggingProposal And this is the project Dmitry (enl) has been approved to work on for this year's Google Summer of Code: http://trac.macports.org/wiki/enl http://trac.macports.org/browser/branches/gsoc09-logging Have you coordinated with him? We don't want duplication of effort. Your work is clearly logging something because the logs are appearing on your web site. If this is not integrated with the MacPorts Tcl code, perhaps you can assist Dmitry in doing so. If you and Dmitry finish the logging task early I'm sure there are other tasks we can have him do for the rest of the summer. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On Jun 8, 2009, at 2:18 AM, Ian Eiloart wrote: So, and automated test suite would (a) get errors diagnosed and fixed quicker, (b) reduce the number of errors as a result, and (c) give us a way of flagging them before a user starts a 20 minute build process. I have been reading this thread, looks like the current project I looked at with the web listing is really nice. Curious, what if MacPorts were to implement a sort of CrashReporter type feature. Granted, this is not a crash, but a system where the output of the build errors were sent somewhere, into a database, where they could be looked at. I can see a few other values to this as well, and I believe there are a number of simple open tools out there that would facilitate making this easy to do. The nice thing as I see it, is end user support. If MacPorts has an error, the app could present them a message Sorry we could not build port x, to date, there have been x build errors with this portfile. We have assigned this build error an id of x. If you would like to follow or start a discussion of this issue, please follow this link: http://eample.com?id=x . Users may have had similar issues, which you can see at http://example.com?id=xporfile=y These build errors could be auto posted to a mailing list, put into trac, whatever was wanted really. The ability to help a user along, in order to get them to help out MacPorts, may be something worth looking into. It is also a very good way to get an exact idea of what ports are being installed. You can then see that port x has been installed 400 times, 390 of those with no issues, 10 of those with some issue. -- Scott * If you contact me off list replace talklists@ with scott@ * ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On Jun 8, 2009, at 15:49, Scott Haneda wrote: On Jun 8, 2009, at 2:18 AM, Ian Eiloart wrote: So, and automated test suite would (a) get errors diagnosed and fixed quicker, (b) reduce the number of errors as a result, and (c) give us a way of flagging them before a user starts a 20 minute build process. I have been reading this thread, looks like the current project I looked at with the web listing is really nice. Curious, what if MacPorts were to implement a sort of CrashReporter type feature. Granted, this is not a crash, but a system where the output of the build errors were sent somewhere, into a database, where they could be looked at. MacPorts does not log build errors, or in fact anything. That's what the logging proposal I pointed to in my previous mail is all about. Once that is implemented, any number of things could happen with those logs, as you suggested. I can see a few other values to this as well, and I believe there are a number of simple open tools out there that would facilitate making this easy to do. The nice thing as I see it, is end user support. If MacPorts has an error, the app could present them a message Sorry we could not build port x, to date, there have been x build errors with this portfile. We have assigned this build error an id of x. If you would like to follow or start a discussion of this issue, please follow this link: http://eample.com?id=x. Users may have had similar issues, which you can see at http://example.com?id=xporfile=y These build errors could be auto posted to a mailing list, put into trac, whatever was wanted really. The ability to help a user along, in order to get them to help out MacPorts, may be something worth looking into. I think the idea of a central build and testing server is the best part of this project to start on. Users can and do have nonstandard things on their machines which can cause builds to fail, and an automated build log posting wouldn't contain such information; as you've no doubt seen in mailing list discussions, it often has to be dragged out of the user that they have things installed in /usr/local or /sw or they are using an outdated version of Xcode. If we get a central testing server, extending that to packaging and distributing binaries should be straightforward. And once we are distributing binaries, there's much less reason for regular users to ever build from source and thus to ever encounter build errors. It is also a very good way to get an exact idea of what ports are being installed. You can then see that port x has been installed 400 times, 390 of those with no issues, 10 of those with some issue. I proposed this two years ago but was shot down because this was considered an invasion of privacy and people didn't want MacPorts phoning home. I had wanted to have a nice status display on the MacPorts homepage showing which ports were the most popular, for example. I see their point, but I'm glad to re-open the topic if attitudes have changed. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On Jun 8, 2009, at 5:46 PM, Ryan Schmidt wrote: It is also a very good way to get an exact idea of what ports are being installed. You can then see that port x has been installed 400 times, 390 of those with no issues, 10 of those with some issue. I proposed this two years ago but was shot down because this was considered an invasion of privacy and people didn't want MacPorts phoning home. I believe the list consensus was that it would be fine provided it was 'opt in'. I had wanted to have a nice status display on the MacPorts homepage showing which ports were the most popular, for example. I see their point, but I'm glad to re-open the topic if attitudes have changed. ... there's also the matter of someone doing the actual development work ;-) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ PGP.sig Description: This is a digitally signed message part ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On Mon, Jun 08, 2009 at 03:36:21PM -0500, Ryan Schmidt said: [...] You said you wrote this with Rails and CouchDB. While I understand the desire to write using technologies you're familiar with, MacPorts is written in Tcl, and the main MacPorts web site is written in PHP and MySQL, and it would be nice to not introduce new technologies if possible, so as to lower the barrier to entry for other developers. It's easy for me to say, since I am very familiar with PHP and MySQL, and do not know and had not planned to know Rails and CouchDB. In fact I would rather not have yet another hostname and yet another disjoint part of the MacPorts web experience, but rather integrate this content into the existing www.macports.org web site, or into the new port pages planned with #19300: http://trac.macports.org/ticket/19300 Of course it doesn't really lower the barrier if someone knows Rails but not PHP, especially when quite a bit of code has already been written. While trying to stay homogeneous would be nice language-wise, it has been an issue with getting base developers as many people don't know/don't want to learn Tcl. Fortunately both PHP and Rails are popular so I'm guessing we'll have less of an issue with developers for those areas than for Tcl. Unless you're willing to rewrite in PHP? I notice it flagged the mldonkey build as failed, but in fact it was one of mldonkey's dependencies which failed. Perhaps there is a way that could be made more clear in the interface. mpab should be skipping ports where a dependency failed, and not even trying otherwise; though this only happens when you tell it to build everything instead of specifying a list of ports. [...] Have you coordinated with him? We don't want duplication of effort. Your work is clearly logging something because the logs are appearing on your web site. If this is not integrated with the MacPorts Tcl code, perhaps you can assist Dmitry in doing so. If you and Dmitry finish the logging task early I'm sure there are other tasks we can have him do for the rest of the summer. Fortunately the logging stuff should be implemented in a way that will be useful for various scenarios, including integration with MPWA (if that ever happens) as well as things like mpab. Note that the way mpab works now is it just uses debug and keeps the output around, basically a really cheap form of what the logging stuff will do. I'm guessing the way Florian is accessing these with the web stuff is to just copy it out from the chroot. Bryan ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
I'll take on the rewriting to PHP this summer if it needs to be done. On Jun 8, 2009, at 7:54 PM, Bryan Blackburn wrote: Of course it doesn't really lower the barrier if someone knows Rails but not PHP, especially when quite a bit of code has already been written. While trying to stay homogeneous would be nice language-wise, it has been an issue with getting base developers as many people don't know/don't want to learn Tcl. Fortunately both PHP and Rails are popular so I'm guessing we'll have less of an issue with developers for those areas than for Tcl. Unless you're willing to rewrite in PHP? smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52043] trunk/dports/tex/texlive_base
On Mon, Jun 08, 2009 at 02:29:16PM -0700, jerem...@macports.org said: Revision: 52043 http://trac.macports.org/changeset/52043 Author: jerem...@macports.org Date: 2009-06-08 14:29:15 -0700 (Mon, 08 Jun 2009) Log Message: --- texlive_base: Use freetype instead of ATSU. Added missing dependency on motif What piece needs Motif? I've had texlive installed for some time without it... Bryan [...] -port:xorg-libXaw port:xorg-libXp +port:xorg-libXaw lib:libXm:openmotif [...] ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
2009/6/8 Scott Haneda talkli...@newgeo.com: On Jun 8, 2009, at 2:46 PM, Ryan Schmidt wrote: I proposed this two years ago but was shot down because this was considered an invasion of privacy and people didn't want MacPorts phoning home. I had wanted to have a nice status display on the MacPorts homepage showing which ports were the most popular, for example. I see their point, but I'm glad to re-open the topic if attitudes have changed. I think we should re-open it. I do not see this as an invasion of privacy, and it could very well be turned off, or requested on demand: Report stats to MP [yes] [no] [never again] IMHO, Apple provides a pretty great user experience for this that we could emulate. If a program crashes, ask the user if they'd like to report the crash using a dialog box (or dialog box equivalent). These are not strictly crashes, but I *think* the user experience translates. The fancy version could allow user input values always, never, yes, and no, which would translate to persisted user preferences of always, never, or ask. The default preference would be ask. Cheers, Andre ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
There's a difference between a crash and a failed compilation in that the system can't just catch it. Apple also pays people to look at those crash reports. We're almost entirely unpaid volunteers with a variable body count. On Jun 8, 2009, at 8:26 PM, Andre Stechert wrote: If a program crashes, ask the user if they'd like to report the crash using a dialog box (or dialog box equivalent). These are not strictly crashes, but I *think* the user experience translates. smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [52043] trunk/dports/tex/texlive_base
xdvi can use either motif or xaw. It builds binaries for both if both are available. xdvi-motif.bin is the file that actually links against it. --Jeremy On Jun 8, 2009, at 17:01, Bryan Blackburn wrote: On Mon, Jun 08, 2009 at 02:29:16PM -0700, jerem...@macports.org said: Revision: 52043 http://trac.macports.org/changeset/52043 Author: jerem...@macports.org Date: 2009-06-08 14:29:15 -0700 (Mon, 08 Jun 2009) Log Message: --- texlive_base: Use freetype instead of ATSU. Added missing dependency on motif What piece needs Motif? I've had texlive installed for some time without it... Bryan [...] -port:xorg-libXaw port:xorg-libXp +port:xorg-libXaw lib:libXm:openmotif [...] ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On 6/8/09 4:56 PM, Jeremy Lavergne wrote: I'll take on the rewriting to PHP this summer if it needs to be done. And I'll volunteer to help with the Rails upkeep if not. =] --j On Jun 8, 2009, at 7:54 PM, Bryan Blackburn wrote: Of course it doesn't really lower the barrier if someone knows Rails but not PHP, especially when quite a bit of code has already been written. While trying to stay homogeneous would be nice language-wise, it has been an issue with getting base developers as many people don't know/don't want to learn Tcl. Fortunately both PHP and Rails are popular so I'm guessing we'll have less of an issue with developers for those areas than for Tcl. Unless you're willing to rewrite in PHP? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Is it time to start regression testing yet?
On 6/8/09 6:17 PM, Jim Meyer wrote: On 6/8/09 2:46 PM, Ryan Schmidt wrote: It is also a very good way to get an exact idea of what ports are being installed. You can then see that port x has been installed 400 times, 390 of those with no issues, 10 of those with some issue. I proposed this two years ago but was shot down because this was considered an invasion of privacy and people didn't want MacPorts phoning home. I had wanted to have a nice status display on the MacPorts homepage showing which ports were the most popular, for example. I see their point, but I'm glad to re-open the topic if attitudes have changed. Check out the CPAN::Reporter perl module. It's essentially an opt-in to just this sort of thing for Perl modules; if you install it, suddenly your build results are sent in. Forgot the link: http://search.cpan.org/dist/CPAN-Reporter/lib/CPAN/Reporter.pod --j ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Default compiler for Snow Leopard
Is there any plan to define or redefine the default compiler for Snow Leopard? Some folks may have access to a developer preview of Snow Leopard soon, what do you recommend to maintain the integrity of an existing MacPorts installation under Leopard, after the upgrade to Snow Leopard? Take care, Darren ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Default compiler for Snow Leopard
On Jun 8, 2009, at 10:22 PM, Darren Weber wrote: Is there any plan to define or redefine the default compiler for Snow Leopard? Some folks may have access to a developer preview of Snow Leopard soon, what do you recommend to maintain the integrity of an existing MacPorts installation under Leopard, after the upgrade to Snow Leopard? Provided you're using MacPorts from trunk, the current default compiler is correct. - Toby ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Removing configure options
I have the most basic of a port file and I can not get it to work.
Here is how I do it by hand
cd ~/Downloads/rbldnsd
sudo -s
./consigure
make
cp rbldnsd var/rbldnsd
I am done at that point.
sudo port -d install in my local repo
DEBUG: Assembled command: 'cd /opt/local/var/macports/build/
_Users_haneda_macports_sysutils_rbldnsd/work/rbldnsd-0.996b ./
configure --prefix=/opt/local'
configure: unknown option `--prefix=/opt/local'
How do I yank away the prefix, where is it best to store this file in /
opt/local, and what category is best for this one?
PortSystem 1.0
namerbldnsd
version 0.996b
categories sysutils
master_siteshttp://www.corpit.ru/mjt/rbldnsd/
distfiles ${name}_0.996b.tar.gz
description test
long_descriptiontest
checksums md5 9a0f26f3b33764c325a96bd4c61b26fa \
sha1
9cfe6cf01c54088cecc3a02902c721ee714f1c28 \
rmd160
15be588fb4051f0526084425b586ea7986b6493a
--
Scott * If you contact me off list replace talklists@ with scott@ *
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Removing configure options
Check out this command for ideas on why prefix isn't working:
./configure --help
If you need to override the configure arguments in MacPorts, that's
done via configure.args-append and configure.args-delete
On Jun 9, 2009, at 1:43 AM, Scott Haneda wrote:
I have the most basic of a port file and I can not get it to work.
Here is how I do it by hand
cd ~/Downloads/rbldnsd
sudo -s
./consigure
make
cp rbldnsd var/rbldnsd
I am done at that point.
sudo port -d install in my local repo
DEBUG: Assembled command: 'cd /opt/local/var/macports/build/
_Users_haneda_macports_sysutils_rbldnsd/work/rbldnsd-0.996b ./
configure --prefix=/opt/local'
configure: unknown option `--prefix=/opt/local'
How do I yank away the prefix, where is it best to store this file
in /opt/local, and what category is best for this one?
PortSystem 1.0
namerbldnsd
version 0.996b
categories sysutils
master_siteshttp://www.corpit.ru/mjt/rbldnsd/
distfiles ${name}_0.996b.tar.gz
description test
long_descriptiontest
checksums md5 9a0f26f3b33764c325a96bd4c61b26fa \
sha1
9cfe6cf01c54088cecc3a02902c721ee714f1c28 \
rmd160
15be588fb4051f0526084425b586ea7986b6493a
--
Scott * If you contact me off list replace talklists@ with scott@ *
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Removing configure options
I tried configure.args-delete, do I have to quote it?
configure.args-delete --prefix=/opt/local
Thanks
On Jun 8, 2009, at 10:46 PM, Jeremy Lavergne wrote:
Check out this command for ideas on why prefix isn't working:
./configure --help
If you need to override the configure arguments in MacPorts, that's
done via configure.args-append and configure.args-delete
On Jun 9, 2009, at 1:43 AM, Scott Haneda wrote:
I have the most basic of a port file and I can not get it to work.
Here is how I do it by hand
cd ~/Downloads/rbldnsd
sudo -s
./consigure
make
cp rbldnsd var/rbldnsd
I am done at that point.
sudo port -d install in my local repo
DEBUG: Assembled command: 'cd /opt/local/var/macports/build/
_Users_haneda_macports_sysutils_rbldnsd/work/rbldnsd-0.996b ./
configure --prefix=/opt/local'
configure: unknown option `--prefix=/opt/local'
How do I yank away the prefix, where is it best to store this file
in /opt/local, and what category is best for this one?
PortSystem 1.0
namerbldnsd
version 0.996b
categories sysutils
master_siteshttp://www.corpit.ru/mjt/rbldnsd/
distfiles ${name}_0.996b.tar.gz
description test
long_descriptiontest
checksums md5 9a0f26f3b33764c325a96bd4c61b26fa \
sha1
9cfe6cf01c54088cecc3a02902c721ee714f1c28 \
rmd160
15be588fb4051f0526084425b586ea7986b6493a
--
Scott * If you contact me off list replace talklists@ with scott@ *
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Removing configure options
My apologies: the prefix is located in configure.pre_args. Please try: configure.pre_args-delete --prefix=/opt/local I believe you shouldn't need to quote it unless there's a space in it. On Jun 9, 2009, at 1:54 AM, Scott Haneda wrote: I tried configure.args-delete, do I have to quote it? configure.args-delete --prefix=/opt/local smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
