Re: New guide section on Git and GitHub
On 2018-04-13 15:31, Jonathan Stickel wrote: > As a long time contributor of patches using the ticket interface (Trac), > I think it would be a mistake to discourage submission of patches there. > While it is fine to encourage use of git pull requests, the barrier of > entry is much higher. In fact, I just made my first pull request this > week, and, after a nontrivial amount of effort, I still managed to mess > it up. Git is quite powerful for sure, but it definitely has a learning > curve. Pull requests makes use of multiple layers of abstract concepts > (forks and branches) and multiple steps. > > I think it would be reasonable to expect casual users to still upload > patches to trac, which then port maintainers ought to turn into PRs. My > 2 cents. Maybe we could revisit the idea that once existed way back with the MacPorts Web Application, but was never realized: a 'port submit' action. I envision it to work like this: $ port submit or: $ port submit The second form would only be needed when also updating patches. This would use credentials stored in Keychain (a GitHub API auth token), which would be asked for when used for the first time, guiding the user through creation of such a API token that has the necessary scope. Of course there should also be commands to delete them again or use different credentials. 1. Run 'port lint' on the given port, stop on errors On warnings, ask for confirmation or require a --force option to continue 2. Get path from the Portfile as / (PORTPATH) 1. Create a new unique branch name on "/macports-ports" (BRANCH) 2. Update BRANCH to the latest master of macports/macports-ports 3. Commit new Portfile to PORTPATH in BRANCH Ask user for a commit message, if implemented with a temporary shallow clone, can just launch 'git commit --verbose'. 4. Open URL of new commit in browser, ask user to review and confirm 5.1 If confirmed, open a pull request against macports/macports-ports 5.2 If not confirmed, delete BRANCH Rainer
Ticket #56139 update to pymol 2.1.0 with PyQt interface support
Can someone commit my final update to pymol 2.1.0 with PyQt interface support? The packaging switches pymol to use the new PyQt based interface while retaining the tcl/k/pmw dependencies for the legacy plugins. Regarding the legacy plugins, the apbstools one only properly functions on the default python27 variant. This is an issue that exists in the current and prior pymol releases as well and is caused by a combination of pdb2pqr python3 incompatibilities and pmw incompatibilities with python 3.5 and later. Upstream pdb2pqr still hasn't pushed their python3 fixes into apbs-pdb2pqr yet and pmw development seems to be completely stagnant. Jack https://trac.macports.org/ticket/56139
Re: port version reports 2.4.2 when built from tag v2.4.3
> On 13 Apr 2018, at 23:55, Joshua Root wrote: > > On 2018-4-14 07:30 , Enrico Maria Crisostomo wrote: >> I think I found the culprit: >> >>% strings /opt/macports-2.4.3-dirty/libexec/macports/lib/libtcl8.5.dylib >> | grep 2\\.4\\. >>/opt/macports-2.4.2/libexec/macports/lib >>/opt/macports-2.4.2/libexec/macports/bin >>/opt/macports-2.4.2/libexec/macports/lib/tcl8.5 >>/opt/macports-2.4.2/libexec/macports/include >>/opt/macports-2.4.2/libexec/macports/man >>/opt/macports-2.4.3-dirty/libexec/macports/lib/tcl8.5 >>/opt/macports-2.4.3-dirty/libexec/macports/lib >> >> while the library built from the clean repo is right: >> >>% strings /opt/macports-2.4.3-clean/libexec/macports/lib/libtcl8.5.dylib >> | grep 2\\.4\\. >>/opt/macports-2.4.3-clean/libexec/macports/lib >>/opt/macports-2.4.3-clean/libexec/macports/bin >>/opt/macports-2.4.3-clean/libexec/macports/lib/tcl8.5 >>/opt/macports-2.4.3-clean/libexec/macports/include >>/opt/macports-2.4.3-clean/libexec/macports/man >>/opt/macports-2.4.3-clean/libexec/macports/lib/tcl8.5 >>/opt/macports-2.4.3-clean/libexec/macports/lib >> >> Hence, the macports installation that was built from the dirty tree is >> referring to the installation directory of the previous build. That also >> explains why removing that directory makes port crash, as I said in a >> previous mail. > > OK, so the issue is not with switching tags without cleaning at all, but > configuring for a different prefix without cleaning. The bug is in one > of Tcl's Makefiles, which compiles tclPkgConfig.c with several -D flags > using values that are directly substituted into the Makefile by > autoconf. There should probably be a dependency declared on the Makefile > itself. > > - Josh Thanks Josh. You're right, and thanks to your pointing out the file involved I've just added a dependency from tclPkgConfig.o to the Makefile itself and the problem disappears. Here's a PR: https://github.com/macports/macports-base/pull/79 I'm not merging until somebody has a look at it. Cheers, -- Enrico
let's actually fix the ccpnmr build
Can someone please commit the changes that I posted in the ticket... https://trac.macports.org/ticket/56292 so that ccpnmr actually builds again? People keep committing changes to this package without actually checking that they work. We need to resort to a compiler.blacklist to avoid all compilers without a working -fopenmp. This includes all Apple clang and llvm.org clang prior to the 4.0 release.
Re: New guide section on Git and GitHub
On Fri, 13 Apr 2018 07:31:45 -0600 Jonathan Stickel wrote: > As a long time contributor of patches using the ticket interface > (Trac), I think it would be a mistake to discourage submission of > patches there. While it is fine to encourage use of git pull > requests, the barrier of entry is much higher. In fact, I just made > my first pull request this week, and, after a nontrivial amount of > effort, I still managed to mess it up. Git is quite powerful for > sure, but it definitely has a learning curve. Pull requests makes > use of multiple layers of abstract concepts (forks and branches) > and multiple steps. > > I think it would be reasonable to expect casual users to still > upload patches to trac, which then port maintainers ought to turn > into PRs. My 2 cents. We're currently encouraging use of pull requests, not banning the use of Trac. If you find Trac is vastly easier, then use that for now. The price is that you may not get attention to your requests as quickly. Perry -- Perry E. Metzgerpmetz...@macports.org
How long should we wait for submitter action on a PR?
We have one open PR where the submitter hasn't replied to some requests for changes since the initial request several weeks ago. (I tried emailing the requester directly some time ago and got no response there either.) Clearly there should be a timeout after which the pull request gets closed for lack of submitter action, but what should it be? (We can always reopen the request if the submitter wakes up of course, it just no longer shows as a pending action for project members to worry about processing.) (I imagine in some cases someone might choose to make the fixes on behalf of the submitter and commit them, but lets ignore that possibility for now.) Perry -- Perry E. Metzgerpmetz...@macports.org
Re: New guide section on Git and GitHub
On 4/14/18 08:29 , Perry E. Metzger wrote: On Fri, 13 Apr 2018 07:31:45 -0600 Jonathan Stickel wrote: As a long time contributor of patches using the ticket interface (Trac), I think it would be a mistake to discourage submission of patches there. While it is fine to encourage use of git pull requests, the barrier of entry is much higher. In fact, I just made my first pull request this week, and, after a nontrivial amount of effort, I still managed to mess it up. Git is quite powerful for sure, but it definitely has a learning curve. Pull requests makes use of multiple layers of abstract concepts (forks and branches) and multiple steps. I think it would be reasonable to expect casual users to still upload patches to trac, which then port maintainers ought to turn into PRs. My 2 cents. We're currently encouraging use of pull requests, not banning the use of Trac. If you find Trac is vastly easier, then use that for now. The price is that you may not get attention to your requests as quickly. Sure, it makes perfect sense to encourage PRs while continue to consider patches. I'm not against that at all, and I'm willing to figure it out. But care should be taken about the tone of the message, especially given the current competition. Any perception that Macports is not friendly to new users and contributors would be a mistake.
Re: New guide section on Git and GitHub
On Apr 14, 2018, at 4:01 PM, Jonathan Stickel wrote: > > Sure, it makes perfect sense to encourage PRs while continue to consider > patches. I'm not against that at all, and I'm willing to figure it out. But > care should be taken about the tone of the message, especially given the > current competition. Any perception that Macports is not friendly to new > users and contributors would be a mistake. Jonathan, I’ll take the blame for the tone. This is not my first transgression, and I apologize both to you and the MacPorts folks. -AM
Re: port version reports 2.4.2 when built from tag v2.4.3
On 2018-04-13 23:55, Joshua Root wrote: > On 2018-4-14 07:30 , Enrico Maria Crisostomo wrote: >> Hence, the macports installation that was built from the dirty tree is >> referring to the installation directory of the previous build. That also >> explains why removing that directory makes port crash, as I said in a >> previous mail. > > OK, so the issue is not with switching tags without cleaning at all, but > configuring for a different prefix without cleaning. The bug is in one > of Tcl's Makefiles, which compiles tclPkgConfig.c with several -D flags > using values that are directly substituted into the Makefile by > autoconf. There should probably be a dependency declared on the Makefile > itself. FWIW, I am usually work with multiple worktrees instead of switching branches in the same directory. That way I can have directories for both master and release-2.4 side-by-side. $ pwd /Users/raimue/src/macports/base $ git worktree add ../base-2.4 release-2.4 $ cd ../base-2.4 $ cat config/macports_version 2.4.3 See the git manual for the details: https://git-scm.com/docs/git-worktree The copy in base-2.4 is also configured to use a different prefix. As the files of the build system can stay in the filesystem, I do not have to re-configure all the time. When I want to work on release-2.4, I only have to change directory in my shell. Rainer
Re: let's actually fix the ccpnmr build
On Apr 14, 2018, at 09:20, Jack Howarth wrote: > Can someone please commit the changes that I posted in the ticket... > > https://trac.macports.org/ticket/56292 > > so that ccpnmr actually builds again? People keep committing changes to this > package without actually checking that they work. There's nothing wrong with making bulk changes to ports without verifying that the ports build, when the change is correct and it has nothing to do with building the ports. For example, the two recent commits to this port were bulk updates to remove the dragonegg and llvm compilers from the compilers and mpi portgroups, and to add your GitHub handle to the ports you maintain. It was correct to commit those changes, even if the port does not build for unrelated reasons.
Re: How long should we wait for submitter action on a PR?
On Apr 14, 2018, at 09:37, Perry E. Metzger wrote: > We have one open PR where the submitter hasn't replied to some > requests for changes since the initial request several weeks ago. (I > tried emailing the requester directly some time ago and got no > response there either.) > > Clearly there should be a timeout after which the pull request gets > closed for lack of submitter action, but what should it be? (We can > always reopen the request if the submitter wakes up of course, it > just no longer shows as a pending action for project members to worry > about processing.) > > (I imagine in some cases someone might choose to make the fixes on > behalf of the submitter and commit them, but lets ignore that > possibility for now.) Why should we ignore that possibility? That would have been my recommendation. That's how we handle tickets, isn't it?
how to create a patch for configure?
Working on my missing dejavusansmono in rrdtool pango cairo fontconfig problem: pango calls 'FcWeightFromOpenTypeDouble' an that function exists only in fontconfig >= 2.92 That implies changes to pango or fontconfig and I can't oversee the consequences. But I verified pango source and it doesn't really use that function but still the older 'FcWeightFromOpenType'. That means that if I bypass the configure check everything should work fine. pango configure:18606 - if $have_fontconfig ; then pango_save_libs=$LIBS LIBS="$LIBS $FONTCONFIG_LIBS" for ac_func in FcWeightFromOpenTypeDouble do : ac_fn_c_check_func "$LINENO" "FcWeightFromOpenTypeDouble" "ac_cv_func_FcWeightFromOpenTypeDouble" if test "x$ac_cv_func_FcWeightFromOpenTypeDouble" = xyes; then : cat >>confdefs.h <<_ACEOF #define HAVE_FCWEIGHTFROMOPENTYPEDOUBLE 1 _ACEOF this check fails so HAVE_FCWEIGHTFROMOPENTYPEDOUBLE is still undefined. The result is that pango doesn't use fontconfig. pango configure.ac:221 -- if $have_fontconfig ; then pango_save_libs=$LIBS LIBS="$LIBS $FONTCONFIG_LIBS" AC_CHECK_FUNCS(FcWeightFromOpenTypeDouble) LIBS=$pango_save_libs fi here I want to disable AC_CHECK_FUNCS() and also add #define HAVE_FCWEIGHTFROMOPENTYPEDOUBLE 1 to confdefs.h I made a patch resulting in pango configure.ac:221 -- if $have_fontconfig ; then pango_save_libs=$LIBS LIBS="$LIBS $FONTCONFIG_LIBS" -># AC_CHECK_FUNCS(FcWeightFromOpenTypeDouble) ->cat >>confdefs.h <<_ACEOF -> #define HAVE_FCWEIGHTFROMOPENTYPEDOUBLE 1 -> _ACEOF LIBS=$pango_save_libs fi but Autoconf didn't run so configure was not updated so nothing changes. Q1: if the patch result correct? Q2: How should I do this in Portfile ?
Re: How long should we wait for submitter action on a PR?
On Sat, 14 Apr 2018 18:31:51 -0500 Ryan Schmidt wrote: > On Apr 14, 2018, at 09:37, Perry E. Metzger wrote: > > > We have one open PR where the submitter hasn't replied to some > > requests for changes since the initial request several weeks ago. > > (I tried emailing the requester directly some time ago and got no > > response there either.) > > > > Clearly there should be a timeout after which the pull request > > gets closed for lack of submitter action, but what should it be? > > (We can always reopen the request if the submitter wakes up of > > course, it just no longer shows as a pending action for project > > members to worry about processing.) > > > > (I imagine in some cases someone might choose to make the fixes on > > behalf of the submitter and commit them, but lets ignore that > > possibility for now.) > > Why should we ignore that possibility? I'm only ignoring it for purposes of asking how long to leave a pull request lying around. Nothing in setting such a timeout prevents us from choosing to make the fixes on our own. > That would have been my > recommendation. That's how we handle tickets, isn't it? Perry -- Perry E. Metzgerpmetz...@macports.org
Re: how to create a patch for configure?
On 2018-4-15 11:11 , macpo...@parvis.nl wrote: > I made a patch resulting in > > pango configure.ac:221 > -- > if $have_fontconfig ; then > pango_save_libs=$LIBS > LIBS="$LIBS $FONTCONFIG_LIBS" > -># AC_CHECK_FUNCS(FcWeightFromOpenTypeDouble) > ->cat >>confdefs.h <<_ACEOF > -> #define HAVE_FCWEIGHTFROMOPENTYPEDOUBLE 1 > -> _ACEOF > LIBS=$pango_save_libs > fi > > but Autoconf didn't run so configure was not updated so nothing changes. > > Q1: if the patch result correct? > Q2: How should I do this in Portfile ? To update configure you have to set use_autoconf or use_autoreconf. However you may be able to not patch anything and pass ac_cv_func_FcWeightFromOpenTypeDouble=yes to configure on the command line or in the environment. Or, update fontconfig to 2.13.0 and bypass the problem. - Josh
