RE: [broken] security/tripwire
/usr/ports/security/tripwire # make
Makefile, line 164: Malformed conditional (${PORT_OPTIONS:MDB_BUILD}
${WITH_DB_BUILD} == true)
Makefile, line 177: if-less endif
make: fatal errors encountered -- cannot continue
This has already been fixed long ago
While that may be so I can confirm that this problem has re-appeared on
FreeBSD 9.2 with a current check out of the ports collection. I updated my
ports collection this evening using portsnap for the weekly server
maintenance session and was also confronted with this error.
First when running 'portmaster -L' to check up on new versions (this crashed
due to the error), then it turned out that its currently even impossible to
run something as trivial as 'make config' without this error showing up:
root@chihiro:/usr/ports/security/tripwire # make config
Makefile, line 122: Malformed conditional (${PORT_OPTIONS:MSW_ONLY}
${WITH_SW_ONLY} == true)
Makefile, line 127: if-less endif
make: fatal errors encountered -- cannot continue
Kind regards,
Peter
___
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: [broken] security/tripwire
Oh you are right there was a second one, fixed now. Nice job Bapt! I just updated my Ports collection using portsnap again this morning and can now confirm a more positive situation as well; working like a charm once again. That was quick. Thanks for reporting And thank you for fixing maintaining one of my favourite software projects :) Kind regards, Peter ___ 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: stagedir vs. jail
On Sun, Oct 13, 2013 at 12:58:53PM +0200, Ekkehard Gehm wrote: Nope that doesn't work as there is no way to globally disable staging, if you add NO_STAGE in make.conf all you end up with is a messed package db, if you are very very lucky it might sometime work. I know this method is frowned upon because it's not a method which was intended to be used by end users, but I have to disagree with you here: this setting seems to work flawlessly in disabling staging. In my situation I'm using a /tmp directory which has the exec flag disabled in order to prevent escalation whenever a customer website uses scripts which aren't as secured as they (c/sh)ould have been. At the very least it blocks 3rd parties from having an easy place to execute their stuff. Ever since staging was introduced I've been having issues where installations or upgrades stopping somewhere near the end and gave an error that the script couldn't execute ./INSTALL. It took me a while but I traced it back to the use of the pkg_add command; apparently it's used to install the created package but without pointing it to a dedicated temporary directory, thus pkg_add defaults to using either /var/tmp or /tmp. Both of which have exec disabled on my system, and so the installation fails. Needless to say but as soon as I specify NO_STAGING on the commandline or in make.conf (which I've been using during upgrade sessions from FreeBSD 9.1 to 9.2 where I rebuild some ports to be sure everything kept working optimally) the whole installation process seems to resort to the previous situation and I get no errors regarding ./INSTALL which can't be executed. Using portmaster or the pkg_info / pkg_version tools also don't show any problems with my package database. Though I could imagine things to be different when using pkgng, I haven't experimented much with that as of yet. As said; I realize that this may not have been intended and it may be ill advised, but at this point this surely seems to be a very effective way to turn staging off. Right now the new stating process gives me more bother than advantages unfortunately. I can understand the theoretical advantages, but fact of the matter is that those don't apply on my situation. With kind regards, Peter -- .\\ S/MIME public key: http://www.catslair.org/pubkey.crt +- My semi-private Root CA: http://ssl.losoco.nl/losoco.crt ___ 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: stagedir vs. jail
I know this method is frowned upon because it's not a method which was
intended to be used by end users, but I have to disagree with you here:
this
setting seems to work flawlessly in disabling staging.
Until you try to install a port that has been converted to use staging,
when it will likely fail. You're only getting apparent successes at the
moment because the staging conversion process has only recently begun.
I'm also not too sure abou that. When looking at lang/perl5.14 you'll see
upon studying it's Makefile that it fully seems to support staging. It
doesn't set NO_STAGE, when issueing make build you'll come across the
stage directory in the ports work directory, and even in the Makefile itself
you'll see it being put to use. For example:
post-install:
@${MKDIR} ${STAGEDIR}${PREFIX}/lib/perl5/${PERL_VER}/man/man3
@${MKDIR} ${STAGEDIR}${SITE_PERL}/${PERL_ARCH}/auto
And yet this is also a good example of a port where a reinstall or updating
will fail on my system because of pkg_add being used to install the
generated package, which in its turn demands /tmp to have the exec flag set.
I'm repeating myself, but forcing NO_STAGE overrides that behavior.
However, one thing I do agree with: you're absolutely right that staging is
still in the early stages (no pun intended), so I wouldn't be surprised if
this behavior got changed somehow in the future.
Kind regards, Peter
___
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: Would software for non-commercial use be acceptable as a port?
This is how DansGuardian works, and it's a part of the ports tree (www/dansguardian). The install points the user to the licensing page on the web. It's up to the user to decide if they're eligible for the non-com license. Thanks a lot for that example, that's a very helpful example indeed. Wasn't even aware of this one so far. And apologies for misaddressing my response in the first place, thus making it end up in your private mailbox instead of the list. Kind regards, Peter -- .\\ S/MIME public key: http://www.catslair.org/pubkey.crt +- My semi-private Root CA: http://ssl.losoco.nl/losoco.crt ___ 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: Would software for non-commercial use be acceptable as a port?
There are a number of entries in ports/LEGAL along the lines of no commercial use, often with RESTRICTED or NO_CDROM or the like also set in the ports' Makefile's. Lots of examples to extrapolate from there. Thanks for the pointers. I had already skimmed through the Porters handbook but was under the impression that the limitations one could place on the software only involved around distribution or storage and not so much other forms of licensing as well. Obviously it didn't help to overlook LEGAL completely as well :-) Now I have plenty of material and examples to work with, and will contact the company behind this software to check if they agree with my ideas as well. Kind regards, Peter -- .\\ S/MIME public key: http://www.catslair.org/pubkey.crt +- My semi-private Root CA: http://ssl.losoco.nl/losoco.crt ___ 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
Would software for non-commercial use be acceptable as a port?
Hi gang, I've been professionally using FreeBSD for quite some time now (my company now uses 4 FreeBSD servers for web services) and during the implementation period I've become quite fascinated with the ports system. And this evening I suddenly had an idea, but I'm not too sure how feasible this idea is, so I'm hoping some of you guys would be willing to give me some suggestions or advice. I've been using a commercial software product for the past 4 years now; I started using it on Linux and nowadays I use it on Windows. The company behind this product provides several editions of their product, including a community edition which can be used free of charge but non-commercial use only. It does have some functional limitations which, in my opinion (but I am biased), aren't really intrusive. For example if you print some output you'll get a watermark too. Stuff like that. Even so; I strongly support this software. Like I said before I've been using it myself for the past 4 years (in all fairness: I got myself a commercial license too, which wasn't too expensive in my opinion) and even now I'm still quite passionate about this stuff. Now; I read that the ports collection provides a /truly/ free environment and doesn't shun entries which may not match the idea of free and/or open source software. So my question should be obvious: Would I be right to assume that the software product as I described it above could be a liable addition for the ports collection, or is there something I'm overlooking? Needless to say I'm obviously contacting the company behind it as well, I can say I'm in quite good terms with them, and nothing will be done without their explicit permission. But before I start on such an endeavor I'd really appreciate if you guys could confirm (or deny) if my plans are actually feasible? Am I right to conclude that the product, with the non-commercial clause I described above, could be a candidate for the ports collection or would the restriction be a huge obstacle? Thanks in advance for any comments, I'd really appreciate some advice and/or comments here. Kind regards, Peter -- .\\ S/MIME public key: http://www.catslair.org/pubkey.crt +- My semi-private Root CA: http://ssl.losoco.nl/losoco.crt ___ 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
