Re: lld amd64 build failures
On Mon, May 07, 2018 at 09:10:21PM +0200, Christian Weisgerber wrote: > net/transmission undefined symbol: libintl_gettext A fix for this is attached. It is a revision to the [update] I posted to ports@ on May 4: https://marc.info/?l=openbsd-ports&m=152539872532019&w=2 Index: Makefile === RCS file: /systems/cvs/ports/net/transmission/Makefile,v retrieving revision 1.125 diff -u -p -r1.125 Makefile --- Makefile24 Apr 2018 12:52:12 - 1.125 +++ Makefile8 May 2018 02:12:36 - @@ -4,7 +4,7 @@ COMMENT-main= BitTorrent command line an COMMENT-gtk= BitTorrent client with GTK+ interface COMMENT-qt=BitTorrent client with Qt interface -VER= 2.93 +VER= 2.94 DISTNAME= transmission-${VER} PKGNAME-main= transmission-${VER} PKGNAME-gtk= transmission-gtk-${VER} @@ -12,7 +12,6 @@ PKGNAME-qt= transmission-qt-${VER} CATEGORIES=net HOMEPAGE= https://transmissionbt.com/ MAINTAINER=Josh Grosse -REVISION= 0 # GPLv2+ PERMIT_PACKAGE_CDROM= Yes @@ -39,12 +38,12 @@ WANTLIB-main= ${WANTLIB-common} nghttp2 WANTLIB-gtk= ${WANTLIB-common} X11 Xcomposite Xcursor Xdamage \ Xext Xfixes Xi Xinerama Xrandr Xrender \ atk-1.0 atk-bridge-2.0 atspi cairo cairo-gobject \ - dbus-1 expat ffi fontconfig freetype \ + dbus-1 expat ffi fontconfig freetype fribidi \ gdk-3 gdk_pixbuf-2.0 gio-2.0 glib-2.0 gmodule-2.0 \ gobject-2.0 graphite2 gthread-2.0 gtk-3 \ harfbuzz pango-1.0 pangoft2-1.0 \ pangocairo-1.0 pixman-1 png pcre xcb \ - xcb-render xcb-shm epoxy nghttp2 iconv Xtst + xcb-render xcb-shm epoxy nghttp2 iconv WANTLIB-qt=${WANTLIB-common} ${MODQT_WANTLIB} \ GL Qt5Core Qt5DBus Qt5Gui Qt5Network Qt5Widgets \ fontconfig freetype $(COMPILER_LIBCXX) @@ -88,6 +87,7 @@ COMPILER_LANGS += c++ MODQT5_USE_CXX11= No MODQMAKE_PROJECTS= qt/qtr.pro CONFIGURE_STYLE+= qmake +LDFLAGS += -lintl SEPARATE_BUILD=No MODQMAKE_INSTALL_ROOT= ${PREFIX} .endif Index: distinfo === RCS file: /systems/cvs/ports/net/transmission/distinfo,v retrieving revision 1.51 diff -u -p -r1.51 distinfo --- distinfo30 Jan 2018 16:34:35 - 1.51 +++ distinfo1 May 2018 20:18:44 - @@ -1,2 +1,2 @@ -SHA256 (transmission-2.93.tar.xz) = iBWSDgpEmbza276JpBFQktq0LOUZn3H/mpJs/RK5uQs= -SIZE (transmission-2.93.tar.xz) = 3363868 +SHA256 (transmission-2.94.tar.xz) = NUQsyEn5H435gsPQ1HnWUMbKGTEKmU7M2qeaSvORa30= +SIZE (transmission-2.94.tar.xz) = 3365952
Re: NEW: Spyder + UPDATE: py-rope
Please wait at least a week between your ping. If no one look at it, it's sadly either no one cares about this software or no one has the time to look at it and frequent ping won't solve any of these issues. Thanks On Mon, 7 May 2018 20:33:09 -0300, "Elias M. Mariani" wrote: > Looking for someone to check and commit the change to the CVS. > Elias. > > 2018-05-04 21:00 GMT-03:00 Elias M. Mariani : > > Updated to 3.2.8 from 3.2.6. > > New spyder.tar.gz attached and also in openbsd-wip: > > https://github.com/jasperla/openbsd-wip/tree/master/devel/spyder > > > > Again, thanks Stuart for the help. > > Elias. > > > > 2018-05-04 17:13 GMT-03:00 Elias M. Mariani > > : > >> Thanks for the help Stuart, > >> > >>> - stray whitespace in Makefile ( and > >>> ) > >> Fixed. > >> > >>> - don't include a maintainer line if it's the default (i.e. > >>> ports@) > >> Fixed. > >> > >>> - would prefer to see the FLAVOR bits next to MODULES for python > >>> things so it's obvious > >> Done. > >> > >>> - RUN_DEPENDS etc should be one entry per line > >> Done. > >> > >>> - why do you @comment the appdata.xml file? > >> My mistake, replaced by ${MODPY_COMMENT}, is only for the python3 > >> flavor. > >>> - it doesn't use our standard handling for multi-version python > >>> ports with py- and py3- prefixes. I think in this case that's > >>> alright as it's more of an application than library and upstream > >>> has their own py3 renaming so it seems better to keep that, > >>> however this is a bit ugly: > >>> > >>> MAJOR_VERSION= > >>> .if ${FLAVOR:Mpython3} > >>> MAJOR_VERSION= 3 > >>> PKGNAME = > >>> spyder${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION} .endif > >>> > >>> I'd replace it with: > >>> > >>> .if ${FLAVOR:Mpython3} > >>> MAJOR_VERSION= 3 > >>> PKGNAME=spyder3-${MODPY_EGG_VERSION} > >>> .else > >>> MAJOR_VERSION= > >>> .endif > >> Changed in the Makefile, yes, it was ugly... > >> The naming convention seems to be attaching a 3 at the end of the > >> application name in this cases, even the setup.py itself makes > >> spyder or spyder3 executable for the python and python3 version. > >> > >> I'm working on openbsd-wip, but I will send here a new tar.gz > >> version when finished. >
Re: UPDATE: audio/soundtouch
On 2018/05/07 20:32, Elias M. Mariani wrote: > Looking for someone to check and commit the change to the CVS. > Elias. > > 2018-05-04 21:02 GMT-03:00 Elias M. Mariani : > > Looking for someone to check and commit the change to the CVS. > > Elias. > > > > 2018-05-02 20:17 GMT-03:00 Elias M. Mariani : > >> Hi, > >> I send a diff for soundtouch, minor change in Makefile from version > >> 1.9.2 to 2.0.0. > >> > >> Soundtouch is a dependency of: > >> audio/audacity > >> emulators/desmume > >> multimedia/gstreamer-0.10/plugins-bad,-main > >> multimedia/gstreamer1/plugins-bad > >> > >> Changes from 1.9.2 to 2.0.0: > >> https://www.surina.net/soundtouch/soundtouch-abi-tracker/compat_report/soundtouch/1.9.2/2.0.0/65640/abi_compat_report.html > >> > >> No changes on patches and PLIST. > >> Thanks. > >> Elias. > The diff is obviously wrong because it doesn't touch distinfo. Don't introduce a new VERSION variable for this, the version is only used once so it's pointless. The ABI compatibility report you linked makes it clear that a major shared library version bump is needed. You listed things that it's a dependency of, but you don't say whether you tested them.
Re: lld amd64 build failures
On Tue, May 08, 2018 at 12:09:58AM +, Ian McWilliam wrote: > > I know it won't help the resolve the issue. > > > https://reviews.llvm.org/D25324 > > > [ELF] - Check that section alignment is a power of 2. > > > > > Ian McWilliam > > Interesting, I'll try shooting this upstream and see what the developer thinks. > > From: owner-po...@openbsd.org on behalf of James > Turner > Sent: Tuesday, 8 May 2018 9:56 AM > To: Christian Weisgerber > Cc: ports@openbsd.org > Subject: Re: lld amd64 build failures > > On Mon, May 07, 2018 at 09:10:21PM +0200, Christian Weisgerber wrote: > > Over the weekend, I ran an experimental amd64 bulk build at home > > with lld as ld(1). That produced a surprising number and variety > > of failures, see the list below. I don't know if these can all be > > blamed on the respective port or if there are problems in lld as > > well. > > > > Many of "undefined symbol" errors are straightforward: The program > > refers to a symbol from some libfoo, but fails to explicitly link > > with this library. This should be fixed. I'm not sure about the > > _Unwind* ones, which refer to libc++abi. > > > > The other errors are largely mysterious to me. > > > > > > audio/audacityundefined symbol: g_signal_connect_data > > benchmarks/wrkstring table non-null terminated > > databases/pgmodeler undefined symbol: backtrace > > devel/arm-none-eabi/gcc-linarocannot preempt symbol: > > __stack_smash_handler > > devel/avr/gdb duplicate symbol: _initialize_gdbarch_utils > > devel/ffcall can't create dynamic relocation R_X86_64_64 against > > local symbol in readonly segment > > devel/xtensa-elf/gcc cannot preempt symbol: __stack_smash_handler > > editors/emacs cannot preempt symbol: memcpy > > editors/emacs21 cannot preempt symbol: __stack_smash_handler > > editors/xemacs21/stable cannot preempt symbol: __stack_smash_handler > > emulators/higan undefined symbol: _Unwind_Resume > > emulators/mednafencannot preempt symbol: __stack_smash_handler > > emulators/retroarch undefined symbol: libusb_init > > games/gargoyleundefined symbol: gtk_init > > games/nethack/3.6,qt undefined symbol: _Unwind_Resume > > games/redeclipse undefined symbol: XOpenDisplay > > games/tome4 undefined symbol: _Unwind_GetCFA > > games/uqm undefined symbol: atan2 > > games/warzone2100 undefined symbol: ogg_sync_init > > games/xteddy undefined symbol: XShapeCombineMask > > games/zaz undefined symbol: vorbis_info_init > > lang/fpc invalid alignment of section headers > > lang/gcc/4.9 configure: Link tests are not allowed after > > GCC_NO_EXECUTABLES > > lang/ghc configure: C compiler cannot create executables > > lang/myrddin section sh_addralign is not a power of 2 > > lang/nim unable to find library -lm > > lang/pypy cc: linker command failed due to signal > > misc/magicpoint configure: C compiler cannot create > > executables > > misc/rocrail undefined symbol: operator new(unsigned long) > > net/hexchat unable to find library -lc > > net/openvpn-auth-ldap configure: Could not locate a working Objective-C > > runtime > > net/telepathy/folks edbus-private not found > > net/transmission undefined symbol: libintl_gettext > > net/utox target emulation unknown > > news/pan undefined symbol: libiconv_close > > productivity/glabels edbus-private not found > > security/opensc unable to find library -lpthread > > security/xca undefined symbol: _Unwind_Resume > > sysutils/firmware/vmm ld -nopie -znorelro does not properly handle > > alignments > > sysutils/memtest86+ unknown argument: --warn-constructors > > www/lighttpd unable to find library -lc > > www/mono-xsp configure: C compiler cannot create executables > > www/mozpluggertarget emulation unknown > > x11/gnome/code-assistance configure: C compiler cannot create > > executables > > x11/gnustep/terminal undefined symbol: libiconv > > x11/rox-filer undefined symbol: floor > > > > -- > > Christian "naddy" Weisgerber na...@mips.inka.de > > > > Would love to fix the myrddin error, but have no idea what it means... > > -- > James Turner > -- James Turner
Re: lld amd64 build failures
I know it's not going to help resolve the issue https://reviews.llvm.org/D25324 [ELF] - Check that section alignment is a power of 2. Ian McWilliam From: owner-po...@openbsd.org on behalf of James Turner Sent: Tuesday, 8 May 2018 9:56 AM To: Christian Weisgerber Cc: ports@openbsd.org Subject: Re: lld amd64 build failures On Mon, May 07, 2018 at 09:10:21PM +0200, Christian Weisgerber wrote: > Over the weekend, I ran an experimental amd64 bulk build at home > with lld as ld(1). That produced a surprising number and variety > of failures, see the list below. I don't know if these can all be > blamed on the respective port or if there are problems in lld as > well. > > Many of "undefined symbol" errors are straightforward: The program > refers to a symbol from some libfoo, but fails to explicitly link > with this library. This should be fixed. I'm not sure about the > _Unwind* ones, which refer to libc++abi. > > The other errors are largely mysterious to me. > > > audio/audacityundefined symbol: g_signal_connect_data > benchmarks/wrkstring table non-null terminated > databases/pgmodeler undefined symbol: backtrace > devel/arm-none-eabi/gcc-linarocannot preempt symbol: > __stack_smash_handler > devel/avr/gdb duplicate symbol: _initialize_gdbarch_utils > devel/ffcall can't create dynamic relocation R_X86_64_64 against > local symbol in readonly segment > devel/xtensa-elf/gcc cannot preempt symbol: __stack_smash_handler > editors/emacs cannot preempt symbol: memcpy > editors/emacs21 cannot preempt symbol: __stack_smash_handler > editors/xemacs21/stable cannot preempt symbol: __stack_smash_handler > emulators/higan undefined symbol: _Unwind_Resume > emulators/mednafencannot preempt symbol: __stack_smash_handler > emulators/retroarch undefined symbol: libusb_init > games/gargoyleundefined symbol: gtk_init > games/nethack/3.6,qt undefined symbol: _Unwind_Resume > games/redeclipse undefined symbol: XOpenDisplay > games/tome4 undefined symbol: _Unwind_GetCFA > games/uqm undefined symbol: atan2 > games/warzone2100 undefined symbol: ogg_sync_init > games/xteddy undefined symbol: XShapeCombineMask > games/zaz undefined symbol: vorbis_info_init > lang/fpc invalid alignment of section headers > lang/gcc/4.9 configure: Link tests are not allowed after > GCC_NO_EXECUTABLES > lang/ghc configure: C compiler cannot create executables > lang/myrddin section sh_addralign is not a power of 2 > lang/nim unable to find library -lm > lang/pypy cc: linker command failed due to signal > misc/magicpoint configure: C compiler cannot create executables > misc/rocrail undefined symbol: operator new(unsigned long) > net/hexchat unable to find library -lc > net/openvpn-auth-ldap configure: Could not locate a working Objective-C > runtime > net/telepathy/folks edbus-private not found > net/transmission undefined symbol: libintl_gettext > net/utox target emulation unknown > news/pan undefined symbol: libiconv_close > productivity/glabels edbus-private not found > security/opensc unable to find library -lpthread > security/xca undefined symbol: _Unwind_Resume > sysutils/firmware/vmm ld -nopie -znorelro does not properly handle alignments > sysutils/memtest86+ unknown argument: --warn-constructors > www/lighttpd unable to find library -lc > www/mono-xsp configure: C compiler cannot create executables > www/mozpluggertarget emulation unknown > x11/gnome/code-assistance configure: C compiler cannot create executables > x11/gnustep/terminal undefined symbol: libiconv > x11/rox-filer undefined symbol: floor > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Would love to fix the myrddin error, but have no idea what it means... -- James Turner
Re: lld amd64 build failures
I know it won't help the resolve the issue. https://reviews.llvm.org/D25324 [ELF] - Check that section alignment is a power of 2. Ian McWilliam From: owner-po...@openbsd.org on behalf of James Turner Sent: Tuesday, 8 May 2018 9:56 AM To: Christian Weisgerber Cc: ports@openbsd.org Subject: Re: lld amd64 build failures On Mon, May 07, 2018 at 09:10:21PM +0200, Christian Weisgerber wrote: > Over the weekend, I ran an experimental amd64 bulk build at home > with lld as ld(1). That produced a surprising number and variety > of failures, see the list below. I don't know if these can all be > blamed on the respective port or if there are problems in lld as > well. > > Many of "undefined symbol" errors are straightforward: The program > refers to a symbol from some libfoo, but fails to explicitly link > with this library. This should be fixed. I'm not sure about the > _Unwind* ones, which refer to libc++abi. > > The other errors are largely mysterious to me. > > > audio/audacityundefined symbol: g_signal_connect_data > benchmarks/wrkstring table non-null terminated > databases/pgmodeler undefined symbol: backtrace > devel/arm-none-eabi/gcc-linarocannot preempt symbol: > __stack_smash_handler > devel/avr/gdb duplicate symbol: _initialize_gdbarch_utils > devel/ffcall can't create dynamic relocation R_X86_64_64 against > local symbol in readonly segment > devel/xtensa-elf/gcc cannot preempt symbol: __stack_smash_handler > editors/emacs cannot preempt symbol: memcpy > editors/emacs21 cannot preempt symbol: __stack_smash_handler > editors/xemacs21/stable cannot preempt symbol: __stack_smash_handler > emulators/higan undefined symbol: _Unwind_Resume > emulators/mednafencannot preempt symbol: __stack_smash_handler > emulators/retroarch undefined symbol: libusb_init > games/gargoyleundefined symbol: gtk_init > games/nethack/3.6,qt undefined symbol: _Unwind_Resume > games/redeclipse undefined symbol: XOpenDisplay > games/tome4 undefined symbol: _Unwind_GetCFA > games/uqm undefined symbol: atan2 > games/warzone2100 undefined symbol: ogg_sync_init > games/xteddy undefined symbol: XShapeCombineMask > games/zaz undefined symbol: vorbis_info_init > lang/fpc invalid alignment of section headers > lang/gcc/4.9 configure: Link tests are not allowed after > GCC_NO_EXECUTABLES > lang/ghc configure: C compiler cannot create executables > lang/myrddin section sh_addralign is not a power of 2 > lang/nim unable to find library -lm > lang/pypy cc: linker command failed due to signal > misc/magicpoint configure: C compiler cannot create executables > misc/rocrail undefined symbol: operator new(unsigned long) > net/hexchat unable to find library -lc > net/openvpn-auth-ldap configure: Could not locate a working Objective-C > runtime > net/telepathy/folks edbus-private not found > net/transmission undefined symbol: libintl_gettext > net/utox target emulation unknown > news/pan undefined symbol: libiconv_close > productivity/glabels edbus-private not found > security/opensc unable to find library -lpthread > security/xca undefined symbol: _Unwind_Resume > sysutils/firmware/vmm ld -nopie -znorelro does not properly handle alignments > sysutils/memtest86+ unknown argument: --warn-constructors > www/lighttpd unable to find library -lc > www/mono-xsp configure: C compiler cannot create executables > www/mozpluggertarget emulation unknown > x11/gnome/code-assistance configure: C compiler cannot create executables > x11/gnustep/terminal undefined symbol: libiconv > x11/rox-filer undefined symbol: floor > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Would love to fix the myrddin error, but have no idea what it means... -- James Turner
Re: lld amd64 build failures
On Mon, May 07, 2018 at 09:10:21PM +0200, Christian Weisgerber wrote: > Over the weekend, I ran an experimental amd64 bulk build at home > with lld as ld(1). That produced a surprising number and variety > of failures, see the list below. I don't know if these can all be > blamed on the respective port or if there are problems in lld as > well. > > Many of "undefined symbol" errors are straightforward: The program > refers to a symbol from some libfoo, but fails to explicitly link > with this library. This should be fixed. I'm not sure about the > _Unwind* ones, which refer to libc++abi. > > The other errors are largely mysterious to me. > > > audio/audacityundefined symbol: g_signal_connect_data > benchmarks/wrkstring table non-null terminated > databases/pgmodeler undefined symbol: backtrace > devel/arm-none-eabi/gcc-linarocannot preempt symbol: > __stack_smash_handler > devel/avr/gdb duplicate symbol: _initialize_gdbarch_utils > devel/ffcall can't create dynamic relocation R_X86_64_64 against > local symbol in readonly segment > devel/xtensa-elf/gcc cannot preempt symbol: __stack_smash_handler > editors/emacs cannot preempt symbol: memcpy > editors/emacs21 cannot preempt symbol: __stack_smash_handler > editors/xemacs21/stable cannot preempt symbol: __stack_smash_handler > emulators/higan undefined symbol: _Unwind_Resume > emulators/mednafencannot preempt symbol: __stack_smash_handler > emulators/retroarch undefined symbol: libusb_init > games/gargoyleundefined symbol: gtk_init > games/nethack/3.6,qt undefined symbol: _Unwind_Resume > games/redeclipse undefined symbol: XOpenDisplay > games/tome4 undefined symbol: _Unwind_GetCFA > games/uqm undefined symbol: atan2 > games/warzone2100 undefined symbol: ogg_sync_init > games/xteddy undefined symbol: XShapeCombineMask > games/zaz undefined symbol: vorbis_info_init > lang/fpc invalid alignment of section headers > lang/gcc/4.9 configure: Link tests are not allowed after > GCC_NO_EXECUTABLES > lang/ghc configure: C compiler cannot create executables > lang/myrddin section sh_addralign is not a power of 2 > lang/nim unable to find library -lm > lang/pypy cc: linker command failed due to signal > misc/magicpoint configure: C compiler cannot create executables > misc/rocrail undefined symbol: operator new(unsigned long) > net/hexchat unable to find library -lc > net/openvpn-auth-ldap configure: Could not locate a working Objective-C > runtime > net/telepathy/folks edbus-private not found > net/transmission undefined symbol: libintl_gettext > net/utox target emulation unknown > news/pan undefined symbol: libiconv_close > productivity/glabels edbus-private not found > security/opensc unable to find library -lpthread > security/xca undefined symbol: _Unwind_Resume > sysutils/firmware/vmm ld -nopie -znorelro does not properly handle alignments > sysutils/memtest86+ unknown argument: --warn-constructors > www/lighttpd unable to find library -lc > www/mono-xsp configure: C compiler cannot create executables > www/mozpluggertarget emulation unknown > x11/gnome/code-assistance configure: C compiler cannot create executables > x11/gnustep/terminal undefined symbol: libiconv > x11/rox-filer undefined symbol: floor > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Would love to fix the myrddin error, but have no idea what it means... -- James Turner
Re: NEW: Spyder + UPDATE: py-rope
Looking for someone to check and commit the change to the CVS. Elias. 2018-05-04 21:00 GMT-03:00 Elias M. Mariani : > Updated to 3.2.8 from 3.2.6. > New spyder.tar.gz attached and also in openbsd-wip: > https://github.com/jasperla/openbsd-wip/tree/master/devel/spyder > > Again, thanks Stuart for the help. > Elias. > > 2018-05-04 17:13 GMT-03:00 Elias M. Mariani : >> Thanks for the help Stuart, >> >>> - stray whitespace in Makefile ( and ) >> Fixed. >> >>> - don't include a maintainer line if it's the default (i.e. ports@) >> Fixed. >> >>> - would prefer to see the FLAVOR bits next to MODULES for python >>> things so it's obvious >> Done. >> >>> - RUN_DEPENDS etc should be one entry per line >> Done. >> >>> - why do you @comment the appdata.xml file? >> My mistake, replaced by ${MODPY_COMMENT}, is only for the python3 flavor. >>> - it doesn't use our standard handling for multi-version python ports >>> with py- and py3- prefixes. I think in this case that's alright as it's >>> more of an application than library and upstream has their own py3 >>> renaming so it seems better to keep that, however this is a bit ugly: >>> >>> MAJOR_VERSION= >>> .if ${FLAVOR:Mpython3} >>> MAJOR_VERSION= 3 >>> PKGNAME = spyder${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION} >>> .endif >>> >>> I'd replace it with: >>> >>> .if ${FLAVOR:Mpython3} >>> MAJOR_VERSION= 3 >>> PKGNAME=spyder3-${MODPY_EGG_VERSION} >>> .else >>> MAJOR_VERSION= >>> .endif >> Changed in the Makefile, yes, it was ugly... >> The naming convention seems to be attaching a 3 at the end of the >> application name in this cases, even the setup.py itself makes spyder >> or spyder3 executable for the python and python3 version. >> >> I'm working on openbsd-wip, but I will send here a new tar.gz version >> when finished.
Re: UPDATE: audio/soundtouch
Looking for someone to check and commit the change to the CVS. Elias. 2018-05-04 21:02 GMT-03:00 Elias M. Mariani : > Looking for someone to check and commit the change to the CVS. > Elias. > > 2018-05-02 20:17 GMT-03:00 Elias M. Mariani : >> Hi, >> I send a diff for soundtouch, minor change in Makefile from version >> 1.9.2 to 2.0.0. >> >> Soundtouch is a dependency of: >> audio/audacity >> emulators/desmume >> multimedia/gstreamer-0.10/plugins-bad,-main >> multimedia/gstreamer1/plugins-bad >> >> Changes from 1.9.2 to 2.0.0: >> https://www.surina.net/soundtouch/soundtouch-abi-tracker/compat_report/soundtouch/1.9.2/2.0.0/65640/abi_compat_report.html >> >> No changes on patches and PLIST. >> Thanks. >> Elias.
Re: update net/xmlrpc-c
On Mon, May 07, 2018 at 10:57:48PM +0100, David CARLIER wrote: > Hi, > > here a proposal to update xmlrpc-c to the last "stable" release in case it > might be of interest. > > Regards. > ? patches/patch-common_mk Looks like you forgot something. > Index: Makefile > === > RCS file: /cvs/ports/net/xmlrpc-c/Makefile,v > retrieving revision 1.17 > diff -u -p -r1.17 Makefile > --- Makefile 8 Dec 2017 17:25:07 - 1.17 > +++ Makefile 7 May 2018 21:46:50 - > @@ -7,22 +7,33 @@ NOT_FOR_ARCHS= m88k > COMMENT= XML-RPC C/C++ client-server implementation > CATEGORIES= net devel textproc > > -V= 1.06.35 > +V= 1.39.12 > DISTNAME=xmlrpc-c-${V} > -REVISION=3 > FIX_EXTRACT_PERMISSIONS=Yes > > EXTRACT_SUFX=.tgz > > -SHARED_LIBS += xmlrpc_util 1.0 # .9.15 > -SHARED_LIBS += xmlrpc_abyss 1.0 # .9.15 > -SHARED_LIBS += xmlrpc_xmlparse 1.0 # .9.15 > -SHARED_LIBS += xmlrpc_xmltok1.0 # .9.15 > -SHARED_LIBS += xmlrpc 1.0 # .9.15 > -SHARED_LIBS += xmlrpc_server1.0 # .9.15 > -SHARED_LIBS += xmlrpc_server_abyss 1.0 # .9.15 > -SHARED_LIBS += xmlrpc_client1.0 # .9.15 > -SHARED_LIBS += xmlrpc_server_cgi1.0 # .9.15 > +SHARED_LIBS += xmlrpc_util 3.0 # .3.39 > +SHARED_LIBS += xmlrpc_abyss3.0 # .3.39 > +SHARED_LIBS += xmlrpc_xmlparse 3.0 # .3.39 > +SHARED_LIBS += xmlrpc_xmltok 3.0 # .3.39 > +SHARED_LIBS += xmlrpc 3.0 # .3.39 This looks bogus right there. If you control the shared libs version, these should be 2.0 If you don't, you're missing patches to make it so.
update net/xmlrpc-c
Hi, here a proposal to update xmlrpc-c to the last "stable" release in case it might be of interest. Regards. ? patches/patch-common_mk Index: Makefile === RCS file: /cvs/ports/net/xmlrpc-c/Makefile,v retrieving revision 1.17 diff -u -p -r1.17 Makefile --- Makefile 8 Dec 2017 17:25:07 - 1.17 +++ Makefile 7 May 2018 21:46:50 - @@ -7,22 +7,33 @@ NOT_FOR_ARCHS= m88k COMMENT= XML-RPC C/C++ client-server implementation CATEGORIES= net devel textproc -V= 1.06.35 +V= 1.39.12 DISTNAME= xmlrpc-c-${V} -REVISION= 3 FIX_EXTRACT_PERMISSIONS=Yes EXTRACT_SUFX= .tgz -SHARED_LIBS += xmlrpc_util 1.0 # .9.15 -SHARED_LIBS += xmlrpc_abyss 1.0 # .9.15 -SHARED_LIBS += xmlrpc_xmlparse 1.0 # .9.15 -SHARED_LIBS += xmlrpc_xmltok1.0 # .9.15 -SHARED_LIBS += xmlrpc 1.0 # .9.15 -SHARED_LIBS += xmlrpc_server1.0 # .9.15 -SHARED_LIBS += xmlrpc_server_abyss 1.0 # .9.15 -SHARED_LIBS += xmlrpc_client1.0 # .9.15 -SHARED_LIBS += xmlrpc_server_cgi1.0 # .9.15 +SHARED_LIBS += xmlrpc_util 3.0 # .3.39 +SHARED_LIBS += xmlrpc_abyss 3.0 # .3.39 +SHARED_LIBS += xmlrpc_xmlparse 3.0 # .3.39 +SHARED_LIBS += xmlrpc_xmltok 3.0 # .3.39 +SHARED_LIBS += xmlrpc 3.0 # .3.39 +SHARED_LIBS += xmlrpc_server 3.0 # .3.39 +SHARED_LIBS += xmlrpc_server_abyss 3.0 # .3.39 +SHARED_LIBS += xmlrpc_client 3.0 # .3.39 +SHARED_LIBS += xmlrpc_server_cgi 3.0 # .3.39 +SHARED_LIBS += xmlrpc_util++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_abyss++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_xmlparse++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_xmltok++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_server++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_server_abyss++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_server_pstream++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_client++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_server_cgi++ 8.0 # .8.39 +SHARED_LIBS += xmlrpc_cpp 8.0 # .8.39 +SHARED_LIBS += xmlrpc_packetsocket 8.0 # .8.39 HOMEPAGE= http://xmlrpc-c.sourceforge.net/ @@ -31,7 +42,8 @@ MASTER_SITES= ${MASTER_SITE_SOURCEFORGE: # BSD PERMIT_PACKAGE_CDROM= Yes -WANTLIB= c crypto curl iconv intl nghttp2 pthread ssl z +WANTLIB= c crypto curl iconv intl nghttp2 pthread ssl z \ + ${COMPILER_LIBCXX} LIB_DEPENDS= devel/gettext \ net/curl Index: distinfo === RCS file: /cvs/ports/net/xmlrpc-c/distinfo,v retrieving revision 1.6 diff -u -p -r1.6 distinfo --- distinfo 18 Jan 2015 03:14:55 - 1.6 +++ distinfo 7 May 2018 21:46:50 - @@ -1,2 +1,2 @@ -SHA256 (xmlrpc-c-1.06.35.tgz) = b8DcmiGUD9WHlbXB+cVL+WM+Gcv0jmKmrmWcgO6fceo= -SIZE (xmlrpc-c-1.06.35.tgz) = 701970 +SHA256 (xmlrpc-c-1.39.12.tgz) = 2DDzJkqDLf4J9inMZANqz9CBIWklJtD6vgkPf/iBzgg= +SIZE (xmlrpc-c-1.39.12.tgz) = 816428 Index: patches/patch-Makefile_common === RCS file: patches/patch-Makefile_common diff -N patches/patch-Makefile_common --- patches/patch-Makefile_common 15 Mar 2008 10:35:54 - 1.2 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,28 +0,0 @@ -$OpenBSD: patch-Makefile_common,v 1.2 2008/03/15 10:35:54 ajacoutot Exp $ Makefile.common.orig Fri Jul 13 02:32:20 2007 -+++ Makefile.common Wed Jan 16 14:20:17 2008 -@@ -32,11 +32,11 @@ CFLAGS_COMMON = -DNDEBUG - CXXFLAGS_COMMON = -DNDEBUG - - ifeq ($(C_COMPILER_GNU),yes) -- CFLAGS_COMMON += $(GCC_C_WARNINGS) -fno-common -g -O3 -+ CFLAGS_COMMON += $(GCC_C_WARNINGS) -O2 -g -pthread $(COPTS) - endif - - ifeq ($(CXX_COMPILER_GNU),yes) -- CXXFLAGS_COMMON += $(GCC_CXX_WARNINGS) -g -+ CXXFLAGS_COMMON += $(GCC_CXX_WARNINGS) -O2 -g -pthread $(COPTS) - endif - - DISTDIR = $(BUILDDIR)/$(PACKAGE)-$(VERSION)/$(SUBDIR) -@@ -259,6 +259,10 @@ $(ALL_OBJS): $(BUILDDIR)/include/xmlrpc-c/config.h - - ifeq ($(SHARED_LIB_TYPE),unix) - include $(SRCDIR)/unix-common.make -+ endif -+ -+ifeq ($(SHARED_LIB_TYPE),openbsd) -+ include $(SRCDIR)/openbsd-common.make - endif - - ifeq ($(SHARED_LIB_TYPE),irix) Index: patches/patch-Makefile_config_in === RCS file: patches/patch-Makefile_config_in diff -N patches/patch-Makefile_config_in --- patches/patch-Makefile_config_in 14 Mar 2009 19:01:31 - 1.3 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,27 +0,0 @@ -$OpenBSD: patch-Makefile_config_in,v 1.3 2009/03/14 19:01:31 ajacoutot Exp $ Makefile.config.in.orig Tue Mar 25 15:24:58 2008 -+++ Makefile.config.in Sat Mar 14 19:07:03 2009 -@@ -35,8 +35,8 @@ HAVE_WCHAR_H_DEFINE = @HAVE_WCHAR_H_DEFINE@ - SHELL = @SHELL@ - CC = @CC@ - CXX = @CXX@ --CCLD = $(CC) --
lld amd64 build failures
Over the weekend, I ran an experimental amd64 bulk build at home with lld as ld(1). That produced a surprising number and variety of failures, see the list below. I don't know if these can all be blamed on the respective port or if there are problems in lld as well. Many of "undefined symbol" errors are straightforward: The program refers to a symbol from some libfoo, but fails to explicitly link with this library. This should be fixed. I'm not sure about the _Unwind* ones, which refer to libc++abi. The other errors are largely mysterious to me. audio/audacity undefined symbol: g_signal_connect_data benchmarks/wrk string table non-null terminated databases/pgmodeler undefined symbol: backtrace devel/arm-none-eabi/gcc-linaro cannot preempt symbol: __stack_smash_handler devel/avr/gdb duplicate symbol: _initialize_gdbarch_utils devel/ffcallcan't create dynamic relocation R_X86_64_64 against local symbol in readonly segment devel/xtensa-elf/gcccannot preempt symbol: __stack_smash_handler editors/emacs cannot preempt symbol: memcpy editors/emacs21 cannot preempt symbol: __stack_smash_handler editors/xemacs21/stable cannot preempt symbol: __stack_smash_handler emulators/higan undefined symbol: _Unwind_Resume emulators/mednafen cannot preempt symbol: __stack_smash_handler emulators/retroarch undefined symbol: libusb_init games/gargoyle undefined symbol: gtk_init games/nethack/3.6,qtundefined symbol: _Unwind_Resume games/redeclipseundefined symbol: XOpenDisplay games/tome4 undefined symbol: _Unwind_GetCFA games/uqm undefined symbol: atan2 games/warzone2100 undefined symbol: ogg_sync_init games/xteddyundefined symbol: XShapeCombineMask games/zaz undefined symbol: vorbis_info_init lang/fpcinvalid alignment of section headers lang/gcc/4.9configure: Link tests are not allowed after GCC_NO_EXECUTABLES lang/ghcconfigure: C compiler cannot create executables lang/myrddinsection sh_addralign is not a power of 2 lang/nimunable to find library -lm lang/pypy cc: linker command failed due to signal misc/magicpoint configure: C compiler cannot create executables misc/rocrailundefined symbol: operator new(unsigned long) net/hexchat unable to find library -lc net/openvpn-auth-ldap configure: Could not locate a working Objective-C runtime net/telepathy/folks edbus-private not found net/transmissionundefined symbol: libintl_gettext net/utoxtarget emulation unknown news/panundefined symbol: libiconv_close productivity/glabelsedbus-private not found security/opensc unable to find library -lpthread security/xcaundefined symbol: _Unwind_Resume sysutils/firmware/vmm ld -nopie -znorelro does not properly handle alignments sysutils/memtest86+ unknown argument: --warn-constructors www/lighttpdunable to find library -lc www/mono-xspconfigure: C compiler cannot create executables www/mozplugger target emulation unknown x11/gnome/code-assistance configure: C compiler cannot create executables x11/gnustep/terminalundefined symbol: libiconv x11/rox-filer undefined symbol: floor -- Christian "naddy" Weisgerber na...@mips.inka.de
llvm: add missing header for InstructionCombining.cpp
Hi, While I was porting llvmlite, I got an issue and I found this bug that was related: https://reviews.llvm.org/D44140 Attached is a diff to add missing header for InstructionCombining.cpp, in order to export LLVMInitializeInstCombine as extern "C". Ok? Cheers, Remi. Index: Makefile === RCS file: /cvs/ports/devel/llvm/Makefile,v retrieving revision 1.176 diff -u -p -u -p -r1.176 Makefile --- Makefile 7 May 2018 06:42:54 - 1.176 +++ Makefile 7 May 2018 18:59:01 - @@ -18,7 +18,7 @@ DISTNAME = llvm-${LLVM_V}.src PKGNAME = llvm-${LLVM_V} PKGNAME-main = llvm-${LLVM_V} PKGNAME-python = py-llvm-${LLVM_V} -REVISION-main = 1 +REVISION-main = 2 CATEGORIES = devel DISTFILES = llvm-${LLVM_V}.src${EXTRACT_SUFX} \ cfe-${LLVM_V}.src${EXTRACT_SUFX} \ Index: patches/patch-lib_Transforms_InstCombine_InstructionCombining_cpp === RCS file: patches/patch-lib_Transforms_InstCombine_InstructionCombining_cpp diff -N patches/patch-lib_Transforms_InstCombine_InstructionCombining_cpp --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-lib_Transforms_InstCombine_InstructionCombining_cpp 7 May 2018 18:59:01 - @@ -0,0 +1,16 @@ +$OpenBSD$ + +https://reviews.llvm.org/D44140 +https://bugs.llvm.org/show_bug.cgi?id=35947 + +Index: lib/Transforms/InstCombine/InstructionCombining.cpp +--- lib/Transforms/InstCombine/InstructionCombining.cpp.orig lib/Transforms/InstCombine/InstructionCombining.cpp +@@ -34,6 +34,7 @@ + //===--===// + + #include "InstCombineInternal.h" ++#include "llvm-c/Initialization.h" + #include "llvm/ADT/APInt.h" + #include "llvm/ADT/ArrayRef.h" + #include "llvm/ADT/DenseMap.h"
Re: NEW: games/xash3d
Ryan Freeman writes: > Hello ports@ > > Attached is a new port for the xash3d engine and accompanying mod to play > a game about hitting things with crowbars. I believe you end up playing > as my cousin Gordon. ;-) > > You can play Half-Life with this package, but you must have access to a > steam version of the game files to play. Thus, outside of having a > Windows or Linux machine handy, you can't get to the data with OpenBSD > alone. I do not believe the old retail CD versions will work with xash3d > due to so many changes since the last CD release version was put on the > shelves. > > I am unsure of what we can do with this as the licensing seems to be a bit > vague, I would love more prying eyes on that part. I kept the main engine > and the half-life client/server bits separate to try and ease this problem, > and (in theory) other Goldsrc-compatible games such as Blueshift, Opposing > Force, etc could one day have ports as well. Counter-strike will not work > at this time without someone investing a lot of time upstream. > > Outside of that it builds and runs on amd64, I can play netgames against > other xash3d players, I've put dozens of hours into the single player > campaign without issue. I think technically this should also run on arm64, > as one of the main targets of xash3d was to make the game playable on > android. > > Passes portcheck, port-lib-depends-check, lib-depends-check, and builds > okay with clang6. > > Thoughts? Comments? OKs? > > Cheers! > -ryan Game run fine (solo / multiplayer) but it seems the configuration menu lacks "check box" and sliders like in Configuration>Audio. Screenshot => https://i.zcraft.fr/8538971525709919.jpeg I will take a look deeper about the port itself.
Re: update: www/weboob 1.3
On Fri, May 04, 2018 at 02:37:50PM +0200, Sebastien Marie wrote: > On Tue, Apr 17, 2018 at 04:49:49PM +0200, Sebastien Marie wrote: > > Hi, > > Here a new diff more complete. > > From previous diff, some missing RUN_DEPENDS has been added. I also be > able to make the testsuite to run. But it fails (it fails also in CI at > upstream, so nothing new here). > > I also added python3 flavor. As it adds lot of complexity in the port, > some explanation: the core of Weboob (what the port contains) is python3 > compatible. But lot of backends (modules downloaded at runtime using > weboob-config) aren't compatible. So to let users has more possibilities, > I included the two. > Updated diff. I found that without py-qt5 (py2 dependency), the py3 build doesn't work: setup.py searchs for 'pyuic5' binary, whereas it is 'pyuic5-3'. I added explicity path in MAKE_ENV to force using 'pyuic5${MODPY_BIN_SUFFIX}'. Thanks. -- Sebastien Marie Index: Makefile === RCS file: /cvs/ports/www/weboob/Makefile,v retrieving revision 1.6 diff -u -p -r1.6 Makefile --- Makefile29 Sep 2015 10:53:17 - 1.6 +++ Makefile7 May 2018 14:25:41 - @@ -2,9 +2,8 @@ COMMENT = web out of browsers -MODPY_EGG_VERSION =1.0 +MODPY_EGG_VERSION =1.3 DISTNAME = weboob-${MODPY_EGG_VERSION} -REVISION = 3 CATEGORIES = www HOMEPAGE = http://weboob.org @@ -12,35 +11,95 @@ HOMEPAGE = http://weboob.org # AGPLv3+ PERMIT_PACKAGE_CDROM = Yes -MASTER_SITES = https://symlink.me/attachments/download/289/ +MASTER_SITES = https://symlink.me/attachments/download/356/ MODULES = lang/python +FLAVORS = python3 +FLAVOR ?= + USE_GMAKE =Yes MODPY_SETUPTOOLS = Yes MODPY_DISTUTILS_BUILDARGS = --qt --xdg -BUILD_DEPENDS += x11/py-qt4 -RUN_DEPENDS = devel/desktop-file-utils \ +BUILD_DEPENDS += x11/py-qt5${MODPY_FLAVOR} +RUN_DEPENDS += devel/desktop-file-utils \ x11/gtk+3,-guic \ - www/py-mako \ - www/py-clientform \ - www/py-mechanize \ - www/py-requests \ - www/py-routes \ - www/py-webob \ - devel/py-dateutil \ - devel/py-gdata \ - devel/py-html5lib \ - devel/py-simplejson \ - converters/py-html2text \ - graphics/py-Pillow \ - x11/py-qt4 \ - textproc/py-prettytable \ - textproc/py-feedparser \ - textproc/py-lxml \ - textproc/py-cssselect \ - textproc/py-yaml + converters/py-html2text${MODPY_FLAVOR} \ + devel/py-dateutil${MODPY_FLAVOR} \ + devel/py-html5lib${MODPY_FLAVOR} \ + devel/py-simplejson${MODPY_FLAVOR} \ + devel/py-six${MODPY_FLAVOR} \ + graphics/py-Pillow${MODPY_FLAVOR} \ + net/curl \ + security/gnupg \ + textproc/py-lxml${MODPY_FLAVOR} \ + textproc/py-feedparser${MODPY_FLAVOR} \ + textproc/py-prettytable${MODPY_FLAVOR} \ + textproc/py-yaml${MODPY_FLAVOR} \ + textproc/py-cssselect${MODPY_FLAVOR} \ + www/py-requests${MODPY_FLAVOR} \ + x11/py-qt5${MODPY_FLAVOR} + +TEST_DEPENDS +=${RUN_DEPENDS} \ + devel/py-coverage${MODPY_FLAVOR} \ + devel/py-nose${MODPY_FLAVOR} \ + shells/bash + +.if ${FLAVOR:Mpython3} +PKGNAME = weboob${MODPY_MAJOR_VERSION}-${MODPY_EGG_VERSION} +.else +RUN_DEPENDS += devel/py-futures \ + www/py-mechanize +.endif + +MAKE_ENV +=PYUIC5_EXECUTABLE=${LOCALBASE}/bin/pyuic5${MODPY_BIN_SUFFIX} + +WEBOOB_BINARIES = boobank boobathon boobcoming boobill booblyrics boobmsg \ + boobooks boobsize boobtracker cineoob comparoob cookboob \ + flatboob galleroob geolooc handjoob havedate monboob \ + parceloob pastoob qbooblyrics qboobmsg qcineoob qcookboob \ + qflatboob qhandjoob qhavedate qvideoob qwebcontentedit \ + radioob shopoob suboob translaboob traveloob videoob \ + webcontentedit weboob weboob-cli weboob-config \ + weboob-config-qt weboob-debug weboob-repos weboorrents \ + wetboobs + +post-install: + rm -f ${PREFIX}/man/man1/masstransit.1 \ + ${PREFIX}/share/applications/qgalleroob.desktop \ + ${PREFIX}/share/applications/masstransit.desktop \ + ${PREFIX}/share/icons/hicolor/64x64/apps/allomatch.png \ + ${PREFIX}/share/icons/hicolor/64x64/apps/banquepopulaire.png \ + ${PREFIX}/share/icons/hicolor/64x64/apps/google.png \ + ${PREFIX}/share/icons/hicolor/64x64/apps/chatoob.png \ + ${PREFIX}/share/icons/hicolor/64x64/apps/masstra
Re: net/tor: enable SEPARATE_BUILD
On Mon, 07 May 2018 13:51:38 +0200, Jeremie Courreges-Anglas wrote: > On Sun, May 06 2018, Klemens Nanni wrote: > > Simple diff for out-of-tree builds: > > > > $ du -sh `make show='WRKSRC WRKBUILD'` > > 27.8M /tmp/pobj/tor-0.3.2.10/tor-0.3.2.10 > > 94.4M /tmp/pobj/tor-0.3.2.10/build-amd64 > > > > Without the symlink, it would rebuild manuals using rst2man. > > > > OK? > > I'm not sure I like introducing workarounds for something like > SEPARATE_BUILD=Yes. I'd rather fix the problem in tor (or at least > report it) so that out-of-tree builds work out of the box in an upcoming > version. > > Anyway, Pascal has the final word here, no strong objection on my side. Seconded. I don't think SEPARATE_BUILD=Yes is high priority enough to warrant extra hoop-jumping. > > Index: Makefile > > === > > RCS file: /cvs/ports/net/tor/Makefile,v > > retrieving revision 1.112 > > diff -u -p -r1.112 Makefile > > --- Makefile25 Apr 2018 12:54:15 - 1.112 > > +++ Makefile6 May 2018 10:01:17 - > > @@ -17,6 +17,7 @@ WANTLIB += c crypto event_core event_ext > > MASTER_SITES= https://www.torproject.org/dist/ > > > > AUTOCONF_VERSION=2.69 > > +SEPARATE_BUILD=Yes > > CONFIGURE_STYLE=autoconf > > # PIE is already taken care of on a per-arch basis, and we have stack > > protection > > # anyway on FRAME_GROWS_DOWN archs. > > @@ -32,5 +33,8 @@ DB_DIR= /var/tor > > SUBST_VARS+= DB_DIR > > > > FAKE_FLAGS=sysconfdir=${PREFIX}/share/examples > > + > > +pre-build: > > + ln -sf ${WRKSRC}/doc ${WRKBUILD}/ > > > > .include > > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: net/tor: enable SEPARATE_BUILD
On Sun, May 06 2018, Klemens Nanni wrote: > Simple diff for out-of-tree builds: > > $ du -sh `make show='WRKSRC WRKBUILD'` > 27.8M /tmp/pobj/tor-0.3.2.10/tor-0.3.2.10 > 94.4M /tmp/pobj/tor-0.3.2.10/build-amd64 > > Without the symlink, it would rebuild manuals using rst2man. > > OK? I'm not sure I like introducing workarounds for something like SEPARATE_BUILD=Yes. I'd rather fix the problem in tor (or at least report it) so that out-of-tree builds work out of the box in an upcoming version. Anyway, Pascal has the final word here, no strong objection on my side. > Index: Makefile > === > RCS file: /cvs/ports/net/tor/Makefile,v > retrieving revision 1.112 > diff -u -p -r1.112 Makefile > --- Makefile 25 Apr 2018 12:54:15 - 1.112 > +++ Makefile 6 May 2018 10:01:17 - > @@ -17,6 +17,7 @@ WANTLIB += c crypto event_core event_ext > MASTER_SITES=https://www.torproject.org/dist/ > > AUTOCONF_VERSION=2.69 > +SEPARATE_BUILD= Yes > CONFIGURE_STYLE=autoconf > # PIE is already taken care of on a per-arch basis, and we have stack > protection > # anyway on FRAME_GROWS_DOWN archs. > @@ -32,5 +33,8 @@ DB_DIR= /var/tor > SUBST_VARS+= DB_DIR > > FAKE_FLAGS= sysconfdir=${PREFIX}/share/examples > + > +pre-build: > + ln -sf ${WRKSRC}/doc ${WRKBUILD}/ > > .include > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: [NEW] devel/py-yapf
Works for me on amd64, no issues Cheers, On Mon, May 7, 2018 at 9:29 AM, Remi Pointel wrote: > Hi, > > attached is the port of yapf: a formatter Python code. > > -- > $ pkg_info py-yapf > Information for inst:py-yapf-0.21.0 > > Comment: > formatter for Python code > > Description: > YAPF is a formatter based off of 'clang-format'. In essence, the algorithm > takes > the code and reformats it to the best formatting that conforms to the style > guide, even if the original code didn't violate the style guide. If the > whole > codebase of a project is simply piped through YAPF whenever modifications > are > made, the style remains consistent throughout the project and there's no > point > arguing about style in every code review. > > Maintainer: The OpenBSD ports mailing-list > > WWW: https://pypi.python.org/pypi/yapf > -- > > Ok? > > Cheers, > > Remi. > -- If you wish to live wisely, ignore sayings -- including this one.
Re: UPDATE: math/ginac 1.7.4
On Fri, May 04, 2018 at 10:29:07PM +0100, Stuart Henderson wrote: > On 2018/05/04 17:59, Theo Buehler wrote: > > On Fri, May 04, 2018 at 06:52:40PM +0300, Paul Irofti wrote: > > > On Fri, May 04, 2018 at 12:13:35PM +0200, Theo Buehler wrote: > > > > On Sat, Apr 28, 2018 at 01:42:52PM +0300, Paul Irofti wrote: > > > > > Hi, > > > > > > > > > > Here is a minor update to GiNaC. All tests pass. OK? > > > > > > > > > > > > > Builds and packages fine, confirm that all tests pass. Portcheck is > > > > happy. > > > > > > > > There is one thing: > > > > > > > > 'make lib-depends-check' complains as follows: > > > > > > > > Missing: curses.14 (/usr/local/bin/ginsh) (system lib) > > > > Extra: ncurses.14 > > > > WANTLIB += curses > > > > Scanning: ok > > > > > > > > I think that should be fixed. > > This is because base started using soname, so the library name as shown > in objdump -p changed. As far as ports/updates go it's basically a noop > but yes please do fix. > > > > Like this? > > > > I think so, but I'd rather have an experienced porter confirm this. > > LIBCXX is wrong for ports-gcc arches, it should be like this: > > ${COMPILER_LIBCXX} c cln curses gmp m readline Thank you, I commited the fix.
Re: UPDATE: net/wget-1.9.5
The file it's in is a new test. Given the security fix I'd go ahead and commit but please report it upstream. -- Sent from a phone, apologies for poor formatting. On 7 May 2018 04:36:09 Björn Ketelaars wrote: On Sun 06/05/2018 23:01, Gleydson Soares wrote: update to wget-1.9.5. This update addresses a vunerability CVE-2018-0494, along with several bug fixes. builds and runs fine, @amd64 OK? I'm unable to run 'make test', log is enclosed. On 1.9.4 'make test' runs fine.
[NEW] devel/py-yapf
Hi, attached is the port of yapf: a formatter Python code. -- $ pkg_info py-yapf Information for inst:py-yapf-0.21.0 Comment: formatter for Python code Description: YAPF is a formatter based off of 'clang-format'. In essence, the algorithm takes the code and reformats it to the best formatting that conforms to the style guide, even if the original code didn't violate the style guide. If the whole codebase of a project is simply piped through YAPF whenever modifications are made, the style remains consistent throughout the project and there's no point arguing about style in every code review. Maintainer: The OpenBSD ports mailing-list WWW: https://pypi.python.org/pypi/yapf -- Ok? Cheers, Remi. py-yapf-0.21.0.tar.gz Description: GNU Zip compressed data