Re: emulators/i386-wine-devel
On Sunday, 16 September 2018 23:51:01 SAST Rozhuk Ivan wrote: > On Sat, 15 Sep 2018 10:06:01 +0200 > Thanks! > I already subscribe to this and post few comments. > I have no choice - I need wine to few win programs. Is the current version of i386-wine(-devel) not working for you? I understand that these are become quite old version. I'm hoping that we can complete the lib32 work (and then the WOW64 patch) before things become too stale. Regards signature.asc Description: This is a digitally signed message part.
Re: emulators/i386-wine-devel
On Saturday, 01 September 2018 22:45:58 SAST Rozhuk Ivan wrote: > Hi! Hi > What happen with emulators/i386-wine-devel ? Honestly, I've lost interest in compiling the port. I'm working on a means to avoid manual compilation [1][2]. I've attached the scripts I use to build and update the ports - if anyone is interested. > I use it on FreeBSD 11.2 x64 to run old win32 apps. The above mentioned work will also make running win64 apps concurrently with win32 apps. Regards [1] https://reviews.freebsd.org/D14721 [2] https://reviews.freebsd.org/D16830 signature.asc Description: This is a digitally signed message part.
Re: Mono 5.2 patch and DotNet Core 2 update
On Wednesday, 10 January 2018 08:55:45 Russell Haley wrote: > Hi David, > > I've successfully built mono based on a modified version of your patch > from here: https://reviews.freebsd.org/D13752 > > I'm getting size and checksum errors for the file > dotnet-roslyn-322bd5b_GH0.tar.gz. This shouldn't be an issue: I > changed the size of the file in distinfo from 22058493 to the actual > size I received of 22058637 in order to make it build. My expectation > is that I should then run make checksum to fix the distinfo file > correctly. I run sudo make checksum and the target goes into an > infinite loop downloading the file, deciding it doesn't match the > checksum and then downloading it again. WTH? > > I am unsure how to proceed. The porters handbook is quite explicit > that this is the way forward: > https://www.freebsd.org/doc/en/books/porters-handbook/porting-checksum.html > > I have attached what I think is the svn diff that include both your > patch and my update. The distinfo file should still be incorrect. I > haven't tested it. I have to get to work . :P > > I have cc'd the ports list as well in this conversation. Any input > from all parties would be grand. Thank you for the review - I see you commented on the review. I'll try and finish the port over the weekend. FYI, I have uploaded another two reviews. These combined get the CentOS version of .NET Core running on FreeBSD :-). Regards signature.asc Description: This is a digitally signed message part.
Re: Help Wanted - Work with MSFT and help finish the port of .NET Core to FreeBSD
On Monday, 4 September 2017 10:54:21 Geoffrey Huntley wrote: > See https://www.youtube.com/watch?v=NHllisWOCpU and > https://twitter.com/GeoffreyHuntley/status/904227946084294656 Hi Geoffrey It is great to hear there is more interest in finishing the port of .NET Core to FreeBSD (and, I hope, to have ports living in the Port's Collection). Would it be possible for you to put me (and the mono@ mailing list) in touch with Karel and Tomas - I'm not on Twitter. I'll reply to this email (dropping ports@ and advocacy@) with more technical details. Regards David signature.asc Description: This is a digitally signed message part.
Re: make install for print/texinfo fails on -CURRENT
On Tuesday, 11 July 2017 08:47:17 Bob Willcox wrote: > Hmm, I just tried running synth on my test system again (this is the system > that I successfully built and install texinfo on just a bit ago) and synth > still fails with the same build errors as before. I'm not all that familiar > with synth, but it appears that it may be working with some old stuff. Hi (Replying to a random email) I've encountered the exact same issue while building the i386 packages for wine. Once I forced a rebuild of _all_ texinfo dependencies, installation worked. I suspect an ABI change in -CURRENT that broke a dependency (sounds like perl based on the thread). Regards signature.asc Description: This is a digitally signed message part.
Re: Which wine do I need?
On Sunday, 14 May 2017 23:23:05 Thomas Mueller wrote: > I see several different wine ports and would like to know which I need for > amd64 and which I need for an i386 installation. - On an i386 environment with 32-bit Windows binaries use lang/wine. - On an amd64 environment with 32-bit Windows binaries use lang/i386-wine. - On an amd64 environment with 64-bit Windows binaries use lang/wine. Note: a i386 chroot would be considered an i386 environment (even if the host environment/kernel was amd64) signature.asc Description: This is a digitally signed message part.
Re: Which wine do I need?
Hi On Saturday, 13 May 2017 08:16:55 Thomas Mueller wrote: > I see several different wine ports and would like to know which I need for > amd64 and which I need for an i386 installation. > > I don't really want i386-wine as such, since I would install wine on i386 > and could then mount this partition at /compat/i386 to run from amd64, > while retaining the ability to run from straight i386. This is effectively what i386-wine does: it bundles the required 32-bit libraries from a i386 host/environment and packages them such that they can run on an amd64 machine. > Am I correct that I would build wine (or wine-devel) on i386 and then > install wine or wine-devel on amd64? Correct, you should use the same port for both i386 and amd64, however if you are running Windows programs from /compat/i386 then there is no need to install wine on the amd64 host (unless you want to run 64-bit programs). > Am I better off doing this on FreeBSD 11-STABLE or on 12-HEAD? Normally CURRENT doesn't cause issues with wine, however STABLE will more, well, more stable. I wouldn't base the decision of CURRENT/STABLE on whats best for Wine. We do, however, need more people to test CURRENT. Regards signature.asc Description: This is a digitally signed message part.
Re: The mystery of the missing library.
On Wednesday, 29 July 2015 09:06:40 Konstantin Belousov wrote: On Wed, Jul 29, 2015 at 07:46:14AM +0200, David Naylor wrote: On Tuesday, 28 July 2015 22:05:54 Bart??omiej Rutkowski wrote: I've checked how linux does it and it seems they're (at least Debian) doing static linking - that would fix the issue, whatever it is. Can you adjust the port to do the static instead of dynamic linking binary? ``` # cd /usr/local/bin # rm pypy # ln ../pypy-2.6/bin/pypy # ls -l pypy -rwxr-xr-x 2 root wheel 5152 Jul 28 22:10 pypy # pypy Shared object libpypy-c.so not found, required by pypy # `which pypy` Shared object libpypy-c.so not found, required by pypy ``` I had a look at Debian and they seem to have quite a large patchset applied to pypy. Perhaps they patch it to make it work? Based on the documentation from pypy it appears they think a symlink should work. There were relatively recent (as in, Feb 2015) changes to always resolve symlinks for $ORIGIN expansion, using realpath. The changes are in HEAD and in stable/10, also in all 10.2 BETAs and RC. What version of the userspace do you use ? If not the versions listed above, try them. Hopefully, $ORIGIN starts behaving for you. I updated my system from 10.1 to 10.2-RC1 and it is fixed :-) ``` # ldconfig -r | grep pypy # pypy Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jul 28 2015, 18:57:04) [PyPy 2.6.0] on freebsd10 Type help, copyright, credits or license for more information. # ldd `which pypy` /usr/local/bin/pypy: libpypy-c.so = /usr/local/pypy-2.6/bin//libpypy-c.so (0x800a0) libthr.so.3 = /lib/libthr.so.3 (0x804537000) libc.so.7 = /lib/libc.so.7 (0x80475b000) libbz2.so.4 = /usr/lib/libbz2.so.4 (0x804b07000) libm.so.5 = /lib/libm.so.5 (0x804d19000) libintl.so.8 = /usr/local/lib/libintl.so.8 (0x804f42000) libz.so.6 = /lib/libz.so.6 (0x80514c000) libssl.so.7 = /usr/lib/libssl.so.7 (0x805362000) libcrypto.so.7 = /lib/libcrypto.so.7 (0x8055ce000) libexpat.so.1 = /usr/local/lib/libexpat.so.1 (0x8059c2000) libffi.so.6 = /usr/local/lib/libffi.so.6 (0x805be8000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x805def000) librt.so.1 = /usr/lib/librt.so.1 (0x80600f000) libutil.so.9 = /lib/libutil.so.9 (0x806215000) libncurses.so.8 = /lib/libncurses.so.8 (0x806427000) ``` signature.asc Description: This is a digitally signed message part.
Re: The mystery of the missing library.
On Tuesday, 28 July 2015 22:05:54 Bartłomiej Rutkowski wrote: I've checked how linux does it and it seems they're (at least Debian) doing static linking - that would fix the issue, whatever it is. Can you adjust the port to do the static instead of dynamic linking binary? ``` # cd /usr/local/bin # rm pypy # ln ../pypy-2.6/bin/pypy # ls -l pypy -rwxr-xr-x 2 root wheel 5152 Jul 28 22:10 pypy # pypy Shared object libpypy-c.so not found, required by pypy # `which pypy` Shared object libpypy-c.so not found, required by pypy ``` I had a look at Debian and they seem to have quite a large patchset applied to pypy. Perhaps they patch it to make it work? Based on the documentation from pypy it appears they think a symlink should work. Regards signature.asc Description: This is a digitally signed message part.
Re: The mystery of the missing library.
On Tuesday, 28 July 2015 17:08:37 Bryan Drewery wrote: On 7/28/15 11:46 AM, David Naylor wrote: Why would the shared library be found when using a relative path but not when using an absolute path? Is this a bug in FreeBSD? What is the output for readelf? readelf -d `which pypy`|grep -i libr ``` # readelf -d `which pypy` | grep -i libr 0x0001 (NEEDED) Shared library: [libpypy-c.so] 0x0001 (NEEDED) Shared library: [libthr.so.3] 0x0001 (NEEDED) Shared library: [libc.so.7] 0x000f (RPATH) Library rpath: [$ORIGIN/] 0x001d (RUNPATH)Library runpath: [$ORIGIN/] ``` signature.asc Description: This is a digitally signed message part.
The mystery of the missing library.
Hi Hackers, I am busy simplifying the lang/pypy port (see https://reviews.freebsd.org/D3209) however I have uncovered a rather strange problem: ## BACKGROUND ## PyPy has it's own directory layout so we install it into $PREFIX/pypy-2.6. In there is everything pypy needs including bin/pypy (the binary) and bin/libpypy-c.so (the shared library). For convenience we create a symlink to the pypy binary: ``` # ln -s ../pypy-2.6/bin/pypy $PREFIX/bin/pypy ``` ## PROBLEM ## For some reason FreeBSD cannot find the library when executing the pypy command - except under some situations: ``` # uname -a FreeBSD dragon.local 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 root@amd64- builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # cd / # pypy Shared object libpypy-c.so not found, required by pypy # `which pypy` Shared object libpypy-c.so not found, required by pypy # .`which pypy` Python 2.7.9 (295ee98b69288471b0fcf2e0ede82ce5209eb90b, Jul 26 2015, 18:38:23) [PyPy 2.6.0 with GCC 4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)] on freebsd10 Type help, copyright, credits or license for more information. # ldd `which pypy` /usr/local/bin/pypy: libpypy-c.so = not found (0) libthr.so.3 = /lib/libthr.so.3 (0x80081d000) libc.so.7 = /lib/libc.so.7 (0x800a42000) # ldd .`which pypy` ./usr/local/bin/pypy: libpypy-c.so = /usr/local/pypy-2.6/bin//libpypy-c.so (0x80081d000) libthr.so.3 = /lib/libthr.so.3 (0x804337000) libc.so.7 = /lib/libc.so.7 (0x80455c000) libbz2.so.4 = /usr/lib/libbz2.so.4 (0x804906000) libm.so.5 = /lib/libm.so.5 (0x804b18000) libintl.so.8 = /usr/local/lib/libintl.so.8 (0x804d4) libexpat.so.1 = /usr/local/lib/libexpat.so.1 (0x804f4a000) libz.so.6 = /lib/libz.so.6 (0x80517) libssl.so.7 = /usr/lib/libssl.so.7 (0x805386000) libcrypto.so.7 = /lib/libcrypto.so.7 (0x8055f1000) libffi.so.6 = /usr/local/lib/libffi.so.6 (0x8059e5000) libcrypt.so.5 = /lib/libcrypt.so.5 (0x805bec000) librt.so.1 = /usr/lib/librt.so.1 (0x805e0c000) libutil.so.9 = /lib/libutil.so.9 (0x806012000) libncurses.so.8 = /lib/libncurses.so.8 (0x806224000) ``` Why would the shared library be found when using a relative path but not when using an absolute path? Is this a bug in FreeBSD? Regards David signature.asc Description: This is a digitally signed message part.
Re: wine (-devel) and i386-wine
Hi Tom, On Monday, 1 September 2014 22:24:57 Thomas Mueller wrote: I read something about two days on www.freshports.org about wine and i386-wine that alters my plans. I tried to build i386-wine from i386 with the idea of using it both from i386 and amd64, in the latter case mounting the i386 partition on /compat/i386. But what I see makes that look not feasible. It is feasible to run the i386-wine ports from a 32bt environment - however it is not ideal. The port implements various hacks to get the package to work properly on an amd64 system that is simply not needed when running natively. If I want to run wine from both i386 and amd64 (not at the same time), do I need to make separate installations on separate partitions? In that case, how do I avoid wasteful duplication in compiling? I am getting ready to rebuild/update FreeBSD-current and possibly 10.0-STABLE from source, am planning to also make a new i386 installation on a hard drive in a USB 2.0 and eSATA enclosure, using eSATA. I want to do this soon, at least for FreeBSD-current because, after running svn up on FreeBSD src tree from NetBSD, I saw an update in $SRCDIR/sys/dev/re/if_re.c and want to see if that works on my Ethernet. I also want the new NFS improvements. If you are going to have a /compat/i386 chroot then you could install (normal 32bit) wine there and with the correct scripts run wine from that chroot without needing i386-wine at all (you will need to set up the correct PATH, LD_32_LIBRARY_PATH and LD_32_LIBRARY_PATH_RPATH variables). Alternatively, you could install wine on 32-bit and i386-wine on 64-bit and use those respectively. I hope this clarifies. Regards signature.asc Description: This is a digitally signed message part.
Re: [kde-freebsd] Error using CMake similar to error from earlier list post
Hi Joe, Apologies for taking so long to get back to you. Work got really, really busy. The underlying issue is that gcc pulls in the pthread headers by default while clang does not. I believe clang is following the more correct approach. The files you attached are for traverso however I do not see it in the Port's Collection. Are you building it directly from source? On Wednesday, 11 December 2013 21:02:27 Joe Nosay wrote: I'm attaching files. 1. Undeclared identifier pthread_self:: Does this mean I need to add the pthread.h before every declaration of pthread_self? No, you only need to add it once. Normally there will be a header file. I'm guessing either to src/engine/AudioDeviceThread.cpp or to a header file included by src/engine/AudioDeviceThread.cpp 2. How do I declare an identifier? I don't know what you are referring to, could you please elaborate? 3. CLang crashed somewhat at the beginning. Files are attached. I see. Can you please try with a newer version of clang/traverso. If that does not fix the issue, then please report that upstream to the LLVM developers, this is well beyond my capabilities to fix. The files will probably be too big for the mailing lists. Now, those errors which have references in section 2 of the man pages, do I replace as suggested with cpusetid_t. For others, do I introduce a patch similar to the pthread.h from the kopete patch? Yes, patches similar to pthread.h should work. Once you get the patches working please submit them upstream. It makes our lives easier if those developers maintain the patches, instead of us. Regards signature.asc Description: This is a digitally signed message part.
Re: [kde-freebsd] Error using CMake similar to error from earlier list post
Hi Joe,
I'm listening!
I've read through your thread on KDE-FreeBSD and Ports-FreeBSD however I am a
bit fuzzy as to the issues.
Are these specific to clang, FreeBSD = 10 or some other trigger? How would I
go about reproducing these errors?
I'm happy to work with you to resolve these issues.
Regards
On Tuesday, 10 December 2013 04:25:58 Joe Nosay wrote:
On Mon, Dec 9, 2013 at 11:18 PM, Joe Nosay superbisq...@gmail.com wrote:
-- Forwarded message --
From: Joe Nosay superbisq...@gmail.com
Date: Sun, Dec 8, 2013 at 6:38 PM
Subject: Re: Error using CMake similar to error from earlier list post
To: kde-freebsd kde-free...@kde.org
On Sat, Dec 7, 2013 at 3:45 PM, Joe Nosay superbisq...@gmail.com wrote:
On Fri, Dec 6, 2013 at 7:50 PM, Joe Nosay superbisq...@gmail.com wrote:
https://www.mail-archive.com/kde-freebsd@kde.org/msg15778.html
Is there a similar fix for this?
Thanks.
Now would
+Build fix for clang.
+
+ error: use of undeclared identifier 'pthread_mutex_lock'
+ error: use of undeclared identifier 'pthread_mutex_unlock'
+ error: use of undeclared identifier 'pthread_self'
+ error: use of undeclared identifier 'pthread_mutex_init'
+ error: use of undeclared identifier 'pthread_mutex_destroy'
+
+---
kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc.or
ig
2013-11-04 01:20:09.0 +0200
kopete/protocols/jabber/googletalk/libjingle/talk/base/ssladapter.cc
2013-11-04 01:20:20.0 +0200
+@@ -29,6 +29,7 @@
+
+ #ifdef POSIX
+ extern C {
++#include pthread.h
+ #include unistd.h
+ }
+ #endif
Be the appropriate fix for
/usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
read.cpp:58:30: error: use of undeclared identifier 'pthread_self'
if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
param) != 0) {}
^
/usr/home/raspycat/traverso/work/traverso-0.49.2/src/engine/AudioDeviceTh
read.cpp:131:30: error: use of undeclared identifier 'pthread_self'
if (pthread_setschedparam (pthread_self(), SCHED_FIFO,
param) != 0) {
I need to write a patch and then apply it to the script in question.
1. Will I need to add the patch to each part that is listed?
Since it is suggested to build an application natively - or at least try
to - on FreeBSD before making a port, I am trying to do such.
The errors seems to be the same CLang type as the others.
Included is the file which was modified according to the patch from the
hyperlink stated earlier in this thread.
Since this a CLang problem which has occurred and will occur in software
with the same or similar type of instructions, it may be of use to make a
patch for all qtX software and others with the same problem.
Me Did I do the patch right?
KDE FreeBSD Did you hear something?
Ports FreeBSD Nope, not at all.
GCC patchiness popping up here and there. I can see it and so can others.
KDE FreeBSD What was that?
Ports FreeBSD Nothing, nothing at all.
These problems also show up on Debian and other systems transitioning to
CLang for the compiler. Errors of the same type happen on software not in
ports or natively part of kde3/4.
KDE FreeBSD There goes that noise again.
Ports FreeBSD Just ignore it.
signature.asc
Description: This is a digitally signed message part.
Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Saturday, 23 November 2013 03:00:54 Gerald Pfeifer wrote: On Sat, 23 Nov 2013, Baptiste Daroussin wrote: This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? Yes. I just tested this, and in my environment it seems to work (passing the tests described in the Handbook). ports/184178 when you commit this. :) Thank you both for addressing this so quickly :-D signature.asc Description: This is a digitally signed message part.
lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
Hi All / Gerald, The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. If this has been fixed, my apologies for the noise. Regards On Thursday, 21 November 2013 20:25:41 Ports-QAT wrote: Add stage support for games/knights-kde4. - Build ID: 20131118181800-45853 Job owner: d...@freebsd.org Buildtime: 3 days Enddate: Thu, 21 Nov 2013 20:25:39 GMT Revision: r334234 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334234 - Port:games/knights-kde4 2.5.0_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228516/knig hts-2.5.0_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228517/knig hts-2.5.0_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND_OBJECT Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228518/knig hts-2.5.0_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228519/knig hts-2.5.0_2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131118181800-45853 redports https://qat.redports.org/ signature.asc Description: This is a digitally signed message part.
Re: poudriere + soundkonverter build fails
On Tuesday, 5 November 2013 14:54:12 Wolfgang Riegler wrote: Hi, Hi, building soundkonverter fails on 9.1 AMD64 with: /usr/local/include/taglib/mp4coverart.h:49: error: comma at end of enumerator list *** [CMakeFiles/soundkonverter.dir/metadata/tagengine.o] Error code 1 My options are: ---Begin OPTIONS List--- === The following configuration options are available for soundkonverter-2.0.4: NLS=on: Native Language Support Audio codec formats: you have to choose at least one of them AFTEN=on: ATSC A/52 audio encoder FAAC=on: FAAC AAC encoder support FFMPEG=on: FFmpeg support (WMA, AIFF, AC3, APE...) FLAC=on: FLAC lossless audio codec support FLAKE=on: FLAC audio codec FLUIDSYNTH=on: SoundFont 2 audio codec LAME=on: LAME MP3 audio encoder support MAC=on: Monkey's Audio lossless codec MPLAYER=on: MPlayer media player support MUSEPACK=on: MPC audio format support NEROAAC=on: Nero AAC MPEG-3 and 3GPP audio codec OPUSTOOLS=on: Opus audio codec SHORTEN=on: Shorten (lossless) audio codec SPEEX=on: Speex audio format support TIMIDITY=on: MIDI audio decoder TTA=on: True Audio lossless audio codec TWOLAME=on: TwoLAME MP2 audio encoder support VORBIS=on: Ogg Vorbis audio codec support WAVPACK=on: WavPack lossless audio format support Audio filter tools: you have to choose at least one of them NORMALIZE=on: MP3/Ogg Vorbis audio filter and replaygain SOX=on: Universal sound sample translator Replaygain tools for codecs: you have to choose at least one of them AACGAIN=on: AAC audio replaygain FLAC=on: FLAC lossless audio codec support MP3GAIN=on: MP3 audio replaygain MUSEPACK=on: MPC audio format support NORMALIZE=on: MP3/Ogg Vorbis audio filter and replaygain VORBISGAIN=on: Ogg Vorbis audio replaygain WAVPACK=on: WavPack lossless audio format support === Use 'make config' to modify these settings ---End OPTIONS List--- Complete build log is attached. This is a strange error. Nothing has changed with soundkonverter to cause this break so the cause is likely some other package (I naively blame taglib). You can fix it by using either clang of a newer version of gcc to build the port (for example `make USE_GCC=yes`). My current approach is to wait and see if the error goes away. (Or wait until I have more time to track down the root cause, other than using an old compiler to compile new code [or something about old dogs and new code ;-D]). Regards signature.asc Description: This is a digitally signed message part.
Fwd: [REL - 83i386-default][x11-toolkits/py-kivy] Failed for py27-kivy-1.7.1 in build
Hi All, Could someone please help me with this. It doesn't make any sense. I have isolated the issue to building on i386 under old Xorg (libGL v7). This does not happen when using new Xorg (libGL v8 - WITH_NEW_XORG), nvidia libGL or under amd64. If I run ldd(1) on kivy/graphics/opengl.so it finds all the required libraries and doesn't complain about the unresolved symbol. grep(1) also confirms that the missing symbol is present in libGL.h and GL/gl.h. I could add to the Makefile: .if !defined(WITH_NEW_XORG) NOT_FOR_ARCHS= i386 NOT_FOR_ARCHS_REASON= Does not compile with old libGL under i386, either \ use amd64 or -DWITH_NEW_XORG .endif so solve the issue but I would prefer a proper solution, if possible. Regards -- Forwarded Message -- Subject: [REL - 83i386-default][x11-toolkits/py-kivy] Failed for py27- kivy-1.7.1 in build Date: Wednesday 18 September 2013, 07:09:07 From: pkg-fall...@freebsd.org To: d...@freebsd.org CC: pkg-fall...@freebsd.org You are receiving this mail as a port that you maintain is failing to build on the FreeBSD package build server. Please investigate the failure and submit a PR to fix build. Maintainer: d...@freebsd.org Last committer: d...@freebsd.org Ident: $FreeBSD: head/x11-toolkits/py-kivy/Makefile 322115 2013-07-01 05:57:32Z dbn $ Log URL: http://beefy1.isc.freebsd.org/bulk/83i386-default/2013-09-18_01h01m37s/logs/py27-kivy-1.7.1.log Build URL: http://beefy1.isc.freebsd.org/bulk/83i386-default/2013-09-18_01h01m37s Log: Building x11-toolkits/py-kivy build started at Wed Sep 18 07:07:12 UTC 2013 port directory: /usr/ports/x11-toolkits/py-kivy building for: FreeBSD 83i386-default-job-18 8.3-RELEASE FreeBSD 8.3-RELEASE i386 maintained by: d...@freebsd.org Makefile ident: $FreeBSD: head/x11-toolkits/py-kivy/Makefile 322115 2013-07-01 05:57:32Z dbn $ Poudriere version: 3.1-pre ---Begin Environment--- UNAME_m=i386 UNAME_p=i386 OSVERSION=803000 UNAME_v=FreeBSD 8.3-RELEASE UNAME_r=8.3-RELEASE FTP_PASSIVE_MODE=YES BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 MASTERMNT=/usr/local/poudriere/data/build/83i386-default/ref PKG_EXT=txz tpid=1850 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin POUDRIERE_BUILD_TYPE=bulk NBPARALLEL=24 PKGNG=1 PKGNAME=py27-kivy-1.7.1 PKG_DELETE=/usr/local/sbin/pkg delete -y -f PKG_ADD=/usr/local/sbin/pkg add PWD=/root MASTERNAME=83i386-default USER=root HOME=/root POUDRIERE_VERSION=3.1-pre SKIPSANITY=0 LOCALBASE=/usr/local PACKAGE_BUILDING=yes ---End Environment--- ---Begin OPTIONS List--- === The following configuration options are available for py27-kivy-1.7.1: DOCS=on: Build and/or install documentation PDF=off: Build PDF documentation (required TeXLive, DOCS) TEST=off: Build and/or run tests Window support (compulsory): you have to choose at least one of them PYGAME=on: Window, text and image rendering support via PyGame X11=off: X11 (graphics) support SDL2=off: Simple Direct Media Layer v2.0 support Text rendering support (compulsory): you have to choose at least one of them PIL=off: Text and window rendering support via PIL PYGAME=on: Window, text and image rendering support via PyGame SDL2=off: Simple Direct Media Layer v2.0 support Video support GSTREAMER=off: Multimedia support via GStreamer PYGLET=off Options available for the group AUDIO GSTREAMER=off: Multimedia support via GStreamer PYGAME=on: Window, text and image rendering support via PyGame SDL=off: Simple Direct Media Layer support Image support PIL=off: Text and window rendering support via PIL PYGAME=on: Window, text and image rendering support via PyGame Camera support OPENCV=on: OpenCV support GSTREAMER=off: Multimedia support via GStreamer Spell checking support ENCHANT=on: Spell checking support via Enchant Clipboard support PYGAME=on: Window, text and image rendering support via PyGame === Use 'make config' to modify these settings ---End OPTIONS List--- --CONFIGURE_ARGS-- --End CONFIGURE_ARGS-- --CONFIGURE_ENV-- TMPDIR=/tmp TMPDIR=/tmp PYTHON=/usr/local/bin/python2.7 SHELL=/bin/sh CONFIG_SHELL=/bin/sh --End CONFIGURE_ENV-- --MAKE_ENV-- KIVY_NO_CONFIG=yes KIVY_NO_FILELOG=yes PYTHONPATH=/wrkdirs/usr/ports/x11- toolkits/py-kivy/work/kivy-kivy-ee1985a TMPDIR=/tmp TMPDIR=/tmp SHELL=/bin/sh NO_LINT=YES LDSHARED=cc -shared PYTHONDONTWRITEBYTECODE= PYTHONOPTIMIZE= PREFIX=/usr/local LOCALBASE=/usr/local LIBDIR=/usr/lib CC=cc CFLAGS=-O2 -pipe -fno-strict-aliasing CPP=cpp CPPFLAGS= LDFLAGS= CXX=c++ CXXFLAGS=-O2 -pipe -fno-strict-aliasing MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -o root -g wheel -m 555 BSD_INSTALL_LIB=install -s -o root -g wheel -m 444 BSD_INSTALL_SCRIPT=install -o root -g wheel -m 555 BSD_INSTALL_DATA=install -o root -g wheel -m 444 BSD_INSTALL_MAN=install
Re: [HEADSUP][CFT] New compiler USES flag, please test, review comment
On Friday 13 September 2013 15:17:53 Baptiste Daroussin wrote: Hi, Hi, Given how old our gcc in base is and the work done on clang and libc++. It is becoming complicating to make some ports properly working on all supported version of FreeBSD. To help in that I would like to propose a new USES: compiler http://people.freebsd.org/~bapt/compiler.mk.txt Would it be possible to add a quirks ability. For example PyPy triggers the GCC memory bug for the gcc in base, so it needs any compiler (clang or gcc) as long as gcc is 4.3+. Regards signature.asc Description: This is a digitally signed message part.
Re: How to start wine?
On Monday, 26 August 2013 11:58:12 Thomas Mueller wrote: What are LD_LIBRARY_PATH and LD_32_LIBRARY_PATH supposed to be? I see neither of these environment variables defined. The LD_(32_)LIBRARY_PATH variables are used by ld-elf(32).so.1 in resolving the libraries. And what about PATH? PATH will not fix the problem, in this case, unless wine needs to find support binaries (such as wineserver). I am trying #!/bin/sh set PATH=/compat/i386/usr/local/bin:/compat/i386/usr/local/sbin:/compat/i386/us r/bin:/compat/i386/usr/sbin:/compat/i386/bin:/compat/i386/sbin:$PATH export LD_32_LIBRARY_PATH=/compat/i386/usr/local/lib:/compat/i386/usr/lib:/compat/ i386/lib:$LD_32_LIBRARY_PATH export LD_LIBRARY_PATH=/compat/i386/usr/local/lib:/compat/i386/usr/lib:/compat/i38 6/lib:$LD_LIBRARY_PATH The bootstrap code from i386-wine does the following: if [ -z $__BINBOUNCE_BOOTSTRAP ] then export LIBGL_DRIVERS_PATH=$LOCALBASE/lib32/dri if [ `uname -p` = i386 ] then export LD_LIBRARY_PATH=$LOCALBASE/lib32:$LOCALBASE/lib32/wine:$LD_LIBRARY_PATH else export LD_32_LIBRARY_PATH=$LOCALBASE/lib32:$LOCALBASE/lib32/wine:$LD_32_LIBRARY_PATH:/usr/lib32 fi export PATH=$LOCALBASE/bin32:$PATH fi What is the difference between the various wine ports in $PORTSDIR/emulators? I used wine-devel, newer but less tested than wine. emulators/wine - Stable version of wine, currently 1.4.1 (we are waiting for 1.6.1). Currently only i386 is supported. emulators/wine-devel - Development version (works for most people), currently 1.7.0. Currently only i386 is supported. emulators/i386-wine - amd64 version of wine tracking emulators/wine emulators/i386-wine-devel - amd64 version of wine tracking emulators/wine- devel I suggest you try i386-wine(-devel) and see if that works for you. If it does and you want to build from source have a look at the Makefile for some of the changes required. Regards signature.asc Description: This is a digitally signed message part.
Re: How to start wine?
On Saturday, 24 August 2013 15:12:57 Thomas Mueller wrote: I built wine from ports on a USB-stick installation of FreeBSD 9.1-STABLE i386, but it won't start. I tried to start from hard-drive installation of (from uname -a) FreeBSD amelia2 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #17 r254196: Sun Aug 11 00:36:49 UTC 2013 root@amelia2:/usr/obj/usr/src/sys/SANDY amd64 I get Shared object libwine.so.1 not found, required by wine This is because ld is looking for libwine.so.1 using the 64-bit library path. I was able to find libwine.so and libwine.so.1 in directory /usr/local/lib, or as it is mounted, /compat/i386/usr/local/lib I can suggest either: a) Making sure ldd(32) reports it can find the libraries (set LD_LIBRARY_PATH and LD_32_LIBRARY_PATH). Using those two environment variables should fix your problem b) Use the binary packages provided from either ports (i386-wine) or wiki.FreeBSD.org/i386-Wine. These include all the compatibility shims required. I tried as nonroot user. Kernel config includes the line options COMPAT_FREEBSD32# Compatible with i386 binaries What is the trick? Should I try to boot the USB stick with FreeBSD 9.1-STABLE i386? I did not build Xorg on this USB stick. Should I have? Hmmm, the last I heard Xorg does not run from a chroot... Wine would have pulled in libXorg so you should be fine (make sure DISPLAY is set correctly, usually to ':0'). What is the requirement of FreeBSD versions matching? Matching is very importantant, especially at the major version. Make sure the kernel is at a higher (or equal) version to the 32-bit binaries. Although I keep the source tree, ports tree and work directories on the hard drive, installing to this Kingston Data Traveler 16 GB USB 2.0 stick is very slow, slower than NetBSD and slower than FreeBSD on other USB sticks. I could try with a Kingston Data Traveler 16 GB or 32 GB USB 3.0 drive. Tom signature.asc Description: This is a digitally signed message part.
Request for assistance: portbuilder
Hi All, I'm looking for assistance with maintaining portbuilder. I do not have time at the moment to maintain it and it has some shortcomings with recent developments from Ports (for example, it cannot bootstrap a new environment due to dialog4ports). If you are interest, please contact me. Regards, David signature.asc Description: This is a digitally signed message part.
Re: Netflix support
Hi Richard, I have forwarded your email on to Gerald who is the maintainer of the port. We generally prefer to wait for the wine devs to integrate the patches instead of doing an out-of-version patch. That being said, if this requires FreeBSD specific code the only likely way the code will get into wine is if someone creates the patch. Unfortunately I do not have time to follow up on this. What I can suggest is either try create the patch yourself (which you can add to emulators/wine- devel to test) or find a src developer who can make the changes for you (FYI, I don't have the knowledge required to make that change :-(). If you have any questions please ask, I'll help where I can. Regards On Sunday, 11 August 2013 08:37:09 Richard Yao wrote: In theory, it should be possible to get Netflix working on FreeBSD by patching Wine with these patches: http://www.compholio.com/wine-compholio/ The Implement NotifyAddrChange on Linux. patch would probably need to be tweaked for FreeBSD, but the rest appear to be platform independent. Eitan Adler asked me to email ports@ and dbn@ about this possibility after I mentioned it to him. signature.asc Description: This is a digitally signed message part.
Re: [REVIEW] Completing i386-wine
On Monday, 5 August 2013 02:31:54 Sam Fourman Jr. wrote: Would there also be the possibility to have i386-wine as a source-code port, and build from i386 installation? That avoids cross-compiling. One could build an i386 installation either from amd64 or previous i386 installation, then build i386-wine and other desired ports when booted into the i386 installation. This i386 installation would be on another partition or another disk (USB 3.0 stick or USB 3.0 hard-drive partition?), and from the amd64 installation, the i386 installation could be mounted on /compat/i386. With a USB hard drive, if not directly bootable, the loader and kernel could be copied to another boot disk/partition, and root could be set for the USB hard-drive partition. My USB 3.0 hard drive, Western Digital My Book Essential, is not recognized by the BIOS/UEFI or GRUB2, but is accessible from Linux or FreeBSD. Tom-- Can't we just have the port build wine in a i386 jail? eg it would require the FreeBSD sources, build the jail... etc.. it seems like a LOT, but honestly whats wrong with it... ill do the testing Hi Sam / Thomas Well, when compiling on i386 the port is source based. I am reluctant to bring in the i386 environment bootstrapping logic within the port (especially given there are so many different ways - and personal preferences - on how to do it). I also think it is not appropriate, in my opinion, for a port to do so much. Given that nothing stops an individual from setting up such an environment manually (such as how I do it to create the packages) I think the port offers enough functionality as is. I hope this clarifies my position on this, and thank you for your feedback :-) signature.asc Description: This is a digitally signed message part.
Re: Re: [RFC] lang/pypy
On Sunday, 10 March 2013 00:37:15 poyop...@puripuri.plala.or.jp wrote: Hi, good work, David. Hi Kuro It compiles, packages and works flawlessly here for replacement of 1.9 so far for a week. Great, thanks. Good to know :-) On my compile box, amd64/Athlon64 5050e 2.6GHz 2 core/8GB, memory requirement for translation processes is far less than warning shown. It prevents build with | warn: this system has insufficient memory, expected at least 9227MiB RAM however my translation processes under -DPYPY_IGNORE_MEMORY take 2GB for normal binary and 2.5GB for sandboxed one so they aggregate 4.5GB to run parallel. This is good news. Could you please detail how you measured peak memory? I might need to retest the port. This is far less than expected, no page thrashing, no hang, no stuttering. It does not matter being with pypy1.9 or pypy2.0 (yes, I built twice for 2.0 self hosting. Not tried with cPython.) So I think this warning is a bit excessive that makes everyone just put PYPY_IGNORE_MEMORY=1 in their make.conf. Just in my case. I'll disable the test for now and revise my estimation. Thanks for reporting back. Regards signature.asc Description: This is a digitally signed message part.
[RFC] lang/pypy
Hi All.
After many months of (sporadic) work I would like to introduce pypy-2.0.b1.
Could you please have a look at, and test, my proposed changes (attached) and
the wiki page at http://wiki.FreeBSD.org/PyPy.
I would like to commit these changes (after incorporating feedback) sometime
next week. Feel free to update the wiki yourselves ;-).
Regards
David
P.S. Please keep my mentors CCed in any discussions :-)
Index: pypy/Makefile
===
--- pypy/Makefile (revision 312473)
+++ pypy/Makefile (working copy)
@@ -2,8 +2,7 @@
# $FreeBSD$
PORTNAME= pypy
-DISTVERSION= 1.9
-PORTREVISION= 2
+DISTVERSION= 2.0-beta1
CATEGORIES= lang python java
MASTER_SITES= https://bitbucket.org/pypy/pypy/get/
DISTNAME= release-${DISTVERSION}
@@ -18,18 +17,30 @@
LIB_DEPENDS= expat:${PORTSDIR}/textproc/expat2 \
ffi:${PORTSDIR}/devel/libffi
-OPTIONS_DEFINE= SANDBOX
+CLI_DESC= (BROKEN) Translate a CLI (.NET) based pypy
+JVM_DESC= (BROKEN) Translate a JVM (Java) based pypy
+PYPY_DESC= Use pypy to translate (faster but uses more memory)
SANDBOX_DESC= Translate a sandboxed pypy
+.if !defined(PYPY_INST)
+OPTIONS_DEFINE+= CLI JVM SANDBOX
+.endif
+LOCALBASE?= /usr/local
+.if exists(${LOCALBASE}/bin/pypy)
+OPTIONS_DEFINE+= PYPY
+.endif
+ALL_TARGET= ${PYPY_NAMES}
BUILD_WRKSRC= ${WRKDIR}
USE_BZIP2= yes
USE_ICONV= yes
USE_GETTEXT= yes
+MAKE_JOBS_SAFE= yes
+MAKEFILE= ${FILESDIR}/Makefile
PKGINSTALL= ${WRKDIR}/pkg-install
PKGDEINSTALL= ${WRKDIR}/pkg-deinstall
-WRKSRC= ${WRKDIR}/pypy-pypy-341e1e3821ff
+WRKSRC= ${WRKDIR}/pypy-pypy-fcb6b056f00e
-PYPY_VER= ${DISTVERSION}
+PYPY_VER= ${DISTVERSION:C|([0-9])\.([0-9]).*|\1.\2|}
PYTHON_IMPL_VER= 2.7
PYPY_LIBDIR= lib/pypy${PYPY_VER}
PYPY_INCLUDEDIR= include/pypy${PYPY_VER}
@@ -38,20 +49,26 @@
PLIST_SUB+= PYPY_LIBDIR=${PYPY_LIBDIR} \
PYPY_INCLUDEDIR=${PYPY_INCLUDEDIR}
-MAKE_ENV+= PYPY_LOCALBASE=${LOCALBASE}
-.if exists(/usr/bin/clang)
-MAKE_ARGS+= CC=clang
-MAKE_JOBS_SAFE= yes
-.endif
+MAKE_ENV+= DISTVERSION=${DISTVERSION} PYTHON_CMD=${PYTHON_CMD} \
+ WRKSRC=${WRKSRC} PYPY_LOCALBASE=${LOCALBASE}
-# XXX !.include bsd.port.pre.mk as USE_* need to be set prior
.include bsd.port.options.mk
-.include ${.CURDIR}/files/bsd.pypy.inst.mk
+.include ${MASTERDIR}/files/bsd.pypy.inst.mk
-.if defined(PACKAGE_BUILDING)
-MANUAL_PACKAGE_BUILD= fails to finish compilation on pointyhat, reason unknown
+.if ${OSVERSION} 124 || ( ${ARCH} != i386 ${ARCH} != amd64 )
+.if ${CC:T} == cc ( exists(/usr/bin/clang) || exists(${LOCALBASE}/clang) )
+CC= clang
+.else
+USE_GCC= yes
.endif
+.endif
+.if ${PORT_OPTIONS:MPYPY} || defined(PYTHON_CMD)
+PYTHON_CMD?= ${LOCALBASE}/bin/pypy
+.else
+USE_PYTHON_BUILD= 2.5+
+.endif
+
# List of PyPy instances
.if !defined(PYPY_INST)
PYPY_INST= DEFAULT
@@ -60,13 +77,26 @@
PYPY_INST+= SANDBOX
.endif
+.if ${PORT_OPTIONS:MCLI}
+PYPY_INST+= CLI
+.endif
+
+.if ${PORT_OPTIONS:MJVM}
+PYPY_INST+= JVM
+.endif
+
.endif # !defined(PYPY_INST)
-PYPY_NAMES=
+MAKE_ENV+= PYPY_INST=${PYPY_INST}
+
.for inst in ${PYPY_INST}
PYPY_NAMES+= ${PYPY_${inst}_NAME}
PYPY_PRIMARY?= ${PYPY_${inst}_NAME}
+MAKE_ENV+= PYPY_${inst}_NAME=${PYPY_${inst}_NAME} \
+ PYPY_${inst}_OBJSPACE_ARGS=${PYPY_${inst}_OBJSPACE_ARGS} \
+ PYPY_${inst}_OPT=${PYPY_${inst}_OPT} \
+ PYPY_${inst}_TRANSLATE_ARGS=${PYPY_${inst}_TRANSLATE_ARGS}
# Check if the boehm GC will be used
.if ${PYPY_${inst}_OPT} == 0 || ${PYPY_${inst}_OPT} == 1 || ${PYPY_${inst}_OPT} == size
@@ -85,24 +115,6 @@
.endfor # inst in ${PYPY_INST}
-# Use pypy if it is installed, else use python (to translate)
-.if !defined(PY)
-.if !defined(PYPY)
-.if ${PYPY_PRIMARY} == pypy
-PYPY!= ${WHICH} ${PYPY_PRIMARY} 2 /dev/null || true
-.else
-PYPY!= ${WHICH} ${PYPY_PRIMARY} 2 /dev/null || ${WHICH} pypy 2 /dev/null || true
-.endif
-.endif # !defined(PYPY)
-
-.if exists(${PYPY})
-PY= ${PYPY}
-.else
-USE_PYTHON_BUILD= 2.5+
-PY= ${PYTHON_CMD}
-.endif
-.endif # !defined(PY)
-
.if defined(WITH_BOEHM_GC)
LIB_DEPENDS+= gc.1:${PORTSDIR}/devel/boehm-gc
.endif
@@ -117,7 +129,7 @@
.if defined(WITH_JVM)
USE_JAVA= yes
-JAVA_VERSION= 1.6+
+JAVA_VERSION= 1.5+
ONLY_FOR_ARCHS= i386 powerpc
ONLY_FOR_ARCHS_REASON= only translates on 32bit systems
BROKEN= JVM backend broken, partially supported upstream
@@ -149,19 +161,59 @@
.endfor # inst in ${PYPY_INST}
.endif # !defined(PYPY_JITTABLE)
-pre-fetch:
- @${ECHO} PyPy requires a large amount of free RAM and time to translate and compile.
- @${ECHO}
- @${ECHO} To translate, PyPy requires on 32bit 3G (min 2G) free RAM and on 64bit
- @${ECHO} 6G (min 4G) free RAM. Also, to compile, PyPy on amd64 gcc requires an
- @${ECHO} extra 4G however clang only requires 400M (CC=clang) but clang is slower
- @${ECHO} in compiling PyPy.
- @${ECHO}
- @${ECHO} If memory is in short supply consider using a lower optimisation level
- @${ECHO} (e.g. PYPY_DEFAULT_OPT=2) however that makes PyPy much slower. Also,
- @${ECHO}
Re: Setting up tinderbox-devel on a pkgng system
On Saturday, 19 January 2013 16:10:38 Alexandr Kovalenko wrote: On Sat, Jan 19, 2013 at 5:29 AM, David Naylor d...@freebsd.org wrote: Another issue is that, by default, the port installs databases/p5-DBD-mysql which is not a recognised port. The attached patch fixes that [2]. I'm not sure where did you get your ports tree from, but it is perfectly valid port, which also autodetects which version of MySQL is used. http://svnweb.freebsd.org/ports/head/databases/p5-DBD-mysql/ [2] I assumed that databases/p5-DBD-mysqlXY needs to correspond to databases/mysqlXY-client (no idea if that is a correct assumption). Apologies if I didn't explain myself properly. The issue is that tindexbox- devel does not recognise databases/p5-DBD-mysql as a valid port. See /usr/local/tinderbox/scripts/lib/db-mysql.sh:27 where it requires a port of format databases/p5-DBD-mysql[456][0145] which will not match databases/p5- DBD-mysql. shell # ls /usr/ports/databases/p5-DBD-mysql[456][0145] /usr/ports/databases/p5-DBD-mysql41: Makefile /usr/ports/databases/p5-DBD-mysql50: Makefile /usr/ports/databases/p5-DBD-mysql51: Makefile /usr/ports/databases/p5-DBD-mysql55: Makefile /shell For clarity, on my system I get, for: shell # ls /usr/ports/databases/p5-DBD-mysql Makefile distinfo pkg-descr pkg-plist /shell and that tinderbox-devel did install that port originally, until I make the change in the previously attached file. I hope this explains things better. Regards signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On 29 Dec 2012 2:03 AM, Gerald Pfeifer ger...@pfeifer.com wrote: On Sat, 3 Nov 2012, David Naylor wrote: # 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 :-). I would say, go ahead and send-pr the port (without the nVidia parts for now). If nobody else bites within two weeks of you sending it, share the number with me, and I'll give it a try. I am sure that, once in, there will be many aspects we'll get feedback on and further tweaks and improvements, but it seems this is relatively widely used and useful, so let's make it port of the ports collection and jointly take it from there. Thanks, I shall do when I get back from holidays. Might have a surprise up my sleeve :-) - 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. My primary question at this point, and to this group, is how to actually name such a port? It probably makes sense to focus on wine-devel, initially, but given that it's really the 32-bit version that is intended for the 64-bit OS, how to best reflect that? wine-devel-fbsd64 as per the current name? wine-devel-32on64?...?? I think there is precedent for the naming. Consider Linux ports, those ports take the prefix linux- to indicate the architecture so I propose i386-wine-devel to indicate a port that has binaries from the i386 architecture. Regards, ___ 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)
On Saturday, 3 November 2012 22:47:56 Jan Beich wrote: 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 I am aware of the change for FreeBSD 10 however didn't realise the port failed. Thanks, I'll try find a fix (although that code is the ugliest hack of the port). 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 I will add this to the wiki (when it gets created). Thanks signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Wednesday, 7 November 2012 11:45:11 Thomas Mueller wrote: from David Naylor naylor.b.da...@gmail.com: 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. # 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 ;-) It would be nice to have wine-fbsd64 as a port, but that might unfortunately deprive the user of certain flexibility. To what flexibility do you refer to? Nothing stops the user from building the port herself and for those who prefer a binary with most options switched on (as is with what I provide) that can still be provided (and possibly in an automated manor via a pkgng repository). Also, nVidia support should be an option, since users with other graphics cards might have no use for it. I think I fail to explain how the nVidia support works: it is a simple script that downloads the corresponding i386 drivers (user land libGL stuff) for the amd64 package. If there is no amd64 package installed it cannot know which i386 version to download, also, when installing it does not download any files, only installing the drivers if the distfile is already available on the system. So, there are three cases (on installation): 1) The user has no amd64 package installed (nothing is done) 2) The user has amd64 package installed but no i386 distfile available (nothing is done) 3) The user has amd64 package installed and i386 distfiles available (user land libGL stuff is extracted and placed in $LOCALBASE/lib32) In case 2, the user is advised to run the script manually to download and install the i386 distfiles. In cases 1, 2 and 3 the user is advised to run the script manually whenever there is a change (or installation) to the amd64 package. I would really prefer to build the i386 FreeBSD system as a separate part, including kernel, since some users, myself included, might want to run an actual FreeBSD i386, especially on an older computer. So one could build this FreeBSD i386 on a USB stick or USB hard drive, and then be able to run wine on an i386 system. I think an easy way to achieve this is to modify the FreeBSD32 compatibility to work similar to the linux compatibility, namely: have a super-imposed shadow file-hierarchy at /compat/i386 (similar to /compat/linux). This way the i386 packages can be installed into /compat/i386 and when called can easily find the correct libraries. Then, create an alias: pkg-i386 = chroot env UNAME_p=i386 UNAME_m=i386 MACHINE=i386 /compat/i386 pkg and with the correct i386 repo specified it is trivial to install i386 programs and with a modified PATH: PATH=$PATH:/compat/i386/usr/local/bin:/compat/i386/usr/local/sbin the programs will integrate seamlessly. However, to my knowledge, there are few ports that are i386 only (such as wine) and maybe it is easier to use a similar hack to the wine-fbsd64 port to cater for the fringe cases??? P.S. I really would like to see FreeBSD be broken into packages and integrated into the ports tree, just my crazy ideas though... Would wine-fbsd64 be a separate port, or would it be wine built on i386, as the page http://wiki.freebsd.org/Wine suggests? It would be nice to be able to run Wine on i386 as well as amd64. The answer is yes to both your questions. It can only be built on i386 but is a separate port. The reason for the separate port is to allow extra stuff to happen so that it can be run on amd64 as well. The package can be run on both i386 and amd64. Regards signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Sunday, 4 November 2012 13:31:46 Chris Rees wrote:
I think this is very interesting... but I'm not 100% convinced the
best place for this is in the ports tree. However, it would improve
visibility for it, with a good IGNORE message.
Ideally, FreeBSD should have an automagical method of supporting i386 packages
on an amd64 system. Please see my reply to Thomas Muller for my thoughts on
this topic.
We have a problem however; we can't include bsd.port.pre.mk in a slave
port.
The solution I can think of is;
post-package-script:
if [ ${PKG_BIN:T} = pkg ]; then \
${XZ_CMD} -dc ${PKGFILE} | \
${SED} -e s/^\(arch: freebsd:.*:x86\):32/\1:64/ | \
${XZ_CMD} ${WRKDIR}/${PKGNAME}.txz; \
${MV} ${WRKDIR}/${PKGNAME}.txz ${PKGFILE}; \
fi
Thanks, I've added that to the port and will test it later :-)
Thanks
signature.asc
Description: This is a digitally signed message part.
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.
Wine-fbsd64 updated to 1.5.8 (32bit Wine for 64bit FreeBSD)
Hi, Packages [1] for wine-fbsd64-1.5.8 have been uploaded to mediafire [2]. The packages for FreeBSD 10 use the pkgng* [3] format. There are many reports that wine does not work with a clang compiled world (help in fixing this problem is appreciated as it affects quite a few users). The patch [4] for nVidia users is now included in the package and is run on installation (if the relevant files are accessible). Please read the installation messages for further information. Regards, David [1] MD5 (wine-1.5.x-freebsd8/wine-fbsd64-1.5.8,1.tbz) = bc57b6b573816d24837c9171e38cdfaf MD5 (wine-1.5.x-freebsd9/wine-fbsd64-1.5.8,1.txz) = 4c06fd3e68c43c977449ab9f824f69dd MD5 (wine-1.5.x-freebsd10/wine-fbsd64-1.5.8,1.txz) = 34cce0d89ef9d3db47f7699a3769a6cd [2] http://www.mediafire.com/wine_fbsd64 [3] http://wiki.freebsd.org/pkgng [4] The patch is located at /usr/local/share/wine/patch-nvidia.sh * pkgng support for nVidia patching should be working properly and using a mixed mode between pkgng and pkg also works signature.asc Description: This is a digitally signed message part.
Re: Wine-fbsd64 updated to 1.5.6 (32bit Wine for 64bit FreeBSD)
On Friday, 22 June 2012 12:26:50 Jan Beich wrote:
(ports@ folk may know more about pkgng)
David Naylor naylor.b.da...@gmail.com writes:
Hi,
Packages [1] for wine-fbsd64-1.5.6 have been uploaded to mediafire [2].
The packages for FreeBSD 10 use the pkgng* [3] format.
[...]
* Support for pkgng has been added to the nvidia-patch script
pkgng seems to be more pedantic regarding conflicting files. And I
haven't found a way to force register a package.
I have reported this issue to both pkgng and FreeBSD ports. I managed to get
it to register by tweaking pkg-plist, also not defining WITH_PKGNG may work
(and with the changes to nvidia.sh it will fall back to `pkg_info` if `pkg
info` doesn\t yield).
--- patch-nvidia.sh~
+++ patch-nvidia.sh
@@ -92,12 +92,20 @@ do
done
version() {
+ local ret pkg=$1
if [ -f /usr/local/sbin/pkg ]
then
-echo `pkg query -g '%v' $1`
+ret=`pkg query -g '%v' $pkg`
else
-echo `pkg_info -E $1'*' | cut -f 3 -d -`
+ret=`pkg_info -E $pkg'*' | cut -f 3 -d -`
fi
+ # installed manually or failed to register
+ if [ -z $ret ] [ $pkg = nvidia-driver ]
+ then
+ret=`sed 2/dev/null -n 's/.*Version: //p' \
+ $PREFIX/share/doc/NVIDIA_GLX-1.0/README || true`
+ fi
+ echo $ret
}
[ `whoami` = root ] \
Thanks for your patch. I have updates the nvidia.sh script and given you
credit. This will be available from wine 1.5.7.
Regards
signature.asc
Description: This is a digitally signed message part.
Re: TeXLive merge into FreeBSD ports tree - FreeBSD project idea
Hi all, Summary of below. I have started an effort to get TeXLive into the FreeBSD ports. See github.com/DragonSA/texlive for details. Volunteers welcome. On Sunday, 17 June 2012 22:04:15 David Schultz wrote: On Sun, Jun 17, 2012, Jan Henrik Sylvester wrote: Even with a knob instead of checking if print/texlive-core is installed, it would put a lot of mess into the ports tree. Some maintainers will not agree to introduce these conditions, if there is no general agreement that we want to transition to TeXLive that way. teTeX hasn't been updated since 2006 and the maintainer of teTeX has discontinued development and recommends using TeXLive. Undoubtably updating the TeXLive will break some things but the same could be said about teTeX if an update existed. Are there any people who don't want to migrate to TeXLive? As far as I remember, both romain@ and hrs@ have stated that they do not want both teTeX and TeXLive in the tree concurrently. Looking through the list of bundled packages for TeXLive it will be quite difficult to have both TeXLive and teTeX in the tree concurrently. There are a group of support ports, such as xdvik and ptex that require special integration into either teTeX or TeXLive. To switch between either will require reinstalling many dependencies, not just the TeXLive or teTeX ports. With that said, it is not impossible nor, I think, will it impose a big maintenance burden. In that case, it sounds like using TeXLive in FreeBSD will be a bit tricky until someone steps in and does all the work required for integration. Unfortunately I'm a bit time-constrained for the next few months, but I do use TeXLive and would be happy to test any proposed patches. I have started working on just this, getting TeXLive into FreeBSD ports. It is still early days and I have only two monolithic ports, with texlive-base requiring lots of love. I believe my work is in a state ready for initial testing (verifying the ports) and some feedback. Some open questions are: - how to split texlive-texmf (OpenBSD has an approach) - how to handle bundled software that has existing (sometimes outdated) ports Also, I am looking for a sponsor: someone who will commit the ports when they are ready, and to provide feedback so that the ports may get to a ready state. For details about the project, and to get the ports, please see: github.com/DragonSA/texlive Regards P.S. I am not subscribed to freebsd-ports@ so please CC me. signature.asc Description: This is a digitally signed message part.
pypy-1.7
Hi All, As of 2011/12/13 pypy-1.7 is in ports (under lang/pypy, thanks lwhsu@). Please uninstall pypy-1.6 before building pypy-1.7, there is a memory leak in pypy-1.6 that prevents it from translating pypy-1.7. For those that are interested, there is a TODO list [1] and the WIP repository for pypy it at github [2]. Contributions are very welcome! Regards David [1] https://github.com/DragonSA/pypy/blob/master/TODO [2] https://github.com/DragonSA/pypy signature.asc Description: This is a digitally signed message part.
Re: [ECFT] drm/dri/mesa/xorg-server update [Part 1]
On Friday 11 March 2011 13:37:59 Martin Wilke wrote: Hi, First of all, note that *this is very experimental, so you really have to know what you’re doing.* We managed to get drm/dri with the newer xorg-server to work, and we have removed the support for WITHOUT_NOUVEAU. We have just updated the xorg-dev repo: – libdrm - 2.4.24 – libGL to 7.10.1 – libGLU to 7.10.1 – libGLUw to 7.10.1 – libglut to 7.10.1 – xproto to 7.0.17 – libXaw to 1.0.9 – libXt to 1.1.0 – libX11 to 1.4.1 – xorg-server to 1.9.4 It appears graphics/mesa-demo is not updated. After installing these, you will have to rebuild the following ports: – your graphic driver x11/nvidia-driver – keybord driver – mouse/synaptics driver Please report any problems and issues to x11 (at) FreeBSD.org. I have no problems ;-). I have tested some wine games and all run without problem. signature.asc Description: This is a digitally signed message part.
Re: MAKE_JOBS and openjdk6
On Saturday 04 September 2010 23:26:27 Greg Lewis wrote: On Sun, Aug 29, 2010 at 10:37:37AM +0200, David Naylor wrote: On Saturday 28 August 2010 23:30:22 Greg Lewis wrote: On Sun, Aug 29, 2010 at 12:44:39AM +0400, Anonymous wrote: Greg Lewis gle...@eyesbeyond.com writes: Your attached patch does not explicitly define either MAKE_JOBS_(UN)SAFE. I would by happy with it being defined as _UNSAFE. If there are no other problems with your patch (see my comment at the bottom) then I'm happy for this patch to be committed. I'd already committed a change that marked the port as MAKE_JOBS_UNSAFE, so the patch didn't include that. Yes, sorry I didn't see that. Is it safe to pass an empty HOTSPOT_BUILD_JOBS to MAKE_ENV? (i.e. when DISABLE_MAKE_JOBS is defined.) Good thought. I tried the build with DISABLE_MAKE_JOBS set and experienced no problems, so I think we're ok on that front. +.endif COPYDIRS=\ hotspot/src/os/linux/launcher \ I'm going to commit the change in a day or two if there are no further objections. I'll then use it as a template for changes to the other JDK ports. No objections here. Thank you for your patience in resolving this. signature.asc Description: This is a digitally signed message part.
Re: MAKE_JOBS and openjdk6
On Saturday 28 August 2010 23:30:22 Greg Lewis wrote:
On Sun, Aug 29, 2010 at 12:44:39AM +0400, Anonymous wrote:
Greg Lewis gle...@eyesbeyond.com writes:
I would argue that overriding a private variable is a hack (other ports
doing it doesn't make it not a hack).
You could've spoke up in ports/148754 about your concern in order for
portmgr@ to notice. The PR strived to be less intrusive than divorcing
build jobs from make jobs. Besides, I think adding more clutter to
Makefiles defeats purpose of having stuff in bsd.port.mk.
In that case, whichever way you cut it, we're deliberately trying to
circumvent what is in bsd.port.mk.
The circumvention is required because bsd.port.mk assumes a certain interface
that may not be applicable for all ports.
Alternative patch attached which seems to achieve the same result from
my perspective without overriding _MAKE_JOBS.
Hardcoding kern.smp.cpus and ignoring MAKE_JOBS_SAFE/UNSAFE doesn't seem
like a less hacky solution. I'd argue that it's more confusing because
MAKE_JOBS_UNSAFE is not equal to DISABLE_MAKE_JOBS.
The patch I attached (a) does not ignore MAKE_JOBS_{SAFE,UNSAFE} and (b)
the first patch similarly uses DISABLE_MAKE_JOBS.
The first patch does the following:
1. Sets MAKE_JOBS_SAFE _erroneously_ (the port is _not_ MAKE_JOBS_SAFE)
purely so it can force the setting of MAKE_JOBS_NUMBER.
Yes and no. The port is partially MAKE_JOBS_SAFE and is able to build some of
the code using make jobs. This is similar to python26: it is _SAFE but only a
small portion of the build actually uses more than one job which in effect
makes it the same as _UNSAFE (from a performance perspective).
2. Overrides passing of -j to the make invocation by fiddling the private
variable _MAKE_JOBS, which it has to do because of (1).
The one I just provided
1. Leaves the port correctly marked as MAKE_JOBS_UNSAFE and doesn't mess
with any private variables.
Your attached patch does not explicitly define either MAKE_JOBS_(UN)SAFE. I
would by happy with it being defined as _UNSAFE. If there are no other
problems with your patch (see my comment at the bottom) then I'm happy for
this patch to be committed.
There will still be issues with scripts that try some form of load balancing
when building ports but either way it will not be doing what was advertised.
Similar to python.
2. Respects MAKE_JOB_NUMBER if it is set and otherwise uses the sysctl
kern.smp.cpus, the latter being what the port _already_ does.
Index: Makefile
===
RCS file: /var/fcvs/ports/java/openjdk6/Makefile,v
retrieving revision 1.28
diff -u -r1.28 Makefile
--- Makefile 15 Aug 2010 05:23:06 - 1.28
+++ Makefile 28 Aug 2010 18:27:44 -
@@ -147,8 +147,14 @@
USE_DISPLAY= yes
.endif
-BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
+.if !defined(DISABLE_MAKE_JOBS)
+.if defined(MAKE_JOBS_NUMBER)
+BUILD_JOBS_NUMBER= ${MAKE_JOBS_NUMBER}
+.else
+BUILD_JOBS_NUMBER= `${SYSCTL} -n kern.smp.cpus`
+.endif
MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
Is it safe to pass an empty HOTSPOT_BUILD_JOBS to MAKE_ENV? (i.e. when
DISABLE_MAKE_JOBS is defined.)
+.endif
COPYDIRS=\
hotspot/src/os/linux/launcher \
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS and openjdk6
On Friday 20 August 2010 17:12:42 Anonymous wrote:
Anonymous swel...@gmail.com writes:
David Naylor naylor.b.da...@gmail.com writes:
%%
Index: java/openjdk6/Makefile
@@ -266,3 +267,6 @@ post-install:
@${CAT} ${PKGMESSAGE}
.include bsd.port.post.mk
+
+# XXX: use `?=' in bsd.port.mk
+_MAKE_JOBS=
%%
Yes, I prefer this approach. See attached for the patch that does this.
I will file a PR about this shortly.
I've filed ports/148754 about defining empty _MAKE_JOBS so it's not
forgotten.
That PR was recently committed. So, you can try to resurrect ports/148753.
I've had a look at openjdk6 and it appears it really is MAKE_JOBS_UNSAFE.
There are portions of it that are able to use make jobs and those are compiled
using HOTSPOT_BUILD_JOBS.
I suggest that either:
- openjdk stops using HOTSPOT_BUILD_JOBS and declares itself unsafe, or
- declare itself make jobs safe and use HOTSPOT_BUILD_JOBS for those parts
that can use it
Attached is a patch that achieves the latter suggestion.
The problem with the port as it stands now is that it breaks with
FORCE_MAKE_JOBS, does not honour MAKE_JOBS_NUMBER and that it will consume a
lot of resources when building, more so than what is reasonably expected.
Simply declaring the port make jobs unsafe does not fix the resource
consumption that some programs/scripts may take into account.
Taking the first option will result in slower build times when the port is able
to build faster.
Taking the second option results in overriding a 'private' variable. There is
precedent in ports for using that 'private' variable. With the recently
committed changes using the 'private' variable is less intrusive.
I recommend the second option. It allows the port to build as fast as
possible, to honour MAKE_JOBS_NUMBER and does not employ any hacks.
Regards
diff -ur /usr/ports/java/openjdk6/Makefile openjdk6/Makefile
--- /usr/ports/java/openjdk6/Makefile 2010-07-15 22:29:26.0 +0200
+++ openjdk6/Makefile 2010-07-15 22:33:45.0 +0200
@@ -48,6 +48,7 @@
# java extracts directly to the cwd
WRKSRC= ${WRKDIR}
+MAKE_JOBS_SAFE= yes
USE_GMAKE= yes
USE_MOTIF= yes
@@ -145,8 +146,10 @@
USE_DISPLAY= yes
.endif
-BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
-MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
+.if !defined(DISABLE_MAKE_JOBS)
+MAKE_ENV+= HOTSPOT_BUILD_JOBS=${MAKE_JOBS_NUMBER}
+_MAKE_JOBS=
+.endif
COPYDIRS= \
hotspot/src/os/linux/launcher \
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS and openjdk6
On Saturday 26 June 2010 00:15:16 Anonymous wrote:
David Naylor naylor.b.da...@gmail.com writes:
On Friday 25 June 2010 18:08:22 David Naylor wrote:
Hi,
java/openjdk6 breaks with FORCE_MAKE_JOBS (it implements its own think).
The attached patch fixes openjdk6, marks it as MAKE_JOBS_SAFE and makes
it respect MAKE_JOBS_NUMBER.
Regards,
David
P.S. I'm off list
Oops. My hack didn't work.
With MAKE_JOBS_SAFE _MAKE_JOBS is included but that evaluated to -jN and
this is choking the Makefile. Is there an easier way to exclude
_MAKE_JOBS? Perhaps set _MAKE_JOBS conditionally in bsd.ports.mk and a
port can then do _MAKE_JOBS=
The attached patch fixes the above problem without touching bsd.ports.mk.
You can as well define empty _MAKE_JOBS *after* bsd.port.post.mk.
At least it wouldn't be as ugly as redefining do-build target.
%%
Index: java/openjdk6/Makefile
@@ -266,3 +267,6 @@ post-install:
@${CAT} ${PKGMESSAGE}
.include bsd.port.post.mk
+
+# XXX: use `?=' in bsd.port.mk
+_MAKE_JOBS=
%%
Yes, I prefer this approach. See attached for the patch that does this. I
will file a PR about this shortly.
Regards
diff -ur /usr/ports/java/openjdk6/Makefile openjdk6/Makefile
--- /usr/ports/java/openjdk6/Makefile 2010-07-15 22:29:26.0 +0200
+++ openjdk6/Makefile 2010-07-15 22:33:45.0 +0200
@@ -48,6 +48,7 @@
# java extracts directly to the cwd
WRKSRC= ${WRKDIR}
+MAKE_JOBS_SAFE= yes
USE_GMAKE= yes
USE_MOTIF= yes
@@ -145,8 +146,10 @@
USE_DISPLAY= yes
.endif
-BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
-MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
+.if !defined(DISABLE_MAKE_JOBS)
+MAKE_ENV+= HOTSPOT_BUILD_JOBS=${MAKE_JOBS_NUMBER}
+# XXX: _MAKE_JOBS=
+.endif
COPYDIRS= \
hotspot/src/os/linux/launcher \
@@ -269,3 +272,5 @@
@${CAT} ${PKGMESSAGE}
.include bsd.port.post.mk
+# XXX: use _MAKE_JOBS in bsd.port.mk (and move libe below up-above)
+_MAKE_JOBS=
signature.asc
Description: This is a digitally signed message part.
MAKE_JOBS and openjdk6
Hi,
java/openjdk6 breaks with FORCE_MAKE_JOBS (it implements its own think). The
attached patch fixes openjdk6, marks it as MAKE_JOBS_SAFE and makes it respect
MAKE_JOBS_NUMBER.
Regards,
David
P.S. I'm off list
--- /usr/ports/java/openjdk6/Makefile 2010-05-22 03:05:20.0 +0200
+++ Makefile 2010-06-25 18:01:27.0 +0200
@@ -45,6 +45,7 @@
# java extracts directly to the cwd
WRKSRC= ${WRKDIR}
+MAKE_JOBS_SAFE= yes
USE_GMAKE= yes
USE_MOTIF= yes
@@ -142,8 +143,11 @@
USE_DISPLAY= yes
.endif
-BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
-MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
+.if !defined(DISABLE_MAKE_JOBS)
+MAKE_ENV+= HOTSPOT_BUILD_JOBS=${MAKE_JOBS_NUMBER}
+# HACK: stop _MAKE_JOBS being defined with -jN
+MAKE_JOBS_UNSAGE=yes
+.endif
COPYDIRS= \
hotspot/src/os/linux/launcher \
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS and openjdk6
On Friday 25 June 2010 18:08:22 David Naylor wrote:
Hi,
java/openjdk6 breaks with FORCE_MAKE_JOBS (it implements its own think).
The attached patch fixes openjdk6, marks it as MAKE_JOBS_SAFE and makes it
respect MAKE_JOBS_NUMBER.
Regards,
David
P.S. I'm off list
Oops. My hack didn't work.
With MAKE_JOBS_SAFE _MAKE_JOBS is included but that evaluated to -jN and this
is choking the Makefile. Is there an easier way to exclude _MAKE_JOBS?
Perhaps set _MAKE_JOBS conditionally in bsd.ports.mk and a port can then do
_MAKE_JOBS=
The attached patch fixes the above problem without touching bsd.ports.mk.
Regards
diff -ur /usr/ports/java/openjdk6/Makefile openjdk6/Makefile
--- /usr/ports/java/openjdk6/Makefile 2010-05-22 03:05:20.0 +0200
+++ openjdk6/Makefile 2010-06-25 23:28:24.0 +0200
@@ -45,6 +45,7 @@
# java extracts directly to the cwd
WRKSRC= ${WRKDIR}
+MAKE_JOBS_SAFE= yes
USE_GMAKE= yes
USE_MOTIF= yes
@@ -142,8 +143,9 @@
USE_DISPLAY= yes
.endif
-BUILD_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
-MAKE_ENV+= HOTSPOT_BUILD_JOBS=${BUILD_JOBS_NUMBER}
+.if !defined(DISABLE_MAKE_JOBS)
+MAKE_ENV+= HOTSPOT_BUILD_JOBS=${MAKE_JOBS_NUMBER}
+.endif
COPYDIRS= \
hotspot/src/os/linux/launcher \
@@ -210,6 +212,15 @@
${WRKSRC}/jdk/make/javax/crypto/Makefile
.endif
+do-build:
+ @(cd ${BUILD_WRKSRC}; if ! ${SETENV} ${MAKE_ENV} ${GMAKE} ${MAKE_FLAGS} ${MAKEFILE} ${MAKE_ARGS} ${ALL_TARGET}; then \
+ if [ x != x${BUILD_FAIL_MESSAGE} ] ; then \
+ ${ECHO_MSG} === Compilation failed unexpectedly.; \
+ (${ECHO_CMD} ${BUILD_FAIL_MESSAGE}) | ${FMT} 75 79 ; \
+ fi; \
+ ${FALSE}; \
+ fi)
+
.if defined(WITH_TEST)
post-build:
@${ECHO_MSG}
signature.asc
Description: This is a digitally signed message part.
Re: [kde-freebsd] [CFT] KDE 4.3.2 / Qt 4.5.3 Ready for Testing
On Tuesday, 6 October 2009 20:12:55 Martin Wilke wrote: We're happy to announce that KDE-4.3.2 is ready for testing. KDE-4.3.2 is only a Bugfix release. If you want to play with KDE 4.3.2 please checkout all ports from area51. A note about area51, we have changed the repo layout, Qt and KDE is now split between area51/QT and area51/KDE. If you have an old check out please delete all and run a new checkout: svn co http://area51.pcbsd.org/trunk/area51 You'll then find 3 dirs: QT, KDE, Tools, in Tools/scripts you'll find 2 scripts to merge QT and KDE to /usr/ports. If you see any issues please let use know. Happy Testing! I've found a problem with devel/qt4-help-tools: PORTNAME=help (instead of help-tools). Other then that everything compiled fine and no apparent regressions. It looks like 'deskutils/dolphin-plugins-mplayerthumbs' has been obsoleted? Thank you for the great work. Looking forward to 8.0 (and beyond :-) ). Many thanks, David signature.asc Description: This is a digitally signed message part.
Re: MAKE_JOBS_UNSAFE (some more ports)
On Saturday 06 June 2009 22:56:47 Ion-Mihai Tetcu wrote: On Sat, 6 Jun 2009 18:05:14 +0200 David Naylor naylor.b.da...@gmail.com wrote: P.S. Is anyone interested in a list of ports that do not compile under tmpfs? Me. The following are on my blacklist for tmpfs build, where: # df -h | grep tmp tmpfs 8.3G 12M8.3G 0%/tmp # grep WRKDIRPREFIX /etc/make.conf WRKDIRPREFIX=/tmp editors/openoffice.org-3 (just to big for my computer to handle) security/gpgme* lang/ocaml** java/openjdk6*** * Confirmed build failure on 7.1p2 and -Current from December * Confirmed build success on -Current from Saturday ** I had a strange problems with math/facile that it wouldn't build if ocaml was built on tmpfs (didn't confirm this one) *** Cannot reproduce (although do remember it) From what I read it appeared that tmpfs had an internal locking problem however it appears to be fixed in current. signature.asc Description: This is a digitally signed message part.
Re: MAKE_JOBS_UNSAFE (some more ports)
On Thursday 21 May 2009 13:56:46 Pav Lucistnik wrote: On Thu, 21 May 2009 12:05:22 +0200, David Naylor wrote The following ports failed to build on my system (with a quad core) and FORCE_MAKE_JOBS set. They did success to build once I added MAKE_JOBS_UNSAFE=yes to their Makefile's. Marked in CVS, thank you! I believe java/jdk* should be marked as unsafe. They define their own do-build targets (and don't use _MAKE_JOBS) so no functional change. I've checked jdk16 with `make MAKE_ARGS=-j4` and build fails. I've found the following ports that are UNSAFE: audio/cdparanoia (under heavy load) devel/dbus-qt4 (under heavy load) java/openjdk6 Is there any effort to mark ports as MAKE_JOBS_SAFE: is it desired for ports that are successful with FORCE_MAKE_JOBS to be reported? Yes, I believe they should be reported. Here are all the ports that compile with -DFORCE_MAKE_JOBS, do not have MAKE_JOBS_* set and do not define a do-build target: (NOTE: FORCE_MAKE_JOBS=yes is in make.conf for all builds) # for i in `pkg_info -oqa`; do cd /usr/ports/$i; if [ -z `make -V MAKE_JOBS_SAFE -V MAKE_JOBS_UNSAFE` -a -z `grep do-build Makefile`]; then echo $i; fi; done | sort [ See attached for output ] Regards, David P.S. Is anyone interested in a list of ports that do not compile under tmpfs? accessibility/atk accessibility/linux-f8-atk accessibility/qt4-accessible archivers/cabextract archivers/libzip archivers/p5-Archive-Zip archivers/p5-Compress-Bzip2 archivers/p5-Compress-Raw-Zlib archivers/p5-Compress-Zlib archivers/p5-IO-Compress-Base archivers/p5-IO-Compress-Zlib archivers/p5-PerlIO-gzip archivers/p5-PerlIO-via-Bzip2 archivers/rpm archivers/unrar archivers/unzip archivers/zip astro/cfitsio astro/libnova audio/aacgain audio/amarok-kde4 audio/faac audio/faad audio/flac audio/gsm audio/lame audio/liba52 audio/libamrnb audio/libamrwb audio/libao audio/libcddb audio/libgpod audio/libid3tag audio/libmad audio/libmikmod audio/libmodplug audio/libmtp audio/libmusicbrainz audio/libofa audio/libogg audio/libtunepimp audio/libvorbis audio/madplay audio/mp3gain audio/normalize audio/sdl_mixer audio/speex audio/taglib audio/vorbis-tools audio/vorbisgain audio/wavpack comms/gnokii converters/fribidi converters/p5-MIME-Base64 databases/db46 databases/gdbm databases/mysql51-client databases/mysql51-server databases/py-bsddb databases/py-qt4-sql databases/qt4-mysql-plugin databases/qt4-sql databases/qt4-sqlite3-plugin databases/rrdtool databases/sqlite3 devel/ORBit2 devel/apache-ant devel/autoconf-wrapper devel/autoconf213 devel/autoconf262 devel/automake-wrapper devel/automake110 devel/automake14 devel/automake15 devel/automake19 devel/bison devel/boost-python devel/clanlib devel/cmake devel/dbus devel/dbus-glib devel/dbus-qt4 devel/desktop-file-utils devel/eric4 devel/gamin devel/gccmakedep devel/gconf2 devel/gettext devel/gio-fam-backend devel/glib12 devel/glib20 devel/gmake devel/gnome-vfs devel/imake devel/kdesvn-kde4 devel/libIDL devel/libcheck devel/libdaemon devel/libexecinfo devel/libglade2 devel/libical devel/libltdl15 devel/liboil devel/libpci devel/libpciaccess devel/libpthread-stubs devel/libstatgrab devel/libtool15 devel/libvolume_id devel/m4 devel/makedepend devel/newfile devel/nspr devel/p5-Algorithm-Annotate devel/p5-Algorithm-Diff devel/p5-App-CLI devel/p5-BFD devel/p5-Class-Accessor devel/p5-Class-Autouse devel/p5-Class-Data-Inheritable devel/p5-Data-Hierarchy devel/p5-Data-UUID devel/p5-ExtUtils-CBuilder devel/p5-ExtUtils-ParseXS devel/p5-File-Temp devel/p5-File-chdir devel/p5-FreezeThaw devel/p5-Getopt-Long devel/p5-IO-Digest devel/p5-IO-Pager devel/p5-IPC-Run3 devel/p5-Locale-Maketext devel/p5-Locale-Maketext-Lexicon devel/p5-Locale-Maketext-Simple devel/p5-Locale-gettext devel/p5-Log-Log4perl devel/p5-Module-Build devel/p5-Path-Class devel/p5-PathTools devel/p5-PerlIO-eol devel/p5-PerlIO-via-dynamic devel/p5-PerlIO-via-symlink devel/p5-Regexp-Shellish devel/p5-SVN-Dump devel/p5-SVN-Mirror devel/p5-SVN-Simple devel/p5-Storable devel/p5-Term-ReadKey devel/p5-Time-Progress devel/p5-TimeDate devel/p5-UNIVERSAL-require devel/p5-VCP-autrijus devel/p5-prefork devel/p5-version devel/patch devel/pcre devel/pkg-config devel/popt devel/py-astng devel/py-dbus devel/py-logilab-common devel/py-qt4-assistant devel/py-qt4-core devel/py-qt4-dbus devel/py-qt4-designer devel/py-qt4-designerplugin devel/py-qt4-help devel/py-qt4-qscintilla2 devel/py-qt4-script devel/py-qt4-test devel/py-sip devel/pylint devel/qca devel/qmake4 devel/qscintilla2 devel/qt4 devel/qt4-assistant devel/qt4-assistant-adp devel/qt4-corelib devel/qt4-designer devel/qt4-help devel/qt4-libqtassistantclient devel/qt4-linguist devel/qt4-makeqpf devel/qt4-moc devel/qt4-porting devel/qt4-qdbusviewer devel/qt4-qt3support devel/qt4-qtestlib devel/qt4-qvfb devel/qt4-rcc devel/qt4-script devel/qt4-uic devel/qt4-uic3 devel/sdl12 devel/subversion devel/t1lib devel/xorg-macros devel/yasm dns/libidn emulators/wine ftp/curl ftp/wget games/freebsd
Re: MAKE_JOBS_UNSAFE (some more ports)
On Tuesday 26 May 2009 23:23:16 Pav Lucistnik wrote:
David Naylor píše v út 26. 05. 2009 v 18:17 +0200:
What about the change that exposes MAKE_JOBS_NUMBER when MAKE_JOBS_SAFE
or FORCE_MAKE_JOBS are defined (to avoid using ${_MAKE_JOBS:C/-j//}, not
sure what the policy is of ports using *.mk internals). I think that is
a reasonable change???
I think it's reasonable. It will need to be tested widely. Can you file
a PR with just that change, to help me track it while in testing?
Done, please see PR ports/134977. This should not have any functional change
and the only ports (at this stage) that will use MAKE_JOBS_NUMBER is OOo*
(although games/teeworld is the next closest candidate).
I've also made some changes to how OOo2 handles concurrency, as pav@ pointed
out `make -j1` is different to `make` and OOo2 now differentiates between the
two, could someone please check if the following work:
(cd /usr/ports/editors/openoffice.org-2; make MAKE_JOBS_NUMBER=1)
OOo3 should be functionally the same to the previous patch however it does not
make the distinction between `make -j1` and `make` and I don't know enough
about the build process to know how to add a normal `make`.
Thanks for all your patience.
David
P.S. This should have been sent ~9 hours ago, but internet went down.
P.P.S. This should be the final patch (pending OOo2 verification).
diff -ur /usr/ports/Mk/bsd.port.mk ports/Mk/bsd.port.mk
--- /usr/ports/Mk/bsd.port.mk 2009-05-23 13:20:58.0 +0200
+++ ports/Mk/bsd.port.mk 2009-05-27 08:38:44.0 +0200
@@ -2185,11 +2185,8 @@
_MAKE_JOBS= #
.else
.if defined(MAKE_JOBS_SAFE) || defined(FORCE_MAKE_JOBS)
-.if defined(MAKE_JOBS_NUMBER)
+MAKE_JOBS_NUMBER?= `${SYSCTL} -n kern.smp.cpus`
_MAKE_JOBS= -j${MAKE_JOBS_NUMBER}
-.else
-_MAKE_JOBS= -j`${SYSCTL} -n kern.smp.cpus`
-.endif
.if defined(FORCE_MAKE_JOBS)
BUILD_FAIL_MESSAGE+= You have chosen to use multiple make jobs (parallelization) for all ports. This port was not tested for this setting. Please remove FORCE_MAKE_JOBS and retry the build before reporting the failure to the maintainer.
.endif
diff -ur /usr/ports/editors/openoffice.org-2/Makefile ports/editors/openoffice.org-2/Makefile
--- /usr/ports/editors/openoffice.org-2/Makefile 2009-01-25 10:45:45.0 +0200
+++ ports/editors/openoffice.org-2/Makefile 2009-05-27 08:38:27.0 +0200
@@ -51,6 +51,7 @@
USE_PERL5= yes
USE_BZIP2= yes
WITHOUT_CPU_CFLAGS= true
+MAKE_JOBS_SAFE= yes
.include bsd.port.pre.mk
@@ -132,7 +133,6 @@
CONFIGURE_WRKSRC= ${WRKSRC}/config_office
TCSH?= /bin/tcsh
PKGMESSAGE= ${WRKDIR}/pkg-message
-NUMOFPROCESSES?= 1
CONFIGURE_ARGS+= --with-gnu-cp=${LOCALBASE}/bin/gcp \
--with-gnu-patch=${LOCALBASE}/bin/gpatch \
@@ -192,8 +192,8 @@
do-build:
@cd ${WRKSRC} ; ./bootstrap
# PR:84786 #i53289#
-.if (${NUMOFPROCESSES}1)
- @cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; cd instsetoo_native ; build.pl -P${NUMOFPROCESSES} --all
+.if !defined(DISABLE_MAKE_JOBS)
+ @cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; cd instsetoo_native ; build.pl -P${MAKE_JOBS_NUMBER} --all
.else
@cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; dmake
.endif
diff -ur /usr/ports/editors/openoffice.org-2-RC/Makefile ports/editors/openoffice.org-2-RC/Makefile
--- /usr/ports/editors/openoffice.org-2-RC/Makefile 2009-01-25 10:45:45.0 +0200
+++ ports/editors/openoffice.org-2-RC/Makefile 2009-05-27 08:41:53.0 +0200
@@ -52,6 +52,7 @@
USE_PERL5= yes
USE_BZIP2= yes
WITHOUT_CPU_CFLAGS= true
+MAKE_JOBS_SAFE= yes
.include bsd.port.pre.mk
@@ -134,7 +135,6 @@
CONFIGURE_WRKSRC= ${WRKSRC}/config_office
TCSH?= /bin/tcsh
PKGMESSAGE= ${WRKDIR}/pkg-message
-NUMOFPROCESSES?= 1
CONFIGURE_ARGS+= --with-gnu-cp=${LOCALBASE}/bin/gcp \
--with-gnu-patch=${LOCALBASE}/bin/gpatch \
@@ -194,8 +194,8 @@
do-build:
@cd ${WRKSRC} ; ./bootstrap
# PR:84786 #i53289#
-.if (${NUMOFPROCESSES}1)
- @cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; cd instsetoo_native ; build.pl -P${NUMOFPROCESSES} --all
+.if !defined(DISABLE_MAKE_JOBS)
+ @cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; cd instsetoo_native ; build.pl -P${MAKE_JOBS_NUMBER} --all
.else
@cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; dmake
.endif
diff -ur /usr/ports/editors/openoffice.org-2-devel/Makefile ports/editors/openoffice.org-2-devel/Makefile
--- /usr/ports/editors/openoffice.org-2-devel/Makefile 2009-01-25 10:45:45.0 +0200
+++ ports/editors/openoffice.org-2-devel/Makefile 2009-05-27 08:46:03.0 +0200
@@ -52,6 +52,7 @@
USE_PERL5= yes
USE_BZIP2= yes
WITHOUT_CPU_CFLAGS= true
+MAKE_JOBS_SAFE= yes
.include bsd.port.pre.mk
Re: MAKE_JOBS_UNSAFE (some more ports)
On Tuesday 26 May 2009 10:48:25 Pav Lucistnik wrote:
David Naylor píše v út 26. 05. 2009 v 08:19 +0200:
pav: ${_MAKE_JOBS:C/-j//} won't work with DISABLE_MAKE_JOBS (or
MAKE_JOBS_UNSAFE) since it needs to always be a positive number, secondly
it still cannot be used for conditional code (since it is defined in the
post section, but the whole code could always be moved to the pre
section).
I'm hesitant to modify bsd.port.mk for benefit of just four ports.
Also, I think having MAKE_JOBS_NUMBER set to 1 when the feature is in
fact disable, is counter-intuitive (because -j1 is very different to no
-j at all).
I understand, I see the light. By the way it is two ports requiring the
below.
What about the change that exposes MAKE_JOBS_NUMBER when MAKE_JOBS_SAFE or
FORCE_MAKE_JOBS are defined (to avoid using ${_MAKE_JOBS:C/-j//}, not sure
what the policy is of ports using *.mk internals). I think that is a
reasonable change???
So how about just having
.if defined(DISABLE_MAKE_JOBS)
MAKE_JOBS_NUMBER= 1
.else
+.if !defined(MAKE_JOBS_NUMBER)
MAKE_JOBS_NUMBER!=echo `${SYSCTL} -n kern.smp.cpus`
+.endif
.endif
in ooo makefile?
This will work in OOo2*, the OOo3 will also need a check for DISABLE_MAKE_JOBS
since they rely on MKAE_JOBS_NUMBER always being set (just the way they do
things).
Will fix and send another patch.
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS_UNSAFE (some more ports)
On Monday 25 May 2009 20:01:25 Ion-Mihai Tetcu wrote:
On Mon, 25 May 2009 10:03:12 +0200
David Naylor naylor.b.da...@gmail.com wrote:
On Sunday 24 May 2009 21:37:45 Ion-Mihai Tetcu wrote:
On Sun, 24 May 2009 10:26:23 +0200
David Naylor naylor.b.da...@gmail.com wrote:
On Sunday 24 May 2009 00:16:37 Maho NAKATA wrote:
Hi I tested it yesterday,
1.
I need
MAKE_JOBS_SAFE=yes
in the Makefile.
Yes, you would need that. I believe that will be default.
2. with above patch, ooo2 doesn't launch parallele jobs.
I spotted that problem after submitting the patch, if you
explicitly set MAKE_JOBS_NUMBER to something it will work.
The problem is that ooo2 does (in effect):
.if (${MAKE_JOBS_NUMBER} 1)
# Stuff
.else
# Other stuff
.endif
and that doesn't work as expected with MAKE_JOBS_NUMBER=`sysctl
kern.smp.cpus` as the command is not resolved.
w/o patch
editors/openoffice.org-3 openoffice.org-3.1.04:53:27
with patch:
+ MAKE_JOBS_SAFE= yes
+ MAKE_JOBS_NUMBER= 4
+ MAXPROCESSES?= ${MAKE_JOBS_NUMBER}
+ MAXMODULES?=${MAKE_JOBS_NUMBER}
editors/openoffice.org-3 openoffice.org-3.1.048:51
The build is done in
/dev/md0 on /usr/local/tinderbox/7-STABLE-FPT-NPD (ufs,
asynchronous, local, noatime)
Wow, that is quite a speedup. Is it even possible (4 * 60 + 53)/4 =
73, and you get 48 (that is 152% scaling efficiency). This would
mean a serious performance problem with the ooo3 build script and
MAX* =1.
I'll make a patch tonight (+10 hours) that will fix ooo2 in the
default case. You can test ooo2 with patch and MAKE_JOBS_NUMBER
preset (not using default value) and MAKE_JOBS_SAFE=yes.
BTW, what about using the same vars for parallel building in all OOo
port?
Done, the following patch uses MAKE_JOBS_NUMBER for all the variables in OOo.
It also tries to be efficient when resolving the MAKE_JOBS_NUMBER to a value
(only done when a port sets USE_MAKE_JOBS, as in the OOo2-RC and OOo2 case).
This should fix OOo2* builds and support such use cases for other ports...
diff -ru /usr/ports/Mk/bsd.port.mk ports/Mk/bsd.port.mk
--- /usr/ports/Mk/bsd.port.mk 2009-05-23 13:20:58.0 +0200
+++ ports/Mk/bsd.port.mk 2009-05-25 22:08:58.0 +0200
@@ -1361,6 +1361,19 @@
.include ${PORTSDIR}/Mk/bsd.linux-apps.mk
.endif
+.if defined(USE_MAKE_JOBS)
+.if defined(MAKE_JOBS_UNSAFE)
+.error USE_MAKE_JOBS requested yet port is marked as MAKE_JOBS_UNSAFE
+.endif
+.if defined(DISABLE_MAKE_JOBS)
+MAKE_JOBS_NUMBER= 1
+.elif defined(FORCE_MAKE_JOBS) || defined(MAKE_JOBS_SAFE)
+.if !defined(MAKE_JOBS_NUMBER)
+MAKE_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
+.endif
+.endif
+.endif
+
.if defined(X_WINDOW_SYSTEM) ${X_WINDOW_SYSTEM:L} != xorg
IGNORE= cannot be installed: bad X_WINDOW_SYSTEM setting; valid value is 'xorg'
.endif
@@ -2182,15 +2195,13 @@
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
+MAKE_JOBS_NUMBER= 1
_MAKE_JOBS= #
.else
.if defined(MAKE_JOBS_SAFE) || defined(FORCE_MAKE_JOBS)
-.if defined(MAKE_JOBS_NUMBER)
+MAKE_JOBS_NUMBER?= `${SYSCTL} -n kern.smp.cpus`
_MAKE_JOBS= -j${MAKE_JOBS_NUMBER}
-.else
-_MAKE_JOBS= -j`${SYSCTL} -n kern.smp.cpus`
-.endif
-.if defined(FORCE_MAKE_JOBS)
+.if defined(FORCE_MAKE_JOBS) !defined(MAKE_JOBS_SAFE)
BUILD_FAIL_MESSAGE+= You have chosen to use multiple make jobs (parallelization) for all ports. This port was not tested for this setting. Please remove FORCE_MAKE_JOBS and retry the build before reporting the failure to the maintainer.
.endif
.endif
diff -ru /usr/ports/editors/openoffice.org-2/Makefile ports/editors/openoffice.org-2/Makefile
--- /usr/ports/editors/openoffice.org-2/Makefile 2009-01-25 10:45:45.0 +0200
+++ ports/editors/openoffice.org-2/Makefile 2009-05-25 22:10:21.0 +0200
@@ -48,9 +48,11 @@
USE_XORG= x11 ice xaw xau xext xrender xrandr \
xi xt xcursor xdamage xcomposite xfixes
USE_GMAKE= yes
+USE_MAKE_JOBS= yes
USE_PERL5= yes
USE_BZIP2= yes
WITHOUT_CPU_CFLAGS= true
+MAKE_JOBS_SAFE= yes
.include bsd.port.pre.mk
@@ -132,7 +134,6 @@
CONFIGURE_WRKSRC= ${WRKSRC}/config_office
TCSH?= /bin/tcsh
PKGMESSAGE= ${WRKDIR}/pkg-message
-NUMOFPROCESSES?= 1
CONFIGURE_ARGS+= --with-gnu-cp=${LOCALBASE}/bin/gcp \
--with-gnu-patch=${LOCALBASE}/bin/gpatch \
@@ -192,8 +193,8 @@
do-build:
@cd ${WRKSRC} ; ./bootstrap
# PR:84786 #i53289#
-.if (${NUMOFPROCESSES}1)
- @cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; cd instsetoo_native ; build.pl -P${NUMOFPROCESSES} --all
+.if (${MAKE_JOBS_NUMBER}1)
+ @cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source ${FREEBSD_ENV_SET} ; setenv TMP ${WRKSRC} ; cd instsetoo_native ; build.pl -P${MAKE_JOBS_NUMBER} --all
.else
@cd ${WRKSRC} ; ${SETENV} LANG=C LC_ALL=C ${TCSH} -c source
Re: MAKE_JOBS_UNSAFE (some more ports)
On Sunday 24 May 2009 00:16:37 Maho NAKATA wrote:
Hi I tested it yesterday,
1.
I need
MAKE_JOBS_SAFE=yes
in the Makefile.
Yes, you would need that. I believe that will be default.
2. with above patch, ooo2 doesn't launch parallele jobs.
I spotted that problem after submitting the patch, if you explicitly set
MAKE_JOBS_NUMBER to something it will work.
The problem is that ooo2 does (in effect):
.if (${MAKE_JOBS_NUMBER} 1)
# Stuff
.else
# Other stuff
.endif
and that doesn't work as expected with MAKE_JOBS_NUMBER=`sysctl kern.smp.cpus`
as the command is not resolved.
3. ooo3, 3-rc, 3-devel are okay with patch 1.
Good to hear.
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS_UNSAFE (some more ports)
On Sunday 24 May 2009 18:27:57 Pav Lucistnik wrote:
Ion-Mihai Tetcu píše v ne 24. 05. 2009 v 19:01 +0300:
On Sun, 24 May 2009 16:10:23 +0200
Pav Lucistnik p...@freebsd.org wrote:
Ion-Mihai Tetcu píše v so 23. 05. 2009 v 13:51 +0300:
- MAKE_JOBS_NUMBER defaults (but user defined) to number of
cores
This part looks OK, I wonder if there's any reason t ain't like this
now; Pav?
-.if defined(MAKE_JOBS_NUMBER)
+MAKE_JOBS_NUMBER?= `${SYSCTL} -n kern.smp.cpus`
_MAKE_JOBS=-j${MAKE_JOBS_NUMBER}
-.else
-_MAKE_JOBS=-j`${SYSCTL} -n kern.smp.cpus`
-.endif
Wouldn't that mean an evaluation of the backtick command in every
make(1) invocation? That would be highly undesirable.
I don't believe that is the case.
Here is what I get with the patch applied (MAKE_JOBS_NUMBER not defined):
/usr/ports/editors/openoffice.org-3# make -V MAKE_JOBS_NUMBER -V _MAKE_JOBS
`/sbin/sysctl -n kern.smp.cpus`
-j`/sbin/sysctl -n kern.smp.cpus`
Wouldn't this indicate that the backtick command is not being evaluated?
The following does, however, make MAKE_JOBS_NUMBER resolve, and fixes ooo2
with parallel build.
# Multiple make jobs support
.if defined(DISABLE_MAKE_JOBS) || defined(MAKE_JOBS_UNSAFE)
MAKE_JOBS_NUMBER= 1
_MAKE_JOBS= #
.else
.if defined(MAKE_JOBS_SAFE) || defined(FORCE_MAKE_JOBS)
.if !defined(MAKE_JOBS_NUMBER)
MAKE_JOBS_NUMBER!= ${SYSCTL} -n kern.smp.cpus
.endif
_MAKE_JOBS= -j${MAKE_JOBS_NUMBER}
[etc]
and then I get:
/usr/ports/editors/openoffice.org-3# make -V MAKE_JOBS_NUMBER -V _MAKE_JOBS
4
-j4
I agree that having sysctl being called every time is not good. I don't think
it is unavoidable in the ooo2 case (but that is only a few ports).
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS_UNSAFE (some more ports)
On Saturday 23 May 2009 12:51:33 Ion-Mihai Tetcu wrote:
On Sat, 23 May 2009 18:24:26 +0900 (JST)
Maho NAKATA cha...@mac.com wrote:
Please see attached for the patch. The changes to bsd.port.mk:
- MAKE_JOBS_NUMBER always defined
- MAKE_JOBS_NUMBER forced to 1 if UNSAFE of DISABLE
AFAIR there are ports that compile OK w/o MAKE_JOBS_SAFE but fail with
MAKE_JOBS_NUMBER=1
That is quite a problem. And this reveals a problem with openoffice-2*, it
doesn't work since it does (in-effect):
.if (${MAKE_JOBS_NUMBER} 1)
which will not work for MAKE_JOBS_NUMBER=`${SYSCTL} -n kern.smp.cpus`. Is
there anyway for MAKE_JOBS_NUMBER to get a resolved value (I think expanding
make to expose the number of cores on the system [rather radical, I know]).
If MAKE_JOBS_NUMBER can be 'fixed' then the solution is straight forward:
.if (${MAKE_JOBS_NUMBER} 1)
# Use concurrent build
.else
# Use standard build
.endif
- MAKE_JOBS_NUMBER defaults (but user defined) to number of cores
This part looks OK, I wonder if there's any reason t ain't like this
now; Pav?
-.if defined(MAKE_JOBS_NUMBER)
+MAKE_JOBS_NUMBER?= `${SYSCTL} -n kern.smp.cpus`
_MAKE_JOBS= -j${MAKE_JOBS_NUMBER}
-.else
-_MAKE_JOBS= -j`${SYSCTL} -n kern.smp.cpus`
-.endif
I believe pav@ didn't put the ' !defined(MAKE_JOBS_SAFE)' part
intentionally until we get to test all our ports.
-.if defined(FORCE_MAKE_JOBS)
+.if defined(FORCE_MAKE_JOBS) !defined(MAKE_JOBS_SAFE)
BUILD_FAIL_MESSAGE+= You have chosen to use multiple make jobs
(parallelization) for all ports. This port was not tested for this
setting. Please remove FORCE_MAKE_JOBS and retry the build before
reporting the failure to the maintainer.
Sorry but I don't see how this would change anything. The message will only
get displayed if the port fails AND -DFORCE_MAKE_JOBS, which is the less
likely scenario.
I only changed it because when testing the command output with `make build -n`
the offset changed with -DFORCE_MAKE_JOBS on a safe port. I just found it
annoying...
I've then used MAKE_JOBS_NUMBER to set MAXPROCESSES, MAXMODULES and
NUMOFPROCESSES for openoffice-* (not including 1.*).
I believe openoffice-2* can me marked as SAFE while openoffice-3*
should not be marked at all (since it sometimes works..., very well
for me :-).
This patch just makes openoffice-* behave like other ports in
regards to parallel builds and the usual MAKE_JOBS variables now
works as expected.
Nice, thanks.
signature.asc
Description: This is a digitally signed message part.
Re: MAKE_JOBS_UNSAFE (some more ports)
On Friday 22 May 2009 07:11:19 Maho NAKATA wrote: Dear, I appriciate David or Ion-Mihai make a patch for that. just seetting MAXMODULE=4 and/or MAXPROCESSES=4 or something like that. But note that sometimes it's broken :-( by missing dependencey. What do you mean by missing dependency? I had it complain about perl (or something) needing to be recompiled but that was because I interrupted the build process. It has always completed for me when using MAX* from the start. I can make the patch, only thing is bsd.port.mk will need to be patched (simple enough though). From: Ion-Mihai Tetcu ite...@freebsd.org Subject: Re: MAKE_JOBS_UNSAFE (some more ports) Date: Fri, 22 May 2009 08:03:42 +0300 On Thu, 21 May 2009 12:05:22 +0200 David Naylor naylor.b.da...@gmail.com wrote: P.P.S. editors/openoffice-3 does not obey MAKE_JOBS, it requires MAXMODULES and MAXPROCESSES set (should I file a PR?). Anything reducing OOo build time would be great :-) -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: This is a digitally signed message part.
MAKE_JOBS_UNSAFE (some more ports)
Hi, The following ports failed to build on my system (with a quad core) and FORCE_MAKE_JOBS set. They did success to build once I added MAKE_JOBS_UNSAFE=yes to their Makefile's. devel/nasm graphics/libart_lgpl lang/ocaml multimedia/mplayer multimedia/smplayer security/nss Is there any effort to mark ports as MAKE_JOBS_SAFE: is it desired for ports that are successful with FORCE_MAKE_JOBS to be reported? Regards David P.S. I'm not on the list P.P.S. editors/openoffice-3 does not obey MAKE_JOBS, it requires MAXMODULES and MAXPROCESSES set (should I file a PR?). signature.asc Description: This is a digitally signed message part.
Re: Ports requiring MAKE_JOBS_UNSAFE
On Wednesday 08 April 2009 01:26:31 Pav Lucistnik wrote: David Naylor píše v út 07. 04. 2009 v 20:07 +0200: I've recently added FORCE_MAKE_JOBS to my make.conf and the following ports popped up as failling. This is on a quad core system (running FreeBSD 7.1p2-i386). I tried MAKE_JOBS_NUMBER=3,2,1 in tern and all failed (even with =1). The ports did complete properly with DISABLE_MAKE_JOBS set. The list of ports (so far): converters/libiconv databases/firebird20-client security/libgpg-error Could someone please commit the changes required. Done. Thanks. I've found another port, although this one appears to work with MAKE_JOBS_NUMBER=1 (but not above 1). audio/nas Regards signature.asc Description: This is a digitally signed message part.
Ports requiring MAKE_JOBS_UNSAFE
Hi, I've recently added FORCE_MAKE_JOBS to my make.conf and the following ports popped up as failling. This is on a quad core system (running FreeBSD 7.1p2-i386). I tried MAKE_JOBS_NUMBER=3,2,1 in tern and all failed (even with =1). The ports did complete properly with DISABLE_MAKE_JOBS set. The list of ports (so far): converters/libiconv databases/firebird20-client security/libgpg-error Could someone please commit the changes required. Thanks P.S. Why did the ports fail with # make clean all MAKE_JOBS_NUMBER=1 FORCE_MAKE_JOBS=yes P.P.S. Not on mailling list, so please CC me. signature.asc Description: This is a digitally signed message part.
Re: [kde-freebsd] Call for Testing KDE 4.2 for FreeBSD
On Tuesday 03 February 2009 15:05:19 Max Brazhnikov wrote:
On Tue, 3 Feb 2009 08:31:10 +0200, David Naylor wrote:
On Monday 02 February 2009 12:01:10 David Naylor wrote:
Just finished compiling on FreeBSD 7.1 and have found the following
problems: 1. The fonts are not being anti-aliased? (Using default fonts
and Use anti-aliasing: Enabled {with sub-pixel rendering [RGB]}).
man fonts-conf? Never had problems with fonts, can't help here :(
I suspect this has something to do with nvidia driver. If one changes the
fonts to bitstream then anti-aliasing does work (but not with the default
fonts).
2. Network Settings doesn't detect anything to do with FreeBSD (it
probably still needs to be told about FreeBSD).
This part surely requires someone who can add support for FreeBSD.
Btw, k...@freebsd team are seeking for developers who would like to improve
KDE4 support for FreeBSD.
Should I file a PR for this, considering there probably isn't enough man-power
to actually resolve it?
3. ksudo does not install?
${KDE$_PREFIX}/lib/kde4/libexec/kdesu
Ask kde devs why kdesu is there.
Please ignore. It appears ksudo or kdesudo is a Kubuntu specific program (why
haven't they pushed the changes upstream?)
4. Samba config module doesn't find smb.conf by default. It should look
in multiple places?
This could be fixed easily I believe.
One the correct place in the code is found, yes it is. See attached. Patch
does compile cleanly and samba config module does not find smb.conf.
Makefile should probably be extended to change the lookup patch if
${LOCALBASE} isn't /usr/local? If so just
# sed -e s|/usr/local/etc/smb.conf|${LOCALBASE}/etc/smb.conf|'
$WRKSRC/kio/kio/ksambashare.cpp
I have also filed a PR (bug #183006) with an improved patch.
5. When I was changing desktop effects X froze. It was a once off
thing...
If it reappears I will file a PR.
I'll ping Alex about the status of mysql_embedded. Meantime you can try
ports/128757 for mysql_embedded and ports/130634 for amarok port.
I already have :-). I had a problem with downloading the patch... But once
that was done amarok2 installed fine :-)
The only app now that is really missing is k3b. Grrr... :-(
Regards,
David
signature.asc
Description: This is a digitally signed message part.
Re: [kde-freebsd] Call for Testing KDE 4.2 for FreeBSD
On Tuesday 03 February 2009 18:44:55 Kris Moore wrote:
David Naylor wrote:
On Tuesday 03 February 2009 15:05:19 Max Brazhnikov wrote:
On Tue, 3 Feb 2009 08:31:10 +0200, David Naylor wrote:
On Monday 02 February 2009 12:01:10 David Naylor wrote:
Just finished compiling on FreeBSD 7.1 and have found the following
problems: 1. The fonts are not being anti-aliased? (Using default
fonts and Use anti-aliasing: Enabled {with sub-pixel rendering
[RGB]}).
man fonts-conf? Never had problems with fonts, can't help here :(
I suspect this has something to do with nvidia driver. If one changes
the fonts to bitstream then anti-aliasing does work (but not with the
default fonts).
Have any of you guys been able to get KDE 4.2 to work with the latest
Xorg 7.4 in ports, and the nvidia driver? I'm playing with it here, and
it always seems to crash X right after KDE finishes logging into my
desktop. When I switch to vesa it works just fine.
Using nvidia 180.25, Xorg 7.4, KDE 4.2, etc.
I had some problems with Xorg and undefined symbols but that was just for
probing. Another problem I had was my previous xorg.conf didn't work, I
needed to provide BusID in my Device section.
Other then that now everything appears fine. Desktop Effects are working
without glitch. I did have some problems logging in, X/KDE just freezes but
Ctrl-Alt-Backspace and relogin works just fine?
I'm using nvidia-driver-177.80, xorg-7.4 on FreeBSD 7.1 (Nvidia 7600GT x2).
Does you xorg.log say anything useful, have you tried with a new config file
(Xorg -configure, nvidia-settings)?
signature.asc
Description: This is a digitally signed message part.
Re: [kde-freebsd] Call for Testing KDE 4.2 for FreeBSD
On Sunday 01 February 2009 23:02:28 Martin Wilke wrote: Howdy Guys, The KDE FreeBSD team is happy to announce the first public Call for Testing for KDE 4.2. Over the past weeks we have focused on the complex and very time consuming task to get KDE 4.2 running. Please read UPDATING-area51 before you start your update. To get KDE 4.2: try svn co https://kf.athame.co.uk/kde-freebsd/trunk/area51/ /path/to/area51 More info here: https://kf.athame.co.uk/access.php - Martin (on behalf of the KDE FreeBSD team) Hi, I'll get started on testing today. I however have this strange desire to use USB2 (the new USB stack introduced to FreeBSD-Current). Is KDE4 happy with USB2 (or to be more precise, is hald happy with USB2 yet)? Is there anything special required to compile KDE4 (and all other ports) to support USB2? I assume installing with KERNCONF=USB2 is a requirement :-) Thanks for the great work, much appreciated. Regards, David signature.asc Description: This is a digitally signed message part.
Re: [kde-freebsd] Call for Testing KDE 4.2 for FreeBSD
On Monday 02 February 2009 12:01:10 David Naylor wrote:
On Sunday 01 February 2009 23:02:28 Martin Wilke wrote:
Howdy Guys,
The KDE FreeBSD team is happy to announce the first public
Call for Testing for KDE 4.2. Over the past weeks we have
focused on the complex and very time consuming task to get
KDE 4.2 running.
Please read UPDATING-area51 before you start your update.
To get KDE 4.2:
try
svn co https://kf.athame.co.uk/kde-freebsd/trunk/area51/
/path/to/area51
More info here:
https://kf.athame.co.uk/access.php
- Martin (on behalf of the KDE FreeBSD team)
Hi,
I'll get started on testing today. I however have this strange desire to
use USB2 (the new USB stack introduced to FreeBSD-Current).
Just finished compiling on FreeBSD 7.1 and have found the following problems:
1. The fonts are not being anti-aliased? (Using default fonts and Use
anti-aliasing: Enabled {with sub-pixel rendering [RGB]}).
2. Network Settings doesn't detect anything to do with FreeBSD (it probably
still needs to be told about FreeBSD).
3. ksudo does not install?
4. Samba config module doesn't find smb.conf by default. It should look in
multiple places?
5. When I was changing desktop effects X froze. It was a once off thing...
Items 1,2, 4, (5) probably qualify for a PR, can anyone confirm these?
Item 3 probably has something to do with our ports. I really prefer to use
(k)sudo (since ksu doesn't like root without a password). Item 4 should be
fixed with a patch (until upstream comes with a proper solution).
If you wait a few hours I'll see what I can do about providing patches for
items 3, 4.
Is KDE4 happy with USB2 (or to be more precise, is hald happy with USB2
yet)?
I'll try compile hald with USB2. If that doesn't work (i.e. starts taking
100% CPU on a core) then I will not persue the issue. I'm not sure ports has
been converted to handle the base system's libusb20 in -current?
Oh and I am still having problems with HTTPS and proxy. I am going to try put
up a Squid proxy and see if Squid behaves better then WinGate. And I am
hoping Qt 4.5 will fix this proxy/socks problem (if it will hurry up and get
released :-)).
Everything else is looking good :-) and working on the FreeBSD side.
Thanks
David
P.S. Any hope in getting Amarok 2 into ports with KDE 4.2. Last I saw it was
pending on a PR to fix mysql_embedded?
signature.asc
Description: This is a digitally signed message part.
FreeBSD Port: libpreludedb-0.9.10
Hi,
I have recently tried a make index for the ports dir, it failed with a
complaint about libpreludedb, when I tried to make libpreludedb I got the
same error. (My make.conf includes WITH_PYTHON=yes)
From the build command:
make WITH_PYTHON=yes
Makefile, line 43: Could not find /Mk/bsd.python.mk
make: fatal errors encountered -- cannot continue
I have tried make -V PORTSDIR on different ports and the output
is: /usr/ports Which is correct. The problematic line, for interest sake
is:
.include ${PORTSDIR}/Mk/bsd.python.mk
I have have a current copy of ports from cvsup2.za.freebsd.org
Thanks
David
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
