Re: ports/119546
On 5/11/13, Andrea Venturoli m...@netfence.it wrote:
On 05/10/13 15:50, b.f. wrote:
...
Here's what I did:
# find /usr/ports -type f -exec grep -l OPENSS_PORT {} ;
This showed very few ports really requiring openssl from ports, none of
which I had currently installed.
Then the simplest and safest solution for you is just to remove
security/openssl, if you don't think that you'll need it.
So I moved its libraries to /usr/local/lib/compat/pkg/ and pkg_deleted
(-f) it. Newer compilations would pick up base, then.
You may also need to move the security/openssl headers out of
${LOCALBASE}/include/openssl, to prevent ports from mistakenly using
them.
...
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: ports/119546
Andrea wrote: ... I had a look at /usr/ports/net/openldap23-server/Makefile and only found: USE_OPENSSL=yes AFAICT this does not give any preference wrt to base vs port openssl; if I'm correct this means the port is choosen if installed, but, otherwise, openssl from base is used. Wouldn't it be better to use base only? Put a knot to give the user a choice? Would I screw too many things if I tried adding: WITH_OPENSSL_BASE=yes Yes, because then the additions to the check-depends target in ports/Mk/bsd.openssl.mk would cause unsandboxed builds of the port on a live system to fail when security/openssl is installed. Adding WITH_OPENSSL_BASE to port Makefiles should be avoided for this reason. 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: ports/119546
On 5/10/13, Andrea Venturoli m...@netfence.it wrote:
On 05/10/13 14:32, b.f. wrote:
Would I screw too many things if I tried adding:
WITH_OPENSSL_BASE=yes
Yes, because then the additions to the check-depends target in
ports/Mk/bsd.openssl.mk would cause unsandboxed builds of the port on
a live system to fail when security/openssl is installed. Adding
WITH_OPENSSL_BASE to port Makefiles should be avoided for this reason.
Thanks for the answer, but I don't quite get this. Do you have any
pointer for docs I can study?
I don't think so, other than the ports Makefiles. With regard to
bsd.openssl.mk, I was referring to:
59 .if defined(WITH_OPENSSL_BASE)
,,,
73 .if exists(${LOCALBASE}/lib/libcrypto.so)
74 check-depends::
75 @${ECHO_CMD} Dependency error: this port wants the
OpenSSL library from the FreeBSD
76 @${ECHO_CMD} base system. You can't build against it,
while a newer
77 @${ECHO_CMD} version is installed by a port.
78 @${ECHO_CMD} Please deinstall the port or undefine
WITH_OPENSSL_BASE.
79 @${FALSE}
80 .endif
What's the purpose/usefulness of WITH_OPENSSL_BASE, then?
I'm afraid that it is not very useful, for the many people that use
security/openssl. We had hoped that it would work as originally
intended, but we found that many ports sloppily change the library
search paths for linking, so if security/openssl is installed, many
ports link to the libraries of the openssl port rather than the base
system openssl, even if WITH_OPENSSL_BASE is set. So the restrictive
checks in bsd.openssl.mk were added to prevent these kinds of
problems, even if they aren't needed in every specific case.
Is there another simple solution?
You can try to work around the problem by not using USE_OPENSSL, but
instead adding the openssl dependencies, link line and rpath
additions, etc. in the port Makefile. A number of ports used to do
this, for various reasons. However, this should only be done when
necessary, to prevent the proliferation of ad hoc methods of using
openssl in the ports tree, which makes maintenance more difficult.
A real solution (probably as good a solution as we can arrive at
without investing a lot more time in patching many different ports, or
fundamentally changing the way that we handle linking) would be to
change the openssl port and bsd.openssl,mk to install the
security/openssl libraries in a location other than ${LOCALBASE}/lib
(as in the parallel case of the compiler support libraries used by the
lang/gcc* ports that conflict with some base system libraries), so
that it would be more difficult to accidentally link to them, and so
the -L and -rpath directives in bsd.openssl.mk would have fewer
unintended side effects. Then some of the restrictive checks in
bsd.openssl.mk could be relaxed.
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: WANTED: Tool to verify installed package/port consistancy
Ronald wrote: ... It occurs to me that *something*, i.e. some tool(s) within the FreeBSD panoply, *must* already be reading and/or otherwise making use of those MD5 checksums within the +CONTENTS files. Otherwise, why would they even be there? So my question really comes down to this: What pre-existing software tools are available that can and do check the MD5 checksums, as given the the +CONTENTS file(s), of various files associated with some given installed port or package? ... Yes, of course, this is a basic package management feature: pkg_info(1) with the -g flag. (The analogous part of the newer pkgng is described in pkg-check(8) from ports-mgmt/pkg.) 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: Ocaml ports needs love
I received a lot of complaint about ocaml being in a bad shape: lang/ocaml being outdated, lots of ocaml ports not being carefully maintained and updated. I personnally know nothing about ocaml so I'm not able to actually be helpful to improve the situation, I would love to see people taking the task of cleaning up the situation, bringing up ocaml ports to newer version. Probably creating a ocaml@ team would be a good idea? Have these people been talking to the maintainers, or those responsible for outstanding PRs? Because I've only had two inquiries in the past several months. There were a few delays as maintainership passed from stas to new volunteers, the pre-release freeze was drawn-out, some upstream bugs were fixed, and while other changes (like tcl/tk) were made. But I expect that the new ocaml will be done soon (right after an update of lablgtk2) , and Michael Grunewald has been active. An ocaml alias and mailing list might help at least for the unmaintained ports, and as a place for discussions. 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: 7+ days of dogfood
On 2/13/13, Anton Shterenlikht me...@bristol.ac.uk wrote:
From s...@troutmask.apl.washington.edu Wed Feb 13 03:40:53 2013
On Wed, Feb 13, 2013 at 02:15:08AM +, b.f. wrote:
On 2/13/13, Steve Kargl s...@troutmask.apl.washington.edu wrote:
On Wed, Feb 13, 2013 at 12:18:29AM +, b.f. wrote:
# cat /etc/make.conf|grep FFLAGS
FFLAGS = -O2 -pipe -march=native -mtune=native
Please do _not_ assign flags unconditionally in make.conf.
FFLAGS is for compiling Fortran. I'm one of the people who
has spent years working/patching gfortran. I think I might
have a better understanding of what options to use with
gfortran than most people.
I know you have, but you are giving advice that is liable to be abused
by those who are less experienced. The flags you are adding are not
the problem -- it's the way that you are adding them -- specifically,
the assignment in the first line of your snippet, if it's applied
unconditionally. You should either be appending all of them, or
assigning them conditionally, so that they are sure to be assigned
only once, or -- preferably -- using another makefile that can't be
re-read multiple times during a build (ports/Mk/bsd.port.mk
automatically includes several makefiles that can be used for this
purpose, if you are building a port). You have been lucky not to trip
over this: every couple of months for the last several years I have
had to debug errors reported by users that arise from this problem. It
is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS,
too.
Try 'find /usr/ports -name Makefile -maxdepth 3 | xargs grep FFLAGS'
Then go read about the options chosen by the various port maintainers.
I specifically set FFLAGS to avoid the questionable options set in
the ports. If -malign-double appears in a port, it should probably
be marked as broken. If a port uses -fdefault-real-8, it should
probably
be marked as broken. If a port uses -ffast-math, it may have issues
that
are extremely difficult to debug.
(I removed freebsd-current@ and added cc to ports@)
Oi vey. I see, it is complicated.
So on the one hand some options are
risky or just wrong and must not be used.
On the other there is a large number of ports,
which might not even build if this is implemented,
and convincing upstream that they are wrong
is never easy.
Is there a middle ground?
What about appending the suggested options
to FFLAGS in ports/MK/bsd.port.mk?
Or will it make debugging ports with questionable
options even harder?
By all means, adjust our conservative default flags if you want to
improve the performance of some ports or other software -- only be
sure to test the results. Dr. Kargl has given you some good
candidates. But I'd advise you to add to the flags once at the start
of a build, and to deal with flag changes in a port or other piece of
software that you think are unnecessary and problematic by patching
the software itself. (If the software uses gmake or adds problematic
flags and then uses them before it invokes make(1) again you won't be
able to deal with them in make.conf, anyway.) It's probably best to
use a makefile that was intended for this purpose, like
${PORTSDIR}/Mk/bsd.local.mk. (Or, If you still prefer make.conf, you
could make the flag alterations there, but conditionally -- you could
test .CURDIR, for example, to prevent your changes from being
reapplied if you have descended into a work directory. But using
another makefile would probably be better.)
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: how to move 9.1 ports to HEAD?
On 2/8/13, Anton Shterenlikht me...@bristol.ac.uk wrote: From bf1...@googlemail.com Fri Feb 8 17:33:09 2013 I don't think it's true. While still on 9.1 ports, the latest entry in UPDATING was (well I lost it now) about NOV-2012. I believe the revision was also substantially lower. AS soon as I switched to head, the latest entry in UPDATING is from 6-FEB-2013 and the revision is 311942. Or maybe I misunderstood you? You do. :-) The local _subversion repository_ (I know I'm using incorrent terminology) has a revision number: r##. Which is the same across different versions of FreeBSD. The individual ports _maintained within that repository_ have their individual ports numbers (e.g. libreoffice-3.6.5) ... which also does not vary with the FreeBSD release. One can have libreoffice-3.6.5 and libreoffice 3.5.4 - but those are two separate ports and both work (or should) on 8.3, 9.1, and -CURRENT. If a port has a minimum (or maximum) release of the OS it supports, there a mechanism for figuring that out and DTRT. Or did I misunderstand you? Yes, it is now branched, and he was probably using the equivalent of: http://svnweb.FreeBSD.org/ports/branches/RELENG_9_1_0/ rather than http://svnweb.FreeBSD.org/ports/head/ By the way, Anton, you may wish to use https:// rather than svn:// -- slightly less efficient, but more secure. yes, got it, cool! root@zzz:/root # svn info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn0.us-east.freebsd.org/ports/head Repository Root: https://svn0.us-east.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 311950 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 311950 Last Changed Date: 2013-02-08 19:18:40 + (Fri, 08 Feb 2013) root@zzz:/root # Does svn://svn.freebsd.org/base/head support https too? Apparently, yes. 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: how to move 9.1 ports to HEAD?
On 2/8/13, Kimmo Paasiala kpaas...@gmail.com wrote: On Fri, Feb 8, 2013 at 10:45 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Fri, Feb 8, 2013 at 10:17 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: From bf1...@googlemail.com Fri Feb 8 17:33:09 2013 I don't think it's true. While still on 9.1 ports, the latest entry in UPDATING was (well I lost it now) about NOV-2012. I believe the revision was also substantially lower. AS soon as I switched to head, the latest entry in UPDATING is from 6-FEB-2013 and the revision is 311942. Or maybe I misunderstood you? You do. :-) The local _subversion repository_ (I know I'm using incorrent terminology) has a revision number: r##. Which is the same across different versions of FreeBSD. The individual ports _maintained within that repository_ have their individual ports numbers (e.g. libreoffice-3.6.5) ... which also does not vary with the FreeBSD release. One can have libreoffice-3.6.5 and libreoffice 3.5.4 - but those are two separate ports and both work (or should) on 8.3, 9.1, and -CURRENT. If a port has a minimum (or maximum) release of the OS it supports, there a mechanism for figuring that out and DTRT. Or did I misunderstand you? Yes, it is now branched, and he was probably using the equivalent of: http://svnweb.FreeBSD.org/ports/branches/RELENG_9_1_0/ rather than http://svnweb.FreeBSD.org/ports/head/ By the way, Anton, you may wish to use https:// rather than svn:// -- slightly less efficient, but more secure. yes, got it, cool! root@zzz:/root # svn info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn0.us-east.freebsd.org/ports/head Repository Root: https://svn0.us-east.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 311950 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 311950 Last Changed Date: 2013-02-08 19:18:40 + (Fri, 08 Feb 2013) root@zzz:/root # Does svn://svn.freebsd.org/base/head support https too? Thanks Anton Just to repeat what others have tried to tell you. The ports tree is NOT branched. The branches/RELENG_9_1_0 thing is a tag in subversion terminology, a read only-snapshot of head from the time the release was made that will never be updated. -Kimmo Actually I'm talking slightly rubbish here, the tags are in the tags/* part of the repository, for example http://svn.freebsd.org/ports/tags/RELEASE_9_1_0. The branches/RELENG_9_1_0 thing is a proper branch but since there's no announcement of what it should used for I would guess it's someone's test branch. Yes, it's a branch -- or a copy, I suppose, in subversion terms. I believe it was used to generate the package set for the 9.1 release. There probably won't be any future changes to it, but people can use it, as Anton apparently did. 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: Removal of Portmanager
Mark wrote: On Wed, Jan 16, 2013 at 01:51:39AM +, RW wrote: Reports are sent to ports@ every 2 weeks. And I wonder how many people read carefully through all 478 entries. And your suggestion is ... ? Try ports/ports-mgmt/portupdate-scan. 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: Removal of Portmanager
On Wed, Jan 16, 2013 at 08:48:37AM +, b.f. wrote: Mark wrote: On Wed, Jan 16, 2013 at 01:51:39AM +, RW wrote: Reports are sent to ports@ every 2 weeks. And I wonder how many people read carefully through all 478 entries. And your suggestion is ... ? Try ports/ports-mgmt/portupdate-scan. portupdate-scan displays pertinent entries from /usr/ports/UPDATING. How does that help you digest long lists posted on a mailing list? Obviously, it can't: I misunderstood the original complaint. If portupdate-scan is parsing MOVED and UPDATING, it can help notify users of port removals before they update their packages, but not before the ports are removed. If users have an up-to-date ports tree in PORTSDIR, they can use something simple like: pkg_info -qoa | xargs -I @ grep -le EXPIRATION_DATE $PORTSDIR/@/Makefile to find which of their installed packages are likely to be removed, with obvious variations to list all DEPRECATED ports, etc. If they don't have a ports tree, they can use: http://portsmon.freebsd.org/portsconcordanceforexpiring.py 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: print/acroreadwrapper and gcc 4.6.3 ISSUE
Building for acroreadwrapper-0.0.20110920 Warning: Object directory not changed from original /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110920 @ - /usr/src/sys machine - /usr/src/sys/i386/include x86 - /usr/src/sys/x86/include gcc46 -O2 -pipe -march=pentium4 -mtune=pentium4 -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -march=pentium4 -mtune=pentium4 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c linux_adobe.c cc1: error: unrecognized command line option '-mno-align-long-strings' cc1: error: unrecognized command line option '-fformat-extensions' *** Error code 1 Stop in /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110920. *** Error code 1 Stop in /usr/ports/print/acroreadwrapper. But gcc 4.2+ works fine. It seems that all the *kmod* ports/parts have 4.2 'origin' and can't be properly compiled with higher versions of gcc or clang. They use base system makefiles to build the kernel modules, which use various kernel flags, including some FreeBSD-specific ones, for consistency. You can override CWARNFLAGS from kern.mk, but you should be careful when mixing toolchains for kernel modules. You are going to find a lot of ports that fail to build with non-default toolchains. If you can suggest small, reasonable changes that make it possible to do so, then submit PRs. 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: Shared library version bump policy suggestion to track these bumps formally
Lev wrote:
Now, when some port after update installs new version of shared
library, used by other ports, here are two variants:
(a) To bump versions of all dependant ports (PORTREVISION=${PORTREVISION} +
1)
(b) Don't touch other ports, but add copy'n'pasted item into
UPDATING with instructions for users of portmaster, portupgrade
and binary pkg-ng packages.
Question is: which way is better? Why sometimes first way is selected
and sometimes second one? Is here any policy to select between them
in different cases?
You're always supposed to do (a), for those default packages that must
be rebuilt because of the change -- whether because of a shared
library version change, or something else.
(b) is only as a reminder for those users that have non-default
packages that may need to be rebuilt, or as a stopgap in an emergency
-- it is not supposed to replace (a). It is usually used when someone
failed to notice that a large number of ports link to a shared
library, but that shared library is not in the LIB_DEPENDS of those
ports, because it is in the LIB_DEPENDS of a port that those port
depends upon (if you want to reopen the debate about whether this
non-redundant dependency accounting is the right thing to do, that may
be worthwhile), and needs to alert users while the problematic ports
are being fixed. It is often a sign that an exp-run should have been
requested, but wasn't.
Personally, I don't like both ways.
First one is error-prone for maintainer: dependency could be
optional and turned off by default, for example.
Then a PORTREVISION bump isn't necessary, but an UPDATING note may be advisable.
Second one is error-prone for users. And, to be honest, I don't
like when formal task is performed by hands. All these records in
UPDATING is copy'n'pasted with replacement of port name, receipt of
upgrading is always the same (yes, I know, that there are more
difficult scenarios in UPDATING too, I don't speak about them now).
Why this receipt should be performed by user, not by tool!?
There are some ways to refine the updating process -- like, for
example, lstewart@'s:
https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh
There is certainly room for improvement in the standard tools here.
But some ports may need to be rebuilt for reasons other than shared
library changes, which may be difficult to detect automatically in
every case.
I suggest to have new variable in port's Makefile: BORDER_VERSIONS
or something like this. Let it will be list of port's versions, when
shared libs are updated and all dependent ports should be rebuild
too.
Then, portmaster/portupgrade could add forced updates to queue
automatically (like with portmaster -r port / portupgrade -fr
port) if port cross (inclusive) one of versions from this list.
Something like this:
BORDER_VERSIONS=0.48 0.65 1.0_1
And if port is updated to version 0.48 or higher from
version STRICTLY LESS than 0.48 (and same for 0.65 and 1.0_1), all
ports, which uses this library, will be rebuild too.
This has some advantages, but how would it be used efficiently by the
package-building clusters, in the absence of PORTREVISION bumps? And
for end users, is BORDER_VERSIONS better, in most cases, than
improving the package-updating tools to perform automatic checks
during partial updates, as in lstewart@'s script? -- how would
BORDER_VERSIONS overcome the existing problems in dependency
accounting that I mentioned above, without forcing unnecessary
rebuilds?
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: Status of ports update submitted 2 months ago
Michael wrote: Dear FreeBSD community, 2 months ago I submitted four port updates related to the ocaml/language. The PRs used to be listed by portsmon but I recently noticed they disappeared. [1] How can I help to let these changes go into our ports tree? The four PRs are 2012/11/04ports/173362devel/ocaml-calendar Update to 2.03.2 2012/11/04ports/173364*lang/ocaml Update to 4.00.1 2012/11/07ports/173438*lang/tuareg-mode.el 2012/11/07ports/173453*graphics/ocaml-images Update to 4.0.1 I didn't see these -- I'll try to resolve at least 173364 and 173453. I think portsmon has some problems with PR links since the disruption of services following the security breach, but the PRs should still be in the database. The ports tree was partially frozen for a while before the release of 9.1, and some of these couldn't have been handled during that period. 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
