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 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. Adding MAKE_JOBS_NUMBER!=`sysctl kern.smp.cpus` in the port Makefile should help. -- 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: PGP signature
Re: MAKE_JOBS_UNSAFE (some more ports)
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. -- Pav Lucistnik p...@oook.cz p...@freebsd.org See file. Click file. Get file. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: [announce] bsd.port.options.mk available
Dmitry Marakasov píše v pá 22. 05. 2009 v 18:31 +0400: * Pav Lucistnik (p...@freebsd.org) wrote: we finally decided that enough users migrated to recent enough FreeBSD versions that we can finally suggest that maintainers can start using bsd.port.options.mk file in their ports. The examples in Porter's Handbook had been updated to illustrate a new usage. This will solve the problem with USE_* flags people were seeing. Perhaps we can also start to deprecate WANT_*? Looks a bit radical to me. Or is there a good reason to do so? -- Pav Lucistnik p...@oook.cz p...@freebsd.org Silence is an oasis in the desert of everlasting chatter. -- Quincy signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: Force rebuild/reinstall dependent ports
On Sun, 24 May 2009 02:18:05 +0100 RW rwmailli...@googlemail.com wrote: On Sat, 23 May 2009 20:22:03 -0400 Robert Huff roberth...@rcn.com wrote: Marcin Rzepecki writes: But why won't port do this automatically? Is there a way to force it before installing updated port version? Revuilding a dependency (here, dovecot) does not always require rebuilding the dependant port. Sometimes, but not always. Also: are you aware of ports-mgmt/portupgrade, ports-mgmt/portmaster, etc.? This kind of thing should be in UPDATING. Portmanager will update automatically, at the expense of a lot of gratuitous rebuilding. I use 'portmanager' myself. It fixes a lot of problems that other 'update managers' seem to miss. Update your ports tree and then run: portmanager mail/dovecot -l -f -y That should get all of your dependencies corrected. -- Jerry ges...@yahoo.com The reverse side also has a reverse side. Japanese proverb signature.asc Description: PGP signature
pciVideoPtr typedef problem causes failue of x11/xorg update:
Problems on portupgrade Does anyone know how to resolve this one(Please also see also note below): Thanks in advance for any help David # Portupgrade -a : : - x11-drivers/xf86-video-via (marked as IGNORE) : : : --- Skipping 'x11/xorg' (xorg-7.4_1) because a requisite package 'xf86-video-via-0.2.2_3' (x11-drivers/xf86-video-via) failed [r...@dns1 /usr/ports/x11-drivers/xf86-video-via]# make configure === xf86-video-via-0.2.2_5 requires pciVideoPtr typedef. *** Error code 1 Stop in /usr/ports/x11-drivers/xf86-video-via. Note: I seem to be getting a lot of IGNORES: - databases/mysqlman (marked as IGNORE) - mail/postfix (marked as IGNORE) - x11-toolkits/ruby-panelapplet (marked as IGNORE) - x11-drivers/xf86-input-calcomp (marked as IGNORE) - x11-drivers/xf86-input-digitaledge (marked as IGNORE) - x11-drivers/xf86-input-dmc (marked as IGNORE) - x11-drivers/xf86-input-dynapro (marked as IGNORE) - x11-drivers/xf86-input-elo2300 (marked as IGNORE) - x11-drivers/xf86-input-jamstudio (marked as IGNORE) - x11-drivers/xf86-input-magellan (marked as IGNORE) - x11-drivers/xf86-input-magictouch (marked as IGNORE) - x11-drivers/xf86-input-microtouch (marked as IGNORE) - x11-drivers/xf86-input-palmax (marked as IGNORE) - x11-drivers/xf86-input-spaceorb (marked as IGNORE) - x11-drivers/xf86-input-summa (marked as IGNORE) - x11-drivers/xf86-input-tek4957 (marked as IGNORE) - x11-drivers/xf86-video-cyrix (marked as IGNORE) - x11-drivers/xf86-video-imstt (marked as IGNORE) - x11-drivers/xf86-video-vga (marked as IGNORE) - x11-drivers/xf86-video-via (marked as IGNORE) ___ 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: [announce] bsd.port.options.mk available
Dmitry Marakasov píše v ne 24. 05. 2009 v 19:33 +0400: * Pav Lucistnik (p...@freebsd.org) wrote: Perhaps we can also start to deprecate WANT_*? Looks a bit radical to me. Or is there a good reason to do so? I meant slow transition from WANT_, like we do with ${MASTER_SITE_SOURCEFORCE} - SF. WANT_* feel clumsy and inconsistent, as sometimes it is not needed (i.e. I can use USE_* after pre.mk), and sometimes it is not available (i.e. not WANT_QT4). I'm okay with slow transition. BTW I never understood why we need SF in place of MASTER_SITE_SOURCEFORGE... -- Pav Lucistnik p...@oook.cz p...@freebsd.org But soft, what light through yonder window breaks? It is the East, and Juliet is the sun! Arise, fair sun, and kill the envious moon, who is already sick and pale with grief that thou her maid art far more fair than she. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: pciVideoPtr typedef problem causes failue of x11/xorg update:
On Sun, 2009-05-24 at 08:47 -0700, David Southwell wrote: Problems on portupgrade Does anyone know how to resolve this one(Please also see also note below): Thanks in advance for any help Uninstall them... They are no longer supported and will be removed at some point. You may also want to re-run make config on x11/xorg-drivers and cleanup the options to only include the drivers that you need. robert. David # Portupgrade -a : : - x11-drivers/xf86-video-via (marked as IGNORE) : : : --- Skipping 'x11/xorg' (xorg-7.4_1) because a requisite package 'xf86-video-via-0.2.2_3' (x11-drivers/xf86-video-via) failed [r...@dns1 /usr/ports/x11-drivers/xf86-video-via]# make configure === xf86-video-via-0.2.2_5 requires pciVideoPtr typedef. *** Error code 1 Stop in /usr/ports/x11-drivers/xf86-video-via. Note: I seem to be getting a lot of IGNORES: - databases/mysqlman (marked as IGNORE) - mail/postfix (marked as IGNORE) - x11-toolkits/ruby-panelapplet (marked as IGNORE) - x11-drivers/xf86-input-calcomp (marked as IGNORE) - x11-drivers/xf86-input-digitaledge (marked as IGNORE) - x11-drivers/xf86-input-dmc (marked as IGNORE) - x11-drivers/xf86-input-dynapro (marked as IGNORE) - x11-drivers/xf86-input-elo2300 (marked as IGNORE) - x11-drivers/xf86-input-jamstudio (marked as IGNORE) - x11-drivers/xf86-input-magellan (marked as IGNORE) - x11-drivers/xf86-input-magictouch (marked as IGNORE) - x11-drivers/xf86-input-microtouch (marked as IGNORE) - x11-drivers/xf86-input-palmax (marked as IGNORE) - x11-drivers/xf86-input-spaceorb (marked as IGNORE) - x11-drivers/xf86-input-summa (marked as IGNORE) - x11-drivers/xf86-input-tek4957 (marked as IGNORE) - x11-drivers/xf86-video-cyrix (marked as IGNORE) - x11-drivers/xf86-video-imstt (marked as IGNORE) - x11-drivers/xf86-video-vga (marked as IGNORE) - x11-drivers/xf86-video-via (marked as IGNORE) ___ 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 signature.asc Description: This is a digitally signed message part
Re: MAKE_JOBS_UNSAFE (some more ports)
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. Umm, why? it shouldn't be evaluated if MAKE_JOBS_NUMBER is defined, no? Am I missing some make magic here? -- 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: PGP signature
Re: MAKE_JOBS_UNSAFE (some more ports)
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. Umm, why? it shouldn't be evaluated if MAKE_JOBS_NUMBER is defined, no? Am I missing some make magic here? But for 99.99% of the users, MAKE_JOBS_NUMBER is not defined. -- Pav Lucistnik p...@oook.cz p...@freebsd.org ... the obese drugged penguin used by Linux. -- Scott Long signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: pciVideoPtr typedef problem causes failue of x11/xorg update:
On Sunday 24 May 2009 08:49:10 Robert Noland wrote: On Sun, 2009-05-24 at 08:47 -0700, David Southwell wrote: Problems on portupgrade Does anyone know how to resolve this one(Please also see also note below): Thanks in advance for any help Thanks Robert however... Uninstall them... Are you saying it is OK to uninstall all of the IGNORE driver ports.. but then you go on to say I should clean up the options to only include the drivers I need. Being a bit of a dumb cluck I therefore need to ask the question how do I find out which drivers I need? Thanks again David They are no longer supported and will be removed at some point. You may also want to re-run make config on x11/xorg-drivers and cleanup the options to only include the drivers that you need. robert. David # Portupgrade -a - x11-drivers/xf86-video-via (marked as IGNORE) --- Skipping 'x11/xorg' (xorg-7.4_1) because a requisite package 'xf86-video-via-0.2.2_3' (x11-drivers/xf86-video-via) failed [r...@dns1 /usr/ports/x11-drivers/xf86-video-via]# make configure === xf86-video-via-0.2.2_5 requires pciVideoPtr typedef. *** Error code 1 Stop in /usr/ports/x11-drivers/xf86-video-via. Note: I seem to be getting a lot of IGNORES: - databases/mysqlman (marked as IGNORE) - mail/postfix (marked as IGNORE) - x11-toolkits/ruby-panelapplet (marked as IGNORE) - x11-drivers/xf86-input-calcomp (marked as IGNORE) - x11-drivers/xf86-input-digitaledge (marked as IGNORE) - x11-drivers/xf86-input-dmc (marked as IGNORE) - x11-drivers/xf86-input-dynapro (marked as IGNORE) - x11-drivers/xf86-input-elo2300 (marked as IGNORE) - x11-drivers/xf86-input-jamstudio (marked as IGNORE) - x11-drivers/xf86-input-magellan (marked as IGNORE) - x11-drivers/xf86-input-magictouch (marked as IGNORE) - x11-drivers/xf86-input-microtouch (marked as IGNORE) - x11-drivers/xf86-input-palmax (marked as IGNORE) - x11-drivers/xf86-input-spaceorb (marked as IGNORE) - x11-drivers/xf86-input-summa (marked as IGNORE) - x11-drivers/xf86-input-tek4957 (marked as IGNORE) - x11-drivers/xf86-video-cyrix (marked as IGNORE) - x11-drivers/xf86-video-imstt (marked as IGNORE) - x11-drivers/xf86-video-vga (marked as IGNORE) - x11-drivers/xf86-video-via (marked as IGNORE) ___ 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-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: [Call For Testing] VirtualBox for FreeBSD! take 3
On Fri, May 22, 2009 at 07:59:57PM +0200, Martin Wilke wrote: We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz happy testing. I've had problems with all vbox builds where the machine screen just turns gray: http://people.freebsd.org/~lulf/2009-05-24-185847_1024x768_scrot.png I also have a truss log here (quite big): http://people.freebsd.org/~lulf/virtualbox_truss.log -- Ulf Lilleengen ___ 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: [Call For Testing] VirtualBox for FreeBSD! take 3
On søn, mai 24, 2009 at 07:02:37pm +0200, Ulf Lilleengen wrote: On Fri, May 22, 2009 at 07:59:57PM +0200, Martin Wilke wrote: We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz happy testing. I've had problems with all vbox builds where the machine screen just turns gray: http://people.freebsd.org/~lulf/2009-05-24-185847_1024x768_scrot.png I also have a truss log here (quite big): http://people.freebsd.org/~lulf/virtualbox_truss.log I forgot to mention, this is i386, Core Duo CPU -- Ulf Lilleengen ___ 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: pciVideoPtr typedef problem causes failue of x11/xorg update:
On Sun, 24 May 2009 10:49:10 -0500 Robert Noland rnol...@freebsd.org wrote: On Sun, 2009-05-24 at 08:47 -0700, David Southwell wrote: Problems on portupgrade Does anyone know how to resolve this one(Please also see also note below): Thanks in advance for any help Uninstall them... They are no longer supported and will be removed at some point. You may also want to re-run make config on x11/xorg-drivers and cleanup the options to only include the drivers that you need. I think that should be: x11-drivers/xorg-drivers. -- Jerry ges...@yahoo.com Ever notice that the word therapist breaks down into the rapist? Simple coincidence? Maybe... signature.asc Description: PGP signature
Re: [Call For Testing] VirtualBox for FreeBSD! take 3
On Sun, May 24, 2009 7:04 pm, Ulf Lilleengen wrote: On søn, mai 24, 2009 at 07:02:37pm +0200, Ulf Lilleengen wrote: On Fri, May 22, 2009 at 07:59:57PM +0200, Martin Wilke wrote: We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz happy testing. I've had problems with all vbox builds where the machine screen just turns gray: http://people.freebsd.org/~lulf/2009-05-24-185847_1024x768_scrot.png I also have a truss log here (quite big): http://people.freebsd.org/~lulf/virtualbox_truss.log I forgot to mention, this is i386, Core Duo CPU It looks like it's the same problem as a few others already mentioned. You could try to set kern.hz=1000 which should help. If that's the case please also test the patch from aeichner that should fix that problem. http://pastebin.ca/1433127 That patch is from upstream and so young that it's not yet included in the port but feedback would be great. -- Bernhard Fröhlich http://www.bluelife.at/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: 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 package-recursive problem
I have no clue as to what is causing this, but this is probably the reason why people use the tinderbox or roll their own system to build consistent packages. I feel like I am though? I have a dedicated box just for building packages. make package creates a tbz file of all packages, and is supposed to be reliable. Another approach had even the package dependency inside a Makefile, so rebuilding the gettext package would trigger all dependent packages to get rebuilt too (I haven't tackled the problem of *reinstalling* them on the target hosts, though) Doesn't this already occur with the default tools in the port system? ___ 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: [Call For Testing] VirtualBox for FreeBSD! take 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, May 24, 2009 at 07:02:38PM +0200, Ulf Lilleengen wrote: On Fri, May 22, 2009 at 07:59:57PM +0200, Martin Wilke wrote: We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz happy testing. I've had problems with all vbox builds where the machine screen just turns gray: http://people.freebsd.org/~lulf/2009-05-24-185847_1024x768_scrot.png Hi Ulf can you try this patch here: http://pastebin.ca/1433127 this fixed all problems :-). - - Martin I also have a truss log here (quite big): http://people.freebsd.org/~lulf/virtualbox_truss.log -- Ulf Lilleengen - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkoZj2wACgkQdLJIhLHm/OmPCgCghhkvqHbZwWJBp6SINiex5YCY HzUAn3pUB6yJvtdhRrVFZOQFTGVa2SOx =JByU -END PGP SIGNATURE- ___ 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: [Call For Testing] VirtualBox for FreeBSD! take 3
On søn, mai 24, 2009 at 08:18:20pm +0200, Martin Wilke wrote: On Sun, May 24, 2009 at 07:02:38PM +0200, Ulf Lilleengen wrote: On Fri, May 22, 2009 at 07:59:57PM +0200, Martin Wilke wrote: We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz happy testing. I've had problems with all vbox builds where the machine screen just turns gray: http://people.freebsd.org/~lulf/2009-05-24-185847_1024x768_scrot.png Hi Ulf can you try this patch here: http://pastebin.ca/1433127 this fixed all problems :-). Yes indeed :) It works fine on hz=100 as well as 1000 now. Thanks! -- Ulf Lilleengen ___ 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
graphics/sane-backends compilation still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As follows, with either portmaster or portupgrade: /bin/sh ../libtool --silent --tag=CC --mode=compile cc -DHAVE_CONFIG_H - -I../include/sane -I. -I/usr/local/include -I. -I. -I../include - -I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=canon_dr - -I/usr/local/include -D_REENTRANT - -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d - -DPATH_SANE_DATA_DIR=/usr/local/share - -DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane -DV_MAJOR=1 - -DV_MINOR=0 -O2 -pipe -march=prescott -fno-strict-aliasing -W -Wall -MT libcanon_dr_la-canon_dr.lo -MD -MP -MF .deps/libcanon_dr_la-canon_dr.Tpo - -c -o libcanon_dr_la-canon_dr.lo `test -f 'canon_dr.c' || echo './'`canon_dr.c canon_dr.c: In function 'sane_canon_dr_get_option_descriptor': canon_dr.c:1333: error: 'SANE_NAME_STANDARD' undeclared (first use in this function) canon_dr.c:1333: error: (Each undeclared identifier is reported only once canon_dr.c:1333: error: for each function it appears in.) canon_dr.c:1334: error: 'SANE_TITLE_STANDARD' undeclared (first use in this function) canon_dr.c:1335: error: 'SANE_DESC_STANDARD' undeclared (first use in this function) canon_dr.c:1545: error: 'SANE_NAME_GEOMETRY' undeclared (first use in this function) canon_dr.c:1546: error: 'SANE_TITLE_GEOMETRY' undeclared (first use in this function) canon_dr.c:1547: error: 'SANE_DESC_GEOMETRY' undeclared (first use in this function) canon_dr.c:1632: error: 'SANE_NAME_PAGE_WIDTH' undeclared (first use in this function) canon_dr.c:1633: error: 'SANE_TITLE_PAGE_WIDTH' undeclared (first use in this function) canon_dr.c:1634: error: 'SANE_DESC_PAGE_WIDTH' undeclared (first use in this function) canon_dr.c:1659: error: 'SANE_NAME_PAGE_HEIGHT' undeclared (first use in this function) canon_dr.c:1660: error: 'SANE_TITLE_PAGE_HEIGHT' undeclared (first use in this function) canon_dr.c:1661: error: 'SANE_DESC_PAGE_HEIGHT' undeclared (first use in this function) canon_dr.c:1680: error: 'SANE_NAME_ENHANCEMENT' undeclared (first use in this function) canon_dr.c:1681: error: 'SANE_TITLE_ENHANCEMENT' undeclared (first use in this function) canon_dr.c:1682: error: 'SANE_DESC_ENHANCEMENT' undeclared (first use in this function) canon_dr.c:1771: error: 'SANE_NAME_ADVANCED' undeclared (first use in this function) canon_dr.c:1772: error: 'SANE_TITLE_ADVANCED' undeclared (first use in this function) canon_dr.c:1773: error: 'SANE_DESC_ADVANCED' undeclared (first use in this function) canon_dr.c:1958: error: 'SANE_NAME_SENSORS' undeclared (first use in this function) canon_dr.c:1959: error: 'SANE_TITLE_SENSORS' undeclared (first use in this function) canon_dr.c:1960: error: 'SANE_DESC_SENSORS' undeclared (first use in this function) gmake[2]: *** [libcanon_dr_la-canon_dr.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/sane-backends/work/sane-backends-1.0.20/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/sane-backends/work/sane-backends-1.0.20/backend' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/graphics/sane-backends. *** Error code 1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoZmRUACgkQQv9rrgRC1JIdJQCgj/2f5rg9uho+s6Y/vwHq0Lzd fLwAn1zmaWVYaQZTjQrTCFttKT5fpCM+ =59fG -END PGP SIGNATURE- ___ 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: Make package-recursive problem
On Sun, 24.05.2009 at 14:11:26 -0400, Matt Juszczak wrote: I have no clue as to what is causing this, but this is probably the reason why people use the tinderbox or roll their own system to build consistent packages. I feel like I am though? I have a dedicated box just for building packages. make package creates a tbz file of all packages, and is supposed to be reliable. It should be under the following circumstances: - You don't update /usr/ports - You don't change /etc/make.conf - You don't deinstall packages Another approach had even the package dependency inside a Makefile, so rebuilding the gettext package would trigger all dependent packages to get rebuilt too (I haven't tackled the problem of *reinstalling* them on the target hosts, though) Doesn't this already occur with the default tools in the port system? No, installed packages will be updated only (by portmaster or portupgrade) if their PKGVERSION changes. To force the update when a new gettext hits the tree, we have these !...@$!#% awful PORTREVISION bumps across a gazillion ports. I chose a bad example. Consider Perl was upgraded from 5.8.8 to 5.8.9, so the target perl.tbz changes mtime (at least), then make(1) would rebuild every port/package that depended on the Perl package. That was what my special Makefile was doing. Plus, you get nice Graphviz input, but a 20,000 node graph is useless to print. Extracting subgraphs for, eg. OpenOffice was nice, though. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ 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: Make package-recursive problem
It should be under the following circumstances: - You don't update /usr/ports I haven't. - You don't change /etc/make.conf I haven't. - You don't deinstall packages I haven't. =) The bug I'm describing would make sense if SOMETHING changed. But I haven't changed a thing. ___ 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: MAKE_JOBS_UNSAFE (some more ports)
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-3openoffice.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-3openoffice.org-3.1.048:51 The build is done in /dev/md0 on /usr/local/tinderbox/7-STABLE-FPT-NPD (ufs, asynchronous, local, noatime) -- 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: PGP signature
Re: [Call For Testing] VirtualBox for FreeBSD! take 3
2009/5/24 Norikatsu Shigemura n...@freebsd.org: Hi Martin. On Fri, 22 May 2009 19:59:57 +0200 Martin Wilke m...@freebsd.org wrote: We rolled a new version with a fix for all users where has problems with kernel load and unload. Many thanks to Shin-ichi Okano where submitted this patch to the vbox ml. http://people.freebsd.org/~miwi/vbox/virtualbox_4.tgz I tried to support NLS. Please see also my patch. BTW, In my environment, VBoxREM32.so and VBoxREM64.so was not installed. Do you know why? Same here (amd64). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- Makefile.orig 2009-05-23 01:59:37.0 +0900 +++ Makefile 2009-05-25 05:11:37.046564727 +0900 @@ -128,6 +128,9 @@ ${MKDIR} ${PREFIX}/lib/virtualbox (cd ${WRKSRC}/out/${KMK_ARCH}/release/bin ${COPYTREE_SHARE} *.so *.gc *.r0 components ${PREFIX}/lib/virtualbox) + ${MKDIR} ${PREFIX}/lib/virtualbox/nls + (cd ${WRKSRC}/out/${KMK_ARCH}/release/obj/VirtualBox/qtnls ${COPYTREE_SHARE} *.qm ${PREFIX}/lib/virtualbox/nls) + ${MKDIR} ${PREFIX}/bin .for f in VBoxBFE VBoxHeadless VBoxManage VBoxNetDHCP VBoxSDL VBoxSVC VBoxXPCOMIPCD VirtualBox ${INSTALL_PROGRAM} ${WRKSRC}/out/${KMK_ARCH}/release/bin/$f ${PREFIX}/lib/virtualbox/ --- pkg-plist.orig 2009-05-08 03:59:50.0 +0900 +++ pkg-plist 2009-05-25 05:11:25.684009015 +0900 @@ -21,8 +21,6 @@ lib/virtualbox/VBoxNetDHCP.so lib/virtualbox/VBoxPython.so lib/virtualbox/VBoxREM.so -lib/virtualbox/VBoxREM32.so -lib/virtualbox/VBoxREM64.so lib/virtualbox/VBoxRT.so lib/virtualbox/VBoxSDL lib/virtualbox/VBoxSDL.so @@ -47,6 +45,63 @@ lib/virtualbox/components/VBoxSVCM.so lib/virtualbox/components/VBoxC.so lib/virtualbox/components/VBoxXPCOMBase.xpt +lib/virtualbox/nls/VirtualBox_ar.qm +lib/virtualbox/nls/VirtualBox_bg.qm +lib/virtualbox/nls/VirtualBox_ca.qm +lib/virtualbox/nls/VirtualBox_cs.qm +lib/virtualbox/nls/VirtualBox_de.qm +lib/virtualbox/nls/VirtualBox_el.qm +lib/virtualbox/nls/VirtualBox_es.qm +lib/virtualbox/nls/VirtualBox_eu.qm +lib/virtualbox/nls/VirtualBox_fi.qm +lib/virtualbox/nls/VirtualBox_fr.qm +lib/virtualbox/nls/VirtualBox_hu.qm +lib/virtualbox/nls/VirtualBox_id.qm +lib/virtualbox/nls/VirtualBox_it.qm +lib/virtualbox/nls/VirtualBox_ja.qm +lib/virtualbox/nls/VirtualBox_km_KH.qm +lib/virtualbox/nls/VirtualBox_ko.qm +lib/virtualbox/nls/VirtualBox_nl.qm +lib/virtualbox/nls/VirtualBox_pl.qm +lib/virtualbox/nls/VirtualBox_pt.qm +lib/virtualbox/nls/VirtualBox_pt_BR.qm +lib/virtualbox/nls/VirtualBox_ro.qm +lib/virtualbox/nls/VirtualBox_ru.qm +lib/virtualbox/nls/VirtualBox_sk.qm +lib/virtualbox/nls/VirtualBox_sr.qm +lib/virtualbox/nls/VirtualBox_sv.qm +lib/virtualbox/nls/VirtualBox_tr.qm +lib/virtualbox/nls/VirtualBox_zh_CN.qm +lib/virtualbox/nls/VirtualBox_zh_TW.qm +lib/virtualbox/nls/qt_ar.qm +lib/virtualbox/nls/qt_bg.qm +lib/virtualbox/nls/qt_ca.qm +lib/virtualbox/nls/qt_cs.qm +lib/virtualbox/nls/qt_de.qm +lib/virtualbox/nls/qt_el.qm +lib/virtualbox/nls/qt_es.qm +lib/virtualbox/nls/qt_eu.qm +lib/virtualbox/nls/qt_fi.qm +lib/virtualbox/nls/qt_fr.qm +lib/virtualbox/nls/qt_hu.qm +lib/virtualbox/nls/qt_id.qm +lib/virtualbox/nls/qt_it.qm +lib/virtualbox/nls/qt_ja.qm +lib/virtualbox/nls/qt_km_KH.qm +lib/virtualbox/nls/qt_ko.qm +lib/virtualbox/nls/qt_nl.qm +lib/virtualbox/nls/qt_pl.qm +lib/virtualbox/nls/qt_pt.qm +lib/virtualbox/nls/qt_pt_BR.qm +lib/virtualbox/nls/qt_ro.qm +lib/virtualbox/nls/qt_ru.qm +lib/virtualbox/nls/qt_sk.qm +lib/virtualbox/nls/qt_sr.qm +lib/virtualbox/nls/qt_sv.qm +lib/virtualbox/nls/qt_tr.qm +lib/virtualbox/nls/qt_zh_CN.qm +lib/virtualbox/nls/qt_zh_TW.qm +...@dirrm lib/virtualbox/nls �...@dirrm lib/virtualbox/components �...@dirrm lib/virtualbox �...@cwd / - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ 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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: graphics/sane-backends compilation still broken
On 25/05/2009, at 4:59 AM, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As follows, with either portmaster or portupgrade: /bin/sh ../libtool --silent --tag=CC --mode=compile cc - DHAVE_CONFIG_H - -I../include/sane -I. -I/usr/local/include -I. -I. -I../include - -I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=canon_dr - -I/usr/local/include -D_REENTRANT - -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d - -DPATH_SANE_DATA_DIR=/usr/local/share - -DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane -DV_MAJOR=1 - -DV_MINOR=0 -O2 -pipe -march=prescott -fno-strict-aliasing -W - Wall -MT libcanon_dr_la-canon_dr.lo -MD -MP -MF .deps/libcanon_dr_la- canon_dr.Tpo - -c -o libcanon_dr_la-canon_dr.lo `test -f 'canon_dr.c' || echo './'`canon_dr.c canon_dr.c: In function 'sane_canon_dr_get_option_descriptor': canon_dr.c:1333: error: 'SANE_NAME_STANDARD' undeclared (first use in this function) canon_dr.c:1333: error: (Each undeclared identifier is reported only once canon_dr.c:1333: error: for each function it appears in.) canon_dr.c:1334: error: 'SANE_TITLE_STANDARD' undeclared (first use in this function) canon_dr.c:1335: error: 'SANE_DESC_STANDARD' undeclared (first use in this function) canon_dr.c:1545: error: 'SANE_NAME_GEOMETRY' undeclared (first use in this function) canon_dr.c:1546: error: 'SANE_TITLE_GEOMETRY' undeclared (first use in this function) canon_dr.c:1547: error: 'SANE_DESC_GEOMETRY' undeclared (first use in this function) canon_dr.c:1632: error: 'SANE_NAME_PAGE_WIDTH' undeclared (first use in this function) canon_dr.c:1633: error: 'SANE_TITLE_PAGE_WIDTH' undeclared (first use in this function) canon_dr.c:1634: error: 'SANE_DESC_PAGE_WIDTH' undeclared (first use in this function) canon_dr.c:1659: error: 'SANE_NAME_PAGE_HEIGHT' undeclared (first use in this function) canon_dr.c:1660: error: 'SANE_TITLE_PAGE_HEIGHT' undeclared (first use in this function) canon_dr.c:1661: error: 'SANE_DESC_PAGE_HEIGHT' undeclared (first use in this function) canon_dr.c:1680: error: 'SANE_NAME_ENHANCEMENT' undeclared (first use in this function) canon_dr.c:1681: error: 'SANE_TITLE_ENHANCEMENT' undeclared (first use in this function) canon_dr.c:1682: error: 'SANE_DESC_ENHANCEMENT' undeclared (first use in this function) canon_dr.c:1771: error: 'SANE_NAME_ADVANCED' undeclared (first use in this function) canon_dr.c:1772: error: 'SANE_TITLE_ADVANCED' undeclared (first use in this function) canon_dr.c:1773: error: 'SANE_DESC_ADVANCED' undeclared (first use in this function) canon_dr.c:1958: error: 'SANE_NAME_SENSORS' undeclared (first use in this function) canon_dr.c:1959: error: 'SANE_TITLE_SENSORS' undeclared (first use in this function) canon_dr.c:1960: error: 'SANE_DESC_SENSORS' undeclared (first use in this function) gmake[2]: *** [libcanon_dr_la-canon_dr.lo] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/sane-backends/work/sane-backends-1.0.20/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/graphics/sane-backends/work/sane-backends-1.0.20/backend' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/graphics/sane-backends. *** Error code 1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoZmRUACgkQQv9rrgRC1JIdJQCgj/2f5rg9uho+s6Y/vwHq0Lzd fLwAn1zmaWVYaQZTjQrTCFttKT5fpCM+ =59fG -END PGP SIGNATURE- ___ 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 Exact same problem here at same place in the process! Raised a PR but... --- From: m...@freebsd.org Subject:Re: ports/134890: graphics/sane-backends port fails to build Date: 24 May 2009 7:46:41 PM To: tme...@optusnet.com.au, m...@freebsd.org, m...@freebsd.org Synopsis: graphics/sane-backends port fails to build State-Changed-From-To: open-closed State-Changed-By: miwi State-Changed-When: Sun May 24 09:46:41 UTC 2009 State-Changed-Why: a patch was committed please update your portstree. http://www.freebsd.org/cgi/query-pr.cgi?pr=134890 - ...so I guess I must be an idiot... Have now used both portsnap fetch extract and portsnap fetch update to no avail as the port fails in the same place each time. Do I have to go back to using CVSup to update the ports tree? That would be going backwards in my view! Cheers, Tom ___ 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: graphics/sane-backends compilation still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Mende wrote: On 25/05/2009, at 4:59 AM, Michael Butler wrote: As follows, with either portmaster or portupgrade: /bin/sh ../libtool --silent --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I../include/sane -I. -I/usr/local/include -I. -I. -I../include -I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=canon_dr -I/usr/local/include -D_REENTRANT -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/local/share -DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane -DV_MAJOR=1 -DV_MINOR=0 -O2 -pipe -march=prescott -fno-strict-aliasing -W -Wall -MT libcanon_dr_la-canon_dr.lo -MD -MP -MF .deps/libcanon_dr_la-canon_dr.Tpo -c -o libcanon_dr_la-canon_dr.lo `test -f 'canon_dr.c' || echo './'`canon_dr.c canon_dr.c: In function 'sane_canon_dr_get_option_descriptor': [ .. ] canon_dr.c:1333: error: 'SANE_NAME_STANDARD' undeclared (first use in this function) Exact same problem here at same place in the process! Raised a PR but... [ .. ] Have now used both portsnap fetch extract and portsnap fetch update to no avail as the port fails in the same place each time. Do I have to go back to using CVSup to update the ports tree? That would be going backwards in my view! The solution is to move the /usr/local/include/sane directory from the previous installation to one side and it will compile. Using the approach of .. cd /usr/ports/graphics/sane-backends make deinstall all reinstall clean .. would also probably work, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoZ+VwACgkQQv9rrgRC1JLRAACfX+ghh3JKkvPLtrzQWD+fTUW0 Xr8An0x6IqMy5naZcAtDNIfHaaS5Uhh7 =9Vsb -END PGP SIGNATURE- ___ 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: graphics/sane-backends compilation still broken
On 25/05/2009, at 11:50 AM, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Mende wrote: On 25/05/2009, at 4:59 AM, Michael Butler wrote: As follows, with either portmaster or portupgrade: /bin/sh ../libtool --silent --tag=CC --mode=compile cc - DHAVE_CONFIG_H -I../include/sane -I. -I/usr/local/include -I. -I. -I../include -I../include -DLIBDIR=/usr/local/lib/sane -DBACKEND_NAME=canon_dr -I/usr/local/include -D_REENTRANT -DPATH_SANE_CONFIG_DIR=/usr/local/etc/sane.d -DPATH_SANE_DATA_DIR=/usr/local/share -DPATH_SANE_LOCK_DIR=/usr/local/var/lock/sane -DV_MAJOR=1 -DV_MINOR=0 -O2 -pipe -march=prescott -fno-strict-aliasing -W -Wall -MT libcanon_dr_la-canon_dr.lo -MD -MP -MF .deps/libcanon_dr_la- canon_dr.Tpo -c -o libcanon_dr_la-canon_dr.lo `test -f 'canon_dr.c' || echo './'`canon_dr.c canon_dr.c: In function 'sane_canon_dr_get_option_descriptor': [ .. ] canon_dr.c:1333: error: 'SANE_NAME_STANDARD' undeclared (first use in this function) Exact same problem here at same place in the process! Raised a PR but... [ .. ] Have now used both portsnap fetch extract and portsnap fetch update to no avail as the port fails in the same place each time. Do I have to go back to using CVSup to update the ports tree? That would be going backwards in my view! The solution is to move the /usr/local/include/sane directory from the previous installation to one side and it will compile. Using the approach of .. cd /usr/ports/graphics/sane-backends make deinstall all reinstall clean .. would also probably work, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkoZ+VwACgkQQv9rrgRC1JLRAACfX+ghh3JKkvPLtrzQWD+fTUW0 Xr8An0x6IqMy5naZcAtDNIfHaaS5Uhh7 =9Vsb -END PGP SIGNATURE- ___ 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 Thanks Michael; Tried deinstall and reinstall approach - it works - but portupgrade definitely fails! Cheers, Tom ___ 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