Re: i386 failures
On Tuesday, August 18, 2020 1:59 PM, Christian Weisgerber wrote: > On 2020-08-18, Stuart Henderson s...@spacehopper.org wrote: > > > build failures: 12 > > These are the actual i386 failures: > > > audio/mscore: out of memory linking If musescore is built on i386 with -Oz instead of -O2, then the link is successful. I was able to create a working MuseScore on i386 (via vmm, X11 accessed via TigerVNC) with this tweak. Though I'm not sure how desirable it is. ~Brian
Re: chromium: Check failed: . : Too many open files
On Tue, Aug 18, 2020 at 10:50 PM Robert Nagy wrote: > What is your fd limit? Please monitor fstat and see which process goes out > of whack with file descriptor usage. > Presumably we verify that the minimal viable value of 400 is available, I have % ulimit -Sn 512 I'll keep an eye on fstat now that I got up to chromium-84.0.4147.125. As of now I'm at: % fstat | grep chrome | sort -k4 -n | tail -n3 greg chrome 19291 263 /home 7405655 -rw---rp81109 greg chrome 19291 264 /home 6340676 -rw---wp 41 greg chrome 19291 265 /home 6340678 -rw---wp 277820 Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
Re: chromium: Check failed: . : Too many open files
Hi What is your fd limit? Please monitor fstat and see which process goes out of whack with file descriptor usage. On 18/08/20 17:14 -0700, Greg Steuck wrote: > I've had chromium dump core on me a few times recently (it had run > reliably for a long time before). I'm on a Aug 5 amd64-current and have > chromium-84.0.4147.105p2. My .xsession-errors contains these lines: > > [8234:607566400:0817/213026.408392:ERROR:platform_shared_memory_region_posix.cc(250)] > Creating shared memory in /tmp/.org.chromium.Chromium.3srUZ4 failed: Too > many open files (24) > ... a few times then > [8234:-980578240:0817/213026.475239:FATAL:platform_channel.cc(148)] Check > failed: . : Too many open files (24) > > egdb shows a somewhat bizarre stack trace, so I don't know if it's a > smashed stack or just an unwinding bug: > > (gdb) bt > #0 0x0f1a95ebe008 in ?? () > #1 0x3332385bbedead01 in ?? () > #2 0x37353038392d3a34 in ?? () > #3 0x3138303a30343238 in ?? () > #4 0x3632303331322f37 in ?? () > #5 0x3a3933323537342e in ?? () > #6 0x6c703a4c41544146 in ?? () > #7 0x635f6d726f667461 in ?? () > #8 0x632e6c656e6e6168 in ?? () > #9 0x205d293834312863 in ?? () > #10 0x6166206b63656843 in ?? () > #11 0x202e203a64656c69 in ?? () > #12 0x616d206f6f54203a in ?? () > #13 0x206e65706f20796e in ?? () > #14 0x32282073656c6966 in ?? () > #15 0x000a2934 in ?? () > #16 0x in ?? () > ... more 0x > #129 0x5050dead in ?? () > #130 0x323d18ea4be34c8c in ?? () > #131 0x0f1d9a3ae018 in ?? () > #132 0x0f1ca613c408 in ofree (argpool=0xf1d77210e00, p=0xf1d9a3ae010, > clear=-845667388, check=, argsz=16616382801953) > at /home/greg/s/src/lib/libc/stdlib/malloc.c:1443 > #133 0x0f1a95ebe2ef in ?? () > #134 0x0018 in ?? () > #135 0x0018 in ?? () > #136 0x0f1d3ee11c00 in ?? () > #137 0x0f1d9a3ae000 in ?? () > #138 0x0f1ccd982a20 in ?? () > #139 0x3ec7d22ecf2bfb01 in ?? () > #140 0x0f1ccd9828d0 in ?? () > #141 0x0f1a95ebe31f in ?? () > #142 0x0f1a9b82d3f0 in ?? () > #143 0x0f1ccd982a38 in ?? () > #144 0x0f1ccd9829c0 in ?? () > #145 0x0f1a960e8828 in ?? () > #146 0x0f1ccd982940 in ?? () > #147 0x0f1ca61877ac in _rthread_mutex_trylock (mutex=0xf1d9a3ae010, > trywait=-1707417600, abs=0xf1d9a3ae010) > at /home/greg/s/src/lib/libc/thread/rthread_mutex.c:99 > #148 _rthread_mutex_timedlock (mutexp=0x, > trywait=-1707417600, abs=0xf1d9a3ae010, timed=-845665968) > at /home/greg/s/src/lib/libc/thread/rthread_mutex.c:167 > > (gdb) info registers > rax0x0 0 > rbx0xf1ccd9823c416616382800836 > rcx0xf1cfb6e62e016617151816416 > rdx0xf1cc58d904016616247889984 > rsi0xf1ca611fd0b16615719697675 > rdi0xf1d117ec63016617521989168 > rbp0xf1ccd9828700xf1ccd982870 > rsp0xf1ccd9823c00xf1ccd9823c0 > r8 0xf1cc58d904016616247889984 > r9 0x0 0 > r100x475acee714674049 5141649416471920713 > r110xd38a41087b546012 -3203676680236015598 > r120xf1ccd98282116616382801953 > r130x -6148914691236517206 > r140xf1d9a3ae01016619816017936 > r150xf1d9a3ae00016619816017920 > rip0xf1a95ebe0080xf1a95ebe008 > eflags 0x246[ PF ZF IF ] > cs 0x2b 43 > ss 0x23 35 > ds 0x23 35 > es 0x23 35 > fs 0x23 35 > gs 0x23 35 > > (gdb) x/36wx $rsp > 0xf1ccd9823c0: 0xbedead01 0x3332385b 0x392d3a34 0x37353038 > 0xf1ccd9823d0: 0x30343238 0x3138303a 0x31322f37 0x36323033 > 0xf1ccd9823e0: 0x3537342e 0x3a393332 0x41544146 0x6c703a4c > 0xf1ccd9823f0: 0x6f667461 0x635f6d72 0x6e6e6168 0x632e6c65 > 0xf1ccd982400: 0x34312863 0x205d2938 0x63656843 0x6166206b > 0xf1ccd982410: 0x64656c69 0x202e203a 0x6f54203a 0x616d206f > 0xf1ccd982420: 0x6f20796e 0x206e6570 0x656c6966 0x32282073 > 0xf1ccd982430: 0x000a2934 0x 0x 0x > 0xf1ccd982440: 0x 0x 0x 0x -- Regards, Robert Nagy
chromium: Check failed: . : Too many open files
I've had chromium dump core on me a few times recently (it had run reliably for a long time before). I'm on a Aug 5 amd64-current and have chromium-84.0.4147.105p2. My .xsession-errors contains these lines: [8234:607566400:0817/213026.408392:ERROR:platform_shared_memory_region_posix.cc(250)] Creating shared memory in /tmp/.org.chromium.Chromium.3srUZ4 failed: Too many open files (24) ... a few times then [8234:-980578240:0817/213026.475239:FATAL:platform_channel.cc(148)] Check failed: . : Too many open files (24) egdb shows a somewhat bizarre stack trace, so I don't know if it's a smashed stack or just an unwinding bug: (gdb) bt #0 0x0f1a95ebe008 in ?? () #1 0x3332385bbedead01 in ?? () #2 0x37353038392d3a34 in ?? () #3 0x3138303a30343238 in ?? () #4 0x3632303331322f37 in ?? () #5 0x3a3933323537342e in ?? () #6 0x6c703a4c41544146 in ?? () #7 0x635f6d726f667461 in ?? () #8 0x632e6c656e6e6168 in ?? () #9 0x205d293834312863 in ?? () #10 0x6166206b63656843 in ?? () #11 0x202e203a64656c69 in ?? () #12 0x616d206f6f54203a in ?? () #13 0x206e65706f20796e in ?? () #14 0x32282073656c6966 in ?? () #15 0x000a2934 in ?? () #16 0x in ?? () ... more 0x #129 0x5050dead in ?? () #130 0x323d18ea4be34c8c in ?? () #131 0x0f1d9a3ae018 in ?? () #132 0x0f1ca613c408 in ofree (argpool=0xf1d77210e00, p=0xf1d9a3ae010, clear=-845667388, check=, argsz=16616382801953) at /home/greg/s/src/lib/libc/stdlib/malloc.c:1443 #133 0x0f1a95ebe2ef in ?? () #134 0x0018 in ?? () #135 0x0018 in ?? () #136 0x0f1d3ee11c00 in ?? () #137 0x0f1d9a3ae000 in ?? () #138 0x0f1ccd982a20 in ?? () #139 0x3ec7d22ecf2bfb01 in ?? () #140 0x0f1ccd9828d0 in ?? () #141 0x0f1a95ebe31f in ?? () #142 0x0f1a9b82d3f0 in ?? () #143 0x0f1ccd982a38 in ?? () #144 0x0f1ccd9829c0 in ?? () #145 0x0f1a960e8828 in ?? () #146 0x0f1ccd982940 in ?? () #147 0x0f1ca61877ac in _rthread_mutex_trylock (mutex=0xf1d9a3ae010, trywait=-1707417600, abs=0xf1d9a3ae010) at /home/greg/s/src/lib/libc/thread/rthread_mutex.c:99 #148 _rthread_mutex_timedlock (mutexp=0x, trywait=-1707417600, abs=0xf1d9a3ae010, timed=-845665968) at /home/greg/s/src/lib/libc/thread/rthread_mutex.c:167 (gdb) info registers rax0x0 0 rbx0xf1ccd9823c416616382800836 rcx0xf1cfb6e62e016617151816416 rdx0xf1cc58d904016616247889984 rsi0xf1ca611fd0b16615719697675 rdi0xf1d117ec63016617521989168 rbp0xf1ccd9828700xf1ccd982870 rsp0xf1ccd9823c00xf1ccd9823c0 r8 0xf1cc58d904016616247889984 r9 0x0 0 r100x475acee714674049 5141649416471920713 r110xd38a41087b546012 -3203676680236015598 r120xf1ccd98282116616382801953 r130x -6148914691236517206 r140xf1d9a3ae01016619816017936 r150xf1d9a3ae00016619816017920 rip0xf1a95ebe0080xf1a95ebe008 eflags 0x246[ PF ZF IF ] cs 0x2b 43 ss 0x23 35 ds 0x23 35 es 0x23 35 fs 0x23 35 gs 0x23 35 (gdb) x/36wx $rsp 0xf1ccd9823c0: 0xbedead01 0x3332385b 0x392d3a34 0x37353038 0xf1ccd9823d0: 0x30343238 0x3138303a 0x31322f37 0x36323033 0xf1ccd9823e0: 0x3537342e 0x3a393332 0x41544146 0x6c703a4c 0xf1ccd9823f0: 0x6f667461 0x635f6d72 0x6e6e6168 0x632e6c65 0xf1ccd982400: 0x34312863 0x205d2938 0x63656843 0x6166206b 0xf1ccd982410: 0x64656c69 0x202e203a 0x6f54203a 0x616d206f 0xf1ccd982420: 0x6f20796e 0x206e6570 0x656c6966 0x32282073 0xf1ccd982430: 0x000a2934 0x 0x 0x 0xf1ccd982440: 0x 0x 0x 0x
Re: UPDATE: GCC 8.4.0
>> On Aug 18, 2020, at 1:12 PM, Brad Smith wrote: >> >> On Sat, Mar 14, 2020 at 03:58:12AM -0400, Brad Smith wrote: >> Here is a start at an update to GCC 8.4.0. >> I e-mailed Pascal 10 days ago but no response. > > Added the version bump for LLVM. > > Has been run through a bulk build on sparc64 without issue. Hi Brad, If we’re going to go through the effort of retesting gcc — and I think it’s probably better to do bulks on many platforms, not just one — then why not go to gcc9 or gcc10 instead? I have a port for gcc9 if there’s interest. Secondly, any reason adastraps are not regenerated as part of the proposal? One nice thing to try to solve for might be to make adastrap builds reproducible. I think there are 4 files that have timestamps updated with every build. If that can be fixed, think there’s a good change to make build a bit more reproducible. Finally, I thought I saw some message in dmesg on about invalid syscalls or something like that on my end. Do you see the same? I will have to dig through my logs to find the message. Wondering what the cause is. I think it’s with every version of gcc I’ve looked at recently (ie 8.x and 9.x series).
Re: Enable TLS 1.3 in ruby 2.7
On 08/18 05:17, Aaron Bieber wrote: > On Tue, 18 Aug 2020 at 15:41:16 -0700, Jeremy Evans wrote: > > On 08/18 04:17, Aaron Bieber wrote: > > > Hi Jeremy! > > > > > > Here is a diff tb@ was kind enough to smack together when I was trying to > > > track > > > down why TLS 1.3 was not available in ruby. > > > > > > I have tested on a few different machines with no ill effect. > > > > > > I also ran the tests which resulted in: > > > Finished tests in 1463.007495s, 14.3492 tests/s, 1858.9283 assertions/s. > > > 20993 tests, 2719626 assertions, 14 failures, 0 errors, 73 skips > > > > I'm OK adding this as long as it doesn't cause any regressions. > > > > What the results you are getting for the tests without this patch? I > > would expect some failures, as I know I've made changes to the ruby > > master branch to fix issues in OpenBSD-current, and those fixes would > > not be present in Ruby 2.7.1. However, if anything additional breaks, > > we need to investigate and determine if it is an issue with the tests > > or a regression that needs to be addressed. > > Results actually look better with the patch! > > Before: > > Finished tests in 896.442532s, 23.4204 tests/s, 3034.9296 assertions/s. > 20995 tests, 2720640 assertions, 16 failures, 0 errors, 78 skips That's great. OK jeremy@. It's a good time to get this in as it will allow for testing before OpenBSD 6.8. Thanks, Jeremy
回复: [Update] databases/py-peewee: Update to 3.13.3
ping ... 发件人: owner-po...@openbsd.org 代表 wen heping 发送时间: 2020年8月4日 12:25 收件人: ports@openbsd.org 主题: [Update] databases/py-peewee: Update to 3.13.3 Hi, ports@: Here is a patch for databases/py-peewee: i) Update to 3.13.3 ii) Add py-psycopg2 as TEST_DEPENDS It build well and run well and pass the tests on amd64-current system, both with py2 and py3. No other ports depends on it. Cheers ! wen
Re: Enable TLS 1.3 in ruby 2.7
On Tue, 18 Aug 2020 at 15:41:16 -0700, Jeremy Evans wrote:
> On 08/18 04:17, Aaron Bieber wrote:
> > Hi Jeremy!
> >
> > Here is a diff tb@ was kind enough to smack together when I was trying to
> > track
> > down why TLS 1.3 was not available in ruby.
> >
> > I have tested on a few different machines with no ill effect.
> >
> > I also ran the tests which resulted in:
> > Finished tests in 1463.007495s, 14.3492 tests/s, 1858.9283 assertions/s.
> > 20993 tests, 2719626 assertions, 14 failures, 0 errors, 73 skips
>
> I'm OK adding this as long as it doesn't cause any regressions.
>
> What the results you are getting for the tests without this patch? I
> would expect some failures, as I know I've made changes to the ruby
> master branch to fix issues in OpenBSD-current, and those fixes would
> not be present in Ruby 2.7.1. However, if anything additional breaks,
> we need to investigate and determine if it is an issue with the tests
> or a regression that needs to be addressed.
Results actually look better with the patch!
Before:
Finished tests in 896.442532s, 23.4204 tests/s, 3034.9296 assertions/s.
20995 tests, 2720640 assertions, 16 failures, 0 errors, 78 skips
>
> Thanks,
> Jeremy
>
> >
> > And some irb action for good measure:
> >
> > qbit@tal[0]:~$ irb27
> > irb(main):001:0> require 'openssl'
> > => true
> > irb(main):002:0> OpenSSL::SSL::TLS1_3_VERSION
> > => 772
> > irb(main):003:0>
> >
> > I am also able to connect to Google via tls 1.3 using the below:
> >
> > #!/usr/bin/env ruby
> >
> > require 'socket'
> > require 'openssl'
> >
> > hostname = "google.com"
> >
> > ctx = OpenSSL::SSL::SSLContext.new()
> > s = TCPSocket.new(hostname, 443)
> > ssl = OpenSSL::SSL::SSLSocket.new(s, ctx)
> > ssl.hostname = hostname
> > ssl.connect
> >
> > p ssl.ssl_version
> > p ssl.peer_cert
> >
> > ssl.sync_close = true
> > ssl.close
> >
> > Any thoughts on adding this?
> >
> > Cheers,
> > Aaron
> >
> > diff refs/heads/master refs/heads/ruby_tls13
> > blob - 64d2b8a0f4fca132c9c60418a41b461a17901b8d
> > blob + 150b0490e7b3006ef7ddb581224adfbba400ed81
> > --- lang/ruby/2.7/Makefile
> > +++ lang/ruby/2.7/Makefile
> > @@ -6,7 +6,7 @@ SHARED_LIBS = ruby27 0.0
> > NEXTVER = 2.8
> > PKGSPEC-main ?= ruby->=2.7.0,<${NEXTVER}
> >
> > -REVISION-main =0
> > +REVISION-main =1
> >
> > PSEUDO_FLAVORS=no_ri_docs bootstrap
> > # Do not build the RI docs on slow arches
> > blob - /dev/null
> > blob + 795924e7187f8cdadc87117a475035ff9ed98273 (mode 644)
> > --- /dev/null
> > +++ lang/ruby/2.7/patches/patch-ext_openssl_ossl_ssl_c
> > @@ -0,0 +1,16 @@
> > +$OpenBSD$
> > +
> > +Index: ext/openssl/ossl_ssl.c
> > +--- ext/openssl/ossl_ssl.c.orig
> > ext/openssl/ossl_ssl.c
> > +@@ -13,6 +13,10 @@
> > +
> > + #define numberof(ary) (int)(sizeof(ary)/sizeof((ary)[0]))
> > +
> > ++#ifndef TLS1_3_VERSION
> > ++# define TLS1_3_VERSION 0x0304
> > ++#endif
> > ++
> > + #ifdef _WIN32
> > + # define TO_SOCKET(s) _get_osfhandle(s)
> > + #else
Re: Enable TLS 1.3 in ruby 2.7
On 08/18 04:17, Aaron Bieber wrote:
> Hi Jeremy!
>
> Here is a diff tb@ was kind enough to smack together when I was trying to
> track
> down why TLS 1.3 was not available in ruby.
>
> I have tested on a few different machines with no ill effect.
>
> I also ran the tests which resulted in:
> Finished tests in 1463.007495s, 14.3492 tests/s, 1858.9283 assertions/s.
> 20993 tests, 2719626 assertions, 14 failures, 0 errors, 73 skips
I'm OK adding this as long as it doesn't cause any regressions.
What the results you are getting for the tests without this patch? I
would expect some failures, as I know I've made changes to the ruby
master branch to fix issues in OpenBSD-current, and those fixes would
not be present in Ruby 2.7.1. However, if anything additional breaks,
we need to investigate and determine if it is an issue with the tests
or a regression that needs to be addressed.
Thanks,
Jeremy
>
> And some irb action for good measure:
>
> qbit@tal[0]:~$ irb27
> irb(main):001:0> require 'openssl'
> => true
> irb(main):002:0> OpenSSL::SSL::TLS1_3_VERSION
> => 772
> irb(main):003:0>
>
> I am also able to connect to Google via tls 1.3 using the below:
>
> #!/usr/bin/env ruby
>
> require 'socket'
> require 'openssl'
>
> hostname = "google.com"
>
> ctx = OpenSSL::SSL::SSLContext.new()
> s = TCPSocket.new(hostname, 443)
> ssl = OpenSSL::SSL::SSLSocket.new(s, ctx)
> ssl.hostname = hostname
> ssl.connect
>
> p ssl.ssl_version
> p ssl.peer_cert
>
> ssl.sync_close = true
> ssl.close
>
> Any thoughts on adding this?
>
> Cheers,
> Aaron
>
> diff refs/heads/master refs/heads/ruby_tls13
> blob - 64d2b8a0f4fca132c9c60418a41b461a17901b8d
> blob + 150b0490e7b3006ef7ddb581224adfbba400ed81
> --- lang/ruby/2.7/Makefile
> +++ lang/ruby/2.7/Makefile
> @@ -6,7 +6,7 @@ SHARED_LIBS = ruby27 0.0
> NEXTVER =2.8
> PKGSPEC-main ?= ruby->=2.7.0,<${NEXTVER}
>
> -REVISION-main = 0
> +REVISION-main = 1
>
> PSEUDO_FLAVORS= no_ri_docs bootstrap
> # Do not build the RI docs on slow arches
> blob - /dev/null
> blob + 795924e7187f8cdadc87117a475035ff9ed98273 (mode 644)
> --- /dev/null
> +++ lang/ruby/2.7/patches/patch-ext_openssl_ossl_ssl_c
> @@ -0,0 +1,16 @@
> +$OpenBSD$
> +
> +Index: ext/openssl/ossl_ssl.c
> +--- ext/openssl/ossl_ssl.c.orig
> ext/openssl/ossl_ssl.c
> +@@ -13,6 +13,10 @@
> +
> + #define numberof(ary) (int)(sizeof(ary)/sizeof((ary)[0]))
> +
> ++#ifndef TLS1_3_VERSION
> ++# define TLS1_3_VERSION 0x0304
> ++#endif
> ++
> + #ifdef _WIN32
> + # define TO_SOCKET(s) _get_osfhandle(s)
> + #else
Enable TLS 1.3 in ruby 2.7
Hi Jeremy!
Here is a diff tb@ was kind enough to smack together when I was trying to track
down why TLS 1.3 was not available in ruby.
I have tested on a few different machines with no ill effect.
I also ran the tests which resulted in:
Finished tests in 1463.007495s, 14.3492 tests/s, 1858.9283 assertions/s.
20993 tests, 2719626 assertions, 14 failures, 0 errors, 73 skips
And some irb action for good measure:
qbit@tal[0]:~$ irb27
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> OpenSSL::SSL::TLS1_3_VERSION
=> 772
irb(main):003:0>
I am also able to connect to Google via tls 1.3 using the below:
#!/usr/bin/env ruby
require 'socket'
require 'openssl'
hostname = "google.com"
ctx = OpenSSL::SSL::SSLContext.new()
s = TCPSocket.new(hostname, 443)
ssl = OpenSSL::SSL::SSLSocket.new(s, ctx)
ssl.hostname = hostname
ssl.connect
p ssl.ssl_version
p ssl.peer_cert
ssl.sync_close = true
ssl.close
Any thoughts on adding this?
Cheers,
Aaron
diff refs/heads/master refs/heads/ruby_tls13
blob - 64d2b8a0f4fca132c9c60418a41b461a17901b8d
blob + 150b0490e7b3006ef7ddb581224adfbba400ed81
--- lang/ruby/2.7/Makefile
+++ lang/ruby/2.7/Makefile
@@ -6,7 +6,7 @@ SHARED_LIBS = ruby27 0.0
NEXTVER = 2.8
PKGSPEC-main ?= ruby->=2.7.0,<${NEXTVER}
-REVISION-main =0
+REVISION-main =1
PSEUDO_FLAVORS=no_ri_docs bootstrap
# Do not build the RI docs on slow arches
blob - /dev/null
blob + 795924e7187f8cdadc87117a475035ff9ed98273 (mode 644)
--- /dev/null
+++ lang/ruby/2.7/patches/patch-ext_openssl_ossl_ssl_c
@@ -0,0 +1,16 @@
+$OpenBSD$
+
+Index: ext/openssl/ossl_ssl.c
+--- ext/openssl/ossl_ssl.c.orig
ext/openssl/ossl_ssl.c
+@@ -13,6 +13,10 @@
+
+ #define numberof(ary) (int)(sizeof(ary)/sizeof((ary)[0]))
+
++#ifndef TLS1_3_VERSION
++# define TLS1_3_VERSION 0x0304
++#endif
++
+ #ifdef _WIN32
+ # define TO_SOCKET(s) _get_osfhandle(s)
+ #else
Re: update net/libtorrent-rasterbar 1.2.8
On 8/17/2020 9:51 PM, Nam Nguyen wrote: Nam Nguyen writes: This is a diff for an update to net/libtorrent-rasterbar 1.2.8, released on August 4, 2020. This new diff applies cleanly now that rsadsowski@ updated devel/boost to 1.67.0. It also uses -mt variants of boost_system-mt and boost_python38-mt. Reasons: - cmake build uses -mt variants for both - I was getting undefined symbols with 1.2.8 + system-mt + python38 (non-mt). 1.2.3 + system-mt + python38 (non-mt), as it is currently in the ports tree, works, however. $ python3 Python 3.8.5 (default, Aug 13 2020, 13:09:39) [Clang 10.0.1 ] on openbsd6 Type "help", "copyright", "credits" or "license" for more information. import libtorrent python3:/usr/local/lib/python3.8/site-packages/libtorrent.so: undefined symbol '_ZTIN10libtorrent12socks5_alertE' python3:/usr/local/lib/python3.8/site-packages/libtorrent.so: undefined symbol '_ZN10libtorrent9peer_infoC1ERKS0_' python3:/usr/local/lib/python3.8/site-packages/libtorrent.so: undefined symbol '_ZN10libtorrent9peer_infoD1Ev' python3:/usr/local/lib/python3.8/site-packages/libtorrent.so: undefined symbol '_ZN10libtorrent9peer_infoC1Ev' Traceback (most recent call last): File "", line 1, in ImportError: Cannot load specified object changelog: https://github.com/arvidn/libtorrent/blob/libtorrent-1.2.8/ChangeLog base-clang 10.0.1 unbreaks libtorrent-rasterbar. This diff is based on rsadowski@'s devel/boost 1.67.0 update. https://marc.info/?l=openbsd-ports&m=159566156026888&w=2 This diff: - is based on rsadowski@'s devel/boost 1.67.0 update, which moves from boost_python3 to boost_python38. rsadowski@ uses MODPY_VERSION here in naming WANTLIB and CONFIGURE_ARGS - updates to 1.2.8 - bumps library major due to symbol deletion - adds a license marker for ConvertUTF.cpp, slated to be removed in upcoming 1.2.9 - changes MASTER_SITES to properly download the new release - specifies devel/boost>=1.67.0 - uses non-mt variants of both boost_system and boost_python38 uses mt variants of libboost_system-mt and libboost_python38-mt - links to -liconv (libiconv.so.7.0) instead of libiconv.a - regens WANTLIB with boost_python38, boost_system (non-mt) and iconv python bindings === lboost_python38 and lboost_system = works lboost_python38-mt and lboost_system-mt = works nonmatching -mt = broken When they were nonmatching -mt as in rsadowski@'s boost update, I had two outcomes: - more recently, SIGILL on deluge startup - update-plist in deluge: Warning: libtorrent (libtorrent-rasterbar) not found: Cannot load specified object ===> Faking installation for deluge-2.0.3p1 I can no longer reproduce the latter since moving from ports-clang back to base-clang. I now always get the SIGILL with nonmatching -mt. To resolve make sure that _system and _python are matching -mt or non-mt. I have an experimental cmake build where cmake uses -lboost_python38-mt and -lboost_system-mt in building python bindings (bindings/python/libtorrent.so). See the first half of the log file. It works. The second half of the log file shows the autohell Makefile using -lboost_system-mt and -lboost_python38, which was broken. log file: https://www.namtsui.com/public/pythonbindings.txt upstream states that boost build (b2) > cmake > autohell for reliably building libtorrent python bindings (libtorrent.so). autohell is removed altogether in the libtorrent 2 branch, unrelated to 1.2.8. Moving to cmake is an option but not necessary. iconv = libiconv.a is always preferred by autohell over libiconv.so.7.0. I replace all generated Makefiles using iconv.a (second half of log file) with -liconv (first half of log file). Specifically, I deleted /usr/local/lib/libiconv.a so that it could only find libiconv.so.7.0. The result is printed in the first half of log file. log file: https://www.namtsui.com/public/iconv.txt make port-lib-depends-check is happy and iconv is now added to WANTLIB. This is hacky. Other options: - move to cmake, which finds -liconv - use libiconv.a and remove this Licensing = debian removed libtorrent-rasterbar because ConvertUTF8.cpp has a special Unicode, Inc., license. Is it fine to leave PERMIT_PACKAGE as is, since upstream will remove it in the upcoming 1.2.9? https://github.com/arvidn/libtorrent/pull/4966 https://github.com/arvidn/libtorrent/issues/4951 Major bump == 1. I referenced "CMakeLists.txt: set (SOVERSION "10")" to keep # 10.0.0 as kn@ had done with a previous update. 2. has_udp_outgoing-sockets() (see 1.2.3's include/libtorrent/aux_/session_impl.hpp:731) has been removed in 1.2.8. This symbol deletion is enough for bumping major. 3. Changelog also says, "deprecate broadcast_lsd setting. Just use multicast" - include/libtorrent/settings_pack.hpp settings_pack struct in 1.2.3 used to have broadcast_lsd: // if ``broadcast_lsd`` is set to true, the local peer discovery (or // Local Service Discovery) will not only use IP multicast, but also // broadcast
Re: [UPDATE FROM MAINTAINER]: games/freeorion
Hi Rafael, On 2020-08-18 05:29, Rafael Sadowski wrote: On Tue Aug 18, 2020 at 08:22:47AM +0300, Kirill Bychkov wrote: On Tue, August 18, 2020 08:10, Rafael Sadowski wrote: > On Sun Aug 02, 2020 at 11:18:44AM +0100, Tom Murphy wrote: >> Hi, >> >> This update brings games/freeorion to 0.4.10. The game now relies >> on Python 3 instead of Python 2. >> >> Compiles and runs fine here. There is a bug with their >> make_versioncpp.py utility which adds the version data based on a >> git commit, however the release source code of course contains no >> .git data. I've raised this as a bug here: >> >> https://github.com/freeorion/freeorion/issues/3129 >> >> OK? >> >> Thanks, >> Tom > > Your diff needs an update after the latest boost update. > >> It was updated before boost [1] and than fixed by you [2] :) [1] https://marc.info/?l=openbsd-ports-cvs&m=159696583926972&w=2 [2] https://marc.info/?l=openbsd-ports-cvs&m=159752347527449&w=2 Perfect, so sorry for the noise. It should work with both 1.66 and 1.67, but the newer boost is better to have, I think! -Tom
Re: UPDATE: GCC 8.4.0
On Sat, Mar 14, 2020 at 03:58:12AM -0400, Brad Smith wrote:
> Here is a start at an update to GCC 8.4.0.
>
> I e-mailed Pascal 10 days ago but no response.
Added the version bump for LLVM.
Has been run through a bulk build on sparc64 without issue.
Index: lang/gcc/8/Makefile
===
RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.32
diff -u -p -u -p -r1.32 Makefile
--- lang/gcc/8/Makefile 8 Aug 2020 16:48:48 - 1.32
+++ lang/gcc/8/Makefile 9 Aug 2020 03:18:29 -
@@ -15,17 +15,16 @@ USE_LLD = No
DPB_PROPERTIES = parallel
-V = 8.3.0
-REVISION = 6
+V = 8.4.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
-ADASTRAP-amd64 = adastrap-amd64-$V-2.tar.xz
+ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
-ADASTRAP-hppa = adastrap-hppa-$V-1.tar.xz
-ADASTRAP-i386 = adastrap-i386-$V-2.tar.xz
-ADASTRAP-mips64 = adastrap-mips64-$V-1.tar.xz
-ADASTRAP-powerpc = adastrap-powerpc-$V-2.tar.xz
+ADASTRAP-hppa = adastrap-hppa-8.3.0-1.tar.xz
+ADASTRAP-i386 = adastrap-i386-8.3.0-2.tar.xz
+ADASTRAP-mips64 = adastrap-mips64-8.3.0-1.tar.xz
+ADASTRAP-powerpc = adastrap-powerpc-8.3.0-2.tar.xz
ADASTRAP-sparc64 = adastrap-sparc64-6.5.0-0.tar.xz
PKGNAME-main = gcc-${FULL_PKGVERSION}
Index: lang/gcc/8/distinfo
===
RCS file: /home/cvs/ports/lang/gcc/8/distinfo,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 distinfo
--- lang/gcc/8/distinfo 3 Dec 2019 21:18:26 - 1.10
+++ lang/gcc/8/distinfo 4 Mar 2020 15:07:14 -
@@ -5,7 +5,7 @@ SHA256 (gcc/adastrap-i386-8.3.0-2.tar.xz
SHA256 (gcc/adastrap-mips64-8.3.0-1.tar.xz) =
0KoMJYD/HZO/b9H0d7oBxYxN/NLfgnb5tug9v0mpu3o=
SHA256 (gcc/adastrap-powerpc-8.3.0-2.tar.xz) =
agAk8BvVOlwvIygLlg22GZq36+55n+exWUqKFk4wC7A=
SHA256 (gcc/adastrap-sparc64-6.5.0-0.tar.xz) =
cqpGS2beYV+CFf7X+P4voVHHT78v6SCgtksHXjP/B4E=
-SHA256 (gcc/gcc-8.3.0.tar.xz) = ZLqt/mzA9JR6hMsS1/Dfr0W7WLfpJGFjlZbCHgLZfSw=
+SHA256 (gcc/gcc-8.4.0.tar.xz) = 4wpuUtEOHyftVRBK0jPDC9HpnPtf+YqwItyUHt0bLdQ=
SIZE (gcc/adastrap-amd64-8.3.0-2.tar.xz) = 58534592
SIZE (gcc/adastrap-arm-4.9.4-0.tar.xz) = 31142168
SIZE (gcc/adastrap-hppa-8.3.0-1.tar.xz) = 48044496
@@ -13,4 +13,4 @@ SIZE (gcc/adastrap-i386-8.3.0-2.tar.xz)
SIZE (gcc/adastrap-mips64-8.3.0-1.tar.xz) = 49736364
SIZE (gcc/adastrap-powerpc-8.3.0-2.tar.xz) = 53062880
SIZE (gcc/adastrap-sparc64-6.5.0-0.tar.xz) = 38704976
-SIZE (gcc/gcc-8.3.0.tar.xz) = 63694700
+SIZE (gcc/gcc-8.4.0.tar.xz) = 63713440
Index: lang/gcc/8/patches/patch-fixincludes_fixincl_x
===
RCS file: /home/cvs/ports/lang/gcc/8/patches/patch-fixincludes_fixincl_x,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-fixincludes_fixincl_x
--- lang/gcc/8/patches/patch-fixincludes_fixincl_x 4 Jan 2019 15:50:39
- 1.1.1.1
+++ lang/gcc/8/patches/patch-fixincludes_fixincl_x 4 Mar 2020 16:15:17
-
@@ -2,7 +2,7 @@ $OpenBSD: patch-fixincludes_fixincl_x,v
Index: fixincludes/fixincl.x
--- fixincludes/fixincl.x.orig
+++ fixincludes/fixincl.x
-@@ -7019,11 +7019,11 @@ static const char* apzSolaris_Complex_CxxPatch[] = { s
+@@ -7276,11 +7276,11 @@ static const char* apzSolaris_Complex_CxxPatch[] = { s
"-e", "/#if[ \t]*!defined(__cplusplus)/c\\\n\
#ifdef\t__cplusplus\\\n\
extern \"C\" {\\\n\
Index: lang/gcc/8/patches/patch-fixincludes_inclhack_def
===
RCS file: /home/cvs/ports/lang/gcc/8/patches/patch-fixincludes_inclhack_def,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-fixincludes_inclhack_def
--- lang/gcc/8/patches/patch-fixincludes_inclhack_def 4 Jan 2019 15:50:40
- 1.1.1.1
+++ lang/gcc/8/patches/patch-fixincludes_inclhack_def 4 Mar 2020 16:14:34
-
@@ -2,7 +2,7 @@ $OpenBSD: patch-fixincludes_inclhack_def
Index: fixincludes/inclhack.def
--- fixincludes/inclhack.def.orig
+++ fixincludes/inclhack.def
-@@ -3490,9 +3490,9 @@ fix = {
+@@ -3621,9 +3621,9 @@ fix = {
mach = "*-*-solaris2.*";
files = complex.h;
sed = "/#if[ \t]*!defined(__cplusplus)/c\\\n"
Index: lang/gcc/8/patches/patch-gcc_Makefile_in
===
RCS file: /home/cvs/ports/lang/gcc/8/patches/patch-gcc_Makefile_in,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 patch-gcc_Makefile_in
--- lang/gcc/8/patches/patch-gcc_Makefile_in4 Jan 2019 15:50:39 -
1.1.1.1
+++ lang/gcc/8/patches/patch-gcc_Makefile_in4 Mar 2020 16:14:34 -
@@ -24,7 +24,7 @@ Index: gcc/Makefile.in
# Native compiler that we use. This may be C++ some day.
COMPILER_FOR_BUILD = $(CXX_FOR_BUILD)
-@@ -2195,6 +2190,12 @@ DRIVER_DEFINES = \
+@@ -2196,6 +2191,12 @@ DRIVER_DEFINES = \
CFLAGS-gcc.o += $(DRIVER_DEFINES) -DBASEVER=$(BASEVER_s)
gcc.o: $(BASEVER)
LLVM 10: build failures on amd64 2020-08-17
The remaining build failures on amd64 due to the LLVM 10 update: devel/py-llvmlite,python3 needs update to 0.34.0 games/fs2open print/scribus productivity/aqbanking Logs: http://build-failures.rhaalovely.net/amd64/2020-08-07/ -- Christian "naddy" Weisgerber na...@mips.inka.de
[macppc] Mark emulators/advancemame BROKEN
Hi, As seen on the current macppc bulk: > emulators/advancemame(build) [55003] on macppc-1 4% frozen for 32 > HOURS! I would like to see it marked BROKEN, since no usual suspect is present here (and we don't distribute the package anyway). I'm sharing the log [0] if someone is interested. OK? Charlène. [0] https://bin.charlenew.xyz/advancemame.log Index: Makefile === RCS file: /cvs/ports/emulators/advancemame/Makefile,v retrieving revision 1.17 diff -u -p -u -p -r1.17 Makefile --- Makefile15 Apr 2020 13:31:42 - 1.17 +++ Makefile18 Aug 2020 17:59:28 - @@ -1,5 +1,7 @@ # $OpenBSD: Makefile,v 1.17 2020/04/15 13:31:42 fcambus Exp $ +BROKEN-powerpc = clang-10 hangs indefinitely + COMMENT = MAME port with advanced video support for monitors and TVs V =3.9
Re: i386 failures
On 2020-08-18, Stuart Henderson wrote: > build failures: 12 These are the actual i386 failures: > audio/mscore: out of memory linking > devel/cutter: narrowing from type 'const unsigned long long' to 'size_t' (aka > 'unsigned long') > devel/geany: linking (scintilla) > geo/pgrouting: ICE (log below) The ones below also happen on amd64: > devel/py-llvmlite: llvm mismatch (all archs) > games/fs2open: no matching constructor for initialization of > 'std::unique_lock' > graphics/openexr: picks up wrong numpy; possibly related to boost update or > openexr update (log below) > print/scribus: no viable overloaded '=' > productivity/aqbanking: linker missing symbols (as amd64) Already fixed: > devel/intellij: patch error (all archs, since fixed) > x11/gnustep/back: (as amd64) > x11/gnustep/renaissance: (as amd64) -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [macppc] Unbreak devel/geany
On Thu, 11 Jun 2020 15:15:34 +0200
Charlene Wendling wrote:
> Hi,
>
> > http://build-failures.rhaalovely.net/powerpc/2020-05-09/devel/geany.log
>
> It's a wild guess, but i think it wants a template with a long
> argument because on macppc:
>
> $ c++ -dM -E - < /dev/null | grep PTRDIFF_MAX
> #define __PTRDIFF_MAX__ 2147483647L
> $ c++ -dM -E - < /dev/null | grep INT_MAX
> #define __INT_MAX__ 2147483647
>
> Either way, the below diff fixes the build on macppc, the runtime is
> fine [0] as well. While here i've moved HOMEPAGE to https.
>
> [...}
>
> Charlène.
>
>
> [0] https://bsd.network/@julianaito/104325481078218916
>
>
Since i386 is impacted as well, here is a variant heavily hinted by
sthen@. This builds fine on macppc.
Index: Makefile
===
RCS file: /cvs/ports/devel/geany/Makefile,v
retrieving revision 1.63
diff -u -p -u -p -r1.63 Makefile
--- Makefile16 Oct 2019 06:51:42 - 1.63
+++ Makefile18 Aug 2020 17:49:13 -
@@ -3,11 +3,12 @@
COMMENT= small and lightweight IDE
DISTNAME = geany-1.36
+REVISION = 0
SHARED_LIBS += geany 0.0 # 0.0
CATEGORIES=devel
-HOMEPAGE= http://www.geany.org/
+HOMEPAGE= https://www.geany.org/
MAINTAINER=Victor Kukshiev
Index: patches/patch-scintilla_src_RunStyles_cxx
===
RCS file: patches/patch-scintilla_src_RunStyles_cxx
diff -N patches/patch-scintilla_src_RunStyles_cxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-scintilla_src_RunStyles_cxx 18 Aug 2020 17:49:13 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+i386/powerpc fix for
+"undefined reference to Scintilla::RunStyles::RunStyles()"
+
+Index: scintilla/src/RunStyles.cxx
+--- scintilla/src/RunStyles.cxx.orig
scintilla/src/RunStyles.cxx
+@@ -308,7 +308,8 @@ void RunStyles::Check() const {
+
+ template class Scintilla::RunStyles;
+ template class Scintilla::RunStyles;
+-#if (PTRDIFF_MAX != INT_MAX) || PLAT_HAIKU
++#if (PTRDIFF_MAX != INT_MAX) || PLAT_HAIKU || \
++( defined(__OpenBSD__) && defined(_ILP32) )
+ template class Scintilla::RunStyles;
+ template class Scintilla::RunStyles;
+ #endif
i386 failures
started at 1597609947 Sun Aug 16 14:32:27 MDT 2020 finished at 1597752003 Tue Aug 18 06:00:03 MDT 2020 report generated at 1597758739 Tue Aug 18 07:52:20 MDT 2020 total 39h27m done with kern.version=OpenBSD 6.7-current (GENERIC.MP) #0: Sun Aug 16 14:12:40 MDT 2020 built packages 10554 build restarts: (manual restarts to pick up fixes, finally succeeded) 3 devel/boost 2 devel/rttr build failures: 12 audio/mscore: out of memory linking devel/cutter: narrowing from type 'const unsigned long long' to 'size_t' (aka 'unsigned long') devel/geany: linking (scintilla) devel/intellij: patch error (all archs, since fixed) devel/py-llvmlite: llvm mismatch (all archs) games/fs2open: no matching constructor for initialization of 'std::unique_lock' geo/pgrouting: ICE (log below) graphics/openexr: picks up wrong numpy; possibly related to boost update or openexr update (log below) print/scribus: no viable overloaded '=' productivity/aqbanking: linker missing symbols (as amd64) x11/gnustep/back: (as amd64) x11/gnustep/renaissance: (as amd64) ==> failures/geo/pgrouting.log <== ^ /pobj/pgrouting-3.1.0/pgrouting-3.1.0/include/c_common/postgres_connection.h:102:26: warning: pragma diagnostic pop could not pop, no matching push [-Wunknown-pragmas] #pragma clang diagnostic pop ^ fatal error: error in backend: Cannot select: 0x576e5800: i32,ch = X86ISD::STRICT_FCMPS 0x456ce080, 0x30b49d40, 0x576e5740 0x30b49d40: f64,ch = X86ISD::FILD<(load 4 from %stack.5)> 0x380ed380, FrameIndex:i32<5> 0x380ede40: i32 = FrameIndex<5> 0x576e5740: f64,ch = load<(load 8 from %ir.203, align 4)> 0x380ed580, 0x30b49300, undef:i32 0x30b49300: i32 = add 0x30b49280, Constant:i32<-40> 0x30b49280: i32 = add 0x576e55c0, 0x485e4540 0x576e55c0: i32,ch = CopyFromReg 0x43e08034, Register:i32 %25 0x380edf40: i32 = Register %25 0x485e4540: i32 = shl 0x380ed680, Constant:i8<2> 0x380ed680: i32,ch = CopyFromReg 0x43e08034, Register:i32 %23 0x576e5d40: i32 = Register %23 0x456ce380: i8 = Constant<2> 0x456ce840: i32 = Constant<-40> 0x456ce280: i32 = undef In function: get_edges_9_columns Stack dump: 0. Program arguments: /usr/bin/cc -B /pobj/pgrouting-3.1.0/bin -DPGROUTING_VERSION="3.1.0" -DPGSQL_VERSION=123 -I/usr/local/include/postgresql/server -I/usr/local/include -I/pobj/pgrouting-3.1.0/pgrouting-3.1.0/include -O2 -pipe -std=gnu99 -fPIC -frounding-math -DNDEBUG -MD -MT src/common/CMakeFiles/common.dir/edges_input.c.o -MF src/common/CMakeFiles/common.dir/edges_input.c.o.d -o src/common/CMakeFiles/common.dir/edges_input.c.o -c /pobj/pgrouting-3.1.0/pgrouting-3.1.0/src/common/edges_input.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/pobj/pgrouting-3.1.0/pgrouting-3.1.0/src/common/edges_input.c'. 4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@get_edges_9_columns' cc: error: clang frontend command failed with exit code 70 (use -v to see invocation) OpenBSD clang version 10.0.1 Target: i386-unknown-openbsd6.7 Thread model: posix InstalledDir: /usr/bin cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. cc: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: cc: note: diagnostic msg: /tmp/edges_input-589099.c cc: note: diagnostic msg: /tmp/edges_input-589099.sh cc: note: diagnostic msg: ninja: build stopped: subcommand failed. >>> Ended at 1597740190.14 ==> failures/graphics/openexr.log <== FAILED: PyIlmBase/PyImathNumpy/CMakeFiles/imathnumpy_python2.dir/imathnumpymodule.cpp.o /pobj/openexr-2.5.3/bin/c++ -Dimathnumpy_python2_EXPORTS -IPyIlmBase/PyImathNumpy -I/pobj/openexr-2.5.3/openexr-2.5.3/PyIlmBase/PyImathNumpy -I/pobj/openexr-2.5.3/openexr-2.5.3/IlmBase/Iex -IIlmBase/config -I/pobj/openexr-2.5.3/openexr-2.5.3/IlmBase/IexMath -I/pobj/openexr-2.5.3/openexr-2.5.3/IlmBase/Imath -I/pobj/openexr-2.5.3/openexr-2.5.3/IlmBase/Half -I/pobj/openexr-2.5.3/openexr-2.5.3/PyIlmBase/PyIex -I/pobj/openexr-2.5.3/openexr-2.5.3/PyIlmBase/PyImath -IPyIlmBase/config -isystem /usr/local/include/python2.7 -isystem /usr/local/include -isystem /usr/local/lib/python2.7/site-packages/numpy/core/include -O2 -pipe -DNDEBUG -fPIC -MD -MT PyIlmBase/PyImathNumpy/CMakeFiles/imathnumpy_python2.dir/imathnumpymodule.cpp.o -MF PyIlmBase/PyImathNumpy/CMakeFiles/imathnumpy_python2.dir/imathnumpymodule.cpp.o.d -o PyIlmBase/PyImathNumpy/CMakeFiles/imathnumpy_python2.dir/imathnumpymodule.cpp.o -c /pobj/openexr-2.5.3/openexr-2.5.3/PyIlmBase/PyImathNumpy/imathnumpymodule.cpp /pobj/openexr-2.5.3/openexr-2.5.3/PyIlmBase/PyImathNumpy/imathnumpymodule.cpp:42:10: fatal error: 'numpy/ar
[update patch] nnn 3.3 -> 3.4
This patch updates nnn from 3.3 to 3.4.
Tested on two amd64 systems.
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile14 Jul 2020 16:52:25 - 1.10
+++ Makefile18 Aug 2020 11:38:38 -
@@ -2,7 +2,7 @@
COMMENT = the missing terminal file browser for X
-V =3.3
+V =3.4
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/nnn/distinfo,v
retrieving revision 1.7
diff -u -p -r1.7 distinfo
--- distinfo14 Jul 2020 16:52:25 - 1.7
+++ distinfo18 Aug 2020 11:38:38 -
@@ -1,2 +1,2 @@
-SHA256 (nnn-v3.3.tar.gz) = FrJFz5hNgafjXxpqb1K+3kgQeE8GB01pNp9mTv3zKso=
-SIZE (nnn-v3.3.tar.gz) = 148795
+SHA256 (nnn-v3.4.tar.gz) = eAOubpdK60AIUH2dGvvMqNCEpDXzb/Y2tFnKUEFJMKE=
+SIZE (nnn-v3.4.tar.gz) = 194844
Re: p5-gtk3 / Gtk3.pm
On 18/08 08:44 , Stuart Henderson wrote: > On 2020/08/18 09:00, su.root wrote: > > During compilation from source I receive the following error > > http://ix.io/2u20 . > > I was unable to locate p5-gtk3 in ports and just wanted to check if > > there is work around to resolving the compilation issue in this case. > > Thxs! > > > > It is not yet in ports. Here's a quick port I threw together (by > running "portgen p5 Gtk3" plus light tweaking). > Thxs Stuart!
Re: [NEW] cad/cura - Ultimake Cura + dependencies
On 2020/08/18 11:29, Stuart Henderson wrote:
> > * devel/libSavitar
> > * net/libArcus
> > * net/libCharon
>
> all lowercase for these port names please
>
other comments: (paco's are generally good too)
- all the ultimaker distfiles have the same version 4.6.2 which implies
that they probably want updating together, it might be easier to do that
if they're grouped e.g. cad/ultimaker/{cura,cura-engine,fdm_materials,...}
- SHARED_LIBS should all start with 0.0 for new ports. if the ports don't
honour that setting in the files they produce, that needs correcting.
- libCharon should use MODULES=lang/python and the python-related variables
in PLIST etc. the python module messes about with CONFIGURE_STYLE, you can
avoid that with CONFIGURE_STYLE=none
> * devel/py-trimesh
> * No need for that NEEDED_DEPENDS. Define BUILD_DEPENDS and later
> RUN_DEPENDS = ${BUILD_DEPENDS}
ah, this is wrong, BUILD_DEPENDS can have other things added to it (ccache,
build tools, etc), RUN_DEPENDS should not be set based on it.
one of them has cython as a run dep; haven't looked closer but this is
normally something that would be a build dep
there are various ones with constructs like
V= 1.23
GH_TAGNAME= ${V}
DISTNAME= bar-${V}
and some others with an additional variable; much of this is not needed,
if you do this
GH_ACCOUNT= foo
GH_PROJECT= bar
GH_TAGNAME= v1.23
the following vars are set automatically and it's better not to explicitly
set them:
DISTNAME= bar-1.23(auto strips the 'v')
HOMEPAGE= https://github.com/foo/bar
and where you have mixed-case ones that need lower-casing you can do e.g.
GH_PROJECT= libBar
PKGNAME=${DISTNAME:L}
some of the ultimaker port PKGNAMEs end up mixed-case as well, those should
be lowered too
p5-gtk3 / Gtk3.pm
During compilation from source I receive the following error http://ix.io/2u20 . I was unable to locate p5-gtk3 in ports and just wanted to check if there is work around to resolving the compilation issue in this case. Thxs!
Re: [NEW] cad/cura - Ultimake Cura + dependencies
> * devel/libSavitar > * net/libArcus > * net/libCharon all lowercase for these port names please
Re: [NEW] cad/cura - Ultimake Cura + dependencies
Hi Evandro,
On Sun, 16 Aug 2020, Evandro Rathke wrote:
> Hi folks!
> I hope everyone is going well.
>
> This is the port for Ultimaker Cura. Is an update for the latest stable
> version available.
> More info: https://gitlab.com/erathke/cura-port
>
> Please, let me know if you have any issues.
First of all, thanks for your work on this. It seems quite an effort
you took there.
I did not have the time to test it all yet, but I took a peek at your
ports. Here are some comments and suggestions you should take a look.
More experienced porters may add/clarify stuff I say below.
Be patient, this is a lot of new ports in one go and review them takes
time.
So, a general comment, why not taking maintainer ? This is a huge thing
that can rot very quickly. It's not absolutely necessary, but make it
clear that you will take care of those ports make it more likely to get
imported.
For the py ports, you did not set MODPY_PYTEST. Have you tried
regression tests for any of them ?
Then, some comments on the ports themselves:
* cad/cura
* MODULES goes before depends (check the Makefile template).
* RUN_DEPENDS needs reorganization. Alphabetically, first by
category then by port name.
* py ports on *_DEPENDS don't need the ',' before MODPY_FLAVOR
* FLAVOR does not need the '+'
* cad/cura-engine
* MODULES goes before depends (check template).
* RUN_DEPENDS needs reorganization
* cad/fdm_materials
* seems good at first sight.
* cad/uranium
* RUN_DEPENDS needs reorganization
* FLAVOR does not need the '?'. New ports py3 only, please.
* py ports on *_DEPENDS don't need the ',' before MODPY_FLAVOR
* you may want to review `patches/patch-UM_Platform_py`. I think the
comment on `isOpenBSD` is copy/pasted from another method.
* also, comment your patches if possible, so somebody looking at
them knows why they are there.
* devel/libSavitar
* MODULES goes before depends (check template).
* FLAVOR does not need the '?'. New ports py3 only, please.
* py ports on *_DEPENDS don't need the ',' before MODPY_FLAVOR
* I think you need a SHARED_LIBS here (bsd.port.mk(5)).
* devel/py-colorlog
* FLAVOR does not need the '?'. New ports py3 only, please.
* devel/py-pycollada
* This is a library, I think it should follow the FLAVORS/FLAVOR schema
and make it explicitly py3 only.
* devel/py-trimesh
* No need for that NEEDED_DEPENDS. Define BUILD_DEPENDS and later
RUN_DEPENDS = ${BUILD_DEPENDS}
* In any case, dependencies need reorganization.
* FLAVOR does not need the '?'. New ports py3 only, please.
* devel/stb
* use ${INSTALL_DATA_DIR} instead of `mkdir -p`
* probably ${INSTALL_DATA} instead of cp
* who's that MAINTAINER ?
* math/fcl
* take a look at the order of variables. SHARED_LIBS goes further up,
MODULES too. Take the Makefile template for reference.
* math/libccd
* again, take a look at the template for variable order
* math/octomap
* again, take a look at the template for variable order
* math/py-fcl
* No need for that NEEDED_DEPENDS. I guess a bit of repeat here is
fine, deps list is short.
* In any case, dependencies need reorganization.
* FLAVOR does not need the '?'. New ports py3 only, please.
* math/py-triangle
* check PERMIT_PACKAGE and the license comment. This seems to be
LGPLv3. So PERMIT_DISTFILES is not needed.
* net/libArcus
* py ports on *_DEPENDS don't need the ',' before MODPY_FLAVOR
* FLAVOR does not need the '?'. New ports py3 only, please.
* again, take a look at the template for variable order
* look at SHARED_LIBS on bsd.port.mk(5). You should start with 0.0
* net/libCharon
* this one has some systemd references in PLIST. Can we get ride of
those or are they needed for something else ?
* security/py-xxhash
* FLAVOR does not need the '?'. New ports py3 only, please.
I'll probably give it all a try towards the end of the week.
It would be nice to have a modern slicer on ports :-)
Cheers,
--
Paco Esteban.
0x5818130B8A6DBC03
Re: rsync: update to 3.2.2
On 2020/07/23 16:31, Klemens Nanni wrote: > Lots of fixes and enhancements: > https://download.samba.org/pub/rsync/NEWS#3.2.2 I use rsync flags including this: --rsh 'ssh -o ControlPersist=5m -o ControlMaster=auto -o VisualHostKey=no' My script is lazy and sets --rsh for everything including local transfers. This used to work fine, but with 3.2.2 it breaks with "Overflow in read_varint()". Trigger seems to be an --rsh string including 'V': $ rsync --rsh 'V' -r /etc/motd /tmp/ Overflow in read_varint() rsync error: error in rsync protocol data stream (code 12) at /usr/obj/ports/rsync-3.2.2/rsync-3.2.2/io.c(1737) [sende r=3.2.2] $ rsync error: received SIGUSR1 (code 19) at /usr/obj/ports/rsync-3.2.2/rsync-3.2.2/main.c(1542) [Receiver=3.2.2]
Re: p5-gtk3 / Gtk3.pm
On 2020/08/18 09:00, su.root wrote: > During compilation from source I receive the following error > http://ix.io/2u20 . > I was unable to locate p5-gtk3 in ports and just wanted to check if > there is work around to resolving the compilation issue in this case. > Thxs! > It is not yet in ports. Here's a quick port I threw together (by running "portgen p5 Gtk3" plus light tweaking). p5-Gtk3.tgz Description: application/tar-gz
UPDATE: games/openrct2 0.2.6 => 0.3.0
Hi ports --
Attached is an update to the newly released OpenRCT2 0.3.0.
The very big changelog is here:
https://github.com/OpenRCT2/OpenRCT2/releases/tag/v0.3.0
Works well on amd64.
OK?
~Brian
Index: Makefile
===
RCS file: /cvs/ports/games/openrct2/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile 26 May 2020 15:41:41 - 1.14
+++ Makefile 18 Aug 2020 02:57:22 -
@@ -3,7 +3,7 @@
# "#error Unknown endianess!" in src/openrct2/common.h
NOT_FOR_ARCHS = ${BE_ARCHS}
-V = 0.2.6
+V = 0.3.0
COMMENT = open source re-implementation of RollerCoaster Tycoon 2
DISTNAME = openrct2-${V}
CATEGORIES = games x11
@@ -14,7 +14,7 @@ MAINTAINER = Brian Callahan https://github.com/OpenRCT2/OpenRCT2/issues/5710
NO_TEST = Yes
+
+# Upstream changed the location to read title sequences from.
+# https://github.com/rdbaris/OpenRCT2/commit/2a00293d88bb38e65040cde42d9bf1e236ab
+post-extract:
+ mv ${WRKSRC}/data/title ${WRKSRC}/data/sequence
pre-configure:
sed -i 's,/usr/local,${TRUEPREFIX},g' \
Index: distinfo
===
RCS file: /cvs/ports/games/openrct2/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo 26 May 2020 15:41:41 - 1.5
+++ distinfo 18 Aug 2020 02:57:22 -
@@ -1,2 +1,2 @@
-SHA256 (openrct2-0.2.6.tar.gz) = j9dho6xbivC4OuVu0zXS4WTZn6sVr+dwZH7JTJ81xE4=
-SIZE (openrct2-0.2.6.tar.gz) = 14736700
+SHA256 (openrct2-0.3.0.tar.gz) = Rd/u46dApsJRNdE3oPtQvzoU8Bdrp5jsszgwzwDDXDs=
+SIZE (openrct2-0.3.0.tar.gz) = 16184154
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/games/openrct2/patches/patch-CMakeLists_txt,v
retrieving revision 1.4
diff -u -p -r1.4 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt 26 May 2020 15:41:41 - 1.4
+++ patches/patch-CMakeLists_txt 18 Aug 2020 02:57:22 -
@@ -6,7 +6,7 @@ Remove -Werror.
Index: CMakeLists.txt
--- CMakeLists.txt.orig
+++ CMakeLists.txt
-@@ -85,25 +85,6 @@ execute_process(
+@@ -103,25 +103,6 @@ execute_process(
ERROR_QUIET
)
@@ -32,7 +32,7 @@ Index: CMakeLists.txt
# Defines
if (USE_MMAP)
add_definitions(-DUSE_MMAP)
-@@ -234,7 +215,7 @@ else ()
+@@ -249,7 +230,7 @@ else ()
# Compiler flags
set(DEBUG_LEVEL 0 CACHE STRING "Select debug level for compilation. Use value in range 0â3.")
Index: patches/patch-src_openrct2_CMakeLists_txt
===
RCS file: patches/patch-src_openrct2_CMakeLists_txt
diff -N patches/patch-src_openrct2_CMakeLists_txt
--- patches/patch-src_openrct2_CMakeLists_txt 26 May 2020 15:41:41 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,32 +0,0 @@
-$OpenBSD: patch-src_openrct2_CMakeLists_txt,v 1.4 2020/05/26 15:41:41 bcallah Exp $
-
-Index: src/openrct2/CMakeLists.txt
src/openrct2/CMakeLists.txt.orig
-+++ src/openrct2/CMakeLists.txt
-@@ -23,7 +23,7 @@ set_target_properties(${PROJECT_NAME} PROPERTIES PREFI
- SET_CHECK_CXX_FLAGS(${PROJECT_NAME})
-
- # GCC / Clang likes us to pass the -lstdc++fs flag to link C++17 filesystem implementation.
--if (NOT MINGW AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
-+if (NOT MINGW AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD")
- if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU" OR CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
- target_link_libraries(${PROJECT_NAME} stdc++fs)
- endif()
-@@ -169,7 +169,7 @@ if (NOT APPLE AND NOT MINGW AND NOT MSVC)
- # This is ugly hack to work around https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1568899.
- # Once C++17 is enabled (and thus old compilers are no longer supported, this needs to be gone.
- # We cannot simply detect the _compiler_ version, as the bug exists with the C++ _library_
--target_link_libraries(${PROJECT_NAME} gcc_s gcc)
-+target_link_libraries(${PROJECT_NAME})
- endif ()
-
- if (NOT DISABLE_TTF)
-@@ -183,7 +183,7 @@ if (NOT DISABLE_TTF)
- target_link_libraries(${PROJECT_NAME} ${FREETYPE_LIBRARIES})
-
- if (UNIX AND NOT APPLE)
--target_link_libraries(${PROJECT_NAME} ${FONTCONFIG_LIBRARIES})
-+target_link_libraries(${PROJECT_NAME} ${FONTCONFIG_LIBRARIES} -L${OPENBSD_X11BASE}/lib)
- endif ()
- endif ()
- endif ()
Index: patches/patch-src_openrct2_common_h
===
RCS file: /cvs/ports/games/openrct2/patches/patch-src_openrct2_common_h,v
retrieving revision 1.3
diff -u -p -r1.3 patch-src_openrct2_common_h
--- patches/patch-src_openrct2_common_h 26 May 2020 15:41:41 - 1.3
+++ patches/patch-src_openrct2_common_h 18 Aug 2020 02:57:22 -
@@ -5,7 +5,7 @@ OpenBSD is missing the _Static_assert ma
Index: src/openrct2/common.h
--- src/openrct2/common.h.orig
+++ src/openrct2/common.h
-@@ -196,6 +196
