Overview
Request 477697 accepted
- Fix SLE 11 build.
- update to version 2.1.10:
* Fixed bug in reporting named parse results for ZeroOrMore
expressions, thanks Ethan Nash for reporting this!
* Fixed behavior of LineStart to be much more predictable.
LineStart can now be used to detect if the next parse position is
col 1, factoring in potential leading whitespace (which would
cause LineStart to fail). Also fixed a bug in col, which is used
in LineStart, where '\n's were erroneously considered to be column
1.
* Added support for multiline test strings in runTests.
* Fixed bug in ParseResults.dump when keys were not strings. Also
changed display of string values to show them in quotes, to help
distinguish parsed numeric strings from parsed integers that have
been converted to Python ints.
- update to version 2.1.9:
* Added class CloseMatch, a variation on Literal which matches
"close" matches, that is, strings with at most 'n' mismatching
characters.
* Fixed bug in Keyword.setDefaultKeywordChars(), reported by
Kobayashi Shinji - nice catch, thanks!
* Minor API change in pyparsing_common. Renamed some of the common
expressions to PEP8 format (to be consistent with the other
pyparsing_common expressions):
+ signedInteger -> signed_integer
+ sciReal -> sci_real
Also, in trying to stem the API bloat of pyparsing, I've copied
some of the global expressions and helper parse actions into
pyparsing_common, with the originals to be deprecated and removed
Request History
tbechtold created request
- Fix SLE 11 build.
- update to version 2.1.10:
* Fixed bug in reporting named parse results for ZeroOrMore
expressions, thanks Ethan Nash for reporting this!
* Fixed behavior of LineStart to be much more predictable.
LineStart can now be used to detect if the next parse position is
col 1, factoring in potential leading whitespace (which would
cause LineStart to fail). Also fixed a bug in col, which is used
in LineStart, where '\n's were erroneously considered to be column
1.
* Added support for multiline test strings in runTests.
* Fixed bug in ParseResults.dump when keys were not strings. Also
changed display of string values to show them in quotes, to help
distinguish parsed numeric strings from parsed integers that have
been converted to Python ints.
- update to version 2.1.9:
* Added class CloseMatch, a variation on Literal which matches
"close" matches, that is, strings with at most 'n' mismatching
characters.
* Fixed bug in Keyword.setDefaultKeywordChars(), reported by
Kobayashi Shinji - nice catch, thanks!
* Minor API change in pyparsing_common. Renamed some of the common
expressions to PEP8 format (to be consistent with the other
pyparsing_common expressions):
+ signedInteger -> signed_integer
+ sciReal -> sci_real
Also, in trying to stem the API bloat of pyparsing, I've copied
some of the global expressions and helper parse actions into
pyparsing_common, with the originals to be deprecated and removed
jberry_factory added openSUSE:Leap:42.3:Staging:E as a reviewer
Being evaluated by staging project "openSUSE:Leap:42.3:Staging:E"
jberry_factory accepted review
Picked openSUSE:Leap:42.3:Staging:E
leaper added python-pyparsing as a reviewer
Submission for python-pyparsing by someone who is not maintainer in the devel project (devel:languages:python). Please review
leaper added leap-reviewers as a reviewer
leaper accepted review
ok
aplanas accepted review
lnussel accepted review
lnussel_factory accepted review
ready to accept
lnussel_factory approved review
ready to accept
lnussel_factory accepted request
Accept to openSUSE:Leap:42.3
@jberry , please add to adi:2
This package is a ring package so I staged in letter staging, but copied to adi:2 as well.
openSUSE:Factory/python-pyparsing@24 -> openSUSE:Leap:42.3/python-pyparsing
expected origin is 'SUSE:SLE-12:GA' (changed)
the submitted sources are in or accepted for Factory
request needs review by release management
@lnussel: adi2: is now green with the series of additional SRs (including this one). As noted in IRC will need to decide if changing the source from SLE to Factory is alright.
Why is this update needed? If it is needed how about updating it in SLE?
What about the 71 packages using python-pyparsing, is the update compatible so they continue to work?
@lnussel , - python-cliff needs a newer version - about the other 71 packages - according to the release notes I guess it is compatible but I haven't tested it in any way - How can I udate it for SLES? Do I not need an ECO for that? And asking as a openSUSE user, is that even possible as non-SUSE employee ?
And why do we need a python-cliff update? :-) I guess the real reason is preparation for something openstack related? What exactly?
If you ask as openSUSE user I'd tell you to file a bug which we forward internally or get in contact with the package maintainer. I can also tell you that for SLE @vuntz is package maintainer for python-pyparsing so he would be the one to talk to. Right now there is a chance to get things into SP3 still but the window is starting to close. So please submit there ASAP. SLE release management will ask similar questions to justify the update.
Most of the openstack clients python-openstackclient, python-heatclient, python-neutronclient, ...) need cliff>=2.3.0 . I try to get it into SLE12SP3