Performing substitutions during post-patch breaks tools such as mkpatches,
making it very difficult to regenerate correct patches after making changes,
and often leading to substituted string replacements being committed.
Problems found with existing distfiles:
distfiles/D6.data.ros.gz
distfiles/cstore0.2.tar.gz
distfiles/data4.tar.gz
distfiles/sphinx-2.2.7-release.tar.gz
No changes made to the cstore or mariadb55-client distinfo files.
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.
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.
pkgsrc-users.
Changes since 4.10:
* Turn down module cleanup verbosity
* Add check for rogue postmasters.
* Add pseudo-branch targets HEAD_PLUS_LATEST and HEAD_PLUS_LATEST2.
* Use Digest::SHA instead of Digest::SHA1.
* Make directory handling more robust in git code.
* Move web transaction into a module procedure.
* Switch to using the porcelain format of git status.
* Provide parameter for core file patterns.
* Use a command file for gdb instead of the -ex option
The web transaction and Digest::SHA changes have allowed the removal of
a couple of long-standing uglinesses on the system. In almost all
cases, the config parameter "aux_path" and the separate
run_web_transaction.pl script are now redundant (the exception is older
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.
From maintainer Nicolas Thauvin via mail to pkgsrc-users.
There are two notable upstream changes :
- the tarball is now hosted on pgbuildfarm.org instead of pgfoundry
- the client has now support for modules allowing to control the build
The PostgreSQL BuildFarm is a distributed build system designed to
detect build failures of the source code of PostgreSQL on a large
collection of platforms and configurations. This is the client
software that enables to perform automated test builds and checks.
