Bug 785869 - R2spec-4.0.0 uses Python 2.5+ syntax on el5 (Python 2.4)
Summary: R2spec-4.0.0 uses Python 2.5+ syntax on el5 (Python 2.4)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: R2spec
Version: el5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Pierre-YvesChibon
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-30 19:59 UTC by Shawn Lower
Modified: 2012-03-11 17:03 UTC (History)
1 user (show)

Fixed In Version: R2spec-4.1.0-1.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-10 17:31:54 UTC


Attachments (Terms of Use)
replaces the os.getlogin() call with the use of the $LOGNAME environment variable, or pwd.getpwduid(os.getuid())[0] if that fails. (1.12 KB, patch)
2012-02-09 20:50 UTC, Shawn Lower
no flags Details | Diff
friendlier error message when R2spec is called without any arguments (1.81 KB, patch)
2012-02-09 20:51 UTC, Shawn Lower
no flags Details | Diff
change tries os.getlogin() but falls back to using either the $LOGNAME environment variable, or pwd.getpwduid(os.getuid())[0] (1.44 KB, patch)
2012-02-11 01:22 UTC, Shawn Lower
no flags Details | Diff

Description Shawn Lower 2012-01-30 19:59:56 UTC
Description of problem:

R2spec 4.0.0 uses the 'with' statement, which was introduced in Python 2.5.

el5 comes with Python 2.4. This causes errors when running either R2spec or R2rpm.


Version-Release number of selected component (if applicable):

R2spec-4.0.0-1.el5

How reproducible:

Always fails on el5

Steps to Reproduce:
1. Install latest R2spec package on el5
2. run either R2spec/R2rpm
3. receive traceback below:
  
Actual results:

[ip-xxx ~/projec..ackages/mockBuilt/pracma (1070)] $ R2spec
Traceback (most recent call last):
  File "/usr/bin/R2spec", line 22, in ?
    from r2spec.r2spec_obj import R2spec, setup_parser
  File "/usr/lib/python2.4/site-packages/r2spec/r2spec_obj.py", line 111
    with open(configfile, 'w') as conf:
            ^
SyntaxError: invalid syntax
[ip-xxx ~/projec..ackages/mockBuilt/pracma (1071)] $ R2rpm
Traceback (most recent call last):
  File "/usr/bin/R2rpm", line 22, in ?
    from r2spec.r2spec_obj import R2rpm, setup_parser
  File "/usr/lib/python2.4/site-packages/r2spec/r2spec_obj.py", line 111
    with open(configfile, 'w') as conf:
            ^
SyntaxError: invalid syntax



Expected results:


Additional info:

R2spec-3.0.3-1.el5.noarch works fine. I guess R2spec-4.0.0 shouldn't be in the el5 branch of EPEL?

Comment 1 Pierre-YvesChibon 2012-02-05 19:28:58 UTC
Thanks for the report.

I think I can fix this, would you be willing to test from the git version once I have pushed a patch ?
I do not have an EL5 at the moment.

Comment 2 Shawn Lower 2012-02-06 15:39:29 UTC
Sure. I'd be happy to test it from git. Just let me know when you've pushed the patch and I'll try it out.

Comment 3 Pierre-YvesChibon 2012-02-07 09:51:34 UTC
I just pushed something that should fix the problem, however I see the tests are not passing at the moment, I believe I forgot to push some commits :-(

Comment 4 Shawn Lower 2012-02-09 20:50:41 UTC
Created attachment 560705 [details]
replaces the os.getlogin() call with the use of the $LOGNAME     environment variable, or pwd.getpwduid(os.getuid())[0] if that fails.

Comment 5 Shawn Lower 2012-02-09 20:51:25 UTC
Created attachment 560706 [details]
friendlier error message when R2spec is called without any arguments

Comment 6 Shawn Lower 2012-02-09 20:53:51 UTC
Great, that works! .. with caveats. I ran across a strange issue when running it under tmux (a terminal multiplexer similar to GNU Screen). It seems that when running under tmux, an entry isn't created in /var/run/utmp, so the call to os.getuser() raises an exception. I made a change (patch 0001) to just use the $LOGUSER variable instead (if it's set), and that seems to have fixed it.

I also added a friendlier error message for when R2spec/R2rpm are called without any arguments (p0002).


The error under tmux looks like this:


[ip-xxxxx ~/projects/R2spec/r2spec (1215)] $ ./R2spec 
Traceback (most recent call last):
  File "./R2spec", line 22, in ?
    from r2spec.r2spec_obj import R2spec, setup_parser
  File "/h/slower/projects/R2spec/r2spec/r2spec/r2spec_obj.py", line 128, in ?
    class Settings(object):
  File "/h/slower/projects/R2spec/r2spec/r2spec/r2spec_obj.py", line 131, in Settings
    packager = os.getlogin()
OSError: [Errno 2] No such file or directory

Comment 7 Pierre-YvesChibon 2012-02-09 21:18:41 UTC
(In reply to comment #6)
> Great, that works! ..

So it did work ? Cool :)

>with caveats. I ran across a strange issue when running
> it under tmux (a terminal multiplexer similar to GNU Screen). It seems that
> when running under tmux, an entry isn't created in /var/run/utmp, so the call
> to os.getuser() raises an exception. I made a change (patch 0001) to just use
> the $LOGUSER variable instead (if it's set), and that seems to have fixed it.

hm what about doing a try/except around the os.getuser() ?
As I expect os.getuser() to work most often.

Otherwise I like the patch :)

> I also added a friendlier error message for when R2spec/R2rpm are called
> without any arguments (p0002).

This is one of the things which I have on my laptop but haven't pushed yet, I'll see which of our solution is best, your might be simpler than what I tried.

Thanks for all this !

Comment 8 Pierre-YvesChibon 2012-02-10 22:37:29 UTC
Ok the latest version in git the unit-tests are finally all working (tested on Fedora and EL6).

The R2spec/R2rpm call without argument provides a nicer message.

If you could provide a new version of your first patch (on getuser()) rebased on the new code I could integrate it in the git :-)
(Maybe with the try/except mentioned above)

I would like to release 4.1.0 with all these changes soon (like this week-end or early next week), so feel free to poke at it and see if there are some release blocker remaining.

Thanks!

Comment 9 Shawn Lower 2012-02-11 01:21:28 UTC
Ok, I tried it on a couple RHEL5 machines. I was able to generate a specfile or RPM package outside of tmux with no patches, and in tmux with the attached patch.

On one very old machine, I had trouble with the following:

$ ./R2spec --sources ~/rpmbuild/SOURCES/RUnit_0.4.22.tar.gz                                                                                                                                            
Traceback (most recent call last):
  File "./R2spec", line 29, in ?
    R2spec().main(ARG)
  File "/h/slower/projects/R2spec/r2spec/r2spec/r2spec_obj.py", line 276, in main
    pack.extract_sources()
  File "/h/slower/projects/R2spec/r2spec/r2spec/rpackage.py", line 142, in extract_sources
    tar.extractall()
AttributeError: 'TarFile' object has no attribute 'extractall'


It seems 'extactall' was added in Python 2.5, but it was backported to 2.4 during a security update that Red Hat pushed out in RHBA-2010:0724. The filename is:

python-2.4.3-27.el5_5.2.x86_64.rpm

Again, that only affects systems that haven't had python updated since that errata was issued, back in September 2010. All the semi-recently updated systems worked fine. Other than that, looks good!

https://rhn.redhat.com/rhn/errata/details/Details.do?eid=10249

Thanks

Comment 10 Shawn Lower 2012-02-11 01:22:29 UTC
Created attachment 561027 [details]
change tries os.getlogin() but falls back to using either the $LOGNAME environment variable, or pwd.getpwduid(os.getuid())[0]

Comment 11 Pierre-YvesChibon 2012-02-11 10:21:36 UTC
Ok I have pushed your patch and started to prepare the release.

I added the following line to the spec file to circumvent the problem you mentioned:
Requires:       python >= python-2.4.3-27


Thanks for all your testing!

Comment 12 Fedora Update System 2012-02-14 20:52:31 UTC
R2spec-4.1.0-1.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/R2spec-4.1.0-1.el5

Comment 13 Fedora Update System 2012-02-14 20:52:40 UTC
R2spec-4.1.0-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/R2spec-4.1.0-1.fc16

Comment 14 Fedora Update System 2012-02-14 20:52:49 UTC
R2spec-4.1.0-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/R2spec-4.1.0-1.fc15

Comment 15 Fedora Update System 2012-02-14 20:52:58 UTC
R2spec-4.1.0-1.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/R2spec-4.1.0-1.el6

Comment 16 Fedora Update System 2012-02-14 20:53:06 UTC
R2spec-4.1.0-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/R2spec-4.1.0-1.fc17

Comment 17 Fedora Update System 2012-02-15 01:20:23 UTC
Package R2spec-4.1.0-1.el6:
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing R2spec-4.1.0-1.el6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0468/R2spec-4.1.0-1.el6
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2012-03-10 17:31:54 UTC
R2spec-4.1.0-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2012-03-10 17:32:04 UTC
R2spec-4.1.0-1.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2012-03-10 21:52:07 UTC
R2spec-4.1.0-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2012-03-10 21:55:56 UTC
R2spec-4.1.0-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2012-03-11 17:03:40 UTC
R2spec-4.1.0-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.