A new ebuild for net-nntp/sabnzbd. It's a web-interface based binary newsgrabber in python, with nzb support.
Created attachment 86376 [details] Ebuild for sabnzbd-0.1.8.1
*** This bug has been marked as a duplicate of 132589 ***
The other way round...
*** Bug 132589 has been marked as a duplicate of this bug. ***
Created attachment 95475 [details] ebuild for SABnzbd-0.2.4
Created attachment 95478 [details] /etc/conf.d file for SABnzbd-0.2.4
Created attachment 95479 [details] /etc/init.d/ file for SABnzbd-0.2.4
I updated the ebuild made by Mekong to work with SABnzbd-0.2.4 This is my first ebuild, so I'm shure it's not 100% but it worked for me :-) I added some USE flags for optional parts of SABnzbd. TODO: - automaticly copy over the config file to /etc/conf.d/sabnzbd - automaticly copy over the init file to /etc/init.d/sabnzbd - give the einfo message at the end of the merge BTW. in my own portage-overlay I placed this ebuild under the net-nntp category, because it's an usenet (NNTP) binary downloaded, which has a web-based interface, but the base of it is usenet downloader, so I think it should be under net-nntp
Created attachment 108363 [details] ebuild for SABnzbd-0.2.5 Ebuild for SABnzbd-0.2.5 based on Patrick van Dissel's ebuild. Added: ====== *creates /ets/SABnzbd.conf *creates /init.d/sabnzbd *creates /conf.d/sabnzbd changed: ======= *Depends on "==dev-python/cherrypy-2.2.1" (<>2.2.1 do not work) rename "cherrypy-2.1.1.ebuild" & "files/cherrypy-2.1.1-test-gentoo.patch" to cherrypy-2.2.1.ebuild files/cherrypy-2.2.1-test-gentoo.patch and digest. * Cleaned up indenting/spaces in ebuild. TODO: ====== *Add some warning message to the pkg_postinst() placeholder to inform people to properly configure /etc/SABnzbd.conf and to change user in etc/init.d/sabnzbd. Make sure the user hasfull access to the folders configured in /etc/SABnzbd.conf!
Created attachment 108365 [details] files/sabnzbd.conf - /etc/conf.d/sabnzbd file config file for the SABnzbd daemon. CHANGES ======== *updated header *changed sabnzbd.ini to sabnzbd.conf
Created attachment 108366 [details] files/sabnzbd.init - /etc/init.d/sabnzbd file CHANGED: ========= *updated header
Should depend on bug #164232 http://bugs.gentoo.org/show_bug.cgi?id=164232 ebuild for cherrypy-2.2.1 (as required for SABnzbd-0.2.5)
Created attachment 111084 [details] Updated ebuild for sabnzbd. Updated ebuild. User and group added Directories created.
Created attachment 111087 [details, diff] Patch for the config file. Config file adjustmeted to make it work out of the box
Created attachment 111089 [details] Updated conf.d file Conf.d file updated to use right group and user.
Created attachment 111091 [details] Updated init script Init script updated to use the right group.
Created 4 attachments: https://bugs.gentoo.org/attachment.cgi?id=111084 https://bugs.gentoo.org/attachment.cgi?id=111087 https://bugs.gentoo.org/attachment.cgi?id=111089 https://bugs.gentoo.org/attachment.cgi?id=111091 Updated ebuild is bases on the ebuild supplied by Pandor. -Ebuild now works out of the box. -sabnzbd user and group are created. -/var/lib/SABnzbd created with subdirs (default download/complete/cache/etc dirs) -/var/log/SABnzbd is the default log dir. -Chmod is 775 so if you add a user to sabnzbd group the user can acces the files created by sabnzbd.
Created attachment 111094 [details] updated ebuild for sabnzbd-0.2.5 added yenc useflag. Yenc ebuild can be found here: https://bugs.gentoo.org/show_bug.cgi?id=168192
(In reply to comment #18) > Created an attachment (id=111094) [edit] > updated ebuild for sabnzbd-0.2.5 > > added yenc useflag. > Yenc ebuild can be found here: https://bugs.gentoo.org/show_bug.cgi?id=168192 > It seems like you posted the yenc ebuild, instead of the updated sabnzbd-0.2.5 ebuild. Nice work on fixing the ebuild btw. To bad it can't go into the portage three, as they won't fix the cherrypy depend... (Note that cherrypy-2.2.1 is marked stable and that it is backwards compatible with 2.1.1, so i don't see why they shouldn't include it.)
Marking this LATER; reopen once it works with something more than just one cherrypy version. Thanks.
(In reply to comment #20) > Marking this LATER; reopen once it works with something more than just one > cherrypy version. Thanks. > Is there maybe an update? Or can I get SABnzbd to work with an alternative approach? I don't mind messing around a bit, but I don't really know what will really break other (python) things.
Created attachment 161536 [details] ebuild for latest sabnzbd (0.4.2) I've built this against python2.5 and cherrypy-2.2.1-r2 (which is in portage) and offers a great deal of enhancements over previous versions.
Created attachment 161537 [details] setup.py file to go along with sabnzbd-0.4.2.ebuild (no longer provided upstream) upstream no longer provides setup.py scripts to register sabnzbd globally in python. This is a modification of the 0.2.7 setup.py script that works with the files provided in the 0.4.2 release.
Created attachment 161539 [details] config file for sabnzbd-0.4.2 with adjustments sabnzbd's src distribution no longer comes with a config file so I had to run an installed version and save it's default config. I have made some modifications for default download/cache/scan/web_templates directories.
Created attachment 161541 [details] improved init.d script that better handles shutdown sabnzbd can have a large amount of data in memory which will be lost if we depend on start-stop-service to kill processes. I added a bit in there to utilize wget or curl (and fallback to start-stop-service as a last resort) to try to stop sabnzbd properly. The implications of this method is the init.d script must now know the address and port the server is listening on, I relied ona conf.d script (soon to be attached); however, some nifty regexing of the config file could just as easily retrieve this information if stored there.
Created attachment 161544 [details] conf.d script to correspond with my updated init.d script this is the conf.d script to go with my enhanced init.d script. hostname/ip and port settings declared here will override information stored in the sabnzbd config file.
Created attachment 161812 [details] updated ebuild, has USE="ssl" with a dep on dev-python/pyopenssl SABnzbd >=0.3.0 supports connecting to SSL enabled nntp servers. This feature depends on the existance of pyopenssl at runtime (it will just disable the feature in SABnzbd if it isn't found) I updated my local ebuild and rebuilt and it pulled the new dep in and enabled SSL support.
Created attachment 161814 [details] (actual ebuild promised in comment #27) Sorry about the failed attachment above... this should work now.
version 0.4.2 is currently running like a charm on my AMD64 server. However shutting down is not working propperly but other than that it works good. Maybe we can finally get this wonderfull app into the tree.
(In reply to comment #29) > version 0.4.2 is currently running like a charm on my AMD64 server. However > shutting down is not working propperly but other than that it works good. > Maybe we can finally get this wonderfull app into the tree. Double check you can run the curl or wget command from the command line to shutdown sab, often times the program just freezes and you need to give it a kill/killall. I have this on x86, and had this using the upstream zip package (no installing, just unzip and run) before as well. This bug seriously needs to be reopened so this has a chance at the tree.
Any reason to post the ebuild and files in DOS format?
Created attachment 164169 [details] sabnzbd-0.4.2.ebuild Updated ebuild a bit with some cosmetics: * UNIX format, not DOS (lol) * celementtree is only needed for python:2.4 it seems (use EAPI=1 and slot deps) * don't quote ${A} * set ${S} correctly and don't move things around * replace ${PN}-${PV} with ${P} * fix enewuser usage * remove unneeded src_compile() * rename useflag: unrar -> rar (unzip is correct) * par2 is essential i'd say * call distutils_pkg_postinst explicitly when overriding distutils.eclass in pkg_postinst()
Created attachment 164256 [details] sabnzbd-0.4.3.ebuild Version bump 0.4.3 + cleanups * fix keepdir/fowners usage (handles $D transparently, so keepdir /var/foo is OK) * fix little typo in gentoo-setup.py * does it really need dos2unix? o.O How do I add multiple attachments?
Created attachment 164257 [details] sabnzbd-0.4.3-gentoo-setup.py
Created attachment 164258 [details] sabnzbd-0.4.3.ini
Created attachment 164263 [details] sabnzbd.init add fixed init script use -c user -g group --name SABnzbd.py - it fails otherwhise
The ebuild works for me more or less. Here are my comments: - The perms weren't set correcty on the conf file and /var/lib/sabnzbd though from the ebuild it looks like they should have been. - There is no sample /etc/conf.d/sabnzbd. E.g., SAB_HOSTNAME=localhost SAB_PORT=8080 SAB_CONFIGFILE=/etc/sabnzbd.conf SAB_USER=sabnzbd SAB_GROUP=sabnzbd - There is an error in sabnzbd-0.4.3.ini: web_dir = /usr/share/sabnzbd-0.4.333/Default should be web_dir = /usr/share/sabnzbd-0.4.3/Default - What is the purpose of sabnzbd-0.4.3-gentoo-setup.py? - When changing anything in Config / General in the web interface "web_dir" ges the path stripped off. E.g., web_dir = /usr/share/sabnzbd-0.4.3/Default becomes web_dir = Default which will cause the program to fail to (re)start because the default path is "/usr/bin/interfaces" - There is no log rotatation.
Version 0.4.4 is out. Changing the ebuild, sabnzbd-0.4.3-gentoo-setup.py, and sabnzbd-0.4.3.ini to this version works. Please disregard my comments about log file rotation. SABnzbd automatically does it (keeping 4 5M log files).
Created attachment 171728 [details] sabnzbd-0.4.5.ebuild New ebuild: * version bump * fix fowners/fperms usage (was still faulty) * create symlink /usr/share/${P} -> /usr/share/${PN}, so the example.ini doesn't have to be bumped/edited by user on every release * also the gentoo-setup.py doesn't need to be versioned
Created attachment 171729 [details] sabnzbd.ini the (version less) .ini
Created attachment 171730 [details] sabnzbd-gentoo-setup.py the (version less) gentoo-setup.py Still no idea how to add multiple attachments in one go. Sorry.
I still don't understand what gentoo-setup.py is for. :)
(In reply to comment #42) > I still don't understand what gentoo-setup.py is for. :) > Nevermind, I see it is used in distutils_src_install in src_install().
SABnzbd 0.4.6 Final is released http://forums.sabnzbd.org/index.php?topic=1531.0
0.4.8 is out .. why was this closed to start with?
I was wondering that as well. I've tried to emerge the latest ebuild, but couldn't get around a problem with the cheetah module that could not be found (and was too busy to log a bug for it).
Renaming the ebuild to 0.4.8 and updating worked for me. (Incidentally, the same trick worked for 0.4.6 too.)
Renaming to 0.4.11 works also. Maybe reviewing some dependencies would make sense so this can finally be added to the portage tree :)
I reworked a little this ebuild and added it to my overlay: http://hg.cryptelium.net/hg/system/gentoo/overlay/ http://hg.cryptelium.net/hg/system/gentoo/overlay/file/tip/net-nntp/sabnzbd Works were : * add default credentials to secure the installation * make it listen on 0.0.0.0 ( all interfaces ) * make it stop correctly * set a default API key
I bumped to 0.5.0beta5 ! You can add my overlay with: layman -L -o http://hg.cryptelium.net/hg/system/gentoo/overlay/raw-file/tip/layman.xml layman -a cryptelium
Oh i forgot to say that this is yet again "repackaged" to be more "sabnzbd friendly" and so easy maintenable on updates. You ll need to add "admin_dir" which is new in 0.5 to your configuration file
I made also some posts upstream: http://forums.sabnzbd.org/index.php?topic=3255.0
updated to b6.
bumped to 0.5.0_rc3 on my overlay
*** Bug 237869 has been marked as a duplicate of this bug. ***
Reopening. Let's see if we can get this into shape for inclusion in portage now.
Yesterday i succesfully compiled sabnzbd using the sabnzbd-0.5.0_rc6 and cherrypy-3.2.0_rc1 ebuilds. Sabnzbd runs perfect, the only problem is that Nzb uploads using "Add NZB" doesn't work. It probably has something to do with the apache proxy i use to connect to sabnzbd trough port 80. Tnx Kiorky for the ebuilds
I just copied over the rc6 file to sabnzbd-0.5.0.ebuild and it emerged just fine. I had some trouble because I hadn't set up the admin_dir, but that's fixed now. And I also can't add files through the web interface, it is not apache related.
I am on my way to commit 0.5.0 to my overlay (no changes). For the nzb part, i hadnt tested that because i mount the 'dirscan' directory with for example sshfs and drop my nzbs there. I can search but i have no ETA, i'm quite busy nowodays.
Hello all, First of all, I have recently installed sabnzbd through the cryptelium overlay. It's working fine, except for two things. So, I can confirm that nzb uploads using either the "Add Nzb" button or the dirscan folder do not work at all. While I am able to select the nzb, it does not upload and no error message is given in the log. However, adding an nzb through an URL works completely well. Also, my dirscan folder is a regular folder and I am not using any proxy to access sabnzbd. Hope everything gets sorted out. Thanks.
Dirscan works fine here. Only the nzb uploading gives problems. I may try to downgrade python to 2.5. But sometimes i receive a cherrypy error, so maybe it has something to do with cherrypy.
I'm clearly over staffed to see what's going on but i'm sure it's on sabnzbd/cherrypy fault. As it's mostly python code, just do some pdb debugging with the server in foreground (launched manually) would let show us where the problem is.
(In reply to comment #62) > I'm clearly over staffed to see what's going on but i'm sure it's on > sabnzbd/cherrypy fault. > As it's mostly python code, just do some pdb debugging with the server in > foreground (launched manually) would let show us where the problem is. > Hi, some time has passed since the last time. I haven't managed to debug that portion of the sabnzbd source code. Not an expert in python, yet! However, recently, I noticed at its homepage, there's a new version available (0.5.2), which although doesn't seem to include this bug in its bugfixes, seems to be able to add manually an nzb file to the queue. Have tried one and successfully downloaded it. One thing I noticed is that at least this version seems to use an embedded cherrypy module. In fact, in the section 3 of the INSTALL file, it includes the following line: "Embedded modules (only use the included version) CherryPy-3.2 rev2138 with patches http://www.cherrypy.org".
Just in case it wasn't clear in the previous comment, the sabnzbd installation I was referring to was a clean one from the package taken from the official site. Now, I intend to say that, I managed to get the manual addition of a nzb file to the queue working, by copying the embedded cherrypy module (folder), in the previous installation, to the installation done through the cryptelium overlay, after unmerging the portage cherrypy package.
As I'm retiring, I won't be taking this on after all.
I used dev-python/yenc and dev-python/cherrypy from the overlay, and bumped the sabnzbd ebuild to 0.5.4 successfully. Hope to see this in portage soon, hellanzb is broken these days and has gone unmaintained for some time it seems. This is a great replacement.
Created attachment 246967 [details] cherrypy-3.2.0_rc1.ebuild
Created attachment 246968 [details] yenc-0.3.ebuild
Created attachment 246970 [details] Files for sabnzbd
Created attachment 246972 [details] Files for sabnzbd
Created attachment 246974 [details] Files for sabnzbd
Created attachment 246976 [details] Files for sabnzbd
Created attachment 246978 [details] Files for sabnzbd
Created attachment 246979 [details] Sabnzbd ebuild
I did not write this ebuild, I just added it for convenience. You can find the original ebuild including overlay here: http://forums.sabnzbd.org/index.php?topic=3255.0
Created attachment 247310 [details] Bumped to 5.4
thanks for the ebuilds! tested on Linux-2.6.35-gentoo-r9-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_6000+-with-gentoo-2.0.1 works great without any problems.
Aniruddha, please read the bug, and the forum, kiorky on the forum, is also, me, kiroky here. don't dup the files as i ve lost time to check if there as any change.
FOR ALL, PLEASE USE THE OVERLAY FILES AND NOT THE BUGS ONES WHICH ARE OLDER THAN 2010-10
bumped to 0.5.6 on my overlay
Just an FYI, I will be looking into adopting this package in the near future. More news to follow.
Looking forward to it :) (In reply to comment #81) > Just an FYI, I will be looking into adopting this package in the near future. > More news to follow.
*** Bug 359795 has been marked as a duplicate of this bug. ***
Created attachment 266817 [details] sabnzbd-0.6.0 beta2 modified the ebuild a bit to work with sabnzbd 0.6.0 beta 2.
Thanks for the work it's working perfectly after adding Kirok's overlay ! (In reply to comment #84) > Created attachment 266817 [details] > sabnzbd-0.6.0 beta2 > > modified the ebuild a bit to work with sabnzbd 0.6.0 beta 2.
Created attachment 272339 [details] Ebuild for SABnzbd-0.6.0
Created attachment 272341 [details] /etc/conf.d/sabnzbd
Created attachment 272343 [details] pre-configured sabnzbd.ini for startup
Created attachment 272345 [details] /etc/init.d/sabnzbd
I've uploaded a fresh ebuild for version 0.6.0, which was released on May 04 2011. Hot off the presses! I based my ebuild off the version in kiorky's overlay, but I've made a lot of significant changes to the ebuild and file layout. The SABnzbd daemon now runs by default as an unprivileged 'sabnzbd' user, and it has its own little areas to play in, namely /var/log/sabnzbd, /var/lib/sabnzbd and /etc/sabnzbd. All files are owned by root:sabnzbd after install, and inaccessible to everyone else. The previous method of shutdown was unreliable when I tested it, and the startup script displayed as 'crashed' in openRC/baselayout-2, so I've replaced the startup and shutdown scripts to work with start-stop-daemon correctly. SABnzbd has no option to create a PID file as of 0.6.0, but the developer has agreed to implement that feature for 0.6.1 - see http://forums.sabnzbd.org/index.php?topic=575.0 for my feature request on their forums. When 0.6.1 is released, I'll revise the ebuild to use that feature. In the meantime, I get the PID with some shell scripting and eliminate the need to pass API keys around, use curl/wget or do anything odd. With proper PID creation, running multiple instances of SABnzbd should be possible. I only need one, so I've only tested it this way.
Created attachment 272583 [details] sabnzbd-0.6.0 ebuild including config, init.d script This is the ebuild I use to install sabnzbd on my system using baselayout-2.
SABnzbd 0.6.1 has been released, and I've attached the revised ebuild and init.d script to use the new PID feature.
Created attachment 273731 [details] Ebuild for SABnzbd-0.6.1
Created attachment 273733 [details] /etc/init.d/sabnzbd
Created attachment 273735 [details] /etc/conf.d/sabnzbd
awesome! thanks for new ebuilds and configurations. all previous problems that i had with downloading nzbs from different nzb search engines and from local nzb files are gone! only thing i needed to do manually is to create the directory /var/run/sabnzbd and to chown it to sabnzbd user.
(In reply to comment #96) > awesome! thanks for new ebuilds and configurations. all previous problems that > i had with downloading nzbs from different nzb search engines and from local > nzb files are gone! > > only thing i needed to do manually is to create the directory /var/run/sabnzbd > and to chown it to sabnzbd user. I overlooked that, thank you for pointing it out. The ebuild should have created the /var/run/sabnzbd directory (I had created it myself, and forgot that it wasn't portage-owned).
Created attachment 274375 [details] sabnzbd-0.6.1.ebuild
Comment on attachment 274375 [details] sabnzbd-0.6.1.ebuild This revision includes a section for creating the /var/run/sabnzbd directory.
Hi Matthew, nicely done ebuild, thx! I had 1 or 2 head-scratchers when setting up and will share my experience here if you don't mind: - there is one more dependency to be fullfilled: pysqlite (sabnzbd init was not starting and no error reported) - if you want to have password-less access, make sure you enter sth in the "api_key" variable and restart sabnzbd, otherwise you won't be able to save anything in the gui -> "error session key incorrect" - there is a little bit of fun of importing 3-rd party ebuild but that's I guess up to your own gentoo-skills :-) Hope it helps, waiting for 0.6.2 now :-) Rgds,Bogdan
Reiterating comment #33, does it really need dos2unix? I see in discussion at http://forums.gentoo.org/viewtopic-p-5234068.html that it used to be needed, but a grep through the code now doesn't turn up any usage. If I'm missing something and it really does need it, I suggest this dep: || ( app-text/dos2unix | app-text/hd2u ) hd2u is a drop-in replacement for dos2unix (which I happen to have installed and blocks dos2unix, forcing me to jump through hoops). :)
Also, you shouldn't dep on the pysqlite package, because it's already included in python-2.7 (which is stable). A better dep (ripped from the django ebuild) is: || ( dev-lang/python:2.7[sqlite] dev-lang/python:2.6[sqlite] dev-lang/python:2.5[sqlite] dev-python/pysqlite:2 )
Created attachment 290557 [details] SABnzbd 0.6.10 ebuild The previous ebuild I uploaded (0.6.1) could be simply renamed for all versions up to 0.6.9, but the recent version (0.6.10) broke because the SAB team including a new python module (gntp). This ebuild includes the gntp modules.
installed the recent ebuild with version 0.6.10 on my fresh installed machine. used the yenc ebuild from c1pher overlay. for some reason it simply hangs in the wizard, when clicking to test the server details. i've also tried the overlay version from c1pher with the same result. the only message i get in the logs, is: "WARNING::[interface:166] Missing Session key" my account is fine, since it works nicely on ubuntu vm just installed for testing. are there any extra dependencies i have to install?
(In reply to comment #104) > installed the recent ebuild with version 0.6.10 on my fresh installed machine. > used the yenc ebuild from c1pher overlay. for some reason it simply hangs in > the wizard, when clicking to test the server details. i've also tried the > overlay version from c1pher with the same result. > > the only message i get in the logs, is: "WARNING::[interface:166] Missing > Session key" > > my account is fine, since it works nicely on ubuntu vm just installed for > testing. > > are there any extra dependencies i have to install? Check out comment #100 where a poster talks about adding an api_key to the blank sabnzbd.ini
its not complaining about the api key, which i've added after you've pointed me to the comment above. it still complains about a missing "SESSION KEY" and does nothing on page one while testing the connection. i don't think its browser related, since i've tried 2 different browsers (ff, chrome) with no blocking addons / features turned on.
(In reply to comment #106) > its not complaining about the api key, which i've added after you've pointed me > to the comment above. it still complains about a missing "SESSION KEY" and does > nothing on page one while testing the connection. * in your configuration file, please set your api key to "abcd". * browse to [1] to generate a new api key. See [2] or [3] for explanations. [1] http://localhost:8080/api?mode=config&name=set_apikey&apikey=abcd [2] http://forums.sabnzbd.org/viewtopic.php?p=57375#p57375 [3] http://forums.sabnzbd.org/viewtopic.php?t=1960
(In reply to comment #107) > (In reply to comment #106) > > its not complaining about the api key, which i've added after you've pointed me > > to the comment above. it still complains about a missing "SESSION KEY" and does > > nothing on page one while testing the connection. > > * in your configuration file, please set your api key to "abcd". > * browse to [1] to generate a new api key. > > See [2] or [3] for explanations. > > [1] http://localhost:8080/api?mode=config&name=set_apikey&apikey=abcd > [2] http://forums.sabnzbd.org/viewtopic.php?p=57375#p57375 > [3] http://forums.sabnzbd.org/viewtopic.php?t=1960 thanks allot! for some reason, i didn't get the connection to those postings in forum when searching them or google. it works now! this localhost link did it! :)
Hi: latest ebuild errors. It seems an ini file is expected to be in the sabnzbd tar, but none exists: '/var/tmp/portage/net-nntp/sabnzbd-0.6.10/temp/build.log' * Messages for package net-nntp/sabnzbd-0.6.10: * ERROR: net-nntp/sabnzbd-0.6.10 failed (install phase): * copying sample sabnzbd.ini * * Call stack: * ebuild.sh, line 56: Called src_install * environment, line 4800: Called die * The specific snippet of code: * cp "${FILESDIR}/${PN}.ini" "${S}" || die "copying sample ${PN}.ini"; * * If you need support, post the output of 'emerge --info =net-nntp/sabnzbd-0.6.10', * the complete build log and the output of 'emerge -pqv =net-nntp/sabnzbd-0.6.10'. * This ebuild is from an overlay named 'user_defined': '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/net-nntp/sabnzbd-0.6.10/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-nntp/sabnzbd-0.6.10/temp/environment'. * S: '/var/tmp/portage/net-nntp/sabnzbd-0.6.10/work/SABnzbd-0.6.10'
(In reply to comment #109) > Hi: latest ebuild errors. It seems an ini file is expected to be > in the sabnzbd tar, but none exists: No : - ini file is at comment #88 (sabnzbd.ini) - init.d file is at comment #94 (sabnzbd.init) - conf.d file is at comment #95 (sabnzbd.conf) All these files goes to $FILESDIR : > $ ls -l net-nntp/sabnzbd/files/ > total 12 > -rw-r--r-- 1 root root 723 15 nov. 19:18 sabnzbd.conf > -rw-r--r-- 1 root root 2415 15 nov. 19:18 sabnzbd.ini > -rw-r--r-- 1 root root 509 15 nov. 19:18 sabnzbd.init
(In reply to comment #110) > (In reply to comment #109) > > Hi: latest ebuild errors. It seems an ini file is expected to be > > in the sabnzbd tar, but none exists: > > No : > - ini file is at comment #88 (sabnzbd.ini) > - init.d file is at comment #94 (sabnzbd.init) > - conf.d file is at comment #95 (sabnzbd.conf) > > All these files goes to $FILESDIR : > > > $ ls -l net-nntp/sabnzbd/files/ > > total 12 > > -rw-r--r-- 1 root root 723 15 nov. 19:18 sabnzbd.conf > > -rw-r--r-- 1 root root 2415 15 nov. 19:18 sabnzbd.ini > > -rw-r--r-- 1 root root 509 15 nov. 19:18 sabnzbd.init Success! Thank you
Created attachment 295443 [details] fixed SABnzbd 0.6.10 ebuild Tried this out today (the 2011-10-22 SABnzbd 0.6.10 ebuild). It's missing a dependency on >=dev-python/pysqlite-2 (the init script would just fail otherwise) Example output after install: # python /usr/share/sabnzbd/SABnzbd.py Sorry, requires Python module sqlite3 Try: apt-get install python-pysqlite2 Attaching the modified ebuild.
(In reply to comment #112) > Created attachment 295443 [details] > fixed SABnzbd 0.6.10 ebuild > > Tried this out today (the 2011-10-22 SABnzbd 0.6.10 ebuild). It's missing a > dependency on >=dev-python/pysqlite-2 (the init script would just fail > otherwise) > > Example output after install: > # python /usr/share/sabnzbd/SABnzbd.py > Sorry, requires Python module sqlite3 > Try: apt-get install python-pysqlite2 > > Attaching the modified ebuild. This is interesting. I don't have pysqlite installed on my system and I have no issues running SABnzbd. I ran it directly on the command line and got a nice startup wizard via HTTP.
(In reply to comment #113) > > This is interesting. I don't have pysqlite installed on my system and I have > no issues running SABnzbd. I ran it directly on the command line and got a > nice startup wizard via HTTP. Same thing. You should read comment #102.
Created attachment 295445 [details] fixed python dep I've updated my SABnzbd 0.6.10 ebuild to install directly into /usr/share/sabnzbd instead of creating a symlink. The previous versions were being abandoned in /usr/share, which built up cruft. Also, I updated the python dependency to require >=2.5 with the sqlite USE flag per http://www.gentoo.org/proj/en/Python/developersguide.xml
Created attachment 295447 [details] sabnzbd-0.6.14.ebuild Version bump for 0.6.14
I installed sabnzbd-0.6.14 yesterday via a local overlay on amd64. It went "nearly" perfect, i just had to: a) recompile python with sqlite useflag by hand b) manually emerge pysqlite (it wouldn't start without it) c) set the api-key in sabnzbd.ini, without it the "webinterface" wouldn't run properly (error session key incorrect)
It seems to work, just the init appears to be borked. After starting it, this is what happens (it keeps running and working though) /etc/init.d/sabnzbd start * Use of the opts variable is deprecated and will be * removed in the future. * Please use extra_commands or extra_started_commands. * Starting SABnzbd ... [ ok ] # /etc/init.d/sabnzbd status * Use of the opts variable is deprecated and will be * removed in the future. * Please use extra_commands or extra_started_commands. * status: crashed pid has disappeared aswell. init will fail to start after this. # ps aux | grep /var/run/sabnzb sabnzbd 23718 0.3 0.5 209424 18272 ? Sl 19:49 0:00 /usr/bin/python2.7 SABnzbd.py -d -f /etc/sabnzbd/sabnzbd.ini --pid /var/run/sabnzbd/ when I manually kill it i can start the init script again.
Created attachment 305361 [details] sabnzbd-0.6.15.ebuild Version bump Variables “PYTHON_” moved before inherit (mandatory) and add funtions calls
Created attachment 305363 [details] sabnzbd.init Remove deprecated variables opts
Created attachment 305365 [details] sabnzbd.conf Change $SAB_PORT to 8080 (default with the ebuild so…) and add a comment for SSL connexion (because pid file is “/var/run/sabnzbd/sabnzbd-9090.pid”, so $SAB_PORT must be “9090” too). I just remember that i forgot ewarn and einfo on the ebuild. I will change them after.
Created attachment 305367 [details] sabnzbd.ini Rename “api_key” to “apikey” (otherwise, there is an infinite loop. See: http://forums.sabnzbd.org/viewtopic.php?p=57375#p57375)
Created attachment 305371 [details] sabnzbd-0.6.15.ebuild Updates of ewarn and einfo
sabnzbd fails to start if python3 is your default python.
Created attachment 311453 [details] sabnzbd.init http://wiki.sabnzbd.org/faq#toc4(In reply to comment #124) > sabnzbd fails to start if python3 is your default python. SABnzbd does not work with Python 3: http://wiki.sabnzbd.org/faq#toc4 If you have “PYTHON_DEPEND="2:2.5"” on your ebuild, it will be enough to pull the correct SLOT. With this update init, it should work for everyone. I just change “python” by “python2”.
Now in Sunrise: Reviewed: http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=tree;f=net-nntp/sabnzbd (until review: http://overlays.gentoo.org/proj/sunrise/browser/net-nntp/sabnzbd)
Version bump 0.7.0. Changed: http://wiki.sabnzbd.org/introducing-0-7-0
just renaming the sabnzbd-0.6.15.ebuild to -0.7.0.ebuild works for me. (version 0.7.0 was released and it pretty awesome).
I've also renamed to 0.7 and have run this on both x86 and ppc
Created attachment 317236 [details] Sabnzbd 0.7.0 ebuild
Created attachment 317494 [details] sabnzbd-0.7.1.ebuild Version bump: -------------------- Fixed problem were fetching par2 files after first verification could stall in the queue Fixed retry behaviour of NZB fetching from URL (with handling of nzbsrus.com error codes) Verification/repair would not be executed properly when one more RAR files missed their first article. Improved backup of sabnzbd.ini file, now uses backup when original is gone or corrupt Several translations extended/improved Plush skin: fix problems with pull-down menus in Mobile Safari On some Linux and OSX systems using localhost would still make SABnzbd give access to other computers Windows: the installer did not set an icon when associating NZB files with SABnzbd Fix problem that the Opera browser had with Config->Servers Retry a few times when accessing a mounted drive to create the final destination folder Minor fixes in Window Tray icon and OSX top menu Add no_ipv6 special for systems that keep having issues with [::1] Fix crash in QuickCheck when expected par2 file wasn't downloaded API calls "addurl" and "addid" (newzbin) can now be used interchangeably Fix endless par2-fetch loop after retrying failed job Don't send "bad fetch" email when emailing is off Add some support for nzbrus.com's non-VIP limiting Fix signing of OSX DMG -------------------- I just update sunrise.
(In reply to comment #131) > Created attachment 317494 [details] > sabnzbd-0.7.1.ebuild I installed it successfully on stable amd64. Two small things : > # cd /var/lib/sabnzbd/config/ > # ls -l > -rwxrwx--- 1 root sabnzbd 5119 18 juil. 09:23 sabnzbd.ini AFAIK, the ini file does not need to be executable. In the ini file, the log_level parameter is set by default to 2 (DEBUG). The log file grows up for nothing. You should decrease it to 1 (INFO). Thanks.
Sure. I will try to change this with 0.7.2 (just released today).
Created attachment 318768 [details] sabnzbd-0.7.2.ebuild Version bump and improvement for permissions (with new installs). You want to upgrade SABnzbd and update your permissions (optional): find /usr/share/sabnzbd/ -type f -exec chmod -x "{}" \; find /var/lib/sabnzbd/ -type f -exec chmod -x "{}" \;
Created attachment 318772 [details] sabnzbd.ini Update for log level (same thing, it will be ok with new installs). If you want to avoid etc-update after upgrade the package: On GUI, go to “Status” and use the select box to define the log level.
(In reply to comment #134) > Created attachment 318768 [details] > sabnzbd-0.7.2.ebuild > > Version bump and improvement for permissions (with new installs). I think there's some permission problems in /usr/share/sabnzbd : > # ls -l /usr/share/sabnzbd/ > -rw-r----- 1 root sabnzbd 64799 21 juil. 10:04 SABnzbd.py > -rw-r--r-- 1 root root 46893 21 juil. 10:04 SABnzbd.pyc > -rw-r--r-- 1 root root 46893 21 juil. 10:04 SABnzbd.pyo > drwxrwx--- 5 root sabnzbd 4096 21 juil. 10:04 cherrypy > drwxrwx--- 2 root sabnzbd 4096 21 juil. 10:04 email > drwxrwx--- 2 root sabnzbd 4096 21 juil. 10:04 gntp > drwxrwx--- 8 root sabnzbd 4096 21 juil. 10:04 interfaces > drwxrwx--- 12 root sabnzbd 4096 21 juil. 10:04 locale > drwxrwx--- 5 root sabnzbd 4096 21 juil. 10:04 po > drwxrwx--- 3 root sabnzbd 4096 21 juil. 10:04 sabnzbd > drwxrwx--- 2 root sabnzbd 4096 21 juil. 10:04 tools > drwxrwx--- 2 root sabnzbd 4096 21 juil. 10:04 util Directories should not be group-writable. You should use diropts : > # Add themes & code into /usr/share > insinto /usr/share/${PN} > insopts -m0640 -o root -g ${PN} >+ diropts -m0750 -o root -g ${PN} > doins -r cherrypy email gntp interfaces locale po sabnzbd SABnzbd.py tools util Also, may I ask where do you commit your changes ? I don't see any new commits on sunrise overlay [1] since weeks ? Thanks. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=summary
another way would be to handle permissions afterwards at the end of src_install phase and do something like cd "${D}" find . -type d -exec fperms -R 770 '{}' \; find . -type f -exec fperms -R 660 '{}' \; etc... Please clean up the attachments or tell me which we should keep, this looks like a mess. Also: don't update ebuilds on the bugtracker if you are updating them in an overlay. Usually you only attach the first ebuild. People should use the overlay from then on.
better to use the find-calls in a loop so you don't randomly change permissions on dirs like /usr/share
(In reply to comment #136) > Directories should not be group-writable. You are right. 0.7.3 should come quikly. I will wait it. > Also, may I ask where do you commit your changes ? I don't see any new > commits on sunrise overlay [1] since weeks ? Thanks. > > [1] > http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=summary This is the “reviewed” tree. I commit on another tree. A Gentoo dev takes the ebuild and commit it on the “reviewed” tree. This can take some time (days or weeks). (In reply to comment #137) > Please clean up the attachments or tell me which we should keep, this looks > like a mess. Also: don't update ebuilds on the bugtracker if you are > updating them in an overlay. Usually you only attach the first ebuild. Every attachment prior to 305365 (sabnzbd.conf at 14th march 2012) should be mark obsolete. I can not do that. You are welcome to do it. “Sabnzbd 0.7.0 ebuild” by Russell York can not be used (patch is missing). > People should use the overlay from then on. They should. I do not. I use some ebuilds on my local tree which I pick up on different places. I am a bad example ;) (In reply to comment #137) > another way would be to handle permissions afterwards at the end of > src_install phase and do something like > > cd "${D}" > find . -type d -exec fperms -R 770 '{}' \; > find . -type f -exec fperms -R 660 '{}' \; (In reply to comment #138) > better to use the find-calls in a loop so you don't randomly change > permissions on dirs like /usr/share Is it fine to modify perms on /usr/share/***? Or should I let them by default (probably 644)? I try to use insopts/diropts options. Except that there is different umasks here. So we should make: find SOME_PLACES_A -type f -exec fperms -R 660 '{}' \; find SOME_PLACES_A -type d -exec fperms -R 770 '{}' \; find SOME_PLACES_B -type f -exec fperms -R 640 '{}' \; find SOME_PLACES_B -type d -exec fperms -R 750 '{}' \; + fowners root:sabnzbd on SOME_PLACES_A and SOME_PLACES_B. (There is one repository for each fperms so: just “fperms etc.”) It is almost the same. I should take care of different cases. I should probably install folder with default mask first (logrotate and perhaps /usr/share/sabnzbd). And use ***opts at the end with non standard mod to avoid errors like this.
I use a group other than "sabnzbd" for my sabnzbd user so the permissions for the diropts and insopts in src_install are awkward for me. For installing the ini file, which contains passwords, I'd make it owned by sabnzbd with perms 0600 and for the other files there should be no harm in making them user and group root and perms 0644. Is there a reason why the ini file is in /var/lib/sabnzbd/config/ rather than /etc/sabnzbd/ in which case a CONFIG_PROTECT wouldn't be needed? Otherwise, isn't there a way to automatically add to CONFIG_PROTECT? Thanks for keeping the ebuild up to date.
Created attachment 319228 [details] sabnzbd.ini
(In reply to comment #140) > Is there a reason why the ini file is in /var/lib/sabnzbd/config/ rather > than /etc/sabnzbd/ in which case a CONFIG_PROTECT wouldn't be needed? > Otherwise, isn't there a way to automatically add to CONFIG_PROTECT? I agree that ideally it would be in /etc. Some raise the counter-argument in cases like this one that sabnzbd.ini is usually writable by the app, so should be kept out of /etc. I don't really buy that since A. it's completely arbitrary; and B. there are plenty of precedents of this already being done by widely-accepted apps (e.g. CUPS does it). That said, if it's decided that it should be kept in /var/lib/sabnzbd, then all that's necessary to add it to config protect is to add to the src_install something: echo "CONFIG_PROTECT=\"${DHOMEDIR}/config\"" > "${T}"/50sabnzbd || die doenvd "${T}"/50sabnzbd || die
Hi! When i try to upgrade to sabnzbd-0.7.2 from sabnzbd-0.6.15 i get this error message: !!! newins: ***/net-nntp/sabnzbd/files/sabnzbd.logrotate does not exist Where do i find sabnzbd.logrotate?
use the sunrise overlay or download it manually from http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=tree;f=net-nntp/sabnzbd/files;hb=HEAD
Created attachment 319336 [details] sabnzbd.logrotate I add sabnzbd.logrotate. Attached files will not be update anymore on bugtracker by me. As hasufell says, users have to use overlay. There is two different ways: use layman: http://overlays.gentoo.org/proj/sunrise/wiki (general doc http://www.gentoo.org/proj/en/overlays/userguide.xml) download files manually: http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=tree;f=net-nntp/sabnzbd;hb=HEAD (In reply to comment #140) > I use a group other than "sabnzbd" for my sabnzbd user so the permissions > for the diropts and insopts in src_install are awkward for me. > > For installing the ini file, which contains passwords, I'd make it owned by > sabnzbd with perms 0600 and for the other files there should be no harm in > making them user and group root and perms 0644. Hmm. Your problem is with /usr/share/sabnzbd, is not it? Perms of /var/lib/sabnzbd are identical between 0.7.2 and 0.6.15 (on Sunrise's version). -rw------- 1 sabnzbd sabnzbd 3802 26 juil. 21:37 sabnzbd.ini => I do not change anything (I think). Before, there is: fowners -R root:${PN} "${DHOMEDIR}" fperms -R 770 "${DHOMEDIR}" Your perms probably come from this. (In reply to comment #142) > (In reply to comment #140) > > Is there a reason why the ini file is in /var/lib/sabnzbd/config/ rather > > than /etc/sabnzbd/ in which case a CONFIG_PROTECT wouldn't be needed? > > Otherwise, isn't there a way to automatically add to CONFIG_PROTECT? > > I agree that ideally it would be in /etc. Some raise the counter-argument in > cases like this one that sabnzbd.ini is usually writable by the app, so > should be kept out of /etc. I don't really buy that since A. it's completely > arbitrary; and B. there are plenty of precedents of this already being done > by widely-accepted apps (e.g. CUPS does it). I am agree with you. For me, daemon config files should be on /etc. But a Sunrise operator (and Gentoo dev) told me to move the file. I need his reviewed so I change this. > That said, if it's decided that it should be kept in /var/lib/sabnzbd, then > all that's necessary to add it to config protect is to add to the > src_install something: > > echo "CONFIG_PROTECT=\"${DHOMEDIR}/config\"" > "${T}"/50sabnzbd || die > doenvd "${T}"/50sabnzbd || die It sounds good. But we have to run manually “env-update” after. “qgrep env-update” finds only log. It can not add it on src_install (or anywhere except elog/ewarn).
> I am agree with you. For me, daemon config files should be on /etc. > > But a Sunrise operator (and Gentoo dev) told me to move the file. > I need his reviewed so I change this. Fair enough - maybe it's worth pointing him to the open debate here, though. Minds change. :) > > That said, if it's decided that it should be kept in /var/lib/sabnzbd, then > > all that's necessary to add it to config protect is to add to the > > src_install something: > > > > echo "CONFIG_PROTECT=\"${DHOMEDIR}/config\"" > "${T}"/50sabnzbd || die > > doenvd "${T}"/50sabnzbd || die > > It sounds good. But we have to run manually “env-update” after. > > “qgrep env-update” finds only log. It can not add it on src_install (or > anywhere except elog/ewarn). You don't need to run env-update. Portage does that automatically. See "man env-update" for confirmation. Something just like the above is already done in plenty of ebuilds. Try: qgrep -e 'echo .CONFIG_PROTECT=' You'll see lots of examples (some of which fail to use "doenvd" like they're supposed to, but that's beside the point).
I'm back as Gentoo dev, and I think it is high time we get this package into the portage tree. I am willing to commit this and related packages, but would like to get some help from you guys with maintaining it. Is anyone (Sébastien P.? others?) willing to be proxy maintainer? (Meaning you would be responsible for handling bugs and ebuild maintenance, and I will do the committing.) See also http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml I have a github repo now, where I accept pull requests, for people who find that convenient: https://github.com/yngwin/proxy-maint
(In reply to comment #147) > I'm back as Gentoo dev, and I think it is high time we get this package into > the portage tree. I am willing to commit this and related packages, but > would like to get some help from you guys with maintaining it. Is anyone > (Sébastien P.? others?) willing to be proxy maintainer? (Meaning you would > be responsible for handling bugs and ebuild maintenance, and I will do the > committing.) See also > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml > > I have a github repo now, where I accept pull requests, for people who find > that convenient: https://github.com/yngwin/proxy-maint Welcome back, good to see some action on this thread. A week ago i created a fork of the ebuild found on http://overlays.gentoo.org/proj/sunrise/browser/net-nntp/sabnzbd. Besides version bump i did a lot of changes to all files, which i find is for the better. As this is my first real ebuild i need someone to test it and verify that it is working. The fork can currently be found on: https://github.com/soehest/gentoo. I would be willing to maintain the ebuild and handle bugreports.
I am still here. Due to lot of work and trip organization, I could not take a look and update the ebuild. I will do it tomorrow (version bump, handle last comments, update depends and this fork). @drunejensen: I did not try your ebuild. But you have to move your variables from .init to .conf and the should be upercase (they are constant). “retart()” is implicit. It is useless to put it. Can you explain your changes? Is it because you have some problems with the precedent version or coding style preference? There will be one version on Portage. We have to merge them before yngwin publish it. @yngwin: I am OK too. hasufell has already wanted to add it on Portage. He wants to unbundle cherrypy and come across a snag: https://github.com/sabnzbd/sabnzbd/issues/47
(In reply to comment #149) > I am still here. > > Due to lot of work and trip organization, I could not take a look and update > the ebuild. > I will do it tomorrow (version bump, handle last comments, update depends > and this fork). Welcome back Sébastien :-) Work and real life must be taken care of before programming. Nice to see you back in action though :-) > > @drunejensen: > I did not try your ebuild. But you have to move your variables from .init to > .conf and the should be upercase (they are constant). > “retart()” is implicit. It is useless to put it. The variables were moved to init as i wanted to create a good user experience. Those variables in init are not supposed to be changed. Changing it would risk all kind of havoc as i am chowning the directories to fix permissions without user intervention. Imagine a user setting log_dir to "/var/log" ;-) "Normal" user would never need to see or change those variables, so i put them in the init script. Uppercase variables for constants? I just took a quick look at existing conf's in /etc/conf.d. and seems people will use uppercase/lowercase at random. I think lower case looks better but i can of course change it. > > Can you explain your changes? Is it because you have some problems with the > precedent version or coding style preference? > There will be one version on Portage. We have to merge them before yngwin > publish it. I can. As this is my very first ebuild I probabaly have made some errors. I picked it up as your versions seemed stalled. At first i thought it would be a quick copy/paste/replace but when getting further into your build there were stuff which i did not like. I am maintaining 3 machines which all use sabnzbd and i need to be able to install those quickly. sabnzbd-0.7.2.ebuild: Changed the way a user is created. No need to create a homedir for sabnzbd. Moved the config file to /etc/sabnzbd/sabnzbd.ini where imho it should belong. Changed paranoid permissions on /usr/share/sabnzbd there is no security risk in using defaults. Any user could install sabnzbd into the homedir if they wanted anyway. sabnzbd.conf: Simplified it as you already noticed. This is a personal choice. As said i need the ebuild to install and fire up without me having to change permissions etc. Having the pidfile logfolder etc in the conf is generally a good idea. But with the permission changes happen in init i think it too dangerous exposing those variables to users who will never need to change them anyway. sabnzbd.ini: Removed all not necessary options. The risk of having a "preused" ini file is that default settings (if changed) will not be set correctly, but be set using the old .ini file. Also there is a risk of old options still being used. Eg. "incomplete_dir = /var/lib/sabnzbd/incomplete" I can not find this option anywhere in sabnzbd. sabnzbd.init: Changed the way sabnzbd launched by using --background instead of -d. This is a symptom of sabnzbd not having a pidfile option but only a piddir (who came up with that solution :D) Instead of having to rely on the conf script setting the port correctly. Which can be confusing for users if they change port options in the web interface, this "fix" will always use a working and existing pidfile. Also there is a lot of chowning to user:group which will chown all used dirs (and files) to the user running the daemon. > > @yngwin: > I am OK too. I believe as you are back that you indeed should take over maintainership of this as it is your work in the first place. Talk to yngwin so we can get this package into portage :-) This fork was just created for my personal use and will probably use stuff which some people would not agree with :-) Best regards
(In reply to comment #147) > I'm back as Gentoo dev, and I think it is high time we get this package into > the portage tree. I am willing to commit this and related packages, but > would like to get some help from you guys with maintaining it. Is anyone > (Sébastien P.? others?) willing to be proxy maintainer? (Meaning you would > be responsible for handling bugs and ebuild maintenance, and I will do the > committing.) See also > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml > > I have a github repo now, where I accept pull requests, for people who find > that convenient: https://github.com/yngwin/proxy-maint I had already prepared a modified version of sabnzbd for the tree (with real multiple python abi support), but I don't like that issue at all: https://github.com/sabnzbd/sabnzbd/issues/47
(In reply to comment #151) > I had already prepared a modified version of sabnzbd for the tree (with real > multiple python abi support), but I don't like that issue at all: > https://github.com/sabnzbd/sabnzbd/issues/47 I don't like it either, which is why I didn't add it to portage when I looked at this 2.5 years ago. But as we can see, the issue is not straightforward (they have basically forked cherrypy) and there is no obvious solution. Even so, this is still a popular package, and as far as I know there are no equivalents. So I am willing to take this on as-is, with the help of some proxy-maintainers (I'm trying not to spread myself too thin).
Created attachment 322298 [details] sabnzbd-0.7.3.ebuild I've updated to the latest rev and added what I feel are more appropriate permissions on the various directories. Additionally I added a python_mod_cleanup the cleanup the optimize mess left over when removing the package.
(In reply to comment #153) > Created attachment 322298 [details] > sabnzbd-0.7.3.ebuild > > I've updated to the latest rev and added what I feel are more appropriate > permissions on the various directories. Additionally I added a > python_mod_cleanup the cleanup the optimize mess left over when removing the > package. - header is wrong - use the latest EAPI - all those useflags are currently invalid until GLEP 62 is implemented some day - python2.5 does not work with yenc, sabnzbd upstream obviously fails to know it. You are unable to restrict the user to run the package with 2.5, cause you don't have multiple python abi support and you don't convert any shebangs. The python version is only controlled by the init script which is bad. - eutils is completely unused - multilib is completely unused - user eclass is not inherited - there is no point in defining src_unpack phase here - the permission handling is ugly and difficult to read, use "find" or do some loop stuff - don't bloat pkg_postinst with information that should be in some kind of README file. And if you need to tell non-standard information which is gentoo specific or differs from the official docs, then use elog, cause einfo will never show up again. - there is no clean way to run sabnzbd without the init script, cause there is no wrapper script - all stuff is dumped into /usr/share/${PN} instead of python sitedirs.
- dodir is useless if we already use insinto
(In reply to comment #153) > Created attachment 322298 [details] > sabnzbd-0.7.3.ebuild > > I've updated to the latest rev and added what I feel are more appropriate > permissions on the various directories. Additionally I added a > python_mod_cleanup the cleanup the optimize mess left over when removing the > package. You probably used an old version (see header “2008”). (In reply to comment #150) > I believe as you are back that you indeed should take over maintainership of > this as it is your work in the first place. Talk to yngwin so we can get > this package into portage :-) This fork was just created for my personal use > and will probably use stuff which some people would not agree with :-) I will keep your pidfile, ini file and the idea of conf/init simplification. These can be usefull for everyone. I will try my changes tuesday.
(In reply to comment #156) > You probably used an old version (see header “2008”). I was. I see now it's been greatly cleaned up from the one I originally copied. I'll stay away from it now and just wait for it to hit portage.
Please CC back ppc if the arch team have anything to do here.
03 Jan 2013; Justin Bronder <jsbronder@gentoo.org> sabnzbd-0.7.7.ebuild, metadata.xml: Add support for using yenc *sabnzbd-0.7.7 (03 Jan 2013) 03 Jan 2013; Justin Bronder <jsbronder@gentoo.org> +sabnzbd-0.7.7.ebuild, +files/sabnzbd, +files/sabnzbd.confd, +files/sabnzbd.initd, +files/use-system-configobj-and-feedparser.patch, +metadata.xml: add net-nntp/sabnzbd
