Qt g++-qmake.conf -Wl,--no-undefined?
Does it makes sense to set QMAKE_LFLAGS_NOUNDEF also for g++?
Rafael
Index: Makefile
===
RCS file: /cvs/ports/x11/qt5/qtbase/Makefile,v
retrieving revision 1.54
diff -u -p -u -p -r1.54 Makefile
--- Makefile13 Jul 2022 15:48:57 - 1.54
+++ Makefile27 Jul 2022 06:07:47 -
@@ -7,7 +7,7 @@ COMMENT-mysql = MySQL plugin for Qt5
COMMENT-psql = PostgresSQL plugin for Qt5
COMMENT-tds = TDS plugin for Qt5
-REVISION-main =10
+REVISION-main =11
REVISION-examples =0
PKGNAME-mysql =qt5-mysql-${VERSION}
Index: files/g++-qmake.conf
===
RCS file: /cvs/ports/x11/qt5/qtbase/files/g++-qmake.conf,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 g++-qmake.conf
--- files/g++-qmake.conf13 Jul 2022 15:48:57 - 1.1
+++ files/g++-qmake.conf27 Jul 2022 06:07:47 -
@@ -16,6 +16,8 @@ isEmpty(LOCALBASE) {
QMAKE_INCDIR_POST = $$LOCALBASE/include
QMAKE_LIBDIR_POST = $$LOCALBASE/lib
+QMAKE_LFLAGS_NOUNDEF= -Wl,--no-undefined
+
include(../common/gcc-base-unix.conf)
include(../common/g++-unix.conf)
clean up qt5/qttranslations
- Use MODQT5_DEPS no to avoid qtbase in LIB_DEPENDS
- Drop PKG_ARCH, qtbase is in RUN_DEPENDS. Makes no sense for me.
- We have no -main -examples in this package, remove WANTLIB- and
LIB_DEPENDS-
Feedback welcome, ok?
Index: Makefile
===
RCS file: /cvs/ports/x11/qt5/qttranslations/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile11 Mar 2022 20:17:03 - 1.5
+++ Makefile27 Jul 2022 05:52:07 -
@@ -1,11 +1,11 @@
QT5NAME = QtTranslations
COMMENT = unofficial Qt5 translations
+REVISION = 0
-PKG_ARCH = *
-WANTLIB- =
-LIB_DEPENDS- =
RUN_DEPENDS = x11/qt5/qtbase>=${QT5_VERSION},<${QT5_NEXT_VERSION}
+BUILD_DEPENDS =x11/qt5/qtbase>=${QT5_VERSION},<${QT5_NEXT_VERSION}
+MODQT5_DEPS = no
MODQT5_USE_CXX11 = No
NO_CCACHE =Yes
Re: Update py-qt5 and friends
Le Thu, Jul 07, 2022 at 08:44:31AM +0200, Rafael Sadowski a écrit : > Here is an update diff to update: > > - x11/py-qt5 > - x11/py-qtawesome > - x11/py-qtpy > - x11/py-sip-qt5 > - editors/qscintilla > - editors/py-qscintilla > - devel/py-qt-builder > - devel/py-sip > - www/py-qtwebengine > > veusz need to be fixed before we can discuss to update this but I think > it makes sense to share is work. I tested geo/qgis and www/qutebrowser > with the qt5.15.5 update and the diff below at runtime. can confirm that qgis works fine as before, after having rebuilt it with all the other ports built from your diff: qgis-3.26.1:py3-ply-3.11p4: ok qgis-3.26.1:py3-sip-6.4.0p0v0->6.6.2v0: ok qgis-3.26.1:py3-pyqt5_sip-12.9.0p1->12.11.0: ok qgis-3.26.1:py3-qt5-5.15.6p0->5.15.7: ok qscintilla-2.11.6->2.13.3 forward dependencies: | Dependency of py3-qscintilla-2.11.6p1 on qscintilla-=2.11.6 doesn't match Merging py3-qscintilla-2.11.6p1->2.13.3 (ok) qgis-3.26.1:py3-qscintilla-2.11.6p1+qscintilla-2.11.6->py3-qscintilla+qscintilla-2.13.3:ok also regarding devel/py-sip/patches/patch-sipbuild_generator_parser_instantiations_py i hope it'll get pushed/reported upstream. ok for me, as far as qgis is concerned, and thanks for the hard work :) Landry
Re: [patch] update irssi to 1.4.2
Stuart Henderson writes:
> On 2022/07/25 19:12, Nam Nguyen wrote:
>> 2. Should the meson.build patch be used? It patches
>> /usr/local/share/irssi --> /usr/local/share/examples/irssi. I'm
>> preserving the behavior from before but I'm also fine not carrying this
>> patch. The important part is that /etc/irssi/irssi.conf is used, via the
>> @sample tags.
>
> I think the package should install those files under share/examples,
> that is the location where users expect to find them. Just make sure that
> the /etc/irssi bits are used at runtime. Would be worth running strings
> on the object files and search output for share/examples which should
> probably not show up.
strings revealed that share/examples was used for themes. I followed:
https://www.openbsd.org/faq/ports/specialtopics.html#Config
Note the distinction between configuration files and example
configuration files:...
I learned that the port must use /etc but it must install files only
under /usr/local. (incorrectly installing to /etc was caught by
update-plist: "Can't put into any plist (no applicable prefix)".) The
solution was to add a post-install snippet to mv files from /etc to
share/examples.
Now, the previous port behavior of using /etc/irssi is restored. I am
able to use themes and scripts from /etc and ~/.irssi, and it never
uses share/examples.
$ strings /usr/local/bin/irssi | ag share/examples
$ strings /usr/local/bin/irssi | ag /etc/irssi
/etc/irssi/irssi.conf
/etc/irssi/themes/%s.theme
$ strings /usr/local/lib/irssi/modules/libfe_perl.so | ag share/examples
$ strings /usr/local/lib/irssi/modules/libfe_perl.so | ag /etc/irssi
/etc/irssi/scripts
$ strings /usr/local/lib/irssi/modules/libperl_core.so
use lib qw(%s/scripts /etc/irssi/scripts %s);
/etc/irssi/scripts/%s
>> - MACHINE_ARCH stuff has been removed from the perl paths.
>> libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/Irssi/
>> This seems harmless because net/twirssi still works.
>
> Perl will still search there, but this is not correct, and no other
> port installs binary modules there:
>
> $ pkglocate /site_perl/|grep '\.so$'|grep -v site_perl/amd64-openbsd/ | wc -l
>0
>
> Just remove the -Dwith-perl-lib line and regen plist.
this fresh diff additionally:
- restores perl ${MACHINE_ARCH} paths
- uses SUBST_CMD, meson.build patch and post-install snippet to
configure the port to use /etc/irssi/ and install sample configuration
files to share/examples/irssi/
@sample ${SYSCONFDIR}/irssi/{,scripts,themes} keep getting shoved to
near the top of the file so I left them there to make future updates
less noisy.
Index: Makefile
===
RCS file: /cvs/ports/net/irssi/Makefile,v
retrieving revision 1.97
diff -u -p -u -p -r1.97 Makefile
--- Makefile23 Jun 2022 02:21:35 - 1.97
+++ Makefile27 Jul 2022 02:01:02 -
@@ -6,7 +6,7 @@ MULTI_PACKAGES = -main -otr
COMMENT-main = modular IRC client with many features
COMMENT-otr = OTR (off-the-record) plugin for irssi
-V =1.4.1
+V =1.4.2
DISTNAME = irssi-$V
PKGSPEC-main = irssi-=$V
PKGNAME-main = irssi-$V
@@ -19,43 +19,41 @@ HOMEPAGE = https://www.irssi.org/
# GPLv2+
PERMIT_PACKAGE = Yes
-WANTLIB += c crypto curses glib-2.0 gmodule-2.0 \
- iconv intl m pcre perl pthread ssl
+WANTLIB += c crypto curses glib-2.0 gmodule-2.0 m perl ssl
MASTER_SITES = https://github.com/irssi/irssi/releases/download/${V}/
DEBUG_PACKAGES = ${BUILD_PACKAGES}
+MODULES = devel/meson
+
LIB_DEPENDS = devel/glib2>=2.28.0
-RUN_DEPENDS-otr = net/irssi,-main
-LIB_DEPENDS-otr = security/libgcrypt>=1.2.0 \
- security/libotr>=4.1.0
-WANTLIB-otr = gcrypt gpg-error iconv intl otr
-
-LIBTOOL_FLAGS += --tag=disable-static
-
-CONFIGURE_STYLE = gnu
-CONFIGURE_ARGS = --disable-utf8proc \
- --with-otr=module \
- --with-perl-lib=${PREFIX}/libdata/perl5/site_perl \
- --with-perl=yes \
- --with-pic \
- --with-proxy
-CONFIGURE_ENV += CPPFLAGS="-I${LOCALBASE}/include" \
- LDFLAGS="-L${LOCALBASE}/lib"
-SEPARATE_BUILD = Yes
-
-MAKE_FLAGS = scriptdir="${SYSCONFDIR}/irssi/scripts" \
- themedir="${SYSCONFDIR}/irssi/themes"
-FAKE_FLAGS = confdir="${PREFIX}/share/examples/irssi" \
- scriptdir="${PREFIX}/share/examples/irssi/scripts" \
- themedir="${PREFIX}/share/examples/irssi/themes"
+MODMESON_CONFIGURE_ARGS += -Ddisable-utf8proc=yes \
+ -Dwith-otr=yes \
+ -Dwith-perl=yes \
+ -Dwith-proxy=yes
+
+RUN_DEPENDS-otr = net/irssi,-main
+LIB_DEPENDS-otr = devel/glib2>=2.28.0 \
+ security/libgcrypt>=1.2.0 \
+ security/libotr>=4.1.0
+
+WANTLIB-
Re: [MAINTAINER UPDATE] textproc/lowdown to 1.0.0
On Mon, Jul 25, 2022 at 09:45:43PM +0200, Omar Polo wrote: > Bryan Vyhmeister wrote: > > This is another maintainer update of lowdown from 0.10.0 to 1.0.0. > > There are quite a few changes included in the in-between releases. The > > changes included are: > > > > [...] > > > > I did testing on amd64 with no issues. It does appear that the > > liblowdown static library is no more also in case someone is using that. > > I believe it should work fine everywhere. If someone could ok and > > commit, that would be great. Thank you. > > > > Bryan > > works fine here, but I think it'd be better if we keep the library, the > header and the manpages :) > > it seems that now an additional FAKE_TARGET is needed. diff below > addresses that and also adds the proper SHARED_LIBS now that the port > has one. Your patch does not compile for me. It seems that those extra man pages have been removed from the release. Bryan
[UPDATE] fonts/junicode to 1.003
diff attached.
Source moved from Sourceforge to Github.
Moved to font MODULES.
thanks
gIndex: junicode//Makefile
===
RCS file: /cvs/ports/fonts/junicode/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- junicode//Makefile 11 Mar 2022 19:00:21 - 1.7
+++ junicode//Makefile 18 Jul 2022 23:51:09 -
@@ -1,27 +1,23 @@
-COMMENT = advanced Unicode font for medievalists
-DISTNAME = junicode-1.002
-EXTRACT_SUFX = .zip
-CATEGORIES = fonts
+COMMENT = advanced Unicode font for medievalists
-HOMEPAGE = http://junicode.sourceforge.net/
-MAINTAINER = George Rosamond
+TYPEFACE = junicode
+V = 1.003
-# OFL
-PERMIT_PACKAGE = Yes
+DISTFILES = v${V}.zip
+MASTER_SITES = https://github.com/psb1558/Junicode-font/archive/refs/tags/
+
+MAINTAINER = George Rosamond
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=junicode/}
+# SIL OFL 1.1
+PERMIT_PACKAGE = Yes
MODULES = font
NO_BUILD = Yes
NO_TEST = Yes
+PKG_ARCH = *
-FONTDIR = ${PREFIX}/share/fonts/junicode
-DOCDIR = ${PREFIX}/share/doc/junicode
-
-do-install:
- ${INSTALL_DATA_DIR} ${FONTDIR} ${DOCDIR}
- ${INSTALL_DATA} ${WRKDIR}/*.ttf ${FONTDIR}
- ${INSTALL_DATA} ${WRKDIR}/doc/*.pdf ${DOCDIR}
+WRKDIST = ${WRKDIR}/Junicode-font-1.003
+WRKSRC = ${WRKDIST}/legacy
.include
Index: junicode//distinfo
===
RCS file: /cvs/ports/fonts/junicode/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- junicode//distinfo 24 Oct 2018 11:14:30 - 1.3
+++ junicode//distinfo 18 Jul 2022 23:51:09 -
@@ -1,2 +1,2 @@
-SHA256 (junicode-1.002.zip) = wZnZbIQkvmD8q40A0u7jnqiuYyz9XnEMu9cGJtanKec=
-SIZE (junicode-1.002.zip) = 1451694
+SHA256 (v1.003.zip) = ZN3FqjjBW9y2ovx6nqcbf4/mqlsYbB6JNesfbPTYqmk=
+SIZE (v1.003.zip) = 3929938
Index: junicode//pkg/PLIST
===
RCS file: /cvs/ports/fonts/junicode/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- junicode//pkg/PLIST 11 Mar 2022 19:00:21 - 1.3
+++ junicode//pkg/PLIST 18 Jul 2022 23:51:09 -
@@ -1,7 +1,3 @@
-share/doc/junicode/
-share/doc/junicode/Junicode.pdf
-share/doc/junicode/aelfric_job.pdf
-share/doc/junicode/homer_sample.pdf
share/fonts/
@fontdir share/fonts/junicode/
share/fonts/junicode/FoulisGreek.ttf
[NEW] net/py-websockets
from pkg/DESCR:
websockets is a library for building WebSocket servers and clients
in Python with a focus on correctness, simplicity, robustness, and
performance.
Built on top of asyncio, Python's standard asynchronous I/O framework,
it provides an elegant coroutine-based API.
***
This is a very common websocket implementation as per
https://repology.org/project/python:websockets/versions.
***
`python3.9 -m unittest` runs fine from ${WRKDIST} with:
Ran 1016 tests in 4.833s
FAILED (failures=9)
***
Note that the PyPi and Github versions are out of sync. PyPi has version
10.3 on 20220417, while Github moved to 10.4 at the same time:
https://github.com/aaugustin/websockets/commit/3742b429a25d5f51511b626435c6a1acdd9027a3
***
In terms of CATEGORIES not sure of best option.
OpenBSD ports has:
www/libwebsockets
net/py-websocket-client (for which it's an optional TEST_DEPEND)
So I went with net/ for now.
g
py-websockets-10.4.tgz
Description: Binary data
[MAINTAINER UPDATE] archivers/zpaqfranz-55.7
Small update for zpaqfranz 55.5 -> 55.7. In theory, the author has fixed the -DNOJIT build for !amd64 in this version, but without an !amd64 machine ready, I probably won't add it to the Makefile again... :) tux0r. zpaqfranz-55.7.diff Description: Binary data
Re: sparc64 bulk build report
On Tue, Jul 26, 2022 at 10:32:15PM +0200, Rafael Sadowski wrote:
> > http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt6/qtdeclarative.log
> https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
> OpenSUSE confirmed that with following patch they can build Qt on SPARC:
> https://github.com/bmwiedemann/openSUSE/blob/934d586b71984cbf31d8ecb30dc8ac7f90369929/packages/q/qt6-shadertools/0001-Fix-encoding-decoding-of-string-literals-for-big-end.patch
> OK?
ok kmos
--Kurt
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/qt6/qtshadertools/Makefile,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 Makefile
> --- Makefile 12 May 2022 09:40:33 - 1.4
> +++ Makefile 26 Jul 2022 20:27:24 -
> @@ -1,6 +1,7 @@
> QT6NAME =QtShaderTools
>
> COMMENT =Qt6 shader tools module
> +REVISION = 0
>
> PKGSPEC =qt6-qtshadertools-${QT6_PKGSPEC}
>
> Index: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
> ===
> RCS file: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
> diff -N patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp 26 Jul 2022
> 20:27:24 -
> @@ -0,0 +1,39 @@
> +Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
> +words with little-endian convention. Explicitly perform that encoding
> +instead of assuming that the host system is little-endian.
> +
> +Note that this change requires corresponding fixes in SPIRV-Tools.
> +
> +Fixes #202
> +https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
> +Index: src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
> +--- src/3rdparty/glslang/SPIRV/SPVRemapper.cpp.orig
> src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
> +@@ -297,15 +297,21 @@ namespace spv {
> + std::string spirvbin_t::literalString(unsigned word) const
> + {
> + std::string literal;
> ++const spirword_t * pos = spv.data() + word;
> +
> + literal.reserve(16);
> +
> +-const char* bytes = reinterpret_cast(spv.data() +
> word);
> +-
> +-while (bytes && *bytes)
> +-literal += *bytes++;
> +-
> +-return literal;
> ++do {
> ++spirword_t word = *pos;
> ++for (int i = 0; i < 4; i++) {
> ++char c = word & 0xff;
> ++if (c == '\0')
> ++return literal;
> ++literal += c;
> ++word >>= 8;
> ++}
> ++pos++;
> ++} while (true);
> + }
> +
> + void spirvbin_t::applyMap()
> Index: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
> ===
> RCS file: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
> diff -N patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp 26 Jul 2022
> 20:27:24 -
> @@ -0,0 +1,104 @@
> +Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
> +words with little-endian convention. Explicitly perform that encoding
> +instead of assuming that the host system is little-endian.
> +
> +Note that this change requires corresponding fixes in SPIRV-Tools.
> +
> +Fixes #202
> +https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
> +Index: src/3rdparty/glslang/SPIRV/disassemble.cpp
> +--- src/3rdparty/glslang/SPIRV/disassemble.cpp.orig
> src/3rdparty/glslang/SPIRV/disassemble.cpp
> +@@ -43,6 +43,7 @@
> + #include
> + #include
> + #include
> ++#include
> +
> + #include "disassemble.h"
> + #include "doc.h"
> +@@ -100,6 +101,7 @@ class SpirvStream { (protected)
> + void outputMask(OperandClass operandClass, unsigned mask);
> + void disassembleImmediates(int numOperands);
> + void disassembleIds(int numOperands);
> ++std::pair decodeString();
> + int disassembleString();
> + void disassembleInstruction(Id resultId, Id typeId, Op opCode, int
> numOperands);
> +
> +@@ -290,31 +292,44 @@ void SpirvStream::disassembleIds(int numOperands)
> + }
> + }
> +
> +-// return the number of operands consumed by the string
> +-int SpirvStream::disassembleString()
> ++// decode string from words at current position (non-consuming)
> ++std::pair SpirvStream::decodeString()
> + {
> +-int startWord = word;
> +-
> +-out << " \"";
> +-
> +-const char* wordString;
> ++std::string res;
> ++int wordPos = word;
> ++char c;
> + bool done = false;
> ++
> + do {
> +-unsigned int content = stream[word];
> +-wordString = (const char*)&content;
> ++unsigned int content = stream[wordPos];
> + for (int charCount = 0; charCount < 4; +
Re: sparc64 bulk build report
On Tue, Jul 26, 2022 at 10:39:09PM +0200, Rafael Sadowski wrote: > > http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt5/qttranslations.log > "Project ERROR: failed to parse default search paths from compiler output" > Bulk build issue? I don't know. Lots of ports that use qmake are failing with that error. Off the top of my head textproc/xxdiff is another example. --Kurt
Re: sparc64 bulk build report
On Sun Jul 24, 2022 at 10:40:00PM -0600, k...@openbsd.org wrote: > Bulk build on sparc64-0a.ports.openbsd.org > > Started : Fri Jul 22 09:17:32 MDT 2022 > Finished: Sun Jul 24 22:39:26 MDT 2022 > Duration: 2 Days 13 hours 22 minutes > > Built using OpenBSD 7.2-beta (GENERIC.MP) #1386: Thu Jul 21 08:50:25 MDT 2022 > > Built 9315 packages > > Number of packages built each day: > Jul 22: 7026 > Jul 23: 1482 > Jul 24: 807 > > > Critical path missing pkgs: > http://build-failures.rhaalovely.net/sparc64/2022-07-22/summary.log > > Build failures: 38 > http://build-failures.rhaalovely.net/sparc64/2022-07-22/devel/kf5/kio.log kio use std::transform_reduce which is not supported by our libestdc++ lib?! > http://build-failures.rhaalovely.net/sparc64/2022-07-22/devel/qcoro.log "eg++: error: unrecognized command line option '-fcoroutines'; did you mean '-fc-prototypes'?" No coroutines support in your old ports g++ > http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt5/qttranslations.log "Project ERROR: failed to parse default search paths from compiler output" Bulk build issue?
Re: sparc64 bulk build report
On Sun Jul 24, 2022 at 10:40:00PM -0600, k...@openbsd.org wrote:
> Bulk build on sparc64-0a.ports.openbsd.org
>
> Started : Fri Jul 22 09:17:32 MDT 2022
> Finished: Sun Jul 24 22:39:26 MDT 2022
> Duration: 2 Days 13 hours 22 minutes
>
> Built using OpenBSD 7.2-beta (GENERIC.MP) #1386: Thu Jul 21 08:50:25 MDT 2022
>
> Built 9315 packages
>
> Number of packages built each day:
> Jul 22: 7026
> Jul 23: 1482
> Jul 24: 807
>
>
> Critical path missing pkgs:
> http://build-failures.rhaalovely.net/sparc64/2022-07-22/summary.log
>
> Build failures: 38
> http://build-failures.rhaalovely.net/sparc64/2022-07-22/x11/qt6/qtdeclarative.log
>
https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
OpenSUSE confirmed that with following patch they can build Qt on SPARC:
https://github.com/bmwiedemann/openSUSE/blob/934d586b71984cbf31d8ecb30dc8ac7f90369929/packages/q/qt6-shadertools/0001-Fix-encoding-decoding-of-string-literals-for-big-end.patch
OK?
Index: Makefile
===
RCS file: /cvs/ports/x11/qt6/qtshadertools/Makefile,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 Makefile
--- Makefile12 May 2022 09:40:33 - 1.4
+++ Makefile26 Jul 2022 20:27:24 -
@@ -1,6 +1,7 @@
QT6NAME = QtShaderTools
COMMENT = Qt6 shader tools module
+REVISION = 0
PKGSPEC = qt6-qtshadertools-${QT6_PKGSPEC}
Index: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
===
RCS file: patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
diff -N patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_3rdparty_glslang_SPIRV_SPVRemapper_cpp26 Jul 2022
20:27:24 -
@@ -0,0 +1,39 @@
+Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
+words with little-endian convention. Explicitly perform that encoding
+instead of assuming that the host system is little-endian.
+
+Note that this change requires corresponding fixes in SPIRV-Tools.
+
+Fixes #202
+https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
+Index: src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
+--- src/3rdparty/glslang/SPIRV/SPVRemapper.cpp.orig
src/3rdparty/glslang/SPIRV/SPVRemapper.cpp
+@@ -297,15 +297,21 @@ namespace spv {
+ std::string spirvbin_t::literalString(unsigned word) const
+ {
+ std::string literal;
++const spirword_t * pos = spv.data() + word;
+
+ literal.reserve(16);
+
+-const char* bytes = reinterpret_cast(spv.data() + word);
+-
+-while (bytes && *bytes)
+-literal += *bytes++;
+-
+-return literal;
++do {
++spirword_t word = *pos;
++for (int i = 0; i < 4; i++) {
++char c = word & 0xff;
++if (c == '\0')
++return literal;
++literal += c;
++word >>= 8;
++}
++pos++;
++} while (true);
+ }
+
+ void spirvbin_t::applyMap()
Index: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
===
RCS file: patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
diff -N patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_3rdparty_glslang_SPIRV_disassemble_cpp26 Jul 2022
20:27:24 -
@@ -0,0 +1,104 @@
+Per SPIR-V spec, a string literal's UTF-8 octets are encoded packed into
+words with little-endian convention. Explicitly perform that encoding
+instead of assuming that the host system is little-endian.
+
+Note that this change requires corresponding fixes in SPIRV-Tools.
+
+Fixes #202
+https://bugreports.qt.io/browse/QTBUG-100125?gerritReviewStatus=All
+Index: src/3rdparty/glslang/SPIRV/disassemble.cpp
+--- src/3rdparty/glslang/SPIRV/disassemble.cpp.orig
src/3rdparty/glslang/SPIRV/disassemble.cpp
+@@ -43,6 +43,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #include "disassemble.h"
+ #include "doc.h"
+@@ -100,6 +101,7 @@ class SpirvStream { (protected)
+ void outputMask(OperandClass operandClass, unsigned mask);
+ void disassembleImmediates(int numOperands);
+ void disassembleIds(int numOperands);
++std::pair decodeString();
+ int disassembleString();
+ void disassembleInstruction(Id resultId, Id typeId, Op opCode, int
numOperands);
+
+@@ -290,31 +292,44 @@ void SpirvStream::disassembleIds(int numOperands)
+ }
+ }
+
+-// return the number of operands consumed by the string
+-int SpirvStream::disassembleString()
++// decode string from words at current position (non-consuming)
++std::pair SpirvStream::decodeString()
+ {
+-int startWord = word;
+-
+-out << " \"";
+-
+-const char* wordString;
++std::string res;
++int wordPos = word;
++c
[maintainer update] nnn 4.5 -> 4.6
This patch updates nnn from 4.5 to 4.6.
Tested on amd64.
Index: Makefile
===
RCS file: /cvs/ports/sysutils/nnn/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile27 Apr 2022 10:39:15 - 1.20
+++ Makefile26 Jul 2022 14:21:29 -
@@ -1,6 +1,6 @@
COMMENT = the missing terminal file browser for X
-V =4.5
+V =4.6
DISTNAME = nnn-v${V}
PKGNAME = nnn-${V}
Index: distinfo
===
RCS file: /cvs/ports/sysutils/nnn/distinfo,v
retrieving revision 1.16
diff -u -p -r1.16 distinfo
--- distinfo27 Apr 2022 10:39:15 - 1.16
+++ distinfo26 Jul 2022 14:21:29 -
@@ -1,2 +1,2 @@
-SHA256 (nnn-v4.5.tar.gz) = +twVvW1EAMBuXMxHhFtC5gd082hXDkdb2IJ2fuGHSao=
-SIZE (nnn-v4.5.tar.gz) = 242191
+SHA256 (nnn-v4.6.tar.gz) = FayvmojPtaKmQNPvVaSK9kT7qStGqsB2jv6UxK3ffj8=
+SIZE (nnn-v4.6.tar.gz) = 248458
Re: Update py-qt5 and friends
On 7/26/2022 10:08 AM, Landry Breuil wrote: > Le Tue, Jul 26, 2022 at 01:57:00PM +, Brian Callahan a écrit : >> On 7/26/2022 9:43 AM, Landry Breuil wrote: >>> Le Sun, Jul 24, 2022 at 12:20:03PM +0200, Caspar Schutijser a écrit : I build-tested this and also did some runtime testing of Calibre and that seems to work fine. So in that sense it's OK. But the veusz problem is still there, right? I looked around in some other ports collections but I've not been able to find a patch we can borrow. So I guess someone actually has to look at the problem. Don't have time for that myself right now. >>> >>> there's an example on >>> https://github.com/veusz/veusz/issues/595#issuecomment-1193392261 but it >>> looks... only for sip wizards. >>> >>> bcallah, what's your opinion as math/veusz maintainer ? >>> >>> Landry >>> >> >> I won't be able to look at this until the weekend. I will have to become >> a sip wizard I suppose. >> >> If the py-qt5 update needs to go in and veusz is the only blocker, I >> suppose we can mark veusz BROKEN until then. I know it's not ideal, but >> I don't see a better option in that case. > > I wouldnt say it 'needs to go in' but usually they're a large pain as > several ports (sip,qscintilla,pyqt...) have to be updated altogether and > all the consumers need to bec checked, rafael did the hard work and > usually if those diffs accumulate they tend to get stale/conflicts and > the person doing the work loses motivation :) > > Landry That sounds close enough to "needs to go in" for me :) Let's get py-qt5 in, mark veusz as BROKEN and I'll do my best to make the length of time veusz is broken as short as possible. ~Brian
Re: Update py-qt5 and friends
Le Tue, Jul 26, 2022 at 01:57:00PM +, Brian Callahan a écrit : > On 7/26/2022 9:43 AM, Landry Breuil wrote: > > Le Sun, Jul 24, 2022 at 12:20:03PM +0200, Caspar Schutijser a écrit : > >> I build-tested this and also did some runtime testing of Calibre and > >> that seems to work fine. So in that sense it's OK. But the veusz > >> problem is still there, right? I looked around in some other ports > >> collections but I've not been able to find a patch we can borrow. So > >> I guess someone actually has to look at the problem. Don't have time > >> for that myself right now. > > > > there's an example on > > https://github.com/veusz/veusz/issues/595#issuecomment-1193392261 but it > > looks... only for sip wizards. > > > > bcallah, what's your opinion as math/veusz maintainer ? > > > > Landry > > > > I won't be able to look at this until the weekend. I will have to become > a sip wizard I suppose. > > If the py-qt5 update needs to go in and veusz is the only blocker, I > suppose we can mark veusz BROKEN until then. I know it's not ideal, but > I don't see a better option in that case. I wouldnt say it 'needs to go in' but usually they're a large pain as several ports (sip,qscintilla,pyqt...) have to be updated altogether and all the consumers need to bec checked, rafael did the hard work and usually if those diffs accumulate they tend to get stale/conflicts and the person doing the work loses motivation :) Landry
Re: Update py-qt5 and friends
On 7/26/2022 9:43 AM, Landry Breuil wrote: > Le Sun, Jul 24, 2022 at 12:20:03PM +0200, Caspar Schutijser a écrit : >> I build-tested this and also did some runtime testing of Calibre and >> that seems to work fine. So in that sense it's OK. But the veusz >> problem is still there, right? I looked around in some other ports >> collections but I've not been able to find a patch we can borrow. So >> I guess someone actually has to look at the problem. Don't have time >> for that myself right now. > > there's an example on > https://github.com/veusz/veusz/issues/595#issuecomment-1193392261 but it > looks... only for sip wizards. > > bcallah, what's your opinion as math/veusz maintainer ? > > Landry > I won't be able to look at this until the weekend. I will have to become a sip wizard I suppose. If the py-qt5 update needs to go in and veusz is the only blocker, I suppose we can mark veusz BROKEN until then. I know it's not ideal, but I don't see a better option in that case. ~Brian
Re: Update py-qt5 and friends
Le Sun, Jul 24, 2022 at 12:20:03PM +0200, Caspar Schutijser a écrit : > I build-tested this and also did some runtime testing of Calibre and > that seems to work fine. So in that sense it's OK. But the veusz > problem is still there, right? I looked around in some other ports > collections but I've not been able to find a patch we can borrow. So > I guess someone actually has to look at the problem. Don't have time > for that myself right now. there's an example on https://github.com/veusz/veusz/issues/595#issuecomment-1193392261 but it looks... only for sip wizards. bcallah, what's your opinion as math/veusz maintainer ? Landry
Re: WIP: Tor Browser 11.5
Le Sat, Jul 23, 2022 at 08:33:55PM +0200, Caspar Schutijser a écrit :
> Hi,
>
> My diff for Tor Browser 11.5 is finally in good enough shape to show it.
> I only did limited testing so far so I'd like interested users to help.
> Please try the diff and report if anything didn't work as before. I
> still need to handle the removal of HTTPS Everywhere (its presence
> doesn't harm though) and I want to do some more reviewing myself.
> More information here:
> https://blog.torproject.org/new-release-tor-browser-115/
>
> -DISTNAME = src-firefox-tor-browser-91.10.0esr-11.0-1-build1
> +DISTNAME = src-firefox-tor-browser-91.11.0esr-11.5-1-build1
im confused now.. i thought tor-browser upstream bumped the minor when
using a newer upstream mozilla esr branch, but they're still on 91 ?
it's dead in 1 or 2 months...
> FIX_EXTRACT_PERMISSIONS = Yes
> EXTRACT_ONLY += ${DISTNAME}.tar.xz \
> @@ -74,7 +74,8 @@ CONFIGURE_ENV +=M4=/usr/local/bin/gm4
> # app-name etc. for tor-browser
> CONFIGURE_ARGS +=--with-app-name=${BROWSER_NAME} \
> --with-tor-browser-version=${TB_VERSION}\
> - --disable-tor-browser-update
> + --disable-tor-browser-update\
> + --enable-tor-browser-data-outside-app-dir
seems you have disable-tor-browser-update here and in the mozconfig
patches (eg patch-browser_config_mozconfigs_tor-browser) - maybe one of
them is too much ?
> SHA256 (mozilla/https-everywhere-2021.4.15-eff.xpi) =
> fl9ygI6hSL7M1BbsvfM+oevEOkMuTnhbXl4TObeitwg=
to remove i guess ? :)
Landry
Re: [patch] update irssi to 1.4.2
On 2022/07/25 19:12, Nam Nguyen wrote:
>
> 2 questions
> ===
> I was getting an infinite loop with `make install'.
>
> Detected loop, merging sets ok
> |
> debug-irssi-1.4.1+irssi-1.4.1+irssi-icb-0.17p2+irssi-otr-1.4.1->debug-irssi-1.
> Detected loop, merging sets ok
> |
> debug-irssi-1.4.1+irssi-1.4.1+irssi-icb-0.17p2+irssi-otr-1.4.1->debug-irssi-1.
This is kind-of expected with tight dependencies like in irssi, dovecot,
and some other ports. Anyway, due to the tight dependency (checked in
irssi code itself) you must rebuild new versions of dependent ports
*after* installing the new irssi, therefore you need to remove the old
chain of installed packages.
> PKGSPEC is defined. (PKGSPEC-main = irssi-=$V). I see the bump comment:
> # XXX -stable package builds can't detect PKGSPEC updates properly;
>
> 1. Is my understanding correct? -current will be able to detect PKGSPEC
> updates and rebuild net/irssi-icb and net/twirssi without needing to
> bump their REVISION for every update of irssi. Thus, the infinite loop
> is not an issue when pkg_add -u is run.
Correct. The problem is in the scripts which decide what to build for
-stable packages. They don't have much ports-internal knowledge and
rely on things like parsing cvs logs.
> 2. Should the meson.build patch be used? It patches
> /usr/local/share/irssi --> /usr/local/share/examples/irssi. I'm
> preserving the behavior from before but I'm also fine not carrying this
> patch. The important part is that /etc/irssi/irssi.conf is used, via the
> @sample tags.
I think the package should install those files under share/examples,
that is the location where users expect to find them. Just make sure that
the /etc/irssi bits are used at runtime. Would be worth running strings
on the object files and search output for share/examples which should
probably not show up.
> this diff:
> ==
> - updates to 1.4.2
> - switches to meson
> - removes SUBST_CMD of irssi.1
> - installs irssi.conf
> - removes Makefile.in patches
> passes portcheck and `make port-lib-depends-check' with the following:
> - WANTLIB uses glib-2.0 and removes iconv/intl/pthread, which are
> WANTLIBs of glib-2.0 anyways.
> - add devel/glib2 to LIB_DEPENDS-otr
> - WANTLIB-otr uses glib-2.0 and removes iconv/intl likewise. removal of
> gpg-error seems harmless.
>
> plist changes:
> ==
> plist was a bit tricky as it involved manual edits.
> - @so lib/irssi/modules/libfe_perl.so and +@so
> lib/irssi/modules/libperl_core.so ended up in PLIST-otr so I moved them
> into PLIST-main.
> - keeps @pkgpath net/irssi,socks for the removed flavor
that all sounds good
> - MACHINE_ARCH stuff has been removed from the perl paths.
> libdata/perl5/site_perl/${MACHINE_ARCH}-openbsd/Irssi/
> This seems harmless because net/twirssi still works.
Perl will still search there, but this is not correct, and no other
port installs binary modules there:
$ pkglocate /site_perl/|grep '\.so$'|grep -v site_perl/amd64-openbsd/ | wc -l
0
Just remove the -Dwith-perl-lib line and regen plist.
> - command.pl, msg-event.pl and redirect.pl have been removed. These are
> found in ${WRKSRC}/scripts/examples and ${WRKSRC}/scripts/meson.build
> does not mention installing them so we also shouldn't bother.
that's probably ok.
> - .la files were removed automatically
> - Files had to be wrangled to emulate the layout from before.
> see: https://namtsui.com/public/irssi_tree.txt
> for the layout from the previous irssi for
> /usr/local/share/examples/irssi and /etc/irssi.
>
> I patched meson.build to have themedir and scriptdir point to
> examples. Then, I manually inserted @sample lines into the plist.
>
> example:
> share/examples/irssi/scripts/autoop.pl
> @sample ${SYSCONFDIR}/irssi/scripts/autoop.pl
>
> >
> > https://irssi.org/2022/07/17/irssi-1.4.2-released/
> >
>
> Testing
> ===
> net/twirssi, net/irssi-icb, and irssi-otr work. However, irssi-proxy did
> not work following these instructions:
> https://irssi.org/modules/
> https://github.com/irssi/irssi/blob/master/docs/proxy.txt
> bug: https://github.com/irssi/irssi/issues/1307
> I left proxy in there anyways though in the hopes that it works in the
> future.
>
> `make test' passes. `portcheck' and `make port-lib-depends' pass. I
> tested irssi's /etc/irssi/scripts/quitmsg.pl.
>
> Feedback and tests are welcome. OK?
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/irssi/Makefile,v
> retrieving revision 1.97
> diff -u -p -u -p -r1.97 Makefile
> --- Makefile 23 Jun 2022 02:21:35 - 1.97
> +++ Makefile 26 Jul 2022 01:39:28 -
> @@ -6,7 +6,7 @@ MULTI_PACKAGES = -main -otr
> COMMENT-main = modular IRC client with many features
> COMMENT-otr =OTR (off-the-record) plugin for irssi
>
> -V = 1.4.1
> +V = 1.4.2
> DISTNAME = irssi-$V
> PKGSPEC-main = irssi-=$V
> PKGNAME-main
Re: [NEW/Update] net/nicotine-plus-3.2.2 port
On 2022/07/25 09:48, Omar Polo wrote: > some nits: > > - we've dropped the RCS Ids (the $OpenBSD$ line) in ports > - i'd set CATEGORIES, HOMEPAGE and MAINTAINER after GH_* as per >Makefile.template > - no need to set MODPY_VERSION, that's already the default agreed on these > Personally, I'd go with a patch instead of sed -i for setup.py, but even > using sed -i should be fine in this case. (patches are more robust than > sed for updates; they break sometimes, but at least you get the chance > to see what's going on instead of blindling substituting.) +1 for this
Re: [NEW/Update] net/nicotine-plus-3.2.2 port
Omar Polo wrote: > Hello, > > "mdw" wrote: > > Hi, > > > > Nicotine+ is a graphical client for the Soulseek peer-to-peer network. > > https://github.com/nicotine-plus/nicotine-plus > > > > Over a year ago v3.0.0 was submitted to ports@, but didn't get any response > > https://marc.info/?l=openbsd-ports&m=161310210623977&w=2 > > > > Here is an updated version 3.2.2, apologies if anything looks funny it is > > my first time working with ports. > > it's not bad, there are just a couple of things to adjust but it's a > solid first submission :) > > > I tested briefly search/chat rooms/transfers on my system running -current > > and it seems to work fine. All of the hard work was done with the original > > submission I just updated a few things. > > > > Thanks, > > Matthew > > some nits: > > - we've dropped the RCS Ids (the $OpenBSD$ line) in ports > - i'd set CATEGORIES, HOMEPAGE and MAINTAINER after GH_* as per >Makefile.template > - no need to set MODPY_VERSION, that's already the default > > Personally, I'd go with a patch instead of sed -i for setup.py, but even > using sed -i should be fine in this case. (patches are more robust than > sed for updates; they break sometimes, but at least you get the chance > to see what's going on instead of blindling substituting.) > > I'm attaching a diff against your Makefile with those nit fixed and an > updated tarball. I haven't really run-tested it more than clicking > around in the GUI (didn't want to mess around with the firewall atm) but > the port looks good and (assuming it works) it's OK op@ to import if > someone wants to. > > (+cc Han, the previous submitter) > > #application/x-gzip: /tmp/nicotine-plus.tar.gz wops, forgot to actually attach the updated port... while here i've dropped Han as maintainer, feel free to add yourself :) nicotine-plus.tar.gz Description: GNU Zip compressed data
