- ftp downloads are no longer provided upstream
- PORTREVISION is not bumped:
- on amd64 there is no change as the upstream binaries have not been
rebuilt; and
- on i386 the build is IGNOREd by default
- the next round of binary updates to wine will include this change
PR: 219775
Submitted by: rozhuk.im@gmail.com
* 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
The dist files were erroniously rebuilt and uploaded. The PORTREVISION is
not being bumped due to the complexities of the wine ports and no functional
change were introduced (only some timestamps were altered).
UNIQUENAME was never unique, it was only used by USE_LDCONFIG and now,
we won't have conflicts there.
Use PKGBASE instead of LATEST_LINK in PKGLATESTFILE, the *only* consumer
is pkg-devel, and it works just fine without LATEST_LINK as pkg-devel
has the correct PKGNAME anyway.
Now that UNIQUENAME is gone, OPTIONSFILE is too. (it's been called
OPTIONS_FILE now.)
Reviewed by: antoine, bapt
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3336
The i386-wine ports bundle their own (32-bit) libraries that cause pkg-1.5
issues. Since these libraries are under lib32 it does not cause issues
with other software.
Bump PORTREVISION [1] for the 32-bit side of the ports. The 64-bit side of
the ports will be bumped when new packages have been prepared.
Approved by: gerald@ [1]
Reported by: bapt@
For example (${OSVERSION} >= 900000 && ${OSVERSION} < 900021) is always true,
as is (${OSVERSION} > 900002 || ${OSVERSION} < 900000 && ${OSVERSION} > 800107).
Regarding patches, when an EXTRA_PATCHES is no longer needed, I remove it, when
it is always needed, I renamed it, in one case, I merged two patches.
Differential Revision: https://reviews.freebsd.org/D2209
Changes:
- Fix install conflicts [1] (for the "newly" added compholio port)
- Reduce diff between i386-wine and i386-wine-devel:
- Add support for sub-ports (unused by this port)
- Update OSVERSION constraints
Changes:
- Fix install conflicts [1] (for the "newly" added compholio port)
- nvidia.sh: Gracefully handle a corrupt nVidia tarball
- nvidia.sh: Provide checksum and size information for nVidia tarball
- Reduce diff between i386-wine and i386-wine-devel:
- Add support for sub-ports (unused by this port)
- Properly detect linked (and dlopen) libraries
- binbounce: Properly set LD_(32_)?LIBRARY_PATH_RPATH variables
- nvidia.sh: Add detection for i386-wine-compholio
- Bump master port [1] due to changes to binbounce, nvidia.sh and shared
library handling.
Approved by: gerald@ [1]
With the removal of REINPLACE_PLIST in r367153 building wine on FreeBSD/i386
broke. This was not detected in an exp-run as i386-wine is marked IGNORE
unless WINE_CROSS_BUILD is defined (to protect the build infrastructure and
avoid confusion).
PR: 193734
Merge back bsd.pkgng.mk into bsd.port.mk
Add a note about @stopdaemon not being supported anymore
With hat: portmgr
Differential Revision: https://reviews.freebsd.org/D693
Due to the hackery things these ports do to properly work under amd64, it
results in issues for pkg. This port - although it needs to build under
i386 - is not intended to be consumed under i386. The normal wine(-devel)?
ports should be consumed on an i386 system and these ports should be
consumed on an amd64 system. [1]
Reorder the library detection to pick up soft dependencies first, then the
linked to libraries. Prior to this change any libraries required by a soft
dependency wasn't bundled, for example libgnutls.so.28 did not have its
dependencies bundled. [2][3]
Requested by: bdrewery [1]
Reported by: Joseph Mingrone <jrm@ftfl.ca> [2]
Beeblebrox <zaphod@berentweb.com> [3]
