Re: keygen problem generating cryptkey
"J. Maxwell" <[email protected]> Fri, 11 Feb 2011 09:45:39 -0800
| Newsgroups | gmane.mail.spam.tmda.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============8041345081004411408== Content-Type: multipart/alternative; boundary="------------050301020703090106010501" This is a multi-part message in MIME format. --------------050301020703090106010501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/10/2011 10:00 AM, Kevin Goodsell wrote: > Please keep the discussion on the list were other people can > contribute and benefit. > > On Wed, Feb 9, 2011 at 9:54 PM, J. Maxwell<[email protected]> wrote: >> On 2/9/2011 11:18 AM, Kevin Goodsell wrote: >> >>> /usr/local/bin isn't what you need in the path. You need >>> /usr/local/lib/python2.6/site-packages, which is supposed to be added to >>> the path by the site module on interpreter startup. More on this below. >>> >>> Getting back to the problem at hand, it looks to me like Python was >>> configured incorrectly, or TMDA installed in the wrong location >> Could be an error in the ports collection, both were installed from the >> ports collection there > No, I was mis-interpreting the problem. My guess, that sys.prefix was > /usr instead of /usr/local, was incorrect. The reason > python2.6/site-packages was missing was that (as you pointed out in > another private email) you were running a different Python version, so > obviously python2.6 paths were not included. > >> #1758:> python -c "import sys; print sys.prefix, sys.exec_prefix" >> /usr/local /usr/local >> >>> If neither one is /usr/local, that explains why >>> /usr/local/lib/python2.6/site-packages is missing from sys.path. >> Both are /usr/local >> >>> I suggest just creating a symlink to >>> /usr/local/lib/python2.6/site-packages/TMDA in the directory where >>> Python looks for site packages (probably sys.prefix + >>> '/lib/python2.6/site-packages') >> Then wouldn't it be looking in /usr/local/lib/python2.6/site-packages >> >> Created the link but got the same results >> >> #1759:> cd /usr/local >> /usr/local >> #1760:> ls -l TMDA >> lrwxr-xr-x 1 root wheel 43 Feb 9 13:00 TMDA@ -> >> /usr/local/lib/python2.6/site-packages/TMDA > This is not what I meant at all. Python won't look in /usr/local for > modules. sys.prefix is just the *prefix* that it uses to construct > module paths. This is explained in the documentation for the site module: > > http://docs.python.org/library/site.html > > My suggestion was meaningless since sys.prefix is actually /usr/local. > The link location and target would be the same. > >> #1761:> >> #1761:> tmda-keygen >> Traceback (most recent call last): >> File "/usr/local/bin/tmda-keygen", line 37, in<module> >> from TMDA import Version >> ImportError: No module named TMDA >> #1762:> >> >> Thinking that the TMDA@ link might be problematic, I created the directory >> ./TMDA and its sub-directories in /usr/local/ , then linked all the files >> across the directories. >> (wouldn't this be just reading the TMDA from /usr/local rather than >> /usr/local/lib/python2.6/site-packages ?) > You are just cluttering /usr/local. There was no reason to put anything > there. > >> Got the same results, no matter where I ran tmda-keygen from >> >> Thank for all your assistance, greatly appreciated >> > Let me try to summarize what happened here. > > 1. The TMDA package directory was installed in > /usr/local/lib/python2.6/site-packages/TMDA, but was not being found > there, presumably because /usr/local/lib/python2.6/site-packages was > not in sys.path. > > 2. I assumed (incorrectly) that Python was configured with a different > site-packages prefix (probably /usr), which would cause the > site-packages path to be, e.g., /usr/lib/python2.6/site-packages. I > suggested adding a symlink at this location. > > 3. In fact, the site-packages location was > /usr/local/lib/python2.7/site-packages because the Python version was > 2.7. > > -Kevin > The Makefile has a line => USE_PYTHON= 2.4+ Can I just simply change this to USE_PYTHON= 2.7+ Since Python 2.7.1 seems to be the default THANKS! --------------050301020703090106010501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 2/10/2011 10:00 AM, Kevin Goodsell wrote: <blockquote cite="mid:[email protected]" type="cite"> <pre wrap="">Please keep the discussion on the list were other people can contribute and benefit. On Wed, Feb 9, 2011 at 9:54 PM, J. Maxwell <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">On 2/9/2011 11:18 AM, Kevin Goodsell wrote: </pre> <blockquote type="cite"> <pre wrap="">/usr/local/bin isn't what you need in the path. You need /usr/local/lib/python2.6/site-packages, which is supposed to be added to the path by the site module on interpreter startup. More on this below. Getting back to the problem at hand, it looks to me like Python was configured incorrectly, or TMDA installed in the wrong location </pre> </blockquote> <pre wrap=""> Could be an error in the ports collection, both were installed from the ports collection there </pre> </blockquote> <pre wrap=""> No, I was mis-interpreting the problem. My guess, that sys.prefix was /usr instead of /usr/local, was incorrect. The reason python2.6/site-packages was missing was that (as you pointed out in another private email) you were running a different Python version, so obviously python2.6 paths were not included. </pre> <blockquote type="cite"> <pre wrap=""> #1758:> python -c "import sys; print sys.prefix, sys.exec_prefix" /usr/local /usr/local </pre> <blockquote type="cite"> <pre wrap="">If neither one is /usr/local, that explains why /usr/local/lib/python2.6/site-packages is missing from sys.path. </pre> </blockquote> <pre wrap=""> Both are /usr/local </pre> <blockquote type="cite"> <pre wrap="">I suggest just creating a symlink to /usr/local/lib/python2.6/site-packages/TMDA in the directory where Python looks for site packages (probably sys.prefix + '/lib/python2.6/site-packages') </pre> </blockquote> <pre wrap=""> Then wouldn't it be looking in /usr/local/lib/python2.6/site-packages Created the link but got the same results #1759:> cd /usr/local /usr/local #1760:> ls -l TMDA lrwxr-xr-x 1 root wheel 43 Feb 9 13:00 TMDA@ -> /usr/local/lib/python2.6/site-packages/TMDA </pre> </blockquote> <pre wrap=""> This is not what I meant at all. Python won't look in /usr/local for modules. sys.prefix is just the *prefix* that it uses to construct module paths. This is explained in the documentation for the site module: <a class="moz-txt-link-freetext" href="http://docs.python.org/library/site.html">http://docs.python.org/library/site.html</a> My suggestion was meaningless since sys.prefix is actually /usr/local. The link location and target would be the same. </pre> <blockquote type="cite"> <pre wrap="">#1761:> #1761:> tmda-keygen Traceback (most recent call last): File "/usr/local/bin/tmda-keygen", line 37, in <module> from TMDA import Version ImportError: No module named TMDA #1762:> Thinking that the TMDA@ link might be problematic, I created the directory ./TMDA and its sub-directories in /usr/local/ , then linked all the files across the directories. (wouldn't this be just reading the TMDA from /usr/local rather than /usr/local/lib/python2.6/site-packages ?) </pre> </blockquote> <pre wrap=""> You are just cluttering /usr/local. There was no reason to put anything there. </pre> <blockquote type="cite"> <pre wrap=""> Got the same results, no matter where I ran tmda-keygen from Thank for all your assistance, greatly appreciated </pre> </blockquote> <pre wrap=""> Let me try to summarize what happened here. 1. The TMDA package directory was installed in /usr/local/lib/python2.6/site-packages/TMDA, but was not being found there, presumably because /usr/local/lib/python2.6/site-packages was not in sys.path. 2. I assumed (incorrectly) that Python was configured with a different site-packages prefix (probably /usr), which would cause the site-packages path to be, e.g., /usr/lib/python2.6/site-packages. I suggested adding a symlink at this location. 3. In fact, the site-packages location was /usr/local/lib/python2.7/site-packages because the Python version was 2.7. -Kevin </pre> </blockquote> The Makefile has a line =><br> USE_PYTHON= 2.4+<br> Can I just simply change this to<br> USE_PYTHON= 2.7+<br> <br> Since Python 2.7.1 seems to be the default<br> <br> THANKS!<br> </body> </html> --------------050301020703090106010501-- --===============8041345081004411408== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb --===============8041345081004411408== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tmda-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tmda-users --===============8041345081004411408==--