Re: multimedia/kbtv: broken saa kmod?
Hi Danny, On Thu, 15 Feb 2007 00:36:17 +0100 Danny Pansters wrote: I don't see this happening but I did get other (casting) errors that gcc calls warnings. Start with a fresh make extract then put the attached diffs in kbtv_wrksrc_dir/saa/patches/ That did it! The kernel module works fine. I managed to get a video from both B/W and color cameras (I use VIDEO input). Thanks, great! This makes it build for me on both amd64 and i386 (on STABLE). I haven't crawled under my desk yet and switched the TV card to my AMD box so I can only say that it compiles on amd (amd64 native, not in 32 bits mode I don't use that at all). I use: % uname -a FreeBSD srv.sem.ipt.ru 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Mon Jan 15 17:30:44 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: default postgresql 7.4 - 8.1, OK?
Ade Lovett wrote: 8.2.x isn't really stable enough yet for Joe User to pick it up when they want postgresql support for random-port. Agreed. Also, I know it doesn't concern many users, but until it gets the ICU patch it's mostly unusable to me. :( signature.asc Description: OpenPGP digital signature
Problems w/apache22 php5 running at 100%
Fellow geeks; After having upgraded to php5.2.1 via ports my server is constantly running at 100%, from about 5-10% earlier: $ ps auxwwf -ru | head -5 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND www 4596 47,9 2,2 33956 22880 ?? R 1:34pm 1:13,25 /usr/local/sbin/httpd -DNOHTTPACCEPT www 4525 35,3 1,7 29108 18184 ?? S 1:21pm 0:32,32 /usr/local/sbin/httpd -DNOHTTPACCEPT www 4610 6,6 1,7 28912 18032 ?? S 1:39pm 0:29,95 /usr/local/sbin/httpd -DNOHTTPACCEPT www 4593 0,8 2,0 31692 20676 ?? S 1:34pm 0:30,32 /usr/local/sbin/httpd -DNOHTTPACCEPT $ pkg_info | grep -e apache -e php -e mysql | cut -f 1 -d ' ' apache-2.2.4 mysql-client-5.1.15 mysql-server-5.1.15 p5-DBD-mysql-4.001 php5-5.2.1_1 php5-ctype-5.2.1_1 php5-curl-5.2.1_1 php5-dom-5.2.1_1 php5-exif-5.2.1_1 php5-extensions-1.1 php5-ftp-5.2.1_1 php5-gd-5.2.1_1 php5-gettext-5.2.1_1 php5-iconv-5.2.1_1 php5-mbstring-5.2.1_1 php5-mhash-5.2.1_1 php5-mysql-5.2.1_1 php5-pcre-5.2.1_1 php5-pdo-5.2.1_1 php5-pdo_sqlite-5.2.1_1 php5-posix-5.2.1_1 php5-recode-5.2.1_1 php5-session-5.2.1_1 php5-simplexml-5.2.1_1 php5-spl-5.2.1_1 php5-sqlite-5.2.1_1 php5-tokenizer-5.2.1_1 php5-xml-5.2.1_1 php5-xmlreader-5.2.1_1 php5-xmlwriter-5.2.1_1 $ uname -a FreeBSD hombre.grimstveit.no 6.2-RELEASE FreeBSD 6.2-RELEASE #25: Mon Jan 15 01:58:22 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOMBRE i386 Doing a multitail on all the access logs and error logs gives no indication why this should happen (0.5req/s), therefore I do not think it is related to too many incoming requests. Anybody else experiencing this? Thanks in advance for any help on this topic. -- Jakob Breivik Grimstveit / http://grimstveit.no/jakob ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
ParaView3 build and Qt4...
Hi all, I'm trying to build ParaView3 (2.9.8) on my freebsd box (6.2). I have successfully built Qt 4.2.2 and cmake 2.4.6. But when I run cmake to configure PV3, it complains about something missing related to Qt4 and X11 if I understand right: QT_X11_QMAKESPEC_LIBRARY QT_X11_QMAKESPEC_LIBRARY-NOTFOUND QT_X11_be_LIBRARY QT_X11_be_LIBRARY-NOTFOUND QT_X11_been_LIBRARY QT_X11_been_LIBRARY-NOTFOUND QT_X11_cannot_LIBRARY QT_X11_cannot_LIBRARY-NOTFOUND QT_X11_configuration_LIBRARY QT_X11_configuration_LIBRARY-NOTFOUND QT_X11_file:_LIBRARY QT_X11_file:_LIBRARY-NOTFOUND QT_X11_has_LIBRARY QT_X11_has_LIBRARY-NOTFOUND QT_X11_not_LIBRARY QT_X11_not_LIBRARY-NOTFOUND QT_X11_processing_LIBRARY QT_X11_processing_LIBRARY-NOTFOUND QT_X11_project_LIBRARY QT_X11_project_LIBRARY-NOTFOUND QT_X11_set,_LIBRARY QT_X11_set,_LIBRARY-NOTFOUND QT_X11_so_LIBRARY QT_X11_so_LIBRARY-NOTFOUND What does it mean ? Moreover, the QT_X11_* look very strange to me (not, been, has ???) ! What's wrong ? Thanks in advance. Cheers, -- Fred. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: amanda-client-2.5.1p3,1
On Thu, Feb 15, 2007 at 11:19:13AM +0900, Jun Kuriyama wrote: Thank you for your investigation. I've committed your patch into our repository. I just checked the amanda subversion repository and it looks like they made the same fix 3 days ago, so the patch should be able to go away at the next release. Craig ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ParaView3 build and Qt4...
On Thursday, 15. February 2007 15:59, fred wrote: Hi all, I'm trying to build ParaView3 (2.9.8) on my freebsd box (6.2). I have successfully built Qt 4.2.2 and cmake 2.4.6. But when I run cmake to configure PV3, it complains about something missing related to Qt4 and X11 if I understand right: QT_X11_QMAKESPEC_LIBRARY QT_X11_QMAKESPEC_LIBRARY-NOTFOUND Try running env QMAKESPEC=/usr/local/share/qt4/mkspecs/freebsd-g++ cmake . -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgpSvdTN3Kp3u.pgp Description: PGP signature
Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007, Michel Talon wrote: Give me a few weeks, and if I can band together with a few people I wanted to try and port sections of portupgrade and its related tools to C++ (and maybe do some code tweaks along the way). Most of the ruby files are over 400 lines long, sparsely commented, and I don't know ruby enough to port right now, but I've been making some headway lately so I'll try porting some stuff soon. I think that porting portupgrade to C++ would be time spent in vain. In my opinion, some of the basic ideas of portupgrade are deeply flawed, and as much as one polishes the algorithms it will not gain much. The idea of keeping state in databases is deeply flawed, it is constantly broken, and doesn't help in speed at all. This was one of the motivations of portmaster, get rid of database dependencies. In my opinion, upgrading progressiveley, that is, port by port, is deeply flawed. There is 90% chance that something will go wrong in the middle and you will be stuck with an half upgraded system. So in my opinion, what is needed is thinking radically new about the problem, write a prototype in a scripting language to experiment with the solutions, and then code it in C++. Personnally i have done that, i have written a python script, which can be found here: http://www.lpthe.jussieu.fr/~talon/pkgupgrade (it needs the companion http://www.lpthe.jussieu.fr/~talon/save_pkg.py). For the time being, i still have bugs, that i am working on, but at least these bugs show that the problem is vastly more complicated that one can imagine at first. Why python? because it is much more readable than perl or ruby, and much more performant than ruby. In may opinion ruby is vastly hyperhyped, it is much closer to rubish than anything else. What ideas? Don't use any database, database connector, do everything in memory, recompute needed information on the fly. It works very well, one can count on something of the order of 1mn to 2mn to perform the necessary analysis for 700 ports. Second, download as much precompiled packages as possible, at full speed, that is with the same connection to the ftp server. This works very well, if you have a good internet connection, in 15 mn to 20 mn you have your packages. Why packages? because packages don't break when compiling. Compiling from source is asking for problems. If you minimise the number of compilations you minimise the risk of breakage. Moreover simultaneously with downloading one can backup old packages, and so, gain time. By contrast, for every packages, portupgrade first does dependency analysis that could be done once, then does backup, then fetches the binary package or compiles, then installs it, then discards backup. Al this is terrible loss of time. Finally my script produces a shell script able to do the upgrade. So you can look in written form to *exactly* what will be removed, what will be installed by binary packages, and what will be compiled. All necessary packages for installation are already present on the machine. There is absolutely no element of surprise, you can evaluate the risk soundly. These are the ideas i have explored. Now, performance wise, when you run the shell script it takes around 2 hours. This is entirely time spent by pkg_delete ( roughly 15 mn) and pkg_add (roughly 1h45mn) for around 500 ports replaced. This is very long, sure, but it can be optimized only by working on pkg_delete and pkg_add. No amount of work on portupgrade or a replacement will help in any way. As for the remaining bugs i have, they are entirely due to the crappy complexity that FreeBSD port developers introduce by constantly modifying the origins of the ports. So for a given program, i can have 3 different origins, one when the port was previously installed on the machine, another one when the last RELEASE was produced, and the last one if i compile now the port on the machine with the present state of the ports tree. These 3 origins may be different, i have examples. These morons are *constantly* modifying the names, as an exercice in bikeshed painting. For example pan - pan2 - pan, etc. Cycles don't worry them at all! Of course, for a given software, you may have all combinations, such as inexistant or existant at the time the machine was installed, at the time of the release, or at present. Compare that to the situation for Debian apt-get. The names are conserved. They have strict rules about package naming, they stick to them and don't change them arbitrarily. All packages exist in compiled form, you don't have to worry about prepackaged or to be compiled, so has 50% chance to break. You have only 2 states to consider instead of 3: the state on the machine and the state on the repository. Things are vastly simpler. No wonders that apt-get works and portupgrade doesn't. This has nothing to do with the fact that apt-get is written in C++ (sorry to cross post, but this thread is just as relevant to @ports as it is to @hackers) Well,
Re: portupgrade O(n^m)?
2007. February 15. 19.17 dátummal [EMAIL PROTECTED] ezt írta: Compare that to the situation for Debian apt-get. The names are conserved. They have strict rules about package naming, they stick to them and don't change them arbitrarily. All packages exist in compiled form, you don't have to worry about prepackaged or to be compiled, so has 50% chance to break. You have only 2 states to consider instead of 3: the state on the machine and the state on the repository. Things are vastly simpler. No wonders that apt-get works and portupgrade doesn't. This has nothing to do with the fact that apt-get is written in C++ Sorry to pipe in, I just want to give the perspective of an ordinary FreeBSD user (since 5.1) who used debian before (and ventured into gentoo-land for a month or so just to run back screaming to freebsd). First of all I don't understand why you exaggerate - implying that you have to woryy because prepackaged or to be compiled, ... has 50% chance to break is simply not true. I just rebuild all my installed packages (615 in total) - and there were only two that broke during compile. Second, there is no generic binary builds that cater to all user's needs. So debian was forced to provide multiple packages for the same program (check out amarok debs or apache-mpm, apache-prefork, etc) built with different options that don't even conver all those options that ports provides me. If you wanted to have the same flexibility freebsd provides, you'll have to have even more duplicated versions of packages. The takes too much time argument against compiling is becoming less and less relevant as hardware improves, but even on my dusty athlon-xp server, how much time do you think I spend compiling? I have apache22, mysql50, php + lots of extensions (plus supporting libs like gd, netbpm) installed, and keeping all these up to date takes less then hour each month! There is not much difference when it comes to core capabilities of the OS between linux and freebsd - but the very reason I stay and will stay with freebsd in the forseeable future is because how ports/packages work. The only distribution that comes close to what I like about this binary system (I mean ports/packages) is arch linux, which is primarily package based but it has a build system similar to ports as well. I know I'm not a large scale user, but freebsd's build system and automatic package creation (installing ports with portinstall -p) came in handy a few times. I think FreeBSD already has an excellent binary package management system. I maintain some really old computers in a lab at our university, some of which can't run windowsXP, but they are excellent internet terminals (opera + gaim + gftp on top of blackbox with a simplified menu). I wanted to sqeeze out every last bit of performance from these machines, so I built a set of packages on my own computer, and lo and behold: I had a repository of binaries optimized for these machines that resolved dependencies automatically just like in debian, without having to learn how to build packages. I could simply download these packages through the lan, and pkg_add * them on each machine (well, four of them), and in a few minutes I had them up and running using packages specifically built for the capabilities of the hardware as well as exactly those options that users will need. Debian in this respect is far less flexible. Yes, you have src debs, but it is far more complicated than just passing -p to portinstall/upgrade. None of the linux distributions I have tried gave me this kind of flexibility and power - and I'm just an ordinary user, with no programming experience whatsoever. As to gentoo - I don't understand the technical issues. What I experienced, however, that gentoo simply relegates the brunt of the work of the port maintainers to the users, which results in far more breakage in everyday use than what I have experienced with FreeBSD. Took me days to configure the silly USE flags just to have sane defaults (I mean an emerge mc without it pulling entire xorg). I also had problems with removing components of packages that were installed via a metaport. During my time with gentoo (granted, it was two years ago) - I haven't seen anything that it can offer to me as a user over ports, but at least I have learnt to appreciate the tremendous work FreeBSD port maintainers put into port maintainance. Ports is simply far more user friendly than portage, with less breakage overall than I have experienced with portage. That's why I felt very unfair your exaggeration about ports breakage. Thats just my two cents, and I don't pretend to understand half of the issues raised in your post. I just know one thing: I twitch everytime I hear someone who wants ports to work more like portage (please please DON'T go there!) or argues for a binary package management. FreeBSD has already a kickass binary package management system. In
Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007 12:17:00 -0600, [EMAIL PROTECTED] wrote: snip = Pros: = -It's written in python (portable). Isn't our more portable for hardware than Python? Also, it is smaller? -It's a system which focuses on ports compilation from source, not binary package installation. This is very cons. The ports can do both, so it is more flexible and is pros than this. In our ports tree, you can even choice to create your own packages, install your own packages that was built by you, use FreeBSD packages or compile by via ports tree. -Stores information in a db format (not Berkeley DB, but something different)for entire system in a common file; stores installed leaf package information in another simple textfile. -Has flags for stability reasons, since some packages are alpha or beta and don't compile under certain architectures. No thanks, I am against this. I have seen the messy over at Gentoo's forums for you can't do the mix very well. Our ports have the better stability than their for in both stable and bleeding edge at the same time. I have used Gentoo before very long time ago and it is too often to break stuff, I personal prefer Slackware or Ubuntu over Gentoo and portage anytime for Linux. -Portage files are fetched via rsync. What is speical about it if you put rsync as in Cons? Why replace it when CVSup works fine? http://www.gentoo.org/news/en/gwn/20021223-newsletter.xml#doc_chap2_sect4 I do realize that it's 2002. -Has separate portage files which are phased out over time, in case the portage maintainers move the files in one release. The maintainers then create an informative message which describes what's going on while emerging the package or going through the portage database. If possible the outdated package is pruned and the newer, more recent dependency is merged. I don't think I like this. Same comments for this in the first top. = Cons: = -It's written in python (not fast). And it is not in base system. It requires Python to be install in the different way when our package system is based on Python. And Python breaks script more often than what we have in base system. -Uses rsync. Why put rsync in Pros too? :-) == Point: == snip === In light of previous statement: === I wasn't trying to port the pkg_* and port* utils to C++ thinking that I would magically get more optimized code. Sure, C++ is much better than ruby at optimizations if done correctly, but C++ is also easier to screw up than ruby or perl or python, because you have the power to shoot yourself in the foot easier (not as much as C or ASM, but close). The point was that with C++ we could finally get a set of standardized tools and a common interface for FreeBSD for managing ports / packages which could be included in the base system, not a bunch of little specialized tools and packages. If you can make C or C++ or whatever what we have in the base system tools better (is a must) than what we have now in ports tree, then I have no problem with it. Go ahead write it, but do expect for that it will be hard to get us to accept for our ports tree to change over to use new tools. Cheers, Mezz I'll have to approach this problem from a black box perspective and be carefully in planning this out, but my goal is to be as backwards compatible friendly as possible or at least provide migration tools to ease the move from the old system to the new one. Again, if anyone is interested in helping me out, it would be more than welcome. That way we could ensure that the project gets done in a timely manner and can reduce bugs and think of better solutions (more people can help in thinking out of the box, the larger the group). Thanks, -Garrett PS Please reply on the @hackers list, if possible. -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
portmaster and local ports (Was: Re: portupgrade O(n^m)?)
David Gilbert wrote: Jeremy == Jeremy Messenger [EMAIL PROTECTED] writes: Jeremy Give ports-mgmt/portmaster a try. I just did. One flaw it has is that I have two no longer supported ports installed. What do you mean by no longer supported? I want to run portmaster -a, but when it finds tund (and I assume it would also stop for xsysinfo), it stops. What do you mean it stops? Are you getting, Cannot cd to port directory? If so, one possible fix is to not fail if the port has an +IGNOREME file, but rather to issue a non-fatal warning. Would that work for you? I don't want to skip the port altogether at this point, since even if you have an +IGNOREME file for the port you may still want to be advised of new versions, moves, etc. I'd rather not just delete their package info --- it is still correct. The other alternative, as already suggested, is to create a ports skeleton for those two packages. For this purpose, all you'd need is a Makefile with: PKGNAME=foo-1.2.3 that matches what's in your +CONTENTS file. Adding the mechanism to ignore these ports (with no skeleton) is probably a good idea for the long run anyway, so if anyone has an idea besides what I suggested above, speak up. :) Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portmaster and local ports (Was: Re: portupgrade O(n^m)?)
On Thu, 15 Feb 2007 15:54:29 -0600, Doug Barton [EMAIL PROTECTED] wrote: David Gilbert wrote: Jeremy == Jeremy Messenger [EMAIL PROTECTED] writes: Jeremy Give ports-mgmt/portmaster a try. I just did. One flaw it has is that I have two no longer supported ports installed. What do you mean by no longer supported? I want to run portmaster -a, but when it finds tund (and I assume it would also stop for xsysinfo), it stops. What do you mean it stops? Are you getting, Cannot cd to port directory? If so, one possible fix is to not fail if the port has an I was wondering about that too, because it has never stop when I don't have any of ports in /usr/ports. Sometimes, when I forgot test some unoffical ports that aren't exist in ports tree and the portmaster has never stop. It only will tell about that it doesn't exists in ports tree and MOVED. But, I have not tried to run portmaster that I keep same port name with MOVED has a line about that port is removed yet. +IGNOREME file, but rather to issue a non-fatal warning. Would that work for you? I don't want to skip the port altogether at this point, since even if you have an +IGNOREME file for the port you may still want to be advised of new versions, moves, etc. I agree with you. I always move my ports from foobar to foobar-old and use marcusmerge to merge some of my unoffical ports into ports tree. Perhaps, add something like 'Do you really want it to be ignore? [With a bit explain about what is in MOVED], press yes or no'? Or/and add +REALLYANDREALLYIGNOREME? :-) I'd rather not just delete their package info --- it is still correct. It is correct for ports tree, but not to you when you want to keep it. :-) The other alternative, as already suggested, is to create a ports skeleton for those two packages. For this purpose, all you'd need is a Makefile with: PKGNAME=foo-1.2.3 that matches what's in your +CONTENTS file. Adding the mechanism to ignore these ports (with no skeleton) is probably a good idea for the long run anyway, so if anyone has an idea besides what I suggested above, speak up. :) Don't know, at least, I am 100% happy with portmaster and have not use portupgrade for months (maybe almost a year). ;-) Cheers, Mezz Doug -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://beta.inerd.com/portscout/[EMAIL PROTECTED] Port| Current version | New version +-+ audio/snd | 7.8 | 8.8 +-+ cad/tkgate | 1.8.6 | 1.8.7 +-+ databases/libzdb| 1.1.3 | 2.0 +-+ devel/gettext-lint | 0.3.1 | 0.4 +-+ devel/gwenhywfar| 1.13.2 | 2.5.3 +-+ devel/premake | 2.4 | 3.3-rc1 +-+ devel/t1lib | 5.1.0 | 5.1.1 +-+ editors/code-browser| 2.11| 2.12 +-+ editors/texmacs | 1.0.6.7 | 1.0.6.9 +-+ graphics/gsculpt| 0.3 | 0.99.38.1-alpha +-+ graphics/pixie | 1.6.3 | 2.0.1 +-+ japanese/linux-JM | 20050615| 20070215 +-+ japanese/lyx| 1.0.3 | 1.4.4 +-+ lang/sisc | 1.9.7 | 1.16.6 +-+ lang/smalltalk | 2.3.1 | 2.3.3 +-+ mail/milter-greylist-devel | 2.0b1 | 3.1.6 +-+ math/add| 20021229| 20070214 +-+ math/fxt| 2006.12.17 | 2007.02.14 +-+ net/lam | 7.1.2 | 7.1.4b1 +-+ net-p2p/phex| 2.2.0.83| 3.0.2.100 +-+ sysutils/hourglass | 1.0.0 | 1.0.1b +-+ textproc/p5-Bloom-Filter| 0.03| 1.0 +-+ www/mod_python | 2.7.11 | 3.3.1 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://beta.inerd.com/portscout-portconfig.txt If you need help, have any problems, find a bug in this software, or wish to stop (or start!) receiving portscout reminders, feel free to contact me at [EMAIL PROTECTED] Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
[semi-OT] Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007, Jeremy Messenger wrote: On Thu, 15 Feb 2007 12:17:00 -0600, [EMAIL PROTECTED] wrote: snip = Pros: = -It's written in python (portable). Isn't our more portable for hardware than Python? Also, it is smaller? -It's a system which focuses on ports compilation from source, not binary package installation. This is very cons. The ports can do both, so it is more flexible and is pros than this. In our ports tree, you can even choice to create your own packages, install your own packages that was built by you, use FreeBSD packages or compile by via ports tree. -Stores information in a db format (not Berkeley DB, but something different)for entire system in a common file; stores installed leaf package information in another simple textfile. -Has flags for stability reasons, since some packages are alpha or beta and don't compile under certain architectures. No thanks, I am against this. I have seen the messy over at Gentoo's forums for you can't do the mix very well. Our ports have the better stability than their for in both stable and bleeding edge at the same time. I have used Gentoo before very long time ago and it is too often to break stuff, I personal prefer Slackware or Ubuntu over Gentoo and portage anytime for Linux. -Portage files are fetched via rsync. What is speical about it if you put rsync as in Cons? Why replace it when CVSup works fine? http://www.gentoo.org/news/en/gwn/20021223-newsletter.xml#doc_chap2_sect4 Well, it takes a lot of time with the diffs and all in rsync.. that's why I added it to the cons. I have no clue why I accidentally added it to the pros as well. Probably did some copying and pasting from my original letter and forgot to delete that part . I just think that it would be nice to get a common solution for all these items. I dislike gentoo after 2 years of use and switched over to FreeBSD because overall the system is much better (in particular more stable). I just want to help make a great system even better--that's all; the only parts of the system I can possibly thinking of improving that also align with my interests are the ports system and sound system (daemonizing it like ALSA, instead of having stuff block /dev/dsp, /dev/mixer, like OSS). -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
linphone: SDL and configure ?
This is related to the linphone-base port, which has its own
problems, but still...
I am trying to enable video support for it, and the first
problem is that its configure script does not detect SDL
unless i put an additiona -lpthread in CFLAGS (because libSDL
requires some pthread functions). The following patch does the job:
USE_AUTOTOOLS= libtool:15
LIBTOOLFILES= configure oRTP/configure
-CONFIGURE_ENV= CPPFLAGS=${CPPFLAGS} LDFLAGS=${LDFLAGS}
+CONFIGURE_ENV= CFLAGS=${CFLAGS} -lpthread CPPFLAGS=${CPPFLAGS}
LDFLAGS=${LDFLAGS}
CONFIGURE_ARGS=--disable-ipv6 --disable-gtk-doc --enable-gnome_ui=no \
--disable-ewarning --without-ilbc --disable-strict \
--with-speex=${LOCALBASE} --with-osip=${LOCALBASE} \
+ --enable-video --with-sdl=${LOCALBASE} \
--with-html-dir=${DOCSDIR}
but if i just add -lpthread to LDFLAGS the linking (during configure)
fails. Any ideas why ?
cheers
luigi
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [semi-OT] Re: portupgrade O(n^m)?
On Thu, February 15, 2007 4:32 pm, [EMAIL PROTECTED] wrote: On Thu, 15 Feb 2007, Jeremy Messenger wrote: I just want to help make a great system even better--that's all; the only parts of the system I can possibly thinking of improving that also align with my interests are the ports system and sound system (daemonizing it like ALSA, instead of having stuff block /dev/dsp, /dev/mixer, like OSS). Enable the virtual channel support (see output of sysctl -a | grep vchans) and the kernel will automatically mix multiple sound streams into one, and auto-assign programs to the different /dev/dsp0.* devices as needed. Much nicer than the ALSA methods, and something that FreeBSD has handled for a *long* time. :) Freddie Cash [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [semi-OT] Re: portupgrade O(n^m)?
On Thu, Feb 15, 2007 at 04:32:00PM -0800, [EMAIL PROTECTED] wrote: I just want to help make a great system even better--that's all; the only parts of the system I can possibly thinking of improving that also align with my interests are the ports system and sound system (daemonizing it like ALSA [...] ) I for one much prefer the FreeBSD way of handling sound over the ALSA method. IMO, ALSA is overengineered and introduces unnecessary complexity into the lives of both application designers and end users. Take for example the task of playing multiple PCM streams simultaneously on a device which supports only a single hardware channel (99% of integrated sound chips). ALSA: * Edit some config files to set up a virtual sound device and force it to be first in the ordering. If you're lucky you're using a distro that has already done this for you. * The mixing happens in a userspace daemon, that you hope isn't swapped out or accidentally killed. Hope that the kernel schedules it often enough to do its job. Incur extra context switching and IPC costs. * This only works for applications that use the ALSA API. Others must be run under aoss or equivalent, which has the same issues as esddsp and artsdsp (problematic mmap support, for one) FreeBSD: * sysctl hw.snd.maxautovchans=8 instead of having stuff block /dev/dsp, /dev/mixer, like OSS Enable vchans and it'll be just like having a sound card that can do hardware mixing. FreeBSD's sound API is compatible with OSS, but it by no means has the same limitations as Linux's OSS implementation did. I've never had any problems with contention over /dev/mixer, even when using multiple applications that want to adjust the mixer settings... The only advantage I can see ALSA having is MIDI support, which has atrophied as of late in the FreeBSD world. That's not really a product of the architecture so much as not having enough interested developers. Craig ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [semi-OT] Re: portupgrade O(n^m)?
On Thu, Feb 15, 2007 at 05:30:29PM -0800, Freddie Cash wrote: Enable the virtual channel support (see output of sysctl -a | grep vchans) and the kernel will automatically mix multiple sound streams into one, and auto-assign programs to the different /dev/dsp0.* devices as needed. Much nicer than the ALSA methods, and something that FreeBSD has handled for a *long* time. :) Someday I hope that in a future release maxautovchans will be set by default on cards that don't support hardware channels, so it can just work no matter what your hardware is. I know 4.x had some stability problems with dynamic vchans vs static ones, but it seems to be solid since 5.1 or 5.2. Craig ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [semi-OT] Re: portupgrade O(n^m)? (fwd)
On Thu, 15 Feb 2007, Craig Boston wrote: On Thu, Feb 15, 2007 at 05:30:29PM -0800, Freddie Cash wrote: Enable the virtual channel support (see output of sysctl -a | grep vchans) and the kernel will automatically mix multiple sound streams into one, and auto-assign programs to the different /dev/dsp0.* devices as needed. Much nicer than the ALSA methods, and something that FreeBSD has handled for a *long* time. :) Someday I hope that in a future release maxautovchans will be set by default on cards that don't support hardware channels, so it can just work no matter what your hardware is. I know 4.x had some stability problems with dynamic vchans vs static ones, but it seems to be solid since 5.1 or 5.2. Craig Oh, cripe.. well glad I mentioned something instead of started working on this. Lol. Frick.. Why isn't this enabled by default?? -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
On Thu, 15 Feb 2007 10:17:00 -0800 (PST) [EMAIL PROTECTED] wrote: I wasn't trying to port the pkg_* and port* utils to C++ thinking that I would magically get more optimized code. Sure, C++ is much better than ruby at optimizations if done correctly, but C++ is also easier to screw up than ruby or perl or python, because you have the power to shoot yourself in the foot easier (not as much as C or ASM, but close). Surely that's the other way around, scripting languages are for quick and dirty, C and C++ are used for multi-million line projects. The point was that with C++ we could finally get a set of standardized tools and a common interface for FreeBSD for managing ports / packages which could be included in the base system, not a bunch of little specialized tools and packages. That sounds like Trebant advocacy to me. I'm all for giving the ports system a more flexible API for port-tools, particularly in the area of dependency management,but different people have different priorities. I like having a choice. Just before I tried FreeBSD I tried Gentoo, and emerge tied itself in knots trying to upgrade Gnome. I'm pretty sure that portupgrade would have failed on that upgrade too, but based on its record with Gnome, Portmanager would likely have taken it in its stride. OTOH it often takes several times as long as an optimally fast solution, and most people don't like that. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
any maintainer for linphone ?
Is anyone working on the linphone port, or i can do that ? I managed to make linphone 1.6.0 work with video4linux and libosip2.2.2, so would like to replace the old port. If someone else is working on it, please contact me. I am cc-ing the osip2 maintainer because it seems that linphone does not work with osip2.2.3 which is in ports, and was wondering what other apps use osip2.2.3 and how to solve the issue cheers luigi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impending update to devel/gettext
On Feb 13, 2007, at 00:23 , Peter Johnson wrote: The correct fix is probably a patch to the gettext configure script to disable the check for gmkdir. Hi Peter, Please see http://www.lovett.com/ade/freebsd/gettext-4.diff MD5 (gettext-4.diff) = 792085ea01e8242e7e0260bad3336efd This should address your issues with sysutils/coreutils being around, and gettext picking up on gmkdir. Everyone, In addition, as part of the ongoing cleanup of the tree as a result of the deprecation of 4.x for the ports world, devel/gettext will now FAIL (strangely) on 4.x. This is on purpose, and I have no plans to change things back. I'm not even going to put in a BROKEN on 4.x stanza, since work is underway to remove those from the tree. Naturally, with the number of ports depending on devel/gettext, this will be a pretty good sledgehammer blow. Assuming no further issues, I will be committing this update on or around 1st March 2007. Thanks to everyone who has provided input on this patch to date. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impending update to devel/gettext
On Thu, 15 Feb 2007 22:01:03 -0600, Ade Lovett [EMAIL PROTECTED] wrote: On Feb 13, 2007, at 00:23 , Peter Johnson wrote: The correct fix is probably a patch to the gettext configure script to disable the check for gmkdir. Hi Peter, Please see http://www.lovett.com/ade/freebsd/gettext-4.diff MD5 (gettext-4.diff) = 792085ea01e8242e7e0260bad3336efd This should address your issues with sysutils/coreutils being around, and gettext picking up on gmkdir. I have updated it in MC without bump it, but I always can bump it for gmkdir issue if one of my team request. Is it rare? If it is, then I think anyone can always reinstall it. :-) Everyone, In addition, as part of the ongoing cleanup of the tree as a result of the deprecation of 4.x for the ports world, devel/gettext will now FAIL (strangely) on 4.x. This is on purpose, and I have no plans to change things back. I'm not even going to put in a BROKEN on 4.x stanza, since work is underway to remove those from the tree. Naturally, with the number of ports depending on devel/gettext, this will be a pretty good sledgehammer blow. Sounds good, I think that Kris said that 4.x support are going to be gone in our tree (include bsd.*.mk) sometime soon (unsure on when, but soon). Assuming no further issues, I will be committing this update on or around 1st March 2007. Thanks to everyone who has provided input on this patch to date. There is no issue with GNOME 2.17/2.18 in MC so far. Cheers, Mezz -aDe -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any maintainer for linphone ?
On Fri, Feb 16, 2007 at 05:15:34AM +0100, Soeren Straarup wrote: On Thu, Feb 15, 2007 at 07:35:29PM -0800, Luigi Rizzo wrote: Is anyone working on the linphone port, or i can do that ? I managed to make linphone 1.6.0 work with video4linux and libosip2.2.2, so would like to replace the old port. If someone else is working on it, please contact me. I am cc-ing the osip2 maintainer because it seems that linphone does not work with osip2.2.3 which is in ports, and was wondering what other apps use osip2.2.3 and how to solve the issue http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/105884 But it is for 1.3.5. I'll give it a try thanks, i saw it, but it seems quite a large diff, considering that all it takes to build 1.6.0 (and presumably 1.3.5 as well) is downgrade the libosip to 2.2.2 Basically i am trying to figure out if there is anything in the ports tree that needs osip2.2.3, and if so, how to use another version for linphone. cheers luigi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impending update to devel/gettext
On Thu, Feb 15, 2007 at 10:34:27PM -0600, Jeremy Messenger wrote: Sounds good, I think that Kris said that 4.x support are going to be gone in our tree (include bsd.*.mk) sometime soon (unsure on when, but soon). After the next -exp run. He and I are merging our changes to do this. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Impending update to devel/gettext
On Feb 15, 2007, at 20:34 , Jeremy Messenger wrote: I have updated it in MC without bump it, but I always can bump it for gmkdir issue if one of my team request. Is it rare? If it is, then I think anyone can always reinstall it. :-) It'll only affect you if you happen to have an old devel/gettext installed, sysutils/coreutils installed, and don't deinstall coreutils before trying to update gettext. So year, pretty rare. Certainly not worth a version bump. It'll be 0.16.1 when it goes to the main three. Sounds good, I think that Kris said that 4.x support are going to be gone in our tree (include bsd.*.mk) sometime soon (unsure on when, but soon). AIUI, the final sweep will be done before 3/1, which is why I chose that date. If it gets delayed for any reason, then I'll wait until that update happens before committing. There is no issue with GNOME 2.17/2.18 in MC so far. Excellent. Good to hear. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any maintainer for linphone ?
On Thu, Feb 15, 2007 at 07:35:29PM -0800, Luigi Rizzo wrote: Is anyone working on the linphone port, or i can do that ? I managed to make linphone 1.6.0 work with video4linux and libosip2.2.2, so would like to replace the old port. If someone else is working on it, please contact me. I am cc-ing the osip2 maintainer because it seems that linphone does not work with osip2.2.3 which is in ports, and was wondering what other apps use osip2.2.3 and how to solve the issue http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/105884 But it is for 1.3.5. I'll give it a try /Soeren -- Soeren Straarup | aka OZ2DAK aka Xride FreeBSD committer | FreeBSD since 2.2.6-R If a program is not working right, then send a patch ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: linphone: SDL and configure ?
Luigi Rizzo wrote: but if i just add -lpthread to LDFLAGS the linking (during configure) fails. Any ideas why ? Probably simply a bad coded configure. Try to look at m4/video.m4. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ParaView3 build...
Michael Nottebrock wrote: Try running env QMAKESPEC=/usr/local/share/qt4/mkspecs/freebsd-g++ cmake . Works much better, thanks ! By the way, PV3 does not find some ffmpeg libs, whereas ffmpeg is well installed. FFMPEG_INCLUDE_DIR */usr/local/include FFMPEG_avcodec_LIBRARY */usr/local/lib/libavcodec.so FFMPEG_avformat_LIBRARY */usr/local/lib/libavformat.so FFMPEG_avutil_LIBRARY *FFMPEG_avutil_LIBRARY-NOTFOUND FFMPEG_dc1394_LIBRARY *FFMPEG_dc1394_LIBRARY-NOTFOUND FFMPEG_dts_LIBRARY */usr/local/lib/libdts.a FFMPEG_gsm_LIBRARY *FFMPEG_gsm_LIBRARY-NOTFOUND FFMPEG_theora_LIBRARY */usr/local/lib/libtheora.so FFMPEG_vorbis_LIBRARY */usr/local/lib/libvorbis.so FFMPEG_vorbisenc_LIBRARY*/usr/local/lib/libvorbisenc.so FFMPEG_z_LIBRARY*/usr/lib/libz.so Any idea ? Cheers, -- http://scipy.org/FredericPetit ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
