Samba problem
Hi all, I have installed freebsd 6.1-RELEASE on my machine and now samba dont work, because of a timeout. I've tried the two versions of the samba ports and none of them work properly. Do you have any idea? Ouput: osiris# mount -t smbfs //porta1/tmpdown /tmpdir Password: mount_smbfs: unable to open connection: syserr = Operation timed out Otherwise, this is not an password error. Best Regards, Carlos Silva, CSilva Web: http://www.csilva.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Samba problem
On Tue, Aug 15, 2006 at 10:10:19AM +0100, Carlos Silva wrote: > Hi all, > > I have installed freebsd 6.1-RELEASE on my machine and now samba dont > work, because of a timeout. > I've tried the two versions of the samba ports and none of them work > properly. > Do you have any idea? > > Ouput: > > osiris# mount -t smbfs //porta1/tmpdown /tmpdir > Password: > > mount_smbfs: unable to open connection: syserr = Operation timed out > > Otherwise, this is not an password error. I can confirm this. something happened and now I am not able to mount smb shares on 6.1R.. on 6.0R it works ok. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Dmitry Marakasov wrote:
Hi!
I'm now exploring new DESTDIR-related stuff, and I find it far from
being useable. More of that, DESTDIR-related changes seem dangerous
to me.
As far as I understand, for port to support DESTDIR, it's files
should be installed into ${DESTDIR}/${PREFIX}/foo (aka ${TARGETDIR}/foo),
but all paths compiled into binaries (or config files) should remain
`local' (i.e. ${PREFIX}/foo). Thus, when DESTDIR used, port will
be installed into (for example) jail environment specified in
DESTDIR, and will correctly work in that environment after chroot'ing
into in. Am I right?
Yes.
Now, I think the way DESTDIR-related changes were done to bsd.port.mk is
absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
DESTDIR. But, these variables are frequently used when changing paths
hardcoded in port's sources (see many of my ports, for example
games/fishsupper:
@${REINPLACE_CMD} -e 's|data/|${DATADIR}/|' ${WRKSRC}/src/getreadydisplay.cc
After change, all these ports will not support DESTDIR automatically.
Incomplete list of such ports:
find /usr/ports -name Makefile -exec grep -E \
"REINPLACE_CMD.*(DATADIR|LOCALBASE|X11BASE)" {}
Now, if we want to fix these, we'll need to change variables in
REINPLACE_CMD lines: LOCALBASE to LOCALBASE_REL, X11BASE to X11BASE_REL
and DATADIR... hmm, we have no DATADIR_REL, so all is left is
${PREFIX}/share/${PORTNAME}. That's unforgivable.
Yes, that's right as well, but note if we had left LOCALBASE, LINUXBASE,
X11BASE unchanged, we would need to change them in the *_DEPENDS lines.
That's true that we don't have DATADIR_REL, etc. We could introduce them
if needed, but that substitution can be done with make :S as well.
DESTDIR implementation is complicated in many ways, no perfect
implementation exist. As you said LOCALBASE is used in substitutions, bu
also used in *_DEPENDS as well. Now those two cases have to be
distinguished. One of them should have been changed at all... That's why
I say no perfect implementation exist. If we implement new functions
later, it can be very difficult...
Also I see that new TARGETDIR/DESTDIR/...DIR scheme brings confusion.
Latest DESTDIR-related port update that I see:
http://www.freshports.org/x11-wm/jwm/[EMAIL PROTECTED]
notice this:
(http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-wm/jwm/Makefile.diff?r1=1.11&r2=1.12)
[EMAIL PROTECTED] -e 's|%%PREFIX%%|${PREFIX}|' ${WRKSRC}/example.jwmrc
[EMAIL PROTECTED] -e 's|%%PREFIX%%|${TARGETDIR}|' ${WRKSRC}/example.jwmrc
Now example.jwmrc will contain GLOBAL system path, not jail-local one,
which is of course wrong.
Please tell that I'm stupid if I am wrong somewhere, but I think
DESTDIR support, being introduced into ports collection in a way it's
currently introduced, will bring much pain.
It will, but I tried to avoid the most of the necessary pain. Changing
all of *_DEPENDS would be good? I don't think so... As for this change,
it is actually wrong. I CC'd the maintainer.
In the HEADS-UP message I sent, I wrote that one can feel free to
contact me to review and test patches. Some people already did so. As my
time lets me doing so, I test every patches sent to me.
What I propose is:
- Change variable naming scheme.
All *BASE and *DIR vars should be reverted to their original meanings
(i.e. local paths). Instead, INSTALL_ vars should be introduced:
INSTALL_LOCALBASE=${DESTDIR}/${LOCALBASE}
INSTALL_X11BASE=${DESTDIR}/${X11BASE}
INSTALL_PREFIX=${DESTDIR}/${PREFIX}
INSTALL_DATADIR=${DESTDIR}/${DATADIR}
I don't think it will happen. It just makes the whole thing much more
complicated.
etc. These should be used in do-install target.
* This is far more clean and understandable,
* This allows us to make all ports (around 5k) that define do-install target
DESTDIR-compatible (there still may be issues, but nevertheless).
- Introduce variable DESTDIR_COMPATIBLE to explititely mark
DESTDIR-compatible ports.
This is going to happen but in the opposite manner. We are planning to
run an -exp run in the pointyhat cluster with DESTDIR set, and fix at
least some of the most common ports, and mark the other ones NO_DESTDIR
or something like that.
* I don't think DESTDIR compatibility can be tested automatically, so
this would make freebsd user's life easier (user will be sure that after he
installs ports into [jail|other freebsd installation mounted via
nfs|locally] being set corresponging DESTDIR, nothing will break).
Without such variable, he'll never be sure.
* Port maintainers will know what ports still are to be converted.
Nothing will be forgotten.
P.S.: Please don't make other people panic with such subject. Other
people also reviewed my code. We are just people, so we can make
mistakes as well, but you can be sure that such a big change like
DESTDIR got enough reviewal and test before committed into Mk. Portmgr
is for ensuring people that only rational and working code gets
committed into bsd.port.m
Re: ATTENTION: is the way DESTDIR was introduced completely wrong?
Sergey Matveychuk wrote:
Dmitry Marakasov wrote:
What I propose is:
- Change variable naming scheme.
All *BASE and *DIR vars should be reverted to their original meanings
(i.e. local paths). Instead, INSTALL_ vars should be introduced:
INSTALL_LOCALBASE=${DESTDIR}/${LOCALBASE}
INSTALL_X11BASE=${DESTDIR}/${X11BASE}
INSTALL_PREFIX=${DESTDIR}/${PREFIX}
INSTALL_DATADIR=${DESTDIR}/${DATADIR}
etc. These should be used in do-install target.
* This is far more clean and understandable,
* This allows us to make all ports (around 5k) that define do-install target
DESTDIR-compatible (there still may be issues, but nevertheless).
I agree with every your word.
I was to implement it in this way, but as I said this would require us
to change all of the *_DEPENDS lines. Erwin told me that this can't be
happen, so I was pushed to go the another way. Erwin is in portmgr, and
portmgr's word make sense in these questions...
- Introduce variable DESTDIR_COMPATIBLE to explititely mark
DESTDIR-compatible ports.
* I don't think DESTDIR compatibility can be tested automatically, so
this would make freebsd user's life easier (user will be sure that after he
installs ports into [jail|other freebsd installation mounted via
nfs|locally] being set corresponging DESTDIR, nothing will break).
Without such variable, he'll never be sure.
* Port maintainers will know what ports still are to be converted.
Nothing will be forgotten.
This is exactly I proposed. But I've not been heard.
You have been, but this will happen later, after an -exp run as Erwin
said. And in the opposite form. Ports that don't respect DESTDIR will be
marked.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Samba problem
that's a big problem.. i've tried to install a NFS server on windowsXP but the filesystem doesnt work very fine with that. so, someone has an idea? Best Regards, Carlos Silva, CSilva Web: [1]http://www.csilva.org/ Divacky Roman escreveu: On Tue, Aug 15, 2006 at 10:10:19AM +0100, Carlos Silva wrote: Hi all, I have installed freebsd 6.1-RELEASE on my machine and now samba dont work, because of a timeout. I've tried the two versions of the samba ports and none of them work properly. Do you have any idea? Ouput: osiris# mount -t smbfs //porta1/tmpdown /tmpdir Password: mount_smbfs: unable to open connection: syserr = Operation timed out Otherwise, this is not an password error. I can confirm this. something happened and now I am not able to mount smb shares on 6.1R.. on 6.0R it works ok. ___ [EMAIL PROTECTED] mailing list [3]http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [4]"[EMAIL PROTECTED]" References 1. http://www.csilva.org/ 2. mailto:freebsd-current@freebsd.org 3. http://lists.freebsd.org/mailman/listinfo/freebsd-current 4. mailto:[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: Samba problem
Hi all, I am using samba-3.0.21b,1 succefully on 6.1-RELEASE-p3 box without any problem. But portaudit marks the package like problemed. Also the port has IGNORE mark and I can't upgrade samba. Regards Roman Streltsov - Original Message - From: "Carlos Silva" <[EMAIL PROTECTED]> To: ; Sent: Tuesday, August 15, 2006 2:08 PM Subject: Re: Samba problem that's a big problem.. i've tried to install a NFS server on windowsXP but the filesystem doesnt work very fine with that. so, someone has an idea? Best Regards, Carlos Silva, CSilva Web: [1]http://www.csilva.org/ Divacky Roman escreveu: On Tue, Aug 15, 2006 at 10:10:19AM +0100, Carlos Silva wrote: Hi all, I have installed freebsd 6.1-RELEASE on my machine and now samba dont work, because of a timeout. I've tried the two versions of the samba ports and none of them work properly. Do you have any idea? Ouput: osiris# mount -t smbfs //porta1/tmpdown /tmpdir Password: mount_smbfs: unable to open connection: syserr = Operation timed out Otherwise, this is not an password error. I can confirm this. something happened and now I am not able to mount smb shares on 6.1R.. on 6.0R it works ok. ___ [EMAIL PROTECTED] mailing list [3]http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [4]"[EMAIL PROTECTED]" References 1. http://www.csilva.org/ 2. mailto:freebsd-current@freebsd.org 3. http://lists.freebsd.org/mailman/listinfo/freebsd-current 4. mailto:[EMAIL PROTECTED] ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mail/roundcube on 6.1 - httpd go balistic
Hi Florent, I'm running 6.1, apache 2.2.3, PHP 4 (and 5). Oh, and roundcube (the latest from the ports collection and the 0.1-beta2). When loading an email in Roundcube, the httpd processes start to go balastic: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 15361 www 1 1080 23416K 16396K RUN0 2:14 20.80% httpd 15368 www 1 1080 24236K 17240K RUN0 0:12 18.70% httpd 15359 www 1 1080 23424K 16396K RUN0 0:10 17.48% httpd 15362 www 1 1080 23672K 16640K RUN0 2:00 17.19% httpd This goes on for a while after which they stop acting so weird. This happens with postgresql and with mysql. This happens with php4 and php5 This happens with apache 2.0 and 2.2 This happens with FreeBSD 6.1 inside and outside a jail. Nothing in the logs. Any clue? This doesn't happen on 6.0 (According to neologism) Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Samba problem
On Tue, Aug 15, 2006 at 02:17:35PM +0400, Roman Streltsov wrote: > Hi all, > > I am using samba-3.0.21b,1 succefully on 6.1-RELEASE-p3 box without any > problem. my problem is that I am not able to MOUNT shares on 6.1R... its not problem with samba not working etc. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mail/roundcube on 6.1 - httpd go balistic
On Tue, Aug 15, 2006 at 09:32:36PM +1000, Edwin Groothuis wrote: > Nothing in the logs. Any clue? Tests with neologisms machine: it's caused by dbmail Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mail/roundcube on 6.1 - httpd go balistic
On Tue, Aug 15, 2006 at 09:45:07PM +1000, Edwin Groothuis wrote: > On Tue, Aug 15, 2006 at 09:32:36PM +1000, Edwin Groothuis wrote: > > Nothing in the logs. Any clue? > > Tests with neologisms machine: it's caused by dbmail http://trac.roundcube.net/trac.cgi/ticket/1483956#preview http://www.dbmail.org/mantis/view.php?id=394 Let them fight it out! -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Samba problem
Le mardi 15 août 2006 13:37, Divacky Roman a écrit : Hello, > On Tue, Aug 15, 2006 at 02:17:35PM +0400, Roman Streltsov wrote: > > Hi all, > > > > I am using samba-3.0.21b,1 succefully on 6.1-RELEASE-p3 box without any > > problem. > > my problem is that I am not able to MOUNT shares on 6.1R... its not > problem with samba not working etc. No problem here (with a mount_smbfs -I host -W workgroup "//") on 6.1-RELEASE or 6.1-STABLE for clients. The (very basic) samba server runs 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 ([EMAIL PROTECTED]) wrote:
> >Now, if we want to fix these, we'll need to change variables in
> >REINPLACE_CMD lines: LOCALBASE to LOCALBASE_REL, X11BASE to X11BASE_REL
> >and DATADIR... hmm, we have no DATADIR_REL, so all is left is
> >${PREFIX}/share/${PORTNAME}. That's unforgivable.
> Yes, that's right as well, but note if we had left LOCALBASE, LINUXBASE,
> X11BASE unchanged, we would need to change them in the *_DEPENDS lines.
> That's true that we don't have DATADIR_REL, etc. We could introduce them
> if needed, but that substitution can be done with make :S as well.
> DESTDIR implementation is complicated in many ways, no perfect
> implementation exist. As you said LOCALBASE is used in substitutions, bu
> also used in *_DEPENDS as well. Now those two cases have to be
> distinguished. One of them should have been changed at all... That's why
> I say no perfect implementation exist. If we implement new functions
> later, it can be very difficult...
I don't quite understand what problems with _DEPENDS will there be, as
DESTDIR can always be prepended to path when checking depends.
> >Please tell that I'm stupid if I am wrong somewhere, but I think
> >DESTDIR support, being introduced into ports collection in a way it's
> >currently introduced, will bring much pain.
> It will, but I tried to avoid the most of the necessary pain. Changing
> all of *_DEPENDS would be good? I don't think so... As for this change,
> it is actually wrong. I CC'd the maintainer.
> In the HEADS-UP message I sent, I wrote that one can feel free to
> contact me to review and test patches. Some people already did so. As my
> time lets me doing so, I test every patches sent to me.
> >What I propose is:
> >- Change variable naming scheme.
> >All *BASE and *DIR vars should be reverted to their original meanings
> >(i.e. local paths). Instead, INSTALL_ vars should be introduced:
> >INSTALL_LOCALBASE=${DESTDIR}/${LOCALBASE}
> >INSTALL_X11BASE=${DESTDIR}/${X11BASE}
> >INSTALL_PREFIX=${DESTDIR}/${PREFIX}
> >INSTALL_DATADIR=${DESTDIR}/${DATADIR}
> I don't think it will happen. It just makes the whole thing much more
> complicated.
Why? I don't think introducing INSTALL_* vars is more complicated
than introducing *_REL, with the difference that it'll be more clear
what to use in ports and it'll be easier to convert ports. Yes, there'll
be some additional changes to Mk/* (hm, prepending DESTDIR where
necessary doesn't seem compicating to me at all) but am I now right
that Mk/* exists to support ports, not otherwise? Also, I may be wrong
here, but I think that smaller set of wars is used in installation that
in build process. At the end, DESTDIR is about installation - it seems
pretty unlogical to me that everything except installation in ports have
to be changed. Even not all vars were introduced (I think using :S to
get local DATADIR is not the good way).
> >etc. These should be used in do-install target.
> >
> >* This is far more clean and understandable,
> >* This allows us to make all ports (around 5k) that define do-install
> >target
> > DESTDIR-compatible (there still may be issues, but nevertheless).
> >
> >- Introduce variable DESTDIR_COMPATIBLE to explititely mark
> > DESTDIR-compatible ports.
> This is going to happen but in the opposite manner. We are planning to
> run an -exp run in the pointyhat cluster with DESTDIR set, and fix at
> least some of the most common ports, and mark the other ones NO_DESTDIR
> or something like that.
Uh, that's good then. What's -exp by the way?
> >* I don't think DESTDIR compatibility can be tested automatically, so
> > this would make freebsd user's life easier (user will be sure that after
> > he
> > installs ports into [jail|other freebsd installation mounted via
> > nfs|locally] being set corresponging DESTDIR, nothing will break).
> > Without such variable, he'll never be sure.
> >* Port maintainers will know what ports still are to be converted.
> > Nothing will be forgotten.
> P.S.: Please don't make other people panic with such subject. Other
> people also reviewed my code. We are just people, so we can make
> mistakes as well, but you can be sure that such a big change like
> DESTDIR got enough reviewal and test before committed into Mk. Portmgr
> is for ensuring people that only rational and working code gets
> committed into bsd.port.mk.
> John, the author of an earlier DESTDIR implementation also reviewed my
> changes and helped to fix some minor issues.
Yep, sorry for emotions. I have nothing against your or your code or
people who reviewed it. It works pretty well, DESTDIR support is of
course thing to have. But, we still have 15k ports to support it as
well. So, what I propose is to make necessary changes in ports
well-determined (i.e. only change known set of vars - X11BASE, PREFIX,
DATADIR etc to their INSTALL_* equivalents in install targets - and
nothing else, and if port doesn't support DESTDIR, cause is 100% in
install
Re: Samba problem
hi, Patrick Lamaizière is right, using this command as-it-is, the share can be mounted. Best Regards, Carlos Silva, CSilva Web: [1]http://www.csilva.org/ Patrick Lamaizière escreveu: Le mardi 15 août 2006 13:37, Divacky Roman a écrit : Hello, On Tue, Aug 15, 2006 at 02:17:35PM +0400, Roman Streltsov wrote: Hi all, I am using samba-3.0.21b,1 succefully on 6.1-RELEASE-p3 box without any problem. my problem is that I am not able to MOUNT shares on 6.1R... its not problem with samba not working etc. No problem here (with a mount_smbfs -I host -W workgroup "//") on 6.1-RELEASE or 6.1-STABLE for clients. The (very basic) samba server runs 6.1-RELEASE. ___ [EMAIL PROTECTED] mailing list [3]http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [4]"[EMAIL PROTECTED]" References 1. http://www.csilva.org/ 2. mailto:freebsd-ports@freebsd.org 3. http://lists.freebsd.org/mailman/listinfo/freebsd-ports 4. mailto:[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: ATTENTION: is the way DESTDIR was introduced completely wrong?
* G??bor K??vesd??n ([EMAIL PROTECTED]) wrote: > >I agree with every your word. > I was to implement it in this way, but as I said this would require us > to change all of the *_DEPENDS lines. Erwin told me that this can't be > happen, so I was pushed to go the another way. Erwin is in portmgr, and > portmgr's word make sense in these questions... Why change _DEPENDS lines in ports while we can prepend DESTDIR where needed in bsd.port.mk? I can make the patches if needed. > >This is exactly I proposed. But I've not been heard. > You have been, but this will happen later, after an -exp run as Erwin > said. And in the opposite form. Ports that don't respect DESTDIR will be > marked. Could you point me to any information regarding this -exp? Honestly I don't get how the software can be proven working without human inspection. Ok, there can be errors on stderr. But what about GUI software? There will be messageboxes, how to detect these? Or there will be no complaints at all, software just won't work properly (i.e. a game will run with no textures/no sound etc.). We may search for paths in all files installed by port (simple grep(1) on text files, strings(1)|grep on binaries) to detect wrong paths - that's far more reliable - is that what's done? -- Best regards, Dmitry mailto:[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: Samba problem
On Tue, Aug 15, 2006 at 01:38:29PM +0100, Carlos Silva wrote: > >hi, >Patrick Lamaizière is right, using this command as-it-is, the share >can be mounted. > Best Regards, > > Carlos Silva, CSilva > Web: [1]http://www.csilva.org/ > I'm having no trouble now. There were some problems in STABLE for awhile where one needed to add the NETSMBCRYPTO. I'm not sure if that's still the case, though I still have it in my kernel. There is a notice that it is no longer necessary in CURRENT /usr/src/UPDATING. mount_smbfs is working for me now, however. This machine is running 6.1-STABLE with samba 3.0.23,1 -- Scott Robbins GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: Oh, no... I have to go take an English make-up exam. They give you credit just for speaking it, right? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ruby gems, use ports or not?
For anyone else admining a FreeBSD box running Ruby, I'm curious as to whether you're managing gems via ports or the gems system. I installed Rails via ports, but I think I'd prefer to just use the gems interface. What is everyone else doing? Thanks, Mike -- Michael P. Soulier <[EMAIL PROTECTED]> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein signature.asc Description: OpenPGP digital signature
Re: ATTENTION: is the way DESTDIR was introduced completely wrong?
Dmitry Marakasov wrote: * G??bor K??vesd??n ([EMAIL PROTECTED]) wrote: I agree with every your word. I was to implement it in this way, but as I said this would require us to change all of the *_DEPENDS lines. Erwin told me that this can't be happen, so I was pushed to go the another way. Erwin is in portmgr, and portmgr's word make sense in these questions... Why change _DEPENDS lines in ports while we can prepend DESTDIR where needed in bsd.port.mk? I can make the patches if needed Maybe with a hackery you can. I haven't thought of such special thing. Can you show how you mean? This is exactly I proposed. But I've not been heard. You have been, but this will happen later, after an -exp run as Erwin said. And in the opposite form. Ports that don't respect DESTDIR will be marked. Could you point me to any information regarding this -exp? Honestly I don't get how the software can be proven working without human inspection. Ok, there can be errors on stderr. But what about GUI software? There will be messageboxes, how to detect these? Or there will be no complaints at all, software just won't work properly (i.e. a game will run with no textures/no sound etc.). We may search for paths in all files installed by port (simple grep(1) on text files, strings(1)|grep on binaries) to detect wrong paths - that's far more reliable - is that what's done? An -exp run is a full run on the package building cluster that is maintained by [EMAIL PROTECTED] You might contact them on this address. I don't know what I can do now myself, I just did what I've been told to do: wrote an implementation where only small modifications are necessary to make ports respect DESTDIR, but many people seem to be unsatisfied and disappointed with this solution. -- Cheers, Gabor ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gtk file chooser weirdness in linux-firefox
Hi! For a long time I am experiencing weird problem when trying to choose file from File->Open_File or when I want to change "download action/helper application" in the preferences. The problem is that GTK file chooser does not list all files in the selected directory. Check it out here: http://daemon.nanophys.kth.se/~kono/buggy_file_chooser.png So some GTK library want to convince me that in /usr/X11R6/bin folder there are only three files? there are 539! I tried to right-click and activate hidden files in the chooser, tried from the root account, no luck. Any suggestions? This problem I have on both i386 and amd64 platforms with FreeBSD 5.5 and 6.1. Some time ago linux-Firefox was without this ugly GTK file chooser, is there any possibility to install/build linux-firefox with another (old) file chooser? Or it is as hopeless as to decide which linux distribution to install? Currently I don't use freebsd natively build firefox because it's unstable. /Alexander Konovalenko +46-8-5537-8142 (office) +46-7-3752-2116 http://daemon.nanophys.kth.se/~kono Royal Institute of Technology (KTH) Nanostructure Physics Department, Albanova Roslagstullsbacken 21 10691 Stockholm Sweden ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ruby gems, use ports or not?
I installed rails using gems, I have not seen any problems with it yet. -Original Message- From: [EMAIL PROTECTED] on behalf of Michael P. Soulier Sent: Tue 8/15/2006 9:26 AM To: freebsd-ports@freebsd.org Subject: ruby gems, use ports or not? For anyone else admining a FreeBSD box running Ruby, I'm curious as to whether you're managing gems via ports or the gems system. I installed Rails via ports, but I think I'd prefer to just use the gems interface. What is everyone else doing? Thanks, Mike -- Michael P. Soulier <[EMAIL PROTECTED]> "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction." --Albert Einstein ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ruby gems, use ports or not?
On Aug 15, 2006, at 10:52 AM, David Sledge wrote: I installed rails using gems, I have not seen any problems with it yet. I personally don't use ruby, but a similar situation exists with perl and the CPAN archives. I used to install all modules via CPAN directly, but in the long run it became very difficult to keep up-to- date across major perl upgrades, system upgrades, etc. It is my firm belief that you not mix and match like this: either install everything (ie, all of ruby + gems) by hand or everything using your package management system of choice. Anything else will eventually end up causing you confusion and difficulty in upgrades. It is for this very reason that I've been submitting quite a number of perl library ports rather than just using the CPAN install of them, which would have been easier short-term.
devel/fam build failure
Hi,
Trying to update my ports but devel/fam won't build. One of the errors
mentions an old version of automake so I've uninstalled *all* versions
of automake and autoconf and just reinstalled the latest versions
(autoconf259 and automake19) but devel/fam still won't build.
Can anyone help?
Thanks.
Mark
/usr/ports/devel/fam{148}# make
===> Vulnerability check disabled, database not found
===> Extracting for fam-2.6.10
=> MD5 Checksum OK for fam/fam-2.6.10.tar.gz.
=> SHA256 Checksum OK for fam/fam-2.6.10.tar.gz.
===> Patching for fam-2.6.10
===> Applying FreeBSD patches for fam-2.6.10
===> fam-2.6.10 depends on executable in : gmake - found
===> fam-2.6.10 depends on file: /usr/local/bin/automake19 - found
===> fam-2.6.10 depends on file: /usr/local/bin/autoconf259 - found
===> fam-2.6.10 depends on file: /usr/local/bin/libtool - found
===> Configuring for fam-2.6.10
configure.in:295: warning: underquoted definition of FAM_DECL_IN_MNTENT
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/X11R6/share/aclocal/xmms.m4:17: warning: underquoted definition of
XMMS_TEST_VERSION
/usr/X11R6/share/aclocal/xmms.m4:62: warning: underquoted definition of
AM_PATH_XMMS
/usr/X11R6/share/aclocal/libart.m4:11: warning: underquoted definition
of AM_PATH_LIBART
/usr/X11R6/share/aclocal/imlib.m4:9: warning: underquoted definition of
AM_PATH_IMLIB
/usr/X11R6/share/aclocal/imlib.m4:167: warning: underquoted definition
of AM_PATH_GDK_IMLIB
/usr/X11R6/share/aclocal/gtk.m4:7: warning: underquoted definition of
AM_PATH_GTK
/usr/X11R6/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted
definition of AM_PATH_GDK_PIXBUF
/usr/local/share/aclocal/speex.m4:10: warning: underquoted definition of
XIPH_PATH_SPEEX
/usr/local/share/aclocal/pilot-link.m4:1: warning: underquoted
definition of AC_PILOT_LINK_HOOK
/usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of
AM_PATH_LINC
/usr/local/share/aclocal/libmikmod.m4:11: warning: underquoted
definition of AM_PATH_LIBMIKMOD
/usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition
of AM_PATH_LIBFAME
/usr/local/share/aclocal/libIDL.m4:6: warning: underquoted definition of
AM_PATH_LIBIDL
/usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of
AM_PATH_GLIB
/usr/local/share/aclocal/audiofile.m4:12: warning: underquoted
definition of AM_PATH_AUDIOFILE
/usr/local/share/aclocal/ao.m4:9: warning: underquoted definition of
XIPH_PATH_AO
/usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of
AM_PATH_AALIB
/usr/local/share/aclocal/ORBit.m4:4: warning: underquoted definition of
AM_PATH_ORBIT
configure.in:40: warning: do not use m4_patsubst: use patsubst or
m4_bpatsubst
/usr/local/share/aclocal/header.m4:53: AM_CONFIG_HEADER is expanded from...
configure.in:40: the top level
configure.in:561: warning: do not use m4_regexp: use regexp or m4_bregexp
/usr/local/share/aclocal/header.m4:66: _AM_DIRNAME is expanded from...
configure.in:561: the top level
configure.in:40: warning: do not use m4_patsubst: use patsubst or
m4_bpatsubst
aclocal.m4:320: AM_CONFIG_HEADER is expanded from...
configure.in:40: the top level
configure.in:561: warning: do not use m4_regexp: use regexp or m4_bregexp
aclocal.m4:333: _AM_DIRNAME is expanded from...
configure.in:561: the top level
configure.in:40: warning: do not use m4_patsubst: use patsubst or
m4_bpatsubst
aclocal.m4:320: AM_CONFIG_HEADER is expanded from...
configure.in:40: the top level
configure.in:561: warning: do not use m4_regexp: use regexp or m4_bregexp
aclocal.m4:333: _AM_DIRNAME is expanded from...
configure.in:561: the top level
configure.in:37: your implementation of AM_INIT_AUTOMAKE comes from an
configure.in:37: old Automake version. You should recreate aclocal.m4
configure.in:37: with aclocal and run automake again.
*** Error code 63
Stop in /usr/ports/devel/fam.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gtk file chooser weirdness in linux-firefox
On Tue, 15 Aug 2006 16:47:31 +0200 Alexander Konovalenko <[EMAIL PROTECTED]> mentioned: > Hi! > > For a long time I am experiencing weird problem when trying to choose file > from File->Open_File or when I want to change "download action/helper > application" in the preferences. The problem is that GTK file chooser does > not list all files in the selected directory. > > Check it out here: http://daemon.nanophys.kth.se/~kono/buggy_file_chooser.png > > So some GTK library want to convince me that in /usr/X11R6/bin folder there > are only three files? there are 539! > > I tried to right-click and activate hidden files in the chooser, tried from > the root account, no luck. > > Any suggestions? > That's because Linux apps access files rooted in /compat/linux first, and only falls back if file isn't found. So firefox merely lists contents of /compat/linux/usr/X11R6, not /usr/X11R6. > > Currently I don't use freebsd natively build firefox because it's unstable. > I'm using it permanetly without any problem. What exactly you are experiencing? -- 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: devel/fam build failure
On Tue, 15 Aug 2006 16:20:58 +0100 Mark Ovens <[EMAIL PROTECTED]> mentioned: > Hi, > > Trying to update my ports but devel/fam won't build. One of the errors > mentions an old version of automake so I've uninstalled *all* versions > of automake and autoconf and just reinstalled the latest versions > (autoconf259 and automake19) but devel/fam still won't build. > > Can anyone help? That's because of stale file /usr/local/share/aclocal/header.m4. Could you, please, provide the output of pkg_info -W /usr/local/share/aclocal/header.m4 ? -- 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: gtk file chooser weirdness in linux-firefox
Quoting Alexander Konovalenko <[EMAIL PROTECTED]> (Tue, 15 Aug 2006 16:47:31 +0200): > > Hi! > > For a long time I am experiencing weird problem when trying to choose file > from File->Open_File or when I want to change "download action/helper > application" in the preferences. The problem is that GTK file chooser does > not list all files in the selected directory. > > Check it out here: http://daemon.nanophys.kth.se/~kono/buggy_file_chooser.png > > So some GTK library want to convince me that in /usr/X11R6/bin folder there > are only three files? there are 539! # ll /compat/linux/usr/X11R6/bin total 46 -r-xr-xr-x 1 root wheel24K Jul 2 12:48 gears* -r-xr-xr-x 1 root wheel21K Jul 2 12:48 glxinfo* So it works as intended (it find the dir in the linux compatibility directory, so it doesn't lookup the FreeBSD one). > Currently I don't use freebsd natively build firefox because it's unstable. Maybe some important lib is linked in in an old version? Bye, Alexander. -- "One of the joys of being a kid is that experiences are new and therefore more intense." -Calvin sniffing mustard http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mrtg problem
hi again, i have troubles with MRTG, a strange error that never happened to me. output osiris# /etc/rc.d/mrtg_daemon start Starting mrtg_daemon. Daemonizing MRTG ... osiris# /bin/rateup: Permission denied Rateup ERROR: Can't open 192.168.1.1_1.tmp for write ERROR: Skipping webupdates because rateup did not return anything sensible WARNING: rateup died from Signal 0 with Exit Value 1 when doing router '192.168.1.1_1' Signal was 0, Returncode was 1 /bin/rateup: Permission denied Rateup ERROR: Can't open 192.168.1.1_4.tmp for write ERROR: Skipping webupdates because rateup did not return anything sensible WARNING: rateup died from Signal 0 with Exit Value 1 when doing router '192.168.1.1_4' Signal was 0, Returncode was 1 someone has an error like that? ideas? Best Regards, Carlos Silva, CSilva Web: http://www.csilva.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
Stanislav Sedov wrote:
On Tue, 15 Aug 2006 16:20:58 +0100
Mark Ovens <[EMAIL PROTECTED]> mentioned:
Hi,
Trying to update my ports but devel/fam won't build. One of the errors
mentions an old version of automake so I've uninstalled *all* versions
of automake and autoconf and just reinstalled the latest versions
(autoconf259 and automake19) but devel/fam still won't build.
Can anyone help?
That's because of stale file /usr/local/share/aclocal/header.m4.
Could you, please, provide the output of
pkg_info -W /usr/local/share/aclocal/header.m4 ?
Thanks for the quick reply.
As requested...
/usr/ports/devel/fam{150}# pkg_info -W /usr/local/share/aclocal/header.m4
/usr/ports/devel/fam{151}#
There is also an aclocal19 directory...
/usr/ports/devel/fam{157}# pkg_info -W /usr/local/share/aclocal19/header.m4
/usr/local/share/aclocal19/header.m4 was installed by package automake-1.9.6
/usr/ports/devel/fam{158}#
Thanks.
Mark
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mrtg problem
On Tue, Aug 15, 2006 at 04:58:12PM +0100, Carlos Silva wrote: > hi again, > > i have troubles with MRTG, a strange error that never happened to me. > > output > > osiris# /etc/rc.d/mrtg_daemon start > Starting mrtg_daemon. > Daemonizing MRTG ... > osiris# /bin/rateup: Permission denied > Rateup ERROR: Can't open 192.168.1.1_1.tmp for write > ERROR: Skipping webupdates because rateup did not return anything sensible > WARNING: rateup died from Signal 0 > with Exit Value 1 when doing router '192.168.1.1_1' > Signal was 0, Returncode was 1 > /bin/rateup: Permission denied > Rateup ERROR: Can't open 192.168.1.1_4.tmp for write > ERROR: Skipping webupdates because rateup did not return anything sensible > WARNING: rateup died from Signal 0 > with Exit Value 1 when doing router '192.168.1.1_4' > Signal was 0, Returncode was 1 > > someone has an error like that? ideas? Do you install all of your ports with PREFIX=/ or something? My mrtg installation has rateup in /usr/local/bin, and mrtg_daemon.sh in /usr/local/etc/rc.d. Possibly some portion of the port isn't respecting a non-default PREFIX? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
On Tue, 15 Aug 2006 17:04:48 +0100
Mark Ovens <[EMAIL PROTECTED]> mentioned:
>
> As requested...
>
> /usr/ports/devel/fam{150}# pkg_info -W /usr/local/share/aclocal/header.m4
>
> /usr/ports/devel/fam{151}#
>
So this file doesn't belong to any package and should be removed.
This should fix build, I suppose.
--
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: ports/102029: Fix 'broken' issues, reapply version update
Synopsis: Fix 'broken' issues, reapply version update Responsible-Changed-From-To: pirzyk->freebsd-ports Responsible-Changed-By: pirzyk Responsible-Changed-When: Tue Aug 15 16:39:14 UTC 2006 Responsible-Changed-Why: Changed ownership to freebsd-ports. The patch is ready to commit. http://www.freebsd.org/cgi/query-pr.cgi?pr=102029 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mrtg problem
In the last episode (Aug 15), Carlos Silva said: > hi again, > > i have troubles with MRTG, a strange error that never happened to me. > > output > > osiris# /etc/rc.d/mrtg_daemon start This file usually likes in /usr/local/etc/rc.d/ > Starting mrtg_daemon. > Daemonizing MRTG ... > osiris# /bin/rateup: Permission denied This file usually lives in /usr/local/bin/ > Rateup ERROR: Can't open 192.168.1.1_1.tmp for write Is WorkDir pointing to a directory the mrtg user has write permission for? -- Dan Nelson [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: mrtg problem
hi thats not the question, because ive installed the port right now on /usr/local, like the default and nothing. /usr/local/etc/rc.d/mrtg_daemon start Starting mrtg_daemon. Daemonizing MRTG ... osiris# /usr/local/bin/rateup: Permission denied Rateup ERROR: Can't open 192.168.1.1_1.tmp for write ERROR: Skipping webupdates because rateup did not return anything sensible WARNING: rateup died from Signal 0 with Exit Value 1 when doing router '192.168.1.1_1' Signal was 0, Returncode was 1 /usr/local/bin/rateup: Permission denied Rateup ERROR: Can't open 192.168.1.1_4.tmp for write ERROR: Skipping webupdates because rateup did not return anything sensible WARNING: rateup died from Signal 0 with Exit Value 1 when doing router '192.168.1.1_4' Signal was 0, Returncode was 1 same output as / :( any ideas? Best Regards, Carlos Silva, CSilva Web: [1]http://www.csilva.org/ Jeremy Chadwick escreveu: On Tue, Aug 15, 2006 at 04:58:12PM +0100, Carlos Silva wrote: hi again, i have troubles with MRTG, a strange error that never happened to me. output osiris# /etc/rc.d/mrtg_daemon start Starting mrtg_daemon. Daemonizing MRTG ... osiris# /bin/rateup: Permission denied Rateup ERROR: Can't open 192.168.1.1_1.tmp for write ERROR: Skipping webupdates because rateup did not return anything sensible WARNING: rateup died from Signal 0 with Exit Value 1 when doing router '192.168.1.1_1' Signal was 0, Returncode was 1 /bin/rateup: Permission denied Rateup ERROR: Can't open 192.168.1.1_4.tmp for write ERROR: Skipping webupdates because rateup did not return anything sensible WARNING: rateup died from Signal 0 with Exit Value 1 when doing router '192.168.1.1_4' Signal was 0, Returncode was 1 someone has an error like that? ideas? Do you install all of your ports with PREFIX=/ or something? My mrtg installation has rateup in /usr/local/bin, and mrtg_daemon.sh in /usr/local/etc/rc.d. Possibly some portion of the port isn't respecting a non-default PREFIX? References 1. http://www.csilva.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mrtg problem
hi, yes i have chmoded 777 Best Regards, Carlos Silva, CSilva Web: [1]http://www.csilva.org/ Dan Nelson escreveu: In the last episode (Aug 15), Carlos Silva said: hi again, i have troubles with MRTG, a strange error that never happened to me. output osiris# /etc/rc.d/mrtg_daemon start This file usually likes in /usr/local/etc/rc.d/ Starting mrtg_daemon. Daemonizing MRTG ... osiris# /bin/rateup: Permission denied This file usually lives in /usr/local/bin/ Rateup ERROR: Can't open 192.168.1.1_1.tmp for write Is WorkDir pointing to a directory the mrtg user has write permission for? References 1. http://www.csilva.org/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gtk file chooser weirdness in linux-firefox
On Tuesday 15 August 2006 15:19, Stanislav Sedov wrote: > On Tue, 15 Aug 2006 16:47:31 +0200 > > Alexander Konovalenko <[EMAIL PROTECTED]> mentioned: > > Hi! > > > > For a long time I am experiencing weird problem when trying to choose > > file from File->Open_File or when I want to change "download > > action/helper application" in the preferences. The problem is that GTK > > file chooser does not list all files in the selected directory. > > > > Check it out here: > > http://daemon.nanophys.kth.se/~kono/buggy_file_chooser.png > > > > So some GTK library want to convince me that in /usr/X11R6/bin folder > > there are only three files? there are 539! > > > > I tried to right-click and activate hidden files in the chooser, tried > > from the root account, no luck. > > > > Any suggestions? > > That's because Linux apps access files rooted in /compat/linux first, > and only falls back if file isn't found. So firefox merely lists > contents of /compat/linux/usr/X11R6, not /usr/X11R6. ok, you are right, but in /usr/compat/linux there is no home folder for example, however file chooser of linux-firefox shows it together with other folders from FreeBSD root folder. Isn't it weird to mix folders from /usr/compat/linux and / ? Is there any configuration of this? And how to jump to the real / folder from linux-app file chooser (currently I just created a soft link to it)? There is button called "Filesystems" but that does not go to freebsd /. > > > Currently I don't use freebsd natively build firefox because it's > > unstable. > > I'm using it permanetly without any problem. What exactly you are > experiencing? natively built firefox just hangs on amd64 FreeBSD 5.5 when started. Tried to rebuild/upgrade it couple of times but did not help. firefox-1.5.0.6,1 /Alexander Konovalenko ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Skipping certain ports, no upgrade of installed packages ...
On Sunday 13 August 2006 12:02, Kiffin Gish wrote: > How can prevent a given package from being reinstalled during the next > portupgrade when I want to delete permanently? > > An example is the Galeon browser. Since it also appears in the > gnome2-fifth-toe makefile t will automatically be rebuilt. IIRC fifth-toe is just a metaport, ie just a set dependencies. If you deinstall fifth-toe and Galeon, all the othe other ports that fifth-toe depends on will still be there as independent leaf-ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
Stanislav Sedov wrote:
On Tue, 15 Aug 2006 17:04:48 +0100
Mark Ovens <[EMAIL PROTECTED]> mentioned:
As requested...
/usr/ports/devel/fam{150}# pkg_info -W /usr/local/share/aclocal/header.m4
/usr/ports/devel/fam{151}#
So this file doesn't belong to any package and should be removed.
This should fix build, I suppose.
That didn't fix it. I then renamed /usr/local/share/aclocal and made it
a symlink to aclocal19/
# cd /usr/local/share
# mv aclocal __aclocal
# ln -s aclocal19/ aclocal
This got rid of many of the errors but I am still getting them for files
in /usr/X11R6/share/aclocal:
# make
===> fam-2.6.10 depends on executable in : gmake - found
===> fam-2.6.10 depends on file: /usr/local/bin/automake19 - found
===> fam-2.6.10 depends on file: /usr/local/bin/autoconf259 - found
===> fam-2.6.10 depends on file: /usr/local/bin/libtool - found
===> Configuring for fam-2.6.10
configure.in:295: warning: underquoted definition of FAM_DECL_IN_MNTENT
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
/usr/X11R6/share/aclocal/xmms.m4:17: warning: underquoted definition of
XMMS_TEST_VERSION
/usr/X11R6/share/aclocal/xmms.m4:62: warning: underquoted definition of
AM_PATH_XMMS
/usr/X11R6/share/aclocal/libart.m4:11: warning: underquoted definition
of AM_PATH_LIBART
/usr/X11R6/share/aclocal/imlib.m4:9: warning: underquoted definition of
AM_PATH_IMLIB
/usr/X11R6/share/aclocal/imlib.m4:167: warning: underquoted definition
of AM_PATH_GDK_IMLIB
/usr/X11R6/share/aclocal/gtk.m4:7: warning: underquoted definition of
AM_PATH_GTK
/usr/X11R6/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted
definition of AM_PATH_GDK_PIXBUF
aclocal:configure.in:44: warning: macro `AM_PROG_LIBTOOL' not found in
library
configure.in:44: error: possibly undefined macro: AM_PROG_LIBTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
*** Error code 1
Stop in /usr/ports/devel/fam.
Is it safe to delete those files or should I rebuild the ports that they
belong to?
Thanks.
Mark
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mrtg problem
On Tue, Aug 15, 2006 at 05:40:59PM +0100, Carlos Silva wrote: >hi >thats not the question, because ive installed the port right now on >/usr/local, like the default and nothing. >/usr/local/etc/rc.d/mrtg_daemon start >Starting mrtg_daemon. >Daemonizing MRTG ... >osiris# /usr/local/bin/rateup: Permission denied >Rateup ERROR: Can't open 192.168.1.1_1.tmp for write >ERROR: Skipping webupdates because rateup did not return anything >sensible >WARNING: rateup died from Signal 0 > with Exit Value 1 when doing router '192.168.1.1_1' > Signal was 0, Returncode was 1 >/usr/local/bin/rateup: Permission denied >Rateup ERROR: Can't open 192.168.1.1_4.tmp for write >ERROR: Skipping webupdates because rateup did not return anything >sensible >WARNING: rateup died from Signal 0 > with Exit Value 1 when doing router '192.168.1.1_4' > Signal was 0, Returncode was 1 >same output as / :( >any ideas? Maybe your umask is wrong when you're installing ports? Not sure. Very suspicious that rateup can't run (Permission denied) *AND* you get a write error... -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
On Tue, 15 Aug 2006 18:19:54 +0100 Mark Ovens <[EMAIL PROTECTED]> mentioned: > That didn't fix it. I then renamed /usr/local/share/aclocal and made it > a symlink to aclocal19/ > Don't do it, all external .m4 files get installed into share/aclocal, including libtool. > # cd /usr/local/share > # mv aclocal __aclocal > # ln -s aclocal19/ aclocal > This leads to > This got rid of many of the errors but I am still getting them for files > in /usr/X11R6/share/aclocal: > > # make > ===> fam-2.6.10 depends on executable in : gmake - found > ===> fam-2.6.10 depends on file: /usr/local/bin/automake19 - found > ===> fam-2.6.10 depends on file: /usr/local/bin/autoconf259 - found > ===> fam-2.6.10 depends on file: /usr/local/bin/libtool - found > ===> Configuring for fam-2.6.10 > configure.in:295: warning: underquoted definition of FAM_DECL_IN_MNTENT >run info '(automake)Extending aclocal' >or see http://sources.redhat.com/automake/automake.html#Extending-aclocal > /usr/X11R6/share/aclocal/xmms.m4:17: warning: underquoted definition of > XMMS_TEST_VERSION > /usr/X11R6/share/aclocal/xmms.m4:62: warning: underquoted definition of > AM_PATH_XMMS > /usr/X11R6/share/aclocal/libart.m4:11: warning: underquoted definition > of AM_PATH_LIBART > /usr/X11R6/share/aclocal/imlib.m4:9: warning: underquoted definition of > AM_PATH_IMLIB > /usr/X11R6/share/aclocal/imlib.m4:167: warning: underquoted definition > of AM_PATH_GDK_IMLIB > /usr/X11R6/share/aclocal/gtk.m4:7: warning: underquoted definition of > AM_PATH_GTK > /usr/X11R6/share/aclocal/gdk-pixbuf.m4:12: warning: underquoted > definition of AM_PATH_GDK_PIXBUF > aclocal:configure.in:44: warning: macro `AM_PROG_LIBTOOL' not found in > library > configure.in:44: error: possibly undefined macro: AM_PROG_LIBTOOL >If this token and others are legitimate, please use m4_pattern_allow. >See the Autoconf documentation. > *** Error code 1 this error. Try to # pkg_delete -f /var/db/pkg/autoconf* /var/db/pkg/automake* \ /var/db/pkg/libtool* /var/db/pkg/gnu-libtool* Then reinstall port. The installations missed AM_PROG_LIBTOOL because this macros is installed into /usr/local/share/aclocal which you removed. So put it back, execute the command above and report error message if any here. There might be additional stale files in your share/aclocal. -- 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: ports/102029: Fix 'broken' issues, reapply version update
Synopsis: Fix 'broken' issues, reapply version update Responsible-Changed-From-To: freebsd-ports->freebsd-ports-bugs Responsible-Changed-By: shaun Responsible-Changed-When: Tue Aug 15 18:14:33 UTC 2006 Responsible-Changed-Why: Re-assign; Missing a '-bugs'. http://www.freebsd.org/cgi/query-pr.cgi?pr=102029 ___ 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 wrote at 11:32 +0200 on Aug 15, 2006:
> Dmitry Marakasov wrote:
> > Now, I think the way DESTDIR-related changes were done to bsd.port.mk is
> > absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
> > DESTDIR. But, these variables are frequently used when changing paths
> > hardcoded in port's sources (see many of my ports, for example
> > games/fishsupper:
> >
> > @${REINPLACE_CMD} -e 's|data/|${DATADIR}/|'
> > ${WRKSRC}/src/getreadydisplay.cc
> >
> > After change, all these ports will not support DESTDIR automatically.
> > Incomplete list of such ports:
> >
> > find /usr/ports -name Makefile -exec grep -E \
> >"REINPLACE_CMD.*(DATADIR|LOCALBASE|X11BASE)" {}
> >
> > Now, if we want to fix these, we'll need to change variables in
> > REINPLACE_CMD lines: LOCALBASE to LOCALBASE_REL, X11BASE to X11BASE_REL
> > and DATADIR... hmm, we have no DATADIR_REL, so all is left is
> > ${PREFIX}/share/${PORTNAME}. That's unforgivable.
>
> Yes, that's right as well, but note if we had left LOCALBASE, LINUXBASE,
> X11BASE unchanged, we would need to change them in the *_DEPENDS lines.
> That's true that we don't have DATADIR_REL, etc. We could introduce them
> if needed, but that substitution can be done with make :S as well.
> DESTDIR implementation is complicated in many ways, no perfect
> implementation exist. As you said LOCALBASE is used in substitutions, bu
> also used in *_DEPENDS as well. Now those two cases have to be
> distinguished. One of them should have been changed at all... That's why
> I say no perfect implementation exist. If we implement new functions
> later, it can be very difficult...
I haven't followed any of this thread, so I apologize for rehashing
anything that's already been beaten to death.
First comment: MOST of the time people should be installing to
${DESTDIR}${PREFIX} (aka ${TARGETDIR}) anyway rather than
${DESTDIR}${LOCALBASE}. If anyone is using LOCALBASE for installs
rather than PREFIX, in most cases, that is wrong. If you install
directly to LOCALBASE, you are no longer PREFIX clean.
Second comment: the way DESTDIR was hacked into bsd.port.mk from the
beginning was wrong (/usr/share/mk/*.mk treats it correctly). We
could either accept that as it has been for a long time or try to fix
it.
Once you accept that the longstanding usage of DESTDIR in ports is
bogus, then you need to think about how to fix it.
Unfortunately, individual ports (port writers) need to be aware,
to some degree, about the proper meaning of DESTDIR. Until all third
party software uses the same method to build and install their
software (never), not everything can be fixed in bsd.port.mk.
Now, let's take LOCALBASE. You could have a version of LOCALBASE (1)
that has DESTDIR in it. You could have another version without
DESTDIR (2). You need to use the right one at the right time (general
rule: anything to do with installing needs DESTDIR; anything at build
time or run time doesn't; the complicated part comes in when you are
trying to build a package - some places need DESTDIR, some don't - the
pkg* tools could be fixed to understand DESTDIR better, but that's
another story altogether).
In my original patch (ports/28155), I chose to have (1) called
${DESTDIR}${LOCALBASE} and (2) called LOCALBASE. This would allow a
certain class of uses of LOCALBASE to remain unchanged... but not all.
Gábor chose to have (1) called LOCALBASE and (2) called LOCALBASE_REL.
Fine. This allows a different class of uses of LOCALBASE to remain
unchanged... but, again, not all.
You could call (1) FOO and (2) BAR. That would require LOTS of
changes, of course.
You could also call (1) ${LOCALBASE:C/^/${DESTDIR}/} and (2) LOCALBASE.
And so on and so on.
Which method requires the fewest changes to individual ports is an
exercise for the reader. But the difference is probably not
consequential enough to worry about.
The hard part is to get ports writers to think the right way about
DESTDIR after ignoring it for so many years. And once you decide to
go about fixing it, there's no way around that problem.
> > What I propose is:
> > - Change variable naming scheme.
> > All *BASE and *DIR vars should be reverted to their original meanings
> > (i.e. local paths). Instead, INSTALL_ vars should be introduced:
> > INSTALL_LOCALBASE=${DESTDIR}/${LOCALBASE}
> > INSTALL_X11BASE=${DESTDIR}/${X11BASE}
> > INSTALL_PREFIX=${DESTDIR}/${PREFIX}
> > INSTALL_DATADIR=${DESTDIR}/${DATADIR}
I understand where you're coming from, Dmitry. It's one way to do it.
It's more like my original way. I chose to not name that variable at
all, however - individual ports would just call it
${DESTDIR}${LOCALBASE} (or more correctly ${DESTDIR}${PREFIX} in most
situations).
You may think it's the better way. It may be that someone performs
the exercise I mentioned above to count the number of changes one way
requires vs. the other way and finds it to be the case.
That
Re: devel/fam build failure
Mark Ovens wrote: Hi, Trying to update my ports but devel/fam won't build. One of the errors mentions an old version of automake so I've uninstalled *all* versions of automake and autoconf and just reinstalled the latest versions (autoconf259 and automake19) but devel/fam still won't build. Can anyone help? Thanks. Mark [snip] I know that this is not a solution to devel/fam, but I just thought that I'd mention what I did last night when I ran into this: 1. removed devel/fam (cd /usr/ports/devel/fam && make deinstall) 2. changed /etc/make.conf: WITH_FAM_SYSTEM=gamin You might want to add this line if you don't already have it, but you most likely have it. 3. cd /usr/ports/devel/gamin && make install 4. pkgdb -F (and replaced all fam to gamin) At this point I was ready to check to see if any of the ports that had required fam didn't work, openoffice, xine, gcalctool, etc, and I would have rebuilt all of those. But there was no problem. Anyway, I have a question: Why are there two ports here that do the same thing? Some of my ports specify fam, some specify gamin, and of course I have to have the WITH_FAM_SYSTEM var in make.conf to remove conflicts. If the two DON'T do the same thing, what is the difference? Just asking. -- B Briggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
On Tue, 15 Aug 2006 13:55:35 -0500 B Briggs <[EMAIL PROTECTED]> mentioned:r > Anyway, I have a question: Why are there two ports here that do the same > thing? Some of my ports specify fam, some specify gamin, and of course I > have to have the WITH_FAM_SYSTEM var in make.conf to remove conflicts. > If the two DON'T do the same thing, what is the difference? Just asking. > They are merely two different implementations of FAM subsystem: one from SGI, another from RedHat. I belive, that SGI's one is sligthly faster currently. Also, it covers standard completely contradictory to gamin. If you have the same problem, can you please provide a list of installed packages and error log? I tested it on 4.x and 7.x with all ports up-to-date and there is no such problem. -- 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: devel/fam build failure
Stanislav Sedov wrote: --Sig_WbNhFI1NVPDTKUJcczy/9wv Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Tue, 15 Aug 2006 13:55:35 -0500 B Briggs <[EMAIL PROTECTED]> mentioned:r Anyway, I have a question: Why are there two ports here that do the same= =20 thing? Some of my ports specify fam, some specify gamin, and of course I= =20 have to have the WITH_FAM_SYSTEM var in make.conf to remove conflicts.=20 If the two DON'T do the same thing, what is the difference? Just asking. =20 They are merely two different implementations of FAM subsystem: one from SGI, another from RedHat. I belive, that SGI's one is sligthly faster currently. Also, it covers standard completely contradictory to gamin. If you have the same problem, can you please provide a list of installed packages and error log? I tested it on 4.x and 7.x with all ports up-to-date and there is no such problem. [snip] Which error log? (My errors upgrading fam seem to be exactly the same as the OP's. This might be helpful, I don't know: ~$ cd /usr/local/share/aclocal /usr/local/share/aclocal$ ll header.* -r--r--r-- 1 root wheel 2328 Jul 20 2004 header.m4 That's a LONG time ago. portversion -v ImageMagick-6.2.8.5 = up-to-date with port ORBit2-2.14.2_1 = up-to-date with port Xaw3d-1.5E_1= up-to-date with port aalib-1.4.r5_2 = up-to-date with port apache-ant-1.6.5_1 = up-to-date with port artwiz-aleczapka-en-1.3 = up-to-date with port aspell-0.60.4_4 = up-to-date with port atk-1.11.4_1= up-to-date with port audacity-1.2.4b = up-to-date with port autoconf-2.13.000227_5 = up-to-date with port autoconf-2.53_3 = up-to-date with port autoconf-2.59_2 = up-to-date with port automake-1.4.6_2= up-to-date with port automake-1.5_2,1= up-to-date with port automake-1.9.6 = up-to-date with port autotrace-0.31.1_7 = up-to-date with port avahi-0.6.12= up-to-date with port avidemux2-2.1.2_2 = up-to-date with port avifile-0.7.43_1,2 = up-to-date with port bash-3.1.17 = up-to-date with port bison-1.75_2,1 = up-to-date with port bitstream-vera-1.10_2 = up-to-date with port boehm-gc+threaded+fulldebug-6.6_3 = up-to-date with port boost-1.33.1_2 = up-to-date with port boxtools-0.70.1 = up-to-date with port bsdstats-3.0= up-to-date with port cairo-1.0.4_1 = up-to-date with port ccache-2.4_4= up-to-date with port cdparanoia-3.9.8_8 = up-to-date with port cdrdao-1.2.1= up-to-date with port cdrtools-2.01_5 = up-to-date with port chexedit-0.9.7 = up-to-date with port coreutils-5.2.1 = up-to-date with port cups-base-1.2.2 = up-to-date with port cups-pstoraster-8.15= up-to-date with port curl-7.15.4 = up-to-date with port cvsup-16.1h_2 = up-to-date with port db41-4.1.25_3 = up-to-date with port dbus-0.62 = up-to-date with port desktop-file-utils-0.11 = up-to-date with port djbfft-0.76_2 = up-to-date with port docbook-sk-4.1.2_3 = up-to-date with port docbook-xml-4.2_1 = up-to-date with port docbook-xml-4.3 = up-to-date with port docbook-xml-4.4 = up-to-date with port docbook-xsl-1.70.1 = up-to-date with port dri-6.4.1,2 = up-to-date with port dvd+rw-tools-6.1= up-to-date with port dvdauthor-0.6.11_1 = up-to-date with port eel-2.14.3 = up-to-date with port esound-0.2.36_1 = up-to-date with port eterm-0.9.3_5 = up-to-date with port expat-2.0.0_1 = up-to-date with port faac-1.24_6 = up-to-date with port faad2-2.0_6,1 = up-to-date with port ffmpeg-devel-0.4.9.c.2006032300_2 = up-to-date with port firefox-1.5.0.6,1 = up-to-date with port flac-1.1.2_1= up-to-date with port fltk-1.1.6_1= up-to-date with port flux-art-0.1= up-to-date with port fluxbox-devel-1.0rc2_1 = up-to-date with port fontconfig-2.3.2_5,1= up-to-date with port fontforge-20060413 = up-to-date with port foomatic-db-20060723= up-to-date with port foomatic-db-hpijs-1.4 = up-to-date with port fox-1.4.32 = up-to-date with port freetype2-2.1.10_3 = up-to-date with port fribidi-0.10.7 = up-to-date with port gail-1.8.11_1 = up-to-date with port gaim-1.5.0_4< needs updating (port has 1.5.0_6) gamin-0.1.7_2 = up-to-date with port gcalctool-5.7.32,2 = up-to-date with port
Re: devel/fam build failure
Stanislav Sedov wrote: --Sig_WbNhFI1NVPDTKUJcczy/9wv Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On Tue, 15 Aug 2006 13:55:35 -0500 B Briggs <[EMAIL PROTECTED]> mentioned:r Anyway, I have a question: Why are there two ports here that do the same= =20 thing? Some of my ports specify fam, some specify gamin, and of course I= =20 have to have the WITH_FAM_SYSTEM var in make.conf to remove conflicts.=20 If the two DON'T do the same thing, what is the difference? Just asking. =20 They are merely two different implementations of FAM subsystem: one from SGI, another from RedHat. I belive, that SGI's one is sligthly faster currently. Also, it covers standard completely contradictory to gamin. If you have the same problem, can you please provide a list of installed packages and error log? I tested it on 4.x and 7.x with all ports up-to-date and there is no such problem. [snip] I removed gamin, and tried to make fam again. Here are the make errors: bbriggs# make ===> Vulnerability check disabled, database not found ===> Extracting for fam-2.6.10 => MD5 Checksum OK for fam/fam-2.6.10.tar.gz. => SHA256 Checksum OK for fam/fam-2.6.10.tar.gz. ===> Patching for fam-2.6.10 ===> Applying FreeBSD patches for fam-2.6.10 ===> fam-2.6.10 depends on executable in : gmake - found ===> fam-2.6.10 depends on file: /usr/local/bin/automake19 - found ===> fam-2.6.10 depends on file: /usr/local/bin/autoconf259 - found ===> fam-2.6.10 depends on file: /usr/local/bin/libtool - found ===> Configuring for fam-2.6.10 configure.in:295: warning: underquoted definition of FAM_DECL_IN_MNTENT run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/X11R6/share/aclocal/xmms.m4:17: warning: underquoted definition of XMMS_TEST_VERSION /usr/X11R6/share/aclocal/xmms.m4:62: warning: underquoted definition of AM_PATH_XMMS /usr/X11R6/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK /usr/local/share/aclocal/speex.m4:10: warning: underquoted definition of XIPH_PATH_SPEEX /usr/local/share/aclocal/linc.m4:1: warning: underquoted definition of AM_PATH_LINC /usr/local/share/aclocal/libmikmod.m4:11: warning: underquoted definition of AM_PATH_LIBMIKMOD /usr/local/share/aclocal/libfame.m4:6: warning: underquoted definition of AM_PATH_LIBFAME /usr/local/share/aclocal/glib.m4:8: warning: underquoted definition of AM_PATH_GLIB /usr/local/share/aclocal/autotrace.m4:7: warning: underquoted definition of AM_PATH_AUTOTRACE /usr/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /usr/local/share/aclocal/ao.m4:9: warning: underquoted definition of XIPH_PATH_AO /usr/local/share/aclocal/aalib.m4:12: warning: underquoted definition of AM_PATH_AALIB configure.in:40: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst /usr/local/share/aclocal/header.m4:53: AM_CONFIG_HEADER is expanded from... configure.in:40: the top level configure.in:561: warning: do not use m4_regexp: use regexp or m4_bregexp /usr/local/share/aclocal/header.m4:66: _AM_DIRNAME is expanded from... configure.in:561: the top level configure.in:40: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst aclocal.m4:320: AM_CONFIG_HEADER is expanded from... configure.in:40: the top level configure.in:561: warning: do not use m4_regexp: use regexp or m4_bregexp aclocal.m4:333: _AM_DIRNAME is expanded from... configure.in:561: the top level configure.in:40: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst aclocal.m4:320: AM_CONFIG_HEADER is expanded from... configure.in:40: the top level configure.in:561: warning: do not use m4_regexp: use regexp or m4_bregexp aclocal.m4:333: _AM_DIRNAME is expanded from... configure.in:561: the top level configure.in:37: your implementation of AM_INIT_AUTOMAKE comes from an configure.in:37: old Automake version. You should recreate aclocal.m4 configure.in:37: with aclocal and run automake again. *** Error code 63 -- B Briggs ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: linux-flashplugin7
I left the libmap as it was and cp'd them back to /usr/X11R6/lib/linux-flashplugin7/ That worked for me but I wondered if what you did worked...I guess not. Also, a day afterward the flashplugin7 was again updated in fresh ports and on this install it put them back in the /usr/X11R6/lib/linux-flashplugin7/ directory so maybe the napi was a mistake. On 8/8/06, Joey Mingrone <[EMAIL PROTECTED]> wrote: Hi Jamie: I just updated my linux-flashplugin-7 port to linux-flashplugin-7.0r63_1 and I'm now having some problems getting it working in FreeBSD's native firefox (firefox-1.5.0.4,1). I noticed that the installation directory is now /usr/local/lib/npapi/linux-flashplugin/ so I updated the soft links in /usr/X11R6/lib/browser_plugins/ to: flashplayer.xpt@ -> /usr/local/lib/npapi/linux-flashplugin/flashplayer.xpt libflashplayer.so@ -> /usr/local/lib/npapi/linux-flashplugin/libflashplayer.so and the relevant part of my /etc/libmap.conf looks like: # Flash7 with Firefox/Konqueror [/usr/local/lib/npapi/linux-flashplugin/libflashplayer.so] libpthread.so.0 pluginwrapper/flash7.so libdl.so.2pluginwrapper/flash7.so libz.so.1 libz.so.3 libstdc++-libc6.2-2.so.3libstdc++.so.4 libm.so.6 libm.so.4 libc.so.6pluginwrapper/flash7.so Do you have any suggestions? Thanks, Joey ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[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: gtk file chooser weirdness in linux-firefox
Quoting Alexander Konovalenko <[EMAIL PROTECTED]> (Tue, 15 Aug 2006 19:01:17 +0200): > On Tuesday 15 August 2006 15:19, Stanislav Sedov wrote: > > On Tue, 15 Aug 2006 16:47:31 +0200 > > > > Alexander Konovalenko <[EMAIL PROTECTED]> mentioned: > > > Hi! > > > > > > For a long time I am experiencing weird problem when trying to choose > > > file from File->Open_File or when I want to change "download > > > action/helper application" in the preferences. The problem is that GTK > > > file chooser does not list all files in the selected directory. > > > > > > Check it out here: > > > http://daemon.nanophys.kth.se/~kono/buggy_file_chooser.png > > > > > > So some GTK library want to convince me that in /usr/X11R6/bin folder > > > there are only three files? there are 539! > > > > > > I tried to right-click and activate hidden files in the chooser, tried > > > from the root account, no luck. > > > > > > Any suggestions? > > > > That's because Linux apps access files rooted in /compat/linux first, > > and only falls back if file isn't found. So firefox merely lists > > contents of /compat/linux/usr/X11R6, not /usr/X11R6. > > ok, you are right, but in /usr/compat/linux there is no home folder for > example, however file chooser of linux-firefox shows it together with other > folders from FreeBSD root folder. Isn't it weird to mix folders > from /usr/compat/linux and / ? Is there any configuration of this? No, there's no config of this. The linuxolator depends upon this behavior. Without it it it either couldn't find the linux libs, or you aren't able to access your files with the native path. If you need to access a file which isn't visible, you just have to type in the full name. This way you aren't able to access a file which is also available with different content but the same name in /compat/linux, and you aren't able to browse with the mouse, but you can at least access it. > And how to jump to the real / folder from linux-app file chooser (currently I > just created a soft link to it)? There is button called "Filesystems" but > that does not go to freebsd /. There's no way to go to see the real / (except you do a null mount to somewhere else or something like this). Bye, Alexander. -- The dame was hysterical. Dames Usually are. -- Calvin as Tracer Bullet http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ports with duplicate LATEST_LINKS
Dear port maintainers, The following list includes ports maintained by you that have duplicate LATEST_LINK values. They should either be modified to use a unique LATEST_LINK or suppressed using NO_LATEST_LINK, to avoid overwriting each other in the packages/Latest directory. If your ports conflict with ports maintained by another person, please coordinate your efforts with them. Thanks, Kris "Annoying Reminder Guy II" Kennaway LATEST_LINK PORTNAME MAINTAINER == flockwww/flock [EMAIL PROTECTED] flocksysutils/flock [EMAIL PROTECTED] gpc lang/gpc [EMAIL PROTECTED] gpc devel/gpc [EMAIL PROTECTED] mediawikiwww/mediawiki [EMAIL PROTECTED] mediawikiwww/mediawiki16[EMAIL PROTECTED] mod_jk www/mod_jk [EMAIL PROTECTED] mod_jk www/mod_jk-apache2 [EMAIL PROTECTED] postfix mail/postfix [EMAIL PROTECTED] postfix mail/postfix22 [EMAIL PROTECTED] py24-pysqlitedatabases/py-pysqlite22[EMAIL PROTECTED] py24-pysqlitedatabases/py-pysqlite23[EMAIL PROTECTED] xchat1 irc/xchat1 [EMAIL PROTECTED] xchat1 japanese/xchat [EMAIL PROTECTED] Total: 14 ports ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php-templates in 6.1
Hello, I'm trying to build php4 with php-templates on 6.1-RELEASE. My system, with /usr/ports updated, uses php-4.4.3 and php-templates-1.7.2.I get a compile error in php-templates (see below). I looked at the code and the pre-processor output and the best I can come up with is "Yeah, looks like a problem", which puts me on par with the compiler, but doesn't help me move forward. Any hints on how I fix this? BTW, I just installed a virgin 6.1 and note that it uses php-4.4.2 and php_templates-1.7, and it fails in the same way. Thanks, -mark ===> Building for php-templates-1.7.2 /bin/sh /usr/ports/www/php-templates/work/templates/libtool --mode=compile gcc -I. -I/usr/ports/www/php-templates/work/templates -DPHP_ATOM_INC -I/usr/ports/www/php-templates/work/templates/include -I/usr/ports/www/php-templates/work/templates/main -I/usr/ports/www/php-templates/work/templates -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -DHAVE_CONFIG_H -O2 -fno-strict-aliasing -pipe -c /usr/ports/www/php-templates/work/templates/templates.c -o templates.lo gcc -I. -I/usr/ports/www/php-templates/work/templates -DPHP_ATOM_INC -I/usr/ports/www/php-templates/work/templates/include -I/usr/ports/www/php-templates/work/templates/main -I/usr/ports/www/php-templates/work/templates -I/usr/local/include/php -I/usr/local/include/php/main -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend -DHAVE_CONFIG_H -O2 -fno-strict-aliasing -pipe -c /usr/ports/www/php-templates/work/templates/templates.c -fPIC -DPIC -o templates.lo /usr/ports/www/php-templates/work/templates/templates.c: In function `php_tmpl_init': /usr/ports/www/php-templates/work/templates/templates.c:370: error: `__zend_filename' undeclared (first use in this function) /usr/ports/www/php-templates/work/templates/templates.c:370: error: (Each undeclared identifier is reported only once /usr/ports/www/php-templates/work/templates/templates.c:370: error: for each function it appears in.) /usr/ports/www/php-templates/work/templates/templates.c:370: error: `__zend_lineno' undeclared (first use in this function) *** Error code 1 Stop in /usr/ports/www/php-templates/work/templates. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports with duplicate LATEST_LINKS
вівторок 15 серпень 2006 19:19, Kris Kennaway написав: > gpc lang/gpc [EMAIL PROTECTED] > gpc devel/gpc [EMAIL PROTECTED] I just renamed the package created by devel/gpc into "libgpc". The directory can now be repo-copied too... Yours, -mi ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports with duplicate LATEST_LINKS
On Tue, Aug 15, 2006 at 07:19:35PM -0400, Kris Kennaway wrote: > LATEST_LINK PORTNAME MAINTAINER > == > mediawikiwww/mediawiki [EMAIL PROTECTED] > mediawikiwww/mediawiki16[EMAIL PROTECTED] > postfix mail/postfix [EMAIL PROTECTED] > postfix mail/postfix22 [EMAIL PROTECTED] > xchat1 irc/xchat1 [EMAIL PROTECTED] > xchat1 japanese/xchat [EMAIL PROTECTED] Fixed these ones. Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ports with duplicate LATEST_LINKS
On Wed, Aug 16, 2006 at 10:30:19AM +1000, Edwin Groothuis wrote: > On Tue, Aug 15, 2006 at 07:19:35PM -0400, Kris Kennaway wrote: > postfix mail/postfix [EMAIL PROTECTED] > postfix mail/postfix22 [EMAIL PROTECTED] > > Fixed these ones. That one wasn't strictly true... It was set to NO_LATEST_LINK by mnag@ Edwin -- Edwin Groothuis |Personal website: http://www.mavetju.org [EMAIL PROTECTED]| Weblog: http://weblog.barnet.com.au/edwin/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question about games/utserver
Hello!
In /ports/games/utserver/Makefile
RUN_DEPENDS=
${LINUXBASE}/usr/lib/libSDL-1.2.so.0:${PORTSDIR}/devel/linux-sdl12
BUILD_DEPENDS= ${RUN_DEPENDS}
Can I remove BUILD_DEPENDS?
In http://www.freshports.org/games/utserver
required to build: devel/linux-sdl12, emulators/linux_base-fc4, lang/perl5.8,
lang/perl5.8
# make install clean
===> Vulnerability check disabled, database not found
===> Extracting for utserver-451_1
=> MD5 Checksum OK for ut-server-436.tar.gz.
=> SHA256 Checksum OK for ut-server-436.tar.gz.
=> MD5 Checksum OK for UTPGPatch451.tar.bz2.
=> SHA256 Checksum OK for UTPGPatch451.tar.bz2.
===> utserver-451_1 depends on file: /usr/local/bin/perl5.8.8 - found
===> Patching for utserver-451_1
===> utserver-451_1 depends on file: /usr/local/bin/perl5.8.8 - found
===> utserver-451_1 depends on file: /usr/local/bin/perl5.8.8 - found
So lang/perl5.8 is duplicate, is it correct?
--
WBR
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-templates in 6.1
On Tue, Aug 15, 2006 at 04:37:33PM -0700, Mark Kent wrote: > Hello, > I'm trying to build php4 with php-templates on 6.1-RELEASE. > My system, with /usr/ports updated, uses php-4.4.3 and > php-templates-1.7.2.I get a compile error in php-templates > (see below). > I looked at the code and the pre-processor output and the best I can > come up with is "Yeah, looks like a problem", which puts me on par > with the compiler, but doesn't help me move forward. > Any hints on how I fix this? > BTW, I just installed a virgin 6.1 and note that it uses > php-4.4.2 and php_templates-1.7, and it fails in the same way. how about switch to textproc/pecl-ctemplate? it's another php tempalte engine base on google ctemplate library, and writen by me :) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ruby gems, use ports or not?
in message <[EMAIL PROTECTED]>, wrote Vivek Khera thusly... > > > either install everything ... by hand or everything using your > package management system of choice. Anything else will > eventually end up causing you confusion and difficulty in > upgrades. > > It is for this very reason that I've been submitting quite a > number of perl library ports rather than just using the CPAN > install of them, which would have been easier short-term. I much appreciate your porting efforts. - Parv -- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
Stanislav Sedov wrote: > They are merely two different implementations of FAM subsystem: one > from SGI, another from RedHat. I belive, that SGI's one is sligthly > faster currently. Also, it covers standard completely contradictory to > gamin. Does any of them use kqueue(2)? -- Dixi. Sem. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devel/fam build failure
Sergey Matveychuk wrote: > Stanislav Sedov wrote: > > They are merely two different implementations of FAM subsystem: one > > from SGI, another from RedHat. I belive, that SGI's one is sligthly > > faster currently. Also, it covers standard completely contradictory to > > gamin. > > Does any of them use kqueue(2)? IIRC, gamin patched to use kqueue and I don't know about fam. pgpihWz3Wsexv.pgp Description: PGP signature
