Sorry, I missed your latest comments in the ticket.
On Apr 21, 2012, at 20:30, Sean Farley wrote:
I think the git.branch can be used interchangeably: it's both a tag or a
hash.
You mean having code that would look the following?
github.setupwilliamh dotconf 1.3 v
If the author
At 3:05 AM -0500 4/22/12, Ryan Schmidt wrote:
Sorry, I missed your latest comments in the ticket.
On Apr 21, 2012, at 20:30, Sean Farley wrote:
I think the git.branch can be used interchangeably: it's both a
tag or a hash.
You mean having code that would look the following?
github.setup
At 11:00 AM -0400 4/15/12, Michael Dickens wrote:
I'm still fighting with Qt patches right now. - MLD
How goes the battle?
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
Except some people still use snowleopard and as far as I could tell, ipfw
is still a valid command on Lion. Is it just ignored or can it still be
configured? If it's the latter, there's another reason for it to stay
enabled.
I would have preferred to see ONE sshguard port with variants.
-d
On
, for livecheck, this would use the rss to check the version
(since git.branch is set), correct?
* any unique identifier; perhaps 20120422 to mean the latest commit
as of this writing
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http
On Apr 22, 2012, at 11:26, Daniel wrote:
Except some people still use snowleopard and as far as I could tell, ipfw is
still a valid command on Lion. Is it just ignored or can it still be
configured? If it's the latter, there's another reason for it to stay enabled.
I would have preferred
is set), correct?
* any unique identifier; perhaps 20120422 to mean the latest commit
as of this writing
Yes, that's what I meant.
Any unique identifier should in addition be something that increases as seen
by ver-cmp; a date is probably a good type of number to use there; a hash is
probably
On 2012-4-23 06:51 , Ryan Schmidt wrote:
No, I'm trying to protect against the gzip compression of the tar archive
varying from generation to generation. gzip compression uses entropy --
random numbers. If you have two identical tar archives, and gzip compress
them with the same settings,
On Apr 22, 2012, at 16:21, Joshua Root wrote:
On 2012-4-23 06:51 , Ryan Schmidt wrote:
No, I'm trying to protect against the gzip compression of the tar archive
varying from generation to generation. gzip compression uses entropy --
random numbers. If you have two identical tar archives,
On 2012-4-23 07:27 , Ryan Schmidt wrote:
On Apr 22, 2012, at 16:21, Joshua Root wrote:
On 2012-4-23 06:51 , Ryan Schmidt wrote:
No, I'm trying to protect against the gzip compression of the tar archive
varying from generation to generation. gzip compression uses entropy --
random
On 2012-4-23 07:35 , Joshua Root wrote:
% openssl sha1 1/file.tar 2/file.tar
SHA1(1/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
SHA1(2/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
% gzip 1/file.tar
% gzip 2/file.tar
% openssl sha1 1/file.tar.gz 2/file.tar.gz
On Apr 22, 2012, at 16:35, Joshua Root wrote:
WFM:
% openssl sha1 1/file.tar 2/file.tar
SHA1(1/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
SHA1(2/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
% gzip 1/file.tar
% gzip 2/file.tar
% openssl sha1 1/file.tar.gz 2/file.tar.gz
Ah, you're right, they did not. Now I get the same sums, if both files have
not only the same name but also the same timestamp.
So I guess what a service like bitbucket would have to do when it generates a
tarball is to set its timestamp to the timestamp of the requested revision
before
that is better :)
On Sun, Apr 22, 2012 at 1:36 PM, Ryan Schmidt ryandes...@macports.orgwrote:
On Apr 22, 2012, at 11:26, Daniel wrote:
Except some people still use snowleopard and as far as I could tell,
ipfw is still a valid command on Lion. Is it just ignored or can it still
be
On Apr 21, 2012, at 5:05 PM, Ryan Schmidt wrote:
On Apr 21, 2012, at 16:28, Jeremy Lavergne wrote:
agreeing to the Xcode license from the command line - with xcodebuild
-license - but I still see this error.
Did you use sudo for that?
You're not supposed to use sudo with that.
On Apr 22, 2012, at 15:38, take...@macports.org wrote:
Revision: 92247
https://trac.macports.org/changeset/92247
Author: take...@macports.org
Date: 2012-04-22 13:38:10 -0700 (Sun, 22 Apr 2012)
Log Message:
---
fftw-3: add openmpi and mpich2 variants. closes #34148
I'm already using the latest base from trunk. Using sudo to accept the license
worked.
Thanks!
Frank
On Apr 21, 2012, at 5:38 PM, Jeremy Huddleston wrote:
You need to accept the XCode license. My guess is that you're not using a
recent version of base. Update to 2.0.4.
You can accept
Well if you were using trunk, then your user's acceptance status should've been
copied to the build user's $HOME, and you shouldn't need to accept it as root.
Adding jmr since I think he wrote the code that deals with that case.
--Jeremy
On Apr 22, 2012, at 16:28, Frank Schima
Getting closer. Things are about working on 10.6, and I'll test
on 10.7 tomorrow. So, hopefully Monday or Tuesday for qt4-mac. -
MLD
On Apr 22, 2012, at 11:25 AM, Craig Treleaven wrote:
At 11:00 AM -0400 4/15/12, Michael Dickens wrote:
I'm still fighting with Qt patches right now. - MLD
At 4:43 PM -0500 4/22/12, Ryan Schmidt wrote:
On Apr 22, 2012, at 16:35, Joshua Root wrote:
WFM:
% openssl sha1 1/file.tar 2/file.tar
SHA1(1/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
SHA1(2/file.tar)= 7937656d0860ca9286a24246a199cf2fddeb6e49
% gzip 1/file.tar
% gzip 2/file.tar
On Apr 22, 2012, at 1:36 PM, Ryan Schmidt wrote:
On Apr 22, 2012, at 11:26, Daniel wrote:
Except some people still use snowleopard and as far as I could tell, ipfw is
still a valid command on Lion. Is it just ignored or can it still be
configured? If it's the latter, there's another
On Apr 21, 2012, at 4:45 PM, Sean Farley wrote:
3) uniform versioning
For (3), I prefer ${last_known_version}-${date} but don't mind
changing this to something else as long as it's consistent.
Open question: what to do about projects that never version? Assign a
Regardless of what action
On Apr 22, 2012, at 20:45, Bradley Giesbrecht wrote:
On Apr 21, 2012, at 4:45 PM, Sean Farley wrote:
3) uniform versioning
For (3), I prefer ${last_known_version}-${date} but don't mind
changing this to something else as long as it's consistent.
Open question: what to do about
On Apr 22, 2012, at 20:05, Bradley Giesbrecht wrote:
On Apr 22, 2012, at 1:36 PM, Ryan Schmidt wrote:
On Apr 22, 2012, at 11:26, Daniel wrote:
Except some people still use snowleopard and as far as I could tell, ipfw
is still a valid command on Lion. Is it just ignored or can it still
On Apr 22, 2012, at 19:27, Craig Treleaven wrote:
At 4:43 PM -0500 4/22/12, Ryan Schmidt wrote:
On Apr 22, 2012, at 16:35, Joshua Root wrote:
Do your two input files also have identical timestamps?
Ah, you're right, they did not. Now I get the same sums, if both files have
not only the
On Apr 22, 2012, at 7:05 PM, Ryan Schmidt wrote:
On Apr 22, 2012, at 20:45, Bradley Giesbrecht wrote:
On Apr 21, 2012, at 4:45 PM, Sean Farley wrote:
3) uniform versioning
For (3), I prefer ${last_known_version}-${date} but don't mind
changing this to something else as long as it's
On Apr 22, 2012, at 7:07 PM, Ryan Schmidt wrote:
On Apr 22, 2012, at 20:05, Bradley Giesbrecht wrote:
On Apr 22, 2012, at 1:36 PM, Ryan Schmidt wrote:
On Apr 22, 2012, at 11:26, Daniel wrote:
Except some people still use snowleopard and as far as I could tell, ipfw
is still a
But want about when no version is present. Without some prefix mmdd makes
a real high version number.
Just make one up then? If you want to keep it low, use a prefix of something
like 0.0.
smime.p7s
Description: S/MIME cryptographic signature
On Apr 22, 2012, at 21:26, Bradley Giesbrecht wrote:
On Apr 22, 2012, at 7:07 PM, Ryan Schmidt wrote:
On Apr 22, 2012, at 20:05, Bradley Giesbrecht wrote:
Thanks Ryan. What about upgrades from pre-Lion to post-SL.
Is there an example port that has some sort of platform/os.version block
On Apr 22, 2012, at 22:20, Jeremy Lavergne wrote:
But want about when no version is present. Without some prefix mmdd
makes a real high version number.
Just make one up then? If you want to keep it low, use a prefix of
something like 0.0.
Yes, we could either use 0.0- or just accept
30 matches
Mail list logo
