Spec URL: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl.spec SRPM URL: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl-0.1.3-1.fc8.src.rpm Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID Description: Megaupload-dl helps on the painful process of downloading files hosted on the popular Megaupload site if you don't have a premium account. The process is completely automatic as the captcha is recognized using a OCR. The script (run from the command line, there is no GUI) only returns the file link; use your favorite web downloader to actually get the file.
Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1045389
Excuse me, will it include Rapidshare downloader ( http://code.google.com/p/megaupload-dl/wiki/RapidShare ) as part of upstream megaupload-dl project ?
Good: + RPMlist is silent on source rpm. + Basename of the SPEC file fit the package name. + Consistent usage fo rpm macros + %doc section is small, so no sepearte doc subpackage is require. + Tar Ball match with upstream tar ball: (md5sum: 8a03cafa72888565f48cf100150c004a) + Files sections contains no files or directories which belongs to othe packages. Bad: - Package should contains the BRs to python a python-BeautifulSoup. - Place remove the argument from the get_python_lib funcstion, so you should wrote: %{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")} - Please put %{python_sitelib}/megaupload* into the %files section, so the egg-info file may be includes into your package. - Please a 'BuildArch: noarch' on your package, because it's doesn't contains archtiecture depending contents. - Con't verfiy License tag of the package. - Not any source files of the package contains a copyright notice. - package contains no verbatin copy of the license text. (I have open a but on the upstream website. Please refer to http://code.google.com/p/megaupload-dl/issues/detail?id=2) - Rpmlint complaints on binary rpm: megaupload-dl.noarch: E: non-executable-script /usr/lib/python2.5/site-packages/megaupload_dl/lib.py 0644 megaupload-dl.noarch: W: spurious-executable-perm /usr/share/doc/megaupload-dl-0.1.3/megaupload_dl_wget.sh megaupload-dl.noarch: E: non-executable-script /usr/lib/python2.5/site-packages/megaupload_dl/megaupload_dl.py 0644
You're too quick sorry :) That wasn't final SRPM I've built in koji, but it is uploaded now. Spec URL: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl.spec SRPM URL: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl-0.1.3-1.fc8.src.rpm
OK, the local build works fine now, But you should really add a 'BuildArch: noarch' on your package, because it's doesn't contains any archtecture depending content. The complaints of rpmlint agains the binary rpm sill exist. The same issue are the licensing issues because the sources contains no copyright notive and the upstream package contains no verbatin copy of the license text. Even of the project homepage i couldN't find any hint about the licensing state of the package. for will emphasis, taht this is a very severe issue. At last: Please increase the release counter if you are releasing a new source rpm.
I have take a second look of the project homepage. On the right magin I have found the information, that the package is copyrighted on the GPLv3. This is a valid open source license for the Fedora project. But the issue of the missing copyright notices in the source files sill exist.
Jochen, - noarch package done - I tihnk rpmlint warnings can be ignored here, we don't need exec permission on these python scripts (they are called from the main script) - do you think it's an issue to have that doc script executable? - I've contacted legal team, to find out if it's ok to include this package in Fedora, as it could be in violation of DCMA
Spec URL: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl.spec SRPM URL: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl-0.1.3-2.fc8.src.rpm
(In reply to comment #2) > Excuse me, will it include Rapidshare downloader ( > http://code.google.com/p/megaupload-dl/wiki/RapidShare ) as part of upstream > megaupload-dl project ? We may package repidshare downloader later, in different package.
Upstream has notified me, that a release 0.2 is available now. But unfortunately not all complainted copyrigh related issue are fixed.
New SRPM uploaded. http://mmahut.fedorapeople.org/reviews/megaupload-dl/
Jochen, Cleared issue with legal team, we are good to go, I'll attach mail from legal later. http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl-0.2-2.fc8.src.rpm
Created attachment 328778 [details] mail from legal
It will be nice, if you can create a SRPM of release 0.2.1. On this release all source files should contains a copyright notice.
SRPM: http://mmahut.fedorapeople.org/reviews/megaupload-dl/megaupload-dl-0.2.1-1.fc8.src.rpm
Good: + Package name fit with nameing guidelines + Name of SPEC file fit with basename of package + Package has a valid open source license + Package contains verbatin copy of the license text + Consistently usage of macros + source can be downloaded via spectool + Tar ball in the package fits with upstreams (md5sum: 366849faf106f4fdfb6e1ff1f72b9e9d) * BUILDROOT will cleaned on the beginning of the %install and %clean stanza + Rpmlint is quiete on source rpm + Package contains no subpackages + Files containing in the package doesn't belongs to others + Content of %doc is small, so no separate subpackage is require + Package will be built on noarch + Local build works fine + Build on koji works fine + Local install works fine + Starting of application without argument works + Removing of the package works fine. Bad: - License tag should be CPLv3+ because the copyright notice on the source files allow the usage of later version of the GPL - Rpmlint complaints on binary rpm: megaupload-dl.noarch: W: spurious-executable-perm /usr/share/doc/megaupload-dl-0.2.1/megaupload_dl_wget.sh megaupload-dl.noarch: E: non-executable-script /usr/lib/python2.5/site-packages/megaupload_dl/lib.py 0644 megaupload-dl.noarch: E: non-executable-script /usr/lib/python2.5/site-packages/megaupload_dl/megaupload_dl.py 0644 - Files on %{_sitedir}/metagupload_dl/*.py should be executables - Files on %{_docdir} should be not executable - __init__.py file should have a shebang
(In reply to comment #17) > - Files on %{_sitedir}/metagupload_dl/*.py should be executables Why? > - __init__.py file should have a shebang Why?
Plese refer to https://fedoraproject.org/wiki/Packaging/Guidelines#Libexecdir Because the complaints files contains executable code, the files perms should set for allow executing of this files.
PIng.
Created attachment 329637 [details] blender wrapper script I have create a fixed release of the blender-wrapper script. It may be nice, if you can try out this script. If the script is ok, I will include it in the next release of the blender package.
??? There was somethin going wrong with me. Please ignore comment #21
Ping mmahut
(In reply to comment #19) > Plese refer to > > https://fedoraproject.org/wiki/Packaging/Guidelines#Libexecdir > > Because the complaints files contains executable code, the files perms should > set for allow executing of this files. These files are scripts used from the main executable script. I don't think they should be executable - nobody will never execute it separately. Looking in my site-packages directory, no files is set as executable. Also, only very few __init__.py files starts with shebang.
Marek, MegaUpload rapidly changes captchas these days, so this no longer works. And are you sure this is a build-time dependency: BuildRequires: tesseract Hint: It's not. And probably also this: BuildRequires: python-imaging
I know about the captcha, upstream is working on that, many users complains that it's not even human readable and I've bought a premium account.
"Let's wait some time." [1] doesn't sound like upstream is working on that. Seriously, are they waiting for megaupload to replace captcha with a machine-readable one? Why would they do that? [1] http://code.google.com/p/plowshare/issues/detail?id=6
(In reply to comment #27) > Why would they do that? Because they are nice people?
We will re-open this bug once upstream fix it.
Hi, I'm the developer of megaupload-dl. >> Seriously, are they waiting for megaupload to replace captcha with a >> machine-readable one? > Because they are nice people? :-D No, we (I) considered that the new captcha was sometimes even hard for a human and then they would eventually change it again (since the first 4-char captcha lasted only one week) in deference to their poor users. Time has proved me wrong, so I implemented a (somewhat clumsy) OCR in my other project, plowshare (http://code.google.com/p/plowshare/) Now, 2 things to say: - Megaupload-dl version 0.3 supports the new captcha (and the upload script works again). - Do you consider droping megaupload_dl and switching to plowshare? It has far more features... thanks!
Hello Arnau, Great! I'll try to package plowshare next week - thank you.
The Megaupload guys have heard us ;-) The new captcha is very, very easy for tesseract. Uploaded new version 0.3.1
Megaupload changed again the captcha some weeks ago (4 letters, rotated and overlapped). Both plowshare and megaupload-dl support it.
I agree in using plowshare instead, I'm using and I'm very satisfied with it.