module-build-general — General discussion about Module::Build project

Re: [Module::Build] http://cpanratings.perl.org/dist/Module-Build

[Johan V. <jvr...@sq...>]

David Wheeler <da...@ki...> writes:

> Well, one should use the right tool for the job. And CPANRATINGS of
> course is not the right place to report a bug.

So, as a start, CPANRATINGS should emphasise on every page that bugs
should be reported using RT, and that CPANRATINGS is only for kudos.

> But at least with AnnoCPAN you should get an email when someone
> annotates your documentation. I did for one of my modules, and as a
> result updated the docs for the next release.

A similar mechanism seems to be missing for CPANRATINGS.

But still, I'd prefer users to discuss things with the appropriate
module authors instead of behind our backs.

-- Johan

Re: [Module::Build] http://cpanratings.perl.org/dist/Module-Build

[David W. <da...@ki...>]

On May 3, 2006, at 13:30, Johan Vromans wrote:

> Slightly OT... I'm not very happy with cpanratings and annocpan
> and such. With quite a few modules on CPAN, I'd very much prefer the
> community feedback to be centralised, e.g., via RT.

Well, one should use the right tool for the job. And CPANRATINGS of  
course is not the right place to report a bug.

But at least with AnnoCPAN you should get an email when someone  
annotates your documentation. I did for one of my modules, and as a  
result updated the docs for the next release.

Best,

David

Re: [Module::Build] http://cpanratings.perl.org/dist/Module-Build

[Johan V. <jvr...@sq...>]

and...@fr... (Andreas J. Koenig) writes:

> ... http://cpanratings.perl.org ...

Slightly OT... I'm not very happy with cpanratings and annocpan
and such. With quite a few modules on CPAN, I'd very much prefer the
community feedback to be centralised, e.g., via RT.

-- Johan

Re: [Module::Build] Re: http://cpanratings.perl.org/dist/Module-Build

[Ken W. <ke...@ma...>]

On May 3, 2006, at 7:21 AM, Patrick J. LoPresti wrote:

> (Yes, MakeMaker is unrelated
> to Module::Build.  That is what makes this whole thing so funny.)

Patrick: if there's anyone in the world that understands the  
relationship between MakeMaker, CPAN.pm, Module::Build, and  
everything else Perl, it's Andreas.

Sorry you had such a shitty experience, but what you're saying just  
doesn't jibe with the 0.28 release you say you're using.

  -Ken

[Module::Build] Re: http://cpanratings.perl.org/dist/Module-Build

[<and...@fr...>]

>>>>> On Wed, 3 May 2006 05:21:36 -0700, "Patrick J. LoPresti" <lop...@gm...> said:

  > First of all, it is extremely rude to quote private messages in public
  > without asking permission (which I would have granted gladly).

I apologize. I will try my very best to never quote you again.

  > Are you telling me Module::Build "Makefile.PL" scripts do NOT generate
  > the following message when passed a "PREFIX=..." argument?

  >    Sorry, PREFIX is not supported.  See the Module::Build
  >    documentation for 'destdir' or 'install_base' instead.

  > Because in my experience, that is exactly what they do.

Yes, I'm telling you, it does not for me.

  > Seriously, it is hard to overstate just how little interest I have
  > in this topic at this point.

So have a nice day,
-- 
andreas

[Module::Build] Re: http://cpanratings.perl.org/dist/Module-Build

[Patrick J. L. <lop...@gm...>]

First of all, it is extremely rude to quote private messages in public
without asking permission (which I would have granted gladly).

On 5/2/06, Andreas J. Koenig <and...@fr...> wro=
te:
> (CC to Module::Build mailinglist, citing you in full length to provide co=
ntext)
>
> Pity that you do not remember: a single module would help to find the
> problem,

I told you, "all of them".  And then I gave a specific example in the
very next sentence.

>   > For example, "install version" ends up
>   > bombing out with:
>
>   >  Sorry, PREFIX is not supported.  See the Module::Build
>   >  documentation for 'destdir' or 'install_base' instead.
>
> As I said above, it worked very well for me. I tried it specifically
> with version-0.59.
>
>   > This happens when the CPAN shell (or the user...) runs "perl
>   > Makefile.PL PREFIX=3D${HOME}/perl".
>
> I repeat, it works for me.

I repeat, I typed the precise command above about 60 seconds before I
sent you my reply.

>   > I ended up downloading the beta version of MakeMaker and using
>   > INSTALL_BASE instead of PREFIX.  But I had to compile and install
>   > MakeMaker by hand...  And this is documented nowhere except in variou=
s
>   > messages on various obscure mailing lists.
>
> Interesting, you do give a hint here that maybe it's a problem with an
> old MakeMaker.

What the hell are you talking about?

1) It is not an "old MakeMaker", it is the current official release.

2) This has nothing to do with MakeMaker whatsoever, since I already
had a working solution for years which broke, but not because of any
change in MakeMaker.  Lucky for me that the MakeMaker developers saw
fit to provide a workaround for Module::Build's brokenness, isn't it?

> The best way to avoid that is to write concise bugreports to the
> developers. Really. Please try to write a diary during the "couple of
> hours" next time you encounter a problem, so that you can back up your
> findings with one or two facts.

Are you telling me Module::Build "Makefile.PL" scripts do NOT generate
the following message when passed a "PREFIX=3D..." argument?

    Sorry, PREFIX is not supported.  See the Module::Build
    documentation for 'destdir' or 'install_base' instead.

Because in my experience, that is exactly what they do.

As I said in my review, I am completely bored by stupid religious wars
-- and this is my last message on the topic.  Yes, I am annoyed that
some idiotic provincial decision deliberately broke something which I
(and others) have relied upon for years.  And it broke it in a way
that gives no guidance for how to fix it, and even made it impossible
to fix without spending hours grovelling stupid mailing lists,
manually installing beta releases of unrelated software, and changing
a setting that used to work to one that looks pretty much the same but
winds up working slightly differently.  (Yes, MakeMaker is unrelated
to Module::Build.  That is what makes this whole thing so funny.)

But now that I finally have a workaround for Module::Build's
crappiness, I really don't care.  Seriously, it is hard to overstate
just how little interest I have in this topic at this point.

OK I am done.  But I did enjoy your "problem with an old MakeMaker"
analysis.  That was hilarious.

 - Pat

[Module::Build] Re: http://cpanratings.perl.org/dist/Module-Build

[<and...@fr...>]

(CC to Module::Build mailinglist, citing you in full length to provide context)

>>>>> On Tue, 2 May 2006 21:45:25 -0700, "Patrick J. LoPresti" <pa...@al...> said:

  > Using the version of CPAN that ships with Perl -- the one on the
  > just-installed Ubuntu system I have -- setting PREFIX does not work.
  > At least it didn't the last time I tried.  I am sorry, but I forget
  > which exact module had the problem....  I believe it was every module
  > that uses Module::Build.

Pity that you do not remember: a single module would help to find the
problem, whereas the assertion that it is every module that uses
Module::Build can easily be falsified, e.g. I just tried

   perl Makefile.PL PREFIX=/tmp

in the Module-Build-0.28 directory and it worked very well.

  > For example, "install version" ends up
  > bombing out with:

  >  Sorry, PREFIX is not supported.  See the Module::Build
  >  documentation for 'destdir' or 'install_base' instead.

As I said above, it worked very well for me. I tried it specifically
with version-0.59.

  > This happens when the CPAN shell (or the user...) runs "perl
  > Makefile.PL PREFIX=${HOME}/perl".

I repeat, it works for me.

  > I ended up downloading the beta version of MakeMaker and using
  > INSTALL_BASE instead of PREFIX.  But I had to compile and install
  > MakeMaker by hand...  And this is documented nowhere except in various
  > messages on various obscure mailing lists.

Interesting, you do give a hint here that maybe it's a problem with an
old MakeMaker.

  > It would be nice if the Module::Build documentation could address this
  > specific issue, telling users exactly what to do if they want their
  > modules installed under a particular path. I don't even care where
  > they end up exactly; I just want to be able to use the CPAN shell and
  > know that everything will wind up under a specific place.

  > Anyway, sorry if my tone was overly hostile, but I lost enough time
  > figuring out PREFIX years ago...  It was frustrating to lose a couple
  > more hours trying to figure out why it broke.

The best way to avoid that is to write concise bugreports to the
developers. Really. Please try to write a diary during the "couple of
hours" next time you encounter a problem, so that you can back up your
findings with one or two facts.

Thanks,
-- 
andreas

[Module::Build] http://cpanratings.perl.org/dist/Module-Build

[<and...@fr...>]

Patrick,

the following posting on http://cpanratings.perl.org/dist/Module-Build
(which seems to be written by you; apologies if I'm mistaken on this)
caught my attention:

|Module-Build (0.28) *
|
|    All I want to do is to configure the CPAN shell to install all
|    modules under my home directory (not as root), even though the
|    Perl I am using is bundled with my system (installed as root).
|
|    I can figure out how to set PERL5LIB to access the modules. I always have.
|
|    I used to simply set PREFIX. But now that half of the &^##@%!
|    modules on CPAN use MakeMaker and half use Module::Build, I have
|    no idea what to set. I tried setting both PREFIX and install_base
|    in the CPAN shell defaults, but then Module::Build modules refuse
|    to compile at all (they bomb when given PREFIX).
|
|    Nice job breaking something that has worked for years. This sucks
|    even by open source standards... I don't care about stupid
|    religious wars; I just want some setting -- any setting -- to
|    convince all of the modules on CPAN to install themselves under
|    ${HOME}. Is there one? There used to be.
|
|Patrick J. LoPresti - 2006-05-01 17:14:41

Would you mind, giving a complete example that bombs, so that the
Module::Build developers can fix the problem?

Thank you very much,
-- 
andreas

Re: [Module::Build] Re: Preserving files' executable bits, once more (was: r5891 - in Module-Build/trunk: . lib/Module/Build)

[Ken W. <ke...@ma...>]

On Apr 25, 2006, at 7:36 AM, Ken Williams wrote:

>
> On Apr 23, 2006, at 12:13 PM, Julian Mehnle wrote:
>
>>
>> So apparently -x always returns true for root, and (mode & 0100) for
>> non-root.
>>
>> Also:
>>
>> | $ sudo -u julian ./f--x------
>> | $ sudo -u julian ./f--------x
>> | sudo: unable to execute ./f--------x: Permission denied
>> | $ sudo ./f--x------
>> | $ sudo ./f--------x
>> | $
>>
>> If a file really is 0445 (0455), then I think it is reasonably  
>> safe to
>> assume that either ug-x (u-x) was _deliberately_ set or that o+x  
>> (go+x)
>> was _accidentally_ set, and that therefore "not x" should be  
>> assumed. IOW,
>> it should be reasonably safe to consider the user x bit  
>> authoritative.
>>
>> Thus Module::Build should use -x for the executable check.   
>> However since
>> root (e.g. during `Build install`) always sees files as "x" if  
>> _any_ x bit
>> is set, M::B would have to emulate -x's non-root behavior:
>>
>>   my $mode = 0444 | ( (stat($file))[2] & 0100 ? 0111 : 0 );
>
>
> Well, the 0100 mask isn't quite right I think, because the user  
> might not be the owner.  In this special case perhaps we can count  
> on the user being the owner of files in blib/ though, I'm not  
> sure.  Certainly it would be true on *nix.
>
> The point about root & -x is certainly true, I hadn't thought about  
> that.  We'll have to fix that.

I've committed this to the repo, thanks for the research.

  -Ken

[Module::Build] [rt.cpan.org #18720] [PATCH] Archive::Tar creates POSIX style tar files unnecessarily and by default, leading to compatibility problems particularly with WinZip.

[v. R. <bug...@rt...>]

<URL: http://rt.cpan.org/Ticket/Display.html?id=3D18720 >

On Fri Apr 14 12:27:43 2006, YVES wrote:
> Archive::Tar since around version .99 has been producing files with a
> POSIX flavour header by default. This behaviour is undesirable as it
> means that the files are not readable with many Win32 based compression
> tools, most notably WinZip.
[...]
> This is especially bad as the POSIX longfile name support is used even
> when it needn't be, that is when the stored file name is shorter than
> 100 bytes.

This is a good point you raise, and seems like something worth fixing.
However, since the patch you attached addresses many more issues than
just this one, i'ts hard to decipher which parts would need to be applied=
.

I'd be interested in a patch for just this particular issue.

> The attached patch resolves this issue (it has been open since 2003 at
> least), by reverting to using the original single field naming scheme
> when it is possible, and then falling back to the Gnu Extend Header lon=
g
> name file support when necessary. This removes the older
> $DO_NO_USE_PREFIX flag and replaces it with a flag of the opposite
> meaning, and with a clearer name: $POSIX_LONGFILE.

I've done quite a bit of thinking about this, and have asked various othe=
rs
for their input in this, as well as testing the possible scenarios. In th=
e end,
I've decided that the patch as it is will not be applied, for the followi=
ng reasons:

* POSIX-tar is the standard tar on many unix filesystems, including Solar=
is,
IRIX and AIX. Applying this change will break all A::T generated tar file=
s for
those platforms. This is not only a backwards incompatible change, but wi=
ll
cripple their use of tools such as CPAN.pm and CPANPLUS.

* On Win32, installation tools such as CPAN.pm and CPANPLUS use Archive::=
Tar
or cygwin's /bin/tar, which both support POSIX and GNU-tar file formats, =
so their
use of the CPAN installers will not be hampered.

* Archive::Tar already supports a way to change the POSIX-compliant archi=
ves
to GNU-style archives. Users worried about these issues have the choice t=
o do
the right thing for their Win32 users, without breaking backward compatib=
ility
of Archive::Tar.
Since this behaviour may not be 100% apparent to the novice user, I have =
added
a FAQ entry about this particalur issue (See below)

* Changing of the global variable C<$DO_NOT_USE_PREFIX> is also a backwar=
ds
incompatible change, which, unless unavoidable, should not be done as it =
will
break peoples existing code.

Here's the docpatch i've applied to inform users of the issues involving =
the use of
A::T, and the intricacies of the tar format itself:

1432,1438c1432,1443
< By default, C<Archive::Tar> will try to put paths that are over
< 100 characters in the C<prefix> field of your tar header. However,
< some older tar programs do not implement this spec. To retain
< compatibility with these older versions, you can set the
< C<$DO_NOT_USE_PREFIX> variable to a true value, and C<Archive::Tar>
< will use an alternate way of dealing with paths over 100 characters
< by using the C<GNU Extended Header> feature.
---
> By default, C<Archive::Tar> will try to put paths that are over=20
> 100 characters in the C<prefix> field of your tar header, as
> defined per POSIX-standard. However, some (older) tar programs=20
> do not implement this spec. To retain compatibility with these older=20
> or non-POSIX compliant versions, you can set the C<$DO_NOT_USE_PREFIX>=20
> variable to a true value, and C<Archive::Tar> will use an alternate=20
> way of dealing with paths over 100 characters by using the=20
> C<GNU Extended Header> feature.
>=20
> Note that clients who do not support the C<GNU Extended Header>
> feature will not be able to read these archives. Such clients include
> tars on C<Solaris>, C<Irix> and C<AIX>.
1539a1545,1555
> =3Ditem I'm using WinZip, or some other non-POSIX client, and files are=
 not being extracted=20
properly!
>=20
> By default, C<Archive::Tar> is in a completely POSIX-compatible
> mode, which uses the POSIX-specification of C<tar> to store files.
> For paths greather than 100 characters, this is done using the
> C<POSIX header prefix>. Non-POSIX-compatible clients may not support
> this part of the specification, and may only support the C<GNU Extended
> Header> functionality. To facilitate those clients, you can set the
> C<$Archive::Tar::DO_NOT_USE_PREFIX> variable to C<true>. See the=20
> C<GLOBAL VARIABLES> section for details on this variable.
>=20
1621a1638,1662
> =3Dhead1 SEE ALSO
>=20
> =3Dover 4
>=20
> =3Ditem The GNU tar specification
>=20
> C<http://www.gnu.org/software/tar/manual/tar.html>
>=20
> =3Ditem The PAX format specication
>=20
> The specifcation which tar derives from; C< http://www.opengroup.org/on=
linepubs/
007904975/utilities/pax.html>
>=20
> =3Ditem A comparison of GNU and POSIX tar standards; C<http://www.delor=
ie.com/gnu/
docs/tar/tar_114.html>
>=20
> =3Ditem GNU tar intends to switch to POSIX compatibility
>=20
> GNU Tar authors have expressed their intention to become completely
> POSIX-compatible; C<http://www.gnu.org/software/tar/manual/html_node/
Formats.html>
>=20
> =3Ditem A Comparison between various tar implementations
>=20
> Lists known issues and incompatibilities; C<http://gd.tuwien.ac.at/util=
s/archivers/star/
README.otherbugs>
>=20
> =3Dback
>=20

[Module::Build] Re: [ANNOUNCE] Module::Build 0.28 -> CPAN

[Adrian H. <ad...@qu...>]

On 28 Apr 2006, at 18:08, Ken Williams wrote:

> Hi all,
>
> The uploaded file
>
>     Module-Build-0.28.tar.gz
>
> has entered CPAN
[snip]

YATY[1] to all involved.

Adrian

[1] Yet Another Thank You 

Re: [Module::Build] Module::Build installation problem: Interaction with cp

[Ken W. <ke...@ma...>]

On May 1, 2006, at 10:53 AM, Jim Keenan wrote:

> David Golden wrote on Mon May 01 07:46:27 CDT 2006
>
>> Given the recent switch to subversion, I figured there's a chance  
>> this
>> could be related.  You might each try checking (in binmode) a  
>> count of
>> the various newline characters in the files that are failing.
>>
> I'm confused.  Recent switch to subversion where?

The Module::Build master repository recently switched from CVS to  
subversion, but I don't think this is related, because the signature  
file does look fine.

  -Ken

Re: Re: [Module::Build] Module::Build installation problem: Interaction with cp

[Jim K. <jk...@ve...>]

David Golden wrote on Mon May 01 07:46:27 CDT 2006

>Given the recent switch to subversion, I figured there's a chance this 
>could be related.  You might each try checking (in binmode) a count of 
>the various newline characters in the files that are failing.
>
I'm confused.  Recent switch to subversion where?

jimk

Re: [Module::Build] Module::Build installation problem: Interaction with cpan shell and gpg

[David G. <da...@hy...>]

James Keenan wrote:
> My permissions match yours exactly (though I don't have a random_seed or 
> secring.gpg file in that directory).
> 
> PathTools is another distro that fails in the same way.  I'm beginning 
> to think that the distros that do the right thing -- have a signature -- 
> are the distros on which my cpan shell will fail.

There was something recently on one of the perl* lists I'm on about 
Module::Signature and newlines.

Subversion is bad about automatic newline conversions between platforms. 
You need to either set the eol-style param or set auto-props in your 
subversion config files.  Here's an example of how to do so for unix and 
windows:

http://www.symfony-project.com/trac/wiki/SymfonyRepositoryTips

Given the recent switch to subversion, I figured there's a chance this 
could be related.  You might each try checking (in binmode) a count of 
the various newline characters in the files that are failing.

Regards,
David Golden

[Module::Build] Svn repository tag naming (was: [ANNOUNCE] Module::Build 0.28 -> CPAN)

[Julian M. <ju...@me...>]

Ken Williams wrote:
> On Apr 28, 2006, at 12:08 PM, Ken Williams wrote:
> > Going forward from 0.28, I'm sure there will be some 0.28xx
> > releases as we get people's reported bugs smooshed.
>
> Accordingly, I just made a https://svn.perl.org/modules/Module-Build/
> tags/release-0_28 tag in subversion.

Just for the record, in Subversion you can call the tag "release-0.28", or=
=20
even just "0.28".  You can even rename all the old tags.

Re: [Module::Build] Module::Build installation problem: Interaction with cpan shell and gpg

[Ken W. <ke...@ma...>]

On Apr 30, 2006, at 10:44 PM, James Keenan wrote:
> My permissions match yours exactly (though I don't have a  
> random_seed or secring.gpg file in that directory).

Perhaps this URL helps?

   http://lists.gnupg.org/pipermail/gnupg-users/2005-March/025320.html

Try a couple more things - as you (not root) can you go into the  
Module-Build-0.28 directory and successfully run "cpansign -v"?  If  
so, and if it fails as root, then I recommend downloading the latest  
CPAN (beta?) that can run all steps except the final 'make/Build  
install' as a regular user, and run the last step under sudo.

  -Ken

Re: [Module::Build] Module::Build installation problem: Interaction with cpan shell and gpg

[James K. <jk...@ve...>]

On Apr 30, 2006, at 4:35 PM, Ken Williams wrote:

> Hi Jim,
>
> I just downloaded M::B 0.28 and checked the validity of the signature, 
> and it looks okay to me.  I don't think it's treating me special 
> because I created it either.
>
> It sounds to me like the most likely culprit is Module::Signature and 
> your gpg setup.  Here's what the permissions on my ~/.gnupg directory 
> look like:
>
>
> % ls -al ~/.gnupg
> total 176
> drwx------    8 ken  ken    272 Apr  5 22:30 ./
> drwxr-xr-x   73 ken  ken   2482 Apr 30 14:16 ../
> -rw-------    1 ken  ken   7850 Apr 25  2004 gpg.conf
> -rw-------    1 ken  ken  33556 Apr  5 22:07 pubring.gpg
> -rw-------    1 ken  ken  31730 Apr  5 22:05 pubring.gpg~
> -rw-------    1 ken  ken    600 Apr 27 23:14 random_seed
> -rw-------    1 ken  ken   1168 Apr 25  2004 secring.gpg
> -rw-------    1 ken  ken   1840 Apr  5 22:07 trustdb.gpg
>
> Does that match yours?  Note that the directory and every file in it 
> have no permissions for group & other.
>
>

My permissions match yours exactly (though I don't have a random_seed 
or secring.gpg file in that directory).

PathTools is another distro that fails in the same way.  I'm beginning 
to think that the distros that do the right thing -- have a signature 
-- are the distros on which my cpan shell will fail.

jimk

Re: [Module::Build] [ANNOUNCE] Module::Build 0.28 -> CPAN

[Ken W. <ke...@ma...>]

On Apr 28, 2006, at 12:08 PM, Ken Williams wrote:

> Going forward from 0.28, I'm sure there will be some 0.28xx  
> releases as we get people's reported bugs smooshed.


Accordingly, I just made a https://svn.perl.org/modules/Module-Build/ 
tags/release-0_28 tag in subversion.

  -Ken

Re: [Module::Build] Module::Build installation problem: Interaction with cpan shell and gpg

[Ken W. <ke...@ma...>]

Hi Jim,

I just downloaded M::B 0.28 and checked the validity of the  
signature, and it looks okay to me.  I don't think it's treating me  
special because I created it either.

It sounds to me like the most likely culprit is Module::Signature and  
your gpg setup.  Here's what the permissions on my ~/.gnupg directory  
look like:


% ls -al ~/.gnupg
total 176
drwx------    8 ken  ken    272 Apr  5 22:30 ./
drwxr-xr-x   73 ken  ken   2482 Apr 30 14:16 ../
-rw-------    1 ken  ken   7850 Apr 25  2004 gpg.conf
-rw-------    1 ken  ken  33556 Apr  5 22:07 pubring.gpg
-rw-------    1 ken  ken  31730 Apr  5 22:05 pubring.gpg~
-rw-------    1 ken  ken    600 Apr 27 23:14 random_seed
-rw-------    1 ken  ken   1168 Apr 25  2004 secring.gpg
-rw-------    1 ken  ken   1840 Apr  5 22:07 trustdb.gpg

Does that match yours?  Note that the directory and every file in it  
have no permissions for group & other.

I'm guessing that the modules you can successfully install via CPAN  
simply don't have signatures on them.

  -Ken


On Apr 30, 2006, at 10:35 AM, James Keenan wrote:

> I am repeatedly encountering problems using the 'cpan' shell to  
> install Module::Build on my laptop (iBook G4, Mac OS X 10.3, Perl  
> 5.8.7).  I have gnupg installed, and the interaction between cpan,  
> Module::Build and gnupg is the problem.  Whether I am installing  
> only Module::Build or installing Module::Build as part of a  
> Bundle::CPAN upgrade, I get a message like this:
>
> #####
> Removing previously used /Users/jimk/.cpan/build/Module-Build-0.28
> gpg: WARNING: unsafe ownership on configuration file `/Users/ 
> jimk/.gnupg/gpg.conf'
> gpg: WARNING: unsafe ownership on configuration file `/Users/ 
> jimk/.gnupg/gpg.conf'
> gpg: Signature made Fri Apr 28 00:14:21 2006 EDT using DSA key ID  
> A6ZK6789
> gpg: external program calls are disabled due to unsafe options file  
> permissions
> gpg: keyserver communications error: general error
> gpg: Can't check signature: public key not found
> ==> BAD/TAMPERED signature detected! <==
>
> Signature invalid for distribution file. Please investigate.
> #####
>
> Module::Build subsequently fails to install via 'cpan' -- but I  
> then have no problem manually downloading and installing it from  
> CPAN!  But this is a nuisance; I would much prefer that the cpan  
> shell DWIM.
>
> I previously raised this question on Perlmonks (http:// 
> perlmonks.org/?node_id=543255), but that thread petered out without  
> a clear answer.  I searched the archives of this mailing list for  
> "unsafe ownership on configuration file" and "Signature invalid"  
> and "gpg," but didn't come up with anything directly relevant.   
> Further note (in case it's relevant):  I have gpg version 1.4.1 and  
> Module::Signature 0.53.
>
> I should note that I encounter this problem with some CPAN modules  
> besides Module::Build.  So it's not specific to Module::Build, but  
> most CPAN modules install without incident.  I don't claim to  
> understand gnupg all that well, so I can't evaluate the error  
> message.  Can anyone help?
>
> Thanks.
> Jim Keenan
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

[Module::Build] Module::Build installation problem: Interaction with cpan shell and gpg

[James K. <jk...@ve...>]

I am repeatedly encountering problems using the 'cpan' shell to install 
Module::Build on my laptop (iBook G4, Mac OS X 10.3, Perl 5.8.7).  I 
have gnupg installed, and the interaction between cpan, Module::Build 
and gnupg is the problem.  Whether I am installing only Module::Build 
or installing Module::Build as part of a Bundle::CPAN upgrade, I get a 
message like this:

#####
Removing previously used /Users/jimk/.cpan/build/Module-Build-0.28
gpg: WARNING: unsafe ownership on configuration file 
`/Users/jimk/.gnupg/gpg.conf'
gpg: WARNING: unsafe ownership on configuration file 
`/Users/jimk/.gnupg/gpg.conf'
gpg: Signature made Fri Apr 28 00:14:21 2006 EDT using DSA key ID 
A6ZK6789
gpg: external program calls are disabled due to unsafe options file 
permissions
gpg: keyserver communications error: general error
gpg: Can't check signature: public key not found
==> BAD/TAMPERED signature detected! <==

Signature invalid for distribution file. Please investigate.
#####

Module::Build subsequently fails to install via 'cpan' -- but I then 
have no problem manually downloading and installing it from CPAN!  But 
this is a nuisance; I would much prefer that the cpan shell DWIM.

I previously raised this question on Perlmonks 
(http://perlmonks.org/?node_id=543255), but that thread petered out 
without a clear answer.  I searched the archives of this mailing list 
for "unsafe ownership on configuration file" and "Signature invalid" 
and "gpg," but didn't come up with anything directly relevant.  Further 
note (in case it's relevant):  I have gpg version 1.4.1 and 
Module::Signature 0.53.

I should note that I encounter this problem with some CPAN modules 
besides Module::Build.  So it's not specific to Module::Build, but most 
CPAN modules install without incident.  I don't claim to understand 
gnupg all that well, so I can't evaluate the error message.  Can anyone 
help?

Thanks.
Jim Keenan

[Module::Build] [rt.cpan.org #18720] [PATCH] Archive::Tar creates POSIX style tar files unnecessarily and by default, leading to compatibility problems particularly with WinZip.

[v. R. <bug...@rt...>]

<URL: http://rt.cpan.org/Ticket/Display.html?id=3D18720 >

On Fri Apr 14 12:27:43 2006, YVES wrote:
> The attached patch resolves this issue (it has been open since 2003 at
> least), by reverting to using the original single field naming scheme
> when it is possible, and then falling back to the Gnu Extend Header lon=
g
> name file support when necessary. This removes the older
> $DO_NO_USE_PREFIX flag and replaces it with a flag of the opposite
> meaning, and with a clearer name: $POSIX_LONGFILE.

Hi Yves,

thanks for the patch. Since it's a rather large and possibly far-reaching=
 patch,
I will have to take some extra time to review it.

I'll get back to you as soon as possible

-- Jos

Re: [Module::Build] [ANNOUNCE] Module::Build 0.28 -> CPAN

[Ron S. <ro...@sa...>]

On Fri, 28 Apr 2006 13:24:03 -0400, David Golden wrote:

Hi David

> Congratulations and many thanks to Ken and Randy and everyone else
> who has put in such a huge effort at getting this out the door!

I second this.

It's a real community effort when so many people combine on a job.

-- 
Cheers
Ron Savage, ro...@sa... on 29/04/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

[Module::Build] Re: [ANNOUNCE] Module::Build 0.28 -> CPAN

[Ken W. <ke...@ma...>]

On Apr 28, 2006, at 12:46 PM, Yuval Kogman wrote:

> What about exposing the full Test::Harness output to CPANPLUS and
> friends? The smoke reports are so unusable I suspect i'm going to
> add Build.PL to MANIFEST.SKIP and use only the traditional-makefile
> it generates for my future releases.

Yup, we're going to do that for future releases of Module::Build.   
The CPANPLUS team decided to turn over maintenance of their  
CPANPLUS::Dist::Build module to us for that specific reason.  It's  
actually not clear yet whether this will require new M::B features or  
whether it can just be solved with a new CPANPLUS::Dist::Build release.

  -Ken

[Module::Build] Re: [ANNOUNCE] Module::Build 0.28 -> CPAN

[Yuval K. <not...@wo...>]

What about exposing the full Test::Harness output to CPANPLUS and
friends? The smoke reports are so unusable I suspect i'm going to
add Build.PL to MANIFEST.SKIP and use only the traditional-makefile
it generates for my future releases.

--=20
  Yuval Kogman <not...@wo...>
http://nothingmuch.woobling.org  0xEBD27418

Re: [Module::Build] [ANNOUNCE] Module::Build 0.28 -> CPAN

[David G. <da...@hy...>]

Ken Williams wrote:
> Hi all,
> 
> The uploaded file
> 
>     Module-Build-0.28.tar.gz
> 
> has entered CPAN as
> 
>   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.28.tar.gz
>   size: 180076 bytes
>    md5: 8b3d9cf3eadebdfbe5847d80ed3a2d0b
> 
> Thanks to those of you who have been patiently (or even non-patiently) 
> waiting for this release.  We promise to never take this long between 
> major releases again. =)

I saw it on the search.cpan.org recent feed this morning and it's 
already installed (on Win32 VanillaPerl + some hacks).

Congratulations and many thanks to Ken and Randy and everyone else who 
has put in such a huge effort at getting this out the door!

Regards,

David