portmaster wants to reinstall OpenOffice
Yesterday I updated OpenOffice and now whenever I run portmaster -Da it reinstalls it for no reason I can see. Thanks to ccache that doesn't take more than an hour. Still it's a /very/ annoying habit. ___ 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
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! All right, I've been gone to the Real World for a while, but I returned %-) First, allow me to note that it's rather impressing to see the level of interest and responses my half-baked email about my little digs into pkg_* tools produced. Before I even finished thinking whether I will have enough time to fix the tools proper, patches started appearing on the horizon (the same day, practically)! This is quite reassuring, as it shows that developers still care about code and algorithm quality, even if things work OK on modern hardware (just lack of developer time, that's all, I suppose). For that I'm grateful -- way to go :) Now, here are the same tests on the same hardware, but with pkg_tools.patch applied: [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# make [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make install SNIP === Generating temporary packing list === Checking if x11/rxvt-unicode already installed load: 0.53 cmd: pkg_info 25799 [biord] 0.06u 0.07s 0% 1532k /usr/bin/install -c -o root -g wheel -d /usr/local/bin SNIP === Documentation installed in /usr/local/share/doc/rxvt-unicode. === Compressing manual pages for rxvt-unicode-9.02_1 === Registering installation for rxvt-unicode-9.02_1 load: 0.29 cmd: sed 26266 [biord] 0.00u 0.00s 0% 728k load: 0.27 cmd: sh 26568 [runnable] 0.00u 0.00s 0% 164k load: 0.24 cmd: sh 25951 [biord] 0.14u 0.09s 0% 1228k load: 0.22 cmd: grep 27026 [runnable] 0.00u 0.00s 0% 256k === SECURITY REPORT: This port has installed the following binaries which execute with SNIP real1m13.885s user0m3.903s sys 0m4.870s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# s; sleep 300 echo -e Several memory-intensive jobs performed to clean buffer\n Several memory-intensive jobs performed to clean buffer [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete /var/db/pkg/rxvt-unicode-9.02_1/ load: 0.36 cmd: pkg_delete 27480 [biord] 0.35u 0.40s 1% 972k real0m37.218s user0m0.448s sys 0m0.509s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# make reinstall /dev/null; sync [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete /var/db/pkg/rxvt-unicode-9.02_1/ real0m20.261s user0m0.349s sys 0m0.476s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# So, the time drops from over 7 minutes to 20 seconds -- sweet! :) Notice pkg_info in ^T output during Checking if x11/rxvt-unicode already installed phase. This one takes awhile. The actual command is: `/usr/sbin/pkg_info -q -O x11/rxvt-unicode` real0m37.697s user0m0.125s sys 0m0.360s find_pkgs_by_origin() in info/perform.c uses the same matchbyorigin() in lib/match.c. What's interesting here, however, is that simple `time grep ORIGIN /var/db/pkg/*/+CONTENTS` takes ~7 sec (XXX re-test on that same notebook XXX), while find_pkgs_by_origin() incarnation of practically the same functionality takes over 30 sec. To my eye, it doesn't look like matchbyorigin() could be re-implemented to be faster with little effort, but could somebody have a quick look as well? Would doing mmap() instead of scanning file line-by-line be any faster? (though I'm not saying it's a great idea) BTW, I have a feeling that the Registering installation should be made more verbose. It takes more time that anything else now, and one's left to wonder what exactly is going on (seems like quite a few different things). Also, I found that during the Checking if * already installed step, 'mtree' (XXX find out exact command here XXX) is called (from bsd.port.mk?), which can be skipped by setting NO_MTREE. What effect does [not] calling mtree have? And to conclude, here we have a benchmark from my faster machine (Core2 Dual 2.72GHz, 2G RAM, MK2018GAS 4200RPM HDD with 2M buffer), BEFORE patch was applied: [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make install /dev/null real0m23.097s user0m0.000s sys 0m0.219s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete /var/db/pkg/rxvt-unicode-9.02/ real0m2.243s user0m0.056s sys 0m0.202s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make reinstall /dev/null real0m26.867s user0m0.641s sys 0m0.936s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete /var/db/pkg/rxvt-2.6.4_3/ #very few depends real0m0.090s user0m0.009s
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. yes, and every developer should test their creations on something like this :) something even slower in fact -- think PDA-like device or UMPC. More seriously, though -- it's a midrange machine, it's fast enough for most development tasks (think CAD, Eagle, etc), and when you think about it, 256Mbytes of RAM is plenty. I believe the issue here is not that this machine's RAM is too small, but /var/db/pkg is far too freakin' huge. Over 300 entries for an X11 system? Don't make me laugh. A gazillion more for all this GNOME/GTK stuff? Insane, I say. Look at the depndencies field for `make search` results -- atrocious. How often do you care about a port depending on xproto, Xlib, x..., instead of just Xorg? Since nothing can be done about it, how about placing all the packages that constitute base of Xorg into a separate directory in /var/db/pkg/ ? GNOME stuff could go into another dir. Ditto for other large projects, like KDE. The rest could stay as it is (thereby preserving the incredible convenience and ease with which packages can be managed -- i.e., the UNiX way of text- and filesystem-based shell tools). This would also clean up /var/db/pkg quite a bit -- that is to say, one could more easily have a look over which [useful|non-useful] packages are installed, without diggin' in a directory with hundreds of subdirs. 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. I remember there being a thread about this some time ago, but I don't remember -- why can't it be made part of our base? In two words... Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] [SorAlx] ridin' VS1400 ___ 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
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. aha, thanks! hmm, this should have been pretty obvious to me... 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. I'm personally against of decresing complexity by means of incresing complexity of pkg_install suit (i.e., database instead of fs). I might have a distorted understanding, but UFS2 is an OK database in itself? Can't the the tools be made O(n) without resorting to moving everything to a DB? FS-based approach performs well enough when /var/db/pkg/ is cached, so IMO the issue is just that whole pkg/ tree doesn't fit in cache on machines with 256M RAM anymore (because of sheer monstrosity of the tree caused by them 'modular' approaches to large projects). 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]). right, but note how I suggested 'intelligently modifying' rather than spamming :) I am probably wrong (didn't check in detail), but doesn't bsd.openssl.mk get invoked every time (every port install) if USE_OPENSSL==yes, no matter if the openssl port is installed or not? Anyway, it'd be nice if dinoex could take a look at bsd.openssl.mk (does he need to be CC'd?) Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] [SorAlx] ridin' VS1400 ___ 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 Sun, Mar 30, 2008 at 11:49:46PM -0700, [EMAIL PROTECTED] 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! All right, I've been gone to the Real World for a while, but I returned %-) First, allow me to note that it's rather impressing to see the level of interest and responses my half-baked email about my little digs into pkg_* tools produced. Before I even finished thinking whether I will have enough time to fix the tools proper, patches started appearing on the horizon (the same day, practically)! This is quite reassuring, as it shows that developers still care about code and algorithm quality, even if things work OK on modern hardware (just lack of developer time, that's all, I suppose). For that I'm grateful -- way to go :) you provided excellent analysis... that couldnt go unpunished ;) Now, here are the same tests on the same hardware, but with pkg_tools.patch applied: I updated the patch in place several times.. please make sure you have the latest version or bad things can happen :( I'll respond to the rest of the mail later... thnx for caring about this! roman [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# make [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make install SNIP === Generating temporary packing list === Checking if x11/rxvt-unicode already installed load: 0.53 cmd: pkg_info 25799 [biord] 0.06u 0.07s 0% 1532k /usr/bin/install -c -o root -g wheel -d /usr/local/bin SNIP === Documentation installed in /usr/local/share/doc/rxvt-unicode. === Compressing manual pages for rxvt-unicode-9.02_1 === Registering installation for rxvt-unicode-9.02_1 load: 0.29 cmd: sed 26266 [biord] 0.00u 0.00s 0% 728k load: 0.27 cmd: sh 26568 [runnable] 0.00u 0.00s 0% 164k load: 0.24 cmd: sh 25951 [biord] 0.14u 0.09s 0% 1228k load: 0.22 cmd: grep 27026 [runnable] 0.00u 0.00s 0% 256k === SECURITY REPORT: This port has installed the following binaries which execute with SNIP real1m13.885s user0m3.903s sys 0m4.870s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# s; sleep 300 echo -e Several memory-intensive jobs performed to clean buffer\n Several memory-intensive jobs performed to clean buffer [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete /var/db/pkg/rxvt-unicode-9.02_1/ load: 0.36 cmd: pkg_delete 27480 [biord] 0.35u 0.40s 1% 972k real0m37.218s user0m0.448s sys 0m0.509s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# make reinstall /dev/null; sync [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time pkg_delete /var/db/pkg/rxvt-unicode-9.02_1/ real0m20.261s user0m0.349s sys 0m0.476s [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# So, the time drops from over 7 minutes to 20 seconds -- sweet! :) Notice pkg_info in ^T output during Checking if x11/rxvt-unicode already installed phase. This one takes awhile. The actual command is: `/usr/sbin/pkg_info -q -O x11/rxvt-unicode` real0m37.697s user0m0.125s sys 0m0.360s find_pkgs_by_origin() in info/perform.c uses the same matchbyorigin() in lib/match.c. What's interesting here, however, is that simple `time grep ORIGIN /var/db/pkg/*/+CONTENTS` takes ~7 sec (XXX re-test on that same notebook XXX), while find_pkgs_by_origin() incarnation of practically the same functionality takes over 30 sec. To my eye, it doesn't look like matchbyorigin() could be re-implemented to be faster with little effort, but could somebody have a quick look as well? Would doing mmap() instead of scanning file line-by-line be any faster? (though I'm not saying it's a great idea) BTW, I have a feeling that the Registering installation should be made more verbose. It takes more time that anything else now, and one's left to wonder what exactly is going on (seems like quite a few different things). Also, I found that during the Checking if * already installed step, 'mtree' (XXX find out exact command here XXX) is called (from bsd.port.mk?), which can be skipped by setting NO_MTREE. What effect does [not] calling mtree have? And to conclude, here we have a benchmark from my faster machine (Core2 Dual 2.72GHz, 2G RAM, MK2018GAS 4200RPM HDD with 2M buffer), BEFORE patch was applied: [EMAIL PROTECTED] /usr/ports/x11/rxvt-unicode]# time make install /dev/null real0m23.097s user0m0.000s sys
Re: [patch] pkg_delete(1) speedup
[EMAIL PROTECTED] píše v ne 30. 03. 2008 v 23:49 -0700: Notice pkg_info in ^T output during Checking if x11/rxvt-unicode already installed phase. This one takes awhile. The actual command is: `/usr/sbin/pkg_info -q -O x11/rxvt-unicode` real0m37.697s user0m0.125s sys 0m0.360s find_pkgs_by_origin() in info/perform.c uses the same matchbyorigin() in lib/match.c. What's interesting here, however, is that simple `time grep ORIGIN /var/db/pkg/*/+CONTENTS` takes ~7 sec (XXX re-test on that same notebook XXX), while find_pkgs_by_origin() incarnation of practically the same functionality takes over 30 sec. Possibly the overhead from plist_cmd()/read_plist() functions. It seems to interpret the whole +CONTENTS file instead of just looking for ORIGIN string. BTW, I have a feeling that the Registering installation should be made more verbose. It takes more time that anything else now, and one's left to wonder what exactly is going on (seems like quite a few different things). See pkg-dep target in bsd.port.mk. I bet the biggest timeslice goes into that for dep loop. Also, I found that during the Checking if * already installed step, 'mtree' (XXX find out exact command here XXX) is called (from bsd.port.mk?), which can be skipped by setting NO_MTREE. What effect does [not] calling mtree have? It's actually install-mtree target, which happen to be silent. It creates a tree of directories that are assumed to exist (like /usr/local/bin, /usr/local/lib, ...). If you skip it, some ports may fail to install because those directories are not present. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] The Novice rogue. A rather shifty individual signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: portmaster wants to reinstall OpenOffice
Dominic Fandrey wrote: Yesterday I updated OpenOffice and now whenever I run portmaster -Da it reinstalls it for no reason I can see. Well it doesn't decide to do things for no reason. :) Somehow it believes that there is a newer version. What does 'portmaster -L' say? (Just the part about openoffice) Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portmaster wants to reinstall OpenOffice
Doug Barton wrote: Dominic Fandrey wrote: Yesterday I updated OpenOffice and now whenever I run portmaster -Da it reinstalls it for no reason I can see. Well it doesn't decide to do things for no reason. :) Somehow it believes that there is a newer version. What does 'portmaster -L' say? (Just the part about openoffice) Doug Apparently my /var/db/pkg had broken entries after I created a couple of packages. Languages that were no longer installed, were still registered. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Current unassigned ports problem reports
Current FreeBSD problem reports The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems Serious problems S Tracker Resp. Description o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode f ports/108077www/linux-flashplugin9 crashes linux-firefox o ports/108413[patch] net/vnc does not works. o ports/111430[ PATCH ] security/isakmpd with OpenSSL 0.9.8b and new f ports/112921x11-wm/Beryl not loading focus and keybinding settings s ports/113144print/ghostscript-gnu dumps core with several output d o ports/116378xorg 7.3 on -stable breaks math/scilab f ports/116385net/vnc using vnc.so crashes Xorg 7.3 when remote comp f ports/116586net/isc-dhcp3-server does not work when compiled with f ports/116777The math/scilab port fails in demos-signal-bode. f ports/116778security/nmap ping-scan misses some hosts o ports/117025multimedia/pwcbsd: Pwcbsd-1.4.0 + New USBStack not wor o ports/117128security/ipsec-tools racoon.sh fails with /var on mfs o ports/118877audio/streamripper does not detect song title from str f ports/119546net/nss_ldap makes /usr/bin/ssh dump core in getpwuid( o ports/120372java/linux-sun-jdk16: linux-sun-jre1.6.0 plugin doesn' f ports/121346building net/ekiga fails o ports/121473graphics/gsnapshot crashes upon startup on FreeBSD-6.3 f ports/121830net-mgmt/nagios-plugins: check_disk plugin works incor o ports/122030mail/listmanager needs to install listmanager with mai o ports/122060Update port: mail/postfix-policyd-weight f ports/122083www/mod_clamav refuses to build with apache22 installe o ports/122128Class not found error during print/pdftk port installa f ports/122150devel/libusb port fails to build o ports/122161Update port: multimedia/mpeg_encode Fix for new distfi f ports/122187[patch] security/ipsec-tools failed build on FreeBSD 7 o ports/122194Update port: mail/postfix-policyd-weight (security-fix o ports/122216New port: graphics/sK1 An opensource vector graphics e o ports/122236[Update]math/linpack: update the Makefile o ports/122251New port: graphics/sK1 An opensource vector graphics e f ports/122276Compiled audio/musicpd segfaults on FreeBSD 7.0 f ports/122280building sysutils/fusefs-kmod fails 33 problems total. Non-critical problems S Tracker Resp. Description o ports/102544ltmdm driver (comms/ltmdm) crashes system whene line r o ports/107354net/icmpinfo: icmpinfo -vvv does not recocnize any ICM f ports/107937jailed net/isc-dhcp3-server wouldn't run with an immut o ports/110144New port: math/Matlab7 o ports/110697New port: ports-mgmt/pkg_deps s ports/112887net/nxserver 1.4.0_1 fails to compile after upgrading o ports/113423Update for ports net/freenx to version 0.6.0 o ports/114825pam module security/pam_abl not working s ports/115216ADA devel/florist exit_process program doesn't compile s ports/115217Ada devel/florist socket program doesn't compile due t f ports/115304multimedia/gpac-mp4box cannot import files larger than o ports/115308multimedia/jahshaka fails to open GUI - ends with pre f ports/115336port
Re: ports system woes
[EMAIL PROTECTED] píše v po 31. 03. 2008 v 01:23 -0700: 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. I'm personally against of decresing complexity by means of incresing complexity of pkg_install suit (i.e., database instead of fs). I might have a distorted understanding, but UFS2 is an OK database in itself? Can't the the tools be made O(n) without resorting to moving everything to a DB? You can't query, for example, which package installed some file, without reading the complete +CONTENTS for all installed packages. With, say, SQL database, you could do that under 10 blockreads. FS-based approach performs well enough when /var/db/pkg/ is cached, so IMO the issue is just that whole pkg/ tree doesn't fit in cache on machines with 256M RAM anymore (because of sheer monstrosity of the tree caused by them 'modular' approaches to large projects). Not much we can do about that, we usually follow the rule one vendor distfile = one port and it has served us well. I would be strongly against merging X.org ports back into a monolitic port again. I am probably wrong (didn't check in detail), but doesn't bsd.openssl.mk get invoked every time (every port install) if USE_OPENSSL==yes, no matter if the openssl port is installed or not? Anyway, it'd be nice if dinoex could take a look at bsd.openssl.mk (does he need to be CC'd?) bsd.openssl.mk does get included every time USE_OPENSSL is specified in a port, but that's not a problem. The problem is execution of != assignments you pointed out, and these happen only when openssl port is actually installed. -- Pav Lucistnik [EMAIL PROTECTED] [EMAIL PROTECTED] The Novice rogue. A rather shifty individual signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: portmaster wants to reinstall OpenOffice
Dominic Fandrey wrote: Doug Barton wrote: Dominic Fandrey wrote: Yesterday I updated OpenOffice and now whenever I run portmaster -Da it reinstalls it for no reason I can see. Well it doesn't decide to do things for no reason. :) Somehow it believes that there is a newer version. What does 'portmaster -L' say? (Just the part about openoffice) Doug Apparently my /var/db/pkg had broken entries after I created a couple of packages. Languages that were no longer installed, were still registered. Yeah, that'd do it. You might try looking at the output of 'portmaster -l' and pick a leaf port that you know you want to delete, and use the expunge option (portmaster -e). This will run the -s option to delete anything else that it can detect is stale for you. Take a look at the man page for more information. Good luck, 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]
Fw: ports/120757: New port: www/joomla15 Stable 1.5 version of the Joomla CMS
Hi Freebsd-porters, I have a question about the New-port procedure. On 17 feb I created this port http://www.freebsd.org/cgi/query-pr.cgi?pr=120757 , hoping to see it soon in the official FreeBSD ports tree. I tested the port against the rules in the FreeBSD porters handbook so I knew it worked completely (on my freebsd platform). After that there were several things happening (and not happening) : - First weeks nothing, nobody to pick it up in the audit trail .. - Than somebody else who also created a port for the same joomla15 software. - Than some [EMAIL PROTECTED] who made himself responsible for the port on 7 march. - After a while I noticed that a non working FreeBSD port joomla15 which was not my version, was committed :-? - I emailed him for question how to help to commit the port and I was anwered that I had to wait for a while. - Now I got this email, that another submitted the same software before the procedure to commit my port was finished. My question : can I get the right to commit a port myself or is there any other way to have some more influence on getting the port commited ? There's lots of other nice software to be ported in the future, but I'd like to see my port actually appear in the FreeBSD ports tree. Thanks Andre - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, March 30, 2008 3:30 AM Subject: Re: ports/120757: New port: www/joomla15 Stable 1.5 version of the Joomla CMS Synopsis: New port: www/joomla15 Stable 1.5 version of the Joomla CMS State-Changed-From-To: open-closed State-Changed-By: miwi State-Changed-When: Sun Mar 30 01:30:41 UTC 2008 State-Changed-Why: Sorry is duplicate with 120757 was committed now. Thanks for your submissin. http://www.freebsd.org/cgi/query-pr.cgi?pr=120757 ___ 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
Roman Divacky wrote: To my eye, it doesn't look like matchbyorigin() could be re-implemented to be faster with little effort, but could somebody have a quick look as well? Would doing mmap() instead of scanning file line-by-line be any faster? (though I'm not saying it's a great idea) In the python script check_pkg.py that i mentioned previously (*), i observed that implementing a mmap solution insted of working line by line produced a *great* speedup (5 times if i remember well), but perhaps this is due to python specifics. (*) http://www.lpthe.jussieu.fr/~talon/pkg_check.py -- Michel TALON ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Out of Office AutoReply: (Virus) Returned mail: see transcript for details
Hello, Thank you for your email. I am out of the office from Friday, March 28 through Monday, March 31, returning on Tuesday, April 1. Best regards, John Amundsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [SOLVED] OpenOffice-2.3 : Error building under 7.0-BETA2
Norberto Meijome wrote: [EMAIL PROTECTED] [Mon Nov 5 08:09:34 2007] /usr/ports/editors/openoffice.org-2 $ sudo make -DWITH_DEBUG=2 -DWITH_SYSTEM_FREETYPE -DWITH_CUPS -DWITHOUT_MOZILLA package [] /usr/ports/editors/openoffice.org-2/work/OOG680_m6/odk/pack/gendocu dmake: Executing shell macro: $(FIND) $(INCLUDETOPDIRLIST) -type d -print dmake: Executing shell macro: $(FIND) $(INCLUDETOPDIRLIST) -type f ! $(QOB) -name *~ -o -name *build.lst -o -name *deliver.log $(QCB) -print touch ../../unxfbsdi.pro/misc/cpp_docu_cleanup.flag mkdir -p ../../unxfbsdi.pro/bin/odkcommon/docs/cpp/ref/ /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/bin/autodoc -html ../../unxfbsdi.pro/bin/odkcommon/docs/cpp/ref -name UDK 3.2.7 C/C++ API Reference -lg c++ -p sal /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t sal -t osl -t rtl -p store /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t store -p registry /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t registry -p cppu /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t cppu -t com -t typelib -t uno -p cppuhelper /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t cppuhelper -p salhelper /usr/ports/editors /openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t salhelper -p bridges /usr/ports/editors/openoffice.org-2/work/OOG680_m6/solver/680/unxfbsdi.pro/inc -t bridges Autodoc version 2.2.5 - Parsing the repository UDK 3.2.7 C/C++ API Reference ... ..80 files found to parse in project sal. assertion failed: i 0 ? i_pTokTypeArray[i] i_pTokTypeArray[i-1] : true in file: ../inc/semantic/callf.hxx at line: 186 dmake: Error code 3, while making '../../unxfbsdi.pro/bin/odkcommon/docs/cpp/ref/index.html' ---* RULES.MK *--- ERROR: Error 65280 occurred while making /usr/ports/editors/openoffice.org-2/work/OOG680_m6/odk/pack/gendocu dmake: Error code 1, while making 'build_instsetoo_native' For the archives: This is OpenOffice.org bug #i82101# http://www.openoffice.org/issues/show_bug.cgi?id=82101 Fixed in the 2.4 release (now in ports). --Marcin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
ports/121187: update www/geronimo to 2.1
Hi, Could some kind committer please review/reject: http://www.freebsd.org/cgi/query-pr.cgi?pr=120745 http://www.freebsd.org/cgi/query-pr.cgi?pr=121187 The submission is 4 weeks old. The current maintainer appears uninterested in reviewing it. Thanks. -- Jonathan Chen [EMAIL PROTECTED] We laugh in the face of danger, we drop icecubes down the vest of fear - Edmond Blackadder III ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
