CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 22:53:50 Modified files: net/ktorrent : Makefile distinfo net/ktorrent/pkg: PLIST Log message: Update ktorrent to 20.12.1 - Enable and switch to python3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 22:52:08 Modified files: net/libktorrent: Makefile distinfo net/libktorrent/pkg: PLIST Log message: Update libktorrent to 20.12.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 22:50:33 Modified files: net/konversation: Makefile distinfo net/konversation/pkg: PLIST Removed files: net/konversation/patches: patch-src_irc_outputfilter_cpp Log message: Update konversation to 20.12.1 - Keep in sync with x11/kde-applications - Switch to Python3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 22:21:24 Modified files: x11/kde-applications: Makefile Log message: Add porters notices
Re: [portgen go] try harder to determine the version
On Tue, Jan 26, 2021 at 05:23:30PM -0700, Aaron Bieber wrote:
> Hi,
>
> Recently a program was found that caused breakage in 'portgen go'. The
> breakage was two fold:
>
> 1) https://proxy.golang.org/qvl.io/promplot/@latest returns unexpected
>results. This caused portgen to bomb out.
> 2) Even it 1) had worked, the logic in 'get_ver_info' was broken and it
>picked the wrong version.
>
> This diff changes things so we first try to get our version from
> '/@latest'. If that fails, we call `get_ver_info` which pulls down the
> full list of versions from the '/@v/list' endpoint.
>
> Thanks to afresh1 for showing me the neat '//=' perl trick!
>
> Tested with:
> portgen go qvl.io/promplot
>
> as well as a number of other ports.
>
> OK? Cluesticks?
>
This seems OK to me, a couple of comments though, but it's up to you
whether you change anything.
> diff 6a862af059a42a1899fe9a62461b2acfc0f8eedc /usr/ports
> blob - 89f2c7297409ef9d54fd1bdde73cf1829c742ff3
> file + infrastructure/lib/OpenBSD/PortGen/Port/Go.pm
> --- infrastructure/lib/OpenBSD/PortGen/Port/Go.pm
> +++ infrastructure/lib/OpenBSD/PortGen/Port/Go.pm
> @@ -67,12 +67,9 @@ sub _go_determine_name
> # Some modules end in "v1" or "v2", if we find one of these, we need
> # to set PKGNAME to something up a level
> my ( $self, $module ) = @_;
> - my $json = $self->get_json( $self->_go_mod_normalize($module) .
> '/@latest' );
>
> - if ($json->{Version} =~ m/incompatible/) {
> - my $msg = "${module} $json->{Version} is incompatible with Go
> modules.";
> - croak $msg;
> - }
Do you still need to check for "incompatible" someplace?
> + my $json = eval { $self->get_json( $self->_go_mod_normalize($module) .
> '/@latest' ) };
Should this eval'd check for `@latest` be in `get_ver_info`?
If not, why not?
Perhaps `get_ver_info` should be:
sub get_ver_info {
my ($self, $module) = @_;
return $self->{ver_info} if $self->{ver_info};
my $ver_info = do { local $@; eval { local $SIG{__DIE__};
$self->_get_latest_ver_info($module) } };
unless ($version) {
my $version = $self->_get_versions($module)->[0];
croak("Unable to find a version for $module")
unless $version;
$ver_info = { Module => $module, Version => $version };
}
return $self->{ver_info} = $ver_info;
}
> + $json //= $self->get_ver_info($module);
>
> if ($module =~ m/v\d$/) {
> $json->{Name} = ( split '/', $module )[-2];
> @@ -81,6 +78,7 @@ sub _go_determine_name
> }
>
> $json->{Module} = $module;
> + $self->{version_info} = $json;
>
> return $json;
> }
> @@ -90,6 +88,7 @@ sub get_dist_info
> my ( $self, $module ) = @_;
>
> my $json = $self->_go_determine_name($module);
> +
> my ($dist, $mods) = $self->_go_mod_info($json);
> $json->{License} = $self->_go_lic_info($module);
>
> @@ -133,7 +132,7 @@ sub _go_mod_info
>
> my $mod = $self->get($self->_go_mod_normalize($json->{Module}) .
> "/\@v/$json->{Version}.mod");
> my ($module) = $mod =~ /\bmodule\s+(.*?)\s/;
> -
> +
> unless ( $json->{Module} eq $module ) {
> my $msg = "Module $json->{Module} doesn't match $module";
> croak $msg;
> @@ -213,6 +212,10 @@ sub _go_mod_normalize
> sub get_ver_info
> {
> my ( $self, $module ) = @_;
> +
> + # We already ran, skip re-running.
> + return $self->{version_info} if defined $self->{version_info};
> +
> my $version_list = $self->get( $module . '/@v/list' );
> my $version = "v0.0.0";
> my $ret;
> @@ -227,13 +230,15 @@ sub get_ver_info
> for my $v ( @parts ) {
> my $a =
> OpenBSD::PackageName::version->from_string($version);
> my $b = OpenBSD::PackageName::version->from_string($v);
> - if ($a->compare($b)) {
> + if ($a->compare($b) == -1) {
> $version = $v;
> }
> }
I think this Schwartzian transform is a bit easier for me to understand
what is going on, but either way this is a good bugfix.
Index: lib/OpenBSD/PortGen/Port/Go.pm
===
RCS file: /cvs/ports/infrastructure/lib/OpenBSD/PortGen/Port/Go.pm,v
retrieving revision 1.7
diff -u -p -r1.7 Go.pm
--- lib/OpenBSD/PortGen/Port/Go.pm 16 Jan 2021 23:38:13 - 1.7
+++ lib/OpenBSD/PortGen/Port/Go.pm 27 Jan 2021 02:42:30 -
@@ -223,14 +223,10 @@ sub get_ver_info
if ($version_list eq "") {
$ret = $self->get_json( $self->_go_mod_normalize($module) .
'/@latest' );
} else {
- my @parts = split("\n", $version_list);
- for my $v ( @parts ) {
- my $a =
OpenBSD::PackageName::version->from_string($version);
- my $b =
sparc64 bulk build report
Bulk build on sparc64-0a.ports.openbsd.org Started : Sun Jan 24 15:35:01 MST 2021 Finished: Tue Jan 26 19:39:36 MST 2021 Duration: 2 Days 4 hours 5 minutes Built using OpenBSD 6.8-current (GENERIC.MP) #657: Sat Jan 23 15:45:28 MST 2021 Built 9340 packages Number of packages built each day: Jan 24: 6510 Jan 25: 2163 Jan 26: 667 Critical path missing pkgs: http://build-failures.rhaalovely.net/sparc64/2021-01-24/summary.log Build failures: 22 http://build-failures.rhaalovely.net/sparc64/2021-01-24/comms/syncterm.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/devel/ccache.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/devel/glog.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/devel/keystone/python,python3.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/devel/spidermonkey78.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/devel/woboq_codebrowser.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/games/frotz.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/games/odamex.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/games/openxcom.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/geo/spatialite/gui.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/graphics/exiv2.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/graphics/inkscape.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/math/mlpack,-main.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/multimedia/gstreamer-0.10/plugins-bad,-main.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/net/barrier.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/net/samba.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/print/gutenprint.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/productivity/gnucash.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/sysutils/libvirt.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/x11/grantlee-qt5.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/x11/qt5/docs,-html.log http://build-failures.rhaalovely.net/sparc64/2021-01-24/x11/roxterm.log Recurrent failures: failures/comms/syncterm.log failures/devel/glog.log failures/devel/keystone/python,python3.log failures/devel/spidermonkey78.log failures/games/frotz.log failures/games/odamex.log failures/games/openxcom.log failures/geo/spatialite/gui.log failures/graphics/inkscape.log failures/math/mlpack,-main.log failures/multimedia/gstreamer-0.10/plugins-bad,-main.log failures/net/barrier.log failures/productivity/gnucash.log failures/sysutils/libvirt.log failures/x11/grantlee-qt5.log failures/x11/roxterm.log New failures: +failures/devel/ccache.log +failures/devel/woboq_codebrowser.log +failures/graphics/exiv2.log +failures/net/samba.log +failures/print/gutenprint.log +failures/x11/qt5/docs,-html.log Resolved failures: -failures/games/pokerth.log -failures/graphics/mypaint.log Packages newly built: +databases/tdb, +databases/tdb,,-main +databases/tdb,,-python +databases/tdb,-main +databases/tdb,-python +devel/py-lief,python3 +games/pokerth +www/py-requests-unixsocket,python3 Packages not built this time: -audio/puddletag -devel/ccache -devel/kf5/kfilemetadata -devel/kf5/kfilemetadata,-locale -devel/kf5/kfilemetadata,-main -devel/p5-Regexp-Copy -devel/woboq_codebrowser -editors/vim,gtk2 -editors/vim,gtk2,-lang -editors/vim,gtk2,-main -editors/vim,gtk2,lua -editors/vim,gtk2,lua,-lang -editors/vim,gtk2,lua,-main -editors/vim,gtk2,perl,python,ruby -editors/vim,gtk2,perl,python,ruby,-lang -editors/vim,gtk2,perl,python,ruby,-main -editors/vim,gtk2,perl,python3,ruby -editors/vim,gtk2,perl,python3,ruby,-lang -editors/vim,gtk2,perl,python3,ruby,-main -editors/vim,gtk3,perl,python,ruby -editors/vim,gtk3,perl,python,ruby,-lang -editors/vim,gtk3,perl,python,ruby,-main -editors/vim,no_x11,perl,python,ruby -editors/vim,no_x11,perl,python,ruby,-main -editors/vim,no_x11,python -editors/vim,no_x11,python,-main -emulators/gns3 -games/valyriatear -graphics/dibuja -graphics/evince -graphics/exiv2 -graphics/geeqie -graphics/gegl04 -graphics/gimp/deskew -graphics/gimp/lensfun -graphics/gimp/liquid-rescale -graphics/gimp/resynthesizer -graphics/gimp/stable -graphics/gthumb -graphics/hugin -graphics/libgexiv2 -graphics/libmypaint -graphics/nomacs -graphics/pdf2djvu -graphics/rawstudio -graphics/shotwell -graphics/ufraw -graphics/viewnior -graphics/xsane,gimp -misc/gramps -net/monitoring-plugins,-samba -net/py-smbc,python3 -net/samba -net/samba,-ldb -net/samba,-main -print/gutenprint -sysutils/backuppc -sysutils/mcollective-plugins/puppet-agent -sysutils/usmb -www/squid,-ntlm -www/squid,krb5,-ntlm -x11/gnome/file-roller -x11/gnome/gvfs, -x11/gnome/gvfs,,-goa -x11/gnome/gvfs,,-google -x11/gnome/gvfs,,-nfs -x11/gnome/gvfs,,-smb -x11/gnome/nautilus -x11/gnome/seahorse-nautilus -x11/gnome/tracker-miners -x11/gnome/tracker3-miners -x11/kde-applications/libkexiv2 -x11/py-qt4
Re: PostgreSQL 13.1 Upgrade
On Tue, 26 Jan 2021 11:03:25 +0100, Pierre-Emmanuel André
wrote:
> I made this small change to database/postgresql/Makefile to fix
> WANTLIB:
>
> @@ -99,7 +98,7 @@ INSTALL_TARGET= install-world
> LIB_DEPENDS-main= archivers/xz \
> converters/libiconv \
> textproc/libxml
> -WANTLIB-main = ${WANTLIB} iconv lzma xml2
> +WANTLIB-main = ${WANTLIB} xml2
>
>
> LIB_DEPENDS-server= databases/postgresql=${VERSION} \
> @@ -119,7 +118,7 @@ LIB_DEPENDS-pg_upgrade= databases/postgr
> WANTLIB-pg_upgrade = ${WANTLIB-main} pq
>
> LIB_DEPENDS-plpython= ${MODPY_LIB_DEPENDS}
> -WANTLIB-plpython = c m pthread util \
> +WANTLIB-plpython = c intl m pthread util \
> ${MODPY_WANTLIB}
> RUN_DEPENDS-plpython= databases/postgresql,-server=${VERSION}
That solves it, thanks!
ok danj@ for the whole thing.
Cheers,
Daniel
[portgen go] try harder to determine the version
Hi,
Recently a program was found that caused breakage in 'portgen go'. The
breakage was two fold:
1) https://proxy.golang.org/qvl.io/promplot/@latest returns unexpected
results. This caused portgen to bomb out.
2) Even it 1) had worked, the logic in 'get_ver_info' was broken and it
picked the wrong version.
This diff changes things so we first try to get our version from
'/@latest'. If that fails, we call `get_ver_info` which pulls down the
full list of versions from the '/@v/list' endpoint.
Thanks to afresh1 for showing me the neat '//=' perl trick!
Tested with:
portgen go qvl.io/promplot
as well as a number of other ports.
OK? Cluesticks?
diff 6a862af059a42a1899fe9a62461b2acfc0f8eedc /usr/ports
blob - 89f2c7297409ef9d54fd1bdde73cf1829c742ff3
file + infrastructure/lib/OpenBSD/PortGen/Port/Go.pm
--- infrastructure/lib/OpenBSD/PortGen/Port/Go.pm
+++ infrastructure/lib/OpenBSD/PortGen/Port/Go.pm
@@ -67,12 +67,9 @@ sub _go_determine_name
# Some modules end in "v1" or "v2", if we find one of these, we need
# to set PKGNAME to something up a level
my ( $self, $module ) = @_;
- my $json = $self->get_json( $self->_go_mod_normalize($module) . '/@latest' );
- if ($json->{Version} =~ m/incompatible/) {
- my $msg = "${module} $json->{Version} is incompatible with Go modules.";
- croak $msg;
- }
+ my $json = eval { $self->get_json( $self->_go_mod_normalize($module) . '/@latest' ) };
+ $json //= $self->get_ver_info($module);
if ($module =~ m/v\d$/) {
$json->{Name} = ( split '/', $module )[-2];
@@ -81,6 +78,7 @@ sub _go_determine_name
}
$json->{Module} = $module;
+ $self->{version_info} = $json;
return $json;
}
@@ -90,6 +88,7 @@ sub get_dist_info
my ( $self, $module ) = @_;
my $json = $self->_go_determine_name($module);
+
my ($dist, $mods) = $self->_go_mod_info($json);
$json->{License} = $self->_go_lic_info($module);
@@ -133,7 +132,7 @@ sub _go_mod_info
my $mod = $self->get($self->_go_mod_normalize($json->{Module}) . "/\@v/$json->{Version}.mod");
my ($module) = $mod =~ /\bmodule\s+(.*?)\s/;
-
+
unless ( $json->{Module} eq $module ) {
my $msg = "Module $json->{Module} doesn't match $module";
croak $msg;
@@ -213,6 +212,10 @@ sub _go_mod_normalize
sub get_ver_info
{
my ( $self, $module ) = @_;
+
+ # We already ran, skip re-running.
+ return $self->{version_info} if defined $self->{version_info};
+
my $version_list = $self->get( $module . '/@v/list' );
my $version = "v0.0.0";
my $ret;
@@ -227,13 +230,15 @@ sub get_ver_info
for my $v ( @parts ) {
my $a = OpenBSD::PackageName::version->from_string($version);
my $b = OpenBSD::PackageName::version->from_string($v);
- if ($a->compare($b)) {
+ if ($a->compare($b) == -1) {
$version = $v;
}
}
$ret = { Module => $module, Version => $version };
}
+ $self->{version_info} = $ret;
+
return $ret;
}
Re: textproc/py-sphinx,python3 build failure
On Tue, Jan 26, 2021 at 07:51:30PM +, Stuart Henderson wrote:
> One method would be to modify setuptools to prevent picking up plugins
> automatically (similar to pytest's PYTEST_DISABLE_PLUGIN_AUTOLOAD -
> hey Kurt, did you know about that one?).
I did _not_ know about that one. Very interesting. I've made a note to
investigate it.
> I think we'd want upstream support if we did that, I imagine it will
> be a pain to maintain.
> Another option, we could do this. It's not very nice because it will
> turn on nojunk for pretty much everything Python, but it is simple.
> Thoughts?
I wish we could mark setuptools_scm itself with nojunk, but that's not
how that works. :|
I agree that modifying setuptools is probably the better angle, but I am
unlikely to be able to dig into that this week. It's the first week of
classes at RIT so I'm unlikely to have the necessary leftover thinking
power.
I guess I worry tagging all python with nojunk perhaps causing fallout
in other ports that start picking up new dependencies beause python
keeps holding off the junk phase. Might be worth trying the below in a
test bulk.
--Kurt
> Index: python.port.mk
> ===
> RCS file: /cvs/ports/lang/python/python.port.mk,v
> retrieving revision 1.124
> diff -u -p -r1.124 python.port.mk
> --- python.port.mk29 Dec 2020 23:59:06 - 1.124
> +++ python.port.mk26 Jan 2021 19:42:47 -
> @@ -132,6 +132,11 @@ MODPY_SETUPUTILS = Yes
> TEST_TARGET ?= test
> _MODPY_USERBASE =
> _MODPY_PRE_BUILD_STEPS += ;${MODPY_CMD} egg_info || true
> +# Setuptools opportunistically picks up plugins. If it picks one up that
> +# uses finalize_distribution_options (usually setuptools_scm), junking
> +# that plugin will cause failure at the end of build.
> +# In the absence of a targetted means of disabling this, use a big hammer:
> +DPB_PROPERTIES +=nojunk
> .else
> # Try to detect the case where a port will build regardless of setuptools
> # but the final plist will be different if it's present.
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 14:18:49 Modified files: security/sudo : Tag: OPENBSD_6_8 Makefile Log message: add FLAVOR_STRING to SUBST_VARS, fixing an issue with updates from pre- multipackage versions reported by danj@ and reproduced by tb@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 14:18:35 Modified files: security/sudo : Makefile Log message: add FLAVOR_STRING to SUBST_VARS, fixing an issue with updates from pre- multipackage versions reported by danj@ and reproduced by tb@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2021/01/26 13:31:56 Modified files: www: Makefile www/p5-Test-LWP-UserAgent: Makefile distinfo Log message: hook www/p5-Test-LWP-UserAgent This has been in tree since 2020/02/23 but was never hooked. While here small update to latest version and change MAINTAINER address
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 13:23:19 Modified files: devel/kf5/kcompletion: Makefile Added files: devel/kf5/kcompletion/patches: patch-src_klineedit_cpp Log message: Backport shortcut breaking regression in KLineEdit https://bugs.kde.org/show_bug.cgi?id=431493 Recommended from upstream
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 13:22:17 ports/devel/kf5/kcompletion/patches Update of /cvs/ports/devel/kf5/kcompletion/patches In directory cvs.openbsd.org:/tmp/cvs-serv32593/patches Log Message: Directory /cvs/ports/devel/kf5/kcompletion/patches added to the repository
Re: [update] deve/py-llvmlite to 0.34.0
On 1/26/21 8:23 AM, Stuart Henderson wrote:
> On 2021/01/26 08:18, Aisha Tammy wrote:
>> bumpity bump bump
>>
>>
>> On 1/17/21 12:04 PM, Aisha Tammy wrote:
>>> Another bump?
>>>
>>> Aisha
>>>
>>> On 11/29/20 11:48 AM, Aisha Tammy wrote:
bump?
both packages are building fine, llvmlite is working locally.
I don't use py-miasm but as mentioned in my previous email, tests
did work after install.
Unfortunately, I am not going to be able to help clean up the patches
as I am busy with schoolwork but wanted to give a reminder nonetheless.
Best,
Aisha
> Please reinclude the diff/tar with bumps.
>
Got it, will include diffs on other bumps, have now attached it here:
What diff does
- unbreak py-llvmlite and update to latest 0.34.0
all tests are passing
- unbreak py-miasm and make it work with latest llvmlite
tests aren't working from inside makefile but pass when run manually after
install
Cheers,
Aisha
diff --git a/devel/py-llvmlite/Makefile b/devel/py-llvmlite/Makefile
index c20460f77e8..b530cf3321c 100644
--- a/devel/py-llvmlite/Makefile
+++ b/devel/py-llvmlite/Makefile
@@ -1,10 +1,8 @@
# $OpenBSD: Makefile,v 1.9 2020/08/22 22:06:01 naddy Exp $
-BROKEN = requires update to 0.34.0 for LLVM 10
COMMENT = lightweight LLVM-Python binding for writing JIT compilers
-MODPY_EGG_VERSION =0.29.0
-REVISION = 1
+MODPY_EGG_VERSION =0.34.0
GH_ACCOUNT = numba
GH_PROJECT = llvmlite
GH_TAGNAME = v${MODPY_EGG_VERSION}
@@ -19,20 +17,22 @@ HOMEPAGE = http://llvmlite.pydata.org/
# BSD
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} LLVM m
+WANTLIB += ${COMPILER_LIBCXX} LLVM m
COMPILER = base-clang
MODULES = lang/python
FLAVORS = python3
-FLAVOR ?=
+FLAVOR ?= python3
-.if !${FLAVOR:Mpython3}
-BUILD_DEPENDS += devel/py-enum34
-RUN_DEPENDS += devel/py-enum34
-.endif
+MAKE_ENV +=LLVM_CONFIG="/usr/bin/llvm-config" \
+ LDLIBS="`llvm-config --libs all`" \
+ CXXFLAGS="`llvm-config --cxxflags` -fPIC ${CXXFLAGS}" \
+ LDFLAGS="`llvm-config --ldflags`"
-MAKE_ENV = LLVM_CONFIG="/usr/bin/llvm-config"
+pre-build:
+ cd ${WRKSRC} && env -i ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
+ -f LIB_MAKEFILE
do-test:
cd ${WRKSRC} && PYTHONPATH=. ${SETENV} ${MODPY_BIN} ./runtests.py
diff --git a/devel/py-llvmlite/distinfo b/devel/py-llvmlite/distinfo
index 464df2c98f1..4e116070593 100644
--- a/devel/py-llvmlite/distinfo
+++ b/devel/py-llvmlite/distinfo
@@ -1,2 +1,2 @@
-SHA256 (llvmlite-0.29.0.tar.gz) = vO54HC3Ga+09tbqF9cBMTv/TjHwQ9Sh+6+qBy029zjQ=
-SIZE (llvmlite-0.29.0.tar.gz) = 196507
+SHA256 (llvmlite-0.34.0.tar.gz) = rqXDPVkUW5YlHRGXG60m2BgQliq2g9EHtu9KGEctPZo=
+SIZE (llvmlite-0.34.0.tar.gz) = 210438
diff --git a/devel/py-llvmlite/patches/patch-LIB_MAKEFILE
b/devel/py-llvmlite/patches/patch-LIB_MAKEFILE
new file mode 100644
index 000..0e491ddbf54
--- /dev/null
+++ b/devel/py-llvmlite/patches/patch-LIB_MAKEFILE
@@ -0,0 +1,13 @@
+$OpenBSD$
+
+upstream libllvmlite.so doesn't build nicely
+
+Index: config_makefile
+--- LIB_MAKEFILE.orig
LIB_MAKEFILE
+@@ -0,0 +1,5 @@
++SRC=ffi/*.cpp
++
++ffi/libllvmlite.so:
++ $(CXX) -shared $(CXXFLAGS) $(LDFLAGS) -o $@ $(SRC) $(LDLIBS)
++
diff --git a/devel/py-llvmlite/pkg/PLIST b/devel/py-llvmlite/pkg/PLIST
index dcbc4e9780d..1a56a66754b 100644
--- a/devel/py-llvmlite/pkg/PLIST
+++ b/devel/py-llvmlite/pkg/PLIST
@@ -5,7 +5,6 @@ lib/python${MODPY_VERSION}/site-packages/llvmlite/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/llvmlite/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/llvmlite/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/llvmlite/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
-lib/python${MODPY_VERSION}/site-packages/llvmlite/${MODPY_PYCACHE}six.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/llvmlite/${MODPY_PYCACHE}utils.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/llvmlite/_version.py
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/
@@ -34,7 +33,7 @@
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/dylib.py
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/executionengine.py
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/ffi.py
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/initfini.py
-lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/libllvmlite.so
+@so lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/libllvmlite.so
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/linker.py
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/module.py
lib/python${MODPY_VERSION}/site-packages/llvmlite/binding/object_file.py
@@ -71,7 +70,6 @@
lib/python${MODPY_VERSION}/site-packages/llvmlite/llvmpy/${MODPY_PYCACHE}core.${
Re: textproc/py-sphinx,python3 build failure
On 2021/01/26 18:59, Christian Weisgerber wrote:
> textproc/py-sphinx,python3 failed to build in my latest amd64 bulk
> build.
>
> ModuleNotFoundError: No module named 'setuptools_scm'
If the setuptools_scm plugin is present at the start of build, setuptools
adds a hook via setuptools.finalize_distribution_options. Here setuptools_scm
is pulled in by another port so is present on the build machine, sphinx
configures/builds and somewhere during that setuptools_scm was junked,
but it still tries to run the hook.
Adding setuptools_scm as a dependency to ports where we notice the problem
shouldn't be done as it will just move the problem elsewhere (the more
ports that have it as a listed dep, the more we'll run into it).
One method would be to modify setuptools to prevent picking up plugins
automatically (similar to pytest's PYTEST_DISABLE_PLUGIN_AUTOLOAD - hey
Kurt, did you know about that one?). I think we'd want upstream support
if we did that, I imagine it will be a pain to maintain.
Another option, we could do this. It's not very nice because it will
turn on nojunk for pretty much everything Python, but it is simple.
Thoughts?
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.124
diff -u -p -r1.124 python.port.mk
--- python.port.mk 29 Dec 2020 23:59:06 - 1.124
+++ python.port.mk 26 Jan 2021 19:42:47 -
@@ -132,6 +132,11 @@ MODPY_SETUPUTILS = Yes
TEST_TARGET ?= test
_MODPY_USERBASE =
_MODPY_PRE_BUILD_STEPS += ;${MODPY_CMD} egg_info || true
+# Setuptools opportunistically picks up plugins. If it picks one up that
+# uses finalize_distribution_options (usually setuptools_scm), junking
+# that plugin will cause failure at the end of build.
+# In the absence of a targetted means of disabling this, use a big hammer:
+DPB_PROPERTIES += nojunk
.else
# Try to detect the case where a port will build regardless of setuptools
# but the final plist will be different if it's present.
Remove Qt4 checks in portcheck
Simple diff to remove Qt4 checks. OK?
Index: portcheck
===
RCS file: /cvs/ports/infrastructure/bin/portcheck,v
retrieving revision 1.134
diff -u -p -r1.134 portcheck
--- portcheck 12 Dec 2020 15:12:07 - 1.134
+++ portcheck 26 Jan 2021 19:30:13 -
@@ -940,8 +940,8 @@ sub_checks() {
#
# * Manual pages shouldn't be compressed.
#
-# * If port installs QML files, it should depend on either x11/qt4,-main
-# or x11/qt5/qtdeclarative,-main
+# * If port installs QML files, it should depend on
+# x11/qt5/qtdeclarative,-main
#
# * Qt5-QML files should live under PREFIX/lib/qt5/qml/.
#
@@ -998,7 +998,7 @@ check_plist() {
local regsh_exec=false unregsh_exec=false
local qml_found=false qt5_qml_found=false non_qt5_qml_found=false
- local qt4_dep=false qt5_dep=false qt5declarative_dep=false
+ local qt5_dep=false qt5declarative_dep=false
local lib_found=false
local owner_set=false group_set=false mode_set=false
@@ -1077,9 +1077,6 @@ check_plist() {
"invocation: ${l#@* }"
;;
- "@depend x11/qt4,-main"*)
- qt4_dep=true
- ;;
"@depend x11/qt5/qtdeclarative,-main"*)
qt5declarative_dep=true
qt5_dep=true
@@ -1215,16 +1212,11 @@ check_plist() {
fi
# QML
- $qml_found && ! $qt4_dep && ! $qt5_dep &&
- [[ $fullpkgname != qt4-[0-9]* ]] &&
- [[ $fullpkgname != qtdeclarative-[0-9]* ]] &&
- err "${portref}looks like providing QML files without" \
- "Qt dependency"
$qt5_qml_found && ! $qt5declarative_dep &&
[[ $fullpkgname != qtdeclarative-[0-9]* ]] &&
err "${portref}provides Qt5 QML files without" \
"x11/qt5/qtdeclarative dependency"
- $qt5_dep && ! $qt4_dep && $non_qt5_qml_found &&
+ $qt5_dep && $non_qt5_qml_found &&
err "${portref}depends on Qt5 but installs QML files" \
"outside PREFIX/lib/qt5/qml/"
Re: [patch] UPDATE: converters/libiconv: pledge iconv binary
On Tue, Jan 26, 2021 at 03:56:11PM +, Stuart Henderson wrote:
> On 2021/01/26 15:31, Clemens Gößnitzer wrote:
> > January 26, 2021 3:44 PM, "Hiltjo Posthuma" wrote:
> > > On Sat, Jan 16, 2021 at 04:29:27PM +0100, Hiltjo Posthuma wrote:
> > >> On Mon, Jan 11, 2021 at 07:50:55PM +0100, Hiltjo Posthuma wrote:
> > >>
> > >> The below patch pledges the iconv binary in the libiconv package. The
> > >> tool is
> > >> useful for converting text-encoding of text data to UTF-8 for example.
> > >>
> > >> It now uses pledge("stdio", NULL) if only using stdin/stdout. It uses
> > >> pledge("stdio rpath", NULL) when specifying files.
> > >>
> > >> I've tested many command-line option combinations and haven't found
> > >> missing
> > >> promises which cause an abort().
> > >>
> > >> Patch:
> ..
> > >> +@@ -846,6 +849,9 @@
> > >> + struct iconv_hooks hooks;
> > >> + int i;
> > >> + int status;
> > >> ++
> > >> ++ if (pledge(i == argc ? "stdio" : "stdio rpath", NULL) == -1)
> >
> > Wouldn't you use i uninitialised here?
> >
> > >> ++ err(1, "pledge");
> > >> +
> > >> + set_program_name (argv[0]);
> > >> + #if HAVE_SETLOCALE
> > >> --
>
> Yes, it needs to be done after parsing the arguments in the loop after
> calling textdomain().
>
> Looks like it was previously done like that but moved before sending out
> the diff? I assume it was moved so that more of the code was moved under
> pledge. Better approach might be to unconditionally pledge stdio rpath,
> then, after the loop, conditionally pledge again to drop rpath if
> possible.
>
> It would be nicer to use the error function used in the rest of
> the file rather than pulling in another header for err().
>
Hi,
Thanks both for the review! I updated the changes in the patch below.
It was indeed a mistake in creating the patch, I'm sorry for the sloppiness.
>From dbb04c280d8ca368da43c0fdf185c3e9a4a59050 Mon Sep 17 00:00:00 2001
From: Hiltjo Posthuma
Date: Tue, 26 Jan 2021 20:21:32 +0100
Subject: [PATCH] libiconv: pledge iconv(1) binary
---
converters/libiconv/Makefile | 3 +-
converters/libiconv/patches/patch-src_iconv_c | 29 +++
2 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 converters/libiconv/patches/patch-src_iconv_c
diff --git a/converters/libiconv/Makefile b/converters/libiconv/Makefile
index 2ab58ea4519..5c8043270de 100644
--- a/converters/libiconv/Makefile
+++ b/converters/libiconv/Makefile
@@ -5,7 +5,7 @@ COMMENT=character set conversion library
DISTNAME= libiconv-1.16
CATEGORIES=converters devel
MASTER_SITES= ${MASTER_SITE_GNU:=libiconv/}
-REVISION= 0
+REVISION= 1
SHARED_LIBS= charset 1.1 \
iconv 7.0
@@ -17,6 +17,7 @@ MAINTAINER= Brad Smith
# LGPLv2 and GPLv3
PERMIT_PACKAGE=Yes
+# uses pledge()
WANTLIB= c
SEPARATE_BUILD=Yes
diff --git a/converters/libiconv/patches/patch-src_iconv_c
b/converters/libiconv/patches/patch-src_iconv_c
new file mode 100644
index 000..9b673fbe5db
--- /dev/null
+++ b/converters/libiconv/patches/patch-src_iconv_c
@@ -0,0 +1,29 @@
+--- src/iconv.c.orig Fri Apr 26 20:50:13 2019
src/iconv.cTue Jan 26 20:07:34 2021
+@@ -19,6 +19,8 @@
+ # define ICONV_CONST
+ #endif
+
++#include
++
+ #include
+ #include
+ #include
+@@ -847,6 +849,8 @@
+ int i;
+ int status;
+
++ if (pledge("stdio rpath", NULL) == -1)
++error(EXIT_FAILURE, errno, "pledge");
+ set_program_name (argv[0]);
+ #if HAVE_SETLOCALE
+ /* Needed for the locale dependent encodings, "char" and "wchar_t",
+@@ -1002,6 +1006,8 @@
+ }
+ break;
+ }
++ if ((do_list || i == argc) && pledge("stdio", NULL) == -1)
++error(EXIT_FAILURE, errno, "pledge");
+ if (do_list) {
+ if (i != 2 || i != argc)
+ usage(1);
--
2.30.0
--
Kind regards,
Hiltjo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 12:11:31 Modified files: security/sudo : Tag: OPENBSD_6_8 Makefile distinfo Log message: Update to sudo 1.9.5p2; fixes CVE-2021-3156
Re: Qt4 on diet or to hell
Hello Rafael, I'm sorry for jumping into the discussione so late. On 26/01/2021 09:45, Rafael Sadowski wrote: Hi Qt4 lovers, qucs-s in the only Qt4 consumer left in our CVS tree. I have spoken with the maintainer and he told me that the port is actively used (not only from him). It looks like cad/qucs-s is the only functional GUI for SPICE-like simulators on OpenBSD. To be honest Qt4 applications are looking a little bit broken. Alessandro De Laurenzis has described this here: https://marc.info/?l=openbsd-ports=160733053308591=2 I see two options. Number 1: We say goodbye to Qt4/qucs-s and delete it. Number 2: We deactivate everything that is possible and not needed by qucs-s. This means that we have to live with the Qt4 issue. I will not invest any time. This is the real point, actually. As I described in [1], the same symptoms that I observe in qucs-s seem to affect qtconfig4, which is an integral part of the *library* (it would be good if someone could confirm this...) So, AFAICS, we have a broken qt4 subsystem at the moment; and, because of that, qucs-s is completely unusable. In these conditions, I don't see the point in keeping it into the tree. qucs-s is more than a GUI for SPICE-based simulators (ngspice in our case); it is a kind of integrated environment for circuital analysis and, in this respect, it is close to be a "unique" project. Without it, we have only a few alternatives in our ports: 1) kicad (and specifically eeschema): a bit bloated, if you ask me, but probably still usable; 2) xschem (for schematic capture only; it can also act as a very primitive simulator launcher). So, even it is my preferred solution, qucs-s isn't essential. But let me stress my point once more: either we preserve the qt4 subsystem (possibly limiting the tree content to what qucs-s strictly needs) and *actively maintain it*, i.e. investing time in bug fixing and/or patch back-porting from upstream, or we remove it completely, including qucs-s. My few cents [1] https://marc.info/?l=openbsd-ports=160733053308591=2 -- Alessandro De Laurenzis [mailto:jus...@atlantide.mooo.com] Web: http://www.atlantide.mooo.com LinkedIn: http://it.linkedin.com/in/delaurenzis
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Sun Jan 24 00:59:29 MST 2021 finished at Tue Jan 26 11:46:08 MST 2021 lasted 2D10h46m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #987: Sat Jan 23 15:32:49 MST 2021 built packages:10723 Jan 24:3831 Jan 25:2284 Jan 26:4607 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2021-01-24/summary.log build failures: 19 http://build-failures.rhaalovely.net/aarch64/2021-01-24/astro/stellarium.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/comms/gnuradio.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/converters/wv2.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/devel/glog.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/devel/kf5/kimageformats.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/editors/calligra.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/emulators/vice.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/games/shockolate.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/net/samba,,-ldb.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/security/age.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/sysutils/ruby-puppet/5.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/sysutils/ruby-puppet/6.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/www/chromium.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/x11/kde-applications/spectacle.log http://build-failures.rhaalovely.net/aarch64/2021-01-24/x11/qt5/qtwebengine.log recurrent failures failures/comms/gnuradio.log failures/converters/wv2.log failures/devel/glog.log failures/editors/calligra.log failures/editors/xwpe.log failures/emulators/vice.log failures/games/shockolate.log failures/security/age.log failures/sysutils/nomad.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log failures/www/chromium.log failures/x11/qt5/qtwebengine.log new failures +++ ls-failures Tue Jan 26 11:46:21 2021 +failures/astro/stellarium.log +failures/devel/kf5/kimageformats.log +failures/net/samba,,-ldb.log +failures/sysutils/ruby-puppet/5.log +failures/sysutils/ruby-puppet/6.log +failures/x11/kde-applications/spectacle.log resolved failures --- ../old/aarch64/last//ls-failuresFri Jan 22 16:04:49 2021 -failures/games/pokerth.log -failures/net/pmacct,postgresql.log -failures/www/apertium-apy.log -failures/www/firefox-i18n/ro.log -failures/www/firefox-i18n/ru.log -failures/www/firefox-i18n/si.log -failures/www/firefox-i18n/sk.log -failures/www/firefox-i18n/sl.log -failures/www/firefox-i18n/son.log -failures/www/firefox-i18n/sq.log -failures/www/firefox-i18n/sr.log -failures/www/firefox-i18n/sv-SE.log -failures/www/firefox-i18n/ta.log -failures/www/firefox-i18n/te.log -failures/www/firefox-i18n/th.log -failures/www/firefox-i18n/tr.log -failures/www/firefox-i18n/uk.log -failures/www/firefox-i18n/vi.log -failures/www/firefox-i18n/xh.log -failures/www/firefox-i18n/zh-CN.log -failures/www/firefox-i18n/zh-TW.log
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 11:29:01 Modified files: x11/qt4: Makefile x11/qt4/pkg: PLIST-examples PLIST-main Log message: Qt4 on diet Disable QtOpenGL, QtMultimedia, QtXmlPatterns, QtScriptTools, QtWebKit, phonon, QtDeclaratin, QtScriptTools to save CPU- and lifetime. Nothing depends on it. Many +1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mill...@cvs.openbsd.org 2021/01/26 11:19:19 Modified files: security/sudo : Makefile distinfo Log message: Update to sudo 1.9.5p2; fixes CVE-2021-3156
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 11:18:47 Modified files: fonts/dina-fonts: Makefile Log message: Drop me as maintainer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 11:17:42 Modified files: devel/jenkins/devel: Makefile distinfo Log message: Bump to jenkins-devel 2.277
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 11:17:40 Modified files: net/unifi : Makefile.inc net/unifi/stable: Makefile distinfo net/unifi/stable/pkg: PLIST Log message: update to unifi-6.0.45
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 11:17:15 Modified files: databases/influxdb: Makefile sysutils/telegraf: Makefile Log message: Drop me as maintainer I can't find the time to become familiar with the Go ports infrastructure. Still a user and happy to see updates.
Re: [NEW] graphics/openvdb
On Tue, Jan 26, 2021 at 01:44:50PM +, Stuart Henderson wrote: > On 2021/01/03 10:34, Rafael Sadowski wrote: > > > > OpenVDB is an Academy Award-winning open-source C++ library comprising > > > > a novel > .. > > > > Build, run tested with blender. > > > > No regression tests available. > > > > > > > > Any comments,OK's? > > > > > > > Port-wise it looks good to me. If someone wants to import, ok rsadowski@ > > Done. Many thanks for the imports. I'll be including all of these in next blender update which has already come through. Might as well drop the ffmpeg patch during that update. regards, Dimitri
textproc/py-sphinx,python3 build failure
textproc/py-sphinx,python3 failed to build in my latest amd64 bulk build. ModuleNotFoundError: No module named 'setuptools_scm' >>> Building on amd64-2 under textproc/py-sphinx,python3 BDEPENDS = [www/py-jinja2,python3;devel/py-setuptools,python3;devel/py-six,python3;textproc/py-alabaster,python3;textproc/py-snowballstemmer,python3;graphics/py-imagesize,python3;textproc/py-pygments,python3;textproc/py-docutils,python3;devel/py-babel,python3;www/py-requests,python3;lang/python/3.8] DIST = [textproc/py-sphinx,python3:Sphinx-1.5.6.tar.gz] FULLPKGNAME = py3-sphinx-1.5.6 RDEPENDS = [textproc/py-pygments,python3;graphics/py-imagesize,python3;textproc/py-snowballstemmer,python3;textproc/py-alabaster,python3;devel/py-six,python3;devel/py-setuptools,python3;www/py-jinja2,python3;lang/python/3.8;www/py-requests,python3;devel/py-babel,python3;textproc/py-docutils,python3] (Junk lock obtained for amd64-2 at 1611681471.46) >>> Running depends in textproc/py-sphinx,python3 at 1611681471.52 last junk was in devel/py-parso,python3 /usr/sbin/pkg_add -aI -Drepair py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 was: /usr/sbin/pkg_add -aI -Drepair py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 python-3.8.7 /usr/sbin/pkg_add -aI -Drepair py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 >>> Running show-prepare-results in textproc/py-sphinx,python3 at 1611681475.35 ===> textproc/py-sphinx,python3 ===> py3-sphinx-1.5.6 depends on: py3-babel-* -> py3-babel-2.8.0p0 ===> py3-sphinx-1.5.6 depends on: py3-six-* -> py3-six-1.15.0 ===> py3-sphinx-1.5.6 depends on: py3-imagesize-* -> py3-imagesize-1.1.0p2 ===> py3-sphinx-1.5.6 depends on: py3-alabaster-* -> py3-alabaster-0.7.10p2 ===> py3-sphinx-1.5.6 depends on: py3-docutils-* -> py3-docutils-0.12p3 ===> py3-sphinx-1.5.6 depends on: py3-pygments-* -> py3-pygments-2.5.2p1 ===> py3-sphinx-1.5.6 depends on: py3-snowballstemmer-* -> py3-snowballstemmer-2.0.0 ===> py3-sphinx-1.5.6 depends on: py3-jinja2-* -> py3-jinja2-2.11.2p1 ===> py3-sphinx-1.5.6 depends on: py3-requests-* -> py3-requests-2.25.0 ===> py3-sphinx-1.5.6 depends on: python->=3.8,<3.9 -> python-3.8.7 ===> py3-sphinx-1.5.6 depends on: py3-setuptools->=39.0.1v0 -> py3-setuptools-44.1.1v0 py3-alabaster-0.7.10p2 py3-babel-2.8.0p0 py3-docutils-0.12p3 py3-imagesize-1.1.0p2 py3-jinja2-2.11.2p1 py3-pygments-2.5.2p1 py3-requests-2.25.0 py3-setuptools-44.1.1v0 py3-six-1.15.0 py3-snowballstemmer-2.0.0 python-3.8.7 (Junk lock released for amd64-2 at 1611681476.62) Woken up devel/py-jaraco-functools,python3 distfiles size=4410607 >>> Running build in textproc/py-sphinx,python3 at 1611681476.70 ===> textproc/py-sphinx,python3 ===> Checking files for py3-sphinx-1.5.6 `/usr/ports/distfiles/Sphinx-1.5.6.tar.gz' is up to date. >> (SHA256) Sphinx-1.5.6.tar.gz: OK ===> Extracting for py3-sphinx-1.5.6 ===> Patching for py3-sphinx-1.5.6 ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ ===> Generating configure for py3-sphinx-1.5.6 ===> Configuring for py3-sphinx-1.5.6 ===> Building for py3-sphinx-1.5.6 running egg_info writing Sphinx.egg-info/PKG-INFO writing dependency_links to Sphinx.egg-info/dependency_links.txt writing entry points to Sphinx.egg-info/entry_points.txt writing requirements to Sphinx.egg-info/requires.txt writing top-level names to Sphinx.egg-info/top_level.txt reading manifest file 'Sphinx.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' warning: no files found matching 'sphinx/locale/.tx/config' no previously-included directories found matching 'doc/_build' no previously-included directories found matching 'sphinx/locale/.tx' writing manifest file 'Sphinx.egg-info/SOURCES.txt' running build running build_py creating /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib creating /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/__init__.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/__main__.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/addnodes.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/apidoc.py -> /usr/obj/ports/py-sphinx-1.5.6-python3/Sphinx-1.5.6/lib/sphinx copying sphinx/application.py ->
Re: [update] deve/py-llvmlite to 0.34.0
bumpity bump bump On 1/17/21 12:04 PM, Aisha Tammy wrote: > Another bump? > > Aisha > > On 11/29/20 11:48 AM, Aisha Tammy wrote: >> bump? >> >> both packages are building fine, llvmlite is working locally. >> I don't use py-miasm but as mentioned in my previous email, tests >> did work after install. >> >> Unfortunately, I am not going to be able to help clean up the patches >> as I am busy with schoolwork but wanted to give a reminder nonetheless. >> >> Best, >> Aisha >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/26 09:26:21 Modified files: graphics/geeqie: Makefile Log message: Add missing LDEP on graphics/openjp2.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/26 08:58:38 Modified files: www/firefox-esr: Tag: OPENBSD_6_8 Makefile distinfo Log message: www/firefox-esr: MFC update to 78.7.0. See https://www.mozilla.org/en-US/firefox/78.7.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2021-04/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/26 08:57:55 Modified files: www/seamonkey-i18n: Makefile.inc distinfo Log message: www/seamonkey-i18N: update to 2.53.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/26 08:57:24 Modified files: www/seamonkey : Makefile distinfo www/seamonkey/pkg: PLIST-main Added files: www/seamonkey/patches: patch-js_src_ctypes_libffi_src_dlmalloc_c patch-security_manager_pki_resources_content_exceptionDialog_js patch-widget_nsPrintSettingsImpl_cpp Removed files: www/seamonkey/patches: patch-mozilla_ipc_chromium_src_base_process_util_bsd_cc patch-mozilla_js_src_ctypes_libffi_src_dlmalloc_c patch-mozilla_security_manager_pki_resources_content_exceptionDialog_js patch-mozilla_third_party_rust_packed_simd_src_api_into_bits_arch_specific_rs patch-mozilla_third_party_rust_packed_simd_src_codegen_reductions_mask_x86_rs patch-mozilla_third_party_rust_packed_simd_src_lib_rs patch-mozilla_widget_nsPrintSettingsImpl_cpp Log message: www/seamonkey: update to 2.53.6. See https://www.seamonkey-project.org/releases/seamonkey2.53.6/ - the topsrcdir changed, so some patches are renamed - build comm/suite instead of suite - remove patches fixing build with rust 1.48.0, merged upstream
Re: [patch] UPDATE: converters/libiconv: pledge iconv binary
On 2021/01/26 15:31, Clemens Gößnitzer wrote:
> January 26, 2021 3:44 PM, "Hiltjo Posthuma" wrote:
> > On Sat, Jan 16, 2021 at 04:29:27PM +0100, Hiltjo Posthuma wrote:
> >> On Mon, Jan 11, 2021 at 07:50:55PM +0100, Hiltjo Posthuma wrote:
> >>
> >> The below patch pledges the iconv binary in the libiconv package. The tool
> >> is
> >> useful for converting text-encoding of text data to UTF-8 for example.
> >>
> >> It now uses pledge("stdio", NULL) if only using stdin/stdout. It uses
> >> pledge("stdio rpath", NULL) when specifying files.
> >>
> >> I've tested many command-line option combinations and haven't found missing
> >> promises which cause an abort().
> >>
> >> Patch:
..
> >> +@@ -846,6 +849,9 @@
> >> + struct iconv_hooks hooks;
> >> + int i;
> >> + int status;
> >> ++
> >> ++ if (pledge(i == argc ? "stdio" : "stdio rpath", NULL) == -1)
>
> Wouldn't you use i uninitialised here?
>
> >> ++ err(1, "pledge");
> >> +
> >> + set_program_name (argv[0]);
> >> + #if HAVE_SETLOCALE
> >> --
Yes, it needs to be done after parsing the arguments in the loop after
calling textdomain().
Looks like it was previously done like that but moved before sending out
the diff? I assume it was moved so that more of the code was moved under
pledge. Better approach might be to unconditionally pledge stdio rpath,
then, after the loop, conditionally pledge again to drop rpath if
possible.
It would be nicer to use the error function used in the rest of
the file rather than pulling in another header for err().
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/26 08:54:32 Modified files: www/firefox-esr: Makefile distinfo www/firefox-esr-i18n: Makefile.inc distinfo Log message: www/firefox-esr: update to 78.7.0. See https://www.mozilla.org/en-US/firefox/78.7.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2021-04/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 08:54:42 Modified files: x11/yakuake: Makefile distinfo x11/yakuake/pkg: PLIST Log message: Update yakuake to 20.12.1 This is a official KDE application which lives outside of x11/kde-applications. Keep in sync with our KDE version.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/01/26 08:52:58 Modified files: www/mozilla-firefox: Makefile distinfo www/mozilla-firefox/patches: patch-config_makefiles_rust_mk patch-dom_ipc_ContentChild_cpp patch-toolkit_system_gnome_nsGIOService_cpp www/firefox-i18n: Makefile.inc distinfo Removed files: www/mozilla-firefox/patches: patch-third_party_libwebrtc_webrtc_modules_desktop_capture_desktop_capture_generic_gn_moz_build Log message: www/mozilla-firefox: update to 85.0. See https://www.mozilla.org/en-US/firefox/85.0/releasenotes/ Fixes https://www.mozilla.org/en-US/security/advisories/mfsa2021-03/ remove patch from #1677715, merged upstream.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 08:47:11 Modified files: graphics : Makefile Log message: +alembic
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 08:46:19 Log message: Import alembic-1.7.16, from deserter666 at danwin1210.me, ok sthen@ Alembic is an open computer graphics interchange framework. It distills complex, animated scenes into a non-procedural, application-independent set of baked geometric results. This "distillation" of scenes into baked geometry is exactly analogous to the distillation of lighting and rendering scenes into rendered image data. Alembic is focused on efficiently storing the computed results of complex procedural geometric constructions. It is very specifically NOT concerned with storing the complex dependency graph of procedural tools used to create the computed results. Status: Vendor Tag: rsadowski Release Tags: rsadowski_20210126 N ports/graphics/alembic/Makefile N ports/graphics/alembic/distinfo N ports/graphics/alembic/pkg/DESCR N ports/graphics/alembic/pkg/PLIST N ports/graphics/alembic/patches/patch-lib_Alembic_AbcCoreOgawa_StreamManager_cpp No conflicts created by this import
Re: [NEW] games/moonlight-qt
On Tue Jan 26, 2021 at 02:15:20PM +0100, Muhammad Kaisar Arkhan wrote:
> Hello ports@,
>
> Moonlight (formerly Limelight) is an open source implementation of
> NVIDIA's GameStream protocol. With Moonlight, You can stream your
> collection of PC games from your GameStream-compatible PC to any
> supported device and play them remotely.
>
> In order to properly test this port, a PC running Windows with an NVIDIA GPU
> (that's capable of running GameStream) is required. You need to install more
> proprietary bloatware^W^W^WNVIDIA GeForce Experience and setup NVIDIA
> GameStream.
>
> More info on that can be found here:
> https://www.nvidia.com/en-us/support/gamestream/gamestream-pc-setup/.
>
> If you don't have an NVIDIA GPU like I do, you can use Sunshine[1] which is
> an NVIDIA GameStream server reimplementation. You can download the pre-built
> binaries from the GitHub tags/releases page and download the zip file.
>
> From there, you can simply launch the sunshine.exe file. Since it appears
> that sunshine lacks the capability to advertise to GameStream clients (like
> Moonlight), you have to add your PC manually via the IP address. When you
> try to connect for the first time, it will ask you to enter a pin. Since
> sunshine doesn't have any GUI/TUI at all, on the same Windows PC, you need
> to go to http://127.0.0.1/pin/ to accept the pairing
> request. After that, you should be able to connect!
>
> From my experience using this port and sunshine, it works fine and it's a
> bit sluggish but I'm not sure if that's caused by sunshine not supporting
> hardware encoding or the lack of hardware decoding on OpenBSD but it's much
> more usable in comparison to using Parsec/Rainway within chromium since it
> works entirely in your local network.
>
> OK?
>
> [1]: https://github.com/loki-47-6F-64/sunshine
>
> --
> Muhammad Kaisar Arkhan
> h...@yukiisbo.red - kai...@arkhan.io
> https://yukiisbo.red - https://arkhan.io
Just a quick Qt port review. Please find below a few tweaks. Otherwise
it looks good. It starts clean and that is all I have tested.
--- Makefile.orig Tue Jan 26 14:56:50 2021
+++ MakefileTue Jan 26 16:28:02 2021
@@ -17,15 +17,19 @@ MAINTAINER =Muhammad Kaisar Arkhan
# GPLv3
PERMIT_PACKAGE = Yes
-WANTLIB += ${COMPILER_LIBCXX} EGL GL Qt5Core Qt5Gui Qt5Network
-WANTLIB += Qt5Widgets X11 c crypto drm m ssl
-WANTLIB += SDL2 SDL2_ttf avcodec avutil opus
-WANTLIB += Qt5Qml Qt5QmlModels Qt5Quick Qt5QuickControls2 Qt5Svg
+WANTLIB += ${COMPILER_LIBCXX} EGL GL Qt5Core Qt5Gui Qt5Network
+WANTLIB += Qt5Qml Qt5QmlModels Qt5Quick Qt5QuickControls2 Qt5Svg
+WANTLIB += Qt5Widgets SDL2 SDL2_ttf X11 avcodec avutil c crypto
+WANTLIB += drm m opus ssl
MODULES = devel/qmake \
x11/qt5
-RUN_DEPENDS = graphics/ffmpeg \
+RUN_DEPENDS = x11/gtk+3,-guic \
+ devel/desktop-file-utils
+
+
+LIB_DEPENDS = graphics/ffmpeg \
devel/sdl2 \
devel/sdl2-ttf \
audio/opus \
Re: [patch] UPDATE: converters/libiconv: pledge iconv binary
January 26, 2021 3:44 PM, "Hiltjo Posthuma" wrote:
> On Sat, Jan 16, 2021 at 04:29:27PM +0100, Hiltjo Posthuma wrote:
>
>> On Mon, Jan 11, 2021 at 07:50:55PM +0100, Hiltjo Posthuma wrote:
>> Hi,
>>
>> The below patch pledges the iconv binary in the libiconv package. The tool is
>> useful for converting text-encoding of text data to UTF-8 for example.
>>
>> It now uses pledge("stdio", NULL) if only using stdin/stdout. It uses
>> pledge("stdio rpath", NULL) when specifying files.
>>
>> I've tested many command-line option combinations and haven't found missing
>> promises which cause an abort().
>>
>> Patch:
>>
>> From f3b6b4de0a010bd7e9725eeaceddb33a61953a72 Mon Sep 17 00:00:00 2001
>> From: Hiltjo Posthuma
>> Date: Mon, 11 Jan 2021 19:39:31 +0100
>> Subject: [PATCH] libiconv: pledge iconv(1) binary
>>
>> ---
>> converters/libiconv/Makefile | 3 ++-
>> converters/libiconv/patches/patch-src_iconv_c | 22 +++
>> 2 files changed, 24 insertions(+), 1 deletion(-)
>> create mode 100644 converters/libiconv/patches/patch-src_iconv_c
>>
>> diff --git a/converters/libiconv/Makefile b/converters/libiconv/Makefile
>> index 2ab58ea4519..5c8043270de 100644
>> --- a/converters/libiconv/Makefile
>> +++ b/converters/libiconv/Makefile
>> @@ -5,7 +5,7 @@ COMMENT= character set conversion library
>> DISTNAME= libiconv-1.16
>> CATEGORIES= converters devel
>> MASTER_SITES= ${MASTER_SITE_GNU:=libiconv/}
>> -REVISION= 0
>> +REVISION= 1
>>
>> SHARED_LIBS= charset 1.1 \
>> iconv 7.0
>> @@ -17,6 +17,7 @@ MAINTAINER= Brad Smith
>> # LGPLv2 and GPLv3
>> PERMIT_PACKAGE= Yes
>>
>> +# uses pledge()
>> WANTLIB= c
>>
>> SEPARATE_BUILD= Yes
>> diff --git a/converters/libiconv/patches/patch-src_iconv_c
>> b/converters/libiconv/patches/patch-src_iconv_c
>> new file mode 100644
>> index 000..2f3eaac346d
>> --- /dev/null
>> +++ b/converters/libiconv/patches/patch-src_iconv_c
>> @@ -0,0 +1,22 @@
>> +--- src/iconv.c.orig Mon Jan 11 19:28:35 2021
>> src/iconv.c Mon Jan 11 19:31:36 2021
>> +@@ -19,6 +19,9 @@
>> + # define ICONV_CONST
>> + #endif
>> +
>> ++#include
>> ++#include
>> ++
>> + #include
>> + #include
>> + #include
>> +@@ -846,6 +849,9 @@
>> + struct iconv_hooks hooks;
>> + int i;
>> + int status;
>> ++
>> ++ if (pledge(i == argc ? "stdio" : "stdio rpath", NULL) == -1)
Wouldn't you use i uninitialised here?
>> ++ err(1, "pledge");
>> +
>> + set_program_name (argv[0]);
>> + #if HAVE_SETLOCALE
>> --
>> 2.30.0
>>
>> Any thoughts/OKs for the above patch?
>>
>> I use it to convert the text-encoding of some RSS/Atom feeds which are
>> non-UTF-8 to UTF-8.
>>
>> With this patch it completes pledge(2)'ing my entire software bundle to
>> handle
>> RSS/Atom feeds.
>>
>> In a nutshell: ftp someurl | iconv -f encoding -t utf-8 | myprogram
>
> Bump, any OKs or comments?
>
> --
> Kind regards,
> Hiltjo
Re: Qt4 on diet or to hell
On Tue, Jan 26, 2021 at 03:29:52PM +0100, Charlene Wendling wrote: > On Tue, 26 Jan 2021 13:01:05 + > Stuart Henderson wrote: > > > On 2021/01/26 10:42, Antoine Jacoutot wrote: > > > I'd say put it on a diet > > > > +1 > > > > > and let's cross fingers that it's ported to Qt5. > > > > or Qt6 by the time it happens ;) > > > > they are working on it, gradually. > > > > The diet is the best compromise, it should save some time on the > macppc bulk cluster nonetheless, which is great :) Nothing to add from me other than that diet seems the most reasonable approach, so +1. >
Re: [patch] UPDATE: converters/libiconv: pledge iconv binary
On Sat, Jan 16, 2021 at 04:29:27PM +0100, Hiltjo Posthuma wrote:
> On Mon, Jan 11, 2021 at 07:50:55PM +0100, Hiltjo Posthuma wrote:
> > Hi,
> >
> > The below patch pledges the iconv binary in the libiconv package. The tool
> > is
> > useful for converting text-encoding of text data to UTF-8 for example.
> >
> > It now uses pledge("stdio", NULL) if only using stdin/stdout. It uses
> > pledge("stdio rpath", NULL) when specifying files.
> >
> > I've tested many command-line option combinations and haven't found missing
> > promises which cause an abort().
> >
> > Patch:
> >
> >
> > From f3b6b4de0a010bd7e9725eeaceddb33a61953a72 Mon Sep 17 00:00:00 2001
> > From: Hiltjo Posthuma
> > Date: Mon, 11 Jan 2021 19:39:31 +0100
> > Subject: [PATCH] libiconv: pledge iconv(1) binary
> >
> > ---
> > converters/libiconv/Makefile | 3 ++-
> > converters/libiconv/patches/patch-src_iconv_c | 22 +++
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> > create mode 100644 converters/libiconv/patches/patch-src_iconv_c
> >
> > diff --git a/converters/libiconv/Makefile b/converters/libiconv/Makefile
> > index 2ab58ea4519..5c8043270de 100644
> > --- a/converters/libiconv/Makefile
> > +++ b/converters/libiconv/Makefile
> > @@ -5,7 +5,7 @@ COMMENT=character set conversion library
> > DISTNAME= libiconv-1.16
> > CATEGORIES=converters devel
> > MASTER_SITES= ${MASTER_SITE_GNU:=libiconv/}
> > -REVISION= 0
> > +REVISION= 1
> >
> > SHARED_LIBS= charset 1.1 \
> > iconv 7.0
> > @@ -17,6 +17,7 @@ MAINTAINER= Brad Smith
> > # LGPLv2 and GPLv3
> > PERMIT_PACKAGE=Yes
> >
> > +# uses pledge()
> > WANTLIB= c
> >
> > SEPARATE_BUILD=Yes
> > diff --git a/converters/libiconv/patches/patch-src_iconv_c
> > b/converters/libiconv/patches/patch-src_iconv_c
> > new file mode 100644
> > index 000..2f3eaac346d
> > --- /dev/null
> > +++ b/converters/libiconv/patches/patch-src_iconv_c
> > @@ -0,0 +1,22 @@
> > +--- src/iconv.c.orig Mon Jan 11 19:28:35 2021
> > src/iconv.cMon Jan 11 19:31:36 2021
> > +@@ -19,6 +19,9 @@
> > + # define ICONV_CONST
> > + #endif
> > +
> > ++#include
> > ++#include
> > ++
> > + #include
> > + #include
> > + #include
> > +@@ -846,6 +849,9 @@
> > + struct iconv_hooks hooks;
> > + int i;
> > + int status;
> > ++
> > ++ if (pledge(i == argc ? "stdio" : "stdio rpath", NULL) == -1)
> > ++err(1, "pledge");
> > +
> > + set_program_name (argv[0]);
> > + #if HAVE_SETLOCALE
> > --
> > 2.30.0
> >
>
> Any thoughts/OKs for the above patch?
>
> I use it to convert the text-encoding of some RSS/Atom feeds which are
> non-UTF-8 to UTF-8.
>
> With this patch it completes pledge(2)'ing my entire software bundle to handle
> RSS/Atom feeds.
>
> In a nutshell: ftp someurl | iconv -f encoding -t utf-8 | myprogram
>
Bump, any OKs or comments?
--
Kind regards,
Hiltjo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 07:34:47 Modified files: lang/php/pecl : pecl.port.mk Log message: set MODPHP_BUILDDEP for pecl ports
Re: Qt4 on diet or to hell
On Tue, 26 Jan 2021 13:01:05 + Stuart Henderson wrote: > On 2021/01/26 10:42, Antoine Jacoutot wrote: > > I'd say put it on a diet > > +1 > > > and let's cross fingers that it's ported to Qt5. > > or Qt6 by the time it happens ;) > > they are working on it, gradually. > The diet is the best compromise, it should save some time on the macppc bulk cluster nonetheless, which is great :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 06:51:15 Modified files: devel/p5-Test-Trap: Makefile distinfo devel/p5-Test-Trap/pkg: DESCR Log message: update to p5-Test-Trap-0.3.4, from wen heping
Re: [NEW] graphics/openvdb
On 2021/01/03 10:34, Rafael Sadowski wrote: > > > OpenVDB is an Academy Award-winning open-source C++ library comprising a > > > novel .. > > > Build, run tested with blender. > > > No regression tests available. > > > > > > Any comments,OK's? > > > > Port-wise it looks good to me. If someone wants to import, ok rsadowski@ Done.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 06:44:27 Modified files: graphics : Makefile Log message: +openvdb
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 06:44:04 Log message: import ports/graphics/openvdb, from deserter666 at danwin1210.me, ok rsadowski OpenVDB is an Academy Award-winning open-source C++ library comprising a novel hierarchical data structure and a suite of tools for the efficient storage and manipulation of sparse volumetric data discretized on three-dimensional grids. It was developed by DreamWorks Animation for use in volumetric applications typically encountered in feature film production and is now maintained by the Academy Software Foundation (ASWF). Status: Vendor Tag: sthen Release Tags: sthen_20210126 N ports/graphics/openvdb/Makefile N ports/graphics/openvdb/distinfo N ports/graphics/openvdb/pkg/DESCR N ports/graphics/openvdb/pkg/PLIST N ports/graphics/openvdb/patches/patch-CMakeLists_txt No conflicts created by this import
Re: [NEW] graphics/alembic
On 2021/01/26 08:58, Dimitri Karamazov wrote: > Ping .. > > > > Comment: > > > > open framework for storing and sharing scene data > > > > > > > > Description: > > > > Alembic is an open computer graphics interchange framework. It distills > > > > complex, animated scenes into a non-procedural, application-independent > > > > set of baked geometric results. This "distillation" of scenes into baked > > > > geometry is exactly analogous to the distillation of lighting and > > > > rendering scenes into rendered image data. > > > > > > > > Alembic is focused on efficiently storing the computed results of > > > > complex > > > > procedural geometric constructions. It is very specifically NOT > > > > concerned > > > > with storing the complex dependency graph of procedural tools used to > > > > create the computed results. .. > > Broken tarball? OK sthen to import. I've reattached the tarball for ease of finding. alembic.tar.gz Description: Binary data
Re: [update] deve/py-llvmlite to 0.34.0
On 2021/01/26 08:18, Aisha Tammy wrote: > bumpity bump bump > > > On 1/17/21 12:04 PM, Aisha Tammy wrote: > > Another bump? > > > > Aisha > > > > On 11/29/20 11:48 AM, Aisha Tammy wrote: > >> bump? > >> > >> both packages are building fine, llvmlite is working locally. > >> I don't use py-miasm but as mentioned in my previous email, tests > >> did work after install. > >> > >> Unfortunately, I am not going to be able to help clean up the patches > >> as I am busy with schoolwork but wanted to give a reminder nonetheless. > >> > >> Best, > >> Aisha > > > Please reinclude the diff/tar with bumps.
Re: [NEW] games/moonlight-qt
On 1/26/21 2:15 PM, Muhammad Kaisar Arkhan wrote: From there, you can simply launch the sunshine.exe file. Since it appears that sunshine lacks the capability to advertise to GameStream clients (like Moonlight), you have to add your PC manually via the IP address. When you try to connect for the first time, it will ask you to enter a pin. Since sunshine doesn't have any GUI/TUI at all, on the same Windows PC, you need to go to http://127.0.0.1/pin/ to accept the pairing request. After that, you should be able to connect! I made a bit of a typo, you should go to http://127.0.0.1:47989/pin/pin number> since Sunshine HTTP server listens on port 47989, not port 80. -- Muhammad Kaisar Arkhan h...@yukiisbo.red - kai...@arkhan.io https://yukiisbo.red - https://arkhan.io
Re: [NEW] graphics/opensubdiv
On 2021/01/26 08:54, Dimitri Karamazov wrote: > Ping > > On Sun, Jan 10, 2021 at 07:20:09PM +0100, Rafael Sadowski wrote: > > On Sat Jan 09, 2021 at 07:15:36PM +, Dimitri Karamazov wrote: > > > Ping > > > > Port-wise it looks good to me. If someone wants to import this, > > ok rsadowski@ > > Imported.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 06:17:14 Modified files: graphics : Makefile Log message: +opensubdiv
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 06:16:47 Log message: import graphics/opensubdiv, from deserter666 at danwin1210.me, ok rsadowski OpenSubdiv is a set of open source libraries that implement high performance subdivision surface (subdiv) evaluation on massively parallel CPU and GPU architectures. This codepath is optimized for drawing deforming subdivs with static topology at interactive framerates. The resulting limit surface matches Pixar's Renderman to numerical precision. Status: Vendor Tag: sthen Release Tags: sthen_20210126 N ports/graphics/opensubdiv/Makefile N ports/graphics/opensubdiv/distinfo N ports/graphics/opensubdiv/patches/patch-cmake_FindGLFW_cmake N ports/graphics/opensubdiv/pkg/DESCR N ports/graphics/opensubdiv/pkg/PLIST No conflicts created by this import
[NEW] games/moonlight-qt
Hello ports@, Moonlight (formerly Limelight) is an open source implementation of NVIDIA's GameStream protocol. With Moonlight, You can stream your collection of PC games from your GameStream-compatible PC to any supported device and play them remotely. In order to properly test this port, a PC running Windows with an NVIDIA GPU (that's capable of running GameStream) is required. You need to install more proprietary bloatware^W^W^WNVIDIA GeForce Experience and setup NVIDIA GameStream. More info on that can be found here: https://www.nvidia.com/en-us/support/gamestream/gamestream-pc-setup/. If you don't have an NVIDIA GPU like I do, you can use Sunshine[1] which is an NVIDIA GameStream server reimplementation. You can download the pre-built binaries from the GitHub tags/releases page and download the zip file. From there, you can simply launch the sunshine.exe file. Since it appears that sunshine lacks the capability to advertise to GameStream clients (like Moonlight), you have to add your PC manually via the IP address. When you try to connect for the first time, it will ask you to enter a pin. Since sunshine doesn't have any GUI/TUI at all, on the same Windows PC, you need to go to http://127.0.0.1/pin/ to accept the pairing request. After that, you should be able to connect! From my experience using this port and sunshine, it works fine and it's a bit sluggish but I'm not sure if that's caused by sunshine not supporting hardware encoding or the lack of hardware decoding on OpenBSD but it's much more usable in comparison to using Parsec/Rainway within chromium since it works entirely in your local network. OK? [1]: https://github.com/loki-47-6F-64/sunshine -- Muhammad Kaisar Arkhan h...@yukiisbo.red - kai...@arkhan.io https://yukiisbo.red - https://arkhan.io moonlight-qt-3.0.0.tgz Description: Binary data
[UPDATE] net/i2pd
On Mon, Jan 18, 2021 at 07:55:23PM +0100, Mikal Villa wrote:
> Hi,
>
> Yea sure do that :)
>
> /Mikal
>
> > On 18 Jan 2021, at 18:25, Dimitri Karamazov
> > wrote:
> >
> > Hey,
> > I intend to use i2pd and keep it updated. I already
> > maintain the i2p java port.
> > https://openports.se/net/i2p
> >
> > Since I'll be actually using it on an openbsd machine is
> > it okay with you if I take MAINTAINER for i2pd?
> >
> > regards,
> > Dimitri
>
Update i2pd to 2.35.0.
Also taking MAINTAINER after an off the list discussion with Mikal Villa.
Build & Run tested on amd64.
2 out of the 7 tests need some more work.
Index: Makefile
===
RCS file: /cvs/ports/net/i2pd/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile28 May 2020 20:57:30 - 1.2
+++ Makefile25 Jan 2021 07:24:09 -
@@ -4,12 +4,12 @@ COMMENT = client for the I2P anonymous n
GH_ACCOUNT = PurpleI2P
GH_PROJECT = i2pd
-GH_TAGNAME = 2.31.0
+GH_TAGNAME = 2.35.0
CATEGORIES = net
HOMEPAGE = https://i2pd.website
-MAINTAINER = Mikal Villa
+MAINTAINER = Dimitri Karamazov
# BSD
PERMIT_PACKAGE = Yes
@@ -28,15 +28,14 @@ USE_GMAKE = Yes
WRKSRC = ${WRKDIST}/build
post-install:
- ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/i2pd/certificates/family
- ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/i2pd/certificates/reseed
- ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/i2pd/certificates/router
- ${INSTALL_DATA} ${WRKDIST}/contrib/certificates/family/* \
- ${PREFIX}/share/examples/i2pd/certificates/family
- ${INSTALL_DATA} ${WRKDIST}/contrib/certificates/reseed/* \
- ${PREFIX}/share/examples/i2pd/certificates/reseed
- ${INSTALL_DATA} ${WRKDIST}/contrib/certificates/router/* \
- ${PREFIX}/share/examples/i2pd/certificates/router
+ ${INSTALL_DATA_DIR} ${PREFIX}/include/i2pd
+ ${INSTALL_DATA} ${WRKDIST}/libi2pd{,_client}/*.h \
+${PREFIX}/include/i2pd
+.for dir in family reseed router
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/i2pd/certificates/${dir}
+ ${INSTALL_DATA} ${WRKDIST}/contrib/certificates/${dir}/* \
+ ${PREFIX}/share/examples/i2pd/certificates/${dir}
+.endfor
${INSTALL_DATA} ${WRKDIST}/contrib/i2pd.conf \
${PREFIX}/share/examples/i2pd/i2pd.conf
${INSTALL_DATA} ${WRKDIST}/contrib/tunnels.conf \
@@ -44,6 +43,6 @@ post-install:
do-test:
cd ${WRKDIST}/tests && ${MAKE_PROGRAM} CXX="${CXX}" \
- INCFLAGS="-L${LOCALBASE}/lib -I${LOCALBASE}/include"
+ INCFLAGS="-L${LOCALBASE}/lib -I${LOCALBASE}/include ${CFLAGS}"
.include
Index: distinfo
===
RCS file: /cvs/ports/net/i2pd/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo28 May 2020 20:57:30 - 1.2
+++ distinfo25 Jan 2021 07:24:09 -
@@ -1,2 +1,2 @@
-SHA256 (i2pd-2.31.0.tar.gz) = fjerz0np9Z72k5Bp9NdPxr8psJ3uwRG9NWECH8E0lSg=
-SIZE (i2pd-2.31.0.tar.gz) = 1092238
+SHA256 (i2pd-2.35.0.tar.gz) = 0EH9TnqIrBaOdvZv2rQBdK0JPNwTRRzb0N0SFuVYH4o=
+SIZE (i2pd-2.35.0.tar.gz) = 1105837
Index: patches/patch-build_CMakeLists_txt
===
RCS file: patches/patch-build_CMakeLists_txt
diff -N patches/patch-build_CMakeLists_txt
--- patches/patch-build_CMakeLists_txt 28 May 2020 20:57:30 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,43 +0,0 @@
-$OpenBSD: patch-build_CMakeLists_txt,v 1.2 2020/05/28 20:57:30 solene Exp $
-
-Index: build/CMakeLists.txt
build/CMakeLists.txt.orig
-+++ build/CMakeLists.txt
-@@ -456,7 +456,7 @@ if (WITH_BINARY)
- target_link_libraries(libi2pd ${Boost_LIBRARIES} ${ZLIB_LIBRARY})
- target_link_libraries( "${PROJECT_NAME}" libi2pd libi2pdclient ${DL_LIB}
${Boost_LIBRARIES} ${OPENSSL_LIBRARIES} ${ZLIB_LIBRARY}
${CMAKE_THREAD_LIBS_INIT} ${MINGW_EXTRA} ${DL_LIB} ${CMAKE_REQUIRED_LIBRARIES})
-
-- install(TARGETS "${PROJECT_NAME}" RUNTIME DESTINATION
${CMAKE_INSTALL_BINDIR} COMPONENT Runtime)
-+ install(TARGETS "${PROJECT_NAME}" RUNTIME DESTINATION
${CMAKE_INSTALL_SBINDIR} COMPONENT Runtime)
- set (APPS
"\${CMAKE_INSTALL_PREFIX}/bin/${PROJECT_NAME}${CMAKE_EXECUTABLE_SUFFIX}")
- set (DIRS
"${Boost_LIBRARY_DIR};${OPENSSL_INCLUDE_DIR}/../bin;${ZLIB_INCLUDE_DIR}/../bin;/mingw32/bin")
- if (MSVC)
-@@ -470,7 +470,7 @@ if (WITH_BINARY)
- endif ()
-
- install(FILES ../LICENSE
-- DESTINATION .
-+ DESTINATION share/doc/i2pd
- COMPONENT Runtime
- )
- # Take a copy on Appveyor
-@@ -481,8 +481,8 @@ install(FILES "C:/projects/openssl-$ENV{OPENSSL}/LICEN
- OPTIONAL # for local builds only!
- )
-
--file(GLOB_RECURSE I2PD_SOURCES "../libi2pd/*.cpp" "../libi2pd_client/*.cpp"
"../daemon/*.cpp" "../build" "../Win32" "../Makefile*")
Re: [NEW] graphics/opensubdiv
Ping On Sun, Jan 10, 2021 at 07:20:09PM +0100, Rafael Sadowski wrote: > On Sat Jan 09, 2021 at 07:15:36PM +, Dimitri Karamazov wrote: > > Ping > > Port-wise it looks good to me. If someone wants to import this, > ok rsadowski@ > opensubdiv.tar.gz Description: Binary data
Re: [NEW] graphics/alembic
Ping On Sun, Jan 03, 2021 at 11:02:56AM +0100, Rafael Sadowski wrote: > On Sun Jan 03, 2021 at 07:48:24AM +, Dimitri Karamazov wrote: > > Ping > > > > On Sun, Dec 13, 2020 at 03:51:14AM +, Dimitri Karamazov wrote: > > > Information for inst:alembic-1.7.16 > > > > > > Comment: > > > open framework for storing and sharing scene data > > > > > > Description: > > > Alembic is an open computer graphics interchange framework. It distills > > > complex, animated scenes into a non-procedural, application-independent > > > set of baked geometric results. This "distillation" of scenes into baked > > > geometry is exactly analogous to the distillation of lighting and > > > rendering scenes into rendered image data. > > > > > > Alembic is focused on efficiently storing the computed results of complex > > > procedural geometric constructions. It is very specifically NOT concerned > > > with storing the complex dependency graph of procedural tools used to > > > create the computed results. > > > > > > Maintainer: Dimitri Karamazov > > > > > > WWW: https://www.alembic.io/ > > > > > > Build, run tested with blender. > > > All regression tests pass. > > > > > > Any comments,OK's? > > > > > > Broken tarball? alembic.tar.gz Description: Binary data
Re: [NEW] graphics/openvdb
Ping On Thu, Jan 14, 2021 at 03:57:25PM +, Dimitri Karamazov wrote: > Ping > > On Sat, Jan 09, 2021 at 07:18:54PM +, Dimitri Karamazov wrote: > > Ping > > > > On Sun, Jan 03, 2021 at 10:34:50AM +0100, Rafael Sadowski wrote: > > > On Sun Jan 03, 2021 at 07:47:29AM +, Dimitri Karamazov wrote: > > > > Ping > > > > > > > > On Thu, Dec 10, 2020 at 02:16:37PM +, Dimitri Karamazov wrote: > > > > > Information for inst:openvdb-7.1.0 > > > > > > > > > > Comment: > > > > > tools for storage and manipulation of volumetric data > > > > > > > > > > OpenVDB is an Academy Award-winning open-source C++ library > > > > > comprising a novel > > > > > hierarchical data structure and a suite of tools for the efficient > > > > > storage and > > > > > manipulation of sparse volumetric data discretized on > > > > > three-dimensional grids. > > > > > It was developed by DreamWorks Animation for use in volumetric > > > > > applications > > > > > typically encountered in feature film production and is now > > > > > maintained by the > > > > > Academy Software Foundation (ASWF). > > > > > > > > > > Maintainer: Dimitri Karamazov > > > > > > > > > > WWW: https://www.openvdb.org/ > > > > > > > > > > Build, run tested with blender. > > > > > No regression tests available. > > > > > > > > > > Any comments,OK's? > > > > > > > > > > Port-wise it looks good to me. If someone wants to import, ok rsadowski@ > > openvdb.tar.gz Description: Binary data
Re: Qt4 on diet or to hell
On 2021/01/26 10:42, Antoine Jacoutot wrote: > I'd say put it on a diet +1 > and let's cross fingers that it's ported to Qt5. or Qt6 by the time it happens ;) they are working on it, gradually.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/26 05:45:46 Modified files: devel/ccache : Makefile Log message: ccache: building the manual requires asciidoc; reported by aja@, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 04:47:09 Modified files: productivity/kmymoney: Makefile Log message: Regen WANTLIB
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 04:46:33 Modified files: editors/calligra: Makefile Log message: Regen WANTLIB
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2021/01/26 04:44:08 Modified files: graphics/kdiagram: Makefile distinfo graphics/kdiagram/pkg: PLIST Log message: Update kdiagram to 2.8.0
Re: PostgreSQL 13.1 Upgrade
On Tue, Jan 26, 2021 at 09:20:55AM +0100, Pierre-Emmanuel André wrote:
> On Mon, Jan 25, 2021 at 08:43:26PM -0500, Daniel Jakots wrote:
> > On Fri, 20 Nov 2020 17:06:13 -0800, Jeremy Evans
> > wrote:
> >
> > > Could we please have this tested in a bulk? Assuming there are no
> > > problems in a bulk, OKs?
> >
> > Thanks for the diff!
> > I updated my server to it. It works fine for me.
> >
> > There is:
> > /usr/ports/databases/postgresql$ make port-lib-depends-check
> >
> > postgresql-client-13.1(databases/postgresql,-main):
> > Extra: iconv.7 lzma.2
> >
> > postgresql-server-13.1(databases/postgresql,-server):
> > Extra: iconv.7 lzma.2
> >
> > postgresql-contrib-13.1(databases/postgresql,-contrib):
> > Extra: iconv.7 lzma.2
> >
> > postgresql-pg_upgrade-13.1(databases/postgresql,-pg_upgrade):
> > Extra: iconv.7 lzma.2
> >
> > postgresql-plpython-13.1(databases/postgresql,-plpython):
> > Missing: intl.7 from gettext-runtime-0.21p0
> > (/usr/local/lib/postgresql/plpython2.so) WANTLIB += intl
> > *** Error 1 in target 'port-lib-depends-check' (ignored)
> >
> >
> > I haven't checked if the current 12.5 does the same or not, and I'm too
> > lazy to move my ports tree back to it to check (when do we switch to
> > got(1)?? :P).
> >
> >
> > Also it seems the current maintainer is very busy/unresponsive so
> > maybe it would make sense if you took maintainership?
> >
> >
> > Cheers,
> > Daniel
>
>
>
> Hello,
>
> Sorry for the late answer. It took me a long time to upgrade my biggest
> system to pg13.
> The diff looks good for me but i have some random failures on regress tests.
> Sometimes on regproc or another times on prepared_xacts.
> You never saw that ?
>
Nevermind it was a local issue.
I made this small change to database/postgresql/Makefile to fix WANTLIB:
@@ -99,7 +98,7 @@ INSTALL_TARGET= install-world
LIB_DEPENDS-main= archivers/xz \
converters/libiconv \
textproc/libxml
-WANTLIB-main = ${WANTLIB} iconv lzma xml2
+WANTLIB-main = ${WANTLIB} xml2
LIB_DEPENDS-server= databases/postgresql=${VERSION} \
@@ -119,7 +118,7 @@ LIB_DEPENDS-pg_upgrade= databases/postgr
WANTLIB-pg_upgrade = ${WANTLIB-main} pq
LIB_DEPENDS-plpython= ${MODPY_LIB_DEPENDS}
-WANTLIB-plpython = c m pthread util \
+WANTLIB-plpython = c intl m pthread util \
${MODPY_WANTLIB}
RUN_DEPENDS-plpython= databases/postgresql,-server=${VERSION}
Re: Qt4 on diet or to hell
On Tue, Jan 26, 2021 at 10:31:43AM +0100, Marc Espie wrote: > On Tue, Jan 26, 2021 at 09:45:50AM +0100, Rafael Sadowski wrote: > > Hi Qt4 lovers, > > > > qucs-s in the only Qt4 consumer left in our CVS tree. I have spoken with > > the maintainer and he told me that the port is actively used (not only > > from him). It looks like cad/qucs-s is the only functional GUI for > > SPICE-like simulators on OpenBSD. > > > > To be honest Qt4 applications are looking a little bit broken. > > > > Alessandro De Laurenzis has described this here: > > https://marc.info/?l=openbsd-ports=160733053308591=2 > > you know my stance: killing an app that's in use is bad. I'd say put it on a diet and let's cross fingers that it's ported to Qt5. -- Antoine
Re: Qt4 on diet or to hell
On Tue, Jan 26, 2021 at 09:45:50AM +0100, Rafael Sadowski wrote: > Hi Qt4 lovers, > > qucs-s in the only Qt4 consumer left in our CVS tree. I have spoken with > the maintainer and he told me that the port is actively used (not only > from him). It looks like cad/qucs-s is the only functional GUI for > SPICE-like simulators on OpenBSD. > > To be honest Qt4 applications are looking a little bit broken. > > Alessandro De Laurenzis has described this here: > https://marc.info/?l=openbsd-ports=160733053308591=2 you know my stance: killing an app that's in use is bad.
[Update] devel/p5-Test-Trap : Update to 0.3.4
Hi, ports@:
Here is a patch for devel/p5-Test-Trap:
i) Update to 0.3.4
ii) Remove trailing whitespace
It build well and pass all tests on amd64-current system.
4 ports TEST_DEPENDS on p5-Test-Trap:
security/clusterssh
devel/p5-MooseX-Getopt
devel/p5-Test-Spec
net/p5-NetAddr-MAC
Onlu one test failed, not caused by this patch, other tests passed.
wen
Index: Makefile
===
RCS file: /cvs/ports/devel/p5-Test-Trap/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile3 Jul 2020 21:45:16 - 1.8
+++ Makefile26 Jan 2021 08:27:07 -
@@ -2,9 +2,8 @@
COMMENT= trap exit codes
-DISTNAME = Test-Trap-v0.2.4
+DISTNAME = Test-Trap-v0.3.4
PKGNAME= p5-${DISTNAME:S/v//}
-REVISION = 2
CATEGORIES=devel
Index: distinfo
===
RCS file: /cvs/ports/devel/p5-Test-Trap/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo14 Apr 2014 14:29:22 - 1.2
+++ distinfo26 Jan 2021 08:27:07 -
@@ -1,2 +1,2 @@
-SHA256 (Test-Trap-v0.2.4.tar.gz) = nsGCKbvpGPQkeG/kveV/N0NZ3ZiNJUM7syWz2ZT2fOA=
-SIZE (Test-Trap-v0.2.4.tar.gz) = 48373
+SHA256 (Test-Trap-v0.3.4.tar.gz) = CwRlbzO2yW2o7sTP/lKGFQtOS14pkdOINoaxCRAQWuI=
+SIZE (Test-Trap-v0.3.4.tar.gz) = 55339
Index: pkg/DESCR
===
RCS file: /cvs/ports/devel/p5-Test-Trap/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- pkg/DESCR 4 Jan 2011 10:12:57 - 1.1.1.1
+++ pkg/DESCR 26 Jan 2021 08:27:07 -
@@ -1,4 +1,4 @@
-This module is for use in test scripts: A block eval on steroids,
-configurable and extensible, but by default trapping (Perl) STDOUT,
-STDERR, warnings, exceptions, would-be exit codes, and return values
+This module is for use in test scripts: A block eval on steroids,
+configurable and extensible, but by default trapping (Perl) STDOUT,
+STDERR, warnings, exceptions, would-be exit codes, and return values
from boxed blocks of test code.
Re: PostgreSQL 13.1 Upgrade
On Mon, Jan 25, 2021 at 08:43:26PM -0500, Daniel Jakots wrote: > On Fri, 20 Nov 2020 17:06:13 -0800, Jeremy Evans > wrote: > > > Could we please have this tested in a bulk? Assuming there are no > > problems in a bulk, OKs? > > Thanks for the diff! > I updated my server to it. It works fine for me. > > There is: > /usr/ports/databases/postgresql$ make port-lib-depends-check > > postgresql-client-13.1(databases/postgresql,-main): > Extra: iconv.7 lzma.2 > > postgresql-server-13.1(databases/postgresql,-server): > Extra: iconv.7 lzma.2 > > postgresql-contrib-13.1(databases/postgresql,-contrib): > Extra: iconv.7 lzma.2 > > postgresql-pg_upgrade-13.1(databases/postgresql,-pg_upgrade): > Extra: iconv.7 lzma.2 > > postgresql-plpython-13.1(databases/postgresql,-plpython): > Missing: intl.7 from gettext-runtime-0.21p0 > (/usr/local/lib/postgresql/plpython2.so) WANTLIB += intl > *** Error 1 in target 'port-lib-depends-check' (ignored) > > > I haven't checked if the current 12.5 does the same or not, and I'm too > lazy to move my ports tree back to it to check (when do we switch to > got(1)?? :P). > > > Also it seems the current maintainer is very busy/unresponsive so > maybe it would make sense if you took maintainership? > > > Cheers, > Daniel Hello, Sorry for the late answer. It took me a long time to upgrade my biggest system to pg13. The diff looks good for me but i have some random failures on regress tests. Sometimes on regproc or another times on prepared_xacts. You never saw that ?
questions about alpine
I was reading over austin hook's problems with the alpine email client
that were posted in misc@. I too have been having problems with alpine in
6.8 stable which are new. I have used alpine for many many years and it
just worked fine.
Like austin, I have had lockups and with the program doing things like
composing, to chaining to external programs like a browser to using xv to
display images. The problems are intermittment but never occurred prior
to 6.8. I guess ktrace is in my future?
Couple of questions about alpine:
Question 1
In working through some of my problems I found that the pkg and port are
compiled with debug disabled. Is there a reason for that default
instead of compiling with debuglevel=0 and setting a low number for the
number of debug files to save?
I created an install with debug enabled which allowed me to use various
command line switches to control how much information was being written to
the debug files. This helped show a communication problem with a
particular imap server was not a timeout but rather an SSL
handshake failure that occurs intermittmently. The debug log minus my
email address as logged
IMAP 11:56:18 1/8 mm_log tcp: DNS resolution mail.acsalaska.net
IMAP 11:56:18 1/8 mm_log tcp: DNS resolution done
IMAP 11:56:18 1/8 mm_log babble: Trying IP address [66.226.70.80]
IMAP 11:56:18 1/8 mm_log tcp: Stream open and ready for read
IMAP 11:56:18 1/8 mm_log tcp: Reading SSL data
IMAP 11:56:22 1/8 mm_log tcp: SSL data read I/O error 54 SSL error 5
IMAP 11:56:22 1/8 mm_notify bye:
{mail.acsalaska.net/user=xx...@xx.xxx/ssl/novalidate-cert}inbox:
[CLOSED] IMAP connection broken (server response)
IMAP 11:56:22 1/8 mm_log error: [CLOSED] IMAP connection broken (server
response)
error 54 SSL error 5 is the problem still looking how to fix it or if it
something with that particular server.
Question 2
The version in ports and pkgs is shown as 2.21 with some patches. The
source location is pointed to alpine.x10host.com which is apparently the
"new" home for the program. The current version is shown as version 2.24.
Is there a reason this isn't being used. One of the interesting issues in
this version is trying to address issues connecting to the yahoo imap
server, which for me stopped working a couple of months ago. Debug logs
showed (with the source ip blanked out)
IMAP DEBUG 21:15:06 1/7: OK AUTHENTICATE completed
IMAP DEBUG 21:15:06 1/7: 0001 ID ("name" "alpine" "version" "2.21")
IMAP DEBUG 21:15:06 1/7: * ID ("remote-host" "xxx.xxx.xxx.xxx" "vendor"
"Yahoo! Inc." "support-url" "http://help.yahoo.com/; "name" "Y!IMAP"
"host" "sky300148.imap.mail.yahoo.com" "version" "1.1.16979")
IMAP DEBUG 21:15:06 1/7: 0001 OK ID completed
IMAP DEBUG 21:15:06 1/7: 0002 SELECT INBOX
IMAP DEBUG 21:15:11 1/7: 0002 BAD [CLIENTBUG] SELECT Command is not
valid in this state
IMAP 21:15:11 1/7 mm_log error: IMAP protocol error: [CLIENTBUG] SELECT
Command is not valid in this state
IMAP 21:15:11 1/7 mm_log error: [CLIENTBUG] SELECT Command is not valid in
this state
I have yet to figure out what "Command is not valid in this state" means
I just show these as examples of the debug log that alpine can create if
debug is enabled.
peter
