Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to configure cpan: getaddrinfo(ucu.ac.ug,,AF_INET) failed - No address associated with hostname #144

Open
hakonhagland opened this issue Jan 14, 2021 · 1 comment

Comments

@hakonhagland
Copy link

I am trying to configure cpan manually after installing perl 5.26.2 with Anaconda :

$ cd /home/hakon/anaconda3/envs/perl_test/bin
$ ./cpan 
Loading internal null logger. Install Log::Log4perl for logging messages
Sorry, we have to rerun the configuration dialog for CPAN.pm due to
some missing parameters. Configuration will be written to
 <</home/hakon/.cpan/CPAN/MyConfig.pm>>


CPAN.pm requires configuration, but most of it can be done automatically.
If you answer 'no' below, you will enter an interactive dialog for each
configuration option instead.

Would you like to configure as much as possible automatically? [yes] no

Use of uninitialized value $what in concatenation (.) or string at /home/hakon/anaconda3/envs/perl_test/lib/5.26.2/App/Cpan.pm line 669, <STDIN> line 1.
 <install_help>

Warning: You do not have write permission for Perl library directories.

To install modules, you need to configure a local Perl library directory or
escalate your privileges.  CPAN can help you by bootstrapping the local::lib
module or by configuring itself to use 'sudo' (if available).  You may also
resolve this problem manually if you need to customize your setup.

What approach do you want?  (Choose 'local::lib', 'sudo' or 'manual')
 [local::lib] manual



The following questions are intended to help you with the
configuration. The CPAN module needs a directory of its own to cache
important index files and maybe keep a temporary mirror of CPAN files.
This may be a site-wide or a personal directory.


I see you already have a directory

/home/hakon/.cpan
Shall we use it as the general CPAN build and cache directory?

 <cpan_home>
CPAN build and cache directory? [/home/hakon/.cpan] /home/hakon/anaconda3/envs/perl_test/.cpan

Unless you are accessing the CPAN on your filesystem via a file: URL,
CPAN.pm needs to keep the source files it downloads somewhere. Please
supply a directory where the downloaded files are to be kept.

 <keep_source_where>
Download target directory? [/home/hakon/anaconda3/envs/perl_test/.cpan/sources] 

 <build_dir>
Directory where the build process takes place? [/home/hakon/anaconda3/envs/perl_test/.cpan/build] 

Until version 1.88 CPAN.pm never trusted the contents of the build_dir
directory between sessions. Since 1.88_58 CPAN.pm has a YAML-based
mechanism that makes it possible to share the contents of the
build_dir/ directory between different sessions with the same version
of perl. People who prefer to test things several days before
installing will like this feature because it saves a lot of time.

If you say yes to the following question, CPAN will try to store
enough information about the build process so that it can pick up in
future sessions at the same state of affairs as it left a previous
session.

 <build_dir_reuse>
Store and re-use state information about distributions between
CPAN.pm sessions? [no] 

CPAN.pm can store customized build environments based on regular
expressions for distribution names. These are YAML files where the
default options for CPAN.pm and the environment can be overridden and
dialog sequences can be stored that can later be executed by an
Expect.pm object. The CPAN.pm distribution comes with some prefab YAML
files that cover sample distributions that can be used as blueprints
to store your own prefs. Please check out the distroprefs/ directory of
the CPAN.pm distribution to get a quick start into the prefs system.

 <prefs_dir>
Directory where to store default options/environment/dialogs for
building modules that need some customization? [/home/hakon/anaconda3/envs/perl_test/.cpan/prefs] 

Normally CPAN.pm keeps config variables in memory and changes need to
be saved in a separate 'o conf commit' command to make them permanent
between sessions. If you set the 'auto_commit' option to true, changes
to a config variable are always automatically committed to disk.

 <auto_commit>
Always commit changes to config variables to disk? [no] 

CPAN.pm can limit the size of the disk area for keeping the build
directories with all the intermediate files.

 <build_cache>
Cache size for build directory (in MB)? [100] 

The CPAN indexes are usually rebuilt once or twice per hour, but the
typical CPAN mirror mirrors only once or twice per day. Depending on
the quality of your mirror and your desire to be on the bleeding edge,
you may want to set the following value to more or less than one day
(which is the default). It determines after how many days CPAN.pm
downloads new indexes.

 <index_expire>
Let the index expire after how many days? [1] 

By default, each time the CPAN module is started, cache scanning is
performed to keep the cache size in sync ('atstart'). Alternatively,
scanning and cleanup can happen when CPAN exits ('atexit'). To prevent
any cache cleanup, answer 'never'.

 <scan_cache>
Perform cache scanning ('atstart', 'atexit' or 'never')? [atstart] 

Users who install modules and do not intend to look back, can free
occupied disk space quickly by letting CPAN.pm cleanup each build
directory immediately after a successful install.

 <cleanup_after_install>
Remove build directory after a successful install? (yes/no)? [no] 

To considerably speed up the initial CPAN shell startup, it is
possible to use Storable to create a cache of metadata. If Storable is
not available, the normal index mechanism will be used.

Note: this mechanism is not used when use_sqlite is on and SQLLite is
running.

 <cache_metadata>
Cache metadata (yes/no)? [yes] 

CPAN::SQLite is a layer between the index files that are downloaded
from the CPAN and CPAN.pm that speeds up metadata queries and reduces
memory consumption of CPAN.pm considerably.

 <use_sqlite>
Use CPAN::SQLite if available? (yes/no)? [no] 

The CPAN module can detect when a module which you are trying to build
depends on prerequisites. If this happens, it can build the
prerequisites for you automatically ('follow'), ask you for
confirmation ('ask'), or just ignore them ('ignore').  Choosing
'follow' also sets PERL_AUTOINSTALL and PERL_EXTUTILS_AUTOINSTALL for
"--defaultdeps" if not already set.

Please set your policy to one of the three values.

 <prerequisites_policy>
Policy on building prerequisites (follow, ask or ignore)? [follow] 

When a module declares another one as a 'build_requires' prerequisite
this means that the other module is only needed for building or
testing the module but need not be installed permanently. In this case
you may wish to install that other module nonetheless or just keep it
in the 'build_dir' directory to have it available only temporarily.
Installing saves time on future installations but makes the perl
installation bigger.

You can choose if you want to always install (yes), never install (no)
or be always asked. In the latter case you can set the default answer
for the question to yes (ask/yes) or no (ask/no).

 <build_requires_install_policy>
Policy on installing 'build_requires' modules (yes, no, ask/yes,
ask/no)? [yes] 

(Experimental feature!) Some CPAN modules recommend additional, optional dependencies.  These should
generally be installed except in resource constrained environments.  When this
policy is true, recommended modules will be included with required modules.

 <recommends_policy>
Included recommended modules? [yes] 

(Experimental feature!) Some CPAN modules suggest additional, optional dependencies.  These 'suggest'
dependencies provide enhanced operation.  When this policy is true, suggested
modules will be included with required modules.

 <suggests_policy>
Included suggested modules? [no] 

CPAN packages can be digitally signed by authors and thus verified
with the security provided by strong cryptography. The exact mechanism
is defined in the Module::Signature module. While this is generally
considered a good thing, it is not always convenient to the end user
to install modules that are signed incorrectly or where the key of the
author is not available or where some prerequisite for
Module::Signature has a bug and so on.

With the check_sigs parameter you can turn signature checking on and
off. The default is off for now because the whole tool chain for the
functionality is not yet considered mature by some. The author of
CPAN.pm would recommend setting it to true most of the time and
turning it off only if it turns out to be annoying.

Note that if you do not have Module::Signature installed, no signature
checks will be performed at all.

 <check_sigs>
Always try to check and verify signatures if a SIGNATURE file is in
the package and Module::Signature is installed (yes/no)? [no] 

The goal of the CPAN Testers project (http://testers.cpan.org/) is to
test as many CPAN packages as possible on as many platforms as
possible.  This provides valuable feedback to module authors and
potential users to identify bugs or platform compatibility issues and
improves the overall quality and value of CPAN.

One way you can contribute is to send test results for each module
that you install.  If you install the CPAN::Reporter module, you have
the option to automatically generate and deliver test reports to CPAN
Testers whenever you run tests on a CPAN package.

See the CPAN::Reporter documentation for additional details and
configuration settings.  If your firewall blocks outgoing traffic,
you may need to configure CPAN::Reporter before sending reports.

 <test_report>
Generate test reports if CPAN::Reporter is installed (yes/no)? [no] 

When a distribution has already been tested by CPAN::Reporter on
this machine, CPAN can skip the test phase and just rely on the
test report history instead.

Note that this will not apply to distributions that failed tests
because of missing dependencies.  Also, tests can be run
regardless of the history using "force".

 <trust_test_report_history>
Do you want to rely on the test report history (yes/no)? [no] 

At the time of this writing (2009-03) there are three YAML
implementations working: YAML, YAML::Syck, and YAML::XS. The latter
two are faster but need a C compiler installed on your system. There
may be more alternative YAML conforming modules. When I tried two
other players, YAML::Tiny and YAML::Perl, they seemed not powerful
enough to work with CPAN.pm. This may have changed in the meantime.

 <yaml_module>
Which YAML implementation would you prefer? [YAML] 

Warning (maybe harmless): 'YAML' not installed.
Both YAML.pm and YAML::Syck are capable of deserialising code. As this
requires a string eval, which might be a security risk, you can use
this option to enable or disable the deserialisation of code via
CPAN::DeferredCode. (Note: This does not work under perl 5.6)

 <yaml_load_code>
Do you want to enable code deserialisation (yes/no)? [no] 



The CPAN module will need a few external programs to work properly.
Please correct me, if I guess the wrong path for a program. Don't
panic if you do not have some of them, just press ENTER for those. To
disable the use of a program, you can type a space followed by ENTER.

 <make>
Where is your make program? [/bin/make] 
 <bzip2>
Where is your bzip2 program? [/bin/bzip2] 
 <gzip>
Where is your gzip program? [/bin/gzip] 
 <tar>
Where is your tar program? [/bin/tar] 
 <unzip>
Where is your unzip program? [/bin/unzip] 
 <gpg>
Where is your gpg program? [/bin/gpg] 
 <patch>
Where is your patch program? [/bin/patch] 
 <applypatch>
Where is your applypatch program? [] /bin/applypatch
 <wget>
Where is your wget program? [/bin/wget] 
 <pager>
What is your favorite pager program? [less] 

 <shell>
What is your favorite shell? [/bin/bash] 

Per default all untar operations are done with the perl module
Archive::Tar; by setting this variable to true the external tar
command is used if available; on Unix this is usually preferred
because they have a reliable and fast gnutar implementation.

 <prefer_external_tar>
Use the external tar program instead of Archive::Tar? [yes] 

When CPAN.pm uses the tar command, which switch for the verbosity
shall be used? Choose 'none' for quiet operation, 'v' for file
name listing, 'vv' for full listing.

 <tar_verbosity>
Tar command verbosity level (none or v or vv)? [none] 

When CPAN.pm loads a module it needs for some optional feature, it
usually reports about module name and version. Choose 'v' to get this
message, 'none' to suppress it.

 <load_module_verbosity>
Verbosity level for loading modules (none or v)? [none] 

When CPAN.pm extends @INC via PERL5LIB, it prints a list of
directories added (or a summary of how many directories are
added).  Choose 'v' to get this message, 'none' to suppress it.

 <perl5lib_verbosity>
Verbosity level for PERL5LIB changes (none or v)? [none] 

When the CPAN shell is started it normally displays a greeting message
that contains the running version and the status of readline support.

 <inhibit_startup_message>
Do you want to turn this message off? [no] 

When you have Module::Build installed and a module comes with both a
Makefile.PL and a Build.PL, which shall have precedence?

The main two standard installer modules are the old and well
established ExtUtils::MakeMaker (for short: EUMM) which uses the
Makefile.PL. And the next generation installer Module::Build (MB)
which works with the Build.PL (and often comes with a Makefile.PL
too). If a module comes only with one of the two we will use that one
but if both are supplied then a decision must be made between EUMM and
MB. See also http://rt.cpan.org/Ticket/Display.html?id=29235 for a
discussion about the right default.

Or, as a third option you can choose RAND which will make a random
decision (something regular CPAN testers will enjoy).

 <prefer_installer>
In case you can choose between running a Makefile.PL or a Build.PL,
which installer would you prefer (EUMM or MB or RAND)? [MB] 

Every Makefile.PL is run by perl in a separate process. Likewise we
run 'make' and 'make install' in separate processes. If you have
any parameters (e.g. PREFIX, UNINST or the like) you want to
pass to the calls, please specify them here.

If you don't understand this question, just press ENTER.

Typical frequently used settings:

    PREFIX=~/perl    # non-root users (please see manual for more hints)

 <makepl_arg>
Parameters for the 'perl Makefile.PL' command? [] 

Parameters for the 'make' command? Typical frequently used setting:

    -j3              # dual processor system (on GNU make)

 <make_arg>
Your choice: [] -j6

Do you want to use a different make command for 'make install'?
Cautious people will probably prefer:

    su root -c make
 or
    sudo make
 or
    /path1/to/sudo -u admin_account /path2/to/make

 <make_install_make_command>
or some such. Your choice: [/bin/make] 

Parameters for the 'make install' command?
Typical frequently used setting:

    UNINST=1         # to always uninstall potentially conflicting files
                     # (but do NOT use with local::lib or INSTALL_BASE)

 <make_install_arg>
Your choice: [-j6] 

A Build.PL is run by perl in a separate process. Likewise we run
'./Build' and './Build install' in separate processes. If you have any
parameters you want to pass to the calls, please specify them here.

Typical frequently used settings:

    --install_base /home/xxx             # different installation directory

 <mbuildpl_arg>
Parameters for the 'perl Build.PL' command? [] 

Parameters for the './Build' command? Setting might be:

    --extra_linker_flags -L/usr/foo/lib  # non-standard library location

 <mbuild_arg>
Your choice: [] 

Do you want to use a different command for './Build install'? Sudo
users will probably prefer:

    su root -c ./Build
 or
    sudo ./Build
 or
    /path1/to/sudo -u admin_account ./Build

 <mbuild_install_build_command>
or some such. Your choice: [./Build] 

Parameters for the './Build install' command? Typical frequently used
setting:

    --uninst 1       # uninstall conflicting files
                     # (but do NOT use with local::lib or INSTALL_BASE)

 <mbuild_install_arg>
Your choice: [] 

When this is true, CPAN will set PERL_MM_USE_DEFAULT to a true
value.  This causes ExtUtils::MakeMaker (and compatible) prompts
to use default values instead of stopping to prompt you to answer
questions. It also sets NONINTERACTIVE_TESTING to a true value to
signal more generally that distributions should not try to
interact with you.

 <use_prompt_default>
Do you want to use prompt defaults (yes/no)? [no] 

Sometimes you may wish to leave the processes run by CPAN alone
without caring about them. Because the Makefile.PL or the Build.PL
sometimes contains question you're expected to answer, you can set a
timer that will kill a 'perl Makefile.PL' process after the specified
time in seconds.

If you set this value to 0, these processes will wait forever. This is
the default and recommended setting.

 <inactivity_timeout>
Timeout for inactivity during {Makefile,Build}.PL? [0] 

This timeout prevents CPAN from hanging when trying to parse a
pathologically coded $VERSION from a module.

The default is 15 seconds.  If you set this value to 0, no timeout
will occur, but this is not recommended.

 <version_timeout>
Timeout for parsing module versions? [15] 

Normally, CPAN.pm continues processing the full list of targets and
dependencies, even if one of them fails.  However, you can specify
that CPAN should halt after the first failure.  (Note that optional
recommended or suggested modules that fail will not cause a halt.)

 <halt_on_failure>
Do you want to halt on failure (yes/no)? [no] 



If you're accessing the net via proxies, you can specify them in the
CPAN configuration or via environment variables. The variable in
the $CPAN::Config takes precedence.

 <ftp_proxy>
Your ftp_proxy? [] 

 <http_proxy>
Your http_proxy? [] 

 <no_proxy>
Your no_proxy? [] 

 <ftp_passive>
Shall we always set the FTP_PASSIVE environment variable when dealing
with ftp download (yes/no)? [yes] 

CPAN.pm changes the current working directory often and needs to
determine its own current working directory. Per default it uses
Cwd::cwd but if this doesn't work on your system for some reason,
alternatives can be configured according to the following table:

    cwd         Cwd::cwd
    getcwd      Cwd::getcwd
    fastcwd     Cwd::fastcwd
    getdcwd     Cwd::getdcwd
    backtickcwd external command cwd

 <getcwd>
Preferred method for determining the current working directory? [cwd] 

The prompt of the cpan shell can contain the current command number
for easier tracking of the session or be a plain string.

 <commandnumber_in_prompt>
Do you want the command number in the prompt (yes/no)? [yes] 

When using Term::ReadLine, you can turn ornaments on so that your
input stands out against the output from CPAN.pm.

 <term_ornaments>
Do you want to turn ornaments on? [yes] 

When you have Term::ANSIColor installed, you can turn on colorized
output to have some visual differences between normal CPAN.pm output,
warnings, debugging output, and the output of the modules being
installed. Set your favorite colors after some experimenting with the
Term::ANSIColor module.

Please note that on Windows platforms colorized output also requires
the Win32::Console::ANSI module.

 <colorize_output>
Do you want to turn on colored output? [no] 

The next option deals with the charset (a.k.a. character set) your
terminal supports. In general, CPAN is English speaking territory, so
the charset does not matter much but some CPAN have names that are
outside the ASCII range. If your terminal supports UTF-8, you should
say no to the next question. If it expects ISO-8859-1 (also known as
LATIN1) then you should say yes. If it supports neither, your answer
does not matter because you will not be able to read the names of some
authors anyway. If you answer no, names will be output in UTF-8.

 <term_is_latin>
Your terminal expects ISO-8859-1 (yes/no)? [yes] no

If you have one of the readline packages (Term::ReadLine::Perl,
Term::ReadLine::Gnu, possibly others) installed, the interactive CPAN
shell will have history support. The next two questions deal with the
filename of the history file and with its size. If you do not want to
set this variable, please hit SPACE ENTER to the following question.

If you have one of the readline packages (Term::ReadLine::Perl,
Term::ReadLine::Gnu, possibly others) installed, the interactive CPAN
shell will have history support. The next two questions deal with the
filename of the history file and with its size. If you do not want to
set this variable, please hit SPACE ENTER to the following question.

 <histfile>
File to save your history? [/home/hakon/anaconda3/envs/perl_test/.cpan/histfile] 

 <histsize>
Number of lines to save? [100] 

The 'd' and the 'm' command normally only show you information they
have in their in-memory database and thus will never connect to the
internet. If you set the 'show_upload_date' variable to true, 'm' and
'd' will additionally show you the upload date of the module or
distribution. Per default this feature is off because it may require a
net connection to get at the upload date.

 <show_upload_date>
Always try to show upload date with 'd' and 'm' command (yes/no)? [no] 

During the 'r' command CPAN.pm finds modules without version number.
When the command finishes, it prints a report about this. If you
want this report to be very verbose, say yes to the following
variable.

 <show_unparsable_versions>
Show all individual modules that have no $VERSION? [no] 

During the 'r' command CPAN.pm finds modules with a version number of
zero. When the command finishes, it prints a report about this. If you
want this report to be very verbose, say yes to the following
variable.

 <show_zero_versions>
Show all individual modules that have a $VERSION of zero? [no] 

If you have never defined your own C<urllist> in your configuration
then C<CPAN.pm> will be hesitant to use the built in default sites for
downloading. It will ask you once per session if a connection to the
internet is OK and only if you say yes, it will try to connect. But to
avoid this question, you can choose your favorite download sites once
and get away with it. Or, if you have no favorite download sites
answer yes to the following question.

 <connect_to_internet_ok>
If no urllist has been chosen yet, would you prefer CPAN.pm to connect
to the built-in default sites without asking? (yes/no)? [yes] 


Now you need to choose your CPAN mirror sites.  You can let me
pick mirrors for you, you can select them from a list or you
can enter them by hand.

Would you like me to automatically choose some CPAN mirror
sites for you? (This means connecting to the Internet) [yes] 

Trying to fetch a mirror list from the Internet
Fetching with HTTP::Tiny:
http://www.perl.org/CPAN/MIRRORED.BY

Looking for CPAN mirrors near you (please be patient)
getaddrinfo(ucu.ac.ug,,AF_INET) failed - No address associated with hostname at /home/hakon/anaconda3/envs/perl_test/lib/5.26.2/CPAN/Mirrors.pm line 564.

Here cpan aborts, and unfortunately no configuration was saved. Any idea what is going on?

@andk
Copy link
Owner

andk commented Jan 14, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants