Re: science/py-obspy.core needs to be renamed
On 16/03/2011 06:34, Doug Barton wrote:
Wen,
The default cvsupd configuration (cvsignore to be exact) prevents the
download of files named *.core
(http://www.freebsd.org/cgi/cvsweb.cgi/CVSROOT-ports/cvsignore?rev=1.4;content-type=text%2Fplain).
The ports you recently committed have this:
cd /usr/ports/science/
grep py-obspy.core Makefile py-obspy.*/*
Makefile: SUBDIR += py-obspy.core
py-obspy.gse2/Makefile:
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
py-obspy.mseed/Makefile:BUILD_DEPENDS=
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
py-obspy.mseed/Makefile:RUN_DEPENDS=
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
py-obspy.signal/Makefile:BUILD_DEPENDS=
${PYTHON_PKGNAMEPREFIX}obspy.core=0.4.6:${PORTSDIR}/science/py-obspy.core
Using cvsup (csup in my case) science/py-obspy.core doesn't get
downloaded, so INDEX creation throws multiple errors, and I'm sure that
if I tried to build those ports they would fail. :)
FYI,
Doug
Yes, I do not have this port neither.
--
David Demelier
___
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: deprecated ports
That said, I think that un-deprecating these ports just because someone can find a distfile somewhere is the wrong approach. bapt has been very careful to only deprecate ports that are on the absolute bottom of the pile. They are unmaintained, and unfetchable. That's not completely accurate. Some ports were deprecated because their distfiles had been moved, sometimes to another directory on the same server, but this went unnoticed because the distfiles were mirrored locally. I see a few others, some of them standard packages, that were caught in the net for various reasons -- one because someone had compressed the local copies of the distfiles, and then marked the Makefile so that only the compressed versions that were not present upstream would be fetched; another, still fetchable and with a reachable homepage, was deprecated presumably because it had a few bad mirrors. I'll fix these. There is certainly a lot that could and should be cleaned up, and it is difficult for one person to do this without making a few mistakes -- I'm glad that Bapt was willing to make the attempt. But it's not clear to me why, for example, some usable fonts were deprecated -- fonts often don't have homepages. 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: [ECFT] drm/dri/mesa/xorg-server update [Part 1]
On Fri 11 March 2011 at 07:37:59PM +0800, Martin Wilke wrote: Please report any problems and issues to x11 (at) FreeBSD.org. Works fine here with a GeForce Go 7300 (xf86-intel-2.7) I have problems with an ATI R710, Xorg randomly crash within 5 to 10 minutes (sigbus) with KDE4 and desktop effects enabled. I've tried Xorg 1.9.3 but to not avail (againg sigbus). I've reverted Xorg to 1.7.7 and I can use my desktop more than 10 minutes... If I disable desktop effect, Xorg 1.9.4 runs happily with no crash. I've recompiled xorg-server, libX11, libGL etc with debug flags but I can't get a useful backtrace. I've just seen [1], I'll try to get more info later today and will post my findings. [1] http://www.x.org/wiki/Development/Documentation/ServerDebugging ___ 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: Compiling ports in a post-9.0-RELEASE world
16.03.2011, 02:27, Alberto Villa avi...@freebsd.org: On Tuesday 15 March 2011 19:20:40 Konstantin Tokarev wrote: 3. Fix Clang to compile more ports lots of problems are due to gcc-isms in software, so it's not always possible From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. -- Regards, Konstantin ___ 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: Compiling ports in a post-9.0-RELEASE world
On Wednesday 16 March 2011 09:15:07 Konstantin Tokarev wrote: From http://clang.llvm.org/docs/LanguageExtensions.html In addition to the language extensions listed here, Clang aims to support a broad range of GCC extensions. So GCC extensions may also be considered as missing features. gcc-isms also means bad code which is nonetheless supported by gcc -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla A pipe gives a wise man time to think and a fool something to stick in his mouth. signature.asc Description: This is a digitally signed message part.
Re: Compiling ports in a post-9.0-RELEASE world
On Tue, Mar 15, 2011 at 09:20:40PM +0300, Konstantin Tokarev wrote: 13.03.2011, 01:00, Doug Barton do...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. There are a few PRs already in GNATS that generalize the compiler settings for ports that portmgr have been looking into, but more work is needed. The idea is to extend the USE_GCC framework to a USE_COMPILER (or similar) macro that can force a port to use gcc, clang or another compiler with a default compiler that easily can be flipped. I've also run a few full builds on the pointyhat cluster with clang as the default compiler, mostly to check for clang bugs and we'll do more rounds with the results posted here to get help with fixing individual ports. -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpYkgwWjZFsk.pgp Description: PGP signature
Re: Compiling ports in a post-9.0-RELEASE world
On Wed, Mar 16, 2011 at 10:19:48AM +0100, Erwin Lansing wrote: On Tue, Mar 15, 2011 at 09:20:40PM +0300, Konstantin Tokarev wrote: 13.03.2011, 01:00, Doug Barton do...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: gnome-translate-0.99_14 problem
Hi! Thanks a lot for help! You both were right, guys. I didn't have *textproc/p5-XML-Parser* on my system, but it all must be connected to my Perl Upgrade. *portupgrade -f p5** made everything needed :) All the best to you! With Kind Regards, Alexey On Tue, Mar 15, 2011 at 6:26 PM, Daniel Nebdal dneb...@gmail.com wrote: On Tue, Mar 15, 2011 at 3:19 PM, Alexey Zaivenko - Vysochin zaivenkoxxxa...@gmail.com wrote: Hello! I was trying to install the port textproc/gnome-translate (gnome-translate-0.99_14), but a problem occurred. And I have upgraded perl to 5.12.3 version earlier. [root@lucky /usr/ports/textproc/gnome-translate]# make install clean (...) checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool (...) It sounds like you're missing textproc/p5-XML-Parser , which is listed in RUN_DEPENDS for textproc/intltool . Could you check if both are indeed installed? If you just want a workaround, I suggest you try (re)installing textproc/p5-XML-Parser - but it'd probably be useful to track down what has happened. -- Daniel Nebdal On Tue, Mar 15, 2011 at 8:09 PM, Koop Mast k...@rainbow-runner.nl wrote: On Tue, 2011-03-15 at 16:19 +0200, Alexey Zaivenko - Vysochin wrote: Hello! I was trying to install the port textproc/gnome-translate (gnome-translate-0.99_14), but a problem occurred. And I have upgraded perl to 5.12.3 version earlier. You need to look up and read the entry in ports/UPDATING about the perl upgrade. -Koop [root@lucky /usr/ports/textproc/gnome-translate]# make install clean === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Found saved configuration for gnome-translate-0.99_14 = gnome-translate-0.99.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch http://nongnu.askapache.com/libtranslate/gnome-translate-0.99.tar.gz gnome-translate-0.99.tar.gz 100% of 291 kB 207 kBps === Extracting for gnome-translate-0.99_14 = SHA256 Checksum OK for gnome-translate-0.99.tar.gz. === Patching for gnome-translate-0.99_14 === Applying FreeBSD patches for gnome-translate-0.99_14 === gnome-translate-0.99_14 depends on executable: gmake - found === gnome-translate-0.99_14 depends on file: /usr/local/bin/intltool-extract - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/gnome-mime-data-2.0.pc - found === gnome-translate-0.99_14 depends on executable: pkg-config - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/gnome-doc-utils.pc - found === gnome-translate-0.99_14 depends on file: /usr/local/libdata/pkgconfig/pygtk-2.0.pc - found === gnome-translate-0.99_14 depends on shared library: translate - found === gnome-translate-0.99_14 depends on shared library: aspell - found === gnome-translate-0.99_14 depends on shared library: esd.2 - found === gnome-translate-0.99_14 depends on shared library: atk-1.0.0 - found === gnome-translate-0.99_14 depends on shared library: eel-2.2 - found === gnome-translate-0.99_14 depends on shared library: gconf-2.4 - found === gnome-translate-0.99_14 depends on shared library: glib-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: gnome-desktop-2.17 - found === gnome-translate-0.99_14 depends on shared library: gnomevfs-2.0 - found === gnome-translate-0.99_14 depends on shared library: gtk-x11-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: art_lgpl_2.5 - found === gnome-translate-0.99_14 depends on shared library: bonobo-2.0 - found === gnome-translate-0.99_14 depends on shared library: bonoboui-2.0 - found === gnome-translate-0.99_14 depends on shared library: glade-2.0.0 - found === gnome-translate-0.99_14 depends on shared library: gnome-2.0 - found === gnome-translate-0.99_14 depends on shared library: gnomecanvas-2.0 - found === gnome-translate-0.99_14 depends on shared library: gnomeui-2.0 - found === gnome-translate-0.99_14 depends on shared library: IDL-2.0 - found === gnome-translate-0.99_14 depends on shared library: xml2.5 - found === gnome-translate-0.99_14 depends on shared library: xslt.2 - found === gnome-translate-0.99_14 depends on shared library: ORBit-2.0 - found === gnome-translate-0.99_14 depends on shared library: pango-1.0.0 - found === Configuring for gnome-translate-0.99_14 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... gawk checking whether gmake sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by gmake... GNU checking for gcc... cc checking for C compiler default output file name... a.out checking
Re: [ECFT] drm/dri/mesa/xorg-server update [Part 1]
On Wed 16 March 2011 at 09:00:30AM +0100, Urankar Mikael wrote: On Fri 11 March 2011 at 07:37:59PM +0800, Martin Wilke wrote: Please report any problems and issues to x11 (at) FreeBSD.org. Works fine here with a GeForce Go 7300 (xf86-intel-2.7) Oups, I'm using the nv driver (xf86-video-nv-2.1.18) of course. Thanks to Tom Evans for pointing this out. ___ 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: Compiling ports in a post-9.0-RELEASE world
On Wed, Mar 16, 2011 at 09:39:38AM +, Anton Shterenlikht wrote: Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? Good point I forgot to mention, the default compiler will of course depend on architecture and FreeBSD version. We'll have to see how many ports will build with clang whether we want to change the default ports compiler to clang, but even if we do we'll have to stay with gcc for non-clang archs and older FreeBSD versions. -erwin -- Erwin Lansing (o_ _o) http://droso.org Ceterum censeo \\\_\ /_/// Carthaginem esse delendam) (er...@lansing.dk pgpbDbF2aIS5d.pgp Description: PGP signature
Re: Compiling ports in a post-9.0-RELEASE world
On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling ports in a post-9.0-RELEASE world
16.03.2011, 13:33, Ade Lovett a...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) -- Regards, Konstantin ___ 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: deprecated ports
Am 15.03.2011 23:19, schrieb Baptiste Daroussin: 2011/3/15 Charlie Kestercorky1...@comcast.net I see there's been another few batch commits deprecating some unmaintained ports where upstream is gone and/or distfile is no longer available. Maintainers and prospective maintainers should be sure to look at the ports listed in these commits. I don't think much effort was made to check the availability of the distfiles. Instead, it seems that all that was done was to try the MASTER_SITES, etc. from the port Makefiles, and if the fetch failed, onto the list they went. NOTE: I'm NOT saying the committers' procedure was too lazy or anything like that. There are a lot of these broken ports in the tree, and deprecation seems like a reasonable step to take -- especially if the result is to trigger some action from people who want to see these ports retained. I just rescued one of these, sysutils/lookat, that was deprecated a few days ago. I followed the WWW link in the pkg-descr, found that the author's website was still up and that the distfile could still be downloaded -- but the download url had changed. So all the port needed was a tweak to the MASTER_SITES. Today I see that the fairly popular graphics/gimpshop has also been deprecated. Here the WWW link from pkg-descr also fails, but a quick websearch found the new (?) official website for this app: http://www.gimpshop.com, where the distfile is available for download. So here's another one that can be easily rescued. And I'll bet there are more. ___ 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 I am responsible for the deprecation and I have done more than just look if the distfiles fetch (I fixed lot of them) I may have missed some for sure, when when I deprecate sysutils/lookat I wasn't able to join the main website nor to fetch a distfile. About gimpshop it may be wrong, but one there website I only found windows and mac binaries, nothing. I am human and I can make mistakes. thanks pointing the mistakes. I really will be happy to remove the deprecation and expiration if people wanted to maintain or point me to the right WWW and MASTER_SITES for the given ports. Baptiste, I generally agree with your approach, and as Doug pointed out, it has worked out fine. Those ports that people had interest in triggered, for instance, Charlie's response. However, we should be sure to find maintainers before ports are undeprecated, else we run into a cycle of deprecation, reviving the port, deprecating it again, and so on. Charlie has stated which ports he isn't interested in (and I haven't checked if there are any left where we could offer him maintainership). For anyone who reads this and is unhappy about the deprecation of a pet port, please feel invited to become a port maintainer -- the porter's handbook has lots of information, and port committers will likely be willing to lend a hand with a new maintainer's first steps. :-) Best regards Matthias -- Matthias Andree ports committer ___ 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: can make -j be used for ports?
Am 15.03.2011 23:44, schrieb Chuck Swiger:
On Mar 15, 2011, at 3:35 PM, Eitan Adler wrote:
[ ... ]
Yes. Ports which support parallel builds will have MAKE_JOBS_SAFE=yes set in
the port Makefile. It defaults to running -j with MAKE_JOBS_NUMBER=`${SYSCTL}
-n kern.smp.cpus`, but you can change that to some other # if you like.
No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used
internally when building a single port.
What is incorrect?
When the OP is asking if he can manually specify -j on the command line which
would end up
building multiple ports in parallel. This can not be done (primarily
because there is no locking done on ports)
It certainly wasn't clear to me that this is what the OP meant. If you:
cd /usr/ports/www/apache22
make -j 3
make FORCE_MAKE_JOBS=yes
and the -j argument will default to the number of CPU cores as provided
by the corresponding sysctl. If the port breaks with
FORCE_MAKE_JOBS=yes please file a PR with a patch fixing it, or if that
is too much of an effort, a patch to add a line MAKE_JOBS_UNSAFE= yes
(on a single line with a TAB between MAKE_JOBS_UNSAFE= and yes).
...what do you expect to happen, and how many ports would you expect to be
built at once?
(Building one port in parallel is supported, where the port itself is safe to
do so; building many at the same time is not. Supporting the former provides
more speed gain for many situations as compared to the latter; which doesn't
help at all if you are just installing or updating one port.)
I beg to differ on the speed assertion. I own a somewhat fast computer
(Phenom II X4 i. e. 4 x 2.5 GHz) and I find that a lot of serialization
takes place, particularly behind the configure phases and the
mtree/registration stuff.
In that respect, building non-dependent ports in parallel would be
rather useful to actually exploit SMP computers; however it would
require a dependency analysis so that only those ports build in parallel
that do not depend on one another, and I also fear that sometimes mtree
during installation might get in the way.
I seem to recall that Doug stated something to the extent he wouldn't be
doing it in portmaster, and I don't see any other tool that is similarly
mature so it would be worthwhile even trying that.
Best
--
Matthias Andree
___
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: Is it possible to install only some parts of libreoffice?
07.03.2011, 00:54, Heino Tiedemann rotkaps_spam_t...@gmx.de: Konstantin Tokarev annu...@yandex.ru; wrote: 03.03.2011, 03:27, Charlie Kester corky1...@comcast.net;: On Wed 02 Mar 2011 at 15:06:52 PST Charlie Kester wrote: I don't want or need all of the programs in the libreoffice suite. In fact, the only reason I might install it is to get the presentation program so I can work with PowerPoint files I occasionally download from the web. (There don't seem to be any workable, lighterweight alternatives, as there are for .doc and .xls files.) Would it be possible to provide some options to select which components to install? Or is the suite written in such a way that I have to install the whole thing in order to get one piece? It doesn't make much sense because all components of OOo/LibO are tightly integrated. I remember my debian GNU/Linux times some years ago: If i remember correcly there was the possibillity to install Openoffice (what is the root of libreoffice) in peaces: Needed was a openoffice core package and maybe another openoffice lib (or so) package. After that you could install writer / base / calc and so on seperatly... Right, but actually there's no much sense in it, because all components are just launchers for soffice.bin executable -- Regards, Konstantin ___ 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: can make -j be used for ports?
Am 16.03.2011 03:38, schrieb John: On 15/03/2011 22:35, Eitan Adler wrote: No, this is incorrect. The MAKE_JOBS_NUMBER and MAKE_JOBS_SAFE is used internally when building a single port. When the OP is asking if he can manually specify -j on the command line which would end up building multiple ports in parallel. This can not be done (primarily because there is no locking done on ports) Actually, he has it partially right, at least in the idea I was trying to convey. I'll explain again, because maybe I wasn't coherent enough previously: I have an amd x2 6000+ with 8GB RAM. It's a wonderful fast desktop. Not the fastest, but it's fast enough for me. What I want to do is this: 1. If I can speed things up, with *ports* as I have a dual cpu, I want to maybe run j2 or j3. I seek clarification which is logically best, because some literature says jn, others jn+1 where n is number of cores. kern.smp.cpus: 2 on my machine. Is there benefit setting this to 3,4,5? I want to know if there is perhaps a conf file or sysctl where I can specify this *for ports only.* - if not I'm happy to specify on the command line. It's just that the manual is a tad unclear about this. /etc/make.conf: FORCE_MAKE_JOBS=yes MAKE_JOBS_NUMBER=3# whatever you find useful. The key is that you need to figure how loaded the CPU is. As long as it is waiting for the disks (which it usually is), you can try to increase the number, but keep an eye on the RAM, you don't want the machine to go swapping in and out (although 8 GibiB are plenty). On an i7-920 with a truckload of RAM I've sometimes even run make -j12 or so (on Linux build jobs though) to actually get the CPU 100% busy. 2. Where I was being unclear I think is when I was talking about building the system. I have seen in the literature that -jn when installing world Breaks Things. This isn't an issue as I run RELEASE and so only either apply patches or make the system, so easy to specify, where I can, -j3 except in make installkernel and make installworld. I've also found that make -j4 -DNOCLEAN buildworld buildkernel works for me on 8.2. If RELENG_8 occasionally failed, I re-ran without -DNOCLEAN but still with -j4. Looks like most of the issues with parallel building have been shaken out of the world :-) -- Matthias Andree ___ 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: Compiling ports in a post-9.0-RELEASE world
On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote: 16.03.2011, 13:33, Ade Lovett a...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't). Let's take the embedded example at random (well, not so much, since we both brought it up). Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff. That's the low hanging fruit. In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in bsd.port.mk and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system. With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box. Enough is enough. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: deprecated ports
2011/3/16 Matthias Andree mand...@freebsd.org Baptiste, I generally agree with your approach, and as Doug pointed out, it has worked out fine. Those ports that people had interest in triggered, for instance, Charlie's response. However, we should be sure to find maintainers before ports are undeprecated, else we run into a cycle of deprecation, reviving the port, deprecating it again, and so on. Charlie has stated which ports he isn't interested in (and I haven't checked if there are any left where we could offer him maintainership). For anyone who reads this and is unhappy about the deprecation of a pet port, please feel invited to become a port maintainer -- the porter's handbook has lots of information, and port committers will likely be willing to lend a hand with a new maintainer's first steps. :-) Yes your right I was planning to send a general mailing at the end of my seek and deprecate campaign inviting users and maintainer to have a look a the deprecation list and adopt the ports they use. regards, Bapt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: deprecated ports
On Wed, Mar 16, 2011 at 11:45:25AM +0100, Matthias Andree wrote: However, we should be sure to find maintainers before ports are undeprecated, else we run into a cycle of deprecation, reviving the port, deprecating it again, and so on. That's the purpose of a long deprecation period + the period emails from portsmon about deprecated ports. The next one of those is scheduled in the next few days. (Remember, too, that deleted ports can always be brought back from the Attic, if there is sufficient cause.) mcl ___ 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: deprecated ports
On Wed, Mar 16, 2011 at 06:15:11AM +, b. f. wrote: But it's not clear to me why, for example, some usable fonts were deprecated -- fonts often don't have homepages. The deprecations are (currently) advisory-only. If people are using these ports, and want to keep them, then they need to step up with either hosting the distfiles, becoming the upstream maintainers, or in the best case, both. mcl ___ 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: Compiling ports in a post-9.0-RELEASE world
On Wed, Mar 16, 2011 at 06:02:55AM -0500, Ade Lovett wrote: On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote: 16.03.2011, 13:33, Ade Lovett a...@freebsd.org: On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. What about Power Architecrure (formerly PowerPC)? It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't). Let's take the embedded example at random (well, not so much, since we both brought it up). Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff. That's the low hanging fruit. In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in bsd.port.mk and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system. With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box. Enough is enough. -aDe Is this your personal view? Or the view of the Ports Management Team? Are you, or the Ports Management Team, going to actively encourage silent death? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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
Deprecation campaign
Hi, As some of you may have noticed I have started a deprecation campaign which should ends at the end of the week. The main goal is to remove stale ports. I have been looking category by category (except for languages category by french) searching for unmaintain ports where I can't find the upstream and where the distfiles can't be fetch from somewhere else than FreeBSD's mirrors Because I know I can make mistakes, the expiration date is set to 2011-05-01 to let users and maintainers the time to save the ports they want to see kept in the ports tree. I use ports-mgmt/distilator to select the candidates for deprecation and then I do a manual checking trying to find new homes, new links and so one. Please do not hesitate to: - double check, - take maintainership on one of those ports, - propose better messages for deprecation message (for example offering a maintained alternative to users), - propose other ports for deletion If you are a maintainer that also would be great if you check your own ports to see if some does need to be deprecated. We have tons of unmaintained (by upstream) libraries which should one day or another be removed from the ports tree, gnome-libs for example. regards, Bapt PS for xmms users : don't be affraid I won't try to remove it :) (not this time :D) ___ 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: portmaster comments
on 14/03/2011 02:45 Doug Barton said the following: BTW, the reason I'm not amenable to your suggestion in 2 is that only a few developer-types actually care about this, and that doesn't justify the code complexity. Just be thankful I didn't go with my first instinct, which was to 'rm -rf $WRKDIRPREFIX' :) I still think that this feature is implemented incorrectly. First, it's silent - it's not documented or advertised in run-time (e.g. now cleaning...). Second, there is no way to turn it off. Third, I think it's kind of useless as is, because a person intelligent enough to use portmaster should also know how to clean his/her WRKDIRPREFIX should it somehow grow. Perhaps you have added this feature for your own benefit, but the way you did that you tried to force your habits on other people, IMO. Well, I know how to alter my local copy of portmaster and you are its author and maintainer, so I have nothing else to add :) -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: deprecated ports
--On March 16, 2011 6:15:11 AM + b. f. bf1...@googlemail.com wrote: That said, I think that un-deprecating these ports just because someone can find a distfile somewhere is the wrong approach. bapt has been very careful to only deprecate ports that are on the absolute bottom of the pile. They are unmaintained, and unfetchable. That's not completely accurate. Some ports were deprecated because their distfiles had been moved, sometimes to another directory on the same server, but this went unnoticed because the distfiles were mirrored locally. I think the point is that if the ports were maintained properly, those changes would not go unnoticed. For example, I maintain a port named security/chaosreader. Recently it failed to build, after which I promptly got an email notification. I quickly figured out that one of the files that needs to be downloaded had been moved to a different uri on sourceforge, updated the port and submitted a PR. That's how it's *supposed* to work. When a port become unmaintained, that doesn't happen. While it's true that some good ports might get caught in the sweep, the reality is that if someone was maintaining them they wouldn't get deprecated. The ports system depends on active maintainers and breaks down when maintainers are inactive. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ 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: Compiling ports in a post-9.0-RELEASE world
On 03/16/2011 02:39 AM, Anton Shterenlikht wrote: On Wed, Mar 16, 2011 at 10:19:48AM +0100, Erwin Lansing wrote: On Tue, Mar 15, 2011 at 09:20:40PM +0300, Konstantin Tokarev wrote: 13.03.2011, 01:00, Doug Bartondo...@freebsd.org: Howdy, As many of you are no doubt already aware, much work has been undertaken to make clang the default compiler for the src tree starting with 9.0-RELEASE. It is not 100% certain that this change will be made, but it's looking more likely every day. This raises an interesting question for how to deal with compiling ports after 9.0 is released. So far there are 2 main ideas for how to deal with this: 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang. 2. Adopt an official ports compiler, which would likely be one of the gcc versions from the ports tree itself, and update all ports to work with it. 3. Fix Clang to compile more ports Note that these 3 are not mutually exclusive. The clang developers have been very responsive on earlier bugs we found and they are usually fixed quickly, so I'm sure that if real bugs in clang are found they will be happy to hear about them. Fixing ports to work with both gcc and clang should also be a good target to reach for, but given the amount of ports this is unrealistic to be finished before 9.0 is released. What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? This is a good reason that number 2 above is likely a necessary step regardless of what other work is done. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) 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: deprecated ports
On Wed 16 Mar 2011 at 03:45:25 PDT Matthias Andree wrote: However, we should be sure to find maintainers before ports are undeprecated, else we run into a cycle of deprecation, reviving the port, deprecating it again, and so on. I definitely agree with this. If someone wants to get one of these ports off the deprecated list, they should be willing to maintain it. I'm willing to take on more myself, but I'm not running a home for orphaned ports here. There has to be something about the port that interests me. I'm fond of commandline tools and ncurses-based interfaces, for example, which is why I took lookat. We have far too many unmaintained ports in the tree. I applaud this effort to weed out the stale ones. I certainly didn't intend for my comments re gimpshop, xinvest and xquote to lead to them being pulled off the deprecated list but still unmaintained. If no one else wants them, I'll take xinvest and xquote, since I'm responsible for their current status. But I'm leery of the whole gimp-y swamp. If I took gimpshop, I'd probably be in over my head. So I hope you'll understand if I decline. ___ 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
sysutils/gpart: deprecated port, anyone interested?
Hi, I have no actual interest in maintaining this port, as I don't use it, however I was able to update the port to find a suitable site for downloading and building. I found the hosting site with a google lookup, and it is also listed as the only downloading reference off of Wikipedia. It appears to work (i386): [jhelfman@eggman ~]$ sudo /sbin/gpart show = 63 488281185 mirror/gm0 MBR (233G) 63 488279547 1 freebsd [active] (233G) 488279610 1638 - free - (819K) =0 488279547 mirror/gm0s1 BSD (233G) 04194304 2 freebsd-swap (2.0G) 4194304 484085243 1 freebsd-ufs (231G) Here is a patch if someone would like to take it over, otherwise it will expire: http://jgh.devio.us/files/gpart_patch.txt Thanks, Jason -- Jason Helfman System Administrator experts-exchange.com http://www.experts-exchange.com/M_4830110.html E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5 ___ 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: sysutils/gpart: deprecated port, anyone interested?
On Wed, Mar 16, 2011 at 10:20:11AM -0700, Jason Helfman thus spake: Hi, I have no actual interest in maintaining this port, as I don't use it, however I was able to update the port to find a suitable site for downloading and building. I found the hosting site with a google lookup, and it is also listed as the only downloading reference off of Wikipedia. It appears to work (i386): [jhelfman@eggman ~]$ sudo /sbin/gpart show = 63 488281185 mirror/gm0 MBR (233G) 63 488279547 1 freebsd [active] (233G) 488279610 1638 - free - (819K) =0 488279547 mirror/gm0s1 BSD (233G) 04194304 2 freebsd-swap (2.0G) 4194304 484085243 1 freebsd-ufs (231G) Here is a patch if someone would like to take it over, otherwise it will expire: http://jgh.devio.us/files/gpart_patch.txt Thanks, Jason Whoops :) I ran the base gpart, so not sure if it works, but I suppose it could, just not on my system. [jhelfman@eggman ~/ports/sysutils/gpart]$ sudo /usr/local/sbin/gpart show *** Fatal error: open(show): No such file or directory. -jgh ___ 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: sysutils/gpart: deprecated port, anyone interested?
on 16/03/2011 19:20 Jason Helfman said the following: Hi, I have no actual interest in maintaining this port, as I don't use it, however I was able to update the port to find a suitable site for downloading and building. I found the hosting site with a google lookup, and it is also listed as the only downloading reference off of Wikipedia. It appears to work (i386): [jhelfman@eggman ~]$ sudo /sbin/gpart show /sbin/gpart is a part of base system. sysutils/gpart is supposed to be something else. = 63 488281185 mirror/gm0 MBR (233G) 63 488279547 1 freebsd [active] (233G) 488279610 1638 - free - (819K) =0 488279547 mirror/gm0s1 BSD (233G) 04194304 2 freebsd-swap (2.0G) 4194304 484085243 1 freebsd-ufs (231G) Here is a patch if someone would like to take it over, otherwise it will expire: http://jgh.devio.us/files/gpart_patch.txt -- Andriy Gapon ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: tracking lib dependencies
On Wed, Mar 16, 2011 at 10:56 AM, Robert Huff roberth...@rcn.com wrote:
When trying to rebuild avahi after the recent upgrade, I get:
signals-marshal.c:186: warning: ISO C forbids conversion of object pointer to
function pointer type
CC libavahi_gobject_la-ga-client-enumtypes.lo
CC libavahi_gobject_la-ga-entry-group-enumtypes.lo
CC libavahi_gobject_la-ga-enums-enumtypes.lo
CCLD libavahi-gobject.la
GISCAN Avahi-0.6.gir
g-ir-scanner: warning: Option --strip-prefix has been deprecated;
see --identifier-prefix and --symbol-prefix.
/usr/include/machine/endian.h:123: syntax error, unexpected '{' in ' return
(__extension__ ({ register __uint64_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at '{'
/usr/include/machine/endian.h:123: syntax error, unexpected ';' in ' return
(__extension__ ({ register __uint64_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at ';'
/usr/include/machine/endian.h:130: syntax error, unexpected '{' in ' return
(__extension__ ({ register __uint32_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at '{'
/usr/include/machine/endian.h:130: syntax error, unexpected ';' in ' return
(__extension__ ({ register __uint32_t __X = (_x); __asm (bswap %0 : +r
(__X)); __X; }));' at ';'
/libexec/ld-elf.so.1: Shared object libicui18n.so.38 not found, required by
libavahi-glib.so.1
Command
'['/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/Avahi-0.6',
'--introspect-dump=/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/types.txt,/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/dump.xml']'
returned non-zero exit status 1
gmake[3]: *** [Avahi-0.6.gir] Error 1
gmake[3]: Leaving directory
`/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject'
gmake[2]: *** [all] Error 2
(full build log is appended)
libicui18n.so.38? The current version of icu is 4.6
(re-installed this morning). Where is this picking up the
dependency on 3.8?
You need to follow icu update in the /usr/ports/UPDATING.
Cheers,
Mezz
Respectfully,
Robert Huff
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@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: FreeBSD Port: mysql-server-5.5.9
On 03/10/11 11:37, joeb wrote: I have been using mysql since fbsd 7.2 and always just issued the mysql_install_db command on the command line to create mysql's control databases and it always worked fine. But now with fbsd 8.2 I get the following error and have no idea why. I installed using pkg_add -r mysql55-server command. I see that 3 weeks ago you updated the mysql55-server port from mysql 554 to 559. I believe there is an error in your update causing the mysql_install_db command to error out. The error message follows. # /usr/local/binmysql_install_db --user=mysql or #rootmysql_install_db --user=mysql FATAL ERROR: Could not find ./bin/my_print_defaults If you compiled from source, you need to run 'make install' to copy the software into the correct location ready for operation. If you are using a binary release, you must either be at the top level of the extracted archive, or pass the --basedir option pointing to that location. * end of error msg. # /usr/local/binlocate my_print_defaults /usr/local/bin/my_print_defaults As you can see the script the error message says it can not find is really in the same location as the mysql_install_db script, so it should have found it. I ended up pointing to the 8.1 packages with the pkg-add command to install and then the mysql-server5.5.4 mysql_install_db command ran from the command line without any errors. ___ 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 The problem appears to be in the mysql_install_db script # All unrecognized arguments to this script are passed to mysqld. basedir= *Should be /usr/local* builddir= ldata=./data langdir= srcdir= I suspect that when the mysql_install_db script was generated that the source for the mysql_install_db was update/modified/changed: basedir= *mysql-5.5.9/scripts* builddir= ldata=@localstatedir@ langdir= srcdir= I suspect that@bindir@ would be the appropriate value. But if you do this you get: basedir=./bin builddir= ldata=./data langdir= srcdir= I suspect that given the level of complexity of the build process that trying to patch the source files to fix this would be extremely difficult. The other approach is to modify the PORT Makefile and have the mysql_install_db modified before installation with the correct binary directory. -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Road, Suite X, Network and System San Diego, CA 92019 Consulting 858-874-6543 Web Site: www.astart.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: sysutils/gpart: deprecated port, anyone interested?
On Wed, 2011-03-16 at 10:36 -0700, Jason Helfman wrote: Whoops :) I ran the base gpart, so not sure if it works, but I suppose it could, just not on my system. [jhelfman@eggman ~/ports/sysutils/gpart]$ sudo /usr/local/sbin/gpart show *** Fatal error: open(show): No such file or directory. -jgh gpart (the port, not the base geom tool) doesn't work that way, you're still confusing the two. sysutils/gpart is a tool for rebuilding broken partitions, so the parameter you're looking for is a device name, not show (what the error message basically told you). m. -- Michal Varga, Stonehenge (Gmail account) ___ 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: sysutils/gpart: deprecated port, anyone interested?
On 16.03.2011 18:54 (UTC+1), Michal Varga wrote: On Wed, 2011-03-16 at 10:36 -0700, Jason Helfman wrote: Whoops :) I ran the base gpart, so not sure if it works, but I suppose it could, just not on my system. [jhelfman@eggman ~/ports/sysutils/gpart]$ sudo /usr/local/sbin/gpart show *** Fatal error: open(show): No such file or directory. -jgh gpart (the port, not the base geom tool) doesn't work that way, you're still confusing the two. sysutils/gpart is a tool for rebuilding broken partitions, so the parameter you're looking for is a device name, not show (what the error message basically told you). gpart in sysutils/gpart stands for 'guess partitions'. Its an old, but very useful tool for repairing partitions. Unfortunately it does not work on amd64. If someone is willing to update the port: I have an original tarball 'gpart-0.1h.tar.gz'. It would need a new home ;-) #cat pkg-descr A port of a tool which tries to guess the primary partition table of a PC-type hard disk in case the primary partition table in sector 0 is damaged, incorrect or deleted. The guessed table can be written to a file or device. Supported (guessable) filesystem or partition types: DOS/Windows FAT, Linux ext2 and swap, OS/2 HPFS, Windows NTFS, FreeBSD and Solaris/x86 disklabels, Minix FS, Reiser FS WWW: http://www.stud.uni-hannover.de/user/76201/gpart/ Rainer Hurling m. ___ 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: [ECFT] drm/dri/mesa/xorg-server update [Part 1]
On Friday 11 March 2011 13:37:59 Martin Wilke wrote: Hi, First of all, note that *this is very experimental, so you really have to know what you’re doing.* We managed to get drm/dri with the newer xorg-server to work, and we have removed the support for WITHOUT_NOUVEAU. We have just updated the xorg-dev repo: – libdrm - 2.4.24 – libGL to 7.10.1 – libGLU to 7.10.1 – libGLUw to 7.10.1 – libglut to 7.10.1 – xproto to 7.0.17 – libXaw to 1.0.9 – libXt to 1.1.0 – libX11 to 1.4.1 – xorg-server to 1.9.4 It appears graphics/mesa-demo is not updated. After installing these, you will have to rebuild the following ports: – your graphic driver x11/nvidia-driver – keybord driver – mouse/synaptics driver Please report any problems and issues to x11 (at) FreeBSD.org. I have no problems ;-). I have tested some wine games and all run without problem. signature.asc Description: This is a digitally signed message part.
Re: tracking lib dependencies
Jeremy Messenger writes: /libexec/ld-elf.so.1: Shared object libicui18n.so.38 not found, required by libavahi-glib.so.1 Command '['/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/Avahi-0.6', '--introspect-dump=/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/types.txt,/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/dump.xml']' returned non-zero exit status 1 gmake[3]: *** [Avahi-0.6.gir] Error 1 You need to follow icu update in the /usr/ports/UPDATING. Ok, did that: portupgrade -fr devel/icu I got a long list of successful rebuilds, plus avahi failing to build with the exact same error. Robert Huff ___ 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: Deprecation campaign
Hello, i noted that ucpp is deprecated because it cannot be fetched from original site. This is an alternate c preprocessor supposed to be better than the gnu one, written by Thomas Pornin. I happen to know the guy (*), so i searched if the soft had been moved, and indeed it can be found here: http://code.google.com/p/ucpp/ I hope you may reconsider your decision. With my best regards (*) i think he now runs a crypto firm in the Boston area. -- Michel TALON ___ 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: deprecated ports
Ruslan Mahmatkhanov wrote: I also saw that graphics/gimp-greycstoration is finally deprecated. Baptiste you may want to look at ports/154596 to close it. In fact this is an interesting plugin which is superseded by gmic from the same author David Tschumperlé http://gmic.sourceforge.net/gimp.shtml and which is in the ports. So this deprecation is fine. -- Michel TALON ___ 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: sysutils/gpart: deprecated port, anyone interested?
On Wed, Mar 16, 2011 at 08:00:17PM +0100, Rainer Hurling wrote: gpart in sysutils/gpart stands for 'guess partitions'. Its an old, but very useful tool for repairing partitions. Unfortunately it does not work on amd64. I've added two patches to make it work on amd64, bumped the expiration date and port revision (to 2), but I'm not sure if it can detect all relevant partition types yet. It detects my BSD UFS partitions, but not my Windows 7 NTFS partitions, and it would probably also need ZFS detection. If someone is willing to update the port: I have an original tarball 'gpart-0.1h.tar.gz'. It would need a new home ;-) Is that tarball different from what's on sunsite and currently fetched by the port? Best regards Matthias ___ 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: tracking lib dependencies
On Wed, Mar 16, 2011 at 5:47 PM, Robert Huff roberth...@rcn.com wrote: Jeremy Messenger writes: /libexec/ld-elf.so.1: Shared object libicui18n.so.38 not found, required by libavahi-glib.so.1 Command '['/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/Avahi-0.6', '--introspect-dump=/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/types.txt,/usr/ports/net/avahi-app/work/avahi-0.6.29/avahi-gobject/tmp-introspectz8YYb8/dump.xml']' returned non-zero exit status 1 gmake[3]: *** [Avahi-0.6.gir] Error 1 You need to follow icu update in the /usr/ports/UPDATING. Ok, did that: portupgrade -fr devel/icu I got a long list of successful rebuilds, plus avahi failing to build with the exact same error. Do you have libicui18n.so.38 in your system? Or like two icu ports installed? Or maybe portupgrade doesn't do upgrade in the right order, so try to use portmaster instead. Cheers, Mezz Robert Huff -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: Deprecation campaign
17.03.2011 02:33, Michel Talon пишет:
Hello,
i noted that ucpp is deprecated because it cannot be fetched
from original site. This is an alternate c preprocessor
supposed to be better than the gnu one, written by Thomas
Pornin. I happen to know the guy (*), so i searched if
the soft had been moved, and indeed it can be found here:
http://code.google.com/p/ucpp/
I hope you may reconsider your decision.
With my best regards
(*) i think he now runs a crypto firm in the Boston area.
I've tried to adopt the port to new distfile..
It builds but doesn't produce ucpp binary.
Maybe you or anybody can look what's wrong.
--
Regards,
Ruslan
diff -ruNa ucpp.orig/Makefile ucpp/Makefile
--- ucpp.orig/Makefile 2011-03-16 16:55:41.0 +0300
+++ ucpp/Makefile 2011-03-17 07:19:14.0 +0300
@@ -9,16 +9,16 @@
PORTNAME= ucpp
PORTVERSION= 1.3
CATEGORIES=devel
-MASTER_SITES= http://pornin.nerim.net/ucpp/
+MASTER_SITES= GOOGLE_CODE
MAINTAINER=po...@freebsd.org
COMMENT= A C preprocessor and lexer
-DEPRECATED= Upstream disapear and distfile is no more available
-EXPIRATION_DATE=2011-05-01
+LICENSE= BSD
MAN1= ucpp.1
PLIST_FILES= bin/ucpp
+USE_GMAKE= yes
do-install:
${INSTALL_PROGRAM} ${WRKSRC}/${PORTNAME} ${PREFIX}/bin
diff -ruNa ucpp.orig/distinfo ucpp/distinfo
--- ucpp.orig/distinfo 2005-11-24 18:40:02.0 +0300
+++ ucpp/distinfo 2011-03-17 07:04:01.0 +0300
@@ -1,3 +1,2 @@
-MD5 (ucpp-1.3.tar.gz) = f6f508ab42dd3eb57c0411a25429c9e8
-SHA256 (ucpp-1.3.tar.gz) =
6057028d96d349acd3de39a83f88f5772c422f822beb7f139dca8eabcf058bfa
-SIZE (ucpp-1.3.tar.gz) = 91537
+SHA256 (ucpp-1.3.tar.gz) =
d81bff52769325497d7663356ebebb358991e4c820b43aa60c40d65a29e9c376
+SIZE (ucpp-1.3.tar.gz) = 91626
diff -ruNa ucpp.orig/files/patch-Makefile ucpp/files/patch-Makefile
--- ucpp.orig/files/patch-Makefile 2003-07-29 00:59:02.0 +0400
+++ ucpp/files/patch-Makefile 2011-03-17 07:20:24.0 +0300
@@ -1,22 +1,22 @@
Makefile.orig Wed Jan 15 02:07:44 2003
-+++ Makefile Sun Jul 27 14:51:51 2003
+--- Makefile.orig 2008-10-01 21:15:41.0 +0400
Makefile 2011-03-17 07:10:39.0 +0300
@@ -56,8 +56,8 @@
#FLAGS = -O -m -DMEM_CHECK
# for gcc
-CC = gcc
--FLAGS = -g -W -Wall -ansi -DAUDIT -DMEM_DEBUG
+-FLAGS = -O3 -W -Wall -ansi
+CC ?= gcc
+FLAGS = -ansi -DAUDIT -DMEM_DEBUG
+ #FLAGS = -g -W -Wall -ansi -DAUDIT -DMEM_DEBUG
#FLAGS = -O3 -mcpu=pentiumpro -fomit-frame-pointer -W -Wall -ansi -DMEM_CHECK
#FLAGS = -O -pg -W -Wall -ansi -DMEM_CHECK
- #LDFLAGS = -pg
-@@ -80,7 +80,7 @@
+@@ -87,7 +87,7 @@
# - nothing should be changed below this line -
COBJ = mem.o nhash.o cpp.o lexer.o assert.o macro.o eval.o
--CFLAGS = $(FLAGS) -DSTAND_ALONE
-+CFLAGS += $(FLAGS) -DSTAND_ALONE
+-CFLAGS = $(FLAGS) $(STAND_ALONE)
++CFLAGS += $(FLAGS) $(STAND_ALONE)
all: ucpp
-
+ @ar cq libucpp.a *.o
diff -ruNa ucpp.orig/pkg-descr ucpp/pkg-descr
--- ucpp.orig/pkg-descr 2002-08-19 15:44:39.0 +0400
+++ ucpp/pkg-descr 2011-03-17 07:04:49.0 +0300
@@ -6,4 +6,4 @@
- Possibility to use the code as a lexer (that outputs tokens
directly)
-WWW: http://pornin.nerim.net/ucpp/
+WWW: http://code.google.com/p/ucpp/
___
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
