Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #5472

Closed
Open
Opened Mar 25, 2012 by neena@neena

Stem version parser matches git hash too

Stem's version parser considers the (git-hash) from tor --version output as a part of the version.

Ex: (git-65420e4cb5edcd02) in Tor version 0.2.3.10-alpha-dev (git-65420e4cb5edcd02).

I have fixed this and added a test for get_system_tor_version.

I also made the regex stricter by having it reject version strings whose status_tags have a space in them and properly matching the dot between version integers (. instead of .).

My branch with these fixes -- http://repo.or.cz/w/stem/neena.git/shortlog/refs/heads/fix-version-parsing

Right now, this breaks a few other things. Primarily because GETINFO version returns this:

250-version=0.2.3.10-alpha-dev (git-65420e4cb5edcd02)

One way to fix this would be to stop at the first space in runner.get_tor_version too. I'm going to do that unless someone suggests something better.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#5472