Fix cmGeneratorTarget_cxx in devel/cmake
There is a mistake in the cmGeneratorTarget_cxx patch (Surely from me).
This creates a wrong scope. "this->IsFrameworkOnApple()" is present
twice and the first one adds a wrong bracket which creates a scope to
the end of the whole function. THIS IS WRONG.
Maybe this triggers our random issues with cmake, maybe not but this
should go in?
Rafael
Index: Makefile
===
RCS file: /cvs/ports/devel/cmake/Makefile,v
retrieving revision 1.185
diff -u -p -u -p -r1.185 Makefile
--- Makefile26 May 2020 15:15:09 - 1.185
+++ Makefile12 Sep 2020 08:01:09 -
@@ -8,7 +8,7 @@ VER = 3.17.2
EPOCH =0
DISTNAME = cmake-${VER}
CATEGORIES = devel
-REVISION = 0
+REVISION = 1
HOMEPAGE = https://www.cmake.org/
Index: patches/patch-Source_cmGeneratorTarget_cxx
===
RCS file: /cvs/ports/devel/cmake/patches/patch-Source_cmGeneratorTarget_cxx,v
retrieving revision 1.13
diff -u -p -u -p -r1.13 patch-Source_cmGeneratorTarget_cxx
--- patches/patch-Source_cmGeneratorTarget_cxx 25 May 2020 05:12:00 -
1.13
+++ patches/patch-Source_cmGeneratorTarget_cxx 12 Sep 2020 08:01:09 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-Source_cmGeneratorTarget
Index: Source/cmGeneratorTarget.cxx
--- Source/cmGeneratorTarget.cxx.orig
+++ Source/cmGeneratorTarget.cxx
-@@ -4154,9 +4154,16 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary
+@@ -4154,9 +4154,15 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary
// Check for library version properties.
const char* version = this->GetProperty("VERSION");
const char* soversion = this->GetProperty("SOVERSION");
@@ -13,14 +13,14 @@ Index: Source/cmGeneratorTarget.cxx
+#else
if (!this->HasSOName(config) ||
this->Makefile->IsOn("CMAKE_PLATFORM_NO_VERSIONED_SONAME") ||
- this->IsFrameworkOnApple()) {
+- this->IsFrameworkOnApple()) {
+ this->IsFrameworkOnApple())
+#endif
+ {
// Versioning is supported only for shared libraries and modules,
// and then only when the platform supports an soname flag.
version = nullptr;
-@@ -4180,6 +4187,35 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary
+@@ -4180,6 +4186,35 @@ cmGeneratorTarget::Names cmGeneratorTarget::GetLibrary
// The library name.
targetNames.Output = prefix + targetNames.Base + suffix;
Fix thread stack base detection in devel/kf5/kjs
I think our current patch to unbreak currentThreadStackBase() is wrong.
pthread_stackseg_np(3):
The pthread_stackseg_np() function returns information about the given
thread's stack. A stack_t is the same as a struct sigaltstack (see
sigaltstack(2)) except the ss_sp variable points to the top of the stack
instead of the base.
The old patch points to the TOP and not to the base(end) of the thread stack.
I see no regressions: 100% tests passed, 0 tests failed out of 1
Feedback, OK?
Rafael
Index: Makefile
===
RCS file: /cvs/ports/devel/kf5/kjs/Makefile,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 Makefile
--- Makefile23 Mar 2020 18:01:09 - 1.12
+++ Makefile12 Sep 2020 09:51:18 -
@@ -2,6 +2,7 @@
COMMENT = JavaScript/ECMAScript engine for KDE
DISTNAME = kjs-${VERSION}
+REVISION = 0
SHARED_LIBS = KF5JS 5.0
SHARED_LIBS += KF5JSApi5.0
Index: patches/patch-src_kjs_collector_cpp
===
RCS file: /cvs/ports/devel/kf5/kjs/patches/patch-src_kjs_collector_cpp,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-src_kjs_collector_cpp
--- patches/patch-src_kjs_collector_cpp 7 Jun 2017 17:03:38 - 1.2
+++ patches/patch-src_kjs_collector_cpp 12 Sep 2020 09:51:18 -
@@ -8,9 +8,9 @@ Index: src/kjs/collector.cpp
pthread_t thread = pthread_self();
if (stackBase == nullptr || thread != stackThread) {
+#if defined(__OpenBSD__)
-+stack_t sinfo;
-+pthread_stackseg_np(thread, &sinfo);
-+stackBase = sinfo.ss_sp;
++stack_t ss;
++pthread_stackseg_np(thread, &ss);
++stackBase = (void*)((size_t) ss.ss_sp - ss.ss_size);
+#else
pthread_attr_t sattr;
#if HAVE_PTHREAD_NP_H || defined(__NetBSD__)
Re: ncmpcpp dumps core when fetching lyrics
On Fri, Sep 11, 2020 at 10:09:25PM +0100, Stuart Henderson wrote:
> [moving to ports@openbsd.org list]
> On 2020-09-11, Ashlen wrote:
> > Sorry Stuart, I think I accidentally replied to you directly the first
> > time I sent this. I'm still getting used to neomutt.
>
> No problem, for mailing lists you usually want 'group-reply'
> (by default this is bound to 'g' in mutt/neomutt).
And I accidentally sent my previous reply as 'list-reply' ('L') to @misc..
> This is likely a bug in ncmpcpp. Not sure if it's the same
> thing but I found https://github.com/ncmpcpp/ncmpcpp/issues/394
> which referenced https://github.com/ncmpcpp/ncmpcpp/issues/396
> so I think the first step is to try a newer version.
> Here's a ports diff to update it to git head, it builds OK but
> I don't have any mpd setup so no idea how well/if it works.
Thanks for the diff. Ncmpcpp still crashes when trying to fetch lyrics though.
Gdb output with last version and after rebuilding with debug flags:
[...]
Program terminated with signal SIGBUS, Bus error.
#0 _libc_pthread_mutex_unlock (mutexp=) at
/usr/src/lib/libc/thread/rthread_mutex.c:246
246 (void *)mutex->owner);
(gdb) bt
#0 _libc_pthread_mutex_unlock (mutexp=) at
/usr/src/lib/libc/thread/rthread_mutex.c:246
#1 0x0f7389525277 in std::__1::__libcpp_mutex_unlock (__m=0xf73b8ff2d18)
at /usr/src/lib/libcxx/include/__threading_support:266
#2 std::__1::mutex::unlock (this=0xf73b8ff2d18) at
/usr/src/lib/libcxx/src/mutex.cpp:45
#3 0x0f713119422d in std::__1::unique_lock::~unique_lock
(this=) at /usr/include/c++/v1/__mutex_base:153
#4 Shared >::Resource::~Resource (this=)
at ./utility/shared_resource.h:29
#5 Lyrics::update (this=0xf740afb5c00) at screens/lyrics.cpp:236
#6 0x0f71311f2215 in std::__1::__function::__value_func::operator()(BaseScreen*&&) const (this=0x7f7d4500,
__args=) at /usr/include/c++/v1/functional:1799
#7 std::__1::function::operator()(BaseScreen*) const
(this=0x7f7d4500, __arg=0xf740afb5c00) at
/usr/include/c++/v1/functional:2347
#8 applyToVisibleWindows(std::__1::function) (f=...) at
screens/screen.cpp:135
#9 0x0f71312d8ad8 in Status::trace (update_timer=,
update_window_timeout=) at status.cpp:236
#10 0x0f7131249a13 in Actions::UpdateEnvironment::run (this=0x7f7d48c8,
update_timer=24, refresh_window=, mpd_sync=)
at actions.cpp:338
#11 0x0f71312ae220 in main (argc=, argv=) at
ncmpcpp.cpp:217
(gdb)
Erling
Re: ncmpcpp dumps core when fetching lyrics
On 2020/09/12 12:36, Erling Westenvik wrote:
> On Fri, Sep 11, 2020 at 10:09:25PM +0100, Stuart Henderson wrote:
> > [moving to ports@openbsd.org list]
> > On 2020-09-11, Ashlen wrote:
> > > Sorry Stuart, I think I accidentally replied to you directly the first
> > > time I sent this. I'm still getting used to neomutt.
> >
> > No problem, for mailing lists you usually want 'group-reply'
> > (by default this is bound to 'g' in mutt/neomutt).
>
> And I accidentally sent my previous reply as 'list-reply' ('L') to @misc..
>
> > This is likely a bug in ncmpcpp. Not sure if it's the same
> > thing but I found https://github.com/ncmpcpp/ncmpcpp/issues/394
> > which referenced https://github.com/ncmpcpp/ncmpcpp/issues/396
> > so I think the first step is to try a newer version.
> > Here's a ports diff to update it to git head, it builds OK but
> > I don't have any mpd setup so no idea how well/if it works.
>
> Thanks for the diff. Ncmpcpp still crashes when trying to fetch lyrics though.
> Gdb output with last version and after rebuilding with debug flags:
Since the problem still exists in git head, I think it would be worth
reporting this upstream.
> [...]
> Program terminated with signal SIGBUS, Bus error.
> #0 _libc_pthread_mutex_unlock (mutexp=) at
> /usr/src/lib/libc/thread/rthread_mutex.c:246
> 246 (void *)mutex->owner);
> (gdb) bt
> #0 _libc_pthread_mutex_unlock (mutexp=) at
> /usr/src/lib/libc/thread/rthread_mutex.c:246
> #1 0x0f7389525277 in std::__1::__libcpp_mutex_unlock (__m=0xf73b8ff2d18)
> at /usr/src/lib/libcxx/include/__threading_support:266
> #2 std::__1::mutex::unlock (this=0xf73b8ff2d18) at
> /usr/src/lib/libcxx/src/mutex.cpp:45
> #3 0x0f713119422d in
> std::__1::unique_lock::~unique_lock (this=)
> at /usr/include/c++/v1/__mutex_base:153
> #4 Shared >::Resource::~Resource (this= out>) at ./utility/shared_resource.h:29
> #5 Lyrics::update (this=0xf740afb5c00) at screens/lyrics.cpp:236
> #6 0x0f71311f2215 in std::__1::__function::__value_func (BaseScreen*)>::operator()(BaseScreen*&&) const (this=0x7f7d4500,
> __args=) at /usr/include/c++/v1/functional:1799
> #7 std::__1::function::operator()(BaseScreen*) const
> (this=0x7f7d4500, __arg=0xf740afb5c00) at
> /usr/include/c++/v1/functional:2347
> #8 applyToVisibleWindows(std::__1::function) (f=...) at
> screens/screen.cpp:135
> #9 0x0f71312d8ad8 in Status::trace (update_timer=,
> update_window_timeout=) at status.cpp:236
> #10 0x0f7131249a13 in Actions::UpdateEnvironment::run
> (this=0x7f7d48c8, update_timer=24, refresh_window=,
> mpd_sync=)
> at actions.cpp:338
> #11 0x0f71312ae220 in main (argc=, argv=)
> at ncmpcpp.cpp:217
> (gdb)
>
> Erling
Re: Update: textproc/py-emoji to 0.6.0
On Tue, Aug 11, 2020 at 05:24:24PM -0400, Pamela Mosiejczuk wrote:
> On Tue, Aug 11, 2020 at 04:48:49PM -0400, Pamela Mosiejczuk wrote:
> > Update for multiple minor fixes and removal of consumerless python 2 flavor.
> > This version adds a "variant" selector, allowing specification of text or
> > emoji
> > variant form (VS15 or VS16).
> > The removed patches have since been upstreamed. Passes all tests.
> > OK?
> > Pamela
> Oops, now with plist tweaking for flavor removal. (Hopefully).
ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/textproc/py-emoji/Makefile,v
> retrieving revision 1.7
> diff -u -p -r1.7 Makefile
> --- Makefile 3 Jul 2020 21:13:14 - 1.7
> +++ Makefile 9 Aug 2020 00:47:29 -
> @@ -2,10 +2,9 @@
>
> COMMENT =emoji for Python
>
> -MODPY_EGG_VERSION = 0.5.4
> +MODPY_EGG_VERSION = 0.6.0
> DISTNAME = emoji-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> -REVISION = 0
>
> CATEGORIES = textproc
>
> @@ -22,6 +21,6 @@ MODPY_PI = Yes
> MODPY_PYTEST = Yes
>
> FLAVORS =python3
> -FLAVOR ?=
> +FLAVOR = python3
>
> .include
> Index: distinfo
> ===
> RCS file: /home/cvs/ports/textproc/py-emoji/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- distinfo 7 Nov 2019 09:23:53 - 1.3
> +++ distinfo 9 Aug 2020 00:16:04 -
> @@ -1,2 +1,2 @@
> -SHA256 (emoji-0.5.4.tar.gz) = YGUtOi3O5bivissJfDF3b7bYCAJ663Ihgw9yza/vwXQ=
> -SIZE (emoji-0.5.4.tar.gz) = 43402
> +SHA256 (emoji-0.6.0.tar.gz) = 5C2k+NZI+O8QaRvCRvaCoexrGDc6v9m+EOwLOYgjvRE=
> +SIZE (emoji-0.6.0.tar.gz) = 51003
> Index: patches/patch-setup_cfg
> ===
> RCS file: patches/patch-setup_cfg
> diff -N patches/patch-setup_cfg
> --- patches/patch-setup_cfg 11 Nov 2019 00:40:45 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,16 +0,0 @@
> -$OpenBSD: patch-setup_cfg,v 1.1 2019/11/11 00:40:45 kmos Exp $
> -
> -Remove unneeded py-nose
> -
> -Index: setup.cfg
> setup.cfg.orig
> -+++ setup.cfg
> -@@ -1,8 +1,3 @@
> --[nosetests]
> --verbosity = 3
> --cover-package = emoji
> --cover-erase = 1
> --
> - [egg_info]
> - tag_build =
> - tag_date = 0
> Index: patches/patch-setup_py
> ===
> RCS file: patches/patch-setup_py
> diff -N patches/patch-setup_py
> --- patches/patch-setup_py11 Nov 2019 00:40:45 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,15 +0,0 @@
> -$OpenBSD: patch-setup_py,v 1.1 2019/11/11 00:40:45 kmos Exp $
> -
> -Remove unneeded py-nose
> -
> -Index: setup.py
> setup.py.orig
> -+++ setup.py
> -@@ -59,7 +59,6 @@ setup(
> - keywords=['emoji'],
> - extras_require={
> - 'dev': [
> --'nose',
> - 'coverage',
> - 'coveralls'
> - ]
> Index: patches/patch-tests_test_core_py
> ===
> RCS file: patches/patch-tests_test_core_py
> diff -N patches/patch-tests_test_core_py
> --- patches/patch-tests_test_core_py 11 Nov 2019 00:40:45 - 1.1
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,15 +0,0 @@
> -$OpenBSD: patch-tests_test_core_py,v 1.1 2019/11/11 00:40:45 kmos Exp $
> -
> -Remove unneeded py-nose
> -
> -Index: tests/test_core.py
> tests/test_core.py.orig
> -+++ tests/test_core.py
> -@@ -9,7 +9,6 @@ Unittests for emoji.core
> - from __future__ import unicode_literals
> -
> - import emoji
> --from nose.tools import assert_raises
> -
> -
> - def test_emojize_name_only():
> Index: pkg/PLIST
> ===
> RCS file: /home/cvs/ports/textproc/py-emoji/pkg/PLIST,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 PLIST
> --- pkg/PLIST 26 Apr 2019 18:25:54 - 1.1.1.1
> +++ pkg/PLIST 11 Aug 2020 21:15:52 -
> @@ -1,4 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.1.1.1 2019/04/26 18:25:54 kmos Exp $
> +@pkgpath textproc/py-emoji
> +@conflict py-emoji-*
> lib/python${MODPY_VERSION}/site-packages/emoji/
>
> lib/python${MODPY_VERSION}/site-packages/emoji-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/
>
> lib/python${MODPY_VERSION}/site-packages/emoji-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
>
Re: [Update] devel/py-pathspec : Update to 0.8.0
On Tue, Sep 08, 2020 at 08:36:46AM +, wen heping wrote:
> Hi, ports@:
>Here is a simple patch for devel/py-pathspec to update to 0.8.0.
> It build well and pass all tests on amd64-current system.
>One port depends on it : devel/py-yamllint. It build well and pass
> all tests too.
> Cheers !
> wen
Committed with tweaks to have it use MODPY_PYTEST
Thanks!
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/py-pathspec/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- Makefile 3 Jul 2020 21:12:47 - 1.5
> +++ Makefile 8 Sep 2020 08:33:07 -
> @@ -2,10 +2,9 @@
>
> COMMENT =utility for gitignore style pattern matching of file paths
>
> -MODPY_EGG_VERSION = 0.5.9
> +MODPY_EGG_VERSION = 0.8.0
> DISTNAME = pathspec-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> -REVISION = 1
>
> CATEGORIES = devel
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/devel/py-pathspec/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- distinfo 22 Jan 2019 11:18:53 - 1.2
> +++ distinfo 8 Sep 2020 08:33:07 -
> @@ -1,2 +1,2 @@
> -SHA256 (pathspec-0.5.9.tar.gz) = VKXquJXYnzQrUror/+cJMO+fjZbjmMzPUw0h+gUWqHM=
> -SIZE (pathspec-0.5.9.tar.gz) = 25473
> +SHA256 (pathspec-0.8.0.tar.gz) = 2kUXPrOm8qWkh++6IfBQrytBlIvmq1K2oeP/IruLcGE=
> +SIZE (pathspec-0.8.0.tar.gz) = 26256
[New] archivers/py-lz4
This package provides python bindings for the LZ4 compression library. The bindings provided in this package cover the frame format, the block format, and the streaming format specifications. The frame format bindings are the recommended ones to use, as this guarantees interoperability with other implementations and language bindings. All but one of some almost 30k tests pass. The one that fails tries to allocate a massive amount of memory. While I had this pending (trying to figure out which port I needed this for) I was reviewing ports and saw that thfr had a version of this for his py-unitypy port. I integrated his patch to eliminate -O3 and the call for py-pkgconfig, but kept my cleaned up version. (His used MODPY_DEFAULT_VERSION_3 and missed a BUILD_DEPENDS on py-setuptools_scm). ok to import? --Kurt py-lz4.tgz Description: application/tar-gz
Re: NEW: kitty - a GPU-accelerated terminal emulator
On 9/6/20 1:39 AM, Thomas Frohwein wrote:
Hi,
Please find attached a new port of kitty. Kitty is a terminal emulator
for X11. The main distinguishing feature from others in ports is that
it uses OpenGL acceleration. It's written in C11 and python. I've been
using it for a few days without any issues.
Notes about the port:
- configuration: https://sw.kovidgoyal.net/kitty/conf.html
- When I ran it a few months ago on radeon (with HD 6870), selecting
text with the mouse didn't work correctly. It would only select a few
characters and not extend the selection beyond that. I'm now running
it on an Intel Coffeelake without any such issues.
- I couldn't get the use of audio/libcanberra via dlopen(3) to work.
Therefore, a patch that reverts it to dynamically linking to the
library is included.
- Otherwise, patches are just dealing with routine stuff - working
around procfs, and disabling hardcoded optimization flags.
ok to import? comments?
Hi,
I am using the port for a few days and I just loved it. Actually
switched from st{,-term} to kitty for my daily routines and it works
pretty good. Hope it will gets into the ports very soon.
Thank you for your work
Cheers,
New: archivers/py-brotli (was Re: NEW: py-unitypy - extractor for Unity projects, with deps)
On Sat, Sep 05, 2020 at 05:45:09PM -0600, Thomas Frohwein wrote: > I started using UnityPy for a project and it would be useful to see > about adding it to ports. It essentially allows accessing the assets of > Unity projects. I've included 4 of the 5 dependencies in the > attachments: py-brotli, py-lz4, py-fsb5, py-texture2ddecoder. The last > one is py-Pillow and is already in ports. > A relatively simple example is on the project GitHub page: > https://github.com/K0lb3/UnityPy#example > I've tested this and it works, and will probably be using it regularly > in the near future. > Some notes on the ports: > - py-brotli build a bundled version and doesn't provide a way that I > could find to link to system libs from archivers/brotli. Here's a version of archivers/py-brotli I'm happier with. It's got a better DESCR, and can run the tests if they are copied into place. (I've opened a pull request upstream to include them in future). --Kurt py-brotli.tgz Description: application/tar-gz
Re: New: archivers/py-brotli (was Re: NEW: py-unitypy - extractor for Unity projects, with deps)
On Sat, Sep 12, 2020 at 12:57:41PM -0400, Kurt Mosiejczuk wrote: > On Sat, Sep 05, 2020 at 05:45:09PM -0600, Thomas Frohwein wrote: > > I started using UnityPy for a project and it would be useful to see > > about adding it to ports. It essentially allows accessing the assets of > > Unity projects. I've included 4 of the 5 dependencies in the > > attachments: py-brotli, py-lz4, py-fsb5, py-texture2ddecoder. The last > > one is py-Pillow and is already in ports. > > A relatively simple example is on the project GitHub page: > > https://github.com/K0lb3/UnityPy#example > > I've tested this and it works, and will probably be using it regularly > > in the near future. > > Some notes on the ports: > > - py-brotli build a bundled version and doesn't provide a way that I > > could find to link to system libs from archivers/brotli. > Here's a version of archivers/py-brotli I'm happier with. It's got a better > DESCR, and can run the tests if they are copied into place. (I've opened a > pull request upstream to include them in future). A quick correction on this, it didn't have a HOMEPAGE before. I've added one now. --Kurt py-brotli.tgz Description: application/tar-gz
New: audio/py-fsb5 (was Re: NEW: py-unitypy - extractor for Unity projects, with deps)
On Sat, Sep 05, 2020 at 05:45:09PM -0600, Thomas Frohwein wrote: > I started using UnityPy for a project and it would be useful to see > about adding it to ports. It essentially allows accessing the assets of > Unity projects. I've included 4 of the 5 dependencies in the > attachments: py-brotli, py-lz4, py-fsb5, py-texture2ddecoder. The last > one is py-Pillow and is already in ports. Here's a tweaked py-fsb5 that has my ok to import. A little formatting work, but mostly having it use the proper FLAVOR=python3 paradigm. --Kurt py-fsb5.tgz Description: application/tar-gz
Re: UPDATE: sysutils/htop 2.2.0 => 3.0.0
On Sat, Sep 05, 2020 at 08:08:36AM +0200, Rafael Sadowski wrote:
> On Tue Sep 01, 2020 at 02:44:43PM +1000, Stephen Gregoratto wrote:
> > A fork[1] of htop has appeared, with blessings[2] from the original
> > developer. Downsides are that it uses GitHub archives, so GH_* stuff is
> > addded. I took the time to modify the patches to work on this release,
> > but since there were some substantial rewrites[3] I wonder if we should
> > drop them altogether.
> >
> > [1] https://github.com/htop-dev/htop
> > [2] https://github.com/hishamhm/htop/issues/992#issuecomment-683286672
> > [3] The shortlog:
> >
> > b92f62f Remove trailing whitespaces
> > dd33444 Clean up existing whitespace
> > 909bb86 Show N/A on unsupported platforms instead of 0KHz
> > 27fe307 Remove a few unnecessary #includes
> > 9197adf Fix CPU usage on OpenBSD
> > c34be41 Widen ST_UID (UID) column to 5 chars to allow UIDs >
> > without breaking alignment Issue Github #841, Debian bug
> > #910492
> > ca1cce4 OpenBSD: make the STARTTIME column display correctly (#815)
> > c1fb585 OpenBSD: add environment reading support (#819)
> > 060aa2b remove wrongfix
> > 3d79c72 Update OpenBSD maximum PID
> > c005ffc Fix zero-index array bounds issue
> > 48b807b Fix CPU meters
> > --
> > Stephen Gregoratto
>
> OK with a small trailing whitespace zap after "-g". Any maintainer
> feedback?
>
> Rafael Sadowski
>
whoops, missed this. everything looks good. i was wondering why my
patches from 2 years ago were suddenly getting merged upstream. good to
see someone has taken over the project. thanks for the bump
there's 3.0.1 now
Index: ports/sysutils/htop//Makefile
===
RCS file: /cvs/ports/sysutils/htop/Makefile,v
retrieving revision 1.22
diff -u -p -r1.22 Makefile
--- ports/sysutils/htop//Makefile 11 Sep 2020 12:34:28 - 1.22
+++ ports/sysutils/htop//Makefile 12 Sep 2020 16:55:34 -
@@ -4,7 +4,7 @@ COMMENT = interactive process viewer
GH_ACCOUNT = htop-dev
GH_PROJECT = htop
-GH_TAGNAME = 3.0.0
+GH_TAGNAME = 3.0.1
CATEGORIES = sysutils
@@ -35,6 +35,6 @@ MODPY_VERSION = ${MODPY_DEFAULT_VERSION
# htop has some bugs which take hours or days to reach.
# Keep the symbols to give a chance to the user to get an useful coredump.
MAKE_FLAGS = AM_CPPFLAGS="-DDEBUG"
-DEBUG =-g
+DEBUG =-g
.include
Index: ports/sysutils/htop//distinfo
===
RCS file: /cvs/ports/sysutils/htop/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- ports/sysutils/htop//distinfo 11 Sep 2020 12:34:28 - 1.4
+++ ports/sysutils/htop//distinfo 12 Sep 2020 16:55:34 -
@@ -1,2 +1,2 @@
-SHA256 (htop-3.0.0.tar.gz) = HAZh8K5fTih02iULYM1RXkrEwEFYMiGt/pXxDhjRpOY=
-SIZE (htop-3.0.0.tar.gz) = 179371
+SHA256 (htop-3.0.1.tar.gz) = hGUWS8CF9fGBPh0/bEubVr9MlcwSImpTZ+ZXlJSbAco=
+SIZE (htop-3.0.1.tar.gz) = 179925
ok ?
UPDATE mail/mblaze 1.0 from MAINTAINER
Hello ports@, 1.0 release of mblaze is out, with a bunch of stuff (taken from NEWS.md): * Caution! Backwards incompatible changes: * As a message name, `-` now refers to the message on the standard input, and not the the previous message anymore. Use `.-` to refer to the previous message in a short way. The tools will print a warning if you use `-` and the standard input comes from a TTY. * mpick: use the -F flag to read script files. * mpick: remove msglist support, use plain mmsg(7) arguments. * Many mblaze tools now make use of pledge(2) on OpenBSD. * add contrib/mcount, a tool to count mails * mrep: use Reply-From configuration to find From header * Many bug fixes. Passes all the tests and I haven't ran into any pledge violations yet, althought I haven't tested every individual command in the package. -Lucas Index: Makefile === RCS file: /home/cvs/ports/mail/mblaze/Makefile,v retrieving revision 1.11 diff -u -p -r1.11 Makefile --- Makefile16 May 2020 22:16:40 - 1.11 +++ Makefile12 Sep 2020 16:39:13 - @@ -2,7 +2,7 @@ COMMENT = set of Maildir utilities -DISTNAME = mblaze-0.7 +DISTNAME = mblaze-1.0 CATEGORIES = mail HOMEPAGE = https://git.vuxu.org/mblaze/ Index: distinfo === RCS file: /home/cvs/ports/mail/mblaze/distinfo,v retrieving revision 1.7 diff -u -p -r1.7 distinfo --- distinfo16 May 2020 22:16:40 - 1.7 +++ distinfo12 Sep 2020 16:39:23 - @@ -1,2 +1,2 @@ -SHA256 (mblaze-0.7.tar.gz) = gE/rYlUaZFdLvxuA+t7nUavlZXyUIF+WyohPc509M/w= -SIZE (mblaze-0.7.tar.gz) = 94775 +SHA256 (mblaze-1.0.tar.gz) = MWBh6NbPZFWpEQXFUGaWOPbgKIxTxxhfskKcVOgPIzU= +SIZE (mblaze-1.0.tar.gz) = 95676
Remove textproc/py-termcolor?
py-termcolor has no consumers. There hasn't been a release since 2011 and it's homepage is the PyPI page. Anyone object to removing it? --Kurt
Re: update alephone and marathon game files
Sound, normal/windowed mode, gameplay all fine. Tested local network
play with kmos@ (pew pew pew!)
OK pamela@
On 2020-09-11 16:22, Peter Hessler wrote:
Update for AlephOne and the Marathon game files to the recent 1.3.1 release.
Major Changes:
Uses SDL 2 for much-improved compatibility with new operating systems
Better support for game controllers
Better performance for the software renderer
Improved mouse control options, with settings for Classic and Modern
mouse control
Better support for high-dpi displays
New controls dialog, which allows simultaneous key, mouse, and
controller bindings
More authentic static effect when using OpenGL
Adds a stash for sharing info between Lua states
Better support for Unicode characters in Windows (should fix Rubicon X)
Better support for original Marathon scenarios including Trojan,
which now works fully
A separate 64-bit Windows build is available
Better master volume and music volume controls
Video export bitrate depends on the video resolution, which leads to
much improved export at 1080p with default settings
Mac apps are now notarized by Apple
Original games now default to more authentic settings on first
install; high res plugins are still included but are not enabled by
default
Plays well for me on amd64
OK?
Index: games/alephone/alephone/Makefile
===
RCS file: /home/cvs/openbsd/ports/games/alephone/alephone/Makefile,v
retrieving revision 1.30
diff -u -p -u -p -r1.30 Makefile
--- games/alephone/alephone/Makefile12 Jul 2019 20:46:14 - 1.30
+++ games/alephone/alephone/Makefile11 Sep 2020 18:06:10 -
@@ -1,12 +1,13 @@
# $OpenBSD: Makefile,v 1.30 2019/07/12 20:46:14 sthen Exp $
+DPB_PROPERTIES = parallel
+
DIST_SUBDIR ?=alephone
COMMENT = open source game engine based on Marathon 2: Durandal
-DATE = 20150620
+DATE = 20200904
DISTNAME =AlephOne-${DATE}
-PKGNAME = alephone-1.2.1
-REVISION = 6
+PKGNAME = alephone-1.3.1
EXTRACT_SUFX = .tar.bz2
CATEGORIES = games x11
@@ -20,10 +21,10 @@ PERMIT_PACKAGE =Yes
MASTER_SITES = https://github.com/Aleph-One-Marathon/alephone/releases/download/release-${DATE}/
-WANTLIB += GL GLU c m pthread ${COMPILER_LIBCXX} z
-WANTLIB += SDL SDL_net SDL_image SDL_ttf mad png sndfile
-WANTLIB += smpeg speex speexdsp vorbisfile zzip
-WANTLIB += avcodec avformat avutil swscale boost_filesystem boost_system curl
+WANTLIB += ${COMPILER_LIBCXX} GL GLU SDL2 SDL2_image SDL2_net
+WANTLIB += SDL2_ttf avcodec avformat avutil boost_filesystem boost_system
+WANTLIB += c curl expat m mad png sndfile speex speexdsp swscale
+WANTLIB += vorbisfile z zzip
COMPILER = base-clang ports-gcc base-gcc
@@ -31,10 +32,9 @@ BUILD_DEPENDS = devel/automake/${AUTOMA
devel/autoconf/${AUTOCONF_VER}
LIB_DEPENDS = archivers/zziplib \
devel/boost \
- devel/sdl-net \
- devel/sdl-image \
- devel/sdl-ttf \
- devel/smpeg \
+ devel/sdl2-net \
+ devel/sdl2-image \
+ devel/sdl2-ttf \
audio/libmad \
audio/libsndfile \
audio/speex \
@@ -42,11 +42,15 @@ LIB_DEPENDS = archivers/zziplib \
graphics/ffmpeg \
net/curl
+RUN_DEPENDS = devel/desktop-file-utils \
+ x11/gtk+3,-guic \
+ misc/shared-mime-info
+
USE_BZIP2 = Yes
USE_GMAKE = Yes
CONFIGURE_STYLE = gnu
-AUTOCONF_VER = 2.61
-AUTOMAKE_VER = 1.9
+AUTOCONF_VER = 2.65
+AUTOMAKE_VER = 1.16
CONFIGURE_ENV = AUTOCONF_VERSION=${AUTOCONF_VER} \
AUTOMAKE_VERSION=${AUTOMAKE_VER} \
CPPFLAGS=-I${LOCALBASE}/include
Index: games/alephone/alephone/distinfo
===
RCS file: /home/cvs/openbsd/ports/games/alephone/alephone/distinfo,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 distinfo
--- games/alephone/alephone/distinfo2 Feb 2016 10:17:44 - 1.10
+++ games/alephone/alephone/distinfo11 Sep 2020 13:08:40 -
@@ -1,2 +1,2 @@
-SHA256 (alephone/AlephOne-20150620.tar.bz2) =
wPNg37dKYmT5XTdRA6dAAJMM8EOf+wRk+RX1N5RD4TM=
-SIZE (alephone/AlephOne-20150620.tar.bz2) = 5031898
+SHA256 (alephone/AlephOne-20200904.tar.bz2) =
kCJ6tt2shq+LGO7uIt/Etm6+CDl5829wnLc0nG4dk40=
+SIZE (alephone/AlephOne-20200904.tar.bz2) = 5567722
Index: games/alephone/alephone/patches/patch-Source_Files_FFmpeg_
Re: New: graphics/mypaint-brushes2
On 2020/09/11 15:53, Pamela Mosiejczuk wrote: > This is needed for the new port mypaint, which follows. (Gimp depends on the > 1.x branch of this port, currently in the tree, while MyPaint itself needs > the 2.x). > > "Brushes used by MyPaint and other software using libmypaint." > > OK to import? > > -Pamela > License marker should be "Public Domain/CC0 1.0", otherwise OK. I'm not sure what cvs does if you try to import something that includes CVS directories, might be safer to remove them beforehand. (This _could_ just be named mypaint-brushes-$V and set the packages to not conflict with each, like is done for different versions of python, though hopefully gimp will move to the newer mypaint-brushes sometime so it will be temporary anyway, so probably easier to leave as-is).
Re: New: graphics/mypaint
On 2020/09/11 15:56, Pamela Mosiejczuk wrote: > MyPaint is a simple drawing and painting program that works well > with Wacom-style graphics tablets. Its brush engine is versatile and > configurable, and it provides useful, productive tools. The standard > brushes can emulate traditional media like charcoal, pencils, ink, or > paint. > > Uses mypaint-brushes2, preceding. > > OK to import? > > -Pamela > yep.
Re: New: graphics/py-blurhash
On Fri, Sep 11, 2020 at 04:33:48PM -0400, Pamela Mosiejczuk wrote: > This a python implementation of the blurhash algorithm, used by the > mastodon software to hide sensitive images using compact placeholders. > It is needed for an update to mastodon.py to support newer mastodon > versions. > Patched so that tests will run, but currently they're not included in > the source distribution. All tests do pass and upstream merged my request to > include them in the future. > OK to import? > -Pamela ok kmos --Kurt
Re: [NEW] textproc/py-regex
On Tue, Sep 08, 2020 at 03:03:29AM +, wen heping wrote: > Hi, >Here is a patch to create new port textproc/py-regex, which is required > by the update of textproc/py-black. >It build well, all tests passed but one failed on amd64-current system. Here's a version moved to use the current FLAVOR=python3 paradigm and use MODPY_PYTEST. ok to import? --Kurt py-regex.tar.gz Description: application/tar-gz
Fix text-to-speech in Qt5, x11/qt5/qtspeech
The following diff fix text-to-speech again in all consumers. I think
for the very first time. You can simply test it with
x11/kde-applications/kmouth for example.
Tested in the hackroom, bluhm@ is my witness ;)
Feedback, OK?
Rafael
Index: Makefile
===
RCS file: /cvs/ports/x11/qt5/qtspeech/Makefile,v
retrieving revision 1.9
diff -u -p -u -p -r1.9 Makefile
--- Makefile13 Mar 2020 16:53:52 - 1.9
+++ Makefile12 Sep 2020 20:58:00 -
@@ -2,15 +2,17 @@
QT5NAME = QtSpeech
COMMENT-main = Qt5 text-to-speech components
+REVISION-main =0
MULTI_PACKAGES = -main -examples
SHARED_LIBS += Qt5TextToSpeech 1.0 # 5.9
-WANTLIB += ${COMPILER_LIBCXX} Qt5Core m
+WANTLIB += ${COMPILER_LIBCXX} Qt5Core glib-2.0 intl m speechd
BUILD_DEPENDS =
x11/qt5/qtmultimedia>=${QT5_VERSION:R},<${QT5_NEXT_VERSION}
RUN_DEPENDS =
x11/qt5/qtmultimedia>=${QT5_VERSION:R},<${QT5_NEXT_VERSION}
+LIB_DEPENDS = audio/speech-dispatcher
FLAVORS = debug
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/x11/qt5/qtspeech/pkg/PLIST-main,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 PLIST-main
--- pkg/PLIST-main 13 Mar 2020 16:53:52 - 1.3
+++ pkg/PLIST-main 12 Sep 2020 20:58:00 -
@@ -23,10 +23,12 @@ lib/pkgconfig/Qt5TextToSpeech.pc
lib/qt5/cmake/Qt5TextToSpeech/
lib/qt5/cmake/Qt5TextToSpeech/Qt5TextToSpeechConfig.cmake
lib/qt5/cmake/Qt5TextToSpeech/Qt5TextToSpeechConfigVersion.cmake
-lib/qt5/examples/
+lib/qt5/cmake/Qt5TextToSpeech/Qt5TextToSpeech_QTextToSpeechPluginSpeechd.cmake
lib/qt5/libQt5TextToSpeech.la
lib/qt5/libQt5TextToSpeech.prl
@lib lib/qt5/libQt5TextToSpeech.so.${LIBQt5TextToSpeech_VERSION}
lib/qt5/mkspecs/modules/qt_lib_texttospeech.pri
lib/qt5/mkspecs/modules/qt_lib_texttospeech_private.pri
lib/qt5/pkgconfig/Qt5TextToSpeech.pc
+lib/qt5/plugins/texttospeech/
+@so lib/qt5/plugins/texttospeech/libqtexttospeech_speechd.so
Re: [UPDATE] audio/picard 2.3.1 -> 2.4.2
On Mon, Aug 24, 2020 at 08:02:01AM +0200, Stefan Hagen wrote: > Hello, > this an udapte for audio/piacard from version 2.3.1 to 2.4.2. > Port changes: > - update port version > - removed revision > - added new dependency devel/py-dateutil > Application changes: > - https://picard.musicbrainz.org/changelog/ > portcheck: ok > port-lib-depends-check: ok > manual test (amd64): ok > OK? Committed. Thanks! --Kurt
Update: devel/py-wcwidth 0.1.9 -> 0.2.5
Update py-wcwidth from 0.1.9 to 0.2.5
All consumer regression tests pass with this update.
ok?
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/devel/py-wcwidth/Makefile,v
retrieving revision 1.10
diff -u -p -r1.10 Makefile
--- Makefile3 Jul 2020 21:12:52 - 1.10
+++ Makefile12 Sep 2020 22:25:47 -
@@ -2,10 +2,9 @@
COMMENT= measures number of terminal column cells of wide-char
code
-MODPY_EGG_VERSION= 0.1.9
+MODPY_EGG_VERSION= 0.2.5
DISTNAME= wcwidth-${MODPY_EGG_VERSION}
PKGNAME= py-${DISTNAME}
-REVISION= 0
CATEGORIES=devel
@@ -19,7 +18,6 @@ MODULES= lang/python
MODPY_PI= Yes
MODPY_SETUPTOOLS= Yes
MODPY_PYTEST = Yes
-MODPY_PYTEST_ARGS =wcwidth
FLAVORS= python3
FLAVOR = python3
Index: distinfo
===
RCS file: /cvs/ports/devel/py-wcwidth/distinfo,v
retrieving revision 1.5
diff -u -p -r1.5 distinfo
--- distinfo30 Mar 2020 13:18:41 - 1.5
+++ distinfo12 Sep 2020 22:25:47 -
@@ -1,2 +1,2 @@
-SHA256 (wcwidth-0.1.9.tar.gz) = 7nOGKGKhVr93/5KwkDT8SCXdOvnPgbxbNgZo1CXzxfE=
-SIZE (wcwidth-0.1.9.tar.gz) = 24764
+SHA256 (wcwidth-0.2.5.tar.gz) = xNZHuZhykp/be9yqT75/AUE+09mAd995hTDlsE8RbIM=
+SIZE (wcwidth-0.2.5.tar.gz) = 34755
Index: pkg/PLIST
===
RCS file: /cvs/ports/devel/py-wcwidth/pkg/PLIST,v
retrieving revision 1.2
diff -u -p -r1.2 PLIST
--- pkg/PLIST 29 Mar 2020 18:46:23 - 1.2
+++ pkg/PLIST 12 Sep 2020 22:25:47 -
@@ -6,6 +6,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/wcwidth-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/PKG-INFO
lib/python${MODPY_VERSION}/site-packages/wcwidth-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/SOURCES.txt
lib/python${MODPY_VERSION}/site-packages/wcwidth-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/dependency_links.txt
+lib/python${MODPY_VERSION}/site-packages/wcwidth-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/requires.txt
lib/python${MODPY_VERSION}/site-packages/wcwidth-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/wcwidth-${MODPY_EGG_VERSION}-py${MODPY_VERSION}.egg-info/zip-safe
lib/python${MODPY_VERSION}/site-packages/wcwidth/__init__.py
@@ -13,13 +14,9 @@ ${MODPY_COMMENT}lib/python${MODPY_VERSIO
lib/python${MODPY_VERSION}/site-packages/wcwidth/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/wcwidth/${MODPY_PYCACHE}table_wide.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/wcwidth/${MODPY_PYCACHE}table_zero.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/wcwidth/${MODPY_PYCACHE}unicode_versions.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/wcwidth/${MODPY_PYCACHE}wcwidth.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/wcwidth/table_wide.py
lib/python${MODPY_VERSION}/site-packages/wcwidth/table_zero.py
-lib/python${MODPY_VERSION}/site-packages/wcwidth/tests/
-lib/python${MODPY_VERSION}/site-packages/wcwidth/tests/__init__.py
-${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/wcwidth/tests/${MODPY_PYCACHE}/
-lib/python${MODPY_VERSION}/site-packages/wcwidth/tests/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/wcwidth/tests/${MODPY_PYCACHE}test_core.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/wcwidth/tests/test_core.py
+lib/python${MODPY_VERSION}/site-packages/wcwidth/unicode_versions.py
lib/python${MODPY_VERSION}/site-packages/wcwidth/wcwidth.py
Re: Update: devel/py-wcwidth 0.1.9 -> 0.2.5
Hi Kurt, Kurt Mosiejczuk wrote on Sat, Sep 12, 2020 at 06:28:30PM -0400: > Update py-wcwidth from 0.1.9 to 0.2.5 This library is a very bad idea, it should better not exist. Python should use native wcwidth(3) instead. PKG-INFO says: This library attempts to determine the printable width [...] using the very latest Unicode specification. [...] The libc version of `wcwidth(3)`_ is often several unicode releases behind, and therefor several levels of support lower than this python library. That's just not true on OpenBSD where wcwidth(3) is very diligently maintained by afresh1@ in a timely manner. Even on systems where libc *is* behind, using a newer version on the application level is a very bad idea because the goal must be to have consistent data between the application program and the terminal emulator. Now the terminal emulator is (hopefully) using libc and certainly not using this Python library, so using the latest and greatest on the application level achieves nothing but inconsistency and hence misformatting in the terminal, whereas using the same native libc function in both Python and the terminal emulator would yield better results, even if the Unicode data data were slightly outdated. Not sure this observation should stand in the way of a routine update - but it might potentially make sense to deliver a dummy version on OpenBSD instead that merely calls through to libc and does not attempt to do any work whatsoever on its own. Yours, Ingo
UPDATE: www/qutebrowser 1.12.0 -> 1.13.1
An update to qutebrowser - 1.13.1
I'll like to take Maintainer if no one minds
Any comments/OK?
Changelog:https://github.com/qutebrowser/qutebrowser/releases
Index: Makefile
===
RCS file: /cvs/ports/www/qutebrowser/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile3 Jul 2020 21:13:21 - 1.20
+++ Makefile12 Sep 2020 20:55:45 -
@@ -2,13 +2,14 @@
COMMENT = keyboard-focused browser with a minimal GUI
-MODPY_EGG_VERSION =1.12.0
+MODPY_EGG_VERSION =1.13.1
DISTNAME = qutebrowser-${MODPY_EGG_VERSION}
-REVISION = 0
HOMEPAGE = https://www.qutebrowser.org/
CATEGORIES = www
+
+MAINTAINER = Dimitri Karamazov
# GPLv3
PERMIT_PACKAGE = Yes
Index: distinfo
===
RCS file: /cvs/ports/www/qutebrowser/distinfo,v
retrieving revision 1.10
diff -u -p -r1.10 distinfo
--- distinfo18 Jun 2020 18:17:08 - 1.10
+++ distinfo12 Sep 2020 20:55:45 -
@@ -1,2 +1,2 @@
-SHA256 (qutebrowser-1.12.0.tar.gz) =
QbvV7eK6dNxpHg47WarVndWnQm45v4Ls7dWbTSL03F8=
-SIZE (qutebrowser-1.12.0.tar.gz) = 3979851
+SHA256 (qutebrowser-1.13.1.tar.gz) =
KJaFHwfGJYz4mRl17tIAyoR3rjk6anpAJJA1svNu4tg=
+SIZE (qutebrowser-1.13.1.tar.gz) = 4027485
Index: pkg/PLIST
===
RCS file: /cvs/ports/www/qutebrowser/pkg/PLIST,v
retrieving revision 1.9
diff -u -p -r1.9 PLIST
--- pkg/PLIST 22 May 2020 07:53:20 - 1.9
+++ pkg/PLIST 12 Sep 2020 20:55:46 -
@@ -292,6 +292,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/
lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/caret.js
lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/global_wrapper.js
+lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/globalthis_quirk.user.js
lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/greasemonkey_wrapper.js
lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/history.js
lib/python${MODPY_VERSION}/site-packages/qutebrowser/javascript/pac_utils.js
diff
Description: Binary data
Re: fix GCC 8.4.0 to unbreak -static linking
On Wed, Sep 09, 2020 at 11:42:27AM -0700, j...@bitminer.ca wrote:
> As recommended by Brad, I've updated the fixes
> for all necessary platforms so that -static
> works.
>
> Some platforms already had something like this so this
> set of patches is for a subset of all platforms.
>
> Only tested on amd64.
>
> John
I had a similar diff as to yours. I also added keeping the PowerPC config in
sync
which I noticed had not been kept in sync with the rest.
I was just waiting for George to do some testing on PowerPC.
Index: Makefile
===
RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 Makefile
--- Makefile4 Sep 2020 09:55:34 - 1.34
+++ Makefile13 Sep 2020 00:55:40 -
@@ -18,6 +18,7 @@ DPB_PROPERTIES = parallel
V = 8.4.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
+REVISION = 0
ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
Index: patches/patch-gcc_config_aarch64_openbsd_h
===
RCS file:
/home/cvs/ports/lang/gcc/8/patches/patch-gcc_config_aarch64_openbsd_h,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-gcc_config_aarch64_openbsd_h
--- patches/patch-gcc_config_aarch64_openbsd_h 20 May 2019 14:59:05 -
1.2
+++ patches/patch-gcc_config_aarch64_openbsd_h 4 Sep 2020 20:18:32 -
@@ -57,7 +57,7 @@ Index: gcc/config/aarch64/openbsd.h
+ %{!static:-Bdynamic} \
+ %{rdynamic:-export-dynamic} \
+ %{assert*} \
-+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}} \
++ %{!shared:%{!static:%{!-dynamic-linker:-dynamic-linker
/usr/libexec/ld.so}}} \
+ -L/usr/lib"
+
+#define OPENBSD_ENTRY_POINT "__start"
Index: patches/patch-gcc_config_alpha_openbsd_h
===
RCS file: /home/cvs/ports/lang/gcc/8/patches/patch-gcc_config_alpha_openbsd_h,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-gcc_config_alpha_openbsd_h
--- patches/patch-gcc_config_alpha_openbsd_h20 May 2019 14:59:05 -
1.2
+++ patches/patch-gcc_config_alpha_openbsd_h13 Sep 2020 00:52:52 -
@@ -17,7 +17,7 @@ Index: gcc/config/alpha/openbsd.h
+ %{!static:-Bdynamic} \
+ %{rdynamic:-export-dynamic} \
+ %{assert*} \
-+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}}"
++ %{!shared:%{!static:%{!dynamic-linker:-dynamic-linker
/usr/libexec/ld.so}}}"
+
+/* As an elf system, we need crtbegin/crtend stuff. */
+#undef STARTFILE_SPEC
Index: patches/patch-gcc_config_arm_openbsd_h
===
RCS file: /home/cvs/ports/lang/gcc/8/patches/patch-gcc_config_arm_openbsd_h,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 patch-gcc_config_arm_openbsd_h
--- patches/patch-gcc_config_arm_openbsd_h 20 May 2019 14:59:05 -
1.2
+++ patches/patch-gcc_config_arm_openbsd_h 4 Sep 2020 20:18:32 -
@@ -82,7 +82,7 @@ Index: gcc/config/arm/openbsd.h
+ %{!static:-Bdynamic} \
+ %{rdynamic:-export-dynamic} \
+ %{assert*} \
-+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}} \
++ %{!shared:%{!static:%{!-dynamic-linker:-dynamic-linker
/usr/libexec/ld.so}}} \
+ %{!nostdlib:-L/usr/lib}"
+#endif
+
Index: patches/patch-gcc_config_i386_openbsdelf_h
===
RCS file:
/home/cvs/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 patch-gcc_config_i386_openbsdelf_h
--- patches/patch-gcc_config_i386_openbsdelf_h 8 Aug 2020 16:48:48 -
1.3
+++ patches/patch-gcc_config_i386_openbsdelf_h 9 Sep 2020 22:21:06 -
@@ -3,26 +3,28 @@ $OpenBSD: patch-gcc_config_i386_openbsde
Index: gcc/config/i386/openbsdelf.h
--- gcc/config/i386/openbsdelf.h.orig
+++ gcc/config/i386/openbsdelf.h
-@@ -97,14 +97,18 @@ along with GCC; see the file COPYING3. If not see
+@@ -97,16 +97,20 @@ along with GCC; see the file COPYING3. If not see
%{shared:-shared} %{R*} \
%{static:-Bstatic} \
%{!static:-Bdynamic} \
+ %{rdynamic:-export-dynamic} \
%{assert*} \
- -dynamic-linker /usr/libexec/ld.so"
-+ %{!shared:%{!-dynamic-linker:-dynamic-linker /usr/libexec/ld.so}} \
++ %{!shared:%{!static:%{!-dynamic-linker:-dynamic-linker
/usr/libexec/ld.so}}} \
+ -L/usr/lib"
#undef STARTFILE_SPEC
--#define STARTFILE_SPEC "\
+ #define STARTFILE_SPEC "\
- %{!shared: %{pg:gcrt0%O%s} %{!pg:%{p:gcrt0%O%s} %{!p:crt0%O%s}} \
- crtbegin%O%s} %{shared:crtbeginS%O%s}"
-
-+#define SUBTARGET32_DEFAULT_CPU "i586"
-+#define STARTFILE_SPEC "\
+-
+ %{!shared: %{pg:gcrt0%O%s} %{!pg:%{p:gcrt0%O%s} \
+ %{!p:%{!static:crt0%O%s} %{static:%{nopie:crt0%O%s} \
+ %{!nopie:rcrt0%O%s crtbegin%O%s} %{shared:crtbeginS%O%s}"
#undef ENDFILE_SPEC
#define ENDFILE_SPEC "%
