Re: Best practice for port contributors in github world

> On Dec 13, 2016, at 7:56 AM, Luc Bourhis wrote: > > file://path/to/my/clone/of/macports-ports [default] Note that you have to use three slashes at the beginning of this line because the "/" that begins the absolute path is distinct from the "://" that separates the protocol. So: file:///pat

Re: [macports-ports] branch master updated: phonon-backend-gstreamer(-qt5): update to 4.9.0 and introduce new subport

> On Dec 12, 2016, at 11:46 PM, Marko Käning wrote: > > Yet, the git metadata is - also to my surprise - still valid, which can be > verified by clicking all the links on the commit’s page: > > > https://github.com/macports/macports-ports/commit/47c0c4f682b22803ae250258187544187d50f898

Re: [macports-ports] branch master updated: phonon-backend-gstreamer(-qt5): update to 4.9.0 and introduce new subport

Please clean up the commit message when you perform squash merges. Most of the text here is outdated Git metadata (old SHA-1 hashes, repeated author name, irrelevant authorship dates). vq > On Dec 12, 2016, at 10:54 PM, Marko Käning wrote: > > Marko Käning (mkae) pushed a commit to branch mas

Commits that implicitly close PRs do not remember doing so

> On Dec 6, 2016, at 10:33 AM, Rainer Müller wrote: > > (e) add "Closes: #XYZ" to the commit message When commits close PRs implicitly (by merging the PR branch) instead of explicitly (by using "closes #XYZ" in the message), the PR is remembered internally by GitHub and displayed on the websit

Re: PR final steps (to squash or not to squash)

> On Dec 6, 2016, at 10:33 AM, Rainer Müller wrote: > >> On 2016-12-06 14:36, Mojca Miklavec wrote: >> >> When someone submits a pull request (let's assume that it's already >> perfect) and a committer fetches it, rebases it and commits it to the >> master, then the PR is not automatically linke

Re: PR final steps (to squash or not to squash)

> On Dec 5, 2016, at 7:37 AM, René J.V. Bertin wrote: > > I guess we all have better things to do than this kind of task. Our commit history is essentially communication with future committers about what we did and why. Like any other communication, it should be clear and useful. Much like writ

Re: PR final steps (to squash or not to squash)

> On Dec 5, 2016, at 10:38 AM, René J.V. Bertin wrote: > >> On Monday December 05 2016 14:58:08 Rainer Müller wrote: >> >> What would be easier than just checking out the updated Portfile? You >> can also just download the patch and apply it. Open for suggestions. > > In this case that would pr

Re: PR final steps (to squash or not to squash)

> On Dec 5, 2016, at 8:57 PM, Zero King wrote: > >> From what I understand, what we'd really like for that case is >> a "squash, rebase and merge" option. Unless we've misunderstood what >> "squash and merge" does and it doesn't actually create a merge >> commit? > > No, it doesn't. See https://

Re: PR final steps (to squash or not to squash)

> On Dec 5, 2016, at 5:14 AM, Mojca Miklavec wrote: > > Usually "larryv" is the one who takes most care to split commits Hey now, why the scare quotes? :) vq

Re: How should ports refer to the 2-clause BSD license?

> On Dec 4, 2016, at 12:11 PM, Ryan Schmidt wrote: > >> On Dec 4, 2016, at 10:49, Lawrence Velázquez wrote: >> >> The checking script only mentions BSD (3-clause) and BSD-old >> (4-clause). > > As far as I was aware, we were referring to all three version

How should ports refer to the 2-clause BSD license?

The checking script only mentions BSD (3-clause) and BSD-old (4-clause). vq

Re: [macports-ports] branch master updated: sqlite3: revert to editline

You didn't remove the readline dependency. vq > On Dec 3, 2016, at 10:21 PM, Marius Schamschula wrote: > > Marius Schamschula (Schamschula) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/b510ccebf141f1f4e0e9275a2cab0baa28f

Re: port requires c++1y -> use cxx11 portgroup?

> On Dec 3, 2016, at 3:42 PM, Ken Cunningham > wrote: > >> C++1y and C++14 are the same. > > Apparently not exactly the same — somewhere in Pingus or its included > bits there was a specific note about changing back to c++1y as some > compilers accepted that but not c++14. "C++1y" was the work

Re: port requires c++1y -> use cxx11 portgroup?

> On Dec 3, 2016, at 2:09 PM, Ken Cunningham > wrote: > > The pingus port I put up last night (and which Ryan so kindly fixed > while I was sleeping for a missing dependency and an error on > case-sensitive file systems - gotta love those buildbots for finding > these things - and thanks for tha

Re: [macports-ports] branch master updated: pingus: new port submission

> On Dec 3, 2016, at 6:01 AM, Ken Cunningham > wrote: > > tobypeterson pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/d9673942b719a31aee1623f64d765e57de401dc5 > >

Re: Tcl list-related 2.3.4 -> 2.3.5 changes?

> On Dec 2, 2016, at 8:47 PM, Joshua Root wrote: > >> On 2016-12-3 02:45, René J.V. Bertin wrote: >> >> Hi, >> >> I'm trying to understand a regression that seems coupled to the >> 2.3.4 -> 2.3.5 upgrade (or more exactly, "master just after 2.3.4" >> -> "master 25 commits after 2.3.5"). >> >>

Re: ports using scons build system

Hi Ken, > On Nov 30, 2016, at 8:23 PM, Ken Cunningham > wrote: > > Would anyone like to point me towards a port that uses the scons build > system properly in Macports? > > I have an idea how to go about importing all the build environment > variables, but I don’t want to go to all the trouble

Re: Porting software that wants to build/install its own language bindings

> On Nov 28, 2016, at 7:31 PM, A. Karl Kornel wrote: > > I am looking for advice on how best to handle a port for a program > that wants to build its own language bindings. > > I am writing a port for a program called "hivex", which is a tool and > an API for manipulating Windows Registry "hive"

Re: [macports-ports] branch master updated: databases/percona: Fixed percona download URL to use version_branch again. Removed $Id$ tag. Closes; #62 Closes: https://trac.macports.org/ticket/52664 Clos

> On Nov 28, 2016, at 7:42 PM, Bradley Giesbrecht wrote: > > In IRC I wasn’t sure how to read Clemens comment: "Yes, Closes: > $ticketlink, due to the length on their own lines, preferably” > > I thought maybe a single long line commit message was not preferable. That's right, otherwise you'd h

Re: [macports-ports] branch master updated: databases/percona: Fixed percona download URL to use version_branch again. Removed $Id$ tag. Closes; #62 Closes: https://trac.macports.org/ticket/52664 Clos

Hi, > On Nov 28, 2016, at 7:13 PM, Roger Ward wrote: > > Bradley Giesbrecht (pixilla) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/2f43f23a572b62018bd0e4c0182df99f1a9bcd34 > >

Re: `git describe`

> On Nov 28, 2016, at 7:41 AM, René J.V. Bertin wrote: > > This is moot if master is exclusively a testing area for experiments > that may never make it to a release. If it has a more usual role and > is used by those who live on the bleeding edge, then my point stands All development is done on

Re: How best to submit new port to maintainer, in a world of Github?

> On Nov 26, 2016, at 6:25 PM, A. Karl Kornel wrote: > > I have a question about how best to deal with submitting a port update > to an existing maintainer, in the new Git setup. > > The port in question is "libvirt", which has Ryan as maintainer, but > also has openmaintainer listed. The "open

Re: [macports-infrastructure] branch mprsyncup-polish created (now 0a20565)

> On Nov 24, 2016, at 11:33 PM, Ryan Schmidt wrote: > > 6 copies of these changes arrived to the list: 1 when you created the > branch, 4 when you updated the branch (perhaps by force-pushing to > it?), and 1 when you merged the branch to master. Yeah sorry, I force-pushed a few times (and once

Re: [macports-infrastructure] branch mprsyncup-polish created (now 0a20565)

> On Nov 24, 2016, at 11:36 PM, Ryan Schmidt wrote: > > On second thought it looks like you haven't merged this to master yet. > Anything you're still waiting on before doing so? No, was just waiting to see if anyone else had feedback. I'll merge it now. vq

Re: [MacPorts] #52699: cmake portgroup version 1.1

> On Nov 24, 2016, at 11:16 AM, René J.V. Bertin wrote: > > On Thursday November 24 2016 14:45:33 MacPorts wrote: > >> I’m not convinced that this should remain. Since it’s created in >> `workpath`, it still gets trashed on `port clean`, so I don’t see how it’s >> any more permanent than the log

Re: port:libressl vs port:openssl, path-style variants and prebuilt binaries

> On Nov 22, 2016, at 4:54 AM, Mojca Miklavec wrote: > >> On 21 November 2016 at 14:23, René J.V. Bertin wrote: >> >> Is there anything currently in MacPorts that avoids issues that will >> probably arise when you install libressl and then pull in a prebuilt >> binary that will supposedly be bui

Re: [macports-ports] 03/03: shared-mime-info: Declare lack of libraries

> On Nov 20, 2016, at 12:39 PM, Ryan Schmidt wrote: > > Why increase revision? This does not change installed files; it just > makes a declaration that the installed files do not contain libraries. Sorry, error on my part. vq

Re: [MacPorts] InterMapTxt modified

> On Nov 18, 2016, at 8:16 AM, Rainer Müller wrote: > > I was not aware we had these macros. Are they in use anywhere? Not that I'm aware of. I added them back on OldTrac on a lark but didn't tell anybody. I might have used them once or twice; they're nifty. vq

Re: [macports-ports] branch master updated: pkcs11-helper: New port Closes: https://trac.macports.org/ticket/51906

Hello, > On Nov 18, 2016, at 11:26 AM, Frank Schima wrote: > > Author: Frank Schima > AuthorDate: Fri Nov 18 09:06:01 2016 -0700 > > pkcs11-helper: New port > Closes: https://trac.macports.org/ticket/51906 Please remember to keep the second line of commit messages blank. Some tools tr

Stop "replacing" existing Trac tickets with GitHub pull requests

I know you all think GitHub pull requests are the bee's knees, but please DO NOT open pull requests to "replace" existing Trac tickets. It doesn't actually help committers evaluate submissions, and it splits the discussion across Trac and GitHub. vq

Re: [macports-ports] 02/02: py-geopy: delete py26 and py33 subports. See also https://trac.macports.org/ticket/52881

> On Nov 16, 2016, at 4:40 PM, Mark Moll wrote: > > Mark Moll (mamoll) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/feb1081ffcbf1d0b06250a9f20c1095f8c4cbb67 > >

Re: Another workflow (pull requests) question.

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

Re: Backport or not: [macports-base] Support multi-valued maintainers

> On Nov 12, 2016, at 3:50 PM, Ryan Schmidt wrote: > > One consequence that occurs to me is that people using master > currently have version 2.3.99. If we branch 2.4 from 2.3, then when > those users run selfupdate they would be "upgraded" to 2.4 which > doesn't contain all the features they had

Re: Backport or not: [macports-base] Support multi-valued maintainers

> On Nov 12, 2016, at 12:44 PM, Rainer Müller wrote: > >> On 2016-11-12 17:39, Ryan Schmidt wrote: >> >> Perhaps it should more properly be called 2.4, but since our master >> is in no fix state to be branched for 2.4 at this time and we are >> still figuring out our release process on GitHub, i

Re: [macports-ports] 03/03: lbdb: Update to 0.42

> On Nov 10, 2016, at 9:57 AM, Ryan Schmidt wrote: > >> On Nov 10, 2016, at 8:55 AM, Rainer Müller wrote: >> >> "Resolves" is not a keyword recognized by the CommitTicketUpdater, >> use "Closes", "Fix", or "Fixes". > > Can't remember what it supports. > > It should recognize "Resolves"; we've

Re: [macports-base] branch master updated: Fix version check for Git autostashing

> On Nov 7, 2016, at 4:00 PM, Clemens Lang wrote: > > Please fix the test in src/macports1.0/tests/macports.test, too. Oops, sorry. https://github.com/macports/macports-base/commit/f4f2fbf9062ef8b365b2e291f34889f83883f7f0 vq

Re: GitHub migration complete

> On Nov 7, 2016, at 12:39 PM, Lawrence Velázquez wrote: > >> On Nov 7, 2016, at 12:29 PM, René J.V. Bertin wrote: >> >> As long as it doesn't cause problems elsewhere I think there >> shouldn't be any hard rules making this kind of thing impossibl

Re: GitHub migration complete

> On Nov 7, 2016, at 12:29 PM, René J.V. Bertin wrote: > >> On Monday November 07 2016 11:52:17 Lawrence Velázquez wrote: >> >> Any sort of Git keyword expansion must happen client-side, which means >> such keywords/markers would only be useful to developers wh

Re: PR usage by people with commit access

> On Nov 5, 2016, at 1:03 PM, Marko Käning wrote: > >> On 04 Nov 2016, at 19:00 , Lawrence Velázquez wrote: >> >> 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 ge

Re: GitHub migration complete

> On Nov 7, 2016, at 11:16 AM, René J.V. Bertin wrote: > > Well, yes, I was indeed thinking about something more readable than > the old syntax (though I don't see what'd be wrong with making it > compatible with the `what` command). Any sort of Git keyword expansion must happen client-side, whi

Re: [macports-ports] branch master updated: misc: follow up on base changes and mass-unbreak ports in trace mode.

> On Nov 7, 2016, at 10:37 AM, Rainer Müller wrote: > > Multiple of the affected ports just change the '.cmd' to 'autogen.sh'. > Would it make sense to have an additional use_autogensh that defaults to > this and adds dependencies on autoconf, automake, libtool? This is a good idea. Over 200 por

Re: GitHub migration complete

> On Nov 7, 2016, at 8:15 AM, René J.V. Bertin wrote: > > Well, I find it very practical to have a quick way to know when a file > was last changed that doesn't involve git magic like wading through > `git blame` output or simply invoking an external command. Of course > YMMV and it's not somethi

Re: Proposal for a MacPorts'ish commit message template

> On Nov 7, 2016, at 6:38 AM, Thibaut Paumard wrote: > > I don't know whether I'll use your template (probably not) but at least > seeing it here taught me a lot about git(hub) commit messages that I'll > use in this project and others. > > I'll welcome finding all this information for reference