[macports-ports] branch master updated: sqlite3: use readline rather than editline to permit non-ASCII characters

[Joshua Root]

FYI, this reverses the decision made in 
 and makes at least 79 ports 
non-distributable.


- Josh

Re: [macports-ports] branch master updated: grib_api: delete unused CMake flags

[Ryan Schmidt]

> On Nov 14, 2016, at 6:42 PM, tenomoto  
> wrote:
> 
> tenomoto pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/8dd1f26e3c8218708a97ac7bd1d4b0aae1984046
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 8dd1f26  grib_api: delete unused CMake flags
> 
> 8dd1f26 is described below
> 
> 
> commit 8dd1f26e3c8218708a97ac7bd1d4b0aae1984046
> 
> Author: Takeshi Enomoto 
> AuthorDate: Tue Nov 15 09:37:46 2016 +0900
> 
> 
> grib_api: delete unused CMake flags
> 
> ---
>  science/grib_api/Portfile | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> 
> diff --git a/science/grib_api/Portfile b/science/grib_api/Portfile
> 
> index 7758a15..4992f40 100644
> 
> --- a/science/grib_api/Portfile
> 
> +++ b/science/grib_api/Portfile
> 
> @@ -1,4 +1,5 @@
> 
>  # -*- 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$
> 

Please don't re-add the $Id$ line. We used that with Subversion but aren't 
using it anymore now that we moved to Git.


>  
>  PortSystem  1.0
>  PortGroup cmake 1.0
> 
> @@ -6,7 +7,6 @@ PortGroup compilers 1.0
> 
>  
>  namegrib_api
>  version 1.18.0
> 
> -revision1

You can't just decrease the revision.

Re: [macports-ports] branch master updated: msieve: upgrade to 1.53, add ecm variant, take maintainership

[Nicolas Pavillon]

>> @@ -32,6 +33,10 @@ post-patch {
>> 
>> use_configure   no
>> 
>> +if {[variant_isset ecm]} {
>> +build.args ECM=1
>> +}
>> +
> 
> Why did you put this code here in a block by itself? Why not set (or better 
> yet: append to) build.args inside the emc variant declaration, so that all 
> the code relating to the variant is in one place?
> 
>> build.env   CFLAGS="${configure.cflags}" \
>> CPATH="${compiler.cpath}" \
>> LIBRARY_PATH="${compiler.library_path}" \
>> @@ -53,6 +58,10 @@ destroot {
>> ${destroot}${prefix}/share/${name}/demo
>> }
>> 
>> +variant ecm description "Use elliptic curve method for factorisation" {
>> +depends_lib-append  port:gmp-ecm
>> +}
> 

You’re right, I forgot to finish to clean up after testing during development. 
Fixed in ec35a394345e0f5ce04ba6d6167ef13870437f0b.

Cheers, 

Nicolas

Re: [macports-ports] 02/03: git-cola: install bash-completion

[Rainer Müller]

On 2016-11-15 01:07, Ryan Schmidt wrote:
> notes "
> If you want to use bash-completion for git-cola, you have to source the\
> completion files from your ~/.bashrc as it extends the git command\
> completion and cannot be loaded automatically:
> 
>   source ${prefix}/share/bash-completion/completions/git
>   source ${prefix}/share/bash-completion/completions/git-cola
> "

I stand corrected. Changed this now to the simpler syntax:

https://github.com/macports/macports-ports/commit/2ad96f3b61d83e9833c6b38b8c3ce620225b9656

Thanks for the hint.

Rainer

Automatic checks on pull requests (was: Re: Another workflow (pull requests) question.)

[Rainer Müller]

On 2016-11-14 20:44, Eric A. Borisch wrote:
> As a wish list item, It would be awesome to have an automated build that
> would run at least through the checksum phase for PRs with just version
> # and checksum changes.

This would be nice indeed. However, as Portfiles are executable code,
this requires proper isolation to avoid system-wide file access and
accessing the network. For example this could be done by spinning up a
new, clean VM for every Portfile.

A particular problem is that MacPorts requires a) macOS and b) root for
many operations. This rules out almost all CI systems available for open
source projects.

For example Travis CI offers OS X [1], even with root access [2].
I would assume a simple check with 'port lint' should be possible to be
deployed there quickly and be integrated with GitHub quite nicely. For
such basic checks, the exact version of the OS should also not matter.

Although, scripting to build ports already exists for our buildbot [3].
The alternative to the above would therefore be to roll our own tooling
on the buildbot infrastructure with VM snapshots, but that will be a lot
more work.

Contributions welcome! :-)

Rainer

[1] https://docs.travis-ci.com/user/osx-ci-environment/#OS-X-Version
[2]
https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments
[3] https://github.com/macports/mpbb

Re: [macports-ports] 02/03: git-cola: install bash-completion

[Ryan Schmidt]

> On Nov 14, 2016, at 6:05 PM, Rainer Müller  wrote:
> 
> On 2016-11-15 00:50, Ryan Schmidt wrote:
> 
>> Why is using the weird
>> 
>>[subst {...}]
>> 
>> here better than using
>> 
>>"..."
>> 
>> ?
> 
> There is no way to split a line within "..." done here with the
> backslashes at the end of the lines within {...}. With quotes, it would
> either require to keep the whole paragraph on a single line in the
> Portfile or hard code a fixed line width instead of letting the port
> client decide how it will be displayed (for port(1), wrap at terminal
> width).
> 
> Normally it is not possible to use variable substitutions within {...},
> which is why the explicit [subst {...}] is required.
> 
> Rainer


What are you talking about? As far as I can tell, this works identically to 
what you have:



notes "
If you want to use bash-completion for git-cola, you have to source the\
completion files from your ~/.bashrc as it extends the git command\
completion and cannot be loaded automatically:

  source ${prefix}/share/bash-completion/completions/git
  source ${prefix}/share/bash-completion/completions/git-cola
"



I use this all the time.

Re: [macports-ports] 02/03: git-cola: install bash-completion

[Rainer Müller]

On 2016-11-15 00:50, Ryan Schmidt wrote:

> Why is using the weird
> 
> [subst {...}]
> 
> here better than using
> 
> "..."
> 
> ?

There is no way to split a line within "..." done here with the
backslashes at the end of the lines within {...}. With quotes, it would
either require to keep the whole paragraph on a single line in the
Portfile or hard code a fixed line width instead of letting the port
client decide how it will be displayed (for port(1), wrap at terminal
width).

Normally it is not possible to use variable substitutions within {...},
which is why the explicit [subst {...}] is required.

Rainer

Re: Another workflow (pull requests) question.

[Ryan Schmidt]

On Nov 14, 2016, at 1:44 PM, Eric A. Borisch wrote:

> As a wish list item, It would be awesome to have an automated build that 
> would run at least through the checksum phase for PRs with just version # and 
> checksum changes.

Yes, automated builds of pull requests would be awesome. But that would involve 
the creation of new infrastructure.

I'm not prepared to run code on the build server, as root (as you know, 
MacPorts runs as root), that has not been tested by any MacPorts-vetted 
contributor.

So we need sandboxes -- pristine virtual machines which we can clone, do the 
build, then discard.

Re: [macports-ports] 02/03: git-cola: install bash-completion

[Ryan Schmidt]

> On Nov 14, 2016, at 5:05 PM, Rainer Müller  
> wrote:
> 
> +notes [subst {
> 
> +If you want to use bash-completion for git-cola, you have to source the\
> 
> +completion files from your ~/.bashrc as it extends the git command\
> 
> +completion and cannot be loaded automatically:
> 
> +
> 
> +  source ${prefix}/share/bash-completion/completions/git
> 
> +  source ${prefix}/share/bash-completion/completions/git-cola
> 
> +}]
> 
> 


Why is using the weird

[subst {...}]

here better than using

"..."

?

Re: Another workflow (pull requests) question.

[Lawrence Velázquez]

> On Nov 14, 2016, at 2:44 PM, Eric A. Borisch  wrote:
> 
>> On Mon, Nov 14, 2016 at 1:17 PM, Rainer Müller  wrote:
>> 
>> I am not opposed to enabling "Squash and merge", but we have no
>> guide for maintainers explaining the pull request workflow. If we
>> had this, it could explain the differences between the "Rebase and
>> merge" and "Squash and merge" button and when to use what.
> 
> Well, I vote for some education (guide section) plus enabling the
> squash and merge button.

We have a chicken-and-egg problem insofar as we don't really understand
how PRs work, so we cannot document how they work. I "botched"* the PR
under discussion because force-pushing to the PR branch did not do what
I had observed in previous PRs.

I am not particularly keen on enabling squash-and-merge because it might
encourage developers to (a) not bother testing and (b) write poor commit
messages on the GitHub web page.

* I say "botched" because I don't really care that that PR has been
  resolved as non-"Merged".

vq

Re: Another workflow (pull requests) question.

[Eric A. Borisch]

On Mon, Nov 14, 2016 at 1:17 PM, Rainer Müller  wrote:

> I agree this is not the easiest workflow we could have. However, even
> with "Squash and merge" button, you could only replace 4) and 5) of your
> steps with the web interface. You still need to the other steps to test
> the changes anyway.


I had already tested (applied in one line with patch and curl, because
those I know how to use them) the change. It would still be less error
prone at that point to have the S&M button. As proof, look no further than
what actually ended up happening on this PR [1] during this discussion.

As a wish list item, It would be awesome to have an automated build that
would run at least through the checksum phase for PRs with just version #
and checksum changes.


> It is cumbersome to ask the pull request author to go through with this.
> I recently made the same experience [1], but explaining how to edit the
> pull request properly definitely took longer than just fixing it myself.
>
> I am not opposed to enabling "Squash and merge", but we have no guide
> for maintainers explaining the pull request workflow. If we had this, it
> could explain the differences between the "Rebase and merge" and "Squash
> and merge" button and when to use what.
>

Well, I vote for some education (guide section) plus enabling the squash
and merge button.

[1]
https://github.com/macports/macports-ports/pull/37#issuecomment-260430808

 - Eric

Re: Another workflow (pull requests) question.

[Rainer Müller]

On 2016-11-14 19:33, Eric A. Borisch wrote:
> OK, so to be pedantic, instead of using the the GitHub "Squash and
> merge" button (one click) committers are going to:
> 
> 1) Go to their local (filesystem) copy of macports-ports
> 2) git checkout -b dgsb-master master
> 3) git pull git://github.com/dgsb/macports-ports.git
>  master  (Or grab the patch
> from GH and apply that?)

Another quick way that would also include rebasing onto the current
origin/master (once again assuming "origin" is the remote pointing to
macports/macports-ports):

git checkout -b pull-XYZ origin/master
curl -sLS https://github.com/macports/macports-ports/pull/XYZ.patch \
  | git am

> 4+) "squash and rebase magic command(s) here including Closes: #xx
> verbiage" (Guessing this is might be two commands. One at a minimum.)
> 5) git push origin master
> 
> All without accidentally changing/committing/appropriate-git-verb-ing
> any other local WIP changes.
> 
> I like the one-click approach here, for obvious reasons. Yes, I'm sure
> anyone can become adept at the steps above -- but I believe the
> one-click approach will still be faster (I'll race you: aand done.)
> and will have less potential user error. Assuming this (multi-step
> process above) is the same workflow the S&M button automates for you
> behind the scenes, I think it would be better in the long run to train
> developers when to use squash+M vs. rebase+M, and let us leverage the
> benefits of GH.

I agree this is not the easiest workflow we could have. However, even
with "Squash and merge" button, you could only replace 4) and 5) of your
steps with the web interface. You still need to the other steps to test
the changes anyway.

> I suppose the other option is to ask the submitter to resubmit this as
> one change, and then use the Rebase & Merge button? The only reason I
> still like the S&M button is that it lowers the barrier to
> contributing... If we wanted to ask the submitter to resubmit, what is
> the proper action to ask for?

It is cumbersome to ask the pull request author to go through with this.
I recently made the same experience [1], but explaining how to edit the
pull request properly definitely took longer than just fixing it myself.

I am not opposed to enabling "Squash and merge", but we have no guide
for maintainers explaining the pull request workflow. If we had this, it
could explain the differences between the "Rebase and merge" and "Squash
and merge" button and when to use what.

Rainer

[1] https://github.com/macports/macports-ports/pull/32

Re: Another workflow (pull requests) question.

[David Bariod via macports-dev]

Hello all,

Just jumping in as I'm the committer of this pull request.
Is something else expected from the committer after the review has been
done and then completed ?
Would it be easier for the reviewer that the comitter rebase the pull
request branch on top of master upon rework after the review ?

David

On Mon, Nov 14, 2016 at 6:39 PM, Rainer Müller  wrote:

> On 2016-11-14 18:24, Eric A. Borisch wrote:
> > Additionally, this PR also has changes requested by another committer,
> > and acted upon (source of the second commit) by the requestor in the
> > pull request. If I were to push the "Rebase and merge", should I first
> > "Dismiss review" with "Requested changes made" as the reason?
>
> I am not sure if it would make a difference. There should be no
> restrictions configured that would prevent a merge despite requested
> changes, so either way should be fine if you checked that the changes
> were fixed.
>
> To resolve this, I just approved the changes I requested. :-)
>
> Rainer
>

Re: Another workflow (pull requests) question.

[Eric A. Borisch]

On Mon, Nov 14, 2016 at 11:36 AM, Rainer Müller  wrote:

> On 2016-11-14 18:11, Eric A. Borisch wrote:
> > If squash-and-merge is what we're going to want for pull requests, can
> > we re-enable the button? (Also known as, if we're using GitHub, can we
> > use GitHub?) Ideally contributions from others (like this pull request)
> > should be as painless (read as: fewest steps that still achieve the
> > desired ends) as possible on both sides.
>
> In the migration, we were reluctant to enable "Squash and merge", as it
> would be the default option when enabled. GitHub does not allow to
> select a different default. Developers without Git/GitHub experience
> (and there seem to be quite a few) might be tempted to just press the
> default button. As there was a consensus to keep the history mostly
> linear [1], "Rebase and merge" was the best compromise as default, which
> is only achievable by disabling the other options.
>
> Maintainers should checkout the pull request to test the changes, so
> they can also squash and rebase the commits locally and then push the
> result. Just remember to add the appropriate "Closes: #xx" to the commit
> message, so GitHub can properly attribute the change.
>
> Rainer
>
> [1] https://trac.macports.org/wiki/WorkingWithGit#Rebasing
>

OK, so to be pedantic, instead of using the the GitHub "Squash and merge"
button (one click) committers are going to:

1) Go to their local (filesystem) copy of macports-ports
2) git checkout -b dgsb-master master
3) git pull git://github.com/dgsb/macports-ports.git master  (Or grab the
patch from GH and apply that?)
4+) "squash and rebase magic command(s) here including Closes: #xx
verbiage" (Guessing this is might be two commands. One at a minimum.)
5) git push origin master

All without accidentally changing/committing/appropriate-git-verb-ing any
other local WIP changes.

I like the one-click approach here, for obvious reasons. Yes, I'm sure
anyone can become adept at the steps above -- but I believe the one-click
approach will still be faster (I'll race you: aand done.) and will have
less potential user error. Assuming this (multi-step process above) is the
same workflow the S&M button automates for you behind the scenes, I think
it would be better in the long run to train developers when to use squash+M
vs. rebase+M, and let us leverage the benefits of GH.

I suppose the other option is to ask the submitter to resubmit this as one
change, and then use the Rebase & Merge button? The only reason I still
like the S&M button is that it lowers the barrier to contributing... If we
wanted to ask the submitter to resubmit, what is the proper action to ask
for?

Thanks,
  - Eric

Re: Another workflow (pull requests) question.

[Rainer Müller]

On 2016-11-14 18:24, Eric A. Borisch wrote:
> Additionally, this PR also has changes requested by another committer,
> and acted upon (source of the second commit) by the requestor in the
> pull request. If I were to push the "Rebase and merge", should I first
> "Dismiss review" with "Requested changes made" as the reason?

I am not sure if it would make a difference. There should be no
restrictions configured that would prevent a merge despite requested
changes, so either way should be fine if you checked that the changes
were fixed.

To resolve this, I just approved the changes I requested. :-)

Rainer

Re: Another workflow (pull requests) question.

[Rainer Müller]

On 2016-11-14 18:11, Eric A. Borisch wrote:
> If squash-and-merge is what we're going to want for pull requests, can
> we re-enable the button? (Also known as, if we're using GitHub, can we
> use GitHub?) Ideally contributions from others (like this pull request)
> should be as painless (read as: fewest steps that still achieve the
> desired ends) as possible on both sides.

In the migration, we were reluctant to enable "Squash and merge", as it
would be the default option when enabled. GitHub does not allow to
select a different default. Developers without Git/GitHub experience
(and there seem to be quite a few) might be tempted to just press the
default button. As there was a consensus to keep the history mostly
linear [1], "Rebase and merge" was the best compromise as default, which
is only achievable by disabling the other options.

Maintainers should checkout the pull request to test the changes, so
they can also squash and rebase the commits locally and then push the
result. Just remember to add the appropriate "Closes: #xx" to the commit
message, so GitHub can properly attribute the change.

Rainer

[1] https://trac.macports.org/wiki/WorkingWithGit#Rebasing

Re: Another workflow (pull requests) question.

[Eric A. Borisch]

On Mon, Nov 14, 2016 at 10:51 AM, Eric A. Borisch 
wrote:

> If I see something like this -- https://github.com/
> macports/macports-ports/pull/37 -- come through, and it LGTM, do I just
> push the big 'Rebase and merge' button on the GitHub GUI? (This particular
> one is an update to a nomaintainer port (fish) to the latest upstream
> version, removes no-longer-needed patches, and removes the $Id$ line).
>
> Let's assume I've tested the changes locally already, and think it is good
> to go for the sake of limiting this discussion.
>
> Thanks,
>   - Eric
>

Additionally, this PR also has changes requested by another committer, and
acted upon (source of the second commit) by the requestor in the pull
request. If I were to push the "Rebase and merge", should I first "Dismiss
review" with "Requested changes made" as the reason?

 - Eric

Re: Another workflow (pull requests) question.

[Ryan Schmidt]

> On Nov 14, 2016, at 11:11 AM, Eric A. Borisch  wrote:
> 
> If squash-and-merge is what we're going to want for pull requests, can we 
> re-enable the button? (Also known as, if we're using GitHub, can we use 
> GitHub?) Ideally contributions from others (like this pull request) should be 
> as painless (read as: fewest steps that still achieve the desired ends) as 
> possible on both sides.

I do not know who disabled the button or why. I'm leaving the details of how we 
use git and github to other contributors who are familiar with how to use git 
and github best.

Re: Another workflow (pull requests) question.

[Eric A. Borisch]

If squash-and-merge is what we're going to want for pull requests, can we
re-enable the button? (Also known as, if we're using GitHub, can we use
GitHub?) Ideally contributions from others (like this pull request) should
be as painless (read as: fewest steps that still achieve the desired ends)
as possible on both sides.

 - Eric

On Mon, Nov 14, 2016 at 10:58 AM, Ryan Schmidt 
wrote:

>
> > On Nov 14, 2016, at 10:51 AM, Eric A. Borisch 
> wrote:
> >
> > If I see something like this -- https://github.com/macports/
> macports-ports/pull/37 -- come through, and it LGTM, do I just push the
> big 'Rebase and merge' button on the GitHub GUI? (This particular one is an
> update to a nomaintainer port (fish) to the latest upstream version,
> removes no-longer-needed patches, and removes the $Id$ line).
> >
> > Let's assume I've tested the changes locally already, and think it is
> good to go for the sake of limiting this discussion.
>
> I thought we had decided that multiple-commit pull requests, where each
> commit does not in and of itself represent a viable state of the port,
> should be squashed into a single commit before merging. The "Squash and
> merge" function of the GitHub web interface seems to have been disabled so
> I guess either the author of the pull request or you should squash the
> commits some other manual way first.
>
>

Re: Another workflow (pull requests) question.

[Ryan Schmidt]

> On Nov 14, 2016, at 10:51 AM, Eric A. Borisch  wrote:
> 
> If I see something like this -- 
> https://github.com/macports/macports-ports/pull/37 -- come through, and it 
> LGTM, do I just push the big 'Rebase and merge' button on the GitHub GUI? 
> (This particular one is an update to a nomaintainer port (fish) to the latest 
> upstream version, removes no-longer-needed patches, and removes the $Id$ 
> line).
> 
> Let's assume I've tested the changes locally already, and think it is good to 
> go for the sake of limiting this discussion.

I thought we had decided that multiple-commit pull requests, where each commit 
does not in and of itself represent a viable state of the port, should be 
squashed into a single commit before merging. The "Squash and merge" function 
of the GitHub web interface seems to have been disabled so I guess either the 
author of the pull request or you should squash the commits some other manual 
way first.

Another workflow (pull requests) question.

[Eric A. Borisch]

If I see something like this -- https://github.com/macports/
macports-ports/pull/37 -- come through, and it LGTM, do I just push the big
'Rebase and merge' button on the GitHub GUI? (This particular one is an
update to a nomaintainer port (fish) to the latest upstream version,
removes no-longer-needed patches, and removes the $Id$ line).

Let's assume I've tested the changes locally already, and think it is good
to go for the sake of limiting this discussion.

Thanks,
  - Eric

Re: [macports-ports] branch master updated: msieve: upgrade to 1.53, add ecm variant, take maintainership

[Ryan Schmidt]

> On Nov 14, 2016, at 7:25 AM, NicosPavlov 
>  wrote:
> 
> NicosPavlov pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/7b571f2dcc80a4650dfd5f9be8f03a40bb53cad7
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>  new 7b571f2  msieve: upgrade to 1.53, add ecm variant, take 
> maintainership
> 
> 7b571f2 is described below


> @@ -32,6 +33,10 @@ post-patch {
>  
>  use_configure   no
>  
> +if {[variant_isset ecm]} {
> +build.args ECM=1
> +}
> +

Why did you put this code here in a block by itself? Why not set (or better 
yet: append to) build.args inside the emc variant declaration, so that all the 
code relating to the variant is in one place?

>  build.env   CFLAGS="${configure.cflags}" \
>  CPATH="${compiler.cpath}" \
>  LIBRARY_PATH="${compiler.library_path}" \
> @@ -53,6 +58,10 @@ destroot {
>  ${destroot}${prefix}/share/${name}/demo
>  }
>  
> +variant ecm description "Use elliptic curve method for factorisation" {
> +depends_lib-append  port:gmp-ecm
> +}