On 2016-7-20 01:09 , Ryan Schmidt wrote:
sources.conf used to default to:
rsync://rsync.macports.org/release/ports/ [default]
Since r79599 it defaults to:
rsync://rsync.macports.org/release/tarballs/ports.tar [default]
though not all of our documentation was updated to match.
The commit mess
Hi,
- On 19 Jul, 2016, at 17:09, Ryan Schmidt ryandes...@macports.org wrote:
> The commit message says "make sync and selfupdate via signed tarballs the
> default"
>
> Was signing support the only reason for this change? On one of my systems with
> an evidently slow disk, "sudo port sync" ta
> On 19 lug 2016, at 18:07, David Spreen wrote:
>
> Hi All,
>
> Thanks for all the awesome work! About a week ago, I submitted a ticket +
> patch to upgrade Gnucash to the newest version (2.6.13). Since Gnucash has
> the openmaintainer address set, would it be possible for someone to have a
>
On Jul 19, 2016, at 11:33 AM, Daniel J. Luke wrote:
> On Jul 19, 2016, at 12:09 PM, Ryan Schmidt wrote:
Considering all the various build systems we encounter in MacPorts, from
autotools to xcodebuild to cmake to scons to qmake to manually crafted
Makefiles, my impression is that
On Jul 19, 2016, at 12:09 PM, Ryan Schmidt wrote:
>>> Considering all the various build systems we encounter in MacPorts, from
>>> autotools to xcodebuild to cmake to scons to qmake to manually crafted
>>> Makefiles, my impression is that autotools sucks the least.
>>
>> I guess we can just dis
On Jul 19, 2016, at 10:49 AM, Watson Ladd wrote:
> We've got it building, the problems outstanding are one easy upstream patch
> and its tendency to fetch things during build/vendored zlib.
>
> Personally I'm not volunteering to maintain distribution patches to fix the
> fetch and zlib issues.
On Jul 19, 2016, at 10:49 AM, Daniel J. Luke wrote:
> On Jul 19, 2016, at 11:44 AM, Ryan Schmidt wrote:
>> Without reading those links, I already know autotools sucks, and from the
>> standpoint of a software developer I don't really enjoy writing autotools
>> files. However, from the standpoin
Hi All,
Thanks for all the awesome work! About a week ago, I submitted a ticket + patch
to upgrade Gnucash to the newest version (2.6.13). Since Gnucash has the
openmaintainer address set, would it be possible for someone to have a look at
the ticket (#51833) and perhaps commit it?[1]
I also h
On Jul 19, 2016, at 9:52 AM, Ken Cunningham wrote:
> You are completely correct, of course - upstream fixes would be ideal, and
> much preferred over fixing the portfile to repair upstream deficiencies. Most
> ports that use configure already seem to get these things brought in from the
> GnuL
On Jul 19, 2016, at 11:44 AM, Ryan Schmidt wrote:
> Without reading those links, I already know autotools sucks, and from the
> standpoint of a software developer I don't really enjoy writing autotools
> files. However, from the standpoint of a package maintainer, I love autotools
> for the con
On Jul 19, 2016 8:38 AM, "Daniel J. Luke" wrote:
>
> On Jul 19, 2016, at 8:19 AM, Ryan Schmidt wrote:
> > This is one of the problems with projects that roll their own
nonstandard configure scripts and Makefiles -- they don't work the way
anybody unfamiliar with that project expects. Developers w
On Jul 19, 2016, at 10:37 AM, Daniel J. Luke wrote:
> On Jul 19, 2016, at 8:19 AM, Ryan Schmidt wrote:
>> This is one of the problems with projects that roll their own nonstandard
>> configure scripts and Makefiles -- they don't work the way anybody
>> unfamiliar with that project expects. Deve
On Jul 19, 2016, at 8:19 AM, Ryan Schmidt wrote:
> This is one of the problems with projects that roll their own nonstandard
> configure scripts and Makefiles -- they don't work the way anybody unfamiliar
> with that project expects. Developers would do well to adopt standard
> configure script
On Tue, Jul 19, 2016 at 11:14 AM, David Evans wrote:
> On 7/19/16 8:04 AM, Ryan Schmidt wrote:
> >> Thanks, Ryan. Fixed in r150468. I'm surprised that there aren't more
> of these since the 'version' module which aims to
> >> normalize perl version numbers always includes the 'v' prefix in the
On 7/19/16 8:04 AM, Ryan Schmidt wrote:
>
> On Jul 19, 2016, at 10:01 AM, David Evans wrote:
>
>> On 7/19/16 5:41 AM, Ryan Schmidt wrote:
>>>
On Jul 12, 2016, at 7:16 AM, dev...@macports.org wrote:
Revision
150102
Author
dev...@macports.org
Date
2016-07-12
sources.conf used to default to:
rsync://rsync.macports.org/release/ports/ [default]
Since r79599 it defaults to:
rsync://rsync.macports.org/release/tarballs/ports.tar [default]
though not all of our documentation was updated to match.
The commit message says "make sync and selfupdate via sign
On Jul 19, 2016, at 10:01 AM, David Evans wrote:
> On 7/19/16 5:41 AM, Ryan Schmidt wrote:
>>
>>> On Jul 12, 2016, at 7:16 AM, dev...@macports.org wrote:
>>>
>>> Revision
>>> 150102
>>> Author
>>> dev...@macports.org
>>> Date
>>> 2016-07-12 05:16:16 -0700 (Tue, 12 Jul 2016)
>>> Log Message
>>>
On 7/19/16 5:41 AM, Ryan Schmidt wrote:
>
>> On Jul 12, 2016, at 7:16 AM, dev...@macports.org wrote:
>>
>> Revision
>> 150102
>> Author
>> dev...@macports.org
>> Date
>> 2016-07-12 05:16:16 -0700 (Tue, 12 Jul 2016)
>> Log Message
>>
>> p5-gearman-server: update to version 1.130.1, homepage, depend
You are completely correct, of course - upstream fixes would be ideal, and much
preferred over fixing the portfile to repair upstream deficiencies. Most ports
that use configure already seem to get these things brought in from the GnuLib
replacements, I've found.
But I suppose I'm torn between
On Tue, Jul 19, 2016 at 5:19 AM, Ryan Schmidt wrote:
> On Jul 19, 2016, at 7:13 AM, Ryan Schmidt wrote:
>
>> On Jul 17, 2016, at 12:31 AM, Watson Ladd wrote:
>>
>>> The problem is that
>>> they want you to run configure with an argument indicating the install
>>> prefix, then don't seem to support
On Jul 19, 2016, at 8:25 AM, Ken Cunningham wrote:
> Perfect. Thanks!
>
> There are a series of EFI32 machines stuck at 10.6.8 or at most 10.7. These
> can be EFI-hacked to run 10.11 but that hasn't worked for me yet.
>
> I have found that almost any port I have tried to install can be install
Perfect. Thanks!
There are a series of EFI32 machines stuck at 10.6.8 or at most 10.7. These can
be EFI-hacked to run 10.11 but that hasn't worked for me yet.
I have found that almost any port I have tried to install can be installed on
this system (so far), with minor surgery to replace a miss
> On Jul 10, 2016, at 5:03 PM, ciserl...@macports.org wrote:
>
> Revision
> 150062
> Author
> ciserl...@macports.org
> Date
> 2016-07-10 15:03:52 -0700 (Sun, 10 Jul 2016)
> Log Message
>
> npm3: update to version 3.10.5
> Modified Paths
>
> • trunk/dports/devel/npm3/Portfile
> Diff
>
> M
> On Jul 12, 2016, at 7:16 AM, dev...@macports.org wrote:
>
> Revision
> 150102
> Author
> dev...@macports.org
> Date
> 2016-07-12 05:16:16 -0700 (Tue, 12 Jul 2016)
> Log Message
>
> p5-gearman-server: update to version 1.130.1, homepage, dependencies.
> Modified Paths
>
> • trunk/dports/
On Jul 19, 2016, at 7:13 AM, Ryan Schmidt wrote:
> On Jul 17, 2016, at 12:31 AM, Watson Ladd wrote:
>
>> The problem is that
>> they want you to run configure with an argument indicating the install
>> prefix, then don't seem to support DESTROOT. I've gone to upstream to
>> report this, but I und
On Jul 17, 2016, at 12:31 AM, Watson Ladd wrote:
> I'm trying to write a portfile for ChezScheme.
Thanks!
> The problem is that
> they want you to run configure with an argument indicating the install
> prefix, then don't seem to support DESTROOT. I've gone to upstream to
> report this, but I
26 matches
Mail list logo
