Re: net/p5-Net-Twitter broken
On Thu 2009-07-30 10:07:28 UTC+0300, Sergey V. Dyatko (sergey.dya...@gmail.com) wrote: AC Warning: prerequisite MooseX::MultiInitArg 0 not found. AC Writing Makefile for Net::Twitter AC Is MooseX::MultiInitArg hidden somewhere in the ports tree? No, we haven't it. You may try install it via cpan How do I 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: net/p5-Net-Twitter broken
On Thu 2009-07-30 09:21:27 UTC+0200, Cezary Morga (c...@therek.net) wrote: Warning: prerequisite MooseX::MultiInitArg 0 not found. Writing Makefile for Net::Twitter Is MooseX::MultiInitArg hidden somewhere in the ports tree? Nope. It's a missing dependency (also visible here http://pointyhat.freebsd.org/errorlogs/i386-7-latest-logs/p5-Net-Twitter-3.03000.log). Please, fill in a PR for this. If you can prepare a proper patch for the new port and modification to net/p5-Net-Twitter/Makefile that would be even better. I'll attempt a PR, but I'm not at all competent enough in Perl to be confident in providing a patch. I have to wonder - why have these recent versions of this port been committed but not tested? If it was tested, presumably it would be flagged as BROKEN. But isn't the rationale of the Ports tree to have buildable, working software? ___ 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/boost: new patch for testing update to 1.39
Mel,
Now It's clear. Thank you for explanation.
The WITH_PYSTE was not in the options framework, that's why I've
missed this part of work.
I see two possible solutions:
1) Put the WITH_PYSTE variable back.
2) Create a separate port like devel/boost-pyste.
The first is easy, however leads to dependeny issues like 'let's
verify that boost-python-libs is installed with PYSTE support'.
Provided that Pyste is actually used by someone, this may re-introduce
bug ports/123927 (see
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123927).
The second is much more robust, but requires more work. This is also
harder because I am not a user of Boost.Pyste. Thus, correctness
verification would be expensive.
Folks, is there a user of Boost.Pyste, willing to volunteer with
devel/boost-pyste quality verification?
Sincerely,
Alexander Churanov
maintainer of devel/boost-*
2009/7/30 Mel Flynn mel.flynn+fbsd.po...@mailing.thruhere.net:
On Thursday 30 July 2009 03:20:56 Alexander Churanov wrote:
I do not understand.
Is it correct that you are discussing the issue of Pyste being part of
boost and depending on gccxml port, which has issues of its own?
I do not use Pyste and did not performed any specific testing of it,
but all of boost-python-libs builds and installs, including
dependencies.
Please, describe what do you expect from ports and what do you
observe, what negative outcome the issue has.
The previous boost-python port had an *optional* dependency on pyste.
The current one does not. This means that boost-python now pulls in
gccxml which pulls in lang/gcc34 on anything but 6.x.
I'm currently building boost-python-libs with the pyste stuff
ifdef'd out[1] and will try to build packages kdeedu3, kdebase4,
games/wesnoth to see if there's any adverse side-effects.
--
Mel
[1]
--- Makefile.orig 2009-07-28 03:44:50.0 -0800
+++ Makefile 2009-07-30 07:19:26.0 -0800
@@ -25,9 +25,11 @@
PYTHON_INCLUDES=${PYTHON_INCLUDEDIR}\
PYTHON_LIB_PATH=${PYTHON_LIBDIR}
-RUN_DEPENDS+=
${PREFIX}/lib/libboost_thread.so.${BOOST_SHARED_LIB_VER}:${PORTSDIR}/devel/boost-libs
-RUN_DEPENDS+= gccxml:${PORTSDIR}/devel/gccxml \
-
${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
+RUN_DEPENDS+=
${LOCALBASE}/lib/libboost_thread.so.${BOOST_SHARED_LIB_VER}:${PORTSDIR}/devel/boost-libs
+RUN_DEPENDS+=
${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
+.if defined(WITH_PYSTE)
+RUN_DEPENDS+= gccxml:${PORTSDIR}/devel/gccxml
+.endif
BUILD_DEPENDS+= ${BJAM}:${PORTSDIR}/devel/boost-jam
BUILD_DEPENDS+=
${PYTHON_SITELIBDIR}/elementtree/ElementTree.py:${PORTSDIR}/devel/py-elementtree
@@ -39,12 +41,13 @@
post-patch: customize-boost-build
-
+.if defined(WITH_PYSTE)
post-configure:
# Configure pyste, the Boost.Python code generator
�...@cd ${BUILD_WRKSRC}/libs/python/pyste/install \
${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
config ${PYDISTUTILS_CONFIGUREARGS}
+.endif
do-build:
# build the library
@@ -52,11 +55,12 @@
${SETENV} ${MAKE_ENV} ${BJAM} ${BJAM_OPTIONS}
--prefix=${PREFIX}\
--toolset=${BOOST_TOOLS} --with-python
+.if defined(WITH_PYSTE)
# Build pyste, the Boost.Python code generator
cd ${BUILD_WRKSRC}/libs/python/pyste/install \
${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
build ${PYDISTUTILS_BUILDARGS}
-
+.endif
# Remove non-python headers
cd ${WRKSRC} \
${FIND} boost -not -path '*python*' -delete
@@ -79,10 +83,12 @@
${FIND} boost -type f -a \! -name *.orig\
-exec ${INSTALL_DATA} \{\} ${PREFIX}/include/\{\} \;
+.if defined(WITH_PYSTE)
# Install pyste, the Boost.Python code generator
cd ${WRKSRC}/libs/python/pyste/install \
${SETENV} ${MAKE_ENV} ${PYTHON_CMD} ${PYSETUP} \
install ${PYDISTUTILS_INSTALLARGS}
+.endif
post-install:
# display pkg-message
___
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: recent change to ifconfig breaks OpenVPN?
(Moving the discussion to -ports.)
Am 31.07.2009 um 00:57 schrieb Matthias Andree:
Am 31.07.2009, 00:36 Uhr, schrieb Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net
:
Yeah that is as great as we are or rather were.
So really, fix the openvpn scripts that assign the address to
interfaces to do something that would make sense from the ``man ip''
(not the literal command) point of view. Just that it's working
somewhere or used to work elswhere neither means that it was correct
nor made sense at any time before.
It's actually in the C code where it was advertised as FreeBSD fix.
OpenVPN runs in 'topology subnet' mode here, which is documented as
follows:
Use a subnet rather than a point-to-point topology by
configuring the tun interface with a local IP address and
subnet
mask, similar to the topology used in --dev tap and
ethernet
bridging mode. This mode allocates a single IP address per
con-
necting client [... MS-Windows stuff here ...]
When used on *nix, requires that the
tun driver supports an ifconfig(8) command which sets a
subnet
instead of a remote endpoint IP address.
I wonder if TUNSIFMODE (see tun(4)) is somehow needed and if so,
already done, and how the proper ifconfig call would look like in
this case. Stefan already uttered some ideas in that direction.
Here's a first draft at a patch for OpenVPN. With this, the tun
interface gets set to IFF_BROADCAST mode. One small piece is still
missing: OpenVPN tries to install a route for the subnet, but that
fails because now ifconfig has already inserted that route. I'll try
to look into that a bit later on. I also haven't tested the server
side yet, or any other mode.
r...@freebsd-current:/usr/ports/security/openvpn-devel# cat files/
patch-tun.c
--- tun.c.orig 2009-05-30 23:34:13.0 +0200
+++ tun.c 2009-07-31 14:22:31.0 +0200
@@ -863,11 +863,10 @@
else {
if (tt-topology == TOP_SUBNET)
argv_printf (argv,
- %s %s %s %s netmask %s mtu %d up,
+ %s %s %s netmask %s mtu %d up,
IFCONFIG_PATH,
actual,
ifconfig_local,
- ifconfig_local,
ifconfig_remote_netmask,
tun_mtu
);
@@ -1745,14 +1744,15 @@
{
open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt);
- if (tt-fd = 0)
+ if (tt-fd = 0 tt-type == DEV_TYPE_TUN)
{
int i = 0;
- /* Disable extended modes */
+ i = tt-topology == TOP_SUBNET ? IFF_BROADCAST : IFF_POINTOPOINT;
+ i |= IFF_MULTICAST;
+ ioctl (tt-fd, TUNSIFMODE, i);
+ i = 0;
ioctl (tt-fd, TUNSLMODE, i);
- i = 1;
- ioctl (tt-fd, TUNSIFHEAD, i);
}
}
Stefan
--
Stefan Bethke s...@lassitu.de Fon +49 151 14070811
___
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: Using WITH_OPENSSL_PORT
Peggy Wilkins wrote: ... It turns out there are a number of open PR's for related issues. For instance: ports/120101: security/krb5 utilities link against wrong libcom_err http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120101 ports/121573: security/krb5 (MIT Kerberos) generates non-working ksu http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/121573 ports/128972: Port security/krb5 has a linking problem when compiled against base openssl http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128972 I get a working security/krb5 compiled against base openssl, if I preface all the client commands with LD_LIBRARY_PATH=/usr/local/lib. I'm not sure what a good resolution for all those PR's would be... how is this sort of conflict of shlibs normally resolved for ports? I don't see why it is necessary to engage in all these gymnastics: it seems to me that the krb5 port should be able to coexist with the base system Heimdal if the proper environment variables (KRB5_HOME, HEIMDAL_HOME, etc.) are set during the build and at runtime. Maybe you should take a look at whether you've done so, and if it still doesn't work, talk to the maintainer about cleaning up the port. It sounds as if it needs some work. Another thing that occurred to me (I may have seen it online somewhere) is that if I replace the base kerberos with ports/krb5 compiled against the base openssl, my problem with multiple conflicting shared libraries would go away. It looks like I can build my system with WITHOUT_KERBEROS setting in /etc/src.conf, though I am still unsure how to remove the already-installed kerberos on my production system -- do I hunt down and delete the already-installed files, or is there an easier way to do that? BTW even though I've been running FreeBSD for over 6 years now, I hadn't heard of /etc/src.conf before this weekend. How do people find out about that? I'm surprised to have missed it before now. If you are convinced that the base system Kerberos is unsuitable for your purposes, then I see no reason why you should build and install it. Caveats: you will lose Kerberos support in several base system utilities like ssh, cvs, telnet, etc. So if you want this, you will have to replace them with other software, or patch the base system build infrastructure. If the repository commit history is to be believed, src.conf first made it's appearance early in 2006, before the release of FreeBSD 7. Before then, the base-system build knobs were used in make.conf. Some of the knobs, or their equivalents, have been around for quite a long time. Cf. http://svn.freebsd.org/viewvc/base/head/share/examples/etc/make.conf?view=log I suppose that if you had not been following the course of development, and if it was not in the release notes for 7.0, then you probably would have noticed the advent of src.conf(5) by noticing that it was referenced in build(7) or make.conf(5). If the knob is set up properly, then running 'make delete-old' will remove the files that are no longer installed as a result of the knob. Unfortunately, some of these knobs receive little testing and maintenance, so some of them break the build(WITHOUT_KERBEROS + WITH_GSSAPI, or WITHOUT_NETGRAPH, for example), and others leave files behind. So I recommend looking for files or directories in the base system that weren't modified by an installworld + installkernel, and not removed by make delete-old. You could use some variation on: find / ! \( -path '/home*' -or -path '/usr/local*' -or -path '/etc*' -or -path '/root*' -or -path '/tmp*' -or -path '/usr/src*' -or -path '/usr/doc*' -or -path '/usr/tmp*' -or -path '/var*' -or -path '/usr/ports*' -or -path '*.snap' \) -and ! -ctime 1h Then determine whether they should be deleted by inspection. I wouldn't do this automatically (at least at first, until you've had a chance to debug your check), as a handful of ports ( perl5, etc. ) place files or links in the base system that should not be removed, and you may have local modifications. mergemaster(8)'s diagnostic messages should help you determine which files in /etc are no longer needed. b. ___ 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/p5-Net-Twitter broken
andrew clarke pisze: I'll attempt a PR, but I'm not at all competent enough in Perl to be confident in providing a patch. I was not refering to patching Perl code, rather that supplying new port and a little modification to net/p5-Net-Twitter/Makefile in a patch format (diff). I filled a PR ports/137305. I have to wonder - why have these recent versions of this port been committed but not tested? If it was tested, presumably it would be flagged as BROKEN. No. The port builds properly, it's just missing some functionality because of missing dependency. This is something automatic checks couldn't catch, and this is what a port maintainer should notice. But, things like this do happen. But isn't the rationale of the Ports tree to have buildable, working software? Yes, that's why when you have noticed and verified that the problem exists you should fill in a PR. Even though you can't supply a patch to fix it you would let the maintainer know. -- Cezary Morga ___ 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
ports/*/jpeg Thanks a lot guys
Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. -- 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: recent change to ifconfig breaks OpenVPN?
Am 31.07.2009 um 14:38 schrieb Stefan Bethke: Here's a first draft at a patch for OpenVPN. With this, the tun interface gets set to IFF_BROADCAST mode. One small piece is still missing: OpenVPN tries to install a route for the subnet, but that fails because now ifconfig has already inserted that route. I'll try to look into that a bit later on. I also haven't tested the server side yet, or any other mode. The route for the subnet is pushed by the server (expanded from the -- server config option). Although adding the route fails, the connection process continues and the connection is working fine. Making either the client ignore the pushed route or the server not push the route would be rather intrusive, so I think leaving it at this should be acceptable. Will continue testing... Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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/*/jpeg Thanks a lot guys
On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ 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: Dropping maintainership for sysutils/zfs-snapshot-mgmt
On Tue, Jul 28, 2009 at 11:36:45AM +0200, Marius Nünnerich wrote: 2009/7/28 Marcin Simonides mar...@studio4plus.com: Hello, I am the maintainer and author of zfs-snaphot-mgmt port - a crude (and a bit buggy) script for automatic snapshot creation and removal on ZFS. Since I am no longer using FreeBSD I cannot keep neither the port nor the script itself up-to-date. If someone, preferably one of the users, would like to take over the script and/or the port please contact me off the list. -- Marcin Simonides I'll take it. Thanks for your good work so far! I'm using it hourly ;) Thanks for the work you put in the port, Marcin. I just passed its maintainership to Marius. Lars pgpu5t0P2WFJU.pgp Description: PGP signature
diablo-jdk with FreeBSD-8.0
I am running a very recent amd64 version of FreeBSD-8.0. diablo-jdk is no longer working. I am guessing it is the bumped shared library versions (because I did do make delete-old-libs as part of my installation). My guess is that the problem will be solved when a version 8.0 of diablo-jdk comes out, and I was inquiring about an ETA. Thanks, Stephen ___ 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/*/jpeg Thanks a lot guys
On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson ertr1...@student.uu.se wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. Yes, but how can you tell if there is newer version? The pkg_version and pkgversion don't tell you that it's PORTREVISION or actually newer version. What about when we run 'port* -a'? Took about two weeks to get PORTREVISION bump isn't right at all. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@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: diablo-jdk with FreeBSD-8.0
Stephen Montgomery-Smith stephen at missouri.edu wrote: I am running a very recent amd64 version of FreeBSD-8.0. diablo-jdk is no longer working. I am guessing it is the bumped shared library versions (because I did do make delete-old-libs as part of my installation). Yes, this came up earlier. libmap.conf(5) is your friend here, until an update. Or you can try building java/openjdk6, but that takes some time and resources. My guess is that the problem will be solved when a version 8.0 of diablo-jdk comes out, and I was inquiring about an ETA. I think you are right, but I have seen no announcement. Did you ask on freebsd-java@, or email gle...@? b. ___ 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 with FreeBSD-8.0
On Fri, Jul 31, 2009 at 6:21 PM, Stephen Montgomery-Smithstep...@missouri.edu wrote: I am running a very recent amd64 version of FreeBSD-8.0. diablo-jdk is no longer working. I am guessing it is the bumped shared library versions (because I did do make delete-old-libs as part of my installation). I was bitten by this snake a few hours ago. Solved it by creating a /etc/libmap.conf with # echo libz.so.4 libz.so.5 /etc/libmap.conf That allowed it to run well enough to bootstrap the building of jdk 1.5: # cd /usr/ports/java/jdk15 # make install Then I deleted Diablo with # pkg_delete diablo\* I built jdk 1.5 because I need it, but I guess you can build jdk 1.6. My guess is that the problem will be solved when a version 8.0 of diablo-jdk comes out, and I was inquiring about an ETA. So I guess. -- My preferred quotation of Robert Louis Stevenson is You cannot make an omelette without breaking eggs. Not because I like the omelettes, but because I like the sound of eggs being broken. ___ 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 with FreeBSD-8.0
Carlos A. M. dos Santos wrote: On Fri, Jul 31, 2009 at 6:21 PM, Stephen Montgomery-Smithstep...@missouri.edu wrote: I am running a very recent amd64 version of FreeBSD-8.0. diablo-jdk is no longer working. I am guessing it is the bumped shared library versions (because I did do make delete-old-libs as part of my installation). I was bitten by this snake a few hours ago. Solved it by creating a /etc/libmap.conf with # echo libz.so.4 libz.so.5 /etc/libmap.conf Thank you. That worked very well. ___ 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/*/jpeg Thanks a lot guys
On Fri, Jul 31, 2009 at 2:53 PM, Jeremy Messenger me...@cox.net wrote: On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson ertr1...@student.uu.se wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. Yes, but how can you tell if there is newer version? The pkg_version and pkgversion don't tell you that it's PORTREVISION or actually newer version. What about when we run 'port* -a'? Took about two weeks to get PORTREVISION bump isn't right at all. Yes it does. If the version numbers are the same, but the _X number is different, then it's a PORTREVISION change only. 2.4.1_1 vs 2.4.1_2 is a port revision bump. 2.4.1_1 vs 2.4.2 is a version change. X.Y.Z are the PORTVERSION. _A is the PORTREVISION ,B is the PORTEPOCH Giving a total version string of X.Y.Z_A,B -- Freddie Cash fjwc...@gmail.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: ports/*/jpeg Thanks a lot guys
On Fri, 31 Jul 2009 16:53:16 -0500 Jeremy Messenger me...@cox.net wrote: On Fri, 31 Jul 2009 12:36:36 -0500, Erik Trulsson ertr1...@student.uu.se wrote: On Fri, Jul 31, 2009 at 12:12:49PM -0400, Jason J. Hellenthal wrote: Now that I have finally upgraded my system in full from the last mix-up with jpeg, You guys have bumped up every PORTREVISION that depends on jpeg Great real great Now I get to spend another three days fixing up some more packages and rebuilding about 800+ ports. Thanks a whole lot. Nobody is forcing you to rebuild your ports just because the PORTREVISION was bumped. If everything works fine for you there is actually no good reason at all to do so. So now the implication becomes that everyone should resort to manual checking of port versions and upgrade each port manually from here on out ?. Because if that is going to happen then eventually someone or a amateur for that matter is going to manually check their ports and come across an update they need and then it will update hand-in-hand every port that depends on libjpeg just to satisfy itself. Am I wrong ? is this not why portupgrade and portmaster were created so this could be done autonomously ? Don't get me wrong but I have been very involved in this upgrade that slipped into my systems from the 19th and it is frustrating when a rather circumvented actions consequences were not well thought out and gets repeated again for a third time. Please don't take this as a list bash or a personal matter, but I believe this needs to be discussed so it could be prevented in the future. Maybe a policy change on library bumps ? that gets more developers involved so the process is less likely to cause administration overhead. Or a policy stating that if your ports lib is bumped you should also bump all PORTREVISIONS that depend on it at the time it is committed ?. That is up for discussion and these are only thoughts but they are thoughts with a new user community in mind. Best regards. I am not on this list: please CC me in your replies. Yes, but how can you tell if there is newer version? The pkg_version and pkgversion don't tell you that it's PORTREVISION or actually newer version. What about when we run 'port* -a'? Took about two weeks to get PORTREVISION bump isn't right at all. Cheers, Mezz -- me...@cox.net - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org Thanks Mezz -- 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
