Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 374871 - net-misc/pyload - A fast, lightweight and full featured download manager for many One-Click-Hosters
Summary: net-misc/pyload - A fast, lightweight and full featured download manager for ...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: Normal normal with 4 votes (vote)
Assignee: Default Assignee for New Packages
URL: https://pyload.github.io/
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks:
 
Reported: 2011-07-11 16:45 UTC by Andre Reinke
Modified: 2016-08-25 22:10 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuild for pyload-0.4.7 and -9999 (pyload-0.4.7.ebuild,3.04 KB, text/plain)
2011-09-20 11:43 UTC, Wilke Schwiedop
Details
pyload init.d file (pyload,382 bytes, text/plain)
2011-09-20 11:44 UTC, Wilke Schwiedop
Details
pyload systemd service (pyload.service,160 bytes, text/plain)
2011-09-20 11:45 UTC, Wilke Schwiedop
Details
refactored ebuild (0.4.7 / 9999) (pyload-0.4.7.ebuild,3.08 KB, text/plain)
2011-09-29 01:19 UTC, hal
Details
0.4.7 with hal's changes and a check that prevents overwriting an existing config (pyload-0.4.7.ebuild,3.13 KB, text/plain)
2011-09-30 10:51 UTC, Wilke Schwiedop
Details
pyload-0.4.7.ebuild (pyload-0.4.7.ebuild,3.21 KB, text/plain)
2011-11-22 23:37 UTC, Sven E.
Details
pyload.init (pyload.init,379 bytes, text/plain)
2011-11-22 23:38 UTC, Sven E.
Details
pyload.init (pyload.init,371 bytes, text/plain)
2011-11-23 01:09 UTC, Sven E.
Details
pyload-0.4.8-sanitize-config.patch (pyload-0.4.8-sanitize-config.patch,877 bytes, text/plain)
2011-11-23 20:44 UTC, Sven E.
Details
pyload-0.4.8-pid.patch (pyload-0.4.8-pid.patch,1.60 KB, text/plain)
2011-11-23 20:45 UTC, Sven E.
Details
pyload-0.4.8.ebuild (pyload-0.4.8.ebuild,3.78 KB, text/plain)
2011-11-23 20:59 UTC, Sven E.
Details
pyload.init (pyload.init,368 bytes, text/plain)
2011-11-23 21:01 UTC, Sven E.
Details
pyload.confd (pyload.confd,128 bytes, text/plain)
2011-11-23 21:02 UTC, Sven E.
Details
pyload.init (pyload.init,373 bytes, text/plain)
2011-11-23 21:18 UTC, Sven E.
Details
pyload.confd (pyload.confd,193 bytes, text/plain)
2011-11-23 21:18 UTC, Sven E.
Details
pyload-0.4.8-locale-fix.patch (pyload-0.4.8-locale-fix.patch,4.42 KB, text/plain)
2011-11-23 23:10 UTC, Sven E.
Details
pyload-0.4.8.ebuild (pyload-0.4.8.ebuild,3.68 KB, text/plain)
2011-11-23 23:11 UTC, Sven E.
Details
pyload-0.4.8-locale-fix.patch (pyload-0.4.8-locale-fix.patch,5.09 KB, text/plain)
2011-11-26 18:09 UTC, Sven E.
Details
Reworked locale patch against mercurial tip (locale.patch,7.58 KB, patch)
2011-11-29 22:16 UTC, Sven E.
Details | Diff
pyload-0.4.8-jinja.patch (pyload-0.4.8-jinja.patch,919 bytes, text/plain)
2011-11-30 19:36 UTC, Sven E.
Details
Removed Syntax Error (due to typo) .... (locale.patch,7.58 KB, patch)
2011-12-01 10:41 UTC, Sven E.
Details | Diff
pyload-0.4.8.ebuild (pyload-0.4.8.ebuild,3.84 KB, text/plain)
2011-12-01 22:08 UTC, Sven E.
Details
More sed'ing to catch the rest of the imports (pyload-0.4.8.ebuild,3.88 KB, text/plain)
2011-12-02 11:34 UTC, Sven E.
Details
locale wrapper fixup (locale.patch,7.71 KB, patch)
2011-12-03 18:39 UTC, Sven E.
Details | Diff
pyload-0.4.9.ebuild (pyload-0.4.9.ebuild,3.76 KB, text/plain)
2012-01-12 23:22 UTC, Sven E.
Details
files/pyload-0.4.9-sanitize-config.patch (pyload-0.4.9-sanitize-config.patch,834 bytes, text/plain)
2012-01-12 23:23 UTC, Sven E.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Reinke 2011-07-11 16:45:10 UTC
I would like to request an ebuild in the official portage tree for pyload.

pyLoad is a fast, lightweight and full featured download manager for many One-Click-Hoster, container formats like DLC, video sites or just plain http/ftp links. It aims for low hardware requirements and platform independence to be runnable on all kind of systems (desktop pc, netbook, NAS, router).
Despite its strict restriction it is packed full of features just like webinterface, captcha recognition, unrar and much more. 


http://pyload.org/:start

Reproducible: Always
Comment 1 Alejandro Ojeda 2011-07-27 16:15:55 UTC
You can find ebuild code at forums:
http://forums.gentoo.org/viewtopic-t-883233-highlight-pyload.html
Comment 2 Wilke Schwiedop 2011-09-20 11:43:46 UTC
Created attachment 287145 [details]
Ebuild for pyload-0.4.7 and -9999

The ebuild is a bit rough, working around some ugliness in the sources (like putting dependencies in the source tree - ugh) 

Things that should be fixed in the future:
- move components (core, qt-gui, webinterface) out of /opt
- maybe find a better place for pyloads workdir (currently /var/lib/pyload)
- replace shipped libraries in pyload/module/lib
- maybe adjust default configs 
- run as unprivileged user
Comment 3 Wilke Schwiedop 2011-09-20 11:44:20 UTC
Created attachment 287147 [details]
pyload init.d file
Comment 4 Wilke Schwiedop 2011-09-20 11:45:07 UTC
Created attachment 287149 [details]
pyload systemd service
Comment 5 nico 2011-09-23 16:43:58 UTC
('Filesize does not match recorded size', 1303376, 313696)
!!! Fetched file: pyload-src-v0.4.7.zip VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got: 1303376
!!! Expected: 313696
how do i fix this
Comment 6 hal 2011-09-29 01:19:58 UTC
Created attachment 288155 [details]
refactored ebuild (0.4.7 / 9999)
Comment 7 hal 2011-09-29 01:20:19 UTC
(In reply to comment #2)
> Created attachment 287145 [details]
> Ebuild for pyload-0.4.7 and -9999
> 
> The ebuild is a bit rough, working around some ugliness in the sources (like
> putting dependencies in the source tree - ugh) 
> 
> Things that should be fixed in the future:
> - move components (core, qt-gui, webinterface) out of /opt

where should those parts reside?

> - maybe find a better place for pyloads workdir (currently /var/lib/pyload)
> - run as unprivileged user

not sure if it would work. but could we create a new user to use its homedir as working directory?
it would also be useful to separate configs. after a re-emerge all settings are going to be lost.

> - replace shipped libraries in pyload/module/lib

this would be nice. but what i saw is there's nearly nothing in the official tree available.

> - maybe adjust default configs 

i'm going to post some useful defaults during the next days.


i "refactored" the ebuild a little bit. please review:
# removed linguas_en from tesseract since the flag is not in portage
# moved python checks before inherit to die early
# added description
# moved SRC_URI for zip to else condition
# added app-arch/unzip as a build and run dependency
# added app-arch/unrar as run dependency
Comment 8 hal 2011-09-30 10:51:20 UTC
I created an ebuild for ossp-js after evaluating rhino, v8, and spidermonkey for pyload's cnl feature:

https://bugs.gentoo.org/show_bug.cgi?id=385015
Comment 9 Wilke Schwiedop 2011-09-30 10:51:40 UTC
Created attachment 288357 [details]
0.4.7 with hal's changes and a check that prevents overwriting an existing config

(In reply to comment #7)
> > Things that should be fixed in the future:
> > - move components (core, qt-gui, webinterface) out of /opt
> 
> where should those parts reside?
/usr/lib/python2.7/site-packages/pyload I guess, but I haven't looked into what needs to be considered for installing it there, but just dumping the .zip there is probably wrong. :P

> > - maybe find a better place for pyloads workdir (currently /var/lib/pyload)
> > - run as unprivileged user
> 
> not sure if it would work. but could we create a new user to use its homedir as
> working directory?
> it would also be useful to separate configs. after a re-emerge all settings are
> going to be lost.
Well let's see …
- The configs could be placed under /etc so we can make use of portage's config-protect.
- userscripts and userplugins have to be +wx
- Logs should go to syslog, but that's gotta be fixed upstream.
- The other stuff, mhhh
yeah I guess /home/pyload would be good.


> i "refactored" the ebuild a little bit. please review:
> # removed linguas_en from tesseract since the flag is not in portage
> # moved python checks before inherit to die early
oops.

> # added description
> # moved SRC_URI for zip to else condition
> # added app-arch/unzip as a build and run dependency
> # added app-arch/unrar as run dependency
nice, thanks

Overall I don't see the point of stringifying everything, other than screwing with syntax hightlighting :P
Also one dependency per line is gentoo policy.
Comment 10 Wilke Schwiedop 2011-09-30 10:53:10 UTC
(In reply to comment #8)
> I created an ebuild for ossp-js after evaluating rhino, v8, and spidermonkey
> for pyload's cnl feature:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=385015

Oh neat.
Comment 11 hal 2011-09-30 12:24:56 UTC
> > > Things that should be fixed in the future:
> > > - move components (core, qt-gui, webinterface) out of /opt
> > 
> > where should those parts reside?
> >
> /usr/lib/python2.7/site-packages/pyload I guess, but I haven't looked into what
> needs to be considered for installing it there, but just dumping the .zip there
> is probably wrong. :P

Can't tell either. :/

> > > - maybe find a better place for pyloads workdir (currently /var/lib/pyload)
> > > - run as unprivileged user
> > 
> > not sure if it would work. but could we create a new user to use its homedir as
> > working directory?
> > it would also be useful to separate configs. after a re-emerge all settings are
> > going to be lost.
> >
> Well let's see …
> - The configs could be placed under /etc so we can make use of portage's
> config-protect.

+1

> - userscripts and userplugins have to be +wx

I guess these should also reside in ~/pyload/.pyload?

> - Logs should go to syslog, but that's gotta be fixed upstream.

This can be fixed by patching the default.conf. One can define the log dir by his own. This is also the place where we could pre-define some useful settings. Users will be able to override the defaults within their own conf in ~/.pyload

> - The other stuff, mhhh
> yeah I guess /home/pyload would be good.
> 

could we tell the init script to run pyload under user XYZ? like defining a $USER in conf.d. upon starting pyload with init.d the script would creeate a dir in ~/ and copy the needed files there? on the next start we would have to check if the directory already exists.

> > i "refactored" the ebuild a little bit. please review:
> > # removed linguas_en from tesseract since the flag is not in portage
> > # moved python checks before inherit to die early
> oops.
> 
> > # added description
> > # moved SRC_URI for zip to else condition
> > # added app-arch/unzip as a build and run dependency
> > # added app-arch/unrar as run dependency
> nice, thanks
> 
> Overall I don't see the point of stringifying everything, other than screwing
> with syntax hightlighting :P
> Also one dependency per line is gentoo policy.

sorry about that. i'm not a "pro" yet. :)
Comment 12 Wilke Schwiedop 2011-09-30 13:12:39 UTC
(In reply to comment #11)
> > - userscripts and userplugins have to be +wx
> 
> I guess these should also reside in ~/pyload/.pyload?

No, I was thinking /home/pyload/user{plugins,scripts}

> > - Logs should go to syslog, but that's gotta be fixed upstream.
>
> This can be fixed by patching the default.conf. One can define the log dir by
> his own. This is also the place where we could pre-define some useful settings.
> Users will be able to override the defaults within their own conf in ~/.pyload

I had a look at pyLoadCore.py:461
It defaults to console logging and optionally sets up the file-logger.
We could easily add the syslogger there.
Generally I'd say logging to syslog is preferrable to configuring logging in every program.

> > - The other stuff, mhhh
> > yeah I guess /home/pyload would be good.
> > 
> 
> could we tell the init script to run pyload under user XYZ? like defining a
> $USER in conf.d. upon starting pyload with init.d the script would creeate a
> dir in ~/ and copy the needed files there? on the next start we would have to
> check if the directory already exists.

Why?
I mean, what's wrong with pyload:pyload?
Comment 13 hal 2011-09-30 13:39:20 UTC
would you like to join #pyload on freenet? i'm around there, devs are available, too.
Comment 14 Alejandro Ojeda 2011-10-06 09:16:07 UTC
> > - The other stuff, mhhh
> > yeah I guess /home/pyload would be good.

I like more to use /lib/pyload as workdir, as does ebuild of Transmission.
Comment 15 Richard H. 2011-10-12 12:06:56 UTC
0.4.8 also seems to work BUT:

* It deletes the GUI and I don't know why. The wrapper is being made, qt4 is being set, but it simply doesn't install the gui.

* The wrapper tries to execute /opt/pyload/pyLoadCli.py -- which does not have +x rights! Shouldn't it be executed via python instead? If not, it should have +x permissions.

I am trying to fix this myself, but I am not succeeding right now...
Comment 16 Jaime Martin 2011-11-04 22:38:11 UTC
(In reply to comment #9)
> Created attachment 288357 [details]
> 0.4.7 with hal's changes and a check that prevents overwriting an existing
> config
> 

It works for me in amd64. Moreover, it lacks the /etc/init.d/pyload init script and has the same permissions issues that Richard said. A message about to run "
/opt/pyload/pyLoadCore.py -s" to configure the application should be in at the compilation end.
Comment 17 Richard H. 2011-11-04 22:41:34 UTC
(In reply to comment #16)
> (In reply to comment #9)
> > Created attachment 288357 [details]
> > 0.4.7 with hal's changes and a check that prevents overwriting an existing
> > config
> > 
> 
> It works for me in amd64. Moreover, it lacks the /etc/init.d/pyload init script
> and has the same permissions issues that Richard said. A message about to run "
> /opt/pyload/pyLoadCore.py -s" to configure the application should be in at the
> compilation end.

The init-script works - did you actually download the init-file (first attachment on this bug)? I am using it in this mode and am so happy with it that it is running on my server 24x7 now :)
Comment 18 Sven E. 2011-11-22 23:37:07 UTC
Created attachment 293449 [details]
pyload-0.4.7.ebuild

Updated ebuild with execute permissions fixed
Comment 19 Sven E. 2011-11-22 23:38:40 UTC
Created attachment 293451 [details]
pyload.init

Adopted init script, since the updated ebuild removed the py extension from the executeable files
Comment 20 Sven E. 2011-11-22 23:54:27 UTC
The current ebuild has broken deps.

pycurl (curl) is mandatory for pyLoadCore. This makes the USE flag pretty much pointless.
Comment 21 Sven E. 2011-11-23 01:09:19 UTC
Created attachment 293467 [details]
pyload.init

Updated init.d file.
Use pyload's daemonization instead of forcing it via start-stop-daemon into the background
(The latter caused problems for me, when startign the service from a terminal)
Remove the call to env, since it is not used to modify the ENV at all anyway
Comment 22 Sven E. 2011-11-23 20:44:43 UTC
Created attachment 293567 [details]
pyload-0.4.8-sanitize-config.patch

Patch pyload-0.4.8 default config to not bind to all interfaces.
Comment 23 Sven E. 2011-11-23 20:45:44 UTC
Created attachment 293569 [details]
pyload-0.4.8-pid.patch

Since pyload already uses a variable for the pidfile, which is hardcoded though,
add a command line option to set the pidfile name.
Comment 24 Sven E. 2011-11-23 20:59:02 UTC
Created attachment 293571 [details]
pyload-0.4.8.ebuild

Reworked ebuild for pyload-0.4.8
-> Executeables go into /usr/bin
-> 'module' stuff goes into python's site-packages/pyload
-> filter all sources to change 'module to pyload, so the site-package is used
-> install other files (locale i.e.) under /usr/share/pyload
-> Patch default config and add pidfile command line option for better handling via init
-> convert shebangs to python2, thus pyLoadCore can be safely called, even from the init script.
-> precompile modules, this deletes some bin only modules though, I had no luck with excluding them via -x yet.
   (precompiled modules removed during optimize run are pulled again by pyLoadCore when it is started)
-> changed license: due to bin only modules, pyload is not compatible with the GPL.
TODO:
Since I have a headless system I could not take care of fixing the gui part for the relocated
modules/locale etc.

Since pyloadcore updates itself the (system) plugins directory should be moved away from /usr which is possibly ro.

The systemwide configs should probably go to /etc someplace
Comment 25 Sven E. 2011-11-23 21:01:13 UTC
Created attachment 293573 [details]
pyload.init

Init Script that utilizes patched in pidfile command line option
Comment 26 Sven E. 2011-11-23 21:02:29 UTC
Created attachment 293575 [details]
pyload.confd

Accompanying confd file for changed init script
Comment 27 Sven E. 2011-11-23 21:18:16 UTC
Created attachment 293577 [details]
pyload.init

Since the workdir does not reside where th ebinaries are, we need
to feed the config dir to pyLoadCore - sorry for posting the wrong init script
Comment 28 Sven E. 2011-11-23 21:18:39 UTC
Created attachment 293579 [details]
pyload.confd

Add the preset configdir to the confd file
Comment 29 Sven E. 2011-11-23 23:10:15 UTC
Created attachment 293585 [details]
pyload-0.4.8-locale-fix.patch

Patch that fixes up the locale issues in pyload.
If the (local) locale is not found as expected, use
locales from /usr/share/pyload as fallback.
This way we keep the original semantics and can yet pull
locales away from the rest of the package
Comment 30 Sven E. 2011-11-23 23:11:52 UTC
Created attachment 293589 [details]
pyload-0.4.8.ebuild

Updated ebuild
-> Include new locale patch instead of using sed
-> add jinja from portage as dependency
-> use jinja from portage instead of the one packaged with pyload
Comment 31 Richard H. 2011-11-26 13:35:47 UTC
I think something went wrong with the localization in here:

richBOOK ~ # pyLoadCore -u
Traceback (most recent call last):
  File "/usr/bin/pyLoadCore", line 636, in <module>
    pyload_core = Core()
  File "/usr/bin/pyLoadCore", line 110, in __init__
    s.set_user()
  File "/usr/lib64/python2.7/site-packages/pyload/setup.py", line 341, in set_user
    translation = gettext.translation("setup", join(self.path, "locale"), languages=["en", self.config["general"]["language"]])
  File "/usr/lib64/python2.7/gettext.py", line 469, in translation
    raise IOError(ENOENT, 'No translation file found for domain', domain)
IOError: [Errno 2] No translation file found for domain: 'setup'

I cannot setup any users :(
Comment 32 Vasco Gervasi 2011-11-26 16:30:49 UTC
Hi I am using this ebuild http://pastebin.com/raw.php?i=QwQNw5jE, but at the end of the emerging it gives me a series of errors such as:

 *     *** Error compiling '/usr/lib/python3.2/site-packages/pyload/Api.py'...
 *     File "/usr/lib/python3.2/site-packages/pyload/Api.py", line 1002
 *     except Exception, e:
 *     ^
 *     SyntaxError: invalid syntax
 *     
 *     *** Error compiling '/usr/lib/python3.2/site-packages/pyload/ConfigParser.py'...
 *     File "/usr/lib/python3.2/site-packages/pyload/ConfigParser.py", line 71
 *     print "Old version of config was replaced"
 *     ^
 *     SyntaxError: invalid syntax

I think they are releated to python-3.2 that is my default choice

Thanks
Comment 33 Sven E. 2011-11-26 18:09:41 UTC
Created attachment 293871 [details]
pyload-0.4.8-locale-fix.patch

Updated locale patch.

Hope I did not miss out on any more calls
Comment 34 Sven E. 2011-11-26 18:40:10 UTC
(In reply to comment #32)
> Hi I am using this ebuild http://pastebin.com/raw.php?i=QwQNw5jE, but at the
> end of the emerging it gives me a series of errors such as:
> 
>  *     *** Error compiling '/usr/lib/python3.2/site-packages/pyload/Api.py'...
>  *     File "/usr/lib/python3.2/site-packages/pyload/Api.py", line 1002
>  *     except Exception, e:
>  *     ^
>  *     SyntaxError: invalid syntax
>  *     
>  *     *** Error compiling
> '/usr/lib/python3.2/site-packages/pyload/ConfigParser.py'...
>  *     File "/usr/lib/python3.2/site-packages/pyload/ConfigParser.py", line 71
>  *     print "Old version of config was replaced"
>  *     ^
>  *     SyntaxError: invalid syntax
> 
> I think they are releated to python-3.2 that is my default choice
> 
> Thanks

Yes, pyload seems to be python 2.x only. I don'T know all the ebuild internals. I actually had hopes that setting the preferred ABI would take care of the rest - looks like I way wrong ....
Comment 35 Sven E. 2011-11-26 18:49:39 UTC
(In reply to comment #32)
> Hi I am using this ebuild http://pastebin.com/raw.php?i=QwQNw5jE, but at the
> end of the emerging it gives me a series of errors such as:
> 
>  *     *** Error compiling '/usr/lib/python3.2/site-packages/pyload/Api.py'...
>  *     File "/usr/lib/python3.2/site-packages/pyload/Api.py", line 1002
>  *     except Exception, e:
>  *     ^
>  *     SyntaxError: invalid syntax
>  *     
>  *     *** Error compiling
> '/usr/lib/python3.2/site-packages/pyload/ConfigParser.py'...
>  *     File "/usr/lib/python3.2/site-packages/pyload/ConfigParser.py", line 71
>  *     print "Old version of config was replaced"
>  *     ^
>  *     SyntaxError: invalid syntax
> 
> I think they are releated to python-3.2 that is my default choice
> 
> Thanks

Could you maybe check something for me?

Exchange the following two lines:
	python_pkg_setup
	python_set_active_version 2
in the ebuild you used.

So that python_set_active_version is SET before the package is set up. That's at least what I dug up, when looking into this.
Comment 36 Vasco Gervasi 2011-11-27 00:56:34 UTC
Exchange the following two lines:
    python_pkg_setup
    python_set_active_version 2
in the ebuild worked.
But now I have the following error when I run "pyLoadCore -s"

Choose your Language / Wähle deine Sprache ([en], de, fr, it, es, nl, sv, ru, pl, cs, pt_BR): it
Traceback (most recent call last):
  File "/usr/bin/pyLoadCore", line 660, in <module>
    main()
  File "/usr/bin/pyLoadCore", line 649, in main
    pyload_core = Core()
  File "/usr/bin/pyLoadCore", line 115, in __init__
    s.start()
  File "/usr/lib/python2.7/site-packages/pyload/setup.py", line 47, in start
    translation = gettext.translation("setup", join(self.path, "locale"), languages=["en", lang])
  File "/usr/lib/python2.7/gettext.py", line 469, in translation
    raise IOError(ENOENT, 'No translation file found for domain', domain)
IOError: [Errno 2] No translation file found for domain: 'setup'
Comment 37 Sven E. 2011-11-27 06:31:51 UTC
(In reply to comment #36)
> Exchange the following two lines:
>     python_pkg_setup
>     python_set_active_version 2
> in the ebuild worked.
> But now I have the following error when I run "pyLoadCore -s"
> 
> Choose your Language / Wähle deine Sprache ([en], de, fr, it, es, nl, sv, ru,
> pl, cs, pt_BR): it
> Traceback (most recent call last):
>   File "/usr/bin/pyLoadCore", line 660, in <module>
>     main()
>   File "/usr/bin/pyLoadCore", line 649, in main
>     pyload_core = Core()
>   File "/usr/bin/pyLoadCore", line 115, in __init__
>     s.start()
>   File "/usr/lib/python2.7/site-packages/pyload/setup.py", line 47, in start
>     translation = gettext.translation("setup", join(self.path, "locale"),
> languages=["en", lang])
>   File "/usr/lib/python2.7/gettext.py", line 469, in translation
>     raise IOError(ENOENT, 'No translation file found for domain', domain)
> IOError: [Errno 2] No translation file found for domain: 'setup'

See: https://bugs.gentoo.org/show_bug.cgi?id=374871#c31
     https://bugs.gentoo.org/show_bug.cgi?id=374871#c33

And updated locale patch: https://bugs.gentoo.org/attachment.cgi?id=293871

For some unobvious reason the set_user() method has an additional import of the same locale ... that's why I missed it in the first patch.
Comment 38 Vasco Gervasi 2011-11-27 08:21:27 UTC
If I add "pyload-0.4.8-locale-fix.patch (5.09 KB, text/plain)" it gives me this error http://pastebin.com/raw.php?i=sFXaNMfJ. I am using pyload-9999 not 0.4.8
Comment 39 Richard H. 2011-11-27 12:18:08 UTC
Thanks the locale patch fixed the user administration.

By the way don't worry about the GUI. It seems broken upstream and I think they are going to abandon it, as they are wanting a new one:

http://forum.pyload.org/viewtopic.php?f=7&t=804
Comment 40 Sven E. 2011-11-29 22:16:51 UTC
Created attachment 294257 [details, diff]
Reworked locale patch against mercurial tip

This patch adds more gettext functionality to pyload. It was made against the current mercurial tip. I had no chance yet to test it, since I don't run the mercurial tip myself.

Additional Info for mercurial-tip users:

The pid patch is now in the repo and not needed for the mercurial tip version.
Comment 41 Jaime Martin 2011-11-30 18:57:03 UTC
(In reply to comment #30)
> Created attachment 293589 [details]
> pyload-0.4.8.ebuild
> 
> Updated ebuild
> -> Include new locale patch instead of using sed
> -> add jinja from portage as dependency
> -> use jinja from portage instead of the one packaged with pyload

It seems jinja system library detection is wrong because I get this message when I run pyLoadCore at first:


...
Your installed jinja2 version 2.6 seems too old.
You can safely continue but if the webinterface is not working,
please upgrade or deinstall it, pyLoad includes a sufficient jinja2 libary.

jinja2: missing
...
Comment 42 Sven E. 2011-11-30 19:34:07 UTC
(In reply to comment #41)
> (In reply to comment #30)
> > Created attachment 293589 [details]
> > pyload-0.4.8.ebuild
> > 
> > Updated ebuild
> > -> Include new locale patch instead of using sed
> > -> add jinja from portage as dependency
> > -> use jinja from portage instead of the one packaged with pyload
> 
> It seems jinja system library detection is wrong because I get this message
> when I run pyLoadCore at first:
> 
> 
> ...
> Your installed jinja2 version 2.6 seems too old.
> You can safely continue but if the webinterface is not working,
> please upgrade or deinstall it, pyLoad includes a sufficient jinja2 libary.
> 
> jinja2: missing
> ...

As you can see, it says you can safely continue, and as far as I checked, the webinterface is working.

Anyhow, upstream decided to check for jinja 2.5, while they consider all other versions too old (in your case your version is actually 'to new').
Comment 43 Sven E. 2011-11-30 19:36:38 UTC
Created attachment 294383 [details]
pyload-0.4.8-jinja.patch

Trivial patch that changes jinja version check from 2.5 to 2.5 and 2.6.

The systemcheck should no longer report a problem.
Comment 44 Vasco Gervasi 2011-11-30 20:15:04 UTC
I have tried "Reworked locale patch against mercurial tip (7.58 KB, patch)" but it give me error.
Comment 45 Vasco Gervasi 2011-11-30 21:04:22 UTC
It gives me this error:

* Compilation and optimization of Python modules for CPython 2.7 ...                                                   [ !! ]
 *     Compiling /usr/lib/python2.7/site-packages/pyload/setup.py ...
 *     SyntaxError: ('invalid syntax', ('/usr/lib/python2.7/site-packages/pyload/setup.py', 346, 75, '        gettext.setpaths([join(os.sep), "usr", "share", "pyload", "locale"), None])n'))

I am using pyload-9999, "pyload-0.4.8-sanitize-config.patch" and "Reworked locale patch against mercurial tip"
Comment 46 Vasco Gervasi 2011-11-30 21:30:51 UTC
Using pyload-0.4.8 and as patch
- pyload-pid.patch
- pyload-sanitize-config.patch
- pyload-0.4.8-locale-fix.patch
- pyload-jinja.patch
worked good.

Thanks
Comment 47 Sven E. 2011-12-01 10:39:37 UTC
(In reply to comment #45)
> It gives me this error:
> 
> * Compilation and optimization of Python modules for CPython 2.7 ...           
>                                        [ !! ]
>  *     Compiling /usr/lib/python2.7/site-packages/pyload/setup.py ...
>  *     SyntaxError: ('invalid syntax',
> ('/usr/lib/python2.7/site-packages/pyload/setup.py', 346, 75, '       
> gettext.setpaths([join(os.sep), "usr", "share", "pyload", "locale"), None])n'))
> 
> I am using pyload-9999, "pyload-0.4.8-sanitize-config.patch" and "Reworked
> locale patch against mercurial tip"

Thanks for your feedback, indeed there's a typo. Will fix it an recreate patch.
Comment 48 Sven E. 2011-12-01 10:41:35 UTC
Created attachment 294429 [details, diff]
Removed Syntax Error (due to typo) ....

Typo should be fixed now.
Comment 49 Vasco Gervasi 2011-12-01 19:14:17 UTC
Using this new patch "Removed Syntax Error (due to typo)" it doesn't show me any error during merging, but if I run:
# /etc/init.d/pyload start
 * Caching service dependencies ...                                                        [ ok ] * Starting PyLoad ...                                                                     [ !! ] * ERROR: pyload failed to start

and I run:
# pyLoadCore -s
Traceback (most recent call last):
  File "/usr/bin/pyLoadCore", line 28, in <module>
    import module.common.pylgettext as gettext
ImportError: No module named module.common.pylgettext
Comment 50 Vasco Gervasi 2011-12-01 19:14:49 UTC
(In reply to comment #49)
> Using this new patch "Removed Syntax Error (due to typo)" it doesn't show me
> any error during merging, but if I run:
> # /etc/init.d/pyload start
>  * Caching service dependencies ...                                            
>            [ ok ] * Starting PyLoad ...                                        
>                             [ !! ] * ERROR: pyload failed to start
> 
> and I run:
> # pyLoadCore -s
> Traceback (most recent call last):
>   File "/usr/bin/pyLoadCore", line 28, in <module>
>     import module.common.pylgettext as gettext
> ImportError: No module named module.common.pylgettext

This happens with pyload-9999
Comment 51 Sven E. 2011-12-01 22:08:55 UTC
Created attachment 294459 [details]
pyload-0.4.8.ebuild

Added additional seds to filter pyloadcore and pyloadcli to
rewrite imports for mercurial locale patch.

Won'T change anything on 0.4.8 but should fix the imports for 
the time being, until upstream finally renames module dir.
Comment 52 Vasco Gervasi 2011-12-02 06:55:40 UTC
This ebuild "pyload-0.4.8.ebuild (3.84 KB, text/plain) 2011-12-01 22:08 UTC, Sven E.", used as pyload-9999, solved problem of "/etc/init.d/pyload start" but if I run "pyLoadCore -s" I get:
Traceback (most recent call last):
  File "/usr/bin/pyLoadCore", line 665, in <module>
    main()
  File "/usr/bin/pyLoadCore", line 654, in main
    pyload_core = Core()
  File "/usr/bin/pyLoadCore", line 114, in __init__
    from pyload.setup import Setup
  File "/usr/lib/python2.7/site-packages/pyload/setup.py", line 20, in <module>
    import module.common.pylgettext as gettext
ImportError: No module named module.common.pylgettext

A question: I read on ebuild that there is use flag called "container" what does it enable?
Comment 53 Vasco Gervasi 2011-12-02 06:58:56 UTC
In this latest ebuild "2011-12-01" there is patch called "${P}-configdir.patch" but there isn't on attachment.
Comment 54 Sven E. 2011-12-02 11:32:33 UTC
(In reply to comment #52)
> This ebuild "pyload-0.4.8.ebuild (3.84 KB, text/plain) 2011-12-01 22:08 UTC,
> Sven E.", used as pyload-9999, solved problem of "/etc/init.d/pyload start" but
> if I run "pyLoadCore -s" I get:
> Traceback (most recent call last):
>   File "/usr/bin/pyLoadCore", line 665, in <module>
>     main()
>   File "/usr/bin/pyLoadCore", line 654, in main
>     pyload_core = Core()
>   File "/usr/bin/pyLoadCore", line 114, in __init__
>     from pyload.setup import Setup
>   File "/usr/lib/python2.7/site-packages/pyload/setup.py", line 20, in <module>
>     import module.common.pylgettext as gettext
> ImportError: No module named module.common.pylgettext
> 
> A question: I read on ebuild that there is use flag called "container" what
> does it enable?

My bad. Sorry for this. The problem is, that I patched a lot of stuff for 0.4.8 and keeping additional patches against mercurial ist cumbersome. 

As for your question, container adds a dependency to install pycrypto, which is needed by pyload, when you want support for DLC, RSDF and other such containers.
Comment 55 Sven E. 2011-12-02 11:34:48 UTC
Created attachment 294501 [details]
More sed'ing to catch the rest of the imports

Added another param to sed, to filter the rest of the modules. Hopefully now everything is caught.
Comment 56 Sven E. 2011-12-02 11:52:35 UTC
(In reply to comment #53)
> In this latest ebuild "2011-12-01" there is patch called "${P}-configdir.patch"
> but there isn't on attachment.

Okay, I will go into detail a little. pyload, at it's current stage, was pretty much developed as a 'portable' only application. It lacks any installation routine etc. and it's primary design goal obviously is and was, to run it somehow as a user.

That of course makes it kinda difficult, to create an apropriate system-wide installation. Version 0.4.8 is packaged and thus stable, that's why patched it, to work around the most problematic stuff and to get it to work in a system wide installation.

To prevent heaps of patches for all future versions, naturally, you'd rather push them into the dev version, so they become part of pyload in the next packaged version.

So, the configdir patch is just another patch to fix one of these design flaws, I was working on, but did not finish yet. Currently the queue of changes I'd like to see grows and some changes will probably need some discussions with upstream devs, to get them adopted.

I.E.: Since not all parts of pyload are available as source, changing the name of the package directory to something less ambiguous than 'module' needs getting upstream involved to fix the non OS parts.
Comment 57 Vasco Gervasi 2011-12-02 17:31:16 UTC
Thanks for this ebuild "More sed'ing to catch the rest of the imports", it solved all my problem.
But now I can't use my own language, if I set "it" on "pyLoadCore -s" or in "config --> general" the interface always in english.
This isn't a huge problem.

Thank you very very very much for your work
Comment 58 Sven E. 2011-12-02 18:32:21 UTC
(In reply to comment #57)
> Thanks for this ebuild "More sed'ing to catch the rest of the imports", it
> solved all my problem.
> But now I can't use my own language, if I set "it" on "pyLoadCore -s" or in
> "config --> general" the interface always in english.
> This isn't a huge problem.
> 
> Thank you very very very much for your work

Assuming you use the locale patch against the mercurial tip, I changed the language order, because the python documentation states, that the first set language takes precedence:

"If multiple files are found, later files are used as fallbacks for earlier ones."

Additionally the patch provides directory based fallback. It is difficult to tell though which 'locale' is currently loaded. Could you maybe do a first check and see, if locales were correctly installed by the ebuild into /usr/share/pyload?
And please check if the language you chose is present?

If it is present, gettext might still use the fallback (en) if no translation string is found in the locale and a null translation if no locale file is found at all.

Thanx for your feedback.
Comment 59 Wilke Schwiedop 2011-12-02 18:56:44 UTC
Hi Sven,

good job overall, but I have to point out one issue:
Since upstream has chosen spaces for indention make absolutely sure that your patches don't contain tabs. Remember, this is python.
Same goes for the ebuilds, just the other way around. It might not be as fatal as in python, but still ugly. :P

With these issues resolved I suggest to send some of these patches upstream.
Comment 60 Sven E. 2011-12-02 21:11:40 UTC
(In reply to comment #59)
> Hi Sven,
> 
> good job overall, but I have to point out one issue:
> Since upstream has chosen spaces for indention make absolutely sure that your
> patches don't contain tabs. Remember, this is python.
> Same goes for the ebuilds, just the other way around. It might not be as fatal
> as in python, but still ugly. :P
> 
> With these issues resolved I suggest to send some of these patches upstream.

Thanks for your input, I realized inbetween, that upstream chose spaces. Evenmore, referring to python.org, 4 spaces of indention is obviously considered 'good style'.

I noticed the problem, when I was looking at the diff output and indention was different.

I gotta admit though, back in the days of python 1.2/1.3 there was nothing, that was considered 'good style' *g*.


If you are interested:

https://bitbucket.org/spoob/pyload/issue/435/patch-pid-file-cmd-line

Got adopted

https://bitbucket.org/spoob/pyload/issue/436/pyload-gettext-i18n

Still waiting ...

Further changes will need some work to convince upstream, I fear.
Comment 61 Vasco Gervasi 2011-12-03 08:26:59 UTC
My language is italian. /usr/share/pyload contains:
-rw-r--r-- 1 root root  5064  2 dic 18.26 cli.pot
-rw-r--r-- 1 root root 19527  2 dic 18.26 core.pot
drwxr-xr-x 3 root root  4096 27 nov 01.53 cs
drwxr-xr-x 3 root root  4096 27 nov 01.53 de
-rw-r--r-- 1 root root 15072  2 dic 18.26 django.pot
drwxr-xr-x 3 root root  4096 27 nov 01.53 en
drwxr-xr-x 3 root root  4096 27 nov 01.53 es
drwxr-xr-x 3 root root  4096 27 nov 01.53 fi
drwxr-xr-x 3 root root  4096 27 nov 01.53 fr
-rw-r--r-- 1 root root  8857  2 dic 18.26 gui.pot
drwxr-xr-x 3 root root  4096 27 nov 01.53 it
drwxr-xr-x 3 root root  4096 27 nov 01.53 nl
drwxr-xr-x 3 root root  4096 27 nov 01.53 pl
drwxr-xr-x 3 root root  4096 27 nov 01.53 pt_BR
drwxr-xr-x 3 root root  4096 27 nov 01.53 ro
drwxr-xr-x 3 root root  4096 27 nov 01.53 ru
-rw-r--r-- 1 root root  8782  2 dic 18.26 setup.pot
drwxr-xr-x 3 root root  4096 27 nov 01.53 tr
and folder it contains:
drwxr-xr-x  2 root root 4096  2 dic 18.26 LC_MESSAGES

I am using these patch:
- pyload-0.4.8-sanitize-config.patch
- Removed Syntax Error (due to typo)

These patch give me error:
- pyload-0.4.8-pid.patch
- pyload-0.4.8-jinja.patch
Comment 62 Sven E. 2011-12-03 18:39:46 UTC
Created attachment 294627 [details, diff]
locale wrapper fixup

Since function calls are resolved during import, the untouched translation function's call to find() still called the original find() function from gettext module instead of the wrapper. Updating the reference within translation() seems to fix this problem.

I tried this with a non-english locale outside of workdir and it seems to work as expected now.
Comment 63 Michele Ciacci 2011-12-08 18:43:21 UTC
which ebuild should I use for 0.4.8?
Comment 64 Sven E. 2011-12-09 11:22:16 UTC
(In reply to comment #63)
> which ebuild should I use for 0.4.8?

https://bugs.gentoo.org/attachment.cgi?id=294501

Should be the one working for 0.4.8 ...
Comment 65 Sven E. 2011-12-09 11:27:40 UTC
FYI:

Current Mercurial TIP includes a suitable patch for locale relocation.

Thus https://bugs.gentoo.org/attachment.cgi?id=294627 is no longer needed, for most current 9999.
Comment 66 Wilke Schwiedop 2011-12-19 22:58:57 UTC
Some annotations/comments:
- tabs/spaces!
- patching should be done in the src_prepare phase
- right now you're dumping all shipped deps into pythons sitedir. Are you sure this is a good idea?
- you changed the licence to freedist, while on pyloads website it says GPL. Whats up with that?
- have you considered moving the development to a ::pyload overlay? (hosted on github or so…)
Comment 67 Sven E. 2011-12-20 13:35:13 UTC
(In reply to comment #66)
> Some annotations/comments:
> - tabs/spaces!
> - patching should be done in the src_prepare phase

Most patches will be gone for 0.49 I'll try to fix this with the version bump. Help is appreciated though :-D, (i.e. reviewing as you did and exact pointers to tabs/spaces issues)

> - right now you're dumping all shipped deps into pythons sitedir. Are you sure
> this is a good idea?

Depends, where would you put pyload's 'modules'/components? Placing them in /usr/bin is not right, obviously, /usr/share/pyload, possible, but then again tricky importing in python. Where else do components, i.e. DSOs of apps usually go? where for python apps? One way out of this might be python3 per user site-package dirs - Then again pyload does not support python3 (and there's no plan from upstream to support python3 in the near future)

> - you changed the licence to freedist, while on pyloads website it says GPL.
> Whats up with that?

The DLC Reader is distributed as part of pyload and pyload says it has integral support for the DLC format, while the corrsponding modules are not distribued as source and not available as source to the public. I am pretty sure that this is not valid with the GPL. (If the plugin was distributed solely as a thrid party component and pyload would not claim the feature to support DLC, it would be different, AFAICS, since it only dynamically loads an external component outside pyload's control). Further discussions on this are welcome, maybe the license can be adjusted to somethign more fitting?

> - have you considered moving the development to a ::pyload overlay? (hosted on
> github or so…)

No, actually I am rather trying to get things fixed with upstream for better system-wide setups etc. - that's currently my main focus ;-).
Comment 68 Wilke Schwiedop 2011-12-20 21:27:18 UTC
(In reply to comment #67)
> Depends, where would you put pyload's 'modules'/components? Placing them in
> /usr/bin is not right, obviously, /usr/share/pyload, possible, but then again
> tricky importing in python. Where else do components, i.e. DSOs of apps usually
> go? where for python apps? One way out of this might be python3 per user
> site-package dirs - Then again pyload does not support python3 (and there's no
> plan from upstream to support python3 in the near future)
> 

Well, I've considered pyload a 3rd party app and that goes to /opt
If we were to write ebuilds for pyloads dependencies sitedir of course is the right location.

> > - you changed the licence to freedist, while on pyloads website it says GPL.
> > Whats up with that?
> 
> The DLC Reader is distributed as part of pyload and pyload says it has integral
> support for the DLC format, while the corrsponding modules are not distribued
> as source and not available as source to the public. I am pretty sure that this
> is not valid with the GPL. (If the plugin was distributed solely as a thrid
> party component and pyload would not claim the feature to support DLC, it would
> be different, AFAICS, since it only dynamically loads an external component
> outside pyload's control). Further discussions on this are welcome, maybe the
> license can be adjusted to somethign more fitting?
>

Mh - ok, I have no idea. We should put a comment into the ebuild though, so the license-gurus can fiddle that out at some point.

> > - have you considered moving the development to a ::pyload overlay? (hosted on
> > github or so…)
> 
> No, actually I am rather trying to get things fixed with upstream for better
> system-wide setups etc. - that's currently my main focus ;-).

I wasn't talking about the patches, I meant the ebuild ;)
If we remove the bundled deps and replace them with proper deps (i.e. write ebuilds for them, which we'll have to do at some point) gathering all files from bugzilla will be a royal pita.
Comment 69 Weedy 2011-12-23 18:20:51 UTC
(In reply to comment #68)
> (In reply to comment #67)
> > > - have you considered moving the development to a ::pyload overlay? (hosted on
> > > github or so…)
> > 
> > No, actually I am rather trying to get things fixed with upstream for better
> > system-wide setups etc. - that's currently my main focus ;-).
> 
> I wasn't talking about the patches, I meant the ebuild ;)
> If we remove the bundled deps and replace them with proper deps (i.e. write
> ebuilds for them, which we'll have to do at some point) gathering all files
> from bugzilla will be a royal pita.

Please do this, it took almost 10mins of fiddling to get this setup when it could have been layman -a andre.
Comment 70 Wilke Schwiedop 2012-01-02 01:18:27 UTC
Ok, back from holidays.
I'll create the overlay as soon as Sven releases the ebuild for 0.4.9
Comment 71 Moritz Schlarb 2012-01-07 11:09:04 UTC
Why do you want to create an own overlay for this ebuild?

IMHO it would be better to put it into the official sunrise overlay http://www.gentoo.org/proj/en/sunrise/ or even become a proxy maintainer http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml , since Sven and Wilke seem to have done most of the work already!

Wouldn't you agree?
Comment 72 Sven E. 2012-01-12 23:22:13 UTC
Created attachment 298795 [details]
pyload-0.4.9.ebuild

Updated ebuild for v.0.4.9
Most patches are gone due to upstream changes.
Comment 73 Sven E. 2012-01-12 23:23:20 UTC
Created attachment 298797 [details]
files/pyload-0.4.9-sanitize-config.patch

Patch for securer default config.
Comment 74 Wilke Schwiedop 2012-01-13 13:18:53 UTC
Ok then…repository is up:
https://github.com/drwilly/pyload
git@github.com:drwilly/pyload.git

Sven: I fixed some minor issues (e.g. the whitespace stuff) before I uploaded everything to github. You also referenced a files/pyload.conf in the ebuild which you didn't upload here - but since you patch the default config shipped with pyload I that is the file that was intended to be used.
Comment 75 Sven E. 2012-01-13 15:19:12 UTC
(In reply to comment #74)
> Ok then…repository is up:
> https://github.com/drwilly/pyload
> git@github.com:drwilly/pyload.git
> 
> Sven: I fixed some minor issues (e.g. the whitespace stuff) before I uploaded
> everything to github. You also referenced a files/pyload.conf in the ebuild
> which you didn't upload here - but since you patch the default config shipped
> with pyload I that is the file that was intended to be used.

Hi Wilke,

thanks for your effort.

pyload usually has a default.conf which is a template to create a 'running' configuration named pyload.conf on first invocation.

The plan was to provide means of a proper system wide installation (*.conf under /etc) and rather provide a complete pyload.conf for the system service, instead of patching just the template (This way an initial configuration run as root is not necessarily required anymore). I think I forgot to remove the pyload.conf reference, since it is rather 'work in progress'.

When I have a patch in place supporting system configs under /etc, having a pyload.conf will become more reasonable -> install pyload.conf under /etc for the system service, while patching default.conf (template) to have 'saner' defaults for per user configurations, when any user wants a local installation in his/her homedir.
Comment 76 Erlend Davidson 2012-03-01 10:58:28 UTC
The QT4 GUI interface doesn't work for me.

$ pyloadgui 
/usr/bin/pyloadgui: line 10: /opt/pyload/pyLoadGui.py: No such file or directory
/usr/bin/pyloadgui: line 10: exec: /opt/pyload/pyLoadGui.py: cannot execute: No such file or directory

There are no pyload files under /opt/pyload.

This is using pyload-0.4.9.ebuild and the sanitize patch.
Comment 77 Sven E. 2012-03-01 22:48:01 UTC
(In reply to comment #76)
> The QT4 GUI interface doesn't work for me.
> 
> $ pyloadgui 
> /usr/bin/pyloadgui: line 10: /opt/pyload/pyLoadGui.py: No such file or
> directory
> /usr/bin/pyloadgui: line 10: exec: /opt/pyload/pyLoadGui.py: cannot execute:
> No such file or directory
> 
> There are no pyload files under /opt/pyload.
> 
> This is using pyload-0.4.9.ebuild and the sanitize patch.

True, this should be fixed, since the GUI was removed upstream, the USE flag should be removed from the build.
Comment 78 Richard H. 2012-03-17 14:54:37 UTC
Hi, I just installed 0.4.9. However, something is missing?

cp: Aufruf von stat für „/home/chain/portage/net-misc/pyload/files/default.conf“ nicht möglich: Datei oder Verzeichnis nicht gefunden


I can not find this default.conf in this bug report. Where should I get it from?
Comment 79 Wilke Schwiedop 2012-03-17 22:28:11 UTC
(In reply to comment #78)
> Hi, I just installed 0.4.9. However, something is missing?
> 
> cp: Aufruf von stat für
> „/home/chain/portage/net-misc/pyload/files/default.conf“ nicht möglich:
> Datei oder Verzeichnis nicht gefunden
> 
> 
> I can not find this default.conf in this bug report. Where should I get it
> from?

Try https://github.com/drwilly/pyload/blob/master/net-misc/pyload/pyload-0.4.9.ebuild
Comment 80 am1 2012-12-04 12:05:06 UTC
Okay, so what files in the above list i need to emerge pyload over portage?

I could not follow... :-/
Comment 81 am1 2012-12-05 17:09:05 UTC
Ok, it works. Please ignore Post(In reply to comment #80).

Using ebuild/files from Post(In reply to comment #79) but got some errors.

As notes a paste.org ( http://paste.org/58261 ) which shows a debug-logfile from pyload.

Any suggestion?
Comment 82 Ivan P. 2013-07-26 15:45:34 UTC
Hi all, I have successfull installed pyload 0.4.9 on my system, but unfortunately it doesn't work.

First configuration with "pyLoadCore -s" went ok, then I start the daemon and it will automatically update all plugins, downloading them into /var/lib/pyload. 

Until here, no problem.
But when I start pyload again, I've get some errors like this:
 > ERROR     Error importing xxxxxxxxxxxx: No module named module.utils

Digging into it, I have found this forum thread:
http://forums.gentoo.org/viewtopic-t-883233-postdays-0-postorder-asc-start-25.html

See the last two posts.

I finally have resolve the issue as specified by Elderon, using this command extracted from your ebuild:

> find . -name "*.py" -type f -print0 | xargs -0 \
> sed -i \
>        -e 's:from module.lib.BeautifulSoup:from BeautifulSoup:' \
>        -e 's:from module.lib \(import feedparser.*\):\1:' \
>        -e 's:from module.lib.simplejson:from simplejson:' \
>        -e 's:from module:from pyload:' \
>        -e 's:"module\(.*\)":"pyload\1":' \
>        -e 's:import module:import pyload:' \

This must be executed into /var/lib/pyload (after update) and it will fix all files and pyload work again, until the next update.

As sayed in the forum by Dr.Willy this is cause by your attempts to move pyload to /usr.

Can you please revert that changes back to default in order to make pyload update with no problem?
Comment 83 Linubie 2016-08-25 22:10:07 UTC
Source URL to https://bitbucket.org/spoob/pyload/ has changed:

pyLoad has moved to Github, please visit:

    https://github.com/pyload/pyload

for current source code.