Re: Ports 104877 causing big problems
On Mar 09, 2007, at 22:47 , Doug Barton wrote: On it's face I find the idea of bumping PORTREVISION for every port that uses libtool in any form a sort of silly proposition. The change in behavior was introduced in Mk/*, I think it's reasonable to expect that the fix happen there too. Ok. Let's take this opportunity right here to take a step back and look at the rather larger picture. Prior to bsd.autotools.mk, we had a situation where, by default, .la files were not installed - this made FreeBSD substantially different from both Linux and, somewhat more importantly, pkgsrc. At the same time, there have been an ever-increasing number of ports that *required* .la files to be installed (KDE being a good example here), in the cases of dynamically loading plugins into an application framework. So the decision was made, with plenty of opportunities for discussion, to install .la files by default (along with a whole ton of other infra-structural changes, ie: the migration to USE_AUTOTOOLS, and the introduction of bsd.autotools.mk where the magick happens). End result, FreeBSD is now considerably more "in-line" with Linux and pkgsrc with respect to autotools handling. It's by no means perfect, but it's *a lot* better than it was. Current future plans involve suitable wrapper ports (very similar to Gentoo, given that it's the closest Linux to FreeBSD in terms of its ability to build most everything from source). Anything that touches autotools has far-reaching consequences. Killing off libtool-1.3.x took something like 5 full -exp runs to iron out all the edge cases and even after that, there was still some fallout which had to be addressed. A *lot* of time and effort had to be spent in order to make this happen. So, seemingly innocuous changes like changing the semantics of what a well-established port variable like GNU_CONFIGURE has potentially far- reaching consequences. The armchair generals are more than welcome to debate to their hearts content the idyllic solution, but there are real-world constraints that prevent such nirvana. As autotools maintainer, I have laid out a potential course of action to this (as yet unproven) problem - it's not related to +REQUIRED_BY, as already pointed out. Braino on my part, this is compile and run- time issues, not a ports dependency issue. My apologies. I'm certainly willing to listen to other options, however they must be at least as non-intrusive as the suggested course of action - hint: changing the semantics of GNU_CONFIGURE, or otherwise touching bsd.port.mk, is considerably more intrusive. I don't for one minute pretend to be the absolute authority on autotools, however I believe that I happen to know a reasonable amount, resulting from my shepherding of them over the past few years. Of course, if someone else wants to step up to the plate and continue the good fight, that's fine by me. Send me your freefall login, and the ports and infrastructure will be handed over in a heartbeat. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports 104877 causing big problems
Ade Lovett wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 09, 2007, at 17:30 , Jean-Yves Lefort wrote: On Fri, 9 Mar 2007 17:05:31 -0800 Ade Lovett <[EMAIL PROTECTED]> wrote: 3. Ports that *are* affected by this issue (assuming the issue still exists) can be fixed in a more relaxed manner (eg: a conversion of GNU_CONFIGURE=YES to USE_AUTOTOOLS=configurehack [implying GNU_CONFIGURE=YES]) than a time-T switch. It will also allow for such affected ports to have PORTREVISIONs bumped by the respective maintainers so as to more clearly identify improved operation to the consumers of those ports. All ports that use libtool to produce a program or shared library are affected by this issue. This in turn implies that in case that there is an issue, and something needs to be done about it, then silently changing the semantics of GNU_CONFIGURE is not an appropriate solution. In order for the change, should it be required, to be communicated to all the consumers of the FreeBSD ports tree, and not that subset that happens to read esoteric discussions on a high volume mailing list, this requires that we use the tools available to us, ie: bumping PORTREVISION. On it's face I find the idea of bumping PORTREVISION for every port that uses libtool in any form a sort of silly proposition. The change in behavior was introduced in Mk/*, I think it's reasonable to expect that the fix happen there too. 1. Identify if there is still a problem. I just performed the following experiment. Please let me know if you think this constitutes empirical evidence of a problem. 1. csup'ed to the latest ports tree 2. Saved a copy of /var/db/pkg/libgpg-error-1.4/+REQUIRED_BY 3. pkg_delete'd mtr-0.72, which was listed in the +REQUIRED_BY file 4. Checked the file, mtr was gone. 5. Built and installed mtr 6. mtr is back in /var/db/pkg/libgpg-error-1.4/+REQUIRED_BY There is no reason that mtr would need libgpg-error, and there is no dependency for it in the Makefile. It does however set GNU_CONFIGURE. 2b. If yes, add a new stanza to USE_AUTOTOOLS, for simplicities sake we'll call it lthack, which defines GNU_CONFIGURE, and also wanders through the configuration files performing the appropriate hackery. I don't think this is reasonable, or realistic. It would require that every single port which uses GNU_CONFIGURE gets changed. 3. Maintainers that have ports affected by the issue go in to the Makefile, chunk GNU_CONFIGURE, add USE_AUTOTOOLS= lthack, bump PORTREVISION, and move on to the next one. The burden for fixing problems caused by the infrastructure should not be placed on maintainers generally. Specifically, this problem is too widespread, too nasty, and too urgently in need of a fix to warrant the delays that asking maintainers to make these changes would cause. If a short term fix that is less elegant needs to happen now so that time can be spent on a more elegant one in the longer term, so be it. 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: portupgrade query
Vizion wrote: How do I get out of the following loop! : I run # pkgdb -f Then try # portupgrade -a and get Stale dependency . manuall run 'pkgdb -F to fix or specify -O to force I run # pkgdb -O then run # portupgrade -a and get Stale dependencies ..manually run 'pkgdb -F' to fix or specify -O to force NOTE the references are to p5-Text-Diff-0.35 (textproc/p5-Text-Diff) etc p5-PathTools [ver] [port] p5- [App] [ver] [port] thanks in advance pkgdb -f != pkgdb -F Case sensitivity is what you are missing judging by your written description. i recommend that you 'man pkgdb' and read the description of each option to get a better idea of what you are doing when you run the command. When you do that i think you will find that pkgdb doesn't take a "-O" argument, but that is a different issue than your "-f" troubles. Peace, - Sam ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fuzzyocr
Garrett What user are you running spamassassin as? -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]" Hmm, even modifying it to use /var/log/FuzzyOcr.log I still get the error. I am running spamassassin thru procmail, not the daemon. So, when it is processing an incoming message I see a perl process running owned by the user receiving the message. Brian ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports 104877 causing big problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 09, 2007, at 18:30 , Jean-Yves Lefort wrote: I told you there is one. You have stated there to be a problem. I am still waiting for quantifiable evidence. I have not received any so far. That's right, thousands of commits are more elegant, practical, and faster than a single commit and a test run. There are two separate issues. First, the (possible) fix to the autotools infrastructure which will be done in an appropriate manner, and without violating POLA. The patch in ports/104877 *may* address part of this, but definitely violates POLA by changing the semantics of GNU_CONFIGURE (thus requiring a poke to bsd.port.mk) which will likely result in non-deterministic breakage. The second is for port maintainers of affected ports to utilize the mechanisms provided in step one (if such a step is required), and communicate that fact to folks that use their ports by also bumping PORTREVISION. Of course, if someone (you?) wants to do the leg-work in updating those ports in one go, working with hundreds of distinct port maintainers, dealing with the fallout, shepherding the -exp runs (yes, multiple will be required), by all means go for it. The only relationship that step 2 has to step 1 is that step 1 is a pre- requisite. No more, no less. - -aDe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF8iaGpXS8U0IvffwRAveBAJ9TQTXqMSLZBOpFag2Y6ecjMphCEgCfXHnJ R3lKLigVZ9tFY0HTBX516gY= =Qlih -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: Ports 104877 causing big problems
On Fri, 9 Mar 2007 17:56:52 -0800 Ade Lovett <[EMAIL PROTECTED]> wrote: > On Mar 09, 2007, at 17:30 , Jean-Yves Lefort wrote: > > > On Fri, 9 Mar 2007 17:05:31 -0800 > > Ade Lovett <[EMAIL PROTECTED]> wrote: > >> 3. Ports that *are* affected by this issue (assuming the issue still > >> exists) can be fixed in a more relaxed manner (eg: a conversion of > >> GNU_CONFIGURE=YES to USE_AUTOTOOLS=configurehack [implying > >> GNU_CONFIGURE=YES]) than a time-T switch. It will also allow for > >> such affected ports to have PORTREVISIONs bumped by the respective > >> maintainers so as to more clearly identify improved operation to the > >> consumers of those ports. > > > > All ports that use libtool to produce a program or shared library are > > affected by this issue. > > This in turn implies that in case that there is an issue, and > something needs to be done about it, then silently changing the > semantics of GNU_CONFIGURE is not an appropriate solution. In order > for the change, should it be required, to be communicated to all the > consumers of the FreeBSD ports tree, and not that subset that happens > to read esoteric discussions on a high volume mailing list, this > requires that we use the tools available to us, ie: bumping > PORTREVISION. > > 1. Identify if there is still a problem. I told you there is one. You've been making a fool of yourself by demonstrating that you do not understand the problem, and yet you assume everything I say is wrong? > 2a. If not, get on with something more productive. > 2b. If yes, add a new stanza to USE_AUTOTOOLS, for simplicities sake > we'll call it lthack, which defines GNU_CONFIGURE, and also wanders > through the configuration files performing the appropriate hackery. > > 3. Maintainers that have ports affected by the issue go in to the > Makefile, chunk GNU_CONFIGURE, add USE_AUTOTOOLS= lthack, bump > PORTREVISION, and move on to the next one. > > The semantics of GNU_CONFIGURE itself don't change, so no chance of > unintended infra-structural breakdown, full-tree operations are not > adversely impacted by needlessly including additional Mk/bsd.*.mk > files, and the update is limited to those consumers of the new > USE_AUTOTOOLS stanza, without touching bsd.port.mk, thus not > requiring a full -exp run. A rather more elegant solution than > sledgehammer blows which, whilst occasionally needed, soak up huge > amounts of resource, and are to be avoided if at all possible. That's right, thousands of commits are more elegant, practical, and faster than a single commit and a test run. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgp4QAHE5jR9v.pgp Description: PGP signature
Re: Ports 104877 causing big problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 09, 2007, at 17:30 , Jean-Yves Lefort wrote: On Fri, 9 Mar 2007 17:05:31 -0800 Ade Lovett <[EMAIL PROTECTED]> wrote: 3. Ports that *are* affected by this issue (assuming the issue still exists) can be fixed in a more relaxed manner (eg: a conversion of GNU_CONFIGURE=YES to USE_AUTOTOOLS=configurehack [implying GNU_CONFIGURE=YES]) than a time-T switch. It will also allow for such affected ports to have PORTREVISIONs bumped by the respective maintainers so as to more clearly identify improved operation to the consumers of those ports. All ports that use libtool to produce a program or shared library are affected by this issue. This in turn implies that in case that there is an issue, and something needs to be done about it, then silently changing the semantics of GNU_CONFIGURE is not an appropriate solution. In order for the change, should it be required, to be communicated to all the consumers of the FreeBSD ports tree, and not that subset that happens to read esoteric discussions on a high volume mailing list, this requires that we use the tools available to us, ie: bumping PORTREVISION. 1. Identify if there is still a problem. 2a. If not, get on with something more productive. 2b. If yes, add a new stanza to USE_AUTOTOOLS, for simplicities sake we'll call it lthack, which defines GNU_CONFIGURE, and also wanders through the configuration files performing the appropriate hackery. 3. Maintainers that have ports affected by the issue go in to the Makefile, chunk GNU_CONFIGURE, add USE_AUTOTOOLS= lthack, bump PORTREVISION, and move on to the next one. The semantics of GNU_CONFIGURE itself don't change, so no chance of unintended infra-structural breakdown, full-tree operations are not adversely impacted by needlessly including additional Mk/bsd.*.mk files, and the update is limited to those consumers of the new USE_AUTOTOOLS stanza, without touching bsd.port.mk, thus not requiring a full -exp run. A rather more elegant solution than sledgehammer blows which, whilst occasionally needed, soak up huge amounts of resource, and are to be avoided if at all possible. - -aDe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF8hBlpXS8U0IvffwRAnosAKCQDwIx0ogGLiPi62ZxEsPSHE/6dwCfbdFk XcigDxQoehlavUuScsrabrk= =Im2J -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: Ports 104877 causing big problems
On Fri, 9 Mar 2007 17:05:31 -0800 Ade Lovett <[EMAIL PROTECTED]> wrote: > On Mar 09, 2007, at 15:14 , Doug Barton wrote: > > > Ade Lovett wrote: > >> So, item (1): does the problem actually still exist with a port using > >> the in-tree devel/libtool15 (via USE_AUTOTOOLS= libtool:15[:env]. If > >> yes, empirical evidence will be required as an addendum to the > >> PR. If > >> no, then we're done. > > > > So it sounds like a reasonable way to proceed would be for Kent to > > save a copy of his current libgpg-error +REQUIRED_BY file, then run > > one of the commands that mezz suggested, and compare the before and > > after pictures. If the problem is fixed, they should be substantially > > different. > > Correct. This is the empirical evidence that needs to be determined > and logged within the PR itself. Not correct. Your approval indicates that you do not understand the problem, which has nothing to do with the way the ports framework records dependencies. > Should it turn out that recent changes have not fixed the problem > then, and only then, do we look at the appropriate solution. This > would most likely be along the lines of an additional stanza to the > USE_AUTOTOOLS construct rather than overloading GNU_CONFIGURE since: > > 1. There are most likely a number of ports that define GNU_CONFIGURE > but which do NOT make use of libtool And? > 2. When it comes to ports-wide operations (such as building indexes) > we need to ensure that addition Mk/* infra-structural code is only > brought in when needed. There is a non-zero cost to processing each > Mk/bsd.*.mk file, so it is important to only bring these files in > when absolutely necessary. As is the case here. Lengthening index builds is preferable to forcing users to constantly rebuild their systems. > 3. Ports that *are* affected by this issue (assuming the issue still > exists) can be fixed in a more relaxed manner (eg: a conversion of > GNU_CONFIGURE=YES to USE_AUTOTOOLS=configurehack [implying > GNU_CONFIGURE=YES]) than a time-T switch. It will also allow for > such affected ports to have PORTREVISIONs bumped by the respective > maintainers so as to more clearly identify improved operation to the > consumers of those ports. All ports that use libtool to produce a program or shared library are affected by this issue. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpQvV5E31Qr4.pgp Description: PGP signature
I need to download hugin-0.6.1 and make a test with hugin-0.6.1....HELP!!!
Cna you please tell me how to download this software hugin-0.6.1 I can't downlod the software and instal it!.. please help me ernesto ___ Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports 104877 causing big problems
On Mar 09, 2007, at 15:14 , Doug Barton wrote: Ade Lovett wrote: So, item (1): does the problem actually still exist with a port using the in-tree devel/libtool15 (via USE_AUTOTOOLS= libtool:15[:env]. If yes, empirical evidence will be required as an addendum to the PR. If no, then we're done. So it sounds like a reasonable way to proceed would be for Kent to save a copy of his current libgpg-error +REQUIRED_BY file, then run one of the commands that mezz suggested, and compare the before and after pictures. If the problem is fixed, they should be substantially different. Correct. This is the empirical evidence that needs to be determined and logged within the PR itself. Should it turn out that recent changes have not fixed the problem then, and only then, do we look at the appropriate solution. This would most likely be along the lines of an additional stanza to the USE_AUTOTOOLS construct rather than overloading GNU_CONFIGURE since: 1. There are most likely a number of ports that define GNU_CONFIGURE but which do NOT make use of libtool 2. When it comes to ports-wide operations (such as building indexes) we need to ensure that addition Mk/* infra-structural code is only brought in when needed. There is a non-zero cost to processing each Mk/bsd.*.mk file, so it is important to only bring these files in when absolutely necessary. 3. Ports that *are* affected by this issue (assuming the issue still exists) can be fixed in a more relaxed manner (eg: a conversion of GNU_CONFIGURE=YES to USE_AUTOTOOLS=configurehack [implying GNU_CONFIGURE=YES]) than a time-T switch. It will also allow for such affected ports to have PORTREVISIONs bumped by the respective maintainers so as to more clearly identify improved operation to the consumers of those ports. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports 104877 causing big problems
On Fri, 9 Mar 2007 14:34:31 -0800 Ade Lovett <[EMAIL PROTECTED]> wrote: > On Mar 09, 2007, at 14:21 , Doug Barton wrote: > > Can we have some response from Ade, and/or portmgr on when this might > > be fixed? I would agree that the current behavior is suboptimal. > > I'm pretty certain that this has been addressed with recent updates > to devel/libtool15 and devel/libltdl15 -- certainly it solved the > gnucash problem that had a similar failure case. No. > The patch as it stands in 104877 is flawed in that it brings in > bsd.autotools.mk merely with a GNU_CONFIGURE enabled and as such > makes tree-wide changes to those ports that use this stanza, but not > a USE_AUTOTOOLS stanza, thus giving no incentive for port maintainers > themselves to ensure that the fixes are punted back upstream. The patch is not flawed. bsd.autotools.mk has to be pulled in when GNU_CONFIGURE is set because many ports use libtool and yet do not set USE_AUTOTOOLS=libtool. The included libtool files must therefore be patched. > So, item (1): does the problem actually still exist with a port using > the in-tree devel/libtool15 (via USE_AUTOTOOLS= libtool:15[:env]. If > yes, empirical evidence will be required as an addendum to the PR. > If no, then we're done. No evidence is needed. Your recent commits have had no influence on the problem and it therefore still stands. Furthermore, ports that use their included version of libtool rather than the system libtool are also affected. > Item (2). The patch as stands will not go in, since that part that > is bsd.port.mk fundamentally violates POLA. If such a mechanism is > required, then it will need to be developed as an addendum to the > existing USE_AUTOTOOLS stanza, so that it is *very* clear which ports > need to be upstream-fixed. If you don't like my solution, provide one yourself. You are the maintainer, and you introduced that regression by resurrecting .la files. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpEceE1wvMDW.pgp Description: PGP signature
Re: How to create a patch that removes a file
Spil Oss wrote: > I'd like to submit the patch in a PR, but I don't know (yet :D) how to > include the removal of a file from the port (that patch-file is now > already included in the distributed sources). This works best for me: - Use a cvs mirror - Install ports-mgmt/porttools - Checkout the port, modify, add files with 'cvs add', delete them with 'cvs rm' - run 'port submit' It runs portlint, fills out the PR, CCs the maintainer, hints at added/removed files, etc. Highly recommended! Ulrich Spoerlein -- "The trouble with the dictionary is you have to know how the word is spelled before you can look it up to see how it is spelled." -- Will Cuppy ___ 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: ncurses wide character support in 7.x
Rong-en Fan wrote: > FYI, we have ncurses wide character support in 7.x now. Congratulations! This is a significant step forward. 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: Ports 104877 causing big problems
Ade Lovett wrote: > > On Mar 09, 2007, at 14:21 , Doug Barton wrote: >> Can we have some response from Ade, and/or portmgr on when this might >> be fixed? I would agree that the current behavior is suboptimal. > > I'm pretty certain that this has been addressed with recent updates to > devel/libtool15 and devel/libltdl15 -- certainly it solved the gnucash > problem that had a similar failure case. > > The patch as it stands in 104877 is flawed in that it brings in > bsd.autotools.mk merely with a GNU_CONFIGURE enabled and as such makes > tree-wide changes to those ports that use this stanza, but not a > USE_AUTOTOOLS stanza, thus giving no incentive for port maintainers > themselves to ensure that the fixes are punted back upstream. > > So, item (1): does the problem actually still exist with a port using > the in-tree devel/libtool15 (via USE_AUTOTOOLS= libtool:15[:env]. If > yes, empirical evidence will be required as an addendum to the PR. If > no, then we're done. So it sounds like a reasonable way to proceed would be for Kent to save a copy of his current libgpg-error +REQUIRED_BY file, then run one of the commands that mezz suggested, and compare the before and after pictures. If the problem is fixed, they should be substantially different. 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]"
Why are package builds failing for editors/abiword-plugins?
http://portsmon.freebsd.org/portoverview.py?category=editors&portname=abiword-plugins
i386 and amd64 builds are "failing" as though something were forcing
USE_AUTOTOOLS= libtool:15
and bypassing the included libtool. What's the difference?
% ${WRKSRC}/libtool --features
host: i386-portbld-freebsd6.2
enable shared libraries
disable static libraries
% ${LOCALBASE}/bin/libtool --features
host: i386-portbld-freebsd6.2
enable shared libraries
enable static libraries
The latter builds extraneous .a files, which, of course, are
picked up during the install phase. The package builder sees
files that aren't in the PLIST (and aren't supposed to be),
and it's reported as a failure.
The included libtool is version 1.5.6, and the external libtool
is version 1.5.22, so I can see how it might be beneficial to
"enhance" the abiword-plugins port to work with either one.
However, doing so merely to work around presumed misconfiguration
on the build cluster doesn't strike me as appropriate.
-=EPS=-
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports 104877 causing big problems
On Mar 09, 2007, at 14:21 , Doug Barton wrote: Can we have some response from Ade, and/or portmgr on when this might be fixed? I would agree that the current behavior is suboptimal. I'm pretty certain that this has been addressed with recent updates to devel/libtool15 and devel/libltdl15 -- certainly it solved the gnucash problem that had a similar failure case. The patch as it stands in 104877 is flawed in that it brings in bsd.autotools.mk merely with a GNU_CONFIGURE enabled and as such makes tree-wide changes to those ports that use this stanza, but not a USE_AUTOTOOLS stanza, thus giving no incentive for port maintainers themselves to ensure that the fixes are punted back upstream. So, item (1): does the problem actually still exist with a port using the in-tree devel/libtool15 (via USE_AUTOTOOLS= libtool:15[:env]. If yes, empirical evidence will be required as an addendum to the PR. If no, then we're done. Item (2). The patch as stands will not go in, since that part that is bsd.port.mk fundamentally violates POLA. If such a mechanism is required, then it will need to be developed as an addendum to the existing USE_AUTOTOOLS stanza, so that it is *very* clear which ports need to be upstream-fixed. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ports 104877 causing big problems
Moving this thread from the cvs lists ... The problem described in http://www.freebsd.org/cgi/query-pr.cgi?pr=104877 is now causing significant issues for our users due to the recent libgpg-error version bump. Can we have some response from Ade, and/or portmgr on when this might be fixed? I would agree that the current behavior is suboptimal. 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]"
misc/zoneinfo port on 6.1R and others
I've portsnapped my servers (some are 6.1R, 6.2 Prerelease, 6.2 Beta2 etc) to get the lasted zoneinfo port. Prior to this I tested the timezone info using zdump -v /etc/localtime | grep 2007 , the test showed I had old DST information. I installed the port without issue and re-ran the tzsetup according to my timezone (CST). then I re-ran my test and it never returns, however another test (found in other threads) works date -r 1173679260, on all the hosts. Does this mean I'm really OK or do I need to have the zdump work? I have not rebooted the hosts as suggested in other threads, I really can't. Some of them I've updated the source, cd /usr/src/share/zoneinfo && make && make install then tzsetup and still get a hang. ___ 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: ncurses wide character support in 7.x
On 3/9/07, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Fri, Mar 09, 2007 at 03:49:09PM +0100, Marcus von Appen wrote: > On, Fri Mar 09, 2007, Rong-en Fan wrote: > > > FYI, we have ncurses wide character support in 7.x now. > [...] > > Great work, thanks a lot. Will it be backported to RELENG_6? Same question I had. I'd love to see this backported sometime in the future! Of course, it's already on my list :-) Regards, Rong-En Fan ___ 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: ncurses wide character support in 7.x
On Fri, Mar 09, 2007 at 03:49:09PM +0100, Marcus von Appen wrote: > On, Fri Mar 09, 2007, Rong-en Fan wrote: > > > FYI, we have ncurses wide character support in 7.x now. > [...] > > Great work, thanks a lot. Will it be backported to RELENG_6? Same question I had. I'd love to see this backported sometime in the future! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://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: HEADS UP: ncurses wide character support in 7.x
On, Fri Mar 09, 2007, Rong-en Fan wrote: > FYI, we have ncurses wide character support in 7.x now. [...] Great work, thanks a lot. Will it be backported to RELENG_6? Regards Marcus pgpqN55PfGFQF.pgp Description: PGP signature
Re: Fwd: Abyssmal dump cache efficiency
On Fri, 23 Feb 2007 10:56:17 +0700 Eugene Grosbein wrote: > On Thu, Feb 22, 2007 at 12:37:00PM -0500, Zaphod Beeblebrox wrote: > > >Peter Jeremy wrote: > > >> I've found that you do get a worthwhile improvement in dump|restore > > >> performance by introducing a large (10's of MB) fifo between them. > > >> This helps reduce synchronisation between dump and restore (so that > > >> dump can continue to read whilst restore is busy writing a batch of > > >> small files and vice versa). There's a suitable port but I can't > > >> recall the name because I wrote my own. > > > > > >There are several. The most popular ones are probably > > >misc/team and misc/buffer. > > > > I can certainly vouch for that , too. I generally use "team 1m 32" (total > > of 32meg of buffer). Team seems to not want to buffer more than 1m per > > process and I think 32 is the max # of processes. > Someone, please take a look at trivial patch for team's buffer size here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/106806 > The maintainer timeout for the PR has occured long time ago. Committed, thanks for both your patches and patience. ;-) WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: ncurses wide character support in 7.x
FYI, we have ncurses wide character support in 7.x now. -- Forwarded message -- From: Rong-En Fan <[EMAIL PROTECTED]> Date: Mar 9, 2007 8:11 PM Subject: cvs commit: src Makefile.inc1 src/lib/ncurses Makefile config.mk src/lib/ncurses/form Makefile src/lib/ncurses/formw Makefile src/lib/ncurses/menu Makefile src/lib/ncurses/menuw Makefile src/lib/ncurses/ncurses Makefile ncurses_cfg.h ... To: [EMAIL PROTECTED], [EMAIL PROTECTED], cvs-all@freebsd.org rafan 2007-03-09 12:11:58 UTC FreeBSD src repository Modified files: .Makefile.inc1 lib/ncurses Makefile config.mk lib/ncurses/form Makefile lib/ncurses/menu Makefile lib/ncurses/ncurses Makefile ncurses_cfg.h lib/ncurses/panelMakefile share/mk bsd.libnames.mk Added files: lib/ncurses/formwMakefile lib/ncurses/menuwMakefile lib/ncurses/ncursesw Makefile lib/ncurses/panelw Makefile Log: Enable ncurses wide character support Approved by:delphij (mentor) Tested by: kris on pointyhat (early version), current@ Revision ChangesPath 1.570 +4 -2 src/Makefile.inc1 1.2 +2 -1 src/lib/ncurses/Makefile 1.3 +7 -0 src/lib/ncurses/config.mk 1.13 +3 -3 src/lib/ncurses/form/Makefile 1.1 +5 -0 src/lib/ncurses/formw/Makefile (new) 1.15 +3 -3 src/lib/ncurses/menu/Makefile 1.1 +5 -0 src/lib/ncurses/menuw/Makefile (new) 1.87 +143 -13 src/lib/ncurses/ncurses/Makefile 1.8 +12 -1 src/lib/ncurses/ncurses/ncurses_cfg.h 1.1 +7 -0 src/lib/ncurses/ncursesw/Makefile (new) 1.14 +3 -3 src/lib/ncurses/panel/Makefile 1.1 +5 -0 src/lib/ncurses/panelw/Makefile (new) 1.101 +1 -0 src/share/mk/bsd.libnames.mk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-src To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Little portmaster 1.15 bug in find_and_delete_distfiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, and hi Doug. PR was submitted about it. http://www.freebsd.org/cgi/query-pr.cgi?pr=110125 And thanks for great program. :) - -- Best regards, Simon Phoenix (Phoenix Lab.) - --- KeyID: 0x2569D30B Fingerprint: 78FC 5C40 07CC D331 148E CC79 84B8 D514 2569 D30B - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF8UjohLjVFCVp0wsRCjf7AJ9+mU5V5BokH5ey6u2ZB13hwciM6gCdESFN ZOV1XzRbp2mGoaWQn7OtZLE= =yYp7 -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: [nss_ldap] version upgrade 254 to 255
Fri, 9 Mar 2007 12:45:01 +0900, Artem Kazakov wrote: > Hello guys, > here is the patch to upgrade nss_ldap port to current version 255 Commited. Thanks! -- Andrey Slusar <[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]"
915resolution port on AMD64
Seems to work fine for my setup, I recently switched from i386 to amd64 and it worked ok. No compile errors (only warnings) runs smoothly on 6.2p1-amd64 sincerely yours, Steve Clement -- __o | Steve Clement - Unix System Administrator _ \<,_ | Current Location: Luxembourgr/Europe (_)/ (_) | "Work to Eat, Eat to Live, Live to Bike, Bike to Work" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Zabbix
On Wed, 07 Mar 2007 08:50:10 -0600 Michael Maynard <[EMAIL PROTECTED]> mentioned: > Greetings, > > I am writing to report a possible bug with the installation of zabbix > from ports. Is ucd-snmp required when net-snmp is already installed? > There is no switch to install without ucd-snmp. > > > FreeBSD 6.0-STABLE > > PORTNAME= zabbix > PORTVERSION=1.1.6 > PORTREVISION= 1 > PORTEPOCH= 1 > CATEGORIES= net-mgmt > MASTER_SITES= SF > > > > ===> Installing for zabbix-1.1.6_1,1 > ===> zabbix-1.1.6_1,1 depends on file: > /usr/local/include/php/main/php.h - found > ===> zabbix-1.1.6_1,1 depends on file: > /usr/local/lib/php/20060613/mysql.so - found > ===> zabbix-1.1.6_1,1 depends on file: > /usr/local/lib/php/20060613/gd.so - found > ===> zabbix-1.1.6_1,1 depends on file: > /usr/local/lib/php/20060613/snmp.so - not found > ===>Verifying install for /usr/local/lib/php/20060613/snmp.so in > /usr/ports/net-mgmt/php5-snmp > ===> php5-snmp-5.2.1_3 depends on executable in : phpize - found > ===> php5-snmp-5.2.1_3 depends on file: /usr/local/bin/autoconf259 - found > ===> php5-snmp-5.2.1_3 depends on shared library: snmp.4 - not found > ===>Verifying install for snmp.4 in /usr/ports/net-mgmt/net-snmp4 > ===> Installing for ucd-snmp-4.2.6_5 > > ===> ucd-snmp-4.2.6_5 conflicts with installed package(s): > net-snmp-5.2.3_1 > > They install files into the same place. > Please remove them first with pkg_delete(1). > *** Error code 1 > > Stop in /usr/ports/net-mgmt/net-snmp4. > *** Error code 1 > > Stop in /usr/ports/net-mgmt/php5-snmp. > *** Error code 1 > > Stop in /usr/ports/net-mgmt/zabbix. > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > zabbix depends on net-snmp directly. You should deinstall ucs-snmp package and then install zabbix. It's not possible to use zabbix with ucs-snmp. -- Stanislav Sedov ST4096-RIPE pgpKkDK1C1NYR.pgp Description: PGP signature
