Understanding what I am calling the mess that is perl modules
Me again... Sorry I need Tie::RDBM If someone can tell me anything wrong I am doing, or better ways, I would be able to provide more ports back to MacPorts. `port search p5-tie` 4 results, none of which appear to be what I want. What are the possibilities Tie::RDBM is contained within one of the 4 results macports found? The answer to that should be 0. If it is not, I am searching wrong and would like to know how to correctly search. If I am searching correctly, there needs to be a standard way to resolve this where the contents of a module are put into the port file so it can be searched and found. I have a feeling the answer is not 0. That being the case, I would like to suggest no port be approved until this qualification for search is met. ports may have 5000+ port files, but with this issue solved, it could appear to have many many more. I am trying to add in Tie::RDBM and find this page: http://search.cpan.org/~lds/Tie-DBI-1.02/lib/Tie/RDBM.pm Version 0.70, so I would make my port file with a name of: p5-Tie-RDBM 0.70 Which is going to translate to downloading a file of: Tie-RDBM-0.70.tar.gz I am betting dollars to donuts that will fail. On the cpan page I see they want me to download Tie-DBI-1.02.tar.gz. And there, I am lost, the version is way off, the name is off, there is no way MacPorts is going to figure this out. I actually do not even understand why a port has to be made for anything in CPAN. I am sure the publish a list of all their modules, how come that list can not just exist in MacPorts, and we can simply issue something like `sudo port install cpan-foo::bar::baz and have MacPorts do the rest. For items that would not build right away, or if someone wants something tried, true, and tested, there could be a full port file. Thanks for all the help, I did manage to submit a few portfiles to the tracker today. -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
On Jan 21, 2009, at 02:35, Scott Haneda wrote: I need Tie::RDBM If someone can tell me anything wrong I am doing, or better ways, I would be able to provide more ports back to MacPorts. `port search p5-tie` 4 results, none of which appear to be what I want. What are the possibilities Tie::RDBM is contained within one of the 4 results macports found? The answer to that should be 0. If it is not, I am searching wrong and would like to know how to correctly search. If I am searching correctly, there needs to be a standard way to resolve this where the contents of a module are put into the port file so it can be searched and found. I have a feeling the answer is not 0. That being the case, I would like to suggest no port be approved until this qualification for search is met. ports may have 5000+ port files, but with this issue solved, it could appear to have many many more. I'm not sure this issue is limited to Perl modules. What if a user knows that they want the program mogrify, but they do not know what software package provides it? port search mogrify does not tell you. You have to already know that it's provided by ImageMagick. MacPorts at this time seems to assume that the user either already knows what software package they want to install, or that they can find it using keywords from the description. It might be nice to let the user search by what files are in the port. port contents tells you what's in a port, but only if it's already installed, which isn't very helpful if you're trying to figure out which port to install. Problem is the list of files in a port is not known to MacPorts until the port is installed. This could be more easily done if we had binary packages, but that is a long way off. There are also the occasional ports that install different files on different systems; one would have to take care that all possible files are included in the search. I am trying to add in Tie::RDBM and find this page: http://search.cpan.org/~lds/Tie-DBI-1.02/lib/Tie/RDBM.pm Version 0.70, so I would make my port file with a name of: p5-Tie-RDBM 0.70 Which is going to translate to downloading a file of: Tie-RDBM-0.70.tar.gz I am betting dollars to donuts that will fail. On the cpan page I see they want me to download Tie-DBI-1.02.tar.gz. And there, I am lost, the version is way off, the name is off, there is no way MacPorts is going to figure this out. So the MacPorts port should probably be for the entire Tie::DBI 1.02 package, not just for its Tie::RDBM subpackage. You can ask the author (s) of Tie::DBI why they have combined several perl modules into one package, but presumably it's because they all work together and require one another. I actually do not even understand why a port has to be made for anything in CPAN. I am sure the publish a list of all their modules, how come that list can not just exist in MacPorts, and we can simply issue something like `sudo port install cpan- foo::bar::baz and have MacPorts do the rest. For items that would not build right away, or if someone wants something tried, true, and tested, there could be a full port file. I don't recall anyone having discussed such an idea before, so that's probably one reason why it hasn't been done. We could have that discussion now. One problem with this approach is that of the version number. MacPorts ports are always of a particular version -- one which has been tested by its maintainer, or at least, by someone. When a new version is released, someone tests it and updates the port. The new version may have new bugs the committer didn't see, the new version may not even compile for everyone, but at least it was tested in some way, presumably on a Mac, by somebody. If you just make MacPorts a conduit to CPAN, there would be no testing of those modules by a MacPorts user at all. Consider also how MacPorts works: there is a directory of portfiles, and a portindex file that lists them all. port install consults the index to know if the port exists. port outdated consults the index to know if your ports are outdated. If there are no portfiles for CPAN modules, how would they appear in the index? If they're not in the index, how would port outdated work? Would we have a separate index for CPAN modules? I'm sure there are several more issues to consider; those are just off the top of my head. And of course again they're not limited to Perl modules from CPAN. One could also consider how this could apply to PHP modules from PEAR and PECL, Ruby gems, Octave packages, etc. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: p5 modules, get me started on one
On Tue, Jan 20, 2009 at 05:50:23PM -0800, Scott Haneda said: On Jan 20, 2009, at 5:01 PM, Bryan Blackburn wrote: [...] Some perl modules come packaged in groups like that, which definitely can cause confusion. Maybe the best solution would be to list all actual modules installed with the given port? Then it may be easier to search for it. List it in the port description? Will that get searched? How do I even get a list of what is in these packages from the CPAN site? In the long_description is what I was pondering; if you're running MacPorts 1.7 'port search' will look in (among other field) long_description by default, with trunk you'd need to add the --long_description flag to search it. Anything more specific to perl modules would mean changing base and of course deciding first how that would work, etc... [...] The base perl5.8 port should actually have what's in libnet like Net::SMTP, so no port should actually be needed for this one. How would I know that? port search smtp All I see is p5-net-smtp_auth @0.08 (perl) Perl5 SMTP client with AUTHentication If that is it, great, but how would I confirm it is in fact the same thing? All signs point to it being different. In many cases, a person running 'port install ...' is probably more interested in some final program and not just perl modules, so that's where the dependency management comes into play. This way various port maintainers only need to determine the which/where question the one time for these things and anyone else just lets port take it from there. If you're one of those maintainers, then it definitely helps to know the software you're dealing with. In perl's case, what I've done in the past is to query search.cpan.org for the specific module, which leads you to either a distribution specific to that module or one that includes several modules. From that you'd just create the port and be done with it. Also, knowing that Net::SMTP is with the base perl5.8 port is something I just knew because it's part of the perl libnet stuff which was integrated into perl core some time ago. Beginning to dislike perl and I have not written more than 100 lines of it in my life :) One advantage is the massive amount of modules already written to reduce the amount of work you have to do; one disadvantage is all of the massive amount of modules one must wade through to determine what you might actually need. Of course using CPAN makes that easier but then that installs outside of port, which means you can't depend on it for other ports or use uninstall/activate/deactivate to manage it, etc. I guess what I'm trying to say is, if there's an easy answer, I haven't heard it. Bryan -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
On Jan 21, 2009, at 1:09 AM, Ryan Schmidt wrote: On Jan 21, 2009, at 02:35, Scott Haneda wrote: I need Tie::RDBM If someone can tell me anything wrong I am doing, or better ways, I would be able to provide more ports back to MacPorts. `port search p5-tie` 4 results, none of which appear to be what I want. What are the possibilities Tie::RDBM is contained within one of the 4 results macports found? The answer to that should be 0. If it is not, I am searching wrong and would like to know how to correctly search. If I am searching correctly, there needs to be a standard way to resolve this where the contents of a module are put into the port file so it can be searched and found. I have a feeling the answer is not 0. That being the case, I would like to suggest no port be approved until this qualification for search is met. ports may have 5000+ port files, but with this issue solved, it could appear to have many many more. I'm not sure this issue is limited to Perl modules. What if a user knows that they want the program mogrify, but they do not know what software package provides it? port search mogrify does not tell you. You have to already know that it's provided by ImageMagick. MacPorts at this time seems to assume that the user either already knows what software package they want to install, or that they can find it using keywords from the description. It might be nice to let the user search by what files are in the port. port contents tells you what's in a port, but only if it's already installed, which isn't very helpful if you're trying to figure out which port to install. Problem is the list of files in a port is not known to MacPorts until the port is installed. This could be more easily done if we had binary packages, but that is a long way off. There are also the occasional ports that install different files on different systems; one would have to take care that all possible files are included in the search. Wow, `port contents` is pretty damn handy. I see your points. However, and maybe it is just me looking at this from the perspective of a user who does not know much about this, much like me... How did I get here? I want to make an ASSP port, so I downloaded it, I learned it is a pretty simple port. In all reality, it may not even need a port, it works fine with Apple's perl, and it is nothing more than a copy of some files and a single command to get it up and running. In this case, a port my be total overkill for ASSP. But... ASSP needs about 15 perl modules to work, and maybe even 20 or so if you want anti-virus. This led me here. I wanted to make a port since my past experience with php and mysql here was pretty nice. I thought I would give back and also to my own gain. There is CPAN, and what is troublesome about all this, is the ASSP distro has a simple install file you can run, and it runs down the CPAN tree and gets what it needs. I have always been wary of CPAN, since I am under the impression it hooks into the Apple perl, and for an email server proxy, the last thing I need is for Apple to break my kit. I guess there is Fink, but somewhere I also got the impression MacPorts was sort of the new Fink. ASSP lists the perl modules I need. I am not sure why the developer lists them out as sub modules, if you can not get to them without getting the entire master module as well. He seems to know what he is doing, so I would guess many other developers just list the one module they are using, rather than the entire package. I, as a end user of MacPorts, got pretty hung up on this. If I wanted to use ASSP, I would just download it, and if I wanted to hand install the modules it needs via CPAN, I just copy and paste the list out of the ASSP notes. In MacPorts, I can not do that. I have to google the port ASSP wants, look to see if it is in MacPorts, if not, google again for the main package the module may be contained in, then see if MacPorts knows about that. If not, I can then think about making a port file. How is CPAN solving this? Even if there is no master list of files, so we could get to the result of `port contents` ahead of time, their site seems so structured it would should not be too hard to get to that list. I just do not know enough about this, and I am not really looking for an answer from you, but more just to relay my experience so you may take it under consideration. This will be a gross simplification, but take LWP::Simple, if I need that, I learn it is inside libwww-perl... Gisle Aas libwww-perl-5.823 LWP::Simple That is just a copy and paste of the breadcrumbs from their cpan site. While it would be a mess, just backing up one on the breadcrumb gets you where you need to be. I am not saying to html scrape the site, but you get what I mean. The process is a burden, there has to be a way to solve this
Re: p5 modules, get me started on one
On Jan 21, 2009, at 1:40 AM, Bryan Blackburn wrote: On Tue, Jan 20, 2009 at 05:50:23PM -0800, Scott Haneda said: On Jan 20, 2009, at 5:01 PM, Bryan Blackburn wrote: [...] Some perl modules come packaged in groups like that, which definitely can cause confusion. Maybe the best solution would be to list all actual modules installed with the given port? Then it may be easier to search for it. List it in the port description? Will that get searched? How do I even get a list of what is in these packages from the CPAN site? In the long_description is what I was pondering; if you're running MacPorts 1.7 'port search' will look in (among other field) long_description by default, with trunk you'd need to add the --long_description flag to search it. Anything more specific to perl modules would mean changing base and of course deciding first how that would work, etc... Nice to know, thanks, I was not aware of --long_description Seems an ok way to deal with it, not ideal to me though. I am not sure if this problem is just perl module related, or is more generic. If it would be appropriate, the idea of adding a new variable to port files may be a fair idea. file_contains or whatever is appropriate, which could then be searched on by default. It seems very common that this comes up. [...] The base perl5.8 port should actually have what's in libnet like Net::SMTP, so no port should actually be needed for this one. How would I know that? port search smtp All I see is p5-net-smtp_auth @0.08 (perl) Perl5 SMTP client with AUTHentication If that is it, great, but how would I confirm it is in fact the same thing? All signs point to it being different. In many cases, a person running 'port install ...' is probably more interested in some final program and not just perl modules, so that's where the dependency management comes into play. This way various port maintainers only need to determine the which/where question the one time for these things and anyone else just lets port take it from there. Correct, and the more I think about it, the more I may be looking at this wrong. My end game here is to get ASSP ported. I need 20 or so perl modules to go with it, but once I get those, and build the dependency tree in the ASSP port file, no other user will ever care about the issues I am currently running into. If you're one of those maintainers, then it definitely helps to know the software you're dealing with. In perl's case, what I've done in the past is to query search.cpan.org for the specific module, which leads you to either a distribution specific to that module or one that includes several modules. That is exactly where I have been spending my time as well. To be honest, I just wish the developer of ASSP had listed the parent perl module rather then the submodule, it would have made this seem a heck of a lot easier. From that you'd just create the port and be done with it. Also, knowing that Net::SMTP is with the base perl5.8 port is something I just knew because it's part of the perl libnet stuff which was integrated into perl core some time ago. And that there is the main major problem with this. While not with Net::SMTP, but other perl modules, this bit me. I need net:foo and did not find it, so I made a port. I later learned net:foo was already in net:main so I wasted my time making the port. In this case, these ports are mostly copy and paste, so not a big deal, but it could have been a larger waste of time. This is the main thing I think needs solving, and it sounds like it can, with better search, a new field in the port file, and or automatic retrieval of some perl module index file that has some mappings in it. It may take all those suggestions, I am not sure. The question of How does a new user know that Net::SMTP is part of the base? is a problem. Beginning to dislike perl and I have not written more than 100 lines of it in my life :) One advantage is the massive amount of modules already written to reduce the amount of work you have to do; one disadvantage is all of the massive amount of modules one must wade through to determine what you might actually need. Of course using CPAN makes that easier but then that installs outside of port, which means you can't depend on it for other ports or use uninstall/activate/deactivate to manage it, etc. Also, is it still true than CPAN can get clobbered by Apple Updates? This is one of the best selling points of MacPorts. I guess what I'm trying to say is, if there's an easy answer, I haven't heard it. Rarely is it easy :) Curious, without going into a lot of detail, how does the hugely raves about apt-get and equivalent get past all this? -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org
Re: Understanding what I am calling the mess that is perl modules
Scott Haneda wrote: I actually do not even understand why a port has to be made for anything in CPAN. I am sure the publish a list of all their modules, how come that list can not just exist in MacPorts, and we can simply issue something like `sudo port install cpan-foo::bar::baz and have MacPorts do the rest. For items that would not build right away, or if someone wants something tried, true, and tested, there could be a full port file. There is cpan2port written by Marc [1] which is meant to create Portfiles from CPAN. It is new and I don't know if it works in all cases, so any help from someone with a Perl background would be appreciated. This should also be moved to our contrib section [2] and then made available as a port so it's easier to use for Portfile authors. Rainer [1] http://lists.macosforge.org/pipermail/macports-users/2008-November/012298.html [2] http://svn.macports.org/repository/macports/contrib/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
Citando Ryan Schmidt : On Jan 21, 2009, at 02:35, Scott Haneda wrote: I actually do not even understand why a port has to be made for anything in CPAN. I am sure the publish a list of all their modules, how come that list can not just exist in MacPorts, and we can simply issue something like `sudo port install cpan-foo::bar::baz and have MacPorts do the rest. For items that would not build right away, or if someone wants something tried, true, and tested, there could be a full port file. I don't recall anyone having discussed such an idea before, so that's probably one reason why it hasn't been done. We could have that discussion now. There was an attempt at that: cpan2port [http://www.nabble.com/announce:-cpan2port-td20415884.html]. I don't know what is its current status, but that's a nice thing. If it was also possible to have this for python eggs, ruby gems, ctan, etc. However, debian has had such a tool for a long time, other package managers also have. Concerning the possibility to search for which port I should install to get which command, I usually try google with the name of the thing I want to get and debian. It usually gives me the name of the debian package which is usually easily translatable into macports' naming. Once more however, debian, pkgsrc and probably other ones provide a way to search for the files provided by a package. In debian, as they make binary packages, it is simple. In pkgsrc, it relies on their build in a sandbox which only uses the specified dependencies (not anything from /usr/local or /usr if it is not explicitly said in the Makefile) and hence builds exactly the same on machines with different things installed. Is macports bound to reinvent wheels over and over? Best, milosh signature.asc Description: Digital signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Can not get Net::SysLog installed
Can someone tell me where I am going wrong with this port? Creating software index in /Users/me/macports Adding port perl/p5-file-readbackwards Adding port perl/p5-mail-spf Adding port perl/p5-mail-spf-query Adding port perl/p5-mail-srs Adding port perl/p5-net-cidr-lite Adding port perl/p5-net-ip-match-regexp Adding port perl/p5-net-senderbase Adding port perl/p5-net-syslog Adding port perl/p5-tie-dbi Total number of ports parsed: 9 Ports successfully parsed: 9 Ports failed: 0 /Users/me/macports/perl/p5-net-syslog cat Portfile # $Id$ PortSystem 1.0 PortGroup perl5 1.0 perl5.setup net-syslog 0.03 maintainers hostwizard.com:scott description Net::Syslog - Perl extension for sending syslog messages directly to a remote syslogd. long_descriptionNet::Syslog implements the intra-host syslog forwarding \ protocol. It is not intended to replace the Sys::Syslog \ or Unix::Syslog modules, but instead to provide a method \ of using syslog when a local syslogd is unavailable or \ when you don't want to write syslog messages to the \ local syslog homepage http://search.cpan.org/~lhoward/Net-Syslog-0.03/Syslog.pm checksums md5 0201f8ac355c6509e8f232179f0a54fd \ sha18b633f4f51540eb94240157e7c7683658ed4461b \ rmd160 309b3d18afc6ddbfb0eba4a1aaba5b6aa0c45397 platforms darwin * I am in this ports dir /Users/me/macports/perl/p5-net-syslog Below is lint, clean, and isntall.. ---***--***--***--***--***--***--***--- $sudo port lint --- Verifying Portfile for p5-net-syslog --- 0 errors and 0 warnings found. ---***--***--***--***--***--***--***--- $sudo port -d clean DEBUG: Changing to port directory: /Users/me/macports/perl/p5-net-syslog DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Using group file /opt/local/var/macports/sources/ rsync.macports.org/release/ports/_resources/port1.0/group/perl5-1.0.tcl DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port p5-net-syslog. DEBUG: Requested variant i386 is not provided by port p5-net-syslog. DEBUG: Requested variant macosx is not provided by port p5-net-syslog. DEBUG: Changing to port directory: /Users/me/macports/perl/p5-net-syslog DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Using group file /opt/local/var/macports/sources/ rsync.macports.org/release/ports/_resources/port1.0/group/perl5-1.0.tcl DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port p5-net-syslog. DEBUG: Requested variant i386 is not provided by port p5-net-syslog. DEBUG: Requested variant macosx is not provided by port p5-net-syslog. DEBUG: Executing org.macports.main (p5-net-syslog) --- Cleaning p5-net-syslog DEBUG: Executing org.macports.clean (p5-net-syslog) --- Removing build directory for p5-net-syslog DEBUG: Removing directory: /opt/local/var/macports/build/ _Users_me_macports_perl_p5-net-syslog DEBUG: delete: /opt/local/var/macports/build/ _Users_me_macports_perl_p5-net-syslog DEBUG: Removing symlink: /Users/me/macports/perl/p5-net-syslog/work DEBUG: delete: /Users/me/macports/perl/p5-net-syslog/work ---***--***--***--***--***--***--***--- $sudo port -d install DEBUG: Changing to port directory: /Users/me/macports/perl/p5-net-syslog DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: Using group file /opt/local/var/macports/sources/ rsync.macports.org/release/ports/_resources/port1.0/group/perl5-1.0.tcl DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port p5-net-syslog. DEBUG: Requested variant i386 is not provided by port p5-net-syslog. DEBUG: Requested variant macosx is not provided by port p5-net-syslog. DEBUG: Changing to port directory: /Users/me/macports/perl/p5-net-syslog DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target
Re: Understanding what I am calling the mess that is perl modules
Rainer Müller wrote: Scott Haneda wrote: I actually do not even understand why a port has to be made for anything in CPAN. I am sure the publish a list of all their modules, how come that list can not just exist in MacPorts, and we can simply issue something like `sudo port install cpan-foo::bar::baz and have MacPorts do the rest. For items that would not build right away, or if someone wants something tried, true, and tested, there could be a full port file. There is cpan2port written by Marc [1] which is meant to create Portfiles from CPAN. It is new and I don't know if it works in all cases, so any help from someone with a Perl background would be appreciated. This should also be moved to our contrib section [2] and then made available as a port so it's easier to use for Portfile authors. Rainer [1] http://lists.macosforge.org/pipermail/macports-users/2008-November/012298.html [2] http://svn.macports.org/repository/macports/contrib/ Integrating something like cpan2port more directly into MacPorts as Scott described would be a neat project. There a bunch of implementation and UI issues, but I don't think they're insurmountable. As usual, it hasn't been done yet simply because nobody has had the time and motivation to do it. And of course cpan2port is a great first step. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can not get Net::SysLog installed
Scott Haneda wrote: Can someone tell me where I am going wrong with this port? perl5.setup net-syslog 0.03 You've used the wrong case here. Also the checksums are wrong. :-) - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can not get Net::SysLog installed
On Jan 21, 2009, at 3:47 AM, Joshua Root wrote: Scott Haneda wrote: Can someone tell me where I am going wrong with this port? perl5.setup net-syslog 0.03 You've used the wrong case here. Also the checksums are wrong. :-) Strange, I have never bothered with case since OS X is non case, I assume this is failing on the download, since the case is wrong? I will go fiddle it and see what happens. Thanks. -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can not get Net::SysLog installed
Scott Haneda wrote: On Jan 21, 2009, at 3:47 AM, Joshua Root wrote: Scott Haneda wrote: Can someone tell me where I am going wrong with this port? perl5.setup net-syslog 0.03 You've used the wrong case here. Also the checksums are wrong. :-) Ok, got it to work, but I had a empty download file and a messed up TMP file. I deleted them in the Finder and all was well. They were at /opt/local/var/macports/distfiles/perl5/ What is the port command to clean those out? I tried sudo port uninstall and sudo port clean and neither worked for me. Clean can take some options, see the port man page. `sudo port clean --dist` will delete the distfile. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
On Jan 21, 2009, at 4:27 AM, Scott Haneda wrote: On Jan 21, 2009, at 3:19 AM, Emmanuel Hainry wrote: There was an attempt at that: cpan2port [http://www.nabble.com/announce:-cpan2port-td20415884.html]. I don't know what is its current status, but that's a nice thing. If it was also possible to have this for python eggs, ruby gems, ctan, etc. However, debian has had such a tool for a long time, other package managers also have. Cool, thanks. I downloaded it, and moved it to ~/bin which is in my path. When I run it with no arguments to get to help for it, I get errors, which reference macports, which I should not, since I am using the built in perl in OS X. $whereis perl /usr/bin/perl I think I am sort of seeing what is going on here. perl -V is using the macports version for some reason. would think that `perl` needs to continue to use the OS X perl, and that I would need to call out the /opt/local/bin/perl when I want to use the MacPorts one. I came to this conclusion since when making a port, one of the main things the port does, is read in files and do a find and replace on the built in perl and stuff in /opt/local/bin/perl. If that is the case, then it has to be my .bashrc file that is messing with the proper behavior. I have the usual export PATH=$PATH:$HOME/bin And I added in # For MacPorts export PATH=/opt/local/bin:/opt/local/sbin:$PATH export DISPLAY=:0.0 export EDITOR=/usr/bin/mate I had to ditch the pre-installed .profile since it did not work for me. Maybe I should have referenced it from this file. How do I tell the shell to use a certain order on where perl is located, or is that the wrong way to solve this? Also, is there any way for EDITOR to be dynamic, so that when I am on the actual machine I want to use mate as my editor, but if I am over ssh, I want to use a terminal based editor. Is that just a matter of wrapping the default in a condition that checks where I am at? -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
On Jan 21, 2009, at 06:34, Scott Haneda wrote: On Jan 21, 2009, at 4:27 AM, Scott Haneda wrote: On Jan 21, 2009, at 3:19 AM, Emmanuel Hainry wrote: There was an attempt at that: cpan2port [http://www.nabble.com/announce:-cpan2port-td20415884.html]. I don't know what is its current status, but that's a nice thing. If it was also possible to have this for python eggs, ruby gems, ctan, etc. However, debian has had such a tool for a long time, other package managers also have. Cool, thanks. I downloaded it, and moved it to ~/bin which is in my path. When I run it with no arguments to get to help for it, I get errors, which reference macports, which I should not, since I am using the built in perl in OS X. $whereis perl /usr/bin/perl I think I am sort of seeing what is going on here. perl -V is using the macports version for some reason. would think that `perl` needs to continue to use the OS X perl, and that I would need to call out the /opt/local/bin/perl when I want to use the MacPorts one. If you list /opt/local/bin first in your path, before /usr/bin, then sure, MacPorts perl will be used (in your Terminal) in preference to Apple perl. Same for any other program that exists in both locations. That's the whole reason we recommend putting (and set up for you, in the default .profile) /opt/local/bin first in the path -- so that you get MacPorts versions where available, since they are usually newer. I came to this conclusion since when making a port, one of the main things the port does, is read in files and do a find and replace on the built in perl and stuff in /opt/local/bin/perl. If that is the case, then it has to be my .bashrc file that is messing with the proper behavior. I have the usual export PATH=$PATH:$HOME/bin And I added in # For MacPorts export PATH=/opt/local/bin:/opt/local/sbin:$PATH export DISPLAY=:0.0 export EDITOR=/usr/bin/mate I had to ditch the pre-installed .profile since it did not work for me. Maybe I should have referenced it from this file. How do I tell the shell to use a certain order on where perl is located, or is that the wrong way to solve this? The shell searches for binaries in the paths in PATH and runs it in the first path where it's found. Also, is there any way for EDITOR to be dynamic, so that when I am on the actual machine I want to use mate as my editor, but if I am over ssh, I want to use a terminal based editor. Is that just a matter of wrapping the default in a condition that checks where I am at? I would also be interested in knowing how to set that up. I've wanted this many times but never really looked into what I would need to do. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mesa
On Wed, Jan 21, 2009 at 2:49 AM, Jeremy Huddleston jeremyhu-at-macports.orgwrote: Should be fixed in r45750 On Jan 20, 2009, at 23:26, Ryan Schmidt wrote: Frank J. R. Hanstick wrote: Oops. Forgot xcode and MacPorts: 2.5 and 1.7.0 respectively. Ok, and based on other output you sent, running Mac OS X 10.4 on a PowerPC Mac. http://trac.macports.org/ticket/17995 After a selfupdate and cleaning mesa, the problem in #17995 no longer occurs, but it can't find the command makedepend: DEBUG: Assembled command: 'cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_mesa/work/Mesa-7.2 nice -n 10 make default INSTALL_DIR=/opt/local X11_DIR=/opt/local' Making sources for darwin touch depend makedepend -fdepend -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi glcontextmodes.c clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c indirect_size.c indirect_window_pos.c indirect_texture_compressi on.c indirect_transpose_matrix.c indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c \ ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/glapi.c ../../../src/mesa/glapi/glthread.c make[2]: makedepend: Command not found make[2]: *** [depend] Error 127 make[1]: *** [subdirs] Error 1 make: *** [default] Error 1 [also Xcode 2.5 and OS X 10.4 on PPC but a newer Trunk MacPorts] -- Joel Thibault [AIM: Jole Tebo] Software Engineer in Boston ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mesa
Joel Thibault (MacPorts) wrote: On Wed, Jan 21, 2009 at 2:49 AM, Jeremy Huddleston jeremyhu-at-macports.org http://jeremyhu-at-macports.org wrote: Should be fixed in r45750 On Jan 20, 2009, at 23:26, Ryan Schmidt wrote: Frank J. R. Hanstick wrote: Oops. Forgot xcode and MacPorts: 2.5 and 1.7.0 respectively. Ok, and based on other output you sent, running Mac OS X 10.4 on a PowerPC Mac. http://trac.macports.org/ticket/17995 After a selfupdate and cleaning mesa, the problem in #17995 no longer occurs, but it can't find the command makedepend: DEBUG: Assembled command: 'cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_mesa/work/Mesa-7.2 nice -n 10 make default INSTALL_DIR=/opt/local X11_DIR=/opt/local' Making sources for darwin touch depend makedepend -fdepend -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi glcontextmodes.c clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c indirect_size.c indirect_window_pos.c indirect_texture_compressi on.c indirect_transpose_matrix.c indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c \ ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/glapi.c ../../../src/mesa/glapi/glthread.c make[2]: makedepend: Command not found make[2]: *** [depend] Error 127 make[1]: *** [subdirs] Error 1 make: *** [default] Error 1 [also Xcode 2.5 and OS X 10.4 on PPC but a newer Trunk MacPorts] -- Joel Thibault [AIM: Jole Tebo] Software Engineer in Boston See also http://trac.macports.org/ticket/18132 http://trac.macports.org/ticket/17995 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Postfix and cyrus in Macports bind to different saslauthd
Hi there, I am experimenting an extrange behaviour with saslauthd daemons. Macports port of Postfix seems to need Apple's builtin saslauthd daemon but Macports port of Cyrus needs macports version of saslauthd. I guess this is not normal... I don't mind using any of the versions of saslauthd as I don't need a special auth mech; just rimap which is built in both, but whould like to use just one of them. Now I have both saslauthd started. mux files ar in /opt/local/var/state/saslauthd/mux and /var/state/saslauthd/mux Anybody knows how can y make Macports ports of postfix or Cyrus Imaps use one or the other saslauthd daemons? Thanks, Ignacio -- View this message in context: http://www.nabble.com/Postfix-and-cyrus-in-Macports-bind-to-different-saslauthd-tp21588754p21588754.html Sent from the MacPorts - Users mailing list archive at Nabble.com. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
On Jan 21, 2009, at 4:46 AM, Ryan Schmidt wrote: Also, is there any way for EDITOR to be dynamic, so that when I am on the actual machine I want to use mate as my editor, but if I am over ssh, I want to use a terminal based editor. Is that just a matter of wrapping the default in a condition that checks where I am at? I would also be interested in knowing how to set that up. I've wanted this many times but never really looked into what I would need to do. This seems to work for me: if [[ -z $SSH_CLIENT ]]; then export EDITOR=/Users/me/bin/mate else export EDITOR=/usr/bin/pico fi; -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Understanding what I am calling the mess that is perl modules
On Jan 21, 2009, at 4:46 AM, Ryan Schmidt wrote: On Jan 21, 2009, at 06:34, Scott me wrote: On Jan 21, 2009, at 4:27 AM, Scott me wrote: On Jan 21, 2009, at 3:19 AM, Emmanuel Hainry wrote: There was an attempt at that: cpan2port [http://www.nabble.com/announce:-cpan2port-td20415884.html]. I don't know what is its current status, but that's a nice thing. If it was also possible to have this for python eggs, ruby gems, ctan, etc. However, debian has had such a tool for a long time, other package managers also have. Cool, thanks. I downloaded it, and moved it to ~/bin which is in my path. When I run it with no arguments to get to help for it, I get errors, which reference macports, which I should not, since I am using the built in perl in OS X. $whereis perl /usr/bin/perl I think I am sort of seeing what is going on here. perl -V is using the macports version for some reason. would think that `perl` needs to continue to use the OS X perl, and that I would need to call out the /opt/local/bin/perl when I want to use the MacPorts one. If you list /opt/local/bin first in your path, before /usr/bin, then sure, MacPorts perl will be used (in your Terminal) in preference to Apple perl. Same for any other program that exists in both locations. That's the whole reason we recommend putting (and set up for you, in the default .profile) /opt/local/bin first in the path -- so that you get MacPorts versions where available, since they are usually newer. Duh, sorry, I do not know why I did not see that. I was just looking at order of definition of the PATH, not the actual order inside each path. I have a new echo'd out path of /usr/bin:/bin:/usr/sbin:/sbin:/Users/me:/usr/local/bin:/usr/X11/bin:/ Users/me/bin:/opt/local/bin:/opt/local/sbin perl -V is now showing what I want /System/Library/Perl/5.8.8/darwin-thread-multi-2level /System/Library/Perl/5.8.8 /Library/Perl/5.8.8/darwin-thread-multi-2level /Library/Perl/5.8.8 /Library/Perl /Network/Library/Perl/5.8.8/darwin-thread-multi-2level /Network/Library/Perl/5.8.8 /Network/Library/Perl /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 Thanks for all the help on this one. -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mesa
Hello, After performing the selfupdate, clean mesa, and -d install mesa, I got the following error: Making sources for darwin touch depend makedepend -fdepend -I. -I../../../include -I../../../include/GL/ internal -I../../../src/mesa/main -I../../../src/mesa/glapi glcontextmodes.c clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c indirect_size.c indirect_window_pos.c indirect_texture_compression.c indirect_transpose_matrix.c indirect_vertex_array.c indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c \ ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/ glapi.c ../../../src/mesa/glapi/glthread.c makedepend: warning: glcontextmodes.c, line 42: cannot find include file GL/glxint.h not in GL/glxint.h not in GL/glxint.h not in ./GL/glxint.h not in ../../../include/GL/glxint.h not in ../../../include/GL/internal/GL/glxint.h not in ../../../src/mesa/main/GL/glxint.h not in ../../../src/mesa/glapi/GL/glxint.h not in /usr/local/lib/gcc-include/GL/glxint.h not in /usr/include/GL/glxint.h not in /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/GL/ glxint.h makedepend: warning: clientattrib.c (reading glxclient.h, line 53): cannot find include file GL/glxint.h not in GL/glxint.h not in GL/glxint.h not in ./GL/glxint.h not in ../../../include/GL/glxint.h not in ../../../include/GL/internal/GL/glxint.h not in ../../../src/mesa/main/GL/glxint.h not in ../../../src/mesa/glapi/GL/glxint.h not in /usr/local/lib/gcc-include/GL/glxint.h not in /usr/include/GL/glxint.h not in /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/GL/ glxint.h makedepend: warning: clientattrib.c (reading glxclient.h, line 54): cannot find include file GL/glxproto.h not in GL/glxproto.h not in GL/glxproto.h not in ./GL/glxproto.h not in ../../../include/GL/glxproto.h not in ../../../include/GL/internal/GL/glxproto.h not in ../../../src/mesa/main/GL/glxproto.h not in ../../../src/mesa/glapi/GL/glxproto.h not in /usr/local/lib/gcc-include/GL/glxproto.h not in /usr/include/GL/glxproto.h not in /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/GL/ glxproto.h makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 74 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 79 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 80 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 81 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 82 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 83 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 85 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 86 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 87 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 88 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 89 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 147 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 153 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 157 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 162 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 167 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 172 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 177 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 211 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 216 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 221 makedepend: warning: /usr/include/architecture/ppc/math.h: non- portable whitespace encountered at line 226 makedepend: warning:
ASSP port testing, not getting all perl mods to work
Hello, this may be getting a little outside the scope of what this list can help me with. Hopefully we can solve it so I can actually get my email server where I want. I downloaded the ASSP package http://superb-east.dl.sourceforge.net/sourceforge/assp/ASSP_1.4.3.1-Install.zip The notes say I need some modules, which I managed to port install or make a port to get them installed. Here is the list from their README as to what I need http://pastebin.com/f692f61e3 Here is a list from `port installed` http://pastebin.com/f564a902e In short, all I need to get it working is to cd into the ASSP directory, and run `perl assp.pl` which will start it as a server, and give me a report to the console, as well as a log, telling me what is going on. Looking over their files, I can see they are referencing a local perl location, which will not work, so I do a global find and replace to repair that. I am near certain for MacPorts I need to use /opt/local/ bin/perl #!/usr/bin/perl - #!/opt/local/bin/perl I am pretty sure, according to the old outdated ASSP port, this is all it is doing. The old port makes some new users and groups, but I do not think that is related, nor needed anymore. cd /Users/me/Downloads/ASSP_1.4.3.1-Install/ASSP sudo perl assp.pl It starts, and most of my efforts worked out, however, there are a few that do not. Here is the result of the log file: http://pastebin.com/f539150d2 Most of the errors are because it is a new install, but there are a few I am lost on: Jan-21-09 12:27:32 Email::Valid module not installed Jan-21-09 12:27:32 Mail::SPF module not installed *Jan-21-09 12:27:32 Tie::RDBM module not installed - mysql usage not available * Tie:RDBM may simply fail because I do not have MySql installed at this point, however, I am pretty sure it should still show as installed. port contents p5-email-valid Port p5-email-valid contains: /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Email/ Valid/.packlist /opt/local/lib/perl5/vendor_perl/5.8.9/Email/Valid.pm /opt/local/share/man/man3/Email::Valid.3pm.gz port contents p5-mail-spf Port p5-mail-spf contains: /opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Mail/ SPF/.packlist /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Base.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Exception.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/MacroString.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/A.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/All.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Exists.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Include.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP4.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP6.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/MX.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/PTR.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Exp.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Redirect.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Record.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Request.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Result.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/SenderIPAddrMech.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Server.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Term.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Util.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/v1/Record.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/v2/Record.pm /opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF.pm /opt/local/share/man/man3/Mail::SPF.3pm.gz /opt/local/share/man/man3/Mail::SPF::Base.3pm.gz /opt/local/share/man/man3/Mail::SPF::MacroString.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::A.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::All.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::Exists.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::Include.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::IP4.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::IP6.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::MX.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mech::PTR.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mod.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mod::Exp.3pm.gz /opt/local/share/man/man3/Mail::SPF::Mod::Redirect.3pm.gz /opt/local/share/man/man3/Mail::SPF::Record.3pm.gz /opt/local/share/man/man3/Mail::SPF::Request.3pm.gz /opt/local/share/man/man3/Mail::SPF::Result.3pm.gz /opt/local/share/man/man3/Mail::SPF::SenderIPAddrMech.3pm.gz /opt/local/share/man/man3/Mail::SPF::Server.3pm.gz /opt/local/share/man/man3/Mail::SPF::Term.3pm.gz /opt/local/share/man/man3/Mail::SPF::Util.3pm.gz
Re: ASSP port testing, not getting all perl mods to work
I think I may have found some of the problem, from the email::valid
docs:
If you installed the module into an alternative directory, you will
need to let Perl know where it can be found: use
lib /path/to/my/modules;
use Email::Valid;
I made a test case
use Email::Valid;
print (Email::Valid-address('maur...@hevanet.com') ? '\nyes' : '\nno');
If I run that as
perl filename
I get errors Can't locate Email/Valid.pm
If I run it as
/opt/local/bin/perl filename
It works
So I now know it works, and is in stalled, but why does ASSP not see
it. I think I am going to have to patch the ASSP files, would that be
the correct method? I am also contacting the developer.
On Jan 21, 2009, at 12:40 PM, Scott Haneda wrote:
Hello, this may be getting a little outside the scope of what this
list can help me with. Hopefully we can solve it so I can actually
get my email server where I want.
I downloaded the ASSP package
http://superb-east.dl.sourceforge.net/sourceforge/assp/ASSP_1.4.3.1-Install.zip
The notes say I need some modules, which I managed to port install
or make a port to get them installed.
Here is the list from their README as to what I need
http://pastebin.com/f692f61e3
Here is a list from `port installed`
http://pastebin.com/f564a902e
In short, all I need to get it working is to cd into the ASSP
directory, and run `perl assp.pl` which will start it as a server,
and give me a report to the console, as well as a log, telling me
what is going on.
Looking over their files, I can see they are referencing a local
perl location, which will not work, so I do a global find and
replace to repair that. I am near certain for MacPorts I need to
use /opt/local/bin/perl
#!/usr/bin/perl - #!/opt/local/bin/perl
I am pretty sure, according to the old outdated ASSP port, this is
all it is doing. The old port makes some new users and groups, but
I do not think that is related, nor needed anymore.
cd /Users/me/Downloads/ASSP_1.4.3.1-Install/ASSP
sudo perl assp.pl
It starts, and most of my efforts worked out, however, there are a
few that do not. Here is the result of the log file:
http://pastebin.com/f539150d2
Most of the errors are because it is a new install, but there are a
few I am lost on:
Jan-21-09 12:27:32 Email::Valid module not installed
Jan-21-09 12:27:32 Mail::SPF module not installed
*Jan-21-09 12:27:32 Tie::RDBM module not installed - mysql usage not
available
* Tie:RDBM may simply fail because I do not have MySql installed at
this point, however, I am pretty sure it should still show as
installed.
port contents p5-email-valid
Port p5-email-valid contains:
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Email/
Valid/.packlist
/opt/local/lib/perl5/vendor_perl/5.8.9/Email/Valid.pm
/opt/local/share/man/man3/Email::Valid.3pm.gz
port contents p5-mail-spf
Port p5-mail-spf contains:
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Mail/
SPF/.packlist
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Base.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Exception.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/MacroString.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/A.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/All.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Exists.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Include.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP4.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP6.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/MX.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/PTR.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Exp.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Redirect.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Record.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Request.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Result.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/SenderIPAddrMech.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Server.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Term.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Util.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/v1/Record.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/v2/Record.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF.pm
/opt/local/share/man/man3/Mail::SPF.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Base.3pm.gz
/opt/local/share/man/man3/Mail::SPF::MacroString.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Mech.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Mech::A.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Mech::All.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Mech::Exists.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Mech::Include.3pm.gz
/opt/local/share/man/man3/Mail::SPF::Mech::IP4.3pm.gz
Re: Understanding what I am calling the mess that is perl modules
On 2009-01-21 08:04:16 -0500, Kurt Hillig wrote: If you always use ssh for remote logins then you can test for the existence of the SSH_CLIENT environment variable. It doesn't exist when you're logged in locally. You need to be a bit smarter: the SSH_CLIENT environment variable isn't necessarily meaningful. 1. Start the screen utility locally. 2. From a remote machine, ssh to the Mac OS X machine. 3. Recall the screen session. 4. Start the editor from it. As SSH_CLIENT is not defined (because the screen session has been started locally), the editor will open on the wrong physical screen! If you want to have an idea of what can be done, see http://www.vinc17.org/mutt/index.en.html#smutt I run Mutt in screen from my Mac OS X machine, which I can use remotely by ssh (typically, a Linux machine). And my editor (Emacs) opens its own window (on the Mac OS X screen) *only* when I've recalled the screen session from the Mac OS X machine. -- Vincent Lefèvre vinc...@vinc17.org - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: ASSP port testing, not getting all perl mods to work
Hello,
It sounds like opt/local is not the first location the path
environment looks for perl. This is a problem when several versions
of a program exists because unless a prefix is supplied, the default
program will always be found in the order of the pathname (first
detected). If perl exists in /opt/local/bin and /usr/bin and the
path is in the order of /usr/bin:/opt/local/bin, then without a
prefix, /usr/bin will always be the perl used and visa versa if path
is /opt/local/bin:/usr/bin. I ran into the same problem with gcc
located in two different locations.
Frank
On Jan 21, 2009, at 4:04 PM, Scott Haneda wrote:
I think I may have found some of the problem, from the email::valid
docs:
If you installed the module into an alternative directory, you will
need to let Perl know where it can be found: use
lib /path/to/my/modules;
use Email::Valid;
I made a test case
use Email::Valid;
print (Email::Valid-address('maur...@hevanet.com') ? '\nyes' :
'\nno');
If I run that as
perl filename
I get errors Can't locate Email/Valid.pm
If I run it as
/opt/local/bin/perl filename
It works
So I now know it works, and is in stalled, but why does ASSP not
see it. I think I am going to have to patch the ASSP files, would
that be the correct method? I am also contacting the developer.
On Jan 21, 2009, at 12:40 PM, Scott Haneda wrote:
Hello, this may be getting a little outside the scope of what this
list can help me with. Hopefully we can solve it so I can
actually get my email server where I want.
I downloaded the ASSP package
http://superb-east.dl.sourceforge.net/sourceforge/assp/
ASSP_1.4.3.1-Install.zip
The notes say I need some modules, which I managed to port install
or make a port to get them installed.
Here is the list from their README as to what I need
http://pastebin.com/f692f61e3
Here is a list from `port installed`
http://pastebin.com/f564a902e
In short, all I need to get it working is to cd into the ASSP
directory, and run `perl assp.pl` which will start it as a server,
and give me a report to the console, as well as a log, telling me
what is going on.
Looking over their files, I can see they are referencing a local
perl location, which will not work, so I do a global find and
replace to repair that. I am near certain for MacPorts I need to
use /opt/local/bin/perl
#!/usr/bin/perl - #!/opt/local/bin/perl
I am pretty sure, according to the old outdated ASSP port, this is
all it is doing. The old port makes some new users and groups,
but I do not think that is related, nor needed anymore.
cd /Users/me/Downloads/ASSP_1.4.3.1-Install/ASSP
sudo perl assp.pl
It starts, and most of my efforts worked out, however, there are a
few that do not. Here is the result of the log file:
http://pastebin.com/f539150d2
Most of the errors are because it is a new install, but there are
a few I am lost on:
Jan-21-09 12:27:32 Email::Valid module not installed
Jan-21-09 12:27:32 Mail::SPF module not installed
*Jan-21-09 12:27:32 Tie::RDBM module not installed - mysql usage
not available
* Tie:RDBM may simply fail because I do not have MySql installed
at this point, however, I am pretty sure it should still show as
installed.
port contents p5-email-valid
Port p5-email-valid contains:
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Email/
Valid/.packlist
/opt/local/lib/perl5/vendor_perl/5.8.9/Email/Valid.pm
/opt/local/share/man/man3/Email::Valid.3pm.gz
port contents p5-mail-spf
Port p5-mail-spf contains:
/opt/local/lib/perl5/vendor_perl/5.8.9/darwin-2level/auto/Mail/
SPF/.packlist
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Base.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Exception.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/MacroString.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/A.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/All.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Exists.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/Include.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP4.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/IP6.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/MX.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech/PTR.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mech.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Exp.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod/Redirect.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Mod.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Record.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Request.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Result.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/SenderIPAddrMech.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Server.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Term.pm
/opt/local/lib/perl5/vendor_perl/5.8.9/Mail/SPF/Util.pm
Re: ASSP port testing, not getting all perl mods to work
I am telling ASSP where the new perl is, this issue is that some modules, only three of 15 or more, are being looked for in the wrong spot. I do not know if I should solve this in the port, by editing the source of the app, or if there is some other way. I actually hope there is some other way, as there should be no reason why I need to modify the source other than to change the perl path at the top of a few files. On Jan 21, 2009, at 5:13 PM, Frank J. R. Hanstick wrote: Hello, It sounds like opt/local is not the first location the path environment looks for perl. This is a problem when several versions of a program exists because unless a prefix is supplied, the default program will always be found in the order of the pathname (first detected). If perl exists in /opt/local/bin and /usr/bin and the path is in the order of /usr/bin:/opt/local/bin, then without a prefix, /usr/bin will always be the perl used and visa versa if path is /opt/local/bin:/usr/bin. I ran into the same problem with gcc located in two different locations. Frank -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
requirement installed where the sun don't shine
Greetings, I've run into this problem a couple of times. The latest incident is with install of wine. It requires fontforge which I installed by hand in its default location of /usr/local/bin/ how do I impart that path to port? thanks, Tom K ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Universal Binaries
Hi Macports people! Two questions: 1. What is the current state of the +universal variant? Do most ports work? 2. How is dependencies and the +universal variants used? Meaning if I type sudo port install pan2 +universal will that pass the variant to all dependencies that get built before pan2? Thanks! Tim ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: ASSP port testing, not getting all perl mods to work
Hello, The problem I had with two gcc's was that one call to the gcc was done direct (gcc) instead of an indirect prefix variable [ ($SRC) gcc ]. I would look into ASSP to be sure that all calls to perl modules use the indirect method. There may be some elements where the call is direct (using the pathname) rather than using the indirect I told you where to look. If the three offending calls use the direct method, then those need to be changed to indirect. The behavior you describe points to what I have seen. I may be wrong; but, it is a place to start. Frank On Jan 21, 2009, at 5:23 PM, Scott Haneda wrote: I am telling ASSP where the new perl is, this issue is that some modules, only three of 15 or more, are being looked for in the wrong spot. I do not know if I should solve this in the port, by editing the source of the app, or if there is some other way. I actually hope there is some other way, as there should be no reason why I need to modify the source other than to change the perl path at the top of a few files. On Jan 21, 2009, at 5:13 PM, Frank J. R. Hanstick wrote: Hello, It sounds like opt/local is not the first location the path environment looks for perl. This is a problem when several versions of a program exists because unless a prefix is supplied, the default program will always be found in the order of the pathname (first detected). If perl exists in /opt/local/bin and / usr/bin and the path is in the order of /usr/bin:/opt/local/bin, then without a prefix, /usr/bin will always be the perl used and visa versa if path is /opt/local/bin:/usr/bin. I ran into the same problem with gcc located in two different locations. Frank -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: ASSP port testing, not getting all perl mods to work
I will look into it, thanks. If I can not get more definitive answers here, I also moved into the perl mail list as well. The ASSP dev just told me to use CPAN, so I do not think he has any interest in working this out. I personally feel it is a bug in ASSP, since other mods work, and this one seems to assume some standard location of perl. On Jan 21, 2009, at 7:56 PM, Frank J. R. Hanstick wrote: Hello, The problem I had with two gcc's was that one call to the gcc was done direct (gcc) instead of an indirect prefix variable [ ($SRC)gcc ]. I would look into ASSP to be sure that all calls to perl modules use the indirect method. There may be some elements where the call is direct (using the pathname) rather than using the indirect I told you where to look. If the three offending calls use the direct method, then those need to be changed to indirect. The behavior you describe points to what I have seen. I may be wrong; but, it is a place to start. Frank On Jan 21, 2009, at 5:23 PM, Scott Haneda wrote: I am telling ASSP where the new perl is, this issue is that some modules, only three of 15 or more, are being looked for in the wrong spot. I do not know if I should solve this in the port, by editing the source of the app, or if there is some other way. I actually hope there is some other way, as there should be no reason why I need to modify the source other than to change the perl path at the top of a few files. On Jan 21, 2009, at 5:13 PM, Frank J. R. Hanstick wrote: Hello, It sounds like opt/local is not the first location the path environment looks for perl. This is a problem when several versions of a program exists because unless a prefix is supplied, the default program will always be found in the order of the pathname (first detected). If perl exists in /opt/local/bin and / usr/bin and the path is in the order of /usr/bin:/opt/local/bin, then without a prefix, /usr/bin will always be the perl used and visa versa if path is /opt/local/bin:/usr/bin. I ran into the same problem with gcc located in two different locations. Frank -- Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
