Re: www/rt36 with mod_perl2 broken

[Philip M. Gollucci]

Ian A. Tegebo wrote:
> Does anyone on this list have any input?
> 
> --
> ian
> 
> - Forwarded message from "Ian A. Tegebo" <[EMAIL PROTECTED]> -
> 
> Date: Mon, 21 Aug 2006 02:40:43 -0700
> From: "Ian A. Tegebo" <[EMAIL PROTECTED]>
> To: freebsd-questions@freebsd.org
> Subject: www/rt36 with mod_perl2 broken
> 
> Has anyone been able to build www/rt36 with apache22 as well as
> mod_perl2?  I get the following error with the following command:
> 
> portinstall -m 'WITH_APACHE2=yes' www/rt36 
> 
> ===>   rt-3.6.1_1 depends on file: 
> /usr/local/lib/perl5/site_perl/5.8.8/Log/Dispatch.pm - not found
> ===>Verifying install for 
> /usr/local/lib/perl5/site_perl/5.8.8/Log/Dispatch.pm in 
> /usr/ports/devel/p5-Log-Dispatch
> ===>  p5-Log-Dispatch-2.12 is marked as broken: Broken due the new mod_perl2 
> API.
Port the file its probably trivial.

See:
http://people.apache.org/~geoff/fixme

and

http://perl.apache.org/docs/2.0/rename.html

For ideas and help howto.

-- 

Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F  6A47 D55A 7172 A799 97F

"In all that I've done wrong I know I must have done something right to
deserve a hug every morning and butterfly kisses at night."
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /
 / /|_/ / // /\ \/ /_/ / /__
/_/  /_/\_, /___/\___\_\___/
   <___/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Update port security/snort to 2.6.0

[Davaeron]

When it will be commited? How long to wait?

Past...
--

*Date: * Fri, 7 Jul 2006 01:35:09 GMT
*From: * Cheng-Lung Sung <[EMAIL PROTECTED]>
*To: *   [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
*Subject: *  Re: ports/99862: Update port security/snort to 2.6.0
*Message-ID: * <[EMAIL PROTECTED] 
>

Synopsis: Update port security/snort to 2.6.0

Responsible-Changed-From-To: freebsd-ports-bugs->clsung
Responsible-Changed-By: clsung
Responsible-Changed-When: Fri Jul 7 01:35:09 UTC 2006
Responsible-Changed-Why: 
I'll take it.

http://www.freebsd.org/cgi/query-pr.cgi?pr=99862


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

Re: Broken Port: enlightenment-devel

[Fabian Keil]

Adrian <[EMAIL PROTECTED]> wrote:

> After recently cvsuping my ports tree, enlightenment-devel failts to
> compile with:
> 
>  -f ".deps/e_entry_dialog.Tpo"; exit 1; fi
> if cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../src/bin
> -I../../src/lib -DUSE_E_CONFIG_H -I/usr/X11R6/include
> -I/usr/X11R6/include -I/usr/X11R6/include -I/usr/local/include
> -I/usr/X11R6/include -I/usr/local/include -I/usr/local/include
> -I/usr/X11R6/include -DLOWRES_PDA=1 -DMEDIUMRES_PDA=2 -DHIRES_PDA=3
> -DSLOW_PC=4 -DMEDIUM_PC=5 -DFAST_PC=6 -DE17_PROFILE=SLOW_PC
> -DPACKAGE_BIN_DIR=\"/usr/X11R6/bin\"
> -DPACKAGE_LIB_DIR=\"/usr/X11R6/lib\"
> -DPACKAGE_DATA_DIR=\"/usr/X11R6/share/enlightenment\"
> -DLOCALE_DIR=\"/usr/X11R6/share/locale\"  -I/usr/local/include
> -I/usr/X11R6/include  -O -pipe  -MT e_fm.o -MD -MP -MF
> ".deps/e_fm.Tpo" -c -o e_fm.o e_fm.c; \
> then mv -f ".deps/e_fm.Tpo" ".deps/e_fm.Po"; else rm -f
> ".deps/e_fm.Tpo"; exit 1; fi
> e_fm.c: In function `e_fm2_config_set':
> e_fm.c:309: warning: assignment discards qualifiers from pointer target type
> e_fm.c:310: warning: assignment discards qualifiers from pointer target type
> e_fm.c:311: warning: assignment discards qualifiers from pointer target type
> e_fm.c: In function `_e_fm2_icon_desktop_url_eval':
> e_fm.c:1343: warning: assignment discards qualifiers from pointer target type
> e_fm.c: In function `_e_fm2_cb_icon_thumb_gen':
> e_fm.c:1645: error: `EDJE_ASPECT_CONTROL_BOTH' undeclared (first use
> in this function)
> e_fm.c:1645: error: (Each undeclared identifier is reported only once
> e_fm.c:1645: error: for each function it appears in.)
> gmake[3]: *** [e_fm.o] Error 1
> gmake[3]: Leaving directory
> `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.032/src/bin'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory
> `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.032/src'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory
> `/usr/ports/x11-wm/enlightenment-devel/work/enlightenment-0.16.999.032'
> gmake: *** [all] Error 2
> *** Error code 2
> 
> Stop in /usr/ports/x11-wm/enlightenment-devel.
> [EMAIL PROTECTED]
> 
> the build system is :
> 
> FreeBSD free.amberprobe.us 6.1-STABLE FreeBSD 6.1-STABLE #1: Thu May
> 11 22:03:51 EDT 2006
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
> 
> 
> Has anyone had a similar problem?

I updated to enlightenment-0.16.999.032 without problems.

Make sure you update to the latest versions of evas, edje,
ecore, embryo and eet before you try to update enlightenment-devel.
The port doesn't do that for you.

Fabian
-- 
http://www.fabiankeil.de/


signature.asc
Description: PGP signature

Re: A section on gettext for the Porter's Handbook

[Yar Tikhiy]

On Wed, Aug 23, 2006 at 01:42:40PM -0700, Doug Barton wrote:
> Yar Tikhiy wrote:
> > Hi all,
> > 
> > I hoped I had learned something about using gettext in ports,
> > and felt I should write down a summary.  Here's what came out
> > of that -- a proposed section for the Porter's Handbook.  Its
> > HTML rendering is available there:
> > 
> > http://people.freebsd.org/~yar/porters-handbook/using-gettext.html
> > 
> > Remarks and corrections are welcome.  Thanks!
> > 
> +.if defined(WITHOUT_NLS)
> +CONFIGURE_ARGS+=--disable-nls
> +PLIST_SUB+= NLS="@comment "
> +.else
> +USE_GETTEXT=yes
> +CONFIGURE_ENV=  LDFLAGS="-L${LOCALBASE}/lib"
> +PLIST_SUB+= NLS=""
> +.endif
> 
> Should that be .if !defined(WITHOUT_NLS), and then the outcome of the tests
> reversed? The reason being that most authors who would put that in OPTIONS
> would default NLS to on.

It's a good idea, thanks!

> Otherwise, good stuff. I think that leading people down the right path for
> the various knobs is a good thing, even if it seems "obvious" to us old hands.

Thank you a lot!

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

inconsistency in portmaster's stale distfile handling

[Rene Ladan]

Hi,

I decided to give portmaster a try to get rid of ${PORTSDIR}/INDEX*db
and /var/db/pkg/pkgdb.db.  It works quite nice, but IMO there is a
inconsistency in the -d option:

after vim got updated from 7.0.x to 7.0.66, portmaster -a -d deleted
vim/vim-6.4.tar.bz2 (which is still an up-to-date distfile for vim6, but
older than vim/vim-7.0.tar.bz2), but not vim/6.4.*

I don't have vim6 installed, so the -d option should either not delete
vim-6.4.tar.bz2 or remove all of vim6's distfiles, including vim/6.4.*
If someone has both vim6 and vim7 installed, would portmaster -d also
delete vim-6.4.tar.bz2 ?

Regards,
Rene
-- 
GPG fingerprint = E738 5471 D185 7013 0EE0  4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)

"It won't fit on the line."
-- me, 2001

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

Re: Broken Port: enlightenment-devel

[[LoN]Kamikaze]

Adrian wrote:
> Hello,
> 
> After recently cvsuping my ports tree, enlightenment-devel failts to
> compile with:
> 
> ...

Did you update the dependencies before you tried to build it?
___
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: iwi-firmware-2.4_7

[Joey Mingrone]

What is the output of:

$ cd /usr/ports/net/iwi-firmware && make -V OSVERSION




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

FreeBSD Port: handbrake-0.7.1_1

[Till Haselmann]

Dear multimedia team:

I have built Handbrake successfully using the old port (0.7.1) but  
cannot get it to compile with the new version 0.7.1_1.  The output  
from portupgrade is as attached to this email.


Apparently, I have problems compiling the libhb (which I figure is a  
handbrake library?).  What's the problem here?  How can I fix it?  I  
have already tried a make distclean but to no avail.


Regards,
Till.

Till Haselmann
[EMAIL PROTECTED]
ICQ: 62868533  |  AIM / Skype: computernomade
>> http://www.computernoma.de <<


--->  Upgrading 'handbrake-0.7.1' to  
'handbrake-0.7.1_1' (multimedia/handbrake)

--->  Building '/usr/ports/multimedia/handbrake'
===>  Cleaning for jam-2.5_2
===>  Cleaning for liba52-0.7.4_1
===>  Cleaning for libdvdcss-1.2.9_2
===>  Cleaning for libdvdread-0.9.4_1
===>  Cleaning for faac-1.24_6
===>  Cleaning for lame-3.96.1
===>  Cleaning for mpeg4ip-libmp4v2-1.5.0.1
===>  Cleaning for libmpeg2-0.4.0b_2
===>  Cleaning for libogg-1.1.3,3
===>  Cleaning for libsamplerate-0.1.2_2
===>  Cleaning for libvorbis-1.1.2,3
===>  Cleaning for xvid-1.1.0,1
===>  Cleaning for x264-0.0.20060808
===>  Cleaning for ffmpeg-devel-0.4.9.c.2006032300_2
===>  Cleaning for unzip-5.52_2
===>  Cleaning for djbfft-0.76_2
===>  Cleaning for gmake-3.81_1
===>  Cleaning for automake-1.5_2,1
===>  Cleaning for autoconf-2.59_2
===>  Cleaning for libtool-1.5.22_2
===>  Cleaning for nasm-0.98.39,1
===>  Cleaning for xorg-libraries-6.9.0
===>  Cleaning for pkg-config-0.20_2
===>  Cleaning for libsndfile-1.0.16
===>  Cleaning for fftw3-3.1.2
===>  Cleaning for gpac-libgpac-0.4.2.r2,1
===>  Cleaning for ldconfig_compat-1.0_8
===>  Cleaning for texi2html-1.76_1,1
===>  Cleaning for freetype2-2.1.10_5
===>  Cleaning for gettext-0.14.5_2
===>  Cleaning for perl-5.8.8
===>  Cleaning for autoconf-2.53_3
===>  Cleaning for m4-1.4.4
===>  Cleaning for help2man-1.36.4_1
===>  Cleaning for imake-6.9.0
===>  Cleaning for libdrm-2.0.2
===>  Cleaning for fontconfig-2.3.2_5,1
===>  Cleaning for flac-1.1.2_1
===>  Cleaning for libiconv-1.9.2_2
===>  Cleaning for p5-gettext-1.05_1
===>  Cleaning for expat-2.0.0_1
===>  Cleaning for handbrake-0.7.1_1
=> HandBrake-0.7.1.tar.gz doesn't seem to exist in /usr/ports/ 
distfiles/.

=> Attempting to fetch from http://download.m0k.org/handbrake/.
HandBrake-0.7.1.tar.gz100% of  248 kB  216  
kBps

===>  Extracting for handbrake-0.7.1_1
=> MD5 Checksum OK for HandBrake-0.7.1.tar.gz.
=> SHA256 Checksum OK for HandBrake-0.7.1.tar.gz.
===>  Patching for handbrake-0.7.1_1
===>  Applying FreeBSD patches for handbrake-0.7.1_1
===>   handbrake-0.7.1_1 depends on executable in : jam - found
===>   handbrake-0.7.1_1 depends on shared library: a52.0 - found
===>   handbrake-0.7.1_1 depends on shared library: dvdcss.2 - found
===>   handbrake-0.7.1_1 depends on shared library: dvdread.3 - found
===>   handbrake-0.7.1_1 depends on shared library: faac.0 - found
===>   handbrake-0.7.1_1 depends on shared library: mp3lame.0 - found
===>   handbrake-0.7.1_1 depends on shared library: mp4v2.0 - found
===>   handbrake-0.7.1_1 depends on shared library: mpeg2.0 - found
===>   handbrake-0.7.1_1 depends on shared library: ogg.5 - found
===>   handbrake-0.7.1_1 depends on shared library: samplerate.1 -  
found

===>   handbrake-0.7.1_1 depends on shared library: vorbis.3 - found
===>   handbrake-0.7.1_1 depends on shared library: xvidcore.4 - found
===>   handbrake-0.7.1_1 depends on shared library: x264.49 - found
===>   handbrake-0.7.1_1 depends on shared library: avcodec.1 - found
===>  Configuring for handbrake-0.7.1_1
System: FreeBSD
Endian: little

To build HandBrake, run 'jam'.
===>  Building for handbrake-0.7.1_1

cc -c -o libhb/common.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/common.c



cc -c -o libhb/hb.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/hb.c



cc -c -o libhb/ports.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/ports.c



cc -c -o libhb/scan.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/scan.c



cc -c -o libhb/work.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/work.c



cc -c -o libhb/decmpeg2.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/decmpeg2.c



cc -c -o libhb/encavcodec.o -O2 -fno-strict-aliasing -pipe -Wall - 
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 - 
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/encavcodec.c

Re: FreeBSD Port: iwi-firmware-2.4_7

[Joey Mingrone]

Hey guys,

Resetting the configuration did allow me to install iwi-firmware.
Thanks Darren.

I've tried the docs at:
http://damien.bergamini.free.fr/ipw/iwi-freebsd.html but they don't
seem to apply?

I added iwi_enable="YES" to /etc/rc.conf and tried running '>
/etc/rc.d/iwi start' and the output is:

Starting iwi [iwi0:bss]iwicontrol: Can't load firmware to driver:
Device not configured

Any suggestions?  Is there any documentation I'm missing?

Thanks,

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

BSD.local.dist - share/locale

[Andrew Pantyukhin]

I can't help thinking that the way we're trying to deal with
locale directories is far from optimal. IMHO, there are
several ways to improve the state of things:

1. Add more locales
We can add all those locales found in the same mtree
file under nls, and all less specific locales. I.e. if
aa_BB.CCC is found under nls, we can add aa_BB.CCC,
aa_BB and aa to share/locale.

2. Forget about left-overs
We can just ignore the directories left over in share/locale.
They are not harmful in any way, but it certainly contradicts
our long-standing effort to deinstall every thing we install.

3. Automate preening
We can add automatic preening to all ports that define
USE_GETTEXT. Something like
find share/locale/ -d -type d | xargs rmdir...
This way we can throw share/locale out of mtree. Ports
shouldn't (and don't) rely on these directories existence
anyway.

4. Define more specific rules as to what goes into mtree
and what doesn't. I know this one is very hard, each
change to mtree preceded by a violent bikeshed, but
someone has to lay down the rules and we have to follow
them.


Another question has arisen: should ports try to remove
directories belonging to their dependencies. On one hand
they certainly should, as "pkg_delete -f foo-dep && \
pkg_delete -f foo" should leave the system clean. OTOH
there are cases when ports need some empty dirs to exist
and become unhappy once they can't find them.

Anyway quite a few ports (e.g. almost all p5 ports) don't
remove one or more dirs of their dependencies and fixing
this is a matter of some research and careful sweeping
commits.

Your thoughts are welcome and thanks for reading this.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BSD.local.dist - share/locale

[Jeremy Messenger]

On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin  
<[EMAIL PROTECTED]> wrote:



I can't help thinking that the way we're trying to deal with
locale directories is far from optimal. IMHO, there are
several ways to improve the state of things:


I think the current how we handle locale is a bit silly, so I personal in  
favor of create localehier like misc/gnomehier than four suggested below..  
Honestly, I would be more rather to put mtree that is for ports in  
somewhere of /usr/ports/ than /etc/mtree/ that way any version of FreeBSD  
won't have any of left over directories problem.


Cheers,
Mezz


1. Add more locales
We can add all those locales found in the same mtree
file under nls, and all less specific locales. I.e. if
aa_BB.CCC is found under nls, we can add aa_BB.CCC,
aa_BB and aa to share/locale.

2. Forget about left-overs
We can just ignore the directories left over in share/locale.
They are not harmful in any way, but it certainly contradicts
our long-standing effort to deinstall every thing we install.

3. Automate preening
We can add automatic preening to all ports that define
USE_GETTEXT. Something like
find share/locale/ -d -type d | xargs rmdir...
This way we can throw share/locale out of mtree. Ports
shouldn't (and don't) rely on these directories existence
anyway.

4. Define more specific rules as to what goes into mtree
and what doesn't. I know this one is very hard, each
change to mtree preceded by a violent bikeshed, but
someone has to lay down the rules and we have to follow
them.


Another question has arisen: should ports try to remove
directories belonging to their dependencies. On one hand
they certainly should, as "pkg_delete -f foo-dep && \
pkg_delete -f foo" should leave the system clean. OTOH
there are cases when ports need some empty dirs to exist
and become unhappy once they can't find them.

Anyway quite a few ports (e.g. almost all p5 ports) don't
remove one or more dirs of their dependencies and fixing
this is a matter of some research and careful sweeping
commits.

Your thoughts are welcome and thanks for reading this.



--
[EMAIL PROTECTED]  -  [EMAIL PROTECTED]
FreeBSD GNOME Team  -  FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/  -  [EMAIL PROTECTED]
http://wiki.freebsd.org/multimedia  -  [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: FreeBSD Port: handbrake-0.7.1_1

[Jeremy Messenger]

On Thu, 24 Aug 2006 07:42:29 -0500, Till Haselmann  
<[EMAIL PROTECTED]> wrote:



Dear multimedia team:

I have built Handbrake successfully using the old port (0.7.1) but
cannot get it to compile with the new version 0.7.1_1.  The output
from portupgrade is as attached to this email.

Apparently, I have problems compiling the libhb (which I figure is a
handbrake library?).  What's the problem here?  How can I fix it?  I
have already tried a make distclean but to no avail.


The update of x264 has broken a few of ports' build, so ahze has fixed  
most of them. Looks like handbrake is missed. I won't be able to check how  
to fix it until this evening or tomorrow (have classes today).


Cheers,
Mezz


Regards,
Till.

Till Haselmann
[EMAIL PROTECTED]
ICQ: 62868533  |  AIM / Skype: computernomade
 >> http://www.computernoma.de <<



--->  Upgrading 'handbrake-0.7.1' to
'handbrake-0.7.1_1' (multimedia/handbrake)
--->  Building '/usr/ports/multimedia/handbrake'
===>  Cleaning for jam-2.5_2
===>  Cleaning for liba52-0.7.4_1
===>  Cleaning for libdvdcss-1.2.9_2
===>  Cleaning for libdvdread-0.9.4_1
===>  Cleaning for faac-1.24_6
===>  Cleaning for lame-3.96.1
===>  Cleaning for mpeg4ip-libmp4v2-1.5.0.1
===>  Cleaning for libmpeg2-0.4.0b_2
===>  Cleaning for libogg-1.1.3,3
===>  Cleaning for libsamplerate-0.1.2_2
===>  Cleaning for libvorbis-1.1.2,3
===>  Cleaning for xvid-1.1.0,1
===>  Cleaning for x264-0.0.20060808
===>  Cleaning for ffmpeg-devel-0.4.9.c.2006032300_2
===>  Cleaning for unzip-5.52_2
===>  Cleaning for djbfft-0.76_2
===>  Cleaning for gmake-3.81_1
===>  Cleaning for automake-1.5_2,1
===>  Cleaning for autoconf-2.59_2
===>  Cleaning for libtool-1.5.22_2
===>  Cleaning for nasm-0.98.39,1
===>  Cleaning for xorg-libraries-6.9.0
===>  Cleaning for pkg-config-0.20_2
===>  Cleaning for libsndfile-1.0.16
===>  Cleaning for fftw3-3.1.2
===>  Cleaning for gpac-libgpac-0.4.2.r2,1
===>  Cleaning for ldconfig_compat-1.0_8
===>  Cleaning for texi2html-1.76_1,1
===>  Cleaning for freetype2-2.1.10_5
===>  Cleaning for gettext-0.14.5_2
===>  Cleaning for perl-5.8.8
===>  Cleaning for autoconf-2.53_3
===>  Cleaning for m4-1.4.4
===>  Cleaning for help2man-1.36.4_1
===>  Cleaning for imake-6.9.0
===>  Cleaning for libdrm-2.0.2
===>  Cleaning for fontconfig-2.3.2_5,1
===>  Cleaning for flac-1.1.2_1
===>  Cleaning for libiconv-1.9.2_2
===>  Cleaning for p5-gettext-1.05_1
===>  Cleaning for expat-2.0.0_1
===>  Cleaning for handbrake-0.7.1_1
=> HandBrake-0.7.1.tar.gz doesn't seem to exist in /usr/ports/
distfiles/.
=> Attempting to fetch from http://download.m0k.org/handbrake/.
HandBrake-0.7.1.tar.gz100% of  248 kB  216
kBps
===>  Extracting for handbrake-0.7.1_1
=> MD5 Checksum OK for HandBrake-0.7.1.tar.gz.
=> SHA256 Checksum OK for HandBrake-0.7.1.tar.gz.
===>  Patching for handbrake-0.7.1_1
===>  Applying FreeBSD patches for handbrake-0.7.1_1
===>   handbrake-0.7.1_1 depends on executable in : jam - found
===>   handbrake-0.7.1_1 depends on shared library: a52.0 - found
===>   handbrake-0.7.1_1 depends on shared library: dvdcss.2 - found
===>   handbrake-0.7.1_1 depends on shared library: dvdread.3 - found
===>   handbrake-0.7.1_1 depends on shared library: faac.0 - found
===>   handbrake-0.7.1_1 depends on shared library: mp3lame.0 - found
===>   handbrake-0.7.1_1 depends on shared library: mp4v2.0 - found
===>   handbrake-0.7.1_1 depends on shared library: mpeg2.0 - found
===>   handbrake-0.7.1_1 depends on shared library: ogg.5 - found
===>   handbrake-0.7.1_1 depends on shared library: samplerate.1 -
found
===>   handbrake-0.7.1_1 depends on shared library: vorbis.3 - found
===>   handbrake-0.7.1_1 depends on shared library: xvidcore.4 - found
===>   handbrake-0.7.1_1 depends on shared library: x264.49 - found
===>   handbrake-0.7.1_1 depends on shared library: avcodec.1 - found
===>  Configuring for handbrake-0.7.1_1
System: FreeBSD
Endian: little

To build HandBrake, run 'jam'.
===>  Building for handbrake-0.7.1_1

cc -c -o libhb/common.o -O2 -fno-strict-aliasing -pipe -Wall -
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 -
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/common.c


cc -c -o libhb/hb.o -O2 -fno-strict-aliasing -pipe -Wall -
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 -
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/hb.c


cc -c -o libhb/ports.o -O2 -fno-strict-aliasing -pipe -Wall -
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 -
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/ports.c


cc -c -o libhb/scan.o -O2 -fno-strict-aliasing -pipe -Wall -
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 -
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/scan.c


cc -c -o libhb/work.o -O2 -fno-strict-aliasing -pipe -Wall -
DSYS_FREEBSD -DHB_VERSION=\"0.7.1\" -DHB_BUILD=2006022400 -
D__LIBHB__ -Ilibhb -I/usr/local/include libhb/work.c


cc -c -o libhb/decmpeg2.o -O2 -fno-strict-aliasing -pipe -Wall -
DSYS_FREEBSD -DHB_VERSION=\"0.7.1

Re: BSD.local.dist - share/locale

[Andrew Pantyukhin]

On 8/24/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:

On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin
<[EMAIL PROTECTED]> wrote:

> I can't help thinking that the way we're trying to deal with
> locale directories is far from optimal. IMHO, there are
> several ways to improve the state of things:

I think the current how we handle locale is a bit silly, so I personal in
favor of create localehier like misc/gnomehier than four suggested below..
Honestly, I would be more rather to put mtree that is for ports in
somewhere of /usr/ports/ than /etc/mtree/ that way any version of FreeBSD
won't have any of left over directories problem.


It's a good idea, but we're back at the second question -
what if someone fancies to pkg_delete -xf gnomehier?
There will be no way to get a clean system after that
other than by reinstalling gnomehier and deleting it after
all the ports requiring it.

And in case we ignore it and say that one should not
deinstall a foo-dep before foo, then the whole point of
the latest locale-related pkg-plist fixes is lost.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

error compiling dsniff on FreeBSD, with the correct version of netlib

[Moon Michael]

Any ideas what I am doing wrong ?
I even had a look in the libnet functions and they are defined so I
don't understand what's happening, anyone else who has come across this
and found a solution please let me know
 make
===>  WARNING: Vulnerability database out of date, checking anyway
===>  Extracting for dsniff-2.3_1
=> MD5 Checksum OK for dsniff-2.3.tar.gz.
=> SHA256 Checksum OK for dsniff-2.3.tar.gz.
===>  Patching for dsniff-2.3_1
===>  Applying FreeBSD patches for dsniff-2.3_1
===>   dsniff-2.3_1 depends on package: libnet*<=1.1.0,1 - found
===>   dsniff-2.3_1 depends on file: /usr/local/lib/libnids.a - found
===>   dsniff-2.3_1 depends on shared library: X11.6 - found
===>  Configuring for dsniff-2.3_1
creating cache ./config.cache
checking for gcc... cc
checking whether the C compiler (cc -O2 -fno-strict-aliasing -pipe  )
works... y
es
checking whether the C compiler (cc -O2 -fno-strict-aliasing -pipe  ) is
a cross
-compiler... no
checking whether we are using GNU C... yes
checking whether cc accepts -g... yes
checking for a BSD compatible install... /usr/bin/install -c -o root -g
wheel
checking for ranlib... ranlib
checking how to run the C preprocessor... cc -E
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for dnet_ntoa in -ldnet... no
checking for dnet_ntoa in -ldnet_stub... no
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for ANSI C header files... yes
checking for err.h... yes
checking for fcntl.h... yes
checking for sys/ioctl.h... yes
checking for sys/queue.h... yes
checking for unistd.h... yes
checking for libgen.h... yes
checking for net/if_tun.h... yes
checking for MIN and MAX in sys/param.h... yes
checking for working const... yes
checking for size_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for u_int32_t... yes
checking for u_int64_t... yes
checking for in_addr_t... yes
checking whether cc needs -traditional... no
checking for 8-bit clean memcmp... yes
checking return type of signal handlers... void
checking for strftime... yes
checking for gethostname... yes
checking for socket... yes
checking for strdup... yes
checking for strstr... yes
checking for xdr_fhstatus in -lrpcsvc... yes
checking for socket in -lsocket... no
checking for gethostbyname in -lnsl... no
checking for dn_expand in -lresolv... no
checking for dirname... yes
checking for strlcpy... yes
checking for strlcat... yes
checking for strsep... yes
checking for MD5Update... no
checking for warnx... yes
checking for ether_ntoa... yes
checking for Berkeley DB with 1.85 compatibility... yes
checking for libpcap... yes
checking for libnet... yes
checking for libnids... yes
checking whether libnids version is good... yes
checking for OpenSSL... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating config.h
===>  Building for dsniff-2.3_1
cc -O2 -fno-strict-aliasing -pipe  -D_BSD_SOURCE -DLIBNET_BSDISH_OS
-DLIBNET_BSD
_BYTE_SWAP -DHAVE_SOCKADDR_SA_LEN -DLIBNET_LIL_ENDIAN
-DDSNIFF_LIBDIR=\"/usr/loc
al/lib/\" -I. -I/usr/include -I/usr/local/include  -I/usr/local/include
-I/usr
/X11R6/include  -I./missing -c ./missing/dummy.c
cc -O2 -fno-strict-aliasing -pipe  -D_BSD_SOURCE -DLIBNET_BSDISH_OS
-DLIBNET_BSD
_BYTE_SWAP -DHAVE_SOCKADDR_SA_LEN -DLIBNET_LIL_ENDIAN
-DDSNIFF_LIBDIR=\"/usr/loc
al/lib/\" -I. -I/usr/include -I/usr/local/include  -I/usr/local/include
-I/usr
/X11R6/include  -I./missing -c ./missing/md5.c
ar -cr libmissing.a dummy.o  md5.o
ranlib libmissing.a
cc -O2 -fno-strict-aliasing -pipe  -D_BSD_SOURCE -DLIBNET_BSDISH_OS
-DLIBNET_BSD
_BYTE_SWAP -DHAVE_SOCKADDR_SA_LEN -DLIBNET_LIL_ENDIAN
-DDSNIFF_LIBDIR=\"/usr/loc
al/lib/\" -I. -I/usr/include -I/usr/local/include  -I/usr/local/include
-I/usr
/X11R6/include  -I./missing -c ./arpspoof.c
cc -O2 -fno-strict-aliasing -pipe  -D_BSD_SOURCE -DLIBNET_BSDISH_OS
-DLIBNET_BSD
_BYTE_SWAP -DHAVE_SOCKADDR_SA_LEN -DLIBNET_LIL_ENDIAN
-DDSNIFF_LIBDIR=\"/usr/loc
al/lib/\" -I. -I/usr/include -I/usr/local/include  -I/usr/local/include
-I/usr
/X11R6/include  -I./missing -c ./arp.c
cc  -o arpspoof arpspoof.o arp.o -lrpcsvc  -L. -lmissing -lpcap
-L/usr/local/lib
-lnet
arpspoof.o(.text+0xce): In function `arp_send':
: undefined reference to `libnet_host_lookup'
arpspoof.o(.text+0x122): In function `arp_send':
: undefined reference to `libnet_write_link_layer'
arpspoof.o(.text+0x14b): In function `arp_send':
: undefined reference to `libnet_get_ipaddr'
arpspoof.o(.text+0x181): In function `arp_send':
: undefined reference to `libnet_host_lookup'
arpspoof.o(.text+0x192): In function `arp_send':
: undefined reference to `libnet_host_lookup'
arpspoof.o(.text+0x360): In function `main':
: undefined reference to `libnet_name_resolve'
arpspoof.o(.text+0x391): In function `main':
: undefined reference to `libnet_open_link_interface'
arpspoof.o(.text+0x42e): In function `main':
: unde

Question on respecting PREFIX, LOCALBASE, SITE_PERL, etc...

[othermark]

I have a port that I'm working on that, in addition to the binaries it
generates, it generates the following:

- C api, includes, libraries
- perl api
- tcl api
- python api

it also has java and rexx extensions, but I'm not going to add those until 
later.

My question revolves around respecting both PREFIX and stuff like TCL_LIBDIR
and SITE_PERL.   I want the port to be heir(7) compliant, but I'm also
patching the install to put perl, tcl, and python modules in the
TCL/PERL/PYTHON respective site library repositories.  

So when the operator uses make PREFIX=/somedir do I rigorously plop
everthing under PREFIX and patch the TCL/PERL/PYTHON destinations to match,
or do I go ahead and plop those in the SITE_PERL, PYTHON_SITELIBDIR, etc
actual locations on the box?

Doing everything under PREFIX makes it easier to properly form the pkg-list,
but that can be coded around to.

-- 
othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);

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

Re: BSD.local.dist - share/locale

[Stanislav Sedov]

On Thu, 24 Aug 2006 18:50:52 +0400
"Andrew Pantyukhin" <[EMAIL PROTECTED]> mentioned:

> On 8/24/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:
> > On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin
> > <[EMAIL PROTECTED]> wrote:
> >
> > > I can't help thinking that the way we're trying to deal with
> > > locale directories is far from optimal. IMHO, there are
> > > several ways to improve the state of things:
> >
> > I think the current how we handle locale is a bit silly, so I personal in
> > favor of create localehier like misc/gnomehier than four suggested below..
> > Honestly, I would be more rather to put mtree that is for ports in
> > somewhere of /usr/ports/ than /etc/mtree/ that way any version of FreeBSD
> > won't have any of left over directories problem.
> 
> It's a good idea, but we're back at the second question -
> what if someone fancies to pkg_delete -xf gnomehier?
> There will be no way to get a clean system after that
> other than by reinstalling gnomehier and deleting it after
> all the ports requiring it.
> 

That's not the main problem, and hasn't point at all since we
doesn't support such kind of deinstalls - dependent ports should
be deinstalled before dependencies. 

The main argument for deinstalling all files/direcotries that
port creates follows from FreeBSD ports goal to support different
PREFIXES. That is, you can install gettext into /usr/local and 
smth that depends on gettext into /usr/local/opt. In that case
all these share/locale/xxx dirs will be created under /usr/local/opt
PREFIX and if this dependent port will not make effort to remove
these files/directories on deinstall, they will stay under /usr/local/opt
forever, though not listed in ${MTREE_FILE}.

The only possible solution I can imagine is to add these direcories into
mtree file, but since all pacthes are alredy there, there is no reason
doing this now. Just port committers should check PLISTS accurately. This
could be achieved by installing port with non standard PREFIX=xxx,
deinstalling it and looking for directories/files left.

The other possible solution is to implement some technique to automatically
gather directories dependencies created and add them into plist. But this
rather can't be achieved now, since we currently doesn't list directories
in plist, and we can't rely on @dirrm for they can be deleted also with rm -rf,
rmdir and even with `set xxx=`mktemp /tmp/1.XX` && echo '#include 
\n#include \nint main(){rmdir("/path/to/dir"); return 0;}' 
> ${xxx} &&
${CC} -o ${xxx:r} ${xxx} && ${xxx:r}` ;-)

-- 
Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]>
Россия, Москва http://mbsd.msk.ru


If the facts don't fit the theory, change the facts.  -- A. Einstein

PGP fingerprint:  F21E D6CC 5626 9609 6CE2  A385 2BF5 5993 EB26 9581


signature.asc
Description: PGP signature

Re: Question on respecting PREFIX, LOCALBASE, SITE_PERL, etc...

[Stanislav Sedov]

On Thu, 24 Aug 2006 10:19:40 -0700
othermark <[EMAIL PROTECTED]> mentioned:

> I have a port that I'm working on that, in addition to the binaries it
> generates, it generates the following:
> 
> - C api, includes, libraries
> - perl api
> - tcl api
> - python api
> 
> it also has java and rexx extensions, but I'm not going to add those until 
> later.
> 
> My question revolves around respecting both PREFIX and stuff like TCL_LIBDIR
> and SITE_PERL.   I want the port to be heir(7) compliant, but I'm also
> patching the install to put perl, tcl, and python modules in the
> TCL/PERL/PYTHON respective site library repositories.  
> 
> So when the operator uses make PREFIX=/somedir do I rigorously plop
> everthing under PREFIX and patch the TCL/PERL/PYTHON destinations to match,
> or do I go ahead and plop those in the SITE_PERL, PYTHON_SITELIBDIR, etc
> actual locations on the box?
> 
> Doing everything under PREFIX makes it easier to properly form the pkg-list,
> but that can be coded around to.
> 

You certainly should respect PREFIX, but now PERL/ruby/tcl etc
frameworks don't do this well. So don't think about this now and
install everything under SITE_PERL etc. Somebody should take a
look on these frameworks and fix them, then your port will be
PREFIX clean without your interaction. It's a framework problem,
not your port's. AFAIK, only ocaml framework handles it properly now.

-- 
Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]>
Россия, Москва http://mbsd.msk.ru


If the facts don't fit the theory, change the facts.  -- A. Einstein

PGP fingerprint:  F21E D6CC 5626 9609 6CE2  A385 2BF5 5993 EB26 9581


signature.asc
Description: PGP signature

portmaster patch for testing CONFLICTS and dependency list (Was: Re: portmaster and dependencies)

[Doug Barton]

B Briggs wrote:
> After reading some of the comments on a prior thread about "the best" 
> port update tool, I decided to give portmaster a look.

Thanks!

> Unfortunately my ports were up to date except for openoffice.org-2.0
> which I had listed as HOLD_PKGS in pkgtools.conf. Anyway, I let it run
> and it stopped because it wanted to install linux-sun-jdk14 (You get the
> manual fetch message in IGNORE=), which I had only used as a bootstrap to
> get the native jdk15 installed, then later removed the linux version and
> its distfile.
> 
> Looked back at prior threads and it looks like someone mentioned this 
> about 3 weeks ago.

I seem to have missed this message, sorry about that.

> I was just wondering if there was any progress along these lines.
> 
> FWIW, I changed the script on line 435 from dep_port_list=`make
> $MAKE_ARGS all-depends-list` to dep_port_list=`make $MAKE_ARGS
> run-depends-list && make $MAKE_ARGS build-depends-list`

That's a very interesting idea, which I have now done some testing on (with
a slightly different version of the patch). An examination of the code in
bsd.port.mk indicates that not only should this work, it also has several
advantages. Not the least of which is that it should be faster, and it
should avoid building dependencies that the user doesn't actually need,
either because of the case you documented here, or because 'make config' in
a dependent port would eliminate the need for that port. Frankly, I wish
I'd thought of this. :)

> The author might want to look at this; he'll know much more about it and 
> can probably tell right away if this is going to break some other 
> functions of the script. I already know that the two depends-lists will 
> have duplicates, but it doesn't seem to affect any builds.

portmaster already has code to avoid doing duplicate dependency checking,
but in this case it's easy to avoid getting the duplicates in the list, so
it saves that much more effort.

> I know just enough about the ports system to be dangerous. Anyway, I've 
> been playing with it for a couple of hours now removing and reinstalling 
> ports with portmaster, and I haven't run into any problems so far. And I 
> want to say that I really like portmaster.

Thanks again!

> I'll probably stick with it and remove portupgrade and ruby, but I'm
> going to miss pkg_which: Is there any replacement?

pkg_info -W

I've created a patch that has the dependency list change, plus the
experimental work I'm doing on trying to handle alternate dependencies via
CONFLICTS. It's at http://dougbarton.us/portmaster-conflicts-depends.patch.
I would appreciate it if folks could at least test the dependency list hunk
of that patch, and report back if they have any problems. As I said, it
_should_ work, but it's a non-trivial change and I don't want to screw
things up for anyone.

Doug

-- 

This .signature sanitized for your protection

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

Re: inconsistency in portmaster's stale distfile handling

[Doug Barton]

Rene Ladan wrote:
> Hi,
> 
> I decided to give portmaster a try to get rid of ${PORTSDIR}/INDEX*db
> and /var/db/pkg/pkgdb.db.  It works quite nice, but IMO there is a
> inconsistency in the -d option:
> 
> after vim got updated from 7.0.x to 7.0.66, portmaster -a -d deleted
> vim/vim-6.4.tar.bz2 (which is still an up-to-date distfile for vim6, but
> older than vim/vim-7.0.tar.bz2), but not vim/6.4.*
> 
> I don't have vim6 installed, so the -d option should either not delete
> vim-6.4.tar.bz2 or remove all of vim6's distfiles, including vim/6.4.*
> If someone has both vim6 and vim7 installed, would portmaster -d also
> delete vim-6.4.tar.bz2 ?

Yes. The stale file algorithm is very aggressive, and tries to find as many
matches as possible that could reasonably be a distfile for that package. If
you regularly run into situations where -d deletes too many files, you can
run portmaster without it and it will prompt you for whether to delete the
files or not.

hth,

Doug

-- 

This .signature sanitized for your protection

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

Re: portmaster patch for testing CONFLICTS and dependency list (Was: Re: portmaster and dependencies)

[Jeremy Messenger]

On Thu, 24 Aug 2006 15:51:56 -0500, Doug Barton <[EMAIL PROTECTED]> wrote:



I've created a patch that has the dependency list change, plus the
experimental work I'm doing on trying to handle alternate dependencies  
via
CONFLICTS. It's at  
http://dougbarton.us/portmaster-conflicts-depends.patch.
I would appreciate it if folks could at least test the dependency list  
hunk

of that patch, and report back if they have any problems. As I said, it
_should_ work, but it's a non-trivial change and I don't want to screw
things up for anyone.


Awsome! I can test it in the next week or so. Right now, I am working on  
install KDE and GNOME 2.15.x together in jail for conflict stuff by merge  
into a prefix. When I am done w/ it, then I can test your patch by upgrade  
GNOME 2.14.x to 2.15.x. It is a huge upgrade, so let's see how portmaster  
can handles it. :-)


Cheers,
Mezz


Doug



--
[EMAIL PROTECTED]  -  [EMAIL PROTECTED]
FreeBSD GNOME Team  -  FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/  -  [EMAIL PROTECTED]
http://wiki.freebsd.org/multimedia  -  [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: BSD.local.dist - share/locale

[Andrew Pantyukhin]

On 8/24/06, Stanislav Sedov <[EMAIL PROTECTED]> wrote:

On Thu, 24 Aug 2006 18:50:52 +0400
"Andrew Pantyukhin" <[EMAIL PROTECTED]> mentioned:

> On 8/24/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:
> > On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin
> > <[EMAIL PROTECTED]> wrote:
> >
> > > I can't help thinking that the way we're trying to deal with
> > > locale directories is far from optimal. IMHO, there are
> > > several ways to improve the state of things:
> >
> > I think the current how we handle locale is a bit silly, so I personal in
> > favor of create localehier like misc/gnomehier than four suggested below..
> > Honestly, I would be more rather to put mtree that is for ports in
> > somewhere of /usr/ports/ than /etc/mtree/ that way any version of FreeBSD
> > won't have any of left over directories problem.
>
> It's a good idea, but we're back at the second question -
> what if someone fancies to pkg_delete -xf gnomehier?
> There will be no way to get a clean system after that
> other than by reinstalling gnomehier and deleting it after
> all the ports requiring it.

That's not the main problem, and hasn't point at all since we
don't support such kind of deinstalls - dependent ports should
be deinstalled before dependencies.


Oh, I'm quite sure you don't mean it. You're saying that
every time we upgrade a port we should also reinstall all
the ports relying on it? Because there's no way we can
guarantee a port's directory structure stays intact across
upgrades.


The main argument for deinstalling all files/direcotries that
port creates follows from FreeBSD ports goal to support different
PREFIXES. That is, you can install gettext into /usr/local and
smth that depends on gettext into /usr/local/opt. In that case
all these share/locale/xxx dirs will be created under /usr/local/opt
PREFIX and if this dependent port will not make effort to remove
these files/directories on deinstall, they will stay under /usr/local/opt
forever, though not listed in ${MTREE_FILE}.


Again, you don't really mean it. Try installing any p5 port into
a non-localbase prefix, and you'll see that lib/perl5 and Co. will
be left over after deinstall. Even if you suppose that all ports
respect PREFIX (which many of them don't), it's not a simple
task to deal with non-mtree left-overs. I would very much like to
think that your locale effort is a step towards a better world,
but it really appears to be a step nowhere at all. I hope I'm too
short-sighted and mistaken.


The only possible solution I can imagine is to add these direcories into
mtree file, but since all pacthes are alredy there, there is no reason
doing this now. Just port committers should check PLISTS accurately. This
could be achieved by installing port with non standard PREFIX=xxx,
deinstalling it and looking for directories/files left.

The other possible solution is to implement some technique to automatically
gather directories dependencies created and add them into plist.


We only need to care about the directories we created (or might have
created if there were none) out of mtree. It's an enormous task to fix
all the ports to do that - and there are quite a few cases when we
just can't remove an empty dir if its real owner is still installed.


A worthwhile effort would be to ensure PREFIX compliance for all
ports.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BSD.local.dist - share/locale

[Stanislav Sedov]

On Fri, 25 Aug 2006 00:09:33 +0400
"Andrew Pantyukhin" <[EMAIL PROTECTED]> mentioned:

> On 8/24/06, Stanislav Sedov <[EMAIL PROTECTED]> wrote:
> > On Thu, 24 Aug 2006 18:50:52 +0400
> > "Andrew Pantyukhin" <[EMAIL PROTECTED]> mentioned:
> >
> > > On 8/24/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:
> > > > On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin
> > > > <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > I can't help thinking that the way we're trying to deal with
> > > > > locale directories is far from optimal. IMHO, there are
> > > > > several ways to improve the state of things:
> > > >
> > > > I think the current how we handle locale is a bit silly, so I personal 
> > > > in
> > > > favor of create localehier like misc/gnomehier than four suggested 
> > > > below..
> > > > Honestly, I would be more rather to put mtree that is for ports in
> > > > somewhere of /usr/ports/ than /etc/mtree/ that way any version of 
> > > > FreeBSD
> > > > won't have any of left over directories problem.
> > >
> > > It's a good idea, but we're back at the second question -
> > > what if someone fancies to pkg_delete -xf gnomehier?
> > > There will be no way to get a clean system after that
> > > other than by reinstalling gnomehier and deleting it after
> > > all the ports requiring it.
> >
> > That's not the main problem, and hasn't point at all since we
> > don't support such kind of deinstalls - dependent ports should
> > be deinstalled before dependencies.
> 
> Oh, I'm quite sure you don't mean it. You're saying that
> every time we upgrade a port we should also reinstall all
> the ports relying on it? Because there's no way we can
> guarantee a port's directory structure stays intact across
> upgrades.

In fact, yes, we should.

> 
> > The main argument for deinstalling all files/direcotries that
> > port creates follows from FreeBSD ports goal to support different
> > PREFIXES. That is, you can install gettext into /usr/local and
> > smth that depends on gettext into /usr/local/opt. In that case
> > all these share/locale/xxx dirs will be created under /usr/local/opt
> > PREFIX and if this dependent port will not make effort to remove
> > these files/directories on deinstall, they will stay under /usr/local/opt
> > forever, though not listed in ${MTREE_FILE}.
> 
> Again, you don't really mean it. Try installing any p5 port into
> a non-localbase prefix, and you'll see that lib/perl5 and Co. will
> be left over after deinstall. Even if you suppose that all ports
> respect PREFIX (which many of them don't), it's not a simple
> task to deal with non-mtree left-overs. I would very much like to
> think that your locale effort is a step towards a better world,
> but it really appears to be a step nowhere at all. I hope I'm too
> short-sighted and mistaken.
> 

Didn't I say the same? ;-) You are not quite right, most of ports
respect PREFIX and remove all directories they creates. I can't really
say why perl/ruby ports don't do this - it may be inaccurate commits, PRs
etc. When creating ocaml framework I've added stubs to automatically
add shared dirs into PLIST. Probably, ruby and perl frameworks require
the same step forward.

> > The only possible solution I can imagine is to add these direcories into
> > mtree file, but since all pacthes are alredy there, there is no reason
> > doing this now. Just port committers should check PLISTS accurately. This
> > could be achieved by installing port with non standard PREFIX=xxx,
> > deinstalling it and looking for directories/files left.
> >
> > The other possible solution is to implement some technique to automatically
> > gather directories dependencies created and add them into plist.
> 
> We only need to care about the directories we created (or might have
> created if there were none) out of mtree. It's an enormous task to fix
> all the ports to do that - and there are quite a few cases when we
> just can't remove an empty dir if its real owner is still installed.
>

Don't understand what are you trying to clarify...
Again: every port should be PREFIX clean, but that doesn't mean that
we should brought entire our work away and sit fixing all the ports.
Just every new commit/PR should ensure PREFIX safety and some amount
of time should be payed to perl/ruby frameworks by their respective
maintainers (we could fix p5-, ruby- ports all by placing some simple
logic into bsd.ruby.mk and bsd.perl.mk). 
 
> 
> A worthwhile effort would be to ensure PREFIX compliance for all
> ports.


-- 
Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]>
Россия, Москва http://mbsd.msk.ru


If the facts don't fit the theory, change the facts.  -- A. Einstein

PGP fingerprint:  F21E D6CC 5626 9609 6CE2  A385 2BF5 5993 EB26 9581


signature.asc
Description: PGP signature

Re: BSD.local.dist - share/locale

[Jeremy Messenger]

On Thu, 24 Aug 2006 09:50:52 -0500, Andrew Pantyukhin  
<[EMAIL PROTECTED]> wrote:



On 8/24/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:

On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin
<[EMAIL PROTECTED]> wrote:

> I can't help thinking that the way we're trying to deal with
> locale directories is far from optimal. IMHO, there are
> several ways to improve the state of things:

I think the current how we handle locale is a bit silly, so I personal  
in
favor of create localehier like misc/gnomehier than four suggested  
below..

Honestly, I would be more rather to put mtree that is for ports in
somewhere of /usr/ports/ than /etc/mtree/ that way any version of  
FreeBSD

won't have any of left over directories problem.


It's a good idea, but we're back at the second question -
what if someone fancies to pkg_delete -xf gnomehier?
There will be no way to get a clean system after that
other than by reinstalling gnomehier and deleting it after
all the ports requiring it.


Why would someone want to delete it when it is need? Same things with why  
would someone delete library when apps need it? I think it's not our  
problem as I haven't seen anyone do that with gnomehier.



And in case we ignore it and say that one should not
deinstall a foo-dep before foo, then the whole point of
the latest locale-related pkg-plist fixes is lost.


I don't see any problem as you can install gnomehier back in, same as with  
put library back in. Unless, I don't get it.


Cheers,
Mezz


--
[EMAIL PROTECTED]  -  [EMAIL PROTECTED]
FreeBSD GNOME Team  -  FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/  -  [EMAIL PROTECTED]
http://wiki.freebsd.org/multimedia  -  [EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

cvsup bug

[Jason Boisvert]

Hi FreeBSD professionals,


Pls note that I received this error msg when trying to run portsdb -Uu on my 
gateway 450 laptop.



==
The error:

[EMAIL PROTECTED] ~ $ sudo portsdb -Uu
Updating the ports index ... Generating INDEX.tmp - please 
wait.."/usr/ports/Mk/bsd.gnome.mk", line 626: Malformed conditional 
(${_USE_GNOME_ALL:Mgtk20}=="")
"/usr/ports/Mk/bsd.port.mk", line 5992: if-less endif
make: fatal errors encountered -- cannot continue
===> games/freeciv-nox11 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/) 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


==



===
Here is my make.conf file:

[EMAIL PROTECTED] ~ $ cat /etc/make.conf
# added by use.perl 2006-05-24 16:32:54
PERL_VER=5.8.8
PERL_VERSION=5.8.8

PORTSSUPFILE=/etc/ports-supfile
KERNCONF=KAILASH
NO_SENDMAIL=YES
CFLAGS= -O -pipe
CPUTYPE=pentium-m
WITH_OPTIMIZED_CFLAGS=1
WITHOUT_RUNTIME_CPUDETECTION=1
WITH_GTK2=1
WITHOUT_3DNOW=1
WITHOUT_DSP=1
WITH_DVD_DEVICE=/dev/acd0
WITH_CDROM_DEVICE=/dev/acd0
NO_LPR=true
CUPS_OVERWRITE_BASE=yes

=


Pls let me know if you need anything else.

Jason





I am running KDE 3.5.3 on 6.1-Release.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]

[Gábor Kövesdán]

John E Hein wrote:

Gábor Kövesdán wrote at 21:44 +0200 on Aug 23, 2006:
 > Kris Kennaway wrote:
 > > mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
 > > mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
 > > mount_devfs foo ${DESTDIR}/dev
 > > chroot ${DESTDIR} cd ${.CURDIR} && make install
 > >
 > > A suitable version of the above should allow all ports to be installed
 > > into a jail-ready filesystem hierarchy, while requiring 0 port
 > > changes.
 >
 > Ok, I think it's time to follow this way, but have to make some parts 
 > clearer. For your last line, it should be
 > 
 > chroot ${DESTDIR} cd ${.CURDIR} && make ${.TARGETDIR}


I assume you mean .TARGET
  

Sure, TARGETDIR is just stuck in my mind. :)


 > since we want to run all targets chrooted. We could put this part into 
 > an .if defined(DESTDIR) block before the targets, but I don't know how 
 > to prevent running the further code, since we don't want to reach 
 > do-install in the host environment, but only in the chroot. I think of 
 > exit 0, if that's correct, or what else is better.

 > So, what I mean:
 > 
 > .if defined(DESTDIR)

 > .BEGIN   # We need this if not in a target
 > ${MOUNT_NULLFS} ${PORTSDIR} ${DESTDIR}${PORTSDIR}
 > ${MOUNT_NULLFS} ${WRKDIR} ${DESTDIR}${WRKDIR}
 > ${MOUNT_DEVFS} foo ${DESTDIR}/dev
 > ${CHROOT} ${DESTDIR} cd ${.CURDIR} && ${MAKE} ${.TARGETDIR}
 > exit 0
 > .endif

Each line with a command in a makefile is it's own shell.
So 'exit 0' will start a shell and exit that shell.
It will not prevent make from continuing.

'exit 1' (or anything that returns a non-zero code, like false) will
stop make (unless -k or -i or similar is specified), but that's not
what you want.


make(1) is not a very good tool for this kind of thing (a script would
probably be better), but here is one way to do this kind of two stage
make (untested, but illustrates the point):

bsd.port.mk would have something like this:

STAGE?= 1
.if ${STAGE} == 1 && defined(DESTDIR) && !empty(DESTDIR)

.MAKEFLAGS: STAGE=2

.BEGIN:
${MOUNT_NULLFS} ${PORTSDIR} ${DESTDIR}${PORTSDIR}
${MOUNT_NULLFS} ${WRKDIR} ${DESTDIR}${WRKDIR}
${MOUNT_DEVFS} foo ${DESTDIR}/dev
${CHROOT} ${DESTDIR} cd ${.CURDIR} && ${MAKE} ${.TARGET}

.else
 .
 .
 rest of bsd.port.mk
 .
 .
.endif

You could put the first part into a bsd.destdir.mk and .include it
to make it look cleaner.

Note there are other complications like unmounting the nullfs and
devfs.
  
What about renaming bsd.port.mk to bsd.build.mk and creating a 
bsd.destdir.mk. At the same time, we could make a "lightweight" 
bsd.index.mk, which would only contain things that are really necessary 
for index building. It could make the index building faster, couldn't 
it? The new bsd.port.mk would be something like this then:


STAGE?= 1
.if target(index)
.include 
.elif ${STAGE} == 1 && defined(DESTDIR) && !empty(DESTDIR)
.include 
.else
.include 
.endif

This method would offer better modularization, as I mentioned the index 
building example. The current bsd.port.mk file is huge and it is 
included every time by port Makefiles, but we doesn't actually need 
this, e.g. index building requires only snippets from bsd.port.mk.


Comments?
I'm interested in the portmgr standpoint about this as well, before I 
start to work on it. I did some useless work in the last round, so I 
want to discuss things better this time.




 > The another issue I find is how we can pass variables to the chrooted 
 > make. E.g. if we want to set WITH_FOO in command line or in make.conf. 
 > And note, that we can't just pass everything, since DESTDIR should be 
 > unset in the chroot, otherwise we would run into infinite loop and it 
 > would fail due to the non-existent directories.


Really, for these and other reasons, a script would be better.  It
could be done with make(1) and bsd.port.mk, but it's probably not
worth it.

  
I think it would be quite complicated with scripts as well. But anyway, 
I'm unsure if we really have to pass such variables. Maybe it is not 
used so often, and can be put into the jail's make.conf as well if 
really necessary. I doubt if it's worth to spam the code with ugly 
workarounds for this.

Again, if we do decide to go this route, we should remove all mention
of DESTDIR from Mk/*.mk (rather than pretend to support it, but
incorrectly).
  
Agreed. The current progress has to be completely reverted for this, 
only little pieces should be kept. E.g. somebody told that he likes my 
OSVERSION change. It is more rational that the old one.

Others have mentioned cross building.  Neither proper DESTDIR support
in bsd.port.mk nor a scripted mount_nullfs & a chroot is going to be
the one thing to solve that problem.  Some ports will build okay if
you give them access to cross tools (like ppc-gcc) and tell them what
target architecture to produce.  Other ports will need to be taught.
Some ports might need to run intermediate native architecture tools
produced at build t

Re: portmaster patch for testing CONFLICTS and dependency list (Was: Re: portmaster and dependencies)

[Doug Barton]

Jeremy Messenger wrote:
> On Thu, 24 Aug 2006 15:51:56 -0500, Doug Barton <[EMAIL PROTECTED]> wrote:
> 
> 
>> I've created a patch that has the dependency list change, plus the
>> experimental work I'm doing on trying to handle alternate dependencies
>> via
>> CONFLICTS. It's at
>> http://dougbarton.us/portmaster-conflicts-depends.patch.
>> I would appreciate it if folks could at least test the dependency list
>> hunk
>> of that patch, and report back if they have any problems. As I said, it
>> _should_ work, but it's a non-trivial change and I don't want to screw
>> things up for anyone.
> 
> Awsome! I can test it in the next week or so. Right now, I am working on
> install KDE and GNOME 2.15.x together in jail for conflict stuff by
> merge into a prefix. When I am done w/ it, then I can test your patch by
> upgrade GNOME 2.14.x to 2.15.x. It is a huge upgrade, so let's see how
> portmaster can handles it. :-)

Well I did the last round of torture testing by doing basically what you're
doing now, first installing gnome from scratch, then installing kde from
scratch. So hopefully it will perform well. :)

Doug

-- 

This .signature sanitized for your protection

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

Re: inconsistency in portmaster's stale distfile handling

[Rene Ladan]

Doug Barton schreef:
> Rene Ladan wrote:
>> Hi,
>>
>> I decided to give portmaster a try to get rid of ${PORTSDIR}/INDEX*db
>> and /var/db/pkg/pkgdb.db.  It works quite nice, but IMO there is a
>> inconsistency in the -d option:
>>
>> after vim got updated from 7.0.x to 7.0.66, portmaster -a -d deleted
>> vim/vim-6.4.tar.bz2 (which is still an up-to-date distfile for vim6, but
>> older than vim/vim-7.0.tar.bz2), but not vim/6.4.*
>>
>> I don't have vim6 installed, so the -d option should either not delete
>> vim-6.4.tar.bz2 or remove all of vim6's distfiles, including vim/6.4.*
>> If someone has both vim6 and vim7 installed, would portmaster -d also
>> delete vim-6.4.tar.bz2 ?
> 
> Yes. The stale file algorithm is very aggressive, and tries to find as many
> matches as possible that could reasonably be a distfile for that package. If
> you regularly run into situations where -d deletes too many files, you can
> run portmaster without it and it will prompt you for whether to delete the
> files or not.
> 
The nice thing about the -d option is that I don't have to type 'y' each
time :)  Just mentioning this case...
> hth,
> 
> Doug
> 
Regards,
Rene
-- 
GPG fingerprint = E738 5471 D185 7013 0EE0  4FC8 3C1D 6F83 12E1 84F6
(subkeys.pgp.net)

"It won't fit on the line."
-- me, 2001

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

Re: BSD.local.dist - share/locale

[Andrew Pantyukhin]

On 8/25/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:

On Thu, 24 Aug 2006 09:50:52 -0500, Andrew Pantyukhin
<[EMAIL PROTECTED]> wrote:

> On 8/24/06, Jeremy Messenger <[EMAIL PROTECTED]> wrote:
>> On Thu, 24 Aug 2006 08:26:53 -0500, Andrew Pantyukhin
>> <[EMAIL PROTECTED]> wrote:
>>
>> > I can't help thinking that the way we're trying to deal with
>> > locale directories is far from optimal. IMHO, there are
>> > several ways to improve the state of things:
>>
>> I think the current how we handle locale is a bit silly, so I personal
>> in
>> favor of create localehier like misc/gnomehier than four suggested
>> below..
>> Honestly, I would be more rather to put mtree that is for ports in
>> somewhere of /usr/ports/ than /etc/mtree/ that way any version of
>> FreeBSD
>> won't have any of left over directories problem.
>
> It's a good idea, but we're back at the second question -
> what if someone fancies to pkg_delete -xf gnomehier?
> There will be no way to get a clean system after that
> other than by reinstalling gnomehier and deleting it after
> all the ports requiring it.

Why would someone want to delete it when it is need? Same things with why
would someone delete library when apps need it? I think it's not our
problem as I haven't seen anyone do that with gnomehier.


Okay, another example. Like Stanislav said, imagine you've
installed gnomehier into PREFIX=A and now you're installing
gfoo into PREFIX=B (A!=B). How will gnomehier ensure that
when both gfoo and gnomehier are deinstalled, nothing is left
behind?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: BSD.local.dist - share/locale

[Andrew Pantyukhin]

On 8/24/06, Stanislav Sedov <[EMAIL PROTECTED]> wrote:

On Fri, 25 Aug 2006 00:09:33 +0400
"Andrew Pantyukhin" <[EMAIL PROTECTED]> mentioned:
> Again, you don't really mean it. Try installing any p5 port into
> a non-localbase prefix, and you'll see that lib/perl5 and Co. will
> be left over after deinstall. Even if you suppose that all ports
> respect PREFIX (which many of them don't), it's not a simple
> task to deal with non-mtree left-overs. I would very much like to
> think that your locale effort is a step towards a better world,
> but it really appears to be a step nowhere at all. I hope I'm too
> short-sighted and mistaken.

Didn't I say the same? ;-) You are not quite right, most of ports
respect PREFIX and remove all directories they creates.


Okay, did you really try a full run on a current ports tree? When
you're talking thousands "most" does not mean "all but a tiny
part". There are plans to add PREFIX-related checks to pointyhat,
but until that happens, battling for clean plists is a lost cause.


I can't really
say why perl/ruby ports don't do this - it may be inaccurate commits, PRs
etc. When creating ocaml framework I've added stubs to automatically
add shared dirs into PLIST. Probably, ruby and perl frameworks require
the same step forward.


They don't do this because they've never done it before. It's in
our history books. I'm not saying that what you're striving to do
is wrong, I'm just saying you're going the wrong way. We've
been trying to move perl stuff out of b.p.m for over three years
now, and we'll do it eventually, but you should understand
that neither thousands of problem reports, nor clear vision can
solve a problem all by themselves. It's coordination of efforts,
continuous discussion, painstaking testing and lots of other
things that make it all happen.

But I'm not trying to get personal here, Stanislav. I can only
hope your future mentor will teach you right from wrong and
direct your exceptional vigor best. I'm just trying to start a
discussion and maybe together we'll find an "open shortest
path".
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"