Sendmail libsasl2 error
Hey, I'm running FreeBSD 6.2-RELEASE-p3. When I rebuilt my system, I added the options in make.conf so it does not rebuild sendmail, then I installed the updated version of sendmail from ports. My make.conf options for the sendmail port are: SENDMAIL_WITHOUT_IPV6=yes SENDMAIL_WITHOUT_MILTER=yes SENDMAIL_WITHOUT_NIS=yes SENDMAIL_WITHOUT_SEM=yes SENDMAIL_WITH_TLS=yes SENDMAIL_WITH_PICKY_HELO_CHECK=yes When I run make maps in /etc/mail/ I get the following error: --- # make maps /usr/sbin/makemap hash access.db access /libexec/ld-elf.so.1: Shared object libsasl2.so.2 not found, required by makemap *** Error code 1 Stop in /etc/mail. --- make cf make aliases and make install all work fine. But make maps fails with that error. Anyone know why and/or have solutions? I don't want to use sasl auth. I just want to use the access db to explicitly allow IPs which can use the server any way they want, and deny everyone else. Thanks in advance! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
php5.2.2 port?
It seems like php5 port is stuck at 5.2.1 version (I didnt check php4) http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/ However php.net has 2 new releases which fix security problems. http://www.php.net/ Affected package: php5-5.2.1_3 (matched by php55.2.2) Type of problem: php -- multiple vulnerabilities. Reference: http://www.FreeBSD.org/ports/portaudit/f5e52bf5-fc77-11db-8163-000e0c2e438a.html Will the maintainer upgrade this port? Thanks, Evren ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php5.2.2 port?
On Sat, May 12, 2007 at 11:46:19AM +0300, Evren Yurtesen wrote: It seems like php5 port is stuck at 5.2.1 version (I didnt check php4) http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/ However php.net has 2 new releases which fix security problems. http://www.php.net/ Affected package: php5-5.2.1_3 (matched by php55.2.2) Type of problem: php -- multiple vulnerabilities. Reference: http://www.FreeBSD.org/ports/portaudit/f5e52bf5-fc77-11db-8163-000e0c2e438a.html Will the maintainer upgrade this port? See the archives. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Time to abandon recursive pulling of dependencies?
With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing == ??SUCCESS??
Hello! Not sure if this is a success mail because i did not 100% exactly what written in UPDATING: 1. instead of portupgrade -a i do it with portupgrade -ak ¹) 2. installed xf86-video-ati-6.6.3_2 while the big update process (had some silly thought - so please don't ask... ;-)) 3. after the update tried to update all error-ports but i stopped it because gimp-gutenprint has again an install error and i want to see how Xorg-7.2 works after 24 hours compiling. 4. simply moved the files in mergebase_output.txt into a backup directory. http://www.webonaut.com/temp/xorg72/mergebase_output.txt http://www.webonaut.com/temp/xorg72/xorg-update_0_README http://www.webonaut.com/temp/xorg72/xorg-update_1.bz2 http://www.webonaut.com/temp/xorg72/xorg-update_2.bz2 http://www.webonaut.com/temp/xorg72/xorg-update_3.bz2 Franz ¹) you will see that i also set -P - did it with the hope that one or the other port is still fetchable as package to save time... even i know that was unrealistic. ;-) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php5.2.2 port?
On Sat, 12 May 2007 11:46:19 +0300 Evren Yurtesen [EMAIL PROTECTED] mentioned: It seems like php5 port is stuck at 5.2.1 version (I didnt check php4) http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php5/ However php.net has 2 new releases which fix security problems. http://www.php.net/ Affected package: php5-5.2.1_3 (matched by php55.2.2) Type of problem: php -- multiple vulnerabilities. Reference: http://www.FreeBSD.org/ports/portaudit/f5e52bf5-fc77-11db-8163-000e0c2e438a.html Will the maintainer upgrade this port? He'll upgrade it when the ports free will be unfrozen. -- Stanislav Sedov ST4096-RIPE pgpmAauW4ijJt.pgp Description: PGP signature
Re: [NEW PORT] ports-mgmt/pkg - smart tool for managing FreeBSD ports
On 5/12/07, Andy Kosela [EMAIL PROTECTED] wrote: Hi all, I would like to present to you the new utility to deal with the ports system. The main goal of this project is to provide one common tool for managing ports and packages instead of relying on many applications (pkg_add, pkg_delete, pkg_info, pkg_version etc.). Actually it is a smart wrapper written in /bin/sh to the previously mentioned applications. It also uses external tool portmaster written also in /bin/sh by Doug Barton to work with the ports compiled from source. Pkg tool automates upgrading installed packages, outputs valuable information about packages/ports and overall simplifies working with the FreeBSD Ports Collection. It uses no external databases like portupgrade, just simplicity and minimalism are its main goals. You can test the latest version by installing the package from here http://home.si.rr.com/pyn/pf/pkg-1.1.tbz I commited pkg-1.0 with send-pr to the ports tree a few days ago. It is awaiting approval... http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/112572 Feel free to send any suggestions, new ideas and of course bug reports... First of all, can you consider renaming it to something less ambitious? A tool named pkg is already present in some other systems (e.g. pkgjam in NetBSD). It would be a pity to see your tool, however marvelous it is, squatter the name just because it was the earliest one. That said, your tool is very welcome. P.S. You wanted to post your message to ports@, not [EMAIL PROTECTED] Cc fixed. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
Kris Kennaway wrote: Amendment two: for now you need to build your own INDEX or portupgrade probably won't work correctly. Before running portupgrade do: portsdb -U It's a weird complain. portsdb -U just run make index (roughly to say). May be I something miss here? -- Dixi. Sem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [NEW PORT] ports-mgmt/pkg - smart tool for managing FreeBSD ports
On 5/12/07, Andrew Pantyukhin [EMAIL PROTECTED] wrote: On 5/12/07, Andy Kosela [EMAIL PROTECTED] wrote: Hi all, I would like to present to you the new utility to deal with the ports system. The main goal of this project is to provide one common tool for managing ports and packages instead of relying on many applications (pkg_add, pkg_delete, pkg_info, pkg_version etc.). Actually it is a smart wrapper written in /bin/sh to the previously mentioned applications. It also uses external tool portmaster written also in /bin/sh by Doug Barton to work with the ports compiled from source. Pkg tool automates upgrading installed packages, outputs valuable information about packages/ports and overall simplifies working with the FreeBSD Ports Collection. It uses no external databases like portupgrade, just simplicity and minimalism are its main goals. You can test the latest version by installing the package from here http://home.si.rr.com/pyn/pf/pkg-1.1.tbz I commited pkg-1.0 with send-pr to the ports tree a few days ago. It is awaiting approval... http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/112572 Feel free to send any suggestions, new ideas and of course bug reports... First of all, can you consider renaming it to something less ambitious? A tool named pkg is already present in some other systems (e.g. pkgjam in NetBSD). It would be a pity to see your tool, however marvelous it is, squatter the name just because it was the earliest one. That said, your tool is very welcome. P.S. You wanted to post your message to ports@, not [EMAIL PROTECTED] Cc fixed. Thank you for your reply. From my understanding of pkgjam this is a completely new system for building applications only on NetBSD and it doesn't relate at all to FreeBSD Ports system. Plus it contains tools like pkg_info which also share the same names with FreeBSD base utilities but are completely different. It won't be ported to FreeBSD anytime soon, if at all. My intention to name my utility just pkg was to make it as simple as possible (especially quick for typing). It gets rid of using various pkg_*. Instead you got ONE simple tool which do everything you need for quickly managing the ports. Andy Kosela Pythagoras Foundation ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
Le Jeu 10 mai 07 à 23:28:17 +0200, Kris Kennaway [EMAIL PROTECTED] écrivait : Dear porters, Hello, Once we have enough success reports and have dealt with all reported failures, we will proceed with the next stage, which is to import into CVS. I'm still upgrading, but have noticed an error in x11-toolkits/tix: === Building for tix-8.1.4_3 cc -pipe -c -O -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DUCHAR_SUPPORTED=1 -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DSTDC_HEADERS=1 -DHAVE_PW_GECOS=1 -DNO_VALUES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DTCL_WIDE_INT_TYPE=long\ long -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DNO_UNION_WAIT=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_PUTENV_THAT_COPIES=1 -DHAVE_LANGINFO=1 -DHAVE_FTS=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_FILIO_H=1 -I/usr/ports/lang/tcl84/work/tcl8.4.14/generic -I/usr/ports/lang/tcl84/work/tcl8.4.14/unix -I/usr/home/thierry/x.org-7.2/ports/x11-toolkits/tk84/work/tk8.4.14/generic -I/usr/home/thierry/x.org-7.2/ports/x11-toolkits/tk84/work/tk8.4.14/unix -I/usr/home/thierry/x.org-7.2/ports/x11-toolkits/tix/work/tix-8.1.4/generic -I/usr/home/thierry/x.org-7.2/ports/x11-toolkits/tix/work/tix-8.1.4/unix -I/usr/local/include -fPIC /usr/home/thierry/x.org-7.2/ports/x11-toolkits/tix/work/tix-8.1.4/generic/tixClass.c In file included from /usr/home/thierry/x.org-7.2/ports/x11-toolkits/tix/work/tix-8.1.4/generic/tixClass.c:29: /usr/home/thierry/x.org-7.2/ports/x11-toolkits/tk84/work/tk8.4.14/generic/tk.h:57:20: tcl.h: No such file or directory /usr/home/thierry/x.org-7.2/ports/x11-toolkits/tk84/work/tk8.4.14/generic/tk.h:59:3: #error Tk 8.4 must be compiled with tcl.h from Tcl 8.4 The full log - an extract on my typescript) is available at http://people.freebsd.org/~thierry/ports/tix.log. No patch ATM, because the upgrade is still in progress... -- Th. Thomas. pgpSH2B5zRlHj.pgp Description: PGP signature
Re: HEADS UP: xorg 7.2 ready for testing
Le Jeu 10 mai 07 à 23:28:17 +0200, Kris Kennaway [EMAIL PROTECTED] écrivait : Once we have enough success reports and have dealt with all reported failures, we will proceed with the next stage, which is to import into CVS. And another failure in devel/ode: checking whether cc accepts -g... yes ./configure: line 2593: syntax error near unexpected token `elif' ./configure: line 2593: `elif test $ac_cv_prog_cc_g = yes; then' gmake: *** [config.status] Erreur 2 *** Error code 2 Stop in /usr/home/thierry/x.org-7.2/ports/devel/ode. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.21255.1 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=ode-0.7,1 UPGRADE_PORT_VER=0.7,1 make Full log at http://people.freebsd.org/~thierry/ports/ode.log. -- Th. Thomas. pgpM11ujohZj0.pgp Description: PGP signature
Coldfusion 7.0.2 Port
Hello, I'm new to port writing however I've put together a basic port to install coldfusion 7.0.2 developer edition... Which can actually be converted to an enterprise release if you had a valid license. If you have any questions please feel free to write me back I am looking forward to hearing from some one... I believe this port would belong under www or possibly lang Sincerely, Christopher Olsen Christopher Olsen [EMAIL PROTECTED] 88B Toledo Street Farmingdale, NY 11735 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
On Sat, 12 May 2007 12:32:38 +0200 [LoN]Kamikaze [EMAIL PROTECTED] wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. Does that matter all that much when there are ports that take several hours to build? As I see it the important figure is the total time taken to register all installed ports, divided by the total time to download, build and install them. As long as that figure remains small it doesn't really matter that small ports install inefficiently. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
RW wrote: On Sat, 12 May 2007 12:32:38 +0200 [LoN]Kamikaze [EMAIL PROTECTED] wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. Does that matter all that much when there are ports that take several hours to build? As I see it the important figure is the total time taken to register all installed ports, divided by the total time to download, build and install them. As long as that figure remains small it doesn't really matter that small ports install inefficiently. My guess is that registering takes about 15% of the total upgrade time. Is that a small figure? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. I think that before you abandon something you should first understand it. Figure out what is taking so long to register the port and then work out whether it can be optimized. Kris P.S. Please wrap your lines so your emails may be easily read ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
xorg7.2 upgrade and i945GM glx
hello i've updated to xorg7.2 on my lappy (hp nx7400), here's the typescript: http://phoemix.harmless.hu/ports-xorg72-upgrade.bz2 the last few part that happend after the reboot are not in there, those involved the upgrade.sh, removal of LOCALBASE/lib/modules (since it contained only 6.9 modules), and the rebuild of xorg-server. and i had to change the modulepath to LOCALBASE/lib/xorg/modules, because the upgrade.sh left out the xorg/ part of the pathname. after starting X, glxinfo shows that direct renderring is enabled, but no gl applications are able to run. every time i try to run anything, i've got the following output: chop with axe here $ gltron [status] loading settings from /usr/home/phoemix/.gltronrc [warning] old config file found, overriding using defaults [warning] defunct config file found, overriding using defaults [status] loading artpack 'default' using min_filter: 9987 (setting: 3) [scripting audio] found track ' song_revenge_of_cats.it ' [sound] initializing sound [sound] loading song song_revenge_of_cats.it X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 157 (DAMAGE) Minor opcode of failed request: 4 () Serial number of failed request: 36 Current serial number in output stream: 38 $ glxgears X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 157 (DAMAGE) Minor opcode of failed request: 4 () Serial number of failed request: 37 Current serial number in output stream: 41 chop with axe here the Xorg logfile can be found here: http://phoemix.harmless.hu/Xorg.0.log If anything else is needed to fix this, please let me know, i will publicate any other required information. Please CC replies to me, since i'm not subscribed to the mailing list. Bye, Gergely Czuczy mailto: [EMAIL PROTECTED] -- Weenies test. Geniuses solve problems that arise. pgpkZd2f1ab6r.pgp Description: PGP signature
Re: Time to abandon recursive pulling of dependencies?
Kris Kennaway wrote: On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. I think that before you abandon something you should first understand it. Figure out what is taking so long to register the port and then work out whether it can be optimized. What takes so long in my opinion, is that not only the dependencies are registered as dependencies, but that the dependencies of dependencies are also registered as dependencies and so forth. Since all the commands supplied by ports walk dependencies recursively, as well as tools like portupgrade, this is unnecessary (that is, assuming that I understood bsd.port.mk correctly). To abandon this behaviour would in my opinion only have advantages. Kris P.S. Please wrap your lines so your emails may be easily read Hope it works, now. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
Le Sam 12 mai 07 à 19:40:11 +0200, Kris Kennaway [EMAIL PROTECTED] écrivait : On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. I think that before you abandon something you should first understand it. Figure out what is taking so long to register the port and then work out whether it can be optimized. Moreover, there are plans to revise /var/db/pkg structure: see http://wiki.freebsd.org/GarrettCooper. -- Th. Thomas. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote: Kris Kennaway wrote: On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. I think that before you abandon something you should first understand it. Figure out what is taking so long to register the port and then work out whether it can be optimized. What takes so long in my opinion, is that not only the dependencies are registered as dependencies, but that the dependencies of dependencies are also registered as dependencies and so forth. Since all the commands supplied by ports walk dependencies recursively, as well as tools like portupgrade, this is unnecessary (that is, assuming that I understood bsd.port.mk correctly). To abandon this behaviour would in my opinion only have advantages. Go and substantiate your opinion with some facts, then we'll talk. Kris P.S. Please wrap your lines so your emails may be easily read Hope it works, now. Thanks Kris pgpzZWjYpiUGf.pgp Description: PGP signature
FreeBSD Port: mytop-1.6_3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings folks, I have a query about the requirements for this port. I have MySQL Server Client 5.1.15, plus I was planning on installed p5-DBD-mysql51 ... Is that OK as they are newer versions? Or will ports require that the older versions be installed like mysql-client-5.0.37, p5-DBD-mysql-4.003? - -- Paul Laudanski, CastleCops®, www.castlecops.com Submit Phish: www.castlecops.com/pirt http://www.linkedin.com/pub/1/49a/17b -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRgMyHP6ZmSxUymURApaTAKDRR4xcpg3hp7cRcVAqOg3eQaRSnACgwGJ2 A41G1xLIpL05f4oHiMZQj2w= =SSAy -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote: On Sat, 12 May 2007, Kris Kennaway wrote: On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote: Kris Kennaway wrote: On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. I think that before you abandon something you should first understand it. Figure out what is taking so long to register the port and then work out whether it can be optimized. What takes so long in my opinion, is that not only the dependencies are registered as dependencies, but that the dependencies of dependencies are also registered as dependencies and so forth. Since all the commands supplied by ports walk dependencies recursively, as well as tools like portupgrade, this is unnecessary (that is, assuming that I understood bsd.port.mk correctly). To abandon this behaviour would in my opinion only have advantages. Go and substantiate your opinion with some facts, then we'll talk. I've done a little poking around. As of right now, I think that the registering takes a huge amount of time inside of a function called sortdeps which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c. That function certainly looks like it can be optimized. Kris pgpT3sXtvQjfw.pgp Description: PGP signature
Re: Time to abandon recursive pulling of dependencies?
On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote: I've done a little poking around. As of right now, I think that the registering takes a huge amount of time inside of a function called sortdeps which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c. Has anyone built a system with profiled libraries and a pkg_install binary with gcc -pg? gprof output would be incredibly beneficial here. We're grasping at straws until we figure out where most of the time is spent during a port installation. The desire to move to Berkeley DB and use hashes (mentioned in another post in this thread) is fine, but that's implying that there's a lot of filesystem I/O going on which could be optimised by using a key/value database somehow. No offence, but I'm sceptical of that being the solution to this whole thing. I can see that being somewhat useful for very quickly iterating through a dependency tree, however. Sorry if this seems like a stupid question, but are there any operations during a port install which are done on-the-fly that could be relinquished by utilising something pre-generated and instead managed by a central source (something similar to ports/INDEX-6 in functionality)? Just a thought. -- | 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: Time to abandon recursive pulling of dependencies?
On Sat, 12 May 2007, Kris Kennaway wrote: On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote: I've done a little poking around. As of right now, I think that the registering takes a huge amount of time inside of a function called sortdeps which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c. That function certainly looks like it can be optimized. I believe that if this function is optimized, that practically all of the slowness issues we have seen with pkg_add, pkg_deinstall, etc, will be solved. Give me a few days. I think I will be able to make it work very much faster. For starters it uses a bubble sort. I can understand why they don't want to use a quicksort, because they want to check complete integrety of comparison tree (i.e. that there are no internal loops), but I recall seeing an algorithm due perhaps to one of or both of Hopcroft and Tarjan that uses a depth first search, maybe 20 years ago, that should be much faster, and I think I could reproduce it. (But if someone else decides to work on it instead, email me immediately so that I don't have to do it.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
On Sat, May 12, 2007 at 11:53:22AM -0700, Jeremy Chadwick wrote: On Sat, May 12, 2007 at 01:33:40PM -0500, Stephen Montgomery-Smith wrote: I've done a little poking around. As of right now, I think that the registering takes a huge amount of time inside of a function called sortdeps which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c. Has anyone built a system with profiled libraries and a pkg_install binary with gcc -pg? gprof output would be incredibly beneficial here. We're grasping at straws until we figure out where most of the time is spent during a port installation. The desire to move to Berkeley DB and use hashes (mentioned in another post in this thread) is fine, but that's implying that there's a lot of filesystem I/O going on which could be optimised by using a key/value database somehow. No offence, but I'm sceptical of that being the solution to this whole thing. It is not claimed that move to Berkeley DB and use hashes is going to be the solution to this whole thing, so that's a straw man argument. It is claimed that it will solve certain specific problems. See my post to hackers@ yesterday for more discussion of the issues. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
On Sat, May 12, 2007 at 12:30:52PM -0700, Jeremy Chadwick wrote: On Sat, May 12, 2007 at 01:53:36PM -0500, Stephen Montgomery-Smith wrote: I believe that if this function is optimized, that practically all of the slowness issues we have seen with pkg_add, pkg_deinstall, etc, will be solved. Give me a few days. I think I will be able to make it work very much faster. For starters it uses a bubble sort. I can understand why they don't want to use a quicksort, because they want to check complete integrety of comparison tree (i.e. that there are no internal loops), but I recall seeing an algorithm due perhaps to one of or both of Hopcroft and Tarjan that uses a depth first search, maybe 20 years ago, that should be much faster, and I think I could reproduce it. Please don't use a bubblesort, it's incredibly inefficient. The *existing* algorithm is a bubble sort; Stephen is not proposing to replace it with one. Kris ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
Stephen Montgomery-Smith wrote: On Sat, 12 May 2007, Kris Kennaway wrote: On Sat, May 12, 2007 at 07:54:57PM +0200, [LoN]Kamikaze wrote: Kris Kennaway wrote: On Sat, May 12, 2007 at 12:32:38PM +0200, [LoN]Kamikaze wrote: With Xorg updated to 7.2 many ports take much longer to register than to download, build and install. I think it's time to abandon the recursive pulling in of dependencies. I think that before you abandon something you should first understand it. Figure out what is taking so long to register the port and then work out whether it can be optimized. What takes so long in my opinion, is that not only the dependencies are registered as dependencies, but that the dependencies of dependencies are also registered as dependencies and so forth. Since all the commands supplied by ports walk dependencies recursively, as well as tools like portupgrade, this is unnecessary (that is, assuming that I understood bsd.port.mk correctly). To abandon this behaviour would in my opinion only have advantages. Go and substantiate your opinion with some facts, then we'll talk. I've done a little poking around. As of right now, I think that the registering takes a huge amount of time inside of a function called sortdeps which may be found in /usr/src/usr.sbin/pkg_install/lib/deps.c. Stephen Thank you for looking into this. I was expecting to have to make experminental patches for the pkg tools as well as in bsd.port.mk to back my opinion. However I wouldn't have been able to start earlier than two weeks from now. And before that I want to look into some acpi_ibm and psm regressions I'm experiencing with stable. ___ 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: dspam-3.6.8_2
On Fri, 11 May 2007 09:47:49 -0700 Ed Lucero [EMAIL PROTECTED] wrote: Hi I was interested in finding out when dspam 3.8.0 Stable will be ported. It's in -devel, I'll will MFD it after the Ports freeze is over. -- IOnut ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
xorg7.2 upgrade and glxgears
I have the following error when running glxgears using the ATI driver:
X Error of failed request: BadRequest (invalid request code or no such
operation)
Major opcode of failed request: 158 (DAMAGE)
Minor opcode of failed request: 4 ()
Serial number of failed request: 37
Current serial number in output stream: 38
Also mesa-demos won't build with the NVIDIA patches. Here are my patches to
the makefile and a revised yuvrect_client.c patch (i.e. elif to else).
--- Makefile.orig Wed May 2 09:27:18 2007
+++ MakefileSat May 12 00:50:41 2007
@@ -96,9 +96,7 @@
.endif
.if defined(WITH_NVIDIA_GL)
-CFLAGS+= -DWITH_NVIDIA_GL=1
-.else
-CFLAGS+= -DWITH_NVIDIA_GL=0
+CFLAGS+= -DWITH_NVIDIA_GL
.endif
.include bsd.port.post.mk
--- progs/xdemos/yuvrect_client.c.orig Sat May 12 01:19:47 2007
+++ progs/xdemos/yuvrect_client.c Sat May 12 01:19:47 2007
@@ -140,7 +140,11 @@
exit(0);
}
- glx_memory = glXAllocateMemoryMESA(dpy, screen, ImgWidth * ImgHeight * 2,
0, 0 ,0);
+ #ifdef WITH_NVIDIA_GL
+ glx_memory = glXAllocateMemoryNV(ImgWidth * ImgHeight * 2, 0, 0 ,0);
+ #else
+ glx_memory = glXAllocateMemoryMESA(dpy, screen, ImgWidth * ImgHeight *
2, 0, 0 ,0);
+ #endif
if (!glx_memory)
{
fprintf(stderr,Failed to allocate MESA memory\n);
@@ -317,7 +321,11 @@
glXSwapBuffers(dpy, win);
event_loop(dpy, win);
- glXFreeMemoryMESA(dpy, DefaultScreen(dpy), glx_memory);
+ #ifdef WITH_NVIDIA_GL
+ glXFreeMemoryNV(glx_memory);
+ #else
+ glXFreeMemoryMESA(dpy, DefaultScreen(dpy), glx_memory);
+ #endif
glXDestroyContext(dpy, ctx);
XDestroyWindow(dpy, win);
XCloseDisplay(dpy);
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
Reporting success on one of my desktops. It's a current/i386 box with a little over 1000 packages (after the upgrade). I used portupgrade-devel, but started with stale INDEX. For this reason or not, I stumbled upon the libXft quirk. Stopped the upgrade when I saw a few pkg_create's to take far too long because of dependency loop, rebuilt the INDEX with make index (portsdb -U didn't work for me), ran pkgdb -F and after that portupgrade -a finished without any major surprises. mergebase.sh failed, probably because my system is quite dirty. Even after I removed the conflicting files, it just failed. I've made the merge myself and been living happily ever since (so far). Waiting for portupgrade -a to finish on my laptop. Thanks, Kris and all of you guys for making this step as painless as possible - for me and everyone. Thanks! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: xorg 7.2 ready for testing
On 5/13/07, Kris Kennaway [EMAIL PROTECTED] wrote: On Sun, May 13, 2007 at 01:00:51AM +0400, Andrew Pantyukhin wrote: Reporting success on one of my desktops. It's a current/i386 box with a little over 1000 packages (after the upgrade). I used portupgrade-devel, but started with stale INDEX. For this reason or not, I stumbled upon the libXft quirk. Stopped the upgrade when I saw a few pkg_create's to take far too long because of dependency loop, rebuilt the INDEX with make index (portsdb -U didn't work for me), ran pkgdb -F and after that portupgrade -a finished without any major surprises. Can you confirm that you started by doing portupgrade -Rf libXft and it still gave the dependency loop? Nope, I actually misread UPDATING and thought portupgrade-devel didn't need it. [ try s/nor/not/ in the message :) ] mergebase.sh failed, probably because my system is quite dirty. Even after I removed the conflicting files, it just failed. I've made the merge myself and been living happily ever since (so far). Hmm, would be nice to know why. I'll try to look closer at it on my laptop. Something tells me it'll fail there too, because it's my development system and it's as dirty as it gets. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xorg7.2 upgrade and glxgears
On Saturday 12 May 2007 12:53:00 pm vehemens wrote: I have the following error when running glxgears using the ATI driver: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 158 (DAMAGE) Minor opcode of failed request: 4 () Serial number of failed request: 37 Current serial number in output stream: 38 Downgrading libGL to 6.5.2 allows me to run glxgears. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xorg7.2 upgrade and glxgears
vehemens wrote: I have the following error when running glxgears using the ATI driver: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 158 (DAMAGE) Minor opcode of failed request: 4 () Serial number of failed request: 37 Current serial number in output stream: 38 I have a rv200 chipset. After the upgrade I don't have glxgears or glxinfo on my system. Could anyone tell me which port they belong to? I'm using Quake3 for testing and it floods the console with the message: Major opcode of failed request: 155 Minor opcode of failed request: 4 Serial number of failed request: 31851 The serial number is a growing number that has reached 31000 after about 2 minutes. Running mplayer with -vo gl or -vo gl2 will open the video window for a moment before the program terminates with the following message: X11 error: BadRequest (invalid request code or no such operation) xrandr leads to the following message: X error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 154 (RANDR) Minor opcode of failed request: 6 () Serial number of failed request: 9 Current serial number in output stream: 9 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xorg7.2 upgrade and glxgears
On Sun, May 13, 2007 at 01:42:23AM +0200, [LoN]Kamikaze wrote: After the upgrade I don't have glxgears or glxinfo on my system. Could anyone tell me which port they belong to? graphics/mesa-demos. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how to speed up the
make package-depends in bsd.ports.mk, but that is beyond my abilities.
I really hope this works. The prospect of modifying a piece of code
that is used by practically the whole FreeBSD community kind of scares
me, so I would appreciate some good testing.
Apply the patch http://www.math.missouri.edu/~stephen/deps/ddd to
/usr/src/usr.sbin/pkg_install/lib. I have also put the patch as an
attachment, but I don't know if the mail filters will take it out.
Stephen
--- deps.c-orig Sat May 12 19:02:21 2007
+++ deps.c Sat May 12 19:56:17 2007
@@ -26,98 +26,105 @@
#include err.h
#include stdio.h
+void list_deps(const char *pkgname, char **pkgs, char *listed,
+ char *check_loop, char **newpkgs, int *nrnewpkgs, int
*errcount);
+
/*
* Sort given NULL-terminated list of installed packages (pkgs) in
* such a way that if package A depends on package B then after
* sorting A will be listed before B no matter how they were
* originally positioned in the list.
+ *
+ * Works by performing a recursive depth-first search on the required-by lists.
*/
+
int
sortdeps(char **pkgs)
{
-char *tmp;
-int i, j, loop_cnt;
-int err_cnt = 0;
+int i, errcount=0;
+int nrpkgs, nrnewpkgs;
+char *listed, *check_loop, **newpkgs;
+char *cp;
if (pkgs[0] == NULL || pkgs[1] == NULL)
return (0);
-for (i = 0; pkgs[i + 1]; i++) {
- /*
-* Check to see if any other package in pkgs[i+1:] depends
-* on pkgs[i] and swap those two packages if so.
-*/
- loop_cnt = 0;
- for (j = i + 1; pkgs[j]; j++) {
- if (chkifdepends(pkgs[j], pkgs[i]) == 1) {
- /*
-* Try to avoid deadlock if package A depends on B which in
-* turn depends on C and C due to an error depends on A.
-* Use ugly but simple method, becase it Should Never
-* Happen[tm] in the real life anyway.
-*/
- if (loop_cnt 4096) {
- warnx(dependency loop detected for package %s, pkgs[j]);
- err_cnt++;
- break;
- }
- loop_cnt++;
- tmp = pkgs[i];
- pkgs[i] = pkgs[j];
- pkgs[j] = tmp;
- /*
-* Another iteration requred to check if new pkgs[i]
-* itself has any packages that depend on it
-*/
- j = i + 1;
- }
- }
+nrpkgs = 0;
+while (pkgs[nrpkgs]) nrpkgs++;
+listed = malloc(nrpkgs);
+bzero(listed,nrpkgs);
+check_loop = malloc(nrpkgs);
+bzero(check_loop,nrpkgs);
+newpkgs = malloc(nrpkgs*sizeof(char*));
+nrnewpkgs = 0;
+
+for (i = 0; pkgs[i]; i++) if (!listed[i]) {
+ check_loop[i] = 1;
+ cp = strchr(pkgs[i], ':');
+ if (cp != NULL)
+ *cp = '\0';
+ list_deps(pkgs[i],pkgs,listed,check_loop,newpkgs,nrnewpkgs,errcount);
+ if (cp != NULL)
+ *cp = ':';
+ listed[i] = 1;
+ newpkgs[nrnewpkgs] = pkgs[i];
+ nrnewpkgs++;
}
-return err_cnt;
+
+if (nrnewpkgs != nrpkgs) {
+ fprintf(stderr,Huge error in code\n);
+ exit(1);
+}
+for (i = 0; i nrnewpkgs; i++) pkgs[i] = newpkgs[i];
+
+return errcount;
}
/*
- * Check to see if pkgname1 depends on pkgname2.
- * Returns 1 if depends, 0 if not, and -1 if error occured.
- */
-int
-chkifdepends(const char *pkgname1, const char *pkgname2)
-{
-char *cp1, *cp2;
-int errcode;
+ * This recursive function lists the dependencies (that is, the required-bys)
+ * for pkgname, putting them into newpkgs.
+ */
+
+void list_deps(const char *pkgname, char **pkgs, char *listed,
+ char *check_loop, char **newpkgs, int *nrnewpkgs, int
*errcount) {
+char *cp;
+int errcode, j;
struct reqr_by_entry *rb_entry;
struct reqr_by_head *rb_list;
-cp2 = strchr(pkgname2, ':');
-if (cp2 != NULL)
- *cp2 = '\0';
-cp1 = strchr(pkgname1, ':');
-if (cp1 != NULL)
- *cp1 = '\0';
-
-errcode = 0;
-/* Check that pkgname2 is actually installed */
-if (isinstalledpkg(pkgname2) = 0)
- goto exit;
+if (isinstalledpkg(pkgname) = 0)
+ return;
-errcode = requiredby(pkgname2, rb_list, FALSE, TRUE);
+errcode = requiredby(pkgname, rb_list, FALSE, TRUE);
if (errcode 0)
- goto exit;
+ return;
-errcode = 0;
-STAILQ_FOREACH(rb_entry, rb_list, link) {
- if (strcmp(rb_entry-pkgname, pkgname1) == 0) { /* match */
- errcode = 1;
- break;
+STAILQ_FOREACH(rb_entry, rb_list, link)
+ for (j = 0;
Re: Time to abandon recursive pulling of dependencies?
Stephen Montgomery-Smith wrote: OK chaps, this is what I came up with. So for example, if I do make install on /usr/ports/x11/xorg (having made all the dependencies), on my computer it turns the pkg_create from taking about 4 minutes to the blink of an eye. Now people need to figure out how to speed up the make package-depends in bsd.ports.mk, but that is beyond my abilities. I really hope this works. The prospect of modifying a piece of code that is used by practically the whole FreeBSD community kind of scares me, so I would appreciate some good testing. Apply the patch http://www.math.missouri.edu/~stephen/deps/ddd to /usr/src/usr.sbin/pkg_install/lib. I have also put the patch as an attachment, but I don't know if the mail filters will take it out. Stephen I spoke too soon. It is kind of buggy. Sorry to have jumped the gun a bit. ___ 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: mytop-1.6_3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yen-Ming Lee wrote:
Greetings folks, I have a query about the requirements for this port.
I have MySQL Server Client 5.1.15, plus I was planning on installed
p5-DBD-mysql51 ...
Is that OK as they are newer versions? Or will ports require that the
older versions be installed like mysql-client-5.0.37, p5-DBD-mysql-4.003?
No, mytop needs ${SITE_PERL}/${PERL_ARCH}/DBD/mysql.pm, and it doesn't
care about where it comes from. So, if you would like to use specific
version of p5-DBD-mysql, say p5-DBD-mysql51, install it first, and then
mytop will depends on it, otherwise mytop will depends on p5-DBD-mysql,
which default version is 4.003.
However, you can also set WANT_MYSQL_VER=51 when installing mytop
or p5-DBD-mysql, and they will depend on mysql-client-5.1.x as you want.
Thank you for the explanation and advice, its appreciated.
- --
Paul Laudanski, CastleCops®, www.castlecops.com
Submit Phish: www.castlecops.com/pirt
http://www.linkedin.com/pub/1/49a/17b
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGRo+vHP6ZmSxUymURAsMlAKCBTyNz8qsorSCaNlCVvK9dtTJ4UgCdEoM2
CE023eQXNQ9eVe1N9xETXWc=
=ywTM
-END PGP SIGNATURE-
___
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: mytop-1.6_3
On Sat, May 12, 2007 at 02:10:58PM -0400, Paul Laudanski wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings folks, I have a query about the requirements for this port.
I have MySQL Server Client 5.1.15, plus I was planning on installed
p5-DBD-mysql51 ...
Is that OK as they are newer versions? Or will ports require that the
older versions be installed like mysql-client-5.0.37, p5-DBD-mysql-4.003?
No, mytop needs ${SITE_PERL}/${PERL_ARCH}/DBD/mysql.pm, and it doesn't
care about where it comes from. So, if you would like to use specific
version of p5-DBD-mysql, say p5-DBD-mysql51, install it first, and then
mytop will depends on it, otherwise mytop will depends on p5-DBD-mysql,
which default version is 4.003.
However, you can also set WANT_MYSQL_VER=51 when installing mytop
or p5-DBD-mysql, and they will depend on mysql-client-5.1.x as you want.
--
Yen-Ming Lee [utf7:+Z05fZWYO] | Taipei, Taiwan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Time to abandon recursive pulling of dependencies?
Stephen Montgomery-Smith wrote:
Stephen Montgomery-Smith wrote:
OK chaps, this is what I came up with. So for example, if I do make
install on /usr/ports/x11/xorg (having made all the dependencies), on
my computer it turns the pkg_create from taking about 4 minutes to the
blink of an eye. Now people need to figure out how to speed up the
make package-depends in bsd.ports.mk, but that is beyond my abilities.
I really hope this works. The prospect of modifying a piece of code
that is used by practically the whole FreeBSD community kind of scares
me, so I would appreciate some good testing.
Apply the patch http://www.math.missouri.edu/~stephen/deps/ddd to
/usr/src/usr.sbin/pkg_install/lib. I have also put the patch as an
attachment, but I don't know if the mail filters will take it out.
Stephen
I spoke too soon. It is kind of buggy. Sorry to have jumped the gun a
bit.
OK, try this one.
--- /usr/src/usr.sbin/pkg_install/lib/deps.cWed Dec 6 20:14:13 2006
+++ usr.sbin/pkg_install/lib/deps.c Sat May 12 23:53:36 2007
@@ -26,98 +26,144 @@
#include err.h
#include stdio.h
+void list_deps(const char *pkgname, char **pkgs, char *listed,
+ char *check_loop, char **newpkgs, int *nrnewpkgs,
+ int *err_cnt);
+
/*
* Sort given NULL-terminated list of installed packages (pkgs) in
* such a way that if package A depends on package B then after
* sorting A will be listed before B no matter how they were
* originally positioned in the list.
+ *
+ * Works by performing a recursive depth-first search on the
+ * required-by lists.
*/
+
int
sortdeps(char **pkgs)
{
-char *tmp;
-int i, j, loop_cnt;
-int err_cnt = 0;
+int i, err_cnt=0;
+int nrpkgs, nrnewpkgs;
+char *listed, *check_loop, **newpkgs;
+char *cp;
if (pkgs[0] == NULL || pkgs[1] == NULL)
return (0);
-for (i = 0; pkgs[i + 1]; i++) {
- /*
-* Check to see if any other package in pkgs[i+1:] depends
-* on pkgs[i] and swap those two packages if so.
-*/
- loop_cnt = 0;
- for (j = i + 1; pkgs[j]; j++) {
- if (chkifdepends(pkgs[j], pkgs[i]) == 1) {
- /*
-* Try to avoid deadlock if package A depends on B which in
-* turn depends on C and C due to an error depends on A.
-* Use ugly but simple method, becase it Should Never
-* Happen[tm] in the real life anyway.
-*/
- if (loop_cnt 4096) {
- warnx(dependency loop detected for package %s, pkgs[j]);
- err_cnt++;
- break;
- }
- loop_cnt++;
- tmp = pkgs[i];
- pkgs[i] = pkgs[j];
- pkgs[j] = tmp;
- /*
-* Another iteration requred to check if new pkgs[i]
-* itself has any packages that depend on it
-*/
- j = i + 1;
- }
- }
+nrpkgs = 0;
+while (pkgs[nrpkgs]) nrpkgs++;
+listed = alloca(nrpkgs);
+if (listed == NULL) {
+ warnx(%s(): alloca() failed, __func__);
+ return 1;
+}
+bzero(listed,nrpkgs);
+check_loop = alloca(nrpkgs);
+if (check_loop == NULL) {
+ warnx(%s(): alloca() failed, __func__);
+ return 1;
+}
+bzero(check_loop,nrpkgs);
+newpkgs = alloca(nrpkgs*sizeof(char*));
+if (newpkgs == NULL) {
+ warnx(%s(): alloca() failed, __func__);
+ return 1;
+}
+nrnewpkgs = 0;
+
+for (i = 0; pkgs[i]; i++) if (!listed[i]) {
+ check_loop[i] = 1;
+ cp = strchr(pkgs[i], ':');
+ if (cp != NULL)
+ *cp = '\0';
+ list_deps(pkgs[i],pkgs,listed,check_loop,newpkgs,nrnewpkgs,err_cnt);
+ if (cp != NULL)
+ *cp = ':';
+ listed[i] = 1;
+ newpkgs[nrnewpkgs] = pkgs[i];
+ nrnewpkgs++;
+}
+
+if (nrnewpkgs != nrpkgs) {
+ fprintf(stderr,This shouldn't happen, and indicates a huge error in
the code.\n);
+ exit(1);
}
+for (i = 0; i nrnewpkgs; i++) pkgs[i] = newpkgs[i];
+
return err_cnt;
}
/*
- * Check to see if pkgname1 depends on pkgname2.
- * Returns 1 if depends, 0 if not, and -1 if error occured.
- */
-int
-chkifdepends(const char *pkgname1, const char *pkgname2)
-{
-char *cp1, *cp2;
-int errcode;
+ * This recursive function lists the dependencies (that is, the
+ * required-bys) for pkgname, putting them into newpkgs.
+ */
+
+void list_deps(const char *pkgname, char **pkgs, char *listed,
+ char *check_loop, char **newpkgs, int *nrnewpkgs,
+ int *err_cnt) {
+char **rb, **rbtmp;
+char *cp;
+int errcode, i, j;
struct reqr_by_entry *rb_entry;
struct reqr_by_head *rb_list;
-cp2 = strchr(pkgname2, ':');
-if (cp2 != NULL)
- *cp2 = '\0';
-cp1 = strchr(pkgname1, ':');
-if (cp1 != NULL)
- *cp1
