Jordan K. Hubbard wrote:
> On Feb 22, 2008, at 7:11 PM, Rainer Müller wrote:
>
>> One of these things would be how we would push files on the mirror?
>> If we keep master_sites we could use something like `port fetch all'
>> in a cronjob or in a post-commit hook. But that will have the
>> problem
On Feb 22, 2008, at 9:34 PM, William Siegrist wrote:
> We dont really see any dips in server load, so waiting until night
> (or any time in particular) doesnt buy us anything. I'm assuming
> you still agree with only fetching distfiles when they change, and
> we already have all the work d
On Feb 22, 2008, at 9:02 PM, Jordan K. Hubbard wrote:
On Feb 22, 2008, at 8:08 PM, William Siegrist wrote:
The server would grab distfiles during post-commit I imagine
(assuming the checksums get changed, patchfiles added, etc). So
similar to the way we handle linting of Portfiles during p
Hi,
currently, we enforce that every change has to increment the revision,
in order to force a rebuild by the user. But in fact, the current base
code also checks the last modified date of the Portfile to see if it was
changed since installation.
See sample with a non-existing port `empty':
---8<
Hi,
when I viist http://www.macports.org/ with Safari v.1.3.2,
I always see the warnings saying
This page contains the following errors:
error on line 41 at column 459: Entity 'nbsp' not defined
error on line 92 at column 45: Entity 'ldquo' not defined
error on line 113 at column 211: Entity 'ld
On Feb 22, 2008, at 8:08 PM, William Siegrist wrote:
> The server would grab distfiles during post-commit I imagine
> (assuming the checksums get changed, patchfiles added, etc). So
> similar to the way we handle linting of Portfiles during post-
> commit, we would check for these changes.
On Feb 22, 2008, at 7:11 PM, Rainer Müller wrote:
> One of these things would be how we would push files on the mirror?
> If we keep master_sites we could use something like `port fetch all'
> in a cronjob or in a post-commit hook. But that will have the
> problem that it currently port fetc
The server would grab distfiles during post-commit I imagine (assuming
the checksums get changed, patchfiles added, etc). So similar to the
way we handle linting of Portfiles during post-commit, we would check
for these changes. I just dont want to implement some hack of parsing
Portfiles m
William Siegrist wrote:
> I already made the offer to portmgr a while back, so they know. I
> think there needs to be some added API to macports in order to make
> the engineering a little cleaner server-side, but there hasnt been
> much discussion yet. So if anyone wants to take the lead o
Ryan Schmidt wrote:
> If a different set of files ends up on the user's machine, the
> revision must be incremented. Otherwise some users with tuxmath
> 1.6.1_0 have one set of files and other users with 1.6.1_0 have a
> different set of files. That's not reliable; that's not reproducible.
On Feb 22, 2008, at 15:48, Rainer Müller wrote:
> Ryan Schmidt wrote:
>
>> You need to bump the port revision too so everyone gets that change.
>
> I thought about that, but was uncertain if just this addition
> justifies a revision increment.
If a different set of files ends up on the user's
Ryan Schmidt wrote:
> You need to bump the port revision too so everyone gets that change.
I thought about that, but was uncertain if just this addition justifies
a revision increment.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.
You need to bump the port revision too so everyone gets that change.
On Feb 22, 2008, at 10:50, [EMAIL PROTECTED] wrote:
> Revision: 34368
> http://trac.macosforge.org/projects/macports/changeset/34368
> Author: [EMAIL PROTECTED]
> Date: 2008-02-22 08:50:30 -0800 (Fri, 22 Feb 200
Ryan Schmidt wrote:
>> I changed the above defaults back to the same as on MacPorts 1.6.0,
>> except that it is now configured at compiletime (in macports.conf).
>>
>> So it will now again use /Developer/SDKs/MacOSX10.5.sdk on Leopard,
>> and /Developer/SDKs/MacOSX10.4u.sdk on Tiger and avoid cros
On Feb 22, 2008, at 05:25, Anders F Björklund wrote:
> Previously, I wrote:
>
>> - universal_target
>> # for setting macosx_deployment_target and configure target
>> Default: 10.4
>>
>> - universal_sysroot
>> # the SDK "sysroot" to use, normally for the -isysroot flag
>> Default: /Develope
On Feb 21, 2008, at 06:22, [EMAIL PROTECTED] wrote:
> Revision: 34313
> http://trac.macosforge.org/projects/macports/changeset/34313
> Author: [EMAIL PROTECTED]
> Date: 2008-02-21 04:22:53 -0800 (Thu, 21 Feb 2008)
>
> Log Message:
> ---
> move back to using 10.5 SDK on Leo
> > I suggest giving non-maintainers the permission to change "Assigned
> > to" field.
>
> It seems to me like that would be a good idea too. But I'm not sure
> what all the implications of that would be.
According to Trac doc[1], if I had TICKET_CHGPROP,
I could modify ticket properties except
On Feb 22, 2008, at 07:18, js wrote:
> On 2/22/08, Ryan Schmidt wrote:
>
>> On Feb 21, 2008, at 11:31, Eric Hall wrote:
>>
>>> I'd like to see an improvement in maintainer notification,
>>> some way for trac to grok the maintainers of a port a ticket is
>>> filed
>>> against and send them an ema
I suggest giving non-maintainers the permission to change "Assigned to" field.
Once tickets are properly assigned, all you have to do is to look at
"My tickets".
In addition to that, How abount sending reminder to macports-dev
when there're tickets unchanged more than a few weeks?
Trac's backend i
Previously, I wrote:
> - universal_target
> # for setting macosx_deployment_target and configure target
> Default: 10.4
>
> - universal_sysroot
> # the SDK "sysroot" to use, normally for the -isysroot flag
> Default: /Developer/SDKs/MacOSX10.4u.sdk
>
> - universal_archs
> # machine archi
Ryan Schmidt wrote:
>
> On Feb 22, 2008, at 04:33, Joshua Root wrote:
>
>> Ryan Schmidt wrote:
>>
>>> You should have used "svn mv" to rename pgpFullLicense.c-patch to
>>> patch-pgpFullLicense.c.diff. It looks like you just added it anew. Look
>>> the revision history now in the repository:
>>>
>
On Feb 22, 2008, at 04:33, Joshua Root wrote:
> Ryan Schmidt wrote:
>
>> You should have used "svn mv" to rename pgpFullLicense.c-patch to
>> patch-pgpFullLicense.c.diff. It looks like you just added it anew.
>> Look
>> the revision history now in the repository:
>>
>> http://trac.macosforge.or
Joshua Root wrote:
> Ryan Schmidt wrote:
>> You should have used "svn mv" to rename pgpFullLicense.c-patch to
>> patch-pgpFullLicense.c.diff. It looks like you just added it anew.
>> Look the revision history now in the repository:
>>
>> http://trac.macosforge.org/projects/macports/log/trunk/dpor
Ryan Schmidt wrote:
> You should have used "svn mv" to rename pgpFullLicense.c-patch to
> patch-pgpFullLicense.c.diff. It looks like you just added it anew. Look
> the revision history now in the repository:
>
> http://trac.macosforge.org/projects/macports/log/trunk/dports/security/pgp/files/pat
Hi Randall,
On Fri, 22 Feb 2008 04:32:19 -0500, "Randall Wood"
<[EMAIL PROTECTED]> said:
> Openoffice.org publishes a daily email of new tickets to, not only its
> developers mailing lists, but to its blogging systems as well.
You can subscribe to a configurable RSS feed of the Trac timeline at
On Feb 22, 2008, at 03:32, Randall Wood wrote:
> Openoffice.org publishes a daily email of new tickets to, not only its
> developers mailing lists, but to its blogging systems as well. Is
> there any reason we should not (or can not) have trac provide a daily
> email into the macports-dev list of
Openoffice.org publishes a daily email of new tickets to, not only its
developers mailing lists, but to its blogging systems as well. Is
there any reason we should not (or can not) have trac provide a daily
email into the macports-dev list of new tickets?
I have subscribed to the tickets list (and
27 matches
Mail list logo
