Re: [ bsd.port.mk ] improper evaluation of config-recursive target
On 21-6-2012 21:02, Alexander Pronin wrote:
- @for dir in ${.CURDIR} $$(${ALL-DEPENDS-LIST}); do \
- (cd $$dir; ${MAKE} config-conditional); \
+ @for dir in $$(${MAKE} all-depends-list); do \
Almost.
@for dir in $$(${MAKE} run-depends-list build-depends-list|uniq); do \
Observe the difference on something like x11/xorg.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16-6-2012 17:11, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
And you won't with this patch. Guess I should've explained myself
better. Here's your worst case scenario:
www/apache3 hits the ports tree. There's a typo in the UNIQUENAME making
it equal to apache2's uniquename. pkgng now happily concludes that
www/apache2 moved it's origin and end users get upgraded to apache3. If
you think people bitch about their lost option settings, see how happy
they are when this happens.
The point isn't the INDEX, the point is that if the information you need
isn't available, you fetch it. If you can't count on /usr/ports/MOVED
being available locally, then make it available on the package server
and fetch it. If it doesn't have the information you need, then change
the format.
Also, we *do* have a unique identifier for a package. It's enforced by
the filesystem. This doesn't change with the childports. Each child port
only applies to one port origin. So the combination of PORTORIGIN +
CHILDPORTNAME is UNIQUE!
What this patch does, is a classic example of patching the patch instead
of fixing the problem. If you're going to base critical operations on
the base that something is unique, then you /have/ to ensure that it is
unique by design, not by human intervention.
Also, there's a discussion going on at hackers about the lack of
resources for the project. And here we are: the proposed fix requires
people to check up on other people and devoting computing time to
automate some of that process.
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
Or using a GUID that is checked against a masterlist and assigned
automatically on port creation if you wish to be able to track a port's
movement through the tree.
So, my problem with this patch is that it doesn't address the issue, it
temporarily masks the issue at the advantage that users don't get option
boxes they've already filled out. Matt's work notwithstanding, it
shouldn't be the final solution to the problem.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http
Re: [CFT] UNIQUENAME patches
On 17-6-2012 21:51, Baptiste Daroussin wrote:
On Sun, Jun 17, 2012 at 08:27:33PM +0200, Mel Flynn wrote:
On 16-6-2012 17:11, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 05:06:36PM +0200, Mel Flynn wrote:
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category
automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its
origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
Before saying that you should have a look at what pkgng is. pkgng doesn't
give a
shit about index. and changing the INDEX won't solve that if you have no way
unique way to identify a package you are doomed, have a look at every single
package management system in the world, all of the sane one with real binary
management system have a unique way to identify packages. We don't !
And you won't with this patch. Guess I should've explained myself
better. Here's your worst case scenario:
www/apache3 hits the ports tree. There's a typo in the UNIQUENAME making
it equal to apache2's uniquename. pkgng now happily concludes that
www/apache2 moved it's origin and end users get upgraded to apache3. If
you think people bitch about their lost option settings, see how happy
they are when this happens.
The maintainer should avoid that before committing. No system can prevent bugs
The point isn't the INDEX, the point is that if the information you need
isn't available, you fetch it. If you can't count on /usr/ports/MOVED
being available locally, then make it available on the package server
and fetch it. If it doesn't have the information you need, then change
the format.
Also, we *do* have a unique identifier for a package. It's enforced by
the filesystem. This doesn't change with the childports. Each child port
only applies to one port origin. So the combination of PORTORIGIN +
CHILDPORTNAME is UNIQUE!
What this patch does, is a classic example of patching the patch instead
of fixing the problem. If you're going to base critical operations on
the base that something is unique, then you /have/ to ensure that it is
unique by design, not by human intervention.
Also, there's a discussion going on at hackers about the lack of
resources for the project. And here we are: the proposed fix requires
people to check up on other people and devoting computing time to
automate some of that process.
I really don't see what the problem is with setting uniquename to:
${PORTORIGIN:S,/,__,}+${CHILDPORTNAME}
or:
databases/mysql55+server
databases/mysql55+client
etc.
And so you want to forbid + as a character for PORTNAME? So you would need to
fix all the ports having a + in the name.
No. Ports all have a version starting with a minus sign, yet we have
ports with a minus sign in it. This is the same principle. The plus or
whatever char you pick, should be the first one
Re: kde 4.8.4
On 16-6-2012 15:30, Edwin L. Culp W. wrote: I've upgraded all kde4 to kde4.8.4 except for kdenetwork. It breaks as shown below but I have no idea where to begin to look to try and fix it. [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/urlchecker.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/settings.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/transfertreemodel.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/core/verifier.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/transferadaptor.o [ 12%] Building CXX object kget/CMakeFiles/kgetcore.dir/verifieradaptor.o Linking CXX shared library ../lib/libkgetcore.so [ 12%] Built target kgetcore 1 error *** [all] Error code 2 1 error *** [do-build] Error code 1 Please retry as make -DDISABLE_MAKE_JOBS build. That will show us the real error. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16-6-2012 15:18, Chris Rees wrote:
On 13 June 2012 16:21, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
After recent mention in this list that UNIQUENAME is not actually a
unique name for each port and how obviously non-sensical that is, plus
how it causes various problems with OPTIONS processing and how having a
proper UNIQUENAME will facilitate the new sub-package functionality
currently on the drawing board.
So, here are some patches:
http://people.freebsd.org/~matthew/uniquename/uniquenames.diff
There's also some data on the effect these have on OPTIONSFILE and
UNIQUENAME values per port in
http://people.freebsd.org/~matthew/uniquename/before/*
http://people.freebsd.org/~matthew/uniquename/after/*
Summarizing the changes:
* UNIQUENAME is now unique per port, and is primarily derived from
the port directory name.
* Where the port directory name isn't unique (eg. accessibility/orca
vs graphics/orca) there is a new UNIQUEPREFIX variable to
distinguish the affected ports. This is set for all the LANG
specific category ports (arabic, chinese, french, german, hebrew,
hungarian, japanese, korean, polish, portuguese, russian,
ukranian, vietnamese) to the standard 2 character abbreviation for
that LANG. Otherwise it is only set for the specific ports where
there is a directory name collision, usually based on the category
names.
* To avoid accidental non-uniqueness, UNIQUENAME should be treated
as a read-only variable by port maintainers. UNIQUEPREFIX should
only be set where necessary to resolve conflicts. All instances of
ports setting UNIQUENAME have been removed: in the majority of
cases, this turned out to be a no-op as the new UNIQUENAME turned
out to be the same as what most ports were previously overriding
it to.
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
I'm also for getting rid of the badly chosen default. Since origins are
unique within the tree, we can simply use:
UNIQUENAME=${PORTORIGIN:S,/,,}
Then once you get childports (tis the new and improved name for
subpackages) you can tack that on there in the same way.
On 16-6-2012 16:13, Matthew Seaman wrote:
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
This causes exactly the problem you're trying to solve. When ports get
moved to a new location, they are for all intents and purposes new ports.
Using an origin-based UNIQUENAME makes the most sense and does the right
thing for the common case.
The issue here is that pkgng has problems with the MOVED format and
wishes to tack on to UNIQUENAME to solve it's problem. The obvious
solution here is to come up with a better MOVED format. Although, to me
it isn't clear what the problem is. I doubt it's the MOVED file, it's
probably more to do with ports that change their name based on dependency.
If you really want to track a port even if it's changing locations, then
you really should use some kind of GUID and provide a query interface
for the set options -- which we already have.
You could probably generate the GUIDs on port creation with an svn hook.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory.
If you change the default and ensure it is unique by design, then
migrating options for the user isn't that hard:
OLDSCHEME=${PKGNAMEPREFIX}${PORTNAME}
OLDOPTIONSFILE=${PORT_DBDIR}/${OLDSCHEME}/options
.if exists(${OLDOPTIONSFILE})
_CONFIG_SEQ=migrate-config ${CONFIG_SEQ}
.endif
migrate-config:
@${ECHO_CMD} An options file has been found using the old
@${ECHO_CMD} naming scheme. Would you like to migrate these
@${ECHO_CMD} settings?
...etc
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
I doubt UNIQUENAME is used in casual end user to maintainer
conversations. :)
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] UNIQUENAME patches
On 16-6-2012 16:53, Baptiste Daroussin wrote:
On Sat, Jun 16, 2012 at 03:13:28PM +0100, Matthew Seaman wrote:
On 16/06/2012 14:18, Chris Rees wrote:
That's great-- though rather than patching colliding-only ports, can't
we just add the category to it?
.for cat in ${CATEGORIES}
UNIQUEPREFIX?= ${cat}
.endfor
(copying the code from PKGCATEGORY; might be better off moving the
PKGCATEGORY code up higher and just using that).
Yes. I thought long and hard about doing that, but I opted not to for
two reasons:
1) Using the port name + a uniqueprefix where necessary produces what
is close to the minimal change required to give every port a
unique name. The UNIQUENAME won't actually change for quite a
lot of ports under my scheme.
2) As a way of future-proofing against reorganizations of the ports
tree. What tends to happen is that a new category is invented
and a number of ports are moved into it. My way should avoid
changing the UNIQUENAME in the majority of cases.
Remember that changing the UNIQUENAME changes where the record of the
port options are stored, and either we annoy a lot of users by making
them fill in a buch of dialogues all over again, or we have to invent
some complicated mechanism copy the old options settings to the new
directory. (Yes -- this sort of thing will occur with the changes as
written. It can't be avoided entirely.)
Plus I think it would be more natural and easier for maintainers and
end-users to talk about (say) phpmyadmin rather than
databases-phpmyadmin.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
I'm strongly against adding something related to the category automatically.
Because I'm thinking about binary managerment, adding PKGCATEGORY to
uniquename
would mean a package tracking will be lots in case of moving a port from a
category to another. Currently in pkgng a package is identified by its origin
and thus can't survive automatically from a move, because origin changes.
You should solve this using a better index format. I figured out years
ago that the INDEX format used by the ports system is not a good format
for binary upgrades.
http://lists.freebsd.org/pipermail/freebsd-questions/2008-December/187796.html
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: UID/GID_OFFSET (Was: Re: WITH_GCC)
On 12-6-2012 2:38, Warren Block wrote:
On Fri, 25 May 2012, Mel Flynn wrote:
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER=42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET=2
GID_OFFSET=${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead
of 70.
Okay, I've finally cleared some room to work on this; sorry about the
delay.
My main question is where to add these descriptions. Should they go in
existing sections where possible? Or are we talking about a new
section, and if so, where? At the end of the Dependencies section?
Ideally in man7/ports.7, but I see that is quite outdated. It shouldn't
be in the porters handbook. The variables are useful for end users. The
handbook maybe?
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports need a uniq identifier, do you have any suggestion?
On 11-6-2012 12:32, Baptiste Daroussin wrote: On Mon, Jun 11, 2012 at 07:36:15AM +0100, Matthew Seaman wrote: On 11/06/2012 05:30, Baptiste Daroussin wrote: In the ports tree we lack a unique identifier, while we could live without it until now, it is more than needed for 2 upcoming features: pkgng and stage directory support. unique means something that will always be the same what ever the options are and what ever the runtime they use are. But also means unique in term of in the whole ports no other package will share its identifier. currently the only equivalent of this in the ports tree is the origin of a package, which will no more be unique with the upcoming sub package support (coming along with stage directory) aka 1 origin to produce n package. UNIQUENAME and LATEST_LINK fails in that area because they both can change according to the runtime: py27- for example which will become py30- if you change the default python. LATEST_LINK by default also append the PKGNAMEPREFIX which some ports can be really creative with. should we introduce something new, should we fix one of the above? do you have any suggestion? UNIQUENAME is a clear name. Abusing it should simply not happen and this is a case of badly chosen defaults. This is a variable that should not have a default as it's too expensive to check whether the chosen default lives up to the standard (being ports-tree wide unique), unless you make this a UUID, which is probably not desirable from an operator/transparency perspective to have a hierarchy like: /var/db/ports/---/options. Ideally, a port maintainer should assign a uniquename and be responsible for it. In turn, bsd.port.mk should throw a fit if UNIQUENAME is not set rather then providing a guess that works most of the time. I was looking at this. You'ld think from the name that UNIQUENAME is the appropriate variable here. Yet by my calculations there are 1439 ports using non-unique UNIQUENAME variables. Fixing that seems like common sense to me: why call it unique if it isn't? UNIQUENAME importance being because the default location for a port's OPTIONSFILE is derived from it, and non-uniqueness can lead to ports fighting over control of that file? Which is bad when unintentional, but can be useful for some related ports to share the same options settings. If you want to share an options file, you should share the OPTIONSFILE. Knowing what UNIQUENAME is used for should not be a vehicle to using it as in the future it can be used for more things or be disconnected from the functionality you were using it for. Maybe they are different packages, but they have the same options, and from pkgng we should be able to detect it as the same package just a different runtime which is what they are. Not if they install in version-specific site-packages. Then they really are different packages, since the packing list will be different after expansion of variables. If you count that as same package, then definitions are getting real fuzzy and I'm not sure how well that's going to play out in the long run. The degradation of UNIQUENAME is an excellent example of how things clearly named end up being not what they are. And finally there's the case where extra stuff gets patched or installed based on the interpreter version. Good example is various perl ports where functionality from a CPAN module has been integrated into the perl port itself. So, older modules installed with older versions have (one or more) extra dependencies. On the plus side, these ports don't change UNIQUENAME, but that is just an implementation issue. I don't know of any python ports that change dependencies based on interpreter version, but I wouldn't be surprised if there are some. All this only enforces my view that we should standardize versioned ports and I've started working on it. bsd.databases.mk will be the victim of my first iteration. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: OPTIONSng and OPTIONS_SINGLE, OPTIONS_MULTI
On 11-6-2012 7:49, Matthew Seaman wrote:
Surely it is more sensible to say that OPTIONS_SINGLE is strictly
'choose one from these options.' Then you can implement 'zero or one of
these options' by:
OPTIONS_SINGLE= EXAMPLE
OPTIONS_SINGLE_EXAMPLE= FOO BAR BAZ BLURFL NONE_OF_THE_ABOVE
I like this approach and it would be nice if you can have a standard
none option, rendered in the dialog consistently none with text
none of the above, but translated to ${GROUPNAME}_NONE for the port
and optionsfile. The group should be indented so one sees what of the
above applies to.
So the definition would look like:
OPTIONS_NONEORONE= EXAMPLE
OPTIONS_NONEORONE_EXAMPLE= BLONDE BRUNETTE
And the port's test would be:
.if ${OPTIONS:MEXAMPLE_NONE}
# yay, no work for me
.else
# crap which one he pick
.endif
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: math/ess CONFLICTS with devel/noweb, help with CONFLICTS= needed
On 9-6-2012 14:02, Matthew Seaman wrote: On 09/06/2012 12:25, Christopher J. Ruwe wrote: Thanks for your quick answer. Incidentally, I am at this moment also preparing a maintainer update for a new version of math/ess. Should I perpare two PRs, one for the CONFLICTS and one for the actual update or is it permissable to pack these two into one? It is best to put all the changes you want to make into one PR. That will get it processed most efficiently. And if there's a PR for the conflict problem, then mention in your update PR that this update closes PR xx. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libreoffice, Makefile fix proposal...
On 9-6-2012 9:42, Chris Rees wrote:
On 7 June 2012 15:28, Hiroto Kagotani hiroto.kagot...@gmail.com wrote:
2012/6/7 Sergio de Almeida Lenzi lenzi.ser...@gmail.com:
Well, now that libreoffice build is
solved, than what about insert
a line:
CONFLICTS_BUILD=boost*
near line 63 of Makefile???
libreoffice does not conflict with boost;
just Makefile has a problem.
Attached is the patch.
The only functional difference here is removing the BDB includes from
CPPFLAGS;
from bsd.port.mk
.if defined(HAS_CONFIGURE)
@(cd ${CONFIGURE_WRKSRC} \
${SET_LATE_CONFIGURE_ARGS} \
if ! ${SETENV} CC=${CC} CPP=${CPP} CXX=${CXX} \
CFLAGS=${CFLAGS} CPPFLAGS=${CPPFLAGS} CXXFLAGS=${CXXFLAGS} \
So CPPFLAGS and LDFLAGS are already added to CONFIGURE_ARGS.
I would suspect something more subtle is at work here.
If this fixes things, then some /real/ configure options are the
culprit. This fix doesn't work like the author thinks it does, since
CONFIGURE_ARGS is /not/ CONFIGURE_ENV. So this would effectively result
in environment variables being passed as arguments to the configure
script. You'd have to look at the configure script implementation to see
what the consequences are of that.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] gdal 1.9.1 update and other changes
On 8-6-2012 4:43, Sunpoet Hsieh wrote: On Thu, Jun 7, 2012 at 2:25 PM, Rainer Hurling rhur...@gwdg.de wrote: Am 07.06.2012 05:30 (UTC+1) schrieb Sunpoet Po-Chuan Hsieh: Hi, Many thanks for this update. What I observed so far: (1) graphics/gdal builds and installs fine. There is a minor problem: dependend port science/libkml (as option) does not configure, if devel/swig13 is installed. I'll check that again. I've tested it in tinderbox which does not have swig13 in the jail. (2) graphics/py-gdal asks for option NUMPY several times, even once more if it wants to install (after build). The port should be OK without numpy but the array support will not be enabled. I'm considering to turn NUMPY on by default or just change it from optional to required dependency. If this becomes required it means gcc46-fortran is pulled in. I wouldn't mind a default on option, but I think adding gcc46/fortran to an already complex tool chain should not be done if it can be avoided. Maybe the option description can be changed to: Enable array support through numPY This makes it easier for people to decide whether they need it. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports registering services in /etc/services and services_mkdb
Hi Olli, On 7-6-2012 16:59, Olli Hauer wrote: I don't think it is practical to patch all the ports like like bacula , spamd and others to not use getservbyname and hardcode the required ports? I've got a preliminary patch that I'm going to submit upstream that enables services support in net/nss-pam-ldapd. Services aren't as flexible as users/groups in that you can assign ranges for different NSS sources, thus running services_mkdb may in fact interfere with a site's infrastructure if the particular service has already been defined on a different port. Maybe it's wiser to standardize a pkg-message string? Also, one should never touch /etc/services if nsswitch.conf does not contain compat or files and finally, adding a single service without /etc/services using services_mkdb is not currently possible. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ruby 1.9 as default
On 2-6-2012 3:32, Steve Wills wrote: Hi All, I think we should try to make Ruby 1.9 the default Ruby again and would like to see it done before 9.1 is released. I've submitted a patch which does this and requested and exp-run from portmgr. This may become obsolete soon, since graphics/gdal is going to be updated, but with my current (slightly outdated) ports tree it fails with not being able to find: a) the ruby binary since there is no /usr/local/bin/ruby b) as a side-effect ruby.h, but also because swig is using a deprecated Config interface that apparently is unable to set the include path correctly. swig-1.3.40 RUBY_VER=1.9 in /etc/make.conf RUBY config option set in graphics/gdal Given issues described with swig 1.x earlier on this list, you may want to investigate if swig 1.x should be removed/patched/whatever before this sweep. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ruby 1.9 as default
On 7-6-2012 21:36, Stanislav Sedov wrote: On Thu, 07 Jun 2012 20:58:43 +0200 Mel Flynn rfl...@acsalaska.net mentioned: Given issues described with swig 1.x earlier on this list, you may want to investigate if swig 1.x should be removed/patched/whatever before this sweep. Swig 1.x actually works fine with ruby 1.9, I'm using it quite regularly. SWIG just generate the C source, it does not provide you with include path. It is a responsibility of the application to find out what the correct path are. You can look at my m4 macro as an example of how to do it properly: https://github.com/stass/autoconf-macros/blob/master/ax_ruby_ext.m4 Point being, that: a) /usr/local/bin/ruby does not exist and apparently there are some ports that expect it b) if you symlink /usr/local/bin/ruby19 to ruby, that things still don't work for a port I don't think a package that is as widely used as gdal uses broken makefiles, so either: - these are issues with swig as they generate the makefiles (this was my assumption, but your mail tells me it is incorrect) - there are ways used in the wild to obtain ruby build information that no longer work: gmake -f RubyMakefile.mk build -e:1: Use RbConfig instead of obsolete and deprecated Config -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Firefox 13
On 7-6-2012 21:55, Warren Block wrote: gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? Shot in the dark: SSE support? Based on threads earlier on this list with respect to chrome. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Firefox 13
On 7-6-2012 23:25, Warren Block wrote: On Thu, 7 Jun 2012, Mel Flynn wrote: On 7-6-2012 21:55, Warren Block wrote: gcc46, and I do have CPUTYPE?=native in make.conf... Interesting! Built without CPUTYPE set, Firefox seems fine. Compiler bug? Shot in the dark: SSE support? Based on threads earlier on this list with respect to chrome. SSE support by gcc, you mean? No idea, but just to make sure I rebuilt with CPUTYPE?=native again, and that's definitely the problem. I was referring to this post: http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/075290.html While it's related to clang, CPUTYPE seems to have an effect on selected extensions and perhaps the root cause is there. Like I said, shot in the dark. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: New OPTIONS and make.conf knobs
On 4-6-2012 14:58, Bernhard Froehlich wrote:
On 04.06.2012 13:29, Miroslav Lachman wrote:
Bernhard Froehlich wrote:
On 04.06.2012 11:55, Miroslav Lachman wrote:
There is another problem with options and portmaster.
I have WITHOUT_X11=yes in make.conf and if I try to install
emulators/virtualbox-ose for the first time it immediately ends with
error message instead of showing options dialog.
# portmaster emulators/virtualbox-ose
=== Currently installed version: virtualbox-ose-4.1.16
=== Port directory: /usr/ports/emulators/virtualbox-ose
=== This port is marked BROKEN
=== QT4 frontend requires X11 support. Run 'make config' again!
=== If you are sure you can build it, remove the
BROKEN line in the Makefile and try again.
Terminated
I don't know the order of processing options / knobs so I don't know
if this is the problem of portmaster, OPTIONSng or Makefile it-self.
To fix this problem, I must manually run `make config` in ports
directory and uncheck QT4, then run portmaster again.
That is not a bug at all. It was that way for the last 2 years and still
is. The virtualbox ports do not use the new optionsng stuff yet and the
problem that you are seeing is just because QT4 GUI without X11 doesn't
make sense. If you don't want X11 you also don't want QT4.
Yes, that's right. But I am confused why portmaster does not show the
options dialog to let user uncheck QT4?
What I expect is:
- run portmaster
- show dialog with unchecked X11
- let user uncheck QT4
- save options in /var/db/ports
- show error about conflicting options
Now is:
- run portmaster
- show error about conflicting options
I don't know if it can be solved by portmaster, ports framework or
anything else.
From the BROKEN message:
QT4 frontend requires X11 support. Run 'make config' again!
I think it will be fixed once virtualbox uses optionsng because it is
able to handle such option dependencies but for now it's the same as
it ever was.
I think only the port can handle this as it falls in the sane defaults
category and a framework can never assess what is sane in the specific
port's case.
A solution that works with old options is to assign the On/Off state
with a variable:
.ifdef WITHOUT_X11
QT4_DEFAULT=off
.else
QT4_DEFAULT=on
.endif
OPTIONS=QT4 Enable QT4 support ${QT4_DEFAULT}
I think the same will work with optionsng and probably offers better
sanity checking as you can query for ${UNIQUENAME}_SET of a related
port, like OPENLDAP24_SASL_SET to set the default for ldap sasl support
accordingly instead of throwing an exception.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: optionsng ignores /var/db/ports/portname/options
On 4-6-2012 0:20, Michael Scheidell wrote: optionsng should have been 100% upward compatible. you should not be forced to an an emergency update of a port you maintain just because the ports tree broke things. This has always been broken. It's just exposed by Roland cause he's /adding/ an option and never had any. graphics/py-yaml has the work around and it's been there since version 1.14: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/py-yaml/Makefile?annotate=1.20 (line 25) The real issue is that something created for slave ports (thus set before any of the option framework comes in play) is abused by Mk/ frameworks that only come in sight /after/ options.mk. This causes two versions of UNIQUENAME in the execution stream to exist. One before the framework is included and one after. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] New framework options aka optionng
On 1-6-2012 21:13, Ulrich Spörlein wrote: I hate WITHOUT_NLS and NO_PORTDOCS with a passion. They work for 80% of the ports you are likely to install, so they are not a safe way to escape docs or NLS. Why bother? Seriously, could someone give me a usecase for them? Not sure which ports don't honor NOPORTDOCS, but that should be fixed. The case of NLS is a bit more special. Even though it is possible to build all software without gettext, there are some that don't bother and either build a static version into their library or the port forces the dependency. The use case of WITHOUT_NLS is still valid, even when installation is forced by package foo, package bar that honors the flag will have no dependency on gettext. This means that gettext can be deinstalled when foo is deinstalled. This value shouldn't be underestimated as often I'm looking at a piece of software, don't like it and go look for the next. Also, if there's automagical detection schemes in ports you know of that do not respect WITHOUT_NLS, please file PR's for them or send me the list. It is one of my pet-peeves to get rid of those. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] New framework options aka optionng
On 12-5-2012 5:41, Erwin Lansing wrote: All the details has been documented and written down on the wiki: http://wiki.freebsd.org/Ports/Options/OptionsNG Sorry to jump in late, but it just occurred to me that I have a valid case for zero or 1 multi options or implemented slightly different, a case for if single is on, multigroup needs one, else multigroup must be 0 The specific case is this: - User can opt to force runtime dependency on a web server by selecting one of 4 or none. Same for mail server (3 choices). While these ports do not necessarily conflict, there can be conflicting entries and as such I prefer to narrow the choice to one. Makes more sense too for the practical case. I currently have this implemented in old options, but I don't see a clear way to do this with optionsng as the minimum for multi options is 1. I can of course present these as they are now, 3-4 simple options with custom logic. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [HEADSUP] New framework options aka optionng
On 2-6-2012 15:24, Chris Rees wrote: On Jun 2, 2012 1:57 PM, Mel Flynn rfl...@acsalaska.net wrote: On 12-5-2012 5:41, Erwin Lansing wrote: All the details has been documented and written down on the wiki: http://wiki.freebsd.org/Ports/Options/OptionsNG Sorry to jump in late, but it just occurred to me that I have a valid case for zero or 1 multi options or implemented slightly different, a case for if single is on, multigroup needs one, else multigroup must be 0 The specific case is this: - User can opt to force runtime dependency on a web server by selecting one of 4 or none. Just put a dummy option NOWEBSERVER or something in the singlegroup. I'll think I'll go for NONE to avoid NO/WITHOUT namespaces. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PHP 5.4.0 : lang/php54
On 31-5-2012 5:00, Doug Barton wrote: On 05/30/2012 12:32, Mel Flynn wrote: On 29-5-2012 19:06, Doug Barton wrote: On 5/29/2012 4:00 AM, Mel Flynn wrote: On 29-5-2012 7:23, Doug Barton wrote: Right. The issue I'm talking about is that fixing the problem of staying with a version, introduces a problem for people that have their software up-to-date and don't use deprecated features. Instead of simply upgrading they now have to jump through hoops of changing origins on multiple ports and their depending ports. Each time a new perl version is introduced or the default changes there are failure reports and compared to php, perl is easy as the modules have a single prefix (p5-) vs the versioned prefix now used by the php ports. I understand what you're saying, but in practice users generally don't need to upgrade the version of a dependency that they are using, at least not until it goes EOL. In the case of PHP, users actively oppose being forced to upgrade, as indicated pretty clearly by the demand for php52 and php53 ports. And users using the latest php in production don't have anything to complain about as they have no problem. Maybe that's two people, maybe it's the silent masses that will rain down on the mail servers once we break their easy upgrade path. That said, I agree that we need a more robust way to say Upgrade my perl/php/whatever from version N to version N+M. I am happy to put effort into that if we can get general agreement on what a versioned infrastructure should look like. Right now we have at least 4 different models that I can think of off the top of my head, none of which robustly address our users' needs. Yep, that's what I'm trying to get at. The ideal solution is to have a system that can upgrade between minor versions and micro versions without a difference to the end user. Major version upgrades are a different ballgame entirely as upstream uses a much bigger axe, though the differences between python2.x and 3.x are less big then I expected initially. But, if the ideal solution cannot be achieved, I'm not sure it's wise to sacrifice a system that already does painless minor upgrades so that we can have painless micro version upgrades. 2) All ports that depend on the previous default version are assumed to be working with the new default version. Hopelessly naive. And demonstrably untrue in the case of PHP. No, it's the assumption made by the ports system as is - both now and if you'd version all PHP ports. And as you say below, Stating it doesn't make it true. We already know that it absolutely is *not* true for PHP, it's only sometimes true for Perl, often isn't true for Python ... etc. I know we'd really like it if this were true, but it quite simply isn't; and isn't going to be any time in the foreseeable future. We need to code for what is, not what we wish it would be. Right and I'm describing the state of the code in the ports tree at the moment. Even with ports that are fully versioned, they get marked for specific versions based on user reports or maintainer insights. But if a port works with all versions in the ports tree at the moment then it's not tagged USE_PYTHON= =32. It's marked as USE_PYTHON=yes, which means 'any'. The only way to fix that is to use an opt-in system for supported versions, similar to MAKE_JOBS_SAFE. Right now, it's opt-out. Instead of an omfg I don't wanna upgrade problem, you have an I installed php-foo but it don't work! problem and an additional how do I upgrade to the new version? problem. The latter problem is soluble. Making the first problem go away is critical. Stating it, doesn't make it true. Not sure which you are referring to here. The upgrade to the new version problem is a SMOP. If we can agree on what a framework should look like, we can write tools to do it. But the haphazard way in which it's handled now does not lend itself to a programmatic solution. Well, if we agree that switching a branch should be no different to the end user as upgrading within a branch then the additional issues I think are: - branches marked EOL upstream shall not live on forever (something to think about really, since this will make people lazier) - conflict resolution for modules that have been imported into or ejected from the main source - opt-in mechanism for versions rather than the current opt-out - support for different maintainers per branch - automatic activation of compiled modules in the case of php specifically - a unified system for naming module ports from which the installed interpreter version can be derived preferably without having multiple origin incarnations of the same software - Decision on whether to support multiple versions of the same interpreter being installed and how to handle that if so (non-trivial) Finally, if you have a vast number of machines to worry about, know how the php port works and see trouble ahead because of incompatibilities introduced, then why
Re: PHP 5.4.0 : lang/php54
On 29-5-2012 19:06, Doug Barton wrote: On 5/29/2012 4:00 AM, Mel Flynn wrote: On 29-5-2012 7:23, Doug Barton wrote: Not too hard for leaf ports. But with ports that are depended on, there is always a default, whether it's named that way or not. You're just changing the problem slightly: Not slight at all. I have dealt with many iterations of mass-updates to many systems caused by the silliness we're talking about here. If everyone affected by the lang/php debacle currently had been able to simply set WITH_PHP_VER= 53 prior to the default changing in order to stay at lang/php53, the introduction of lang/php54 would have been a no-op. Right. The issue I'm talking about is that fixing the problem of staying with a version, introduces a problem for people that have their software up-to-date and don't use deprecated features. Instead of simply upgrading they now have to jump through hoops of changing origins on multiple ports and their depending ports. Each time a new perl version is introduced or the default changes there are failure reports and compared to php, perl is easy as the modules have a single prefix (p5-) vs the versioned prefix now used by the php ports. 2) All ports that depend on the previous default version are assumed to be working with the new default version. Hopelessly naive. And demonstrably untrue in the case of PHP. No, it's the assumption made by the ports system as is - both now and if you'd version all PHP ports. Maintainers get a heads up of a new version, but in practice not all have the time to fully test if their application is ready for it and the ones not being able to test in time are simply assumed to be working. Instead of an omfg I don't wanna upgrade problem, you have an I installed php-foo but it don't work! problem and an additional how do I upgrade to the new version? problem. The latter problem is soluble. Making the first problem go away is critical. Stating it, doesn't make it true. Fact is that right now, again, people that have their applications in shape have zero problems upgrading. I can easily state that people that don't want to upgrade can put a +IGNOREME in their respective ports or simply not run upgrades, but the fact of the matter is that the solution that satisfies all isn't that easy. First of all, php is an oddball in the interpreted languages, since it's loadable module directory is not based on release versions but API compatibility. While in theory that's a good thing, it also means that if the module API does not change, that the dependency tracking of the port system fails, as the module will be in exactly the same spot for version X as version Y. Possible solution here is to force depending packages to use a pkg_info-based dependency. Secondly, it also installs only a fraction of it's bundled modules in the main port. This complicates the logic should you decide to use a single PKGPREFIX for for the different extensions as the distinfo, WRKSRC and possibly dependencies has to be set properly. Some packages have moved from pecl- to the main distribution in the past, which makes things even more complicated. Some lessons may be learned from Perl here, though I'm not sure if they have actually moved compiled modules from CPAN into the main source. Finally, if you have a vast number of machines to worry about, know how the php port works and see trouble ahead because of incompatibilities introduced, then why on earth are you not using a local version of the port and merge at your own leisure? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: PHP 5.4.0 : lang/php54
On 29-5-2012 7:23, Doug Barton wrote: On 5/21/2012 9:40 AM, Miroslav Lachman wrote: I think that the best will be to not have any default php5 port and just use php52, php53, php54, php5X, php60... as we have apache20, apache22, apache24, or mysql50-server, mysql51-server, mysql55-server. There is no default apache2 or mysql5-server, so there is no confusion what is / what will be installed. Then it can be choosed in make.conf what version will be used as default, similar to WITH_MYSQL_VER=51 or APACHE_PORT=www/apache22 Doesn't make a difference as there is DEFAULT_MYSQL_VER and DEFAULT_APACHE_VERSION. I have been advocating for this for years. IMO we shouldn't have *any* unversioned ports for things that have multiple simultaneous versions supported. I've actually done this for the things I support (most notably bind*) for a long time, and have never had a single user complaint. Not too hard for leaf ports. But with ports that are depended on, there is always a default, whether it's named that way or not. You're just changing the problem slightly: 1) There's always need for repo copies, followed in the case of php by maintainer changes. (user don't care, until this visibly starts to slow down the port's upgrades or a previous version is suddenly without maintainer) 2) All ports that depend on the previous default version are assumed to be working with the new default version. Instead of an omfg I don't wanna upgrade problem, you have an I installed php-foo but it don't work! problem and an additional how do I upgrade to the new version? problem. 3) Nobody seems to care that this should be addressed: a) upstream for breaking API in minor releases b) upstream for not releasing php6 where many of these features and obsoletions belong. c) depending packages for using features that have been deprecated for years. 4) There's simply no way to not select a default version, unless you want people to be confronted with this port requires php but it's not installed. Either you make a meta-port which allows the user to select the php version it wants, or you provide a default. In case of a meta-port, I'd like to see the patches that handle changing the selected version in the meta port. Concluding from the above, having a lang/php port has the advantage that people tracking the latest version have zero issues installing and upgrading. Having only versioned ports means that there is always need for origin changes across multiple ports when upgrading to a new minor version which as far as I can tell, no ports-mgmt tool can handle in one invocation of the command. Has anyone been working/thinking on unifying the way various lang/* ports and their modules are handled across versions? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libX11 and clang: compile error
On 26-5-2012 11:39, Oliver Pinter wrote: Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ... Stop in /usr/ports/x11/libX11. [1mroot[m@[4mopn[24m libX11# cat /etc/src.conf This file is irrelevant. It is not used by ports (or closer to the truth - it's turned off by /usr/share/mk/bsd.port.mk). -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libX11 and clang: compile error
On 26-5-2012 19:17, Oliver Pinter wrote: I think src.conf is relevant, while it changes the system behavior, as changed the default cc from gcc-4.2 to clang. Thinking it doesn't make it so. Run: grep _WITHOUT_SRCCONF /usr/share/mk/*.mk Then investigate. Setting CC in /etc/src.conf has *no effect on CC passed to the ports*. Really. It does not. The file that can do that is /etc/make.conf. Another way is setting CC in your environment variables, through /etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not. In order to debug your issue, you should provide the output of what make thinks CC and CPP are and backtrack where they are set. Start with: make -C /usr/ports/x11/libX11 -V CC -V CPP -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libX11 and clang: compile error
On 26-5-2012 20:40, Oliver Pinter wrote: On 5/26/12, Mel Flynn rfl...@acsalaska.net wrote: On 26-5-2012 19:17, Oliver Pinter wrote: I think src.conf is relevant, while it changes the system behavior, as changed the default cc from gcc-4.2 to clang. Thinking it doesn't make it so. Run: grep _WITHOUT_SRCCONF /usr/share/mk/*.mk Then investigate. Setting CC in /etc/src.conf has *no effect on CC passed to the ports*. Really. It does not. The file that can do that is /etc/make.conf. Another way is setting CC in your environment variables, through /etc/login.conf, /etc/yourshellrc ~/.profile ~/.[cz]?shrc and what not. In order to debug your issue, you should provide the output of what make thinks CC and CPP are and backtrack where they are set. Start with: make -C /usr/ports/x11/libX11 -V CC -V CPP -- Mel After setting WITH_CLANG_IS_CC in src.conf the base system cc,cpp and c++ has changed: See ports/166373. Also, the fact that your /usr/bin/cpp == clang-cpp is relevant! Especially if you report: Somewhere in config* or Makefile are a hardcoded /usr/bin/cpp ... -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Packages target
Hi, over the past few weeks I've been using the ports system without any ports-mgmt tool and have become utterly convinced that the PACKAGE_SEQ needs to be PACKAGE_SUSEQ for all but package-message. The primary reason is that the install target can install hierarchies or files not readable by the unprivileged user and as such the package target will fail. I'm not aware of any downsides to making this change in bpm or am I overlooking something? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
UID/GID_OFFSET (Was: Re: WITH_GCC)
On 20-5-2012 14:06, Chris Rees wrote:
Usually. Sometimes it's (ab)used to include the relevant bsd.*.mk
file without adding dependencies (WANT_GNOME), but normally that's
what WANT_ is used for.
Definitely add a warning that if you want to use a WANT_ variable you
should also check the relevant Mk/ files to check for syntax.
What's also not consistent is the use of:
USE_FOO=42+
which is shorthand for:
USE_FOO=yes
WANT_FOO_VER= 42+
Anyway, since Warren is on the job, on one of my travels through pmk, I
turned a corner and met these totally awesome user settable variables:
UID_OFFSET
GID_OFFSET
No docs on them in pmk itself or share/examples/etc/make.conf. What they
do is add the specified number to the UID and GID that a port defines by
using /usr/ports/{UIDS,GIDS}. This is extremely useful if you are using
multiple jails on one machine and don't want the uid's to clash (shared
memory for example).
It's also useful, if you have different providers for uid/gid
information through the use of NSS modules. Knowing that ports won't
ever get into your module range makes you sleep better.
Example in /etc/make.conf
UID_OFFSET= 2
GID_OFFSET= ${UID_OFFSET} # best to keep them equal
Installing for example postgresql, will now use uid/gid 20070 instead of 70.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: problem running pkg_delete
On 12-5-2012 20:24, Robert Huff wrote: Suddenly I'm getting: pkg_delete: the package info for package Source is corrupt Any ideas? Can you provide the output of: grep -E '@(unexec|exec).*Source' /var/db/pkg/*/+CONTENTS -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: problem running pkg_delete
On 13-5-2012 14:48, Robert Huff wrote: Mel Flynn writes: pkg_delete: the package info for package Source is corrupt Any ideas? Can you provide the output of: grep -E '@(unexec|exec).*Source' /var/db/pkg/*/+CONTENTS Yes. Well, I was hoping to see some exotic exec construct that would confuse pkg_delete, but no such luck. huff@ grep -E '@(unexec|exec).*Source' /var/db/pkg/*/+CONTENTS /var/db/pkg/p5-Test-Harness-3.23/+CONTENTS:@unexec rmdir %D/lib/perl5/site_perl/5.14.2/TAP/Parser/Source 2/dev/null || true /var/db/pkg/p5-Test-Harness-3.23/+CONTENTS:@unexec rmdir %D/lib/perl5/site_perl/5.14.2/TAP/Parser/SourceHandler 2/dev/null || true This looks a bit suspicious, the quotes shouldn't really be there and it actually installs something ending in Source. However, it's probably best to rule out the obvious: if you have dir /var/db/pkg/Source/ does the +CONTENTS file in it look sane? When in doubt, post it. If you don't, any hits on: grep '^@pkgdep Source' /var/db/pkg/*/+CONTENTS -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: problem running pkg_delete
On 13-5-2012 21:51, Chris Rees wrote: The quotes are from @dirrmtry, so inserted by bsd.port.mk. Ah, shows how rusty I am. Also, why aren't they single quotes? Do we actually support shell expansion dirrmtry? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Zimbra mail exchange port for FreeBSD
Hi, On 2-5-2012 16:47, Kaya Saman wrote: is anyone working on a FreeBSD port of Zimbra? I´ve been working on a port of Zarafa which should provide the same features. The hold up is currently my computer issues and the fact that I am in the process of setting up a second environment to test the LDAP user connector with. If you don't use that feature, the port should be functional, just rough on the edges (it might leave some files behind after deinstall and it needs one or two more rc scripts). https://redports.org/browser/melflynn/mail/zarafa https://redports.org/browser/melflynn/mail/zarafa-libvmime https://redports.org/browser/melflynn/devel/zarafa-libical -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: devel/subversion 1.7.4_1 svnversion errors E200030: sqlite: callback requested query abort
On 4/12/2012 17:30, Jason Hellenthal wrote: Console# sqlite3 .svn/wc.db pragma integrity_check ok Does that mean /usr/src/sys/.svn is a directory? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 4/10/2012 06:14, Da Rock wrote: On 04/10/12 13:14, Mel Flynn wrote: On 4/10/2012 02:26, Da Rock wrote: So what should the patch look like? Am I correct in my understanding of the BUILD_DEPENDS, or have I chased a goose on that one? I'd like to divert your attention to the libnet source directory in samba distribution. It's built by default and integrated into pretty much every binary through libnetapi. Your focus should shift to the compilation error itself, your solution of installing the port libnet masked the actual problem. I'll look into it then. I'm still trying to determine what sets it off. I'm fairly sure ADS is a major factor, though simply disabling it merely grows another failure elsewhere... :/ I'll start posting the logs soon. Is there a particular reason why a dependency on libnet is an issue? If you'd just post the error message and the compilation line that caused it, there'd be a lot of info there that can narrow things down. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 4/10/2012 14:44, Pietro Cerutti wrote: I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In theory, it tickles administrators to look for alternatives if they depend on the port or fork a working copy of the port in their local infrastructure and provides a deadline for this to action to be completed. BROKEN is supposed to be a temporary state, leading to a fix. DEPRECATED is a temporary state leading to removal. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-
On 4/10/2012 16:47, Pietro Cerutti wrote: On 2012-Apr-10, 11:20, Marcelo Araujo wrote: 2012/4/10 Pietro Cerutti g...@freebsd.org I might agree on that. But how is a DEPRECATED port better than a BROKEN one in this regard? In my point of view, no make sense have a bunch of ports that actually doesn't works or because there is a fetch problem or even it is set as BROKEN. Who never was upset when need and find a port but it is BROKEN for some reason, In my view, have a port BROKEN or haven't it, is the same. Of course, I mean when a port is BROKEN for all plataforms as well as for all FreeBSD version. I agree on that. I believe set it as DEPRECATED is a good way to make the maintainer take attention to fix it soon as possible, due he has put effort to insert this software on the ports tree in the past. What about submitting a PR, as we usually do for anything else? If it's ok to wait 15 days (maintainer timeout) to commit an update to a port that brings in important features, it is even more so to wait to deprecate one. Not to discredit your work in any way, but 6 months of being BROKEN can be classified as maintainer timeout in the general case. Also given the error you're seeing it sounds like a very specific case that shouldn't affect the generally solid deprecation policy that is in effect - the bulk of the deprecation cases are upstream abandonware with an equally absent maintainer. I check the list of deprecated ports regularly when I feel nostalgic for blink, java-based rollover menus and News from the previous millennium. On a more constructive note - why don't you mention the specific port? Maybe some of us on the list can help you figure out why some files sometimes don't get byte compiled or provide you with a work-around solution (dynamically generated plist comes to mind). -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: upgrade sqlite3-3.7.10 - sqlite3-3.7.11 appears to break svnversion?
On 4/10/2012 18:11, David Wolfskill wrote: svn: E200030: sqlite: callback requested query abort Does svn cleanup in /usr/src fix the issue? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: upgrade sqlite3-3.7.10 - sqlite3-3.7.11 appears to break svnversion?
On 4/10/2012 18:26, David Wolfskill wrote: On Tue, Apr 10, 2012 at 06:22:24PM +0200, Mel Flynn wrote: On 4/10/2012 18:11, David Wolfskill wrote: svn: E200030: sqlite: callback requested query abort Does svn cleanup in /usr/src fix the issue? ... Huh -- it seems to do precisely that -- thanks! Is this something that should be done ... often? I suspect this is something that svn upgrade should have taken care of as I've only seen the issue with working directories checked out with pre-1.7 subversion and subsequently upgraded to the new format. But I don't have enough data points or insight into subversion code to make that definitive. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autodetecting dependencies
On 4/10/2012 04:02, Stephen Montgomery-Smith wrote: 1. Don't worry about it. tinderbox builds will never build port A in the presence of package B. 2. Have the Makefile of port A detect whether package B is installed, and if it is then add B as a dependency of A. 3. Cripple the configure in port A so that it doesn't autodetect for package B. (Sometimes this can be done using a suitable CONFIGURE_ARGS, but not in my particular situation.) 4. Add OPTION PACKAGE_B. And cripple configure through EXTRA_PATCH if set to off. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: samba34-3.4.14
On 4/10/2012 02:26, Da Rock wrote: So what should the patch look like? Am I correct in my understanding of the BUILD_DEPENDS, or have I chased a goose on that one? I'd like to divert your attention to the libnet source directory in samba distribution. It's built by default and integrated into pretty much every binary through libnetapi. Your focus should shift to the compilation error itself, your solution of installing the port libnet masked the actual problem. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FAQ on PORTREVISION bump?
On 4/5/2012 22:21, Philip M. Gollucci wrote:
On 04/05/12 20:04, Michael Scheidell wrote:
on this one, I did. And was told by crees that I didn't need to wrap
PORTDOCS= around an ifdef.
So, 2 programmers, 2 opinions. Thank God I didn't ask in ports@.
Of the 2 of them one is right. At least as it is currently documented.
[snip bpm docs]
in the case of NOPORTDOCS, no documentation files should be installed,
so this variable should not be set. So you _must_ ifdef it.
Shouldn't confuse two cases:
1) A case where upstream software takes care of installing the
documentation. In this case you can set PORTDOCS without any need to
wrap it, because bpm already takes care of this:
.if !target(add-plist-docs)
add-plist-docs:
.if defined(PORTDOCS) !defined(NOPORTDOCS)
# do the magic
.else
@${DO_NADA}
.endif
In this case you need to pass --disable-docs or something to that
effect to it's CONFIGURE_ARGS or whatever the upstream build system
requires for it. Simply wrapping NOPORTDOCS around PORTDOCS will not do
this for you. It's also possible you need to do reverse: if NOPORTDOCS
is not defined, pass --enable-docs.
2) The case where you abuse PORTDOCS to install the documentation
yourself in (pre|post|do)-install. In this case you shall not install
the documentation if NOPORTDOCS is set and thus either you wrap PORTDOCS
in NOPORTDOCS so that it's an empty variable and your loop in the
install target doesn't run, or you wrap the PORTDOCS related part in the
install target with NOPORTDOCS.
Wrapping the install target is IMHO the preferred option, since you will
also have to disable ${MKDIR} ${DOCSDIR} if you use that.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: BUILD_DEPENDS and libraries -- how to express build-time-only dependency on library?
On 4/1/2012 18:53, Lev Serebryakov wrote:
Hello, Julien.
You wrote 1 апреля 2012 г., 17:04:06:
In case of static build of ported program, port need to have
BUILD_DEPENDS on libraries. LIB_DEPENDS is not suitable here, because
inc ase of static linkage, there will no dependency on livbrary in
runtime.
But BUILD_DEPENDS search for files at absolute pathname or for
executables.
Is it possible to express build-time-only dependency on library?
BUILD_DEPENDS=${LOCALBASE}/lib/libfoo.a:${PORTSDIR}/foo/libfoo ?
It works, but here are other problem: if iconv or gettext or
something like this are used, they added after all libs anyway :(
The upstream build system _has_ to support linking to a static library.
Adding a dependency to a static version of a shared library, does not
magically change the upstream link logic.
You would use the above BUILD_DEPENDS only for libraries that only come
in static version, like hebrew/hspell.
Or when the upstream build system only links with the static version.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
PORTWWW proposal (Was: Re: How useful is %%DATADIR%%, anyway?)
Hi all,
so we took this off list for a bit to work out an implementation.
On 3/29/2012 10:46, Matthew Seaman wrote:
On 28/03/2012 22:04, Mel Flynn wrote:
I'm not sure about exclusion. I have an implementation up here:
http://redports.org/browser/melflynn/net-mgmt/observium/bsd.www.mk
The problem with -not -path $glob is that it isn't the inverse of inclusion:
PORTWWW= html
will only find the dir html and everything below it.
PORTWWWEXCLUDE= html
will only exclude the html dir but not everything below it. The correct
way to write this would be:
PORTWWWEXCLUDE= html html/*
I also can't see a way to do this, since:
html/* - won't match the file named html and we can't test for -d/-f
html* - will also match the paths html.php and htmladmin which may be
undesired.
I suppose one can document it to not abuse the exclusion for directories
but strictly for files.
Hmmm... yes. The '-not -path /foo/bar' construction (not using
wildcards) really only works with files. To stop find(1) recursing into
a whole directory subtree by naming the top of that subtree you'ld use
-prune. With wildcards, yes, it is different, .
Since -prune is always true, it's a whole different beast that requires
wrapping any other arguments into -o \( ... -print \). It won't work
well here.
There is some precedence for using separate variables for files vs
directories: see PLIST_DIRS, PLIST_DIRSTRY and PLIST_FILES.
If we separate exclusion into files and dirs, things get a lot easier,
as we can simply use -not -path '${WWWDIR}/${glob}' -not -path
'${WWWDIR}/${glob}/*' for a directory. The only question is whether to
use PORTWWWEXCLUDE_FILES explicitly or have PORTWWWEXCLUDE be the files one.
There's also the @dirrm vs @dirrmtry question.
Yes, I thought about that. I think it can be done with some
post-processing, rewriting @dirrm foo to @dirrmtry foo for dirs matching
PORTWWW_DIRSTRY.
Anyhow, would you consider publishing your work on freebsd-ports@... so
more interested parties can comment on it? I think it has promise and
I'll have a go trying to apply it to some of my ports over the next week
or so. If it can work correctly with www/rt40 then it should work for
anything.
I'll have these changes incorporated later tonight. While there's now a
lot of variables to consider, it's hard to loose sight of the fact that
the common case will only use PORTWWW=* + the exclusion of one or two
configuration files.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How useful is %%DATADIR%%, anyway?
On 3/24/2012 00:31, Michael Scheidell wrote:
On 3/23/12 6:27 PM, Chris Rees wrote:
Almost. PORTDOCS=* in the Makefile basically uses find on ${DOCSDIR}
and sticks it into TMPPLIST. The advantage is that we then have one
line in the Makefile instead of up to 2000 in pkg-plist.
thats frekeing magic.. how did it find the source in $WRKDIR/specs?
It doesn't. It looks at ${DOCSDIR}. See add-plist-docs target in
Mk/bsd.port.mk.
As such the requirement for this to work, is that docs are installed in
${DOCSDIR}. If a port has a valid reason to not install documentation
into ${PREFIX}/share/doc/${PORTNAME} then DOCSDIR should be set in the
port's Makefile.
Same applies to PORTDATA and PORTEXAMPLES and their respective DATADIR
and EXAMPLESDIR.
I think even more space can be saved if a PORTWWW is introduced, though
PORTWWW=* should be used more carefully as WWWDIR can be dynamic.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: p0f v3
On 3/18/2012 18:01, Kurt Jaeger wrote: Hi! I'll give it a try. I prepared a patch, see http://www.freebsd.org/cgi/query-pr.cgi?pr=166224 It still has an issue with the pkg-plist and I would appreciate hints on what's wrong. You replaced in Makefile: PORTDOCS= COPYING CREDITS ChangeLog KNOWN_BUGS README TODO win-memleak.txt With in pkg-plist: share/doc/p0f/COPYING The PORTDOCS variable respects NOPORTDOCS and does all the automatic pkg-plist stuff. If you want to do it in pkg-plist the line would be: %%PORTDOCSDOCSDIR%%/COPYING Details: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/install.html#INSTALL-DOCUMENTATION -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: qpopper compile failure
On 3/13/2012 14:01, David Southwell wrote: qpopper has been working fine (amd64 running postfix) but on portupgrade I am Getting the following error: set MISSING_OBJS to base64.o set MISSING_SRCS to base64.c Set AR_FLAG = -r ; RANLIB_CMD = checking for sendmail program... ERROR: The sendmail program cannot be located === Script configure failed unexpectedly. Something severely wrong with your setup. It looks at several places for sendmail and does not actually check if the program is a valid sendmail or even executable, just that the file exists. Not even sure where to start looking. I guess the following is a good start: sh -c 'test -f /usr/sbin/sendmail echo sendmail found' If that works on the shell, take portupgrade out of the equation and run make -C /usr/ports/mail/qpopper clean configure. FWIW: rev 1.104 of mail/qpopper/Makefile works for me(tm), except for the configure: WARNING: unrecognized options: --with-apopuid -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: qpopper compile failure
On 3/14/2012 14:53, David Southwell wrote:
On Wednesday 14 March 2012 07:17:55 Mel Flynn wrote:
On 3/13/2012 14:01, David Southwell wrote:
qpopper has been working fine (amd64 running postfix) but on portupgrade
I am Getting the following error:
set MISSING_OBJS to base64.o
set MISSING_SRCS to base64.c
Set AR_FLAG = -r ; RANLIB_CMD =
checking for sendmail program... ERROR: The sendmail program cannot be
located === Script configure failed unexpectedly.
Something severely wrong with your setup. It looks at several places for
sendmail and does not actually check if the program is a valid sendmail
or even executable, just that the file exists.
Not even sure where to start looking. I guess the following is a good
start: sh -c 'test -f /usr/sbin/sendmail echo sendmail found'
If that works on the shell, take portupgrade out of the equation and run
make -C /usr/ports/mail/qpopper clean configure.
FWIW: rev 1.104 of mail/qpopper/Makefile works for me(tm), except for
the configure: WARNING: unrecognized options: --with-apopuid
Here is what we have in response. As sendmail is in /usr/local/sbin a search
in /usr/sbin fails:
[root@dns1 /usr/ports/mail/postfix-policyd-spf-perl]# sh -c 'test -f
/usr/sbin/sendmail echo sendmail found'
[root@dns1 /usr/ports/mail/postfix-policyd-spf-perl]# cd /usr/sbin/
[root@dns1 /usr/sbin]# ls -l |grep sendmail
echo 'CONFIGURE_ARGS+=--sbindir=${PREFIX}/sbin' \
/usr/ports/mail/qpopper/Makefile.local
See if that fixes things.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/openssh-portable
Hello Cy,
On 3/14/2012 08:57, Cy Schubert wrote:
[snip]
What I propose to do is remove the GSSAPI
patch from security/openssh-portable and for those who need the GSSAPI
server key exchange, create a new port (through a repocopy of course) which
includes the illinois.edu GSI patch with reworked FreeBSD patches resolving
patch conflicts, calling it security/openssh-portable-gsi. Does this make
any sense to anyone?
Or, instead of the above, just include the GSI patch by default in a
one-size-fits-all openssh-portable port? (Meaning that the GSI patch is
applied regardless.) Does this make more sense to people?
Personally, I use HPN and LPK. If KRB5 becomes a requirement for HPN, I
don't find that an issue, but others may.
I'm also keeping a local fix you might want to properly integrate into
the LPK patch: it fixes a bug that TLS cannot be turned off if
LPKLdapConf is used.
--
Mel
Index: Makefile
===
RCS file: /home/ncvs/ports/security/openssh-portable/Makefile,v
retrieving revision 1.157
diff -u -r1.157 Makefile
--- Makefile23 Dec 2011 12:52:28 - 1.157
+++ Makefile14 Mar 2012 19:09:36 -
@@ -205,6 +205,9 @@
@${REINPLACE_CMD} -e 's|TMP_SSH_VERSION SSH_PORTABLE|TMP_SSH_VERSION
SSH_PORTABLE SSH_HPN|' \
${WRKSRC}/version.h
.endif
+.if defined(WITH_LPK)
+ @${PATCH} ${PATCH_DIST_ARGS} ${FILESDIR}/fix-lpk-tls.patch
+.endif
pre-su-install:
@${MKDIR} ${EMPTYDIR}
Index: files/fix-lpk-tls.patch
===
RCS file: files/fix-lpk-tls.patch
diff -N files/fix-lpk-tls.patch
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/fix-lpk-tls.patch 2 Jan 2012 17:26:37 -
@@ -0,0 +1,11 @@
+--- ldapauth.c.prev2012-01-02 07:15:19.0 -0900
ldapauth.c 2012-01-02 08:21:23.0 -0900
+@@ -565,6 +565,8 @@
+ else if (!strcasecmp (k, ssl)) {
+ if (!strcasecmp (v, start_tls))
+ l-tls = 1;
++ else if (!strcasecmp(v, off))
++ l-tls = 0;
+ }
+ }
+
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: listing TrueType fonts?
On 3/14/2012 20:00, Robert Huff wrote: If I want to list the Type 1 fonts known to X, I can use x11-fonts/xlsfonts. Is there an equivalent tool for TrueType fonts? fc-list should show them all (part of fontconfig). -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: qpopper compile failure
On 3/14/2012 17:27, David Southwell wrote: That worked It worked to confirm my suspicions. I've filed a proper fix in: http://www.freebsd.org/cgi/query-pr.cgi?pr=166108 -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: skype-2.1.0.81,1
On 3/11/2012 18:59, Joseph Mingrone wrote: On Sun, Mar 11, 2012 at 14:33, Matthias Apitz g...@unixarea.de wrote: It sounds a bit like some NAT issue in the router and the first client connecting to Skype wins. No sure, though. I'm going on a few assumptions that I'll have to verify, but a reboot of the router should flush the first client, but as of today,it's always the laptop client who wins and the phone who fails. I've had issues like this when I was still using Skype. Very hard to trace, but I had the feeling that a login gets bound to a client-id or client version and that failed attempts to log in mark a client-id/client version invalid. When this happened to me, I used the website password reset feature and it would then let me sign on with the new client. It's a shot in the dark, but worth testing. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Building a port with math/superlu fails: linking a shared obj library adding archive superlu.a fails
On 3/11/2012 20:39, O. Hartmann wrote: [...] IsisInterfaceMapLineScan.cc:92:11: warning: variable 'lon_lat_radius' set but not used [-Wunused-but-set-variable] CXXIsisAdjustCameraModel.lo CXXLD libaspIsisIO.la /usr/local/bin/ld: /usr/local/lib/libsuperlu.a(dgssvx.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libsuperlu.a: could not read symbols: Bad value collect2: ld returned 1 exit status *** [libaspIsisIO.la] Error code 1 Are you using USE_AUTOTOOLS=libtool but not automake? I'm seeing similar issues with zarafa if I do just that. If I let the port use the provided libtool *or* use the entire autotools toolchain, then all is well. Also, adding --with-pic to CONFIGURE_ARGS does not change either outcome. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Boost ports update
On 3/8/2012 00:19, Mel Flynn wrote: On 3/7/2012 23:44, Baptiste Daroussin wrote: On Wed, Mar 07, 2012 at 11:56:17PM +0300, Alexander Churanov wrote: Folks, I've read the conversation on ports/156253 (Update devel/boost-* from 1.45 to 1.46.1) and decided to share current status of my work. I have a patch for updating Boost to 1.48.0. http://alexanderchuranov.com/boost-port/boost-145-to-148-v05.diff Adding myself to CC, as the upcoming mail/zarafa uses boost_filesystem. Will be testing patch tomorrow. The current Zarafa 7.0.5 fails with a version check. However, the beta1 of 7.0.6 has the version check upgraded to greater or equal then 149. Patched the version check in 7.0.5's configure and everything compiles OK, with clang on 9.0. Will do runtime tests later this week. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Squeezeboxserver loops endlessly
Hi, On 3/7/2012 22:48, Michael Heitmeier wrote: I just cvsupped ports so I'm wondering is that a problem on my side or is the port broken? === Port directory: /usr/ports/www/p5-libwww === Launching 'make checksum' for www/p5-libwww in background === Gathering dependency list for www/p5-libwww from ports === The dependency for net/p5-Net-HTTP seems to be handled by p5-libwww-5.837 This one of two cases I know of that portmaster is trying to be smarter then it should. It notices a conflict and tries to redirect the dependency to the conflicting port. In many cases this is the correct thing to do, but not in this case, because one of the ports depends on the other. Deleting both p5-libwww-5.837 and p5-Net-HTTP-* and then re-running portmaster should fix things for you. (The other case is detecting BROKEN and failing prematurely so that TRYBROKEN can't be used. It should instead inspect IGNORE to be non empty.) -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Boost ports update
On 3/7/2012 23:44, Baptiste Daroussin wrote: On Wed, Mar 07, 2012 at 11:56:17PM +0300, Alexander Churanov wrote: Folks, I've read the conversation on ports/156253 (Update devel/boost-* from 1.45 to 1.46.1) and decided to share current status of my work. I have a patch for updating Boost to 1.48.0. http://alexanderchuranov.com/boost-port/boost-145-to-148-v05.diff Adding myself to CC, as the upcoming mail/zarafa uses boost_filesystem. Will be testing patch tomorrow. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [lang/perl5.14] Fails on amd64 when WITH_THREADS is enabled
On 2/28/2012 20:56, Spil Oss wrote: /bin/ln -s perldelta.pod pod/perl5142delta.pod LD_LIBRARY_PATH=/var/ports/usr/ports/lang/perl5.14/work/perl-5.14.2 ./miniperl -Ilib autodoc.pl *** Signal 10 I'm out of commission till Monday at least as I tore a muscle in my arm and as such can only type with one hand, but I remembered one more cause of SIGBUS: linking with libc.a (yes, the static library) and -pthread. Any chance that's happening here? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [lang/perl5.14] Fails on amd64 when WITH_THREADS is enabled
On 2/28/2012 14:31, o.°[ kElm ]°.o wrote: hello after irc dial with Barnerd and crest we find a compilation problem with [lang/perl5.12] Fails on amd64 when WITH_THREADS or/and WITH_PTHREADS are enabled [lang/perl5.14] Fails on amd64 when WITH_THREADS or/and WITH_PTHREADS are enabled Note that if you build like make -j4 all, that will not work. You shouldn't have to use -j with ports at all, as ports have MAKE_JOBS* flags in /usr/ports/Mk/bsd.port.mk which will by default grab all CPUs and cores on the system. The perl ports are specifically marked MAKE_JOBS_UNSAFE, which means that the perl build system is not equipped for parallel building. If that was not your error, then please post the error you get. I for one, cannot reproduce your problem. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portupgrade - portmaster Rosetta Stone?
On 2/27/2012 11:18, Olivier Smedts wrote: Now I only need to find a way to ignore the errors when creating a backup package if there was a plist problem, and it will be really fine. It's much easier to not use the feature and use -g as there's a greater chance that the package created during a successful installation will work for restoring purposes. Also, plist problems of past revisions are not interesting, but plist problems of up-to-date packages should generate PR's. All in all, the backup feature is only useful as convenience for when an install fails, but in my experience generates more noise then you're saving. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
[PATCH] deskutils/myitcrm: update to 0.2.9.3
Submitter-Id: current-users
Originator:Mel Flynn
Organization:
Confidential: no
Synopsis: [PATCH] deskutils/myitcrm: update to 0.2.9.3
Severity: non-critical
Priority: low
Category: ports
Class: update
Release: FreeBSD 8.2-STABLE amd64
Environment:
System: FreeBSD datakitty.lan.rachie.is-a-geek.net 8.2-STABLE FreeBSD
8.2-STABLE #6 r230977: Sun Feb 5 06:20:11
Description:
- Update to 0.2.9.3
- Take maintainership
Added file(s):
- files/patch-bug263
Fixes post-release bug which makes billing sections not visible
due to misplaced HTML comment.
Changed files:
- Makefile
- distinfo
- files/pkg-message.in
- pkg-plist
Generated with FreeBSD Port Tools 0.99
How-To-Repeat:
Does not apply.
Fix:
--- myitcrm-0.2.9.3.patch begins here ---
diff -ruN --exclude=CVS
/home/mel/svn/redports/melflynn/deskutils/myitcrm.orig/Makefile
/home/mel/svn/redports/melflynn/deskutils/myitcrm/Makefile
--- /home/mel/svn/redports/melflynn/deskutils/myitcrm.orig/Makefile
2011-09-26 17:16:03.0 -0800
+++ /home/mel/svn/redports/melflynn/deskutils/myitcrm/Makefile 2012-02-25
10:08:03.0 -0900
@@ -6,44 +6,93 @@
#
PORTNAME= myitcrm
-PORTVERSION= 0.2.9.1
+PORTVERSION= 0.2.9.3
CATEGORIES=deskutils
MASTER_SITES= SF/myitcrm/
-DISTNAME= MyITCRM-${PORTVERSION}
+DISTNAME= MyITCRM1-${PORTVERSION}
-MAINTAINER=po...@freebsd.org
-COMMENT= MYIT CRM is a CRM project designed for Computer Servicing and
Repairs
+MAINTAINER=rfl...@acsalaska.net
+COMMENT= MyIT CRM is a CRM project designed for Computer Servicing and
Repairs
+
+LICENSE= GPLv3
USE_ZIP= yes
-USE_PHP+= mysql
-USE_MYSQL= yes
+USE_PHP= mysql session xml
NO_BUILD= yes
-WWWOWN=www
-WWWGRP=${WWWOWN}
+WRKSRC=${WRKDIR}/MyITCRM-${PORTVERSION}
-PKGMESSAGE=${WRKDIR}/${PORTNAME}/pkg-message
SUB_FILES= pkg-message
PLIST_DIRSTRY= %%WWWDIR%%
-
-OPTIONS= APACHE Use Apache webserver on \
- LIGHTTPD Use Lighttpd webserver off
+PATCH_STRIP= -p1
+WRITEABLE= conf.php log/access.log cache
+PORTEXAMPLES= htaccess.txt
+PORTDOCS= changelog.txt README.textile
+USE_DOS2UNIX= yes
+
+OPTIONS= APACHE Use Apache webserver on \
+ PHPMOD Use php module for Apache off \
+ LIGHTTPDUse Lighttpd webserver off \
+ NGINX Use Nginx off
.include bsd.port.options.mk
-.if defined(WITH_APACHE)
-USE_APACHE=22
+.if defined(WITH_PHPMOD)
+WANT_PHP_MOD= yes
+.else
+WANT_PHP_CGI= yes
+.endif
+
+.if !defined(WITHOUT_APACHE)
+USE_APACHE=22+
.endif
.if defined(WITH_LIGHTTPD)
RUN_DEPENDS+= lighttpd:${PORTSDIR}/www/lighttpd
.endif
+.if defined(WITH_NGINX)
+RUN_DEPENDS+= nginx:${PORTSDIR}/www/nginx
+.endif
+
+# Set files to ignore.
+.for file in ${PORTEXAMPLES} ${PORTDOCS} LICENSE.txt
+WWW_IGNORE+= -not -name ${file}
+.endfor
+
+.if defined(MAINTAINER_MODE)
+trace-distfile: distclean
+ @cd ${.CURDIR} make FETCH_ARGS=-vFpr makesum
+
+rm-install:
+ ${SU_CMD} '${RM} -rf ${WWWDIR}/install'
+
+.endif
do-install:
@${MKDIR} ${WWWDIR}
- @${CP} -r ${WRKDIR}/${PORTNAME}-${PORTVERSION}/* ${WWWDIR}
- @${TOUCH} ${WWWDIR}/conf.php
- @${CHOWN} -R ${WWWOWN}:${WWWGRP} ${WWWDIR}
+ @cd ${WRKSRC} ${COPYTREE_SHARE} . ${WWWDIR} '${WWW_IGNORE}'
+ @if [ ! -f ${WWWDIR}/conf.php ]; then \
+ ${CP} ${WWWDIR}/conf-default.php ${WWWDIR}/conf.php; \
+fi
+.for ent in ${WRITEABLE}
+ @${CHOWN} ${WWWOWN}:${WWWGRP} ${WWWDIR}/${ent}
+ @${CHMOD} u+w ${WWWDIR}/${ent}
+.endfor
+.if !defined(NOPORTEXAMPLES)
+ @${MKDIR} ${EXAMPLESDIR}
+.for ex in ${PORTEXAMPLES}
+ @${INSTALL_DATA} ${WRKSRC}/${ex} ${EXAMPLESDIR}
+.endfor
+.endif # NOPORTEXAMPLES
+.if !defined(NOPORTDOCS)
+ @${MKDIR} ${DOCSDIR}
+.for doc in ${PORTDOCS}
+ @${INSTALL_DATA} ${WRKSRC}/${doc} ${DOCSDIR}
+.endfor
+.endif #NOPORTDOCS
post-install:
@${CAT} ${PKGMESSAGE}
+.if defined(MAINTAINER_MODE)
+ @${MAKE} -C ${.CURDIR} rm-install
+.endif
.include bsd.port.mk
diff -ruN --exclude=CVS
/home/mel/svn/redports/melflynn/deskutils/myitcrm.orig/distinfo
/home/mel/svn/redports/melflynn/deskutils/myitcrm/distinfo
--- /home/mel/svn/redports/melflynn/deskutils/myitcrm.orig/distinfo
2011-01-31 05:58:14.0 -0900
+++ /home/mel/svn/redports/melflynn/deskutils/myitcrm/distinfo 2012-02-22
07:31:51.0 -0900
@@ -1,2 +1,2 @@
-SHA256 (MyITCRM-0.2.9.1.zip) =
877583b2c1de8a70a60478ece9b18db8b4571d284426916fdeddd153edc8dfb1
-SIZE (MyITCRM-0.2.9.1.zip) = 2035632
+SHA256 (MyITCRM1-0.2.9.3.zip) =
22560b9b5407cdc099fd775458dfb6bd34f0821dc5d57cd3a5e8e469a270a184
+SIZE (MyITCRM1-0.2.9.3.zip) = 2102844
diff -ruN --exclude=CVS
/home/mel/svn/redports/melflynn/deskutils/myitcrm.orig/files/patch-bug263
/home/mel/svn/redports/melflynn/deskutils/myitcrm
Re: Fix nvidia-like ports, help needed
On 2/23/2012 02:35, Alexey Dokuchaev wrote: On Wed, Feb 22, 2012 at 04:36:08PM -0700, John Hein wrote: One of the issues with 'alternatives' implementations is that they are not selectable per-user (including non superuser). In this particular case (libGL), also what about the native X server vs. virtual X servers that support using the mesa lib (per-application selection)? In addition to something like alternatives, another option is to allow installation of conflicting files (like libGL.so in this case) to separate directories and specify which to use using a path (like LD_LIBRARY_PATH or rpath at compile time). That can help with the aforementioned per-user and per-application variation. Personally, I prefer the path method over something like alternative sym links (e.g., debian/redhat alternatives). There can still be a front-end tool to get at the alternates configuration information, but I like the ability to set a path rather than a sym link. I tend to agree. While I currently do not see clearly the best solution to the problem, when I see etc/alternative.d I want to unsee it ASAP. For nvidia driver, it might be easier to simply provide a knob in xorg-server and libGL and perhaps register a dependency on nvidia-driver; no need to invent some cumbersome framework. Years ago, I suggested to have nvidia-driver conflict with Mesa libGL and select nvidia through WITH_NVIDIA_GL knob. At the time the consensus was that end users shouldn't be left with a non-working system if they uninstall the driver. So maybe the solution it to have a restore mechanism in place (/usr/local/lib/pkg/restore?) that puts replaced files back. This is essentially what nvidia-driver is doing, not just with libGL. The challenge will to update the pkg that it replaced files for and to know that it should not install the files that are replaced in case of an upgrade of that package. This will also make things easier for users, because the current situation is that after an upgrade of Mesa, users will need to forcibly reinstall nvidia-driver to overwrite the libGL. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On 2/21/2012 23:32, Steve Kargl wrote: On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote: On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: On 2012-02-21 20:42, Steve Kargl wrote: ... Yes, /lib comes before /usr/local/lib/gcc46. I suppose that this is a heads up for gerald@. lang/gcc is used by the ports collections to build a large number of other ports, so others are likely to hit this issue. Does -rpath not help ? I already mentioned that I can add '-rpath /usr/local/lib/gcc46' to my various projects. I can also build with -static to avoid rtld. One can also use LD_LIBRARY_PATH. Make sure it's your binary pulling in libgcc_s. I just went through a few iterations of recompiling mplayer with different *FLAGS and each time base gcc_s was pulled in. I then did an ldd -a `which mplayer` and saw libschroedinger was the one actually pulling it in. Recompiled libschroedinger with gcc46 by putting USE_GCC=46 in the Makefile and sure enough: % ldd `which mplayer`|grep gcc libgcc_s.so.1 = /usr/local/lib/gcc46/libgcc_s.so.1 (0x29625000) In short, bsd.gcc.mk is doing the right thing, but dependencies may screw things up. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [RFC] PHP 5.3
Hi, sorry to jump in late.. On Wednesday 02 December 2009 04:52:35 Alex Dupre wrote: Gergely CZUCZY ha scritto: Oh come on. Security-wise you shouldn't hold php at all. It's about backwards incompatibility, not about security. PHP 5.3 is not more incompatible with 5.2 than 5.2 was with 5.1 (and 5.1 with 5.0). 5.2 branch will be dropped in near future, so I'm not going to maintain 80 (eighty) additional ports just for fun. Would it be interesting to see which ports break with 5.3 and fix these or mark them broken before/at the same time 5.3 hits the tree? Also, the impact of the 5.3 incompatibilities is much larger then 5.1 to 5.2, even though the number is similar. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFC: svn for make fetch
On Wed, 18 Nov 2009 11:43:07 +, Thomas Sandford
freebsdu...@paradisegreen.co.uk wrote:
(Sorry, Ive lost track of the higher level attributions, but)
Eitan Adler wrote:
Creating deterministic tars (ignoring metadeta) sounds like it
should be a solved problem by now. If it isn't then I will have to
make it my next project ;)
Instead of creating tar files, create zip files and then run them
through torrentzip
http://www.freebsd.org/cgi/cvsweb.cgi/ports/archivers/torrentzip/
Torrentzip resets the date/time on the files and directories in the
zip archive so that the checksum of the file will match, no matter who
builds the zip file using the same set of files.
Scot
Does such a tool exist for tar archives?
Couldn't you achieve the same thing by the use of touch(1)
Probably, but my idea was at the time to provide a simple way to support
non-releases (like mplayer) and devel snapshots for which a tarball is
not or rarely rolled, with minimal change to bsd.port.mk.
Hence the abuse of FETCH_*. I found it again, I'll clean it up when I have
more time - there's more stuff in my bsd.local.mk so not a clean diff, but
the crux is this:
FETCH_BINARY=${SVN_CMD}
FETCH_ARGS=${SVN_QUIET} export
FETCH_BEFORE_ARGS=-r${SVN_REVISION}
DISABLE_SIZE=yes # screws with FETCH_BEFORE_ARGS
# cwd at this point is ${_DISTDIR}
FETCH_AFTER_ARGS=${_SVN_STAGE} ${TAR} -C ${SVN_STAGE} -czf \
${PORTNAME}-${PORTVERSION}.tar.gz ${PORTNAME}-${PORTVERSION} \
WRKSRC?=${WRKDIR}/${SVN_ROOT}
FETCH_NO_APPEND_FILE=yes
pre-fetch:
@${MKDIR} ${SVN_STAGE}
# Once bsdtar supports remove after archiving, we don't need this anymore.
post-fetch:
@${RM} -rf ${_SVN_STAGE}
(Yes, I realize I should inject my own targets and not abuse
pre|post-fetch).
bsd.port.mk diff snippet (long line):
--- Mk/bsd.port.mk 21 Sep 2009 19:13:51 - 1.629
+++ Mk/bsd.port.mk 22 Sep 2009 01:21:26 -
@@ -3490,11 +3490,15 @@
for site in `eval $$SORTED_MASTER_SITES_CMD_TMP
${_RANDOMIZE_SITES}`; do \
${ECHO_MSG} = Attempting to fetch from $${site}.; \
CKSIZE=`alg=SIZE; ${DISTINFO_DATA}`; \
- case $${file} in \
- */*) ${MKDIR} $${file%/*}; \
- args=-o $${file} $${site}$${file};; \
- *)args=$${site}$${file};; \
- esac; \
+ if test x${FETCH_NO_APPEND_FILE} != xyes; then \
+ case $${file} in \
+ */*) ${MKDIR} $${file%/*}; \
+args=-o $${file} $${site}$${file};; \
+ *)args=$${site}$${file};; \
+ esac; \
+ else \
+ args=$${site}; \
+ fi; \
if ${SETENV} ${FETCH_ENV} ${FETCH_CMD} ${FETCH_BEFORE_ARGS}
$${args} ${FETCH_AFTER_ARGS}; then \
continue 2; \
fi; \
--
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: RFC: svn for make fetch
On Mon, 16 Nov 2009 15:16:22 +0300, Dmitry Marakasov amd...@amdmi3.ru wrote: * Eitan Adler (eitanadlerl...@gmail.com) wrote: I was hoping to get a bit more of a response to a recent posting of mine with regard to using svn to fetch files for ports My proposal: http://www.mail-archive.com/freebsd-ports@freebsd.org/msg23776.html A summary of what has been going on: http://wiki.freebsd.org/EitanAdler/ports-svn This was discussed many times before, and this is a bad idea. - No checksums - security issue - No distfile caching/mirroring - excess traffic consumption and horrible availability Actually, I *had* a patch that got the source from svn, tarred it and checksummed it, with little modification to the do-fetch target and abusing FETCH_* variables. The unsolvable problem I ran in to, is that svn doesn't adjust timestamps for directories on export, so the checksum for the tar was always different. Hacking svn export was outside my timeframe and hacking tar to grow an option that sets all created dirs to a fixed time stamp, seemed too hackish, so I let it go. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: remove BUILD_DEPENDS automatically after install
On Mon, 16 Nov 2009 15:58:23 -0800, Doug Barton do...@freebsd.org wrote: Sandra Kachelmann wrote: (portmaster author cc:ed) On Mon, Nov 16, 2009 at 1:06 AM, Erik Trulsson ertr1...@student.uu.se wrote: On Sun, Nov 15, 2009 at 11:44:04PM +0100, Sandra Kachelmann wrote: Is there a reason why BUILD_DEPENDS aren't being removed after a port has been installed and if no other installed port depends on it? How do you know that the user does not want that port installed? And what if the user will install 20 other ports afterwards - all of which is that same port as a BUILD_DEPENDS - should that port be installed/deinstalled each and every time? It would be nice if this was configurable. Maybe it could be even integrated into portupgrade or portmaster. If such a port is installed directly it could get a package entry DIRECT_INSTALLED=yes in /var/db/pkg/.. or something (there is probably a better way to do this). I have a new feature in the svn version of portmaster called --packages-build that for any given run creates an internal list of dependencies that are only ever listed as build deps (never run deps) and installs packages for them but builds everything else. This feature was created at the request of one of companies that sponsored the package installation code. Currently it does not pkg_delete those packages when it's done, but I could easily add that. \o/ Actually I suppose it would not be too hard to extend that list of build only deps idea to a general feature which deletes them when done. Something like --delete-build-only maybe? This would be limited to the subset of the list of build-only deps that portmaster actually installed. Just because something is build-only for a given run of portmaster doesn't mean that it isn't a run dep for something else if it is already installed. I think this can be handled better with a --finish-cmd. After portmaster is done with everything, exec the finish command. A port build server can then pkg_delete -a and see what's still left in $PREFIX, while a casual user can run pkg_cutleaves -xRg to add the newly installed leafs to the exclude file and remove the build dependencies and their dependencies. (Personally I would be *very* annoyed if, for example, libtool or automake/autoconf would be reinstalled every time I installed a port which had one of them as a build-time dependency. Well then don't use the option. :) Options are generally good things. With libtool there is a gotcha though. If you change CC/CXX, libtool has to be rebuilt, so the package may not be valid. -- -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Stealth dependency in textproc/redland
Hi, the naughty rasqal/configure will try to find libgmp and link with it if found. This must have been installed during a previous package build and after cleaning environment and rebuilding x11/kdebase4-runtime with USE_PACKAGE_DEPENDS I got this error: (Soprano::PluginManager) found no soprano plugin at /usr/local/lib/soprano/libsoprano_redlandbackend.so Failed to create memory model *** Error code 1 1 error *** Error code 2 I traced this to the now absent libgmp.so.8. I'm a little short on time, but if needed can patch and PR it. Would you like this through OPTIONS asking for libgmp or disable it all together? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Creating a New Port: /usr/ports/security/pecl-kadm5
On Wednesday 16 September 2009 02:16:07 Tim Gustafson wrote: Ah yes, didn't test on earlier versions. It's passed midnight here, but I'll add fixes for 7 and 6.x if possible. You probably need to add -lroken to the link chain for this. If you get what's happening in files/patch-config.m4 you can try and fix it yourself. Thanks for all your help on this - I'm really getting excited about the prospect of using this library. I've been holding out for like a year now. :\ I got a bit further than before - I'm attaching the updated files/patch-config.m4 file. I added roken and also com_err. The library compiles and I can call functions in it. However, this is what I'm getting in the Apache error log now: foo/ad...@blah.local's Password: It looks like it's trying to prompt me for a password interactively over STDERR or something at the server level. The latest release is 2003 so it looks largely unmaintained :/. I don't have a kerberos server available that I can play with, without upsetting people :). There's also no docs available that specify if this module is meant to be working through a webserver. However, you did specify a password for kadm5_init_with_password in php? If you have some php testcode, I can see if I can steal a jail to setup a test kerberos server. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Stealth dependency in textproc/redland
On Wednesday 16 September 2009 15:36:36 Chuck Swiger wrote:
Hi, Mel--
On Sep 16, 2009, at 5:46 AM, Mel Flynn wrote:
the naughty rasqal/configure will try to find libgmp and link with
it if found
[ ... ]
I traced this to the now absent libgmp.so.8. I'm a little short on
time, but
if needed can patch and PR it. Would you like this through OPTIONS
asking for
libgmp or disable it all together?
Thanks for the report. It's probably best to have an OPTION which
controls whether to pull in libgmp and list as a dependency, or
disable it from being used. If you write a patch, I'll be happy to
review, otherwise I'll try to add something along those lines when I
get a chance...
Ok, patch attached. Thanks to Jan Henrik Sylvester for pointing at mpfr as
well. I don't believe it's necessary to recompile direct consumers of redland
if any of the math options change, but this is untested by me. I verified
output of make clean config configure for all possible combinations.
--
Mel
Index: textproc/redland/Makefile
===
RCS file: /home/ncvs/ports/textproc/redland/Makefile,v
retrieving revision 1.34
diff -u -r1.34 Makefile
--- textproc/redland/Makefile 22 Aug 2009 00:37:06 - 1.34
+++ textproc/redland/Makefile 16 Sep 2009 16:43:07 -
@@ -8,7 +8,7 @@
PORTNAME= redland
PORTVERSION= 1.0.7
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES=textproc
MASTER_SITES= SF/librdf/${PORTNAME}/${PORTVERSION} \
http://librdf.org/dist/source/
@@ -43,6 +43,9 @@
MAN3= librasqal.3 redland.3
OPTIONS+= MYSQL Use MySQL instead of BDB off
+OPTIONS+= MPFR Use MPFR library for decimals (implies GMP) off
+OPTIONS+= GMP Use Gnu MP library for decimals off
+
.include bsd.port.pre.mk
@@ -55,6 +58,19 @@
PLIST_SUB+=MYSQL=@comment
.endif
+# Set to mpfr if MPFR is on, gmp if only GMP is on and none if neither.
+# This guards against $user setting both GMP and MPFR, since we can't be
+# very verbose in explaining our options.
+.if defined(WITH_MPFR)
+CONFIGURE_ARGS+= --with-decimal=mpfr
+LIB_DEPENDS+= mpfr.3:${PORTSDIR}/math/mpfr
+.elif defined(WITH_GMP)
+CONFIGURE_ARGS+= --with-decimal=gmp
+LIB_DEPENDS+= gmp.8:${PORTSDIR}/math/gmp4
+.else
+CONFIGURE_ARGS+= --with-decimal=none
+.endif
+
pre-everything::
@${ECHO_CMD} You can choose BDB version by setting WITH_BDB_VER to one
off:
@${ECHO_CMD} 3 40 41 42 43 44 3+ 40+ 41+ 42+ 43+ 44+ (current:
${BDB_VER})
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Creating a New Port: /usr/ports/security/pecl-kadm5
On Friday 11 September 2009 02:36:25 Tim Gustafson wrote: I'm trying to create a new port. To get myself started, I copied pecl-hash and then modified the Makefile and the distinfo file. When I try to make my port, it downloads the file from the PECL repository, extracts it, runs configure and then starts compiling, but in the end I get a bunch of errors from cc about undefined constants: kadm5.c: In function 'kadm5_error': kadm5.c:285: error: 'KADM5_FAILURE' undeclared (first use in this function) kadm5.c:285: error: (Each undeclared identifier is reported only once kadm5.c:285: error: for each function it appears in.) kadm5.c:288: error: 'KADM5_AUTH_GET' undeclared (first use in this function) kadm5.c:291: error: 'KADM5_AUTH_ADD' undeclared (first use in this function) So, I manually edited work/kadm5-0.2.3/kadm5.c and added: #include kadm5/kadm5_err.h That file has -most- of the needed declarations, but there are a few more that aren't there, and I'm thinking the version of Kerberos that's installed in FreeBSD 7.2 just doesn't have those declarations (the two missing declarations are for KADM5_AUTH_SETKEY and KADM5_SETKEY_DUP_ENCTYPES). So, my first question is: How can I tell my port to patch work/kadm5-0.2.3/kadm5.c with the needed line above? My second question is: Is there a proper way to hack the needed values into kadm5_err.h? Should I make a new .h file and include it as part of the port only? And last but not least: After I manually patched the kadm5.c file and hacked the missing declarations into kadm5_err.h, I get a different set of errors: kadm5.c: In function 'kadm5_error': kadm5.c:440: error: label at end of compound statement kadm5.c: In function 'zif_kadm5_get_principals': kadm5.c:1048: warning: passing argument 3 of 'kadm5_free_name_list' makes pointer from integer without a cast kadm5.c: In function 'zif_kadm5_get_policies': kadm5.c:1184: warning: passing argument 3 of 'kadm5_free_name_list' makes pointer from integer without a cast Now, I am not a C programmer. I took a C class in about 1996 and that's more or less the last I've done in C. Is there anyone out there who might be kind enough to help me get this port working? I have a real need for Kerberos administration from within PHP, and this PECL library being absent has been a stumbling block for a long time now. Could shar(1) your current work? I can likely fix the issues you're seeing, but it would be nice if you can save me some cycles finding the urls and making the distinfo. How to shar a port is I think covered in the porters handbook. In short: cd /usr/ports shar `find category/portname -type f` /tmp/portname.sh. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: skype problem with fc10 and worldofgoo-demo
On Tuesday 15 September 2009 14:44:22 Alexey Dokuchaev wrote: On Tue, Sep 15, 2009 at 11:39:07AM +0300, Sergey V. Dyatko wrote: Earlier I'm using linux-dri-7.4_1 but today I'm install games/linux-worldofgoo-demo [ti...@tiger]/usr/ports/games/linux-worldofgoo-demo%make run-depends-list /usr/ports/audio/linux-f10-libogg /usr/ports/audio/linux-f10-libvorbis /usr/ports/audio/linux-f10-mikmod /usr/ports/audio/linux-f10-sdl_mixer /usr/ports/devel/linux-f10-sdl12 /usr/ports/emulators/linux_base-f10 /usr/ports/graphics/linux-f10-libGLU /usr/ports/textproc/linux-f10-expat /usr/ports/x11-fonts/linux-f10-fontconfig /usr/ports/x11/linux-f10-xorg-libs Typically, there are two major providers of libGL (both native and Linux flavors): linux-*-dri ports *or* nvidia-driver, depending on what gfx card you have). Now the problem here that linux-*-dri ports install *both* libGL and libGLU, while nvidia-driver installs just libGL (which is perfectly fine, since only libGL must directly interact with hardware via kernel module, for example). Recently bsam@ committed linux-f10-libGLU port with allowed me to port WorldOfGoo; previously, it was impossible without ugly hacks, since I use nVidia card + drivers, which conflict with linux-*-dri (the latter was the only provider of libGL for f10 until recently). Ideally, any port that needs libGL and/or libGLU should depend on libGLU *and* either libGL *or* nvidia-driver. Ports that depend on linux-*-dri to get these libs are very likely to drag conflicts sooner or later (this is especially true for nVidia cards owners). What I never understood is that nvidia-driver fakes dep on libGL, only to replace it. Is the rationale for that, that it eases the pain for the end user when uninstalling nvidia-driver, by still having a libGL around? Or is libGL needed for the opengl headers? I think things are a lot less complicated if nvidia-driver is one of the choices for libGL and that if one wants to stop using it, one does: portmaster -o graphics/libGL nvidia-driver-\* -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: portmaster completion for ZSH
On Tuesday 15 September 2009 21:03:48 Doug Barton wrote: Baptiste Daroussin wrote: Hi, Here is a more complete ZSH completion for portmaster, can people test it and validate it please. to make it work, copy it to /usr/local/share/zsh/site-functions reload you zsh and portmaster [tab] http://github.com/bapt/zfbsd/blob/master/_portmaster Since I don't use zsh I have no way to judge what is better here, so I will leave it to the community to point me in the right direction. I like this one, but haven't tested the former. Will do tomorrow as I suspect daily csup will give me the new portmaster with the old zsh completion. @Baptiste, feature request for csup :. Currently csup -L2 /etc/[tab] gives: No matches for: `verbosity level' or `corrections' Sorry for the little hijack, feel free to take it off list. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Creating a New Port: /usr/ports/security/pecl-kadm5
On Tuesday 15 September 2009 18:29:13 Tim Gustafson wrote: Could shar(1) your current work? I can likely fix the issues you're seeing, but it would be nice if you can save me some cycles finding the urls and making the distinfo. How to shar a port is I think covered in the porters handbook. In short: cd /usr/ports shar `find category/portname -type f` /tmp/portname.sh. I'm attaching the file as a ZIP (so that it doesn't get clobbered anywhere). Thanks for your help - I really appreciate it! Here you go: php -i: kadm5 kadm5 support = enabled You will have to test if this works as expected. I just made it compile and link. -- Mel # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering sh file. Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # security/pecl-kadm5 # security/pecl-kadm5/Makefile # security/pecl-kadm5/distinfo # security/pecl-kadm5/pkg-descr # security/pecl-kadm5/files # security/pecl-kadm5/files/patch-config.m4 # security/pecl-kadm5/files/patch-kadm5.c # security/pecl-kadm5/out # security/pecl-kadm5/err # echo c - security/pecl-kadm5 mkdir -p security/pecl-kadm5 /dev/null 21 echo x - security/pecl-kadm5/Makefile sed 's/^X//' security/pecl-kadm5/Makefile '4bc45574b886d0973c667fac52a88143' X# Ports collection makefile for: pecl-kadm5 X# Date created: 2009-09-10 X# Whom: Tim Gustafson t...@soe.ucsc.edu X# X# $FreeBSD$ X# X XPORTNAME= kadm5 XDISTVERSION= 0.2.3 XCATEGORIES=security www XMASTER_SITES= http://pecl.php.net/get/ XPKGNAMEPREFIX= pecl- XEXTRACT_SUFX= .tgz XDIST_SUBDIR= PECL X XMAINTAINER=t...@soe.ucsc.edu XCOMMENT= Kerberos Admin Module for PHP X XUSE_PHP= yes XUSE_PHPEXT=yes XDEFAULT_PHP_VER=5 X X.include bsd.port.mk 4bc45574b886d0973c667fac52a88143 echo x - security/pecl-kadm5/distinfo sed 's/^X//' security/pecl-kadm5/distinfo 'f740f39faefa93fed072b1a5f9aff7c2' XMD5 (PECL/kadm5-0.2.3.tgz) = 2b393f22232496fb799c452dd3868227 XSHA256 (PECL/kadm5-0.2.3.tgz) = 82423432ebbf7fd827b9049e760ec5139d5661f731854256a1adc43a239f2b37 XSIZE (PECL/kadm5-0.2.3.tgz) = 23090 f740f39faefa93fed072b1a5f9aff7c2 echo x - security/pecl-kadm5/pkg-descr sed 's/^X//' security/pecl-kadm5/pkg-descr 'fb602e7c4f1a8b1c868cf521efbe635a' XThis port enabled the KADM5 module for PHP5. fb602e7c4f1a8b1c868cf521efbe635a echo c - security/pecl-kadm5/files mkdir -p security/pecl-kadm5/files /dev/null 21 echo x - security/pecl-kadm5/files/patch-config.m4 sed 's/^X//' security/pecl-kadm5/files/patch-config.m4 '9e9aa0e8f5d01d840f913b43d4c107be' X--- config.m4.orig 2003-05-09 16:28:45.0 +0200 X+++ config.m4 2009-09-15 23:41:56.0 +0200 X@@ -34,6 +34,28 @@ Xfi X done X fi X+ SEARCH_PATH=/usr/local/include /usr/include /usr/src/krb5-1.2.4/src/include X+ SEARCH_FOR=kadm5/kadm5_err.h X+ AC_MSG_CHECKING(for kadm5/kadm5_err.h) X+ for i in $SEARCH_PATH ; do X+if test -r $i/$SEARCH_FOR; then X+ AC_DEFINE(HAVE_KADM5_ERR_H, [], [Wether kadm5/kadm5_err.h is present]) X+ AC_MSG_RESULT(found in $i) X+fi X+ done X+ AC_MSG_CHECKING(various enum values) X+ ENUMS=KADM5_AUTH_SETKEY KADM5_SETKEY_DUP_ENCTYPES X+ found=0 X+ for i in $ENUMS; do X+if grep -q $i $KADM5_DIR/*; then X+ AC_DEFINE([HAVE_$i], [], [System has $i]) X+ AC_MSG_RESULT($i) X+ found=1 X+fi X+ done X+ if test $found -eq 0; then X+AC_MSG_RESULT(none) X+ fi X X if test -z $KADM5_DIR; then X AC_MSG_RESULT(not found) X@@ -56,10 +78,12 @@ X PHP_SUBST(KADM5_SHARED_LIBADD) X PHP_ADD_LIBRARY_WITH_PATH(kadm5clnt, /usr/lib, KADM5_SHARED_LIBADD) X dnl PHP_ADD_LIBRARY_WITH_PATH(kdb5, /usr/lib, KADM5_SHARED_LIBADD) X- PHP_ADD_LIBRARY_WITH_PATH(gssrpc, /usr/lib, KADM5_SHARED_LIBADD) X+ dnl not needed in FreeBSD PHP_ADD_LIBRARY_WITH_PATH(gssrpc, /usr/lib, KADM5_SHARED_LIBADD) X PHP_ADD_LIBRARY_WITH_PATH(krb5, /usr/lib, KADM5_SHARED_LIBADD) X- PHP_ADD_LIBRARY_WITH_PATH(k5crypto, /usr/lib, KADM5_SHARED_LIBADD) X- PHP_ADD_LIBRARY_WITH_PATH(dyn, /usr/lib, KADM5_SHARED_LIBADD) X+ dnl not needed in FreeBSD PHP_ADD_LIBRARY_WITH_PATH(k5crypto, /usr/lib, KADM5_SHARED_LIBADD) X+ dnl not needed in FreeBSD PHP_ADD_LIBRARY_WITH_PATH(dyn, /usr/lib, KADM5_SHARED_LIBADD) X+ dnl needed for FreeBSD: X+ PHP_ADD_LIBRARY_WITH_PATH(asn1, /usr/lib, KADM5_SHARED_LIBADD) X X PHP_EXTENSION(kadm5, $ext_shared) X fi 9e9aa0e8f5d01d840f913b43d4c107be echo x - security/pecl-kadm5/files/patch-kadm5.c sed 's/^X//' security/pecl-kadm5/files/patch-kadm5.c '3ad0cac2c6984eaf3261c558d078ba70' X--- kadm5.c.orig 2003-05-28 12:51:42.0 +0200 X+++ kadm5.c2009-09-15 23:21:35.0 +0200 X@@ -30,6 +30,9 @@ X #endif X X #include kadm5/admin.h X+#ifdef HAVE_KADM5_ERR_H
Re: Creating a New Port: /usr/ports/security/pecl-kadm5
On Tuesday 15 September 2009 23:50:50 Mel Flynn wrote: On Tuesday 15 September 2009 18:29:13 Tim Gustafson wrote: Could shar(1) your current work? I can likely fix the issues you're seeing, but it would be nice if you can save me some cycles finding the urls and making the distinfo. How to shar a port is I think covered in the porters handbook. In short: cd /usr/ports shar `find category/portname -type f` /tmp/portname.sh. I'm attaching the file as a ZIP (so that it doesn't get clobbered anywhere). Thanks for your help - I really appreciate it! Here you go: php -i: kadm5 kadm5 support = enabled You will have to test if this works as expected. I just made it compile and link. Eep, sorry for not cleaning up the test output. I was checking if make test can be run, but run-tests.php doesn't work without full source as it screws with LD_LIBRARY_PATH. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Creating a New Port: /usr/ports/security/pecl-kadm5
On Wednesday 16 September 2009 00:02:49 Tim Gustafson wrote: You will have to test if this works as expected. I just made it compile and link. Awesome, thanks! I've got it complied and installed. Here's what I get when I use this library now: /libexec/ld-elf.so.1: /usr/lib/libkrb5.so.9: Undefined symbol issuid Is that enough to go on, or do you need more info? Ah yes, didn't test on earlier versions. It's passed midnight here, but I'll add fixes for 7 and 6.x if possible. You probably need to add -lroken to the link chain for this. If you get what's happening in files/patch-config.m4 you can try and fix it yourself. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD unmaintained ports which are currently marked broken
On Monday 07 September 2009 08:29:16 lini...@freebsd.org wrote: portname: graphics/gephex broken because: does not build build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.6.2009081417/ge phex-0.4.4_1.log (_Aug_17_05:37:40_UTC_2009) overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphicsportname=geph ex This is a libtool regression / creative use of libtool15 by upstream. I have fixed the offending module, by patching Makefile.am[1], but then run into issues with the frbinmodule. I could probably fix that too, but since I'm neither a videojock, nor have a joystick, I wonder if making it compile is good enough. So are there any users of this port that could do runtime testing? -- Mel --- modules/src/chromakeymodule/Makefile.am.orig2007-04-29 16:53:43.0 +0200 +++ modules/src/chromakeymodule/Makefile.am 2009-09-09 08:43:28.0 +0200 @@ -11,7 +11,7 @@ chromakeymodule.def: chromakeymodule.spec $(PLUC) def @srcdir@/chromakeymodule.spec -exeex...@sharedlibext@ +EXEEXT=.la bin_PROGRAMS = chromakeymodule @@ -47,7 +47,7 @@ cpuinfoINCLUDES = -I @srcdir@/../../../util/src/cpuinfo endif -chromakeymodule_LDFLAGS = @SHARED_LD_FLAGS@ +chromakeymodule_LDFLAGS = @SHARED_LD_FLAGS@ -module INCLUDES = -...@srcdir@/../../../engine/src/engine \ -...@srcdir@/../../../util/include \ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/engine_pkcs11 unable to use it
On Wednesday 09 September 2009 10:41:32 Alex Dupre wrote: Mel Flynn ha scritto: As per http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart I've modified my /etc/ssl/openssl.cnf, yet: Can you try the command-line alternative? OpenSSL engine -t dynamic -pre SO_PATH:/usr/local/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/local/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD Loaded: (pkcs11) pkcs11 engine unable to load module (null) OpenSSL engine -t dynamic -pre SO_PATH:/usr/local/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/local/lib/engines/engine_pkcs11.so (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/local/lib/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:/usr/local/lib/engines/engine_pkcs11.so Loaded: (pkcs11) pkcs11 engine unable to load module /usr/local/lib/engines/engine_pkcs11.so [ unavailable ] % ldd /usr/local/lib/engines/engine_pkcs11.so /usr/local/lib/engines/engine_pkcs11.so: libp11.so.3 = /usr/local/lib/libp11.so.3 (0x281b7000) libssl.so.6 = /usr/lib/libssl.so.6 (0x2830) libltdl.so.7 = /usr/local/lib/libltdl.so.7 (0x281bf000) libc.so.7 = /lib/libc.so.7 (0x28091000) libcrypto.so.6 = /lib/libcrypto.so.6 (0x28346000) % find /usr/lib /usr/local/lib -name 'opensc-*' -ls|wc -l 0 -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/engine_pkcs11 unable to use it
On Wednesday 09 September 2009 11:45:15 Alex Dupre wrote:
Mel Flynn ha scritto:
Mel Flynn ha scritto:
As per http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart I've
modified my /etc/ssl/openssl.cnf, yet:
Can you try the command-line alternative?
OpenSSL engine -t dynamic -pre
SO_PATH:/usr/local/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre
LIST_ADD:1 -pre LOAD -pre
MODULE_PATH:/usr/local/lib/engines/engine_pkcs11.so (dynamic) Dynamic
engine loading support
[Success]: SO_PATH:/usr/local/lib/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:/usr/local/lib/engines/engine_pkcs11.so
Loaded: (pkcs11) pkcs11 engine
unable to load module /usr/local/lib/engines/engine_pkcs11.so
[ unavailable ]
Ops, I didn't notice it before, but which PKCS11 token are you using?
This is the engine, MODULE_PATH must address a criptoki library.
Aha! Maybe patch below is an idea?
OpenSSL engine -t dynamic -pre
SO_PATH:/usr/local/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1
-pre LOAD -pre MODULE_PATH:/usr/local/lib/opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/local/lib/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:/usr/local/lib/opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine
--- security/engine_pkcs11/Makefile.orig2009-08-05 22:28:40.0
+0200
+++ security/engine_pkcs11/Makefile 2009-09-09 12:01:51.0 +0200
@@ -33,4 +33,8 @@
${WRKSRC}/Makefile.in ${WRKSRC}/doc/Makefile.in
.endif
+post-install:
+ @${ECHO_MSG} You will need a criptoki library to use the engine.
+ @${ECHO_MSG} One is provided by security/opensc
+
.include bsd.port.mk
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/engine_pkcs11 unable to use it
On Wednesday 09 September 2009 12:15:46 Alex Dupre wrote:
Mel Flynn ha scritto:
+post-install:
+ @${ECHO_MSG} You will need a criptoki library to use the
engine. + @${ECHO_MSG} One is provided by security/opensc
+
If you need engine_pkcs11, you know what you want, the cryptoki library
should be the start.
I was actually looking for a way to decrypt my firefox's signons3.txt, which
from searches on the net lead me to pkcs11 functions. ls security|grep pkcs11
lead me to the engine and nothing lead me to security/opensc. Granted, I
should probably have researched the standard further.
However, the configuration file issue remains. With the correct module_path
added to openssl.cnf, openssl refuses to look in /usr/local/lib/engines or to
give any indication it understands the sections added. Is this broken with the
base openssl?
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
security/engine_pkcs11 unable to use it
Hi, after installing security/engine_pkcs11, I'm unable to use it. As per http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart I've modified my /etc/ssl/openssl.cnf, yet: % openssl req -config /etc/ssl/openssl.cnf -engine pkcs11 -new -key id_45 - keyform engine -out req.pem -text -x509 -subj /CN=Foo Bar invalid engine pkcs11 18730:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dso/dso_dlfcn.c:162:filename(/usr/lib/engines/libpkcs11.so): Cannot open /usr/lib/engines/libpkcs11.so 18730:error:25070067:DSO support routines:DSO_load:could not load the shared library:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dso/dso_lib.c:244: 18730:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_dyn.c:450: 18730:error:2606A074:engine routines:ENGINE_by_id:no such engine:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_list.c:415:id=pkcs11 18730:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dso/dso_dlfcn.c:162:filename(libpkcs11.so): Shared object libpkcs11.so not found, required by openssl 18730:error:25070067:DSO support routines:DSO_load:could not load the shared library:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/dso/dso_lib.c:244: 18730:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/engine/eng_dyn.c:450: no engine specified unable to load Private Key Also, the file referenced on the quickstart page opensc-pkcs11.so is not installed by the port. Probably the weirdest thing is that I see no evidence of openssl understanding the configuration variables, meaning not looking in /usr/local/lib. For completeness: openssl.cnf changes: engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path= /usr/local/lib/engines/engine_pkcs11.so init= 0 uname -a FreeBSD smoochies.rachie.is-a-geek.net 8.0-BETA4 FreeBSD 8.0-BETA4 #14 r196875M: Mon Sep 7 18:00:45 CEST 2009 m...@smoochies.rachie.is-a- geek.net:/usr/obj/usr/src/sys/HPDV9000 i386 openssl version (base): OpenSSL 0.9.8k 25 Mar 2009 How would one get this engine recognized and working and could this information be added to a pkg-message? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
V4bsd (Was: Re: skype 2.1 beta for linux)
On Thursday 03 September 2009 10:54:46 Martin Wilke wrote: Also that's not a problem from Skype, FreeBSD need a v4l(v4bsd)... Without getting into the nitty gritty of USB/PCI, what does a camera really do? Power on/off and send a stream of pictures in format X? I've never understood why it is so complex, that v4l needs a second release to get to a somewhat acceptable API. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: libical config error Cannot find Python.h
On Wednesday 26 August 2009 10:02:50 David Southwell wrote: Thanks Greg -- as usual your are right on the button. I have done as you suggested and disabled the GNU Pth which I would have prefered to have but can get round for a while. Just curious, but why do you prefer a userland threads wrapper over 1:1 kernel threads when the application doesn't require it? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: boost-python-libs and associated compile errors
On Wednesday 26 August 2009 16:07:56 David Southwell wrote: I have just completed # portupgrade -fRra following a system upgrade from freebsd 7.2 p2 to p3 after a few minor hiccuups and recompiling ssome of the ports I am left with four failing ports. As at least three of them seem to share some common features. If anyone would be willing to help me out here it would be most appreciated. The failure list is: ! science/openbabel (openbabel-2.2.1) (unknown build error) * misc/kdeedu4 (kdeedu-4.2.4) ! graphics/blender (blender-2.49a_1)(unknown build error) ! deskutils/kdeplasma-addons (kdeplasma-addons-4.2.4_1) (missing header) The errors reports are shown below in the same order. The common features are: problems with compiling boost-python-libs threading issues ## ! science/openbabel (openbabel-2.2.1) (unknown build error) ## In file included from /usr/include/c++/4.2/bits/gthr.h:114, from /usr/include/c++/4.2/bits/c++io.h:43, from /usr/include/c++/4.2/iosfwd:46, from /usr/include/c++/4.2/ios:43, from /usr/include/c++/4.2/ostream:45, from /usr/include/c++/4.2/iterator:70, from ./boost/iterator.hpp:17, from ./boost/operators.hpp:81, from ./boost/python/type_id.hpp:11, from ./boost/python/converter/registrations.hpp:10, from libs/python/src/object/function_doc_signature.cpp:6: /usr/include/c++/4.2/bits/gthr-default.h: In function 'int __gthread_active_p()': /usr/include/c++/4.2/bits/gthr-default.h:174: error: conversion from 'int' to non-scalar type 'pthread_once' requested ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-4.2.1/release/link- static/threading-multi/object/function_doc_signature.o... ...skipped pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multilibboost_python.a(clean) for lack of pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multinumeric.o... ...skipped pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multilibboost_python.a for lack of pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multinumeric.o... ...skipped pstage/liblibboost_python.a for lack of pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multilibboost_python.a... ...failed updating 54 targets... ...skipped 5 targets... ...updated 17 targets... *** Error code 1 Stop in /usr/ports/devel/boost-python-libs. *** Error code 1 Stop in /usr/ports/devel/boost-python-libs. *** Error code 1 Stop in /usr/ports/science/openbabel. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20090826-26960-1q590yk-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=openbabel-2.2.1 UPGRADE_PORT_VER=2.2.1 make ** Fix the problem and try again. ## * misc/kdeedu4 (kdeedu-4.2.4) ## In file included from /usr/include/c++/4.2/bits/gthr-default.h:43, from /usr/include/c++/4.2/bits/gthr.h:114, from /usr/include/c++/4.2/bits/c++io.h:43, from /usr/include/c++/4.2/iosfwd:46, from /usr/include/c++/4.2/ios:43, from /usr/include/c++/4.2/ostream:45, from /usr/include/c++/4.2/iterator:70, from ./boost/iterator.hpp:17, from ./boost/operators.hpp:81, from ./boost/python/type_id.hpp:11, from ./boost/python/converter/registrations.hpp:10, from libs/python/src/object/function_doc_signature.cpp:6: /usr/local/include/python2.6/pthread.h:285: error: conflicting declaration 'typedef struct pthread_st* pthread_t' ^^ David, I really think that your previous escapade with pth+python has screwed up boost-python. Did you recompile boost after removing pth from python? Because, pth/pthread.h: 282 /* 283* Primitive system data type definitions required by P1003.1c 284*/ 285 typedef struct pthread_st *pthread_t; ^^ -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Dropping maintainership for multimedia/handbrake
Hi, On Wednesday 26 August 2009 19:41:03 Jonathan wrote: I was hoping to fix the handbrake port and get it working properly over the summer but it didn't happen and now I'm in school full time. I don't have time to work on the port anymore and I don't want people to not try and update it because someone else is already maintaining it. If someone wants to take over this port let the list know and a ports committer will likely go ahead and assign it to you. Is this one of the problems you refer to? kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit region Followed by: kernel: (cd0:ata1:0:0:0): Retries Exhausted kernel: ata1: FAILURE - non aligned DMA transfer attempted kernel: unknown: setting up DMA failed handbrake becomes unkillable, machine can only be rebooted by power cycle. I'm interested in this port cause I'm looking for a solid alternative for the fragile multimedia/transcode. If this is one of the problems you're seeing and not something local to my test machine, I'll see what I can do and follow up through PR's. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: boost-python-libs and associated compile errors
On Thursday 03 September 2009 17:48:36 David Southwell wrote: On Wednesday 26 August 2009 16:07:56 David Southwell wrote: I have just completed # portupgrade -fRra following a system upgrade from freebsd 7.2 p2 to p3 after a few minor hiccuups and recompiling ssome of the ports I am left with four failing ports. As at least three of them seem to share some common features. If anyone would be willing to help me out here it would be most appreciated. The failure list is: ! science/openbabel (openbabel-2.2.1) (unknown build error) * misc/kdeedu4 (kdeedu-4.2.4) ! graphics/blender (blender-2.49a_1)(unknown build error) ! deskutils/kdeplasma-addons (kdeplasma-addons-4.2.4_1) (missing header) The errors reports are shown below in the same order. The common features are: problems with compiling boost-python-libs threading issues ## ! science/openbabel (openbabel-2.2.1) (unknown build error) ## In file included from /usr/include/c++/4.2/bits/gthr.h:114, from /usr/include/c++/4.2/bits/c++io.h:43, from /usr/include/c++/4.2/iosfwd:46, from /usr/include/c++/4.2/ios:43, from /usr/include/c++/4.2/ostream:45, from /usr/include/c++/4.2/iterator:70, from ./boost/iterator.hpp:17, from ./boost/operators.hpp:81, from ./boost/python/type_id.hpp:11, from ./boost/python/converter/registrations.hpp:10, from libs/python/src/object/function_doc_signature.cpp:6: /usr/include/c++/4.2/bits/gthr-default.h: In function 'int __gthread_active_p()': /usr/include/c++/4.2/bits/gthr-default.h:174: error: conversion from 'int' to non-scalar type 'pthread_once' requested ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-4.2.1/release/link- static/threading-multi/object/function_doc_signature.o... ...skipped pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multilibboost_python.a(clean) for lack of pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multinumeric.o... ...skipped pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multilibboost_python.a for lack of pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multinumeric.o... ...skipped pstage/liblibboost_python.a for lack of pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading- multilibboost_python.a... ...failed updating 54 targets... ...skipped 5 targets... ...updated 17 targets... *** Error code 1 Stop in /usr/ports/devel/boost-python-libs. *** Error code 1 Stop in /usr/ports/devel/boost-python-libs. *** Error code 1 Stop in /usr/ports/science/openbabel. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20090826-26960-1q590yk-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=openbabel-2.2.1 UPGRADE_PORT_VER=2.2.1 make ** Fix the problem and try again. ## * misc/kdeedu4 (kdeedu-4.2.4) ## In file included from /usr/include/c++/4.2/bits/gthr-default.h:43, from /usr/include/c++/4.2/bits/gthr.h:114, from /usr/include/c++/4.2/bits/c++io.h:43, from /usr/include/c++/4.2/iosfwd:46, from /usr/include/c++/4.2/ios:43, from /usr/include/c++/4.2/ostream:45, from /usr/include/c++/4.2/iterator:70, from ./boost/iterator.hpp:17, from ./boost/operators.hpp:81, from ./boost/python/type_id.hpp:11, from ./boost/python/converter/registrations.hpp:10, from libs/python/src/object/function_doc_signature.cpp:6: /usr/local/include/python2.6/pthread.h:285: error: conflicting declaration 'typedef struct pthread_st* pthread_t' ^^ David, I really think that your previous escapade with pth+python has screwed up boost-python. Did you recompile boost after removing pth from python? Because, pth/pthread.h: 282 /* 283* Primitive system data type definitions required by P1003.1c 284*/ 285 typedef struct pthread_st *pthread_t; ^^ After the last escapade I did a complete system rebuild and a total rebuild of all ports including python. But let us assume the worst. How would you suggest I do a complete rebuild of the relevant dependencies? I have already tried portupgrade -rRfa but still have the problem. I would pkg_delete pth-\*, then portmaster -rf /usr/ports/lang/python26, just in case pth is picked up automagically. Because this python2.6/pthread.h really shows pth constructs, rather then FreeBSD native threads. I would not use portupgrade, because I'm
Re: portmaster is not always recursive
On Sunday 30 August 2009 19:07:24 Doug Barton wrote:
Ok, I found the problem, but the bad news is that I don't know what the
solution is going to be. I've cc'ed ale since what I'm seeing is weird
behavior by the php5-mcrypt slave port.
What portmaster does by default when looking for dependencies is to run
'make build-depends-list run-depends-list | sort -u' to get the list of
things to check. I used to just do all-depends-list by default but users
complained that it was creating problems by recursing so far down the
tree.
What I'm seeing in security/php5-mcrypt is that the union of
{build|run}-depends-list is different if I run it in the slave port than
if I run it in lang/php5 (after enabling the OPTION for apache):
In the slave port:
/usr/ports/devel/autoconf262
/usr/ports/devel/libltdl22
/usr/ports/lang/php5
/usr/ports/security/libmcrypt
In lang/php5:
/usr/ports/devel/autoconf262
/usr/ports/devel/pkg-config
/usr/ports/textproc/libxml2
/usr/ports/www/apache22
That's why portmaster is not picking up the dependency on apache when
updating php5-mcrypt.
Why should it matter? I didn't think portmaster stopped searching if a first
level dep does not need upgrading. The reason for not using all-depends-list
is that it duplicates efforts. F.e. all-depends-list on x11/xorg recurses down
to everything and then asking all-depends-list for x11/xorg-apps will have
been done already by x11/xorg, but make(1) will still recurse the list and you
can't filter it till you see it.
But when using {build|run}-depends-list, lang/php5 is seen from security/php5-
mcrypt, as such, portmaster should drill down to {build|run}-depends-list of
lang/php5 until ending at leaf nodes. In principle this will end up to be an
all-depends-list, but with faster performance.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Dropping maintainership for multimedia/handbrake
On Thursday 03 September 2009 17:24:46 Mel Flynn wrote: Hi, On Wednesday 26 August 2009 19:41:03 Jonathan wrote: I was hoping to fix the handbrake port and get it working properly over the summer but it didn't happen and now I'm in school full time. I don't have time to work on the port anymore and I don't want people to not try and update it because someone else is already maintaining it. If someone wants to take over this port let the list know and a ports committer will likely go ahead and assign it to you. Is this one of the problems you refer to? kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit region Followed by: kernel: (cd0:ata1:0:0:0): Retries Exhausted kernel: ata1: FAILURE - non aligned DMA transfer attempted kernel: unknown: setting up DMA failed K, this is something with FreeBSD and ata/dma, mplayer does the same. Until I find a DVD player that works, can't evaluate this port :/. Doesn't help to be with a US DVD player in Europe. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Dovecot Sieve port switched from CMU Sieve to Dovecot
On Saturday 29 August 2009 20:11:22 Wesley Shields wrote:
On Fri, Aug 28, 2009 at 03:19:37PM -0400, Yarema wrote:
I was previously overruled by a committer when I filed a PR to default
ManageSieve to ON. IIRC, POLA was sited as the reason. I'm still of
the opinion that the ManageSieve patch to the main dovecot port should
default to ON for the following reasons:
- with the ManageSieve patch built into the package it becomes possible
for users of binary packages to just install the dovecot-sieve and
dovecot-managesieve ports and have them work. As it stands now anyone
who wants to use ManageSieve has to build the dovecot port from source.
So it doesn't even make sense to have a binary package of
dovecot-managesieve unless the ManageSieve patch is built into the
dovecot package by default as well.
- the ManageSieve patch does not add much bulk to the package. Those
who do not use ManageSieve can simply ignore it or if they build from
source can disable it. Either way from the perspective of those who do
not use ManageSieve nothing really changes (thus POLA is not violated).
- and finally there would be fewer broken PRs filed without the distinfo
for the ManageSieve patch included.
In my opinion it seems not having the binary dovecot-managesieve package
just work is more of a POLA violation than having an extra
README.managesieve and related dovecot.conf sections installed by
default in the main dovecot port.
I have no problems marking that option as on by default since it will
mean that the managesieve port can be usefully packaged, while not
bloating the port at all.
To further this issue in the right direction, I've investigated the bloat,
using a slave port:
PORTNAME= dovecot
PKGNAMESUFFIX= -withsieve
CATEGORIES= mail ipv6
MASTERDIR= ${.CURDIR}/../../mail/dovecot
CONFLICTS= dovecot-1*
.include ${MASTERDIR}/Makefile
.if defined(WITHOUT_MANAGESIEVE)
.undef WITHOUT_MANAGESIEVE
.endif
WITH_MANAGESIEVE= yes
Result:
-rw-r--r-- 1 root wheel 2626479 Sep 2 05:05 dovecot-1.2.4.tbz
-rw-r--r-- 1 root wheel 2626719 Sep 2 05:04 dovecot-withsieve-1.2.4.tbz
I think more bytes have been wasted on discussing this, then it adds to the
port. Also, I've left it off, thinking I'll add this later or just add the
package, because the OPTION framework does not really have enough room to
specify You have to tick this option to ON if you want to be able to add
dovecot-managesieve port later, so yes, POLA was violated by not having it on
by default and the description should probably read something like Set to off
if you never want managesieve support.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: omnetpp-3.3_3
On Tuesday 11 August 2009 19:13:44 Gabriele Cecchetti wrote:
Probably there is an error in the Makefile of omnetpp:
When I do portupgrade at the install phase the following output is shown:
--- Installing the new version via the port
=== Installing for omnetpp-3.3_3
=== omnetpp-3.3_3 depends on executable: convert - found
=== omnetpp-3.3_3 depends on executable: dot - found
=== omnetpp-3.3_3 depends on executable: doxygen - found
=== omnetpp-3.3_3 depends on executable: giftrans - found
=== omnetpp-3.3_3 depends on file: /usr/local/bin/perl5.10.0 - found
=== omnetpp-3.3_3 depends on executable: pkg-config - found
=== omnetpp-3.3_3 depends on shared library: BLT24 - found
=== omnetpp-3.3_3 depends on shared library: tcl84 - found
=== omnetpp-3.3_3 depends on shared library: tk84 - found
=== omnetpp-3.3_3 depends on shared library: glib-12.3 - found
=== omnetpp-3.3_3 depends on shared library: xml.5 - found
=== omnetpp-3.3_3 depends on shared library: xml2.5 - found
=== omnetpp-3.3_3 depends on shared library: xslt.2 - found
cp: pkg-plist: No such file or directory
...
Having a working directory is legal and this is set putting the
following variable in /etc/make.conf
WRKDIRPREFIX= /somedir
FWIW, reproduced and ${.CURDIR} should be used (`pwd` at pre-install is
${.OBJDIR}).
--
Mel
Index: science/omnetpp/Makefile
===
RCS file: /home/ncvs/ports/science/omnetpp/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- science/omnetpp/Makefile31 Jul 2009 13:55:36 - 1.12
+++ science/omnetpp/Makefile12 Aug 2009 06:21:49 -
@@ -82,7 +82,7 @@
@${ECHO} WISH=wish${TK_VER} ${CONFIGUREUSER}
pre-install:
- @${CP} pkg-plist ${PLIST}
+ @${CP} ${.CURDIR}/pkg-plist ${PLIST}
@(cd ${WRKSRC}; \
${FIND} -s include -type f | ${SED}
s,^include,${INCLDIR_REL}, ${PLIST}; \
${FIND} -s -d include -type d | ${SED} s,^include,@dirrm
${INCLDIR_REL}, ${PLIST}; \
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: apr-gdbm-db42 upgrade conflicting with libtool
On Tuesday 04 August 2009 08:10:53 N.J. Mann wrote:
In message 20090803155055.ga31...@titania.njm.me.uk,
N.J. Mann (n...@njm.me.uk) wrote:
In message 20090803125519.ga60...@twisted.net,
Troy (t...@twisted.net) wrote:
I was trying to upgrade apr-gdbm-db42-1.3.6.1.3.8 to 1.3.7.1.3.8 and
ran into the following error. My libtool was just upgraded to
libtool-2.2.6a so there may be a conflict there. Anyone have ideas?
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for library containing strerror... none required
checking whether system uses EBCDIC... no
performing libtool configuration...
./configure: 9753: Syntax error: word unexpected (expecting ))
*** Error code 2
Stop in /usr/ports/devel/apr.
*** Error code 1
Stop in /usr/ports/devel/apr.
I am also having problems updating devel/apr. In my case it gets past
the configure stage and fails during the compile stage:
%
=== Building for apr-gdbm-db43-1.3.7.1.3.8
cd /usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7; /usr/bin/env
TMPDIR=/home/njm/tmp TMPDIR=/home/njm/tmp SHELL=/bin/sh NO_LINT=YES
ACLOCAL=/usr/local/bin/aclocal-1.9 AUTOMAKE=/usr/local/bin/automake-1.9
AUTOMAKE_VERSION=19 AUTOCONF=/usr/local/bin/autoconf-2.62
AUTOHEADER=/usr/local/bin/autoheader-2.62
AUTOIFNAMES=/usr/local/bin/ifnames-2.62
AUTOM4TE=/usr/local/bin/autom4te-2.62
AUTORECONF=/usr/local/bin/autoreconf-2.62
AUTOSCAN=/usr/local/bin/autoscan-2.62
AUTOUPDATE=/usr/local/bin/autoupdate-2.62 AUTOCONF_VERSION=262
LIBTOOL=/usr/local/bin/libtool LIBTOOLIZE=/usr/local/bin/libtoolize
LIBTOOL_M4=/usr/local/share/aclocal/libtool.m4 PREFIX=/usr/local
LOCALBASE=/usr/local X11BASE=/usr/local MOTIFLIB=-L/usr/local/lib -lXm
-lXp LIBDIR=/usr/lib CC=cc CFLAGS=-O2 -fno-strict-aliasing -pipe
CXX=c++ CXXFLAGS=-O2 -fno-strict-aliasing -pipe
MANPREFIX=/usr/local BSD_INSTALL_PROGRAM=install -s -m 555
BSD_INSTALL_SCRIPT=install -m 555 BSD_INSTALL_DATA=install -m
444 BSD_INSTALL_ MAN=install -m 444 /usr/bin/make
/bin/sh /libtool --silent --mode=compile cc -O2 -fno-strict-aliasing
-pipe -DHAVE_CONFIG_H-I./include
-I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix
-I./include/arch/unix
-I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include/arch/unix
-I/usr/ports.workdir/usr/ports/devel/apr/work/apr-1.3.7/include -o
passwd/apr_getpass.lo -c passwd/apr_getpass.c touch
passwd/apr_getpass.lo
^
This is the why it fails. In the relevant makefile this is actually:
./build/apr_rules.mk:38:LIBTOOL=$(SHELL) $(top_builddir)/libtool
but top_buildir is not defined anywhere in the makefiles. If I set it
then everything works. If I change the line above to use top_blddir
instead of top_builddir it works.
So, why isn't it defined? I looked through the config files - I know
nothing about autoconf, automake, c., and found:
./config.log:17410:LIBTOOL='$(SHELL) $(top_builddir)/libtool'
./config.log:17611:top_builddir='/usr/ports.workdir/usr/ports/devel/apr/wor
k/apr-1.3.7'
Just got bitten by this too, amd64, 6.x in a jail, clean environment. I traced
it to building as normal user, root works. The tell tale is this:
buildconf: Using libtool.m4 at /usr/local/share/aclocal/libtool.m4.
./buildconf: cannot create build/libtool.m4: Permission denied
As a result, configure works with the provided libtool.m4 and things go
downhill from there.
The provided libtool.m4 is installed by libtoolize with 444 permissions. Thus:
cat $ltfile | sed -e 's/LIBTOOL=\(.*\)top_build/LIBTOOL=\1apr_build/' \
build/libtool.m4
fails for a normal user. The patch below sig fixes the issue.
--
Mel
--- /dev/null 2009-08-12 08:33:00.0 -0800
+++ devel/apr/files/patch-buildconf 2009-08-12 08:32:46.0 -0800
@@ -0,0 +1,11 @@
+--- apr-1.3.8/buildconf.orig2009-08-12 08:28:47.0 -0800
apr-1.3.8/buildconf 2009-08-12 08:31:45.0 -0800
+@@ -71,6 +71,7 @@
+
+ echo buildconf: Using libtool.m4 at ${ltfile}.
+
++rm -f build/libtool.m4
+ cat $ltfile | sed -e 's/LIBTOOL=\(.*\)top_build/LIBTOOL=\1apr_build/'
build/libtool.m4
+
+ # libtool.m4 from 1.6 requires ltsugar.m4
+
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Multiple instances of Mailman on FreeBSD
On Wednesday 12 August 2009 11:40:47 Bill Moran wrote: In response to Jeffrey Goldberg jeff...@goldmark.org: I'm posting this to both the mailman-users list and the freebsd-ports list. I realize that not all follow-up will make it to both lists. I would like to set up multiple instances of Mailman on a FreeBSD 7- STABLE system with using Postfix. Looking at the ports Makefile, it appears that if I set MM_DIR=mailman/vhosts/domain-for-this-instance everything should work file (plus add FORCE_PACKAGE_REGISTER allow this second instance to be installed.) Were it me, I'd add jails to the system. Then you can install a separate copy of mailman in each jail. This will keep them happily independent of each other. That's obviously not the only way to get what you want, just my suggestion. And mine. FORCE_PKG_REGISTER abuse will hurt you sooner or later. If you must, then set PKG_DBDIR, PORT_DBDIR and PREFIX correctly. But things get much easier if you use seperate jails and a postfix in mailhub mode on the main IP if you have only one incoming IP. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports completely and permanently hosed
On Thursday 06 August 2009 23:56:32 Lars Eighner wrote: On Thu, 6 Aug 2009, Mel Flynn wrote: On Thursday 06 August 2009 19:29:24 Lars Eighner wrote: On Thu, 6 Aug 2009, Mel Flynn wrote: On Thursday 06 August 2009 17:38:40 Lars Eighner wrote: It's hard to resist the sales pitch (really, USB will work again on 8.0, we promise! [but we are going to trash your modem driver]) --- sooner or later one has to wise up. If you actually know how responsive in particular hps@ is at people posting USB problems, you may want to vent your frustration at the wall and instead file a PR Done, months ago with all the core dump stuff. Still open. Umass still crashes the system if I plug the camera or the mp3 player in. (I don't mean just doesn't work in some vague way; I mean really crashes the system.) PR number? And I'm gonna guess the camera is a Kodak. 133390 Well, unfortunately that dump is useless. It doesn't contain any ref to anything inside the kernel that triggers it, so from that info, nothing can be fixed. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports completely and permanently hosed
On Thursday 06 August 2009 17:38:40 Lars Eighner wrote: It's hard to resist the sales pitch (really, USB will work again on 8.0, we promise! [but we are going to trash your modem driver]) --- sooner or later one has to wise up. If you actually know how responsive in particular hps@ is at people posting USB problems, you may want to vent your frustration at the wall and instead file a PR or post your problem in curr...@. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Ports completely and permanently hosed
On Thursday 06 August 2009 19:29:24 Lars Eighner wrote: On Thu, 6 Aug 2009, Mel Flynn wrote: On Thursday 06 August 2009 17:38:40 Lars Eighner wrote: It's hard to resist the sales pitch (really, USB will work again on 8.0, we promise! [but we are going to trash your modem driver]) --- sooner or later one has to wise up. If you actually know how responsive in particular hps@ is at people posting USB problems, you may want to vent your frustration at the wall and instead file a PR Done, months ago with all the core dump stuff. Still open. Umass still crashes the system if I plug the camera or the mp3 player in. (I don't mean just doesn't work in some vague way; I mean really crashes the system.) PR number? And I'm gonna guess the camera is a Kodak. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: x11-toolkits/xview (actually contool)
On Wednesday 05 August 2009 20:08:55 Doug Barton wrote:
Ok, so now I'm up to the point where starting contool give me this:
contool
Assertion failed: (ret != inval_id), function _XAllocID, file
xcb_io.c, line 378.
Abort trap: 6 (core dumped)
You get a better a log if you install contool unstripped [1]:
(gdb) bt
#0 0x28463eb7 in kill () from /lib/libc.so.7
#1 0x28463e16 in raise () from /lib/libc.so.7
#2 0x28462a1a in abort () from /lib/libc.so.7
#3 0x28448ee6 in __assert () from /lib/libc.so.7
#4 0x28284d46 in _XAllocID (dpy=0x28524600) at xcb_io.c:378
#5 0x2818e11c in server_init (parent=0, server_public=676345056,
avlist=0xbfbfd944)
at server.c:746
#6 0x281f33b9 in xv_create_avlist (parent=0, pkg=0x0, avlist=0xbfbfd944) at
xv.c:391
#7 0x281f315b in xv_create (parent=0, pkg=0x28210040) at xv.c:307
#8 0x281f520a in xv_init (attr1=1241974786) at xv_init.c:308
#9 0x0804b801 in main (argc=1, argv=0xbfbfe6e4) at contool.c:777
Which points to xv_init from xview as the culprit. Since that is
the most basic function of xview, it might be best to mark it as
BROKEN for the time being and complain with Xorg about yet another
case of backwards compatibility failing. Of course I meant to say
to patch it or remove the port and it's dependants.
[1] Patch:
Index: Makefile
===
RCS file: /home/ncvs/ports/sysutils/contool/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- Makefile9 Jun 2009 15:33:17 - 1.20
+++ Makefile6 Aug 2009 05:20:11 -
@@ -24,8 +24,12 @@
MAN1= contool.1
+
pre-install:
@${MKDIR} ${PREFIX}/lib/help
+.if defined(WITH_DEBUG)
+ -${SED} -i.bak -e 's/INSTPGMFLAGS = -s/INSTPGMFLAGS =/'
${WRKSRC}/Makefile
+.endif
post-install:
@${CAT} ${PKGMESSAGE}
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ports/*/jpeg Thanks a lot guys
On Sunday 02 August 2009 06:52:03 Matthew Seaman wrote:
Similarly, programs that declare 'USE_MYSQL=NN' will have a LIB_DEPENDS
on libmysqlclient.so.X added to their dependency mix even if they contain
no compiled ELF binaries [See net-mgmt/cacti databases/phpmyadmin]
That's because you use USE_MYSQL when you really want to include
bsd.databases.mk and throw and error on specific mysql versions.
This could be addressed as below and for similar Mk/* files, should
it be needed:
Index: Mk/bsd.database.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.database.mk,v
retrieving revision 1.37
diff -u -r1.37 bsd.database.mk
--- Mk/bsd.database.mk 21 Jul 2009 08:02:18 - 1.37
+++ Mk/bsd.database.mk 4 Aug 2009 06:59:12 -
@@ -158,7 +158,7 @@
.if (${USE_MYSQL} == embedded)
BUILD_DEPENDS+=
${LOCALBASE}/lib/mysql/libmysqld.a:${PORTSDIR}/databases/mysql${MYSQL_VER}-server
.endif
-.else
+.elif (${USE_MYSQL} != vcheck)
LIB_DEPENDS+=
mysqlclient.${MYSQL${MYSQL_VER}_LIBVER}:${PORTSDIR}/databases/mysql${MYSQL_VER}-client
.endif
.else
Index: databases/phpmyadmin/Makefile
===
RCS file: /home/ncvs/ports/databases/phpmyadmin/Makefile,v
retrieving revision 1.108
diff -u -r1.108 Makefile
--- databases/phpmyadmin/Makefile 30 Jun 2009 19:10:53 - 1.108
+++ databases/phpmyadmin/Makefile 4 Aug 2009 07:00:04 -
@@ -14,7 +14,7 @@
MAINTAINER=m.sea...@infracaninophile.co.uk
COMMENT= A set of PHP-scripts to manage MySQL over the web
-USE_MYSQL= yes
+USE_MYSQL= vcheck
IGNORE_WITH_PHP= 4
IGNORE_WITH_MYSQL= 323 40 41
USE_BZIP2= yes
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compile error mail/alpine
On Tuesday 04 August 2009 01:15:04 David Southwell wrote:
latest error messages:
cc -std=gnu99 -g -D_THREAD_SAFE -O2 -fno-strict-aliasing -pipe -
DLDAP_DEPRECATED -rpath=/usr/local/lib -o alpine addrbook.o adrbkcmd.o
after.o alpine.o arg.o busy.o colorconf.o confscroll.o context.o dispfilt.o
flagmaint.o folder.o help.o imap.o init.o kblock.o keymenu.o ldapconf.o
listsel.o mailcmd.o mailindx.o mailpart.o mailview.o newuser.o pattern.o
pipe.o print.o radio.o remote.o reply.o roleconf.o send.o setup.o signal.o
status.o takeaddr.o titlebar.o smime.o date.o -lcrypt -lpam -L/usr/lib -
L/usr/local/openssl/lib -L/usr/local/lib ../pico/libpico.a
../pico/osdep/libpicoosd.a ../pith/libpith.a ../pith/osdep/libpithosd.a
../pith/charconv/libpithcc.a osdep/libpineosd.a ../c-client/c-client.a
/usr/local/lib/libldap.so -lcrypto -ltinfo /usr/local/lib/liblber.so -lssl
- Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib
../c-client/c-client.a(osdep.o)(.text+0x68a1): In function
`ssl_onceonlyinit':
/usr/ports/mail/alpine/work/alpine-2.00/imap/c-client/osdep.c:335: warning:
warning: tmpnam() possibly used unsafely; consider using mkstemp()
after.o(.text+0x36d): In function `start_after':
/usr/ports/mail/alpine/work/alpine-2.00/alpine/after.c:77: undefined
reference to `pthread_create'
David, given that all your errors posted in the last 24 hours point to a
messed up pth/pthread installation I suggest you look into that before trying
to build more ports.
The shell archive attached should compile and run cleanly, by typing make
run once extracted. If it does not, then even the base compiler/linker cannot
find pthread, which is not a good thing, but at least you know where to start
(reinstall world and possibly kernel).
--
Mel
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# threadtest/BSDmakefile
# threadtest/thrtest.c
#
echo x - threadtest/BSDmakefile
sed 's/^X//' threadtest/BSDmakefile 'd68d3d39019a946b87b33afe0474b0cc'
XPROG=thrtest
XNO_MAN=yes
XLDFLAGS+=-pthread
X
Xrun: ${PROG}
X ${.OBJDIR}/${PROG}
X
X.include bsd.prog.mk
d68d3d39019a946b87b33afe0474b0cc
echo x - threadtest/thrtest.c
sed 's/^X//' threadtest/thrtest.c '22cb4804387108296f45df39552f86e9'
X#include pthread.h
X#include stdlib.h
X#include stdio.h
X#include err.h
X
Xvoid *thr_main(void *priv);
X
Xint main(int argc, char **argv)
X{
X pthread_t tid[5];
X int i, res;
X
X printf(main\n);
X
X for(i=0; i5; i++)
X {
X res = pthread_create(tid[i], NULL, thr_main, NULL);
X if( res )
X errc(EXIT_FAILURE, res, pthread_create);
X }
X for(i=0; i5; i++)
X {
X int *ex;
X
X ex = malloc(sizeof(int));
X if( !ex )
X err(EXIT_FAILURE, malloc: %zu bytes, sizeof(int));
X res = pthread_join(tid[i], (void*)ex);
X if( res )
X errc(EXIT_FAILURE, res, pthread_join);
X }
X
X return (0);
X}
X
Xvoid *thr_main(void *priv)
X{
X printf(Thread tid %u\n, (unsigned int)pthread_self());
X
X return (priv);
X}
22cb4804387108296f45df39552f86e9
exit
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: kdeedu-4.2.4 to 4.2.4_1 facile.cmxa compile error
On Sunday 02 August 2009 12:39:55 Martin Wilke wrote: On Sunday 02 August 2009 05:06:19 Troy wrote: [ 12%] Generating solver.o File _none_, line 1, characters 0-1: Error: Files /usr/local/lib/ocaml/facile/facile.cmxa and /usr/local/lib/ocaml/stdlib.cmxa make inconsistent assumptions over implementation Printf *** Error code 2 try to rebuild ocaml, after that rerun kdeedu4 For the archives: it's upgrading ocaml that creates the error and rebuilding facile that fixes it. Long story is available here: http://mail.kde.org/pipermail/kde-freebsd/2009-July/005914.html -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: What does py25 mean?
On Tuesday 04 August 2009 17:28:59 matt donovan wrote: On Tue, Aug 4, 2009 at 4:48 PM, Lars Eighner portsu...@larseighner.comwrote: What does py25 mean? I can't seem to upgrade about 40 ports (the old versions of which now seem to be broken) evidently because the build of py25-gtk-2.13.1 fails with the message py25-cairo-1.8.6 needs Python 2.6 at least. But you specified 2.5. Well, of *I* did not specify 2.5. yes it means python 2.5 most likely for cairo the py25 was not bumped to py26 No, the package name (or actually the PKGNAMEPREFIX) is dynamically created from the *detected* python version. Also graphics/py-cairo has: USE_PYTHON= 2.6+ Which signals that it cannot work with python 2.5. If you install lang/python26, it should work, tho I haven't checked. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
