* Remove .gitreview and switch to pulling the main asterisk branch
version from configure.ac instead.
* Replace references to JIRA with GitHub.
* Other minor cleanup found along the way.
Resolves: #39
(cherry picked from commit 5c6d5ea38f)
* All of the code that used subversion has been removed.
* When Asterisk is checked out from a tag or commit instead
of one of the regular branches, git would emit messages like
"fatal: ref HEAD is not a symbolic ref" which weren't fatal
at all. Those are now suppressed.
Change-Id: I2a11bc9ebbaf6dfa50f53516ede50a6bac65ca3c
(cherry picked from commit bbec5d1a99)
make_version now silently checks if the required git commands will
fail. If they do, then return UNKNOWN__git_check_fail to
distinguish this failure from other UNKNOWN__ version failures
Makefile checks for this value on install and exits out with
instructions
ASTERISK-30029
Change-Id: If8f10cac8f509c08981120f17555762342020221
Recap from earlier commit: If you have a development branch for a
major project that will receive gerrit reviews it'll probably be
named something like "development/16/newproject" or a work branch
based on that "development" branch. That will necessitate
setting "defaultbranch=development/16/newproject" in .gitreview.
The make_version script uses that variable to construct the
asterisk version however, which results in versions
like "GIT-development/16/newproject-ee582a8c7b" which is probably
not what you want. It also constructs the URLs for downloading
external modules with that version, which will fail.
Fast-forward:
The earlier attempt at adding a "basebranch" variable to
.gitreview didn't work out too well in practice because changes
were made to .gitreview, which is a checked-in file. So, if
you wanted to rebase your work branch on the base branch, rebase
would attempt to overwrite your .gitreview with the one from
the base branch and complain about a conflict.
This is a slighltly different approach that adds three methods to
determine the mainline branch:
1. --- MAINLINE_BRANCH from the environment
If MAINLINE_BRANCH is already set in the environment, that will
be used. This is primarily for the Jenkins jobs.
2. --- .develvars
Instead of storing the basebranch in .gitreview, it can now be
stored in a non-checked-in ".develvars" file and keyed by the
current branch. So, if you were working on a branch named
"new-feature-work" based on "development/16/new-feature" and wanted
to push to that branch in Gerrit but wanted to pull the external
modules for 16, you'd create the following .develvars file:
[branch "new-feature-work"]
mainline-branch = 16
The .gitreview file would still look like:
[gerrit]
defaultbranch=development/16/new-feature
...which would cause any reviews pushed from "new-feature-work" to
go to the "development/16/new-feature" branch in Gerrit.
The key is that the .develvars file is NEVER checked in (it's been
added to .gitignore).
3. --- Well Known Development Branch
If you're actually working in a branch named like
"development/<mainline_branch>/some-feature", the mainline branch
will be parsed from it.
4. --- .gitreview
If none of the earlier conditions exist, the .gitreview
"defaultbranch" variable will be used just as before.
Change-Id: I1cdeeaa0944bba3f2e01d7a2039559d0c266f8c9
If you have a development branch for a major project that
will receive gerrit reviews it'll probably be named something
like "development/16/newproject". That will necessitate setting
"defaultbranch=development/16/newproject" in .gitreview. The
make_version script uses that variable to construct the asterisk
version however, which results in versions like
"GIT-development/16/newproject-ee582a8c7b" which is probably not
what you want. Worse, since the download_externals script uses
make_version to construct the URL to download the binary codecs
or DPMA. Since it's expecting a simple numeric version, the
downloads will fail.
To get this to work, a new variable "basebranch" has been added
to .gitreview and make_version has been updated to use that instead
of defaultversion:
.gitreview:
defaultbranch=development/16/myproject
basebranch=16
Now git-review will send the reviews to the proper branch
(development/16/myproject) but the version will still be
constructed using the simple branch number (16).
If "basebranch" is missing from .gitreview, make_version will
fall back to using "defaultbranch".
Change-Id: I2941a3b21e668febeb6cfbc1a7bb51a67726fcc4
Fix the sed(1) invocation used to process git-svn-id not to use "\s"
that is a GNU-ism and is not supported by NetBSD sed. As a result,
this call did not work properly and make_version did output the full
git-svn-id line rather than the revision.
ASTERISK-29852
Change-Id: Ie4b406e2748920643446851a0a252a4ca7245772
Use .gitreview defaultbranch setting to determine the mainline branch.
This allows the script to be used against other directories which might
not be on the same defaultbranch. This can be used by CI scripts to
report the testsuite version being used:
./build_tools/make_version ${TESTSUITE_DIR}
Change-Id: Ifdad4a9d8a26138c41bc6b630ecc3e34ea1c2758
The DPMA and g729a, silk, siren7 and siren14 codecs hosted at
http://downloads.digium.com/pub/telephony/ are now listed in the
"External" sections of the "Resource Modules" and "Codec Translators"
pages in menuselect. Any that are selected will automatically be
downloaded and installed when "make install" is run. Their LICENSE and
README (if avaialble) files will be installed to
ASTVARLIBDIR/documentation/thirdparty/<product_name>.
Example use with codecs:
The codecs/codecs.xml file is a menuselect style xml file that lists
the codecs to be included. Their support levels are 'external', which
triggers the download and install, and defaultenabled is no. Also
because codec_g729a is actually in a directory named codec_g729 on the
download server, the newly added 'member_data' element is used to
override the default of the directory name being the package name. You
can use the 'directory_name' attribute to keep default base URL
(http://downloads.digium.com/pub/telephony/) but use the new directory,
or you use the 'remote_url' attribute to specify a full URL to the
download directory. In this case, you must still follow the same
subdirectory naming conventions as that used for the packages located
at 'http://downloads.digium.com/pub/telephony'.
A new configure option '--with-externals-cache' was added and like
'--with-sounds-cache' it allows the installer to cache tarballs so
they're not downloaded every time.
To assist with the download and install process, each external package
now has a manifest.xml file that, among other things, contains a package
version and checksums for each file in the tarball. The manifest is
saved to both the cache directory and ASTMODDIR and together with the
manifest.xml on the downloads site, tells the install scripts whether
a download and/or update is needed.
bash and xmlstarlet are required for downloader operation. If they're
not installed, the external items in menuselect will be unavailable.
Change-Id: Id3dcf1289ffd3cb0bbd7dfab3cafbb87be60323a
External systems - such as the Asterisk Test Suite - require knowledge of the
upstream branch. Unfortunately, after moving to Git, the Asterisk version
currently consists of only a 'GIT" prefix followed by an object blob,
e.g., GIT-as08d7. This makes it difficult for such systems to know what
features are available in a particular check out of Asterisk.
This patch fixes this by hardcoding the branch in a variable in the
make_version script. Since the mainline branches are not changed often -
typically only once a year - this is a reasonable approach to solving
the problem, and is more reliable than parsing the output of 'git branch
-vv'. Branches that track off of an upstream primary branch will then get the
benefit of knowing which mainline branch they are currently based off
of.
ASTERISK-24954 #close
Change-Id: I8090d5d548b6d19e917157ed530b914b7eaf9799
Make git more attractive for managing work-in-progress. Especially
convenient when a potential patch set needs to be tested on multiple
platforms since one can use git to keep all the test environments in sync
independent of a subversion server.
Now the Asterisk version will show the exact git SHA5 that was used when
building (still appended by "M" if there are local modifications) from a
git clone of the Asterisk repository so the developer can more easily know
what is actually under test.
You will now get this:
$ asterisk -V
Asterisk GIT-1698298
Instead of this:
$ asterisk -V
Asterisk UNKNOWN__and_probably_unsupported
This has zero impact for those not using git with the exception of an
extra test in the configure script to gather git's path. This is
necessary to prevent "sudo make install" from failing since git may not be
in the path in make's shell environment.
(closes issue ASTERISK-20483)
Reported by: Shaun Ruffell
Patches:
0001-build_tools-Allow-Asterisk-to-report-git-SHAs-in-ver.patch (license #5417) patch uploaded by Shaun Ruffell
Modified
........
Merged revisions 375189 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375190 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375191 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375192 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Certain branches, such as Certified Asterisk, may have a modifier added to
them that specifies the features available in that branch. For branches, this
modifier is expected to be reflected in the location of the branch in
subversion. For example, a subversion of URL of /certified/branches/1.8.11
would have a feature modifier of 'certified'. This is slightly different then
how features are determined for tags, where the feature is part of the actual
tag name, e.g., "10.5.0-digiumphones".
In keeping with the nomenclature used for tags, the feature specifier for
branches is translated and placed after the revision numbers. For the example
given previously, this would result in a branch version of
"Asterisk SVN-branch-1.8.11-cert-rXXXXXX".
........
Merged revisions 368604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368605 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r93180 | kpfleming | 2007-12-16 22:44:51 -0800 (Sun, 16 Dec 2007) | 23 lines
In http://lists.digium.com/pipermail/asterisk-dev/2007-December/031145.html,
rizzo brought up some issues related to the way that the metadata required
for menuselect and the rest of the build system is extracted from the source
files. Since I had a few hours to kill on an airplane today, I decided to
improve this situation... so now the system caches the extracted metadata
and uses it to build the menuselect 'tree' as much as it can. The result
of this is that when a single source file is changed, only the metadata for
that file needs to be extracted again, and the rest is used from the cache
files. I also reduced the number of forked processes required to do the
metadata extraction; it was actually possible to do most of what we needed
in the Makefiles themselves without using any shell scripts at all! On my
laptop, these changes resulted in an 80% decrease in the time required
for the 'menuselect.makeopts' automatic check to occur after editing a single
source file.
While doing this work I also cleaned up a few minor things in the Makefiles,
adding a check for 'awk' to the configure script and changed all remaining
places we use 'grep' or 'awk' to use the ones found by the configure script,
and changed the 'prep_tarball' script to build the menuselect metadata so
that tarballs of Asterisk will include it and won't require the user to
wait while it is extracted after unpacking.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@93184 65c4cc65-6c06-0410-ace0-fbb531ad65f3