All checksums have been double-checked against existing RMD160 and
SHA512 hashes
The following distfiles could not be fetched (possibly fetched
conditionally?):
./misc/libreoffice/distinfo libreoffice/harfbuzz-2.6.4.tar.xz
-----------------
1.1 Lee Duncan drew my attention to Stephan Muller's fixes for Windows
compatibility
Changed the use of the system's mv command to using File::Copy in the
tests. (Steffen Mueller)
Added machine-readable license statement to Makefile.PL and thus
META.yml (Steffen Mueller)
The sixth test in 10/open.t is skipped on win32 because you can't just
move files around that are opened. (Steffen Mueller)
Due to using sysread and friends, there were newline problems on win32.
That should be fixed now. (Steffen Mueller)
1.2 Break the infinite loop that can result when the average length of lines
causes the attempt to fill the tail buffer to fill with the exact same
or even smaller number of lines.
1.3 Fix for a stupid bug in 1.2 (GFILATOV, Slaven_Rezic)
Added a warning for use of debug in a non-debug version of File::Tail
Shows a warning when maxbuf is set to a too-small value
Invoking name_changes callback changes the value of input attribute
(sottile@ix.netcom.com)
When deciding to reopen the file, check if the inode matches (that
would mean it has not been ranamed)
Problems found locating distfiles:
Package colorls: missing distfile ls.tar.gz
Package molden: missing distfile molden-4.6/molden4.6.tar.gz
Package softmaker-office-demo: missing distfile ofl06trial.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.
{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
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!
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:
- Set USE_LANGUAGES
- HOMEPAGE changed to search.cpan.org
Changes since version 0.99.1:
=============================
"Lyle D. Brooks" <brooks@deseret.com> reported there were instances
where interval was set to a negative value
Joe Smith <Joe.Smith@wcom.com> noted that one shouldn't declare
@ISA=qw(Autoloader) unless one is prepared to deal with it correctly.
Peter Allen <pgmppa@ibi.com> undef warnings when starting up on a
nonexistant file
Alain Fauconnet <alain@ait.ac.th> and Benjamin Zwittnig <beni@arnes.si>
provided test cases which helped me chase down another two cases where
File::Tail would spontaneously read too much.
Some operating systems sometimes return 0 for sysread on busy files.
This should now be handled correctly.
nowait can now be specified at object creation.
A callback is called on every file rotation, which can be used for
files that change their names with time.
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.
