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]
Changes:
* various: migrate USE_BZIP2 to USES=tar:bzip2
* various: migrate USE_XZ to USES=tar:xz
* multimedia/py-ffmpeg: add and prefer github (GH) as master site
* ports-mgmt/portbuilder: specify license as BSD2CLAUSE (instead of just BSD)
Most ports are updated infrequently so a single batch commit is preferred over
collating changes per port.
The distfile info for FreeBSD 8.3+ had been replaced with a duplicate
entry for th distfiles infor for FreeBSD 9.1+, this has been corrected.
Reported by: pkg-fallout
Subversion and pre-commit hooks are not cooperating in the changes
required for i386-wine(-devel).
For the historians: This file is a copy of i386-wine-devel/Makefile as
at version 321106.
With the introducation of binary packages for i386-wine-devel the
port itself is largely complete (although there are still problems with
3D acceleration, both with and without nVidia).
