Re: [147850] trunk/dports/finance/bitcoin/Portfile

[Mark Evenson]

On 2016/4/18 15:34, Macports wrote:
> 
>> On Apr 18, 2016, at 4:34 AM, easie...@macports.org
>>  wrote:
>>
>> Revision
>> 147850 
>> Author
>> easie...@macports.org 
>> Date
>> 2016-04-18 03:34:24 -0700 (Mon, 18 Apr 2016)
>>
>>
>>   Log Message
>>
>> finance/bitcoin: update to Bitcoin Core bitcoin-0.12.1
>>
>>
>>   Modified Paths
>>
>>   * trunk/dports/finance/bitcoin/Portfile
>> 
>>
>>
>>   Diff
>>
>>
>> Modified: trunk/dports/finance/bitcoin/Portfile (147849 => 147850)
>>
>> --- trunk/dports/finance/bitcoin/Portfile 2016-04-18 06:04:48 UTC (rev
>> 147849) +++ trunk/dports/finance/bitcoin/Portfile 2016-04-18 10:34:24
>> UTC (rev 147850) @@ -5,7 +5,7 @@ name bitcoin categories finance
>> crypto -version 0.12.0 +version 0.12.1 revision 2 
> 
> For next time, please remember that when increasing the version, the
> revision needs to be 0. Since this is the default, the revision line
> should be deleted. 

Yep.  Sorry about that.

But I should leave the revision alone now, not that I have released it,
right?

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [127967] trunk/dports/finance/bitcoind/Portfile

[Mark Evenson]

> On Nov 10, 2014, at 09:13, Ryan Schmidt  wrote:
> 
> 
> On Nov 10, 2014, at 1:55 AM, Mark Evenson wrote:
> 
>> On 2014/11/10 08:03, Ryan Schmidt wrote:
>> 
>>> Are you sure just increasing the epoch is sufficient? Usually the version 
>>> or revision should be increased when replacing a port.
>> 
>> I was [following the advice of step 4 in the PortfileRecipes][1],
>> without really understanding what sort of behavior this is supposed to
>> trigger that I could test for.
>> 
>> Would you recommend changing the version to match bitcoin as well then?
>> 
>> [1]: https://trac.macports.org/wiki/PortfileRecipes#replaced-by
> 
> The behavior you're trying to trigger is that a user who has the previous 
> version of the port installed sees in "port outdated" that a new version is 
> available. Does that happen?
> 
> The epoch is used when a new version of a project appears to MacPorts' vercmp 
> function to be older. That's not the case here.
> 

Thanks for the explanation; addressed in [r127996][].

[r127996]: http://trac.macports.org/changeset/127996

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [127967] trunk/dports/finance/bitcoind/Portfile

[Mark Evenson]

On 2014/11/10 08:03, Ryan Schmidt wrote:

> 
> Are you sure just increasing the epoch is sufficient? Usually the version or 
> revision should be increased when replacing a port.
> 
> 

I was [following the advice of step 4 in the PortfileRecipes][1],
without really understanding what sort of behavior this is supposed to
trigger that I could test for.

Would you recommend changing the version to match bitcoin as well then?

[1]: https://trac.macports.org/wiki/PortfileRecipes#replaced-by

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [127599] trunk/dports/editors

[Mark Evenson]

> On 31 Oct 2014, at 03:07, Lawrence Velázquez  wrote:

[…]

>> +notes "To use ${name}, add the following to your ~/.emacs:\n\
>> +\n\
>> +(require 'mediawiki)\n\
>> +\n\
>> +Once the mediawiki mode is loaded, one can customize the variable\n\
>> +mediawiki-site-alist to set up information by issuing:\n\
>> +\n\
>> +   M-x customize-variable RET mediawiki-site-alist RET"
> 
> All these '\n's are unnecessary and are really ugly to boot. Double quotes 
> preserve newlines; just start new lines where you want new lines to start. 
> And the line-ending backslashes are only necessary for explicit line 
> continuation. See the zsh Portfile, for example.

Indeed it does look much better.

Thanks for the tips!



-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [127060] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

> On 21 Oct 2014, at 02:53, Ryan Schmidt  wrote:
> 
> 
>> On Oct 20, 2014, at 5:31 AM, easie...@macports.org wrote:
>> 
>> Revision
>> 127060
>> Author
>> easie...@macports.org
>> Date
>> 2014-10-20 03:31:13 -0700 (Mon, 20 Oct 2014)
>> Log Message
>> 
>> lang/sbcl: make "+fancy" the default variant as it is most commonly used.
>> Modified Paths
>> 
>>  • trunk/dports/lang/sbcl/Portfile
>> Diff
>> 
>> Modified: trunk/dports/lang/sbcl/Portfile (127059 => 127060)
>> 
>> --- trunk/dports/lang/sbcl/Portfile  2014-10-20 06:51:16 UTC (rev 127059)
>> +++ trunk/dports/lang/sbcl/Portfile  2014-10-20 10:31:13 UTC (rev 127060)
>> 
>> @@ -80,6 +80,8 @@
>> 
>> }
>> 
>> }
>> 
>> 
>> 
>> +default_variants +fancy
> 
> Please make +fancy a default variant only if none of the conflicting variants 
> have been selected, to avoid problems like this:
> 
> 
> $ port info sbcl +threads
> Error: sbcl: Variant fancy conflicts with threads
> Error: Unable to open port: Error evaluating variants

This is addressed with [r127181][] in a slightly kludgy way that will break
when more incompatible variants are introduced without adjusting the
conditional clause, as I couldn’t easily figure out how to code walk the
variants' declarations of conflicts easily.

[r127181]: https://trac.macports.org/changeset/127181

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #39723: ccl @1.9 build failure

[Mark Evenson]

On 10/5/14 9:20, MacPorts wrote:
> #39723: ccl @1.9 build failure
> -+
>   Reporter:  alanclar@…  |  Owner:  easieste@…
>   Type:  defect  | Status:  new
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.1.3
> Resolution:  |   Keywords:
>   Port:  ccl |
> -+
> 
> Comment (by fu7mu4@…):
> 
>  I don't know why. But ccl 1.10 has released with dx86cl binary on
>  darwinx86. I suggest to try ccl 1.10.
> 

I tried building ccl 1.10 yesterday, but ran into problems that look
similar to the missing header file.


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #43156: maven-devel installation completely broken

[Mark Evenson]

On 4/2/14, 2:50, MacPorts wrote:
[…]
>  maven seems to be using both strategies 1(b) and 2, and it should decide
>  which of these strategies it wants to follow. I think it wants to follow
>  the 2nd strategy, since the maven port is replaced by the maven1 port. So
>  shouldn't maven3 be updated to a newer version (#42737) and maven-devel
>  replaced by maven3? See also #42114.

Yes, this is the way forward in general.

The subtlety was that maven-3.1.x changed the API points it exports to
be used by other tools in a way that is incompatible with maven-3.0.x,
so previous consumers of the maven3 port were broken if I we had updated
maven3 to point to maven-3.1.x.  Enough time has passed, that most of
these consumers of maven3 (or at least the ones that I use), now work
with both the maven-3.0.x and maven-3.1.x API.

Two ways forward:

1)  maven3 goes to maven-3.1.x.  MacPorts no longer offers a maven-3.0.x
installation

2)  A new port 'maven31' gets introduced for maven-3.1.x; We rename
'maven3' as 'maven30' which offers maven-3.0.x.  Possibly we use
'maven3' as synonym for 'maven31'.

In any event, maven-devel should be retired.


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Oldish devel versions of Emacs

[Mark Evenson]

On 2013-12-24 14:10:06 +, Akim Demaille said:


Is it really useful to keep these obsolete « devel » versions
of Emacs?  emacs-app-devel, emacs-snapshot, emacs-w3m-devel



[…]


emacs-w3m-devel @20120808 (www)
Use the w3m web browser inside emacs.


I added emacs-w3m-devel to track the CVS sources of emacs-w3m because 
there was no release that worked with Emacs 24.


I do not know if this is still the case.


--
"A screaming comes across the sky.  It has happened before, but there s 
nothing to compare to it now."



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [114736] trunk/dports/finance

[Mark Evenson]

On Dec 14, 2013, at 21:45, Ryan Schmidt  wrote:

> 
> On Dec 14, 2013, at 10:38, easie...@macports.org wrote:
> 
>> Revision
>> 114736
>> Author
>> easie...@macports.org
>> Date
>> 2013-12-14 08:38:41 -0800 (Sat, 14 Dec 2013)
>> Log Message
>> 
>> Segregate 'finance/bitcoind':  build the Satoshi daemon from know good 
>> Github source.
>> 
>> Builds and installs a `${prefix}/sbin/bitcoind` built from a known,
>> good post 0.8.6 git commit.
>> 
>> 'finance/bitcoin' remains hosed.
> 
> Oh? 
> What’s hosed about it?

It doesn’t build for me under the 10.9 llvm.  Does it build for you?

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Promoting maven3 to 3.1.1

[Mark Evenson]

Good: possible objection retracted.

Blair Zajac  wrote:

>On Nov 25, 2013, at 10:06 PM, Mark Evenson  wrote:
>
>> Other than I don’t know any other example of a port name with a period (“.”) 
>> in it, so we might want to check that including version in this way doesn’t 
>> break anything, this looks like a perfectly acceptable proposal to me.
>
>The scala2.* ports have periods in them.
>
>Blair
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Promoting maven3 to 3.1.1

[Mark Evenson]

On Nov 24, 2013, at 22:38, Blair Zajac  wrote:

> 
> On Nov 24, 2013, at 3:30 AM, Mark Evenson  wrote:
> 
>> 
>> On Nov 23, 2013, at 9:20, Blair Zajac  wrote:

[…]

>>> Any reason for me not to update the maven3 port to 3.1.1?
>> 
>> Maven 3.1 is significantly different “under the hood” than Maven 3.0, 
>> especially in the adoption of the apache.org Aether connector.  This 
>> affected me with ABCL’s usage in that I needed to have both ports around to 
>> test things.  

[…]

>> Two paths here that I see:  

[…]

> 
> I’m thinking we do the following:
> 
> 1) Add maven3.0 which is a copy of maven3.
> 2) maven3 becomes replaced_by maven3.0.
> 3) Move maven-devel to maven3.1.
> 
> I don’t see a need for a mvn30 and mvn31 symlinks.  People can ‘port select’ 
> between maven3.0 and maven3.1.

Other than I don’t know any other example of a port name with a period (“.”) in 
it, so we might want to check that including version in this way doesn’t break 
anything, this looks like a perfectly acceptable proposal to me.

-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Promoting maven3 to 3.1.1

[Mark Evenson]

On Nov 23, 2013, at 9:20, Blair Zajac  wrote:

> Hi Mark,
> 
> Any reason for me not to update the maven3 port to 3.1.1?

Maven 3.1 is significantly different “under the hood” than Maven 3.0, 
especially in the adoption of the apache.org Aether connector.  This affected 
me with ABCL’s usage in that I needed to have both ports around to test things. 
  Since we have yet to make a release of abcl-1.3.0 which contains code for 
handling both maven-3.0.x and maven-3.1.x, an update of the maven3 port to 
3.1.1 will break `lang/abcl` for usage of Maven to dynamically download 
dependencies from the distributed POM graph.  But `lang/abcl` probably has a 
tiny enough user base that this will not create that much of a problem.  And I 
should get my act together to make a new release of ABCL.  

Two paths here that I see:  

1)  create a `maven31` port, move `maven-devel` over there, maybe use the 
`maven` port to install `maven31` by default.  I would then have a `mvn30` and 
`mvn31` symlink to the respective Maven installations, toggling the `mvn3` 
symlink depending on the “active” port in the “port —select” sense. 

2)  just update `maven3` to use Maven-3.1.1; remove `maven-revel`.  ABCL breaks 
for certain usages, but I handle it with email until I can make a new release.

Please let me know what you decide,
Mark


-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [112776] trunk/dports/lang/clisp/Portfile

[Mark Evenson]

On 11/11/13 1526 , 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


[…]


It should just be:

if {${os.platform} eq "darwin" && ${os.major} >= 11} {
 configure.cflags-append -Wl,-no_pie
}




This code has been [committed as 113206][r113206].

[r113206]: http://trac.macports.org/changeset/113206

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [112776] trunk/dports/lang/clisp/Portfile

[Mark Evenson]

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  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: [112830] trunk/dports/java/maven-devel/Portfile

[Mark Evenson]

On Nov 3, 2013, at 0:10, Ryan Schmidt  wrote:

> 
> On Nov 2, 2013, at 16:39, Frank Schima wrote:
> 
>> 
>> On Nov 2, 2013, at 8:17 AM, easie...@macports.org wrote:
>> 
>>># Symlink maven into the bin directory
>>> 
>>> -system "cd ${destroot}${prefix}/bin && ln -s 
>>> ../share/java/${name}/bin/mvn mvn3"
>>> 
>>> +system "cd ${destroot}${prefix}/bin && ln -s 
>>> ../share/java/${maven_dir}/bin/mvn mvn3”
>>> 
>> 
>> Using system “cd” seems totally unnecessary here. It would be best to only 
>> use the ln command and simply use absolute paths for both files. 
> 
> Or use the -W argument of the system command; that’s what it’s for.
> 

Changed to symbolic links in [r112879][].

N.b. both `java/maven3` and `java/maven2`--for neither of which am I
maintainer--contain the same sort of use of "cd  && ln -s https://trac.macports.org/changeset/112879


-- 
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #39698: sbcl @1.1.8: update to 1.1.9 and revbump maxima

[Mark Evenson]

No. The maintainer is on vacation until next week. The port is open maintainer 
if someone else has commit rights.
--

Tersely written with my 'Droid

MacPorts  wrote:

>#39698: sbcl @1.1.8: update to 1.1.9 and revbump maxima
>--+
>  Reporter:  crossd@… |  Owner:  easieste@…
>  Type:  update   | Status:  new
>  Priority:  Normal   |  Milestone:
> Component:  ports|Version:
>Resolution:   |   Keywords:  haspatch
>  Port:  sbcl maxima  |
>--+
>
>Comment (by crossd@…):
>
> Friendly Ping?  I believe this has fallen out of the maintainer window.
> Thanks!
>
>-- 
>Ticket URL: 
>MacPorts 
>Ports system for OS X
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #37954: Cleanup whitespace in SBCL Portfile.

[Mark Evenson]

On Feb 7, 2013, at 9:49 AM, MacPorts  wrote:

> #37954: Cleanup whitespace in SBCL Portfile.
> --+
>  Reporter:  crossd@… |  Owner:  easieste@…
>  Type:  enhancement  | Status:  reopened
>  Priority:  Normal   |  Milestone:
> Component:  ports|Version:
> Resolution:   |   Keywords:  haspatch
>  Port:  sbcl |
> --+
> Changes (by larryv@…):
> 
> * status:  closed => reopened
> * resolution:  wontfix =>
> 
> 
> Comment:
> 
> Correct, portfiles use 4-space indentation. However, on account of how
> ugly the sbcl portfile currently is, I’ve applied crossd’s patch and just
> converted the tabs to spaces.

Thanks!  I couldn't easily figure out what the intended alignment was, or I 
would have simply run untabify myself.


--
"A screaming comes across the sky.  It has happened before but there is nothing 
to compare to it now."

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #37214: Maxima not playing well with SBCL 1.1.2

[Mark Evenson]

On 12/6/12 3:58 AM, MacPorts wrote:

#37214: Maxima not playing well with SBCL 1.1.2
---+
   Reporter:  kirc0076@…|  Owner:  macports-tickets@…
   Type:  defect| Status:  new
   Priority:  Normal|  Milestone:
  Component:  ports |Version:  2.1.2
Resolution:|   Keywords:
   Port:  maxima, sbcl  |
---+

Comment (by jmr@…):

  IIRC it's necessary to increment maxima's revision every time sbcl's
  version is updated.



That's silly!  Any way I can do something to sbcl (like exporting an 
"Approved for Maxima" value or something) to make this unnecessary?



--

"A screaming comes across the sky.  It has happened before, but there is 
nothing to compare it to now."



___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #36111: ghc-7.4.2 fails to build on osx-12.1.0

[Mark Evenson]

On Sep 12, 2012, at 2:14 PM, MacPorts  wrote:

> I've seen similar issues which magically vanished when re-attempting the
> build. Can you just re-try and see if the issue persists? Also consider
> disabling parallel builds by appending build.jobs=1 to the command line
> you use to install ghc.

Re-running the install command seemingly gets me further in the
build, but again stops at another point with the same command.  So,
it is probably something with the parallel build colliding between
threads.  Since ghc is such a long compile anyways, instead of
limiting the threads bia build.jobs, I guess I will just keep
restarting the build.

THanks for the quick help.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [97575] trunk/dports/lang/ecl/Portfile

[Mark Evenson]

On Sep 9, 2012, at 2:52 PM, Ryan Schmidt  wrote:

> 
> On Sep 9, 2012, at 07:35, easie...@macports.org wrote:
> 
>> Needed to explicitly name llvm-gcc-4.2 as the compiler for OS X 12.x.
>> Maybe this needs to be done for other platforms?
> 
> Why? What happened using clang?

The build fails with clang, running into a segmentation fault when the 
bootstrap images attempts to compile the system Lisp.

> If anything, the compiler choice should be based on the Xcode version, not 
> the OS version.
> 
> Usually you'd just write:
> 
> compiler.blacklist clang

I don't have access to other OS X versions to test enough, so I thought that 
this would be the minimally destructive specification as I *know* that clang 
fails on OS X 12.x.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #35263: py27-hggit: update to 0.3.2

[Mark Evenson]

On Jul 20, 2012, at 13:53 , MacPorts wrote:

> #35263: py27-hggit: update to 0.3.2
> -+--
> Reporter:  leonardo.schenkel@…  |   Owner:  easieste@…   
> Type:  update   |  Status:  new  
> Priority:  Normal   |   Milestone:   
> Component:  ports| Version:  2.1.1
> Keywords:  haspatch |Port:  py27-hggit   
> -+--
> 
> Comment(by leonardo.schenkel@…):
> 
> It would be extremely nice if both py*-dulwich and py*-hggit are updated
> at the same time but it is not a hard requirement; hg-git does not depend
> in a specific version of dulwich (version 0.8.3 currently in MacPorts is
> fine).

Agreed. 

> Since Mercurial depends on Python 2.7, is there any reason for py26-hggit
> to be still maintained?

None that I know of.  Anyone else have an objection to removing py26-hggit as 
well?


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #35263: py27-hggit: update to 0.3.2

[Mark Evenson]

On Jul 20, 2012, at 12:20 , MacPorts wrote:

> #35263: py27-hggit: update to 0.3.2
> -+--
> Reporter:  leonardo.schenkel@…  |   Owner:  easieste@…   
> Type:  update   |  Status:  new  
> Priority:  Normal   |   Milestone:   
> Component:  ports| Version:  2.1.1
> Keywords:  haspatch |Port:  py27-hggit   
> -+--
> Changes (by ryandesign@…):
> 
>  * keywords:  => haspatch
>  * owner:  macports-tickets@… => easieste@…
> 
> 
> Comment:
> 
> Presumably py26-hggit should be updated at the same time. Ideally the two
> ports would be combined into a unified port.

Yep.  I just haven't gotten the time to study the other examples of Python 
version unification:  much  general refactored utility has been introduced in 
the last several year, but the documentation lags so I always end up reading 
the source.

> 
> Dependency py*-dulwich should be updated first; see #35262.


Thanks for the heads up.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [90432] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

On 3/5/12 19:23 , Ryan Schmidt wrote:


On Mar 5, 2012, at 03:56, easie...@macports.org wrote:


Revision: 90432
  http://trac.macports.org/changeset/90432
Author:   easie...@macports.org
Date: 2012-03-05 01:56:10 -0800 (Mon, 05 Mar 2012)
Log Message:
---
lang/sbcl:  Add variant to force use of llvm-gcc-4.2.



This was in response to [ticket #33446][1] for users who have XCode 4.2 
installed.  I suppose there is a better way to do this other than 
variant.  Could you please point me to documentation and/or a currently 
canonical example of determining which version of XCode is being used?


[1]: https://trac.macports.org/ticket/33446#comment:7

[…]



You've combined the $Id$ and modeline lines. The modeline should be the first 
line, and the $Id$ line should be the second line.



-long_description {


[…]



This still contains hard linebreaks. Every other port simply uses backslashes 
at the end of the line of the long_description, thus allowing MacPorts to 
insert soft linebreaks where appropriate for the terminal window's width -- 
just as the sbcl port did before you started making changes. :) It was really 
better the way it was before.


[…]

Both of these remaining metadata convention violations should be 
resolved in [r90463][2].


[2]: https://trac.macports.org/changeset/90463



If you have whitespace changes to make, they should be made in a separate 
commit.


Alright.  I'll try to avoid the temptation to tweak between functional 
commits…


[…]


+variant use-llvm-gcc-4.2 description {Force the use of LLVM GCC 4.2.
+This is perhaps better handled with the gcc_select port.} {
+configure.compiler llvm-gcc-4.2
+}


The gcc_select port is for the user's convenience in selecting a compiler for 
their use for things outside of MacPorts; ports themselves may not use the 
compiler the user has selected; ports use the default compiler for the 
currently-installed version of Xcode (which MacPorts sets the 
configure.compiler variable to), or a different compiler the port maintainer 
chose (by setting configure.compiler) if that's necessary for some reason.


Alright.  Confusion cleared up for me, although I think this is the 
second time you have pointed this out.  I guess I don't do enough daily 
work with Macport maintenance to have had this stick.  Hopefully I can 
keep it straight in the future.


[…]

Thanks for your patient mentoring here,
Mark


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [90393] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

On 3/4/12 22:51 , Ryan Schmidt wrote:


On Mar 4, 2012, at 07:11, easie...@macports.org wrote:


Revision: 90393
  http://trac.macports.org/changeset/90393
Author:   easie...@macports.org
Date: 2012-03-04 05:10:59 -0800 (Sun, 04 Mar 2012)
Log Message:
---
lang/sbcl: passes port lint and human inspection of output.


I pick further nits! See below.


[…]


Whereas before it was stored as a single line, and MacPorts was able to 
introduce line breaks in the correct places, regardless of terminal width:


The terminal output seems to wrap the text in funny places for me.

I guess that a string literal enclosed via "{" and "}" is quite a bit 
different from one not somehow.


I took another whack at fixing things in [r90432]()

[r90432]: http://trac.macports.org/changeset/90432

[…]


We don't manually add wording like "Enabled by default" to variant 
descriptions; MacPorts automatically indicates which variants are enabled by default when 
you use the default_variants command. For example the pango port:



[…]


The "[+]" before the x11 variant indicates that it is a default variant of the port and will be 
automatically selected. (The "(+)" before the universal variant indicates that it will also be 
automatically selected, but only because I have placed "+universal" into my variants.conf file.)


[…]


In the case of sbcl, it does not appear as though the threads variant is actually enabled 
by default. If you want it to be, add the line "default_variants +threads".


Ooh. That explains things.  I'll do that (make threads the default) in a 
subsequent commit, as it is certainly quite stable at this point.


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #33446: sbcl 1.0.55 won't build on lion

[Mark Evenson]

On 3/5/12 08:14 , MacPorts wrote:

#33446: sbcl 1.0.55 won't build on lion
--+-
  Reporter:  Ephaeton@…|   Owner:  easieste@…
  Type:  defect|  Status:  new
  Priority:  Normal|   Milestone:
Component:  ports | Version:  2.0.4
  Keywords:|Port:  sbcl
--+-

Comment(by jinxiaoyong@…):

  The default compiler breaks the compilation.  Adding

  {{{
  configure.compiler llvm-gcc-4.2
  }}}

  to the Portfile solves the problem.



Please review [the instructions for nominating the compiler used by 
macports][1], as the recommended way to do this would be to use the 
gcc_select port.  If that doesn't work, the lang/sbcl/Portfile is broken 
somehow.  I have very slow Lion machines (laptops with HDs), so testing 
is painful for me wrt time.


In the meantime, I have [added a variant 'use-llvm-gcc-4.2'][r90432] 
that includes the step suggested by jinxiaoyong@….


[1]: http://trac.macports.org/wiki/UsingTheRightCompiler

[r90432]: http://trac.macports.org/changeset/90432

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [90329] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

On Sun Mar  4 11:21:29 2012, Mark Evenson wrote:

I won't be back to my Mac until Monday, […]


Made it "back" early--useful thing OS X virtualization--so I managed to 
attempt to address your concerns in [svn r90303][r90303].


[r90303]: https://trac.macports.org/changeset/90393

Any further nits, please do not hesitate to pick.

yers in ports,
Mark

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [90329] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

I won't be back to my Mac until Monday, but I will then address the style 
issues caused by my recent commits to lang/sbcl.

Just some quick comments to the style issues:

The error message from whatever is emitting the lint message on Portffile 
commit should be fixed to indicate that the RCS Id keyword may be placed on the 
second line of a Portfile.

The intention of breaking the greater than 80 char comment line with the 
concatenated initialization instructions for vim/Emacs was to facilitate human 
editing.

As for the attempt at introducing multiline variant descriptions bounded by a 
Pythonesque triple  double-quote, the motivation was to introduce a more 
human-friendly syntax that would not require backslash escapes for many common 
characters.  It seemed to work in my tests, but I will revert to the previous 
form as requested.

Again, I will revert to the conventions outlined by Ryan when I get a chance 
but offer these comments to elucidate my thinking. 

Sent from my iPad

On Mar 4, 2012, at 6:18 AM, Ryan Schmidt  wrote:

> 
> On Mar 2, 2012, at 04:30, easie...@macports.org wrote:
> 
>> Revision: 90329
>> http://trac.macports.org/changeset/90329
>> Author:   easie...@macports.org
>> Date: 2012-03-02 02:30:54 -0800 (Fri, 02 Mar 2012)
>> Log Message:
>> ---
>> macports:lang/sbcl Satisfy lint by placing the RCS Id keyword in the first 
>> physical line.
>> 
>> Modified Paths:
>> --
>>   trunk/dports/lang/sbcl/Portfile
>> 
>> Modified: trunk/dports/lang/sbcl/Portfile
>> ===
>> --- trunk/dports/lang/sbcl/Portfile2012-03-02 10:13:30 UTC (rev 90328)
>> +++ trunk/dports/lang/sbcl/Portfile2012-03-02 10:30:54 UTC (rev 90329)
>> @@ -1,6 +1,6 @@
>> +# $Id$
>> # vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4
>> # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
>> c-basic-offset: 4 -*- 
>> -# $Id$
> 
> The modeline should be the first line, and the $Id$ line should be the second 
> line, as it shows in the Guide and in most existing portfiles.
> 
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [84577] trunk/dports/python/py26-hggit/Portfile

[Mark Evenson]

On Sep 29, 2011, at 7:13 AM, Ryan Schmidt wrote:

> On Sep 28, 2011, at 23:59, Mark Evenson wrote:
> 
>> On Sep 28, 2011, at 10:04 PM, Ryan Schmidt wrote:
>> 
>>> On Sep 28, 2011, at 09:27, easie...@macports.org wrote:
>>> 
>>>> namepy26-hggit
>>>> -version 0.2.6.6867b01d1379
>>>> +version 0.3.1
>>>> revision0
>>>> -epoch   201107011
>>>> +epoch   20110928
>>> 
>>> The epoch cannot decrease. "20110928" is less than "201107011".
>> 
>> Argh.  Should I now change this to "201109028"?
> 
> You can use any value you like, so long as it's an integer greater than or 
> equal to 201107011 :)
> 
> When you change the epoch, please also increase the revision, for reasons to 
> do with the buildbot and the binary packages it builds (since the epoch 
> number is not included in package names).


Alright.  Damn me and my long number dyslexia…
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [84577] trunk/dports/python/py26-hggit/Portfile

[Mark Evenson]

On Sep 28, 2011, at 10:04 PM, Ryan Schmidt wrote:

> 
> On Sep 28, 2011, at 09:27, easie...@macports.org wrote:
> 
>> Revision: 84577
>> http://trac.macports.org/changeset/84577
>> Author:   easie...@macports.org
>> Date: 2011-09-28 07:27:56 -0700 (Wed, 28 Sep 2011)
>> Log Message:
>> ---
>> Fix #31397: update to hggit-0.3.1
>> 
>> Modified Paths:
>> --
>>   trunk/dports/python/py26-hggit/Portfile
[…]
>> namepy26-hggit
>> -version 0.2.6.6867b01d1379
>> +version 0.3.1
>> revision0
>> -epoch   201107011
>> +epoch   20110928
> 
> The epoch cannot decrease. "20110928" is less than "201107011".

Argh.  Should I now change this to "201109028"?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [83049] trunk/dports/lang/ecl/Portfile

[Mark Evenson]

On 8/24/11 10:23 PM, Ryan Schmidt wrote:


It's not 11.1.1, but you're still installing it as if it were 11.1.1
(by not changing the version field)? Yuck.


Agreed that it is suboptimal from a "when I install ecl-11.1.1 I expect 
that exact version point of view".  But currently there is *no* working 
ecl for Lion via MacPorts.   My intention is to remove the git fetch 
when a proper ecl release is cut, making this a transitory situation.



If there are really so many changes from 11.1.1 that they could not
be expressed as a patchfile, this really should have been a new
ecl-devel port instead.


I wanted to get something out fast, rather than hunting through all the 
patches.  Creating an ecl-devel was the other option, but since this 
would ideally be a transient, one-time dependency, I opted to get the 
working port out there rather than having people hunt for ecl-devel.  If 
it turns out that this version of ECL under Lion is somehow bad, I 
promise to move to patches and/or ecl-devel.


My experience with xx-devel ports is that they "get stale".  They are 
used for a transient window, then the main trunk catches up to whatever 
caused the xx-devel version to be issued, and then the xx-devel lags. 
Can one remove a port and add it again later without issues?



Why is setting CC, CXX, CPP only applicable here and not in the
portfile generally?


ECL needs gcc-4.2 under Lion.  Setting configure.compiler wasn't enough: 
 the CC env. var. has to be passed to configure.  For other platforms, 
the default macports compilers are deemed to work.



--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #28262: hs-digest: configure fails to find zlib

[Mark Evenson]

No, I didn't modify macports.conf.

I agree it's a bit odd, but this is what worked for me.

Tersely written from my iPhone

On 10.08.2011, at 19:33, "MacPorts"  wrote:

> #28262: hs-digest: configure fails to find zlib
> ---+
> Reporter:  easieste@… |   Owner:  macports-tickets@…  
>  
> Type:  defect |  Status:  new 
>  
> Priority:  Normal |   Milestone:  
>  
> Component:  ports  | Version:  1.9.2  
>   
> Keywords: |Port:  hs-digest   
>  
> ---+
> 
> Comment(by ryandesign@…):
> 
> Are you saying you've removed ${prefix}/bin from binpath in macports.conf?
> Because that's the only reason why modifying PATH in that way in the
> portfile should have any effect. And modifying binpath in macports.conf is
> not recommended.
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for Mac OS
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [80550] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

On 7/14/11 8:04 PM, Jeremy Lavergne wrote:

Does the new sbcl version help this ticket at all?
http://trac.macports.org/ticket/30047

On Thu, July 14, 2011 1:55 pm, easie...@macports.org wrote:

Update to sbcl-1.0.50.




Answer: Unknown, as I have no access to Lion.

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #29837: sbcl: update to 1.0.49

[Mark Evenson]

I thought I committed this.  I'll check…

Sent from my iPad

On Jun 15, 2011, at 8:52 PM, "MacPorts"  wrote:

> #29837: sbcl: update to 1.0.49
> -+--
> Reporter:  ryandesign@… |   Owner:  easieste@…   
> Type:  update   |  Status:  new  
> Priority:  Normal   |   Milestone:   
> Component:  ports| Version:   
> Keywords:   |Port:  sbcl 
> -+--
> sbcl 1.0.49 is available since June 5; perhaps the port should be updated.
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for Mac OS
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [77859] trunk/dports/python

[Mark Evenson]

On Apr 18, 2011, at 08:36 , Ryan Schmidt wrote:

[…]

> Ports that are not python modules but merely use python probably should only 
> exist as a single port (whose name does not begin with a py*- prefix, and 
> which is not in the python category) and instead have variants for each 
> supported version of python.

The `py26-hggit' port gets installed into the respective python
implementation `site-packages' directory, so in that sense it is a
module (i.e. one could access it via a Python "import hggit"
statement).  But in practice, only the `mercurial' port would use
this, so this is more of a Mercurial extension than a Python module.
I see that the `mercurial' port is in the python26 Portgroup anyways,
so until that port gets rationalized into a multi-Python manner,
it makes sense that `py26-hggit' should stay as it is.  Maybe it
could be renamed to 'hggit' to make it clearer that this isn't
really a Python module that one expects to use.

--
"A screaming comes across the sky.  It has happened before, but there is 
nothing to compare to it now."




___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [77859] trunk/dports/python

[Mark Evenson]

On 4/18/11 7:36 AM, Ryan Schmidt wrote:


On Apr 15, 2011, at 00:32, easie...@macports.org wrote:


Revision: 77859
  http://trac.macports.org/changeset/77859
Author:   easie...@macports.org

[…]


Date: 2011-04-14 22:32:14 -0700 (Thu, 14 Apr 2011)
hg-git-0.2.6: Push to and pull from a Git server repository from Mercurial.

[…]

You should notes instead of ui_msg in post-activate.


Committed in [77955](http://trac.macports.org/changeset/77955).

As a side note: is there any mechanism, current or planned, to enable a 
port to work with multiple versions of Python as long as it uses 
something standard like distribute?  As far as I can tell the straight 
"py-" ports are only valid for python-2.4 and python-2.5.  A pointer to 
the relevant wiki section or mailing list thread would be appreciated.


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [73027] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

On Nov 12, 2010, at 15:24 , Jeremy Lavergne wrote:

[…]

>> 
>> How would the "grayer beards" than mine of MacPorts suggest I tackle
>> Ryan's suggestion?
> 
> You might simply set the two variants as conflicting.
> 
> variant X conflicts Y description {Z} { ... }

That's the current implementation.  Ryan's point is that logically
'pdf' should be a superset of 'html', so I am trying to accommodate
that request.

--
"A screaming comes across the sky.  It has happened before, but there is 
nothing to compare to it now."




___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [73027] trunk/dports/lang/sbcl/Portfile

[Mark Evenson]

On Nov 2, 2010, at 01:45 , Ryan Schmidt wrote:

[…]

> It sounds like the pdf variant does everything the html variant
> does, and then a little more. So why not make the pdf variant require
> the html variant, instead of making them conflict? Especially since
> the html variant is selected by default.

Logically I agree that your request makes sense, but I need some
conceptual help here due to my limited knowledge of Portfiles.  The
'html' variant works by patching the SBCL source to not install the
full documentation.  The 'pdf' variant needs this code not to be
patched to execute.  I didn't see a  way to temporally order the
execution of variant code-blocks, so I didn't know how to guarantee
the 'pdf' variant always "undoes" the patch if both variants are
specified.  If there is no way to temporally order variant clauses,
I guess the way around this is to find a Portfile phase after all
the variants have been executed to cleanup the corner cases.

With my submission of the sbcl-1.0.44 update yesterday, the 'html'
variant is no longer the default.

How would the "grayer beards" than mine of MacPorts suggest I tackle
Ryan's suggestion?

--
"A screaming comes across the sky.  It has happened before, but there is 
nothing to compare to it now."




___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #20132: ghc missing variable definitions in 10.6

[Mark Evenson]

On Mar 11, 2010, at 11:22 AM, MacPorts wrote:

[…]

> It sounds like you are trying to solve a harder problem than necessary.
> Getting the ghc port working at all looks like difficult task. I think
> installing one "flavor" of ghc is sufficient. Maybe that's naïve of me.

Not at all:  We're approaching six months after the release of Snow
Leopard, and we still don't have basic tools like darcs working.
Let's get something working please.

--

"A screaming comes across the sky.  It has happened before, but
there is nothing to compare to it now."





___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #20904: sbcl 1.0.29 fails to build on 10.6

[Mark Evenson]

On 12/24/09 2:34 PM, MacPorts wrote:
[…]

  Somehow, sometimes the POSIX return values for various tests on the
  filesystem return different values then expected.   I think the port
  itself has compiled ok, and would be okay to install.

  Not sure how to track this down in a reproducible manner.


A dim memory came to me in the meantime:  fixing the disk permissions 
via the Apple supplied Disk Utility "Repair Disk Permissions" got the 
system that this occurred on working again.


Could you possibly try this, reporting if it had any effect?


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #20904: sbcl 1.0.29 fails to build on 10.6

[Mark Evenson]

On 12/24/09 10:02 AM, MacPorts wrote:

#20904: sbcl 1.0.29 fails to build on 10.6
--+-
   Reporter:  luis.b...@…  |   Owner:  easie...@…
   Type:  defect   |  Status:  closed
   Priority:  Normal   |   Milestone:
  Component:  ports| Version:  1.8.0
Resolution:  fixed|Keywords:  snowleopard
   Port:  sbcl |
--+-

Comment(by jab...@…):

  When is it going to be available through selfupdate?



Dunno. I committed it to [svn in the usual place][1] about ten minutes 
ago, but it hasn't shown up via 'selfupdate'.


Is there an additional step to take that I didn't know about or have 
forgotten about?  I'll move the port status back to 'assigned' until I 
see it "take".


[1]: https://svn.macports.org/repository/macports/trunk/dports/lang/sbcl

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [65823] trunk/dports/python/py26-hgsvn

[Mark Evenson]

On 4/2/10 7:17 AM, Ryan Schmidt wrote:

On Apr 1, 2010, at 09:03, easie...@macports.org wrote:


Revision: 65823
  http://trac.macports.org/changeset/65823
Author:   easie...@macports.org
Date: 2010-04-01 07:03:34 -0700 (Thu, 01 Apr 2010)
Log Message:
---
Update to hgsvn-0.1.8.




Added: trunk/dports/python/py26-hgsvn/files/ez_setup.py
===
--- trunk/dports/python/py26-hgsvn/files/ez_setup.py
(rev 0)
+++ trunk/dports/python/py26-hgsvn/files/ez_setup.py2010-04-01 14:03:34 UTC 
(rev 65823)
@@ -0,0 +1,284 @@
+#!python


I thought a shebang line had to specify an absolute path?


Yes, it appears that shebang requires an absolute path under OS X, so I 
can't really explain the intention of that line.   I included 
'ez_setup.py' to be used inside Python to satisfy the "from ez_setup 
import use_setuptools" line in the hgsvn 'setup.py'.  From what I 
understand in the 'hgsvn' bug reports, this dependency will be corrected 
in subsequent releases.


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #12624: devel/git-core is missing a dependency on perl/p5-error

[Mark Evenson]

On Feb 22, 2010, at 4:26 PM, MacPorts wrote:

> #12624: devel/git-core is missing a dependency on perl/p5-error
> ---+
> Reporter:  even...@…  |   Owner:  macch...@…
> Type:  defect |  Status:  new   
> Priority:  Normal |   Milestone:
> Component:  ports  | Version:  1.5.0 
> Keywords: |Port:  git-core  
> ---+
> 
> Comment(by macch...@…):
> 
> I think this bug is obsolete as we have {{{path:bin/perl:perl5}}} and
> {{{port:p5-error}}} in the general {{{depends_run}}}.
> 
> Or am I missing a point here?


I filed this bug a *long* time ago, on a system that is long gone, so if your 
analysis shows that this isn't relevant, then please close the ticket.

--
"A screaming comes across the sky.  It has happened before, but there is 
nothing to compare to it now."




___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [62712] trunk/dports/lang/slime/Portfile

[Mark Evenson]

On 1/15/10 3:13 AM, Ryan Schmidt wrote:


On Jan 14, 2010, at 05:05, easie...@macports.org wrote:


Revision: 62712
  http://trac.macports.org/changeset/62712
Author:   easie...@macports.org
Date: 2010-01-14 03:05:34 -0800 (Thu, 14 Jan 2010)

[…]


You have some variant-duplication and -description issues here.



Fixed in svn r62730.

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [MacPorts] #21017: clisp 2.47 build failure 64-bit

[Mark Evenson]

On 11/2/09 3:11 AM, Sheldon W Thomas wrote:
[…]

Can anybody explain how to use the portfile listed on this bug to
install a working copy of clisp on 64bit Snow Leopard?
I'm so lost in documentation

[…]

1) create a directory somewhere called 'clisp'

2) copy the Portfile to the directory

3) from the 'clisp' directory issue the following command

osx$ sudo port -D . -v install

The '-D .' tells port to use the Portfile in the current directory; the 
'sudo' is the elevation of privileges necessary in the default 
installation of MacPorts.


Unfortunately, when I tried the Portfile this morning, the configure 
phases failed when it tried to link with the 64bit version of 
libsigsegv.  Maybe building with the '+nolibsigsegv' variant would work, 
but I ran out of time to try this.


If you are merely looking for a Common Lisp from MacPorts on Snow 
Leopard, both 'ecl' and 'abcl' are currently working.



--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Macports trac/wiki down?

[Mark Evenson]

Mark Evenson wrote:

Joshua Root wrote:

On 2009-7-6 22:51, Mark Evenson wrote:
The [Macports Trac instance][1] seems to have been down for several 
days.


[…]


I haven't noticed any downtime. What happens when you try to use it?


[…]


The following python trace:

Traceback (most recent call last):
  File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 
367, in send_error

'text/html')
  File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", line 
728, in render_template

if not req.session or not int(req.session.get('accesskeys', 0)):
  File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 


[…]

Apparently something screwy with my login ID, as coming in with a clean 
browser shows everything normal (I'm loathe to clear my main browser's 
cookies but I guess I should, and then iterate over the login ID).


Thanks to those who responded.


--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: Macports trac/wiki down?

[Mark Evenson]

Joshua Root wrote:

On 2009-7-6 22:51, Mark Evenson wrote:

The [Macports Trac instance][1] seems to have been down for several days.

Is there any status on when it might be back, or is it being no longer
used?


[1]: http://trac.macports.org/


I haven't noticed any downtime. What happens when you try to use it?

- Josh


The following python trace:

Traceback (most recent call last):
  File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 
367, in send_error

'text/html')
  File "/opt/local/lib/python2.5/site-packages/trac/web/chrome.py", 
line 728, in render_template

if not req.session or not int(req.session.get('accesskeys', 0)):
  File "/opt/local/lib/python2.5/site-packages/trac/web/api.py", line 
194, in __getattr__

value = self.callbacks[name](self)
  File "/opt/local/lib/python2.5/site-packages/trac/web/main.py", line 
267, in _get_session

return Session(self.env, req)
  File "/opt/local/lib/python2.5/site-packages/trac/web/session.py", 
line 156, in __init__

self.promote_session(sid)
  File "/opt/local/lib/python2.5/site-packages/trac/web/session.py", 
line 214, in promote_session

"WHERE sid=%s OR sid=%s ", (sid, self.req.authname))
  File "/opt/local/lib/python2.5/site-packages/trac/db/util.py", line 
50, in execute

return self.cursor.execute(sql_escape_percent(sql), args)
  File "/opt/local/lib/python2.5/site-packages/trac/db/util.py", line 
50, in execute

return self.cursor.execute(sql_escape_percent(sql), args)
ProgrammingError: current transaction is aborted, commands ignored until 
end of transaction block




--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Macports trac/wiki down?

[Mark Evenson]

The [Macports Trac instance][1] seems to have been down for several days.

Is there any status on when it might be back, or is it being no longer used?


[1]: http://trac.macports.org/

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [39976] trunk/dports/lang/slime/Portfile

[Mark Evenson]

Ryan Schmidt wrote:
[…]
 >
 > Ah, but you can't do it this way. This relies on emacs or emacs-app 
being installed. But it might not yet be installed at the time the user 
runs "port info" or "port variants" or "port fetch" or "port checksum" 
or "port deps" or "portindex" which will cause an error, like it's doing 
for the PortIndexRegen.sh script now:
 >
 > 
http://lists.macosforge.org/pipermail/macports-changes/2008-September/020930.html
 


Reverted [1] to previous buggy behavior (stuffing global variable 
assignment in 'configure').

[1]: http://trac.macports.org/changeset/39992

Does anybody have a suggestion how to implement the right behavior 
without breaking things?

I need to set some Portfile specific variables conditionally (like where 
to install the Elisp files based on which emacs is installed, which 
Emacs binary to use to byte-compile files).  If I set these variables in 
the 'configure' section, then if a user does a two step port 
installation (like a 'port build' followed by a 'port install') the 
variables are not set in the second invocation (because 'configure' is 
already marked as having been executed).

Any suggestions?

I supposed I could define a slime Portfile specific procedure, executing 
this explicitly before each phase that I need the variables set.



-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [35801] trunk/dports/lang/slime/Portfile

[Mark Evenson]

Ryan Schmidt wrote:



Also, are you the maintainer of this port, or were the changes approved 
by the maintainer, or did the maintainer not respond within 72 hours?




I am the maintainer of the port.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [35801] trunk/dports/lang/slime/Portfile

[Mark Evenson]

Ryan Schmidt wrote:
[...]
In the future could you please make functional changes separately from 
whitespace changes? That way we have a chance of understanding what 
functional changes were made, by looking at the diff.


Acknowledged.  The Portfile had so many accumulated changes *and* the 
Portfile had changed radically since I originally wrote the port (in 
2006?), that I pushed everything together.  Ticket [14136][1] has most 
of the blow by blow if you wish to construct.


[1]: http://trac.macosforge.org/projects/macports/ticket/14136

Also, one of your recent changes (possibly "Moved setup code from 
'configure' to 'platform darwin' (#macports jmr_mp)") has broken the 
port. It now does this:


I could use advice on how to move that code into a "global" section. 
Eventually all those variables should be moved into a "Emacsen" section 
of the base system, but for now, I was just trying to setup everything 
in one place in the Portfile.  I originally had that block in 
'configure', but that had the property that


  osx$ sudo port build slime
  osx$ sudo port install slime

would fail.

Any advice on where I can put such a section that is always invoked when 
the Portfile is parsed.  I need to dig through the base macports code 
more to understand how TCL is interpolating the Portfile, but pointers 
from the more knowledgable would be helpful.




$ port info slime
Error: Error executing darwin: Registry error: emacs not registered as 
installed.

Error: Unable to open port: Error evaluating variants
$

This is also blowing up the PortIndex process, therefore the port is 
(automatically) no longer being included in the PortIndex until this is 
fixed.


Mea culpa.  How do I run the PortIndex process manually to verify my fix?

Mark

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Can some kind committer please promote/comment on "emacs compiling on Leopard" ticket #13492

[Mark Evenson]

The ticket for [Emacs build broken under Leopard][1] has been open for a 
month, complete with a patch and verified solution.

Could kind soul please either commit this patch or respond with feedback 
as to what needs to be done?



[1]: http://trac.macosforge.org/projects/macports/ticket/13942

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re-requesting commit for 'lang/slime' 14136

[Mark Evenson]

I maintain 'lang/slime' but do not have commit rights.

Could someone please review the [Portfile attached to ticket 14136][1], 
and either provide feedback or commit it?  Extensive commentary on the 
changes has been attached to this ticket.

[1]: http://trac.macosforge.org/projects/macports/ticket/14136

Thanks,
Mark <[EMAIL PROTECTED]>
-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Updated Portfile for 'lang/slime' attached to ticket 14136

[Mark Evenson]

As maintainer of the 'lang/slime' port I have created an essentially 
reworked Portfile attached to ticket [14136][1] which:


* updates the SLIME sources to CVS HEAD of 20080203, which reflects the 
major refactoring into a 'contrib' subdirectory that occured in the last 
couple of months


* now has an 'app' variant that will install with the 'emacs-app' port 
(thanks to Jamison Hope for the initial patch)


* removed the obsolescent 'devel' variant ('emacs-devel' is no longer in 
the MacPorts trunk


* updated style to comply with what is outlined in 
http://guide.macports.org/#development.practices (no tabs, 4 column 
indents, Emacs/vim initial modeline)


* rewrote the sample '.emacs' initialization code message to conform 
with the new style enabling SLIME to more easily serve as the frontend 
to multiple Lisp (or with varying commandline options)



[1]: http://trac.macosforge.org/projects/macports/ticket/14136

Could someone please commit the Portfile?

Mark <[EMAIL PROTECTED]>

(who is a maintainer, but doesn't have commit rights, even though he is 
subscribed to the very chatty macports-change list, and is marked as the 
maintainer of 'lang/slime' and 'lang/nxml-mode', and wouldn't mind 
terribly if somebody wanted to change that situation).


___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Please commit openssh breakage on Leopard patch on ticket 13046

[Mark Evenson]

openssh on Leopard is broken as reported and fixed in ticket [13046][1], 
but the commit seems stalled over confusion of the proper maintainer.


Can someone please promote this to the correct party?



[1]: http://trac.macports.org/projects/macports/ticket/13046

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Maintainer but not committer with update: Submitted a Trac ticket, now I just wait?

[Mark Evenson]

I am the maintainer of 'lang/slime' for which I have submitted a ticket 
to Trac [1], attaching it to the Milestone "Port Updates".


Now I just wait for a committer to notice this, or should I bring it to 
some email address's attention?  The Wiki has the start [2] of guide to 
these questions, but no answers, for which it would be good to fill in 
even provisional answers to the procedure.



1: http://trac.macports.org/projects/macports/ticket/11902

2: http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort

___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev