[patch] ports/*/Makefile: move missorted SUBDIR lines
>Submitter-Id: current-users >Originator:Conrad J. Sabatier >Organization: >Confidential: no >Synopsis: [patch] ports/*/Makefile: move missorted SUBDIR lines >Severity: non-critical >Priority: low >Category: ports >Class: change-request >Release: FreeBSD 10.0-CURRENT amd64 >Environment: System: FreeBSD serene.no-ip.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sun Feb 12 19:15:46 CST 2012 conr...@serene.no-ip.org:/usr/obj/usr/src/sys/CUSTOM amd64 >Description: A few of the ports categories' Makefiles contain missorted entries. I discovered this while working on a new tool I'm writing in C to speed up the rebuilding of the ports README.html files. Other ports tools or make targets may be affected by this missorting as well. >How-To-Repeat: N/A >Fix: patch below --- ports-Makefiles.diff begins here --- Index: /usr/ports/audio/Makefile === RCS file: /home/ncvs/ports/audio/Makefile,v retrieving revision 1.1211 diff -u -r1.1211 Makefile --- /usr/ports/audio/Makefile 7 Feb 2012 06:39:52 - 1.1211 +++ /usr/ports/audio/Makefile 23 Feb 2012 07:02:19 - @@ -303,8 +303,8 @@ SUBDIR += icegenerator SUBDIR += ices SUBDIR += ices0 -SUBDIR += id3el SUBDIR += id3ed +SUBDIR += id3el SUBDIR += id3lib SUBDIR += id3mtag SUBDIR += id3ren Index: /usr/ports/devel/Makefile === RCS file: /home/ncvs/ports/devel/Makefile,v retrieving revision 1.4870 diff -u -r1.4870 Makefile --- /usr/ports/devel/Makefile 21 Feb 2012 20:02:35 - 1.4870 +++ /usr/ports/devel/Makefile 23 Feb 2012 07:04:39 - @@ -3780,8 +3780,8 @@ SUBDIR += rubygem-templater SUBDIR += rubygem-test SUBDIR += rubygem-test-unit -SUBDIR += rubygem-thrift SUBDIR += rubygem-thor +SUBDIR += rubygem-thrift SUBDIR += rubygem-tilt SUBDIR += rubygem-tins SUBDIR += rubygem-transactionsimple Index: /usr/ports/japanese/Makefile === RCS file: /home/ncvs/ports/japanese/Makefile,v retrieving revision 1.792 diff -u -r1.792 Makefile --- /usr/ports/japanese/Makefile19 Feb 2012 20:10:02 - 1.792 +++ /usr/ports/japanese/Makefile23 Feb 2012 07:16:29 - @@ -156,8 +156,8 @@ SUBDIR += less SUBDIR += libicq SUBDIR += libjcode -SUBDIR += libslang SUBDIR += libskk +SUBDIR += libslang SUBDIR += libtomoe-gtk SUBDIR += lipsf SUBDIR += lookup Index: /usr/ports/net-im/Makefile === RCS file: /home/ncvs/ports/net-im/Makefile,v retrieving revision 1.164 diff -u -r1.164 Makefile --- /usr/ports/net-im/Makefile 18 Jan 2012 07:43:03 - 1.164 +++ /usr/ports/net-im/Makefile 23 Feb 2012 07:16:00 - @@ -173,10 +173,10 @@ SUBDIR += tkabber-devel SUBDIR += tkabber-plugins SUBDIR += tkabbur -SUBDIR += turpial SUBDIR += tmsnc SUBDIR += trix SUBDIR += ttytter +SUBDIR += turpial SUBDIR += twirssi SUBDIR += twitmail SUBDIR += vacuum-im Index: /usr/ports/net-mgmt/Makefile === RCS file: /home/ncvs/ports/net-mgmt/Makefile,v retrieving revision 1.278 diff -u -r1.278 Makefile --- /usr/ports/net-mgmt/Makefile17 Feb 2012 17:22:20 - 1.278 +++ /usr/ports/net-mgmt/Makefile23 Feb 2012 07:15:19 - @@ -157,8 +157,8 @@ SUBDIR += net-snmp SUBDIR += netams SUBDIR += netams-front -SUBDIR += netdisco-mibs SUBDIR += netdisco +SUBDIR += netdisco-mibs SUBDIR += netleak SUBDIR += netmask SUBDIR += netmond Index: /usr/ports/sysutils/Makefile === RCS file: /home/ncvs/ports/sysutils/Makefile,v retrieving revision 1.1381 diff -u -r1.1381 Makefile --- /usr/ports/sysutils/Makefile16 Feb 2012 18:06:06 - 1.1381 +++ /usr/ports/sysutils/Makefile23 Feb 2012 07:14:36 - @@ -485,8 +485,8 @@ SUBDIR += mapchan SUBDIR += massadmin SUBDIR += mbmon -SUBDIR += mcollective SUBDIR += mcelog +SUBDIR += mcollective SUBDIR += mcron SUBDIR += mcweject SUBDIR += mdcp Index: /usr/ports/www/Makefile === RCS file: /home/ncvs/ports/www/Makefile,v retrieving revision 1.3135 diff -u -r1.3135 Makefile --- /usr/ports/www/Makefile 22 Feb 2012 03:41:01 - 1.3135 +++ /usr/ports/www/Makefile 23 Feb 2012 07:13:26 - @@ -1708,8 +1708,8 @@ SUBDIR += rubygem-typhoeus SUBDIR += rubygem-uglifier SUBDIR += rubygem-unicorn -SUBDIR += rubygem-url_escape SUBDIR += rubygem-url-mount +SUBDIR += rubygem-url_escape
Re: Fix nvidia-like ports, help needed
On Thursday 23 February 2012 08:21:33 Baptiste Daroussin wrote: > Why not but which package will provide the libGL.so file? in all case the > users might need to be able to switch the libGL.so file from the nvidia > one to the mesa one, what would a user have to do for that, in particular > a user using only binary packages where a file can't belong to 2 different > packages without conflicting? Something like splitting libGL.so and making a mesa-libgl-whatever port? Then mark CONFLICTS, and replacing that with nvidia-driver will be easy. Won't it? -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla Dear Lord: I just want *_o_n_e* one-armed manager so I never have to hear "On the other hand", again. signature.asc Description: This is a digitally signed message part.
Re: Fix nvidia-like ports, help needed
On 23.02.2012 08:34, Alexander Leidinger wrote: Quoting Baptiste Daroussin (from Thu, 23 Feb 2012 08:21:33 +0100): On Thu, Feb 23, 2012 at 01:35:02AM +, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: > One of the issues with 'alternatives' implementations is that they are > not selectable per-user (including non superuser). > > In this particular case (libGL), also what about the native X server > vs. virtual X servers that support using the mesa lib (per-application > selection)? > > In addition to something like alternatives, another option is to allow > installation of conflicting files (like libGL.so in this case) to > separate directories and specify which to use using a path (like > LD_LIBRARY_PATH or rpath at compile time). That can help with the > aforementioned per-user and per-application variation. > > Personally, I prefer the "path" method over something like alternative > sym links (e.g., debian/redhat alternatives). There can still be a > front-end tool to get at the "alternates" configuration information, > but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see "etc/alternative.d" I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Why not but which package will provide the libGL.so file? in all case the users might need to be able to switch the libGL.so file from the nvidia one to the mesa one, what would a user have to do for that, in particular a user using only binary packages where a file can't belong to 2 different packages without conflicting? if someone have a better solution than a framework for that I'm open but no the knob is not a solution for package people. Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths="$ldconfig_paths /usr/local/lib/-gl/" to rc.conf could be an option. Bye, Alexander. Currently, no I don't have a list of packages that overwrite things, anyway way I do really like this kind of solution, I don't know yet how this can be automated, it really looks the right way. regards, Bapt ___ 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: [patch] ports/*/Makefile: move missorted SUBDIR lines
On 2/23/12 2:50 AM, Conrad J. Sabatier wrote: retrieving revision 1.278 diff -u -r1.278 Makefile --- /usr/ports/net-mgmt/Makefile17 Feb 2012 17:22:20 - 1.278 +++ /usr/ports/net-mgmt/Makefile23 Feb 2012 07:15:19 - @@ -157,8 +157,8 @@ SUBDIR += net-snmp SUBDIR += netams SUBDIR += netams-front -SUBDIR += netdisco-mibs SUBDIR += netdisco +SUBDIR += netdisco-mibs SUBDIR += netleak SUBDIR += netmask SUBDIR += netmond woops, this one was mine. thanks for finding it. -- Michael Scheidell, CTO >*| * SECNAP Network Security Corporation d: +1.561.948.2259 w: http://people.freebsd.org/~scheidell ___ 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: Fix nvidia-like ports, help needed
Quoting Baptiste Daroussin (from Thu, 23 Feb 2012 08:21:33 +0100): On Thu, Feb 23, 2012 at 01:35:02AM +, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: > One of the issues with 'alternatives' implementations is that they are > not selectable per-user (including non superuser). > > In this particular case (libGL), also what about the native X server > vs. virtual X servers that support using the mesa lib (per-application > selection)? > > In addition to something like alternatives, another option is to allow > installation of conflicting files (like libGL.so in this case) to > separate directories and specify which to use using a path (like > LD_LIBRARY_PATH or rpath at compile time). That can help with the > aforementioned per-user and per-application variation. > > Personally, I prefer the "path" method over something like alternative > sym links (e.g., debian/redhat alternatives). There can still be a > front-end tool to get at the "alternates" configuration information, > but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see "etc/alternative.d" I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Why not but which package will provide the libGL.so file? in all case the users might need to be able to switch the libGL.so file from the nvidia one to the mesa one, what would a user have to do for that, in particular a user using only binary packages where a file can't belong to 2 different packages without conflicting? if someone have a better solution than a framework for that I'm open but no the knob is not a solution for package people. Do you havea list of packages which overzrite something, respectively do you have a list of files which are overwriten? If we just talk about the nvidia lib, installing the mesa and nvidia ones into subdirectories and asking to add (or adding automatically/optionally) ldconfig_paths="$ldconfig_paths /usr/local/lib/-gl/" to rc.conf could be an option. Bye, Alexander. -- What we cannot speak about we must pass over in silence. -- Wittgenstein http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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"
conky does not build
Hi, conky does not build on 9-STABLE: ... cc -DHAVE_CONFIG_H -I. -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -Wall -W -O2 -pipe -march=nocona -fno-strict-aliasing -MT conky-freebsd.o -MD -MP -MF .deps/conky-freebsd.Tpo -c -o conky-freebsd.o `test -f 'freebsd.c' || echo './'`freebsd.c freebsd.c:286:46: error: operator '<' has no left operand freebsd.c: In function 'get_cpu_count': freebsd.c:303: warning: unused variable 'cpu_count_len' gmake[2]: *** [conky-freebsd.o] Error 1 gmake[2]: Leaving directory `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/sysutils/conky. *** Error code 1 Stop in /usr/ports/sysutils/conky. There are other people with the same problem [1]. It seems related to __FreeBSD_kernel__ (missing macro?). I didn't go deeper (ENOTIME), maybe someone on the list knows more... While speaking about conky I'd like mention another issue - very low MAX_NET_INTERFACES value. When I run VirtualBox, conky crashes due to increased number of network interfaces on the host. What about the following patch? (I know it doesn't cure the the cause... but yet does help a bit) diff -Naur conky-1.8.1/configure conky-1.8.1-patched/configure --- configure.orig +++ configure @@ -16102,7 +16102,7 @@ $as_echo "#define DEFAULT_TEXT_BUFFER_SIZE 256" >>confdefs.h -$as_echo "#define MAX_NET_INTERFACES 16" >>confdefs.h +$as_echo "#define MAX_NET_INTERFACES 64" >>confdefs.h (CC'd to MAINTAINER) Best regards, Oli [1] http://forums.freebsd.org/showthread.php?t=29128 ___ 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: conky does not build
В Thu, 23 Feb 2012 11:12:28 +0100 kron пишет: > Hi, > > conky does not build on 9-STABLE: > > ... > cc -DHAVE_CONFIG_H -I. > -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" > -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include > -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -Wall -W > -O2 -pipe -march=nocona -fno-strict-aliasing -MT conky-freebsd.o -MD > -MP -MF .deps/conky-freebsd.Tpo -c -o conky-freebsd.o `test -f > 'freebsd.c' || echo './'`freebsd.c > freebsd.c:286:46: error: operator '<' has no left operand > freebsd.c: In function 'get_cpu_count': > freebsd.c:303: warning: unused variable 'cpu_count_len' > gmake[2]: *** [conky-freebsd.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake[1]: *** [all] > Error 2 gmake[1]: Leaving directory > `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake: *** > [all-recursive] Error 1 *** Error code 1 > > Stop in /usr/ports/sysutils/conky. > *** Error code 1 > > Stop in /usr/ports/sysutils/conky. > > There are other people with the same problem [1]. It seems > related to __FreeBSD_kernel__ (missing macro?). I didn't > go deeper (ENOTIME), maybe someone on the list knows more... > > While speaking about conky I'd like mention another issue > - very low MAX_NET_INTERFACES value. When I run VirtualBox, > conky crashes due to increased number of network interfaces > on the host. What about the following patch? (I know it doesn't > cure the the cause... but yet does help a bit) > > diff -Naur conky-1.8.1/configure conky-1.8.1-patched/configure > --- configure.orig > +++ configure > @@ -16102,7 +16102,7 @@ > $as_echo "#define DEFAULT_TEXT_BUFFER_SIZE 256" >>confdefs.h > > > -$as_echo "#define MAX_NET_INTERFACES 16" >>confdefs.h > +$as_echo "#define MAX_NET_INTERFACES 64" >>confdefs.h > > > > > (CC'd to MAINTAINER) > > Best regards, > Oli sorry, not all patches are the ones that need to be sent ___ 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: conky does not build
On Thu, Feb 23, 2012 at 03:26:25PM +0200, Ivan Klymenko wrote: > В Thu, 23 Feb 2012 11:12:28 +0100 > kron пишет: > > > Hi, > > > > conky does not build on 9-STABLE: > > > > ... > > cc -DHAVE_CONFIG_H -I. > > -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" > > -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include > > -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE > > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -Wall -W > > -O2 -pipe -march=nocona -fno-strict-aliasing -MT conky-freebsd.o -MD > > -MP -MF .deps/conky-freebsd.Tpo -c -o conky-freebsd.o `test -f > > 'freebsd.c' || echo './'`freebsd.c > > freebsd.c:286:46: error: operator '<' has no left operand > > freebsd.c: In function 'get_cpu_count': > > freebsd.c:303: warning: unused variable 'cpu_count_len' > > gmake[2]: *** [conky-freebsd.o] Error 1 > > gmake[2]: Leaving directory > > `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake[1]: *** [all] > > Error 2 gmake[1]: Leaving directory > > `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake: *** > > [all-recursive] Error 1 *** Error code 1 > > > > Stop in /usr/ports/sysutils/conky. > > *** Error code 1 > > > > Stop in /usr/ports/sysutils/conky. > > > > There are other people with the same problem [1]. It seems > > related to __FreeBSD_kernel__ (missing macro?). I didn't > > go deeper (ENOTIME), maybe someone on the list knows more... > > > > While speaking about conky I'd like mention another issue > > - very low MAX_NET_INTERFACES value. When I run VirtualBox, > > conky crashes due to increased number of network interfaces > > on the host. What about the following patch? (I know it doesn't > > cure the the cause... but yet does help a bit) > > > > diff -Naur conky-1.8.1/configure conky-1.8.1-patched/configure > > --- configure.orig > > +++ configure > > @@ -16102,7 +16102,7 @@ > > $as_echo "#define DEFAULT_TEXT_BUFFER_SIZE 256" >>confdefs.h > > > > > > -$as_echo "#define MAX_NET_INTERFACES 16" >>confdefs.h > > +$as_echo "#define MAX_NET_INTERFACES 64" >>confdefs.h > > > > > > > > > > (CC'd to MAINTAINER) > > > > Best regards, > > Oli > > > > check out new patches Thanks for the patches mate. Unfortunately I'm in ENOTIME state till the end of the month. I hope you guys can wait until then. Sorry about that. \n\n ___ 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: conky does not build
On 2012/02/23 14:41, Ivan Klymenko wrote: В Thu, 23 Feb 2012 11:12:28 +0100 kron пишет: Hi, conky does not build on 9-STABLE: ... cc -DHAVE_CONFIG_H -I. -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -Wall -W -O2 -pipe -march=nocona -fno-strict-aliasing -MT conky-freebsd.o -MD -MP -MF .deps/conky-freebsd.Tpo -c -o conky-freebsd.o `test -f 'freebsd.c' || echo './'`freebsd.c freebsd.c:286:46: error: operator '<' has no left operand freebsd.c: In function 'get_cpu_count': freebsd.c:303: warning: unused variable 'cpu_count_len' gmake[2]: *** [conky-freebsd.o] Error 1 gmake[2]: Leaving directory `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake: *** [all-recursive] Error 1 *** Error code 1 Stop in /usr/ports/sysutils/conky. *** Error code 1 Stop in /usr/ports/sysutils/conky. There are other people with the same problem [1]. It seems related to __FreeBSD_kernel__ (missing macro?). I didn't go deeper (ENOTIME), maybe someone on the list knows more... While speaking about conky I'd like mention another issue - very low MAX_NET_INTERFACES value. When I run VirtualBox, conky crashes due to increased number of network interfaces on the host. What about the following patch? (I know it doesn't cure the the cause... but yet does help a bit) diff -Naur conky-1.8.1/configure conky-1.8.1-patched/configure --- configure.orig +++ configure @@ -16102,7 +16102,7 @@ $as_echo "#define DEFAULT_TEXT_BUFFER_SIZE 256">>confdefs.h -$as_echo "#define MAX_NET_INTERFACES 16">>confdefs.h +$as_echo "#define MAX_NET_INTERFACES 64">>confdefs.h (CC'd to MAINTAINER) Best regards, Oli sorry, not all patches are the ones that need to be sent ... and not all replies help. I stand corrected, please skip the patch. Still the build issue needs is to be resolved... BR, Oli ___ 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: conky does not build
В Thu, 23 Feb 2012 11:12:28 +0100 kron пишет: > Hi, > > conky does not build on 9-STABLE: > > ... > cc -DHAVE_CONFIG_H -I. > -DSYSTEM_CONFIG_FILE=\"/usr/local/etc/conky/conky.conf\" > -DPACKAGE_LIBDIR=\"/usr/local/lib/conky\" -I/usr/local/include > -D_THREAD_SAFE -I/usr/local/include -D_THREAD_SAFE > -I/usr/local/include -D_THREAD_SAFE -I/usr/local/include -Wall -W > -O2 -pipe -march=nocona -fno-strict-aliasing -MT conky-freebsd.o -MD > -MP -MF .deps/conky-freebsd.Tpo -c -o conky-freebsd.o `test -f > 'freebsd.c' || echo './'`freebsd.c > freebsd.c:286:46: error: operator '<' has no left operand > freebsd.c: In function 'get_cpu_count': > freebsd.c:303: warning: unused variable 'cpu_count_len' > gmake[2]: *** [conky-freebsd.o] Error 1 > gmake[2]: Leaving directory > `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake[1]: *** [all] > Error 2 gmake[1]: Leaving directory > `/usr/ports/sysutils/conky/work/conky-1.8.1/src' gmake: *** > [all-recursive] Error 1 *** Error code 1 > > Stop in /usr/ports/sysutils/conky. > *** Error code 1 > > Stop in /usr/ports/sysutils/conky. > > There are other people with the same problem [1]. It seems > related to __FreeBSD_kernel__ (missing macro?). I didn't > go deeper (ENOTIME), maybe someone on the list knows more... > > While speaking about conky I'd like mention another issue > - very low MAX_NET_INTERFACES value. When I run VirtualBox, > conky crashes due to increased number of network interfaces > on the host. What about the following patch? (I know it doesn't > cure the the cause... but yet does help a bit) > > diff -Naur conky-1.8.1/configure conky-1.8.1-patched/configure > --- configure.orig > +++ configure > @@ -16102,7 +16102,7 @@ > $as_echo "#define DEFAULT_TEXT_BUFFER_SIZE 256" >>confdefs.h > > > -$as_echo "#define MAX_NET_INTERFACES 16" >>confdefs.h > +$as_echo "#define MAX_NET_INTERFACES 64" >>confdefs.h > > > > > (CC'd to MAINTAINER) > > Best regards, > Oli > check out new patches ___ 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: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 21:11:13 -0800 Tim Kientzle wrote: > > On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > > > On Tue, 21 Feb 2012, Steve Kargl wrote: > > > >> 3) Add a new option to ldconfig to prepend new libraries to > >> the hints files and fix the ports to use this option instead > >> of -m. > > > > You don't want system binaries that want /lib/libgcc_s.so.1 > > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't > > your option 3 do that? > > Why not? Would it cause problems? > > Is libgcc from GCC 4.6 incompatible with /lib/libgcc? > > If I understand correctly, the libgcc in base is pretty stripped > down compared to "regular" libgcc, because most of that > stuff is in our libc instead. So if there were compatibility > problems, I'd expect those to show up when GCC 4.6 linked > programs against /usr/local/.../libgcc and /lib/libc. > You understand it a bit wrong, but your conclusions are correct. libgcc in base is not stripped in any way and is supposed to be identical to one coming from upstream. As long as upstream maintains backward compatibility, their library should be a perfect replacement for ours. There was a time period while FreeBSD used dynamic unwind into search using dl_iterate_phdr while upstream GCCs didn't, but that was fixed by GCC folks switching GCC to use dl_iterate_phdr on Linux and FreeBSD by default quite while ago. I am not aware of any other incompatibilities at this time. -- Alexander Kabaev signature.asc Description: PGP signature
Re: ports/16417: nethack3 port won't compile on 3.4-Stable
Synopsis: nethack3 port won't compile on 3.4-Stable Responsible-Changed-From-To: freebsd-ports->jgh Responsible-Changed-By: jgh Responsible-Changed-When: Thu Feb 23 17:35:38 UTC 2012 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=16417 ___ 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/16417: nethack3 port won't compile on 3.4-Stable
Synopsis: nethack3 port won't compile on 3.4-Stable Responsible-Changed-From-To: jgh->freebsd-ports Responsible-Changed-By: jgh Responsible-Changed-When: Thu Feb 23 17:36:29 UTC 2012 Responsible-Changed-Why: took wrong number http://www.freebsd.org/cgi/query-pr.cgi?pr=16417 ___ 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: Fix nvidia-like ports, help needed
Baptiste Daroussin wrote at 11:28 + on Feb 23, 2012: > On 23.02.2012 08:34, Alexander Leidinger wrote: > > Do you havea list of packages which overzrite something, respectively > > do you have a list of files which are overwriten? > > > > If we just talk about the nvidia lib, installing the mesa and nvidia > > ones into subdirectories and asking to add (or adding > > automatically/optionally) ldconfig_paths="$ldconfig_paths > > /usr/local/lib/-gl/" to rc.conf could be an option. > > Currently, no I don't have a list of packages that overwrite things, > anyway way I do really like this kind of solution, I don't know yet how > this can be automated, it really looks the right way. If the nvidia libGL can be dynamically linked with, say, a vnc server, and have it be a drop in replacement for the mesa libGL, then ldconfig_paths would be fine. If not, then those apps which need the mesa libGL would need to link with -rpath perhaps to point at the "right" libGL (or pass appropriate path info to those apps that might use dlopen(3)). ___ 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: Fix nvidia-like ports, help needed
On Thu, Feb 23, 2012 at 12:56:22PM -0700, John Hein wrote: > Baptiste Daroussin wrote at 11:28 + on Feb 23, 2012: > > On 23.02.2012 08:34, Alexander Leidinger wrote: > > > Do you havea list of packages which overzrite something, respectively > > > do you have a list of files which are overwriten? > > > > > > If we just talk about the nvidia lib, installing the mesa and nvidia > > > ones into subdirectories and asking to add (or adding > > > automatically/optionally) ldconfig_paths="$ldconfig_paths > > > /usr/local/lib/-gl/" to rc.conf could be an option. > > > > Currently, no I don't have a list of packages that overwrite things, > > anyway way I do really like this kind of solution, I don't know yet how > > this can be automated, it really looks the right way. > > If the nvidia libGL can be dynamically linked with, say, a vnc server, and > have it be a drop in replacement for the mesa libGL, then ldconfig_paths > would be fine. If not, then those apps which need the mesa libGL would > need to link with -rpath perhaps to point at the "right" libGL (or > pass appropriate path info to those apps that might use dlopen(3)). > ___ > 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" Another solution could be to add an entry (and drop it in deinstallation to libmap.conf) when installing the nvidia driver, in that case installing it ad libGL-nvidia.so.1 and adding: libGL.so.1 libGL-nvidia.so.1 or something like that. regards, Bapt pgpkk4DzWAqw6.pgp Description: PGP signature
graphics/poppler-qt4: Installation error: /poppler-0.18.4/qt4/src', GEN poppler-optcontent.moc, not: not found, gmake[1]: *** [poppler-optcontent.moc] Error 127
I found myself confronted with this error today. I happens on a FreeBSD 10.0/amd64 box, most recently built-world. The error is persistent with CLANG and legacy GCC 4.2.1. The port is a denepndency for several client applications I've installed on that box and after the update today (poppler-qt4 seems to be installed before as version 0.18.4 and got updated today to version 0.18.4_1), the port isn't installed anymore! The portmaintainersoftware is portmaster. Error follows below. Any ideas? Regards, Oliver clang++: warning: argument unused during compilation: '-fno-check-new' CXXlibpoppler_cpp_la-poppler-version.lo clang++: warning: argument unused during compilation: '-fno-check-new' CXXLD libpoppler-cpp.la clang++: warning: argument unused during compilation: '-pthread' clang++: warning: argument unused during compilation: '-pthread' gmake[3]: Leaving directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp' Making all in tests gmake[3]: Entering directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests' CXXparseargs.o clang++: warning: argument unused during compilation: '-fno-check-new' CXXpoppler-dump.o clang++: warning: argument unused during compilation: '-fno-check-new' CXXLD poppler-dump clang++: warning: argument unused during compilation: '-ansi' CXXpoppler-render.o clang++: warning: argument unused during compilation: '-fno-check-new' CXXLD poppler-render clang++: warning: argument unused during compilation: '-ansi' gmake[3]: Leaving directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp/tests' gmake[2]: Leaving directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/cpp' gmake[2]: Entering directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4' gmake[2]: Nothing to be done for `all-am'. gmake[2]: Leaving directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4' gmake[1]: Leaving directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4' ===> Installing for poppler-qt4-0.18.4 ===> Generating temporary packing list Making install in src gmake[1]: Entering directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src' GENpoppler-optcontent.moc not: not found gmake[1]: *** [poppler-optcontent.moc] Error 127 gmake[1]: Leaving directory `/usr/ports/graphics/poppler-qt4/work/poppler-0.18.4/qt4/src' gmake: *** [install-recursive] Error 1 *** [do-install] Error code 2 Stop in /usr/ports/graphics/poppler-qt4. ===>>> Installation of poppler-qt4-0.18.4 (graphics/poppler-qt4) failed ===>>> Aborting update Terminated ===>>> You can restart from the point of failure with this command line: portmaster graphics/poppler-qt4 signature.asc Description: OpenPGP digital signature
Re: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 23/02/2012 04:19 Doug Barton said the following: > This gives much better results. :) I can kldload the module, and get > this on the command line: > vboxdrv: fAsync=0 offMin=0x3596 offMax=0xa897 Thank you for reporting and testing! -- 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: Virtualbox 4.1.8 vboxdrv instantly panics on 8-stable i386
on 23/02/2012 08:26 Cy Schubert said the following: > In message <4f457ae8.4090...@freebsd.org>, Andriy Gapon writes: >> on 22/02/2012 12:48 Doug Barton said the following: >>> On 02/22/2012 02:23, Andriy Gapon wrote: The attached patched should try to grab the memory harder. >>> >>> Same result, different memory address: >>> >>> supdrvGipCreate: failed to allocate the GIP page. rc=-8 >>> vboxdrv: supdrvInitDevExt failed, rc=-8 >>> module_register_init: MOD_LOAD (vboxdrv, 0xc66e8410, 0) error 12 >> >> OK, now that, thanks to more testers, I realize that this issue is entirely >> i386-specific, I think that I might have been barking at the wrong trees. >> Now something very i386-ish to try to deal with the problem - the usual patch >> file is attached. > > The patch tests out OK on 8.2 and 9.0. No panic. Fedora 16 runs nicely under > vbox. Thank you for testing! -- 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: Fix nvidia-like ports, help needed
On 2/23/2012 13:14, Baptiste Daroussin wrote:
Another solution could be to add an entry (and drop it in deinstallation to
libmap.conf) when installing the nvidia driver, in that case installing it ad
libGL-nvidia.so.1 and adding:
libGL.so.1 libGL-nvidia.so.1
or something like that.
Going that route is likely to be messy given the current monolithic
/etc/libmap{,32}.conf
You'd most likely want ${LOCALBASE}/etc/libmap.conf.d/* (in a similar
manner to etc/periodic, etc/rc.d and so on). Whether the code that
currently handles libmap.conf is itself extended to use this directory
structure is open for discussion. An alternate method could perhaps be
a 'genlibmap' command which takes /etc/libmap.conf and this directory
structure to create a /var/run/libmap.conf which is actually used by rtld.
Having potentially multiple ports dinking _directly_ with
/etc/libmap.conf will result in considerable foot shooting.
-aDe
___
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"
