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: opencv to be revbumped?

On 29 Nov 2016, at 01:44 , Marko Käning wrote: > I figure that I should have revbumped opencv2, right? I meant opencv, of course. Well, I’ll do the revbump once the install has finished successfully...

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

On Mon, Nov 28, 2016 at 7:41 PM, Karl Kornel wrote: > Yeah, I was thinking about variants, but then how best to things like > Python, with its multiple versions? I could do one variant per version, > but it would be nice if I could avoid that! I have seen a number of ports that do exactly that

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 29 Nov 2016, at 01:42 , Bradley Giesbrecht wrote: > Do you literally mean the second line blank, like this: Yes, Brad, check out the relevant wiki page at https://trac.macports.org/wiki/CommitMessages and see the example! Greets, Marko

opencv to be revbumped?

Hi devs, as - the new variant ‘avx2’ has been introduced - the default port’s configure options changed - python[23] handling has changed in commit https://github.com/macports/macports-ports/commit/14a1fa8d5e1d4e07a6f2538d1779f5f42714aed3 I figure that I should have revbumped op

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 4:20 PM, Lawrence Velázquez wrote: > > 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/2f43f23a572b620

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

On Nov 28, 2016, at 4:32 PM, Brandon Allbery wrote: > > >> On Mon, Nov 28, 2016 at 7:31 PM, A. Karl Kornel wrote: >> What makes this confusing is that additional language support is added by >> `configure` switches (like --with-python and --without-ocaml), so I don't >> think separate Portfil

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

On Mon, Nov 28, 2016 at 7:31 PM, A. Karl Kornel wrote: > What makes this confusing is that additional language support is added by > `configure` switches (like --with-python and --without-ocaml), so I don't > think separate Portfiles would be the best option here. I'm also not sure > if subports

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

Hello! 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" files. The API is written in C, but it also is able

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: Build Failure: gstreamer1-gst-plugins-bad, mesa, x265

Can you please grab a sysdiagnose before rebooting? That'll be a good first step. Once I see that, I might have some questions for next time. > On Nov 28, 2016, at 15:31, Ryan Schmidt wrote: > > > On Nov 27, 2016, at 7:49 PM, David Evans wrote: > >> On 11/27/16 5:10 PM, Jeremy Huddleston S

Re: Build Failure: gstreamer1-gst-plugins-bad, mesa, x265

On Nov 27, 2016, at 7:49 PM, David Evans wrote: > On 11/27/16 5:10 PM, Jeremy Huddleston Sequoia wrote: >> From: >> >> https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/11628/steps/install-port/logs/stdio >> >> DEBUG: Using compiler 'System cc' >> >> Why is that the c

Re: [macports-ports] branch master updated: lapack-manpages: update to 3.6.1

> On Nov 18, 2016, at 7:50 PM, Takeshi wrote: > > tenomoto pushed a commit to branch master > in repository macports-ports. > > > https://github.com/macports/macports-ports/commit/005bd26a6c4195d468735b3e33cb31b5bc596d99 > > The following commit(s) were added to refs/heads/master by this push

Re: `git describe`

> On Nov 28, 2016, at 3:28 PM, René J.V. Bertin wrote: > >> As you discovered yourself now, 'port version' of master identifies >> itself as 2.3.99 at the moment. > > Yes, and if you look at the history of the script in config that sets that > version, it apparently has been fixed at 2.3.99 fo

Re: `git describe`

On Monday November 28 2016 20:16:17 Rainer Müller wrote: >No, not at all. What you might see there are not the same commit >objects, as the changes were cherry-picked from master to release-2.3. I'll take your word for it, it's much easier to compare commit messages than random commit hashes. >

Re: `git describe`

On 2016-11-28 13:41, René J.V. Bertin wrote: > On Monday November 28 2016 12:54:35 Rainer Müller wrote: > >> The release was done from the release-2.3 branch, which has >> diverged from the master branch. There is no way to merge either >> branch to the other. I do not see any importance in gettin

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: [macports-ports] branch master updated: x265: update to 2.1

Hi Kurt, - On 24 Nov, 2016, at 19:12, Kurt Hindenburg khindenb...@macports.org wrote: > Kurt Hindenburg (kurthindenburg) pushed a commit to branch master > in repository macports-ports. > > https://github.com/macports/macports-ports/commit/7f2cec2bec0559005bb31e74ad3da3f0be7eea6d > > The fo

Re: `git describe`

FWIW, running configure in the current master/head prints "MacPorts version 2.3.99", which complies with common practice I see elsewhere ... except that here it's a hard-coded version. R.

Re: "catch" wrapper (commit 0ecff30a328993179b757a13830a1a5249839dd8)

On Monday November 28 2016 15:33:22 Clemens Lang wrote: >> So in practice the number of call levels didn't change > >Correct. Ok, I should have asked that then. >The number of backslashes isn't related to the number of call levels >anyway. It's just about the number of stack frames added by a cat

Re: "catch" wrapper (commit 0ecff30a328993179b757a13830a1a5249839dd8)

Hi, - On 28 Nov, 2016, at 14:34, René J.V. Bertin rjvber...@gmail.com wrote: > So in practice the number of call levels didn't change Correct. > and one doesn't have to worry about the number of backslashes, for > instance? The number of backslashes isn't related to the number of call leve

Re: "catch" wrapper (commit 0ecff30a328993179b757a13830a1a5249839dd8)

On Monday November 28 2016 13:56:50 Clemens Lang wrote: Hi, >No. It only means that we had to use a different method to replace the catch >command in Portfiles. So in practice the number of call levels didn't change and one doesn't have to worry about the number of backslashes, for instance?

Re: "catch" wrapper (commit 0ecff30a328993179b757a13830a1a5249839dd8)

Hi, - On 28 Nov, 2016, at 10:05, René J.V. Bertin rjvber...@gmail.com wrote: > The new catch command >> can't simply be aliased in to the slaves like we >> normally do for shared commands because it uses uplevel and aliases add >> an extra call level. > > Does this mean that every ex

Re: `git describe`

On Monday November 28 2016 12:54:35 Rainer Müller wrote: > The release was done from the release-2.3 branch, which has diverged > from the master branch. There is no way to merge either branch to the > other. I do not see any importance in getting this tag to the master branch. > > Fact is, maste

Re: `git describe`

On 2016-11-28 12:43, René J.V. Bertin wrote: > I checked: the release-2.3 branch has seen only a single commit after > v2.3.5, all other commits done since were done on the master branch > after the 2.3 branch was merged. If there's a good reason not to > apply the tag to the main branch (too) I fa

Re: `git describe`

On Monday November 28 2016 12:15:59 Rainer Müller wrote: > > I presume that means they merge the development branch into master > > before creating the release. > > Maybe. I do not want to dive deep into the release workflow of other > projects. I can understand, but doing things that way makes

Re: `git describe`

On 2016-11-28 11:44, René J.V. Bertin wrote: > I presume that means they merge the development branch into master > before creating the release. Maybe. I do not want to dive deep into the release workflow of other projects. > Possibly: > > %> port provides /opt/local/bin/git-release > /opt/loca

Re: `git describe`

On Monday November 28 2016 10:45:39 Rainer Müller wrote: >What you expected would only work with an entirely linear history >without branches. That's not my experience with the KDE repositories I'm working with. They too have repos where development is done on release branches and then merged in

Re: `git describe`

On 2016-11-28 10:18, René J.V. Bertin wrote: > Git has a very useful feature when tags are used properly, where each > commit increases a counter so that the `git describe` command returns > the current release version plus a patchlevel. I use this in certain > of my KF5 -devel ports but one can al

`git describe`

Hi, Git has a very useful feature when tags are used properly, where each commit increases a counter so that the `git describe` command returns the current release version plus a patchlevel. I use this in certain of my KF5 -devel ports but one can also imagine a MacPorts-devel (or -testing or -

"catch" wrapper (commit 0ecff30a328993179b757a13830a1a5249839dd8)

Hi, Looking at upgrading my MacPorts base I noticed this tidbit in the commit 0ecff30a328993179b757a13830a1a5249839dd8 message: The new catch command > can't simply be aliased in to the slaves like we > normally do for shared commands because it uses uplevel and aliases add > an extra ca