Re: How best to change a hard-coded config search path, before compilation

[Lawrence Velázquez]

> On Nov 4, 2016, at 8:53 PM, A. Karl Kornel  wrote:
> 
> The first thing I was thinking of doing is using "reinplace" directly
> on the file in question, in the pre-build phase. The section method
> I came up with was to use a patch file to change the line, replacing
> "/etc" with "PREFIX_GOES_HERE" (or something), and then using
> reinplace to put in the correct path.
> 
> Both methods do the same thing, but in my mind the second method is
> better because it makes absolutely sure I am only changing one part of
> the file. Also, if the code changes in a future version, the patch
> will fail to apply. That will help me from missing changes.

We strongly prefer the second method, for the reasons you already gave.
Your portfile should contain a bit resembling this:

patchfiles use-macports-prefix.patch

post-patch {
reinplace s|__PREFIX__|${prefix}| file.ext
}

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

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:48 PM, Clemens Lang  wrote:
> 
>> * Using the same change methods as outside contributors may help to
>> develop better PR flow.

I am not particularly interested in accommodating contributors' workflow
expectations for their own sake. Their workflows may work for them but
not for us.

>> 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.
> 
> Absolutely agree.

I think this is mainly us trying to figure out a good workflow. I expect
things will settle down eventually.

>> * Ability to get a feedback / review from other project members.
> 
> Agree for the cases where other people interested in the ports and
> capable of reviewing exist, and those people have the time to review in
> a timely fashion.

Sure. I would encourage committers who want feedback to open as many PRs
as they want.

(You get a PR! You get a PR! Everybody gets a PR!!!)

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

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:43 PM, Marko Käning <mk-macpo...@posteo.net> wrote:
> 
>> On 04 Nov 2016, at 18:34 , Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>> It doesn't really do anything differently w.r.t. wrapping, but it
>> highlights subject-line overflow in an alarming red color.
> 
> that’s a nice feature.

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

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

[Lawrence Velázquez]

> On Nov 4, 2016, at 1:30 PM, Marko Käning  wrote:
> 
> Oh, I’d be using vim as well, good to know that it does support git.
> I didn’t know that vim would be able to treat commit message line
> formatting for the first and the 3r+ lines differently with 50 and 72
> chars respectively.

It doesn't really do anything differently w.r.t. wrapping, but it
highlights subject-line overflow in an alarming red color.

> Well, this was a trigger for a discussion about the topic of
> a template which potentially could make the committer’s life easier...
> But I understood in the meantime that I could have just used my spare
> time much better for other things than trying to care about such silly
> things like a commit template. I thought what KDE has is a good
> starting point and I believed MacPorts devs would see value in it.
> I have now been taught that I wasted my time and yours.

Not a waste of time! Can't know what the water is like without dipping
your toe in. We appreciate your enthusiasm :)

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

Re: Working with Git

[Lawrence Velázquez]

> 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.

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 2:46 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
> 
>> On Nov 3, 2016, at 2:16 PM, Rainer Müller <rai...@macports.org> wrote:
>> 
>> 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.
> 
> Yeah, I think that's right. That means that rebasing from the command
> line is not feasible for most PRs because the contributors' branch is
> unlikely to be based on the absolute latest master. So I think the
> process you mentioned (push to collaborator's branch, rebase from the
> web) might become our standard operating procedure.

Actually I think I was mistaken about this. Rebasing onto master + fast-forward 
merging + pushing from the command line works fine, as long as you force-push 
your local changes to the PR branch first. It doesn't seem to matter where the 
PR branch was branched from; GitHub knows to isolate the changes that aren't in 
the base branch.

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 2:16 PM, Rainer Müller <rai...@macports.org> wrote:
> 
> 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.

Yeah, I think that's right. That means that rebasing from the command
line is not feasible for most PRs because the contributors' branch is
unlikely to be based on the absolute latest master. So I think the
process you mentioned (push to collaborator's branch, rebase from the
web) might become our standard operating procedure.

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 1:46 PM, Rainer Müller  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.

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 11:59 AM, Mojca Miklavec  wrote:
> 
> 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.

I think (don't quote me on this) that GitHub considers a PR "merged"
when the base branch is updated and has incorporated the changes from
the head branch. If a committer modifies their local branch before
merging, the base branch does not look like it has merged in the head
branch because the new content is in fact different.

(This makes sense, in a way. After all, if you had to change a PR branch
before merging it, did you really accept the PR?)

> 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.

To reduce excessive communication, it does seems like a good idea to ask
contributors to allow us to push changes to their PR branches. Those
modified branches should then merge as desired.

https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork

> 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).

Why was that stupid? Did it cause a problem?

(Note that GitHub shows PR links on closing commits. Look just under the
commit message, next to "master":
https://github.com/macports/macports-infrastructure/commit/1e6b092)

> I probably also sinned by thinking of "playing safe" and using
> cherry-pick rather than "wrongly rebasing" and risking some undesired
> merge.

You cherry-picked instead of rebasing the PR branch onto master? That
shouldn't cause any problems, I think.

> 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

My sense is that the only real rule is that you need to push
modifications before doing the merge. For most PRs, that would require
the contributor to enable the setting that I mentioned above.

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 12:19 PM, Sterling Smith  wrote:
> 
> The user will not learn if you change it under his/her feet.  I think
> that you should make line by comments of changes that need to be made
> in the files tab of the pull request and ask the pull request
> submitter to make those changes.

While this is all fine in the abstract, in practice committers have
always felt free to improve contributors' patches before committing,
especially if said improvements are minor.

> Or you can make them yourself and push them to the branch of the pull
> request and ask the submitter if s/he is OK with them.

The contributor must first allow us to modify their PR branch:

https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork

This seems very useful. Perhaps we should request that all contributors
do this when opening PRs.

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

Re: How to submit an updated portfile on new system?

[Lawrence Velázquez]

> On Nov 3, 2016, at 12:12 PM, Watson Ladd  wrote:
> 
> Dear all,
> A new version of Pari has come out, and I will update the portfile
> soon. However, I haven't found new git compatible workflow
> documentation anywhere. Should I still do the old-fashioned make a
> patch and submit in a ticket, or should I fork the repo, modify it,
> and submit a pull request?

Either is fine. We do still accept Trac patches and do not plan to stop
doing so.

vq
___
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?]

[Lawrence Velázquez]

> On Nov 3, 2016, at 8:01 AM, René J.V. Bertin  wrote:
> 
> On Thursday November 03 2016 12:42:40 Rainer Müller wrote:
> 
>> Overall, can we just stop this discussion, please? We settled to stay
>> with Trac and it is not going to change.
> 
> Really, all your decisions are always set in stone from the very
> moment you make them regardless of how things evolve?

This is not the first discussion we have had about possibly switching
bug trackers. All have generally concluded that, despite Trac's warts,
migrating is not worth it right now. At this point, we are kicking
a horse that is dead and buried and worm food, and it is wasting
everyone's time and energy. Enough.

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

Re: Working with Git

[Lawrence Velázquez]

> On Nov 2, 2016, at 11:24 PM, Ryan Schmidt  wrote:
> 
> Yes, there are "command line instructions" on the web site, but they
> are different from the commands you gave below, which are again
> different from other commands suggested in previous threads, so it is
> difficult to know which set of instructions to follow.

Obviously I think you should follow mine ;)

The GitHub instructions assume that you're okay with nonlinear history
(they create merge commits), so we can't really use them. But I found
them useful for developing my instructions.

> Thanks, that worked, up until the "git push origin master" command,
> which asked me to authenticate, and supplying my username and password
> was unsuccessful:
> 
> $ git push origin master
> Username for 'https://github.com': ryandesign
> Password for 'https://ryandes...@github.com': 
> remote: Invalid username or password.
> fatal: Authentication failed for 
> 'https://github.com/macports/macports-ports.git/'

That's curious. What does "git remote -v" print?

> Now I still seem to have this branch in my local git repo:
> 
> $ git branch
>  l2dy-curl-ca-bundle-update
> * master
> 
> Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"?

Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
suggested because these instructions are designed so that you can always
fast-forward merge the PR branch into master. If "git branch -d" fails,
something is not right, and you have to go back and figure out what.

One small addendum: Before "git push origin master", you should run "git
pull --rebase" to get any new commits that were pushed by other
committers.

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

Re: New project members: jonesc

[Lawrence Velázquez]

> On Nov 2, 2016, at 2:20 PM, Rainer Müller  wrote:
> 
> Please join us in welcoming the following new MacPorts project member:
> 
> - Chris Jones (jonesc)
> 
> We look forward to continued excellent contributions!

Yay!

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

Re: New build failure emails are difficult to act on

[Lawrence Velázquez]

Can you open a ticket for this and assign it to me? You can just
copypaste your original email as the description or something.

vq

> On Nov 2, 2016, at 3:56 AM, Jeremy Huddleston Sequoia  
> wrote:
> 
> 
>> On Nov 2, 2016, at 00:20, Mojca Miklavec  wrote:
>> 
>> On 2 November 2016 at 06:17, Jeremy Huddleston Sequoia wrote:
>>> I've been having a bit of difficulty dealing with the new buildbot emails.  
>>> I would really like links to the individual failing jobs.  Instead, we're 
>>> given links to each job and a list of failed ports, but there is no 
>>> indication as to which port corresponds to which job.  One must look 
>>> thorough each link to find the relevant one.
>>> 
>>> Could we get those links added to the 'Broken ports' section?
>> 
>> Sure. We gladly accept patches :) :) :)
>> 
>> OK, joke aside. I wrote the part of the code that generates the
>> emails, but I did not manage to figure out how to map the build
>> number/url to a port. Buildbot nine is apparently more clever about
>> that and there it should apparently be more straightforward to do it,
>> but many are reluctant to switch just yet.
>> 
>> There are several ways to fix this:
>> 
>> - hack into Python code (most elegant, but I did not have any success
>> with that yet)
>> 
>> - I once tried to fetch the contents of json files for individual
>> builds and parse it, but that crashed/froze the buildbot (it might be
>> that I wrote buggy code, but that approach is super ugly anyway)
>> 
>> - probably the easiest workaround would be to print the URL or the
>> build number to
>> https://build.macports.org/builders/ports-10.8_x86_64_legacy-watcher/builds/2764/steps/summary/logs/stdio
>> which would make it easier to map the URLs to ports.
>> 
>> Somewhat related tickets:
>>  https://trac.macports.org/ticket/52766
>>  https://trac.macports.org/ticket/51995
> 
> FYI, My current hack method is to open the 'Full logs:' link, check out the 
> summary, and then figure out from that list which of the job's to check (if 
> the third job failed, pick the link with the third number in the series).
> 
> --Jeremy
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: port info --{build,configure}.dir ?

[Lawrence Velázquez]

> On Nov 2, 2016, at 5:06 AM, René J.V. Bertin  wrote:
> 
> Would a request to provide the build and/or configure directory
> variables as meta-info data be accepted?

Probably not.

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

[Lawrence Velázquez]

> On Nov 1, 2016, at 6:51 PM, Marko Käning  wrote:
> 
> I know that many of you weren't in favour of a commit message template,
> but I propose one anyway, which I derived from KDE’s neat one, as I find
> it on the console quite handy to know when 50 or 72 characters are
> reached in a line:

To be honest, this template adds so much comment noise that I can't
imagine ever using it.

> --- ~/.git-commit-template ---
> #  Please enter the commit message for your changes. Lines starting
> #  with '#' will be ignored, and an empty message aborts the commit.
> #
> #   -> The title MUST not be longer than 50 characters. 

I don't think we should dictate a hard limit on this. Sometimes it's
hard to say anything meaningful in 50 characters, especially since we
prepend port names to the subject line. Anything less than 60 chars is
generally good enough.

> #   -> You MUST wrap all further lines at 72 characters.
> #
> #  For more information on how to write commit messages see MacPorts'
> #  wiki at https://trac.macports.org/wiki/WorkingWithGit#commitmessages
> #
> # ==[ Subject: One meaningful line ONLY!  ]==|
> 
> # ==[ Blank: Follow the Subject with a blank line, do NOT remove ]=|
> 
> # ==[ Details: Describe what changed and explain why it changed]===|

This is all informative exactly once.

> # ==[ Fields: Uncomment and edit where applicable ]|
> 
> # --[ Links to issues on MacPorts' trac ]--|
> #ISSUE:  
> #RESOLVES:   
> #BLOCKED BY: 
> #
> ##EXAMPLE:
> # ISSUE: https://trac.macports.org/ticket/98765
> #
> ##NOTE: Don't use '#'-notation, since it's a Pull Request ID on GitHub!
> #
> # --[ Links to other pull requests at GitHub ]—|
> #PR:  
> #
> ##EXAMPLE:
> # PR:  #123

As Clemens already noted, these aren't the supported keywords.

> # --[ FUTURE FEATURE TO IGNORE/TRIGGER BUILDS ON SPECIFIC BUILDBOTS ]--|
> #BUILDBOT: < ignore | list_of_buildbots >
> #
> ##EXAMPLE:
> # BUILDBOT: ignore
> # BUILDBOT: ports-10.9_x86_64 ports-10.12_x86_64
> #
> ##NOTE: This isn't yet implemented at MacPorts' GitHub!
> #
> ##NOTE: See relevant issue: https://trac.macports.org/ticket/52769
> ---
> 
> 
> I have fantasised a little here what concerns the (perhaps upcoming)
> BUILDBOT feature.

I wouldn't hold my breath on this.

> The links section is also just serving as an example, but it might be a
> good idea to define some useful keywords there as well.
> 
> I also introduced a pull request section, which might be nice to have
> for proper documentation, who knows.

We have the wiki and guide for documentation. This template is not the
place for documentation.

> But perhaps all this is overkill?!

In case it's not obvious, I think this is serious overkill.

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

Claiming your user repository

[Lawrence Velázquez]

Hello,

As a reminder:

> On Oct 31, 2016, at 11:00 PM, Ryan Schmidt  wrote:
> 
> If you had a personal directory in the users directory of the
> Subversion repository, that has now been converted to a separate git
> repository in https://github.com/macports with a name starting with
> "macports-user-".
> 
> We suggest that you move your user repository to your own GitHub
> account where you can continue to use it as you see fit. Instructions
> for how to move it are forthcoming.

To take ownership of your user repository, just fork it to your personal
GitHub account. We will then delete the original, making yours the
canonical repository.

(If you don't see your repository on the organization page, enter your
MacPorts handle in the search box immediately above the repository list.
Or just go to "https://github.com/macports/macports-user-[YOUR HANDLE]".)

> You should not use the Fork button to do so.

Disregard this warning; we were mistaken about the way GitHub would
handle deletion of the original repository.

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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> On Nov 1, 2016, at 3:55 PM, Daniel J. Luke <dl...@geeklair.net> wrote:
> 
>> On Nov 1, 2016, at 3:36 PM, Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>> While I agree in principle that our committing should not be
>> hampered by the buildbot and would welcome another solution, I'm not
>> crazy about the idea of polluting our (permanent!) commit history
>> with transient administrivia like this.
> 
> A tag that indicates 'This commit was part of a mass change' (that
> doesn't change the build product) doesn't seem like pollution in the
> commit history to me, but I don't really care too much.

In the Trac ticket, Rainer linked to a Stack Overflow post that
suggested modifying a dummy file. I'm more amenable to that method.

> I imagine this could also be handled 'manually' by someone who could
> temporarily disable the build infrastructure, make the mass change,
> and then bring the build infrastructure back up.

I think GitHub would eventually redeliver the failed webhook payload in
that case.

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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> On Nov 1, 2016, at 3:45 PM, Rainer Müller <rai...@macports.org> wrote:
> 
> 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.

In private discussion with Mojca, I realized that for some reason I'd
gotten it into my head that there would be thousands of commits, instead
of just a few commits that modified thousands of ports each. I'd also
forgotten (even though I implemented it) that the buildmaster now only
sends off one BuildSet per push due to the tree-stable timer. So there
would not be as many objects flying around as I'd thought.

It's hard to say without trying it, but committing then canceling might
not actually be that bad.

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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> On Nov 1, 2016, at 4:59 AM, Marko Käning  wrote:
> 
>> On 01 Nov 2016, at 02:02 , Rainer Müller  wrote:
>> 
>> buildbot: ignore
> 
> +1
> 
> I’d also suggest to use this also to specify which buildbots should be used 
> for a commit:
> 
> buildbot: Mavericks Sierra
> 
> I think that can be very helpful in some cases.

While I agree in principle that our committing should not be hampered by
the buildbot and would welcome another solution, I'm not crazy about the
idea of polluting our (permanent!) commit history with transient
administrivia like this.

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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> On Nov 1, 2016, at 2:22 PM, Mojca Miklavec <mo...@macports.org> wrote:
> 
>> On 1 November 2016 at 18:07, Lawrence Velázquez wrote:
>> 
>>> On Nov 1, 2016, at 7:00 AM, Mojca Miklavec wrote:
>>> 
>>> Why not:
>>> - wait until all the slaves have something non-trivial to do (make
>>> sure the queue is not empty)
>>> - do a bulk commit
>>> - cancel the job manually
>> 
>> That won't prevent the buildmaster from receiving 20,000 changes,
>> processing ~100,000 build requests, and scheduling ~100,000 builds.
> 
> No, that's not true. 100.000(?) build request would only be scheduled
> if we fail to cancel the build on the portwatcher.

I don't think this is accurate. Builds would not yet have been created,
but BuildRequests would have been scheduled.

But I think you're right, for the wrong reasons. I forgot that the port
scheduler has a tree stable timer now; a single BuildSet would be
created for all 20,000 Changes.

> If we cancel the job on the portwatcher before
> it gets processed, there will be absolutely zero penalty (except that
> the failcache would probably be erased).

Just because builds are not actually happening yet does not mean there
isn't a memory penalty from the queued requests.

In any case, the proposed set of commits is utterly unnecessary and is
not worth any of this fuss.

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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> On Nov 1, 2016, at 7:00 AM, Mojca Miklavec  wrote:
> 
> On 1 November 2016 at 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.
>> 
>> Please, for now, just make this change together with other necessary changes.
> 
> Why not:
> - wait until all the slaves have something non-trivial to do (make
> sure the queue is not empty)
> - do a bulk commit
> - cancel the job manually

That won't prevent the buildmaster from receiving 20,000 changes,
processing ~100,000 build requests, and scheduling ~100,000 builds.

There's basically zero benefit to such a mass commit. The "$Id$" lines
are harmless.

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

Re: Working with Git

[Lawrence Velázquez]

> On Nov 1, 2016, at 4:57 AM, Rainer Müller  wrote:
> 
>> On 2016-11-01 05:54, Mojca Miklavec wrote:
>> 
>> 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].

+1

The point of the wiki is to help users, not play politics. We do not
have quid pro quo relationships with any upstream developers. As
irritating as the hub devs' attitude may be, the tool they develop may
still be useful to our users, so there's no reason we shouldn't mention
it matter-of-factly and let users decide if it fits their needs. I don't
see this as an advertisement or recommendation.

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

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

[Lawrence Velázquez]

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

vq

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

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

Re: Removing "$Id$" lines

[Lawrence Velázquez]

> On Oct 31, 2016, at 6:17 PM, Dan Ports  wrote:
> 
> Any reason not to just bulk-remove them all at once?

No reason other than time and effort.

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

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:55 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
>> On Oct 31, 2016, at 5:50 PM, Sean Farley <s...@macports.org> wrote:
>> 
>> I'm not sure I agree with attempting to modify the git repo at all. For
>> example, what if I'm in the middle of bisecting and need to add/remove a
>> port? Why does 'port sync' call at all what the state is?
> 
> Updating the repository is the whole point of "port sync".

That's not to say "port sync" couldn't be smarter about it, obviously.
The Git functionality was implemented in a very straightforward way,
back when just a few people used git-svn or Mac OS Forge's Git mirrors.

But yeah, it's a layer-cake sort of thing. "port selfupdate" updates
base and does a sync. "port sync" updates the ports tree and reindexes.
"portindex"…indexes. The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.

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

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:50 PM, Sean Farley  wrote:
> 
> I'm not sure I agree with attempting to modify the git repo at all. For
> example, what if I'm in the middle of bisecting and need to add/remove a
> port? Why does 'port sync' call at all what the state is?

Updating the repository is the whole point of "port sync". If you just
want to refresh your portindex, you should be running "portindex
/path/to/ports/tree".

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

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:46 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
> Ultimately, anything you do before pushing is up to you, as long as
> you don't push any merge commits. We've disabled force-pushing on all
> master branches, so you don't have to worry too much doing that
> accidentally.

That is to say, you don't have to worry about accidentally
force-pushing. You still have to avoid pushing merge commits.

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

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:01 PM, Eric A. Borisch  wrote:
> 
> Just so I'm clear on this, is the desired approach for each committer
> to:
> 
> == setup ==
> 1) clone macports/macports-ports to the local filesystem

After cloning, you should be sure that you are using your MacPorts email
address for commits. It's not the end of the world if you forget, but
the shorter our .mailmap files are, the better.

> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes

More or less. Ultimately, anything you do before pushing is up to you,
as long as you don't push any merge commits. We've disabled
force-pushing on all master branches, so you don't have to worry too
much doing that accidentally.

> 5) 'push' changes (to macports-ports)
> 
> Oh, and and to capture upstream changes, somewhere after 1 and before
> 5 (4? 3?),
> 
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too
> bad.

That's the idea, although you'll have to do this with a clean working
tree. That means committing or stashing your WIPs.

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

Removing "$Id$" lines

[Lawrence Velázquez]

Hi,

We no longer have use for "$Id" lines, so committers should remove them at 
their convenience.

vq

> On Oct 31, 2016, at 5:20 PM, Schamschula 
>  wrote:
> 
> Schamschula pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/eee819a1785e92bd2824517c0aff6ee855837c12
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new eee819a  libpcap: update to version 1.8.1.
> eee819a is described below
> 
> commit eee819a1785e92bd2824517c0aff6ee855837c12
> Author: Marius Schamschula 
> AuthorDate: Mon Oct 31 16:16:22 2016 -0500
> 
> libpcap: update to version 1.8.1.
> ---
>  net/libpcap/Portfile | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/net/libpcap/Portfile b/net/libpcap/Portfile
> index 6b8eb0d..201f2bd 100644
> --- a/net/libpcap/Portfile
> +++ b/net/libpcap/Portfile
> @@ -1,10 +1,10 @@
>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> -# $Id$
> +# $Id: Portfile 152274 2016-09-02 11:03:02Z m...@macports.org $
>  
>  PortSystem  1.0
>  
>  namelibpcap
> -version 1.8.0
> +version 1.8.1
>  categories  net
>  maintainers mps openmaintainer
>  license BSD
> @@ -17,8 +17,8 @@ homepagehttp://www.tcpdump.org/
>  platforms   darwin
>  master_sites${homepage}release/
>  
> -checksums   rmd160  4cfef07ac9f008b329c00bf0ebbe547f6738f2eb \
> -sha256  
> f47b51533f9f060afb304010ea5cbf51d032707333bca70c36351d255754659c
> +checksums   rmd160  295766ab2646c05c330aa04cabc30c5737200279 \
> +sha256  
> 673dbc69fdc3f5a86fb5759ab19899039a8e5e6c631749e48dcd9c6f0c83541e
>  
>  configure.args  --disable-bluetooth \
>  --disable-canusb \

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

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:23 AM, Marko Käning  wrote:
> 
> a post-commit-hook checking whether the GitHub pull request ID #123
> actually exists for the main repository seems like a valuable feature,
> especially in the transition phase. Shall I file a ticket on trac for it?

Sure, if you like. Feel free to assign me as owner; I'll try to look into it 
this week.

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

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 31, 2016, at 1:16 PM, Thibaut Paumard <thib...@macports.org> wrote:
> 
> Le 31/10/2016 à 17:23, Lawrence Velázquez a écrit :
>>> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard <thib...@macports.org> wrote:
>>> 
>>>> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
>>>>> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
>>>>> 
>>>>> This issue only affects the very small percentage of the MacPorts user 
>>>>> population (including developers and maintainers) that clones the git 
>>>>> repository. Most users will use the rsync server, on which we do generate 
>>>>> portindexes for each macOS version.
>>>> 
>>>> Of course, but note how I used the word collective, which was supposed to 
>>>> include the idea that portindex has to be run each time by every user. :)
>>>> 
>>> 
>>> I would actually believe the number of affected users should be between
>>> very small and zero.
>> 
>> Pretty much.
>> 
>> In any case, between the capabilities of Git itself and the facilities 
>> GitHub provides, I do not believe it is possible to do what you suggest.
> 
> You mean what René is suggesting?

Yes.

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

Re: Working with Git

[Lawrence Velázquez]

> On Oct 31, 2016, at 1:04 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
> Now you can check out the new branch and try out the submitter's
> changes. You can also modify the branch as you see fit.
> 
>   $ git checkout l2dy-curl-ca-bundle-update

Actually, if the rebase is successful, you'll automatically end up in
this branch and won't have to check it out yourself.

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

Re: Working with Git

[Lawrence Velázquez]

> On Oct 31, 2016, at 11:29 AM, Ryan Schmidt  wrote:
> 
>> On Oct 5, 2016, at 9:53 PM, Ryan Schmidt  wrote:
>> 
>> How will this work on GitHub?
>> 
>> The user will submit a pull request. How do I test it locally? What if the 
>> pull request is incomplete? I know I can tell the user what's wrong, and 
>> they can push another commit to the same branch they made to initiate the 
>> pull request, and those new commits will automatically appear in the pull 
>> request, and I can then merge it if I like it. But what if the user does not 
>> respond and fix the changes? What if the user makes additional commits but 
>> they're still not sufficient? How do I take the user's pull request, make 
>> additional changes, and commit them to our master?
> 
> There were several different and sometimes conflicting answers to this 
> question in this thread. Now that we have converted to git, and I have 
> received a pull request for one of my ports, I need to know how to test it 
> locally and then commit it to master. I don't want to understand git's theory 
> or to be given lots of options amongst which to choose; I just want to be 
> told how to get my work done.

Here are some rough instructions. These will have to be refined; let me
know if you have any problems. I'm writing this in a bit of
a sleep-deprived fog.

To the right of the big green "Rebase and merge" button on the PR page,
you should see a link to view "command line instructions". Those
instructions are almost what you want, but you'll have to tweak them to
avoid merge commits.

To obtain the submitter's changes:

$ git fetch https://github.com/l2dy/macports-ports.git 
curl-ca-bundle-update
$ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
$ git rebase master l2dy-curl-ca-bundle-update

The first command imports changes from the submitter's
"curl-ca-bundle-update" branch. The second command creates a new local
branch to match. The third command transplants the submitter's changes
onto the top of your master branch. (Rebasing will fail if the
submitter's changes don't apply cleanly to the current ports tree. You
can just ask them to fix this themselves and push a new branch.)

Now you can check out the new branch and try out the submitter's
changes. You can also modify the branch as you see fit.

$ git checkout l2dy-curl-ca-bundle-update

When you're ready to push the submitter's contributions to master:

$ git checkout master
$ git merge --ff-only l2dy-curl-ca-bundle-update
$ git push origin master

The first two commands incorporate the submitter's changes into your
master branch. The last one pushes to GitHub.

> Could someone please update the WorkingWithGit page with the correct 
> instructions?

Yes, I will polish up that page this week, as well as the migration FAQ.

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

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 31, 2016, at 12:16 PM, Thibaut Paumard  wrote:
> 
>> Le 31/10/2016 à 17:01, René J.V. Bertin a écrit :
>>> On Monday October 31 2016 10:00:05 Ryan Schmidt wrote:
>>> 
>>> This issue only affects the very small percentage of the MacPorts user 
>>> population (including developers and maintainers) that clones the git 
>>> repository. Most users will use the rsync server, on which we do generate 
>>> portindexes for each macOS version.
>> 
>> Of course, but note how I used the word collective, which was supposed to 
>> include the idea that portindex has to be run each time by every user. :)
>> 
> 
> I would actually believe the number of affected users should be between
> very small and zero.

Pretty much.

In any case, between the capabilities of Git itself and the facilities GitHub 
provides, I do not believe it is possible to do what you suggest.

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

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 31, 2016, at 7:12 AM, René J.V. Bertin  wrote:
> 
>> On Monday October 31 2016 11:52:28 Rainer Müller wrote:
>> 
>> rsync -vt 
>> rsync://rsync.macports.org/macports/release/ports/PortIndex_darwin_16_i386/PortIndex*
>>  $ports
> 
> Thanks for the suggestion, I might do that.
> 
> (Are you running 10.12 on a 32bit host? Is that even possible?)

The portindices are based on platform, not architecture. There are
indices for Intel and (for Tiger and Leopard) PowerPC.

-

% rsync 'rsync://rsync.macports.org/macports/release/ports/PortIndex*'

Willkommen auf dem RSYNC-server auf ftp.fau.de.
Nicht all unsere Mirror sind per rsync verfuegbar.

Welcome to the RSYNC daemon on ftp.fau.de.
Not all of our mirrors are available through rsync.


-rw-r--r-- 11,985,357 2016/10/31 08:31:49 PortIndex
-rw-r--r--509,450 2016/10/31 08:31:49 PortIndex.quick
drwxr-xr-x  4,096 2016/10/31 09:01:42 PortIndex_darwin_10_i386
drwxr-xr-x  4,096 2016/10/31 09:01:45 PortIndex_darwin_11_i386
drwxr-xr-x  4,096 2016/10/31 09:01:48 PortIndex_darwin_12_i386
drwxr-xr-x  4,096 2016/10/31 09:01:50 PortIndex_darwin_13_i386
drwxr-xr-x  4,096 2016/10/31 09:01:53 PortIndex_darwin_14_i386
drwxr-xr-x  4,096 2016/10/31 09:01:55 PortIndex_darwin_15_i386
drwxr-xr-x  4,096 2016/10/31 09:01:57 PortIndex_darwin_16_i386
drwxr-xr-x  4,096 2016/10/31 09:01:35 PortIndex_darwin_8_i386
drwxr-xr-x  4,096 2016/10/31 09:01:32 PortIndex_darwin_8_powerpc
drwxr-xr-x  4,096 2016/10/31 09:01:40 PortIndex_darwin_9_i386
drwxr-xr-x  4,096 2016/10/31 09:01:37 PortIndex_darwin_9_powerpc

-

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

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 30, 2016, at 9:54 PM, Clemens Lang  wrote:
> 
> MacPorts developers should now have commit access to the GitHub
> repositories.

A quick reminder about commit messages:

Old habits die hard, but from now on do NOT refer to Trac tickets as
"#12345" in your commit messages; GitHub's website interprets those as
pull request numbers. Copy and paste the full Trac URL instead.

vq

P.S. If you want to see something nifty, use this line in a commit that
resolves a ticket:

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

Re: GitHub migration complete

[Lawrence Velázquez]

> On Oct 30, 2016, at 9:54 PM, Clemens Lang  wrote:
> 
> Our Subversion repository has been split into several repositories on
> GitHub.

Please note that Ryan ran the svn2git conversion several times this
weekend, so any clones made previously will have nothing in common with
the final repositories, and a naïve "git pull" will try to produce
a merge commit. This is not desirable.

You should instead press the proverbial reset button. Assuming you made
a straightforward clone and only checked out a local master branch:

$ git fetch
$ git reset --hard origin/master
$ git gc --aggressive

This fetches the new history, forces your local master branch to match
ours, and garbage-collects the old objects.

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

Re: git fetch fails because of gnutls_handshake

[Lawrence Velázquez]

> On Oct 29, 2016, at 11:17 AM, René J.V. Bertin  wrote:
> 
> Does trac no longer auto-subscribe new participants? 

Our Trac has never automatically subscribed anyone except ticket
reporters. Owners and Cc need to be set explicitly. I don't know if
other projects do things differently.

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

Re: git fetch fails because of gnutls_handshake

[Lawrence Velázquez]

> On Oct 29, 2016, at 9:54 AM, René J.V. Bertin  wrote:
> 
> On Saturday October 29 2016 15:32:19 Clemens Lang wrote:
> 
> hi,
> 
>> That's https://trac.macports.org/ticket/51516.
> 
> Ah, thanks.
> 
>>> What could this be due to?
>> 
>> Your system libcurl is too old to talk modern SSL, or you have modified
>> your system libcurl to use a different library, or you have built
>> MacPorts against a custom copy of libcurl that uses a SSL library that
>> cannot talk to kernel.org.
> 
> Erm, I don't think so (3x if I count correctly). Pextlib is linked to the 
> system libcurl (and libssl) which I haven't modified, and the system curl 
> command (which uses that same library) works correctly. That's why I asked, I 
> have no clue how this can happen.
> 
> I haven't yet found any indication that the port process might be using the 
> OpenSLL library from port:openssl, or indeed any other related library.

What OS are you running? Have you set DYLD_LIBRARY_PATH or something else?

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

Fwd: [154314] trunk/dports/security/paperkey/Portfile

[Lawrence Velázquez]

Please do not commit version updates to my openmaintainer ports. I don't 
consider such changes "minor".

vq


> Begin forwarded message:
> 
> From: not...@macports.org
> Subject: [154314] trunk/dports/security/paperkey/Portfile
> Date: October 27, 2016 at 1:46:10 PM EDT
> To: macports-chan...@lists.macosforge.org
> Reply-To: macports-dev@lists.macosforge.org, not...@macports.org
> 
> Revision
> 154314 Author
> not...@macports.org Date
> 2016-10-27 19:46:10 +0200 (Thu, 27 Oct 2016)
> Log Message
> 
> paperkey: Update to 1.4
> Modified Paths
> 
> trunk/dports/security/paperkey/Portfile 
> 
> Diff
> 
>  <>Modified: trunk/dports/security/paperkey/Portfile (154313 => 154314)
> 
> --- trunk/dports/security/paperkey/Portfile   2016-10-27 16:22:34 UTC (rev 
> 154313)
> +++ trunk/dports/security/paperkey/Portfile   2016-10-27 17:46:10 UTC (rev 
> 154314)
> @@ -4,7 +4,7 @@
>  PortSystem  1.0
>  
>  namepaperkey
> -version 1.3
> +version 1.4
>  categories  security
>  platforms   darwin
>  license GPL-3+
> @@ -19,5 +19,5 @@
>  homepagehttp://www.jabberwocky.com/software/paperkey/ 
> 
>  
>  master_sites${homepage}
> -checksums   rmd160  b5849759b53ec55c39296b750cfafa5280248c03 \
> -sha256  
> 5b57d7522336fb65c4c398eec27bf44ec0aaa35926157b79a76423231792cbfb
> +checksums   rmd160  3a5c61a372b9442a0722e57f1aca5feaa43c7793 \
> +sha256  
> e12bb0ec835127d12a922a8d60b3dfdb3ca8ee60bb5b4d15ae4cea85bbcf336f
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org 
> 
> https://lists.macosforge.org/mailman/listinfo/macports-changes 
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Trac down again

[Lawrence Velázquez]

It’s back. I have seen this error a couple of times since the Trac migration.

vq


> On Oct 26, 2016, at 3:18 PM, Marius Schamschula  wrote:
> 
> Hmm.
> 
> Service Unavailable
> 
> The server is temporarily unable to service your request due to maintenance 
> downtime or capacity problems. Please try again later.
> 
> Apache/2.4.10 (Debian) Server at trac.macports.org 
>  Port 443
> 
> Wow. apache24-devel is @2.4.23, but then again the Debian folks back-port 
> patches to the old version rather than updating to the current version...
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
>> On Oct 26, 2016, at 2:13 PM, Marko Käning > > wrote:
>> 
>> Where is our trac again?
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org 
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
> 
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Lawrence Velázquez]

> On Oct 25, 2016, at 4:43 PM, René J.V. Bertin  wrote:
> 
> Where does one file tickets for trac?

In Trac.

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

Re: "Failed to open portfile from registry" while reinstalling because of configure.optflags

[Lawrence Velázquez]

> On Oct 25, 2016, at 1:17 PM, René J.V. Bertin  wrote:
> 
> I've looked into putting the offending statement (`$workername eval set 
> user_options($opt) $val`) in a loop, something like
> 
> $workername eval set user_options($opt) ""
> foreach v $val {
>$workername eval set user_options($opt) "$user_options($opt) $v"
> }
> 
> but I haven't gotten that right yet.

I haven't looked at the offending code, but I can tell you that this
approach is inherently flawed and cannot work robustly. The issue is
unwanted double substitution; the solution must prevent this, not work
around it.

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

Re: Git tools for managing patchsets

[Lawrence Velázquez]

> On Oct 24, 2016, at 7:03 PM, Michael  wrote:
> 
>> On 2016-10-24, at 2:57 PM, Marko Käning  wrote:
>> 
>> Well, but I think what you, Michael, are describing, is only needed
>> if you work with many patches which aren’t really committed to any
>> repository.
> 
> Actually, it's something else. It's the tracking of the history of
> changes when those changes get rebased.

The history is tracked by the MacPorts repository.

> This is not about the port files; those work just fine. This is about
> the patchsets needed to port a program to OS X.

There is no difference.

> If I have a set of patches to port version 1 of a program to OS X,
> what happens when version 2 of the program comes out?

The maintainer adjusts the patches for v2, adds some new ones, removes
ones that are no longer needed, and commits the new set of patches to
the repository. No history is lost.

> If you just rebase the patches onto version 2's code, then there is no
> connection between the patches for v1 and v2

Yes, there is. They are linked by the MacPorts repository history.

> there's no good way to compare how your patches for version 1 compared
> to the patches for version 2, or version 3. Etc.

Diff between the commit that updates the port to v2, and its immediate
parent.

> The answer is, that there are now two good methods for doing this. Git
> for Windows has one method (in fairness, I did not understand it, it
> seems mostly manual, but has been developed/improved over years), and
> the just-released git-series has a second one (based around extensions
> to normal git commands).

Not seeing how either of those tools applies to us.

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

Re: Git tools for managing patchsets

[Lawrence Velázquez]

> On Oct 24, 2016, at 5:57 PM, Marko Käning  wrote:
> 
> The only question mark I have there is:
> 
>   Will we ask the committers to squash their changesets or prefer
>   to clutter the main repo with potentially many tiny iterations
>   for the changed ports??
> 
> Personally I don’t like history rewriting, but a squash every now and
> then seems fine to me, as an update to a port sometimes requires a few
> iterations until it is ready for pushing to the central repo and it is
> usually one logical unit deserving an atomic commit.

I would encourage committers to learn how to rewrite history and then
edit pull request branches as they see fit before rebasing them onto
master. Don't assume that contributors will submit logical commits with
polished messages. Even now, I break all but the simplest Trac patches
into multiple commits.

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

[Lawrence Velázquez]

> On Oct 24, 2016, at 1:58 PM, Clemens Lang  wrote:
> 
> I don't think we should mandate a complex "run these magic git commands"
> workflow. Making things complicated will just make them go wrong.

Agreed.

>> On Mon, Oct 24, 2016 at 07:47:18PM +0200, Mojca Miklavec wrote:
>> 
>> (My preference would be to keep linear history for master and not to
>> keep ten broken revisions of a Portfile resulting from stepwise
>> improvements in a pull request, but it would be nice to do some
>> testing first.)
> 
> Yes, that's also my preference. So we can agree on:
> - rebase when merging PRs
> - rewrite history on PR branches until it looks good

+1 to both (so +2, I guess?). We want to avoid merge commits, and we
want the history that is ultimately added to master to be clean and
understandable. The precise method of achieving this (squash merging,
interactive rebasing, etc.) is not really important.

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

[Lawrence Velázquez]

> On Oct 24, 2016, at 2:00 PM, Vincent Habchi  wrote:
> 
> I’ve bought Coda 2 when I use to do a bit of HTML development. Can
> I use it to check out - tinker with the new MacPorts GIT repository?

You can use any Git client you like, as long as you're aware that we'll
effectively be trashing the current repository soon. So don't get too
attached to it!

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

[Lawrence Velázquez]

> On Oct 24, 2016, at 12:50 PM, Mojca Miklavec  wrote:
> 
>> On 21 October 2016 at 20:12, Clemens Lang wrote:
>> 
>> Action Required: GitHub Accounts
>> 
>> Our new Trac installation will use GitHub for login. If you do not have
>> a GitHub account yet, please create one now at
>> https://github.com/join
>> 
>> To help us match your previous contributions and Trac tickets to your
>> GitHub account, please go to
>> https://github.com/settings/emails
>> and ensure that you have added and verified all email addresses you have
>> used for MacPorts Trac.
> 
> Is that true also for any other email we used prior to becoming
> committers?

Yes.

> Can new emails be added later?

Yes. If you add a new address to your GitHub account later, you should
sign out of Trac. When you sign back in, references to that new address
will be switched over within minutes. (That is to say, the migration
occurs continuously and not just when you create your NewTrac account.)

> How exactly does it work when people enter multiple emails? (Judging
> from, say #37017, I guess that whenever I was assigned as the owner of
> the ticket with my old pre-committer-email, that would now be replaced
> with my github handle.)

That's right. Your NewTrac account takes over references to all email
addresses listed on your GitHub account.

> (not?) related to the above question: One thing I'm confused about is
> that whenever I'm listed as a reporter or in CC, my name would be
> replaced by all the three data (my macports handle, my full email, my
> github account), while the tickets where I'm the owner only contain my
> macports email. Tickets where the owner has been assigned later
> contain full info about that owner. I didn't investigate too closely
> yet.


Can you provide some examples? In all three situations (reporter, owner,
Cc), I see only my GitHub username and real name. Likewise, for users
who have created a NewTrac account, I see only their GitHub username and
optional real name. (If they haven't created an account yet, their email
address is listed.)

> May I suggest creating a clone of the port repository on GitHub (in
> whatever state it is now) and let it serve as a playground for testing
> different strategies of pushing, using pull requests, merging,
> properly rebasing, merging several commits of a pull request together,
> editing pull requests by non-committers (when a pull request needs
> just a tiny bit of fixing: will that be one commit or original commit
> + edits by "committer"), ...
> 
> It would help a lot if we had at least some idea how we want to
> proceed after the official switch. And some "grace period" to test
> what we want to do and what we want to avoid. Some playground for
> people that are new to git & and github wouldn't hurt either.

I'm not sure it's necessary to host such a sandbox repository in the
macports organization. The "macports-ports" repository
(https://github.com/macports/macports-ports.git) already contains
a stale version of the ports tree; you can fork it and play around with
it as you wish.

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Lawrence Velázquez]

> On Oct 23, 2016, at 6:04 PM, Fred Wright  wrote:
> 
>> On Sun, 23 Oct 2016, Clemens Lang wrote:
>> 
>>> On Sun, Oct 23, 2016 at 11:25:52AM +0200, René J.V. Bertin wrote:
>>> 
>>> I noticed it for Trac (which isn't a complete improvement *). I'm not
>>> aware that git allows pulling only changes to a single subdirectory
>>> like svn does (svn up in a port dir. to update only that port, for
>>> instance). Does it?
>> 
>> No it doesn't. It's something you'll have to live with.
> 
> Actually it does.  You can do:
> 
>   git checkout  -- 

This procedure is equivalent to editing all the content in the
subdirectory to match the contents of the specified treeish (optionally
adding it to the index), and Git has about as much awareness of what
you're doing as if you'd literally made all the changes by hand. It is
nothing like Subversion's selective subdirectory updating (where
revisions are tracked on a per-subdirectory basis), and suggesting that
it is will just court more confusion.

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Lawrence Velázquez]

> On Oct 23, 2016, at 5:25 AM, René J.V. Bertin  wrote:
> 
>> On Sunday October 23 2016 02:21:02 Marko Käning wrote:
>> 
>> I guess we can wait committing those once the new GitHub workflow is
>> in place, because it would make reviewing all the changes much
>> easier in a GitHub’ish pull request. :)
> 
> SVN is being retired completely?

GitHub provides a Subversion bridge if you wish to use it, but I don't
know if we'll support doing so. Our workflow will be Git-focused.

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Lawrence Velázquez]

> On Oct 23, 2016, at 3:59 AM, Chris Jones  wrote:
> 
> So... you are saying you would take these collections, and instead of
> grouping them together scatter them around in the other directories,
> like 'science' etc., depending on what sort of functionality they
> provide ? I think that would be much worse, sorry.

Would I prefer that they be organized the way all the other ports are
already organized? Yes. Our current inconsistent hodgepodge is the worse
of all worlds.

Would I push to reorganize them at this point? No. It's not worth the
effort.

> I also question would these directories are really for, users or
> developers ? I don't think users really get much exposure to them,
> they don't really have much bearing on how users find and install
> ports. For me, its more for the developers, so we should be flexible
> in how they are grouped depending on what makes sense to whoever is
> maintaining them.

Users are exposed to them insofar as a port's primary category
corresponds to the directory it's stored in. Do users use categories?
I don't know.

As a developer, I don't even bother looking at the location of ports
because the organization of the ports tree is so inconsistent.

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

Re: port:qt5 and (proposed) port:qt5-kde cohabitation

[Lawrence Velázquez]

> On Oct 22, 2016, at 8:08 PM, Marko Käning  wrote:
> 
> in the light of the upcoming commit of the new 'qt5-kde' port I want
> to ask (again) whether it would be acceptable, that we - for the sake
> of housekeeping - store all KF5-related ports in a dedicated folder at
> 
>dports/kf5
> 
> or whether it is really necessary, that all these KDE ports have to
> live under
> 
>dports/kde
> 
> just like all those port files belonging to KDE 3 and 4?

Why should KF5 get its own category? It's not special.

> - and both port collections having independent maintainers (Nicolas
> and René)

This has no bearing on anything.

> it would make maintenance easier if one kept also their storage
> locations separate, no?

I don't see why separating them would make anything easier. It's not as
if there's any namespacing going on. The ports would still have to have
unique names.

> Are there other reasons of not going for such an approach which we up
> to now aren’t aware of, perhaps?

I think having top-level directories based on implementation details
like language or framework are silly and pointless from a users'
perspective, and we should not add anymore of them.

(No, I don't like the top-level "java", "php", "python", etc.
directories, either.)

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

[Lawrence Velázquez]

> On Oct 22, 2016, at 9:40 AM, Marko Käning  wrote:
> 
>> On 22 Oct 2016, at 15:34 , Ryan Schmidt  wrote:
>> 
>> as well as the "hub" command line program in the "hub" port.
> 
> Exactly, that’s the one I meant. Perhaps it’s worth mentioning it on the
> wiki page.

I've added several tools to the list since last night. Further
suggestions are welcome.

https://trac.macports.org/wiki/WorkingWithGit#tools

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

[Lawrence Velázquez]

> On Oct 21, 2016, at 10:20 PM, Craig Treleaven  wrote:
> 
> However, would it be possible to add a tangible example of updating
> a port to that page?  
> 
> I know a little bit about Subversion and less about Git.  I would like
> to see a soup-to-nuts example of cloning the ports tree, updating
> a Portfile, maybe deleting an old patch and adding a new one, and
> getting the updated port into MacPorts (direct commit v. pull
> request).  It would be helpful if one-time requirements (setting name
> and email address) were clearly separated from repetitive steps
> (pulling changes from master?).  Otherwise, it is going to be a wee
> bit nerve-wracking the first few times...

This would be good.

> Also, is the consensus that a graphical user interface over git more
> likely to be harmful than helpful?  The Tools section at the bottom of
> the page doesn’t give any kind of recommendation.

I don't know that there is any sort of consensus on that. Everyone has
their own preferences, and Git is almost absurdly flexible about
workflows. I don't think our documentation should recommend any
particular tools. 

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

Re: [152490] contrib/buildbot-test

[Lawrence Velázquez]

> On Oct 20, 2016, at 6:58 PM, Ryan Schmidt  wrote:
> 
> Are the passwords then a separate entry?

I overlooked passwords; I'll have to chew on that.

> I had planned to put the guide-building and www-fetching and
> ports-sql-updating and distfiles-fetching and rsync-server-updating
> tasks on the buildbot master, rather than on any of the existing
> buildbot workers that are building ports and base, because the
> existing workers are often quite busy, while the master is just
> sitting there doing largely nothing.

That makes sense.

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

Re: foo-snapshot / foo-diff convenience functions

[Lawrence Velázquez]

> On Oct 20, 2016, at 4:25 PM, René J.V. Bertin <rjvber...@gmail.com>
> 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 ...

Nonsense. There's plenty of functionality currently implemented in
portfiles that would make no sense in base.

> I won't be reinventing all kinds of wheels to delay updating
> dependency declarations beyond checking for the presence of a token
> when the portgroup is being read.

¯\_(ツ)_/¯

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

Re: Trac down?

[Lawrence Velázquez]

> On Oct 20, 2016, at 2:47 PM, Vincent Habchi  wrote:
> 
>> On 20 Oct 2016, at 20:44, Rainer Müller  wrote:
>> No, this downtime is not intentional or planned.
> 
> Yeah, I get that, but I mean: so nothing has changed yet: SVN is still 
> supposed to work the way it always did (at least to my knowledge).

Right.

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

Re: foo-snapshot / foo-diff convenience functions

[Lawrence Velázquez]

> On Oct 20, 2016, at 3:40 AM, René J.V. Bertin  wrote:
> 
>> On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote:
>> 
>> No, that situation should not be common, nor indeed present at all.
> 
> I'm not sure I agree. PortGroups are intended to take care of setting
> up things for the ports that use them (like declaring a dependency in
> such a way ports work with the main as well as the -devel port), and
> even an official one like the github PG adds dependency info. Ditto
> for the Python PG: you cannot (to my knowledge) include it just to
> obtain the variables that provide the python paths without also
> redefining the configure mechanism.
> 
> You could claim that it should be uncommon that ports want only part
> of the info a PG provides, but even that might not be relevant as
> I think there are quite a few ports providing Python extensions but
> that don't use Python's own configure/build/install mechanism (PyQt
> and PyKDE come to mind).

This is arguably a defect of python-1.0 that should be fixed in the
portgroup.

>>> For instance, a port providing translation files for a KDE port
>>> would probably need to include a KDE PortGroup but doesn't need to
>>> depend on Qt.
>> 
>> I haven't looked at the kde portgroup specifically. Maybe the
>> portgroup needs additional options to handle different types of
>> ports (e.g. libraries vs. translation files), or maybe there need to
>> be separate portgroup.
> 
> Well, that's indeed what I've ended up doing with KF5, but there it's
> justified because of the sheer number of dependency variables (over 30
> frameworks). The Qt PGs on the other hand define a considerable number
> of relevant variables but also add a single dependency to depends_lib.
> I don't think it's really justified to put just that in a separate PG.
> For that I'd rather add a switch to the PG, a variable to define
> before including it in order to deactivate something.
> 
> Maybe it would be possible to make that latter approach a bit more
> elegant, somehow merging those variable declarations into the
> PortGroup syntax?

It is already possible to create options that enable/disable portgroup
behavior after the portgroup is included. The python-1.0 and php-1.1 do
this quite a bit. There is no need to muck up the inclusion syntax.

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

Objection to restoring deprecated Python subports

[Lawrence Velázquez]

Fred Wright recently opened several tickets that suggest restoring
several Python subports that were deprecated and moved to the Python
graveyard a long time ago.

https://trac.macports.org/ticket/52636
https://trac.macports.org/ticket/52637
https://trac.macports.org/ticket/52638
https://trac.macports.org/ticket/52639
https://trac.macports.org/ticket/52640
https://trac.macports.org/ticket/52641
https://trac.macports.org/ticket/52642

I strenuously object to these proposals.

A few years ago, I proposed a Python subport/variant policy to reduce
project-wide support load. That policy was that we should only provide
subports for the two most recent Python versions on each of the 2.x and
3.x branches (modulo some details about termination of upstream
support).

Thanks to the efforts of many contributors, that proposal has been
mostly carried out. We absolutely should not be going backwards on this.

Users who wish to work with unsupported versions of Python should use
virtualenv to create a contained environment in which they may use the
bundled pip, setuptools, and wheel to install any modules they please.
The deprecated subports would have to be restored to the virtualenv and
setuptools ports; I'd be fine with this.

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

Re: advanced bash-ing for long compiles

[Lawrence Velázquez]

> On Oct 14, 2016, at 10:50 AM, Ken Cunningham 
>  wrote:
> 
> I notice mdworker seems to go nuts during these long builds, often appearing 
> to soak up lots of cycles. I assume it’s trying to index all the build files, 
> etc
> 
> is it easy to sleep that function and then re-enable it after the compile is 
> done?

You should just stop Spotlight from indexing your MacPorts prefix at all
(System Preferences > Spotlight > Privacy).

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

Re: advanced bash-ing for long compiles

[Lawrence Velázquez]

> On Oct 14, 2016, at 10:30 AM, Ken Cunningham 
>  wrote:
> 
> long compiles can take hours
> 
> i can ssh into the machine and get it started
> 
> sudo port -v install gcc48 gcc5 gcc6 gcc7
> 
> that, for example, might take several days to finish (if it does
> finish)
> 
> then I control-Z to pause it, and "bg" to throw it into the background
> 
> then I can close my ssh session and the compile proceeds...
> 
> how exactly do I best find that process to "fg" it again? If I just
> log back in and "fg" it, it is not found. but top shows the process is
> humming away in the background, as expected

You can't bring that process back into the foreground because it is no
longer under any shell's job control because you terminated its
controlling shell by exiting the ssh session.

http://mywiki.wooledge.org/BashGuide/JobControl

> is the process different from a local shell vs a remote shell?

There's no real distinction between a "local" shell and a "remote"
shell.

> is this all wrong, and it's way better to use screen or tmux or ???

Yes. Save yourself the headache.

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

Re: trac down?

[Lawrence Velázquez]

> On Oct 14, 2016, at 8:55 AM, René J.V. Bertin  wrote:
> 
> I cannot connect to trac but the main site works fine. Is there a problem 
> with the server?

I have not been able to reach it since last night (~12 hours ago).

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

Re: Documentation overhaul

[Lawrence Velázquez]

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

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

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

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

I agree that our portgroup documentation is especially weak.

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

Re: Documentation overhaul

[Lawrence Velázquez]

> On Oct 9, 2016, at 7:23 PM, Ryan Schmidt  wrote:
> 
> 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.

+1

> 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.

A lot of our process will be changing very shortly. It's probably a good
idea to hold off for a bit.

> I like markdown but it is missing a lot of things. There is an opinion
> piece I found online about who you should never try to write
> documentation using markdown for this reason.

One problem with Markdown vis-à-vis documentation is that it was
specifically designed to be transformed into HTML. That is why it
permits inline HTML and does not try to do everything in syntax; the
intention was that complex content be written in raw HTML.

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

Re: Epiphany requires gnupg and does not accept gnupg21?

[Lawrence Velázquez]

> On Oct 8, 2016, at 3:33 PM, Johannes Kastl  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Dear all,
> 
> while trying to upgrade my gimp2 port today, I stumbled upon
> epiphany throwing this error:
> 
>> sudo port install epiphany --->  Computing dependencies for
>> epiphany Error: Unable to execute port: Can't install gnupg
>> because conflicting ports are active: gnupg21
> 
> Is this a known issue?

That would be gcr, not epiphany.

% port echo depends:gnupg and rdepof:epiphany
gcr

gnupg and gnupg21 conflict so that users don't run into unexpected
behavior switching back and forth [1]. I'm not really sure what the best
way of remedying this is.

[1]: https://trac.macports.org/ticket/45856#comment:3

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

On Oct 8, 2016, at 6:34 AM, Ryan Schmidt  wrote:

> It seems counterproductive to me to close a ticket if you're not addressing 
> the issue. Just because nobody has done anything with a ticket for 6 months 
> or 2 years or whatever period of time doesn't necessarily mean that the issue 
> is no longer valid, just that nobody has had time to deal with it yet.

It would be nice if there were a third state between "open" and "closed" for 
this.

(Then again, "it would be nice" if tickets just fixed themselves, so….)

> When I go searching for tickets, I don't typically search for closed tickets, 
> because I assume that closed tickets are closed because they've been dealt 
> with. If we change that rule now, it will mean that I either don't find 
> tickets that might have been relevant to whatever I'm searching for, or that 
> I have to remember to search for closed tickets and spend a lot of time 
> sifting through tickets that have already been dealt with.

This would be difficult even with a "lack-of-interest" keyword, now that you 
mention it. Today we can search for tickets that are (!closed AND [other 
conditions]). If we start closing stale tickets, one would have to search for 
tickets that are (!closed OR (closed AND keyword ~ lack-of-interest)) AND 
whatever other conditions you care about.

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 3:24 PM, Ken Cunningham  
> wrote:
> 
>> On 2016-10-07, at 10:05 AM, Rainer Müller wrote:
>> 
>> I am not sure how we could change these to make triaging trickets
>> easier.
> 
> I can't easily just look at the list and see what are new requests for
> ports to be included in macports. It all mixed in with other things.

You can use a Trac query for this:

https://trac.macports.org/query?status=!closed=request=ports

The Tickets page [1] on Trac has links for several such queries, there is
a list of various Trac reports [2], and you can construct a custom query
if you need to [3]. 

It might be useful to add more query links to the Tickets page.

[1]: https://trac.macports.org/wiki/Tickets
[2]: https://trac.macports.org/report
[3]: https://trac.macports.org/query

> Like Ryan said, I'd have separate queues for each major
> category..

That's not really what Ryan said. He was just pointing out that our
current selection of ticket types is inconsistent, not that we should
add a bunch more.

> let's see -- 
> 
>   new incoming port requests that anyone could claim - port that
>   don't exist in macports at present

https://trac.macports.org/query?status=!closed=request=ports=macports-tickets%40lists.macosforge.org

>   new portfiles that have been finished and are awaiting committer
>   review

https://trac.macports.org/query?status=!closed=submission=ports

>   requests for updates to existing ports by people who have
>   noticed something out on the web of significance.

https://trac.macports.org/query?status=!closed=update=ports=!~haspatch

>   port updates with patches (approved by maintainer if there is
>   one) waiting for committer review

https://trac.macports.org/query?status=!closed=update=ports=~haspatch

>> Requests for new ports could still be valid after years. This list
>> could be helpful for newcomers that want to create new ports.
> 
> Totally agree - but I'd close everything over six months old or
> something like that for optics. People can still search to "closed"
> tickets if they want.

I think we have a collective hoading instinct w.r.t. tickets. (Don't
close that ticket! I might work on it one day. Really.) Perhaps we could
be more bold about closing tickets with Rainer's "lack-of-interest"
keyword, while making it easy to find all such tickets.

https://trac.macports.org/query?status=closed=~lack-of-interest

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

Re: Working with Git

[Lawrence Velázquez]

> On Oct 7, 2016, at 6:56 PM, Rainer Müller  wrote:
> 
> 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.

I think this would be fine, since only a few people are likely to fetch a pull 
request branch, and anyone who does just has to be aware that the branch can be 
force-updated at any time.

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 2:58 PM, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
> wrote:
> 
>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>>> On Oct 7, 2016, at 2:09 PM, Chris Jones <jon...@hep.phy.cam.ac.uk> 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.
> 
> 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.

We will not be migrating to GitHub Issues in its current form. Several
of us (not me) have already evaluated it as a possible Trac replacement
and concluded that it is insufficient for our needs.

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> 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.

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

Re: Patch naming policy

[Lawrence Velázquez]

> On Oct 6, 2016, at 12:04 PM, Rainer Müller  wrote:
> 
> On 2016-10-06 13:56, Mojca Miklavec wrote:
>> I don't care if we use *.diff or *.patch. Either is fine, but I would
>> prefer if we would stick to one ending and try to be as consistent as
>> we can be.
> 
> Some statistics on consistency:
> 
> $ find dports -name '*.diff' |wc -l
>4922
> $ find dports -name '*.patch' |wc -l
>1079
> $ find dports -name '*.diff' -exec basename {} \; |grep -c -v '^patch-'
> 324
> 
> Especially when maintainers use patches from 'git format-patch' they
> often end up with *.patch.

I'm not sure that we have to mandate one extension, but if we do,
I would prefer ".patch", which I feel implies intent to modify, as
opposed to merely describing a difference.

"Did you just make that up? And aren't those just two sides of the same
coin?"

Correct on both counts, imaginary collaborator.

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 1:23 PM, Marcel Bischoff  wrote:
> 
> On 16/10/07, Guido Soranzio wrote:
> [...]
>> I really hope that the migration of MacPorts to GitHub will trigger a
>> collaboration between the two communities at last.

How would our switching to GitHub facilitate this at all? We still will
not be able to share code in any meaningful way (other than patches,
which we already do sometimes). Just because I will be spending more
time on github.com doesn't mean that I'm going to start wandering over
to github.com/homebrew.

> That would be swell, indeed. Although I can't shake the feeling that it
> could be a clash of cultures. Kind of like old school coders vs.
> hipsters. ;)

My eyes bleed every time I look at a Homebrew formula. True story.

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

Re: Of C++ (and other) runtimes

[Lawrence Velázquez]

> On Oct 7, 2016, at 11:59 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Friday October 07 2016 11:43:48 Lawrence Velázquez wrote:
> 
> [was Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because
> of using libstdc++]
> 
>> it might be useful to refine this mechanism to allow something like
>> "configure.compiler.cxx macports-gcc-XYZ", which would add a direct
>> library dependency on libgcc (among other things).
> 
> Yep, that sounds like a good idea, but can that not be handled by the
> existing configure.cxx syntax?

The "configure.cxx" option is meant to directly set the CXX environment
variable for the configure stage. Technically it is possible to add
traces to it to add dependencies automatically, which would be the
inverse of what we currently do (explicitly specify the compiler
collection and update configure.* accordingly). That might be fragile,
though.

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

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

[Lawrence Velázquez]

> On Oct 7, 2016, at 11:11 AM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
> On Friday October 07 2016 10:51:59 Lawrence Velázquez wrote:
> 
>> Not to mention the fact that literally every single C++ port would have
>> to declare a library dependency on libgcc.
> 
> Or not: if a compiler selection mechanism is used that picks
> a macports-gcc version that dependency would be added indirectly, no?
> I'd find it more intuitive to invoke such a mechanism than declare
> a dependency on something we're used to take for granted...

Currently, if you set "configure.compiler macports-gcc-XYZ",
a dependency on gccXYZ is added automatically. A direct dependency on
libgcc is not added because we don't know what the port wants to use gcc
for. It currently works out because gcc* already depends on libgcc, but
the dependency tree is not actually correct.

The current mechanism for adding these dependencies is coarse. It
considers each of Clang / GCC / DragonEgg (RIP) to be a sort of compiler
collection and assumes that ports aren't going to mix and match. There
are many ports that do in fact mix and match (notably for Fortran), so
it might be useful to refine this mechanism to allow something like
"configure.compiler.cxx macports-gcc-XYZ", which would add a direct
library dependency on libgcc (among other things).

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

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

[Lawrence Velázquez]

> On Oct 6, 2016, at 10:48 AM, Mojca Miklavec  wrote:
> 
> On 6 October 2016 at 16:23, René J.V. Bertin wrote:
>> 
>> Ken: apologies for not having thought of this, but myself when I was still 
>> running 10.6 I've had sufficient success with building C++11 code using a 
>> (then) recent gcc port.  It's possible that things have evolved so much 
>> nowadays that even that may not cut it anymore.
> 
> This would probably mostly work fine if *all* ports were built with
> g++ (= against the same version of mp-provided stdlibc++). I can
> easily imagine problems when gcc is switched from, say, version 5 to
> version 6, but let's ignore that for a moment.
> 
> The problem is that MacPorts cannot easily support a zillion of
> different configurations and this is certainly an unsupported one.
> 
> Some of the ports that require C++11 currently blacklist all the gcc
> compilers and enforce libc++. Not because gcc would not be able to
> build it, but to ensure at least some consistency. So if you want to
> use this configuration, you need quite a bit of editing of different
> ports, say goodbye to binary packages, expect other random problems.
> 
> I'm not saying that this cannot work. Just that it calls for random
> headaches that one has to willingly accept and be able to fix on
> him/her own. (Or maintain a fork of MP with a monstrous amount of
> work.)

Not to mention the fact that literally every single C++ port would have
to declare a library dependency on libgcc.

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

Re: dbusmenu-qt5 build failure on 10.7 and 10.8 buildbots because of using libstdc++

[Lawrence Velázquez]

> On Oct 6, 2016, at 12:49 PM, René J.V. Bertin  wrote:
> 
>> On Thursday October 06 2016 12:32:24 Brandon Allbery wrote:
>> 
>> now. At my previous job, when we ran into this we just lifted the whole
>> thing to glue multiple g++ releases to a common libstdc++ from Debian
>> (clang / libc++ wasn't an issue back then).
> 
> Sounds like something to be considered for the gcc ports, then ;)

All the gcc* ports (the recent ones, anyway) already use the single C++
support library installed by the libgcc port.

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

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

[Lawrence Velázquez]

> On Oct 4, 2016, at 7:45 PM, Ryan Schmidt  wrote:
> 
>> On Oct 4, 2016, at 3:58 PM, Rainer Müller  wrote:
>> 
>> Patches should follow the patch-*.diff naming scheme, so this should be
>> named patch-skeyprune-man8.diff or similar.
> 
> 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".

"patch-" and ".diff" are effectively synonymous, so I don't see any reason to 
include both in a single patch name, as it's redundant and makes every patch 
name longer. Plain "*.{patch,diff}" should be sufficient.

vq
Sent from my iPhone

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

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

[Lawrence Velázquez]

> On Oct 4, 2016, at 7:05 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
> But that day is not today. https://trac.macports.org/changeset/153579

I meant this, obviously.
https://trac.macports.org/changeset/153576

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

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

[Lawrence Velázquez]

> On Oct 4, 2016, at 4:58 PM, Rainer Müller  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

One day I'll get this naming guideline changed, if it's the last thing I do.*

But that day is not today. https://trac.macports.org/changeset/153579

vq







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

Re: Dual g++ ABI in libraries --- how to handle it?

[Lawrence Velázquez]

> On Oct 3, 2016, at 10:42 PM, Brandon Allbery 
> wrote:
> 
>> On Mon, Oct 3, 2016 at 10:35 PM, Alexander Gaenko 
>> wrote:
>> 
>> This situation could be remedied by using Boost variant compiled
>> with the "new" ABI --- however, there seems to be no such variant in
>> the Boost port.
> 
> What OS X / macOS version? Boost should build with whatever the
> default C++ ABI is, which will be pre-C++11 on 10.8 and older; see
> https://trac.macports.org/wiki/LibcxxOnOlderSystems for how to change
> this (it is much, much more involved than just rebuilding boost ---
> changing C++ ABI is not trivial at all, and it is all or nothing ---
> otherwise nothing can trust any other libraries to be compatible).

Furthermore, Boost (and all other MacPorts C++ software) uses the system
C++ runtime, while anything compiled with g++ from the gcc* ports uses
the C++ runtime from the libgcc port. For this reason, we strongly
discourage (one could say "ban") the use of gcc* for C++ ports.

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

Re: ${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Oct 2, 2016, at 4:47 AM, René J.V. Bertin <rjvber...@gmail.com>
> wrote:
> 
>> On Saturday October 01 2016 20:55:57 Lawrence Velázquez wrote:
>> 
>> So what happens when a port-installed Launch{Agent,Daemon} is loaded
>> before the one that mounts the entire MacPorts prefix?
> 
> A priori they won't if their plists are symlinks into ${prefix}.
> Something similar happens when your prefix sits on another volume. Or
> used to happen to me at some point; launchd simply deferred loading
> the plists in question as far as I've ever able to tell.

I forgot that we generally link the launchd stuff. I guess that's…
something. Seems like it would be better to mount the image before
launchd does anything, if possible.

> Actually, making a prefix load through a lauchd agent means all
> launchd agents and daemons under that prefix can the OtherJobEnabled
> key to signal that they depend on the prefix job.

OtherJobEnabled is fragile because it only ensures that the other job is
loaded, not whether the condition we care about is met (in this case,
whether the contents of the image are mounted and available).

>> We don't really support dedicated partitions either, other than
>> making sure that symlinks resolve properly.
> 
> What's there to support about a dedicated partition that's mounted on
> /opt/local?

Nothing, if the user sets it up themselves. That's fine, and anyone who
wants to experiment is welcome to do so. This is already our position on
replacing various bits of the prefix tree with symlinks elsewhere.

On the other hand, offering it as an install-time option would at
a minimum involve adding code to the build system and helping users with
any issues that might arise. (You probably don't think there would be
any issues. Users are very good at finding issues.)

> Either way, much as I like this idea I didn't expect for minute that
> it would receive a very warm welcome. OK, I kind of expected I'd get
> at least 1 "yeah, that'd be cool" kind of reaction, but I probably
> should have known better.


Don't get me wrong; it's a neat idea. Might even be worth writing up
a wiki page for anyone else who's interested in such a setup (with
healthy doses of caveat emptor).

> Thing is that some of the aspects I find appealing won't apply to me
> anyway; unmounting the image will be complicated for instance as
> I have my login shell set to one installed through MacPorts (tcsh).


I once made the mistake of removing MacPorts from a long-dormant 10.5 or
10.6 VM, intending to start over from scratch, forgetting that my login
shell was /opt/local/bin/zsh. Didn't realize it until Terminal.app and
ssh started failing. Ended up creating a new admin user to fix it with
chsh and making my zsh startup files compatible with 4.x so I didn't
have to install a new zsh on old systems. Good times.

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

Re: ${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Oct 1, 2016, at 4:33 PM, René J.V. Bertin 
> wrote:
> 
> The attach command can be put in a "RunAtLoad" launchd plist in
> /Library/LaunchAgents, to avoid having to mess with /etc/fstab .

So what happens when a port-installed Launch{Agent,Daemon} is loaded
before the one that mounts the entire MacPorts prefix?

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

Re: ${prefix} as a disk-image (was: #49559: nepomuk-core can't be installed on a case-sensitive system)

[Lawrence Velázquez]

> On Oct 1, 2016, at 7:19 PM, René J.V. Bertin 
> wrote:
> 
>> On Saturday October 01 2016 23:13:25 Clemens Lang wrote:
>> 
>> People can already do that. People can also mount a different
>> filesystem at /opt/local. I just don't think that should be our
>> default setup.
> 
> I'm not saying it should be, this is just an idea for something that
> could be optional. It shouldn't be too difficult to provide as an
> option in an installer; the same cannot be said about other ways to
> mount a different filesystem at /opt/local.

Non-default configurations need to be compelling enough that base
developers are willing to develop, test, use, and support them on an
ongoing basis. I have a hard time believing that that condition would
hold here.

>> Sparse Bundles have the huge downside that they don't shrink
>> automatically. Yes, there are methods to shrink them, but that's
>> extra work and extra code.
> 
> I thought about that, but just how often does a typical MacPorts
> installation *shrink*? Look at it from the opposite side: with
> a sparse bundle you *can* shrink the size it takes up on shared disk
> space, something that's much less trivial if you use a dedicated
> partition for instance.


We don't really support dedicated partitions either, other than making
sure that symlinks resolve properly.

>> Additionally, I'd leave such a fundamental decision to Apple.
> 
> I don't see how this would be a fundamental decision that should be
> taken by Apple. They're supposed not to have any say over MacPorts at
> all.

They are the platform vendor. Every decision they make affects us.

The point is that case sensitivity is by and large a non-issue for us,
so our efforts are better spent accommodating the default filesystem —
whatever it is — rather than defying it in such a drastic manner.

>>> I also like the idea of being able to take the whole MacPorts tree
>>> offline with a simple command. 
>> 
>> A pretty uncommon use-case.
> 
> Because it typically isn't possible? O:-)

I fail to see why anyone would want to do this, even if they could.

But anyone who wants to can do so, right now, by following the
instructions you posted earlier, without any support from us.

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

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

[Lawrence Velázquez]

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

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

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

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

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

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

[Lawrence Velázquez]

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

That sounds like more work than it's worth.

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

You first.

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

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

[Lawrence Velázquez]

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

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

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

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

[Lawrence Velázquez]

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

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

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

Your moralizing is not appreciated. Cut it out.

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

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

> And in general MacPorts seem to agree with my PoV

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

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

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

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

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

vq

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

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

[Lawrence Velázquez]

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

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

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

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

[Lawrence Velázquez]

> On Sep 29, 2016, at 5:46 PM, Mojca Miklavec  wrote:
> 
>> On 29 September 2016 at 22:10, Leonardo Brondani Schenkel wrote:
>> 
>> 1. Should I open a ticket when a build broke to track the progress of fixing
>> it?
> 
> Yes.

I would encourage doing so. Sometimes old tickets have information that
proves useful elsewhere.

>> 2. In case a package simply cannot be built in an unsupported version/ arch
>> of OS X (because upstream won't fix it and I don't know how to fix it), is
>> it possible to blacklist that combination on the Portfile so the buildbot
>> won't attempt to build it and/or users will be notified if they try to
>> install that package on that combination?

If you really have no intention of attempting to support the old
platform, you can bail out in a pre-fetch stage (I think) with an error
message. It's much less than ideal, but it's better than failing with an
obtuse linking error or something.

>> When I feel that I need a
>> second pair of eyes, like in this case, should I prefer to contact first the
>> -user or -devel lists or upstream?
> 
> I would suggest macports-devel and/or upstream.
> 
> This is not something that plain users should be concerned about, it's
> clearly a "developer" issue. Whether asking on the -devel mailing list
> or upstream depends a bit on situation. You could do both.

Don't hesitate to email macports-dev about maintainence issues. That's
its raison d'être, after all.

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

[Lawrence Velázquez]

> On Sep 29, 2016, at 3:51 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
>> On Sep 29, 2016, at 3:26 PM, Leonardo Brondani Schenkel
>> <leonardo.schen...@gmail.com> wrote:
>> 
>> After that mail I got dozens of mails today from the buildbot
>> regarding other unrelated packages, many just a few seconds or minutes
>> apart. Is this expected or was there a glitch? I don't get why I'm
>> getting mails for packages that I didn't change or maintain.
> 
> This is a known bug in our configuration that we are attempting to
> address: https://trac.macports.org/ticket/52446

It is fixed: https://trac.macports.org/changeset/153387

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

[Lawrence Velázquez]

> On Sep 29, 2016, at 3:26 PM, Leonardo Brondani Schenkel
>  wrote:
> 
> I recently started maintaining some MacPorts packages. For the first
> time today I got a message from the buildbot: apparently the neomutt
> package does not build on OS X 10.5 PPC due to '_safe_malloc' being
> undefined
> (https://build.macports.org/builders/ports-10.5_ppc_legacy-watcher/builds/632).
> My first question is regarding the procedure for failed builds: what
> is it expected that I as the maintainer should do in this case? Should
> I notify upstream and so maybe we could come up with a patch?
> Something else?

Our blanket policy is to support the three most recent major OS
versions. As of right now, that means Yosemite, El Capitan, and Sierra.
If you receive a failure notification from one of the relevant
buildslaves, you are expected to do something about it. Ideally you
would report the problem to upstream, who would then develop a general
fix that benefits all users. If the problem is not with the software
itself but with our packaging, hopefully upstream would be kind enough
to help you fix that. If upstream is uninterested for some reason,
you'll have to fix everything yourself and consider whether it's worth
maintaining a port with such an uncooperative upstream.

If the problem occurs on an earlier OS (as yours did), then it's up to
you. We'd like to keep ports working on as many systems as possible, but
you are not obligated to expend effort doing so. You should still report
the issue upstream, but upstream developers often don't want to support
legacy systems either. Sometimes you just have to choose between fixing
it yourself, opening a Trac ticket and hoping another intrepid dev takes
a crack at it, or leaving the port broken.

> After that mail I got dozens of mails today from the buildbot
> regarding other unrelated packages, many just a few seconds or minutes
> apart. Is this expected or was there a glitch? I don't get why I'm
> getting mails for packages that I didn't change or maintain.

This is a known bug in our configuration that we are attempting to
address: https://trac.macports.org/ticket/52446

> Maybe what I am asking is explained somewhere in the documentation,
> but honestly I couldn't find it. I may be looking at the wrong place.

We don't really have much documentation on the Buildbot infrastructure.

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

Re: force a compiler install, or default the port to reduced features?

[Lawrence Velázquez]

> On Sep 26, 2016, at 4:11 PM, Ken Cunningham  
> wrote:
> 
> And of course I find out that the preferred variant (a nice MacOSX GUI) 
> doesn't build with the default installation on about the only system I didn't 
> test it on - a vanilla 10.6 system (my 10.6 systems are LibCxxOnOlderSystems 
> now, with clang-3.7). 
> 
> So my choice is to let it use the existing default compiler and build a 
> somewhat impaired but usable command-line only version, or force a compiler 
> install (clang-3.4 works, maybe 3.3, clang 3.7 would be best), and get the 
> really much better racing-stripes GUI version. The compiler would be 
> installed precompiled on a vanilla 10.6 system. (LibCxx... systems already 
> have clang-3.7, and so don't have this problem).
> 
> I'm tempted to force the compiler install, and if so it might as well be to 
> clang-3.7.
> 
> Is this the "MacPorts" way?

The usual approach is to blacklist compilers that *don't* work.

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

Re: buildpath conf variable

[Lawrence Velázquez]

> On Sep 26, 2016, at 7:19 AM, René J.V. Bertin  wrote:
> 
>> On Monday September 26 2016 04:45:19 Ryan Schmidt wrote:
>> 
>> Most users use Macs with a single volume, so I don't think a patch
>> for this is of general interest.
> 
> Can't the same be said for portdbpath?

Yes. I don't know the rationale for this setting, but if it were
proposed today I would object to it as too niche.

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

Re: [MacPorts] WorkingWithGit modified

[Lawrence Velázquez]

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

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

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

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

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

Re: No Xcode 8 CLT for El Capitan

[Lawrence Velázquez]

> On Sep 21, 2016, at 3:38 PM, Adam Dershowitz  wrote:
> 
> The release Xcode 8 release notes (no longer beta) don’t have that comment:
> https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html

I think that only covers 8.0, not 8.1.

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

[Lawrence Velázquez]

> On Sep 21, 2016, at 3:08 PM, C. R. Oldham  wrote:
> 
> For those of us on Sierra, is it OK to install the CLT for Xcode 8?

I would assume so, given that there's a Sierra package available.

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

No Xcode 8 CLT for El Capitan

[Lawrence Velázquez]

Jack Howarth has noted on IRC that that Apple will not be releasing
a Command Line Tools package for Xcode 8 on El Capitan [*].

There is no Command Line Tools (OS X 10.11) for Xcode
8 package. Xcode 8 contains SDKs that are incompatible
with earlier toolchains. Developers who want to make use
of the Xcode 8 SDKs from the command line must choose
the SDK with xcode-select. Developers on OS X El Capitan
who have installed versions of the Command Line Tools
(OS X 10.11) for Xcode 8 Beta should install Command
Line Tools (OS X 10.11) for Xcode 7.3.1. (28234439)

Do we need to adjust our installation instructions to account for this?
The consequences of mixing the Xcode 7 CLT with Xcode 8 are not clear to
me; maybe it's not a problem at all.

[*]: 
http://adcdownload.apple.com/Developer_Tools/Xcode_8.1_beta/Release_Notes_for_Xcode_8.1_beta.pdf

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

Re: [152558] trunk/dports/sysutils/python_select/Portfile

[Lawrence Velázquez]

> On Sep 12, 2016, at 4:01 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> On Sep 12, 2016, at 2:54 PM, Ryan Schmidt wrote:
> 
>> On Sep 12, 2016, at 2:53 PM, Lawrence Velázquez wrote:
>> 
>>> Does anyone know whether the python26-apple.mtln and python27-apple.mtln 
>>> schemes still apply to Sierra?
>> 
>> How can I verify that's the case? Just check that each file listed in those 
>> files exists?
> 
> Because they do:
> 
> 
> 
> $ sw_vers
> ProductName:  Mac OS X
> ProductVersion:   10.12
> BuildVersion: 16A320
> $ grep -hv ^-$ $(port dir python_select)/files/python2{6,7}-apple.mtln | 
> xargs ls -l
> lrwxr-xr-x  1 root  wheel 74 Sep  8 23:49 /usr/bin/2to3-2.7 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/2to3-2.7
> lrwxr-xr-x  1 root  wheel 73 Sep  8 23:49 /usr/bin/2to32.6 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/2to32.6
> lrwxr-xr-x  1 root  wheel 73 Sep  8 23:49 /usr/bin/idle2.6 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/idle2.6
> lrwxr-xr-x  1 root  wheel 73 Sep  8 23:49 /usr/bin/idle2.7 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/idle2.7
> lrwxr-xr-x  1 root  wheel 74 Sep  8 23:49 /usr/bin/pydoc2.6 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/pydoc2.6
> lrwxr-xr-x  1 root  wheel 74 Sep  8 23:49 /usr/bin/pydoc2.7 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pydoc2.7
> lrwxr-xr-x  1 root  wheel 75 Sep  8 23:49 /usr/bin/python2.6 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6
> lrwxr-xr-x  1 root  wheel 82 Sep  8 23:49 /usr/bin/python2.6-config -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-config
> lrwxr-xr-x  1 root  wheel 75 Sep  8 23:49 /usr/bin/python2.7 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
> lrwxr-xr-x  1 root  wheel 82 Sep  8 23:49 /usr/bin/python2.7-config -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
> lrwxr-xr-x  1 root  wheel 76 Sep  8 23:49 /usr/bin/pythonw2.6 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/pythonw2.6
> lrwxr-xr-x  1 root  wheel 76 Sep  8 23:49 /usr/bin/pythonw2.7 -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
> lrwxr-xr-x  1 root  wheel 77 Sep  8 23:49 /usr/bin/smtpd2.6.py -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.6/bin/smtpd2.6.py
> lrwxr-xr-x  1 root  wheel 77 Sep  8 23:49 /usr/bin/smtpd2.7.py -> 
> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/smtpd2.7.py
> -rw-r--r--  1 root  wheel  15329 Jul 30 20:35 /usr/share/man/man1/python2.6.1
> -rw-r--r--  1 root  wheel  15825 Jul 30 20:36 /usr/share/man/man1/python2.7.1

I think that's fine then. I'll revbump.

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