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
You can find ebuild code at forums: http://forums.gentoo.org/viewtopic-t-883233-highlight-pyload.html
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
Created attachment 287147 [details] pyload init.d file
Created attachment 287149 [details] pyload systemd service
('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
Created attachment 288155 [details] refactored ebuild (0.4.7 / 9999)
(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
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
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.
(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.
> > > 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. :)
(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?
would you like to join #pyload on freenet? i'm around there, devs are available, too.
> > - 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.
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...
(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.
(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 :)
Created attachment 293449 [details] pyload-0.4.7.ebuild Updated ebuild with execute permissions fixed
Created attachment 293451 [details] pyload.init Adopted init script, since the updated ebuild removed the py extension from the executeable files
The current ebuild has broken deps. pycurl (curl) is mandatory for pyLoadCore. This makes the USE flag pretty much pointless.
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
Created attachment 293567 [details] pyload-0.4.8-sanitize-config.patch Patch pyload-0.4.8 default config to not bind to all interfaces.
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.
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
Created attachment 293573 [details] pyload.init Init Script that utilizes patched in pidfile command line option
Created attachment 293575 [details] pyload.confd Accompanying confd file for changed init script
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
Created attachment 293579 [details] pyload.confd Add the preset configdir to the confd file
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
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
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 :(
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
Created attachment 293871 [details] pyload-0.4.8-locale-fix.patch Updated locale patch. Hope I did not miss out on any more calls
(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 ....
(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.
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'
(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.
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
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
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.
(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 ...
(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').
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.
I have tried "Reworked locale patch against mercurial tip (7.58 KB, patch)" but it give me error.
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"
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
(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.
Created attachment 294429 [details, diff] Removed Syntax Error (due to typo) .... Typo should be fixed now.
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
(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
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.
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?
In this latest ebuild "2011-12-01" there is patch called "${P}-configdir.patch" but there isn't on attachment.
(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.
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.
(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.
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
(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.
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.
(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.
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
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.
which ebuild should I use for 0.4.8?
(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 ...
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.
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…)
(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 ;-).
(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.
(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.
Ok, back from holidays. I'll create the overlay as soon as Sven releases the ebuild for 0.4.9
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?
Created attachment 298795 [details] pyload-0.4.9.ebuild Updated ebuild for v.0.4.9 Most patches are gone due to upstream changes.
Created attachment 298797 [details] files/pyload-0.4.9-sanitize-config.patch Patch for securer default config.
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.
(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.
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.
(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.
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?
(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
Okay, so what files in the above list i need to emerge pyload over portage? I could not follow... :-/
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?
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?
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.
