Re: gcc versions following upgrade 6.3 7.0
On Mon, Jul 21, 2008 at 4:09 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 03:11:25AM -0700, [EMAIL PROTECTED] wrote:
FreeBSD **.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16
09:27:38 PDT 2008 @**.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64
# pkg_info |grep gcc
gcc-4.1.3_20080630 GNU Compiler Collection 4.1
gcc-4.2.5_20080702 GNU Compiler Collection 4.2
gccmakedep-1.0.2Create dependencies in makefiles using 'gcc -M'
Should both versions be installed?
That depends. Are you using any ports which depend on specific versions
of GCC? The base system version comes with gcc 4.2.1. There may be
ports which require older or newer GCC, however.
pkg_info -R should help you determine what ports are dependant upon
those two GCC ports.
There isn't anything wrong with having multiple compilers installed on
a given system, insomuch as they install within separate directories
or are prefixed differently. The sym-/hard-links for the compiler last
installed may be the one that gets used though (not sure because I
don't have any experience installing gcc from ports on FreeBSD)...
Do they not place files in same place?
No.
This ties into the reply above, but if you have a compiler provided by
the base system and a compiler provided by ports, they won't install
in the same location, as ${PREFIX} dictates in ports.
-Garrett
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc versions following upgrade 6.3 7.0
On Monday 21 July 2008 23:27:49 Garrett Cooper wrote:
On Mon, Jul 21, 2008 at 4:09 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 03:11:25AM -0700, [EMAIL PROTECTED] wrote:
FreeBSD **.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16
09:27:38 PDT 2008 @**.vizion2000.net:/usr/obj/usr/src/sys/GENERIC
amd64 # pkg_info |grep gcc
gcc-4.1.3_20080630 GNU Compiler Collection 4.1
gcc-4.2.5_20080702 GNU Compiler Collection 4.2
gccmakedep-1.0.2Create dependencies in makefiles using 'gcc -M'
Should both versions be installed?
That depends. Are you using any ports which depend on specific versions
of GCC? The base system version comes with gcc 4.2.1. There may be
ports which require older or newer GCC, however.
pkg_info -R should help you determine what ports are dependant upon
those two GCC ports.
There isn't anything wrong with having multiple compilers installed on
a given system, insomuch as they install within separate directories
or are prefixed differently. The sym-/hard-links for the compiler last
installed may be the one that gets used though (not sure because I
don't have any experience installing gcc from ports on FreeBSD)...
Do they not place files in same place?
No.
This ties into the reply above, but if you have a compiler provided by
the base system and a compiler provided by ports, they won't install
in the same location, as ${PREFIX} dictates in ports.
-Garrett
What happens, as in this instance, the system was originally on 6.1 then 6.3
subsequently upgraded to 7.0?
How can I tell whether the versions were installed by the base system or via
ports?
I am not clear about how the system distinguishes between gcc installed via
ports and via base system. Indcidentally when did gcc become part of the base
system?
david
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc versions following upgrade 6.3 7.0
On Tue, Jul 22, 2008 at 01:07:53AM -0700, David Southwell wrote:
On Monday 21 July 2008 23:27:49 Garrett Cooper wrote:
On Mon, Jul 21, 2008 at 4:09 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 03:11:25AM -0700, [EMAIL PROTECTED] wrote:
FreeBSD **.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16
09:27:38 PDT 2008 @**.vizion2000.net:/usr/obj/usr/src/sys/GENERIC
amd64 # pkg_info |grep gcc
gcc-4.1.3_20080630 GNU Compiler Collection 4.1
gcc-4.2.5_20080702 GNU Compiler Collection 4.2
gccmakedep-1.0.2Create dependencies in makefiles using 'gcc -M'
Should both versions be installed?
That depends. Are you using any ports which depend on specific versions
of GCC? The base system version comes with gcc 4.2.1. There may be
ports which require older or newer GCC, however.
pkg_info -R should help you determine what ports are dependant upon
those two GCC ports.
There isn't anything wrong with having multiple compilers installed on
a given system, insomuch as they install within separate directories
or are prefixed differently. The sym-/hard-links for the compiler last
installed may be the one that gets used though (not sure because I
don't have any experience installing gcc from ports on FreeBSD)...
Do they not place files in same place?
No.
This ties into the reply above, but if you have a compiler provided by
the base system and a compiler provided by ports, they won't install
in the same location, as ${PREFIX} dictates in ports.
-Garrett
What happens, as in this instance, the system was originally on 6.1 then 6.3
subsequently upgraded to 7.0?
How can I tell whether the versions were installed by the base system or via
ports?
The base system does not add anything to the ports/pkg database. The
reason you have gcc 4.1.3 and gcc 4.2.5 on your machine is because some
other port/package depended/depends on them. pkg_info -R will solve
that mystery.
As I said before: some ports/packages may require a newer (or older)
version of GCC, in which case, you'll end up with two (or more) versions
of gcc on your system -- one in the base and one (or more) managed via
ports.
Regardless of what Garrett and others say about how multiple compilers
on a system works great, I do not advocate it. There are many catches
which can/will surprise you down the road, especially with regards to
library linking order, symbol versioning, and a couple other things.
I'm sorry, but in my eyes it's risky behaviour. We've been down this
road before back when perl was in the base system, for similar reasons.
This spawns the whole base vs. ports discussion. For the record, I am
one of the minority who wants to do away with the entire base system
concept. I do not want this thread to start discussing that, though;
let's stay on topic. I just wanted to point it out so that you have
some idea of *why* I say what I do.
I am not clear about how the system distinguishes between gcc installed via
ports and via base system. Indcidentally when did gcc become part of the base
system?
It always has been part of the base system, since at least FreeBSD 2.x
days. I can't speak for 1.x because I wasn't using FreeBSD then.
Use pkg_info -R gcc-4.1.3_20080630 to see what ports are reliant upon
gcc 4.1.3, and rebuild those ports now that you've upgraded to FreeBSD 7
(which includes gcc 4.2.1 in the base system). FreeBSD 6 had gcc 3.4.6,
which is why some ports might have wanted something newr.
Does all of this now make sense?
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc versions following upgrade 6.3 7.0
On Tue, Jul 22, 2008 at 01:07:53AM -0700, David Southwell wrote:
On Monday 21 July 2008 23:27:49 Garrett Cooper wrote:
On Mon, Jul 21, 2008 at 4:09 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Mon, Jul 21, 2008 at 03:11:25AM -0700, [EMAIL PROTECTED] wrote:
FreeBSD **.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul 16
09:27:38 PDT 2008 @**.vizion2000.net:/usr/obj/usr/src/sys/GENERIC
amd64 # pkg_info |grep gcc
gcc-4.1.3_20080630 GNU Compiler Collection 4.1
gcc-4.2.5_20080702 GNU Compiler Collection 4.2
gccmakedep-1.0.2Create dependencies in makefiles using 'gcc -M'
Should both versions be installed?
That depends. Are you using any ports which depend on specific versions
of GCC? The base system version comes with gcc 4.2.1. There may be
ports which require older or newer GCC, however.
pkg_info -R should help you determine what ports are dependant upon
those two GCC ports.
There isn't anything wrong with having multiple compilers installed on
a given system, insomuch as they install within separate directories
or are prefixed differently. The sym-/hard-links for the compiler last
installed may be the one that gets used though (not sure because I
don't have any experience installing gcc from ports on FreeBSD)...
Do they not place files in same place?
No.
This ties into the reply above, but if you have a compiler provided by
the base system and a compiler provided by ports, they won't install
in the same location, as ${PREFIX} dictates in ports.
-Garrett
What happens, as in this instance, the system was originally on 6.1 then 6.3
subsequently upgraded to 7.0?
The version of gcc shipped with 6.3 is 3.4.6.
What probably happened was that you installed some port that required
gcc 4.1 or newer to build, and thus gcc-4.1 was installed automatically as
part of the dependencies for that port.
Later you installed some port that needed gcc 4.2 or later, at which point
gcc-4.2 was installed for you.
If you had been running 7.0 from start, then the gcc ports would not have
been needed, since (as has been noted) FreeBSD 7.0 includes gcc 4.2.
How can I tell whether the versions were installed by the base system or via
ports?
If they show up with pkg_info, then they were installed via the ports
system.
I am not clear about how the system distinguishes between gcc installed via
ports and via base system.
Installed in different places: Just about everything installed from ports
(or packages) will end up under /usr/local/ (or on older systems under
/usr/X11R6/) Files that are part of the base system will not be installed
there.
Indcidentally when did gcc become part of the base
system?
gcc has always been part of the base system. (Otherwise it would have been
difficult to recompile the base system, or to compile any ports.)
--
Insert your favourite quote here.
Erik Trulsson
[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: Vlc
On Sat, Jul 19, 2008 at 10:47 PM, Garrett Cooper [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 3:01 AM, Rafaël Carré [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008, Peter Pentchev wrote: On Fri, Jul 18, 2008 at 01:46:53PM +0300, Okalany Daniel wrote: On Fri, Jul 18, 2008 at 1:14 PM, Garrett Cooper [EMAIL PROTECTED] wrote: [snip] The following options will need to be passed into configure: If you feel so, you can make all these options conditional on WITHOUT_X and send me a patch ;) i.e. for skins2 that would be: .if defined(WITH_SKINS) !defined(WITHOUT_SKINS) !defined(WITHOUT_X) [snip] --disable-freetype Okalany, you seem to have missed this one :) yep --disable-skins These days this option has no effect, it's now named skins2. --disable-skins2 should solve your problem --disable-freetype will build a skins2 interface without freetype support, but I guess it will fail to build anyway because it needs X11 It cofigures okay, but the make fails with In file included from ../../../include/vlc/intf.h:39, parser/../src/ft2_font.hpp: At global scope: parser/../src/ft2_font.hpp:60: error: 'FT_Glyph' does not name a type parser/../src/ft2_font.hpp:61: error: 'FT_BBox' does not name a type parser/../src/ft2_font.hpp:74: error: 'FT_Library' does not name a type parser/../src/ft2_font.hpp:76: error: 'FT_Face' does not name a type Yep, FreeType symbols - see above, you missed an option :) These are the skins2 files Actually if you read through ./configure --help not all options are enabled. I just picked the ones that weren't enabled. I may have missed the --without-skins2 option though :\... -Garrett Thanks alot guys.. The options that worked for me ( to install text only vlc) are: ./configure --disable-x11 --disable-xvideo --disable-glx --disable-sdl --disable-sd --disable-wxwidgets --disable-skins2 --disable-freetype --disable-mad --disable-ffmpeg -- OKALANY DANIEL P.O BOX 26150 KAMPALA. http://okaman.one2net.co.ug -- Youth is a wonderful thing. What a crime to waste it on children. The Word was spoken before it was written, and it was written so it could be spoken! Words can move mountais because mountains are created by words! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc versions following upgrade 6.3 7.0
On Tuesday 22 July 2008 01:16:30 Jeremy Chadwick wrote:
On Tue, Jul 22, 2008 at 01:07:53AM -0700, David Southwell wrote:
On Monday 21 July 2008 23:27:49 Garrett Cooper wrote:
On Mon, Jul 21, 2008 at 4:09 AM, Jeremy Chadwick [EMAIL PROTECTED]
wrote:
On Mon, Jul 21, 2008 at 03:11:25AM -0700, [EMAIL PROTECTED] wrote:
FreeBSD **.vizion2000.net 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jul
16 09:27:38 PDT 2008
@**.vizion2000.net:/usr/obj/usr/src/sys/GENERIC amd64 # pkg_info
|grep gcc
gcc-4.1.3_20080630 GNU Compiler Collection 4.1
gcc-4.2.5_20080702 GNU Compiler Collection 4.2
gccmakedep-1.0.2Create dependencies in makefiles using 'gcc -M'
Should both versions be installed?
That depends. Are you using any ports which depend on specific
versions of GCC? The base system version comes with gcc 4.2.1.
There may be ports which require older or newer GCC, however.
pkg_info -R should help you determine what ports are dependant upon
those two GCC ports.
There isn't anything wrong with having multiple compilers installed on
a given system, insomuch as they install within separate directories
or are prefixed differently. The sym-/hard-links for the compiler last
installed may be the one that gets used though (not sure because I
don't have any experience installing gcc from ports on FreeBSD)...
Do they not place files in same place?
No.
This ties into the reply above, but if you have a compiler provided by
the base system and a compiler provided by ports, they won't install
in the same location, as ${PREFIX} dictates in ports.
-Garrett
What happens, as in this instance, the system was originally on 6.1 then
6.3 subsequently upgraded to 7.0?
How can I tell whether the versions were installed by the base system or
via ports?
The base system does not add anything to the ports/pkg database. The
reason you have gcc 4.1.3 and gcc 4.2.5 on your machine is because some
other port/package depended/depends on them. pkg_info -R will solve
that mystery.
As I said before: some ports/packages may require a newer (or older)
version of GCC, in which case, you'll end up with two (or more) versions
of gcc on your system -- one in the base and one (or more) managed via
ports.
Regardless of what Garrett and others say about how multiple compilers
on a system works great, I do not advocate it. There are many catches
which can/will surprise you down the road, especially with regards to
library linking order, symbol versioning, and a couple other things.
I'm sorry, but in my eyes it's risky behaviour. We've been down this
road before back when perl was in the base system, for similar reasons.
This spawns the whole base vs. ports discussion. For the record, I am
one of the minority who wants to do away with the entire base system
concept. I do not want this thread to start discussing that, though;
let's stay on topic. I just wanted to point it out so that you have
some idea of *why* I say what I do.
I am not clear about how the system distinguishes between gcc installed
via ports and via base system. Indcidentally when did gcc become part of
the base system?
It always has been part of the base system, since at least FreeBSD 2.x
days. I can't speak for 1.x because I wasn't using FreeBSD then.
Use pkg_info -R gcc-4.1.3_20080630 to see what ports are reliant upon
gcc 4.1.3, and rebuild those ports now that you've upgraded to FreeBSD 7
(which includes gcc 4.2.1 in the base system). FreeBSD 6 had gcc 3.4.6,
which is why some ports might have wanted something newr.
Does all of this now make sense?
Makes a very great deal of sense. During a portupgrade -frR ruby*
(necessitated following a power out during a portupgrade!!!) I had a consol
message about the two versions of gcc causing a conflict. The conflict was
resolved by the upgrades. It was that message that started my enquiry. The
dependencies in 4.1_3 have now been removed from pkgdb following the
portupgrade and that version deinstalled.
Thank you, and everyone else, for taking the time to answer my question.
David
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Managing bsdpan
The following portsupgrade reports for bsdpan lead me to ask a few trivial questions and suggestions (see below) [Updating the pkgdb format:bdb_btree in /var/db/pkg ... - 1012 packages found (-0 +1) . done] --- Skipping 'bsdpan-libnet-1.21' because it is held by user (specify -f to force) --- Skipping 'devel/p5-Devel-Symdump' because it is held by user (specify -f to force) --- Skipping 'bsdpan-DB_File-1.817' because it is held by user (specify -f to force) --- Skipping 'bsdpan-ANSIColor-1.12' because it is held by user (specify -f to force) --- Skipping 'textproc/p5-Text-Balanced' because it is held by user (specify -f to force) --- Skipping 'bsdpan-File-Path-2.04' because it is held by user (specify -f to force) --- Skipping 'bsdpan-CPAN-1.9205' because it is held by user (specify -f to force) --- Skipping 'www/p5-CGI.pm' because it is held by user (specify -f to force) --- Skipping 'bsdpan-Safe-2.16' because it is held by user (specify -f to force) --- Skipping 'bsdpan-B-Lint-1.11' because it is held by user (specify -f to force) --- Skipping 'bsdpan-Shell-0.72' because it is held by user (specify -f to force) --- Skipping 'bsdpan-Thread-Semaphore-2.09' because it is held by user (specify -f to force) --- Skipping 'bsdpan-Text-Soundex-3.03' because it is held by user (specify -f to force) --- Skipping 'bsdpan-IPC-SysV-2.00' because it is held by user (specify -f to force) --- Skipping 'bsdpan-SelfLoader-1.15' because it is held by user (specify -f to force) --- Skipping 'bsdpan-Term-ReadLine-Perl-1.0302' because it is held by user (specify -f to force) --- Skipping 'bsdpan-libwww-perl-5.813' because it is held by user (specify -f to force) --- Skipping 'misc/p5-Array-Compare' because it is held by user (specify -f to force) --- Skipping 'bsdpan-B-Debug-1.10' because it is held by user (specify -f to force) ** Listing the failed packages (-:ignored / *:skipped / !:failed) - (bsdpan-constant-1.15) - (bsdpan-MailTools-2.03) - (bsdpan-CPAN-1.9102) - (bsdpan-Term-Cap-1.12) - (bsdpan-Exporter-5.62) - (bsdpan-Thread-Queue-2.11) - devel/p5-IO (bsdpan-IO-1.23) - (bsdpan-CPAN-1.9203) - (bsdpan-libnet-1.21) - devel/p5-Devel-Symdump (bsdpan-Devel-Symdump-2.08) - (bsdpan-DB_File-1.817) - (bsdpan-ANSIColor-1.12) - textproc/p5-Text-Balanced (bsdpan-Text-Balanced-undef) - (bsdpan-File-Path-2.04) - (bsdpan-CPAN-1.9205) - www/p5-CGI.pm (bsdpan-CGI.pm-3.38) - (bsdpan-Safe-2.16) - (bsdpan-B-Lint-1.11) - (bsdpan-Shell-0.72) - (bsdpan-Thread-Semaphore-2.09) - (bsdpan-Text-Soundex-3.03) - (bsdpan-IPC-SysV-2.00) - (bsdpan-SelfLoader-1.15) - (bsdpan-Term-ReadLine-Perl-1.0302) - (bsdpan-libwww-perl-5.813) - misc/p5-Array-Compare (bsdpan-Array-Compare-1.15) - (bsdpan-B-Debug-1.10) # /usr/ports/ 1. why are some packages listed in the format: - isc/p5-Array-Compare (bsdpan-Array-Compare-1.15) rather than: - (bsdpan-libwww-perl-5.813) Is this indicative of an inconsistency in my system administration or inconsistencies between package make files? 2. There is another question on similar lines because some packages helpfully show the hierarchy in the ports tree etc: devel/*** rather than simply *** 3. In regard to bsdpan apropos generates: # apropos bsdpan bsdpan: nothing appropriate # 4. A search on freebsd website under bsdpan brings reference to the inclusion of bsdpan in the ports distribution but not to any documentation on its use. 5. # locate bsdpan brings a list of bsdpan packages in /var/db/pkg but no other files documentation etc. 6. My guess is that there are some guidelines for constructing bsdpan pkgs and for using the bsdpan? If it does exist could anyone tell me where it is? 7 If something does exist could it be incorporated into the ports tree e.g ports/BSDPAN_README for holding general guidelines about using the BSDPAN and covering such issues as advice about holding packages etc. 8. Might the ports tree also provide a central point of information about BSDPAN ports updates e.g ports/BSDPAN_UPDATING. This would be particluarly valuable as the ports themselves are distributed around the ports tree. 9. Would not a current index of BSDPAN ports e.g ports/BSDPAN_INDEX including a short description also be useful? David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Ports Database - Update failure
Hello,
Reporting failure in Updating the Ports Database
Second run, used pre-generated version of INDEX , I think everything is as
defined in failure message
FreeBSD econ.com 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Tue Oct 17 05:16:31 PDT
2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMATUK_KERNEL i386
My portupgrade is at
/usr/ports/ports-mgmt/portupgrade not at
/usr/ports/sysutils/portupgrade ...?
Ports Tree sync'd with supfile
*default host=cvsup.ca.freebsd.org
*default base=/usr/local/etc/cvsup
*default prefix=/usr
*default release=cvs tag=RELENG_6
*default release=cvs delete use-rel-suffix compress
ports-all tag=.
cvsup -g -L 2 /usr/local/sup/supfile =
---
---
---
Running
Updating collection ports-all/cvs
Edit ports/ports-mgmt/portmk/Mk/bsd.port.mk
Add delta 1.76 2008.07.22.04.33.47 linimon
Shutting down connection to server
Finished successfully
portsdb -Uu
cd: can't cd to /usr/ports/sysutils/portupgrade
Updating the ports index ... Generating INDEX.tmp - please wait..Makefile,
line 55: Could not find bsd.port.options.mk
make: fatal errors encountered -- cannot continue
=== sysutils/apcupsd failed
*** Error code 1
1 error
Before reporting this error, verify that you are running a supported
version of FreeBSD (see
http://www.FreeBSD.org/ports/http://www.freebsd.org/ports/)
and that you
have a complete and up-to-date ports collection. (INDEX builds are
not supported with partial or out-of-date ports collections -- in
particular, if you are using cvsup, you must cvsup the ports-all
collection, and have no refuse files.) If that is the case, then
report the failure to [EMAIL PROTECTED] together with relevant
details of your ports configuration (including FreeBSD version,
your architecture, your environment, and your /etc/make.conf
settings, especially compiler flags and WITH/WITHOUT settings).
Note: the latest pre-generated version of INDEX may be fetched
automatically with make fetchindex.
*** Error code 1
Stop in /usr/ports.
*** Error code 1
Stop in /usr/ports.
failed to generate INDEX!
portsdb: index generation error
--
ll /usr/ports/INDEX
-rw-r--r-- 1 root 100 17645575 Jul 22 01:28 /usr/ports/INDEX
Index.db is created
file /usr/ports/INDEX.db
/usr/ports/INDEX.db: Berkeley DB 1.85/1.86 (Btree, version 3, native
byte-order)
econ 1576# ll /usr/ports/INDEX.db
-rw-r--r-- 1 root 100 28423168 Jul 22 03:14 /usr/ports/INDEX.db
--
cat /etc/make.conf
# added by use.perl 2006-10-11 13:23:36
PERL_VER=5.8.7
PERL_VERSION=5.8.7
X11BASE=${LOCALBASE}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Managing bsdpan
On Tuesday 22 July 2008 05:42:05 Volodymyr Kostyrko wrote: David Southwell wrote: The following portsupgrade reports for bsdpan lead me to ask a few trivial questions and suggestions (see below) 1. why are some packages listed in the format: - isc/p5-Array-Compare (bsdpan-Array-Compare-1.15) rather than: - (bsdpan-libwww-perl-5.813) Ports tree contains the port for the given package and knows its correct name. Is this indicative of an inconsistency in my system administration or inconsistencies between package make files? Maybe. to which option does your maybe apply?? 2. There is another question on similar lines because some packages helpfully show the hierarchy in the ports tree etc: devel/*** rather than simply *** Why 'devel/'? There's no confidence that thees packages have their corresponding ports. I do not think you read carefully. Some packages are reported for example as: - devel/p5-Devel-Symdump (bsdpan-Devel-Symdump-2.08) others as - (bsdpan-DB_File-1.817) In other words some show the BSDPAN package location in the port hierarchy others do not. The former method seems more useful. Please note that bsdpan-* is not a port name or part of it. It's the name of installed package. I do not agree. BSDPAN is the name that is used by and referred to in freebsd documentation as the system by which cpan ports are incorporated into the frebsd ports tree. The package are the ports. bsdpan is not the name of a port. 3. In regard to bsdpan apropos generates: # apropos bsdpan bsdpan: nothing appropriate # True. Perl packages installed directly from bsdpan or from tarballs automatically do create corresponding package entry in '/var/db/pkg'. How kind of them, really. 4. A search on freebsd website under bsdpan brings reference to the inclusion of bsdpan in the ports distribution but not to any documentation on its use. I think I have not explained clearly. I did not mean how to use the individual port but how to manage perl ports that are installed via BSDPAN. For example the appropriateness of holding packages. I'm not a perl junkie. Try hitting CPAN instead. 5. # locate bsdpan brings a list of bsdpan packages in /var/db/pkg but no other files documentation etc. True. See 3. 7 If something does exist could it be incorporated into the ports tree e.g ports/BSDPAN_README for holding general guidelines about using the BSDPAN and covering such issues as advice about holding packages etc. Not by me, really. Try to invetigate this and write it down then propose it for inclusion. 9. Would not a current index of BSDPAN ports e.g ports/BSDPAN_INDEX including a short description also be useful? Reply hazy. Ports ain't really the correct place for this staff. Try hitting CPAN. freebsd ports may not have an equivalent for all items listed in cpan. I am thinking of simply an index which list the bsdpan path/portname showing the equivalent cpan port names versions, This file could be updated whenever a bsdpan port is committed and maintained in the same way as ports/ UPDATING. PS: Personally I don't accept the possibility of installation of unhandled / unmaintained software (e.g. not found in ports) on any hardware supervised by me. Any piece of junk which need to be installed and maintained should have a corresponding person, responsible for it freshness and usability. Agree I do not htink anyone has suggested that - I do not think you have read carefully. -- The assumption is that everything in the ports tree must fall in that category. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Managing bsdpan
David Southwell wrote: On Tuesday 22 July 2008 05:42:05 Volodymyr Kostyrko wrote: David Southwell wrote: The following portsupgrade reports for bsdpan lead me to ask a few trivial questions and suggestions (see below) 1. why are some packages listed in the format: - isc/p5-Array-Compare (bsdpan-Array-Compare-1.15) rather than: - (bsdpan-libwww-perl-5.813) Ports tree contains the port for the given package and knows its correct name. Is this indicative of an inconsistency in my system administration or inconsistencies between package make files? Maybe. to which option does your maybe apply?? I just don't know why in your example bsdpan-libwww-perl-5.813 wasn't mapped to www/p5-libwww and so on. 2. There is another question on similar lines because some packages helpfully show the hierarchy in the ports tree etc: devel/*** rather than simply *** Why 'devel/'? There's no confidence that thees packages have their corresponding ports. I do not think you read carefully. Some packages are reported for example as: - devel/p5-Devel-Symdump (bsdpan-Devel-Symdump-2.08) others as - (bsdpan-DB_File-1.817) In other words some show the BSDPAN package location in the port hierarchy others do not. The former method seems more useful. There's some misunderstanding here... Packages are not ports. In your example we have ' - [port name] (package name)' syntax, but this doesn't state that any port name installs package name. Just try it yourself - the package name when build from the ports would be 'p5-Devel-Symdump-2.0800'. This explicitly states that your installed package wasn't built from ports, but have a proper port to be installed/upgraded/replaced with. As for other lines ports system fail to identify corresponding ports. Please note that bsdpan-* is not a port name or part of it. It's the name of installed package. I do not agree. BSDPAN is the name that is used by and referred to in freebsd documentation as the system by which cpan ports are incorporated into the frebsd ports tree. The package are the ports. bsdpan is not the name of a port. *Curios*. Citacion needed. Quick search through the handbook gives me nothing on 'bsdpan' at all. There's nothing on official site either except: BSDPAN, a collection of modules that provides tighter integration of Perl into the FreeBSD Ports Collection, has been added. in 5.0 relnotes. Again packages are not ports, they are really different beasts. 3. In regard to bsdpan apropos generates: # apropos bsdpan bsdpan: nothing appropriate # True. Perl packages installed directly from bsdpan or from tarballs automatically do create corresponding package entry in '/var/db/pkg'. How kind of them, really. 4. A search on freebsd website under bsdpan brings reference to the inclusion of bsdpan in the ports distribution but not to any documentation on its use. I think I have not explained clearly. I did not mean how to use the individual port but how to manage perl ports that are installed via BSDPAN. For example the appropriateness of holding packages. Human cause. If someone uses this package personally. Any software which comes from ports do have complete dependency tree in ports also so none of that packages are actually needed. Or in case some packages from ports were installed after having these ones installed from CPAN you can safely delete them and use 'pkgdb -F' to correct any dependency errors found. Just in case. Some software do have a weird preference to interfere with package building. This means webmin changing rc.d scripts for installed packages. This means web hosting software trying to move in packages users requested. This means other web hosting software trying to support it's own pile of binaries. In this cases you should be aware of such things and count yourself as their personal user. I'm not a perl junkie. Try hitting CPAN instead. 5. # locate bsdpan brings a list of bsdpan packages in /var/db/pkg but no other files documentation etc. True. See 3. 7 If something does exist could it be incorporated into the ports tree e.g ports/BSDPAN_README for holding general guidelines about using the BSDPAN and covering such issues as advice about holding packages etc. Not by me, really. Try to invetigate this and write it down then propose it for inclusion. 9. Would not a current index of BSDPAN ports e.g ports/BSDPAN_INDEX including a short description also be useful? Reply hazy. Ports ain't really the correct place for this staff. Try hitting CPAN. freebsd ports may not have an equivalent for all items listed in cpan. I am thinking of simply an index which list the bsdpan path/portname showing the equivalent cpan port names versions, This file could be updated whenever a bsdpan port is committed and maintained in the same way as ports/ UPDATING. I think this way we result in local equivalent of 'grep ^p5- /usr/ports/INDEX-*' -- Sphinx of black quartz judge my vow.
Re: Managing bsdpan
On Tuesday 22 July 2008 07:00:09 Volodymyr Kostyrko wrote: David Southwell wrote: On Tuesday 22 July 2008 05:42:05 Volodymyr Kostyrko wrote: David Southwell wrote: The following portsupgrade reports for bsdpan lead me to ask a few trivial questions and suggestions (see below) 1. why are some packages listed in the format: - isc/p5-Array-Compare (bsdpan-Array-Compare-1.15) rather than: - (bsdpan-libwww-perl-5.813) Ports tree contains the port for the given package and knows its correct name. Is this indicative of an inconsistency in my system administration or inconsistencies between package make files? Maybe. to which option does your maybe apply?? I just don't know why in your example bsdpan-libwww-perl-5.813 wasn't mapped to www/p5-libwww and so on. Exactlky my point.. the system is not consistent!!! My guess is it is not consistent because there are no references for how BSDPAN is meant to work. 2. There is another question on similar lines because some packages helpfully show the hierarchy in the ports tree etc: devel/*** rather than simply *** Why 'devel/'? There's no confidence that thees packages have their corresponding ports. I do not think you read carefully. Some packages are reported for example as: - devel/p5-Devel-Symdump (bsdpan-Devel-Symdump-2.08) others as - (bsdpan-DB_File-1.817) In other words some show the BSDPAN package location in the port hierarchy others do not. The former method seems more useful. There's some misunderstanding here... Packages are not ports. In your example we have ' - [port name] (package name)' syntax, but this doesn't state that any port name installs package name. Just try it yourself - the package name when build from the ports would be 'p5-Devel-Symdump-2.0800'. This explicitly states that your installed package wasn't built from ports, but have a proper port to be installed/upgraded/replaced with. As for other lines ports system fail to identify corresponding ports. Let us be careful here.. the fact that they appear in the ports hierarchy means they get referred to as ports. The intention seems to be to maintain consistency with the rest of the ports system. It may be a bit of a kludge but it needs to be systematic if it is going to be easily understood. The reason I have drawn attention to a few of the inconsistebncies is because the lack of consistency makes it difficult to understand, explain and manage. Please note that bsdpan-* is not a port name or part of it. It's the name of installed package. I do not agree. BSDPAN is the name that is used by and referred to in freebsd documentation as the system by which cpan ports are incorporated into the frebsd ports tree. The package are the ports. bsdpan is not the name of a port. *Curios*. Citacion needed. Quick search through the handbook gives me nothing on 'bsdpan' at all. There's nothing on official site either except: BSDPAN, a collection of modules that provides tighter integration of Perl into the FreeBSD Ports Collection, has been added. in 5.0 relnotes. Again packages are not ports, they are really different beasts. Like I said trying to make perl modules constent with the ports system. 3. In regard to bsdpan apropos generates: # apropos bsdpan bsdpan: nothing appropriate # So a wonderful introduction in freebsd documentationbut no further details to follow up the introduction. True. Perl packages installed directly from bsdpan or from tarballs automatically do create corresponding package entry in '/var/db/pkg'. How kind of them, really. 4. A search on freebsd website under bsdpan brings reference to the inclusion of bsdpan in the ports distribution but not to any documentation on its use. I think I have not explained clearly. I did not mean how to use the individual port but how to manage perl ports that are installed via BSDPAN. For example the appropriateness of holding packages. Human cause. If someone uses this package personally. Any software which comes from ports do have complete dependency tree in ports also so none of that packages are actually needed. Or in case some packages from ports were installed after having these ones installed from CPAN you can safely delete them and use 'pkgdb -F' to correct any dependency errors found. Just in case. Some software do have a weird preference to interfere with package building. This means webmin changing rc.d scripts for installed packages. This means web hosting software trying to move in packages users requested. This means other web hosting software trying to support it's own pile of binaries. In this cases you should be aware of such things and count yourself as their personal user. I'm not a perl junkie. Try hitting CPAN instead. 5. # locate bsdpan brings a list of bsdpan packages in /var/db/pkg but no other files documentation etc. True. See 3. 7 If
Re: Managing bsdpan
David Southwell wrote: 2. There is another question on similar lines because some packages helpfully show the hierarchy in the ports tree etc: devel/*** rather than simply *** Why 'devel/'? There's no confidence that thees packages have their corresponding ports. I do not think you read carefully. Some packages are reported for example as: - devel/p5-Devel-Symdump (bsdpan-Devel-Symdump-2.08) others as - (bsdpan-DB_File-1.817) In other words some show the BSDPAN package location in the port hierarchy others do not. The former method seems more useful. There's some misunderstanding here... Packages are not ports. In your example we have ' - [port name] (package name)' syntax, but this doesn't state that any port name installs package name. Just try it yourself - the package name when build from the ports would be 'p5-Devel-Symdump-2.0800'. This explicitly states that your installed package wasn't built from ports, but have a proper port to be installed/upgraded/replaced with. As for other lines ports system fail to identify corresponding ports. Let us be careful here.. the fact that they appear in the ports hierarchy means they get referred to as ports. Nope. Most of em' won't appear in ports anyway. Not all modules from CPAN have correspondent FreeBSD ports. This way when such an orphan package is installed bsdpan creates a proper package entry. And one more thing, they are referred _to_ ports, not referred _to as_ ports. The intention seems to be to maintain consistency with the rest of the ports system. It may be a bit of a kludge but it needs to be systematic if it is going to be easily understood. The reason I have drawn attention to a few of the inconsistebncies is because the lack of consistency makes it difficult to understand, explain and manage. I agree with you. That's why I personally would avoid at all possibility installing anything (as packages or bunch of files) if there's no such port in the tree. Please note that bsdpan-* is not a port name or part of it. It's the name of installed package. I do not agree. BSDPAN is the name that is used by and referred to in freebsd documentation as the system by which cpan ports are incorporated into the frebsd ports tree. The package are the ports. bsdpan is not the name of a port. *Curios*. Citacion needed. Quick search through the handbook gives me nothing on 'bsdpan' at all. There's nothing on official site either except: BSDPAN, a collection of modules that provides tighter integration of Perl into the FreeBSD Ports Collection, has been added. in 5.0 relnotes. Again packages are not ports, they are really different beasts. Like I said trying to make perl modules constent with the ports system. You are free to go. Submitting patches would be the fastest way around. I'm not a perl junkie. Try hitting CPAN instead. 5. # locate bsdpan brings a list of bsdpan packages in /var/db/pkg but no other files documentation etc. True. See 3. 7 If something does exist could it be incorporated into the ports tree e.g ports/BSDPAN_README for holding general guidelines about using the BSDPAN and covering such issues as advice about holding packages etc. Not by me, really. Try to invetigate this and write it down then propose it for inclusion. 9. Would not a current index of BSDPAN ports e.g ports/BSDPAN_INDEX including a short description also be useful? Reply hazy. Ports ain't really the correct place for this staff. Try hitting CPAN. freebsd ports may not have an equivalent for all items listed in cpan. I am thinking of simply an index which list the bsdpan path/portname showing the equivalent cpan port names versions, This file could be updated whenever a bsdpan port is committed and maintained in the same way as ports/ UPDATING. I think this way we result in local equivalent of 'grep ^p5- /usr/ports/INDEX-*' This does not deal with discrepancies between versions as list in freebsd ports index and cpan index... Things are not that simple. Try yelling at port maintainers. Most CPAN ports in tree are named like correspondent bsdpan packages. If some are not - only the maintainer can give you a clue why would that happen. -- Sphinx of black quartz judge my vow. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vlc
On Tue, Jul 22, 2008 at 1:32 AM, Okalany Daniel [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 10:47 PM, Garrett Cooper [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 3:01 AM, Rafaël Carré [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008, Peter Pentchev wrote: On Fri, Jul 18, 2008 at 01:46:53PM +0300, Okalany Daniel wrote: On Fri, Jul 18, 2008 at 1:14 PM, Garrett Cooper [EMAIL PROTECTED] wrote: [snip] The following options will need to be passed into configure: If you feel so, you can make all these options conditional on WITHOUT_X and send me a patch ;) i.e. for skins2 that would be: .if defined(WITH_SKINS) !defined(WITHOUT_SKINS) !defined(WITHOUT_X) [snip] --disable-freetype Okalany, you seem to have missed this one :) yep --disable-skins These days this option has no effect, it's now named skins2. --disable-skins2 should solve your problem --disable-freetype will build a skins2 interface without freetype support, but I guess it will fail to build anyway because it needs X11 It cofigures okay, but the make fails with In file included from ../../../include/vlc/intf.h:39, parser/../src/ft2_font.hpp: At global scope: parser/../src/ft2_font.hpp:60: error: 'FT_Glyph' does not name a type parser/../src/ft2_font.hpp:61: error: 'FT_BBox' does not name a type parser/../src/ft2_font.hpp:74: error: 'FT_Library' does not name a type parser/../src/ft2_font.hpp:76: error: 'FT_Face' does not name a type Yep, FreeType symbols - see above, you missed an option :) These are the skins2 files Actually if you read through ./configure --help not all options are enabled. I just picked the ones that weren't enabled. I may have missed the --without-skins2 option though :\... -Garrett Thanks alot guys.. The options that worked for me ( to install text only vlc) are: ./configure --disable-x11 --disable-xvideo --disable-glx --disable-sdl --disable-sd --disable-wxwidgets --disable-skins2 --disable-freetype --disable-mad --disable-ffmpeg Hi, I'm contacting you because you are listed as the maintainer on Freshports for the multimedia/vlc port for FreeBSD. The user cited above, Okalany, was interested in compiling VLC without X11 support to act as a multimedia server, but currently the port doesn't allow for that type of functionality at this time. However, Okalany was able to get the source to compile without X11 using the above options to configure (don't believe the --disable-mad and --disable-ffmpeg options are required, but you probably know better than us about that :)...), so we were wondering whether or not the port could be modified to add a WITHOUT_X11 knob. Thanks and we hope to hear back from you soon, -Garrett, Okalany, et all ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc versions following upgrade 6.3 7.0
On Tue, Jul 22, 2008 at 1:16 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 01:07:53AM -0700, David Southwell wrote: The base system does not add anything to the ports/pkg database. The reason you have gcc 4.1.3 and gcc 4.2.5 on your machine is because some other port/package depended/depends on them. pkg_info -R will solve that mystery. As I said before: some ports/packages may require a newer (or older) version of GCC, in which case, you'll end up with two (or more) versions of gcc on your system -- one in the base and one (or more) managed via ports. Regardless of what Garrett and others say about how multiple compilers on a system works great, I do not advocate it. There are many catches which can/will surprise you down the road, especially with regards to library linking order, symbol versioning, and a couple other things. I'm sorry, but in my eyes it's risky behaviour. We've been down this road before back when perl was in the base system, for similar reasons. The complication and mess stems from the fact that you'll need to compile components using an absolute prefix to the compiler or have a script which manages gcc and the binutils as a series of symlinks (Gentoo Linux does that). Not all projects unfortunately have wizened up to the fact that keeping something cross-compile safe is the best way to go so things may fail unless you have robust compile tools scripts to help manage everything. Cheers, -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vlc
2008/7/22 Garrett Cooper [EMAIL PROTECTED]: On Tue, Jul 22, 2008 at 1:32 AM, Okalany Daniel [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 10:47 PM, Garrett Cooper [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 3:01 AM, Rafaël Carré [EMAIL PROTECTED] wrote: If you feel so, you can make all these options conditional on WITHOUT_X and send me a patch ;) i.e. for skins2 that would be: .if defined(WITH_SKINS) !defined(WITHOUT_SKINS) !defined(WITHOUT_X) That is the way to go in my opinion. Thanks alot guys.. The options that worked for me ( to install text only vlc) are: ./configure --disable-x11 --disable-xvideo --disable-glx --disable-sdl --disable-sd --disable-wxwidgets --disable-skins2 --disable-freetype --disable-mad --disable-ffmpeg Do you have libX11 installed anyway on your system ? It would be clever to build VLC the same way on a system with libX11 and then verify each .so built, to see if they are not linked with libX11. That is to be sure autodetection will not enable something you don't want, i.e. not enabled if libX11 was not detected, but enabled if it was detected. If this is the case, that would mean more --disable-xx are required. The debian people verify each plugin (prefix/lib/vlc/**.so) when building vlc-nox package. Extract from debian/rules : # Check that we did not install a plugin linked with libX11 in vlc-nox ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) BORKED=no; \ for file in $$(find debian/vlc-nox/usr/lib/vlc -name '*.so'); do \ if ldd $$file | grep -q libX11; then \ BORKED=yes; \ echo $$file depends on libX11; \ fi; \ done; \ if test $$BORKED = yes; then exit 1; fi endif Hi, I'm contacting you because you are listed as the maintainer on Freshports for the multimedia/vlc port for FreeBSD. The user cited above, Okalany, was interested in compiling VLC without X11 support to act as a multimedia server, but currently the port doesn't allow for that type of functionality at this time. Ok However, Okalany was able to get the source to compile without X11 using the above options to configure (don't believe the --disable-mad and --disable-ffmpeg options are required, but you probably know better than us about that :)...), so we were wondering whether or not the port could be modified to add a WITHOUT_X11 knob. Of course, but I am lazy to do the patch, so you have to do the work :) However I'm glad to help if you have trouble Thanks and we hope to hear back from you soon, -Garrett, Okalany, et all -- Rafaël Carré ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc versions following upgrade 6.3 7.0
On Tuesday 22 July 2008 08:16:38 Garrett Cooper wrote: On Tue, Jul 22, 2008 at 1:16 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Tue, Jul 22, 2008 at 01:07:53AM -0700, David Southwell wrote: The base system does not add anything to the ports/pkg database. The reason you have gcc 4.1.3 and gcc 4.2.5 on your machine is because some other port/package depended/depends on them. pkg_info -R will solve that mystery. As I said before: some ports/packages may require a newer (or older) version of GCC, in which case, you'll end up with two (or more) versions of gcc on your system -- one in the base and one (or more) managed via ports. Regardless of what Garrett and others say about how multiple compilers on a system works great, I do not advocate it. There are many catches which can/will surprise you down the road, especially with regards to library linking order, symbol versioning, and a couple other things. I'm sorry, but in my eyes it's risky behaviour. We've been down this road before back when perl was in the base system, for similar reasons. The complication and mess stems from the fact that you'll need to compile components using an absolute prefix to the compiler or have a script which manages gcc and the binutils as a series of symlinks (Gentoo Linux does that). Not all projects unfortunately have wizened up to the fact that keeping something cross-compile safe is the best way to go so things may fail unless you have robust compile tools scripts to help manage everything. Cheers, -Garrett Thanks guys this has been very interesting discussion. I have learnt quite a bit. David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vlc
On Jul 22, 2008, at 8:46 AM, Rafaël Carré wrote: 2008/7/22 Garrett Cooper [EMAIL PROTECTED]: On Tue, Jul 22, 2008 at 1:32 AM, Okalany Daniel [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 10:47 PM, Garrett Cooper [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 3:01 AM, Rafaël Carré [EMAIL PROTECTED] wrote: If you feel so, you can make all these options conditional on WITHOUT_X and send me a patch ;) i.e. for skins2 that would be: .if defined(WITH_SKINS) !defined(WITHOUT_SKINS) !defined(WITHOUT_X) That is the way to go in my opinion. Thanks alot guys.. The options that worked for me ( to install text only vlc) are: ./configure --disable-x11 --disable-xvideo --disable-glx --disable- sdl --disable-sd --disable-wxwidgets --disable-skins2 --disable-freetype --disable-mad --disable-ffmpeg Do you have libX11 installed anyway on your system ? It would be clever to build VLC the same way on a system with libX11 and then verify each .so built, to see if they are not linked with libX11. That is to be sure autodetection will not enable something you don't want, i.e. not enabled if libX11 was not detected, but enabled if it was detected. If this is the case, that would mean more --disable-xx are required. The debian people verify each plugin (prefix/lib/vlc/**.so) when building vlc-nox package. Extract from debian/rules : # Check that we did not install a plugin linked with libX11 in vlc-nox ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) BORKED=no; \ for file in $$(find debian/vlc-nox/usr/lib/vlc -name '*.so'); do \ if ldd $$file | grep -q libX11; then \ BORKED=yes; \ echo $$file depends on libX11; \ fi; \ done; \ if test $$BORKED = yes; then exit 1; fi endif Hi, I'm contacting you because you are listed as the maintainer on Freshports for the multimedia/vlc port for FreeBSD. The user cited above, Okalany, was interested in compiling VLC without X11 support to act as a multimedia server, but currently the port doesn't allow for that type of functionality at this time. Ok However, Okalany was able to get the source to compile without X11 using the above options to configure (don't believe the --disable-mad and --disable-ffmpeg options are required, but you probably know better than us about that :)...), so we were wondering whether or not the port could be modified to add a WITHOUT_X11 knob. Of course, but I am lazy to do the patch, so you have to do the work :) However I'm glad to help if you have trouble Thanks and we hope to hear back from you soon, -Garrett, Okalany, et all Rafael: Ah, didn't realize that was you. rofl... As the saying goes, good thing you weren't a snake -- otherwise I'd be dead =o I'll fix up a patch for you soon. Okalany: Do this on a compiled tree please -- sh -c 'for i in `find -type f`; if ldd $i | grep -q libX11; then echo $i depends on libX11.so; fi; done' Cheers, -Garrett___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/125169: [PATCH] www/xpi-noscript: update to 1.7.4
Hello. Would someone please commit this PR with maintainer timeout? Regards. --- Yasuhiro KIMURA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ports/125625: [PATCH] dns/nsd: USE_RC_SUBR != yes
Why has committing a patch gotten so complicated? --Original Message-- From: [EMAIL PROTECTED] To: Ólafur Osvaldsson To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Jul 22, 2008 22:17 Subject: Re: ports/125625: [PATCH] dns/nsd: USE_RC_SUBR != yes Synopsis: [PATCH] dns/nsd: USE_RC_SUBR != yes Responsible-Changed-From-To: araujo-pgollucci Responsible-Changed-By: pgollucci Responsible-Changed-When: Tue Jul 22 22:17:49 UTC 2008 Responsible-Changed-Why: Submitter has gants access http://www.freebsd.org/cgi/query-pr.cgi?pr=125625 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Help for a problematic port to replace biology/nab
I am the maintainer of biology/nab and asked that it be marked deprecated several months ago. I just filed a PR to have it removed. Nab has been superseded by AmberTools (also by the nab developers). I have the current version of AmberTools building with no problems from within a skeleton port. The problem (and I do not see any solution) is that AmberTools assumes that it will be built in its final installed location. This location is hardwired throughout the compiled code. The build process fails spectacularly if you specify some other location, then move the built code and data. Is there some secret method to handle such ports for which I do not possess the magical decoder ring? Any help would be appreciated. Bud Dodson -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: openldap-server-2.4.10
Xin LI wrote: [...] I have committed these changes as part of OpenLDAP 2.4.11, thanks for your submission! A line that isn't supposed to exist is still present in 2.4.11. When compiling from ports the DATABASEDIR is still created. The line: @-$(INSTALL) -m 700 -d $(DESTDIR)$(localstatedir)/openldap-data The working patch: --- patch-servers::slapd::Makefile.in.orig 2008-07-22 19:29:17.0 + +++ patch-servers::slapd::Makefile.in 2008-07-22 19:34:37.0 + @@ -1,5 +1,5 @@ servers/slapd/Makefile.in.orig 2008-02-11 15:26:43.0 -0800 -+++ servers/slapd/Makefile.in 2008-07-19 20:10:16.023473779 -0700 +--- servers/slapd/Makefile.in.orig 2008-02-11 23:26:43.0 + servers/slapd/Makefile.in 2008-07-22 19:25:03.0 + @@ -374,7 +374,6 @@ install-slapd: FORCE @@ -33,12 +33,13 @@ done install-conf: FORCE -@@ -432,8 +433,6 @@ +@@ -430,9 +431,6 @@ + + install-db-config: FORCE @-$(MKDIR) $(DESTDIR)$(localstatedir) $(DESTDIR)$(sysconfdir) - @-$(INSTALL) -m 700 -d $(DESTDIR)$(localstatedir)/openldap-data - $(INSTALL) $(INSTALLFLAGS) -m 600 $(srcdir)/DB_CONFIG \ -- $(DESTDIR)$(localstatedir)/openldap-data/DB_CONFIG.example +- @-$(INSTALL) -m 700 -d $(DESTDIR)$(localstatedir)/openldap-data - $(INSTALL) $(INSTALLFLAGS) -m 600 $(srcdir)/DB_CONFIG \ +- $(DESTDIR)$(localstatedir)/openldap-data/DB_CONFIG.example + $(INSTALL) $(INSTALLFLAGS) -m 600 $(srcdir)/DB_CONFIG \ $(DESTDIR)$(sysconfdir)/DB_CONFIG.example - install-tools: FORCE Once again, thanks! Regards, Mikhail. -- Mikhail Goriachev Webanoide ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help for a problematic port to replace biology/nab
On Tue, Jul 22, 2008 at 06:40:15PM -0500, M. L. Dodson wrote: I am the maintainer of biology/nab and asked that it be marked deprecated several months ago. I just filed a PR to have it removed. Nab has been superseded by AmberTools (also by the nab developers). I have the current version of AmberTools building with no problems from within a skeleton port. The problem (and I do not see any solution) is that AmberTools assumes that it will be built in its final installed location. This location is hardwired throughout the compiled code. The build process fails spectacularly if you specify some other location, then move the built code and data. Is there some secret method to handle such ports for which I do not possess the magical decoder ring? Any help would be appreciated. What a very odd build system... Could you attach the port, so I/we can have a look at this AmberTools (and it's build system). -- Martin Tournoij [EMAIL PROTECTED] http://www.daemonforums.org QOTD: You will have long and healthy life. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help for a problematic port to replace biology/nab
M. L. Dodson wrote: I am the maintainer of biology/nab and asked that it be marked deprecated several months ago. I just filed a PR to have it removed. Nab has been superseded by AmberTools (also by the nab developers). I have the current version of AmberTools building with no problems from within a skeleton port. The problem (and I do not see any solution) is that AmberTools assumes that it will be built in its final installed location. This location is hardwired throughout the compiled code. The build process fails spectacularly if you specify some other location, then move the built code and data. Is there some secret method to handle such ports for which I do not possess the magical decoder ring? Any help would be appreciated. Bud Dodson I just discovered the port depends on a 64-bit. Work around the patch rejection to get it to work on 32-bit, and I will fix it tomorrow. -- M. L. Dodson Email: mldodson-at-comcast-net Phone: eight_three_two-five_63-386_one ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: cfengine-2.2.7
Hello there, it appears that an old(ish) bug has come back in the cfengine port? Its compiling with the oldest existing BDB version found on the system. Tested on both 7.0 and 6.3 with the same result. Configure says: === cfengine-2.2.7 depends on shared library: db-4.6.0 - found but then 4.0 is linked. I have found this to be perfectly repeatable, and reversable (if old versions are removed, it works with 4.6). let me know if i can be of further assistance, and thank you for your time, Simon Shapiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: cfengine-2.2.7
On Tue, 22 Jul 2008 21:03:22 -0700 Simon Shapiro wrote: Hello there, it appears that an old(ish) bug has come back in the cfengine port? Its compiling with the oldest existing BDB version found on the system. Tested on both 7.0 and 6.3 with the same result. Configure says: === cfengine-2.2.7 depends on shared library: db-4.6.0 - found but then 4.0 is linked. I have found this to be perfectly repeatable, and reversable (if old versions are removed, it works with 4.6). let me know if i can be of further assistance, and thank you for your time, Current maintainer is rather unresponsive and Jo Rhett (CCed) is very active and responsive about this port. Jo, can you help here? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: cfengine-2.2.7
On Jul 22, 2008, at 10:16 PM, Boris Samorodov wrote: On Tue, 22 Jul 2008 21:03:22 -0700 Simon Shapiro wrote: Hello there, it appears that an old(ish) bug has come back in the cfengine port? Its compiling with the oldest existing BDB version found on the system. Tested on both 7.0 and 6.3 with the same result. Configure says: === cfengine-2.2.7 depends on shared library: db-4.6.0 - found but then 4.0 is linked. I have found this to be perfectly repeatable, and reversable (if old versions are removed, it works with 4.6). let me know if i can be of further assistance, and thank you for your time, Current maintainer is rather unresponsive and Jo Rhett (CCed) is very active and responsive about this port. Jo, can you help here? Thanks! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve Thank you Boris. Some more info from my digging... forgive my complete unfamiliarity, this is deeper than I usually venture into the workings of the ports tree. As far as I can tell, the ports tree makefile (ports/sysutils/ cfengine/Makefile) gets it right, it appears that environment variables passed to the cfengine configure script (ports/sysutils/ cfengine/work/cfengine-2.2.7/configure) are ignored. That is, cfengine seems to want the command line argument --with- berkleydb= and we seem to be passing the information as an environment variable, which quickly gets overwritten with the string 'default' The evidence being that the first place i see any reference to the *old* bdb, is when the cfengine package's configure script says checking for BerkeleyDB location in default... Found header in /usr/ local/include/db4 -Simon Shapiro ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
