Age | Commit message (Collapse) | Author | Files | Lines |
|
All checksums have been double-checked against existing RMD160 and
SHA512 hashes
The following distfiles were unfetchable (possibly fetched
conditionally?):
./mail/qmail/distinfo netqmail-1.05-TAI-leapsecs.patch
|
|
|
|
|
|
|
|
pkglint -Wall -F --only aligned -r
No manual corrections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Problems found locating distfiles:
Package mutt: missing distfile patch-1.5.24.rr.compressed.gz
Package p5-Email-Valid: missing distfile Email-Valid-1.198.tar.gz
Package pine: missing distfile fancy.patch.gz
Package postgrey: missing distfile targrey-0.31-postgrey-1.34.patch
Package qmail: missing distfile badrcptto.patch
Package qmail: missing distfile outgoingip.patch
Package qmail: missing distfile qmail-1.03-realrcptto-2006.12.10.patch
Package qmail: missing distfile qmail-smtpd-viruscan-1.3.patch
Package thunderbird24: missing distfile enigmail-1.7.2.tar.gz
Package thunderbird31: missing distfile enigmail-1.7.2.tar.gz
Otherwise, existing SHA1 digests verified and found to be the same on
the machine holding the existing distfiles (morden). All existing
SHA1 digests retained for now as an audit trail.
|
|
{perl>=5.16.6,p5-ExtUtils-ParseXS>=3.15}:../../devel/p5-ExtUtils-ParseXS
since pkgsrc enforces the newest perl version anyway, so they
should always pick perl, but sometimes (pkg_add) don't due to the
design of the {,} syntax.
No effective change for the above reason.
Ok joerg
|
|
having a PKGNAME of p5-*, or depending such a package,
for perl-5.22.0.
|
|
Do it for all packages that
* mention perl, or
* have a directory name starting with p5-*, or
* depend on a package starting with p5-
like last time, for 5.18, where this didn't lead to complaints.
Let me know if you have any this time.
|
|
Bump PKGREVISION for runtime dependency pattern changed packages.
|
|
|
|
a) refer 'perl' in their Makefile, or
b) have a directory name of p5-*, or
c) have any dependency on any p5-* package
Like last time, where this caused no complaints.
|
|
|
|
are called p5-*.
I hope that's all of them.
|
|
|
|
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
|
|
to trigger/signal a rebuild for the transition 5.8.8 -> 5.10.0.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=...").
|
|
|
|
can handle packages having no PLIST files.
|
|
|
|
PR-responsible person (such as I am ;) a little easier.
|
|
of Perl files to deal with the perl-5.8.7 update that moved all
pkgsrc-installed Perl files into the "vendor" directories.
|
|
These paths are now relative to PERL5_PACKLIST_DIR, which currently
defaults to ${PERL5_SITEARCH}. There is no change to the binary
packages.
|
|
|
|
|
|
module directory has changed (eg. "darwin-2level" vs.
"darwin-thread-multi-2level").
binary packages of perl modules need to be distinguishable between
being built against threaded perl and unthreaded perl, so bump the
PKGREVISION of all perl module packages and introduce
BUILDLINK_RECOMMENDED for perl as perl>=5.8.5nb5 so the correct
dependencies are registered and the binary packages are distinct.
addresses PR pkg/28619 from H. Todd Fujinaka.
|
|
Notable changes (no changelog to speak of):
- added srsc command line client to srsd
- fixed upper/lower case comparisons in domain matching
|
|
The Sender Rewriting Scheme preserves .forward functionality in an
SPF-compliant world.
SPF requires the SMTP client IP to match the envelope sender
(return-path). When a message is forwarded through an intermediate
server, that intermediate server may need to rewrite the return-path to
remain SPF compliant. If the message bounces, that intermediate server
needs to validate the bounce and forward the bounce to the original
sender.
SRS provides a convention for return-path rewriting which allows
multiple forwarding servers to compact the return-path. SRS also
provides an authentication mechanism to ensure that purported bounces
are not arbitrarily forwarded.
|