On Oct 4, 2012, at 10:28 AM, mk-macpo...@techno.ms wrote:
On Oct 4, 2012, at 6:57 PM, Rainer Müller wrote:
This syntax is only supported as of gcc 4.5.0 [1,2].
Thanks Rainer for your advice!
I modified the two patches accordingly in r98400.
Looks like you made a copy/paste-o for one of
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 10:54 AM, Jeremy Huddleston Sequoia wrote:
Looks like you made a copy/paste-o for one of them:
-void result_free(result_t *r) __attribute__ ((weak, alias
(csvdb_free_result)));
-+void result_free(result_t *r);
++void result_free(result_t *r) __attribute__ ((deprecated));
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 2:02 AM, mk-macpo...@techno.ms wrote:
On Oct 5, 2012, at 10:54 AM, Jeremy Huddleston Sequoia wrote:
Looks like you made a copy/paste-o for one of them:
-void result_free(result_t *r) __attribute__ ((weak, alias
(csvdb_free_result)));
-+void result_free(result_t *r);
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
We continue to receive bug reports from users on Snow Leopard with Xcode 4.2
(and therefore no /usr/bin/gcc-4.2), who receive a package from our packages
server that was built by the Snow Leopard buildbot which has Xcode 3.2.6 (and
therefore builds things using /usr/bin/gcc-4.2), specifically
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. :-)
On Oct 5, 2012, at 11:37 AM, Jeremy Huddleston Sequoia wrote:
Your changes would present a message of deprecation at compile time if
someone used result_free, but the resulting executable would fail to link. I
fixed such that it the call to result_free() would be rewritten to
But if we restrict MacPorts to fetch only packages built of the same compiler
and/or Xcode version, then we'd need more buildbots to build those extra
packages.
We don't really need more than one buildbot per OS: we simply restrict what we
build to the most current free version of Xcode for
On 2012-10-04 22:25, Jack Howarth wrote:
Note this issue is described in http://llvm.org/bugs/show_bug.cgi?id=6.
The alternative of using weakref's apparently requires these be static...
http://www.lsd.ic.unicamp.br/~oliva/writeups/weakref/weakref.txt
Thanks for the links. I thought the
Hey,
this is regarding your addition to the MacPorts wiki at
https://trac.macports.org/wiki/howto/PatchLocal
First of all, this is a great idea for a tutorial. Thank you for your
contribution. However, I have some notes on this topic:
Users should not apply patches directly in sources synced
On Oct 5, 2012, at 2:16 PM, Rainer Müller wrote:
We should avoid documenting the same things at multiple places (as we
experienced with our installation instructions as they are now shattered
across the wiki, the website and the guide in different versions). For
+1
I have no preference
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
At 8:03 AM -0400 10/5/12, Jeremy Lavergne wrote:
But if we restrict MacPorts to fetch only packages built of the
same compiler and/or Xcode version, then we'd need more buildbots to
build those extra packages.
We don't really need more than one buildbot per OS: we simply
restrict what we
Umm, I thought XCode 4.2, specifically, was generally considered to be
less-than-optimal (aka buggy)?
That too.
Xcode 4.2 isn't available for Snow Leopard except for paid accounts--it really
shouldn't even be considered.
___
macports-dev mailing
On 2012-10-5 19:46 , Ryan Schmidt wrote:
We continue to receive bug reports from users on Snow Leopard with Xcode 4.2
(and therefore no /usr/bin/gcc-4.2), who receive a package from our packages
server that was built by the Snow Leopard buildbot which has Xcode 3.2.6 (and
therefore builds
Regards,
Blair
On Oct 5, 2012, at 2:46 AM, Ryan Schmidt ryandes...@macports.org wrote:
We continue to receive bug reports from users on Snow Leopard with Xcode 4.2
(and therefore no /usr/bin/gcc-4.2), who receive a package from our packages
server that was built by the Snow Leopard
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.
On Oct 5, 2012, at 6:38 AM, Jeremy Lavergne wrote:
Umm, I thought XCode 4.2, specifically, was generally considered to be
less-than-optimal (aka buggy)?
That too.
Xcode 4.2 isn't available for Snow Leopard except for paid accounts--it
really shouldn't even be considered.
I believe
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 Oct 4, 2012, at 10:06 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Oct 4, 2012, at 17:06, aron...@macports.org wrote:
Revision: 98411
http://trac.macports.org//changeset/98411
Author: aron...@macports.org
Date: 2012-10-04 15:06:18 -0700 (Thu, 04 Oct 2012)
Log
On Oct 5, 2012, at 13:33, Leo Singer wrote:
On Oct 4, 2012, at 10:06 PM, Ryan Schmidt wrote:
Usually we want the opposite: the livecheck enabled on the main port only,
and disabled on the subports.
Thanks. Fixed in r98437. Is it possible/advisable to have the Python
portgroup do that
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
On Oct 5, 2012, at 07:03, Jeremy Lavergne wrote:
We don't really need more than one buildbot per OS: we simply restrict what
we build to the most current free version of Xcode for each OS.
That would be another good thing to do, but we don't do it currently. Our Lion
buildbot has not been
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
hi,
can someone please update the gearmand package ? it's too much outdated.
current stable release is 1.1.1 where the macports version is 0.34.
i need this package badly.
thanks for your effort.
--
S. M. Ibrahim Lavlu
my blog: http://www.lavluda.com
my book:
52 matches
Mail list logo
