Re: net/grsync fails to build on i386
On Tue, 25 Mar 2008 23:12:56 +0200, Peter Pentchev wrote Hi Peter, It is quite possible that you caught the small time window just after the GNOME upgrade, in which bsd.gnome.mk was missing two lines that recorded LIB_ and RUN_DEPENDS. Thus, even though you specified gtk20 in your port's Makefile, bsd.gnome.mk just didn't add a dependency on libgtk - so your port's build did not find it. Since this was corrected a couple of hours later, I strongly suspect that the next automated build will go just fine. Thank you very much for your answer. It must explain why I was not able to reproduce the problem... I'll wait for the next build :) Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: net/grsync fails to build on i386
On Tue, 25 Mar 2008 23:55:06 -0500, Jeremy Messenger wrote Hi Jeremy, No, it's not USE_XLIB. It's bsd.gnome.mk problem that was fixed by marcus yesterday. Two lines were removed by accident. It's what I believe that caused these logs. Yes, Peter told me about that :p Thanks a lot for your answer too ! Best regards, Ganaël LAPLANCHE [EMAIL PROTECTED] http://www.martymac.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
There is no way to know what port options mean (in general)
Hi all, I had posted this as a send-pr, and Edwin (reasonably) suggested that the denizens of this list might prefer to discuss it here, than in GNATS. Fair enough. The issue: make config in many port directories produces an interactive dialog where one may select various make environment variables to be set. There is a one line description of each flag, to help one make this selection. Unfortunately, in many situations, this description is unhelpful, as flag FOO will have description foo support, or possiblly libfoo support. Unless one is fairly well familiar with both the package and the libraries, one can not readily know what the implications of setting these controls one way or the other is. To complicate things, some options are mutually exclusive, and one only discovers this when the build or install subsequently fails. How-To-Repeat: make config something like print/ghostscript-gpl, and wonder what a FreeType bridge might be (bridge, as opposed to just using the FreeType library to render TrueType fonts?) Notice that SVGALIB -- svgalib support doesn't mention that svgalib is i386-only: you have to wait for the build to fail to discover that. Suggestion: In lieu of interactive F1 or ? keys popping up descriptive windows (which could be nice), it would be keen if ports could grow a new target with a name like desc-config that would print out a paragraph (supplied by the port creator/maintainer) that had at least a(n) (explicit) reference to the port that the config knob pulled in as a dependency. Better would be a short paragraph about why one might want to do that, and perhaps what alternatives might exist. Thoughts: ? Cheers, -- Andrew ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: net/grsync fails to build on i386
On Tue, Mar 25, 2008 at 08:46:47PM +0100, Ganael LAPLANCHE wrote: Hi everybody, I try to understand what happens here : http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.2008032407/grsync-0.6.1.log Since yesterday, my net/grsync port seems to refuse to build on i386. The configure script uses (expanded) : pkg-config --exists --print-errors 'gtk+-2.0' which leads to the error 'No package 'gtk+-2.0' found'. This error message is clear. What I don't understand is that the dependency against gtk20 is explicitly specified in the Makefile, so why has gtk+-2.0 not been installed during the build process (and does not appear in the log file) ? Am I missing something ? It is quite possible that you caught the small time window just after the GNOME upgrade, in which bsd.gnome.mk was missing two lines that recorded LIB_ and RUN_DEPENDS. Thus, even though you specified gtk20 in your port's Makefile, bsd.gnome.mk just didn't add a dependency on libgtk - so your port's build did not find it. Since this was corrected a couple of hours later, I strongly suspect that the next automated build will go just fine. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 I am not the subject of this sentence. pgpRPJtpCA9bC.pgp Description: PGP signature
Re: portmaster and BROKEN ports
On Tue, Mar 25, 2008 at 03:39:11PM -0700, Doug Barton wrote: Willy Picard wrote: I would like to know if there is a smart way to ask portmaster to ignore BROKEN ports. Currently I added a +IGNOREME file to all BROKEN ports I have but I would like portmaster to automatically ignore these ports without the +IGNOREME file. Sorry, portmaster hasn't developed psychic abilities yet, so it can't know for sure what you want to do with your broken ports vs. what all the other portmaster users want to do with them. :) Well, I am not thinking about paranormal abilities for portmaster, I was rather thinking about a nice option (e.g. --ignore-broken) that would allow postmaster to ignore BROKEN ports during a postmaster -a. Currently, I have the www/flock port installed. This port is marked as BROKEN (not by me, so this is not my broken port but a broken port). When I run postmaster -a, postmaster exists before updating of ports because flock is broken. I therefore add a +IGNOREME file in the /var/db/pkg/flock-* dir. However, if the flock port is not marked BROKEN tomorrow, I will have to 1) detect this fact, 2) remove the +IGNOREME file. portupgrade simply ignores BROKEN ports during a portupgrade -a. I am not even asking about a similar behaviour for portmaster. I wanted just to ask if an option allows to do the same. If no such an option exists, I think that its addition to the functionality of portmaster may be worth considering. Best regards, Willy Picard -- Willy Picarde-mail: [EMAIL PROTECTED] Dept. of Information Technology www:http://www.kti.ae.poznan.pl/ The Poznan University of Economics tel:+48 61 848 05 49 Mansfelda 4, 60-854 Poznan, Poland fax:+48 61 848 38 40 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: There is no way to know what port options mean (in general)
On Wed, 26 Mar 2008, Andrew Reilly wrote: Suggestion: In lieu of interactive F1 or ? keys popping up descriptive windows (which could be nice), it would be keen if ports could grow a new target with a name like desc-config that would print out a paragraph (supplied by the port creator/maintainer) that had at least a(n) (explicit) reference to the port that the config knob pulled in as a dependency. Better would be a short paragraph about why one might want to do that, and perhaps what alternatives might exist. Thoughts: ? Twofold: 1 - descriptions don't hurt 2 - OPTIONS interdependencies are something else, and something which goes much in the direction of Linux's make config/xconfig/gconfig/menuconfig kconf framework -- Matthias Andree ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: ports system woes
There is a newly-spawned discussion on -hackers about the inefficiencies the existing pkg_* utiliies (e.g. pkg_delete taking minutes to operate, etc.): http://lists.freebsd.org/pipermail/freebsd-hackers/2008-March/024057.html Those who wish to participate should probably be people who are familiar with both the ports framework and actual C code; IMHO it should not be a let's talk about features I want thread. Just bringing this to other technical users' attention who may feel inclined to participate. Stephen, I'm CC'ing you because I know you've put in great efforts fixing said inefficiencies in the past. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
You've received A Hallmark E-Card!
[1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the Privacy and Security link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://ns1.apunto-host.com/~felipe/card.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: There is no way to know what port options mean (in general)
On Wed, Mar 26, 2008 at 04:33:28PM +1100, Andrew Reilly wrote: make config in many port directories produces an interactive dialog where one may select various make environment variables to be set. There is a one line description of each flag, to help one make this selection. Unfortunately, in many situations, this description is unhelpful, as flag FOO will have description foo support, or possiblly libfoo support. Unless one is fairly well familiar with both the package and the libraries, one can not readily know what the implications of setting these controls one way or the other is. What you want is something like what some ports offer (but it's a per-port thing): make showconfig, which describes all the available knobs in detail. I'm not saying what you want is unreasonable -- it's very reasonable. But there's no existing ports framework for documenting OPTIONS features in verbose detail for all ports which use OPTIONS. At this time it's a per port thing, and up to the port maintainer. Solving this problem: I don't agree with something like a pkg-options-descr file in each port, because that drastically increases the number of inodes used on the filesystem. Simultaneously, sticking long and verbose texts inside of the Makefile only clutters things. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to build cups-base-1.3.6_1
Hi, On Tue, Mar 25, 2008 at 06:35:42PM -0400, Gerard wrote: I just finished updating the Gstreamer port. As per the instructions in UPDATING, I ran 'portupgrade -f gstreamer-plugins-good' after first running 'portupgrade -a'. Everything built except the cups-base port. Same here. subscriptions.o(.text+0x1a71): In function `cupsdAddEvent': /data/tmp/usr/ports/print/cups-base/work/cups-1.3.6/scheduler/subscriptions.c:1337: undefined reference to `dbus_message_append_iter_init' ^ I assumed some problems (lost files, overwritten .h-files or libs ... ) with my installed dbus-* and recompiled portupgrade -Of dbus-*. Didn't change anything about cups-base. No idea here, help needed. TIA Raphael Becker -- Raphael Becker [EMAIL PROTECTED] http://rabe.uugrn.org/ GnuPG:E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .|.|.|.|.|.|.|.. pgpCtGj2yKPI5.pgp Description: PGP signature
Re: ports system woes
Hi, I have read your mail on hackers@ (I'm not subscribed) with great interest. We're certainly interested in any optimizations for the pkg_install suite. The pkg database in /var/db/pkg stores two-way dependency chains. Each port lists all it's dependencies in +CONTENTS file, and all ports that depend on it in +REQUIRED_BY. When you delete package, all dependencies of deleted package are iterated and the name of deleted package is removed from dependency's +REQUIRED_BY file. That's what undepend() do. Quick solution would be to gather all depnames for the deleted package, and then do a single pass over /var/db/pkg entries looking for origins. Ultimate solution would be to implement a database which would concentrate origins for all packages with linear lookup time. The OpenSSL thing I assume is only relevant for people who happen to have OpenSSL installed from ports. For that, it could be solved by spamming the required value into /etc/make.conf, similar what perl ports do. But that really is up to the openssl port maintainer ([EMAIL PROTECTED]). -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] If God is perfect, why did He create discontinuous functions? signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: ports system woes
Pav Lucistnik wrote: Quick solution would be to gather all depnames for the deleted package, and then do a single pass over /var/db/pkg entries looking for origins. Ultimate solution would be to implement a database which would concentrate origins for all packages with linear lookup time. In fact last year i wrote a python script which reads all the /var/db/pkg/+CONTENTS files, and fixes all the +REQUIRED_BY files, assuming they are corrupted. Moreover it follows the MOVED file. Optionnally it decomposes the set of ports in connected components, and builds graphviz graphs for the dependencies. Of course the leaf packages are written down. As far as i remember this program runs in a few *seconds* certainly not minutes like it is said here for the pkg_delete stuff. You can find it here: http://www.lpthe.jussieu.fr/~talon/pkg_check.py This being said, i agree with you, that for various reasons, the package system needs to get rid of the extremely bad idea of abusing the filesystem as a database, and use a true database for doing its job. This would allow O(1) searches, as you are saying, and would allow to perform appropriate locking for supporting parallel builds. We had this discussion last year, and i am even more convinced that the good solution is to use sqlite and not some half-assed solution like a Berkeley database, if only because using a sql database will lead naturally to a more structured solution, and not a pile of blobs, and also because sqlite is a stable software. More generally i disagree with Kris Kennaway idea that all is required is to polish the existing tools. They are so obviously broken from all points of view, particularly portupgrade, that only a complete rewrite can do any good. Needless to say, this cannot please those FreeBSD ports afficionados who are convinced that their toy is the best in the world. Let me recall that *one* person has completely rewritten the ports system for OpenBSD (Marc Espie), including the pkg* tools and all the Makefile scripts, and now it works. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
On Wed, 2008-03-26 at 14:18 +0100, Michel Talon wrote: More generally i disagree with Kris Kennaway idea that all is required is to polish the existing tools. They are so obviously broken from all points of view, particularly portupgrade, that only a complete rewrite can do any good. Um, while I agree with part of what you said, this is just plain not true. The existing tools can easily be fixed as soon as someone takes the time to actually do it; a rewrite is neither necessary nor desirable. Portupgrade is, in fact, my preferred application, although lately I've had to move to portmaster just because of the O(n^2) inefficiencies. It doesn't need to be replaced, it needs to be fixed, and Pav's suggested fix is one place to start. Needless to say, this cannot please those FreeBSD ports afficionados who are convinced that their toy is the best in the world. Let me recall that *one* person has completely rewritten the ports system for OpenBSD (Marc Espie), including the pkg* tools and all the Makefile scripts, and now it works. Oh, please. The FreeBSD ports system works as well. Instead of complaining, why don't you actually do someting about it? Code speaks louder than mere words. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to build cups-base-1.3.6_1
On Wed, 2008-03-26 at 11:20 +0100, Raphael Becker wrote: Hi, On Tue, Mar 25, 2008 at 06:35:42PM -0400, Gerard wrote: I just finished updating the Gstreamer port. As per the instructions in UPDATING, I ran 'portupgrade -f gstreamer-plugins-good' after first running 'portupgrade -a'. Everything built except the cups-base port. Same here. subscriptions.o(.text+0x1a71): In function `cupsdAddEvent': /data/tmp/usr/ports/print/cups-base/work/cups-1.3.6/scheduler/subscriptions.c:1337: undefined reference to `dbus_message_append_iter_init' ^ I assumed some problems (lost files, overwritten .h-files or libs ... ) with my installed dbus-* and recompiled portupgrade -Of dbus-*. Didn't change anything about cups-base. The problem is really that configure fails to resolve a couple of pthread functions. I fixed it by putting LIBS=-lpthread in my environment before rebuilding the port. This is a kludge, though; the port maintainer needs to fix this. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: There is no way to know what port options mean (in general)
On Wed, Mar 26, 2008 at 02:38:58AM -0700, Jeremy Chadwick wrote: On Wed, Mar 26, 2008 at 04:33:28PM +1100, Andrew Reilly wrote: make config in many port directories produces an interactive dialog where one may select various make environment variables to be set. There is a one line description of each flag, to help one make this selection. Unfortunately, in many situations, this description is unhelpful, as flag FOO will have description foo support, or possiblly libfoo support. Unless one is fairly well familiar with both the package and the libraries, one can not readily know what the implications of setting these controls one way or the other is. What you want is something like what some ports offer (but it's a per-port thing): make showconfig, which describes all the available knobs in detail. The showconfig target is actually not a per-port thing, though I suppose some ports could over-ride it. By default it doesn't give any more information than what is contained in the config screen. I'm not saying what you want is unreasonable -- it's very reasonable. But there's no existing ports framework for documenting OPTIONS features in verbose detail for all ports which use OPTIONS. At this time it's a per port thing, and up to the port maintainer. Solving this problem: I don't agree with something like a pkg-options-descr file in each port, because that drastically increases the number of inodes used on the filesystem. Simultaneously, sticking long and verbose texts inside of the Makefile only clutters things. While, it has to go somewhere and as a maintainer I have no problem printing out a description of each option inside a custom target. What's important is that there be some consistency in what that target is called. Even better would be to provide a framework to ease the work maintainers have to do. I envision the following: - For each available option have a variable called DESC_$FOO which is a string which describes that option in detail. - Whatever that target is called should be in bsd.ports.mk and output the contents of DESC_$FOO. Maybe I'll work on this in my free time. :) -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
On Wed, 26 Mar 2008 14:18:00 +0100, Michel Talon wrote In fact last year i wrote a python script which reads all the /var/db/pkg/+CONTENTS files, and fixes all the +REQUIRED_BY files, assuming they are corrupted. Moreover it follows the MOVED file. So you basically reimplemented pkgdb -F in python? As far as i remember this program runs in a few *seconds* certainly not minutes like it is said here Mind that the original poster is using a very low-spec notebook with next to none RAM. solution is to use sqlite and not some half-assed solution like a Berkeley database, Solution is to use tools that are available in our base system. SQLite is not. -- Pav Lucistnik [EMAIL PROTECTED] [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: ports system woes
Frank Mayhar wrote: Portupgrade is, in fact, my preferred application, although lately I've had to move to portmaster just because of the O(n^2) inefficiencies. It doesn't need to be replaced, it needs to be fixed, I have rarely seen such a wonderful contradiction between the two halves of the same sentence. Oh, please. The FreeBSD ports system works as well. Instead of No, it doesn't or it does barely. complaining, why don't you actually do someting about it? Code speaks louder than mere words. We have learnt recently that many people have brought code to the table, including myself, only to be scorned by people of your sort. I have yet to see people like you contributing any testing or discussion when code is offered, all you are good for is parrotting Code speaks louder than mere words. -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
On Wed, 2008-03-26 at 14:59 +0100, Pav Lucistnik wrote: On Wed, 26 Mar 2008 14:18:00 +0100, Michel Talon wrote In fact last year i wrote a python script which reads all the /var/db/pkg/+CONTENTS files, and fixes all the +REQUIRED_BY files, assuming they are corrupted. Moreover it follows the MOVED file. So you basically reimplemented pkgdb -F in python? No. I'm not sure what he did implement, but it's not pkgdb -F. As far as i remember this program runs in a few *seconds* certainly not minutes like it is said here Mind that the original poster is using a very low-spec notebook with next to none RAM. That having been said, O(n^2) algorithms are generally not a good idea. solution is to use sqlite and not some half-assed solution like a Berkeley database, Solution is to use tools that are available in our base system. SQLite is not. Indeed. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: There is no way to know what port options mean (in general)
On Wed, 26 Mar 2008 09:36:11 -0400, Wesley Shields wrote While, it has to go somewhere and as a maintainer I have no problem printing out a description of each option inside a custom target. What's important is that there be some consistency in what that target is called. Even better would be to provide a framework to ease the work maintainers have to do. I envision the following: - For each available option have a variable called DESC_$FOO which is a string which describes that option in detail. - Whatever that target is called should be in bsd.ports.mk and output the contents of DESC_$FOO. I think best it would be to extend the OPTIONS syntax from five to six fields, adding a long description field. Two issues 1) what about backward compatibility with existing ports 2) is dialog(1) able to display such a text field? -- Pav Lucistnik [EMAIL PROTECTED] [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: ports system woes
On Wed, 2008-03-26 at 15:00 +0100, Michel Talon wrote: Frank Mayhar wrote: Portupgrade is, in fact, my preferred application, although lately I've had to move to portmaster just because of the O(n^2) inefficiencies. It doesn't need to be replaced, it needs to be fixed, I have rarely seen such a wonderful contradiction between the two halves of the same sentence. There's no contradiction, Michel. Fixing isn't the same thing as rewriting and despite the fact that I'm using portmaster at the moment, portupgrade _is_ my preferred application. Oh, please. The FreeBSD ports system works as well. Instead of No, it doesn't or it does barely. Do you even _use_ it? It's working fine for me, modulo the few problems that have been caused solely by the increase in size of the collection. complaining, why don't you actually do someting about it? Code speaks louder than mere words. We have learnt recently that many people have brought code to the table, including myself, You mean your python code? What does it do that's useful? I ran it and it gives me a lot of output that's just not very interesting or useful and doesn't offer to correct anything. And what many people? When code is offered, I've seen it generally accepted, if it's complete. If you think the ports system should be rewritten, rewrite it. If it's better than the existing solution, I'm sure the world will beat a path to your door. Otherwise, well, them's the breaks. only to be scorned by people of your sort. I have yet to see people like you contributing any testing or discussion when code is offered, all you are good for is parrotting Code speaks louder than mere words. I'm not the one who is complaining that the ports system is broken, Michel. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ http://www.zazzle.com/fmayhar* ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: There is no way to know what port options mean (in general)
On Wed, Mar 26, 2008 at 03:11:39PM +0100, Pav Lucistnik wrote: On Wed, 26 Mar 2008 09:36:11 -0400, Wesley Shields wrote While, it has to go somewhere and as a maintainer I have no problem printing out a description of each option inside a custom target. What's important is that there be some consistency in what that target is called. Even better would be to provide a framework to ease the work maintainers have to do. I envision the following: - For each available option have a variable called DESC_$FOO which is astring which describes that option in detail. - Whatever that target is called should be in bsd.ports.mk and output the contents of DESC_$FOO. I think best it would be to extend the OPTIONS syntax from five to six fields, adding a long description field. Two issues 1) what about backward compatibility with existing ports The idea would be to call make describeconfig (or whatever it ends up being) which would output the information. If the port does not have a DESC_$FOO it will emit a string indicating that this option is not documented and to contact the maintainer to address that. 2) is dialog(1) able to display such a text field? I was not thinking of displaying these in dialog at all, but rather similar to how showconfig works right now. I see no point in using dialog(1) for this as it's not really an interactive process at all, just purely informational. Sounds to me like you are thinking of including the description in the dialog. This sounds like a good idea to me and is something I can look into doing instead of my proposal. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
New portmgr member: Florent Thoumie
Portmgr is pleased to announce that Florent Thoumie has accepted the challenge of being a portmgr member. Florent has been with the project for a long time and is one of our most active committers. Amongst other things, he was one of the people that worked on the complete overhaul of the X11 infrastructure with the Xorg 7.2 upgrade. He will join the other portmgr members on integrating infrastructure patches and quality assurance in addition to other portmgr tasks. Wish him luck! -erwin portmgr secretary -- I'm Erwin Lansing [EMAIL PROTECTED] and I approve this message[EMAIL PROTECTED] pgpqkP612NXYD.pgp Description: PGP signature
Re: There is no way to know what port options mean (in general)
Wesley Shields píše v st 26. 03. 2008 v 10:18 -0400: Sounds to me like you are thinking of including the description in the dialog. This sounds like a good idea to me and is something I can look into doing instead of my proposal. Yes, that was my thought, it must be easily visible in the blue screen, otherwise it will not be seen, most of the time. Something which would add a three line textbox below the dialog window, listing a long description for the item currently under the cursor. I can see it already! :) Can you code it? -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] God is real unless declared integer. signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: ports system woes
Pav Lucistnik wrote: Solution is to use tools that are available in our base system. SQLite is not. Yet :) Compared to some of the (huge) things that are maintained in the base, maintaining sqlite would be trivial :) But it's not as if the question is sqlite or bust - as OP noted, restructuring the system a bit and using better algorithms could fix many problems. The thing is - using something like sqlite is (at least for people used to SQL) much easier than rolling your own file system database (including locking and atomic ops). signature.asc Description: OpenPGP digital signature
Re: devel/pyqt4-gui fails to compile
David J Brooks ha scritto: I wonder if anyone else has noticed the same? Disable cups support in qt4-gui. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
[patch] pkg_delete(1) speedup
You might have noticed a thread on the mailing list called ports system
woes. The submitter pointed out an inefficiency in pkg_delete routine,
that parses the whole /var/db/pkg over and over again for every
dependency of a package being removed.
Attached is a patch by rdivacky that implements the idea of looking up
all the values in a single pass over /var/db/pkg content.
A trivial benchmark, wall times:
port with two dependencies (comms/obexapp)
before
0.083s
after
0.049s
port with 172 dependencies (graphics/agave)
before
8.404s
8.955s
11.734s
after
2.816s
2.690s
3.195s
The patch is not WARNS clean, that needs to be fixed. And I'd like a
review by someone with src commit bit.
--
Pav Lucistnik [EMAIL PROTECTED]
[EMAIL PROTECTED]
42.7 percent of all statistics are made up on the spot.
Index: delete/perform.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/delete/perform.c,v
retrieving revision 1.41
diff -a -u -r1.41 perform.c
--- delete/perform.c 29 Jun 2004 19:06:41 - 1.41
+++ delete/perform.c 26 Mar 2008 15:47:29 -
@@ -123,16 +123,20 @@
{
FILE *cfile;
char *deporigin, **depnames, home[FILENAME_MAX];
+char **undirect_deps;
PackingList p;
int i, len;
int isinstalled;
/* support for separate pre/post install scripts */
-int new_m = 0;
+int new_m = 0, ud_count;
const char *pre_script = DEINSTALL_FNAME;
const char *post_script, *pre_arg, *post_arg;
struct reqr_by_entry *rb_entry;
struct reqr_by_head *rb_list;
+depnames = NULL;
+undirect_deps = NULL;
+
if (!pkg || !(len = strlen(pkg)))
return 1;
if (pkg[len - 1] == '/')
@@ -263,6 +267,7 @@
}
}
+ud_count = 0;
for (p = Plist.head; p ; p = p-next) {
if (p-type != PLIST_PKGDEP)
continue;
@@ -275,18 +280,28 @@
printf(.\n);
}
if (!Fake) {
- depnames = (deporigin != NULL) ? matchbyorigin(deporigin, NULL) :
- NULL;
- if (depnames == NULL) {
- depnames = alloca(sizeof(*depnames) * 2);
- depnames[0] = p-name;
- depnames[1] = NULL;
+ if (deporigin == NULL) {
+ undepend(p-name, pkg);
+ } else {
+ undirect_deps = realloc(undirect_deps, (ud_count + 2) * sizeof(*undirect_deps));
+ undirect_deps[ud_count] = deporigin;
+ undirect_deps[ud_count + 1] = NULL;
+ ud_count++;
}
- for (i = 0; depnames[i] != NULL; i++)
- undepend(depnames[i], pkg);
}
}
+if (undirect_deps != NULL) {
+ depnames = matchallbyorigin(undirect_deps, NULL);
+
+ free(undirect_deps);
+
+ /* Undepend all the dependancies at once */
+ for (i = 0; depnames[i] != NULL; i++)
+ undepend(depnames[i], pkg);
+
+}
+
if (chdir(home) == FAIL) {
cleanup(0);
errx(2, %s: unable to return to working directory %s!, __func__,
Index: lib/lib.h
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/lib/lib.h,v
retrieving revision 1.56.2.2
diff -a -u -r1.56.2.2 lib.h
--- lib/lib.h 14 May 2006 07:06:37 - 1.56.2.2
+++ lib/lib.h 26 Mar 2008 15:47:29 -
@@ -216,6 +216,7 @@
/* Query installed packages */
char **matchinstalled(match_t, char **, int *);
char **matchbyorigin(const char *, int *);
+char **matchallbyorigin(const char **, int *);
int isinstalledpkg(const char *name);
int pattern_match(match_t MatchType, char *pattern, const char *pkgname);
Index: lib/match.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/lib/match.c,v
retrieving revision 1.19.8.2
diff -a -u -r1.19.8.2 match.c
--- lib/match.c 10 Nov 2007 22:04:31 - 1.19.8.2
+++ lib/match.c 26 Mar 2008 15:47:29 -
@@ -238,10 +238,10 @@
* as a key for matching packages.
*/
char **
-matchbyorigin(const char *origin, int *retval)
+matchallbyorigin(const char **origins, int *retval)
{
char **installed;
-int i;
+int i, j;
static struct store *store = NULL;
store = storecreate(store);
@@ -290,8 +290,9 @@
continue;
cmd = plist_cmd(tmp + 1, cp);
if (cmd == PLIST_ORIGIN) {
- if (csh_match(origin, cp, FNM_PATHNAME) == 0)
- storeappend(store, installed[i]);
+ for (j = 0; origins[j] != NULL; j++)
+ if (csh_match(origins[j], cp, FNM_PATHNAME) == 0)
+ storeappend(store, installed[i]);
break;
}
}
@@ -307,6 +308,25 @@
}
/*
+ * Synopsis is similar to matchinstalled(), but use origin
+ * as a key for matching packages.
+ */
+char **
+matchbyorigin(const char *origin, int *retval)
+{
+ char **origins;
+ char **deps;
+
+ origins = malloc(sizeof(*origins) * 2);
+ origins[0] = origin;
+ origins[1] = NULL;
+
+ deps = matchallbyorigin(origins, retval);
+ free(origins);
+ return deps;
+}
+
+/*
* Small linked list to memoize results of isinstalledpkg(). A hash table
* would be faster but for n ~= 1000 may be overkill.
*/
signature.asc
CrackLib needs to be updated
cracklib-2.7_2 seems to be out in version 2.8.12. The pkg-descr file that comes with cracklib-2.7_2 shows an non-working URL. The new URL should be http://sourceforge.net/projects/cracklib/ Kind regards, Marius Korsmo ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Applying security updates to ports.
Hi, As far as I understand there is the ports tree that is released along with an OS release and the security updates to specific ports has to be followed through info on http://wiki.samba.org/index.php/Samba4/HOWTO#Testing_Samba4_Active_Directory_in_Ubuntu_7.04_howto right? I ask this because I am more familiar with OpenBSD and it has 1) The ports tree that comes with the OS Release 2) The ports tree that gets only security updates ( called ports-stable) 3) The ports tree that has newer versions of ports ( called ports-current ) thanks --Siju ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
beryl installation fails with fuse and KDE support on FreeBSD 7
Hi, How do I fix this? === freebsdsrv# cd /usr/ports/x11-wm/beryl freebsdsrv# make install clean === beryl-0.2.1 depends on file: /usr/local/bin/beryl - found === beryl-0.2.1 depends on file: /usr/local/bin/beryl-manager - found === beryl-0.2.1 depends on file: /usr/local/lib/beryl/libanimation.so - found === beryl-0.2.1 depends on file: /usr/local/bin/beryl-settings - found === beryl-0.2.1 depends on file: /usr/local/bin/emerald - not found ===Verifying install for /usr/local/bin/emerald in /usr/ports/x11-wm/emerald === emerald-0.5.2_1 depends on file: /usr/local/libdata/pkgconfig/compiz.pc - not found ===Verifying install for /usr/local/libdata/pkgconfig/compiz.pc in /usr/ports/x11-wm/compiz === compiz-0.6.2 depends on file: /usr/local/libdata/pkgconfig/dbus-1.pc - found === compiz-0.6.2 depends on file: /usr/local/libdata/pkgconfig/dbus-glib-1.pc - found === compiz-0.6.2 depends on file: /usr/local/libdata/pkgconfig/fuse.pc - found === compiz-0.6.2 depends on file: /usr/local/bin/moc - not found ===Verifying install for /usr/local/bin/moc in /usr/ports/x11-toolkits/qt33 === qt-3.3.8_6 depends on executable: qmake - found === qt-3.3.8_6 depends on file: /usr/local/libdata/xorg/libraries - found === qt-3.3.8_6 depends on shared library: mng - found === qt-3.3.8_6 depends on shared library: png - found === qt-3.3.8_6 depends on shared library: jpeg - found === qt-3.3.8_6 depends on shared library: Xft.2 - found === qt-3.3.8_6 depends on shared library: cups.2 - not found ===Verifying install for cups.2 in /usr/ports/print/cups-base === Patching for cups-base-1.3.5_2 === Applying FreeBSD patches for cups-base-1.3.5_2 Ignoring previously applied (or reversed) patch. 10 out of 10 hunks ignored--saving rejects to cups/ipp.c.rej = Patch patch-CVE-2007-4351 failed to apply cleanly. *** Error code 1 Stop in /usr/ports/print/cups-base. *** Error code 1 Stop in /usr/ports/x11-toolkits/qt33. *** Error code 1 Stop in /usr/ports/x11-wm/compiz. *** Error code 1 Stop in /usr/ports/x11-wm/compiz. *** Error code 1 Stop in /usr/ports/x11-wm/emerald. *** Error code 1 Stop in /usr/ports/x11-wm/beryl. freebsdsrv# = Thanks --Siju ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Applying security updates to ports.
Siju George wrote: Hi, As far as I understand there is the ports tree that is released along with an OS release and the security updates to specific ports has to be followed through info on http://wiki.samba.org/index.php/Samba4/HOWTO#Testing_Samba4_Active_Directory_in_Ubuntu_7.04_howto right? I ask this because I am more familiar with OpenBSD and it has 1) The ports tree that comes with the OS Release 2) The ports tree that gets only security updates ( called ports-stable) 3) The ports tree that has newer versions of ports ( called ports-current ) Currently we do not maintain many branches as OpenBSD did due to limited human and compiling resources. What I usually do on FreeBSD is: - Update ports tree; - Install portupgrade, portaudit (both under ports-mgmt/) - portupgrade -rR `portaudit -Fqa` The third step would update affected ports and their required dependencies plus ports depending on them. This is not perfect (if there is shared library version bump, but dependent ports revison is not bumped) but works just fine in most cases. Cheers, -- Xin LI [EMAIL PROTECTED]http://www.delphij.net/ FreeBSD - 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: New portmgr member: Florent Thoumie
Hi flz and ret, On Wed, 26 Mar 2008 15:19:20 +0100 Erwin Lansing [EMAIL PROTECTED] wrote: Portmgr is pleased to announce that Florent Thoumie has accepted the challenge of being a portmgr member. Florent has been with the project for a long time and is one of our most active committers. Amongst other things, he was one of the people that worked on the complete overhaul of the X11 infrastructure with the Xorg 7.2 upgrade. He will join the other portmgr members on integrating infrastructure patches and quality assurance in addition to other portmgr tasks. Wish him luck! -erwin portmgr secretary After all that work he has done .. and then all he gets is a hat (; Congrats with yet another punishment. /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: Applying security updates to ports.
On March 26, 2008 12:18 pm Siju George wrote: I ask this because I am more familiar with OpenBSD and it has 1) The ports tree that comes with the OS Release 2) The ports tree that gets only security updates ( called ports-stable) 3) The ports tree that has newer versions of ports ( called ports-current ) There is only 1 ports tree on FreeBSD, that is constantly being updated. You can update the ports tree that is on your system using a variety of methods. The two most common are: - portsnap - csup Read the man pages, Handbook sections on keeping current and ports, and the examples listed under /usr/share/examples/cvsup for more information. Once the ports tree on your system has been updated, then you can use tools like pkg_version to see which of your installed apps have updates available, portaudit to see which installed apps have known security vulnerabilities, and portmaster to automatically update the app(s) and their dependencies. pkg_version is part of the base OS. portaudit and portmaster can be installed via the ports tree. -- 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: New portmgr member: Florent Thoumie
Soeren Straarup wrote: Hi flz and ret, On Wed, 26 Mar 2008 15:19:20 +0100 Erwin Lansing [EMAIL PROTECTED] wrote: Portmgr is pleased to announce that Florent Thoumie has accepted the challenge of being a portmgr member. Florent has been with the project for a long time and is one of our most active committers. Amongst other things, he was one of the people that worked on the complete overhaul of the X11 infrastructure with the Xorg 7.2 upgrade. He will join the other portmgr members on integrating infrastructure patches and quality assurance in addition to other portmgr tasks. Wish him luck! -erwin portmgr secretary After all that work he has done .. and then all he gets is a hat (; Congrats with yet another punishment. No truth to the rumour that the portmgr hat is conical. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [patch] pkg_delete(1) speedup
On Wed, Mar 26, 2008 at 05:18:29PM +0100, Pav Lucistnik wrote: You might have noticed a thread on the mailing list called ports system woes. The submitter pointed out an inefficiency in pkg_delete routine, that parses the whole /var/db/pkg over and over again for every dependency of a package being removed. Attached is a patch by rdivacky that implements the idea of looking up all the values in a single pass over /var/db/pkg content. I hacked a slightly better patch that coveres a part of pkg_add too.. please review/test on: www.vlakno.cz/~rdivacky/pkg_tools.patch comments, benchmarks more than welcome! roman pgp8r5GxqeDEV.pgp Description: PGP signature
Re: portmaster and BROKEN ports
Willy Picard wrote: portupgrade simply ignores BROKEN ports during a portupgrade -a. I am not even asking about a similar behaviour for portmaster. I wanted just to ask if an option allows to do the same. If no such an option exists, I think that its addition to the functionality of portmaster may be worth considering. I think it's important for users to know when their ports go into a BROKEN state, so ignoring them is not an option. If a user actually wants to ignore a port that is BROKEN, the +IGNOREME mechanism is available, as you pointed out. 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]
call for testers: dynamically configuring amd
I built a script to dynamically configure amd and populate /media with the links. The script can be called from devd when a mass storage device appears/disappears. The target audience are all those who do not want or cannot use HAL. I have created a package for all those who wish to try it: http://www.home.hs-karlsruhe.de/~fado0011/automounter-0.9.tbz It provides the script and the manual pages automounter(8) and automounter.conf(5). The first explains how to set everything up, the second how to tweak the behaviour. ___ 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 BROKEN ports
On Wed, 26 Mar 2008 09:50:35 +0100 Willy Picard [EMAIL PROTECTED] wrote: portupgrade simply ignores BROKEN ports during a portupgrade -a. It carries on building ports that don't depend on the broken port, which is not the same thing as ignoring it. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports system woes
On Mar 26, 2008, at 7:43 AM, Ivan Voras wrote: Pav Lucistnik wrote: Solution is to use tools that are available in our base system. SQLite is not. Yet :) Compared to some of the (huge) things that are maintained in the base, maintaining sqlite would be trivial :) But it's not as if the question is sqlite or bust - as OP noted, restructuring the system a bit and using better algorithms could fix many problems. The thing is - using something like sqlite is (at least for people used to SQL) much easier than rolling your own file system database (including locking and atomic ops). We're rehashing the discussion made last year around June - July. We came to the conclusion that BDB should be used, as no other DB backend / API exists in the base system (currently), and porting SQLLite (while nice) appeared to be non-trivial to port and got a lot of unhappy responses from folks. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
