Re: How do you remove unneeded patch files?
Erwin Lansing wrote: On Tue, Jul 24, 2007 at 02:41:04PM -0500, Paul Schmehl wrote: I'm working on a port upgrade. The existing port has a number of patch files in FILESDIR that are no longer needed. (The changes they made have been incorporated into the distro.) What's the appropriate way to submit those changes? Normally, a send-pr submission will contain the patches for existing port files. There is no patch for these. They need to be removed. I could do this: diff -Naur files/original_patch_file files/empty_file, but I don't know if that removes the file or simply replaces it with an empty one. The result of using that patch would be an empty file. This is also alright to submit it that way, but as a courtesy to the committer (and also to make sure he doesn't forget) it would be good to mention in the PR that file/xyz and files/abc should be removed completely. You really should be unambiguous and clear in explaining that the files are to be deleted. I have had a couple of experiences where ports I maintain did not have the files deleted, and I had to remind the committer. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: powerdot
Nikola Lecic wrote: On Tue, 24 Jul 2007 21:15:57 -0700 Predrag Punosevac <[EMAIL PROTECTED]> wrote: Nikola Lecic wrote: Nobody thinks that TeXLive shouldn't be ported :) What do you mean by "light version"? One of original arguments for not porting TeXLive was that the program is simply to big (over 1Gb). Having downloaded TeXLive (binaries only) on several occasions for my friends over DSL I can confess that that is really the case (at least 3 hours for binaries over 1.5Mps DSL connection) . Binaries are 38M: % du -sh /usr/local/texlive/2007/bin/i386-freebsd/ 38M/usr/local/texlive/2007/bin/i386-freebsd/ (~270 binaries). texmf-dist/: common, platform-independent resources: 972M texmf-doc/: 136M I purpose that the program be ported in the style of Gnome. Light strip down version which would be the minimal fully functional configuration, "full" (English language) version with all bells, and then another port with the support for different languages, another port Music part of the TeXLive etc. Well, yes, of course, this is the way it was done where TeXLive was ported (OpenBSD, Debian...): as modularised as possible. The idea of dividing the port is just initial and should be more carefully considered by the people who know more about various aspects of TeX that I do not use. What makes you think they are not aware of this? Nikola Lečić Well, I hope that they are aware but it seems that nobody is acting on these issues(or at least not fast enough). ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: powerdot
On Tue, 24 Jul 2007 21:15:57 -0700 Predrag Punosevac <[EMAIL PROTECTED]> wrote: > Nikola Lecic wrote: > > > > > > Nobody thinks that TeXLive shouldn't be ported :) What do you mean > > by "light version"? > > > > > One of original arguments for not porting TeXLive was that the > program is simply to big > (over 1Gb). Having downloaded TeXLive (binaries only) on several > occasions for my friends over DSL I can confess that that is really > the case (at least 3 hours for binaries over 1.5Mps DSL connection) . Binaries are 38M: % du -sh /usr/local/texlive/2007/bin/i386-freebsd/ 38M/usr/local/texlive/2007/bin/i386-freebsd/ (~270 binaries). texmf-dist/: common, platform-independent resources: 972M texmf-doc/: 136M > I purpose that the program be ported in the style of Gnome. Light > strip down version which would > be the minimal fully functional configuration, > "full" (English language) version with all bells, and then another > port with the support for different languages, another port Music > part of the TeXLive etc. Well, yes, of course, this is the way it was done where TeXLive was ported (OpenBSD, Debian...): as modularised as possible. > The idea of dividing the port is just > initial and should be more carefully considered by the people who > know more about various aspects of TeX that I do not use. What makes you think they are not aware of this? Nikola Lečić ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: powerdot
Nikola Lecic wrote: Nobody thinks that TeXLive shouldn't be ported :) What do you mean by "light version"? One of original arguments for not porting TeXLive was that the program is simply to big (over 1Gb). Having downloaded TeXLive (binaries only) on several occasions for my friends over DSL I can confess that that is really the case (at least 3 hours for binaries over 1.5Mps DSL connection) . I purpose that the program be ported in the style of Gnome. Light strip down version which would be the minimal fully functional configuration, "full" (English language) version with all bells, and then another port with the support for different languages, another port Music part of the TeXLive etc. The idea of dividing the port is just initial and should be more carefully considered by the people who know more about various aspects of TeX that I do not use. Sincerely, Predrag Punosevac ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fwd: CUPS vs lpt0
I originally sent this to the CUPS maintainer and got a "that would be nice" reply to the last part, so I'm wondering how hard it would be to do :) Hi, Recently I have had trouble using CUPS and I tracked it down to the fact that CUPS [now] appears to access device nodes as a non-root user. Unfortunately this conflicts with the standard permissions for /dev/lpt0. Do you have an opinion on the correct solution? I have an /etc/devfs.rules file with this in it.. [root=100] add path 'lpt*' group cups mode 660 And have this in /etc/rc.conf.. devfs_system_ruleset="root" but this is annoying to have to remember to do for a new install. I wonder if an lpt group should be created by default and then the CUPS user can be a member. Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: powerdot
Hello Predrag, On Tue, 24 Jul 2007 17:02:56 -0700 Predrag Punosevac <[EMAIL PROTECTED]> wrote: > I would like to bring to your attention the fact that there is a new > (actually about 3 years old) Latex class of presentations called > powerdot which replaces obsolete and baggy class of presentations > called prosper (comprehensive information about all Latex classes of > slide presentations can be found at > http://texcatalogue.sarovar.org/bytopic.html#present). > > Prosper is ported for a very long time, beamer another popular class > of presentations is ported as well. However powerdot is not ported. > The advantages of powerdot over beamer are plentiful > (starting with the fact that manual is about 60 pages vs beamer > manual 400pages). The only reason that beamer seems to gain more > popularity is that fact that can be directly compiled by pdflatex > while powerdot requires tex>dvi>ps>pdf. This is really not a problem > since most integrated tex environments allow users to set the option > tex>dvi>ps>pdf for compiling. > > On the same note I believe that the issue of the porting of TeXLive > (light version of course) should be reconsidered [...] Nobody thinks that TeXLive shouldn't be ported :) What do you mean by "light version"? > not just because of the fact that TeXLive includes powerdot and > beamer as a standard packages but because teTeX will not exist for to > much longer (I am not sure if you are familiar with the fact that > teTeX is winding down activities and that LiveTeX is becoming > standard *nix distribution). There was a small discussion related to porting TeXLive to FreeBSD 3-4 days ago, please see the archives; I'm personally interested to see it ported (and to help), too. AFAIK hrs@ is working on it, but still no answer from him. Nikola Lečić ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
powerdot
I would like to bring to your attention the fact that there is a new (actually about 3 years old) Latex class of presentations called powerdot which replaces obsolete and baggy class of presentations called prosper (comprehensive information about all Latex classes of slide presentations can be found at http://texcatalogue.sarovar.org/bytopic.html#present). Prosper is ported for a very long time, beamer another popular class of presentations is ported as well. However powerdot is not ported. The advantages of powerdot over beamer are plentiful (starting with the fact that manual is about 60 pages vs beamer manual 400pages). The only reason that beamer seems to gain more popularity is that fact that can be directly compiled by pdflatex while powerdot requires tex>dvi>ps>pdf. This is really not a problem since most integrated tex environments allow users to set the option tex>dvi>ps>pdf for compiling. On the same note I believe that the issue of the porting of TeXLive (light version of course) should be reconsidered not just because of the fact that TeXLive includes powerdot and beamer as a standard packages but because teTeX will not exist for to much longer (I am not sure if you are familiar with the fact that teTeX is winding down activities and that LiveTeX is becoming standard *nix distribution). Sincerely, Predrag Punosevac Department of Mathematics The University of Arizona (520) 578-9861 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How do you remove unneeded patch files?
On Tue, Jul 24, 2007 at 02:41:04PM -0500, Paul Schmehl wrote: > I'm working on a port upgrade. The existing port has a number of patch > files in FILESDIR that are no longer needed. (The changes they made have > been incorporated into the distro.) What's the appropriate way to submit > those changes? Normally, a send-pr submission will contain the patches for > existing port files. There is no patch for these. They need to be removed. > > I could do this: diff -Naur files/original_patch_file files/empty_file, but > I don't know if that removes the file or simply replaces it with an empty > one. > The result of using that patch would be an empty file. This is also alright to submit it that way, but as a courtesy to the committer (and also to make sure he doesn't forget) it would be good to mention in the PR that file/xyz and files/abc should be removed completely. Cheers, -erwin -- Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_///[EMAIL PROTECTED] And it makes you cry.<) (>[EMAIL PROTECTED] pgprzbx0osTRD.pgp Description: PGP signature
How do you remove unneeded patch files?
I'm working on a port upgrade. The existing port has a number of patch files in FILESDIR that are no longer needed. (The changes they made have been incorporated into the distro.) What's the appropriate way to submit those changes? Normally, a send-pr submission will contain the patches for existing port files. There is no patch for these. They need to be removed. I could do this: diff -Naur files/original_patch_file files/empty_file, but I don't know if that removes the file or simply replaces it with an empty one. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: HEADS UP: Impending autotools changes
On Jul 24, 2007, at 01:58 , Alex Dupre wrote: Ade Lovett ha scritto: Regretfully, particularly in the case of PHP, this will likely require manual intervention outside of the portupgrade/portmaster update methodologies. Can you elaborate, please? Actually, this was a screwup on my part. A simple PORTREVISION bump will take care of this. Sorry for any inconvenience. -aDe ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to include new dirs in @INC
On Tue, Jul 24, 2007 at 12:03:48PM -0500, Paul Schmehl wrote: > --On Tuesday, July 24, 2007 18:16:16 +0200 Anton Berezin <[EMAIL PROTECTED]> > wrote: > >Right. I assume that the port you are creating uses "normal" Makefile.PL > >for a part of the configuration process, while not being the main > >configuration mechanism (that is, the port does not define PERL_CONFIGURE > >in its skeleton). > Yes, but it also uses GNU_CONFIGURE for the main parts of the port. > Is it possible to use both GNU_CONFIGURE *and* PERL_CONFIGURE? Nope, not to my knowledge. > I'll poke around. > Maybe I could pre-build the perl parts? This is a very complex port. Well, it certainly sounds like it is. There are other ports that do something similar, however, for example net/spread. In fact, what it does looks almost exactly like what you need. \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Xorg upgrade issues, pulling wrong lib
Hi, And yes, I did do according to the instructions : Script started on Mon Jul 23 00:05:00 2007 himinbjorg# setenv XORG_UPGRADE yes himinbjorg# portupgrade -Rfi libXft ---> Session started at: Mon, 23 Jul 2007 00:05:34 -0400 ---> Reinstallation of x11/xproto started at: Mon, 23 Jul 2007 00:05:38 -0400 ---> Reinstalling 'xproto-7.0.10' (x11/xproto) OK? [yes] ---> Build of x11/xproto started at: Mon, 23 Jul 2007 00:05:42 -0400 So not sure why I'm running into this and the rest of the world didn't. If the path to the old one is before the new one, no one should have gotten it to work... Or did I do something wrong or have a "special situation"? Thanks, Tuc > > Hi, > > I've asked this on questions, but thought maybe porters would > have a better idea... > > I'm following the directions to upgrade Xorg (REALLY I AM, PROMISE!) > and I'm seeing this fly by my screen : > > /usr/local/bin/bdftopcf -t lubR12-ISO8859-13.bdf | gzip > > lubR12-ISO8859-13.pcf.gz > /libexec/ld-elf.so.1: /usr/X11R6/lib/libXfont.so.1: Undefined symbol > "serverClient" > /usr/local/bin/ucs2any lubR14.bdf > /usr/local/lib/X11/fonts/util/map-ISO8859-13 ISO8859-13 > Writing 192 characters into file 'lubR14-ISO8859-13.bdf'. > > (AND SO ON) > > I won't go any further as I'm sure this is indicating a problem. > But where/how? > > -r-xr-xr-x 1 root wheel 5308 Jul 23 13:18 /usr/local/bin/bdftopcf > /usr/local/bin/bdftopcf: > libXfont.so.1 => /usr/X11R6/lib/libXfont.so.1 (0x2807f000) > libc.so.5 => /lib/libc.so.5 (0x280e5000) > > Looks like its picking up libXfont.so.1 from the /usr/X11R6 : > > -rwxr-xr-x 1 root wheel 424992 Oct 26 2006 /usr/X11R6/lib/libXfont.so.1 > > and not from the local : > > -rwxr-xr-x 1 root wheel 432705 Jul 23 13:18 /usr/local/lib/libXfont.so.1 > > What could cause it? How do I fix it mid build? Is there anything > else I should be looking at? > > So I went to x11-fonts/bdftopcf. I set my XORG_UPGRADE variable > (Just incase) and did : > > ===> Vulnerability check disabled, database not found > ===> Extracting for bdftopcf-1.0.1 > => MD5 Checksum OK for xorg/app/bdftopcf-1.0.1.tar.bz2. > => SHA256 Checksum OK for xorg/app/bdftopcf-1.0.1.tar.bz2. > ===> Patching for bdftopcf-1.0.1 > ===> bdftopcf-1.0.1 depends on file: /usr/local/libdata/pkgconfig/xfont.pc > - found > ===> bdftopcf-1.0.1 depends on executable in : pkg-config - found > ===> Configuring for bdftopcf-1.0.1 > configure: WARNING: you should use --build, --host, --target > checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel > checking whether build environment is sane... yes > checking for gawk... no > checking for mawk... no > checking for nawk... nawk > checking whether make sets $(MAKE)... yes > checking whether to enable maintainer-specific portions of Makefiles... no > checking if xorg-macros used to generate configure is at least 1.1... yes, > 1.1.5 > checking for i386-portbld-freebsd5.5-gcc... cc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether cc accepts -g... yes > checking for cc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of cc... gcc3 > checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel > checking for i386-portbld-freebsd5.5-pkg-config... no > checking for pkg-config... /usr/local/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for BDFTOPCF... yes > checking build system type... i386-portbld-freebsd5.5 > checking host system type... i386-portbld-freebsd5.5 > configure: creating ./config.status > config.status: creating Makefile > config.status: creating config.h > config.status: executing depfiles commands > ===> Building for bdftopcf-1.0.1 > make all-am > if cc -DHAVE_CONFIG_H -I. -I. -I.-I/usr/local/include > -I/usr/local/include/freetype2 -O -pipe -MT bdftopcf-bdftopcf.o -MD -MP -MF > ".deps/bdftopcf-bdftopcf.Tpo" -c -o bdftopcf-bdftopcf.o `test -f 'bdftopcf.c' > || echo './'`bdftopcf.c; then mv -f ".deps/bdftopcf-bdftopcf.Tpo" > ".deps/bdftopcf-bdftopcf.Po"; else rm -f ".deps/bdftopcf-bdftopcf.Tpo"; exit > 1; fi > cc -O -pipe -o bdftopcf bdftopcf-bdftopcf.o -L/usr/local/lib -lXfont > sed -e 's|__vendorversion__|"bdftopcf 1.0.1" "X Version 11"|' -e > 's|__xorgversion__|"bdftopcf 1.0.1" "X Version 11"|' -e > 's|__xservername__|Xorg|g' -e 's|__xconfigfile__|xorg.conf|g' -e > 's|__projectroot__|/usr/local|g' -e 's|__apploaddir__||' -e > 's|__appmansuffix__|1|g' -e 's|__libmansuffix__|3|g' -e > 's|__adminmansuffix__|8|g' -e 's|__miscmansuffix__|7|g' -e > 's|__fil
Re: How to include new dirs in @INC
--On Tuesday, July 24, 2007 18:16:16 +0200 Anton Berezin <[EMAIL PROTECTED]>
wrote:
Right. I assume that the port you are creating uses "normal" Makefile.PL
for a part of the configuration process, while not being the main
configuration mechanism (that is, the port does not define PERL_CONFIGURE
in its skeleton).
Yes, but it also uses GNU_CONFIGURE for the main parts of the port. So, in
the Makefile, I have:
GNU_CONFIGURE= Yes
USE_PERL= Yes
Is it possible to use both GNU_CONFIGURE *and* PERL_CONFIGURE? Because the
port needs to compile not just the perl scripts but a great deal of C code
as well.
In bsd.port.mk, there is a special handling of the ports that do define
PERL_CONFIGURE to make them PREFIX-clean. Unfortunately, this handling is
not kicking in for special cases such as yours.
The relevant lines from bsd.port.mk:
.if defined(PERL_CONFIGURE)
CONFIGURE_ARGS+= CC="${CC}" CCFLAGS="${CFLAGS}" PREFIX="${TARGETDIR}" \
INSTALLPRIVLIB="${TARGETDIR}/lib" INSTALLARCHLIB="${TARGETDIR}/lib"
.
So, if you can duplicate the setting of INSTALLPRIVLIB and INSTALLARCHLIB
wherever "perl Makefile.PL" is run during configuration process of your
port, this should make Perl modules installed by the port PREFIX-clean.
If Build.PL is used instead, there is a similar way which you can look up
in bsd.port.mk yourself.
I'll poke around. I was unsure if I could use both GNU_CONFIGURE *and*
PERL_CONFIGURE in the same port. That's why I didn't use PERL_CONFIGURE.
Maybe I could pre-build the perl parts? This is a very complex port. I've
spent untold hours getting it working. If I can get the perl part working
right, then I can eliminate the pkg-deinstall script, but I'm not sure it's
worth the effort.
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
Re: emacs22
Hi,
> On Tue, 24 Jul 2007 10:43:33 -0400
> Duane Winner <[EMAIL PROTECTED]> said:
dwinner> Please confirm that I'm doing the right thing:
dwinner> I followed /usr/ports/UPDATING to upgrade emacs21 to emacs 22 by
adding
dwinner> EMACS_PORT_NAME=emacs22 to make.conf
dwinner> After that, any time I do a portsdb -Uu to follow-up on my cvsup, I
dwinner> would get a dependency list incomplete error (lsdb-emacs22-0.10_1:
dwinner> "/usr/ports/editors/flim-emacs22" non-existent).
dwinner> Even though /usr/ports/UPDATING doesn't say anything about removing
dwinner> "EMACS_PORT_NAME=emacs22" from make.conf after the upgrade, I tried
dwinner> taking it out and running portsdb -Uu again.
dwinner> Now it works.
dwinner> Is this the correct thing to do?
Perhaps, the following patch fixes your problem. This patch changes
to obey default EMACS_PORT_NAME defined in bsd.emacs.mk, as well.
Index: databases/lsdb/Makefile
diff -u databases/lsdb/Makefile.orig databases/lsdb/Makefile
--- databases/lsdb/Makefile.origMon May 21 05:03:59 2007
+++ databases/lsdb/Makefile Wed Jul 25 01:48:39 2007
@@ -18,11 +18,13 @@
BUILD_DEPENDS=
${LOCALBASE}/share/flim/${FLIM_COOKIE}:${PORTSDIR}/editors/flim${DEPPORT_SUFFIX}
USE_EMACS= yes
-EMACS_PORT_NAME?= emacs21
-.if (${EMACS_PORT_NAME} == emacs21)
-DEPPORT_SUFFIX=
-.else
+
+.include
+
+.if ${EMACS_PORT_NAME} == emacs20
DEPPORT_SUFFIX=-${EMACS_PORT_NAME}
+.else
+DEPPORT_SUFFIX=
.endif
SFJP_RELEASE_ID= 1494
@@ -40,4 +42,4 @@
${INSTALL_DATA} ${WRKSRC}/README ${DOCSDIR}
.endif
-.include
+.include
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to include new dirs in @INC
On Tue, Jul 24, 2007 at 10:17:53AM -0500, Paul Schmehl wrote:
> --On Tuesday, July 24, 2007 16:25:14 +0200 Anton Berezin <[EMAIL PROTECTED]>
> wrote:
>
> >On Tue, Jul 24, 2007 at 09:18:17AM -0500, Paul Schmehl wrote:
> >
> >>BTW, maybe you know the answer to this. I can't remove the perl modules
> >>in pkg-plist because it prepends PREFIX to SITE_PERL, making the
> >>location /usr/local/usr/local/lib/perl5/site_perl/5.8.8. This seems to
> >>me to be a bug. Shouldn't pkg-plist honor SITE_PERL and not prepend
> >>PREFIX?
> >
> >Hmmm. I assume you are using %%SITE_PERL%% as the prefix in the
> >pkg-plist?
> >
> Yes, that's correct.
>
> >bsd.port.mk defines ${SITE_PERL} as ${PREFIX}${SITE_PERL_REL}, and it
> >defines a plist substitution %%SITE_PERL%% to be the same as
> >${SITE_PERL_REL}, so in most circumstances it "just works".
> >
> I tried both %%SITE_PERL%% and %%SITE_PERL_REL%% and both failed.
>
> >Maybe a snippet of your pkg-plist together with *-install Makefile targets
> >(if any) would help to see what's wrong?
> >
> The %%SITE_PERL%% stuff is no longer in pkg-plist. I moved it to the
> pkg-deinstall script. I could do some more testing, I suppose.
>
> OK, commented out one of the modules in the pkg-deinstall script and added
> it to pkg-plist like this:
> %%SITE_PERL%%/mach/IP4.pm
>
> Then I installed the port and confirmed that the module was installed:
> ls /usr/local/lib/perl5/site_perl/5.8.8/mach/IP4.pm
> /usr/local/lib/perl5/site_perl/5.8.8/mach/IP4.pm
>
> Then I deinstalled the port and got this error:
> make deinstall PREFIX=/var/tmp/$(make -V PORTNAME)
> ===> Deinstalling for security/bro
> ===> Deinstalling bro-1.2
> pkg_delete: file '/var/tmp/bro/lib/perl5/site_perl/5.8.8/mach/IP4.pm'
> doesn't exist
> pkg_delete: couldn't entirely delete package (perhaps the packing list is
> incorrectly specified?)
>
> As you can see, SITE_PERL is prepending PREFIX to SITE_PERL_REL (as you
> said), but perl modules are *always* installed in
> /usr/local/lib/perl5/site_perl/blah, are they not?
>
> IOW, this will work fine in pkg-plist *if* (and only if) PREFIX is the
> default. If the installer changes PREFIX to anything else, the perl
> modules will not be uninstalled and the deinstall will generate an error.
> (Installing the perl modules in non-standard-PREFIX/lib/blah makes no sense
> because the scripts won't work because @INC doesn't include non-standard
> locations by default.)
>
> Perhaps the correct way to resolve this is to change bsd.port.mk to define
> ${SITE_PERL} in pkg-plist as ${LOCALBASE}/${SITE_PERL_REL} instead of
> ${PREFIX}/${SITE_PERL_REL}? No matter what PREFIX an installer chooses,
> perl modules should always be in LOCALBASE, right?
Right. I assume that the port you are creating uses "normal" Makefile.PL
for a part of the configuration process, while not being the main
configuration mechanism (that is, the port does not define PERL_CONFIGURE in
its skeleton).
In bsd.port.mk, there is a special handling of the ports that do define
PERL_CONFIGURE to make them PREFIX-clean. Unfortunately, this handling is
not kicking in for special cases such as yours.
The relevant lines from bsd.port.mk:
.if defined(PERL_CONFIGURE)
CONFIGURE_ARGS+= CC="${CC}" CCFLAGS="${CFLAGS}" PREFIX="${TARGETDIR}" \
INSTALLPRIVLIB="${TARGETDIR}/lib" INSTALLARCHLIB="${TARGETDIR}/lib"
.
So, if you can duplicate the setting of INSTALLPRIVLIB and INSTALLARCHLIB
wherever "perl Makefile.PL" is run during configuration process of your
port, this should make Perl modules installed by the port PREFIX-clean.
If Build.PL is used instead, there is a similar way which you can look up in
bsd.port.mk yourself.
Hope this helps.
\Anton.
--
We're going for 'working' here. 'clean' is for people with skills...
-- Flemming Jacobsen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to include new dirs in @INC
--On Tuesday, July 24, 2007 16:25:14 +0200 Anton Berezin <[EMAIL PROTECTED]>
wrote:
On Tue, Jul 24, 2007 at 09:18:17AM -0500, Paul Schmehl wrote:
BTW, maybe you know the answer to this. I can't remove the perl modules
in pkg-plist because it prepends PREFIX to SITE_PERL, making the
location /usr/local/usr/local/lib/perl5/site_perl/5.8.8. This seems to
me to be a bug. Shouldn't pkg-plist honor SITE_PERL and not prepend
PREFIX?
Hmmm. I assume you are using %%SITE_PERL%% as the prefix in the
pkg-plist?
Yes, that's correct.
bsd.port.mk defines ${SITE_PERL} as ${PREFIX}${SITE_PERL_REL}, and it
defines a plist substitution %%SITE_PERL%% to be the same as
${SITE_PERL_REL}, so in most circumstances it "just works".
I tried both %%SITE_PERL%% and %%SITE_PERL_REL%% and both failed.
Maybe a snippet of your pkg-plist together with *-install Makefile targets
(if any) would help to see what's wrong?
The %%SITE_PERL%% stuff is no longer in pkg-plist. I moved it to the
pkg-deinstall script. I could do some more testing, I suppose.
OK, commented out one of the modules in the pkg-deinstall script and added
it to pkg-plist like this:
%%SITE_PERL%%/mach/IP4.pm
Then I installed the port and confirmed that the module was installed:
ls /usr/local/lib/perl5/site_perl/5.8.8/mach/IP4.pm
/usr/local/lib/perl5/site_perl/5.8.8/mach/IP4.pm
Then I deinstalled the port and got this error:
make deinstall PREFIX=/var/tmp/$(make -V PORTNAME)
===> Deinstalling for security/bro
===> Deinstalling bro-1.2
pkg_delete: file '/var/tmp/bro/lib/perl5/site_perl/5.8.8/mach/IP4.pm'
doesn't exist
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
As you can see, SITE_PERL is prepending PREFIX to SITE_PERL_REL (as you
said), but perl modules are *always* installed in
/usr/local/lib/perl5/site_perl/blah, are they not?
IOW, this will work fine in pkg-plist *if* (and only if) PREFIX is the
default. If the installer changes PREFIX to anything else, the perl
modules will not be uninstalled and the deinstall will generate an error.
(Installing the perl modules in non-standard-PREFIX/lib/blah makes no sense
because the scripts won't work because @INC doesn't include non-standard
locations by default.)
Perhaps the correct way to resolve this is to change bsd.port.mk to define
${SITE_PERL} in pkg-plist as ${LOCALBASE}/${SITE_PERL_REL} instead of
${PREFIX}/${SITE_PERL_REL}? No matter what PREFIX an installer chooses,
perl modules should always be in LOCALBASE, right?
--
Paul Schmehl ([EMAIL PROTECTED])
Senior Information Security Analyst
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
Re: FreeBSD Port: wxglade-0.5_1
On Wed, 11 Jul 2007 20:45:06 + Ewout Boks <[EMAIL PROTECTED]> wrote: > Hi, > > i was wondering whether you could help me out on this; I have used > wxGlade since version 0.3 and now, after having installed 0.5, I end up > with a Glade windows where the icons aren't visible (see attached > screenshot). > > I looked on the internet for clues and similar problems but to no avail. > I think it is a FreeBSD problem, but am not sure. Perhaps you have > experienced something alike? > > Best regards, > Hello. I don't use the port, I maintain it because it was unmaintained and broken before. But I will check the source code for Linux specific code or the like. Best Regards, Ale signature.asc Description: PGP signature
emacs22
Hello, Please confirm that I'm doing the right thing: I followed /usr/ports/UPDATING to upgrade emacs21 to emacs 22 by adding EMACS_PORT_NAME=emacs22 to make.conf After that, any time I do a portsdb -Uu to follow-up on my cvsup, I would get a dependency list incomplete error (lsdb-emacs22-0.10_1: "/usr/ports/editors/flim-emacs22" non-existent). Even though /usr/ports/UPDATING doesn't say anything about removing "EMACS_PORT_NAME=emacs22" from make.conf after the upgrade, I tried taking it out and running portsdb -Uu again. Now it works. Is this the correct thing to do? Thanks DW ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to include new dirs in @INC
On Tue, Jul 24, 2007 at 09:18:17AM -0500, Paul Schmehl wrote:
> >So problem solved, or?
> Problem solved.
Nice!
> BTW, maybe you know the answer to this. I can't remove the perl modules in
> pkg-plist because it prepends PREFIX to SITE_PERL, making the location
> /usr/local/usr/local/lib/perl5/site_perl/5.8.8. This seems to me to be a
> bug. Shouldn't pkg-plist honor SITE_PERL and not prepend PREFIX?
Hmmm. I assume you are using %%SITE_PERL%% as the prefix in the pkg-plist?
bsd.port.mk defines ${SITE_PERL} as ${PREFIX}${SITE_PERL_REL}, and it
defines a plist substitution %%SITE_PERL%% to be the same as
${SITE_PERL_REL}, so in most circumstances it "just works".
Maybe a snippet of your pkg-plist together with *-install Makefile targets
(if any) would help to see what's wrong?
\Anton.
--
We're going for 'working' here. 'clean' is for people with skills...
-- Flemming Jacobsen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to include new dirs in @INC
--On Tuesday, July 24, 2007 11:57:18 +0200 Anton Berezin <[EMAIL PROTECTED]> wrote: On Mon, Jul 23, 2007 at 05:13:50PM -0500, Paul Schmehl wrote: > Alternatively, you need to figure out whether you can place the modules > into a standard location. It looks like you are trying to do that, but > clearly you are doing something wrong. What are the names of the > modules and their packages? After checking the scripts, all of them refer to Bro::Module except one. So I can put that one module (IP4.pm) in /mach and solve the problem that way. The others appear to be correctly coded. So problem solved, or? Problem solved. I had two options; patch the script or install the one module in SITE_PERL/mach. I chose the latter. The rest of the modules and scripts work fine because they call the modules correctly - use Bro::Report::Conn.pm; (for example.) The one script simply called IP4.pm without any directory (use IP4.pm;) I was hoping to keep all the modules in one location, unique to the port, but it made more sense to me not to edit the script. BTW, maybe you know the answer to this. I can't remove the perl modules in pkg-plist because it prepends PREFIX to SITE_PERL, making the location /usr/local/usr/local/lib/perl5/site_perl/5.8.8. This seems to me to be a bug. Shouldn't pkg-plist honor SITE_PERL and not prepend PREFIX? I solved the problem by writing a pkg-deinstall script that removes the modules and directories, but seems like a kludgy solution to me. -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: apache13+ssl on 64bit system on amd64
Hallo Bakul Shah, > This used to work under 32 bit kernel+userland on the same > machine. After I switched to a 64 bit kernel+userland, I > used original 32 httpsd until now. Today I decided to > compile it for 64 bit and now it dies with: > > # /usr/local/etc/rc.d/apache.sh start > Syntax error on line 208 of /usr/local/etc/apache/httpsd.conf: > Cannot load /usr/local/libexec/apache/mod_mmap_static.so into server: /usr/loc > al/libexec/apache/mod_mmap_static.so: Undefined symbol "ap_null_cleanup" > > And yet apache13 works fine. Has anyone else seen this? Any workaround? Yes, Please rebuild all apache modules, as the module ABI is diffrent. kind regards Dirk - Dirk Meyer, Im Grund 4, 34317 Habichtswald, Germany - [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED] http://people.freebsd.org/~dinoex/errorlogs/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Perl Dependancies in 7-CURRENT
A bit more background on my ports building adventure. I have one system I am using as a master ports system. It exports the ports tree via nfs. The system I am attempting to build on has the ports tree rw nfs mounted, and rw null mounted into a jail I am attempting to build up (using ezjail to create the jails and the nullfs ports "trick" to mount the base system /usr/ports - an nfs mount - into the jail). The 0 length perl Makefiles affected both the base (nfs mounted) and jailed (null mounted) systems. I went back to the exporting exporting and did a portsnap to bring the system ports tree up to date - still the issue persisted. So I built perl on the ports exporting system and suddenly the nfs mounting system could successfully build and installed. The jail with the nullfs mounted /usr/ports still gets 0 length makefiles. My temporary solution is to nfs mount the /usr/ports into the jail from the base system as well. I am cc'ing this to current for information and more eyes :) -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: bash-3.2.17_2
Hi Obrien, portupgrading bash from 3.1.17 to 3.2.17_2 is finished with error about missing autoconf. It is interesting why bash needs autoconf while compiling and for the second I have autoconf package, but it is useless for that as you can see below. What can I do to fix it? Thanks Bye Dan configure: creating ./config.status config.status: creating Makefile config.status: creating builtins/Makefile config.status: creating lib/readline/Makefile config.status: creating lib/glob/Makefile config.status: creating lib/intl/Makefile config.status: creating lib/malloc/Makefile config.status: creating lib/sh/Makefile config.status: creating lib/termcap/Makefile config.status: creating lib/tilde/Makefile config.status: creating doc/Makefile config.status: creating support/Makefile config.status: creating po/Makefile.in config.status: creating examples/loadables/Makefile config.status: creating examples/loadables/perl/Makefile config.status: creating pathnames.h config.status: creating config.h config.status: executing default-1 commands config.status: creating po/POTFILES config.status: creating po/Makefile config.status: executing default commands ===> Building for bash-3.2.17_2 yacc -d ./parse.y yacc: 1 shift/reduce conflict touch parser-built cd . && autoconf autoconf: not found *** Error code 127 Stop in /usr/ports/tmp/usr/ports/shells/bash/work/bash-3.2. *** Error code 1 Stop in /usr/ports/shells/bash. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall.50881.0 en ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! shells/bash (unknown build error) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed # # pkg_info autoconf-2.59_2 Automatically configure source code on many Un*x platforms bmon-2.1.0 Portable bandwidth monitor and rate estimator bsdstats-5.3_4 Monthly script for reporting anonymous statistics about you cvsup-without-gui-16.1h_3 General network file distribution system optimized for CVS db41-4.1.25_4 The Berkeley DB package, revision 4.1 gettext-0.16.1_3GNU gettext package glib-2.12.13Some useful routines of C programming (current stable versi gmake-3.81_2GNU version of 'make' utility gnu-watch-3.2.7 GNU watch command help2man-1.36.4_1 Automatically generating simple manual pages from program o ipfw2dshield-0.5A DShield client for ipfw logs isc-dhcp3-server-3.0.5_2 The ISC Dynamic Host Configuration Protocol server kismet-200701.r1802.11 layer2 wireless network detector, sniffer, and IDS libiconv-1.9.2_2A character set conversion library libtool-1.5.22_4Generic shared library support script lsof-4.79B Lists information about open files (similar to fstat(1)) m4-1.4.9GNU m4 mc-4.6.1_5 Midnight Commander, a free Norton Commander Clone net-snmp-5.3.1_3An extendable SNMP implementation openntpd-3.9p1_1,2 OpenBSD's Network Time Protocol daemon p5-gettext-1.05_1 Message handling functions perl-5.8.8 Practical Extraction and Report Language pkg-config-0.22 A utility to retrieve information about installed libraries portaudit-0.5.11Checks installed ports against a list of security vulnerabi portupgrade-2.3.1,2 FreeBSD ports/packages administration and management tool s quagga-0.99.7_2 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software ruby-1.8.6_2,1 An object-oriented interpreted scripting language ruby18-bdb-0.6.0Ruby interface to Sleepycat's Berkeley DB revision 2 or lat screen-4.0.3A multi-screen window manager sudo-1.6.9 Allow others to run commands as root trafshow-5.2.3,1Full screen visualization of network traffic uptimed-0.3.7 Rob Kaper's uptime daemon wget-1.10.2_1 Retrieve files from the Net via HTTP and FTP ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Perl Dependancies in 7-CURRENT
> This snipped part is probably the most interesting to determine what caused > this in your setup... Actually it isn't - here is a much simpler, complete example: /usr/ports/dns/p5-Net-DNS: mx1# cd /usr/ports/dns/p5-Net-DNS mx1# ls Makefiledistinfofiles pkg-descr pkg-plist mx1# make clean ===> Cleaning for p5-Net-DNS-0.60 mx1# make ===> Vulnerability check disabled, database not found ===> Found saved configuration for p5-Net-DNS-0.60 ===> Extracting for p5-Net-DNS-0.60 => MD5 Checksum OK for Net-DNS-0.60.tar.gz. => SHA256 Checksum OK for Net-DNS-0.60.tar.gz. ===> p5-Net-DNS-0.60 depends on file: /usr/local/bin/perl5.8.8 - found ===> Patching for p5-Net-DNS-0.60 ===> p5-Net-DNS-0.60 depends on file: /usr/local/bin/perl5.8.8 - found ===> p5-Net-DNS-0.60 depends on file: /usr/local/bin/perl5.8.8 - found ===> Configuring for p5-Net-DNS-0.60 Testing if you have a C compiler and the needed header files You have a working compiler. Checking if your kit is complete... Looks good Writing Makefile for Net::DNS ===> Building for p5-Net-DNS-0.60 make: don't know how to make all. Stop *** Error code 2 Stop in /usr/ports/dns/p5-Net-DNS. *** Error code 1 Stop in /usr/ports/dns/p5-Net-DNS. mx1# ls -l work/Net-DNS-0.60/Makefile -rw-r--r-- 1 root wheel 0 Jul 24 08:00 work/Net-DNS-0.60/Makefile mx1# As you can see, 0 length Makefile. If i go into the work directory and issues a perl Makefile.PL, it generates one, without any patches being properly applied. -- Tony Holmes Ph: (416) 993-1219 Founder and Senior Systems Architect Crosswinds Internet Communications Inc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: x11-themes/kde-icons-icosx - PLEASE DON'T DELETE
In general the way we want to assign maintainership is in conjunction with a port update/fix. Please submit anything that you come up with via GNATS. Even if in the meantime the port gets deleted, it can easily be brought back from the Attic. Thanks for volunteering to help. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Perl Dependancies in 7-CURRENT
On Mon, Jul 23, 2007 at 10:18:26PM -0400, Tony Holmes wrote: > System Info: > > 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Fri Jul 20 08:42:22 EDT 2007 amd64 > > Ports cvsup'd at 7pm EST, July 23, 2007. > > I am installing various ports as part of an incoming mail system. I have > found that *all* perl ports are failing to generate a valid Makefile. > > eg: p5-Mail-SpamAssassin: > > mx1# make > > [snip] This snipped part is probably the most interesting to determine what caused this in your setup... > Writing Makefile for Mail::SpamAssassin > Makefile written by ExtUtils::MakeMaker 6.30 > ===> Building for p5-Mail-SpamAssassin-3.2.1_1 > make: don't know how to make all. Stop > *** Error code 2 Cheers, \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to include new dirs in @INC
On Mon, Jul 23, 2007 at 05:13:50PM -0500, Paul Schmehl wrote: > >Alternatively, you need to figure out whether you can place the modules > >into a standard location. It looks like you are trying to do that, but > >clearly you are doing something wrong. What are the names of the modules > >and their packages? > After checking the scripts, all of them refer to Bro::Module except one. > So I can put that one module (IP4.pm) in /mach and solve the problem that > way. The others appear to be correctly coded. So problem solved, or? \Anton. -- We're going for 'working' here. 'clean' is for people with skills... -- Flemming Jacobsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: Impending autotools changes
Ade Lovett ha scritto: Regretfully, particularly in the case of PHP, this will likely require manual intervention outside of the portupgrade/portmaster update methodologies. Can you elaborate, please? -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
x11-themes/kde-icons-noia - PLEASE DON'T DELETE
Greetings, Would anybody be willing to assign this port to me? I have all the components, and hope to add some enhancements soon. Thank you for all your time and consideration. -- panic: kernel trap (ignored) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
x11-themes/kde-icons-icosx - PLEASE DON'T DELETE
Greetings, Did I get your attention. ;) If nobody has any objection, may I adopt this port? I have all the components, and intended to do some modifications/ enhancements in the near future. Thank you for all your time and consideration. -- panic: kernel trap (ignored) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
