Re: Why is security/pinentry not a dependency of security/gnupg

2008-06-23 Thread Johan van Selst
Tobias Rehbein wrote:
 Or is there some way to use gpg without pinentry?

You could use security/gnupg1 instead (which is still developed, just
a seperate branch), which doens't require pinentry.


Ciao,
Johan


pgp2IwUtXegLB.pgp
Description: PGP signature


Re: INDEX build optimizations - please review

2008-06-23 Thread Doug Barton

Kris Kennaway wrote:

Unfortunately it doesn't DTRT with files terminated with DOS-style CRLF 
(e.g. devel/p5-Tie-Restore, others).


First, I certainly would not have any problem with a policy that says 
files in ports shouldn't have CRLF line endings. Second, I am sure we 
could probably do something about that if we needed to. And Third, I 
fixed p5-Tie-Restore, along with a whole bunch of others, thanks to Alex 
Kozlov pointing me in the right direction. :)


I really don't care if you use this solution or not, although I would be 
interested in benchmark results if you chose to give it a try.


Doug

--

This .signature sanitized for your protection
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Doug Barton

Alex Dupre wrote:

Peter Jeremy wrote:

Firstly, I have jdk-1.5.0.14p8,1 installed and this needs updating.
portmaster has decided that doing so requires java/diablo-jdk15 to be
installed - which is wrong because I already have a suitable jdk
installed.


You are right, but the port has the following line:

BUILD_DEPENDS+= ${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15

So, even if it correctly find the installed
/usr/local/jdk1.5.0/bin/javac binary, it adds the diablo dependency.
Portmaster checks all the dependencies, even if the binary file exists,
and so try to install the diablo jdk. All java ports should be fixed
regarding this issue.


Portmaster uses CONFLICTS to avoid this issue. This isn't the first time 
I've heard this complaint about the java ports. I'm wondering if glewis 
could shed some light on why they don't have proper CONFLICTS set.


Meanwhile, the only other alternative is for portmaster to essentially 
adopt the same functionality as the ports infrastructure itself in order 
to handle these kinds of dependency issues. That's a step I'd really 
like to avoid since my goal has always been to make portmaster a sort of 
wrapper that ties together existing ports functionality rather than 
replacing it. And of course there is the obvious objection to doing this 
that it would make the script a lot more complicated.


For the most part, relying on CONFLICTS has worked well to solve this 
problem, I'm hoping it will continue to be a reliable solution.


Finally, I'm glad to hear that overall your experience has been 
favorable Peter. :)



Doug

--

This .signature sanitized for your protection
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Dominic Fandrey

Doug Barton wrote:

Alex Dupre wrote:

Peter Jeremy wrote:

Firstly, I have jdk-1.5.0.14p8,1 installed and this needs updating.
portmaster has decided that doing so requires java/diablo-jdk15 to be
installed - which is wrong because I already have a suitable jdk
installed.


You are right, but the port has the following line:

BUILD_DEPENDS+= 
${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15


So, even if it correctly find the installed
/usr/local/jdk1.5.0/bin/javac binary, it adds the diablo dependency.
Portmaster checks all the dependencies, even if the binary file exists,
and so try to install the diablo jdk. All java ports should be fixed
regarding this issue.


Portmaster uses CONFLICTS to avoid this issue. This isn't the first time 
I've heard this complaint about the java ports. I'm wondering if glewis 
could shed some light on why they don't have proper CONFLICTS set.


Because they don't conflict. /usr/local/bin/javac is a script that selects
one of the installed JAVA VMs, dependant on what is available, environment
settings and a make variable that can be changed in make.conf.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Doug Barton

Dominic Fandrey wrote:

Doug Barton wrote:


Portmaster uses CONFLICTS to avoid this issue. This isn't the first 
time I've heard this complaint about the java ports. I'm wondering if 
glewis could shed some light on why they don't have proper CONFLICTS set.


Because they don't conflict. /usr/local/bin/javac is a script that selects
one of the installed JAVA VMs, dependant on what is available, environment
settings and a make variable that can be changed in make.conf.


AFAICT, javac isn't relevant to the issue of whether the various jdk 
ports conflict with each other. It's just a convenient way to handle the 
dependency question within the ports framework.


Doug

--

This .signature sanitized for your protection
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Dominic Fandrey

Doug Barton wrote:

Dominic Fandrey wrote:

Doug Barton wrote:


Portmaster uses CONFLICTS to avoid this issue. This isn't the first 
time I've heard this complaint about the java ports. I'm wondering if 
glewis could shed some light on why they don't have proper CONFLICTS 
set.


Because they don't conflict. /usr/local/bin/javac is a script that 
selects
one of the installed JAVA VMs, dependant on what is available, 
environment

settings and a make variable that can be changed in make.conf.


AFAICT, javac isn't relevant to the issue of whether the various jdk 
ports conflict with each other. It's just a convenient way to handle the 
dependency question within the ports framework.


JDK Ports don't conflict. None of them. And because many Java developers
have several JDKs installed, noone will ever put a CONFLICT line into
JDK port.

The only way to resolve this is to detect weather a dependency is required
in the same way as a port does.

I suggest to check for the existence of the file and when the file is
from a different port, 'pkg_info -W' should be called and whatever turns
out to be the origin, should be entered as a dependency in /var/db/pkg.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Alex Dupre

Doug Barton ha scritto:

Portmaster uses CONFLICTS to avoid this issue.


I can't see how CONFLICTS could solve this issue: we can install all the 
JDKs together without problems (this is different from original bison 
problem). The issue here is that the jdk port directory is not a 
variable parameter, based on which javac binary is selected.


--
Alex Dupre
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Alexey Shuvaev
Hello!

On Mon, Jun 23, 2008 at 12:49:22AM -0700, Doug Barton wrote:
 Alex Dupre wrote:
 Doug Barton ha scritto:
 Portmaster uses CONFLICTS to avoid this issue.

 I can't see how CONFLICTS could solve this issue: we can install all 
 the JDKs together without problems

It seems I don't understand something here. Can someone explain why
jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
Why it is not possible to define it inside 'if !defined(BOOTSTRAPJDKDIR)'?
(See attached patch.)

Just curious,
Alexey.
--- Makefile.orig   2008-06-23 10:33:59.0 +0200
+++ Makefile2008-06-23 10:34:36.0 +0200
@@ -108,9 +108,8 @@
 # if no valid jdk found, set dependency
 .if !defined(BOOTSTRAPJDKDIR)
 BOOTSTRAPJDKDIR?=  ${LOCALBASE}/diablo-jdk1.5.0
-.endif
-
 BUILD_DEPENDS+=
${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/diablo-jdk15
+.endif
 
 .if defined(WITHOUT_WEB)
 MAKE_ENV+= DONT_BUILD_DEPLOY=YES
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Issues with portmaster

2008-06-23 Thread Alex Dupre

Alexey Shuvaev ha scritto:

It seems I don't understand something here. Can someone explain why
jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?


(nearly) every JDK port needs an already usable/installed JDK to 
bootstrap the compilation. This is the reason of the BUILD_DEPENDS on 
javac that you cannot remove. But the port providing the javac binary 
could not be the diablo-jdk.


--
Alex Dupre
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


bind95?

2008-06-23 Thread Dirk Estenfeld
Hello,

is it planned to add bind95 to the ports?

best regards,
Dirk
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Current unassigned ports problem reports

2008-06-23 Thread FreeBSD bugmaster
Current FreeBSD problem reports

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including\nexperimental 
development code and obsolete releases.\n
Bugs can be in one of several states:

o - open
A problem report has been submitted, no sanity checking performed.

a - analyzed
The problem is understood and a solution is being sought.

f - feedback
Further work requires additional information from the
 originator or the community - possibly confirmation of
 the effectiveness of a proposed solution.

p - patched
A patch has been committed, but some issues (MFC and / or
 confirmation from originator) are still open.

r - repocopy
The resolution of the problem report is dependent on
 a repocopy operation within the CVS repository which
 is awaiting completion.

s - suspended
The problem is not being worked on, due to lack of information
 or resources.  This is a prime candidate
 for somebody who is looking for a project to do.
 If the problem cannot be solved at all,
 it will be closed, rather than suspended.

c - closed
A problem report is closed when any changes have been integrated,
 documented, and tested -- or when fixing the problem is abandoned.

Critical problems

S Tracker  Resp.  Description

f ports/124901[patch] sysutils/fusefs-kmod dataloss on write shortly

1 problem total.

Serious problems

S Tracker  Resp.  Description

f ports/112921x11-wm/Beryl not loading focus and keybinding settings
s ports/113144print/ghostscript-gnu dumps core with several output d
f ports/116385net/vnc using vnc.so crashes Xorg 7.3 when remote comp
f ports/116586net/isc-dhcp3-server does not work when compiled with 
o ports/117128security/ipsec-tools racoon.sh fails with /var on mfs
o ports/118104[PATCH] multimedia/vlc - volume bar position almost in
f ports/118877audio/streamripper does not detect song title from str
f ports/122276Compiled audio/musicpd segfaults on FreeBSD 7.0
o ports/122381net-mgmt/collectd in FreeBSD 7.0 i386 and sparc64 segf
f ports/122416deskutils/kmatrix3d and deskutils/ksmoothdock don't in
o ports/122676multimedia/mplayer: can't access dvd with any applicat
o ports/122907[patch] sysutils/fusefs-kmod dataloss on write shortly
f ports/122973textproc/xerces-c2: installed files do not have o+r bi
f ports/123655mail/postfix - I can't build port postfix-2.5.1 with p
a ports/124154mail/milter-bogom cores out intermittently
f ports/124401security/sshguard dumps core
f ports/124437socket.connect can't work correct in lang/gdc
o ports/124441sysutils/wmmemfree doesn't report swap changes
s ports/124601science/gramps dumps core at initialization: never run
o ports/124776new port lang/plt-scheme (attached)
o ports/124864print/ghostscript-gpl fails to install if ESC/Page dri

21 problems total.

Non-critical problems

S Tracker  Resp.  Description

o ports/85513 Intel C++ compiler not 100% binary compatible with sys
o ports/108795ports/icc: Proposed update to icc port for intel compi
o ports/108856[mbone/sdr] make sdr usable again; patch appended
o ports/110144New port: math/Matlab7
o ports/110697New port: ports-mgmt/pkg_deps
o ports/112746[NEW PORT]: www/coldfusion: coldfusion7 Coldfusion 7.0
f ports/115304multimedia/gpac-mp4box cannot import files larger than
o ports/115336port multimedia/avifile on FreeBSD 7.0 not BROKEN with
o ports/116567[PATCH] net/vnc: patch x0vncserver to not give the sel
o ports/117521[new port] net/asterisk-res-bonjour Bonjour (Zeroconf)
o ports/117810multimedia/vlc-devel port could be compiled with lua m
o ports/117824CONFIGURE_LINE truncated to 2048 chars in [at least] m
f ports/118368New port: net/asterisk-agx AGX Extra Addons (including
o ports/119183[NEW PORT] net/freeradius-client: FreeRADIUS Client li
o ports/119556[PATCH] textproc/xerces-c2: Update to 2.8.0
f ports/119745www/linux-flashplugin7 - flashplayer does not work wit
o ports/120923www/squidguard does not work unless its UID/GID are mo
o ports/121050New port: sysutils/heartbeat2 Linux High-Availability 
o ports/121126New port: science/caret Computerized Anatomical Recons
f ports/121149www/tomcat55 - www/tomcat* choaks on ip6
o ports/121194   

Re: Issues with portmaster

2008-06-23 Thread Alexey Shuvaev
On Mon, Jun 23, 2008 at 10:57:41AM +0200, Alex Dupre wrote:
 Alexey Shuvaev ha scritto:
 It seems I don't understand something here. Can someone explain why
 jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?

 (nearly) every JDK port needs an already usable/installed JDK to  
 bootstrap the compilation. This is the reason of the BUILD_DEPENDS on  
 javac that you cannot remove. But the port providing the javac binary  
 ^
 could not be the diablo-jdk.

Mmmm... why not???
In a nutshell, from the user point of view the reason to set BUILD_DEPENDS is
to ensure that some port (java here) is installed prior to build.
However, if the port checks against installed java in a more complicated manner
than BUILD_DEPENDS mechanism can provide, I see no reason to set
BUILD_DEPENDS to something just for its own sake.
And from the build cluster point of view, the port will be built in a clean
environment, so port will not detect any installed java and will set
BUILD_DEPENDS *conditionally* (.if !defiend(BOOTSTRAPJDKDIR)).

I have a feeling that the way BUILD_DEPENDS is set now is overkill, and
one can put it under .if !defined(BOOTSTRAPJDKDIR) without any functional
change. Of course, the Right Way To Do This would be to set the whole
correct BUILD_DEPENDS line based on detected java. Maybe this is even not
so complicated. Or I miss something?

Just 0.02$,
Alexey.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread RW
On Mon, 23 Jun 2008 10:57:41 +0200
Alex Dupre [EMAIL PROTECTED] wrote:

 Alexey Shuvaev ha scritto:
  It seems I don't understand something here. Can someone explain why
  jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
 
 (nearly) every JDK port needs an already usable/installed JDK to 
 bootstrap the compilation. This is the reason of the BUILD_DEPENDS on 
 javac that you cannot remove. But the port providing the javac binary 
 could not be the diablo-jdk.

The thing is that, IIRC, it doesn't have to create a dependency at
all, unless the functionality is missing. It's not simply a case of it
creating a normally dependency in the sense of: install this port if
that file is not found. 

The makefile has logic to detect which java ports are installed, so it
doesn't build a second bootstap port, but it doesn't carry it through
to removing the dependency once bootstrapping is no longer required.

I reported this problem a long time ago after I spotted that
portmanager was reinstalling a linux java version. I thought the
maintainer was going to fix it. 
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread RW
On Mon, 23 Jun 2008 00:06:38 -0700
Doug Barton [EMAIL PROTECTED] wrote:

 Portmaster uses CONFLICTS to avoid this issue. This isn't the first
 time I've heard this complaint about the java ports. I'm wondering if
 glewis could shed some light on why they don't have proper CONFLICTS
 set.
 
 Meanwhile, the only other alternative is for portmaster to
 essentially adopt the same functionality as the ports infrastructure
 itself in order to handle these kinds of dependency issues. That's a
 step I'd really like to avoid since my goal has always been to make
 portmaster a sort of wrapper that ties together existing ports
 functionality rather than replacing it. And of course there is the
 obvious objection to doing this that it would make the script a lot
 more complicated.

In this case I think it's pure logic problem in the makefile.

More generally though I wonder if it would be possible to create a more
useful missing target, i.e. show which first-level dependencies
would actually be installed if the given port were rebuilt. That way
build tools would have enough information to determine which ports need
to be built without having to parse the makefiles. 

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


INDEX build failed for 6.x

2008-06-23 Thread Erwin Lansing
INDEX build failed with errors:
Generating INDEX-6 - please 
wait../a/erwin/tindex/ports/chinese/links/../../www/links/Makefile, line 75: 
warning: duplicate script for target pre-configure ignored
ireport-3.0.0_1: /a/erwin/tindex/ports/java/bsh non-existent -- dependency 
list incomplete
=== devel/ireport failed
*** Error code 1
*** Error code 1

Stop in /a/erwin/tindex/ports.
*** Error code 1

Stop in /a/erwin/tindex/ports.
1 error

Committers on the hook:
lippe tdb 

Most recent CVS update was:
U Mk/bsd.sites.mk
U java/Makefile
U lang/Makefile
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


INDEX now builds successfully on 6.x

2008-06-23 Thread Erwin Lansing

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: erlang doesn't build on 7.0?

2008-06-23 Thread Dale Hagglund
 Vivek == Vivek Khera [EMAIL PROTECTED] writes:

Vivek erlang-r12b2,1 installed just fine on our 7.0/i386 box a
Vivek couple of months ago.  It was pulled in as a dependency of
Vivek ejabberd automatically.

Thanks for the information.  Did you compile via the port, or install
from the pre-built package?  Since I have no immediate need for the java
support that comes with lang/erlang, I uninstalled my modified version
and added erlang-{lite,doc} from packages.

Dale.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Doug Barton

Alexey Shuvaev wrote:

On Mon, Jun 23, 2008 at 10:57:41AM +0200, Alex Dupre wrote:

Alexey Shuvaev ha scritto:

It seems I don't understand something here. Can someone explain why
jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
(nearly) every JDK port needs an already usable/installed JDK to  
bootstrap the compilation. This is the reason of the BUILD_DEPENDS on  
javac that you cannot remove. But the port providing the javac binary  

 ^

could not be the diablo-jdk.


Mmmm... why not???
In a nutshell, from the user point of view the reason to set BUILD_DEPENDS is
to ensure that some port (java here) is installed prior to build.
However, if the port checks against installed java in a more complicated manner
than BUILD_DEPENDS mechanism can provide, I see no reason to set
BUILD_DEPENDS to something just for its own sake.
And from the build cluster point of view, the port will be built in a clean
environment, so port will not detect any installed java and will set
BUILD_DEPENDS *conditionally* (.if !defiend(BOOTSTRAPJDKDIR)).

I have a feeling that the way BUILD_DEPENDS is set now is overkill, and
one can put it under .if !defined(BOOTSTRAPJDKDIR) without any functional
change. Of course, the Right Way To Do This would be to set the whole
correct BUILD_DEPENDS line based on detected java. Maybe this is even not
so complicated. Or I miss something?


Thanks for the discussion on this. Since I don't use java I'm relying 
an the users here. Hopefully glewis can weigh in at some point.


Doug

--

This .signature sanitized for your protection

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: erlang doesn't build on 7.0?

2008-06-23 Thread Vivek Khera


On Jun 23, 2008, at 3:01 PM, Dale Hagglund wrote:


Thanks for the information.  Did you compile via the port, or install
from the pre-built package?  Since I have no immediate need for the  
java

support that comes with lang/erlang, I uninstalled my modified version
and added erlang-{lite,doc} from packages.


we always compile from port to build our own packages where necessary  
(erlang is a one-off so we didn't build any package)


___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Issues with portmaster

2008-06-23 Thread Greg Lewis
On Mon, Jun 23, 2008 at 12:28:08PM -0700, Doug Barton wrote:
 Alexey Shuvaev wrote:
 On Mon, Jun 23, 2008 at 10:57:41AM +0200, Alex Dupre wrote:
 Alexey Shuvaev ha scritto:
 It seems I don't understand something here. Can someone explain why
 jdk ports need to set BUILD_DEPENDS on diablo-jdk15 unconditionally?
 (nearly) every JDK port needs an already usable/installed JDK to  
 bootstrap the compilation. This is the reason of the BUILD_DEPENDS on  
 javac that you cannot remove. But the port providing the javac binary  
  ^
 could not be the diablo-jdk.
 
 Mmmm... why not???
 In a nutshell, from the user point of view the reason to set BUILD_DEPENDS 
 is
 to ensure that some port (java here) is installed prior to build.
 However, if the port checks against installed java in a more complicated 
 manner
 than BUILD_DEPENDS mechanism can provide, I see no reason to set
 BUILD_DEPENDS to something just for its own sake.
 And from the build cluster point of view, the port will be built in a clean
 environment, so port will not detect any installed java and will set
 BUILD_DEPENDS *conditionally* (.if !defiend(BOOTSTRAPJDKDIR)).
 
 I have a feeling that the way BUILD_DEPENDS is set now is overkill, and
 one can put it under .if !defined(BOOTSTRAPJDKDIR) without any functional
 change. Of course, the Right Way To Do This would be to set the whole
 correct BUILD_DEPENDS line based on detected java. Maybe this is even not
 so complicated. Or I miss something?
 
 Thanks for the discussion on this. Since I don't use java I'm relying 
 an the users here. Hopefully glewis can weigh in at some point.

Its probably not that complicated for the port to stop cheating on the
way it sets up BUILD_DEPENDS.  At the moment it knows the potential
bootstrap JDKs install paths, but it doesn't know where they live in
ports, so it cheats and sets the requirement to the detected javac but
then hardcodes the dependency as Diablo.  This works from a ports point
of view in that the dependency isn't installed if the requirement is
found, but it obviously confuses portsmaster.

From a partial reading of the email thread, it looks like the simplest
thing to do is to just not set BUILD_DEPENDS if it finds an appropriately
installed JDK.  That way it will only set it if it can't find a bootstrap
JDK and it needs one installed.

-- 
Greg Lewis  Email   : [EMAIL PROTECTED]
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology  FreeBSD : [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]


RE: devel/libdlna build fail

2008-06-23 Thread Greg Larkin
  From: Jyun-Yi Liou [mailto:[EMAIL PROTECTED] 
 
  2008/6/20 Greg Larkin [EMAIL PROTECTED]:
  
   -Original Message-
   From: [EMAIL PROTECTED]
   [mailto:[EMAIL PROTECTED] On Behalf Of Jyun-Yi Liou
   Sent: Thursday, June 19, 2008 4:06 AM
   To: freebsd-ports@freebsd.org
   Cc: [EMAIL PROTECTED]
   Subject: devel/libdlna build fail
  
   Hi list!,
   I have some trouble while I am trying to install
   devel/libdlna at ./configure
  
   and the attatchment is my config.log
  
   Thx a lot!
  
   Regards,
   jyuny1
  
  Hi Jyun-Yi,
 
  What do you get as output from the following command?
 
  pkg_info -L ffmpeg\* | grep avformat.h
 
  On my machine, I see:
 
  /usr/local/include/ffmpeg/avformat.h
  
  I was able to configure and install devel/libdlna with no problem, and
it
  looks like as long as multimedia/ffmpeg installs correctly, you should
have
  an avformat.h file in the location above.  If you do have that file and
the
  devel/libdlna configuration still fails, then I'll have to think of
  something else to try.
 
  Regards,
  Greg Larkin
  SourceHosting.net, LLC
  http://www.sourcehosting.net/
 
 
 
 Hi Gerg,
 
 jyuny1|/usr/ports/devel/libdlna% pkg_info -L ffmpeg\* | grep avformat.h
 /usr/local/include/libavformat/avformat.h
 
 yes, I installed another custom-ffmpeg, not the regular one
 How can I fix this ussie?
 
 Thx a lot!
 
 Regards,
 jyuny1

Hi Jyun-Yi,

What do you mean that you installed another custom-ffmpeg?  Did you
install ffmpeg from ports and with what options?  

If you didn't install it from ports, I suggest that you remove the one you
did install, and then try the libdlna installation again.  It should
automatically build and install the ffmpeg dependency for you.  If that
doesn't work, post back to the list.

Regards,
Greg Larkin
SourceHosting.net, LLC
http://www.sourcehosting.net/



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]