Flow-tools and Flow-tools-ng - Flow-Capture - supposed to be memory leak - patch
Dear Sir/Madam,
Please, publish in the official ports build patch system, the patch
bellow for the problem
that manifest itself only on the amd64 platform, and it is one and the
same for both the
flow-tools and flow-tools-ng - i.e. flow-capture eats all of the RAM
and SWAP of the
machine, until killed by the kernel.
The problem itself is in the built-in mechanism in the flow-tools,(
instead of using the
macros in the FreeBSD,) to read msg structures and control-information
from recvmsg
calls.
I've managed to patch myself the source, but my patch is ugly one, and
consist of
just commenting out the usage of the hack-in tools to read msg structures of the
original source (but worked).
The patch I am pasting here is from the author, and concerns the same problem.
It looks much better than mine, and If I've new about it, I would be
spending 4 days
debugging;-(
Best Regards,
Z.Vladov
Mark R. mark at inetu.net
Tue Oct 7 14:53:09 EDT 2008
Previous message: [Flow-tools] ftpdu_seq_check lost flows
Next message: [Flow-tools] limit for number of filter elements
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Paul,
Upon further investigation, it appears as if there is an alignment issue in
'struct msgip' inside of 'struct ftnet'. I've looked at some other code, and
there appear to be a handful of useful CMSG_* macros to help deal with this.
RFC 2292 details them.
The attached patch works cleanly on my system and fixes the issue at hand.
Hopefully it doesn't break other platforms. It's there for anybody who is
interested.
Thanks,
Mark
On Tue, 7 Oct 2008, Mark R. wrote:
Paul,
This is where I'm picking up the garbage data:
ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr
The kernel is GENERIC plus IPFW. Nothing terribly oddball. I'm wondering if
this is a variable type issue somewhere. Running a 32bit build on amd64 and
the same box doesn't exhibit this issue.
If you care to look into this, I can provide access to the box in question.
If not, I'll might eventually figure it out.
I'm not at the point of caring about a memory leak. When I get there, I can
run it through valgrind.
Thanks,
Mark
On Tue, 7 Oct 2008, Paul P Komkoff Jr wrote:
Replying to Mark R.:
Are there any known issues with flow-tools on 64-bit platforms? I'm
trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd
behavior with flow-capture and flow-fanout.
There is at least one known memory leak that only happens on 64-bit
FreeBSD, that I still haven't fixed (mainly because it requires to set up
FreeBSD somewhere).
This one that you telling here is new. And it's serious, I wonder why
nobody else seeing it. Maybe your kernel is broken?
Or maybe it's ipv4-over-ipv6 issue?
I don't have access to freebsd system to verify how recvmsg works
there, sorry.
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key - my pgp key
This message represents the official view of the voices in my head
___
Flow-tools mailing list
flow-tools at splintered.net
http://mailman.splintered.net/mailman/listinfo/flow-tools
-- next part --
--- lib/ftlib.h-orig2008-03-09 13:09:01.0 +
+++ lib/ftlib.h 2008-10-07 17:41:11.0 +
@@ -459,11 +459,16 @@
int fd; /* fd receiving flows on */
struct mymsghdr msg;/* recvmsg data */
struct {
-struct cmsghdr hdr;
#ifdef IP_RECVDSTADDR
+#ifdef CMSG_DATA
+char cbuf[CMSG_SPACE(sizeof(struct sockaddr_storage))];
+#else
+struct cmsghdr hdr;
struct in_addr ip;
+#endif /* CMSG_DATA */
#else
#ifdef IP_PKTINFO
+struct cmsghdr hdr;
struct in_pktinfo pktinfo;
#endif /* else */
#endif /* IP RECVDSTADDR */
--- src/flow-fanout.c-orig 2008-01-27 20:48:55.0 +
+++ src/flow-fanout.c 2008-10-07 17:42:33.0 +
@@ -124,6 +124,11 @@
int i, n, detach, one, ret, offset, hdr_len;
int npeers, tx_delay;
int stat_interval, stat_next, src_ip_spoof;
+#ifdef IP_RECVDSTADDR
+#ifdef CMSG_DATA
+ struct cmsghdr *cmsg;
+#endif
+#endif
time_startup = time((time_t)0L);
@@ -625,12 +630,24 @@
#ifdef IP_RECVDSTADDR
/* got destination IP back? */
+#ifdef CMSG_DATA
+ for (cmsg = CMSG_FIRSTHDR(ftnet.msg); cmsg != NULL;
+ cmsg = CMSG_NXTHDR(ftnet.msg, cmsg)) {
+ if (cmsg-cmsg_level == IPPROTO_IP
+ cmsg-cmsg_type == IP_RECVDSTADDR) {
+ memcpy(ftnet.loc_addr.sin_addr.s_addr,
+ CMSG_DATA(cmsg), sizeof(struct in_addr));
+ break;
+ }
+ }
+#else
if ((ftnet.msgip.hdr.cmsg_level == IPPROTO_IP)
(ftnet.msgip.hdr.cmsg_type == IP_RECVDSTADDR)) {
ftnet.loc_addr.sin_addr.s_addr = ftnet.msgip.ip.s_addr;
} else {
Dovecot port requires mention in UPDATING
The configuration file of dovecot 1.1 will most likely not work for Dovecot 1.2 Shouldn't this be mentioned in UPDATING? See: http://wiki.dovecot.org/Upgrading/1.2 ___ 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: Dovecot port requires mention in UPDATING
On Sat, Aug 15, 2009 at 02:01:27PM +0200, Oliver Heesakkers wrote: The configuration file of dovecot 1.1 will most likely not work for Dovecot 1.2 Shouldn't this be mentioned in UPDATING? See: http://wiki.dovecot.org/Upgrading/1.2 Yes, I will get something in there now. Sorry for the noise but this was not mentioned in the PR. -- 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
portversion and pkg_version have different opinions on current versions
First off: not subscribed to this list, please make sure to Cc me or I won't see your answers! :) Oh, and I use portsnap, in crontab: 0 19 * * * portsnap -I cron update So, long story short: [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# ... How do I figure out which is correct, and which/what should I use in my crontab to check for out-of-date packages? I'm pretty new to FreeBSD (testing use since May, but I've used it briefly before), but have almost 10 years of Linux experience, mostly Gentoo, so I'm not new to *nix-like OS's, not to mention that Gentoo's portage is based on FreeBSD ports - except that it has an official interface (i.e. emerge), rather than portupgrade, portmaster, portmanager, etc. A bit of a mess in my outsider opinion. ;) I don't care overly much about having the bleeding-edge version, but I'd rather not, as I currently have, use packages with known vulnerabilities (I do know about portaudit, though, and will give that a check). For instance, I just noticed yesterday that I needed to upgrade apr, among about 6-7 other packages; the apr vulnerability had been known for a while before I updated. Regards, Thomas ___ 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: portversion and pkg_version have different opinions on current versions
In message b787d58e-9157-48e7-adf3-e8d54f8af...@exscape.org, Thomas Backman (seren...@exscape.org) wrote: First off: not subscribed to this list, please make sure to Cc me or I won't see your answers! :) Oh, and I use portsnap, in crontab: 0 19 * * * portsnap -I cron update So, long story short: [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# I do not have portversion on my system so I assume it is part of portupgrade or some other tool. I find pkg_version works fine for letting me know what needs updating after doing a CVSup. BTW you do not need to use awk in the above, e.g. pkg_version -L = will show only those ports which are not up-to-date, RTFM for details. :-) Some years ago I tried using portupgrade, but had all sorts of problems with its database getting corrupted. In desparation I tried portmaster and have been a very happy since. (Thanks Doug!). [...] I don't care overly much about having the bleeding-edge version, but I'd rather not, as I currently have, use packages with known vulnerabilities (I do know about portaudit, though, and will give that a check). For instance, I just noticed yesterday that I needed to upgrade apr, among about 6-7 other packages; the apr vulnerability had been known for a while before I updated. I think portaudit is definitely worth having installed. You can always ignore its warnings if you want to. Cheers, Nick. -- ___ 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: portversion and pkg_version have different opinions on current versions
N.J. Mann wrote: Some years ago I tried using portupgrade, but had all sorts of problems with its database getting corrupted. In desparation I tried portmaster and have been a very happy since. (Thanks Doug!). Well I don't know about the desperation part, but you're welcome in any case. :) -- This .signature sanitized for your protection ___ 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: portversion and pkg_version have different opinions on current versions
Thomas Backman wrote: First off: not subscribed to this list, please make sure to Cc me or I won't see your answers! :) Oh, and I use portsnap, in crontab: 0 19 * * * portsnap -I cron update So, long story short: [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# Off hand I'd say this looks like your pkgdb might be corrupt or out of sync, but I am far from an expert in portupgrade. ... How do I figure out which is correct, pkg_version is authoritative since by default it checks the version of what you have installed against what's in the port's Makefile. Nick was right and you can just use the following: pkg_version -L '=' and which/what should I use in my crontab to check for out-of-date packages? If you want to run it every night after portsnap runs I'd just add pkg_version -L '=' to the end of your crontab. If you want a little nicer output there is a periodic script to check package status. You could copy the lines about 400.status-pkg from /etc/defaults/periodic.conf to /etc/periodic.conf, enable it there, and then do: /etc/periodic/weekly/400.status-pkg at the end of your crontab line. I'm pretty new to FreeBSD Welcome! (testing use since May, but I've used it briefly before), but have almost 10 years of Linux experience, mostly Gentoo, so I'm not new to *nix-like OS's, not to mention that Gentoo's portage is based on FreeBSD ports - except that it has an official interface (i.e. emerge), rather than portupgrade, portmaster, portmanager, etc. A bit of a mess in my outsider opinion. ;) One person's mess is another person's freedom of choice. :) Each of those tools has its positives and negatives, and each of them has a user base that is happy with the tool. In any case, hope that answers your question and good luck! Doug -- This .signature sanitized for your protection ___ 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: portversion and pkg_version have different opinions on current versions
Thomas Backman wrote: [...] [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# [...] As was mentioned, you can use pkg_version -L =, or you can compare it with INDEX.db instead of ports tree: pkg_version -IL =. This is significantly faster. pkg_version -L = Usr: 7.286s Krnl: 3.984s Totl: 0:31.77s pkg_version -IL = Usr: 0.195s Krnl: 0.015s Totl: 0:00.21s And if you want to know the version of newer (available) port, you can use pkg_version -vIL = It gives you something like this: png-1.2.35 needs updating (index has 1.2.38) postfix-2.5.6,1 needs updating (index has 2.6.3,1) vim-lite-7.2.209needs updating (index has 7.2.239) Miroslav Lachman ___ 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: portversion and pkg_version have different opinions on current versions
On Aug 15, 2009, at 20:31, Miroslav Lachman wrote: Thomas Backman wrote: [...] [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# [...] As was mentioned, you can use pkg_version -L =, or you can compare it with INDEX.db instead of ports tree: pkg_version -IL =. This is significantly faster. pkg_version -L = Usr: 7.286s Krnl: 3.984s Totl: 0:31.77s pkg_version -IL = Usr: 0.195s Krnl: 0.015s Totl: 0:00.21s And if you want to know the version of newer (available) port, you can use pkg_version -vIL = It gives you something like this: png-1.2.35 needs updating (index has 1.2.38) postfix-2.5.6,1 needs updating (index has 2.6.3,1) vim-lite-7.2.209needs updating (index has 7.2.239) Miroslav Lachman Thanks, guys! However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update /dev/null [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL= [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL= curl-7.19.5_1 needs updating (index has 7.19.6) dnsmasq-2.49_1 needs updating (index has 2.49_2) ezm3-1.1_2 needs updating (index has 1.2_1) libtool-1.5.26 ! Comparison failed postfix-2.6.2_1,1 needs updating (index has 2.6.3,1) python26-2.6.2_1 needs updating (index has 2.6.2_2) vnstat-1.7_2 needs updating (index has 1.8) vsftpd-ssl-2.1.2 needs updating (index has 2.2.0) [r...@chaos /usr/ports/ports-mgmt]# portupgrade -a [r...@chaos /usr/ports/ports-mgmt]# ls -l /usr/ports/INDEX-* -rw-r--r-- 1 root wheel 17370624 Jul 31 19:45 /usr/ports/INDEX-5 -rw-r--r-- 1 root wheel 19813792 Aug 15 20:42 /usr/ports/INDEX-6 -rw-r--r-- 1 root wheel 19808537 Aug 15 20:42 /usr/ports/INDEX-7 -rw-r--r-- 1 root wheel 34316288 May 8 10:35 /usr/ports/INDEX-7.db -rw-r--r-- 1 root wheel 19816190 Aug 15 20:42 /usr/ports/INDEX-8 -rw-r--r-- 1 root wheel 1291821 May 30 12:06 /usr/ports/INDEX-8.bz2 -rw-r--r-- 1 root wheel 34869248 Aug 14 19:30 /usr/ports/INDEX-8.db [r...@chaos /usr/ports/ports-mgmt]# date Sat Aug 15 20:43:07 CEST 2009 [r...@chaos /usr/ports/ports-mgmt]# So... Using the index causes problems (or the opposite!). Could I be using an index for something like HEAD despite not using that ports tree? (Again, pretty new to this!) I don't know how the INDEX files work, but I do know (thank you DTrace) that INDEX-8 was the only one read during pkg_version -vIL=. Oh, and my understanding is that the INDEX-8 is fetched via portsnap? Running the fetch update took less than 20 seconds (the cron job ran about 2 hours ago, though), so I guess it cannot have been built (that does take a lot of time, yes?)? Regards, Thomas ___ 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: portversion and pkg_version have different opinions on current versions
In message 6b5b7698-ccd8-48ff-a5fb-0349d4cc1...@exscape.org, Thomas Backman (seren...@exscape.org) wrote: On Aug 15, 2009, at 20:31, Miroslav Lachman wrote: Thomas Backman wrote: [...] [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# [...] As was mentioned, you can use pkg_version -L =, or you can compare it with INDEX.db instead of ports tree: pkg_version -IL =. This is significantly faster. pkg_version -L = Usr: 7.286s Krnl: 3.984s Totl: 0:31.77s pkg_version -IL = Usr: 0.195s Krnl: 0.015s Totl: 0:00.21s And if you want to know the version of newer (available) port, you can use pkg_version -vIL = It gives you something like this: png-1.2.35 needs updating (index has 1.2.38) postfix-2.5.6,1 needs updating (index has 2.6.3,1) vim-lite-7.2.209needs updating (index has 7.2.239) Miroslav Lachman Thanks, guys! However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). [...] I am not familiar with portsnap - I use CVS (and SVN) because I like to have ports, src, doc and www locally, just in case... Be that as it may, you can always do a make index to rebuild the INDEX-* file. Cheers, Nick. -- ___ 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: portversion and pkg_version have different opinions on current versions
Thomas Backman wrote: However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). libtool-1.5.26 ! Comparison failed This is because the libtool-1.5.x port -- devel/libtool15 -- was renamed to devel/libtool22 and the port updated to libtool-1.22.x. See the 20090802 entry in /usr/ports/UPDATING for special instructions on how to deal with this. So... Using the index causes problems (or the opposite!). Could I be using an index for something like HEAD despite not using that ports tree? (Again, pretty new to this!) No -- using the INDEX shows you what the INDEX is capable of showing you, which isn't everything you need to know when using the ports. You should get in the habit of casting an eye over /usr/ports/UPDATING any time you want to do an upgrade. There is only one ports tree, and you should be using the HEAD of it no matter what OS version you're running. There aren't any OS version specific branches -- just tags to mark the point in time at which support for a particular OS version was dropped, or to mark the specific set of ports bundled with a release. HEAD is a continuously moving target -- of the order of a hundred port updates will be checked in daily largely driven by the availability of new upsteam versions. The generated INDEXes are labeled with the OS major version, out of a choice of 5, 6, 7 or 8 -- which are the only OS versions the ports system is set up to work with right now. Actually, I think 5.x support may have been dropped already. The choice of 6, 7 or 8 covers all of the supported release branches and the bleeding edge 8-CURRENT stuff. Once the release of 8.0-STABLE happens, and the bleeding edge moves to 9-CURRENT there will be an INDEX-9 generated. The reason for the difference is that certain ports are not supported on all OS versions, some have variations in their dependency lists and some have a different set of default options, so the INDEX comes out differently on the different versions. I don't know how the INDEX files work, but I do know (thank you DTrace) that INDEX-8 was the only one read during pkg_version -vIL=. Yes. You'll only use the INDEX corresponding to the major version of FreeBSD that you have installed. See portindex(5) for details of what the INDEX contains. Oh, and my understanding is that the INDEX-8 is fetched via portsnap? Running the fetch update took less than 20 seconds (the cron job ran about 2 hours ago, though), so I guess it cannot have been built (that does take a lot of time, yes?)? Yes. Building the INDEX on a fairly beefy machine takes 20min or more and thrashes disk IO while doing so. The index available for download by: # cd /usr/ports # make fetchindex should be rebuilt approximately hourly, but it isn't unknown for problems to prevent a new INDEX being available for a number of hours. I believe the INDEXes portsnap supplies are generated similarly. In fact, depending on the ports management software you use, the INDEX may be pretty much irrelevant -- portmaster(1) ignores it -- or certain discrepancies may be ignored -- portupgrade(1) uses data in the INDEX as a guide but double checks against the reality of the ports tree when working out what needs updating. If you've made any non-standard settings in /etc/make.conf such as, eg. running mysql-5.1.x instead of the default mysql-5.0.x or using apache13 or enabling LDAP or SASL functionality then you may find it worthwhile to build your own INDEX[*] as this can help avoid different bits of the system getting conflicting ideas about exactly what depends on what. Cheers, Matthew [*] Modesty prevents me from mentioning ports-mgmt/p5-FreeBSD-Portindex. -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: portversion and pkg_version have different opinions on current versions
Thomas Backman wrote: Thanks, guys! However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update /dev/null [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL= [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL= curl-7.19.5_1 needs updating (index has 7.19.6) dnsmasq-2.49_1 needs updating (index has 2.49_2) ezm3-1.1_2 needs updating (index has 1.2_1) Can you check the files in your ports tree to see if they have the older versions or the newer? You can either read the Makefiles or do this: cd /usr/ports/ftp/curl make -V PKGNAME I suspect that somehow the INDEX file and your ports tree are out of date, although my understanding was that this should not happen with portsnap. libtool-1.5.26 ! Comparison failed Read /usr/ports/UPDATING, you need to fix this. [r...@chaos /usr/ports/ports-mgmt]# ls -l /usr/ports/INDEX-* -rw-r--r-- 1 root wheel 17370624 Jul 31 19:45 /usr/ports/INDEX-5 -rw-r--r-- 1 root wheel 19813792 Aug 15 20:42 /usr/ports/INDEX-6 -rw-r--r-- 1 root wheel 19808537 Aug 15 20:42 /usr/ports/INDEX-7 -rw-r--r-- 1 root wheel 34316288 May 8 10:35 /usr/ports/INDEX-7.db -rw-r--r-- 1 root wheel 19816190 Aug 15 20:42 /usr/ports/INDEX-8 -rw-r--r-- 1 root wheel 1291821 May 30 12:06 /usr/ports/INDEX-8.bz2 -rw-r--r-- 1 root wheel 34869248 Aug 14 19:30 /usr/ports/INDEX-8.db I would 'rm /usr/ports/INDEX*' before doing your next portsnap update just to be sure. hth, Doug -- This .signature sanitized for your protection ___ 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: portversion and pkg_version have different opinions on current versions
On Sat, 15 Aug 2009 20:48:53 +0200 Thomas Backman seren...@exscape.org wrote: On Aug 15, 2009, at 20:31, Miroslav Lachman wrote: Thomas Backman wrote: [...] [r...@chaos ~]# pkgdb -aF --- Checking the package registry database [r...@chaos ~]# portversion -l '' dnsmasq ezm3 libtool python26 [r...@chaos ~]# pkg_version | awk '$2 !~ /=/' [r...@chaos ~]# portupgrade -a [r...@chaos ~]# [...] As was mentioned, you can use pkg_version -L =, or you can compare it with INDEX.db instead of ports tree: pkg_version -IL =. This is significantly faster. pkg_version -L = Usr: 7.286s Krnl: 3.984s Totl: 0:31.77s pkg_version -IL = Usr: 0.195s Krnl: 0.015s Totl: 0:00.21s And if you want to know the version of newer (available) port, you can use pkg_version -vIL = It gives you something like this: png-1.2.35 needs updating (index has 1.2.38) postfix-2.5.6,1 needs updating (index has 2.6.3,1) vim-lite-7.2.209needs updating (index has 7.2.239) Miroslav Lachman Thanks, guys! However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update /dev/null [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL= [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL= curl-7.19.5_1 needs updating (index has 7.19.6) dnsmasq-2.49_1 needs updating (index has 2.49_2) ezm3-1.1_2 needs updating (index has 1.2_1) libtool-1.5.26 ! Comparison failed postfix-2.6.2_1,1 needs updating (index has 2.6.3,1) python26-2.6.2_1 needs updating (index has 2.6.2_2) vnstat-1.7_2 needs updating (index has 1.8) vsftpd-ssl-2.1.2 needs updating (index has 2.2.0) [r...@chaos /usr/ports/ports-mgmt]# portupgrade -a [r...@chaos /usr/ports/ports-mgmt]# ls -l /usr/ports/INDEX-* -rw-r--r-- 1 root wheel 17370624 Jul 31 19:45 /usr/ports/INDEX-5 -rw-r--r-- 1 root wheel 19813792 Aug 15 20:42 /usr/ports/INDEX-6 -rw-r--r-- 1 root wheel 19808537 Aug 15 20:42 /usr/ports/INDEX-7 -rw-r--r-- 1 root wheel 34316288 May 8 10:35 /usr/ports/INDEX-7.db -rw-r--r-- 1 root wheel 19816190 Aug 15 20:42 /usr/ports/INDEX-8 -rw-r--r-- 1 root wheel 1291821 May 30 12:06 /usr/ports/INDEX-8.bz2 -rw-r--r-- 1 root wheel 34869248 Aug 14 19:30 /usr/ports/INDEX-8.db [r...@chaos /usr/ports/ports-mgmt]# date Sat Aug 15 20:43:07 CEST 2009 [r...@chaos /usr/ports/ports-mgmt]# So... Using the index causes problems (or the opposite!). Could I be using an index for something like HEAD despite not using that ports tree? (Again, pretty new to this!) I don't know how the INDEX files work, but I do know (thank you DTrace) that INDEX-8 was the only one read during pkg_version -vIL=. Oh, and my understanding is that the INDEX-8 is fetched via portsnap? Running the fetch update took less than 20 seconds (the cron job ran about 2 hours ago, though), so I guess it cannot have been built (that does take a lot of time, yes?)? Regards, Thomas Why not just add weekly_status_pkg_enable=YES to /etc/periodic.conf.local and youll be informed of packages that need updating. Best regards. -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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: portversion and pkg_version have different opinions on current versions
Jason J. Hellenthal wrote: Why not just add weekly_status_pkg_enable=YES to /etc/periodic.conf.local and youll be informed of packages that need updating. Sorry to pick on your response, but this thread is a good time to remind people of some basic mailing list etiquette: 1. Read the whole thread before you reply (the suggestion you made above was already made earlier in this thread). 2. Make sure you understand the real problem before you reply (the OP has some sort of problem with his INDEX and ports tree not matching, we've moved past just finding out what needs updating). 3. Don't speculate. If you're not 100% sure about something let someone who is more knowledgeable reply. There have been several posts in this thread that gave misleading and/or confusing information that could easily have been avoided. hth, Doug -- This .signature sanitized for your protection ___ 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: portversion and pkg_version have different opinions on current versions
On Sat, 15 Aug 2009 13:06:56 -0700 Doug Barton do...@freebsd.org wrote: Jason J. Hellenthal wrote: Why not just add weekly_status_pkg_enable=YES to /etc/periodic.conf.local and youll be informed of packages that need updating. Sorry to pick on your response, but this thread is a good time to remind people of some basic mailing list etiquette: No its not a problem at all I must have missed part of the thread and picked up the portion where pkg_version was being discussed. 1. Read the whole thread before you reply (the suggestion you made above was already made earlier in this thread). 2. Make sure you understand the real problem before you reply (the OP has some sort of problem with his INDEX and ports tree not matching, we've moved past just finding out what needs updating). 3. Don't speculate. If you're not 100% sure about something let someone who is more knowledgeable reply. There have been several posts in this thread that gave misleading and/or confusing information that could easily have been avoided. hth, Doug -- This .signature sanitized for your protection -- Jason J. Hellenthal +1.616.403.8065 jas...@dataix.net ___ 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 Port: kdebase-workspace-4.3.0
Folks, Am compiling KDE4 (from scratch) am getting a stop in kdebase4-workspace. Stop is due to a missing xml file /usr/local/kde4/share/dbus-1/interfaces/org.kde.NotificationItemWatcher.xml. I believe I have compiled the dependencies with all the latest sources.. What am I missing Thank you, Ron Robinson Monroe, NY ___ 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: portversion and pkg_version have different opinions on current versions
Doug Barton wrote: Thomas Backman wrote: Thanks, guys! However, a new issue appeared... Kind of. I know I read something about portsnap and INDEX on the -current list recently, so I'm guessing this is related? Maybe not, though (see later in the mail). [r...@chaos /usr/ports/ports-mgmt]# portsnap -I fetch update /dev/null [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vL= [r...@chaos /usr/ports/ports-mgmt]# pkg_version -vIL= curl-7.19.5_1 needs updating (index has 7.19.6) dnsmasq-2.49_1 needs updating (index has 2.49_2) ezm3-1.1_2 needs updating (index has 1.2_1) Can you check the files in your ports tree to see if they have the older versions or the newer? You can either read the Makefiles or do this: cd /usr/ports/ftp/curl make -V PKGNAME I suspect that somehow the INDEX file and your ports tree are out of date, although my understanding was that this should not happen with portsnap. Files in ports tree and INDEX are out of sync, because of the -I in portsnap command. The -I updates INDEX only! man portsnap: -I For the update command, update INDEX files, but not the rest of the ports tree. That's why portupgrade -a cannot upgrade anything, because ports tree doesn't have updated files. Solution: portsnap fetch update (This will update both INDEX + files) Miroslav Lachman PS: do not redirect output of the portsnap command to /dev/null and you will see, what portsnap is doing :) ___ 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: diablo-jdk-1.6.0.07.02_5 remote code execution exploit
On Sun, Aug 09, 2009 at 10:16:44AM +0200, Klaus Koch wrote: as of 6th of August, there's a possible remote code execution exploit known in both Sun JDK and JRE 6 Update 14 and earlier and Sun JDK and JRE 5.0 Update 19 and earlier [...] I didn't get any notifications with portaudit yet. Because I don't know who to contact else, I'm sending this to the port maintainer/team. For future reference, the right mailing address is sect...@freebsd.org. This is an address rather than a mailing list so tat fixes may be developed before vulnerabilities are announced. mcl ___ 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
startx won't start twm with empty xinitrc
Hi! I rebuilt whole x11/xorg (due to problem with google earth - it's been missing earth picture) but i didn't solve that problem. Even more, now I'm trying to startx with empty ~/.xinitrc (twm should be run as default WM), but twm won't start. X server just shut down without errors. With exec twm defined in ~/.xinitrc something happens, X seems to be running, but screen is just black. Nothing happens. How can I solve this? Nik ___ 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
