re: [MacPorts] LibcxxOnOlderSystems modified

[Ken Cunningham]

We should be very careful about modifying Jeremy's LibCxxOnOlderSystems page -- 
would suggest we just send any suggestions to him, rather than touch that page. 
Too much detailed info to mess up accidentally.

Regarding building and running newer clangs on PPC, there is this report to get 
you started playing if you like, and shows how to solve the supported_archs 
issue you had.

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


It is quite complicated to move newer clangs to PPC, and in the end likely to 
be pointless, because PPC code coming out of clang / llvm is unreliable and 
there is no current plan to fix it. Some things might work on a spotty basis, 
for whatever good that is.


I would like to find some way of handing newer ObjC files on PPC, but don't 
really see that every coming. 

For now, if  your source doesn't build with gcc42, and if gcc5 or gcc6 doesn't 
handle the ObjC in the source, you're out of luck.


Ken

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

Re: [macports-ports] 01/02: New port for wallet @1.3

[Clemens Lang]

Hi Ryan,

On Sat, Nov 05, 2016 at 03:40:48AM -0500, Ryan Schmidt wrote:
> You should not use newlines in notes, unless you actually want the
> user to see a newline there, for example if you are starting a new
> paragraph or are constructing a list of items.

Thanks, fixed:
 https://github.com/macports/macports-ports/commit/f601b79

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

Re: [macports-ports] 01/02: New port for wallet @1.3

[Ryan Schmidt]

> On Nov 2, 2016, at 8:06 PM, Clemens Lang 
>  wrote:
> 
> Clemens Lang (neverpanic) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/a2792f4120bbf7fc5b7f771930da83895fd504f1
> 
> commit a2792f4120bbf7fc5b7f771930da83895fd504f1
> 
> Author: A. Karl Kornel 
> AuthorDate: Mon Oct 31 12:42:00 2016 -0700
> 
> 
> New port for wallet @1.3


> diff --git a/net/wallet/Portfile b/net/wallet/Portfile


> +# We have some post-activation setup that the user needs to do.
> 
> +notes-append "
> 
> +Before using the Wallet server, you will need to choose a database
> 
> +backend to use.  MySQL, Postgres, and SQLite are known to work.
> 
> +Then you will need to install the p5-datetime-format-* and p5-dbd-*
> 
> +ports that match the database backend you chose.
> 
> +
> 
> +If you want to support getting keytabs through Wallet, then your KDC
> 
> +will need to have the wallet port installed with the +kdc variant.
> 
> +
> 
> +Other Perl modules may be required, depending on what you want to
> 
> +support.  Read ${prefix}/share/doc/wallet/setup
> 
> +for additional server configuration instructions.
> 
> +
> 
> +Wallet server runs via remctl, so be sure that remctld is running,
> 
> +and is configured correctly!
> 
> +"
> 



> +# We have soe post-activation setup that the user needs to do.

Typo (soe => some)


> 
> +notes-append "
> 
> +To configure your KDC to generate keytabs for the Wallet server,
> 
> +you will need to configure etc/krb5kdc/allow-extract, as well as
> 
> +/etc/remctl/acl/keytab.  This uses remctl, so remctld must also
> 
> +be running and configured properly.
> 
> +"

You should not use newlines in notes, unless you actually want the user to see 
a newline there, for example if you are starting a new paragraph or are 
constructing a list of items.

When you're just making a paragraph of text, use a single long line, which 
MacPorts will word wrap to the user's terminal width.

You can wrap that long line in the portfile by using a backslash before a 
newline:

notes-append "
To configure your KDC to generate keytabs for the Wallet server,\
you will need to configure etc/krb5kdc/allow-extract, as well as\
/etc/remctl/acl/keytab.  This uses remctl, so remctld must also\
be running and configured properly.
"

Make sure there is no space before the backslash.

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

Re: [macports-ports] branch master updated: octave-image: add cxx11 portgroup, remove gcc-4.2 from compiler blacklist

[Ryan Schmidt]

> On Nov 4, 2016, at 15:18, Marius Schamschula 
>  wrote:
> 
> Marius Schamschula (Schamschula) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/1119466ab172e47ff602563e691649f1cbcae0cc
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 1119466  octave-image: add cxx11 portgroup, remove gcc-4.2 from 
> compiler blacklist
> 1119466 is described below
> 
> commit 1119466ab172e47ff602563e691649f1cbcae0cc
> Author: Marius Schamschula 
> AuthorDate: Fri Nov 4 15:16:37 2016 -0500
> 
> octave-image: add cxx11 portgroup, remove gcc-4.2 from compiler blacklist
> ---
>  math/octave-image/Portfile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/math/octave-image/Portfile b/math/octave-image/Portfile
> index 4da7048..ff6cc88 100644
> --- a/math/octave-image/Portfile
> +++ b/math/octave-image/Portfile
> @@ -2,6 +2,7 @@
>  
>  PortSystem  1.0
>  PortGroup   compiler_blacklist_versions 1.0
> +PortGroup   cxx11 1.0
>  PortGroup   octave 1.0
>  
>  octave.setupimage 2.6.1
> @@ -27,4 +28,4 @@ patchfiles-append   patch-src-Makefile.in.diff \
>  configure.env-append "PREFIX_BIN=${prefix}/bin"
>  
>  # https://savannah.gnu.org/bugs/?45096
> -compiler.blacklist-append   gcc-4.2 gcc-5.0 gcc-5.1
> +compiler.blacklist-append   gcc-5.0 gcc-5.1
> 

There is no compiler "gcc-5.0" nor "gcc-5.1". It's called "macports-gcc-5". 
There's also probably no reason to blacklist any MacPorts FSF GCC compiler 
because there is no circumstance in which MacPorts would automatically select 
it. ___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] CommittersGuide/PersonalSVNRepository modified

[Rainer Müller]

On 2016-11-04 05:01, Lawrence Velázquez wrote:
>> On Nov 2, 2016, at 9:40 PM, MacPorts  wrote:
>>
>> Page "CommittersGuide/PersonalSVNRepository" was changed by raimue
>> Diff URL: 
>> 
>> Revision 9
>> Comment: No longer applies after move to GitHub
>> Changes:

[...]

> Is there a reason you didn't just delete the page?

Deleting a wiki page also erases all of its history and it is irreversible.

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

Re: [MacPorts] #1: foo @1.2: fails to build from source

[Rainer Müller]

On 2016-11-03 15:01, MacPorts wrote:
> #1: foo @1.2: fails to build from source
> -+--
>   Reporter:  anonymous   |  Owner:  somebody
>   Type:  defect  | Status:  new
>   Priority:  blocker |  Milestone:
>  Component:  component1  |Version:
> Resolution:  |   Keywords:  haspatch
>   Port:  foo |
> -+--

Sorry, this notification was from my local test setup of Trac and should
not have gone to the real mailing list.

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

Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)

[Clemens Lang]

Hi,

On Wed, Nov 02, 2016 at 09:57:37AM -0700, Bradley Giesbrecht wrote:
>  Can you pass multiple tickets (closes x y z)?

Yes, space-separated, comma-separated, or because the ticket references
are quite long, just with multiple Closes $ticket lines.

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

Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)

[Bradley Giesbrecht]

> On Nov 1, 2016, at 5:47 PM, Rainer Müller  wrote:
> 
> On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote:
>> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70
> 
>> [...]
> 
>> commit 864eb7639d6774a7853767be6b15384c790bfe70
>> Author: Jeremy Huddleston Sequoia 
>> AuthorDate: Tue Nov 1 16:52:53 2016 -0700
>> 
>>libcxx: Bump to 3.9.0 (#52666)
>> 
>>Signed-off-by: Jeremy Huddleston Sequoia 
> 
> Please do not use the # syntax anymore in commit messages. This is now
> reserved for references to pull requests on GitHub. Instead, paste the
> full URL to the Trac ticket into the commit message:
> 
> Closes https://trac.macports.org/ticket/52666
> 
> When you add keywords such as "closes", "fixes", "fix" in front of the
> ticket URL, the ticket will also automatically be closed with a
> reference to the commit.

 Can you pass multiple tickets (closes x y z)?


Regards,
Bradley Giesbrecht (pixilla)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)

[Jeremy Huddleston Sequoia]

> On Nov 1, 2016, at 17:47, Rainer Müller  wrote:
> 
> On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote:
>> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
>> in repository macports-ports.
>> 
>> https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70
> 
>> [...]
> 
>> commit 864eb7639d6774a7853767be6b15384c790bfe70
>> Author: Jeremy Huddleston Sequoia 
>> AuthorDate: Tue Nov 1 16:52:53 2016 -0700
>> 
>>libcxx: Bump to 3.9.0 (#52666)
>> 
>>Signed-off-by: Jeremy Huddleston Sequoia 
> 
> Please do not use the # syntax anymore in commit messages. This is now
> reserved for references to pull requests on GitHub. Instead, paste the
> full URL to the Trac ticket into the commit message:
> 
> Closes https://trac.macports.org/ticket/52666
> 
> When you add keywords such as "closes", "fixes", "fix" in front of the
> ticket URL, the ticket will also automatically be closed with a
> reference to the commit.

Cool, thanks.  I missed that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: libcxx: Bump to 3.9.0 (#52666)

[Rainer Müller]

On 2016-11-02 00:54, Jeremy Huddleston Sequoia wrote:
> Jeremy Huddleston Sequoia (jeremyhu) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/864eb7639d6774a7853767be6b15384c790bfe70

> [...]

> commit 864eb7639d6774a7853767be6b15384c790bfe70
> Author: Jeremy Huddleston Sequoia 
> AuthorDate: Tue Nov 1 16:52:53 2016 -0700
> 
> libcxx: Bump to 3.9.0 (#52666)
> 
> Signed-off-by: Jeremy Huddleston Sequoia 

Please do not use the # syntax anymore in commit messages. This is now
reserved for references to pull requests on GitHub. Instead, paste the
full URL to the Trac ticket into the commit message:

Closes https://trac.macports.org/ticket/52666

When you add keywords such as "closes", "fixes", "fix" in front of the
ticket URL, the ticket will also automatically be closed with a
reference to the commit.

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

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Sean Farley]

Rainer Müller  writes:

> On 2016-11-01 19:23, Sean Farley wrote:
>> Lawrence Velázquez  writes:
>> 
>>> You should set your repository's user.email to your MacPorts email address.
>> 
>> Is this really necessary? I've seen mention of a mailmap but that hardly
>> seems like a big enough reason to force us to change user.email.
>> 
>> I'm pushing back on this, by the way, because I'd like to keep the fact
>> that I have one email for all the projects I've contributed to and this
>> is the first time there's been an email requirement.
>
> This is no hard requirement. However, all your existing commits were
> attributed to your @macports.org mail address.

Ah, I forgot I did my own custom map since I was using hgsubversion.

> I am only aware of one case where the commit author email address will
> be used:
>
> When you close a ticket with "Closes
> ​https://trac.macports.org/ticket/...; in a commit message, a comment
> will automatically be added to the corresponding ticket. This comment
> will be attributed to the author of the commit. By using the same email
> address for your commits that is also configured in Trac, you ensure
> that these comments will be properly attributed to you.

That is a fairly compelling reason so I'll go with that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub usernames as maintainers [Was: Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.]

[Rainer Müller]

On 2016-11-01 19:57, Clemens Lang wrote:
> On Tue, Nov 01, 2016 at 07:42:23PM +0100, Mojca Miklavec wrote:
>> At some point (rather sooner than later) we'll have to start adding
>> GitHub usernames to Portfiles (we might have to extend the base to
>> properly support that).
> 
> I agree, especially because the GitHub username is now also valid in
> Trac. At the moment, you'd get new tickets sent to your email address,
> not your Trac account (unless a user notices the equivalence in the
> auto-completion box).

Should we get Trac to automatically replace email addresses with the
corresponding username in the Owner and CC fields?

>> And quite honestly I would also be in favour of asking committers to
>> use the same MacPorts handle as their GitHub account name (and only
>> keep the old ones as aliases).
> 
> I like my handle, but I can see how it could lead to confusion. On the
> other hand, the maintainer handles are bound to become less important in
> the future anyway. If you want to reach a committer, there usually are
> contact methods on their GitHub profile.

Using GitHub usernames in the maintainer field has the downside that you
can no longer reach port maintainers outside of GitHub or Trac. There is
no requirement to have a public email address on the GitHub profile.

We could add a mapping of GitHub username to MacPorts handle to the
ports tree, but that would also only solve the problem for the
developers team, not outside collaborators.

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

GitHub usernames as maintainers [Was: Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.]

[Clemens Lang]

On Tue, Nov 01, 2016 at 07:42:23PM +0100, Mojca Miklavec wrote:
> If someone submits a pull request for a maintained port, the
> maintainer should probably be notified explicitly with @username. The
> problem is that currently only Trac maintainers have access to that
> mapping.

It's not a set of data I'd like to keep forever. We're requesting
people's non-public email addresses from GitHub to do the migration, not
to implement arbitrary other features on top of that data.


> At some point (rather sooner than later) we'll have to start adding
> GitHub usernames to Portfiles (we might have to extend the base to
> properly support that).

I agree, especially because the GitHub username is now also valid in
Trac. At the moment, you'd get new tickets sent to your email address,
not your Trac account (unless a user notices the equivalence in the
auto-completion box).

> And quite honestly I would also be in favour of asking committers to
> use the same MacPorts handle as their GitHub account name (and only
> keep the old ones as aliases).

I like my handle, but I can see how it could lead to confusion. On the
other hand, the maintainer handles are bound to become less important in
the future anyway. If you want to reach a committer, there usually are
contact methods on their GitHub profile.

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

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Rainer Müller]

On 2016-11-01 19:23, Sean Farley wrote:
> Lawrence Velázquez  writes:
> 
>> You should set your repository's user.email to your MacPorts email address.
> 
> Is this really necessary? I've seen mention of a mailmap but that hardly
> seems like a big enough reason to force us to change user.email.
> 
> I'm pushing back on this, by the way, because I'd like to keep the fact
> that I have one email for all the projects I've contributed to and this
> is the first time there's been an email requirement.

This is no hard requirement. However, all your existing commits were
attributed to your @macports.org mail address.

I am only aware of one case where the commit author email address will
be used:

When you close a ticket with "Closes
​https://trac.macports.org/ticket/...; in a commit message, a comment
will automatically be added to the corresponding ticket. This comment
will be attributed to the author of the commit. By using the same email
address for your commits that is also configured in Trac, you ensure
that these comments will be properly attributed to you.

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

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Mojca Miklavec]

On 1 November 2016 at 19:23, Sean Farley wrote:
> Lawrence Velázquez writes:
>
>> You should set your repository's user.email to your MacPorts email address.
>
> Is this really necessary? I've seen mention of a mailmap but that hardly
> seems like a big enough reason to force us to change user.email.
>
> I'm pushing back on this, by the way, because I'd like to keep the fact
> that I have one email for all the projects I've contributed to and this
> is the first time there's been an email requirement.

Under subversion you had absolutely no other choice, but to login with
your usern...@macports.org, so all your commits had that email
recorded. Personally I would be in favour to keep that convention and
to commit to MacPorts with your MacPorts handle. But I also agree that
raising the question of whether this is absolutely necessary is
perfectly valid.

Switching to GitHub raised a few other issues. Many committers now
have two different usernames, one MacPorts handle and one GitHub
account. And most (if not all) maintainers will now be known under
some GitHub username. If someone submits a pull request for a
maintained port, the maintainer should probably be notified explicitly
with @username. The problem is that currently only Trac maintainers
have access to that mapping. (You can potentially get the username by
checking the commit logs on the GitHub website ... but that takes a
lot of extra effort.)

At some point (rather sooner than later) we'll have to start adding
GitHub usernames to Portfiles (we might have to extend the base to
properly support that). And quite honestly I would also be in favour
of asking committers to use the same MacPorts handle as their GitHub
account name (and only keep the old ones as aliases).

Those are completely different questions of course.

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

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Sean Farley]

Lawrence Velázquez  writes:

> You should set your repository's user.email to your MacPorts email address.

Is this really necessary? I've seen mention of a mailmap but that hardly
seems like a big enough reason to force us to change user.email.

I'm pushing back on this, by the way, because I'd like to keep the fact
that I have one email for all the projects I've contributed to and this
is the first time there's been an email requirement.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[David Strubbe]

I just wanted to try out the new git setup to make sure things were working
for me, and this was a simple little thing to do.

On Mon, Oct 31, 2016 at 7:10 PM, Brandon Allbery 
wrote:

>
> On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez 
> wrote:
>
>> new 8ed388e berkeleygw: Remove svn $Id$ line.
>
>
> btw, given that it's not being automated because of the unnecessary builds
> it would trigger, I would say don't bother making commits that *only*
> remove the Id line. It's not harmful; it's just irrelevant with git. Just
> remember to remove the line as part of the next update you make.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Brandon Allbery]

On Mon, Oct 31, 2016 at 10:05 PM, Lawrence Velázquez 
wrote:

> new 8ed388e berkeleygw: Remove svn $Id$ line.


btw, given that it's not being automated because of the unnecessary builds
it would trigger, I would say don't bother making commits that *only*
remove the Id line. It's not harmful; it's just irrelevant with git. Just
remember to remove the line as part of the next update you make.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[David Strubbe]

Thanks, yes I just realized I hadn't set that up.

David

On Mon, Oct 31, 2016 at 7:05 PM, Lawrence Velázquez 
wrote:

> You should set your repository's user.email to your MacPorts email address.
>
> vq
>
> On Oct 31, 2016, at 9:50 PM, dstrubbe 
> wrote:
>
> dstrubbe pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/
> 8ed388e541ce01d92d698791fefd72a4bd2448c9
>
> The following commit(s) were added to refs/heads/master by this push: new 
> 8ed388e  berkeleygw: Remove svn $Id$ line.8ed388e is described below
> commit 8ed388e541ce01d92d698791fefd72a4bd2448c9Author: David Strubbe 
> 
> AuthorDate: Mon Oct 31 18:48:04 2016 -0700
> berkeleygw: Remove svn $Id$ line.---
>  science/berkeleygw/Portfile | 1 -
>  1 file changed, 1 deletion(-)
> diff --git a/science/berkeleygw/Portfile b/science/berkeleygw/Portfileindex 
> 0a82359..9f495ea 100644--- a/science/berkeleygw/Portfile+++ 
> b/science/berkeleygw/Portfile@@ -1,5 +1,4 @@ # -*- coding: utf-8; mode: tcl; 
> tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- 
> vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4-# $Id$
>  PortSystem  1.0
>  PortGroup   mpi 1.0
>
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Lawrence Velázquez]

You should set your repository's user.email to your MacPorts email address.

vq

> On Oct 31, 2016, at 9:50 PM, dstrubbe  
> wrote:
> 
> dstrubbe pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/8ed388e541ce01d92d698791fefd72a4bd2448c9
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 8ed388e  berkeleygw: Remove svn $Id$ line.
> 8ed388e is described below
> 
> commit 8ed388e541ce01d92d698791fefd72a4bd2448c9
> Author: David Strubbe 
> AuthorDate: Mon Oct 31 18:48:04 2016 -0700
> 
> berkeleygw: Remove svn $Id$ line.
> ---
>  science/berkeleygw/Portfile | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/science/berkeleygw/Portfile b/science/berkeleygw/Portfile
> index 0a82359..9f495ea 100644
> --- a/science/berkeleygw/Portfile
> +++ b/science/berkeleygw/Portfile
> @@ -1,5 +1,4 @@
>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> -# $Id$
>  
>  PortSystem  1.0
>  PortGroup   mpi 1.0
> 
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

So, now I ran *again* into a problem with my local install after self updating 
it just now:
---
$ port -v rev-upgrade
--->  Scanning binaries for linking errors
Warning: Error parsing file /opt/local/bin/cdda2wav: Error opening or reading 
file
Warning: Error parsing file /opt/local/bin/cdrecord: Error opening or reading 
file
Warning: Error parsing file /opt/local/bin/readcd: Error opening or reading file
Warning: Error parsing file /opt/local/sbin/rscsi: Error opening or reading file
Warning: Error parsing file /opt/local/libexec/dbus-daemon-launch-helper: Error 
opening or reading file
Incompatible library version: /opt/local/bin/imgcmp requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/imginfo requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/jasper requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/bin/tmrdemo requires version 12.0.0 or 
later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
Incompatible library version: /opt/local/lib/libjasper.1.dylib requires version 
12.0.0 or later, but /opt/local/lib/libjpeg.9.dylib provides version 11.0.0
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s):
 jasper @1.900.16 
 /opt/local/bin/imgcmp
 /opt/local/bin/imginfo
 /opt/local/bin/jasper
 /opt/local/bin/tmrdemo
 /opt/local/lib/libjasper.1.dylib
---

So, obviously, my own setup is borked. Turns out I have an older jpeg in my 
ports tree
---
$ port dir jpeg
/Users/marko/WC/GIT/macstrop/graphics/jpeg
---
which is the cause of trouble here.

I am sorry for rev-bumping! Not the first time that this happens to me. I have 
to become more careful!!!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Clemens Lang]

On Mon, Oct 31, 2016 at 08:08:26PM +0100, Marko Käning wrote:
> Doesn’t the second build of jasper justify the revbump, or should we
> simply ignore this and let rev-upgrade take care of it??

The revbump is justified. Your commit message should have mentioned why
it was necessary, though.

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

On 2016-11-1 06:34 , Marko Käning wrote:

On 31 Oct 2016, at 20:25 , Joshua Root  wrote:

Depends on the nature of the breakage, which is not shown above. The only 
dependency is jpeg, which has not changed in some time. My jasper installation 
is certainly not broken.


Hmmm…

OK, next time I need to get more detailed logs. Just don’t know how to get that 
done in the demoed workflow. :(


It would probably help to set:
revupgrade_mode report

Then if it finds anything, you can rerun with -v for details.


Maybe something else is being linked to, in which case simply rev bumping does 
not fix the problem. Or maybe something happened to your copy of jpeg that 
changed the soname, in which case that is the problem.


I don’t think I can do anything now there anymore.

Perhaps I better ask the list if I run into stg similar again and then we can 
decide together whether to revbump or not?


Tell me. That's what maintainers are for. :)

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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

On 31 Oct 2016, at 20:25 , Joshua Root  wrote:
> Depends on the nature of the breakage, which is not shown above. The only 
> dependency is jpeg, which has not changed in some time. My jasper 
> installation is certainly not broken.

Hmmm…

OK, next time I need to get more detailed logs. Just don’t know how to get that 
done in the demoed workflow. :(


> Maybe something else is being linked to, in which case simply rev bumping 
> does not fix the problem. Or maybe something happened to your copy of jpeg 
> that changed the soname, in which case that is the problem.

I don’t think I can do anything now there anymore.

Perhaps I better ask the list if I run into stg similar again and then we can 
decide together whether to revbump or not?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Joshua Root]

On 2016-11-1 06:08 , Marko Käning wrote:

Hi Joshua,

On 31 Oct 2016, at 18:04 , Joshua Root  wrote:

Why?


because I ran into this:
---
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16



Doesn’t the second build of jasper justify the revbump, or should we simply 
ignore this and let rev-upgrade take care of it??


Depends on the nature of the breakage, which is not shown above. The 
only dependency is jpeg, which has not changed in some time. My jasper 
installation is certainly not broken.


Maybe something else is being linked to, in which case simply rev 
bumping does not fix the problem. Or maybe something happened to your 
copy of jpeg that changed the soname, in which case that is the problem.


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

Re: [macports-ports] branch master updated: jasper: needs a revbump

[Marko Käning]

Hi Joshua,

On 31 Oct 2016, at 18:04 , Joshua Root  wrote:
> Why?

because I ran into this:
---
$ port dir jasper
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/graphics/jasper
$ sudo port upgrade outdated
--->  Computing dependencies for jasper
--->  Fetching archive for jasper
--->  Attempting to fetch jasper-1.900.16_0.darwin_13.x86_64.tbz2 from 
http://nue.de.packages.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16_0.darwin_13.x86_64.tbz2.rmd160 from 
http://nue.de.packages.macports.org/jasper
--->  Installing jasper @1.900.16_0
--->  Cleaning jasper
--->  Computing dependencies for jasper
--->  Deactivating jasper @1.900.5_0
--->  Cleaning jasper
--->  Activating jasper @1.900.16_0
--->  Cleaning jasper
--->  Uninstalling jasper @1.900.5_0
--->  Cleaning jasper
--->  Computing dependencies for py27-pycparser
--->  Fetching archive for py27-pycparser
--->  Attempting to fetch py27-pycparser-2.17_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py27-pycparser
--->  Attempting to fetch py27-pycparser-2.17_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py27-pycparser
--->  Installing py27-pycparser @2.17_0
--->  Cleaning py27-pycparser
--->  Computing dependencies for py27-pycparser
--->  Deactivating py27-pycparser @2.16_1
--->  Cleaning py27-pycparser
--->  Activating py27-pycparser @2.17_0
--->  Cleaning py27-pycparser
--->  Uninstalling py27-pycparser @2.16_1
--->  Cleaning py27-pycparser
--->  Computing dependencies for py27-setuptools
--->  Fetching archive for py27-setuptools
--->  Attempting to fetch py27-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py27-setuptools
--->  Attempting to fetch py27-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py27-setuptools
--->  Installing py27-setuptools @28.7.0_0
--->  Cleaning py27-setuptools
--->  Computing dependencies for py27-setuptools
--->  Deactivating py27-setuptools @28.5.0_0
--->  Cleaning py27-setuptools
--->  Activating py27-setuptools @28.7.0_0
--->  Cleaning py27-setuptools
--->  Uninstalling py27-setuptools @28.5.0_0
--->  Cleaning py27-setuptools
--->  Computing dependencies for py34-setuptools
--->  Fetching archive for py34-setuptools
--->  Attempting to fetch py34-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py34-setuptools
--->  Attempting to fetch py34-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py34-setuptools
--->  Installing py34-setuptools @28.7.0_0
--->  Cleaning py34-setuptools
--->  Computing dependencies for py34-setuptools
--->  Deactivating py34-setuptools @28.5.0_0
--->  Cleaning py34-setuptools
--->  Activating py34-setuptools @28.7.0_0
--->  Cleaning py34-setuptools
--->  Uninstalling py34-setuptools @28.5.0_0
--->  Cleaning py34-setuptools
--->  Computing dependencies for py35-setuptools
--->  Fetching archive for py35-setuptools
--->  Attempting to fetch py35-setuptools-28.7.0_0.darwin_13.noarch.tbz2 from 
http://nue.de.packages.macports.org/py35-setuptools
--->  Attempting to fetch py35-setuptools-28.7.0_0.darwin_13.noarch.tbz2.rmd160 
from http://nue.de.packages.macports.org/py35-setuptools
--->  Installing py35-setuptools @28.7.0_0
--->  Cleaning py35-setuptools
--->  Computing dependencies for py35-setuptools
--->  Deactivating py35-setuptools @28.5.0_0
--->  Cleaning py35-setuptools
--->  Activating py35-setuptools @28.7.0_0
--->  Cleaning py35-setuptools
--->  Uninstalling py35-setuptools @28.5.0_0
--->  Cleaning py35-setuptools
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16 
--->  Computing dependencies for jasper
--->  Cleaning jasper
--->  Scanning binaries for linking errors
--->  Found 5 broken file(s), matching files to ports
--->  Found 1 broken port(s), determining rebuild order
--->  Rebuilding in order
 jasper @1.900.16 
--->  Computing dependencies for jasper
--->  Fetching distfiles for jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://nue.de.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
https://distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://lil.fr.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://mse.uk.distfiles.macports.org/sites/distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://osl.no.distfiles.macports.org/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 
http://fco.it.distfiles.macports.org/mirrors/macports-distfiles/jasper
--->  Attempting to fetch jasper-1.900.16.tar.gz from 

Re: [MacPorts] #52645: qt5-qtbase build problem

[CeDeROM]

On Sun, Oct 30, 2016 at 2:07 AM, CeDeROM  wrote:
> On Sun, Oct 30, 2016 at 2:04 AM, MacPorts  wrote:
>> Comment (by MarcusCalhoun-Lopez):
>>  Are you by chance using libressl?[[BR]]
> Yes! LibreSSL in use. Will replace with OpenSSL and report back :-)

I can confirm this is the LibreSSL + QT issue! Thanks!!

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52645: qt5-qtbase build problem

[CeDeROM]

On Sun, Oct 30, 2016 at 2:04 AM, MacPorts  wrote:
> Comment (by MarcusCalhoun-Lopez):
>  Are you by chance using libressl?[[BR]]

Yes! LibreSSL in use. Will replace with OpenSSL and report back :-)

Why QT does not support LibreSSL? Is it QT or MacPorts?

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52663: libcxxabi patch to update to 3.9.0

[Ken Cunningham]

easy to do -- already have it done, actually, for my own testing. Up to
Jeremy, of course.

On Wed, Oct 19, 2016 at 7:27 PM, MacPorts  wrote:

> #52663: libcxxabi patch to update to 3.9.0
> --+
>   Reporter:  ken.cunningham.webuse@…  |  Owner:  jeremyhu@…
>   Type:  submission   | Status:  new
>   Priority:  Normal   |  Milestone:
>  Component:  ports|Version:  2.3.4
> Resolution:   |   Keywords:  haspatch
>   Port:  libcxxabi|
> --+
>
> Comment (by larryv@…):
>
>  I think the LLVM project clearly has a preference for CMake at this point.
>  We should probably switch to it for this port as we already have for the
>  LLVM ports.
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for the Mac operating system
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52468: gtk3 3.22.0_0 build fails on 10.5 ppc

[David Evans]

On 10/15/16 2:48 PM, MacPorts wrote:
> #52468: gtk3 3.22.0_0 build fails on 10.5 ppc
> -+--
>   Reporter:  dgonyier@…  |  Owner:  devans@…
>   Type:  defect  | Status:  assigned
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.3.4
> Resolution:  |   Keywords:  leopard
>   Port:  gtk3|
> -+--
> 
> Comment (by ken.cunningham.webuse@…):
> 
>  FYI - on 10.4 Tiger PPC:
> 
>  {{{
>  $ sudo port -v install gtk3 configure.compiler=macports-gcc-6
>  }}}
> 
>  results in success
>  {{{
> 
>gtk3 @3.22.1_0+x11 (active) platform='darwin 8' archs='ppc'
>  }}}
> 
>  without touching the portfile.
> 

You're on your own here.  The basic idea is that
you want to come up with a tool set that you will use for everything on
this platform.  And the dependencies too. Did you build all gtk3's dependencies
with gcc6 (and it's runtime)?

So the test is not whether gtk3 builds (a good start) but
whether everything you want to install (say the rest of the GNOME ports) build
as well.  Then there's the +quartz issue.  This is where things get 
interesting.  gcc6
has some support for objective C 1.0 and some 2.0 features but whether this
will work with Apple's objective C syntax and link with Apple frameworks is an
interesting unknown in my mind.

So the next thing I would try is building gtk3 +quartz and see what happens.

By the way, gtk3 builds a demo app, gtk3-demo, that demonstrates most of the 
API.
Give that a try and see what happens.  For this to look right you need to
install gnome-themes-standard too.  Would be interesting if I could run this
remotely using ssh -X.

This all goes toward establishing a tool chain that can be used reliably on your
platform.  That combined with your port repo overlay should be the biggest
part being able to build and use modern software on such an old platform.

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

Re: [MacPorts] #52246: Portfile for l3afpad (GTK+ 3 fork of leafpad)

[Russell Jones]

Hello David,

I've only tested on Linux via ssh -X and don't see this. I'll try with 
Xquartz. I'm testing on 10.11. If that works, I guess there's a missing 
dep. Which platform are you testing on?


Russell



On 30/09/16 18:59, MacPorts wrote:

#52246: Portfile for l3afpad (GTK+ 3 fork of leafpad)
--+--
   Reporter:  russell.jones@…  |  Owner:  devans@…
   Type:  submission   | Status:  assigned
   Priority:  Normal   |  Milestone:
  Component:  ports|Version:  2.3.4
Resolution:   |   Keywords:
   Port:  l3afpad  |
--+--

Comment (by devans@…):

  I was able to build the port but the menus don't function properly.  When
  clicking on say File, instead of a pulldown menu there, only a bold
  horizontal line is drawn.  Terminal output as follows.
  {{{
  Davids-Mac-mini:l3afpad devans$ !!
  l3afpad

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate toplevel GtkWindow 0x7fa1f3820520. Allocation is 1x1, but
  minimum required size is 216x66.

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkWindow's child GtkMenu 0x7fa1f38602c0. Allocation is 1x1,
  but minimum required size is 216x66.

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed

  (l3afpad:6558): Gtk-CRITICAL **:
  gtk_widget_get_preferred_height_for_width: assertion 'width >= 0' failed
  *** BUG ***
  In void pixman_region32_init_rect(region_type_t *, int, int, unsigned int,
  unsigned int): Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug

  *** BUG ***
  In void pixman_region32_init_rect(region_type_t *, int, int, unsigned int,
  unsigned int): Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug


  (l3afpad:6558): Gtk-WARNING **: Negative content width -7 (allocation 1,
  extents 4x4) while allocating gadget (node arrow, owner GtkMenu)

  (l3afpad:6558): Gtk-WARNING **: Negative content width -7 (allocation 1,
  extents 4x4) while allocating gadget (node arrow, owner GtkMenu)
  *** BUG ***
  In void pixman_region32_init_rect(region_type_t *, int, int, unsigned int,
  unsigned int): Invalid rectangle passed
  Set a breakpoint on '_pixman_log_error' to debug


  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkMenu's child GtkImageMenuItem 0x7fa1f3869470. Allocation
  is 1x138551296, but minimum required size is 52x24.

  (l3afpad:6558): Gtk-WARNING **: Negative content width -11 (allocation 1,
  extents 6x6) while allocating gadget (node menuitem, owner
  GtkImageMenuItem)

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkImageMenuItem's child GtkAccelLabel 0x7fa1f38665b0.
  Allocation is 1x138551288, but minimum required size is 27x14.

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkMenu's child GtkImageMenuItem 0x7fa1f3869640. Allocation
  is 1x138551296, but minimum required size is 56x24.

  (l3afpad:6558): Gtk-WARNING **: Negative content width -11 (allocation 1,
  extents 6x6) while allocating gadget (node menuitem, owner
  GtkImageMenuItem)

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkImageMenuItem's child GtkAccelLabel 0x7fa1f38667a0.
  Allocation is 1x138551288, but minimum required size is 44x14.

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkMenu's child GtkImageMenuItem 0x7fa1f3869810. Allocation
  is 1x138551296, but minimum required size is 52x24.

  (l3afpad:6558): Gtk-WARNING **: Negative content width -11 (allocation 1,
  extents 6x6) while allocating gadget (node menuitem, owner
  GtkImageMenuItem)

  (l3afpad:6558): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to
  underallocate GtkImageMenuItem's child GtkAccelLabel 0x7fa1f3866990.
  Allocation is 1x138551288, but minimum 

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Friday September 30 2016 03:48:09 Ryan Schmidt wrote:

> > Still: https://bugs.kde.org/show_bug.cgi?id=369554
> 
> Thanks.

Also see https://git.reviewboard.kde.org/r/127822/ for a prototype fix I 
started working on months ago...

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Sierk Bornemann]

> Am 30.09.2016 um 17:30 schrieb Lawrence Velázquez :
> 
>> On Sep 30, 2016, at 11:17 AM, Sierk Bornemann  wrote:
>> 
>> If you were right - why then implementing then case-sensitivity in the
>> first place instead of firstly implementing case-insensitivity?
> 
> I am no expert, but isn't implementing a case-sensitive filesystem
> *easier*? The classic Unix "bag of bits" is already inherently
> case-sensitive.

Seethe road, Apple already has taken since years with iOS, which is 
case-sensitive.

> My point is that we should not make assumptions about Apple's plans for the 
> future.

And my point is: go further than assumptions. Know and make sure, clarify it, 
read Apple developer documentations, if that does not suffice, ask an Apple 
expert/intern who really knows, if you yourself don’t know. :)


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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Sep 30, 2016, at 11:17 AM, Sierk Bornemann  wrote:
> 
> If you were right - why then implementing then case-sensitivity in the
> first place instead of firstly implementing case-insensitivity?

I am no expert, but isn't implementing a case-sensitive filesystem
*easier*? The classic Unix "bag of bits" is already inherently
case-sensitive.

> I, on your stead, would assume that Apple finally here begins to
> practically fulfill a years-long indicated paradigm change - towards
> case-sensitivity per default.

I am not interested in arguing about the merits of case (in)sensitivity
or guessing whether APFS will be case sensitive by default. My point is
that we should not make assumptions about Apple's plans for the future.

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Sep 30, 2016, at 11:10 AM, René J.V. Bertin  wrote:
> 
>> On Friday September 30 2016 10:10:40 Lawrence Velázquez wrote:
>> 
>> So users would have to have this disk image mounted at all times, just
>> in case they ever want to use anything installed by MacPorts?
> 
> Yes, but that can be completely transparent. The image can be mounted at an 
> appropriate time during the boot sequence, possibly on-demand by launchd. And 
> it can be configured not to show up as a volume on the desktop.
> Use a dynamically sized (sparse) disk image, and you get very close to ZFS 
> dataset.

That sounds like more work than it's worth.

>> Your moralizing is not appreciated. Cut it out.
>> Rest assured, "MacPorts" does not agree with your PoV on anything.
> 
> Your aggressiveness and overgeneralisation aren't appreciated either, cut 
> that out too.

You first.

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Sierk Bornemann]

> Am 30.09.2016 um 16:28 schrieb Lawrence Velázquez :
> 
>> On Sep 30, 2016, at 10:15 AM, Sierk Bornemann  wrote:
>> 
>>> Am 30.09.2016 um 09:53 schrieb Ryan Schmidt :
>>> 
 Apple could (and IMHO should) have made case-sensitivity the
 default and let everyone come to term with the fact that foo and
 Foo are not the same thing (or add normalising glue code in their
 highlevel APIs).
>>> 
>>> Apple has decided Mac OS has a case-insensitive filesystem by
>>> default; it's pointless to talk about what you think they should
>>> have done; they didn't do that.
>> 
>> Past/presence. But: Apple seems finally to go into case-sensitive per
>> default resp. case-sensitive-only:
>> 
>> Apples forthcoming APFS is/will be case sensitive per default, and
>> relating Sierra so far is case sensitive-only (when, if at all
>> case-insensitivity will be implemented, only Apple knows):
> 
> Given the nature of the other items on that list (no startup volumes, no
> Time Machine, no FileVault), it would be highly imprudent to assume that
> case-sensitivity-by-default is anything other than a corner that was cut
> to get the Developer Preview out the door.
> 
> vq

If you were right - why then implementing then case-sensitivity in the first 
place instead of firstly implementing case-insensitivity?
I, on your stead, would assume that Apple finally here begins to practically 
fulfill a years-long indicated paradigm change - towards case-sensitivity per 
default. Finally.
I think further, it would worth a check, if POSIX 2008 conformance on which the 
fresh Single UNIX Specification version 4 (SUSv4) of this current year 2016 
also mandats case-sensitivity per default, as I can read the POSIX 2008 
specification site on Open Group: 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html

[quote]
The Open Group Base Specifications Issue 7, IEEE Std 1003.1-2008, 2016 Edition, 
Copyright © 2001-2016 The IEEE and The Open Group
2. Conformance
2.1 Implementation Conformance
For the purposes of POSIX.1-2008, the implementation conformance requirements 
given in this section apply.
2.1.1 Requirements
A conforming implementation shall meet all of the following criteria:
[…]
The system may provide non-standard extensions. These are features not required 
by POSIX.1-2008 and may include, but are not limited to:
[…]
• Non-conforming file systems (for example, legacy file systems for 
which _POSIX_NO_TRUNC is false, case-insensitive file systems, or network file 
systems)
[…]
[/quote]

Apples OS X incl. Sierra so far conforms to SUSv3 based on (the old) POSIX 2001 
(meanwhile POSIX 2004 and POSIX 2008 have been published years ago).


Maybe a further inspection worth, which path Apple will go per default, if APFS 
is stable and shipped? Maybe asking some expert from Apple directly, who have 
insight and know more?
Case-insensitivity per default on Apples systems seems to come to en end. More 
than ever, if you realize, that in iOS, being the case sensitive HFSX by 
default.

And so https://developer.apple.com/library/content/qa/qa1697/_index.html

states:

[quote=Apple]Case-sensitivity: iPhone OS uses a case-sensitive file system, 
unlike the Simulator which uses a case-insensitive file system by default. Make 
sure the case-sensitivity of resources accessed within code matches the 
filename case-sensitivity.
[/quote]

Apple walks the case-sensitive path, with iOS being case sensitive per default 
since years, and they advice the developers since a very while to walk that 
path too and to make and assure their applications and their filesystem 
handling to be case sensitive. And OS X/macOS now marches the same path - 
towards case sensitivity per default, it will follow, all signs undeniably 
point to that direction. Finally!


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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Friday September 30 2016 10:10:40 Lawrence Velázquez wrote:

> So users would have to have this disk image mounted at all times, just
> in case they ever want to use anything installed by MacPorts?

Yes, but that can be completely transparent. The image can be mounted at an 
appropriate time during the boot sequence, possibly on-demand by launchd. And 
it can be configured not to show up as a volume on the desktop.
Use a dynamically sized (sparse) disk image, and you get very close to ZFS 
dataset.

> Your moralizing is not appreciated. Cut it out.
> Rest assured, "MacPorts" does not agree with your PoV on anything.

Your aggressiveness and overgeneralisation aren't appreciated either, cut that 
out too.

> On Friday September 30 2016 16:09:43 Sierk Bornemann wrote:
> > case sensitive per default, and relating Sierra so far is case
> > sensitive-only

I don't understand that; 10.12 installs to a case-sensitive HFS filesystem? 
Does it actually convert existing disks?

> > (when, if at all case-insensitity will be implemented,
> > only Apple knows).

I consider this good news, possibly the best thing (= with the most day-to-day 
usefulness) yet I've read about APFS (ApFS?! :)), together with "space sharing" 
if that's indeed comparable to ZFS datasets.
Case-insensitivity for Apple's target users doesn't have to be implemented at 
the FS level, I think. The user interface can provide natural language search 
facilities and handle mismatches in case transparently in the rare cases where 
you actually get to type in a filename to be opened without backup from a GUI 
that shows the matching filenames.

In fact, it should be possible to provide low/FS-level support to mimick the 
behaviour of case-insensitive HFS on top of actual case-sensitivity. If a file 
or path doesn't exist in the exact spelling, check if it exist disregarding 
case and if so use that instance. You'd probably not want to do that for 
creation, though :)

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Sep 30, 2016, at 10:15 AM, Sierk Bornemann  wrote:
> 
>> Am 30.09.2016 um 09:53 schrieb Ryan Schmidt :
>> 
>>> Apple could (and IMHO should) have made case-sensitivity the
>>> default and let everyone come to term with the fact that foo and
>>> Foo are not the same thing (or add normalising glue code in their
>>> highlevel APIs).
>> 
>> Apple has decided Mac OS has a case-insensitive filesystem by
>> default; it's pointless to talk about what you think they should
>> have done; they didn't do that.
> 
> Past/presence. But: Apple seems finally to go into case-sensitive per
> default resp. case-sensitive-only:
> 
> Apples forthcoming APFS is/will be case sensitive per default, and
> relating Sierra so far is case sensitive-only (when, if at all
> case-insensitivity will be implemented, only Apple knows):

Given the nature of the other items on that list (no startup volumes, no
Time Machine, no FileVault), it would be highly imprudent to assume that
case-sensitivity-by-default is anything other than a corner that was cut
to get the Developer Preview out the door.

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Sep 30, 2016, at 4:44 AM, René J.V. Bertin 
> wrote:
> 
>> On Friday September 30 2016 02:53:22 Ryan Schmidt wrote:
>> 
>> I am not aware of Apple installing files whose names differ only by
>> case; it wouldn't make sense for them to do so, given that the
>> default filesystem is case-insensitive and can't accommodate that.
>> If you believe they do install files that way, please give
>> a specific example.
> 
> No, I didn't say that, and you're right that makes it less of an issue
> (but still a bad idea to rely on a case-preserving feature, IMHO).

Case-insensitive and case-preserving are not the same thing.

>> Apple has decided Mac OS has a case-insensitive filesystem by
>> default; it's pointless to talk about what you think they should
>> have done; they didn't do that.
> 
> I don't agree; it's never too late to repent and do the right thing
> (in general).

Your moralizing is not appreciated. Cut it out.

> That's your right, but don't think you have the "moral high ground".
> Or do you consider that nothing in computer science and application
> should be case-sensitive?

We are not talking about about computer science. We are talking about
the Mac platform, on which most filesystems are case-insensitive.

> And in general MacPorts seem to agree with my PoV

Rest assured, "MacPorts" does not agree with your PoV on anything.

> otherwise the build bots wouldn't have used a case-sensitive
> filesystem.

We are in full control of those systems, so it's feasible for us to use
HFSX there. We do not control our users' systems.

> It's simple reality: a probably big majority of the ports provided
> come from a universe where case-sensitivity is the norm, and there's
> no point in crusading against this or projects making assumptions
> about it.

Our "simple reality" is that most of our users do not use HFSX, and
there's an equally strong argument to be made that we should not be
crusading against *that*.

vq

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

Re: [MacPorts] #52462: ALPSCore version update to 0.5.5

[Emanuel Gull]

Oh, got it:

https://guide.macports.org/chunked/project.update-policies.html

Port maintainers normally are given commit privileges to the Subversion 
repository so they can make updates to their own ports as described in Section 
7.4, “MacPorts Membership” 
. However, The 
MacPorts Project does not restrict commit privileges for maintainers, so before 
a person other than a port's maintainer updates a port it is a good practice to 
inform a port's maintainer. See details below.

…do you have commit privileges, or can you ask for it? this will speed up 
things dramatically…

Emanuel

> On Sep 30, 2016, at 3:16 PM, MacPorts  wrote:
> 
> #52462: ALPSCore version update to 0.5.5
> ---+--
>  Reporter:  egull@…   |  Owner:  galexv@…
>  Type:  update| Status:  new
>  Priority:  Normal|  Milestone:
> Component:  ports |Version:
> Resolution:|   Keywords:  haspatch
>  Port:  ALPSCore  |
> ---+--
> Changes (by mf2k@…):
> 
> * owner:  macports-tickets@… => galexv@…
> * cc: galexv@… (removed)
> * version:  2.3.4 =>
> 
> 
> Comment:
> 
> Please do not modify the {{{# $Id:}}} line. It may mean you have edited on
> old version of the Portfile.
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for the Mac operating system

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Sierk Bornemann]

> Am 30.09.2016 um 09:53 schrieb Ryan Schmidt :
>> Apple could (and IMHO should) have made case-sensitivity the default and let 
>> everyone come to term with the fact that foo and Foo are not the same thing 
>> (or add normalising glue code in their highlevel APIs).

> Apple has decided Mac OS has a case-insensitive filesystem by default; it's 
> pointless to talk about what you think they should have done; they didn't do 
> that.

Past/presence. But: Apple seems finally to go into case-sensitive per default 
resp. case-sensitive-only:
Apples forthcoming APFS is/will be case sensitive per default, and relating 
Sierra so far is case sensitive-only (when, if at all case-insensitivity will 
be implemented, only Apple knows):

Apple Developer Library: Apple File System Guide: FAQ: Compatibility
https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html#//apple_ref/doc/uid/TP40016999-CH6-DontLinkElementID_1

[quote]
Q: What are the limitations of Apple File System in macOS Sierra?
A: […]
° Case Sensitivity: Filenames are case-sensitive only.
[…]
[/quote]

ars technica (6/13/2016): Digging into the dev documentation for APFS, Apple’s 
new file system
http://arstechnica.com/apple/2016/06/digging-into-the-dev-documentation-for-apfs-apples-new-file-system/

[quote]
Perhaps most importantly, the file system currently is case-sensitive, and this 
cannot be disabled. HFS+ breaks with most Unix-y file systems in that it can be 
configured to not use case sensitivity; in fact, running OS X—ahem, macOS, 
sorry—with case-sensitive HFS+ can lead to its own problems. But, for now, if 
you want to use APFS, you’re going to do so on a non-startup volume, and you’re 
going to have to deal with case sensitivity.
[/quote]





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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Sep 30, 2016, at 3:39 AM, René J.V. Bertin 
> wrote:
> 
>> On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote:
>> 
>>> But why do it only for ${workpath}; the whole of ${prefix} could be
>>> on a case-sensitive RW dynamically-sized disk image (a sparse
>>> bundle?) that gets created by the MacPorts installer, with some
>>> magic to get it to mount automagically at the right time.
>>> 
>>> That would solve all case-sensitivity issues once and for all (or
>>> almost), without need for telling users to convert their whole
>>> (boot) volume to case-sensitivity. It's probably less easy to
>>> implement than it sounds, but maybe it's something to consider?
>> 
>> This sound convoluted. Also remember that MacPorts is not confined to
>> installing files in ${prefix}. 
> 
> A tad, maybe. Anything that gets installed outside of ${prefix} is
> largely out of control, but it's probably also safe to say that those
> files are where they are because they're somehow specific to the OS
> and thus don't make assumptions about filename case. 

So users would have to have this disk image mounted at all times, just
in case they ever want to use anything installed by MacPorts?

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Friday September 30 2016 03:48:09 Ryan Schmidt wrote:

>> Still: https://bugs.kde.org/show_bug.cgi?id=369554
>
>Thanks.

Let's not hold our breath though. Addressing this issue properly will be very 
invasive: lots of dependent code will require patches. And even if the patching 
can be done more or less automatically the patched code will then be locked to 
the latest version of the frameworks.

The only lever I really see is the fact that there has been a growing idea that 
KDE apps should behave as natively as possible; so support bundling as 
standalone app bundles on OS X. That will include support for dragging to and 
from FAT32 thumbdrives without breakage, and that's probably possible only if 
you make no assumptions at all about filename case.

Note however that MacPorts' reproducible-build principle also kind of imposes 
the use of a case-sensitive FS at the user end. I think that's the only way to 
guarantee that users build exactly the same binary images as the build bots 
do... ;)

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Ryan Schmidt]

> On Sep 30, 2016, at 3:44 AM, René J.V. Bertin  wrote:
> 
> Still: https://bugs.kde.org/show_bug.cgi?id=369554

Thanks.

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Friday September 30 2016 02:53:22 Ryan Schmidt wrote:

>I am not aware of Apple installing files whose names differ only by case; it 
>wouldn't make sense for them to do so, given that the default filesystem is 
>case-insensitive and can't accommodate that. If you believe they do install 
>files that way, please give a specific example.

No, I didn't say that, and you're right that makes it less of an issue (but 
still a bad idea to rely on a case-preserving feature, IMHO).

>Apple has decided Mac OS has a case-insensitive filesystem by default; it's 
>pointless to talk about what you think they should have done; they didn't do 
>that.

I don't agree; it's never too late to repent and do the right thing (in 
general).

>> Also: until the late nineties or whenever Mac OS X was first released, Mac 
>> OS wasn't a Unix OS. Until that time, Macs under Unix either ran some 
>> version of A/UX or Linux, both of which only had case-sensitive native 
>> filesystems.
>
>*That* was niche.

Yep. A niche application of a computer family that was more and more of a niche 
itself...

>> That's a bit arrogant as a statement...
>
>Maybe, but I'm sticking by it.

That's your right, but don't think you have the "moral high ground". Or do you 
consider that nothing in computer science and application should be 
case-sensitive?

>
>> There are simply a lot of them that do, and most of them *will* consider the 
>> Mac a niche "market". 
>
>They should be educated about their error.

Again, arrogance. This is an error only in the commercial sense. There is no 
error in considering the Mac a niche "market" of Gnome applications, for 
instance. And in general MacPorts seem to agree with my PoV; otherwise the 
build bots wouldn't have used a case-sensitive filesystem.
It's simple reality: a probably big majority of the ports provided come from a 
universe where case-sensitivity is the norm, and there's no point in crusading 
against this or projects making assumptions about it. Be it implicitly, or 
explicitly (by comparing the obtained path to the requested path, as I thought 
the compiler did). When individual ports break because of this you can try to 
do something about it upstream, but as a general attitude it would be Don 
Quixote'sque.

Still: https://bugs.kde.org/show_bug.cgi?id=369554

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Ryan Schmidt]

On Sep 30, 2016, at 2:39 AM, René J.V. Bertin wrote:

> On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote:
> 
>>> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
>>> standardised the behaviour of using capitalised letters in C++ header 
>>> filenames. 
>> 
>> Someone needs to make it clear to them that this is not a good idea. Not all 
>> filesystems are case sensitive. Mac OS has been around since 1984, always by 
>> default with a case insensitive filesystem, and Mac OS is used by a lot more 
>> people than Linux, so nobody has any excuse to be surprised by this anymore 
>> or to ignore this problem.
> 
> I agree but you do realise that Apple themselves do the same thing in their 
> SDK headers?

I am not aware of Apple installing files whose names differ only by case; it 
wouldn't make sense for them to do so, given that the default filesystem is 
case-insensitive and can't accommodate that. If you believe they do install 
files that way, please give a specific example.

> AppKit.h etc. C++ headers don't have an extension, or else a different one 
> (.hpp; see boost). IOW, aliasing isn't possible. The practice of putting 
> different classes of headers in directories with names distinguished only by 
> case is a much bigger problem, as we've seen.
> Don't forget that MS Windows also uses case-insensitive file systems by 
> default, and at least for Qt that most likely represents a much bigger 
> market. But that's ... Messy Windows Apple could (and IMHO should) have 
> made case-sensitivity the default and let everyone come to term with the fact 
> that foo and Foo are not the same thing (or add normalising glue code in 
> their highlevel APIs).

Apple has decided Mac OS has a case-insensitive filesystem by default; it's 
pointless to talk about what you think they should have done; they didn't do 
that.


> Also: until the late nineties or whenever Mac OS X was first released, Mac OS 
> wasn't a Unix OS. Until that time, Macs under Unix either ran some version of 
> A/UX or Linux, both of which only had case-sensitive native filesystems.

*That* was niche.


>>> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
>>> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
>>> created by the MacPorts installer, with some magic to get it to mount 
>>> automagically at the right time.
>>> 
>>> That would solve all case-sensitivity issues once and for all (or almost), 
>>> without need for telling users to convert their whole (boot) volume to 
>>> case-sensitivity. It's probably less easy to implement than it sounds, but 
>>> maybe it's something to consider?
>> 
>> This sound convoluted. Also remember that MacPorts is not confined to 
>> installing files in ${prefix}. 
> 
> A tad, maybe. Anything that gets installed outside of ${prefix} is largely 
> out of control, but it's probably also safe to say that those files are where 
> they are because they're somehow specific to the OS and thus don't make 
> assumptions about filename case. 
> 
>> Projects should not assume case sensitive filesystems.
> 
> That's a bit arrogant as a statement...

Maybe, but I'm sticking by it.

> There are simply a lot of them that do, and most of them *will* consider the 
> Mac a niche "market". 

They should be educated about their error.


>> I don't recall that, but maybe I forgot.
> 
> One thing is certain: GNU cp will raise an overwrite error when copying a 
> tree containing directories (and files?) differing only in case to a 
> case-insensitive location. Mac cp and BSD tar don't (the latter not even on 
> Linux).

Ok.


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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Thursday September 29 2016 18:21:15 Ryan Schmidt wrote:

>> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
>> standardised the behaviour of using capitalised letters in C++ header 
>> filenames. 
>
>Someone needs to make it clear to them that this is not a good idea. Not all 
>filesystems are case sensitive. Mac OS has been around since 1984, always by 
>default with a case insensitive filesystem, and Mac OS is used by a lot more 
>people than Linux, so nobody has any excuse to be surprised by this anymore or 
>to ignore this problem.

I agree but you do realise that Apple themselves do the same thing in their SDK 
headers? AppKit.h etc. C++ headers don't have an extension, or else a different 
one (.hpp; see boost). IOW, aliasing isn't possible. The practice of putting 
different classes of headers in directories with names distinguished only by 
case is a much bigger problem, as we've seen.
Don't forget that MS Windows also uses case-insensitive file systems by 
default, and at least for Qt that most likely represents a much bigger market. 
But that's ... Messy Windows Apple could (and IMHO should) have made 
case-sensitivity the default and let everyone come to term with the fact that 
foo and Foo are not the same thing (or add normalising glue code in their 
highlevel APIs).

Also: until the late nineties or whenever Mac OS X was first released, Mac OS 
wasn't a Unix OS. Until that time, Macs under Unix either ran some version of 
A/UX or Linux, both of which only had case-sensitive native filesystems.

>> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
>> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
>> created by the MacPorts installer, with some magic to get it to mount 
>> automagically at the right time.
>> 
>> That would solve all case-sensitivity issues once and for all (or almost), 
>> without need for telling users to convert their whole (boot) volume to 
>> case-sensitivity. It's probably less easy to implement than it sounds, but 
>> maybe it's something to consider?
>
>This sound convoluted. Also remember that MacPorts is not confined to 
>installing files in ${prefix}. 

A tad, maybe. Anything that gets installed outside of ${prefix} is largely out 
of control, but it's probably also safe to say that those files are where they 
are because they're somehow specific to the OS and thus don't make assumptions 
about filename case. 

>Projects should not assume case sensitive filesystems.

That's a bit arrogant as a statement... There are simply a lot of them that do, 
and most of them *will* consider the Mac a niche "market". 

>I don't recall that, but maybe I forgot.

One thing is certain: GNU cp will raise an overwrite error when copying a tree 
containing directories (and files?) differing only in case to a 
case-insensitive location. Mac cp and BSD tar don't (the latter not even on 
Linux).

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[Ryan Schmidt]

> On Sep 29, 2016, at 5:10 AM, René J.V. Bertin  wrote:
> 
> On Thursday September 29 2016 07:14:11 MacPorts wrote:
>> #49559: nepomuk-core can't be installed on a case-sensitive system
> 
> Hi,
> 
>> The new buildbot setup does not show this behavior, so I revbumped
>> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
>> case-sensitive systems. See also #42904.
> 
> Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
> standardised the behaviour of using capitalised letters in C++ header 
> filenames. 

Someone needs to make it clear to them that this is not a good idea. Not all 
filesystems are case sensitive. Mac OS has been around since 1984, always by 
default with a case insensitive filesystem, and Mac OS is used by a lot more 
people than Linux, so nobody has any excuse to be surprised by this anymore or 
to ignore this problem.


> I've been thinking recently about how this kind of thing could be avoided, in 
> relation to my earlier question about the build directory. I toyed with the 
> idea that instead of being a simple subdirectory, ${workpath} could be the 
> mountpoint of a RW dmg with appropriate filesystem settings, like 
> case-sensitivity. 
> 
> But why do it only for ${workpath}; the whole of ${prefix} could be on a 
> case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
> created by the MacPorts installer, with some magic to get it to mount 
> automagically at the right time.
> 
> That would solve all case-sensitivity issues once and for all (or almost), 
> without need for telling users to convert their whole (boot) volume to 
> case-sensitivity. It's probably less easy to implement than it sounds, but 
> maybe it's something to consider?

This sound convoluted. Also remember that MacPorts is not confined to 
installing files in ${prefix}. Projects should not assume case sensitive 
filesystems.


> Something else: I seem to recall preprocessor errors either on `#include 
> ` or `#include ` even if the underlying system calls 
> (fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless 
> the exact case, on a case-insensitive HFS. I can no longer reproduce this, 
> but has that been a known issue at some point? Or is it just a figment of my 
> imagination (if not simply the result of a testing error)?

I don't recall that, but maybe I forgot.

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

Re: [MacPorts] #49559: nepomuk-core can't be installed on a case-sensitive system (was: neponuk can't be installed on a case-sensitive system)

[René J . V . Bertin]

On Thursday September 29 2016 07:14:11 MacPorts wrote:
>#49559: nepomuk-core can't be installed on a case-sensitive system

Hi,

> The new buildbot setup does not show this behavior, so I revbumped
> nepomuk-core in r153339 so that all the packages are correctly rebuilt for
> case-sensitive systems. See also #42904.

Ah, good news, because Qt5 and the KF5 frameworks have unfortunately 
standardised the behaviour of using capitalised letters in C++ header 
filenames. 

I've been thinking recently about how this kind of thing could be avoided, in 
relation to my earlier question about the build directory. I toyed with the 
idea that instead of being a simple subdirectory, ${workpath} could be the 
mountpoint of a RW dmg with appropriate filesystem settings, like 
case-sensitivity. 

But why do it only for ${workpath}; the whole of ${prefix} could be on a 
case-sensitive RW dynamically-sized disk image (a sparse bundle?) that gets 
created by the MacPorts installer, with some magic to get it to mount 
automagically at the right time.

That would solve all case-sensitivity issues once and for all (or almost), 
without need for telling users to convert their whole (boot) volume to 
case-sensitivity. It's probably less easy to implement than it sounds, but 
maybe it's something to consider?

Something else: I seem to recall preprocessor errors either on `#include 
` or `#include ` even if the underlying system calls 
(fopen("foo/foo.h","r") or fopen("Foo/Foo","r")) should succeed regardless the 
exact case, on a case-insensitive HFS. I can no longer reproduce this, but has 
that been a known issue at some point? Or is it just a figment of my 
imagination (if not simply the result of a testing error)?

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

Re: [MacPorts] WorkingWithGit modified

[Joshua Root]

On 2016-9-24 06:02 , Ryan Schmidt wrote:


I think we should be able to add build status to commits. Building untrusted 
pull requests is however an entirely different matter. We would have to set up 
a new VM for each build. It's conceivable, but nothing of the kind is currently 
set up or in progress.


Autobuilding pull requests should be a lot safer for base than for 
ports, and that's all we have automated testing set up for at the moment 
anyway. I guess it would still be possible to add malicious code to the 
build system or test suite that performs a DoS or something.


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

Re: [MacPorts] WorkingWithGit modified

[Lawrence Velázquez]

> On Sep 23, 2016, at 2:38 PM, Ryan Schmidt  wrote:
> 
> If you commit directly to master of your fork, then submit a pull
> request, you can't do anything else on master until your pull request
> is accepted. If you make further changes on master they will be
> included in the pull request, which you wouldn't want if they are
> unrelated changes. And once your pull request is merged, then what?
> GitHub will give you a nice "you can now delete your master branch
> because it's been merged" button...

The workflow we recommend should mesh with GitHub's website.
Contributors shouldn't feel like they're fighting the pull request UI or
doing something unorthodox. It sounds like topic/feature branches are
the most natural way to work with pull requests, so that is what we
should recommend.

On a related note, the workflow should reduce openings for error. As
Fred noted, working in a topic branch ensures that updating master
results in a fast-forward merge and shifts conflict resolution to the
point of merging/rebasing the topic branch, which most users might find
less… alarming.

(Advanced Git users will ignore our recommendations and do whatever they
want anyway, which is fine.)

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

Re: [MacPorts] WorkingWithGit modified

[Sterling Smith]

Clemens,

On Sep 23, 2016, at 12:14PM, Clemens Lang  wrote:

> Hi,
> 
> On Fri, Sep 23, 2016 at 11:56:19AM -0700, Sterling Smith wrote:
>> Being a co-maintainer of a software project hosted on GitHub, where
>> the main developer does not use branches leads to inconsistencies in
>> how his contributions are handled vs other developers.
> 
> What would those inconsistencies be?

The main inconsistency in how his contributions are handled is that other 
developers have their code reviewed during the pull request, whereas he is 
pushing directly to the equivalent of MacPorts/master.  You are right that I 
was conflating fork/master with MacPorts/master.  Sorry.

> What is the difference between the master branch in a fork and an
> arbitrarily named branch based off master in a fork? Can't both be
> rebased against upstream/master in exactly the same way?
> 
>> There should also be a decision on the recommended way to get updates
>> from the latest master, whether that is by merging or rebasing.  I
>> personally like rebasing, but there is a stigma associated with it.
>> Note the possibility of a safer forced push after a rebase with
>> --force-with-lease.  (I didn't look to see if there was already a
>> recommendation.)
> 
> See https://trac.macports.org/wiki/WorkingWithGit#updating. The text
> currently recommends a rebase.

Thanks.

> 
> What's the stigma? The need to force push to your fork?

Since MacPorts is already recommending rebasing, apparently there is no stigma.

> -- 
> Clemens

-Sterling

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

Re: [MacPorts] WorkingWithGit modified

[Arno Hautala]

On Fri, Sep 23, 2016 at 4:02 PM, Ryan Schmidt  wrote:
> Building untrusted pull requests is however an entirely different matter

Hah, excellent point. Though now it strikes me what the current
situation is... Hold on, I have to go burn my computers. ;-)

-- 
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: [MacPorts] WorkingWithGit modified

[Rainer Müller]

On 2016-09-23 20:38, Ryan Schmidt wrote:
>> On Sep 23, 2016, at 13:33, Clemens Lang  wrote:
>> 
>> I didn't include this because it's not how I normally work. I
>> usually only create branches for larger changes. I wouldn't be
>> opposed to include it, but I'm probably not the best person to
>> write these docs.
> 
> How can you not work that way?

I usually do the work on my local master. Only when I want to submit a
pull request, I create a new branch starting from upstream/master to
which I cherry-pick or rebase the changes I want to send in the pull
request. I do it this way because I also want to keep all the fixes in
the local copy I use.

Of course that means I need to keep rebasing my local master from
upstream/master.

> If you commit directly to master of your fork, then submit a pull
> request, you can't do anything else on master until your pull request
> is accepted. If you make further changes on master they will be
> included in the pull request, which you wouldn't want if they are
> unrelated changes. And once your pull request is merged, then what?
> GitHub will give you a nice "you can now delete your master branch
> because it's been merged" button...

You could also push from your master to a new remote branch that did not
exist locally:

$ git push origin master:foo-fix

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

Re: [MacPorts] WorkingWithGit modified

[Ryan Schmidt]

> On Sep 23, 2016, at 14:46, Arno Hautala  wrote:
> 
>> On Fri, Sep 23, 2016 at 3:14 PM, Ryan Schmidt  
>> wrote:
>> Seems best to always create a branch before beginning any work, in case you 
>> find out later you have more work you want to submit.
> 
> I use git at work and our workflow is to create a new branch for every
> issue, even if it's as small as a single character typo in a
> documentation file. git clones are really inexpensive so I think the
> advantage really shows itself for smaller changes where you can
> quickly open multiple pull requests.
> 
> We also require that all tests pass before any pull is merged to
> master with the goal that master is never broken. 

Tests are currently broken so we can't enforce such a thing right now. 


> I'm not sure if
> there's any way to integrate the status from the buildbot with Github
> pull requests. Or if there's an easy way to have the buildbot build
> from external branches. It would certainly be nifty if the status of
> each buildbot could be listed next to the pull request for base and
> ports.


I think we should be able to add build status to commits. Building untrusted 
pull requests is however an entirely different matter. We would have to set up 
a new VM for each build. It's conceivable, but nothing of the kind is currently 
set up or in progress. 


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

Re: [MacPorts] WorkingWithGit modified

[Arno Hautala]

On Fri, Sep 23, 2016 at 3:14 PM, Ryan Schmidt  wrote:
> Seems best to always create a branch before beginning any work, in case you 
> find out later you have more work you want to submit.

I use git at work and our workflow is to create a new branch for every
issue, even if it's as small as a single character typo in a
documentation file. git clones are really inexpensive so I think the
advantage really shows itself for smaller changes where you can
quickly open multiple pull requests.

We also require that all tests pass before any pull is merged to
master with the goal that master is never broken. I'm not sure if
there's any way to integrate the status from the buildbot with Github
pull requests. Or if there's an easy way to have the buildbot build
from external branches. It would certainly be nifty if the status of
each buildbot could be listed next to the pull request for base and
ports.


-- 
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: [MacPorts] WorkingWithGit modified

[Clemens Lang]

Hi,

On Fri, Sep 23, 2016 at 02:14:25PM -0500, Ryan Schmidt wrote:
> True but I'd like to default to assuming a user will make a valuable
> contribution and will want to make additional contributions in the
> future. And our track record of accepting patches in Trac in a timely
> fashion is not good. Hopefully it will improve once we go to pull
> requests instead of patches but I don't want our failure to timely
> accept a pull request to prevent a user from submitting a second
> unrelated pull request. 

That's a good point.

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

Re: [MacPorts] WorkingWithGit modified

[Clemens Lang]

Hi,

On Fri, Sep 23, 2016 at 11:56:19AM -0700, Sterling Smith wrote:
> Being a co-maintainer of a software project hosted on GitHub, where
> the main developer does not use branches leads to inconsistencies in
> how his contributions are handled vs other developers.

What would those inconsistencies be?

What is the difference between the master branch in a fork and an
arbitrarily named branch based off master in a fork? Can't both be
rebased against upstream/master in exactly the same way?

> I highly recommend that Clemens move to putting logically separate
> changes in separate topical branches, and avoid developing on master,
> except very tiny changes, e.g. typos in docs.

My point was (as explained in the parallel mail) that I seldom have
multiple logically separate changes at the same time, and just make my
fork's master branch my topic branch for the duration of the pull
request.

> There should also be a decision on the recommended way to get updates
> from the latest master, whether that is by merging or rebasing.  I
> personally like rebasing, but there is a stigma associated with it.
> Note the possibility of a safer forced push after a rebase with
> --force-with-lease.  (I didn't look to see if there was already a
> recommendation.)

See https://trac.macports.org/wiki/WorkingWithGit#updating. The text
currently recommends a rebase.

What's the stigma? The need to force push to your fork?

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

Re: [MacPorts] WorkingWithGit modified

[Ryan Schmidt]

> On Sep 23, 2016, at 14:02, Clemens Lang  wrote:
> 
> Hi,
> 
> On Fri, Sep 23, 2016 at 01:38:43PM -0500, Ryan Schmidt wrote:
>>> On Sep 23, 2016, at 13:33, Clemens Lang  wrote:
>>> 
>>> I didn't include this because it's not how I normally work. I
>>> usually only create branches for larger changes. I wouldn't be
>>> opposed to include it, but I'm probably not the best person to write
>>> these docs.
>> 
>> If you commit directly to master of your fork, then submit a pull
>> request, you can't do anything else on master until your pull request
>> is accepted. If you make further changes on master they will be
>> included in the pull request, which you wouldn't want if they are
>> unrelated changes.
> 
> For most of the pull requests I've sent on GitHub so far I wanted a
> specific feature or bugfix to be integrated and did not want to make
> other changes, so the branch was just not necessary.
> 
> If you still want to make other changes, you can always work locally,
> too. You can see your local repository as yet another branch.
> 

But I can't submit a pull request for that. 

What has happened to me before is I fork, commit changes to master, pull 
request, upstream does not accept the pull request right away, then I realize I 
have another unrelated change I want to submit. Seems best to always create a 
branch before beginning any work, in case you find out later you have more work 
you want to submit. 


>> And once your pull request is merged, then what? GitHub will give you
>> a nice "you can now delete your master branch because it's been
>> merged" button...
> 
> I usually deleted the entire repository after the PR was merged.

Yes I want to do that too when I'm totally done. GitHub doesn't make this as 
easy though. 



> Maybe this approach will change for MacPorts, but most of our users
> probably don't update 12 different ports in 6 different PRs at the same
> time.

True but I'd like to default to assuming a user will make a valuable 
contribution and will want to make additional contributions in the future. And 
our track record of accepting patches in Trac in a timely fashion is not good. 
Hopefully it will improve once we go to pull requests instead of patches but I 
don't want our failure to timely accept a pull request to prevent a user from 
submitting a second unrelated pull request. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] WorkingWithGit modified

[Clemens Lang]

Hi,

On Fri, Sep 23, 2016 at 01:38:43PM -0500, Ryan Schmidt wrote:
> > On Sep 23, 2016, at 13:33, Clemens Lang  wrote:
> > 
> > I didn't include this because it's not how I normally work. I
> > usually only create branches for larger changes. I wouldn't be
> > opposed to include it, but I'm probably not the best person to write
> > these docs.
> 
> If you commit directly to master of your fork, then submit a pull
> request, you can't do anything else on master until your pull request
> is accepted. If you make further changes on master they will be
> included in the pull request, which you wouldn't want if they are
> unrelated changes.

For most of the pull requests I've sent on GitHub so far I wanted a
specific feature or bugfix to be integrated and did not want to make
other changes, so the branch was just not necessary.

If you still want to make other changes, you can always work locally,
too. You can see your local repository as yet another branch.

> And once your pull request is merged, then what? GitHub will give you
> a nice "you can now delete your master branch because it's been
> merged" button...

I usually deleted the entire repository after the PR was merged.

Maybe this approach will change for MacPorts, but most of our users
probably don't update 12 different ports in 6 different PRs at the same
time.

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

Re: [MacPorts] WorkingWithGit modified

[Sterling Smith]

Whether to delete the branch depends largely on how the branch was merged into 
master.  If it was merged as a regular merge (with a merge commit), then there 
is no reason to delete the branch, as a new pull request on the same branch 
(after adding some new commits) will only show any new commits since that 
merge.  On the other hand, if MacPorts decides it likes to squash and merge 
pull requests, then the branch should be deleted both on GitHub and locally, 
otherwise further development on that branch will show both the unsquashed 
commits and the further development in the pull request (although the 
differences shouldn't show up in the files/diff section of the pull request).

Being a co-maintainer of a software project hosted on GitHub, where the main 
developer does not use branches leads to inconsistencies in how his 
contributions are handled vs other developers.  I highly recommend that Clemens 
move to putting logically separate changes in separate topical branches, and 
avoid developing on master, except very tiny changes, e.g. typos in docs.

There should also be a decision on the recommended way to get updates from the 
latest master, whether that is by merging or rebasing.  I personally like 
rebasing, but there is a stigma associated with it.  Note the possibility of a 
safer forced push after a rebase with --force-with-lease.  (I didn't look to 
see if there was already a recommendation.)

-Sterling


On Sep 23, 2016, at 11:38AM, Ryan Schmidt  wrote:

> 
> 
>> On Sep 23, 2016, at 13:33, Clemens Lang  wrote:
>> 
>> I didn't include this because it's not how I normally work. I usually
>> only create branches for larger changes. I wouldn't be opposed to
>> include it, but I'm probably not the best person to write these docs.
> 
> How can you not work that way?
> 
> If you commit directly to master of your fork, then submit a pull request, 
> you can't do anything else on master until your pull request is accepted. If 
> you make further changes on master they will be included in the pull request, 
> which you wouldn't want if they are unrelated changes. And once your pull 
> request is merged, then what? GitHub will give you a nice "you can now delete 
> your master branch because it's been merged" button...
> 
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: [MacPorts] WorkingWithGit modified

[Ryan Schmidt]

> On Sep 23, 2016, at 13:33, Clemens Lang  wrote:
> 
> I didn't include this because it's not how I normally work. I usually
> only create branches for larger changes. I wouldn't be opposed to
> include it, but I'm probably not the best person to write these docs.

How can you not work that way?

If you commit directly to master of your fork, then submit a pull request, you 
can't do anything else on master until your pull request is accepted. If you 
make further changes on master they will be included in the pull request, which 
you wouldn't want if they are unrelated changes. And once your pull request is 
merged, then what? GitHub will give you a nice "you can now delete your master 
branch because it's been merged" button...


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

Re: [MacPorts] WorkingWithGit modified

[Clemens Lang]

On Fri, Sep 23, 2016 at 01:08:38PM -0500, Ryan Schmidt wrote:
> Something I did not see discussed on this page was that after you
> fork, and before you start making changes, you should create a branch
> specific to the work you are doing.

I didn't include this because it's not how I normally work. I usually
only create branches for larger changes. I wouldn't be opposed to
include it, but I'm probably not the best person to write these docs.

In general, I think our "how to pull request" docs aren't very fleshed
out yet; this is intentional, because we don't yet know how we will deal
with pull requests and whether we want to request a specific workflow.

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

Re: [MacPorts] WorkingWithGit modified

[Ryan Schmidt]

Thanks everyone for your work in creating this documentation. 

Something I did not see discussed on this page was that after you fork, and 
before you start making changes, you should create a branch specific to the 
work you are doing. For example if you are updating port foo to a new version, 
make a branch called "update-foo". If you later want to do other unrelated 
work, you create a new branch from master for that. The github pull request 
interface makes it easy to delete your branch after it's been merged, which 
only works if you made a branch to begin with. 


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

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

[René J . V . Bertin]

On Friday September 16 2016 16:06:54 Rainer Müller wrote:

>Moving the discussion to macports-dev as this is about the
>implementation, nothing users should care about.

You're not entirely right: users can and should care about ease of updating. I 
posted to macports-users on purpose, to get the largest possible awareness.

>That would be solved with dependency resolution using a SAT solver and
>version information in dependency specifications. We already started to
>work on that in last GSoC.

I'm not entirely sure if versioned dependencies are a solution to this 
particular problem. They shouldn't even become necessary when old runtime 
libraries can be left around; any port using them that gets updated will use 
the latest version. I don't see how you could end up in a situation where a 
non-rebuilt/reinstalled port that worked with a previous version will stop to 
work if you upgrade that dependency while keeping the required old runtime 
libraries around. A bump in the required dependency version will by definition 
be a result of an upgrade of the dependent.

>Putting the files into the destroot for the new archive is the wrong
>solution to this problem.

But the only workable workaround at the moment, as far as I can tell.
Even if it'll remain acceptable only in custom ports trees I'd still appreciate 
suggestions to improve it.

>Libraries that would not be replaced, but still have linking information
>need to be preserved on disk and in the registry indicating which port
>they belonged to. After all other ports linking to the files are
>upgraded, they can be safely removed.

Are you thinking of an automatic feature here? You're right that this should be 
feasible but that'd be so elegant even I didn't dare dreaming of it :)

>version) changes. This does not happen that often and as long as the
>major part of ports comes from our ports tree, the current solution of

It happens often enough with far-reaching enough consequences, in my perception!

>and cannot introduce the rev-bump at the same time. However, the
>automatic scanning in rev-upgrade will detect the problem and either
>upgrade the broken port with a new binary archive or eventually rebuild
>the port locally, ensuring the user has a working installation of all ports.

And hopefully for him/her, one that doesn't have any ports that require manual 
rebuilding, have pending changes, or any other whatever-it-is that means it 
shouldn't be upgraded completely automatically.

>needs to be done in base. As you said, that will require changes to the
>registry format. As we currently handle upgrade as a completely
>transparent deactivate old/activate new cycle, that would also require
>significant changes to the internal phases.

I know next to nothing about db internals, so I have no idea if one can store 
new data fields in a database and still keep it forwards compatible (i.e. old 
db file readable by the new code). I'd hope this is or can be more or less 
transparent, but if not, couldn't that new data be stored in an additional file?
And wouldn't that reduce the overhead of operating on a single huge db file, at 
least in theory?

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

Re: [MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

[Rainer Müller]

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

Moving the discussion to macports-dev as this is about the
implementation, nothing users should care about.

On 2016-09-16 10:06, René J.V. Bertin wrote:
> My proposal aims to introduce (and provide a proof of concept) of an
> optional other solution, which could be used by select ports and give
> users with specific needs an easier way to adjust the update
> behaviour and cycle to their requirements. Easier than backing out of
> an upgrade cycle that turns out to have unwelcome consequences, copy
> the retrieved outdated culprit ports to a personal ports tree and
> start over again.
> 
> It'd be more elegant if implemented in "base", with more control over
> which libraries get preserved from an existing install, but I think
> it's obvious a non-default variant should be used to activate the
> feature.
> 
> It'd be even more elegant if the implementation actually reactivated
> select files from an older software image, meaning they'd remain
> members of that installed version only and be removed from the system
> when the user uninstalls that or those older versions. I'd love to
> try my hand at that but it's clearly going to involve substantial
> changes to "base", possibly even a change to the registry database,
> and I'm not comfortable with that. Maybe the additional metadata
> could be stored in an additional *sql file?
> 
> If that additional metadata includes a list of which ports depend on
> what "outdated" libraries it should even become trivial to present a
> list of recommended updates, i.e. the ports that ought to be rebuilt
> in order to use the latest dependencies available. That's the same
> list of ports that would break when uninstalling a particular version
> of a particular dependency.

That would be solved with dependency resolution using a SAT solver and
version information in dependency specifications. We already started to
work on that in last GSoC.

> I know that users can already decide not to upgrade select ports (and
> back out of an unwelcome upgrade by reactivating old versions), but
> then you quickly end up with an increasing list of outdated ports
> (making it hard to see and figure out which can and should be
> upgraded) and at some point you almost stop upgrading (and
> selfupdating) at all.

Overall, handling these kinds of upgrades could be improved. You are
correct that the proposed way would be what other package managers do,
for example Gentoo's portage:

https://wiki.gentoo.org/wiki/Preserve-libs

Putting the files into the destroot for the new archive is the wrong
solution to this problem.

Libraries that would not be replaced, but still have linking information
need to be preserved on disk and in the registry indicating which port
they belonged to. After all other ports linking to the files are
upgraded, they can be safely removed.

This problem will only appear when the SONAME (or dylib compatibility
version) changes. This does not happen that often and as long as the
major part of ports comes from our ports tree, the current solution of
rev-bumping works. The problem exists mainly for custom ports trees with
ports linking with the main ports tree. We have no control over these
and cannot introduce the rev-bump at the same time. However, the
automatic scanning in rev-upgrade will detect the problem and either
upgrade the broken port with a new binary archive or eventually rebuild
the port locally, ensuring the user has a working installation of all ports.

There is really no way to add such a functionality in a port group, it
needs to be done in base. As you said, that will require changes to the
registry format. As we currently handle upgrade as a completely
transparent deactivate old/activate new cycle, that would also require
significant changes to the internal phases.

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

Re: [MacPorts] #51448: New Portfile for pyFAI

[coquelleni]

 

clang was blacklisted because at the time the first version of a port
file was generated (a while before the port was actually submitted),
there was no open mp support for clang.
It looks like everything builds smoothly now.

Best,
Nico.

Le 2016-09-11 18:48, MacPorts a écrit : 

> #51448: New Portfile for pyFAI
> ---+
> Reporter: coquelleni@… | Owner: macports-tickets@…
> Type: submission | Status: new
> Priority: Normal | Milestone:
> Component: ports | Version:
> Resolution: | Keywords:
> Port: py-pyFAI |
> ---+
> Changes (by raimue@…):
> 
> * cc: raimue@… (added)
> 
> Comment:
> 
> Here is an updated Portfile with some changes:
> 
> * Formatted in common style
> * Use GitHub port group
> * Update to 0.12.0
> * license is actually GPL-3+
> 
> Why was clang blacklisted in the original submission? The port builds fine
> for me with the default Xcode 7.2.1 on OS X 10.10 Yosemite.

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

Re: [MacPorts] #45251: request for lldb

[René J . V . Bertin]

On Friday September 09 2016 17:07:48 MacPorts wrote:

>  I'm ok with splitting up the port and would be happy do to so if we can
>  avoid build time regressions and setup sane dependencies.  

Building a redistributable, standalone libclang is a bit of a separate issue, 
no?
That said, it's also supposed to speed up compile times when using clang, as 
there are less shared libraries to load at each invocation.

>  I don't like
>  the current situation in which clang rebuilds libLLVM.dylib at build time
>  instead of using llvm-config to find the installed one to build and link
>  against.

No, I agree (all the more since build times for 3.9 appear to be almost 50% 
longer than the ones for 3.8).

That said, I tried my trick of calling make in the tools/clang. For once it 
doesn't work, probably because there are apparently 3 parallel directories that 
have to be built in the right order.

You probably saw my thread about standalone building of lldb. In short: it 
almost works. Of course I can only tell if it has any benefits over my current 
approach once I've gotten it to work ;)

>  If that is needed, it should be addressed as a patch to the build system
>  that can be integrated upstream.  Using install_name_tool can introduce a
>  dependency on cctools, which is a pain point as it can cause a dependncy

Can you explain? Why would that the be case as long as we don't tell the port 
to use the copy from cctools?

>  Let's track that in a separate bug (I filed #52196).  I'm of the opinion
>  that `llvm-config --ldflags` should "do the right thing" but it doesn't
>  setup rpath.

I've thought about this a bit more, and it may be a moot point. The official 
Linux builds I have on my Ubuntu rig also install libclang, libLLVM etc. 
somewhere that's not part of the standard ldconfig search path. IOW, 
cross-platform code already has to add the path to those libraries to its 
rpath, which should solve the issue on OS X too. No?

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

Re: [MacPorts] #52170: zebra: updated to version 2.0.62

[David Coate]

yes

> On Sep 3, 2016, at 11:44 PM, MacPorts  wrote:
> 
> #52170: zebra: updated to version 2.0.62
> --+---
> Reporter:  devans@…  |  Owner:  dlc@…
>Type:  update| Status:  new
> Priority:  Normal|  Milestone:
> Component:  ports |Version:  2.3.4
> Keywords:|   Port:  zebra
> --+---
> Patch attached.  Ok to commit?
> 
> -- 
> Ticket URL: 
> MacPorts 
> Ports system for macOS

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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Craig Treleaven]

> On Sep 5, 2016, at 4:09 PM, Bradley Giesbrecht  wrote:
> 
>> On Sep 5, 2016, at 8:03 AM, Lawrence Velázquez  wrote:
>> 
>>> On Sep 5, 2016, at 8:42 AM, Craig Treleaven  wrote:
>>> 
>>> Not to belabour the issue, but should it not be the impact to port users 
>>> that determines whether a change is “minor” or not?
>> 
>> I believe the "minorness" of the change is wholly up to the maintainer.
>> 
>>> The number of lines, by itself, doesn’t necessarily determine that impact. 
>>> For example, a 1 or 2 line change in one of the database ports might make a 
>>> new database engine the default.
>> 
>> It is certainly true that a small change with great impact is not minor, but 
>> a large change with little impact is also not minor. As an extreme example, 
>> I would not appreciate a commit to one of my ports that had no impact on the 
>> installation yet completely rearranged the portfile. I'd have to waste time 
>> reading and understanding the committer's code, looking for edge cases and 
>> failure modes, reworking local commits that no longer apply, etc.
>> 
>> (This situation can already happen via timeout, but in that case there is a 
>> clear, objective policy that maintainers implicitly agree to when they take 
>> up maintainership.)
>> 
>> My rule of thumb is that fixing typos and broken builds is almost always 
>> okay under openmaintainer. Many maintainers also permit minor version bumps 
>> and bug fixes, but some don't. In all cases, it's safest to wait out the 72 
>> hours.
> 
> I was going to add to the ticket but maybe this is a better place to discuss 
> for now.
> 
> I have attempted to keep the mysql ports similar to make maintaining them 
> easier.
> 
> I have a few questions regarding these changes.
> 
> 1. Will "port load mariadb-server" work?

Good point, I don’t know.  I’ll try it.

BTW, this afternoon I noticed that I’m not respecting the “startupitem.install” 
setting.  I’ll change the patch so if the user has modified macports.conf with 
‘startupitem.install no’, we don’t put anything in /Library/LaunchDaemons.

> 2. Has this been tested on older systems?

Not yet.  It has been a lot of time and work to get this far.  What is the 
earliest OS that you test with the server ports?  The new version of my MythTV 
ports are not going to support anything before 10.9!  The best I can do is 10.6 
on X86_64.

> 3. Can the pkg run concurrently with the port? I assume pkg installs into 
> $prefix, am I right?

Correct, the pkg installs in the same prefix it was built in.  For development, 
I build mpkgs on my main system (10.10) and test installation on a VM (10.11).  
(Later, I’ll build the mpkg for distribution on a VM with a non-default 
prefix.)  

> 4. Is there any reason the same changes would not work for the mysql*-server, 
> mariadb*-server and persona-server ports?

I know almost nothing about percona but I think it ought to work with the 
different versions of mysql and mariadb.  The launchd plist was introduced in 
MySQL 5.7.8.

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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Bradley Giesbrecht]

> On Sep 5, 2016, at 8:03 AM, Lawrence Velázquez  wrote:
> 
>> On Sep 5, 2016, at 8:42 AM, Craig Treleaven  wrote:
>> 
>> Not to belabour the issue, but should it not be the impact to port users 
>> that determines whether a change is “minor” or not?
> 
> I believe the "minorness" of the change is wholly up to the maintainer.
> 
>> The number of lines, by itself, doesn’t necessarily determine that impact. 
>> For example, a 1 or 2 line change in one of the database ports might make a 
>> new database engine the default.
> 
> It is certainly true that a small change with great impact is not minor, but 
> a large change with little impact is also not minor. As an extreme example, I 
> would not appreciate a commit to one of my ports that had no impact on the 
> installation yet completely rearranged the portfile. I'd have to waste time 
> reading and understanding the committer's code, looking for edge cases and 
> failure modes, reworking local commits that no longer apply, etc.
> 
> (This situation can already happen via timeout, but in that case there is a 
> clear, objective policy that maintainers implicitly agree to when they take 
> up maintainership.)
> 
> My rule of thumb is that fixing typos and broken builds is almost always okay 
> under openmaintainer. Many maintainers also permit minor version bumps and 
> bug fixes, but some don't. In all cases, it's safest to wait out the 72 hours.

I was going to add to the ticket but maybe this is a better place to discuss 
for now.

I have attempted to keep the mysql ports similar to make maintaining them 
easier.

I have a few questions regarding these changes.

1. Will "port load mariadb-server" work?
2. Has this been tested on older systems?
3. Can the pkg run concurrently with the port? I assume pkg installs into 
$prefix, am I right?
4. Is there any reason the same changes would not work for the mysql*-server, 
mariadb*-server and persona-server ports?

Regards,
Bradley Giesbrecht (pixilla)




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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Lawrence Velázquez]

> On Sep 5, 2016, at 8:42 AM, Craig Treleaven  wrote:
> 
> Not to belabour the issue, but should it not be the impact to port users that 
> determines whether a change is “minor” or not?

I believe the "minorness" of the change is wholly up to the maintainer.

> The number of lines, by itself, doesn’t necessarily determine that impact. 
> For example, a 1 or 2 line change in one of the database ports might make a 
> new database engine the default.

It is certainly true that a small change with great impact is not minor, but a 
large change with little impact is also not minor. As an extreme example, I 
would not appreciate a commit to one of my ports that had no impact on the 
installation yet completely rearranged the portfile. I'd have to waste time 
reading and understanding the committer's code, looking for edge cases and 
failure modes, reworking local commits that no longer apply, etc.

(This situation can already happen via timeout, but in that case there is a 
clear, objective policy that maintainers implicitly agree to when they take up 
maintainership.)

My rule of thumb is that fixing typos and broken builds is almost always okay 
under openmaintainer. Many maintainers also permit minor version bumps and bug 
fixes, but some don't. In all cases, it's safest to wait out the 72 hours.

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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Craig Treleaven]

> On Sep 4, 2016, at 8:54 PM, Lawrence Velázquez  wrote:
> 
>> On Sep 4, 2016, at 8:32 PM, MacPorts  wrote:
>> 
>> #52144: mariadb: support for mpkg / mdmg
>> -+---
>> Reporter:  ctreleaven@…|  Owner:  pixilla@…
>> Type:  enhancement | Status:  new
>> Priority:  Normal  |  Milestone:
>> Component:  ports   |Version:
>> Resolution:  |   Keywords:
>> Port:  mariadb-server  |
>> -+---
>> 
>> Comment (by ctreleaven@…):
>> 
>> [snip]
>> 
>> Barring objections, I plan commit these changes under openmaintainer in
>> the next few days.  I feel the startupitem to launchd plist changes are
>> relatively low risk.  I'll try to handle anything that might crop up.
> 
> This is the MacPorts Guide’s description[*] of the openmaintainer policy:
> 
>   If a port's maintainer contains the address
>   , this means that the author
>   allows minor updates to the port without contacting him first.
>   But permission should still be sought for major changes.
> 
> While limited in scope, your changes are anything but minor (the patch
> is 181 lines!), and committing them would clearly violate the spirit of
> the openmaintainer guideline.
> 
> You’d be better off invoking the 72-hour maintainer timeout policy.
> 
> [*] 
> https://guide.macports.org/chunked/project.update-policies.html#project.update-policies.nonmaintainer
> 
You’re right, I should have referenced maintainer timeout.  I tried to contact 
Bradley a week ago today with no response.

Not to belabour the issue, but should it not be the impact to port users that 
determines whether a change is “minor” or not?  The number of lines, by itself, 
doesn’t necessarily determine that impact.   For example, a 1 or 2 line change 
in one of the database ports might make a new database engine the default.  
That would be much more signficant that what I’ve proposed.  At the heart of 
it, the proposed changes are:

1) Use an upstream launchd plist.

2) Enable packaging where it has never worked before.

Nonetheless, whether this is “maintainer timeout” or “openmaintainer”, I don’t 
want to create problems with the port.  I welcome any and all feedback.

Craig

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

Re: [MacPorts] #52144: mariadb: support for mpkg / mdmg

[Lawrence Velázquez]

> On Sep 4, 2016, at 8:32 PM, MacPorts  wrote:
> 
> #52144: mariadb: support for mpkg / mdmg
> -+---
>  Reporter:  ctreleaven@…|  Owner:  pixilla@…
>  Type:  enhancement | Status:  new
>  Priority:  Normal  |  Milestone:
> Component:  ports   |Version:
> Resolution:  |   Keywords:
>  Port:  mariadb-server  |
> -+---
> 
> Comment (by ctreleaven@…):
> 
> [snip]
> 
> Barring objections, I plan commit these changes under openmaintainer in
> the next few days.  I feel the startupitem to launchd plist changes are
> relatively low risk.  I'll try to handle anything that might crop up.

This is the MacPorts Guide’s description[*] of the openmaintainer policy:

If a port's maintainer contains the address
, this means that the author
allows minor updates to the port without contacting him first.
But permission should still be sought for major changes.

While limited in scope, your changes are anything but minor (the patch
is 181 lines!), and committing them would clearly violate the spirit of
the openmaintainer guideline.

You’d be better off invoking the 72-hour maintainer timeout policy.

[*] 
https://guide.macports.org/chunked/project.update-policies.html#project.update-policies.nonmaintainer

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Rainer Müller]

On 2016-08-24 21:40, Mihai Moldovan wrote:
> On 24.08.2016 09:36 PM, Lawrence Velázquez wrote:
>> But those Perl ports are always leaves (w.r.t. `cpuid`) because they are 
>> build dependencies. There's no need to revbump if you're just updating build 
>> dependencies.
> 
> Aren't build dependencies included in the DB? I typically run port_cutleaves 
> -b
> to get rid of leaves minus build dependencies, as these will be needed at some
> point in time again anyway (given I build everything from source.)

port_cutleaves actually takes all of the dependency information from the
PortIndex in the ports tree.

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Lawrence Velázquez]

> On Aug 24, 2016, at 3:40 PM, Mihai Moldovan  wrote:
> 
>> On 24.08.2016 09:36 PM, Lawrence Velázquez wrote:
>> 
>> But those Perl ports are always leaves (w.r.t. `cpuid`) because they are 
>> build dependencies. There's no need to revbump if you're just updating build 
>> dependencies.
> 
> Aren't build dependencies included in the DB?

They are not, at least with trunk.

% port deps clang-3.8
Full Name: clang-3.8 @3.8.1_3+analyzer
Extract Dependencies: subversion, xz
Build Dependencies:   cmake, cctools
Library Dependencies: libxml2, libomp, llvm-3.8, python27, libedit, libffi,
  ncurses, zlib, libcxx
Runtime Dependencies: clang_select, ld64, perl5
%
% (cd ~[mp:base]/src/cregistry && sqlite3 
/opt/local/var/macports/registry/registry.db <<'EOF'
> .load macports.sqlext
> SELECT dependencies.name FROM ports, dependencies WHERE ports.name = 
> 'clang-3.8' AND ports.id = dependencies.id ORDER BY dependencies.name ASC;
> EOF
)
clang_select
ld64
libcxx
libedit
libffi
libomp
libxml2
llvm-3.8
ncurses
perl5
python27
zlib
%

> I typically run port_cutleaves -b to get rid of leaves minus build 
> dependencies, as these will be needed at some point in time again anyway 
> (given I build everything from source.)

I just mark such ports as requested and use "port uninstall 
--follow-dependencies leaves".

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[René J . V . Bertin]

On Wednesday August 24 2016 15:40:27 Lawrence Velázquez wrote:

> > But those Perl ports are always leaves (w.r.t. `cpuid`) because they are 
> > build dependencies. There's no need to revbump if you're just updating 
> > build dependencies.
> 
> To be more specific, there's no need to revbump if the change in build 
> dependencies does not alter the build product.

And in this case there isn't even a need for the dependencies anymore; the new 
version builds fine after I deactivated the ports. Which, btw, didn't raise any 
errors about how `port:cpuid` depended on them. So no, apparently build 
dependencies are not recorded in the DB the same way runtime dependencies are.

>From what I've been able to determine the package needs just *a* perl 
>interpreter >5.8 to execute a build script. The system perl does perfectly 
>fine for that purpose.

R


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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Mihai Moldovan]

On 24.08.2016 09:36 PM, Lawrence Velázquez wrote:
> But those Perl ports are always leaves (w.r.t. `cpuid`) because they are 
> build dependencies. There's no need to revbump if you're just updating build 
> dependencies.

Aren't build dependencies included in the DB? I typically run port_cutleaves -b
to get rid of leaves minus build dependencies, as these will be needed at some
point in time again anyway (given I build everything from source.)

The only way to update this would be a revbump, but if I'm mistaken indeed no
additional work is necessary.



Mihai





signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Lawrence Velázquez]

> On Aug 24, 2016, at 3:36 PM, Lawrence Velázquez  wrote:
> 
>> On Aug 24, 2016, at 3:05 PM, Mihai Moldovan  wrote:
>> 
>>> On 24.08.2016 09:02 PM, René J.V. Bertin wrote:
>>> 
>>> Also, cpuid only has a build dependency on 2 perl packages, so there's no 
>>> need to reinstall the port when perl changes.
>> 
>> You can use the revbump to change the dependency to the new perl version, 
>> mainly
>> to make that perl package a leaf. It's not strictly required, but my personal
>> opinion is to do that to enable users to get rid of packages they don't need
>> anymore (and at least I don't like to remove build dependencies, as they 
>> will be
>> pulled in again later anyway.)
> 
> But those Perl ports are always leaves (w.r.t. `cpuid`) because they are 
> build dependencies. There's no need to revbump if you're just updating build 
> dependencies.

To be more specific, there's no need to revbump if the change in build 
dependencies does not alter the build product.

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[René J . V . Bertin]

On Wednesday August 24 2016 21:05:29 Mihai Moldovan wrote:

>Uhm but that won't lead to rebuilds...

But there's no need to rebuild here, just as there wouldn't be a reason to 
rebuild if the perl packages were a runtime dependency.

>to make that perl package a leaf. It's not strictly required, but my personal
>opinion is to do that to enable users to get rid of packages they don't need
>anymore (and at least I don't like to remove build dependencies, as they will 
>be
>pulled in again later anyway.)

Are build dependencies counted in the number of dependents of a port, and if 
so, why. And if so, is that also the case when a port is installed from a 
binary package - and if *that* is not the case, how is that difference 
justified?

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Lawrence Velázquez]

> On Aug 24, 2016, at 3:05 PM, Mihai Moldovan  wrote:
> 
>> On 24.08.2016 09:02 PM, René J.V. Bertin wrote:
>> 
>> Also, cpuid only has a build dependency on 2 perl packages, so there's no 
>> need to reinstall the port when perl changes.
> 
> You can use the revbump to change the dependency to the new perl version, 
> mainly
> to make that perl package a leaf. It's not strictly required, but my personal
> opinion is to do that to enable users to get rid of packages they don't need
> anymore (and at least I don't like to remove build dependencies, as they will 
> be
> pulled in again later anyway.)

But those Perl ports are always leaves (w.r.t. `cpuid`) because they are build 
dependencies. There's no need to revbump if you're just updating build 
dependencies.

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Mihai Moldovan]

On 24.08.2016 09:02 PM, René J.V. Bertin wrote:
> On Wednesday August 24 2016 20:43:08 Mihai Moldovan wrote:
> 
>> It will need a revbump once that's done, but otherwise yes.
> 
> That shouldn't actually be necessary; "base" ought to track which PortGroup 
> files a port depends on, so that portindex can parse them if any of those 
> dependencies change.

Uhm but that won't lead to rebuilds...


> Also, cpuid only has a build dependency on 2 perl packages, so there's no 
> need to reinstall the port when perl changes.

You can use the revbump to change the dependency to the new perl version, mainly
to make that perl package a leaf. It's not strictly required, but my personal
opinion is to do that to enable users to get rid of packages they don't need
anymore (and at least I don't like to remove build dependencies, as they will be
pulled in again later anyway.)



Mihai



signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[René J . V . Bertin]

On Wednesday August 24 2016 20:43:08 Mihai Moldovan wrote:

>It will need a revbump once that's done, but otherwise yes.

That shouldn't actually be necessary; "base" ought to track which PortGroup 
files a port depends on, so that portindex can parse them if any of those 
dependencies change.

Also, cpuid only has a build dependency on 2 perl packages, so there's no need 
to reinstall the port when perl changes.

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

Re: [MacPorts] #52081: Ports should require perl5.24 instead of 5.22

[Mihai Moldovan]

On 24.08.2016 08:28 PM, MacPorts wrote:
> #52081: Ports should require perl5.24 instead of 5.22
> Comment (by rjvbertin@…):
> 
>  Not that I can commit it anyway, but I had a look at my `port:cpuid`.
>  Turns out it depends on `port:p${perl5.major}-foo` ; am I right that this
>  means it'll transition as soon as the `perl5.major` variable changes?

It will need a revbump once that's done, but otherwise yes.



Mihai




signature.asc
Description: OpenPGP digital signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

[Ryan Schmidt]

> On Aug 22, 2016, at 9:20 AM, Rainer Müller  wrote:
> 
> On 2016-08-22 12:39, Niels Dettenbach wrote:
>> Hmmm,
>> i'm just wondering how the port worked up to 1.2 - there was no significant 
>> changes within darkice sources done as far as i know from Rafael Diniz 
>> (darkice maintainer) and i see no differences in the configure flag sheme 
>> too.
> 
> If you had the pkgconfig port installed, it just worked because it was
> already available. That is very likely as pkgconfig is a build
> dependency for many other ports.
> 
>> Do i have to correct here something further? In that case i have to dig in 
>> deeper asap (i.e. next weekend) into macports again.
>> 
>> depends_build-append port:pkgconfig
> 
> That would be correct.
> 
>> Could i add this in general anywhere or should place this under any of the 
>> variant sections? In practice, any mac osx user would at least need jack - 
>> and 
>> i don't know if further of the encoders need pkg-config too.
> 
> According to the configure script, the detection for all of them uses
> pkg-config.

Except lame.

> Makes sense to add it as a general dependency.

Agreed.



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

Re: [MacPorts] WorkingWithGit modified

[MacPorts]

Hi Clemens,

On 21.08.2016 17:28, Clemens Lang wrote:

Thanks for the section on setting up commiter name and email address, I
had forgot about this.


you are welcome. I saw the page and that was the first thing hitting my 
eye,

which is why I started to give that wiki page some polish. :-)


+Additionally one should define a few (not necessarily global) presets 
for working with your clone of the MacPorts repository:

+{{{
+$ git config --global push.default nothing
+$ git config --global branch.autosetuprebase always
+$ git config --global core.excludesfile ~/.gitignore_global
+$ git config --global commit.template ~/.git-commit-template
+}}}


Well, I chose to suggest these, as they were recommended by the KDE 
community.




I do not think we should recommend setting these variables for the
following reasons:


Let's see...



 - Users don't understand they're doing here. I want our developers
   to know what and why things are happening with Git, not serve them a
   "here's how you ought to do it" recipe.


So, than we need to explain what these settings do. I am strongly 
opposing the
concept of giving just orders to our port maintainers without educating 
them about
why things were set up the way they are. These settings make sense 
because they
prevent bad things which can happen easily with git. I always favour(ed) 
Mercurial
over it, but it was decided against... so we need to make sure that the 
basic settings

are chosen such that they prevent evil.


 - This is also the reason why the "Fetching the latest changes" 
section

   I wrote yesterday is so long: Developers should understand what
   happens when they run these commands, not just be told "run this". I
   think we should move branch.autosetuprebase to the end of the
   "Fetching the latest changes" section where we tell them that 
instead

   of the --rebase flag, they can also set this option. Also, setting
   this option globally is bad; other projects might not want this
   behavior.


As I wrote above that section I am aware of that those settings might 
not be
wanted as global ones, but I actually have them set as global in most of 
my

setups, to tell you the truth.


 - push.default nothing may be a good idea, but I would only put it as 
a

   recommendation in a section on committing and pushing changes for
   people that want to make sure they're not accidentially pushing
   something they don't want to push.


I think it is a good thing, as it always forces the maintainers to think 
about
which branch they really want to target. That's an extra level of 
precaution.




 - I do not think we need .gitignore_global; We already converted our
   svn:excludes into .gitignores in the repositories and we've always
   left the configuration of svn clients to our developers. If they
   think this is necessary, they can figure it out on their own.


OK, fine with me.


 - I also do not think we should recommend a git commit template for 
the

   same reason. Developers with Subversion have always been free to
   configure their own client and while a commit template is possible
   with Subversion, we did not recommend it there either.


Well, a commit template I definitely favour, because quite some times 
you
do find commits to the MacPorts repo which do not adhere to the 
standards
defined on our Wiki or in the Guide. A template would guide the 
committers
to not to forget some rules of the game. But, if you don't want to annoy 
our

committers with too many rules then so be it. :)

Greets,
Marko

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

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

[Rainer Müller]

On 2016-08-22 12:39, Niels Dettenbach wrote:
> Hmmm,
> i'm just wondering how the port worked up to 1.2 - there was no significant 
> changes within darkice sources done as far as i know from Rafael Diniz 
> (darkice maintainer) and i see no differences in the configure flag sheme too.

If you had the pkgconfig port installed, it just worked because it was
already available. That is very likely as pkgconfig is a build
dependency for many other ports.

> Do i have to correct here something further? In that case i have to dig in 
> deeper asap (i.e. next weekend) into macports again.
> 
> depends_build-append port:pkgconfig

That would be correct.

> Could i add this in general anywhere or should place this under any of the 
> variant sections? In practice, any mac osx user would at least need jack - 
> and 
> i don't know if further of the encoders need pkg-config too.

According to the configure script, the detection for all of them uses
pkg-config. Makes sense to add it as a general dependency.

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

Re: [MacPorts] #52068: darkice needs pkgconfig dependency

[Niels Dettenbach]

Am Samstag, 20. August 2016, 12:13:32 schrieb MacPorts:
>  Alternatively, you may set the environment variables JACK_CFLAGS
>  and JACK_LIBS to avoid the need to call pkg-config.
>  See the pkg-config man page for more details.
> 
>  To get pkg-config, see .
>  See `config.log' for more details
>  }}}
> 
>  Evidently, darkice needs pkgconfig to find jack, so a build dependency on
>  port:pkgconfig should be added to the port somewhere. But where?
> 
>  If only the jack variant needs pkgconfig, then put the dependency in the
>  jack variant.
> 
>  It looks lame was detected without pkgconfig. What about the other
>  variants, which are not default variants? If some of them require
>  pkgconfig, then the pkgconfig dependency should be made in a conditional
>  outside of a variant directive (to avoid each variant declaring the same
>  dependency). For example, if only jack and faac need pkgconfig, you could
>  do:
> 
>  {{{
>  if {[variant_isset faac] || [variant_isset jack]} {
>  depends_build-append port:pkgconfig
>  }
>  }}}

Hmmm,
i'm just wondering how the port worked up to 1.2 - there was no significant 
changes within darkice sources done as far as i know from Rafael Diniz 
(darkice maintainer) and i see no differences in the configure flag sheme too.

Do i have to correct here something further? In that case i have to dig in 
deeper asap (i.e. next weekend) into macports again.

depends_build-append port:pkgconfig

Could i add this in general anywhere or should place this under any of the 
variant sections? In practice, any mac osx user would at least need jack - and 
i don't know if further of the encoders need pkg-config too.

Just to explain a bit:

 - darkice needs one audio i/o framework to work (currently the only available 
under MacOS seems jack - coreaudio is not provided yet)

 - beside this, darklice need at least (!) one of the encoder framworks - but 
could be compiled with any other combination (or even all enc libraries)  as 
well. There is no further dependency between them.

The most "typical" (entry) setup of darkice is jack + lame (mp3) - as defined 
in the default_variants


many thanks.
best regards,


Niels.


-- 
 ---
 Niels Dettenbach
 Syndicat IT & Internet
 http://www.syndicat.com
 PGP: https://syndicat.com/pub_key.asc
 ---
 





signature.asc
Description: This is a digitally signed message part.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] WorkingWithGit modified

[Clemens Lang]

Hi Marko,

On Sun, Aug 21, 2016 at 06:55:25AM +, MacPorts wrote:
> Page "WorkingWithGit" was changed by m...@macports.org
> Diff URL: 
> 
> Revision 20
> Comment: Add basic setup info based on KDE's configuration hints
> Changes:
> ---8<--8<--8<--8<--8<--8<--8<--8<
> Index: WorkingWithGit
> =
> --- WorkingWithGit (version: 19)
> +++ WorkingWithGit (version: 20)

Thanks for the section on setting up commiter name and email address, I
had forgot about this.

> +Additionally one should define a few (not necessarily global) presets for 
> working with your clone of the MacPorts repository:
> +{{{
> +$ git config --global push.default nothing
> +$ git config --global branch.autosetuprebase always
> +$ git config --global core.excludesfile ~/.gitignore_global
> +$ git config --global commit.template ~/.git-commit-template
> +}}}

I do not think we should recommend setting these variables for the
following reasons:

 - Users don't understand what they're doing here. I want our developers
   to know what and why things are happening with Git, not serve them a
   "here's how you ought to do it" recipe.
 - This is also the reason why the "Fetching the latest changes" section
   I wrote yesterday is so long: Developers should understand what
   happens when they run these commands, not just be told "run this". I
   think we should move branch.autosetuprebase to the end of the
   "Fetching the latest changes" section where we tell them that instead
   of the --rebase flag, they can also set this option. Also, setting
   this option globally is bad; other projects might not want this
   behavior.
 - push.default nothing may be a good idea, but I would only put it as a
   recommendation in a section on committing and pushing changes for
   people that want to make sure they're not accidentially pushing
   something they don't want to push.
 - I do not think we need .gitignore_global; We already converted our
   svn:excludes into .gitignores in the repositories and we've always
   left the configuration of svn clients to our developers. If they
   think this is necessary, they can figure it out on their own.
 - I also do not think we should recommend a git commit template for the
   same reason. Developers with Subversion have always been free to
   configure their own client and while a commit template is possible
   with Subversion, we did not recommend it there either.

What do you think?

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

Re: [MacPorts] #51448: New Portfile for pyFAI

[ILL]

Could you please check the pyFAI port ?

See ticket below.
Thanks in advance, 

Nico.


> On 26 May 2016, at 23:00, MacPorts  wrote:
> 
> #51448: New Portfile for pyFAI
> ---+
>  Reporter:  coquelleni@…  |  Owner:  macports-tickets@…
>  Type:  submission| Status:  new
>  Priority:  Normal|  Milestone:
> Component:  ports |Version:
> Resolution:|   Keywords:
>  Port:  py-pyFAI  |
> ---+
> 
> Comment (by coquelleni@…):
> 
> Replying to [comment:2 mf2k@…]:
>> Comments/Questions:
>> - The {{{depends_build-append}}} line needs to move inside the {{{if
> {${name} ne ${subport} block.
>> - Which specific version of the GPL is the license?
>> - Can openmaintainer be added?
>> - Can py35 be added?
> 
> I modified the PortFile according to your comments.
> - Moved the  {{{depends_build-append}}} line needs to move inside the
> {{{if {${name} ne ${subport} block.
> - GPL-3 licence
> - Openmaintainer added
> - py35 added.
> 
> -- 
> 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] #51664: Please add pseudo-portnames for some common programs

[Rainer Müller]

On 2016-07-02 08:51, Ryan Schmidt wrote:
> 
> On Jul 1, 2016, at 8:17 AM, Rainer Müller wrote:
> 
>> Anyway, in order to let 'port install' suggest candidates or 
>> alternatives based on binary names, we first need a database of
>> port contents.
>> 
>> This use case would be an example what such an index could be used
>> for. I would also say that makes it a good case for including such
>> a database in the ports tree (PackageIndex similar to PortIndex?).
> 
> Having that database locally on everyone's system would probably be
> huge and constantly out of date. I would favor making it a an API on
> the new web site.

It should be easily compressable. Even if it is not part of the ports
tree, I would prefer to download the database over querying an API for
every request.

I agree we have to begin somewhere, just a web interface to query this
would be a good start. But let's not plan too much here, such an API
does not depend on a potential new website in any way.

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

Re: [MacPorts] #51664: Please add pseudo-portnames for some common programs

[Ryan Schmidt]

On Jul 1, 2016, at 8:17 AM, Rainer Müller wrote:

> Anyway, in order to let 'port install' suggest candidates or
> alternatives based on binary names, we first need a database of port
> contents.
> 
> This use case would be an example what such an index could be used for.
> I would also say that makes it a good case for including such a database
> in the ports tree (PackageIndex similar to PortIndex?).

Having that database locally on everyone's system would probably be huge and 
constantly out of date. I would favor making it a an API on the new web site.


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

Re: [MacPorts] #51664: Please add pseudo-portnames for some common programs

[Rainer Müller]

On 2016-07-01 12:15, Ryan Schmidt wrote:
> 
> On Jun 30, 2016, at 7:25 AM, Rainer Müller wrote:
>>
>> Even with that, the proposal would not work for everything. There is no
>> port that provides a 'python' binary. The GNU coreutils are provided
>> with a 'g' prefix, in order not to override standard system utils by
>> default. Searching for the binary name here will not return any results.
> 
> Well it would if it were a substring or regexp search, as I think it is now 
> for the other fields...

I don't think a substring search will be specific enough in the general
case. I understood that the binary name was supposed to narrow the
result set down to only one port that is then installed.

Anyway, in order to let 'port install' suggest candidates or
alternatives based on binary names, we first need a database of port
contents.

This use case would be an example what such an index could be used for.
I would also say that makes it a good case for including such a database
in the ports tree (PackageIndex similar to PortIndex?).

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

Re: [MacPorts] #51726: Gildas Install Fail

[Ryan Schmidt]

On Jun 30, 2016, at 4:54 AM, Sébastien Maret  wrote:
> 
> I don't think that "sudo gcc select" has an effect on the compiler which is 
> used to build this port. There is a patch that forces the use of a specific 
> version of the compiler (clang for C and C++ and gfortran for Fortran). 

You should reply to this topic by visiting the ticket URL in a web browser, not 
by sending an email.

>> Ticket URL: 


>> Le 30 juin 2016 à 11:40, MacPorts  a écrit :
>> 
>> #51726: Gildas Install Fail
>> +--
>> Reporter:  jtb1435@…  |  Owner:  smaret@…
>> Type:  defect | Status:  new
>> Priority:  Normal |  Milestone:
>> Component:  ports  |Version:  2.3.4
>> Resolution: |   Keywords:
>> Port:  gildas |
>> +--
>> 
>> Comment (by bardeau@…):
>> 
>> Ok. So that's really a symbol issue. That's hard to debug without having
>> access to an identical machine and reproducing the bug. I see several
>> options, from easiest to more complicated:
>> 
>> 1) Use the MacPorts compilers, i.e.
>> sudo port select gcc mp-gcc5
>> This will change gcc and g++ from Apple LLVM ones to MacPorts ones. This
>> can be a problem for other software if they were relying precisely on the
>> Apple compilers. Note that this does not solve the issue, this circumvents
>> it by using another configuration. Once the compilers are changed, you
>> should rebuild gildas from scratch.
>> 
>> 2) Update the Apple compilers. You have Apple LLVM version 5.1
>> (clang-503.0.38), but I have 6.1. Compilers can be updated by updating
>> Xcode ( https://developer.apple.com/support/xcode/ ). However there is no
>> guarantee this solves the issue.
>> 
>> 3) Compile Gildas "by hand" (see
>> http://www.iram.fr/~gildas/dist/gildas.README section IV.2). The bug won't
>> disappear but we will will able to make some tests and iterate together.
>> 
>> As you prefer!
>> 
>> -- 
>> 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

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

Re: [MacPorts] #51664: Please add pseudo-portnames for some common programs

[Ryan Schmidt]

On Jun 30, 2016, at 7:25 AM, Rainer Müller wrote:
> 
> Even with that, the proposal would not work for everything. There is no
> port that provides a 'python' binary. The GNU coreutils are provided
> with a 'g' prefix, in order not to override standard system utils by
> default. Searching for the binary name here will not return any results.

Well it would if it were a substring or regexp search, as I think it is now for 
the other fields...

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

Re: [MacPorts] #51598: bsdmake: setrlimit: Invalid argument

[Rainer Müller]

On 2016-06-27 12:53, Joshua Root wrote:
> On 2016-6-21 07:58 , Bryan Nunweek wrote:
>> Thanks, but `sudo port -v install xinit` still fails with same error
>> when using `/opt/local/bin/bsdmake`
>>
>> The bsdmake port was already installed but was not being used. Path
>> seems OK:
>>
>>> BingleyG5:~ bryan$ echo $PATH
>>> /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
>>>
>>>
>>
>> Had to rename `/usr/bin/bsdmake` to get `/opt/local/bin/bsdmake` to be
>> used, then:
>>
>>> BingleyG5:~ bryan$ sudo port -v install xinit
>>> --->  Computing dependencies for xinit..
>>> --->  Dependencies to be installed: tradcpp xrdb xset
>>> xorg-libXfontcache xorg-fontcacheproto xorg-libXp xorg-printproto
>>> xorg-libXxf86misc xorg-xf86miscproto
>>> --->  Building tradcpp
>>> bsdmake: setrlimit: Invalid argument
> 
>  may be relevant here?
>
> Maybe we should avoid using the system bsdmake if it's known to be
> broken in this way? Though it seems to be only triggered by a custom
> configuration.

Yes, that was why I suggested using the bsdmake port, but I made a
mistake: we detect bsdmake using findBinary. That prefers the path that
was present during autoconf over anything in PATH, so just installing
the port is not enough.

I am not sure if DTrace was in the PowerPC version of OS X 10.5, but it
could be used to decode the arguments to setrlimit being used here,
although dtruss does not offer any such functionality. Maybe easier to
just patch bsdmake to report them in the error output.

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

Re: [MacPorts] #51664: Please add pseudo-portnames for some common programs

[Rainer Müller]

On 2016-06-29 19:39, Jeffrey Walton wrote:
>>  The `--long_description` modifier is just the field as written in the
>>  Portfile.
>>
>>  Regarding searching for binaries in ports, this is a completely different
>>  problem that would be addressed by having an offline index of port
>>  contents for uninstalled ports.
>>
>>  As this ticket does not propose any solution, I am closing this. Please
>>  start discussion on the [MailingLists macports-dev] mailing list. Only
>>  after having a plan, a ticket should be created with the outcome of the
>>  discussion to track the progress of the implementation.
> 
> You know there is a chronic problem; and you have proposed solution.

What is the solution? Sorry if I do not understand it yet, but how do
you propose it should be implemented?

What I understood from the ticket is that you proposed to make the
command 'sudo port install ' install the port that contains
a binary by this name. That would still not be enough to implement this.
Is that just any file in a a port at ${prefix}/bin? What if there are
multiple candidates?

At the moment, we do not have any database for this kind of mapping.
There also was another recent thread discussing that no such database
exists.

Even with that, the proposal would not work for everything. There is no
port that provides a 'python' binary. The GNU coreutils are provided
with a 'g' prefix, in order not to override standard system utils by
default. Searching for the binary name here will not return any results.

The ticket then went on about searching for ports. Just including the
name of the binaries into the description of ports would be a task that
can be done individually. You are welcome to file tickets to the port
maintainers suggesting to add that. Even better, attach a patch that
directly implements this change to the description.

> Its your sandbox. Feel free to do nothing so it does not work as
> expected in the future.

Please do not misunderstand this. I am open to change everything,
keeping corner cases and backwards compatibility in mind.

I suggested to discuss this at the mailing list, where it gets more
visibility. The tickets are helpful to keep progress when implementing
new features for base, but are not a good place for discussions.

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

Re: [MacPorts] #51726: Gildas Install Fail

[Sébastien Maret]

I don't think that "sudo gcc select" has an effect on the compiler which is 
used to build this port. There is a patch that forces the use of a specific 
version of the compiler (clang for C and C++ and gfortran for Fortran). 

> Le 30 juin 2016 à 11:40, MacPorts  a écrit :
> 
> #51726: Gildas Install Fail
> +--
>  Reporter:  jtb1435@…  |  Owner:  smaret@…
>  Type:  defect | Status:  new
>  Priority:  Normal |  Milestone:
> Component:  ports  |Version:  2.3.4
> Resolution: |   Keywords:
>  Port:  gildas |
> +--
> 
> Comment (by bardeau@…):
> 
> Ok. So that's really a symbol issue. That's hard to debug without having
> access to an identical machine and reproducing the bug. I see several
> options, from easiest to more complicated:
> 
> 1) Use the MacPorts compilers, i.e.
> sudo port select gcc mp-gcc5
> This will change gcc and g++ from Apple LLVM ones to MacPorts ones. This
> can be a problem for other software if they were relying precisely on the
> Apple compilers. Note that this does not solve the issue, this circumvents
> it by using another configuration. Once the compilers are changed, you
> should rebuild gildas from scratch.
> 
> 2) Update the Apple compilers. You have Apple LLVM version 5.1
> (clang-503.0.38), but I have 6.1. Compilers can be updated by updating
> Xcode ( https://developer.apple.com/support/xcode/ ). However there is no
> guarantee this solves the issue.
> 
> 3) Compile Gildas "by hand" (see
> http://www.iram.fr/~gildas/dist/gildas.README section IV.2). The bug won't
> disappear but we will will able to make some tests and iterate together.
> 
> As you prefer!
> 
> -- 
> 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] #51598: bsdmake: setrlimit: Invalid argument

[Joshua Root]

On 2016-6-21 07:58 , Bryan Nunweek wrote:

Thanks, but `sudo port -v install xinit` still fails with same error when using 
`/opt/local/bin/bsdmake`

The bsdmake port was already installed but was not being used. Path seems OK:


BingleyG5:~ bryan$ echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin



Had to rename `/usr/bin/bsdmake` to get `/opt/local/bin/bsdmake` to be used, 
then:


BingleyG5:~ bryan$ sudo port -v install xinit
--->  Computing dependencies for xinit..
--->  Dependencies to be installed: tradcpp xrdb xset xorg-libXfontcache 
xorg-fontcacheproto xorg-libXp xorg-printproto xorg-libXxf86misc xorg-xf86miscproto
--->  Building tradcpp
bsdmake: setrlimit: Invalid argument


 may be relevant here?

Maybe we should avoid using the system bsdmake if it's known to be 
broken in this way? Though it seems to be only triggered by a custom 
configuration.


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

Re: [MacPorts] #51598: bsdmake: setrlimit: Invalid argument

[Bryan Nunweek]

Thanks, but `sudo port -v install xinit` still fails with same error when using 
`/opt/local/bin/bsdmake`

The bsdmake port was already installed but was not being used. Path seems OK:

> BingleyG5:~ bryan$ echo $PATH
> /opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
> 

Had to rename `/usr/bin/bsdmake` to get `/opt/local/bin/bsdmake` to be used, 
then:

> BingleyG5:~ bryan$ sudo port -v install xinit
> --->  Computing dependencies for xinit..
> --->  Dependencies to be installed: tradcpp xrdb xset xorg-libXfontcache 
> xorg-fontcacheproto xorg-libXp xorg-printproto xorg-libXxf86misc 
> xorg-xf86miscproto
> --->  Building tradcpp
> bsdmake: setrlimit: Invalid argument
> Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_tradcpp/tradcpp/work/tradcpp-0.4"
>  && /opt/local/bin/bsdmake -j4 all 
> Exit code: 2
> Error: org.macports.build for port tradcpp returned: command execution failed
> Warning: targets not executed for tradcpp: org.macports.activate 
> org.macports.build org.macports.destroot org.macports.install
> Error: Failed to install tradcpp
> Please see the log file for port tradcpp for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_tradcpp/tradcpp/main.log
> Error: The following dependencies were not installed: tradcpp xrdb xset 
> xorg-libXfontcache xorg-fontcacheproto xorg-libXp xorg-printproto 
> xorg-libXxf86misc xorg-xf86miscproto
> To report a bug, follow the instructions in the guide:
>http://guide.macports.org/#project.tickets
> Error: Processing of port kinit failed


> On 20/06/2016, at 22:51, MacPorts  wrote:
> 
> #51598: bsdmake: setrlimit: Invalid argument
> --+--
> Reporter:  bryan.nunweek@…  |  Owner:  raimue@…
> Type:  defect   | Status:  closed
> Priority:  Normal   |  Milestone:
> Component:  ports|Version:  2.3.4
> Resolution:  wontfix  |   Keywords:
> Port:  bsdmake  |
> --+--
> Changes (by raimue@…):
> 
> * status:  new => closed
> * resolution:   => wontfix
> 
> 
> Comment:
> 
> Up to Xcode 4.2, bsdmake was still shipped with the system. As can be seen
> from the attached `main.log`, it is using `/usr/bin/bsdmake` and not
> `/opt/local/bin/bsdmake`. Installing the bsdmake port might solve your
> problem.
> 
> -- 
> 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