letsencrypt also needs psutil >= 2.1.0, so I'd appreciate an upgrade for that as well. We have no tracker bug for letsencrypt in EPEL7 yet.

I have been able to get psutil 2.1.3 to build on EPEL7 [1], but I have not checked the effect of the upgrade with its reverse-dependencies yet. From reading the changelog [2], API has been changed in 2.0, but continues to work raising DeprecationWarnings. Deprecated APIs have been removed in 3.0 though.

[1] https://copr.fedoraproject.org/coprs/rbu/letsencrypt/build/144751/
[2] https://github.com/giampaolo/psutil/blob/master/HISTORY.rst#200---2014-03-10

I've audited the packages depending on python-psutil on their usage changed APIs in 1.0 to 2.0.

I only looked at fedmsg and pagure, Fabian can you please check whether the current EPEL7 glances would be ready for a newer psutil or could we possibly coordinate a python-psutil upgrade with a glances upgrade?
 

[root@el7 ~]# repoquery --whatrequires python2-psutil
glances-0:1.7.7-1.el7.noarch
pagure-0:0.1.31-1.el7.noarch
python-fedmsg-commands-0:0.16.2-2.el7.noarch
python-fedmsg-consumers-0:0.16.2-2.el7.noarch


(1) Glances, haven't checked. See bug 1285999. Hopefully Fabian can help?



(2) fedmsg can be upgraded

It's usage of an API that changed in psutil 2.0 (Process().name is now Process().name()) actually handles the old and the new variant, incorrectly referencing to a Python 2.6/2.7 change.
Here's the relevant portions of the code (this covers all usage of psutil in the package, modulo requirements):


fedmsg-0.16.2-2.el7.src/fedmsg-0.16.2/fedmsg/commands/__init__.py
87-        pid = pidlock.read_pid()
88:        if pid and not psutil.pid_exists(pid):
89-            self.log.warn("PID file exists but with no proc:  coup d'etat!")
90-            pidlock.break_lock()

fedmsg-0.16.2-2.el7.src/fedmsg-0.16.2/fedmsg/consumers/__init__.py
117-            # Extract proc name and handle differences between py2.6 and py2.7
118:            proc_name = current_proc().name
119:            if callable(proc_name):
120:                proc_name = proc_name()
--
263-def current_proc():
264-    mypid = os.getpid()
265-
266:    for proc in psutil.process_iter():
267-        if proc.pid == mypid:
268-            return proc


(3) pagure is currently NOT ready for the new psutil
Unfortunately, this is also true for pagure in Fedora (23, rawhide).

So this bug should be fixed in rawhide, ideally supporting old and new API. 
If the code looks similar, it was actually copied from fedmsg.

pagure-0.1.31-1.el7.src/pagure-0.1.31/pagure/mail_logging.py
71:        current_process = ContextInjector.get_current_process()
72-        current_hostname = socket.gethostname()
73-
74-        record.host = current_hostname
75:        record.proc = current_process
76-        record.pid = '-'
77:        if not isinstance(current_process, str):
78:            record.pid = current_process.pid
79:            record.proc_name = current_process.name
80:            record.command_line = " ".join(current_process.cmdline)
81-        record.callstack = self.format_callstack()
--
122-    @staticmethod
123:    def get_current_process():
124-        """ Return the current process (PID). """
125-        mypid = os.getpid()
126-
127:        if not psutil:
128:            return "Could not import psutil for %r" % mypid
129-
130:        for proc in psutil.process_iter():
131-            if proc.pid == mypid:
132-                return proc

@python-psutil maintainer, if we get pagure fixed and glances checks out ok/will be updated, would you update python-psutil to a later version?

For pagure, I have opened https://pagure.io/pagure/issue/524.

Yes!  Let's do it.

Pagure is under active development, so we should be able to fix it.

I'll go ahead and update python-psutil in epel-testing.  Let's leave it there for a while to see if any other bugs pop up.

python-psutil-2.2.1-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-eead4a588c

Ralph, thanks a lot for preparing the package.

Pingou, I wanted to bring you in to this discussion here. You raised the point of not breaking the API for third-party packages in the issue on pagure instance. From https://pagure.io/pagure/issue/524:
> While I'm fine with adjusting the code, the policy for EPEL will probably
> prevent you from doing the update as it will break any application using this 
> library, whether in the repo or not.
>
> A compat package seems a better way to update psutils in EPEL.

I don't know how wide usage of psutil might be outside of the packages in EPEL, so I don't have a strong opinion in this matter. How would you imagine a compat package to look like?

python-psutil-2.2.1-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'yum --enablerepo=epel-testing update python-psutil'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-eead4a588c

python-psutil-2.2.1-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.

Huh. For the record, this totally broke a little terminal util I wrote about a decade ago. (It might still be in use at Harvard, but I doubt it.)

Sorry, Matt.  :/

I wrote to epel-announce here https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/7RROO5S5AHYBXBFTMJNUD2HUR32RM6HX/ and intended to wait a while, but then the update got karma and I didn't disable the threshold.