Re: FreeBSD Port: git-2.0.1 unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
This comes up from time to time. I think most people solve it by rebuilding docbook. -- WXS On Fri, Jul 18, 2014 at 02:06:40AM +0200, David wrote: Path: . Working Copy Root Path: /usr/ports URL: https://svn0.eu.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.eu.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 362166 Node Kind: directory Schedule: normal Last Changed Author: thierry Last Changed Rev: 362166 Last Changed Date: 2014-07-17 23:17:48 +0200 (Thu, 17 Jul 2014) I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; compilation error: file /tmp/xmlto-xsl.0LLyQ9 line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl gmake[2]: *** [git-subtree.1] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/git/work/git-2.0.1/contrib/subtree' *** Error code 2 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 ___ 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: FreeBSD Port: git-2.0.1 unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
Ugh, I thought I thoroughly tested this update. I don't think the problem is related to OpenSSL from ports at all. I botched the plist somewhere. I'll take a look at this tomorrow and hopefully get a fix in. Sorry for the noise, my testing systems have recently undergone some major changes. -- WXS On Wed, Jul 23, 2014 at 03:16:50AM +0200, David wrote: It worked! Thanks. But now I get this instead. === Checking if devel/git already installed === Registering installation for git-2.0.2 pkg-static: lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-http-fetch): No such file or directory pkg-static: lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-http-push): No such file or directory pkg-static: lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-http): No such file or directory pkg-static: lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-https): No such file or directory pkg-static: lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-ftp): No such file or directory pkg-static: lstat(/usr/ports/devel/git/work/stage/usr/local/libexec/git-core/git-remote-ftps): No such file or directory *** Error code 74 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 Stop. make: stopped in /usr/ports/devel/git (I'm trying to use openssl from ports if that might be causing this.) On 2014-07-22 16:01, Gary J. Hayers wrote: I get this error all the time, could you expand on reinstalling docbook as I did this and still get the same error. Many thanks, Gary On 22/07/2014 14:01, Wesley Shields wrote: This comes up from time to time. I think most people solve it by rebuilding docbook. -- WXS On Fri, Jul 18, 2014 at 02:06:40AM +0200, David wrote: Path: . Working Copy Root Path: /usr/ports URL: https://svn0.eu.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.eu.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 362166 Node Kind: directory Schedule: normal Last Changed Author: thierry Last Changed Rev: 362166 Last Changed Date: 2014-07-17 23:17:48 +0200 (Thu, 17 Jul 2014) I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl; compilation error: file /tmp/xmlto-xsl.0LLyQ9 line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl gmake[2]: *** [git-subtree.1] Error 1 gmake[2]: Leaving directory `/usr/ports/devel/git/work/git-2.0.1/contrib/subtree' *** Error code 2 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 ___ 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 ___ 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: I need help with git
On Tue, Feb 05, 2013 at 11:30:43AM +1030, Shane Ambler wrote: GH_COMMIT= 4dfdc80 Probably not needed if you specify a tag other than master. If I pull master, I get commit f57e464. That's not what I want. Why doesn't this thing pull the commit I'm telling it to pull? I think the thing most people miss here is that GH_COMMIT doesn't effect what gets downloaded, it's not used like an svn rev number - it is only used to define WRKSRC When a github tarball gets extracted GH_COMMIT is part of the dir name. Which is why it is mandatory and needs to match the tag. It is just needed to work with the way github creates tarballs. It is inconvenient but github is only setup to let you download tarballs of specific tags not specific commits. If the main devs don't tag the specific points you want the only option is to fork and create your own tags. I don't know if we have a way to express this in the ports framework but you absolutely can grab a tarball of a repo at any specific commit on github even if it is not tagged. This is the URL to grab ironbee/libhtp at 234fd5bab1225e483ea263a5a15faebed0bd61b9: https://github.com/ironbee/libhtp/archive/234fd5bab1225e483ea263a5a15faebed0bd61b9.tar.gz -- WXS ___ 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: Problems with GITHUB pulls
On Tue, Jan 29, 2013 at 03:24:31PM -0600, Paul Schmehl wrote:
I maintain the security/barnyard2 port. It pulls the software from git,
which is the only place where it's available.
Here's the relevant portion of the port's Makefile:
USE_GITHUB= yes
GH_ACCOUNT= firnsy
GH_PROJECT= ${PORTNAME}
GH_TAGNAME= master
GH_COMMIT= 4dfdc80
The problem is, master's commit tag and md5 sum and size have changed. I
*could* update the port by changing the commit tag and the distino file,
but that's seems rather kludgy to me. The version hasn't changed. The
developers simply fixed some problems in the software and then bumped
master to the newer commit.
The point of GH_COMMIT is to checkout a specific commit. I think you
don't need GH_TAGNAME set here as that is probably overriding the
desired behavior (and always fetching the latest from master). For an
idea of how to fetch a specific commit from git check out devel/libhtp.
-- WXS
___
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: Problems with GITHUB pulls
On Tue, Jan 29, 2013 at 10:10:13PM -0500, Wesley Shields wrote:
On Tue, Jan 29, 2013 at 03:24:31PM -0600, Paul Schmehl wrote:
I maintain the security/barnyard2 port. It pulls the software from git,
which is the only place where it's available.
Here's the relevant portion of the port's Makefile:
USE_GITHUB= yes
GH_ACCOUNT= firnsy
GH_PROJECT= ${PORTNAME}
GH_TAGNAME= master
GH_COMMIT= 4dfdc80
The problem is, master's commit tag and md5 sum and size have changed. I
*could* update the port by changing the commit tag and the distino file,
but that's seems rather kludgy to me. The version hasn't changed. The
developers simply fixed some problems in the software and then bumped
master to the newer commit.
The point of GH_COMMIT is to checkout a specific commit. I think you
don't need GH_TAGNAME set here as that is probably overriding the
desired behavior (and always fetching the latest from master). For an
idea of how to fetch a specific commit from git check out devel/libhtp.
I think I might have completely misspoken here. What's happening is you
are fetching master at the appropriate commit, but distinfo is getting
the filename with the DISTVERSION string in it. When you update to the
next commit the DISTVERSION isn't changing and thus distinfo is now out
of date.
The best way to approach this is as was suggested by someone else. Get
upstream to tag releases and use those. The way you are doing it you
will have to set a PORTVERSION that is not accurate at all and bump
PORTREVISION everytime you update.
The devel/libhtp port is using a very old tag because upstream has not
tagged a new version in the last 7 months and I don't want to end up in
the situation you are experiencing.
-- WXS
___
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: databases/mongodb fails to start, assertion failure in unit test
On Sat, Jan 26, 2013 at 07:06:21AM -0800, Waitman Gobble wrote:
Waitman Gobble uzi...@da3m0n8t3r.com wrote ..
Hi,
I've installed databases/mongodb and get an error when starting.
# /usr/local/etc/rc.d/mongod start
Starting mongod.
forked process: 59576
all output going to: /var/db/mongodb/mongod.log
/usr/local/etc/rc.d/mongod: WARNING: failed to start mongod
# cat /var/db/mongodb/mongod.log
Fri Jan 25 00:30:57 Assertion failure l bigl src/mongo/db/btree.cpp 1973
0x5a503d 0x5eb41d 0x74dce9 0x547638 0x545ed9 0x542bc1
0x5a503d _ZN5mongo12verifyFailedEPKcS1_j+285 at /usr/local/bin/mongod
0x5eb41d _ZN5mongo10BTUnitTest3runEv+333 at /usr/local/bin/mongod
0x74dce9 _ZN5mongo11StartupTest8runTestsEv+57 at /usr/local/bin/mongod
0x547638 main+5992 at /usr/local/bin/mongod
0x545ed9 main+9 at /usr/local/bin/mongod
0x542bc1 _start+145 at /usr/local/bin/mongod
Fri Jan 25 00:30:57 Got signal: 6 (Abort trap: 6).
# portversion -v mongodb
mongodb-2.2.0_1 = up-to-date with port
# uname -a
FreeBSD kamira.waitman.net 9.1-STABLE FreeBSD 9.1-STABLE #0 r245772M: Tue
Jan 22
06:09:00 PST 2013 r...@kamira.waitman.net:/usr/obj/usr/src/sys/BURPLEX
amd64
I added a couple lines to print the values before the failure.
src/mongo/db/btree.h
..
struct BTUnitTest : public StartupTest {
void run() {
DiskLoc big(0xf12312, 0x70001234);
DiskLoc56Bit bigl;
{
bigl = big;
verify( big == bigl );
DiskLoc e = bigl;
verify( big == e );
}
{
DiskLoc d;
verify( d.isNull() );
DiskLoc56Bit l;
l = d;
verify( l.isNull() );
d = l;
verify( d.isNull() );
printf(bigl %s\n,bigl.toString().c_str());
printf(l %s\n,l.toString().c_str());
verify( l bigl );
}
}
} btunittest;
..
output:
bigl f12312:70001234
l null
Thu Jan 24 23:18:17 Assertion failure l bigl src/mongo/db/btree.cpp 1978
looking at
src/mongo/db/diskloc.h
bool isNull() const { return _a == -1; }
..
int compare(const DiskLoc b) const {
int x = _a - b._a;
if ( x )
return x;
return ofs - b.ofs;
}
bool operator(const DiskLoc b) const {
return compare(b) 0;
}
..
void Null() {
_a = -1;
ofs = 0; /* note NullOfs is different. todo clean up. see refs
to
NullOfs in code - use is valid but outside DiskLoc context so confusing
as-is.
*/
}
it seems that this should be working!
test model:
#include stdio.h
int
compare (int a, int b)
{
int x = a - b;
if ( x )
return x;
return 555;
}
bool
ncompare (int a, int b)
{
return compare(a,b) 0;
}
int
main (void)
{
int a, b;
a = -1;
b = 0xf12312;
int c = a - b;
printf(%d\n,c);
c = compare(a,b);
printf(%d\n,c);
bool d = ncompare(a,b);
printf(%d\n,d);
bool e = ncompare(b,a);
printf(%d\n,e);
return 0;
}
# clang++ -o test test.cpp
# ./test
-15803155
-15803155
1
0
I'm missing something...
Suggestions, tips, hints much appreciated.
Thanks,
--
Waitman Gobble
San Jose California USA
Hi,
I've tinkered around with this problem. Commenting out the 'verify( l
bigl );' line in src/mongo/db/btree.h solves the assertion failure
problem, and mongodb starts and runs. However, after reviewing the
code it seems this 'start' unit test is only actually testing if the
thing can 'subtract integers.' I'm very puzzled as to why it is
failing, it's bombing out when it does 'verify ((-1 - 0xf12312)0)'.
which seems trivial.
The code that runs the unit test/StartupTest is simple, but i haven't
yet found the 'verify' macro, at least i believe it's a macro.
Anyhow, commenting out the test line gets mongodb running, but I'm
wondering what other problems there could be. (?)
I found that compiling with base gcc avoids the startup problem, so
this indeed seems to be an issue related to building with clang. clang
builds mongodb without error, however running the mongodb compiled
with clang fails during 'startuptest'.
IMHO It would be good to track down the problem, at least understand
the cause, but at this moment it seems like compiling mongodb with gcc
is the way to go.
I've updated the port to use the latest release/ 2.2.2 version of
mongodb, I'll submit a PR in a bit, (it does not appear to have
Re: Fwd: FreeBSD ports you maintain which are out of date
On Wed, Dec 05, 2012 at 01:59:49AM +0800, Yanhui Shen wrote: -- Forwarded message -- From: Yanhui Shen shen@gmail.com Date: 2012/12/5 Subject: Re: FreeBSD ports you maintain which are out of date To: portsc...@portscout.freebsd.org Hi, According to this page http://basiccoder.com/openfetion The OpenFetion Project is deprecated, and therefore I do not want to maintain it any more. :-( Actually, there is a 2.2.1 port, but I think the software itself is buggy. The most annonying problem is, it'll be offline when shortmsg arrived. (100%) So, in my opinion what about just remove it from the ports tree? I will set an expiration date of one month from now and remove the port then. Thanks for bringing this to our attention. -- WXS ___ 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: databases/mongodb on FreeBSD 9
On Fri, Nov 30, 2012 at 06:22:28AM -0800, Patrick wrote: Has anyone had any issues building the mongodb port on FreeBSD 9? I'm running 9.0-RELEASE-p5 on i386: It's bailing for me here: c++ -o build/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/shell/linenoise.o -c -Wnon-virtual-dtor -Woverloaded-virtual -fno-omit-frame-pointer -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -O3 -D_SCONS -DMONGO_EXPOSE_MACROS -DSUPPORT_UTF8 -D__freebsd__ -D_FILE_OFFSET_BITS=64 -DJS_C_STRINGS_ARE_UTF8 -DMONGO_SSL -DMONGO_HAVE_HEADER_UNISTD_H -DMONGO_HAVE_EXECINFO_BACKTRACE -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm -Isrc -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo -Isrc/mongo -Ibuild/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/cpp -Isrc/mongo/cpp -I/usr/local/include src/mongo/shell/linenoise.cpp In file included from src/mongo/shell/linenoise.cpp:115: src/mongo/shell/linenoise_utf8.h: In member function 'void linenoise_utf8::UtfStringMixinchar_type::swap(linenoise_utf8::UtfStringMixinchar_type)': src/mongo/shell/linenoise_utf8.h:145: error: 'swap' is not a member of 'std' src/mongo/shell/linenoise_utf8.h:146: error: 'swap' is not a member of 'std' src/mongo/shell/linenoise_utf8.h:147: error: 'swap' is not a member of 'std' scons: *** [build/freebsd/cpppath_cpp/cxx_c++/ssl/use-system-all/usesm/mongo/shell/linenoise.o] Error 1 scons: building terminated because of errors. *** Error code 2 It builds fine for me. Can you check what version of boost and it's related packages you are building against? -- WXS ___ 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: was: portsnap down.. cvs broken?
On Tue, Nov 13, 2012 at 09:45:51AM -0800, Jeffrey Bouquet wrote: Reply below...? --- On Mon, 11/12/12, Christoph Moench-Tegeder c...@burggraben.net wrote: From: Christoph Moench-Tegeder c...@burggraben.net Subject: portsnap down? To: freebsd-ports@FreeBSD.org Date: Monday, November 12, 2012, 11:33 PM Hi, as I saw noone complaining until right now (and didn't find any announcement about downtime): looks like portsnap does not provide new snapshots; if I'm reading the current snapshot tag correctly, it's from Sun Nov 11 15:54:03 CET 2012. The svnweb interface shows way more recent commits... Anyone to enlighten me or to nudge portsnap? Regards, Christoph -- Spare Space ___ 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 UPDATING is a broken link from freshports.org cvs/cvsup is not doing anything here for the last twelve hours or so... cvsweb is a broken link from freebsd.org UPDATING might have a clue (something about git) but I am unable to view it, as the cvs nor sites have access... There is some work being done on the machines that provide these services. The UPDATING entry you mention (the one about git) has nothing to do with this. -- WXS ___ 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
[HEADS UP]: CVE-2012-4929 (CRIME)
I think there is nothing FreeBSD can do about this besides making sure our users are aware of it. The situation in which this is a problem is specific but one you should consider if you are using TLS with compression. TLS 1.2 and earlier are vulnerable to an attack commonly known as CRIME. The attack involves TLS sessions using compression where an attacker is able to inject known plaintext into the stream. Through a series of guesses and measuring the length of the encrypted text an attacker is able to determine the plaintext. The recommended workaround for now is to disable compression on servers where this may have an impact. As this is a flaw in a protocol and no one specific implementation please consult the documentation for any affected services to determine how to turn off TLS compression. More information is available at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4929 -- WXS ___ 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: Failed upgrade sudo-1.8.5.p3 to sudo-1.8.6.p3 running stable/9
On Wed, Sep 26, 2012 at 02:05:57PM -0700, David Wolfskill wrote: On Wed, Sep 26, 2012 at 04:59:28PM -0400, Wesley Shields wrote: On Wed, Sep 26, 2012 at 04:43:57AM -0700, David Wolfskill wrote: This is a FreeBSD/i386 stable/9 system: FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #485 240956M: Wed Sep 26 04:19:48 PDT 2012 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 built with clang, but cc is gcc: This is a failure on i386 only, which is why I didn't notice it. Would you apply the patch available at [1] and let me know if it works. It does build for me now that I built up a i386 environment. [1]: http://people.freebsd.org/~wxs/sudo-ssp.diff Aye; builds a trivial test: d134(9.1-P)[1] sudo id Password: uid=0(root) gid=0(wheel) groups=0(wheel),5(operator) d134(9.1-P)[2] works. :-} My original patch did not build correctly with clang. I've just committed r304961 which works on both i386 and under clang. -- WXS ___ 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: redports - should I rename the updated distfile (tarball)?
On Thu, Sep 27, 2012 at 12:55:51PM +0100, Anton Shterenlikht wrote: redports.org is good, thank you to whoever worked on it. One question: the upstream for my port is non-existent, so rather then patch it, I'm updating the code itself. I then create a new tarball. It seems redports doesn't update the tarball every time I request a build. So it seems I have to update the version in Makefile each time and create a tarball with this new number. Is that so? I can't comment on the relation of this to redports as I've never used it myself. I can state that if you're modifying the source and creating a new tarball you should bump the PORTVERSION in the port (and consequently in your distfile too) and also make sure distinfo is correct. This will help to distinguish your changed tarball from the original. -- WXS ___ 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: Failed upgrade sudo-1.8.5.p3 to sudo-1.8.6.p3 running stable/9
On Wed, Sep 26, 2012 at 04:43:57AM -0700, David Wolfskill wrote: This is a FreeBSD/i386 stable/9 system: FreeBSD freebeast.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #485 240956M: Wed Sep 26 04:19:48 PDT 2012 r...@freebeast.catwhisker.org:/usr/obj/usr/src/sys/GENERIC i386 built with clang, but cc is gcc: This is a failure on i386 only, which is why I didn't notice it. Would you apply the patch available at [1] and let me know if it works. It does build for me now that I built up a i386 environment. [1]: http://people.freebsd.org/~wxs/sudo-ssp.diff -- WXS ___ 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: security/sudo: make fails after update to 1.8.6p3
On Wed, Sep 26, 2012 at 09:43:06PM +0900, Yasuhiro KIMURA wrote: From: ??ukasz W??sikowski luk...@wasikowski.net Subject: Re: security/sudo: make fails after update to 1.8.6p3 Date: Wed, 26 Sep 2012 14:14:37 +0200 W dniu 2012-09-26 13:57, Herbert J. Skuhra pisze: After update of security/sudo to 1.8.6p3, make fails on 9.0-RELEASE as following: [Several lines removed] Are there anyone alse experienced this? Yes, the port obviously builds only on amd64. True, I've installed it successfully on amd64 and got the same error on i386 box. Thanks. I found PR for this issue is already sent. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/172085 So I'll wait for maintainer's reaction. This patch [1] should suffice. Please test it out and let me know. [1]: http://people.freebsd.org/~wxs/sudo-ssp.diff -- WXS ___ 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: Qestion about patching
On Mon, Aug 20, 2012 at 10:03:54AM +0800, HU Dong wrote:
Hi!
The porter's handbook says that Note that if the path of a patched
file contains an underscore (_) character, the patch needs to have two
underscores instead in its name. For example, to patch a file named
src/freeglut_joystick.c, the corresponding patch should be named
patch-src-freeglut__joystick.c.
Question: What if the file contains -
charactor(src/freeglut-joystick.c)? Should the patch be
patch-src-freeglut-joystick.c or patch-src-freeglut--joystick.c?
When applying a patch I get from upstream I apply it manually in
${WRKSRC} and then use 'make makepatch' from the port directory to
generate the appropriate filename in files for me.
-- WXS
___
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: [Full-disclosure] nvidia linux binary driver priv escalation exploit
On Wed, Aug 08, 2012 at 10:34:06AM +, Alexey Dokuchaev wrote: On Mon, Aug 06, 2012 at 01:49:50PM +0200, Rainer Hurling wrote: Am 06.08.2012 10:03 (UTC+1) schrieb Doug Barton: On 08/01/2012 05:09, Oliver Pinter wrote: I found this today on FD: http://seclists.org/fulldisclosure/2012/Aug/4 Apparently this affects us as well. Any news? Thanks for the info. I had been not aware of it before. NVidia has released a driver version 304.32 for FreeBSD i386 and amd64, which should remedy these security issues. Luckily, they've released version 295.71 which is on Long Lived Branch. I will update the port shortly. Thank you! VuXML entry will have to follow separately, as it is unclear whether new CVE number will be assigned or not. You can do the VuXML without a CVE for now and update it when/if one is assigned. -- WXS ___ 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: net/mosh conflicts with lang/mosh
On Thu, Aug 09, 2012 at 12:12:32AM +0800, Yanhui Shen wrote: Hi, net/mosh is a mobile terminal, while lang/mosh is a R6RS scheme interpreter, and both of them have bin/mosh. So is there any way to make both of them installed? Or actually, one of which needs to be renamed? No decent way to have both of them installed under the same prefix. You can always install one in a chroot somewhere. One of them would need to rename bin/mosh to something else. -- WXS ___ 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: Can I get some love on this PR?
On Mon, Jul 02, 2012 at 12:55:28PM -0400, Bill Moran wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168583 This bugger is about a month old at this point. Of course, part of that is my fault for being slow to respond, so I'm just putting a heads-up out -- if anyone is able to commit that, it'd be great. I'll grab it, unless sylvio@ speaks up and says he's going to commit it soon. -- WXS ___ 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: ports/169078
On Mon, Jun 25, 2012 at 06:24:22PM +0300, Kimmo Paasiala wrote: Hi, I wrote a small fix for ports-mgmt/psearch some time ago and I submitted a bug report http://www.freebsd.org/cgi/query-pr.cgi?pr=169078 and the maintainer of the port rolled out a new distfile for a new version but the fix hasn't been yet committed to the ports tree. Could someone commit this? I've grabbed this PR and will be committing the update to 2.0.2 shortly. -- WXS ___ 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: etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7)
On Thu, Jun 21, 2012 at 11:40:15AM +, Michael Scheidell wrote: Sorry if I confused you with more than one comment in one email. Next time I will send multiple emails with just one comment in each email. I hope this helps. Please try to be civil. -Original message- From: Mikhail T. mi+t...@aldan.algebra.com To: Michael Scheidell scheid...@freebsd.org Cc: freebsd-ports@freebsd.org freebsd-ports@freebsd.org Sent: Thu, Jun 21, 2012 11:32:59 GMT+00:00 Subject: etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7) On 21.06.2012 06:54, Michael Scheidell wrote: you are more then welcome to adopt them. Is the above REALLY, what API no longer supported means these days? -mi The release in our ports tree is not recommended upstream anymore. Quoting the upstream webpage: Take note they [old releases] won't usually work with recent LLVM and GNUstep releases. As the port is unmaintained and the version in our tree is not recommended for use anymore it was deprecated. Sure, the reason could be more clear. I will commit an update that reflects that to make it more clear. If you would like to see this port remain in the tree I recommend adopting it and keeping it in working order (first step is to update it to a recommended release). -- WXS ___ 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: etoile ports dropped for strange reason (Re: freebsd-ports Digest, Vol 474, Issue 7)
On Thu, Jun 21, 2012 at 12:27:04PM -0400, Mikhail T. wrote: On 21.06.2012 11:37, Wesley Shields wrote: The release in our ports tree is not recommended upstream anymore. Quoting the upstream webpage: Take note they [old releases] won't usually work with recent LLVM and GNUstep releases. Do we have these recent LLVM and GNUstep releases in the tree already? In base, yes I believe so. Older, yet still supported FreeBSD releases, would require using what's in the ports tree. Please don't take my word on any of this as it was only what I read from their webpage as I don't use any of these ports. As the port is unmaintained and the version in our tree is not recommended for use anymore it was deprecated. Sure, the reason could be more clear. I will commit an update that reflects that to make it more clear. If you would like to see this port remain in the tree I recommend adopting it and keeping it in working order (first step is to update it to a recommended release). The chance of a new maintainer stepping up may increase, if the deprecation message states something like Update to a new release is required... And, of course, a more generous expiration time would be needed. These ports are a legion... I will update the deprecation message shortly. I will also update the expiration date if someone is willing to at least verbally commit to working on an update. I see no point in pushing the expiration date back if nobody is going to do the work to keep it properly maintained. If someone steps up after the port has been removed I will happily pull it out of the Attic for that person. -- WXS ___ 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: More Heimdal 1.5.2 port problems
On Sun, May 27, 2012 at 01:58:23PM -0400, Robert Simmons wrote:
On Sat, May 26, 2012 at 3:22 PM, Robert Simmons rsimmo...@gmail.com wrote:
I've found another problem with the port.
kadmind and kdc both look for krb5.conf in /usr/local/etc, but
kpasswdd and kstash look for it in /etc. ?This can be fixed with a
symlink, but I feel like that's not the best solution. ?Ultimately,
all the heimdal utilities and daemons should be looking in the same
location for krb5.conf, correct?
I don't see any flags for kstash or kpasswdd to change where they look
for krb5.conf.
I'm going to go back and compile it from source again and see if there
is another configure flag that is missing from the port.
I've attached a patch for this problem. Please review it and make
sure this is the right way to fix the problem.
--- Makefile.old 2012-05-27 13:53:01.132516965 -0400
+++ Makefile 2012-05-27 13:54:13.928517659 -0400
@@ -7,7 +7,7 @@
PORTNAME=heimdal
PORTVERSION= 1.5.2
-PORTREVISION=2
+PORTREVISION=3
CATEGORIES= security ipv6
MASTER_SITES=http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
@@ -39,7 +39,8 @@
CONFIGURE_ARGS+= --with-libintl=${LOCALBASE} \
--with-readline=${DESTDIR}/usr \
--enable-pthread-support \
- --with-hdbdir=/var/db/${PORTNAME}
+ --with-hdbdir=/var/db/${PORTNAME} \
+ --sysconfdir=${LOCALBASE}/etc
MAKE_ENV+= INSTALL_CATPAGES=no
You want to use PREFIX instead of LOCALBASE for sysconfdir.
PREFIX is where the port will install into, LOCALBASE is where the
dependencies will be looked for. It's almost always the case that PREFIX
is the same as LOCALBASE but we should support them being different.
Otherwise the patch looks sane to me. Awaiting Joerg's input before I
commit. Thanks again!
-- WXS
___
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: Heimdal 1.5.2 problem
On Fri, May 25, 2012 at 12:21:54PM -0400, Robert Simmons wrote: On Thu, May 24, 2012 at 8:38 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 06:29:20PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 5:14 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 03:08:31PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote: As the person who committed this update I will take responsibility for seeing this through. Would you mind opening a PR with this patch and CC both myself and the maintainer so it can be properly tracked. I will work with both of you to make sure it is addressed. I got some good feedback about the patch. ?I was missing a \. ?Also, it was noted that I shouldn't make changes to the default settings in this patch since it is meant to correct a problem. ?I removed the change to default. I'm not opposed to removing the change to the default, but it does cause another problem. See below. Perhaps the different default is not the best solution. ?Maybe there should be a message that at least one backend is needed for the port to function, but none have been selected by default? If a backend is required the port should refuse to build if no backend is selected. This is pretty easy to do, just check for at least one of the backends. I have no idea if multiple backends can be supported so you may or may not want to also check for that. I may have been too hasty. ?I've thought of a situation where one would want to build the port with no backend at all. ?If one wanted to use the tools in the port to administrate a remote install of Heimdal, they may want to build it without a backend. My initial thoughts were only for installing the port as a Heimdal server, and with the --with-berkeley-db=no problem fixed it does not wrongly find the version of BDB in the base OS. ?With this fix, the port can function with no backends selected. ?It just won't be able to function in a server capacity. I am also not an expert in Heimdal, I just installed it from source via its own instructions and compared that with what the FreeBSD port was doing. ?I'd wait for the maintainer to make changes to the default behavior for the above reason. This all sounds perfectly reasonable to me. :) If I'm understanding you correctly the patch[1] in ports/168214 is the correct one to commit. The only change I would make is not bumping PORTREVISION since the option is off by default. Sounds like the only thing left to do is wait for maintainer comment on the PR and commit accordingly. Sounds good. One question: what do you mean by PORTREVISION being off by default? There is no need to bump PORTREVISION because the option which you are changing is off by default so there's no need to force a rebuild of it on the package cluster since your changes are going to have no effect there. For those that have the option to on, it hasn't built properly for them yet so bumping is going to have no effect either. -- WXS ___ 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: Heimdal 1.5.2 problem
On Fri, May 25, 2012 at 01:20:46PM -0400, Robert Simmons wrote: On Fri, May 25, 2012 at 12:56 PM, Wesley Shields w...@freebsd.org wrote: On Fri, May 25, 2012 at 12:21:54PM -0400, Robert Simmons wrote: On Thu, May 24, 2012 at 8:38 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 06:29:20PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 5:14 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 03:08:31PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote: As the person who committed this update I will take responsibility for seeing this through. Would you mind opening a PR with this patch and CC both myself and the maintainer so it can be properly tracked. I will work with both of you to make sure it is addressed. I got some good feedback about the patch. ?I was missing a \. ?Also, it was noted that I shouldn't make changes to the default settings in this patch since it is meant to correct a problem. ?I removed the change to default. I'm not opposed to removing the change to the default, but it does cause another problem. See below. Perhaps the different default is not the best solution. ?Maybe there should be a message that at least one backend is needed for the port to function, but none have been selected by default? If a backend is required the port should refuse to build if no backend is selected. This is pretty easy to do, just check for at least one of the backends. I have no idea if multiple backends can be supported so you may or may not want to also check for that. I may have been too hasty. ?I've thought of a situation where one would want to build the port with no backend at all. ?If one wanted to use the tools in the port to administrate a remote install of Heimdal, they may want to build it without a backend. My initial thoughts were only for installing the port as a Heimdal server, and with the --with-berkeley-db=no problem fixed it does not wrongly find the version of BDB in the base OS. ?With this fix, the port can function with no backends selected. ?It just won't be able to function in a server capacity. I am also not an expert in Heimdal, I just installed it from source via its own instructions and compared that with what the FreeBSD port was doing. ?I'd wait for the maintainer to make changes to the default behavior for the above reason. This all sounds perfectly reasonable to me. :) If I'm understanding you correctly the patch[1] in ports/168214 is the correct one to commit. The only change I would make is not bumping PORTREVISION since the option is off by default. Sounds like the only thing left to do is wait for maintainer comment on the PR and commit accordingly. Sounds good. ?One question: what do you mean by PORTREVISION being off by default? There is no need to bump PORTREVISION because the option which you are changing is off by default so there's no need to force a rebuild of it on the package cluster since your changes are going to have no effect there. For those that have the option to on, it hasn't built properly for them yet so bumping is going to have no effect either. I understand what you're saying. However, my change would actually change the package cluster. Because those packages were built with --without-berkeley-db rather than --with-berkeley-db=no the old packages were built with broken BDB support by accident. By fixing this, the default package is actually going to be different than the one built before this change. I would recommend bumping PORTREVISION because of this. That makes sense. Thanks for the clarification. I will be awaiting maintainer approval or timeout then. -- WXS ___ 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: Heimdal 1.5.2 problem
On Tue, May 22, 2012 at 03:08:31PM -0400, Robert Simmons wrote:
On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote:
As the person who committed this update I will take responsibility for
seeing this through. Would you mind opening a PR with this patch and CC
both myself and the maintainer so it can be properly tracked. I will
work with both of you to make sure it is addressed.
I got some good feedback about the patch. I was missing a \. Also,
it was noted that I shouldn't make changes to the default settings in
this patch since it is meant to correct a problem. I removed the
change to default.
I'm not opposed to removing the change to the default, but it does cause
another problem. See below.
Perhaps the different default is not the best solution. Maybe there
should be a message that at least one backend is needed for the port
to function, but none have been selected by default?
If a backend is required the port should refuse to build if no backend
is selected. This is pretty easy to do, just check for at least one of
the backends. I have no idea if multiple backends can be supported so
you may or may not want to also check for that.
If it does require a backend then the port should default to one of
them. If we don't pick one as a default then we get no package with the
changes you are suggesting above (the IGNORE line I put in place will
always happen on the package cluster).
I'm attaching an updated version of your patch to this email that flips
BDB on by default and does the check to make sure at least one backend
is selected. If you feel it's sufficent we can get it in the PR so it is
properly tracked.
I have attached the updated patch, and I've opened a PR here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168214
Thank you for opening a PR. All too often things can fall through the
mailing list cracks, and if it's in a PR we can at least have a record
of it. I see eadler@ has grabbed your PR. As I said earlier, I'm willing
to step up and commit this (pending maintainer approval or timeout).
-- WXS
Index: Makefile
===
RCS file: /home/ncvs/ports/security/heimdal/Makefile,v
retrieving revision 1.94
diff -u -r1.94 Makefile
--- Makefile 20 May 2012 00:08:19 - 1.94
+++ Makefile 22 May 2012 20:45:56 -
@@ -7,13 +7,12 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES= security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
ftp://ftp.pdc.kth.se/pub/heimdal/src/ \
- ftp://ftp.sunet.se/pub/unix/admin/mirror-pdc/heimdal/src/ \
- ftp://ftp.ayamura.org/pub/heimdal/
+ ftp://ftp.sunet.se/pub/unix/admin/mirror-pdc/heimdal/src/
MAINTAINER= joerg.p...@frm2.tum.de
COMMENT= A popular BSD-licensed implementation of Kerberos 5
@@ -22,7 +21,7 @@
OPTIONS= IPV6 Enable IPV6 supporton \
KCM Enable Kerberos Credentials Manager on \
- BDB Enable BerkeleyDB KDC backend support off \
+ BDB Enable BerkeleyDB KDC backend support on \
SQLITE Enable SQLite KDC backend support off \
LDAP Enable OpenLDAP KDC backend support off \
PKINIT Enable PK-INIT support on \
@@ -48,6 +47,10 @@
.include bsd.port.pre.mk
+.if !defined(WITH_BDB) !defined(WITH_SQLITE) !defined(WITH_LDAP)
+IGNORE= Need a backend.
+.endif
+
.if ${ARCH} == amd64
CFLAGS+= -fPIC
.endif
@@ -77,10 +80,10 @@
CFLAGS+= -I${BDB_INCLUDE_DIR}
CPPFLAGS+= -I${BDB_INCLUDE_DIR}
LDFLAGS+= -L${BDB_LIB_DIR}
-CONFIGURE_ARGS+= --with-berkeley-db=${LOCALBASE}
-# --with-berkeley-db-include=${BDB_INCLUDE_DIR}
+CONFIGURE_ARGS+= --with-berkeley-db=${LOCALBASE} \
+ --with-berkeley-db-include=${BDB_INCLUDE_DIR}
.else
-CONFIGURE_ARGS+= --without-berkeley-db
+CONFIGURE_ARGS+= --with-berkeley-db=no
.endif
.if defined(WITH_SQLITE)
___
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: FreeBSD Port: samba34-3.4.14
On Tue, Apr 10, 2012 at 11:35:46PM +0400, Ruslan Mahmatkhanov wrote: Completely offtopic, but we have a nice unauthenticated remote root here: http://www.samba.org/samba/security/CVE-2012-1182 It looks like the ports have just been updated. Please let the update mirror out and then update quickly! This one is particularly nasty. -- WXS ___ 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: post-deinstall target is invalid
On Fri, Mar 30, 2012 at 09:14:02PM -0700, Jason Helfman wrote: On Thu, Mar 29, 2012 at 01:40:16PM -0700, Jason Helfman wrote: On Thu, Mar 29, 2012 at 09:47:27PM +0200, Gabor Kovesdan thus spake: On 2012.03.29. 20:49, Jason Helfman wrote: I will work on a effort, as well, to get some supporting documentation into the Porter's Handbook. Jason, thanks for this cleanup work. Have you checked if there is any portlint check for this? It would also be very valuable. Gabor Your welcome, and thanks. I did consider it, however it was also noted to me that portlint shouldn't take the place of poor port coding. That doesn't mean it can't be done, but I also tend to agree with this. Perhaps adding logic to bpm would be a good way to wrap it up, as well. I'm not sure we should add anything to bpm. It's a legitimate name of a custom target which maintainers can use if they want. We should be vigilant of code which assumes it will be called though, but there's nothing wrong with it being a custom target that the maintainer wants for one reason or another. -- WXS I don't completely disagree, however the target is never used, and in all cases it merely performed the actions that were already being done in a pkg-deinstall script, or the action wasn't done due to an assumption that the target was valid. My comment was about adding code to bsd.port.mk. Removing the dead code that was already in the tree was the right thing to do, thank you. -- WXS ___ 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: FAQ on PORTREVISION bump?
On Fri, Mar 30, 2012 at 07:02:43AM +1100, Peter Jeremy wrote: On 2012-Mar-28 20:52:13 +, Philip M. Gollucci pgollu...@gmail.com wrote: Absolutely, b/c we maintain PORTREVISION for pointyhat not the end users This is completely backwards. The Project exists for end-users and end users need a way to determine when there's been a change to a port that needs them to re-install that port. Pointyhat provides automated testing facilities as a way to improve the quality of FreeBSD because not all committers are sufficiently careful. If PORTREVISION cannot adequately serve both end users pointyhat, then the ports system needs an additional, new flag to trigger pointyhat. I think Philip was wrong in his statement. PORTREVISION exists for the reason of telling the ports infrastructure (which pointyhat and the users use) of updates. End users and pointyhat use it constantly. -- WXS ___ 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: post-deinstall target is invalid
On Thu, Mar 29, 2012 at 01:40:16PM -0700, Jason Helfman wrote: On Thu, Mar 29, 2012 at 09:47:27PM +0200, Gabor Kovesdan thus spake: On 2012.03.29. 20:49, Jason Helfman wrote: I will work on a effort, as well, to get some supporting documentation into the Porter's Handbook. Jason, thanks for this cleanup work. Have you checked if there is any portlint check for this? It would also be very valuable. Gabor Your welcome, and thanks. I did consider it, however it was also noted to me that portlint shouldn't take the place of poor port coding. That doesn't mean it can't be done, but I also tend to agree with this. Perhaps adding logic to bpm would be a good way to wrap it up, as well. I'm not sure we should add anything to bpm. It's a legitimate name of a custom target which maintainers can use if they want. We should be vigilant of code which assumes it will be called though, but there's nothing wrong with it being a custom target that the maintainer wants for one reason or another. -- WXS ___ 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: Where are conventions like -devel ports documented?
On Sun, Mar 25, 2012 at 11:24:59PM +0300, Gerald Pfeifer wrote: Perhaps I am missing the obvious and will be rewarded with embarrassement, but where are conventions like the use and naming of -devel ports described? I would have expected this to be covered in http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html but -- it is not. (If this is an omission, can someone more closely involved than I have been so far donate a paragraph or two?) Gerald PS: I am thinking to split the existing emulators/wine port into two, the regular one (tracking releases of Wine) and a -devel port that tracks the bi-weekly snapshots that will lead to the next release in a year or two. Somehow I would prefer something like wine-stable / wine instead of wine / wine-devel, but the latter is more in line with how we are doing things, right? Correct, the latter is how things are done. I think of it this way: as a user of wine I want the wine port/package to give me the best working version while wine-devel to give me a development version, for whatever development version means. It is clear to me that I'm getting something not as well tested as the latest release. -- WXS ___ 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: p0f v3
On Sun, Mar 18, 2012 at 09:17:53PM +0100, Kurt Jaeger wrote: Hi! http://www.freebsd.org/cgi/query-pr.cgi?pr=166224 It still has an issue with the pkg-plist and I would appreciate hints on what's wrong. You replaced in Makefile: PORTDOCS= COPYING CREDITS ChangeLog KNOWN_BUGS README TODO win-memleak.txt With in pkg-plist: share/doc/p0f/COPYING The PORTDOCS variable respects NOPORTDOCS and does all the automatic pkg-plist stuff. Ah, thanks! I submitted a fixed pkg-plist to the PR. I just committed an update, which used your PR as a basis. I also took maintainer of it but if you would like it please let me know. Thanks for you work on this! -- WXS ___ 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: update on /usr/ports/UPDATING entry 20110928
On Mon, Mar 05, 2012 at 10:37:29AM -0500, Robert Huff wrote: Is there documentation of the current state of this issue? It should be properly fixed. Should is the keyword here. If you're having specific problems please share. -- WXS ___ 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: On the usage of ${FILE}
On Thu, Mar 01, 2012 at 12:38:01PM +, Chris Rees wrote:
On 1 Mar 2012 11:26, Matthew Seaman matt...@freebsd.org wrote:
Dear all,
bsd.commands.mk has the following:
FILE?= /usr/bin/file
which is unfortunate, given that ${FILE} is used in several thousand
ports, generally as a loop control variable for iterating through a list
of files. In fact, I can only find about 8 places where the file(1)
program is intended.
This obvious conflict of meanings seems pretty undesirable to me. Am I
missing something? Is there any reason to keep the status quo rather
than changing the bsd.commands.mk variable to FILE_CMD and making the
corresponding changes in those 8 places?
Cheers,
Matthew
I think that the loop control variables should be renamed to lower case.
Except more of them in uppercase are bound to be added in the future,
despite the best warnings not to do so.
-- WXS
___
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: FreeBSD Port: git-1.7.9.1
On Sat, Feb 18, 2012 at 04:29:32PM -0800, Douglas Thrift wrote: Hello, It looks like the update to git-1.7.9.1 missed updating distinfo. Fixed, sorry about that. -- WXS ___ 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: Sudo security advisory
On Mon, Jan 30, 2012 at 10:56:44AM -0500, Mike Tancsa wrote: Hi, http://www.gratisoft.us/sudo/alerts/sudo_debug.html From the advisory, Successful exploitation of the bug will allow a user to run arbitrary commands as root. Exploitation of the bug does *not* require that the attacker be listed in the sudoers file. As such, we strongly suggest that affected sites upgrade from affected sudo versions as soon as possible. I was aware of this last night but was not planning on touching a computer until I'm officially off vacation tomorrow. However, I think I have enough time today to get the updated version in the tree along with a VuXML entry. Update your ports tree later tonight and hopefully it will be in there. -- WXS ___ 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: Sudo security advisory
On Mon, Jan 30, 2012 at 10:56:44AM -0500, Mike Tancsa wrote: Hi, http://www.gratisoft.us/sudo/alerts/sudo_debug.html From the advisory, Successful exploitation of the bug will allow a user to run arbitrary commands as root. Exploitation of the bug does *not* require that the attacker be listed in the sudoers file. As such, we strongly suggest that affected sites upgrade from affected sudo versions as soon as possible. Turns out my son is taking a longer than usual nap, which gave me enough time to get the update in the tree and a VuXML entry in for it. Please wait for them to mirror out. If you have any untrusted users you really should update quickly. If there are any problems please let me know. -- WXS ___ 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: Encoding question
On Thu, Jan 19, 2012 at 08:43:14AM -0900, rfl...@acsalaska.net wrote: Hi, I'm trying to compile a C++ software on FreeBSD. While compiling, this error shows up: error: stray '\357' in program error: stray '\273' in program error: stray '\277' in program This file is reported (by file[1]) to be UTF-8 Unicode (with BOM) C program text, with CRLF line terminators while the rest of the files in the package are ASCII C program text, with CRLF line terminators. While I can convert the file with iconv -c -f utf-8 -t ascii file new_file in the post extract stage, I wonder if there is a more suitable way for achieving the same thing. Also I would like to avoid this software from depending on iconv. You have three options: - have it fixed upstream; - post process on extract like above; - post process releases and roll your own tarball which you host yourself. Be careful doing this third one. Often times (but not always) upstream locations use mirrors to make sure the distfile is always available. If you roll your own, just to fix something which can be so easily patched, and you don't provide similar mirror functionality then you are introducing a single point of failure we should try to avoid. Not to mention you're now going to have to do extra work everytime there is a new release. Either fix it upstream or patch it. -- WXS ___ 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
CFT: sudo 1.8.4b5 update
I've got a patch to update sudo to the latest 1.8.4 beta (b5) available at [1]. There's lots of changes in this release and I want to give people who run more complex sudo installs than I do a chance to test it out. I'd appreciate people running this update and reporting back with either success or failure stories, so I feel better about eventually committing the update once it is out of beta. [1]: http://people.freebsd.org/~wxs/sudo-beta.diff -- WXS ___ 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: CFT: sudo 1.8.4b5 update
On Wed, Jan 18, 2012 at 10:28:33AM -0500, Wesley Shields wrote: I've got a patch to update sudo to the latest 1.8.4 beta (b5) available at [1]. There's lots of changes in this release and I want to give people who run more complex sudo installs than I do a chance to test it out. I'd appreciate people running this update and reporting back with either success or failure stories, so I feel better about eventually committing the update once it is out of beta. [1]: http://people.freebsd.org/~wxs/sudo-beta.diff I forgot to mention that the changes are all documented at: http://www.sudo.ws/sudo/devel.html#1.8.4b5 Please at least take a look through there if you run an even moderately complex sudo environment. -- WXS ___ 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: FW: p0f3 release candidate
On Fri, Jan 13, 2012 at 12:49:02AM -0500, Jason Hellenthal wrote: Ports maintainers and other ideals might be interested in the following. It purely needs more eyes at this point. If anyone has anything to update this port please let me know. If I don't get anything I'll just write the update myself soon(TM). -- WXS ___ 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: USE_GCC and CC=clang
On Mon, Jan 09, 2012 at 06:22:58PM +, b. f. wrote: I'm trying to fix a port which absolutely will not build with clang, since clang does not support the gcc extension used by this port. I set USE_GCC=4.2+, which is the lowest version of GCC which will work, but it doesn't properly override CC=clang. wxs at ack spamdyke % env CC=clang make test-gcc | grep -E ^(CC|USE_GCC) USE_GCC=4.2+ CC=clang - CXX=c++ - CPP=cpp - CFLAGS=-O2 -pipe -fno-strict-aliasing wxs at ack spamdyke % This problem only arises if the base compiler is gcc 4.2.x and USE_GCC=4.2+. Otherwise CC will be set to the appropriate gcc compiler. Since Gerald (who maintains ports/Mk/bsd.gcc.mk) is trying to retire lang/gcc42 anyway, it is not a good idea to set USE_GCC=4.2+ in a port. Thanks for the pointer. I understand this is probably an acceptable behavior, since if the user sets CC=clang they are explicitly asking to build with clang. However, in the case of a port known to not work with clang, and more importantly not able to be fixed, I was hoping there was a knob I could set that would forcible override any compiler related environment variables which may be set. I didn't find one, so I came up with this quick (and poorly tested) patch to do so. The problem is due to a slight flaw in the implementation of the USE_GCC=4.2+ case, which will be obviated soon by the removal of this case. If in the meantime a change is made to bsd.gcc.mk, it should address this flaw directly -- by setting CC=gcc explicitly where needed, instead of relying upon the default setting of CC. Another knob is unnecessary. Note that changes to bsd.gcc.mk, good or bad, won't address the cases where a user sets CC on the command-line via make CC= ..., or adds it to MAKE_ARGS, or sets CC in the environment, and then calls make with -e or -E CC. So the right thing to do is to add something like: .if !empty(CC:M*clang*) IGNORE= : clang cannot be used to build this port .endif to the port Makefile, after the inclusion of bsd.port.options.mk or bsd.port.pre.mk (since a user may have set CC in Makefile.local, Makefile.inc, etc). Or, better yet, to patch the port so that it can be built with clang (which may have to be done anyway...). I was hoping to not have to set IGNORE if using clang. I'm also not really interested in patching the port, since it's more about structural changes than a simple fixes. I guess I'll set the IGNORE line if using clang for now. No point in wasting cycles on a port which won't compile for a long time, if ever. -- WXS ___ 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
USE_GCC and CC=clang
I'm trying to fix a port which absolutely will not build with clang,
since clang does not support the gcc extension used by this port. I set
USE_GCC=4.2+, which is the lowest version of GCC which will work, but it
doesn't properly override CC=clang.
wxs@ack spamdyke % env CC=clang make test-gcc | grep -E ^(CC|USE_GCC)
USE_GCC=4.2+
CC=clang - CXX=c++ - CPP=cpp - CFLAGS=-O2 -pipe -fno-strict-aliasing
wxs@ack spamdyke %
I understand this is probably an acceptable behavior, since if the user
sets CC=clang they are explicitly asking to build with clang. However,
in the case of a port known to not work with clang, and more importantly
not able to be fixed, I was hoping there was a knob I could set that
would forcible override any compiler related environment variables which
may be set. I didn't find one, so I came up with this quick (and poorly
tested) patch to do so.
The patch allows ports to set GCC_REQUIRED=yes which will forcible
override the environment variables. Maybe it makes sense to spit out a
warning message saying I know you asked me to use clang, but this port
is known to be broken with clang, and will never be fixed so I'm
altering your choice.
Here's the output with the patch applied:
wxs@ack spamdyke % env CC=clang make test-gcc | grep -E ^(CC|USE_GCC)
USE_GCC=4.2+
CC=gcc42 - CXX=g++42 - CPP=cpp42 - CFLAGS=-O2 -pipe
-Wl,-rpath=/usr/local/lib/gcc42 -fno-strict-aliasing
wxs@ack spamdyke %
-- WXS
Index: bsd.gcc.mk
===
RCS file: /ncvs/ports/Mk/bsd.gcc.mk,v
retrieving revision 1.62
diff -u -r1.62 bsd.gcc.mk
--- bsd.gcc.mk 12 Nov 2011 22:03:55 - 1.62
+++ bsd.gcc.mk 9 Jan 2012 01:58:55 -
@@ -181,7 +181,7 @@
# dependencies, CC, CXX, CPP, and flags.
.for v in ${GCCVERSIONS}
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
-. if ${OSVERSION} ${_GCCVERSION_${v}_L} || ${OSVERSION} ${_GCCVERSION_${v}_R}
+. if ${OSVERSION} ${_GCCVERSION_${v}_L} || ${OSVERSION} ${_GCCVERSION_${v}_R} || defined(GCC_REQUIRED)
V:= ${_GCCVERSION_${v}_V:S/.//}
_GCC_BUILD_DEPENDS:= gcc${V}
_GCC_PORT_DEPENDS:= gcc${V}
___
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: Patch for net-mgmt/p0f
On Fri, Jan 06, 2012 at 04:12:19PM -, Clayton Milos wrote: Hi guys I found that p0f doesn't work with the pflog interface. A bit of searching and this patch turned up: http://desync.com/~bw/patch-p0f.c With it applied instead of the default patch it works. It looks like the default patch has a few wrong line numbers in it and is missing the first part of the patch. Please could somebody commit the new patch. The patch needs to include sys/queue.h before including net/if_pflog.h, at least on my -CURRENT system. I'm testing things now and will commit if it all looks good. -- WXS ___ 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: Patch for net-mgmt/p0f
On Fri, Jan 06, 2012 at 04:12:19PM -, Clayton Milos wrote: Hi guys I found that p0f doesn't work with the pflog interface. A bit of searching and this patch turned up: http://desync.com/~bw/patch-p0f.c With it applied instead of the default patch it works. It looks like the default patch has a few wrong line numbers in it and is missing the first part of the patch. Please could somebody commit the new patch. These kinds of requests are better filled out as a PR so that they don't get lost in the daily shuffle of this list. For now I will take a look at that patch and see about getting it committed. -- WXS ___ 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: More nitpicks from the department of redundancy department...
On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote: On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler li...@eitanadler.com wrote: On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: PORT_DBDIR?= /var/db/ports is the default setting in bsd.ports.mk -- the following ports redefine it to exactly the same value: [ snip ] Thanks for the report - I'll handle these. Sorry for the empty promise. Something came up and I won't have the time to look at these :( - maybe someone else can take them up Hi Matthew! If you could please file these in a PR and CC me I will try and work through all of these. -- WXS ___ 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: More nitpicks from the department of redundancy department...
On Tue, Nov 22, 2011 at 03:44:47PM +, Matthew Seaman wrote: On 22/11/2011 13:29, Wesley Shields wrote: On Mon, Nov 21, 2011 at 12:42:59AM -0500, Eitan Adler wrote: On Sun, Nov 20, 2011 at 10:18 AM, Eitan Adler li...@eitanadler.com wrote: On Sun, Nov 20, 2011 at 4:45 AM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: PORT_DBDIR?= /var/db/ports is the default setting in bsd.ports.mk -- the following ports redefine it to exactly the same value: [ snip ] Thanks for the report - I'll handle these. Sorry for the empty promise. Something came up and I won't have the time to look at these :( - maybe someone else can take them up Hi Matthew! If you could please file these in a PR and CC me I will try and work through all of these. Done: http://www.freebsd.org/cgi/query-pr.cgi?pr=162754 Thank you! I will try and clean all this up, but as I'm sure you're aware we are coming up on a holiday in the states so my time is limited for the next few days. I will look at this as time permits though! -- WXS ___ 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: gstat collision between sysutils/coreutils and base gstat
On Mon, Oct 31, 2011 at 05:43:23PM +, Chris Rees wrote: On 31 October 2011 15:18, Wesley Shields w...@freebsd.org wrote: On Mon, Oct 31, 2011 at 09:21:26AM +, Chris Rees wrote: Hey all, Traditionally we've tended to use the 'g' prefix for GNU utilities; gmake, gtar etc, but apparently with stat that is a problem [1], due to the different gstat utility in base. I'm reluctant to simply rename the coreutils to gnu- prefixes, because that would upset quite a lot of things! We either need to: 1) Rename to coreutils to gnu- like most of the rest of the non-GNU world and deal with the breakage (!) 2) Make gstat an OPTION, off by default 3) Be horribly inconsistent and rename gstat to gnustat I don't know if 3 is as horribly inconsistent as you think: misc/gnuls installs the GNU version of ls as gnuls. Which would then introduce another conflict; coreutils installs gls :( Would anyone yell too much if I _just_ changed gstat to gnustat? It could be a little 'quirk'... Just rename it. It solves a conflict and is just one of those little quirks about porting lots of software. ;) -- WXS ___ 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: gstat collision between sysutils/coreutils and base gstat
On Mon, Oct 31, 2011 at 09:21:26AM +, Chris Rees wrote: Hey all, Traditionally we've tended to use the 'g' prefix for GNU utilities; gmake, gtar etc, but apparently with stat that is a problem [1], due to the different gstat utility in base. I'm reluctant to simply rename the coreutils to gnu- prefixes, because that would upset quite a lot of things! We either need to: 1) Rename to coreutils to gnu- like most of the rest of the non-GNU world and deal with the breakage (!) 2) Make gstat an OPTION, off by default 3) Be horribly inconsistent and rename gstat to gnustat I don't know if 3 is as horribly inconsistent as you think: misc/gnuls installs the GNU version of ls as gnuls. -- WXS ___ 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: ports/162049: The Ports tree lacks a framework to restart services
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
Hi folks,
As crees@ suggested, I'm sending an email to ports@ about this.
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent. As mentioned in the PR:
I agree inconsistency is a problem that could be addressed, but I don't
particularly agree with some of your statements.
- If I upgrade Apache, MySQL or PostgreSQL, it does not restart the
service, meaning it won't use the freshly installed daemon. This has
potential security issues.
I'd prefer that no services are started or stopped automatically, unless
absolutely necessary for the upgrade.
- If I upgrade Dovecot, it shuts it down during the upgrade, but won't
restart it. This means that I have to watch portmaster to complete and
must not forget to restart Dovecot afterwards.
Unless it is absolutely necessary to stop and restart dovecot during an
upgrade I would like to see this removed.
My question is whether anyone has ever attempted to improve the
integration with rc-scripts? In the PR I propose something along these
lines:
We know exactly which ports install rc scripts (USE_RC_SUBR).
Why not run `/usr/local/etc/rc.d/${FOO} status' and
`/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
on the return value of the first, we can run
`/usr/local/etc/rc.d/${FOO} start' after installation.
I'm of the opinion that ports/packages should not touch running services
unless absolutely necessary.
-- WXS
___
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: What is wrong here?
On Mon, Oct 17, 2011 at 10:22:08PM +0200, Leslie Jensen wrote: 2011-10-17 22:13, Matthias Andree skrev: Am 17.10.2011 22:10, schrieb Leslie Jensen: I have a script that does portsnap fetch update pkg_version -vIL= on a Daily basis Today I got this little message about corrupted record and I would like to solve it ImageMagick-6.7.3.0_1needs updating (index has 6.7.3.1) pkg_version: corrupted record (pkgdep line without argument), ignoring pkg_version: corrupted record (pkgdep line without argument), ignoring kdemultimedia-4.6.5needs updating (index has 4.7.2) libgtop-2.28.3_1needs updating (index has 2.28.3_2) Any suggestions? It might help to run: portmaster --check-depends and the corruption is either from a file system corruption (like: hard shutdown/power blackout with enabled write caches), or from an interrupted portmaster/portupgrade/portinstall or bare-bones ports make run. ___ 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 Thanks. I have done that and I have two errors considering kdelibs-4. At the moment kdelibs-4 will not build. Because I deleted kdelibs following the instructions in UPDATING, that might cause the error. I didn't connect those two because there was no mention of port name in the error. Thanks for clarifying :-) You can find out which pkg is giving you the problems by looking for @pkgdep in /var/db/pkg/*+CONTENTS. If you find any lines with nothing after the space then that is your problem. You should just be able to rebuild that port or reinstall the package and you should be fine. -- WXS ___ 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: Ports maintrainer mode?
On Sun, Oct 16, 2011 at 11:46:01PM +1100, Alexey Golodov wrote: Looking through the ports, I see that sometimes maintrainers include in Makefile block with actions for maintrain port. There are different ways to define it (starting with MAINTRAINER_MODE in devel/git, and ends if user = $maintrainer_username) The latter strikes me as a very bad idea. Do you happen to know which ports do that? -- WXS ___ 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: git distfiles on the local mirror
On Fri, Sep 09, 2011 at 09:37:08PM +, b. f. wrote: Could someone please place the latest devel/git distfiles on the local mirrors, so that they are available while kernel.org is recovering from being hacked? The github mirror only has gzipped development tarballs, that don't work with the current ports Makefile. I was hoping that kernel.org would get their act together before I had a chance to fix this tonight. I will be updating the port to point to a couple of new locations now. -- WXS ___ 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: rawtherapee
On Tue, Aug 09, 2011 at 02:20:49PM +0200, Rainer Hurling wrote: Am 09.08.2011 12:53 (UTC+1) schrieb Oliver Heesakkers: Op dinsdag 9 augustus 2011 05:39:46 schreef ajtiM: It doesn't build still.. CMake Error at CMakeLists.txt:260 (message): hg command not found! -- Configuring incomplete, errors occurred! *** Error code 1 Stop in /usr/ports/graphics/rawtherapee. *** Error code 1 Stop in /usr/ports/graphics/rawtherapee. It requires devel/mercurial to be installed. AFAICT it's a build dependency only, so you can remove it again after the rawtherapee build completes. You are right. But why not including a BUILD_DEPENDS= in the ports makefile, then? Two things. 1. It's probably best to include the maintainer on an initial report like this. 2. Do you have files/patch-About-Linux.cmake? It was committed at 2011/08/07 21:27:31 and should be what drops the dependency on hg. -- WXS ___ 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: Which to bump for distfile location change?
On Tue, Jul 26, 2011 at 09:08:13PM +0100, Chris Rees wrote: On 26 Jul 2011 20:47, Bob Eager r...@tavi.co.uk wrote: Following a recent post to this list, I need to update a port, just to change a distfile location. It seems excessive to bump PORTREVISION, so what is the best thing to change (if any). No default package change, no portrevision bump. Leave it as is. Chris is right but I don't want to give people the impression that is the only time to bump PORTREVISION. While the default package change rule of thumb is always a good one there is more to it than just that when deciding to bump PORTREVISION or not. Here's the rough questions I go through in my head when I'm facing this kind of decision: If the default package changes, bump it. Only caveat here is if it's a minor change (say a typo in a man page or something). If it's chasing a shlib bump of another port and this port defaults to off, bump it anyways as some people may be bit by this. If it's a change to an option that defaults to off, and one can expect a reasonable number of people to benefit from it, bump it. I'm sure there are others and I'm sure some people will disagree with some of these. But those are the rough guidelines I follow. -- WXS ___ 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: How to best run a script post installation _and_ deinstallation?
On Sun, May 22, 2011 at 11:01:50PM +0200, Gerald Pfeifer wrote:
Trying to implement the final steps in addressing PR 155568: bsd.gcc.mk:
Fixing dependency not to pick ccache stubs which I have been working on
with Emanuel, I'd like to invoke a script after a port/package has been
installed and again after it has been deinstalled.
The naive approach below works for installation:
Index: Makefile
===
post-install:
---
post-install: ccache-update
181a182,186
post-deinstall ccache-update:
@if [ -x ${PREFIX}/bin/ccache-update-links ]; then \
${PREFIX}/bin/ccache-update-links -v; \
fi
It does not cover de-installation which raises two questions:
1. Why don't we have a post-deinstall target?
2. How is the task best accomplished?
Are these what you are looking for:
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-install.html
http://www.freebsd.org/doc/en/books/porters-handbook/pkg-deinstall.html
-- WXS
___
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: patch for force fetch
On Mon, May 16, 2011 at 10:22:23PM +0300, Andriy Gapon wrote: on 16/05/2011 19:53 Eitan Adler said the following: I've run into this myself and simply done the manual rm -f. This looks like a great addition. what about make distclean ? Can you please elaborate? If you mean that I could just run 'make distclean', then my answer is why should I. I.e. if the ports infrastructure already knows that there is something wrong with a local copy of a distfile (wrong size, wrong checksum), then it should just do the right thing and not annoy me to run some cleanup action. While I certainly don't disagree with you here, I do want to point out that keeping old distfiles around when the checksum is different has saved my butt more than once. It's very useful to not delete the old distfile. On more than one occasion I've had to diff old and new distfiles to figure out why the checksums are different. If ports just deleted the old one I may not be able to get it back. I do like the idea of ports DTRT and just fetch the new file, but can we have it move the old one to some place safe instead of delete it? -- WXS ___ 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: saving a few ports from death
On Wed, Apr 27, 2011 at 04:03:58PM -0400, Mikhail T. wrote: On 27.04.2011 14:16, Eitan Adler wrote: Then bapt@ marked the ports*deprecated* which does not mean deleted. It was a warning that people who were interested should step up and take up the work. If after N amount of time no one does so they will be individually deleted. The ports I listed -- db2 and apache13* family -- are/were not broken. What work are you talking about? Yet, mandree deleted db2 on April 12th and dougb is anxious to delete apache13 as well instead of simply disowning it... apache13 is EOL upstream. We should not have ports for EOL software. I don't care if it works perfectly fine and someone wants to hand-roll patches back to it. If upstream says it's dead, who are we to keep it alive? -- WXS ___ 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: on boot starting jails hangs
On Fri, Apr 22, 2011 at 09:32:13AM -0700, Mickey Harvey wrote: When I boot up my host rc hangs at starting jails: indefinitely. If i Control^C during the hang boot continues as usual so I login ,run jls and the jail appears to have started correctly. I can login to the jail as usual using jexec 1 sh. I'm using 8.2-RELEASE i386 on a VirtualBox VM. My rc is set up as follows: ifconfig_em0=DHCP ifconfig_em0_alias0=10.0.2.16 netmask 255.255.255.255 jail_enable=YES jail_list=www jail_www_rootdir=/usr/local/jails/www jail_www_hostname=www jail_www_ip=10.0.2.16 jail_www_devfs_enable=YES It's most likely something inside the jail failing to start properly. My money is on sendmail trying to get a reverse lookup completed. Try disabling sendmail entirely and see if the jail starts properly. -- WXS ___ 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: Error when updating sudo
On Mon, Apr 11, 2011 at 08:03:34AM +0200, Leslie Jensen wrote: I get the error below when updating/installing sudo everything in the file /usr/local/etc/sudoers near line 97 is commented out! It's actually not commented out, as Charlie mentioned. I committed an update to address this for default installs, but if you have that laying around your existing sudoers file you will have to address it by removing that line or creating the directory yourself. -- WXS ___ 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: Error when updating sudo
On Mon, Apr 11, 2011 at 08:57:45AM -0400, Wesley Shields wrote: On Mon, Apr 11, 2011 at 08:03:34AM +0200, Leslie Jensen wrote: I get the error below when updating/installing sudo everything in the file /usr/local/etc/sudoers near line 97 is commented out! It's actually not commented out, as Charlie mentioned. I committed an update to address this for default installs, but if you have that laying around your existing sudoers file you will have to address it by removing that line or creating the directory yourself. On second thought, this is a glaring POLA problem. My desire to simplify the port is not worth the churn this is causing to users. I will be reverting this portion of the update shortly and removing the UPDATING entry as it will no longer be valid. My apologies for the churn. -- WXS ___ 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: FreeBSD Port: vim-lite-7.3.121
On Wed, Apr 06, 2011 at 10:33:53AM -0700, David O'Brien wrote: On Wed, Mar 23, 2011 at 11:13:45PM -0400, Niek Dekker wrote: Using the syntax on command in .vimrc. When opening a php file in Vim, a lot of errors are being displayed. The errors are caused by line continuation characters in /usr/local/share/vim/vim73/syntax/php.vim. Hi I really don't know anything about PHP. Can you point out the line number (and line content) of an example of this in /usr/local/share/vim/vim73/syntax/php.vim? I found /usr/local/share/doc/antiword/antiword.php on my system and am assuming it is an OK example of a PHP file. Syntax colouring works OK with Vim 7.3.121 (non-lite). Have you tried the non-lite build? Somehow, in FreeBSD Vim does not seem to recognize the line continuation character and complains about it, resulting in errors when opening a syntax file containing these characters. What is the solution to this, if you know any? So that I know what to look at, can you also send the error messages you are seeing (and any required file(s) to reproduce the issue? I get a similar problem when editing python files. To trigger it all I have to do is have syntax on in my .vimrc, then edit a file with the .py extension (it can be a totally new file). The first few errors, and there are more, are: Error detected while processing /usr/local/share/vim/vim73/syntax/python.vim: line 86: E475: Invalid argument: pythonFunction line 87: E10: \ should be followed by /, ? or line 93: E475: Invalid argument: pythonString line 94: E10: \ should be followed by /, ? or line 95: E10: \ should be followed by /, ? or line 96: -- WXS ___ 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: Fwd: Deprecation campaign
On Thu, Apr 07, 2011 at 11:40:31AM +0100, Chris Rees wrote: On 06/04/2011, Ruslan Mahmatkhanov cvs-...@yandex.ru wrote: 06.04.2011 18:30, Wesley Shields ?: I went ahead and committed these changes. Please let me know if you would like to be maintainer or not. Thanks a lot! I'm afraid that i'm not a proper person to maintain such a port, because my c-foo is very little. Maybe Michel Talon, that initiated this port resurrection and that sent build patches would be interested in maintaining this port. I could look after it in the absence of others' interest. I just committed this. -- WXS ___ 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: FreeBSD Port: vim-lite-7.3.121
On Thu, Apr 07, 2011 at 08:27:58AM -0500, Matthew D. Fuller wrote: On Thu, Apr 07, 2011 at 08:57:12AM -0400 I heard the voice of Wesley Shields, and lo! it spake thus: I get a similar problem when editing python files. For a data point, I edit .php files all day long, and .py files occasionally (with both full vim and vim-lite), and have never seen this with either... Are you using syntax highlighting? -- WXS ___ 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: Fwd: Deprecation campaign
On Wed, Apr 06, 2011 at 08:56:27AM +0400, Ruslan Mahmatkhanov wrote: Hi! So can please anybody commit this? This patch unbreaks devel/ucpp. Build patches are from Michel Talon ta...@lpthe.jussieu.fr. (Should be applied with -p0) I will take care of this. As this port is currently unmaintained, do you want to take the maintainer role? -- WXS ___ 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: Fwd: Deprecation campaign
On Wed, Apr 06, 2011 at 08:56:27AM +0400, Ruslan Mahmatkhanov wrote: Hi! So can please anybody commit this? This patch unbreaks devel/ucpp. Build patches are from Michel Talon ta...@lpthe.jussieu.fr. (Should be applied with -p0) Actually, on second thought I'm hesitant to commit this. There is a distinfo change without a version bump. I will try to hunt down the old distfile and figure out what has changed between that and the new one in recorded in your patch. -- WXS ___ 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: Fwd: Deprecation campaign
On Wed, Apr 06, 2011 at 10:17:53AM -0400, Wesley Shields wrote: On Wed, Apr 06, 2011 at 08:56:27AM +0400, Ruslan Mahmatkhanov wrote: Hi! So can please anybody commit this? This patch unbreaks devel/ucpp. Build patches are from Michel Talon ta...@lpthe.jussieu.fr. (Should be applied with -p0) Actually, on second thought I'm hesitant to commit this. There is a distinfo change without a version bump. I will try to hunt down the old distfile and figure out what has changed between that and the new one in recorded in your patch. I reviewed the changes between the old distfile and the new one and they are build related and one change to the code, which was harmless. I went ahead and committed these changes. Please let me know if you would like to be maintainer or not. -- WXS ___ 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: portmaster comments
On Mon, Mar 14, 2011 at 05:08:26AM -0400, J. Hellenthal wrote:
On Sun, 13 Mar 2011 20:45, dougb@ wrote:
On 3/13/2011 5:35 PM, Peter Jeremy wrote:
Hi Doug,
I'd like to raise a couple of nits with portmaster (primarily a wish
for more configurability):
1) In v3.0, you added code to nice(1) all make(1) invocations. In some
cases, the default niceness does not suit me (in particular, I'd often
prefer '0' to '10'). Would it be possible to add an option to control
the priority?
2) In v3.6, you added a find $WRKDIRPREFIX ... to the cleanup. For
various reasons, I have _lots_ of unrelated stuff under that tree and
so the find(1) takes an unacceptably long time to run. It would be
nice to restrict that search to $WRKDIRPREFIX${.CURDIR} and have an
option to disable it completely.
Neither is likely to happen. :) I may however remove 1, it didn't really
help much, if at all. As for 2, my suggestion is to have a WRKDIRPREFIX for
development stuff, and a different one for portmaster. It's pretty easy to
do
with a make.conf knob searching for whether UPGRADE_TOOL is set to
This doesn't have any effect for,
/usr/ports/lang/python/Makefile:31:.if defined(USE_PORTMASTER)
Does it ?
It has an effect on how the upgrade-site-packages target works. I wrote
it specifically because I didn't want to have to install portupgrade
just to get the upgrade-site-packages target to work.
It would be real nice if these things were somewhat in sync for their
intended use.
I don't know what you mean by this.
Ill BCC python@ for the heads up on ``UPGRADE_TOOL'' I would prefer this
personally over USE_ vars. But is this common among portupgrade and
portmaster ? If not can something be done in tree to decipher it into what
is supposed to be set to avoid confusion ?
I don't know what you mean by this.
I think you might be confusing two different issues. The USE_PORTMASTER
knob was put in place specifically for the upgrade-site-packages target,
which is not something called during the normal build process by any
upgrading tool. I'm not sure how using UPGRADE_TOOL will help this at
all.
-- WXS
___
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: Superfluous dependencies
On Sat, Mar 12, 2011 at 02:12:34PM -0800, Charlie Kester wrote: On Sat 12 Mar 2011 at 13:53:07 PST Mark Linimon wrote: On Thu, Mar 10, 2011 at 10:28:40AM +0100, Hans Ottevanger wrote: If anybody is interested I could consolidate my results and post a few patches. I would like to see them. This is the kind of really-dull-but-necessary work that we need to have people work on to fight the creeping dependencies :-) A few minutes ago, I was answering a post on the forums, in which a user expressed surprise (and outrage) that the phpmyadmin port was installing libX11 and similar things on his server. By installing it myself and then using pkg_tree -v to examine the dependencies, I was able to narrow it down to two of the port's options that were ON by default. I'm not aware of any tool that will display a similar dependency tree for a port *before* it is installed. make all-depends-list creates exactly what it suggests, a list, and doesn't show any of the hierarchical info that is needed to answer questions like the one I was working on. If there is such a tool, I'd love to hear about it. Otherwise, it might be an interesting and useful project for someone to take a stab at. There is always the missing target to show you what is currently missing if a particular port were to be installed with whatever options you have chosen. I use this target regularly, because I'm often too lazy to read OPTIONS and other knobs. -- WXS ___ 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: sysutils/dolly breaks cvs
On Fri, Mar 11, 2011 at 11:35:02AM -0500, Aryeh Friedman wrote: This is from a repo that was updated 15 mins ago: flosoft-stable# cvs co ports/sysutils/dolly | more cvs checkout: Updating ports/sysutils/dolly cvs checkout: Updating ports/sysutils/dolly/files cvs checkout: Updating ports/sysutils/dolly/files/ cvs checkout: Updating ports/sysutils/dolly/files// cvs checkout: Updating ports/sysutils/dolly/files/// cvs checkout: Updating ports/sysutils/dolly/files cvs checkout: Updating ports/sysutils/dolly/files/ Please don't top-post. You have something weird going on. There has not been a commit there in years. This is most likely a local problem. Can you find a way to force your repo to update that again? -- WXS ___ 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: ports/155355: mail/mailman: XXS vulnerability affecting Mailman 2.1.14 and prior
I'm going to be traveling from 3/8 through 3/9. If anyone can get to this before I return please feel free to commit as necessary. ___ 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: shells/zsh links to devel/ncurses
On Thu, Mar 03, 2011 at 03:21:17PM +0800, Alexander Kojevnikov wrote: If devel/ncurses is installed, shells/zsh links to libncursesw from that port but doesn't add it as a dependency. To reproduce: 1. Install devel/ncurses 2. (Re)install shells/zsh 3. Run: % ldd `shich zsh` libncursesw.so.6.0 = /usr/local/lib/libncursesw.so.6.0 (0x8008f4000) ... 4. pkg_delete devel/ncurses 5. zsh cannot start: % ldd `which zsh` libncursesw.so.6.0 = not found (0x0) ... Re-building shells/zsh fixes it: % ldd `which zsh` libncursesw.so.8 = /lib/libncursesw.so.8 (0x8008f5000) ... To sum it up, shells/zsh should either not link to devel/ncurses or list it as a dependency if it does. Thanks for bringing this up. I noticed it a while ago but forgot to mail the maintainer. While we are on the subject of silent dependencies, mail/mutt-devel links with ncurses silently too. I've attached the maintainer of mutt-devel to this mail so he can hopefully work up a patch. -- WXS ___ 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: pr 155131
On Mon, Feb 28, 2011 at 04:26:12PM -0500, Dean Freeman wrote: the distinfo portion of my udiff should be removed from the patch i supplied earlier for the DAQ port. Apparently the tarball got garbled slightly on Sourceforge earlier and that's why the file size was off. We re-uploaded and the file size and sha256 hash are back to being normal. Just to be clear, the patch at [1] is the one you wish to be applied? If so I do want to bring to your attention that a BUILD_DEPENDS addition does not warrant a PORTREVISION bump as it doesn't affect the package or is a feature that requires people to rebuild. I'll go ahead and work on getting this in the tree shortly... -- WXS [1]: http://www.freebsd.org/cgi/query-pr.cgi?prp=155131-3-diffn=/patch-3.diff ___ 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: /usr/local/bin/extract
On Wed, Feb 23, 2011 at 10:16:46PM +1300, Atom Smasher wrote: conflict between: audio/csound security/outguess # pkg_info -W /usr/local/bin/extract pkg_info: both csound-5.12.1_3 and outguess-0.2 claim to have installed /usr/local/bin/extract I'll take care of this. I want to give the maintainer of audio/csound a chance to speak up in case he has something in the works that this might conflict with (no pun intended). -- WXS ___ 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: port revision for Snort
On Fri, Feb 18, 2011 at 01:05:56PM -0500, Dean Freeman wrote: I've submitted a patch to fix two issues, including a potential segfault in HttpInspect. This change will bump the port revision to 2. I'll commit this. Two quick things for the next time you submit a PR though. 1. The patch is reversed. 2. You probably don't want to have all the unnecessary stuff in the patches to the port (? cflags.out, etc). I'll try and get this in the tree as quickly as I can. -- WXS ___ 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: TeamSpeak server port
On Tue, Feb 01, 2011 at 08:53:41PM +0100, Richard Hirner wrote: Hi, I'm trying to make a port for TeamSpeak 3. I have some questions before I can submit it. I appended it to this mail as shar: 1) There's already a teamspeak_server port for the TeamSpeak 2 server. TS2 is not widely used anymore, only available for x86 and the port is not maintained. Therefor I think that it would be better to take over this port instead of creating a new teamspeak3-server port (although TS2 and TS3 are separate products in some kind). It that OK? I see no reason to keep an old version in the tree that nobody is likely using anymore if there is a newer version out. I'd say whatever you're working on should be an update of audio/teamspeak_server to version 3. The fact that it's been unmaintained for over a year now, and the last update was 2 years ago (to the day) makes me think that as the new maintainer you can do what you want and nobody is likely to care. :) 2) Are there naming conventions? The old port is named teamspeak_server while there are other ports like mysql-server (- instead of _). Not that I'm aware of, but I'm sure someone somewhere will speak up. If it's not officially documented you're allowed to use your best judgment. 3) There are conditional DISTFILES in the port and I don't know if this is OK. This is done in other ports. See devel/git and the WITH_HTMLDOCS option which adds to DISTFILES. Just be sure to put all optional distfiles in distinfo. -- WXS ___ 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: New port needs review: net/erlyvideo
On Sun, Jan 16, 2011 at 01:45:57PM -0800, Jason Helfman wrote:
On Mon, Jan 17, 2011 at 12:22:59AM +0300, Ruslan Mahmatkhanov thus spake:
16.01.2011 23:44, Jason Helfman ??:
On Sun, Jan 16, 2011 at 08:25:18PM +0300, Ruslan Mahmatkhanov thus spake:
As you can see this patch indeed eliminates using of git, because this
part isn't really needed for erlyvideo to work.
Read this wrong. Thanks, for pointing this out.
You may wish to consider a for loop on the make install target.
Are these directories created during the install process of the package? I
didn't see these directories created outside of the Makefile.
Do you mean something like this?
DIRS=/var/lib/${PORTNAME}/movies /var/lib/${PORTNAME}/plugins \
/var/log/${PORTNAME} ${ERLYDIR} ${ETCDIR} ${WWWDIR}
.for dir in ${DIRS}
${MKDIR} ${dir}
.endfor
Yes, however are they created during a pkg_add command? Consider a recent
patch I submitted for comms/minicom.
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/153749
Directories created in Makefile process, aren't created in the packaging
process, unless you are putting the operations into a pkg-install or an
@exec operation in pkg-plist, respectively.
That is my understanding, and what I have found in fixing ports here and
there. I fixed the packaging for www/tomcat55, as well. I found that as a
port it worked fine, however package installation would fail.
Excuse me if I'm wrong but I think what Jason is getting at is empty
directories created when installing the port are not put in the package.
This is documented in the handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/plist-cleaning.html
If these directories are created so that you can install files in them
(with INSTALL_FOO macros) then Jason's suggestion is not necessary,
because the files will be registered in the package and the directories
created automatically when using the package.
Not all cases of ${MKDIR} in a port are special. :)
-- WXS
___
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: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Fri, Jan 07, 2011 at 12:04:20PM -0800, Doug Barton wrote: On 01/07/2011 11:57, Olli Hauer wrote: Maybe something like the apache22 rc script will work. Apache22 can start more than one instance and it is easy to control all or only a single instance with the apache rc script. And the best, it works without links With respect to those involved, the apache scripts are a good example of what I don't want more examples of. I agree. It's extra complexity that can be solved with a simple solution like the one Doug proposed. -- WXS ___ 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: jpeg build problem
On Thu, Jan 06, 2011 at 12:00:03AM +0100, Radek Krej?a wrote: Hi, I have problem with build of jpeg from ports - latest ports, csup 10 minutes ago. = Attempting to fetch from http://www.ijg.org/files/. jpegsrc.v8b.tar.gz === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Extracting for jpeg-8_3 = SHA256 Checksum OK for jpeg8b/jpegsrc.v8b.tar.gz. = SHA256 Checksum OK for jpeg8b/jpegexiforient.c. = SHA256 Checksum OK for jpeg8b/exifautotran.txt. cp: /usr/ports/distfiles//jpegexiforient.c: No such file or directory *** Error code 1 Wait for r1.159 of graphics/jpeg/Makefile to make it to the mirrors. Should be fixed with that. -- WXS ___ 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: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Wed, Jan 05, 2011 at 01:14:26AM -0800, Douglas Thrift wrote: Hello, Since ISC dhcpd 4.1 now supports DHCPv6, but a single instance of the daemon can't do both IPv4 DHCP and DHCPv6, it would be nice if the rc.d script from the port could be configured to start the daemon twice. Has anyone thought about this at all or implemented anything? I'm certainly open to the idea if you can get it to work cleanly. I'm not entirely sure it's going to be an easy solution though. It might be a better question for the rc list (to which I am not subscribed so you may want to keep me on the CC). -- WXS ___ 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: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Thu, Jan 06, 2011 at 04:49:36PM -0800, Doug Barton wrote:
On 01/05/2011 01:14, Douglas Thrift wrote:
Hello,
Since ISC dhcpd 4.1 now supports DHCPv6, but a single instance of the
daemon can't do both IPv4 DHCP and DHCPv6, it would be nice if the rc.d
script from the port could be configured to start the daemon twice. Has
anyone thought about this at all or implemented anything?
I really dislike this trend that we're seeing of individual rc.d scripts
supporting running multiple versions of the same daemon, but I haven't
yet found the time to write it up for TPH. The canonical way to do this
is for the rc.d script to have multiple copies of itself, and then do
something like:
name=${0##*/}
For this example you could have the port install rc.d/dhcpd by default
(or whatever the name is, not suggesting a change), and an option to
also install dhcpd_v6 (perhaps as a symlink). This would make it easy to
clean up as the additional copy of the script should also be in the plist.
I'm not a big fan of the same script running multiple versions of the
same daemon either. I do think the symlink and code above is a good
solution though.
The other reason I haven't squawked more about this is that for services
that would like to be able to run an arbitrary number of the same daemon
the servicename_N_{flags|pidfile|etc} method works, and eliminates the
problem of leaving behind multiple numbers of the script after port
deinstall. But for something like this where we're discussing a fixed
(and small) number of copies it's better to have this done the right way.
I didn't know servicename_N_foo existed. I still like the symlink
approach. I can certainly add that to the port in the future.
Thanks!
-- WXS
___
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: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Thu, Jan 06, 2011 at 10:01:23PM -0500, Wesley Shields wrote:
On Thu, Jan 06, 2011 at 04:49:36PM -0800, Doug Barton wrote:
On 01/05/2011 01:14, Douglas Thrift wrote:
Hello,
Since ISC dhcpd 4.1 now supports DHCPv6, but a single instance of the
daemon can't do both IPv4 DHCP and DHCPv6, it would be nice if the rc.d
script from the port could be configured to start the daemon twice. Has
anyone thought about this at all or implemented anything?
I really dislike this trend that we're seeing of individual rc.d scripts
supporting running multiple versions of the same daemon, but I haven't
yet found the time to write it up for TPH. The canonical way to do this
is for the rc.d script to have multiple copies of itself, and then do
something like:
name=${0##*/}
For this example you could have the port install rc.d/dhcpd by default
(or whatever the name is, not suggesting a change), and an option to
also install dhcpd_v6 (perhaps as a symlink). This would make it easy to
clean up as the additional copy of the script should also be in the plist.
I'm not a big fan of the same script running multiple versions of the
same daemon either. I do think the symlink and code above is a good
solution though.
The other reason I haven't squawked more about this is that for services
that would like to be able to run an arbitrary number of the same daemon
the servicename_N_{flags|pidfile|etc} method works, and eliminates the
problem of leaving behind multiple numbers of the script after port
deinstall. But for something like this where we're discussing a fixed
(and small) number of copies it's better to have this done the right way.
I didn't know servicename_N_foo existed. I still like the symlink
approach. I can certainly add that to the port in the future.
Forgot to mention... Could you please submit a PR for this so that it
does not end up lost?
-- WXS
___
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: Web feeds for UPDATING files [and commits too]
On Wed, Nov 03, 2010 at 11:00:22PM +0100, Lapo Luchini wrote: Alexander Kojevnikov wrote: The site now features Atom feeds for the following files: * ports/UPDATING * head/UPDATING * stable/7/UPDATING * stable/8/UPDATING Hope you find the feeds useful. Useful indeed! Also, this is probably a nice thread to point out that a commit log feed exists. It was made by ale@ many months ago but (as far as GoogleReader says) I think I'm the only user so far; these are the FeedBurner-cached entries (to avoid hitting ale@'s ADSL too much): src/ http://feeds.feedburner.com/FreeBSD-6-src http://feeds.feedburner.com/FreeBSD-7-src http://feeds.feedburner.com/FreeBSD-8-src http://feeds.feedburner.com/FreeBSD-HEAD-src ports/ http://feeds.feedburner.com/FreeBSD-ports There is also freshports.org which has an RSS feed apparently. It also has fancy graphs and the ability to get notified when commits are made to ports you choose. -- WXS ___ 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: New tools for committers and maintainers
On Tue, Oct 19, 2010 at 08:12:23PM +0300, Ion-Mihai Tetcu wrote: Hi, A new tool was just committed to ports, ports-mgmt/distilator. It will check for you each of the MASTER_SITES of the port you call it with. The link I was given when ehaupt@ ran it included URLs in pkg-descr too. It even found some of those that were no longer valid for me. I wold like to recommend that all the maintainers and commiters run it just before submitting/committing. It's fast enough (it doesn't download the DISTFILES, just checks each (MASTER_SITED, DISTFILES) combination and gives you a nice list of what file is (not) where. For speed, you will want to use perl-threaded. And yes, it's on it's way to be integrated into QAT and PortsMon, so there's no reason not to use it yourselves, to prevent receiving those nasty BotMails. A BIG thanks to ehaupt@ for writing it! Agreed, thank you eha...@! -- WXS ___ 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: New tools for committers and maintainers
On Tue, Oct 19, 2010 at 08:41:28PM +0200, Emanuel Haupt wrote: Wesley Shields w...@freebsd.org wrote: On Tue, Oct 19, 2010 at 08:12:23PM +0300, Ion-Mihai Tetcu wrote: Hi, A new tool was just committed to ports, ports-mgmt/distilator. It will check for you each of the MASTER_SITES of the port you call it with. The link I was given when ehaupt@ ran it included URLs in pkg-descr too. It even found some of those that were no longer valid for me. ports-mgmt/distilator can do that too. It's basically code extracted from the version that creates the distilator report [1] and put into a library. Thanks! I didn't mean to imply that distilator could not do that. I just wanted to point out that it does more than just MASTER_SITE checking. In any case, thank you again for making it. It will be quite useful in cleaning up the little things that can go stale over time. -- WXS ___ 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: FreeBSD Port: spamdyke-4.0.10
On Sun, Oct 10, 2010 at 05:35:13PM -0700, Peter Kieser wrote: Hello, I am no longer in a position to test spamdyke fixes, please remove me as maintainer. -Peter Done. On 10/10/2010 5:25 PM, BC wrote: Hi Peter - There has been a new version of spamdyke out since July. The new version fixes an important bug with TLS. Could you update the port, please? At this point the port is unmaintained and if you want to see it updated it will require a patch from you or someone else. -- WXS ___ 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: Entries in /usr/ports/UPDATING
On Thu, Oct 14, 2010 at 11:59:53AM +, Helmut Schneider wrote: Hi, a repocopy for typo3 was done recently and I would like to suggest users to change origin if they want to stay at the 4.3 branch. I guess UPDATING is the right place to do so but who does so, who changes/decides that a hint in UPDATING might be useful? Committers make the changes but if a maintainer thinks it's important enough he/she can note that in the PR and the committer should honor that. If you have a blurb you would like to see in UPDATING for this please let me know and I will commit it. -- WXS ___ 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: net/isc-dhcp41-client, dhclient-script and DHCPv6
On Wed, Sep 22, 2010 at 06:20:07PM +1000, Lawrence Stewart wrote: Hi Wesley, I've been playing with DHCPv6 and in doing so, ran into an apparent problem with the net/isc-dhcp41-client port. I've switched to using the script provided by upstream. Thanks for noticing this and sorry for the delay in response. -- WXS ___ 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: Idea: entries in UPDATING for each release
On Tue, Sep 28, 2010 at 12:07:08PM -0600, Warren Block wrote: Right now, people who install ports from a -release CD and then start upgrading don't have a clear marker for how far back to go in UPDATING. A simple entry would be enough: 20100703: AFFECTS: AUTHOR: FreeBSD 8.1-RELEASE Not sure what AFFECTS should say. There might be other useful information that could be included in the note. Comments? I'm certainly not opposed to the idea but what exactly do we use for a date? When the tree is tagged? When the release media is finalized and published to mirrors? What about tag slippage? Do we account for that? If the only goal is to get a rough idea of when a release was cut then either when the tree is tagged or when the media is pushed out to mirrors is probably sufficient. -- WXS ___ 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: [HEADS-UP] graphics/claraocr out of date.
On Sat, Sep 25, 2010 at 07:54:42PM -0400, jhell wrote: On 09/25/2010 19:01, Wesley Shields wrote: On Sat, Sep 25, 2010 at 02:49:02PM -0400, jhell wrote: Going through some of my old OCR uses, I could the subject listed port out of date and the URL referenced in the pkg-descr is non functional. The new website for this port is: http://www.claraocr.org/en/download.html And seems to be last updated as of: 11/18/09 which is the v1.1 release. [HEADS-UP] like subject lines are usually reserved for when something major is going to happen (like an update of gnome or kde). -- WXS So sue me. I'm just trying to educate you so that you can adhere to the social norms of the community in the future. -- WXS ___ 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: [HEADS-UP] graphics/claraocr out of date.
On Sat, Sep 25, 2010 at 02:49:02PM -0400, jhell wrote: Going through some of my old OCR uses, I could the subject listed port out of date and the URL referenced in the pkg-descr is non functional. The new website for this port is: http://www.claraocr.org/en/download.html And seems to be last updated as of: 11/18/09 which is the v1.1 release. [HEADS-UP] like subject lines are usually reserved for when something major is going to happen (like an update of gnome or kde). -- WXS ___ 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: update bacula-server 5.0.2 - 5.0.3, Undefined symbol ASN1_INTEGER_it
On Tue, Sep 21, 2010 at 09:48:50PM +0200, olli hauer wrote: On 2010-09-21 02:24, Wesley Shields wrote: On Mon, Sep 20, 2010 at 07:39:58PM +0200, olli hauer wrote: On 2010-09-19 08:20, Per olof Ljungmark wrote: FreeBSD 7.3-STABLE #0: Tue Sep 7 22:46:59 CEST 2010 p...@candyman.i.inter-sonic.com:/usr/obj/usr/src/sys/GENERIC amd64 Portupgrade of bacula-server 5.0.2 - 5.0.3 Starting bacula_fd. /libexec/ld-elf.so.1: /usr/local/lib/libbac.so.5: Undefined symbol ASN1_INTEGER_it Starting bacula_sd. Starting bacula_dir. If one deselects OPENSSL and recompile bacula-fd will start without complaints. Is this a known issue with 5.0.3? No, can you provide me some more details. First make sure if you have both bacula-server and bacula-client installed on the same machine both are build with(out) ssl support. Both ports install libs with the same name to the same place, but if the client is build/installed first with SSL support, and then the server without SSL support you can see exact the described issue. Shouldn't the two ports register CONFLICTS then, thus making it (normally) impossible for both to be installed on the same host? -- WXS At the moment I'm thinking about to install the client part within the server part as one port and mark bacula-client/bacula-server as conflict. Should probably rename bacula-server to just bacula then as it will include both the client and the server. And have separate ports for server and client if that's all the user wants. Conflicts will have to be set accordingly. Until now all my backup servers from different vendors doing the same and I see no reason to not backup the backup-server. However this will only solve the shared lib problem in those two ports and there are some other slaves. For the SSL thing a nice way would be a shared option like a electrical cross switch for such ports, on/off for all master/slaves not independent. Maybe Dan (the maintainer) has some additional thoughts, so I set him on CC. I'll leave all this up to you all. I trust the port is in good hands between Dan and yourself. Thanks for working on it! -- WXS ___ 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: update bacula-server 5.0.2 - 5.0.3, Undefined symbol ASN1_INTEGER_it
On Tue, Sep 21, 2010 at 07:51:26PM -0400, Dan Langille wrote: On 9/21/2010 4:46 PM, Wesley Shields wrote: On Tue, Sep 21, 2010 at 09:48:50PM +0200, olli hauer wrote: On 2010-09-21 02:24, Wesley Shields wrote: On Mon, Sep 20, 2010 at 07:39:58PM +0200, olli hauer wrote: On 2010-09-19 08:20, Per olof Ljungmark wrote: FreeBSD 7.3-STABLE #0: Tue Sep 7 22:46:59 CEST 2010 p...@candyman.i.inter-sonic.com:/usr/obj/usr/src/sys/GENERIC amd64 Portupgrade of bacula-server 5.0.2 - 5.0.3 Starting bacula_fd. /libexec/ld-elf.so.1: /usr/local/lib/libbac.so.5: Undefined symbol ASN1_INTEGER_it Starting bacula_sd. Starting bacula_dir. If one deselects OPENSSL and recompile bacula-fd will start without complaints. Is this a known issue with 5.0.3? No, can you provide me some more details. First make sure if you have both bacula-server and bacula-client installed on the same machine both are build with(out) ssl support. Both ports install libs with the same name to the same place, but if the client is build/installed first with SSL support, and then the server without SSL support you can see exact the described issue. Shouldn't the two ports register CONFLICTS then, thus making it (normally) impossible for both to be installed on the same host? -- WXS At the moment I'm thinking about to install the client part within the server part as one port and mark bacula-client/bacula-server as conflict. That sounds OK. Should probably rename bacula-server to just bacula then as it will include both the client and the server. And have separate ports for server and client if that's all the user wants. Conflicts will have to be set accordingly. We had bacula before Why don't we just keep it as bacula-server and add an announcement that it now installs bacula-fd by default. Because if it installs both the client and server portions (like Olli is suggesting) we should probably rename it to just bacula again. I would expect that if I installed a bacula-server port that I would get just the server portion and no client portion. -- WXS ___ 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: update bacula-server 5.0.2 - 5.0.3, Undefined symbol ASN1_INTEGER_it
On Tue, Sep 21, 2010 at 06:16:15PM -0700, Jeremy Chadwick wrote: On Tue, Sep 21, 2010 at 08:42:09PM -0400, Wesley Shields wrote: On Tue, Sep 21, 2010 at 07:51:26PM -0400, Dan Langille wrote: On 9/21/2010 4:46 PM, Wesley Shields wrote: On Tue, Sep 21, 2010 at 09:48:50PM +0200, olli hauer wrote: On 2010-09-21 02:24, Wesley Shields wrote: On Mon, Sep 20, 2010 at 07:39:58PM +0200, olli hauer wrote: On 2010-09-19 08:20, Per olof Ljungmark wrote: FreeBSD 7.3-STABLE #0: Tue Sep 7 22:46:59 CEST 2010 p...@candyman.i.inter-sonic.com:/usr/obj/usr/src/sys/GENERIC amd64 Portupgrade of bacula-server 5.0.2 - 5.0.3 Starting bacula_fd. /libexec/ld-elf.so.1: /usr/local/lib/libbac.so.5: Undefined symbol ASN1_INTEGER_it Starting bacula_sd. Starting bacula_dir. If one deselects OPENSSL and recompile bacula-fd will start without complaints. Is this a known issue with 5.0.3? No, can you provide me some more details. First make sure if you have both bacula-server and bacula-client installed on the same machine both are build with(out) ssl support. Both ports install libs with the same name to the same place, but if the client is build/installed first with SSL support, and then the server without SSL support you can see exact the described issue. Shouldn't the two ports register CONFLICTS then, thus making it (normally) impossible for both to be installed on the same host? -- WXS At the moment I'm thinking about to install the client part within the server part as one port and mark bacula-client/bacula-server as conflict. That sounds OK. Should probably rename bacula-server to just bacula then as it will include both the client and the server. And have separate ports for server and client if that's all the user wants. Conflicts will have to be set accordingly. We had bacula before Why don't we just keep it as bacula-server and add an announcement that it now installs bacula-fd by default. Because if it installs both the client and server portions (like Olli is suggesting) we should probably rename it to just bacula again. I would expect that if I installed a bacula-server port that I would get just the server portion and no client portion. For sake of comparison, this isn't how the MySQL port works. Installing mysql51-server pulls in mysql51-client. But installing mysql51-client doesn't pull in mysql51-server. I believe there are other ports which behave the same way as this. I've never liked that, but I can understand it. The concept makes sense when you consider that the server is a centralised piece of software (usually installed on one machine), and may need to run the client itself (e.g. backup itself). While other machines in the cluster are just clients (they get backed up by the server). Hope this makes sense. :-) It does make sense. I was merely stating my opinion on the matter and if Dan doesn't like it then I respect that and he should continue to maintain the port how he chooses. As I've said before, between Dan and Olli the port is in good hands and I trust them both to do whatever they think is right. -- WXS ___ 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: update bacula-server 5.0.2 - 5.0.3, Undefined symbol ASN1_INTEGER_it
On Mon, Sep 20, 2010 at 07:39:58PM +0200, olli hauer wrote: On 2010-09-19 08:20, Per olof Ljungmark wrote: FreeBSD 7.3-STABLE #0: Tue Sep 7 22:46:59 CEST 2010 p...@candyman.i.inter-sonic.com:/usr/obj/usr/src/sys/GENERIC amd64 Portupgrade of bacula-server 5.0.2 - 5.0.3 Starting bacula_fd. /libexec/ld-elf.so.1: /usr/local/lib/libbac.so.5: Undefined symbol ASN1_INTEGER_it Starting bacula_sd. Starting bacula_dir. If one deselects OPENSSL and recompile bacula-fd will start without complaints. Is this a known issue with 5.0.3? No, can you provide me some more details. First make sure if you have both bacula-server and bacula-client installed on the same machine both are build with(out) ssl support. Both ports install libs with the same name to the same place, but if the client is build/installed first with SSL support, and then the server without SSL support you can see exact the described issue. Shouldn't the two ports register CONFLICTS then, thus making it (normally) impossible for both to be installed on the same host? -- WXS ___ 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: editors/vim installs to /
On Fri, Sep 17, 2010 at 09:21:46PM +0200, David DEMELIER wrote:
2010/9/17 jhell jh...@dataix.net:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/150649
There's that PR which is probably related but it's a bit light on useful
information.
No,
${PREFIX} is the good variable to specify the installation directory,
of course if you set this the port will probably install its files in
the user-defined ${PREFIX}.
I'm writing the rewrite of the port to update vim to 7.3 and with a
real OPTIONS framework and remove the stupid WITH_VIM_OPTIONS KNOB
that doesn't work. The problem is that David doesn't like clean things
and I think he won't commit it because it won't be enough complicated.
While I agree that editors/vim could use the changes you're discussing,
do you really think such a comment is needed? Attacks like that are not
necessary. Let your code speak for itself.
-- WXS
___
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: editors/vim installs to /
On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
I reverted to the previous Makefile just to get something working before
I leave. I did want to point out that the cleanup (at least for me) was
not that hard. /man and /share were left behind along with a handful of
files in /bin that shouldn't have been there. Once I had reverted and
installed vim I was able to use something like
pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
To find the files which were in /bin that should not have been there.
Not all of them were there in my case but the cleanup was easy. Just
delete /man and /share and the handful of files in /bin.
I still don't know what the real fix for this is but hopefully someone
is working on it. ;)
-- WXS
___
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: editors/vim installs to /
On Fri, Sep 17, 2010 at 07:18:09PM -0400, jhell wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/17/2010 17:19, Wesley Shields wrote:
On Fri, Sep 17, 2010 at 01:49:37PM -0400, jhell wrote:
After a force upgrade of vim that had failed unfortunately not
registering the files it installed already I found out that it is
installing to / ~! ugh.
Why is ${PREFIX} being used and not ${LOCALBASE} ???
I reverted to the previous Makefile just to get something working before
I leave. I did want to point out that the cleanup (at least for me) was
not that hard. /man and /share were left behind along with a handful of
files in /bin that shouldn't have been there. Once I had reverted and
installed vim I was able to use something like
pkg_info -L -x vim | fgrep /usr/local/bin | sed -e 's|/usr/local||'
To find the files which were in /bin that should not have been there.
Not all of them were there in my case but the cleanup was easy. Just
delete /man and /share and the handful of files in /bin.
I still don't know what the real fix for this is but hopefully someone
is working on it. ;)
-- WXS
Attached is the exact patch that fixes this. The two effected areas are
post pre-configure. My best guess on this lays on the REINPLACE_CMD in
pre-configure but I could be wrong.
You may want to also revert the MAKE_JOBS_SAFE too.
-- WXS
___
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: editors/vim installs to /
On Fri, Sep 17, 2010 at 03:51:42PM -0700, Rob Farmer wrote: On Fri, Sep 17, 2010 at 13:54, Wesley Shields w...@freebsd.org wrote: While I agree that editors/vim could use the changes you're discussing, do you really think such a comment is needed? Attacks like that are not necessary. Let your code speak for itself. -- WXS This port has major issues and numerous polite requests (including with patches) to fix them have been summarily ignored or rejected. So don't act surprised when people start to get annoyed by the situation. I'm not surprised. I'm pointing out that attacks like that are not going to further the cause of getting the port the care you think it deserves. Unfortunately I don't know what the answer is beyond polite requests and patches to fix the problems as you see them. I do know that attacks are not the answer and are in fact harmful to achieving a goal. -- WXS ___ 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: editors/vim installs to /
On Sat, Sep 18, 2010 at 03:52:17AM +0400, Anonymous wrote: jhell jh...@dataix.net writes: After a force upgrade of vim that had failed unfortunately not registering the files it installed already I found out that it is installing to / ~! ugh. Does the following diff fixes it? It does allow the port to pass my tinderbox tests. Hopefully obrien@ will commit it shortly. -- WXS ___ 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: [ports/net/isc-dhcp*] Don't stop DHCP related daemons
On Sat, Sep 11, 2010 at 05:33:59PM +0300, Ion-Mihai Tetcu wrote: On Sat, 11 Sep 2010 22:29:02 +0900 Norikatsu Shigemura n...@freebsd.org wrote: Hi wxs and jpaetzel. I noticed that dhcpd server stoped after portupgrade, sometimes. It's a painful accident on my network. Because I didn't notice some troubles:-(. Why do you stop the daemons? Is it really absolutely necessary to stop a service before it's files go away? SEE ALSO: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html#AEN5402 $ grep forcestop isc-dhcp*/pkg-plist isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh forcestop 2/dev/null || true isc-dhcp31-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay forcestop 2/dev/null || true isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd.sh forcestop 2/dev/null || true isc-dhcp31-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay.sh forcestop 2/dev/null || true isc-dhcp41-relay/pkg-plist:@unexec %D/etc/rc.d/isc-dhcrelay forcestop 2/dev/null || true isc-dhcp41-server/pkg-plist:@unexec %D/etc/rc.d/isc-dhcpd forcestop 2/dev/null || true I want to remove these lines in pkg-plist. This 'stop the service before we install' seems to be a new fashion, usually unneeded/disruptive. IMO this should only happen when it's really needed, and with some big warning printed. This is there because that is how the old ISC ports were done. I'm not a fan of this at all. If it doesn't break upgrades I'm going to remove it. Ports/packages should keep their grubby little hands off my services. ;) -- WXS ___ 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
