Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 447406 - gentoolkit issue, regular expression parsing of dev-libs/libsigc++-2.2.11, query.smart_find
Summary: gentoolkit issue, regular expression parsing of dev-libs/libsigc++-2.2.11, qu...
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Third-Party Tools (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage Tools Team
Depends on:
Blocks: 346443 445502
  Show dependency tree
Reported: 2012-12-16 01:28 UTC by Mike Pagano
Modified: 2013-09-05 17:18 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

Test program to show the issue (,426 bytes, text/plain)
2012-12-16 01:28 UTC, Mike Pagano

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Pagano gentoo-dev 2012-12-16 01:28:05 UTC
Created attachment 332430 [details]
Test program to show the issue

I get an issue when which query.smart_find when passed dev-libs/libsigc++-2.2.11

I have attached a small test program to show the issue.

The output is:

Traceback (most recent call last):
  File "./", line 15, in <module>
    packages = query.smart_find(True,True,True,True,False,True)
  File "/usr/lib64/python2.7/site-packages/gentoolkit/", line 169, in smart_find
    matches = self._do_complex_lookup(show_progress=show_progress)
  File "/usr/lib64/python2.7/site-packages/gentoolkit/", line 333, in _do_complex_lookup
    result = [x for x in pre_filter if predicate(x)]
  File "/usr/lib64/python2.7/site-packages/gentoolkit/", line 325, in <lambda>
    predicate = lambda x:, x)
  File "/usr/lib64/python2.7/", line 142, in search
    return _compile(pattern, flags).search(string)
  File "/usr/lib64/python2.7/", line 242, in _compile
    raise error, v # invalid expression
sre_constants.error: multiple repeat
Comment 1 Paul Varner (RETIRED) gentoo-dev 2012-12-26 21:18:35 UTC
It works if you change:

query = Query(package_name, True)
query = Query(package_name, False)

However, I see that it raises an InvalidCPV exception if you set it to True and pass a valid regular expression.  So it is definitely seems like it is not working like it supposed to.
Comment 2 Paul Varner (RETIRED) gentoo-dev 2013-01-04 22:28:14 UTC
This is fixed in the following commit.;a=commit;h=de264bbe75fe45ff7d457343a8a8a5f96cd14a7f

Note: If you tell smart_find to do a regular expression search, you do need to make sure you pass a valid regular expression or it will raise a GentoolkitInvalidRegex exception.
Comment 3 C W Rose 2013-01-16 09:18:10 UTC
Mike, with reference to your message on the forums I don't know if we've
hit the same problem, but I ran some rough tests on equery by attaching
the Python code below to gentoolkit's, and the combination of '*"
and '-' produced the "Invalid CPV error".  (This was under Python 2.7).

Running the code under winpdb I can see the call to split_cpv treating
the '-' as a package name/version separator, and then returning an
invalid name response from isvalid_pkg_name, but my Python isn't up
to digging deeper.

Interestingly, the formal tests in mention a problem with '-',
not including '*', and a bug report 316961.

I get the same result however I try reconfiguring the regexp.

# Rough test of - attach the code to the end of
def main(argv=None):
    print "main() running"
    # Sample tests from
    cpv = CPV('sys-apps/portage-2.2-r1')
    print cpv.category,, cpv.fullversion # 'sys-apps portage 2.2-r1'
    print str(cpv) # 'sys-apps/portage-2.2-r1'
    # Local tests.
    cpv = CPV('x11-libs/qt-meta-4.8')
    print cpv.category,, cpv.fullversion
    print str(cpv)
    cpv = CPV('*qt*')
    print cpv.category,, cpv.fullversion
    print str(cpv)
    cpv = CPV('*qt-meta*')
    print cpv.category,, cpv.fullversion
    print str(cpv)
    return 0

if __name__ == "__main__":

# eof
Comment 4 Andreas Sturmlechner gentoo-dev 2013-02-17 14:55:25 UTC
I confirm that gentoolkit-9999 does not crash over dev-libs/libsigc++ anymore.

What remains is another problem already mentioned in bug 445502, portpeek now reads


and lists it as 'Not Installed', while in fact it is. Back with gentoolkit-, changing ~ to = solved the problem - I didn't try that out yet as portpeek is still running: Queries seem to take much, much longer with gentoolkit-9999 right now, I've already had three cups of coffee in the meantime.
Comment 5 Paul Varner (RETIRED) gentoo-dev 2013-09-05 17:18:25 UTC
Released in gentoolkit-