There is no update. Fields ``name`` and ``version`` are available.
event=no-result
No version is detected. There may be an error. Fields ``name`` is available.
level=error
There is an error. Fields ``name`` and ``exc_info`` may be available to give
further information.
Upgrade from 1.x version
~~~~~~~~~~~~~~~~~~~~~~~~
There are several backward-incompatible changes from the previous 1.x version.
1. Version 2.x requires Python 3.7+ to run.
2. The command syntax changes a bit. You need to use a ``-c`` switch to specify your software version configuration file (or use the default).
3. The configuration file format has been changed from ini to `toml`_. You can use the ``nvchecker-ini2toml`` script to convert your old configuration files. However, comments and formatting will be lost, and some options may not be converted correctly.
4. Several options have been renamed. ``max_concurrent`` to ``max_concurrency``, and all option names have their ``-`` be replaced with ``_``.
5. All software configuration tables need a ``source`` option to specify which source is to be used rather than being figured out from option names in use. This enables additional source plugins to be discovered.
6. The version record files have been changed to use JSON format (the old format will be converted on writing).
8.``include_tags_pattern`` and ``ignored_tags`` are removed. Use :ref:`list options` instead.
Version Record Files
--------------------
Version record files record which version of the software you know or is available. They are a simple JSON object mapping software names to known versions.
The ``nvtake`` Command
~~~~~~~~~~~~~~~~~~~~~~
This command helps to manage version record files. It reads both old and new version record files, and a list of names given on the commandline. It then update the versions of those names in the old version record file.
This helps when you have known (and processed) some of the updated software, but not all. You can tell nvchecker that via this command instead of editing the file by hand.
This command will help most if you specify where you version record files are in your config file. See below for how to use a config file.
The ``nvcmp`` Command
~~~~~~~~~~~~~~~~~~~~~
This command compares the ``newver`` file with the ``oldver`` one and prints out any differences as updates, e.g.::
$ nvcmp -c sample_source.toml
Sparkle Test App None -> 2.0
test 0.0 -> 0.1
Configuration Files
-------------------
The software version source files are in `toml`_ format. The *key name* is the name of the software. Following fields are used to tell nvchecker how to determine the current version of that software.
A special table named ``__config__`` provides some configuration options.
Relative path are relative to the source files, and ``~`` and environmental variables are expanded.
Currently supported options are:
oldver
Specify a version record file containing the old version info.
newver
Specify a version record file to store the new version info.
proxy
The HTTP proxy to use. The format is ``proto://host:port``, e.g. ``http://localhost:8087``. Different backends have different level support for this, e.g. with ``pycurl`` you can use ``socks5h://host:port`` proxies.
(*Optional*) When present, a ``POST`` request (instead of a ``GET``) will be used. The value should be a string containing the full body of the request. The encoding of the string can be specified using the ``post_data_type`` option.
post_data_type
(*Optional*) Specifies the ``Content-Type`` of the request body (``post_data``). By default, this is ``application/x-www-form-urlencoded``.
(*Optional*) When present, a ``POST`` request (instead of a ``GET``) will be used. The value should be a string containing the full body of the request. The encoding of the string can be specified using the ``post_data_type`` option.
post_data_type
(*Optional*) Specifies the ``Content-Type`` of the request body (``post_data``). By default, this is ``application/x-www-form-urlencoded``.
Send an HTTP request and search through the body with a specific ``jq`` filter.
url
The URL of the HTTP request.
filter
An ``jq`` filter used to find the version string.
post_data
(*Optional*) When present, a ``POST`` request (instead of a ``GET``) will be used. The value should be a string containing the full body of the request. The encoding of the string can be specified using the ``post_data_type`` option.
post_data_type
(*Optional*) Specifies the ``Content-Type`` of the request body (``post_data``). By default, this is ``application/json``.
This is used when you run ``nvchecker`` on an Arch Linux system and the program always keeps up with a package in your configured repositories for `Pacman`_.
pacman
The package name to reference to.
strip_release
Strip the release part.
Check Arch Linux official packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
source = "archpkg"
This enables you to track the update of `Arch Linux official packages <https://www.archlinux.org/packages/>`_, without needing of pacman and an updated local Pacman databases.
archpkg
Name of the Arch Linux package.
strip_release
Strip the release part, only return part before ``-``.
Instead of the package version, return the version this package provides. Its value is what the package provides, and ``strip_release`` takes effect too. This is best used with libraries.
This enables you to track the update of `Debian Linux official packages <https://packages.debian.org>`_, without needing of apt and an updated local APT database.
debianpkg
Name of the Debian Linux source package.
suite
Name of the Debian release (jessie, wheezy, etc, defaults to sid)
strip_release
Strip the release part.
Check Ubuntu Linux official packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
::
source = "ubuntupkg"
This enables you to track the update of `Ubuntu Linux official packages <https://packages.ubuntu.com/>`_, without needing of apt and an updated local APT database.
ubuntupkg
Name of the Ubuntu Linux source package.
suite
Name of the Ubuntu release (xenial, zesty, etc, defaults to None, which means no limit on suite)
strip_release
Strip the release part.
Check Repology
~~~~~~~~~~~~~~
::
source = "repology"
This enables you to track updates from `Repology <https://repology.org/>`_ (repology.org).
repology
Name of the ``project`` to check.
repo
Check the version in this repo. This field is required.
This enables you to track updates from `Anitya <https://release-monitoring.org/>`_ (release-monitoring.org).
anitya
``distro/package``, where ``distro`` can be a lot of things like "fedora", "arch linux", "gentoo", etc. ``package`` is the package name of the chosen distribution.
This enables you to track updates of Android SDK packages listed in ``sdkmanager --list``.
android_sdk
The package path prefix. This value is matched against the ``path`` attribute in all <remotePackage> nodes in an SDK manifest XML. The first match is used for version comparisons.
repo
Should be one of ``addon`` or ``package``. Packages in ``addon2-1.xml`` use ``addon`` and packages in ``repository2-1.xml`` use ``package``.
Choose the target channel from one of ``stable``, ``beta``, ``dev`` or ``canary``. This option also accepts a comma-separated list to pick from multiple channels. For example, the latest unstable version is picked with ``beta,dev,canary``. The default is ``stable``.
Choose the target OS for the tracked package from one of ``linux``, ``macosx``, ``windows``. The default is ``linux``. For OS-independent packages (e.g., Java JARs), this field is ignored.
The language of release notes to return when localized release notes are available (defaults to ``en`` for English, the unlocalized release notes are used as a fallback)
This enables you to check latest package versions in an arbitrary RPM repository in `repomd` format used by package managers such as ``dnf`` (Fedora, RHEL, AlmaLinux etc.) or ``zypper`` (openSUSE) without the need for native RPM tools.
pkg
Name of the RPM package (you can also use ``rpmrepo`` as with other sources, but ``pkg`` is preferred for clarity)
repo
URL of the repository (required, ``repodata/repomd.xml`` should be there)
arch
Architecture of the RPM package (``binary``, ``src``, ``any``, ``x86_64``, ``aarch64``, etc, defaults to ``binary``)
An array of possible repositories in which the package may reside in, nvchecker will use the first repository which contains the package. If not provided, ``core``, ``extra`` and ``multilib`` will be used, in that order.
Strip the release part, only return the part before ``-``.
provided
Instead of the package version, return the version this package provides. Its value is what the package provides, and ``strip_release`` takes effect too. This is best used with libraries.
Search package files in a local ALPM files database. The package does not need to be installed. This can be useful for checking shared library versions if a package does not list them in its ``provides``.
pkgname
Name of the package.
filename
Regular expression for the file path. If it contains one matching group, that group is returned. Otherwise return the whole file path. Paths do not have an initial slash. For example, ``usr/lib/libuv\\.so\\.([^.]+)`` matches the major shared library version of libuv.
repo
Name of the package repository in which the package resides. If not provided, search all repositories.
strip_dir
Strip directory from the path before matching. Defaults to ``false``.
dbpath
Path to the ALPM database directory. Default: ``/var/lib/pacman``. You need to update the database yourself with ``pacman -Fy``.
This enables you to check latest package versions in an arbitrary `opam repository <https://opam.ocaml.org/doc/Manual.html#Repositories>` without the need for the opam command line tool.
pkg
Name of the opam package
repo
URL of the repository (optional, the default ``https://opam.ocaml.org`` repository is used if not specified)