Re: gcc --static produces programs that crash
This diff in lang/gcc/8 works for me on amd64 and powerpc. I would
like tests on more arches. Is it ok to commit?
This diff makes 4 changes to LINK_SPEC:
1. use "%{!static:-dynamic-linker /usr/libexec/ld.so}" to fix
static linking; you can try the Fortran example below.
2. change %{r*:} to %{r:}; base-gcc uses %{r*:}, but upstream
changed %{r*:} to %{r:} in commit 7aed7df [1].
3. change -L/usr/lib to %{!nostdlib:-L/usr/lib} to be like base-gcc.
4. rewrite powerpc's *_rs6000_openbsd_h to be like other arches,
and add %{!nostdlib:-L/usr/lib} so I can try lld on powerpc.
$ cat works.f90
print *, 'Fortran works.'
end
$ egfortran -o works works.f90 -static
$ ./works
Fortran works.
%{!shared:%{!nostdlib:%{!r:%{!e*:-e __start
means if not "gcc -shared" and not "gcc -nostdlib" and not "gcc -r"
and not "gcc -e something_else", then run "ld -e __start". We don't
need this spec on arches like powerpc, where ld's default entry is
__start, but I added this spec to powerpc to be like other arches.
%{shared:-shared}
means if "gcc -shared" then "ld -shared".
%{R*}
means if "gcc -R/some/dir" then "ld -R /some/dir". This had been
missing on powerpc, where "gcc -R/some/dir" got ignored.
%{static:-Bstatic}
means if "gcc -static" then "ld -Bstatic". We need this to tell ld
to avoid shared libs when linking static bins. powerpc was using
"ld -static", but I changed it to -Bstatic to be like other arches.
%{!static:-Bdynamic}
might not be needed, but I kept it and added it to powerpc.
%{rdynamic:-export-dynamic}
was added by our patches, and I kept it.
%{assert*}
is useless. The intent is "gcc -assert X" => "ld -assert X", but
gcc rejects -assert and uses --assert for Fortran. I didn't delete
the %{assert*} because upstream hadn't deleted it.
%{!static:-dynamic-linker /usr/libexec/ld.so}
fixes static linking. base-gcc uses the longer spec
%{!static:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}}
but there is no such option "gcc -dynamic-linker X"; upstream
deleted %{!dynamic-linker:} in commit e59dabd [2].
%{!nostdlib:-L/usr/lib}
is for lld to search /usr/lib. There is a bug, for which I don't
know the fix: this spec passes -L/usr/lib too early, so the search
order is /usr/lib before anything else, and you can't tell gcc to
use your own libcurses.a instead of the one in /usr/lib [3].
[1]
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7aed7dfc45e81230bd4fa01c16b55c0904b49535
[2]
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e59dabd237f24b87814a3664e2f092c2b107facf
[3] https://marc.info/?l=openbsd-bugs&m=156547894114050&w=2
Index: Makefile
===
RCS file: /cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.36
diff -u -p -r1.36 Makefile
--- Makefile14 Nov 2020 00:00:39 - 1.36
+++ Makefile2 Dec 2020 04:27:15 -
@@ -18,7 +18,7 @@ DPB_PROPERTIES = parallel
V = 8.4.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
-REVISION = 1
+REVISION = 2
ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
Index: patches/patch-gcc_config_aarch64_openbsd_h
===
RCS file: /cvs/ports/lang/gcc/8/patches/patch-gcc_config_aarch64_openbsd_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-gcc_config_aarch64_openbsd_h
--- patches/patch-gcc_config_aarch64_openbsd_h 20 May 2019 14:59:05 -
1.2
+++ patches/patch-gcc_config_aarch64_openbsd_h 2 Dec 2020 04:27:15 -
@@ -51,14 +51,14 @@ Index: gcc/config/aarch64/openbsd.h
+#define SUBTARGET_CPP_SPEC OBSD_CPP_SPEC
+
+#define LINK_SPEC \
-+ "%{!shared:%{!nostdlib:%{!r*:%{!e*:-e __start \
++ "%{!shared:%{!nostdlib:%{!r:%{!e*:-e __start \
+ %{shared:-shared} %{R*} \
+ %{static:-Bstatic} \
+ %{!static:-Bdynamic} \
+ %{rdynamic:-export-dynamic} \
+ %{assert*} \
-+ %{!shared:%{!dynamic-linker:-dynamic-linker /usr/libexec/ld.so}} \
-+ -L/usr/lib"
++ %{!static:-dynamic-linker /usr/libexec/ld.so} \
++ %{!nostdlib:-L/usr/lib}"
+
+#define OPENBSD_ENTRY_POINT "__start"
+
Index: patches/patch-gcc_config_alpha_openbsd_h
===
RCS file: /cvs/ports/lang/gcc/8/patches/patch-gcc_config_alpha_openbsd_h,v
retrieving revision 1.2
diff -u -p -r1.2 patch-gcc_config_alpha_openbsd_h
--- patches/patch-gcc_config_alpha_openbsd_h20 May 2019 14:59:05 -
1.2
+++ patches/patch-gcc_config_alpha_openbsd_h2 Dec 2020 04:27:15 -
@@ -10,14 +10,14 @@ Index: gcc/config/alpha/openbsd.h
+#define TARGET_DEFAULT \
+ (MASK_FPREGS | MASK_IEEE | MASK_IEEE_CONFORMANT)
+
-+ #define LINK_SPEC \
-+ "%{!shared:%{!nostdlib:%{!r*:%{!e*:-e __start \
++#define LINK_SPEC \
++ "%{!shared:%{!nostdlib:%{!r:%{!e*:-e __start \
+ %{shared:-shared} %{R*} \
+ %{static:-Bstatic} \
+ %{!st
Update net/ddclient to 3.9.1
patch Description: Binary data
[update] intellij and pycharm to 2020.3
Hello,
Apologies for the rapid version turnover :/ I would have just waited
for 2020.3 had I known they'd be right around the corner from 2020.2.4.
The PLISTs have a lot of churn for this version bump, but they've built
and run just fine. Tested by building some projects and running tests
within the applications.
New in these releases are "light" versions of the respective
applications which are more basic code editors. I personally won't use
them, but they're there so let's make them available for use.
intellij release notes:
https://confluence.jetbrains.com/display/IDEADEV/IntelliJ+IDEA+2020.3+(203.5981.155+build)+Release+Notes
intellij What's new: https://www.jetbrains.com/idea/whatsnew/
pycharm release notes:
https://confluence.jetbrains.com/display/PYH/PyCharm+2020.3+Release+Notes
pycharm What's new: https://www.jetbrains.com/pycharm/whatsnew/
Lucas
diff 30636d6b423dce7105604f52f79a3a6493f41f43 /usr/ports
blob - a502a51e1fc81370f28cf6165d1477a770327c1d
file + devel/intellij/Makefile
--- devel/intellij/Makefile
+++ devel/intellij/Makefile
@@ -2,7 +2,7 @@
COMMENT= IntelliJ IDEA Java IDE
-V= 2020.2.4
+V= 2020.3
DISTNAME= ideaIC-${V}
PKGNAME= intellij-${V}
CATEGORIES=devel
@@ -25,7 +25,7 @@ RUN_DEPENDS= devel/desktop-file-utils \
NO_TEST= Yes
-WRKDIST= ${WRKDIR}/idea-IC-202.8194.7
+WRKDIST= ${WRKDIR}/idea-IC-203.5981.155
IJ=${PREFIX}/intellij
# If NO_BUILD is set, JAVA_HOME doesn't get defined. So do
@@ -40,7 +40,11 @@ do-install:
@rm -rf ${IJ}/jbr
@rm -rf ${IJ}/plugins/android
@${SUBST_PROGRAM} ${FILESDIR}/idea ${PREFIX}/bin/idea
+ @${SUBST_PROGRAM} ${FILESDIR}/idea-lightedit \
+ ${PREFIX}/bin/idea-lightedit
@ln -s ${TRUEPREFIX}/bin/idea ${PREFIX}/bin/intellij
+ @ln -s ${TRUEPREFIX}/bin/idea-lightedit \
+ ${PREFIX}/bin/intellij-lightedit
${INSTALL_MAN} ${FILESDIR}/idea.1 ${PREFIX}/man/man1
${INSTALL_DATA_DIR} ${PREFIX}/share/applications
cd ${WRKDIST}/lib && ${JAVA_HOME}/bin/jar xf icons.jar
blob - 9d20300312baa4bf97f04d087681532729306ca7
file + devel/intellij/distinfo
--- devel/intellij/distinfo
+++ devel/intellij/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ideaIC-2020.2.4.tar.gz) = y3+vKwHIdZR8zJDPJDSXMoEBxjwHkUZ2NyQyg1UAnOY=
-SIZE (ideaIC-2020.2.4.tar.gz) = 679072530
+SHA256 (ideaIC-2020.3.tar.gz) = xveLcs97gmGWhWUa6FF8P6+YPcVYxNT0wXGAGrjUNnQ=
+SIZE (ideaIC-2020.3.tar.gz) = 738387806
blob - 26d8c7cc33e1581698b1dfaf92201fa8ee13f127
file + devel/intellij/pkg/PLIST
--- devel/intellij/pkg/PLIST
+++ devel/intellij/pkg/PLIST
@@ -1,6 +1,8 @@
@comment $OpenBSD: PLIST,v 1.46 2020/11/28 08:14:46 rsadowski Exp $
bin/idea
+bin/idea-lightedit
bin/intellij
+bin/intellij-lightedit
intellij/
intellij/Install-Linux-tar.txt
intellij/LICENSE.txt
@@ -19,14 +21,19 @@ intellij/bin/idea.vmoptions
intellij/bin/idea64.vmoptions
intellij/bin/inspect.sh
intellij/bin/log.xml
+intellij/bin/ltedit.sh
intellij/bin/printenv.py
intellij/bin/restart.py
intellij/build.txt
+intellij/icons.db
intellij/idea.png
intellij/lib/
intellij/lib/FastInfoset-1.2.15.jar
intellij/lib/HdrHistogram-2.1.4.jar
+intellij/lib/RoaringBitmap-0.9.0.jar
intellij/lib/aapt2-proto-0.3.1.jar
+intellij/lib/animal-sniffer-annotations-1.18.jar
+intellij/lib/annotations-4.1.1.4.jar
intellij/lib/annotations.jar
intellij/lib/ant/
intellij/lib/ant/CONTRIBUTORS
@@ -91,33 +98,35 @@ intellij/lib/ant/lib/ant.pom
intellij/lib/ant/lib/libraries.properties
intellij/lib/ant/src.zip
intellij/lib/asm-7.1.jar
-intellij/lib/asm-all-8.0.1.jar
+intellij/lib/asm-all-9.0.jar
intellij/lib/asm-analysis-7.1.jar
intellij/lib/asm-commons-7.1.jar
intellij/lib/asm-tree-7.1.jar
intellij/lib/asm-util-7.1.jar
intellij/lib/automaton-1.12-1.jar
intellij/lib/baksmali-2.2.4.jar
-intellij/lib/batik-anim-1.12.0-8.jar
-intellij/lib/batik-awt-util-1.12.0-8.jar
-intellij/lib/batik-bridge-1.12.0-8.jar
-intellij/lib/batik-codec-1.12.0-8.jar
-intellij/lib/batik-constants-1.12.0-8.jar
-intellij/lib/batik-css-1.12.0-8.jar
-intellij/lib/batik-dom-1.12.0-8.jar
-intellij/lib/batik-ext-1.12.0-8.jar
-intellij/lib/batik-gvt-1.12.0-8.jar
-intellij/lib/batik-parser-1.12.0-8.jar
-intellij/lib/batik-svg-dom-1.12.0-8.jar
-intellij/lib/batik-svggen-1.12.0-8.jar
-intellij/lib/batik-transcoder-1.12.0-8.jar
-intellij/lib/batik-util-1.12.0-8.jar
-intellij/lib/batik-xml-1.12.0-8.jar
+intellij/lib/batik-anim-1.13.0-21.jar
+intellij/lib/batik-awt-util-1.13.0-21.jar
+intellij/lib/batik-bridge-1.13.0-21.jar
+intellij/lib/batik-codec-1.13.0-21.jar
+intellij/lib/batik-constants-1.13.0-21.jar
+intellij/lib/batik-css-1.13.0-21.jar
+intellij/lib/batik-dom-1.13.0-21.jar
+intellij/lib/batik-ext-1.13.0-21.jar
+intellij/lib/batik-gvt-1.13.0-21.jar
+intellij/lib/batik-parser-1.13.0-21.jar
+intellij/lib/batik-svg-dom-1.13.0-21.jar
+intellij/li
Re: [New] devel/re2
Stuart Henderson writes: > You mentioned a cmakefile change that would increase it, can you show > that please, some of us only have slow machines like > > cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.17 MHz, 06-3c-03 > > :) Here you go. I've added a patch that increases the timeout, with reference in the Makefile. I've increased it from 1500 seconds to 2000. This seems to help on my slower machine. re2.tgz Description: Binary data
Re: PostgreSQL 13.1 Upgrade
On Wed, Dec 02, 2020 at 01:02:46PM -0800, Jeremy Evans wrote:
> On 12/02 09:39, Christian Weisgerber wrote:
> > Jeremy Evans:
> >
> > > Now that PostgreSQL 13.1 is out, I think we can consider upgrading to
> > > it. The diff below was tested on amd64 on a partial bulk of the ports
> > > depending on PostgreSQL.
> > >
> > > Could we please have this tested in a bulk?
> >
> > I ran this through a bulk build on amd64. Two build failures were
> > attributable to it:
>
> Thank you very much for you testing. I'll try to make sure I catch
> these issues next time.
>
> > ===> databases/postgresql-plr
> > pg_backend_support.c:120:13: error: use of undeclared identifier
> > 'tag_hash'; did
> > you mean 'time_hash'?
> > ctl.hash = tag_hash;
> >^~~~
>
> This is fixed by upgrading from plr 8.4 to 8.4.1.
>
> > ===> databases/timescaledb
> > -- Compiling against PostgreSQL version 13.1
> > -- Configuring incomplete, errors occurred!
> > See also
> > "/usr/obj/ports/timescaledb-1.7.4/build-amd64/CMakeFiles/CMakeOutput.log".
> > CMake Error at CMakeLists.txt:209 (message):
> > TimescaleDB only supports PostgreSQL 9.6.3+, 10.2+, 11 or 12
>
> TimescaleDB's master branch still doesn't support PostgreSQL 13 (they
> also dropped support for <11):
> https://github.com/timescale/timescaledb/blob/master/CMakeLists.txt#L197
>
> There is a work in progress pull request to add support, but it is
> fairly large:
> https://github.com/timescale/timescaledb/pull/2498
>
> I think it's best if we mark TimescaleDB BROKEN, as I don't think it
> should hold back the PostgreSQL upgrade.
>
Fine with me.
> Patch below with both fixes. OKs for committing the PostgreSQL 13
> update?
>
> Thanks,
> Jeremy
>
> Index: databases/timescaledb/Makefile
> ===
> RCS file: /cvs/ports/databases/timescaledb/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- databases/timescaledb/Makefile15 Nov 2020 09:12:13 - 1.1.1.1
> +++ databases/timescaledb/Makefile2 Dec 2020 20:53:33 -
> @@ -1,5 +1,6 @@
> # $OpenBSD: Makefile,v 1.1.1.1 2020/11/15 09:12:13 denis Exp $
>
> +BROKEN = Does not yet support PostgreSQL 13
> COMMENT =database designed to make SQL scalable for time-series data
>
> GH_ACCOUNT = timescale
> Index: databases/postgresql-plr/Makefile
> ===
> RCS file: /cvs/ports/databases/postgresql-plr/Makefile,v
> retrieving revision 1.6
> diff -u -p -r1.6 Makefile
> --- databases/postgresql-plr/Makefile 6 Feb 2020 00:36:58 - 1.6
> +++ databases/postgresql-plr/Makefile 2 Dec 2020 20:46:39 -
> @@ -2,8 +2,8 @@
>
> COMMENT =R procedural language for PostgreSQL
>
> -VERSION =8.4
> -DISTNAME = REL8_4
> +VERSION =8.4.1
> +DISTNAME = REL8_4_1
> PKGNAME =postgresql-plr-${VERSION}
>
> CATEGORIES = databases
> Index: databases/postgresql-plr/distinfo
> ===
> RCS file: /cvs/ports/databases/postgresql-plr/distinfo,v
> retrieving revision 1.3
> diff -u -p -r1.3 distinfo
> --- databases/postgresql-plr/distinfo 6 Feb 2020 00:36:58 - 1.3
> +++ databases/postgresql-plr/distinfo 2 Dec 2020 20:46:44 -
> @@ -1,2 +1,2 @@
> -SHA256 (REL8_4.tar.gz) = v5w4IeY+IDsl8vrlzbdhBBb0q8y8ZSu3jp5oAHE4FjA=
> -SIZE (REL8_4.tar.gz) = 264511
> +SHA256 (REL8_4_1.tar.gz) = 3bbyA3EFtZ+d2mkw1Kme14kJXYll7G8PftW5Y6wCLgc=
> +SIZE (REL8_4_1.tar.gz) = 265142
> Index: databases/postgresql-plr/pkg/PLIST
> ===
> RCS file: /cvs/ports/databases/postgresql-plr/pkg/PLIST,v
> retrieving revision 1.3
> diff -u -p -r1.3 PLIST
> --- databases/postgresql-plr/pkg/PLIST6 Feb 2020 00:36:59 -
> 1.3
> +++ databases/postgresql-plr/pkg/PLIST2 Dec 2020 20:47:56 -
> @@ -1,6 +1,6 @@
> @comment $OpenBSD: PLIST,v 1.3 2020/02/06 00:36:59 jeremy Exp $
> -lib/postgresql/plr.so
> -share/postgresql/extension/plr--8.3.0.18--8.4.sql
> -share/postgresql/extension/plr--8.4.sql
> -share/postgresql/extension/plr--unpackaged--8.4.sql
> +@so lib/postgresql/plr.so
> +share/postgresql/extension/plr--8.4--8.4.1.sql
> +share/postgresql/extension/plr--8.4.1.sql
> +share/postgresql/extension/plr--unpackaged--8.4.1.sql
> share/postgresql/extension/plr.control
Re: PostgreSQL 13.1 Upgrade
On 12/02 09:39, Christian Weisgerber wrote:
> Jeremy Evans:
>
> > Now that PostgreSQL 13.1 is out, I think we can consider upgrading to
> > it. The diff below was tested on amd64 on a partial bulk of the ports
> > depending on PostgreSQL.
> >
> > Could we please have this tested in a bulk?
>
> I ran this through a bulk build on amd64. Two build failures were
> attributable to it:
Thank you very much for you testing. I'll try to make sure I catch
these issues next time.
> ===> databases/postgresql-plr
> pg_backend_support.c:120:13: error: use of undeclared identifier 'tag_hash';
> did
> you mean 'time_hash'?
> ctl.hash = tag_hash;
>^~~~
This is fixed by upgrading from plr 8.4 to 8.4.1.
> ===> databases/timescaledb
> -- Compiling against PostgreSQL version 13.1
> -- Configuring incomplete, errors occurred!
> See also
> "/usr/obj/ports/timescaledb-1.7.4/build-amd64/CMakeFiles/CMakeOutput.log".
> CMake Error at CMakeLists.txt:209 (message):
> TimescaleDB only supports PostgreSQL 9.6.3+, 10.2+, 11 or 12
TimescaleDB's master branch still doesn't support PostgreSQL 13 (they
also dropped support for <11):
https://github.com/timescale/timescaledb/blob/master/CMakeLists.txt#L197
There is a work in progress pull request to add support, but it is
fairly large:
https://github.com/timescale/timescaledb/pull/2498
I think it's best if we mark TimescaleDB BROKEN, as I don't think it
should hold back the PostgreSQL upgrade.
Patch below with both fixes. OKs for committing the PostgreSQL 13
update?
Thanks,
Jeremy
Index: databases/timescaledb/Makefile
===
RCS file: /cvs/ports/databases/timescaledb/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- databases/timescaledb/Makefile 15 Nov 2020 09:12:13 - 1.1.1.1
+++ databases/timescaledb/Makefile 2 Dec 2020 20:53:33 -
@@ -1,5 +1,6 @@
# $OpenBSD: Makefile,v 1.1.1.1 2020/11/15 09:12:13 denis Exp $
+BROKEN = Does not yet support PostgreSQL 13
COMMENT = database designed to make SQL scalable for time-series data
GH_ACCOUNT = timescale
Index: databases/postgresql-plr/Makefile
===
RCS file: /cvs/ports/databases/postgresql-plr/Makefile,v
retrieving revision 1.6
diff -u -p -r1.6 Makefile
--- databases/postgresql-plr/Makefile 6 Feb 2020 00:36:58 - 1.6
+++ databases/postgresql-plr/Makefile 2 Dec 2020 20:46:39 -
@@ -2,8 +2,8 @@
COMMENT = R procedural language for PostgreSQL
-VERSION = 8.4
-DISTNAME = REL8_4
+VERSION = 8.4.1
+DISTNAME = REL8_4_1
PKGNAME = postgresql-plr-${VERSION}
CATEGORIES = databases
Index: databases/postgresql-plr/distinfo
===
RCS file: /cvs/ports/databases/postgresql-plr/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- databases/postgresql-plr/distinfo 6 Feb 2020 00:36:58 - 1.3
+++ databases/postgresql-plr/distinfo 2 Dec 2020 20:46:44 -
@@ -1,2 +1,2 @@
-SHA256 (REL8_4.tar.gz) = v5w4IeY+IDsl8vrlzbdhBBb0q8y8ZSu3jp5oAHE4FjA=
-SIZE (REL8_4.tar.gz) = 264511
+SHA256 (REL8_4_1.tar.gz) = 3bbyA3EFtZ+d2mkw1Kme14kJXYll7G8PftW5Y6wCLgc=
+SIZE (REL8_4_1.tar.gz) = 265142
Index: databases/postgresql-plr/pkg/PLIST
===
RCS file: /cvs/ports/databases/postgresql-plr/pkg/PLIST,v
retrieving revision 1.3
diff -u -p -r1.3 PLIST
--- databases/postgresql-plr/pkg/PLIST 6 Feb 2020 00:36:59 - 1.3
+++ databases/postgresql-plr/pkg/PLIST 2 Dec 2020 20:47:56 -
@@ -1,6 +1,6 @@
@comment $OpenBSD: PLIST,v 1.3 2020/02/06 00:36:59 jeremy Exp $
-lib/postgresql/plr.so
-share/postgresql/extension/plr--8.3.0.18--8.4.sql
-share/postgresql/extension/plr--8.4.sql
-share/postgresql/extension/plr--unpackaged--8.4.sql
+@so lib/postgresql/plr.so
+share/postgresql/extension/plr--8.4--8.4.1.sql
+share/postgresql/extension/plr--8.4.1.sql
+share/postgresql/extension/plr--unpackaged--8.4.1.sql
share/postgresql/extension/plr.control
Re: [NEW] net/td
On 20-12-01 17:45:42, Omar Polo wrote:
Omar Polo writes:
Hello ports@,
$ pkg_info td
Information for inst:td-1.6.9
Comment:
cross-platform library for building Telegram clients
Description:
TDLib (Telegram Database Library) is a cross-platform, fully
functional Telegram client that can be easily used from almost any
programming language.
Maintainer: Omar Polo
WWW: https://github.com/tdlib/td
I've been using this for about a year, initially only as a C++ library
in some test projects of mine, and then in the last two months as a
dependency of telega.el[0], a telegram client for Emacs. I've seen a
recent post on r/OpenBSD so here's the port since it could be useful to
others too.
td provides two set of libraries: some C++ statically-liked only
libraries (libtd{actor,api,client,...}) and a library, td_json.so, that
exposes a JSON api. I'm including both set of libraries, as the C++
libraries can be useful (to me at least), even though I'm expecting the
majority of clients to use the json library only. We can drop the C++
libraries eventually if they aren't considered useful.
The code is released under the boost software license 1.0. Different
ports uses different comments for it, like "Boost", "Boost license",
"boost software license" and even "MIT-like (Boost)". I went with
"Boost SL 1.0", like math/mlpac does.
A note regarding the name: based on a quick look on repology, it seems
that the majority of distro package td as "tdlib" (see td[1] vs
tdlib[2]). I've kept td, as it was the name that I picked first when
making the port, and also because it's the name of the upstream
repository, but we can go with tdlib if we want consistency with others
systems.
A note about the versioning: upstream only tags "major" releases, like
1.6 and 1.7, as they consider "minor" releases (i.e. 1.6.9) development
versions, and thus they only bump the version in their CMakeList.txt for
minor releases. I'm going with 1.6.9 since it seems pointless to me
providing a stable version of a library that cannot be used by its
consumer (telega.el requires 1.6.9, and the other clients mentioned in
the reddit post works with the library built from master). It doesn't
seem a bad idea to me, please correct me if I'm wrong. (also, I'm
providing an explicit DISTNAME since with the auto-generated one from
GH_COMMIT fails to download the tarball)
scratch this, upstream released v1.7.0. I’ve updated the attached
port. Tests are passing, portcheck and port-lib-depends-check are happy.
A final note: upstream provides a script to split the sources to limit
the memory usage when building. I successfully built the library on a
decade old i686 with 2 gigs of ram without hitting the swap (while also
running X), so such workaround doesn't seem to be needed, but I left a
comment in the Makefile anyway just in case. (splitting the sources
will require an additional build-only dep on php.)
Built and tested on amd64, successfully built on i386.
; make test
===> Regression tests for td-1.6.9
[0/1] ...[snip]
Test project /usr/ports/pobj/td-1.6.9/build-amd64
Start 1: run_all_tests
1/1 Test #1: run_all_tests Passed 618.16 sec
100% tests passed, 0 tests failed out of 1
Total Test time (real) = 618.17 sec
OK? Comments?
[0]: https://github.com/zevlg/telega.el
[1]: https://repology.org/project/td/versions
[2]: https://repology.org/project/tdlib/versions
Build and tested on amd64. Runs well with tg[1] until now.
[1]: https://github.com/paul-nameless/tg
Re: PostgreSQL 13.1 Upgrade
Jeremy Evans: > Now that PostgreSQL 13.1 is out, I think we can consider upgrading to > it. The diff below was tested on amd64 on a partial bulk of the ports > depending on PostgreSQL. > > Could we please have this tested in a bulk? I ran this through a bulk build on amd64. Two build failures were attributable to it: ===> databases/postgresql-plr pg_backend_support.c:120:13: error: use of undeclared identifier 'tag_hash'; did you mean 'time_hash'? ctl.hash = tag_hash; ^~~~ ===> databases/timescaledb -- Compiling against PostgreSQL version 13.1 -- Configuring incomplete, errors occurred! See also "/usr/obj/ports/timescaledb-1.7.4/build-amd64/CMakeFiles/CMakeOutput.log". CMake Error at CMakeLists.txt:209 (message): TimescaleDB only supports PostgreSQL 9.6.3+, 10.2+, 11 or 12 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [new] net/kristall (gopher/gemini navigator)
On Fri, 27 Nov 2020, Solene Rapenne wrote: > hi, > > this is a new port for Kristall > https://github.com/MasterQ32/kristall > > A GUI program to navigate into Gemini and Gopher > spaces (or even http). > > I patched a git call which happened at every clang > call which was pretty bad. Builds and works well for me on amd64. Remove the indefinite article at the beginning of COMMENT. Other than that ok paco@ -- Paco Esteban. 0x5818130B8A6DBC03
Re: [NEW] textproc/py-regex
On Sat, 12 Sep 2020, Kurt Mosiejczuk wrote: > On Tue, Sep 08, 2020 at 03:03:29AM +, wen heping wrote: > > Hi, > > >Here is a patch to create new port textproc/py-regex, which is required > > by the update of textproc/py-black. > >It build well, all tests passed but one failed on amd64-current system. > > Here's a version moved to use the current FLAVOR=python3 paradigm and use > MODPY_PYTEST. > > ok to import? builds and tests pass for me (all but one) on amd64. That one errors bugs me a bit, but I guess it's ok. ok paco@ -- Paco Esteban. 0x5818130B8A6DBC03
Re: nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
On Wed, Dec 02, 2020 at 05:34:52PM +, Stuart Henderson wrote:
> I didn't manage to track down a fix but I've set nsca-ng back to using
> openssl/1.0.2 for now, my glasses do not permit looking at BIO_* for
> more than a few moments.
Seems reasonable.
Turns out this is also broken client side where I use a literal hostname in
send_nsca.cfg:
send_nsca: [FATAL] Socket error (xxx.yyy.xyz): Broken pipe
Putting in an ip address fixes things.
>
>
> On 2020/12/02 17:23, Florian Obser wrote:
> > Looks like this thing might be legacy IP only.
> > I work around the problem by adding:
> > listen = "0.0.0.0"
> > to /etc/nsca-ng.cfg
> >
> > Having glanced at the code in src/common/tls.c could this be an
> > openssl update?
> >
> > Don't think I'll have a lot of time digging into this though.
> >
> > On Wed, Dec 02, 2020 at 04:44:27PM +0100, Florian Obser wrote:
> > > After the recent nsca-ng update it no longer starts:
> > >
> > > nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
> > >
> > > My nsca-ng config is fairly simple:
> > >
> > > # cat /etc/nsca-ng.cfg
> > > command_file = "/var/icinga/rw/icinga.cmd"
> > >
> > > authorize "*" {
> > > password = "XXX"
> > > hosts = ".*"
> > > services = ".*"
> > > }
> > >
> > > I don't recall if the previous version was listening on v4, v6 or
> > > both.
> > > It starts for example with:
> > > nsca-ng -b 127.0.0.1
> > >
> > > Thanks,
> > > Florian
> > >
> > > --
> > > I'm not entirely sure you are real.
> > >
> >
> > --
> > I'm not entirely sure you are real.
> >
>
--
I'm not entirely sure you are real.
Re: nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
I didn't manage to track down a fix but I've set nsca-ng back to using
openssl/1.0.2 for now, my glasses do not permit looking at BIO_* for
more than a few moments.
On 2020/12/02 17:23, Florian Obser wrote:
> Looks like this thing might be legacy IP only.
> I work around the problem by adding:
> listen = "0.0.0.0"
> to /etc/nsca-ng.cfg
>
> Having glanced at the code in src/common/tls.c could this be an
> openssl update?
>
> Don't think I'll have a lot of time digging into this though.
>
> On Wed, Dec 02, 2020 at 04:44:27PM +0100, Florian Obser wrote:
> > After the recent nsca-ng update it no longer starts:
> >
> > nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
> >
> > My nsca-ng config is fairly simple:
> >
> > # cat /etc/nsca-ng.cfg
> > command_file = "/var/icinga/rw/icinga.cmd"
> >
> > authorize "*" {
> > password = "XXX"
> > hosts = ".*"
> > services = ".*"
> > }
> >
> > I don't recall if the previous version was listening on v4, v6 or
> > both.
> > It starts for example with:
> > nsca-ng -b 127.0.0.1
> >
> > Thanks,
> > Florian
> >
> > --
> > I'm not entirely sure you are real.
> >
>
> --
> I'm not entirely sure you are real.
>
Re: nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
Looks like this thing might be legacy IP only.
I work around the problem by adding:
listen = "0.0.0.0"
to /etc/nsca-ng.cfg
Having glanced at the code in src/common/tls.c could this be an
openssl update?
Don't think I'll have a lot of time digging into this though.
On Wed, Dec 02, 2020 at 04:44:27PM +0100, Florian Obser wrote:
> After the recent nsca-ng update it no longer starts:
>
> nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
>
> My nsca-ng config is fairly simple:
>
> # cat /etc/nsca-ng.cfg
> command_file = "/var/icinga/rw/icinga.cmd"
>
> authorize "*" {
> password = "XXX"
> hosts = ".*"
> services = ".*"
> }
>
> I don't recall if the previous version was listening on v4, v6 or
> both.
> It starts for example with:
> nsca-ng -b 127.0.0.1
>
> Thanks,
> Florian
>
> --
> I'm not entirely sure you are real.
>
--
I'm not entirely sure you are real.
nsca-ng: nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
After the recent nsca-ng update it no longer starts:
nsca-ng: [FATAL] Cannot bind to *:5668: Invalid argument
My nsca-ng config is fairly simple:
# cat /etc/nsca-ng.cfg
command_file = "/var/icinga/rw/icinga.cmd"
authorize "*" {
password = "XXX"
hosts = ".*"
services = ".*"
}
I don't recall if the previous version was listening on v4, v6 or
both.
It starts for example with:
nsca-ng -b 127.0.0.1
Thanks,
Florian
--
I'm not entirely sure you are real.
Re: [NEW] graphics/opencollada
On Wed, December 2, 2020 05:53, Dimitri Karamazov wrote:
> Information for inst:opencollada-1.6.68
>
>
> Comment:
> stream based reader and writer library for COLLADA files
>
> Description:
> OpenCOLLADA is a reader and writer library for the COLLADA format, an open,
> royalty-free standard for exchanging 3D asset information between
> applications, digital content creation tools and libraries.
>
> Maintainer: Dimitri Karamazov
>
>
> WWW: https://github.com/KhronosGroup/OpenCOLLADA
>
>
> Any comments/OK's?
Fixed location of cmake files and libraries to ${LOCALBASE}/lib/cmake and
${LOCALBASE}/lib
respectively.
Build tested on amd64
regards,
Dimitri
opencollada.tar.gz
Description: application/gzip
Re: [UPDATE] math/hdf5 1.12.0
On Wed, Dec 02, 2020 at 11:57:24AM +0100, Landry Breuil wrote: > On Tue, Dec 01, 2020 at 09:01:14PM +0100, Martin Reindl wrote: > > The attached diff updates math/hdf5 to the latest version 1.12.0. > > there's no geo/gdal anymore, and geo/gdal,python3 builds fine with this > update. > Thanks. In the meantime, testing on arm64 finished succesfully. Ingo offered me to take maintainer, so I will commit an adapted diff. -m
Re: [UPDATE] math/hdf5 1.12.0
On Tue, Dec 01, 2020 at 09:01:14PM +0100, Martin Reindl wrote: > The attached diff updates math/hdf5 to the latest version 1.12.0. > > - enable fortran > - API changes require major bump to all shlib > - use configure argument for example dir instead of post-install mv(1) > - pull patches from upstream to respect DESTDIR for examples > > (https://github.com/HDFGroup/hdf5/commit/4cebd8aa6c965fe2e5dde6dbff36b2be3ca58bf1) > - patch h5repack_plugin.sh test to work with our cp(1) > > The extensive hdf5 test-suite passes on amd64. My arm64 is too slow so it > runs into > the test timeout. Checking currently if raising HDF5_ALARM_SECONDS helps. > Also tested on sparc64, but fheap tests fail there. > > Also compile and partially run-time tested where especially relevant to me: > math/armadillo > math/matio > math/netcdf > math/octave > math/py-h5py,python3 > math/py-netcdf4 > math/py-tables > > Currently NOT tested: > geo/gdal > geo/gdal,python3 there's no geo/gdal anymore, and geo/gdal,python3 builds fine with this update. Landry
[UPDATE] www/youtube-dl to 2020.12.02
Hi,
New release today, OK?
[tva] Add support for qub.ca (#27235)
[toggle] Detect DRM protected videos (closes #16479)(closes #20805)
[toggle] Add support for new MeWatch URLs (#27256)
[youtube:tab] Extract channels only from channels tab (#27266)
[cpan] Extract info from jwplayer data (#3672, #3734, #10638, #13030, #18806,
#23148, #24461, #26171, #26800, #27263)
[cspan] Pass Referer header with format's video URL (#26032, #25729)
[youtube] Improve age-gated videos extraction (#27259)
[mediaset] Add support for movie URLs (#27240)
[yandexmusic] Refactor
[yandexmusic] Add support for artist's tracks and albums (#11887, #22284)
[yandexmusic:track] Fix extraction (#26449, #26669, #26747, #26748, #26762)
Index: Makefile
===
RCS file: /cvs/ports/www/youtube-dl/Makefile,v
retrieving revision 1.218
diff -u -p -u -r1.218 Makefile
--- Makefile29 Nov 2020 21:45:25 - 1.218
+++ Makefile2 Dec 2020 10:44:27 -
@@ -2,7 +2,7 @@
COMMENT = CLI program to download videos from YouTube and other sites
-VERSION = 2020.11.29
+VERSION = 2020.12.02
MODPY_EGG_VERSION =${VERSION:S/.0/./g}
DISTNAME = youtube-dl-${VERSION}
Index: distinfo
===
RCS file: /cvs/ports/www/youtube-dl/distinfo,v
retrieving revision 1.197
diff -u -p -u -r1.197 distinfo
--- distinfo29 Nov 2020 21:45:26 - 1.197
+++ distinfo2 Dec 2020 10:44:27 -
@@ -1,2 +1,2 @@
-SHA256 (youtube-dl-2020.11.29.tar.gz) =
5ii+hgPSj3ZVZkNd3iU7zcIlNcEgoHJg+5RwqS0v/YI=
-SIZE (youtube-dl-2020.11.29.tar.gz) = 3222467
+SHA256 (youtube-dl-2020.12.02.tar.gz) =
cWGy4/PAmt5Z+246QWCiJKOwTjnHdE4UzZ82H3GlenI=
+SIZE (youtube-dl-2020.12.02.tar.gz) = 3225560
Re: cyrus-imapd upstreamed patches and improvements
On Mon, Nov 30, 2020 at 04:19:16AM -0300, Anatoli wrote:
> Antoine, Stuart,
>
> cyrus-imapd 3.2.5 was just released.
>
> I'm attaching an updated patch that also includes the SHA256 and the version
> bump + everything else from my initial mail, which is needed to accommodate
> the
> cross-platform changes and upstreamed port's patches that are included in this
> release (and the explanations for each change are in my initial mail).
Thanks, I will look at this over the week-end.
>
> Regards,
> Anatoli
>
>
>
> diff --git Makefile Makefile
> index bfee0b835b1..d738a1ca91b 100644
> --- Makefile
> +++ Makefile
> @@ -4,7 +4,7 @@ PORTROACH=limitw:1,even
>
> COMMENT= Cyrus IMAP server
>
> -V= 3.2.4
> +V= 3.2.5
> DISTNAME=cyrus-imapd-${V}
>
> SHARED_LIBS += cyrus 0.0 # 0.0
> diff --git distinfo distinfo
> index 2c825c1a02a..367870468fe 100644
> --- distinfo
> +++ distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (cyrus-imapd-3.2.4.tar.gz) =
> UWEmLDgqpaeMKLGk9eolRQne4eet6DH37JsUB4+0LyM=
> -SIZE (cyrus-imapd-3.2.4.tar.gz) = 12270070
> +SHA256 (cyrus-imapd-3.2.5.tar.gz) =
> zDhqdU4kOJtSr4NzdrO7YFW+pwV/U+yHq8oGqOjWlWM=
> +SIZE (cyrus-imapd-3.2.5.tar.gz) = 12237158
> diff --git Makefile Makefile
> index c7fb05ebcee..bfee0b835b1 100644
> --- Makefile
> +++ Makefile
> @@ -39,8 +39,7 @@ LIB_DEPENDS=databases/sqlite3 \
>
> CONFIGURE_STYLE= gnu
> CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
> - LDFLAGS="-L${LOCALBASE}/lib" \
> - cyrus_cv_sse42=no
> + LDFLAGS="-L${LOCALBASE}/lib"
> CONFIGURE_ARGS= --bindir=${PREFIX}/cyrus/bin \
> --libexec=${PREFIX}/cyrus/libexec \
> --sbindir=${PREFIX}/cyrus/sbin \
> @@ -48,17 +47,12 @@ CONFIGURE_ARGS= --bindir=${PREFIX}/cyrus/bin \
> --with-cyrus-user=_cyrus \
> --with-syslogfacility=MAIL \
> --without-chardet \
> - --without-cld2 \
> --without-sphinx-build \
> --without-zeroskip \
> --disable-gssapi \
> --enable-autocreate \
> --enable-idled \
> - --enable-murder \
> - --enable-nntp
> -
> -# XXX FLAVOR
> -CONFIGURE_ARGS +=--without-snmp
> + --enable-murder
>
> # XXX notyet; FLAVOR
> CONFIGURE_ARGS +=--without-clamav \
> diff --git patches/patch-imap_conversations_c
> patches/patch-imap_conversations_c
> deleted file mode 100644
> index 9eab9396e0d..000
> --- patches/patch-imap_conversations_c
> +++ /dev/null
> @@ -1,16 +0,0 @@
> -$OpenBSD: patch-imap_conversations_c,v 1.3 2020/05/14 12:26:39 ajacoutot Exp
> $
> -
> -64 bit time_t
> -
> -Index: imap/conversations.c
> imap/conversations.c.orig
> -+++ imap/conversations.c
> -@@ -567,7 +567,7 @@ static int _conversations_set_key(struct conversations
> - if (i) buf_putc(&buf, ',');
> - buf_printf(&buf, CONV_FMT, cid);
> - }
> --buf_printf(&buf, " %lu", stamp);
> -+buf_printf(&buf, " %lld", stamp);
> -
> - r = cyrusdb_store(state->db,
> - key, keylen,
> diff --git patches/patch-imap_fud_c patches/patch-imap_fud_c
> deleted file mode 100644
> index cc6a8f8d327..000
> --- patches/patch-imap_fud_c
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -$OpenBSD: patch-imap_fud_c,v 1.2 2020/08/28 09:53:04 ajacoutot Exp $
> -
> -Index: imap/fud.c
> imap/fud.c.orig
> -+++ imap/fud.c
> -@@ -96,8 +96,10 @@ static void send_reply(struct sockaddr *sfrom, socklen
> -
> - static int soc = 0; /* inetd (master) has handed us the port as stdin */
> -
> --#ifndef MAXDOMNAME
> -+#ifndef MAXLOGNAME
> - #define MAXLOGNAME 16 /* should find out for real */
> -+#endif
> -+#ifndef MAXDOMNAME
> - #define MAXDOMNAME 20 /* should find out for real */
> - #endif
> -
> diff --git patches/patch-imap_mailbox_c patches/patch-imap_mailbox_c
> deleted file mode 100644
> index 0793441fdfa..000
> --- patches/patch-imap_mailbox_c
> +++ /dev/null
> @@ -1,34 +0,0 @@
> -$OpenBSD: patch-imap_mailbox_c,v 1.19 2020/05/30 10:09:27 ajacoutot Exp $
> -
> -64 bit time_t
> -
> -Index: imap/mailbox.c
> imap/mailbox.c.orig
> -+++ imap/mailbox.c
> -@@ -2899,7 +2899,7 @@ static uint32_t crc_basic(const struct mailbox *mailbo
> - flagcrc ^= crc32_cstring(buf);
> - }
> -
> --snprintf(buf, sizeof(buf), "%u " MODSEQ_FMT " %lu (%u) %lu %s",
> -+snprintf(buf, sizeof(buf), "%u " MODSEQ_FMT " %lld (%u) %lld %s",
> - record->uid, record->modseq, record->last_updated,
> - flagcrc,
> - record->internaldate,
> -@@ -2959,7 +2959,7 @@ static uint32_t crc_virtannot(struct mailbox *mailbox,
> - }
> -
> - if (r
[NEW] graphics/opencollada
Information for inst:opencollada-1.6.68 Comment: stream based reader and writer library for COLLADA files Description: OpenCOLLADA is a reader and writer library for the COLLADA format, an open, royalty-free standard for exchanging 3D asset information between applications, digital content creation tools and libraries. Maintainer: Dimitri Karamazov WWW: https://github.com/KhronosGroup/OpenCOLLADA Any comments/OK's? opencollada.tar.gz Description: application/gzip
