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: http://www.lavluda.com/2009/07/08
So we use at least 12 digits. Woo.
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, un
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
http://lists.macosfo
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 upd
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
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
_
It isn't any worse than stealth updates: it would still be out of our hands, a
calculated risk.
Blair Zajac 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 increase the default
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"
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 d
On Oct 4, 2012, at 10:06 PM, Ryan Schmidt 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 Message:
>> ---
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
http://lists.macosforge.org/ma
> 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: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
> 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
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
> 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 afad8eca9
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 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
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
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 val
> 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
> sinc
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
At 9:03 AM -0700 10/5/12, Blair Zajac wrote:
On Oct 5, 2012, at 5:59 AM, Craig Treleaven 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: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 be
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 5:59 AM, Craig Treleaven 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 afad8eca960af3b61b0a8ee3e1c3e0db4cc5c8f
Regards,
Blair
On Oct 5, 2012, at 2:46 AM, 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.
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 build
> 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
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 b
On Oct 5, 2012, at 2:59 PM, Craig Treleaven wrote:
> Note that you don't need the full Git hash. I believe that the first 7
> characters is sufficient but I use 8. (Eg "afad8eca".) Makes paths a little
> less unwieldy!
Thanks, Craig!
Done in r98429.
Greets,
Marko
_
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 fig
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 whe
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 fro
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 t
> 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 f
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
> csvdb_free
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: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 automate
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
> PortGro
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: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 por
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?
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 fo
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
fetch.t
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(resu
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 -
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 cou
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?
Unfortun
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/Po
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 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__ ((deprec
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
http:
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
53 matches
Mail list logo
