Do not publish PDFs for all projects anymore with jenkins.sh --publish
or "make publish". Extract known_hosts from jenkins.sh, and install it
along with the other shared files in OSMO_GSM_MANUALS_DIR. Add a
"publish" target to Makefile.common.inc, so we can use it from the
project repositories. Document its usage in INSTALL.txt.
No automatism for building and publishing the documentation of all
projects will be implemented in this patch series, as discussed here:
https://osmocom.org/issues/3385#note-7
(moving manuals to project repositories 19/19)
Related: OS#3385
Change-Id: Ibe0424ceace151115985896b6d43035c69067c50
Everything is in place for 'make distcheck' now.
(moving manuals to project repositories 18/19)
Related: OS#3385
Change-Id: Ie31fba3d1afd31c25489ce08169101d9ed9de536
Necessary for 'make distcheck': the files will otherwise not end up in
the dist archives.
(moving manuals to project repositories 17/19)
Related: OS#3385
Change-Id: I5a2d6e572d346addc8770d1331c9223a56635869
Force the xsltproc output file to be writable, if it exists already.
This is needed for 'make distcheck': xsltproc gives output files the
same permissions as input files. We need to change the output file in
multiple iterations in vty_reference_combine.sh, hence it must be
writable.
(moving manuals to project repositories 15/19)
Related: OS#3385
Change-Id: I693e12ee15665d01cbc50187e6cb3ca74ad0356a
Includes from other projects don't work anymore when moving project
specific manuals into other repositories.
(moving manuals to project repositories 14/19)
Related: OS#3385
Change-Id: I96933dd4dd6cac159847647f1c642215051a9aad
Define a new {srcdir} variable in Makefile.asciidoc.inc, that can be
used in all adoc files. The value is the same as the Makefile variable
$(srcdir). Use {srcdir} in the "include::" lines of all adoc files.
(moving manuals to project repositories 13/19)
Related: OS#3385
Change-Id: I823e3d534cbc9ffceb68d3ab14c9f6710ff2eb2a
Makefile.asciidoc.inc: create a symlink for the root adoc file, from
which a PDF gets generated, from the srcdir to the builddir. This file
may include other adoc files, which do not get symlinked. We need to do
this, because a2x (the program generating the PDF file) does not have a
parameter for the output file, and will otherwise generate the PDF in
the srcdir instead of the builddir. Do the same in the check target, so
the relative include paths work the same.
Makefile.asciidoc.inc, Makefile.docbook.inc: set the include paths for
the xstl parser, as well as the LaTeX compiler, so they can find the
files they need from both OSMO_GSM_MANUALS_DIR and builddir.
Makefile.asciidoc.inc, Makefile.docbook.inc: refer to the output file
$@ with $(notdir $@). This removes the path from the file, like
basename from coreutils. The output file will then be placed in the
builddir instead of the srcdir.
Makefile.vty-reference.inc: use $(srcdir) in references to vty/*.xml
files.
(moving manuals to project repositories 12/19)
Related: OS#3385
Change-Id: Ie6b212a6518f0fc29fae610a37ae6c533189278d
Use $(srcdir) infront of all relative paths, which reference other
files in the repository. Use $(top_srcdir) as OSMO_GSM_MANUALS_DIR.
This is needed for out-of-tree building.
(moving manuals to project repositories 11/19)
Related: OS#3385
Change-Id: I2454d7507fae4e1c47458a1adf36f68e637f4bbc
Pass the path to $(srcdir)/vty/*reference.xml as parameter to
vty_reference_combine.sh instead of assuming that it will be in
./vty/*reference.xml.
This is necessary to make the build scripts work for out-of-tree
builds. Because when building out-of-tree, the source dir and build dir
(the one where the Makefile gets generated, and in which "make" runs),
are not the same anymore. The relative vty/reference.xml path is only
valid in the source dir, not in the build dir. The next commits in this
series have more changes for out-of-tree builds.
Out-of-tree building is necessary for consistency with the other
Osmocom code, which can be built out-of-tree as well. It would be
strange if this did not work anymore as soon as the users enabled
building the manuals.
(moving manuals to project repositories 10/19)
Related: OS#3385
Change-Id: I3dcb49d7705f882bd117088d4e5eab91dd1c7d8c
Change hardcoded ../common paths, which will break when moving the
project specific manuals in other repositories, to ./common so they
use the dynamically created symlink that always points to the right
path.
(moving manuals to project repositories 9/19)
Change-Id: I5368bcff34586c515af23e5a868417e561fd539d
Change hardcoded ../common paths, which will break when moving the
project specific manuals in other repositories, to ./common so they
use the dynamically created symlink that always points to the right
path.
(moving manuals to project repositories 8/19)
Related: OS#3385
Change-Id: Id984f5e85481f7877567ee6d21f7ca455d773ef1
$(OSMO_GSM_MANUALS_DIR) is used in most places to reference to the top
dir, which contains "build" and "common". But not in the asciidoc
mscgen filter configurations, and in the custom LaTeX style. They have
../common or ../build hardcoded, which won't work anymore when the
project specific files will be in another repository.
Update the Makefiles to create symlinks to "build" and "common" in the
dir where the build was started. Use ./common in the files that had
../common hardcoded, and do the same for ./build.
Update the Makefile.common.inc comment to refer to common targets in
general, so we don't need to list each single one there (like the new
'common' and 'build' targets).
I've also thought about using variables there, but this would only work
for the asciidoc files, not for the .sty file. We would need to
generate the latter from another file and replace the variable
dynamically. Having the symlinks instead seemed to be slightly easier.
(moving manuals to project repositories 7/19)
Related: OS#3385
Change-Id: I4cfd1a9ef482d382f10cdf060e8e2cba81852864
OSMO_GSM_MANUALS_DIR should use pkg-config to figure out the location
of the shared osmo-gsm-manuals files.
(moving manuals to project repositories 6/19)
Related: OS#3385
Change-Id: I64cfffb5104edcf7a20f41aeb5bf8ee6988b57c4
For reasoning why a transition to autotools is desired, see the commit
message of the previous patch in this series.
"make install" copies the "build", "common" dirs, as well as the "*.xsl"
files to $(prefix)/share/osmo-gsm-manuals. Prefix is typically
/usr/local. Also a pkg-config file gets installed, so the path of the
shared files can be looked up by autoconf scripts of the project
repositories. The check-depends script is installed to
$(prefix)/bin/osmo-gsm-manuals-check-depends and will be used by
project specific autoconf scripts, too.
All existing make targets ("make", "make check", "make upload") are
still working, users only need to run "autoreconf -fi" and
"./configure" beforehand.
Makefile.am uses custom install-data-hook and uninstall-local targets,
so we don't need to specify each file of the relevant subdirs in a
_DATA variable (no extra maintenance effort).
(moving manuals to project repositories 5/19)
Related: OS#3385
Change-Id: I8e7036fae062ee783cb132b14608827a82c5e7c7
Add the same version of git-version-gen, which most other Osmocom
repositories (libasn1c, libosmocore, libosmo-netif, libosmo-sccp, ...)
are using, so they behave the same.
git-version-gen generates a version string derived from the git
repository, or from a .tarball-version file when running outside of a
git directory. Unfortunatelly it seems to be impossible to use
git-version-gen from autoconf without adding it to the source tree.
Autotools will be used to install the shared manual files into the
system in a way that is consistent with the other Osmocom repositories:
$ autoreconf -fi
$ ./configure --prefix=/usr/local
$ make
$ make install
Project repositories will check with pkg-config if osmo-gsm-manuals is
installed (like any other shared Osmocom component), when a new
configure flag for building the manuals is passed. This will also work
with distribution's package managers, for instance we could have a
osmo-gsm-manuals-dev package in Debian on which the other packages
would have a build-time dependency to build the UNIX man pages
(OS#3386).
(moving manuals to project repositories 4/19)
Related: OS#3385
Change-Id: I34b0d20046417179250a5065574e2bc303889cf6
Replace TOPDIR with OSMO_GSM_MANUALS_DIR. When the project specific
manuals will be built out of this repository, we still need to refer to
the top directory of the shared content. But it will be in another
repository, so we need to rename the variable to avoid confusion.
(moving manuals to project repositories 3/19)
Related: OS#3385
Change-Id: I2af797546de048a6ab19a5cbc755e5e15575d7ab
Build project independent "test-usermanual.pdf" (with all common
chapters automatically included) and "test-vty-reference.pdf" files.
This allows testing if changed common chapters and the build scripts
are still working, even when the project specific manuals will be moved
away from this repository.
(moving manuals to project repositories 2/19)
Related: OS#3386
Change-Id: Ia74e32678c95e22ba493e80d0a4a8f783c5a5ddf
Use $(ASCIIDOC_DEPS) instead of assuming that the value would be
"chapters/*.adoc". The variable exists already, but it was not used
yet in 'make check' of Makefile.asciidoc.inc.
This allows creating a tests dir without its own chapters subdir
(follow-up commit), which is part of a larger effort to move manuals to
project repositories.
The reason for moving manuals to project repositories is that we can
have documentation changes together with code changes in the same
patches. Not part of this patchset, but possible in the future, is
optionally building UNIX man pages in the project repositories
(OS#3386) as well as generating the VTY documentation on the fly from
running the project binaries (OS#3695).
(moving manuals to project repositories 1/19)
Related: OS#3386
Change-Id: Id8b26759607a3490d6cbd93c68ba1f89aa8ef1f2
After I66e97706de0c546db3c6ff77fb5e6ac6e32bff55 which adds the missing
sccp_vty_init(), update VTY reference with the new SCCP show / config commands.
Depends: I66e97706de0c546db3c6ff77fb5e6ac6e32bff55
Change-Id: Id941b8e31d3b4cfdb3f912beedc1e7af321a0113
Re-generate bsc_vty_reference.xml from osmo-bsc, including updates to:
- handover and neighbor config
- SCCP timers
- logging
Change-Id: Ia9ba8d5eba531b1156de57573ab42517e0c1ca15
We reference the port list appendix where all the ports used by various
Osmocom projects are listed and it's unlikely that pointing out the
osmo-nitb port would significantly help the reader, so just remove the
reference.
Change-Id: I354d50314ba248835191fa3da122032201618a0e
Surrounding with '@' didn't seem to yield the intended result, the
charactars appeared in the compiled document.
Change-Id: I66e7949fa4a6c2164bf9572a2beaf8ace169fa1c
Build scripts do not depend on the libosmocore sources anymore
with 161365f ("merge_doc.xsl: move from libosmocore.git"),
so don't try to use them in jenkins.sh anymore.
Related: OS#3385
Change-Id: Ied3661b8a02e9defca0e5aedcc4494845553db84
Make it possible to run the dependency check without the Makefile. This
is needed to split up the manual pages into the projects repositories,
so we can call check-depends.sh from there.
Related: OS#3385
Change-Id: I82a7efd7e9c265c82d1ba8a60856c892a15a7a33
Print "unknown" to stdout when unix-time-to-fmt.py was called without
an argument, instead of printing a Python stack trace to stderr. It gets
called that way when building outside of a git folder.
Change-Id: I3ba27cc23543e47cc8a1e494c35cc33f1dc8f297
a2x wraps asciidoc. When a2x fails, we run asciidoc without a2x to
print verbose output. Make sure that 'make' fails at this point, even
if asciidoc runs through.
Change-Id: I30931303ecc6094efaedcb08380433a34211a169
Add chapter "Handover", explaining:
- intra- and
- inter-BSC handover,
- HO algorithm 1 and
- algorithm 2
- new neighbor configuration
Adjust copyright, add revision and add me as author.
Change-Id: I7afb3f66c98abda07fc8acc76e00c46091fe55e2
Those graphs + message sequence charts are not yet used by any
of our manuals, but they should become used by the OsmoMSC user
manual once SGs interface support is added.
Related: OS#2583
Change-Id: Idfd3a66c18131b5458d183b8e66f62eaaab65991
Add an informative note on how DTMF signalling is done in mobile
networks and mention the limitations regarding DTMF, when internal MNCC
is used.
Change-Id: Iedcf4ad5e0e4697c6a05ebdd4f43173c14c7c448
Related: OS#2777
The list that describes the MNCC message types lacks the message types
used for DTMF.
Change-Id: I4251b296e043e7583518d6672e614b376331d25e
Related: OS#2777
Max
Oliver Smith
Daniel Willmann
Harald Welte
Philipp Maier