pypi-get-latest-version.sh retrieves the latest version of any
Python package as registered on https://pypi.org
It makes it easy to check the latest version from the command line.
The command 'update-rust-port.sh <version>', when run in the Rust
port directory, updates this port to the requested version.
update-rust-port.sh should work in most cases.
-g option means also bump portevision of indirect dependencies,
this is not required by default since at least FreeBSD 11 when we
stopped recursively copying DT_NEEDED
This helps in `git shortlog`, replacing "cleanup: Remove expired ports" by
"category/port: Remove expired port" for a given category and port.
Reported by: gerald
People should use 'make makepatch' instead which creates patches
with the expected filename and header.
Differential Revision: https://reviews.freebsd.org/D36767
- Mk/bsd.port.mk: mark 13.0 as unsupported
- Tools/scripts/portsearch: Drop support for FreeBSD <= 4
- archivers/zstd: revert "Fix build on FreeBSD 13.0"
- deskutils/xdg-desktop-portal: remove check for 13.0
- devel/libpeas: remove outdated comment
- editors/imhex: remove compatibility for 13.0
- editors/libreoffice: remove compatibility for 13.0
- editors/openoffice-4: remove compatibility for 13.0
- editors/openoffice-devel: remove compatibility for 13.0
- emulators/linux_base-c7: remove compatiblity for 13.0
- graphics/drm-kmod: remove detection for 13.0
- graphics/gpu-firmware-amd-kmod: do not check 13.0 anymore
- graphics/linux-c7-libdrm: remove support for 13.0
- math/igraph: remove support for 13.0
- net/asterisk16: drop support for ancient FreeBSD versions
- net/asterisk18: drop support for ancient FreeBSD versions
- security/openssl*: drop now obsolete patches
- sysutils/bhyve+: drop support for FreeBSD 13.0
- sysutils/ebsnvme-id: drop support for FreeBSD 13.0
- sysutils/openzfs: remove detection of FreeBSD 13.0
- sysutils/openzfs-kmod: drop detection of FreeBSD 13.0
- www/firefox: generalize pkg-message a bit regarding hgame(4)
- x11/xorg-cf-files: remove support for FreeBSD < 6 (yes, pre-2008)
While here, regenerate patches for:
- x11/xorg-cf-files
- net/asterisk16
- net/asterisk18
While here, remove a stale $Id$ from Tools/scripts/portsearch
Differential Revision: https://reviews.freebsd.org/D36233
Reviewed by: office (fluffy), x11 (manu), arrowd, brnrd, cperciva, freqlabs, imp, jbeich, madpilot, nobutaka
Ignoring make.conf when looking up for existing flavors, makes the
test less likely to be polluted by end user defaults, like default
version of python etc.
There is no need to document when a port has been flavored or new
flavor has been added, check if someone added such a line, and prevent
the person it is not needed
This update provides the following enhancements:
- The list of all files of all packages in the official repository
is directly parsed from a dump of the provides.db database, instead
of parsing the output of "pkg provides".
- If a package uses a version specific sub-directory as is the case
for e.g. most perl or python modules, a pattern that is generated
that matches only other modules built for the same interpreter
version.
The addport script is no longer useful since git has been introduced in
April 2021, just use plain "git add" instead. Do not forget to add the
port name to the category Makefile and mention the contributor in the
contributors article in the doc repository.
Differential Revision: https://reviews.freebsd.org/D35104
Add a script to check the CONFLICTS and CONFLICTS_INSTALL parameters
of ports for completeness and correctness.
This script uses the "hidden" LUA interpreter in the FreeBSD base
system and the pkg-provides extension of the pkg command to check
for conflicting files in all packages available for the architecture
and version of the base system this command is run on.
It generates output in the following format:
portedit merge -ie 'CONFLICTS_INSTALL=kicad-library-footprints-devel \
# share/kicad/template/fp-lib-table' \
/usr/ports/cad/kicad-library-footprints
(The last line is shown wrapped for the text of this commit message.)
The portedit command is provided by the port-fmt package. It takes
care of placing the CONFLICTS_ENTRY into the correct position of the
port's Makefile (and removes prior definitions).
The files listed with each result are examples of files that are in
conflict between the port and the packages in the list after ">".
The main purpose of the files list is to help distinguish between
conflicts that affect all flavors or versions of a port, or whether
the files are placed in version specific sub-directories or use other
mechanisms to allow e.g. multiple Python versions to co-exist.
(In the latter case ${PYTHON_PKGNAMEPREFIX} can be used to limit
the CONFLICTS_INSTALL entry to conflicting packages using the same
Python interpreter version, for example, else a prefix like py*- might
be required for a version independent pattern).
Users of this feature are highly advised to check each Makefile by
comparing it with pre-edit version before the changes are committed!
There are several limitations that can cause incorrect or undesirable
changes:
- The list of files installed by each port is only available for the
officially built packages (and the flavors selected from the set of
available flavors). It does not include ports that may not be
packaged or that are broken or ignored due to a dependency on a
broken port (or for other reasons). As a result, there may be
undected conflicts with ports for which no official package is
available.
- The CONFLICTS_INSTALL line is not always inserted into the correct
position in the Makefile, typically due to out-of-order entries used
by portedit to locate the desired position.
- Complex ports may have conditional CONFLICTS_INSTALL entries,
depending on port options or flavors that are in effect. It is not
possible to deal with that kind of Makefiles in an automated way.
- The union of all CONFLICTS and CONFLICTS_INSTALL entries is used as
the list of install conflicts of a port. But only CONFLICTS_INSTALL
entries are generated by this tool. Quite a lot of ports have
CONFLICTS entries where CONFLICTS_INSTALL would suffice (i.e. there
is no build conflict, actually), but there are ports that need to
keep the conflicts listed as CONFLICTS. Such issues can be found by
comparing the before and after versions of the edited Makefiles.
- Conflicting ports that have been removed from the ports system will
only be found as long as their official package files are still
available. (There is a recommendation that conflicts with removed
ports are kept for a few months.)
- If all packages conflicting with a given port have been removed
from the ports system and the official packages repository, the
now superfluous CONFLICTS_INSTALL definition will not be detected.
This is due to only Makefiles of ports being parsed that install
files in the same place as some other port. Parsing all Makefiles
instead would increase the run-time of this script by more than a
factor of 10.
Add zstd (faster to decompress) and xz (smaller) compression for INDEX
Results are the following:
39552 INDEX-14
2366 INDEX-14.bz2
1625 INDEX-14.xz
1672 INDEX-14.zst
Simple shell script to help updating Makefile CARGO_CRATES variable
returned by make cargo-crates.
simplest way to use it :
make cargo-crates | update_crates Makefile > NewMakefile
LEGAL is badly maintained, LEGALlint notices quite a number of ports
which mismatch their line in LEGAL. The port itself is always leading.
* math/giacxcas: restrict RESTRICTED_FILES to giac_* only
Differential Revision: https://reviews.freebsd.org/D30061
Reviewed by: portmgr (mat), dch, eadler, marcus
When you run `git log foo` foo can be, from git-log(1),
`[<revision range>] [[--] <path>...]`, so, may things.
- A "revision range" described by gitrevision(7) (don't got there unless
you have a few hours, or already lost your sanity), which can be :
* a commit hash,
* a tag
* a branch,
* a ref name
* a "describe output"
* and many other ways to describe revisions
* a range made by any of the above
- An existing path.
When it can't find any of those, git figures out that you meant
something else and made a typo, and exits.
If you really meant a path, you have to run `git log -- foo`. Then git
knows that you meant a path and only a path, it will then assume that
you knew what you meant, and will go look in the history.
`git log' cannot get the log of a non-existent file, which the script uses
to obtain the last person who touched a port, so check if the file exists
before getting its log. This is similar to the Subversion case, which only
inspected changed files. The Git version still also checks added ports.
While here, call git in blame() using the predefined global variable.
Reported by: antoine
