Re: portmaster-with-package-support release candidate available for testing
On Fri, 04 Dec 2009 07:53:52 +0100, Christer Solskogen wrote: Err... Delete that. setenv PACKAGESITE /usr/ports/packages is the correct one. IMHO PACKAGESITE should be set to that by default. I also see that I need to run 'portmaster --check-depends' manually after doing a 'portmaster -a -PP' -- chs ___ 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
unbreak devel/smake
Here is a straightforward change to resolve name conflict between fexecve(2) and
same named function in smake sources:
.if ${OSVERSION} = 800032
post-patch:
@${FIND} ${WRKSRC} -name *.[ch] | ${XARGS} ${REINPLACE_CMD} \
-e 's/fexecve/fexecve_bsd/'
.endif
OSVERSION condition is actually not necessary, I kept it just for clarity.
--
Andriy Gapon
___
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: bsd.gnustep.mk: gnustep-objc
on 04/12/2009 10:58 Dirk Meyer said the following: Andriy Gapon schrieb:, What is the purpose of installing libobjc.so from gnustep-objc in the case when GNUSTEP_WITH_BASE_GCC is defined? Is /usr/lib/libobjc.so somehow not suitable? Esp. given that all stable and old-stable versions of FreeBSD have GCC 4.2. Am I missing something? There are FreeBSD releases which did not have a shared libobjc. or the shared object is unuseable. Do we still support ports on any of those releases? If yes, then perhaps we can add a check for those, presumably old, releases. I think there is no need to impose gnustep-objc on newer, good releases. Especially support for non i386 was broken. gnustep-objc is not perfect in that respect too: NOT_FOR_ARCHS= ia64 amd64 For example: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/51484 The port builds a tested version of libobjc.so which is needed to build gnsutep ports. Judging by information at the end of the following post, it seems that gnustep-objc is some rather dated code and needed only in non-mainstream situations: http://www.mail-archive.com/discuss-gnus...@gnu.org/msg11288.html There are still a few ports which do not build with the base gcc yet. This could be fixed in time. You can build it by setting in /etc/make.conf GNUSTEP_WITHOUT_LIBOBJC=yes GNUSTEP_WITH_BASE_GCC=yes Did you mean I can avoid gnustep-objc with these settings? But gcc will be replaced in base, so I do put not very much effort in fixing the base stuff. I don't think that this will happen any time soon. Anyway, what are problems are there with base gcc with respect to objc? I mean, this part must be identical to what is in upstream gcc (of the same version). My main point is that currently it's not possible to use GNUSTEP_WITH_BASE_GCC on recent FreeBSD releases for e.g. amd64. Because GNUSTEP_WITH_BASE_GCC injects a gnustep-objc dependency and gnustep-objc doesn't build on amd64. OTOH, everything is OK without GNUSTEP_WITH_BASE_GCC as well as with explicit GNUSTEP_WITH_GCC42. But why do I have to install another gcc 4.2.X from ports when base gcc is also 4.2? Most probably I still do miss something important. -- Andriy Gapon ___ 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: What's going on at Opera ? or is it only me ?
Op Fri, 04 Dec 2009 01:09:58 +0100 schreef Claude Buisson clbuis...@orange.fr: Hello, 1) On November 2, I submitted a bug report (DSK-269766) to Opera concerning Opera 10.01 for FreeBSD 6.4, namely that the binary was linked with libstdc++.so.6 libgcc_s.so.1 which do not exist in FreeBSD 6.4, and also with libstdc++.so.5 which in the correct library in FreeBSD 6.4 So Opera could not be started, with the message: /libexec/ld-elf.so.1: Shared object libstdc++.so.6 not found, required by opera Unfortunately, our bug system is not open for reading by the public, but I can tell you that this bug report has been received and is being looked at by our build system maintainers. A temporary solution is to install any of the gcc 4 ports on your system (eg. lang/gcc43). Arjan van Leeuwen Opera Software -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ ___ 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: What's going on at Opera ? or is it only me ?
Op Fri, 04 Dec 2009 06:49:23 +0100 schreef Doug Barton do...@freebsd.org: Claude Buisson wrote: 2) Today, I installed Opera 10.10 on a FreeBSD 7.2 system, and now the IPv6 connectivity is lost !! On the same system: Opera show me the Network problem screen, saying that http://ipv6.google.com/ in unavailable, and Firefox connects perfectly to http://ipv6.google.com/ So, am I a perfect idiot, or Opera is unable to produce a working browser (at least for FreeBSD) ? I can't comment intelligently about the library issues, but inre the IPv6 problems there are reports on another (non-FreeBSD) list that Opera is having problems in this area. It's not 100% clear what the problems were, although they seem to have been related to how Opera was preferring Teredo even when better options were available. It's also not 100% clear to me what the fix applied to the latest version was, although the rumor is that they simply changed it to prefer IPv4. Sorry to reply with sketchy information, but I wanted you to know that you were not alone. :) This is correct. There was a problem in Opera for users who had both IPv6 and IPv4 connections on *nix systems, for which we needed an immediate solution, because URLs that were reachable through both IPv4 and IPv6 were no longer working in Opera. We are aware of current problems with IPv6 addresses in Opera 10.10 (which were a result of the fix for that), and this will be fixed ASAP. Arjan van Leeuwen Opera Software -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ ___ 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: What's going on at Opera ? or is it only me ?
,--- You/Arjan (Fri, 04 Dec 2009 15:19:58 +0100) * | Unfortunately, our bug system is not open for reading by the public, but I | can tell you that this bug report has been received and is being looked at | by our build system maintainers `* This issue aside: Thank you, all your team, for the outstanding browser which is a true pleasure to use! (And for fixing (in 10.0) the issue with not updating icon titles -- the problem I entered into your bug system somewhere around the early 2008, AFAIR. :) -- Alex -- alex-goncha...@comcast.net -- ___ 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
nvidia-driver 64bit version
Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Since it's a completely different version it should IMO be seperate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. Emanuel [1] http://www.nvnews.net/vbulletin/showthread.php?t=142120 ___ 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: nvidia-driver 64bit version
On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. Since it's a completely different version it should IMO be separate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to cd category/port and make install. The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. ./danfe ___ 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: nvidia-driver 64bit version
On 04.12.2009 16:18 (UTC+1), Alexey Dokuchaev wrote: On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. Since it's a completely different version it should IMO be separate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to cd category/port and make install. The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. I tried it with patching your Makefile and distinfo. In Makefile I only changed DISTVERSION and DISTNAME and commented out ONLY_FOR_ARCHS. It installs fine and as far as I can see now all is well :-) This is on 9.0-CURRENT (amd64) from today. Rainer Hurling ./danfe ___ 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: nvidia-driver 64bit version
On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. Since it's a completely different version it should IMO be separate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to cd category/port and make install. The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. Right, you can put shared make functionality in a seperate file and include it by both ports. Personally I'd prefer two seperate ports rather than OPTIONS because the two drivers don't provide the same funcionality (ie missing TRIM support) and have different versions. Emanuel ___ 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: nvidia-driver 64bit version
On Fri, Dec 04, 2009 at 04:32:11PM +0100, Emanuel Haupt wrote: On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. Since it's a completely different version it should IMO be separate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to cd category/port and make install. The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. Right, you can put shared make functionality in a separate file and include it by both ports. Personally I'd prefer two separate ports rather than OPTIONS because the two drivers don't provide the same functionality (ie missing TRIM support) and have different versions. In any case, I'll post a diff here for review before I make any commits WRT amd64 support in nvidia-driver. ./danfe ___ 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: nvidia-driver 64bit version
On Fri, Dec 04, 2009 at 04:25:22PM +0100, Rainer Hurling wrote: On 04.12.2009 16:18 (UTC+1), Alexey Dokuchaev wrote: Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. I tried it with patching your Makefile and distinfo. In Makefile I only changed DISTVERSION and DISTNAME and commented out ONLY_FOR_ARCHS. It installs fine and as far as I can see now all is well :-) This is on 9.0-CURRENT (amd64) from today. Good to hear. I expect few things would require some adjustments (OPTIONS and packaging list come to mind first), but the fact port works with just your simple changes is definitely a good sign. ./danfe ___ 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: nvidia-driver 64bit version
On Fri, 2009-12-04 at 15:18 +, Alexey Dokuchaev wrote: On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. Since it's a completely different version it should IMO be separate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to cd category/port and make install. The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. I've never actually used the blob, but is the new driver only amd64? I presume that it does need at least 8.0-RELEASE to work, but I can't imagine that the underlying code would be different for i386/amd64. i.e. the new driver *should* be better on both i386 and amd64, at least if they have compiled an i386 version. I do still wish that nvidia would join the rest of the modern world and decide to release docs and code like every other vendor, but that is a different debate I suppose. robert. ./danfe ___ 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 -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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
FreeBSD Port: zaptel-1.4.11.2
Setting up a Asterisk box on Freebsd 7.2 i386 Need to install the wct4xxp driver for our TE212P card. Extracted the sources from the ports tarball to do a manual config of the make file. When doing a make it stops in the wct4xxp directory with this : awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/isa/isa_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O2 -fno-strict-aliasing -pipe -Wall -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -I/root/zaptel-ports/zaptel-bsd-1.4.11.2/wct4xxp/../zaptel -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c base.c base.c: In function '__t4_pci_in': base.c:433: warning: implicit declaration of function 'udelay' base.c:433: warning: nested extern declaration of 'udelay' base.c: In function '__t4_pci_out': base.c:441: warning: assignment makes integer from pointer without a cast base.c: In function 't4_gpio_setdir': base.c:485: warning: unused variable 'flags' base.c: In function 't4_gpio_set': base.c:493: warning: unused variable 'flags' base.c: In function 't4_pci_out': base.c:501: warning: unused variable 'flags' base.c: In function 't4_pci_in': base.c:525: warning: unused variable 'flags' base.c: In function 't4_framer_in': base.c:549: warning: unused variable 'flags' base.c: In function 't4_framer_out': base.c:580: warning: unused variable 'flags' base.c: In function 'hdlc_start': base.c:955: warning: unused variable 'flags' base.c: In function 't4_hdlc_hard_xmit': base.c:1259: warning: unused variable 'flags' base.c: In function 't4_rbsbits': base.c:1338: warning: unused variable 'flags' base.c:1429:11: error: macro msleep requires 5 arguments, but only 1 given base.c: In function 't4_shutdown': base.c:1429: error: 'msleep' undeclared (first use in this function) base.c:1429: error: (Each undeclared identifier is reported only once base.c:1429: error: for each function it appears in.) base.c:1390: warning: unused variable 'flags' base.c: In function 't4_chanconfig': base.c:1482: warning: unused variable 'flags' base.c: In function 'init_spans': base.c:1573: error: 'struct t4' has no member named 'vpm' base.c:1574: error: 'struct t4' has no member named 'vpm450m' base.c:1634: error: 'struct t4' has no member named 'wc_dma' base.c:1635: error: 'struct t4' has no member named 'wc_dma' base.c:1644: error: 'struct t4' has no member named 'wc_dma' base.c:1645: error: 'struct t4' has no member named 'wc_dma' base.c: In function '__t4_findsync': base.c:1781: warning: unused variable 'flags' base.c: In function 't4_startup': base.c:2024: warning: unused variable 'flags' base.c: In function 't4_receiveprep': base.c:2159: error: 'struct t4' has no member named 'wc_dma' base.c:2164: error: 'struct t4' has no member named 'wc_dma' base.c: In function '__receive_span': base.c:2254: warning: implicit declaration of function 'prefetch' base.c:2254: warning: nested extern declaration of 'prefetch' base.c: In function 't4_transmitprep': base.c:2317: error: 'struct t4' has no member named 'wc_dma' base.c:2319: error: 'struct t4' has no member named 'wc_dma' base.c: In function 't4_check_alarms': base.c:2438: warning: unused variable 'flags' base.c: In function 't4_framer_interrupt': base.c:2651: warning: unused variable 'flags' base.c: At top level: base.c:2795: warning: no previous prototype for 't4_interrupt' base.c: In function 't4_interrupt': base.c:2797: warning: unused variable 'flags' base.c: In function 't4_isr_bh': base.c:2899: warning: unused variable 'wc' base.c: At top level: base.c:2917: warning: no previous prototype for 't4_interrupt_gen2' base.c: In function 't4_interrupt_gen2': base.c:3018: error: 'struct t4' has no member named 'vpm' base.c:3018: error: 'vpmdtmfsupport' undeclared (first use in this function) base.c:3019: error: 'struct t4' has no member named 'vpm450m' base.c:3041: warning: implicit declaration of function 'tasklet_schedule' base.c:3041: warning: nested extern declaration of 'tasklet_schedule' base.c:3041: error: 'struct t4' has no member named 't4_tlet' base.c: In function 't4_reset_dma': base.c:3065: error: 'struct t4' has no member named 'wc_dma' base.c:3066: error: 'struct t4' has no member named 'wc_dma' base.c: In function 't4_tsi_assign': base.c:3396: warning: unused variable 'flags' base.c: In function 't4_tsi_unassign': base.c:3417: warning: unused variable 'flags' base.c: In function 't4_hardware_init_1': base.c:3452: error: 'struct t4' has no member named 'wc_dma' base.c:3453: error:
The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
At the end of this email I'm referencing a previous email that I sent about this before checking if the problem was the new BSD stack and it appears that it is. I just checked with my FreeBSD 9.0-CURRENT laptop and it finds the USB printer perfectly and prints as expected. It would seem that I'm going to have to upgrade all my 7.2-STABLE servers to either 8.0 or 9.0 that all have usb printers that are being shared by others through cups. I assume that either of the two would be equally problematic. I hadn't wanted to upgrade just yet but now I see little choice. I've almost always run current on them and upgrade less than on my laptop and have never had any major problem since 4.0 or maybe before. That makes my upgrading seamless although a bit risky. I wonder, if anyone who has upgraded, could give me a suggestion as to which method to use cvsup or burn a cd/dvd and I will need to recompile all ports and the first thing that pops into my mind is the example in the portmaster manual page. One other question, Shouldn't this have a notation in UPGRADING and maybe a work around? Thanks for any suggestions, ed Reference: Re: The new cups ports seem to not recognize or I don't know how to configure usb printers. Quoting eculp ec...@encontacto.net: I haven't had a problem like this with cups in years. I updated cups yesterday and can no longer print, install, reinstall usb printers. In admin/add a printer I have no local options only: Other Network Printers: Internet Printing Protocol (http) Internet Printing Protocol (ipp) LPD/LPR Host or Printer AppSocket/HP JetDirect No input for discription, location, etc. The usb printers are recognized when connected or disconnected by the kernel. I am seeing this on both up to date current and 7.2 Stable. I am going through the documentation hoping to find the problem. If not, what is the best way to go back to the previous port? Thanks, ed ___ 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: nvidia-driver 64bit version
On Fri, 4 Dec 2009, Robert Noland wrote: *snip* I've never actually used the blob, but is the new driver only amd64? I presume that it does need at least 8.0-RELEASE to work, but I can't imagine that the underlying code would be different for i386/amd64. i.e. the new driver *should* be better on both i386 and amd64, at least if they have compiled an i386 version. My understanding is that the blob is the same on all platforms. The driver may be the same (or close). The package is different. While both ship with Linux x86 libraries, they contain only the FreeBSD libraries specific to the platform (amd64 or i386). I do still wish that nvidia would join the rest of the modern world and decide to release docs and code like every other vendor, but that is a different debate I suppose. I concur, yet I am very happy at the moment to see them support FreeBSD amd64. Sean -- s...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nvidia-driver 64bit version
On Fri, Dec 04, 2009 at 10:20:10AM -0600, Robert Noland wrote: I've never actually used the blob, but is the new driver only amd64? I presume that it does need at least 8.0-RELEASE to work, but I can't imagine that the underlying code would be different for i386/amd64. Driver we talk about is beta 195.22, and it exists for both i386 and amd64. It officially supports FreeBSD 7.2 with a current RELENG_7 kernel (= 702106; use of a top-of-tree RELENG_7 kernel is recommended to ensure recent Linux ABI compatibility fixes are picked up); 8.0 is also supported: http://www.nvnews.net/vbulletin/showthread.php?t=142120 ./danfe ___ 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: nvidia-driver 64bit version
On Fri, Dec 4, 2009 at 10:20 AM, Robert Noland rnol...@freebsd.org wrote: On Fri, 2009-12-04 at 15:18 +, Alexey Dokuchaev wrote: On Fri, Dec 04, 2009 at 03:47:24PM +0100, Emanuel Haupt wrote: Hi I was wondering if you're working on a port for the 64bit version of the new beta state nvidia driver [1]. Yup, thanks for the pointer. I'm considering options right now. Since it's a completely different version it should IMO be separate from x11/nvidia-driver. Maybe x11/nvidia-driver-amd64 and x11/nvidia-driver could be renamed to x11/nvidia-driver-i386. This would be the easiest route, but I'm not sure this is the best thing to do. From user's perspective, one should be able to cd category/port and make install. The rest (including taking care of architecture-dependent things) should be handled by underlying infrastructure. Right now I believe our bpm is capable of the task, and my pmake/bpm-fu is strong enough, we'll see. I've never actually used the blob, but is the new driver only amd64? I presume that it does need at least 8.0-RELEASE to work, but I can't it also works with RELENG_7 (but not 7.2R) as a side note, I installed wine in a 32bit chroot and installed the 32bit version of the new nvidia driver and I can Play World of Warcraft without any issues, so I guess it works Just like linux does. Sam Fourman Jr. Fourman Networks ___ 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
php5-ffmpeg = config.m4 broken
Hello, I don't know if this issue concern port maintainer or php ffmpeg extension team directly, but after make extract in FreeBSD ports there's an error in config.m4, this line use PHP == operator that is of course not available in a .m4 file : if test $enable_ffmpeg_swscale == yes; then the wrong line must be replaced with : if test $enable_ffmpeg_swscale = yes; then or the ffmpeg_frame-toGDImage() function will not work because detection of swscale presence made by configure script is not working Thanks to fix and/or to tell me where to direct the issue. Hope this help ! ___ 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: The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
On Fri, 04 Dec 2009 12:49:10 -0600 eculp ec...@encontacto.net wrote: At the end of this email I'm referencing a previous email that I sent about this before checking if the problem was the new BSD stack and it appears that it is. I just checked with my FreeBSD 9.0-CURRENT laptop and it finds the USB printer perfectly and prints as expected. It would seem that I'm going to have to upgrade all my 7.2-STABLE servers to either 8.0 or 9.0 that all have usb printers that are being shared by others through cups. I assume that either of the two would be equally problematic. I hadn't wanted to upgrade just yet but now I see little choice. I've almost always run current on them and upgrade less than on my laptop and have never had any major problem since 4.0 or maybe before. That makes my upgrading seamless although a bit risky. I took me some time, but I can confirm that the new CUPS does not see USB printers on a GENERIC 7.2 kernel. It does, however, if you delete the ulpt driver from the kernel. Which you don't need anymore anyway. HTH ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: rt-3.8.4_1
On Dec 3, 2009, at 5:19 PM, Steven Kreuzer wrote: On Dec 3, 2009, at 4:44 PM, Kyle McKinley wrote: Hello, I was just wondering when the 3.8.6 would be available? Thanks! I am currently running 3.8.6 through tinderbox so the answer is in the very near future.. If you (or anyone on the ports mailing list) happen to be in a position to help me test out this update, please get in touch with me Patch can be found at http://exit2shell.com/~skreuzer/patches/rt38.patch This is a fairly complex port so if anyone is able to assist in testing a live install, please do so and let me know if you encounter any problems. I am going to test it out a little bit more and hopefully next week I'll commit it to the ports tree. -- Steven Kreuzer http://www.exit2shell.com/~skreuzer ___ 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
[HEADS UP] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx.
Hi Radeon HD 2xxx, 3xxx and 4xxx users!
I'm ready to update ports related Mesa3D to 7.6 base, graphics/dri,
graphics/libGL*, graphics/libglut, graphics/mesa-demos and
graphics/libdrm. Please see also my attached patch file. I'll
update these as soon as tomorrow.
Mesa3D 7.6 supports experimental r600 driver, as known as AMD
R6xx/R7xx architecture. I confirmed that it's good works, but
buggy on my Radeon HD 4850 environment with 9-current/amd64 and
xf86-video-radeonhd-devel. Please see also [I known problem]
section.
[kernel support]
maybe, 7-stable, 8-release(at least 8-stable) and 9-current are OK.
http://svn.freebsd.org/changeset/base/196470 (HEAD 2009/08/23)
http://svn.freebsd.org/changeset/base/198685 (RELENG_8 2009/10/30)
http://svn.freebsd.org/changeset/base/198686 (RELENG_7 2009/10/30)
[X11 driver support]
x11-drivers/xf86-video-ati OK
x11-drivers/xf86-video-radeonhd I don't know
x11-drivers/xf86-video-radeonhd-devel OK
[To enable xorg.conf]
Section ServerFlags
Option AIGLX true
EndSection
[I know a problem]
3D accelerated applications like glxgear, compiz display with
bluish coloring. I confirmed git master branch Mesa3D codes,
too. So I consider that this problem wasn't be fixed.
[Why update to 7.6]
I confirmed git master and 7.6, I think these are almost same
quality. So I choose 7.6.
Index: dri/distinfo
===
RCS file: /home/ncvs/ports/graphics/dri/distinfo,v
retrieving revision 1.17
diff -u -r1.17 distinfo
--- dri/distinfo24 Jun 2009 01:15:07 - 1.17
+++ dri/distinfo5 Dec 2009 00:59:36 -
@@ -1,3 +1,3 @@
-MD5 (MesaLib-7.4.4.tar.bz2) = b66528d314c574dccbe0ed963cac5e93
-SHA256 (MesaLib-7.4.4.tar.bz2) =
eaf73d7a3a2dc959ddc0753abaa18160c64bec00b35bf4a0c96040b2072918ec
-SIZE (MesaLib-7.4.4.tar.bz2) = 3375615
+MD5 (MesaLib-7.6.tar.bz2) = 8c75f90cd0303cfac9e4b6d54f6759ca
+SHA256 (MesaLib-7.6.tar.bz2) =
782a7b2810b1c466b3a994eba96485b59b47cc1120c0caa24de1aecf1e013830
+SIZE (MesaLib-7.6.tar.bz2) = 4866983
Index: dri/pkg-plist
===
RCS file: /home/ncvs/ports/graphics/dri/pkg-plist,v
retrieving revision 1.11
diff -u -r1.11 pkg-plist
--- dri/pkg-plist 24 Jan 2009 18:13:00 - 1.11
+++ dri/pkg-plist 5 Dec 2009 00:59:36 -
@@ -7,6 +7,7 @@
lib/dri/r128_dri.so
lib/dri/r200_dri.so
lib/dri/r300_dri.so
+lib/dri/r600_dri.so
lib/dri/radeon_dri.so
lib/dri/savage_dri.so
lib/dri/sis_dri.so
Index: dri/files/patch-configure
===
RCS file: dri/files/patch-configure
diff -N dri/files/patch-configure
--- dri/files/patch-configure 10 Apr 2009 18:00:47 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,11 +0,0 @@
configure.orig 2009-03-28 00:59:46.0 +
-+++ configure 2009-04-05 11:53:44.0 +
-@@ -5739,7 +5739,7 @@
- ;;
- *freebsd* | dragonfly*)
- case $host_cpu in
--i*86|x86_64) default_driver=dri;;
-+i*86|x86_64|powerpc*|sparc*) default_driver=dri;;
- esac
- ;;
- esac
Index: libGL/bsd.mesalib.mk
===
RCS file: /home/ncvs/ports/graphics/libGL/bsd.mesalib.mk,v
retrieving revision 1.15
diff -u -r1.15 bsd.mesalib.mk
--- libGL/bsd.mesalib.mk22 Aug 2009 00:22:54 - 1.15
+++ libGL/bsd.mesalib.mk5 Dec 2009 00:59:36 -
@@ -17,7 +17,7 @@
# $FreeBSD: ports/graphics/libGL/bsd.mesalib.mk,v 1.15 2009/08/22 00:22:54
amdmi3 Exp $
#
-MESAVERSION= 7.4.4
+MESAVERSION= 7.6
MASTER_SITES?= SF/mesa3d/MesaLib/${PORTVERSION}:mesa \
ftp://ftp.fu-berlin.de/pub/unix/X11/graphics/Mesa/:mesa,glut,demos
MASTER_SITE_SUBDIR=mesa3d
@@ -32,6 +32,7 @@
CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include \
LDFLAGS=-L${LOCALBASE}/lib
+CONFIGURE_ARGS=--disable-gallium
ALL_TARGET=default
Index: libGL/distinfo
===
RCS file: /home/ncvs/ports/graphics/libGL/distinfo,v
retrieving revision 1.11
diff -u -r1.11 distinfo
--- libGL/distinfo 24 Jun 2009 01:15:06 - 1.11
+++ libGL/distinfo 5 Dec 2009 00:59:36 -
@@ -1,3 +1,3 @@
-MD5 (MesaLib-7.4.4.tar.bz2) = b66528d314c574dccbe0ed963cac5e93
-SHA256 (MesaLib-7.4.4.tar.bz2) =
eaf73d7a3a2dc959ddc0753abaa18160c64bec00b35bf4a0c96040b2072918ec
-SIZE (MesaLib-7.4.4.tar.bz2) = 3375615
+MD5 (MesaLib-7.6.tar.bz2) = 8c75f90cd0303cfac9e4b6d54f6759ca
+SHA256 (MesaLib-7.6.tar.bz2) =
782a7b2810b1c466b3a994eba96485b59b47cc1120c0caa24de1aecf1e013830
+SIZE (MesaLib-7.6.tar.bz2) = 4866983
Index: libGL/pkg-plist
Re: The new cups ports seem to not recognize usb printers on FreeBSD 7.2-STABLE
Dirk Meyer wrote: eculp schrieb:, would seem that I'm going to have to upgrade all my 7.2-STABLE servers to either 8.0 or 9.0 that all have usb printers that are being shared by others through cups. Please update the ports and try again. I would like to know if using libusb solves your problems. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [dirk.me...@dinoex.sub.org],[dirk.me...@guug.de],[din...@freebsd.org] http://people.freebsd.org/~dinoex/errorlogs/ ___ 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 I have been having a different cups problem related to the man page portion of this on a FreeBSD 8 system. This has been a problem that I believe appeared early this week. Compiling mantohtml.c... cc -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -I.. -D_CUPS_SOURCE -I/usr/local/include -O2 -pipe -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -c mantohtml.c cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler -L/usr/local/lib -Wl,-R/usr/local/lib -pie -fPIE -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -o mantohtml mantohtml.o echo Converting man pages to HTML... Converting man pages to HTML... for file in cancel.1 cupstestdsc.1 cupstestppd.1 lp.1 lpoptions.1 lppasswd.1 lpq.1 lprm.1 lpr.1 lpstat.1 ppdc.1 ppdhtml.1 ppdi.1 ppdmerge.1 ppdpo.1; do \ echo $file...; \ ./mantohtml `basename $file .1`.man ../doc/help/man-`basename $file .1`.html; \ done cancel.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR cupstestdsc.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR cupstestppd.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lp.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lpoptions.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lppasswd.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lpq.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lprm.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lpr.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR lpstat.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR ppdc.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR ppdhtml.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR ppdi.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR ppdmerge.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR ppdpo.1... /libexec/ld-elf.so.1: ./mantohtml: invalid PT_PHDR gmake[1]: *** [html] Error 1 gmake[1]: Leaving directory `/usr/ports/print/cups-base/work/cups-1.4.2/man' gmake: *** [all] Error 1 *** Error code 1 Stop in /usr/ports/print/cups-base. *** Error code 1 Stop in /usr/ports/print/cups-base. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20091204-2776-1rxg9wx-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=cups-base-1.3.10_4 UPGRADE_PORT_VER=1.3.10_4 make ** Fix the problem and try again. ___ 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: mail/perdition 1.18 available
Sandra Kachelmann wrote: Hi Version 1.18 of perdition is available. Could you please update the port? You might want to take a look at http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html and have a go yourself. :) Good luck, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ 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: [HEADS UP] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx.
On 12/4/09, Norikatsu Shigemura n...@freebsd.org wrote:
Hi Radeon HD 2xxx, 3xxx and 4xxx users!
I'm ready to update ports related Mesa3D to 7.6 base, graphics/dri,
graphics/libGL*, graphics/libglut, graphics/mesa-demos and
graphics/libdrm. Please see also my attached patch file. I'll
update these as soon as tomorrow.
Mesa3D 7.6 supports experimental r600 driver, as known as AMD
R6xx/R7xx architecture. I confirmed that it's good works, but
buggy on my Radeon HD 4850 environment with 9-current/amd64 and
xf86-video-radeonhd-devel. Please see also [I known problem]
section.
[kernel support]
maybe, 7-stable, 8-release(at least 8-stable) and 9-current are OK.
http://svn.freebsd.org/changeset/base/196470 (HEAD 2009/08/23)
http://svn.freebsd.org/changeset/base/198685 (RELENG_8 2009/10/30)
http://svn.freebsd.org/changeset/base/198686 (RELENG_7 2009/10/30)
[X11 driver support]
x11-drivers/xf86-video-ati OK
x11-drivers/xf86-video-radeonhd I don't know
x11-drivers/xf86-video-radeonhd-devel OK
[To enable xorg.conf]
Section ServerFlags
Option AIGLX true
EndSection
[I know a problem]
3D accelerated applications like glxgear, compiz display with
bluish coloring. I confirmed git master branch Mesa3D codes,
too. So I consider that this problem wasn't be fixed.
[Why update to 7.6]
I confirmed git master and 7.6, I think these are almost same
quality. So I choose 7.6.
I patched my ports tree, but when I ran portmaster to update the
installed ports, it was unable to download the MesaLib file:
= Attempting to fetch from
http://heanet.dl.sourceforge.net/project/mesa3d/MesaLib/7.6/.
fetch:
http://heanet.dl.sourceforge.net/project/mesa3d/MesaLib/7.6/MesaLib-7.6.tar.bz2:
Moved Temporarily
= Attempting to fetch from
http://sunet.dl.sourceforge.net/project/mesa3d/MesaLib/7.6/.
fetch:
http://sunet.dl.sourceforge.net/project/mesa3d/MesaLib/7.6/MesaLib-7.6.tar.bz2:
Moved Temporarily
I had to add the following to MASTER_SITES in graphics/libGL/bsd.mesalib.mk:
ftp://ftp.freedesktop.org/pub/mesa/${MESAVERSION}/:mesa,glut,demos
Scot
___
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
