Re: Call for testers - mplayer svn port
On Thu, 7 Jan 2010 22:52:51 +0100, Thomas Zander wrote Hi Thomas, Hi Martin, Happy new year :) thanks to Wes Morgan and Martin Wilke there is something for you to test which approximates what's going to become our next mplayer in the ports tree. Thanks for this update. I have had no time to test the port yet unfortunately, but reading files/patch-stream-stream_dvd.h, I see that you use an included libdvdread. I think it would be great to use our (ports') version. It is the one released by the Mplayer team, so it should build without trouble (I hope so). By the way, Martin, I have an old PR waiting for approval (see http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/131969). It suggests switching to Mplayer's version of libdvdnav. It may be interesting to switch to this version and add libdvdnav support to the new Mplayer port... Best regards, Ganaël LAPLANCHE ganael.laplan...@martymac.org http://www.martymac.org ___ 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: libftdi-0.14_1
Hi!
Written by Steve Franks at 2010 January 04 14:40:32 (-0700)
It seems our libftdi is several versions behind (current is 0.17).
I'm no expert, but I got 0.17 to build by adding the following to
/usr/ports/devel/libftdi/Makefile:
WITH_BOOST=yes
CONFIGURE_ARGS+=--with-boost=/usr/local/include/boost
CFLAGS+=-I${LOCALBASE}/include -L${LOCALBASE}/lib
CXXFLAGS+=-I${LOCALBASE}/include -L${LOCALBASE}/lib
I'm not sure which of those are canonically required, I'm a noob as
far as freebsd.
Also, I changed to (obviously):
PORTVERSION= 0.17
I thought I'd run it by you before submitting a pr, since maybe I'm
missing something...
--with-boost=${LOCALBASE}/include/boost will be better, than
--with-boost=/usr/local/include/boost
--
WBR,
Davidenko Alexandr
___
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: UIDs question
On Wed, Jan 6, 2010 at 8:26 PM, Jason jhelf...@e-e.com wrote:
Hi,
I am new to building ports, however I have started to get the hang of
things.
I am not building any ports that I intend on submitting to FreeBSD, yet,
however maybe that isn't too far off :)
I've used a guide I found to create a local ports repository that is working
out wonderfully with the existing ports tree under /usr/ports
My tree is under /usr/ports/local, and I found a way to integrate a local
UIDs and GIDs file, by setting this variable in my Makefile:
UID_FILES:=${PORTSDIR}/local/UIDs
When I go to install my port it installs the user as expected, however it
fails on the ${INSTALL_PROGRAM} function. I understand this is just using
install with the appropriate flags. Obviously, the port doesn't install.
If I run it again, the user is already on the system, and the port installs
successfully.
I was wondering if there is a way to have the port install the user using
the native USERS or GROUPS directives in the do-install phase with the
INSTALL macros, or if there is a more suggested, or conventional, way of
doing this operation.
Would you mind putting the files somewhere and showing us the error
log? I am aware of one caveat at the moment, which is that you can't
use users/groups created with USERS/GROUPS in pkg-plist. Every typical
use case with directives contained in Makefile should be fine AFAIK.
--
Florent Thoumie
f...@freebsd.org
FreeBSD Committer
___
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: Call for testers - mplayer svn port
On Thursday 07 January 2010 22:52:51 Thomas Zander wrote: Hi, thanks to Wes Morgan and Martin Wilke there is something for you to test which approximates what's going to become our next mplayer in the ports tree. Thanks for your effort. It basically seems to work, but haven't really done much testing yet. I'd really like to have a knob for enabling asm for x264. I've tried a linux binary and it is about 4x faster. Apparently it seems to work when built with gcc44, see: http://lists.freebsd.org/pipermail/freebsd-multimedia/2009- November/010548.html VDPAU support would also be nice. ___ 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: GNAT and LAPACK
On 2010-01-08 00:09:57, Gerald Pfeifer wrote: I looked into the situation and think the following should work nicely given the constraints of the FreeBSD Ports Collection in handling dependencies and creating several packages from one build: 1. Make gnat-gcc44 dependent on gcc44 itself by means of USE_GCC=4.4. 2. Have math/lapack as another dependency to gnat-gcc44. 3. Build the minimum necessary as part of gnat-gcc44. Do not install using `make install`, but copy the relevant files to $PREFIX/bin, $PREFIX/lib,... manually. That way the Ports Collection as such will use gcc44 and you will add the GNAT support from gnat-gcc44 (and only that) on top. I agree, this sounds much better. It's not clear to me, however, how to determine which parts of a given GNAT build are specific to GNAT so that I only install those. Any ideas? I'm currently looking at the output of pkg_info -Lx to try to make an educated guess... M ___ 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: GNAT and LAPACK
This appears to be the correct list of files that only apply to GNAT: http://coreland.ath.cx/tmp/gnat-dist.txt M ___ 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: GNAT and LAPACK
On Fri, 8 Jan 2010, freebsd-po...@coreland.ath.cx wrote:
This appears to be the correct list of files that only apply to GNAT:
http://coreland.ath.cx/tmp/gnat-dist.txt
Note that if you want to combine this with lang/gcc44 as I had
suggested you'll need something like
TARGLIB=${PREFIX}/lib/gcc${SUFFIX}
LIBEXEC=${PREFIX}/libexec/gcc${SUFFIX}
CONFIGURE_ARGS+= --libdir=${TARGLIB} \
--libexecdir=${LIBEXEC}
in your port.
Glimpsing at the list your created, it does look good to me.
Gerald
___
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
The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
01/-10/37 14:59, lini...@freebsd.org wrote: portname: devel/adabindx description:An Ada-binding to the X Window System and *tif maintainer:po...@freebsd.org status: BROKEN deprecated because: has been broken for 3 months expiration date:2010-01-08 build errors: none. overview:http://portsmon.FreeBSD.org/portoverview.py?category=develportname=adabindx [...] It looks like a noticeable share of the ports listed have one thing in common -- they depend on Ada. Various gnat-ports would not even build on anything but i386... Is Ada-support really in such a bad shape by the GNU-project, or is it just a FreeBSD problem? -mi ___ 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: Issues with Perl 5.8.9_3 port/package (in combination with FreeRADIUS 2.1.6)
One of the FreeRADIUS maintainers pointed out to me that there is a problem
with freeradius + rlm_perl module + libltdl/libtools 2.2, in that they are
still using the old libltdl API. You can fix this by either using libtools
1.5 (which is difficult since its been removed from the ports tree) or
upgrade the freeradius2 port to version 2.1.8 and add the following diff to
the port. I also had to manually update the pkg-plist file.
--- src/main/modules.c 2010-01-08 06:43:51.0 -0800
+++ src/main/modules.c 2010-01-08 07:48:12.0 -0800
@@ -207,9 +207,6 @@
* Solve the issues of libraries linking to other libraries
* by using a newer libltdl API.
*/
-#ifndef HAVE_LT_DLADVISE_INIT
-#define fr_dlopenext lt_dlopenext
-#else
static lt_dlhandle fr_dlopenext(const char *filename)
{
lt_dlhandle handle = 0;
@@ -225,7 +222,6 @@
return handle;
}
-#endif /* HAVE_LT_DLADVISE_INIT */
#endif /* WITHOUT_LIBLTDL */
static int virtual_server_idx(const char *name)
On Thu, Jan 7, 2010 at 3:30 PM, Nick Rogers ncrog...@gmail.com wrote:
I've tried using portupgrade to build and install the freeradius2 package
on a fresh 8.0-RELEASE install with latest ports tree and that did not seem
to change anything.
On Tue, Jan 5, 2010 at 2:04 PM, Jerry ges...@yahoo.com wrote:
On Tue, 5 Jan 2010 15:21:04 -0500 Nick Rogers ncrog...@gmail.com
articulated:
I installed FreeBSD 8.0-RELEASE from official ISO and used pkg_add -r to
install the packages. I also tried building my own packages from ports
tree
and got the same result.
You might try using something like portmanger to rebuild your installed
packages:
portmanager -u -f -l -y
If you go that route, be sure to update your ports tree first.
--
Jerry
ges...@yahoo.com
___
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
___
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: freeradius-2.1.6 + perl-5.8.9_3 + perl hook problem
One of the FreeRADIUS maintainers pointed out to me that there is a problem
with freeradius + rlm_perl module + libltdl/libtools 2.2, in that they are
still using the old libltdl API. You can fix this by either using libtools
1.5 (which is difficult since its been removed from the ports tree) or
upgrade the freeradius2 port to version 2.1.8 and add the following diff to
the port. I also had to manually update the pkg-plist.
--- src/main/modules.c 2010-01-08 06:43:51.0 -0800
+++ src/main/modules.c 2010-01-08 07:48:12.0 -0800
@@ -207,9 +207,6 @@
* Solve the issues of libraries linking to other libraries
* by using a newer libltdl API.
*/
-#ifndef HAVE_LT_DLADVISE_INIT
-#define fr_dlopenext lt_dlopenext
-#else
static lt_dlhandle fr_dlopenext(const char *filename)
{
lt_dlhandle handle = 0;
@@ -225,7 +222,6 @@
return handle;
}
-#endif /* HAVE_LT_DLADVISE_INIT */
#endif /* WITHOUT_LIBLTDL */
static int virtual_server_idx(const char *name)
On Thu, Jan 7, 2010 at 8:19 AM, Nick Rogers ncrog...@gmail.com wrote:
I started a thread discussing a similar problem a few days ago but I would
like to repost a more concise statement and a way to replicate easily.
There seems to be some kind of shared library linking issue between the
freeradius2 and perl packages compiled from RELEASE_8_0 ports tree branch.
If one tries to use freeradius in conjunction with a perl hook (script) for
authentication, and the perl script requires a perl module relying on a
compiled shared object file (e.g., IO), then freeradius will fail to load
the perl script and throws errors.
Below is a dump that should make it easy to replicate the problem. This was
done after freshly installing 8.0-RELEASE-i386 onto a system from the
official ISO.
Note that I have also tried to compile the ports myself and run into the
same problem on i386 and amd64 architectures. I am going to try and compile
the ports using portupgrade as suggested by someone on this list and see if
that changes anything. Any further help would be greatly appreciated.
Thanks!
# uname -a
FreeBSD 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
#
# pkg_info
#
#
# pkg_add -r freeradius
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/Latest/freeradius.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/python26-2.6.2_3.tbz...
Done.
Note that some of the standard modules are provided as separate
ports since they require extra dependencies:
bsddb databases/py-bsddb
gdbmdatabases/py-gdbm
sqlite3 databases/py-sqlite3
tkinter x11-toolkits/py-tkinter
Install them as needed.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/perl-5.8.9_3.tbz...
Done.
Removing stale symlinks from /usr/bin...
Skipping /usr/bin/perl
Skipping /usr/bin/perl5
Done.
Creating various symlinks in /usr/bin...
Symlinking /usr/local/bin/perl5.8.9 to /usr/bin/perl
Symlinking /usr/local/bin/perl5.8.9 to /usr/bin/perl5
Done.
Cleaning up /etc/make.conf... Done.
Spamming /etc/make.conf... Done.
Cleaning up /etc/manpath.config... Done.
Spamming /etc/manpath.config... Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/libltdl-2.2.6a.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/gdbm-1.8.3_3.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/libiconv-1.13.1.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/gettext-0.17_1.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/gmake-3.81_3.tbz...
Done.
=== Created group freeradius
=== Created user freeradius
=== Setting user and group in radiusd.conf
=== Bootstrapping default certificates, please wait...
=== Adjusting ownership of directory /usr/local/etc/raddb
=== Adjusting ownership of directory /var/log/radacct
=== Adjusting ownership of directory /var/run/radiusd
=== Adjusting ownership of /var/log/radius.log
=== Adjusting ownership of /var/log/radutmp
=== Adjusting ownership of /var/log/radwtmp
=== Updating libdir in /usr/local/etc/raddb/radiusd.conf
===
To enable FreeRADIUS, put the following line in /etc/rc.conf
radiusd_enable=YES
The sample configuration can be found at
/usr/local/share/examples/freeradius/raddb
If you are upgrading FreeRADIUS, you are advised to use this as a reference
for updating your configuration.
FreeRADIUS will look for its configuration directory at
/usr/local/etc/raddb by default.
If you did not already have a configuration at this location, the sample
configuration has been copied to this location and has
Re: Initial bsd.gnat.mk
On 2010-01-02 21:00:35, freebsd-po...@coreland.ath.cx wrote: Hello. This is an initial version of 'bsd.gnat.mk'. Any chance of someone committing this so that I may start sweeping through the existing BROKEN Ada ports? I'm taking the lack of comments to mean a lack of objections! M ___ 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: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
It looks like a noticeable share of the ports listed have one thing in common -- they depend on Ada. Various gnat-ports would not even build on anything but i386... Is Ada-support really in such a bad shape by the GNU-project, or is it just a FreeBSD problem? 'Lo. Current situtation is this: I've spent a great deal of time getting GCC 4.4 ported to FreeBSD on i386 and x86_64. I currently do regular builds of GCC from SVN on 7/8 i386/x86_64, the logs and test results of which are available here: http://gcc.coreland.ath.cx/ No binaries, sorry. I'm limited by bandwidth and disk space. As you can see, GNAT works pretty well on FreeBSD and passes most of ACATS. I created the lang/gnat-gcc44 port a couple of months ago and have worked to ensure that it works on 7/8 i386/x86_64. Unfortunately, there won't be support for other platforms until somebody else decides to do the cross compilation and produce bootstrap binaries (it's not particularly difficult, just time consuming). http://coreland.ath.cx/code/gnatport I've recently written a bsd.gnat.mk file which I hope will soon be committed to the ports system. This will allow all Ada ports to state 'USE_GNAT=yes' and will remove the requirement to have up to four (!) different Ada compilers installed in order to use all existing ports (assuming that they build and work). This also allows one to, for example, set 'USE_GNAT=gnat-gpl' in /etc/make.conf and use the GNAT GPL compiler for all ports. This'll currently only work on i386 as the current version of the compiler seems to lack x86_64 support (maybe the 2010 version will be better). I'll work on converting all existing ports to this system. I also have a large number of my own projects to submit (bindings for various libraries such as SDL, OpenGL, OpenAL and pure Ada libraries). In short, the current state of Ada on FreeBSD is poor but should shortly improve exponentially. M ___ 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/142476: bsd.gnat.mk - improved Ada support for the ports system
Thank you very much for your problem report. It has the internal identification `ports/142476'. The individual assigned to look at your report is: freebsd-ports-bugs. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=142476 Category: ports Responsible:freebsd-ports-bugs Synopsis: bsd.gnat.mk - improved Ada support for the ports system Arrival-Date: Fri Jan 08 19:20:01 UTC 2010 ___ 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: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
- Original Message From: freebsd-po...@coreland.ath.cx freebsd-po...@coreland.ath.cx To: John Merryweather Cooper john_m_coo...@yahoo.com Cc: Mikhail T. mi+t...@aldan.algebra.com; ka...@lovetemple.net; eisc...@vigrid.com; freebsd-ports@freebsd.org Sent: Fri, January 8, 2010 10:56:38 AM Subject: Re: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion) It looks like a noticeable share of the ports listed have one thing in common -- they depend on Ada. Various gnat-ports would not even build on anything but i386... Is Ada-support really in such a bad shape by the GNU-project, or is it just a FreeBSD problem? 'Lo. Current situtation is this: I've spent a great deal of time getting GCC 4.4 ported to FreeBSD on i386 and x86_64. I currently do regular builds of GCC from SVN on 7/8 i386/x86_64, the logs and test results of which are available here: http://gcc.coreland.ath.cx/ No binaries, sorry. I'm limited by bandwidth and disk space. As you can see, GNAT works pretty well on FreeBSD and passes most of ACATS. I created the lang/gnat-gcc44 port a couple of months ago and have worked to ensure that it works on 7/8 i386/x86_64. Unfortunately, there won't be support for other platforms until somebody else decides to do the cross compilation and produce bootstrap binaries (it's not particularly difficult, just time consuming). http://coreland.ath.cx/code/gnatport I've recently written a bsd.gnat.mk file which I hope will soon be committed to the ports system. This will allow all Ada ports to state 'USE_GNAT=yes' and will remove the requirement to have up to four (!) different Ada compilers installed in order to use all existing ports (assuming that they build and work). This also allows one to, for example, set 'USE_GNAT=gnat-gpl' in /etc/make.conf and use the GNAT GPL compiler for all ports. This'll currently only work on i386 as the current version of the compiler seems to lack x86_64 support (maybe the 2010 version will be better). I'll work on converting all existing ports to this system. I also have a large number of my own projects to submit (bindings for various libraries such as SDL, OpenGL, OpenAL and pure Ada libraries). In short, the current state of Ada on FreeBSD is poor but should shortly improve exponentially. M USE_GNAT would be a massive improvement. It would allow the dependent ports to potentially strip out the logic necessary to determine which compiler is try to build them (and if it will work). jmc ___ 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: Initial bsd.gnat.mk
ports/142476 M ___ 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: Maintaining compiler front-ends (Re: The state of Ada)
On 2010-01-08 14:37:37, Mikhail T. wrote: I remain convinced, that the bending into shape ought to begin with making the additional GNU compiler front-ends (be they Ada, or Lisp, Java, Fortran, Pascal, Objective C, etc.) addable to an already existing C-compiler. That's the plan! The lang/gnat-gcc44 currently has a problem in that anything that uses Ada.Numerics.* will quietly depend on liblapack.so at compile time. In order to compile liblapack, you need a recent GCC with fortran support... The idea is now for the lang/gnat-gcc44 port to install itself into the files installed by the existing lang/gcc44 port. I hope to work on this soon (getting USE_GNAT in and unbreaking all the existing ports is currently of higher priority). M ___ 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: Maintaining compiler front-ends (Re: The state of Ada)
- Original Message From: Mikhail T. mi+t...@aldan.algebra.com To: John Merryweather Cooper john_m_coo...@yahoo.com Cc: po...@freebsd.org; ka...@lovetemple.net; eisc...@vigrid.com; m...@freebsd.org; jo...@freebsd.org Sent: Fri, January 8, 2010 11:37:37 AM Subject: Maintaining compiler front-ends (Re: The state of Ada) 01/08/10 13:10, John Merryweather Cooper написав(ла): Well, the [Ada -mi] compiler needs to be upgraded to the latest version. Linux gets a compiler out of the box, but we have to bend one to shape. I remain convinced, that the bending into shape ought to begin with making the additional GNU compiler front-ends (be they Ada, or Lisp, Java, Fortran, Pascal, Objective C, etc.) addable to an already existing C-compiler. I find it crazy, that every such front end currently downloads and builds its own gcc-core-SOMEVERSION, instead of using the base gcc or DEPEND-ing on lang/gccSOMEVERSION. Yes, I am well aware, that this is, how GNU people do things. No, I don't think, there is nothing FreeBSD can do about it... Starting with making all such compilers use common binutils. (Perhaps, these can even be provided by the base -- NetBSD does just that, for example...) Once done, ports of front-ends will no longer have to each deal with the back-end making the maintainership easier and thus giving us better ports... -mi Common binutils would help alot. In general, it would also be excellent to return to a schema where languages are considered plugins to GCC. The savings in disk space, build trouble, and compiler porting could be substantial. jmc ___ 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: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
On Fri, 8 Jan 2010, John Merryweather Cooper wrote: Well, the compiler needs to be upgraded to the latest version. Linux gets a compiler out of the box, but we have to bend one to shape. Most things stay the same, but there are always subtle differences. I'd be happy to help do this (as I'm currently unemployed), but I'm also going through a divorce. You can contact me more directly at j.m.cooper at borgsdemons.com. All the ports that I saw that were broken, were broken *because* the compiler (lang/gnat) was updated. Those ports seemed to be vastly out of date and didn't build with the latest GPL gnat from ACT. -- DE ___ 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: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
On Fri, Jan 08, 2010 at 06:56:38PM +, freebsd-po...@coreland.ath.cx wrote: I created the lang/gnat-gcc44 port a couple of months ago and have worked to ensure that it works on 7/8 i386/x86_64. Unfortunately, there won't be support for other platforms until somebody else decides to do the cross compilation and produce bootstrap binaries (it's not particularly difficult, just time consuming). IMHO it's not much worth worrying about the state of Ada on our tier-2 architectures. I just don't see there being any userbase for that. sparc64 has lots of other ports that need attention more than Ada, and the other archs ... just need lots of attention. (Yes, I do know of people using powerpc and ia64 even as desktops, but they're a small, brave, minority.) fwiw, I'm glad you've taken up the banner of fixing this stuff. mcl ___ 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: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
- Original Message From: Daniel Eischen deisc...@freebsd.org To: John Merryweather Cooper john_m_coo...@yahoo.com Cc: Mikhail T. mi+t...@aldan.algebra.com; po...@freebsd.org; ka...@lovetemple.net Sent: Fri, January 8, 2010 11:59:05 AM Subject: Re: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion) On Fri, 8 Jan 2010, John Merryweather Cooper wrote: Well, the compiler needs to be upgraded to the latest version. Linux gets a compiler out of the box, but we have to bend one to shape. Most things stay the same, but there are always subtle differences. I'd be happy to help do this (as I'm currently unemployed), but I'm also going through a divorce. You can contact me more directly at j.m.cooper at borgsdemons.com. All the ports that I saw that were broken, were broken *because* the compiler (lang/gnat) was updated. Those ports seemed to be vastly out of date and didn't build with the latest GPL gnat from ACT. -- DE That's largely true--I need to take a look and get things going again. But there's still a parallel compiler path that creates problems. Most ports (before being put into the tree) expect to be built with one of the pre-built compilers from ACT. So name and location problems exist. I'm sorry I've been off the wheel but I sold my soul to Microsoft (at least for awhile) . . . jmc ___ 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: The state of Ada (Re: FreeBSD unmaintained ports which are currently scheduled for deletion)
01/08/10 14:59, Daniel Eischen написав(ла): All the ports that I saw that were broken, were broken *because* the compiler (lang/gnat) was updated. Those ports seemed to be vastly out of date and didn't build with the latest GPL gnat from ACT. Well, I tried to fix one, but my system is amd64, so I couldn't even begin... Good to see, somebody is working on it, though... -mi ___ 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: Call for testers - mplayer svn port
On Fri, Jan 8, 2010 at 09:04, Ganael LAPLANCHE ganael.laplan...@martymac.org wrote: I have had no time to test the port yet unfortunately, but reading files/patch-stream-stream_dvd.h, I see that you use an included libdvdread. I think it would be great to use our (ports') version. It is the one released by the Mplayer team, so it should build without trouble (I hope so). Probably. I prefer the internal dvdread, though, because the dependency list of mplayer is already quite extensive, and I am trying to reduce the number of dependencies where possible. By the way, Martin, I have an old PR waiting for approval (see http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/131969). It suggests switching to Mplayer's version of libdvdnav. It may be interesting to switch to this version and add libdvdnav support to the new Mplayer port... The new port uses libdvdnav support already. Again, mplayer's built-in version. Works fine here. Riggs ___ 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: Maintaining compiler front-ends (Re: The state of Ada)
As Mikhail T. wrote: I remain convinced, that the bending into shape ought to begin with making the additional GNU compiler front-ends (be they Ada, or Lisp, Java, Fortran, Pascal, Objective C, etc.) addable to an already existing C-compiler. I find it crazy, that every such front end currently downloads and builds its own gcc-core-SOMEVERSION, instead of using the base gcc or DEPEND-ing on lang/gccSOMEVERSION. Since you've got me on Cc, you are aware that the GCC ports I'm maintaining are only cross compilers (for the AVR target). I don't think you'll be able to combine them together with a native compiler. ;-) I'm also maintaining a port of libbfd which is used by some AVR toolchain software. This port is set up in a kitchensink way, so all possible binary file formats are included. This could perhaps serve as a base for a generic GNU libbfd package to be used by other GNU stuff if desired. Note that it requires GNU libiberty to be installed as well (freelibiberty won't do), as libbfd uses undocumented GNU libiberty functions. :-( -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ 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: Call for testers - mplayer svn port
On Fri, Jan 8, 2010 at 11:40, Stefan Ehmann shoes...@gmx.net wrote: VDPAU support would also be nice. Noted, thanks. I have overlooked that one. I'll include it with the next iteration in a few days. You are right about the x264 defects. We shall look into this. Riggs ___ 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: Maintaining compiler front-ends (Re: The state of Ada)
01/08/10 15:59, Joerg Wunsch ???(??): I'm also maintaining a port of libbfd which is used by some AVR toolchain software. This port is set up in a kitchensink way, so all possible binary file formats are included. This could perhaps serve as a base for a generic GNU libbfd package to be used by other GNU stuff if desired. Note that it requires GNU libiberty to be installed as well (freelibiberty won't do), as libbfd uses undocumented GNU libiberty functions.:-( Hi, Joerg! Yes, this is why I added you to CC, and I do think, that the common libbfd ought to have all of the known targets included. Even altogether they use very little space -- less, than having to add just one more flavor separately (even multiplied by the probability of ever having to do that :) As for GNUberty, well... Maybe, some day, we'll add those functions to the liberfreety (or patch bfd to avoid them). Until then -- use the GNU's code as we do elsewhere... Yours, -mi ___ 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
courier authldap problem with the latest 1.9 authldap.schema
#$Id: authldap.schema,v 1.8 2005/03/20 19:10:30 mrsam Exp $ --- #$Id: authldap.schema,v 1.9 2009/12/18 04:24:20 mrsam Exp $ Slapd doesn't want to start with schema 1.9 but with 1.8 still works fine. I looked at the differences but wasn't able to or didn't take enough time to figure out why or exactly what was causing the problem. I get no real error the log file only shows: Jan 8 11:05:49 HOME slapd[48464]: @(#) $OpenLDAP: slapd 2.4.21 (Jan 8 2010 10:35:29) $ r...@home.encontacto.net:/usr/local/ports/net/openldap24-server/work/openldap-2.4.21/servers/slapd Jan 8 11:05:49 HOME slapd[48464]: slapd stopped. Jan 8 11:05:49 HOME slapd[48464]: connections_destroy: nothing to destroy. Not ver intuitive, IMHO :( I'm runing openldap-server-2.4.21 and openldap-client-2.4.21 on FreeBSD 7.2-STABLE #1092. It is running fine with schema 1.8. Thanks, ed ___ 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: UIDs question
On Fri, Jan 08, 2010 at 10:09:36AM +, Florent Thoumie thus spake:
On Wed, Jan 6, 2010 at 8:26 PM, Jason jhelf...@e-e.com wrote:
Hi,
I am new to building ports, however I have started to get the hang of
things.
I am not building any ports that I intend on submitting to FreeBSD, yet,
however maybe that isn't too far off :)
I've used a guide I found to create a local ports repository that is working
out wonderfully with the existing ports tree under /usr/ports
My tree is under /usr/ports/local, and I found a way to integrate a local
UIDs and GIDs file, by setting this variable in my Makefile:
UID_FILES:=${PORTSDIR}/local/UIDs
When I go to install my port it installs the user as expected, however it
fails on the ${INSTALL_PROGRAM} function. I understand this is just using
install with the appropriate flags. Obviously, the port doesn't install.
If I run it again, the user is already on the system, and the port installs
successfully.
I was wondering if there is a way to have the port install the user using
the native USERS or GROUPS directives in the do-install phase with the
INSTALL macros, or if there is a more suggested, or conventional, way of
doing this operation.
Would you mind putting the files somewhere and showing us the error
log? I am aware of one caveat at the moment, which is that you can't
use users/groups created with USERS/GROUPS in pkg-plist. Every typical
use case with directives contained in Makefile should be fine AFAIK.
--
Florent Thoumie
f...@freebsd.org
FreeBSD Committer
I've uploaded to pastebin, and hope this is enough to go on. Please let me
know if it is not, and I will make the information needed available.
http://freebsd.pastebin.com/m359b2c91
Thanks!
-jgh
___
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
FreeBSD Port: clamav-0.95.3
hi there. this port appears to be broken for 6.3 release (which i realize is old, but regardless) by --enable-gethostbyname_r in the Makefile. changing this to --disable-gethostbyname_r allows the port to build fine. Since even the man pages for FreeBSD 8.0 don't seem to have a gethostbyname_r http://www.freebsd.org/cgi/man.cgi?query=gethostbyname_rapropos=0sektion=0manpath=FreeBSD+8.0-RELEASEformat=html i'm fairly sure it's not supposed to be there. Cheers! Sundie... ___ 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
