Problems found locating distfiles:
Package cabocha: missing distfile cabocha-0.68.tar.bz2
Package convertlit: missing distfile clit18src.zip
Package php-enchant: missing distfile php-enchant/enchant-1.1.0.tgz
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.
-------------------
Changes for version 1.75 (June 25, 2015)
------------------------
- Export only necessary from POSIX (RT#99970, thanks Alexandr Ciornii)
- Upgrade Makefile.PL (thanks Alexandr Ciornii)
- Fix testing issue with missing locales (RT 97607, 97766, thanks to KHW)
(thanks David Solimano)
- Fix testing issue with bad Russian data on some platforms (RT 92666)
(thanks David Solimano)
- Add t/bigfloat.t (thanks Paul Miller / Alexandr Ciornii)
Changes for version 1.74 (April 19, 2011)
------------------------
- Only Perl 5.10.0 and newer supported
- Allow multi-character (e.g. " " for thousands_sep) (thanks
Nick Patch; RT 65489)
- Strip out illegal negative values returned by localeconv(),
observed on Windows - see @IGNORE_NEGATIVE (thanks Adam Kennedy;
RT 56802)
- Manage warnings when undef is passed to methods (RT 48038)
- Fix round() for Math::BigFloat objects (RT 62059)
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.
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.
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!
- Updating package for p5 module Number::Format from 1.70 to 1.72a
- Setting license to gnu-gpl-v2
Upstream changes:
Changes for version 1.72 (May 5, 2009)
------------------------
- Use Makefile.PL based on suggestion in RT 38020
- Add 'use strict' & 'use warnings'
- Add MAX_INT constant for detecting overflows
- Add helper sub _get_multipliers for getting kilo/mega/giga mult values
- Add test in round() for overflow from large of a precision value (RT 40126)
- Add .5 + 1e-14 to rounded value instead of .5000001 (RT 20298)
- Fix undef $pic_prefix (RT 43029)
- Add support for giga and base option in unformat_number (RT 40455)
- Fix Russian locale issues, esp. in unformat_number (RT 40859)
- Remove variables from error messages (XSS risk) and standardize errors
- Remove requirement that decimal_point & thousands_sep be 1 char (for ru_RU)
- Add Russian and unformat_number tests in locale.t
- Add compare_numbers to test with an allowable error of 1e-10 in round.t
Changes for version 1.71 (May 3, 2009)
------------------------
- Changes to tests t/format_price.t, t/locale.t, and t/round.t to
fix cpan tester errors
- No change to Format.pm itself
This despite some self-tests failing, but that's probably due
to deficiencies in the host system's locale implementation
(NetBSD/i386 4.0).
Pkgsrc changes:
o Remove workarounds for 1.61a version
Upstream changes (could not find newer changes):
Changes for version 1.63 (Feb 10, 2009)
------------------------
- Minor tweak to format_bytes test for German locales
Changes for version 1.62 (Feb 9, 2009)
------------------------
- Change format_bytes to fully specify all formatting options, not
rely on locale at all as it was causing too many CPAN tester errors.
Pkgsrc changes:
o Add some cludges to tell pkgsrc this is really version 1.61, not 1.61a
(the module version is 1.61)
Upstream changes:
Changes for version 1.61 (Dec 29, 2008)
------------------------
- Fix bugs in locale operations for format_price (thanks Moritz Onken)
- Fix documentation in format_bytes (rt # 42036)
- Enable warning when format_bytes called with numeric precision not hash
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=...").
Pkgsrc changes:
o Use dist/ on search.cpan.org instead of personal page
Upstream changes:
Changes for version 1.60 (Jul 2, 2008)
------------------------
- Rewrite new() and format_price() to use mon_* POSIX Locale values
- Add all missing POSIX Locale variables
(Thanks to Kevin Ryde for help identifying the problem)
And change HOMEPAGE to fixed URL.
Changes for version 1.52 (Sep 21, 2006)
------------------------
- Patch to t/format_price.t supplied by jonasbn addressing failling
tests in 1.51, tests 2-6, the regex formatting the currency code did
not take 0 occurrences of white space into account
Patch: rt #21382
Resolves: rt #18964
(The same issue/patch was also reported by Cosimo Streppone, Randy
W. Sims, J. R. Taisto)
Changes for version 1.51 (Apr 26, 2006)
------------------------
- Patch to t/format_price.t supplied by Cosimo Streppone to allow it
to work with non-US locales
Changes for version 1.5 (Feb 14, 2005)
------------------------
- Require Perl 5.8 - was 5.003 before
- Require POSIX.pm - was optional before
- If C<THOUSANDS_SEP> is set to the empty string, format_number will
not insert any separators.
- Replace "use vars" with "our"
- Support scientific notation - skip formatting
- Change format_bytes to support options (precision, unit, and base)
instead of precision number
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
