module-build-general Mailing List for Module::Build (Page 141)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general — General discussion about Module::Build project
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
| 2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
| 2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
| 2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-08 05:15:32
|
On 1/8/2004 12:04 AM, Randy W. Sims wrote:
> +sub _varchname {
> +# copied from PPM.pm
> + my $varchname = $Config{archname};
> + # Append "-5.8" to architecture name for Perl 5.8 and later
> + if (length($^V) && ord(substr($^V,1)) >= 8) {
> + $varchname .= sprintf("-%d.%d", ord($^V), ord(substr($^V,1)));
> + }
> +}
Of course there should be a return $varchname at the end of that sub.
|
|
From: Glenn L. <pe...@ne...> - 2004-01-08 05:05:22
|
On approximately 1/7/2004 8:04 PM, came the following characters from
the keyboard of Ken Williams:
> On Wednesday, January 7, 2004, at 08:51 PM, Glenn Linderman wrote:
>
>> Randy... It looks like M::B 0.21_02 is still building PPD files that
>> PPM dislikes: "Error: no suitable installation target found for
>> package GFfP." So I still have to manually edit the PPD file to fix
>> this. Maybe this one got dropped through the cracks of all the other
>> problems?
>
>
> Hmm, it may have - if you don't mind reminding me, what kind of edits
> did you have to make?
Well, now. I can tell you the edits I _did_ make, that cured the
symptom. Whether both were necessary, I couldn't say... but this made
it more like one that is "known to work".
diff -c gffp.ppd~ gffp.ppd
*** gffp.ppd~ Wed Jan 7 18:33:43 2004
--- gffp.ppd Wed Jan 7 18:41:38 2004
***************
*** 3,11 ****
<ABSTRACT>computational routines</ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
- <PERLCORE VERSION="5,008000,0,0" />
<OS VALUE="MSWin32" />
! <ARCHITECTURE NAME="MSWin32-x86-multi-thread" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
--- 3,10 ----
<ABSTRACT>computational routines</ABSTRACT>
<AUTHOR>Glenn Linderman <pe...@ne...></AUTHOR>
<IMPLEMENTATION>
<OS VALUE="MSWin32" />
! <ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" />
<CODEBASE HREF="GFfP-0.1.tar.gz" />
</IMPLEMENTATION>
</SOFTPKG>
--
Glenn -- http://nevcal.com/
===========================
The best part about procrastination is that you are never bored,
because you have all kinds of things that you should be doing.
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-08 05:04:27
|
On 1/7/2004 9:51 PM, Glenn Linderman wrote: > Randy... It looks like M::B 0.21_02 is still building PPD files that PPM > dislikes: "Error: no suitable installation target found for package > GFfP." So I still have to manually edit the PPD file to fix this. Maybe > this one got dropped through the cracks of all the other problems? Hi Glenn, Sorry, I forgot about that one. Can you try the attached patch and let me know if it works for you? I "borrowed" the code from PPM.pm for modifying the archname based on perl version >5.8. I also noticed that PPM uses NAME rather than VALUE in the OS tag and corrected it. Regards, Randy. |
|
From: Ken W. <ke...@ma...> - 2004-01-08 04:04:39
|
On Wednesday, January 7, 2004, at 08:51 PM, Glenn Linderman wrote: > Randy... It looks like M::B 0.21_02 is still building PPD files that > PPM dislikes: "Error: no suitable installation target found for > package GFfP." So I still have to manually edit the PPD file to fix > this. Maybe this one got dropped through the cracks of all the other > problems? Hmm, it may have - if you don't mind reminding me, what kind of edits did you have to make? -Ken |
|
From: Glenn L. <pe...@ne...> - 2004-01-08 02:50:50
|
On approximately 1/7/2004 4:10 PM, came the following characters from the keyboard of Randy W. Sims: > On 1/7/2004 5:47 PM, Glenn Linderman wrote: > >> On approximately 1/7/2004 1:08 AM, came the following characters from >> the keyboard of Jos I. Boumans: >> >>> >>> On 7-jan-04, at 3:35, Glenn Linderman wrote: >>> >>>> The way I see things, after installing the A::T 1.07 on Windows >>>> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B >>>> to build a module's .tar.gz and .ppd file, and then there were 3 >>>> symptoms, that may or may not be related. >>>> >>>> 1) During the build of the .tar.gz, warnings were printed about not >>>> being able to add directory entries to the archive. >>> >>> >>> >>> by A::T? if so, can you provide me with a test case? >> >> >> >> Using Win2K SP4, M::B 21_02, A::T 1.07 (latest with PPDs in my >> repository list) > > > If the ppm archives are not up to date yet, and you don't have a make > tool, grab A::T 1.08 from CPAN.org and put the attached 'Build.PL' in > the root distribution dir, and you should be able to use it to install. > >> Unzip the attached (Actually, I'll send it to you privately), will >> create \GFfP directory structure. >> >> cd \GFfP >> perl build.pl >> perl build >> perl build dist >> >> Warnings from the last command are: >> >> d:\GFfP>perl build dist >> perl build dist >> Unable to add file: 'GFfP-0.1' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/lib' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch/auto' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at >> C:\Perl\site\lib/Module/Build/Base.pm line 1706 >> Deleting META.yml >> Creating GFfP-0.1.tar.gz >> Deleting GFfP-0.1 > > > This is fixed in 1.08. OK, I've installed Archive::Tar 1.08, and confirmed that I no longer get the warnings above. >>>> 2) Most TAR decoding programs cannot see the PATH data, although >>>> the latest GNU TAR can >>> >>> >>> >>> yes, apparently (especially on windows) there's many clients that >>> follow an old(er) spec. Although i am still of the same opinion that >>> these clients are just inherintly broken, I do have a thought on how >>> we may be able to amend this; >>> >>> Can one of you who had trouble with the extracting confirm that when >>> extracting this tarball >>> >>> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >>> Pluggable-Module-SimpleBlog-0.02.tar.gz >> >> >> >> Well, interesting. >> >> PowerArchiver 2001 can usually ungzip and untar in one operation. But >> not this file. But by first doing ungzip in PowerArchiver, and then >> reopening the resulting .tar file in PowerArchiver, then the paths are >> visible. > > > I tested with WinZip 8.1 and WinRAR 3.20 and both worked, I had forgot > you had mentioned the problem occuring in PowerArchiver. Yep, well it seems pretty clear that PowerArchiver is truncating names longer than 100 chars. But my module's .tar.gz doesn't have names longer than 100 chars. But PowerArchiver still can't see the pathnames for my module, not even when built with A::T 1.08 (previous test was with 1.07). >>> everything actually goes as expected, and that a file named >>> >>> Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ >>> Pluggable/Module/SimpleBlog/Store/SQLite.pm >>> >>> is living in the extracted directory? >> >> >> >> In the extracted directory, at the location specified, there is a file >> named "SQ" which seems to contain what you would expect to find in a >> file named SQLite.pm . So it appears that PowerArchiver 2001 length >> limits the extraction path name to a length of 100 bytes. >> >> However, the "unxutils" version of TAR can extract it, some other >> ancient NT port of TAR can extract it. GNU TAR 1.12 can extract it. >> >> None of these latter three utilities can extract the path names of the >> .tar.gz build for the attached module, by A::T 1.07 (nor can >> PowerArchiver 2001). >> >>> If so, we could use the ././@LongLink extended tar format solution, >>> which is >>> really meant to be used for paths > 255 chars, but will work equally >>> well for >>> our purposes here... i'd equip A::T with a special flag that would >>> trigger the >>> use of ././@LongLink files at anything over >100 chars, rather than >>> at >255, >>> thus avoiding the use of the PREFIX header, and thus (hopefully) >>> solving your >>> problems :) >> >> >> >> As far as avoiding the problems, I don't think any of my paths are >> greater than 100 chars. They are less. But still not seen by the >> above mentioned 4 programs. >> >>>> 3) PPM claims to install the module, but nothing actually gets >>>> installed. M::B can install the module fine from the source >>>> directory. Given the other symptoms, it seems like it can't find >>>> the files in the archive, but it reports no errors. >>> >>> >>> >>> not much i can do with this one Randy... It looks like M::B 0.21_02 is still building PPD files that PPM dislikes: "Error: no suitable installation target found for package GFfP." So I still have to manually edit the PPD file to fix this. Maybe this one got dropped through the cracks of all the other problems? After hand editing the PPD file, this time around PPM install GFfP.ppd again claimed to installe GFfP, but only one file was listed during the install (hey, that's better than none, like last time around): ppm> install GFfP.ppd ==================== Install 'GFfP' version 0.1 in ActivePerl 5.8.0.805. ==================== Downloaded 7356 bytes. Extracting 14/14: GFfP-0.1/blib/arch/auto/GFfP/GFfP.lib Successfully installed GFfP version 0.1 in ActivePerl 5.8.0.805. And? It didn't actually install anything, not even that one file. So it still seems to me like PPM is getting confused by a funny .tar.gz file. Or something. >> Well, if PPM is using A::T to do extraction (I believe it is), and I >> am using A::T to do archiving (I believe M::B is, on my behalf), and >> PPM cannot extract the files because of a either a change in A::T >> interface, or a change in A::T file format, then perhaps you can, as >> you maintain A::T. On the other hand, if PPM is misusing A::T, then >> you probably can't. >> >> I really don't know where the problem is, for this one, but if we can >> get the first two issues resolved, then we will have a better >> foundation on which to analyze this third issue. And get the PPM >> folks involved if needed. But it is hard to point the finger at PPM >> at the moment, since (1) It hasn't changed (on my machine, at least) >> (2) It unpacks lots of other stuff (3) just the .tar.gz package build >> by M::B and A::T seem to give it problems. > > > Randy. > > > > > ------------------------------------------------------------------------ > > use Module::Build; > > use strict; > use warnings; > > my $have_zlib = eval { require IO::Zlib; 1 }; > > unless( $have_zlib ) { > warn <<EOM; > You do not have IO::Zlib installed. This means you can not read > or write compressed archives! > EOM > } > > Module::Build->new( > module_name => 'Module::Build', > dist_author => 'Jos Boumans <kane[at]cpan.org>', > dist_abstract => 'Manipulates TAR archives', > dist_version_from => 'lib/Archive/Tar.pm', > license => 'perl', > > requires => { > 'perl' => '5.005_03', > 'File::Spec' => 0.82, > }, > recommends => { > 'IO::Zlib' => 0, > }, > build_requires => { > 'Test::More' => 0, > 'Test::Harness' => 2.26, > }, > )->create_build_script(); > -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-08 00:11:08
|
On 1/7/2004 5:47 PM, Glenn Linderman wrote: > On approximately 1/7/2004 1:08 AM, came the following characters from > the keyboard of Jos I. Boumans: > >> >> On 7-jan-04, at 3:35, Glenn Linderman wrote: >> >>> The way I see things, after installing the A::T 1.07 on Windows >>> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B to >>> build a module's .tar.gz and .ppd file, and then there were 3 >>> symptoms, that may or may not be related. >>> >>> 1) During the build of the .tar.gz, warnings were printed about not >>> being able to add directory entries to the archive. >> >> >> by A::T? if so, can you provide me with a test case? > > > Using Win2K SP4, M::B 21_02, A::T 1.07 (latest with PPDs in my > repository list) If the ppm archives are not up to date yet, and you don't have a make tool, grab A::T 1.08 from CPAN.org and put the attached 'Build.PL' in the root distribution dir, and you should be able to use it to install. > Unzip the attached (Actually, I'll send it to you privately), will > create \GFfP directory structure. > > cd \GFfP > perl build.pl > perl build > perl build dist > > Warnings from the last command are: > > d:\GFfP>perl build dist > perl build dist > Unable to add file: 'GFfP-0.1' at C:\Perl\site\lib/Module/Build/Base.pm > line 1706 > Unable to add file: 'GFfP-0.1/blib' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/lib' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch/auto' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at > C:\Perl\site\lib/Module/Build/Base.pm line 1706 > Deleting META.yml > Creating GFfP-0.1.tar.gz > Deleting GFfP-0.1 This is fixed in 1.08. >>> 2) Most TAR decoding programs cannot see the PATH data, although the >>> latest GNU TAR can >> >> >> yes, apparently (especially on windows) there's many clients that >> follow an old(er) spec. Although i am still of the same opinion that >> these clients are just inherintly broken, I do have a thought on how >> we may be able to amend this; >> >> Can one of you who had trouble with the extracting confirm that when >> extracting this tarball >> >> http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- >> Pluggable-Module-SimpleBlog-0.02.tar.gz > > > Well, interesting. > > PowerArchiver 2001 can usually ungzip and untar in one operation. But > not this file. But by first doing ungzip in PowerArchiver, and then > reopening the resulting .tar file in PowerArchiver, then the paths are > visible. I tested with WinZip 8.1 and WinRAR 3.20 and both worked, I had forgot you had mentioned the problem occuring in PowerArchiver. >> everything actually goes as expected, and that a file named >> >> Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ >> Pluggable/Module/SimpleBlog/Store/SQLite.pm >> >> is living in the extracted directory? > > > In the extracted directory, at the location specified, there is a file > named "SQ" which seems to contain what you would expect to find in a > file named SQLite.pm . So it appears that PowerArchiver 2001 length > limits the extraction path name to a length of 100 bytes. > > However, the "unxutils" version of TAR can extract it, some other > ancient NT port of TAR can extract it. GNU TAR 1.12 can extract it. > > None of these latter three utilities can extract the path names of the > .tar.gz build for the attached module, by A::T 1.07 (nor can > PowerArchiver 2001). > >> If so, we could use the ././@LongLink extended tar format solution, >> which is >> really meant to be used for paths > 255 chars, but will work equally >> well for >> our purposes here... i'd equip A::T with a special flag that would >> trigger the >> use of ././@LongLink files at anything over >100 chars, rather than >> at >255, >> thus avoiding the use of the PREFIX header, and thus (hopefully) >> solving your >> problems :) > > > As far as avoiding the problems, I don't think any of my paths are > greater than 100 chars. They are less. But still not seen by the above > mentioned 4 programs. > >>> 3) PPM claims to install the module, but nothing actually gets >>> installed. M::B can install the module fine from the source >>> directory. Given the other symptoms, it seems like it can't find >>> the files in the archive, but it reports no errors. >> >> >> not much i can do with this one > > > Well, if PPM is using A::T to do extraction (I believe it is), and I am > using A::T to do archiving (I believe M::B is, on my behalf), and PPM > cannot extract the files because of a either a change in A::T interface, > or a change in A::T file format, then perhaps you can, as you maintain > A::T. On the other hand, if PPM is misusing A::T, then you probably can't. > > I really don't know where the problem is, for this one, but if we can > get the first two issues resolved, then we will have a better foundation > on which to analyze this third issue. And get the PPM folks involved if > needed. But it is hard to point the finger at PPM at the moment, since > (1) It hasn't changed (on my machine, at least) (2) It unpacks lots of > other stuff (3) just the .tar.gz package build by M::B and A::T seem to > give it problems. Randy. |
|
From: Glenn L. <pe...@ne...> - 2004-01-07 22:47:33
|
On approximately 1/7/2004 1:08 AM, came the following characters from the keyboard of Jos I. Boumans: > > On 7-jan-04, at 3:35, Glenn Linderman wrote: > >> The way I see things, after installing the A::T 1.07 on Windows >> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B to >> build a module's .tar.gz and .ppd file, and then there were 3 >> symptoms, that may or may not be related. >> >> 1) During the build of the .tar.gz, warnings were printed about not >> being able to add directory entries to the archive. > > by A::T? if so, can you provide me with a test case? Using Win2K SP4, M::B 21_02, A::T 1.07 (latest with PPDs in my repository list) Unzip the attached (Actually, I'll send it to you privately), will create \GFfP directory structure. cd \GFfP perl build.pl perl build perl build dist Warnings from the last command are: d:\GFfP>perl build dist perl build dist Unable to add file: 'GFfP-0.1' at C:\Perl\site\lib/Module/Build/Base.pm line 1706 Unable to add file: 'GFfP-0.1/blib' at C:\Perl\site\lib/Module/Build/Base.pm line 1706 Unable to add file: 'GFfP-0.1/blib/lib' at C:\Perl\site\lib/Module/Build/Base.pm line 1706 Unable to add file: 'GFfP-0.1/blib/arch' at C:\Perl\site\lib/Module/Build/Base.pm line 1706 Unable to add file: 'GFfP-0.1/blib/arch/auto' at C:\Perl\site\lib/Module/Build/Base.pm line 1706 Unable to add file: 'GFfP-0.1/blib/arch/auto/GFfP' at C:\Perl\site\lib/Module/Build/Base.pm line 1706 Deleting META.yml Creating GFfP-0.1.tar.gz Deleting GFfP-0.1 >> 2) Most TAR decoding programs cannot see the PATH data, although the >> latest GNU TAR can > > yes, apparently (especially on windows) there's many clients that > follow an old(er) spec. Although i am still of the same opinion that > these clients are just inherintly broken, I do have a thought on how we > may be able to amend this; > > Can one of you who had trouble with the extracting confirm that when > extracting this tarball > > http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- > Pluggable-Module-SimpleBlog-0.02.tar.gz Well, interesting. PowerArchiver 2001 can usually ungzip and untar in one operation. But not this file. But by first doing ungzip in PowerArchiver, and then reopening the resulting .tar file in PowerArchiver, then the paths are visible. > everything actually goes as expected, and that a file named > > Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ > Pluggable/Module/SimpleBlog/Store/SQLite.pm > > is living in the extracted directory? In the extracted directory, at the location specified, there is a file named "SQ" which seems to contain what you would expect to find in a file named SQLite.pm . So it appears that PowerArchiver 2001 length limits the extraction path name to a length of 100 bytes. However, the "unxutils" version of TAR can extract it, some other ancient NT port of TAR can extract it. GNU TAR 1.12 can extract it. None of these latter three utilities can extract the path names of the .tar.gz build for the attached module, by A::T 1.07 (nor can PowerArchiver 2001). > If so, we could use the ././@LongLink extended tar format solution, > which is > really meant to be used for paths > 255 chars, but will work equally > well for > our purposes here... i'd equip A::T with a special flag that would > trigger the > use of ././@LongLink files at anything over >100 chars, rather than at > >255, > thus avoiding the use of the PREFIX header, and thus (hopefully) > solving your > problems :) As far as avoiding the problems, I don't think any of my paths are greater than 100 chars. They are less. But still not seen by the above mentioned 4 programs. >> 3) PPM claims to install the module, but nothing actually gets >> installed. M::B can install the module fine from the source >> directory. Given the other symptoms, it seems like it can't find the >> files in the archive, but it reports no errors. > > not much i can do with this one Well, if PPM is using A::T to do extraction (I believe it is), and I am using A::T to do archiving (I believe M::B is, on my behalf), and PPM cannot extract the files because of a either a change in A::T interface, or a change in A::T file format, then perhaps you can, as you maintain A::T. On the other hand, if PPM is misusing A::T, then you probably can't. I really don't know where the problem is, for this one, but if we can get the first two issues resolved, then we will have a better foundation on which to analyze this third issue. And get the PPM folks involved if needed. But it is hard to point the finger at PPM at the moment, since (1) It hasn't changed (on my machine, at least) (2) It unpacks lots of other stuff (3) just the .tar.gz package build by M::B and A::T seem to give it problems. > > -- > > Jos Boumans > > "If superman is so smart, why does he wear underpants over his > trousers?" > > CPANPLUS http://cpanplus.sf.net > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Module-build-general mailing list > Mod...@li... > https://lists.sourceforge.net/lists/listinfo/module-build-general > > -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-07 10:25:52
|
On 1/7/2004 4:08 AM, Jos I. Boumans wrote: > > On 7-jan-04, at 3:35, Glenn Linderman wrote: > >> The way I see things, after installing the A::T 1.07 on Windows >> (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B to >> build a module's .tar.gz and .ppd file, and then there were 3 >> symptoms, that may or may not be related. >> >> 1) During the build of the .tar.gz, warnings were printed about not >> being able to add directory entries to the archive. > > by A::T? if so, can you provide me with a test case? If this is what Glenn reported before, it was fixed in A::T 1.08. From the README: - Fix a bug where adding dirs on win32 gave 'permission denied' >> 2) Most TAR decoding programs cannot see the PATH data, although the >> latest GNU TAR can > > yes, apparently (especially on windows) there's many clients that > follow an old(er) spec. Although i am still of the same opinion that > these clients are just inherintly broken, I do have a thought on how we > may be able to amend this; > > Can one of you who had trouble with the extracting confirm that when > extracting this tarball > > http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- > Pluggable-Module-SimpleBlog-0.02.tar.gz > > everything actually goes as expected, and that a file named > > Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ > Pluggable/Module/SimpleBlog/Store/SQLite.pm > > is living in the extracted directory? YES! Looks good. I will test more extensively when a snapshot is available. Thanks. > If so, we could use the ././@LongLink extended tar format solution, > which is > really meant to be used for paths > 255 chars, but will work equally > well for > our purposes here... i'd equip A::T with a special flag that would > trigger the > use of ././@LongLink files at anything over >100 chars, rather than at > >255, > thus avoiding the use of the PREFIX header, and thus (hopefully) > solving your > problems :) > >> 3) PPM claims to install the module, but nothing actually gets >> installed. M::B can install the module fine from the source >> directory. Given the other symptoms, it seems like it can't find the >> files in the archive, but it reports no errors. > > not much i can do with this one I believe this might be related to #2 above, but I have not actually investigated as I don't normally use ppm. When a snapshot of the fixed A::T is available, I'll check it out and atleast notify someone on the ppm mailing list if it persists. Thanks, Randy. |
|
From: Jos I. B. <ka...@dw...> - 2004-01-07 09:09:07
|
On 7-jan-04, at 3:35, Glenn Linderman wrote: > The way I see things, after installing the A::T 1.07 on Windows > (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B to > build a module's .tar.gz and .ppd file, and then there were 3 > symptoms, that may or may not be related. > > 1) During the build of the .tar.gz, warnings were printed about not > being able to add directory entries to the archive. by A::T? if so, can you provide me with a test case? > 2) Most TAR decoding programs cannot see the PATH data, although the > latest GNU TAR can yes, apparently (especially on windows) there's many clients that follow an old(er) spec. Although i am still of the same opinion that these clients are just inherintly broken, I do have a thought on how we may be able to amend this; Can one of you who had trouble with the extracting confirm that when extracting this tarball http://search.cpan.org/CPAN/authors/id/K/KA/KAKE/Bot-BasicBot- Pluggable-Module-SimpleBlog-0.02.tar.gz everything actually goes as expected, and that a file named Bot-BasicBot-Pluggable-Module-SimpleBlog-0.02/lib/Bot/BasicBot/ Pluggable/Module/SimpleBlog/Store/SQLite.pm is living in the extracted directory? If so, we could use the ././@LongLink extended tar format solution, which is really meant to be used for paths > 255 chars, but will work equally well for our purposes here... i'd equip A::T with a special flag that would trigger the use of ././@LongLink files at anything over >100 chars, rather than at >255, thus avoiding the use of the PREFIX header, and thus (hopefully) solving your problems :) > 3) PPM claims to install the module, but nothing actually gets > installed. M::B can install the module fine from the source > directory. Given the other symptoms, it seems like it can't find the > files in the archive, but it reports no errors. not much i can do with this one -- Jos Boumans "If superman is so smart, why does he wear underpants over his trousers?" CPANPLUS http://cpanplus.sf.net |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-07 08:25:21
|
On 1/7/2004 2:41 AM, Uri Guttman wrote: > anyone ever see this before? > > Useless use of a variable in void context at /usr/local/lib/perl5/5.6.1/ExtUtils/Install.pm line 267. > > the line of code is: > > local *SRC, *CMD; > > which is DUMB DUMB DUMB! > > but upgrading that module fixed it. Yep, seen this just recently when I forgot parens in a variable decleration: C:\working>perl -we "my $a,$b" Useless use of a variable in void context at -e line 1. Name "main::b" used only once: possible typo at -e line 1. C:\working>perl -we "my ($a,$b)" C:\working> Regards, Randy. |
|
From: Uri G. <ur...@st...> - 2004-01-07 07:41:53
|
anyone ever see this before?
Useless use of a variable in void context at /usr/local/lib/perl5/5.6.1/ExtUtils/Install.pm line 267.
the line of code is:
local *SRC, *CMD;
which is DUMB DUMB DUMB!
but upgrading that module fixed it.
uri
--
Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
|
|
From: Glenn L. <pe...@ne...> - 2004-01-07 02:35:02
|
On approximately 1/6/2004 5:16 PM, came the following characters from the keyboard of Randy W. Sims: > On 12/20/2003 5:23 PM, Jos I. Boumans wrote: > >> >> On Sat, 20 Dec 2003, Ken Williams wrote: >> >>> On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >>> >>>> Well this atleast proves that the paths are there, thus it is not a >>>> problem with M::B, but I think this is going to be a big issue for >>>> Windows users. I think if it's possible for Archive::Tar to be better >>>> compatible with other tools, it should. If I knew anything about the >>>> tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>> the maintainer. ;-) >>> >>> >>> I have some kind of vague recollection that maybe this issue in >>> Archive::Tar has been fixed privately by Kane and is just waiting for >>> him to release it. >>> >>> Kane, can you put Glenn out of his misery? Or am I remembering wrong? >> >> >> >> well, even though m::b may use A::T to build an archive, and ppm uses it >> to extract, it may not be the same A::T -- AS perl ships with a very old >> version of A::T which does not support the full tar standard (including >> the prefix header). Several people have already advised AS to upgrade >> A::T >> to a recent version, that works on win32 and actually supports most of >> the >> spec... >> >> the easiest fix would be to require the client to have a::t > 1.00 to >> make >> sure this doesn't happen, but i'm not sure how to enforce this... > > > Hi Jos, > > I just saw that A::T 1.08 hit CPAN and was very quick to try it out. > It's looking a lot better since you've taken over maintenance on it, and > more specifically this latest release has fixed some annoying problems > on Win32. However the above problem is unfortunately still present. I've > verified that using this latest version to create an archive does not > solve the problem with most Windows utilities being unable to read the > path information in the archive. This problem does not occur with > archive created with GNU tar. As this problem has been reported several > times on the M::B mailing list (and is apparently becoming a critical > issue for Win32 M::B users), I'm afraid this problem is going to > continue to plague us unless we can find a resolution. If I knew > anything of the tar format I'd submit a patch--Is there anything I can > do to help resolve this issue. > > Thanks, > Randy. Right. Thanks Randy for following up on this, I was just wondering again today if anything had happened in the last couple weeks (of course it is hard to get computer time during the holidays!). The way I see things, after installing the A::T 1.07 on Windows (hadn't notice 1.08 yet, Randy has sharp eyes!), I would use M::B to build a module's .tar.gz and .ppd file, and then there were 3 symptoms, that may or may not be related. 1) During the build of the .tar.gz, warnings were printed about not being able to add directory entries to the archive. 2) Most TAR decoding programs cannot see the PATH data, although the latest GNU TAR can 3) PPM claims to install the module, but nothing actually gets installed. M::B can install the module fine from the source directory. Given the other symptoms, it seems like it can't find the files in the archive, but it reports no errors. -- Glenn -- http://nevcal.com/ =========================== The best part about procrastination is that you are never bored, because you have all kinds of things that you should be doing. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-07 01:16:53
|
On 12/20/2003 5:23 PM, Jos I. Boumans wrote: > > On Sat, 20 Dec 2003, Ken Williams wrote: > >>On Saturday, December 20, 2003, at 12:17 PM, Randy W. Sims wrote: >> >>>Well this atleast proves that the paths are there, thus it is not a >>>problem with M::B, but I think this is going to be a big issue for >>>Windows users. I think if it's possible for Archive::Tar to be better >>>compatible with other tools, it should. If I knew anything about the >>>tar format, I'd try to provide a patch. Since I don't, I'll just cc >>>the maintainer. ;-) >> >>I have some kind of vague recollection that maybe this issue in >>Archive::Tar has been fixed privately by Kane and is just waiting for >>him to release it. >> >>Kane, can you put Glenn out of his misery? Or am I remembering wrong? > > > well, even though m::b may use A::T to build an archive, and ppm uses it > to extract, it may not be the same A::T -- AS perl ships with a very old > version of A::T which does not support the full tar standard (including > the prefix header). Several people have already advised AS to upgrade A::T > to a recent version, that works on win32 and actually supports most of the > spec... > > the easiest fix would be to require the client to have a::t > 1.00 to make > sure this doesn't happen, but i'm not sure how to enforce this... Hi Jos, I just saw that A::T 1.08 hit CPAN and was very quick to try it out. It's looking a lot better since you've taken over maintenance on it, and more specifically this latest release has fixed some annoying problems on Win32. However the above problem is unfortunately still present. I've verified that using this latest version to create an archive does not solve the problem with most Windows utilities being unable to read the path information in the archive. This problem does not occur with archive created with GNU tar. As this problem has been reported several times on the M::B mailing list (and is apparently becoming a critical issue for Win32 M::B users), I'm afraid this problem is going to continue to plague us unless we can find a resolution. If I knew anything of the tar format I'd submit a patch--Is there anything I can do to help resolve this issue. Thanks, Randy. |
|
From: Uri G. <ur...@st...> - 2004-01-04 23:10:17
|
>>>>> "RWS" == Randy W Sims <Ra...@th...> writes: RWS> Actually, you're right--Here docs eliminate the need for word RWS> wrapping. This is what happens when I think before I speak <:-I an affliction that affects us all too often. :) and another reason i love and promote here docs. i still don't see them used enough. and long strings with q/qq are not as nice. the one sometime negative about here docs is the trailing newline. notice in my query_edit sub i chomp it and then add the "\n\t" if needed to avoid a long line. so it is simple to workaround. uri -- Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-04 22:22:54
|
On 1/4/2004 12:46 PM, Uri Guttman wrote:
>>>>>>"RWS" == Randy W Sims <Ra...@Th...> writes:
>
>
> RWS> On 1/4/2004 2:01 AM, Uri Guttman wrote:
> >> sub edit_query {
> >> my ( $query, $default ) = @_;
> >> chomp $query;
> >> my $last_line = (split /\n/, $query)[-1];
> >> if ( length( $last_line ) + 2 * length( $default ) > 70 ) {
> >> $query .= "\n\t";
> >> }
> >> return $query ;
> >> }
>
> RWS> A simple format_prompt() function similar to the above which also
> RWS> wrapped lines on word boundaries at some configurable screen width
> RWS> could make for some nicer prompts.
>
> would that want to be standalone or use text::format? also some
> queries/prompts might have formatted text (indented, columns, etc.)
> which would be broken in a formatter. so i thought only dealing with the
> last line and the default was a good idea. i use here docs so my prompt
> text looks exactly as i want it to look (other than that last line).
Actually, you're right--Here docs eliminate the need for word wrapping.
This is what happens when I think before I speak <:-I
Randy.
|
|
From: Uri G. <ur...@st...> - 2004-01-04 17:46:57
|
>>>>> "RWS" == Randy W Sims <Ra...@Th...> writes:
RWS> On 1/4/2004 2:01 AM, Uri Guttman wrote:
>> sub edit_query {
>> my ( $query, $default ) = @_;
>> chomp $query;
>> my $last_line = (split /\n/, $query)[-1];
>> if ( length( $last_line ) + 2 * length( $default ) > 70 ) {
>> $query .= "\n\t";
>> }
>> return $query ;
>> }
RWS> A simple format_prompt() function similar to the above which also
RWS> wrapped lines on word boundaries at some configurable screen width
RWS> could make for some nicer prompts.
would that want to be standalone or use text::format? also some
queries/prompts might have formatted text (indented, columns, etc.)
which would be broken in a formatter. so i thought only dealing with the
last line and the default was a good idea. i use here docs so my prompt
text looks exactly as i want it to look (other than that last line).
uri
--
Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-04 15:29:52
|
On 1/4/2004 2:01 AM, Uri Guttman wrote:
> sub edit_query {
> my ( $query, $default ) = @_;
> chomp $query;
> my $last_line = (split /\n/, $query)[-1];
> if ( length( $last_line ) + 2 * length( $default ) > 70 ) {
> $query .= "\n\t";
> }
> return $query ;
> }
A simple format_prompt() function similar to the above which also
wrapped lines on word boundaries at some configurable screen width could
make for some nicer prompts.
Randy.
|
|
From: Randy W. S. <Ra...@Th...> - 2004-01-04 15:19:04
|
On 1/4/2004 12:12 AM, Ken Williams wrote: > > On Saturday, January 3, 2004, at 11:59 AM, Randy W. Sims wrote: > >> I was wondering though... How attached to the interface are you? >> Couldn't we shorten the names to the obvious: >> >> preprocess() => converts .xs to .c >> compile() => converts .c to .o >> prelink() => generates export symbol file >> link() => creates library or executable (depending on args) > > > Yeah, sounds good to me. I'd had the library/executable split at the > compilation stage (compile_library() vs. compile_executable()) though, > is that wrong? When I do "gcc -o foo myprog.c" to create a 'foo' > executable, what are the equivalent separate compile & link stages? I think for the most part that the differences are small enough that we can use a parameter to differentiate instead of using seperate routines. I'm not yet sure how the static builds will fit in yet. After I get the Windows code cleaned up, I'll think about this some more and see if I can come up with a more coherent proposal. > Also, you think we should add XS capabilities to CBuilder? That would > add a lot of extra "smarts" to the module that I'm not sure it really > needs. I hadn't really looked yet at what would be required; I was thinking it would just be a simple proxy for invoking xsubpp or EU::ParseXS. It seems like it belongs in CBuilder as it is a preprocessor used in generating extensions... > I've got a new (well, actually about 10 years old) machine in my > basement that I'm going to set up, among other things, as a project > server for stuff like this. All my modules will have accessible > CVS/Perforce/Subversion/whatever repositories on it so we can work a > little more effectively on stuff like this. Ouch! I've got one of those 10+ year old machines sitting around too. It was my first PC, though I had had other computers. Hasn't been turned on in about 4-5 years, but I haven't been able to bring myself to get rid of it. A machine that old should be able to run fine for cvs though if your running under linux. It'll probably be more reliable than sourceforge. :-) Randy. |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-04 07:25:19
|
On 1/4/2004 12:44 AM, Ken Williams wrote:
> Hi Randy,
>
> Thanks, I'm working on applying this.
>
> On Tuesday, December 30, 2003, at 12:37 AM, Randy W. Sims wrote:
>
>> I'm not sure this patch is clean or complete (I'm up past my bedtime),
>> but I thought I'd post for comments. This patch:
>>
>> - Adapts the 'author' parameter to accept either a string or
>> anonymous array of strings for multiple authors.
>>
>> - Initialize dist_author and dist_abstract like dist_(name|version).
>
>
> I think these methods were a little more complicated than they needed to
> be, I've simplified 'em (_pod_parse() does its own memoization).
>
> Do we want $self->{dist_author} to always be an array ref, or always be
> however the user specified it? I'm thinking the latter, but I'm not sure.
I think it has to accept either. For backwards compatibility it needs to
accept a single string, and that's what will probably be used most often
anyway, so it's convenient. I think it should also accept an array
reference because many projects are developed by teams, and its easy and
makes sense to allow for that.
>> - Adds authored_by field to F<META.yml> and adapts PPMMaker.pm to
>> write multiple AUTHOR tags if appropriate in PPD files (which is
>> allowed by the PPD spec).
>
>
> Can we change 'authored_by' to just 'author' in the META.yml?
Yeah, the /only/ reason I chose 'authored_by' over 'author' is because
it makes sense when you read it whether there is one author or a dozen.
(Ex. "authored by Ken" / "authored by Ken, Micheal, Dave") I think
either way will be understandable, so I don't have a firm preference.
Randy.
|
|
From: Uri G. <ur...@st...> - 2004-01-04 07:02:44
|
well, i think i got it all working now. it isn't too bad. i even added
in the edited prompt when the default is very long thingy.
here is the relevant code:
my %defaults = (
bin_path => $Config{bin},
perl_path => $Config{perlpath},
conf_path => $default_conf_path,
prefix => $Config{prefix},
tail_dir => $default_tail_dir,
install_stem_demos => $is_win32,
install_ssfe => $is_win32,
%Stem::InstallConfig::Config,
);
sub query_config_value {
my( $self, $query, $key ) = @_ ;
my $default = $self->{args}{$key} ;
$default = $defaults{ $key } unless defined $default ;
$defaults{ $key } = ( $self->{args}{use_defaults} ) ?
$default :
$self->prompt( edit_query( $query, $default ), $default ) ;
}
sub get_config_boolean {
my( $self, $query, $key ) = @_ ;
my $default = $self->{args}{$key} ;
$default = $defaults{ $key } unless defined $default ;
$default = $default ? 'y' : 'n' ;
$defaults{ $key } = ( $self->{args}{use_defaults} ) ?
$default :
$self->y_n( edit_query( $query, $default ), $default ) ;
}
sub edit_query {
my ( $query, $default ) = @_ ;
chomp $query ;
my $last_line = (split /\n/, $query)[-1] ;
if ( length( $last_line ) + 2 * length( $default ) > 70 ) {
$query .= "\n\t" ;
}
return $query ;
}
note that i found a little problem with the boolean/y_n query. the
%defaults value is 1/0 (also from the loaded config hash) and that is
the result is also 1/0. but the default in the prompt has to be y/n. so
i had to make a conversion to y/n before the actual query. since the y_n
method knows it will be either y/n it should handle this for you. the
y_n method passes @_ to the prompt method so that would need changing to
store the args so the default can be forced to y/n and passed to
prompt().
now onto the actual install work which is mostly done and needs cleaning
up and testing.
uri
--
Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
|
|
From: Ken W. <ke...@ma...> - 2004-01-04 05:44:47
|
Hi Randy,
Thanks, I'm working on applying this.
On Tuesday, December 30, 2003, at 12:37 AM, Randy W. Sims wrote:
> I'm not sure this patch is clean or complete (I'm up past my bedtime),
> but I thought I'd post for comments. This patch:
>
> - Adapts the 'author' parameter to accept either a string or
> anonymous array of strings for multiple authors.
>
> - Initialize dist_author and dist_abstract like dist_(name|version).
I think these methods were a little more complicated than they needed
to be, I've simplified 'em (_pod_parse() does its own memoization).
Do we want $self->{dist_author} to always be an array ref, or always be
however the user specified it? I'm thinking the latter, but I'm not
sure.
>
> - Adds authored_by field to F<META.yml> and adapts PPMMaker.pm to
> write multiple AUTHOR tags if appropriate in PPD files (which is
> allowed by the PPD spec).
Can we change 'authored_by' to just 'author' in the META.yml?
>
> - Adds abstract field to the F<META.yml> file.
>
> - If YAML.pm is not installed, print a warning and generate a minimal
> META.yml file.
>
Great.
-Ken
|
|
From: Ken W. <ke...@ma...> - 2004-01-04 05:13:05
|
On Saturday, January 3, 2004, at 11:59 AM, Randy W. Sims wrote: > > I've got CBuilder compiling under Windows now; it's a bit hackish at > the moment, so I need to clean it up a bit. I should have had this > done sooner, but it was... not difficult, but.. a bit tedious for the > season, so I kept putting it off in favor of... lighter things. Anyway > I'll have a patch ready soon. Exactly the same reason I've been putting it off myself. =) > I was wondering though... How attached to the interface are you? > Couldn't we shorten the names to the obvious: > > preprocess() => converts .xs to .c > compile() => converts .c to .o > prelink() => generates export symbol file > link() => creates library or executable (depending on args) Yeah, sounds good to me. I'd had the library/executable split at the compilation stage (compile_library() vs. compile_executable()) though, is that wrong? When I do "gcc -o foo myprog.c" to create a 'foo' executable, what are the equivalent separate compile & link stages? Also, you think we should add XS capabilities to CBuilder? That would add a lot of extra "smarts" to the module that I'm not sure it really needs. I've got a new (well, actually about 10 years old) machine in my basement that I'm going to set up, among other things, as a project server for stuff like this. All my modules will have accessible CVS/Perforce/Subversion/whatever repositories on it so we can work a little more effectively on stuff like this. -Ken |
|
From: Randy W. S. <Ra...@Th...> - 2004-01-03 17:59:52
|
Hi Ken, I've got CBuilder compiling under Windows now; it's a bit hackish at the moment, so I need to clean it up a bit. I should have had this done sooner, but it was... not difficult, but.. a bit tedious for the season, so I kept putting it off in favor of... lighter things. Anyway I'll have a patch ready soon. I was wondering though... How attached to the interface are you? Couldn't we shorten the names to the obvious: preprocess() => converts .xs to .c compile() => converts .c to .o prelink() => generates export symbol file link() => creates library or executable (depending on args) Just a thought. Regards, Randy. |
|
From: Uri G. <ur...@st...> - 2004-01-02 06:25:33
|
here is a interesting but tiny problem. in my query code i expected the prompt to have a [] in it. i would do an s/// on that to put in the default value. the build prompt and y_n methods do something simular. but my question is about where does that default string get printed? if the question ends at a certain column and the default is long enough, it forces the user input to be wrapped beyond 80 columns. also my questions were passed in as here docs (love them!) but that causes them to end in a newline and so the default is always on the next line. sure i can chomp off that newline and such. but still is there any way to make the prompt print nicely with room for the default and user input? this means if the default and user input (assume the length of the default) is long enough to wrap, then print them on the next line. like i said, this isn't critical but has anyone done anything with this? uri -- Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org |
|
From: Uri G. <ur...@st...> - 2004-01-02 04:55:56
|
>>>>> "RWS" == Randy W Sims <Ra...@th...> writes: RWS> On 1/1/2004 11:08 PM, Uri Guttman wrote: >> so i won't be testing this as i don't really need it for this right >> now. but i can see users wanting it for multiple installations and >> similar situations. RWS> Ok, I guess the extended version I just posted is unneccessary RWS> also <<:-\ RWS> But I still think it usefull addition to M::B to aid testing and RWS> automation. it looks like a good tool for that so don't erase it. i just don't need it now. there are plenty of uses for an automated way to answer install scripts. uri -- Uri Guttman ------ ur...@st... -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org |
7 messages has been excluded from this view by a project administrator.
