NuxRef Repository

Introduction

The NuxRef Repository contains packages I maintained which are either original or a fork of the original changed for my own needs. Most RPMs on here are additionally featured in my blog entries.

Note: These repositories only supports 64-bit architectures.

Setup

The following RPMs will get you set up:

Repositories

Content/Repositories are grouped as follows:

  • nuxrefel6/src/rss, el7/src/rss, el8/src/rss, fc29/src/rss, fc30/src/rss, fc31/src/rss, fc32/src/rss, fc33/src/rss : All custom packages rebuilt reside here.
  • nuxref-testingel6/src/rss, el7/src/rss, el8/src/rss, fc29/src/rss, fc30/src/rss, fc31/src/rss, fc32/src/rss, fc33/src/rss : This is where I build early releases of projects I took on as my own. It’s also where I build newer versions of code already shared in the nuxref repository above. Once I’m satisfied with something here, it’ll eventually move into the nuxref repository.
  • nuxref-sharedel6/src/rss, el7/src/rss, el8/src/rss, fc29/src/rss, fc30/src/rss, fc31/src/rss, fc32/src/rss, fc33/src/rss: This is really just a snapshot in time of packages I used from the different external repositories I don’t maintain. It may not always be up to date, but it can be thought of as a baseline I use to support other blog entries I wrote. Anything you intend to install from the nuxref or the nuxref-testing repository may also require dependencies. I try to include those here to ease things for other people so they don’t run into dependency nightmares in the future. It’s also important to note that even though these packages are not mine, I re-write their rpm signature as an act to let you know it’s safe.

Repository Priorities

Most of my packaging is original, but some of it is based on and/or replaces content to which other repositories neglected or had just simply forgotten to maintain. I’ll only repackage something here because I either found a bug, or that I updated it to a more recent version. This process can however introduce conflicts over time when the original source finally gets around to updating their version. As recommended in one of the comments below, it would be advisable to install yum-priorities on your system. This can allow the original’s sources content to always over-ride mine.

# CentOS 6 & 7 users may wish to do this:
yum install yum-plugin-priorities

# DNF (for Fedora users) already has priorities built into it
# The following command will lower the priority for you:
sed -i -e 's/^\(priority\)=.*/\1=2/g' /etc/yum.repos.d/nuxref.repo

Consider that this can also work against you as well. Some of the packages I host add additional enhancements and patches that improve the usability of the product. If you chose to lower the priority of this repository and acquire the one hosted by the original source, you may lose functionality you once had (hence the reason I repackaged it in the first place).

If there are ever conflicts with my repository and another, please feel free to email me and let me know or just leave a comment in comment section below. I have no problem upgrading packages (and/or just simply abandoning them if there is no need to rehost them anymore). My goal is to keep all of the 3rd party repositories out there in working harmony with mine (if I can). My repositories are to just simply offer another (open source) solution for people.

Appreciation

I do all this for free and only when I have time on weekends (and some evenings). This includes hosting fees, system updates, the repository hosting, and all of the research for new packaging that I share. I certainly want to be clear by saying that no one owes me anything at all. But if you want to lend a helping hand by just buying me a cup of coffee (if I was able to help you out), it would certainly be greatly appreciated.

122 thoughts on “NuxRef Repository”

        1. I finally got around to fulfilling your request. Have a look at the /etc/yum.repos.d/nuxref.conf so you can point it to my CentOS 7 repositories instead (of version 6). Alternatively, I updated this post. You can recreate the .conf file and it should work (using $releasever variable).

          I ported over nzbget v15.0 (which just came out a few days ago). But I have not ported over all of it’s addons yet. If you use them though, you can just download them directly from NZBGet’s Extension Forum and install them into /usr/share/nzbget/scripts and it ‘should’ all work for the time being (depending on who’s script you use).

          Good luck! 🙂

  1. Been using your repo’s some time on CentOS/ClearOS 6. Now it’s time to play with ClearOS 7 which is based on CentOS 7. When installing NZBGet I get the following dependency issue:
    [pre]Package nzbget.x86_64 0:16.3-1.el7.nuxref will be installed
    –> Processing Dependency: libgnutls.so.28(GNUTLS_1_4)(64bit) for package: nzbget-16.3-1.el7.nuxref.x86_64
    –> Processing Dependency: libgnutls.so.28()(64bit) for package: nzbget-16.3-1.el7.nuxref.x86_64
    –> Finished Dependency Resolution
    Error: Package: nzbget-16.3-1.el7.nuxref.x86_64 (nuxref)
    Requires: libgnutls.so.28(GNUTLS_1_4)(64bit)
    Error: Package: nzbget-16.3-1.el7.nuxref.x86_64 (nuxref)
    Requires: libgnutls.so.28()(64bit)[/pre]
    I cannot find any package called libgnutls in the ClearOS repos. Is this dependecy issue also present in fresh CentOS 7 install?

    1. you could try adding:
      yum –enablerepo=nuxref-shared –enablerepo=nuxref install nzbget

      I’m pretty sure I already captured all of the missing dependencies and place them in the nuxref-shared repo.

  2. For all ClearOS users…
    Fixed by first using the following yum command:

    # yum install gnutls --enablerepo=clearos-centos

    It install GnuTLS and a tool called “trousers” for dependecy.

    1. Sure,

      I just built and packaged it now for you. I don’t have anytime to test it myself (just yet) so I’m just going to drop it in my testing repository for now. You’ll need to add –enable-repo=nuxref-testing to your call to yum.

      Hope that helps!

    1. So i’ve been running this for a couple days with no show stoppers. The only “issue” i’m seeing is that whenever Nagios goes to send an email I get the following error (with changes for the PID and the Job number)

      job 22600 (pid=18350): read() returned error 11

      It still sends the email but that error gets logged. I highly doubt that this is a packaging issue it seems much more like a Nagios issue.

      One other thing to remember when you upgrade is that it resets (as it should) all of the permissions on Nagios config directories and files back to defaults. If you use a web-based configurator (I use Lilac-reloaded) or something else that interacts with the files you’ll have to go back and reset so that your apache user (or whatever user your process runs as) can write to the files and directories.

      1. Thank you for passing along all your findings! I still have yet to try it out yet myself. Hopefully I’ll eventually get around to doing it soon.

        As per your first issue; it still may be my end (not sure). Do you have SELinux in enforcing mode by chance? I wrote all of the Nagios (SELinux) policies from scratch (originally for v4.1.1) since I couldn’t find any otherwise in the past. I’m just reusing the same ones for v4.2.0. It’s possible there are new features in this release that i need to account for (and update my policies). Would you mind passing along any error messages you see when you run the following and sharing your results; (if there is to much then maybe send it via email instead)?
        cat /var/log/audit/audit.log | egrep -i nagios | egrep -i deny

        As per your second comment; I have no problem adjusting my packaging a bit and altering some default permissions. Perhaps it would be easier if i set the nagios group with rwx permissions on the directories you’re having issues with (if they’re not already)?
        That way whatever user the Lilac-reloaded runs as, you just need to add it to the nagios group and it won’t be bothered by future updates. Alternatively; maybe this will simply fix your problem:
        # grant the lilac user access to all files owned
        # by the nagios group
        usermod -a -G nagios lilac

        1. I’m in permissive mode on SELinux so no dice on the first part. As for the second yes, settings nagios group with rwx permissions on the /etc portions of the package would have solved my issue.

          1. Thanks for all of your feedback. I finally got around to pushing one more update (still in the testing repo) that adds the (nagios) group permissions as discussed.

  3. Hello,

    I came across this repo via a forum post somewhere. I usually only trust repos on the Centos 3rd party repos wiki page, this repo is not. So how trustworthy are the maintainers behind this repo? And can this repo be used in combination with epel?

    1. I am the sole maintainer of every package you see here (except the shared repositories). I do this as a hobby on the side; I usually write a blog to go with it explaining their use (not all though). My packages are very legit; most of them are original too (some of which are even re-hosted on other peoples repositories such as Nux Dextop).

      The only thing I can’t promise you is when a new version of something is released, that it is available for everyone (here) right away. Some updates never get propagated here unless I get a request or find time. I post the source code (src.rpm) for every package I build and share for anyone who’s skeptical to rebuild or review it for themselves if they wish. I also sign my packages to help keep the integrity for those using dnf and yum to access the content.

      My repositories can definitely be used with EPEL or any other alike out there; absolutely. I wasn’t even aware of the ‘CentOS 3rd Party Repos‘ page until you just shared it with me; Thanks! I’ll pass my repo info along to them.

  4. Hi l2g, can you update NZBGet to 17.1? Current version in your repo is 16.3. I’m using your EL6 repo.
    Like your work! [ThumbsUp]

    1. Unfortunately NZBGet v17.x was re-coded using a glib library that isn’t supported in CentOS 6.x; See here for more details. But basically that link takes you to a blog i wrote explaining (and sharing) the patch I created just to make NZBGet v17.0 work with CentOS 7.x. At this time, I don’t know what the effort would be to back port all of this code even further.

  5. Thanks l2g for your quick reply. It seems I can no longer postpone upgrading from CentOS 6 to 7. Will be on my to do list for the spring holidays this year.

    Regards.

  6. Hi. You might want to add that installing yum-plugin-priorities is a strong recommendation, since without it there is a risk of conflicts between nuxref and epel repositories. Like for instance

    pkcon search name nagios
    Searching by name [=========================]
    Starting [=========================]
    Querying [=========================]
    Finished [=========================]
    Available nagios-4.2.2-2.el7.nuxref.x86_64 (nuxref) Open Source host, service and network monitoring program
    Available nagios-4.2.2-4.el7.nuxref.x86_64 (nuxref) Open Source host, service and network monitoring program
    Available nagios-4.2.4-2.el7.x86_64 (epel) Host/service/network monitoring program
    Available nagios-4.3.1-1.el7.nuxref.x86_64 (nuxref) Open Source host, service and network monitoring program
    ...
    Available nagios-plugins-1.5-5.el7.nuxref.x86_64 (nuxref) Host/service/network monitoring program plugins for Nagios
    Available nagios-plugins-2.1.3-1.el7.nuxref.x86_64 (nuxref) Host/service/network monitoring program plugins for Nagios
    Available nagios-plugins-2.1.4-2.el7.x86_64 (epel) Host/service/network monitoring program plugins for Nagios

    In this case, without priorities plugin installed, trying to run “yum install nagios nagios-plugins” will fail because the plugins package from epel have a newer version.

    1. Your advice is welcome! This can honestly be said about any 3rd party repository to which you might prefer one over another. On a side note, I didn’t realize EPEL had finally upgraded their hosting of Nagios AND Nagios Plugins. That’s great news!

      I updated the page to consider your advice; but always consider the downside to priorities as well. On that note, I also updated Nagios plugins on my repository to accommodate what you had observed.

  7. Hi Nuxref,

    Can I request that the sabnzbd package be updated? Current version is 2.2, and the version in your repo is stuck at 1.x

  8. yum install sonarr

    Error: Package: nodejs-error-ex-1.3.0-2.el7.nuxref.noarch (nuxref)
    Requires: npm(is-arrayish)
    Error: Package: nodejs-error-ex-1.3.0-2.el7.nuxref.noarch (nuxref)
    Requires: npm(is-arrayish) <= 0.3.0
    You could try using –skip-broken to work around the problem
    You could try running: rpm -Va –nofiles –nodigest

    1. Good find! Thank you for pointing that out. I had the RPM built but not available on my repository. It is now though! 🙂 Giver another go!

    1. Good catch; python-sabyenc has been added now.

      Your system (via dnf) may have already cached what I had hosted (missing the package), so you might have to do the following first in order to haul it in:

      # Just clear out repository cache for nuxref content
      dnf clean all --disablerepo=* --enablerepo=nuxref*

      # now SABnzbd should install:
      dnf install sabnzbd

      That will allow your local side to resync with mine (but not touch any other repositories you may already have set up such as epel, etc).

      Not sure if you’ve used my packages before, but I have a write-up on how I set SABnzbd up if it helps.

  9. Thanks for the reply; my sabnzbd installation went smoothly, following your instructions. I then followed the instructions at http://nuxref.com/2016/10/20/sabnzbd-installation-centos-7/:

    login as steve
    usermod -a -G sabnzbd steve
    logout
    login as steve
    systemctl start sabnzbd.service
    firefox : http://localhost:8090

    firefox result : problem loading page – unable to connect

    I request any advice. I have no firewall. Using fedora 26 because 10 days ago my fedora 22 boot disk died. About two years ago, under fedora 22 cinnamon, the sabnzbd install went okay, providing a f22-cinnamon menu item. Apparently, that install took me to http://127.0.0.1:8080/sabnzbd/. Experimenting, I tried various combinations to see if the problem was http://localhost:8090 : no joy. Below is the tail of /var/log/sabnzbd/sabnzbd.log

    ———— start of tail of log —————–

    2017-09-11 12:50:04,376::INFO::[postproc:82] Saving postproc queue
    2017-09-11 12:50:04,376::INFO::[__init__:941] Saving data for postproc2.sab in /var/lib/sabnzbd/admin/postproc2.sab
    2017-09-11 12:54:18,722::INFO::[SABnzbd:1147] ——————————–
    2017-09-11 12:54:18,734::INFO::[SABnzbd:1148] SABnzbd.py-2.2.1 (rev=bcc4dd75cfeab41a4b56308709c04fd568859d1f)
    2017-09-11 12:54:18,734::INFO::[SABnzbd:1149] Full executable path = /usr/share/sabnzbd/SABnzbd.py
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1161] Platform = posix
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1162] Python-version = 2.7.13 (default, Sep 5 2017, 08:53:59)
    [GCC 7.1.1 20170622 (Red Hat 7.1.1-3)]
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1163] Arguments = /usr/share/sabnzbd/SABnzbd.py –logging=1 –browser=0 –config-file=/etc/sabnzbd/sabnzbd.conf
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1168] Preferred encoding = UTF-8
    2017-09-11 12:54:18,735::INFO::[SABnzbd:1209] Read INI file /etc/sabnzbd/sabnzbd.conf
    2017-09-11 12:54:18,760::INFO::[__init__:964] Loading data for rss_data.sab from /var/lib/sabnzbd/admin/rss_data.sab
    2017-09-11 12:54:18,766::INFO::[__init__:964] Loading data for totals10.sab from /var/lib/sabnzbd/admin/totals10.sab
    2017-09-11 12:54:18,767::INFO::[postproc:88] Loading postproc queue
    2017-09-11 12:54:18,767::INFO::[__init__:964] Loading data for postproc2.sab from /var/lib/sabnzbd/admin/postproc2.sab
    2017-09-11 12:54:18,768::INFO::[__init__:964] Loading data for queue10.sab from /var/lib/sabnzbd/admin/queue10.sab
    2017-09-11 12:54:18,769::INFO::[__init__:964] Loading data for watched_data2.sab from /var/lib/sabnzbd/admin/watched_data2.sab
    2017-09-11 12:54:18,770::INFO::[__init__:964] Loading data for Rating.sab from /var/lib/sabnzbd/admin/Rating.sab
    2017-09-11 12:54:18,771::INFO::[__init__:967] /var/lib/sabnzbd/admin/Rating.sab missing
    2017-09-11 12:54:18,772::INFO::[scheduler:201] Setting schedule for midnight BPS reset
    2017-09-11 12:54:18,772::INFO::[__init__:343] All processes started
    2017-09-11 12:54:18,772::INFO::[SABnzbd:281] Web dir is /usr/share/sabnzbd
    2017-09-11 12:54:18,773::WARNING::[SABnzbd:285] Cannot find web template: /usr/share/sabnzbd/templates/main.tmpl, trying standard template
    2017-09-11 12:54:18,784::INFO::[SABnzbd:281] Web dir is /usr/share/sabnzbd/interfaces/Config
    2017-09-11 12:54:18,801::INFO::[config:855] Writing settings to INI file /etc/sabnzbd/sabnzbd.conf
    2017-09-11 12:54:18,837::INFO::[SABnzbd:405] SABYenc module (v3.0.2)… found!
    2017-09-11 12:54:18,837::INFO::[SABnzbd:424] Cryptography module… NOT found!
    2017-09-11 12:54:18,837::INFO::[SABnzbd:427] par2 binary… found (/usr/bin/par2)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:435] UNRAR binary… found (/usr/bin/unrar)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:448] unzip binary… found (/usr/bin/unzip)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:453] 7za binary… found (/usr/bin/7za)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:459] nice binary… found (/usr/bin/nice)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:463] ionice binary… found (/usr/bin/ionice)
    2017-09-11 12:54:18,837::INFO::[SABnzbd:1254] SSL version OpenSSL 1.1.0f-fips 25 May 2017
    2017-09-11 12:54:18,838::INFO::[SABnzbd:1255] SSL supported protocols [‘TLS v1.2’, ‘TLS v1.1’, ‘TLS v1’, ‘SSL v3’]
    2017-09-11 12:54:18,839::INFO::[SABnzbd:1365] Starting web-interface on 127.0.0.1:8080
    2017-09-11 12:54:18,839::INFO::[_cplogging:219] [11/Sep/2017:12:54:18] ENGINE Bus STARTING
    2017-09-11 12:54:18,848::INFO::[_cplogging:219] [11/Sep/2017:12:54:18] ENGINE Started monitor thread ‘_TimeoutMonitor’.
    2017-09-11 12:54:19,097::INFO::[_cplogging:219] [11/Sep/2017:12:54:19] ENGINE Serving on http://127.0.0.1:8080
    2017-09-11 12:54:19,099::INFO::[_cplogging:219] [11/Sep/2017:12:54:19] ENGINE Bus STARTED
    2017-09-11 12:54:19,106::INFO::[zconfig:64] No Bonjour/ZeroConfig support installed
    2017-09-11 12:54:19,106::INFO::[SABnzbd:1410] Starting SABnzbd.py-2.2.1
    2017-09-11 12:54:19,111::INFO::[dirscanner:327] Dirscanner starting up
    2017-09-11 12:54:19,112::INFO::[urlgrabber:72] URLGrabber starting up
    2017-09-11 12:54:19,141::INFO::[postproc:169] Completed Download Folder /var/lib/sabnzbd/complete is not on FAT
    2017-09-11 12:54:29,904::WARNING::[__init__:181] Signal 15 caught, saving and exiting…
    2017-09-11 12:54:29,904::INFO::[nzbqueue:274] Saving queue
    2017-09-11 12:54:29,904::INFO::[__init__:941] Saving data for queue10.sab in /var/lib/sabnzbd/admin/queue10.sab
    2017-09-11 12:54:29,904::INFO::[__init__:941] Saving data for totals10.sab in /var/lib/sabnzbd/admin/totals10.sab
    2017-09-11 12:54:29,905::INFO::[__init__:941] Saving data for rss_data.sab in /var/lib/sabnzbd/admin/rss_data.sab
    2017-09-11 12:54:29,905::INFO::[__init__:941] Saving data for watched_data2.sab in /var/lib/sabnzbd/admin/watched_data2.sab
    2017-09-11 12:54:29,905::INFO::[postproc:82] Saving postproc queue
    2017-09-11 12:54:29,905::INFO::[__init__:941] Saving data for postproc2.sab in /var/lib/sabnzbd/admin/postproc2.sab

    ———— end of tail of log —————–

    1. It could very well just be a typo in my blog. Your configuration file will be in /etc/sabnzbd/sabnzbd.conf.

      You can see what port is defined there. If you can access http://localhost:8080 after you install it then you’re in great shape! You can do any future configuring from within the SABnzb website when it comes up.

      You could also try doing the follow after you’ve started it up:

      # list all of the ports your system is listening on that match
      # the regular expression 80.0 (8080 would match, so would 8090)
      netstat -nat | egrep -i listen | egrep :80.0

      At least that will give you some insight on what to try next.

      Feel free to message me again if you have problems. I’m slow responding because I’m out of town right now. Good luck!

  10. Total success, thanks again for your responses. In my previous query, I provided an excerpt from the log just in case my sabnzbd was malfunctioning, which it was not. Based on the results of your suggested netstat command, it appeared that http://127.0.0.1:8080/sabnzbd/ would work for me. In fact, this url does work. Interesting that the install of two years ago actually created a menu app (in fedora 22 – cinnamon); launching this app placed an icon in the system tray and simultaneously invoked http://127.0.0.1:8080/sabnzbd/ in the web browser.

    Your latest sabnzbd has streamlined this to eliminate the app, the user merely ensures that the sabnzbd service is started and then manually launches http://127.0.0.1:8080/sabnzbd/ (et al) in his web browser. BTW
    1. I found that “systemctl enable sabnzbd.service” does work across reboots, but after executing this bash command, I had to do a cold boot (rather than mere logout) to “initiate” the service.
    2. Selecting the “shutdown sabnzbd” command from the upper right portion of the http://127.0.0.1:8080/sabnzbd/ webpage is apparently equivalent to “systemctl stop sabnzbd.service”.

    1. Just to address the first of your 2 points (for future reference).
      1. systemctl enable <service.name> does just that.. it just enables the service so that it can start on system boot (as you already know). systemctl start <service.name> is all the magic that happens at boot; so you can run this yourself (and save yourself from rebooting your server in the future).

      Otherwise, I’m glad hear you got everything going and thanks for your feedback. I updated the blog to reference 8080 instead of 8090.

  11. This message is an fyi that happens to be consistent with the site-admin’s message of September 11, 2017. My boot disk died, so I had to re-install fedora 26 and then sabnzbd. Following this
    installation, I attempted to access http://localhost:8080/ in Firefox; the result was “…can not connect…”. Investigating, I found the following line near the top of the /etc/sabnzbd/sabnzbd.conf file:

    port = 9080

    I then resolved the problem by accessing http://localhost:9080/

  12. Responding because I’m unsure that my message of Oct 2, 2017 is being interpreted correctly. For me, the pertinent url varied from one Fedora 26 install to another. Therefore, I think that the site-admin’s blog should NOT indicate a specific url, such as http://localhost:9080/, http://localhost:8080/, or http://localhost:8090/.

    Consistent with the site-admin’s message of Sept 11, 2017, the blog should instead give the user two choices:

    1. Inspect the configuration file. In Fedora 26, this is the /etc/sabnzbd/sabnzbd.conf file. In this file, the user may find a string near the top of the file that is similar to the following: “port = 9080”.

    2. Use the netstat command to list all of the ports that the user’s system is listening on:
    netstat -nat | egrep -i listen

    Using one or both of the above methods, the user should then make an educated guess at formatting the pertinent url (a sample url would be http://localhost:8080/) . If you can access the url (e.g. in Firefox), then you have probably formatted the url correctly. If you can’t, then your web browser may respond with a “… can not connect …” message.

  13. I installed sabnzbd, now I get an error trying to install certbot-nginx (letsencrypt):

    Transaction check error:
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/__init__.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/__init__.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/__init__.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/__init__.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/utils.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/utils.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/utils.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/bin/ndg_httpclient from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/https.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/https.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/https.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_context_util.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_context_util.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_context_util.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_peer_verification.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_peer_verification.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_peer_verification.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_socket.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_socket.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/ssl_socket.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/subj_alt_name.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/subj_alt_name.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/subj_alt_name.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/pki/localhost.crt from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/pki/localhost.key from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_https.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_https.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_https.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_urllib2.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_urllib2.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_urllib2.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_utils.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_utils.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/test/test_utils.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/urllib2_build_opener.py from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/urllib2_build_opener.pyc from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch
    file /usr/lib/python2.7/site-packages/ndg/httpsclient/urllib2_build_opener.pyo from install of python-ndg-httpsclient-0.4.2-1.el7.nuxref.noarch conflicts with file from package python-ndg_httpsclient-0.3.2-1.el7.noarch

    Any ideas?

    1. Your error shows a conflict between my repository and EPEL’s. I honestly want to two to work in harmony so i really appreciate you sharing with me your issue!

      EPEL usually follows a very specific naming scheme and avoids references to underscores (_) in rpm names. This one appears to be an exception. I just updated my copy (a newer version) of ndg_httpsclient that I ship as ndg-httpsclient allowing it too accept ndg_httpsclient as a valid name too.

      If you wouldn’t mind, just clean your yum cache and try again (let me know how it goes):

      yum  --enablerepo=nuxref* clean all
      
      # then try your update again (whatever you were doing previously).
      

      If this doesn’t work (it should), i got one more trick up my sleeve; so please let me know either way! 🙂

  14. Can’t find a way to report a probem with a package … ?

    nzbget-19.1-1.fc27.nuxref.x86_64 seems to be broken, can’t run the binary in
    daemon mode, -D does nothing. Works just fine if I run a screen session and
    run it in server mode using the -s switch.

    1. Thanks for your input, I’ll have a look at it tonight if i can.
      It might be related to SELinux (not sure). You could try running “setenforce 0” (as root) first.

  15. Mystery solved.

    The news server account had expired 🙂

    The daemon mode didn’t complain about this, but the -s eventually did.

  16. Hi, just tried to run an update on my CentOS 7 server but got the following errors:

    Transaction check error:
      file /usr/lib64/python2.7/site-packages/cryptography-1.7.2-py2.7.egg-info/SOURCES.txt from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography-1.7.2-py2.7.egg-info/requires.txt from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography-1.7.2-py2.7.egg-info/top_level.txt from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/backends/openssl/decode_asn1.py from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/backends/openssl/decode_asn1.pyc from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/backends/openssl/decode_asn1.pyo from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/_constant_time.so from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/_openssl.so from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/_padding.so from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.pyc from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
      file /usr/lib64/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.pyo from install of python2-cryptography-1.7.2-1.el7_4.1.x86_64 conflicts with file from package python-cryptography-1.7.2-2.el7.nuxref.x86_64
    
    1. Hi,

      Interesting, EPEL hasn’t updated their cryptography library in 2 years, and they suddenly decided to do so and use the exact same version I’m sharing here (causing your conflict). I just upgraded to the latest stable version of cryptography (2.1.4) and made a small patch so the next time EPEL updates there won’t be a conflict like you got today.

      You can try again and it should work (let me know otherwise) and thanks for bringing this to my attention!

          1. try this:

            # Clear your cache again (as i did just make another update)
            yum clean all
            
            # Just update your cryptography package using the one provided on nuxref (don't use the updates/base one for now)
            yum --disablerepo=* --enablerepo=nuxref install python-cryptography
            

            Going forward, my package identifies itself as providing python2-cryptography (as well as python-cryptography). This should get rid of any package issues around it.

  17. Just noticed new problem : downloads are going okay, but sabnzbd is reporting errors when trying to write to any subdirectory of /var/lib/sabnzbd/. In my fedora 26 (64-bit) OS, /var/lib/sabnzbd/ is listed as read-only for the general user. I just tried ‘sudo chmod -R /var/lib/sabnzbd/’, and IT FAILED.

    Request help. If a configuration setting that reroutes history entries to a subfolder of /home/steve/ will resolve problem, that would be GREAT.

  18. Please disregard my message of March 27, 2018. Hard disk was just starting to fail, this was one of the symptoms. This was NOT A SABNZBD PROBLEM.

  19. Fedora 28

    Only way I could get your repo working was to issue the install like this:
    # dnf –nogpgcheck install http://repo.nuxref.com/fedora/fc27/en/x86_64/custom/nuxref-release-1.0.0-4.fc27.nuxref.noarch.rpm
    I had to also add the non-free rpm fusion repo to install the required unrar which is needed and not found when trying to install sabnzbd

    When trying to install the notify script I get this:
    # dnf install sabnzbd-script-notify
    Last metadata expiration check: 0:00:14 ago on Sun 06 May 2018 05:42:41 AM EDT.
    Error:
    Problem: conflicting requests
    – nothing provides python-ordereddict needed by sabnzbd-script-notify-0.7.0-1.fc27.nuxref.noarch

    No clue how to address this

      1. Thanks. Let me just preface that I am NOT and dnf expert; I am ‘muddling” my way through for now (FC27 and now playing FC28), so apologies in advance and thanks for indulging my ignorance.

        So that error is gone. Now I get:
        # dnf install sabnzbd-script-notify
        Failed to synchronize cache for repo ‘nuxref-shared’, disabling.
        Last metadata expiration check: 0:00:29 ago on Sun 06 May 2018 05:45:11 PM EDT.
        Error:
        Problem: conflicting requests
        – nothing provides python-nzbget >= 0.6.1 needed by sabnzbd-script-notify-0.7.0-1.fc27.nuxref.noarch

        The synchronize error has been there since the start and I worked around it, just like I had to install the fc27 repo using the “–nogpgcheck” option because this:
        # dnf install http://repo.nuxref.com/fedora/fc27/en/x86_64/custom/nuxref-release-1.0.0-4.fc27.nuxref.noarch.rpm

        gives GPG key import errors from the repo and errors that the cache couldn’t be synced or something and fails to enable (and install I guess?). I missed copying/capturing the “cache error” part but here are the other errors when trying to install the repo w/o the –nogpgcheck:

        error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
        error: /etc/pki/rpm-gpg/RPM-GPG-KEY-nuxref-com: key 1 import failed.

        So the –nogpgcheck got around installing and/or enabling the repo so the “dnf install sabnzdb” worked.

        Now as far as the python-nzbget requirement for the notify script, can I just install the FC26 repo and “dnf check-update –refresh”? As I see it appears there.. ?

  20. Another problem simply running sabnzbd (haven’t addressed the “sabnzbd-script-notify” issue above yet…):

    I run the daemon as “liveuser” in this live instance of Fedora28 because user sabnzbd cannot access (to write to) the external USB hard drive I have connected where I store downloads.. therefore I run the daemon as follow:
    $ python /usr/share/sabnzbd/SABnzbd.py –logging=1 –browser=0 –config-file=/home/liveuser/sabnzbd.conf

    This was not an issue on the live fedora27 I was running a few weeks ago. On that install of SAB I couldn’t get the sab install done via the repo either and I manually installed the RPM of sab (plus manually installed the pre-req unrar).

    This FC28 live instance I got the repo to install SAB but now the error thrown from the above command line is follows:
    Sorry, requires Python module Cheetah 2.0rc7 or higher.

    Cheetah version installed is:
    python2-cheetah-3.1.0-1.fc28.x86_64

    I’m not sure WHY it doesn’t, or if it does, detect cheetah at all.. I believe it was installed along with the sabnzbd package from the repo. No version lower than the 3.1.0 version is avail according to dnf search.

    What I did was remove python2-cheetah AND python3-cheetah (which ALSO removed sabnzbd), then manually installed:
    $ dnf install http://dl.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/p/python-cheetah-2.4.4-16.fc27.x86_64.rpm

    then reinstalled sabnzbd (from your repo)

    Now it runs.

    1. Wow, that sounds complicated but I’m glad you got it going! Thanks for sharing your success!

      Sadly the software I use (mock) to build all of my RPMs for all of the different repositories (and Linux flavors) can’t build Fedora 28 packages at all (at the moment). It can still build packages for Fedora 27 (and lower) + CentOS, etc.

      Something changed in Fedora 28 that will require me to re-invest time in how i deploy software for others to use. I’m not sure when i’ll get around to this, so Fedora 27 will be the latest repo just for now.

      As per nzb-notify, good catch; it looks like you found another rpm I didn’t account for. I’ve posted it here (for Fedora 27 which seems to be working for you).

  21. Anything what I can do?

    Fehler: Paket: node-gyp-0.10.6-2.el7.noarch (@epel)
    Benötigt: npm(graceful-fs) < 3
    Entfernen: nodejs-graceful-fs-2.0.0-2.el7.noarch (@epel)
    npm(graceful-fs) = 2.0.0
    Aktualisiert durch: nodejs-graceful-fs-4.1.3-1.el7.nuxref.noarch (nuxref)
    npm(graceful-fs) = 4.1.3
    Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
    Benötigt: npm(once) < 1.2
    Entfernen: nodejs-once-1.1.1-5.el7.noarch (@epel)
    npm(once) = 1.1.1
    Aktualisiert durch: nodejs-once-1.3.3-1.el7.nuxref.noarch (nuxref)
    npm(once) = 1.3.3
    Fehler: Paket: node-gyp-0.10.6-2.el7.noarch (@epel)
    Benötigt: npm(minimatch) < 1
    Entfernen: nodejs-minimatch-0.2.12-2.el7.noarch (@epel)
    npm(minimatch) = 0.2.12
    Aktualisiert durch: nodejs-minimatch-3.0.0-1.el7.nuxref.noarch (nuxref)
    npm(minimatch) = 3.0.0
    Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
    Benötigt: npm(osenv) = 0.0.3
    Entfernen: nodejs-osenv-0.0.3-5.el7.noarch (@epel)
    npm(osenv) = 0.0.3
    Aktualisiert durch: nodejs-osenv-0.1.3-1.el7.nuxref.noarch (nuxref)
    npm(osenv) = 0.1.3
    Fehler: Paket: node-gyp-0.10.6-2.el7.noarch (@epel)
    Benötigt: npm(semver) < 2.2
    Entfernen: nodejs-semver-2.1.0-3.el7.noarch (@epel)
    npm(semver) = 2.1.0
    Aktualisiert durch: nodejs-semver-5.1.0-1.el7.nuxref.noarch (nuxref)
    npm(semver) = 5.1.0
    Fehler: Paket: node-gyp-0.10.6-2.el7.noarch (@epel)
    Benötigt: npm(tar) < 1
    Entfernen: nodejs-tar-0.1.18-1.el7.noarch (@epel)
    npm(tar) = 0.1.18
    Aktualisiert durch: nodejs-tar-2.2.1-1.el7.nuxref.noarch (nuxref)
    npm(tar) = 2.2.1
    Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
    Benötigt: npm(semver) < 3
    Entfernen: nodejs-semver-2.1.0-3.el7.noarch (@epel)
    npm(semver) = 2.1.0
    Aktualisiert durch: nodejs-semver-5.1.0-1.el7.nuxref.noarch (nuxref)
    npm(semver) = 5.1.0
    Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
    Benötigt: npm(ini) < 1.2
    Entfernen: nodejs-ini-1.1.0-3.el7.noarch (@epel)
    npm(ini) = 1.1.0
    Aktualisiert durch: nodejs-ini-1.3.4-1.el7.nuxref.noarch (nuxref)
    npm(ini) = 1.3.4
    Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
    Benötigt: npm(mkdirp) < 0.4
    Entfernen: nodejs-mkdirp-0.3.5-3.el7.noarch (@epel)
    npm(mkdirp) = 0.3.5
    Aktualisiert durch: nodejs-mkdirp-0.5.1-1.el7.nuxref.noarch (nuxref)
    npm(mkdirp) = 0.5.1
    Fehler: Paket: node-gyp-0.10.6-2.el7.noarch (@epel)
    Benötigt: npm(npmlog) < 1
    Entfernen: nodejs-npmlog-0.0.4-3.el7.noarch (@epel)
    npm(npmlog) = 0.0.4
    Aktualisiert durch: nodejs-npmlog-2.0.3-1.el7.nuxref.noarch (nuxref)
    npm(npmlog) = 2.0.3
    Fehler: Paket: node-gyp-0.10.6-2.el7.noarch (@epel)
    Benötigt: npm(fstream) < 1
    Entfernen: nodejs-fstream-0.1.24-1.el7.noarch (@epel)
    npm(fstream) = 0.1.24
    Aktualisiert durch: nodejs-fstream-1.0.8-1.el7.nuxref.noarch (nuxref)
    npm(fstream) = 1.0.8

    1. For now, you could try adding –ignorerepo=epel to your yum command as there appears to be a conflict taking place. Alternatively if it’s just my repository that is holding you back, you could try –ignorerepo=nuxref instad and see if the update goes a little smoother.

      The packages on nuxref (my repository) for NodeJS are probably pretty old now; at the time they would have been better than EPEL, but it’s possible the EPEL repository has finally caught up (this is a good thing).

      Anyway; thanks for sharing your issue; I’ll see if i can investigate this further in the next couple of days and make the 2 repositories work in harmony again.

      1. Thank you for your reply. I have tried your “-ignorerepo” command but this didn’t worked. But with “yum update –disablerepo=nuxref*” I was able to run my update command for all other packages 😉

        Hope to hear from you soon. 😉

        1. Hi Toxic,

          I made one small change to the repository that should help you out. You’ll want to clean any nuxref metadata you have cached with yum first (otherwise it won’t see this new package):

          # as root
          # the below just clears the nuxref metadata
          yum clean all --disablerepo=* --enablerepo=nuxref*
          

          Then you should be able to get the package you’re stuck on (node-gyp). EPEL refers to it as node-gyp which is against their normal naming convention (which prefixes everything with “nodejs-“). I updated my copy of it which will hopefully resolve your issue. So… back on topic: after clearing your yum cache, this command should actually pull from nuxref’s repo and not epel:

          # as root
          yum install node-gyp 
          

          Alternatively; you should be able to just try your original yum install command again and it will work.

          1. Thank you for your solution but this worked partial I have some issues left:

            Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
            Benötigt: npm(once) < 1.2
            Entfernen: nodejs-once-1.1.1-5.el7.noarch (@epel)
            npm(once) = 1.1.1
            Aktualisiert durch: nodejs-once-1.3.3-1.el7.nuxref.noarch (nuxref)
            npm(once) = 1.3.3
            Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
            Benötigt: npm(osenv) = 0.0.3
            Entfernen: nodejs-osenv-0.0.3-5.el7.noarch (@epel)
            npm(osenv) = 0.0.3
            Aktualisiert durch: nodejs-osenv-0.1.3-1.el7.nuxref.noarch (nuxref)
            npm(osenv) = 0.1.3
            Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
            Benötigt: npm(ini) < 1.2
            Entfernen: nodejs-ini-1.1.0-3.el7.noarch (@epel)
            npm(ini) = 1.1.0
            Aktualisiert durch: nodejs-ini-1.3.4-1.el7.nuxref.noarch (nuxref)
            npm(ini) = 1.3.4
            Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
            Benötigt: npm(mkdirp) < 0.4
            Entfernen: nodejs-mkdirp-0.3.5-3.el7.noarch (@epel)
            npm(mkdirp) = 0.3.5
            Aktualisiert durch: nodejs-mkdirp-0.5.1-1.el7.nuxref.noarch (nuxref)
            npm(mkdirp) = 0.5.1
            Fehler: Paket: nodejs-npmconf-0.1.3-1.el7.noarch (@epel)
            Benötigt: npm(semver) < 3
            Entfernen: nodejs-semver-2.1.0-3.el7.noarch (@epel)
            npm(semver) = 2.1.0
            Aktualisiert durch: nodejs-semver-5.1.0-1.el7.nuxref.noarch (nuxref)
            npm(semver) = 5.1.0

          2. We’ll just keep tackling this one package at a time. I updated package at the top of your error list (nodejs-npmconf) on my site (to attempt to be compatible with what you’re trying to do).

            You’ll have to clean your nuxref cache again before trying again (see our previous chat exchange) and give it another try. Let me know how it goes! If you get into another pickle, just keep pasting your errors and we’ll slowly figure them out! 🙂

            Thanks for being patient in this matter!

            Good luck!

          3. I can’t answer to your last comment.

            However your last solution works now and I was able to run my yum update command.

            Thank you for your support 😉

  22. I want to thank the site admin for a great product. I also want to thank al g for his comments of May 18, 2018; they were very helpful. I had been using sabnzbd in Fedora 26 and I recently had to do a COMPLETE REINSTALL TO FEDORA 29. Using al g’s comments, I SUCCESSFULLY used the following steps to install into Fedora 29.

    1. sudo dnf –nogpgcheck install http://repo.nuxref.com/fedora/fc27/en/x86_64/custom/nuxref-release-1.0.0-4.fc27.nuxref.noarch.rpm

    Note that if you paste the above command from this webpage, you should check that the nogpgcheck parameter is preceded by two hyphens, as the dnf command requires.

    Also, when I executed this command, the response in my bash terminal included the following two messages

    error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
    error: /etc/pki/rpm-gpg/RPM-GPG-KEY-nuxref-com: key 1 import failed.

    Experimenting, I decided to ignore these messages; the install seems to have worked okay.

    2. sudo dnf install sabnzbd

    When I executed this command, the response in my bash terminal included the following two messages

    RHEL 29 – nuxref.com – shared
    Failed to synchronize cache for repo ‘nuxref-shared’, ignoring this repo.

    warning: /var/cache/dnf/nuxref-574af2fdd520fd74/packages/python-sabyenc-3.3.5-1.fc27.nuxref.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID efe82e3b: NOKEY

    Again experimenting, I ignored these messages. The install worked. The rest of my sabnzbd install proceeded normally. As a reference, my subsequent steps are shown below:

    3. sudo usermod -a -G sabnzbd steve

    4. sudo systemctl start sabnzbd.service :

    This initial start of sabnzbd is manually invoked, this permits immediate configuration.

    5. determine port to use: either 5a or 5b below may be used.

    5a. examine the sabnzbd configuration file.

    my file was found in /etc/sabnzbd/sabnzbd.conf
    it contained : port = 9080

    5b. from a bash terminal : netstat -nat | egrep -i listen

    6. Close and then re-open your web browser (e.g. Firefox) and then navigate to http://localhost:9080/

    Since the sabnzbd service is running, and since it was using port 9080, I was able to use this link to access the SABnzbd quick start wizard. This wizard allowed me to customize my folders and servers.

    7. sudo systemctl enable sabnzbd.service

    My first start of the sabnzbd service was manually invoked (step 4 above). This step will ensure that the sabnzbd service is automatically started each time I reboot my pc.

    7. In my web browser, create a bookmark to http://127.0.0.1:9080/sabnzbd/

    With the service running, I can access the sabnzbd services in my web browser, via the above link.

    1. Thanks for your updates. I haven’t had time to get any of this working out of the box with an actual Fedora 28 and 29 RPM only because they changed how the product that i normally use works with these flavors.

      Glad to see you have a workaround though and thanks for sharing it! 🙂

    1. Hi,

      This is probably the one (and only) time I actually had this package updated just hours after it was released :). It’s already available through yum (and was at the time you made this post). But you can also get it directly here.

  23. Hey,

    it’s me again. 😉
    Actually I have 2 dependencies issues with your repo:

    Fehler: Paket: python2-josepy-1.2.0-1.el7.noarch (epel)
    Benötigt: python2-setuptools
    Verfügbar: python-setuptools-0.9.8-7.el7.noarch (base)
    python2-setuptools = 0.9.8-7.el7
    Installiert: python-setuptools-25.0.1-1.el7.nuxref.noarch (@nuxref)
    ~python-setuptools = 25.0.1-1.el7.nuxref
    Fehler: Paket: nodejs-validate-npm-package-name-2.2.2-1.el7.nuxref.noarch (@nuxref)
    Benötigt: npm(builtins) = 0.0.7
    Entfernen: nodejs-builtins-0.0.7-1.el7.nuxref.noarch (@nuxref)
    npm(builtins) = 0.0.7
    Aktualisiert durch: nodejs-builtins-1.0.2-1.el7.noarch (epel)
    npm(builtins) = 1.0.2

    Do you have any solutions?

    Greetings

    1. Sorry to take so long to get back to you. It looks like the EPEL Repository is conflicting with mine. What happens if you just try something like:

      yum --disablerepo=* --enablerepo=epel install python2-josepy

      Does that work?

      1. Nope not really.

        Fehler: Paket: python2-josepy-1.2.0-1.el7.noarch (epel)
        Benötigt: python2-setuptools

        It needs python2-setuptools but my system has python2-2-setuptools. ?

        1. First off,

          Sorry to take so long to get back to you. Life is a busy one :). This weekend i will try to repackage python-setuptools (my copy here) to additionally mask itself as python2-setuptools and python2-2-setuptools. That should hopefully fix your issue.

        2. I pushed a small update that may work for you. You’ll need to make sure you clear your yum cache first before you give it another shot. Let me know how it goes. 🙂

          1. Thank you for your reply.

            It seems like that python2-josepy update is working. The only package left is the nodejs-builtins. Your package is behind the epel release package. I think an update to the latest version would solve the problem. 😉

            An update to nodejs-builtins from 0.0.7-1.el7.nuxref to 1.0.2-1.el7 is available.

          2. I upgraded it to 2.0.1; It is possible I broke things though. Please let me know and I’ll revert back to the version you suggested instead.

          3. Sorry for my late response…yes you broke things 😛

            —> Paket nodejs-builtins.noarch 0:0.0.7-1.el7.nuxref markiert, um aktualisiert zu werden
            –> Abhängigkeit npm(builtins) = 0.0.7 wird für Paket nodejs-validate-npm-package-name-2.2.2-1.el7.nuxref.noarch verarbeitet
            —> Paket nodejs-builtins.noarch 0:2.0.1-1.el7.nuxref markiert, um eine Aktualisierung zu werden
            –> Abhängigkeit npm(semver) >= 6.0.0 wird für Paket nodejs-builtins-2.0.1-1.el7.nuxref.noarch verarbeitet
            –> Abhängigkeitsauflösung beendet
            Fehler: Paket: nodejs-builtins-2.0.1-1.el7.nuxref.noarch (nuxref)
            Benötigt: npm(semver) >= 6.0.0
            Installiert: nodejs-semver-5.1.0-1.el7.nuxref.noarch (@nuxref)
            npm(semver) = 5.1.0
            Verfügbar: nodejs-semver-2.1.0-3.el7.noarch (epel)
            npm(semver) = 2.1.0
            Fehler: Paket: nodejs-validate-npm-package-name-2.2.2-1.el7.nuxref.noarch (@nuxref)
            Benötigt: npm(builtins) = 0.0.7
            Entfernen: nodejs-builtins-0.0.7-1.el7.nuxref.noarch (@nuxref)
            npm(builtins) = 0.0.7
            Aktualisiert durch: nodejs-builtins-2.0.1-1.el7.nuxref.noarch (nuxref)
            npm(builtins) = 2.0.1
            Verfügbar: nodejs-builtins-1.0.2-1.el7.noarch (epel)
            npm(builtins) = 1.0.2

  24. Nope not really.

    Fehler: Paket: python2-josepy-1.2.0-1.el7.noarch (epel)
    Benötigt: python2-setuptools

    It needs python2-setuptools but my system has python2-2-setuptools. 😉

  25. Thanks for all the hard work you did over the years, i have used your repo on Centos 7 for a while.
    im swithing to Centos 8 at the moment, and im wondering if you expect to start offering the repo for Centos 8 as well?

    1. I hope so soon. I apologize for not having done much. I just haven’t had much incentive to keep this thing going ?. It’s a lot of work to maintain for little reward. But comments like yours (implying that you did actually use it) are always nice.

  26. Any plans to support Fedora 31? Also I see the repo even on FC30 is somewhat behind the latest version.
    With my FC31 install python has been upgraded to ver 3 so I has to change the systemd files to explicitly run python2.

    1. You caught me red handed. ? Starting with FC30 (I think) they completely dropped Python 2 support. I hadn’t begun the massive overhaul to start re-figuring out Sabnzbd, CouchPotato, etc.. I’m just a one man team over here doing it for free and have just had other priorities at the time.

      No promises, but the goal would really be to start seeing what can get ported to python 3 and doing it.

        1. The problem is that Fedora 32 no longer supports Python 2.x which is the base of most systems. Other then NZBGet, there wouldn’t be much to prepare.

    1. I just put it in the repo now but it’s not tested yet. I need to update the HTML on the main page, but if you swap fc30 for say fc31 or fc32 or even el8 you should get the desired results. I’m still slowly updating the repositories with all of the new stuff.

      Edit: repo website update 🙂

      1. Got some time to test the latest repo. Fresh install of CentOS 8 (2004). Linked the nuxref repo el8. Installed python3. And finally ran : yum install –enablerepo=nuxref –enablerepo=nuxref-shared sabnzbd which errored out:

        # yum -y install sabnzbd
        Last metadata expiration check: 0:09:14 ago on Wed 09 Sep 2020 01:02:15 PM EDT.
        Error:
        Problem: cannot install the best candidate for the job
        – nothing provides dbus-python needed by sabnzbd-3.0.2-2.el8.nuxref.noarch
        – nothing provides python3-feedparser needed by sabnzbd-3.0.2-2.el8.nuxref.noarch
        (try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)

        Extra packages should be installed separately or are part of sabnzbd dep-s? Thx much!

        1. Dan,

          Thanks for all your help testing! Your report was very complimentary to another (source). Basically it comes down to: I think i fixed it now. 🙂

          • I didn’t realize that python3-feedparser doesn’t ship with EL8 (but does with all Fedora versions). I built it for EL8 and added it to the repo. That will fix that entry.
          • I built the unrar packages as well and am now hosting them; so that will no longer be a problem.
          • dbus-python I dropped as a Required RPM; I don’t feel it’s needed personally.

          Consider flushing your cache to pull in the new repo updates:

          sudo dnf clean all
          sudo dnf install sabnzbd
          
          1. hmm git this at install:

            error: lsetfilecon: (/var/lib/sabnzbd/admin, system_u:object_r:var_lib_t:s0) Operation not supported
            error: lsetfilecon: (/var/lib/sabnzbd/complete, system_u:object_r:var_lib_t:s0) Operation not supported
            error: lsetfilecon: (/var/lib/sabnzbd/email, system_u:object_r:var_lib_t:s0) Operation not supported
            error: lsetfilecon: (/var/lib/sabnzbd/incomplete, system_u:object_r:var_lib_t:s0) Operation not supported
            error: lsetfilecon: (/var/lib/sabnzbd/nzb_backups, system_u:object_r:var_lib_t:s0) Operation not supported
            error: lsetfilecon: (/var/lib/sabnzbd/scan, system_u:object_r:var_lib_t:s0) Operation not supported

            what is the problem?

          2. systemctl start sabnzbd fails and i see this in messages:

            Sep 10 10:28:26 leviathan python2[215874]: Sorry, requires Python 3.5 or above
            Sep 10 10:28:26 leviathan python2[215874]: You can read more at: https://sabnzbd.org/python3

            hmm I’ve installed python36 hmmmm

          3. And fixed it you have Sir! Install went w/o a hiccup. In addition to that, sabnzbd v3 booted fine with v2 conf. So, all’s good.

            Thanks a bunch for holding up providing these rpm-s. Saves a lot of hassle. Cup of coffee well deserved! 🙂 Cheers!

    1. It’s a bit of a bigger challenge because Python 3.x support is somewhat spotty for CentOS 7.x. I’ll look into it, but no promises only because i already foresee having to build a lot of packages to make it possible (for Python 3.x that aren’t otherwise available).

    1. That’s strange; What happens if you do follow through with the instructions… or even take it one step further:

      yum clean all --disablerepo=* --enablerepo=nuxref*
      
      1. I am running into the same issue. I ran the command above, then tried yum update again, same exact error.

        If I download the rpm directly and attempt to run “yum install” I get this error:
        ERROR You need to update rpm to handle:
        rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by nuxref-release-1.0.0-5.el7.nuxref .noarch
        RPM needs to be updated
        You could try running: rpm -Va –nofiles –nodigest

        1. I built the Centos 7.x 1.0.0-5 RPM using Fedora 32; that was probably my first mistake. The good news is, there is no difference between 1.0.0-4 and 1.0.0-5 anyway (for CentOS 7), so i just removed the newer RPM entirely. This should the repo error you and the previous user was getting.

          Let me know! 🙂

          1. Well, I ran the command to clear the nuxref metadata, but running yum update still thinsk there is a 1.0.0.5 release, now it just fails to download it and generates a different error.

            —————-
            Downloading packages:
            Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
            nuxref-release-1.0.0-5.el7.nux FAILED
            http://repo.nuxref.com/centos/7/en/x86_64/custom/nuxref-release-1.0.0-5.el7.nuxr ef.noarch.rpm: [Errno 14] HTTP Error 404 – Not Found
            Trying other mirror.
            To address this issue please refer to the below wiki article

            https://wiki.centos.org/yum-errors

            If above article doesn’t help to resolve this issue please use https://bugs.cent os.org/.

            Error downloading packages:
            nuxref-release-1.0.0-5.el7.nuxref.noarch: [Errno 256] No more mirrors to try.
            ———————

          2. Unfortunately the error you shared definitely identifies that your meta data hasn’t been entirely flushed because as your pointing out, it’s still looking for an rpm (that isn’t there).

            sudo yum clean all --disablerepo=* --enablerepo=nuxref*
            sudo yum update
            

            give it one more try and let me know 🙂

          3. Hey,
            I’m also having the same issue. Followed all the steps by disabling repos, just enabling nuxref. Cleared the yum cache.
            I’ve also tried manually removing nuxref and reinstalling that didn’t seem to help at all still erroring out at the same place. It really wants to download that updated nuxref-release 😀

            Thanks.

  27. Hey,

    I’ve flushed all the metadata, done yum clean multiple times, tried disabling nuxref removing it, reinstalling it.. and I am still getting the error where it is looking for 1.0.0-5 for el7.

    Not sure if there is anything else i can try.

    Thanks!

    1. Sorry that you’re having all of these troubles. I’ve actually move nuxref to another server (behind the scenes). I didn’t realize i was no longer building the repo meta data properly. I think I’ve fixed it now :). Try clearing your meta data again (hopefully for the final try) and give it another go; keep me posted.

        1. Okay, i set up a CentOS 7 VM and made what should be the final change i need to on my end. This time i even tested it through the VM. These words are getting repetitive at this point, but i truly thank you for hanging in there and helping me out. Give it another cache clean and one more try. This should be the final time.

  28. trying to install on centos 8 and this is the error i get

    rpm -Uhi http://repo.nuxref.com/centos/8/en/x86_64/custom/nuxref-release-1.0.0-5.el8.nuxref.noarch.rpm
    warning: /var/tmp/rpm-tmp.n0UZPM: Header V4 RSA/SHA1 Signature, key ID efe82e3b: NOKEY
    ################################# [100%]
    ################################# [100%]
    Updating / installing…
    ################################# [100%]
    error: can’t create transaction lock on /var/lib/rpm/.rpm.lock (Resource temporarily unavailable)
    error: /etc/pki/rpm-gpg/RPM-GPG-KEY-nuxref-com: key 1 import failed.
    [root@pumba usr]# dnf install -y sabnzbd
    RHEL 8 – nuxref.com 19 kB/s | 3.9 kB 00:00
    Errors during downloading metadata for repository ‘nuxref’:
    – Status code: 404 for http://repo.nuxref.com/centos/8/en/x86_64/custom/repodata/repomd.xml (IP: 165.22.234.27)
    Error: Failed to download metadata for repo ‘nuxref’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

    1. Clear your cash and try it one more time; this is a result of a lot of serverside changes that occurred on my side. I’ve re-generated the file in question manually; you should be good to go (you may need to clear your dnf cache first though). Thank you for your patients!

Leave a Reply

Your email address will not be published. Required fields are marked *

Linux Solutions