| USCAN(1) | USCAN(1) |
uscan - scan/watch upstream sources for new releases of software
uscan [options] [path]
For basic usage, uscan is executed without any arguments from the root of the Debianized source tree where you see the debian/ directory, or a directory containing multiple source trees.
Unless --watchfile is given, uscan looks recursively for valid source trees starting from the current directory (see the below section "Directory name checking" for details).
For each valid source tree found, typically the following happens:
Please note the following.
The current version 4 format of debian/watch can be summarized as follows:
This is a required line and the recommended version number.
If you use "version=3" instead here, some features may not work as documented here. See "HISTORY AND UPGRADING".
Here,
There are a few special strings which are substituted by uscan to make it easy to write the watch file.
[-_]?v?(\d[\-+\.:\~\da-zA-Z]*)
(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))
(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|tar\.zstd?|zip|tgz|tbz|txz))'(?:\.(?:asc|pgp|gpg|sig|sign))'
[\+~](debian|dfsg|ds|deb)(\.)?(\d+)?$
Some file extensions are not included in the above intentionally to avoid false positives. You can still set such file extension patterns manually.
uscan reads the watch options specified in opts=" ... " to customize its behavior. Multiple options option1, option2, option3, ... can be set as opts="option1, option2, option3, ... " . The double quotes are necessary if options contain any spaces.
Unless otherwise noted as persistent, most options are valid only within their containing watch line.
The available watch options are:
When using ctype=nodejs, uscan tries to find a version in "package.json", when using ctype=perl, uscan tries to find a version in "META.json". If a version is found, it is used as current version for this component, regardless version found in Debian version string. This permits a better change detection when using ignore or checksum as Debian version.
Available method values are what mk-origtargz supports, so xz, gzip (alias gz), bzip2 (alias bz2), lzma, default. The default method is currently xz. When uscan is launched in a debian source repository which format is "1.0" or undefined, the method switches to gzip.
Please note the repacking of the upstream tarballs by mk-origtargz happens only if one of the following conditions is satisfied:
If the upstream publishes the released tarball via its web interface, please use it instead of using this mode. This mode is the last resort method.
For git mode, matching-pattern specifies the full string matching pattern for tags instead of hrefs. If matching-pattern is set to refs/tags/tag-matching-pattern, uscan downloads source from the refs/tags/matched-tag of the git repository. The upstream version is extracted from concatenating the matched parts in ( ... ) with . . See "WATCH FILE EXAMPLES".
If matching-pattern is set to HEAD, uscan downloads source from the HEAD of the git repository and the pertinent version is automatically generated with the date and hash of the HEAD of the git repository.
If matching-pattern is set to refs/heads/branch, uscan downloads source from the named branch of the git repository.
The local repository is temporarily created as a bare git repository directory under the destination directory where the downloaded archive is generated. This is normally erased after the uscan execution. This local repository is kept if --debug option is used.
If the current directory is a git repository and the searched repository is listed among the registered "remotes", then uscan will use it instead of cloning separately. The only local change is that uscan will run a "fetch" command to refresh the repository.
For svn mode, matching-pattern specifies the full string matching pattern for directories under Subversion repository directory, specified via URL. The upstream version is extracted from concatenating the matched parts in ( ... ) with . .
If matching-pattern is set to HEAD, uscan downloads the latest source tree of the URL. The upstream version is then constructed by appending the last revision of the URL to 0.0~svn.
As commit signing is not possible with Subversion, the default pgpmode is set to none when mode=svn. Settings of pgpmode other than default and none are reported as errors.
When pretty=describe is used, the upstream version string is the output of the "git describe --tags | sed s/-/./g" command instead. For example, if the commit is the 5-th after the last tag v2.17.12 and its short hash is ged992511, then the string is v2.17.12.5.ged992511 . For this case, it is good idea to add uversionmangle=s/^/0.0~/ or uversionmangle=s/^v// to make the upstream version string compatible with Debian. uversionmangle=s/^v// may work as well. Please note that in order for pretty=describe to function well, upstream need to avoid tagging with random alphabetic tags.
The pretty=describe forces to set gitmode=full to make a full local clone of the repository automatically.
This option is valid only in git mode.
If the current directory is a git repository and the searched repository is listed among the registered "remotes", then uscan will use it instead of cloning separately.
If the specified pgpsigurlmangle is missing, uscan checks possible URLs for the signature file and suggests adding a pgpsigurlmangle rule.
version=4
opts="searchmode=plain" \
https://registry.npmjs.org/aes-js \
https://registry.npmjs.org/aes-js/-/aes-js-(\d[\d\.]*)@ARCHIVE_EXT@
user-agent option should be specified by itself in the watch line without URL, to allow using semicolons and commas in it.
If PASV mode is required due to the client side network environment, set uscan to use PASV mode via "COMMANDLINE OPTIONS" or "DEVSCRIPT CONFIGURATION VARIABLES" instead.
You can also use dversionmangle=auto, this is exactly the same than dversionmangle=s/@DEB_EXT@//
Substitution such as s/PRE/~pre/; s/RC/~rc/ may help.
This is handy if you wish to access Amazon AWS or Subversion repositories in which <a href="..."> is not used.
Substitution such as s/PRE/~pre/; s/RC/~rc/ may help.
Without this option, the default upstream tarball filename is generated by taking the last component of the URL and removing everything after any '?' or '#'.
Here, the mangling rules apply the rules to the pertinent string. Multiple rules can be specified in a mangling rule string by making a concatenated string of each mangling rule separated by ; (semicolon).
Each mangling rule cannot contain ; (semicolon), , (comma), or " (double quote).
Each mangling rule behaves as if a Perl command "$string =~ rule" is executed. There are some notable details.
uscan reads the first entry in debian/changelog to determine the source package name and the last upstream version.
For example, if the first entry of debian/changelog is:
then, the source package name is bar and the last Debian package version is 3:2.03+dfsg-4.
The last upstream version is normalized to 2.03+dfsg by removing the epoch and the Debian revision.
If the dversionmangle rule exists, the last upstream version is further normalized by applying this rule to it. For example, if the last upstream version is 2.03+dfsg indicating the source tarball is repackaged, the suffix +dfsg is removed by the string substitution s/\+dfsg\d*$// to make the (dversionmangled) last upstream version 2.03 and it is compared to the candidate upstream tarball versions such as 2.03, 2.04, ... found in the remote site. Thus, set this rule as:
uscan downloads a web page from http://URL specified in debian/watch.
For example, this http://URL may be specified as:
Please note the trailing / in the above to make @ANY_VERSION@ as the directory.
If the pagemangle rule exists, the whole downloaded web page as a string is normalized by applying this rule to it. This is very powerful tool and needs to be used with caution. If other mangling rules can be used to address your objective, do not use this rule.
The downloaded web page is scanned for hrefs defined in the <a href=" ... "> tag to locate the candidate upstream tarball hrefs. These candidate upstream tarball hrefs are matched by the Perl regex pattern matching-pattern such as DL-(?:[\d\.]+?)/foo-(.+)\.tar\.gz to narrow down the candidates. This pattern match needs to be anchored at the beginning and the end. For example, candidate hrefs may be:
Here the matching string of (.+) in matching-pattern is considered as the candidate upstream version. If there are multiple matching strings of capturing patterns in matching-pattern, they are all concatenated with . (period) to form the candidate upstream version. Make sure to use the non-capturing regex such as (?:[\d\.]+?) instead for the variable text matching part unrelated to the version.
Then, the candidate upstream versions are:
The downloaded tarball filename is basically set to the same as the filename in the remote URL of the selected href.
If the uversionmangle rule exists, the candidate upstream versions are normalized by applying this rule to them. (This rule may be useful if the upstream version scheme doesn't sort correctly to identify the newest version.)
The upstream tarball href corresponding to the newest (uversionmangled) candidate upstream version newer than the (dversionmangled) last upstream version is selected.
If multiple upstream tarball hrefs corresponding to a single version with different extensions exist, the highest compression one is chosen. (Priority: tar.xz > tar.lzma > tar.bz2 > tar.gz.)
If the selected upstream tarball href is the relative URL, it is converted to the absolute URL using the base URL of the web page. If the <base href=" ... "> tag exists in the web page, the selected upstream tarball href is converted to the absolute URL using the specified base URL in the base tag, instead.
If the downloadurlmangle rule exists, the selected upstream tarball href is normalized by applying this rule to it. (This is useful for some sites with the obfuscated download URL.)
If the filenamemangle rule exists, the downloaded tarball filename is generated by applying this rule to the selected href if matching-pattern can extract the latest upstream version <uversion> from the selected href string. Otherwise, generate the upstream tarball filename from its full URL string and set the missing <uversion> from the generated upstream tarball filename.
Without the filenamemangle rule, the default upstream tarball filename is generated by taking the last component of the URL and removing everything after any '?' or '#'.
uscan downloads the selected upstream tarball to the parent ../ directory. For example, the downloaded file may be:
Let's call this downloaded version 2.04 in the above example generically as <uversion> in the following.
If the pgpsigurlmangle rule exists, the upstream signature file URL is generated by applying this rule to the (downloadurlmangled) selected upstream tarball href and the signature file is tried to be downloaded from it.
If the pgpsigurlmangle rule doesn't exist, uscan warns user if the matching upstream signature file is available from the same URL with their filename being suffixed by the 5 common suffix asc, gpg, pgp, sig and sign. (You can avoid this warning by setting pgpmode=none.)
If the signature file is downloaded, the downloaded upstream tarball is checked for its authenticity against the downloaded signature file using the armored keyring debian/upstream/signing-key.asc (see "KEYRING FILE EXAMPLES"). If its signature is not valid, or not made by one of the listed keys, uscan will report an error.
If the oversionmangle rule exists, the source tarball version oversion is generated from the downloaded upstream version uversion by applying this rule. This rule is useful to add suffix such as +dfsg to the version of all the source packages of the MUT package for which the repacksuffix mechanism doesn't work.
uscan invokes mk-origtargz to create the source tarball properly named for the source package with .orig. (or .orig-<component>. for the secondary tarballs) in its filename.
Usually, there is no need to set up opts="dversionmangle= ... " for this case.
The removal of files is required if files are not DFSG-compliant. For such case, +dfsg is used as suffix.
So the combined options are set as opts="dversionmangle=s/\+dfsg\d*$// ,repacksuffix=+dfsg", instead.
For example, the repacked upstream tarball may be:
uscan normally invokes "uupdate --find --upstream-version oversion " for the version=4 watch file.
Please note that --find option is used here since mk-origtargz has been invoked to make *.orig.tar.gz file already. uscan picks bar from debian/changelog.
It creates the new upstream source tree under the ../bar-<oversion> directory and Debianize it leveraging the last package contents.
When writing the watch file, you should rely on the latest upstream source announcement web page. You should not try to second guess the upstream archive structure if possible. Here are the typical debian/watch files.
Please note that executing uscan with -v or -vv reveals what exactly happens internally.
The existence and non-existence of a space the before tailing \ (back slash) are significant.
Some undocumented shorter configuration strings are used in the below EXAMPLES to help you with typing. These are intentional ones. uscan is written to accept such common sense abbreviations but don't push the limit.
Here is an example for the basic single upstream tarball.
version=4
http://example.com/~user/release/@PACKAGE@.html \
files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Or without using the substitution strings (not recommended):
http://example.com/~user/release/foo.html \
files/foo-([\d\.]+)\.tar\.gz
version=4
For the upstream source package foo-2.0.tar.gz, this watch file downloads and creates the Debian orig.tar file foo_2.0.orig.tar.gz.
Here is an example for the basic single upstream tarball with the matching signature file in the same file path.
version=4
opts="pgpsigurlmangle=s%$%.asc%" http://example.com/release/@PACKAGE@.html \
files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
For the upstream source package foo-2.0.tar.gz and the upstream signature file foo-2.0.tar.gz.asc, this watch file downloads these files, verifies the authenticity using the keyring debian/upstream/signing-key.asc and creates the Debian orig.tar file foo_2.0.orig.tar.gz.
Here is another example for the basic single upstream tarball with the matching signature file on decompressed tarball in the same file path.
version=4
opts="pgpsigurlmangle=s%@ARCHIVE_EXT@$%.asc%,decompress" \
http://example.com/release/@PACKAGE@.html \
files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
For the upstream source package foo-2.0.tar.gz and the upstream signature file foo-2.0.tar.asc, this watch file downloads these files, verifies the authenticity using the keyring debian/upstream/signing-key.asc and creates the Debian orig.tar file foo_2.0.orig.tar.gz.
Here is an example for the basic single upstream tarball with the matching signature file in the unrelated file path.
version=4
opts="pgpmode=next" http://example.com/release/@PACKAGE@.html \
files/(?:\d+)/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian
opts="pgpmode=previous" http://example.com/release/@PACKAGE@.html \
files/(?:\d+)/@PACKAGE@@ANY_VERSION@@SIGNATURE_EXT@ previous
(?:\d+) part can be any random value. The tarball file can have 53, while the signature file can have 33.
([\d\.]+) part for the signature file has a strict requirement to match that for the upstream tarball specified in the previous line by having previous as version in the watch line.
Here is an example for the maximum flexibility of upstream tarball and signature file extensions.
version=4
opts="pgpmode=next" http://example.com/DL/ \
files/(?:\d+)/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian
opts="pgpmode=previous" http://example.com/DL/ \
files/(?:\d+)/@PACKAGE@@ANY_VERSION@@SIGNATURE_EXT@ \
previous
Here is an example for the basic multiple upstream tarballs.
version=4
opts="pgpsigurlmangle=s%$%.sig%" \
http://example.com/release/foo.html \
files/foo-@ANY_VERSION@@ARCHIVE_EXT@ debian
opts="pgpsigurlmangle=s%$%.sig%, component=bar" \
http://example.com/release/foo.html \
files/foobar-@ANY_VERSION@@ARCHIVE_EXT@ same
opts="pgpsigurlmangle=s%$%.sig%, component=baz" \
http://example.com/release/foo.html \
files/foobaz-@ANY_VERSION@@ARCHIVE_EXT@ same
For the main upstream source package foo-2.0.tar.gz and the secondary upstream source packages foobar-2.0.tar.gz and foobaz-2.0.tar.gz which install under bar/ and baz/, this watch file downloads and creates the Debian orig.tar file foo_2.0.orig.tar.gz, foo_2.0.orig-bar.tar.gz and foo_2.0.orig-baz.tar.gz. Also, these upstream tarballs are verified by their signature files.
Here is an example with the recursive directory scanning for the upstream tarball and its signature files released in a directory named after their version.
version=4
opts="pgpsigurlmangle=s%$%.sig%, dirversionmangle=s/-PRE/~pre/;s/-RC/~rc/" \
http://tmrc.mit.edu/mirror/twisted/Twisted/@ANY_VERSION@/ \
Twisted-@ANY_VERSION@@ARCHIVE_EXT@
Here, the web site should be accessible at the following URL:
http://tmrc.mit.edu/mirror/twisted/Twisted/
Here, dirversionmangle option is used to normalize the sorting order of the directory names.
For the bare HTTP site where you can directly see archive filenames, the normal watch file:
version=4
opts="pgpsigurlmangle=s%$%.sig%" \
http://www.cpan.org/modules/by-module/Text/ \
Text-CSV_XS-@ANY_VERSION@@ARCHIVE_EXT@
can be rewritten in an alternative shorthand form only with a single string covering URL and filename:
version=4
opts="pgpsigurlmangle=s%$%.sig%" \
http://www.cpan.org/modules/by-module/Text/Text-CSV_XS-@ANY_VERSION@@ARCHIVE_EXT@
In version=4, initial white spaces are dropped. Thus, this alternative shorthand form can also be written as:
version=4
opts="pgpsigurlmangle=s%$%.sig%" \
http://www.cpan.org/modules/by-module/Text/\
Text-CSV_XS-@ANY_VERSION@@ARCHIVE_EXT@
Please note the subtle difference of a space before the tailing \ between the first and the last examples.
For a site which has funny version numbers, the parenthesized groups will be joined with . (period) to make a sanitized version number.
version=4 http://www.site.com/pub/foobar/foobar_v(\d+)_(\d+)@ARCHIVE_EXT@
The upstream part of the Debian version number can be mangled to indicate the source package was repackaged to clean up non-DFSG files:
version=4 opts="dversionmangle=s/\+dfsg\d*$//,repacksuffix=+dfsg" \ http://some.site.org/some/path/foobar-@ANY_VERSION@@ARCHIVE_EXT@
See "COPYRIGHT FILE EXAMPLES".
The upstream tarball filename is found by taking the last component of the URL and removing everything after any '?' or '#'.
If this does not fit to you, use filenamemangle. For example, <A href="http://foo.bar.org/dl/?path=&dl=foo-0.1.1.tar.gz"> could be handled as:
version=4 opts=filenamemangle=s/.*=(.*)/$1/ \ http://foo.bar.org/dl/\?path=&dl=foo-@ANY_VERSION@@ARCHIVE_EXT@
<A href="http://foo.bar.org/dl/?path=&dl_version=0.1.1"> could be handled as:
version=4 opts=filenamemangle=s/.*=(.*)/foo-$1\.tar\.gz/ \ http://foo.bar.org/dl/\?path=&dl_version=@ANY_VERSION@
If the href string has no version using <I>matching-pattern>, the version can be obtained from the full URL using filenamemangle.
version=4 opts=filenamemangle=s&.*/dl/(.*)/foo\.tar\.gz&foo-$1\.tar\.gz& \ http://foo.bar.org/dl/@ANY_VERSION@/ foo.tar.gz
The option downloadurlmangle can be used to mangle the URL of the file to download. This can only be used with http:// URLs. This may be necessary if the link given on the web page needs to be transformed in some way into one which will work automatically, for example:
version=4 opts=downloadurlmangle=s/prdownload/download/ \ http://developer.berlios.de/project/showfiles.php?group_id=2051 \ http://prdownload.berlios.de/softdevice/vdr-softdevice-@ANY_VERSION@@ARCHIVE_EXT@
The option oversionmangle can be used to mangle the version of the source tarball (.orig.tar.gz and .orig-bar.tar.gz). For example, +dfsg can be added to the upstream version as:
version=4 opts=oversionmangle=s/(.*)/$1+dfsg/ \ http://example.com/~user/release/foo.html \ files/foo-@ANY_VERSION@@ARCHIVE_EXT@ debian opts="component=bar" \ http://example.com/~user/release/foo.html \ files/bar-@ANY_VERSION@@ARCHIVE_EXT@ same
See "COPYRIGHT FILE EXAMPLES".
The option pagemangle can be used to mangle the downloaded web page before applying other rules. The non-standard web page without proper <a href=" << ... >> "> entries can be converted. For example, if foo.html uses <a bogus=" ... ">, this can be converted to the standard page format with:
version=4 opts=pagemangle="s/<a\s+bogus=/<a href=/g" \ http://example.com/release/foo.html \ files/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
Please note the use of g here to replace all occurrences.
If foo.html uses <Key> ... </Key>, this can be converted to the standard page format with:
version=4 opts="pagemangle=s%<Key>([^<]*)</Key>%<Key><a href="$1">$1</a></Key>%g" \ http://example.com/release/foo.html \ (?:.*)/@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@
version=4 ftp://ftp.tex.ac.uk/tex-archive/web/c_cpp/cweb/cweb-@ANY_VERSION@@ARCHIVE_EXT@
version=4 ftp://ftp.worldforge.org/pub/worldforge/libs/\ Atlas-C++/transitional/Atlas-C\+\+-@ANY_VERSION@@ARCHIVE_EXT@
Please note that this URL is connected to be ... libs/Atlas-C++/ ... . For ++, the first one in the directory path is verbatim while the one in the filename is escaped by \.
This is another way of handling site with funny version numbers, this time using mangling. (Note that multiple groups will be concatenated before mangling is performed, and that mangling will only be performed on the basename version number, not any path version numbers.)
version=4 opts="uversionmangle=s/^/0.0./" \ ftp://ftp.ibiblio.org/pub/Linux/ALPHA/wine/\ development/Wine-@ANY_VERSION@@ARCHIVE_EXT@
For SourceForge based projects, qa.debian.org runs a redirector which allows a simpler form of URL. The format below will automatically be rewritten to use the redirector with the watch file:
version=4 https://sf.net/<project>/ <tar-name>-@ANY_VERSION@@ARCHIVE_EXT@
For audacity, set the watch file as:
version=4 https://sf.net/audacity/ audacity-minsrc-@ANY_VERSION@@ARCHIVE_EXT@
Please note, you can still use normal functionalities of uscan to set up a watch file for this site without using the redirector.
version=4
opts="uversionmangle=s/-pre/~pre/, \
filenamemangle=s%(?:.*)audacity-minsrc-(.+)\.tar\.xz/download%\
audacity-$1.tar.xz%" \
http://sourceforge.net/projects/audacity/files/audacity/@ANY_VERSION@/ \
(?:.*)audacity-minsrc-@ANY_VERSION@@ARCHIVE_EXT@/download
Here, % is used as the separator instead of the standard /.
For GitHub based projects, you can use the tags or releases page. The archive URL uses only the version as the filename. You can rename the downloaded upstream tarball from into the standard <project>-<version>.tar.gz using filenamemangle:
version=4
opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" \
https://github.com/<user>/<project>/tags \
(?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@
For PyPI based projects, pypi.debian.net runs a redirector which allows a simpler form of URL. The format below will automatically be rewritten to use the redirector with the watch file:
version=4
https://pypi.python.org/packages/source/<initial>/<project>/ \
<tar-name>-@ANY_VERSION@@ARCHIVE_EXT@
For cfn-sphere, set the watch file as:
version=4
https://pypi.python.org/packages/source/c/cfn-sphere/ \
cfn-sphere-@ANY_VERSION@@ARCHIVE_EXT@
Please note, you can still use normal functionalities of uscan to set up a watch file for this site without using the redirector.
version=4
opts="pgpmode=none" \
https://pypi.python.org/pypi/cfn-sphere/ \
https://pypi.python.org/packages/.*/.*/.*/\
cfn-sphere-@ANY_VERSION@@ARCHIVE_EXT@#.*
Sites which used to be hosted on the Google Code service should have migrated to elsewhere (github?). Please look for the newer upstream site if available.
npmjs.org modules are published in JSON files. Here is a way to read them:
version=4 opts="searchmode=plain" \ https://registry.npmjs.org/aes-js \ https://registry.npmjs.org/aes-js/-/aes-js-@ANY_VERSION@@ARCHIVE_EXT@
Some node modules are split into multiple little upstream package. Here is a way to group them:
version=4
opts="searchmode=plain,pgpmode=none" \
https://registry.npmjs.org/mongodb \
https://registry.npmjs.org/mongodb/-/mongodb-@ANY_VERSION@@ARCHIVE_EXT@ group
opts="searchmode=plain,pgpmode=none,component=bson" \
https://registry.npmjs.org/bson \
https://registry.npmjs.org/bson/-/bson-@ANY_VERSION@@ARCHIVE_EXT@ group
opts="searchmode=plain,pgpmode=none,component=mongodb-core" \
https://registry.npmjs.org/mongodb-core \
https://registry.npmjs.org/mongodb-core/-/mongodb-core-@ANY_VERSION@@ARCHIVE_EXT@ group
opts="searchmode=plain,pgpmode=none,component=requireoptional" \
https://registry.npmjs.org/require_optional \
https://registry.npmjs.org/require_optional/-/require_optional-@ANY_VERSION@@ARCHIVE_EXT@ group
Package version is then the concatenation of upstream versions separated by "+~".
To avoid having a too long version, the "checksum" method can be used. In this case, the main source has to be declared as "group":
version=4
opts="searchmode=plain,pgpmode=none" \
https://registry.npmjs.org/mongodb \
https://registry.npmjs.org/mongodb/-/mongodb-@ANY_VERSION@@ARCHIVE_EXT@ group
opts="searchmode=plain,pgpmode=none,component=bson" \
https://registry.npmjs.org/bson \
https://registry.npmjs.org/bson/-/bson-@ANY_VERSION@@ARCHIVE_EXT@ checksum
opts="searchmode=plain,pgpmode=none,component=mongodb-core" \
https://registry.npmjs.org/mongodb-core \
https://registry.npmjs.org/mongodb-core/-/mongodb-core-@ANY_VERSION@@ARCHIVE_EXT@ checksum
opts="searchmode=plain,pgpmode=none,component=requireoptional" \
https://registry.npmjs.org/require_optional \
https://registry.npmjs.org/require_optional/-/require_optional-@ANY_VERSION@@ARCHIVE_EXT@ checksum
The "checksum" is made up of the separate sum of each number composing the component versions. Following is an example with 3 components whose versions are "1.2.4", "2.0.1" and "10.0", with the main tarball having version "2.0.6":
Main: 2.0.6 Comp1: 1 . 2 . 4 Comp2: 2 . 0 . 1 Comp3: 10 . 0 ================================ Result : 1+2+10 . 2+0+0 . 4+1 Checksum: 13 . 2 . 5 ================================ Final Version: 2.0.6+~cs13.2.5
uscan will also display the original version string before being encoded into the checksum, which can for example be used in a debian/changelog entry to easily follow the changes:
2.0.6+~1.2.4+~2.0.1+~10.0
Note: This feature currently accepts only versions composed of digits and full stops (`.`).
If the upstream only publishes its code via the git repository and its code has no web interface to obtain the release tarball, you can use uscan with the tags of the git repository to track and package the new upstream release.
version=4 opts="mode=git, gitmode=full, pgpmode=none" \ http://git.ao2.it/tweeper.git \ refs/tags/v@ANY_VERSION@
Please note "git ls-remote" is used to obtain references for tags.
If a tag v20.5 is the newest tag, the above example downloads spkg-20.5.tar.xz after making a full clone of the git repository which is needed for dumb git server.
If tags are signed, set pgpmode=gittag to verify them.
If the upstream only publishes its code via the git repository and its code has no web interface nor the tags to obtain the released tarball, you can use uscan with the HEAD of the git repository to track and package the new upstream release with an automatically generated version string.
version=4 opts="mode=git, pgpmode=none" \ https://github.com/Debian/dh-make-golang \ HEAD
Please note that a local shallow copy of the git repository is made with "git clone --bare --depth=1 ..." normally in the target directory. uscan generates the new upstream version with "git log --date=format:%Y%m%d --pretty=0.0~git%cd.%h" on this local copy of repository as its default behavior.
The generation of the upstream version string may the adjusted to your taste by adding pretty and date options to the opts arguments.
If the upstream only publishes its code via the Subversion repository and its code has no web interface to obtain the release tarball, you can use uscan with the tags of the Subversion repository to track and package the new upstream release.
version=4 opts="mode=svn, pgpmode=none" \ svn://svn.code.sf.net/p/jmol/code/tags/ \ @ANY_VERSION@\/
If the upstream only publishes its code via the Subversion repository and its code has no web interface to obtain the release tarball, you can use uscan to get the most recent source of a subtree in the repository with an automatically generated version string.
version=4 opts="mode=svn, pgpmode=none" \ svn://svn.code.sf.net/p/jmol/code/trunk/ \ HEAD
By default, uscan generates the new upstream version by appending the revision number to "0.0~svn". This can later be changed using uversionmangle.
Here is an example for the debian/copyright file which initiates automatic repackaging of the upstream tarball into <spkg>_<oversion>.orig.tar.gz (In debian/copyright, the Files-Excluded and Files-Excluded-component stanzas are a part of the first paragraph and there is a blank line before the following paragraphs which contain Files and other stanzas.):
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Files-Excluded: exclude-this exclude-dir */exclude-dir .* */js/jquery.js Files: * Copyright: ... ...
Here is another example for the debian/copyright file which initiates automatic repackaging of the multiple upstream tarballs into <spkg>_<oversion>.orig.tar.gz and <spkg>_<oversion>.orig-bar.tar.gz:
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Files-Excluded: exclude-this exclude-dir */exclude-dir .* */js/jquery.js Files-Excluded-bar: exclude-this exclude-dir */exclude-dir .* */js/jquery.js Files: * Copyright: ... ...
See mk-origtargz(1).
Let's assume that the upstream "uscan test key (no secret) <none@debian.org>" signs its package with a secret OpenPGP key and publishes the corresponding public OpenPGP key. This public OpenPGP key can be identified in 3 ways using the hexadecimal form.
Considering the existence of the collision attack on the short keyid, the use of the long keyid is recommended for receiving keys from the public key servers. You must verify the downloaded OpenPGP key using its full fingerprint value which you know is the trusted one.
The armored keyring file debian/upstream/signing-key.asc can be created by using the gpg (or gpg2) command as follows.
$ gpg --recv-keys "C77E2D6872543FAF"
...
$ gpg --finger "C77E2D6872543FAF"
pub 4096R/72543FAF 2015-09-02
Key fingerprint = CF21 8F0E 7EAB F584 B7E2 0402 C77E 2D68 7254 3FAF
uid uscan test key (no secret) <none@debian.org>
sub 4096R/52C6ED39 2015-09-02
$ cd path/to/<upkg>-<uversion>
$ mkdir -p debian/upstream
$ gpg --export --export-options export-minimal --armor \
'CF21 8F0E 7EAB F584 B7E2 0402 C77E 2D68 7254 3FAF' \
>debian/upstream/signing-key.asc
The binary keyring files, debian/upstream/signing-key.pgp and debian/upstream-signing-key.pgp, are still supported but deprecated.
If a group of developers sign the package, you need to list fingerprints of all of them in the argument for gpg --export ... to make the keyring to contain all OpenPGP keys of them.
Sometimes you may wonder who made a signature file. You can get the public keyid used to create the detached signature file foo-2.0.tar.gz.asc by running gpg as:
$ gpg -vv foo-2.0.tar.gz.asc
gpg: armor: BEGIN PGP SIGNATURE
gpg: armor header: Version: GnuPG v1
:signature packet: algo 1, keyid C77E2D6872543FAF
version 4, created 1445177469, md5len 0, sigclass 0x00
digest algo 2, begin of digest 7a c7
hashed subpkt 2 len 4 (sig created 2015-10-18)
subpkt 16 len 8 (issuer key ID C77E2D6872543FAF)
data: [4091 bits]
gpg: assuming signed data in `foo-2.0.tar.gz'
gpg: Signature made Sun 18 Oct 2015 11:11:09 PM JST using RSA key ID 72543FAF
...
For the basic usage, uscan does not require to set these options.
Previously downloaded tarballs may be used.
Change default to --skip-signature.
Change default to --no-download and --skip-signature.
When the objective of running uscan is to gather the upstream package status under the security conscious environment, please make sure to use this option.
The above is true not only for the simple uscan run in the single source tree but also for the advanced scanning uscan run with subdirectories holding multiple source trees.
One exception is when --watchfile and --package are used together. For this case, the internal current directory of uscan execution and the default destination directory are set to the current directory . where uscan is started. The default destination directory can be overridden by setting --destdir option as well.
One exception is when --watchfile and --package are used together. uscan can be called from anywhare and the internal current directory of uscan execution and the default destination directory are set to the current directory . where uscan is started.
See more in the --destdir explanation.
uscan --http-header https://example.org@My-Token=qwertyuiop
Security:
| --http-header value | Good for | Never used |
+------------------------------------+-----------------------------+------------+
| https://example.org.com@Hdr=Value | https://example.org.com/... | |
| https://example.org.com/@Hdr=Value | | X |
| https://e.com:1879@Hdr=Value | https://e.com:1879/... | |
| https://e.com:1879/dir@Hdr=Value | https://e.com:1879/dir/... | |
| https://e.com:1879/dir/@Hdr=Value | | X |
uscan also accepts following options and passes them to mk-origtargz:
The unzip package must be installed in order to repack zip and jar archives, the mozilla-devscripts package must be installed to repack xpi archives, the xz-utils package must be installed to repack lzma or xz tar archives, and zstd must be installed to repack zstd archives.
For the basic usage, uscan does not require to set these configuration variables.
The two configuration files /etc/devscripts.conf and ~/.devscripts are sourced by a shell in that order to set configuration variables. These may be overridden by command line options. Environment variable settings are ignored for this purpose. If the first command line option given is --noconf, then these files will not be read. The currently recognized variables are:
The exit status gives some indication of whether a newer version was found or not; one is advised to read the output to determine exactly what happened and whether there were any warnings to be noted.
uscan has many other enhanced features which are skipped in the above section for the simplicity. Let's check their highlights.
uscan can be executed with path as its argument to change the starting directory of search from the current directory to path .
If you are not sure what exactly is happening behind the scene, please enable the --verbose option. If this is not enough, enable the --debug option too see all the internal activities.
See "COMMANDLINE OPTIONS" and "DEVSCRIPT CONFIGURATION VARIABLES" for other variations.
The optional script parameter in debian/watch means to execute script with options after processing this line if specified.
See "HISTORY AND UPGRADING" for how uscan invokes the custom script.
For compatibility with other tools such as git-buildpackage, it may not be wise to create custom scripts with random behavior. In general, uupdate is the best choice for the non-native package and custom scripts, if created, should behave as if uupdate. For possible use case, see <http://bugs.debian.org/748474> as an example.
Some popular web sites changed their web page structure causing maintenance problems to the watch file. There are some redirection services created to ease maintenance of the watch file. Currently, uscan makes automatic diversion of URL requests to the following URLs to cope with this situation.
Similarly to several other scripts in the devscripts package, uscan explores the requested directory trees looking for debian/changelog and debian/watch files. As a safeguard against stray files causing potential problems, and in order to promote efficiency, it will examine the name of the parent directory once it finds the debian/changelog file, and check that the directory name corresponds to the package name. It will only attempt to download newer versions of the package and then perform any requested action if the directory name matches the package name. Precisely how it does this is controlled by two configuration file variables DEVSCRIPTS_CHECK_DIRNAME_LEVEL and DEVSCRIPTS_CHECK_DIRNAME_REGEX, and their corresponding command-line options --check-dirname-level and --check-dirname-regex.
DEVSCRIPTS_CHECK_DIRNAME_LEVEL can take the following values:
The directory name is checked by testing whether the current directory name (as determined by pwd(1)) matches the regex given by the configuration file option DEVSCRIPTS_CHECK_DIRNAME_REGEX or by the command line option --check-dirname-regex regex. Here regex is a Perl regex (see perlre(3perl)), which will be anchored at the beginning and the end. If regex contains a /, then it must match the full directory path. If not, then it must match the full directory name. If regex contains the string package, this will be replaced by the source package name, as determined from the debian/changelog. The default value for the regex is: package(-.+)?, thus matching directory names such as package and package-version.
This section briefly describes the backwards-incompatible watch file features which have been added in each watch file version, and the first version of the devscripts package which understood them.
If you are upgrading from version 2, the key incompatibility is if you have multiple groups in the pattern part; whereas only the first one would be used in version 2, they will all be used in version 3. To avoid this behavior, change the non-version-number groups to be (?: ... ) instead of a plain ( ... ) group.
The syntax of the watch file is relaxed to allow more spaces for readability.
If you have a custom script in place of uupdate, you may also encounter problems updating from Version 3.
Restriction for --dehs is lifted by redirecting other output to STDERR when it is activated.
dpkg(1), mk-origtargz(1), perlre(1), uupdate(1), devscripts.conf(5)
The original version of uscan was written by Christoph Lameter <clameter@debian.org>. Significant improvements, changes and bugfixes were made by Julian Gilbey <jdg@debian.org>. HTTP support was added by Piotr Roszatycki <dexter@debian.org>. The program was rewritten in Perl by Julian Gilbey. Xavier Guimard converted it in object-oriented Perl using Moo.
| 2023-10-20 | Debian Utilities |