Grandfather dependencies completely out of control
Howdy, I'm looking at the use of portmaster to upgrade perl versions, and noticed that there are a ton of ports listed as dependent on perl that don't have any use for it, including one of mine: qbittorrent-2.2.6 libnotify-0.4.5_3 atk-1.28.0 gio-fam-backend-2.22.4 gamin-0.1.10_3 glib-2.22.4 perl-threaded-5.8.9_3 Taking a look at devel/glib20, I see this: USE_PERL5= yes although from the docs in the glib tarball it's not at all clear (to me anyway) what it's used for. Given that it doesn't seem to be a rundep for glib20 it's also not at all clear to me why qbittorrent should have a pkgdep for it. Can someone please explain what the heck is going on here? (And please note, I'm picking on glib20 because this seems to be a particularly egregious example, but I'm really more interested in the problem generally.) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Xorg does not start after upgrade from 7.4 to 7.5 (Undefined symbol xf86LoaderReqSymLists in intel_drv.so)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 01, 2010 at 10:01:51PM -0300, Joey Mingrone wrote: Hi, When starting Xorg /libexec/ld-elf.so.1: /usr/local/lib/xorg/modules/drivers/intel_drv.so: Undefined symbol xf86LoaderReqSymLists appears. I tried a newly generated config file, but there was no change. The is on a box running 8.0-RELEASE-p2. If there is any other information I can provide, please let me know. looks like your upgrade isn't complete. Cheers, Joey Mingrone ___ 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 - -- \ || / ( * * ) +-oOO--(_)--OOo-+ | PGP: 0xB1E6FCE9 | | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkvdHloACgkQdLJIhLHm/Ok6qACfZ/F+OdvoQC7hqiua1avc+vT0 CqsAnR2FyejWRLugREKfGTQwphsbyPa/ =6I6/ -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: GSoC: Making ports work with clang
Andrius Morkūnas wrote: Hi, I'm Andrius Morkūnas from Lithuania. My Summer of Code proposal was accepted this year and be working on my project, which is to make clang and ports to be friendly with each other. My main goals are: * Create an easy way to set ports compiler to either clang or gcc (and no, CC=clang is not a good way to do that). * Write a tool to detect common problems with individual ports not respecting environment variables like CC/CXX or doing other horrible things that break compilation with clang. * Make Gnome, KDE, Xorg and other widely used things to work with clang. Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. It crashes a lot, fails on many quite simple c++ patterns. Very immature. Don't you feel it's too early to start project like you are going to given the state of clang with c++? You will just keep stumbling upon various problems with various ports and maybe will make 30% of c++ ports build with it at best. 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
graphics/dri fails to build.
Hi freebsd-ports, I have two machines one running 8.0-RELEASE and one using 8.0-STABLE, the stable one successfully update xorg to 7.5 but the other one do not : cc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I../../../../../include -I../../../../../src/mesa -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri -I/usr/local/include -I/usr/local/include/drm-I/usr/local/include -O2 -pipe -fno-strict-aliasing -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -I../intel -I../intel/server -DI915 -DDRM_VBLANK_FLIP=DRM_VBLANK_FLIP i830_context.c -o i830_context.o In file included from i830_context.h:31, from i830_context.c:28: ../intel/intel_context.h:38:26: error: intel_bufmgr.h: No such file or directory In file included from ../intel/intel_context.h:40, from i830_context.h:31, from i830_context.c:28: ../intel/intel_screen.h:81: error: expected specifier-qualifier-list before 'dri_bufmgr' In file included from i830_context.h:31, from i830_context.c:28: ../intel/intel_context.h:93: error: expected specifier-qualifier-list before 'drm_intel_bo' ../intel/intel_context.h:166: error: expected declaration specifiers or '...' before 'dri_bo' ../intel/intel_context.h:183: error: expected specifier-qualifier-list before 'dri_bufmgr' In file included from i830_context.c:28: i830_context.h:133: error: expected specifier-qualifier-list before 'dri_bo' i830_context.c: In function 'i830CreateContext': i830_context.c:75: error: 'struct intel_context' has no member named 'ViewportMatrix' i830_context.c:85: error: 'struct intel_context' has no member named 'no_rast' i830_context.c:108: error: 'struct intel_context' has no member named 'verts' gmake[5]: *** [i830_context.o] Error 1 gmake[5]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa/drivers/dri/i915' gmake[4]: *** [subdirs] Error 1 gmake[4]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa/drivers/dri' gmake[3]: *** [default] Error 1 gmake[3]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa/drivers' gmake[2]: *** [driver_subdirs] Error 2 gmake[2]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src/mesa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/dri/work/Mesa-7.6.1/src' gmake: *** [default] Error 1 *** Error code 1 I have the same make.conf on the both, only WITHOUT_NOUVEAU=YES defined. What can I try ? King regards. 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
Re: graphics/dri fails to build.
http://www.freebsd.org/cgi/query-pr.cgi?pr=143723 It seems adding CFLAGS+=-march-=native solved the problem but I don't want to keep this flag everytime in my make.conf How this flag could solve the problem ? I can't understand. Cheers. ___ 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: Xorg does not start after upgrade from 7.4 to 7.5 (Undefined symbol xf86LoaderReqSymLists in intel_drv.so)
On Sun, May 2, 2010 at 03:42, Martin Wilke m...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 01, 2010 at 10:01:51PM -0300, Joey Mingrone wrote: Hi, When starting Xorg /libexec/ld-elf.so.1: /usr/local/lib/xorg/modules/drivers/intel_drv.so: Undefined symbol xf86LoaderReqSymLists appears. I tried a newly generated config file, but there was no change. The is on a box running 8.0-RELEASE-p2. If there is any other information I can provide, please let me know. looks like your upgrade isn't complete. I did a portmaster -a and everything compiled fine. I also did portmaster xf86-video-intel-2.7.1_2. Any other suggestions? portmaster -f xorg? Thanks, Joey ___ 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: Grandfather dependencies completely out of control
On Sat, 2010-05-01 at 23:09 -0700, Doug Barton wrote: Howdy, I'm looking at the use of portmaster to upgrade perl versions, and noticed that there are a ton of ports listed as dependent on perl that don't have any use for it, including one of mine: qbittorrent-2.2.6 libnotify-0.4.5_3 atk-1.28.0 gio-fam-backend-2.22.4 gamin-0.1.10_3 glib-2.22.4 perl-threaded-5.8.9_3 Taking a look at devel/glib20, I see this: USE_PERL5= yes although from the docs in the glib tarball it's not at all clear (to me anyway) what it's used for. Given that it doesn't seem to be a rundep for glib20 it's also not at all clear to me why qbittorrent should have a pkgdep for it. One of the scripts provided by devel/glib20 is a perl script. That is the reason why we need perl. -Koop Can someone please explain what the heck is going on here? (And please note, I'm picking on glib20 because this seems to be a particularly egregious example, but I'm really more interested in the problem generally.) Doug ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: firefox-3.6.3, 1 (trying to load certain pages causes the browser to hang then crash)
On Sat, 1 May 2010 22:30:47 -0300 Joey Mingrone j...@mingrone.org wrote: Hi, This behaviour is consistent for the same pages. For example, reader.google.com will never load. I can load pages with https:// so I'm not sure if this is related to the problem I've seen in gnats. This is on a box running 8.0-RELEASE-p2. Here is what /etc/make.conf looks like: CUPS_OVERWRITE_BASE=YES NO_SENDMAIL=true OVERRIDE_LINUX_BASE_PORT=f10 OVERRIDE_LINUX_NONBASE_PORTS=f10 PERL_VERSION=5.10.1 WITH_CUPS=YES WITH_GECKO=libxul WITHOUT_LPR=YES I can load reader.google.com without a problem. Note that I do not have any WITH_GECKO in my make.conf. Can't say whether that is the issue. However, if you mean by will never load, that you keep getting sent back to the log-in page, then I do see that if I have my local caching proxy server (wwwoffle) enabled. Turning it off allows me to log in. -- Gary Jennejohn ___ 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: Apache 22 - FreeBSD 8.0 - (httpd), uid 80: exited on signal 11
Hans F. Nordhaug wrote: I recently upgrade to FreeBSD 8.0 (from 7.2) and suddenly I get a lot of (httpd), uid 80: exited on signal 11 in my logs. I have similar problems with amavisd - see http://lists.freebsd.org/pipermail/freebsd-questions/2010-April/thread.html#215757 I'm have updated and recompiled all ports. The logs /var/log/messages and the httpd error log both just report exited on signal 11 or Segmentation fault (11) Any hints? Find the .core file, start gdb with the core file, type bt, post the output. Helmut -- No Swen today, my love has gone away My mailbox stands for lorn, a symbol of the dawn ___ 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: Grandfather dependencies completely out of control
On 02/05/2010 11:21, Koop Mast wrote: On Sat, 2010-05-01 at 23:09 -0700, Doug Barton wrote: I'm looking at the use of portmaster to upgrade perl versions, and noticed that there are a ton of ports listed as dependent on perl that don't have any use for it, including one of mine: qbittorrent-2.2.6 libnotify-0.4.5_3 atk-1.28.0 gio-fam-backend-2.22.4 gamin-0.1.10_3 glib-2.22.4 perl-threaded-5.8.9_3 Taking a look at devel/glib20, I see this: USE_PERL5= yes although from the docs in the glib tarball it's not at all clear (to me anyway) what it's used for. Given that it doesn't seem to be a rundep for glib20 it's also not at all clear to me why qbittorrent should have a pkgdep for it. Can someone please explain what the heck is going on here? (And please note, I'm picking on glib20 because this seems to be a particularly egregious example, but I'm really more interested in the problem generally.) One of the scripts provided by devel/glib20 is a perl script. That is the reason why we need perl. A solution in this instance would appear to be to split devel/glib20 into two ports, glib20 and a slave port glib20-scripts The former would need no (run) dependency on perl (or python), solving the chain problem Doug raises. The latter would have run dependencies on both languages, but would only (as far as I can tell) ever need to be a build dependency of dependent ports, again breaking the chain of run dependencies on a scripting languange. There is IMHO a separate issue (not applicable in this case) that all too many porters have used USE_PERL5 when USE_PERL5_BUILD would be sufficient. -- Thomas Sandford ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: firefox-3.6.3, 1 (trying to load certain pages causes the browser to hang then crash)
On Sun, May 2, 2010 at 07:00, Gary Jennejohn gljennj...@googlemail.com wrote: I can load reader.google.com without a problem. Note that I do not have any WITH_GECKO in my make.conf. Can't say whether that is the issue. However, if you mean by will never load, that you keep getting sent back to the log-in page, then I do see that if I have my local caching proxy server (wwwoffle) enabled. Turning it off allows me to log in. Nothing loads at all. It just remains on the current page and says something like connected to mail.google.com in the status bar and hangs for a minute or two then crashes/closes. Sometimes it seg. faults and other times it closes, but the processes are still running when I check with ps. Joey ___ 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: Apache 22 - FreeBSD 8.0 - (httpd), uid 80: exited on signal 11
* Helmut Schneider jumpe...@gmx.de [2010-05-02]: Hans F. Nordhaug wrote: I recently upgrade to FreeBSD 8.0 (from 7.2) and suddenly I get a lot of (httpd), uid 80: exited on signal 11 in my logs. I have similar problems with amavisd - see http://lists.freebsd.org/pipermail/freebsd-questions/2010-April/thread.html#215757 I'm have updated and recompiled all ports. The logs /var/log/messages and the httpd error log both just report exited on signal 11 or Segmentation fault (11) Any hints? Find the .core file, start gdb with the core file, type bt, post the output. Sorry, I should have mentioned that I can't find any core files. find / -name '*.core' returns nothing. Hans ___ 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/dri fails to build.
On May 2, 2010, at 5:30 AM, Robert Noland rnol...@freebsd.org wrote: On Sun, 2010-05-02 at 11:26 +0200, Demelier David wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=143723 It seems adding CFLAGS+=-march-=native solved the problem but I don't want to keep this flag everytime in my make.conf How this flag could solve the problem ? I can't understand. This actually stems from libdrm. Intel requires certain atomics that are not available on pure i386. They are present in code built for i486 +. The default cpu was changed to i486 some time . Should the port be marked broken with -march=i386 then? -Garrett ___ 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/dri fails to build.
On Sun, 2010-05-02 at 11:46 -0700, Garrett Cooper wrote: On May 2, 2010, at 5:30 AM, Robert Noland rnol...@freebsd.org wrote: On Sun, 2010-05-02 at 11:26 +0200, Demelier David wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=143723 It seems adding CFLAGS+=-march-=native solved the problem but I don't want to keep this flag everytime in my make.conf How this flag could solve the problem ? I can't understand. This actually stems from libdrm. Intel requires certain atomics that are not available on pure i386. They are present in code built for i486 +. The default cpu was changed to i486 some time . Should the port be marked broken with -march=i386 then? Well, I'm not sure quite how we would do that... but if your kernel/world is not really old, it should just work unless you force gcc to produce code that will run on i386. robert. -Garrett -- Robert Noland rnol...@freebsd.org FreeBSD ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Dixit port bad management
1) I don't understand why the Textproc/Dixit port is so badly managed. The program itself is at version 10.4, while your unprofessional port still stays at version 1.0.1, claiming that the GCC 4.2 compilation is broken. 2) I don't understand either why you don't use Dixit sourceforge RSS feeds to know when a new version is available. 3) I don't understand how your Dixit port points to files which don't exist anymore. 4) I don't understand the suprematism attitude of the maintainers in charge, who don't give a penny on the programs they are suppose to maintain. They are only interested in the statistics generated by their unprofessional ports, but not in their quality. Tim _ Videos that have everyone talking! Now also in HD! http://go.microsoft.com/?linkid=9724465___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] Xorg 7.5 merge comming tomorrow.
The CVS mirror I use apparently didn't get the Xorg 7.5 updates as of my daily update yesterday, but I seem to have the updates today, so I tried using portmaster -- largely with good success. Save for points when the wireless NIC on my laptop went flaky, it seems to have gone with but a single hitch: x11-drivers/xf86-input-hyperpen (xf86-input-hyperpen-1.3.0_2 - xf86-input-hyperpen-1.3.0_3) failed. The Maefile is at 1.7, updated 2010/05/01 11:40:32 miwi. After I completed everything else by excluding that port, I tried updating it once more; here's what happened: ... === Proceed? y/n [y] === Starting build for for ports that need updating === === Launching child to update xf86-input-hyperpen-1.3.0_2 ]0;portmaster: All xf86-input-hyperpen-1.3.0_2 (1/1) === Port directory: /usr/ports/x11-drivers/xf86-input-hyperpen === Starting check for build dependencies === Gathering dependency list for x11-drivers/xf86-input-hyperpen from ports === Starting dependency check === Dependency check complete for x11-drivers/xf86-input-hyperpen ]0;portmaster: All xf86-input-hyperpen-1.3.0_2 (1/1)=== Cleaning for xf86-input-hyperpen-1.3.0_3 === Vulnerability check disabled, database not found === Extracting for xf86-input-hyperpen-1.3.0_3 = MD5 Checksum OK for xorg/driver/xf86-input-hyperpen-1.3.0.tar.bz2. = SHA256 Checksum OK for xorg/driver/xf86-input-hyperpen-1.3.0.tar.bz2. === Patching for xf86-input-hyperpen-1.3.0_3 === xf86-input-hyperpen-1.3.0_3 depends on file: /usr/local/libdata/pkgconfig/randrproto.pc - found === xf86-input-hyperpen-1.3.0_3 depends on file: /usr/local/libdata/pkgconfig/inputproto.pc - found === xf86-input-hyperpen-1.3.0_3 depends on file: /usr/local/libdata/pkgconfig/xorg-server.pc - found === xf86-input-hyperpen-1.3.0_3 depends on file: /usr/local/libdata/pkgconfig/xproto.pc - found === xf86-input-hyperpen-1.3.0_3 depends on file: /usr/local/libdata/pkgconfig/xi.pc - found === xf86-input-hyperpen-1.3.0_3 depends on executable: pkg-config - found === Configuring for xf86-input-hyperpen-1.3.0_3 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i386-portbld-freebsd7.3 checking host system type... i386-portbld-freebsd7.3 checking for style of include used by make... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking dependency style of cc... gcc3 checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... cc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking how to run the C++ preprocessor... c++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... (cached) 262144 checking command to parse /usr/bin/nm -B output from cc object... ok checking for objdir... .libs
Re: GSoC: Making ports work with clang
Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. It crashes a lot, fails on many quite simple c++ patterns. Very immature. Don't you feel it's too early to start project like you are going to given the state of clang with c++? You will just keep stumbling upon various problems with various ports and maybe will make 30% of c++ ports build with it at best. Good - and those 30% of ports will help improve clang++ even more. Hopefully over time that number will increase to 100% and we will be able to say goodbye to gcc for good. ___ 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/dri fails to build.
On May 2, 2010, at 12:58 PM, Robert Noland wrote:
On Sun, 2010-05-02 at 11:46 -0700, Garrett Cooper wrote:
On May 2, 2010, at 5:30 AM, Robert Noland rnol...@freebsd.org wrote:
On Sun, 2010-05-02 at 11:26 +0200, Demelier David wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=143723
It seems adding CFLAGS+=-march-=native solved the problem but I
don't want to
keep this flag everytime in my make.conf
How this flag could solve the problem ? I can't understand.
This actually stems from libdrm. Intel requires certain atomics that
are not available on pure i386. They are present in code built for
i486
+. The default cpu was changed to i486 some time .
Should the port be marked broken with -march=i386 then?
Well, I'm not sure quite how we would do that... but if your
kernel/world is not really old, it should just work unless you force gcc
to produce code that will run on i386.
Something like this?
.if ${CPUTYPE} == i386 || ${ARCH} == i386 ${CPUTYPE} == native
BROKEN := this port requires i486+ CPU support
.endif
Can't protect against someone using the non-supported means of
compiling things and putting -m{arch,cpu,tune}=native in CFLAGS, et all.
Thanks,
-Garrett___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] Xorg 7.5 merge comming tomorrow.
It all seems to work, I'm running iceWM with the new Xorg version. However if I try and run the friendly xeyes I get a segfault which brings down the entire X server - not just xeyes.FreeBSD 8.0-RELEASE-p2 i386 ___ 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/dri fails to build.
On Sun, 2010-05-02 at 13:20 -0700, Garrett Cooper wrote:
On May 2, 2010, at 12:58 PM, Robert Noland wrote:
On Sun, 2010-05-02 at 11:46 -0700, Garrett Cooper wrote:
On May 2, 2010, at 5:30 AM, Robert Noland rnol...@freebsd.org wrote:
On Sun, 2010-05-02 at 11:26 +0200, Demelier David wrote:
http://www.freebsd.org/cgi/query-pr.cgi?pr=143723
It seems adding CFLAGS+=-march-=native solved the problem but I
don't want to
keep this flag everytime in my make.conf
How this flag could solve the problem ? I can't understand.
This actually stems from libdrm. Intel requires certain atomics that
are not available on pure i386. They are present in code built for
i486
+. The default cpu was changed to i486 some time .
Should the port be marked broken with -march=i386 then?
Well, I'm not sure quite how we would do that... but if your
kernel/world is not really old, it should just work unless you force gcc
to produce code that will run on i386.
Something like this?
.if ${CPUTYPE} == i386
This part might work.
|| ${ARCH} == i386 ${CPUTYPE} == native
${CPUTYPE} == native will work fine and long as you aren't on a real
i386. And I feel really sorry for anyone building X on a real i386.
robert.
BROKEN := this port requires i486+ CPU support
.endif
Can't protect against someone using the non-supported means of
compiling things and putting -m{arch,cpu,tune}=native in CFLAGS, et all.
Thanks,
-Garrett___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
--
Robert Noland rnol...@freebsd.org
FreeBSD
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Sun, 02 May 2010 10:25:22 +0300, Yuri y...@rawbw.com wrote: Having tried clang++ I have a feeling that it's not quite ready to be a generic c++ compiler. It crashes a lot, fails on many quite simple c++ patterns. The current state of clang doesn't bother me too much. I'm aware of its limitations, but I'm also aware of the pace of clang/llvm development. Trying clang at any given time is quite different than actually seeing it get better and better every week, for months. When llvm 2.6 was released, clang didn't compile C++ at all, and compared to that, what we have now is definitely better. I'm sure that by the end of the summer I'm going to call current version of clang/llvm horribly outdated, just like I've been calling any clang version which is over a month old. It will get better. Very immature. Many problems that C++ ports have with clang is not related to it being immature, they're related to the fact that clang isn't gcc and that those ports aren't written in standard C++. Don't you feel it's too early to start project like you are going to given the state of clang with c++? No I don't. My project doesn't rely on clang supporting all of C++. I just want to prepare ports tree for clang. I don't intend to make 21645+ ports work with clang over the summer, that may be slightly too much work even for me. So if I can't get KDE working, too bad, but let's wait until clang supports all the fancy C++ KDE needs and I'll just get it working then, even if that's after the summer is long over. You could say that the goal of this project is to make fixing ports+clang easier in the future. You will just keep stumbling upon various problems with various ports I've mentioned that I've been involved with ports+clang since last October. Stumbling upon various problems is what I do. I'm still here, even doing a GSoC project, so it doesn't look like various problems will scare me off. And as I've mentioned above, just because some ports don't compile, it doesn't affect this project too much. and maybe will make 30% of c++ ports build with it at best. [citation needed] -- Andrius ___ 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: GSoC: Making ports work with clang
On Sun, 02 May 2010 23:17:00 +0300, Eitan Adler eitanadlerl...@gmail.com wrote: Good - and those 30% of ports will help improve clang++ even more. Some probably will, we submit a lot of bug reports for clang/llvm. Hopefully over time that number will increase to 100% and we will be able to say goodbye to gcc for good. That won't happen, at least not anytime soon and not until we get rid of [old] poorly written ports from the ports tree. Another problem is ports using horrible or less horrible GNU extensions for C or C++, clang will not support all of them. So we will still need gcc for some things, just like we need USE_GCC=whatever now, because some ports don't compile with gcc42 from base. I just hope we can get the majority of ports working with clang and keep the number of ports that need gcc as low as possible. -- Andrius ___ 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: Dixit port bad management
On May 2, 2010, at 9:59 PM, Tim A wrote: 1) I don't understand why the Textproc/Dixit port is so badly managed. The program itself is at version 10.4, while your unprofessional port still stays at version 1.0.1, claiming that the GCC 4.2 compilation is broken. 2) I don't understand either why you don't use Dixit sourceforge RSS feeds to know when a new version is available. 3) I don't understand how your Dixit port points to files which don't exist anymore. 4) I don't understand the suprematism attitude of the maintainers in charge, who don't give a penny on the programs they are suppose to maintain. They are only interested in the statistics generated by their unprofessional ports, but not in their quality. Tim Dear Tim, Thank you for sending this email. As you might understand, people come and go on the project, things get fixed, imported, and left alone. But.. the great part of our community is.. you can help! I see that this is hurting you badly.. you can change this, you can help us upgrading the port, and making sure it entirely works. How about that? I invite you to become an active member of the community and help us to get proper support. Untill then, your email is noted and hopefully someone will have the time/motivation etc to fix this. Thank you for using FreeBSD! -- /\ Best regards,| re...@freebsd.org \ / Remko Lodder | re...@efnet Xhttp://www.evilcoder.org/| / \ ASCII Ribbon Campaign| Against HTML Mail and News ___ 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: Grandfather dependencies completely out of control
On 05/02/10 03:21, Koop Mast wrote: One of the scripts provided by devel/glib20 is a perl script. That is the reason why we need perl. Thanks for the response, couple things come to mind. First, how many things actually make use of those perl/python scripts? If the number is small they should probably be OPTIONS that default to off, or slave ports as Thomas suggested. Meanwhile, I still don't understand why qbittorrent needs a pkgdep on perl when it cannot use perl in any way, and will not be affected in any way if perl is updated, or disappears entirely. The glib dependency is 6 layers deep from qbittorrent, isn't this just a little silly? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
xf86-video-intel-2.7.1_2 problem
After a surprisingly smooth update Xorg-7.5 update (good job there) it's time for me to complain about a change in the intel driver. The driver suddenly seems to be hard-coded to come up with 96dpi. This is quite ridiculous as the driver perfectly knows the correct display size: LVDS connected 1440x900+0+0 (normal left inverted right x axis y axis) 304mm x 190mm 1440px / 304mm * 25.4(mm/) ~= 120dpi Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: GSoC: Making ports work with clang
On Sun 02 May 2010 at 14:03:06 PDT Andrius Mork??nas wrote: On Sun, 02 May 2010 23:17:00 +0300, Eitan Adler eitanadlerl...@gmail.com wrote: Good - and those 30% of ports will help improve clang++ even more. Some probably will, we submit a lot of bug reports for clang/llvm. Hopefully over time that number will increase to 100% and we will be able to say goodbye to gcc for good. That won't happen, at least not anytime soon and not until we get rid of [old] poorly written ports from the ports tree. Another problem is ports using horrible or less horrible GNU extensions for C or C++, clang will not support all of them. So we will still need gcc for some things, just like we need USE_GCC=whatever now, because some ports don't compile with gcc42 from base. I just hope we can get the majority of ports working with clang and keep the number of ports that need gcc as low as possible. As things stand today, we don't know exactly which ports have the kind of dependency on gcc that you describe. If this project gets us closer to that list, it will have been worthwhile. Once we know which ports are unavoidably dependent on gcc, we can start exploring alternatives to them. More projects for GSOC and others looking for ways to contribute! Sounds like fun! ___ 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: Grandfather dependencies completely out of control
On 5/2/10 5:19 PM, Doug Barton wrote: On 05/02/10 03:21, Koop Mast wrote: One of the scripts provided by devel/glib20 is a perl script. That is the reason why we need perl. Thanks for the response, couple things come to mind. First, how many things actually make use of those perl/python scripts? If the number is small they should probably be OPTIONS that default to off, or slave ports as Thomas suggested. The script (glib-mkenums) is actually very important to almost all ports which depend on glib. Yes, what Thomas suggested could be done with some considerable work. What might be better is to have someone versed in shell scripting translate this script to sh. I think the GNOME guys would be fine to accept that. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gn...@freebsd.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADS UP] Xorg 7.5 merge comming tomorrow.
On 05/02/10 13:17, David Wolfskill wrote: The CVS mirror I use apparently didn't get the Xorg 7.5 updates as of my daily update yesterday, but I seem to have the updates today, so I tried using portmaster -- largely with good success. That's good news. :) Save for points when the wireless NIC on my laptop went flaky, I did the following: 1. Upgrade ports tree 2. portmaster -Fa 3. portmaster --index -a And didn't have any problems. I don't have the hyperpen app installed though. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Grandfather dependencies completely out of control
On 05/02/10 15:28, Joe Marcus Clarke wrote: On 5/2/10 5:19 PM, Doug Barton wrote: On 05/02/10 03:21, Koop Mast wrote: One of the scripts provided by devel/glib20 is a perl script. That is the reason why we need perl. Thanks for the response, couple things come to mind. First, how many things actually make use of those perl/python scripts? If the number is small they should probably be OPTIONS that default to off, or slave ports as Thomas suggested. The script (glib-mkenums) is actually very important to almost all ports which depend on glib. Yes, what Thomas suggested could be done with some considerable work. What might be better is to have someone versed in shell scripting translate this script to sh. I think the GNOME guys would be fine to accept that. Please note that I'm not overwhelmingly interested in this particular case. I'm more concerned about the general problem of grandfather dependencies. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Testers wanted: ISC DHCP 4
I've prepared ports for the latest version of the DHCP suite from ISC. I'd appreciate people testing it out and letting me know if it works for them or not. I'm not able to test every configuration so I appreciate the help with this. It can be fetched and extracted with: fetch -o /tmp/dhcp41.shar http://people.freebsd.org/~wxs/dhcp41.shar cd /usr/ports sh /tmp/dhcp41.shar Please build the ports you wish and report back to me, privately, if you have any problems with them. I'd also appreciate reports of successes. Differences from isc-dhcp31-*: Server does not support jails. Client does not support polling. I still need to add proper CONFLICTS and eventually remove the unsupported versions from our tree. The CONFLICTS will be done before I commit these and removal of unsupported versions will be done in due time. -- 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
Re: Testers wanted: ISC DHCP 4
On Sun, May 02, 2010 at 10:36:54PM -0400, Wesley Shields wrote: I've prepared ports for the latest version of the DHCP suite from ISC. I'd appreciate people testing it out and letting me know if it works for them or not. I'm not able to test every configuration so I appreciate the help with this. It can be fetched and extracted with: fetch -o /tmp/dhcp41.shar http://people.freebsd.org/~wxs/dhcp41.shar cd /usr/ports sh /tmp/dhcp41.shar Make that cd /usr/ports/net -- 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
MD2 Dependency in FreeBSD 8.0 - OpenSSL 1.0.0 Needs MD2 enabled
This is obviously a workaround but... After updating ports (including security/openssl) on a FreeBSD 8-STABLE (Feb 25) system, I couldn't build net/samba33. This is what I saw... Linking bin/smbd /usr/lib/libhx509.so: undefined reference to `MD2_Init' /usr/lib/libhx509.so: undefined reference to `MD2_Final' /usr/lib/libhx509.so: undefined reference to `MD2_Update' gmake: *** [bin/smbd] Error 1 *** Error code 1 OpenSSL 1.0.0 does not include MD2 by default but does include a knob: MD2 Build with MD2 hash (obsolete) off If I re-build OpenSSL 1.0.0 with the obsolete MD2, then samba builds happily. Is there a better workaround until such time as the base system Heimdal is updated? -- John Marshall pgpZimLg0AePe.pgp Description: PGP signature
