textproc/elasticsearch2 Update to 2.1.1
Is there a committer that can take a look at this update. It includes Poudriere QA logs, and I can verify that it builds correctly in my environment ( 10.2-RELEASE-p10). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206107 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: textproc/elasticsearch2 Update to 2.1.1
Understood. I'm trying to follow the protocol of submit bug, then ask on freebsd-ports, and only after those two, ping the maintainer directly. On Sun, Jan 24, 2016 at 5:33 PM, Walter Schwarzenfeld < w.schwarzenf...@utanet.at> wrote: > It is a maintained port. It needs approval from the maintainer. > ___ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: New pkg audit / vuln.xml failures (php55, unzoo)
On Fri, May 29, 2015 at 5:15 PM, Robert Simmons rsimmo...@gmail.com wrote: On Thu, May 28, 2015 at 12:47 PM, Bryan Drewery bdrew...@freebsd.org wrote: I think the VUXML database needs to be simpler to contribute to. Only a handful of committers feel comfortable touching the file. We have also had the wrong pervasive mentality by committers and users that the vuxml database should only have an entry if there is a committed fix. This is totally wrong. These CVE are _already public_ in all of these cases. Users deserve to know that there is a known issue with a package they have installed. I can understand how the mentality grew to what it is with some people, but the fact that there is not an update doesn't change that the user's system is insecure and needs to be dealt with. If the tool can't reliably report issues then it is not worth trusting. TL;DR; the file needs to be simpler. I know there is an effort to use CPE but I'm not too familiar with where it is going. As for maintainers tracking upstream mailing lists, this is hard. I'm subscribed to a lot of lists and can't keep up with all of the traffic. The RedHat security team and reporting is very impressive. Don't forget that they are a funded company though. Perhaps the FreeBSD Foundation needs to fund a fulltime security officer that is devoted to both Ports and Src. Just the Ports piece is easily a fulltime job. It seems from this thread that we have a group of people who are passionate enough about fixing this problem. How do we find out who the members of the Ports Secteam are? Once we know that, I'd say that at least some of the people on this thread are willing to join the Ports Secteam (myself included). How do we join the team? Once the team has new and energized members, I would envision the team then working through the problems that have been outlined in this thread and putting together a plan for fixing them. Crickets. May I ask again: How do we find out who the members of the Ports Secteam are? How do we join the team? ___ 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
Update to security/libsodium
I just opened a bug that includes a patch to update libsodium. Can someone who uses this port, please QA this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200548 ___ 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: New pkg audit / vuln.xml failures (php55, unzoo)
On Thu, May 28, 2015 at 12:47 PM, Bryan Drewery bdrew...@freebsd.org wrote: I think the VUXML database needs to be simpler to contribute to. Only a handful of committers feel comfortable touching the file. We have also had the wrong pervasive mentality by committers and users that the vuxml database should only have an entry if there is a committed fix. This is totally wrong. These CVE are _already public_ in all of these cases. Users deserve to know that there is a known issue with a package they have installed. I can understand how the mentality grew to what it is with some people, but the fact that there is not an update doesn't change that the user's system is insecure and needs to be dealt with. If the tool can't reliably report issues then it is not worth trusting. TL;DR; the file needs to be simpler. I know there is an effort to use CPE but I'm not too familiar with where it is going. As for maintainers tracking upstream mailing lists, this is hard. I'm subscribed to a lot of lists and can't keep up with all of the traffic. The RedHat security team and reporting is very impressive. Don't forget that they are a funded company though. Perhaps the FreeBSD Foundation needs to fund a fulltime security officer that is devoted to both Ports and Src. Just the Ports piece is easily a fulltime job. It seems from this thread that we have a group of people who are passionate enough about fixing this problem. How do we find out who the members of the Ports Secteam are? Once we know that, I'd say that at least some of the people on this thread are willing to join the Ports Secteam (myself included). How do we join the team? Once the team has new and energized members, I would envision the team then working through the problems that have been outlined in this thread and putting together a plan for fixing them. ___ 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
databases/py-sqlite3 Fails To Install
This port is failing to install at the moment. Is there a bug in autoplist? I've opened the following bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199021 Using make makeplist seems to work around this problem, but is suboptimal. ___ 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
www/spawn-fcgi IPv6 Bugfix
Greetings, Is there a committer available to review and commit the following. I have approved the patch: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198483 ___ 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: www/nginx-devel Name Change
Also, I don't believe that bugs in new features has the same meaning as development. On Sat, Mar 7, 2015 at 1:46 AM, Robert Simmons rsimmo...@gmail.com wrote: Here is a quote from the NGINX project: Which version should I use? In general, you should deploy the NGINX mainline branch at all times. You may wish to use stable if you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the introduction of bugs in new features. From this and checking the source code repository here: hg.nginx.org/nginx the development branch is default. Perhaps the -devel port should be tied to a specific date on the true development branch? I am only interested in calling a spade a spade here to reduce confusion. If the NGINX project called mainline development there wouldn't be a problem. But it seems that this is a distinction that FreeBSD has decided rather than using upstream terminology and thinking. On Fri, Mar 6, 2015 at 11:02 PM, Sergey A. Osokin o...@freebsd.org wrote: Hi Robert, On Wed, Mar 04, 2015 at 04:52:58PM -0500, Robert Simmons wrote: The port www/nginx-devel should really be renamed nginx-mainline. It is definitely not the development branch as is explained by the upstream project. Calling it devel may cause users to avoid using this port over the www/nginx port. I have a detailed explanation of this in a bug report here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196480 Does this seem logical? Objection. The nginx project basically provides two versions of nginx: stable and mainline. New releases of the stable version contains bug and security fixes. The mainline usually introduces a bugs in a new features. This is why it has been marked with '-devel' suffix. For stable version FreeBSD ports tree historycally uses the same name as a software product has been named by author, for development version with '-devel' prefix. Also, I see no reason why user may cause to avoid using the www/nginx-devel port. Think it's always up to user to use or not to use any port from FreeBSD ports tree as well as FreeBSD operating system. -- Sergey A. Osokin o...@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: www/nginx-devel Name Change
Here is a quote from the NGINX project: Which version should I use? In general, you should deploy the NGINX mainline branch at all times. You may wish to use stable if you are concerned about possible impacts of new features, such as incompatibility with third-party modules or the introduction of bugs in new features. From this and checking the source code repository here: hg.nginx.org/nginx the development branch is default. Perhaps the -devel port should be tied to a specific date on the true development branch? I am only interested in calling a spade a spade here to reduce confusion. If the NGINX project called mainline development there wouldn't be a problem. But it seems that this is a distinction that FreeBSD has decided rather than using upstream terminology and thinking. On Fri, Mar 6, 2015 at 11:02 PM, Sergey A. Osokin o...@freebsd.org wrote: Hi Robert, On Wed, Mar 04, 2015 at 04:52:58PM -0500, Robert Simmons wrote: The port www/nginx-devel should really be renamed nginx-mainline. It is definitely not the development branch as is explained by the upstream project. Calling it devel may cause users to avoid using this port over the www/nginx port. I have a detailed explanation of this in a bug report here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196480 Does this seem logical? Objection. The nginx project basically provides two versions of nginx: stable and mainline. New releases of the stable version contains bug and security fixes. The mainline usually introduces a bugs in a new features. This is why it has been marked with '-devel' suffix. For stable version FreeBSD ports tree historycally uses the same name as a software product has been named by author, for development version with '-devel' prefix. Also, I see no reason why user may cause to avoid using the www/nginx-devel port. Think it's always up to user to use or not to use any port from FreeBSD ports tree as well as FreeBSD operating system. -- Sergey A. Osokin o...@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
www/nginx-devel Name Change
The port www/nginx-devel should really be renamed nginx-mainline. It is definitely not the development branch as is explained by the upstream project. Calling it devel may cause users to avoid using this port over the www/nginx port. I have a detailed explanation of this in a bug report here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196480 Does this seem logical? ___ 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: squid 3.5 plans
On Mon, Feb 23, 2015 at 5:41 PM, Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au wrote: Thank you so much for posting this link! Merging r275456 and r275502 from stable/10 to my releng/10.1 src tree and rebuilding and installing the kernel, means that I can once again manage squid 3.4.n via the rc.d script instead of a prescribed series of kill(1) commands. Back to the original question: lets drop 3.3x and only support 3.4/3.5 in ports. ___ 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: squid 3.5 plans
On Thu, Feb 19, 2015 at 7:13 PM, Nick Rogers ncrog...@gmail.com wrote: On Thu, Feb 19, 2015 at 6:46 AM, Robert Simmons rsimmo...@gmail.com wrote: According to the Squid website: Provided for archival purposes only. Not intended for general use in new installations. This is marking all versions of Squid except 3.5 http://www.squid-cache.org/Versions/ I would recommend removing all the older unsupported versions except 3.5. I agree, although it looks like www/squid was just updated to 3.4.12. https://svnweb.freebsd.org/ports?view=revisionrevision=379384 That is true. It looks like an update to both 3.5 and 3.4 were released on the same day. How about dropping www/squid33 and creating a www/squid34 port. Then updating the www/squid port to 3.5.2. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: squid 3.5 plans
According to the Squid website: Provided for archival purposes only. Not intended for general use in new installations. This is marking all versions of Squid except 3.5 http://www.squid-cache.org/Versions/ I would recommend removing all the older unsupported versions except 3.5. On Wed, Feb 18, 2015 at 8:50 PM, Nick Rogers ncrog...@gmail.com wrote: It seems that squid 3.5 is becoming the latest recommended production quality version. Squid 3.4.12 and 3.5.2 were just released today. What is everyones thought (or the maintainers plan) on moving the www/squid port from 3.4 to 3.5? It looks like the www/squid33 port has been kept around past its ideal expiration date because of an issue with ntlm_auth affecting squid 3.4. This bug has been fixed in the latest 3.4 and 3.5 release. http://bugs.squid-cache.org/show_bug.cgi?id=3997 So is the idea to now move the www/squid port to 3.5, or create yet another squid port of www/squid35 because we want to keep 3.4 as the stable version for a while. I am just wondering because I would like to move my production environment from squid 3.4 to 3.5, and am happy to contribute patches to the ports tree, but am not sure what the plans are. Thanks. -Nick ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ 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
databases/sqlite3: update port to 3.8.8.2
The port maintainer has approved my update patch. Is there a committer available to look this over and commit? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197285 ___ 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
devel/ccache
Is there a plan to update the devel/ccache port? The new version has improved clang support. ___ 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: x11-servers/xorg-vfbserver depends on x11/xkeyboard-config
On Mon, Dec 29, 2014 at 1:50 PM, John D. Hendrickson johnandsa...@cox.net wrote: Robert Simmons wrote: When I start Xvfb it fails with the following error: XKB: Failed to compile keymap It appears that xvfb now requires xkeyboard-config. After installing x11/xkeyboard-config everything works as expected. I wanted to modify the port to add this dependency, but I wanted to make sure it is correct. I looked in the /usr/ports/Mk/bsd.xorg.mk and did not see this port listed to add it to the USE_XORG= line in the Makefile. In this case, should this be set in RUN_DEPENDS= ? check your dependancy list, you missed a package you want :) gmiX has dep list, here's part of it: xev-1.1.0 xgamma-1.0.4 xhost-1.0.4 xinput-1.5.3 xkbcomp-1.2.0 xkbevd-1.1.2 xkbutils-1.0.3 intltool-0.33 xkeyboard-config-1.4 xkbdata-1.0.1 xkill-1.0.3 xlsatoms-1.1.0 xlsclients-1.1.1 Please pardon my ignorance, but I don't see gmiX in bsd.xorg.mk either. Should I add xkeyboard-config to the port's RUN_DEPENDS? ___ 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
x11-servers/xorg-vfbserver depends on x11/xkeyboard-config
When I start Xvfb it fails with the following error: XKB: Failed to compile keymap It appears that xvfb now requires xkeyboard-config. After installing x11/xkeyboard-config everything works as expected. I wanted to modify the port to add this dependency, but I wanted to make sure it is correct. I looked in the /usr/ports/Mk/bsd.xorg.mk and did not see this port listed to add it to the USE_XORG= line in the Makefile. In this case, should this be set in RUN_DEPENDS= ? ___ 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
devel/libffi and lang/python34
The default for lang/python34 is to use libffi from ports. The version in ports is getting old (v3.0.13). The current version is v3.2.1. However, the version that ships with python 3.4.2 is 3.1. Should the default for python34 be changed to use the included version (v3.1)? ___ 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/libffi and lang/python34
I think the best option is AC: to remove libffi from python and to update our port. The config choice itself can then be removed from the python port. On Thu, Dec 25, 2014 at 11:37 PM, Kubilay Kocak ko...@freebsd.org wrote: On 26/12/2014 3:06 PM, Robert Simmons wrote: The default for lang/python34 is to use libffi from ports. The version in ports is getting old (v3.0.13). The current version is v3.2.1. However, the version that ships with python 3.4.2 is 3.1. Should the default for python34 be changed to use the included version (v3.1)? ___ 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 I'd like to see: a) The libffi port updated b) libffi *not* be the default for Python ports We prefer to be as close to upstream as possible. c) See upstream Python not bundle libffi at all iirc, there's been mentions upstream of ripping libffi out in the past, perhaps its worth re-starting that conversation koobs ___ 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 that don't actually support Python 3.x
Beautiful Soup 3.x is Python 2.x only. From the website: Beautiful Soup 3 works only under Python 2.x. http://www.crummy.com/software/BeautifulSoup/ On Sun, Jul 6, 2014 at 3:56 PM, Melvyn Sopacua mel...@magemana.nl wrote: Hello, I'm coming accross a few ports that are in the tree as we speak, that do not actually install correctly with Python 3.x but aren't marked as 2.7 only. There seems to be 2 cases: 1. incompatibility in setup.py or related, thus failing in configure 2. incompatibility in the code itself, thus failing in byte_compile The ones in 2 fail with PYDISTUTILS_AUTOPLIST in install, because the files cannot be compiled and thus are missing when using the plist. I've got a few in PRs, few in the queue to become PR's, but perhaps a broader effort is needed? I'm willing to help, if an exp-run or something similar would generate a list. PS: A common error is: `except Exception, var:`. This can probably be fixed with a REINPLACE_CMD that can be standardized, but so far, bringing the port up-to-date with upstream fixes the problem (notable exception being www/py-beautifulsoup32). -- Melvyn ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Python 2.7.7
Is there an ETA for updating the python27 port to 2.7.7? ___ 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
Python 2.7.7
Is there an ETA for updating the python27 port to 2.7.7? ___ 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: squid-3.4
Not sure what the plans are, but I'm interested in the new version as well. On Mon, Mar 24, 2014 at 9:02 AM, Adri Koppes ad...@salesmanager.nl wrote: Dear Sir, I was wondering if there are any plans to support squid 3.4.x via FreeBSD ports soon? Version 3.4.x adds support for TPROXY and intercept using FreeBSD or OpenBSD, which I would really like to use. At the moment, there is no alternative to 'transparent' or 'intercept' connections when using IPV6. Best regards, Adri Koppes ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-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: GSSAPI and Heimdal in Base
Actually both port and base are 1.5.2. Base was updated in Apr 2012: http://svnweb.freebsd.org/base?view=revisionrevision=234027 Both 9.x and 10.0 have Heimdal 1.5.2, same version in ports. The Heimdal project's current stable version is actually 1.5.3. They have forgotten to update their main website, but the Git repository speaks the truth: https://github.com/heimdal/heimdal/blob/master/NEWS Also, they are pushing out 1.6 release candidates at the moment, so I think 1.6 should arrive shortly. I will give the project a poke and see if they can update their website, but security/openssh-portable should build fine against heimdal base or the heimdal port since they are identical. On Mon, Feb 17, 2014 at 7:43 AM, Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au wrote: Robert, There's a couple of versions different. Heimdal from ports is 1.5.2. I'm writing personally because I don't build any systems with the heimdal in base, but I recall it being around 1.0.1 on 9.X. As an aside I recall the openssh developer mentioning somewhere that gssapi wasn't supported in openssh 6.5, but if it builds for you then you're probably running an earlier version of the ports system? It's also helpful to let folks know what FreeBSD version you're discussing ;) Cheers, Dewayne On 17/02/2014 5:14 PM, Robert Simmons wrote: When building openssh-portable, and enabling kerb_gssapi, but using the heimdal that is in base, it gives the error: KERB_GSSAPI Requires either MIT or HEMIDAL, does not build with base Heimdal currently What is the difference between base and the port of Heimdal? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
GSSAPI and Heimdal in Base
When building openssh-portable, and enabling kerb_gssapi, but using the heimdal that is in base, it gives the error: KERB_GSSAPI Requires either MIT or HEMIDAL, does not build with base Heimdal currently What is the difference between base and the port of Heimdal? ___ 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: Growing list of required(ish) ports
On Tue, Apr 9, 2013 at 12:48 PM, Florent Peterschmitt flor...@peterschmitt.fr wrote: Le mardi 09 avril 2013 à 06:09 -0700, Darren Pilgrim a écrit : On 2013-04-08 10:22, Florent Peterschmitt wrote: Yep, OpenSSH is tiny enought to keep it in base system. It would be a big loss not to have it by default, securely installed in the base system. I really wish it wasn't. Having OpenSSH (and thus OpenSSL) in the base means FreeBSD has an outdated version installed by default. You have to install openssl from ports in order to have modern cipher support, TLS v1.1/1.2, DTLS, etc. This puts two sets of openssl libs on the system and creates recurrent headaches with builds where the autoconfiguration selects the wrong set of libs. Hum, I didn't thought about that. So I think it would be possible to have a secondary « branch » for the distribution including something like « special ports » which can be retrieved, built and managed (for porters) quickly. Anybody think something like that is relevant and possible to do ? One thing to note is that these parts of base are kept just about as up-to-date as ports over in the HEAD branch. In the case of OpenSSH, HEAD is way way more up to date than ports. These changes are also fairly quickly MFC'd over to stable. The real hiccup is that these changes don't dribble out of freebsd-update. ___ 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: Growing list of required(ish) ports
On Tue, Apr 9, 2013 at 1:11 PM, Florent Peterschmitt flor...@peterschmitt.fr wrote: Le mardi 09 avril 2013 à 13:03 -0400, Robert Simmons a écrit : Hum, I didn't thought about that. So I think it would be possible to have a secondary « branch » for the distribution including something like « special ports » which can be retrieved, built and managed (for porters) quickly. Anybody think something like that is relevant and possible to do ? One thing to note is that these parts of base are kept just about as up-to-date as ports over in the HEAD branch. In the case of OpenSSH, HEAD is way way more up to date than ports. These changes are also fairly quickly MFC'd over to stable. The real hiccup is that these changes don't dribble out of freebsd-update. I see. So you suggest to use -STABLE ? Because -RELEASE is aimed to stay as frozen (I mean stable and secured) as possible, it makes sens not to have updates. No, stable is just another type of development branch. It is not meant for production use. I'm suggesting that enough testing and QA be applied to certain updates to be able to offer them as part of freebsd-update. Not sure if this is even possible. It may go against the philosophy of RELEASE and it would require resources that are in short supply as is. ___ 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: Growing list of required(ish) ports
On Mon, Apr 8, 2013 at 1:11 AM, Kevin Oberman rkober...@gmail.com wrote: On Sun, Apr 7, 2013 at 8:34 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Mon, Apr 8, 2013 at 6:19 AM, Robert Simmons rsimmo...@gmail.com wrote: On Sun, Apr 7, 2013 at 10:45 PM, Bryan Drewery bdrew...@freebsd.org wrote: On 4/7/2013 8:47 PM, Robert Simmons wrote: Are there plans to get the following ports moved into HEAD? 1) ports-mgmt/pkg 2) ports-mgmt/dialog4ports 3) ports-mgmt/portaudit 4) ports-mgmt/portmaster It seems to me like these belong in the base system. On the contrary, the idea is that more and more should come *out of base* and into ports. Base is very static and stuck in time. By moving these things into ports, you are able to get updates much simpler. No need for an errata or security advisory or release. Just updating with portmaster/pkg upgrade. I understand where you're coming from, but perhaps there needs to be movement in both directions. I may be way off the mark here, but I'd love to spark a discussion about this. I think that in general things that are directly FreeBSD projects belong in base. Examples would be pkgng, and making dialog4ports a switch in dialog(1). Essentially, code that does not have an upstream should be in base. On the other hand, there are a number of things that I think should be pulled out of base. Some already have ports, and others would need ports created. Examples of things to pull out of base are OpenSSL, Heimdal, OpenSSH, PF, ntpd, ipfilter, bind, sendmail, and others. Code that is typically way behind the upstream project basically. portaudit is not needed with pkg, just use 'pkg audit'. I had missed that. Thanks! Also, is there a reason why dialog4ports's functionality wasn't added to dialog(1) as a switch? -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ I think Bryan already explained the reasons why pkg should not be in base, it's an external tool that is not strictly required to get a bare bones FreeBSD system up and running. Including it in base you create yet another maintainance burden and would slow down the development of the ports/packages management tools. -Kimmo What people seem to miss is that putting tools into the base system strangles the tools. Look at the difficulty we have seen in updating openssl. perl was removed from base for exactly that reason. Once something is in base, it usually can only be updated on major releases and even then it can be very complicated. That is a problem for any dynamically changing tool. I would love to see BIND removed from base, but most of the things you listed really are hard to remove. I know that I don't want to try bringing up a new install of FreeBSD on a remote system without OpenSSH and that OpenSSH is the only one that doesn't follow the same pattern. It seems that the port of it has been abandoned going on 2 years. It is lagging far far behind 9-stable which looks like DES bumped to 6.1 and HEAD has been bumped to 6.2p1. pulls in openssl. In the case of many tools, it really turns into a bikeshed. But i can see no reason to add any of the new packaging tools simply because it is critical that updates be possible far more often than is possible for the base system. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@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
Growing list of required(ish) ports
Are there plans to get the following ports moved into HEAD? 1) ports-mgmt/pkg 2) ports-mgmt/dialog4ports 3) ports-mgmt/portaudit 4) ports-mgmt/portmaster It seems to me like these belong in the base system. Also, is there a reason why dialog4ports's functionality wasn't added to dialog(1) as a switch? ___ 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: [CFT] New dialog for ports
I'm getting the same error after the most recent portsnap update. It looks like this has been added as a default for all make config commands now. Perhaps these changes should be backed out so it's not the default for everything? On Tue, Mar 19, 2013 at 10:39 PM, Steve Wills swi...@freebsd.org wrote: On 03/14/13 09:55, Baptiste Daroussin wrote: Hi all, Ilya A. Arkhipov wrote dialog4ports which has just been added into the ports tree ports-mgmt/dialog4ports, this is intended to be a replacement for dialog(1) designed specifically for the options, in particular for optionsng. It uses libdialog (recent version) and extend it with a new widget able to deal with both normal and radio options in the same window. dialog4ports will live forever in ports so that it can easily be updated and get support for new features on all supported arches at the same time. It bundles libdialog on FreeBSD versions that doesn't have a recent libdialog in base (read 8.x) dialog4ports also support a new feature: it has a help dialog to be able to print a human readable help text if possible. Here is a patch to the ports tree that makes it use dialog4ports by default. What it does is: When make config is requested and dialog4ports is not installed yet the ports tree will install dialog4ports first. New feature for maintainer, if a pkg-help file is found inside the port directory then dialog will show to the user a help file is available et propose him to hint F1 or ^E to show the said help file http://people.freebsd.org/~bapt/d4p.diff Please test! I didn't get a chance to test this before it was committed, but I'm currently running into this: % pwd /usr/local/tinderbox/portstrees/FreeBSD/ports/www/apache22 % sudo make config dialog4ports isn't installed, do you want to install it now? [Y/n] n env: /usr/local/bin/dialog4ports: No such file or directory === Options unchanged % And I'm prompted every time. Is this how it's supposed to work? Steve ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
QT4 Port Installing Too Many Deps
I'm trying to install the quassel port with only the quassel core not
any of the client components. I'm running into two problems:
1) Even when I specify the CORE only make option, make still tries to
install absolutely everything related to qt4 and X11, the whole
kitchen sink. This is the line in the makefile and it seems like this
port is disobeying this:
.if ${PORT_OPTIONS:MCORE}
USE_QT4+= network script sql sql-sqlite3_run
2) There is no make config option to disable NLS, even though it is
listed as an option in the makefile:
.if ${PORT_OPTIONS:MNLS}
USE_QT4+= linguist_build
How can I install this port without installing all of qt4 and x11 etc etc etc?
___
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: Python libraries moved
Ports tree updated, but it is still a problem. I don't see anything
that was checked in recently that mentions this problem.
On Sun, Mar 3, 2013 at 1:10 AM, Martin Wilke m...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Mar 03, 2013 at 12:08:41AM -0500, Robert Simmons wrote:
It looks like a port revision made a few hours ago has broken firefox
(and most likely a bunch of other ports). In the makefile for
firefox, it has the following checks for dependencies:
BUILD_DEPENDS= nspr=4.9.4:${PORTSDIR}/devel/nspr \
nss=3.14.1:${PORTSDIR}/security/nss \
sqlite3=3.7.14.1:${PORTSDIR}/databases/sqlite3 \
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3 \
As you can see, it looks for _sqlite3.so in ${PYTHON_SITELIBDIR} which
points to the old location for this library. The revision to python
and its libraries has moved the location of these libraries to
lib-dynload
This is the revision in question:
http://svnweb.freebsd.org/ports?view=revisionrevision=313167
This has broken firefox and most likely all other ports that look for
libraries in ${PYTHON_SITELIBDIR}
This is fixed please update your portstree.
- - Martin
___
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
- --
+-oOO--(_)--OOo-+
With best Regards,
Martin Wilke (miwi_(at)_FreeBSD.org)
Mess with the Best, Die like the Rest
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlEy6WEACgkQdLJIhLHm/OlXlwCfRXWOPSk2cJ725IjYx9jeEy1+
Pb8AoL34Lr6ffYhsMeQgU8SreN8U6P4+
=3TVO
-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
Python libraries moved
It looks like a port revision made a few hours ago has broken firefox
(and most likely a bunch of other ports). In the makefile for
firefox, it has the following checks for dependencies:
BUILD_DEPENDS= nspr=4.9.4:${PORTSDIR}/devel/nspr \
nss=3.14.1:${PORTSDIR}/security/nss \
sqlite3=3.7.14.1:${PORTSDIR}/databases/sqlite3 \
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3 \
As you can see, it looks for _sqlite3.so in ${PYTHON_SITELIBDIR} which
points to the old location for this library. The revision to python
and its libraries has moved the location of these libraries to
lib-dynload
This is the revision in question:
http://svnweb.freebsd.org/ports?view=revisionrevision=313167
This has broken firefox and most likely all other ports that look for
libraries in ${PYTHON_SITELIBDIR}
___
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: Python libraries moved
Sorry, what was the change you made?
On Sun, Mar 3, 2013 at 1:10 AM, Martin Wilke m...@freebsd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Mar 03, 2013 at 12:08:41AM -0500, Robert Simmons wrote:
It looks like a port revision made a few hours ago has broken firefox
(and most likely a bunch of other ports). In the makefile for
firefox, it has the following checks for dependencies:
BUILD_DEPENDS= nspr=4.9.4:${PORTSDIR}/devel/nspr \
nss=3.14.1:${PORTSDIR}/security/nss \
sqlite3=3.7.14.1:${PORTSDIR}/databases/sqlite3 \
${PYTHON_SITELIBDIR}/_sqlite3.so:${PORTSDIR}/databases/py-sqlite3 \
As you can see, it looks for _sqlite3.so in ${PYTHON_SITELIBDIR} which
points to the old location for this library. The revision to python
and its libraries has moved the location of these libraries to
lib-dynload
This is the revision in question:
http://svnweb.freebsd.org/ports?view=revisionrevision=313167
This has broken firefox and most likely all other ports that look for
libraries in ${PYTHON_SITELIBDIR}
This is fixed please update your portstree.
- - Martin
___
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
- --
+-oOO--(_)--OOo-+
With best Regards,
Martin Wilke (miwi_(at)_FreeBSD.org)
Mess with the Best, Die like the Rest
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlEy6WEACgkQdLJIhLHm/OlXlwCfRXWOPSk2cJ725IjYx9jeEy1+
Pb8AoL34Lr6ffYhsMeQgU8SreN8U6P4+
=3TVO
-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
Build of firefox from ports does not finish
It ends with the following: gmake[5]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release/browser/app/profile/extensions' gmake[4]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release/browser/app' gmake[3]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release/browser' gmake[2]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release' gmake[1]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release' if test -d ./dist/bin ; then touch ./dist/bin/.purgecaches ; fi hg: not found sed: /usr/ports/www/firefox/work/mozilla-release/build/unix/*.pc: No such file or directory Any ideas as to what is causing this? ___ 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/openssh-portable line # 82 of rc.d/openssh generates DSA not ECDSA
On Sun, Jun 24, 2012 at 1:17 PM, J. Hellenthal jhellent...@dataix.net wrote: As stated in the subject if [ -f /usr/local/etc/ssh/ssh_host_ecdsa_key ]; then echo You already have a Elliptic Curve DSA host key \ in /usr/local/etc/ssh/ssh_host_ecdsa_key echo Skipping protocol version 2 Elliptic Curve DSA Key Generation else /usr/local/bin/ssh-keygen -t dsa \ -f /usr/local/etc/ssh/ssh_host_ecdsa_key -N '' fi Specifically /usr/local/bin/ssh-keygen -t dsa needs to be changed to -t ecdsa to be correct. Otherwise we are just reimplementing a DSA key in a different file. Good eye. I'm in the process of updating that port to 6.0p1. There are quite a lot of local patches that are part of the port. At the moment I'm muddling through what they do and whether they can be removed or not. I didn't even notice this problem. I've attached a pair of patches that correct this problem. Open a PR about this, and you can attach these patches to it. I'm not the maintainer nor do I have commit privileges, but if you open a PR, I'm sure someone will make the change. Makefile.diff Description: Binary data openssh.in.diff Description: Binary data ___ 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/openssh-portable line # 82 of rc.d/openssh generates DSA not ECDSA
On Sun, Jun 24, 2012 at 2:24 PM, J. Hellenthal jhellent...@dataix.net wrote: On Sun, Jun 24, 2012 at 01:46:20PM -0400, Robert Simmons wrote: On Sun, Jun 24, 2012 at 1:17 PM, J. Hellenthal jhellent...@dataix.net wrote: As stated in the subject if [ -f /usr/local/etc/ssh/ssh_host_ecdsa_key ]; then echo You already have a Elliptic Curve DSA host key \ in /usr/local/etc/ssh/ssh_host_ecdsa_key echo Skipping protocol version 2 Elliptic Curve DSA Key Generation else /usr/local/bin/ssh-keygen -t dsa \ -f /usr/local/etc/ssh/ssh_host_ecdsa_key -N '' fi Specifically /usr/local/bin/ssh-keygen -t dsa needs to be changed to -t ecdsa to be correct. Otherwise we are just reimplementing a DSA key in a different file. Good eye. I'm in the process of updating that port to 6.0p1. There are quite a lot of local patches that are part of the port. At the moment I'm muddling through what they do and whether they can be removed or not. I didn't even notice this problem. I've attached a pair of patches that correct this problem. Open a PR about this, and you can attach these patches to it. I'm not the maintainer nor do I have commit privileges, but if you open a PR, I'm sure someone will make the change. Should have also said the changes were already committed. I also want to see what can be pushed upstream. I understand that the OpenBSD/OpenSSH people are touchy about outside patches, but I think they should at least accept a patch to configure so that FreeBSD's native openpty() is detected properly. ___ 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: Skype 4.0
On Sat, Jun 16, 2012 at 2:02 AM, Waitman Gobble uzi...@da3m0n8t3r.com wrote: dude like since MS bought it they haven't even released any non-win32 version. i agree, a different alternative to skype is better, and get your contacts to join up with that. Huh? New in this version 4.0: http://www.skype.com/intl/en-us/get-skype/on-your-computer/linux/ ___ 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: Skype 4.0
On Sat, Jun 16, 2012 at 2:12 AM, Kevin Oberman kob6...@gmail.com wrote: You might look at ekiga. It is in ports and a standard part of Gnome. It does sip and also claims to support H.323 conferencing, but I have not had much success making it work with our H.323 system. I will admit that I have not tried in a while, though. I remember looking at Ekiga when I was trying out different SIP clients last year, and what turned me off is the gnome thing. I am a KDE user, so Blink being a qt application means it is a KDE camp application. ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 1:08 PM, Jerry je...@seibercom.net wrote: Skype 4.0 for Linux is now available. Is there any possibility of getting it ported to FreeBSD? The latest version in ports is only 2.x. I don't have time to do it right at the moment, but since this is pre-compiled binary software, updating the port yourself and sending the patches in with a PR would not be a complex task. I'm confident that you could do it. Start here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/quick-porting.html The URL for downloading the bugger is here: http://download.skype.com/linux/skype_static-4.0.0.7.tar.bz2 Good luck, and thanks in advance! ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 1:08 PM, Jerry je...@seibercom.net wrote: Skype 4.0 for Linux is now available. Is there any possibility of getting it ported to FreeBSD? The latest version in ports is only 2.x. One last thing. These are the files that you are going to want to patch: ports/net-im/skype/ If you've never used cvs before, it is trivially easy. Follow A.4.3 Examples in the handbook exactly, but replace ls with ports/net-im/skype/Makefile etc: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html You will also want to read 4.3. Attaching patches or files: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 5:11 PM, Rich Neese r.ne...@gmail.com wrote: I just wish skype would get off their buts and make a bsd version. time to break code and make a opensource version That's not the answer. Really, everyone needs to move away from Skype altogether. Use Blink. It is a superior client and it uses SIP rather than Skype's network. Making a FreeBSD port of it has been on my list of things to do for quite a while, I just haven't had the time. If you want to check it out you can find it here: http://devel.ag-projects.com/repositories/blink-qt/ It is written in Python, and it is GPL. There is a MacOS binary and a Windows binary download of it on their website. http://icanblink.com/index.phtml ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 6:06 PM, animelo...@gmail.com wrote: On 06/15/2012 05:25 PM, Robert Simmons wrote: On Fri, Jun 15, 2012 at 5:11 PM, Rich Neeser.ne...@gmail.com wrote: I just wish skype would get off their buts and make a bsd version. time to break code and make a opensource version That's not the answer. Really, everyone needs to move away from Skype altogether. Use Blink. It is a superior client and it uses SIP rather than Skype's network. Making a FreeBSD port of it has been on my list of things to do for quite a while, I just haven't had the time. If you want to check it out you can find it here: http://devel.ag-projects.com/repositories/blink-qt/ It is written in Python, and it is GPL. There is a MacOS binary and a Windows binary download of it on their website. http://icanblink.com/index.phtml __ Thanks for the intelligent answer, I could have not said anything better. Will look into SIP/Blink for a more secure alternative than skype... :-) Thanks! One more thing to note, since using SIP/Blink introduces the old problem of being the only person on Earth with a fax machine. Getting your linuxy friends to convert to FreeBSD may be impossible, but getting them to add Blink's repositories to their apt config is trivial since Blink runs their own Ubuntu PPA: http://www.ag-projects.com/projects-products-96/683-software-repositories ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 8:42 PM, Franci Nabalanci lum...@gmail.com wrote: No, the aswer is Skype still. Why? Because Skype use user of Windows 3.1 to Windows 7, MAC, Linux... How many people use FreeBSD? Does FreeBSD user comunicate just with the other FreeBSD user? Please reread my post to the list. I was describing an open source SIP client written in Python. It is not restricted to FreeBSD, it can run anywhere you like. You should modify what you said to How many other people have telephone numbers? And how many people use SIP? Otherwise what you asked doesn't make any sense. ___ 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: Skype 4.0
On Fri, Jun 15, 2012 at 9:59 PM, Darren Pilgrim list_free...@bluerosetech.com wrote: On 2012-06-15 14:25, Robert Simmons wrote: On Fri, Jun 15, 2012 at 5:11 PM, Rich Neeser.ne...@gmail.com wrote: I just wish skype would get off their buts and make a bsd version. time to break code and make a opensource version That's not the answer. Really, everyone needs to move away from Skype altogether. Use Blink. It is a superior client and it uses SIP rather than Skype's network. Making a FreeBSD port of it has been on my list of things to do for quite a while, I just haven't had the time. Skype supports video calls. According to AG Projects' website, Blink is a VoIP app with IM features added, no video. Is this not the case? I dislike video, so I have never even looked for that feature, but now that I'm looking, no it doesn't support video. I was curious, so I googled alternatives to Blink and I ran across Linphone. Has anyone used this? It exists in the FreeBSD ports collection, but is a few versions behind the current stable version from the project's website. ___ 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: port unmaintained since 2005? drop it? misc/gpt*
On Mon, Jun 11, 2012 at 2:33 AM, b. f. bf1...@googlemail.com wrote: On 6/11/12, Michael Scheidell scheid...@freebsd.org wrote: On 6/10/12 11:14 PM, b. f. wrote: The distribution files are at: ftp://ftp.ncsa.uiuc.edu/aces/gpt/releases and the homepage is: http://grid.ncsa.illinois.edu/gpt/ (And Globus is at: http://www.globus.org/toolkit/ ) Time to determine this: 1 min. b. glad to know you are volunteering to maintain these ports. I will resurrect globus from the archives (where it has been since 2008, see /usr/ports/MOVED), which email address do you want in the MAINTAINER= line? Heh, not so fast. I've got other things to do first. I was just pointing out that it is not so hard to correct some of the stale information, and it is useful to do this as a pointer to those who may wish to more actively maintain the port later, even if it is moved to the attic in a few months. I should add that globus comes with a bundled version of gpt, and I think the Debian port is based upon this -- it's at 3.6.x. Also, that brooks@, who was involved in adding this port and other related software, could probably tell you more about grid software. Well, there may be some users coming out of the woodwork for this port. I noticed the following vulnerability alert today: CVE-2012-3292 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3292 ___ 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: port unmaintained since 2005? drop it? misc/gpt*
On Mon, Jun 11, 2012 at 4:31 AM, per...@pluto.rain.com wrote: Michael Scheidell scheid...@freebsd.org wrote: Two unmaintained ports, nothing depends on them, and upstream has not updated source since 2004, ftp server unresponsive. http://www.freebsd.org/cgi/cvsweb.cgi/ports/misc/gpt31/Makefile (gpt32: misc/gpt also unmaintained since 2005. http://www.freebsd.org/cgi/cvsweb.cgi/ports/misc/gpt/Makefile ftp server mentioned doesn't respond (ftp.freebsd.org has distfile), upstream unmaintained since 2004, and upstream points to a different distfile (with different checksum and same version number), mentions an alpha version 4.0. These are originally from NCSA, but the website mentioned in the pkg-descr (http://www.gridpackagingtools.org/) now seems to be promoting some kind of diet/nutritional approach. The only connection to middleware that immediately comes to mind is that such sites tend to be frequented by those concerned about excessive weight around their middle :) Dunno what (if anything) they are currently good for, but it seems that, at a minimum, the PORTVERSION and/or MASTER_SITES -- and the pkg-descr -- need to be updated. I would have to think that that is a remnant of a project that is no longer running. The current owners of that domain are squatters: Registrant ID:DOT-SY49XY2F9J0P Registrant Name:Domain Admin Registrant Organization:Maripon Management, Inc. Registrant Street1:Office 2, 456-458 Strand Registrant Street2:WC2R 0DZ Registrant Street3: Registrant City:London Registrant State/Province:uk Registrant Postal Code:n/a Registrant Country:GB Registrant Phone:+44.12053169373 Registrant Phone Ext.: Registrant FAX: Registrant FAX Ext.: Registrant Email:supp...@internet-guide.biz ___ 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: More Heimdal 1.5.2 port problems
On Sun, May 27, 2012 at 3:33 PM, Wesley Shields w...@freebsd.org wrote:
On Sun, May 27, 2012 at 01:58:23PM -0400, Robert Simmons wrote:
On Sat, May 26, 2012 at 3:22 PM, Robert Simmons rsimmo...@gmail.com wrote:
I've found another problem with the port.
kadmind and kdc both look for krb5.conf in /usr/local/etc, but
kpasswdd and kstash look for it in /etc. ?This can be fixed with a
symlink, but I feel like that's not the best solution. ?Ultimately,
all the heimdal utilities and daemons should be looking in the same
location for krb5.conf, correct?
I don't see any flags for kstash or kpasswdd to change where they look
for krb5.conf.
I'm going to go back and compile it from source again and see if there
is another configure flag that is missing from the port.
I've attached a patch for this problem. Please review it and make
sure this is the right way to fix the problem.
--- Makefile.old 2012-05-27 13:53:01.132516965 -0400
+++ Makefile 2012-05-27 13:54:13.928517659 -0400
@@ -7,7 +7,7 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES= security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
@@ -39,7 +39,8 @@
CONFIGURE_ARGS+= --with-libintl=${LOCALBASE} \
--with-readline=${DESTDIR}/usr \
--enable-pthread-support \
- --with-hdbdir=/var/db/${PORTNAME}
+ --with-hdbdir=/var/db/${PORTNAME} \
+ --sysconfdir=${LOCALBASE}/etc
MAKE_ENV+= INSTALL_CATPAGES=no
You want to use PREFIX instead of LOCALBASE for sysconfdir.
PREFIX is where the port will install into, LOCALBASE is where the
dependencies will be looked for. It's almost always the case that PREFIX
is the same as LOCALBASE but we should support them being different.
Otherwise the patch looks sane to me. Awaiting Joerg's input before I
commit. Thanks again!
Understood. Here's a new patch. Also, this particular behavior seems
odd to me, and I think I will ping Heimdal's list about this. It
seems to me that this configure flag shouldn't be needed, or at least
all the daemons and utilities should look consistently in the same
location if this flag is not set.
--- Makefile.old2012-05-27 13:53:01.132516965 -0400
+++ Makefile2012-05-27 13:54:13.928517659 -0400
@@ -7,7 +7,7 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES=security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
@@ -39,7 +39,8 @@
CONFIGURE_ARGS+= --with-libintl=${LOCALBASE} \
--with-readline=${DESTDIR}/usr \
--enable-pthread-support \
- --with-hdbdir=/var/db/${PORTNAME}
+ --with-hdbdir=/var/db/${PORTNAME} \
+ --sysconfdir=${PREFIX}/etc
MAKE_ENV+= INSTALL_CATPAGES=no
INFO= heimdal hx509
___
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: More Heimdal 1.5.2 port problems
On Sat, May 26, 2012 at 3:22 PM, Robert Simmons rsimmo...@gmail.com wrote:
I've found another problem with the port.
kadmind and kdc both look for krb5.conf in /usr/local/etc, but
kpasswdd and kstash look for it in /etc. This can be fixed with a
symlink, but I feel like that's not the best solution. Ultimately,
all the heimdal utilities and daemons should be looking in the same
location for krb5.conf, correct?
I don't see any flags for kstash or kpasswdd to change where they look
for krb5.conf.
I'm going to go back and compile it from source again and see if there
is another configure flag that is missing from the port.
I've attached a patch for this problem. Please review it and make
sure this is the right way to fix the problem.
--- Makefile.old2012-05-27 13:53:01.132516965 -0400
+++ Makefile2012-05-27 13:54:13.928517659 -0400
@@ -7,7 +7,7 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 2
+PORTREVISION= 3
CATEGORIES=security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
@@ -39,7 +39,8 @@
CONFIGURE_ARGS+= --with-libintl=${LOCALBASE} \
--with-readline=${DESTDIR}/usr \
--enable-pthread-support \
- --with-hdbdir=/var/db/${PORTNAME}
+ --with-hdbdir=/var/db/${PORTNAME} \
+ --sysconfdir=${LOCALBASE}/etc
MAKE_ENV+= INSTALL_CATPAGES=no
INFO= heimdal hx509
___
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: More Heimdal 1.5.2 port problems
On Sun, May 27, 2012 at 1:58 PM, Robert Simmons rsimmo...@gmail.com wrote: On Sat, May 26, 2012 at 3:22 PM, Robert Simmons rsimmo...@gmail.com wrote: I've found another problem with the port. kadmind and kdc both look for krb5.conf in /usr/local/etc, but kpasswdd and kstash look for it in /etc. This can be fixed with a symlink, but I feel like that's not the best solution. Ultimately, all the heimdal utilities and daemons should be looking in the same location for krb5.conf, correct? I don't see any flags for kstash or kpasswdd to change where they look for krb5.conf. I'm going to go back and compile it from source again and see if there is another configure flag that is missing from the port. I've attached a patch for this problem. Please review it and make sure this is the right way to fix the problem. PR opened: http://www.freebsd.org/cgi/query-pr.cgi?pr=168386 ___ 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
More Heimdal 1.5.2 port problems
I've found another problem with the port. kadmind and kdc both look for krb5.conf in /usr/local/etc, but kpasswdd and kstash look for it in /etc. This can be fixed with a symlink, but I feel like that's not the best solution. Ultimately, all the heimdal utilities and daemons should be looking in the same location for krb5.conf, correct? I don't see any flags for kstash or kpasswdd to change where they look for krb5.conf. I'm going to go back and compile it from source again and see if there is another configure flag that is missing from the port. ___ 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: Heimdal 1.5.2 problem
On Thu, May 24, 2012 at 8:38 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 06:29:20PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 5:14 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 03:08:31PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote: As the person who committed this update I will take responsibility for seeing this through. Would you mind opening a PR with this patch and CC both myself and the maintainer so it can be properly tracked. I will work with both of you to make sure it is addressed. I got some good feedback about the patch. ?I was missing a \. ?Also, it was noted that I shouldn't make changes to the default settings in this patch since it is meant to correct a problem. ?I removed the change to default. I'm not opposed to removing the change to the default, but it does cause another problem. See below. Perhaps the different default is not the best solution. ?Maybe there should be a message that at least one backend is needed for the port to function, but none have been selected by default? If a backend is required the port should refuse to build if no backend is selected. This is pretty easy to do, just check for at least one of the backends. I have no idea if multiple backends can be supported so you may or may not want to also check for that. I may have been too hasty. I've thought of a situation where one would want to build the port with no backend at all. If one wanted to use the tools in the port to administrate a remote install of Heimdal, they may want to build it without a backend. My initial thoughts were only for installing the port as a Heimdal server, and with the --with-berkeley-db=no problem fixed it does not wrongly find the version of BDB in the base OS. With this fix, the port can function with no backends selected. It just won't be able to function in a server capacity. I am also not an expert in Heimdal, I just installed it from source via its own instructions and compared that with what the FreeBSD port was doing. I'd wait for the maintainer to make changes to the default behavior for the above reason. This all sounds perfectly reasonable to me. :) If I'm understanding you correctly the patch[1] in ports/168214 is the correct one to commit. The only change I would make is not bumping PORTREVISION since the option is off by default. Sounds like the only thing left to do is wait for maintainer comment on the PR and commit accordingly. Sounds good. One question: what do you mean by PORTREVISION being off by default? I appreciate your thoroughness in this and apologize for the problem. Thanks! ___ 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: Heimdal 1.5.2 problem
On Fri, May 25, 2012 at 12:56 PM, Wesley Shields w...@freebsd.org wrote: On Fri, May 25, 2012 at 12:21:54PM -0400, Robert Simmons wrote: On Thu, May 24, 2012 at 8:38 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 06:29:20PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 5:14 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 03:08:31PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote: As the person who committed this update I will take responsibility for seeing this through. Would you mind opening a PR with this patch and CC both myself and the maintainer so it can be properly tracked. I will work with both of you to make sure it is addressed. I got some good feedback about the patch. ?I was missing a \. ?Also, it was noted that I shouldn't make changes to the default settings in this patch since it is meant to correct a problem. ?I removed the change to default. I'm not opposed to removing the change to the default, but it does cause another problem. See below. Perhaps the different default is not the best solution. ?Maybe there should be a message that at least one backend is needed for the port to function, but none have been selected by default? If a backend is required the port should refuse to build if no backend is selected. This is pretty easy to do, just check for at least one of the backends. I have no idea if multiple backends can be supported so you may or may not want to also check for that. I may have been too hasty. ?I've thought of a situation where one would want to build the port with no backend at all. ?If one wanted to use the tools in the port to administrate a remote install of Heimdal, they may want to build it without a backend. My initial thoughts were only for installing the port as a Heimdal server, and with the --with-berkeley-db=no problem fixed it does not wrongly find the version of BDB in the base OS. ?With this fix, the port can function with no backends selected. ?It just won't be able to function in a server capacity. I am also not an expert in Heimdal, I just installed it from source via its own instructions and compared that with what the FreeBSD port was doing. ?I'd wait for the maintainer to make changes to the default behavior for the above reason. This all sounds perfectly reasonable to me. :) If I'm understanding you correctly the patch[1] in ports/168214 is the correct one to commit. The only change I would make is not bumping PORTREVISION since the option is off by default. Sounds like the only thing left to do is wait for maintainer comment on the PR and commit accordingly. Sounds good. One question: what do you mean by PORTREVISION being off by default? There is no need to bump PORTREVISION because the option which you are changing is off by default so there's no need to force a rebuild of it on the package cluster since your changes are going to have no effect there. For those that have the option to on, it hasn't built properly for them yet so bumping is going to have no effect either. I understand what you're saying. However, my change would actually change the package cluster. Because those packages were built with --without-berkeley-db rather than --with-berkeley-db=no the old packages were built with broken BDB support by accident. By fixing this, the default package is actually going to be different than the one built before this change. I would recommend bumping PORTREVISION because of this. ___ 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: Heimdal 1.5.2 problem
On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote:
As the person who committed this update I will take responsibility for
seeing this through. Would you mind opening a PR with this patch and CC
both myself and the maintainer so it can be properly tracked. I will
work with both of you to make sure it is addressed.
I got some good feedback about the patch. I was missing a \. Also,
it was noted that I shouldn't make changes to the default settings in
this patch since it is meant to correct a problem. I removed the
change to default.
Perhaps the different default is not the best solution. Maybe there
should be a message that at least one backend is needed for the port
to function, but none have been selected by default?
I have attached the updated patch, and I've opened a PR here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168214
--- ports/security/heimdal/Makefile.old 2012-05-20 16:19:39.0 -0400
+++ ports/security/heimdal/Makefile 2012-05-21 06:58:34.0 -0400
@@ -7,13 +7,12 @@
PORTNAME= heimdal
PORTVERSION= 1.5.2
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES=security ipv6
MASTER_SITES= http://www.h5l.org/dist/src/ \
http://ftp.pdc.kth.se/pub/heimdal/src/ \
ftp://ftp.pdc.kth.se/pub/heimdal/src/ \
- ftp://ftp.sunet.se/pub/unix/admin/mirror-pdc/heimdal/src/ \
- ftp://ftp.ayamura.org/pub/heimdal/
+ ftp://ftp.sunet.se/pub/unix/admin/mirror-pdc/heimdal/src/
MAINTAINER=joerg.p...@frm2.tum.de
COMMENT= A popular BSD-licensed implementation of Kerberos 5
@@ -77,10 +76,10 @@
CFLAGS+= -I${BDB_INCLUDE_DIR}
CPPFLAGS+= -I${BDB_INCLUDE_DIR}
LDFLAGS+= -L${BDB_LIB_DIR}
-CONFIGURE_ARGS+= --with-berkeley-db=${LOCALBASE}
-# --with-berkeley-db-include=${BDB_INCLUDE_DIR}
+CONFIGURE_ARGS+= --with-berkeley-db=${LOCALBASE} \
+ --with-berkeley-db-include=${BDB_INCLUDE_DIR}
.else
-CONFIGURE_ARGS+= --without-berkeley-db
+CONFIGURE_ARGS+= --with-berkeley-db=no
.endif
.if defined(WITH_SQLITE)
___
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: Heimdal 1.5.2 problem
On Tue, May 22, 2012 at 5:14 PM, Wesley Shields w...@freebsd.org wrote: On Tue, May 22, 2012 at 03:08:31PM -0400, Robert Simmons wrote: On Tue, May 22, 2012 at 8:57 AM, Wesley Shields w...@freebsd.org wrote: As the person who committed this update I will take responsibility for seeing this through. Would you mind opening a PR with this patch and CC both myself and the maintainer so it can be properly tracked. I will work with both of you to make sure it is addressed. I got some good feedback about the patch. I was missing a \. Also, it was noted that I shouldn't make changes to the default settings in this patch since it is meant to correct a problem. I removed the change to default. I'm not opposed to removing the change to the default, but it does cause another problem. See below. Perhaps the different default is not the best solution. Maybe there should be a message that at least one backend is needed for the port to function, but none have been selected by default? If a backend is required the port should refuse to build if no backend is selected. This is pretty easy to do, just check for at least one of the backends. I have no idea if multiple backends can be supported so you may or may not want to also check for that. I may have been too hasty. I've thought of a situation where one would want to build the port with no backend at all. If one wanted to use the tools in the port to administrate a remote install of Heimdal, they may want to build it without a backend. My initial thoughts were only for installing the port as a Heimdal server, and with the --with-berkeley-db=no problem fixed it does not wrongly find the version of BDB in the base OS. With this fix, the port can function with no backends selected. It just won't be able to function in a server capacity. I am also not an expert in Heimdal, I just installed it from source via its own instructions and compared that with what the FreeBSD port was doing. I'd wait for the maintainer to make changes to the default behavior for the above reason. If it does require a backend then the port should default to one of them. If we don't pick one as a default then we get no package with the changes you are suggesting above (the IGNORE line I put in place will always happen on the package cluster). I'm attaching an updated version of your patch to this email that flips BDB on by default and does the check to make sure at least one backend is selected. If you feel it's sufficent we can get it in the PR so it is properly tracked. See above. And I read the commit logs for Heimdal 1.5.2 in HEAD in the base OS and it seems that the default that that maintainer uses is SQLite. That makes me even more wary of changing default behavior to choose BDB. This is from the commit log: Heimdal's KDC now require sqlite to operate. We use the bundled version and install it as libheimsqlite. If some other FreeBSD components will require it in the future we can rename it to libbsdsqlite and use for these components as well. http://svnweb.freebsd.org/base/head/crypto/heimdal/ChangeLog?view=log I have attached the updated patch, and I've opened a PR here: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168214 Thank you for opening a PR. All too often things can fall through the mailing list cracks, and if it's in a PR we can at least have a record of it. I see eadler@ has grabbed your PR. As I said earlier, I'm willing to step up and commit this (pending maintainer approval or timeout). Glad I can help. ___ 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: Heimdal 1.5.2 problem
On Tue, May 15, 2012 at 12:51 PM, Robert Simmons rsimmo...@gmail.com wrote: On Tue, May 15, 2012 at 5:46 AM, Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au wrote: Thanks for the updates Robert. I've pursued building heimdal on a custom FreeBSD9-Stable jail built without crypto (openssl, heimdal,...); and forced the selection of bdb throughout the range 5 to 41 via the following ports.conf setting *: WITH_BDB_VER=5 ... *: WITH_BDB_VER=41 Combined with security/heimdal: PREFIX=/usr/local | WITH_CRACKLIB | WITHOUT_SQLITE | WITH_BDB Only the databases/db41 builds heimdal to completion. All others terminated with /var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/lib/com_err/.libs/libc om_err.so /usr/local/lib/libintl.so /usr/local/lib/libiconv.so /var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/lib/roken/.libs/librok en.so ../../lib/sqlite/.libs/libheimsqlite.so ../../lib/roken/.libs/libroken.so -lcrypt /usr/local/lib/libldap.so /usr/local/lib/libsasl2.so -lssl -lcrypto /usr/local/lib/liblber.so -ldb -O2 -O2 -march=prescott -mtune=prescott -Wl,--version-script -Wl,./version-script.map -pthread -pthread -Wl,-soname -Wl,libhdb.so.11 -o .libs/libhdb.so.11 .libs/db3.o: In function `hdb_db_create': db3.c:(.text+0x3a): multiple definition of `hdb_db_create' .libs/db.o:db.c:(.text+0x15): first defined here *** Error code 1 There was a change to /usr/ports/security/heimda/files with the addition of patch patch-cf__db.m4, which I removed during one build attempt with db41. This generated many more error messages libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../lib/roken -I../../lib/roken -I../asn1 -I./../asn1 -I/usr/local/include -DHDB_DB_DIR=\/var/db/heimdal\ -I./../krb5 -I../../lib/sqlite -I/usr/local/include -I/usr/local/include/db41 -D_LARGE_FILES= -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -O2 -pipe -pipe -O2 -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UEBUGGING -I/usr/local/include/db41 -DLDAP_DEPRECATED -fno-strict-aliasing -MT db.lo -MD -MP -MF .deps/db.Tpo -c db.c -fPIC -DPIC -o .libs/db.o db.c: In function 'DB_close': db.c:48: error: too few arguments to function 'd-close' db.c: In function 'DB_lock': db.c:67: error: too few arguments to function 'd-fd' db.c: In function 'DB_unlock': db.c:80: error: too few arguments to function 'd-fd' db.c: In function 'DB_seq': db.c:104: error: 'DB' has no member named 'seq' ... Unfortunately this confirms that the heimdal 1.5.2 port doesn't build with bdb. I'll advise later in the week, the result of my preferred build of heimdal over ldap (over bdb5). For completeness, FreeBSD9-Stable was updated yesterday (May 14) and the ports tree was also updated and built on a virgin machine today (May 15). Yep. That's exactly what I've found. Also, as I have noted earlier, if you look at the output from configure during the building of the heimdal port, it builds db41 as a dependency, but configure does not find it! The only version of BDB that configure finds is the one in the base OS which is 185! This port is totally borken as far as building with BDB backend support. I've reached out to the Heimdal mailing list for some assistance, and I will try to fix the problem myself and submit a patch to the port. I haven't been able to get the port maintainer to respond to queries about this problem, but he may just be very busy. I have solved the problem. There are a couple of problems, actually: Heimdal 1.5.2 is incompatible with the version of BDB included in the base FreeBSD system. Also, the Makefile for the port has a few mistakes which cause configure to find the OS's BDB no matter what. These same mistakes cause configure to ignore BDB even if the port is set to install BDB backend support. Lastly, the default configuration for this port builds no backend at all, and is therefore broken. Here is a patch that corrects all the mistakes and sets BDB as the default backend. It also removes a dead mirror. Can the list please review this patch for any mistakes that I've made? --- ports/security/heimdal/Makefile.old 2012-05-20 16:19:39.0 -0400 +++ ports/security/heimdal/Makefile 2012-05-20 16:21:43.0 -0400 @@ -7,13 +7,12 @@ PORTNAME= heimdal PORTVERSION= 1.5.2 -PORTREVISION= 1 +PORTREVISION= 2 CATEGORIES=security ipv6 MASTER_SITES= http://www.h5l.org/dist/src/ \ http://ftp.pdc.kth.se/pub/heimdal/src/ \ ftp://ftp.pdc.kth.se/pub/heimdal/src/ \ - ftp://ftp.sunet.se/pub/unix/admin/mirror-pdc/heimdal/src/ \ - ftp://ftp.ayamura.org/pub/heimdal/ + ftp://ftp.sunet.se/pub/unix/admin/mirror-pdc/heimdal/src/ MAINTAINER=joerg.p...@frm2.tum.de COMMENT
Re: Heimdal 1.5.2 problem
On Tue, May 15, 2012 at 5:46 AM, Dewayne Geraghty dewayne.gerag...@heuristicsystems.com.au wrote: Thanks for the updates Robert. I've pursued building heimdal on a custom FreeBSD9-Stable jail built without crypto (openssl, heimdal,...); and forced the selection of bdb throughout the range 5 to 41 via the following ports.conf setting *: WITH_BDB_VER=5 ... *: WITH_BDB_VER=41 Combined with security/heimdal: PREFIX=/usr/local | WITH_CRACKLIB | WITHOUT_SQLITE | WITH_BDB Only the databases/db41 builds heimdal to completion. All others terminated with /var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/lib/com_err/.libs/libc om_err.so /usr/local/lib/libintl.so /usr/local/lib/libiconv.so /var/ports/usr/ports/security/heimdal/work/heimdal-1.5.2/lib/roken/.libs/librok en.so ../../lib/sqlite/.libs/libheimsqlite.so ../../lib/roken/.libs/libroken.so -lcrypt /usr/local/lib/libldap.so /usr/local/lib/libsasl2.so -lssl -lcrypto /usr/local/lib/liblber.so -ldb -O2 -O2 -march=prescott -mtune=prescott -Wl,--version-script -Wl,./version-script.map -pthread -pthread -Wl,-soname -Wl,libhdb.so.11 -o .libs/libhdb.so.11 .libs/db3.o: In function `hdb_db_create': db3.c:(.text+0x3a): multiple definition of `hdb_db_create' .libs/db.o:db.c:(.text+0x15): first defined here *** Error code 1 There was a change to /usr/ports/security/heimda/files with the addition of patch patch-cf__db.m4, which I removed during one build attempt with db41. This generated many more error messages libtool: compile: cc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -I../../lib/roken -I../../lib/roken -I../asn1 -I./../asn1 -I/usr/local/include -DHDB_DB_DIR=\/var/db/heimdal\ -I./../krb5 -I../../lib/sqlite -I/usr/local/include -I/usr/local/include/db41 -D_LARGE_FILES= -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -O2 -pipe -pipe -O2 -g0 -ggdb0 -DSTRIP_FBSDID -UDEBUGGING -UEBUGGING -I/usr/local/include/db41 -DLDAP_DEPRECATED -fno-strict-aliasing -MT db.lo -MD -MP -MF .deps/db.Tpo -c db.c -fPIC -DPIC -o .libs/db.o db.c: In function 'DB_close': db.c:48: error: too few arguments to function 'd-close' db.c: In function 'DB_lock': db.c:67: error: too few arguments to function 'd-fd' db.c: In function 'DB_unlock': db.c:80: error: too few arguments to function 'd-fd' db.c: In function 'DB_seq': db.c:104: error: 'DB' has no member named 'seq' ... Unfortunately this confirms that the heimdal 1.5.2 port doesn't build with bdb. I'll advise later in the week, the result of my preferred build of heimdal over ldap (over bdb5). For completeness, FreeBSD9-Stable was updated yesterday (May 14) and the ports tree was also updated and built on a virgin machine today (May 15). Yep. That's exactly what I've found. Also, as I have noted earlier, if you look at the output from configure during the building of the heimdal port, it builds db41 as a dependency, but configure does not find it! The only version of BDB that configure finds is the one in the base OS which is 185! This port is totally borken as far as building with BDB backend support. I've reached out to the Heimdal mailing list for some assistance, and I will try to fix the problem myself and submit a patch to the port. I haven't been able to get the port maintainer to respond to queries about this problem, but he may just be very busy. ___ 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: Heimdal 1.5.2 problem
I've determined that there are actually two problems: configure finds the version of BDB that is built into FreeBSD: checking db.h usability... yes checking db.h presence... yes checking for db.h... yes checking db_185.h usability... yes checking db_185.h presence... yes checking for db_185.h... yes But after install, I get the following error: # /usr/local/sbin/kadmin -l kadmin init HOME kadmin: hdb_open: hdb_open: failed initialize database /var/db/heimdal/heimdal kadmin The other problem is when I configure the heimdal port to use BDB, none of the possible BDB versions available in the ports tree are detected by heimdal's configure: checking db5/db.h usability... no checking db5/db.h presence... no checking for db5/db.h... no checking db4/db.h usability... no checking db4/db.h presence... no checking for db4/db.h... no checking db3/db.h usability... no checking db3/db.h presence... no checking for db4/db.h... no checking db3/db.h usability... no checking db3/db.h presence... no checking for db3/db.h... no ___ 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: Heimdal 1.5.2 problem
On Fri, May 11, 2012 at 1:15 PM, Matthias Andree matthias.and...@gmx.de wrote: Am 11.05.2012 04:42, schrieb Robert Simmons: And, this is the version of BerkeleyDB that it compiles and installs to satisfy the BDB backend that I enabled during config: db41-4.1.25_4 Try with the newest BDB that builds. Chances are versions 4.4 and beyond are better-behaved, chances are that they aren't. db41 is very old. Heimdal fails to compile if any other version of BDB is installed already. Also, according to the docs in Heimdal itself, GDBM is an alternative, but when I install GDBM, configure for Heimdal does not find it and goes ahead and installs db41. Has anyone else successfully installed Heimdal 1.5.2 from ports on FreeBSD 9.0? What did you do differently than me? I'm using the base system Kerberos where needed (i. e. fetchmail as a GSSAPI client). Have you or anyone else been able to successfully install Heimdal 1.5.2 from the ports tree using BDB? If so, what steps did you take that are different from what I did? ___ 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
Heimdal 1.5.2 problem
I've just installed the new version of Heimdal, 1.5.2 from ports, and
I'm having a problem.
As in the past, BerkeleyDB needs to be enabled with make config so
that there is a backend. However, I'm still getting the error as if
BerkeleyDB was not enabled, and there is no backend support.
I've followed this process to get to this point:
# cd /usr/ports/security/heimdal
# make config
*at this point, I've just made sure that BDB and cracklib support are compiled.
# make install
# mkdir /var/db/heimdal
# chmod 600 /var/db/heimdal
Then the following is added to /etc/rc.conf
kerberos5_server_enable=YES
kerberos5_server=/use/local/libexec/kdc
kadmind5_server_enable=YES
kadmind5_server=/usr/local/libexec/kadmind
kpasswdd_server_enable=YES
kpasswdd_server=/usr/local/libexec/kpasswdd
This is my /etc/krb5.conf
[libdefaults]
default_realm = HOME
default_etypes = aes256-cts-hmac-sha1-96
[realms]
EXAMPLE.ORG = {
kdc = kerberos.home
admin_server = kerberos.home
kpasswd_server = kerberos.home
}
[password_quality]
policies = builtin:minimum-length builtin:character-class
min_length = 20
min_classes = 4
[kdc]
enable-kerberos4 = false
enable-524 = false
require-preauth = true
allow-anonymous = false
[kadmin]
require-preauth = true
default_keys = aes256-cts-hmac-sha1-96:pw-salt
[domain_realm]
.home = HOME
I then created a key
# kstash --enctype=aes256-cts-hmac-sha1-96 --random-key
Then tried to initialize the realm:
# /usr/local/sbin/kadmin -l
kadmin init HOME
kadmin: hdb_open: hdb_open: failed initialize database /var/db/heimdal/heimdal
kadmin
This is the error I get. Also, after performing this failed init, the
database is actually created in /var/db/heimdal
# ll /var/db/heimdal
total 24
-rw--- 1 root wheel 16384 May 10 19:56 heimdal.db
-rw--- 1 root wheel 0 May 10 19:18 heimdal.lock
-rw--- 1 root wheel264 May 10 19:17 kdc.log
-rw--- 1 root wheel 73 May 10 19:18 m-key
According to PR 154711, I've done everything correct, but I'm still
getting the error.
http://www.freebsd.org/cgi/query-pr.cgi?pr=154711
All of the regular dependencies are satisfied:
autoconf-2.68, autoconf-wrapper-20101119, gettext-0.18.1.1,
libiconv-1.14, libtool-2.4.2, m4-1.4.16,1, perl-5.12.4_4,
pkg-config-0.25_1
And, this is the version of BerkeleyDB that it compiles and installs
to satisfy the BDB backend that I enabled during config:
db41-4.1.25_4
Has anyone else successfully installed Heimdal 1.5.2 from ports on
FreeBSD 9.0? What did you do differently than me?
___
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
