| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
$Revision: 2.70 $ $Date: 2015/02/05 10:53:00 $
! Makefile.PL
add bin/encguess to EXE_FILES
2.69 2015/02/05 10:35:11
! bin/encguess
Refactored so that
* does not depend on non-core module (File::Slurp in particular)
* PODified document
* -s "encA encB" to -s encA,encB which is more shell-friendly
* and more
! MANIFEST
+ bin/encguess
Pulled: Added CLI wrapper for Encode::Guess
https://github.com/dankogai/p5-encode/pull/32
! Unicode/Unicode.pm
Pulled: Bump $VERSION in module changed since Encode-2.60
https://github.com/dankogai/p5-encode/pull/31
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Guessing the encoding of a report file prepared ahead of time is
really, well, too much guesswork, plus there are at least a couple
of mistakes in the implementation. And we weren't even trying to
guess for reports created on-the-fly in an editor, which is a bit
inconsistent.
So handle prepared reports the same way as on-the-fly reports and
attachments, which means all I/O is done using the :raw layer.
This is only "Unicode-aware" in the sense that we're aware there
are a lot of encodings out there and we're trying not to mangle
them in transit by accidental conversion. We're not doing any
explicit character set conversions and we shouldn't assert in the
MIME headers that we know what character set we're sending because
we don't.
|
|
|
|
| |
When cross-compiling we want to run miniperl etc on the compile host, not the test target
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Try to do input in whatever the locale wants and output raw in
hopes that will best survive mail transport.
Except when reading in a patch file, we'll also use raw for input
because there may be multiple encodings in the patch, and we'll
also use raw for input when reading in the report file that we've
written out raw.
We attempt to detect the locale encoding using the private and
undocumented _get_locale_encoding() function of the deprecated
encoding pragma module. But it's what the open pragma does and
we protect ourselves by checking that it's available and falling
back to an empty layer specification ("<:") if we can't load that
function. That should also give us something workable when there
is no dynamic loading, such as under miniperl.
|
|
|
|
|
|
|
|
|
|
|
| |
The VMS mail utility can't do attachments because it always adds
a blank line in front of any headers you add. So use the Send
From File utility, which has been documented and supported for
any release in the last decade and was latently present before
that.
It takes the whole message verbatim just like sendmail, but also
needs the envelope prepended.
|
|
|
|
|
|
|
|
|
|
|
| |
Log files and other text attachments should also be fine as long
as they aren't big enough to be rejected by RT.
Only text attachments are supported, as other kinds would involve
wrestling with myriad MIME types and possibly content transfer
encodings. This should be fine for binary patches, though, as
git format-patch encodes those in Base85, so the patch file itself
is still text.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Add rules to the Win32 Makefiles to call utils/Makefile.PL to generate
utils/Makefile, and rules to both them and the *nix Makefile to delete
the generated file as part of the cleanup targets.
VMS continues to do its own thing, rather than using utils/Makefile.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This shares all the existing deficiencies of utils/Makefile.SH, and
generates a byte-for-byte identical utils/Makefile, including boilerplate
that claims it was generated by utils/Makefile.SH
utils/Makefile remains as a file checked into the repository, and is not (yet)
deleted, because as-was only *nix platforms could run utils/Makefile.SH to
generate utils/Makefile. This messy state of affairs means that if you build
with static linking, the checked-out utils/Makefile is modified
('../miniperl' is replaced with '../perl')
The next commit will resolve just these bugs.
In turn, it seems that the pre-generated utils/Makefile is only used by
Win32, as VMS contains rules in descrip_mms.template to build the
utilities. Probably the next thing to unpick is the build on VMS, but it
seems better to reduce the size of the "problem" in both utils/Makefile.PL
and vms/descrip_mms.template by attempting to move the work from them to
the extension directories and ExtUtils::MakeMaker.
|
|
|
|
|
|
|
|
| |
Re-parsing patchlevel.h in Perl by perlbug.PL is error prone
and apparently unnecessary. The same information is available
to perlbug via Config::local_patches().
This fixes [perl #118433].
|
| |
|
|
|
|
| |
perl 5.5)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Suggested by Dave Mitchell.
|
|
|
|
|
|
|
| |
An XS module not using PERL_NO_GET_CONTEXT is extremely inefficient under
threaded Perls. Prevent PERL_NO_GET_CONTEXT-less modules in the future
by making it a default. Many XS modules are created with h2xs.
Also see this anonymous complaint http://perlmonks.org/?node_id=990732 .
|
|
|
|
|
| |
Otherwise the generated C code uses such macros in expressions, which causes
compilation errors because the macro is expanded to an empty token list.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
2.044 2 December 2011
* Moved FAQ.pod under the lib directory so it can get installed
* Added bin/zipdetails
* IO::Compress::Zip
- In one-shot mode enable Zip64 mode if the input file/buffer
>= 0xFFFFFFFF bytes.
* IO::Compress::FAQ
- Updates
|
| |
|
|
|
|
| |
This causes h2xs.t to fail on systems where that is the case
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
h2ph generates code of the form
unless(defined(&FOO)) {
sub FOO () {42;}
}
for a C macro like '#define FOO 42'.
The problem with that: 'sub' happens at compile time, 'unless' at runtime.
So the sub is unconditionally defined first, then the unless runs with
an empty body. This behavior was introduced in commit
3d271ce79d39df56470393916b3d33ff26db2c8b (the syntax errors there were
fixed in commit 4a8e146e38ec2045f1f817a7cb578e1b1f80f39f).
There are already two code paths there, one for indentation level > 0
(eval), the other for toplevel definitions (straight sub). This patch
unifies them to always use 'eval' / runtime definitions. This change
shortens the code and makes the conditions actually work.
It moves the check for '#define FOO FOO' further up because I don't
see why it only needs to be done if indentation == 0. I changed the
comparison to use a whitespace-agnostic regex because
'" \&$name" eq $new' looks too brittle (the redundant \ doesn't help).
|
|
|
|
|
|
| |
This will make the CPAN dist easier. For the perl core, we still need
substitutions to get the right she-bang as we don't go through EU::MM to fix it
for us. For that, we add utils/pod2html.PL.
|
|
|
|
|
|
|
| |
These tests were made optional in 2005 in commit 2a36bdc27 and
refer to files which are no longer generated during install.
To avoid confusion, the tests for these files have been removed.
|
| |
|
| |
|
| |
|
|
|
|
| |
It has been deprecated in 5.14. Now is the time to remove it.
|
|
|
|
|
|
|
|
|
| |
patch does:
perl -pi -e 's/$::opt_(\w)/$opt{$1}/g' perlbug.PL
adds my %opt decl, and in getopts.
drops no warnings 'once'
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
System header conversion with "h2ph -a" is currently broken on Ubuntu
Natty and Oneiric (unless the gcc-multilib package is installed for
backward compatibility), resulting in things like
# perl -e 'require "syscall.ph"'
Can't locate asm/unistd.ph in @INC [...]
This happens because Ubuntu has switched to a 'multiarch' setup, see
<https://wiki.ubuntu.com/MultiarchSpec> for details.
The asm subdirectory isn't in $Config{usrinc} anymore: /usr/include/asm
is now /usr/include/x86_64-linux-gnu/asm. (The third component of the
new path varies with the actual architecture.)
gcc --print-search-dirs doesn't really tell anything about where gcc
looks for the include directories, it was just used to find the gcc
internal directory prefix.
Parse the output of "gcc -v -E" instead, and append $Config{usrinc}
for safety. Duplicates shouldn't matter.
The h2ph "-a" switch isn't currently tested automatically, and that
seems nontrivial to do portably. Manual testing was done with
# mkdir ttt
# ./perl -Ilib ./utils/h2ph -a -d $(pwd)/ttt syscall.h
The gcc invocation has been tested to work with gcc 4.6, 4.1, and 3.3.
http://bugs.debian.org/625808
https://bugs.launchpad.net/bugs/777903
|
|
|
|
|
|
| |
(There's a less than idea situation with a somewhat complex history of trying
to resolve it, where utils/Makefile is in the repository for the use of
platforms unable to run utils/Makefile.SH)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have spotted a couple of missing dependencies in the makefiles
utils/Makefile.SH and x2p/Makefile.SH that prevent json_pp, s2p,
psed, and find2perl from being rebuilt after configuration changes.
This could cause trouble if the install prefix has been changed,
so that the shebang line of these scripts from a previous build
no longer matches the target location of the perl binary.
A workaround would be to always "make clean" after changes to
the configuration, which sounds reasonable anyway. That said,
most of the other tools do have config.sh properly listed as a
dependency and I don't see why those four should not.
I have attached a small patch against perl-5.13.11 to fix this.
The bug is also present in the latest stable release as of this
writing, perl-5.12.3, except that json_pp is not included there.
|
|
|
|
| |
It's not actually on CPAN yet, but it will be in the next couple of days.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way the script can easily be part of the CPAN distribution, where
ExtUtils::MakeMaker will do its shebang munging.
In the core, we still have utils/dprofpp.PL, which also does shebang munging and
takes care of creating `dprofpp.com' instead of just `dprofpp' on VMS, which
ExtUtils::MakeMaker doesn't seem to be up to yet.
To make this work, some things had to be moved from script-generation-time to
run-time:
* location of the stty binary
This is probably better for binary perl distributions anyway
* Devel::DProf version detection
This is needed for `dprofpp -V'. The version number used to be copied into
the script, but is now determined by actually loading Devel::DProf.
In order for this to work it's necessary to be able to load DProf without
causing profiling to start. For that, starting of the profiler has been moved
to `import', causing
require Devel::DProf;
to not trigger it anymore, while
use Devel::DProf;
(and therefore perl -d:DProf) still does.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[DELTA]
0.37_04 - Wed Feb 16 15:27:21 EST 2011
[OTHER]
- moved scripts/ to bin/ for less confusing porting to bleadperl
0.37_03 - Wed Feb 16 09:54:05 EST 2011
[BUG FIXES]
- removed an irrelevant test in t/actions/installdeps.t that was causing
failures on some Cygwin platforms
[OTHER]
- dropped configure_requires as some CPAN clients apparently get
confused by having things in both configure_requires and requires
- bumped Parse::CPAN::Meta build prereq to 1.4401
- bumped CPAN::Meta prereq to 2.110420
0.37_02 - Mon Feb 7 21:05:30 EST 2011
[BUG FIXES]
- bumped CPAN::Meta prereq to 2.110390 to avoid a regression in 2.110360
0.37_01 - Thu Feb 3 03:44:38 EST 2011
[ENHANCEMENTS]
- Generates META.json and MYMETA.json consistent with version 2 of the
CPAN Meta Spec. [David Golden]
[BUG FIXES]
- t/signature.t now uses a mocked Module::Signature; this should be
more robust across platforms as it only needs to confirm that
Module::Build is calling Module::Signature when expected
[OTHER]
- Added CPAN::Meta and Parse::CPAN::Meta to prerequisites and dropped
CPAN::Meta::YAML
0.3624 - Thu Jan 27 11:38:39 EST 2011
- Fixed pod2html directory bugs and fixed creation of spurious blib
directory in core perl directory when running install.t (RT#63003)
[Chris Williams]
0.3623 - Wed Jan 26 17:45:30 EST 2011
- Fixed bugs involving bootstrapping configure_requires prerequisites
on older CPANPLUS clients or for either CPAN/CPANPLUS when using
the compatibility Makefile.PL
- Added diagnostic output when configure_requires are missing for
the benefit of users doing manual installation
|
|
|
|
|
|
|
| |
Many systems thesedays don't have a valid internet domain name and
perlbug@perl.org does not accept email with a return-path that does not
resolve. Therefore pass the user's address to sendmail so it's less
likely to get stuck in a mail queue somewhere.
|
| |
|
|
|
|
|
|
|
|
|
| |
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81914]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81914 >
Signed-off-by: Abigail <abigail@abigail.be>
|
|
|
|
|
| |
Per discussions with Jesse Vincent, JSON::PP has been added
to the Perl core to support the new CPAN meta file specification
|
|
|
|
|
| |
the "right" thing and insert a valid "From:", not all of them do,
potentially resulting in dropped mail.
|