Re: Proposal for a MacPorts'ish commit message template

[Rainer Müller]

On 2016-11-04 18:46, Lawrence Velázquez wrote:
> Actually, I might have been thinking about another editor. My vim
> highlights the subject in *green* up until 50 chars, and then black for
> the overflow. But one can probably change that black to red if they want
> :P

.vimrc:
hi def link gitcommitOverflow Error

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

Re: PR usage by people with commit access

[Rainer Müller]

On 2016-11-04 18:10, Ivan Larionov wrote:
> I'm not saying that you have to wait for review or something like
> this, but opening a PR from your branch and then merging it has some
> pros:
> 
> * Better visibility of changes. Instead of cloning full repository
> and digging through history I can search PRs by port name and see
> changes which were done by maintainers and contributors.

You cannot filter by portname in a reasonable way. GitHub search is just
too limited to support anything like that. That is one of the main
reasons we rejected GitHub Issues, which have the same problem.

Isn't it much easier to just view the history of the corresponding port
directory than a convoluted search? You can also do that on GitHub:

https://github.com/macports/macports-ports/commits/master/python/py-sqlparse

> * Using the same change methods as outside contributors may help to
> develop better PR flow. Currently I see some lack of the standard
> flow, maintainers commit contributors' changes in different ways, PRs
> marked as rejected while they're actually merged, people ask to
> enable "Allow edits from maintainers" for PR, etc.

They were "rejected" because GitHub does not have a way to mark them as
"merged" unless the exact same object was merged. In case the maintainer
had to make additional changes to the commit, GitHub will not recognize
them as merged.

The only solution we found so far is to push the modified commits back
to the pull request branch, which will mark the pull request as
"merged". However, that requires that pull request authors allow
modifications by maintainers.

> * Ability to get a feedback / review from other project members.
> 
> We use private github setup on my work and we have a rule that you
> shouldn't commit directly to master in a project with multiple
> contributors until it's very small change like fixing typo. Open PR,
> ask for review, merge. Or fix issues and merge if you got any useful
> comments on PR.

Who would be better to review the change then the maintainers of ports
themselves? I feel like this would unnecessary slow down the process of
getting the update out.

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

Re: Working with Git

[Rainer Müller]

On 2016-11-04 03:41, Lawrence Velázquez wrote:
>> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt  wrote:
>>
>> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git
>> branch -d l2dy-curl-ca-bundle-update" failed because of an error.
> 
> Do you remember what the error was? The next time it happens could you
> let me know? I could certainly have overlooked something.

After the branch was pushed to the remote master, locally the commits
are only in this branch. You need to do another pull on the master
branch, which will introduce these changes locally, before you can
delete the changes without error.

$ git checkout master
$ git pull --rebase
$ git branch -d l2dy-curl-ca-bundle-update

Rainer
___
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: Properly merging pull requests

[Rainer Müller]

On 2016-11-03 18:57, Lawrence Velázquez wrote:
>> On Nov 3, 2016, at 1:46 PM, Rainer Müller <rai...@macports.org> wrote:
>>
>> I think the proper way to do it on GitHub would be as follows:
>> When the pull request author checked the box for "Allow modifications by
>> maintainers" [1], you can force-push your changes to the pull request
>> branch, replacing the original commits. Then you can merge the pull
>> request from the GitHub web interface.
> 
> GitHub will also automatically close the PR as "merged" if you push the
> PR branch's changes to master from a local client. It's quite nice.

If I understand this correctly, the exact commits have to be on the pull
request branch for GitHub to recognize you want to close the PR. So I
would have to push them first to the pull request branch and then to master.

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

Re: Pull Requests for Work in Progress (WIP)

[Rainer Müller]

On 2016-11-03 17:49, Sterling Smith wrote:
>  The main question of procedure is: Should the main macports repo be
> used for proposing review of work in progress via pull requests?  If
> not, what is the proposed method?

I propose you put your changes on a branch, add the compare URL to a
ticket or send an email to macports-dev.

In the case you referred to, this would be:

https://github.com/mkae/macports-ports/compare/master...mkae:qtcurve_upgrade-for-Qt5

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

Re: Properly merging pull requests

[Rainer Müller]

On 2016-11-03 16:59, Mojca Miklavec wrote:
> Hi,
> 
> We have recently experienced problems with pull requests showing up as
> rejected on the web interface rather than merged (while the changes
> were in fact accepted, possibly with some modifications).
> 
> I admit my sins. In one case I did a minor modification (squashed
> commits, removed the "Id" line, edited the commit message), while
> basically everything else stayed the same as the author submitted and
> everyone would have preferred if GitHub displayed "Merged" rather than
> the red rejected sign.
> 
> We could have asked the author to keep fixing the branch forever, but
> at some point it's simply faster and easier if an experienced
> MacPorter just finishes the obvious rather than turning the users away
> due to some stupid mistakes. The users can fix the mistakes in the
> next PR.
> 
> In another case I (stupidly?) decided to add "Closes: #N" at the end
> of the commit message (I thought it would be useful to have a link to
> the original PR which is something that the committer cannot do anyway
> without knowing the number of PR in advance). I probably also sinned
> by thinking of "playing safe" and using cherry-pick rather than
> "wrongly rebasing" and risking some undesired merge.

GitHub will already add an annotation right next to the branch name in
the commit view to show that this commit came from a pull request. As an
example, note "master (#2)" right below the commit message here:

https://github.com/macports/macports-ports/commit/ec150ad742e511cc38e5a0815c8b5805125d2aea

I think the proper way to do it on GitHub would be as follows:
When the pull request author checked the box for "Allow modifications by
maintainers" [1], you can force-push your changes to the pull request
branch, replacing the original commits. Then you can merge the pull
request from the GitHub web interface.

> Can someone provide some guidelines of DOs and DONTs when accepting
> (and modifying) pull requests? That should cover the cases that need:
> - squashing commits
> - minor edits of commit messages
> - other minor edits of the sources

If commits were made to address review comments, but these commits do
not follow our rules for commit messages, they need to be squashed or
edited. Otherwise, after the changes were brought to master with a
rebase, looking at these commit messages in the linear history would not
clearly show what they addressed.

Rainer

[1]
https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/
___
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: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[Rainer Müller]

On 2016-11-03 12:38, René J.V. Bertin wrote:
> Conversion of existing tickets would be nifty, but I don't think it's 
> something I'd miss myself.

What do you want to discuss then? A bug tracker is for tracking, we will
not throw everything away that was reported.

Overall, can we just stop this discussion, please? We settled to stay
with Trac and it is not going to change.

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

Re: GitHub usernames as maintainers

[Rainer Müller]

On 2016-11-02 23:58, Clemens Lang wrote:
> On Wed, Nov 02, 2016 at 06:45:21PM -0400, Brandon Allbery wrote:
>> For me, it looks too much like an email address when combined with
>> other things (e.g. "maintainers openmaintainer @foo").
> 
> I think that's a formatting problem. We could just as well print
> https://github.com/neverpanic in the output of port info --maintainer,
> which is (a) not ambiguous, and (b) clickable.

Although clickable, from such an URL it is quite strange to deduce what
to use in the CC field on tickets.

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

Re: Github user repos?

[Rainer Müller]

On 2016-11-02 23:39, Ryan Schmidt wrote:
> Contrary to Rainer's statement above, my plan was to leave unclaimed
> old user repo in the macports org indefinitely. Deleting them implies
> they contain no useful information; having not examined them, I'm not
> in a position to make that determination.

I do not mind keeping them in the GitHub organization for the time
being, but after some time has passed, we should get rid of unclaimed
user repositories.

We will still have these files and their history in the svn repository,
that will stay available as a read-only copy.

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

Re: Proposal for a MacPorts'ish commit message template

[Rainer Müller]

On 2016-11-02 23:46, Ryan Schmidt wrote:
>> Which editor are you using? It differs by editor.
> 
> Well, you mentioned vim. Very occasionally I use that. I don't
> remember seeing any particular syntax highlighting in it when editing
> a commit message.

You would need these settings in your ~/.vimrc, which enable syntax
highlighting in general:

  filetype plugin indent on
  syntax on

On the first line, the text color will change after 50 characters.
The second line will turn red if it is not blank as supposed to be.

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

New mailing list host: lists.macports.org

[Rainer Müller]

Hello,

as part of the move off of macOS forge, we will migrate the mailing
lists to the new mail server. We will migrate all subscriptions and user
preferences and postings to the old mailing list addresses will be
forwarded. However, the new hostname lists.macports.org implies that
addresses and List-Ids will change.

Please adapt your filtering rules and expect mails with addresses
@lists.macports.org.

The migration of all lists to the new host and addresses will happen
this weekend, November 5/6.

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

Re: Trac down again

[Rainer Müller]

On 2016-11-02 19:16, Adam Mercer wrote:
> On Tue, Nov 1, 2016 at 10:17 AM, Rainer Müller <rai...@macports.org> wrote:
> 
>> We still have some options for tuning, but as it only occurs
>> sporadically, we always have to wait to see if this solved it.
> 
> Seems like trac is down again, just got a 503. Does it need another kick?

We are on it and investigating what the currently running requests and
processes are. It will return shortly.

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

New project members: jonesc

[Rainer Müller]

Please join us in welcoming the following new MacPorts project member:

 - Chris Jones (jonesc)

We look forward to continued excellent contributions!

- Joshua, Ryan, and Rainer


Do you want to join the MacPorts team? If you would like to be
considered for team membership and commit access, please read this
section of the Guide:

http://guide.macports.org/chunked/project.membership.html
___
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: Github user repos?

[Rainer Müller]

On 2016-11-01 21:10, David Evans wrote:
> I see that some github user repos have been created while others (like mine 
> ;-) ) have not.  Is this an ongoing process
> that's going to take a while or is there some action that the user needs to 
> take and get his repo created?

Yours is already there:

https://github.com/macports/macports-user-devans

GitHub only show the most recently modified repositories on the
organization page. You need to use the search box on top of the list of
repositories to find it.

> BTW, I note that at least one of those already created belongs to a 
> maintainer who has not been with us for quite a
> while (nox).

The plan is to eventually remove them, if users do not claim them.

> Maybe they should be done on a per request basis to avoid converting 
> abandoned user space.

All of our Subversion history was converted and each commit moved to the
appropriate Git repository. There is no extra work involved with this.

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

Re: How to handle MacPorts' handles in the future (including the email address connected to it)??

[Rainer Müller]

On 2016-11-01 20:27, Marko Käning wrote:
> I’d actually be happier if I had my - up to now - MacPorts handle
> (mk) also for the future… :)
> 
> But ok, I guess I’ll have to apply at ad...@macports.org for a new
> handle then, being m...@macports.org, right?
> 
> The only problem with all this is, that I then have to ask my good
> old friend Brad (pixilla) to create that user mkae on his mail server
> (which can handle address rewriting).

What do you mean by address rewriting? If you are referring to problems
with SPF, the new mail server is now doing SRS [1].

> Well, as an alternative I could go through my own email provider, but
> they have special requirements for such address rewriting and I
> wonder whether at least those could be fulfilled by macports.org - in
> case it is absolutely impossible to get an email address at MacPorts’
> IMAP server directly.

Right now we do not host any mailboxes with IMAP, we only forward mails
to existing addresses. I would like to keep the administrative overhead
low, certainly all developers have an existing mailbox.

Although I thought about implementing authenticated mail submission on
our mail server in order to be able to enable SPF for macports.org and
reduce spam. But that will not happen in the near future while there are
other issues.

Rainer

[1] http://www.openspf.org/SRS
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Removing "$Id$" lines

[Rainer Müller]

On 2016-11-01 19:43, Lawrence Velázquez wrote:
> In any case, the proposed set of commits is utterly unnecessary and is
> not worth any of this fuss.

I do not want to keep commenting on every single submission that it
needs to remove the $Id$ line. This should be done as one commit and we
would never see it again.

If I had anticipated that this would cause such a problem because of the
buildbots, I would have insisted we remove $Id$ during the repository
migration...

Rainer
___
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

Re: rev-upgrade question

[Rainer Müller]

On 2016-11-01 19:50, Clemens Lang wrote:
> On Tue, Nov 01, 2016 at 07:09:48PM +0100, Marko Käning wrote:
>> how can I convince rev-upgrade to actually rebuild broken ports if
>> 'revupgrade_mode' is set to ‘report' in macports.conf? 
> 
> You can specifically rebuild them manually using port -nf upgrade $port.

Never use the global force option -f with upgrade, but instead:

  sudo port -n upgrade --force $port

The local --force was specifically added to only force the upgrade, but
do not apply force to any other phase. In case of variant mismatches,
the global 'port -f' will continue although the state in the work/
directory is inconsistent. In case of activation conflicts, the global
'port -f' will blindly overwrite existing files.

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.

[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: Trac down again

[Rainer Müller]

On 2016-11-01 13:54, Marko Käning wrote:
> Trac is down again. It seems like it is periodically dying and reviving 
> itself. :(

I kicked it again.

Periodically, too many requests clog up the web server threads. The
server would still have free resources and the load average is also not
particularly high.

We still have some options for tuning, but as it only occurs
sporadically, we always have to wait to see if this solved it.

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

Re: Working with Git

[Rainer Müller]

On 2016-11-01 05:54, Mojca Miklavec wrote:
> I can imagine a newbie trying to navigate to the page and thinking
> that installation of Homebrew is necessary for making that software
> work, just to screw up the rest of MacPorts. An additional problem
> might be that whenever users have a problem with the software and file
> a bug report, they might get an equally annoying answer saying
> "Install Homebrew, I don't support MP". I had a problem with one
> particular project in the past that a typical answer to any bug report
> I filed was "stop using MacPorts, it's obviously broken" when in 90%
> of the cases it was their bug that just showed up when using certain
> newer dependencies or a particular set of configure flags they never
> tested.

You see these kind of messages on many software homepages on the web,
because the Homebrew crowd has to spew it everywhere. Nobody should
think Homebrew is required because of them.

By adding hub to instructions, we never send people to their homepage,
so they will not even see this message.

> I'm with Ryan in this case. We don't prevent anyone from using this
> software if they choose to, I just don't see the point of advertising
> software whose maintainer decided to go against MP.

This argument is just nonsense. I am not going to stop using vim just
because upstream decided to mention Homebrew (and only Homebrew) in its
README_mac [1].

I do not see valid reasons not to use hub.

Rainer

[1] https://github.com/vim/vim/blob/master/READMEdir/README_mac.txt
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Removing "$Id$" lines

[Rainer Müller]

On 2016-11-01 01:03, Ryan Schmidt wrote:
> On Oct 31, 2016, at 17:17, Dan Ports  wrote:
>> 
>> Any reason not to just bulk-remove them all at once?
> 
> That would probably tie up the buildbot for weeks or months. We could
> cancel those builds, but even the act of scheduling 20,000 builds per
> builder is much more than we've ever attempted before and I think it
> would not be happy about it. At the very least, I would want to wait
> until I've switched the buildbot from SQLite to PostgreSQL.

Can we maybe decide on special commands in commit messages that cause
the buildbot to completely ignore the commit? Such things should not
limit us to what we can commit or not.

Perhaps a footer line (similar to Signed-off-by) at the end, such as:

buildbot: ignore


For reference, other services seem to use "[ci skip]" as a keyword that
can appear anywhere in the commit message.

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

Re: GitHub migration complete

[Rainer Müller]

On 2016-10-31 11:41, René J.V. Bertin wrote:
> Pity though, the first-run portindex of a fresh git clone just took about 5 
> quarters of an hour on one of my machines (a good 5s/port).

Just as with Subversion.

To speed it up, you could seed it with the latest generated version
from rsync:

  rsync -vt 
rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex*
 $ports

Just make sure you use the correct OS version in the rsync path. There
is also no guarantee that this really matches the git ports tree, which
might already contain newer Portfile changes.

Rainer

PS: On purpose not sending this to macports-users, as it should not be
used in the general case.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CC maintainer on GitHub

[Rainer Müller]

On 2016-10-31 10:47, Zero King wrote:
> I just submitted a PR on GitHub and the wiki didn't say how to CC the
> maintainer. Should I use mention like @ryandesign?

Yes, we need to use mentions. GitHub does not provide anything better.

In the general case, you would first need to map the MacPorts handle to
a GitHub username.

> If mentioning is correct I suggest that we use mention-bot [0] to
> automatically mention developers in PRs.
> 
> [0] https://github.com/facebook/mention-bot

A bot like this sounds like a good idea, but we would need custom rules
to specifically mention the maintainers.

Mentioning those who touched the file in the past will mostly hit those
that regularly committed patches from Trac, but not the maintainer.

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

Re: Compiling dnsmasq with dnssec support?

[Rainer Müller]

On 2016-10-30 16:40, Johannes Kastl wrote:
> Hi Joshua,
> 
> On 30.10.16 12:19 Joshua Root wrote:
>> On 2016-10-30 19:15 , Johannes Kastl wrote:
>>> Question 1: Is it possible to use different
>>> patchfiles-statements, depending on the variant?
> 
>> Yes.
> 
> As the documentation (at least the pages I found) does not have an
> example of this, do you know of any port that uses this?

variant dnssec description {Enable DNSSEC} {
patchfiles-appendpatch-dnssec.diff
}

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

Trac's Cc Me button is too small

[Rainer Müller]

On 2016-10-30 04:21, Fred Wright wrote:
> Though if the new "Cc me" button were any smaller, it would be considered
> a web bug. :-)

I agree it is too small.

The CSS rules for this button are minimal in addition to what Trac has
for all other buttons. CSS and full plugin sources are available and
linked in the corresponding ticket. If anyone has suggestions how to
make it look better, just post them.

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

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

Re: Moving to GitHub: Status Update, Action Required

[Rainer Müller]

On 2016-10-28 16:02, Craig Treleaven wrote:
>> On Oct 21, 2016, at 2:12 PM, Clemens Lang  wrote:
>> ...
>> Migration Timeline
>> ==
>> The switch to Git will happen on the weekend of October 29th/30th. ...
> 
> Is this still on track?

Yes, expect Subversion to go read-only this weekend. Shortly afterwards,
the repositories on GitHub will be the authoritative source for MacPorts.

The infrastructure team did not schedule the exact time when this will
happen, but definitely this weekend.

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

Re: port:gpgme / Fwd: Review Request 129265: Port from KF5Gpgme to GpgME

[Rainer Müller]

On 2016-10-27 09:58, René J.V. Bertin wrote:
> I'm not getting into trac (github being DDoS'ed again??), so I'm forwarding 
> this info via the ML hoping Ryan will catch it.

Once again, our Trac is not hosted by GitHub.

This is still the same cause Clemens reported on yesterday. Please bear
with us while we are trying to find the right knobs to avoid these timeouts.

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

Re: Moving to GitHub: Status Update, Action Required

[Rainer Müller]

On 2016-10-25 10:36, Ryan Schmidt wrote:
> 
> 
> On Oct 24, 2016, at 17:57, Clemens Lang  wrote:
> 
>>> On Tue, Oct 25, 2016 at 12:17:57AM +0200, Marko Käning wrote:
>>> A description of how exactly one would rebase (potentially squash and
>>> history-rewrite) a submitted PR onto current master should be on our
>>> WorkingWithGit wiki page.
>>
>> the easiest approach is just clicking the button that does this on
>> GitHub. Of course there's also a way to do it from the command line.
> 
> We should document, with screenshots, the specific buttons that should be 
> clicked to achieve this, for the benefit of those developers like me who are 
> not that familiar with git and GitHub. 

Keeping such a documentation with screenshots updated to the current
GitHub release seems excessive. The GitHub documentation already has
screenshots. We should not try to recreate it, but rather place the
links to the relevant sections.

https://help.github.com/articles/merging-a-pull-request/

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

Re: Trac & Subversion available again

[Rainer Müller]

On 2016-10-24 20:24, Daniel J. Luke wrote:
> On Oct 24, 2016, at 1:26 PM, Clemens Lang  wrote:
>> On Mon, Oct 24, 2016 at 12:54:23PM -0400, Daniel J. Luke wrote:
>>> This looks like it's true for me as well (cannot edit tickets beyond
>>> making comments).
>>
>> Try clearing your cache (a force-reload should do that). It seems the
>> problem can also be that the edit form is there, but hidden for you due
>> to some CSS rules.
> 
> no luck (also tried a second browser just in case).

The permission to edit tickets is granted by being a member of the
macports/developers team on GitHub.

Existing developers need to request to be added to this team by sending
a mail to the macports-infra mailing list as instructed in the announcement.

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

Re: New Trac Uses Session Cookies

[Rainer Müller]

On 2016-10-22 18:16, Zero King wrote:
> Please provide an option to keep the cookies after browser exits.

Thanks for noticing. I raised the expiry date of cookies to 30 days.

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

Re: SVN committing not possible ATM?

[Rainer Müller]

On 2016-10-22 14:44, Marko Käning wrote:
> I just now couldn’t commit to the SVN server:
> 
> ---
> $ svn ci -m "gwenhywfar4-devel: update to 4.16.0beta"
> SendingPortfile
> Transmitting file data .svn: E175002: Commit failed (details follow):
> svn: E175002: Unexpected server error 500 'Internal Server Error' on 
> '/repository/macports/!svn/txr/154147-3axv/trunk/dports/devel/gwenhywfar4/Portfile’
> ---
> 
> Very likely, I am just not authenticating properly. What do I have to change 
> to make this work again?

This is probably some configuration issue on the server. We have not yet
figured out what causes this, but you are the second to report this. It
only seems to affect some users with specific commits.

I have a slight suspicion that it is related to internal locking in
mod_dav_svn for some operations, but could not nail it down yet.

Rainer

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

Re: foo-snapshot / foo-diff convenience functions

[Rainer Müller]

On 10/20/2016 10:25 PM, René J.V. Bertin wrote:
> On Thursday October 20 2016 15:38:42 Lawrence Velázquez wrote:
> 
>> Better that than increasing the complexity of base and portfiles.
> 
> Yeah, unless someone proposes to implement something in a portgroup. Then all 
> of a sudden it becomes base functionality ...

Port groups can be complex as long as that makes it easier to use the port group
in a Portfile. That is the whole point of port groups, eliminate redundancy and
make Portfiles concise.

However, port groups also have their limits of what can be implemented.
Functionality for all ports or extensions to the syntax should be in base.

Back to your proposal: in my opinion, such a syntax does not fit the declarative
style we commonly have in Portfiles. Previously we agreed more settings should
be declarative, but this would be a step backwards. In an ideal Portfile, port
groups are included by statements at the top of the Portfile and there is no
need to set anything before that.

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

Re: Trac down?

[Rainer Müller]

On 2016-10-20 20:28, Vincent Habchi wrote:
>> On 20 Oct 2016, at 14:04, Ryan Schmidt  wrote:
>> Trac, svn, www-origin and guide-origin are inaccessible outside of the Apple 
>> network. I'm trying to figure out why.
> 
> I’ve been very busy lately and didn’t have much time but for very perfunctory 
> looks at MacPorts. Now I’m almost back but… it doesn’t work. This has nothing 
> to do with migrating to git or whatever?

No, this downtime is not intentional or planned.

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

Re: 2nd MacPorts Meeting & Online Meeting

[Rainer Müller]

On 2016-10-16 22:36, David Evans wrote:
> * now that I think about it, using irc might be the best way to go since a 
> transcript of the meeting
>   can be obtained from the irc logs.  After the meeting this can be processed 
> into a "minutes" document and
>   published to document the meeting proceedings. That way, people who don't 
> participate can benefit from
>   the meeting's discussion.

IRC bots with support for meeting can be used for this. They can be
instructed with commands to take notes of decisions and action items
during a meeting:

http://meetbot.debian.net/Manual.html

There might also be more modern business chat providers, but I have no
experience with any of them. IRC should be accessible to all and
FreeNode also offers a web interface.

> Establishment of a meeting time that is convenient to participants in a wide 
> range of
> geographical locations is probably the most difficult task and is key to good 
> turnout.  Maybe say 9 to 10 am on the
> US west coast which would translate to 6 to 7 pm in various parts of Europe.  
> Weekends might be better than
> weekdays to avoid conflicts with daily work schedules.

I also think finding the right time and date is the biggest obstacle.

I guess we should also not leave too much time between setting topics
and the actual meeting to avoid starting discussions early.

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

Re: 2nd MacPorts Meeting & Online Meeting

[Rainer Müller]

On 2016-10-16 23:58, Clemens Lang wrote:
> On Mon, Oct 10, 2016 at 07:53:13AM +0200, Mojca Miklavec wrote:
>> Me and Aljaž would be willing to host the MacPorts meeting in 2017
>> again.
> 
> Thanks, and sorry for not putting a plan together to do it in Munich in
> the fall. Seems I need to improve my time management :)

I feel guilty for that as well. However, there was a a lot of other
time-consuming stuff going on with the migration. Maybe we can revive
the plan another year.

I would appreciate another meeting next year. I will definitely want to
attend.

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

Re: MP Cert Revoked?

[Rainer Müller]

On 2016-10-13 17:11, Clemens Lang wrote:
> Hi,
> 
> - On 13 Oct, 2016, at 17:00, Michael Dickens michae...@macports.org wrote:
> 
>> Your connection is not private
>> Attackers might be trying to steal your information from
>> trac.macports.org (for example, passwords, messages, or credit cards).
>> NET::ERR_CERT_REVOKED
> 
> See https://twitter.com/globalsign/status/786505261842247680
> See also http://apple.stackexchange.com/a/257082
> 
> The problem is with the intermediate, not with our certificate, it seems.

Here is a statement from GlobalSign on the matter:

https://downloads.globalsign.com/acton/fs/blocks/showLandingPage/a/2674/p/p-008f/t/page/fm/0

The responses will be cached on your system for the next days. Manual
user action is required to clear the cache if you want to get rid of the
error earlier.

On older versions of the Mac operating system, the command
  crlrefresh rp
might clear the cache in /var/db/crls/*cache*.db, but I had no way to test.

On macOS 10.12 Sierra, the cache appears to be stored in
~/Library/Keychains/*/ocspcache.sqlite3

I do not know any official, documented way from Apple to clear cached
entries in this database. However, I documented some way that worked for
me here:

https://apple.stackexchange.com/questions/257080/how-to-tell-why-macos-thinks-that-a-certificate-is-revoked/257112#257112

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

Re: Can't edit commit message

[Rainer Müller]

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

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

Rainer

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

Re: path normalisation in "base"

[Rainer Müller]

On 2016-10-11 16:38, René J.V. Bertin wrote:
> This does work though:
> 
> {{{
> proc macports::normalize { filename } {
> # normalise the user-specified prefix. The test file under $prefix need 
> not exist for that:
> set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
> set file [file normalize $filename]
> # check if the result starts with the "normalised" prefix:
> if {$nprefix ne $macports::prefix && [string first $nprefix $file] eq 0} {
> # obtain the part after the normalised prefix, and prepend the 
> user-specific prefix to it:
> set file [file join $macports::prefix [string range $file [string 
> length $nprefix]+1 end]]
> }
> return $file
> }
> }}}

This might solve the ${prefix} being a symlink. Do we want to treat that
as a supported special case after all?

If ${prefix}/bin is a symlink, this would still not work as expected.
How do we decide when to honor a symlink put in place by a port versus
ignoring a manual replacement in normalization? At which paths do we
want to support symlinks?

We make certain assumptions about ${prefix}, such as the common check
for [file writable ${prefix}] throughout the code. We should make sure
these always follow the symlink and not report status of the symlink
itself. Symlinks have their own permission bits on HFS+, can be changed
by chmod -h and will adopt umask on creation.

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

Re: path normalisation in "base"

[Rainer Müller]

On 2016-10-11 10:43, René J.V. Bertin wrote:
> To come back to action_provides: if the registry saves a port's
> "intended" paths (the ones stored in the software image tarball), why
> do a lookup of the actual/resolved path? That would make it
> impossible to check which port installs a symlink (to a file or
> directory installed by itself, some other port, or even to something
> in system space), regardless of whether there are "unexpected"
> symlinks in the path, no?

I cannot reproduce these claims. 'port provides' works for symlinks as
expected. Note that file normalize does not resolve symlinks in the last
component.

$ readlink /opt/local/lib/terminfo
../share/terminfo
$ port provides /opt/local/lib/terminfo
/opt/local/lib/terminfo is provided by: ncurses
$ port provides /opt/local/lib/terminfo/78/xterm
/opt/local/share/terminfo/78/xterm is provided by: ncurses

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

Re: Documentation overhaul

[Rainer Müller]

On 2016-10-10 01:23, Ryan Schmidt wrote:
> Thanks for your interest, Marcel, but do you feel you would be able
> to lead such an effort, since you seem to be new to MacPorts? I've
> been with MacPorts for around 10 years and have thought of rewriting
> the documentation for several years so I feel I might be able to do
> it. I'm just not doing it right this second because I'm busy trying
> to move us to new hosting. And also because we don't yet know how how
> we will work on GitHub, so we can't fully document that yet.

Our documentation has been in a dire state for years now. As I mentioned
before, the new help system was started by me about 7 years ago. Even
back then we were already discussing to convert/rewrite the guide. Not
much has changed since then.

Most of the time the man page project was in limbo because nobody was
writing the actual man pages. I also lost motivation after a while and
eventually Clemens picked it up and finished it.

Now here is Marcel offering his help with the documentation. I do not
want to turn down his offer or stop him from contributing in any way.

I do not think a lot of experience is required to write good
documentation. Especially when we are talking about reorganizing the
existing documents. Being only a user could help to write the
documentation from the view of a user without diving too deep into
internals.

Moving away from Docbook, converting the existing content or evaluating
other tools would be a lot of work that could be done by anyone.

> My plan is to read all documentation, maybe even print it all out on
> paper (guide, wiki, web site), cut it up, group related information
> together, remove duplication (like the three different sets of
> install documentation we currently have), remove superfluous
> language, simplify, and also add new documentation for things that
> currently aren't documented, like newer portgroups. Also review the
> organization and content of the documentation of other projects that
> I consider well done, such as svnbook.org. If you know of other good
> documentation I should review let me know.

One of the most important steps would be to split the documentation
clearly into:

* Installation
+ MacPorts Quickstart/Cheat Sheet
* Using MacPorts
* Writing Portfiles
* Contributing
+ List of Terms/Glossary
* Management Policies
* Internals for base Developers

  * = already exists
  + = needs to be written

Overall:
make it more concise, less text, examples instead of explanations.

Maybe split installation instructions by macOS versions so users only
see relevant instructions.

It would also be good to have some conditionals to mark
paragraphs/sections by version. Then we could write documentation for
trunk while the website keeps displaying the stable versions (or let you
choose).

To me, svnbook.org is old, outdated and the HTML version on the web
definitely does not feel modern.

> My plan is to do this after redoing the web site. I intend to keep
> the installation instructions that have to do with the default
> installation using the macOS Installer on the web site, so rewriting
> that will be a good beginning to rewriting the documentation.

I know you have been working on the new website for quite a while. But
you also do the buildbot and other management related tasks. I would
even say chances are high that this will be delayed further...

If Marcel has time right now, I think he should just start with the
documentation.

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

Re: reasons for `port provides` not working?

[Rainer Müller]

On 2016-10-10 18:05, René J.V. Bertin wrote:
> Is there a good reason why action_provides (in port) does a `file normalize`? 
> Wouldn't it be just as OK if the actual registry lookup (after doing all 
> checks) used the original $filename?

file normalize is used to support relative paths and paths containing
"../" components.

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

Re: reasons for `port provides` not working?

[Rainer Müller]

On 2016-10-10 16:49, René J.V. Bertin wrote:
> On Monday October 10 2016 15:30:57 Clemens Lang wrote:
>> IIRC the problem was that your installation mangled paths somehow, either by
>> making /opt/local a symlink or some other uncommon configuration.
> 
> Yes (/opt/local is a symlink), but from what I read on here that is not 
> *that* uncommon and that it's been getting silent support in practice.

What kind of setup is this?
1) /opt/local is the prefix, but the directory was moved and replaced
   with a symlink
2) you installed into a different prefix and then added a symlink at
   /opt/local

> Either way, this shouldn't have any incidence on file-to-port lookups.
> Either:
> - /opt/local/foo/bar is registered as such and a look-up of that path succeeds
> - /opt/local/foo/bar is actually /what/ever/foo/bar, registered as such, and 
> thus a look-up of the resolved path succeeds.
> 
> Neither look-ups work via `port provides` (i.e. via 
> registry::file_registered) but one of them clearly does via [registry::entry 
> owner] (in portimage.tcl::activate_contents). 

Which one does work? What does 'port contents' return?

You could also look into the registry manually to find out which path
was registered. Instructions are here:

https://trac.macports.org/browser/trunk/base/src/cregistry/README.sqlext

For example:
SELECT * FROM files WHERE id = (SELECT id FROM ports WHERE name = 'zlib'
AND state = 'installed');

Note: state 'installed' corresponds to the pseudo-port active, while the
pseudo-port installed would be 'imaged'. Historical reasons.

>> You'll forgive me when I just tell you that problems caused by unsupported
>> modifications made by you locally are not supported by MacPorts. I won't 
>> spend
>> any time diagnosing this unless you can show that it's broken in a fresh
>> install.
> 
> Good thing I didn't ask you specifically then... 
> 
> In fact, in absence of proof that my use of a symlinked $prefix explains 
> everything I won't assume that that is the culprit. I'm more inclined to 
> believe that it is the rescue operation I've had to do a year or 2,3 back 
> because an upgrade (2.3.3 -> 2.3.4 IIRC) had not run all required steps. As 
> far as I can remember `port provides` worked perfectly fine in 2.3.3 - and 
> I've always had a symlinked $prefix.

The general rule is that if you run a non-standard installation, you
will have to debug that yourself, because it is complicated to reproduce
your issue for anyone else.

If your last upgrade was not complete, it is usually safe to just re-run
the installation on top of the existing prefix.

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

Re: Documentation overhaul

[Rainer Müller]

Hello Marcel,

On 2016-10-09 15:53, Marcel Bischoff wrote:
> As Ryan has identified that the online documentation needs work, I'm
> hereby volunteering to give it a go. Since there appear to be quite
> specific views on how everthing here needs to be, I'm asking in advance:
> 
> - Is that in everyone's interest?

Of course! :-)

> - Is there already someone working on it?

We have a new help system on trunk. Each command has a separate man page
that can be reached with 'port help install' and similar. Eventually
these should also end up on on the web, for example at man.macports.org.

https://trac.macports.org/wiki/NewHelpSystem

The source of the new man pages can be found in base/doc/*.txt in
AsciiDoc format:

https://trac.macports.org/browser/trunk/base/doc

> - Where should the final documentation be located: separate website,
>  GitHub wiki, GitHub pages, readthedocs.org, something else?

The best would be to overhaul/replace https:///guide.macports.org with
something new and better structure.

The existing guide can be found here:
https://trac.macports.org/browser/trunk/doc-new

Hosting the site should be the least concern, we have resources for that
now.

> - In what format should the documentation be written: HTML, Markdown,
>  TeX, whatever? I prefer Markdown.

I think one of the main reasons why nobody likes updating the guide is
the DocBook XML syntax.

Back in 2009 (sic!), I started the new help system in AsciiDoc, inspired
by the git help system. AsciiDoc is more complex than Markdown, but
supports syntax elements such as includes and macros, that are very
helpful in reusing the some content in multiple pages and keeping the
layout consistent. Also, macros can be defined per output device,
expanding to specific syntax in roff/html/pdf/etc.

I am fine with using Markdown, as it is the dominant markup syntax
today. However, it is also very limited, but that might just be enough
for the guide.

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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

On 2016-10-07 19:07, Marcel Bischoff wrote:
> On 16/10/07, Ryan Schmidt wrote:
>> The problem is: somebody needs to do the correct work to update each of
>> those ports to the latest version. In many cases, tickets are already
>> filed, and you can look them up to see what the current status is; if
>> you don't find a ticket, please file a new one. In some cases, such as
>> boost, pandoc, ghc, there are serious issues preventing the update. If
>> Homebrew has solved those problems, great, maybe we can crib from them.
> 
> Again, I was under the impression that to be a port maintainer you would
> actually need to maintain the port. In this case, checking out what
> Homebrew is doing and trying to implement it the MacPort way. As this
> does not appear to be the case, I guess when things are broken, they are
> just considered being broken.

Anybody can get listed as maintainer, making the promise to do that.
However, when they are not actually keeping it up-to-date, there is
little we can do about it. After following the port abandonment policy,
will will drop the port back to "nomaintainer", leaving you in the same
situation.

> I don't see any concrete discussion as to why certain ports would not
> build, nor any kind of coordination between different port maintainers.
> This may very well be my fault due to selective perception on my part.
> I'm just a bit confised as to why one project can figure it out while
> another lags months or years behind in certain areas.

As soon as I figure out why a port does not build, I might just commit a
fix instead of writing lengthy discussions on that. :-)

> I'll be sure to devote some time to help solve long-standing issues. The
> proper mailing list to discuss those issues is this one I presume?

Yes, definitely. Comments on commits will be discussed here as well as
discussions originally started at tickets that will require more help
from others.

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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

On 2016-10-07 20:58, Christopher Jones wrote:
> 
>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez 
>> wrote:
>> 
>>> On Oct 7, 2016, at 2:09 PM, Chris Jones
>>>  wrote:
>>> 
>>> Currently, once they find out about svn, and trac
>> 
>> We will still use Trac for issue tracking, although I believe
>> someone is looking into integrating GitHub sign in.

Trac will stay. Clemens and I already wrote new modules for the
trac-github plugin [1] in order to allow both login with GitHub as main
authentication provider, migrating old tickets from mail addresses to
the GitHub accounts and all permissions in Trac will be based on team
memberships on GitHub.

The only downside is that references to tickets will have to become full
URLs to Trac, because GitHub claims the #12345 syntax for their own
issue tracker and pull requests. Commits which contain such an URL will
automatically be linked from the corresponding ticket.

> Personally I think we have to migrate away from trac as well. Pull
> requests in GitHub will largely replace what happens in trac for
> submission of patches and the discussion of them. If we stick with
> trac for issues then for me it will be an utter mess.

Pull requests can be used in addition to tickets. For simple port
updates, there will be no need to open a ticket.

We evaluated several options, including issue trackers provided by
GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the
conclusion that Trac is still the best option at hand.

Especially with hosting our own installation, we will finally be able to
make more modifications and use custom plugins, that we never got
deployed at Mac OS Forge (for example [2]).

Rainer

[1] https://github.com/trac-hacks/trac-github
[2] https://trac.macports.org/ticket/40987
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

On 2016-10-07 19:00, Brandon Allbery wrote:
> On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones  > wrote:
>
> Indeed, I was a little dubious of the suggestions that involve
> -force. I suspect there are better ways of working that should avoid
> the need for that.
> 
> 
> --force only comes into it when you are rewriting history (i.e. merging
> existing commits that were already sent upstream). Best is to not do
> this; work in a branch, combine commits after, and cherrypick those to
> *another* clean branch (or diff the first branch to get all changes as
> one patch, and apply it in the new branch to get a single commit).

It would not be helpful to keep all commits from a pull request that
took multiple iterations, that just adds clutter in the history and in
the blame output.

If you want to replace the commits in a pull request, it will require a
'git push --force' to the branch of the pull request. There is no way
around it, except closing the pull request and submitting it as a new
pull request, which breaks the connection to the previous discussion.

> Or just accept multiple commits instead of trying to pretend to be a neat
> freak after hosting a wild party.

If the pull request just had a few fixups after the initial commit, that
would be solved by squash merging everything into a single commit on the
merge.

However, a squash merge should not be used when multiple logical
separated commits were submitted in a pull request (for example separate
whitespace changes).

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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

On 2016-10-07 18:25, Ken Cunningham wrote:
> The current "port update" ticket queue I find to be a rather
> unpredictable mixture of requests of port updates, requests for new
> ports, announcements that somebody has noticed a version update has
> come available, and finished port updates awaiting approval by
> committers. I don’t mind picking off a few of these and updating
> them, or building some new ones, but it’s a bit of a tangle
> sometimes.
> 
> Like this ticket: https://trac.macports.org/ticket/52538
> 
> I think this ticket represents someone noticing there’s a new version
> available, and requesting the existing port be updated. But that
> should be in a different lineup, IMHO.

We are currently using the type field with "defect", "enhancement",
"update", "submission", "request". A ticket should be filed with the
appropriate type.

To indicate a patch is attached to the ticket, we add the "haspatch"
keyword. Additionally the "maintainer" keyword can be added to express
the update needs no thorough review as it comes directly from the
maintainer.

https://trac.macports.org/wiki/Tickets#Keywords

I am not sure how we could change these to make triaging trickets easier.

> And there are "requests for ports" ( I think this means new requests
> for ports that don’t presently exist, mostly) that go back 11 years.
> Port submissions that go back the same length of time. Possibly some
> kind of massive clean-out of the old, dead, never-will-be-touched
> stuff might need to happen.

Requests for new ports could still be valid after years. This list could
be helpful for newcomers that want to create new ports. The number of
people in CC in such a ticket could also be an indicator of its importance.

A few years back, I began adding a keyword "lack-of-interest" to tickets
that where open for a long time without response on questions. When the
reporter does no longer seem to want it or there is nobody else who
steps up to do it, just closed these tickets.

Maybe there would be a better approach that can become a real policy to
avoid so much old cruft in the tickets.

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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

Hello Marcel,

On 2016-10-06 19:12, Marcel Bischoff wrote:
> I was advised that I should ask my questions and raise my issues here.
> 
> I'm currently considering dropping the use of MacPorts altogether as
> this projects' track record regarding critical updates of major software
> tools is rather underwhelming. Furthermore, I'm asking myself what use
> it is to have appointed port maintainers when numerous updates are not
> included in a timely manner.

Thank you for coming here to discuss your issues instead of merely
turning your back on the project and leaving silently.

> Just today I commented on a ticket that is six weeks old, about an
> update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
> 4.6.0 on 27-Sep-2016. Version 4 is considered the stable LTS variant,
> only fixing security issues without introducing new features. This makes
> timely updates all the more important. If installing software by hand
> results in more current and more secure software for my development
> machine, I don't get the point of using MacPorts in the first place.

Our ports do have maintainers, which are people who expressed interest
in a port and are interested in keeping them up-to-date. This is meant
to assign issues with ports to certain people that care about this port
and would have the most knowledge how to fix it.

However, we also have a maintainer timeout policy [1] by which updates
to ports can be committed by any project member after 72 hours of
submission if the maintainer does not show any reaction. In case a port
is in a broken state (does not compile at all, typo, etc.) or
vulnerabilities require a security patch, any project member can
immediately commit an update.

In this particular case [2], a ticket was filed with an update request,
but no patch was attached. With a patch, it would be much easier to
verify that the build still works and then commit the update.

The backlog of patches already approved by the maintainer is not that
long [3] right now. Those still in the queue often already went through
review, but issues with the update were found that need to be addressed.

If you think a contribution has stalled, ping the macports-dev list
about it and request a review. This has proved to work quite well in
recent time.

> It pains me to say that Homebrew is running circles around MacPorts in
> the department of current available packages.
> 
> If time and manpower is the problem, wouldn't it be better to move to a
> GitHub-based approach like Homebrew does? This way far more people would
> contribute. It would lower the bar to contributing significantly. I like
> MacPorts' clean implementation far more than Homebrews'. But if I still
> cannot install (for example) pandoc because ghc still requires llwm-3.5
> which does not compile on Sierra: what choice do I have? I need to get
> stuff done, not tinker with the infrastructure of my working environment
> for hours on end, just to get it to work. A package manager's sole
> reason for being is to make the routine task of installing software and
> updates easier, more reliable and trustworthy.

After all, MacPorts maintainers are just some people devoting their free
time to writing Portfiles. Sometimes other stuff in life stops them from
responding to tickets or addressing certain issues.

I can understand your frustration about broken ports and missing
updates. I have that as well.

If your work depends on these ports, you benefit from the donation of
time from the people keeping the port up-to-date. The best you can do if
you encounter a problem is to check if it is a known issue in our Trac.
Sometimes others already proposed a solution but did not have the time
to get through with updating the Portfile in multiple iterations testing
the change. Yes, this is a time-consuming process, but others would
benefit from your work as well as you benefit form theirs.

Just switching to GitHub would not change the way port updates are put
together. In my experience, preparing the patch and attaching it to a
ticket is only a small fraction of what needs to be done for a port
update. You will still need to update the Portfile, test the build, etc.

> The way it is now, I repeatedly find myself in need to modify the
> Portfiles manually, test, check, test again and so on. Or I simply run
> `brew install pandoc` and — be done. Plus, doing all that manual diffing
> where just a minor mistake will frustrate me and requires me to attach a
> completely new diff file quite honestly keeps me from contributing
> regularly. In 2016 this feels like pulling teeth, not satisfaction or a
> sense of accomplishment that should accompany working together on free
> software.

Even as a non-committer you can easily work from a Subversion checkout
with local modifications and create the patch from there. Or you keep a
separate local ports tree that you diff against.

Where exactly do you see the benefit of Git/GitHub for this? I am
honestly interested in this for 

Re: Working with Git

[Rainer Müller]

On 2016-10-06 09:33, Sterling Smith wrote:
> On Oct 5, 2016, at 7:53PM, Ryan Schmidt  wrote:
> 
>> Suppose a user submits an update to a port.
>>
>> With Subversion, the user would submit a patch in a Trac ticket. To test it, 
>> I would download the patch and apply it to my local Subversion working copy. 
>> If I like it, I commit it. If I don't like it, I give feedback to the user 
>> in the ticket, or I edit the Portfile further and commit it, then tell the 
>> user in the ticket what changes I made.
>>
>> How will this work on GitHub?
>>
>> The user will submit a pull request. How do I test it locally?
> You test their changes by checking out their branch on your system.  Most 
> likely they are on their own fork, and you will need to add their fork as a 
> new remote
> 
> git remote add  
> 
> before checking out their branch by issuing
> 
> git checkout   # Note that this can fail if more than one remote has 
> the same branch name (such as master...), and there is a more verbose way to 
> indicate from where to check out the branch

You will not need a new remote for this as GitHub will store a copy of
the branch submitted in the pull request in our repository.

Check the GitHub documentation here:

https://help.github.com/articles/checking-out-pull-requests-locally/#modifying-an-inactive-pull-request-locally


You can also use the hub [1] wrapper around git to make such things
easier. This tool implies all repository URLs will point to GitHub. For
example, the command
  hub remote add raimue/ports
would add a new remote named "raimue" with the URL for this repository
on GitHub.

Even better, many commands will just accept references to commits or
pull requests on GitHub. For example, you can directly switch to a local
checkout of a pull request with a single command:
  hub checkout https://github.com/macports/ports/pull/42
Also works similarly with 'hub cherry-pick' or 'hub am'.

Although I do not like their proposal to alias git to hub, as I like to
keep control what extensions I use with git. I prefer to explicitly call
hub when I want to work with GitHub.

Rainer

[1] https://hub.github.com/ ; 'sudo port install hub'
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Rainer Müller]

On 2016-10-06 10:22, Ryan Schmidt wrote:
> On Oct 6, 2016, at 02:33, Sterling Smith 
> wrote:
>> When is the macports repo on GitHub supposed to appear?
> 
> I have no ETA for you yet. "When it's ready." Part of being ready
> includes having documentation about how we'll perform the tasks we
> need to perform on GitHub, so people who know how to do that should
> definitely contribute to the documentation, and people should ask
> questions about things that aren't explained in the documentation.

While I agree we need some basic rules, I do not think we need to make
the instructions too complex. Nobody is going to read them anymore when
they get too long.

We should have an idea how we want to work, but we cannot anticipate
everything. MacPorts has always formed its policies and workflows by
learning how maintainers do their work. I think we should continue the
process that way.

There will always be problems with the transition to GitHub that can be
discussed on the mailing list to find a common solution. Then it can be
documented to point people to that if they have the same problem.

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

Re: Working with Git

[Rainer Müller]

On 2016-10-06 14:28, Ryan Schmidt wrote:
> If there are easy ways to rewrite the history of a pull request, by all 
> means, let's suggest the user do that, and provide instructions for how to do 
> so. I have no idea how to do it.

You can rewrite the source branch of a pull request in any way you want.
You can use 'git commit --amend' to add something to the last commit, or
you can do a 'git rebase -i' to change specific commits further down in
the history in any way you want.

After doing such changes to the branch history, git would reject a
normal push to the branch as it not only appends new commits at the top
of the branch. Therefore this will require a 'git push --force' to make
the branch look exactly like the reworked version.

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

Re: order of operations in port upgrade

[Rainer Müller]

On 2016-10-06 00:14, Brandon Allbery wrote:
> On Wed, Oct 5, 2016 at 5:41 PM, Rainer Müller <rai...@macports.org
> <mailto:rai...@macports.org>> wrote:
> 
> On 2016-10-05 11:09, René J.V. Bertin wrote:
> > Quick question: a normal (non-forced) upgrade currently does
> >
> > 1) install (create new tarball image)
> > 2) deactivate old
> > 3) activate new
> > 4) clean ${workpath} (unless -k)
> 
> Cannot reproduce. The clean target will already be run after step 1) and
> remove the work directory.
> 
> 
> 1 is the destroot phase of a "port upgrade", not a separate command 

Yes, the clean target is run after executing the install target (without
activate) during the upgrade procedure.

It can clearly be seen in the output. For testing, just increase the
revision in a port and run an upgrade:

$ sudo port upgrade less
--->  Computing dependencies for less
...
--->  Building less
--->  Staging less into destroot
--->  Installing less @481_999+pcre
--->  Cleaning less
--->  Computing dependencies for less
--->  Deactivating less @481_0+pcre
--->  Cleaning less
--->  Activating less @481_999+pcre
--->  Cleaning less
...

You will see additional cleaning after deactivate/activate. This is for
the Portfile stored in the registry and is unrelated to the work
directory used for building and destroot.

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

Re: order of operations in port upgrade

[Rainer Müller]

On 2016-10-05 11:09, René J.V. Bertin wrote:
> Quick question: a normal (non-forced) upgrade currently does
> 
> 1) install (create new tarball image)
> 2) deactivate old
> 3) activate new
> 4) clean ${workpath} (unless -k)

Cannot reproduce. The clean target will already be run after step 1) and
remove the work directory.

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

Patch naming policy (was: Re: [153574] trunk/dports/sysutils/skey)

[Rainer Müller]

On 2016-10-05 01:45, Ryan Schmidt wrote:
>> Patches should follow the patch-*.diff naming scheme, so this
>> should be named patch-skeyprune-man8.diff or similar.
>> 
>> https://guide.macports.org/#development.patches.source
> 
> Popular opinion seems to be that we should relax that restriction.
> 
> I think it's reasonable if we change it to "patch-*.diff or
> *.patch".
> 
> My primary gripe was with the way patches used to be named
> "patch-foo" or "patch-foo.c" which caused editors to use incorrect
> syntax highlighting. As long as we use a .diff or .patch extension,
> to indicate to a syntax highlighter that this is a diff or patch
> file, that should be fine.

The initial patch-* policy was adopted from FreeBSD ports. The filename
extension .diff was added later for this reason.

If we want to change the patch naming policy, should we allow both
*.diff and *.patch or would one file extension be better to avoid
configuring editors twice?

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

Re: [153574] trunk/dports/sysutils/skey

[Rainer Müller]

On 2016-10-04 22:03, lar...@macports.org wrote:
> Revision: 153574
>   https://trac.macports.org/changeset/153574
> Author:   lar...@macports.org
> Date: 2016-10-04 13:03:08 -0700 (Tue, 04 Oct 2016)
> Log Message:
> ---
> skey: Rename patch
> 
> Modified Paths:
> --
> trunk/dports/sysutils/skey/Portfile
> 
> Added Paths:
> ---
> trunk/dports/sysutils/skey/files/install-skeyprune.8.patch
> 
> Removed Paths:
> -
> trunk/dports/sysutils/skey/files/patch-Makefile.in.diff
> 
> Modified: trunk/dports/sysutils/skey/Portfile
> ===
> --- trunk/dports/sysutils/skey/Portfile   2016-10-04 20:00:00 UTC (rev 
> 153573)
> +++ trunk/dports/sysutils/skey/Portfile   2016-10-04 20:03:08 UTC (rev 
> 153574)
> @@ -25,6 +25,6 @@
>  sha1d55fb286098900cdf3eb6b174a720a06c722312a \
>  rmd160  33d97cbcd6dbc91bdca5b27056d51d1f5d06b68d
>  
> -patchfiles  patch-Makefile.in.diff
> +patchfiles  install-skeyprune.8.patch
>  
>  configure.args  --mandir=${prefix}/share/man

Patches should follow the patch-*.diff naming scheme, so this should be
named patch-skeyprune-man8.diff or similar.

https://guide.macports.org/#development.patches.source

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

Re: I'm a newbie mantainer and I'm confused about the buildbot

[Rainer Müller]

On 2016-09-30 00:09, Brandon Allbery wrote:
> On Thu, Sep 29, 2016 at 4:28 PM, Daniel J. Luke  > wrote:
> 
> On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez  > wrote:
> > Our blanket policy is to support the three most recent major OS
> > versions.
> 
> unless policy has actually changed (and I somehow missed it), the
> policy is current release and one previous.
> [and if anything, the policy should be further restricted to only
> include OS releases still supported by Apple - ie those actively
> getting security updates]
> 
> 
> The policy changed, and it did so because Apple changed its policy to
> that as of 10.10. So with 10.12 out Apple is providing security updates
> for 10.10 and up only (unless I missed them changing it again).

I am not aware Apple has any public security policy.

Security updates just seem to happen when they want to. For example,
macOS 10.12 Sierra is the recommended update to fix security bugs
discovered and left vulnerable in OS X 10.11 El Capitan:

https://support.apple.com/en-us/HT207170


When Apple switched to yearly releases, consensus in discussions was to
support the last three releases of the Mac operating system. Anything
older are legacy systems, for which we try to provide a working base and
accept patches for ports. If something is broken on these older
releases, maintainers should not invest their time to get it fixed -
unless they have personal interest, in which case we cannot stop them
anyway.

The only indicator of this policy seems to be our downloads page, which
at the moment still lists OS X 10.9 Mavericks as non-legacy. I would
move that to legacy once macOS 10.12 Sierra has been out for at least a
month.

https://www.macports.org/install.php

Rainer
___
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: No Xcode 8 CLT for El Capitan

[Rainer Müller]

On 2016-09-21 21:15, Adam Dershowitz wrote:
> That comment does not make it at all clear what those of us who updated to 
> Xcode 8 (but not beta!) but are still on OS X 10.11 are supposed to do. 
> I have posted a ticket about building cmake that seems to be because it is 
> trying to use 10.12 SDK, but it is not clear how to work around that.

That would be normal. The latest SDK can be used on previous systems.
For example, on OS X 10.10 Yosemite, Xcode 7.2 also only ships the 10.11
SDK.

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

Re: github desktop's request to install command line tools, and macports git command line tools ...

[Rainer Müller]

On 2016-09-18 19:39, Ken Cunningham wrote:
> Github desktop seems a useful tool — but it wants to install command
> line tools (specifically mentioning github utility and git-lfs) into
> /usr/local/bin.
> 
> right now, I’m set up with 
> 
> /opt/local/bin/git
> 
> and I see there already is a port git-lfs versioned 1.4.1
> 
> It’s just these kinds of things that gets things messed up sometimes.
> 
> Anyone been down this path? Could always install the desktop’s tools and
> then hide them I suppose ...

The operations in GitHub.app will always use their own tools and they
also bundle their own version of git. Although I don't know if this will
be symlinked on older releases of OS X.

If your PATH lists /opt/local/bin before /usr/local/bin (which is the
default configuration), git-lfs from the port will already take preference.

There is nothing to worry about here, as the git file format is meant to
be stable and you should be able to work with any version of git on the
same local repository.

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

python's LINKFORSHARED

[Rainer Müller]

Hello pythonXY maintainers,

in python27, the LINKFORSHARED config variable is broken:

$ python2.7 -c "import distutils.sysconfig; \
  conf = distutils.sysconfig.get_config_var; \
  print (conf('LINKFORSHARED'))"
-u _PyMac_Error Python.framework/Versions/2.7/Python

This value cannot be used for linking. However, this is the exact
command that is used in the current macros in ax_python_devel.m4 from
autoconf-archive [1]. With this value, linking a test program with
python27 will always fail.

All other python ports (really all of python24-26 and python31-36,
except python27) fix the LINKFORSHARED variable with a reinplace in
post-destroot. The very same reinplace existed in the python27 port, but
was removed in r108762:

  * remove non-working attempt to change LINKFORSHARED. Any dependents
  relying on this are broken anyway and should  be fixed to get the
  required info from python2.7-config (#39223)

https://trac.macports.org/changeset/108762
https://trac.macports.org/ticket/39223

I don't know what the correct solution would be, but either all python
ports should use the same approach (and have a broken LINKFORSHARED), or
python27 should also do what apparently works for the other ports.

This issue complicates writing ports with +pythonXY variants, as
+python27 needs to be special.

If LINKFORSHARED should really not be used, I would suggest to submit a
patch to autoconf-archive to get it fixed upstream instead of applying
workarounds in individual ports.

Rainer

[1]
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_python_devel.m4;hb=35f52877a6c1c8568575c2456fb1004e92839a82
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152743] trunk/dports/_resources/port1.0/group

[Rainer Müller]

On 2016-09-16 17:33, Ryan Schmidt wrote:
> 
>> On Sep 16, 2016, at 9:06 AM, Rainer Müller <rai...@macports.org> wrote:
>>
>> I would keep this as Mac OS X 10.5 Leopard, the name does not change
>> retroactively.
> 
> I suppose that's an open question. Previously, I've tried to use the OS 
> marketing name as it was when that OS version was released. Now, I'm thinking 
> we should always use the current marketing name. Do we have any guidance from 
> Apple on what they want people to do?
> 
>> The version number is usually also helpful to get the
>> "10.X" to "darwin Y" mapping right.
> 
> Yes but I didn't want to go into a long explanation in that comment.

Then let's just replace it here with "(e.g. 16 for macOS 10.12 Sierra)"
to avoid the confusion.

>>> options minimum_xcodeversions
>>> @@ -57,7 +57,7 @@
>>> return -code error "unable to find Xcode"
>>> }
>>> if {[vercmp ${xcodeversion} ${minimum_xcodeversion}] < 0} {
>>> -ui_error "On Mac OS X ${macosx_version}, ${name} 
>>> ${version} requires Xcode ${minimum_xcodeversion} or later but you have 
>>> Xcode ${xcodeversion}."
>>> +ui_error "On macOS ${macosx_version}, ${name} 
>>> @${version} requires Xcode ${minimum_xcodeversion} or later but you have 
>>> Xcode ${xcodeversion}."
>>
>> Why drop the foo @1.0 syntax that we use at so many other places to
>> specify a port version?
> 
> I didn't drop it; I started using it, finally, in this portgroup.

Sorry, somehow I misread that in reverse... I blame Friday :-)

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

Re: [152743] trunk/dports/_resources/port1.0/group

[Rainer Müller]

On 2016-09-16 01:09, ryandes...@macports.org wrote:
> Revision: 152743
>   https://trac.macports.org/changeset/152743
> Author:   ryandes...@macports.org
> Date: 2016-09-15 16:09:26 -0700 (Thu, 15 Sep 2016)
> Log Message:
> ---
> Portgroups: replace "Mac OS X" and "OS X" with "macOS"

> Modified: trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
> ===
> --- trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
> 2016-09-15 23:06:35 UTC (rev 152742)
> +++ trunk/dports/_resources/port1.0/group/xcodeversion-1.0.tcl
> 2016-09-15 23:09:26 UTC (rev 152743)
> @@ -38,7 +38,7 @@
>  #   minimum_xcodeversions   {darwin_major minimum_xcodeversion}
>  #
>  # where darwin_major is the major version of the underlying Darwin OS (e.g. 9
> -# for Mac OS X 10.5 Leopard) and minimum_xcodeversion is the minimum version
> +# for macOS Leopard) and minimum_xcodeversion is the minimum version
>  # of Xcode the port requires (e.g. 3.1).

I would keep this as Mac OS X 10.5 Leopard, the name does not change
retroactively. The version number is usually also helpful to get the
"10.X" to "darwin Y" mapping right.

>  options minimum_xcodeversions
> @@ -57,7 +57,7 @@
>  return -code error "unable to find Xcode"
>  }
>  if {[vercmp ${xcodeversion} ${minimum_xcodeversion}] < 0} {
> -ui_error "On Mac OS X ${macosx_version}, ${name} 
> ${version} requires Xcode ${minimum_xcodeversion} or later but you have Xcode 
> ${xcodeversion}."
> +ui_error "On macOS ${macosx_version}, ${name} 
> @${version} requires Xcode ${minimum_xcodeversion} or later but you have 
> Xcode ${xcodeversion}."

Why drop the foo @1.0 syntax that we use at so many other places to
specify a port version?

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

Re: Could not open Portfile

[Rainer Müller]

On 2016-09-16 14:20, Craig Treleaven wrote:
> I’ve hit this scenario a couple of times.  Am I doing something wrong with 
> svn patch?

What is your umask set to? From the permissions it looks like this is
with umask 0077.

I encountered the same problem before. svn patch does not preserve the
permissions of the existing files. Actually this behavior is not even
specific to svn patch, other commands such as svn revert behave the same
way. svn creates a new temporary file with umask applied, deletes the
existing file and moves the new file in place.

Personally, I use ACLs on my ports directory to automatically grant read
permissions to everyone on new files. This also resolves this problem
with svn patch for me.

chmod -R +a "group:everyone allow
read,execute,list,search,file_inherit,directory_inherit" ~/ports

It would be nice to have a better solution for this problem, but the
actual bug is in Subversion.

Rainer
___
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: lldb ...

[Rainer Müller]

On 2016-09-16 10:18, Jeremy Huddleston Sequoia wrote:
> Yeah, this contradicts what I'm seeing as expected.  Given that
> you've signed /opt/local/bin/ggdb with an entitlement, it should be
> CS_RESTRICT which should imply CS_HARD.  The lack of a code signature
> would trigger !CS_VALID which would prevent the process from loading
> the unsigned libraries.

There is actually no entitlement data in the code-signature itself.
The access is granted by embedding a Info.plist into the binary:

$ otool -P /opt/local/bin/ggdb
/opt/local/bin/ggdb:
(__TEXT,__info_plist) section

http://www.apple.com/DTDs/PropertyList-1.0.dtd;>


  CFBundleIdentifier
  org.gnu.gdb
  CFBundleName
  gdb
  CFBundleVersion
  1.0
  SecTaskAccess
  
allowed
debug
  



Probably that is why these rules are not enforced?

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

Re: [152630] contrib/buildbot-test

[Rainer Müller]

On 2016-09-14 21:15, Ryan Schmidt wrote:
> The master uses MacPorts in /opt/local for its own software (nginx, buildbot, 
> rsync, etc.). I can manually install anything else there that we need. It's 
> probably not best to automate selfupdating that MacPorts install, but it can 
> have its own install in another prefix that it selfupdates. Giving the 
> buildbot user sudoers access to that port command seems fine.

Currently the only job that would require software would be the
generation of the guide with the ports: docbook-xsl docbook-xml libxslt

For www, we could add a syntax check of the PHP files to avoid deploying
anything obviously broken.

Later I have plans to also add a job for generating HTML versions of the
new man pages (requires asciidoc) and maybe another one for the Doxygen
documentation of base (requires doxygen).

The need for additional ports would usually only arise when we add a new
builder to master.cfg, which also needs to be deployed by you anyway.
The more I think about it, I come to the conclusion that we probably do
not even need that automation and could just keep a list of ports that
should be installed on this worker next to master.cfg.

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

Re: [152630] contrib/buildbot-test

[Rainer Müller]

On 2016-09-14 16:10, Ryan Schmidt wrote:
>> +"deploy": {
>> +"www": {
>> +"host": "",
>> +"user": "",
>> +"sshkeyfile": "",
>> +"sshknownhostsfile": "ssh_known_hosts",
>> +"destpath": ""
>> +},
>> +"guide": {
>> +"host": "",
>> +"user": "",
>> +"sshkeyfile": "",
>> +"sshknownhostsfile": "ssh_known_hosts",
>> +"destpath": ""
>> +}
>> +}
>>
>>  }
> 
> I had to remove these lines when deploying because I don't have a "docs" 
> worker set up yet.
>
> Configuration Errors:
>   builder 'docs-www' uses unknown slaves 'docs'
>   builder 'docs-guide' uses unknown slaves 'docs'

Yes, that is the right solution. The previous logic based it on the
existence of the "docs" worker, now it is controlled by the entries in
the "deploy" dict.

> This worker will run on the same server as the master. We have other tasks we 
> need to run on the master as well: mirroring distfiles on port changes; 
> copying ports to the rsync server on port changes; creating ports.tar on port 
> changes; creating base.tar on base changes. Will these builders use the same 
> worker? If so, what name could we pick (not "docs") that would be 
> sufficiently all-encompassing?

Yes, I would put all of these tasks on the same set of workers
(let's start with just one, but if we ever get too many of these tasks,
we could add more for load balancing).

I agree this will be more than just documentation. Maybe give it a very
generic name such as "jobs"?

This worker would need the required software installed, preferably from
ports. If we want to automate port install/upgrade, we would have to run
the worker as root and drop privileges with sudo/su for the actual jobs.
An alternative solution would be to provide an existing port install and
only run 'sudo port ...' with sudoers allowing the user to run this
command without password.

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

Re: RFC: mp-buildbot failcache

[Rainer Müller]

On 2016-09-12 14:41, Clemens Lang wrote:
> here's a patch against mp-buildbot that would add a fail cache for use
> on the buildbots. Unfortunately I don't have a test setup yet, so I'm
> hesitating to commit this immediately. I'd welcome feedback, a code
> review, or testing by somebody with a working builbot setup.
> 
> Basically, I'm keeping failcache per tuple of (portname, canonical
> variants, checksum) where
>  - I need one additional call to a custom port client to dump the
>canonical variants
>  - calculate the checksum as
>sha256(sort(sha256(Portfile), sha256(files/*)))
>which will make the buildbots re-try a dependency if, for example, a
>maintainer forgot to commit a patch file

Should the PortGroups be included in this hash as well?

We should put the buildername/buildnumber/URL of the failing build into
the failcache to be reported back on a match. The current output would
not be helpful to find the reason why it failed. I added this
information to the build environment [1].

During setup for a quick test I made a small mistake with the new files.
This failure in execution of tools/canonical_variants.tcl should not
have been a success. The return code of failcache_failure/success was
not handled. I also added a missing mkdir and fixed the reversed logic
in failcache_test and another classic bash problem [2].

Now this works for me. To save bandwidth, I am only attaching my changes
on top of your patch.

Rainer

[1] https://trac.macports.org/changeset/152554
[2] http://mywiki.wooledge.org/BashFAQ/024
diff -u functions functions
--- functions   (working copy)
+++ functions   (working copy)
@@ -83,8 +83,8 @@
 ## Test whether a given port with variants has previously failed.
 #
 # Valid arguments are a port name, optionally followed by a variant
-# specification. Succeeds if the port did not previsouly fail to build, fails
-# if the port is known to fail.
+# specification. Succeeds if the port did not previously fail to build,
+# fails if the port is known to fail.
 failcache_test() {
 local key
 key=$(failcache_key "$@")
@@ -93,7 +93,7 @@
 return 1
 fi
 
-test -f "${option_failcache_dir}/${key}"
+test ! -f "${option_failcache_dir}/${key}"
 }
 
 ## Mark a build of a given port with variants as successful.
@@ -125,4 +125,6 @@
 fi
 
+mkdir -p "${option_failcache_dir}"
+
 touch "${option_failcache_dir}/${key}"
 }
diff -u mpbb-install-dependencies mpbb-install-dependencies
--- mpbb-install-dependencies   (working copy)
+++ mpbb-install-dependencies   (working copy)
@@ -76,7 +76,8 @@
 echo >> "$log_status_dependencies"
 
 # Check whether any of the dependencies have previously failed
-echo "$dependencies" | while read -r dependency; do
+failcachecounter=0
+while read -r dependency; do
 # Split portname +variant1+variant2 into portname and variants, where
 # the variants are optional.
 depname=${dependency%% *}
@@ -89,9 +90,14 @@
 echo "$text" >&2
 echo "$text" >> "$log_status_dependencies"
 echo "Building '$port' ... [ERROR] (failed to install dependency 
'${depname}') maintainers: $(get-maintainers "$port" "${depname}")." >> 
"$log_subports_progress"
-return 1
+failcachecounter=$((failcachecounter + 1))
 fi
-done
+done < <(echo "$dependencies")
+
+if [ $failcachecounter != 0 ]; then
+echo "Aborting build due to $failcachecounter previously failed 
dependencies." >&2
+return 1
+fi
 
 echo "$dependencies" | while read -r dependency; do
 # Split portname +variant1+variant2 into portname and variants, where
@@ -113,6 +119,10 @@
 # $depvariants isn't quoted on purpose
 # shellcheck disable=SC2086
 failcache_failure "$depname" $depvariants
+if [ $? -ne 0 ]; then
+err "failcache_failure failed."
+return 1
+fi
 return 1
 else
 echo "[OK]" >> "$log_status_dependencies"
@@ -120,6 +130,10 @@
 # $depvariants isn't quoted on purpose
 # shellcheck disable=SC2086
 failcache_success "$depname" $depvariants
+if [ $? -ne 0 ]; then
+err "failcache_success failed."
+return 1
+fi
 dependencies_counter=$((dependencies_counter + 1))
 fi
 done
diff -u mpbb-install-port mpbb-install-port
--- mpbb-install-port   (working copy)
+++ mpbb-install-port   (working copy)
@@ -58,12 +58,20 @@
 if "${option_prefix}/bin/port" -dk install "$@"; then
 # Remove failcache if it exists
 failcache_success "$@"
+if [ $? -ne 0 ]; then
+err "failcache_success failed."
+return 1
+fi
 else
 echo "Build of '$port' failed."
 # log: summary for the portwatcher
 echo "Building '$port' ... [ERROR] maintainers: 

Re: [152490] contrib/buildbot-test

[Rainer Müller]

On 2016-09-12 04:17, Ryan Schmidt wrote:
> {
> "workers": {
> "10.5_ppc": {
> "base": ""
> },
> "10.5_ppc_legacy": {
> "ports": ""
> },
> "10.6_x86_64": {
> "base": "",
> "ports": ""
> },
> "10.6_x86_64_legacy": {
> "ports": ""
> },
> "10.6_i386": {
> "ports": ""
> },
> "10.6_i386_legacy": {
> "ports": ""
> },
> "10.7_x86_64": {
> "base": "",
> "ports": ""
> },
> "10.7_x86_64_legacy": {
> "ports": ""
> },
> "10.8_x86_64": {
> "base": "",
> "ports": ""
> },
> "10.8_x86_64_legacy": {
> "ports": ""
> },
> "10.9_x86_64": {
> "base": "",
> "ports": ""
> },
> "10.10_x86_64": {
> "base": "",
> "ports": ""
> },
> "10.11_x86_64": {
> "base": "",
> "ports": ""
> },
> "10.12_x86_64": {
> "base": "",
> "ports": ""
> },
> "master": {
> "docs-guide": "",
> "docs-www": ""
> }
> }
> }
> 
> 
> 
> There are currently too many places in master.cfg that have knowledge of 
> which worker runs on which platform. I'd like to get all of that information 
> confined to the config file.

This list would be based on OS X installations, not on the function the
buildslaves serve. Maybe we should split the list of builders between
those tied to a machine and those that could run anywhere?

My intention was that the builders "docs-guide" and "docs-www" can use
the same slave. I do not see a need to use separate buildslave instances
for them. That will make it easier to just add new builders for more
tasks (for example portindex2sql or generating a web version of our port
help/man pages).

The configuration for "ports" has become special, as we make the
assumption of a 1:1 mapping between builders and buildslaves.

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

Re: [152507] contrib/mp-buildbot/mpbb-cleanup

[Rainer Müller]

On 2016-09-12 10:41, Clemens Lang wrote:
> On Sun, Sep 11, 2016 at 11:47:58AM -0700, rai...@macports.org wrote:
>> Revision: 152507
>>   https://trac.macports.org/changeset/152507
>> Author:   rai...@macports.org
>> Date: 2016-09-11 11:47:58 -0700 (Sun, 11 Sep 2016)
>> Log Message:
>> ---
>> buildbot: skip cleanup if port is not installed
>> [...]
>> Modified: contrib/mp-buildbot/mpbb-cleanup
>> ===
>> --- contrib/mp-buildbot/mpbb-cleanup 2016-09-11 18:41:15 UTC (rev 152506)
>> +++ contrib/mp-buildbot/mpbb-cleanup 2016-09-11 18:47:58 UTC (rev 152507)
>> @@ -10,6 +10,15 @@
>>  }
>>  
>>  cleanup() {
>> +# if this is the very first build, selfupdate did not install port yet
>> +# $option_prefix is set by mpbb
>> +# shellcheck disable=SC2154
>> +if [ ! -e "${option_prefix}/bin/port" ]; then
>> +echo "---> Skipping cleanup"
>> +echo "port not installed at ${option_prefix}/bin/port"
>> +return
>> +fi
>> +
>>  echo "> Deactivating ports"
>>  # $option_prefix is set by mpbb
>>  # shellcheck disable=SC2154
> 
> If $prefix/bin/port does not exist, $prefix/bin/port-tclsh will not
> exist either, and the invocation of "tools/uninstall-old-ports.tcl"
> below will fail as well.

The 'return' just skips everything else in this step, so that would be
covered.

Another solution would be to run selfupdate before the cleanup step to
ensure we always cleanup with a working port command. Although such a
situation should only happen when the slaveprefix was deleted manually.

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

Re: [152490] contrib/buildbot-test

[Rainer Müller]

On 2016-09-11 14:34, rai...@macports.org wrote:
> Revision: 152490
>   https://trac.macports.org/changeset/152490
> Author:   rai...@macports.org
> Date: 2016-09-11 05:34:55 -0700 (Sun, 11 Sep 2016)
> Log Message:
> ---
> buildbot: move build platforms to slaves.json
> 
> Modified Paths:
> --
> contrib/buildbot-test/master.cfg
> contrib/buildbot-test/slaves.json.sample

When you update to this revision, please also change your local
configuration in slaves.json accordingly. This avoids the need to edit
master.cfg to run a custom buildbot installation.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-11 02:56, Jeremy Sequoia wrote:
>> By the way, as I did lots of trial and error, is there a way to get
>> debug output (from taskgated?) to see why task_for_pid() was denied?
> 
> Is it not being logged?  You should see it in the system log
> (Console.app, log collect, etc).

That is where I looked. When it fails, all I see is:

  taskgatedMacOS error: -67062

I assumed there must be some switch to get more output, but maybe it is
only enabled Apple internal.

Messages with the same error code also appear from taskgated when it
works, but also some other error codes. So this might even be unrelated
to the actual verification. When it works, I also get more output from
other components such as trustd and authd.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-10 17:52, Jeremy Huddleston Sequoia wrote:
>> On OS X 10.10 Yosemite, signing only the ggdb binary was certainly 
>> enough. I cannot reproduce this on macOS 10.12 Sierra, so the
>> requirements might have changed.
> 
> 10.10 predates SIP and related hardening around ptrace().  That
> version is so far in my rearview that I forget the details there,
> sorry.  I'll have to dig into it, but it certainly seems wrong to me
> that a process could become privileged if it linked against unsigned
> libraries.

I would assume if we find a solution that passes the current
restrictions on Sierra that will also work for older releases with less
strict checking.

I got gdb to work now on Sierra now. In fact I did not even have to sign
any of the libraries it links to.


$ otool -L /opt/local/bin/ggdb |awk 'NR>1 {print $1}' \
|grep '^/opt/local' | xargs -I{} codesign -d -v {}
/opt/local/lib/libintl.8.dylib: code object is not signed at all
/opt/local/lib/libncurses.6.dylib: code object is not signed at all
/opt/local/lib/libz.1.dylib: code object is not signed at all
/opt/local/lib/libiconv.2.dylib: code object is not signed at all
/opt/local/lib/libexpat.1.dylib: code object is not signed at all

$ /opt/local/bin/ggdb -q /opt/local/bin/curl
Reading symbols from /opt/local/bin/curl...(no debugging symbols
found)...done.
(gdb) r
Starting program: /opt/local/bin/curl
warning: unhandled dyld version (15)
curl: try 'curl --help' or 'curl --manual' for more information
[Inferior 1 (process 6964) exited with code 02]
(gdb) q


The main problem I encountered was that the setgid for the procmod group
seems to interfere with the validation now. Once I removed that by
changing the permissions to a regular 0755, I can use the code-signed
ggdb just fine to debug other programs.

By the way, as I did lots of trial and error, is there a way to get
debug output (from taskgated?) to see why task_for_pid() was denied?

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

Re: lldb ...

[Rainer Müller]

On 2016-09-10 00:23, Jeremy Sequoia wrote:
>>> YES!  We should not be needing to do such things as root.  That is
>>> 100% true, and I am in full support of moving away from that and only
>>> using root for activate.  We should be able to use fakeroot
>>> (https://wiki.debian.org/FakeRoot) for destdir.

+1

> It isn't that complicated.  It should be fairly easy for someone to
> write the moral equivalent of it under a virus-free license.  I'd also
> be happy to sponsor/advise anyone interested in doing it for GSoC or
> self-ed.

I added this to the list of ideas, in case we want to do GSoC again next
year.

https://trac.macports.org/wiki/SummerOfCode#fakeroot

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

Re: newbie python - cmake build problem I can't seem to fix...

[Rainer Müller]

On 2016-09-09 17:32, Ken Cunningham wrote:
> I'm working on updating a port (hatari) that only builds with
> python2.7 (or more accurately, doesn't build with python35 selected ,
> but does build with python27 selected). it uses cmake, and
> FindPythonInterp to find python.
> 

PYTHON_EXECUTABLE is a cmake variable. Unlike make, cmake does not fill
in variables from the environment. Instead, you have to set/override
variables with command line arguments.

Try this:

configure.args-append   -DPYTHON_EXECUTABLE=${prefix}/bin/python2.7

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

Re: lldb ...

[Rainer Müller]

On 2016-09-09 13:38, René J.V. Bertin wrote:
>> At least on OS X 10.10 Yosemite, I can use any path to a keychain with
>> `codesign --keychain`. This keychain does not have to be listed in
>> `security list-keychains`.
> 
> Does `man codesign` still mention the search list  requirement in the 
> documentation for --keychain?

>From the man page:
"""
--keychain filename
...
Note that _filename_ will not be searched to resolve the signing
identity's certificate chain unless it is also on the user's
keychain search list.
"""

I think you misunderstand this sentence. codesign will search in this
keychain for the certificate itself, but the keychain will not be used
to find other certificates in the certificate chain (all intermediates
up to a root CA). With a self-signed certificate, there is no additional
certificate in the chain.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-09 10:17, René J.V. Bertin wrote:
> On Thursday September 08 2016 16:03:21 Jeremy Huddleston Sequoia wrote:
> 
>> That's not really necessary.  All that is relevant is that the macports user 
>> has read access to the file.
> 
> The fact that codesign only accepts keychain file arguments that are also in 
> the user's keychain search list may have something to do with that.

At least on OS X 10.10 Yosemite, I can use any path to a keychain with
`codesign --keychain`. This keychain does not have to be listed in
`security list-keychains`.

>>> Technically it doesn't really matter if it's implemented in "base" or in a 
>>> PortGroup, right?
>>
>> In order for *every* port to benefit, it needs to be in base.
> 
> I don't see this argument. Are you considering codesigning each and every 
> binary automatically, without any need for requesting that from the Portfile? 
> What's the point in that?
> OTOH, if portfile devs have to indicate which binary is to be signed they can 
> just as well add a PortGroup to be able to access that functionality. 

I also have the impression we are talking about different things here. I
only want to add code-signing to the binaries that require it to work,
such as gdb and lldb.

I see no reason to and no benefits in adding a (ad-hoc) signature to
every binary MacPorts creates.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-09 11:26, Jeremy Huddleston Sequoia wrote:
> Yes.  The fact that we aren't doing that for the binary packages that
> we ship is quite embarrassing.  We should solve this problem more
> generally such that we can ship properly signed binaries for every
> port.  Users installing the binary packages that we ship right now
> are running unsigned code, and that is quite frightening.  There's
> nothing guaranteeing that the package hasn't been MITMd.  There's no
> way for us to revoke a certificate if it turns out that our build
> servers had been compromised, etc.

This is just not true. All of our binary archives are in fact signed
with a detached .rmd160 signature that is verified before installation
when downloading from a mirror.

This signature is for all files in the tarball and not just for the
binaries. This is already more than codesigning would provide.

If your machine is compromised in a way that the binaries can be
replaced, this is out of the scope of MacPorts and a signature on the
binary will not help in any way.

The key can be revoked by releasing a new MacPorts version, or you can
just remove it from /opt/local/etc/macports/pubkeys.conf.

>> OTOH, if portfile devs have to indicate which binary is to be
>> signed they can just as well add a PortGroup to be able to access
>> that functionality.
> 
> Yeah, it would be much better if we just signed every Mach-O in the
> destroot of every port.

What do we gain from that? Everything else would still be unsigned.

>> So in your approach users who want to install a debugger port will
>> become power users, change their configuration and then what?
>> Rebuild everything if they've been building from source,
> 
> No, they just need everything that the debugger executable links
> against to be signed with a trusted certificate.  That is no
> different than your case either.  Either way, the debugger and all
> its dependencies need to be signed by a valid certificate.

That does not seem to be the case. In my testing on OS X 10.10 Yosemite,
it is enough to sign /opt/local/bin/ggdb with a trusted certificate to
get it working.

Did this change with El Capitan or Sierra?

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

Re: lldb ...

[Rainer Müller]

On 2016-09-09 03:38, Jeremy Sequoia wrote:
> You are describing a system to automatically create and automatically
> trust a code signing certificate that contains a private key in a file
> on disk that is not encrypted with a passphrase and only depends on file
> system ACLs to protect it.
> 
> That is trivially insecure and attack-prone.

Adding trust for an additional certificate also only relies on the
filesystem permissions. If I get root write access to System.keychain, I
can add my own certificate.

If we add a trusted certificate to System.keychain and the corresponding
private key is only accessible by root, that would still be the same
level of security in my opinion.

>> Consider that any software can already use your developer certificate
>> from your user keychain to sign whatever it wants. 
> 
> No, it cannot.  It requires my explicit authorization to do so.  I must
> unlock the keychain for it to gain access.
> 
>> You will not even be
>> asked when that happens.
> 
> You should be if you set it up to do so.  If you put your private keys
> in your login keychain, then the act of logging in with your password is
> what unlocks them.  I don't consider that secure enough for my needs, so
> I place mine in another keychain which requires me to explicitly unlock
> it before use.

Fair enough. However, I guess most users only have a login.keychain.

>> I propose we add an additional keychain, readable by root only that is
>> used to sign MacPorts binaries. As root is required to access it, your
>> security would be defeated anyway if anyone gets to it.
> 
> It's great that only root can read it, but it should not be created
> automatically, added to any trusted store automatically, or stored
> unencrypted automatically.  We should instead give good instructions for
> setting it up with either a self-signed or ADC-Provided code signing
> certificate.

Requiring manual setup defeats my goal of just making it work by
installing the port. The status quo is already that everything needs to
be done manually.

> The user should just specify the path in macports.conf.  If it is
> locked, we should prompt for the passphrase to unlock it before use.

Would need both the path to the .keychain and the CN of the certificate,
right?

As a compromise, I would propose we generate an identity in a separate
keychain and sign the binary with it. However, adding the certificate to
the trust store in System.keychain needs to be done manually by the
user. Would you be comfortable with that?

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

Re: lldb ...

[Rainer Müller]

On 2016-09-08 22:03, Jeremy Huddleston Sequoia wrote:
> 
>> On Sep 2, 2016, at 05:19, Rainer Müller <rai...@macports.org> wrote:
>>
>> In my opinion, the actual implementation of codesigning should be in base:
>>
>> 1) Create a self-signed certificate/identity for code-signing
>> 2) Import certificate/identity into keychain
>> 3) Add it to trust store (`security add-trusted-cert ...`)
>> 4) In activate phase, if requested in Portfile, codesign the binary
> 
> No, that is incredibly dangerous.  code should not be signed during activate, 
> it should be signed at build time.  The packages that a user downloads from 
> MacPorts should not be altered at activation time.  Ideally, the packages 
> they download should be codesigned by a MacPorts developer codesigning 
> certificate.

I do not want to bless binary archives produced on the buildbot or make
them special. MacPorts is not a binary-only distribution, we allow and
support local compilation of ports.

>> Unsolved problems:
>> For step 1), how to to automate certificate creation.
> 
> Don't.  This should be a manual process.  The user should create a keychain 
> and specify the path to the keychain in macports.conf.  If that's not set, we 
> should just adhoc sign.

Adhoc code-signing does not solve the problem at hand with gdb/lldb as
that requires a trusted certificate in keychain as far as I understand it.

For what use case would ad-hoc code-signing be useful on macOS?
What would be the benefit of adding an ad-hoc signature?

>> We cannot click
>> that in Keychain Assistent. That means finding a way to do it
>> programmatically with other tools. As far as I see, this is just a
>> standard x509 certificate which could be done with openssl, but which
>> extensions need to be enabled?
>>
>> For step 4), how to give user 'macports' access to the System.keychain
>> without entering a password?
> 
> Don't use System.keychain.  A separate keychain should be used just for the 
> codesigning.  It should be password protected, and the user should be 
> prompted for the password to unlock the keychain as part of 'port build'.

Users just want to get a working gdb/lldb, they don't want to learn
stuff about keychain or code-signing. They would need to create an
identity with a specific name, know where to place it, and set the
correct trust on the certificate. All these factors will lead to user
errors and that makes the manual process not feasible in my opinion.

After some testing, I would no longer want to add the identity (private
key) to System.keychain, but instead keep it in a separate keychain
accessible by root only.

However, as far as I see, for trusting the certificate (public key) it
needs to be in System.keychain or taskgated will not accept it.

>> As an alternative, how to import the
>> identity (both private/public key) into a different keychain with
>> unlocked access?
> 
> It should be unlocked by the user providing the password to unlock the 
> keychain.

I definitely do not want my upgrades to get stalled by password dialogs.
That will only annoy users as when they have to type their password more
often.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-08 22:09, Jeremy Huddleston Sequoia wrote:
>> On Sep 5, 2016, at 03:49, Rainer Müller <rai...@macports.org> wrote:
>> My intention here is to describe a way how the code-signing can be
>> automated. We do not gain much by providing a solution that still
>> requires manual interaction by the user. Generating a certificate and
>> signing the binary should be completely transparent to the user.
> 
> That obfuscation is very bad for security purposes.  We should not hide this 
> detail from users.  It needs to be very explicit.

At the moment it is very explicit. We have no automation at all and you
need to do all of the code-signing yourself or gdb/lldb will not work as
intended.

The alternative way, recommended in the notes of the gdb port, requires
disabling SIP to edit /System/Library/com.apple.taskgated.plist, which I
would consider even worse for security. See [1].

Where do you see a security risk in adding a new trusted cert?

Consider that any software can already use your developer certificate
from your user keychain to sign whatever it wants. You will not even be
asked when that happens.

I propose we add an additional keychain, readable by root only that is
used to sign MacPorts binaries. As root is required to access it, your
security would be defeated anyway if anyone gets to it.

Rainer

[1] https://trac.macports.org/ticket/49815
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: lldb ...

[Rainer Müller]

On 2016-09-05 12:56, René J.V. Bertin wrote:
> On Monday September 05 2016 12:21:08 Rainer Müller wrote:
> 
> Do the steps in that TN include the trust setting and the magic command in 
> lldb's code-signing document?

I was talking about generating self-signed identities/certificates and
that is covered in TN 2206.

>> However, another thing I did not think of before, what should be used as
>> expiry date on the certificate? According to the TN, OS X does not care
>> about the expiration date for both verification or signing for "simple
>> applications", whatever that means.
> 
> So, why would you force an expiration date on users? Say they install 
> lldb-3.x and stay at that version for whatever reason. That port isn't going 
> to change anymore at some point, so why force people to go through the hassle 
> even of de/re-activating. That seems rather unheard of, and a first step on 
> planned and forced obsolescence (where software stops working after a given 
> date).

I am not forcing it on them. x509 certificates have an expiry date. That
is just a fact.

> I still think the easiest would be if that certificate and the corresponding 
> keys would be stored in a keychain belonging to the MacPorts operator, not 
> the macports. That's going to make maintenance and support so much easier. 
> However, there's one surprising thing one should be aware of:
> 
> {{{
> %> ll /opt/local/bin/411toppm
> 288233 0 -rwxrwxr-x 1 root wheel 33904 Dec  7  2014 /opt/local/bin/411toppm*
> %> id | fgrep wheel
> Exit 1
> %> codesign -s lldb_codesign -vvv /opt/local/bin/411toppm
> /opt/local/bin/411toppm: signed Mach-O universal (i386 x86_64) [411toppm]
> %> ll /opt/local/bin/411toppm
> 57101195 52 -rwxrwxr-x 1 bertin admin 51488 Sep  5 12:41 
> /opt/local/bin/411toppm*
> }}}
> 
> IOW: I'm not a member of the wheel group, so I do not normally have write 
> access to 411toppm even if I own its parent directory. Yet I could run 
> codesign on it without having to authenticate. It's probably better that the 
> root ownership wasn't preserved even if that shouldn't make a difference for 
> execs that aren't SETUID or SETGUID, but still. FWIW, running `sudo codesign` 
> doesn't alter the file's ownership:

That's expected behavior. The permissions on the file itself are not
relevant for unlinking, only permissions of the directory matter. Your
user has write access to /opt/local/bin or this would have failed with
an error message.

But yes, that means we have to take care of preserving the permissions
when codesigning.

> {{{
> %> sudo codesign -s lldb_codesign -vvv -f /opt/local/bin/asciitopgm
> /opt/local/bin/asciitopgm: replacing existing signature
> /opt/local/bin/asciitopgm: signed Mach-O universal (i386 x86_64) [asciitopgm]
> %> ll /opt/local/bin/asciitopgm
> 57101222 52 -rwxrwxr-x 1 bertin admin 51456 Sep  5 12:53 
> /opt/local/bin/asciitopgm*
> }}}
> 
> So the current solution in my code-signing PortGroup isn't good, probably; 
> only the HOME directory should be set to point to where the keychain holding 
> the signing identify is to be found.

Why set HOME when you can use --keychain?

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

Re: lldb ...

[Rainer Müller]

On 2016-09-05 13:29, René J.V. Bertin wrote:
> Reminds me: I'm not really comfortable with the idea that PortFiles
> would be able to create and store certificates. I'd rather see a form
> where they can check for the availability of the identity, and then
> inform the user exactly what command to run. More tedious, but at
> least it forces you to see what's being done.

I see no problem in generating certificates automatically. We also add
users to the system or create launchd configurations without forcing the
user to do it manually.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-05 00:57, René J.V. Bertin wrote:
> In a first draft the command accepted a list of binaries to sign, and read 
> the identify from a configuration file. I suppose that corresponds to what 
> you mean with a declarative syntax?
> I then went to a simpler, single-binary interface because I realised that it 
> would sometimes be necessary to specify a different identity. It shouldn't be 
> hard to change that into
> 
> ```
> codesign identity binary1 [binary2 [...]]
> ```

In a Portfile you would not be interested in the name of the identity,
the but trust policy it grants (firewall bypass, task_for_pid, etc.).

Otherwise you would expect users to set up different identities and
assign the correct trust policy, which is just not feasible.

I am thinking of a list of files and policies such as:

codesign.files   ${prefix}/bin/binary1 developer \
 ${prefix}/bin/binary2 firewall
codesign.identifier  org.macports.${name}

Of course this identifier would usually just be the default value, so it
does not need to be specified explicitly.

>>> Alternatively, MacPorts could create the certificate and then export it in 
>>> such a way that users only have to import it. There might be other benefits 
>>> to that (signing kexts provided by ports ...).
>>
>> I don't think I understand your idea... Why would we need to export it
>> for users to import it again? The generated identity is meant only to be
>> used by MacPorts and nothing else.
> 
> I don't know how easy it is to automate the certificate creation, if at all 
> possible. Creating one that users only have to import removes a step or two 
> that could go wrong (if it cannot be automated), importing may be easier to 
> automate, and there may be an advantage if everyone signs using the same 
> certificate.

If users need a identity, they can generate one with Keychain Access.
The identity generated by MacPorts is only meant to be used by MacPorts.

>> This approach cannot be used to sign kext, as that requires a
>> certificate signed by Apple.
> 
> I was thinking about a hypothetical possibility to redistribute such a signed 
> certificate. I know, probably extremely unlikely, but one can dream :)

No way to do that. As we are code-signing on the local machine, we would
need to distribute the private key. Everyone would be allowed to sign
their kext with this, which defeats the whole purpose of signed kexts.

>> This is not fully automatic and requires user interaction. This makes it
>> fragile as it requires users to follow manual steps very closely to
>> generate a certificate and set the required trust. That needs to be
>> automated.
> 
> I wouldn't be completely surprised if it turns out to be impossible to 
> automated the whole process; Apple could well have seen to that as a 
> protection against unexpected certificates popping up, with unlimited trust 
> etc. It's been a while since I used the API, and I only used the parts 
> related to traditional credentials, and keychain creation/management.

My intention here is to describe a way how the code-signing can be
automated. We do not gain much by providing a solution that still
requires manual interaction by the user. Generating a certificate and
signing the binary should be completely transparent to the user.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-02 14:19, Rainer Müller wrote:
> For step 4), how to give user 'macports' access to the System.keychain
> without entering a password? As an alternative, how to import the
> identity (both private/public key) into a different keychain with
> unlocked access?

I found the missing information in this technical note:

https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG10

However, another thing I did not think of before, what should be used as
expiry date on the certificate? According to the TN, OS X does not care
about the expiration date for both verification or signing for "simple
applications", whatever that means.

Would it be enough to just use 365 days as every port is expected to be
updated/reinstalled during this time period? And after that we just add
another certificate valid for the next 365 days.

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

Re: lldb ...

[Rainer Müller]

On 2016-09-02 14:45, René J.V. Bertin wrote:
> On Friday September 02 2016 14:19:02 Rainer Müller wrote:
> 
>>> https://trac.macports.org/ticket/45251
>>
>> That would equivalent to what gdb recommends for codesigning.
> 
> Yes, minus the part related to taskgated. And plus a few extra steps that 
> probably serve to add the certificate to the trust store.
> 
>> In my opinion, the actual implementation of codesigning should be in base:
>>
>> 1) Create a self-signed certificate/identity for code-signing
>> 2) Import certificate/identity into keychain
>> 3) Add it to trust store (`security add-trusted-cert ...`)
>> 4) In activate phase, if requested in Portfile, codesign the binary
> 
> That's what's done in my PortGroup, which could of course be a vector to test 
> out the functionality before integrating it into "base" (and make it 
> available before the next new base release).

For reference, this would be about #51504:
https://trac.macports.org/ticket/51504

As far as I see it, this only implements step 4), it already expects an
identity generated by the user before. Also, this is implement as a
command, I would prefer a declarative syntax (list of binaries for
codesigning).

>> Unsolved problems:
>> For step 1), how to to automate certificate creation. We cannot click
>> that in Keychain Assistent. That means finding a way to do it
>> programmatically with other tools. As far as I see, this is just a
>> standard x509 certificate which could be done with openssl, but which
>> extensions need to be enabled?
> 
> Alternatively, MacPorts could create the certificate and then export it in 
> such a way that users only have to import it. There might be other benefits 
> to that (signing kexts provided by ports ...).

I don't think I understand your idea... Why would we need to export it
for users to import it again? The generated identity is meant only to be
used by MacPorts and nothing else.

This approach cannot be used to sign kext, as that requires a
certificate signed by Apple. There is no (documented) way to trust
another certificate in the kernel.

> If the security utility doesn't already allow it, it shouldn't be 
> particularly hard to write some code that will import a certificate into a 
> possibly newly created keychain that is then set default. When executed as 
> the macports user this should result in a keychain that's accessible to ... 
> the macports user.

codesign accepts a --keychain option, so there is no need to modify the
default keychain.

> But are you sure that the activate and/or post-activate phases are executed 
> as the macports user? I don't have the impression that's the case.

You are correct that only root would need access. That could mean that
the certificate could just be in the System.keychain. In my testing that
always seems to require a password, though...

>> For step 4), how to give user 'macports' access to the System.keychain
>> without entering a password? As an alternative, how to import the
>> identity (both private/public key) into a different keychain with
>> unlocked access?
> 
> Is there anything wrong with my approach of specifying a username (typically 
> your own) that's used only for the signing operation?
>
> BTW, I'm pretty sure that I tried putting the certificate back into the 
> System keychain and attempt to sign without specifying a user. That still 
> gave the error that the certificate wasn't found, which is why I kept 
> searching and found the solution currently implemented in the PortGroup.

This is not fully automatic and requires user interaction. This makes it
fragile as it requires users to follow manual steps very closely to
generate a certificate and set the required trust. That needs to be
automated.

In your testing, did you move the private/public key ("identity") or
maybe just the public key ("certificate")?

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

Re: lldb ...

[Rainer Müller]

On 2016-08-31 23:25, Lawrence Velázquez wrote:
>> On Aug 31, 2016, at 4:57 PM, René J.V. Bertin  wrote:
>>
>> I noticed that Apple don't ship an lldb-mi executable (at least they don't 
>> for OS X 10.9). 
> 
> Xcode 7.3 includes it (`xcrun --run lldb-mi`) but Xcode 4.6.3 does not. 
> Someone else is welcome to bisect on that.
> 
>> Has anyone looked at building an lldb port before?
> 
>> The real problem is going to be with the code-signing. This is done 
>> automagically by lldb's Xcode projects so it's not entirely clear which 
>> files have to be signed ... nor if an "ad-hoc" signing identify ("-") will 
>> lead to a usable debugger.
> 
> You opened a ticket about this a while ago. One of Eric's comments hints at 
> what a pain it might be to get it working with code signing.
> 
> https://trac.macports.org/ticket/45251

That would equivalent to what gdb recommends for codesigning.

https://sourceware.org/gdb/wiki/BuildingOnDarwin#Giving_gdb_permission_to_control_other_processes


In my opinion, the actual implementation of codesigning should be in base:

1) Create a self-signed certificate/identity for code-signing
2) Import certificate/identity into keychain
3) Add it to trust store (`security add-trusted-cert ...`)
4) In activate phase, if requested in Portfile, codesign the binary

Unsolved problems:
For step 1), how to to automate certificate creation. We cannot click
that in Keychain Assistent. That means finding a way to do it
programmatically with other tools. As far as I see, this is just a
standard x509 certificate which could be done with openssl, but which
extensions need to be enabled?

For step 4), how to give user 'macports' access to the System.keychain
without entering a password? As an alternative, how to import the
identity (both private/public key) into a different keychain with
unlocked access?

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

Re: checking a file's dependents/cies?

[Rainer Müller]

On 2016-08-30 12:33, René J.V. Bertin wrote:
> Is there a direct way to check what (binary) files depend on a given file 
> belonging to a port, something a bit less blunt than moving the file aside 
> and running `port -v rev-upgrade`?
> I presume a mysql query of the registry could return that kind of information 
> - just as it could return the file's own registered dependencies?

No, that information is not stored in the registry. The registry only
stores dependencies between ports, not files.

rev-upgrade iterates over all binaries in the prefix and checks if
referenced libraries are still available and if they have a compatible
version.

You can recreate that with the subset of relevant files to get the
information you want, you can get the list of files in recursive
dependents of the port providing the library you are interested in
and then check if they link against this library.

For example for liblzma provided by the xz port:

lib=/opt/local/lib/liblzma.dylib
port -q contents rdependentof:$(port -q provides $lib |awk '{print $5}') \
  | grep /bin/ \
  | while read bin; do
  otool -L $bin | grep -q liblzma && echo $bin
  done

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

Re: Permission denied, "pkg" phase

[Rainer Müller]

On 2016-08-26 05:09, Craig Treleaven wrote:
> I’ve tried adding:
> 
> pkg.asroot  yes
> 
> to my portfile but that seems to be unrecognized.
> 
> Is there a way around this?

Not without patching base. I have no experience with creating pkgs, so I
don't know if it makes sense to allow running this as root at all.

Rainer
Index: src/package1.0/portpkg.tcl
===
--- src/package1.0/portpkg.tcl  (revision 151752)
+++ src/package1.0/portpkg.tcl  (working copy)
@@ -45,6 +45,7 @@
 
 # define options
 options package.type package.destpath package.flat package.resources 
package.scripts
+options pkg.asroot
 
 # Set defaults
 default package.destpath {${workpath}}
@@ -52,6 +53,7 @@
 default package.scripts  {${workpath}/pkg_scripts}
 # Need productbuild to make flat packages really work
 default package.flat {[expr {[vercmp $macosx_deployment_target 10.6] >= 
0}]}
+default pkg.asroot no
 
 set_ui_prefix
 
___
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: request review #52066

[Rainer Müller]

On 2016-08-24 02:14, Björn Ketelaars wrote:
> Would someone be so kind to review (and commit)
> https://trac.macports.org/ticket/52066 ?

Done.
https://trac.macports.org/changeset/151932

Rainer

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

Re: how about a 'snowleopardfixes' library port?

[Rainer Müller]

On 2016-08-23 19:13, Ryan Schmidt wrote:
> I would prefer you work with the developers of the affected software packages 
> to get the necessary compatibility functions into their sources. This will 
> help all Snow Leopard users, not just those using MacPorts.  

I agree that fixing bugs in upstream is preferable.

However, the functions getline() and strnlen() were already standardized
in POSIX.1-2008. Assuming these functions to be available is reasonable
today. I would totally understand if upstream rejects the burden of
supporting legacy systems.

@Ken:
Just another thought, the declaration could be in its own file,
referenced with the compile option -include in CFLAGS/CXXFLAGS, with
conditional #ifdef to add extern "C" for C++. The unused declaration
should not do any harm in other compile units. That way you could even
avoid generating patches for the ports.

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

[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: port install v port mpkg | mdmg

[Rainer Müller]

Hello,

On 2016-08-10 17:23, Craig Treleaven wrote:
> Is it possible for a port to take different actions depending on
> whether the user has initiated ‘port install’ v. 'port mpkg’ (or
> ‘port mdmg’)?

Unfortunately, no, as all phases can be run individually. So up to the
destroot phase, there is no knowledge whether the following step would
be install or mpkg.

> My mythtv-pkg.27 is intended to be used to create an all-in-one
> installer package for MythTV.  I have a VM with a custom prefix for
> this.  The resulting mpkg needs daemondo, so I created the nasty hack
> in MacPorts_daemondo.  However, mythtv-pkg.27 could be a nice
> shortcut for a MacPorts user that wants to install a complete MythTV
> system in one go.  In such case, they don’t need MacPorts_daemondo.

One solution for this could be in base to automatically include daemondo
in the mpkg when it is used by the port being packaged.

See portmpkg::make_dependency_list in src/package1.0/portmpkg.tcl [1]
where the list of dependencies is generated. If the port to be packaged
has a startupitem, additionally include MacPorts_daemondo in the result
list.

Of course MacPorts_daemondo itself would still be a hack and require
force activation...

Rainer

[1]
https://trac.macports.org/browser/trunk/base/src/package1.0/portmpkg.tcl?rev=134837#L61
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: A separate PortIndex for libc++ on older systems

[Rainer Müller]

On 2016-08-10 20:09, Lawrence Velázquez wrote:
> On Aug 10, 2016, at 4:37 AM, Ryan Schmidt 
> wrote:
> 
>> We also still need to decide how to differentiate the URLs for
>> libc++ packages from the URLs of the existing libstdc++ packages.
>> One suggestion was to add cxx_stdlib as a variable in
>> archive_sites.conf, and upload the libc++ archives with the same
>> names as the libstdc++ archives but in a new subdirectory, e.g.
>> https://packages.macports.org/libc++/.
> 
> One downside of using identical archive names is that we'd be unable
> to differentiate local libstdc++ archives from libc++ ones based on
> file name. This distinction could be used to rebuild packages after
> changing cxx_stdlib, for instance.

Other variables that make archives incompatible, such as the prefix,
applications_dir, or frameworks_dir, are already not visible in the
filename.

Perhaps all of this should be part of the +CONTENTS file in the archive?

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

Re: Determine before installation whether a port can be installed

[Rainer Müller]

On 2016-07-28 09:06, Artur Szostak wrote:
> This sounds like there is a need to allow encoding of version ranges. In 
> which case I would suggest to solve this problem generically, to allow 
> encoding version ranges in port dependencies also. Similar to what is 
> possible with RPMs or Debian packages. If the logic is implemented for 
> dependencies then one could surely easily have things like the following 
> encoded in the Portfile:
> 
>   macosx >= 10.9
>   macosx < 10.10

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

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