Re: port ${name}

[Lawrence Velázquez]

On Oct 18, 2014, at 10:59 PM, Mark Brethen  wrote:

> At this point I issued 'sudo port clean reduce-csl' and everything was ok, 
> but should portfiles anticipate such an event?

We generally consider interrupted builds to be user error. If we eventually 
decide that we should clean up preemptively, then base should do it universally.

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

Re: port ${name}

[Ryan Schmidt]

On Oct 18, 2014, at 9:59 PM, Mark Brethen wrote:

> On Oct 18, 2014, at 9:50 PM, Ryan Schmidt wrote:
> 
>> On Oct 18, 2014, at 9:35 PM, Mark Brethen wrote:
>> 
>>> However an issue I've found is that if the install process is interrupted, 
>>> a subsequent re-issue of 'port install reduce' will fail due to the fact 
>>> that the subport that was interrupted isn't clean.
>> 
>> What error occurs?
> 
> I had canceled the install to make changes, and reissued the port install 
> command. 
> 
> brethen-mbp:ports marbre$ sudo port install reduce
> Password:
> Portfile changed since last build; discarding previous state.
> --->  Computing dependencies for reduce
> --->  Dependencies to be installed: reduce-csl reduce-psl
> --->  Fetching archive for reduce-csl
> --->  Attempting to fetch reduce-csl-20101217_0.darwin_13.x86_64.tbz2 from 
> http://packages.macports.org/reduce-csl
> --->  Attempting to fetch reduce-csl-20101217_0.darwin_13.x86_64.tbz2 from 
> http://mse.uk.packages.macports.org/sites/packages.macports.org/reduce-csl
> --->  Attempting to fetch reduce-csl-20101217_0.darwin_13.x86_64.tbz2 from 
> http://lil.fr.packages.macports.org/reduce-csl
> --->  Fetching distfiles for reduce-csl
> Error: org.macports.fetch for port reduce-csl returned: Subversion check out 
> failed
> Error: Failed to install reduce-csl
> Please see the log file for port reduce-csl for details:
>
> /opt/local/var/macports/logs/_Users_marbre_ports_math_reduce/reduce-csl/main.log
> Error: The following dependencies were not installed: reduce-csl reduce-psl
> To report a bug, follow the instructions in the guide:
>http://guide.macports.org/#project.tickets
> Error: Processing of port reduce failed
> 
> At this point I issued 'sudo port clean reduce-csl' and everything was ok, 
> but should portfiles anticipate such an event?

Ah, so you cancelled a Subversion fetch. Yes, it's normal for a second 
Subversion fetch on top of an incomplete one to fail; don't interrupt the fetch 
phase, or if you do, clean before trying again. Ports are not expected to 
individually handle this situation. If you believe it's a common enough problem 
that it needs to be handled at all, we could modify base to remove existing 
directories before a Subversion fetch.

This issue may apply to other revision control systems too, I'm not sure.

There is work in progress by Larry to cache these revision control system 
checkouts, which may affect how a solution to this issue gets implemented.




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

Re: port ${name}

[Mark Brethen]

On Oct 18, 2014, at 9:50 PM, Ryan Schmidt  wrote:

> 
> On Oct 18, 2014, at 9:35 PM, Mark Brethen wrote:
> 
>> if {${name} eq ${subport}} {
>>   supported_archs noarch
>>   distfiles
>>   archive_sites
>> 
>>   use_configure   no
>> 
>>   build   {}
>> 
>>   depends_build-append\
>>   port:reduce-common\
>>   port:reduce-csl\
>>   port:reduce-psl\
>>   port:reduce-addons
> 
> These should be depends_run.
> 
>> However an issue I've found is that if the install process is interrupted, a 
>> subsequent re-issue of 'port install reduce' will fail due to the fact that 
>> the subport that was interrupted isn't clean.
> 
> What error occurs?
> 

I had canceled the install to make changes, and reissued the port install 
command. 

brethen-mbp:ports marbre$ sudo port install reduce
Password:
Portfile changed since last build; discarding previous state.
--->  Computing dependencies for reduce
--->  Dependencies to be installed: reduce-csl reduce-psl
--->  Fetching archive for reduce-csl
--->  Attempting to fetch reduce-csl-20101217_0.darwin_13.x86_64.tbz2 from 
http://packages.macports.org/reduce-csl
--->  Attempting to fetch reduce-csl-20101217_0.darwin_13.x86_64.tbz2 from 
http://mse.uk.packages.macports.org/sites/packages.macports.org/reduce-csl
--->  Attempting to fetch reduce-csl-20101217_0.darwin_13.x86_64.tbz2 from 
http://lil.fr.packages.macports.org/reduce-csl
--->  Fetching distfiles for reduce-csl
Error: org.macports.fetch for port reduce-csl returned: Subversion check out 
failed
Error: Failed to install reduce-csl
Please see the log file for port reduce-csl for details:

/opt/local/var/macports/logs/_Users_marbre_ports_math_reduce/reduce-csl/main.log
Error: The following dependencies were not installed: reduce-csl reduce-psl
To report a bug, follow the instructions in the guide:
http://guide.macports.org/#project.tickets
Error: Processing of port reduce failed

At this point I issued 'sudo port clean reduce-csl' and everything was ok, but 
should portfiles anticipate such an event?

Mark




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

Re: port ${name}

[Ryan Schmidt]

On Oct 18, 2014, at 9:35 PM, Mark Brethen wrote:

> if {${name} eq ${subport}} {
>supported_archs noarch
>distfiles
>archive_sites
> 
>use_configure   no
> 
>build   {}
> 
>depends_build-append\
>port:reduce-common\
>port:reduce-csl\
>port:reduce-psl\
>port:reduce-addons

These should be depends_run.

> However an issue I've found is that if the install process is interrupted, a 
> subsequent re-issue of 'port install reduce' will fail due to the fact that 
> the subport that was interrupted isn't clean.

What error occurs?

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

Re: port ${name}

[Mark Brethen]

On Oct 13, 2014, at 4:03 PM, Ryan Schmidt  wrote:

> All ports must install at least one file. You can look at other metaports to 
> see what they do. Typically they create a file called README and put either a 
> placeholder message or the port's description into it.
> 
> You'll also want to set "supported_archs noarch" and clear "distfiles", and 
> you may as well clear "archive_sites" too.
> 
> I've requested that we make these kinds of ports easier by introducing a 
> "stub" keyword, but we don't have this yet.

I've written the stub like so:

# This is just a stub that installs all REDUCE subports.
if {${name} eq ${subport}} {
supported_archs noarch
distfiles
archive_sites

use_configure   no

build   {}

depends_build-append\
port:reduce-common\
port:reduce-csl\
port:reduce-psl\
port:reduce-addons

destroot {
# Create a dummy file so the port can be successfully activated.
xinstall -d ${docdir}
set docfile [open ${docdir}/README.${name}.txt "w"]
puts $docfile "REDUCE ${version} (MacPorts revision 
${version}_${revision})\n"
puts $docfile "${long_description}\n"
close $docfile
}
}

I don't think the order in which the subports are installed matters (I'm 
testing that presently). However an issue I've found is that if the install 
process is interrupted, a subsequent re-issue of 'port install reduce' will 
fail due to the fact that the subport that was interrupted isn't clean.

Mark




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

Re: depends

[Ryan Schmidt]

If B and C are different versions of the same program, for example a stable 
version and a development version, then it is usual to use a path:-style 
dependency. The ports should be named X and X-devel. The ports would install 
the same files to the same places and would be marked as conflicting with one 
another. See how ports depend on graphviz/graphviz-devel, pango/pango-devel, 
cairo/cairo-devel, glib2/glib2-devel for examples.

If B and C are different programs that serve a similar function, then it is 
usual to use port:-style dependencies. Have B and C not conflict with one 
another, and have them install files to different places. In D, offer variants 
for selecting B or C. Make the variants conflict and make one the default. In 
each variant, add the appropriate dependency and configure args. See how ports 
depend on gnutls/openssl, libiodbc/unixODBC for examples.


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

Re: depends

[Mark Brethen]

On Oct 18, 2014, at 9:09 PM, Ryan Schmidt  wrote:

> 
> On Oct 18, 2014, at 7:32 PM, Mark Brethen wrote:
> 
>> On Oct 18, 2014, at 7:19 PM, Ryan Schmidt wrote:
>> 
>>> 
>>> On Oct 18, 2014, at 7:16 PM, Mark Brethen wrote:
 
 On Oct 18, 2014, at 7:10 PM, Ryan Schmidt wrote:
 
> On Oct 18, 2014, at 1:41 PM, Mark Brethen wrote:
>> 
>> Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either 
>> port A or port B?
> 
> No, unless port A and port B are different versions of the same software 
> that install their files to the same locations.
> 
> For example, if your port requires Graphviz, then the dependency should 
> be written "path:bin/dot:graphviz"; thus either the graphviz port or the 
> graphviz-devel port will satisfy the dependency, since they both provide 
> (different versions of) the dot binary.
> 
> What is the specific scenario you're dealing with?
> 
> 
 
 I have four subports: A, B, C and D. Subports B, C depend on A (pretty 
 straightforward). Subport D depends on either B or C. The stub installs 
 all four.
>>> 
>>> Can you be more specific? What are B and C, what is their relationship to 
>>> one another? Do they install the same files?
>>> 
>>> 
>> 
>> A are common files, B and C are different lisp systems (mutually exclusive), 
>> and D contains extras (emacs  mode, batch shell script, and a terminal-based 
>> interactive frontend) that work with either B or C.
> 
> Are there any common files between B and C?
> 
> Will D link with a library in B or C? If so, is it the same library in both 
> of them, and are they ABI-compatible?
> 
> 

The terminal frontend hardcodes the binary path for both. So, maybe the install 
order doesn't matter (I'll check).

Mark




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

Re: Yosemite Build Slave

[Arno Hautala]

Cool, thanks for the update.

On Sat, Oct 18, 2014 at 1:18 PM, Joshua Root  wrote:
> On 2014-10-19 02:49 , Ryan Schmidt wrote:
>>
>> On Oct 18, 2014, at 8:20 AM, Arno Hautala wrote:
>>
>>> I know Yosemite is officially only a couple days old, but I was
>>> wondering if a new build slave is on the schedule. I think I recall
>>> hearing that they're all VMs now so setting up new versions should be
>>> "easier".
>>
>> We requested it at the beginning of the month but have not heard back yet.
>
> Shree mentioned to me that he was waiting on some internal IT stuff.
>
> - Josh



-- 
arno  s  hautala/-|   a...@alum.wpi.edu

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

Re: depends

[Ryan Schmidt]

On Oct 18, 2014, at 7:32 PM, Mark Brethen wrote:

> On Oct 18, 2014, at 7:19 PM, Ryan Schmidt wrote:
> 
>> 
>> On Oct 18, 2014, at 7:16 PM, Mark Brethen wrote:
>>> 
>>> On Oct 18, 2014, at 7:10 PM, Ryan Schmidt wrote:
>>> 
 On Oct 18, 2014, at 1:41 PM, Mark Brethen wrote:
> 
> Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either 
> port A or port B?
 
 No, unless port A and port B are different versions of the same software 
 that install their files to the same locations.
 
 For example, if your port requires Graphviz, then the dependency should be 
 written "path:bin/dot:graphviz"; thus either the graphviz port or the 
 graphviz-devel port will satisfy the dependency, since they both provide 
 (different versions of) the dot binary.
 
 What is the specific scenario you're dealing with?
 
 
>>> 
>>> I have four subports: A, B, C and D. Subports B, C depend on A (pretty 
>>> straightforward). Subport D depends on either B or C. The stub installs all 
>>> four.
>> 
>> Can you be more specific? What are B and C, what is their relationship to 
>> one another? Do they install the same files?
>> 
>> 
> 
> A are common files, B and C are different lisp systems (mutually exclusive), 
> and D contains extras (emacs  mode, batch shell script, and a terminal-based 
> interactive frontend) that work with either B or C.

Are there any common files between B and C?

Will D link with a library in B or C? If so, is it the same library in both of 
them, and are they ABI-compatible?


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

Re: depends

[Mark Brethen]

On Oct 18, 2014, at 7:19 PM, Ryan Schmidt  wrote:

> 
> On Oct 18, 2014, at 7:16 PM, Mark Brethen wrote:
>> 
>> On Oct 18, 2014, at 7:10 PM, Ryan Schmidt wrote:
>> 
>>> On Oct 18, 2014, at 1:41 PM, Mark Brethen wrote:
 
 Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either 
 port A or port B?
>>> 
>>> No, unless port A and port B are different versions of the same software 
>>> that install their files to the same locations.
>>> 
>>> For example, if your port requires Graphviz, then the dependency should be 
>>> written "path:bin/dot:graphviz"; thus either the graphviz port or the 
>>> graphviz-devel port will satisfy the dependency, since they both provide 
>>> (different versions of) the dot binary.
>>> 
>>> What is the specific scenario you're dealing with?
>>> 
>>> 
>> 
>> I have four subports: A, B, C and D. Subports B, C depend on A (pretty 
>> straightforward). Subport D depends on either B or C. The stub installs all 
>> four.
> 
> Can you be more specific? What are B and C, what is their relationship to one 
> another? Do they install the same files?
> 
> 

A are common files, B and C are different lisp systems (mutually exclusive), 
and D contains extras (emacs  mode, batch shell script, and a terminal-based 
interactive frontend) that work with either B or C.

Mark




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

Re: depends

[Ryan Schmidt]

On Oct 18, 2014, at 7:16 PM, Mark Brethen wrote:
> 
> On Oct 18, 2014, at 7:10 PM, Ryan Schmidt wrote:
> 
>> On Oct 18, 2014, at 1:41 PM, Mark Brethen wrote:
>>> 
>>> Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either 
>>> port A or port B?
>> 
>> No, unless port A and port B are different versions of the same software 
>> that install their files to the same locations.
>> 
>> For example, if your port requires Graphviz, then the dependency should be 
>> written "path:bin/dot:graphviz"; thus either the graphviz port or the 
>> graphviz-devel port will satisfy the dependency, since they both provide 
>> (different versions of) the dot binary.
>> 
>> What is the specific scenario you're dealing with?
>> 
>> 
> 
> I have four subports: A, B, C and D. Subports B, C depend on A (pretty 
> straightforward). Subport D depends on either B or C. The stub installs all 
> four.

Can you be more specific? What are B and C, what is their relationship to one 
another? Do they install the same files?


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

Re: depends

[Mark Brethen]

On Oct 18, 2014, at 7:10 PM, Ryan Schmidt  wrote:

> 
> On Oct 18, 2014, at 1:41 PM, Mark Brethen wrote:
>> 
>> Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either 
>> port A or port B?
> 
> No, unless port A and port B are different versions of the same software that 
> install their files to the same locations.
> 
> For example, if your port requires Graphviz, then the dependency should be 
> written "path:bin/dot:graphviz"; thus either the graphviz port or the 
> graphviz-devel port will satisfy the dependency, since they both provide 
> (different versions of) the dot binary.
> 
> What is the specific scenario you're dealing with?
> 
> 

I have four subports: A, B, C and D. Subports B, C depend on A (pretty 
straightforward). Subport D depends on either B or C. The stub installs all 
four.


Mark




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

Re: depends

[Ryan Schmidt]

On Oct 18, 2014, at 1:41 PM, Mark Brethen wrote:
> 
> Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either port 
> A or port B?

No, unless port A and port B are different versions of the same software that 
install their files to the same locations.

For example, if your port requires Graphviz, then the dependency should be 
written "path:bin/dot:graphviz"; thus either the graphviz port or the 
graphviz-devel port will satisfy the dependency, since they both provide 
(different versions of) the dot binary.

What is the specific scenario you're dealing with?


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

Re: svn conflict

[Ryan Schmidt]

On Oct 18, 2014, at 12:33 PM, Craig Treleaven wrote:
> 
>> Yes, you should fix the case of the directory. Since you have a 
>> case-insensitive filesystem, you'll need to do the move in the repository, 
>> rather than in your working copy:
>> 
>> https://subversion.apache.org/faq.html#case-change
> 
> In case anyone else is following along at home...
> 
> I did the move on the repository but still had a conflict as svn locally 
> believed the directory had the old name.  So I deleted 
> sysutils/MacPorts-daemondo locally and checked-out a new copy from the 
> server.  All seems well, now.

That'll work. Or following the update instructions in the Subversion FAQ item 
linked to above should work too.



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

Re: [126963] trunk/dports/lang/g95/Portfile

[Joshua Root]

On 2014-10-19 08:08 , Takeshi Enomoto wrote:
> fcomp is a comparison and a pop without a size, but
> I'm not sure if I should add s (32-bit) or l (64-bit).
> For example fmuls and movl are used before and after fcomp in line 412.
> 
> I don't speak assembler. Could anyone help me with asm?
> Comments on the patches in r126961 would be also appreciated.

I guess you could run the ambiguous mnemonic through gas and see what it
outputs.

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

Re: [126963] trunk/dports/lang/g95/Portfile

[Takeshi Enomoto]

Dear Ryan and all,

> This is unusual. What's the basis for this? Is it because of libstdc++? or 
> because of the clang version? or something else?

Thank you for noting this. This is not related to libstdc++ because g95 is 
written in C.
Probably it is due to clang version.

Clang is somewhat stricter than gas (GNU assembler).
Patches added in r126961 are meant to avoid ambiguity.
I added s for 8 and 16-bit integer and l for 32-bit load commands (fild).

The builds on Lion and Mountain Lion fail due to the assembly mnemonic `fcomp' 
in the following file.

g95-0.93/libf95.a-0.93/math/x87.S

fcomp is a comparison and a pop without a size, but
I'm not sure if I should add s (32-bit) or l (64-bit).
For example fmuls and movl are used before and after fcomp in line 412.

I don't speak assembler. Could anyone help me with asm?
Comments on the patches in r126961 would be also appreciated.

Regards,

Takeshi

r126961:


Clang doc:


Error:
/usr/bin/clang -DHAVE_CONFIG_H -I. -DHAVE_REAL_10=3 -Os -std=gnu89 -arch 
x86_64 -MT x87.o -MD -MP -MF .deps/x87.Tpo -c -o x87.o `test -f 'math/x87.S' || 
echo './'`math/x87.S
math/x87.S:1548:2: error: unknown use of instruction mnemonic without a size 
suffix
 fcomp
 ^

Buildbots:




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

Re: [126965] trunk/dports/python/py-mssql

[petr]

On 18 Oct 2014, at 17:45, Ryan Schmidt  wrote:

> 
>> On Oct 18, 2014, at 9:19 AM, p...@macports.org wrote:
>> 
>> Revision
>> 126965
>> Author
>> p...@macports.org
>> Date
>> 2014-10-18 07:19:30 -0700 (Sat, 18 Oct 2014)
>> Log Message
>> 
>> py-mssql: update to 2.1.0, remove py24, py25 subport
> 
> Perhaps we want to add them to py-graveyard?
> 
Done in r126988.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: depends

[Jeremy Lavergne]

You'd have it also share the variants/subport naming.

There's a portgroup for ensuring whether variants are selected:
https://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/active_variants-1.1.tcl

On Oct 18, 2014, at 3:13 PM, Mark Brethen wrote:

> Right, but I have subport C whose configure.args would be appended depending 
> on whether subport A or subport B or both are installed.

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

Re: depends

[Mark Brethen]

On Oct 18, 2014, at 2:09 PM, Jeremy Lavergne  wrote:

> Usually a variant or subport would achieve this.
> 
> On Oct 18, 2014, at 2:41 PM, Mark Brethen wrote:
> 
>> Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either 
>> port A or port B?
> 

Right, but I have subport C whose configure.args would be appended depending on 
whether subport A or subport B or both are installed.

Mark




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

depends

[Mark Brethen]

Is it possible to specify e.g lib-depends {port:A || port:B} i.e. either port A 
or port B?


Mark




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

Re: svn conflict

[Craig Treleaven]

At 11:24 AM -0500 10/18/14, Ryan Schmidt wrote:

On Oct 18, 2014, at 11:18 AM, Craig Treleaven wrote:


 At 10:59 AM -0500 10/18/14, Ryan Schmidt wrote:


 $ port lint MacPorts_daemondo
 --->  Verifying Portfile for MacPorts_daemondo
 Warning: Line 2 is missing RCS tag ($Id$)
 Error: Portfile directory macports_daemondo does not match port 
name MacPorts_daemondo

 --->  1 errors and 1 warnings found.


 I'm an svn newbie, where/how does the RCS tag get set?  I thought 
it was something that was automatically added by svn.


You manually put the line "# $Id$" as the second line of the 
portfile, after the modeline. Subversion fills in the details.


https://guide.macports.org/chunked/development.creating-portfile.html


 Should I now do 'svn move sysutils/macports_daemondo 
sysutils/MacPorts-daemondo' ?  Don't want to screw this up more...


Yes, you should fix the case of the directory. Since you have a 
case-insensitive filesystem, you'll need to do the move in the 
repository, rather than in your working copy:


https://subversion.apache.org/faq.html#case-change


In case anyone else is following along at home...

I did the move on the repository but still had a conflict as svn 
locally believed the directory had the old name.  So I deleted 
sysutils/MacPorts-daemondo locally and checked-out a new copy from 
the server.  All seems well, now.


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

Re: Yosemite Build Slave

[Joshua Root]

On 2014-10-19 02:49 , Ryan Schmidt wrote:
> 
> On Oct 18, 2014, at 8:20 AM, Arno Hautala wrote:
> 
>> I know Yosemite is officially only a couple days old, but I was
>> wondering if a new build slave is on the schedule. I think I recall
>> hearing that they're all VMs now so setting up new versions should be
>> "easier".
> 
> We requested it at the beginning of the month but have not heard back yet.

Shree mentioned to me that he was waiting on some internal IT stuff.

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

Re: [126965] trunk/dports/python/py-mssql

[Joshua Root]

On 2014-10-19 02:45 , Ryan Schmidt wrote:
> 
>> On Oct 18, 2014, at 9:19 AM, p...@macports.org wrote:
>>
>> Revision
>> 126965
>> Author
>> p...@macports.org
>> Date
>> 2014-10-18 07:19:30 -0700 (Sat, 18 Oct 2014)
>> Log Message
>>
>> py-mssql: update to 2.1.0, remove py24, py25 subport
> 
> Perhaps we want to add them to py-graveyard?

TBH I'm not convinced of the usefulness of replacing py24-foo with
py27-foo. We've never done it before when projects dropped support for
older pythons. If you really need to use foo in python24 for some
reason, having it in python27 doesn't help. And if it's a dependency for
something else, then that something else should presumably have been
updated. We have the 'obsolete' pseudo-portname to find out which
installed ports no longer exist in the tree.

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

Re: [126965] trunk/dports/python/py-mssql

[Ryan Schmidt]

On Oct 18, 2014, at 11:21 AM, petr wrote:
> 
> On 18 Oct 2014, at 17:45, Ryan Schmidt wrote:
> 
>> 
>>> On Oct 18, 2014, at 9:19 AM, p...@macports.org wrote:
>>> 
>>> Revision
>>> 126965
>>> Author
>>> p...@macports.org
>>> Date
>>> 2014-10-18 07:19:30 -0700 (Sat, 18 Oct 2014)
>>> Log Message
>>> 
>>> py-mssql: update to 2.1.0, remove py24, py25 subport
>> 
>> Perhaps we want to add them to py-graveyard?
> 
> Maybe, was considering this, but I am not really sure. 
> 
> This is not really related to the deprecation process.

Yes it is, in that we're in the process of deprecating all python 24 and 25 
modules, and other old python versions.

> The situation here is rather comparable to what we did earlier when updating 
> ports and older Python versions were not supported.

We did not have a good method for upgrading users to newer supported versions 
before; now, with py-graveyard, we do, and I think we should use it.

> But on the other hand, adding this to py-graveyard should not have any 
> drawback and might even provide a smoother user experience.
> 
> I understood, that the new subport (here: py27) should be already around when 
> adding to py-graveyard. So this always needs to be a two step process. But 
> keeping the unsupported subport(s) around when updating makes no sense. Right?
> 
> Should I add I now?

That's my suggestion.


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

Re: svn conflict

[Ryan Schmidt]

On Oct 18, 2014, at 11:18 AM, Craig Treleaven wrote:

> At 10:59 AM -0500 10/18/14, Ryan Schmidt wrote:
>> 
>> $ port lint MacPorts_daemondo
>> --->  Verifying Portfile for MacPorts_daemondo
>> Warning: Line 2 is missing RCS tag ($Id$)
>> Error: Portfile directory macports_daemondo does not match port name 
>> MacPorts_daemondo
>> --->  1 errors and 1 warnings found.
> 
> I'm an svn newbie, where/how does the RCS tag get set?  I thought it was 
> something that was automatically added by svn.

You manually put the line "# $Id$" as the second line of the portfile, after 
the modeline. Subversion fills in the details.

https://guide.macports.org/chunked/development.creating-portfile.html


> Should I now do 'svn move sysutils/macports_daemondo 
> sysutils/MacPorts-daemondo' ?  Don't want to screw this up more...

Yes, you should fix the case of the directory. Since you have a 
case-insensitive filesystem, you'll need to do the move in the repository, 
rather than in your working copy:

https://subversion.apache.org/faq.html#case-change


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

Re: [126965] trunk/dports/python/py-mssql

[petr]

On 18 Oct 2014, at 17:45, Ryan Schmidt  wrote:

> 
>> On Oct 18, 2014, at 9:19 AM, p...@macports.org wrote:
>> 
>> Revision
>> 126965
>> Author
>> p...@macports.org
>> Date
>> 2014-10-18 07:19:30 -0700 (Sat, 18 Oct 2014)
>> Log Message
>> 
>> py-mssql: update to 2.1.0, remove py24, py25 subport
> 
> Perhaps we want to add them to py-graveyard?

Maybe, was considering this, but I am not really sure. 

This is not really related to the deprecation process. The situation here is 
rather comparable to what we did earlier when updating ports and older Python 
versions were not supported. But on the other hand, adding this to py-graveyard 
should not have any drawback and might even provide a smoother user experience.

I understood, that the new subport (here: py27) should be already around when 
adding to py-graveyard. So this always needs to be a two step process. But 
keeping the unsupported subport(s) around when updating makes no sense. Right?

Should I add I now?
~petr

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

Re: svn conflict

[Craig Treleaven]

At 10:59 AM -0500 10/18/14, Ryan Schmidt wrote:

On Oct 18, 2014, at 8:22 AM, Craig Treleaven wrote:

 At 12:45 PM +0200 10/18/14, Peter Danecek wrote:

 On 18 Oct 2014, at 02:55, Craig Treleaven wrote:

 I've ended up with an svn conflict--just in the capitalization 
of the directory name, if I'm reading this right.


 SixBare:mp-trunk-ports craigtreleaven$ svn status
 ?   sysutils/MacPorts_daemondo
 ! C sysutils/macports_daemondo
  >   local add, incoming add upon update


 Might this be, because the underlaying FS is not case-sensitive 
(only case-preserving) so the two names would identify basically 
the same directory?


 Have you used `svn mv` to capitalise the name? Or how did you get 
into the current state?


 I don't know how it got out of sync.  I thought I committed it 
with uppercase in the directory name.  Anyway, I just changed the 
local directory name to lowercase, did 'svn update' and the 
conflict is gone.


You probably had the directory "MacPorts_daemondo" on disk, but ran 
"svn add macports_daemondo" which scheduled it for addition in the 
all-lowercase version. Subversion is always case-sensitive, even on 
case-insensitive-but-case-preserving filesystems.



 I can live with the lowercase directory name.


Note:

$ port lint MacPorts_daemondo
--->  Verifying Portfile for MacPorts_daemondo
Warning: Line 2 is missing RCS tag ($Id$)
Error: Portfile directory macports_daemondo does not match port name 
MacPorts_daemondo

--->  1 errors and 1 warnings found.


I'm an svn newbie, where/how does the RCS tag get set?  I thought it 
was something that was automatically added by svn.


Should I now do 'svn move sysutils/macports_daemondo 
sysutils/MacPorts-daemondo' ?  Don't want to screw this up more...


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

Re: [126921] trunk/dports/python/py-tvdb/Portfile

[petr]

On 17 Oct 2014, at 22:26, Ryan Schmidt  wrote:

> 
>> On Oct 17, 2014, at 1:33 PM, p...@macports.org wrote:
>> 
>> Revision
>> 126921
>> Author
>> p...@macports.org
>> Date
>> 2014-10-17 11:33:53 -0700 (Fri, 17 Oct 2014)
>> Log Message
>> 
>> py-tvdb: update to version 1.9, github portgroup, categories and license 
>> update, closes #39708
> 
> 
>> --- trunk/dports/python/py-tvdb/Portfile 2014-10-17 18:12:36 UTC (rev 
>> 126920)
>> +++ trunk/dports/python/py-tvdb/Portfile 2014-10-17 18:33:53 UTC (rev 
>> 126921)
>> @@ -3,27 +3,25 @@
>> 
>> PortSystem  1.0
>> PortGroup   python 1.0
>> +PortGroup   github 1.0
>> 
>> +github.setupdbr tvdb_api 1.9
>> namepy-tvdb
>> -version 1.5
>> +categories-append   net
>> platforms   darwin
>> supported_archs noarch
>> -license GPL-2
>> +license Public Domain
> 
> Please use "license public-domain". ("license Public Domain" means "This port 
> is under the license 'Public' and under the license 'Domain'.)
> 
Okay, understand. Done in r126939.
Thanks!
~petr


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

Re: CFPreferences warnings

[Ryan Schmidt]

On Oct 16, 2014, at 10:42 AM, Brandon Allbery wrote:

> This is just that these programs (in particular osacompile which is the 
> Applescript compiler) use the CFPreferences framework, which always looks for 
> stuff in $HOME before system locations, and for whatever reason the fake home 
> directory used by MacPorts builds is still pointing at /opt/local instead of 
> /opt/dvr. Since I don't see a macports.conf entry for it, this may well 
> indicate a shortcoming in the MacPorts base.
> 

Possibly this is coming from the home directory setting of the macports user.


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

Re: svn conflict

[Ryan Schmidt]

On Oct 18, 2014, at 8:22 AM, Craig Treleaven wrote:
> At 12:45 PM +0200 10/18/14, Peter Danecek wrote:
>> On 18 Oct 2014, at 02:55, Craig Treleaven wrote:
>> 
>>> I've ended up with an svn conflict--just in the capitalization of the 
>>> directory name, if I'm reading this right.
>>> 
>>> SixBare:mp-trunk-ports craigtreleaven$ svn status
>>> ?   sysutils/MacPorts_daemondo
>>> ! C sysutils/macports_daemondo
>>>  >   local add, incoming add upon update
>> 
>> Might this be, because the underlaying FS is not case-sensitive (only 
>> case-preserving) so the two names would identify basically the same 
>> directory?
>> 
>> Have you used `svn mv` to capitalise the name? Or how did you get into the 
>> current state?
> 
> I don't know how it got out of sync.  I thought I committed it with uppercase 
> in the directory name.  Anyway, I just changed the local directory name to 
> lowercase, did 'svn update' and the conflict is gone.

You probably had the directory "MacPorts_daemondo" on disk, but ran "svn add 
macports_daemondo" which scheduled it for addition in the all-lowercase 
version. Subversion is always case-sensitive, even on 
case-insensitive-but-case-preserving filesystems.

> I can live with the lowercase directory name.

Note:

$ port lint MacPorts_daemondo
--->  Verifying Portfile for MacPorts_daemondo
Warning: Line 2 is missing RCS tag ($Id$)
Error: Portfile directory macports_daemondo does not match port name 
MacPorts_daemondo
--->  1 errors and 1 warnings found.


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

Re: Yosemite Build Slave

[Ryan Schmidt]

On Oct 18, 2014, at 8:20 AM, Arno Hautala wrote:

> I know Yosemite is officially only a couple days old, but I was
> wondering if a new build slave is on the schedule. I think I recall
> hearing that they're all VMs now so setting up new versions should be
> "easier".

We requested it at the beginning of the month but have not heard back yet.


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

Re: [126963] trunk/dports/lang/g95/Portfile

[Ryan Schmidt]

> On Oct 18, 2014, at 7:05 AM, take...@macports.org wrote:
> 
> Revision
> 126963
> Author
> take...@macports.org
> Date
> 2014-10-18 05:05:00 -0700 (Sat, 18 Oct 2014)
> Log Message
> 
> g95: blacklist clang on Lion and Mountain Lion
> Modified Paths
> 
>   • trunk/dports/lang/g95/Portfile

> +if {${os.major} == 11 || ${os.major} == 12} {
> +compiler.blacklist-append   *clang*
> +}

This is unusual. What's the basis for this? Is it because of libstdc++? or 
because of the clang version? or something else?


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

Re: [126965] trunk/dports/python/py-mssql

[Ryan Schmidt]

> On Oct 18, 2014, at 9:19 AM, p...@macports.org wrote:
> 
> Revision
> 126965
> Author
> p...@macports.org
> Date
> 2014-10-18 07:19:30 -0700 (Sat, 18 Oct 2014)
> Log Message
> 
> py-mssql: update to 2.1.0, remove py24, py25 subport

Perhaps we want to add them to py-graveyard?


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

Re: svn conflict

[Craig Treleaven]

At 12:45 PM +0200 10/18/14, Peter Danecek wrote:

On 18 Oct 2014, at 02:55, Craig Treleaven  wrote:

 > I've ended up with an svn conflict--just in the capitalization of 
the directory name, if I'm reading this right.


 SixBare:mp-trunk-ports craigtreleaven$ svn status
 ?   sysutils/MacPorts_daemondo
 ! C sysutils/macports_daemondo
  >   local add, incoming add upon update


Might this be, because the underlaying FS is not case-sensitive 
(only case-preserving) so the two names would identify basically the 
same directory?


Have you used `svn mv` to capitalise the name? Or how did you get 
into the current state?


I don't know how it got out of sync.  I thought I committed it with 
uppercase in the directory name.  Anyway, I just changed the local 
directory name to lowercase, did 'svn update' and the conflict is 
gone.  I can live with the lowercase directory name.


Thanks,

Craig

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

Yosemite Build Slave

[Arno Hautala]

I know Yosemite is officially only a couple days old, but I was
wondering if a new build slave is on the schedule. I think I recall
hearing that they're all VMs now so setting up new versions should be
"easier".

Thanks,
--Arno

-- 
arno  s  hautala/-|   a...@alum.wpi.edu

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