Re: php52-snmp
I think it should be
LIB_DEPENDS+= netsnmp:${PORTSDIR}/net-mgmt/net-snmp
Like this
http://www.freebsd.org/cgi/query-pr.cgi?pr=159253
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/php52-snmp-tp4656720p4657818.html
Sent from the freebsd-ports mailing list archive at Nabble.com.
___
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
Typo in x11-toolkits/gtk30
Hello, I'm not sure that gtk-3.0 appears in 1997 ;-). # New ports collection makefile for: gtk13 ^ # Date Created: 28 Sep 1997 ^^^ # Whom: Vanilla I. Shu vani...@minje.com.tw # # $FreeBSD: ports/x11-toolkits/gtk30/Makefile,v 1.251 2011/07/30 09:20:20 kwm Exp $ # $MCom: ports/x11-toolkits/gtk30/Makefile,v 1.35 2011/06/07 13:19:12 kwm Exp $ # Cheers, -- David Demelier ___ 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: Typo in x11-toolkits/gtk30
On Tue, 2011-08-02 at 10:26 +0200, David Demelier wrote: Hello, I'm not sure that gtk-3.0 appears in 1997 ;-). It isn't a typo. This port was repo-copied from gtk20 which was in a previous life gtk13 :). It all history. -Koop # New ports collection makefile for: gtk13 ^ # Date Created: 28 Sep 1997 ^^^ # Whom: Vanilla I. Shu vani...@minje.com.tw # # $FreeBSD: ports/x11-toolkits/gtk30/Makefile,v 1.251 2011/07/30 09:20:20 kwm Exp $ # $MCom: ports/x11-toolkits/gtk30/Makefile,v 1.35 2011/06/07 13:19:12 kwm Exp $ # Cheers, ___ 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: postfix-2.8.4,1
olli hauer wrote: On 2011-08-01 23:31, Olli Hauer wrote: On 2011-08-01 22:54, Miroslav Lachman wrote: Olli Hauer wrote: On 2011-08-01 12:55, Miroslav Lachman wrote: [...] Today (after Postfix upgrade) I have this in daily report: Backup passwd and group files: elsa.codelab.cz group diffs: 34c34 maildirs:*:3125:postfix --- maildirs:*:3125: So I looked in to /etc/group and found that postfix is no longer member of the group maildirs: maildirs:*:3125: I must re-add it to group maildirs, so now I have it right: id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) Miroslav Lachman Oh, indeed. You hit a limitation of /usr/sbin/pw. The groups are applied with pw usermod -G $grouplist from pw(8): -G grouplist Set additional group memberships for an account. grouplist is a comma, space or tab-separated list of group names or group numbers. The user's name is added to the group lists in /etc/group, *and removed from any groups not specified in grouplist*. I can think about a workaround for your case. Give me some time will do some tests. No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. I will look into this. Thanks for your report. Thank you for your time. I am so glad to see quick and helpful response like this. I have a bunch of mail servers waiting for Postfix upgrade, so let me know about some patches I can test. 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: porter handbook MASTER_SITES section outdated?
On Mon, Aug 01, 2011 at 10:42:13AM -0400, b. f. wrote:
In sec 5.4.2 MASTER_SITES in the porter handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-distfiles.html#AEN1512
the example given is:
MASTER_SITES= ${MASTER_SITE_GNU}
However, sunpoet@ has just committed my patch
changing my ${IGNORE_MASTER_SITE_XCONTRIB} and
${MASTER_SITE_LOCAL} to:
MASTER_SITES= XCONTRIB/applications \
http://seis.bris.ac.uk/~mexas/ \
LOCAL/simon
Are both forms acceptable? Or is the form
given in the porters handbook outdated?
Yes. No. He is just making use of an abbreviation that is translated
into the full urls by the macros at the end of ports/Mk/bsd.sites.mk.
You can do the same in your own submissions, but you should check that
they actually work by using make fetch-urlall-list or the like.
...and (not or! :) also by using the ports-mgmt/distilator port.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
I had to translate this sentence into English because I could not read the
original Sanskrit.
signature.asc
Description: Digital signature
Re: Claws-Mail marked as BROKEN
Am 30.07.2011 15:44, schrieb Pawel Pekala: Dnia 2011-07-30, o godz. 09:08:20 Carmel carmel...@hotmail.com napisał(a): I am in the process of setting up a new PC and wanted to install claws-mail as my MUA. I have it all ready installed on another machine I use. This port, unfortunately, is marked: BROKEN= does not compile I`m working on fix right now. If you comment this line it should compile just fine as problem appears to show only in clean tinderbuild environment (software we use to test our ports). You can just do make TRYBROKEN=yes, or pass make options through portmaster or portupgrade (see the respective manual for how to do that). ___ 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 unattended run?
Am 30.07.2011 19:44, schrieb Lev Serebryakov: Hello, Freebsd-ports. How could I run `portmaster' without ANY questions and confirmations? Simple and obvious `portmaster --no-confirm -y list of ports' doesn't work. It asks: (1) About interactive ports. (2) About removing old distfiles (3) About errors from `tar' when create backup archive with old versions. portmaster --no-confirm -y -d -mBATCH=yes /dev/null LISTOFPORTS ___ 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
from netsnmp.20 to netsnmp.30
since we have net-snmp 5.7 in ports it would be right to correct some ports
from netsnmp.20 to netsnmp.30
[root@monitor /usr/ports]# grep -R netsnmp.20 *
french/plgrenouille/Makefile:LIB_DEPENDS=
netsnmp.20:${PORTSDIR}/net-mgmt/net-snmp
security/libfwbuilder/Makefile:
netsnmp.20:${PORTSDIR}/net-mgmt/net-snmp
sysutils/rsyslog5-devel-snmp/Makefile:LIB_DEPENDS=
netsnmp.20:${PORTSDIR}/net-mgmt/net-snmp
___
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: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
On Aug 1, 2011, at 9:01 PM, Sahil Tandon sa...@freebsd.org wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. And it would help if I did not transmit horribly mangled patches! Sorry about that, please see: http://people.freebsd.org/~sahil/2011-08-02/bsd.port.mk.diff.txt -- Sahil Tandon___ 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: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4, 1]
Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. # pkg_version -vIL = | grep postfix postfix-2.7.2,1 needs updating (index has 2.8.4,1) # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) # patch ~/bsd.port.mk.diff # portmaster postfix-2.7.2,1 === The following actions were performed: Upgrade of mysql-client-5.1.53 to mysql-client-5.1.58 Upgrade of libtool-2.2.10 to libtool-2.4 Upgrade of cyrus-sasl-2.1.23_1 to cyrus-sasl-2.1.23_3 Upgrade of postfix-2.7.2,1 to postfix-2.8.4,1 # id postfix uid=125(postfix) gid=125(postfix) groups=125(postfix),6(mail),3125(maildirs) It was tested on really old testing system... Thank you for your time and working solution. 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: UPDATING 20110730
on 31/07/2011 22:14 Doug Barton said the following: Understood, but I'm not sure what I can do about it unless I can reproduce it. I reproduced the problem by doing a similar kind of upgrade: $ pkg_delete -f gtk-2.\* $ portmaster -v atk-2.0.1 gio-fam-backend-2.28.8 glib-2.28.8 gobject-introspection-0.10.8 x11-toolkits/gtk20 Now I see some duality in the problem. First, let's consider the portmaster side. Suppose we have two ports A and B that both depend on both of two other ports C and D. When portmaster upgrades port C it updates dependency information in ports A and B, and while doing that it also checks (and potentially updates) dependency information for port D. First of all, it's not clear if that check for port D is really required. Second, I think that portmaster could cache the origin = pkg mapping that it builds while working on port A, so that it can be readily re-used for port B. That could also include negative mapping where there is no installed pkg for a given origin. Why this caching could be useful becomes more evident if there are hundreds of ports in the A, B, ... class and hundreds of ports in the C, D, ... class. As it stands now, the above invocation of portmaster searches for an installed package with an origin of x11-toolkits/gtk20 for 714 times. Each search includes grepping */+CONTENTS in /var/db/pkg directory and also executing pkg_info -q -O x11-toolkits/gtk20. As far as I can see, each such pkg_info invocation also performs something very similar to the grep action: it calls getdirentries(2) on each port subdirectory and then reads +CONTENTS from it. What I further observe is those pkg_info calls are sometimes quite fast, sometimes slow and sometimes are very slow like couple dozen seconds. Given that there are ~700 pkg_info runs all those delays add up to quite a long period. And now to my side of the problem. While profiling pkg_info with ktrace I see getdirentries(2) calls sometimes take quite a while. And since I have 1000 ports all those calls do add up. DTrace shows that the calls are quite fast (~0.3 ms) when there is no actual disk access, but if it occurs then it introduces a delay on the orders of 1 - 100 milliseconds. I am really in doubts about what is happening here. It seems that all the directory data isn't kept in ZFS ARC for long enough or is squeezed out of it by some other data (without additional pressure it should easily fit into the ARC). And also that somehow disk accesses have quite large latency. Although svc_t according to iostat is smaller (5 - 10 ms). DTrace shows that the thread spends the time in cv_wait. So it's possible that the scheduler is also involved here as its decisions also may add a delay to when the thread becomes runnable again. -- Andriy Gapon ___ 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
PackageKit apparently depends on lzma
(Note: I am totally new to FreeBSD ports and have no idea if I am sending this
to the right place.)
At least for FreeBSD 8.2-stable, the most recent PackageKit port requires that
the lzma port be installed -- it fails to link if you have not
installed the lzma port
(which itself requires a little hand-holding since it overrides the
base system's
xz, which I'm not sure if that's OK either...).
My guess is that this should be listed in the LIB_DEPENDS line in
ports/ports-mgmt/packagekit/Makefile.
This diff (using cut and paste with gmail so blanks get expanded) seems to
work, but I don't really know if it is right.
Chris
Author: Chris Torek chris.to...@gmail.com
Date: Tue Aug 2 08:12:04 2011 -0600
depends on lzma
PackageKit needs lzma installed (overriding base xz). List
this in the LIB_DEPENDS.
diff --git a/packagekit/Makefile b/packagekit/Makefile
index 519dd82..e842619 100644
--- a/packagekit/Makefile
+++ b/packagekit/Makefile
@@ -20,6 +20,7 @@ LIB_DEPENDS= execinfo.1:${PORTSDIR}/devel/libexecinfo \
sqlite3.8:${PORTSDIR}/databases/sqlite3 \
dbus-glib-1:${PORTSDIR}/devel/dbus-glib \
polkit-gobject-1.0:${PORTSDIR}/sysutils/polkit \
+ lzma:${PORTSDIR}/archivers/lzma \
ck-connector.0:${PORTSDIR}/sysutils/consolekit
RUN_DEPENDS= lsof:${PORTSDIR}/sysutils/lsof \
${LOCALBASE}/share/gir-1.0/GLib-2.0.gir:${PORTSDIR}/devel/gobject-introspection
\
___
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
portmaster, zfs metadata caching [Was: UPDATING 20110730]
on 02/08/2011 16:14 Andriy Gapon said the following: And now to my side of the problem. While profiling pkg_info with ktrace I see getdirentries(2) calls sometimes take quite a while. And since I have 1000 ports all those calls do add up. DTrace shows that the calls are quite fast (~0.3 ms) when there is no actual disk access, but if it occurs then it introduces a delay on the orders of 1 - 100 milliseconds. I am really in doubts about what is happening here. It seems that all the directory data isn't kept in ZFS ARC for long enough or is squeezed out of it by some other data (without additional pressure it should easily fit into the ARC). And also that somehow disk accesses have quite large latency. Although svc_t according to iostat is smaller (5 - 10 ms). DTrace shows that the thread spends the time in cv_wait. So it's possible that the scheduler is also involved here as its decisions also may add a delay to when the thread becomes runnable again. Reporting further, just in case anyone follows this. (You may want to scroll down to my conclusions at the end of the message). I tracked my ZFS problem to my experiments with ZFS tuning. I limited my ARC size at some value that I considered to be large enough to cache my working sets of data and _metadata_. Little did I know that by default ZFS sets aside only 1/4th of ARC size for metadata. So this is already significantly smaller than I expected. Then it seems that a large piece of that metadata portion is permanently occupied by some non-evict-able data (not sure what it actually is, haven't tracked yet). In the end only a small portion of my ARC was available for holding the metadata which included the directory contents data. So this is what I had with the old settings: vfs.zfs.arc_meta_limit: 314572800 vfs.zfs.arc_meta_used: 401064272 and $ for i in $(jot 5) ; do /usr/bin/time -p pkg_info -O print/printme ; done The following installed package(s) has print/printme origin: real 12.55 user 0.02 sys 2.51 The following installed package(s) has print/printme origin: real 12.65 user 0.03 sys 1.99 The following installed package(s) has print/printme origin: real 10.57 user 0.02 sys 1.57 The following installed package(s) has print/printme origin: real 8.85 user 0.03 sys 0.17 The following installed package(s) has print/printme origin: real 9.28 user 0.02 sys 0.20 I think that you should get the picture. Now I have bumped the limit and this is what I had just right after doing it: vfs.zfs.arc_meta_limit: 717225984 vfs.zfs.arc_meta_used: 414439800 and $ for i in $(jot 5) ; do /usr/bin/time -p pkg_info -O print/printme ; done The following installed package(s) has print/printme origin: real 9.08 user 0.01 sys 0.18 The following installed package(s) has print/printme origin: real 7.48 user 0.04 sys 0.14 The following installed package(s) has print/printme origin: real 0.08 user 0.00 sys 0.07 The following installed package(s) has print/printme origin: real 0.95 user 0.03 sys 0.04 The following installed package(s) has print/printme origin: real 0.08 user 0.00 sys 0.07 Two runs to warm up the ARC and then everything works just perfect. I think that this is an important discovery for two reason: 1. I learned a new thing about ZFS ARC. 2. This problem demonstrates that portmaster currently does depend on a filesystem cache being able to hold a significant amount of ports/packages (meta)data. -- Andriy Gapon ___ 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 unattended run?
2011/7/30 Lev Serebryakov l...@freebsd.org: Hello, Freebsd-ports. How could I run `portmaster' without ANY questions and confirmations? Simple and obvious `portmaster --no-confirm -y list of ports' doesn't work. It asks: (1) About interactive ports. (2) About removing old distfiles (3) About errors from `tar' when create backup archive with old versions. I like to use portmaster -adw, but it still asks what to do when there is an error during creation ok backup package (for example if there's a plist error). I was used to portupgrade -a but now I'm happier with portmaster -adw. You can check the man page. -- // Black Lion AKA Lev Serebryakov l...@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 -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: UPDATING 20110730
on 02/08/2011 21:26 Doug Barton said the following: On 08/02/2011 06:14, Andriy Gapon wrote: Second, I think that portmaster could cache the origin = pkg mapping that it builds while working on port A, so that it can be readily re-used for port B. That could also include negative mapping where there is no installed pkg for a given origin. That's a reasonable idea, but moderately complex to do. I'll put it on the list but it's not going to be a priority since in non-worst-case scenarios it's generally quite fast as it is. Meanwhile thanks for digging further into your situation and confirming that it's a local problem. Well, yes with a little bit of no. I will repeat myself: currently portmaster's performance relies on the fact that certain often used data originating from disk is actually cached in memory by the OS. Typically performance-conscious applications explicitly pull such data into an application cache. But practice is the main criterion. -- Andriy Gapon ___ 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: from netsnmp.20 to netsnmp.30
On Tue, Aug 02, 2011 at 03:39:57PM +0400, Pavel Timofeev thus spake:
since we have net-snmp 5.7 in ports it would be right to correct some ports
from netsnmp.20 to netsnmp.30
[root@monitor /usr/ports]# grep -R netsnmp.20 *
french/plgrenouille/Makefile:LIB_DEPENDS=
netsnmp.20:${PORTSDIR}/net-mgmt/net-snmp
security/libfwbuilder/Makefile:
netsnmp.20:${PORTSDIR}/net-mgmt/net-snmp
sysutils/rsyslog5-devel-snmp/Makefile:LIB_DEPENDS=
netsnmp.20:${PORTSDIR}/net-mgmt/net-snmp
You may want to update your portstree, and run this check again. All of
the ports listed here are either no longer in the ports tree, or have
been merged into other ports that are using netsnmp.30.
-jgh
--
Jason Helfman
System Administrator
experts-exchange.com
http://www.experts-exchange.com/M_4830110.html
E4AD 7CF1 1396 27F6 79DD 4342 5E92 AD66 8C8C FBA5
___
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: UPDATING 20110730
On 08/02/2011 12:12, Andriy Gapon wrote: on 02/08/2011 21:26 Doug Barton said the following: On 08/02/2011 06:14, Andriy Gapon wrote: Second, I think that portmaster could cache the origin = pkg mapping that it builds while working on port A, so that it can be readily re-used for port B. That could also include negative mapping where there is no installed pkg for a given origin. That's a reasonable idea, but moderately complex to do. I'll put it on the list but it's not going to be a priority since in non-worst-case scenarios it's generally quite fast as it is. Meanwhile thanks for digging further into your situation and confirming that it's a local problem. Well, yes with a little bit of no. I will repeat myself: currently portmaster's performance relies on the fact that certain often used data originating from disk is actually cached in memory by the OS. And I will repeat myself, one last time. The assumptions that portmaster makes are reasonable under typical conditions, but can be improved which I will do in due course. However, your conditions are very non-typical, including but not limited to: slow disk, small amount of ram, zfs on a slow disk with a small amount of ram, poorly tuned zfs on a slow disk with a small amount of ram, and a large'ish number of ports installed. I get that you're disappointed with portmaster's performance under these circumstances, and I've already said that I will do what I can, when I can, to improve that. Hopefully I won't need to repeat myself again. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Any progress on updating boost?
I notice that http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/156253 exists for the 1.46.1 update, however 1.47 is out since July 11. I'm curious about whatever plans may exist to do the update ... Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: UPDATING 20110730
on 02/08/2011 23:08 Doug Barton said the following: On 08/02/2011 12:12, Andriy Gapon wrote: on 02/08/2011 21:26 Doug Barton said the following: On 08/02/2011 06:14, Andriy Gapon wrote: Second, I think that portmaster could cache the origin = pkg mapping that it builds while working on port A, so that it can be readily re-used for port B. That could also include negative mapping where there is no installed pkg for a given origin. That's a reasonable idea, but moderately complex to do. I'll put it on the list but it's not going to be a priority since in non-worst-case scenarios it's generally quite fast as it is. Meanwhile thanks for digging further into your situation and confirming that it's a local problem. Well, yes with a little bit of no. I will repeat myself: currently portmaster's performance relies on the fact that certain often used data originating from disk is actually cached in memory by the OS. And I will repeat myself, one last time. The assumptions that portmaster makes are reasonable under typical conditions, but can be improved which I will do in due course. However, your conditions are very non-typical, including but not limited to: slow disk, small amount of ram, zfs on a slow disk with a small amount of ram, poorly tuned zfs on a slow disk with a small amount of ram, and a large'ish number of ports installed. Just a few small corrections: - the disks are not that slow (not sure how you deduced that): Seagate Barracuda 7200.12 - the RAM is not that small: 4GB - ZFS is not in such a bad environment as you portrayed it - ZFS is not so poorly tuned, ARC size above 1GB should be sufficient for a desktop-ish machine - the number of ports is not so large-ish for a desktop-ish machine I get that you're disappointed with portmaster's performance under these circumstances, and I've already said that I will do what I can, when I can, to improve that. Hopefully I won't need to repeat myself again. :) I got this. -- Andriy Gapon ___ 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: UPDATING 20110730
On 08/02/2011 13:39, Andriy Gapon wrote: Just a few small corrections: I was using your description of the situation. Sorry if I misunderstood. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: UPDATING 20110730
On 2011-Aug-01 19:21:21 +0200, Michel Talon ta...@lpthe.jussieu.fr wrote: This is unfortunately impossible because the ports system is organized around a make logic and the relevant dependency variables are only obtained through running make on each ports Makefile *in the context* of the gigantic makefiles (bsd.port.mk, etc) which are included. We've had this discussion before but there is plenty of scope for someone with copious free time to optimise this. Options include a new tool that handles the easy cases without needing to fully parse all of bsd.*.mk (and knows to punt the cases it can't handle to make) and/or pre-precessing bsd.*.mk to speed up their loading. Note that about 1/3 of bsd.*.mk is comments. On 2011-Aug-02 22:12:48 +0300, Andriy Gapon a...@freebsd.org wrote: I will repeat myself: currently portmaster's performance relies on the fact that certain often used data originating from disk is actually cached in memory by the OS. Typically performance-conscious applications explicitly pull such data into an application cache. An alternative viewpoint is that this is wasteful because data is then double-buffered. An alternative view is that the default ZFS configuration is sub-optimal and should be fixed - rather than insisting that every tool that accesses more than a handful of files should do its own caching. (And, reading zfs-discuss, avg@ is far from the only person to have been bitten by the ZFS metadata limit). -- Peter Jeremy pgp4AvKy1tNvA.pgp Description: PGP signature
Re: Typo in x11-toolkits/gtk30
On 02/08/2011 10:45, Koop Mast wrote: On Tue, 2011-08-02 at 10:26 +0200, David Demelier wrote: Hello, I'm not sure that gtk-3.0 appears in 1997 ;-). It isn't a typo. This port was repo-copied from gtk20 which was in a previous life gtk13 :). It all history. Yes but this does not make sense at all... -Koop # New ports collection makefile for: gtk13 ^ # Date Created: 28 Sep 1997 ^^^ # Whom: Vanilla I. Shuvani...@minje.com.tw # # $FreeBSD: ports/x11-toolkits/gtk30/Makefile,v 1.251 2011/07/30 09:20:20 kwm Exp $ # $MCom: ports/x11-toolkits/gtk30/Makefile,v 1.35 2011/06/07 13:19:12 kwm Exp $ # Cheers, -- David Demelier ___ 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: Typo in x11-toolkits/gtk30
On 8/2/11 5:37 PM, David Demelier wrote: On 02/08/2011 10:45, Koop Mast wrote: On Tue, 2011-08-02 at 10:26 +0200, David Demelier wrote: Hello, I'm not sure that gtk-3.0 appears in 1997 ;-). It isn't a typo. This port was repo-copied from gtk20 which was in a previous life gtk13 :). It all history. Yes but this does not make sense at all... FreeBSD is very sensitive to give credit where credit is due and to preserve the history of our work. When we repocopy ports, we preserve some fields to tell the story. The work done on the gtk30 port today has it roots way back when gtk13 was spinning up. Joe -Koop # New ports collection makefile for: gtk13 ^ # Date Created:28 Sep 1997 ^^^ # Whom:Vanilla I. Shuvani...@minje.com.tw # # $FreeBSD: ports/x11-toolkits/gtk30/Makefile,v 1.251 2011/07/30 09:20:20 kwm Exp $ # $MCom: ports/x11-toolkits/gtk30/Makefile,v 1.35 2011/06/07 13:19:12 kwm Exp $ # Cheers, -- Joe Marcus Clarke FreeBSD GNOME Team :: gn...@freebsd.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ 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: devel/icu... help... ?
Are you serious? Upgrading the OS on a production machine is a really steep price to pay. I've over a thousand working ports and numerous customers that I would have to port afterwards. You really can't fix what appears to be a reasonable request? -- View this message in context: http://freebsd.1045724.n5.nabble.com/devel-icu-help-tp4600103p4660554.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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: devel/icu... help... ?
On Tue, 2 Aug 2011 15:34:00 -0700 (PDT), JoelFRodriguez wrote: Are you serious? Upgrading the OS on a production machine is a really steep price to pay. I've over a thousand working ports and numerous customers that I would have to port afterwards. You really can't fix what appears to be a reasonable request? -- View this message in context: http://freebsd.1045724.n5.nabble.com/devel-icu-help-tp4600103p4660554.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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 well we already support 3 version at the same time, which can be complicated sometime, if we had a fix we would provide it, if someone comes with fix I'll be happy to integrate it. But the rules about EOL are clear, and it is easy for production to have a clear statement on what will be supported and what won't, and to organize themself with the informations. the portstree is also tagged when EOL occurs, so why still updating the ports tree after the dead line? Another solution can be to pay some freelance to do the fix if really needed. icu is a complicated ports and not an easy one to maintain, keeping the version working on 3 OSes (7 8 and 9) is already a pain. Last it's free software, you can contribute, maybe you have a fix to propose, I'll be glad to commit it. regards, Bapt ___ 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: devel/icu... help... ?
On 08/02/2011 15:34, JoelFRodriguez wrote: Are you serious? Upgrading the OS on a production machine is a really steep price to pay. I've over a thousand working ports and numerous customers that I would have to port afterwards. FreeBSD 6 has been EOL since November 30, 2010. We have been encouraging users to move to a newer branch since long before that. It's awesome that often things work past the EOL date, but we definitely do not encourage users to rely on that. We all understand how difficult it is to migrate, but sometimes it's necessary. Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: devel/icu... help... ?
Thanks for the quick reply and I certainly appreciate your viewpoint. Are these undefined references defined by FREEBSD? If so, why would you introduce an OS dependency in a library intended to provide unicode support? c++ -O2 -fno-strict-aliasing -pipe -W -Wall -ansi -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -o intltest aliastst.o allcoll.o apic\ oll.o astrotst.o callimts.o calregts.o caltest.o caltztst.o canittst.o citrtest.o cntabcol.o convtest.o currcoll.o fldset.o dadrfmt.o dadrcal.o da\drcoll.o dcfmapts.o decoll.o dtfmapts.o dtfmrgts.o dtfmtrtts.o dtfmttst.o dtptngts.o encoll.o escoll.o ficoll.o frcoll.o g7coll.o intltest.o iterc\ oll.o itformat.o itmajor.o itutil.o jacoll.o lcukocol.o loctest.o miscdtfm.o mnkytst.o msfmrgts.o nmfmapts.o nmfmtrt.o numfmtst.o numrgts.o plurul\ ts.o plurfmts.o pptest.o regcoll.o restest.o restsnew.o sdtfmtts.o svccoll.o tchcfmt.o selfmts.o tfsmalls.o tmsgfmt.o trcoll.o tscoll.o tsdate.o t\ sdcfmsy.o tsdtfmsy.o tsmthred.o tsnmfmt.o tsputil.o tstnrapi.o tstnorm.o tzbdtest.o tzregts.o tztest.o ucdtest.o usettest.o ustrtest.o strcase.o t\ ranstst.o strtest.o thcoll.o bytestrietest.o ucharstrietest.o itrbbi.o rbbiapts.o dicttest.o rbbitst.o ittrans.o transapi.o cpdtrtst.o testutil.o \ transrt.o trnserr.o normconf.o sfwdchit.o jamotest.o srchtest.o reptest.o regextst.o itrbnf.o itrbnfrt.o itrbnfp.o ucaconf.o icusvtst.o uobjtest.o\ idnaref.o idnaconf.o nptrans.o punyref.o testidn.o testidna.o uts46test.o incaltst.o calcasts.o v32test.o uvectest.o textfile.o tokiter.o utxttes\ t.o windttst.o winnmtst.o winutil.o csdetest.o tzrulets.o tzoffloc.o tzfmttst.o ssearch.o dtifmtts.o tufmtts.o itspoof.o simplethread.o bidiconf.o\ locnmtst.o dcfmtest.o alphaindextst.o -L../../tools/ctestfw -licutest -L../../lib -licui18n -L../../lib -licuuc -L../../stubdata -licudata -L../.\ ./lib -licutu -lm -lpthread numfmtst.o(.data+0x30c): undefined reference to `.LC3163' numfmtst.o(.data+0x314): undefined reference to `.LC3164' numfmtst.o(.data+0x324): undefined reference to `.LC3165' numfmtst.o(.data+0x39c): undefined reference to `.LC3171' gmake[1]: *** [intltest] Error 1 gmake[1]: Leaving directory `/usr/ports/devel/icu/work/icu/source/test/intltest' gmake: *** [all-recursive] Error 2 gmake: Leaving directory `/usr/ports/devel/icu/work/icu/source/test' *** Error code 2 (ignored) cd /usr/ports/devel/icu/work/icu/source/test/iotest /usr/bin/env LD_LIBRARY_PATH=/usr/ports/devel/icu/work/icu/source/lib:/usr/ports/devel/icu\ /work/icu/source/tools/ctestfw ./iotest env: ./iotest: No such file or directory *** Error code 127 Stop in /usr/ports/devel/icu. *** Error code 1 Stop in /usr/ports/devel/icu. If I ignore the bad refs, then the error looks like a shell syntax problem. Of course, I only ask because I do not have the time to wade through all your stuff to figure out what is going on. But ICU is required for the latest glib20 build which QT uses. This stuff has worked fine on my FREEBSD6.2 system until this week. And if I read these msgs correctly, this problem also occurs on FREEBSD8. -- View this message in context: http://freebsd.1045724.n5.nabble.com/devel-icu-help-tp4600103p4660860.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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: devel/icu... help... ?
On 08/02/2011 17:59, JoelFRodriguez wrote: This stuff has worked fine on my FREEBSD6.2 system until this week. And if I read these msgs correctly, this problem also occurs on FREEBSD8. The current icu and glib20 ports work fine on all supported versions of FreeBSD. I think bapt's response was very diplomatic, but I'll be more blunt. You can't expect anyone else to solve this problem for you. We make the effort (on an almost exclusively volunteer basis) to support what we agree to support. We gave up on supporting FreeBSD 6 last year. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: Deprecation: round3
Baptiste Daroussin b...@freebsd.org wrote: For the third time, I'm running a deprecation campaign to remove old, unmaintain and/or problematic stuff from the ports tree (ports@) As usual I may be wrong there maybe some false positive, I sharpened a bit my analysis scripts so there should be less false positive in the deprecated ports. While here I have fix and will fix lots of ports master_sites that would be great if you fix as much master sites as you can, this website may help: http://people.freebsd.org/~ehaupt/distilator/ What, exactly, is the significance of the list at http://people.freebsd.org/~ehaupt/distilator/po...@freebsd.org-bad.html beyond that the ports listed there are unmaintained? make fetch succeeded for every one of the ~150 ports that I tried from that list, using the first site it attempted in the considerable majority of cases. ___ 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: USERS/GROUPS in bsd.port.mk [was: FreeBSD Port: postfix-2.8.4,1]
[ adding portmgr@ to the chain since we're in bpmk territory] On Tue, 2011-08-02 at 15:09:49 +0200, Miroslav Lachman wrote: Sahil Tandon wrote: On Tue, 2011-08-02 at 00:04:14 +0200, olli hauer wrote: No, you don't hit the limitation. It seems you really found a bug in the Framework! From the Framework code in bsd.port.mk existing groups should honored. Along those lines, what about using groupmod instead of usermod? Perhaps due to my ignorance, it seems more straightforward and does not require much sed-fu; I've attached a (probably incomplete) patch to illustrate my thinking. I understand what I am suggesting could introduce other problems, so please do not construe it as an as-is suggestion, but rather something to stoke discussion. I tested your patch and it works for me. [ .. ] It was tested on really old testing system... Thank you for your time and working solution. You are welcome - thanks again for reporting the problem and testing the new patch. I believe ohauer@ is taking a look at how else to achieve the desired behavior without introducing new problems. I hope we can get a fix into the tree soon. -- Sahil Tandon sa...@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: Deprecation: round3
make fetch succeeded for every one of the ~150 ports that I tried from that list, using the first site it attempted in the considerable majority of cases. Did it fetch from a FreeBSD distfile mirror? We don't count that as functioning correctly. -- Eitan Adler ___ 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
