- Update to version 3.5.3:

+ Line numbers in the HTML report line up better with the source lines, fixing
    issue 197
  + When specifying a directory as the source= option, the directory itself no
    longer needs to have a __init__.py file, though its subdirectories do, to
    be considered as source files.
  + Files encoded as UTF-8 with a BOM are now properly handled, fixing
    issue 179_.
  + Fixed more cases of non-Python files being reported as Python source, and
    then not being able to parse them as Python.  Closes issue 82 (again).
  + Fixed memory leaks under Python 3, thanks, Brett Cannon. Closes issue 147_.
  + Optimized .pyo files may not have been handled correctly, issue 195_.
  + Certain unusually named file paths could have been mangled during reporting,
    issue 194_.
  + Try to do a better job of the impossible task of detecting when we can't
    build the C extension, fixing issue 183_.
  + Testing is now done with tox
- Changes from version 3.5.2:
  + No changes since 3.5.2.b1
- Changes from version 3.5.2b1
  + The HTML report has slightly tweaked controls: the buttons at the top of
    the page are color-coded to the source lines they affect.
  + Custom CSS can be applied to the HTML report by specifying a CSS file as
    the extra_css configuration value in the [html] section.
  + Source files with custom encodings declared in a comment at the top are now
    properly handled during reporting on Python 2.  Python 3 always handled them
    properly.  This fixes issue 157_.
  + Backup files left behind by editors are no longer collected by the source=
    option, fixing issue 168_.
  + If a file doesn't parse properly as Python, we don't report it as an error

OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-coverage?expand=0&rev=20

python-coverage.changes

@@ -1,3 +1,51 @@
+-------------------------------------------------------------------
+Tue Nov 20 18:15:53 UTC 2012 - saschpe@suse.de
+
+- Update to version 3.5.3:
+  + Line numbers in the HTML report line up better with the source lines, fixing
+    issue 197
+  + When specifying a directory as the source= option, the directory itself no
+    longer needs to have a __init__.py file, though its subdirectories do, to
+    be considered as source files.
+  + Files encoded as UTF-8 with a BOM are now properly handled, fixing
+    issue 179_.
+  + Fixed more cases of non-Python files being reported as Python source, and
+    then not being able to parse them as Python.  Closes issue 82 (again).
+  + Fixed memory leaks under Python 3, thanks, Brett Cannon. Closes issue 147_.
+  + Optimized .pyo files may not have been handled correctly, issue 195_.
+  + Certain unusually named file paths could have been mangled during reporting,
+    issue 194_.
+  + Try to do a better job of the impossible task of detecting when we can't
+    build the C extension, fixing issue 183_.
+  + Testing is now done with tox
+- Changes from version 3.5.2:
+  + No changes since 3.5.2.b1
+- Changes from version 3.5.2b1
+  + The HTML report has slightly tweaked controls: the buttons at the top of
+    the page are color-coded to the source lines they affect.
+  + Custom CSS can be applied to the HTML report by specifying a CSS file as
+    the extra_css configuration value in the [html] section.
+  + Source files with custom encodings declared in a comment at the top are now
+    properly handled during reporting on Python 2.  Python 3 always handled them
+    properly.  This fixes issue 157_.
+  + Backup files left behind by editors are no longer collected by the source=
+    option, fixing issue 168_.
+  + If a file doesn't parse properly as Python, we don't report it as an error
+    if the filename seems like maybe it wasn't meant to be Python.  This is a
+    pragmatic fix for issue 82_.
+  + The -m switch on coverage report, which includes missing line numbers
+    in the summary report, can now be specifed as show_missing in the
+    config file.  Closes issue 173_.
+  + When running a module with coverage run -m <modulename>, certain details
+    of the execution environment weren't the same as for
+    python -m <modulename>.  This had the unfortunate side-effect of making
+    coverage run -m unittest discover not work if you had tests in a
+    directory named "test".  This fixes issue 155_.
+  + Now the exit status of your product code is properly used as the process
+    status when running python -m coverage run ....  Thanks, JT Olds.
+  + When installing into pypy, we no longer attempt (and fail) to compile
+    the C tracer function, closing issue 166_.
+
 -------------------------------------------------------------------
 Thu May 24 11:47:40 UTC 2012 - cfarrell@suse.com