On Oct 4, 2012, at 5:52 AM, m...@macports.org wrote:
+pre-configure {
+ system cd ${worksrcpath}; autoreconf -i
+}
Use use_autoreconf instead ...
use_autoreconf yes
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On Oct 5, 2012, at 11:00 AM, Jeremy Huddleston Sequoia wrote:
Use use_autoreconf instead ...
Thanks Jeremy!
Done in r98419.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
On Oct 4, 2012, at 07:52, m...@macports.org wrote:
Revision: 98388
http://trac.macports.org//changeset/98388
Author: m...@macports.org
Date: 2012-10-04 05:52:38 -0700 (Thu, 04 Oct 2012)
Log Message:
---
csvdb: new port
Added: trunk/dports/databases/csvdb/Portfile
On Oct 5, 2012, at 11:12 AM, Ryan Schmidt wrote:
Please use the github portgroup, and if possible, allow it to fetch from a
distfile instead of from the git repository itself.
Ryan, could you please name a portfile where I could have a look at how the
github portgroup is to be used?
On Oct 5, 2012, at 2:16 AM, mk-macpo...@techno.ms wrote:
On Oct 5, 2012, at 11:12 AM, Ryan Schmidt wrote:
Please use the github portgroup, and if possible, allow it to fetch from a
distfile instead of from the git repository itself.
Ryan, could you please name a portfile where I could
On Oct 5, 2012, at 11:30 AM, Ryan Schmidt wrote:
The best documentation is to read the portgroup itself:
:)
and some ports that use it. You can see the list of ports using the github
portgroup by running this command:
port file all | sort -u | xargs grep -E 'PortGroup\s+github' | cut -d :
On Oct 5, 2012, at 11:24 AM, Jeremy Huddleston Sequoia wrote:
devel/git-extras/Portfile
Thanks, Jeremy.
In the meantime I have found and used git-flow as an example to come up with
this:
---
PortSystem 1.0
PortGroup github 1.0
github.setupdarkrose csvdb 0.5.1
On Oct 5, 2012, at 11:30 AM, Ryan Schmidt wrote:
http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/github-1.0.tcl
Wouldn't it be advisable to include
---
depends_build-append port:git-core
---
in that portgroup, since git-core is a necessary dep in any case?
On Oct 5, 2012, at 04:49, mk-macpo...@techno.ms wrote:
On Oct 5, 2012, at 11:30 AM, Ryan Schmidt wrote:
http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/github-1.0.tcl
Wouldn't it be advisable to include
---
depends_build-append port:git-core
---
in that portgroup,
On Oct 5, 2012, at 11:54 AM, Ryan Schmidt wrote:
No, it's never needed at build time, and it's only needed at fetch time if
fetch.type is git, in which case MacPorts base will add that dependency for
you (regardless of whether you're using the github portgroup or not).
OK, then it was just
On Oct 5, 2012, at 04:46, mk-macpo...@techno.ms wrote:
On Oct 5, 2012, at 11:24 AM, Jeremy Huddleston Sequoia wrote:
devel/git-extras/Portfile
Thanks, Jeremy.
In the meantime I have found and used git-flow as an example to come up with
this:
---
PortSystem 1.0
PortGroup
On Oct 5, 2012, at 11:59 AM, Ryan Schmidt wrote:
You can remove the name line; github.setup sets it for you.
OK.
You can remove the master_sites line; github.setup sets it for you.
OK.
use_bzip2 yes
Most projects on github use gz files not bz2 files. Certainly the automated
On Oct 5, 2012, at 12:02 PM, Ryan Schmidt wrote:
Replacing \s+ with .* however helped.
Ah. I have the grep port installed, so perhaps that version is a little
different from the one that comes with OS X.
Yep. I didn't have it installed.
Installing MacPorts' grep solved the issue. :-)
At 12:02 PM +0200 10/5/12, mk-macpo...@techno.ms wrote:
Failing that, yes, you'd need to continue to specify a changeset.
I think you can do it this way:
github.setupdarkrose csvdb afad8eca960af3b61b0a8ee3e1c3e0db4cc5c8f5
version 0.5.1
Yeah, just a minute ago I
On Oct 5, 2012, at 5:59 AM, Craig Treleaven ctrelea...@cogeco.ca wrote:
At 12:02 PM +0200 10/5/12, mk-macpo...@techno.ms wrote:
Failing that, yes, you'd need to continue to specify a changeset. I think
you can do it this way:
github.setupdarkrose csvdb
On Oct 5, 2012, at 6:03 PM, Blair Zajac wrote:
Given we're moving to ever longer checksums in our Portfiles, it seems best
to use the full sha.
Hmm, you are right…
BTW, what happens if there is a duplicate truncated sha?
… which of course could happen, but with very low probability, I guess.
At 9:03 AM -0700 10/5/12, Blair Zajac wrote:
On Oct 5, 2012, at 5:59 AM, Craig Treleaven ctrelea...@cogeco.ca wrote:
At 12:02 PM +0200 10/5/12, mk-macpo...@techno.ms wrote:
Failing that, yes, you'd need to continue to specify a
changeset. I think you can do it this way:
github.setup
On Oct 5, 2012, at 6:27 PM, Craig Treleaven wrote:
I can't find an 'official' reference for it, but I believe GitHub says that 7
characters are unique (7**26).
I see.
Anyway, if it were not unique, the MacPorts checksums would alert the user.
Seems safe to me.
Checksums?
If sources are
I can't find an 'official' reference for it, but I believe GitHub says that 7
characters are unique (7**26). Anyway, if it were not unique, the MacPorts
checksums would alert the user. Seems safe to me.
I also use the short hash as part of the full version string for the port
since it
On Oct 5, 2012, at 6:39 PM, Jeremy Lavergne wrote:
Feel free to use `$ git log --abbrev-commit --pretty=oneline` to find out
just how long your hash needs to be to be guaranteed unique in the
repository. Seven is the default, but it will increase if necessary.
Still, this would be only valid
On 2012-10-05 18:32, mk-macpo...@techno.ms wrote:
On Oct 5, 2012, at 6:27 PM, Craig Treleaven wrote:
I can't find an 'official' reference for it, but I believe GitHub says that
7 characters are unique (7**26).
I see.
They are not unique, it's just unlikely that conflicts would occur in
such
On Oct 5, 2012, at 9:27 AM, Craig Treleaven wrote:
At 9:03 AM -0700 10/5/12, Blair Zajac wrote:
On Oct 5, 2012, at 5:59 AM, Craig Treleaven ctrelea...@cogeco.ca wrote:
At 12:02 PM +0200 10/5/12, mk-macpo...@techno.ms wrote:
Failing that, yes, you'd need to continue to specify a changeset.
I believe there have been discussions for reasons to not use changeset hashes
in MacPorts version strings.
Maybe the hashes are not always greater strings to MacPorts vercmp?
That's why his example redefines version immediately following...
github.setupdarkrose csvdb
On 2012-10-6 03:00 , Bradley Giesbrecht wrote:
I believe there have been discussions for reasons to not use changeset hashes
in MacPorts version strings.
Maybe the hashes are not always greater strings to MacPorts vercmp?
Yes, exactly. Commit hashes vary pseudo-randomly as the version
Still, this would be only valid for all existing hashes. Imagine a new
changeset would appear which would increase the default to 8.
If that short hash had been used at MacPorts it would likely cause an error,
wouldn't it.
Given that their book says the largest git repositories they've seen
On Oct 5, 2012, at 7:02 PM, Jeremy Lavergne wrote:
I believe there have been discussions for reasons to not use changeset
hashes in MacPorts version strings.
Maybe the hashes are not always greater strings to MacPorts vercmp?
That's why his example redefines version immediately
Wondering as to why livecheck uses the hash and not the version specified.
If you're using hashes then we already know we cannot assume the existence of a
tag for the version you want.
A portfile's `version` cannot be used if there isn't a repository `tag` of the
same version.
On Oct 5, 2012, at 7:19 PM, Jeremy Lavergne wrote:
A portfile's `version` cannot be used if there isn't a repository `tag` of
the same version.
q.e.d. :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On 10/05/2012 10:06 AM, Jeremy Lavergne wrote:
Still, this would be only valid for all existing hashes. Imagine a new
changeset would appear which would increase the default to 8.
If that short hash had been used at MacPorts it would likely cause an error,
wouldn't it.
Given that their book
It isn't any worse than stealth updates: it would still be out of our hands, a
calculated risk.
Blair Zajac bl...@orcaware.com wrote:
On 10/05/2012 10:06 AM, Jeremy Lavergne wrote:
Still, this would be only valid for all existing hashes. Imagine a
new changeset would appear which would
On 10/05/2012 05:53 PM, Jeremy Lavergne wrote:
It isn't any worse than stealth updates: it would still be out of our hands, a
calculated risk.
Choosing a short hash is always ones own fault and one would then have
to clean it up, unlike stealth updates which are caused by upstream.
Blair
At 6:01 PM -0700 10/5/12, Blair Zajac wrote:
On 10/05/2012 05:53 PM, Jeremy Lavergne wrote:
It isn't any worse than stealth updates: it would still be out of
our hands, a calculated risk.
Choosing a short hash is always ones own fault and one would then
have to clean it up, unlike stealth
On 2012-10-6 11:49 , Craig Treleaven wrote:
there are 26 alpha and 10 numeric
characters available in each position.
Aren't hashes generally written in hexadecimal?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
So we use at least 12 digits. Woo.
Blair Zajac bl...@orcaware.com wrote:
On 10/05/2012 05:53 PM, Jeremy Lavergne wrote:
It isn't any worse than stealth updates: it would still be out of our
hands, a calculated risk.
Choosing a short hash is always ones own fault and one would then have
to
34 matches
Mail list logo
