CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/25 00:43:17 Modified files: security/nss : Makefile distinfo Log message: security/nss: update to 3.61. Will be required by gecko 86. See https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.61_release_notes
Re: collision in python-3.8.6 when upgrading 6.7 to snapshot
On Thu, Oct 08, 2020 at 11:42:53AM +0100, Stuart Henderson wrote: > On 2020/10/08 02:33, James Cook wrote: > > I'm reporting a slight hiccup upgrading from 6.7 to snapshot. This might > > count as my own fault, but reporting it in case it's something that's > > supposed to run smoothly. (I was able to recover; no help needed.) > > > > I upgraded from 6.7 to a snapshot (with sysupgrade -s), then ran > > "doas pkg_add -u", and got this: > > > > > > Collision in python-3.8.6: the following files already exist > > /usr/local/bin/2to3 from python-3.8.6 > > /usr/local/bin/pydoc3 from python-3.8.6 > > /usr/local/bin/python3 from python-3.8.6 > > /usr/local/bin/python3-config from python-3.8.6 > > /usr/local/lib/pkgconfig/python3.pc from python-3.8.6 > > It seems to be a missing package registration > > This is because, > > 1) The default Python version in ports was switched from 3.7 to 3.8, > so the symlinks for the "default names" moved at that time > > 2) After this, Python 3.7 was updated in 6.7-stable > > The @conflict lines in the PLIST files for 3.8 in -current should have > been updated after the -stable update, so pkg_add doesn't know that > it needs to update 3.7.9 to the "6.8 version" (without the symlinks) > before installing 3.8. > > We can't do anything for the main 6.8 release packages now, but it can > be fixed in 6.8-stable once it's open. For those arches with -stable > packages available, once those packages are built it shouldn't be > noticeable to users. > > > After this, pkg_delete partial-python; pkg_add python3; pkg_add -u > > completed the upgrade without trouble (though I haven't tested anything). > > Yes that should do the trick. Somehow, this old problem is still haunting my computer. I'm reviving this old thread for two reasons: 1. In case the below is a useful bug report. 2. To request advice dealing with it. (My goal: I'd like to have a functioning /usr/local/bin/python3 symlink, and no "partial-python-3.8.7" package.) Ever since the problem I reported above, I've had trouble with the Python3 symlinks whenever I run pkg_add -u on that same system. I haven't kept careful track, so I'll start with the most recent symptoms: * Today, I noticed that I had no /usr/local/bin/python3 symlink, even though I have python-3.8.7 installed. (This is probably because I had earlier uninstalled the "partial-python-3.(something)" package.) * Seeing that, I decided to force-reinstall Python 3.8, resulting in the following: falsifian angel tmp $ doas pkg_add -u -D installed python-3.8.7 quirks-3.519 signed on 2021-01-24T21:22:51Z quirks-3.519->3.519: ok python-3.8.7:libffi-3.3->3.3: ok python-3.8.7:libiconv-1.16p0->1.16p0: ok python-3.8.7:gettext-runtime-0.21p0->0.21p0: ok python-3.8.7:sqlite3-3.34.0->3.34.0: ok python-3.8.7:xz-5.2.5->5.2.5: ok python-3.8.7:bzip2-1.0.8p0->1.0.8p0: ok Bogus symlink: /usr/local/bin/2to3 Bogus symlink: /usr/local/bin/pydoc3 Bogus symlink: /usr/local/bin/python3 Bogus symlink: /usr/local/bin/python3-config Bogus symlink: /usr/local/lib/pkgconfig/python3.pc Bad rename /usr/local/bin/2to3 to /usr/local/bin/2to3.HZzyyvf4Qq: No such file or directory Bad rename /usr/local/bin/pydoc3 to /usr/local/bin/pydoc3.IA1AJiEcMU: No such file or directory Bad rename /usr/local/bin/python3 to /usr/local/bin/python3.puMIJ7N7oe: No such file or directory Bad rename /usr/local/bin/python3-config to /usr/local/bin/python3-config.QD8CNhk2EW: No such file or directory Bad rename /usr/local/lib/pkgconfig/python3.pc to /usr/local/lib/pkgconfig/python3.pc.jrFTvKCyzK: No such file or directory python-3.8.7->3.8.7: ok Read shared items: ok --- -python-3.8.7 --- Files kept as partial-python-3.8.7 package I have no idea what's happening here. Somehow, pkg_add has decided that the symlinks (which didn't exist before I ran the command) should now be part of a new "partial-python-3.8.7" package: falsifian angel tmp $ pkg_info -L partial-python-3.8.7 Information for inst:partial-python-3.8.7 Files: /usr/local/bin/2to3 /usr/local/bin/pydoc3 /usr/local/bin/python3 /usr/local/bin/python3-config /usr/local/lib/pkgconfig/python3.pc Here's what I remember from the time between the October 2020 thread and today: * For a while (possibly still continuing to today; I haven't been paying close attention) every time I ran pkg_add -u, I would see error messages related to /usr/local/bin/python3 and other symlinks (but the upgrade seems to work). I think the error messages were generally similar to what's shown above, but I'm not sure. * The symlinks were generally kept in a "partial-python-3.(something)" package. * I deleted that partial-python-3.(something) package, probably more than once. I guess that is why /usr/local/bin/python3 didn't exist today when I checked. I guess my system is in some state that pkg_add can't puzzle its way out
Re: [macppc] unbreak devel/clang-tools-extra?
Hi George,
On Sun, 24 Jan 2021 16:18:54 -0500
George Koehler wrote:
> Hello ports list,
>
> We don't build devel/clang-tools-extra for macppc because,
>
> BROKEN-powerpc = no consumers on powerpc, save 25 build hours
> in bulks
>
> This reason (from cwen@ in Jul 2020) is still true; the consumers
> devel/kdevelop and devel/qt-creator don't exist on powerpc, because
> they depend on x11/qt5/qtwebengine, which is only for amd64 aarch64.
>
> If you remove the BROKEN line, then the powerpc build wastes some
> hours, then fails to link clang-tidy with "relocation truncated to
> fit" errors. I got the below diff from Brad Smith. It adds
> -Wl,--relax to fix the errors. With this diff, a 2700 MHz G5 built
> clang-tools-extra in just under 19 hours (18:43:47).
>
> Do we commit this diff?
>
Sadly it will take more than that in bulks, the bulk machines are way
slower (dual G4 1.0GHz). Similarly to guile2, if there are people using
it i think we should nonetheless.
> I would drop this diff and leave the port as is. The BROKEN reason
> is still true. If we add -Wl,--relax, we would delete -Wl,--relax
> when macppc switches from ld.bfd to ld.lld.
We miss a DPB_PROPERTIES for such a situation, but this is a very rare
one, iirc the only other one on macppc is cad/oce.
> Because I took 19 hours to build it, I feel that I should at least
> share the diff. I tried a few tools on macppc with a single C file in
> a CMake project (because cmake generates the compile_commands.json for
> these tools). clang-tidy warned of a magic number in my C, and
> clang-reorder-fields reordered my struct, but then clang-rename missed
> a spot when it renamed my struct.--George
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/devel/clang-tools-extra/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile 7 Sep 2020 08:54:29 - 1.11
> +++ Makefile 24 Jan 2021 18:33:00 -
> @@ -9,7 +9,6 @@
> # patches: rm patches/patch-*lld*
>
> ONLY_FOR_ARCHS = ${LLVM_ARCHS}
> -BROKEN-powerpc = no consumers on powerpc, save 25 build hours
> in bulks
> COMMENT= Clang extra tools
>
> @@ -66,6 +65,11 @@ CONFIGURE_ARGS += -DCLANG_ENABLE_STATIC_
> -DLLVM_INCLUDE_EXAMPLES=OFF \
> -DLLVM_INCLUDE_TESTS=OFF \
> -DLLVM_INCLUDE_BENCHMARKS=OFF
> +
> +.if ${MACHINE_ARCH} == "powerpc"
> +CONFIGURE_ARGS +=-DCMAKE_EXE_LINKER_FLAGS="-Wl,--relax"
> +CONFIGURE_ARGS +=-DCMAKE_SHARED_LINKER_FLAGS="-Wl,--relax"
> +.endif
>
> GCC_VER =8.4.0
> .if ${MACHINE_ARCH} == "amd64"
>
Re: [macppc] Fix devel/liboil runtime
On Sat, 23 Jan 2021 13:15:45 +0100 Charlene Wendling wrote: > While trying to fix the issue on powerpc64 through macppc, which was > experiencing the same issue without using gas(1), i've found out that > our current CVS version of liboil has 18 tests failures on macppc. > > The below diff removes the powerpc optimisations also on macppc, > leaving out only one test failure [1]. I briefly looked at the asm code. The register names are in Apple syntax (for Mac OS X), not ELF syntax (for BSD, Linux), but liboil passes options to gas(1) to enable the Apple names. I don't know why the asm is broken. I can see that the asm clobbers some registers like r11 without telling the compiler. If I ever find the problem, I would tell upstream.--George
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/24 15:03:47 Modified files: x11/kde-applications/konqueror: Makefile Log message: Add hidden build dependency on devel/kf5/kinit Spotted by naddy
Re: unbreak devel/spidermonkey78 on sparc64 (wip)
On Sun, Jan 24 2021, Sebastien Marie wrote: > Hi, > > With the following (wip) diff, I am able to unbreak > devel/spidermonkey78 on sparc64, and build it successfully. > > There were two differents problems: > > - ErrorReport.h is using va_list without including stdarg.h > > - rust part needs ports-gcc to build (as lang/rust is linked with llvm > libs and estdc++, and so search for libgcc.a, and ports-clang > doesn't know where to find it) > > For both, I need some help to proper correction :) > > Regarding stdarg.h, the problem seems to occurs only on > sparc64. Others archs doesn't have this problem. I assume stdarg.h (or > c++ counterpart) is included by some others include. I am really > unsure about patching js/public/ErrorReport.h (which is a public API). Explicitely including stdarg.h like you did makes sense to me, I doubt that it will break a consumer. > Regarding COMPILER ports-gcc changes, it will some affect others > archs. Maybe we could set COMPILER conditionnally (.if MACHINE == > sparc64) ? This should do the trick to only use ports-gcc on sparc64: COMPILER = base-clang ports-gcc ports-clang MODGCC4_ARCHS = sparc64 However, | diff f70231781648f922592f106731742fbc994f02c4 /home/semarie/repos/ports | blob - 1cc4370a95b301480afdab723c4176eaf66c5acb | file + devel/spidermonkey78/Makefile | --- devel/spidermonkey78/Makefile | +++ devel/spidermonkey78/Makefile | @@ -37,7 +37,7 @@ MODPY_RUNDEP = No | | # C++11 | # sync with SHARED_LIBS consumers: x11/gnome/gjs ^^ This should be kept in mind. I don't know why ports-clang was chosen in the first place. | -COMPILER = base-clang ports-clang | +COMPILER = base-clang ports-gcc | | USE_GMAKE = yes | | blob - /dev/null | file + devel/spidermonkey78/patches/patch-js_public_ErrorReport_h | --- /dev/null | +++ devel/spidermonkey78/patches/patch-js_public_ErrorReport_h | @@ -0,0 +1,13 @@ | +$OpenBSD$ | + | +Index: js/public/ErrorReport.h | +--- js/public/ErrorReport.h.orig | js/public/ErrorReport.h | +@@ -20,7 +20,6 @@ | + #include "mozilla/Assertions.h" // MOZ_ASSERT | + | + #include // std::input_iterator_tag, std::iterator | ++#include | + #include // size_t | + #include // int16_t, uint16_t | + #include // strlen -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Creating package debug... Fatal error: can't parse comment is too long
You are correct that it will require bumping every port that has
debug packages. It might be better to only change the comment
if it's too long (so that existing ones aren't changed).
Also, you don't need to use the full $prefix.0.$date.git.$sha in
the PKGNAME, in particular the sha is likely to be problematic.
On 2021/01/24 19:20, Mikolaj Kucharski wrote:
> I didn't receive any feedback. Would like to hear your thoughts. As
> below diff helps me in certain way, I would like to have this change
> incorporated into OpenBSD ports tree.
>
> On Fri, Jan 01, 2021 at 07:53:42PM +, Mikolaj Kucharski wrote:
> > Hi,
> >
> > I often generate my own distfiles from git checkout when I debug code
> > from OpenBSD ports tree. Some of the ports have already debug packages
> > defined. Sample debug package looks as follows:
> >
> > # pkg_info -I debug-sane-backends
> > debug-sane-backends-1.0.31p1 debug info for sane-backends-1.0.31p1
> > debug-sane-backends-1.0.31p1-snmp debug info for sane-backends-1.0.31p1-snmp
> >
> > As you can see package version ends up inside the COMMENT. When I
> > generate my debugging distfiles, they are usually generated from
> > git repos as most projects are currently hosted on GitHub and that's
> > git. Here is example distfile:
> >
> > sane-backends-1.0.31.0.20201130.120702.git.e3e397556.tar.gz
> >
> > and I generate it something a long the lines of:
> >
> > git archive --format=tar --prefix="$prefix.0.$date.git.$sha/" $hash | gzip
> > -9nf
> >
> > I find that naming convention useful to me. However with that long
> > versioning it goes over the limit of 60 characters in COMMENT, per code
> > in OpenBSD/PkgCreate.pm, function add_description().
> >
> > Looking at current code in bsd.port.mk:
> >
> > 1201. if ${DEBUG_PACKAGES:M${_S}}
> > 1202_DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
> > 1203_DBG_PKG_ARGS${_S} +=
> > -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
> > 1204_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
> > 1205_DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
> > 1206# XXX revisit that fullpkgpath later ?
> > 1207_DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
> > 1208_DBG_PKG_ARGS${_S} += -f ${_WRKDEBUG}/${PLIST${_S}:T}
> > 1209_EXCLUDE_DEBUG_PLISTS += ${_WRKDEBUG}/${PLIST${_S}:T}
> > 1210_pkg${_S} += ${_DBG_PKGFILE${_S}}
> > 1211_pkg_cookie${_S} += ${_DBG_PACKAGE_COOKIE${_S}}
> > 1212. endif
> >
> > We see that version information is also inside description of the
> > package:
> >
> > # pkg_info debug-sane-backends-- | grep -A1 -E '^(Comment|Description)'
> > Comment:
> > debug info for sane-backends-1.0.31p1
> > Description:
> > debug info for sane-backends-1.0.31p1
> >
> > So my proposition is to just drop the version part from the comment:
> >
> > Index: bsd.port.mk
> > ===
> > RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> > retrieving revision 1.1542
> > diff -u -p -u -r1.1542 bsd.port.mk
> > --- bsd.port.mk 26 Jun 2020 11:51:16 - 1.1542
> > +++ bsd.port.mk 1 Jan 2021 19:48:31 -
> > @@ -1201,7 +1201,7 @@ _pkg_cookie${_S} = ${_PACKAGE_COOKIE${_S
> > . if ${DEBUG_PACKAGES:M${_S}}
> > _DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
> > _DBG_PKG_ARGS${_S} +=
> > -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
> > -_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
> > +_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${PKGSTEM${_S}}"
> > _DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
> > # XXX revisit that fullpkgpath later ?
> > _DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
> >
> > However I think that would require to bump all debug packages across the
> > entire OpenBSD ports tree, right? Anyway, I would love to see above diff
> > committed. Comments?
> >
>
> --
> Regards,
> Mikolaj
>
[macppc] unbreak devel/clang-tools-extra?
Hello ports list,
We don't build devel/clang-tools-extra for macppc because,
BROKEN-powerpc =no consumers on powerpc, save 25 build hours in bulks
This reason (from cwen@ in Jul 2020) is still true; the consumers
devel/kdevelop and devel/qt-creator don't exist on powerpc, because
they depend on x11/qt5/qtwebengine, which is only for amd64 aarch64.
If you remove the BROKEN line, then the powerpc build wastes some
hours, then fails to link clang-tidy with "relocation truncated to
fit" errors. I got the below diff from Brad Smith. It adds
-Wl,--relax to fix the errors. With this diff, a 2700 MHz G5 built
clang-tools-extra in just under 19 hours (18:43:47).
Do we commit this diff?
I would drop this diff and leave the port as is. The BROKEN reason
is still true. If we add -Wl,--relax, we would delete -Wl,--relax
when macppc switches from ld.bfd to ld.lld.
Because I took 19 hours to build it, I feel that I should at least
share the diff. I tried a few tools on macppc with a single C file in
a CMake project (because cmake generates the compile_commands.json for
these tools). clang-tidy warned of a magic number in my C, and
clang-reorder-fields reordered my struct, but then clang-rename missed
a spot when it renamed my struct.--George
Index: Makefile
===
RCS file: /cvs/ports/devel/clang-tools-extra/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile7 Sep 2020 08:54:29 - 1.11
+++ Makefile24 Jan 2021 18:33:00 -
@@ -9,7 +9,6 @@
# patches: rm patches/patch-*lld*
ONLY_FOR_ARCHS = ${LLVM_ARCHS}
-BROKEN-powerpc = no consumers on powerpc, save 25 build hours in bulks
COMMENT= Clang extra tools
@@ -66,6 +65,11 @@ CONFIGURE_ARGS +=-DCLANG_ENABLE_STATIC_
-DLLVM_INCLUDE_EXAMPLES=OFF \
-DLLVM_INCLUDE_TESTS=OFF \
-DLLVM_INCLUDE_BENCHMARKS=OFF
+
+.if ${MACHINE_ARCH} == "powerpc"
+CONFIGURE_ARGS += -DCMAKE_EXE_LINKER_FLAGS="-Wl,--relax"
+CONFIGURE_ARGS += -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--relax"
+.endif
GCC_VER = 8.4.0
.if ${MACHINE_ARCH} == "amd64"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/24 13:25:11 Modified files: sysutils/ruby-puppet/5: Makefile sysutils/ruby-puppet/5/pkg: PLIST sysutils/ruby-puppet/6: Makefile sysutils/ruby-puppet/6/pkg: PLIST Log message: Fix PLIST after README removal Noticed by naddy
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/24 13:05:40 Modified files: lang/racket-minimal: Makefile Log message: enable build for powerpc64 ok juanfra@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2021/01/24 13:04:36 Modified files: x11/kde-applications/spectacle: Makefile Log message: missing bump after KDE Applications 20.12.1 update
Re: Creating package debug... Fatal error: can't parse comment is too long
I didn't receive any feedback. Would like to hear your thoughts. As
below diff helps me in certain way, I would like to have this change
incorporated into OpenBSD ports tree.
On Fri, Jan 01, 2021 at 07:53:42PM +, Mikolaj Kucharski wrote:
> Hi,
>
> I often generate my own distfiles from git checkout when I debug code
> from OpenBSD ports tree. Some of the ports have already debug packages
> defined. Sample debug package looks as follows:
>
> # pkg_info -I debug-sane-backends
> debug-sane-backends-1.0.31p1 debug info for sane-backends-1.0.31p1
> debug-sane-backends-1.0.31p1-snmp debug info for sane-backends-1.0.31p1-snmp
>
> As you can see package version ends up inside the COMMENT. When I
> generate my debugging distfiles, they are usually generated from
> git repos as most projects are currently hosted on GitHub and that's
> git. Here is example distfile:
>
> sane-backends-1.0.31.0.20201130.120702.git.e3e397556.tar.gz
>
> and I generate it something a long the lines of:
>
> git archive --format=tar --prefix="$prefix.0.$date.git.$sha/" $hash | gzip
> -9nf
>
> I find that naming convention useful to me. However with that long
> versioning it goes over the limit of 60 characters in COMMENT, per code
> in OpenBSD/PkgCreate.pm, function add_description().
>
> Looking at current code in bsd.port.mk:
>
> 1201. if ${DEBUG_PACKAGES:M${_S}}
> 1202_DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
> 1203_DBG_PKG_ARGS${_S} +=
> -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
> 1204_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
> 1205_DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
> 1206# XXX revisit that fullpkgpath later ?
> 1207_DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
> 1208_DBG_PKG_ARGS${_S} += -f ${_WRKDEBUG}/${PLIST${_S}:T}
> 1209_EXCLUDE_DEBUG_PLISTS += ${_WRKDEBUG}/${PLIST${_S}:T}
> 1210_pkg${_S} += ${_DBG_PKGFILE${_S}}
> 1211_pkg_cookie${_S} += ${_DBG_PACKAGE_COOKIE${_S}}
> 1212. endif
>
> We see that version information is also inside description of the
> package:
>
> # pkg_info debug-sane-backends-- | grep -A1 -E '^(Comment|Description)'
> Comment:
> debug info for sane-backends-1.0.31p1
> Description:
> debug info for sane-backends-1.0.31p1
>
> So my proposition is to just drop the version part from the comment:
>
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1542
> diff -u -p -u -r1.1542 bsd.port.mk
> --- bsd.port.mk 26 Jun 2020 11:51:16 - 1.1542
> +++ bsd.port.mk 1 Jan 2021 19:48:31 -
> @@ -1201,7 +1201,7 @@ _pkg_cookie${_S} = ${_PACKAGE_COOKIE${_S
> . if ${DEBUG_PACKAGES:M${_S}}
> _DBG_PKG_ARGS${_S} := ${PKG_ARGS${_S}}
> _DBG_PKG_ARGS${_S} +=
> -P${FULLPKGPATH${_S}}:${FULLPKGNAME${_S}}:${FULLPKGNAME${_S}}
> -_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${FULLPKGNAME${_S}}"
> +_DBG_PKG_ARGS${_S} += -DCOMMENT="debug info for ${PKGSTEM${_S}}"
> _DBG_PKG_ARGS${_S} += -d"-debug info for ${FULLPKGNAME${_S}}"
> # XXX revisit that fullpkgpath later ?
> _DBG_PKG_ARGS${_S} += -DFULLPKGPATH=debug/${FULLPKGPATH${_S}}
>
> However I think that would require to bump all debug packages across the
> entire OpenBSD ports tree, right? Anyway, I would love to see above diff
> committed. Comments?
>
--
Regards,
Mikolaj
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:43:28 Modified files: graphics/geeqie: Makefile distinfo graphics/geeqie/patches: patch-Makefile_am graphics/geeqie/pkg: PLIST Log message: Update to geeqie-1.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:30:50 Modified files: graphics/exiv2 : Makefile distinfo graphics/exiv2/patches: patch-cmake_compilerFlags_cmake patch-src_actions_cpp patch-src_value_cpp patch-src_version_cpp graphics/exiv2/pkg: PLIST Log message: Update to exiv2-0.27.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:24:27 Modified files: audio/grip : Makefile distinfo audio/grip/patches: patch-src_cddev_c patch-src_grip_c patch-src_launch_c patch-src_rip_c Log message: Update to grip-4.2.0.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:18:45 Modified files: graphics/py-sane: Makefile distinfo graphics/py-sane/patches: patch-setup_py graphics/py-sane/pkg: PLIST Log message: Update to py3-sane-2.9.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:14:33 Modified files: cad/gtkwave: Makefile distinfo Log message: Update to gtkwave-3.3.108.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/01/24 11:10:40 Modified files: textproc/uni : Makefile distinfo textproc/uni/pkg: DESCR Log message: Update to uni 1.1.1 Diff to move to MODGO_* from abieber OK abieber
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:08:59 Modified files: x11/lablgtk2 : Makefile distinfo x11/lablgtk2/patches: patch-src_Makefile Log message: Update to lablgtk2-2.18.11.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:05:47 Modified files: x11/p5-Tk : Makefile distinfo x11/p5-Tk/pkg : PLIST-main Log message: Update to p5-Tk-804.035.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 11:00:05 Modified files: x11/p5-Gtk3: Makefile distinfo Log message: Update to p5-Gtk3-0.038.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 10:58:55 Modified files: x11/p5-Gtk2-GladeXML: Makefile distinfo x11/p5-Gtk2-GladeXML/pkg: PLIST Removed files: x11/p5-Gtk2-GladeXML/patches: patch-Makefile_PL Log message: Update to p5-Gtk2-GladeXML-1.008.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/24 10:14:57 Modified files: x11/xfce4/xfce4-genmon: Makefile distinfo x11/xfce4/xfce4-genmon/pkg: PLIST Log message: x11/xfce4/xfce4-genmon: update to 4.1.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/24 10:14:35 Modified files: x11/xfce4/xfce4-whiskermenu: Makefile distinfo Log message: x11/xfce4/xfce4-whiskermenu: update to 2.5.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/24 09:35:48 Modified files: x11/kde-applications/kalarm: Makefile Log message: Missing dependency devel/kf5/knotifyconfig Spotted by naddy, thanks
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/24 09:08:23 Modified files: print/gutenprint: Makefile distinfo print/gutenprint/patches: patch-configure patch-src_cups_backend_common_h print/gutenprint/pkg: PLIST Added files: print/gutenprint/patches: patch-src_escputil_escputil_c patch-src_gutenprintui2_plist_c Log message: Update to gutenprint-5.3.4. with cluebat from robert@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2021/01/24 09:03:41 Modified files: lang/tcc : Makefile distinfo lang/tcc/pkg : PLIST Log message: The tcc armv7 backend is complete. Let's enable a package for it.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mgloc...@cvs.openbsd.org2021/01/24 08:41:38 Modified files: x11/spectrwm : Makefile Added files: x11/spectrwm/patches: patch-baraction_sh Log message: Fix the baraction.sh example script to display current statistics from iostat(8). ok gonzalo@
[update] security/fwbuilder 5.1 -> 6.0.0rc1
Hi,
Here is an update for fwbuilder to 6.0.0rc1.
This comes from a new upstream, that focused on moving fwbuilder to
CMake and Qt5 (instead of autotools and Qt4). There is no other
functional changes to be expected by this update (there is no proper
changelog).
HOMEPAGE is dead, and the old sourceforge page covers version 5.xx
only, so i preferred to keep the github page.
I had to work around the 'rc' versioning used, which is different from
ours. If someone has something more elegant, it would be great :)
It builds successfully on macppc and amd64. Tests report 2 failures out
of 45 units. I can't compare to 5.1, tests don't build.
Comments and feedback are welcome,
Charlène.
Index: Makefile
===
RCS file: /cvs/ports/security/fwbuilder/Makefile,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 Makefile
--- Makefile9 Jun 2020 07:14:45 - 1.45
+++ Makefile24 Jan 2021 14:10:37 -
@@ -1,76 +1,58 @@
# $OpenBSD: Makefile,v 1.45 2020/06/09 07:14:45 jasper Exp $
COMMENT = firewall GUI
-DISTNAME = fwbuilder-5.1.0.3599
-CATEGORIES = net security
-REVISION = 8
-HOMEPAGE = http://www.fwbuilder.org/
+V =6.0.0
+# We need to have ${LOCALBASE}/share/* directories matching with our own
+# versioning, see CONFIGURE_ARGS and patches/patch-cmake_VERSION_cmake as well.
+RC = rc1
+GH_ACCOUNT = fwbuilder
+GH_PROJECT = fwbuilder
+GH_TAGNAME = v${V}-${RC}
+DISTNAME = ${GH_PROJECT}-${V}${RC}
+
+CATEGORIES = net security
# GPLv2+ mostly, some code under BSD-like
PERMIT_PACKAGE = Yes
-WANTLIB += c crypto iconv m netsnmp QtGui QtNetwork
-WANTLIB += lzma pthread ${COMPILER_LIBCXX} util xml2 xslt z
-WANTLIB += ICE SM X11 Xext Xi Xinerama Xrender fontconfig freetype
+WANTLIB += ${COMPILER_LIBCXX}
+WANTLIB += Qt5Core Qt5Gui Qt5Network Qt5PrintSupport Qt5Widgets
+WANTLIB += c crypto m netsnmp util xml2 xslt z
-COMPILER = base-clang ports-gcc base-gcc
-
-MASTER_SITES = ${MASTER_SITE_SOURCEFORGE:=fwbuilder/}
+MODULES = devel/cmake \
+ x11/qt5
# .orig produces too much spam in tests directories
-PATCHORIG =.ports.orig
-
-AUTOMAKE_VERSION = 1.10
-AUTOCONF_VERSION = 2.63
-AUTORECONF = sh autogen.sh
+PATCHORIG =.orig.port
-CONFIGURE_STYLE = autoreconf
+LIB_DEPENDS = net/net-snmp \
+ textproc/libxml \
+ textproc/libxslt \
+ x11/qt5/qtbase
-BUILD_DEPENDS +=devel/cppunit
RUN_DEPENDS = devel/desktop-file-utils \
x11/gtk+3,-guic
-COPTS =${DEBUG}
-
-CONFIGURE_ARGS += --with-docdir=${TRUEPREFIX}/share/doc/fwbuilder \
- --with-templatedir=${TRUEPREFIX}/share/fwbuilder \
- --with-qtdir=${MODQT_QTDIR} \
- --with-qmake=qmake4 \
- --without-distcc
-MAKE_ENV +=QMAKE=${MODQT_QTDIR}/bin/qmake \
- CXXFLAGS="${CXXFLAGS}" \
- COPTS="${COPTS}" \
- LDFLAGS="${LDFLAGS}"
-
-USE_LIBTOOL = gnu
-MODULES = x11/qt4
-DESTDIRNAME = INSTALL_ROOT
-LIB_DEPENDS = converters/libiconv \
- net/net-snmp \
- textproc/libxml \
- textproc/libxslt \
- x11/qt4
-
+# Requires itself to be installed for tests
TEST_DEPENDS = ${FULLPKGNAME}:${BUILD_PKGPATH}
-TEST_TARGET = tests
-TEST_ENV +=COPTS="${COPTS}"
+
+CONFIGURE_ARGS +=
-DNETSNMP_INCLUDE_DIR="${LOCALBASE}/include/net-snmp/library" \
+ -DPROJECT_VERSION_EXTRA="${RC}"
+CONFIGURE_ENV += CXXFLAGS="${CXXFLAGS} -I${LOCALBASE}/include" \
+ LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib"
+
+# 2 failures:
+# instDialogInstallTest: fails because it can't catch its own background
process
+# FirewallDialogTest: the test seems broken because the dialog text changed
TEST_IS_INTERACTIVE = X11
-FAKE_FLAGS = INSTALL_PROGRAM="${INSTALL_PROGRAM}" \
- INSTALL_FILE="${INSTALL_DATA}"
+# For PLIST
+SUBST_VARS += DISTNAME
+# gunzip all manpages, it's an hell to patch.
post-install:
- cd ${WRKSRC}/src/res/Icons && find . -type d -mindepth 1 -maxdepth 1 | \
- while read D; do \
- ${INSTALL_DATA_DIR} ${PREFIX}/share/icons/hicolor/$$D; \
- ${INSTALL_DATA_DIR}
${PREFIX}/share/icons/hicolor/$$D/apps; \
- done
-
- cd ${WRKSRC}/src/res/Icons && find . -name '*.png' | \
- while read F; do \
- ${INSTALL_DATA} $$F \
- ${PREFIX}/share/icons/hicolor/`dirname
$$F`/apps/`basename $$F`; \
- done
+ ln -sf /usr/bin/gunzip ${WRKDIR}/bin/gunzip
+ cd ${PREFIX}/man/man1 && gunzip *.1.gz
.include
Index: distinfo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/24 08:25:01 Modified files: devel/ccache : Makefile distinfo Added files: devel/ccache/patches: patch-CMakeLists_txt patch-cmake_GenerateConfigurationFile_cmake patch-cmake_config_h_in patch-src_Logging_cpp patch-src_system_hpp Removed files: devel/ccache/patches: patch-Makefile_in patch-configure patch-src_util_c Log message: update to ccache-4.1 patched to disable the inode cache (new in 4.0, described as experimental, and not enabled by default at runtime) is disabled in build; it cannot be built without pthread_mutexattr_setpshared which we don't have.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/24 08:20:07 Modified files: editors: Makefile editors/vim: Makefile distinfo editors/vim/patches: patch-runtime_filetype_vim editors/vim/pkg: PLIST-main Added files: editors/vim/pkg: PFRAG.gtk3-main Removed files: editors/vim/pkg: PFRAG.gtk2-main Log message: Update to vim-8.2.2401 Drop gtk2 and py2 flavours, so now it only has to build 7 instead of 14 times in bulk builds and update tests.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/24 07:59:35 Modified files: devel/kf5/kimageformats: Makefile Log message: Add missing dependency libavif Spotted by naddy@ thanks!
Re: CVS: cvs.openbsd.org: ports
On 2021/01/24 06:49, Ricardo Mestre wrote: > CVSROOT: /cvs > Module name: ports > Changes by: mes...@cvs.openbsd.org 2021/01/24 06:49:38 > > Modified files: > www/youtube-dl : Makefile distinfo > www/youtube-dl/pkg: PLIST > > Log message: > update to 2021.01.24.1, part II > could you bump REVISION please, even if it was only in the tree for a short time somebody may have built the version with the wrong PLIST and without a bump "pkg_add -u" won't find the update.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/24 07:38:34 Modified files: infrastructure/mk: bsd.port.mk Log message: Change ccache handling from adding to BUILD_DEPENDS to doing an ".if exists" check. Newer ccache uses cmake making it impractical to break the loop by just disabling ccache for the individual ports on the way to building ccache.
Re: promplot - assistance with golang port
If some kind soul could push me in the right direction, I would greatly appreciate it. See reattached port, what I have so far. On Fri, Jan 01, 2021 at 02:17:31PM +, Mikolaj Kucharski wrote: > > I looking for a tool which can easily generate a screenshot from > Prometheus metrics and I found https://github.com/qvl/promplot > > I have work in progress port, but it fails to build with: > > ... > go install -modcacherw -v -p 1 github.com/qvl/promplot ; fi; > cannot find module providing package github.com/qvl/promplot: working > directory is not part of a module > *** Error 1 in . (/home/mkucharski/openbsd/ports/lang/go/go.port.mk:153 > 'do-build') > > Any idea what I'm doing wrong? > -- Regards, Mikolaj promplot-0.16.0-port.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/24 07:29:09 Modified files: converters/p5-JSON: Makefile distinfo Log message: update to p5-JSON-4.03
unbreak devel/spidermonkey78 on sparc64 (wip)
Hi, With the following (wip) diff, I am able to unbreak devel/spidermonkey78 on sparc64, and build it successfully. There were two differents problems: - ErrorReport.h is using va_list without including stdarg.h - rust part needs ports-gcc to build (as lang/rust is linked with llvm libs and estdc++, and so search for libgcc.a, and ports-clang doesn't know where to find it) For both, I need some help to proper correction :) Regarding stdarg.h, the problem seems to occurs only on sparc64. Others archs doesn't have this problem. I assume stdarg.h (or c++ counterpart) is included by some others include. I am really unsure about patching js/public/ErrorReport.h (which is a public API). Regarding COMPILER ports-gcc changes, it will some affect others archs. Maybe we could set COMPILER conditionnally (.if MACHINE == sparc64) ? Thanks. -- Sebastien Marie diff f70231781648f922592f106731742fbc994f02c4 /home/semarie/repos/ports blob - 1cc4370a95b301480afdab723c4176eaf66c5acb file + devel/spidermonkey78/Makefile --- devel/spidermonkey78/Makefile +++ devel/spidermonkey78/Makefile @@ -37,7 +37,7 @@ MODPY_RUNDEP =No # C++11 # sync with SHARED_LIBS consumers: x11/gnome/gjs -COMPILER = base-clang ports-clang +COMPILER = base-clang ports-gcc USE_GMAKE =yes blob - /dev/null file + devel/spidermonkey78/patches/patch-js_public_ErrorReport_h --- /dev/null +++ devel/spidermonkey78/patches/patch-js_public_ErrorReport_h @@ -0,0 +1,13 @@ +$OpenBSD$ + +Index: js/public/ErrorReport.h +--- js/public/ErrorReport.h.orig js/public/ErrorReport.h +@@ -20,7 +20,6 @@ + #include "mozilla/Assertions.h" // MOZ_ASSERT + + #include // std::input_iterator_tag, std::iterator ++#include + #include // size_t + #include // int16_t, uint16_t + #include // strlen
Re: CVS: cvs.openbsd.org: ports
On 2021/01/24 02:28, Rafael Sadowski wrote:
> Currently it also no longer wants to start.
> $ gns3
> Can't import Qt modules, PyQt is probably not installed ...
That is because of "--sip-module PyQt5.sip" in the recent py-sip commit
Still wondering how
self.splashSleepTime = 1
...
time.sleep(self.splashSleepTime)
can end up doing
34997 python2.7 CALL select(0,0,0,0,0x7f7f73b8)
34997 python2.7 STRU struct timeval { 1.-9223372036854775808 }
34997 python2.7 RET select -1 errno 22 Invalid argument
which does not seem right!
UPDATE: MPlayer 20210124
ox code was actually broken even
before the SSE2 code since it did not request the
even the 8 byte alignment even the pre-SSE2 code
already needed.
r38186 | al | 2020-05-26 16:33:56 -0400 (Tue, 26 May 2020) | 8 lines
configure: Make strip tool configurable
Initially based on a patch by Hank Wang >ex0804992 at itri org tw<
Use case of the original author:
When cross-compiling use the cross-strip for make install.
r38185 | al | 2020-05-23 08:46:49 -0400 (Sat, 23 May 2020) | 5 lines
configure: Disable FFmpeg encoder wrappers for MediaFoundation
Fix build with internal FFmpeg on systems without MediaFoundation.
r38184 | ib | 2020-03-03 12:33:32 -0500 (Tue, 03 Mar 2020) | 4 lines
Fix linking error of the non-GUI Wine build.
There is an undefined reference to 'ExtractIconA'.
r38183 | ib | 2020-03-03 05:47:07 -0500 (Tue, 03 Mar 2020) | 4 lines
Fix compilation of the Win32 GUI Wine build.
Add missing definition of gui_vinfo.
r38182 | ib | 2020-03-03 05:15:22 -0500 (Tue, 03 Mar 2020) | 4 lines
Fix compilation of non-X11 OpenGL video output driver.
Patch by Stephen Sheldon, sfsheldo gmail com.
Index: Makefile
===
RCS file: /home/cvs/ports/x11/mplayer/Makefile,v
retrieving revision 1.310
diff -u -p -u -p -r1.310 Makefile
--- Makefile4 Oct 2020 18:33:40 - 1.310
+++ Makefile24 Jan 2021 09:36:01 -
@@ -2,10 +2,9 @@
COMMENT= movie player supporting many formats
-V= 20200229
+V= 20210124
FFMPEG_V= 4.3.1
DISTNAME= mplayer-${V}
-REVISION= 3
CATEGORIES=x11 multimedia
MASTER_SITES= https://comstyle.com/source/
EXTRACT_SUFX= .tar.xz
Index: distinfo
===
RCS file: /home/cvs/ports/x11/mplayer/distinfo,v
retrieving revision 1.52
diff -u -p -u -p -r1.52 distinfo
--- distinfo1 Mar 2020 10:01:04 - 1.52
+++ distinfo24 Jan 2021 09:36:11 -
@@ -1,2 +1,2 @@
-SHA256 (mplayer-20200229.tar.xz) = P3D6MTpC986g5SpvBBiCDQI2Kgh45VsxnH+rNavgIz4=
-SIZE (mplayer-20200229.tar.xz) = 5166240
+SHA256 (mplayer-20210124.tar.xz) = lFK2anWHpV8JKwI29rkQdCpopUJgKygmFcfIn+SWcFI=
+SIZE (mplayer-20210124.tar.xz) = 5169156
Index: patches/patch-DOCS_man_en_mplayer_1
===
RCS file: /home/cvs/ports/x11/mplayer/patches/patch-DOCS_man_en_mplayer_1,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 patch-DOCS_man_en_mplayer_1
--- patches/patch-DOCS_man_en_mplayer_1 1 Mar 2020 10:01:04 - 1.20
+++ patches/patch-DOCS_man_en_mplayer_1 24 Jan 2021 09:36:37 -
@@ -12,7 +12,7 @@ Index: DOCS/man/en/mplayer.1
.
.TP
.B \-channels (also see \-af channels)
-@@ -12268,7 +12268,7 @@ mplayer dvd://1 \-dvdangle 2
+@@ -12277,7 +12277,7 @@ mplayer dvd://1 \-dvdangle 2
.PP
.B Play from a different DVD device:
.nf
@@ -21,7 +21,7 @@ Index: DOCS/man/en/mplayer.1
.fi
.
.PP
-@@ -12334,11 +12334,11 @@ mplayer \-vo zr2 \-vf scale=352:288,zrmjpeg file.avi
+@@ -12343,11 +12343,11 @@ mplayer \-vo zr2 \-vf scale=352:288,zrmjpeg file.avi
.PP
.B Play DTS-CD with passthrough:
.nf
Index: patches/patch-configure
===
RCS file: /home/cvs/ports/x11/mplayer/patches/patch-configure,v
retrieving revision 1.88
diff -u -p -u -p -r1.88 patch-configure
--- patches/patch-configure 1 Mar 2020 10:01:04 - 1.88
+++ patches/patch-configure 24 Jan 2021 09:36:35 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-configure,v 1.88 2020/03
Index: configure
--- configure.orig
+++ configure
-@@ -1509,39 +1509,39 @@ echo configuration: $configuration > "$TMPLOG"
+@@ -1514,39 +1514,39 @@ echo configuration: $configuration > "$TMPLOG"
echo >> "$TMPLOG"
@@ -75,7 +75,7 @@ Index: configure
list_subparts() {
test ! -e ffmpeg/libav${3} && return 1
pattern="s/^[^#]*${1}.*([^ ,]*, *\([^ ,)]*\).*/\1_${2}/p"
-@@ -2446,7 +2446,7 @@ case "$host_arch" in
+@@ -2465,7 +2465,7 @@ case "$host_arch" in
arch='sparc'
iproc='sparc'
if test "$host_arch" = "sparc64" ; then
@@ -84,7 +84,7 @@ Index: configure
proc='ultrasparc'
def_fast_64bit='#define HAVE_FAST_64BIT 1'
elif sunos ; then
-@@ -2815,7 +2815,7 @@ cat > $TMPC << EOF
+@@ -2840,7 +2840,7 @@ cat > $TMPC << EOF
int ff_extern;
EOF
cc_check -c || die "Symbol mangling check failed."
@@ -93,7 +93,7 @@ Index: configure
extern_prefix=
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/24 06:53:55 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: better @msg for gns3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mes...@cvs.openbsd.org 2021/01/24 06:49:38 Modified files: www/youtube-dl : Makefile distinfo www/youtube-dl/pkg: PLIST Log message: update to 2021.01.24.1, part II
UPDATE: libplacebo 3.104.0
Here is an update to libplacebo 3.104.0. v3.104.0 This is a major release, introducing many new features and modifications. Most importantly, libplacebo now interoperates well with FFmpeg's libav* abstractions. This is primarily exposed via a new set of helpers, , implemented as a single header library. In addition to this, a number of other supporting changes have been made to the API, most notably the unification of `pl_image` and `pl_render_target` into a single `pl_frame` concept, similar in spirit to AVFrame. As such, libplacebo now supports **rendering to planar targets**, including subsampled YCbCr. Besides the libav* compatibility changes, this release also brings with it a new feature for custom shaders: buffer blocks, and persistent storage. This can be used by third parties to implement stateful shaders (e.g. motion interpolation or temporal deinterlacing), or be leveraged to speed up some shaders by combining multiple passes into one. Finally, various import/export procedures have been expanded, including the ability to import host pointers and real-world DMABUFs. Additions: - add `pl_memory_qualifiers`, plus a corresponding `pl_shader_desc.memory`, to allow attaching GLSL memory qualifiers (coherent, volatile etc.) to shader descriptors - add functions `pl_dispatch_save` and `pl_dispatch_load` to allow saving/restoring the contents of an entire `pl_dispatch`'s cache - add functions `pl_renderer_save` and `pl_renderer_load` to allow saving/restoring the contents of an entire `pl_renderer`'s cache - add `pl_vulkan_swapchain_params.prefer_hdr`, which will cause the surface format selection logic to try HDR output formats first - add `pl_buf_copy` to copy from one buffer to another - add `pl_get_detected_peak`, to read back the result of peak detection - add `pl_primaries_superset` to test if one set of primaries is fully enclosed by another - add `pl_color_map_params.gamut_clipping`, which will colorimetrically clip any out-of-gamut colors by desaturating them towards neutral gray until they're in-gamut, rather than clipping per channel as before - add `PL_GPU_CAP_SUBGROUPS` and `pl_gpu_limits.subgroup_size`, to expose GLSL subgroup functionality via the `pl_gpu` interface - add `pl_gpu_is_failed`, to query at a high level whether the `pl_gpu` is in some internal failure state. GPUs in this state should be recreated, using the appropriate mechanism - add `pl_shader_custom`, to allow injecting arbitrary custom GLSL code into a `pl_shader`. - add `pl_buf_params.import_handle` to allow importing buffers - add `PL_HANDLE_HOST_POTR`, to allow importing arbitrary host pointers - add `pl_pass_run_params.vertex_buf`, to allow drawing vertex data directly from a `pl_buf`, guarded by `pl_gpu_limits.max_vbo_size` - add `_COUNT` members to all public enums, for consistency - add `pl_shared_mem.drm_format_mod`, to allow communicating DRM format modifiers when importing/exporting textures - add support for importing DMABUFs via EGL, via the new fields `pl_opengl_params.egl_display/context` - add `pl_fmt.fourcc` to facilitate mapping between `pl_fmt` and DRM - add the missing `pl_var_*` helpers, for consistency - add `pl_plane_data_align` to help with aligning `pl_plane_data` structs to byte boundaries - add support for STORAGE textures in user shaders, which can be used to persist data across separate invocations of the shader - add support for BUFFER blocks in user shaders, which can be used to create UBOs or SSBOs for use inside shaders, the latter of which can also persist across frames and be used to store persistent state - add PL_COLOR_PRIM_EBU_3213 and PL_COLOR_PRIM_FILM_C - add a new header , containing a variety of helper functions for interoperating between libav* and libplacebo - add `demos/plplay.c` to serve as a demonstration of how to make a trivial playback loop with libavcodec and libplacebo - add `pl_sample_src.component_mask` to allow sampling an arbitrary subset of the available components from a plane - add `pl_frame_is_cropped` and `pl_frame_clear` to assist in properly clearing frames before rendering to them - add `pl_tex_poll` to assist in interoperating with some external APIs - add `pl_render_params.blend_params` to allow blending the final output Changes: - remove `pl_image.signature` and `pl_render_params.skip_redraw_caching` - change vulkan surface format selection to prioritize formats by 'score', preferring higher depth integer formats - `pl_fmt` may now have PL_FMT_CAP_STORABLE even when `glsl_format` is NULL, in which case formatless image storage must be used - `pl_buf_read` no longer requires `buf_offset` be a multiple of 4 - `pl_buf_*` commands are now synchronized internally: - `pl_buf_write` and `pl_buf_read` now block while the buffer is in use Note: for this reason, `pl_buf_write` should not be used in loops - `pl_tex_upload/download` may now be called on in-use buffers - allow `pl_dispatch_compute` on shaders
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mes...@cvs.openbsd.org 2021/01/24 06:16:30 Modified files: www/youtube-dl : Makefile distinfo www/youtube-dl/pkg: PLIST Log message: revert back to 2021.01.16, previous commit is still not working properly
UPDATE: x11/spectrwm - baraction.sh
The first line of iostat(8) displays the stats from the time of the
last reboot. Wouldn't it be more interesting to see the current stats
in the bar, and therefore use the second line?
Index: x11/spectrwm/Makefile
===
RCS file: /cvs/ports/x11/spectrwm/Makefile,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 Makefile
--- x11/spectrwm/Makefile 23 Jan 2021 18:34:17 - 1.36
+++ x11/spectrwm/Makefile 24 Jan 2021 13:05:45 -
@@ -8,7 +8,7 @@ GH_PROJECT= spectrwm
GH_TAGNAME=SPECTRWM_${V:S/./_/g}
DISTNAME= ${GH_PROJECT}-${V}
-REVISION= 0
+REVISION= 1
SHARED_LIBS= swmhack 1.0
Index: x11/spectrwm/patches/patch-baraction_sh
===
RCS file: x11/spectrwm/patches/patch-baraction_sh
diff -N x11/spectrwm/patches/patch-baraction_sh
--- /dev/null 1 Jan 1970 00:00:00 -
+++ x11/spectrwm/patches/patch-baraction_sh 24 Jan 2021 13:05:45 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: baraction.sh
+--- baraction.sh.orig
baraction.sh
+@@ -84,7 +84,7 @@ print_bat() {
+ APM_DATA=""
+ I=0
+ while :; do
+- IOSTAT_DATA=`/usr/sbin/iostat -C | grep '[0-9]$'`
++ IOSTAT_DATA=`/usr/sbin/iostat -C -c 2 | tail -n 1 | grep '[0-9]$'`
+ if [ $I -eq 0 ]; then
+ APM_DATA=`/usr/sbin/apm -alb`
+ fi
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mes...@cvs.openbsd.org 2021/01/24 06:08:05 Modified files: www/youtube-dl : Makefile distinfo www/youtube-dl/pkg: PLIST Log message: update to 2021.01.24.1
Re: NEW: security/py-hvac 0.10.6
Hi, Kind reminder. Port reattached for convenience. On Fri, Jan 01, 2021 at 05:08:59PM +, Mikolaj Kucharski wrote: > > I'm using py3-hvac Python module to fetch Vault secrets from Ansible via > its hashi_vault lookup plugin. > > > Comment: > > Python client library for Hashicorp Vault > > > > Description: > > HVAC allows accessing secrets stored in a Vault directly from > > Python code. > > > > An access token must be created first, using a separate tool > > like vault or vault-client. > > I've made it Python3-only port. Comments? > -- Regards, Mikolaj py-hvac-0.10.6.port.tgz Description: application/tar-gz
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: rsadow...@cvs.openbsd.org 2021/01/24 03:43:13
Modified files:
devel/quirks : Makefile
devel/quirks/files: Quirks.pm
Log message:
Register removal of py-qt4{-docs}
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/24 03:41:23 Modified files: x11: Makefile Removed files: x11/py-qt4 : Makefile distinfo x11/py-qt4/patches: patch-configure_py x11/py-qt4/pkg : DESCR-docs DESCR-main PLIST-docs PLIST-main Log message: Remove py-qt4 OK kn@
Re: [sparc64] Fix x11/spectrwm runtime
Sebastien Marie wrote: > On Sun, Jan 24, 2021 at 09:13:31AM +0100, Stefan Hagen wrote: >>> >>> I am suspecting some issue in the way your x11 sets were installed >>> (did you use bsd.rd ? installing from source ?) >> >> My system is fairly standard, all sets installed. I upgrade every few >> days with sysupgrade to the next snapshot and update my ports with >> pkg_add -u. I'm not installing anything that's not a port or package. > > ok, thanks to confirming. > > could you provide to me the following elements ? Of course! > - system installation date (I would like to look at the used sets) > $ doas what /bsd# show kernel build date > $ ls -l /dev/MAKEDEV /dev/sd0a# show userland build date (MAKEDEV is > usually not manually edited) and installation date (sd0a is regenerated at > install time) > > - /var/cache/fontconfig listing: > $ ls -l /var/cache/fontconfig As requested: ### amd64 ### $ doas what /bsd /bsd: OpenBSD 6.8-current (GENERIC.MP) #287: Thu Jan 21 20:56:22 MST 2021 $ ls -l /dev/MAKEDEV /dev/sd0a -r-xr-xr-x 1 root wheel11908 Jan 22 04:31 /dev/MAKEDEV brw-r- 1 root operator4, 0 Jan 22 20:52 /dev/sd0a $ ls -l /var/cache/fontconfig total 7620 -rw-r--r-- 1 root wheel 500400 Jan 23 20:26 0f0db7876307790c19e1f91eb9095080-le64.cache-7 -rw-r--r-- 1 root wheel73504 Jan 23 20:26 0f51981a91016500e33371abfaf44b15-le64.cache-7 -rw-r--r-- 1 root wheel 499680 Jan 23 20:26 1487dd4aecf3164c4a11193169052443-le64.cache-7 -rw-r--r-- 1 root wheel43088 Jan 23 20:26 1ef8e776effc8a96fba79ecc7cb994f8-le64.cache-7 -rw-r--r-- 1 root wheel 112 Jan 23 20:26 49aa604a5ac92994756d3008e408245c-le64.cache-7 -rw-r--r-- 1 root wheel 232 Jan 23 20:26 4c599c202bc5c08e2d34565a40eac3b2-le64.cache-7 -rw-r--r-- 1 root wheel 176 Jan 23 20:26 558352270fb122ca08359d23b5a778d4-le64.cache-7 -rw-r--r-- 1 root wheel 2418824 Jan 23 20:26 5590eef8711d78f75a1d19f78ae9af8f-le64.cache-7 -rw-r--r-- 1 root wheel 128 Jan 23 20:26 5dc9fcf026e07a49c5f91c19054b9930-le64.cache-7 -rw-r--r-- 1 root wheel 141880 Jan 23 20:26 79652363633577d7d713baab7f54ad8c-le64.cache-7 -rw-r--r-- 1 root wheel33656 Jan 23 20:26 a1a78d9c18cd095d3829c724810e6ffb-le64.cache-7 -rw-r--r-- 1 root wheel35304 Jan 23 20:26 ba022efc551c75e21c690774bbcf5304-le64.cache-7 -rw-r--r-- 1 root wheel64120 Jan 23 20:26 bc06c1eea3e636f72101cafc3fb39508-le64.cache-7 -rw-r--r-- 1 root wheel 488 Jan 23 20:26 c5f5d66d15c24edc3e863c27139db87e-le64.cache-7 -rw-r--r-- 1 root wheel 120 Jan 23 20:26 f22309b238134d3cca63435f528976cd-le64.cache-7 ### sparc64 ### $ doas what /bsd /bsd: OpenBSD 6.8-current (GENERIC) #623: Fri Jan 22 23:45:17 MST 2021 $ ls -l /dev/MAKEDEV /dev/sd0a -r-xr-xr-x 1 root wheel13606 Jan 23 07:24 /dev/MAKEDEV brw-r- 1 root operator7, 0 Jan 24 00:30 /dev/sd0a $ ls -l /var/cache/fontconfig total 2768 -rw-r--r-- 1 root wheel 500400 Jan 23 09:36 0fe0af1d5898cfe43064332244d1dc15-be64.cache-7 -rw-r--r-- 1 root wheel 112 Jan 23 09:36 1bd20f0f0c9d7d1d5fd55b69fcc2b3a3-be64.cache-7 -rw-r--r-- 1 root wheel 488 Jan 23 09:36 2cee944125173ffd13126fb55c9a0dc1-be64.cache-7 -rw-r--r-- 1 root wheel 176 Jan 23 09:36 68418e0da60dfe4003a8c2435e92b1d3-be64.cache-7 -rw-r--r-- 1 root wheel 35208 Jan 23 09:36 6ac606a6cc613b1dd45fa75d9315a55e-be64.cache-7 -rw-r--r-- 1 root wheel 33656 Jan 23 09:36 7c10409a5d7a696d98ceb77b9b1e9209-be64.cache-7 -rw-r--r-- 1 root wheel 73504 Jan 24 01:01 7cef3f2ad6de75f422b6cd179c7674f2-be64.cache-7 -rw-r--r-- 1 root wheel 499680 Jan 23 09:36 8b934b58f0acb2e86a05d24d97c0-be64.cache-7 -rw-r--r-- 1 root wheel 120 Jan 23 09:36 90acf7d99f5044d4df0432f2d0f16b42-be64.cache-7 -rw-r--r-- 1 root wheel 200 Jan 24 01:01 CACHEDIR.TAG -rw-r--r-- 1 root wheel 64024 Jan 23 09:36 be2547a64937fd44a1f33dfd1eea53e8-be64.cache-7 -rw-r--r-- 1 root wheel 128 Jan 23 09:36 d929d2c542e4f6652ca46d613e4b360e-be64.cache-7 -rw-r--r-- 1 root wheel 144 Jan 24 01:01 f06766f883c12b9298ca893082d31aea-be64.cache-7 -rw-r--r-- 1 root wheel 141880 Jan 23 09:36 f8033d5e4c6effb98c84b18a50eef42d-be64.cache-7 Best Regards, Stefan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/24 02:31:48 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Add gns3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/24 02:28:49 Modified files: emulators : Makefile Removed files: emulators/gns3 : Makefile distinfo emulators/gns3/patches: patch-setup_py patch-src_GNS3_Config_Defaults_py patch-src_GNS3_QemuManager_py emulators/gns3/pkg: PLIST Log message: Remove gns3 This is the last py-qt4 consumer in the tree. No one has come out to try an update. https://github.com/GNS3/gns3-server Currently it also no longer wants to start. $ gns3 Can't import Qt modules, PyQt is probably not installed ... OK kn
Re: [sparc64] Fix x11/spectrwm runtime
On Sun, Jan 24, 2021 at 09:13:31AM +0100, Stefan Hagen wrote:
> >
> > I am suspecting some issue in the way your x11 sets were installed
> > (did you use bsd.rd ? installing from source ?)
>
> My system is fairly standard, all sets installed. I upgrade every few
> days with sysupgrade to the next snapshot and update my ports with
> pkg_add -u. I'm not installing anything that's not a port or package.
ok, thanks to confirming.
could you provide to me the following elements ?
- system installation date (I would like to look at the used sets)
$ doas what /bsd # show kernel build date
$ ls -l /dev/MAKEDEV /dev/sd0a# show userland build date (MAKEDEV is
usually not manually edited) and installation date (sd0a is regenerated at
install time)
- /var/cache/fontconfig listing:
$ ls -l /var/cache/fontconfig
>
> I spend more time on this und this .xsession can reliably reproduce it.
>
> (This is on amd64 now)
>
> $ cat .xsession
> #!/bin/sh
> export PATH=$HOME/.bin:$PATH
> export ENV=$HOME/.kshrc
>
> xset fp+ $HOME/.fonts
>
> if [ -f $HOME/.fonts/a.pcf ];
> then
> mv $HOME/.fonts/a.pcf $HOME/.fonts/b.pcf
> else
> mv $HOME/.fonts/b.pcf $HOME/.fonts/a.pcf
> fi
>
> ktrace /usr/local/bin/spectrwm
> fc-cache
> /usr/local/bin/spectrwm
>
> The above can also be reproduced if I change a font in X and then
> restart X before starting another application that updates the font
> cache.
>
> Now the interesting part:
>
> ktrace without wpath pledge (same as above):
> 74576 spectrwm CALL open(0x60aca42e2c0,0x1)
> 74576 spectrwm NAMI "/home/sdk/.fonts"
> 74576 spectrwm RET open 4
> 74576 spectrwm CALL fstatfs(4,0x7f7c5b20)
> 74576 spectrwm RET fstatfs 0
> 74576 spectrwm CALL close(4)
> 74576 spectrwm RET close 0
> 74576 spectrwm CALL open(0x60b68610580,0x10002)
> 74576 spectrwm NAMI
> "/var/cache/fontconfig//16ed0cc8073ec56eceb979219ebd6117-le64.cache-7"
> 74576 spectrwm PLDG open, "wpath", errno 1 Operation not permitted
> 74576 spectrwm PSIG SIGABRT SIG_DFL
>
> ktrace with wpath pledge:
> 43198 spectrwm CALL open(0xe8a4ebca400,0x1)
> 43198 spectrwm NAMI
> "/home/sdk/.fontconfig//16ed0cc8073ec56eceb979219ebd6117-le64.cache-7"
> 43198 spectrwm RET open -1 errno 2 No such file or directory
> 43198 spectrwm CALL stat(0xe8a729bc620,0x7f7f3f08)
> 43198 spectrwm NAMI "/home/sdk/.fonts"
> 43198 spectrwm STRU struct stat { [...] }
> 43198 spectrwm RET stat 0
> 43198 spectrwm CALL open(0xe8a729bc620,0x1)
> 43198 spectrwm NAMI "/home/sdk/.fonts"
> 43198 spectrwm RET open 4
> 43198 spectrwm CALL fstatfs(4,0x7f7f3c30)
> 43198 spectrwm RET fstatfs 0
> 43198 spectrwm CALL close(4)
> 43198 spectrwm RET close 0
> 43198 spectrwm CALL open(0xe898828b280,0x10002)
> 43198 spectrwm NAMI
> "/var/cache/fontconfig//16ed0cc8073ec56eceb979219ebd6117-le64.cache-7"
> 43198 spectrwm RET open -1 errno 2 No such file or directory
> 43198 spectrwm CALL open(0xe8a14b2e480,0x10002)
> 43198 spectrwm NAMI
> "/home/sdk/.cache/fontconfig//16ed0cc8073ec56eceb979219ebd6117-le64.cache-7"
> 43198 spectrwm RET open 4
> 43198 spectrwm CALL kbind(0x7f7f3da8,24,0x972bc9d9d6b346c2)
> 43198 spectrwm RET kbind 0
> 43198 spectrwm CALL getpid()
> 43198 spectrwm RET getpid 43198/0xa8be
> 43198 spectrwm CALL kbind(0x7f7f3da8,24,0x972bc9d9d6b346c2)
> 43198 spectrwm RET kbind 0
> 43198 spectrwm CALL fcntl(4,F_SETLKW,0x3ea0)
> 43198 spectrwm PLDG fcntl, "flock", errno 1 Operation not permitted
> 43198 spectrwm PSIG SIGABRT SIG_DFL code <-73839872>
>
> What I see here is a bug in fontconfig, right?
>
> 1. O_RDONLY open in the user cache
> 2. O_RDWR open to _check_ the system cache
> 3. O_RDWR open to create the cache file in the user cache
>
> I believe that number 2 could as well be O_RDONLY.
I don't know fontconfig code, but it could also make sense to use
system cache if writeable, and fallback to user cache if not possible
to write to it.
from your ktrace extract, a part of it seems to be FcDirCacheLock()
function. It is trying to place a lockfile inside the first writeable
directory from cacheDirs list. the name of the lock file is a hash
based on the name of the directory wanted to lock (if I correctly
understand). The directory is "/home/sdk/.fonts", so the md5 hash is
16ed0cc8073ec56eceb979219ebd6117.
$ printf '/home/sdk/.fonts' | md5
16ed0cc8073ec56eceb979219ebd6117
At the time of the ktrace output, the cache has already seen as
out-of-sync, and the decision to update it seems to already have
took. In order to safely update it, it is trying to take a lock.
> (The flock kill is not happening on sparc64, I'll do more testing there
> later. But that's unrelated to this problem.)
>
> Best Regards,
> Stefan
--
Sebastien Marie
Re: [sparc64] Fix x11/spectrwm runtime
Stefan Hagen wrote: > Sebastien Marie wrote: >> On Sat, Jan 23, 2021 at 09:04:22PM +0100, Stefan Hagen wrote: >>> Sebastien Marie wrote: On Sat, Jan 23, 2021 at 07:14:33PM +0100, Stefan Hagen wrote: > Hi, > > Spectrwm on Sparc64 wants the wpath pledge: > > 70801 spectrwm CALL open(0x7904d18380,0x10002) > 70801 spectrwm NAMI > "/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7" > 70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted > 70801 spectrwm PSIG SIGABRT SIG_DFL > > I've sent the fix upstream and it got merged already. > Meanwhile, here is the fixed port. > > Changes: > - added wpath pledge where needed > - added revision I am a bit unsure about adding "wpath" in promises. Usually when fontconfig write is involved, it means the cache is out of sync (and it is odd it is happening for the system cache). If I didn't mess myself, I recall about something like that previously. If adding "wpath" is really required, it would be interesting to use also unveil to restrict the promise added. >>> >>> You're right. I can reproduce it on amd64 now: >>> >>> If I fiddle with my font paths and then (re)start X, spectrwm crashes >>> with a wpath violation on amd64 too. >>> >>> This is something that can happen with any X application... >>> >>> Instead of allowing wpath and catching it again with unveil, wouldn't >>> it be worth thinking about a pledge promise that allows X font cache >>> updates? >> >> no. the kernel shouldn't have to know what all libraries could do :) >> >> the responsability is shared between the compoments: >> >> - it is the application responsability to pledge for what the >> application and all linked libraries will need (like sthen@ >> mentioned) >> >> - it is the library responsability to not doing silly things >> (regarding fontconfig, we patched out chmod(2) usage from it for >> example: https://marc.info/?l=openbsd-cvs=157229154821950=2). >> >> - it is the responsability of the kernel to enforce, in a generic way, >> what the application pledge for, without having a complex interface. >> >> you could compare pledge(2) usage in cat(1) (it was tame(2) in first >> ages) >> >> https://github.com/openbsd/src/commit/b7db428a8107ad20577d7c8416bf55a8f875e621 >> and capsicum >> >> https://cgit.freebsd.org/src/commit/bin/cat/cat.c?id=aefe30c5437159a5399bdbc1974d6fbf40f2ba0f >> . >> >> >>> There is still a difference. On amd64, I can start another WM or an >>> xterm and on the next start spectrwm works. The same does not work on >>> the sparc64 machine. I don't know what fontconfig is doing there. It >>> looks like the font cache is always out of sync here. >> >> in your ktrace extract, fontconfig is trying to revalidate the >> *system* cache (/var/cache/fontconfig). only root could do that (but >> fontconfig tries to do it, and will fail due to EPERM - and when >> pledged, the fact to try to use O_RDWR makes it to die). >> >> in "fiddle with my font paths", it should rewrite the user cache >> (usually ~/.cache/fontconfig), which is something it has permission to >> do (if not killed by pledge). >> >> I am suspecting some issue in the way your x11 sets were installed >> (did you use bsd.rd ? installing from source ?) > > My system is fairly standard, all sets installed. I upgrade every few > days with sysupgrade to the next snapshot and update my ports with > pkg_add -u. I'm not installing anything that's not a port or package. > >> system fontconfig cache comes from xbase68.tgz. Previously, we made >> some adjustements too keep it in sync with fonts directories >> (https://marc.info/?l=openbsd-cvs=153117126409370=2). > >> Please note I am also unsure how fonts from ports are managed. >> >> A possible workaround would be to run `fc-cache -s' as root, but it >> will only correct the immediate problem (out-of-sync) and not the >> underline problem (why the cache is out-of-sync). > > Yes, I know how to work around this. There are ways - but it shouldn't > need those workarounds. > > I spend more time on this und this .xsession can reliably reproduce it. > > (This is on amd64 now) > > $ cat .xsession > #!/bin/sh > export PATH=$HOME/.bin:$PATH > export ENV=$HOME/.kshrc > > xset fp+ $HOME/.fonts > > if [ -f $HOME/.fonts/a.pcf ]; > then > mv $HOME/.fonts/a.pcf $HOME/.fonts/b.pcf > else > mv $HOME/.fonts/b.pcf $HOME/.fonts/a.pcf > fi > > ktrace /usr/local/bin/spectrwm > fc-cache > /usr/local/bin/spectrwm > > The above can also be reproduced if I change a font in X and then > restart X before starting another application that updates the font > cache. > > Now the interesting part: > > ktrace without wpath pledge (same as above): > 74576 spectrwm CALL open(0x60aca42e2c0,0x1) > 74576 spectrwm NAMI "/home/sdk/.fonts" > 74576 spectrwm RET open 4 > 74576 spectrwm CALL fstatfs(4,0x7f7c5b20) > 74576 spectrwm RET
[maintainer update] graphics/chafa to 1.6.0
Hi, this updates graphics/chafa to 1.6.0 * Added support for fullwidth symbols that take up two character cells. These are common in East Asian scripts. Single-cell and double-cell symbols can be mixed, and -f symbols mode will use both if possible. * New symbol tags: Alpha, digit, alnum, narrow, wide, ambiguous, ugly, bad. "Ambiguous" symbols have uncertain widths and may render poorly in some terminals. "Ugly" denotes symbols that are unsuitable for Chafa's cell-based graphics (multicolor emoji, ideographic descriptors, etc). "Bad" is a superset of these two categories. Bad symbols are always excluded unless explicitly enabled with e.g. CHAFA_SYMBOL_TAG_BAD (--symbols +bad in the frontend). * The font loader (--glyph-file option) now does a better job with proportional fonts. * Added options for controlling lossless optimization of output. Currently, attribute reuse and character repetition (REP sequence) are implemented. * Added -O option to the frontend. This controls the optimization level. * Added a simple abstraction layer for terminal control sequences (ChafaTermInfo and ChafaTermDb). This allows for improved terminal support. * FbTerm is now supported with TERM=fbterm in the environment. * Bug fixes: github#43 Fix signal handler (reported by Markus Elfring). [unfiled] Crash when invalid font paths were passed on command line. [unfiled] Small typo in fontgen's README (Tim Gates). [unfiled] Bad contrast adjustment in images with transparency. 'make test' passes, as well as 'portcheck -N'. No issues found on amd64 and i386. Feedback welcome. Index: Makefile === RCS file: /cvs/ports/graphics/chafa/Makefile,v retrieving revision 1.2 diff -u -p -u -p -r1.2 Makefile --- Makefile24 Sep 2020 20:05:22 - 1.2 +++ Makefile23 Jan 2021 15:36:15 - @@ -1,9 +1,9 @@ # $OpenBSD: Makefile,v 1.2 2020/09/24 20:05:22 danj Exp $ COMMENT = character art facsimile generator -DISTNAME = chafa-1.4.1 +DISTNAME = chafa-1.6.0 -SHARED_LIBS += chafa 0.0 # 4.0 +SHARED_LIBS += chafa 0.0 # 5.0 CATEGORIES = graphics Index: distinfo === RCS file: /cvs/ports/graphics/chafa/distinfo,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 distinfo --- distinfo22 Sep 2020 22:08:23 - 1.1.1.1 +++ distinfo23 Jan 2021 15:36:15 - @@ -1,2 +1,2 @@ -SHA256 (chafa-1.4.1.tar.xz) = RtNANPTJbRIOBjn4eiZZBCfMKelf5UiekDpI7JZAK6M= -SIZE (chafa-1.4.1.tar.xz) = 389428 +SHA256 (chafa-1.6.0.tar.xz) = BwbhAabg6AYzWutXRF4va+/+C+Kadh9WGXnoFpHCxoE= +SIZE (chafa-1.6.0.tar.xz) = 417888 Index: pkg/PLIST === RCS file: /cvs/ports/graphics/chafa/pkg/PLIST,v retrieving revision 1.1.1.1 diff -u -p -u -p -r1.1.1.1 PLIST --- pkg/PLIST 22 Sep 2020 22:08:23 - 1.1.1.1 +++ pkg/PLIST 23 Jan 2021 15:36:15 - @@ -6,6 +6,9 @@ include/chafa/chafa-canvas.h include/chafa/chafa-common.h include/chafa/chafa-features.h include/chafa/chafa-symbol-map.h +include/chafa/chafa-term-db.h +include/chafa/chafa-term-info.h +include/chafa/chafa-term-seq-def.h include/chafa/chafa-util.h include/chafa/chafa-version-macros.h include/chafa/chafa.h @@ -24,6 +27,8 @@ share/gtk-doc/html/chafa/ch02.html share/gtk-doc/html/chafa/chafa-ChafaCanvas.html share/gtk-doc/html/chafa/chafa-ChafaCanvasConfig.html share/gtk-doc/html/chafa/chafa-ChafaSymbolMap.html +share/gtk-doc/html/chafa/chafa-ChafaTermDb.html +share/gtk-doc/html/chafa/chafa-ChafaTermInfo.html share/gtk-doc/html/chafa/chafa-Features.html share/gtk-doc/html/chafa/chafa-Miscellaneous.html share/gtk-doc/html/chafa/chafa-building.html -- greetings, Florian Viehweger
Re: [sparc64] Fix x11/spectrwm runtime
Sebastien Marie wrote: > On Sat, Jan 23, 2021 at 09:04:22PM +0100, Stefan Hagen wrote: >> Sebastien Marie wrote: >>> On Sat, Jan 23, 2021 at 07:14:33PM +0100, Stefan Hagen wrote: Hi, Spectrwm on Sparc64 wants the wpath pledge: 70801 spectrwm CALL open(0x7904d18380,0x10002) 70801 spectrwm NAMI "/var/cache/fontconfig//7908e75dfa020c169504380270e5263a-be64.cache-7" 70801 spectrwm PLDG open, "wpath", errno 1 Operation not permitted 70801 spectrwm PSIG SIGABRT SIG_DFL I've sent the fix upstream and it got merged already. Meanwhile, here is the fixed port. Changes: - added wpath pledge where needed - added revision >>> >>> I am a bit unsure about adding "wpath" in promises. Usually when >>> fontconfig write is involved, it means the cache is out of sync (and >>> it is odd it is happening for the system cache). If I didn't mess >>> myself, I recall about something like that previously. >>> >>> If adding "wpath" is really required, it would be interesting to use >>> also unveil to restrict the promise added. >> >> You're right. I can reproduce it on amd64 now: >> >> If I fiddle with my font paths and then (re)start X, spectrwm crashes >> with a wpath violation on amd64 too. >> >> This is something that can happen with any X application... >> >> Instead of allowing wpath and catching it again with unveil, wouldn't >> it be worth thinking about a pledge promise that allows X font cache >> updates? > > no. the kernel shouldn't have to know what all libraries could do :) > > the responsability is shared between the compoments: > > - it is the application responsability to pledge for what the > application and all linked libraries will need (like sthen@ > mentioned) > > - it is the library responsability to not doing silly things > (regarding fontconfig, we patched out chmod(2) usage from it for > example: https://marc.info/?l=openbsd-cvs=157229154821950=2). > > - it is the responsability of the kernel to enforce, in a generic way, > what the application pledge for, without having a complex interface. > > you could compare pledge(2) usage in cat(1) (it was tame(2) in first > ages) > > https://github.com/openbsd/src/commit/b7db428a8107ad20577d7c8416bf55a8f875e621 > and capsicum > > https://cgit.freebsd.org/src/commit/bin/cat/cat.c?id=aefe30c5437159a5399bdbc1974d6fbf40f2ba0f > . > > >> There is still a difference. On amd64, I can start another WM or an >> xterm and on the next start spectrwm works. The same does not work on >> the sparc64 machine. I don't know what fontconfig is doing there. It >> looks like the font cache is always out of sync here. > > in your ktrace extract, fontconfig is trying to revalidate the > *system* cache (/var/cache/fontconfig). only root could do that (but > fontconfig tries to do it, and will fail due to EPERM - and when > pledged, the fact to try to use O_RDWR makes it to die). > > in "fiddle with my font paths", it should rewrite the user cache > (usually ~/.cache/fontconfig), which is something it has permission to > do (if not killed by pledge). > > I am suspecting some issue in the way your x11 sets were installed > (did you use bsd.rd ? installing from source ?) My system is fairly standard, all sets installed. I upgrade every few days with sysupgrade to the next snapshot and update my ports with pkg_add -u. I'm not installing anything that's not a port or package. > system fontconfig cache comes from xbase68.tgz. Previously, we made > some adjustements too keep it in sync with fonts directories > (https://marc.info/?l=openbsd-cvs=153117126409370=2). > Please note I am also unsure how fonts from ports are managed. > > A possible workaround would be to run `fc-cache -s' as root, but it > will only correct the immediate problem (out-of-sync) and not the > underline problem (why the cache is out-of-sync). Yes, I know how to work around this. There are ways - but it shouldn't need those workarounds. I spend more time on this und this .xsession can reliably reproduce it. (This is on amd64 now) $ cat .xsession #!/bin/sh export PATH=$HOME/.bin:$PATH export ENV=$HOME/.kshrc xset fp+ $HOME/.fonts if [ -f $HOME/.fonts/a.pcf ]; then mv $HOME/.fonts/a.pcf $HOME/.fonts/b.pcf else mv $HOME/.fonts/b.pcf $HOME/.fonts/a.pcf fi ktrace /usr/local/bin/spectrwm fc-cache /usr/local/bin/spectrwm The above can also be reproduced if I change a font in X and then restart X before starting another application that updates the font cache. Now the interesting part: ktrace without wpath pledge (same as above): 74576 spectrwm CALL open(0x60aca42e2c0,0x1) 74576 spectrwm NAMI "/home/sdk/.fonts" 74576 spectrwm RET open 4 74576 spectrwm CALL fstatfs(4,0x7f7c5b20) 74576 spectrwm RET fstatfs 0 74576 spectrwm CALL close(4) 74576 spectrwm RET close 0 74576 spectrwm CALL open(0x60b68610580,0x10002) 74576 spectrwm NAMI
