pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/42691 (net/bittorrent fails to build (installs too many files))

On Fri 29 Jan 2010 at 16:30:04 +0000, Rhialto wrote:
>  Next I'll try cleaning out the chroot, since it has built almost all
>  binary packages already anyway, and install bittorrent from a hopefully
>  clean start.

And then, the files don't get installed! And I think I see a
difference, too.

At the start of the build, after the long line ending in
"/usr/pkg/bin/python2.5 build )" that supposedly runs, there is an extra line of output:

extra:  python: not found
        running build
        running build_py

This may be caused by the first line of being

    #!/usr/bin/env python

but there is no python, only python2.5.

Apparently, previously I did have a /usr/pkg/bin/python, and the one in
my main system is a wrapper script from pkg_alternatives, although the
pkg database denies knowledge of which pkg has installed it.

So explicitly calling "python2.5" to be explicit about the
python interpreter isn't sufficient, but even fixing the #! line
isn't enough (???).

pkg_comp:default.conf# python2.5                                      
python: not found
Traceback (most recent call last):
 line 383, in install_translation
    lang = read_language_file()
 line 335, in read_language_file
    lang_file_name = language_path()
 line 318, in language_path
    lang_file_name = os.path.join(config_dir, '.bittorrent', 'data', 'language')
  File "/usr/pkg/lib/python2.5/", line 62, in join
    elif path == '' or path.endswith('/'):
AttributeError: 'NoneType' object has no attribute 'endswith'
usage: [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: --help [cmd1 cmd2 ...]
   or: --help-commands
   or: cmd --help

error: no commands supplied

Looking at the traceback, config_dir seems to be undefined, but this
seems to be a red herring, related to the absence of a fake $HOME

When adding a symlink from /usr/pkg/bin/python -> python2.5, the line

    os.system('sh ./')

magically starts to work ( produces plenty of output that
shows it is running).

But... the solution seems nearby: don't call the script, or
patch it (or Python) so that it works (and add the locale files to
PLIST). Maybe it is really a problem for the Python maintainers to

(Maybe as a workaround, if fixing Python takes too long, you can call
the shell script from the pkgsrc Makefile and stub out the call in

___ Olaf 'Rhialto' Seibert    -- You author it, and I'll reader it.
\X/ rhialto/at/      -- Cetero censeo "authored" delendum esse.

Home | Main Index | Thread Index | Old Index