* The MATE DE is now GTK+3 based
* mate-calc has come back.
* New USE_MATE=mixer macro
* Add license
* Review dependancies
* Swich to USES=localbase
* atril/eom options reworked into option helper
Thanks to Eric Turgeon for submitting the bulk of this MATE update.
Obtained from: gnome devel repo
Move `files.pythonhosted.org` mirror to the top
The mirror `pypi.python.org` soon will be replaced with the
new Warehouse [1][2], now it's only serving the old files
and its returning `404 - Not Found` to the new files hosted
[1] https://pypi.org
[2] https://github.com/pypa/warehouse
Approved by: garga (mentor), python (sunpoet)
Differential Revision: https://reviews.freebsd.org/D11420
Using ninja instead of make (1) can lead to significant speed ups while building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
* qtdiag outputs diagnostics on the current Qt installation and can be helpful to find issues.
* qtpluginfo is useful while writing plugins for Qt5/KDE Plasma
Reviewed by: rakuco, mat
Differential Revision: https://reviews.freebsd.org/D11280
If NO_ARCH is set then check that no FreeBSD elf(5) files are in $STAGEDIR.
If an elf(5) file is bundles as part of the package, but is not meant to be
run directly (i.e. the elf(5) file is a payload, and not compiled) then
those files can be added to NO_ARCH_IGNORE to avoid the check from failing,
Changes to ports:
- Ports that have NO_ARCH set, but actually compile files have had NO_ARCH
removed.
- Ports that have elf(5) payloads have had those files added to
NO_ARCH_IGNORE.
- R-cran ports that do not set USES=cran:compiles have NO_ARCH set,
PR: 218976
Reviewed by: antoine, mat
Approved by: portmgr
The port's own USES may note that is only supports certain versions. If it
is attempted to build an unsupported version there's no reason to even
try. Rather than giving a WARNING, actually mark it IGNORE.
Currently this should only impact devel/py3-enum34 which does not support
the default python3 version of 3.6.
With hat: portmgr
For example a option of the "boolean" type only accepts true/false this
option is covered by ${opt}_MESON_TRUE/_FALSE.
Add option helpers ${opt}_MESON_YES/_NO for the "combo" type which
accepts yes and no.
Approved by: portmgr@ (mat@)
Differential Revision: https://reviews.freebsd.org/D11078
libdata/pkgconfig.
Fix ports that where installing the file in the wrong place.
PR: 218067
Submitted by: mat
Exp-run by: antoine
Reviewed by: rene, antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D10129
gold linker from binutils 2.28 may produce duplicate library
symbols, which makes shared libraries created with it not usable
with conventional ld linker.
PR: 218187
Submitted by: amdmi3
A few important changes:
- '.' is no longer in @INC.
- "do" now gives a deprecation warning when it fails to load a file
which it would have loaded had "." been in @INC.
- In regular expression patterns, a literal left brace "{" should be
escaped.
Changes: https://metacpan.org/pod/release/XSAWYERX/perl-5.26.0/pod/perldelta.pod
Sponsored by: Absolight
- Add 102m client and library version
- Add dynamic libmysqlclient dependency (libmariadb)
- Make WARNING and IGNORE messages display the correct port
Reviewed by: mmokhi
Differential Revision: https://reviews.freebsd.org/D10057
it will handle the dependencies on groff by using groff from ports if not
available in base
Reviewed by: swills
Approved by: swills
Differential Revision: https://reviews.freebsd.org/D9084
KDE has moved distfiles for applications 16.12.3 to Attic/ on their mirros.
Reported by: Matthias Apitz <guru@unixarea.de>
Reviewed by: rakuco
Approved by: rakuco (mentor, implicit)
Differential Revision: https://reviews.freebsd.org/D10830
makes ports build by meson respect the current policy regarding pkg-config
files. I picked this solution over hacking meson itself, and potential
breaking more.
Bump graphics/graphene due to this change.
Obtained from: Code copied from ports/218067 by mat@
USES=mono: minor fixes
- save a copy of the nuget package in the packages directory
- force linking of directories, allowing nuget-extract to be rerun
without `make clean`
- fix makenuget: nuget requires an equals to identify the version, not a dash
devel/monodevelop: update to 6.2.1.3
- update nuget packages:
- link older System.Collection.Immutable 1.1.37 to newer 1.3.1 (used
by C# and F# respectively)
- update external github repositories
- allow post-extract target to be run multiple times
- change MonoDevelop.Packaging to use a newer version of
NuGet.Build.Packaging (the older version is no longer fetchable)
- remove patch integrated upstream
- moved `nuget restore` patching from post-patch into a patch file (the
former broke silently)
- ChangeLog:
- https://developer.xamarin.com/releases/studio/xamarin.studio_6.2/xamarin.studio_6.2/
irc/smartirc4net: update to 1.1
- add LICENSE
lang/fsharp: update to 4.1.18
- add test dependency on libgdiplus
- update nuget packages
- update test paths for fsharp assemblies
- update patches to prevent `nuget restore` from running
- ChangeLog:
- Set executable bit correctly on output
- Integrate visualfsharp
- Fix regression on binding redirects for System.Collections.Immutable
- Fix regression in Microsoft.Build.FSharp.targets
- Fix binding redirects for System.Collections.Immutable
- Fix version of library going in %PREFIX/lib/mono/fsharp
- Align fsc task and target file
- Use install layout that includes mono/fsharp
- Fix F# Intereactive on Mono 4.9+
- Update compiler tools
- Updates to FSharp.Core nuget package for F# 4.1
- Fix#656: error FS0193: internal error: No access to the given key
lang/mono: various fixes
- fix linking with lld [1]
- double maximum handle size [2]
- add option to run acceptance tests
- allow for optional bootstrapping of mono via either installed mcs (if
available) or via downloaded "monolite" (default)
- add python and py-pillow as dependencies for bin/mono-heapviz
- add armv6 as a supported architecture (untested)
- switch to github for source code:
- official tarball does not include tests
- patches:
- recognise FreeBSD for AOT suffix
- change mono-heapviz to use pillow instead of PIL
multimedia/banshee: tell portscout to ignore this port
- Portscout was not skipping the 2.9.1 version, and upstream appears to be
quiet for the last few years.
x11-toolkits/gtk-sharp20: update to 2.12.43
- ChangeLog:
- fix compilation on mono-4.8.0 (incorrect use of sizeof())
- correctly set owned=true on custom constructors
PR: 218885 [1]
PR: 200937 [2]
* libGL, libEGL, libglesv2, libglapi, and gbm have been moved into mesa-libs,
graphics/dri has been renamed to mesa-dri, and USE_GL has been adjusted
* mesa-libs has a new WAYLAND option that enables platform support in libEGL
* mesa-dri now depends on graphics/s2tc for compressed texture support [1]
* re-remove obsolete dependency on makedepends [2]
* correct sed fix backported from 17.1 [3]
PR: 218799 (exp-run), 212762 [1], 218552 [2], 218562 [3]
Submitted by: dbn [1], jbeich [2,3]
Reported by: afiskon@devzen.ru [1]
Reviewed by: kwm, johalun0@gmail.com
Approved by: portmgr, swills (mentor)
Differential Revision: https://reviews.freebsd.org/D10448
and consequently many of the USES=compiler flavors use the canonical
version of GCC as defined in Mk/bsd.default-versions.mk as well as
the lang/gcc port
With the "new" setup starting with GCC 5 where I have introduced
lang/gcc5-devel for regular snapshots and lang/gcc5 for releases,
and similarly for GCC 6 and onward, we can now leverage lang/gcc5
(and later) for most of the role that lang/gcc used to play -- and
indeed as of today lang/gcc and lang/gcc5 are nearly identical
short of symlinks for gcc, g++, and gfortran binaries that the
former provides.
So now use lang/gcc5 instead of lang/gcc whenever requested via the
USE_GCC framework directly or indirectly.
This is similar to how the python ports work, for example, and it
allows simplifications in Mk/bsd.gcc.mk and Mk/Uses/fortran.mk and
dropping LANG_GCC_IS from Mk/bsd.default-versions.mk. As a next
step lang/gcc is going to become a "hull" essentially only providing
those symlinks and requiring lang/gcc5 (or whatever has been set as
default in Mk/bsd.default-versions.mk).
