review request -- sshuttle https://trac.macports.org/ticket/52198

2016-10-12 Thread Ken Cunningham 
https://trac.macports.org/ticket/52198

I think this port has reached a point where a review would be a reasonable ask. 

It was a requested port I filled -- a very useful piece of software for me. 
Helps you access a network behind a router with only ssh access to one machine. 
Nicely fills a need I had to access a hylafax server behind a firewall that has 
been an issue for me for years.

It is close to prime-time ready, but there is one hiccup.

There is something weird about the install process - it pauses for up to two 
minutes at a certain point, looks like it's hung, but then proceeds on. I 
assume something times out, but I can't figure out what it is.

Look forward to any comments.

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

Re: Building for 10.5 i386+ppc on 10.6 x86_64

2016-10-12 Thread Daniel J. Luke 
On Oct 12, 2016, at 5:36 AM, Mojca Miklavec  wrote:
> (Un)related question: the ticket is currently assigned to me. What's
> the best way to say something like "happy to accept any patches, but
> unable to actively work on it"? I miss a trac status to indicate that.
> I simply don't want to keep giving false impression that I'll actively
> try to fix the problem while. At the same time I *really* don't want
> to close the ticket with a "sorry, we're not interested" attitude. I
> would find it useful to get this working, I just don't have the
> resources to investigate too deeply.

I think it's fine to close as 'wontfix' with a note back to the reporter (and 
anyone who looks at the ticket in the future) explaining that you don't have 
time/resources to get the unsupported configuration working, but that you're 
happy to accept patches.

-- 
Daniel J. Luke



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

Re: Documentation overhaul

2016-10-12 Thread Bruce Miller 

On 10/12/2016 11:03 AM, Lawrence Velázquez wrote:

On Oct 12, 2016, at 10:30 AM, Bruce Miller  wrote:

On 10/09/2016 09:53 AM, Marcel Bischoff wrote:

Hi all.

As Ryan has identified that the online documentation needs work,


I would applaud this, while acknowledging that it will be a lot
of work.

To pick up on a comment from another thread:
Although I tend to program Perl like lisp, I might
program Tcl like fortran, since it seems to
me very much like fortran, or even cobol.


That's interesting. I've found Tcl to have interesting functional
properties, so I tend to write it pretty Lisp-y, for better or worse.

Not sure what this says about Tcl. Nothing good, I expect.


Probably my lack of familiarity does injustice to Tcl;
I have certainly competent colleagues that use it.

But still, many aren't familiar with it, so while
the MacPorts documentation shouldn't take on teaching
Tcl, it ought to provide plenty of examples of Tcl
"Done Right".


There's a *lot* of stuff in MacPorts, but much
isn't documented well, or at all. If I find example
portfiles doing similar things, they use magic that
I can't find explained anywhere.  An Index of commands
would be very useful.  And also PortGroups are very
powerful I think, I had particular needs from the
Perl & TeX groups. But: even reading the code, it
wasn't completely clear what functionality they
provided and what they didn't, and how best to use them.


I agree that our portgroup documentation is especially weak.

vq


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

Re: Documentation overhaul

2016-10-12 Thread Lawrence Velázquez 
> On Oct 12, 2016, at 10:30 AM, Bruce Miller  wrote:
> 
> On 10/09/2016 09:53 AM, Marcel Bischoff wrote:
>> Hi all.
>> 
>> As Ryan has identified that the online documentation needs work,
> 
> I would applaud this, while acknowledging that it will be a lot
> of work.
> 
> To pick up on a comment from another thread:
> Although I tend to program Perl like lisp, I might
> program Tcl like fortran, since it seems to
> me very much like fortran, or even cobol.

That's interesting. I've found Tcl to have interesting functional
properties, so I tend to write it pretty Lisp-y, for better or worse.

Not sure what this says about Tcl. Nothing good, I expect.

> There's a *lot* of stuff in MacPorts, but much
> isn't documented well, or at all. If I find example
> portfiles doing similar things, they use magic that
> I can't find explained anywhere.  An Index of commands
> would be very useful.  And also PortGroups are very
> powerful I think, I had particular needs from the
> Perl & TeX groups. But: even reading the code, it
> wasn't completely clear what functionality they
> provided and what they didn't, and how best to use them.

I agree that our portgroup documentation is especially weak.

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

Re: Building for 10.5 i386+ppc on 10.6 x86_64

2016-10-12 Thread Ryan Schmidt 

> On Oct 12, 2016, at 9:35 AM, Ken Cunningham  
> wrote:
> 
> 
> On 2016-10-12, at 2:36 AM, Mojca Miklavec wrote:
> 
>> Hi,
>> 
>> A while ago we got a bug report about problems building Perl on 10.6
>> x86_64 for 10.5 i386+ppc
>> 
>>   https://trac.macports.org/ticket/52290
>> 
>> To what extent is (or should be) this supported?
>> 
> 
> I would not expect this to be supported at all. It never has been, to my 
> knowledge.

The capability exists in MacPorts base to do this (by changing the sdk and 
deployment target in macports.conf), but it may not work for some ports. The 
MacPorts base functionality is supported, in that if there is a bug with it, we 
should fix it. The ability to build any given port using this feature is less 
well supported. You could conceivably say it's unsupported, in that I probably 
wouldn't expend too much effort to make this work, since it's such a niche 
feature. If the user can supply patches to make it work, of course we should 
consider incorporating them.


> However, it's not necessary anyway. Perl builds fine on all systems back to 
> Tiger (I added some evidence to the ticket report).

The user wished to build for 10.5 PowerPC on 10.6 Intel. The user may not have 
access to a machine that can run 10.5 to do the build natively.

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

Re: Can't edit commit message

2016-10-12 Thread Rainer Müller 
On 2016-10-12 16:33, take...@macports.org wrote:
> I can’t edit the commit message as described
> in https://trac.macports.org/wiki/CommitRules.
> 
> $ svn propedit --revprop svn:log -r 153822
> svn: E175008: While handling the 'svn:log' property on
> '/repository/macports/!svn/bln/153822':
> svn: E175008: Revprop change blocked by pre-revprop-change hook (exit
> code 1) with output:
> Changing revision properties is prohibited
> 
> Is the related to the transition to Github?

svn:log property editing was disabled in August [1] in order to allow
continuous conversion to Git. During testing we want to keep Git in sync
by only appending new revisions as editing old commits would require a
history rewrite with Git.

Rainer

[1]
https://lists.macosforge.org/pipermail/macports-dev/2016-August/033406.html
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Building for 10.5 i386+ppc on 10.6 x86_64

2016-10-12 Thread Ken Cunningham 

On 2016-10-12, at 2:36 AM, Mojca Miklavec wrote:

> Hi,
> 
> A while ago we got a bug report about problems building Perl on 10.6
> x86_64 for 10.5 i386+ppc
> 
>https://trac.macports.org/ticket/52290
> 
> To what extent is (or should be) this supported?
> 

I would not expect this to be supported at all. It never has been, to my 
knowledge.

However, it's not necessary anyway. Perl builds fine on all systems back to 
Tiger (I added some evidence to the ticket report).

Best,

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

Can't edit commit message

2016-10-12 Thread takeshi 
Hi,

I can’t edit the commit message as described in 
https://trac.macports.org/wiki/CommitRules 
.

$ svn propedit --revprop svn:log -r 153822
svn: E175008: While handling the 'svn:log' property on 
'/repository/macports/!svn/bln/153822':
svn: E175008: Revprop change blocked by pre-revprop-change hook (exit code 1) 
with output:
Changing revision properties is prohibited

Is the related to the transition to Github?

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

Re: Documentation overhaul

2016-10-12 Thread Bruce Miller 

On 10/09/2016 09:53 AM, Marcel Bischoff wrote:

Hi all.

As Ryan has identified that the online documentation needs work,


I would applaud this, while acknowledging that it will be a lot
of work.

To pick up on a comment from another thread:
Although I tend to program Perl like lisp, I might
program Tcl like fortran, since it seems to
me very much like fortran, or even cobol.
I don't particularly like Tcl, but so what?

My point is to tease, not flame, but really:
Tcl isn't the most widely know language these
days, and newbies to MacPorts and/or Tcl need
some help.

In writing the Portfile for LaTeXML, I needed to
do a couple of not-quite-standard things, and it
wasn't at all clear where to start.  I got a lot
of help from Mojca and Rainer, but that clearly
isn't fair to them, and slows the whole process down.
I think in the end the Portfile seems to work, and
is relatively clean & compact, to my eye
(but still needs to be committed; Hint :> )

There's a *lot* of stuff in MacPorts, but much
isn't documented well, or at all. If I find example
portfiles doing similar things, they use magic that
I can't find explained anywhere.  An Index of commands
would be very useful.  And also PortGroups are very
powerful I think, I had particular needs from the
Perl & TeX groups. But: even reading the code, it
wasn't completely clear what functionality they
provided and what they didn't, and how best to use them.

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

Building for 10.5 i386+ppc on 10.6 x86_64

2016-10-12 Thread Mojca Miklavec 
Hi,

A while ago we got a bug report about problems building Perl on 10.6
x86_64 for 10.5 i386+ppc

https://trac.macports.org/ticket/52290

To what extent is (or should be) this supported?

I remember that I tried to cross-compile clang/libc++ on 10.6 x86_64
for 10.5 ppc, but I gave up at some point because many ports do "if
this is darwin 9" rather than "if this is meant to build files for
darwin 9" and I would have to modify too many ports to get the desired
outcome. This is of course a different kind of problem, but still.

(Un)related question: the ticket is currently assigned to me. What's
the best way to say something like "happy to accept any patches, but
unable to actively work on it"? I miss a trac status to indicate that.
I simply don't want to keep giving false impression that I'll actively
try to fix the problem while. At the same time I *really* don't want
to close the ticket with a "sorry, we're not interested" attitude. I
would find it useful to get this working, I just don't have the
resources to investigate too deeply.

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

Re: path normalisation in "base"

2016-10-12 Thread Gustaf Neumann 

Am 11.10.16 um 16:38 schrieb René J.V. Bertin:

On Tuesday October 11 2016 16:04:21 René J.V. Bertin wrote:


{{{
proc macports::normalize { filename } {
set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
return [string map {${nprefix} ${macports::prefix}} [file normalize 
$filename]]
}
}}}

probably, the following works:

   proc macports::normalize { filename } {
  set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
  return [string map [list $nprefix ${macports::prefix}] [file normalize 
$filename]]
   }

The curly braces prevent variable substitution.
-g

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