INDEX build failed with errors:
Generating INDEX-6 - please wait..pkg_info: not found
pkg_info: not found
Done.
make_index: psptoolchain-newlib-1.15.0: no entry for
/usr/ports/devel/psptoolchain-pspsdk-stage1
make_index: psptoolchain-gdb-6.4: no entry for
/usr/ports/devel/psptoolchain-pspsdk-sta
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as "broken" in their Makefiles. In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments. The most common probl
As part of an ongoing effort to reduce the number of problems in the
FreeBSD ports system, we periodically notify users about
ports that are marked as "forbidden" in their Makefiles. Often,
these ports are so marked due to security concerns, such as known
exploits.
An overview of each port, inclu
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically schedule removal of ports
that have been judged to have outlived their usefulness. Often,
this is due to a better alternative having become available and/or
the cessation of development on th
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically notify users of ports
that are marked as "broken" in their Makefiles. In many cases
these ports are failing to compile on some subset of the FreeBSD
build environments. The most common probl
As part of an ongoing effort to reduce the number of problems in
the FreeBSD ports system, we periodically schedule removal of ports
that have been judged to have outlived their usefulness. Often,
this is due to a better alternative having become available and/or
the cessation of development on th
As part of an ongoing effort to reduce the number of problems in the
FreeBSD ports system, we periodically notify users about
ports that are marked as "forbidden" in their Makefiles. Often,
these ports are so marked due to security concerns, such as known
exploits.
An overview of each port, inclu
Dmitry Marakasov writes:
> To make adding DESKTOP_ENTRIES simple and fun, here's a script called
> "de" which outputs a template for desktop entry when run from port's
> directory:
>
> --- de begins here ---
> #!/bin/sh
>
> echo "DESKTOP_ENTRIES=\"`make -V PORTNAME`\" \\"
> echo "
Woo hoo! I found the bug, and fixed it in the just-committed version
2.10. The bug was in the NO_DEP_UPDATES flag which is one of the
oldest features of portmaster. It operates in the first pass through
the dependencies (aka config mode) and if all of the dependent ports
are up to date it allows th
INDEX build failed with errors:
Generating INDEX-6 - please wait..pkg_info: not found
pkg_info: not found
Done.
make_index: psptoolchain-newlib-1.15.0: no entry for
/usr/ports/devel/psptoolchain-pspsdk-stage1
make_index: psptoolchain-gdb-6.4: no entry for
/usr/ports/devel/psptoolchain-pspsdk-sta
* Pav Lucistnik (p...@freebsd.org) wrote:
> > > I've been following this discussion closely since several of my ports
> > > fetch
> > > from Sourceforge. Is it safe to assume that some global solution will be
> > > applied to the ports tree? Or are we maintainers going to need to submit
> >
Andriy Gapon wrote:
It seems that the problem is caused by arp carrying its own libtool-related bits
and those bits being incompatible with libtool-2.2.6a.
For me, I resolved the problem by copying
/usr/local/share/aclocal/ltoptions.m4
/usr/local/share/aclocal/ltsugar.m4
/usr/local/share/aclocal/
ports/multimedia/libxine
Somehow links against a lib in its own source directory.
Unresolvable link(s) found in: /usr/local/bin/xine-list-1.1
../src/xine-engine/.libs/libxine.so
Is there another way of getting around this problem ?
--
Jason J. Hellenthal
+1.616.403.8065
jas...@dataix.n
Dmitry Marakasov píše v čt 20. 08. 2009 v 20:40 +0400:
> * Paul Schmehl (pschmehl_li...@tx.rr.com) wrote:
>
> > I've been following this discussion closely since several of my ports fetch
> > from Sourceforge. Is it safe to assume that some global solution will be
> > applied to the ports tree?
on 20/08/2009 19:50 Matthias Andree said the following:
> This isn't sufficient on my system, because then the apr-util still fails.
>
> Note that there is no previous libtool version that Philip's port could
> require.
>
Could you please try also the following?
cp /usr/local/share/libtool/confi
Am 20.08.2009, 13:32 Uhr, schrieb Andriy Gapon :
It seems that the problem is caused by arp carrying its own
libtool-related bits
and those bits being incompatible with libtool-2.2.6a.
For me, I resolved the problem by copying
/usr/local/share/aclocal/ltoptions.m4
/usr/local/share/aclocal/lt
* Paul Schmehl (pschmehl_li...@tx.rr.com) wrote:
> I've been following this discussion closely since several of my ports fetch
> from Sourceforge. Is it safe to assume that some global solution will be
> applied to the ports tree? Or are we maintainers going to need to submit PRs
> for affect
webkit-gtk2 fails to build after libtool-2.2.6a update.
Auto tools provide some helpful self diagnostics:
===> Configuring for webkit-gtk2-1.0.1_8
/usr/local/share/aclocal/smpeg.m4:13: warning: underquoted definition of
AM_PATH_SMPEG
/usr/local/share/aclocal/smpeg.m4:13: run info '(automake)Ext
--On Wednesday, August 19, 2009 23:08:04 -0500 "Philip M. Gollucci"
wrote:
Dmitry Marakasov wrote:
[1] http://people.freebsd.org/~amdmi3/sf.pl.txt
Awesome.
Rewriting this:
my $portname = `make -VPORTNAME`;
chomp $portname;
my $portname_lc = lc($portname);
my $portversion = `make -VPORTVER
...
/bin/sh /usr/obj/ports/usr/ports/audio/pulseaudio/work/gnome-libtool --tag=CC
--mode=compile cc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include
-I../src -I../src -I../src/modules -I../src/modules -I../src/modules/rtp
-I../src/modules/rtp -I../src/modules/gconf -I../src/modules/gconf
> Troy wrote:
> > David Southwell wrote:
> >>> Troy wrote:
> Updated all ports to python 26 and the problem still exists:
>
> pkg_info|grep py
> boost-python-libs-1.39.0 Framework for interfacing Python and C++
> p5-Clone-0.31 Clone - recursively copy Perl datatypes
>
* Philip M. Gollucci (pgollu...@p6m7g8.com) wrote:
> Rewriting this:
> my $portname = `make -VPORTNAME`;
> chomp $portname;
> my $portname_lc = lc($portname);
>
> my $portversion = `make -VPORTVERSION`;
> chomp $portversion;
>
> Like this, will help substantially by reducing make spawns by 1/2,
It seems that the problem is caused by arp carrying its own libtool-related bits
and those bits being incompatible with libtool-2.2.6a.
For me, I resolved the problem by copying
/usr/local/share/aclocal/ltoptions.m4
/usr/local/share/aclocal/ltsugar.m4
/usr/local/share/aclocal/ltversion.m4
/usr/loc
Ports tree updated this morning.
libtool-2.2.6a is installed
stable/7 amd64
Options:
_OPTIONS_READ=apr-gdbm-db42-1.3.8.1.3.9
WITH_THREADS=true
WITHOUT_IPV6=true
WITH_GDBM=true
WITH_BDB=true
WITHOUT_NDBM=true
WITHOUT_LDAP=true
WITHOUT_MYSQL=true
WITHOUT_PGSQL=true
Build fails at configure stage.
Hi, all. Hopefully this is the right list; apologies if not.
Wondering if anyone else has seen this or if something peculiar to my
set-up.
Server is i386 FreeBSD 7.2, ports upgraded with portmaster.
vsftpd upgraded from 2.0.5 (or .6) to 2.1.0 no problems.
Upgraded to 2.2.0 and ftp clients
On 19/08/2009, Dmitry Marakasov wrote:
> Here's the list of ports that depend on libX11 (based on INDEX-8) and do
> not either have DESKTOP_ENTRIES in Makefile or share/applications/*.desktop
> in pkg-plist:
>
> http://people.freebsd.org/~amdmi3/desktop-needed.txt
Should interactive console appli
26 matches
Mail list logo
