Re: Direct or indirect libdependencies (using the libintl.so.8 case)
Quoting Alex Dupre a...@freebsd.org (from Mon, 07 Jun 2010 16:35:13 +0200):
Alexander Leidinger ha scritto:
The best solution would be to fix the ports to not link explicitely to
indirect deps (by improving libtool and by improving the .pc files
for pkg-config). Then we could even switch from recording indirect
dependencies in /var/db/pkg/port-version/+{CONTENTS,REQUIRED_BY} to
only record direct deps.
How hard is it? What prevents us in doing it? Later we modify libtool
upstream, later we could switch to record only direct dependencies.
You should talk with the libtool maintainer about libtool.
Regarding the pkg-config stuff: you just have to determine which libs
are direct and which are indirect deps for a specific port, move the
indirect one into Libs.private, and then convince the upstream
maintainers to pick up this change.
Bye,
Alexander.
--
This is supposed to be a happy occasion.
Let's not BICKER and ARGUE over who killed who!
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: Direct or indirect libdependencies (using the libintl.so.8 case)
Alexander Leidinger ha scritto: How hard is it? What prevents us in doing it? Later we modify libtool upstream, later we could switch to record only direct dependencies. You should talk with the libtool maintainer about libtool. Ah, you were all waiting for me to talk to libtool maintainer, you could tell me before :-) Regarding the pkg-config stuff: you just have to determine which libs are direct and which are indirect deps for a specific port, move the indirect one into Libs.private, and then convince the upstream maintainers to pick up this change. These are all simple steps. You haven't answered to What prevents us in doing it? If we haven't already done it, I bet there is a reason. -- Alex Dupre ___ 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 looking for maintainer
Hello folks, recently, I have less time for ports as I'm working on othr items, like GSOC, so today I've reviewed my maintained ports and dropped some of them that I don't want to maintain any more. If you want to have any of them, please feel free to pick up. Regards, Gabor Mensaje original Asunto: cvs commit: ports/archivers/bsdar Makefile ports/audio/gnuitar Makefile ports/devel/opencvs Makefile ports/dns/pdnsd Makefile ports/security/p5-Crypt-CFB Makefile ports/security/p5-Crypt-Ctr Makefile ports/security/p5-Crypt-DES_PP Makefile ... Fecha: Tue, 8 Jun 2010 07:31:58 + (UTC) De: Gabor Kovesdan ga...@freebsd.org Para: ports-committ...@freebsd.org, cvs-po...@freebsd.org, cvs-...@freebsd.org gabor 2010-06-08 07:31:58 UTC FreeBSD ports repository Modified files: archivers/bsdar Makefile audio/gnuitarMakefile devel/opencvsMakefile dns/pdnsdMakefile security/p5-Crypt-CFB Makefile security/p5-Crypt-Ctr Makefile security/p5-Crypt-DES_PP Makefile security/p5-Crypt-GOST Makefile security/p5-Crypt-GPG Makefile security/p5-Crypt-HCE_MD5 Makefile security/p5-Crypt-Khazad Makefile security/p5-Crypt-License Makefile security/p5-Crypt-Lite Makefile security/p5-Crypt-Loki97 Makefile security/p5-Crypt-MySQL Makefile security/p5-Crypt-SKey Makefile security/p5-Crypt-Salt Makefile security/p5-Crypt-Shark Makefile security/p5-Crypt-X509 Makefile security/p5-Digest-CRC Makefile security/p5-Digest-Crc32 Makefile security/p5-Digest-DJB Makefile security/p5-Digest-Elf Makefile security/p5-Digest-FNV Makefile security/p5-Digest-JHash Makefile security/p5-Digest-MD5-File Makefile security/p5-Digest-MD5-Reverse Makefile security/p5-Digest-ManberHash Makefile security/p5-Digest-Pearson Makefile security/p5-Digest-Pearson-PurePerl Makefile security/p5-Digest-Perl-MD4 Makefile security/p5-Digest-Perl-MD5 Makefile security/p5-Digest-SHA-PurePerl Makefile security/p5-Digest-SV1 Makefile textproc/europass-xsl Makefile textproc/uml2svg Makefile Log: - Drop maintainership Revision ChangesPath 1.7 +1 -1 ports/archivers/bsdar/Makefile 1.13 +1 -1 ports/audio/gnuitar/Makefile 1.2 +1 -1 ports/devel/opencvs/Makefile 1.25 +1 -1 ports/dns/pdnsd/Makefile 1.5 +1 -1 ports/security/p5-Crypt-CFB/Makefile 1.5 +1 -1 ports/security/p5-Crypt-Ctr/Makefile 1.5 +1 -1 ports/security/p5-Crypt-DES_PP/Makefile 1.5 +1 -1 ports/security/p5-Crypt-GOST/Makefile 1.8 +1 -1 ports/security/p5-Crypt-GPG/Makefile 1.5 +1 -1 ports/security/p5-Crypt-HCE_MD5/Makefile 1.6 +1 -1 ports/security/p5-Crypt-Khazad/Makefile 1.6 +1 -1 ports/security/p5-Crypt-License/Makefile 1.7 +1 -1 ports/security/p5-Crypt-Lite/Makefile 1.6 +1 -1 ports/security/p5-Crypt-Loki97/Makefile 1.6 +1 -1 ports/security/p5-Crypt-MySQL/Makefile 1.8 +1 -1 ports/security/p5-Crypt-SKey/Makefile 1.5 +1 -1 ports/security/p5-Crypt-Salt/Makefile 1.6 +1 -1 ports/security/p5-Crypt-Shark/Makefile 1.8 +1 -1 ports/security/p5-Crypt-X509/Makefile 1.8 +1 -1 ports/security/p5-Digest-CRC/Makefile 1.5 +1 -1 ports/security/p5-Digest-Crc32/Makefile 1.6 +1 -1 ports/security/p5-Digest-DJB/Makefile 1.7 +1 -1 ports/security/p5-Digest-Elf/Makefile 1.6 +1 -1 ports/security/p5-Digest-FNV/Makefile 1.7 +1 -1 ports/security/p5-Digest-JHash/Makefile 1.10 +1 -1 ports/security/p5-Digest-MD5-File/Makefile 1.5 +1 -1 ports/security/p5-Digest-MD5-Reverse/Makefile 1.6 +1 -1 ports/security/p5-Digest-ManberHash/Makefile 1.5 +1 -1 ports/security/p5-Digest-Pearson-PurePerl/Makefile 1.6 +1 -1 ports/security/p5-Digest-Pearson/Makefile 1.6 +1 -1 ports/security/p5-Digest-Perl-MD4/Makefile 1.5 +1 -1 ports/security/p5-Digest-Perl-MD5/Makefile 1.17 +1 -1 ports/security/p5-Digest-SHA-PurePerl/Makefile 1.7 +1 -1 ports/security/p5-Digest-SV1/Makefile 1.2 +1 -1 ports/textproc/europass-xsl/Makefile 1.4 +1 -1 ports/textproc/uml2svg/Makefile ___ 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
unable to infer tagged configuration
A lot of ports currently break with spaces in CC, e.g. audio/flac or multimedia/libtheora, they seem to be using gnome-libtool: if /bin/sh /usr/local/bin/libtool --mode=compile env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc -DHAVE_CONFIG_H -I. -I. -I../..-DFLaC__INLINE=__inline__ -DNDEBUG -I../.. -I./include -I../../include -I/usr/obj/mobileKamikaze.norad/amd64/usr/ports/audio/flac/work/flac-1.2.1/include -I/usr/local/include -I/usr/local/include -Wall -W -O2 -pipe -march=nocona -fno-strict-aliasing -MT bitwriter.lo -MD -MP -MF .deps/bitwriter.Tpo -c -o bitwriter.lo `test -f 'bitwriter.c' || echo './'`bitwriter.c; then mv -f .deps/bitwriter.Tpo .deps/bitwriter.Plo; else rm -f .deps/bitwriter.Tpo; exit 1; fi libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' *** Error code 1 libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' *** Error code 1 *** Error code 1 3 errors *** Error code 1 1 error *** Error code 1 1 error *** Error code 1 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/audio/flac. ___ 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: OpenArena 0.8.5 port
On 24/05/2010 16:10, Robert Noland wrote: Dominic Fandrey wrote: For those of you interested in playing OpenArena on FreeBSD, I submitted a patch to games/openarena and a shar for OAX (OpenArena Xpanded): http://www.freebsd.org/cgi/query-pr.cgi?pr=146818 Unfortunately I'm not the maintainer so there's no saying if and when this will be committed, so I recommend to apply the patches yourself. Have fun fragging! Great work, if this doesn't get committed fairly soon, let me know and I'll prod someone. I requested a maintainer time out. Regards! ___ 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: unable to infer tagged configuration
Dominic Fandrey ha scritto: A lot of ports currently break with spaces in CC, e.g. audio/flac or multimedia/libtheora, they seem to be using gnome-libtool: Have you rebuilt libtool after changing CC ? -- Alex Dupre ___ 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: unable to infer tagged configuration
On 08/06/2010 09:48, Alex Dupre wrote: Dominic Fandrey ha scritto: A lot of ports currently break with spaces in CC, e.g. audio/flac or multimedia/libtheora, they seem to be using gnome-libtool: Have you rebuilt libtool after changing CC ? They're not using libtool from the ports, but come with their own libtool. You can add audio/speex archivers/rpm to the list. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: unable to infer tagged configuration
On 08/06/2010 09:56, Dominic Fandrey wrote: On 08/06/2010 09:48, Alex Dupre wrote: Dominic Fandrey ha scritto: A lot of ports currently break with spaces in CC, e.g. audio/flac or multimedia/libtheora, they seem to be using gnome-libtool: Have you rebuilt libtool after changing CC ? They're not using libtool from the ports, but come with their own libtool. This is not true for all of them. But the problem remains that they pass CC on to libtool without escaping spaces. I will report this upstream to Xiph.org, because all their ports seem to do this. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: unable to infer tagged configuration
On 08/06/2010 09:48, Alex Dupre wrote:
Dominic Fandrey ha scritto:
A lot of ports currently break with spaces in CC, e.g. audio/flac
or multimedia/libtheora, they seem to be using gnome-libtool:
Have you rebuilt libtool after changing CC ?
OK, I'm sorry about the noise, though I rebuilt libtool I had an
exception for it in my make.conf.
I wonder why the ports pass CC to libtool if that is ignored
anyway.
To avoid this hazzle in the future I changed my /usr/local/bin/libtool
From
LTCC=env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc
to
LTCC=${CC:-env CCACHE_PREFIX=/usr/local/bin/distcc /usr/local/bin/ccache cc}
Regards
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: HEADS UP: devel/gettext upgrade incoming
On 05/28/10 17:47, Ade Lovett wrote: Hi folks, After a little bit of a hiatus, I'm baaack ;) First up on the line is an upgrade of devel/gettext to 0.18, which also bumps the shlib version from .7 to .8 -exp run ran just fine (thanks to pav), so now it's merely a question of PORTREVISION bumps, which will most likely take the form of those ports that have a direct dependency on gettext, though this may not cover everything (as usual) I plan on doing two commits in the not-too-distant future, the first to bump gettext itself, the second to bump PORTREVISION on anything that has a direct USE_GETTEXT or devel/gettext (ick) dependency. This should cover most things, but as with all things gettext, it's entirely possible that stuff will break as a result. Ya'll take care now, y'hear? One question: _ now gimp wants gir-repository-libsoup; _ portupgrade -RN gir-repository-libsoup installs gir-repository-libsoup, but does not upgrade anything else; _ in fact gir-repository-libsoup has no dependencies; _ however, I get: /usr/bin/ld: warning: libintl.so.8, needed by /usr/local/lib/libsoup-2.4.so, may conflict with libintl.so.9; _ pkg_which /usr/local/lib/libsoup-2.4.so gives libsoup; _ so gir-repository-libsoup seems to depend on libsoup. Should this dependency be made explicit? bye Thanks av. P.S. 7.2/i386 ___ 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: Direct or indirect libdependencies (using the libintl.so.8 case)
Quoting Alex Dupre a...@freebsd.org (from Tue, 08 Jun 2010 09:33:04 +0200): Alexander Leidinger ha scritto: How hard is it? What prevents us in doing it? Later we modify libtool upstream, later we could switch to record only direct dependencies. You should talk with the libtool maintainer about libtool. Ah, you were all waiting for me to talk to libtool maintainer, you could tell me before :-) Correct, sorry about not tellung you before. :) I can tell you that he will not accept local modifications, which more or less comes down to testing it yourself and let others test it too, and then to convince the libtool authors to include it (maybe there is something we are not aware about, which prevents this). Regarding the pkg-config stuff: you just have to determine which libs are direct and which are indirect deps for a specific port, move the indirect one into Libs.private, and then convince the upstream maintainers to pick up this change. These are all simple steps. You haven't answered to What prevents us in doing it? If we haven't already done it, I bet there is a reason. The subset of people which knew about the problem before was very small (me and IIRC pav@, maybe others too I do not know about). The subset of people which have time and interest to do something about this was the empty subset... Now the number of people which know about it is bigger. Time will tell if the subset of people which do something about it is non-empty now... Bye, Alexander. -- You will reach the highest possible point in your business or profession. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Direct or indirect libdependencies (using the libintl.so.8 case)
Alexander Leidinger ha scritto: Now the number of people which know about it is bigger. Time will tell if the subset of people which do something about it is non-empty now... I think the first step could be to run a tinderbox build with a patched libtool and see if anything break. Then, if the patch is simple, we could add a target to patch ports using bundled libtool and see again if anything break on tinderbox. What do you think? -- Alex Dupre ___ 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: Manually registering dependencies for ports
On Mon, 07 Jun 2010 18:04:37 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2010 17:34:39, RW wrote: If it's a metaport then it does have an origin. It certainly needs an origin if some other port is going to depend on it. Which is usually the case for metaports, but not necessarily so. A metaport is a port and has an origin by definition. What you are referring to is a metapackage. ___ 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: Manually registering dependencies for ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2010 12:36:33, RW wrote: On Mon, 07 Jun 2010 18:04:37 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 07/06/2010 17:34:39, RW wrote: If it's a metaport then it does have an origin. It certainly needs an origin if some other port is going to depend on it. Which is usually the case for metaports, but not necessarily so. A metaport is a port and has an origin by definition. What you are referring to is a metapackage. Right. So the 'meta' nature is irrelevant, and you might as well say if it's a port, then it has an origin: otherwise, it's a package. That makes sense. Quite a lot of sense really, although I think most people don't think quite so precisely about such things. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwONL4ACgkQ8Mjk52CukIxZyACdEcA7IIy1zm5IPAV/RpbCLsFj V2UAn2KJXIZSlsZ73tDzfKIQknocLXFd =ef8h -END PGP SIGNATURE- ___ 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: Direct or indirect libdependencies (using the libintl.so.8 case)
Quoting Alex Dupre a...@freebsd.org (from Tue, 08 Jun 2010 12:06:51 +0200): Alexander Leidinger ha scritto: Now the number of people which know about it is bigger. Time will tell if the subset of people which do something about it is non-empty now... I think the first step could be to run a tinderbox build with a patched libtool and see if anything break. Then, if the patch is simple, we could add a target to patch ports using bundled libtool and see again if anything break on tinderbox. What do you think? I found some message I exchanged on the libtool list regarding this in 2007. I do not know the current state (libtool 2.2.6b) of this, but someone with a little bit of time can check via the testcase which is described in the mail at: http://thread.gmane.org/gmane.comp.gnu.libtool.general/8500/focus=8501 When this testcase does not rise a problem, your approach sounds good. Bye, Alexander. -- By the time they had diminished from 50 to 8, the other dwarves began to suspect Hungry ... -- Gary Larson, The Far Side http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Direct or indirect libdependencies (using the libintl.so.8 case)
Alexander Leidinger ha scritto: When this testcase does not rise a problem, your approach sounds good. For the reference, these are the debian patches to libtool: http://ftp.de.debian.org/debian/pool/main/libt/libtool/libtool_1.5.26-4+lenny1.diff.gz -- Alex Dupre ___ 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: Manually registering dependencies for ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2010 08:53:53, Matthew Seaman wrote: So, you're creating your own meta-port that exists only to be depended on by the ports you specifically want to have installed? That's a really good idea. You might need to fill out the contents of your wanted-ports meta-port a bit more, but the concept seems sound to me. Actually, I thought this was a good enough idea that I had a go at implementing it. My first cut at doing this is available at: http://www.infracaninophile.co.uk/wanted-ports.shar What do people think? Unless this meets with utter horror or there are some horrendous bugs, I'll tidy it up, add a man page and submit it as a new port in a week or so. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwORVYACgkQ8Mjk52CukIzwegCaAhV/gRXkKLkjD7627SrkJGho hJ0AnjNI9kVYN8h4xVgg9gtq9XO+JeRT =lygQ -END PGP SIGNATURE- ___ 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
Recent updates cause firefox3 to crash on fbsd8
Hello, I think some upgrades to some of the graphics libraries in ports have something to do with causing firefox3 (most recent version) to crash. After updating some ports, firefox throws a sig 11 right when I try to bring up a pull-down menu from the menu bar or the bookmark bar. Rebuilding firefox doesn't seem to help and the stack trace on the core file suggests that the problem occurs in firefox's libxul, but I could be reading it wrong. More later, but hope that helps somewhat. Andrew Lankford ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: security/tor and WITH_OPENSSL_PORT=yes
On Mon, 7 Jun 2010 19:24:36 + b. f. bf1...@googlemail.com wrote: Why we need uncoditional WITH_OPENSSL_PORT=yes in security/tor? It builds fine on 8-stable with base system openssl. Moreover this setting isn't needed on -CURRENT because openssl 1.0 is in base system. May be it should be removed from port's Makefile? You are right that it no longer should be unconditional, but not that it should be removed altogether. Remember, although you may be running a recent version of 8-stable, with openssl 0.9.8n, others may still be using older, but still supported, versions of the FreeBSD, with older base system openssl. And, as far as I know, openssl 1.0 is _not_ in the base system, even in -CURRENT. We are still at 0.9.8n. Anyway, I think Martin planned to fix this, now that __FreeBSD_version has been bumped after some recent changes. Before anyone decides to fix this, they should keep in mind that the port needs not only to build correctly, but to *run* correctly. tor built with openssl 1.0.0 builds just fine on 7.3-STABLE, but definitely does not work in relay mode. Clients and other relays attempt to connect to it, but no data packets ever get through, and the connections are soon closed. Because of this, tor's self-reachability testing fails, so it never publishes a descriptor. After the update from openssl 0.9.8n, a version that had worked just fine, came through, I had to install portdowngrade and use it to get back from openssl 1.0.0 to openssl 0.9.8n in order to get tor to work properly again. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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
[HEADSUP] ports feature freeze starts soon
In preparation for 8.1-RELEASE, the ports tree will be in feature freeze after release candidate 1 (RC1) is released, currently planned for June 11. If you have any commits with high impact planned, get them in the tree before then and if they require an experimental build, have a request for one in portmgr@ hands within the next few days. Note that this again will be a feature freeze and not a full freeze. Normal upgrade, new ports, and changes that only affect other branches will be allowed without prior approval but with the extra Feature safe: yes tag in the commit message. Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr@ after that date. Thomas with portmgr-secretary@ hat on -- Thomas Abthorpe | FreeBSD Ports Management Team Secretary tabtho...@freebsd.org | portmgr-secret...@freebsd.org pgpv0DCoxauL4.pgp Description: PGP signature
Re: security/tor and WITH_OPENSSL_PORT=yes
On 6/8/10, Scott Bennett benn...@cs.niu.edu wrote: On Mon, 7 Jun 2010 19:24:36 + b. f. bf1...@googlemail.com wrote: Why we need uncoditional WITH_OPENSSL_PORT=yes in security/tor? It builds fine on 8-stable with base system openssl. Moreover this setting isn't needed on -CURRENT because openssl 1.0 is in base system. May be it should be removed from port's Makefile? You are right that it no longer should be unconditional, but not that it should be removed altogether. Remember, although you may be running a recent version of 8-stable, with openssl 0.9.8n, others may still be using older, but still supported, versions of the FreeBSD, with older base system openssl. And, as far as I know, openssl 1.0 is _not_ in the base system, even in -CURRENT. We are still at 0.9.8n. Anyway, I think Martin planned to fix this, now that __FreeBSD_version has been bumped after some recent changes. Before anyone decides to fix this, they should keep in mind that the port needs not only to build correctly, but to *run* correctly. tor built with openssl 1.0.0 builds just fine on 7.3-STABLE, but definitely does not work in relay mode. Clients and other relays attempt to connect to it, but no data packets ever get through, and the connections are soon closed. Because of this, tor's self-reachability testing fails, so it never publishes a descriptor. After the update from openssl 0.9.8n, a version that had worked just fine, came through, I had to install portdowngrade and use it to get back from openssl 1.0.0 to openssl 0.9.8n in order to get tor to work properly again. Then a change to allow the use of base system openssl on some versions of the OS should make your life a little bit easier. Information about run-time failures is just the kind of feedback that you should be providing to Martin, because I don't think his testing includes the full range of conditions under which tor is used. Speaking for myself, when I submit an update, I am content if tor builds and installs cleanly, passes the bundled regression tests (with one known exception), and works as a client. We need more information from people like you to fix problems. 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
