Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sun, Jun 02, 2019 at 06:34:22AM +0200, zeurk...@volny.cz wrote: > "Thomas Frohwein" wrote: > > > > For the record, I'm against dynamic core and against disabling the > > splash. I'm indifferent regarding ne2000. > > Since the latter seems to be the least controversial, perhaps meshould > trim the patch down to that first...? jsg@, you're maintainer, please > speak up :) You gave no justification for wanting us to carry a third party patch for the ne2k support instead of using existing ipx and modem emulation.
Re: [maintainer update] gzdoom-4.1.2
ping, anyone had time to test this?
timo
timo.my...@bittivirhe.fi (Timo Myyrä) writes:
> timo.my...@bittivirhe.fi (Timo Myyrä) writes:
>
>> Hi,
>>
>> Gzdoom seems to have few releases since last ports update.
>> Is anyone interested in having legacy release of 3.8.0 which requires OpenGL
>> 2.0+ or would it be best to use the current 4.2.1 version requiring OpenGL
>> 3.3+?
>>
>> I'm leaning towards the latter, there are other doom ports for older hw so
>> I'd
>> say we could switch to using the modern branch.
>>
>> Here's update to 4.1.2 for review. Quickly tested on amd64 but I'm using the
>> amdgpu which isn't stable yet so this could use some further testing with
>> other hw.
>>
>> Timo
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/games/gzdoom/Makefile,v
>> retrieving revision 1.5
>> diff -u -p -u -p -r1.5 Makefile
>> --- Makefile 2 Apr 2019 13:56:40 - 1.5
>> +++ Makefile 25 May 2019 08:43:16 -
>> @@ -6,7 +6,7 @@ ONLY_FOR_ARCHS = i386 amd64
>>
>> COMMENT = OpenGL engine for idTech 1 games like
>> doom,hexen,heretic...
>>
>> -V = 3.7.2
>> +V = 4.1.2
>> PKGNAME = gzdoom-${V}
>> DISTNAME = gzdoom-src-g${V}
>>
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/games/gzdoom/distinfo,v
>> retrieving revision 1.2
>> diff -u -p -u -p -r1.2 distinfo
>> --- distinfo 27 Feb 2019 23:35:17 - 1.2
>> +++ distinfo 25 May 2019 08:43:16 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (gzdoom-src-g3.7.2.zip) =
>> BzdegCYKsjPC6VMhy4iWfaRvd2+DS+7tYKChCkxwAgU=
>> -SIZE (gzdoom-src-g3.7.2.zip) = 12189731
>> +SHA256 (gzdoom-src-g4.1.2.zip) =
>> PlpypHGf8jEBwTGL+dSlZ0rWgj9s4GfDC/J/nuS1uPY=
>> +SIZE (gzdoom-src-g4.1.2.zip) = 15297100
>> Index: patches/patch-src_CMakeLists_txt
>> ===
>> RCS file: /cvs/ports/games/gzdoom/patches/patch-src_CMakeLists_txt,v
>> retrieving revision 1.1.1.1
>> diff -u -p -u -p -r1.1.1.1 patch-src_CMakeLists_txt
>> --- patches/patch-src_CMakeLists_txt 6 Feb 2019 09:32:21 - 1.1.1.1
>> +++ patches/patch-src_CMakeLists_txt 25 May 2019 08:43:16 -
>> @@ -14,8 +14,8 @@ Index: src/CMakeLists.txt
>> if( WIN32 )
>> if( X64 )
>> set( WIN_TYPE Win64 )
>> -@@ -1301,7 +1305,13 @@ if(${CMAKE_SYSTEM_NAME} STREQUAL "SunOS")
>> -set( ZDOOM_LIBS ${ZDOOM_LIBS} nsl socket)
>> +@@ -1369,7 +1373,13 @@ if( UNIX )
>> +endif()
>> endif()
>>
>> +find_package( Backtrace )
>> Index: patches/patch-src_scripting_vm_vmframe_cpp
>> ===
>> RCS file:
>> /cvs/ports/games/gzdoom/patches/patch-src_scripting_vm_vmframe_cpp,v
>> retrieving revision 1.1
>> diff -u -p -u -p -r1.1 patch-src_scripting_vm_vmframe_cpp
>> --- patches/patch-src_scripting_vm_vmframe_cpp 12 Feb 2019 18:07:11
>> - 1.1
>> +++ patches/patch-src_scripting_vm_vmframe_cpp 25 May 2019 08:43:16
>> -
>> @@ -1,14 +1,14 @@
>> -$OpenBSD: patch-src_scripting_vm_vmframe_cpp,v 1.1 2019/02/12 18:07:11
>> solene Exp $
>> +$OpenBSD$
>>
>> disable JIT so it's W^X compatible
>>
>> Index: src/scripting/vm/vmframe.cpp
>> --- src/scripting/vm/vmframe.cpp.orig
>> +++ src/scripting/vm/vmframe.cpp
>> -@@ -49,7 +49,7 @@
>> - #endif
>> +@@ -45,7 +45,7 @@
>> + #include "version.h"
>>
>> - #ifdef ARCH_X64
>> + #ifdef HAVE_VM_JIT
>> -CUSTOM_CVAR(Bool, vm_jit, true, CVAR_NOINITCALL)
>> +CUSTOM_CVAR(Bool, vm_jit, false, CVAR_NOINITCALL)
>> {
>> Index: patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
>> ===
>> RCS file:
>> /cvs/ports/games/gzdoom/patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp,v
>> retrieving revision 1.1.1.1
>> diff -u -p -u -p -r1.1.1.1
>> patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
>> --- patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
>> 6 Feb 2019 09:32:21 - 1.1.1.1
>> +++ patches/patch-src_sound_mididevices_music_fluidsynth_mididevice_cpp
>> 25 May 2019 08:43:16 -
>> @@ -3,7 +3,7 @@ $OpenBSD: patch-src_sound_mididevices_mu
>> Index: src/sound/mididevices/music_fluidsynth_mididevice.cpp
>> --- src/sound/mididevices/music_fluidsynth_mididevice.cpp.orig
>> +++ src/sound/mididevices/music_fluidsynth_mididevice.cpp
>> -@@ -49,12 +49,11 @@
>> +@@ -50,12 +50,11 @@
>> // do this without including windows.h for this one single prototype
>> extern "C" unsigned __stdcall GetSystemDirectoryA(char *lpBuffer, unsigned
>> uSize);
>>
>> @@ -17,7 +17,7 @@ Index: src/sound/mididevices/music_fluid
>> #endif
>> #else
>> #include
>> -@@ -64,6 +63,15 @@ extern "C" unsigned __stdcall GetSystemDirectoryA(char
>> +@@ -65,6 +64,15 @@ extern "C" unsigned __stdcall
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
theo wrote: > >> The ideal future state would be removing W|X from those remaining >> ports. > > That is seriously idealistic. > > The upstream software teams must decide to do that. > > After that, the "port" has no work to do. > > It is generally impossible for a "port" to solve this problem. > It's like adding pledge, unveil, or privsep to a piece of > software upstream-maintained by a group who doesn't understand > the concept or benefit yet... Would you mind if for a change, mejust shamelessly agrees w/ you this time? =) Ideals are good. They are not always workable. That's why they're ideals. --zeurkous. -- Friggin' Machines!
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Thomas Frohwein" wrote: > > For the record, I'm against dynamic core and against disabling the > splash. I'm indifferent regarding ne2000. Since the latter seems to be the least controversial, perhaps meshould trim the patch down to that first...? jsg@, you're maintainer, please speak up :) > The ideal future state would be removing W|X from those remaining > ports. In the ideal future ports wouldn't be needed and all third-party software would fit in perfectly with base ;) But yeah. > Therefore, the burden of proof should lie with anyone wanting > to go in the opposite direction. You want dynamic core? Convince us > that the benefit is worth going _against_ our security mitigations. You > should seriously consider showing numbers or comparison videos to make > your case. Uhm, as me's said, me's not *forcing* anyone to run the dyncore... me's not even proposing it as a default. Just an option. If this were in base, mewouldn't bother proposing it, but hey, this is ports, it's full of junk that people need despite it being so. > Even then I'm likely not going to think it's worth it. There is a fork > of dosbox called dosbox-x [1] that has seen continuous improvement and > regular releases over the recent years. Mehasn't been monitoring dosbox development much, due to the lack of Code quality and indeed plain English quality... mewas thus unaware of the fork and will investigate, thanks for bringing it me attention. > The project is complex and a > little messy, which is why I haven't sent it to ports@ yet. I had an > SDL1-based version that worked very well about a year ago. There was a > noticeable performance advantage in the game Tie Fighter over then > dosbox 0.74, with the normal core. That to me was good enough to lose > any interest in the dynamic core. It even runs Windows 98 acceptably, > but 3D acceleration isn't fully there in Win98. Medoesn't know that game, but meexperience is that some games really do try to be too clever with optimizations, turning them into pessimizations within an emulator of any kind. The dynamic core somewhat (sometimes greatly) alleviates that. > The port has since seen a few updates. I just built the most recent one > with SDL2, but there are several bugs that I'd like to address before > it's ready. > > I would recommend to check out dosbox-x and how it performs with its > normal core before looking into dynamic core and the associated > reduction in mitigations. IME running dosbox in general is not so much putting the door ajar as it is removing it from its frame entirely and junking it. >>> A better way to spend time on dosbox would be to investigate ways to >>> improve speed without sacrificing basic security protections. > > dosbox-x may offer this; however I haven't tried most recent dosbox > 0.74-2 yet. I should soon have a version to share for testing. Well, if this "dosbox-x" does the job, we of course don't need the dyncore. Just don't make it drag in gtk+? and python (or similar horrors), please... > I think upstream made it clear enough that the splash should remain > part of the application. Imagine the mess if we started adding patches > to ports for anything that someone might consider "convenient". It brings the functionality of the port closer to base, doesn't it? Honestly, I don't find "you're allowed to modify everything *except* that bit", when "that bit" gets in the way, much acceptable. Someone /could/ go and ask the developers what their intentions were, and if they're fine w/ removal for completely non-commercial reasons. It won't be me since they barely ever responded to me about anything in the first place. (But others seem to have this problem as well.) --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
Thomas Frohwein wrote: > The ideal future state would be removing W|X from those remaining > ports. That is seriously idealistic. The upstream software teams must decide to do that. After that, the "port" has no work to do. It is generally impossible for a "port" to solve this problem. It's like adding pledge, unveil, or privsep to a piece of software upstream-maintained by a group who doesn't understand the concept or benefit yet...
security/burpsuite MODJAVA_VER
Burp Suite Community Edition needs jdk 1.8 to run properly. Using it
with jdk 11 will show this message on startup:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by burp.uie
(file:/usr/local/share/java/classes/burpsuite.jar) to field
javax.crypto.JceSecurity.isRestricted
WARNING: Please consider reporting this to the maintainers of burp.uie
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
Your JRE appears to be version 11.0.3 from Oracle Corporation
Burp has not been fully tested on this platform and you may experience problems.
In addition, attempting to intercept HTTPS will make the browser show an
error code SSL_ERROR_RX_RECORD_TOO_LONG (I tested with Firefox).
According to [1], this is due to using the free edition of Burp Suite
with jdk 11.
The diff below fixes this by setting MODJAVA_VER to 1.8 which resolves
both issues. While here I have also:
* Used sthen@'s XXX message about checking if future updates will work
with jdk 11
* Changed the HOMEPAGE to https
* Switched to the new PERMIT_* markers
ok?
1.
https://support.portswigger.net/customer/portal/questions/17434431-gettin-error-code-ssl-error-rx-record-too-long
Index: Makefile
===
RCS file: /cvs/ports/security/burpsuite/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile24 Mar 2019 22:24:14 - 1.26
+++ Makefile2 Jun 2019 03:04:52 -
@@ -5,16 +5,16 @@ COMMENT = tool for testing security of
VERSION = 1.7.36
DISTNAME = burpsuite_free_v${VERSION}
PKGNAME = burpsuite-${VERSION}
+REVISION = 0
DISTFILES=${DISTNAME}${EXTRACT_SUFX}{Download?productId=100\=${VERSION}\=Jar}
CATEGORIES = security
-HOMEPAGE = http://portswigger.net/burp/
+HOMEPAGE = https://portswigger.net/burp/
-PERMIT_PACKAGE_CDROM= https://portswigger.net/burp/eula-free.html
-PERMIT_PACKAGE_FTP= https://portswigger.net/burp/eula-free.html
-PERMIT_DISTFILES_FTP= https://portswigger.net/burp/eula-free.html
+PERMIT_PACKAGE = https://portswigger.net/burp/eula-free.html
+PERMIT_DISTFILES = https://portswigger.net/burp/eula-free.html
MASTER_SITES = https://portswigger.net/Burp/Releases/
@@ -22,7 +22,8 @@ EXTRACT_ONLY =
EXTRACT_SUFX = .jar
MODULES = java
-MODJAVA_VER = 1.8+
+# XXX if updating, please check if it works with jdk 11 and switch to "1.8+"
if ok
+MODJAVA_VER = 1.8
MODJAVA_JRERUN = yes
RUN_DEPENDS = java/javaPathHelper
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: l...@cvs.openbsd.org2019/06/01 20:07:44 Modified files: net/snort : Makefile distinfo net/snort/patches: patch-src_dynamic-plugins_sf_engine_Makefile_in patch-src_dynamic-preprocessors_Makefile_in patch-src_dynamic-preprocessors_appid_Makefile_in patch-src_dynamic-preprocessors_dcerpc2_Makefile_in patch-src_dynamic-preprocessors_dnp3_Makefile_in patch-src_dynamic-preprocessors_dns_Makefile_in patch-src_dynamic-preprocessors_ftptelnet_Makefile_in patch-src_dynamic-preprocessors_gtp_Makefile_in patch-src_dynamic-preprocessors_imap_Makefile_in patch-src_dynamic-preprocessors_modbus_Makefile_in patch-src_dynamic-preprocessors_pop_Makefile_in patch-src_dynamic-preprocessors_reputation_Makefile_in patch-src_dynamic-preprocessors_sdf_Makefile_in patch-src_dynamic-preprocessors_sip_Makefile_in patch-src_dynamic-preprocessors_smtp_Makefile_in patch-src_dynamic-preprocessors_ssh_Makefile_in patch-src_dynamic-preprocessors_ssl_Makefile_in patch-src_preprocessors_Stream6_snort_stream_tcp_c patch-src_preprocessors_spp_sfportscan_c patch-src_util_c patch-src_util_h Log message: Update to Snort 2.9.13 from maintainer Markus Lude, with a note in patch-src_dynamic-plugins_sf_engine_Makefile_in to indicate that libsf_sorules is disabled.
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01, 2019 at 05:53:27PM +0200, zeurk...@volny.cz wrote: [...] > Me data is 'it helps me, and me's willing to accept the risk when > necessary'. Obviously, only the big, bloated, poorly-programmed stuff > (such as the Build engine) really benefits :) > > And please do note that the dynamic core is a run-time *option*: > core=normal *still* works even with this patch applied. For the record, I'm against dynamic core and against disabling the splash. I'm indifferent regarding ne2000. The ideal future state would be removing W|X from those remaining ports. Therefore, the burden of proof should lie with anyone wanting to go in the opposite direction. You want dynamic core? Convince us that the benefit is worth going _against_ our security mitigations. You should seriously consider showing numbers or comparison videos to make your case. Even then I'm likely not going to think it's worth it. There is a fork of dosbox called dosbox-x [1] that has seen continuous improvement and regular releases over the recent years. The project is complex and a little messy, which is why I haven't sent it to ports@ yet. I had an SDL1-based version that worked very well about a year ago. There was a noticeable performance advantage in the game Tie Fighter over then dosbox 0.74, with the normal core. That to me was good enough to lose any interest in the dynamic core. It even runs Windows 98 acceptably, but 3D acceleration isn't fully there in Win98. The port has since seen a few updates. I just built the most recent one with SDL2, but there are several bugs that I'd like to address before it's ready. I would recommend to check out dosbox-x and how it performs with its normal core before looking into dynamic core and the associated reduction in mitigations. [...] > > A better way to spend time on dosbox would be to investigate ways to > > improve speed without sacrificing basic security protections. dosbox-x may offer this; however I haven't tried most recent dosbox 0.74-2 yet. I should soon have a version to share for testing. [...] > Me's not removing any copyright notices at all :s Just a funky splash > screen that just *happens* to get in me way. I think upstream made it clear enough that the splash should remain part of the application. Imagine the mess if we started adding patches to ports for anything that someone might consider "convenient". [...] [1] https://github.com/joncampbell123/dosbox-x/releases
Re: 回复: [New]www/p5-WWW-Form-UrlEncoded
Hi, On Thu, 30 May 2019 10:14:48 -0700 Andrew Hewus Fresh wrote: > On Thu, May 30, 2019 at 12:04:35AM +, wen heping wrote: > > Hi, > > > >This is the revised patch which reviewed by cwen@. > >Comments ? > For p5-WWW-Form-UrlEncoded i've let the old fix as-is. I could have put instead the proposal i did to upstream [0], but i am not sure it will be merged. I've added the XS module as a RUN_DEPENDS. > This looks mostly OK, but the port for the XS module seemed pretty > easy to make, so I'd like to see a RUN_DEPENDS on this so that Plack > is hopefully slightly faster. > > Attached is mostly just a portgen(1) version of it. - portgen(1) was not able to find the 'c' WANTLIB :| - i reworded DESCR - it builds on macppc I'm attaching an all-in-one tarball. OK cwen@ on these 2 ports if you're fine with them and willing to commit them. Charlène. [0] https://github.com/kazeburo/WWW-Form-UrlEncoded/pull/8 > > l8rZ, > -- > andrew - http://afresh1.com > > Full-time system administration is a delicate balance > between proactiveness and laziness. > -- jhorwitz from use.perl.org p5-WWW-Form-UrlEncoded-ALL.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 17:22:41 Modified files: net/bro: Makefile distinfo Log message: SECURITY update to bro-2.6.2. - CVE-2019-12175
Re: py-unicorn: enable Python 3 flavor
On 6/1/2019 7:12 PM, Klemens Nanni wrote: On Sat, Jun 01, 2019 at 06:38:13PM -0400, Brad Smith wrote: QEMU's configure script depends on >=2.7 and has supported 3 for awhile. 2 support has been deprecated for awhile and will be dropped in 4.1 from the looks of it. That is upstream, but yeah. py-unicorn ships parts of QEMU and hasn't seen new releases for a while so we're talking old QEMU here. Ohh. When I first saw what you said I thought there wasn't something right about what you said. Now I know why.
Re: py-unicorn: enable Python 3 flavor
On Sat, Jun 01, 2019 at 06:38:13PM -0400, Brad Smith wrote: > QEMU's configure script depends on >=2.7 and has supported 3 for awhile. 2 > support > has been deprecated for awhile and will be dropped in 4.1 from the looks of > it. That is upstream, but yeah. py-unicorn ships parts of QEMU and hasn't seen new releases for a while so we're talking old QEMU here.
Re: py-unicorn: enable Python 3 flavor
On 6/1/2019 7:38 AM, Klemens Nanni wrote: The reason unicorn is Python 2 only is QEMU's configure script depending on Python >=2.4,<3. QEMU's configure script depends on >=2.7 and has supported 3 for awhile. 2 support has been deprecated for awhile and will be dropped in 4.1 from the looks of it.
Re: enable Theora in ffmpeg (again)
On Sat, Jun 01, 2019 at 10:40:08AM -0700, Thomas Frohwein wrote:
> Hi,
>
> I have a use case for Theora encoding with ffmpeg and would like to
> bring this back to the port.
>
> A brief history:
>
> * ffmpeg's Theora support was removed in 2015, arguing that VP8/VP9 are
> replacements. [1]
> * ffmpeg2theora was removed in January 2019 because of breakage with
> ffmpeg 4.x; claiming that "ffmpeg does the job nowadays" which in all
> my trying has not been the case, with ffmpeg compiled without Theora
> support. [2]
Well, ffmpeg does the job when it has the theora codec enabled :P
>
> While this may be true for decoding, encoding Theora is now impossible
> with the ffmpeg family. The FNA framework only uses Theora for video
> playback because of the very compact implementation in
> multimedia/libtheorafile:
>
> $ du -hs /usr/local/lib/lib{theorafile,vpx}.so*
> 28.0K /usr/local/lib/libtheorafile.so.1.0
> 2.1M/usr/local/lib/libvpx.so.12.0
>
> libvpx only contains support for VP8/9, but not VP3 (Theora).
>
> I'm not sure what exactly the reasoning was for removing Theora support,
> in the absence of a full replacement of this still-used codec. Below is
> a diff to consider that would add a theora FLAVOR to ffmpeg. There is
> no relevant difference in package size, so I'm not sure if this should
> really be branched off into a flavor if it is considered:
>
> 23.2M ffmpeg-4.1.3p2v0-theora.tgz
> 23.2M ffmpeg-4.1.3p2v0.tgz
>
> So, my question is if this diff could be considered, or clarification
> if not.
>
> [1] https://marc.info/?l=openbsd-ports-cvs=143020279411648=2
> [2] https://marc.info/?l=openbsd-ports-cvs=154834827813518=2
Can you remove the flavor and just enable the codec?
--
Juan Francisco Cantero Hurtado http://juanfra.info
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: fcam...@cvs.openbsd.org 2019/06/01 14:54:12 Modified files: fonts/spleen : Makefile distinfo Log message: Update spleen to 1.0.5.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/06/01 14:00:01 Modified files: devel : Makefile devel/py-unicorn: Makefile devel/py-unicorn/patches: patch-src_Makefile devel/py-unicorn/pkg: PLIST Log message: Enable py-unicorn,python3 QEMU's configure script cannot cope with modern Python, but unicorn does. Pass python2 to QEMU in both cases, otherwise unicorn behaves like any other flavored python port. "go ahead" jasper
Re: [UPDATE] devel/openmpi 4.0.1
That needs fixing then..
--
Sent from a phone, apologies for poor formatting.
On 1 June 2019 17:15:19 Jeremie Courreges-Anglas wrote:
On Sat, Jun 01 2019, Stuart Henderson wrote:
Please don't do the huge bump for SHARED_LIBS, just a standard major
bump for the existing libraries and start the new ones at 0.0
IIRC the problem is that SHARED_LIBS isn't respected.
--
Sent from a phone, apologies for poor formatting.
On 31 May 2019 18:55:23 Martin Reindl wrote:
Hello ports@,
here is an update for another port that probably get's not much widespread
usage. Nevertheless, this is worthwhile for people running in an MPI-3.1
environment. Tested on macppc, arm64 and amd64. I only needed this once, so
I am not too keen on taking MAINTAINER. Note all fortran bits pass make test
with the new egfortran from ports-gcc on the aforementioned archs.
-m
Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile 21 Jan 2019 14:24:30 - 1.26
+++ Makefile 30 May 2019 17:19:34 -
@@ -1,52 +1,46 @@
# $OpenBSD: Makefile,v 1.26 2019/01/21 14:24:30 jca Exp $
-BROKEN-hppa = error: Could not determine global symbol label prefix
-BROKEN-powerpc = checking if Fortran 77 compiler works... no
+COMMENT = open source MPI-3.1 implementation
-COMMENT = open source MPI-2 implementation
-
-V= 1.4.1
+V= 4.0.1
DISTNAME = openmpi-$V
-REVISION = 8
-
-SHARED_LIBS = mca_common_sm 1.0 \
- mpi 0.1 \
- mpi_cxx 0.0 \
- mpi_f77 0.0 \
- open-pal 0.0 \
- open-rte 0.0
CATEGORIES = devel
+MASTER_SITES =
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
+
HOMEPAGE = http://www.open-mpi.org/
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+SHARED_LIBS += mca_common_dstore 1.0 \
+ mca_common_monitoring 60.0 \
+ mca_common_ompio 60.1 \
+ mca_common_sm 60.0 \
+ mpi 60.1 \
+ mpi_cxx 60.0 \
+ mpi_mpifh 60.1 \
+ mpi_usempi_ignore_tkr 60.0 \
+ mpi_usempif08 60.0 \
+ ompitrace 60.0 \
+ open-pal 60.1 \
+ open-rte 60.1
+
MODULES = fortran
-MODFORTRAN_COMPILER = g77
+MODFORTRAN_COMPILER = gfortran
BUILD_DEPENDS += ${MODFORTRAN_BUILD_DEPENDS}
-# BSD
-PERMIT_PACKAGE_CDROM = Yes
+LIB_DEPENDS += devel/libexecinfo
WANTLIB += c m pthread ${COMPILER_LIBCXX} util z
+WANTLIB += pciaccess execinfo
COMPILER = base-clang ports-gcc base-gcc
-MASTER_SITES =
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
-
-# XXX: uses a locally modified libtool.
-USE_LIBTOOL = No
-
-FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
CONFIGURE_STYLE = gnu
-CONFIGURE_ENV = F77=${MODFORTRAN_COMPILER}
+CONFIGURE_ARGS += --enable-mpi-cxx
-.include
-.if ${PROPERTIES:Mclang}
-CONFIGURE_ARGS = --disable-visibility
-.endif
-
-# openmpi's otfinfo conflicts with the one from texlive
-post-install:
- mv ${PREFIX}/bin/otfinfo ${PREFIX}/bin/otfinfompi
+FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
.include
Index: distinfo
===
RCS file: /cvs/ports/devel/openmpi/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo 18 Jan 2015 03:13:19 - 1.3
+++ distinfo 30 May 2019 17:19:34 -
@@ -1,2 +1,2 @@
-SHA256 (openmpi-1.4.1.tar.gz) = quq9IhjNxPEejgPhVTkQEpzIQw6TN2xANsqW/BoVubU=
-SIZE (openmpi-1.4.1.tar.gz) = 9960381
+SHA256 (openmpi-4.0.1.tar.gz) = 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
+SIZE (openmpi-4.0.1.tar.gz) = 17513706
Index: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
===
RCS file: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
diff -N patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
--- patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc 11 Apr
2018 22:49:40 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,145 +0,0 @@
-$OpenBSD: patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc,v 1.1
2018/04/11 22:49:40 sthen Exp $
-
-Index: ompi/contrib/vt/vt/tools/compwrap/compwrap.cc
ompi/contrib/vt/vt/tools/compwrap/compwrap.cc.orig
-+++ ompi/contrib/vt/vt/tools/compwrap/compwrap.cc
-@@ -99,7 +99,7 @@ ReadDataFile()
- "compiler_iflags_ftrace", "inst_avail", "inst_default"
-};
-
-- std::string data_file = DATADIR"/" + ExeName + "-wrapper-data.txt";
-+ std::string data_file = DATADIR "/" + ExeName + "-wrapper-data.txt";
-std::ifstream in( data_file.c_str() );
-if( !in )
-{
-@@ -646,11 +646,11 @@ ParseCommandLine( int argc, char ** argv )
- //
- // -vt:
- //
-- else if( arg.compare("-vt:"WRAP_LANG_SUFFIX) == 0 )
-+ else if( arg.compare("-vt:" WRAP_LANG_SUFFIX) == 0 )
- {
- if( i == argc - 1 )
- {
--std::cerr << ExeName << ": expected -- -vt:"WRAP_LANG_SUFFIX
-+std::cerr <<
Re: [update] www/p5-WWW-Search-Ebay 3.042 -> 3.052
Hi,
On Wed, 29 May 2019 19:30:52 -0700
Andrew Hewus Fresh wrote:
> On Tue, May 21, 2019 at 08:12:30AM +0200, Charlene Wendling wrote:
> >
[...]
>
> This one needs:
> RUN_DEPENDS+= www/p5-LWP-Protocol-https
Yes, it makes sense indeed.
> and a comment that tests need the network to run, similar to
> p5-WWW-Tumbler.
>
> It still doesn't quite seem to work right when I use:
> AutoSearch --engine Ebay -n BSD -s bsd bsd
>
> it does work though, check out:
> https://www.ebay.com/itm/COMDEX-1999-special-1-4M-preview-release-of-the-NetBSD-operating-system-CD-ROM/333212907390?hash=item4d9509777e:g:GQcAAOSwX1xc2Wjm
>
> But lots of warnings for:
> Use of uninitialized value in numeric lt (<)
> at /usr/local/libdata/perl5/site_pe rl/WWW/Search/Ebay.pm line 672.
>
> This patch seems to fix it, but I don't know if it's the right fix or
> if there's some other extenuating reason that the end_date is
> sometimes undefined. I do see a few wide characters in the output so
> I wonder if it's just not very unicode safe and stuff is going wrong
> due to that.
>
>
[...]
I'm sending an updated diff that deals with these issues. There seems
to be a problem in the HTML parsing code. I thought i found out why, but
it appears that's not it. Debug logs seem interesting for upstream though,
so i'll report there - meanwhile your fix and that update are better than
what we have currently :)
Charlène.
> --
> andrew - http://afresh1.com
>
> Hey, I think I see a barn up ahead.
> -- The American Astronaut
>
Index: Makefile
===
RCS file: /cvs/ports/www/p5-WWW-Search-Ebay/Makefile,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 Makefile
--- Makefile6 Aug 2017 20:12:57 - 1.14
+++ Makefile1 Jun 2019 18:06:48 -
@@ -2,22 +2,28 @@
COMMENT= backend for searching www.ebay.com
-DISTNAME = WWW-Search-Ebay-3.042
-REVISION = 1
+DISTNAME= WWW-Search-Ebay-3.052
CATEGORIES=www
-# perl
+# Perl
PERMIT_PACKAGE_CDROM= Yes
MODULES= cpan
PKG_ARCH= *
-BUILD_DEPENDS =devel/p5-Module-Install-AuthorTests
-RUN_DEPENDS= www/p5-WWW-Search
+BUILD_DEPENDS= devel/p5-Module-Install-AuthorTests
+
+RUN_DEPENDS= converters/p5-DateManip \
+ www/p5-HTML-Tree \
+ www/p5-LWP-Protocol-https \
+ www/p5-WWW-Search>=2.517 \
+ www/p5-libwww
+
+# Tests need network access
TEST_DEPENDS= devel/p5-IO-Capture
MAKE_ENV+= TEST_POD="Yes"
-CONFIGURE_STYLE = modinst
+CONFIGURE_STYLE= modinst
.include
Index: distinfo
===
RCS file: /cvs/ports/www/p5-WWW-Search-Ebay/distinfo,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 distinfo
--- distinfo19 Sep 2015 10:05:48 - 1.6
+++ distinfo1 Jun 2019 18:06:48 -
@@ -1,2 +1,2 @@
-SHA256 (WWW-Search-Ebay-3.042.tar.gz) =
IJnzUNMmnbHXrgb8Tbxbjb5QJ0wlu7dzCnFSYVPER5U=
-SIZE (WWW-Search-Ebay-3.042.tar.gz) = 54585
+SHA256 (WWW-Search-Ebay-3.052.tar.gz) =
osgshTeJPvhLfwLOQoGN+TW4F7cL0EBrgoE6iA6R0Gg=
+SIZE (WWW-Search-Ebay-3.052.tar.gz) = 54632
Index: patches/patch-lib_WWW_Search_Ebay_pm
===
RCS file: patches/patch-lib_WWW_Search_Ebay_pm
diff -N patches/patch-lib_WWW_Search_Ebay_pm
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-lib_WWW_Search_Ebay_pm1 Jun 2019 18:06:48 -
@@ -0,0 +1,27 @@
+$OpenBSD$
+
+Fix for:
+Use of uninitialized value in numeric lt (<) at
+/usr/local/libdata/perl5/site_perl/WWW/Search/Ebay.pm line 672.
+
+Index: lib/WWW/Search/Ebay.pm
+--- lib/WWW/Search/Ebay.pm.orig
lib/WWW/Search/Ebay.pm
+@@ -669,7 +669,7 @@ sub result_as_HTML
+ my $dateNow = ParseDate('now');
+ print STDERR " DDD compare end_date ==$dateEnd==\n" if (DEBUG_DATES || (1 <
$self->{_debug}));
+ print STDERR " DDD compare date_now ==$dateNow==\n" if (DEBUG_DATES || (1 <
$self->{_debug}));
+- if (Date_Cmp($dateEnd, $dateNow) < 0)
++ if ((Date_Cmp($dateEnd, $dateNow) || 0) < 0)
+ {
+ $sEndedColor = 'red';
+ $sEndedWord = 'ended';
+@@ -1040,7 +1040,7 @@ sub _parse_tree
+ &&
+ (0 < $iBids) # Item got any bids
+ &&
+-(Date_Cmp($enddate, 'now') < 0) # Item is ended
++((Date_Cmp($enddate, 'now') || 0) < 0) # Item is ended
+)
+ {
+ # Item must have been sold!?!
Re: enable Theora in ffmpeg (again)
Oh please, don't provide a flavor. Just provide a full featured ffmpeg,
let it be a normal port.
Theora support was removed in this port just because of maintainer's
personal opinion.
On Sat, Jun 01, 2019 at 10:40:08AM -0700, Thomas Frohwein wrote:
> Hi,
>
> I have a use case for Theora encoding with ffmpeg and would like to
> bring this back to the port.
>
> A brief history:
>
> * ffmpeg's Theora support was removed in 2015, arguing that VP8/VP9 are
> replacements. [1]
> * ffmpeg2theora was removed in January 2019 because of breakage with
> ffmpeg 4.x; claiming that "ffmpeg does the job nowadays" which in all
> my trying has not been the case, with ffmpeg compiled without Theora
> support. [2]
>
> While this may be true for decoding, encoding Theora is now impossible
> with the ffmpeg family. The FNA framework only uses Theora for video
> playback because of the very compact implementation in
> multimedia/libtheorafile:
>
> $ du -hs /usr/local/lib/lib{theorafile,vpx}.so*
> 28.0K /usr/local/lib/libtheorafile.so.1.0
> 2.1M/usr/local/lib/libvpx.so.12.0
>
> libvpx only contains support for VP8/9, but not VP3 (Theora).
>
> I'm not sure what exactly the reasoning was for removing Theora support,
> in the absence of a full replacement of this still-used codec. Below is
> a diff to consider that would add a theora FLAVOR to ffmpeg. There is
> no relevant difference in package size, so I'm not sure if this should
> really be branched off into a flavor if it is considered:
>
> 23.2M ffmpeg-4.1.3p2v0-theora.tgz
> 23.2M ffmpeg-4.1.3p2v0.tgz
>
> So, my question is if this diff could be considered, or clarification
> if not.
>
> [1] https://marc.info/?l=openbsd-ports-cvs=143020279411648=2
> [2] https://marc.info/?l=openbsd-ports-cvs=154834827813518=2
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
> retrieving revision 1.184
> diff -u -p -r1.184 Makefile
> --- Makefile 23 May 2019 08:51:21 - 1.184
> +++ Makefile 1 Jun 2019 17:37:44 -
> @@ -4,7 +4,7 @@ COMMENT= audio/video converter and strea
>
> V= 4.1.3
> DISTNAME=ffmpeg-${V}
> -REVISION=1
> +REVISION=2
> CATEGORIES= graphics multimedia
> MASTER_SITES=https://ffmpeg.org/releases/
> EXTRACT_SUFX=.tar.xz
> @@ -162,8 +162,10 @@ VERSION_FLAGS= libavcodec_VERSION=${LIBa
> libswresample_VERSION=${LIBswresample_VERSION} \
> libswscale_VERSION=${LIBswscale_VERSION}
>
> +AVCODEC_FLAGS= -lswresample -lavutil ${LIBavcodec_EXTRALIBS}
> +
> MAKE_FLAGS= ${VERSION_FLAGS} \
> - LIBavcodec_EXTRALIBS="-lswresample -lavutil
> ${LIBavcodec_EXTRALIBS}" \
> + LIBavcodec_EXTRALIBS="${AVCODEC_FLAGS}" \
> LIBavdevice_EXTRALIBS="-lavfilter -lswscale -lpostproc
> -lavformat -lavcodec -lswresample -lavresample -lavutil
> ${LIBavdevice_EXTRALIBS}" \
> LIBavfilter_EXTRALIBS="-lswscale -lpostproc -lavformat
> -lavcodec -lswresample -lavresample -lavutil ${LIBavfilter_EXTRALIBS}" \
> LIBavformat_EXTRALIBS="-lavcodec -lswresample -lavutil
> ${LIBavformat_EXTRALIBS}" \
> @@ -174,6 +176,16 @@ MAKE_FLAGS= ${VERSION_FLAGS} \
> LIBswscale_EXTRALIBS="-lavutil ${LIBswscale_EXTRALIBS}"
> FAKE_FLAGS= ${VERSION_FLAGS} \
> LDCONFIG=true
> +
> +FLAVORS =theora
> +FLAVOR ?=
> +
> +.if ${FLAVOR:Mtheora}
> +LIB_DEPENDS += multimedia/libtheora
> +CONFIGURE_ARGS+= --enable-libtheora
> +AVCODEC_FLAGS += -ltheora
> +WANTLIB += theora
> +.endif
>
> .ifdef DEBUG
> CONFIGURE_ARGS+=--disable-stripping
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/06/01 12:03:30 Modified files: www/chromium : Makefile distinfo www/chromium/patches: patch-chrome_browser_about_flags_cc patch-chrome_browser_flag_descriptions_cc patch-chrome_browser_flag_descriptions_h patch-chrome_common_webui_url_constants_cc patch-chrome_common_webui_url_constants_h patch-chrome_test_BUILD_gn patch-content_browser_BUILD_gn patch-ui_message_center_views_message_popup_view_cc Added files: www/chromium/patches: patch-tools_gn_build_gen_py patch-tools_gn_tools_gn_args_cc Log message: update to 75.0.3770.66
Re: [update] games/barony: fix backport
On Fri, May 31, 2019 at 05:20:24AM +0100, David CARLIER wrote: > ping :) > > On Tue, 14 May 2019 at 20:01, David CARLIER wrote: > > > > Hi, > > > > thfr reported an issue a bit before 6.5 release and as the barony > > release takes longer than expected here is the fix backported. > > > > Cheers. > Hi What kind of bug is this fixing? I can play barony on 6.5, I did not play long but it was running fine.
enable Theora in ffmpeg (again)
Hi,
I have a use case for Theora encoding with ffmpeg and would like to
bring this back to the port.
A brief history:
* ffmpeg's Theora support was removed in 2015, arguing that VP8/VP9 are
replacements. [1]
* ffmpeg2theora was removed in January 2019 because of breakage with
ffmpeg 4.x; claiming that "ffmpeg does the job nowadays" which in all
my trying has not been the case, with ffmpeg compiled without Theora
support. [2]
While this may be true for decoding, encoding Theora is now impossible
with the ffmpeg family. The FNA framework only uses Theora for video
playback because of the very compact implementation in
multimedia/libtheorafile:
$ du -hs /usr/local/lib/lib{theorafile,vpx}.so*
28.0K /usr/local/lib/libtheorafile.so.1.0
2.1M/usr/local/lib/libvpx.so.12.0
libvpx only contains support for VP8/9, but not VP3 (Theora).
I'm not sure what exactly the reasoning was for removing Theora support,
in the absence of a full replacement of this still-used codec. Below is
a diff to consider that would add a theora FLAVOR to ffmpeg. There is
no relevant difference in package size, so I'm not sure if this should
really be branched off into a flavor if it is considered:
23.2M ffmpeg-4.1.3p2v0-theora.tgz
23.2M ffmpeg-4.1.3p2v0.tgz
So, my question is if this diff could be considered, or clarification
if not.
[1] https://marc.info/?l=openbsd-ports-cvs=143020279411648=2
[2] https://marc.info/?l=openbsd-ports-cvs=154834827813518=2
Index: Makefile
===
RCS file: /cvs/ports/graphics/ffmpeg/Makefile,v
retrieving revision 1.184
diff -u -p -r1.184 Makefile
--- Makefile23 May 2019 08:51:21 - 1.184
+++ Makefile1 Jun 2019 17:37:44 -
@@ -4,7 +4,7 @@ COMMENT=audio/video converter and strea
V= 4.1.3
DISTNAME= ffmpeg-${V}
-REVISION= 1
+REVISION= 2
CATEGORIES=graphics multimedia
MASTER_SITES= https://ffmpeg.org/releases/
EXTRACT_SUFX= .tar.xz
@@ -162,8 +162,10 @@ VERSION_FLAGS= libavcodec_VERSION=${LIBa
libswresample_VERSION=${LIBswresample_VERSION} \
libswscale_VERSION=${LIBswscale_VERSION}
+AVCODEC_FLAGS= -lswresample -lavutil ${LIBavcodec_EXTRALIBS}
+
MAKE_FLAGS=${VERSION_FLAGS} \
- LIBavcodec_EXTRALIBS="-lswresample -lavutil
${LIBavcodec_EXTRALIBS}" \
+ LIBavcodec_EXTRALIBS="${AVCODEC_FLAGS}" \
LIBavdevice_EXTRALIBS="-lavfilter -lswscale -lpostproc
-lavformat -lavcodec -lswresample -lavresample -lavutil
${LIBavdevice_EXTRALIBS}" \
LIBavfilter_EXTRALIBS="-lswscale -lpostproc -lavformat
-lavcodec -lswresample -lavresample -lavutil ${LIBavfilter_EXTRALIBS}" \
LIBavformat_EXTRALIBS="-lavcodec -lswresample -lavutil
${LIBavformat_EXTRALIBS}" \
@@ -174,6 +176,16 @@ MAKE_FLAGS=${VERSION_FLAGS} \
LIBswscale_EXTRALIBS="-lavutil ${LIBswscale_EXTRALIBS}"
FAKE_FLAGS=${VERSION_FLAGS} \
LDCONFIG=true
+
+FLAVORS = theora
+FLAVOR ?=
+
+.if ${FLAVOR:Mtheora}
+LIB_DEPENDS += multimedia/libtheora
+CONFIGURE_ARGS+= --enable-libtheora
+AVCODEC_FLAGS += -ltheora
+WANTLIB += theora
+.endif
.ifdef DEBUG
CONFIGURE_ARGS+=--disable-stripping
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 10:41:36 Modified files: sysutils/google-cloud-sdk: Makefile distinfo sysutils/google-cloud-sdk/pkg: PLIST Log message: Update to google-cloud-sdk-248.0.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 10:32:27 Modified files: sysutils/awscli: Makefile distinfo sysutils/awscli/pkg: PLIST Log message: Update to awscli-1.16.169.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 10:32:13 Modified files: net/py-botocore: Makefile distinfo net/py-botocore/pkg: PLIST Log message: Update to py-botocore-1.12.159.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 10:32:00 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py-boto3-1.9.159.
Re: [UPDATE] devel/openmpi 4.0.1
On Sat, Jun 01 2019, Stuart Henderson wrote:
> Please don't do the huge bump for SHARED_LIBS, just a standard major
> bump for the existing libraries and start the new ones at 0.0
IIRC the problem is that SHARED_LIBS isn't respected.
> --
> Sent from a phone, apologies for poor formatting.
>
> On 31 May 2019 18:55:23 Martin Reindl wrote:
>
>> Hello ports@,
>>
>>
>> here is an update for another port that probably get's not much widespread
>> usage. Nevertheless, this is worthwhile for people running in an MPI-3.1
>> environment. Tested on macppc, arm64 and amd64. I only needed this once, so
>> I am not too keen on taking MAINTAINER. Note all fortran bits pass make test
>> with the new egfortran from ports-gcc on the aforementioned archs.
>>
>>
>> -m
>>
>>
>>
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/ports/devel/openmpi/Makefile,v
>> retrieving revision 1.26
>> diff -u -p -u -p -r1.26 Makefile
>> --- Makefile 21 Jan 2019 14:24:30 - 1.26
>> +++ Makefile 30 May 2019 17:19:34 -
>> @@ -1,52 +1,46 @@
>> # $OpenBSD: Makefile,v 1.26 2019/01/21 14:24:30 jca Exp $
>>
>> -BROKEN-hppa = error: Could not determine global symbol label prefix
>> -BROKEN-powerpc = checking if Fortran 77 compiler works... no
>> +COMMENT = open source MPI-3.1 implementation
>>
>> -COMMENT = open source MPI-2 implementation
>> -
>> -V= 1.4.1
>> +V= 4.0.1
>> DISTNAME = openmpi-$V
>> -REVISION = 8
>> -
>> -SHARED_LIBS = mca_common_sm 1.0 \
>> - mpi 0.1 \
>> - mpi_cxx 0.0 \
>> - mpi_f77 0.0 \
>> - open-pal 0.0 \
>> - open-rte 0.0
>>
>> CATEGORIES = devel
>>
>> +MASTER_SITES =
>> ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
>> +
>> HOMEPAGE = http://www.open-mpi.org/
>>
>> +# BSD
>> +PERMIT_PACKAGE_CDROM = Yes
>> +
>> +SHARED_LIBS += mca_common_dstore 1.0 \
>> + mca_common_monitoring 60.0 \
>> + mca_common_ompio 60.1 \
>> + mca_common_sm 60.0 \
>> + mpi 60.1 \
>> + mpi_cxx 60.0 \
>> + mpi_mpifh 60.1 \
>> + mpi_usempi_ignore_tkr 60.0 \
>> + mpi_usempif08 60.0 \
>> + ompitrace 60.0 \
>> + open-pal 60.1 \
>> + open-rte 60.1
>> +
>> MODULES = fortran
>> -MODFORTRAN_COMPILER = g77
>> +MODFORTRAN_COMPILER = gfortran
>> BUILD_DEPENDS += ${MODFORTRAN_BUILD_DEPENDS}
>>
>> -# BSD
>> -PERMIT_PACKAGE_CDROM = Yes
>> +LIB_DEPENDS += devel/libexecinfo
>>
>> WANTLIB += c m pthread ${COMPILER_LIBCXX} util z
>> +WANTLIB += pciaccess execinfo
>>
>> COMPILER = base-clang ports-gcc base-gcc
>>
>> -MASTER_SITES =
>> ${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
>> -
>> -# XXX: uses a locally modified libtool.
>> -USE_LIBTOOL = No
>> -
>> -FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
>> CONFIGURE_STYLE = gnu
>> -CONFIGURE_ENV = F77=${MODFORTRAN_COMPILER}
>> +CONFIGURE_ARGS += --enable-mpi-cxx
>>
>> -.include
>> -.if ${PROPERTIES:Mclang}
>> -CONFIGURE_ARGS = --disable-visibility
>> -.endif
>> -
>> -# openmpi's otfinfo conflicts with the one from texlive
>> -post-install:
>> - mv ${PREFIX}/bin/otfinfo ${PREFIX}/bin/otfinfompi
>> +FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
>>
>> .include
>> Index: distinfo
>> ===
>> RCS file: /cvs/ports/devel/openmpi/distinfo,v
>> retrieving revision 1.3
>> diff -u -p -u -p -r1.3 distinfo
>> --- distinfo 18 Jan 2015 03:13:19 - 1.3
>> +++ distinfo 30 May 2019 17:19:34 -
>> @@ -1,2 +1,2 @@
>> -SHA256 (openmpi-1.4.1.tar.gz) = quq9IhjNxPEejgPhVTkQEpzIQw6TN2xANsqW/BoVubU=
>> -SIZE (openmpi-1.4.1.tar.gz) = 9960381
>> +SHA256 (openmpi-4.0.1.tar.gz) = 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
>> +SIZE (openmpi-4.0.1.tar.gz) = 17513706
>> Index: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
>> ===
>> RCS file: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
>> diff -N patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
>> --- patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc 11 Apr
>> 2018 22:49:40 - 1.1
>> +++ /dev/null 1 Jan 1970 00:00:00 -
>> @@ -1,145 +0,0 @@
>> -$OpenBSD: patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc,v 1.1
>> 2018/04/11 22:49:40 sthen Exp $
>> -
>> -Index: ompi/contrib/vt/vt/tools/compwrap/compwrap.cc
>> ompi/contrib/vt/vt/tools/compwrap/compwrap.cc.orig
>> -+++ ompi/contrib/vt/vt/tools/compwrap/compwrap.cc
>> -@@ -99,7 +99,7 @@ ReadDataFile()
>> - "compiler_iflags_ftrace", "inst_avail", "inst_default"
>> -};
>> -
>> -- std::string data_file = DATADIR"/" + ExeName + "-wrapper-data.txt";
>> -+ std::string data_file = DATADIR "/" + ExeName + "-wrapper-data.txt";
>> -std::ifstream in( data_file.c_str() );
>> -if( !in )
>> -{
>> -@@ -646,11 +646,11 @@ ParseCommandLine( int argc, char ** argv )
>> - //
>> -
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
[blah, volny flagged your message as spam...] "Jeremie Courreges-Anglas" wrote: > >[about the dynamic core...] > >> It's a risk and people are free to take it or not to take it. Me's just >> contributing a patch :) > > Who should provide actual data regarding the risk increases and the > *actual benefits* if not you? Me data is 'it helps me, and me's willing to accept the risk when necessary'. Obviously, only the big, bloated, poorly-programmed stuff (such as the Build engine) really benefits :) And please do note that the dynamic core is a run-time *option*: core=normal *still* works even with this patch applied. > While Jonathan (maintainer) has the final > say here, I would object to such a FLAVOR and patch being added. *shrugs* Your objection is noted. It might help other people. Me's not dictating anything to anyone... > A better way to spend time on dosbox would be to investigate ways to > improve speed without sacrificing basic security protections. A better way would IMNSHO be to port all those fun games the hell away from the obscure platform, *w/o* including a dependency tree that ultimately involves gnome and python! >[about the splash screen...] > > For the record: > --8<-- > bc 1.07.1 > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free > Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > -->8-- Yes, exactly :r Nice if you're juggling numbers in your head and quickly want to invoke bc to flush them... > You're indeed free to do whatever you want on your machines, but the > OpenBSD ports tree can't get away with removing copyright notices from > software later distributed on the mirrors. Me's not removing any copyright notices at all :s Just a funky splash screen that just *happens* to get in me way. > Again, maybe not for your own use case. Yes, YMMV, as always. > emulators/dosbox/Makefile: > > PERMIT_PACKAGE_CDROM= Yes > > so people may sell packages produced with the port. If that's really so much of a problem, we can disable that for the 'nosplash' flavour. And quite possibly not even build it by default. >[about whether or not me patch constitutes a formal proposal...] > > Proposals need to be reviewed, tested and committed. This takes time, > and time is a scarce resource. So again, please make it clear whether > you consider your next contributions proper for inclusion in the ports > tree. Alright, me'll make it clear: "me's honestly not sure". Y'know, medid anticipate all these point of principle. > You'll save other people's time and you'll avoid rants from > grumpy porters like me: a clear win for everybody. Rants are fine. Criticism is more than appreciated. But medoesn't like to waste people's time, no: if medid, mehereby offers me sincere apologies. >[about possible dep-reducing flavours...] > > Looking at the deps of feh and fceux, I doubt you're having a point > here. fceux: devel/desktop-file-utils, devel/scons, x11/gtk+2 feh: devel/desktop-file-utils, x11/gtk+3 And all that stuff pulls in python. Some things just go too far for me. --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01 2019, wrote: > Haai, > > "Jeremie Courreges-Anglas" wrote: >> >> Not to rain on your parade, but... > > Don't worry, me's just sharing a WFM :) > >>> 'dyncore': re-enable the dynamic core (possibly insecure) >> >> You don't mention a rationale for this. The only wxneeded report I know >> of mentions no performance change. > > Mehasn't measured, but on me (by your standards possibly ancient ;) > machines it really does help performance a lot (mewouldn't have > bothered if it didn't). > >> https://marc.info/?l=openbsd-ports=149053625314161=2 >> >> So what's the point of lowering the security of an emulator possibly >> used to run untrusted images? > > That's the one thing medoesn't do, mehas a background in IBM PC poop > (the horrors of me youth), so mealways manually installs stuff. Of > course, one needs to know what one is doing, but UNIX ain't for lusers. > > Of course, your point remains: most stuff running inside the emulator > is inherently untrusted (since most often no source code is available), > so there's still a risk. Honestly, though, given the general, ehrm, > "quality" of dosbox code, mesuspects some much larger holes in there > than --disable-dynamic-core could possibly address. > > It's a risk and people are free to take it or not to take it. Me's just > contributing a patch :) Who should provide actual data regarding the risk increases and the *actual benefits* if not you? While Jonathan (maintainer) has the final say here, I would object to such a FLAVOR and patch being added. A better way to spend time on dosbox would be to investigate ways to improve speed without sacrificing basic security protections. [...] >>> 'nosplash': disable spam piccy upon invocation >> >> Is that a serious proposal? The wording used for the ifdef doesn't seem >> appropriate. > > *shrugs* It's up to individual operators what runs on their machines, > and how it runs. Do we really want to end up w/ things like bc(1) first > sprouting lines of copyright info before accepting any input (the GNU > version does)? For the record: --8<-- bc 1.07.1 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. -->8-- You're indeed free to do whatever you want on your machines, but the OpenBSD ports tree can't get away with removing copyright notices from software later distributed on the mirrors. > Besides, me's always figured that the ad was put in as a response to > commercial peddlers wrapping old games inside dosbox and re-selling them > w/o giving any credit or indeed any indication, which is definitely not > the case here. Again, maybe not for your own use case. emulators/dosbox/Makefile: PERMIT_PACKAGE_CDROM= Yes so people may sell packages produced with the port. >> Regarding the intent, your diff contains the surrounding >> line: >> >>> + /* Please leave the Splash screen stuff in working order in DOSBox. We >>> spend a lot of time making DOSBox. */ >> >> That change doesn't look desirable in the ports tree IMO. > > It's a patch, and an optional one: individual operators are free to > honour or disregard the request. Me's giving choice, not a strait > jacket. > >> Obviously tests on -current would be better. > > Medoesn't have any machine that runs -current right now, sorry. > >> If you're proposing this diff for inclusion in the ports tree, please >> make that clear. > > Medoesn't know. Depends on whether or not people like it enough. > >> Your earlier proposal (with MAINTAINER in Cc) > > Meforgot the Cc this time, so mesent it separately to the maintainer > moments later. > >> didn't >> make it clear either: >> >> https://marc.info/?l=openbsd-ports=154669079320603=2 > > Well, honestly, me's been burned a little here and there when trying to > contribute to OpenBSD... If there's interest, me's certainly inclined to > rework it to make it more suitable for inclusion. Proposals need to be reviewed, tested and committed. This takes time, and time is a scarce resource. So again, please make it clear whether you consider your next contributions proper for inclusion in the ports tree. You'll save other people's time and you'll avoid rants from grumpy porters like me: a clear win for everybody. >> FLAVORS should be seldom used, they add complexity and make >> tests/updates harder. > > The lack of FLAVORS in several packages (feh, fceux...) actually made me > build them manually, in order to cut down on the bloat. So that argument > works both ways. Looking at the deps of feh and fceux, I doubt you're having a point here. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Marc Espie" wrote: > > Easy to run as a user who doesn't have any rights whatsoever Yup, the practical problems are limited. But it still ain't correct! :) --zeur. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01, 2019 at 04:55:58PM +0200, zeurk...@volny.cz wrote: > "Marc Espie" wrote: > > > > There are quite a few networked games that run in DOSbox. > > Yup, me point :) > > > I doubt you can 0wn anything but the game itself... > > It's mess-dos: pwn one program, pwn everything. And then there's the > emulated 'mount' command that any program can call... bit of a mess. > > Thus, medoes somewhat share the security concerns. > > --zeurkous. Easy to run as a user who doesn't have any rights whatsoever
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
"Marc Espie" wrote: > > There are quite a few networked games that run in DOSbox. Yup, me point :) > I doubt you can 0wn anything but the game itself... It's mess-dos: pwn one program, pwn everything. And then there's the emulated 'mount' command that any program can call... bit of a mess. Thus, medoes somewhat share the security concerns. --zeurkous. -- Friggin' Machines!
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Sat, Jun 01, 2019 at 01:25:18PM +0200, Jeremie Courreges-Anglas wrote: > I guess this is the easiest way to get networking support in dosbox. > But is that a good thing? Running DOS applications on the modern > internet looks dubious at best. There are quite a few networked games that run in DOSbox. I doubt you can 0wn anything but the game itself...
RE: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
Haai, "Jeremie Courreges-Anglas" wrote: > > Not to rain on your parade, but... Don't worry, me's just sharing a WFM :) >> 'dyncore': re-enable the dynamic core (possibly insecure) > > You don't mention a rationale for this. The only wxneeded report I know > of mentions no performance change. Mehasn't measured, but on me (by your standards possibly ancient ;) machines it really does help performance a lot (mewouldn't have bothered if it didn't). > https://marc.info/?l=openbsd-ports=149053625314161=2 > > So what's the point of lowering the security of an emulator possibly > used to run untrusted images? That's the one thing medoesn't do, mehas a background in IBM PC poop (the horrors of me youth), so mealways manually installs stuff. Of course, one needs to know what one is doing, but UNIX ain't for lusers. Of course, your point remains: most stuff running inside the emulator is inherently untrusted (since most often no source code is available), so there's still a risk. Honestly, though, given the general, ehrm, "quality" of dosbox code, mesuspects some much larger holes in there than --disable-dynamic-core could possibly address. It's a risk and people are free to take it or not to take it. Me's just contributing a patch :) >> 'ne2000': add third-party ne(4) emulation > > I guess this is the easiest way to get networking support in dosbox. > But is that a good thing? Running DOS applications on the modern > internet looks dubious at best. Actually, friends have used this in the past to play network doom w/ me running it on a real machine =) There are some other uses, as well. Me's not shooting anyone for this not being included in the first place, but it's handy at times. > Technically such a patch should probably be handled using > PATCHFILES/SUPDISTFILES. Yeah, you're prolly right, me's not that familiar w/ ports so metook the most straightforward way... >> 'nosplash': disable spam piccy upon invocation > > Is that a serious proposal? The wording used for the ifdef doesn't seem > appropriate. *shrugs* It's up to individual operators what runs on their machines, and how it runs. Do we really want to end up w/ things like bc(1) first sprouting lines of copyright info before accepting any input (the GNU version does)? Besides, me's always figured that the ad was put in as a response to commercial peddlers wrapping old games inside dosbox and re-selling them w/o giving any credit or indeed any indication, which is definitely not the case here. > Regarding the intent, your diff contains the surrounding > line: > >> + /* Please leave the Splash screen stuff in working order in DOSBox. We >> spend a lot of time making DOSBox. */ > > That change doesn't look desirable in the ports tree IMO. It's a patch, and an optional one: individual operators are free to honour or disregard the request. Me's giving choice, not a strait jacket. > Obviously tests on -current would be better. Medoesn't have any machine that runs -current right now, sorry. > If you're proposing this diff for inclusion in the ports tree, please > make that clear. Medoesn't know. Depends on whether or not people like it enough. > Your earlier proposal (with MAINTAINER in Cc) Meforgot the Cc this time, so mesent it separately to the maintainer moments later. > didn't > make it clear either: > > https://marc.info/?l=openbsd-ports=154669079320603=2 Well, honestly, me's been burned a little here and there when trying to contribute to OpenBSD... If there's interest, me's certainly inclined to rework it to make it more suitable for inclusion. > FLAVORS should be seldom used, they add complexity and make > tests/updates harder. The lack of FLAVORS in several packages (feh, fceux...) actually made me build them manually, in order to cut down on the bloat. So that argument works both ways. > s/WANT_LIB/WANTLIB/ below Ah, sorry, will fix on this end :) Again, if there's any interest (please speak up folks!), me'll work on this further. --zeurkous. -- Friggin' Machines!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 05:49:15 Modified files: x11/rdesktop : Makefile distinfo Removed files: x11/rdesktop/patches: patch-configure Log message: Update to rdesktop-1.8.6.
py-unicorn: enable Python 3 flavor
The reason unicorn is Python 2 only is QEMU's configure script depending
on Python >=2.4,<3.
But that's it; you can still build the rest with latest Python and use
it as some software does I'm currently trying to get running.
Thoughts?
Index: devel/Makefile
===
RCS file: /cvs/ports/devel/Makefile,v
retrieving revision 1.1860
diff -u -p -r1.1860 Makefile
--- devel/Makefile 23 May 2019 17:50:11 - 1.1860
+++ devel/Makefile 1 Jun 2019 11:26:25 -
@@ -1664,6 +1664,7 @@
SUBDIR += py-uncompyle6
SUBDIR += py-uncompyle6,python3
SUBDIR += py-unicorn
+ SUBDIR += py-unicorn,python3
SUBDIR += py-unit
SUBDIR += py-unit,no_x11
SUBDIR += py-unittest2
Index: devel/py-unicorn//Makefile
===
RCS file: /cvs/ports/devel/py-unicorn/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- devel/py-unicorn//Makefile 2 Apr 2019 13:09:12 - 1.3
+++ devel/py-unicorn//Makefile 1 Jun 2019 11:30:14 -
@@ -23,9 +23,11 @@ MODULES =lang/python
MODPY_PI = Yes
MODPY_SETUPTOOLS = Yes
-# XXX: ERROR: Cannot use '/usr/local/bin/python3.6', Python 2.4 or later is
required.
-#FLAVORS = python3
-#FLAVOR ?=
+FLAVORS = python3
+FLAVOR ?=
+
+# see patches/patch-src_Makefile
+BUILD_DEPENDS =lang/python/${MODPY_DEFAULT_VERSION_2}
USE_GMAKE =Yes
Index: devel/py-unicorn//patches/patch-src_Makefile
===
RCS file: /cvs/ports/devel/py-unicorn/patches/patch-src_Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 patch-src_Makefile
--- devel/py-unicorn//patches/patch-src_Makefile1 Apr 2019 02:24:07
- 1.1.1.1
+++ devel/py-unicorn//patches/patch-src_Makefile30 May 2019 21:50:56
-
@@ -1,5 +1,7 @@
$OpenBSD: patch-src_Makefile,v 1.1.1.1 2019/04/01 02:24:07 jasper Exp $
+ERROR: Cannot use '/usr/local/bin/python3.6', Python 2.4 or later is required.
+
Index: src/Makefile
--- src/Makefile.orig
+++ src/Makefile
@@ -8,7 +10,7 @@ Index: src/Makefile
qemu/config-host.h-timestamp:
cd qemu && \
- ./configure --cc="${CC}" --extra-cflags="$(UNICORN_CFLAGS)"
--target-list="$(UNICORN_TARGETS)" ${UNICORN_QEMU_FLAGS}
-+ ./configure --cc="${CC}" --extra-cflags="$(UNICORN_CFLAGS)"
--target-list="$(UNICORN_TARGETS)" ${UNICORN_QEMU_FLAGS} --python=${MODPY_BIN}
++ ./configure --cc="${CC}" --extra-cflags="$(UNICORN_CFLAGS)"
--target-list="$(UNICORN_TARGETS)" ${UNICORN_QEMU_FLAGS}
--python=${LOCALBASE}/bin/python2
printf "$(UNICORN_ARCHS)" > config.log
$(MAKE) -C qemu $(SMP_MFLAGS)
$(eval UC_TARGET_OBJ += $$(wildcard qemu/util/*.o) $$(wildcard
qemu/*.o) $$(wildcard qemu/qom/*.o) $$(wildcard qemu/hw/core/*.o) $$(wildcard
qemu/qapi/*.o) $$(wildcard qemu/qobject/*.o))
Index: devel/py-unicorn//pkg/PLIST
===
RCS file: /cvs/ports/devel/py-unicorn/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- devel/py-unicorn//pkg/PLIST 2 Apr 2019 13:09:12 - 1.2
+++ devel/py-unicorn//pkg/PLIST 30 May 2019 21:55:52 -
@@ -7,11 +7,18 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/unicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/unicorn-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/zip-safe
lib/python${MODPY_VERSION}/site-packages/unicorn/__init__.py
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/unicorn/arm64_const.py
lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}arm64_const.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/unicorn/arm_const.py
lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}arm_const.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}m68k_const.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}mips_const.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}sparc_const.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}unicorn.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}unicorn_const.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/${MODPY_PYCACHE}x86_const.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/unicorn/arm64_const.py
+lib/python${MODPY_VERSION}/site-packages/unicorn/arm_const.py
Re: patch: emulators/dosbox add 'dyncore', 'ne2000', 'nosplash' flavours
On Fri, May 31 2019, wrote:
> [not subscribed, please Cc, thanks.]
Not to rain on your parade, but...
> 6.5 update of the previous patch, w/ additional 'ne2000' flavour.
>
> 'dyncore': re-enable the dynamic core (possibly insecure)
You don't mention a rationale for this. The only wxneeded report I know
of mentions no performance change.
https://marc.info/?l=openbsd-ports=149053625314161=2
So what's the point of lowering the security of an emulator possibly
used to run untrusted images?
> 'ne2000': add third-party ne(4) emulation
I guess this is the easiest way to get networking support in dosbox.
But is that a good thing? Running DOS applications on the modern
internet looks dubious at best.
Technically such a patch should probably be handled using
PATCHFILES/SUPDISTFILES.
> 'nosplash': disable spam piccy upon invocation
Is that a serious proposal? The wording used for the ifdef doesn't seem
appropriate. Regarding the intent, your diff contains the surrounding
line:
> + /* Please leave the Splash screen stuff in working order in DOSBox. We
> spend a lot of time making DOSBox. */
That change doesn't look desirable in the ports tree IMO.
> Tested only in the most limited of fashions (on 6.5), but expected to
> work fine. As always, {bug,test} reports are very welcome.
Obviously tests on -current would be better.
If you're proposing this diff for inclusion in the ports tree, please
make that clear. Your earlier proposal (with MAINTAINER in Cc) didn't
make it clear either:
https://marc.info/?l=openbsd-ports=154669079320603=2
FLAVORS should be seldom used, they add complexity and make
tests/updates harder.
s/WANT_LIB/WANTLIB/ below
> Enjoy!
>
> --zeurkous.
>
> --- ports/emulators/dosbox/Makefile.orig Tue Jan 22 04:31:41 2019
> +++ ports/emulators/dosbox/Makefile Fri May 31 19:34:00 2019
> @@ -6,6 +6,7 @@
>
> VERSION= 0.74-2
> DISTNAME=dosbox-${VERSION}
> +REVISION=0
> PKGNAME= dosbox-${VERSION:S/-/./}
> CATEGORIES= games x11 emulators
> MASTER_SITES=${MASTER_SITE_SOURCEFORGE:=dosbox/}
> @@ -37,8 +38,26 @@
> CONFIGURE_ENV+=LDFLAGS="-L${LOCALBASE}/lib -L${X11BASE}/lib"
> CONFIGURE_ARGS+= --disable-alsatest
>
> +PATCH_LIST= patch-*
> +
> +FLAVORS= dyncore ne2000 nosplash
> +FLAVOR?=
> +
> +.if ${FLAVOR:L:Mne2000}
> +PATCH_LIST+= ne2000
> +WANT_LIB+=pcap
> +.endif
> +
> +.if ${FLAVOR:L:Mnosplash}
> +PATCH_LIST+= nosplash
> +.endif
> +
> +.if ${FLAVOR:L:Mdyncore}
> +PATCH_LIST+= wxneeded
> +.else
> # needs W+X memory
> CONFIGURE_ARGS+= --disable-dynamic-core
> +.endif
>
> pre-configure:
> cp ${FILESDIR}/midi_sndio.h ${WRKSRC}/src/gui
>
> --- /dev/null Fri May 31 19:56:39 2019
> +++ ports/emulators/dosbox/patches/ne2000 Fri May 31 19:45:02 2019
> @@ -0,0 +1,2047 @@
> +--- visualc_net/dosbox.vcproj.orig Thu Jul 5 13:24:23 2018
> visualc_net/dosbox.vcprojFri May 31 18:19:21 2019
> +@@ -480,6 +480,9 @@
> + +
> RelativePath="..\src\hardware\mixer.cpp">
> +
> ++ ++
> RelativePath="..\src\hardware\ne2000.cpp">
> ++
> + + RelativePath="..\src\hardware\pic.cpp">
> +
> +@@ -827,6 +830,9 @@
> +
> + + RelativePath="..\include\mouse.h">
> ++
> ++ ++RelativePath="..\include\ne2000.h">
> +
> + + RelativePath="..\include\paging.h">
> +
> +--- src/platform/visualc/config.h.orig Mon Aug 27 14:55:55 2018
> src/platform/visualc/config.hFri May 31 18:19:21 2019
> +@@ -12,6 +12,9 @@
> + /* Define to 1 to enable internal modem support, requires SDL_net */
> + #define C_MODEM 1
> +
> ++/* Define to 1 to enable NE2000 ethernet passthrough, requires libpcap */
> ++#define C_NE2000 1
> ++
> + /* Define to 1 to enable IPX networking support, requires SDL_net */
> + #define C_IPX 1
> +
> +
> +--- src/hardware/ne2000.cpp.orig Fri May 31 18:19:21 2019
> src/hardware/ne2000.cpp Fri May 31 18:28:13 2019
> +@@ -0,0 +1,1660 @@
> ++#include "config.h"
> ++
> ++#ifdef C_NE2000
> ++
> ++
> ++#include "dosbox.h"
> ++#include
> ++#include
> ++#include "support.h"
> ++#include "inout.h"
> ++#include "setup.h"
> ++#include "callback.h"
> ++#include "timer.h"
> ++#include "pic.h"
> ++#include "cpu.h"
> ++
> ++/* Couldn't find a real spec for the NE2000 out there, hence this is
> adapted heavily from Bochs */
> ++
> ++
> ++/
> ++// $Id: ne2k.cc,v 1.56.2.1 2004/02/02 22:37:22 cbothamy Exp $
>
Re: WIP attempt at updating devel/py-sip
(Sending the mail again, properly formatted this time.) Hi, Thanks for your response. On Fri, May 31, 2019 at 08:10:03PM +0200, Landry Breuil wrote: > On Fri, May 31, 2019 at 08:08:34PM +0200, Landry Breuil wrote: > > Fwiw if you go down that road, might aswell have a look at pyqt5 and > > py-sip, it's best to usually update all the things coming from this > > upstream altogether - we're badly lagging behind on py-qt5, but it might > > not be an easy task at all :) >=20 > Bah, spoke too fast, we have pyqt 5.9 because qt 5.9. Still py-sip is > lagging behind a bit :) I took a quick look at updating devel/py-sip. Most dependencies build with this new version of py-sip, except for x11/kde4/py-kde. Applying the following patch, found on the KDE/4.14 branch of upstream's git repository, does not fix the problems. https://cgit.kde.org/pykde4.git/commit/?h=3DKDE/4.14=3D2d1eadf5d0148c88c= b4393993f0269e196cbe7b1 Probably, I won't have time any time soon to look into this. So at least for now, it ends here. Below you can find the list of ports that I tried to build, the errors that I ran into when building x11/kde4/py-kde and my current diff for devel/py-sip. Best regards, Caspar Schutijser -- List of ports that I tried to build. As mentioned above, they all build successfully, except for x11/kde4/py-kde. games/mnemosyne is marked as BROKEN so didn't attempt to build that port. (Is there an easier way to just list all ports that in some way depend on devel/py-sip?) sqlite3 /usr/local/share/sqlports < Building for py-kde-4.14.3p1 [1/169] cd /home/ports/pobj/py-kde-4.14.3/build-amd64 && /usr/local/bin/cma= ke -E echo && touch /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/s= ipkutilspart0.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sip= kutilspart1.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipku= tilspart2.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkuti= lspart3.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutils= part4.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspa= rt5.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart= 6.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart7.= cpp && /usr/local/bin/sip -t ALL -t WS_X11 -t Qt_4_8_6 -x VendorID -x PyQt_= NoPrintRangeBug -P -g -x PyKDE_QVector -x Py_v3 -x PyKDE_GLuint -j 8 -c /ho= me/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils -I /home/ports/pobj/py-k= de-4.14.3/build-amd64 -I /usr/local/share/sip -I /usr/ports/pobj/py-kde-4.1= 4.3/pykde4-4.14.3/sip /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kutil= s/kutilsmod.sip FAILED: sip/kutils/sipkutilspart0.cpp sip/kutils/sipkutilspart1.cpp sip/kut= ils/sipkutilspart2.cpp sip/kutils/sipkutilspart3.cpp sip/kutils/sipkutilspa= rt4.cpp sip/kutils/sipkutilspart5.cpp sip/kutils/sipkutilspart6.cpp sip/kut= ils/sipkutilspart7.cpp=20 cd /home/ports/pobj/py-kde-4.14.3/build-amd64 && /usr/local/bin/cmake -E ec= ho && touch /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutils= part0.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspa= rt1.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart= 2.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart3.= cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart4.cp= p /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart5.cpp = /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart6.cpp /h= ome/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart7.cpp && /= usr/local/bin/sip -t ALL -t WS_X11 -t Qt_4_8_6 -x VendorID -x PyQt_NoPrintR= angeBug -P -g -x PyKDE_QVector -x Py_v3 -x PyKDE_GLuint -j 8 -c /home/ports= /pobj/py-kde-4.14.3/build-amd64/sip/kutils -I /home/ports/pobj/py-kde-4.14.= 3/build-amd64 -I /usr/local/share/sip -I /usr/ports/pobj/py-kde-4.14.3/pykd= e4-4.14.3/sip /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kutils/kutils= mod.sip sip: /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kdecore/typedefs.sip:2= 6: syntax error ninja: build stopped: subcommand failed. *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:39 'do-build': @cd /= usr/ports/pobj/py-kde-4.14.3/build-amd64 && exec /usr/bin/env -i ...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2801 '/usr/ports= /pobj/py-kde-4.14.3/build-amd64/.build_done') *** Error 1 in /usr/ports/x11/kde4/py-kde (/usr/ports/infrastructure/mk/bsd= =2Eport.mk:2471 'all') /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kdecore/typedefs.sip looks as follows: 22 typedef uint mode_t; 23 =20 24 typedef long time_t; 25 =20 26 typedef ulong size_t; 27 =20 28 typedef int ssize_t; 29 =20 30 typedef int pid_t; I quickly commented out line 26 in /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kdecore/typedefs.sip to see how far I would get, but that results in: $ make =3D=3D=3D> Building for py-kde-4.14.3p1 [1/153] cd
WIP attempt at updating devel/py-sip
Hi, Thanks for your response. On Fri, May 31, 2019 at 08:10:03PM +0200, Landry Breuil wrote: > On Fri, May 31, 2019 at 08:08:34PM +0200, Landry Breuil wrote: > > Fwiw if you go down that road, might aswell have a look at pyqt5 and > > py-sip, it's best to usually update all the things coming from this > > upstream altogether - we're badly lagging behind on py-qt5, but it might > > not be an easy task at all :) >=20 > Bah, spoke too fast, we have pyqt 5.9 because qt 5.9. Still py-sip is > lagging behind a bit :) I took a quick look at updating devel/py-sip. Most dependencies build with this new version of py-sip, except for x11/kde4/py-kde. Applying the following patch, found on the KDE/4.14 branch of upstream's git repository, does not fix the problems. https://cgit.kde.org/pykde4.git/commit/?h=3DKDE/4.14=3D2d1eadf5d0148c88c= b4393993f0269e196cbe7b1 Probably, I won't have time any time soon to look into this. So at least for now, it ends here. Below you can find the list of ports that I tried to build, the errors that I ran into when building x11/kde4/py-kde and my current diff for devel/py-sip. Best regards, Caspar Schutijser -- List of ports that I tried to build. As mentioned above, they all build successfully, except for x11/kde4/py-kde. games/mnemosyne is marked as BROKEN so didn't attempt to build that port. (Is there an easier way to just list all ports that in some way depend on devel/py-sip?) sqlite3 /usr/local/share/sqlports < Building for py-kde-4.14.3p1 [1/169] cd /home/ports/pobj/py-kde-4.14.3/build-amd64 && /usr/local/bin/cma= ke -E echo && touch /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/s= ipkutilspart0.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sip= kutilspart1.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipku= tilspart2.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkuti= lspart3.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutils= part4.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspa= rt5.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart= 6.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart7.= cpp && /usr/local/bin/sip -t ALL -t WS_X11 -t Qt_4_8_6 -x VendorID -x PyQt_= NoPrintRangeBug -P -g -x PyKDE_QVector -x Py_v3 -x PyKDE_GLuint -j 8 -c /ho= me/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils -I /home/ports/pobj/py-k= de-4.14.3/build-amd64 -I /usr/local/share/sip -I /usr/ports/pobj/py-kde-4.1= 4.3/pykde4-4.14.3/sip /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kutil= s/kutilsmod.sip FAILED: sip/kutils/sipkutilspart0.cpp sip/kutils/sipkutilspart1.cpp sip/kut= ils/sipkutilspart2.cpp sip/kutils/sipkutilspart3.cpp sip/kutils/sipkutilspa= rt4.cpp sip/kutils/sipkutilspart5.cpp sip/kutils/sipkutilspart6.cpp sip/kut= ils/sipkutilspart7.cpp=20 cd /home/ports/pobj/py-kde-4.14.3/build-amd64 && /usr/local/bin/cmake -E ec= ho && touch /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutils= part0.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspa= rt1.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart= 2.cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart3.= cpp /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart4.cp= p /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart5.cpp = /home/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart6.cpp /h= ome/ports/pobj/py-kde-4.14.3/build-amd64/sip/kutils/sipkutilspart7.cpp && /= usr/local/bin/sip -t ALL -t WS_X11 -t Qt_4_8_6 -x VendorID -x PyQt_NoPrintR= angeBug -P -g -x PyKDE_QVector -x Py_v3 -x PyKDE_GLuint -j 8 -c /home/ports= /pobj/py-kde-4.14.3/build-amd64/sip/kutils -I /home/ports/pobj/py-kde-4.14.= 3/build-amd64 -I /usr/local/share/sip -I /usr/ports/pobj/py-kde-4.14.3/pykd= e4-4.14.3/sip /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kutils/kutils= mod.sip sip: /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kdecore/typedefs.sip:2= 6: syntax error ninja: build stopped: subcommand failed. *** Error 1 in . (/usr/ports/devel/cmake/cmake.port.mk:39 'do-build': @cd /= usr/ports/pobj/py-kde-4.14.3/build-amd64 && exec /usr/bin/env -i ...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2801 '/usr/ports= /pobj/py-kde-4.14.3/build-amd64/.build_done') *** Error 1 in /usr/ports/x11/kde4/py-kde (/usr/ports/infrastructure/mk/bsd= =2Eport.mk:2471 'all') /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kdecore/typedefs.sip looks as follows: 22 typedef uint mode_t; 23 =20 24 typedef long time_t; 25 =20 26 typedef ulong size_t; 27 =20 28 typedef int ssize_t; 29 =20 30 typedef int pid_t; I quickly commented out line 26 in /usr/ports/pobj/py-kde-4.14.3/pykde4-4.14.3/sip/kdecore/typedefs.sip to see how far I would get, but that results in: $ make =3D=3D=3D> Building for py-kde-4.14.3p1 [1/153] cd /home/ports/pobj/py-kde-4.14.3/build-amd64 &&
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/06/01 04:11:09 Modified files: textproc/libwpd: Makefile Added files: textproc/libwpd/patches: patch-src_lib_WPXHeader_cpp Log message: libwpd: add a missing header to fix the build with ports-gcc OK jca@ (maintainer timeout)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/06/01 03:53:27 Modified files: www/p5-WWW-Search: Makefile distinfo Log message: p5-WWW-Search: update to 2.518 Changelog: https://metacpan.org/source/MTHURN/WWW-Search-2.518/Changes OK afresh1@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 03:52:34 Modified files: www/lighttpd : Makefile distinfo www/lighttpd/pkg: PLIST Log message: Update to lighttpd-1.4.54. from Brad (maintainer)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 03:47:19 Modified files: net/ircd-hybrid: Makefile distinfo net/ircd-hybrid/patches: patch-doc_Makefile_in patch-doc_reference_conf net/ircd-hybrid/pkg: PLIST Log message: Update to ircd-hybrid-8.2.26. from Brad
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2019/06/01 02:39:23 Modified files: www/chromium : Makefile www/chromium/patches: patch-base_process_process_metrics_openbsd_cc Log message: fix functions to show the proper number of open fds
UPDATE: graphics/krita
Update krita to 4.2.0.
Krita 4.2 Release Notes:
https://krita.org/en/krita-4-2-release-notes/
To build it you have to deinstall krita 4.18 otherwise tests will fetch
the old one.
Feedback is very welcome. All shared libs checked with
check_sym. Lightly tested on amd64.
RS
Index: Makefile
===
RCS file: /cvs/ports/graphics/krita/Makefile,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 Makefile
--- Makefile20 May 2019 22:15:13 - 1.25
+++ Makefile1 Jun 2019 08:21:07 -
@@ -2,37 +2,36 @@
COMMENT = advanced drawing and image manipulation
-VERSION = 4.1.8
+VERSION = 4.2.0
DISTNAME = krita-${VERSION}
-REVISION = 1
-SHARED_LIBS += kritabasicflakes 1.0 # 16.0
+SHARED_LIBS += kritabasicflakes 2.0 # 16.0
SHARED_LIBS += kritacolord 1.0 # 16.0
-SHARED_LIBS += kritaflake2.0 # 16.0
-SHARED_LIBS += kritaodf 1.0 # 16.0
-SHARED_LIBS += kritapigment 2.0 # 16.0
+SHARED_LIBS += kritaflake3.0 # 16.0
+SHARED_LIBS += kritaodf 2.0 # 16.0
+SHARED_LIBS += kritapigment 3.0 # 16.0
SHARED_LIBS += kritaplugin 1.0 # 16.0
-SHARED_LIBS += kritastore1.0 # 16.0
+SHARED_LIBS += kritastore2.0 # 16.0
SHARED_LIBS += kritatext 1.0 # 16.0
SHARED_LIBS += kritatextlayout 1.0 # 16.0
-SHARED_LIBS += kritaundo21.0 # 16.0
SHARED_LIBS += kritavectorimage 2.0 # 16.0
SHARED_LIBS += kritaversion 1.0 # 16.0
-SHARED_LIBS += kritawidgets 1.0 # 16.0
-SHARED_LIBS += kritawidgetutils 3.0 # 16.0
-SHARED_LIBS += kritacommand 1.0 # 16.0
+SHARED_LIBS += kritawidgets 2.0 # 16.0
+SHARED_LIBS += kritawidgetutils 4.0 # 16.0
+SHARED_LIBS += kritacommand 2.0 # 16.0
SHARED_LIBS += kritaimpex1.0 # 16.0
-SHARED_LIBS += kritalibkis 1.0 # 16.0
-SHARED_LIBS += kritalibkra 1.0 # 16.0
-SHARED_LIBS += kritaqml 1.0 # 16.0
+SHARED_LIBS += kritalibkis 2.0 # 16.0
+SHARED_LIBS += kritalibkra 2.0 # 16.0
+SHARED_LIBS += kritaqml 2.0 # 16.0
+SHARED_LIBS += kritametadata 0.0 # 18.0
# XXX Version numbers from editors/calligra 2.x port
SHARED_LIBS += kritapsd 2.0 # 14.0
SHARED_LIBS += kritacolor2.0 # 14.0
-SHARED_LIBS += kritaglobal 3.0 # 14.0
-SHARED_LIBS += kritaimage53.0 # 0.0
-SHARED_LIBS += kritalibbrush 52.0 # 0.0
-SHARED_LIBS += kritalibpaintop 52.0 # 0.0
-SHARED_LIBS += kritaui 56.0 # 0.0
+SHARED_LIBS += kritaglobal 4.0 # 14.0
+SHARED_LIBS += kritaimage54.0 # 0.0
+SHARED_LIBS += kritalibbrush 52.1 # 0.0
+SHARED_LIBS += kritalibpaintop 53.0 # 0.0
+SHARED_LIBS += kritaui 57.0 # 0.0
CATEGORIES = graphics
DPB_PROPERTIES = parallel
@@ -52,7 +51,7 @@ WANTLIB += Qt5Core Qt5DBus Qt5Gui Qt5Mul
WANTLIB += Qt5Qml Qt5Quick Qt5QuickWidgets Qt5Svg Qt5Widgets Qt5X11Extras
WANTLIB += Qt5Xml SM X11 Xext Xi boost_system-mt c exiv2 fftw3
WANTLIB += gif gsl gslcblas jpeg lcms2 m png poppler poppler-qt5
-WANTLIB += raw tiff xcb xcb-util z
+WANTLIB += quazip5 raw tiff xcb xcb-util z
MASTER_SITES = ${MASTER_SITE_KDE:=stable/krita/${VERSION}/}
EXTRACT_SUFX = .tar.gz
@@ -68,7 +67,8 @@ RUN_DEPENDS +=devel/desktop-file-utils
x11/gtk+3,-guic \
x11/qt5/qtquickcontrols
-LIB_DEPENDS += devel/boost \
+LIB_DEPENDS += archivers/quazip,qt5 \
+ devel/boost \
devel/gsl \
devel/kf5/karchive \
devel/kf5/kcompletion \
@@ -102,8 +102,8 @@ BUILD_DEPENDS +=devel/gettext,-tools \
math/eigen3 \
net/curl
-CONFIGURE_ARGS += -DCMAKE_DISABLE_FIND_PACKAGE_SIP:Bool=Yes \
- -DCMAKE_DISABLE_FIND_PACKAGE_PyQt5:Bool=Yes
+CONFIGURE_ARGS += -DCMAKE_DISABLE_FIND_PACKAGE_SIP=NO \
+ -DCMAKE_DISABLE_FIND_PACKAGE_PyQt5=NO
TEST_IS_INTERACTIVE = X11
Index: distinfo
===
RCS file: /cvs/ports/graphics/krita/distinfo,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 distinfo
--- distinfo10 Mar 2019 10:52:57 - 1.15
+++ distinfo1 Jun 2019 08:21:07 -
@@ -1,2 +1,2 @@
-SHA256 (krita-4.1.8.tar.gz) = BHbJ4iefCuaQwu0C4aqcPUkZQ2Q/mFk1WgJlcxi9WUA=
-SIZE (krita-4.1.8.tar.gz) = 244065767
+SHA256 (krita-4.2.0.tar.gz) = 1etczovbaLxmno+PakHQmCG8xO9aTJneb3g4sciEq9A=
+SIZE (krita-4.2.0.tar.gz) = 240015177
Index:
Re: [UPDATE] devel/openmpi 4.0.1
Please don't do the huge bump for SHARED_LIBS, just a standard major bump
for the existing libraries and start the new ones at 0.0
--
Sent from a phone, apologies for poor formatting.
On 31 May 2019 18:55:23 Martin Reindl wrote:
Hello ports@,
here is an update for another port that probably get's not much widespread
usage. Nevertheless, this is worthwhile for people running in an MPI-3.1
environment. Tested on macppc, arm64 and amd64. I only needed this once, so
I am not too keen on taking MAINTAINER. Note all fortran bits pass make test
with the new egfortran from ports-gcc on the aforementioned archs.
-m
Index: Makefile
===
RCS file: /cvs/ports/devel/openmpi/Makefile,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 Makefile
--- Makefile 21 Jan 2019 14:24:30 - 1.26
+++ Makefile 30 May 2019 17:19:34 -
@@ -1,52 +1,46 @@
# $OpenBSD: Makefile,v 1.26 2019/01/21 14:24:30 jca Exp $
-BROKEN-hppa = error: Could not determine global symbol label prefix
-BROKEN-powerpc = checking if Fortran 77 compiler works... no
+COMMENT = open source MPI-3.1 implementation
-COMMENT = open source MPI-2 implementation
-
-V= 1.4.1
+V= 4.0.1
DISTNAME = openmpi-$V
-REVISION = 8
-
-SHARED_LIBS = mca_common_sm 1.0 \
- mpi 0.1 \
- mpi_cxx 0.0 \
- mpi_f77 0.0 \
- open-pal 0.0 \
- open-rte 0.0
CATEGORIES = devel
+MASTER_SITES =
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
+
HOMEPAGE = http://www.open-mpi.org/
+# BSD
+PERMIT_PACKAGE_CDROM = Yes
+
+SHARED_LIBS += mca_common_dstore 1.0 \
+ mca_common_monitoring 60.0 \
+ mca_common_ompio 60.1 \
+ mca_common_sm 60.0 \
+ mpi 60.1 \
+ mpi_cxx 60.0 \
+ mpi_mpifh 60.1 \
+ mpi_usempi_ignore_tkr 60.0 \
+ mpi_usempif08 60.0 \
+ ompitrace 60.0 \
+ open-pal 60.1 \
+ open-rte 60.1
+
MODULES = fortran
-MODFORTRAN_COMPILER = g77
+MODFORTRAN_COMPILER = gfortran
BUILD_DEPENDS += ${MODFORTRAN_BUILD_DEPENDS}
-# BSD
-PERMIT_PACKAGE_CDROM = Yes
+LIB_DEPENDS += devel/libexecinfo
WANTLIB += c m pthread ${COMPILER_LIBCXX} util z
+WANTLIB += pciaccess execinfo
COMPILER = base-clang ports-gcc base-gcc
-MASTER_SITES =
${HOMEPAGE}/software/ompi/v${V:C/^([0-9]+\.[0-9]+).*/\1/}/downloads/
-
-# XXX: uses a locally modified libtool.
-USE_LIBTOOL = No
-
-FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
CONFIGURE_STYLE = gnu
-CONFIGURE_ENV = F77=${MODFORTRAN_COMPILER}
+CONFIGURE_ARGS += --enable-mpi-cxx
-.include
-.if ${PROPERTIES:Mclang}
-CONFIGURE_ARGS = --disable-visibility
-.endif
-
-# openmpi's otfinfo conflicts with the one from texlive
-post-install:
- mv ${PREFIX}/bin/otfinfo ${PREFIX}/bin/otfinfompi
+FAKE_FLAGS = sysconfdir=${PREFIX}/share/examples/openmpi/
.include
Index: distinfo
===
RCS file: /cvs/ports/devel/openmpi/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- distinfo 18 Jan 2015 03:13:19 - 1.3
+++ distinfo 30 May 2019 17:19:34 -
@@ -1,2 +1,2 @@
-SHA256 (openmpi-1.4.1.tar.gz) = quq9IhjNxPEejgPhVTkQEpzIQw6TN2xANsqW/BoVubU=
-SIZE (openmpi-1.4.1.tar.gz) = 9960381
+SHA256 (openmpi-4.0.1.tar.gz) = 5V4hP+CaIUq58scirP2L97ObvBgA5LekZNON8V5wf1k=
+SIZE (openmpi-4.0.1.tar.gz) = 17513706
Index: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
===
RCS file: patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
diff -N patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc
--- patches/patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc 11 Apr 2018
22:49:40 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,145 +0,0 @@
-$OpenBSD: patch-ompi_contrib_vt_vt_tools_compwrap_compwrap_cc,v 1.1
2018/04/11 22:49:40 sthen Exp $
-
-Index: ompi/contrib/vt/vt/tools/compwrap/compwrap.cc
ompi/contrib/vt/vt/tools/compwrap/compwrap.cc.orig
-+++ ompi/contrib/vt/vt/tools/compwrap/compwrap.cc
-@@ -99,7 +99,7 @@ ReadDataFile()
- "compiler_iflags_ftrace", "inst_avail", "inst_default"
-};
-
-- std::string data_file = DATADIR"/" + ExeName + "-wrapper-data.txt";
-+ std::string data_file = DATADIR "/" + ExeName + "-wrapper-data.txt";
-std::ifstream in( data_file.c_str() );
-if( !in )
-{
-@@ -646,11 +646,11 @@ ParseCommandLine( int argc, char ** argv )
- //
- // -vt:
- //
-- else if( arg.compare("-vt:"WRAP_LANG_SUFFIX) == 0 )
-+ else if( arg.compare("-vt:" WRAP_LANG_SUFFIX) == 0 )
- {
- if( i == argc - 1 )
- {
--std::cerr << ExeName << ": expected -- -vt:"WRAP_LANG_SUFFIX
-+std::cerr << ExeName << ": expected -- -vt:" WRAP_LANG_SUFFIX
- << std::endl;
-return false;
- }
-@@ -824,7 +824,7 @@ Wrapper::showUsageText()
- << " compiler wrapper for VampirTrace."
- << std::endl << std::endl
- << "
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2019/06/01 01:58:09 Modified files: x11/gnome/gedit: Makefile Log message: Missing BDEP on devel/libsoup.
UPDATE games/lgeneral
Hi!
This is an update to the latest version of lgeneral.
I've added CC BY-SA 3.0 licensed data package, so there is
no need to purchase original PD data.
OK, comments?
Index: Makefile
===
RCS file: /cvs/ports/games/lgeneral/Makefile,v
retrieving revision 1.19
diff -u -p -r1.19 Makefile
--- Makefile 7 May 2019 17:04:58 - 1.19
+++ Makefile 1 Jun 2019 07:32:04 -
@@ -2,28 +2,40 @@
COMMENT= turn-based strategy engine
-DISTNAME= lgeneral-0.5.0
-REVISION = 3
+DISTNAME= lgeneral-1.4.3
CATEGORIES= games x11
-HOMEPAGE= http://lgeneral.sourceforge.net/
+DISTFILES= ${DISTNAME}${EXTRACT_SUFX} \
+ kukgen-data-1.1.tar.gz
+HOMEPAGE= http://lgames.sourceforge.net/LGeneral/
+
+# GPLv2 / CC BY-SA 3.0 (data)
PERMIT_PACKAGE_CDROM= Yes
-WANTLIB= X11 Xext c m pthread usbhid xcb \
- SDL SDL_mixer
+
+WANTLIB += SDL SDL_mixer c intl m pthread
MASTER_SITES= ${MASTER_SITE_SOURCEFORGE:=lgeneral/}
-LIB_DEPENDS= devel/sdl \
+LIB_DEPENDS= devel/gettext \
devel/sdl-mixer
+RUN_DEPENDS= devel/desktop-file-utils \
+ x11/gtk+3,-guic
-
-AUTOCONF_VERSION=2.13
+SEPARATE_BUILD= Yes
+AUTOCONF_VERSION=2.69
CONFIGURE_STYLE= autoconf
+CONFIGURE_ENV+= LDFLAGS=-L${LOCALBASE}/lib \
+ CPPFLAGS=-I${LOCALBASE}/include
CFLAGS += -fgnu89-inline
+DATA= lgeneral-data-1.1-d4d831b06c39a4d20dd0a96d0a89e3d50f22e69a
+
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/lgeneral
- ${INSTALL_DATA} ${WRKSRC}/README ${PREFIX}/share/doc/lgeneral
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/lgeneral/
+ ${INSTALL_DATA} ${WRKSRC}/README.lgeneral ${PREFIX}/share/doc/lgeneral/
+ ${INSTALL_DATA} ${WRKSRC}/README.lgc-pg ${PREFIX}/share/doc/lgeneral/
+ cd ${WRKDIR}/${DATA}/ && pax -rw {gfx,maps,nations,scenarios,sounds,units} \
+ ${PREFIX}/share/lgeneral/
.include
Index: distinfo
===
RCS file: /cvs/ports/games/lgeneral/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo 18 Jan 2015 03:13:59 - 1.4
+++ distinfo 1 Jun 2019 07:32:04 -
@@ -1,2 +1,4 @@
-SHA256 (lgeneral-0.5.0.tar.gz) = NrvzWw+LzwSjZrj+26zABinRYyxsv6K5TJNF3CJp5FU=
-SIZE (lgeneral-0.5.0.tar.gz) = 580837
+SHA256 (kukgen-data-1.1.tar.gz) = +61o5uySMl/2Pb5q53M3+YBqQ0dmfHEvlCZUGbidbYQ=
+SHA256 (lgeneral-1.4.3.tar.gz) = nJ0/vYWVr8ozpHUz+cLOYyBXewvOhYUfZgyb7gdVYCg=
+SIZE (kukgen-data-1.1.tar.gz) = 1883592
+SIZE (lgeneral-1.4.3.tar.gz) = 1924730
Index: patches/patch-configure_in
===
RCS file: patches/patch-configure_in
diff -N patches/patch-configure_in
--- patches/patch-configure_in 26 May 2002 01:07:57 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,21 +0,0 @@
-$OpenBSD: patch-configure_in,v 1.2 2002/05/26 01:07:57 brad Exp $
configure.in.orig Fri Aug 3 15:45:21 2001
-+++ configure.in Sat May 25 19:59:07 2002
-@@ -50,6 +50,8 @@ mixer_flag="-lSDL_mixer"
- AC_ARG_ENABLE( sound,
- [ --disable-sound Disables sound], sound_flag=""; mixer_flag="")
-
-+AC_CHECK_LIB(m, sqrt)
-+
- dnl check if SDL_mixer's installed
- dnl if not: clear sound_flag and mixer_flag
- AC_CHECK_LIB(SDL_mixer, main,
-@@ -60,7 +62,7 @@ AC_SUBST(sound_flag)
- AC_SUBST(mixer_flag)
-
- dnl installation path
--inst_dir=$datadir/games/lgeneral
-+inst_dir=$datadir/lgeneral
- inst_flag="-DSRC_DIR=\\\"$inst_dir\\\""
-
- AC_ARG_ENABLE( install,
Index: patches/patch-lgeneral_deploy_h
===
RCS file: patches/patch-lgeneral_deploy_h
diff -N patches/patch-lgeneral_deploy_h
--- patches/patch-lgeneral_deploy_h 17 May 2017 11:00:07 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,14 +0,0 @@
-$OpenBSD: patch-lgeneral_deploy_h,v 1.1 2017/05/17 11:00:07 espie Exp $
-
-Index: lgeneral/deploy.h
lgeneral/deploy.h.orig
-+++ lgeneral/deploy.h
-@@ -16,7 +16,7 @@
- ***/
-
- #ifndef __DEPLOY_H
--#define __DELPOY_H
-+#define __DEPLOY_H
-
- /*
-
Index: patches/patch-lgeneral_gui_c
===
RCS file: patches/patch-lgeneral_gui_c
diff -N patches/patch-lgeneral_gui_c
--- patches/patch-lgeneral_gui_c 20 May 2017 17:13:01 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,41 +0,0 @@
-$OpenBSD: patch-lgeneral_gui_c,v 1.2 2017/05/20 17:13:01 espie Exp $
-
-Index: lgeneral/gui.c
lgeneral/gui.c.orig
-+++ lgeneral/gui.c
-@@ -565,7 +565,7 @@ Window* create_edit( Window *parent, int id, SDL_Surfa
- /* if frame pic == 0 leave away the frame */
- if ( frame_pic != 0 ) {
- /* frame tile size */
--tile_size = tile_size = frame_pic->w / 3;
-+tile_size = frame_pic->w / 3;
- /* add horizontal top/bottom line */
- for ( i = tile_size; i < width -
new: devel/woboq_codebrowser
Hi, I would like to import woboq_codebrowser, a HTML generator from C, C++ source code. It is based on LLVM. Homepage: https://woboq.com/codebrowser.html Example usage: https://code.woboq.org/ (with Qt, GLibc, LLVM, Boost, GCC, Linux) >From pkg/DESCR: The generator generates static HTML pages that can be served by any web server. It can be run automatically manually or with a hook on your version control or CI system. It functions as the source code indexer (using libclang). In contrast to other solutions (LXR, OpenGrok) it semantically analyzes the code as a compile step. The generation is a two-step process: First is a compile step that creates a .h.html and .cpp.html (and some other) files from the syntax tree (AST) of the source source. The second step generates an index.html for each directory. A server-side database or CGI script are currently not needed, so it is easy to host. Your normal HTML5 web browser is the source code navigator (from your local machine or your network). First, it is dual licenced: Commercial or CC-BY-NC-SA 3.0. It means the licence does not allow to use the code browser to assist the development of your commercial software: https://github.com/woboq/woboq_codebrowser#licence-information I mentioned it in pkg/DESCR and in pkg/README to ensure user will be aware of it. Regarding the port itself: - does the category "devel" is the right one ? It could be "www" ou "textproc" too. - the programs (code generator and index generator) are C++ and are linked against LLVM-7.so. As it is using "MODULES += lang/clang", I do not mention any preference in COMPILER. Is it right ? - for LLVM-7.so dependency, I added devel/llvm explicitly in RUN_DEPENDS. - the port version is "2.1pl0" : the official 2.1 (from Jul 26, 2017) doesn't build against LLVM 7. There are commits in master branch to support it, so I targeted the latest commit in master branch (Mar 26, 2019). It is still versioned as "2.1" in code source, so the port has "2.1 patchlevel 0", and we could increment the patchlevel if we target a new commit still in 2.1, or switch to 2.2 when released. - I included in pkg/README the way to use it on OpenBSD kernel as some gymnastic is required (the input list of files to consider is JSON as required by clang tooling). - I also added pledge(2) and unveil(2) to the programs. There are restricted to basic filesystem operations (readonly), with only write capability on output directory. Comments or OK to import it ? Thanks. -- Sebastien Marie woboq_codebrowser.tgz Description: application/tar-gz
