Project

General

Profile

Bug #2524

building osmocom projects prints tons of bumpversion usage information

Added by laforge 7 months ago. Updated 7 months ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
10/01/2017
Due date:
% Done:

100%

Spec Reference:

Description

When building any osmocom project (from libosmocore on) the make output is interspersed with many instances of

usage: bumpversion [-h] [--config-file FILE] [--verbose] [--list]
                   [--allow-dirty] [--parse REGEX] [--serialize FORMAT]
                   [--search SEARCH] [--replace REPLACE]
                   [--current-version VERSION] [--dry-run] --new-version
                   VERSION [--commit | --no-commit] [--tag | --no-tag]
                   [--tag-name TAG_NAME] [--message COMMIT_MSG]
                   part [file [file ...]]
bumpversion: error: the following arguments are required: --new-version, part

What is going on here? I'm not tagging a new release or bumping any versions. I'm just doing a normal build, and that should neither need bumpversion, nor call it in a way that is a syntax violation that spews help texts to stdout/stderr.

This entire bumpversion story is going on for months now. I had to create Debian packages for it to fix builds. Now this. Honestly, I'm very close to reverting "Change-Id: I790ceb958195b9f6cbabfe8c977dc30e2bd7414b" and related follow-up commits.

Local environment:

bumpversion: v0.5.3 (using Python v3.5.4)

History

#1 Updated by msuraev 7 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

Fix is under review in gerrit 3973.

#2 Updated by msuraev 7 months ago

The debian package for bumpversion are not needed anymore as of libosmocore 98f6482ec7eb603b17e5a99fb92d28c17fcf61e9.
The reason for those error messages is that we call bumpversion outside of release target to populate variables (aither make does not allow such calls from inside the target or I did not manage to find a way to do it). Those error messages are harmless (although they might indicate that smth is wrong with the release version/tags) but unnecessary and confusing so the patch to suppress them is available for 2 weeks already.

#3 Updated by msuraev 7 months ago

Gerrit 4127 will fix it too.

#4 Updated by msuraev 7 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Gerrit 4127 has been merged.

#5 Updated by laforge 7 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF