github tags containing /
I'm working on a couple of new ports where I'm using fetching the
distfiles from github. One quirk is that the tags start with a prefix
of tags/v. I'm setting PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}.
If I follow the example for in the Porters Handbook using
DISTVERSIONPREFIX=tags/v then the distfile gets named
${PORTNAME}-tags/v${PORTVERSION}_GH0.tar.gz,
which seems somewhat undesirable. This seems to be a bit misleading
and risky because this port is just a python wrapper around another
library that also has the same PORTNAME. That port hasn't been
converted to fetch from github, and when it does it seems like there
would be a chance of collisions.
I seem to get better results by setting GH_TAGNAME=tags/v${PORTVERSION}.
In that case, the distfile gets named
${GH_ACCOUNT}-${GH_PROJECT}-${PORTVERSION}-tags-v${PORTVERSION}_GH0.tar.gz.
This seems to be excessively verbose, but safer.
Thoughts?
___
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: github tags containing /
On 4/1/2015 1:54 AM, Don Lewis wrote:
I'm working on a couple of new ports where I'm using fetching the
distfiles from github. One quirk is that the tags start with a prefix
of tags/v. I'm setting PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}.
If I follow the example for in the Porters Handbook using
DISTVERSIONPREFIX=tags/v then the distfile gets named
${PORTNAME}-tags/v${PORTVERSION}_GH0.tar.gz,
which seems somewhat undesirable. This seems to be a bit misleading
and risky because this port is just a python wrapper around another
library that also has the same PORTNAME. That port hasn't been
converted to fetch from github, and when it does it seems like there
would be a chance of collisions.
I seem to get better results by setting GH_TAGNAME=tags/v${PORTVERSION}.
In that case, the distfile gets named
${GH_ACCOUNT}-${GH_PROJECT}-${PORTVERSION}-tags-v${PORTVERSION}_GH0.tar.gz.
This seems to be excessively verbose, but safer.
Thoughts?
Can you please be more specific on what port this is and possibly
provide a patch?
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: Replacing vlc with vlc-qt4 broke pkg upgrade
On 03/31/2015 21:29, Kevin Oberman wrote: I don't see any information that vlc-qt4 has replaced vlc. It is just a version of vlc that will build using the old version of Qt. If you update vlc, it will install the required Qt5 ports. vlc in my case is an automatic dependency of multimedia/phonon-vlc which was recently switched to vlc-qt4. In such case 'pkg upgrade' should automatically delete vlc and install vlc-qt4, but pkg fails instead. Yuri ___ 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: github tags containing /
On 4/1/2015 2:13 AM, Don Lewis wrote:
On 1 Apr, Bryan Drewery wrote:
On 4/1/2015 1:54 AM, Don Lewis wrote:
I'm working on a couple of new ports where I'm using fetching the
distfiles from github. One quirk is that the tags start with a prefix
of tags/v. I'm setting PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}.
Wow it really has 'tags/' in the tags and 'branches/' in the branches.
It has to be a bad conversion from SVN. Anyway it is intended to be
supported fine...
If I follow the example for in the Porters Handbook using
DISTVERSIONPREFIX=tags/v then the distfile gets named
${PORTNAME}-tags/v${PORTVERSION}_GH0.tar.gz,
which seems somewhat undesirable. This seems to be a bit misleading
and risky because this port is just a python wrapper around another
library that also has the same PORTNAME. That port hasn't been
converted to fetch from github, and when it does it seems like there
would be a chance of collisions.
I seem to get better results by setting GH_TAGNAME=tags/v${PORTVERSION}.
In that case, the distfile gets named
${GH_ACCOUNT}-${GH_PROJECT}-${PORTVERSION}-tags-v${PORTVERSION}_GH0.tar.gz.
This seems to be excessively verbose, but safer.
Just use GH_TAGNAME=tags/v${PORTVERSION} for now.
The DISTVERSIONPREFIX is supposed to work in this case as well. I'll
look into it tomorrow.
It is likely the same as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199069 which I
realized earlier today.
The DISTNAME you see is intentionally verbose so it is unique and avoids
rerolled checksums on account/project renames or PORTVERSION changes or
github-specific rerolls. It is intended to stand out as a
GITHUB-generated file so it is not confused with other distributed files.
The DISTVERSIONPREFIX _not_ producing the same filename is a bug.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
Re: github tags containing /
On 1 Apr, Bryan Drewery wrote:
On 4/1/2015 2:13 AM, Don Lewis wrote:
On 1 Apr, Bryan Drewery wrote:
On 4/1/2015 1:54 AM, Don Lewis wrote:
I'm working on a couple of new ports where I'm using fetching the
distfiles from github. One quirk is that the tags start with a prefix
of tags/v. I'm setting PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}.
Wow it really has 'tags/' in the tags and 'branches/' in the branches.
It has to be a bad conversion from SVN. Anyway it is intended to be
supported fine...
Yeah, trying to get make fetch working was quite entertaining.
If I follow the example for in the Porters Handbook using
DISTVERSIONPREFIX=tags/v then the distfile gets named
${PORTNAME}-tags/v${PORTVERSION}_GH0.tar.gz,
which seems somewhat undesirable. This seems to be a bit misleading
and risky because this port is just a python wrapper around another
library that also has the same PORTNAME. That port hasn't been
converted to fetch from github, and when it does it seems like there
would be a chance of collisions.
I seem to get better results by setting GH_TAGNAME=tags/v${PORTVERSION}.
In that case, the distfile gets named
${GH_ACCOUNT}-${GH_PROJECT}-${PORTVERSION}-tags-v${PORTVERSION}_GH0.tar.gz.
This seems to be excessively verbose, but safer.
Just use GH_TAGNAME=tags/v${PORTVERSION} for now.
Ok, will do.
The DISTVERSIONPREFIX is supposed to work in this case as well. I'll
look into it tomorrow.
It is likely the same as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199069 which I
realized earlier today.
The DISTNAME you see is intentionally verbose so it is unique and avoids
rerolled checksums on account/project renames or PORTVERSION changes or
github-specific rerolls. It is intended to stand out as a
GITHUB-generated file so it is not confused with other distributed files.
The DISTVERSIONPREFIX _not_ producing the same filename is a bug.
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
boinc-client dependencies
Hello port maintainers, I use boinc-client on 10.1-RELEASE-p6. I found that at least one MilkyWay@Home task needs libstdc++.so.6, so I had install lang/gcc to make it work. Mabye it makes sense to add lang/gcc as a dependency for boinc-client or just add a note that some BOINC projects or project tasks might require it. Thanks for your time. Best regards, Andreas Obermaier ___ 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: github tags containing /
On 1 Apr, Bryan Drewery wrote:
On 4/1/2015 1:54 AM, Don Lewis wrote:
I'm working on a couple of new ports where I'm using fetching the
distfiles from github. One quirk is that the tags start with a prefix
of tags/v. I'm setting PKGNAMEPREFIX=${PYTHON_PKGNAMEPREFIX}.
If I follow the example for in the Porters Handbook using
DISTVERSIONPREFIX=tags/v then the distfile gets named
${PORTNAME}-tags/v${PORTVERSION}_GH0.tar.gz,
which seems somewhat undesirable. This seems to be a bit misleading
and risky because this port is just a python wrapper around another
library that also has the same PORTNAME. That port hasn't been
converted to fetch from github, and when it does it seems like there
would be a chance of collisions.
I seem to get better results by setting GH_TAGNAME=tags/v${PORTVERSION}.
In that case, the distfile gets named
${GH_ACCOUNT}-${GH_PROJECT}-${PORTVERSION}-tags-v${PORTVERSION}_GH0.tar.gz.
This seems to be excessively verbose, but safer.
Thoughts?
Can you please be more specific on what port this is and possibly
provide a patch?
The ports aren't in the tree yet. This is the Makefile for one of them:
# $FreeBSD$
PORTNAME= wdns
PORTVERSION=0.6.0
#DISTVERSIONPREFIX= tags/v
CATEGORIES= dns python
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
MAINTAINER= truck...@freebsd.org
COMMENT=Python wrapper for dns/wdns
LICENSE=APACHE20
BUILD_DEPENDS= cython:${PORTSDIR}/lang/cython
LIB_DEPENDS=libwdns.so:${PORTSDIR}/dns/wdns
USE_GITHUB= yes
GH_ACCOUNT= farsightsec
GH_PROJECT= pywdns
GH_TAGNAME= tags/v${PORTVERSION}
USE_PYTHON= distutils autoplist
USES= pkgconfig python
post-patch:
${REINPLACE_CMD} -e 1s+ python+ ${PYTHON_CMD}+ ${WRKSRC}/setup.py
${REINPLACE_CMD} -e 1s+ python+ ${PYTHON_CMD}+
${WRKSRC}/gen_pywdns_constants
.include bsd.port.mk
___
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] Call for testing pkg 1.5.0
On 31.03.2015 21:03, Baptiste Daroussin wrote: - pkg has grown with an initial support for provides/requires: this is a naive version but good enough to at least make major upgrade of php safer as well as making pear/pecl maintenance saner (note that this will need modifications in the ports tree) Thank you! -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ math/giacxcas | 1.1.0 | 1.2.0 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt 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: Galera ports
I would propose to add something like WSREP knob to existing mysql*-server ports that adds the extra patches and then make slaves with WSREP option selected That's a great idea, Nikolai! And I think databases/galera should be renamed to something more obvious, like databases/galera-plugin or something else. Next to databases/galera-arbitrator, for example. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Galera-ports-tp6001219p6001898.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] Call for testing pkg 1.5.0
On 1 Apr 2015, at 05:03, Rui Paulo rpa...@me.com wrote: That is expected. WITH_PKG=devel is a make(1) option that only affects ports (non-binary pkgs). Are you sure? I have it in make.conf on one of my systems where I never build ports manually (and don't even have a ports tree installed) and there I get this: $ pkg -v 1.4.99.13 In a jail on the same machine without the make.conf entry, I get the stable version. This is how I've been testing pkg-devel for a while. Is there a different recommended way? David ___ 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] Call for testing pkg 1.5.0
On Wed, Apr 01, 2015 at 11:48:27AM +, Thomas Mueller wrote: Excerpt from Baptiste Daroussin: - Initial support for OS X - Initial support for NetBSD/EdjeBSD How would pkg-1.5.0 integrate with NetBSD pkgsrc? I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is such a plan in the works? There are people looking at integrating pkg with pkgsrc yes, don't know the status, (pkg is already in pkgsrc-wip but no further integration for what I do know And yes you are right it is EdgeBSD not EdjeBSD sorry. Best regards, Bapt pgpDw5iJ1YWPm.pgp Description: PGP signature
Re: [CFT] Call for testing pkg 1.5.0
Excerpt from Baptiste Daroussin: - Initial support for OS X - Initial support for NetBSD/EdjeBSD How would pkg-1.5.0 integrate with NetBSD pkgsrc? I didn't think there were any plans to port FreeBSD ports to NetBSD. Or is such a plan in the works? EdjeBSD should be EdgeBSD. A little spelling error can be critical when trying to find something on the Internet. Web site is edgebsd.org (I just went there). Tom ___ 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
port maintainer wants to change port maintainer email address
Hello, I maintain 4 different ports. The port maintainer email address listed with the ports have been harvested by spammers and I am now receiving over 100 spam emails per email address each day. The ports in question do not require update. Just want to change the maintainer email address. Is there some way this can be done without bumping the port version number? ___ 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 maintainer wants to change port maintainer email address
Submit patches in bugzilla with the diff from your new mail account. Login with your old mail account and approve the patches. Someone will take care of it. On Wed, Apr 1, 2015 at 4:37 PM, joeb1 jo...@a1poweruser.com wrote: Hello, I maintain 4 different ports. The port maintainer email address listed with the ports have been harvested by spammers and I am now receiving over 100 spam emails per email address each day. The ports in question do not require update. Just want to change the maintainer email address. Is there some way this can be done without bumping the port version number? ___ 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
libdrm 2.4.58 upgrade fails
Upgrading libdrm to version 2.4.58 fails: root@kg-v7# uname -a FreeBSD kg-v7.kg4.no 10.1-STABLE FreeBSD 10.1-STABLE #0 r278322: Fri Feb 6 21:36:01 CET 2015 r...@kg-v7.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 root@kg-v7# pv libdrm* [Reading data from pkg(8) ... - 488 packages found - done] libdrm-2.4.50 needs updating (port has 2.4.58_1,1) root@kg-v7# portupgrade -R libdrm [...] buffers.c:163:15: warning: packed attribute is unnecessary for 'value' [-Wpacked] unsigned int value:24; ^ 1 warning generated. 1 warning generated. CCLD modetest libtool: link: cannot find the library `/usr/local/lib/libfontconfig.la' or unhandled argument `/usr/local/lib/libfontconfig.la' Makefile:418: recipe for target 'modetest' failed gmake[5]: *** [modetest] Error 1 gmake[5]: Leaving directory '/usr/ports/graphics/libdrm/work/libdrm-2.4.58/tests/modetest' Makefile:824: recipe for target 'all-recursive' failed gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory '/usr/ports/graphics/libdrm/work/libdrm-2.4.58/tests' Makefile:742: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory '/usr/ports/graphics/libdrm/work/libdrm-2.4.58' Makefile:500: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory '/usr/ports/graphics/libdrm/work/libdrm-2.4.58' === Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/libdrm *** Error code 1 Stop. make: stopped in /usr/ports/graphics/libdrm ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20150401-46550-1b6s0of env UPGRADE_TOOL=portupgrade UPGRADE_PORT=libdrm-2.4.50 UPGRADE_PORT_VER=2.4.50 make ** Fix the problem and try again. ** Listing the failed packages (-:ignored / *:skipped / !:failed) ! graphics/libdrm (libdrm-2.4.50)(unknown build error) Perhaps the port is looking for the wrong file? root@kg-v7# ll /usr/local/lib/libfontc* lrwxr-xr-x 1 root wheel 22 Feb 6 23:47 /usr/local/lib/libfontconfig.so@ - libfontconfig.so.1.8.0 lrwxr-xr-x 1 root wheel 22 Feb 6 23:47 /usr/local/lib/libfontconfig.so.1@ - libfontconfig.so.1.8.0 -rwxr-xr-x 1 root wheel 262024 Feb 6 23:47 /usr/local/lib/libfontconfig.so.1.8.0* Trying a 'make' (after make clean) in the ports directory doesn't work either -- Regards, Torfinn Ingolfsen, Norway ___ 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] Call for testing pkg 1.5.0
On Wed, Apr 01, 2015 at 01:56:38PM +0100, David Chisnall wrote: On 1 Apr 2015, at 05:03, Rui Paulo rpa...@me.com wrote: That is expected. WITH_PKG=devel is a make(1) option that only affects ports (non-binary pkgs). Are you sure? I have it in make.conf on one of my systems where I never build ports manually (and don't even have a ports tree installed) and there I get this: $ pkg -v 1.4.99.13 In a jail on the same machine without the make.conf entry, I get the stable version. This is how I've been testing pkg-devel for a while. Is there a different recommended way? That is because you enforced installing pkg-devel one day via: pkg install pkg-devel probably then it will stay on pkg-devel :) pkg itself is not aware of make.conf Best regards Bapt pgpUdcTBG3cfF.pgp Description: PGP signature
New 2015Q2 branch
Hi, The 2015Q2 branch has been created. It means that the next update on the quarterly packages will be on the 2015Q2 branch A lot of things happened in the last three months: - pkg 1.4.12 - New USES: blaslapack, fonts, metaport, xfce - Removed keywords: @fc, @fontsdir - Default version of MySQL switched to 5.6 - Default version of PHP switched to 5.6 - Default version of Python 3 switched to 3.4 - Default version of Ruby switched to 2.1 - Firefox 37.0 - Firefox-esr 31.6.0 - Chromium 40.0.2214.115 - Ruby 2.1.5 - gcc 4.8.4 - Gnome 3.14.2 - Xorg 1.14.7 Next quarterly package builds will start on Wednesday 7th at 1:00 am UTC and should be available on your closest mirrors few days later. For those stat nerds out there, here's what happened during the last 3 months on head: Number of commits: 6796 Number of committers: 163 Diffstat: 16577 files changed, 868545 insertions(+), 500248 deletions(-) Most active committers: 1178 sunpoet 560 amdmi3 401 bapt 268 vanilla 254 adamw 234 marino 212 antoine 154 robak 136 kwm 118 jbeich and on the 2015Q1 branch: Number of commits: 140 Number of committers: 35 Diffstat: 491 files changed, 10582 insertions(+), 8491 deletions(-) Most active committers: 20 antoine 19 amdmi3 10 delphij 9 zi 8 rene 7 jbeich 6 xmj 5 rakuco 4 riggs 4 ohauer Regards, -- Mathieu Arnold With portmgr's hat on pgpRLTwEniKu3.pgp Description: PGP signature
databases/mysql-connector-java: Looks broken to me
I was getting indications that mysql connections through the com.mysql.jdbc
driver was not working. So I searched for a test method (included below) and
here are the results.
* Server: mariadb100--10.0.17, jailed, tcp connection. Able to connect through
other drivers using same params.
* Client: mysql-connector-java-5.1.35
* Test code compiled with javac, $ java -cp . jdbc
com.mysql.jdbc.Driver
Exception in thread main java.lang.ClassNotFoundException:
com.mysql.jdbc.Driver # I compile with OPTIONS_UNSET= NLS
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:191)
at jdbc.main(jdbc.java:15)
* Java Test Code:
[code]
import java.sql.*;
import java.util.Properties;
public class jdbc
{
// The JDBC Connector Class.
private static final String dbClassName = com.mysql.jdbc.Driver;
private static final String CONNECTION =
jdbc:mysql://192.168.2.110/mydb;
public static void main(String[] args) throws
ClassNotFoundException,SQLException
{
System.out.println(dbClassName);
// Class.forName(xxx) loads the jdbc classes and
// creates a drivermanager class factory
Class.forName(dbClassName);
// Properties for user and password.
Properties p = new Properties();
p.put(user,mydb);
p.put(password,);
// Now try to connect
Connection c = DriverManager.getConnection(CONNECTION,p);
System.out.println(It works !);
c.close();
}
}
[/code]
--
FreeBSD_amd64_11-Current_RadeonKMS
Please CC my email when responding, mail from list is not delivered.
___
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: libdrm 2.4.58 upgrade fails
On 1-4-2015 15:06, Torfinn Ingolfsen wrote: 1 warning generated. CCLD modetest libtool: link: cannot find the library `/usr/local/lib/libfontconfig.la' or unhandled argument `/usr/local/lib/libfontconfig.la' Makefile:418: recipe for target 'modetest' failed gmake[5]: *** [modetest] Error 1 gmake[5]: Leaving directory Please read ports/UPDATING entry 20140909 for instructions for a solution how to deal with missing .la files. -Koop ___ 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
Re: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 1 April 2015, at 14:21, Yuri y...@rawbw.com wrote: On 04/01/2015 14:17, Jung-uk Kim wrote: I know bsd.openssl.mk has been broken for very long time. For example, http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405 However, I am not sure whether entirely removing it is the best way going forward. I mean, removing of the dependency on base. Ports should use only openssl port. If you think this isn't a good idea, and ports should still occasionally use base openssl, would you care to explain why you think so? Yuri Some of us don’t use the ports version of openssl because of the issues with v1.xxx. ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
I implemented the new 'basemix' stage-qa test: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199106 Currently it complains about libssl.so libcrypto.so from base. Yuri ___ 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: databases/mysql-connector-java: Looks broken to me
Thanks Matt. I forgot to mention that my make.conf has these defined (however redundant or ridiculous): JAVA_PREFERRED_PORTS= JAVA_PORT_NATIVE_OPENJDK_JDK_1_8 JAVA_PORT_VERSION= 1.8+ JAVA_DEFAULT?= 1.8+ OVERRIDE_JAVA_VERSION= 1.8+ JAVA_OS=native JAVA_VERSION= 1.8+ JAVA_VENDOR=openjdk I wonder if these may have caused breakage yet I expect not since you advise that ports download the pre-compiled *.jar. Let me know if there's anything I can help with. Regards. PS: Please CC my email when responding, mail from list is not delivered. ___ 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: databases/mysql-connector-java: Looks broken to me
On 04/01/15 15:31, Beeblebrox via freebsd-ports wrote: I was getting indications that mysql connections through the com.mysql.jdbc driver was not working. So I searched for a test method (included below) and here are the results. * Server: mariadb100--10.0.17, jailed, tcp connection. Able to connect through other drivers using same params. * Client: mysql-connector-java-5.1.35 * Test code compiled with javac, $ java -cp . jdbc com.mysql.jdbc.Driver Exception in thread main java.lang.ClassNotFoundException: com.mysql.jdbc.Driver # I compile with OPTIONS_UNSET= NLS at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:191) at jdbc.main(jdbc.java:15) Thank you for the report. Unfortunately, I'm at a loss to fix this. The driver is supplied pre-compiled by Oracle -- we used to compile it, long ago, but then it grew some compatibility shims that meant bits of it needed compiling with different JDKs, something that couldn't be supported in the ports. I guess it's time to try recompiling it ourselves since java has moved on quite a lot since those days. Give me a while to test that please. Given that it's basically a .jar file downloaded from the net and copied into position, the OPTIONS_USET=NLS thing will have absolutely no effect on mysql-connector-java itself Cheers, Matthew signature.asc Description: OpenPGP digital signature
Re: port maintainer wants to change port maintainer email address
On Wed, 1 Apr 2015, joeb1 wrote: I maintain 4 different ports. The port maintainer email address listed with the ports have been harvested by spammers and I am now receiving over 100 spam emails per email address each day. Doesn't a1poweruser.com use spam filters such as the various DNSBLs? On a bad week, I may get 10 and reject 500. Can FreeBSD protect the email addresses somehow, such as requiring Javascript to decode them? I assume that the spam in question doesn't come straight from FreeBSD's servers of course (unlike a lot of other spam). -- Dave Horsfall DTM (VK2KFU) Those who don't understand security will suffer. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 04/01/2015 14:30, Guido Falsi wrote: Some examples of things that could (and will) go wrong: - ports silently linking to base ssl due to weirdness in their build scripts - ports linking to other libraries in base which are linked to base ssl, causing conflicts - ports interacting with base parts, which are using base ssl. I am going to write the stage-qa test checking for just that: no base libraries of certain kinds are mixed into the link list. Yuri ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 04/01/15 23:21, Yuri wrote: On 04/01/2015 14:17, Jung-uk Kim wrote: I know bsd.openssl.mk has been broken for very long time. For example, http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405 However, I am not sure whether entirely removing it is the best way going forward. I mean, removing of the dependency on base. Ports should use only openssl port. If you think this isn't a good idea, and ports should still occasionally use base openssl, would you care to explain why you think so? I'm not in the position of taking such decisions, but based on some experience and quick tests I have discovered that changing the default would cause ports now working to break. I generally agree with your idea that ports should use ports ssl, but making this switch is more difficult than just changing a variable. Some real testing is needed, and just exp-runs would not suffice, most software would show misbehavior only at runtime. Some examples of things that could (and will) go wrong: - ports silently linking to base ssl due to weirdness in their build scripts - ports linking to other libraries in base which are linked to base ssl, causing conflicts - ports interacting with base parts, which are using base ssl. All this without accounting for eventual ports who do need older ssl to work, causing further mixing. I have experienced or seen reports about all tree examples. Also, you could have a look at this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198788 -- Guido Falsi m...@madpilot.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Pourdriere produces faulty build results due to bsd.openssl.mk bug
Le mer 1 avr 15 à 22:59:56 +0200, Yuri y...@rawbw.com écrivait : I found that packages produced by poudriere likely link with base openssl, while port make likely links with the port openssl. This is because of the lines in bsd.openssl.mk which check for the presence of openssl shared library and headers under PREFIX, and set WITH_OPENSSL_BASE when they aren't present. In case of port make files are likely present, and in case of poudriere build files are likely not present. On this subject, please read Build packages in poudriere without OpenSSL in the base jail at http://bsdxbsdx.blogspot.fr/2015/04/build-packages-in-poudriere-without.html Regards, -- Th. Thomas. pgp310_kWHLXL.pgp Description: PGP signature
Re: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On Wed, Apr 01, 2015 at 11:30:20PM +0200 I heard the voice of Guido Falsi, and lo! it spake thus: - ports linking to other libraries in base which are linked to base ssl, causing conflicts On my system, libssl/libcrypto is used by: /usr/lib/libarchive.so /usr/lib/libbsnmp.so /usr/lib/libfetch.so /usr/lib/libgssapi_krb5.so /usr/lib/libgssapi_ntlm.so /usr/lib/libhdb.so /usr/lib/libheimntlm.so /usr/lib/libhx509.so /usr/lib/libkadm5clnt.so /usr/lib/libkadm5srv.so /usr/lib/libkafs5.so /usr/lib/libkdc.so /usr/lib/libkrb5.so /usr/lib/libmp.so /usr/lib/libradius.so /usr/lib/libssl.so /usr/lib/pam_krb5.so /usr/lib/pam_ksu.so /usr/lib/pam_radius.so /usr/lib/pam_ssh.so At a glance, I wouldn't be surprised to find libfetch/libarchive used somewhere in ports. But the krb5/gssapi bits may be the trickiest to unravel, considering how widely they wind up getting linked into stuff. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 04/01/15 23:37, Yuri wrote: On 04/01/2015 14:30, Guido Falsi wrote: Some examples of things that could (and will) go wrong: - ports silently linking to base ssl due to weirdness in their build scripts - ports linking to other libraries in base which are linked to base ssl, causing conflicts - ports interacting with base parts, which are using base ssl. I am going to write the stage-qa test checking for just that: no base libraries of certain kinds are mixed into the link list. This would be good. What I am most worried about, though, are problems showing up at runtime only on specific configurations or use cases. This would help nailing them down. Check the last entry about asterisk in UPDATING too (I maintain it and that one did hit me on a server of mine) -- Guido Falsi m...@madpilot.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Pourdriere produces faulty build results due to bsd.openssl.mk bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/01/2015 16:59, Yuri wrote: I found that packages produced by poudriere likely link with base openssl, while port make likely links with the port openssl. This is because of the lines in bsd.openssl.mk which check for the presence of openssl shared library and headers under PREFIX, and set WITH_OPENSSL_BASE when they aren't present. In case of port make files are likely present, and in case of poudriere build files are likely not present. Example is ftp/curl (with GSSAPI=NONE, OPENSSL=yes options). *Poudriere produces curl library, that causes VirtualBox to break* due to the openssl base vs. port conflicts. See recent emulation@ ML threads. Port make produces curl library that works fine with VirtualBox. I think both WITH_OPENSSL_BASE and WITH_OPENSSL_PORT should be retired, and code checking file presence also should be removed, and all ports should be made to build with an openssl port instead. Ports should never use base OpenSSL. Only 100 ports touch WITH_OPENSSL_... variables. Somebody who is able to make such decisions and has the commit bit should bit should look into this. Otherwise, massively faulty package repositories are produces. [Adding the maintainer to CC] I know bsd.openssl.mk has been broken for very long time. For example, http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405 However, I am not sure whether entirely removing it is the best way going forward. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVHGBMAAoJEHyflib82/FGH5cIAJKuo+LsZ6LUWwgIOAqTRF5E OXlq/hBKa4JFqxzH3rQvwbuhpzLZglFf8cmxfOzqyv/soQhduddsh+ljodIfbfhH JrwScfdIc6bP1lWpX3kACtlEwe4cUxm81XJiTQk/WrCom+DppXtdV6EqOxyiTj0B UgiBYplQpihdUNgHIQL8USIQFeadZReOiUxNdNvc5EbIoO2QUbd3lAORQ96SZM5W PRZRFMZmLyQkCNdP8oaTYE1s+heN0Rul+JPNfovVuGOIjEkclqMUVCUzhQuB7/Do S+clMj88/sBhdoPMloThi0hI3lOgh+GjQb3McKoT7s5dhgVDEwqpfJrhS7TYYsQ= =oY1m -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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 4/1/2015 3:59 PM, Yuri wrote: I found that packages produced by poudriere likely link with base openssl, while port make likely links with the port openssl. This is because of the lines in bsd.openssl.mk which check for the presence of openssl shared library and headers under PREFIX, and set WITH_OPENSSL_BASE when they aren't present. In case of port make files are likely present, and in case of poudriere build files are likely not present. Example is ftp/curl (with GSSAPI=NONE, OPENSSL=yes options). *Poudriere produces curl library, that causes VirtualBox to break* due to the openssl base vs. port conflicts. See recent emulation@ ML threads. Port make produces curl library that works fine with VirtualBox. I think both WITH_OPENSSL_BASE and WITH_OPENSSL_PORT should be retired, and code checking file presence also should be removed, and all ports should be made to build with an openssl port instead. Ports should never use base OpenSSL. Only 100 ports touch WITH_OPENSSL_... variables. Somebody who is able to make such decisions and has the commit bit should bit should look into this. Otherwise, massively faulty package repositories are produces. Yuri I've wanted this for a long time. I think we should just do it. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 04/01/2015 14:17, Jung-uk Kim wrote: I know bsd.openssl.mk has been broken for very long time. For example, http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405 However, I am not sure whether entirely removing it is the best way going forward. I mean, removing of the dependency on base. Ports should use only openssl port. If you think this isn't a good idea, and ports should still occasionally use base openssl, would you care to explain why you think so? Yuri ___ 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: libdrm 2.4.58 upgrade fails
On Wed, Apr 1, 2015 at 10:52 PM, Torfinn Ingolfsen tin...@gmail.com wrote: Update, Furthermore, how do I rebuiuld all these ports? They all refer to (have as dependency) the libdrm port, and therefore fail when I try to portupgrade them. I figured it out; I had to rebuild a few (about a handful) ports one by one (without upgrading dependencies, ie. 'portupgrade portname'), until I could successfully upgrade the libdrm port. normal portupgrade works now (it is still portupgrading, but it looks much better now). Thanks! -- Regards, Torfinn ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 04/01/15 23:21, Bryan Drewery wrote: On 4/1/2015 3:59 PM, Yuri wrote: I found that packages produced by poudriere likely link with base openssl, while port make likely links with the port openssl. This is because of the lines in bsd.openssl.mk which check for the presence of openssl shared library and headers under PREFIX, and set WITH_OPENSSL_BASE when they aren't present. In case of port make files are likely present, and in case of poudriere build files are likely not present. Example is ftp/curl (with GSSAPI=NONE, OPENSSL=yes options). *Poudriere produces curl library, that causes VirtualBox to break* due to the openssl base vs. port conflicts. See recent emulation@ ML threads. Port make produces curl library that works fine with VirtualBox. I think both WITH_OPENSSL_BASE and WITH_OPENSSL_PORT should be retired, and code checking file presence also should be removed, and all ports should be made to build with an openssl port instead. Ports should never use base OpenSSL. Only 100 ports touch WITH_OPENSSL_... variables. Somebody who is able to make such decisions and has the commit bit should bit should look into this. Otherwise, massively faulty package repositories are produces. Yuri I've wanted this for a long time. I think we should just do it. As I said in another email, I agree on the idea. On the other hand some testing plan should be laid out before unleashing this change in the tree... -- Guido Falsi m...@madpilot.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Pourdriere produces faulty build results due to bsd.openssl.mk bug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/01/2015 17:21, Yuri wrote:
On 04/01/2015 14:17, Jung-uk Kim wrote:
I know bsd.openssl.mk has been broken for very long time. For
example,
http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405
However, I am not sure whether entirely removing it is the best
way going forward.
I mean, removing of the dependency on base. Ports should use only
openssl port.
If you think this isn't a good idea, and ports should still
occasionally use base openssl, would you care to explain why you
think so?
I don't like to see adding -Wl,-rpath,${LOCALBASE}/lib to LDFLAGS
for all ports depending on libcrypto, etc. If it is moved to separate
directories first, then it makes some sense, though.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVHGPwAAoJEHyflib82/FGX8YIAIefRcO47zRHmojZ4E0gS15J
Y4bWyCFFVpIjuEDW4kQ6mFK83lJz9DD+KWfn/FFJrxAvmFpKnw4jJ8UtqsH1KuRp
o9fXPH6TGVZqvM33KCWSdDBKw/7Pu29gQjxnHmN5R8aa96oTYA7yR09BWAKcQs37
ZOrwJBcKKt03KZtvYYkc3GeK5oKKIuC1DNporYzoWFCKzrtzKDIUBJgPIePrWF6a
QGvZe85D9nwk5WCoVAw26FHV4sGpd7DMFxgkm5EfiYVvte9El3rDrIRkLLxkYqzV
C3M7pbuQ8Uf9gGUcuBnrfpWU42jVGNjvpq2w7sBQAJibeOh1TlwaDLNtS7H5ctU=
=+7Bt
-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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
+--On 1 avril 2015 14:21:48 -0700 Yuri y...@rawbw.com wrote: | On 04/01/2015 14:17, Jung-uk Kim wrote: | I know bsd.openssl.mk has been broken for very long time. For example, | | http://docs.freebsd.org/cgi/mid.cgi?50108FEF.3030405 | | However, I am not sure whether entirely removing it is the best way | going forward. | | I mean, removing of the dependency on base. Ports should use only openssl | port. | | If you think this isn't a good idea, and ports should still occasionally | use base openssl, would you care to explain why you think so? There is only one port that will need openssl from base, and it's ports-mgmt/pkg, but it can be a special case. -- Mathieu Arnold ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 01 Apr 2015, at 23:21, Bryan Drewery bdrew...@freebsd.org wrote: On 4/1/2015 3:59 PM, Yuri wrote: I found that packages produced by poudriere likely link with base openssl, while port make likely links with the port openssl. This is because of the lines in bsd.openssl.mk which check for the presence of openssl shared library and headers under PREFIX, and set WITH_OPENSSL_BASE when they aren't present. In case of port make files are likely present, and in case of poudriere build files are likely not present. Example is ftp/curl (with GSSAPI=NONE, OPENSSL=yes options). *Poudriere produces curl library, that causes VirtualBox to break* due to the openssl base vs. port conflicts. See recent emulation@ ML threads. Port make produces curl library that works fine with VirtualBox. I think both WITH_OPENSSL_BASE and WITH_OPENSSL_PORT should be retired, and code checking file presence also should be removed, and all ports should be made to build with an openssl port instead. Ports should never use base OpenSSL. Only 100 ports touch WITH_OPENSSL_... variables. Somebody who is able to make such decisions and has the commit bit should bit should look into this. Otherwise, massively faulty package repositories are produces. Yuri I've wanted this for a long time. I think we should just do it. +1 -- Regards, Bryan Drewery ___ 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
Synchronising ports with package cluster
I use pkg upgrade to maintain most of my ports but a small number need to be built from source. To avoid problems I aim to keep my ports tree in sync with the snapshots used by the package cluster. Until a couple of weeks ago I was able to obtain the revision number of the ports snapshot by parsing the results of fetching beefy2.isc.freebsd.org/data/101amd64- default/.data.json. That server now appears to be only building 93amd64-default and 101amd64-quarterly. So now my ports are stuck at revision 381523 from about two weeks ago. Where can I now obtain the revision number for the ports tree used for the latest package build? Although the above method has worked in the past it's a bit of a bodge. The ideal way would be if this information could be accessed directly from the relevant package repository. Would it be possible to provide such a facility? -- Mike Clarke ___ 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: libdrm 2.4.58 upgrade fails
Update, On Wed, Apr 1, 2015 at 4:40 PM, Koop Mast k...@rainbow-runner.nl wrote: Please read ports/UPDATING entry 20140909 for instructions for a solution how to deal with missing .la files. Thanks for the hint, but it doesn't appear to be any missing (not found in the database) files: root@kg-v7# find /usr/local/lib -name '*.la' | xargs grep -l 'libfontconfig\.la' | xargs pkg which /usr/local/lib/libcairo.la was installed by package cairo-1.10.2_7,2 /usr/local/lib/libcairo-gobject.la was installed by package cairo-1.10.2_7,2 /usr/local/lib/libcairo-script-interpreter.la was installed by package cairo-1.10.2_7,2 /usr/local/lib/libpoppler-cpp.la was installed by package poppler-0.24.5_1 /usr/local/lib/tumbler-1/plugins/tumbler-poppler-thumbnailer.la was installed by package xfce4-tumbler-0.1.30 /usr/local/lib/vlc/plugins/text_renderer/libfreetype_plugin.la was installed by package vlc-2.1.2_2,4 /usr/local/lib/libvte.la was installed by package vte-0.28.2 /usr/local/lib/libpangocairo-1.0.la was installed by package pango-1.34.1_1 /usr/local/lib/pango/1.8.0/modules/pango-basic-fc.la was installed by package pango-1.34.1_1 /usr/local/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.la was installed by package librsvg2-2.36.4 /usr/local/lib/gtk-2.0/modules/libferret.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/modules/libgail.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/modules/libcanberra-gtk-module.la was installed by package libcanberra-0.28_3 /usr/local/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-cups.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-file.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/printbackends/libprintbackend-lpr.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-am-et.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-cedilla.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-cyrillic-translit.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-inuktitut.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-ipa.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-multipress.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-thai.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-ti-er.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-ti-et.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-viqr.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/immodules/im-xim.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libpixmap.la was installed by package gtk2-2.24.22_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libxfce.la was installed by package gtk-xfce-engine-3.0.1 /usr/local/lib/gtk-2.0/2.10.0/engines/libclearlooks.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libcrux-engine.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libhcengine.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libindustrial.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libmist.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libredmond95.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libglide.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libthinice.la was installed by package gtk-engines2-2.20.2_1 /usr/local/lib/gtk-2.0/2.10.0/engines/libsvg.la was installed by package librsvg2-2.36.4 /usr/local/lib/libpoppler.la was installed by package poppler-0.24.5_1 /usr/local/lib/thunarx-2/thunar-apr.la was installed by package Thunar-1.6.3_1 /usr/local/lib/thunarx-2/thunar-sbr.la was installed by package Thunar-1.6.3_1 /usr/local/lib/thunarx-2/thunar-uca.la was installed by package Thunar-1.6.3_1 /usr/local/lib/thunarx-2/thunar-wallpaper-plugin.la was installed by package Thunar-1.6.3_1 /usr/local/lib/libpoppler-glib.la was installed by package poppler-glib-0.24.5 /usr/local/lib/libthunarx-2.la was installed by package Thunar-1.6.3_1 /usr/local/lib/libgailutil.la was installed by package gtk2-2.24.22_1 /usr/local/lib/libgdk-x11-2.0.la was installed by package gtk2-2.24.22_1 /usr/local/lib/xfce4/session/splash-engines/libbalou.la was installed by package xfce4-session-4.10.1_2 /usr/local/lib/xfce4/session/splash-engines/libmice.la was installed by package xfce4-session-4.10.1_2 /usr/local/lib/xfce4/session/splash-engines/libsimple.la was installed by package xfce4-session-4.10.1_2
Pourdriere produces faulty build results due to bsd.openssl.mk bug
I found that packages produced by poudriere likely link with base openssl, while port make likely links with the port openssl. This is because of the lines in bsd.openssl.mk which check for the presence of openssl shared library and headers under PREFIX, and set WITH_OPENSSL_BASE when they aren't present. In case of port make files are likely present, and in case of poudriere build files are likely not present. Example is ftp/curl (with GSSAPI=NONE, OPENSSL=yes options). *Poudriere produces curl library, that causes VirtualBox to break* due to the openssl base vs. port conflicts. See recent emulation@ ML threads. Port make produces curl library that works fine with VirtualBox. I think both WITH_OPENSSL_BASE and WITH_OPENSSL_PORT should be retired, and code checking file presence also should be removed, and all ports should be made to build with an openssl port instead. Ports should never use base OpenSSL. Only 100 ports touch WITH_OPENSSL_... variables. Somebody who is able to make such decisions and has the commit bit should bit should look into this. Otherwise, massively faulty package repositories are produces. Yuri ___ 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: Pourdriere produces faulty build results due to bsd.openssl.mk bug
On 04/01/2015 15:08, Guido Falsi wrote: This would be good. What I am most worried about, though, are problems showing up at runtime only on specific configurations or use cases. This would help nailing them down. Such stage-qa check will currently likely fail on many ports. It can help in testing after the removal of the said dependencies on base OpenSSL, and should be permanently enabled afterwards. Currently VirtualBox is broken when installed out of the default package repository. I also observed that rebuilding only curl locally doesn't help for other broken things, and one also needs to rebuild kde4-network, and maybe other things. So the problem is quite nasty. It has been triggered by some curl update during March. Check the last entry about asterisk in UPDATING too (I maintain it and that one did hit me on a server of mine) Yes, things shouldn't need to be disabled just because of this conflict. Yuri ___ 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
