Re: Compiling sguil-server on Release 9.2 i386
--On October 21, 2013 7:48:59 AM +0200 John Marino
freebsd.cont...@marino.st wrote:
On 10/21/2013 00:47, Paul Schmehl wrote:
--On October 20, 2013 9:34:36 AM +0200 John Marino
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition.
You're wrong. The RUN_DEPENDS does not have a shell command embedded in
it anywhere.
When you indent, it executes the command in the shell. Notice that only
make targets are indented.
I discovered this on my own while working on the port this morning.
That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port.
You're pretty sure? Rather than hard code a version, which would break
the port the moment mysqltcl was updated, I chose to use the existing
port version, which would work no matter what version was current on any
particular box.
Yes, I am sure. You can tell it that the port is the dependency
regardless of version. If you absolutely wanted to specify a file, you
can specify a different one that the file name doesn't change. Yes, you
can a RUN_DEPENDS without that line in ways that are robust.
The dependency is mysqltcl. That port installs two files in
${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/. How do you reference those
files without using the portversion?
Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Yes, and that is a problem. I noticed that last night when I was
looking at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD}
$$(${MYSQLTCL_CMDS}).
Again, completely unnecessary. Specify the *NON-INDENTED* RUN_DEPENDS
in a better way.
It looks like that port has changed, however, because it no longer
appends the version number to the name of the port, so I can probably
drop that entirely. I won't know until I test it.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
What do you suggest it be hardcoded to? ${PORTSDIR} can be set to
anything on an individual system. Using your construction forces it to
be in /usr/ports. Although that's the default, it's by no means
guaranteed that the ports tree will exist there on any given system.
That's why we use macros in Makefiles - to avoid forcing users to stick
to the default structure.
I just showed you. Replace ${PORTSDIR} with ${.CURDIR}/../../
I know you haven't believed a thing I've said so far, but using
${PORTSDIR} can break the build in specific configurations. And yes,
we've been replacing it with .CURDIR in other ports.
When I work on my ports I create a new directory ${PORTNAME}-update. Then
I svn the port into that directory, which creates a subdirectory named
${PORTNAME}. With ${.CURDIR}../../../ the build will not descend to
/usr/ports but to /usr/ports/security and the build will break. I fail to
see how that can be correct. If I build ports anywhere other than the
default location, the build will break.
Is this information documented somewhere? And how do I overcome this
obvious problem?
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should
fail. It didn't. I can't explain why. (I've slept since I last worked
on that port.) I can assure you I tested the port with the option
enabled and it built and ran fine.
So you state previously that it *HAD* to be defined for RUN_DEPENDS to
work, and now state that it wasn't defined but RUN_DEPENDS did work?
Doubtful and easily verifiable. Find an old platform where it worked
and type make -V RUN_DEPENDS and see if mysqltcl is in the list. I
believe it simply wasn't defined which didn't prevent this build from
building (it was indented, remember?). I think the error was masked
with the previous version of make.
But I doubt seriously that has anything to do with the error that the OP
reported. It's probably related to the change to bmake, which I will
have to investigate, if I have to continue to define the port version
for mysqltcl. It looks like I might not have to any more.
I'll also have to update the port to use the new STAGE syntax, so this
will take a little while.
In the future, I would appreciate it if you adopt a less smug attitude
about somebody else's work. Or take over the port if you think you're
so much better. There's three sguil ports. You're welcome to take over
maintainership if you think you're God's gift to port building.
Sigh
I guess you still feel this way after what I just
Re: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 18:15, Paul Schmehl wrote:
--On October 21, 2013 7:48:59 AM +0200 John Marino
The dependency is mysqltcl. That port installs two files in
${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/. How do you reference those
files without using the portversion?
Look at section 5.8.9 of the Porters Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html
Something like this should work:
RUN_DEPENDS+= mysqltcl3:${PORTSDIR}/databases/mysqltcl
With that line, you can forgot the shell command above. It means, use
any version of mysqltcl 3.0 or greater.
When I work on my ports I create a new directory ${PORTNAME}-update.
Then I svn the port into that directory, which creates a subdirectory
named ${PORTNAME}. With ${.CURDIR}../../../ the build will not descend
to /usr/ports but to /usr/ports/security and the build will break. I
fail to see how that can be correct. If I build ports anywhere other
than the default location, the build will break.
it would be ${.CURDIR}/../../
(notice slash immediate following ${.CURDIR} and only two ../. Really
only one is needed since since the port is in the same category. But
this is unnecessary if you make the change above.
Is this information documented somewhere? And how do I overcome this
obvious problem?
I don't know if it's documented or not. The more common occurrence is
trying to include a file from another port, rather than trying to make
a port (which has forked bombed me when it ran into an unexpected error
which is why I hate make in a shell so much).
There are multiple ways to point out problems. One way is to point to
the problem and say, Look - you screwed up here. That's your way, and
I can assure you it doesn't lend to a sense of cooperation and learning.
If you want to get pedantic, I never addressed you directly or by name.
I said the option wasn't properly tested (obviously true) and that
there were multiple problems with it (again true). I told the user to
open a PR and document it, and let the maintainer deal with it. I'm a
bit perplexed about why you are so sensitive about it. It's a honest
mistake, I think you learned from it, move on. Nobody thinks less, this
kind of thing is discovered all the time.
You know, you could have just said, Thank you as I've spent a
considerable time on this topic when nobody else did.
Yes, and you could have been a lot more pleasant. Don't forget, port
maintainers are volunteers.
What do you think I am?
maintainers are volunteers. I spend my personal time working on these
problems, and the thanks I get from you is, hey, you screwed this up,
you screwed that up, in fact, I can see five or six problems just from a
brief look at your port instead of here's what the problem is, and
here's a way to fix it.
1. I can't stress enough that you were never addressed directly or by name.
2. I only stated the truth
3. Do you really think I should do this for you? Or spoon-feed you? I
believe I gave you more than enough information to both understand the
problem and figure out the solution. that's how people learn.
It's not an attitude that makes me want to get to work on fixing the
problems.
How about pride in a job well done?
Again, I think you should accept this in the spirit it was given. If
you found it unpleasant, I'm sorry but that wasn't the intention.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
--On October 21, 2013 7:09:06 PM +0200 John Marino
freebsd.cont...@marino.st wrote:
On 10/21/2013 18:15, Paul Schmehl wrote:
--On October 21, 2013 7:48:59 AM +0200 John Marino
The dependency is mysqltcl. That port installs two files in
${LOCALBASE}/lib/mysqltcl-${PORTVERSION}/. How do you reference those
files without using the portversion?
Look at section 5.8.9 of the Porters Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html
Something like this should work:
RUN_DEPENDS+= mysqltcl3:${PORTSDIR}/databases/mysqltcl
No, it won't. You can't use that construction on libraries, which is what
mysqltcl is.
What do you think I am?
I haven't the foggiest idea. What you come across as is a guy who thinks
he knows everything and everyone else is stupid.
3. Do you really think I should do this for you? Or spoon-feed you? I
believe I gave you more than enough information to both understand the
problem and figure out the solution. that's how people learn.
No, you didn't. You provided the information in drips and drabs. It took
several emails, during which time I had already figured out the problem
myself before you posted what you could have posted initially.
As for your snarky do I want you to spoon-feed me, no thanks. I'd starve
to death waiting for you to feed me. You could have simply posted, in your
first reply, You cannot index commands under options. Remove the tabs.
Also, the ECHO line will probably generate a shell error anyway, so you're
going to have to find a way to resolve that. My suggestion would be to
hardcode the version number, since you can't approximate libraries.
It's not an attitude that makes me want to get to work on fixing the
problems.
How about pride in a job well done?
Again, I think you should accept this in the spirit it was given. If
you found it unpleasant, I'm sorry but that wasn't the intention.
How about I've always had pride in a job well done, and I resent you
implicating that I did not? My responses have been written the way they
were in the hope that YOU would learn something, but it's apparent you
haven't.
It's a moot point now. I've fixed the problems and updated the port to use
STAGE, and it's fixing to be sent in as a response to the PR.
--
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 20:40, Paul Schmehl wrote:
--On October 21, 2013 7:09:06 PM +0200 John Marino
Look at section 5.8.9 of the Porters Handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html
Something like this should work:
RUN_DEPENDS+= mysqltcl3:${PORTSDIR}/databases/mysqltcl
No, it won't. You can't use that construction on libraries, which is
what mysqltcl is.
Are you as certain about that as you were about the RUN_DEPENDS line not
being a shell command before? As the handbook clearly states, you can
use that construction on RUN_DEPENDS. The fact that you want a library
out of the port is not relevant. It would install everything in the
mysqltcl port, including the library you desire.
The rest of your post doesn't merit a response.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/20/2013 03:49, Paul Schmehl wrote:
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
I'm the maintainer, and I can assure you I tested it thoroughly. The
port has built without error on many machines before this came up. I've
personally built and tested it numerous times.
With the MYSQL option set on? The default is off, so building the
default configuration numerous times would not have hit this.
Nevertheless, I will take a look at what you've discussed and attempt to
determine what the problem is. It appears that something may have
changed in 9.2 that is causing the problem. Unfortunately I don't have
a 9.2 install, so I'll have to set one up before I can test it.
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition. That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port. Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
--On October 20, 2013 9:34:36 AM +0200 John Marino
freebsd.cont...@marino.st wrote:
On 10/20/2013 03:49, Paul Schmehl wrote:
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
I'm the maintainer, and I can assure you I tested it thoroughly. The
port has built without error on many machines before this came up. I've
personally built and tested it numerous times.
With the MYSQL option set on? The default is off, so building the
default configuration numerous times would not have hit this.
Yes, of course it was set. I wouldn't submit a port without testing all
its options, and committers wouldn't commit a port that doesn't build with
any options set.
Nevertheless, I will take a look at what you've discussed and attempt to
determine what the problem is. It appears that something may have
changed in 9.2 that is causing the problem. Unfortunately I don't have
a 9.2 install, so I'll have to set one up before I can test it.
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition.
You're wrong. The RUN_DEPENDS does not have a shell command embedded in it
anywhere.
That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port.
You're pretty sure? Rather than hard code a version, which would break the
port the moment mysqltcl was updated, I chose to use the existing port
version, which would work no matter what version was current on any
particular box.
Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Yes, and that is a problem. I noticed that last night when I was looking
at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD}
$$(${MYSQLTCL_CMDS}).
It looks like that port has changed, however, because it no longer appends
the version number to the name of the port, so I can probably drop that
entirely. I won't know until I test it.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
What do you suggest it be hardcoded to? ${PORTSDIR} can be set to anything
on an individual system. Using your construction forces it to be in
/usr/ports. Although that's the default, it's by no means guaranteed that
the ports tree will exist there on any given system. That's why we use
macros in Makefiles - to avoid forcing users to stick to the default
structure.
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should fail.
It didn't. I can't explain why. (I've slept since I last worked on that
port.) I can assure you I tested the port with the option enabled and it
built and ran fine.
But I doubt seriously that has anything to do with the error that the OP
reported. It's probably related to the change to bmake, which I will have
to investigate, if I have to continue to define the port version for
mysqltcl. It looks like I might not have to any more.
I'll also have to update the port to use the new STAGE syntax, so this will
take a little while.
In the future, I would appreciate it if you adopt a less smug attitude
about somebody else's work. Or take over the port if you think you're so
much better. There's three sguil ports. You're welcome to take over
maintainership if you think you're God's gift to port building.
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/21/2013 00:47, Paul Schmehl wrote:
--On October 20, 2013 9:34:36 AM +0200 John Marino
It is not a mystery what is wrong.
The RUN_DEPENDS is being executed as a shell command, not a make
definition.
You're wrong. The RUN_DEPENDS does not have a shell command embedded in
it anywhere.
When you indent, it executes the command in the shell. Notice that only
make targets are indented.
That was never correct, and the new bmake makes this much
more obvious. Secondly, I'm pretty sure you can specify
databases/mysqltcl without having to execute a make command on that
port.
You're pretty sure? Rather than hard code a version, which would break
the port the moment mysqltcl was updated, I chose to use the existing
port version, which would work no matter what version was current on any
particular box.
Yes, I am sure. You can tell it that the port is the dependency
regardless of version. If you absolutely wanted to specify a file, you
can specify a different one that the file name doesn't change. Yes, you
can a RUN_DEPENDS without that line in ways that are robust.
Thirdly, you use ${MYSQLTCL_VER}, but it's never defined.
Yes, and that is a problem. I noticed that last night when I was
looking at the port. Line 46 should read MYSQLTCL_VER= @${ECHO_CMD}
$$(${MYSQLTCL_CMDS}).
Again, completely unnecessary. Specify the *NON-INDENTED* RUN_DEPENDS
in a better way.
It looks like that port has changed, however, because it no longer
appends the version number to the name of the port, so I can probably
drop that entirely. I won't know until I test it.
Apparently line 46 was intended to define it but does not. Lastly, if
you were to use a shell command (which I highly discourage), it should
be something like this (not indented, and definitely not hardcoded to
${PORTSDIR}):
MYSQLT_VER!= cd ${.CURDIR}/../../databases/mysqltcl ${MAKE} -V
PORTVERSION
What do you suggest it be hardcoded to? ${PORTSDIR} can be set to
anything on an individual system. Using your construction forces it to
be in /usr/ports. Although that's the default, it's by no means
guaranteed that the ports tree will exist there on any given system.
That's why we use macros in Makefiles - to avoid forcing users to stick
to the default structure.
I just showed you. Replace ${PORTSDIR} with ${.CURDIR}/../../
I know you haven't believed a thing I've said so far, but using
${PORTSDIR} can break the build in specific configurations. And yes,
we've been replacing it with .CURDIR in other ports.
So that's like 4 or 5 errors right off the bat, problems that were
always present. I suspect the legacy make simply didn't define
RUN_DEPENDS and continued building, so mysqltcl was never specified in
the package.
Because MYSQLTCL_VER is never defined, I think the RUN_DEPENDS should
fail. It didn't. I can't explain why. (I've slept since I last worked
on that port.) I can assure you I tested the port with the option
enabled and it built and ran fine.
So you state previously that it *HAD* to be defined for RUN_DEPENDS to
work, and now state that it wasn't defined but RUN_DEPENDS did work?
Doubtful and easily verifiable. Find an old platform where it worked
and type make -V RUN_DEPENDS and see if mysqltcl is in the list. I
believe it simply wasn't defined which didn't prevent this build from
building (it was indented, remember?). I think the error was masked
with the previous version of make.
But I doubt seriously that has anything to do with the error that the OP
reported. It's probably related to the change to bmake, which I will
have to investigate, if I have to continue to define the port version
for mysqltcl. It looks like I might not have to any more.
I'll also have to update the port to use the new STAGE syntax, so this
will take a little while.
In the future, I would appreciate it if you adopt a less smug attitude
about somebody else's work. Or take over the port if you think you're
so much better. There's three sguil ports. You're welcome to take over
maintainership if you think you're God's gift to port building.
Sigh
I guess you still feel this way after what I just wrote?
What did I do, beside help one of the port's users get going and point
out the problems with it and telling the user to write a PR?
You know, you could have just said, Thank you as I've spent a
considerable time on this topic when nobody else did.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 04:33, Stan Gammons wrote:
On 18/10/13 09:04, s_gamm...@charter.net wrote:
I was trying to install sguil-server on Release 9.2 and received the
following error. I get the same unassociated shell command when I
goto /usr/src/security/sguil-server and try make install clean. Any
ideas what the problem is?
It appears as though the problem is in line 45 of the makefile in
/usr/ports/security/sguil-server. The original line was .if
${PORT_OPTIONS:MMYSQL} changing it to .if ${PORT_OPTIONS:MYSQL} seems
to have fixed the problem. Although I haven't started over from scratch
then changed the Makefile to confirm.
That is a completely incorrectly thing to do. MMYSQL is correct,
MYSQL is not. the first M means Match. So you ready the line as,
If there is any option in the option list that matches MYSQL, do the
following. All you did was change it to look for YSQL which in
effect, is the same as not selecting the MYSQL option from the options
dialog.
Your error is line 46 where it tries to run, cd
${PORTSDIR}/databases/mysqltcl ${MAKE} -V PORTVERSION.
While running make on another port is horrible, it's not the actually
problem either.
First, make sure ports tree is up to date.
Then run, cd /usr/ports/databases/mysqltcl make-V PORTVERSION
And see if you have an error message.
If not, try sguil-server again after restoring it.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
Your error is line 46 where it tries to run, cd
${PORTSDIR}/databases/mysqltcl ${MAKE} -V PORTVERSION.
While running make on another port is horrible, it's not the
actually
problem either.
First, make sure ports tree is up to date.
Then run, cd /usr/ports/databases/mysqltcl make-V PORTVERSION
And see if you have an error message.
If not, try sguil-server again after restoring it.
I started from scratch. Reinstalled the OS, updated the ports tree then
changed to /usr/ports/databases/mysqltcl and ran make -V PORTVERSION
That resulted in 3.052 being returned. Changing to
/usr/ports/security/sguil-server and running make install starts the
build process and I get the prompt to build with MYSQL. When I select
MYSQL option, it bombs with the same error.
What I tried before was install all of the depends with portmaster, then
tried to install sguil-server by going to
/usr/ports/security/sguil-server and running make install. I got the
same unassociated shell command error. Modifying the Makefile by
removing the M allowed the build process to continue. I had to stop the
build process before it completed since that machine was getting really
hot from being run so hard all day. So, I don't know if the build would
have completed. I can try it again, but I'd like to find out what's
causing this to fail.
Any other ideas?
Stan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 15:15, s_gamm...@charter.net wrote:
I started from scratch. Reinstalled the OS, updated the ports tree then
changed to /usr/ports/databases/mysqltcl and ran make -V PORTVERSION
That resulted in 3.052 being returned. Changing to
/usr/ports/security/sguil-server and running make install starts the
build process and I get the prompt to build with MYSQL. When I select
MYSQL option, it bombs with the same error.
What I tried before was install all of the depends with portmaster, then
tried to install sguil-server by going to
/usr/ports/security/sguil-server and running make install. I got the
same unassociated shell command error. Modifying the Makefile by
removing the M allowed the build process to continue. I had to stop the
build process before it completed since that machine was getting really
hot from being run so hard all day. So, I don't know if the build would
have completed. I can try it again, but I'd like to find out what's
causing this to fail.
Any other ideas?
other ideas?
The line I mentioned is the one returning the error. That is still
true, it's not getting 3.052 when building security/sguil-server.
You need to forget about removing the M, that's a red herring. By
removing the M, you skipped the line that is failing, but that also
means MYSQL isn't built in either.
If you just want the thing to build (and not care if that sguil-server
makefile is busted), then try this:
1) Remove line 46 completely.
2) On line 47, replace ${MYSQLTCL_VER} with 3.052
I feel that the makefile could be reworked to avoid calling make on
databases/mysqltcl in a number of different ways, but that is for the
maintainer to decide (i.e. open a PR so it's fixed permanently).
Regards,
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
The line I mentioned is the one returning the error. That is still
true, it's not getting 3.052 when building security/sguil-server.
You need to forget about removing the M, that's a red herring. By
removing the M, you skipped the line that is failing, but that also
means MYSQL isn't built in either.
If you just want the thing to build (and not care if that sguil-server
makefile is busted), then try this:
1) Remove line 46 completely.
2) On line 47, replace ${MYSQLTCL_VER} with 3.052
I feel that the makefile could be reworked to avoid calling make on
databases/mysqltcl in a number of different ways, but that is for the
maintainer to decide (i.e. open a PR so it's fixed permanently).
I modified like so, and it still bombs... Guess I'll have to file a PR
or build it manually like I talked about before.
.if ${PORT_OPTIONS:MMYSQL}
# @${ECHO_CMD} $$(${MYSQLTCL_CMDS})
RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
.endif
root@gateway2:/usr/ports # portmaster security/sguil-server
=== Port directory: /usr/ports/security/sguil-server
=== Gathering distinfo list for installed ports
Makefile, line 47: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
Makefile, line 47: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
Makefile, line 47: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
=== Gathering dependency list for security/sguil-server from ports
Makefile, line 47: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
=== No dependencies for security/sguil-server
=== Starting build for security/sguil-server ===
=== All dependencies are up to date
Makefile, line 47: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
Makefile, line 47: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
=== make clean failed
=== Aborting update
=== Killing background jobs
Terminated
=== You can restart from the point of failure with this command line:
portmaster flags security/sguil-server
=== Exiting
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 16:15, s_gamm...@charter.net wrote:
I modified like so, and it still bombs... Guess I'll have to file a PR
or build it manually like I talked about before.
.if ${PORT_OPTIONS:MMYSQL}
# @${ECHO_CMD} $$(${MYSQLTCL_CMDS})
RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
.endif
Ah, try removing the tab before RUN_DEPENDS, so that the R is on the
first column (iow, remove the indent).
you can test it my make -V RUN_DEPENDS and verifying mysqltcl is in
the result (and that there is no shell error)
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On Sat, Oct 19, 2013 at 9:23 AM, John Marino wrote:
On 10/19/2013 16:15, s_gamm...@charter.net wrote:
I modified like so, and it still bombs... Guess I'll have to file a
PR
or build it manually like I talked about before.
.if ${PORT_OPTIONS:MMYSQL}
# @${ECHO_CMD} $$(${MYSQLTCL_CMDS})
RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-3.052:${PORTSDIR}/databases/mysqltcl
.endif
Ah, try removing the tab before RUN_DEPENDS, so that the R is on
the
first column (iow, remove the indent).
you can test it my make -V RUN_DEPENDS and verifying mysqltcl is in
the result (and that there is no shell error)
John
Looks like that fixed it. It's building now.
Should the tab be removed before @${ECHO_CMD} $$(${MYSQLTCL_CMDS}) ?
Thanks for your help!
Stan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 10/19/2013 16:32, s_gamm...@charter.net wrote:
Looks like that fixed it. It's building now.
Should the tab be removed before @${ECHO_CMD} $$(${MYSQLTCL_CMDS}) ?
No, I think that line is broken too, in at least two different ways.
The MYSQL option is busted. It doesn't appear to me that it was ever
tested; I can't see how it ever worked.
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
John
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
--On October 19, 2013 4:37:58 PM +0200 John Marino
freebsd.cont...@marino.st wrote:
On 10/19/2013 16:32, s_gamm...@charter.net wrote:
Looks like that fixed it. It's building now.
Should the tab be removed before @${ECHO_CMD} $$(${MYSQLTCL_CMDS}) ?
No, I think that line is broken too, in at least two different ways.
The MYSQL option is busted. It doesn't appear to me that it was ever
tested; I can't see how it ever worked.
You should create a PR on sguil-server and document all this there and
request the maintainer fix it properly. Personally I don't think any
shell commands are needed at all, certainly not to specify a
RUN_DEPENDS. it's all messed up.
I'm the maintainer, and I can assure you I tested it thoroughly. The port
has built without error on many machines before this came up. I've
personally built and tested it numerous times.
Nevertheless, I will take a look at what you've discussed and attempt to
determine what the problem is. It appears that something may have changed
in 9.2 that is causing the problem. Unfortunately I don't have a 9.2
install, so I'll have to set one up before I can test it.
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
***
It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead. Thomas Jefferson
There are some ideas so wrong that only a very
intelligent person could believe in them. George Orwell
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Compiling sguil-server on Release 9.2 i386
I was trying to install sguil-server on Release 9.2 and received the
following error. I get the same unassociated shell command when I goto
/usr/src/security/sguil-server and try make install clean. Any ideas
what the problem is?
root@gateway2:~ # cd /usr/src
root@gateway2:/usr/src # portmaster security/sguil-server
=== Port directory: /usr/ports/security/sguil-server
=== Gathering distinfo list for installed ports
Makefile, line 45: Unassociated shell command @${ECHO_CMD}
$$(${MYSQLTCL_CMDS})
Makefile, line 46: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-${MYSQLTCL_VER}:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
Makefile, line 45: Unassociated shell command @${ECHO_CMD}
$$(${MYSQLTCL_CMDS})
Makefile, line 46: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-${MYSQLTCL_VER}:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
Makefile, line 45: Unassociated shell command @${ECHO_CMD}
$$(${MYSQLTCL_CMDS})
Makefile, line 46: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-${MYSQLTCL_VER}:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
=== Gathering dependency list for security/sguil-server from ports
Makefile, line 45: Unassociated shell command @${ECHO_CMD}
$$(${MYSQLTCL_CMDS})
Makefile, line 46: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-${MYSQLTCL_VER}:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
=== No dependencies for security/sguil-server
=== Starting build for security/sguil-server ===
=== All dependencies are up to date
Makefile, line 45: Unassociated shell command @${ECHO_CMD}
$$(${MYSQLTCL_CMDS})
Makefile, line 46: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-${MYSQLTCL_VER}:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
Makefile, line 45: Unassociated shell command @${ECHO_CMD}
$$(${MYSQLTCL_CMDS})
Makefile, line 46: Unassociated shell command RUN_DEPENDS+=
${LOCALBASE}/lib/mysqltcl-${MYSQLTCL_VER}:${PORTSDIR}/databases/mysqltcl
make: fatal errors encountered -- cannot continue
=== make clean failed
=== Aborting update
=== Killing background jobs
Terminated
=== You can restart from the point of failure with this command line:
portmaster flags security/sguil-server
=== Exiting
root@gateway2:/usr/src #
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Compiling sguil-server on Release 9.2 i386
On 18/10/13 09:04, s_gamm...@charter.net wrote:
I was trying to install sguil-server on Release 9.2 and received the
following error. I get the same unassociated shell command when I
goto /usr/src/security/sguil-server and try make install clean. Any
ideas what the problem is?
It appears as though the problem is in line 45 of the makefile in
/usr/ports/security/sguil-server. The original line was .if
${PORT_OPTIONS:MMYSQL} changing it to .if ${PORT_OPTIONS:MYSQL} seems
to have fixed the problem. Although I haven't started over from scratch
then changed the Makefile to confirm.
Stan
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
