Re: lang/perl5.10 doesn't build with gcc 4.5.1
On Sat, Jun 19, 2010 at 8:25 AM, b. f. bf1...@googlemail.com wrote:
lang/perl5.* fails with -fstack-protector in CFLAGS, when built with
the base system compiler, on some architectures. I used the attached
patch with the base system compiler and lang/perl5.10 on 9-CURRENT
i386 to fix the problem. However, I never attempted to use it with
lang/gcc45, because I did not want to introduce circular dependencies
in my ports. Your problem may be related.
This patch's logic is inverted:
$ make -f Makefile.cflags_test
-fstack-protector -fstack-protector-all
$ cat Makefile.cflags_test
CFLAGS+=-fstack-protector -fstack-protector-all -funroll-loops
all:
@echo ${CFLAGS:M-fstack-protector*}
I think you wanted :N...
HTH,
-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: lang/perl5.10 doesn't build with gcc 4.5.1
On Mon, 21 Jun 2010, Garrett Cooper wrote: This patch's logic is inverted: Doesn't matter, ports Makefile fu isn't going to get the job done to remove -fstack-protector, see my post tonight about this. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/thunderbird3 does not build with gcc 4.5.1
Doug Barton wrote: On to the next victim. :) In my ongoing campaign to build my ports with gcc 4.5.1 thunderbird was the next to fall. Full log is at http://people.freebsd.org/~dougb/tbird.txt Before you embark on this campaign, remember that others have been experimenting with building ports with later versions of gcc for months or even years now, and there are suggestions on how to solve some of the problems that arise in the FreeBSD forums and in the open PRs. This particular set of problems can probably be solved via patches similar to those in: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/142736 where some other mozilla ports are discussed. b. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/thunderbird3 does not build with gcc 4.5.1
On 06/21/10 23:25, b. f. wrote: Doug Barton wrote: On to the next victim. :) In my ongoing campaign to build my ports with gcc 4.5.1 thunderbird was the next to fall. Full log is at http://people.freebsd.org/~dougb/tbird.txt Before you embark on this campaign, remember that others have been experimenting with building ports with later versions of gcc for months or even years now, and there are suggestions on how to solve some of the problems that arise in the FreeBSD forums and in the open PRs. I certainly mean no disrespect to those who've already been working on this problem. I'm really interested in the idea of having a ports compiler, and I'm trying to do what I can from more of a typical user perspective. If bringing more visibility to the issue helps get more ports fixed, that's a good thing, right? (I'm also trying to fix _my_ ports as I go along as well.) The ultimate goal (in my mind anyway) would be for both src AND ports to be in better shape to be compiler agnostic so that newer versions of gcc, clang, or whatever else can be more of a drop-in replacement. I'm not naive enough to think that it will be easy, or even 100% possible. But the more things we _can_ fix the better. This particular set of problems can probably be solved via patches similar to those in: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/142736 where some other mozilla ports are discussed. Hopefully the gecko@ team is listening. :) 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: mail/thunderbird3 does not build with gcc 4.5.1
On 22.06.2010 09:23, Doug Barton wrote: On 06/21/10 23:25, b. f. wrote: Doug Barton wrote: On to the next victim. :) In my ongoing campaign to build my ports with gcc 4.5.1 thunderbird was the next to fall. Full log is at http://people.freebsd.org/~dougb/tbird.txt Before you embark on this campaign, remember that others have been experimenting with building ports with later versions of gcc for months or even years now, and there are suggestions on how to solve some of the problems that arise in the FreeBSD forums and in the open PRs. I certainly mean no disrespect to those who've already been working on this problem. I'm really interested in the idea of having a ports compiler, and I'm trying to do what I can from more of a typical user perspective. If bringing more visibility to the issue helps get more ports fixed, that's a good thing, right? (I'm also trying to fix _my_ ports as I go along as well.) The ultimate goal (in my mind anyway) would be for both src AND ports to be in better shape to be compiler agnostic so that newer versions of gcc, clang, or whatever else can be more of a drop-in replacement. I'm not naive enough to think that it will be easy, or even 100% possible. But the more things we _can_ fix the better. This particular set of problems can probably be solved via patches similar to those in: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=ports/142736 where some other mozilla ports are discussed. Hopefully the gecko@ team is listening. :) Sure :) This is on our TODO list: http://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO But our man power is very limited and we'd like to cleanup/remove old gecko ports and update libxul first. 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: mail/thunderbird3 does not build with gcc 4.5.1
On 06/22/10 00:46, Beat Gaetzi wrote: Sure :) This is on our TODO list: http://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO But our man power is very limited and we'd like to cleanup/remove old gecko ports and update libxul first. Awesome, thanks for replying! So far 3.0.5 compiled with the base compiler is working just fine. 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: [freebsd] pecl-imagick - Segmentation fault: 11 (core dumped) on php -i under freebsd 7.3
Hello, On Sun, 2009-05-24 at 11:07 +0300, Andrey Slusar wrote: Current version (under 7.2) seems to crash with a Segmentation fault: 11 (core dumped) with php 5.2.9, and in some bug reports I saw that the problem doesn't occur anymore with pecl-imagick 2.2.2 (stable) or 2.3.x (beta) ( http://pecl.php.net/package/imagick ). Updated to 2.2.2 Thanks for your updates :) But at the moment, it seems to be broken again, and I can't find why. Problem: [...@pandora ~]$ php -v -c /usr/local/etc/php.ini-production PHP 5.3.2 with Suhosin-Patch (cli) (built: Jun 14 2010 18:11:48) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies Segmentation fault: 11 (core dumped) If I comment the line extension=imagick.so in /usr/local/etc/php/extensions.ini , it works fine (but without imagick then...). I tried recompiling about nearly all related packages (png, imagemagick, php, etc.), but it didn't helped. Same if I comment some other extensions (like pdf.so, etc.). All packages are 100% uptodate, as well as the OS (7.3-RELEASE-p1 amd64), but it was previously a 7.2 system, so this may have an influence. Is anybody using pecl-imagick without this segfault at the moment? Or do you have any suggestion about what I could try? I will setup a blank 7.3 system as a VM later this week to test by myself Thanks regards, Olivier PS: some files infos: 1) /usr/local/etc/php/extensions.ini extension=imap.so extension=openssl.so extension=zip.so extension=ftp.so extension=sqlite.so extension=ctype.so extension=json.so extension=zlib.so extension=gettext.so extension=filter.so extension=tidy.so extension=mysql.so extension=mcrypt.so extension=hash.so extension=mbstring.so extension=tokenizer.so extension=dom.so extension=xmlreader.so extension=bz2.so extension=iconv.so extension=simplexml.so extension=pdo.so extension=xml.so extension=xsl.so extension=pdo_sqlite.so extension=pdo_mysql.so extension=curl.so extension=mssql.so extension=mysqli.so extension=session.so extension=soap.so extension=wddx.so extension=memcache.so extension=gd.so extension=pdf.so extension=imagick.so 2) pkg_info |grep -i -e pecl -e php pear-1.9.0 PEAR framework for PHP pecl-imagick-3.0.0.r1 Provides a wrapper to the ImageMagick/GraphicsMagick librar pecl-memcache-3.0.4 Memcached extension pecl-pdflib-2.1.8 A PECL extension to create PDF on the fly php5-5.3.2_1PHP Scripting Language php5-bz2-5.3.2_1The bz2 shared extension for php php5-ctype-5.3.2_1 The ctype shared extension for php php5-curl-5.3.2_1 The curl shared extension for php php5-dom-5.3.2_1The dom shared extension for php php5-filter-5.3.2_1 The filter shared extension for php php5-ftp-5.3.2_1The ftp shared extension for php php5-gd-5.3.2_1 The gd shared extension for php php5-gettext-5.3.2_1 The gettext shared extension for php php5-hash-5.3.2_1 The hash shared extension for php php5-iconv-5.3.2_1 The iconv shared extension for php php5-imap-5.3.2_1 The imap shared extension for php php5-json-5.3.2_1 The json shared extension for php php5-mbstring-5.3.2_1 The mbstring shared extension for php php5-mcrypt-5.3.2_1 The mcrypt shared extension for php php5-mssql-5.3.2_1 The mssql shared extension for php php5-mysql-5.3.2_1 The mysql shared extension for php php5-mysqli-5.3.2_1 The mysqli shared extension for php php5-openssl-5.3.2_1 The openssl shared extension for php php5-pdo-5.3.2_1The pdo shared extension for php php5-pdo_mysql-5.3.2_1 The pdo_mysql shared extension for php php5-pdo_sqlite-5.3.2_1 The pdo_sqlite shared extension for php php5-session-5.3.2_1 The session shared extension for php php5-simplexml-5.3.2_1 The simplexml shared extension for php php5-soap-5.3.2_1 The soap shared extension for php php5-sqlite-5.3.2_1 The sqlite shared extension for php php5-tidy-5.3.2_1 The tidy shared extension for php php5-tokenizer-5.3.2_1 The tokenizer shared extension for php php5-wddx-5.3.2_1 The wddx shared extension for php php5-xml-5.3.2_1The xml shared extension for php php5-xmlreader-5.3.2_1 The xmlreader shared extension for php php5-xsl-5.3.2_1The xsl shared extension for php php5-zip-5.3.2_1The zip shared extension for php php5-zlib-5.3.2_1 The zlib shared extension for php phpMyAdmin-3.3.3A set of PHP-scripts to manage MySQL over the web phpSysInfo-3.0.r9_1 A PHP script for displaying system information 3) uname -a FreeBSD pandora 7.3-RELEASE-p1 FreeBSD 7.3-RELEASE-p1 #0: Tue May 25 19:23:41 UTC 2010 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 4) php -i shows: [...] imagick imagick module = enabled imagick module version = 3.0.0RC1 imagick classes = Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator ImageMagick version = ImageMagick 6.6.1-10 2010-06-22 Q16 http://www.imagemagick.org ImageMagick copyright = Copyright (C) 1999-2010 ImageMagick Studio LLC ImageMagick release date = 2010-06-22 [...]
Re: FreeBSD ports USE_XZ critical issue on low-RAM computers
On 2010-06-20 Matthias Andree wrote: $ export XZ_OPT=-9 $ export XZ_OPT_OVERRIDES=-M40% $ xz -Mmax blah.tar would result in the same behaviour as: $ xz -9 -M40% blah.tar # here, the XZ_OPT_OVERRIDES cancels -Mmax from command line and could mean: xz trying -9, but lowering that as necessary to meet the -M40% limit. This or a config file should solve the problem that removing the default memory usage limit would create for me and some other people -- at least as long we remember to add the environment variable or config file on each system. ;-) Environment variable could be easier than a config file. Adding support for it is almost a trivial change to the code, and it is easier to use it per-command basis if needed for some reason. It's still possible that applications using liblzma will use too high settings on low-memory systems, but so far I haven't seen such problems in real-world situations like I have with scripts that use the xz tool. So at least for now there's no need to think about controlling liblzma e.g. via an environment variable, and hopefully it will never be needed. Environment variables with a big banner don't XZ_OPT_OVERRIDES use in scripts, it is reserved for the user might work. Then everybody can complain to the script author if it touches XZ_OPT_OVERRIDES. I'm sure it will work. Sure, it cannot fully parallelize, whatever that means. But the amount of parallelization that is possible is welcomed by many others (you are the very first person to think it's useless). For example, 7-Zip can use any number of threads with .xz files and there are some liblzma-based experimental tools too. Fully parallelizable means neglible overhead on the algorithmic side, i. e. near 100% speedup with each new processor added (considering Amdahl's law and later refinements). If compressing position 20-40MB in a file depends on the outcome of compressing positions 0-20MB, the task is not parallelizable at all. If two threads manage 140% of throughput of one, it's not fully parallelizable. OK, so it's fully parallizable only with a simple method that splits the uncompressed data into chunks that are compressed independently. This can decrease compression ratio, but often not too much if chunk size is big enough. Definition of too much naturally depends on the specific use case. There are non-fully parallizable ways too with their own advantages and disadvantages. In the long term there will probably be a few different threading methods in liblzma. Next question could be how to determine how many threads could be OK for multithreaded decompression. It doesn't fully parallelize either, and would be possible only in certain situations. There too the memory usage grows quickly when threads are added. To me, a memory usage limit together with a limit on number of threads looks good; with no limits, the decompressor could end up reading the whole file into RAM (and swap). Threaded decompression isn't so important though, so I'm not even sure if I will ever implement it. The easy answer for you is a -j N option like make's, with a default of 1. Since threads share their address space, the --memory option can easily be interpreted either way: overall or per-thread. My above description was not good. See my previous email and how a default limit could be useful here even if single-threaded operation should have no limits by default. I'd like to avoid this discussion though with the large audiences of ports@ and portmgr@ involved. Feel free to adjust the recipient list. I think for adoption in infrastructure, we need consistency across all computers before all else. I can understand that. For me it is important that if the _default_ memory usage limit is thrown away, there needs to be something else to solve the problems that the default memory usage limit was designed to fix. I have got some useful ideas from this discussion, thanks to you and others commenting this thread. I will remove the default limit and probably add support for another environment variable. Hopefully this will make most people somewhat happy. I'm sorry about the hassle that this issue has created. The dictionary size is only one thing to get high compression. It depends on the file. Some files benefit a lot when dictionary size increases while others benefit mostly from spending more CPU cycles. That's why there is the --extreme option. It allows improving the compression ratio by spending more time without requiring so much RAM. The manpages states factor of two, which barely qualifies as extreme in my eyes. extreme would be an order of magnitude (10x). The option name isn't the greatest, I'm generally bad at naming things. Time increase with xz -2e is around 10x compared to xz -2, because it turns a fast mode into slow mode without increasing the dictionary size. With xz -6 and xz -6e the speed difference is not
Re: Unable to update/build security/gpa
On Monday, June 21, 2010 15:07:38 Doug Barton wrote: On 06/20/10 09:30, Jason E. Hale wrote: On Sunday, June 20, 2010 06:55:52 you wrote: FreeBSD-PRERELEASE 8.1 amd64 Since the release of libassuan-2.0.0, I have not been able to update or reinstall security/GPA. All of the other ports appear to build fine. Jerry, I'm sorry to hear that you're having problems. At this time if you want to use gpa the only alternative is to use gnupg 1.x. I realize that's not necessarily an attractive alternative, but see below. GPA won't work with gnupg 1.x. It requires gpgsm which is only provided by gnupg 2.x. I have submitted a PR to make GPA work with libassuan 2.x. I have also submitted a PR for the latest version of GPGME which is also required. GPGME: http://www.freebsd.org/cgi/query-pr.cgi?pr=148061 GPA: http://www.freebsd.org/cgi/query-pr.cgi?pr=148062 I know all too well. Unfortunately a committer made a hasty move and updated libassuan to version 2.0.0 and then made gnupg 2.x use the newer libassuan. Jason, It wasn't hasty. My first public message to maintainers of affected ports went out on May 11th. According to this message on May 12th you seemed quite optimistic that you would be able to deal with gpa, and actually gave some helpful information on some of the other ports as well, which I appreciated. http://mail.kde.org/pipermail/kde-freebsd/2010-May/008334.html In subsequent messages I agreed with your suggestion that handling everything at once was the best option, however after repeated prompting neither you, nor any of the other maintainers came forward with patches to accomplish that. Due to a bug in gnupg 2.0.14 (albeit a minor one) I thought it was important to move forward with the upgrade prior to 8.1-RELEASE. FWIW, I agree that the situation with libassuan 2.x being incompatible with 1.x is not ideal, but it's not something I have any control over. The authors of the software made that choice, and the theory is that the benefits outweigh the costs. I hope they are right. :) I couldn't really do anything with my ports until their dependencies were updated first (which you have done). I would have liked to have gotten the updated ports for the dependencies ahead of time so I could tackle my ports before they broke. As a KDE user, I also didn't want to see kdepim4 lose functionality. However, seeing how the gnupg developers saw fit to release all of their software in reverse dependency order, I guess a few small sacrifices are acceptable. This of course turns into a chain of conflicts because everything else that depends on libassuan 1.x usually needs gnupg 2.x as well. Anything that depends on gnupg 2.x will also work with 1.x as it applies to strict gnupg functionality. Once again, I realize that this is not necessarily the most desirable option, however it _does_ leave the users with a path. It's probably also worth pointing that out of the 3 remaining ports that need to be fixed, kdepim will be fixed in the next release, and the kde folks have already committed to dealing with it. In opensc the dependency is optional, and the feature that depends on it will be removed in the next version anyway. I am working to resolve the situation for my ports, Do you have ports other than gpa that are affected by this change? however, the author of gpa has not released a version that will work with libassuan 2.x. I asked Werner about this, and unfortunately it's not likely that he will be able to cut a new release of gpa prior to our 8.1-RELEASE. Are you still optimistic about using what's in their source tree to produce a patch for libassuan 2.x compatibility? I downloaded their tree but haven't had time to look at it much since I've had other urgent issues to handle. There is a ports freeze now too, so I am not sure if my updates will even go through for a while. Just in case I haven't been clear, if you get a patch for gpa I will commit it. Making it work with libassuan 2.0.0 definitely falls into the category of what's acceptable to commit during the slush. Thanks, the PR links are above. I CC'd you as well. If you really need to use gpa immediately, I suggest downgrading everything that depended on libassuan 2.x to use libassuan 1.x. At this point the only thing that depends on it is gnupg 2.x (and dirmngr, but the only thing that depends on it is gnupg 2.x). hth, Doug Regards, Jason ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/thunderbird3 does not build with gcc 4.5.1
On 6/22/10, Doug Barton do...@freebsd.org wrote: On 06/21/10 23:25, b. f. wrote: Doug Barton wrote: On to the next victim. :) In my ongoing campaign to build my ports with gcc 4.5.1 thunderbird was the next to fall. Full log is at http://people.freebsd.org/~dougb/tbird.txt Before you embark on this campaign, remember that others have been experimenting with building ports with later versions of gcc for months or even years now, and there are suggestions on how to solve some of the problems that arise in the FreeBSD forums and in the open PRs. I certainly mean no disrespect to those who've already been working on this problem. I'm really interested in the idea of having a ports compiler, and I'm trying to do what I can from more of a typical user perspective. If bringing more visibility to the issue helps get more ports fixed, that's a good thing, right? (I'm also trying to fix _my_ ports as I go along as well.) The ultimate goal (in my mind anyway) would be for both src AND ports to be in better shape to be compiler agnostic so that newer versions of gcc, clang, or whatever else can be more of a drop-in replacement. I'm not naive enough to think that it will be easy, or even 100% possible. But the more things we _can_ fix the better. Yes, of course. I didn't mean to suggest that I thought you were being disrespectful, but only to let you know that you may solve some of these problems more quickly by skimming through the open PRs, mailing lists archives, and forum listings first. Also, because many GNU/Linux distros, NetBSD, and DragonflyBSD have switched to later versions of gcc and/or binutils than we have in our base system, other packaging systems (especially Red Hat Fedora's Rawhide packages, Gentoo Portage, and NetBSD pkgsrc) may have relevant patches, especially for older software. Also, http://gcc.gnu.org/gcc-4.3/porting_to.html http://gcc.gnu.org/gcc-4.4/porting_to.html http://gcc.gnu.org/gcc-4.3/changes.html http://gcc.gnu.org/gcc-4.4/changes.html http://gcc.gnu.org/gcc-4.5/changes.html http://gcc.gnu.org/gcc-4.6/changes.html provide useful hints for some problems related to re-factoring of compiler headers, and changes in compiler defaults (those for earlier versions of gcc than the one you have mentioned may contain information that is also applicable to 4.5 and 4.6). I think it would be good if someone posted tinderbox results for exp-runs of ports built with the latest stable branch of gcc, and with clang, to show which ports need to be patched. Perhaps that fellow who has a GSoC project to make it possible to use clang with the Ports system may be willing to do this, at least for clang. I can tell you right now from my own experiences that the ports infrastructure and many individual ports do not respect the necessary compiler and toolchain-related variables. b. ___ 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
net-snmp unusable after upgrade to 5.5
Hello! Yesterday I upgraded net-snmp in about ten servers. After the upgrade net-snmp doesn't accept connections (in FreeBSD 7.3) or won't even start (in FreeBSD 6.4). FreeBSD 7.3-RELEASE === net-snmp upgraded to 5.5 with portmaster using source. All configuration unchanged. $ cat /var/db/ports/net-snmp/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for net-snmp-5.4.2.1_6 _OPTIONS_READ=net-snmp-5.4.2.1_6 WITH_IPV6=true WITHOUT_MFD_REWRITES=true WITH_PERL=true WITH_PERL_EMBEDDED=true WITHOUT_TKMIB=true WITH_DUMMY=true WITHOUT_DMALLOC=true $ cat /var/log/snmpd.log NET-SNMP version 5.5 Connection from UDP: [x.x.x.x]:57497-[0.0.0.0] REFUSED Connection from UDP: [x.x.x.x]:57497-[0.0.0.0] REFUSED Connection from UDP: [x.x.x.x]:57497-[0.0.0.0] REFUSED $ grep snmp /etc/hosts.allow snmpd : x.x.x.x : allow $ cat /usr/local/share/snmp/snmpd.conf syslocation xxx rocommunity xxx x.x.x.x $ ps auxwww|grep snmp root 69517 0,0 0,5 9416 4772 ?? S 1:26pm 0:01,04 /usr/local/sbin/snmpd -c /usr/local/share/snmp/snmpd.conf -p /var/run/snmpd.pid -a This worked fine with previous versions of net-snmp. (I added snmpd_conffile to rc.conf as a test today, previously I didn't use that parameter.) FreeBSD 6.4-RELEASE-p9 == net-snmp upgraded to 5.5 with portmaster using source. All configuration unchanged. $ cat /var/db/ports/net-snmp/options # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for net-snmp-5.4.2.1_5 _OPTIONS_READ=net-snmp-5.4.2.1_5 WITH_IPV6=true WITHOUT_MFD_REWRITES=true WITH_PERL=true WITH_PERL_EMBEDDED=true WITHOUT_TKMIB=true WITH_DUMMY=true WITHOUT_DMALLOC=true $ /usr/local/etc/rc.d/snmpd start Starting snmpd. /libexec/ld-elf.so.1: Shared object libperl.so not found, required by libnetsnmphelpers.so.20 $ ldd /usr/local/lib/libnetsnmphelpers.so.20 /usr/local/lib/libnetsnmphelpers.so.20: libnetsnmpagent.so.20 = /usr/local/lib/libnetsnmpagent.so.20 (0x28182000) libwrap.so.4 = /usr/lib/libwrap.so.4 (0x281c1000) libperl.so = not found (0x0) libcrypt.so.3 = /lib/libcrypt.so.3 (0x281c8000) libutil.so.5 = /lib/libutil.so.5 (0x281e) libnetsnmp.so.20 = /usr/local/lib/libnetsnmp.so.20 (0x281ec000) libcrypto.so.4 = /lib/libcrypto.so.4 (0x28291000) libm.so.4 = /lib/libm.so.4 (0x28384000) libkvm.so.3 = /lib/libkvm.so.3 (0x2839a000) libdevstat.so.5 = /lib/libdevstat.so.5 (0x283a1000) libperl.so = /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so (0x283a6000) $ l /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so -r-xr-xr-x 1 root wheel 1161691 22 Jun 11:25 /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so $ file /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so /usr/local/lib/perl5/5.8.9/mach/CORE/libperl.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked, not stripped I tried rebuilding all ports in one of the 6.4 servers, and then reboot, but that didn't help. Here is the port list from this 6.4 server: aespipe-v2.3.e = up-to-date with port ca_root_nss-3.12.4 = up-to-date with port curl-7.20.1 = up-to-date with port gettext-0.18_1 = up-to-date with port gnupg-2.0.15= up-to-date with port libassuan-2.0.0 = up-to-date with port libgcrypt-1.4.5 = up-to-date with port libgpg-error-1.7_1 = up-to-date with port libiconv-1.13.1_1 = up-to-date with port libksba-1.0.7 = up-to-date with port libol-0.3.18= up-to-date with port nbsmtp-1.00 = up-to-date with port net-snmp-5.5= up-to-date with port perl-5.8.9_3= up-to-date with port portmaster-2.32 = up-to-date with port pth-2.0.7 = up-to-date with port sendmail-8.14.4_2 = up-to-date with port sudo-1.7.2.7= up-to-date with port syslog-ng-1.6.12_1 = up-to-date with port yafic-1.2.2 = up-to-date with port I have searched the list archives back through March, but find nothing relevant there or with Google. Thanks! -- Peter Olssonp...@leissner.se ___ 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
stellarium crashes on 9.0-CURRENT
For some weeks now I am not able to start astro/stellarium (versions 10.3 and 10.5) any more. Immediately after starting I only get a core dump, nothing else. It seems like this behaviour appeared after the latest update of KDE / QT. I am running recent 9.0-CURRENT (amd64) with x11/nvidia-driver. Other OpenGL programs like astro/celestia and astro/openunivers work like a charm. Looking at the core dump with gdb gives me the following output (btw. it seems to be difficult to build stellarium with debugging symbols, any hints?): (gdb) core stellarium.core warning: exec file is newer than core file. Core was generated by `stellarium'. Program terminated with signal 11, Segmentation fault. Symbols already loaded for /usr/local/lib/qt4/libQtOpenGL.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtScript.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtGui.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtSql.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtNetwork.so.4 Symbols already loaded for /usr/local/lib/qt4/libQtCore.so.4 Symbols already loaded for /usr/local/lib/libGLU.so.1 Symbols already loaded for /usr/local/lib/libGL.so.1 Symbols already loaded for /usr/local/lib/libSM.so.6 Symbols already loaded for /usr/local/lib/libICE.so.6 Symbols already loaded for /usr/local/lib/libX11.so.6 Symbols already loaded for /usr/local/lib/libXext.so.6 Symbols already loaded for /usr/local/lib/libiconv.so.3 Symbols already loaded for /usr/local/lib/libintl.so.9 Symbols already loaded for /lib/libz.so.6 Symbols already loaded for /usr/lib/libstdc++.so.6 Symbols already loaded for /lib/libm.so.5 Symbols already loaded for /lib/libgcc_s.so.1 Symbols already loaded for /lib/libc.so.7 Symbols already loaded for /usr/local/lib/libfreetype.so.9 Symbols already loaded for /usr/local/lib/libXrender.so.1 Symbols already loaded for /usr/local/lib/libfontconfig.so.1 Symbols already loaded for /lib/libthr.so.3 Symbols already loaded for /usr/local/lib/libgthread-2.0.so.0 Symbols already loaded for /usr/local/lib/libglib-2.0.so.0 Symbols already loaded for /usr/local/lib/libpng.so.6 Symbols already loaded for /usr/local/lib/libnvidia-tls.so.1 Symbols already loaded for /usr/local/lib/libGLcore.so.1 Symbols already loaded for /usr/local/lib/libxcb.so.2 Symbols already loaded for /usr/local/lib/libXau.so.6 Symbols already loaded for /usr/local/lib/libXdmcp.so.6 Symbols already loaded for /usr/local/lib/libpthread-stubs.so.0 Symbols already loaded for /usr/lib/librpcsvc.so.5 Symbols already loaded for /usr/local/lib/libexpat.so.6 Symbols already loaded for /usr/local/lib/libicui18n.so.38 Symbols already loaded for /usr/local/lib/libpcre.so.0 Symbols already loaded for /usr/local/lib/libicuuc.so.38 Symbols already loaded for /usr/local/lib/libicudata.so.38 Symbols already loaded for /libexec/ld-elf.so.1 #0 0x4271b143 in glXCreateWindow () from /usr/local/lib/libGL.so.1 This looks like a problem with OpenGL (QT / NVidia?). I have no clue what to do next ... Any help is really appreciated. Thanks in advance, Rainer Hurling ___ 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: Who to bug to commit some ports?
I recently submitted some PRs for updates and new ports and would like to know whom to ask for them to be committed. Yes, I know, I can try to bug some ports committers using e-mail 8-), but if possible, I would like to avoid this 8-) It's approx. 8 days later, and the ports are still not committed. I'm aware there's something like a ports freeze (not a full freeze, only a 'major upgrade freeze'. What are my options ? In the Porter's Handbook documentation it advises that review/acceptance of new ports can take anywhere from a few days to two months. It may seem like a long time, but the Port people do have a lot of these requests to go through. We should probably just sit tight and wait. I'm sure they'll get through them all sooner or later. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mail/thunderbird3 does not build with gcc 4.5.1
On Tue, Jun 22, 2010 at 1:04 AM, Doug Barton do...@freebsd.org wrote: Howdy, On to the next victim. :) In my ongoing campaign to build my ports with gcc 4.5.1 thunderbird was the next to fall. Full log is at http://people.freebsd.org/~dougb/tbird.txt I've been doing the same thing but with lang/gcc46. Here are the ports that currently fail for me devel/llvm* develclang devel/icu devel/libexecinfo devel/gobject-introspection www/firefox* www/libxul lang/perl* irc/xchat Maybe it would be a good idea to make a wiki page with a table for which ports fail with which compilers? -- Eitan Adler ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: pecl-oauth-0.99.5
Hi. Can anyone tell when the port will be upgraded to 1.0.0 (stable) http://pecl.php.net/package/oauth/ -- Regards Carsten Jonstrup Webudvikler c...@folia.dk ___ 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
commit PR ports/146582: [PATCH]textproc/libxml2
Hello! Can anybody commit this http://www.freebsd.org/cgi/query-pr.cgi?pr=146582? Thanks a lot. -- Alexander Kriventsov ___ 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: commit PR ports/146582: [PATCH]textproc/libxml2
On 22 June 2010 15:21, Alexander Kriventsov a...@vl.ru wrote: Hello! Can anybody commit this http://www.freebsd.org/cgi/query-pr.cgi?pr=146582? You need to ask the Gnome team to approve it first. Chris ___ 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
GSoC: Ports and clang: PORTS_CC
Hi list,
One of the things I've been working on for the past few weeks is
creating an easy way to change ports compiler without breaking things
that shouldn't break just because compiler changed. Some of the
current problems are mentioned on the wiki page[1]. Something not
mentioned there is that it is difficult to set compiler only for ports
and not for base system/everything else.
I've implemented PORTS_CC, which, at the moment, properly handles all
versions of GCC in ports and clang. Another new thing is USE_CC, which
does very similar job to USE_GCC, but also works for clang.
Valid values for PORTS_CC are gcc, gccXY and clang. Everything else is
mostly unhandled and just does CC=${PORTS_CC} CXX=${PORTS_CXX}. If
PORTS_CC is set to some version of gcc or clang, PORTS_CXX isn't used
and CXX is set automatically.
What is USE_CC:
USE_CC=gcc4.2+ does exactly the same thing as USE_GCC=4.2+, not really
interesting. USE_CC=clang forces the port to use clang. More interesting
is USE_CC=gcc4.4 clang - if PORTS_CC is set to some version of gcc,
use gcc44, if PORTS_CC is set to clang, use clang. Another thing to note
is that USE_{CC,GCC} don't unconditionally override the compiler, for
example if PORTS_CC=gcc45 and USE_GCC=4.4+, gcc45 will be used, because
USE_GCC allows higher versions. USE_CC=gcc is a bit special, if gcc
version is not specified, port will use gcc from base system.
Since I'm testing ports with clang, I don't always want ports to respect
USE_GCC, that's why I've added NO_USE_CC. When defined, it forces
USE_GCC and USE_CC to be ignored.
One of the problems that I haven't solved yet is that ports never had to
care about the compiler, it was just there. That's why now there's no I
want to use gcc45 as my ports compiler, so install it switch. Adding
build depend is tricky because of recursive dependencies. I do have some
ideas how to fix it, but I haven't tested them yet.
If you want to try this, download bsd.*.mk files[2] (diffs are here[3]),
put them in /usr/ports/Mk/, put PORTS_CC=gcc44 (or whatever you want) in
make.conf, pray a little and try to build some ports. If you don't put
anything in make.conf, gcc from base will be used. PORTS_CC will ignore
any CC/CXX magic you have in make.conf.
If you're feeling adventurous, you can try building ports with clang:
Put PORTS_CC=clang to make.conf, apply all the patches[4] for ports,
rebuild devel/libtool22, pray even more than before, and try to build
stuff. Just remember that THINGS WILL BREAK, many ports don't compile
with clang yet. As a workaround, you can put USE_CC=gcc in port's
makefile to build it with gcc instead of clang. Don't report broken
ports unless clang miscompiles something. If something goes wrong you
can always do portsnap extract to clean the ports tree.
If you have suggestions how to improve something, questions or some
other feedback, I'm listening.
[1] http://wiki.freebsd.org/SOC2010AndriusMorkunas
[2] http://rainbow-runner.nl/~andrius/soc/ports/Mk/
[3] http://rainbow-runner.nl/~andrius/soc/patches/
[4] http://rainbow-runner.nl/clang/patches/
--
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: mail/thunderbird3 does not build with gcc 4.5.1
On Tue, 22 Jun 2010, b. f. wrote: I can tell you right now from my own experiences that the ports infrastructure and many individual ports do not respect the necessary compiler and toolchain-related variables. Part of this problem is that the Porters Handbook only tells porters to respect CC, CXX and CFLAGS, nothing else. This issue came up as well in the Building ports with stack-protector thread a couple of weeks ago (by yourself). What would be the comprehensive list of variables to respect? There are already quite many from the top of my head: CC CFLAGS CXX CXXFLAGS CPP CPPFLAGS LD LDFLAGS AS AFLAGS AR ARFLAGS RANLIB INSTALL OBJCOPY Some of the above would generally be required to be respected only when cross-compiling to an another architecture. I have been thinking of making a test build of all ports with some useless options in relevant variables and capturing output or doing ktrace to figure out which ports respect those flags and which do not. Haven't gotten around to actually doing it just yet :). Another work-around would be to make a directory containing wrapper-shell-scripts with the names like cc, gcc, ld, cpp etc. and make them invoke the desired tools with desired flags. That directory would be placed in the beginning of PATH before compiling ports. This would be a quicker alternative to patching lots of ports. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.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: mail/thunderbird3 does not build with gcc 4.5.1
On 6/22/10, Janne Snabb sn...@epipe.com wrote: On Tue, 22 Jun 2010, b. f. wrote: I can tell you right now from my own experiences that the ports infrastructure and many individual ports do not respect the necessary compiler and toolchain-related variables. I should say that a few simple changes in the infrastructure makefiles are sufficient to solve many, but not all problems. I doubt we will make the ports tree completely compiler/toolchain (C/T)-agnostic in the near future -- that would probably require more time and effort than the committers are willing to invest -- but it seems desirable to try to support at least (1) clang+BSD-licensed ELF toolchain and (2) the latest stable release of gcc+GNU binutils. One outstanding question is how to handle the C/T and their dependencies. In future releases it seems likely that (1) will be in the base system. But what about the use of (1) with older, but still supported releases? And what about (2)? If the C/Ts aren't in the base system, then the present USE_GCC arrangement must be modified so that important dependencies of the C/Ts, like perl, may themselves be built with the C/Ts without introducing circular dependencies. Also, will the use of different C/Ts for the base system and for ports be supported? Or the use of different C/Ts for different ports? That seems desirable, but it makes life more difficult for ports committers. For example, the current USE_GCC arrangement is problematic, because even with special LDFLAGS, there are problems with the new gcc libraries from ports interposing on the old base system gcc libraries, and vice versa. And various build utilities like libtool, cmake, and qmake sometimes use hard-coded defaults based upon the C/T that is used to built them, causing problems for those who want to use different C/Ts for different ports. Part of this problem is that the Porters Handbook only tells porters to respect CC, CXX and CFLAGS, nothing else. This issue came up as well in the Building ports with stack-protector thread a couple of weeks ago (by yourself). What would be the comprehensive list of variables to respect? There are already quite many from the top of my head: CC CFLAGS CXX CXXFLAGS CPP CPPFLAGS LD LDFLAGS AS AFLAGS AR ARFLAGS RANLIB INSTALL OBJCOPY With the exception of INSTALL, yes. Probably also: ADDR2LINE CXXFILT FC FFLAGS GPROF NM OBJCFLAGS OBJDUMP READELF SIZE STRINGS STRIP Some of these are obviously less important than others, because they are used by a smaller number of ports, or in special targets like regression tests, or are less susceptible to problems when mixing C/Ts, but we should probably ensure consistent use of utilities from only one C/T for a given port, or perhaps even for all ports. Some of the above would generally be required to be respected only when cross-compiling to an another architecture. There are already examples of how mixing utilities from the older base system and newer ports gcc/binutils causes problems even with regular builds. I have been thinking of making a test build of all ports with some useless options in relevant variables and capturing output or doing ktrace to figure out which ports respect those flags and which do not. Haven't gotten around to actually doing it just yet :). Some scripts to detect these problems would be useful additions to ports/Tools. Another work-around would be to make a directory containing wrapper-shell-scripts with the names like cc, gcc, ld, cpp etc. and make them invoke the desired tools with desired flags. That directory would be placed in the beginning of PATH before compiling ports. This would be a quicker alternative to patching lots of ports. Perhaps. We'd obviously have to act to prevent environment variables or auto-detection from overriding these, too -- but such an approach may save some work. b. ___ 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: deskutils/alexandria - why does it create a world readable and writable directory?
On Fri, Jun 11, 2010 at 9:28 PM, Torfinn Ingolfsen tin...@gmail.com wrote: Hei, I just found deskutils/alexandria (0.6.5_3) and installed it. A very nice program. I have just one question: why does it create a directory (~/.alexandria) with 777 permissions? Wouldn't it be more correct to use something like 740 or even 750? Note: all subdirectories of said directory have 755 permissions too. In case nobody noticed, Alexandria 0.6.6 is ready now: http://alexandria.rubyforge.org/news/2010-06-21--0.6.6-released.html -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
nvidia-driver 256.35 released
Nvidia released version 256.35 of their FreeBSD driver today: http://www.nvidia.com/object/freebsd-x86-256.35-driver.html http://www.nvidia.com/object/freebsd-x64-256.35-driver.html I just compiled the the 64bit version on 8.1-RC1 and watched a few youtube videos, ran glxgears and played games/nexuiz for a few minutes w/o any issues. If you want to test the new driver, just bump PORTVERSION of x11/nvidia-driver to 256.35 and run make makesum. Emanuel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nvidia-driver 256.35 released
On 22-06-2010 21:35, Emanuel Haupt wrote: Nvidia released version 256.35 of their FreeBSD driver today: http://www.nvidia.com/object/freebsd-x86-256.35-driver.html http://www.nvidia.com/object/freebsd-x64-256.35-driver.html I just compiled the the 64bit version on 8.1-RC1 and watched a few youtube videos, ran glxgears and played games/nexuiz for a few minutes w/o any issues. If you want to test the new driver, just bump PORTVERSION of x11/nvidia-driver to 256.35 and run make makesum. Doesn't this imply repocopy'ing the current port to x11/nvidia-driver-195 and _then_ updating this port to 256.35 ? Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nvidia-driver 256.35 released
В Tue, 22 Jun 2010 21:35:11 +0200 Emanuel Haupt eha...@freebsd.org пишет: Nvidia released version 256.35 of their FreeBSD driver today: http://www.nvidia.com/object/freebsd-x86-256.35-driver.html http://www.nvidia.com/object/freebsd-x64-256.35-driver.html I just compiled the the 64bit version on 8.1-RC1 and watched a few youtube videos, ran glxgears and played games/nexuiz for a few minutes w/o any issues. If you want to test the new driver, just bump PORTVERSION of x11/nvidia-driver to 256.35 and run make makesum. Emanuel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org Hi! I use this version drivers from the moment they appear on this resource: ftp://download.nvidia.com/XFree86/FreeBSD-x86_64/256.35/ in this case I have problems with global locks. I use compiz and system is freeze for a few seconds the mouse cursor and screen... I returned back to the driver version 195.36.24 uname -a FreeBSD nonamehost 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Tue Jun 22 22:27:15 EEST 2010 i...@nonamehost:/usr/obj/usr/src/sys/mk9 amd64 nvidia0: GeForce 8400M GS on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nvidia-driver 256.35 released
libGLcore.so is rename to libnvidia-glcore.so so you need to update pkg-plist to 2010/6/22 Rene Ladan r.c.la...@gmail.com: On 22-06-2010 21:35, Emanuel Haupt wrote: Nvidia released version 256.35 of their FreeBSD driver today: http://www.nvidia.com/object/freebsd-x86-256.35-driver.html http://www.nvidia.com/object/freebsd-x64-256.35-driver.html I just compiled the the 64bit version on 8.1-RC1 and watched a few youtube videos, ran glxgears and played games/nexuiz for a few minutes w/o any issues. If you want to test the new driver, just bump PORTVERSION of x11/nvidia-driver to 256.35 and run make makesum. Doesn't this imply repocopy'ing the current port to x11/nvidia-driver-195 and _then_ updating this port to 256.35 ? Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nvidia-driver 256.35 released
On 22-06-2010 22:15, Mickaël Maillot wrote: libGLcore.so is rename to libnvidia-glcore.so so you need to update pkg-plist to and these files don't exist any longer: pkg_info: /compat/linux/usr/lib/libnvidia-glcore.so.1 doesn't exist pkg_info: /compat/linux/usr/lib/libnvidia-tls.so.1 doesn't exist Rene 2010/6/22 Rene Ladan r.c.la...@gmail.com: On 22-06-2010 21:35, Emanuel Haupt wrote: Nvidia released version 256.35 of their FreeBSD driver today: http://www.nvidia.com/object/freebsd-x86-256.35-driver.html http://www.nvidia.com/object/freebsd-x64-256.35-driver.html I just compiled the the 64bit version on 8.1-RC1 and watched a few youtube videos, ran glxgears and played games/nexuiz for a few minutes w/o any issues. If you want to test the new driver, just bump PORTVERSION of x11/nvidia-driver to 256.35 and run make makesum. Doesn't this imply repocopy'ing the current port to x11/nvidia-driver-195 and _then_ updating this port to 256.35 ? Rene -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Call for testers: sysutils/3dm
On Mon, Jun 21, 2010 at 1:28 AM, Darren Pilgrim free...@bitfreak.org wrote: I need testers for an update to the sysutils/3dm port. If you want to help test the patch, begin by downloading it from here: http://vivi.cat.pdx.edu/3dm2/sysutils_3dm.patch.txt You can apply the patch by issuing the command: cd /usr/ports/sysutils/3dm patch /path/to/sysutils_3dm.patch.txt The updated port should install v2.11.00.009 on 7.x and earlier and v2.09.01.004 on 8.x and later. Please test the port installs, runs and functions correctly. When reporting, please include the following information: - RAID controller model - FreeBSD version (be specific, uname -r output is good) - OS architecture (i386 or amd64) - Outcome of test FreeBSD thehive.sd73.bc.ca 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Fri Jun 11 13:10:12 PDT 2010 3Ware 9550SXU-16ML 3Ware 9650SE-12ML amd64 Patch successful. 3dm2 upgraded from 2.04 to 2.09. Started fine. Able to login. Able to navigate around and twiddle options on both controllers. -- Freddie Cash fjwc...@gmail.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: Unable to update/build security/gpa
On 06/22/10 03:41, Jason E. Hale wrote: On Monday, June 21, 2010 15:07:38 Doug Barton wrote: On 06/20/10 09:30, Jason E. Hale wrote: On Sunday, June 20, 2010 06:55:52 you wrote: FreeBSD-PRERELEASE 8.1 amd64 Since the release of libassuan-2.0.0, I have not been able to update or reinstall security/GPA. All of the other ports appear to build fine. Jerry, I'm sorry to hear that you're having problems. At this time if you want to use gpa the only alternative is to use gnupg 1.x. I realize that's not necessarily an attractive alternative, but see below. GPA won't work with gnupg 1.x. Sorry if my information was incorrect. It requires gpgsm which is only provided by gnupg 2.x. I have submitted a PR to make GPA work with libassuan 2.x. I have also submitted a PR for the latest version of GPGME which is also required. GPGME: http://www.freebsd.org/cgi/query-pr.cgi?pr=148061 GPA: http://www.freebsd.org/cgi/query-pr.cgi?pr=148062 Those are committed now, thanks for jumping on this. :) I couldn't really do anything with my ports until their dependencies were updated first (which you have done). I would have liked to have gotten the updated ports for the dependencies ahead of time so I could tackle my ports before they broke. Sorry if my previous messages weren't clear. On May 12th I sent out the following with the link to my proposed libassuan update: http://mail.kde.org/pipermail/kde-freebsd/2010-May/008339.html I also discussed the fact that gnupg 2.0.15 was a simple update, but I did not provide a patch for that. In any case I'm glad that we're making progress on this transition. As of now there are no broken ports related to the libassuan update. When the optional dependencies in kdepim and opensc are removed I'll remove the libassuan-1 port. 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: nvidia-driver 256.35 released
On Tue, Jun 22, 2010 at 10:06:51PM +0200, Rene Ladan wrote: On 22-06-2010 21:35, Emanuel Haupt wrote: Nvidia released version 256.35 of their FreeBSD driver today: http://www.nvidia.com/object/freebsd-x86-256.35-driver.html http://www.nvidia.com/object/freebsd-x64-256.35-driver.html I just compiled the the 64bit version on 8.1-RC1 and watched a few youtube videos, ran glxgears and played games/nexuiz for a few minutes w/o any issues. If you want to test the new driver, just bump PORTVERSION of x11/nvidia-driver to 256.35 and run make makesum. Doesn't this imply repocopy'ing the current port to x11/nvidia-driver-195 and _then_ updating this port to 256.35 ? At this point there are no plans to repocopy for a yet another version of nvidia driver other than three legacy versions we already have. Master port will be updated to the latest stable version once people who had original problems with anything 195.22 (dougb@ et al) would test any latest version nVidia has for us and confirm their stability issues are indeed gone. ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Calling for test: python-2.7
Hi, I created a new port python-2.7 based on python-2.6, now it is in RC2 and I hope it will release soon. Here is the shar file of it and the diff file of bsd.python.mk: http://people.freebsd.org/~wen/python27rc2.shar.txt http://people.freebsd.org/~wen/python27rc2mk.diff.txt Any comments is welcomed. Regards, wen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: nvidia-driver 256.35 released
2010/6/22 Alexey Dokuchaev da...@freebsd.org: On Tue, Jun 22, 2010 at 10:23:51PM +0200, Rene Ladan wrote: On 22-06-2010 22:15, Micka?l Maillot wrote: libGLcore.so is rename to libnvidia-glcore.so so you need to update pkg-plist to and these files don't exist any longer: pkg_info: /compat/linux/usr/lib/libnvidia-glcore.so.1 doesn't exist pkg_info: /compat/linux/usr/lib/libnvidia-tls.so.1 doesn't exist Sure, I will take care of plist issues upon the upgrade. What is more important right now is driver stability issues people had been having. I must rely on other people testing since I was not able to reproduce most of them in my local environment. ./danfe So what exactly do I have to do to test this? in the Makefile just -DISTVERSION?= 195.36.24 +DISTVERSION?= 256.35 make makesum make deinstall make install or will I have to change the plist somewhere Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.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: nvidia-driver 256.35 released
On Tue, Jun 22, 2010 at 08:30:54PM -0500, Sam Fourman Jr. wrote: 2010/6/22 Alexey Dokuchaev da...@freebsd.org: On Tue, Jun 22, 2010 at 10:23:51PM +0200, Rene Ladan wrote: On 22-06-2010 22:15, Micka?l Maillot wrote: libGLcore.so is rename to libnvidia-glcore.so so you need to update pkg-plist to and these files don't exist any longer: pkg_info: /compat/linux/usr/lib/libnvidia-glcore.so.1 doesn't exist pkg_info: /compat/linux/usr/lib/libnvidia-tls.so.1 doesn't exist Sure, I will take care of plist issues upon the upgrade. What is more important right now is driver stability issues people had been having. I must rely on other people testing since I was not able to reproduce most of them in my local environment. So what exactly do I have to do to test this? in the Makefile just -DISTVERSION?= 195.36.24 +DISTVERSION?= 256.35 I would suggest to start with 195.36.31, as 256.xx are early betas. Ideally, I want a stable version in 195.36.yy series before start looking at upcoming 256 ones. make makesum make deinstall make install or will I have to change the plist somewhere Yes, plist changes are required to make the port deinstall itself cleanly. It won't affect driver stability in any way though. :-) ./danfe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
