Graph::Easy installation failing here with YAML 0.50 (newer versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Any suggestions?
Adam K
Moin Alex,
On Saturday 28 January 2006 01:35, [EMAIL PROTECTED] wrote:
Hello,
I was doing some I18N of a bunch of existing CGI scripts and
encountered a problem.
I guess I'm making some very basic error, but I'm stuck with this for a
day and I thought
I may ask. I have my strings in
Moin,
On Saturday 28 January 2006 11:08, Adam Kennedy wrote:
Graph::Easy installation failing here with YAML 0.50 (newer versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Just what I said about dependecies etc. My
Moin,
On Saturday 28 January 2006 08:20, Tyler MacDonald wrote:
Gabor Szabo [EMAIL PROTECTED] wrote:
I have just moved to Ubuntu and thought I will try to rely on apt-get
to install my Perl modules. Quckly I hit a wall and could not install
some of the basic modules. I did not have the
On Sat, Jan 28, 2006 at 09:08:48PM +1100, Adam Kennedy wrote:
Graph::Easy installation failing here with YAML 0.50 (newer versions of
YAML seem to be uninstallable at the moment due to Class::Spiffy +
Spiffy + Test::Base install failures...
Any suggestions?
You're getting install failures
Knocking off points for fails, however, might be due to things that are
completely idiosyncratic. For example, anyone whose module depended on
a test module that used Test::Builder::Tester when Test::Builder changed
and broke it could get dinged.
Does this really tell us anything about
* Adam Kennedy [EMAIL PROTECTED] [2006-01-28 09:00]:
If a Perl module needs libfoo then it should be stated in the
metadata somewhere so that the binary packaging system can
resolve that generalised dependency into the appropriate action
for that environment.
++
How does Alien:: stack up here in
Moin,
On Saturday 28 January 2006 15:54, David Golden wrote:
Adam Kennedy wrote:
Likewise, if your module installs all the way from a vanilla
installation and all it dependencies go on cleanly, then I think
that's well and truly worthy of a point.
Something like a clean_install metric.
Adam Kennedy wrote:
Whether or not that is a transient thing that lasts for a week, or a
serious and ongoing problem, I think it's still worth it.
But that would require regular scanning -- otherwise I might get the
point one week and then a dependency might upgrade in a way that is
borked.
As I understand it, Alien packs the module for you, or otherwise does
what it takes. Having only done a quick basic reading of the Alien
docs, it seems that it's a brute force thing for when you REALLY want
the lib and you have only CPAN.pm with which to get it. (Although it
might shortcut in
A. Pagaltzis wrote:
* Adam Kennedy [EMAIL PROTECTED] [2006-01-28 16:20]:
More to the point, it should lead people to spend more time
looking into WHY their module isn't installing, and help us nail
down the critical modules in the CPAN toolchain that have
problems.
Sounds to me like a case of
* Adam Kennedy [EMAIL PROTECTED] [2006-01-28 17:15]:
So do have any additional specific objections, or are we up to
grumble, just fucking do it then, but I won't care :)
Actually, I like the effort, even if I share some of the concerns
of the people who ridicule it. But it won’t motivate *me* to
On Jan 27, 2006, at 6:06 PM, James E Keenan wrote:
Steffen Schwigon wrote:
Quite often -l (to read from lib/) is enough, depending on your
module
build complexity. For -b you have to call ./Build before prove,
which can be annoying and/or difficult to remember.
I'll have to try that out.
Barbie [EMAIL PROTECTED] wrote:
I'm one of the maintainers/developers for CPAN::YACSmoke. I was
intrigued by your post about adding a Packager plugin to it. However,
I'm unclear as to what purpose it would serve. CPAN::YACSmoke is purely
about reporting on test results. CPANPLUS does the
A. Pagaltzis wrote:
* Adam Kennedy [EMAIL PROTECTED] [2006-01-28 17:15]:
So do have any additional specific objections, or are we up to
grumble, just fucking do it then, but I won't care :)
Actually, I like the effort, even if I share some of the concerns
of the people who ridicule it. But it
(*If* the author fixes the problem. I still can't get my patches for
Sub::Uplevel high enough in Schwern's queue.
Have you considered offering to take it over, or just co-maint the
module for one or two releases? He's given away modules before to people
that have more time to give them love
Gabor Szabo [EMAIL PROTECTED] wrote:
You simple cannot guess what libraries/compiler/system/kernel the user
has installed, unless you know the distribution and version *and* require
that the user never updates anything.
I think I agree. That's what I would like to see solved. If I stick
Changing these HTTP like codes, might okay for an internal
representation, but would require ALOT of work to change several CPAN
modules and ensure all the testers upgraded. There is also the fact that
all existing reports are in the system and not going to change. Although
I may have
* Adam Kennedy [EMAIL PROTECTED] [2006-01-28 18:45]:
My point is really that CPAN Testers CAN be fixed, it's merely a
case of how much effort is involved and finding someone that
cares enough to fix it.
I wasn’t saying anything to the contrary; just saying that that
is where the effort should be
On Sat, Jan 28, 2006 at 11:01:06AM -0500, David Golden wrote:
You need to deal with N/A's down the chain. E.g. I prereq a module that
can't be built in an automated fashion but requires human intervention
or choices or external libraries. If you don't have it and the
automated build to
At 4:35 pm -0800 27/1/06, [EMAIL PROTECTED] wrote:
Hello,
I was doing some I18N of a bunch of existing CGI scripts and
encountered a problemI have my strings in UTF-8. I read most of
them from file,do some processing and spit them out of the
CGI-script.
Let say I do this:
On Sun, Jan 29, 2006 at 04:45:51AM +1100, Adam Kennedy wrote:
I haven't been able to find (although I haven't looked to hard) for a
documented set of result codes. But either DEPFAIL or N/A makes sense.
See CPAN::YACSmoke pod. Just before Christmas I completed the
TestersGuide pod, which
Adam Kennedy wrote:
That said, I'd also like I need libfoo 1.41 declarations and other
similar things, so we can really make the auto-packagers work some
hardcore magic.
/me takes the Net::Pcap maintainer hat
I'd really like to see something like that, this would allow for
a much simpler
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
That said, I'd also like I need libfoo 1.41 declarations and other
similar things, so we can really make the auto-packagers work some
hardcore magic.
/me takes the Net::Pcap maintainer hat
I'd really like to see something like that,
Gabor Szabo wrote:
I think I agree. That's what I would like to see solved. If I stick to
the standard apt-get (or whatever) of my distribution I would like to be
able to get all the CPAN modules by saying
# apt-get install Module::Name
Did anybody here have played with CPANPLUS::Dist::Deb?
Adam Kennedy wrote:
(*If* the author fixes the problem. I still can't get my patches for
Sub::Uplevel high enough in Schwern's queue.
Have you considered offering to take it over, or just co-maint the
module for one or two releases? He's given away modules before to people
that have more
Adam Kennedy wrote:
Could you have a look at the COOKBOOK section of the Module::Install
docs on CPAN, is that File::HomeDir example sort of what you would need?
Module::Install... 1) I'm allergic to this module, 2) I want to keep
the backward compatibility with Perl 5.004, and Module::Install
Sébastien Aperghis-Tramoni wrote:
Adam Kennedy wrote:
Could you have a look at the COOKBOOK section of the Module::Install
docs on CPAN, is that File::HomeDir example sort of what you would need?
Module::Install... 1) I'm allergic to this module, 2) I want to keep
the backward compatibility
Tels,
Please forgive me for being blunt, but I think it's your fault for
writing fragile META.yml creation code. YAML.pm is not even at 1.00
yet, so an API change is allowed by convention, and lack of backward
compatibility is to be expected. If you were to have wrapped your
whole
On Fri, Jan 27, 2006 at 03:42:58PM +0100, Tels wrote:
On Thursday 26 January 2006 15:26, Thomas Klausner wrote:
I just uploaded Module::CPANTS::Analyse to CPAN. MCA contains most of
the previous Kwalitee indicators and some code to check if one
distribution tarball conforms to those
30 matches
Mail list logo
