cargo.mk is a little too eager in splitting a crate's name and version
in two when the version contains a dash (e.g. csv-1.0.0-beta.4) and
the wrong URL ends up being used in MASTER_SITES e.g.
.../csv-1.0.0/beta.4/download/...
instead of the correct one
.../csv/1.0.0-beta.4/download/...
Reviewed by: dumbbell
Differential Revision: https://reviews.freebsd.org/D12628
When defined it will create symlinks of some given binaries in a directory which
will be prepended to the PATH.
The syntax is the following:
BINARY_ALIAS= target1=source1 target2=source2
For example to have a "swig" binary in the path which will be pointing at
swig3.0 and a "sed" pointing at GNU sed: gsed
BINARY_ALIAS= swig=swig3.0 sed=gsed
Reviewed by: swills, adamw, mat
Approved by: swills (portmgr)
Differential Revision: https://reviews.freebsd.org/D12603
- linux- version cannot be updated due to lack of gtk3 package
- mirror -i18n distfiles locally until the langpacks are renamed
Changes: http://www.seamonkey-project.org/news
PR: 222464
Security: 5e0a038a-ca30-416d-a2f5-38cbf5e7df33
Security: 6cec1b0a-da15-467d-8691-1dea392d4c8d
Security: 555b244e-6b20-4546-851f-d8eb7d6c1ffa
Security: 1098a15b-b0f6-42b7-b5c7-8a8646e8be07
MFH: 2017Q4 (piling up until release)
part of USE_QT5, since all of those suggestions are wrong.
Approved by: rakuco (mentor), tcberner (mentor), portmgr (mat)
Differential Revision: https://reviews.freebsd.org/D12526
Having this enabled breaks Poudriere's ability to build py2 and py3 ports
together which FLAVORS aims to resolve. Once we have actual python
FLAVORS support ready to commit we can then enable this feature again.
With hat: portmgr
This is slightly early but due to recent PORTREVISION bump there's no
point doing QA for 55.0.* anymore.
Changes: https://www.mozilla.org/firefox/56.0/releasenotes/
PR: 221335
Security: 1098a15b-b0f6-42b7-b5c7-8a8646e8be07
MFH: 2017Q3 not possible: requires r447450 and r450556
**Do not start migrating any ports, a hook will prevent it**
This has been a long awaiting feature, most of the work has been done by
bapt, bdrewery and antoine, I am just the one actually doing the commit.
All this informations, and more to come are in the first link to our wiki
in the bottom block. A roadmap is in the second link.
To define a different flavors in a port, before any include, set:
FLAVORS= flavor1 flavor2 [...]
The first flavor in the list will be the default.
You can then check for flavors after includ'ing bsd.port.options.mk with:
.if ${FLAVOR} == flavor2
[some stuff]
.endif
To build flavor2, simply run:
make FLAVOR=flavor2
To depend on a specific flavor, write @<flavor> at the end of the depend
string, like:
RUN_DEPENDS= something:origin@foo
Submitted by: bapt, bdrewery, antoine
Reviewed by: portmgr
More infos: https://wiki.freebsd.org/Ports/FlavorsMigration
Todo List: https://wiki.freebsd.org/Ports/FlavorsAndSubPackages
With hat: portmgr
Differential Revision: https://reviews.freebsd.org/D10327
* Once upon a time, we checked all of STAGEDIR/PREFIX's executable
files.
* We then decided too many false positives were found, so we switched to
only checking executable files in bin/sbin/libexec/www, and also
symlinks that were in there.
* And then, we decided to go back to check all of STAGEDIR/PREFIX's
executable files, but forgot to remove the checks for symlinks (which
are now useless because we already check all the executable files.)
Reported by: lifanov
Sponsored by: Absolight
Use `mysql_config --version` instead of `mysql --version` because
in MySQL 8.0 the format of output is changed and it'd be [more reliable] and
easier to use just mysql_config because it only returns the numbers we want.
Reviewed by: brnrd, mat (mentor, portmgr)
Approved by: brnrd, mat (mentor, portmgr)
Sponsored by: EuroBSDCon Paris Devsummit
Differential Revision: https://reviews.freebsd.org/D12458
Cargo started to ship with Rust in 1.19.0_2. I forgot to indicate the
port revision in the 1.19.0_2 commit.
Reported by: jbeich@
Differential Revision: https://reviews.freebsd.org/D12460
Failed builds can occur when PORTSDIR is a symbolic link, or with
make -C /usr/ports/category/port/
PR: 221296
Reported by: yasu@utahime.org, rum1cro@yandex.ru
Reviewed by: bdrewery, sjg
Approved by: portmgr (bdrewery)
Differential Revision: https://reviews.freebsd.org/D11934
This port now provides Cargo. This is the recommended now because Cargo
won't be provided separately in the future.
To build Cargo, we set `extended = true` in `config.toml`. As a side
effect, this flag also installs Rust source code. The port has a new
`SOURCES` option (disabled by default) to keep those sources.
As a consequence of this, `devel/cargo` is removed. Several ports
and Makefiles in Mk were updated to depend on `lang/rust` instead of
`devel/cargo`.
The other big change in this patch is the use of the bundled crates,
instead of relying on Cargo's registry (which was part of the distfiles,
in order to allow offline builds). So now, we don't need to prepare the
registry when updating this port.
This has several other benefits:
* It fixes the build with sudo(8).
* It fixes the use of the ino-64 patch (it was not applied to the
registry, thus not used).
Compilation errors were fixed in the ino-64 patch.
Various `.cargo-checksum.json` files are updated after the sources are
patched (FBSD10_FIX, ino-64, and so on). This fixes builds which were
failing with errors such as:
error: the listed checksum of `.../rustc-1.19.0-src/src/vendor/lzma-sys/xz-5.2.3/build-aux/config.rpath` has changed:
expected: c8b4c017079da9dfb3086a0583e60ffe736184d89005dc5973f0bb0fd17c04bb
actual: 561b00eb30ecaef2c9da17bc195e7d2a7ea63facea38ea9849fbb0ed340bebba
PR: 221088
Reported by: joneum@, nwhitehorn@, romain@,
Ekaterina Vaartis <vaartis@cock.li>,
david@catwhisker.org,
fullermd@over-yonder.net,
rum1cro@yandex.ru,
w.schwarzenfeld@utanet.at
Differential Revision: https://reviews.freebsd.org/D11783
When this was added by r392084 on 2015-07-14, the default flavor of GCC
was GCC 4.8 and explicitly requesting GCC 5 (or later) was necessary for
C++ 14 support. Now that the default version of GCC is GCC 6, after GCC 5
for several months, we can use the preferred notion of USE_GCC=yes instead
of specifying a concrete minimum version.
Among others this helps with cases where GCC 6 is better adjusted for
FreeBSD, notably the well known std::to_string issue (where that is only
enabled with GCC 6 or later).
PR: 222268
Approved by: portmgr (antoine)
MFH: 2017Q3