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

> 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

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

Hello! I am creating a port for a Python program called "clustershell", and I'd like some advice as to how to handle a hard-coded config file search path. The clustershell program looks for configuration in a number of places, with "/etc/clustershell/" hard-coded as the first path, so I

Re: Proposal for a MacPorts'ish commit message template

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

Re: [macports-ports] branch master updated: octave-image: add cxx11 portgroup, remove gcc-4.2 from compiler blacklist

> On Nov 4, 2016, at 15:18, Marius Schamschula > wrote: > > Marius Schamschula (Schamschula) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/1119466ab172e47ff602563e691649f1cbcae0cc >

Re: PR usage by people with commit access

On 2016-11-5 06:14 , Daniel J. Luke wrote: On Nov 4, 2016, at 2:09 PM, Sterling Smith wrote: In the past, I have seen responses to svn changelogs directed to the committer and copied to the dev list, I expect that to continue to be the case. so apparently port

Re: PR usage by people with commit access

On Nov 4, 2016, at 2:09 PM, Sterling Smith wrote: > In the past, I have seen responses to svn changelogs directed to the > committer and copied to the dev list, I expect that to continue to be the case. > so apparently port maintainers who are committers are not always

Re: Pull Requests for Work in Progress (WIP)

On 4 November 2016 at 18:55, Marko Käning wrote: > > Besides there is even a clearly visible RED "Work-In-Progress" label > available in the PR interface, which Mojca had spotted eventually. I didn't spot it. I though it was useful and made it after this discussion was started. Mojca

Re: PR usage by people with commit access

On Nov 4, 2016, at 10:50AM, Rainer Müller wrote: > On 2016-11-04 18:10, Ivan Larionov wrote: > >> * Ability to get a feedback / review from other project members. >> >> We use private github setup on my work and we have a rule that you >> shouldn't commit directly to

Re: Pull Requests for Work in Progress (WIP)

On 04 Nov 2016, at 02:19 , Arno Hautala wrote: > But, it occurs to me that one of the goals of moving > to GitHub is greater collaboration and that is facilitated by inline > comments on the pull request. Plus, a completed pull request is one > comment away from a work in

Re: PR usage by people with commit access

> 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

Re: Pull Requests for Work in Progress (WIP)

Hi Rainer, On 03 Nov 2016, at 18:57 , Sterling Smith wrote: > On Nov 3, 2016, at 10:47AM, Rainer Müller wrote: > >> On 2016-11-03 17:49, Sterling Smith wrote: >>> The main question of procedure is: Should the main macports repo be >>> used for

Re: PR usage by people with commit access

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

Re: PR usage by people with commit access

Hi, On Fri, Nov 04, 2016 at 10:10:44AM -0700, Ivan Larionov wrote: > I think this is a good practice for port maintainers with write access > to repository still use PRs instead of direct commits to master. I agree, with some limitations: > * Better visibility of changes. Instead of cloning

Re: Proposal for a MacPorts'ish commit message template

> On Nov 4, 2016, at 1:43 PM, Marko Käning wrote: > >> On 04 Nov 2016, at 18:34 , Lawrence Velázquez wrote: >> >> It doesn't really do anything differently w.r.t. wrapping, but it >> highlights subject-line overflow in an alarming red color. > >

Re: Proposal for a MacPorts'ish commit message template

Hi Larry, On 04 Nov 2016, at 18:34 , Lawrence Velázquez 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. Will have to test whether that works as documented in our

Re: Proposal for a MacPorts'ish commit message template

On 02 Nov 2016, at 23:33 , Ryan Schmidt wrote: > ...my initial reaction to your template (and my initial reaction when I saw > it mentioned previously) was "TL;DR”. I got it now. :) >> vim does that with syntax highlighting automatically nowadays when it >> notices

Re: Proposal for a MacPorts'ish commit message template

On 02 Nov 2016, at 01:03 , Lawrence Velázquez wrote: > To be honest, this template adds so much comment noise that I can't > imagine ever using it. That’s fine ok, your decision. :) >> --- ~/.git-commit-template --- >> # Please enter the commit message for your changes.

Re: Proposal for a MacPorts'ish commit message template

> 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

Re: Proposal for a MacPorts'ish commit message template

Hi, On 02 Nov 2016, at 00:08 , Clemens Lang wrote: > Developers are free to use your template if they want to. We don't want > to mandate using it though (since we couldn't enforce it anyway). yeah, I am aware of that. > vim does that with syntax highlighting automatically

Re: How to keep uncommitted work in a git clone

On 2016-11-03, at 10:39 PM, David Bariod wrote: > Hello, > > Personnally, I would just commit such change. It is cheap, can be reworked > later and be ketp safe in a private remote repository in case of disaster. > With git there are no reason to not commit event not

PR usage by people with commit access

I think this is a good practice for port maintainers with write access to repository still use PRs instead of direct commits to master. I'm not saying that you have to wait for review or something like this, but opening a PR from your branch and then merging it has some pros: * Better

Re: rsync not being kept up to date?

On Fri, Nov 4, 2016 at 11:14 AM, Ryan Schmidt wrote: > What does this port contain? Does it download 2GB of data and repackage it? > Does it generate 2GB of data? It contains the output of numerical relativity simulations that routines in the lalsimualtion port read in

Re: rsync not being kept up to date?

On 2016-11-5 03:14 , Ryan Schmidt wrote: On Nov 4, 2016, at 08:03, Adam Mercer wrote: Or is there a way to tell the buildbot not to produce packages? Whether the buildbot distributes the binary is based on whether its stated license is distributable or not. But I'm

Re: Working with Git

On 2016-11-04 03:41, Lawrence Velázquez wrote: >> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt wrote: >> >> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git >> branch -d l2dy-curl-ca-bundle-update" failed because of an error. > > Do you remember what

Re: [MacPorts] CommittersGuide/PersonalSVNRepository modified

On 2016-11-04 05:01, Lawrence Velázquez wrote: >> On Nov 2, 2016, at 9:40 PM, MacPorts wrote: >> >> Page "CommittersGuide/PersonalSVNRepository" was changed by raimue >> Diff URL: >> >>

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On Friday November 04 2016 23:52:30 Joshua Root wrote: >We could really do without this kind of sarcastic, insinuated personal >attack. For the record, there was nothing personal intended in my remark; it was inspired by recent exchanges I've seen that involved more than just the 2 people

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

On 2016-11-4 19:36 , René J. V. Bertin wrote: Lawrence Velázquez wrote: Overall, can we just stop this discussion, please? We settled to stay 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

Re: How to keep uncommitted work in a git clone

On Fri, Nov 4, 2016 at 10:20 AM, Chris Jones wrote: > Hi, > > On 04/11/16 09:16, David Bariod wrote: > >> >> >> On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones > > wrote: >> >> >> >> On 04/11/16 05:39, David

Re: How to keep uncommitted work in a git clone

On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones wrote: > > > On 04/11/16 05:39, David Bariod wrote: > >> Hello, >> >> Personnally, I would just commit such change. It is cheap, can be >> reworked later and be ketp safe in a private remote repository in case >> of disaster.

Re: How to keep uncommitted work in a git clone

On 04/11/16 05:39, David Bariod wrote: Hello, Personnally, I would just commit such change. It is cheap, can be reworked later and be ketp safe in a private remote repository in case of disaster. With git there are no reason to not commit event not ready yet change set. I would not do this,

Re: How to keep uncommitted work in a git clone

On 04/11/16 04:18, Sterling Smith wrote: On Nov 3, 2016, at 7:54PM, Arno Hautala wrote: On Thu, Nov 3, 2016 at 9:56 PM, Ryan Schmidt wrote: Well, I tried that. I git stashed, then made changes to curl and committed them, and later when I

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

Lawrence Velázquez wrote: >>> Overall, can we just stop this discussion, please? We settled to stay > 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. So is this the kind of