CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2022/07/12 23:57:53 Modified files: www/chromium : Makefile distinfo Removed files: www/chromium/patches: patch-build_config_compiler_pgo_pgo_gni Log message: enable PGO (Profile Guided Optimization) by providing a profile datafile compatible with our llvm
UPDATE: arm-compute-library 22.05
Hi,
This updates arm-compute-library to 22.05. Changes are listed here [1].
ok?
[1]
https://arm-software.github.io/ComputeLibrary/v22.05/versions_changelogs.xhtml#S2_2_changelog
Index: devel/arm-compute-library/Makefile
===
RCS file: /cvs/ports/devel/arm-compute-library/Makefile,v
retrieving revision 1.6
diff -u -p -u -p -r1.6 Makefile
--- devel/arm-compute-library/Makefile 31 Mar 2022 16:39:08 - 1.6
+++ devel/arm-compute-library/Makefile 13 Jul 2022 00:31:26 -
@@ -2,9 +2,8 @@ ONLY_FOR_ARCHS =aarch64
COMMENT = Arm compute library
-V =22.02
+V =22.05
PKGNAME = arm-compute-library-${V}
-REVISION = 0
GH_ACCOUNT = ARM-software
GH_PROJECT = ComputeLibrary
@@ -17,13 +16,11 @@ HOMEPAGE = https://github.com/ARM-softwa
MAINTAINER = Kevin Lo
SO_VERSION = 2.0
-ACL_LIBS = arm_compute \
- arm_compute_core \
- arm_compute_graph
+COMPUTE_SO_V = 3.0
-.for _lib in ${ACL_LIBS}
-SHARED_LIBS += ${_lib} ${SO_VERSION}
-.endfor
+SHARED_LIBS += arm_compute ${COMPUTE_SO_V}
+SHARED_LIBS += arm_compute_core ${SO_VERSION}
+SHARED_LIBS += arm_compute_graph ${SO_VERSION}
# MIT
PERMIT_PACKAGE=Yes
@@ -49,15 +46,19 @@ do-install:
cp -R ${WRKSRC}/${dir} ${PREFIX}/include
.endfor
cp -R ${WRKSRC}/include/* ${PREFIX}/include
-.for _lib in ${ACL_LIBS}
- ${INSTALL_DATA} ${WRKSRC}/build/lib${_lib}.so \
-${PREFIX}/lib/lib${_lib}.so.${SO_VERSION}
-.endfor
+ ${INSTALL_DATA} ${WRKSRC}/build/libarm_compute.so \
+${PREFIX}/lib/libarm_compute.so.${COMPUTE_SO_V}
+ ${INSTALL_DATA} ${WRKSRC}/build/libarm_compute_core.so \
+${PREFIX}/lib/libarm_compute_core.so.${SO_VERSION}
+ ${INSTALL_DATA} ${WRKSRC}/build/libarm_compute_graph.so \
+${PREFIX}/lib/libarm_compute_graph.so.${SO_VERSION}
${INSTALL_DATA} ${WRKSRC}/build/*.a ${PREFIX}/lib
${INSTALL_DATA_DIR} ${PREFIX}/share/examples/arm-compute-library
${INSTALL_DATA} ${WRKSRC}/examples/*.{h,cpp} \
${PREFIX}/share/examples/arm-compute-library
- cp -R ${WRKSRC}/examples/gemm_tuner \
+.for dir in dynamic_fusion gemm_tuner
+ cp -R ${WRKSRC}/examples/${dir} \
${PREFIX}/share/examples/arm-compute-library
+.endfor
.include
Index: devel/arm-compute-library/distinfo
===
RCS file: /cvs/ports/devel/arm-compute-library/distinfo,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 distinfo
--- devel/arm-compute-library/distinfo 29 Mar 2022 08:06:01 - 1.3
+++ devel/arm-compute-library/distinfo 13 Jul 2022 00:31:26 -
@@ -1,2 +1,2 @@
-SHA256 (ComputeLibrary-22.02.tar.gz) =
ESRLBSWfscSvc4TQwzka6t3siqwUR3QgdYLbSEJyZUA=
-SIZE (ComputeLibrary-22.02.tar.gz) = 12990648
+SHA256 (ComputeLibrary-22.05.tar.gz) =
lOLp/4fCYanJmHvJAkxEnEgBT3/nBzEb36drh/PdpcU=
+SIZE (ComputeLibrary-22.05.tar.gz) = 13119545
Index: devel/arm-compute-library/patches/patch-SConscript
===
RCS file: /cvs/ports/devel/arm-compute-library/patches/patch-SConscript,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-SConscript
--- devel/arm-compute-library/patches/patch-SConscript 29 Mar 2022 08:06:01
- 1.4
+++ devel/arm-compute-library/patches/patch-SConscript 13 Jul 2022 00:31:26
-
@@ -1,7 +1,7 @@
Index: SConscript
--- SConscript.orig
+++ SConscript
-@@ -610,7 +610,7 @@ else:
+@@ -623,7 +623,7 @@ else:
elif 'sve' in env['arch']:
lib_files += lib_files_sve
@@ -10,7 +10,7 @@ Index: SConscript
Export('arm_compute_a')
-@@ -629,7 +629,7 @@ if env['os'] == 'macos':
+@@ -642,7 +642,7 @@ if env['os'] == 'macos':
# macos static library archiver fails if given an empty list of files
arm_compute_core_a = build_library('arm_compute_core-static',
arm_compute_env, lib_files, static=True)
else:
@@ -19,7 +19,7 @@ Index: SConscript
Export('arm_compute_core_a')
-@@ -642,7 +642,7 @@ arm_compute_graph_env = arm_compute_env.Clone()
+@@ -655,7 +655,7 @@ arm_compute_graph_env = arm_compute_env.Clone()
# Build graph libraries
arm_compute_graph_env.Append(CXXFLAGS = ['-Wno-redundant-move',
'-Wno-pessimizing-move'])
Index: devel/arm-compute-library/patches/patch-SConstruct
===
RCS file: /cvs/ports/devel/arm-compute-library/patches/patch-SConstruct,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 patch-SConstruct
--- devel/arm-compute-library/patches/patch-SConstruct 29 Mar 2022 08:06:01
- 1.4
+++ devel/arm-compute-library/patches/patch-SConstruct 13 Jul 2022 00:31:26
-
@@ -1,7 +1,7 @@
Index: SConstruct
--- SConstruct.orig
+++ SConstruct
-@@ -215,17 +215,8 @@ c_compiler = os.environ.get('CC', default_c_compiler)
+@@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jer...@cvs.openbsd.org 2022/07/12 17:39:34 Modified files: databases/ruby-ldap: Makefile Log message: Remove --without-libldap from configure args This has been broken at runtime since the update to OpenLDAP 2.6.2. ruby-ldap previously linked to libldap_r, but the OpenLDAP update removed libldap_r, and the code compiled without linking to any ldap library, breaking at runtime. Update WANTLIB while here.
Re: [new] devel/libdispatch (for deadbeef)
Looking at our net/tdesktop and github.com/desktop-app/cmake_helpers which is telegram's code handling libdispatch, I'm sure it would pick it up. Right now, it tries to find system dispatch, fails, tries to build the bundled version, fails again since we intentionally zapped the bundle and eventually tdesktop still builds/runs fine... I vaguely remember upstream introducing libdispatch as dependency and Andrew and me trying to disable/neuter it, but I plain forgot how we arrived at the current status quo.
Re: bsd.port.mk: allow for simpler patch fetching in GH_* ports
On 13/07/2022 02:52, Stuart Henderson wrote:
On 2022/07/12 08:41, Aaron Bieber wrote:
On Mon, 11 Jul 2022 at 11:17:55 +, Klemens Nanni wrote:
GH_* ports obviously set MASTER_SITES to MASTER_SITES_GITHUB which
defaults github.com/${account}/${project}/archive/${commit-or-tag}.
If additional patches need to be fetched, e.g. pending PRs to fix the
local port, additional MASTER_SITES0-9 must be defined which always
duplicate the GH_* values:
MASTER_SITES0 = https://github.com/account/project/pull/
PATCHFILES += many_fixes-{}number.patch:0
or
MASTER_SITES0 = https://github.com/account/project/commit/
PATCHFILES += one_fix-{}id.patch:0
or
MASTER_SITES0 = https://github.com/account/project/
PATCHFILES += many_fixes-{pull/}number.patch:0
PATCHFILES += one_fix-{commit/}id.patch:0
Not super important but a bit annoying, the automatically generated
MASTER_SITES_GITHUB can't really be reused (without dirty make fiddling)
so MASTER_SITES0 is always a duplicate and PATCHFILES need :0 to work.
But all we need to make this reusable is move the "archive/" part from
MASTER_SITES_GITHUB to GH_DISTFILE, i.e. internally do
MASTER_SITES = https://github.com/account/project/
DISTNAME = account-project-{archive/}commit_or_tag.tar.gz
instead of
MASTER_SITES = https://github.com/account/project/archive/
DISTNAME = account-project-{}commit_or_tag.tar.gz
If that is changing I think it might be better to go for
MASTER_SITES = https://github.com/
DISTNAME = account-project-{account/project/archive/}commit_or_tag.tar.gz
Then we don't need multiple MASTER_SITES for a second github distfile either
since this way the aforementioned patch fetching can be simplified to
PATCHFILES += many_fixes-{pull/}number.patch
or
PATCHFILES += one_fix-{commit/}id.patch
without additional MASTER_SITES0-9.
It's a rather unimportant detail but juggling with WIP ports, own PRs,
fixes, etc. gets a little easier with this since the Makefile stays a
bit smaller.
For testing, I have fetched several ports, both using GH_COMMIT and
GH_TAGNAME, without any failures or distinfo changes.
As for the logic in bsd.port.mk itself, this also lifts the quirky
add-trailing-slash-to-MASTER_SITES_GITHUB-only-if-GH_TAGNAME-is-set
since it now ends with a fixed string and the additional URL paths only
come in where GH_TAGNAME or whatever follows is definitely set.
Feedback? Objection? OK?
I like it! I can't speak to the make voodoo but the functionality is OK
abieber@ :D
I worry that these upstream patchfiles might become inconsistent fairly
easily (even more than git-archive tarballs). A post-commit tweak to the
commit log message or an edit to the PR will break fetches because the
file will change.
That's only true if /pull/.patch is used and certainly a valid
point, but that's already a problem regardless of this diff.
.patch URLs remain the same, we'd just keep fetching the old
stuff if someone updated a PR or force pushed to a repo.
Another problem is that it can be used to misrepresent patches as being
real repo commits when they are spoofed. e.g. this was never committed to
the real github/dmca repo, yet the URL looks official:
https://github.com/github/dmca/commit/48c5663c5f7dd9ecc4720f7c1522627665197939.patch
While this is a fundemantally GitHub specific issue, we can try our best
to avoid shady URLs by using author/project/pull//
instead of author/project/.
I myself usually annotate fetched patches with
# pending "do this"
# https://link.to/PR/or/so
Does the proposed change make it easier to misuse GitHub URLs?
If you view the non-patch version it does look a bit more suspicious with
the header on the page, but there's no cue like that in a port with such a line
https://github.com/github/dmca/commit/48c5663c5f7dd9ecc4720f7c1522627665197939
(Method at https://gist.github.com/lrvick/02088ee5466ca51116bdaf1e709ddd7c)
patches upstream.. for example:
https://patch-diff.githubusercontent.com/raw/tailscale/tailscale/pull/4838.patch
)
I wonder if it would make sense to have an "alias" for a
MASTER_SITES entry that could be referenced in a more human
frindly/generic way. Maybe something like:
PATCHFILES += github:account/project/many_fixes-{pull/}number.patch
PATCHFILES += gitlab:account/project/one_fix-{commit/}id.patch
There's a lot of common handling between DISTFILES, PATCHFILES, SUPDISTFILES.
Considering that some ports have thousands of distfiles I'd worry that more
complex processing of this will really slow down make(1), it's already pretty
bad in some cases.
Yes, we've had DISTFILES tweaks in go.port.mk with noticable performance
impacts already, so this should be looked after.
Re: bsd.port.mk: allow for simpler patch fetching in GH_* ports
On 2022/07/12 08:41, Aaron Bieber wrote:
> On Mon, 11 Jul 2022 at 11:17:55 +, Klemens Nanni wrote:
> > GH_* ports obviously set MASTER_SITES to MASTER_SITES_GITHUB which
> > defaults github.com/${account}/${project}/archive/${commit-or-tag}.
> >
> > If additional patches need to be fetched, e.g. pending PRs to fix the
> > local port, additional MASTER_SITES0-9 must be defined which always
> > duplicate the GH_* values:
> >
> > MASTER_SITES0 = https://github.com/account/project/pull/
> > PATCHFILES += many_fixes-{}number.patch:0
> > or
> > MASTER_SITES0 = https://github.com/account/project/commit/
> > PATCHFILES += one_fix-{}id.patch:0
> > or
> > MASTER_SITES0 = https://github.com/account/project/
> > PATCHFILES += many_fixes-{pull/}number.patch:0
> > PATCHFILES += one_fix-{commit/}id.patch:0
> >
> > Not super important but a bit annoying, the automatically generated
> > MASTER_SITES_GITHUB can't really be reused (without dirty make fiddling)
> > so MASTER_SITES0 is always a duplicate and PATCHFILES need :0 to work.
> >
> >
> > But all we need to make this reusable is move the "archive/" part from
> > MASTER_SITES_GITHUB to GH_DISTFILE, i.e. internally do
> >
> > MASTER_SITES = https://github.com/account/project/
> > DISTNAME = account-project-{archive/}commit_or_tag.tar.gz
> > instead of
> > MASTER_SITES = https://github.com/account/project/archive/
> > DISTNAME = account-project-{}commit_or_tag.tar.gz
If that is changing I think it might be better to go for
MASTER_SITES = https://github.com/
DISTNAME = account-project-{account/project/archive/}commit_or_tag.tar.gz
Then we don't need multiple MASTER_SITES for a second github distfile either
> > since this way the aforementioned patch fetching can be simplified to
> >
> > PATCHFILES += many_fixes-{pull/}number.patch
> > or
> > PATCHFILES += one_fix-{commit/}id.patch
> >
> > without additional MASTER_SITES0-9.
> >
> > It's a rather unimportant detail but juggling with WIP ports, own PRs,
> > fixes, etc. gets a little easier with this since the Makefile stays a
> > bit smaller.
> >
> > For testing, I have fetched several ports, both using GH_COMMIT and
> > GH_TAGNAME, without any failures or distinfo changes.
> >
> > As for the logic in bsd.port.mk itself, this also lifts the quirky
> > add-trailing-slash-to-MASTER_SITES_GITHUB-only-if-GH_TAGNAME-is-set
> > since it now ends with a fixed string and the additional URL paths only
> > come in where GH_TAGNAME or whatever follows is definitely set.
> >
> > Feedback? Objection? OK?
> >
>
> I like it! I can't speak to the make voodoo but the functionality is OK
> abieber@ :D
I worry that these upstream patchfiles might become inconsistent fairly
easily (even more than git-archive tarballs). A post-commit tweak to the
commit log message or an edit to the PR will break fetches because the
file will change.
Another problem is that it can be used to misrepresent patches as being
real repo commits when they are spoofed. e.g. this was never committed to
the real github/dmca repo, yet the URL looks official:
https://github.com/github/dmca/commit/48c5663c5f7dd9ecc4720f7c1522627665197939.patch
If you view the non-patch version it does look a bit more suspicious with
the header on the page, but there's no cue like that in a port with such a line
https://github.com/github/dmca/commit/48c5663c5f7dd9ecc4720f7c1522627665197939
(Method at https://gist.github.com/lrvick/02088ee5466ca51116bdaf1e709ddd7c)
> patches upstream.. for example:
> https://patch-diff.githubusercontent.com/raw/tailscale/tailscale/pull/4838.patch
> )
>
> I wonder if it would make sense to have an "alias" for a
> MASTER_SITES entry that could be referenced in a more human
> frindly/generic way. Maybe something like:
>
> PATCHFILES += github:account/project/many_fixes-{pull/}number.patch
> PATCHFILES += gitlab:account/project/one_fix-{commit/}id.patch
There's a lot of common handling between DISTFILES, PATCHFILES, SUPDISTFILES.
Considering that some ports have thousands of distfiles I'd worry that more
complex processing of this will really slow down make(1), it's already pretty
bad in some cases.
Re: UPDATE: xonotic-0.8.5
> Hi, > > Here's an update to xonotic. > > kn@ is no longer interested in maintaining it, and has asked me to drop > MAINTAINER. > > OK? I have tested this on my machine and played on a Xonotic server with it and it works OK for me on amd64 platform. Thanks, Tom
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/07/12 15:17:30 Modified files: cad/lepton-eda : Makefile distinfo cad/lepton-eda/pkg: PLIST Log message: update to lepton-eda-1.9.18, from Dmitry Pryakhin (maintainer), feedback kn@
Re: Does p5-Net-ICal work for you?
Never tried it, but seems it hasn't been updated upstream since 2001 so there's a good chance it needs changes to stay working On 2022/07/12 19:51, Mikolaj Kucharski wrote: > Hi, > > I see this on my end: > > OpenBSD 7.1-current (GENERIC.MP) #610: Sat Jul 9 09:19:43 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > $ perl -MNet::ICal -e '' > UNIVERSAL does not export anything at > /usr/local/libdata/perl5/site_perl/Class/MethodMapper.pm line 67. > BEGIN failed--compilation aborted at > /usr/local/libdata/perl5/site_perl/Class/MethodMapper.pm line 67. > Compilation failed in require at /usr/libdata/perl5/base.pm line 137. > ...propagated at /usr/libdata/perl5/base.pm line 159. > BEGIN failed--compilation aborted at > /usr/local/libdata/perl5/site_perl/Net/ICal/Component.pm line 27. > Compilation failed in require at /usr/libdata/perl5/base.pm line 137. > ...propagated at /usr/libdata/perl5/base.pm line 159. > BEGIN failed--compilation aborted at > /usr/local/libdata/perl5/site_perl/Net/ICal/Alarm.pm line 27. > Compilation failed in require at > /usr/local/libdata/perl5/site_perl/Net/ICal.pm line 17. > BEGIN failed--compilation aborted at > /usr/local/libdata/perl5/site_perl/Net/ICal.pm line 17. > Compilation failed in require. > BEGIN failed--compilation aborted. > > Do you see the same? > > -- > Regards, > Mikolaj >
Does p5-Net-ICal work for you?
Hi, I see this on my end: OpenBSD 7.1-current (GENERIC.MP) #610: Sat Jul 9 09:19:43 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ perl -MNet::ICal -e '' UNIVERSAL does not export anything at /usr/local/libdata/perl5/site_perl/Class/MethodMapper.pm line 67. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Class/MethodMapper.pm line 67. Compilation failed in require at /usr/libdata/perl5/base.pm line 137. ...propagated at /usr/libdata/perl5/base.pm line 159. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Net/ICal/Component.pm line 27. Compilation failed in require at /usr/libdata/perl5/base.pm line 137. ...propagated at /usr/libdata/perl5/base.pm line 159. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Net/ICal/Alarm.pm line 27. Compilation failed in require at /usr/local/libdata/perl5/site_perl/Net/ICal.pm line 17. BEGIN failed--compilation aborted at /usr/local/libdata/perl5/site_perl/Net/ICal.pm line 17. Compilation failed in require. BEGIN failed--compilation aborted. Do you see the same? -- Regards, Mikolaj
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2022/07/12 14:45:16 Modified files: lang/erlang: Makefile Makefile.inc Added files: lang/erlang/25 : Makefile distinfo lang/erlang/25/patches: patch-Makefile_in patch-erts_emulator_Makefile_in patch-erts_etc_common_ct_run_c patch-erts_etc_common_dialyzer_c patch-erts_etc_common_erlc_c patch-erts_etc_common_escript_c patch-erts_etc_common_typer_c patch-erts_lib_src_Makefile_in patch-lib_crypto_c_src_otp_test_engine_c patch-lib_dialyzer_src_dialyzer_plt_erl patch-make_install_bin lang/erlang/25/pkg: DESCR-main DESCR-wx PLIST-main PLIST-wx Log message: add erlang 25, from Volker Schlecht
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2022/07/12 14:01:50 Modified files: devel/py-protobuf: Makefile distinfo Log message: Update to py-protobuf 4.21.2 https://github.com/protocolbuffers/protobuf/releases/tag/v21.2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2022/07/12 14:01:22 Modified files: devel/protobuf : Makefile distinfo Log message: Update to protobuf 3.21.2 https://github.com/protocolbuffers/protobuf/releases/tag/v21.2
Re: [maintainer update] x11/xscope 1.4.3
On 12/07/2022 23:46, Matthieu Herrb wrote: XSCOPE is a program to monitor the connections between the X11 window server and a client program. Alan Coopersmith (1): xscope 1.4.3 Matthieu Herrb (1): On OpenBSD SO_PEERCRED uses struct sockpeercred Thomas Klausner (7): Remove/comment out unused variables. Match format strings with arguments. ifdef out unused static functions Use correct argument type for ctype(3) functions. Increase buffer length to avoid truncation. Add casts to fix signedness change warnings. Mark MainLoop as _X_NORETURN. OK kn
[maintainer update] x11/xscope 1.4.3
XSCOPE is a program to monitor the connections between the X11 window
server and a client program.
Alan Coopersmith (1):
xscope 1.4.3
Matthieu Herrb (1):
On OpenBSD SO_PEERCRED uses struct sockpeercred
Thomas Klausner (7):
Remove/comment out unused variables.
Match format strings with arguments.
ifdef out unused static functions
Use correct argument type for ctype(3) functions.
Increase buffer length to avoid truncation.
Add casts to fix signedness change warnings.
Mark MainLoop as _X_NORETURN.
ok ?
Index: Makefile
===
RCS file: /cvs/OpenBSD/ports/x11/xscope/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile2 May 2022 07:00:39 - 1.5
+++ Makefile12 Jul 2022 19:41:05 -
@@ -1,5 +1,5 @@
COMMENT = X Window Protocol Viewer
-DISTNAME = xscope-1.4.2
+DISTNAME = xscope-1.4.3
CATEGORIES = x11
HOMEPAGE = https://gitlab.freedesktop.org/xorg/app/xscope
Index: distinfo
===
RCS file: /cvs/OpenBSD/ports/x11/xscope/distinfo,v
retrieving revision 1.2
diff -u -p -u -r1.2 distinfo
--- distinfo2 May 2022 07:00:39 - 1.2
+++ distinfo12 Jul 2022 19:41:41 -
@@ -1,2 +1,2 @@
-SHA256 (xscope-1.4.2.tar.gz) = 4S1jSmnOHsNrCv0dQIFCFeJigBoDDd+D19A0jNBGs4E=
-SIZE (xscope-1.4.2.tar.gz) = 280923
+SHA256 (xscope-1.4.3.tar.gz) = hvnaPPBCK1lkGRyej3kuEHV3gY3glLONsKbbzkA6m1Q=
+SIZE (xscope-1.4.3.tar.gz) = 287174
Index: patches/patch-peerinfo_c
===
RCS file: patches/patch-peerinfo_c
diff -N patches/patch-peerinfo_c
--- patches/patch-peerinfo_c2 May 2022 07:00:39 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-Index: peerinfo.c
peerinfo.c.orig
-+++ peerinfo.c
-@@ -43,7 +43,11 @@ static pid_t
- GetPidFromFd(FD fd)
- {
- #ifdef SO_PEERCRED
-+#ifndef __OpenBSD__
- struct ucred cred;
-+#else
-+struct sockpeercred cred;
-+#endif
- socklen_t cred_len = sizeof(cred);
-
- if (getsockopt(fd, SOL_SOCKET, SO_PEERCRED, , _len) == 0 &&
--
Matthieu Herrb
Re: [update] cad/lepton-eda to 1.9.18 - cvs diff
On Sun, 10 Jul 2022 11:40:42 +
Klemens Nanni wrote:
> On Thu, Jul 07, 2022 at 12:41:53PM +0300, Dmitry Pryakhin wrote:
> > Sorry, forgot to attach the diff... :-(
> >
> > > Hello!
> >
> > > To view recent changes, please see the NEWS.md file:
> > > https://github.com/lepton-eda/lepton-eda/blob/master/NEWS.md#notable-changes-in->
> > > lepton-eda-1918-20220529
> >
> > > The most notable improvement in this release is that now
> > > we can pre-compile Guile source files in advance with
> > > the standard tools (guild), without resorting to certain
> > > hacks, i.e. 'make precompile'.
> > > Using these .go files makes the startup time MUCH shorter.
> >
> > > Tested on -current, amd64.
> >
> > Regards,
> > Dmitry.
>
> This looks OK to me portwise except for the issue below.
> I haven't done any runtests to me.
>
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/cad/lepton-eda/Makefile,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 Makefile
> > --- Makefile27 Mar 2022 10:26:39 - 1.3
> > +++ Makefile6 Jul 2022 19:52:14 -
> > @@ -1,11 +1,10 @@
> > COMMENT = lepton electronic design automation suite
> >
> > -V =1.9.17-20211219
> > +V =1.9.18-20220529
> > DISTNAME = lepton-eda-${V:C/-.*//}
> > -REVISION = 0
> >
> > -SHARED_LIBS += lepton 0.0 # 10.0
> > -SHARED_LIBS += leptongui0.0 # 4.0
> > +SHARED_LIBS += lepton 0.0 # 11.0
> > +SHARED_LIBS += leptongui0.0 # 5.0
>
> This looked off since an upstream version crank should usually result
> in a ports crank as well.
>
> Using /usr/lib/check_sym against liblepton.so.0.0 from the current
> package and liblepton.so.0.0 from the build with this diff shows that
> a major version bump is warranted.
>
> Same goes for leptongui.
Bumped version of lepton and leptongui to 1.0.
Regards,
Dmitry.
Index: Makefile
===
RCS file: /cvs/ports/cad/lepton-eda/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- Makefile 27 Mar 2022 10:26:39 - 1.3
+++ Makefile 12 Jul 2022 18:02:01 -
@@ -1,17 +1,16 @@
COMMENT = lepton electronic design automation suite
-V = 1.9.17-20211219
+V = 1.9.18-20220529
DISTNAME = lepton-eda-${V:C/-.*//}
-REVISION = 0
-SHARED_LIBS += lepton 0.0 # 10.0
-SHARED_LIBS += leptongui0.0 # 4.0
+SHARED_LIBS += lepton 1.0 # 11.0
+SHARED_LIBS += leptongui1.0 # 5.0
CATEGORIES = cad
HOMEPAGE = https://github.com/lepton-eda/lepton-eda
-MAINTAINER = Dmitry Pryakhin
+MAINTAINER = Dmitry Pryakhin
# GPLv2+
PERMIT_PACKAGE = Yes
@@ -44,7 +43,8 @@ LIB_DEPENDS = devel/gettext,-runtime \
CONFIGURE_STYLE = gnu
CONFIGURE_ARGS += --disable-attrib \
- --disable-update-xdg-database
+ --disable-update-xdg-database \
+ --enable-guild
CONFIGURE_ENV = GROFF=false \
GUILE=guile2.2 \
@@ -52,17 +52,16 @@ CONFIGURE_ENV = GROFF=false \
MAKEINFO=gmakeinfo \
M4=/usr/bin/m4
-# XXX make sure guile2 headers are picked up first (over guile1);
-# cannot use CPPFLAGS/CFLAGS since they get appended last
-CONFIGURE_ENV += "CC=${CC} -I${LOCALBASE}/include/guile/2.2"
+# XXX make sure guile2 headers are picked up first (over guile1);
+# cannot use CPPFLAGS/CFLAGS since they get appended last
+CONFIGURE_ENV += "CC=${CC} -I${LOCALBASE}/include/guile/2.2"
CONFIGURE_ENV += "CXX=${CXX} -I${LOCALBASE}/include/guile/2.2"
+# suppress tons of warnings
+# "compilation of /usr/local/bin/guild2.2 failed"
+MAKE_ENV += "GUILE_AUTO_COMPILE=0"
+
post-install:
- # would be nice to precompile the guile files otherwise
- # they're done per-user at startup. it should be similar
- # to this, but it needs more to get it to work:
- # cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} \
- # prefix=${PREFIX} precompile
mv ${PREFIX}/share/doc/lepton-eda/examples \
${PREFIX}/share/examples/lepton-eda
Index: distinfo
===
RCS file: /cvs/ports/cad/lepton-eda/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 18 Mar 2022 09:42:36 - 1.1.1.1
+++ distinfo 12 Jul 2022 18:02:01 -
@@ -1,2 +1,2 @@
-SHA256 (lepton-eda-1.9.17.tar.gz) = lOneKeJUcw6jOX/3iv9BDWOJ3xip/vGhzxHHNAbtsS8=
-SIZE (lepton-eda-1.9.17.tar.gz) = 9454425
+SHA256 (lepton-eda-1.9.18.tar.gz) = X9yNuosNR1Jf3gYWQZeOnKdxzJLld29Sn9XYsPGWYYI=
+SIZE (lepton-eda-1.9.18.tar.gz) = 9459680
Index: pkg/PLIST
===
RCS file: /cvs/ports/cad/lepton-eda/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 PLIST
--- pkg/PLIST 18 Mar 2022 09:42:36 - 1.1.1.1
+++ pkg/PLIST 12 Jul 2022 18:02:07 -
@@ -41,6 +41,7 @@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2022/07/12 13:24:21 Modified files: devel/jenkins/devel: Tag: OPENBSD_7_1 Makefile distinfo Log message: Update jenkins-devel to 2.359
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rsadow...@cvs.openbsd.org 2022/07/12 13:05:34 Modified files: devel/jenkins/devel: Makefile distinfo Log message: Update jenkins-devel to 2.359
Re: UPDATE: x11/qt5
Hi, On Wed, Jul 06, 2022 at 08:49:35AM +0200, Rafael Sadowski wrote: > Update Qt5 to the latest stable opensource version 5.15.5. > I cleaned up some Makefile, removed non-used helper functions > and create a new openbsd-g++/qmake.conf based on freebsd-g++. > > I have tested the update with a lot of Qt5 application without finding > any issues. While here, add me as maintainer. > > The qtwebengine update will come separate. > > OK? I tested this for a while on amd64 with applications like audacious, calibre, keepassxc and trojita. Works fine here and diff looks good to, except for that one commented-out #WRKDIST line which you have already fixed locally so that's fine now. Can this be committed independent from the py-qt5 updates? (I think so, since this is just a minor Qt update so it shouldn't contain any/many API changes.) If so, OK caspar@ Caspar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: b...@cvs.openbsd.org2022/07/12 11:28:04 Modified files: meta/audacious : Makefile audio/audacious: Makefile.inc audio/audacious/player: Makefile distinfo audio/audacious/player/patches: patch-src_libaudqt_Makefile audio/audacious/player/pkg: PLIST audio/audacious/plugins: Makefile distinfo audio/audacious/plugins/patches: patch-configure audio/audacious/plugins/pkg: PLIST Log message: Update to audacious-4.2 Release notes can be found at https://audacious-media-player.org/news/53-audacious-4-2-released. Bumped minor of libaudqt, which is part of player. Player installs system-wide icons so add x11/gtk+3,-guic as RDEP (found by portcheck). OK caspar@
RStudio: keep in sync with R
Hi Brian Due to R's bump of libR, RStudio's port needs tweaking. Patch attached. Thanks Zé -- Index: patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp === RCS file: /cvs/ports/math/rstudio/patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp,v retrieving revision 1.2 diff -u -p -r1.2 patch-src_cpp_core_r_util_REnvironmentPosix_cpp --- patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp 11 Mar 2022 19:36:31 - 1.2 +++ patches/patch-src_cpp_core_r_util_REnvironmentPosix_cpp 12 Jul 2022 13:04:35 - @@ -8,7 +8,7 @@ Index: src/cpp/core/r_util/REnvironmentP #else -#define kLibRFileName"libR.so" -+#define kLibRFileName"libR.so.37.0" ++#define kLibRFileName"libR.so.38.0" #define kLibraryPathEnvVariable "LD_LIBRARY_PATH" FilePath systemDefaultRScript(std::string* pErrMsg)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2022/07/12 09:12:47 Modified files: mail/aerc : Makefile distinfo modules.inc mail/aerc/pkg : PLIST Removed files: mail/aerc/patches: patch-filters_colorize Log message: update mail/aerc to 0.11.0 "This is a big one" (sic) changelog: * New commands to deal with calendar invites. * Background mail count polling for all folders. * Authentication-Results display (DKIM, SPF & DMARC). * Maildir++ support. * Messages are now deselected after performing a command. * IMAP header cache. * Better PGP indicators. * Better threading. * User interface improvements and optimizations. * Various bug fixes.
Upstream Yosys and ABC patches for OpenBSD
Hello OpenBSD porters, I am trying to upstream some of the patches from yosys and abc ports upstream. Yosys - the patches in OpenBSD ports hardcode the $PREFIX path to find the /share directory. This is a workaround the absence of a way to get the executable path in OpenBSD. Upstream said they would prefer deducing the executable path from $PATH. [1] Abc - has minor makefile and #define tweaks, submitted to the upstream project around when the port was created. I will just reach them up again here. [2] I do not want to step on Alessandro DE LAURENZIS long standing effort [3], which is why I communicate here. I am open to suggestions if any. [1]: https://github.com/YosysHQ/yosys/pull/3406 [2]: https://github.com/berkeley-abc/abc/issues/17 [3]: https://marc.info/?l=openbsd-ports=153329187423658=2
Re: bsd.port.mk: allow for simpler patch fetching in GH_* ports
On Mon, 11 Jul 2022 at 11:17:55 +, Klemens Nanni wrote:
> GH_* ports obviously set MASTER_SITES to MASTER_SITES_GITHUB which
> defaults github.com/${account}/${project}/archive/${commit-or-tag}.
>
> If additional patches need to be fetched, e.g. pending PRs to fix the
> local port, additional MASTER_SITES0-9 must be defined which always
> duplicate the GH_* values:
>
> MASTER_SITES0 = https://github.com/account/project/pull/
> PATCHFILES += many_fixes-{}number.patch:0
> or
> MASTER_SITES0 = https://github.com/account/project/commit/
> PATCHFILES += one_fix-{}id.patch:0
> or
> MASTER_SITES0 = https://github.com/account/project/
> PATCHFILES += many_fixes-{pull/}number.patch:0
> PATCHFILES += one_fix-{commit/}id.patch:0
>
> Not super important but a bit annoying, the automatically generated
> MASTER_SITES_GITHUB can't really be reused (without dirty make fiddling)
> so MASTER_SITES0 is always a duplicate and PATCHFILES need :0 to work.
>
>
> But all we need to make this reusable is move the "archive/" part from
> MASTER_SITES_GITHUB to GH_DISTFILE, i.e. internally do
>
> MASTER_SITES = https://github.com/account/project/
> DISTNAME = account-project-{archive/}commit_or_tag.tar.gz
> instead of
> MASTER_SITES = https://github.com/account/project/archive/
> DISTNAME = account-project-{}commit_or_tag.tar.gz
>
> since this way the aforementioned patch fetching can be simplified to
>
> PATCHFILES += many_fixes-{pull/}number.patch
> or
> PATCHFILES += one_fix-{commit/}id.patch
>
> without additional MASTER_SITES0-9.
>
> It's a rather unimportant detail but juggling with WIP ports, own PRs,
> fixes, etc. gets a little easier with this since the Makefile stays a
> bit smaller.
>
> For testing, I have fetched several ports, both using GH_COMMIT and
> GH_TAGNAME, without any failures or distinfo changes.
>
> As for the logic in bsd.port.mk itself, this also lifts the quirky
> add-trailing-slash-to-MASTER_SITES_GITHUB-only-if-GH_TAGNAME-is-set
> since it now ends with a fixed string and the additional URL paths only
> come in where GH_TAGNAME or whatever follows is definitely set.
>
> Feedback? Objection? OK?
>
I like it! I can't speak to the make voodoo but the functionality is OK
abieber@ :D
Taking it a step further.. Often times I have a MODGO_ port that has GH
patches upstream.. for example:
https://patch-diff.githubusercontent.com/raw/tailscale/tailscale/pull/4838.patch
)
I wonder if it would make sense to have an "alias" for a
MASTER_SITES entry that could be referenced in a more human
frindly/generic way. Maybe something like:
PATCHFILES += github:account/project/many_fixes-{pull/}number.patch
PATCHFILES += gitlab:account/project/one_fix-{commit/}id.patch
>
> Index: bsd.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
> retrieving revision 1.1576
> diff -u -p -r1.1576 bsd.port.mk
> --- bsd.port.mk 6 Jul 2022 09:30:41 - 1.1576
> +++ bsd.port.mk 11 Jul 2022 10:59:44 -
> @@ -613,7 +613,7 @@ GH_PROJECT ?=
>
> .if !empty(GH_PROJECT) && !empty(GH_TAGNAME)
> DISTNAME ?=
> ${GH_PROJECT}-${GH_TAGNAME:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}
> -GH_DISTFILE =
> ${GH_PROJECT}-${GH_TAGNAME:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}${EXTRACT_SUFX}
> +GH_DISTFILE =
> ${GH_PROJECT}-{archive/}${GH_TAGNAME:C/^(v|V|ver|[Rr]el|[Rr]elease)[-._]?([0-9])/\2/}${EXTRACT_SUFX}
> .endif
>
> PKGNAME ?= ${DISTNAME}
> @@ -1261,7 +1261,7 @@ ERRORS += "Fatal: specifying both GH_TAG
> ERRORS += "Fatal: using master as GH_TAGNAME is invalid"
> . endif
> MASTER_SITES_GITHUB += \
> -
> https://github.com/${GH_ACCOUNT}/${GH_PROJECT}/archive/${GH_TAGNAME:S/$/\//}
> + https://github.com/${GH_ACCOUNT}/${GH_PROJECT}/
>
> MASTER_SITES ?= ${MASTER_SITES_GITHUB}
> HOMEPAGE ?= https://github.com/${GH_ACCOUNT}/${GH_PROJECT}
> @@ -1290,7 +1290,7 @@ _warn_checksum += ;echo ">>> MASTER_SITE
> EXTRACT_SUFX ?= .tar.gz
>
> .if !empty(GH_COMMIT)
> -GH_DISTFILE =
> ${DISTNAME}-${GH_COMMIT:C/().*/\1/}${EXTRACT_SUFX}{${GH_COMMIT}${EXTRACT_SUFX}}
> +GH_DISTFILE =
> ${DISTNAME}-${GH_COMMIT:C/().*/\1/}${EXTRACT_SUFX}{archive/${GH_COMMIT}${EXTRACT_SUFX}}
> DISTFILES ?= ${GH_DISTFILE}
> .elif defined(DISTNAME)
> DISTFILES ?= ${DISTNAME}${EXTRACT_SUFX}
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/07/12 08:14:27 Modified files: security/yara/python: Makefile Log message: The new version of yara/python won't build with base-gcc. Shift to ports-gcc on base-gcc arches. Fixes build on sparc64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/07/12 08:02:45 Modified files: archivers/zziplib: Makefile Log message: zziplib now uses a compiler option base-gcc does not understand. Shift to using ports-gcc on base-gcc architectures to fix build on sparc64
arm bulk build report
bulk build on armv7.ports.openbsd.org started on Sun Jun 19 02:05:48 MDT 2022 finished at Tue Jul 12 06:06:01 MDT 2022 lasted 23D04h00m done with kern.version=OpenBSD 7.1-current (GENERIC) #46: Wed Jun 15 19:50:07 MDT 2022 built packages:8334 Jun 19:503 Jun 20:84 Jun 21:270 Jun 22:205 Jun 23:30 Jun 24:271 Jun 25:278 Jun 26:99 Jun 27:145 Jun 28:132 Jun 29:189 Jun 30:203 Jul 1:3315 Jul 2:227 Jul 3:266 Jul 4:246 Jul 5:287 Jul 6:315 Jul 7:490 Jul 8:379 Jul 9:399 Jul 10:383 Jul 11:1649 Jul 12:1100 critical path missing pkgs: http://build-failures.rhaalovely.net/arm/2022-06-19/summary.log build failures: 57 http://build-failures.rhaalovely.net/arm/2022-06-19/devel/abseil-cpp.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/boost.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/dyncall.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/liboil.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/ptlib.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/remake.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/reposurgeon.log http://build-failures.rhaalovely.net/arm/2022-06-19/devel/xsd.log http://build-failures.rhaalovely.net/arm/2022-06-19/editors/micro.log http://build-failures.rhaalovely.net/arm/2022-06-19/editors/poke.log http://build-failures.rhaalovely.net/arm/2022-06-19/editors/zile.log http://build-failures.rhaalovely.net/arm/2022-06-19/emulators/dgen-sdl.log http://build-failures.rhaalovely.net/arm/2022-06-19/emulators/higan.log http://build-failures.rhaalovely.net/arm/2022-06-19/emulators/ppsspp.log http://build-failures.rhaalovely.net/arm/2022-06-19/emulators/spike.log http://build-failures.rhaalovely.net/arm/2022-06-19/games/barony.log http://build-failures.rhaalovely.net/arm/2022-06-19/games/hyperrogue.log http://build-failures.rhaalovely.net/arm/2022-06-19/games/stockfish.log http://build-failures.rhaalovely.net/arm/2022-06-19/graphics/babl.log http://build-failures.rhaalovely.net/arm/2022-06-19/graphics/tesseract/tesseract.log http://build-failures.rhaalovely.net/arm/2022-06-19/graphics/xfig.log http://build-failures.rhaalovely.net/arm/2022-06-19/inputmethods/uim.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/STk.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/guile2.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/hashlink.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/janet.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/moarvm.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/nekovm.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/parrot.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/racket-minimal,no_jit.log http://build-failures.rhaalovely.net/arm/2022-06-19/lang/swi-prolog.log http://build-failures.rhaalovely.net/arm/2022-06-19/mail/bogofilter,db4.log http://build-failures.rhaalovely.net/arm/2022-06-19/mail/courier-unicode.log http://build-failures.rhaalovely.net/arm/2022-06-19/math/lean.log http://build-failures.rhaalovely.net/arm/2022-06-19/math/mathomatic.log http://build-failures.rhaalovely.net/arm/2022-06-19/misc/astrolog.log http://build-failures.rhaalovely.net/arm/2022-06-19/misc/osinfo/libosinfo.log http://build-failures.rhaalovely.net/arm/2022-06-19/misc/osinfo/osinfo-db-tools.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/bro.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/minio/client.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/minio/server.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/syncthing.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/tailscale.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/tdlib.log http://build-failures.rhaalovely.net/arm/2022-06-19/net/ucspi-tools.log http://build-failures.rhaalovely.net/arm/2022-06-19/plan9/drawterm.log http://build-failures.rhaalovely.net/arm/2022-06-19/print/foo2zjs.log http://build-failures.rhaalovely.net/arm/2022-06-19/productivity/davical.log http://build-failures.rhaalovely.net/arm/2022-06-19/security/foremost.log http://build-failures.rhaalovely.net/arm/2022-06-19/sysutils/autossh.log http://build-failures.rhaalovely.net/arm/2022-06-19/sysutils/libvirt.log http://build-failures.rhaalovely.net/arm/2022-06-19/sysutils/login_krb5.log http://build-failures.rhaalovely.net/arm/2022-06-19/sysutils/rancid.log http://build-failures.rhaalovely.net/arm/2022-06-19/telephony/kamailio.log http://build-failures.rhaalovely.net/arm/2022-06-19/x11/gnustep/libobjc2.log http://build-failures.rhaalovely.net/arm/2022-06-19/x11/qt5/qtbase.log http://build-failures.rhaalovely.net/arm/2022-06-19/x11/qt6/qtbase.log recurrent failures failures/devel/ptlib.log failures/devel/remake.log failures/devel/reposurgeon.log failures/editors/micro.log failures/editors/poke.log failures/editors/zile.log failures/emulators/higan.log failures/emulators/ppsspp.log failures/emulators/spike.log
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2022/07/12 05:22:15 Modified files: www/varnish: Makefile Log message: Do not pick up GNU tools during configure Fixes sporadic build failures OK sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: de...@cvs.openbsd.org 2022/07/12 05:18:39 Modified files: sysutils/kopia : Makefile distinfo modules.inc Log message: update to v0.11.3 Changelog : https://github.com/kopia/kopia/releases/tag/v0.11.3
Re: [new] devel/libdispatch (for deadbeef)
On Sun Jul 10, 2022 at 09:54:00PM +0200, Omar Polo wrote:
> I was taking a look at deadbeef for curiosity and it seems that newer
> versions needs this Grand Central Dispatch thingy. Fortunately, an
> impavid user has already done the though work to get this working on
> OpenBSD [0], so this took just minutes to port. (thanks!)
>
> [0]: https://github.com/apple/swift-corelibs-libdispatch/pull/559
>
> (I've just added two small patches on top to drop a -O3 and -Werror)
>
> All but one test are passing!
>
> As-is this conflicts with devel/blocksruntime due to
> /usr/local/include/Block.h. FWIW the two headers are practically
> identical. Maybe this libdispatch will deprecate blocksruntime? Never
> used blocks before so I don't know.
>
> With this installed i manage to start compiling deadbeef and get until
> the linking of the deadbeef executable (which fails for other reasons
> than libdispatch.)
>
This may help us with asterisk? Of course this requires run-time tests. I
have no chance to test this. Don't shoot the messenger!
Rafael
Index: Makefile.inc
===
RCS file: /cvs/ports/telephony/asterisk/Makefile.inc,v
retrieving revision 1.13
diff -u -p -r1.13 Makefile.inc
--- Makefile.inc12 May 2022 20:51:20 - 1.13
+++ Makefile.inc12 Jul 2022 10:09:08 -
@@ -25,33 +25,14 @@ PERMIT_PACKAGE= Yes
WANTLIB-main += c crypto curl curses edit gsm iconv iksemel
WANTLIB-main += jansson m ogg portaudio pthread radcli spandsp
WANTLIB-main += sqlite3 srtp2 ssl tiff uriparser unbound uuid
-WANTLIB-main += vorbis vorbisenc vorbisfile xml2 xslt z
+WANTLIB-main += vorbis vorbisenc vorbisfile xml2 xslt z BlocksRuntime
DEBUG_PACKAGES=${BUILD_PACKAGES}
DPB_PROPERTIES=parallel
-# Asterisk requires either nested functions (gcc extension), or -fblocks
(clang).
-# However -fblocks fails:
-#
-# - configure test fails on ld.bfd arches:
-#
-#echo 'int main(){return ^{return 42;}();}' | \
-# clang -o /tmp/blockstest -fblocks -x c -L/usr/local/lib
-lBlocksRuntime -
-#
-# -> undefined reference to `_NSConcreteGlobalBlock' (also can be tested
-# on ld.lld arches by adding "-fuse-ld=bfd")
-#
-# - runtime fails on ld.lld arches: dlopen()ing the .so modules results in
-# undefined symbols from the BlocksRuntime lib (_NSConcreteStackBlock,
-# _Block_object_dispose, _Block_object_assign, etc); Asterisk appears to
-# start up but without modules loaded it is useless.
-#
-# So, as things stand, this requires building with gcc.
-#
-# If this is fixed and moved to clang, update telephony/asterisk-g729 in sync.
COMPILER= ports-gcc
-# XXX bsd.port.arch.mk is included below, before compiler.port.mk can set
-# ONLY_FOR_ARCHS
+#COMPILER= base-clang ports-gcc
+
ONLY_FOR_ARCHS=${GCC49_ARCHS}
SHARED_LIBS+= asteriskssl ${SHLIB_V}
@@ -74,6 +55,7 @@ FLAVOR+=no_vm_odbc
# MODGCC4_CPPLIBDEP is empty on a clang build.
# leave it here, don't try to conditionalize it below, dpb doesn't like that.
LIB_DEPENDS-main= ${MODGCC4_CPPLIBDEP} \
+ devel/libdispatch \
audio/gsm \
audio/libogg \
audio/libvorbis \
@@ -113,6 +95,7 @@ MODPY_RUNDEP=No
CPPFLAGS+= -I${X11BASE}/include -I${LOCALBASE}/include
LDFLAGS+= -L${X11BASE}/lib -L${LOCALBASE}/lib
+LDFLAGS+= -lBlocksRuntime
CONFIGURE_ENV+=CPPFLAGS="${CPPFLAGS}" \
CFLAGS="${CFLAGS}" \
LDFLAGS="${LDFLAGS}" \
@@ -179,20 +162,19 @@ CFLAGS += -DHAVE_OPENSSL_BIO_METHOD
.include
-#.if ${PROPERTIES:Mclang}
-#BUILD_DEPENDS += devel/blocksruntime
-#LDFLAGS +=-lBlocksRuntime
-#WANTLIB-main += ${COMPILER_LIBCXX}
-#.else
-CFLAGS += -ftrampolines
+.if ${PROPERTIES:Mclang}
+WANTLIB-main +=${COMPILER_LIBCXX}
+.else
+FLAGS += -ftrampolines
WANTLIB-main +=${MODGCC4_CPPWANTLIB}
-#.endif
+.endif
# calendar
COMMENT-calendar= calendar support for Asterisk
WANTLIB-calendar= crypto expat ical intl iksemel neon \
- proxy pthread ssl xml2 z
+ proxy pthread ssl xml2 z BlocksRuntime
LIB_DEPENDS-calendar= devel/gettext,-runtime \
+ devel/libdispatch \
net/neon \
textproc/libical
.if !${BUILD_PACKAGES:M-calendar}
@@ -202,24 +184,27 @@ CONFIGURE_ARGS+= --with-ical=no
# http_post
COMMENT-http_post= HTTP POST support for Asterisk
LIB_DEPENDS-http_post= devel/gettext,-runtime \
+ devel/libdispatch \
mail/gmime30
-WANTLIB-http_post= gio-2.0 glib-2.0 gmime-3.0 gobject-2.0 intl pthread
+WANTLIB-http_post= gio-2.0 glib-2.0 gmime-3.0 gobject-2.0
Re: aarch64 bulk build report
Ok. That problem is very unlikely to be arm64-specific.
--
Sent from a phone, apologies for poor formatting.
On 11 July 2022 13:34:46 Klemens Nanni wrote:
On Mon, Jul 11, 2022 at 01:15:09PM +0100, Stuart Henderson wrote:
On 2022/07/11 10:41, Klemens Nanni wrote:
> On Mon, Jul 11, 2022 at 04:31:13AM -0600, Peter Hessler wrote:
> > bulk build on arm64.ports.openbsd.org
> > started on Sat Jul 9 05:33:35 MDT 2022
> > finished at Mon Jul 11 04:31:02 MDT 2022
> > lasted 1D22h57m
> > done with kern.version=OpenBSD 7.1-current (GENERIC.MP) #1721: Fri Jul
8 12:28:55 MDT 2022
> >
> > built packages:11237
> > Jul 9:3998
> > Jul 10:3208
> > Jul 11:4030
> >
> >
> > critical path missing pkgs:
http://build-failures.rhaalovely.net/aarch64/2022-07-09/summary.log
> >
> > build failures: 3
> >
http://build-failures.rhaalovely.net/aarch64/2022-07-09/net/bitlbee,libpurple.log
> > http://build-failures.rhaalovely.net/aarch64/2022-07-09/www/varnish.log
>
> This looks like a fluke in this build, given that the last arm64 bulks
> had no problems with varnish 7.0.2 and nothing changed in this port.
>
> It fails to package because the files got lost?
gmake[3]: Entering directory
'/usr/obj/ports/varnish-7.0.2/build-aarch64/bin/varnishadm'
/usr/obj/ports/varnish-7.0.2/varnish-7.0.2/build-aux/install-sh -c -d
'/usr/obj/ports/varnish-7.0.2/fake-aarch64/usr/local/bin'
/bin/sh: gawk: not found
Oops.
Diff below makes it use base awk, grep, etc.
Still builds and passes tests on amd64, I can't test arm64 at the moment.
Feedback? OK?
Index: Makefile
===
RCS file: /cvs/ports/www/varnish/Makefile,v
retrieving revision 1.71
diff -u -p -r1.71 Makefile
--- Makefile11 Mar 2022 20:11:06 - 1.71
+++ Makefile11 Jul 2022 12:32:24 -
@@ -1,7 +1,7 @@
COMMENT = high-performance HTTP accelerator
DISTNAME = varnish-7.0.2
-REVISION = 0
+REVISION = 1
CATEGORIES =www
@@ -30,7 +30,7 @@ LIB_DEPENDS = devel/pcre2
USE_GMAKE = Yes
SEPARATE_BUILD =Yes
-CONFIGURE_STYLE = simple
+CONFIGURE_STYLE = gnu
CONFIGURE_ENV = CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib ${LDFLAGS}" \
PYTHON="${MODPY_BIN}"
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/07/12 00:53:39 Modified files: sysutils/dspy : Makefile distinfo sysutils/dspy/pkg: PLIST Log message: Update to dspy-1.2.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/07/12 00:48:35 Modified files: print/foomatic-db-engine: Makefile print/foomatic-db-engine/pkg: README Log message: tyop
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/07/12 00:47:07 Modified files: print/gutenprint: Makefile print/gutenprint/pkg: DESCR PLIST Log message: Enable simplified-cups-ppds. Tweak DESCR. Reload cups with cups-genppdupdate.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2022/07/12 00:44:05 Modified files: print/foomatic-db-engine: Makefile print/foomatic-db-engine/pkg: README Log message: Tweak README.
