Re: Trubles compiling lxqt on RPi4

[Rainer Hurling]

Am 13.05.21 um 17:39 schrieb bob prohaska:
> On Thu, May 13, 2021 at 08:13:07AM +0200, Jan Beich wrote:
>>>
>>> Moving to /usr/ports/json-glib and using 
>>> make -DBATCH MAKE_JOBS_UNSAFE=yes MAKE_JOBS_NUMBER=4 
>>> DISABLE_VULNERABILITIES=yes > make.log
>>> reports several instances of 
>>> error: unknown argument: '-fno-color-diagnostics'
>>
>> Likely caused by desync between USES=meson and devel/meson, see
>> https://cgit.freebsd.org/ports/commit/?id=ff2796d5bc83
>>
>> Try again after re-installing devel/meson.
> 
> That might be a hint which circles back to Mark's comments related to
> python37 vs -38. Trying to re-make devel/meson finds.
> 
> root@nemesis:/usr/ports/devel/meson # make -DBATCH FORCE_PKG_REGISTER=yes 
> install
> ===>   meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===>  Installing for py38-setuptools-44.0.0_1
> ===>   Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0 
> (installs files into the same place).  Problematic file: 
> /usr/local/bin/easy_install
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/devel/py-setuptools
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/devel/meson
> 
> The fix for the -37 vs-38 conflict invokes portmaster, might it 
> suffice to simply deinstall -37 and explicitly replace it with
> -38 ? I'll give it a try.
> 
> Hmm, no dice. After deinstalling python37 and reinstalling python38 an
> attempt to make devel/meson still stops with
> 
> root@nemesis:/usr/ports/devel/meson # make -DBATCH 
> DISABLE_VULNERABILITIES=yes install
> ===>   meson-0.57.1_1 depends on package: py38-setuptools>0 - not found
> ===>  Installing for py38-setuptools-44.0.0_1
> ===>  Checking if py38-setuptools is already installed
> ===>   Registering installation for py38-setuptools-44.0.0_1 as automatic
> Installing py38-setuptools-44.0.0_1...
> pkg-static: py38-setuptools-44.0.0_1 conflicts with py37-setuptools-44.0.0 
> (installs files into the same place).  Problematic file: 
> /usr/local/bin/easy_install
> *** Error code 1
> 

For me this works:

portmaster -o devel/py-setuptools py37-setuptools-44.0.0

HTH,
Rainer

> How did python38 get installed without py38-setuptools?
> 
> bob prohaska
___
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: gdal

[Rainer Hurling]

Am 02.05.21 um 19:55 schrieb LuMiWa via freebsd-ports:
> Hi!
> 
> I have a problem to build graphics/gdal on FreeBSD-13.0-RELEASE:
> m::seekp' declared here: type mismatch at 1st parameter ('uint64_t'
> (aka 'unsigned long') vs 'GInt64' (aka 'long long')) virtual void
>  seekp (uint64_t pos) = 0; ^
> exrdataset.cpp:495:1: error: unknown type name 'Int64'; did you mean
> 'GInt64'? Int64 GDALEXRIOStream::tellg ()
> ^
> GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig  GInt64;
>  ^
> exrdataset.cpp:497:24: error: unknown type name 'Int64'; did you mean
> 'GInt64'? return static_cast(VSIFTellL(m_fp));
>^
>GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig  GInt64;
>  ^
> exrdataset.cpp:500:30: error: unknown type name 'Int64'; did you mean
> 'GInt64'? void GDALEXRIOStream::seekg (Int64 pos)
>  ^
>  GInt64
> /usr/ports/graphics/gdal/work/gdal-3.2.2/port/cpl_port.h:267:26: note:
> 'GInt64' declared here typedef GIntBig  GInt64;
>  ^
> exrdataset.cpp:566:36: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pIStream.reset(new GDALEXRIOStream(fp,
> osFilename)); ^
> exrdataset.cpp:992:25: error: variable type 'GDALEXRIOStream' is an
> abstract class GDALEXRIOStream ostream(fp, pszFilename);
> ^
> exrdataset.cpp:1984:32: error: allocating an object of abstract class
> type 'GDALEXRIOStream' poDS->m_pOStream.reset(new GDALEXRIOStream(fp,
> pszFilename)); ^
> 3 warnings and 14 errors generated.
> gmake[4]: *** [../../GDALmake.opt:646: ../o/exrdataset.o] Error 1
> gmake[4]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts/exr' gmake[3]: ***
> [GNUmakefile:15: exr-install-obj] Error 2 gmake[3]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2/frmts' gmake[2]: ***
> [GNUmakefile:114: frmts-target] Error 2 gmake[2]: Leaving directory
> '/usr/ports/graphics/gdal/work/gdal-3.2.2' *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/graphics/gdal
> *** Error code 1
> 
> Thank you.
> 
> 
I just opened a PR with a patch, which should solve the issue ;)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255592

HTH,
Rainer

___
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: Help with changing gitlab based download urls in ports

[Rainer Hurling]

Am 10.04.21 um 14:22 schrieb Matthias Fechner:
> Am 07.04.2021 um 17:12 schrieb Matthias Fechner:
>> This also causes gitlab-ce to be not fetchable anymore.
>> I already created a review to fix this here (sry, it also includes an
>> upgrade of gitlab-ce, but without the upgrade, it would not be
>> possible to testbuild this modification):
>> https://reviews.freebsd.org/D29628
> 
> the problem is now fixed in main and 2021Q2.
> 
> Matthias

Hi Matthias,

Thank you very much for this extensive and rather boring job :)

Best wishes,
Rainer
___
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: gstreamer1-plugins-opencv

[Rainer Hurling]

Am 31.01.21 um 10:13 schrieb Stefan Ehmann:
> On Sunday, January 31, 2021 12:43:27 AM CET LuMiWa via freebsd-ports wrote:
>> ...doesn't built on FreeBSD 12.2-RELEASE-p3 after update of opencv:
>>
>> opencv_1.0_la-gstopencvutils.lo -MD -MP -MF
>> .deps/libgstopencv_1.0_la-gstopencvutils.Tpo -c gstopencvutils.cpp
>> -fPIC -DPIC -o .libs/libgstopencv_1.0_la-gstopencvutils.o
>> gstopencvutils.cpp:28:10: fatal error: 'opencv2/core.hpp' file not
>> found #include  ^~ 1 error generated.
>> gmake[1]: *** [Makefile:866: libgstopencv_1.0_la-gstopencvutils.lo]
>> Error 1 gmake[1]: Leaving directory
>> '/usr/ports/graphics/gstreamer1-plugins-opencv/work/gst-plugins-bad-1.16.2/g
>> st-libs/gst/opencv' *** Error code 2
>>
>> Stop.
>> make: stopped in /usr/ports/graphics/gstreamer1-plugins-opencv
>>
>> ===>>> make build failed for graphics/gstreamer1-plugins-opencv
>> ===>>> Aborting update
>>
>> Thank you.
> 
> frei0r-plugins-opencv ist also broken after the update to graphics/opencv.

I prepared a review on Phabricator [1], which should solve the problem
for graphics/frei0r :)

[1] https://reviews.freebsd.org/D28436


> ___
> 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: Warning: Major OS version upgrade detected

[Rainer Hurling]

Am 30.01.21 um 23:02 schrieb Xavier Humbert:
> Hi,
> 
> I was running 13-CURRENT, and as of 01/22 I switched to 13-STABLE
> 
> Now, when I run any ports/pkg command - I use only ports-, I got
> 
>> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg
>> bootstrap -f" recommended
> No a big deal, I thought, but :
> 
>> [root@numenor ~]# pkg bootstrap -f
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]: y
>> Bootstrapping pkg from
>> pkg+http://pkg.FreeBSD.org/FreeBSD:13:amd64/latest, please wait...
>> Verifying signature with trusted certificate
>> pkg.freebsd.org.2013102301... done
>> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg
>> bootstrap -f" recommended
>> Installing pkg-1.16.2...
>> pkg-static: wrong architecture: FreeBSD:13:amd64 instead of
>> *FreeBSD:14:amd64*
>> package pkg is already installed, forced install
>> Extracting pkg-1.16.2: 100%
>> [root@numenor ~]# pkg check -Bd
>> pkg: Warning: Major OS version upgrade detected.  Running "pkg
>> bootstrap -f" recommended
> 
> The message is still there. I never had 14-CURRENT on this system.
> 
> Reinstalled ports-mgmt/pkg from source, didn't help

I had the exactly same error message.

It turns out, that in my /etc/pkg/FreeBSD.conf instead of '${ABI}' there
was a hardcoded '13' in the url entry. Probably I did a bad job last
time I 'repaired' that file after upgrading from 12.0-CURRENT to
13.0-CURRENT manually ;)

This is how it works for me:

#cat /etc/pkg/FreeBSD.conf
FreeBSD: {
  url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest;,
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

HTH,
Rainer

> 
> Any help ?
> 
> Thanks,
> 
> Xavier
> 

___
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: Need a commiter

[Rainer Hurling]

Am 16.01.21 um 13:08 schrieb Nuno Teixeira:
> Hello,
> 
> Could a commiter take a look at:
> 
> 252635 
> 252601 
> 251917 
> 
> Thank you!
> 
> Nuno Teixeira

I take 252601 :)
___
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"

License question - New port databases/libmswstr

[Rainer Hurling]

I intend to update my databases/mdbtools port and add a new
databases/libmswstr [1] port as a dependency. This new port should allow
mdbtools to use indexes of databases in JET4 format.

[1] https://reviews.freebsd.org/D27955

The author of libmswstr [2] did not include a license [3] with his
Github project.

[2] https://github.com/leecher1337/libmswstr
[3] https://github.com/leecher1337/libmswstr/blob/master/COPYING

It is not clear to me whether the reverse-engineered data and structures
of libmswstr violate license terms and should therefore not be included
as a port in FreeBSD.

Personally, I think that this form of reverse engineering also happens
in many other projects and therefore no legal problems are to be expected.

Are there any ideas or statements on this in the community?

Thanks in advance.

Regards,
Rainer Hurling
___
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: lang/gauche 0.9.10

[Rainer Hurling]

Am 17.12.20 um 21:24 schrieb Lassi Kortela:
> Hello,
> 
> Here's a patch to update the Gauche port to version 0.9.10, released a
> few days ago. There's a commit message on top of the patch.
> 
> This is my first port submission of any kind so a quick review by an
> experienced porter would be much appreciated. I ran `make makeplist` to
> regenerate pkg-plist, hand-editing a few things afterwards. portlint
> gave no warnings. The interpreter seems to work, man pages and GNU info
> files are readable; in particular, I tested HTTPS using mbedTLS.
> 
> KR,
> Lassi

Hi Lassi,

Thanks for your first patch, and congrats: It applies fine against the
port :)

I build tested it a bit and found some minor issues, for which I
prepared an updated version of your patch, see attachment. In this
updated patch the most important differences against your patch are:

- Defining a variable ABI_VERSION=0.97 for the changes in the
post-install target and for pkg-plist. This should make it more readable?

- manpages should be installed using OPTION MANPAGES. I put it to the
default options. One can enable and disable it per 'make config'

- The bash replacement for src/gen-features.sh is not needed (sh already)

- The URL in pkg-descr should better begin with https (secured)


I would suggest, that you open a PR in Bugzilla [1]. That would make it
much easier for committers to test and subsequently commit your patch ;)
 If you have questions about how to proceed, please feel free and ask.

[1] https://bugs.freebsd.org/bugzilla/


Last but not least: No port should be orphaned. Would you like to take
maintainership of the port?
More information about port maintainership is available at:

https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html#maintain-port


Best wishes,
Rainer
Index: lang/gauche/Makefile
===
--- lang/gauche/Makefile	(revision 558456)
+++ lang/gauche/Makefile	(working copy)
@@ -2,9 +2,9 @@
 # $FreeBSD$
 
 PORTNAME=	gauche
-PORTVERSION=	0.9.9
+PORTVERSION=	0.9.10
 CATEGORIES=	lang scheme
-MASTER_SITES=	SF/${PORTNAME}/Gauche
+MASTER_SITES=	https://github.com/shirok/Gauche/releases/download/release0_9_10/
 DISTNAME=	Gauche-${PORTVERSION}
 
 MAINTAINER=	po...@freebsd.org
@@ -21,24 +21,27 @@
 GNU_CONFIGURE=	yes
 CONFIGURE_ARGS=	--with-local=${LOCALBASE} ${ICONV_CONFIGURE_BASE:S/lib//}
 USE_LDCONFIG=	yes
-MAKE_JOBS_UNSAFE=yes
+#MAKE_JOBS_UNSAFE=yes
 TEST_TARGET=	check
+ABI_VERSION=	0.97
 
-PLIST_SUB=	VERSION="${PORTVERSION}" \
+PLIST_SUB=	ABI_VERSION="${ABI_VERSION}" \
+		VERSION="${PORTVERSION}" \
 		TARGET="${CONFIGURE_TARGET}"
 
-# avoids a problem with with ccache's pre-processor optimization
+# avoids a problem with ccache's pre-processor optimization
 MAKE_ENV+=	CCACHE_CPP2=1
 TEST_ENV=	# must be empty, otherwise cf-check-lib test fails
 
 INFO=		gauche-refe gauche-refj
 
-OPTIONS_DEFINE=		GDBM THREADS SLIB
+OPTIONS_DEFINE=		GDBM THREADS SLIB MANPAGES
 OPTIONS_RADIO=		MULTIBYTE TLS
 OPTIONS_RADIO_MULTIBYTE=	EUCJP SJIS UTF8
 OPTIONS_RADIO_TLS=	AXTLS MBEDTLS
-OPTIONS_DEFAULT=	AXTLS THREADS UTF8
+OPTIONS_DEFAULT=	MBEDTLS THREADS UTF8 MANPAGES
 OPTIONS_SUB=		yes
+NO_OPTIONS_SORT=	yes
 
 AXTLS_DESC=		Cameron Rich's axTLS implementation (bundled)
 AXTLS_CONFIGURE_ON=	--with-tls=axtls
@@ -47,8 +50,9 @@
 GDBM_LIB_DEPENDS=	libgdbm.so:databases/gdbm
 GDBM_CONFIGURE_ON=	--with-dbm=gdbm,ndbm
 GDBM_CONFIGURE_OFF=	--with-dbm=ndbm
+MBEDTLS_RUN_DEPENDS=	${LOCALBASE}/share/certs/ca-root-nss.crt:security/ca_root_nss
 MBEDTLS_LIB_DEPENDS=	libmbedtls.so:security/mbedtls
-MBEDTLS_CONFIGURE_ON=	--with-tls=mbedtls
+MBEDTLS_CONFIGURE_ON=	--with-tls=mbedtls --with-ca-bundle=${LOCALBASE}/share/certs/ca-root-nss.crt
 SLIB_DESC=		Create catalogue for SLIB port
 # Gauche's slib module to use Aubrey Jaffer's SLIB
 SLIB_BUILD_DEPENDS=	${LOCALBASE}/share/slib/require.scm:lang/slib
@@ -71,7 +75,6 @@
 .endif
 
 post-patch:
-	@${REINPLACE_CMD} -e 's,/bash,/sh,' ${WRKSRC}/src/gen-features.sh
 # required for sparc64, no-op elsewhere
 	@${REINPLACE_CMD} -e \
 		'/^VPATH = /s,$$,/src,' ${WRKSRC}/gc/Makefile.in
@@ -81,13 +84,13 @@
 		's,darwin,&|${OPSYS:tl},' ${WRKSRC}/test/scripts.scm
 
 post-install:
-	@${TOUCH} ${STAGEDIR}${PREFIX}/lib/gauche-0.97/site/${CONFIGURE_TARGET}/.keepme
+	@${TOUCH} ${STAGEDIR}${PREFIX}/lib/gauche-${ABI_VERSION}/site/${CONFIGURE_TARGET}/.keepme
 	@${MKDIR} ${STAGEDIR}${DATADIR}/${PORTVERSION}/lib/.packages
 	@${TOUCH} ${STAGEDIR}${DATADIR}/${PORTVERSION}/lib/.packages/.keepme
 	@${MKDIR} ${STAGEDIR}${DATADIR}/site/lib/.packages
 	@${TOUCH} ${STAGEDIR}${DATADIR}/site/lib/.packages/.keepme
-	@${MKDIR} ${STAGEDIR}${PREFIX}/share/gauche-0.97/site/lib/.packages
-	@${TOUCH} ${STAGEDIR}${PREFIX}/share/gauche-0.97/site/lib/.packages/.keepme
+	@${MKDIR} ${STAGEDIR}${PREFIX}/share/gauche-${ABI_VERSION}/site/lib/.packages
+	@${TOUCH} ${STAGEDIR}${PREFIX}/share/gauche-${ABI_VERSION}/site/lib/.packages/.keepme
 	@${MKDIR} ${STAGEDIR}${DOCSDIR}
 	

Re: textproc/cast2gif not compiling on i386

[Rainer Hurling]

Hi Nuno,

I think you are right. cargo-crates/font-kit lists only the following
platforms:

  x86_64-unknow-linux-gnu
  x86_64-pc-windows-msvc
  i686-pc-windows-msvc
  x86_64-apple-darwin

ONLY_FOR_ARCHS=amd64 seems right to me.

Greetings,
Rainer


Am 07.12.20 um 08:09 schrieb Nuno Teixeira:
> Hello,
> 
> textproc/cast2gif is not compiling on i386 and "expected `i32`, found
> `i64`" error seems to tell that font-kit rust dependency is not i386
> buildable.
> 
> Should I use ONLY_FOR_ARCHS= amd64?
> 
> Full log
> 
> 
> Thanks,
> 
> Nuno Teixeira
> 
> (...)
> 
> error[E0308]: mismatched types
>--> 
> /wrkdirs/usr/ports/textproc/cast2gif/work/cast2gif-4f76eeb/cargo-crates/font-kit-0.6.0/src/loaders/freetype.rs:811:21
> |
> 811 | yy: matrix.w() as i64,
> | ^ expected `i32`, found `i64`
> 
> error: aborting due to 6 previous errors
> 
> For more information about this error, try `rustc --explain E0308`.
> error: could not compile `font-kit`
> 
> Caused by:
>   process didn't exit successfully: `/usr/local/bin/rustc --crate-name
> font_kit --edition=2018
> /wrkdirs/usr/ports/textproc/cast2gif/work/cast2gif-4f76eeb/cargo-crates/font-kit-0.6.0/src/lib.rs
> --error-format=json --json=diagnostic-rendered-ansi,artifacts
> --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C
> linker-plugin-lto --cfg 'feature="default"' --cfg 'feature="freetype"'
> --cfg 'feature="loader-freetyp
> 
> (...)
> ___
> 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: Could a comitter take a look

[Rainer Hurling]

Am 28.11.20 um 04:18 schrieb Nuno Teixeira:
> Hello,
> 
> Could a commiter take a look at:
> 
> - new ports: 251064
>  251309

Hi Nuno,

For PR 251064 (textproc/cast2gif) I showed in comment #7, that there is
a problem building your port. This has to be solved by someone (probably
you?) before a commit.

Regards,
Rainer


> 
> 
> - adoption/takeover: 251072
>  251397
> 
> 
> Thanks,
> 
> Nuno Teixeira

___
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: Portlint complains about %%FOO%% in PLIST_FILES

[Rainer Hurling]

Hi Yuri,

Am 24.11.20 um 10:06 schrieb Yuri Pankov:

Rainer Hurling wrote:
Yesterday I committed net/hblock [r556099] after changing the patch to 
PLIST_FILES (instead of pkg-plist with only two files) against the 
suggestion of the submitter. The line in question is:


PLIST_FILES=bin/${PORTNAME} %%MANPAGES%%man/man1/hblock.1.gz


I made this change because it allows the port to build and install 
correctly in all combinations of OPTIONS.


With the use of %%MANPAGES%%% in PLIST_FILES one can selectively 
enable and disable the building of manpages.


The maintainer of net/hblock informs me about a problem with using 
%%MANPAGES%% in PLIST_FILES. I don't know why I did not notice the 
message from 'portlint -AC' before:


FATAL: PLIST_FILES: files cannot contain %%FOO%% variables.  Use make 
variables and logic instead



Is it possibly correct to use %%MANPAGES%% in PLIST_FILES and only 
portlint can't handle it?


Is there an alternative to switching back to pkg-plist file?


Thanks in advance for clarification and maybe a suggestion for correct 
usage.


See 5.13.3.11 in 
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-options.html, 
i.e. use MANPAGES_PLIST_FILES=.

See x11/swaybg/Makefile for example.


That's it! Thanks for the hint :)

I will prepare a patch for net/hblock ...
___
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"

Portlint complains about %%FOO%% in PLIST_FILES

[Rainer Hurling]

Yesterday I committed net/hblock [r556099] after changing the patch to 
PLIST_FILES (instead of pkg-plist with only two files) against the 
suggestion of the submitter.The line in question is:


PLIST_FILES=bin/${PORTNAME} %%MANPAGES%%man/man1/hblock.1.gz


I made this change because it allows the port to build and install 
correctly in all combinations of OPTIONS.


With the use of %%MANPAGES%%% in PLIST_FILES one can selectively enable 
and disable the building of manpages.


The maintainer of net/hblock informs me about a problem with using 
%%MANPAGES%% in PLIST_FILES. I don't know why I did not notice the 
message from 'portlint -AC' before:


FATAL: PLIST_FILES: files cannot contain %%FOO%% variables.  Use make 
variables and logic instead



Is it possibly correct to use %%MANPAGES%% in PLIST_FILES and only 
portlint can't handle it?


Is there an alternative to switching back to pkg-plist file?


Thanks in advance for clarification and maybe a suggestion for correct 
usage.


Regards,
Rainer Hurling
___
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: Poudriere: Installing or updating jails fail with cp/utils.c error

[Rainer Hurling]

On 02.10.20 11:19, Rainer Hurling wrote:
> For some time now, I get the following error when trying to create or
> update 11.4 or 12.2 jails in Poudriere:
> 
> 
> #poudriere jail -c -j F114i386 -v stable/11 -a i386 -m svn+https
> 
> [..snip..]
> --- all_subdir_rescue ---
> --- /poudriere/jails/F114i386/usr/src/bin/cp/utils.o ---
> cc  -O2 -pipe   -std=gnu99    -Qunused-arguments   -O2 -pipe -c
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c -o
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.o
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:515:14: error: member
> reference base type 'void' is not a structure or union
>     aclp = >ats_acl;
>     ~~~^ ~~~
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:516:11: error:
> incomplete definition of type 'struct acl'
>     if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
>     ^
> /poudriere/jails/F114i386/usr/src/bin/cp/utils.c:466:9: note: forward
> declaration of 'struct acl'
>     struct acl *aclp;
>    ^
> 2 errors generated.
> *** [/poudriere/jails/F114i386/usr/src/bin/cp/utils.o] Error code 1
> 
> make[5]: stopped in
> /usr/obj/i386.i386/poudriere/jails/F114i386/usr/src/rescue/rescue
> 
> 
> This happens on a recent 13.0-CURRENT amd64 (r366190). Updating HEAD
> jails work fine so far.

Just for the record:

After updating my (host) box to 13.0-CURRENT r366466 (crunchgen: fix
MK_AUTO_OBJ logic), I am able to install and update my jails versions
11.4 and 12.1 on Poudriere again.

> 
> Am I doing something wrong? I thought, the cp/utils.c problem was solved
> some time ago?
> 
> Thanks for any insight and help.
> 
> Regards,
> Rainer Hurling

___
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"

Poudriere: Installing or updating jails fail with cp/utils.c error

[Rainer Hurling]

For some time now, I get the following error when trying to create or 
update 11.4 or 12.2 jails in Poudriere:



#poudriere jail -c -j F114i386 -v stable/11 -a i386 -m svn+https

[..snip..]
--- all_subdir_rescue ---
--- /poudriere/jails/F114i386/usr/src/bin/cp/utils.o ---
cc  -O2 -pipe   -std=gnu99-Qunused-arguments   -O2 -pipe -c 
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c -o 
/poudriere/jails/F114i386/usr/src/bin/cp/utils.o
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c:515:14: error: member 
reference base type 'void' is not a structure or union

aclp = >ats_acl;
~~~^ ~~~
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c:516:11: error: 
incomplete definition of type 'struct acl'

if (aclp->acl_cnt != 0 && aclsetf(dest_dir,
^
/poudriere/jails/F114i386/usr/src/bin/cp/utils.c:466:9: note: forward 
declaration of 'struct acl'

struct acl *aclp;
   ^
2 errors generated.
*** [/poudriere/jails/F114i386/usr/src/bin/cp/utils.o] Error code 1

make[5]: stopped in 
/usr/obj/i386.i386/poudriere/jails/F114i386/usr/src/rescue/rescue



This happens on a recent 13.0-CURRENT amd64 (r366190). Updating HEAD 
jails work fine so far.


Am I doing something wrong? I thought, the cp/utils.c problem was solved 
some time ago?


Thanks for any insight and help.

Regards,
Rainer Hurling
___
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: nvidia-driver vs. mesa-libs

[Rainer Hurling]

Hi Russel,

There is a PR opened already:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249448

You could try the patch or wait until x11/nvidia-driver* is updated.

HTH,
Rainer


On 20.09.20 21:12, Russell L. Carter wrote:
> Hi folks,
> 
> I'm running FreeBSD-stable amd64, updated monthly.  Every Sat.  night
> I svn update and rebuild my ports with poudriere.  This has been
> working smoothly for several years.  I have also been running
> nvidia-driver for several years without issue.
> 
> This morning 'pkg upgrade' presents me with the following situation:
> 
> (I also try to pkg remove mesa-libs below this output)
> 
> ***
> 
> Updating pinyon repository catalogue...
> Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
> Fetching packagesite.txz: 100%  366 KiB 374.7kB/s    00:01
> Processing entries: 100%
> pinyon repository update completed. 1511 packages processed.
> All repositories are up to date.
> Checking for upgrades (83 candidates): 100%
> Processing candidates (83 candidates): 100%
> Checking integrity... done (2 conflicting)
>   - mesa-libs-19.0.8_3 conflicts with nvidia-driver-440.100 on
> /usr/local/lib/libGLESv1_CM.so
>   - mesa-libs-19.0.8_3 conflicts with nvidia-driver-440.100 on
> /usr/local/lib/libGLESv1_CM.so
> Checking integrity... done (0 conflicting)
> The following 85 package(s) will be affected (of 0 checked):
> 
> Installed packages to be REMOVED:
>     nvidia-driver: 440.100
> 
> New packages to be INSTALLED:
>     botan2: 2.15.0
> 
> Installed packages to be UPGRADED:
>     alsa-utils: 1.1.2 -> 1.1.2_1
>     cairo: 1.17.2,2 -> 1.16.0,3
>     dconf: 0.36.0 -> 0.38.0
>     desktop-file-utils: 0.24 -> 0.26
>     emacs-devel: 28.0.50.20200901,2 -> 28.0.50.20200915,2
>     firefox: 80.0.1,2 -> 81.0,2
>     go: 1.15.1,1 -> 1.15.2,1
>     graphene: 1.10.0 -> 1.10.2
>     gtk3: 3.24.20 -> 3.24.23
>     htop: 2.2.0_1 -> 3.0.2
>     intel-media-sdk: 20.2.1 -> 20.3.p6
>     jasper: 2.0.16_1 -> 2.0.20
>     json-glib: 1.4.4 -> 1.6.0
>     kf5-attica: 5.73.0 -> 5.74.0
>     kf5-breeze-icons: 5.73.0 -> 5.74.0
>     kf5-extra-cmake-modules: 5.73.0 -> 5.74.0
>     kf5-kactivities: 5.73.0 -> 5.74.0
>     kf5-karchive: 5.73.0 -> 5.74.0
>     kf5-kauth: 5.73.0 -> 5.74.0
>     kf5-kbookmarks: 5.73.0 -> 5.74.0
>     kf5-kcmutils: 5.73.0 -> 5.74.0
>     kf5-kcodecs: 5.73.0 -> 5.74.0
>     kf5-kcompletion: 5.73.0 -> 5.74.0
>     kf5-kconfig: 5.73.0 -> 5.74.0
>     kf5-kconfigwidgets: 5.73.0 -> 5.74.0
>     kf5-kcoreaddons: 5.73.0 -> 5.74.0
>     kf5-kcrash: 5.73.0 -> 5.74.0
>     kf5-kdbusaddons: 5.73.0 -> 5.74.0
>     kf5-kdeclarative: 5.73.0 -> 5.74.0
>     kf5-kded: 5.73.0 -> 5.74.0
>     kf5-kdelibs4support: 5.73.0 -> 5.74.0
>     kf5-kdesignerplugin: 5.73.0 -> 5.74.0
>     kf5-kdewebkit: 5.73.0 -> 5.74.0
>     kf5-kdoctools: 5.73.0 -> 5.74.0
>     kf5-kemoticons: 5.73.0 -> 5.74.0
>     kf5-kglobalaccel: 5.73.0 -> 5.74.0
>     kf5-kguiaddons: 5.73.0 -> 5.74.0
>     kf5-khtml: 5.73.0 -> 5.74.0
>     kf5-ki18n: 5.73.0 -> 5.74.0
>     kf5-kiconthemes: 5.73.0 -> 5.74.0
>     kf5-kinit: 5.73.0 -> 5.74.0
>     kf5-kio: 5.73.0 -> 5.74.1
>     kf5-kirigami2: 5.73.0 -> 5.74.0
>     kf5-kitemmodels: 5.73.0 -> 5.74.0
>     kf5-kitemviews: 5.73.0 -> 5.74.0
>     kf5-kjobwidgets: 5.73.0 -> 5.74.0
>     kf5-kjs: 5.73.0 -> 5.74.0
>     kf5-knotifications: 5.73.0 -> 5.74.0
>     kf5-kpackage: 5.73.0 -> 5.74.0
>     kf5-kparts: 5.73.0 -> 5.74.0
>     kf5-kplotting: 5.73.0 -> 5.74.0
>     kf5-kpty: 5.73.0 -> 5.74.0
>     kf5-kservice: 5.73.0 -> 5.74.0
>     kf5-ktextwidgets: 5.73.0 -> 5.74.0
>     kf5-kunitconversion: 5.73.0 -> 5.74.0
>     kf5-kwallet: 5.73.0 -> 5.74.0
>     kf5-kwidgetsaddons: 5.73.0 -> 5.74.0
>     kf5-kwindowsystem: 5.73.0 -> 5.74.0
>     kf5-kxmlgui: 5.73.0 -> 5.74.0
>     kf5-purpose: 5.73.0 -> 5.74.0
>     kf5-solid: 5.73.0 -> 5.74.0
>     kf5-sonnet: 5.73.0 -> 5.74.0
>     kf5-threadweaver: 5.73.0 -> 5.74.0
>     libmtdev: 1.1.5_2 -> 1.1.5_3
>     libnotify: 0.7.8 -> 0.7.9
>     libva: 2.8.0 -> 2.9.0
>     libxcb: 1.13.1 -> 1.14_1
>     libxkbcommon: 0.10.0_2 -> 1.0.1
>     mesa-libs: 19.0.8_2 -> 19.0.8_3
>     nasm: 2.15.03,1 -> 2.15.05,1
>     nautilus: 3.28.1_3 -> 3.28.1_4
>     net-snmp: 5.7.3_20,1 -> 5.9,1
>     nspr: 4.28 -> 4.29
>     p5-HTTP-Message: 6.25 -> 6.26
>     p5-Mojolicious: 8.58 -> 8.59
>     qt5-webengine: 5.15.0_2 -> 5.15.0_3
>     qtchooser: 66_3 -> 66_4
>     thunderbird: 68.12.0_2 -> 78.2.2
>     xf86-video-vesa: 2.4.0_3 -> 2.5.0
>     xorg-server: 1.20.8_4,1 -> 1.20.9,1
> 
> Installed packages to be REINSTALLED:
>     evince-3.28.5_18 (direct 

Re: LibreOffice 7.0 call for testing

[Rainer Hurling]

Hi Dima,

Am 16.07.20 um 07:17 schrieb Dima Panov:
> Hello!
> 
> LibreOffice 7.0 branch is over to release candadate and office@FreeBSD team 
> calls everyone interested to join us in testing cycle
> 
> Our WIP repository available at GitHub, 
> https://github.com/lwhsu/freebsd-ports-libreoffice, branch 7.0.0
> 
> Of course, we support ports’ OVERLAY feature by adding:
> 
> OVERLAYS+=/path/to/freebsd-ports-libreoffice
> 
> to /etc/make.conf
> 
> Poudriere users should follows next steps:
> 
> sudo poudriere ports -c -F -p portoverlay
> cd ${LOCALBASE}/poudriere/ports/portsoverlay
> git clone https://github.com/lwhsu/freebsd-ports-libreoffice .
> git checkout 7.0.0
> poudriere bulk -j 121amd64 -p portstree -O portsoverlay editors/libreoffice
> 
> Or you can use pre-built packages with default options.
> Take yours from https://people.freebsd.org/~lwhsu/libreoffice/
> 
> You can start the LibreOffice with x11 UI backend by setting
> environment variable:
> 
> SAL_USE_VCLPLUGIN=gen
> 
> where ‘gen’ can be replaced by x11, gtk3, qt5 ,kf5, depends on selected build 
> options to get a required vcl active
> 
> Current known issue is missed vertical and gorizontal scrollbars with gkt3 
> vcl.
> Qt5 vcl is already locked to use cairo font renderer.
> 
> Patches and suggestions are welcome!
> 
> --
> WBR, Dima. (Desktop, KDE, X11, Office)@FreeBSD team
> (flu...@freebsd.org, https://t.me/dima_panov)
> 

Many thanks for the possibility to test the 7.0.0.1 port before the
release is coming. Much appreciated!

I built the port with Poudriere on a 13.0-CURRENT box. It builts and
installs fine. As far as I can say after testing with some types of
files, the following works as expected:

- opening .odt, .docx, .xlsx
- saving the same formats
- opening encrypted files
- exporting to pdf

Using SAL_USE_VCLPLUGIN=kf5, rendering seems fine for me.

Could hardly await the final release of libreoffice and the port :)

Best wishes,
Rainer
___
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: ffmpeg 4.2.3'1

[Rainer Hurling]

Am 23.05.20 um 11:17 schrieb ajtiM via freebsd-ports:
> On FreeBSD 12.1-RELEASE-p5 I cannot build ffmpeg update:
> 
> ===>  Cleaning for ffmpeg-4.2.3,1
> ===>  License GPLv3+ LGPL3+ accepted by the user
> ===>   ffmpeg-4.2.3,1 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by ffmpeg-4.2.3,1 for building
> ===>  Extracting for ffmpeg-4.2.3,1
> => SHA256 Checksum OK for ffmpeg-4.2.3.tar.xz.
> => SHA256 Checksum OK for
> 0001-Add-ability-for-ffmpeg-to-run-svt-vp9.patch. ===>  Patching for
> ffmpeg-4.2.3,1 ===>  Applying distribution patches for ffmpeg-4.2.3,1
> 2 out of 8 hunks failed--saving rejects to libavformat/matroskaenc.c.rej
> ===>  FAILED Applying distribution patch
> 0001-Add-ability-for-ffmpeg-to-run-svt-vp9.patch with -p1 *** Error
> code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/multimedia/ffmpeg
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/multimedia/ffmpeg
> 
> ===>>> make build failed for multimedia/ffmpeg
> ===>>> Aborting update
> 
> ===>>> Update for multimedia/ffmpeg failed
> ===>>> Aborting update
> 
> Thank you.
> 

VVD alread opened PR 246673 [1] about this failure.


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246673
___
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: OpenSSL multiple names?

[Rainer Hurling]

Am 08.02.20 um 00:01 schrieb LuKreme:
> On Feb 7, 2020, at 13:20, Rainer Hurling  wrote:
>>
>> Did you try
>>
>> 'portmaster -o security/openssl openssl111-1.1.1d'
> 
> Yes, that failed with no error. Trying to uninstall openssl111 said there was 
> no such port.

That could be because of an already deinstalled openssl111, if you tried
before with portmaster. In such cases, the reinstallation failed, but a
copy of the precedent installation is under
/usr/ports/packages/portmaster-backup ...

> 
>> (with DEFAULT_VERSIONS= ssl=openssl, instead ssl=openssl111)?
> 
> That was set back in January.
> 
>> For me, that worked.
> 
> pkg delete -f openssl111
> cd security/openssl 
> make install
> 
> That worked.

Nice to hear.
___
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: OpenSSL multiple names?

[Rainer Hurling]

Am 07.02.20 um 19:16 schrieb @lbutlr:
> On 07 Feb 2020, at 11:06, @lbutlr  wrote:
>>  I updated openssl in January, and as I said it has been recompiled several 
>> times 
> 
> To be clear, I did everything that UPDATING 20200101 mentions, including 
> reinstalling all ports, changing make.conf, etc.
> 
> But all along, the system has reported that the version is openssl111-1.1.1, 
> until 05 Feb. BTW, there is no new version of openssl listed in Postmaster 
> and the distill in security/openssl says the date is Wed Sep 11 02:04:23 MDT 
> 2019.
> 
>  root # cat security/openssl/distinfo
>  
> [11:14] [/usr/ports] 
> TIMESTAMP = 1568189063
> SHA256 (openssl-1.1.1d.tar.gz) = 
> 1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2
> SIZE (openssl-1.1.1d.tar.gz) = 8845861
> 
> 
> 

Did you try

'portmaster -o security/openssl openssl111-1.1.1d'

(with DEFAULT_VERSIONS= ssl=openssl, instead ssl=openssl111)?

For me, that worked.
___
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: PR 23672 - java/eclipse update

[Rainer Hurling]

Hi Kurt,

Am 13.04.19 um 19:57 schrieb Kurt Jaeger:
> Hi!
> 
> While test-building java/eclipse in poudriere from 
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236792
> 
> I run into this problem: During the build, git is used to
> create a local git repo.
> 
> This works in current, because the build inside poudriere runs as root
> and therefore, this works:
> 
> git init
> git config --global user.email "ecli...@freebsd.org"
> git config --global user.name "Eclipse"
> git add .
> 
> It fails on 12.0 and 11.2, because the build is run as
> user nobody with 
> 
> home: /nonexistent
> error: could not lock config file /nonexistent/.gitconfig: No such file or 
> directory
> error: could not lock config file /nonexistent/.gitconfig: No such file or 
> directory
> 
> Any hints how I can force git to use existing directory as $HOME
> so that git does not fail ?
> 

Many thanks for the update. Eclipse 4.11 builds and installs fine!

Now I am trying to also update several tools inside ...

Best wishes,
Rainer
___
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: llvm60 required by ???

[Rainer Hurling]

[resend, because forgot to include po...@freebsd.org]

On my systems there are also the following ports as dependencies of llvm60

libpgmath-g20180904
flang-6.0.g20180904_1
flang-clang-6.0.g20180904_3
qt5-qdoc-5.12.0_1

They seem to need llvm60.


Am 11.01.19 um 22:33 schrieb Robert Huff:
> 
>   Is there anything other than mesa-dri that requires this port?
> 
> 
>   Respectfully,
> 
> 
>   Robert Huff
___
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"

SIP configuration seems incomplete for Python3

[Rainer Hurling]

In the preparation of a new port for QGIS 3 (graphics/qgis) I need a
functioning sip installation under Python 3.x, to be able to build and
use QGIS Python plugins. Unfortunately, the QGIS scripts have problems
to find the right sip version and fail. After spending some time, I
think it is more a problem with Python 3 SIP than a QGIS one.

I have _not_ set

  DEFAULT_VERSIONS+= python=2.7 python2=2.7 python3=3.6

in /etc/make.conf, so 2.7 should be the default version (I need this for
other projects).

Installed for Python 3 are the following and other ports:

  python36-3.6.7
  py36-sip-4.19.8_1,1


sipconfig.py for both Python versions can be found under their Python dirs:

  # locate sipconfig.py
  /usr/local/lib/python2.7/site-packages/sipconfig.py
  /usr/local/lib/python2.7/site-packages/sipconfig.pyc
  /usr/local/lib/python2.7/site-packages/sipconfig.pyo
  /usr/local/lib/python3.6/site-packages/sipconfig.py

Interestingly enough, only sip under Python 2.7 seems to have a compiled
version.

The sip binaries are found on their expected locations. The one from the
default version 2.7 is linked against the unnumbered one:

  # ls /usr/local/bin/sip*
  ...  /usr/local/bin/sip -> sip-2.7
  ...  /usr/local/bin/sip-2.7
  ...  /usr/local/bin/sip-3.6


Now, in Python3, if I test for installed SIP configuration, I get:

  # python3
  Python 3.6.7 (default, Nov 18 2018, 09:23:28)
  [GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final
  335540)] on freebsd13
  Type "help", "copyright", "credits" or "license" for more
  information.
  >>> import sipconfig
  >>>
  >>> sipcfg = sipconfig.Configuration()
  >>> print("sip_version:%06.0x" % sipcfg.sip_version)
  sip_version:041308
  >>> print("sip_version_num:%d" % sipcfg.sip_version)
  sip_version_num:267016
  >>> print("sip_version_str:%s" % sipcfg.sip_version_str)
  sip_version_str:4.19.8
  >>> print("sip_bin:%s" % sipcfg.sip_bin)
  sip_bin:/usr/local/bin/sip-3.6
  >>> print("default_sip_dir:%s" % sipcfg.default_sip_dir)
  default_sip_dir:/usr/local/share/py36-sip
  ^
  >>> print("sip_inc_dir:%s" % sipcfg.sip_inc_dir)
  sip_inc_dir:/usr/local/include/python3.6m
  >>> # SIP 4.19.10+ has new sipcfg.sip_module_dir
  ... if hasattr(sipcfg, "sip_module_dir"):
  ... print("sip_module_dir:%s" % sipcfg.sip_module_dir)
  ... else:
  ... print("sip_module_dir:%s" % sipcfg.sip_mod_dir)
  ...
  sip_module_dir:/usr/local/lib/python3.6/site-packages
  >>>

The problem seems to be, that there is no

  /usr/local/share/py36-sip

any more. After the recent changes to PyQt it resides under

  /usr/loca/share/PyQt5/3.6/sip/


Obviously, there is something wrong with the detection of the right
location. Perhaps, the old patch (/usr/local/share/py36-sip) is
hardcoded somewhere?

Is this a general problem or is there something wrong with my
configuration? Any help is really appreciated.

Regards,
Rainer Hurling
___
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: QT4 problem with OpenSSL

[Rainer Hurling]

Am 23.11.18 um 18:56 schrieb Walter Schwarzenfeld:
> In PR
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214691
> 
> is a patch
> 
> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=199093=diff
> 
> 
> I have not tried it (have libressl), but maybe it helps.

I tried the patch some days before. It builds and installs fine, and for
me it seems to solve my problems so far (mainly graphics/qgis was not
able to start any more after the openssl changes).

HTH,
Rainer

___
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: pkg-plist and stage directory for new port

[Rainer Hurling]

Hi Marco,

just a few comments about your port stub.

Am 14.09.18 um 17:31 schrieb Marco Beishuizen:
> On Fri, 14 Sep 2018, the wise Lorenzo Salvadore via freebsd-ports wrote:
> 
>> Show us your makefile please.
> 
> The Makefile I have so far:
> 
> PORTNAME=    pgadmin4
> PORTVERSION=    3.3
> CATEGORIES=    databases
> MASTER_SITES=    PGSQL/pgadmin/pgadmin4/v${PORTVERSION}/source/

I would insert the next line, because it is common for Postgres ports
for years now, to hold the distfiles under distfiles/postgresql/

DIST_SUBDIR=postgresql

I think, the following line is not necessary, the port fetches and build
fine without it:
> DISTNAME=    pgadmin4-${PORTVERSION}

> 
> MAINTAINER=    mb...@xs4all.nl
> COMMENT=    PostgreSQL Administration Tool
> 
> LICENSE=    PostgreSQL
> 
> BUILD_DEPENDS    sphinx-build:textproc/py-sphinx
> USES=    pgsql python qmake:outsource qt:5
> USE_QT=    core gui network widgets
> QMAKE_SOURCE_PATH=    ${WRKSRC}/runtime
> 
> .include 
> 
>> When I created my first port, I remember I had some difficulty to
>> understand staging: imho it needs to be explained better in the
>> documentation. Are you aware of the variable ${STAGEDIR}? You probably
>> need to add to your makefile some lines similar to the followings:
>>
>> do-install:
>>   ${INSTALL_PROGRAM} ${WRKSRC}/??/pgAdmin4 ${STAGEDIR}${PREFIX}/bin
> 
> Quite possible that it's something like this. I'll dig into it.

Most of the needed stuff seems to be under ${WORKSRC}/runtime and
${WORKSRC}/web.

HTH a little bit.

Greetings,
Rainer

> 
> Thanks,
> 
> Marco
> 

___
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: U[dating Bind912 wants ghostscript?

[Rainer Hurling]

Am 07.09.18 um 09:46 schrieb @lbutlr:
> I went to update my install of Bind9 and it wanted to install a lot o new 
> things, including ghostscript (which I have been careful to keep off my 
> system due to many remotely exploitable vulnerabilities and a lack of need). 
> In fact, there were a lot of new packages it wanted to install which appear 
> to all be depended on doxygen.
> 
> Were does this dependency on doxygen come from, and why does that then want 
> to install ghostscript and tex?
> 
> 
> ===>>> bind912-9.12.1P2 >> (18)
> 
> ===>>> The following actions will be taken if you choose to proceed:
> Upgrade bind912-9.12.1P2 to bind912-9.12.2P1_2
> Upgrade json-c-0.13 to json-c-0.13.1
> Upgrade protobuf-c-1.3.0_1 to protobuf-c-1.3.1
> Install devel/doxygen

devel/protobuf-c seems to be the culprit:

OPTIONS_DEFINE= DOXYGEN
OPTIONS_DEFAULT=DOXYGEN

> Install print/ghostscript9-agpl-base
> Upgrade poppler-data-0.4.8 to poppler-data-0.4.9
> Install print/tex-dvipsk
> Install devel/tex-web2c
> Upgrade zziplib-0.13.62_2 to zziplib-0.13.69_1
> Install print/texlive-texmf
> Install print/tex-basic-engines
> Install print/texlive-base
> Install devel/t1lib
> Install graphics/poppler
> Upgrade nspr-4.19 to nspr-4.20
> Upgrade nss-3.38 to nss-3.39
> Install print/harfbuzz-icu
> Install print/tex-formats
> Upgrade protobuf-3.5.2,1 to protobuf-3.5.2_1,1
> 
> I looked in the make config for bin912 and didn't see anything that implied 
> doxygen was needed,
> 
> I went ahead and did postmaster -i bind912 and said no to Doxygen which meant 
> the only things updated were bind, json, protobuff-c and protobuff. which is 
> much more in line with what I was expecting.
> 
> However, during the compile process, doxygen, ghostscript, and the various 
> tex packages were installed anyway.
> 
> What has changed in the build instructions for bind912?
> 
> 

___
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: postgis status

[Rainer Hurling]

Am 23.08.18 um 08:51 schrieb Loïc Bartoletti:

Hi,

The new version of postgis (2.5) is coming soon. I'm preparing the tests 
to integrate it into our ports. I take this opportunity to ask you a 
general question about the status of postgis in our ports.


As for postgresql, with each postgis version, we have a port 
(databases/postgis2(1,2,3,4 and soon 5). I proposed some time ago, to be 
able to manage these versions with a USE ( 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213038 ) which from my 
point of view allows to simplify dependencies as for pgrouting ( 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225264 )


I wonder if we should continue to maintain all versions and in this 
case, we should go ahead with the framework (or other ideas?).
Another possibility is simply to delete the different versions and only 
propose the last one; I will prepare the patch for the postgis25 release.


What do you think of that?

Regards

Loïc



Hi Loïc,

thanks for your efforts. I really like the idea of the suggested framework.

In our ports tree, we have PostgreSQL versions from 9.3 upwards. The 
support matrix of PostgreSQL and PostGIS versions [1] shows, that 
PostGIS 2.1 and 2.2 are obsolete now and can be deprecated.


PostGIS 2.4 seems to be the version with support for all PostgreSQL 
version in our tree.


HTH,
Rainer


[1] https://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS
___
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"

Package Quarterly 104 amd64/i386 cannot build math/saga

[Rainer Hurling]

The package builders for 104amd64-quarterly and 104i386-quarterly 
complain about a build problem with math/saga[1][2].


This happens, because 104 uses the outdated math/saga version 6.3.0. In 
HEAD, there is already a working version 6.4.0 for some time now.


Is it possible to also update the quarterly packages to version 6.4.0?

Thanks for any clarification.

Regards,
Rainer Hurling


[1] 
http://beefy2.nyi.freebsd.org/data/104amd64-quarterly/474918/logs/errors/saga-6.3.0.log
[2] 
http://beefy4.nyi.freebsd.org/data/104i386-quarterly/474918/logs/saga-6.3.0.log

___
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: Fortran compiler [devel/flang-clang] broken

[Rainer Hurling]

Am 08.07.2018 um 10:20 schrieb blubee blubeeme:
> Hello
> 
> devel/flangclang seems to still be broken, on pkg-install I get errors
> because flang is installed in {PREFIX}/flang instead of {PREFIX}
> 
> Is there any particular reason why flang-clang isn't installed in the
> standard directory?


Hi blubee blubeeme,

Both, devel/flang-clang and devel/flang, install in ${PREFIX}/flang.

I just tried to reinstall and it works for me. What exactly is wrong
with it for you?

Regards,
Rainer Hurling
___
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: www/firefox-i18n: Install problems on 12.0-CURRENT

[Rainer Hurling]

Sorry for answering myself. But I found the changes in Firefox 60.x,
please see above.


Am 17.05.2018 um 17:30 schrieb Rainer Hurling:
> Hi Jan,
> 
> Am 17.05.2018 um 13:21 schrieb Jan Beich:
>> Rainer Hurling <rhur...@gwdg.de> writes:
>>
>>> For some time now (Firefox 60.x beta versions and on), I get the
>>> following error, if I try to install www/firefox-i18n on 12.0-CURRENT
>>> amd64:
>>
>> Can you reproduce with firefox binary built by FreeBSD package cluster?
>>
>> $ pkg delete -f firefox
>> $ pkg install firefox
>> $ make install -C/usr/ports/www/firefox-i18n
> 
> Hmm, I usually install from sources via portmaster. Now, if I try via
> 'pkg install', I get:
> 
> 
> #pkg install firefox
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> All repositories are up to date.
> The following 87 package(s) will be affected (of 0 checked):
> 
> Installed packages to be REMOVED:
>   gdm-3.16.4_3
>   gnome-terminal-3.24.2
>   gnome-shell-3.18.5_7
>   libgnomekbd-3.6.0_2
>   gnome-keyring-3.18.3_4
>   pinentry-gnome3-1.1.0
>   seahorse-3.18.0_1
>   gstreamer1-plugins-all-1.12
>   telepathy-gabble-0.18.3_5
>   gnome-control-center-3.18.2_8
>   evolution-data-server-3.24.2_9
>   gnome-contacts-3.18.0_6
>   gnome-utils-3.18.0,1
>   evince-3.26.0
>   nautilus-3.18.5
>   gimp-app-2.8.22_1,1
>   py27-gimp-2.8.22_1
>   gnome-maps-3.24.3
>   evolution-3.24.2_5
>   telepathy-qt4-0.9.7_1
>   py27-game-1.9.1_7
>   einstein-2.0_10
>   jools-0.20_11
>   totem-3.18.1_3
>   grilo-plugins2-0.2.17_1
>   libgdata-0.17.8
>   eog-plugins-3.16.6
>   cheese-3.18.1_2
>   mdbtools-0.7.2.a
>   krdc-kde4-4.14.3_6
>   kdenetwork-kde4-4.14.3_5
>   krfb-kde4-4.14.3_3
>   empathy-3.12.14_1
>   telepathy-farstream-0.6.2_2
>   folks-0.11.4
>   sushi-3.18.0_1
>   file-roller-3.26.1,1
>   gvfs-1.26.3_9
>   gnome-photos-3.24.2_2
>   libcryptui-3.12.2_1
>   gnome-online-miners-3.14.3_1
>   gnome-documents-3.24.2
>   kde-4.14.3_7
>   caribou-0.4.21_1
>   libgnomeui-2.24.5
>   eclipse-4.6_2
>   libgnomesu-1.0.0_13
>   py27-gnome-2.28.1_8
>   brasero-3.12.2
>   gimp-gmic-plugin-1.6.9_14
>   gimp-lqr-plugin-0.7.2
>   libpurple-2.13.0
>   telepathy-haze-0.8.0_2
>   epiphany-3.24.2_5
>   gimp-2.8.22,2
>   gimp-gutenprint-5.2.13
>   gnome-user-share-3.14.0_2
>   gimp-focusblur-plugin-3.2.6_6
>   gnome-shell-extensions-3.18.4
>   gnome-todo-3.18.1_8
>   gnome-calendar-3.18.2.1_7
>   gstreamer1-plugins-dv-1.12.3
>   autopano-sift-C-2.5.1_5
>   gstreamer1-plugins-aalib-1.12.3
> 
> New packages to be INSTALLED:
>   firefox: 60.0_2,1
> 
> Installed packages to be REINSTALLED:
>   libmpeg2-0.5.1_6
>   libproxy-0.4.12
>   geocode-glib-3.18.2
>   upower-0.99.4
>   gnome-power-manager-3.18.0 (ABI changed: 'freebsd:11:x86:64' ->
> 'freebsd:12:x86:64')
>   liboauth-1.0.3_3
>   libgnomeprint-2.18.8_4
>   libgnomecups-0.2.3_8,1
>   libijs-0.35_5 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   gsound-1.0.2 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   libcue-2.1.0 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   libao-1.2.0_3 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   libotr-4.1.1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   libmms-0.6.4_1
>   libirman-0.4.6 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   qqwing-1.3.4_1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   spandsp-0.0.6
>   gsm-1.0.13_2
>   phonon-gstreamer-4.9.0_1 (options changed)
>   CoinMP-1.8.3 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
>   plotutils-2.6_7,1 (ABI changed: 'freebsd:11:x86:64' -> 
> 'freebsd:12:x86:64')
>   cracklib-2.9.6 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
> 
> Number of packages to be removed: 64
> Number of packages to be installed: 1
> Number of packages to be reinstalled: 22
> 
> The operation will free 485 MiB.
> 48 MiB to be downloaded.
> 
> 
> I did not install via 'pkg install', because it is to destructive for my
> box. But, I did reinstall the 22 ports via portmaster, mentioned by 'pkg
> install'.
> 
>>
>>> #make
>>> make: "/usr/ports/Mk/Uses/gecko.mk" line 48

www/firefox-i18n: Install problems on 12.0-CURRENT

[Rainer Hurling]

Hi Jan,

Am 17.05.2018 um 13:21 schrieb Jan Beich:
> Rainer Hurling <rhur...@gwdg.de> writes:
> 
>> For some time now (Firefox 60.x beta versions and on), I get the
>> following error, if I try to install www/firefox-i18n on 12.0-CURRENT
>> amd64:
> 
> Can you reproduce with firefox binary built by FreeBSD package cluster?
> 
> $ pkg delete -f firefox
> $ pkg install firefox
> $ make install -C/usr/ports/www/firefox-i18n

Hmm, I usually install from sources via portmaster. Now, if I try via
'pkg install', I get:


#pkg install firefox
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 87 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
gdm-3.16.4_3
gnome-terminal-3.24.2
gnome-shell-3.18.5_7
libgnomekbd-3.6.0_2
gnome-keyring-3.18.3_4
pinentry-gnome3-1.1.0
seahorse-3.18.0_1
gstreamer1-plugins-all-1.12
telepathy-gabble-0.18.3_5
gnome-control-center-3.18.2_8
evolution-data-server-3.24.2_9
gnome-contacts-3.18.0_6
gnome-utils-3.18.0,1
evince-3.26.0
nautilus-3.18.5
gimp-app-2.8.22_1,1
py27-gimp-2.8.22_1
gnome-maps-3.24.3
evolution-3.24.2_5
telepathy-qt4-0.9.7_1
py27-game-1.9.1_7
einstein-2.0_10
jools-0.20_11
totem-3.18.1_3
grilo-plugins2-0.2.17_1
libgdata-0.17.8
eog-plugins-3.16.6
cheese-3.18.1_2
mdbtools-0.7.2.a
krdc-kde4-4.14.3_6
kdenetwork-kde4-4.14.3_5
krfb-kde4-4.14.3_3
empathy-3.12.14_1
telepathy-farstream-0.6.2_2
folks-0.11.4
sushi-3.18.0_1
file-roller-3.26.1,1
gvfs-1.26.3_9
gnome-photos-3.24.2_2
libcryptui-3.12.2_1
gnome-online-miners-3.14.3_1
gnome-documents-3.24.2
kde-4.14.3_7
caribou-0.4.21_1
libgnomeui-2.24.5
eclipse-4.6_2
libgnomesu-1.0.0_13
py27-gnome-2.28.1_8
brasero-3.12.2
gimp-gmic-plugin-1.6.9_14
gimp-lqr-plugin-0.7.2
libpurple-2.13.0
telepathy-haze-0.8.0_2
epiphany-3.24.2_5
gimp-2.8.22,2
gimp-gutenprint-5.2.13
gnome-user-share-3.14.0_2
gimp-focusblur-plugin-3.2.6_6
gnome-shell-extensions-3.18.4
gnome-todo-3.18.1_8
gnome-calendar-3.18.2.1_7
gstreamer1-plugins-dv-1.12.3
autopano-sift-C-2.5.1_5
gstreamer1-plugins-aalib-1.12.3

New packages to be INSTALLED:
firefox: 60.0_2,1

Installed packages to be REINSTALLED:
libmpeg2-0.5.1_6
libproxy-0.4.12
geocode-glib-3.18.2
upower-0.99.4
gnome-power-manager-3.18.0 (ABI changed: 'freebsd:11:x86:64' ->
'freebsd:12:x86:64')
liboauth-1.0.3_3
libgnomeprint-2.18.8_4
libgnomecups-0.2.3_8,1
libijs-0.35_5 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
gsound-1.0.2 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
libcue-2.1.0 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
libao-1.2.0_3 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
libotr-4.1.1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
libmms-0.6.4_1
libirman-0.4.6 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
qqwing-1.3.4_1 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
spandsp-0.0.6
gsm-1.0.13_2
phonon-gstreamer-4.9.0_1 (options changed)
CoinMP-1.8.3 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')
plotutils-2.6_7,1 (ABI changed: 'freebsd:11:x86:64' -> 
'freebsd:12:x86:64')
cracklib-2.9.6 (ABI changed: 'freebsd:11:x86:64' -> 'freebsd:12:x86:64')

Number of packages to be removed: 64
Number of packages to be installed: 1
Number of packages to be reinstalled: 22

The operation will free 485 MiB.
48 MiB to be downloaded.


I did not install via 'pkg install', because it is to destructive for my
box. But, I did reinstall the 22 ports via portmaster, mentioned by 'pkg
install'.

> 
>> #make
>> make: "/usr/ports/Mk/Uses/gecko.mk" line 48: warning:
>> "/usr/local/bin/firefox --version 2>/dev/null" returned non-zero
>> status
> 
> Probably because "firefox --version" crashes. It would be surprising
> if firefox works fine otherwise.

Nope, it does not crash (built from sources):

#firefox --version
Mozilla Firefox 60.0.1


I think, I found the problem: It is the way, I am using portmaster
and/or make install, always as root, not a normal user.

If I do 'make' as a normal user, the error does not occur, only as root.
This is, because 'firefox --version' is not possible as root any more.
It breaks with:

www/firefox-i18n: Install problems on 12.0-CURRENT

[Rainer Hurling]

For some time now (Firefox 60.x beta versions and on), I get the 
following error, if I try to install www/firefox-i18n on 12.0-CURRENT amd64:



#make
make: "/usr/ports/Mk/Uses/gecko.mk" line 48: warning: 
"/usr/local/bin/firefox --version 2>/dev/null" returned non-zero status
===>  firefox-i18n-60.0.1 cannot install: firefox versions mismatch: 
firefox-

is installed and wanted version is firefox-60.
*** Error code 1
Stop.
make: stopped in /usr/ports/www/firefox-i18n


This happens on three boxes. Any hints are really appreciated.
Thanks in advance.

Regards,
Rainer Hurling
___
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: math/suitesparse is broken

[Rainer Hurling]

Am 01.05.2018 um 05:40 schrieb Steve Kargl:
> Can someone fix math/suitesparse?
> 
> % make config
>   
> 
> % make 
> ...
> 
> h/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12 -lm -lamd -lcolamd 
> -lsuitesparseconfig -lccolamd -lcamd -L/usr/local/lib -lmetis  
> -Wl,-rpath=/usr/local/lib/gcc7  -L/usr/local/lib/gcc7 -B/usr/local/bin 
> -L/usr/local/lib -fstack-protector -Wl,-rpath=/usr/local/lib/gcc7 
> -L/usr/local/lib/gcc7 -llapack -lopenblas
> /usr/local/bin/ld: cannot find -lopenblas
> collect2: error: ld returned 1 exit status
> gmake[5]: *** [Makefile:544: 
> /usr/ports/math/suitesparse/work/SuiteSparse/lib/libcholmod.so.3.0.12] Error 1
> gmake[5]: Leaving directory 
> '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Lib'
> gmake[4]: *** [Makefile:31: library] Error 2
> gmake[4]: Leaving directory 
> '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD/Lib'
> gmake[3]: *** [Makefile:14: all] Error 2
> gmake[3]: Leaving directory 
> '/usr/ports/math/suitesparse/work/SuiteSparse/CHOLMOD'
> gmake[2]: *** [Makefile:21: go] Error 2
> gmake[2]: Leaving directory '/usr/ports/math/suitesparse/work/SuiteSparse'
> *** Error code 2
> 
> openblas is not Netlib BLAS.
> 
> 


Hi Steve,

For this error it should be sufficient to deinstall the old port.
before you build and install the new one. In some cases, there are
further breaks [1].

HTH,
Rainer


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227791
___
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: FreeBSD Port: py27-qt5-core / Py36-qt5-core

[Rainer Hurling]

Hi D.-C. M., hi others,

Am 27.03.2018 um 23:49 schrieb Guido Falsi:

On 03/27/18 22:44, D.-C. M. wrote:

Hello,



Hi!

  


At this moment, it is impossible to build side by side py27-qt5-core and
py36-qt5-core.

  


There is a collison on /usr/local/bin/pyuic

  


This is annoying… Python 27 is still the default, but become quite old now.



I'm not a python expert, but I understand that python 2.7 and python 3
are two slightly different languages not fully compatible with each other.

I also understand(but have not gone into depth about this) that there is
some resistance to python 3, with many developers being reluctant to
move to version 3, for whatever reason(I imagine it's language design
choices, but I really don't know)

I'm stating this because it means such incompatibilities are not going
away easily. It's not just a ports system problem, but an actual python
ecosystem problem.

Too say it in other words, python 2.7 isn't really just "the old
version" and python 3 is not just "the new version". They have parallel
lifes.



deskutils/calibre

which requires py27-qt5-core

I have tried to modify Makefile to try to build calibre-ebook port
versus py36, but there seems to be a hard dependency to Python 27, as


calibre is programmed for python 2.7 and the original author has no plan
to update it to work with python 3:

https://bugs.launchpad.net/calibre/+bug/1456642

This is in relation to what I said above.



  


www/py-mechanize does not not exist in py36 flavor


It's not just a dependency problem. Calibre code depends on python 2.7
language peculiarities which are different in python 3 (again I don't
know the details)



  


I would guess that it could be possible to differentiate the name of binary

/usr/local/lib/pyuic


This would not suffice to fix the problem you're seeing.



  


According to Py27 / Py36 flavor, with some strap.

In fact, most of py27-xx/py36-xx can build side by side, but not py-qt5-core


There are some PRs about this[1][2]

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219641
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223764

In comment #33 of PR 219641 I suggested a possible change. This would be 
'double flavored' (QT[45] and py[45] at the same ports), which could be 
a problem with the design of flavors. Also, it is not tested very well.





And that's a problem since packages downstream from py-qt5-core strictly
require python 2.7 or 3 and can't switch from one to another, but as I
said, that's a python problem.



___
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: Not much reason to have */R-cran-* ports

[Rainer Hurling]

Am 20.03.2018 um 21:32 schrieb Yuri:
> On 03/20/18 11:20, Eugene Grosbein wrote:
>> It is a bit funny you are bothered on 250 R-cran-* ports when we have
>> 1908 p5-* ports,
>> 964 py-* ports, 600 rubygem-* ports and 280 hs-* ports in the single
>> ports/devel category.
>>
>> Are you planning to ban and remove p5 ports too? Most of them should
>> be from CPAN.
>> We had BSDPAN for some time even...
> 
> 
> You are missing the key differences:
> 
> 1. Python and perl ports represent individually run software with their
> own executables, when R doesn't. R packages are only useful in the
> context of R, as building blocks of larger R programs only runnable in R
> environment. R packages are much more dependent on environment.
> 
> 
> 2. With python, there is a hope of having all major software pieces in
> ports. With R there is no such hope. There are thousands of individual
> small R packages, while we only have 250 in ports with no hope or reason
> to add another few thousands. Now, if I want to use some R package
> should I look it up in ports and try to port if it is missing? Of course
> not, I will just install it from R. It's much easier this way,
> 
> 
> Yuri
> 

I think, the initial reason for creating R-cran ports was, that several
of them should take care of needed non-R dependencies, like
math/R-cran-sf, math/R-cran-nloptr, math/R-cran-igraph,
databases/R-cran-RMySQL, and many others.

A second reason was, that some of the original R packages have to be
patched to build on FreeBSD, like devel/R-cran-Rcpp,
textproc/R-cran-xml2, security/R-cran-openssl, and others.

Without ports for those, some R packages are not installable and in many
cases needed dependencies are missing.

It seems, we need some (other) mechanism, which should take care of
those R packages.

Regards,
Rainer
___
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: graphics/evince

[Rainer Hurling]

Am 18.02.2018 um 19:02 schrieb Kurt Jaeger:
> Hi!
> 
>>> Ah, there's a patch already at
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221781
>>>
>>> Can you test if it works for you ?
> 
>> I just tried the patch to update evince-3.18.2_5 to evince-3.26.0 on
>> 12.0-CURRENT amd64 and it works for me.
> 
> Works as in 'builds' or works as in 'runs' 8-} ?
> 

Both, it builds, installs and runs fine, as far as I can say after
opening a few pdf files.
___
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: graphics/evince

[Rainer Hurling]

Am 18.02.2018 um 16:40 schrieb Kurt Jaeger:
> Hi!
> 
>>> Who is suppose to keep this up to date?
>>
>> A vage group called gnome.
>>
>> Which has many open PRs, and unfortunatly a bad track record 8-(
>>
>> In the wiki we find:
>>
>> https://wiki.freebsd.org/Gnome#Team_Members
>>
>> If you can provide a patch, I can testbuild and commit... ?
> 
> Ah, there's a patch already at
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221781
> 
> Can you test if it works for you ?
> 

I just tried the patch to update evince-3.18.2_5 to evince-3.26.0 on
12.0-CURRENT amd64 and it works for me.

HTH,
Rainer Hurling
___
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: FLAVOR for Qt4 and Qt5 (was Re: Flavor or not for this port?)

[Rainer Hurling]

Hi Loïc,

Am 04.01.2018 um 18:37 schrieb L.Bartoletti:
> Hi Mathieu,
> 
> Thank you for your review and tips.
> 
> I have just submitted the patch.
> 
> Rainer, QGis 2 may be able to use Qwt6 instead of Qwt5?

I just tried to use Qwt6 with QGIS2 and it seems to work. A few small
tests showed no regressions, so far.

If this is true, I could change my port to use qwt6@qt4, once flavors
for QWT hit the ports tree.

Thanks to both, Loïc and Mathieu, for the work on this.

Best wishes,
Rainer

> 
> Regards.
> 
> Loïc
> 
> On 21.12.2017 17:10, Mathieu Arnold wrote:
>> Le 19/12/2017 à 20:48, L.Bartoletti a écrit :
>>> Hi,
>>>
>>> Here's my WIP
>>>
>>> https://gitlab.com/lbartoletti/freebsd_ports/tree/master/qwt6
>> As long as you are defining a default FLAVOR value, do it right:
>>
>> FLAVOR?= ${FLAVORS:[1]}
>>
>> There are a few stuffs that could be simplified, this works for both
>> flavors:|
>>
>> |
>>
>> |PLIST=    ${PKGDIR}/pkg-plist.${FLAVOR} PLIST_SUB+=
>> QT_MKSPECDIR=lib/${FLAVOR}/mkspecs DOCSDIR=
>> ${PREFIX}/share/doc/qwt6-${FLAVOR} And this: ||@${REINPLACE_CMD} -e
>> 's/__QT_VERSION__/${FLAVOR:S/qt//}/g'
>> ${WRKSRC}/qwtconfig.pri|
>> ||
>>
>>
>>
>> You are missing:
>>
>> qt4_CONFLICTS_INSTALL= qwt6-qt5
>> qt5_CONFLICTS_INSTALL= qwt6-qt4
>>
>>
>>
> 

___
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: FLAVOR for Qt4 and Qt5 (was Re: Flavor or not for this port?)

[Rainer Hurling]

Hi Loïc,

Am 04.01.2018 um 18:37 schrieb L.Bartoletti:
> Hi Mathieu,
> 
> Thank you for your review and tips.
> 
> I have just submitted the patch.
> 
> Rainer, QGis 2 may be able to use Qwt6 instead of Qwt5?

I just tried to use Qwt6 with QGIS2 and it seems to work. A few small
tests showed no regressions, so far.

If this is true, I could change my port to use qwt6@qt4, once flavors
for QWT hit the ports tree.

Thanks to both, Loïc and Mathieu, for the work on this.

Best wishes,
Rainer


> 
> Regards.
> 
> Loïc
> 
> On 21.12.2017 17:10, Mathieu Arnold wrote:
>> Le 19/12/2017 à 20:48, L.Bartoletti a écrit :
>>> Hi,
>>>
>>> Here's my WIP
>>>
>>> https://gitlab.com/lbartoletti/freebsd_ports/tree/master/qwt6
>> As long as you are defining a default FLAVOR value, do it right:
>>
>> FLAVOR?= ${FLAVORS:[1]}
>>
>> There are a few stuffs that could be simplified, this works for both
>> flavors:|
>>
>> |
>>
>> |PLIST=    ${PKGDIR}/pkg-plist.${FLAVOR} PLIST_SUB+=
>> QT_MKSPECDIR=lib/${FLAVOR}/mkspecs DOCSDIR=
>> ${PREFIX}/share/doc/qwt6-${FLAVOR} And this: ||@${REINPLACE_CMD} -e
>> 's/__QT_VERSION__/${FLAVOR:S/qt//}/g'
>> ${WRKSRC}/qwtconfig.pri|
>> ||
>>
>>
>>
>> You are missing:
>>
>> qt4_CONFLICTS_INSTALL= qwt6-qt5
>> qt5_CONFLICTS_INSTALL= qwt6-qt4
>>
>>
>>
> 

___
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: FLAVOR for Qt4 and Qt5 (was Re: Flavor or not for this port?)

[Rainer Hurling]

Hi Loïc,

Am 19.12.2017 um 20:48 schrieb L.Bartoletti:

Hi,

Here's my WIP

https://gitlab.com/lbartoletti/freebsd_ports/tree/master/qwt6


Looks interesting to me.

Do we agree, that the package should be named qwt6-qt[45], and not 
qwt-qt[45]?


And shouldn't PORTNAME better be named qwt6 instead of qwt. If so, the 
port has to handle with DISTNAME in some way to fetch a file named qwt-.


At least, the actual naming brings some problems, for example if one 
tries to fetch the distfile


make distclean
make FLAVOR=qt4 fetch

make distclean
make FLAVOR=qt5 fetch


QWT is licensed under Qwt 1.0, which is a LGPL with three execptions[1]. 
There is no definition for this license in Mk/bsd.license.db.mk until 
now. I don't know, what is the right way to define this 'unknown' 
license in the port.



Again, many thanks for your work on this port.
Best wishes,
Rainer

[1] http://qwt.sourceforge.net/qwtlicense.html




Regards


On 18.12.2017 22:57, L.Bartoletti wrote:

Hi Rainer,

I have made a try with subpackages with success, but I think it's 
better with flavor (like on OpenBSD).


So, I have started to create flavors for this port.

For now, I success for qt4 but not yet for qt5.

Extract from my Makefile in progress:

FLAVORS=    qt5 qt4
FLAVOR?=

.if ${FLAVOR:Mqt5}
PKGNAMESUFFIX=    -qt5
USE_QT5=    widgets gui core designer gui opengl svg xml buildtools 
printsupport concurrent

PLIST=        ${PKGDIR}/pkg-plist.qt5
PLIST_SUB+=    QT_MKSPECDIR=lib/qt5/mkspecs
DOCSDIR=    ${PREFIX}/share/doc/qwt6-qt5
.else
PKGNAMESUFFIX=    -qt4
USE_QT4=     corelib gui opengl svg xml moc_build
PLIST=        ${PKGDIR}/pkg-plist.qt4
PLIST_SUB+=    QT_MKSPECDIR=lib/qt4/mkspecs
DOCSDIR=    ${PREFIX}/share/doc/qwt6-qt4
.endif

Ther error for qt5:

qwt-qt5-6.1.3 can't be installed: different Qt versions specified via
USE_QT[4 5].

Regards.

On 17.12.2017 10:12, Rainer Hurling wrote:

Am 02.11.2017 um 07:41 schrieb Rainer Hurling:

Am 02.11.2017 um 07:13 schrieb L.Bartoletti:

Hi,

I want to take x11-toolkits/qwt{5,6}-*

Both are built for Qt4. I especially need qwt6 for Qt5. Since we have
flavors. Is it better to add a Qt5 flavor for Qwt6 or simply add a
x11-toolkits/qwt6-qt5 (like security/qtkeychain-qt{4,5} ?)

Thanks.

Regards.

Loïc


Hi Loïc,

Thanks for your dedication. I am very interested in a qwt6-qt5 port,
since it is needed for the upcoming version 3.0 of graphics/qgis :)

Sorry for my inexperience. In case of adding the qwt6-qt5 as a flavor,
should we expect any change or restriction in the way, it would be used
as a dependency of e.g. QGIS?

Thanks for any answer.

Best wishes,
Rainer

Hi Loïc,

Again about x11-toolkits/qwt{5,6}-*

Now, that we have our first real world experiences with FLAVORS, it
seems to be functional to use flavors in this context. Something like

x11-toolkits/qwt6@qt4
x11-toolkits/qwt6@qt5

A bit tricky could be, that USE_QT* are different in both cases:

USE_QT4= corelib gui opengl svg xml moc_build
USE_QT5= core gui opengl svg xml printsupport qmake_build widgets

What do you think?

Best wishes,
Rainer

___
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: devel/R-cran-gsubfn: broken because of missing dependency

[Rainer Hurling]

Am 19.12.2017 um 08:21 schrieb Walter Schwarzenfeld:

Is in math/R the option tcl/tk=on?


Hi Walter,

I think, you are right.

pkg-fallout[1] seems to have problems with building devel/R-cran-gsubfn, 
because default setting for math/R option 'TCLTK' is disabled. This have 
to be enabled by default, if the build of devel/R-cran-gsubfn should 
work automatically.


Thanks for the pointer.

[1] http://svnweb.freebsd.org/changeset/ports/456684
___
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"

devel/R-cran-gsubfn: broken because of missing dependency

[Rainer Hurling]

Hi Steven,

devel/R-cran-gsubfn was marked broken recently because it fails in 
staging with:


** byte-compile and prepare package for lazy loading
Warning: S3 methods 'as.character.tclObj', 'as.character.tclVar', 
'as.double.tclObj', 'as.integer.tclObj', 'as.logical.tclObj', 
'as.raw.tclObj', 'print.tclObj', '[[.tclArray', '[[<-.tclArray', 
'$.tclArray', '$<-.tclArray', 'names.tclArray', 'names<-.tclArray', 
'length.tclArray', 'length<-.tclArray', 'tclObj.tclVar', 
'tclObj<-.tclVar', 'tclvalue.default', 'tclvalue.tclObj', 
'tclvalue.tclVar', 'tclvalue<-.default', 'tclvalue<-.tclVar', 
'close.tkProgressBar' were declared in NAMESPACE but not found

Error : package or namespace load failed for 'tcltk':
 .onLoad failed in loadNamespace() for 'tcltk', details:
  call: fun(libname, pkgname)
  error: Tcl/Tk support is not available on this system
Error : unable to load R code in package 'gsubfn'
ERROR: lazy loading failed for package 'gsubfn'


It seems, that tcltk is needed as a dependency from FreeBSD ports. 
Something like USES=tcl and USES=tk should do the trick?


Best regards,
Rainer Hurling
___
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: Flavor or not for this port?

[Rainer Hurling]

Am 02.11.2017 um 07:41 schrieb Rainer Hurling:
> Am 02.11.2017 um 07:13 schrieb L.Bartoletti:
>> Hi,
>>
>> I want to take x11-toolkits/qwt{5,6}-*
>>
>> Both are built for Qt4. I especially need qwt6 for Qt5. Since we have
>> flavors. Is it better to add a Qt5 flavor for Qwt6 or simply add a
>> x11-toolkits/qwt6-qt5 (like security/qtkeychain-qt{4,5} ?)
>>
>> Thanks.
>>
>> Regards.
>>
>> Loïc
> 
> 
> Hi Loïc,
> 
> Thanks for your dedication. I am very interested in a qwt6-qt5 port,
> since it is needed for the upcoming version 3.0 of graphics/qgis :)
> 
> Sorry for my inexperience. In case of adding the qwt6-qt5 as a flavor,
> should we expect any change or restriction in the way, it would be used
> as a dependency of e.g. QGIS?
> 
> Thanks for any answer.
> 
> Best wishes,
> Rainer

Hi Loïc,

Again about x11-toolkits/qwt{5,6}-*

Now, that we have our first real world experiences with FLAVORS, it
seems to be functional to use flavors in this context. Something like

x11-toolkits/qwt6@qt4
x11-toolkits/qwt6@qt5

A bit tricky could be, that USE_QT* are different in both cases:

USE_QT4= corelib gui opengl svg xml moc_build
USE_QT5= core gui opengl svg xml printsupport qmake_build widgets

What do you think?

Best wishes,
Rainer
___
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: portmaster with FLAVOR support available for testing

[Rainer Hurling]

Am 15.12.2017 um 22:09 schrieb Stefan Esser:
> Am 15.12.17 um 16:11 schrieb Rainer Hurling:
>> Am 15.12.2017 um 15:48 schrieb Walter Schwarzenfeld:
>>> Yes, if it don't work in the port the port is the problem.
>>>
>>> Rainer Hurling was filed a PR
>>>
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223764
>>
>> Yes, Walter, your problem is another ports problem as mine, first
>> described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219641,
>> comment #23, than doubled by PR #223764.
>>
>> In this thread, with portmaster, I asked why portmaster deinstalls
>> py27-qt5-core before it tries to install py36-qt5-core. This is not the
>> case with pure ports make mechanism.
> 
> Please try again with the version I just committed. It seems, that there
> was a path through the program that just removed the passed flavor and
> then proceeded to operate on the default flavor (py27 in this case).
> 
> Sorry for these problems with the port. There are so many possible cases
> and it is impossible for me to achieve sufficient coverage in my tests.
> 
> But I'll try to always quickly fix such problems, when they are brought
> to my attention.
> 
> This was a real problem in portmaster, but problems with ports that
> install files in places that don't differ for different flavors will
> continue to cause the error message reported as an assumed portmaster
> bug multiple times in the last few days.
> 
> Whenever the error message indicates that files are installed in the
> same place, the problem is in the port, not in portmaster.
> 
> Regards, STefan
> 

Hi STefan,

with r456417, portmaster 3.17.11_3, your first approach does not work:


#portmaster -m 'FLAVOR=py36' devel/py-qt5-core
===>>> Currently installed version: py27-qt5-core-5.7.1
===>>> Port directory: /usr/ports/devel/py-qt5-core
===>>> Gathering distinfo list for installed ports
===>>> Launching 'make checksum' for devel/py-qt5-core in background
===>>> Gathering dependency list for devel/py-qt5-core from ports
===>>> Launching child to install devel/py-sip@py27
===>>> py27-qt5-core-5.7.1 >> devel/py-sip@py27 (1/1)
===>>> Port directory: /usr/ports/devel/py-sip@py27
===>>> Launching 'make checksum' for devel/py-sip@py27 in background
===>>> Gathering dependency list for devel/py-sip@py27 from ports
===>>> Initial dependency check complete for devel/py-sip@py27
===>>> Continuing initial dependency check for devel/py-qt5-core
===>>> Initial dependency check complete for devel/py-qt5-core
===>>> py27-qt5-core-5.7.1 >> (1)
===>>> The following actions will be taken if you choose to proceed:
Re-install py27-qt5-core-5.7.1
Install devel/py-sip@py27
===>>> Proceed? y/n [y]


FLAVOR completely get lost in some way ...


The second approach, brought up by Mathieu Arnold, works fine:

#portmaster devel/py-qt5-core@py36


The installation does not work with this special port, because of the
conflict with /usr/local/bin/pyuic5, already installed by
devel/py-qt5-core@py27. But this is another story ...


Many thanks for the last patches to portmaster.
___
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: portmaster with FLAVOR support available for testing

[Rainer Hurling]

Am 15.12.2017 um 16:20 schrieb Mathieu Arnold:
> Le 15/12/2017 à 12:00, Rainer Hurling a écrit :
>> Hi Stefan and others,
>>
>> I just tried to install devel/py-qt5-core for Python 3.6, beside to an
>> already installed py27-qt5-core-5.7.1, with the following command
>>
>>   portmaster -m 'FLAVOR=py36' devel/py-qt5-core
>>
>> and it ends up with 
> 
> I have no idea how portmaster works, but I hope it works the same as
> poudriere, so you should probably do this:
> 
> portmaster devel/py-qt5-core@py36
> 
> instead.
> 
> 

Hi Mathieu,

Thanks for your answer. My attempt was from a private conversation with
Stefan, who suggested to try to install py36 ports via

portmaster -m 'FLAVOR=py36' portname

and to report back. That failed, like described before.

Now I also tried your suggestion with 'portmaster
devel/py-qt5-core@py36', which stopped with the following failure:


[..snip..]
Compiling
/usr/ports/devel/py-qt5-core/work-py27/stage/usr/local/lib/python2.7/site-packages/PyQt5/uic/widget-plugins/qtwebenginewidgets.py
...
Compiling
/usr/ports/devel/py-qt5-core/work-py27/stage/usr/local/lib/python2.7/site-packages/PyQt5/uic/widget-plugins/qtwebkit.py
...
> Compressing man pages (compress-man)
===>>> Starting check for runtime dependencies
===>>> Gathering dependency list for devel/py-qt5-core@py36 from ports
===>>> Dependency check complete for devel/py-qt5-core@py36
===>  Installing for py27-qt5-core-5.7.1
===>  Checking if py27-qt5-core already installed
===>   py27-qt5-core-5.7.1 is already installed
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of py27-qt5-core
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1
Stop.
make[1]: stopped in /usr/ports/devel/py-qt5-core
*** Error code 1
Stop.
make: stopped in /usr/ports/devel/py-qt5-core
===>>> Installation of py36-qt5-core-5.7.1 (devel/py-qt5-core@py36) failed
===>>> Aborting update
===>>> Re-installation of py36-sip-4.19.2,1 complete
===>>> You can restart from the point of failure with this command line:
   portmaster  devel/py-qt5-core@py36
This command has been saved to /tmp/portmasterfail.txt


Obviously, it does not work as expected, @py36 has no effect.

I think, it would be nice, if portmaster behaves as much as possible
like ports make and pkg.

___
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: portmaster with FLAVOR support available for testing

[Rainer Hurling]

Am 15.12.2017 um 15:48 schrieb Walter Schwarzenfeld:
> Yes, if it don't work in the port the port is the problem.
> 
> Rainer Hurling was filed a PR
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223764

Yes, Walter, your problem is another ports problem as mine, first
described in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219641,
comment #23, than doubled by PR #223764.

In this thread, with portmaster, I asked why portmaster deinstalls
py27-qt5-core before it tries to install py36-qt5-core. This is not the
case with pure ports make mechanism.

___
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: portmaster with FLAVOR support available for testing

[Rainer Hurling]

Hi Stefan and others,

I just tried to install devel/py-qt5-core for Python 3.6, beside to an 
already installed py27-qt5-core-5.7.1, with the following command


  portmaster -m 'FLAVOR=py36' devel/py-qt5-core

and it ends up with


[..snip..]
===>>> Creating a backup package for old version py27-qt5-core-5.7.1
Creating package for py27-qt5-core-5.7.1
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 
packages in the universe):

Installed packages to be REMOVED:
py27-qt5-core-5.7.1
Number of packages to be removed: 1
The operation will free 5 MiB.
[1/1] Deinstalling py27-qt5-core-5.7.1...
[1/1] Deleting files for py27-qt5-core-5.7.1: 100%
===>  Installing for py36-qt5-core-5.7.1
===>  Checking if py36-qt5-core already installed
===>   Registering installation for py36-qt5-core-5.7.1 as automatic
Installing py36-qt5-core-5.7.1...
===>>> Upgrade of py27-qt5-core-5.7.1 to py36-qt5-core-5.7.1 complete


So it seems, that portmaster first removed the version for Python 2.7 
and after that installs the version for Python 3.6.


Note, that devel/py-qt5-core is a problematic port because of its 
conflict of /usr/local/bin/pyuic5, as described in [1].


Any ideas, what is going on here with portmaster? Thanks for any help.

Best regards,
Rainer

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219641, comment #23


Am 13.12.2017 um 22:39 schrieb Stefan Esser:

I have created a new version of portmaster with FLAVOR support.

Before committing the changes to the ports repository, I'd like to receive
some feedback from users.

My tests have only covered port upgrades, not any of the other features
offered by portmaster. In fact, I'd like to remove several of the other
features, which may have been of use before PKG_NG (e.g. functions that
use the INDEX file, and in fact also the -P/-PP/--packages-* features).


*** Please let me know, if you want to receive the new version by personal
*** mail (I do not want to spam the mail-list by posting a 100KB+ file).


The following is example output from an portmaster upgrade run that I just
performed. It includes upgrades of flavored and non-flavored ports and the
re-installation of ports that have been converted to flavors Without wersion
update:

# portmaster -dgw -a

[...]

===>>> Launching child to update py27-werkzeug-0.12.2 to py27-werkzeug-0.13

===>>> All >> py27-werkzeug-0.12.2 (5/5)

===>>> Currently installed version: py27-werkzeug-0.12.2
===>>> Port directory: /usr/svn/ports/head/www/py-werkzeug

===>>> Launching 'make checksum' for www/py-werkzeug in background
===>>> Gathering dependency list for www/py-werkzeug from ports
===>>> Launching child to install security/py-openssl@py27

===>>> All >> py27-werkzeug-0.12.2 >> security/py-openssl@py27 (6/6)

===>>> Currently installed version: py27-openssl-17.3.0
===>>> Port directory: /usr/svn/ports/head/security/py-openssl@py27

===>>> Launching 'make checksum' for security/py-openssl@py27 in background
===>>> Gathering dependency list for security/py-openssl@py27 from ports
===>>> Launching child to install devel/py-six@py27

[...]

===>>> The following actions were performed:
Upgrade of avidemux-2.6.11_6 to avidemux-2.6.11_7
Upgrade of libva-intel-driver-1.8.3_1 to libva-intel-driver-2.0.0
Upgrade of nghttp2-1.28.0 to nghttp2-1.28.0_1
Upgrade of py27-psutil-5.4.1 to py27-psutil-5.4.2
Re-installation of py27-six-1.11.0
Re-installation of py27-cffi-1.7.0
Re-installation of py27-asn1crypto-0.22.0
Re-installation of py27-enum34-1.1.6
Re-installation of py27-idna-2.5
Re-installation of py27-ipaddress-1.0.18
Re-installation of py27-cryptography-2.0.3
Re-installation of py27-openssl-17.3.0
Upgrade of py27-werkzeug-0.12.2 to py27-werkzeug-0.13
Upgrade of sbcl-1.4.1,1 to sbcl-1.4.2,1
Upgrade of scons-2.5.1_1 to scons-3.0.1
Upgrade of xfce4-notifyd-0.4.0 to xfce4-notifyd-0.4.1

___
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: Working on FLAVOR support in portmaster

[Rainer Hurling]

Am 05.12.2017 um 08:35 schrieb Stefan Esser:
> Am 05.12.17 um 00:43 schrieb Tatsuki Makino:
>> By the way, where is the clever way to update to flavor?
>> I am using portmaster.
> 
> I'm working on FLAVOR support in portmaster. My version did already build
> all updated ports, the FLAVOR parameter is passed to build sub-processes,
> but there is still some confusion between multiple flavored versions of the
> same port (installing the py27 version wants to deinstall the py36 version
> and vice versa), which I still have to fix.

Isn't the described behaviour (installing the py27 version wants to
deinstall the py36 version and vice versa) caused by the underlying
ports mechanisms? As far as I can see, portmaster gives exactly the
output, that also comes from using pure 'make deinstall' and 'make
reinstall'.

> I'm not sure that I have time to complete the fix today, but it is not too
> hard. Ports need to complement the port origin with the FLAVOR, where
> appropriate (e.g. when a flavored destination is found in MOVED). Already
> installed packages are annotated with "flavor" and that must be passed to
> the build command, when that port is updated. Most other logic in portmaster
> remains unaffected.
> 
> 
> My work version has all non PKG_NG support stripped, but that is mainly to
> not waste effort fixing irrelevant sub-routines.
> 
> Is it acceptable, to have portmaster stop supporting the old package system?
> AFAIK, there is no way that a modern ports tree with flavor support works
> with a non-PKG_NG infrastructure?
> 
> Regards, STefan

Many thanks for your efforts in bringing flavors into portmaster. Really
appreciated!

Regards,
Rainer
___
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: Flavor or not for this port?

[Rainer Hurling]

Am 02.11.2017 um 07:13 schrieb L.Bartoletti:

Hi,

I want to take x11-toolkits/qwt{5,6}-*

Both are built for Qt4. I especially need qwt6 for Qt5. Since we have 
flavors. Is it better to add a Qt5 flavor for Qwt6 or simply add a 
x11-toolkits/qwt6-qt5 (like security/qtkeychain-qt{4,5} ?)


Thanks.

Regards.

Loïc



Hi Loïc,

Thanks for your dedication. I am very interested in a qwt6-qt5 port, 
since it is needed for the upcoming version 3.0 of graphics/qgis :)


Sorry for my inexperience. In case of adding the qwt6-qt5 as a flavor, 
should we expect any change or restriction in the way, it would be used 
as a dependency of e.g. QGIS?


Thanks for any answer.

Best wishes,
Rainer
___
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"

science/udunits2: Seg faults while deinstall and install

[Rainer Hurling]

I tried to rebuild and reinstall science/udunits2 on a box with recent 
HEAD amd64 and it gives me some errors while deinstalling and reinstalling:



#make deinstall
===>  Deinstalling for udunits
===>   Deinstalling udunits-2.2.25
Updating database digests format: 100%
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 1 packages (of 0 
packages in the universe):


Installed packages to be REMOVED:
udunits-2.2.25

Number of packages to be removed: 1
[1/1] Deinstalling udunits-2.2.25...
[1/1] Deleting files for udunits-2.2.25: 100%
Segmentation fault
Segmentation fault



#make reinstall
===>  Installing for udunits-2.2.25
===>   udunits-2.2.25 depends on executable: indexinfo - found
===>   udunits-2.2.25 depends on shared library: libexpat.so - found 
(/usr/local/lib/libexpat.so)

===>   Registering installation for udunits-2.2.25
Installing udunits-2.2.25...
Segmentation fault
Segmentation fault


Is this a known issue? Any ideas and/or help would be really 
appreciated. Thanks in advance.


Best wishes,
Rainer Hurling
___
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: Update failure E000022 after upgrade to subversion 1.9.6

[Rainer Hurling]

Hi duglas@

I had the same problem. I completely solved it by rebuilding the 
dependency chain of devel/subversion:


portmaster serf-1.3.9_1 expat-2.2.1 gettext-runtime-0.19.8.1_1 
apr-1.5.2.1.5.4_2 sqlite3-3.19.3_1 subversion-1.9.6


Probably, only one of them is the culprit, but I haven't testet ;)

Best wishes,
Rainer Hurling


Am 11.07.2017 um 18:33 schrieb Torsten Zuehlsdorff:

On 11.07.2017 17:17, duglas wrote:

Hi,

After upgrading to subversion 1.9.6
My latest svn update attempts result in the following.

svn update /usr/ports
Updating 'ports':
svn: E22: Error converting entry in directory '/usr/ports' to UTF-8
svn: E22: Can't convert string from native encoding to 'UTF-8':
svn: E22: ?\A89'

Coincidentally it also occurs when attempting to update /usr/src and 
/usr/docs as well.


Attempts to portdowngrade to the 1.9.5 version fail similarly.


Are you sure that this is an update problem?

I remember this error back some time. It occurs only when having 
non-native file names like "Überraschung.txt" in the repo while using a 
shell without having correct encoding set.


(Beside: it works for me without the problems you describe :D)

Greetings,
Torsten



___
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"

lang/rust: build problems after r443109

[Rainer Hurling]

ARCH_${ARCH}}-unknown-freebsd

${MV} ${WRKSRC}/rustc.tbz ${WRKSRC}/build/cache/${RUST_STD_BOOTSTRAP}
 .endif


Greetings,
Rainer Hurling
___
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: does inkscape-0.92.0_1 works for you ?

[Rainer Hurling]

Am 04.05.2017 um 10:47 schrieb Patrick Lamaiziere:

Hello,

I've upgraded my workstation (10.3-STABLE / amd64) via poudriere and
ports svn://svn0.eu.freebsd.org/ports/branches/2017Q2 (rev 440002) and
inkscape does not work anymore and fails with a segfault.


Works for me on recent 12.0-CURRENT amd64, build and installed from 
ports (HEAD) via portmaster.


HTH,
Rainer



$ inkscape
(inkscape:1234): GLib-CRITICAL **: g_convert: assertion 'str != NULL' failed
...
(inkscape:1234): GLib-CRITICAL **: g_convert: assertion 'str != NULL' failed
...
Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
Incident de segmentation

Any clue ?

Thanks, regards.

___
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: Perl - what is the default?

[Rainer Hurling]

Am 18.04.2017 um 16:56 schrieb Mathieu Arnold:
> Le 18/04/2017 à 15:59, Jim Trigg a écrit :
>> According to UPDATING as of 20161103, "The default Perl version has
>> been switched to Perl 5.24." However, when I follow the instructions
>> there to switch, I get the following message (after running portsnap
>> fetch update manually even though it runs automatically every night):
>> "  This is *NOT* the DEFAULT perl version
>>
>> It will *NOT* install /usr/local/bin/perl
>>
>> It will *ONLY* install /usr/local/bin/perl5.24.1
>>
>> The default Perl version currently is 5.20."
>>
>> Yes, I added "DEFAULT_VERSIONS+= perl=5.24" to /etc/make.conf, and
>> grep confirms that that is the only incidence of perl in the file.

Perhaps, it is only a small typo at your side (missing number 5)?

DEFAULT_VERSIONS+= perl=5.24

instead of

DEFAULT_VERSIONS+= perl5=5.24

> 
> But did you add:
> 
> DEFAULT_VERSIONS+= perl5=5.24
> 
> like the message says you have to ?
> 
> If you did, it is possible that you have a really really old system and
> you still have a /usr/local/etc/perl5_version file, you should remove it.
> 

___
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: More shebangfix problems with ports

[Rainer Hurling]

Hi Jochen,

Am 18.04.2017 um 11:35 schrieb Jochen Neumeister:

Hi Rainer,


Am 18.04.2017 um 11:27 schrieb Rainer Hurling:
After the shebang rules where intensified, many ports have been fixed 
already. Many thanks for that!



For me, on 12.0-CURRENT, at least lang/go and www/libxul have non 
fixed shebangs until now:



lang/go:
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/lib/time/update.bash'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/benchcmp'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/nacl/go_nacl_386_exec'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/nacl/go_nacl_amd64p32_exec'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/nacl/go_nacl_arm_exec'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/all.rc'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/clean.rc'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/src/cmd/dist/mkdeps.bash'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/src/cmd/go/mkalldocs.sh'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/make.rc'
Error: '/usr/bin/perl' is an invalid shebang you need USES=shebangfix 
for 'go/src/net/http/cgi/testdata/test.cgi'
Error: '/usr/bin/perl' is an invalid shebang you need USES=shebangfix 
for 'go/src/regexp/syntax/make_perl_groups.pl'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/run.rc'
For lang/go look at this patch: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218702


I've tested it, and it works fine.


Thanks for the hint to the patch and for your testing.

Now I am irritated, why my system complains about shebang problems. I 
will investigate a bit more ...






www/libxul:
Error: '/usr/bin/env python' is an invalid shebang you need 
USES=shebangfix for 'lib/libxul/sdk/bin/xpidl.py'
Error: '/usr/bin/env python' is an invalid shebang you need 
USES=shebangfix for 'lib/libxul/sdk/bin/xpt.py'
Warning: Bad symlink '/usr/local/bin/xulrunner' pointing to an 
absolute pathname '/usr/local/lib/libxul/xulrunner'
Warning: Bad symlink '/usr/local/lib/libxul/lib' pointing to an 
absolute pathname '/usr/local/lib/libxul/sdk/lib'
Warning: Bad symlink '/usr/local/lib/libxul/bin' pointing to an 
absolute pathname '/usr/local/lib/libxul'
Warning: Bad symlink '/usr/local/lib/libxul/include' pointing to an 
absolute pathname '/usr/local/include/libxul'
Warning: Bad symlink '/usr/local/lib/libxul/idl' pointing to an 
absolute pathname '/usr/local/share/idl/libxul'



Cheers
Jochen



___
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"

More shebangfix problems with ports

[Rainer Hurling]

After the shebang rules where intensified, many ports have been fixed 
already. Many thanks for that!



For me, on 12.0-CURRENT, at least lang/go and www/libxul have non fixed 
shebangs until now:



lang/go:
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/lib/time/update.bash'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/benchcmp'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/nacl/go_nacl_386_exec'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/nacl/go_nacl_amd64p32_exec'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/misc/nacl/go_nacl_arm_exec'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/all.rc'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/clean.rc'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/src/cmd/dist/mkdeps.bash'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 
'go/src/cmd/go/mkalldocs.sh'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/make.rc'
Error: '/usr/bin/perl' is an invalid shebang you need USES=shebangfix 
for 'go/src/net/http/cgi/testdata/test.cgi'
Error: '/usr/bin/perl' is an invalid shebang you need USES=shebangfix 
for 'go/src/regexp/syntax/make_perl_groups.pl'
Error: '/bin/rc' is an invalid shebang you need USES=shebangfix for 
'go/src/run.rc'



www/libxul:
Error: '/usr/bin/env python' is an invalid shebang you need 
USES=shebangfix for 'lib/libxul/sdk/bin/xpidl.py'
Error: '/usr/bin/env python' is an invalid shebang you need 
USES=shebangfix for 'lib/libxul/sdk/bin/xpt.py'
Warning: Bad symlink '/usr/local/bin/xulrunner' pointing to an absolute 
pathname '/usr/local/lib/libxul/xulrunner'
Warning: Bad symlink '/usr/local/lib/libxul/lib' pointing to an absolute 
pathname '/usr/local/lib/libxul/sdk/lib'
Warning: Bad symlink '/usr/local/lib/libxul/bin' pointing to an absolute 
pathname '/usr/local/lib/libxul'
Warning: Bad symlink '/usr/local/lib/libxul/include' pointing to an 
absolute pathname '/usr/local/include/libxul'
Warning: Bad symlink '/usr/local/lib/libxul/idl' pointing to an absolute 
pathname '/usr/local/share/idl/libxul'

___
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: shebangfix problems with devel/llvm40 on 12.0-CURRENT

[Rainer Hurling]

Am 17.04.2017 um 16:44 schrieb Martin Wilke:
> I committed just a fix.

Hi Martin,

Your patch works as expected :)

Many thanks for this and the other shebang fixes.

Greetings from Germany,
Rainer


> 
> -- Original Message --
> From: "Rainer Hurling" <rhur...@gwdg.de>
> To: bro...@freebsd.org
> Cc: freebsd-ports@freebsd.org
> Sent: 17/04/2017 03:13:27 PM
> Subject: shebangfix problems with devel/llvm40 on 12.0-CURRENT
> 
>> On 12.0-CURRENT r316757 with recent ports system a got the following
>> built error:
>>
>>
>> [..snip..]
>> > Compressing man pages (compress-man)
>> ===>   Installing ldconfig configuration file
>> > Running Q/A tests (stage-qa)
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'bin/lit40'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'bin/llvm-lit40'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/bin/git-clang-format'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/bin/scan-view'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/bin/lit'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/bin/llvm-lit'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/share/clang/clang-format-diff.py'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/share/clang/clang-tidy-diff.py'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/share/clang/run-clang-tidy.py'
>> Error: '/usr/bin/env python' is an invalid shebang you need
>> USES=shebangfix for 'llvm40/share/clang/run-find-all-symbols.py'
>> Error: /usr/local/bin/FileCheck40 is linked to
>> /usr/local/lib/libtinfo.so.6 from devel/ncurses but it is not declared
>> as a dependency
>> Warning: you need USES+=ncurses
>> Error: /usr/local/llvm40/bin/lldb-server-4.0.0 is linked to
>> /usr/local/lib/libform.so.6 from devel/ncurses but it is not declared as
>> a dependency
>> Warning: you need USES+=ncurses
>> Error: /usr/local/llvm40/bin/lldb-server-4.0.0 is linked to
>> /usr/local/lib/libpanel.so.6 from devel/ncurses but it is not declared
>> as a dependency
>> Warning: you need USES+=ncurses
>> Error: /usr/local/llvm40/bin/lldb-server-4.0.0 is linked to
>> /usr/local/lib/libexecinfo.so.1 from devel/libexecinfo but it is not
>> declared as a dependency
>> Warning: you need USES+=execinfo
>> *** Error code 1
>>
>> Stop.
>> make[1]: stopped in /usr/ports/devel/llvm40
>> [..snip..]
>>
>>
>> I think, this is because of the new requirements of shebang pathes?
>>
>> Thanks for any help.

___
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"

shebangfix problems with devel/llvm40 on 12.0-CURRENT

[Rainer Hurling]

On 12.0-CURRENT r316757 with recent ports system a got the following
built error:


[..snip..]
> Compressing man pages (compress-man)
===>   Installing ldconfig configuration file
> Running Q/A tests (stage-qa)
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'bin/lit40'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'bin/llvm-lit40'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/bin/git-clang-format'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/bin/scan-view'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/bin/lit'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/bin/llvm-lit'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/share/clang/clang-format-diff.py'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/share/clang/clang-tidy-diff.py'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/share/clang/run-clang-tidy.py'
Error: '/usr/bin/env python' is an invalid shebang you need
USES=shebangfix for 'llvm40/share/clang/run-find-all-symbols.py'
Error: /usr/local/bin/FileCheck40 is linked to
/usr/local/lib/libtinfo.so.6 from devel/ncurses but it is not declared
as a dependency
Warning: you need USES+=ncurses
Error: /usr/local/llvm40/bin/lldb-server-4.0.0 is linked to
/usr/local/lib/libform.so.6 from devel/ncurses but it is not declared as
a dependency
Warning: you need USES+=ncurses
Error: /usr/local/llvm40/bin/lldb-server-4.0.0 is linked to
/usr/local/lib/libpanel.so.6 from devel/ncurses but it is not declared
as a dependency
Warning: you need USES+=ncurses
Error: /usr/local/llvm40/bin/lldb-server-4.0.0 is linked to
/usr/local/lib/libexecinfo.so.1 from devel/libexecinfo but it is not
declared as a dependency
Warning: you need USES+=execinfo
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/devel/llvm40
[..snip..]


I think, this is because of the new requirements of shebang pathes?

Thanks for any help.
___
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: graphics/opencv2 orphaned. Where from here

[Rainer Hurling]

Am 15.04.2017 um 01:04 schrieb Kevin Oberman:
> Thanks for the work on opencv, but PLEASE put something in UPDATING when
> you make changes that impact large numbers of ports. I see opencv2 as
> orphaned, so I can't stay there.
> 
> Do I reset the origin of opencv2 to opencv? Or will I need to delete all of
> them and rebuild everything? Please put information in UPDATING to give us
> poor users some idea of how to proceed. I really would rathe rnot have to
> re-install all of those ports if there is no reason.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683


As a user of portmaster, all I had to do, was:

portmaster -o graphics/opencv-core opencv2-core-2.4.13.1_1
portmaster -o graphics/opencv opencv2-2.4.13.1_6
portmaster -o graphics/py-opencv py27-opencv2-2.4.13.1_1
___
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: building net/samba43 in poudriere with gcc494

[Rainer Hurling]

Am 10.04.2017 um 20:32 schrieb Matthias Apitz:
> El día lunes, abril 10, 2017 a las 12:11:47p. m. -0400, Anton Yuzhaninov 
> escribió:
> 
>> On 04/10/17 08:06, Matthias Apitz wrote:
>>>
>>> I was able to build net/samba34 with setting 
>>>
>>> CC=gcc
>>> CXX=g++
>>>
>>> in /etc/make.conf on my r314251 with ports head from March, 4.
>>>
>>> How to is set CC=gcc only for the port net/samba34 in the make.conf
>>> files used by poudriere, i.e. not for all the other ~1800 ports?
>>
>> Add
>>
>> .if ${.CURDIR:N*/ports/net/samba34} == ""
>> USE_GCC=4.9
>> .endif
>>
>> to make.conf used by poudriere
> 
> Thanks, but this does not work; it installs the gcc49 pkg in the jail,
> but it sets the compiler to 'gcc49' which fails in the configure phase
> of the port.
> 
>   matthias
> 

I am using a file "jailname-portname-make.conf in
/usr/local/etc/poudriere.d. The jailname is the one, you also use for
the -j option of the poudriere run, the portname would be 'samba34'.

In your case, this conf file should contain USE_GCC=5+ .

HTH,
Rainer Hurling
___
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: devel/libcheck

[Rainer Hurling]

Hi René,

Am 06.02.2017 um 09:51 schrieb René Ladan:
> 2017-02-06 9:18 GMT+01:00 Rainer Hurling <rhur...@gwdg.de
> <mailto:rhur...@gwdg.de>>:
> 
> Am 06.02.2017 um 07:29 schrieb Kurt Jaeger:
> > Hi!
> >
> >> I just went to update my ports today on a machine, and there was a
> >> conflict between devel/check and devel/libcheck.
> >
> > It's more that libcheck was moved to check.
> >
> > According to /usr/ports/MOVED:
> >
> > devel/libcheck|devel/check|2017-02-05|Rename to match upstream naming
> >
> 
> For me, the following did the job:
> 
> portmaster -o devel/check libcheck-0.10.0
> 
> Perhaps, this is something for UPDATING?
> 
> No, UPDATING is for things humans need to do. portmaster should be able
> to figure this out from MOVED (which is mostly meant for machines).

Of course, I know this about UPDATING.

In this case with devel/check, the automatism with portmaster does not
work as expected, at least for Don and me.

Shouldn't portmaster, after a successful build of devel/check, first
deinstall libcheck and than install check?

For some reason, this seems not to work as expected. When portmaster
tries to install devel/check, it conflicts with a present
/usr/local/bin/checkmk, because libcheck was not uninstalled before.

I have no clue about the underlying reasons.

Rainer

> 
> René
> -- 
> https://rene-ladan.nl/

___
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: devel/libcheck

[Rainer Hurling]

Am 06.02.2017 um 07:29 schrieb Kurt Jaeger:
> Hi!
> 
>> I just went to update my ports today on a machine, and there was a 
>> conflict between devel/check and devel/libcheck.
> 
> It's more that libcheck was moved to check.
> 
> According to /usr/ports/MOVED:
> 
> devel/libcheck|devel/check|2017-02-05|Rename to match upstream naming
> 

For me, the following did the job:

portmaster -o devel/check libcheck-0.10.0

Perhaps, this is something for UPDATING?

___
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: net/boinc-client: make LINUX option a default or Slave port?

[Rainer Hurling]

Am 17.01.2017 um 21:29 schrieb Larry Rosenman:
> With the imminent demise of astro/boinc-setiathome-v7, I'm wondering if
> the
> community would object to net/boinc-client having its LINUX set as a
> default for the package.   Or a slave port with that option set.
> 
> I'm planning on taking MAINTAINER of net/boinc-client but would like
> input
> on the above.
> 
> Thanks!

Thanks for taking this up. It is really appreciated.

Excuse my ignorance. But, what are the differences in using native or
Linux boinc clients? And is this only of interest for SetiAtHome?

Thanks for any answer.

Best regards,
Rainer Hurling
___
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: Help with C++, gcc4.9 and libstdc++

[Rainer Hurling]

Hi Fernando,

Am 29.11.2016 um 17:50 schrieb Fernando Apesteguía:
> I maintain a port written mostly in C++ (cad/openvsp).
> 
> This port used to compile fine in 11 and 10.x in both i386 and amd64.
> Since Nov 22nd I'm receiving a pkg-fallout for this port in 10.1. The
> port fails with this message:
> 
> undefined reference to `__cxa_throw_bad_array_new_length'
> 
> I assume the source of the problem is defaulting to gcc 4.9 in the
> ports and it seems to be related to libstdc++
> 
> I use USES=compiler:gcc-c++11-lib in the Makefile since some c++11
> features are required. Any idea of why this could be failing to link?.
> What puzzles me is that it compiles fine with gcc 4.9 in 10.2.
> 
> Thanks in advance.

this also happens with a few other ports, and is described in

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863

As far, as I understand, a patch with a workaround will be committed in
the next time.

HTH,
Rainer
___
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: devel/llvm38 install seems to be missing files (e.g., FileCheck)

[Rainer Hurling]

Hi David,

Am 05.11.2016 um 14:54 schrieb David Wolfskill:
> On Sat, Nov 05, 2016 at 05:26:33AM -0700, David Wolfskill wrote:
>> ...
>> I circumvented the problem: ...
>>
>> g1-252(11.0-S)[20] sudo cp -p !$ /usr/local/llvm38/bin/
>> sudo cp -p work/stage/usr/local/llvm38/bin/FileCheck /usr/local/llvm38/bin/
>> g1-252(11.0-S)[21]
>>
>> That done, lang/rust built.
>>
>> My build machine is doing the first of its weekend poudriere runs
>> as I type; if that shows anything relevant with respect to lang/rust
>> and devel/llvm38, I'll follow up.
>> 
> 
> Turns out that "PORT_LLVM" is, by default, off; I had turned it on since
> I had other reasons to need llvm38 anyway.
> 
> And since I only use lang/rust as a build dependency (e.g., for
> www/fierfox), I had not specified any non-default options for the
> poudriere build.  Thus, poudriere had built rust using the "bundled"
> llvm38, which apparently has FileCheck in the place where the rust
> config looks for it.  So poudriere didn't have an issue building
> www/firefox (which required lang/rust).
> 
> Am I incorrect in thinking that devel/llvm38 has a problem, though, in
> that "%%LIT%%llvm38/bin/FileCheck" is in that port's pkg-plist, and
> llvm38/bin/FileCheck is found in the staging directory, but
> llvm38/bin/FileCheck is not actually installed?

not sure, if I missed something in your postings.

On my boxes, all recent FreeBSD 12.0-CURRENT amd64, the port
devel/llvm38 installed FileCheck as expected, in the two places
/usr/local/llvm38/bin/ and /usr/local/bin/.

Unfortunately, I have no clue, what happens on your side.

Best wishes,
Rainer Hurling

> 
> Peace,
> david
> 

___
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: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

[Rainer Hurling]

Am 01.09.2016 um 13:17 schrieb Mathieu Arnold:
> Le 01/09/2016 à 12:29, Konstantin Belousov a écrit :
>> On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
>>> I am the maintainer of databases/postgis-jdbc. For some days now I get
>>> mails like to one further down, for HEAD i386 and HEAD amd64.
>>>
>>> The FreeBSD package build server complains about a problem with untaring
>>> the jar distfile.
>>>
>>> This worked fine before, and as far as I can see, the distfile is ok. On
>>> Windows, I am also able to open the jar distfile and use it.
>>>
>>> I think, the port and the distfile are ok, and there is something odd
>>> with base tar, used by the port system.
>>>
>>> Any idea, what's going on here?
>>>
>>> Thanks for any help in advance.
>> Probably related to the libarchive updates, in particular r304869,
>> r304988, r304989.
>>
>> But I am not sure which version of the userspace the poudriere jail runs.
>> I see mention of r305036, which might be userspace, but also might be
>> just the kernel version.
> 
> On the package cluster, the pkgproduce script will always update a jail
> before building from it, for the releases, it does so using
> freebsd-update, for HEAD, it will rebuild the whole jail.  So if it says
> r305036, it is using that :-)
> The host, itself, is updated about once a month, at the same revision
> the rest of the cluster is, unless someone breaks the KBI, in which case
> it is updated early :-)
> 
> Right now, the box running the HEAD amd64 builds' host is running
> r304967 and the jail is "12.0-CURRENT r305036".
> 

Thanks for the clarification. I read this a little bit to late, so
answered kib@ a minute before ...
___
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: Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

[Rainer Hurling]

Am 01.09.2016 um 12:29 schrieb Konstantin Belousov:
> On Thu, Sep 01, 2016 at 11:47:33AM +0200, Rainer Hurling wrote:
>> I am the maintainer of databases/postgis-jdbc. For some days now I get
>> mails like to one further down, for HEAD i386 and HEAD amd64.
>>
>> The FreeBSD package build server complains about a problem with untaring
>> the jar distfile.
>>
>> This worked fine before, and as far as I can see, the distfile is ok. On
>> Windows, I am also able to open the jar distfile and use it.
>>
>> I think, the port and the distfile are ok, and there is something odd
>> with base tar, used by the port system.
>>
>> Any idea, what's going on here?
>>
>> Thanks for any help in advance.
> Probably related to the libarchive updates, in particular r304869,
> r304988, r304989.
> 
> But I am not sure which version of the userspace the poudriere jail runs.
> I see mention of r305036, which might be userspace, but also might be
> just the kernel version.

Thanks for the answer, really appreciated!

I investigated a little bit more on the ports side and it turns out,
that adding USES=zip:infozip should do the trick :)

Now I am testing in poudriere, if there would be any side effects with
my patch to databases/postgis-jdbc ...

Nevertheless, it is likely that we found an edge condition for the
libarchive updates in r304989.

BTW: I did not understand, why r305036 is relevant here?

> 
>>
>> Regards,
>> Rainer Hurling
>>
>>
>>  Weitergeleitete Nachricht 
>> Betreff: [package - head-amd64-default][databases/postgis-jdbc] Failed
>> for postgis-jdbc-2.1.7 in extract
>> Datum: Thu, 1 Sep 2016 09:11:11 +
>> Von: pkg-fall...@freebsd.org
>> An: rhur...@gwdg.de
>> Kopie (CC): pkg-fall...@freebsd.org
>>
>> You are receiving this mail as a port that you maintain
>> is failing to build on the FreeBSD package build server.
>> Please investigate the failure and submit a PR to fix
>> build.
>>
>> Maintainer: rhur...@gwdg.de
>> Last committer: m...@freebsd.org
>> Ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile 412346
>> 2016-04-01 14:00:51Z mat $
>> Log URL:
>> http://beefy4.nyi.freebsd.org/data/head-amd64-default/p421100_s305036/logs/postgis-jdbc-2.1.7.log
>> Build URL:
>> http://beefy4.nyi.freebsd.org/build.html?mastername=head-amd64-default=p421100_s305036
>> Log:
>>
>> >> Building databases/postgis-jdbc
>> build started at Thu Sep  1 09:11:08 UTC 2016
>> port directory: /usr/ports/databases/postgis-jdbc
>> building for: FreeBSD head-amd64-default-job-22 12.0-CURRENT FreeBSD
>> 12.0-CURRENT r305036 amd64
>> maintained by: rhur...@gwdg.de
>> Makefile ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile
>> 412346 2016-04-01 14:00:51Z mat $
>> Poudriere version: 3.1.14
>> Host OSVERSION: 125
>> Jail OSVERSION: 125
>>
>> ---Begin Environment---
>> SHELL=/bin/csh
>> UNAME_v=FreeBSD 12.0-CURRENT r305036
>> UNAME_r=12.0-CURRENT
>> BLOCKSIZE=K
>> MAIL=/var/mail/root
>> STATUS=1
>> OPSYS=FreeBSD
>> ARCH=amd64
>> SAVED_TERM=
>> MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
>> UID=0
>> PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
>> _JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
>> POUDRIERE_BUILD_TYPE=bulk
>> PKGNAME=postgis-jdbc-2.1.7
>> OSREL=12.0
>> _OSRELEASE=12.0-CURRENT
>> PYTHONBASE=/usr/local
>> OLDPWD=/
>> _SMP_CPUS=24
>> PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
>> HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32
>> MASTERNAME=head-amd64-default
>> SCRIPTPREFIX=/usr/local/share/poudriere
>> _JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
>> USER=root
>> HOME=/root
>> POUDRIERE_VERSION=3.1.14
>> SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
>> CONFIGURE_MAX_CMD_LEN=262144
>> LIBEXECPREFIX=/usr/local/libexec/poudriere
>> LOCALBASE=/usr/local
>> PACKAGE_BUILDING=yes
>> _JAVA_OS_LIST_REGEXP=native\|linux
>> OSVERSION=125
>> ---End Environment---
>>
>> ---Begin OPTIONS List---
>> ---End OPTIONS List---
>>
>> --CONFIGURE_ARGS--
>>
>> --End CONFIGURE_ARGS--
>>
>> --CONFIGURE_ENV--
>> XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
>> XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
>> HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
>> SHELL=/bin/sh CONFIG_SHELL=/bin/sh
>> --End CONFIGUR

Fwd: [package - head-amd64-default][databases/postgis-jdbc] Failed for postgis-jdbc-2.1.7 in extract

[Rainer Hurling]

I am the maintainer of databases/postgis-jdbc. For some days now I get
mails like to one further down, for HEAD i386 and HEAD amd64.

The FreeBSD package build server complains about a problem with untaring
the jar distfile.

This worked fine before, and as far as I can see, the distfile is ok. On
Windows, I am also able to open the jar distfile and use it.

I think, the port and the distfile are ok, and there is something odd
with base tar, used by the port system.

Any idea, what's going on here?

Thanks for any help in advance.

Regards,
Rainer Hurling


 Weitergeleitete Nachricht 
Betreff: [package - head-amd64-default][databases/postgis-jdbc] Failed
for postgis-jdbc-2.1.7 in extract
Datum: Thu, 1 Sep 2016 09:11:11 +
Von: pkg-fall...@freebsd.org
An: rhur...@gwdg.de
Kopie (CC): pkg-fall...@freebsd.org

You are receiving this mail as a port that you maintain
is failing to build on the FreeBSD package build server.
Please investigate the failure and submit a PR to fix
build.

Maintainer: rhur...@gwdg.de
Last committer: m...@freebsd.org
Ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile 412346
2016-04-01 14:00:51Z mat $
Log URL:
http://beefy4.nyi.freebsd.org/data/head-amd64-default/p421100_s305036/logs/postgis-jdbc-2.1.7.log
Build URL:
http://beefy4.nyi.freebsd.org/build.html?mastername=head-amd64-default=p421100_s305036
Log:

>> Building databases/postgis-jdbc
build started at Thu Sep  1 09:11:08 UTC 2016
port directory: /usr/ports/databases/postgis-jdbc
building for: FreeBSD head-amd64-default-job-22 12.0-CURRENT FreeBSD
12.0-CURRENT r305036 amd64
maintained by: rhur...@gwdg.de
Makefile ident:  $FreeBSD: head/databases/postgis-jdbc/Makefile
412346 2016-04-01 14:00:51Z mat $
Poudriere version: 3.1.14
Host OSVERSION: 125
Jail OSVERSION: 125

---Begin Environment---
SHELL=/bin/csh
UNAME_v=FreeBSD 12.0-CURRENT r305036
UNAME_r=12.0-CURRENT
BLOCKSIZE=K
MAIL=/var/mail/root
STATUS=1
OPSYS=FreeBSD
ARCH=amd64
SAVED_TERM=
MASTERMNT=/usr/local/poudriere/data/.m/head-amd64-default/ref
UID=0
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
_JAVA_VERSION_LIST_REGEXP=1.6\|1.7\|1.8\|1.6+\|1.7+\|1.8+
POUDRIERE_BUILD_TYPE=bulk
PKGNAME=postgis-jdbc-2.1.7
OSREL=12.0
_OSRELEASE=12.0-CURRENT
PYTHONBASE=/usr/local
OLDPWD=/
_SMP_CPUS=24
PWD=/usr/local/poudriere/data/.m/head-amd64-default/ref/.p/pool
HAVE_COMPAT_IA32_KERN=YES LINUX_OSRELEASE=2.6.32
MASTERNAME=head-amd64-default
SCRIPTPREFIX=/usr/local/share/poudriere
_JAVA_VENDOR_LIST_REGEXP=openjdk\|oracle\|sun
USER=root
HOME=/root
POUDRIERE_VERSION=3.1.14
SCRIPTPATH=/usr/local/share/poudriere/bulk.sh
CONFIGURE_MAX_CMD_LEN=262144
LIBEXECPREFIX=/usr/local/libexec/poudriere
LOCALBASE=/usr/local
PACKAGE_BUILDING=yes
_JAVA_OS_LIST_REGEXP=native\|linux
OSVERSION=125
---End Environment---

---Begin OPTIONS List---
---End OPTIONS List---

--CONFIGURE_ARGS--

--End CONFIGURE_ARGS--

--CONFIGURE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
SHELL=/bin/sh CONFIG_SHELL=/bin/sh
--End CONFIGURE_ENV--

--MAKE_ENV--
XDG_DATA_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
XDG_CONFIG_HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work
HOME=/wrkdirs/usr/ports/databases/postgis-jdbc/work TMPDIR="/tmp"
NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh
NO_LINT=YES PREFIX=/usr/local  LOCALBASE=/usr/local  LIBDIR="/usr/lib"
CC="cc" CFLAGS="-O2 -pipe  -fstack-protector -fno-strict-aliasing"
CPP="cpp" CPPFLAGS=""  LDFLAGS=" -fstack-protector" LIBS=""  CXX="c++"
CXXFLAGS="-O2 -pipe -fstack-protector -fno-strict-aliasing "
MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install  -s -m 555"
BSD_INSTALL_LIB="install  -s -m 444"  BSD_INSTALL_SCRIPT="install  -m
555"  BSD_INSTALL_DATA="install  -m 0644"  BSD_INSTALL_MAN="install  -m 444"
--End MAKE_ENV--

--PLIST_SUB--
JAVASHAREDIR="share/java"
JAVAJARDIR="share/java/classes"
OSREL=12.0
PREFIX=%D
LOCALBASE=/usr/local
RESETPREFIX=/usr/local
PORTDOCS=""
PORTEXAMPLES=""
LIB32DIR=lib
DOCSDIR="share/doc/postgis-jdbc"
EXAMPLESDIR="share/examples/postgis-jdbc"
DATADIR="share/postgis-jdbc"
WWWDIR="www/postgis-jdbc"
ETCDIR="etc/postgis-jdbc"
--End PLIST_SUB--

--SUB_LIST--
JAVASHAREDIR="/usr/local/share/java"
JAVAJARDIR="/usr/local/share/java/classes"
JAVALIBDIR="/usr/local/share/java/classes"
JAVA_VERSION="1.6+"
PREFIX=/usr/local
LOCALBASE=/usr/local
DATADIR=/usr/local/share/postgis-jdbc
DOCSDIR=/usr/local/share/doc/postgis-jdbc
EXAMPLESDIR=/usr/local/share/examples/postgis-jdbc
WWWDIR=/usr/local/www/postgis-jdbc
E

INDEX-12 for 12-CURRENT missing?

[Rainer Hurling]

On my boxes with 12-CURRENT amd64 I am not able to fetch the ports index
file any more:

#cd /usr/ports
#make fetchindex
fetch: http://www.FreeBSD.org/ports/INDEX-12.bz2: Not Found
*** Error code 1
Stop.
make: stopped in /usr/ports


Is there any reason to not provide an INDEX file for 12-CURRENT?

Thanks in advance.

Regards,
Rainer Hurling
___
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: python 3.4.5 update

[Rainer Hurling]

Am 30.06.16 um 11:02 schrieb Otacílio de Araújo Ramos Neto:

Em qua, 29 de jun de 2016 20:16, Stari Karp <starik...@yandex.com> escreveu:




Hi!

I tried to update Python on my
10.3-RELEASE-p5 (akd64) and I got:




ports/lang/python34/work/Python-3.4.5 ./python -E -m
ensurepip  $ensurepip --root=/usr/ports/lang/python34/work/stage/ ;  fi
/bin/rm -f
/usr/ports/lang/python34/work/stage/usr/local/lib/libpython3.so
# Upstream Issue: http://bugs.python.org/issue17975
for i in
/usr/ports/lang/python34/work/stage/usr/local/lib/python3.4/lib-
dynload/*.so; do  /usr/bin/strip $i; done
# Strip shared extensions
> Compressing man pages (compress-man)

===>>> Creating a backup package for old version python34-3.4.4_3
Creating package for python34-3.4.4_3
process with pid 2056 still holds the lock
process with pid 2056 still holds the lock
process with pid 2056 still holds the lock
process with pid 2056 still holds the lock
process with pid 2056 still holds the lock
process with pid 2056 still holds the lock
pkg: Cannot get an advisory lock on a database, it is locked by another
process

===>>> Starting check for runtime dependencies
===>>> Gathering dependency list for lang/python34 from ports
===>>> Dependency check complete for lang/python34

===>>> All >> python34-3.4.4_3 (1/1)

===>  Installing for python34-3.4.5
===>  Checking if python34 already installed
===>   An older version of python34 is already installed (python34-
3.4.4_3)
  You may wish to ``make deinstall'' and install this port again
  by ``make reinstall'' to upgrade it properly.
  If you really wish to overwrite the old port of python34
  without deleting it first, set the variable "FORCE_PKG_REGISTER"
  in your environment or the "make install" command line.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/python34
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/python34

===>>> A backup package for python34-3.4.4_3 should
   be located in /usr/ports/packages/portmaster-backup

===>>> Installation of python34-3.4.5 (lang/python34) failed
===>>> Aborting update

===>>> Update for lang/python34 failed
===>>> Aborting update

Thank you very much.

SK



Are you shure that no other process is handling The ports at the same time?
Like doing a query.

[]'S
-Otacilio

As far as I know, portmaster itself has some not yet solved problems 
with ports, escpecially in a mixed system of ports, installed as a 
package by pkg and build from sources.


For me, there are some possible opportunities, to circumstance this 
behaviour:


1) portmaster -m "FORCE_PKG_REGISTER" lang/python34
   [this also does not work in all situations :( ]

2) portmaster lang/perl5 lang/python34
   [(re)installing something like lang/perl5 before should help always ]

3) cd /usr/ports/lang/python34
   make clean && make install

Please keep in mind, that your failed update already deinstalled the old 
python 3.4.4 port, but failed to install the new version. So, at the 
moment, python 3 is probably not installed on your system. You can get 
back the old version by


   pkg add /usr/ports/packages/portmaster-backup/python34-3.4.4_3

as stated by portmasters message.

HTH,
Rainer Hurling


___
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: Any interest in keeping Boinc & SETI alive.

[Rainer Hurling]

Am 27.02.16 um 13:27 schrieb Ron Von:
> HI all, I was wondering if there was any interest in keeping the BOINC ports 
> alive? SETI is now at version 8, and thus version 7 is useless now.  I don't 
> have porting and compiling skills yet, so otherwise I would try my hand at it.

Hi Ron,

Thanks for asking.

I am one of the guys, who uses BOINC not only for SETI, but also for
lhcathomeclassic, milkiway, and einstein. So yes, there is an interest
in keeping these ports alive.

Regards,
Rainer


> Thanks!

___
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"

graphics/qgis: commit of PR 206834

[Rainer Hurling]

Hi committers,

is someone willing to commit bug 206834 [1]?

It is about activating some features by new options in QGIS and it is 
maintainer approved (by me).


Thanks in advance.

Best regards,
Rainer Hurling


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206834
___
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 port assistance for mlr

[Rainer Hurling]

Am 31.01.16 um 17:57 schrieb Kurt Jaeger:
> Hi!
> 
>> Do I need to contact the maintainer and see why it won't build on 9?
> 
> The problem is that the port requires a recent flex, but 9.3 has
> an older version. So for 9.3 the makefiles need some patch
> to use the proper flex version.
> 
>> Do you have the build log that I can show him?
> 
> http://people.freebsd.org/~pi/logs/textproc__miller-93a-1454241832.txt
> 

I had a nearly similar problem with graphics/qgis. This way it works for me:

.if ${OPSYS} == FreeBSD && ${OSVERSION} < 100
BUILD_DEPENDS+= flex>=2.5.39:${PORTSDIR}/textproc/flex
CMAKE_ARGS+=-DFLEX_EXECUTABLE:STRING=${LOCALBASE}/bin/flex
CXXFLAGS+=  -I${LOCALBASE}/include/flex
.endif

HTH,
Rainer

___
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: FreeBSD Port: mcmc-jags-3.4.0_4

[Rainer Hurling]

Hello Giuseppe,

Am 23.11.15 um 10:07 schrieb Giuseppe Pagnoni:

Hello Rainer,

don't mean to pressure you in any way, and thank you in advance for your
work in maintaining the port, but do you happen to have any status
update on mcmc-jags v. 4?


I am sorry, but I am not the maintainer of the port. I only filed a PR 
(Bug 204525) as a suggestion for an update.


The maintainer (b...@freebsd.org, CC'ed) is the person to decide, if this 
should happen.


In the meantime, you could try the patch as a local copy and update your 
math/jags installation, if you want to.


HTH,
Rainer




very best
giuseppe

On Fri, Nov 13, 2015 at 6:18 PM, Rainer Hurling <rhur...@gwdg.de
<mailto:rhur...@gwdg.de>> wrote:

Hi Giuseppe,

Am 13.11.15 um 16:36 schrieb Giuseppe Pagnoni:
> Hello,
>
> I noticed that the R package for calling jags is now pointing to JAGS v.
> 4.  I was wondering if an upgrade to the mcmc-jags port is in the making.
>
> Thank you very much for your attention and for maintaining the port.

some weeks ago I prepared an updated port for math/jags in the hurry. It
was never published, only used local by me. But it seems to work :)


I just filed a PR [1] and put this version in. It is only quick and
dirty, at least some smaller problems remain.

HTH,
Rainer

 >
 > very best
 > giuseppe
 >


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204525




--
Giuseppe Pagnoni
Dip. Scienze Biomediche, Metaboliche e Neuroscienze
Sezione Fisiologia e Neuroscienze
Univ. di Modena e Reggio Emilia
Via Campi 287
I-41125 Modena, Italy
Tel: +39-059-205-5742
Fax: +39-059-205-5363



___
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: FreeBSD Port: mcmc-jags-3.4.0_4

[Rainer Hurling]

Hi Giuseppe,

Am 13.11.15 um 16:36 schrieb Giuseppe Pagnoni:
> Hello,
> 
> I noticed that the R package for calling jags is now pointing to JAGS v.
> 4.  I was wondering if an upgrade to the mcmc-jags port is in the making.
> 
> Thank you very much for your attention and for maintaining the port.

some weeks ago I prepared an updated port for math/jags in the hurry. It
was never published, only used local by me. But it seems to work :)


I just filed a PR [1] and put this version in. It is only quick and
dirty, at least some smaller problems remain.

HTH,
Rainer

> 
> very best
> giuseppe
> 


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204525

___
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: texlive appears broken

[Rainer Hurling]

Am 13.11.15 um 02:55 schrieb Steve Kargl:

On Thu, Nov 12, 2015 at 01:16:38PM -0800, Steve Kargl wrote:

% make
% make install

...


pkg-static: Unable to access file 
/usr/ports/print/texlive-base/work/stage/usr/local/bin/a2ping: No such file or 
directory
pkg-static: Unable to access file 
/usr/ports/print/texlive-base/work/stage/usr/local/bin/a5toa4: No such file or 
directory


Sigh.  All of these install errors are due to the
recent collate changes.

make install fails with

troutmask:root[220] locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

make install works with

troutmask:root[220] locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE=C
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=




I think, it is the same problem with LC_COLLATE=C, that I reported in 
[1]. It took me some time to find out, that some build processes need 
LC_COLLATE=C instead of LC_COLLATE=xx_XX.UTF-8 with the new locale stuff 
from bapt@.


Regards,
Rainer Hurling


[1] https://www.mail-archive.com/freebsd-ports@freebsd.org/msg66706.html
___
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: lang/gcc48 fails to build [on HEAD]

[Rainer Hurling]

Am 09.11.15 um 11:06 schrieb Gerald Pfeifer:
> Hi Rainer,
> 
> On Mon, 9 Nov 2015, Rainer Hurling wrote:
>> I am using lang/gcc48 for a long time now on FreeBSD 11.0-CURRENT. From 
>> time to time I have to rebuild the port. This is the first time, that I 
>> get the following error:
> 
> I have no idea where this is coming from.  In fact, I rebuilt
> the lang/gcc port just last night (which is pretty much the same)
> and did not run into this.
> 
>> Is this a known error? It seems, there is something odd with C++ mode 
>> and C files?
> 
> GCC now is built as C++ code, even though most source files have
> not been renamed from .c.  So this warning is expected and can be
> ignored.
> 
> This being an old port, nothing has changed on the GCC side.  Which
> means something in -CURRENT must have broken it.
> 
> Gerald
> 

I think I found the problem.

In my initial mail of this thread, I reported, that after upgrading
Freebsd 11.0-CURRENT to r290538 (including locale and localedef updates)
I am not able to build lang/gccXX any more. All I get are errors like
that in usr/ports/lang/gccXX/work/build/gcc:


In file included from .././../gcc-4.8.5/gcc/genflags.c:26:
In file included from ./tm.h:16:
./options.h:4293:3: error: redefinition of enumerator 'OPT_C'
  OPT_C = 129,   /* -C */
  ^


After more than 20 of them the build stops with
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.


This is with locale for Germany:
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_ALL=


If I use 'LC_COLLATE="C"' for the build, the build works fine again:

cd /usr/ports/lang/gcc48
env LC_COLLATE="C" make
...


So it seems, that something with the new 'locale' code in base of HEAD
is not working as expected here? (At least for other locales than US?)

I added bapt@, because he is the author introducing the new code into HEAD.

Hope, my explanations are clear enough to get the problem. Please feel
free to ask for more information, if needed.

Regards,
Rainer Hurling

___
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"

lang/gcc48 fails to build

[Rainer Hurling]

I am using lang/gcc48 for a long time now on FreeBSD 11.0-CURRENT. From 
time to time I have to rebuild the port. This is the first time, that I 
get the following error:



[..snip..]
gmake[4]: Verzeichnis „/usr/ports/lang/gcc48/work/build/gcc“ wird betreten
c++   -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing  -DLIBICONV_PLUG 
-DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o 
build/gengtype \
build/gengtype.o build/errors.o build/gengtype-lex.o 
build/gengtype-parse.o build/gengtype-state.o build/version.o 
../build-x86_64-portbld-freebsd11.0/libiberty/libiberty.a

build/gengtype  \
-S .././../gcc-4.8.5/gcc -I gtyp-input.list -w 
tmp-gtype.state

/bin/sh .././../gcc-4.8.5/gcc/../move-if-change tmp-gtype.state gtype.state
build/gengtype  \
-r gtype.state
echo timestamp > s-gtype
c++ -c   -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing  -DLIBICONV_PLUG 
-DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild 
-I.././../gcc-4.8.5/gcc -I.././../gcc-4.8.5/gcc/build 
-I.././../gcc-4.8.5/gcc/../include 
-I.././../gcc-4.8.5/gcc/../libcpp/include -DLIBICONV_PLUG \

-o build/genflags.o .././../gcc-4.8.5/gcc/genflags.c
c++: warning: treating 'c' input as 'c++' when in C++ mode, this 
behavior is deprecated

In file included from .././../gcc-4.8.5/gcc/genflags.c:26:
In file included from ./tm.h:16:
./options.h:4293:3: error: redefinition of enumerator 'OPT_C'
  OPT_C = 129,   /* -C */
  ^
./options.h:4290:3: note: previous definition is here
  OPT_C = 126,   /* -C */
  ^
./options.h:4301:3: error: redefinition of enumerator 'OPT_d'
  OPT_d = 137,   /* -d */
  ^
./options.h:4299:3: note: previous definition is here
  OPT_d = 135,   /* -d */
  ^
[..snip..]
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
Makefile:3840: die Regel für Ziel „build/genflags.o“ scheiterte
gmake[4]: *** [build/genflags.o] Fehler 1
gmake[4]: Verzeichnis „/usr/ports/lang/gcc48/work/build/gcc“ wird verlassen
Makefile:3908: die Regel für Ziel „all-gcc“ scheiterte
gmake[3]: *** [all-gcc] Fehler 2


Is this a known error? It seems, there is something odd with C++ mode 
and C files?


This happens on a FreeBSD 11.0-CURRENT box with r290541 (bapt's 
locale/localedef updates of base from the weekend included).


Please tell me, if I should provide more information.

Thanks in advance,
Rainer Hurling
___
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"

science/libkml: conflicting file with archivers/minizip

[Rainer Hurling]

Dear developers and maintainers,

I just tried to install science/libkml (as a dependency of graphics/gdal).

'make && make install' gives the following error:

[..snip..]
Installing libkml-1.2_4...
pkg-static: libkml-1.2_4 conflicts with minizip-1.2.8_1 (installs files
into the same place).  Problematic file: /usr/local/lib/libminizip.a
*** Error code 70


archivers/minizip  is needed for example by multimedia/vlc,
emulators/mupen64plus-core, and net-im/psi.

It would be fine, if this conflict could be solved.


Many thanks in advance,
Rainer Hurling
___
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 port with USES=gmake will not stage

[Rainer Hurling]

Hi Euan,

Am 11.06.2015 um 07:33 schrieb Euan Thoms:


On Thursday, June 11, 2015 13:18 SGT, Chris H bsd-li...@bsdforge.com wrote:


On Thu, 11 Jun 2015 11:33:03 +0800 Euan Thoms e...@potensol.com wrote


I'm making a port for OpenSIPS. It builds successfully, but the even with
just make it installs files to the system instead of to stage (i.e. to
/usr/local/... instead of /usr/ports/net/opensips/work/stage/usr/local/...).

I am using gmake and gcc since that's what's required for OpenSIPS.

I've done a similar port before and the FreeBSD ports macros do the staging
for me. However, even when I tell gmake the DESTDIR=${STAGEDIR} in do-build
and do-install, a make just installs the files to /usr/local/... .

I can't find any documentation on how to ensure building uses staging.
OpenSIPS doesn't have a configure script AFAIK. It has it's own menuconfig
which normally generates a Makefile.conf. The only thing useful in there is
PREFIX= , but that is to specify the final destination paths (also used in
linking I guess). My port passes the compile flags in MAKE_ARGS instead of
using a Makefile.conf file.

Kind of a tough call w/o any real information -- your Makefile, the source
location? :)


Sorry about that.

Source file is here: 
http://opensips.org/pub/opensips/1.11.5/opensips-1.11.5-latest_src.tar.gz

here is my Makefile contents:

# cat Makefile
# Created by: Euan Thoms e...@potensol.com
# $FreeBSD$



I am wondering, if there is a small typo in your PORTNAME. Shouldn't it 
be 'opensips1-tls' instead of 'opensips1-lts' (lts - tls)?


And why do you use 'opensips1' instead of 'opensips'? PORTVERSION 
already includes the version number. It seems, this complicates the 
subsequent setting of WRKSRC etc ...



PORTNAME=   opensips1-lts
PORTVERSION=1.11.5
CATEGORIES= net
MASTER_SITES=   http://opensips.org/pub/opensips/1.11.5/
DISTNAME=   opensips-${PORTVERSION}-latest_src

MAINTAINER= e...@potensol.com
COMMENT=OpenSIPS (Open SIP Server) is a mature Open Source 
implementation of a SIP server.

LICENSE=GPLv2
LIB_DEPENDS=libxml2.so:${PORTSDIR}/textproc/libxml2 \
 libmemcached.so:${PORTSDIR}/databases/libmemcached

BUILD_DEPENDS=  python:${PORTSDIR}/lang/python

WRKSRC= ${WRKDIR}/opensips-${PORTVERSION}-tls

OPTIONS_DEFINE= LDAP MYSQL PGSQL MEMCACHED
OPTIONS_DEFAULT=LDAP PGSQL MEMCACHED
OPTIONS_SUB= yes

LDAP_DESC=  Build with LDAP support
MYSQL_DESC= Build with MySQL support
PGSQL_DESC= Build with PostgreSQL support
MEMCACHED_DESC= Build with memcached support

USES=   gmake shebangfix
USE_GCC=yes

.include bsd.port.options.mk

#post-patch:
#   ${REINPLACE_CMD} -e 's|^#include Python.h|#include Python.h|' 
${WRKSRC}/

EXCLUDE_MODULES=aaa_radius b2b_logic cachedb_cassandra 
cachedb_couchbase \
 cachedb_memcached cachedb_mongodb cachedb_redis 
carrierroute cpl-c db_berkeley \
 db_http db_mysql db_oracle db_perlvdb db_postgres 
db_unixodbc dialplan \
 event_rabbitmq h350 regex identity jabber json ldap 
lua httpd mi_xmlrpc_ng \
 mi_xmlrpc mmgeoip osp perl pi_http presence 
presence_dialoginfo presence_mwi \
 presence_xml pua pua_bla pua_dialoginfo pua_mi 
pua_usrloc pua_xmpp python \
 rest_client rls sngtc snmpstats xcap xcap_client xmpp

INCLUDE_MODULES=aaa_radius b2b_logic cachedb_memcached carrierroute \
 cpl-c db_postgres dialplan event_rabbitmq h350 regex 
identity jabber json \
 ldap httpd mi_xmlrpc_ng mi_xmlrpc mmgeoip perl pi_http 
presence \
 presence_dialoginfo presence_mwi presence_xml pua 
pua_bla pua_dialoginfo \
 pua_mi pua_usrloc pua_xmpp python rest_client rls xcap 
xcap_client xmpp

MAKE_ARGS+= PREFIX=${LOCALBASE}
MAKE_ARGS+= exclude_modules=${EXCLUDE_MODULES} 
include_modules=${INCLUDE_MODULES}

#do-build:
#   cd ${WRKSRC}  ${GMAKE} ${MAKE_ARGS} ${ALL_TARGET}
#
#do-install:
#   cd ${WRKSRC}  ${GMAKE} ${MAKE_ARGS} ${INSTALL_TARGET}

.include bsd.port.mk
 EOF 

I can't find the make files for stage to drill down and see what's going wrong. Any 
pointers to the script that make stage uses?



--
Regards, Euan Thoms


___
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 port with USES=gmake will not stage

[Rainer Hurling]

Am 11.06.2015 um 09:43 schrieb Euan Thoms:


On Thursday, June 11, 2015 15:35 SGT, Rainer Hurling rhur...@gwdg.de wrote:



I am wondering, if there is a small typo in your PORTNAME. Shouldn't it
be 'opensips1-tls' instead of 'opensips1-lts' (lts - tls)?

And why do you use 'opensips1' instead of 'opensips'? PORTVERSION
already includes the version number. It seems, this complicates the
subsequent setting of WRKSRC etc ...



No, it's not  a typo. It's version 1.11.5 LTS (Long Term Support), so I named 
it opensips1-lts so that the current stable (v2.1.0) could be called opensips 
or opensips2. In other words I'm thinking further down the line. But I'm 
personally most interested in a LTS branch. I needs the upgrade stability, 
rather than new features.



Thanks for the clarification and sorry to bother you with these issues.

___
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

graphics/gdal: /lib/libgcc_s.so.1 problem

[Rainer Hurling]

For some time now, I get the following message, when I use some of the 
GDAL tools (graphics/gdal) on FreeBSD HEAD (11.0-CURRENT r278036). For 
example, if I try:



#gdalinfo --version
ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found

GDAL 1.11.1, released 2014/09/24

Because of this, GDAL is not usable for me with ports like math/saga or 
graphics/qgis on HEAD. They core dump right after starting them.


The port graphics/gdal itself builds and installs fine. Don't know, if 
this is relevant: On my boxes, devel/libc++ is installed by other ports.


Obviously, there is something odd between clang (base) and gcc (ports). 
Is this a known problem?


Thanks for any help.

Regards,
Rainer Hurling
___
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: eTeX in TeXlive

[Rainer Hurling]

Am 03.12.2014 um 09:19 schrieb Michael:

Hi everyone!


In my current installation of TeXlive (texlive-base-20140525_3) there
is no command etex.  This is a problem, as some packages and programs
rely on etex (e.g. metapost).

I am not sure which port to install to have an etex program again.


Also I just noticed fmtutil-sys --all does nothing (just sit for half
a second or so), isn't it expected that it rebuilds all available
formats?


Shouldn't all this be solved by installing print/texlive-texmf?

HTH,
Rainer Hurling


I'm stymied!
\bye


___
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: eTeX in TeXlive

[Rainer Hurling]

Am 03.12.2014 um 11:05 schrieb Michael:

Rainer Hurling wrote:

Am 03.12.2014 um 09:19 schrieb Michael:

In my current installation of TeXlive (texlive-base-20140525_3) there
is no command etex. [Also an issue with fmtutil-sys]

Shouldn't all this be solved by installing print/texlive-texmf?

It is already there:

# pkg info texlive-texmf
texlive-texmf-20140525_4

Do you think it is worth trying to ritually build the package from source?



Hmm, I am not an expert in this. Eventually there are some hangovers 
from a former teTeX installation?


___
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: GNOME3 and nvidia-driver

[Rainer Hurling]

Hi Jonathan,

Am 24.11.2014 um 21:10 schrieb Jonathan Chen:
 Hi,
 
 The latest GNOME3 update doesn't appear to live well with
 nvidia-driver. I'm attempting to build gnome3, but it's failing during
 the configure of graphics/cogl (required by graphics/cogl, required by
 graphics/clutter, required by accessibility/caribou):
 
 ...
 checking for GLIB - version = 2.32.0... yes (version 2.42.0)
 checking EGL/egl.h usability... no
 checking EGL/egl.h presence... no
 checking for EGL/egl.h... no
 configure: error: Unable to locate required EGL headers
 ===  Script configure failed unexpectedly.
 ...
 
 Hmm. Okay, a quick search reveals graphics/libEGL has the headers.
 # cd /usr/ports/graphics/libEGL  make install clean
 ...
 ===  Checking if libEGL already installed
 ===   Registering installation for libEGL-10.3.3
 pkg-static: libEGL-10.3.3 conflicts with nvidia-driver-340.46
 (installs files into the same place).  Problematic file:
 /usr/local/lib/libEGL.so
 *** Error code 70
 
 Stop.
 make: stopped in /usr/ports/graphics/libEGL
 
 What should I do?

For me, the following works as a workaround:

1.   Switch back to a console (without using X11)
2.   pkg delete -f nvidia-driver-340.46
3.   portmaster -a
 portmaster x11/gnome3
4.   pkg delete -f libEGL-10.3.3
5.   cd /usr/ports/x11/nvidia-driver  make install [ kldload nvidia]

After that, you should be able to start X11 again and work as usual. It
seems to be no problem without having libEGL installed, because there is
a libEGL version from nvidia-driver installed.

Of course, it would be better, if someone could solve the conflict of
the two ports ;)

HTH,
Rainer Hurling


 Cheers
 --
 Jonathan Chen j...@chen.org.nz

___
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: [audio/pulseaudio] no sound after update from 0.9.23 to 5.0

[Rainer Hurling]

Am 22.11.2014 um 09:51 schrieb Rainer Hurling:
 Together with the big gnome3 update also audio/pulseaudio was updated.
 Unfortunately, after that update, I have no sound anymore. Before, with
 PulseAudio 0.9.23, sound was excellent.
 
 Because I am using an ASUS mainboard 'M4A88TD-V EVO-USB3' and a NVIDIA
 GeForce GTX 750Ti with a recent HEAD (amd64), my sound devices are like
 this:
 
 #cat /dev/sndstat
 FreeBSD Audio Driver (64bit 2009061500/amd64)
 Installed devices:
 pcm0: NVIDIA (0x0060) (HDMI/DP 8ch) on hdaa0 kld snd_hda (1p:1v/0r:0v)
 pcm1: NVIDIA (0x0060) (HDMI/DP 8ch) on hdaa0 kld snd_hda (1p:6v/0r:0v)
 pcm2: NVIDIA (0x0060) (HDMI/DP 8ch) on hdaa0 kld snd_hda (1p:1v/0r:0v)
 pcm3: Realtek ALC892 (Analog 7.1+HP/2.0) on hdaa1 kld snd_hda
 (1p:6v/1r:2v) default
 pcm4: Realtek ALC892 (Rear Digital) on hdaa1 kld snd_hda (1p:1v/0r:0v)
 pcm5: Realtek ALC892 (Onboard Digital) on hdaa1 kld snd_hda (1p:1v/0r:0v)
 pcm6: Realtek ALC892 (Front Analog Mic) on hdaa1 kld snd_hda (0p:0v/1r:1v)
 
 Because my surround sound system is found on pcm3, I have to change the
 default device to /dev/dsp3 for a 5.1 system. I successfully use these
 settings for years now:
 
 # /etc/sysctl.conf:
 hw.snd.compat_linux_mmap=1
 hw.snd.default_unit=3
 hw.snd.verbose=1
 dev.pcm.3.play.vchanformat=s16le:5.1
 dev.pcm.3.play.vchans=6
 dev.pcm.3.eq_preamp=+4
 hw.snd.latency=10
 
 # /boot/device.hints:
 # Change 'black' und 'grey'
 # green:  front  nid 20 as 1 seq 0
 # black:  rear   nid 21 as 1 seq 2
 # orange: subwoofer  nid 22 as 1 seq 1
 # grey:   sides  nid 23 as 1 seq 4
 hint.hdac.1.cad0.nid21.config=as=1 seq=4 device=Line-Out color=Grey
 hint.hdac.1.cad0.nid23.config=as=1 seq=2 device=Line-Out color=Black
 hint.hdac.1.cad0.nid27.config=as=1 seq=15 device=Headphones color=Green
 hint.pcm.3.vol=80
 hint.pcm.3.eq=1
 hint.pcm.3.vpc=1
 
 
 The four main PulseAudio configuration files at /usr/local/etc/pulse are
 changed as following:
 
 diff daemon.conf.sample daemon.conf
 79c79
  ; default-sample-channels = 2
 ---
 default-sample-channels = 6
 80a81
 default-channel-map =
 front-left,front-center,front-right,rear-right,rear-left,lfe
 82c83
  ; default-fragments = 4
 ---
 default-fragments = 8
 
 
 #diff default.pa.sample default.pa
 47c47
  #load-module module-oss device=/dev/dsp sink_name=output
 source_name=input
 ---
 load-module module-oss device=/dev/dsp3 sink_name=output
 source_name=input
 61c61
  load-module module-jackdbus-detect channels=2
 ---
 load-module module-jackdbus-detect channels=6
 
 
 #diff client.conf.sample client.conf
 22,23c22,23
  ; default-sink =
  ; default-source =
 ---
 default-sink = output
 default-source = input
 27c27
  ; autospawn = yes
 ---
 autospawn = no
 31c31
  ; cookie-file =
 ---
 cookie-file = .config/pulse/cookie
 
 
 #diff system.pa.sample system.pa
 52c52
  load-module module-suspend-on-idle
 ---
 #load-module module-suspend-on-idle
 
 
 When I try to start PulseAudio, it breaks like that:
 
 # pulseaudio --start
 W: [(null)] caps.c: Normally all extra capabilites would be dropped now,
 but that's impossible because PulseAudio was build without capabilities
 support.
 E: [(null)] main.c: Start des Daemons fehlgeschlagen.
 
 # pulseaudio
 W: [(null)] caps.c: Normally all extra capabilities would be dropped
 now, but that's impossible because PulseAudio was built without
 capabilities support.
 W: [(null)] pid.c: Stale PID file, overwriting.
 W: [(null)] module-oss.c: mmap(PROT_READ) failed, reverting to non-mmap
 mode: Invalid argument
 W: [(null)] oss-util.c: '/dev/dsp0' doesn't support full duplex
 W: [(null)] module-oss.c: mmap(PROT_WRITE) failed, reverting to non-mmap
 mode: Invalid argument
 W: [(null)] oss-util.c: '/dev/dsp1' doesn't support full duplex
 W: [(null)] module-oss.c: mmap(PROT_WRITE) failed, reverting to non-mmap
 mode: Invalid argument
 W: [(null)] oss-util.c: '/dev/dsp1' doesn't support full duplex
 W: [(null)] module-oss.c: mmap(PROT_WRITE) failed, reverting to non-mmap
 mode: Invalid argument
 W: [(null)] oss-util.c: '/dev/dsp6' doesn't support full duplex
 W: [(null)] module-oss.c: mmap(PROT_READ) failed, reverting to non-mmap
 mode: Invalid argument
 E: [oss] module-oss.c: pa_read() failed: Resource temporarily unavailable
 E: [(null)] source.c: Assertion 'source_set_state(s, PA_SOURCE_IDLE) ==
 0' failed at pulsecore/source.c:612, function void
 pa_source_put(pa_source *)(). Aborting.
 Abbruch
 
 
 A more detailed report, generated by 'pulseaudio --log-level=4 -',
 is attached as a file. In this log, there is a hint about a key problem.
 I have no idea, if this is of any importance in this context:
 
 [..snip..]
 D: [(null)] module-device-restore.c: Database contains invalid data for
 key: source:output.monitor (probably pre-v1.0 data)
 D: [(null)] module-device-restore.c: Attempting to load legacy
 (pre-v1.0) data for key: source:output.monitor
 D: [(null)] module-device-restore.c: Size does not match.
 D: [(null)] module-device-restore.c: Unable

[audio/pulseaudio] no sound after update from 0.9.23 to 5.0

[Rainer Hurling]

[..snip..]


I hope, there is some knowledge on the list to overcome these problems
with PulseAudio. As I said, before the update it works like a charm for
years on my boxes.

Any help is really appreciated. An please let me know, if I should
provide more information. Thanks in advance.

Greetings,
Rainer Hurling
#pulseaudio --log-level=4 -
W: [(null)] caps.c: Normally all extra capabilities would be dropped now, but 
that's impossible because PulseAudio was built without capabilities support.
I: [(null)] core-util.c: Failed to acquire high-priority scheduling: Operation 
not supported
I: [(null)] main.c: Dies ist PulseAudio 5.0
D: [(null)] main.c: Kompilier-Host: amd64-portbld-freebsd11.0
D: [(null)] main.c: Kompilier-CFLAGS: -O2 -pipe  -fstack-protector 
-fno-strict-aliasing -Wall -W -Wextra -Wno-long-long -Wno-overlength-strings 
-Wundef -Wformat=2 -Wsign-compare -Wformat-security -Wformat-nonliteral 
-Wold-style-definition -Wpointer-arith -Winit-self 
-Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes 
-Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn 
-Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing -Wwrite-strings 
-Wno-unused-parameter -ffast-math -fno-common -fdiagnostics-show-option
D: [(null)] main.c: Laufe auf Host: FreeBSD amd64 11.0-CURRENT FreeBSD 
11.0-CURRENT #0 r274748: Thu Nov 20 13:46:44 CET 2014 
rhur...@krabat.raven.hur:/usr/obj/usr/src/sys/RHURLIN
D: [(null)] main.c: 6 CPUs gefunden.
I: [(null)] main.c: Seitengröße ist 4096 Bytes.
D: [(null)] main.c: Kompiliere mit Valgrind-Unterstützung: nein
D: [(null)] main.c: Läuft im Valgrind-Modus: no
D: [(null)] main.c: Running in VM: no
D: [(null)] main.c: Optimiertes Build: ja
D: [(null)] main.c: FASTPATH definiert, nur fast-path-Ansprüche deaktiviert.
I: [(null)] main.c: System- ID ist krabat.raven.hur.
I: [(null)] main.c: Nutze Laufzeit-Verzeichnis 
/home/rhurlin/.pulse/krabat.raven.hur-runtime.
I: [(null)] main.c: Nutze Zustands-Verzeichnis /home/rhurlin/.pulse.
I: [(null)] main.c: Modul-Verzeichnis /usr/local/lib/pulse-5.0/modules benutzen.
I: [(null)] main.c: Laufe im System-Modus: no
W: [(null)] pid.c: Stale PID file, overwriting.
I: [(null)] main.c: Neue hochauslösende Timer verfügbar! Guten Appetit!
D: [(null)] memblock.c: Using shared memory pool with 1024 slots of size 64,0 
KB each, total size is 64,0 MB, maximum usable slot size is 65472
I: [(null)] cpu-x86.c: CPU flags: CMOV MMX SSE SSE2 SSE3 MMXEXT 3DNOW 3DNOWEXT 
I: [(null)] svolume_mmx.c: Initialising MMX optimized volume functions.
I: [(null)] remap_mmx.c: Initialising MMX optimized remappers.
I: [(null)] svolume_sse.c: Initialising SSE2 optimized volume functions.
I: [(null)] remap_sse.c: Initialising SSE2 optimized remappers.
I: [(null)] sconv_sse.c: Initialising SSE2 optimized conversions.
I: [(null)] svolume_orc.c: Initialising ORC optimized volume functions.
I: [(null)] module-device-restore.c: Successfully opened database file 
'/home/rhurlin/.pulse/krabat.raven.hur-device-volumes'.
I: [(null)] module.c: Loaded module-device-restore (index: #0; argument: ).
I: [(null)] module-stream-restore.c: Successfully opened database file 
'/home/rhurlin/.pulse/krabat.raven.hur-stream-volumes'.
D: [(null)] protocol-dbus.c: Interface org.PulseAudio.Ext.StreamRestore1 added 
for object /org/pulseaudio/stream_restore1
I: [(null)] module.c: Loaded module-stream-restore (index: #1; argument: ).
I: [(null)] module-card-restore.c: Successfully opened database file 
'/home/rhurlin/.pulse/krabat.raven.hur-card-database'.
I: [(null)] module.c: Loaded module-card-restore (index: #2; argument: ).
I: [(null)] module.c: Loaded module-augment-properties (index: #3; argument: 
).
I: [(null)] module.c: Loaded module-switch-on-port-available (index: #4; 
argument: ).
D: [(null)] oss-util.c: capabilities: DUPLEX MMAP REALTIME TRIGGER
I: [(null)] module-oss.c: Device opened in O_RDWR mode.
D: [(null)] oss-util.c: Asking for 8 fragments of size 8192 (requested 13224)
I: [(null)] module-oss.c: Input -- 8 fragments of size 8184.
I: [(null)] module-oss.c: Output -- 8 fragments of size 8184.
W: [(null)] module-oss.c: mmap(PROT_READ) failed, reverting to non-mmap mode: 
Invalid argument
D: [(null)] module-device-restore.c: Database contains invalid data for key: 
source:input (probably pre-v1.0 data)
D: [(null)] module-device-restore.c: Attempting to load legacy (pre-v1.0) data 
for key: source:input
D: [(null)] module-device-restore.c: Size does not match.
D: [(null)] module-device-restore.c: Unable to load legacy (pre-v1.0) data for 
key: source:input. Ignoring.
D: [(null)] module-device-restore.c: Database contains invalid data for key: 
source:input:null
I: [(null)] source.c: Created source 0 input with sample spec s16le 6ch 
44100Hz and channel map 
front-left,front-left-of-center,front-center,front-right,front-right-of-center,rear-center
I: [(null)] source.c: device.string = /dev/dsp3
I: [(null)] source.c: device.api = oss
I: [(null

graphics/qgis: bug 192605 obsolete after r372306

[Rainer Hurling]

After newest commits for graphics/qgis (r372306, followed by r372316,
r372341), Bugzilla 192605 [1] should be obsolete.

It would be nice, if someone with a commit bit could close it, thanks.


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192605
___
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: py-setuptools27 conflicts with itself

[Rainer Hurling]

Am 08.10.2014 um 05:35 schrieb Erich Dollansky:

Hi,

I just updated my ports tree a few minutes ago and tried to
install /usr/ports/devel/py-setuptools27

This is what I get:

===   Registering installation for py27-setuptools27-5.5.1
pkg-static: py27-setuptools27-5.5.1 conflicts with
py27-setuptools-5.5.1 (installs files into the same place).
Problematic
file: /usr/local/lib/python2.7/site-packages/easy-install.pth.dist ***
Error code 70

Stop.
make: stopped in /usr/ports/devel/py-setuptools27

How can a port conflict with itself?

Should I deinstall it? I do not want to risk this without some kind of
confirmation.

Erich


It is only almost the same. py27-setuptools27 conflicts with 
py27-setuptools (take care of the '27' after setuptools). There had been 
a slight change in the near past.


For me, it helped to change the origin and update again. Eventually it 
is also necessary to delete the old version py27-setuptools before.


portmaster -o devel/py-setuptools27 py27-setuptools-5.5.1

or something like this should do it.

Regards,
Rainer Hurling

___
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: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 01.10.2014 um 22:17 schrieb NGie Cooper:
 On Mon, Sep 29, 2014 at 11:13 PM, O. Hartmann
 ohart...@zedat.fu-berlin.de wrote:

 Hello.

 I just made the last update of the ports yesterday (I use portmaster -da 
 performing this
 task) and obviously or superficially everything went all right.

 I'm running on the boxes in question most recent CURRENT.

 On one system, a subsequent start of updating ports starts to freak out when 
 updateing
 lang/gcc: it loops over and over on some ports already updated, especially
 devel/binutils, but the port looping on isn't specific and varies.

 On every CURRENT box I tried this morning to update the ports again, I find 
 this
 frsutrating message (depends on installation, but it seems in principal the 
 same, only
 the affected ports in dependency chain varies):
 
 Are you using portmaster? If so, it might be fallout from r272282.
 Cheers,

Yup, after defining

setenv PORTSDIR /usr/ports

my problems, described on my mail in this thread from 30th September,
completely went away.

Thanks for this hint. It helps a lot!

Regards,
Rainer Hurling

___
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: pkg/ports system terribly messed up?

[Rainer Hurling]

Am 30.09.2014 um 08:13 schrieb O. Hartmann:
 
 Hello.
 
 I just made the last update of the ports yesterday (I use portmaster -da 
 performing this
 task) and obviously or superficially everything went all right.
 
 I'm running on the boxes in question most recent CURRENT.
 
 On one system, a subsequent start of updating ports starts to freak out when 
 updateing
 lang/gcc: it loops over and over on some ports already updated, especially
 devel/binutils, but the port looping on isn't specific and varies.
 
 On every CURRENT box I tried this morning to update the ports again, I find 
 this
 frsutrating message (depends on installation, but it seems in principal the 
 same, only
 the affected ports in dependency chain varies):
 
  === Gathering distinfo list for installed ports
 
 === Starting check of installed ports for available updates
 === Launching child to update openldap-sasl-client-2.4.39_2 to
 openldap-sasl-client-2.4.40
 
 === All  openldap-sasl-client-2.4.39_2 (1/1)
 
 === Currently installed version: openldap-sasl-client-2.4.39_2
 === Port directory: /usr/ports/net/openldap24-sasl-client
 
 === Launching 'make checksum' for net/openldap24-sasl-client in background
 === Gathering dependency list for net/openldap24-sasl-client from ports
 === Launching child to install 
 net/openldap24-sasl-client/../../ports-mgmt/pkg
 
 === All  openldap-sasl-client-2.4.39_2 
 net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2)
 
 === Port directory: 
 /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg
 
 
 === Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed
 === Aborting update
 
 === Update for openldap-sasl-client-2.4.39_2 failed
 === Aborting update
 
 You have new mail.
 
 
 This isn't, so far, OpenLDAP specific, on other systems without LDAP the 
 update fails on
 another port.
 
 Oliver
 

I am afraid I am observing something similar to what Oliver reported. On
a CURRENT box (r272295) I get the following for all ports execpt pkg itself:

portmaster indexinfo-0.2

=== Currently installed version: indexinfo-0.2
=== Port directory: /usr/ports/print/indexinfo

=== Gathering distinfo list for installed ports

=== Launching 'make checksum' for print/indexinfo in background
=== Gathering dependency list for print/indexinfo from ports
=== Launching child to install print/indexinfo/../../ports-mgmt/pkg

=== indexinfo-0.2  print/indexinfo/../../ports-mgmt/pkg (1/1)

=== Port directory: /usr/ports/print/indexinfo/../../ports-mgmt/pkg

=== Update for print/indexinfo/../../ports-mgmt/pkg failed
=== Aborting update


When I try to build other ports, it does not complain about
ports-mgmt/pkg, but something else in the dependency list. For example,
for net/mpich2 it complains about devel/binutils ...


This does not happen on my other CURRENT boxes (they build ports as
exected). All systems have pkg-1.3.8_2 installed. The main difference
between these boxes is, that the boxes without problems come from older
installations, which were converted via pkg2ng.

Only the box in question has all ports built and installed from scratch
after installing pkg, without any installations via pkg_* before.

As far as I can say, all went well until r369572. After svn'ing to a
more recent revision, I was not able to build ports any more ...

HTH,
Rainer Hurling

___
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

graphics/qgis: Bug 192602 patch seems ready

[Rainer Hurling]

For the Quantum GIS port (graphics/qgis) Bug 192602 [1] from 2014-08-12
is open until now.

As far as I (maintainer) can say, there is a patch ready, which should
solve the addressed problems.

Could someone please have a look at it?

Thanks in advance,
Rainer Hurling


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192605
___
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: pkg: Cannot get a read lock on a database, it is locked by another process

[Rainer Hurling]

Am 28.07.2014 23:36, schrieb Kevin Oberman:
 On Mon, Jul 28, 2014 at 8:34 AM, Kris Moore k...@pcbsd.org wrote:
 
 On 07/27/2014 10:51, Stefan Esser wrote:
 The locking of the pkg database leads to soft failures, but I'm afraid,
 if these soft failures happen to coincide with certain administrative
 tasks, they can lead to unexpected results.

 One example is that portmaster fails to detect PKGNG (and then assumes
 to be working in a pre-PKGNG environment), if some pkg subcommand locks
 the database. To repeat:

 # pkg version -Bs 
 # pkg info

 As long as pkg version runs, pkg info fails to get the read lock (at
 least in the large majority of my tests). You can also prevent any pkg
 command from running, if you STOP (kill -STOP / ^Z) pkg version. Any
 other pkg command will fail, until pkg version has been unstopped
 and run to completion. This might even be a local DoS, if any command
 that read-locks the package DB for extended time can be executed by
 an unprivileged user.

 Similar error messages are reported by pkg_libcheck, which issues
 lots of pkg commands in parallel. (I have observed some 5 lock
 failures per 1000 installed packages on my system).


 I did not try to test all combinations of simultanous pkg commands
 and did not verify, whether e.g. pkg upgrade might be stopped
 half way through because of an error accessing the pkg database,
 but I have seen SQLITE error messages that indicated failed write
 operations (INSERT/UPDATE).

 Either the timeouts are too low, or the duration during which the
 database is locked by a single operation is too large (or there is
 no fairness and some processes never get access to the database?).


 I think this should be fixed, since pkg commands that lock the
 database can be run from CRON or by other means in the background
 and the operator who issues pkg commands in the foreground (or runs
 portmaster) receives spurious error messages (which might still be
 better than the batch jobs doing silly things, after they failed to
 obtain information from the pkg database ...)

 Regards, STefan

 +1 to this whole thing.

 I would prefer that pkg commands simply wait for the DB to become
 unlocked again, instead of just failing outright.

 We have many scripts which monitor the system, check for updates,
 display our GUI store-front, and its really annoying to have random bits
 of it fail simply because of bad timing with another pkg process.

 --
 Kris Moore
 PC-BSD Software
 iXsystems
 
 
 This is a real pain, but I only see it on one of my systems. That system is
 my only i386 system and also my only system running 9.2. Whether that has
 anything to do with it, I can't say, but it makes me very nervous. I just
 would like to know why only the one system has the problem.
 --
 R. Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.com


I am running three boxes with recent HEAD. Only one of them was a new
installation, from the beginning on with pkgng (no pkg_ before). The
other two boxes were upgraded over years now, and so from old pkg_ to
new pkgng.

Locks, as described above, I only observe on the two upgraded boxes
(from older pkg_ to newer pkgng). So, for me, it looks more like a
remnant from the conversion towards the newer pkgng.

But of course, I may be completely wrong. So excuse me, if this is a
misleading contribution.

Rainer Hurling

___
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: inkscape does not build on 10 stable after ImageMagick update

[Rainer Hurling]

Am 19.06.2014 02:27 (UTC+1) schrieb Sergio de Almeida Lenzi:
 it does not links
 
 If I deinstall Inkscape  remove the dependency, it works...
 
 
 
 
   AR 2geom/lib2geom.a
   CXXLD  inkscape
   CXXLD  inkview
 libinkscape.a(imagemagick.o): In function
 `Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::readImage(char 
 const*, Magick::Image*)':
 extension/internal/bitmap/imagemagick.cpp:(.text+0x30f): undefined
 reference to `Magick::Blob::base64(std::__1::basic_stringchar,
 std::__1::char_traitschar, std::__1::allocatorchar )'
 extension/internal/bitmap/imagemagick.cpp:(.text+0x3a8): undefined
 reference to `Magick::Image::read(std::__1::basic_stringchar,
 std::__1::char_traitschar, std::__1::allocatorchar  const)'
 libinkscape.a(imagemagick.o): In function
 `Inkscape::Extension::Internal::Bitmap::ImageMagickDocCache::readImage(char 
 const*, Magick::Image*)':
 extension/internal/bitmap/imagemagick.cpp:(.text+0x30f): undefined
 reference to `Magick::Blob::base64(std::__1::basic_stringchar,
 std::__1::char_traitschar, std::__1::allocatorchar )'
 extension/internal/bitmap/imagemagick.cpp:(.text+0x3a8): undefined
 reference to `Magick::Image::read(std::__1::basic_stringchar,
 std::__1::char_traitschar, std::__1::allocatorchar  const)'
 c++: error: linker command failed with exit code 1 (use -v to see
 invocation)

This also happens for me on three slightly different boxes with HEAD.

I don't understand, what dependency has to be removed to get it work?

Regards,
Rainer Hurling
___
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: opencv2 import problem with python

[Rainer Hurling]

Am 29.06.2014 19:50 (UTC+1) schrieb Jason E. Hale:
 On Sun, Jun 29, 2014 at 4:47 AM, Zenny garbytr...@gmail.com wrote:
 Thanks John:

 I am getting the following:

 % grep ZTIN2cv15FeatureDetectorE /usr/local/lib/*
 Binary file /usr/local/lib/libopencv_contrib.so matches
 Binary file /usr/local/lib/libopencv_contrib.so.2 matches
 Binary file /usr/local/lib/libopencv_contrib.so.2.4.7 matches
 Binary file /usr/local/lib/libopencv_features2d.so matches
 Binary file /usr/local/lib/libopencv_features2d.so.2 matches
 Binary file /usr/local/lib/libopencv_features2d.so.2.4.7 matches
 Binary file /usr/local/lib/libopencv_legacy.so matches
 Binary file /usr/local/lib/libopencv_legacy.so.2 matches
 Binary file /usr/local/lib/libopencv_legacy.so.2.4.7 matches
 Binary file /usr/local/lib/libopencv_stitching.so matches
 Binary file /usr/local/lib/libopencv_stitching.so.2 matches
 Binary file /usr/local/lib/libopencv_stitching.so.2.4.7 matches

 I am CCing this mail to jhale for his attention, who is reportedly the
 maintainer accoring to the ports Makefile.

 /z




 On Sun, Jun 29, 2014 at 10:34 AM, John-Mark Gurney j...@funkthat.com wrote:

 Zenny wrote this message on Sun, Jun 29, 2014 at 10:24 +0200:
 Hi:

 I am trying to run opencv2 and installed it using the pkg binaries
 (opencv
 and py27-opencv).

 However when I try to import opencv2 module, it outputs:

 % python
 Python 2.7.6 (default, Mar  4 2014, 19:30:28)
 [GCC 4.2.1 Compatible FreeBSD Clang 3.3 (tags/RELEASE_33/final 183502)]
 on
 freebsd10
 Type help, copyright, credits or license for more information.
 import cv2
 Traceback (most recent call last):
   File stdin, line 1, in module
 ImportError: /usr/local/lib/python2.7/site-packages/cv2.so: Undefined
 symbol _ZTIN2cv15FeatureDetectorE
 

 cv2.so file does exist. Any hints to run opencv2 in FreeBSD 10.0 will be
 appreciated! Thanks!

 Sounds like one of the libraries that cv2.so depends upon wasn't linked
 w/ cv2.so...  doing a: grep ZTIN2cv15FeatureDetectorE /usr/local/lib/*
 should identify it, and you should report it to opencv2's maintainer
 to fix..

 --
   John-Mark Gurney  Voice: +1 415 225 5579

  All that I will do, has been done, All that I have, has not.


 
 I'm moving this discussion to the freebsd-ports mailing list.
 
 Could you try the attached diff?  It's interesting that this has been
 in the ports
 tree for 7 months and nobody noticed it until now.

I am one of those guys who had some trouble with disfunctional opencv
libs, but did not react. Sorry for that, I had been very busy last months.

math/saga is a GIS application, which uses OpenCV in one of its modules.
For some month now, SAGA GIS disables this module at start time of the
program.

I tried your patch for graphics/opencv, but nothing changed for me. It
seems, the opencv libs continue to be non usable.

 Note: you need to import numpy before cv2.

Does this mean, we have to rebuild and reinstall math/py-numpy before
installing graphics/opencv? Do we have to also reinstall
graphics/opencv-core?

Thanks for your work,
Rainer Hurling
___
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: opencv2 import problem with python

[Rainer Hurling]

Am 30.06.2014 11:02 (UTC+1) schrieb Jason E. Hale:
 On Mon, Jun 30, 2014 at 2:24 AM, Rainer Hurling rhur...@gwdg.de wrote:
 Am 29.06.2014 19:50 (UTC+1) schrieb Jason E. Hale:
 math/saga is a GIS application, which uses OpenCV in one of its modules.
 For some month now, SAGA GIS disables this module at start time of the
 program.

 I tried your patch for graphics/opencv, but nothing changed for me. It
 seems, the opencv libs continue to be non usable.

 The patch was for py-opencv only, so I'm not sure it would apply to
 saga.  I'll take a look at it though.

Ahh, ok. So I completely misunderstood, sorry.

Because of this thread, I had another look at my port math/saga. And it
came out, that I used LDFLAGS in a wrong context (graphics/opencv-core
instead of graphics/opencv). So my problem with SAGA GIS and OpenCV
should be solved.

I will file a PR for this. Sorry for the noise.

Regards,
Rainer Hurling

 
 Note: you need to import numpy before cv2.

 Does this mean, we have to rebuild and reinstall math/py-numpy before
 installing graphics/opencv? Do we have to also reinstall
 graphics/opencv-core?
 
 This would only apply to py-opencv, so that is the only port that
 would have to be rebuilt.  Sorry if that was unclear.  I meant that
 numpy should be imported at the python prompt before the opencv
 module.
 $python
 import numpy
 import cv2
___
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: Graphics Magick

[Rainer Hurling]

Am 18.06.2014 11:00 (UTC+1) schrieb Ajtim:
 Hi!
 
 On FreeBSD 10.0-RELEASE (amd64) I have a problem with update. The first 
 problem 
 is Graphics Magick:
 
 s.h 
 '/usr/ports/graphics/GraphicsMagick/work/stage/usr/local/include/GraphicsMagick/wand'
  Compressing man pages (compress-man)
 === Starting check for runtime dependencies
 === Gathering dependency list for graphics/GraphicsMagick from ports
 === Dependency check complete for graphics/GraphicsMagick
 
 === All  graphics/GraphicsMagick (1/15)
 
 ===  Installing for GraphicsMagick-1.3.19,1
 ===  Checking if graphics/GraphicsMagick already installed
 ===   Registering installation for GraphicsMagick-1.3.19,1 as automatic
 Installing GraphicsMagick-1.3.19,1...pkg-static: GraphicsMagick-1.3.19,1 
 conflicts with GraphicsMagick13-1.3.19_6 (installs files into the same 
 place).  
 Problematic file: /usr/local/bin/GraphicsMagick++-config
 *** Error code 70
 
 Stop.
 make[1]: stopped in /usr/ports/graphics/GraphicsMagick
 *** Error code 1
 
 Stop.
 make: stopped in /usr/ports/graphics/GraphicsMagick
 
 === Installation of GraphicsMagick-1.3.19,1 (graphics/GraphicsMagick) 
 failed
 
 Thank you.
 

For me the following helped

  pkg set -o graphics/GraphicsMagick13:graphics/GraphicsMagick

After that it should be possible to replace the old version.

(Perhaps this should be mentioned in UPDATING?)

HTH,
Rainer
___
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: [Stagedir] x11-fonts/sgifonts pending issues

[Rainer Hurling]

Am 09.06.2014 20:41, schrieb A.J. 'Fonz' van Werven:
 Attempting to stagify x11-fonts/sgifonts I'm still stuck with two issues:
 
 -1-
 
 No license is specified. There's no clue in the distfile and the WWW only
 reveals that this port is part of a collection of things that are either
 GPL or LGPL, but it doesn't specify which is which. And the authors can
 only be contacted by registering and requesting a support ticket.
 
 So, is it permissible-although-undesirable to leave LICENSE unspecified?
 Or is there another recommended solution?

One possibility could be

LICENSE=GPLv2 LGPL21
LICENSE_COMB=   dual

'dual' means OR, 'multi' means AND, see Mk/bsd.licenses.mk


 
 -2-
 
 # portmaster x11-fonts/sgifonts
 still results in pkg-message being displayed twice. So there must be
 *something* I'm doing wrong, but I can't seem to figure out what. Any
 advice?
 
 The Makefile as I have it now locally follows below and I've attached a
 patch for those who want it because I had to replace manual creation of
 pkg-message (using ${ECHO_CMD} stuff in the Makefile) with use of
 files/pkg-message.in.

Hmm, I am not sure. But did you really need SUB_FILES=pkg-message ?

Regards,
Rainer

 
 Thanks in advance,
 
 AvW
 
 [/usr/ports/x11-fonts/sgifonts/Makefile]
 # Created by: trevor
 # $FreeBSD: head/x11-fonts/sgifonts/Makefile 327781 2013-09-20 23:51:14Z bapt 
 $
 
 PORTNAME= sgifonts
 PORTVERSION=  1.0.1
 PORTREVISION= 2
 CATEGORIES=   x11-fonts
 MASTER_SITES= ftp://patches-europe.sgi.com/pub/linux/ProPack1.4/SRPMS/ \
   
 ftp://ftp.rediris.es/sites/patches-europe.sgi.com/pub/linux/ProPack1.4/SRPMS/ 
 \
   http://www.skysmurf.nl/comp/FreeBSD/distfiles/
 DISTNAME= sgi-fonts-1.0-1.src
 EXTRACT_SUFX= .rpm
 
 MAINTAINER=   free...@skysmurf.nl
 COMMENT=  Fonts from the SGI ProPack 1.4 (originally for Linux)
 
 BUILD_DEPENDS=bdftopcf:${PORTSDIR}/x11-fonts/bdftopcf \
   mkfontdir:${PORTSDIR}/x11-fonts/mkfontdir
 
 SUB_FILES=pkg-message
 SUB_LIST= FONTDIR=${FONTDIR}
 FONTDIR=  lib/X11/fonts/local/sgi
 PLIST=${WRKDIR}/pkg-plist
 PLIST_DIRS=   ${FONTDIR}
 USES= imake
 EXTRACT_CMD=  ${TAR}
 EXTRACT_BEFORE_ARGS=  -O -xf
 EXTRACT_AFTER_ARGS=   sgi-fonts.tar.gz | ${TAR} -xf -
 WRKSRC=   ${WRKDIR}/sgi-fonts
 
 post-build:
   @${RM} -f ${PLIST}
   @cd ${WRKSRC}; \
   for foo in `${LS} *gz fonts.alias fonts.dir|${SORT}`; \
   do ${ECHO_CMD} ${FONTDIR}/$${foo}  ${PLIST}; done
 
 do-install:
   ${MKDIR} ${STAGEDIR}${PREFIX}/${FONTDIR}
   ${INSTALL_DATA} ${WRKSRC}/*gz ${STAGEDIR}${PREFIX}/${FONTDIR}
   ${INSTALL_DATA} ${WRKSRC}/fonts* ${STAGEDIR}${PREFIX}/${FONTDIR}
 
 .include bsd.port.mk
 [eof]

___
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: bsd.port.mk

[Rainer Hurling]

Am 26.05.2014 14:45 (UTC+1) schrieb Baptiste Daroussin:
 On Mon, May 26, 2014 at 08:42:31AM -0400, Ajtim wrote:
 Hi!

 A few minutes ago I did run portsnap fetch update and was okay. After 
 portmaster -aD I got:

 === Gathering distinfo list for installed ports

 === Starting check of installed ports for available updates
 make: /usr/ports/Mk/bsd.port.mk line 1540: Cannot open 
 /usr/ports/Mk/Uses/bzip2.mk
 make: Fatal errors encountered -- cannot continue

 Thanks.
 
 Something went wrong on your side, /usr/ports/Mk/Uses/bzip2.mk this file 
 exists
 for a while now.

I am sorry, but I also do not have this file in all of my boxes running
HEAD with recent ports (r355321).

Greetings,
Rainer


 
 regards,
 Bapt
 
___
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: qgis, mapserver, deegree ports

[Rainer Hurling]

Am 12.05.2014 06:59 (UTC+1) schrieb Harrison Grundy:
 Hi,
 
 I'm working with OSGeo to get the various projects they work with to
 provide upstream support for FreeBSD, including maintaining ports so
 that they stay up to date. You can find a list of these projects at
 https://github.com/OSGeo/osgeo4freebsd/
 
 I was wondering if you would be interested in continuing to maintain
 these ports, or if you'd rather see their maintenance move upstream.

Hi Harrison,

there was a change with graphics/qgis, the maintainership changed from
wen@ to me (rhur...@gwdg.de). I would like to keep maintainership for
the foreseeable future.

There is another gis desktop application, I am the maintainer of:
math/saga. SAGA GIS also belongs to the OSGEO distributions and is
available for FreeBSD, see supported platforms for example at
http://live.osgeo.org/en/overview/saga_overview.html . I think, SAGA GIS
should be incorporated in your list?

Thanks for your work,
Rainer


 
 Thanks,
 --- Harrison
___
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: Subversion can't update ports tree: bug somewhere?

[Rainer Hurling]

Am 22.04.2014 15:01 (UTC+1) schrieb Thomas Mueller:
 I am unable to update ports tree using subversion, where I was consistently 
 successful until now, because of a supposedly missing file:
 
 root@amelia4:/BETA1/usr/ports # svn up .
 
 I get following error:
 
 svn: E02: Can't open file 
 '/usr/ports/x11/libxcb/files/patch-64bit-packed': No such file or directory
 
 Is there a bug on the server, or what else can I do?  Delete ports tree and 
 checkout anew?
 
 I am on 11-current amd64 here, though I got the same error running svn from 
 NetBSD-current amd64.
 
 Something must have gone awry with the ports tree, either in my svn download 
 or on the server.
 
 By the way, I just tried svn up . in /usr/doc directory, and that 
 successfully updated to revision 44625.
 
 Tom

It is unlikely, but did you try 'svn upgrade' and after it 'svn update'?

HTH,
Rainer
___
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