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
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
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
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:
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:
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:
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 architectures to
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 is
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 email without having
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
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 2008)
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
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:
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.
I
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 on
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
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 fetch
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.
It
Hi,
when I viist http://www.macports.org/ with Safari v.1.3.2,
I always see the warnings saying
warnings
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:
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':
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
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 done
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 that it
24 matches
Mail list logo
