Re: ports/141131: www/libxul does not compile any more
On Tue, 22 Dec 2009 11:46:06 + Anton Shterenlikht wrote: >On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote: >> On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote: >> > On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote: >> >> According to PR 141131 I see exactly the same error messages when I try >> >> to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16: >> >> >> >> --- >> >> [..snip..] >> >> cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi >> >> -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX >> >> -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" >> >> -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG >> >> -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC >> >> -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include >> >> -I/usr/local/include/nspr >> >> -I/usr/ports/www/libxul/work/mozilla/dist/include >> >> -I../../../../dist/public/nss -I../../../../dist/private/nss >> >> -I../../../../dist/include -Impi -Iecl dsa.c >> >> dsa.c: In function 'FIPS186Change_ReduceModQForDSA': >> >> dsa.c:75: error: 'mp_int' undeclared (first use in this function) >> >> dsa.c:75: error: (Each undeclared identifier is reported only once >> >> dsa.c:75: error: for each function it appears in.) >> >> dsa.c:75: error: expected ';' before 'W' >> >> dsa.c:76: error: 'mp_err' undeclared (first use in this function) >> >> dsa.c:76: error: expected ';' before 'err' >> >> [..snip..] >> >> gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] Fehler 1 >> >> gmake[6]: Leaving directory >> >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' >> >> gmake[5]: *** [libs] Fehler 2 >> >> gmake[5]: Leaving directory >> >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' >> >> gmake[4]: *** [libs] Fehler 2 >> >> gmake[4]: Leaving directory >> >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib' >> >> gmake[3]: *** [libs] Fehler 2 >> >> gmake[3]: Leaving directory >> >> `/usr/ports/www/libxul/work/mozilla/security/manager' >> >> gmake[2]: *** [libs_tier_toolkit] Fehler 2 >> >> gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla' >> >> gmake[1]: *** [tier_toolkit] Fehler 2 >> >> gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla' >> >> gmake: *** [default] Fehler 2 >> >> *** Error code 1 >> >> --- >> >> >> >> This happens on three different machines all running latest 9.0-CURRENT >> >> (i386). As far as I can see there are no relevant flags set in >> >> etc/make.conf. >> >> >> >> Any clues what is going wrong? I found no solution to this PR. >> >> >> >> Please let me know if I can provide more information or test something. >> > >> > I've got libxul-1.9.0.16 built fine on ia64 and sparc64. >> > No issues, just 'portmaster -force-config -Bd libxul'. >> > >> >> Thanks for answering. >> >> As I wrote before, I have this on different machines, all running newest >> i386-CURRENT. On another machine with amd64-CURRENT I had been able to >> compile libxul-1.9.0.16. Perhaps there is something wrong with my >> configuration? (I copied most from system to system ...) > ># uname -srm >FreeBSD 9.0-CURRENT i386 ># pkg_info -xo libxul >Information for libxul-1.9.0.16: > >Origin: >www/libxul > ># cd /usr/ports/www/libxul ># make showconfig >===> The following configuration options are available for libxul-1.9.0.16: > JAVA=off "Enable JAVA xpcom" > DEBUG=off "Build a debugging image" > LOGGING=off "Enable additional log messages" > OPTIMIZED_CFLAGS=off "Enable some additional optimizations" >===> Use 'make config' to modify these settings ># > >Have you checked /etc/make.conf, /etc/src.conf? > I doubt that either of those has anything to do with the problem. An update for libxul came through in the last two to four days that broke it. It halted my "portmaster -a" run, so I've added -x libxul to the command for now until another update for it comes through. For now, though, it's broken on 7.2-STABLE as well as on Rainer's system. FWIW, there have been other bad updates recently, too, although many have been fixed by subsequent updates within a few days. A bad pair of updates came through a couple of days ago: print/gutenprint and print/gimp-gutenprint. These have yet to be fixed. multimedia/gstreamer-plugins-dvd was broken by an update a while back, three or four months, I think. It remains unfixed today. Note that these problems are not execution or functional problems in the code, but rather problems that prevent the port from completing the updating process all the way through installation. This sort of problem is not a daily thing by any means, so it seems like most of the maintainers know what they're about, for which we can all be grateful. But it does seem to happen a few times per month, which suggests that at least a few maintainers don't or perhaps
Re: ports/141131: www/libxul does not compile any more
Scott Bennett wrote: > On Tue, 22 Dec 2009 11:46:06 + Anton Shterenlikht > wrote: >> On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote: >>> On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote: On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote: > According to PR 141131 I see exactly the same error messages when I try > to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16: > > --- > [..snip..] > cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi > -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX > -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" > -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG > -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC > -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include > -I/usr/local/include/nspr > -I/usr/ports/www/libxul/work/mozilla/dist/include > -I../../../../dist/public/nss -I../../../../dist/private/nss > -I../../../../dist/include -Impi -Iecl dsa.c > dsa.c: In function 'FIPS186Change_ReduceModQForDSA': > dsa.c:75: error: 'mp_int' undeclared (first use in this function) > dsa.c:75: error: (Each undeclared identifier is reported only once > dsa.c:75: error: for each function it appears in.) > dsa.c:75: error: expected ';' before 'W' > dsa.c:76: error: 'mp_err' undeclared (first use in this function) > dsa.c:76: error: expected ';' before 'err' > [..snip..] > gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] Fehler 1 > gmake[6]: Leaving directory > `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' > gmake[5]: *** [libs] Fehler 2 > gmake[5]: Leaving directory > `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' > gmake[4]: *** [libs] Fehler 2 > gmake[4]: Leaving directory > `/usr/ports/www/libxul/work/mozilla/security/nss/lib' > gmake[3]: *** [libs] Fehler 2 > gmake[3]: Leaving directory > `/usr/ports/www/libxul/work/mozilla/security/manager' > gmake[2]: *** [libs_tier_toolkit] Fehler 2 > gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla' > gmake[1]: *** [tier_toolkit] Fehler 2 > gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla' > gmake: *** [default] Fehler 2 > *** Error code 1 > --- > > This happens on three different machines all running latest 9.0-CURRENT > (i386). As far as I can see there are no relevant flags set in > etc/make.conf. > > Any clues what is going wrong? I found no solution to this PR. > > Please let me know if I can provide more information or test something. I've got libxul-1.9.0.16 built fine on ia64 and sparc64. No issues, just 'portmaster -force-config -Bd libxul'. >>> Thanks for answering. >>> >>> As I wrote before, I have this on different machines, all running newest >>> i386-CURRENT. On another machine with amd64-CURRENT I had been able to >>> compile libxul-1.9.0.16. Perhaps there is something wrong with my >>> configuration? (I copied most from system to system ...) >> # uname -srm >> FreeBSD 9.0-CURRENT i386 >> # pkg_info -xo libxul >> Information for libxul-1.9.0.16: >> >> Origin: >> www/libxul >> >> # cd /usr/ports/www/libxul >> # make showconfig >> ===> The following configuration options are available for libxul-1.9.0.16: >> JAVA=off "Enable JAVA xpcom" >> DEBUG=off "Build a debugging image" >> LOGGING=off "Enable additional log messages" >> OPTIMIZED_CFLAGS=off "Enable some additional optimizations" >> ===> Use 'make config' to modify these settings >> # >> >> Have you checked /etc/make.conf, /etc/src.conf? >> > I doubt that either of those has anything to do with the problem. An > update for libxul came through in the last two to four days that broke it. > It halted my "portmaster -a" run, so I've added -x libxul to the command for > now until another update for it comes through. For now, though, it's broken > on 7.2-STABLE as well as on Rainer's system. > FWIW, there have been other bad updates recently, too, although many > have been fixed by subsequent updates within a few days. A bad pair of > updates came through a couple of days ago: print/gutenprint and > print/gimp-gutenprint. These have yet to be fixed. > multimedia/gstreamer-plugins-dvd was broken by an update a while back, > three or four months, I think. It remains unfixed today. > Note that these problems are not execution or functional problems in > the code, but rather problems that prevent the port from completing the > updating process all the way through installation. This sort of problem is > not a daily thing by any means, so it seems like most of the maintainers know > what they're about, for which we can all be grateful. But it does seem to > happe
Re: Ports marked as IGNORE - (cups-pdf) & (urlview) why - how long?
> > > Looks like all the PR's were not in place before the test was run on > > > pointyhat. > > > > pointyhat doesn't have anything to do with PRs. It runs based on what > > is checked into CVS when its runs start. How would it be able to do > > otherwise? The ports PR count is currently 998. How is a computer > > program going to know which ones are relevant or correct? > > > > > I deduced from the information on my system that the error was more > > > likely due to a false positive for failure by the testing procedure > > > rather than due to an inherent failure in the code. > > > > build error != install error. If you look at the two error logs, you'll > > see that those are install errors (files required to be installed not > > installed; files required to be deinstalled not being deinstalled). > > > > Ports that do not allow a clean install/deinstall cycle are broken, > > whether they compile or not. > > > > mcl > > Yes I agree BUT it is suggested that the reason that there was not a clean > install/deinstall cycle was because the pointyhat test may have been done > without the benefit of PR ports 141375. Here is Mathew Seaman's take on it: > > "Looks like the problem would have been fixed in PR ports/141375, which > modified > the cups-base port to create the directory in question. As that fix was > applied > on the 12th at 19:39 and the last pointyhat test on cups-pdf appears to > have been > on the same day at 20:57 I reckon pointyhat just missed getting the fix for > at least one of its test cases by about >< that much." > > What we need now is another test on pointyhat to see whether his > speculation is accurate. It seems highly probable to me. > > Time will tell > > David > ___ Well that was it! Compiles and installs when the Makefile is amended. So the pointy hat run must have started before the fix was applied even though the test was done after. I suppose the only thing that could prevent similar "false positives for failure" would be for the pointy hat test cycle to include a second check on failures after the run ends to pick up any fixes which had been applied between the start of the run and any individual test. However this is probably such a rare occurence that the effort to amend the procedure may not be justified. It is a useful reminder that pointyhat failures can, under such restricted circumstances, be misleading. Mind you I would prefer a few extra "false failures" than one "false passes"!! David ___ 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"
installing java
Today I had the pleasure to install some java port and well it was quite frustrating. I still have to download all the distfiles manually. Isn't FreeBSD now officially supported by Sun? Is it really still necessary to manually fetch the distfiles or is this something that could be looked at again? Theoretically: What if the port would just point to the distfiles and don't actually host them on any FreeBSD mirror. Wouldn't that be legal? I mean a link some site that provides instruction on how to build an atomic bomb is still legal as well, right? If so I could simply upload the distfiles to some russian FTP server and nobody but Sun would really care. This is so annyoing: - Manually fetch - Login to some bloated sun.com site ARGHH!!! Sandra ___ 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: ports/141131: www/libxul does not compile any more
On 24.12.2009 09:46 (UTC+1), Scott Bennett wrote: On Tue, 22 Dec 2009 11:46:06 + Anton Shterenlikht wrote: On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote: On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote: On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote: According to PR 141131 I see exactly the same error messages when I try to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16: --- [..snip..] cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include -I/usr/local/include/nspr -I/usr/ports/www/libxul/work/mozilla/dist/include -I../../../../dist/public/nss -I../../../../dist/private/nss -I../../../../dist/include -Impi -Iecl dsa.c dsa.c: In function 'FIPS186Change_ReduceModQForDSA': dsa.c:75: error: 'mp_int' undeclared (first use in this function) dsa.c:75: error: (Each undeclared identifier is reported only once dsa.c:75: error: for each function it appears in.) dsa.c:75: error: expected ';' before 'W' dsa.c:76: error: 'mp_err' undeclared (first use in this function) dsa.c:76: error: expected ';' before 'err' [..snip..] gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] Fehler 1 gmake[6]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' gmake[5]: *** [libs] Fehler 2 gmake[5]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' gmake[4]: *** [libs] Fehler 2 gmake[4]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/nss/lib' gmake[3]: *** [libs] Fehler 2 gmake[3]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/manager' gmake[2]: *** [libs_tier_toolkit] Fehler 2 gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla' gmake[1]: *** [tier_toolkit] Fehler 2 gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla' gmake: *** [default] Fehler 2 *** Error code 1 --- This happens on three different machines all running latest 9.0-CURRENT (i386). As far as I can see there are no relevant flags set in etc/make.conf. Any clues what is going wrong? I found no solution to this PR. Please let me know if I can provide more information or test something. I've got libxul-1.9.0.16 built fine on ia64 and sparc64. No issues, just 'portmaster -force-config -Bd libxul'. Thanks for answering. As I wrote before, I have this on different machines, all running newest i386-CURRENT. On another machine with amd64-CURRENT I had been able to compile libxul-1.9.0.16. Perhaps there is something wrong with my configuration? (I copied most from system to system ...) # uname -srm FreeBSD 9.0-CURRENT i386 # pkg_info -xo libxul Information for libxul-1.9.0.16: Origin: www/libxul # cd /usr/ports/www/libxul # make showconfig ===> The following configuration options are available for libxul-1.9.0.16: JAVA=off "Enable JAVA xpcom" DEBUG=off "Build a debugging image" LOGGING=off "Enable additional log messages" OPTIMIZED_CFLAGS=off "Enable some additional optimizations" ===> Use 'make config' to modify these settings # Have you checked /etc/make.conf, /etc/src.conf? I doubt that either of those has anything to do with the problem. An update for libxul came through in the last two to four days that broke it. It halted my "portmaster -a" run, so I've added -x libxul to the command for now until another update for it comes through. For now, though, it's broken on 7.2-STABLE as well as on Rainer's system. FWIW, there have been other bad updates recently, too, although many have been fixed by subsequent updates within a few days. A bad pair of updates came through a couple of days ago: print/gutenprint and print/gimp-gutenprint. These have yet to be fixed. multimedia/gstreamer-plugins-dvd was broken by an update a while back, three or four months, I think. It remains unfixed today. Note that these problems are not execution or functional problems in the code, but rather problems that prevent the port from completing the updating process all the way through installation. This sort of problem is not a daily thing by any means, so it seems like most of the maintainers know what they're about, for which we can all be grateful. But it does seem to happen a few times per month, which suggests that at least a few maintainers don't or perhaps may lose track of a testing step or two when under pressure. (And there certainly is a *lot* of ports to maintain!) Unfortunately this error with libxul arises only on my i386 systems. On my amd64 systems (9.0-CURRENT) with allmost the same configuration and installed ports libxul builds fine.
Re: installing java
On Thu, Dec 24, 2009 at 9:04 AM, Sandra Kachelmann wrote: > Today I had the pleasure to install some java port and well it was > quite frustrating. I still have to download all the distfiles > manually. Isn't FreeBSD now officially supported by Sun? No, Sun does not officially support FreeBSD. The official Java port for FreeBSD is provided by the FreeBSD foundation. Take a look at http://www.freebsdfoundation.org/downloads/java.shtml and the corresponding ports: /usr/ports/java/diablo-jdk15 /usr/ports/java/diablo-jdk16 /usr/ports/java/diablo-jre15 /usr/ports/java/diablo-jre16 > Is it really > still necessary to manually fetch the distfiles or is this something > that could be looked at again? Yes, if you want to build it from the sources. This limitation is imposed by the Java license to which FreeBSD must be compliant. > What if the port would just point to the distfiles and don't actually > host them on any FreeBSD mirror. Wouldn't that be legal? The ports already points you to the distfiles but the license terms require explicit acceptance by the user before downloading the files. > I mean a link > some site that provides instruction on how to build an atomic bomb is > still legal as well, right? It would depend on the license terms of the atomic bomb. :-) > If so I could simply upload the distfiles > to some russian FTP server and nobody but Sun would really care. You can upload them to some FTP server in *any* country. It would not be legal, anyway. The FreeBSD project is not whiling to be sued by Sun. And yes, they *do* care. > This is so annyoing: > > - Manually fetch > - Login to some bloated sun.com site > > ARGHH!!! Send your complaints, politely, to Sun. FreeBSD is just another victim in this case. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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: installing java
On Thu, Dec 24, 2009 at 12:04:22PM +0100, Sandra Kachelmann wrote:
> Today I had the pleasure to install some java port and well it was
> quite frustrating. I still have to download all the distfiles
> manually. Isn't FreeBSD now officially supported by Sun? Is it really
> still necessary to manually fetch the distfiles or is this something
> that could be looked at again?
>
> Theoretically:
>
> What if the port would just point to the distfiles and don't actually
> host them on any FreeBSD mirror. Wouldn't that be legal? I mean a link
> some site that provides instruction on how to build an atomic bomb is
> still legal as well, right? If so I could simply upload the distfiles
> to some russian FTP server and nobody but Sun would really care.
>
> This is so annyoing:
>
> - Manually fetch
> - Login to some bloated sun.com site
>
> ARGHH!!!
>
>
>
> Sandra
Why not just use diablo-{jdk,jre}-* then?
Yuri
___
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: ports/141131: www/libxul does not compile any more
Rainer Hurling wrote: > On 24.12.2009 09:46 (UTC+1), Scott Bennett wrote: >> On Tue, 22 Dec 2009 11:46:06 + Anton Shterenlikht >> wrote: >>> On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote: On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote: > On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote: >> According to PR 141131 I see exactly the same error messages when >> I try >> to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16: >> >> --- >> [..snip..] >> cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi >> -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK >> -DXP_UNIX >> -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" >> -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG >> -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC >> -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include >> -I/usr/local/include/nspr >> -I/usr/ports/www/libxul/work/mozilla/dist/include >> -I../../../../dist/public/nss -I../../../../dist/private/nss >> -I../../../../dist/include -Impi -Iecl dsa.c >> dsa.c: In function 'FIPS186Change_ReduceModQForDSA': >> dsa.c:75: error: 'mp_int' undeclared (first use in this function) >> dsa.c:75: error: (Each undeclared identifier is reported only once >> dsa.c:75: error: for each function it appears in.) >> dsa.c:75: error: expected ';' before 'W' >> dsa.c:76: error: 'mp_err' undeclared (first use in this function) >> dsa.c:76: error: expected ';' before 'err' >> [..snip..] >> gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] >> Fehler 1 >> gmake[6]: Leaving directory >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' >> gmake[5]: *** [libs] Fehler 2 >> gmake[5]: Leaving directory >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' >> gmake[4]: *** [libs] Fehler 2 >> gmake[4]: Leaving directory >> `/usr/ports/www/libxul/work/mozilla/security/nss/lib' >> gmake[3]: *** [libs] Fehler 2 >> gmake[3]: Leaving directory >> `/usr/ports/www/libxul/work/mozilla/security/manager' >> gmake[2]: *** [libs_tier_toolkit] Fehler 2 >> gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla' >> gmake[1]: *** [tier_toolkit] Fehler 2 >> gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla' >> gmake: *** [default] Fehler 2 >> *** Error code 1 >> --- >> >> This happens on three different machines all running latest >> 9.0-CURRENT >> (i386). As far as I can see there are no relevant flags set in >> etc/make.conf. >> >> Any clues what is going wrong? I found no solution to this PR. >> >> Please let me know if I can provide more information or test >> something. > > I've got libxul-1.9.0.16 built fine on ia64 and sparc64. > No issues, just 'portmaster -force-config -Bd libxul'. > Thanks for answering. As I wrote before, I have this on different machines, all running newest i386-CURRENT. On another machine with amd64-CURRENT I had been able to compile libxul-1.9.0.16. Perhaps there is something wrong with my configuration? (I copied most from system to system ...) >>> >>> # uname -srm >>> FreeBSD 9.0-CURRENT i386 >>> # pkg_info -xo libxul >>> Information for libxul-1.9.0.16: >>> >>> Origin: >>> www/libxul >>> >>> # cd /usr/ports/www/libxul >>> # make showconfig >>> ===> The following configuration options are available for >>> libxul-1.9.0.16: >>> JAVA=off "Enable JAVA xpcom" >>> DEBUG=off "Build a debugging image" >>> LOGGING=off "Enable additional log messages" >>> OPTIMIZED_CFLAGS=off "Enable some additional optimizations" >>> ===> Use 'make config' to modify these settings >>> # > Unfortunately this error with libxul arises only on my i386 systems. On > my amd64 systems (9.0-CURRENT) with allmost the same configuration and > installed ports libxul builds fine. It seems to be a question of > configuration or composition of other, already installed ports. According to the pr this problem also occur on 8.0-STABLE/amd64. Could you please send me (or upload it somewhere) the output of pkg_info from the system where the build fails and from the system where the build was successful. Thanks, Beat ___ 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: New version of the fakeroot patch
On Thursday 24 December 2009 06:43:02 Ulrich Spörlein wrote:
> On Tue, 15.12.2009 at 10:00:18 +0100, Tijl Coosemans wrote:
>> On Tuesday 15 December 2009 09:10:47 Matthew Seaman wrote:
>>> Uh -- is it actually possible to create an empty directory when
>>> installing from a pkg tarball?
>>>
>>> I ran into this problem with the phpMyAdmin port, and the only good
>>> way I found to solve it was to add a stub file into any empty
>>> directories. You could use a post install script or an mtree file,
>>> but that seems like overkill for such a trivial operation.
>>
>> If you want to create ${PREFIX}/somedir you can add this line
>> to pkg-plist:
>>
>> @exec mkdir -p %D/somedir
>
> ... and then you still need to chmod/chown to fix permissions. I
> wonder why that doesn't work with tar. Is that a limitation of the
> format, should we perhaps use cpio (with bsdtar, it would be
> transparent anyway).
Ownership and permissions are restored by tar. It's just that empty
directories aren't added to the archive by pkg_create.
Also, if you have to change ownership/permissions you should be careful
not to create any race conditions where too many permissions are given
to the wrong users. Removing permissions should happen before chown and
adding permissions should happen after chown.
___
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"
ruby gemcutter ports - how to handle fetching?
Hello, I recently submitted two ports with master site set to http://gemcutter.ogr/gems/ because rubyforge did not have the .gem files. The ruby community seems to be transitioning to gemcutter, so it would be good if gemcutter gems were easily maintained in ports. I suppose gemcutter should be added to bsd.sites.mk (see patch below), but the other problem is that I ended up adding to my port Makefile: # we care about not passing -A FETCH_ARGS= -pRr While this works it is not maintainable (what if fetch isn't used? what if other FETCH_ARGS overrides are in effect? etc). The problem is that the official location of gemcutter gem downloads return (correctly) 302 redirects - currently to Amazon S3. But the default FETCH_ARG:s contain -A, which means this is treated as a failure. I understand that many times a 302 is just some broken site and we do not want to follow it. The question is how this is supposed to be handled in a maintainable way? Suggestion: * Create FETCH_DISTFILE_REDIRECTS which, if yes, implies that when fetching redirects must be followed. * Define USE_GEMCUTTER=yes which would imply FETCH_DISTFILE_REDIRECTS (is a USE_* appropriate for this?). * Have bsd.port.mk add -A only if FETCH_DISTFILES_REDIRECTS is not yes. Thoughts? bsd.sites.mk patch for gemcutter follows (will probably be mangled by gmail). Should one add as a fall-back the current direct destination being used? In other words, although it is presumably an implementation detail of gemcutter, should one add, in this case, http://s3.amazonaws.com/gemcutter_production/gems/ to the master sites so that fetching has a high chance of working even if gemcutter is down (as long as S3 is up, which should be reliable)? --- bsd.sites.mk.orig 2009-12-24 13:53:17.958746367 +0100 +++ bsd.sites.mk2009-12-24 13:56:57.472840650 +0100 @@ -458,6 +458,11 @@ ftp://mirror.aarnet.edu.au/pub/gcc/%SUBDIR%/ .endif +.if !defined(IGNORE_MASTER_SITE_GEMCUTTER) +MASTER_SITE_GEMCUTTER+= \ + http://gemcutter.org/gems/ +.endif + .if !defined(IGNORE_MASTER_SITE_GENTOO) MASTER_SITE_GENTOO+= \ http://ftp.roedu.net/pub/mirrors/gentoo.org/%SUBDIR%/ \ -- / Peter Schuller ___ 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: ports/141131: www/libxul does not compile any more
Beat Gaetzi wrote: > Rainer Hurling wrote: >> On 24.12.2009 09:46 (UTC+1), Scott Bennett wrote: >>> On Tue, 22 Dec 2009 11:46:06 + Anton Shterenlikht >>> wrote: On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote: > On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote: >> On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote: >>> According to PR 141131 I see exactly the same error messages when >>> I try >>> to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16: >>> >>> --- >>> [..snip..] >>> cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi >>> -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK >>> -DXP_UNIX >>> -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" >>> -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG >>> -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC >>> -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include >>> -I/usr/local/include/nspr >>> -I/usr/ports/www/libxul/work/mozilla/dist/include >>> -I../../../../dist/public/nss -I../../../../dist/private/nss >>> -I../../../../dist/include -Impi -Iecl dsa.c >>> dsa.c: In function 'FIPS186Change_ReduceModQForDSA': >>> dsa.c:75: error: 'mp_int' undeclared (first use in this function) >>> dsa.c:75: error: (Each undeclared identifier is reported only once >>> dsa.c:75: error: for each function it appears in.) >>> dsa.c:75: error: expected ';' before 'W' >>> dsa.c:76: error: 'mp_err' undeclared (first use in this function) >>> dsa.c:76: error: expected ';' before 'err' >>> [..snip..] >>> gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] >>> Fehler 1 >>> gmake[6]: Leaving directory >>> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' >>> gmake[5]: *** [libs] Fehler 2 >>> gmake[5]: Leaving directory >>> `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' >>> gmake[4]: *** [libs] Fehler 2 >>> gmake[4]: Leaving directory >>> `/usr/ports/www/libxul/work/mozilla/security/nss/lib' >>> gmake[3]: *** [libs] Fehler 2 >>> gmake[3]: Leaving directory >>> `/usr/ports/www/libxul/work/mozilla/security/manager' >>> gmake[2]: *** [libs_tier_toolkit] Fehler 2 >>> gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla' >>> gmake[1]: *** [tier_toolkit] Fehler 2 >>> gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla' >>> gmake: *** [default] Fehler 2 >>> *** Error code 1 >>> --- >>> >>> This happens on three different machines all running latest >>> 9.0-CURRENT >>> (i386). As far as I can see there are no relevant flags set in >>> etc/make.conf. >>> >>> Any clues what is going wrong? I found no solution to this PR. >>> >>> Please let me know if I can provide more information or test >>> something. >> I've got libxul-1.9.0.16 built fine on ia64 and sparc64. >> No issues, just 'portmaster -force-config -Bd libxul'. >> > Thanks for answering. > > As I wrote before, I have this on different machines, all running > newest > i386-CURRENT. On another machine with amd64-CURRENT I had been able to > compile libxul-1.9.0.16. Perhaps there is something wrong with my > configuration? (I copied most from system to system ...) # uname -srm FreeBSD 9.0-CURRENT i386 # pkg_info -xo libxul Information for libxul-1.9.0.16: Origin: www/libxul # cd /usr/ports/www/libxul # make showconfig ===> The following configuration options are available for libxul-1.9.0.16: JAVA=off "Enable JAVA xpcom" DEBUG=off "Build a debugging image" LOGGING=off "Enable additional log messages" OPTIMIZED_CFLAGS=off "Enable some additional optimizations" ===> Use 'make config' to modify these settings # >> Unfortunately this error with libxul arises only on my i386 systems. On >> my amd64 systems (9.0-CURRENT) with allmost the same configuration and >> installed ports libxul builds fine. It seems to be a question of >> configuration or composition of other, already installed ports. > > According to the pr this problem also occur on 8.0-STABLE/amd64. Could > you please send me (or upload it somewhere) the output of pkg_info from > the system where the build fails and from the system where the build was > successful. It looks like this problem only occur if net/mpich2 is installed and libxul tries to use include/mpi.h which was installed by mpich2. With the help of Rainer's package list I was able to reproduce this problem here by installing mpich2. We are working on a fix. Beat ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/free
Re: New version of the fakeroot patch
On Thu, 24.12.2009 at 13:22:40 +0100, Tijl Coosemans wrote:
> On Thursday 24 December 2009 06:43:02 Ulrich Spörlein wrote:
> > On Tue, 15.12.2009 at 10:00:18 +0100, Tijl Coosemans wrote:
> >> On Tuesday 15 December 2009 09:10:47 Matthew Seaman wrote:
> >>> Uh -- is it actually possible to create an empty directory when
> >>> installing from a pkg tarball?
> >>>
> >>> I ran into this problem with the phpMyAdmin port, and the only good
> >>> way I found to solve it was to add a stub file into any empty
> >>> directories. You could use a post install script or an mtree file,
> >>> but that seems like overkill for such a trivial operation.
> >>
> >> If you want to create ${PREFIX}/somedir you can add this line
> >> to pkg-plist:
> >>
> >> @exec mkdir -p %D/somedir
> >
> > ... and then you still need to chmod/chown to fix permissions. I
> > wonder why that doesn't work with tar. Is that a limitation of the
> > format, should we perhaps use cpio (with bsdtar, it would be
> > transparent anyway).
>
> Ownership and permissions are restored by tar. It's just that empty
> directories aren't added to the archive by pkg_create.
For me, pkg_create does not even add non-empty directories to the tar,
just the files. Case in point: games/bsdgames
1. Remove all "chmod" calls in pkg-plist (won't affect install target)
2. make package
3. find /var/games -ls > /tmp/dir.port
4. pkg_delete bsdgames-\*
5. rm -rf /var/games
6. pkg_add /usr/ports/packages/All/bsdgames-2.4_1,1.tbz
7. find /var/games -ls > /tmp/dir.pkg
8. Compare and find out that all directories have 0755, which is wrong.
Or simply run tar tvf on the package and see all files, but no
directories.
Adding the directory itself to the PLIST would work, but then everything
under /var/games would get sucked up by pkg_create, no matter if it's
relevant or not. (Cpio would have that feature ...)
Tricky, huh?
Regards,
Uli
___
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: ports/141131: www/libxul does not compile any more
On 24.12.2009 15:51 (UTC+1), Beat Gaetzi wrote: Beat Gaetzi wrote: Rainer Hurling wrote: On 24.12.2009 09:46 (UTC+1), Scott Bennett wrote: On Tue, 22 Dec 2009 11:46:06 + Anton Shterenlikht wrote: On Tue, Dec 22, 2009 at 12:36:12PM +0100, Rainer Hurling wrote: On 22.12.2009 10:38 (UTC+1), Anton Shterenlikht wrote: On Mon, Dec 21, 2009 at 09:47:33PM +0100, Rainer Hurling wrote: According to PR 141131 I see exactly the same error messages when I try to upgrade from libxul-1.9.0.15 to libxul-1.9.0.16: --- [..snip..] cc -o FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o -c -O -fPIC -ansi -Wall -Wno-switch -DFREEBSD -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DSHLIB_SUFFIX=\"so\" -DSHLIB_PREFIX=\"lib\" -DSHLIB_VERSION=\"3\" -DSOFTOKEN_SHLIB_VERSION=\"3\" -DRIJNDAEL_INCLUDE_TABLES -UDEBUG -DNDEBUG -D_THREAD_SAFE -D_REENTRANT -DNSS_ENABLE_ECC -DUSE_UTIL_DIRECTLY -D_X86_ -DMP_API_COMPATIBLE -I/usr/local/include -I/usr/local/include/nspr -I/usr/ports/www/libxul/work/mozilla/dist/include -I../../../../dist/public/nss -I../../../../dist/private/nss -I../../../../dist/include -Impi -Iecl dsa.c dsa.c: In function 'FIPS186Change_ReduceModQForDSA': dsa.c:75: error: 'mp_int' undeclared (first use in this function) dsa.c:75: error: (Each undeclared identifier is reported only once dsa.c:75: error: for each function it appears in.) dsa.c:75: error: expected ';' before 'W' dsa.c:76: error: 'mp_err' undeclared (first use in this function) dsa.c:76: error: expected ';' before 'err' [..snip..] gmake[6]: *** [FreeBSD9.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/dsa.o] Fehler 1 gmake[6]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' gmake[5]: *** [libs] Fehler 2 gmake[5]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/nss/lib/freebl' gmake[4]: *** [libs] Fehler 2 gmake[4]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/nss/lib' gmake[3]: *** [libs] Fehler 2 gmake[3]: Leaving directory `/usr/ports/www/libxul/work/mozilla/security/manager' gmake[2]: *** [libs_tier_toolkit] Fehler 2 gmake[2]: Leaving directory `/usr/ports/www/libxul/work/mozilla' gmake[1]: *** [tier_toolkit] Fehler 2 gmake[1]: Leaving directory `/usr/ports/www/libxul/work/mozilla' gmake: *** [default] Fehler 2 *** Error code 1 --- This happens on three different machines all running latest 9.0-CURRENT (i386). As far as I can see there are no relevant flags set in etc/make.conf. Any clues what is going wrong? I found no solution to this PR. Please let me know if I can provide more information or test something. I've got libxul-1.9.0.16 built fine on ia64 and sparc64. No issues, just 'portmaster -force-config -Bd libxul'. Thanks for answering. As I wrote before, I have this on different machines, all running newest i386-CURRENT. On another machine with amd64-CURRENT I had been able to compile libxul-1.9.0.16. Perhaps there is something wrong with my configuration? (I copied most from system to system ...) # uname -srm FreeBSD 9.0-CURRENT i386 # pkg_info -xo libxul Information for libxul-1.9.0.16: Origin: www/libxul # cd /usr/ports/www/libxul # make showconfig ===> The following configuration options are available for libxul-1.9.0.16: JAVA=off "Enable JAVA xpcom" DEBUG=off "Build a debugging image" LOGGING=off "Enable additional log messages" OPTIMIZED_CFLAGS=off "Enable some additional optimizations" ===> Use 'make config' to modify these settings # Unfortunately this error with libxul arises only on my i386 systems. On my amd64 systems (9.0-CURRENT) with allmost the same configuration and installed ports libxul builds fine. It seems to be a question of configuration or composition of other, already installed ports. According to the pr this problem also occur on 8.0-STABLE/amd64. Could you please send me (or upload it somewhere) the output of pkg_info from the system where the build fails and from the system where the build was successful. It looks like this problem only occur if net/mpich2 is installed and libxul tries to use include/mpi.h which was installed by mpich2. With the help of Rainer's package list I was able to reproduce this problem here by installing mpich2. We are working on a fix. I can confirm that for my i386. After deinstalling net/mpich2 I am able to compile www/libxul again :-) Many many thanks to Beat for working this out. Merry Christmas, Rainer ___ 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"
CTF: sudo update
I'd like to update sudo to the latest version. I've done some testing locally and everything is fine but I would like further testing in other environments. If you are willing to test this out please apply the patch at http://people.freebsd.org/~wxs/sudo.diff and rebuild/reinstall sudo. If it works, or not, for you please respond PRIVATELY and describe your environment. I'm especially interested in LDAP environments. I'd like to make sure I break as little as possible since this is such a heavily used port. -- WXS ___ 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"
