FreeBSD Port: net-p2p/mldonkey - mldonkey 3.1.3
mldonkey gad released a new version 3.1.3 It add a new option filenames_utf8, Would you release FreeBSD version? Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each ${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
Regards,
signature.asc
Description: This is a digitally signed message part.
Re: [HEADSUP] current switched by default to pkgng
Hello, Baptiste. You wrote 3 ноября 2012 г., 3:56:22: BD The BSDmc project (http://code.google.com/p/bsdmc/) uses nanobsd BD and pkgng, have a look in particular at the BD following diff: http://code.google.com/p/bsdmc/source/detail?r=75 BD Maybe you can find something helpful for you in there :) Unfortunately, it diverged with nanobsd long time ago and have completely custom package installation function, very complex and unobvious. Now I have only one problem with replacing `pkg_add' with `pkg add' (I've implemented bootstrap of chrooted environment): `pkg add' doesn't have `-F' flag, and attempt to add package twice (first time as dependency and second time because simple nanobsd script doesn't sort packages and add all of them, so required package could be again added after dependant package) leads to non-success return code :( Also, I could not find any documentation about system `pkg' command: `man pkg' shows nothing, `pkg -h' doesn't work, etc. So it is unobvious, where could I read about ASSUME_ALWAYS_YES, PACKAGESITE and other variables, needed for automatic (non-interactive, non-networked) bootstrap. Way to construct proper URL for pkg.txz (with ABI, etc) from script is not clear, too, and automatic downloading doesn't work in chrooted environment, as it doesn't have configured resolver. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: net-p2p/mldonkey - mldonkey 3.1.3
Try this. To use it, cd into the port directory, ports/net-p2p/mldonkey , and run this command: # patch /path/to/file/attached Then you should be able to build the new mldonkey. Please give it a thorough testing, and, if everything works, we can send it as a PR and get someone to commit it. It would also be good if you could test the other ports that depend on it, to see if anything needs to be done to update them as well. You can start with this list: http://www.freshports.org/search.php?query=mldonkeysearch=gonum=10stype=namemethod=matchdeleted=excludedeletedstart=1casesensitivity=caseinsensitive Thanks, Robert Backhaus. On 3 November 2012 17:05, aspire future tabs...@yahoo.com.tw wrote: mldonkey gad released a new version 3.1.3 It add a new option filenames_utf8, Would you release FreeBSD version? Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org mldonkey.diff Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
LIB_DEPENDS and a library ABI version
Hi All,
what's the right way to determine ABI version number (and specify
it at a port)?
For textproc/goldendict portlint suggests:
-
LIB_DEPENDS=hunspell-1:${PORTSDIR}/textproc/hunspell
-
The library itself is:
-
% ls -l /usr/local/lib/libhunspell-1.3.*so*
lrwxr-xr-x 1 root wheel 20 28 авг 23:41
/usr/local/lib/libhunspell-1.3.so - libhunspell-1.3.so.0
-rwxr-xr-x 1 root wheel 368752 28 авг 23:41
/usr/local/lib/libhunspell-1.3.so.0
-
Should I use LIB_DEPENDS=hunspell-1.3:... (since only 0
is after .so?
Some libraries seems to place .so suffix at a random position:
-
libspreadsheet-1.10.17.so
liblua-5.1.so.1
libwx_base-2.8.so.0.8.0
-
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
net-p2p/retroshare VoIP plugin: Undefined symbol
Hi All, I'm currently trying to get the VoIP plugin from RetroShare to work under FreeBSD. After this patch I was able to build it: --- plugins/VOIP/services/rsvoipitems.cc~ 2012-02-26 18:13:54.0 +0100 +++ plugins/VOIP/services/rsvoipitems.cc2012-10-29 12:53:56.650925587 +0100 @@ -182,7 +182,7 @@ ok = setRawUInt32(data, tlvsize, offset, flags); ok = setRawUInt32(data, tlvsize, offset, data_size); std::cerr data_size : data_size std::endl; -memcpy(data+offset,voip_data,data_size) ; +memcpy(((uint8_t*)data)[offset],voip_data,data_size) ; offset += data_size ; if (offset != tlvsize) But I can't get RetroShare to load it: Cannot open plugin: /home/user/.retroshare/extensions/libVOIP.so: Undefined symbol _ZN9p3Service7receiveEP9RsRawItem Now the symbol is part of the RetroShare binary: $ grep _ZN9p3Service7receiveEP9RsRawItem work/trunk/retroshare-gui/src/RetroShare Binary file work/trunk/retroshare-gui/src/RetroShare matches but somehow the symbols from the main binary do not get exported to the plugin. The FreeBSD man page for dlopen(3) states in the NOTES section ELF executables need to be linked using the -export-dynamic option to ld(1) for symbols defined in the executable to become visible to dlsym(). So I rebuilt RetroShare with the -export-dynamic option, and the symbol is part of the symbol table: $ objdump -t work/trunk/retroshare-gui/src/RetroShare | grep _ZN9p3Service7receiveEP9RsRawItem 00809580 g F .text 00c7 _ZN9p3Service7receiveEP9RsRawItem but still to no avail (same undefined symbol error). My knowledge of ELF binaries is pretty sparse, so if someone has more clues, I would appreciate sharing :) Thanks Peter ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-p2p/retroshare VoIP plugin: Undefined symbol
On Sat, Nov 03, 2012 at 01:59:18PM +0100, Peter Klett wrote: Hi All, I'm currently trying to get the VoIP plugin from RetroShare to work under FreeBSD. After this patch I was able to build it: --- plugins/VOIP/services/rsvoipitems.cc~ 2012-02-26 18:13:54.0 +0100 +++ plugins/VOIP/services/rsvoipitems.cc2012-10-29 12:53:56.650925587 +0100 @@ -182,7 +182,7 @@ ok = setRawUInt32(data, tlvsize, offset, flags); ok = setRawUInt32(data, tlvsize, offset, data_size); std::cerr data_size : data_size std::endl; -memcpy(data+offset,voip_data,data_size) ; +memcpy(((uint8_t*)data)[offset],voip_data,data_size) ; offset += data_size ; if (offset != tlvsize) But I can't get RetroShare to load it: Cannot open plugin: /home/user/.retroshare/extensions/libVOIP.so: Undefined symbol _ZN9p3Service7receiveEP9RsRawItem Now the symbol is part of the RetroShare binary: $ grep _ZN9p3Service7receiveEP9RsRawItem work/trunk/retroshare-gui/src/RetroShare Binary file work/trunk/retroshare-gui/src/RetroShare matches but somehow the symbols from the main binary do not get exported to the plugin. The FreeBSD man page for dlopen(3) states in the NOTES section ELF executables need to be linked using the -export-dynamic option to ld(1) for symbols defined in the executable to become visible to dlsym(). So I rebuilt RetroShare with the -export-dynamic option, and the symbol is part of the symbol table: $ objdump -t work/trunk/retroshare-gui/src/RetroShare | grep _ZN9p3Service7receiveEP9RsRawItem 00809580 g F .text 00c7 _ZN9p3Service7receiveEP9RsRawItem but still to no avail (same undefined symbol error). My knowledge of ELF binaries is pretty sparse, so if someone has more clues, I would appreciate sharing :) The objdump -t dumps wrong table. You want to examine the output of -T AKA --dynamic-syms. pgpPoCweZVYHj.pgp Description: PGP signature
Re: Poudriere not registering OPTIONS changes?
Make sure you have this in your /usr/local/etc/poudriere.conf: facepalm Aww man, I'm sorry. When I read up on the feature I never realized it was something *optional*, so I never thought of looking in the config file, where it is plain as day. I turned it on as you indicated and it works like a charm. Thank you very much! -Martin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: net-p2p/retroshare VoIP plugin: Undefined symbol
Perfect, that clue just did it, turns out RetroShare uses g++ for linking which has a slightly different parameter -rdynamic instead of -export-dynamic. Setting this option while linking the RetroShare binary brings the symbol in the dynamic exported table and lets the binary finally load the plugin. Thanks Konstantin for your input. Am 2012-11-03 15:53, schrieb Konstantin Belousov: On Sat, Nov 03, 2012 at 01:59:18PM +0100, Peter Klett wrote: Hi All, I'm currently trying to get the VoIP plugin from RetroShare to work under FreeBSD. After this patch I was able to build it: --- plugins/VOIP/services/rsvoipitems.cc~ 2012-02-26 18:13:54.0 +0100 +++ plugins/VOIP/services/rsvoipitems.cc2012-10-29 12:53:56.650925587 +0100 @@ -182,7 +182,7 @@ ok = setRawUInt32(data, tlvsize, offset, flags); ok = setRawUInt32(data, tlvsize, offset, data_size); std::cerr data_size : data_size std::endl; -memcpy(data+offset,voip_data,data_size) ; +memcpy(((uint8_t*)data)[offset],voip_data,data_size) ; offset += data_size ; if (offset != tlvsize) But I can't get RetroShare to load it: Cannot open plugin: /home/user/.retroshare/extensions/libVOIP.so: Undefined symbol _ZN9p3Service7receiveEP9RsRawItem Now the symbol is part of the RetroShare binary: $ grep _ZN9p3Service7receiveEP9RsRawItem work/trunk/retroshare-gui/src/RetroShare Binary file work/trunk/retroshare-gui/src/RetroShare matches but somehow the symbols from the main binary do not get exported to the plugin. The FreeBSD man page for dlopen(3) states in the NOTES section ELF executables need to be linked using the -export-dynamic option to ld(1) for symbols defined in the executable to become visible to dlsym(). So I rebuilt RetroShare with the -export-dynamic option, and the symbol is part of the symbol table: $ objdump -t work/trunk/retroshare-gui/src/RetroShare | grep _ZN9p3Service7receiveEP9RsRawItem 00809580 g F .text 00c7 _ZN9p3Service7receiveEP9RsRawItem but still to no avail (same undefined symbol error). My knowledge of ELF binaries is pretty sparse, so if someone has more clues, I would appreciate sharing :) The objdump -t dumps wrong table. You want to examine the output of -T AKA --dynamic-syms. -- netkey information technology gmbh amalienstrasse 68/6 | a-1130 vienna | austria t +43 1 888 49 93 -21 | f dw -25 e pe...@netkey.at | i www.netkey.at ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: LIB_DEPENDS and a library ABI version
Hi Jason and All, 03.11.2012 16:46, Jason E. Hale пишет: Typically, you would want to leave off only what is after .so. Got it, thanks! 2All: BTW it would be nice to have some words about the matter at the Porter's Handbook... -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Poudriere not registering OPTIONS changes?
Curious, where did you read about this feature? Would be good to make it more clear how to enable. At the bottom of the following web page: http://wiki.freebsd.org/FreeBSDPackageBuildingComparison One of the listed strengths of Poudriere is Detects OPTIONS changes. I just read that and went with it. To me it's such a cool feature that I never thought there'd be a knob for it, much less one that's off by default. And I never thought of revisiting my poudriere.conf file, but that's my mistake. -Martin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Can not update firefox
Hello, I can not update firefox to 16.0.2,1 In file included from /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:16: ../../dist/system_wrappers/gtk/gtk.h:3:26: error: gtk/gtk.h: No such file or directory /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp: In member function 'void BloatEntry::Dump(PRIntn, FILE*, nsTraceRefcntImpl::StatisticsType)': /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 6 has type 'PRUint64' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 7 has type 'PRUint64' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 8 has type 'long unsigned int' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'PRUint64' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'long unsigned int' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp: In member function 'nsresult nsSystemInfo::Init()': /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:107: error: 'gtk_major_version' was not declared in this scope /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:107: error: 'gtk_minor_version' was not declared in this scope /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:107: error: 'gtk_micro_version' was not declared in this scope gmake[4]: *** [nsSystemInfo.o] Error 1 gmake[4]: *** Waiting for unfinished jobs gmake[4]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base' gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom' gmake[2]: *** [libs_tier_platform] Error 2 gmake[2]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release' gmake[1]: *** [tier_platform] Error 2 gmake[1]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release' gmake: *** [default] Error 2 *** [do-build] Error code 1 Cheers, -- David Demelier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Can not update firefox
On 03/11/2012 20:13, David Demelier wrote: Hello, I can not update firefox to 16.0.2,1 In file included from /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:16: ../../dist/system_wrappers/gtk/gtk.h:3:26: error: gtk/gtk.h: No such file or directory /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp: In member function 'void BloatEntry::Dump(PRIntn, FILE*, nsTraceRefcntImpl::StatisticsType)': /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 6 has type 'PRUint64' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 7 has type 'PRUint64' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 8 has type 'long unsigned int' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 11 has type 'PRUint64' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsTraceRefcntImpl.cpp:384: warning: format '%8llu' expects type 'long long unsigned int', but argument 12 has type 'long unsigned int' /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp: In member function 'nsresult nsSystemInfo::Init()': /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:107: error: 'gtk_major_version' was not declared in this scope /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:107: error: 'gtk_minor_version' was not declared in this scope /usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base/nsSystemInfo.cpp:107: error: 'gtk_micro_version' was not declared in this scope gmake[4]: *** [nsSystemInfo.o] Error 1 gmake[4]: *** Waiting for unfinished jobs gmake[4]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom/base' gmake[3]: *** [libs] Error 2 gmake[3]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release/xpcom' gmake[2]: *** [libs_tier_platform] Error 2 gmake[2]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release' gmake[1]: *** [tier_platform] Error 2 gmake[1]: Leaving directory `/usr/obj/usr/ports/www/firefox/work/mozilla-release' gmake: *** [default] Error 2 *** [do-build] Error code 1 Cheers, Sorry, that seems to be a broken /usr/ports, I wiped out and it worked. I was using the marcusmerge script to test mate desktop and that have break my ports. Cheers, -- David Demelier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
David Naylor naylor.b.da...@gmail.com writes: The post-package-script (run only if WITH_PKGNG is defined): - Amends the package so the arch label to 64bit WITH_PKGNG is checked too early. The port fails to fix arch on 10.0 without the variable being set explicitly in make.conf. http://svn.freebsd.org/changeset/ports/305637 To produce the package on an amd64 system do the following: # (cd /usr/ports/emulators/; patch -p0 /path/to/diff) # make -C /usr/src world DESTDIR=/i386 TARGET=i386 # mount -t devfs devfs /i386/dev # mkdir /i386/usr/ports # mount -t nullfs /usr/ports /i386/usr/ports # chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes This is probably easier to manage when using poudriere e.g. # poudriere jails -c -j 10i386 -v HEAD -a i386 -m allbsd # patch -Efsp0 -i /path/to/diff -d /poudriere/ports/default/ports/emulators # poudriere bulk -j 10i386 emulators/wine-fbsd64 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
science/getdp
Hey, does anyone use the science/getdp port? I took over maintainership, perhaps because at that time I was using it. Now I am working on updating it to 2.2.1, which is quite a jump from where it currently is at 1.2.1. Anyway, I just wanted to check with anyone to see if this would be a problem. Thanks, Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
