Re: [113152] trunk/dports
On 2013-11-11 05:43, Jeremy Huddleston Sequoia wrote: What was the reason for moving it from pre_args to args? I don't really see that in the commit message. Most ports were either setting autoconf.args to -fvi (or in the long form --force --install --verbose) or clearing autoconf.pre_args as they also change autoconf.cmd. I wrote in the commit message: It's unlikely that we need additional commands, but more likely we need completely different or no arguments (for instance when running ./autogen.sh). Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Oct 31, 2013, at 12:17, easie...@macports.org wrote:
Revision
112776
Author
easie...@macports.org
Date
2013-10-31 10:17:12 -0700 (Thu, 31 Oct 2013)
Log Message
Fix #41026 for darwin 13 (aka OS X 10.9 Mavericks).
Modified Paths
• trunk/dports/lang/clisp/Portfile
Diff
Modified: trunk/dports/lang/clisp/Portfile (112775 = 112776)
--- trunk/dports/lang/clisp/Portfile 2013-10-31 15:29:35 UTC (rev 112775)
+++ trunk/dports/lang/clisp/Portfile 2013-10-31 17:17:12 UTC (rev 112776)
@@ -56,6 +56,10 @@
configure.cflags-append -Wl,-no_pie
}
+platform darwin 13 {
+configure.cflags-append -Wl,-no_pie
+}
Instead of copying the same code three times for platforms darwin 11, 12 and
13, can we assume that all OS versions after 10 will need this fix and use just
a single block for that? DRY.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
Sure: my TCL fu is not that great, so I always a little to hesitant to move
outside the patterns that I know work in Portfiles, but getting the right
conditionalized stanza that is somewhat future proof is certainly the right
thing to do
Ryan Schmidt ryandes...@macports.org wrote:
On Oct 31, 2013, at 12:17, easie...@macports.org wrote:
Revision
112776
Author
easie...@macports.org
Date
2013-10-31 10:17:12 -0700 (Thu, 31 Oct 2013)
Log Message
Fix #41026 for darwin 13 (aka OS X 10.9 Mavericks).
Modified Paths
• trunk/dports/lang/clisp/Portfile
Diff
Modified: trunk/dports/lang/clisp/Portfile (112775 = 112776)
--- trunk/dports/lang/clisp/Portfile 2013-10-31 15:29:35 UTC (rev 112775)
+++ trunk/dports/lang/clisp/Portfile 2013-10-31 17:17:12 UTC (rev 112776)
@@ -56,6 +56,10 @@
configure.cflags-append -Wl,-no_pie
}
+platform darwin 13 {
+configure.cflags-append -Wl,-no_pie
+}
Instead of copying the same code three times for platforms darwin 11, 12 and
13, can we assume that all OS versions after 10 will need this fix and use
just a single block for that? DRY.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 08:20, Mark Evenson wrote:
Sure: my TCL fu is not that great, so I always a little to hesitant to move
outside the patterns that I know work in Portfiles, but getting the right
conditionalized stanza that is somewhat future proof is certainly the right
thing to do
It should just be:
if {${os.platform} eq darwin ${os.major} = 11} {
configure.cflags-append -Wl,-no_pie
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
fatal error: ' X11 .rules' file not found
Jeremy (and dev list), The last comment in https://trac.macports.org/ticket/31504 says you were looking into the issue “fatal error: ' X11 .rules' file not found” which was seen when clang first started being used. Now we’re seeing it again in Mavericks, e.g.: https://trac.macports.org/ticket/40862 (tightvnc) https://trac.macports.org/ticket/41293 (rasmol) Do you have any ideas about a fix? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 9:26 AM, Ryan Schmidt ryandes...@macports.org wrote:
On Nov 11, 2013, at 08:20, Mark Evenson wrote:
Sure: my TCL fu is not that great, so I always a little to hesitant to move
outside the patterns that I know work in Portfiles, but getting the right
conditionalized stanza that is somewhat future proof is certainly the right
thing to do
It should just be:
if {${os.platform} eq darwin ${os.major} = 11} {
configure.cflags-append -Wl,-no_pie
}
why not
platform darwin {
if {${os.major} = 11} {
configure.cflags-append -Wl,-no_pie
}
}
which doesn't loose the platform block? [aside: didn't we have a proposal for
more flexible platform descriptions at some point so you could just write this
in a normal platform block?]
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 09:45, Daniel J. Luke wrote:
On Nov 11, 2013, at 9:26 AM, Ryan Schmidt wrote:
On Nov 11, 2013, at 08:20, Mark Evenson wrote:
Sure: my TCL fu is not that great, so I always a little to hesitant to move
outside the patterns that I know work in Portfiles, but getting the right
conditionalized stanza that is somewhat future proof is certainly the right
thing to do
It should just be:
if {${os.platform} eq darwin ${os.major} = 11} {
configure.cflags-append -Wl,-no_pie
}
why not
platform darwin {
if {${os.major} = 11} {
configure.cflags-append -Wl,-no_pie
}
}
which doesn't loose the platform block?
“platform darwin” used to be different from “if {${os.platform} eq “darwin”}”
but is since a few years exactly the same. So I propose to combine the two if
statements into a single one so as not to need two levels of indentation.
[aside: didn't we have a proposal for more flexible platform descriptions at
some point so you could just write this in a normal platform block?]
Yes but it doesn’t seem that important to me since it’s exactly equivalent to
an “if” statement so just write the “if” statement that you want.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 10:48 AM, Ryan Schmidt ryandes...@macports.org wrote: [aside: didn't we have a proposal for more flexible platform descriptions at some point so you could just write this in a normal platform block?] Yes but it doesn’t seem that important to me since it’s exactly equivalent to an “if” statement so just write the “if” statement that you want. platform variants get recorded in the registry. Using bare if statements also looses the (mostly) declarative nature of the portfile. Encouraging people to write portfiles this way also weakens the generally true heuristic that if you're doing this sort of thing you're doing it wrong (since you're probably writing your own version of some existing macports functionality). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 09:58, Daniel J. Luke wrote: On Nov 11, 2013, at 10:48 AM, Ryan Schmidt wrote: [aside: didn't we have a proposal for more flexible platform descriptions at some point so you could just write this in a normal platform block?] Yes but it doesn’t seem that important to me since it’s exactly equivalent to an “if” statement so just write the “if” statement that you want. platform variants get recorded in the registry. Is that still true? platform statements *used to be* handled like variants, but are no longer handled that way. Looking at “port -v installed”, we do seem to store the os.platform and os.major, of all ports, regardless of whether they have any “platform” blocks. Using bare if statements also looses the (mostly) declarative nature of the portfile. Encouraging people to write portfiles this way also weakens the generally true heuristic that if you're doing this sort of thing you're doing it wrong (since you're probably writing your own version of some existing macports functionality). Meh. I can’t find a ticket for this feature request, but here’s a related one. https://trac.macports.org/ticket/15712 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 11:02 AM, Ryan Schmidt ryandes...@macports.org wrote: On Nov 11, 2013, at 09:58, Daniel J. Luke wrote: On Nov 11, 2013, at 10:48 AM, Ryan Schmidt wrote: [aside: didn't we have a proposal for more flexible platform descriptions at some point so you could just write this in a normal platform block?] Yes but it doesn’t seem that important to me since it’s exactly equivalent to an “if” statement so just write the “if” statement that you want. platform variants get recorded in the registry. Is that still true? yes (at least, I have one example of a port with a platform darwin that port installed has listed with +darwin and port variants doesn't list a +darwin variant). Using bare if statements also looses the (mostly) declarative nature of the portfile. Encouraging people to write portfiles this way also weakens the generally true heuristic that if you're doing this sort of thing you're doing it wrong (since you're probably writing your own version of some existing macports functionality). Meh. really? For someone who is quick to jump on /many/ stylistic differences it's surprising that you don't care at all about the initial design philosophy ... I can’t find a ticket for this feature request, but here’s a related one. https://trac.macports.org/ticket/15712 IIRC kvv also proposed something (along with syntax for specifying versions in dependencies) back long before trac ;-) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 10:14, Daniel J. Luke wrote: platform variants get recorded in the registry. Is that still true? yes (at least, I have one example of a port with a platform darwin that port installed has listed with +darwin and port variants doesn't list a +darwin variant). I’m not seeing it on my system, for example with wine-devel. What port do you see this with? What exactly does “port -v installed” show for that port? Maybe there’s something special/wrong about that port. Using bare if statements also looses the (mostly) declarative nature of the portfile. Encouraging people to write portfiles this way also weakens the generally true heuristic that if you're doing this sort of thing you're doing it wrong (since you're probably writing your own version of some existing macports functionality). Meh. really? For someone who is quick to jump on /many/ stylistic differences it's surprising that you don't care at all about the initial design philosophy ... Oh, you’re right, it would be nice to be able to specify platform versions in the block. But it’s a matter of a few more characters on a single line which isn’t a big deal to me. I’d much rather for example find ways of reducing the enormous boilerplate that is the fortran variant recipe. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 11:26 AM, Ryan Schmidt ryandes...@macports.org wrote: On Nov 11, 2013, at 10:14, Daniel J. Luke wrote: platform variants get recorded in the registry. Is that still true? yes (at least, I have one example of a port with a platform darwin that port installed has listed with +darwin and port variants doesn't list a +darwin variant). I’m not seeing it on my system, for example with wine-devel. What port do you see this with? What exactly does “port -v installed” show for that port? Maybe there’s something special/wrong about that port. maybe, I see it with 'mutt' but not with wine-devel (and not with any ports on another machine I just checked), so maybe it doesn't get recorded like that anymore... -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 11:35 AM, Ryan Schmidt ryandes...@macports.org wrote: platform blocks were changed from variants into “if” statements in MacPorts 1.9.0. If you installed mutt before MacPorts 1.9.0 and haven’t rebuilt it since then, then it would still be recorded in the registry with a darwin variant. I have rebuilt it since then, but it may have just been doing non-migration-approved upgrades ;-) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [112776] trunk/dports/lang/clisp/Portfile
On Nov 11, 2013, at 10:31, Daniel J. Luke wrote: On Nov 11, 2013, at 11:26 AM, Ryan Schmidt wrote: On Nov 11, 2013, at 10:14, Daniel J. Luke wrote: platform variants get recorded in the registry. Is that still true? yes (at least, I have one example of a port with a platform darwin that port installed has listed with +darwin and port variants doesn't list a +darwin variant). I’m not seeing it on my system, for example with wine-devel. What port do you see this with? What exactly does “port -v installed” show for that port? Maybe there’s something special/wrong about that port. maybe, I see it with 'mutt' but not with wine-devel (and not with any ports on another machine I just checked), so maybe it doesn't get recorded like that anymore… $ sudo port install mutt Password: --- Computing dependencies for mutt --- Fetching distfiles for mutt --- Verifying checksums for mutt --- Extracting mutt --- Configuring mutt --- Building mutt --- Staging mutt into destroot --- Installing mutt @1.4.2.3_1+universal --- Activating mutt @1.4.2.3_1+universal --- Cleaning mutt $ port -v installed mutt The following ports are currently installed: mutt @1.4.2.3_1+universal (active) platform='darwin 13' archs='i386 x86_64’ $ platform blocks were changed from variants into “if” statements in MacPorts 1.9.0. If you installed mutt before MacPorts 1.9.0 and haven’t rebuilt it since then, then it would still be recorded in the registry with a darwin variant. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: fatal error: ' X11 .rules' file not found
On Nov 11, 2013, at 7:29, Ryan Schmidt ryandes...@macports.org wrote: Jeremy (and dev list), The last comment in https://trac.macports.org/ticket/31504 says you were looking into the issue “fatal error: ' X11 .rules' file not found” which was seen when clang first started being used. Now we’re seeing it again in Mavericks, e.g.: https://trac.macports.org/ticket/40862 (tightvnc) https://trac.macports.org/ticket/41293 (rasmol) Do you have any ideas about a fix? Oh yeah, that... The real fix is to stop using imake et al. But a short term solution would be using gcc's preprocessor instead of clang's. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: redefined data types in different packages - request for help
On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote: Hi Mojca, since this beautiful example of Bad Code (TM) is inside (system) library headers there's not much you can do without reporting upstream http://bugzilla.maptools.org/show_bug.cgi?id=2464 or resorting to very rude measures like using your own patched tiff: MacPorts sometimes fixes upstream bugs in order to make the ports compile. This would probably be another such case. The problem is that I'm not sure how to properly fix this in tiff. Without having a system here to test my suggestions, you might be able to - configure tiff to not define this type name (or define it correctly in the sense of portability and compatibility, at least). I cannot configure it to not define the type name uint64. This type name is used all over the place. The solution might be to define it to uint64_t instead of unsigned long. - configure the software to try to avoid #including one or the other file (WTH is cssmconfig.h, anyway?) The file cssmconfig.h is part of Security.framework. What it is used for - no idea at all. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Unable to log in to Trac
Hi,
I am unable to log in to Trac right now. Upon logging in, I get the following
Python traceback:
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 441, in
send_error
data, 'text/html')
File /usr/lib/python2.6/site-packages/trac/web/chrome.py, line 828, in
render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216, in
__getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 309, in
_get_session
return Session(self.env, req)
File /usr/lib/python2.6/site-packages/trac/web/session.py, line 201, in
__init__
if req.authname == 'anonymous':
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216, in
__getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 168, in
authenticate
authname = authenticator.authenticate(req)
File
/usr/lib/python2.6/site-packages/IgneousAuthenticationModule-2.0-py2.6.egg/igneousauth/auth.py,
line 34, in authenticate
s = Session.objects.get(pk=fid)
File /usr/lib/python2.6/site-packages/django/db/models/manager.py, line
132, in get
return self.get_query_set().get(*args, **kwargs)
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line 344,
in get
num = len(clone)
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line 82,
in __len__
self._result_cache = list(self.iterator())
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line 273,
in iterator
for row in compiler.results_iter():
File /usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py,
line 680, in results_iter
for rows in self.execute_sql(MULTI):
File /usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py,
line 734, in execute_sql
cursor = self.connection.cursor()
File /usr/lib/python2.6/site-packages/django/db/backends/__init__.py, line
252, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
File
/usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py,
line 144, in _cursor
cursor = self.connection.cursor()
InterfaceError: connection already closed
Thanks,
Leo Singer
Graduate Student @ LIGO-Caltech
Leo Singer
Graduate Student @ LIGO-Caltech
(w)626-395-8510
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #41303: splash @2.3.1 new release
please could someone commit this? thanks, Daniel On 11 Nov 2013, at 19:53, MacPorts nore...@macports.org wrote: #41303: splash @2.3.1 new release -+- Reporter: daniel.price@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports |Version: 2.2.1 Resolution: | Keywords: haspatch maintainer Port: splash | -+- Comment (by daniel.price@…): now fixed -- Ticket URL: https://trac.macports.org/ticket/41303#comment:2 MacPorts http://www.macports.org/ Ports system for OS X ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
conflicts treats tcl list as string
Is there a better alternative to eval for setting conflicts to a list variable?
set mp.conflicts {c1 c2 c3 c4}
conflicts${mp.conflicts}
foreach mp.conflict $conflicts {
puts ${mp.conflict}
}
/* returns:
c1 c2 c3 c4
*/
eval conflicts ${mp.conflicts}
foreach mp.conflict $conflicts {
puts ${mp.conflict}
}
/* returns:
c1
c2
c3
c4
*/
Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Unable to log in to Trac
I wasn't even trying to log in, I was just refreshing the page, and got a
similar error:
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 441,
in send_error
data, 'text/html')
File /usr/lib/python2.6/site-packages/trac/web/chrome.py, line
828, in render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216,
in __getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 309,
in _get_session
return Session(self.env, req)
File /usr/lib/python2.6/site-packages/trac/web/session.py, line
201, in __init__
if req.authname == 'anonymous':
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216,
in __getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 168,
in authenticate
authname = authenticator.authenticate(req)
File
/usr/lib/python2.6/site-packages/IgneousAuthenticationModule-2.0-py2.6.egg/igneousauth/auth.py,
line 34, in authenticate
s = Session.objects.get(pk=fid)
File /usr/lib/python2.6/site-packages/django/db/models/manager.py,
line 132, in get
return self.get_query_set().get(*args, **kwargs)
File /usr/lib/python2.6/site-packages/django/db/models/query.py,
line 344, in get
num = len(clone)
File /usr/lib/python2.6/site-packages/django/db/models/query.py,
line 82, in __len__
self._result_cache = list(self.iterator())
File /usr/lib/python2.6/site-packages/django/db/models/query.py,
line 273, in iterator
for row in compiler.results_iter():
File /usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py,
line 680, in results_iter
for rows in self.execute_sql(MULTI):
File /usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py,
line 734, in execute_sql
cursor = self.connection.cursor()
File /usr/lib/python2.6/site-packages/django/db/backends/__init__.py,
line 252, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
File
/usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py,
line 140, in _cursor
self.connection = Database.connect(**conn_params)
OperationalError: could not connect to server: Connection timed out
Is the server running on host data.macosforge.org and accepting
TCP/IP connections on port ?
On Mon, Nov 11, 2013 at 2:22 PM, Leo Singer aron...@macports.org wrote:
Hi,
I am unable to log in to Trac right now. Upon logging in, I get the
following Python traceback:
Traceback (most recent call last):
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 441, in
send_error
data, 'text/html')
File /usr/lib/python2.6/site-packages/trac/web/chrome.py, line 828, in
render_template
message = req.session.pop('chrome.%s.%d' % (type_, i))
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216, in
__getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 309, in
_get_session
return Session(self.env, req)
File /usr/lib/python2.6/site-packages/trac/web/session.py, line 201,
in __init__
if req.authname == 'anonymous':
File /usr/lib/python2.6/site-packages/trac/web/api.py, line 216, in
__getattr__
value = self.callbacks[name](self)
File /usr/lib/python2.6/site-packages/trac/web/main.py, line 168, in
authenticate
authname = authenticator.authenticate(req)
File
/usr/lib/python2.6/site-packages/IgneousAuthenticationModule-2.0-py2.6.egg/igneousauth/auth.py,
line 34, in authenticate
s = Session.objects.get(pk=fid)
File /usr/lib/python2.6/site-packages/django/db/models/manager.py,
line 132, in get
return self.get_query_set().get(*args, **kwargs)
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line
344, in get
num = len(clone)
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line
82, in __len__
self._result_cache = list(self.iterator())
File /usr/lib/python2.6/site-packages/django/db/models/query.py, line
273, in iterator
for row in compiler.results_iter():
File
/usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py, line
680, in results_iter
for rows in self.execute_sql(MULTI):
File
/usr/lib/python2.6/site-packages/django/db/models/sql/compiler.py, line
734, in execute_sql
cursor = self.connection.cursor()
File /usr/lib/python2.6/site-packages/django/db/backends/__init__.py,
line 252, in cursor
cursor = util.CursorWrapper(self._cursor(), self)
File
/usr/lib/python2.6/site-packages/django/db/backends/postgresql_psycopg2/base.py,
line 144, in _cursor
cursor = self.connection.cursor()
InterfaceError: connection already closed
Thanks,
Leo Singer
Graduate Student @ LIGO-Caltech
Leo Singer
Graduate Student @ LIGO-Caltech
(w)626-395-8510
removing -arch from LDFLAGS
Hi all, Is there a way to remove the -arch option from LDFLAGS, as for gfortran? Using configure.compiler macports-gcc-XX removes it, but that is not compatible with the Fortran recipe which only sets configure.f90 etc. On my machine, the default value is LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64' I can use configure.args-append LDFLAGS= to clear LDFLAGS entirely, but it may better to just remove the -arch part. However, putting configure.ldflags-delete -arch x86_64, either in the main part of the Portfile, or in a pre-configure block, has no effect, because at that point if I write out configure.ldflags it is only -L/opt/local/lib -Wl,-headerpad_max_install_names, and if I try to write out configure.args, I get Error: org.macports.configure for port libxc returned: can't read configure.args: no such variable What is the best approach here? Thanks, David ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: local PortGroup repo?
I tried it out, and it works partially. The PortGroup file I made in _resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but not when uninstalling. For example: $ sudo port uninstall libxc @2.0.2_0+gcc47 Warning: PortGroup fortran 1.0 could not be located. fortran-1.0.tcl does not exist. Error: org.macports.uninstall for port libxc returned: Registry error: libxc @2.0.2_0 not registered as installed Please see the log file for port libxc for details: /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log Warning: Failed to execute portfile from registry for libxc @2.0.2_0+gcc47 Warning: PortGroup fortran 1.0 could not be located. fortran-1.0.tcl does not exist. Error: org.macports.deactivate for port libxc returned: Active version of libxc is not 2.0.2_0 but 2.0.2_0+gcc47. Please see the log file for port libxc for details: /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log Warning: Failed to execute portfile from registry for libxc @2.0.2_0+gcc47 --- Deactivating libxc @2.0.2_0+gcc47 --- Uninstalling libxc @2.0.2_0+gcc47 The log file mentioned doesn't contain much more information: $ cat /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log version:1 :debug:main Executing org.macports.main (libxc) :debug:deactivate deactivate phase started at Tue Nov 12 00:37:14 EST 2013 :debug:deactivate Executing org.macports.deactivate (libxc) :error:deactivate org.macports.deactivate for port libxc returned: Active version of libxc is not 2.0.2_0 but 2.0.2_0+gcc47. :debug:deactivate Error code: NONE :debug:deactivate Backtrace: Active version of libxc is not 2.0.2_0 but 2.0.2_0+gcc47. invoked from within registry_deactivate $subport $version $revision $portvariants [array get user_options] (procedure portdeactivate::deactivate_main line 11) invoked from within $procedure $targetname :info:deactivate Warning: targets not executed for libxc: org.macports.deactivate :notice:deactivate Please see the log file for port libxc for details: /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_libxc_2.0.2_0+gcc47/libxc/main.log On Sat, Nov 2, 2013 at 8:04 AM, Rainer Müller rai...@macports.org wrote: On 2013-11-01 21:02, Dan Ports wrote: On Fri, Nov 01, 2013 at 03:21:36PM -0400, Eric Gallager wrote: Really? That's strange, I could've sworn I was able to use the qmake portgroup in my local PortFile repository successfully when I was testing it... I believe portfiles will use portgroups from their own repository, so portgroups in a local repository will affect your local ports but not override ones in the default repo. Yes, port groups will be used from their own ports tree. Only if the port group file does not exist there, it falls back to using the port group from the default ports tree. This is the same behavior that is applied for all files in the _resources directory. I added a debug message in r112824 [1], which makes it easier to see which port groups are sourced. Rainer [1] https://trac.macports.org/changeset/112824 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: local PortGroup repo?
dstru...@mit.edu writes: I tried it out, and it works partially. The PortGroup file I made in _resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but not when uninstalling. Yep. I filed a bug long ago and tried to fix it: https://trac.macports.org/ticket/34933 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: removing -arch from LDFLAGS
On 2013-11-12 16:32 , David Strubbe wrote: Hi all, Is there a way to remove the -arch option from LDFLAGS, as for gfortran? Using configure.compiler macports-gcc-XX removes it, but that is not compatible with the Fortran recipe which only sets configure.f90 etc. On my machine, the default value is LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64' I can use configure.args-append LDFLAGS= to clear LDFLAGS entirely, but it may better to just remove the -arch part. However, putting configure.ldflags-delete -arch x86_64, either in the main part of the Portfile, or in a pre-configure block, has no effect, because at that point if I write out configure.ldflags it is only -L/opt/local/lib -Wl,-headerpad_max_install_names, and if I try to write out configure.args, I get Error: org.macports.configure for port libxc returned: can't read configure.args: no such variable What is the best approach here? The option you want is configure.ld_archflags. Note that simply clearing it may break the port's ability to build for the selected build_arch. The corresponding option used for +universal is configure.universal_ldflags. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: local PortGroup repo?
I see. As it stands, I am not sure how to actually uninstall the ports I installed with the test portgroup -- they are still there after the failed uninstall. Any tip? David On Tue, Nov 12, 2013 at 12:44 AM, Sean Farley s...@macports.org wrote: dstru...@mit.edu writes: I tried it out, and it works partially. The PortGroup file I made in _resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but not when uninstalling. Yep. I filed a bug long ago and tried to fix it: https://trac.macports.org/ticket/34933 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: removing -arch from LDFLAGS
Thanks. This isn't in the guide. Would be helpful to list in
http://guide.macports.org/#reference.phases.configure.
I think I should do configure.ld_archflags (i.e. set to blank) if the
compiler is gfortran. When you say simply clearing it may break the port's
ability to build for the selected build_arch are you saying this is still
not the way to go? If so, what do you suggest? Or did you mean clearing
LDFLAGS entirely? Or do you mean if I clear it always not just when using
gfortran?
Also, why didn't ${configure.args} work?
David
On Tue, Nov 12, 2013 at 1:08 AM, Joshua Root j...@macports.org wrote:
On 2013-11-12 16:32 , David Strubbe wrote:
Hi all,
Is there a way to remove the -arch option from LDFLAGS, as for gfortran?
Using configure.compiler macports-gcc-XX removes it, but that is not
compatible with the Fortran recipe which only sets configure.f90 etc. On
my machine, the default value is
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
I can use
configure.args-append LDFLAGS=
to clear LDFLAGS entirely, but it may better to just remove the -arch
part. However, putting configure.ldflags-delete -arch x86_64, either in
the main part of the Portfile, or in a pre-configure block, has no
effect, because at that point if I write out configure.ldflags it is
only -L/opt/local/lib -Wl,-headerpad_max_install_names, and if I try
to write out configure.args, I get
Error: org.macports.configure for port libxc returned: can't read
configure.args: no such variable
What is the best approach here?
The option you want is configure.ld_archflags. Note that simply clearing
it may break the port's ability to build for the selected build_arch.
The corresponding option used for +universal is
configure.universal_ldflags.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: local PortGroup repo?
If they're not uninstalling that would be a bug in base. The files are meant to be uninstalled and the registry entry removed regardless of whether executing the portfile succeeds. - Josh On 2013-11-12 17:16 , David Strubbe wrote: I see. As it stands, I am not sure how to actually uninstall the ports I installed with the test portgroup -- they are still there after the failed uninstall. Any tip? David On Tue, Nov 12, 2013 at 12:44 AM, Sean Farley s...@macports.org mailto:s...@macports.org wrote: dstru...@mit.edu mailto:dstru...@mit.edu writes: I tried it out, and it works partially. The PortGroup file I made in _resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but not when uninstalling. Yep. I filed a bug long ago and tried to fix it: https://trac.macports.org/ticket/34933 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: removing -arch from LDFLAGS
On 2013-11-12 17:25 , David Strubbe wrote:
Thanks. This isn't in the guide. Would be helpful to list
in http://guide.macports.org/#reference.phases.configure.
Yep.
I think I should do configure.ld_archflags (i.e. set to blank) if the
compiler is gfortran. When you say simply clearing it may break the
port's ability to build for the selected build_arch are you saying this
is still not the way to go? If so, what do you suggest? Or did you mean
clearing LDFLAGS entirely? Or do you mean if I clear it always not just
when using gfortran?
I'm saying that if the user sets build_arch to i386 in macports.conf,
adding '-arch i386' to LDFLAGS is one of the ways that we tell the build
system to build for i386 and not for (say) x86_64 which is the default
on recent systems. So if you don't do that, you may need to do something
else. I don't know your build system so I don't know what if anything
would be needed.
Also, why didn't ${configure.args} work?
Referencing an unset variable is an error in Tcl, it's not like sh where
everything unset is an empty string.
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
