Based on multiple previous maintainer's timeouts:
bug#255239 - 8+ months
bug#255673 - 7+ months
bug#254121 - 14 days
Approved by: portmgr (maintainer reset after multiple maintainer's timeouts on this port)
A new USES has been added to depend on ImageMagick.
USES=magick
adds a LIB_DEPENDS on graphics/ImageMagick${IMAGEMAGICK_DEFAULT}.
If a specific version is required, use for example
USES=magick:6 resp. USES=magick:7
If only a build, run or test is required, use for example
USES=magick:build resp. USES=magick:6,build,test
If a dependency on the nox11 flavor is required, use for example
USES=magick:nox11 resp. USES=magick:7,nox11,run,test
See magick.mk for more details on the available flags.
The tree has been completely converted to make use of this.
Approved by: bapt
Differential Revision: https://reviews.freebsd.org/D32754
The conflict checks compare the patterns first against the package
names without version (as reported by "pkg query "%n"), then - if
there was no match - agsinst the full package names including the
version (as reported by "pkg query "%n-%v").
Approved by: portmgr (blanket)
Before both flavors installed headers and .cm files.
This caused them to conflict with each other.
This commit removes conflicting files from the @x11 flavor
allowing the executable to be installed in parallel with libraries.
The executable seems to work in a standalone mode fine, but if it ever
needs headers or .cm files the @shlib flavor can always be installed.
PR: 259809
Tested by: kevinz5000@gmail.com
/wrkdirs/usr/ports/cad/openvsp/work/.build/Libraries-prefix/src/Libraries-build/EIGEN-prefix/src/EIGEN/Eigen/src/Core/arch/AltiVec/PacketMath.h:1340:32: error: use of undeclared identifier 'vec_sqrt'; did you mean 'vec_rsqrte'?
BF16_TO_F32_UNARY_OP_WRAPPER(vec_sqrt, a);
The conflict checks compare the patterns first against the package
names without version (as reported by "pkg query "%n"), then - if
there was no match - agsinst the full package names including the
version (as reported by "pkg query "%n-%v").
Many CONFLICTS definitions used patterns like "bash-[0-9]*" to filter
for the bash package in any version. But that pattern is functionally
identical with just "bash".
Approved by: portmgr (blanket)
ONLY_FOR_ARCHS_REASON is used as part of the sentence and thus should
start with lower-case letter and not end with a period which is added
by the framework, similar to other knobs like BROKEN, IGNORE, et al.
While here, remove needless quoting, add missing Oxford comma, expand
contractions and jargonisms, use correct spelling for proper names.
While here, make sure gtk-update-icon-cache is only on run dependency
where added as a dependency
Enforce gtk3 to depend on gtk-update-icon-cache (previously it was
inheriting the dependency)
Restore the patch accidentally removed due to an out of date comment.
8a4af42707 removed pthread_setname_np references.
src/libslic3r/Thread.cpp:13:10: fatal error: 'tbb/tbb_thread.h' file not found
#include <tbb/tbb_thread.h>
^~~~~~~~~~~~~~~~~~
The option implied a dependency on gcc but clang got openmp support long ago.
Remove compiler:openmp from Mk/Uses/compiler.mk
For ports using USE=compiler:openmp, just remove it and make them build with
clang.
Fix conditionals when necessary
Bump PORTREVISION where appropriate
If problem arises, they can be addressed by using USE_GCC=yes
An update to the Porter's Handbook will follow.
Approved by: portmgr (bapt)
Differential Revision: https://reviews.freebsd.org/D31971
verilator requires the GNU ar feature: '@' file prefix indicating
that the file contains command-line options.
Reference: https://github.com/verilator/verilator/issues/2999
Reported by: Antonin Houska <ah@melesmeles.cz>
github's patch file is switching the commit hashes between 11 and
12 digits: see also f4bd9d5c50, and today
pkg-fallout complained that the patch file was back at it's "original"(?)
format: "size mismatch: expected 34578, actual 34604", log:
http://beefy18.nyi.freebsd.org/data/main-amd64-default/pb6f59eeeccee_s297e9f364b/logs/FreeCAD-0.19.2_3.log
I regret having to put that patch into files/, but that seems better
than to host other project's patches ourselfes.
While here, garbage-collect files/ae641dc5278efaf.patch, which is not
referenced anymore and was applied upstream for FreeCAD 0.19.2.
Switch to GCC because of missing libomp for powerpc:
In file included from /wrkdirs/usr/ports/cad/meshlab/work/meshlab-Meshlab-2020.05/src/common/filterparameter.cpp:28:
In file included from /usr/local/include/vcglib/vcg/math/matrix44.h:33:
/usr/local/include/vcglib/eigenlib/Eigen/Core:247:10: fatal error: 'omp.h' file not found
the generated patch from github now has 11-digit short-hases
(previously we got 12 digits there).
The whole diff between the old and the new file consists of lines like
-index 14a6d9a763f0..0e9b9e6c9057 100644
+index 14a6d9a763f..0e9b9e6c905 100644
and no other changes.
- switches opencascade to vtk9 to enable upcoming import of
cad/py-ocp
- cad/freecad has to switch vtk8 -> vtk9, too
- this requires upstream commit 0cfea3fee3e7848bbf043d2b1a19f6405d7ebe25
"Make smesh compile with vtk9"
- while touching this, fixes vtk module detection
- clean up VTK_DIR usage: that variable does not exist in FreeCAD's
build system anymore (for quite some time, actually)
Obtained from: opencascade upstream: Kirill Gavrilov
Obtained from: freecad upstream: committed by github/wwmayer
Differential Revision: D30934
Reported by: thierry@
Submitted by: thierry@
QtChooser allows you to select your version of Qt among those installed.
However, this tool is no longer supported upstream and will not be
available for Qt6.
By default, our Qt installations are done in
${LOCALBASE}/lib/qt${QT_VERSION} as recommended.
We have added symbolic linking for the main binaries to
${LOCALBASE}/bin with the suffix -qt5.
Per discussion with bapt on helping pkg handle the changing of these
deps and avoiding impossible upgrade senarios.
PR: 246767
Reviewed by: manu, bapt
Approved by: x11
Differential Revision: https://reviews.freebsd.org/D30824
From [1]
* What is new in gsl-2.7:
* fixed doc bug for gsl_histogram_min_bin (lhcsky at 163.com)
* fixed bug #60335 (spmatrix test failure, J. Lamb)
* fixed bug #36577
* clarified documentation on interpolation accelerators (V. Krishnan)
* fixed bug #45521 (erroneous GSL_ERROR_NULL in ode-initval2, thanks to M. Sitte)
* fixed doc bug #59758
* fixed bug #58202 (rstat median for n=5)
* added support for native C complex number types in gsl_complex
when using a C11 compiler
* upgraded to autoconf 2.71, automake 1.16.3, libtool 2.4.6
* updated exponential fitting example for nonlinear least squares
* added banded LU decomposition and solver (gsl_linalg_LU_band)
* New functions added to the library:
- gsl_matrix_norm1
- gsl_spmatrix_norm1
- gsl_matrix_complex_conjtrans_memcpy
- gsl_linalg_QL: decomp, unpack
- gsl_linalg_complex_QR_* (thanks to Christian Krueger)
- gsl_vector_sum
- gsl_matrix_scale_rows
- gsl_matrix_scale_columns
- gsl_multilarge_linear_matrix_ptr
- gsl_multilarge_linear_rhs_ptr
- gsl_spmatrix_dense_add (renamed from gsl_spmatrix_add_to_dense)
- gsl_spmatrix_dense_sub
- gsl_linalg_cholesky_band: solvem, svxm, scale, scale_apply
- gsl_linalg_QR_UD: decomp, lssolve
- gsl_linalg_QR_UU: decomp, lssolve, QTvec
- gsl_linalg_QR_UZ: decomp
- gsl_multifit_linear_lcurvature
- gsl_spline2d_eval_extrap
* bug fix in checking vector lengths in gsl_vector_memcpy (dieggsy@pm.me)
* made gsl_sf_legendre_array_index() inline and documented
- gsl_sf_legendre_nlm()
[1] http://git.savannah.gnu.org/cgit/gsl.git/tree/NEWS
PR: 256423
Exp-run by: antoine
During an exp-run for llvm 12 (see bug 255570), it turned out that
cad/brlcad does not build with clang 12.0.0:
[ 99% 4379/4403] cd /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/db/nist && /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/bin/step-g -O /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/share/db/nist/NIST_MBE_PMI_11.g /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/db/nist/NIST_MBE_PMI_11.stp > /wrkdirs/usr/ports/cad/brlcad/work/brlcad-7.30.2/db/nist/NIST_MBE_PMI_11.log 2>&1
FAILED: share/db/nist/NIST_MBE_PMI_11.g
What happens is that the step-g intermediate program segfaults, because
it attempts to access a null pointer. Valgrind shows:
Reading Data from /wrkdirs/share/dim/ports/cad/brlcad/work/brlcad-7.30.2/db/nist/NIST_MBE_PMI_11.stp...
HEADER read:
==24919== Invalid read of size 4
==24919== at 0x1337BA10: EntList::firstNot(JoinType) (entlist.cc:39)
==24919== by 0x1337C93E: nextNot (complexSupport.h:185)
==24919== by 0x1337C93E: AndList::matchNonORs(EntNode*) (non-ors.cc:135)
==24919== by 0x1337B77C: ComplexList::matches(EntNode*) (complexlist.cc:176)
==24919== by 0x1337B36A: ComplexCollect::supports(EntNode*) const (collect.cc:140)
==24919== by 0x1335FA5A: STEPcomplex::Initialize(char const**, char const*) (STEPcomplex.cc:126)
==24919== by 0x1335F774: STEPcomplex::STEPcomplex(Registry*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const**, int, char const*) (STEPcomplex.cc:33)
==24919== by 0x1331842E: STEPfile::CreateSubSuperInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, int, ErrorDescriptor&) (STEPfile.cc:1048)
==24919== by 0x13315E15: STEPfile::CreateInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) (STEPfile.cc:833)
==24919== by 0x133158B1: STEPfile::ReadData1(std::__1::basic_istream<char, std::__1::char_traits<char> >&) (STEPfile.cc:502)
==24919== by 0x13319EA8: STEPfile::AppendFile(std::__1::basic_istream<char, std::__1::char_traits<char> >*, bool) (STEPfile.cc:1674)
==24919== by 0x1331C984: STEPfile::ReadExchangeFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool) (STEPfile.inline.cc:119)
==24919== by 0x3AFDCE: STEPWrapper::load(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) (STEPWrapper.cpp:1300)
==24919== Address 0x8 is not stack'd, malloc'd or (recently) free'd
==24919==
==24919==
==24919== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==24919== Access not within mapped region at address 0x8
==24919== at 0x1337BA10: EntList::firstNot(JoinType) (entlist.cc:39)
==24919== by 0x1337C93E: nextNot (complexSupport.h:185)
==24919== by 0x1337C93E: AndList::matchNonORs(EntNode*) (non-ors.cc:135)
==24919== by 0x1337B77C: ComplexList::matches(EntNode*) (complexlist.cc:176)
==24919== by 0x1337B36A: ComplexCollect::supports(EntNode*) const (collect.cc:140)
==24919== by 0x1335FA5A: STEPcomplex::Initialize(char const**, char const*) (STEPcomplex.cc:126)
==24919== by 0x1335F774: STEPcomplex::STEPcomplex(Registry*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const**, int, char const*) (STEPcomplex.cc:33)
==24919== by 0x1331842E: STEPfile::CreateSubSuperInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, int, ErrorDescriptor&) (STEPfile.cc:1048)
==24919== by 0x13315E15: STEPfile::CreateInstance(std::__1::basic_istream<char, std::__1::char_traits<char> >&, std::__1::basic_ostream<char, std::__1::char_traits<char> >&) (STEPfile.cc:833)
==24919== by 0x133158B1: STEPfile::ReadData1(std::__1::basic_istream<char, std::__1::char_traits<char> >&) (STEPfile.cc:502)
==24919== by 0x13319EA8: STEPfile::AppendFile(std::__1::basic_istream<char, std::__1::char_traits<char> >*, bool) (STEPfile.cc:1674)
==24919== by 0x1331C984: STEPfile::ReadExchangeFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, bool) (STEPfile.inline.cc:119)
==24919== by 0x3AFDCE: STEPWrapper::load(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) (STEPWrapper.cpp:1300)
==24919== If you believe this happened as a result of a stack
==24919== overflow in your program's main thread (unlikely but
==24919== possible), you can try to increase the size of the
==24919== main thread stack using the --main-stacksize= flag.
==24919== The main thread stack size used in this run was 16777216.
To fix this, add null pointer checks to EntList::firstNot() and various
other EntList functions.
Approved by: erik@brlcad.org (maintainer)
PR: 256166
MFH: 2021Q2
The port had been makred broken due to build issed with fig2dev
version 3.2.7, which has been upgraded to 3.2.8a, allowing this
port to be built again.
USE_GCC=any has been equivalent to USE_GCC=yes in most cases (such
as i386 and amd64 since 12.x and depending on configuration 11.x,
most newer installations on other platforms, and 13.x across the
board).
Since commit 96c17633d9 Mk/bsd.gcc.mk is treating them as
different spellings of the same, so continue the deorbiting of the
USE_GCC=any form and simply replace it with USE_GCC=yes.
This should not make any functional difference at all.
Discussed with: mat, linimon, pkubaj
Since the previous update changed USES=python from 3.6+ to 3.7+, all
dependent ports must have USES=python:3.7+ as well, otherwise it breaks
the @py36 flavor.
PR: 255347
Reported by: sunpoet
For ports that already use the licenses framwork, merge the content of
RESTRICTED/NO_CDROM/LEGAL* entries into LICENSEs.
Approved by: rene
Differential Revision: https://reviews.freebsd.org/D30010
These ports, not maintained by kde@, use KDE Frameworks
and require kdoctools to build. Since that is no longer
an implicit build & run dependency, (re)introduce it
explicitly as a build-time dependency.
No revision bump tool that we have cleans them up or deals with
them, so we end up with duplicated lines. Instead of implementing
that just clean up the 51 ports that do this.
PORTREVISION and PORTEPOCH can be set to 0 explicitly instead if
you need a reminder or placeholder.
