PATCH_QUIET (was: Re: CVS: cvs.openbsd.org: ports)
Klemens Nanni: > CVSROOT: /cvs > Module name: ports > Changes by: k...@cvs.openbsd.org2024/10/06 04:24:24 > > Modified files: > infrastructure/mk: bsd.port.mk > > Log message: > new opt-in PATCH_QUIET aka. patch(1) -s; OK tb Was this discussed somewhere? We could have simply brought PATCH_DEBUG back, which was removed in rev 1.1617. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: borgbackup 1.4 (Re: CVS: cvs.openbsd.org: ports)
On Thu 04/07/2024 07:44, Matthieu Herrb wrote: > On Wed, Jul 03, 2024 at 11:14:26PM -0600, Bjorn Ketelaars wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: b...@cvs.openbsd.org2024/07/03 23:14:26 > > > > Modified files: > > sysutils/borgbackup: Makefile > > > > Log message: > > sysutils/borgbackup - hook up 1.4/ and unhook 1.2/ > > > > Hi, > > Is 1.4 compatible with 1.2 repositories or is there some constraint to > upgrade the server and clients simultaneously ? sthen@ beat me to it: - borg 1.4 will behave quite similar to borg 1.2. Repositories are compatible - tested connecting 1.2 to 1.4 in both directions
Re: borgbackup 1.4 (Re: CVS: cvs.openbsd.org: ports)
Yes repos are compatible, there's not much to worry about. https://borgbackup.readthedocs.io/en/1.4-maint/changes.html#borg-1-2-x-to-1-4-x -- Sent from a phone, apologies for poor formatting. On 4 July 2024 06:44:56 Matthieu Herrb wrote: On Wed, Jul 03, 2024 at 11:14:26PM -0600, Bjorn Ketelaars wrote: CVSROOT: /cvs Module name: ports Changes by: b...@cvs.openbsd.org 2024/07/03 23:14:26 Modified files: sysutils/borgbackup: Makefile Log message: sysutils/borgbackup - hook up 1.4/ and unhook 1.2/ Hi, Is 1.4 compatible with 1.2 repositories or is there some constraint to upgrade the server and clients simultaneously ? -- Matthieu Herrb
borgbackup 1.4 (Re: CVS: cvs.openbsd.org: ports)
On Wed, Jul 03, 2024 at 11:14:26PM -0600, Bjorn Ketelaars wrote: > CVSROOT: /cvs > Module name: ports > Changes by: b...@cvs.openbsd.org2024/07/03 23:14:26 > > Modified files: > sysutils/borgbackup: Makefile > > Log message: > sysutils/borgbackup - hook up 1.4/ and unhook 1.2/ > Hi, Is 1.4 compatible with 1.2 repositories or is there some constraint to upgrade the server and clients simultaneously ? -- Matthieu Herrb
Re: CVS: cvs.openbsd.org: ports (textproc/ripgrep)
Theo Buehler writes:
> CVSROOT: /cvs
> Module name: ports
> Changes by: t...@cvs.openbsd.org2024/04/13 18:16:34
>
> Modified files:
> textproc/ripgrep: Makefile
>
> Log message:
> drop maintainer
is it intented ?
the commit message doesn't correspond to the patch (it could happen),
and the patch is weird (does ripgrep do not depend on c, pthread and
c++abi at all ?)
Below is the diff which was commited.
--
Sebastien Marie
===
RCS file: /cvsrepo/anoncvs/cvs/ports/textproc/ripgrep/Makefile,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- ports/textproc/ripgrep/Makefile 2024/04/14 00:14:15 1.33
+++ ports/textproc/ripgrep/Makefile 2024/04/14 00:16:34 1.34
@@ -3,14 +3,12 @@
GH_ACCOUNT = BurntSushi
GH_PROJECT = ripgrep
GH_TAGNAME = 14.1.0
-REVISION = 0
+REVISION = 1
CATEGORIES = textproc sysutils
# Unlicense/MIT
PERMIT_PACKAGE = Yes
-
-WANTLIB += ${MODCARGO_WANTLIB}
MAINTAINER = Theo Buehler
Re: squid 6.4 Re: CVS: cvs.openbsd.org: ports
On 2023/10/25 10:49, Matthieu Herrb wrote: > On Sun, Oct 22, 2023 at 04:51:37AM -0600, Stuart Henderson wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: st...@cvs.openbsd.org 2023/10/22 04:51:37 > > > > Modified files: > > www/squid : Tag: OPENBSD_7_4 Makefile distinfo > > > > Log message: > > update to squid-6.4, fixes include: > > > > SQUID-2023:1 Request/Response smuggling in HTTP(S) and ICAP > > SQUID-2023:2 Multiple issues in HTTP response caching > > SQUID-2023:3 Denial of Service in HTTP Digest Authentication > > SQUID-2023:5 Denial of Service in FTP > > > > > Hi, > > After upgrading to 6.4, the squid cache at my lab is exiting on a assertion > after > a short while of running. I've tried removing the disk cache, it still > happens. > > 2023/10/25 10:45:31 kid1| Completed Validation Procedure > Validated 39 Entries > store_swap_size = 4002.00 KB > 2023/10/25 10:45:32 kid1| storeLateRelease: released 1 objects > 2023/10/25 10:45:33 kid1| FATAL: assertion failed: stmem.cc:98: "lowestOffset > () <= target_offset" > current master transaction: master108 > 2023/10/25 10:45:33| Removing PID file (/var/squid/squid.pid) > > Any idea? Known upstream but no usable fix or backout diff yet unfortunately. Am out today, will look again later.
squid 6.4 Re: CVS: cvs.openbsd.org: ports
On Sun, Oct 22, 2023 at 04:51:37AM -0600, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: ports > Changes by: st...@cvs.openbsd.org 2023/10/22 04:51:37 > > Modified files: > www/squid : Tag: OPENBSD_7_4 Makefile distinfo > > Log message: > update to squid-6.4, fixes include: > > SQUID-2023:1 Request/Response smuggling in HTTP(S) and ICAP > SQUID-2023:2 Multiple issues in HTTP response caching > SQUID-2023:3 Denial of Service in HTTP Digest Authentication > SQUID-2023:5 Denial of Service in FTP > Hi, After upgrading to 6.4, the squid cache at my lab is exiting on a assertion after a short while of running. I've tried removing the disk cache, it still happens. 2023/10/25 10:45:31 kid1| Completed Validation Procedure Validated 39 Entries store_swap_size = 4002.00 KB 2023/10/25 10:45:32 kid1| storeLateRelease: released 1 objects 2023/10/25 10:45:33 kid1| FATAL: assertion failed: stmem.cc:98: "lowestOffset () <= target_offset" current master transaction: master108 2023/10/25 10:45:33| Removing PID file (/var/squid/squid.pid) Any idea? -- Matthieu Herrb
Re: pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 8/16/2023 10:55 AM, Stuart Henderson wrote:
> On 2023/08/16 14:06, Brian Callahan wrote:
>> On 8/16/2023 9:43 AM, Stuart Henderson wrote:
>>>
>>> also, the comment about why it's using a wrong version of autoconf
>>> should have the version bumped to 2.71 (though if there's a problem
>>> with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..)
>>
>> You may want to try using autoconf-2.71. The scripts were last reconf'd
>> with 2.71, and I was the one who last reconf'd them, on an OpenBSD
>> machine. Worked fine here.
>
> It fails in a ports build with 2.71, and it fails with the bundled
> configure script.
>
> Seems that the problem is that ac_cv_prog_lex_root ("checking for
> lex output file root... lex.yy" is set by ports infrastructure in
> config.cache but that the subsequent "checking for lex library"
> depends on the file created in the ac_cv_prog_lex_root check.
>
Ah, I see the issue. Admittedly, I don't build pcc within the ports
tree, so with lex.yy not cached, things work fine.
~Brian
Re: pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 2023/08/16 14:06, Brian Callahan wrote:
> On 8/16/2023 9:43 AM, Stuart Henderson wrote:
> >
> > also, the comment about why it's using a wrong version of autoconf
> > should have the version bumped to 2.71 (though if there's a problem
> > with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..)
>
> You may want to try using autoconf-2.71. The scripts were last reconf'd
> with 2.71, and I was the one who last reconf'd them, on an OpenBSD
> machine. Worked fine here.
It fails in a ports build with 2.71, and it fails with the bundled
configure script.
Seems that the problem is that ac_cv_prog_lex_root ("checking for
lex output file root... lex.yy" is set by ports infrastructure in
config.cache but that the subsequent "checking for lex library"
depends on the file created in the ac_cv_prog_lex_root check.
[...]
checking for bison... /usr/bin/yacc
checking for flex... (cached) flex
checking for lex output file root... (cached) lex.yy
checking for lex library... cat: lex.yy.c: No such file or directory
cat: lex.yy.c: No such file or directory
cat: lex.yy.c: No such file or directory
not found
configure: WARNING: required lex library not found; giving up on flex
checking for library containing yywrap... -lfl
[...]
This issue is fixed by one or other of the two infrastructure diffs
below. I prefer the first; the 'none needed' setting feels a bit magic.
If anyone is able to add it to a bulk I'd appreciate it (I don't expect
a problem, but since the file is used for every CONFIGURE_STYLE=gnu or
autoconf in the tree, it feels safer to test first).
Index: config.site
===
RCS file: /cvs/ports/infrastructure/db/config.site,v
retrieving revision 1.31
diff -u -p -r1.31 config.site
--- config.site 31 Oct 2022 21:32:43 - 1.31
+++ config.site 16 Aug 2023 14:44:12 -
@@ -886,7 +886,6 @@ ac_cv_prog_egrep=${ac_cv_prog_egrep='gre
ac_cv_prog_f77_g=${ac_cv_prog_f77_g=yes}
ac_cv_prog_gcc=${ac_cv_prog_gcc=yes}
ac_cv_prog_have_hp2ps=${ac_cv_prog_have_hp2ps=1}
-ac_cv_prog_lex_root=${ac_cv_prog_lex_root=lex.yy}
ac_cv_prog_lex_yytext_pointer=${ac_cv_prog_lex_yytext_pointer=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
ac_cv_sizeof_char=${ac_cv_sizeof_char=1}
Index: config.site
===
RCS file: /cvs/ports/infrastructure/db/config.site,v
retrieving revision 1.31
diff -u -p -r1.31 config.site
--- config.site 31 Oct 2022 21:32:43 - 1.31
+++ config.site 16 Aug 2023 14:51:15 -
@@ -887,6 +887,7 @@ ac_cv_prog_f77_g=${ac_cv_prog_f77_g=yes}
ac_cv_prog_gcc=${ac_cv_prog_gcc=yes}
ac_cv_prog_have_hp2ps=${ac_cv_prog_have_hp2ps=1}
ac_cv_prog_lex_root=${ac_cv_prog_lex_root=lex.yy}
+ac_cv_lib_lex='none needed'
ac_cv_prog_lex_yytext_pointer=${ac_cv_prog_lex_yytext_pointer=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
ac_cv_sizeof_char=${ac_cv_sizeof_char=1}
Re: pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 8/16/2023 9:43 AM, Stuart Henderson wrote: > On 2023/08/12 20:43, Daniel Dickman wrote: >> CVSROOT: /cvs >> Module name: ports >> Changes by: dan...@cvs.openbsd.org 2023/08/12 20:43:15 >> >> Modified files: >> lang/pcc : Makefile.inc >> lang/pcc/pcc : distinfo >> lang/pcc/pcc/patches: patch-arch_powerpc_local_c >>patch-cc_cc_cc_c >> lang/pcc/pcc-libs: Makefile distinfo >> >> Log message: >> update to pcc 20230813 > > i386 fails: > > cc -O2 -pipe -Wall -Wmissing-prototypes -Wstrict-prototypes -Wshadow > -Wsign-compare -DGCC_COMPAT -DPCC_DEBUG -D_ISOC > 99_SOURCE -Dos_openbsd -Dmach_i386 -I. -I. -I../.. -I../../mip > -I../../arch/i386 -I../../os/openbsd -I../../common > -c -o code.o ../../arch/i386/code.c > ../../arch/i386/code.c:452:22: error: no member named 'ss' in 'struct attr' > if (stcall && (ap = strattr(p->n_left->n_ap)) && > ^~~~ > ./pass1.h:623:26: note: expanded from macro 'strattr' > #define strattr(x) ((x)->ss) > ~~~ ^ > 1 error generated. > > > also, the comment about why it's using a wrong version of autoconf > should have the version bumped to 2.71 (though if there's a problem > with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..) > You may want to try using autoconf-2.71. The scripts were last reconf'd with 2.71, and I was the one who last reconf'd them, on an OpenBSD machine. Worked fine here. ~Brian
pcc i386 build fails / autoconf [Re: CVS: cvs.openbsd.org: ports]
On 2023/08/12 20:43, Daniel Dickman wrote: > CVSROOT: /cvs > Module name: ports > Changes by: dan...@cvs.openbsd.org 2023/08/12 20:43:15 > > Modified files: > lang/pcc : Makefile.inc > lang/pcc/pcc : distinfo > lang/pcc/pcc/patches: patch-arch_powerpc_local_c > patch-cc_cc_cc_c > lang/pcc/pcc-libs: Makefile distinfo > > Log message: > update to pcc 20230813 i386 fails: cc -O2 -pipe -Wall -Wmissing-prototypes -Wstrict-prototypes -Wshadow -Wsign-compare -DGCC_COMPAT -DPCC_DEBUG -D_ISOC 99_SOURCE -Dos_openbsd -Dmach_i386 -I. -I. -I../.. -I../../mip -I../../arch/i386 -I../../os/openbsd -I../../common -c -o code.o ../../arch/i386/code.c ../../arch/i386/code.c:452:22: error: no member named 'ss' in 'struct attr' if (stcall && (ap = strattr(p->n_left->n_ap)) && ^~~~ ./pass1.h:623:26: note: expanded from macro 'strattr' #define strattr(x) ((x)->ss) ~~~ ^ 1 error generated. also, the comment about why it's using a wrong version of autoconf should have the version bumped to 2.71 (though if there's a problem with AC_PROG_LEX in 2.70/2.71 that should probably be fixed in autoconf..)
Re: Puppet master status [was: Re: CVS: cvs.openbsd.org: ports]
On Tuesday, January 24, 2023 12:27 CET, Giovanni Bechis wrote: > On Fri, Jan 20, 2023 at 08:59:35PM +, Sebastian Reitenbach wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: sebas...@cvs.openbsd.org2023/01/20 13:59:35 > > > > Removed files: > > sysutils/ruby-puppet/5: Makefile distinfo > > sysutils/ruby-puppet/5/patches: patch-ext_rack_config_ru > > patch-install_rb > > patch-lib_puppet_defaults_rb > > > > patch-lib_puppet_file_system_file_impl_rb > > patch-lib_puppet_gettext_config_rb > > > > patch-lib_puppet_provider_package_gem_rb > > > > patch-lib_puppet_provider_package_openbsd_rb > > > > patch-lib_puppet_provider_package_pip3_rb > > > > patch-lib_puppet_provider_package_pip_rb > > > > patch-lib_puppet_provider_service_openbsd_rb > > > > patch-lib_puppet_reference_configuration_rb > > patch-lib_puppet_util_run_mode_rb > > sysutils/ruby-puppet/5/pkg: PLIST > > > > Log message: > > bye bye puppet 5 > > > > OK jeremy@ > is puppetmaster definitely gone ? > this will need an upgrade.html entry at least. I've puppetserver 7 as replacement coming, works for /me, still needs little cleanup. Early next week it should hit ports@ Once it's in, upgrade.html entry will follow. If you feel adventurous and want to test already before: https://github.com/buzzdeee/mystuff/ you'd need sysutils/puppetserver/7 and databases/puppetdb/7 cheers, Sebastian
Puppet master status [was: Re: CVS: cvs.openbsd.org: ports]
On Fri, Jan 20, 2023 at 08:59:35PM +, Sebastian Reitenbach wrote: > CVSROOT: /cvs > Module name: ports > Changes by: sebas...@cvs.openbsd.org2023/01/20 13:59:35 > > Removed files: > sysutils/ruby-puppet/5: Makefile distinfo > sysutils/ruby-puppet/5/patches: patch-ext_rack_config_ru > patch-install_rb > patch-lib_puppet_defaults_rb > > patch-lib_puppet_file_system_file_impl_rb > patch-lib_puppet_gettext_config_rb > > patch-lib_puppet_provider_package_gem_rb > > patch-lib_puppet_provider_package_openbsd_rb > > patch-lib_puppet_provider_package_pip3_rb > > patch-lib_puppet_provider_package_pip_rb > > patch-lib_puppet_provider_service_openbsd_rb > > patch-lib_puppet_reference_configuration_rb > patch-lib_puppet_util_run_mode_rb > sysutils/ruby-puppet/5/pkg: PLIST > > Log message: > bye bye puppet 5 > > OK jeremy@ is puppetmaster definitely gone ? this will need an upgrade.html entry at least. Cheers Giovanni signature.asc Description: PGP signature
Re: CVS: cvs.openbsd.org: ports
On Tue, Mar 15, 2022 at 05:03:17PM -0400, Kurt Mosiejczuk wrote:
> On Tue, Mar 15, 2022 at 08:22:43PM +, Stuart Henderson wrote:
>
> > > It fails identically on -current.
>
> > base-gcc won't be good enough:
>
> > > util.c:3183: error: thread-local storage not supported for this target
>
> Here's a diff to switch to ports-gcc for base-gcc arches.
>
> ok?
>
> (Should also be backported to fix -stable (minus the REVISION bump) to
> fix it there.
>
ok giovanni@ portwise.
Giovanni
> --Kurt
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/apache-httpd/Makefile,v
> retrieving revision 1.114
> diff -u -p -r1.114 Makefile
> --- Makefile 14 Mar 2022 14:41:34 - 1.114
> +++ Makefile 15 Mar 2022 21:03:05 -
> @@ -3,6 +3,7 @@ COMMENT= apache HTTP server
> V= 2.4.53
> DISTNAME=httpd-${V}
> PKGNAME= apache-httpd-${V}
> +REVISION=0
>
> CATEGORIES= www net
>
> @@ -12,6 +13,9 @@ HOMEPAGE= https://httpd.apache.org/
>
> # Apache 2.0
> PERMIT_PACKAGE= Yes
> +
> +COMPILER=base-clang ports-gcc
> +COMPILER_LANGS= c
>
> WANTLIB += apr-1 aprutil-1 brotlicommon brotlienc c crypto curl
> WANTLIB += db expat iconv jansson lzma m nghttp2 pcre pthread ssl
>
signature.asc
Description: PGP signature
Re: CVS: cvs.openbsd.org: ports
On Tue, Mar 15, 2022 at 08:22:43PM +, Stuart Henderson wrote:
> > It fails identically on -current.
> base-gcc won't be good enough:
> > util.c:3183: error: thread-local storage not supported for this target
Here's a diff to switch to ports-gcc for base-gcc arches.
ok?
(Should also be backported to fix -stable (minus the REVISION bump) to
fix it there.
--Kurt
Index: Makefile
===
RCS file: /cvs/ports/www/apache-httpd/Makefile,v
retrieving revision 1.114
diff -u -p -r1.114 Makefile
--- Makefile14 Mar 2022 14:41:34 - 1.114
+++ Makefile15 Mar 2022 21:03:05 -
@@ -3,6 +3,7 @@ COMMENT=apache HTTP server
V= 2.4.53
DISTNAME= httpd-${V}
PKGNAME= apache-httpd-${V}
+REVISION= 0
CATEGORIES=www net
@@ -12,6 +13,9 @@ HOMEPAGE= https://httpd.apache.org/
# Apache 2.0
PERMIT_PACKAGE=Yes
+
+COMPILER= base-clang ports-gcc
+COMPILER_LANGS=c
WANTLIB += apr-1 aprutil-1 brotlicommon brotlienc c crypto curl
WANTLIB += db expat iconv jansson lzma m nghttp2 pcre pthread ssl
Re: sqlports on riscv64 (was: Re: CVS: cvs.openbsd.org: ports)
On 2021/10/30 18:10, Marc Espie wrote:
> I think the most reasonable solution is this:
Makes sense. We should probably rename it from MODGCC4/GCC49_ARCHS sometime!
> Index: gcc4.port.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
> retrieving revision 1.14
> diff -u -p -r1.14 gcc4.port.mk
> --- gcc4.port.mk 27 Apr 2019 21:26:35 - 1.14
> +++ gcc4.port.mk 30 Oct 2021 16:08:34 -
> @@ -1,2 +1 @@
> -MODGCC4_VERSION?=8
> .include "${PORTSDIR}/lang/gcc/${MODGCC4_VERSION}/gcc4.port.mk"
> Index: arch-defines.mk
> ===
> RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
> retrieving revision 1.85
> diff -u -p -r1.85 arch-defines.mk
> --- arch-defines.mk 21 Aug 2021 03:25:05 - 1.85
> +++ arch-defines.mk 30 Oct 2021 16:08:34 -
> @@ -40,6 +40,10 @@ LLVM_ARCHS = aarch64 amd64 arm i386 mips
> # arches where ports-gcc >4.9 exists. To be used again for modules
> GCC49_ARCHS = aarch64 alpha amd64 arm hppa i386 mips64 mips64el powerpc
> powerpc64 sparc64
>
> +# XXX put this here instead of gcc4.port.mk to simplify COMPILER handling
> +# in case we would require the gcc module but don't have it. This keeps
> +# the depends variables happy in NOT_FOR_ARCHS- ports
> +MODGCC4_VERSION?=8
> # arches where there is a C++11 compiler, either clang in base or ports-gcc
> CXX11_ARCHS = ${CLANG_ARCHS} ${GCC49_ARCHS}
> DEBUGINFO_ARCHS = aarch64 amd64
Re: sqlports on riscv64 (was: Re: CVS: cvs.openbsd.org: ports)
I think the most reasonable solution is this:
Index: gcc4.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/gcc4.port.mk,v
retrieving revision 1.14
diff -u -p -r1.14 gcc4.port.mk
--- gcc4.port.mk27 Apr 2019 21:26:35 - 1.14
+++ gcc4.port.mk30 Oct 2021 16:08:34 -
@@ -1,2 +1 @@
-MODGCC4_VERSION?=8
.include "${PORTSDIR}/lang/gcc/${MODGCC4_VERSION}/gcc4.port.mk"
Index: arch-defines.mk
===
RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
retrieving revision 1.85
diff -u -p -r1.85 arch-defines.mk
--- arch-defines.mk 21 Aug 2021 03:25:05 - 1.85
+++ arch-defines.mk 30 Oct 2021 16:08:34 -
@@ -40,6 +40,10 @@ LLVM_ARCHS = aarch64 amd64 arm i386 mips
# arches where ports-gcc >4.9 exists. To be used again for modules
GCC49_ARCHS = aarch64 alpha amd64 arm hppa i386 mips64 mips64el powerpc
powerpc64 sparc64
+# XXX put this here instead of gcc4.port.mk to simplify COMPILER handling
+# in case we would require the gcc module but don't have it. This keeps
+# the depends variables happy in NOT_FOR_ARCHS- ports
+MODGCC4_VERSION?=8
# arches where there is a C++11 compiler, either clang in base or ports-gcc
CXX11_ARCHS = ${CLANG_ARCHS} ${GCC49_ARCHS}
DEBUGINFO_ARCHS = aarch64 amd64
Re: sqlports on riscv64 (was: Re: CVS: cvs.openbsd.org: ports)
On Sat, Oct 30, 2021 at 10:45:16AM +0200, Jeremie Courreges-Anglas wrote: > On Fri, Oct 29 2021, Daniel Dickman wrote: > > So I guess ONLY FOR ARCHS didn’t help here? > > That's right. make dump-vars output is used even if the port is > disabled, so a broken RUN_DEPENDS matters. Maybe this port could > use MODULES=gcc4? > > > would never have thought about needing it here. > > > >> On Oct 29, 2021, at 5:38 PM, Jeremie Courreges-Anglas > >> wrote: > >> > >> CVSROOT:/cvs > >> Module name:ports > >> Changes by:j...@cvs.openbsd.org2021/10/29 15:37:58 > >> > >> Modified files: > >>lang/compcert : Makefile > >> > >> Log message: > >> Unbreak sqlports on archs that don't have lang/gcc support (riscv64) > >> > >> Culprit found with help from espie@ > >> > > The other thing we could do is just put MODGCC4_VERSION ?= 8 in arch.defines.mk so that this specific case doesn't break... or possibly tweak compiler.port.mk so that a port with COMPILER = ports-gcc *will* get us the gcc module, even with everything disabled.
sqlports on riscv64 (was: Re: CVS: cvs.openbsd.org: ports)
On Fri, Oct 29 2021, Daniel Dickman wrote: > So I guess ONLY FOR ARCHS didn’t help here? That's right. make dump-vars output is used even if the port is disabled, so a broken RUN_DEPENDS matters. Maybe this port could use MODULES=gcc4? > would never have thought about needing it here. > >> On Oct 29, 2021, at 5:38 PM, Jeremie Courreges-Anglas >> wrote: >> >> CVSROOT:/cvs >> Module name:ports >> Changes by:j...@cvs.openbsd.org2021/10/29 15:37:58 >> >> Modified files: >>lang/compcert : Makefile >> >> Log message: >> Unbreak sqlports on archs that don't have lang/gcc support (riscv64) >> >> Culprit found with help from espie@ >> > -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
Antoine Jacoutot wrote:
> On Wed, Oct 27, 2021 at 02:16:35PM +0100, Matthieu Herrb wrote:
> > On Mon, Jul 26, 2021 at 09:04:55AM +0200, Matthieu Herrb wrote:
> > > On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
> > > > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
> > > > > CVSROOT: /cvs
> > > > > Module name: ports
> > > > > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39
> > > > >
> > > > > Modified files:
> > > > > graphics/flameshot: Makefile distinfo
> > > > > graphics/flameshot/pkg: PLIST
> > > > > Added files:
> > > > > graphics/flameshot/patches: patch-src_CMakeLists_txt
> > > > >
> > > > > Log message:
> > > > > Update to 0.10.0
> > > > >
> > > > > Patch by Stefan Hagen
> > > > > Help and OK sthen@
> > > >
> > > > Hi,
> > > >
> > > >
> > > > Looks like this broke the .desktop file
> > > > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
> > > > It now contains:
> > > >
> > > >Exec=/usr/bin/flameshot
> > > >
> > > > Which obviously doesn't work.
> > > >
> > >
> > > Possible fix:
> >
> > Ping with updated patch.
> >
> > diff --git a/graphics/flameshot/Makefile b/graphics/flameshot/Makefile
> > index 3da3ba32700..1716eae60e3 100644
> > --- a/graphics/flameshot/Makefile
> > +++ b/graphics/flameshot/Makefile
> > @@ -6,6 +6,7 @@ CATEGORIES =graphics x11
> > GH_ACCOUNT = flameshot-org
> > GH_PROJECT = flameshot
> > GH_TAGNAME = v0.10.1
> > +REVISION = 0
> >
> > HOMEPAGE = https://flameshot.org/
> > MAINTAINER = Denis Fondras
> > @@ -26,6 +27,10 @@ RUN_DEPENDS =devel/desktop-file-utils \
> >
> > CONFIGURE_ARGS += -DENABLE_CACHE=OFF
> >
> > +post-patch:
> > + perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
> > + ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
>
> Could you do it in pre-configure and use TRUEPREFIX instead of LOCALBASE?
Ok sdk@ with ajas suggestion ^
In the next version of flameshot, this should be removed again and
replaced with
CONFIGURE_ARGS += -DENABLE_CACHE=OFF \
-DUSE_LAUNCHER_ABSOLUTE_PATH:BOOL=OFF
Because: https://github.com/flameshot-org/flameshot/pull/1775
Best regards,
Stefan
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Wed, Oct 27, 2021 at 03:33:35PM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Oct 27 2021, Antoine Jacoutot wrote:
> > On Wed, Oct 27, 2021 at 02:16:35PM +0100, Matthieu Herrb wrote:
> >> On Mon, Jul 26, 2021 at 09:04:55AM +0200, Matthieu Herrb wrote:
> >> > On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
> >> > > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
> >> > > > CVSROOT: /cvs
> >> > > > Module name: ports
> >> > > > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39
> >> > > >
> >> > > > Modified files:
> >> > > > graphics/flameshot: Makefile distinfo
> >> > > > graphics/flameshot/pkg: PLIST
> >> > > > Added files:
> >> > > > graphics/flameshot/patches: patch-src_CMakeLists_txt
> >> > > >
> >> > > > Log message:
> >> > > > Update to 0.10.0
> >> > > >
> >> > > > Patch by Stefan Hagen
> >> > > > Help and OK sthen@
> >> > >
> >> > > Hi,
> >> > >
> >> > >
> >> > > Looks like this broke the .desktop file
> >> > > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
> >> > > It now contains:
> >> > >
> >> > >Exec=/usr/bin/flameshot
> >> > >
> >> > > Which obviously doesn't work.
> >> > >
> >> >
> >> > Possible fix:
> >>
> >> Ping with updated patch.
> >>
> >> diff --git a/graphics/flameshot/Makefile b/graphics/flameshot/Makefile
> >> index 3da3ba32700..1716eae60e3 100644
> >> --- a/graphics/flameshot/Makefile
> >> +++ b/graphics/flameshot/Makefile
> >> @@ -6,6 +6,7 @@ CATEGORIES = graphics x11
> >> GH_ACCOUNT = flameshot-org
> >> GH_PROJECT = flameshot
> >> GH_TAGNAME = v0.10.1
> >> +REVISION =0
> >>
> >> HOMEPAGE =https://flameshot.org/
> >> MAINTAINER = Denis Fondras
> >> @@ -26,6 +27,10 @@ RUN_DEPENDS = devel/desktop-file-utils \
> >>
> >> CONFIGURE_ARGS += -DENABLE_CACHE=OFF
> >>
> >> +post-patch:
> >> + perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
> >> + ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
> >
> > Could you do it in pre-configure and use TRUEPREFIX instead of LOCALBASE?
>
> Didn't we decide that we shouldn't care about LOCALBASE vs TRUEPREFIX
> any more? (In Bucarest IIRC)
We never validated it and no one came up with a diff.
--
Antoine
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Wed, Oct 27 2021, Antoine Jacoutot wrote:
> On Wed, Oct 27, 2021 at 02:16:35PM +0100, Matthieu Herrb wrote:
>> On Mon, Jul 26, 2021 at 09:04:55AM +0200, Matthieu Herrb wrote:
>> > On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
>> > > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
>> > > > CVSROOT: /cvs
>> > > > Module name: ports
>> > > > Changes by:de...@cvs.openbsd.org 2021/07/16 10:47:39
>> > > >
>> > > > Modified files:
>> > > >graphics/flameshot: Makefile distinfo
>> > > >graphics/flameshot/pkg: PLIST
>> > > > Added files:
>> > > >graphics/flameshot/patches: patch-src_CMakeLists_txt
>> > > >
>> > > > Log message:
>> > > > Update to 0.10.0
>> > > >
>> > > > Patch by Stefan Hagen
>> > > > Help and OK sthen@
>> > >
>> > > Hi,
>> > >
>> > >
>> > > Looks like this broke the .desktop file
>> > > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
>> > > It now contains:
>> > >
>> > >Exec=/usr/bin/flameshot
>> > >
>> > > Which obviously doesn't work.
>> > >
>> >
>> > Possible fix:
>>
>> Ping with updated patch.
>>
>> diff --git a/graphics/flameshot/Makefile b/graphics/flameshot/Makefile
>> index 3da3ba32700..1716eae60e3 100644
>> --- a/graphics/flameshot/Makefile
>> +++ b/graphics/flameshot/Makefile
>> @@ -6,6 +6,7 @@ CATEGORIES = graphics x11
>> GH_ACCOUNT =flameshot-org
>> GH_PROJECT =flameshot
>> GH_TAGNAME =v0.10.1
>> +REVISION = 0
>>
>> HOMEPAGE = https://flameshot.org/
>> MAINTAINER =Denis Fondras
>> @@ -26,6 +27,10 @@ RUN_DEPENDS = devel/desktop-file-utils \
>>
>> CONFIGURE_ARGS += -DENABLE_CACHE=OFF
>>
>> +post-patch:
>> +perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
>> +${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
>
> Could you do it in pre-configure and use TRUEPREFIX instead of LOCALBASE?
Didn't we decide that we shouldn't care about LOCALBASE vs TRUEPREFIX
any more? (In Bucarest IIRC)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Wed, Oct 27, 2021 at 02:16:35PM +0100, Matthieu Herrb wrote:
> On Mon, Jul 26, 2021 at 09:04:55AM +0200, Matthieu Herrb wrote:
> > On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
> > > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
> > > > CVSROOT:/cvs
> > > > Module name:ports
> > > > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39
> > > >
> > > > Modified files:
> > > > graphics/flameshot: Makefile distinfo
> > > > graphics/flameshot/pkg: PLIST
> > > > Added files:
> > > > graphics/flameshot/patches: patch-src_CMakeLists_txt
> > > >
> > > > Log message:
> > > > Update to 0.10.0
> > > >
> > > > Patch by Stefan Hagen
> > > > Help and OK sthen@
> > >
> > > Hi,
> > >
> > >
> > > Looks like this broke the .desktop file
> > > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
> > > It now contains:
> > >
> > >Exec=/usr/bin/flameshot
> > >
> > > Which obviously doesn't work.
> > >
> >
> > Possible fix:
>
> Ping with updated patch.
>
> diff --git a/graphics/flameshot/Makefile b/graphics/flameshot/Makefile
> index 3da3ba32700..1716eae60e3 100644
> --- a/graphics/flameshot/Makefile
> +++ b/graphics/flameshot/Makefile
> @@ -6,6 +6,7 @@ CATEGORIES = graphics x11
> GH_ACCOUNT = flameshot-org
> GH_PROJECT = flameshot
> GH_TAGNAME = v0.10.1
> +REVISION = 0
>
> HOMEPAGE = https://flameshot.org/
> MAINTAINER = Denis Fondras
> @@ -26,6 +27,10 @@ RUN_DEPENDS = devel/desktop-file-utils \
>
> CONFIGURE_ARGS +=-DENABLE_CACHE=OFF
>
> +post-patch:
> + perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
> + ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
Could you do it in pre-configure and use TRUEPREFIX instead of LOCALBASE?
--
Antoine
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Wed, Oct 27 2021, Matthieu Herrb wrote:
> On Mon, Jul 26, 2021 at 09:04:55AM +0200, Matthieu Herrb wrote:
>> On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
>> > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
>> > > CVSROOT: /cvs
>> > > Module name: ports
>> > > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39
>> > >
>> > > Modified files:
>> > > graphics/flameshot: Makefile distinfo
>> > > graphics/flameshot/pkg: PLIST
>> > > Added files:
>> > > graphics/flameshot/patches: patch-src_CMakeLists_txt
>> > >
>> > > Log message:
>> > > Update to 0.10.0
>> > >
>> > > Patch by Stefan Hagen
>> > > Help and OK sthen@
>> >
>> > Hi,
>> >
>> >
>> > Looks like this broke the .desktop file
>> > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
>> > It now contains:
>> >
>> >Exec=/usr/bin/flameshot
>> >
>> > Which obviously doesn't work.
>> >
>>
>> Possible fix:
>
> Ping with updated patch.
ok jca@
> diff --git a/graphics/flameshot/Makefile b/graphics/flameshot/Makefile
> index 3da3ba32700..1716eae60e3 100644
> --- a/graphics/flameshot/Makefile
> +++ b/graphics/flameshot/Makefile
> @@ -6,6 +6,7 @@ CATEGORIES = graphics x11
> GH_ACCOUNT = flameshot-org
> GH_PROJECT = flameshot
> GH_TAGNAME = v0.10.1
> +REVISION = 0
>
> HOMEPAGE = https://flameshot.org/
> MAINTAINER = Denis Fondras
> @@ -26,6 +27,10 @@ RUN_DEPENDS = devel/desktop-file-utils \
>
> CONFIGURE_ARGS +=-DENABLE_CACHE=OFF
>
> +post-patch:
> + perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
> + ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
> +
> NO_TEST =Yes
>
> .include
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Mon, Jul 26, 2021 at 09:04:55AM +0200, Matthieu Herrb wrote:
> On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
> > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
> > > CVSROOT: /cvs
> > > Module name: ports
> > > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39
> > >
> > > Modified files:
> > > graphics/flameshot: Makefile distinfo
> > > graphics/flameshot/pkg: PLIST
> > > Added files:
> > > graphics/flameshot/patches: patch-src_CMakeLists_txt
> > >
> > > Log message:
> > > Update to 0.10.0
> > >
> > > Patch by Stefan Hagen
> > > Help and OK sthen@
> >
> > Hi,
> >
> >
> > Looks like this broke the .desktop file
> > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
> > It now contains:
> >
> >Exec=/usr/bin/flameshot
> >
> > Which obviously doesn't work.
> >
>
> Possible fix:
Ping with updated patch.
diff --git a/graphics/flameshot/Makefile b/graphics/flameshot/Makefile
index 3da3ba32700..1716eae60e3 100644
--- a/graphics/flameshot/Makefile
+++ b/graphics/flameshot/Makefile
@@ -6,6 +6,7 @@ CATEGORIES =graphics x11
GH_ACCOUNT = flameshot-org
GH_PROJECT = flameshot
GH_TAGNAME = v0.10.1
+REVISION = 0
HOMEPAGE = https://flameshot.org/
MAINTAINER = Denis Fondras
@@ -26,6 +27,10 @@ RUN_DEPENDS =devel/desktop-file-utils \
CONFIGURE_ARGS += -DENABLE_CACHE=OFF
+post-patch:
+ perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
+ ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
+
NO_TEST = Yes
.include
--
Matthieu Herrb
Re: CVS: cvs.openbsd.org: ports
Stuart Henderson writes: > On 2021/08/27 10:32, Aaron Bieber wrote: >> CVSROOT: /cvs >> Module name: ports >> Changes by: abie...@cvs.openbsd.org 2021/08/27 10:32:06 >> >> Log message: >> Import tailscale: an overlay-like VPN built on top of WireGuard >> >> OK tracey, sthen >> >> Status: >> >> Vendor Tag: abieber >> Release Tags:abieber_20210827 >> >> N ports/net/tailscale/Makefile >> N ports/net/tailscale/distinfo >> N ports/net/tailscale/modules.inc >> N ports/net/tailscale/pkg/DESCR >> N ports/net/tailscale/pkg/PLIST >> N ports/net/tailscale/pkg/tailscaled.rc >> >> No conflicts created by this import >> > > As things stand, this doesn't build on i386: > > # golang.zx2c4.com/wireguard/ipc > ../go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20210624150102-15b24b6179e0/ipc/uapi_unix.go:21:29: > undefined: unix.EP > ROTO I am looking into getting Go's x/sys/unix package synced up with OpenBSD 6.9. I'll be sure to include an update for all the supported arches. Once that bit is in, Ill send an update to wireguard-go's upstream.
Re: CVS: cvs.openbsd.org: ports
On 2021/08/27 10:32, Aaron Bieber wrote: > CVSROOT: /cvs > Module name: ports > Changes by: abie...@cvs.openbsd.org 2021/08/27 10:32:06 > > Log message: > Import tailscale: an overlay-like VPN built on top of WireGuard > > OK tracey, sthen > > Status: > > Vendor Tag: abieber > Release Tags: abieber_20210827 > > N ports/net/tailscale/Makefile > N ports/net/tailscale/distinfo > N ports/net/tailscale/modules.inc > N ports/net/tailscale/pkg/DESCR > N ports/net/tailscale/pkg/PLIST > N ports/net/tailscale/pkg/tailscaled.rc > > No conflicts created by this import > As things stand, this doesn't build on i386: # golang.zx2c4.com/wireguard/ipc ../go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20210624150102-15b24b6179e0/ipc/uapi_unix.go:21:29: undefined: unix.EP ROTO
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
Matthieu Herrb wrote: > On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote: >> On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote: >>> CVSROOT:/cvs >>> Module name:ports >>> Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39 >>> >>> Modified files: >>> graphics/flameshot: Makefile distinfo >>> graphics/flameshot/pkg: PLIST >>> Added files: >>> graphics/flameshot/patches: patch-src_CMakeLists_txt >>> >>> Log message: >>> Update to 0.10.0 >>> >>> Patch by Stefan Hagen >>> Help and OK sthen@ >> >> It now contains: >> >>Exec=/usr/bin/flameshot >> >> Which obviously doesn't work. I asked upstream to change it: https://github.com/flameshot-org/flameshot/issues/1766 This is wrong for other systems too. We're not the only ones installing to /usr/local. Best Regards, Stefan
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Mon, Jul 26, 2021 at 01:08:32PM +0200, Antoine Jacoutot wrote: > Why not use sed instead of Perl? People are still stunned we finally got non standard sed -i :)
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
Why not use sed instead of Perl?
—
Antoine
> On 26 Jul 2021, at 11:06, Charlene Wendling wrote:
>
> On Mon, 26 Jul 2021 09:04:47 +0200
> Matthieu Herrb wrote:
>
>>> On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
>>> On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
CVSROOT:/cvs
Module name:ports
Changes by:de...@cvs.openbsd.org2021/07/16
10:47:39
Modified files:
graphics/flameshot: Makefile distinfo
graphics/flameshot/pkg: PLIST
Added files:
graphics/flameshot/patches: patch-src_CMakeLists_txt
Log message:
Update to 0.10.0
Patch by Stefan Hagen
Help and OK sthen@
>>>
>>> Hi,
>>>
>>>
>>> Looks like this broke the .desktop file
>>> (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
>>> It now contains:
>>>
>>> Exec=/usr/bin/flameshot
>>>
>>> Which obviously doesn't work.
>>>
>>
>> Possible fix:
>>
>> Index: Makefile
>> ===
>> RCS file: /cvs/OpenBSD/ports/graphics/flameshot/Makefile,v
>> retrieving revision 1.5
>> diff -u -p -u -r1.5 Makefile
>> --- Makefile16 Jul 2021 16:47:38 -1.5
>> +++ Makefile26 Jul 2021 05:41:37 -
>> @@ -1,6 +1,7 @@
>> # $OpenBSD: Makefile,v 1.5 2021/07/16 16:47:38 denis Exp $
>>
>> COMMENT =powerful yet simple to use screenshot software
>> +REVISION =0
>> CATEGORIES =graphics x11
>>
>> GH_ACCOUNT =flameshot-org
>> @@ -25,6 +26,10 @@ RUN_DEPENDS =devel/desktop-file-utils \
>>x11/gtk+3,-guic
>>
>> CONFIGURE_ARGS +=-DENABLE_CACHE=OFF
>> +
>> +post-patch:
>> +perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
>> +$
>> {WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
>> NO_TEST =Yes
>>
>>
>> --
>> Matthieu Herrb
>>
>
> By the way, while running configure i hit this:
>
> -- Found Git: /usr/local/bin/git (found version "2.32.0")
> git found: /usr/local/bin/git in version 2.32.0
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
> FLAMESHOT_GIT_HASH:
>
> I have disabled git for the build in the below diff.
>
> I don't know if using ${SUBST_CMD} with a patched .desktop file is
> preferable or not (i would have done it that way).
>
> OK cwen@ either way.
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/graphics/flameshot/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 Makefile
> --- Makefile16 Jul 2021 16:47:38 -1.5
> +++ Makefile26 Jul 2021 08:54:25 -
> @@ -1,6 +1,7 @@
> # $OpenBSD: Makefile,v 1.5 2021/07/16 16:47:38 denis Exp $
>
> COMMENT =powerful yet simple to use screenshot software
> +REVISION =0
> CATEGORIES =graphics x11
>
> GH_ACCOUNT =flameshot-org
> @@ -24,7 +25,12 @@ LIB_DEPENDS =x11/qt5/qtsvg
> RUN_DEPENDS =devel/desktop-file-utils \
>x11/gtk+3,-guic
>
> -CONFIGURE_ARGS +=-DENABLE_CACHE=OFF
> +CONFIGURE_ARGS +=-DENABLE_CACHE=OFF \
> +-DCMAKE_DISABLE_FIND_PACKAGE_Git=TRUE
> +
> +post-patch:
> +perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
> +${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
>
> NO_TEST =Yes
>
>
>
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Mon, 26 Jul 2021 09:04:47 +0200
Matthieu Herrb wrote:
> On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
> > On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
> > > CVSROOT: /cvs
> > > Module name: ports
> > > Changes by: de...@cvs.openbsd.org 2021/07/16
> > > 10:47:39
> > >
> > > Modified files:
> > > graphics/flameshot: Makefile distinfo
> > > graphics/flameshot/pkg: PLIST
> > > Added files:
> > > graphics/flameshot/patches: patch-src_CMakeLists_txt
> > >
> > > Log message:
> > > Update to 0.10.0
> > >
> > > Patch by Stefan Hagen
> > > Help and OK sthen@
> >
> > Hi,
> >
> >
> > Looks like this broke the .desktop file
> > (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
> > It now contains:
> >
> >Exec=/usr/bin/flameshot
> >
> > Which obviously doesn't work.
> >
>
> Possible fix:
>
> Index: Makefile
> ===
> RCS file: /cvs/OpenBSD/ports/graphics/flameshot/Makefile,v
> retrieving revision 1.5
> diff -u -p -u -r1.5 Makefile
> --- Makefile 16 Jul 2021 16:47:38 - 1.5
> +++ Makefile 26 Jul 2021 05:41:37 -
> @@ -1,6 +1,7 @@
> # $OpenBSD: Makefile,v 1.5 2021/07/16 16:47:38 denis Exp $
>
> COMMENT =powerful yet simple to use screenshot software
> +REVISION = 0
> CATEGORIES = graphics x11
>
> GH_ACCOUNT = flameshot-org
> @@ -25,6 +26,10 @@ RUN_DEPENDS = devel/desktop-file-utils \
> x11/gtk+3,-guic
>
> CONFIGURE_ARGS +=-DENABLE_CACHE=OFF
> +
> +post-patch:
> + perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
> + $
> {WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
> NO_TEST =Yes
>
>
> --
> Matthieu Herrb
>
By the way, while running configure i hit this:
-- Found Git: /usr/local/bin/git (found version "2.32.0")
git found: /usr/local/bin/git in version 2.32.0
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).
FLAMESHOT_GIT_HASH:
I have disabled git for the build in the below diff.
I don't know if using ${SUBST_CMD} with a patched .desktop file is
preferable or not (i would have done it that way).
OK cwen@ either way.
Index: Makefile
===
RCS file: /cvs/ports/graphics/flameshot/Makefile,v
retrieving revision 1.5
diff -u -p -u -p -r1.5 Makefile
--- Makefile16 Jul 2021 16:47:38 - 1.5
+++ Makefile26 Jul 2021 08:54:25 -
@@ -1,6 +1,7 @@
# $OpenBSD: Makefile,v 1.5 2021/07/16 16:47:38 denis Exp $
COMMENT = powerful yet simple to use screenshot software
+REVISION = 0
CATEGORIES = graphics x11
GH_ACCOUNT = flameshot-org
@@ -24,7 +25,12 @@ LIB_DEPENDS =x11/qt5/qtsvg
RUN_DEPENDS = devel/desktop-file-utils \
x11/gtk+3,-guic
-CONFIGURE_ARGS += -DENABLE_CACHE=OFF
+CONFIGURE_ARGS += -DENABLE_CACHE=OFF \
+ -DCMAKE_DISABLE_FIND_PACKAGE_Git=TRUE
+
+post-patch:
+ perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
+ ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
NO_TEST = Yes
Re: flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Sun, Jul 25, 2021 at 06:16:05PM +0200, Matthieu Herrb wrote:
> On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39
> >
> > Modified files:
> > graphics/flameshot: Makefile distinfo
> > graphics/flameshot/pkg: PLIST
> > Added files:
> > graphics/flameshot/patches: patch-src_CMakeLists_txt
> >
> > Log message:
> > Update to 0.10.0
> >
> > Patch by Stefan Hagen
> > Help and OK sthen@
>
> Hi,
>
>
> Looks like this broke the .desktop file
> (/usr/local/share/applications/org.flameshot.Flameshot.desktop).
> It now contains:
>
>Exec=/usr/bin/flameshot
>
> Which obviously doesn't work.
>
Possible fix:
Index: Makefile
===
RCS file: /cvs/OpenBSD/ports/graphics/flameshot/Makefile,v
retrieving revision 1.5
diff -u -p -u -r1.5 Makefile
--- Makefile16 Jul 2021 16:47:38 - 1.5
+++ Makefile26 Jul 2021 05:41:37 -
@@ -1,6 +1,7 @@
# $OpenBSD: Makefile,v 1.5 2021/07/16 16:47:38 denis Exp $
COMMENT = powerful yet simple to use screenshot software
+REVISION = 0
CATEGORIES = graphics x11
GH_ACCOUNT = flameshot-org
@@ -25,6 +26,10 @@ RUN_DEPENDS =devel/desktop-file-utils \
x11/gtk+3,-guic
CONFIGURE_ARGS += -DENABLE_CACHE=OFF
+
+post-patch:
+ perl -pi -e 's,/usr/bin/,${LOCALBASE}/bin/,' \
+ ${WRKSRC}/data/desktopEntry/package/org.flameshot.Flameshot.desktop
NO_TEST = Yes
--
Matthieu Herrb
flameshot 0.10 broken .desktop (Re: CVS: cvs.openbsd.org: ports)
On Fri, Jul 16, 2021 at 10:47:39AM -0600, Denis Fondras wrote: > CVSROOT: /cvs > Module name: ports > Changes by: de...@cvs.openbsd.org 2021/07/16 10:47:39 > > Modified files: > graphics/flameshot: Makefile distinfo > graphics/flameshot/pkg: PLIST > Added files: > graphics/flameshot/patches: patch-src_CMakeLists_txt > > Log message: > Update to 0.10.0 > > Patch by Stefan Hagen > Help and OK sthen@ Hi, Looks like this broke the .desktop file (/usr/local/share/applications/org.flameshot.Flameshot.desktop). It now contains: Exec=/usr/bin/flameshot Which obviously doesn't work. -- Matthieu Herrb
Re: x11/gtk+2: print to lpr (was: Re: CVS: cvs.openbsd.org: ports)
Landry Breuil: > i think print/gtklp can be used to test it.. That appears to require a running CUPS server. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: x11/gtk+2: print to lpr (was: Re: CVS: cvs.openbsd.org: ports)
On Mon, Dec 07, 2020 at 10:25:04AM +0100, Antoine Jacoutot wrote: > On Sun, Dec 06, 2020 at 09:30:02PM +0100, Christian Weisgerber wrote: > > Antoine Jacoutot: > > > > > CVSROOT: /cvs > > > Module name: ports > > > Changes by: ajacou...@cvs.openbsd.org 2020/12/06 02:00:22 > > > > > > Modified files: > > > x11/gtk+3 : Makefile distinfo > > > x11/gtk+3/pkg : PLIST-main > > > > > > Log message: > > > Update to gtk+3-3.24.24. > > > Amongst other changes: > > > - Allow the lpr backend to print pdf and ps files > > > > Should we port this change back to x11/gtk+2? I seem to remember > > that it affected GTK+2 too, back when Mozilla still used it. > > I don't know an actual GTK+2 application to test it on now, though. > > Yes I think it's worth backporting it. > We still have lots of gtk+2 apps in tree. i think print/gtklp can be used to test it.. Landry
Re: x11/gtk+2: print to lpr (was: Re: CVS: cvs.openbsd.org: ports)
On Sun, Dec 06, 2020 at 09:30:02PM +0100, Christian Weisgerber wrote:
> Antoine Jacoutot:
>
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: ajacou...@cvs.openbsd.org 2020/12/06 02:00:22
> >
> > Modified files:
> > x11/gtk+3 : Makefile distinfo
> > x11/gtk+3/pkg : PLIST-main
> >
> > Log message:
> > Update to gtk+3-3.24.24.
> > Amongst other changes:
> > - Allow the lpr backend to print pdf and ps files
>
> Should we port this change back to x11/gtk+2? I seem to remember
> that it affected GTK+2 too, back when Mozilla still used it.
> I don't know an actual GTK+2 application to test it on now, though.
Yes I think it's worth backporting it.
We still have lots of gtk+2 apps in tree.
ok aja
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/gtk+2/Makefile,v
> retrieving revision 1.236
> diff -u -p -r1.236 Makefile
> --- Makefile 11 Nov 2020 11:49:55 - 1.236
> +++ Makefile 6 Dec 2020 20:27:55 -
> @@ -11,7 +11,7 @@ GNOME_PROJECT= gtk+
> PKGNAME-main=gtk+2-${GNOME_VERSION}
> PKGNAME-cups=gtk+2-cups-${GNOME_VERSION}
>
> -REVISION-main= 10
> +REVISION-main= 11
> REVISION-cups= 4
>
> CATEGORIES= x11 devel
> Index: patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
> ===
> RCS file: patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
> diff -N patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c 6 Dec
> 2020 20:27:55 -
> @@ -0,0 +1,25 @@
> +$OpenBSD$
> +
> +Allow attempts to print PDF and PS files using the LPR backend.
> +https://gitlab.gnome.org/GNOME/gtk/-/commit/8d5357ee56b1d34fe14346ed15004f9e4d571594
> +
> +Index: modules/printbackends/lpr/gtkprintbackendlpr.c
> +--- modules/printbackends/lpr/gtkprintbackendlpr.c.orig
> modules/printbackends/lpr/gtkprintbackendlpr.c
> +@@ -392,9 +392,13 @@ gtk_print_backend_lpr_init (GtkPrintBackendLpr *backen
> + {
> + GtkPrinter *printer;
> +
> +- printer = gtk_printer_new (_("Print to LPR"),
> +- GTK_PRINT_BACKEND (backend),
> +- TRUE);
> ++ printer = g_object_new (GTK_TYPE_PRINTER,
> ++ "name", _("Print to LPR"),
> ++ "backend", backend,
> ++ "is-virtual", FALSE,
> ++ "accepts-pdf", TRUE,
> ++ "accepts-ps", TRUE,
> ++ NULL);
> + gtk_printer_set_has_details (printer, TRUE);
> + gtk_printer_set_icon_name (printer, "gtk-print");
> + gtk_printer_set_is_active (printer, TRUE);
> --
> Christian "naddy" Weisgerber na...@mips.inka.de
>
--
Antoine
x11/gtk+2: print to lpr (was: Re: CVS: cvs.openbsd.org: ports)
Antoine Jacoutot:
> CVSROOT: /cvs
> Module name: ports
> Changes by: ajacou...@cvs.openbsd.org 2020/12/06 02:00:22
>
> Modified files:
> x11/gtk+3 : Makefile distinfo
> x11/gtk+3/pkg : PLIST-main
>
> Log message:
> Update to gtk+3-3.24.24.
> Amongst other changes:
> - Allow the lpr backend to print pdf and ps files
Should we port this change back to x11/gtk+2? I seem to remember
that it affected GTK+2 too, back when Mozilla still used it.
I don't know an actual GTK+2 application to test it on now, though.
Index: Makefile
===
RCS file: /cvs/ports/x11/gtk+2/Makefile,v
retrieving revision 1.236
diff -u -p -r1.236 Makefile
--- Makefile11 Nov 2020 11:49:55 - 1.236
+++ Makefile6 Dec 2020 20:27:55 -
@@ -11,7 +11,7 @@ GNOME_PROJECT=gtk+
PKGNAME-main= gtk+2-${GNOME_VERSION}
PKGNAME-cups= gtk+2-cups-${GNOME_VERSION}
-REVISION-main= 10
+REVISION-main= 11
REVISION-cups= 4
CATEGORIES=x11 devel
Index: patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
===
RCS file: patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
diff -N patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-modules_printbackends_lpr_gtkprintbackendlpr_c6 Dec
2020 20:27:55 -
@@ -0,0 +1,25 @@
+$OpenBSD$
+
+Allow attempts to print PDF and PS files using the LPR backend.
+https://gitlab.gnome.org/GNOME/gtk/-/commit/8d5357ee56b1d34fe14346ed15004f9e4d571594
+
+Index: modules/printbackends/lpr/gtkprintbackendlpr.c
+--- modules/printbackends/lpr/gtkprintbackendlpr.c.orig
modules/printbackends/lpr/gtkprintbackendlpr.c
+@@ -392,9 +392,13 @@ gtk_print_backend_lpr_init (GtkPrintBackendLpr *backen
+ {
+ GtkPrinter *printer;
+
+- printer = gtk_printer_new (_("Print to LPR"),
+- GTK_PRINT_BACKEND (backend),
+- TRUE);
++ printer = g_object_new (GTK_TYPE_PRINTER,
++"name", _("Print to LPR"),
++"backend", backend,
++"is-virtual", FALSE,
++"accepts-pdf", TRUE,
++"accepts-ps", TRUE,
++NULL);
+ gtk_printer_set_has_details (printer, TRUE);
+ gtk_printer_set_icon_name (printer, "gtk-print");
+ gtk_printer_set_is_active (printer, TRUE);
--
Christian "naddy" Weisgerber na...@mips.inka.de
Re: dovecot 2.3.11.3 - vfprintf messages (was: Re: CVS: cvs.openbsd.org: ports)
On 2020/08/13 12:51, Mark Patruck wrote: > Anyone else seeing these lines filling up /var/log/messages after updating > to dovecot 2.3.11.3 > > lmtp: vfprintf %s NULL in "Cache %s: " Ah, yes I am. I've reported it here: https://dovecot.org/pipermail/dovecot/2020-August/119645.html
dovecot 2.3.11.3 - vfprintf messages (was: Re: CVS: cvs.openbsd.org: ports)
Anyone else seeing these lines filling up /var/log/messages after updating to dovecot 2.3.11.3 lmtp: vfprintf %s NULL in "Cache %s: " On 2020-08-12 17:21, Stuart Henderson wrote: CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2020/08/12 09:21:11 Modified files: mail/dovecot : Makefile distinfo mail/dovecot/patches: patch-doc_example-config_Makefile_in patch-doc_example-config_conf_d_Makefile_in mail/dovecot/pkg: PLIST-server Log message: update to Dovecot 2.3.11.3, ok Brad (maintainer) includes some crash fixes, see https://github.com/dovecot/core/blob/2.3.11.3/NEWS -- Mark Patruck ( mark at wrapped.cx ) GPG key 0xF2865E51 / 187F F6D3 EE04 1DCE 1C74 F644 0D3C F66F F286 5E51 https://www.wrapped.cx
lang/haxe (was: Re: CVS: cvs.openbsd.org: ports)
Thomas Frohwein: > It looks like this is because the bundled OCaml deps in > ocamldeps/extlib contain binary-compiled parts in the .cmx files [1]. > My bad, I thought this was only interpreted code. > > I propose either setting the port to ONLY_FOR_ARCHS=amd64 as in the > diff below, or BROKEN until I've found a better way to address this. It failed to build on amd64, too. >>> Building on localhost under lang/haxe BDEPENDS = [devel/gmake;devel/boehm-gc;lang/ocaml;lang/nekovm;sysutils/findlib;devel/pcre;devel/ocaml-ocamlbuild;archivers/xz;lang/ocaml-camlp5] DIST = [lang/haxe:haxe-4.0.5.tar.xz] FULLPKGNAME = haxe-4.0.5 RDEPENDS = [devel/pcre;devel/boehm-gc;lang/ocaml;lang/nekovm] (Junk lock failure for localhost at 1579426953.84286) Received IO (Junk lock obtained for localhost at 1579426953.87) Received IO Woken up lang/haxe Woken up lang/haxe >>> Running depends in lang/haxe at 1579426954.88 last junk was in x11/kde4/kimono /usr/sbin/pkg_add -aI -Drepair boehm-gc-7.6.0p4 findlib-1.8.1p1 gmake-4.2.1p4 nekovm-2.3.0p0 ocaml-4.09.0 ocaml-camlp5-7.08p1 ocamlbuild-0.14.0p1 pcre-8.41p2 was: /usr/sbin/pkg_add -aI -Drepair boehm-gc-7.6.0p4 findlib-1.8.1p1 gmake-4.2.1p4 nekovm-2.3.0p0 ocaml-4.09.0 ocaml-camlp5-7.08p1 ocamlbuild-0.14.0p1 pcre-8.41p2 xz-5.2.4 /usr/sbin/pkg_add -aI -Drepair boehm-gc-7.6.0p4 findlib-1.8.1p1 gmake-4.2.1p4 nekovm-2.3.0p0 ocaml-4.09.0 ocaml-camlp5-7.08p1 ocamlbuild-0.14.0p1 pcre-8.41p2 >>> Running show-prepare-results in lang/haxe at 1579426970.07 ===> lang/haxe ===> haxe-4.0.5 depends on: ocamlbuild-* -> ocamlbuild-0.14.0p1 ===> haxe-4.0.5 depends on: nekovm-* -> nekovm-2.3.0p0 ===> haxe-4.0.5 depends on: ocaml-camlp5-* -> ocaml-camlp5-7.08p1 ===> haxe-4.0.5 depends on: findlib-* -> findlib-1.8.1p1 ===> haxe-4.0.5 depends on: ocaml-=4.09.0 -> ocaml-4.09.0 ===> haxe-4.0.5 depends on: gmake-* -> gmake-4.2.1p4 ===> haxe-4.0.5 depends on: xz-* -> xz-5.2.4 ===> haxe-4.0.5 depends on: boehm-gc-* -> boehm-gc-7.6.0p4 ===> haxe-4.0.5 depends on: pcre-* -> pcre-8.41p2 ===> Verifying specs: c gc m neko pcre pthread z ===> found c.96.0 gc.4.0 m.10.1 neko.0.0 pcre.3.0 pthread.26.1 z.5.0 boehm-gc-7.6.0p4 findlib-1.8.1p1 gmake-4.2.1p4 nekovm-2.3.0p0 ocaml-4.09.0 ocaml-camlp5-7.08p1 ocamlbuild-0.14.0p1 pcre-8.41p2 xz-5.2.4 (Junk lock released for localhost at 1579426971.67) distfiles size=38784960 >>> Running patch in lang/haxe at 1579426971.73 ===> lang/haxe ===> Checking files for haxe-4.0.5 `/usr/ports/distfiles/haxe-4.0.5.tar.xz' is up to date. >> (SHA256) haxe-4.0.5.tar.xz: OK ===> Extracting for haxe-4.0.5 ===> Patching for haxe-4.0.5 ===> Applying OpenBSD patch patch-libs_extc_process_stubs_c Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-libs_extc_process_stubs_c,v 1.1.1.1 2020/01/18 00:31:05 thfr Exp $ | |Index: libs/extc/process_stubs.c |--- libs/extc/process_stubs.c.orig |+++ libs/extc/process_stubs.c -- Patching file libs/extc/process_stubs.c using Plan A... Hunk #1 succeeded at 37. done ===> Applying OpenBSD patch patch-libs_extlib-leftovers_uTF8_ml Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-libs_extlib-leftovers_uTF8_ml,v 1.1.1.1 2020/01/18 00:31:05 thfr Exp $ | |Index: libs/extlib-leftovers/uTF8.ml |--- libs/extlib-leftovers/uTF8.ml.orig |+++ libs/extlib-leftovers/uTF8.ml -- Patching file libs/extlib-leftovers/uTF8.ml using Plan A... Hunk #1 succeeded at 177. done ===> Applying OpenBSD patch patch-src_compiler_main_ml Hmm... Looks like a unified diff to me... The text leading up to this was: -- |$OpenBSD: patch-src_compiler_main_ml,v 1.1.1.1 2020/01/18 00:31:05 thfr Exp $ | |path to hashlink version | |Index: src/compiler/main.ml |--- src/compiler/main.ml.orig |+++ src/compiler/main.ml -- Patching file src/compiler/main.ml using Plan A... Hunk #1 succeeded at 273. done ===> Compiler link: clang -> /usr/bin/clang ===> Compiler link: clang++ -> /usr/bin/clang++ ===> Compiler link: cc -> /usr/bin/cc ===> Compiler link: c++ -> /usr/bin/c++ >>> Running configure in lang/haxe at 1579426979.93 ===> lang/haxe ===> Generating configure for haxe-4.0.5 /usr/bin/perl /usr/ports/infrastructure/bin/pkg_subst -DARCH=amd64 -DBASE_PKGPATH=lang/haxe -DFLAVOR_EXT= -DFULLPKGNAME=haxe-4.0.5 -DHOMEPAGE=https://haxe.org -DLOCALBASE=/usr/local -DLOCALSTATEDIR=/var -DMACHINE_ARCH=amd64 -DMAINTAINER=Thomas\ Frohwein\ \ -DPREFIX=/usr/local -DRCDIR=/etc/rc.d -DSYSCONFDIR=/etc -DTRUEPREFIX=/usr/local -DX11BASE=/usr/X11R6 -DPKGSTEM=haxe -i -B /usr/obj/ports/haxe-4.0.5 /usr/obj/ports/haxe-4.0.5/haxe-4.0.5/src/compiler/main.ml ===> Configuring for haxe-4.0.5 >>> Running build in lang/haxe at 1579426980.43 ===> lang/haxe ===> Building
Re: poppler/cmake cannot find libpoppler-glib.so.8.15.0 [Re: CVS: cvs.openbsd.org: ports]
On 2019/11/22 20:16, Matthias Kilian wrote:
> Hi,
>
> On Fri, Nov 22, 2019 at 10:20:17AM +, Stuart Henderson wrote:
> > I have built 0.82.0 successfully before, but on my last build I had this:
> >
> >
> > -- Set runtime path of
> > "/pobj/poppler-0.82.0/fake-i386/usr/local/bin/pdfunite" to ""
> > -- Installing: /pobj/poppler-0.82.0/fake-i386/usr/local/man/man1/pdfunite.1
> > CMake Error at glib/cmake_install.cmake:52 (file):
> > file INSTALL cannot find
> > "/pobj/poppler-0.82.0/build-i386/glib/libpoppler-glib.so.8.15.0".
> > Call Stack (most recent call first):
> > cmake_install.cmake:245 (include)
> >
> >
> > FAILED: CMakeFiles/install.util
> > cd /pobj/poppler-0.82.0/build-i386 && /usr/local/bin/cmake -P
> > cmake_install.cmake
> > ninja: build stopped: subcommand failed.
>
> IIRC, naddy@ had the same problem with an older version of poppler,
> where the cmake suddenly decided to use the upstream shared lib
> version of libpoppler-glib.so instead of what the port sets (here:
> 8.15.0 instead of 19.4).
>
> glib/CMakeLists.txt has:
>
> set_target_properties(poppler-glib PROPERTIES VERSION 8.15.0 SOVERSION 8)
>
> while the port has:
>
> SHARED_LIBS += poppler-glib 19.4 # 8.15
>
> > $ ls -l /pobj/poppler-0.82.0/build-i386/glib
> [...]
> > -rw-r--r-- 1 _pbuild _pbuild3925 Nov 21 20:27 cmake_install.cmake
> [...]
>
> I'm not that cmake expert, but I'd like to have a look at that file,
> and probably compare it with a version from a successfull build. I don't
> think I need the full build directory.
>
> Ciao,
> Kili
>
You're onto something there. cmake_install.cmake diff below; "-" lines
are from the failed build, "+" lines from the working one.
There are similar differences in qt5/src/cmake_install.cmake and
cpp/cmake_install.cmake.
I also diffed CMakeCache.txt, which gives a clue at one difference between
the systems which might possibly be related. (Machine is now building
kf5/qt5-ish things so I don't want to clean installed packages to test
theories until it's at a better stage during the build).
sthen@i386-3[/pobj] diff poppler-0.82.0-/build-i386/CMakeCache.txt
poppler-0.82.0/build-i386/CMakeCache.txt
--- poppler-0.82.0-/build-i386/CMakeCache.txt Thu Nov 21 20:27:17 2019
+++ poppler-0.82.0/build-i386/CMakeCache.txtFri Nov 22 12:27:33 2019
@@ -272,7 +272,7 @@ CMAKE_STRIP:FILEPATH=/usr/bin/strip
CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE
//The directory containing a CMake configuration file for ECM.
-ECM_DIR:PATH=ECM_DIR-NOTFOUND
+ECM_DIR:PATH=/usr/local/share/ECM/cmake
//Use color management system. Possible values: lcms2, none. 'none'
// disables color management system.
sthen@i386-3[/pobj/poppler-0.82.0/build-i386] diff
/pobj/poppler-0.82.0-/build-i386/glib/cmake_install.cmake
glib/cmake_install.cmake
--- /pobj/poppler-0.82.0-/build-i386/glib/cmake_install.cmake Thu Nov 21
20:27:17 2019
+++ glib/cmake_install.cmakeFri Nov 22 12:27:33 2019
@@ -38,36 +38,23 @@ if(NOT DEFINED CMAKE_CROSSCOMPILING)
endif()
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT
CMAKE_INSTALL_COMPONENT)
- foreach(file
- "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.8.15.0"
- "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.8"
- )
-if(EXISTS "${file}" AND
- NOT IS_SYMLINK "${file}")
- file(RPATH_CHECK
- FILE "${file}"
- RPATH "")
+ if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4"
AND
+ NOT IS_SYMLINK
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4")
+file(RPATH_CHECK
+ FILE
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4"
+ RPATH "")
+ endif()
+ file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib" TYPE SHARED_LIBRARY
FILES "/pobj/poppler-0.82.0/build-i386/glib/libpoppler-glib.so.19.4")
+ if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4"
AND
+ NOT IS_SYMLINK
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4")
+file(RPATH_CHANGE
+ FILE
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4"
+ OLD_RPATH "/pobj/poppler-0.82.0/build-i386:"
+ NEW_RPATH "")
+if(CMAKE_INSTALL_DO_STRIP)
+ execute_process(COMMAND "/usr/bin/strip"
"$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.19.4")
endif()
- endforeach()
- file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib" TYPE SHARED_LIBRARY
FILES
-"/pobj/poppler-0.82.0/build-i386/glib/libpoppler-glib.so.8.15.0"
-"/pobj/poppler-0.82.0/build-i386/glib/libpoppler-glib.so.8"
-)
- foreach(file
- "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.8.15.0"
- "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libpoppler-glib.so.8"
- )
-if(EXISTS "${file}" AND
- NOT IS_SYMLINK "${file}")
- file(RPATH_CHANGE
- FILE "${file}"
- OLD_RPATH "/pobj/poppler-0.82.0/build-i386
Re: poppler/cmake cannot find libpoppler-glib.so.8.15.0 [Re: CVS: cvs.openbsd.org: ports]
Hi, On Fri, Nov 22, 2019 at 10:20:17AM +, Stuart Henderson wrote: > I have built 0.82.0 successfully before, but on my last build I had this: > > > -- Set runtime path of > "/pobj/poppler-0.82.0/fake-i386/usr/local/bin/pdfunite" to "" > -- Installing: /pobj/poppler-0.82.0/fake-i386/usr/local/man/man1/pdfunite.1 > CMake Error at glib/cmake_install.cmake:52 (file): > file INSTALL cannot find > "/pobj/poppler-0.82.0/build-i386/glib/libpoppler-glib.so.8.15.0". > Call Stack (most recent call first): > cmake_install.cmake:245 (include) > > > FAILED: CMakeFiles/install.util > cd /pobj/poppler-0.82.0/build-i386 && /usr/local/bin/cmake -P > cmake_install.cmake > ninja: build stopped: subcommand failed. IIRC, naddy@ had the same problem with an older version of poppler, where the cmake suddenly decided to use the upstream shared lib version of libpoppler-glib.so instead of what the port sets (here: 8.15.0 instead of 19.4). glib/CMakeLists.txt has: set_target_properties(poppler-glib PROPERTIES VERSION 8.15.0 SOVERSION 8) while the port has: SHARED_LIBS += poppler-glib 19.4 # 8.15 > $ ls -l /pobj/poppler-0.82.0/build-i386/glib [...] > -rw-r--r-- 1 _pbuild _pbuild3925 Nov 21 20:27 cmake_install.cmake [...] I'm not that cmake expert, but I'd like to have a look at that file, and probably compare it with a version from a successfull build. I don't think I need the full build directory. Ciao, Kili
poppler/cmake cannot find libpoppler-glib.so.8.15.0 [Re: CVS: cvs.openbsd.org: ports]
On 2019/11/12 15:03, Matthias Kilian wrote: > CVSROOT: /cvs > Module name: ports > Changes by: k...@cvs.openbsd.org2019/11/12 15:03:42 > > Modified files: > print/poppler : Makefile distinfo > print/poppler/pkg: PLIST-main > > Log message: > Update to poppler-0.82.0. > I have built 0.82.0 successfully before, but on my last build I had this: -- Set runtime path of "/pobj/poppler-0.82.0/fake-i386/usr/local/bin/pdfunite" to "" -- Installing: /pobj/poppler-0.82.0/fake-i386/usr/local/man/man1/pdfunite.1 CMake Error at glib/cmake_install.cmake:52 (file): file INSTALL cannot find "/pobj/poppler-0.82.0/build-i386/glib/libpoppler-glib.so.8.15.0". Call Stack (most recent call first): cmake_install.cmake:245 (include) FAILED: CMakeFiles/install.util cd /pobj/poppler-0.82.0/build-i386 && /usr/local/bin/cmake -P cmake_install.cmake ninja: build stopped: subcommand failed. ... $ ls -l /pobj/poppler-0.82.0/build-i386/glib total 2364 drwxr-xr-x 3 _pbuild _pbuild 512 Nov 21 20:22 CMakeFiles -rw-r--r-- 1 _pbuild _pbuild 289 Nov 21 20:22 CTestTestfile.cmake -rw-r--r-- 1 _pbuild _pbuild 598197 Nov 21 20:27 Poppler-0.18.gir -rw-r--r-- 1 _pbuild _pbuild 66944 Nov 21 20:27 Poppler-0.18.typelib -rw-r--r-- 1 _pbuild _pbuild3925 Nov 21 20:27 cmake_install.cmake lrwxr-xr-x 1 _pbuild _pbuild 23 Nov 21 20:27 libpoppler-glib.so -> libpoppler-glib.so.19.4 -rwxr-xr-x 1 _pbuild _pbuild 413744 Nov 21 20:27 libpoppler-glib.so.19.4 -rw-r--r-- 1 _pbuild _pbuild 54121 Nov 21 20:24 poppler-enums.c -rw-r--r-- 1 _pbuild _pbuild8522 Nov 21 20:24 poppler-enums.h -rw-r--r-- 1 _pbuild _pbuild2697 Nov 21 20:22 poppler-features.h ... Anyone have a clue? Full log attached, I have kept a tar of the build directory if needed. poppler.log.gz Description: application/gunzip
Re: sdl2-related breakage - Re: CVS: cvs.openbsd.org: ports
On 2019-09-28 07:34, Stuart Henderson wrote: Please could somebody either backout the SDL2 update or fix the dependent ports. I've already seen and OK'd fixes by thfr@ for both ports (since I'm the maintainer of both of the ports listed). ~Brian On 2019/09/25 11:51, Stuart Henderson wrote: On 2019/09/22 09:46, Thomas Frohwein wrote: CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2019/09/22 09:46:26 Modified files: devel/sdl2 : Makefile distinfo devel/sdl2/patches: patch-Makefile_in patch-src_SDL_c patch-src_joystick_SDL_gamecontroller_c patch-src_video_SDL_egl_c Removed files: devel/sdl2/patches: patch-src_joystick_bsd_SDL_sysjoystick_c Log message: update to sdl2 2.0.10 testing and ok brynet@ Changelog says: * Removed SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH (replaced by SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS) SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=1, should be replaced by setting both previous hints to 0. SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=0, should be replaced by setting both previous hints to 1. As a result of this removal, the update breaks games/julius and games/freedink/game.
sdl2-related breakage - Re: CVS: cvs.openbsd.org: ports
Please could somebody either backout the SDL2 update or fix the dependent ports. On 2019/09/25 11:51, Stuart Henderson wrote: > On 2019/09/22 09:46, Thomas Frohwein wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: t...@cvs.openbsd.org2019/09/22 09:46:26 > > > > Modified files: > > devel/sdl2 : Makefile distinfo > > devel/sdl2/patches: patch-Makefile_in patch-src_SDL_c > > patch-src_joystick_SDL_gamecontroller_c > > patch-src_video_SDL_egl_c > > Removed files: > > devel/sdl2/patches: patch-src_joystick_bsd_SDL_sysjoystick_c > > > > Log message: > > update to sdl2 2.0.10 > > > > testing and ok brynet@ > > > > Changelog says: > > * Removed SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH (replaced by > SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS) > SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=1, should be replaced by setting > both previous hints to 0. > SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=0, should be replaced by setting > both previous hints to 1. > > As a result of this removal, the update breaks games/julius and > games/freedink/game. > >
Re: handbrake/i386 (was: Re: CVS: cvs.openbsd.org: ports)
On 2019/08/07 11:32, Brian Callahan wrote:
> Hi Stuart --
>
> On 8/7/19 5:09 AM, Stuart Henderson wrote:
> > On 2019/08/05 07:35, Brian Callahan wrote:
> > > CVSROOT: /cvs
> > > Module name: ports
> > > Changes by: bcal...@cvs.openbsd.org 2019/08/05 07:35:20
> > >
> > > Log message:
> > > Import multimedia/handbrake, an open source video transcoder.
> > > ok kn@
> > Handbrake doesn't build on i386 as-is. Either it needs asm disabling,
> > or at least using -msse2 (however there might be further problems),
> > log below.
>
> I'm perfectly ok with requiring -msse2 on i386. Upstream assumes you have
> sse2 (make/include/gcc.defs:77).
>
> > Also there are a few implicit declarations of iconv-related functions
> > which might be a problem on LP64 arches too. this will probably just be
> > a missing #include.
>
> This wasn't a missing #include. It was a stray #define confusing iconv.h.
> Fixed.
>
> The other warnings look like they come from devel/libdvdread. I don't think
> they'll be much of an issue but I guess I'm willing to be proven wrong.
>
> I don't have any i386 machines, so this is untested. The added patch (fixing
> libiconv silliness) is definitely correct; it's the i386 addition of -msse2
> someone will need to check.
Reads ok - can you just commit it please, then it'll get tested in the next
build.
> ~Brian
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/handbrake/Makefile,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 Makefile
> --- Makefile 5 Aug 2019 13:35:20 - 1.1.1.1
> +++ Makefile 7 Aug 2019 15:19:13 -
> @@ -4,6 +4,7 @@ V = 1.2.2
> COMMENT =open source video transcoder
> DISTNAME = HandBrake-${V}-source
> PKGNAME =handbrake-${V}
> +REVISION = 0
> EXTRACT_SUFX = .tar.bz2
> CATEGORIES = multimedia x11
>
> @@ -69,6 +70,11 @@ MAKE_ENV = AUTOCONF_VERSION="${AUTOCONF_
> MAKE_FILE = GNUmakefile
> MAKE_FLAGS = CFLAGS="${CFLAGS} -I${LOCALBASE}/include/libxml2
> -D_NO_UPDATE_CHECK" \
> LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib -L${X11BASE}/lib -lx265
> -liconv"
> +
> +.if ${MACHINE_ARCH:Mi386}
> +CFLAGS +=-msse2
> +CXXFLAGS += -msse2
> +.endif
>
> AUTOCONF_VERSION = 2.69
> AUTOMAKE_VERSION = 1.16
> Index: patches/patch-make_variant_freebsd_defs
> ===
> RCS file: patches/patch-make_variant_freebsd_defs
> diff -N patches/patch-make_variant_freebsd_defs
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-make_variant_freebsd_defs 7 Aug 2019 15:19:13 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: make/variant/freebsd.defs
> +--- make/variant/freebsd.defs.orig
> make/variant/freebsd.defs
> +@@ -3,8 +3,6 @@ LOCALBASE ?= /usr/local
> +
> + TARGET.dylib.ext = .so
> +
> +-GCC.D = LIBICONV_PLUG
> +-
> + GCC.args.dylib = -shared
> + GCC.args.pic = 1
> +
handbrake/i386 (was: Re: CVS: cvs.openbsd.org: ports)
Hi Stuart --
On 8/7/19 5:09 AM, Stuart Henderson wrote:
On 2019/08/05 07:35, Brian Callahan wrote:
CVSROOT:/cvs
Module name:ports
Changes by: bcal...@cvs.openbsd.org 2019/08/05 07:35:20
Log message:
Import multimedia/handbrake, an open source video transcoder.
ok kn@
Handbrake doesn't build on i386 as-is. Either it needs asm disabling,
or at least using -msse2 (however there might be further problems),
log below.
I'm perfectly ok with requiring -msse2 on i386. Upstream assumes you
have sse2 (make/include/gcc.defs:77).
Also there are a few implicit declarations of iconv-related functions
which might be a problem on LP64 arches too. this will probably just be
a missing #include.
This wasn't a missing #include. It was a stray #define confusing
iconv.h. Fixed.
The other warnings look like they come from devel/libdvdread. I don't
think they'll be much of an issue but I guess I'm willing to be proven
wrong.
I don't have any i386 machines, so this is untested. The added patch
(fixing libiconv silliness) is definitely correct; it's the i386
addition of -msse2 someone will need to check.
~Brian
Index: Makefile
===
RCS file: /cvs/ports/multimedia/handbrake/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 5 Aug 2019 13:35:20 - 1.1.1.1
+++ Makefile 7 Aug 2019 15:19:13 -
@@ -4,6 +4,7 @@ V = 1.2.2
COMMENT = open source video transcoder
DISTNAME = HandBrake-${V}-source
PKGNAME = handbrake-${V}
+REVISION = 0
EXTRACT_SUFX = .tar.bz2
CATEGORIES = multimedia x11
@@ -69,6 +70,11 @@ MAKE_ENV = AUTOCONF_VERSION="${AUTOCONF_
MAKE_FILE = GNUmakefile
MAKE_FLAGS = CFLAGS="${CFLAGS} -I${LOCALBASE}/include/libxml2 -D_NO_UPDATE_CHECK" \
LDFLAGS="${LDFLAGS} -L${LOCALBASE}/lib -L${X11BASE}/lib -lx265 -liconv"
+
+.if ${MACHINE_ARCH:Mi386}
+CFLAGS += -msse2
+CXXFLAGS += -msse2
+.endif
AUTOCONF_VERSION = 2.69
AUTOMAKE_VERSION = 1.16
Index: patches/patch-make_variant_freebsd_defs
===
RCS file: patches/patch-make_variant_freebsd_defs
diff -N patches/patch-make_variant_freebsd_defs
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-make_variant_freebsd_defs 7 Aug 2019 15:19:13 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: make/variant/freebsd.defs
+--- make/variant/freebsd.defs.orig
make/variant/freebsd.defs
+@@ -3,8 +3,6 @@ LOCALBASE ?= /usr/local
+
+ TARGET.dylib.ext = .so
+
+-GCC.D = LIBICONV_PLUG
+-
+ GCC.args.dylib = -shared
+ GCC.args.pic = 1
+
Re: nexcloud 16.0.0 on OPENBSD_6_4 Re: CVS: cvs.openbsd.org: ports
On Sun, May 19, 2019 at 09:49:54AM +0200, Gonzalo L. Rodriguez wrote: > > > > On 18. May 2019, at 21:44, Stuart Henderson wrote: > > > >> On 2019/05/18 19:12, Matthieu Herrb wrote: > >>> On Tue, Apr 30, 2019 at 01:54:06AM -0600, Gonzalo L. Rodriguez wrote: > >>> CVSROOT:/cvs > >>> Module name:ports > >>> Changes by:gonz...@cvs.openbsd.org2019/04/30 01:54:06 > >>> > >>> Modified files: > >>>www/nextcloud : Tag: OPENBSD_6_4 Makefile distinfo > >>>www/nextcloud/pkg: Tag: OPENBSD_6_4 PLIST > >>> > >>> Log message: > >>> Update for Nextcloud to 16.0.0: > >>> > >>> https://nextcloud.com/changelog/ > >>> > >>> Fart cloud all the things! > >> > >> Hmm, MODPHP_VERSION is 7.0 on 6.4. Thus this update fails to run with > >> > >> This version of Nextcloud requires at least PHP 7.1 > >> You are currently running 7.0.33. Please update your PHP version. > >> > >> How do I fix that (other than upgrading to 6.5) ? > >> -- > >> Matthieu Herrb > >> > > > > 6.4 does have php 7.1.x (and 7.2.x), you could work around this by > > pkg_add'ing them and do the usual changeover steps (add symlinks in > > /etc/php-7.2 to ../php-7.2.sample, change php70_fpm to php72_fpm in > > pkg_scripts) and ignore the 7.0 packages. > > > > It's not ideal though. > > Yes, this is the best option without upgrade to 6.5 Hi, I managed to upgrade my nextcloud installation. Thanks. -- Matthieu Herrb
Re: nexcloud 16.0.0 on OPENBSD_6_4 Re: CVS: cvs.openbsd.org: ports
> On 18. May 2019, at 21:44, Stuart Henderson wrote: > >> On 2019/05/18 19:12, Matthieu Herrb wrote: >>> On Tue, Apr 30, 2019 at 01:54:06AM -0600, Gonzalo L. Rodriguez wrote: >>> CVSROOT:/cvs >>> Module name:ports >>> Changes by:gonz...@cvs.openbsd.org2019/04/30 01:54:06 >>> >>> Modified files: >>>www/nextcloud : Tag: OPENBSD_6_4 Makefile distinfo >>>www/nextcloud/pkg: Tag: OPENBSD_6_4 PLIST >>> >>> Log message: >>> Update for Nextcloud to 16.0.0: >>> >>> https://nextcloud.com/changelog/ >>> >>> Fart cloud all the things! >> >> Hmm, MODPHP_VERSION is 7.0 on 6.4. Thus this update fails to run with >> >> This version of Nextcloud requires at least PHP 7.1 >> You are currently running 7.0.33. Please update your PHP version. >> >> How do I fix that (other than upgrading to 6.5) ? >> -- >> Matthieu Herrb >> > > 6.4 does have php 7.1.x (and 7.2.x), you could work around this by > pkg_add'ing them and do the usual changeover steps (add symlinks in > /etc/php-7.2 to ../php-7.2.sample, change php70_fpm to php72_fpm in > pkg_scripts) and ignore the 7.0 packages. > > It's not ideal though. Yes, this is the best option without upgrade to 6.5
Re: nexcloud 16.0.0 on OPENBSD_6_4 Re: CVS: cvs.openbsd.org: ports
On 2019/05/18 19:12, Matthieu Herrb wrote: > On Tue, Apr 30, 2019 at 01:54:06AM -0600, Gonzalo L. Rodriguez wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: gonz...@cvs.openbsd.org 2019/04/30 01:54:06 > > > > Modified files: > > www/nextcloud : Tag: OPENBSD_6_4 Makefile distinfo > > www/nextcloud/pkg: Tag: OPENBSD_6_4 PLIST > > > > Log message: > > Update for Nextcloud to 16.0.0: > > > > https://nextcloud.com/changelog/ > > > > Fart cloud all the things! > > Hmm, MODPHP_VERSION is 7.0 on 6.4. Thus this update fails to run with > > This version of Nextcloud requires at least PHP 7.1 > You are currently running 7.0.33. Please update your PHP version. > > How do I fix that (other than upgrading to 6.5) ? > -- > Matthieu Herrb > 6.4 does have php 7.1.x (and 7.2.x), you could work around this by pkg_add'ing them and do the usual changeover steps (add symlinks in /etc/php-7.2 to ../php-7.2.sample, change php70_fpm to php72_fpm in pkg_scripts) and ignore the 7.0 packages. It's not ideal though.
nexcloud 16.0.0 on OPENBSD_6_4 Re: CVS: cvs.openbsd.org: ports
On Tue, Apr 30, 2019 at 01:54:06AM -0600, Gonzalo L. Rodriguez wrote: > CVSROOT: /cvs > Module name: ports > Changes by: gonz...@cvs.openbsd.org 2019/04/30 01:54:06 > > Modified files: > www/nextcloud : Tag: OPENBSD_6_4 Makefile distinfo > www/nextcloud/pkg: Tag: OPENBSD_6_4 PLIST > > Log message: > Update for Nextcloud to 16.0.0: > > https://nextcloud.com/changelog/ > > Fart cloud all the things! Hmm, MODPHP_VERSION is 7.0 on 6.4. Thus this update fails to run with This version of Nextcloud requires at least PHP 7.1 You are currently running 7.0.33. Please update your PHP version. How do I fix that (other than upgrading to 6.5) ? -- Matthieu Herrb
Re: math/lapack update to 3.8.0 (was: Re: CVS: cvs.openbsd.org: ports)
On Tue, Apr 30, 2019 at 03:04:40PM +0200, Jeremie Courreges-Anglas wrote: > On Tue, Apr 30 2019, Landry Breuil wrote: > > On Tue, Apr 30, 2019 at 01:49:49PM +0200, Landry Breuil wrote: > >> On Sat, Apr 27, 2019 at 11:00:10AM +0200, Landry Breuil wrote: > >> > On Wed, Apr 24, 2019 at 09:30:31AM -0600, Steven Mestdagh wrote: > >> > > CVSROOT: /cvs > >> > > Module name: ports > >> > > Changes by:ste...@cvs.openbsd.org 2019/04/24 09:30:31 > >> > > > >> > > Modified files: > >> > >math/lapack: Makefile distinfo > >> > >math/lapack/files: Makefile > >> > >math/lapack/pkg: PLIST > >> > > > >> > > Log message: > >> > > update to 3.8.0 > >> > > >> > It seems this has side-effects on py-numpy, which complains on a missing > >> > symbol now: > >> > > >> > python2 -c 'import numpy' > >> > python2:/usr/local/lib/liblapack.so.7.0: undefined symbol > >> > 'ilaenv2stage_' > >> > > >> > same with python3, and this breaks geo/pdal configure via cmake (seen by > >> > naddy@ and ajacoutot@) > >> > > >> > steven, can you investigate ? > >> > >> it also shows with rio from geo/rasterio: > >> > >> $rio > >> python2.7:/usr/local/lib/liblapack.so.7.0: undefined symbol 'ilaenv2stage_' > >> > >> i had a quick look but my fortran fu is lacking. > >> > > sthen found https://bugzilla.redhat.com/show_bug.cgi?id=1514512 which > > points at > > https://src.fedoraproject.org/rpms/lapack/c/4ec46f8519f085bedb8ae9c16aa32b981e0d7004?branch=master > > but we already have ilaenv2stage.o in ALLAUX in objdir/Makefile s i > > dont see what can be wrong here. lld ? > > Our port uses its own Makefile instead of reusing upstream's build > system so it needs to be kept in sync. Steven only missed one change in > the update to 3.8.0: Doh. How could i miss that... maybe we should just use upstream Makefile then ? > ok? Definitely ok for me, thanks !
math/lapack update to 3.8.0 (was: Re: CVS: cvs.openbsd.org: ports)
On Tue, Apr 30 2019, Landry Breuil wrote: > On Tue, Apr 30, 2019 at 01:49:49PM +0200, Landry Breuil wrote: >> On Sat, Apr 27, 2019 at 11:00:10AM +0200, Landry Breuil wrote: >> > On Wed, Apr 24, 2019 at 09:30:31AM -0600, Steven Mestdagh wrote: >> > > CVSROOT: /cvs >> > > Module name: ports >> > > Changes by: ste...@cvs.openbsd.org 2019/04/24 09:30:31 >> > > >> > > Modified files: >> > > math/lapack: Makefile distinfo >> > > math/lapack/files: Makefile >> > > math/lapack/pkg: PLIST >> > > >> > > Log message: >> > > update to 3.8.0 >> > >> > It seems this has side-effects on py-numpy, which complains on a missing >> > symbol now: >> > >> > python2 -c 'import numpy' >> > python2:/usr/local/lib/liblapack.so.7.0: undefined symbol >> > 'ilaenv2stage_' >> > >> > same with python3, and this breaks geo/pdal configure via cmake (seen by >> > naddy@ and ajacoutot@) >> > >> > steven, can you investigate ? >> >> it also shows with rio from geo/rasterio: >> >> $rio >> python2.7:/usr/local/lib/liblapack.so.7.0: undefined symbol 'ilaenv2stage_' >> >> i had a quick look but my fortran fu is lacking. >> > sthen found https://bugzilla.redhat.com/show_bug.cgi?id=1514512 which > points at > https://src.fedoraproject.org/rpms/lapack/c/4ec46f8519f085bedb8ae9c16aa32b981e0d7004?branch=master > but we already have ilaenv2stage.o in ALLAUX in objdir/Makefile s i > dont see what can be wrong here. lld ? Our port uses its own Makefile instead of reusing upstream's build system so it needs to be kept in sync. Steven only missed one change in the update to 3.8.0: > --- lapack-3.7.1/SRC/Makefile Sun Jun 18 00:46:53 2017 > +++ lapack-3.8.0/SRC/Makefile Mon Nov 13 05:15:54 2017 > @@ -56,7 +56,8 @@ > # > ### > > -ALLAUX = ilaenv.o ieeeck.o lsamen.o xerbla.o xerbla_array.o iparmq.o > iparam2stage.o \ > +ALLAUX = ilaenv.o ilaenv2stage.o ieeeck.o lsamen.o xerbla.o xerbla_array.o \ > + iparmq.o iparam2stage.o \ Here ^ > ilaprec.o ilatrans.o ilauplo.o iladiag.o chla_transtype.o \ > ../INSTALL/ilaver.o ../INSTALL/lsame.o ../INSTALL/slamch.o > > @@ -151,6 +152,7 @@ > ssytf2_rk.o ssytrf_rk.o ssytrs_3.o \ > ssytri_3.o ssytri_3x.o ssycon_3.o ssysv_rk.o \ > slasyf_aa.o ssysv_aa.o ssytrf_aa.o ssytrs_aa.o \ > + ssysv_aa_2stage.o ssytrf_aa_2stage.o ssytrs_aa_2stage.o \ > stbcon.o \ > stbrfs.o stbtrs.o stgevc.o stgex2.o stgexc.o stgsen.o \ > stgsja.o stgsna.o stgsy2.o stgsyl.o stpcon.o stprfs.o stptri.o \ > @@ -212,6 +214,7 @@ > chetf2_rk.o chetrf_rk.o chetri_3.o chetri_3x.o \ > chetrs_3.o checon_3.o chesv_rk.o \ > chesv_aa.o chetrf_aa.o chetrs_aa.o clahef_aa.o \ > + chesv_aa_2stage.o chetrf_aa_2stage.o chetrs_aa_2stage.o \ > chgeqz.o chpcon.o chpev.o chpevd.o \ > chpevx.o chpgst.o chpgv.o chpgvd.o chpgvx.o chprfs.o chpsv.o \ > chpsvx.o \ > @@ -248,6 +251,7 @@ > csytri_rook.o csycon_rook.o csysv_rook.o \ > csytf2_rk.o csytrf_rk.o csytrf_aa.o csytrs_3.o csytrs_aa.o \ > csytri_3.o csytri_3x.o csycon_3.o csysv_rk.o csysv_aa.o \ > + csysv_aa_2stage.o csytrf_aa_2stage.o csytrs_aa_2stage.o \ > ctbcon.o ctbrfs.o ctbtrs.o ctgevc.o ctgex2.o \ > ctgexc.o ctgsen.o ctgsja.o ctgsna.o ctgsy2.o ctgsyl.o ctpcon.o \ > ctprfs.o ctptri.o \ > @@ -345,6 +349,7 @@ > dsytf2_rk.o dsytrf_rk.o dsytrs_3.o \ > dsytri_3.o dsytri_3x.o dsycon_3.o dsysv_rk.o \ > dlasyf_aa.o dsysv_aa.o dsytrf_aa.o dsytrs_aa.o \ > + dsysv_aa_2stage.o dsytrf_aa_2stage.o dsytrs_aa_2stage.o \ > dtbcon.o dtbrfs.o dtbtrs.o dtgevc.o dtgex2.o dtgexc.o dtgsen.o \ > dtgsja.o dtgsna.o dtgsy2.o dtgsyl.o dtpcon.o dtprfs.o dtptri.o \ > dtptrs.o \ > @@ -405,6 +410,7 @@ > zhetf2_rk.o zhetrf_rk.o zhetri_3.o zhetri_3x.o \ > zhetrs_3.o zhecon_3.o zhesv_rk.o \ > zhesv_aa.o zhetrf_aa.o zhetrs_aa.o zlahef_aa.o \ > + zhesv_aa_2stage.o zhetrf_aa_2stage.o zhetrs_aa_2stage.o \ > zhgeqz.o zhpcon.o zhpev.o zhpevd.o \ > zhpevx.o zhpgst.o zhpgv.o zhpgvd.o zhpgvx.o zhprfs.o zhpsv.o \ > zhpsvx.o \ > @@ -441,6 +447,7 @@ > zsyconv.o zsyconvf.o zsyconvf_rook.o \ > zsytf2_rook.o zsytrf_rook.o zsytrs_rook.o zsytrs_aa.o \ > zsytri_rook.o zsycon_rook.o zsysv_rook.o \ > + zsysv_aa_2stage.o zsytrf_aa_2stage.o zsytrs_aa_2stage.o \ > zsytf2_rk.o zsytrf_rk.o zsytrf_aa.o zsytrs_3.o \ > zsytri_3.o zsytri_3x.o zsycon_3.o zsysv_rk.o zsysv_aa.o \ > ztbcon.o ztbrfs.o ztbtrs.o ztgevc.o ztgex2.o \ Here's a diff to address this issue. No more warning about missing ilaenv2stage_ with python2 -c 'import numpy' ok? Index: Makefile === RCS file: /cvs/ports/math/lapack/Makefile,v retrieving revision 1.29 diff -u -p -r1.29 Makefile --- Makefile28 Apr 2019 21:08:27 - 1.29 +++ Makefile30 Apr 2019 12:42:23 - @@ -4,9 +4,9 @@ COMMENT=library of Fortran linear algeb VERSION= 3.8.0
Re: pdal [-Wc++11-narrowing on 32 bit] Re: CVS: cvs.openbsd.org: ports
On Sat, Apr 27, 2019 at 04:47:52PM +0100, Stuart Henderson wrote:
> On 2019/04/24 02:14, Landry Breuil wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: lan...@cvs.openbsd.org 2019/04/24 02:14:17
> >
> > Modified files:
> > geo/pdal : Makefile distinfo
> > geo/pdal/patches: patch-cmake_macros_cmake
> > geo/pdal/pkg : PLIST
> > Added files:
> > geo/pdal/patches: patch-vendor_arbiter_arbiter_hpp
> > Removed files:
> > geo/pdal/patches: patch-cmake_modules_FindGEOS_cmake
> > patch-dimbuilder_CMakeLists_txt
> > patch-pdal_PluginDirectory_cpp
> > patch-pdal_util_CMakeLists_txt
> > patch-pdal_util_Utils_cpp
> > patch-plugins_sqlite_io_SQLiteCommon_hpp
> > patch-test_unit_PluginManagerTest_cpp
> >
> > Log message:
> > Update to pdal 1.9.0.
> >
> > Should build fine with python 3.7.
> >
>
> This breaks on i386 in a source file for tests,
> test/unit/filters/DelaunayFilterTest.cpp,
>
> 88 // Loop through the triangles of the generated mesh...
> 89 for (size_t i = 0; i < mesh->size(); i++)
> 90 {
> 91 Triangle triangle = (*mesh)[i];
> 92
> 93 // Build a vector so we can compare to an expected triangle
> with
> 94 // the == operator.
> 95 std::vector triangleVector = {triangle.m_a,
> triangle.m_b, triangle.m_c};
> 96
>
> /usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:47:
> error: non-constant-expressio
> n cannot be narrowed from type 'pdal::PointId' (aka 'unsigned long long') to
> 'unsigned long' in initializer list [-Wc+
> +11-narrowing]
> std::vector triangleVector = {triangle.m_a, triangle.m_b,
> triangle.m_c};
> ^~~~
> /usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:47:
> note: insert an explicit cast
> to silence this issue
> std::vector triangleVector = {triangle.m_a, triangle.m_b,
> triangle.m_c};
> ^~~~
> static_cast( )
Well, going the dumb wayi and adding the proposed static_cast seems to
work here, builds both on amd64 & i386 without extra warnings. does this
look better?
http://pastebitch.com/hXMD
Landry
pdal [-Wc++11-narrowing on 32 bit] Re: CVS: cvs.openbsd.org: ports
On 2019/04/24 02:14, Landry Breuil wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: lan...@cvs.openbsd.org 2019/04/24 02:14:17
>
> Modified files:
> geo/pdal : Makefile distinfo
> geo/pdal/patches: patch-cmake_macros_cmake
> geo/pdal/pkg : PLIST
> Added files:
> geo/pdal/patches: patch-vendor_arbiter_arbiter_hpp
> Removed files:
> geo/pdal/patches: patch-cmake_modules_FindGEOS_cmake
> patch-dimbuilder_CMakeLists_txt
> patch-pdal_PluginDirectory_cpp
> patch-pdal_util_CMakeLists_txt
> patch-pdal_util_Utils_cpp
> patch-plugins_sqlite_io_SQLiteCommon_hpp
> patch-test_unit_PluginManagerTest_cpp
>
> Log message:
> Update to pdal 1.9.0.
>
> Should build fine with python 3.7.
>
This breaks on i386 in a source file for tests,
test/unit/filters/DelaunayFilterTest.cpp,
88 // Loop through the triangles of the generated mesh...
89 for (size_t i = 0; i < mesh->size(); i++)
90 {
91 Triangle triangle = (*mesh)[i];
92
93 // Build a vector so we can compare to an expected triangle with
94 // the == operator.
95 std::vector triangleVector = {triangle.m_a,
triangle.m_b, triangle.m_c};
96
/usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:47:
error: non-constant-expressio
n cannot be narrowed from type 'pdal::PointId' (aka 'unsigned long long') to
'unsigned long' in initializer list [-Wc+
+11-narrowing]
std::vector triangleVector = {triangle.m_a, triangle.m_b,
triangle.m_c};
^~~~
/usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:47:
note: insert an explicit cast
to silence this issue
std::vector triangleVector = {triangle.m_a, triangle.m_b,
triangle.m_c};
^~~~
static_cast( )
/usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:61:
error: non-constant-expressio
n cannot be narrowed from type 'pdal::PointId' (aka 'unsigned long long') to
'unsigned long' in initializer list [-Wc+
+11-narrowing]
std::vector triangleVector = {triangle.m_a, triangle.m_b,
triangle.m_c};
^~~~
/usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:61:
note: insert an explicit cast
to silence this issue
std::vector triangleVector = {triangle.m_a, triangle.m_b,
triangle.m_c};
^~~~
static_cast( )
/usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:75:
error: non-constant-expressio
n cannot be narrowed from type 'pdal::PointId' (aka 'unsigned long long') to
'unsigned long' in initializer list [-Wc+
+11-narrowing]
std::vector triangleVector = {triangle.m_a, triangle.m_b,
triangle.m_c};
^~~~
/usr/obj/ports/pdal-1.9.0/PDAL-1.9.0-src/test/unit/filters/DelaunayFilterTest.cpp:95:75:
note: insert an explicit cast
to silence this issue
std::vector triangleVector = {triangle.m_a, triangle.m_b,
triangle.m_c};
^~~~
static_cast( )
3 errors generated.
Dirty fix here, or does someone have a better idea?
Index: Makefile
===
RCS file: /cvs/ports/geo/pdal/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile24 Apr 2019 08:14:17 - 1.8
+++ Makefile27 Apr 2019 15:47:06 -
@@ -46,4 +46,11 @@ CONFIGURE_ARGS = \
# needs load extension
# -DBUILD_PLUGIN_SQLITE=ON
+.include
+.if ${PROPERTIES:Mclang}
+CXXFLAGS +=-Wno-c++11-narrowing
+# fails on 32-bit otherwise:
+# test/unit/filters/DelaunayFilterTest.cpp:95:47: error:
non-constant-expression cannot be narrowed from type 'pdal::PointId' (aka
'unsigned long long') to 'unsigned long' in initializer list [-Wc++11-narrowing]
+.endif
+
.include
Re: ocaml/i386 Re: CVS: cvs.openbsd.org: ports
On Fri, 8 Mar 2019 00:19:24 + Stuart Henderson wrote: > Broken on i386; LDFLAGS is no longer getting passed to the linker in > some places. I tested the improved patch below successfully on i386. It failed once with a "Sys_error: Permission denied", but I could not reproduce this error. OK? Christopher Index: patch-configure === RCS file: /cvs/ports/lang/ocaml/patches/patch-configure,v retrieving revision 1.23 diff -u -p -r1.23 patch-configure --- patch-configure 4 Mar 2019 12:51:14 - 1.23 +++ patch-configure 8 Mar 2019 21:26:18 - @@ -25,7 +25,7 @@ Index: configure |*-*-openbsd*|*-*-netbsd*|*-*-dragonfly*|*-*-gnu*|*-*-haiku*) sharedcccompopts="-fPIC" - mksharedlib="$cc -shared" -+ mksharedlib="$cc $common_cflags -shared" ++ mksharedlib="$cc $common_cflags $ldflags -shared" ldflags="$ldflags -Wl,-E" + mkexe="$cc $ldflags" rpath="-Wl,-rpath," -- http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1 pgprtlOYwHsH5.pgp Description: OpenPGP digital signature
ocaml/i386 Re: CVS: cvs.openbsd.org: ports
Broken on i386; LDFLAGS is no longer getting passed to the linker in some places. cc -O2 -pipe -fno-strict-aliasing -fwrapv -shared -o libasmrun_shared.so startup_aux.pic.o startup.pic.o main.pic.o fail.pic.o roots.pic.o signals.pic.o signals_asm.pic.o misc.pic.o freelist.pic.o major_gc.pic.o minor_gc.pic.o memory. pic.o alloc.pic.o compare.pic.o ints.pic.o floats.pic.o str.pic.o array.pic.o io.pic.o extern.pic.o intern.pic.o hash. pic.o sys.pic.o parsing.pic.o gc_ctrl.pic.o md5.pic.o obj.pic.o lexing.pic.o unix.pic.o printexc.pic.o callback.pic.o weak.pic.o compact.pic.o finalise.pic.o custom.pic.o globroots.pic.o backtrace_prim.pic.o backtrace.pic.o natdynlink.p ic.o debugger.pic.o meta.pic.o dynlink.pic.o clambda_checks.pic.o spacetime.pic.o spacetime_snapshot.pic.o afl.pic.o b igarray.pic.o i386.pic.o -lm ld: error: can't create dynamic relocation R_386_32 against symbol: caml_last_return_address in readonly segment; reco mpile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in roots.pic.o >>> referenced by i386.S >>> i386.pic.o:(.text+0x4) ld: error: can't create dynamic relocation R_386_32 against symbol: caml_bottom_of_stack in readonly segment; recompil e object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in roots.pic.o >>> referenced by i386.S >>> i386.pic.o:(.text+0xD) [...] On 2019/03/04 05:51, Christopher Zimmermann wrote: > CVSROOT: /cvs > Module name: ports > Changes by: chr...@cvs.openbsd.org 2019/03/04 05:51:17 > > Modified files: > devel/cil : Makefile distinfo > devel/cil/patches: patch-Makefile_in patch-bin_CilConfig_pm_in > devel/cil/pkg : PFRAG.native PLIST > devel/coccinelle: Makefile distinfo > devel/coccinelle/patches: patch-Makefile patch-cocci_ml > patch-commons_common_ml > devel/coccinelle/pkg: PLIST > devel/cudf : Makefile > devel/dune : Makefile distinfo > devel/dune/pkg : PLIST > devel/frama-c : Makefile distinfo > devel/frama-c/pkg: PFRAG.dynlink-native PFRAG.native > PFRAG.no-native PLIST > devel/ocaml-cppo: Makefile distinfo > devel/ocaml-cppo/pkg: PFRAG.dynlink-native PFRAG.native PLIST > devel/ocaml-dose: Makefile distinfo > devel/ocaml-dose/patches: patch-Makefile > devel/ocaml-dose/pkg: PFRAG.dynlink-native PFRAG.native PLIST > devel/ocaml-jsonm: Makefile distinfo > devel/ocaml-jsonm/pkg: PLIST > devel/ocaml-menhir: Makefile distinfo > devel/ocaml-menhir/pkg: PLIST > devel/ocaml-ocamlbuild: Makefile distinfo > devel/ocaml-ocamlbuild/patches: patch-configure_make > devel/ocaml-ocamlbuild/pkg: PFRAG.native PLIST > devel/ocaml-parmap: Makefile distinfo > devel/ocaml-parmap/pkg: PFRAG.native PLIST > devel/ocaml-re : Makefile distinfo > devel/ocaml-re/pkg: PFRAG.dynlink-native PFRAG.native PLIST > devel/ocaml-uutf: Makefile distinfo > devel/ocaml-uutf/pkg: PLIST > devel/omake: Makefile distinfo > devel/omake/patches: patch-lib_build_OCaml_om > devel/omake/pkg: PLIST > devel/ounit: Makefile distinfo > devel/ounit/pkg: PLIST > lang/ocaml : Makefile distinfo > lang/ocaml/patches: patch-configure > lang/ocaml/pkg : PFRAG.dynlink-native-main PFRAG.native-main >PLIST-graphics PLIST-main > lang/ocaml-camlp4: Makefile distinfo > lang/ocaml-camlp5: Makefile distinfo > lang/ocaml-camlp5/patches: patch-etc_Makefile > lang/ocaml-camlp5/pkg: PLIST > math : Makefile > math/coq : Makefile distinfo > math/coq/pkg : PFRAG.dynlink-native PFRAG.native PLIST > math/ocaml-num : Makefile > math/ocaml-zarith: Makefile > net/mldonkey : Makefile > net/mldonkey/patches: patch-config_Makefile_in > net/unison : Makefile.inc > net/unison/2.4x: Makefile distinfo > net/unison/2.5x: Makefile > sysutils/findlib: Makefile distinfo > sysutils/findlib/pkg: PFRAG.dynlink-native PFRAG.native PLIST > sysutils/opam : Makefile distinfo > textproc/hevea : Makefile distinfo > textproc/hevea/pkg: PLIST > x11/lablgtk2 : Makefile distinfo > Added files: > devel/cil/patches: patch-_tags patch-myocamlbuild_ml > patch-src__tags patch-src_cil_mllib > devel/coccinelle/patches: patch-bundles_pyml_Makefile > patch-configure > patch-parsing_c_Makefile > patch-parsing_c_unparse_c_ml > patch-tools_spgen_source_Makefile > patch-tools_spgen_source_spg
Re: CVS: cvs.openbsd.org: ports
On Tue, Feb 19, 2019 at 10:57:05AM -0700, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: ports > Changes by: st...@cvs.openbsd.org 2019/02/19 10:57:04 > > Modified files: > graphics/giflib: Makefile distinfo > graphics/giflib/patches: patch-tests_makefile > graphics/giflib/pkg: PLIST > Added files: > graphics/giflib/patches: patch-Makefile > > Log message: > update to giflib-5.1.6 There are two BUILD_DEPENDS= lines in the Makefile. The second overwrites the first, which removes the dependency on archivers/gtar, which in turn breaks the build if gtar is not already installed. -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
devel/sdl2 (was: Re: CVS: cvs.openbsd.org: ports)
On Mon, Oct 29, 2018 at 01:44:39PM +, tfrohw...@fastmail.com wrote: > On October 29, 2018 1:09:57 PM UTC, Antoine Jacoutot > wrote: > >On Sun, Oct 28, 2018 at 11:39:49PM -0600, Thomas Frohwein wrote: > >> Change BOOL type to Bool, fixing macppc (and likely other big-endian > >arches), > >> from George Koehler (kernigh () gmail DOT com), ok kirby@, jca@. > >> Update maintainer email while here. > > > >Doesn't patch... [...] > I'm sorry, formatting must have gotten messed up along the way. > I should have checked again before committing. I will make a > working one after work tonight. Treiling whitespace is evil, except when it isn't (in patch files). I don't want to steal commits, so I'll keep it in my tree for now. Index: patches/patch-src_video_x11_SDL_x11keyboard_c === RCS file: /cvs/ports/devel/sdl2/patches/patch-src_video_x11_SDL_x11keyboard_c,v retrieving revision 1.1 diff -u -p -r1.1 patch-src_video_x11_SDL_x11keyboard_c --- patches/patch-src_video_x11_SDL_x11keyboard_c 29 Oct 2018 05:39:49 - 1.1 +++ patches/patch-src_video_x11_SDL_x11keyboard_c 29 Oct 2018 22:36:56 - @@ -13,6 +13,6 @@ Index: src/video/x11/SDL_x11keyboard.c int distance; -BOOL xkb_repeat = 0; +Bool xkb_repeat = 0; - + X11_XAutoRepeatOn(data->display); - +
Re: gmpxx, productivity/libalkimia [Re: CVS: cvs.openbsd.org: ports]
Marc Espie: > This is almost what I sent you the other day, except that I would > leave the default flavor empty, and use the bootstrap flavor where > it's really needed. Yes. So gmp,no_gmpxx,bootstrap in devel/mpfr devel/libmpc lang/gcc/4.9 I think -cxx and no_cxx would be better names for the subpackage and flavor. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: gmpxx, productivity/libalkimia [Re: CVS: cvs.openbsd.org: ports]
On Fri, Oct 26, 2018 at 03:59:55PM +0100, Stuart Henderson wrote:
> On 2018/10/24 09:21, Stuart Henderson wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: st...@cvs.openbsd.org 2018/10/24 09:21:56
> >
> > Modified files:
> > devel/gmp : Makefile
> > devel/gmp/pkg : PLIST
> >
> > Log message:
> > disable gmpxx (c++ library), it isn't used in ports or enabled by default
> > upstream
> > ok naddy@
> >
>
> Annoyingly it turns out that productivity/libalkimia uses the gmpxx.h
> header but not the library from gmp's C++ support.
>
> This gives a choice between a dirty option (install gmpxx.h anyway)
> and the messy option below. I think I've got the bootstrap parts right
> but a pair of eyes that understands it better than me wouldn't go
> amiss :)
>
> (bumps in dependent ports not shown here but also needed).
>
> Index: devel/gmp/Makefile
> ===
> RCS file: /cvs/ports/devel/gmp/Makefile,v
> retrieving revision 1.37
> diff -u -p -r1.37 Makefile
> --- devel/gmp/Makefile24 Oct 2018 15:21:56 - 1.37
> +++ devel/gmp/Makefile26 Oct 2018 14:57:53 -
> @@ -1,10 +1,16 @@
> # $OpenBSD: Makefile,v 1.37 2018/10/24 15:21:56 sthen Exp $
>
> -COMMENT= library for arbitrary precision arithmetic
> +COMMENT-main=library for arbitrary precision arithmetic
> +COMMENT-gmpxx= C++ library for arbitrary precision arithmetic
>
> DISTNAME=gmp-6.1.2
> -REVISION = 2
> +MULTI_PACKAGES= -main -gmpxx
> +PKGNAME-main=${DISTNAME}
> +PKGNAME-gmpxx= gmpxx-6.1.2
> +
> +REVISION = 3
> SHARED_LIBS += gmp 10.0 # 13.2
> +SHARED_LIBS += gmpxx2.0 # 9.2
> CATEGORIES= devel math
>
> HOMEPAGE=https://gmplib.org/
> @@ -15,11 +21,25 @@ EXTRACT_SUFX= .tar.xz
> # LGPLv3+
> PERMIT_PACKAGE_CDROM=Yes
>
> +WANTLIB-main=# empty
> +WANTLIB-gmpxx= gmp m ${COMPILER_LIBCXX}
> +
> +LIB_DEPENDS-gmpxx= ${BASE_PKGPATH},-main
> +
> +PSEUDO_FLAVORS= no_gmpxx bootstrap
> +FLAVOR?= no_gmpxx bootstrap
> +
> MASTER_SITES=https://gmplib.org/download/gmp/ \
> ${MASTER_SITE_GNU:=gmp/}
>
> CONFIGURE_STYLE=autoconf
> AUTOCONF_VERSION=2.69
> +
> +.include
> +.if ${BUILD_PACKAGES:M-gmpxx}
> +CONFIGURE_ARGS= --enable-cxx
> +.endif
> +
> # Don't try to optimize for the local CPU submodel
> CONFIGURE_ARGS+=--build=${MACHINE_ARCH}-unknown-openbsd${OSrev}
>
> Index: devel/gmp/pkg/DESCR
> ===
> RCS file: devel/gmp/pkg/DESCR
> diff -N devel/gmp/pkg/DESCR
> --- devel/gmp/pkg/DESCR 1 Nov 2006 18:43:09 - 1.3
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,17 +0,0 @@
> -GNU MP is a library for arbitrary precision arithmetic, operating on
> -signed integers, rational numbers, and floating point numbers. It has a
> -rich set of functions, and the functions have a regular interface.
> -
> -GNU MP is designed to be as fast as possible, both for small operands and
> -for huge operands. The speed is achieved by using fullwords as the basic
> -arithmetic type, by using fast algorithms, by carefully optimized assembly
> -code for the most common inner loops for a lots of CPUs, and by a general
> -emphasis on speed (instead of simplicity or elegance).
> -
> -The speed of GNU MP is believed to be faster than any other similar
> -library. The advantage for GNU MP increases with the operand sizes for
> -certain operations, since GNU MP in many cases has asymptotically faster
> -algorithms.
> -
> -The mpfr library is no longer bundled with gmp, but exists as a separate
> -package instead.
> Index: devel/gmp/pkg/DESCR-gmpxx
> ===
> RCS file: devel/gmp/pkg/DESCR-gmpxx
> diff -N devel/gmp/pkg/DESCR-gmpxx
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ devel/gmp/pkg/DESCR-gmpxx 26 Oct 2018 14:57:53 -
> @@ -0,0 +1,5 @@
> +GNU MP is a library for arbitrary precision arithmetic, operating on
> +signed integers, rational numbers, and floating point numbers. It has a
> +rich set of functions, and the functions have a regular interface.
> +
> +This subpackage contains "gmpxx", the C++ support.
> Index: devel/gmp/pkg/DESCR-main
> ===
> RCS file: devel/gmp/pkg/DESCR-main
> diff -N devel/gmp/pkg/DESCR-main
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ devel/gmp/pkg/DESCR-main 26 Oct 2018 14:57:53 -
> @@ -0,0 +1,17 @@
> +GNU MP is a library for arbitrary precision arithmetic, operating on
> +signed integers, rational numbers, and floating point numbers. It has a
> +rich set of functions, and the functions have a regular interface.
> +
> +GNU MP is designed to be as fast as possible, both for small operands and
> +for huge operands. The speed is achieved by using fullwords as the basic
gmpxx, productivity/libalkimia [Re: CVS: cvs.openbsd.org: ports]
On 2018/10/24 09:21, Stuart Henderson wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: st...@cvs.openbsd.org 2018/10/24 09:21:56
>
> Modified files:
> devel/gmp : Makefile
> devel/gmp/pkg : PLIST
>
> Log message:
> disable gmpxx (c++ library), it isn't used in ports or enabled by default
> upstream
> ok naddy@
>
Annoyingly it turns out that productivity/libalkimia uses the gmpxx.h
header but not the library from gmp's C++ support.
This gives a choice between a dirty option (install gmpxx.h anyway)
and the messy option below. I think I've got the bootstrap parts right
but a pair of eyes that understands it better than me wouldn't go
amiss :)
(bumps in dependent ports not shown here but also needed).
Index: devel/gmp/Makefile
===
RCS file: /cvs/ports/devel/gmp/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- devel/gmp/Makefile 24 Oct 2018 15:21:56 - 1.37
+++ devel/gmp/Makefile 26 Oct 2018 14:57:53 -
@@ -1,10 +1,16 @@
# $OpenBSD: Makefile,v 1.37 2018/10/24 15:21:56 sthen Exp $
-COMMENT= library for arbitrary precision arithmetic
+COMMENT-main= library for arbitrary precision arithmetic
+COMMENT-gmpxx= C++ library for arbitrary precision arithmetic
DISTNAME= gmp-6.1.2
-REVISION = 2
+MULTI_PACKAGES=-main -gmpxx
+PKGNAME-main= ${DISTNAME}
+PKGNAME-gmpxx= gmpxx-6.1.2
+
+REVISION = 3
SHARED_LIBS += gmp 10.0 # 13.2
+SHARED_LIBS += gmpxx2.0 # 9.2
CATEGORIES=devel math
HOMEPAGE= https://gmplib.org/
@@ -15,11 +21,25 @@ EXTRACT_SUFX= .tar.xz
# LGPLv3+
PERMIT_PACKAGE_CDROM= Yes
+WANTLIB-main= # empty
+WANTLIB-gmpxx= gmp m ${COMPILER_LIBCXX}
+
+LIB_DEPENDS-gmpxx= ${BASE_PKGPATH},-main
+
+PSEUDO_FLAVORS=no_gmpxx bootstrap
+FLAVOR?= no_gmpxx bootstrap
+
MASTER_SITES= https://gmplib.org/download/gmp/ \
${MASTER_SITE_GNU:=gmp/}
CONFIGURE_STYLE=autoconf
AUTOCONF_VERSION=2.69
+
+.include
+.if ${BUILD_PACKAGES:M-gmpxx}
+CONFIGURE_ARGS=--enable-cxx
+.endif
+
# Don't try to optimize for the local CPU submodel
CONFIGURE_ARGS+=--build=${MACHINE_ARCH}-unknown-openbsd${OSrev}
Index: devel/gmp/pkg/DESCR
===
RCS file: devel/gmp/pkg/DESCR
diff -N devel/gmp/pkg/DESCR
--- devel/gmp/pkg/DESCR 1 Nov 2006 18:43:09 - 1.3
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,17 +0,0 @@
-GNU MP is a library for arbitrary precision arithmetic, operating on
-signed integers, rational numbers, and floating point numbers. It has a
-rich set of functions, and the functions have a regular interface.
-
-GNU MP is designed to be as fast as possible, both for small operands and
-for huge operands. The speed is achieved by using fullwords as the basic
-arithmetic type, by using fast algorithms, by carefully optimized assembly
-code for the most common inner loops for a lots of CPUs, and by a general
-emphasis on speed (instead of simplicity or elegance).
-
-The speed of GNU MP is believed to be faster than any other similar
-library. The advantage for GNU MP increases with the operand sizes for
-certain operations, since GNU MP in many cases has asymptotically faster
-algorithms.
-
-The mpfr library is no longer bundled with gmp, but exists as a separate
-package instead.
Index: devel/gmp/pkg/DESCR-gmpxx
===
RCS file: devel/gmp/pkg/DESCR-gmpxx
diff -N devel/gmp/pkg/DESCR-gmpxx
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/gmp/pkg/DESCR-gmpxx 26 Oct 2018 14:57:53 -
@@ -0,0 +1,5 @@
+GNU MP is a library for arbitrary precision arithmetic, operating on
+signed integers, rational numbers, and floating point numbers. It has a
+rich set of functions, and the functions have a regular interface.
+
+This subpackage contains "gmpxx", the C++ support.
Index: devel/gmp/pkg/DESCR-main
===
RCS file: devel/gmp/pkg/DESCR-main
diff -N devel/gmp/pkg/DESCR-main
--- /dev/null 1 Jan 1970 00:00:00 -
+++ devel/gmp/pkg/DESCR-main26 Oct 2018 14:57:53 -
@@ -0,0 +1,17 @@
+GNU MP is a library for arbitrary precision arithmetic, operating on
+signed integers, rational numbers, and floating point numbers. It has a
+rich set of functions, and the functions have a regular interface.
+
+GNU MP is designed to be as fast as possible, both for small operands and
+for huge operands. The speed is achieved by using fullwords as the basic
+arithmetic type, by using fast algorithms, by carefully optimized assembly
+code for the most common inner loops for a lots of CPUs, and by a general
+emphasis on speed (instead of simplicity or elegance).
+
+The speed of GNU MP is believed to be faster than any other similar
+library. The advantage for GNU MP increases with the operand sizes f
Re: webkitgtk4 / CMakeLists dependencies [Re: CVS: cvs.openbsd.org: ports]
On Sat, May 05, 2018 at 11:00:00AM +0100, Stuart Henderson wrote:
> On 2018/04/10 07:20, Antoine Jacoutot wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: ajacou...@cvs.openbsd.org 2018/04/10 07:20:18
> >
> > Modified files:
> > www/webkitgtk4 : Makefile distinfo
> >
> > Log message:
> > Maintenance update to webkitgtk4-2.20.1.
> >
>
> I'm having some problems getting this built,
>
> In file included from
> DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h:29:
> DerivedSources/ForwardingHeaders/JavaScriptCore/JSObjectRef.h:31:10: fatal
> error: 'JavaScriptCore/JSValueRef.h' file not found
> #include
> ^
> 1 error generated.
>
> Any ideas how to add dependencies in cmake? I've tried things like this
> in Source/JavaScriptCore/CMakeLists.txt but not getting anywhere.
>
> WEBKIT_ADD_SOURCE_DEPENDENCIES(${DERIVED_SOURCES_JAVASCRIPTCORE_DIR}/JSObjectRef.h
> ${DERIVED_SOURCES_JAVASCRIPTCORE_DIR}/JSValueRef.h)
Hmm that's weird, I've never run into that one yet.
--
Antoine
webkitgtk4 / CMakeLists dependencies [Re: CVS: cvs.openbsd.org: ports]
On 2018/04/10 07:20, Antoine Jacoutot wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: ajacou...@cvs.openbsd.org 2018/04/10 07:20:18
>
> Modified files:
> www/webkitgtk4 : Makefile distinfo
>
> Log message:
> Maintenance update to webkitgtk4-2.20.1.
>
I'm having some problems getting this built,
In file included from
DerivedSources/ForwardingHeaders/JavaScriptCore/JSContextRef.h:29:
DerivedSources/ForwardingHeaders/JavaScriptCore/JSObjectRef.h:31:10: fatal
error: 'JavaScriptCore/JSValueRef.h' file not found
#include
^
1 error generated.
Any ideas how to add dependencies in cmake? I've tried things like this
in Source/JavaScriptCore/CMakeLists.txt but not getting anywhere.
WEBKIT_ADD_SOURCE_DEPENDENCIES(${DERIVED_SOURCES_JAVASCRIPTCORE_DIR}/JSObjectRef.h
${DERIVED_SOURCES_JAVASCRIPTCORE_DIR}/JSValueRef.h)
_SYSTEM_VERSION-xx for clang [Re: CVS: cvs.openbsd.org: ports]
On 2018/04/17 15:06, Matthias Kilian wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: k...@cvs.openbsd.org2018/04/17 15:06:07
>
> Modified files:
> x11/qt3: Makefile
>
> Log message:
> Bump the -main subpackage to make sure people get the clang6 fix
> of include/X11/qt3/qgplugin.h.
>
> Found by dpb -uR; a full bulk build won't expose this kind of
> problems.
>
Can anyone see a downside to bumping _SYSTEM_VERSION-xx for clang arches
now to make sure updates are triggered?
Obviously we're not done fixing all the builds yet but we're probably far
enough on that it's about time we made sure people get updated binaries
so we can start getting reports of runtime breakage ...
Index: arch-defines.mk
===
RCS file: /cvs/ports/infrastructure/mk/arch-defines.mk,v
retrieving revision 1.48
diff -u -p -r1.48 arch-defines.mk
--- arch-defines.mk 26 Jan 2018 13:10:08 - 1.48
+++ arch-defines.mk 17 Apr 2018 21:44:54 -
@@ -59,9 +59,9 @@ LIBECXX = estdc++>=17 pthread
# system version wide specifics
_SYSTEM_VERSION = 0
-_SYSTEM_VERSION-i386 = 1
-_SYSTEM_VERSION-amd64 = 1
-_SYSTEM_VERSION-arm = 1
+.for _CLANG_ARCH in ${CLANG_ARCHS}
+_SYSTEM_VERSION-${_CLANG_ARCH} = 2
+.endfor
_SYSTEM_VERSION-${MACHINE_ARCH} ?= 0
_SYSTEM_VERSION-${ARCH} ?= 0
Re: CVS: cvs.openbsd.org: ports
On 2018/04/10 12:19, Stuart Henderson wrote: > On 2018/04/09 12:14, Gonzalo L. Rodriguez wrote: > > On [08/04/18] [10:30P], Stuart Henderson wrote: > > > CVSROOT: /cvs > > > Module name: ports > > > Changes by: st...@cvs.openbsd.org 2018/04/08 04:30:32 > > > > > > Modified files: > > > sysutils/apachetop: Makefile > > > Added files: > > > sysutils/apachetop/patches: patch-src_apachetop_cc > > > patch-src_display_cc > > > patch-src_hits_circle_cc > > > patch-src_log_cc > > > > > > Log message: > > > add clang6 patches from Matthew Martin > > > > > > update homepage while there, someone should look at updating this, > > > the newest release (2017-04) includes a buffer overflow fix > > > > > > > Yes, I was working on that. > > > > Moving to git, and update to the last version with the clang6 fix. > > > > Diff attached. > > > > OK? Comments? > > > > Cheers.- > > > > -- > > Sending from my toaster. > > > Index: Makefile > > === > > RCS file: /cvs/ports/sysutils/apachetop/Makefile,v > > retrieving revision 1.11 > > diff -u -p -r1.11 Makefile > > --- Makefile8 Apr 2018 10:30:32 - 1.11 > > +++ Makefile9 Apr 2018 10:13:05 - > > @@ -2,8 +2,9 @@ > > > > COMMENT = top-like monitor for Apache > > > > -DISTNAME = apachetop-0.12.6 > > -REVISION = 3 > > +GH_ACCOUNT = tessus > > +GH_PROJECT = apachetop > > +GH_TAGNAME = 0.17.4 > > CATEGORIES = sysutils > > > > MAINTAINER = Gonzalo L. R. > > @@ -15,12 +16,16 @@ PERMIT_PACKAGE_CDROM= Yes > > > > MASTER_SITES = http://www.webta.org/apachetop/ > > It doesn't fetch like this. > > apachetop-0.17.4.tar.gz isn't present at http://www.webta.org/apachetop/ > and setting MASTER_SITES here overrides the automatic MASTER_SITES setting > used for GH_*. > > But there is a proper uploaded release on github, so please use that instead. > You can use something like > > V=0.17.4 > DISTNAME= apachetop-$V > MASTER_SITES= https://github.com/tessus/apachetop/releases/download/$V/ > > That also has autoconf files generated so you should be able to go to > CONFIGURE_STYLE=gnu and drop the autoconf dep. > PS: it might be nice to enable adns as well..
Re: CVS: cvs.openbsd.org: ports
On 2018/04/09 12:14, Gonzalo L. Rodriguez wrote: > On [08/04/18] [10:30P], Stuart Henderson wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: st...@cvs.openbsd.org 2018/04/08 04:30:32 > > > > Modified files: > > sysutils/apachetop: Makefile > > Added files: > > sysutils/apachetop/patches: patch-src_apachetop_cc > > patch-src_display_cc > > patch-src_hits_circle_cc > > patch-src_log_cc > > > > Log message: > > add clang6 patches from Matthew Martin > > > > update homepage while there, someone should look at updating this, > > the newest release (2017-04) includes a buffer overflow fix > > > > Yes, I was working on that. > > Moving to git, and update to the last version with the clang6 fix. > > Diff attached. > > OK? Comments? > > Cheers.- > > -- > Sending from my toaster. > Index: Makefile > === > RCS file: /cvs/ports/sysutils/apachetop/Makefile,v > retrieving revision 1.11 > diff -u -p -r1.11 Makefile > --- Makefile 8 Apr 2018 10:30:32 - 1.11 > +++ Makefile 9 Apr 2018 10:13:05 - > @@ -2,8 +2,9 @@ > > COMMENT =top-like monitor for Apache > > -DISTNAME = apachetop-0.12.6 > -REVISION = 3 > +GH_ACCOUNT = tessus > +GH_PROJECT = apachetop > +GH_TAGNAME = 0.17.4 > CATEGORIES = sysutils > > MAINTAINER = Gonzalo L. R. > @@ -15,12 +16,16 @@ PERMIT_PACKAGE_CDROM= Yes > > MASTER_SITES = http://www.webta.org/apachetop/ It doesn't fetch like this. apachetop-0.17.4.tar.gz isn't present at http://www.webta.org/apachetop/ and setting MASTER_SITES here overrides the automatic MASTER_SITES setting used for GH_*. But there is a proper uploaded release on github, so please use that instead. You can use something like V= 0.17.4 DISTNAME= apachetop-$V MASTER_SITES= https://github.com/tessus/apachetop/releases/download/$V/ That also has autoconf files generated so you should be able to go to CONFIGURE_STYLE=gnu and drop the autoconf dep.
Re: CVS: cvs.openbsd.org: ports
On [08/04/18] [10:30P], Stuart Henderson wrote:
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2018/04/08 04:30:32
Modified files:
sysutils/apachetop: Makefile
Added files:
sysutils/apachetop/patches: patch-src_apachetop_cc
patch-src_display_cc
patch-src_hits_circle_cc
patch-src_log_cc
Log message:
add clang6 patches from Matthew Martin
update homepage while there, someone should look at updating this,
the newest release (2017-04) includes a buffer overflow fix
Yes, I was working on that.
Moving to git, and update to the last version with the clang6 fix.
Diff attached.
OK? Comments?
Cheers.-
--
Sending from my toaster.
Index: Makefile
===
RCS file: /cvs/ports/sysutils/apachetop/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile8 Apr 2018 10:30:32 - 1.11
+++ Makefile9 Apr 2018 10:13:05 -
@@ -2,8 +2,9 @@
COMMENT = top-like monitor for Apache
-DISTNAME = apachetop-0.12.6
-REVISION = 3
+GH_ACCOUNT = tessus
+GH_PROJECT = apachetop
+GH_TAGNAME = 0.17.4
CATEGORIES = sysutils
MAINTAINER = Gonzalo L. R.
@@ -15,12 +16,16 @@ PERMIT_PACKAGE_CDROM= Yes
MASTER_SITES = http://www.webta.org/apachetop/
-CONFIGURE_STYLE = autoconf
-AUTOCONF_VERSION = 2.59
+CONFIGURE_STYLE = autoconf automake
+AUTOCONF_VERSION = 2.65
+AUTOMAKE_VERSION = 1.15
-CONFIGURE_ARGS = --disable-fam \
- --with-logfile=/var/www/logs/access_log
+CONFIGURE_ARGS = --with-logfile=/var/www/logs/access_log
-WANTLIB += c m ncurses readline ${COMPILER_LIBCXX}
+WANTLIB += c m curses readline ${COMPILER_LIBCXX}
+
+post-patch:
+ cd ${WRKSRC} && ${SETENV} AUTOCONF_VERSION=${AUTOCONF_VERSION} \
+ AUTOMAKE_VERSION=${AUTOMAKE_VERSION} ./autogen.sh
.include
Index: distinfo
===
RCS file: /cvs/ports/sysutils/apachetop/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- distinfo18 Jan 2015 03:15:09 - 1.2
+++ distinfo9 Apr 2018 10:13:05 -
@@ -1,2 +1,2 @@
-SHA256 (apachetop-0.12.6.tar.gz) = hQBiQUUXBV6rJEC3iLUD1F6+mykNSy4Cel+IetcPPyk=
-SIZE (apachetop-0.12.6.tar.gz) = 126930
+SHA256 (apachetop-0.17.4.tar.gz) = iS7TuDtF6ziBHnTQaAibHow0cHeH8kDOEz2MkxmNf/A=
+SIZE (apachetop-0.17.4.tar.gz) = 42729
Index: patches/patch-src_log_cc
===
RCS file: /cvs/ports/sysutils/apachetop/patches/patch-src_log_cc,v
retrieving revision 1.1
diff -u -p -r1.1 patch-src_log_cc
--- patches/patch-src_log_cc8 Apr 2018 10:30:32 - 1.1
+++ patches/patch-src_log_cc9 Apr 2018 10:13:05 -
@@ -6,13 +6,13 @@ Index: src/log.cc
@@ -37,7 +37,7 @@ int CommonLogParser::parse(char *logline, struct logbi
if (!bufcp)
return -1;
-
+
- *bufcp = (char) NULL;
+ *bufcp = '\0';
++bufcp;
/* quickly figure out if this is an IP or a host. We do this by
-@@ -172,7 +172,7 @@ int CommonLogParser::parse(char *logline, struct logbi
+@@ -176,7 +176,7 @@ int CommonLogParser::parse(char *logline, struct logbi
/* find the end of referrer and null it */
if (!(bufcp = strchr(bufsp, '"')))
return -1;
@@ -21,7 +21,7 @@ Index: src/log.cc
/* unless they want to keep it, skip over the protocol, ie http:// */
if ((cf.preserve_ref_protocol == 0) && (bufcp = strstr(bufsp, "://")))
-@@ -230,7 +230,7 @@ char *LogParser::processURL(char **buf) /* {{{ */
+@@ -234,7 +234,7 @@ char *LogParser::processURL(char **buf) /* {{{ */
return NULL;
/* null the space in front of it */
@@ -30,7 +30,7 @@ Index: src/log.cc
/* TODO maybe we can use the protocol someday.. */
-@@ -258,7 +258,7 @@ int LogParser::mungeURL(char **url, int *length) /* {{
+@@ -262,7 +262,7 @@ int LogParser::mungeURL(char **url, int *length) /* {{
char *bufcp, *endptr, *workptr;
endptr = *url + *length;
@@ -39,7 +39,7 @@ Index: src/log.cc
/* do we want to keep the query string? */
if (!cf.keep_querystring)
-@@ -273,7 +273,7 @@ int LogParser::mungeURL(char **url, int *length) /* {{
+@@ -277,7 +277,7 @@ int LogParser::mungeURL(char **url, int *length) /* {{
if (workptr < endptr)
{
/* we're ok */
@@ -48,7 +48,7 @@ Index: src/log.cc
bufcp = workptr+1;
}
}
-@@ -308,7 +308,7 @@ int LogParser::mungeURL(char **url, int *length) /* {{
+@@ -312,7 +312,7 @@ int LogParser::mungeURL(ch
Re: CVS: cvs.openbsd.org: ports
On Wed, 30 Aug 2017 21:19:43 -0400 Daniel Jakots wrote: > On Wed, 30 Aug 2017 16:43:54 -0600 (MDT), Juan Francisco Cantero > Hurtado wrote: > > > CVSROOT:/cvs > > Module name:ports > > Changes by: juan...@cvs.openbsd.org 2017/08/30 > > 16:43:54 > > > > Modified files: > > lang : Makefile > > lang/cython: Makefile distinfo > > lang/cython/pkg: PLIST > > > > Log message: > > Update to cython 0.26.1. Add python3 flavor. > > Hola juanfra, > > You can't do this. You can add a py3 flavor only for 'py-' prefixed > package otherwise there's no way to differentiate the py2 package from > the py3 one. To see the problem you can do: > > /usr/ports/lang/cython$ FLAVOR="python3" make show=FULLPKGNAME > cython-0.26.1 > /usr/ports/lang/cython$ make show=FULLPKGNAME > cython-0.26.1 > > Also even if this worked, you wouldn't be able to install both py2 and > py3 package because binaries would conflict, they would need to be > renamed. Oh, that's why the tests didn't create a new directory. I will take a look tomorrow. Thanks! -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: CVS: cvs.openbsd.org: ports
On Wed, 30 Aug 2017 16:43:54 -0600 (MDT), Juan Francisco Cantero Hurtado wrote: > CVSROOT: /cvs > Module name: ports > Changes by: juan...@cvs.openbsd.org 2017/08/30 16:43:54 > > Modified files: > lang : Makefile > lang/cython: Makefile distinfo > lang/cython/pkg: PLIST > > Log message: > Update to cython 0.26.1. Add python3 flavor. Hola juanfra, You can't do this. You can add a py3 flavor only for 'py-' prefixed package otherwise there's no way to differentiate the py2 package from the py3 one. To see the problem you can do: /usr/ports/lang/cython$ FLAVOR="python3" make show=FULLPKGNAME cython-0.26.1 /usr/ports/lang/cython$ make show=FULLPKGNAME cython-0.26.1 Also even if this worked, you wouldn't be able to install both py2 and py3 package because binaries would conflict, they would need to be renamed. Cheers, Daniel
audio/calf 0.0.60 [Re: CVS: cvs.openbsd.org: ports]
On 2017/07/27 08:06, Stuart Henderson wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: st...@cvs.openbsd.org 2017/07/27 08:06:31
>
> Modified files:
> audio/calf : Makefile distinfo
> audio/calf/patches: patch-configure patch-src_calf_fixed_point_h
> audio/calf/pkg : PLIST
>
> Log message:
> update to calf-0.0.18.6, switch homepage to http://calf-studio-gear.org/,
> add patch from espie@ fixing clang build on 32-bit arches.
>
> there is also a calf-0.0.60, but that requires additional work.
>
Here's a start at calf-0.0.60 if anyone wants to pick it up.
Fails with "candidate template ignored: deduced conflicting types for
parameter '_Tp' ('float' vs. 'double')"
Index: Makefile
===
RCS file: /cvs/ports/audio/calf/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- Makefile27 Jul 2017 14:06:31 - 1.26
+++ Makefile27 Jul 2017 14:10:44 -
@@ -3,7 +3,7 @@
ONLY_FOR_ARCHS = ${GCC4_ARCHS} ${CLANG_ARCHS}
COMMENT = CALF LADSPA plugins
-DISTNAME = calf-0.0.18.6
+DISTNAME = calf-0.0.60
CATEGORIES = audio
HOMEPAGE = http://calf-studio-gear.org/
@@ -24,7 +24,8 @@ MASTER_SITES =http://calf-studio-gear.
COMPILER = gcc
RUN_DEPENDS = devel/desktop-file-utils \
x11/gtk+3,-guic
-LIB_DEPENDS = audio/jack \
+LIB_DEPENDS = audio/fluidsynth \
+ audio/jack \
devel/libglade2
BUILD_DEPENDS += audio/ladspa
Index: distinfo
===
RCS file: /cvs/ports/audio/calf/distinfo,v
retrieving revision 1.3
diff -u -p -r1.3 distinfo
--- distinfo27 Jul 2017 14:06:31 - 1.3
+++ distinfo27 Jul 2017 14:10:44 -
@@ -1,2 +1,2 @@
-SHA256 (calf-0.0.18.6.tar.gz) = MEcz77r8AMlIB6D41aVhJYk3aSMdtI+NaoibnKeUhg8=
-SIZE (calf-0.0.18.6.tar.gz) = 599207
+SHA256 (calf-0.0.60.tar.gz) = qecVZ0C3GzG1yBcwtXxWue0Dvz7/mJOLOkFsCcDjLgU=
+SIZE (calf-0.0.60.tar.gz) = 5881741
Index: patches/patch-configure
===
RCS file: /cvs/ports/audio/calf/patches/patch-configure,v
retrieving revision 1.2
diff -u -p -r1.2 patch-configure
--- patches/patch-configure 27 Jul 2017 14:06:31 - 1.2
+++ patches/patch-configure 27 Jul 2017 14:10:44 -
@@ -1,8 +1,8 @@
-$OpenBSD: patch-configure,v 1.2 2017/07/27 14:06:31 sthen Exp $
+$OpenBSD: patch-configure,v 1.1.1.1 2010/10/23 21:52:00 jakemsr Exp $
Index: configure
--- configure.orig
+++ configure
-@@ -15066,7 +15066,7 @@ if test "${ac_cv_lib_jack_jack_port_register+set}" = s
+@@ -15904,7 +15904,7 @@ if ${ac_cv_lib_jack_jack_port_register+:} false; then
$as_echo_n "(cached) " >&6
else
ac_check_lib_save_LIBS=$LIBS
@@ -11,12 +11,12 @@ Index: configure
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
-@@ -15493,7 +15493,7 @@ $as_echo "$set_enable_debug" >&6; }
- if test "$set_enable_debug" = "yes"; then
+@@ -16507,7 +16507,7 @@ if test "$set_enable_debug" = "yes"; then
CXXFLAGS="$CXXFLAGS -O0 -g -Wall"
else
+ # TODO: remove -finline options if clang is used
- CXXFLAGS="$CXXFLAGS -O3 -finline-functions -finline-functions-called-once
-Wall"
+ CXXFLAGS="$CXXFLAGS -finline-functions -finline-functions-called-once -Wall"
fi
- if test "$DSSI_FOUND" = "yes"; then
+ if test "$set_enable_sse" = "yes"; then
Index: patches/patch-src_benchmark_cpp
===
RCS file: patches/patch-src_benchmark_cpp
diff -N patches/patch-src_benchmark_cpp
--- patches/patch-src_benchmark_cpp 3 May 2017 09:46:40 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-src_benchmark_cpp,v 1.1 2017/05/03 09:46:40 espie Exp $
-
-Index: src/benchmark.cpp
src/benchmark.cpp.orig
-+++ src/benchmark.cpp
-@@ -25,6 +25,7 @@
- #include
- #include
- #include
-+#include
- #include
- #include
-
Index: patches/patch-src_calf_buffer_h
===
RCS file: patches/patch-src_calf_buffer_h
diff -N patches/patch-src_calf_buffer_h
--- patches/patch-src_calf_buffer_h 3 May 2017 09:46:40 - 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,15 +0,0 @@
-$OpenBSD: patch-src_calf_buffer_h,v 1.1 2017/05/03 09:46:40 espie Exp $
-right, this template never even compiled
-
-Index: src/calf/buffer.h
src/calf/buffer.h.orig
-+++ src/calf/buffer.h
-@@ -153,7 +153,7 @@ void copy_buf(T &dest_buf, const U &src_buf, T scale =
- typedef typename T::data_type data_type;
- data_type *dest = dest_buf.data();
- const data_type *src = src_buf.data();
--int size = src.size();
-+int size = src->size();
- for (int i=0; i class fixed_point { (p
- }
-
- template
--inline U lerp_table_loo
"loadable library and perl binaries are mismatched" [Re: CVS: cvs.openbsd.org: ports]
On 2017/05/11 07:44, Pierre-Emmanuel Andre wrote: > CVSROOT: /cvs > Module name: ports > Changes by: p...@cvs.openbsd.org2017/05/11 07:44:15 > > Modified files: > databases/postgresql: Makefile > Added files: > databases/postgresql/patches: patch-src_pl_plperl_GNUmakefile > > Log message: > Fix bug with create extension plperl > ( Util.c: loadable library and perl binaries are mismatched ) > Spotted and fix by Markus Hennecke, Thanks ! Interesting, I wonder if this is similar to p5-SDL at runtime on i386. I see that the plperl patch adds "-DBIG_TIME" which doesn't appear in the compiler flags on i386 p5-SDL..
Re: CVS: cvs.openbsd.org: ports
I don't know what this has to do with certbot, anyway qtox/toxcore is of no interest to me. On 2017/03/18 00:36, Андрей Болконский wrote: > please make and add the qtox and toxcore ports in tree... > > 2017-03-17 11:58 GMT+03:00 Stuart Henderson : > > CVSROOT: /cvs > Module name: ports > Changes by: st...@cvs.openbsd.org 2017/03/17 02:58:01 > > Modified files: > security/letsencrypt: Makefile.inc > security/letsencrypt/client: distinfo > security/letsencrypt/py-acme: distinfo > > Log message: > update to py-acme/certbot 0.12.0 > > >
Re: CVS: cvs.openbsd.org: ports
Hi,
On Mon, Mar 06, 2017 at 09:04:22AM -0700, Giovanni Bechis wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: giova...@cvs.openbsd.org2017/03/06 09:04:22
>
> Modified files:
> net/unison : Makefile
> Added files:
> net/unison/patches: patch-patch-bytearray_stubs_c
>
> Log message:
> Fix rare SIGSEGV when transferring large replicas.
> from Alex Markley via Davide Gerhard
There is a problem with patch-patch-bytearray_stubs_c.
The file should patch bytearray_stubs.c, but instead it creates a
patch which would patch bytearray_stubs.c. A fix can be found below.
Thanks,
Caspar Schutijser
Index: Makefile
===
RCS file: /cvs/ports/net/unison/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile6 Mar 2017 16:04:22 - 1.11
+++ Makefile12 Mar 2017 20:43:26 -
@@ -4,7 +4,7 @@ COMMENT=multi-platform file synchroniza
CATEGORIES=net
V= 2.48.4
-REVISION= 0
+REVISION= 1
DISTNAME= unison-${V}
MASTER_SITES= ${HOMEPAGE}download/releases/stable/
Index: patches/patch-bytearray_stubs_c
===
RCS file: patches/patch-bytearray_stubs_c
diff -N patches/patch-bytearray_stubs_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-bytearray_stubs_c 12 Mar 2017 20:43:26 -
@@ -0,0 +1,41 @@
+$OpenBSD$
+
+Fix rare SIGSEGV when transferring large replicas.
+Fix a theoretical integer overflow.
+
+References:
+https://github.com/bcpierce00/unison/commit/c1ddff13aa96b124680cce61673129aeb563dbf7
+https://github.com/bcpierce00/unison/commit/f59663d67f4593a5bc1e554058fe6864751e805e
+
+Thanks to Alex Markley and OCaml developers
+--- bytearray_stubs.c.orig Mon May 23 18:40:05 2016
bytearray_stubs.c Sun Mar 12 20:41:53 2017
+@@ -5,6 +5,7 @@
+
+ #include "caml/intext.h"
+ #include "caml/bigarray.h"
++#include "caml/memory.h"
+
+ CAMLprim value ml_marshal_to_bigarray(value v, value flags)
+ {
+@@ -21,15 +22,18 @@ CAMLprim value ml_marshal_to_bigarray(value v, value f
+
+ CAMLprim value ml_unmarshal_from_bigarray(value b, value ofs)
+ {
++ CAMLparam1(b); /* Holds [b] live until unmarshalling completes. */
++ value result;
+ struct caml_bigarray *b_arr = Bigarray_val(b);
+- return input_value_from_block (Array_data (b_arr, ofs),
++ result = input_value_from_block (Array_data (b_arr, ofs),
+ b_arr->dim[0] - Long_val(ofs));
++ CAMLreturn(result);
+ }
+
+ CAMLprim value ml_blit_string_to_bigarray
+ (value s, value i, value a, value j, value l)
+ {
+- char *src = String_val(s) + Int_val(i);
++ char *src = String_val(s) + Long_val(i);
+ char *dest = Array_data(Bigarray_val(a), j);
+ memcpy(dest, src, Long_val(l));
+ return Val_unit;
Index: patches/patch-patch-bytearray_stubs_c
===
RCS file: patches/patch-patch-bytearray_stubs_c
diff -N patches/patch-patch-bytearray_stubs_c
--- patches/patch-patch-bytearray_stubs_c 6 Mar 2017 16:04:22 -
1.1
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,44 +0,0 @@
-$OpenBSD: patch-patch-bytearray_stubs_c,v 1.1 2017/03/06 16:04:22 giovanni Exp
$
patch-bytearray_stubs_c.orig Fri Jan 20 23:42:43 2017
-+++ patch-bytearray_stubs_cFri Jan 20 23:42:56 2017
-@@ -0,0 +1,40 @@
-+
-+Fix rare SIGSEGV when transferring large replicas.
-+Fix a theoretical integer overflow.
-+
-+References:
-+https://github.com/bcpierce00/unison/commit/c1ddff13aa96b124680cce61673129aeb563dbf7
-+https://github.com/bcpierce00/unison/commit/f59663d67f4593a5bc1e554058fe6864751e805e
-+
-+Thanks to Alex Markley and OCaml developers
-+--- bytearray_stubs.c.origTue Jan 17 08:41:00 2017
- bytearray_stubs.c Tue Jan 17 08:41:21 2017
-+@@ -5,6 +5,7 @@
-+ #include "caml/intext.h"
-+
-+ #include "caml/bigarray.h"
-++#include "caml/memory.h"
-+
-+ CAMLprim value ml_marshal_to_bigarray(value v, value flags)
-+ {
-+@@ -21,15 +22,18 @@ CAMLprim value ml_marshal_to_bigarray(value v, value f
-+
-+ CAMLprim value ml_unmarshal_from_bigarray(value b, value ofs)
-+ {
-++ CAMLparam1(b); /* Holds [b] live until unmarshalling completes. */
-++ value result;
-+ struct caml_bigarray *b_arr = Bigarray_val(b);
-+- return input_value_from_block (Array_data (b_arr, ofs),
-++ result = input_value_from_block (Array_data (b_arr, ofs),
-+ b_arr->dim[0] - Long_val(ofs));
-++ CAMLreturn(result);
-+ }
-+
-+ CAMLprim value ml_blit_string_to_bigarray
-+ (value s, value i, value a, value j, value l)
-+ {
-+- char *src = String_val(s) + Int_val(i);
-++ char *src = String_val(s) + Long_val(i);
-+ char *dest = Array_data(Bigarray_val(a), j);
-+ memcpy(dest, src, Long_val(l));
-+ return Val_unit;
make search complains Re: CVS: cvs.openbsd.org: ports
On Tue, 21 Feb 2017 09:43:53 -0700 (MST), Marc Espie
wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: es...@cvs.openbsd.org 2017/02/21 09:43:53
>
> Removed files:
> infrastructure/man/man1: retrieve-index.1
> infrastructure/bin: extract-dependencies find-build-order
> retrieve-index
>
> Log message:
> kill old cruft. keep portslogger as people still use it
>
$ make search name=foobar
Can't open perl script "/usr/ports/infrastructure/bin/retrieve-index":
No such file or directory
*** Warning in /usr/ports: "${_CMD}" returned non-zero status
(Makefile:29)
Re: CVS: cvs.openbsd.org: ports
On 2017/02/01 06:56, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: ports > Changes by: st...@cvs.openbsd.org 2017/02/01 06:56:12 > > Modified files: > x11/qt4: Makefile > > Log message: > Record the dependency on libssl/libcrypto in WANTLIB-main. This would > have been missed previously listed because Qt likes to dlopen() things > so check-lib-depends can't find it, which would stop qt4 getting updated > when ssl/crypto libs are updated. > If you have issues with qt4 or qt5 programs that use TLS following snapshot upgrade, either wait for new packages and run pkg_add -u as normal, or forcibly update qt with "pkg_add -r -D installed qt4" or "pkg_add -r -D installed qt5base" as appropriate.
Re: php: jit in embedded pcre [Re: CVS: cvs.openbsd.org: ports]
ok for me
On (2017-01-26 20:08), Stuart Henderson wrote:
> [moved from ports-changes to ports]
>
> On 2017/01/24 10:08, Stuart Henderson wrote:
> > On 2017/01/23 17:40, Jeremie Courreges-Anglas wrote:
> > > CVSROOT: /cvs
> > > Module name: ports
> > > Changes by: j...@cvs.openbsd.org2017/01/23 17:40:13
> > >
> > > Modified files:
> > > lang/php : Makefile.inc
> > >
> > > Log message:
> > > BROKEN on alpha: pcre_jit_compile.c:65:2: error: #error Unsupported
> > > architecture
> > >
> >
> > hmm. 7.0 now has a way to disable the pcre jit (which I don't think existed
> > when I patched to disable at runtime in
> > 7.0/patches/patch-ext_pcre_php_pcre_c)
> > so we should be able to do this, which I think is preferable.
> >
> > I don't know if the pcre jit even works if it's enabled in config any more;
> > with the current iteration of the kernel code, unless the executable has the
> > wxneeded marker (which it doesn't) those mappings are going to fail anyway.
> >
> > thoughts?
>
> I've been running 7.0 with this on amd64, no problems seen and it seems
> a better idea than my previous 7.0/patches/patch-ext_pcre_php_pcre_c ..
> OK to commit it?
>
>
> > Index: Makefile.inc
> > ===
> > RCS file: /cvs/ports/lang/php/Makefile.inc,v
> > retrieving revision 1.90
> > diff -u -p -r1.90 Makefile.inc
> > --- Makefile.inc24 Jan 2017 00:40:13 - 1.90
> > +++ Makefile.inc24 Jan 2017 10:06:06 -
> > @@ -1,7 +1,5 @@
> > # $OpenBSD: Makefile.inc,v 1.90 2017/01/24 00:40:13 jca Exp $
> > -#
> >
> > -BROKEN-alpha= pcre_jit_compile.c:65:2: error: #error Unsupported
> > architecture
> > BROKEN-hppa= no __sync_bool_compare_and_swap support nor asm fallback
> >
> > COMMENT-main= server-side HTML-embedded scripting language
> > Index: 5.5/Makefile
> > ===
> > RCS file: /cvs/ports/lang/php/5.5/Makefile,v
> > retrieving revision 1.63
> > diff -u -p -r1.63 Makefile
> > --- 5.5/Makefile19 Dec 2016 20:34:22 - 1.63
> > +++ 5.5/Makefile24 Jan 2017 10:06:06 -
> > @@ -1,5 +1,7 @@
> > # $OpenBSD: Makefile,v 1.63 2016/12/19 20:34:22 martijn Exp $
> >
> > +BROKEN-alpha= pcre_jit_compile.c:65:2: error: #error Unsupported
> > architecture
> > +
> > PV=5.5
> > V= ${PV}.38
> > REVISION = 0
> > Index: 5.6/Makefile
> > ===
> > RCS file: /cvs/ports/lang/php/5.6/Makefile,v
> > retrieving revision 1.43
> > diff -u -p -r1.43 Makefile
> > --- 5.6/Makefile22 Jan 2017 17:00:33 - 1.43
> > +++ 5.6/Makefile24 Jan 2017 10:06:06 -
> > @@ -1,5 +1,7 @@
> > # $OpenBSD: Makefile,v 1.43 2017/01/22 17:00:33 martijn Exp $
> >
> > +BROKEN-alpha= pcre_jit_compile.c:65:2: error: #error Unsupported
> > architecture
> > +
> > PV=5.6
> > V= ${PV}.30
> >
> > Index: 7.0/Makefile
> > ===
> > RCS file: /cvs/ports/lang/php/7.0/Makefile,v
> > retrieving revision 1.25
> > diff -u -p -r1.25 Makefile
> > --- 7.0/Makefile22 Jan 2017 17:01:32 - 1.25
> > +++ 7.0/Makefile24 Jan 2017 10:06:06 -
> > @@ -4,10 +4,12 @@ BROKEN-sparc64= SIGBUS during phar gener
> >
> > PV=7.0
> > V= ${PV}.15
> > +REVISION-main= 0
> >
> > WANTLIB-main+= stdc++ ncurses readline
> > BUILD_DEPENDS+=devel/bison
> >
> > CONFIGURE_ENV+=YACC="${LOCALBASE}/bin/bison -y"
> > +CONFIGURE_ARGS+= --with-pcre-jit=no
> >
> > .include
> > Index: 7.0/patches/patch-ext_pcre_php_pcre_c
> > ===
> > RCS file: 7.0/patches/patch-ext_pcre_php_pcre_c
> > diff -N 7.0/patches/patch-ext_pcre_php_pcre_c
> > --- 7.0/patches/patch-ext_pcre_php_pcre_c 19 Dec 2016 20:35:47 -
> > 1.3
> > +++ /dev/null 1 Jan 1970 00:00:00 -
> > @@ -1,12 +0,0 @@
> > -$OpenBSD: patch-ext_pcre_php_pcre_c,v 1.3 2016/12/19 20:35:47 martijn Exp $
> > ext/pcre/php_pcre.c.orig.port Tue Dec 6 19:05:07 2016
> > -+++ ext/pcre/php_pcre.cFri Dec 9 14:17:09 2016
> > -@@ -148,7 +148,7 @@ PHP_INI_BEGIN()
> > - STD_PHP_INI_ENTRY("pcre.backtrack_limit", "100", PHP_INI_ALL,
> > OnUpdateLong, backtrack_limit, zend_pcre_globals, pcre_globals)
> > - STD_PHP_INI_ENTRY("pcre.recursion_limit", "10", PHP_INI_ALL,
> > OnUpdateLong, recursion_limit, zend_pcre_globals, pcre_globals)
> > - #ifdef HAVE_PCRE_JIT_SUPPORT
> > -- STD_PHP_INI_ENTRY("pcre.jit", "1", PHP_INI_ALL,
> > OnUpdateBool, jit, zend_pcre_globals, pcre_globals)
> > -+ STD_PHP_INI_ENTRY("pcre.jit", "0", PHP_INI_ALL,
> > OnUpdateBool, jit, zend_pcre_globals, pcre_globals)
> > - #endif
> > - PHP_INI_END()
> > -
> >
Re: php: jit in embedded pcre [Re: CVS: cvs.openbsd.org: ports]
[moved from ports-changes to ports]
On 2017/01/24 10:08, Stuart Henderson wrote:
> On 2017/01/23 17:40, Jeremie Courreges-Anglas wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: j...@cvs.openbsd.org2017/01/23 17:40:13
> >
> > Modified files:
> > lang/php : Makefile.inc
> >
> > Log message:
> > BROKEN on alpha: pcre_jit_compile.c:65:2: error: #error Unsupported
> > architecture
> >
>
> hmm. 7.0 now has a way to disable the pcre jit (which I don't think existed
> when I patched to disable at runtime in 7.0/patches/patch-ext_pcre_php_pcre_c)
> so we should be able to do this, which I think is preferable.
>
> I don't know if the pcre jit even works if it's enabled in config any more;
> with the current iteration of the kernel code, unless the executable has the
> wxneeded marker (which it doesn't) those mappings are going to fail anyway.
>
> thoughts?
I've been running 7.0 with this on amd64, no problems seen and it seems
a better idea than my previous 7.0/patches/patch-ext_pcre_php_pcre_c ..
OK to commit it?
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/lang/php/Makefile.inc,v
> retrieving revision 1.90
> diff -u -p -r1.90 Makefile.inc
> --- Makefile.inc 24 Jan 2017 00:40:13 - 1.90
> +++ Makefile.inc 24 Jan 2017 10:06:06 -
> @@ -1,7 +1,5 @@
> # $OpenBSD: Makefile.inc,v 1.90 2017/01/24 00:40:13 jca Exp $
> -#
>
> -BROKEN-alpha=pcre_jit_compile.c:65:2: error: #error Unsupported
> architecture
> BROKEN-hppa= no __sync_bool_compare_and_swap support nor asm fallback
>
> COMMENT-main=server-side HTML-embedded scripting language
> Index: 5.5/Makefile
> ===
> RCS file: /cvs/ports/lang/php/5.5/Makefile,v
> retrieving revision 1.63
> diff -u -p -r1.63 Makefile
> --- 5.5/Makefile 19 Dec 2016 20:34:22 - 1.63
> +++ 5.5/Makefile 24 Jan 2017 10:06:06 -
> @@ -1,5 +1,7 @@
> # $OpenBSD: Makefile,v 1.63 2016/12/19 20:34:22 martijn Exp $
>
> +BROKEN-alpha=pcre_jit_compile.c:65:2: error: #error Unsupported
> architecture
> +
> PV= 5.5
> V= ${PV}.38
> REVISION = 0
> Index: 5.6/Makefile
> ===
> RCS file: /cvs/ports/lang/php/5.6/Makefile,v
> retrieving revision 1.43
> diff -u -p -r1.43 Makefile
> --- 5.6/Makefile 22 Jan 2017 17:00:33 - 1.43
> +++ 5.6/Makefile 24 Jan 2017 10:06:06 -
> @@ -1,5 +1,7 @@
> # $OpenBSD: Makefile,v 1.43 2017/01/22 17:00:33 martijn Exp $
>
> +BROKEN-alpha=pcre_jit_compile.c:65:2: error: #error Unsupported
> architecture
> +
> PV= 5.6
> V= ${PV}.30
>
> Index: 7.0/Makefile
> ===
> RCS file: /cvs/ports/lang/php/7.0/Makefile,v
> retrieving revision 1.25
> diff -u -p -r1.25 Makefile
> --- 7.0/Makefile 22 Jan 2017 17:01:32 - 1.25
> +++ 7.0/Makefile 24 Jan 2017 10:06:06 -
> @@ -4,10 +4,12 @@ BROKEN-sparc64= SIGBUS during phar gener
>
> PV= 7.0
> V= ${PV}.15
> +REVISION-main= 0
>
> WANTLIB-main+= stdc++ ncurses readline
> BUILD_DEPENDS+= devel/bison
>
> CONFIGURE_ENV+= YACC="${LOCALBASE}/bin/bison -y"
> +CONFIGURE_ARGS+= --with-pcre-jit=no
>
> .include
> Index: 7.0/patches/patch-ext_pcre_php_pcre_c
> ===
> RCS file: 7.0/patches/patch-ext_pcre_php_pcre_c
> diff -N 7.0/patches/patch-ext_pcre_php_pcre_c
> --- 7.0/patches/patch-ext_pcre_php_pcre_c 19 Dec 2016 20:35:47 -
> 1.3
> +++ /dev/null 1 Jan 1970 00:00:00 -
> @@ -1,12 +0,0 @@
> -$OpenBSD: patch-ext_pcre_php_pcre_c,v 1.3 2016/12/19 20:35:47 martijn Exp $
> ext/pcre/php_pcre.c.orig.portTue Dec 6 19:05:07 2016
> -+++ ext/pcre/php_pcre.c Fri Dec 9 14:17:09 2016
> -@@ -148,7 +148,7 @@ PHP_INI_BEGIN()
> - STD_PHP_INI_ENTRY("pcre.backtrack_limit", "100", PHP_INI_ALL,
> OnUpdateLong, backtrack_limit, zend_pcre_globals, pcre_globals)
> - STD_PHP_INI_ENTRY("pcre.recursion_limit", "10", PHP_INI_ALL,
> OnUpdateLong, recursion_limit, zend_pcre_globals, pcre_globals)
> - #ifdef HAVE_PCRE_JIT_SUPPORT
> --STD_PHP_INI_ENTRY("pcre.jit", "1", PHP_INI_ALL,
> OnUpdateBool, jit, zend_pcre_globals, pcre_globals)
> -+STD_PHP_INI_ENTRY("pcre.jit", "0", PHP_INI_ALL,
> OnUpdateBool, jit, zend_pcre_globals, pcre_globals)
> - #endif
> - PHP_INI_END()
> -
>
Re: urlwatch update/'TypeError: expected string or buffer' [Re: CVS: cvs.openbsd.org: ports]
On 2016/11/08 16:51, Sebastien Marie wrote: > On Tue, Nov 08, 2016 at 03:22:15PM +, Stuart Henderson wrote: > > I've tried updating to git head and same problem. > > I also saw the "TypeError: expected string or buffer" error message. > > The problem is in the installed ~/.urlwatch/hooks.py file: some examples > aren't commented, and there is a problem somewhere: a "match" that > shouldn't, and it breaks with cryptic python exception. So just keeping > what I need in the file solves the problem for me. Ah! Thank you very much, that solves it for me too. > > Also one or two times > > since the update I've seen what looks like a hang where it sits in > > state:thrsleep with no activity apparent in ktrace. > > I personnally didn't see it. It might possibly be connected with the other problem, so I'll keep an eye on things and see if it recurs. > > It's a bit awkward since the database and config has changed completely. > > But unless anyone has ideas of what might be wrong I think it might be a > > good idea to revert www/urlwatch and add a new urlwatch2 port for those > > that want it, what does anyone else think? > > As the switch from urlwatch to urlwatch2 could take lot of time for a > complete transition, it could be a good solution :) > > In my case, I already switched, so please at least add a new urlwatch2. For most cases it should be quite simple I think, and the newer version seems a lot faster so far. So if this solves the problem, let's keep things simple and just have one version. I'll open an issue upstream, but if I don't get a better idea, maybe we should comment-out the entries for now..
Re: urlwatch update/'TypeError: expected string or buffer' [Re: CVS: cvs.openbsd.org: ports]
On Tue, Nov 08, 2016 at 03:22:15PM +, Stuart Henderson wrote: > I've tried updating to git head and same problem. I also saw the "TypeError: expected string or buffer" error message. The problem is in the installed ~/.urlwatch/hooks.py file: some examples aren't commented, and there is a problem somewhere: a "match" that shouldn't, and it breaks with cryptic python exception. So just keeping what I need in the file solves the problem for me. > Also one or two times > since the update I've seen what looks like a hang where it sits in > state:thrsleep with no activity apparent in ktrace. I personnally didn't see it. > It's a bit awkward since the database and config has changed completely. > But unless anyone has ideas of what might be wrong I think it might be a > good idea to revert www/urlwatch and add a new urlwatch2 port for those > that want it, what does anyone else think? As the switch from urlwatch to urlwatch2 could take lot of time for a complete transition, it could be a good solution :) In my case, I already switched, so please at least add a new urlwatch2. Thanks. -- Sebastien Marie > > > On 2016/11/01 15:57, Stuart Henderson wrote: > > On 2016/11/01 08:20, Robert Peichaer wrote: > > > CVSROOT: /cvs > > > Module name: ports > > > Changes by: r...@cvs.openbsd.org2016/11/01 08:20:15 > > > > > > Modified files: > > > www/urlwatch : Makefile distinfo > > > www/urlwatch/pkg: PLIST > > > Removed files: > > > www/urlwatch/patches: patch-lib_urlwatch_html2txt_py > > > > > > Log message: > > > Update www/urlwatch to version 2. > > > > > > This is a major update for urlwatch which is now a python3 program. > > > Consider looking at the README.md at https://github.com/thp/urlwatch > > > if you are migrating from version 1. > > > > > > Noteable changes: > > > - the urls file is now in PyYaml format and will be auto-convertert > > > - watching ftp:// URLs needs a workaround like: > > > kind: shell > > > command: curl ftp://url/path/ > > > - custom hooks are different and need rewriting > > > > > > Feedback from and OK sthen@ aja@ > > > > > > > It was working when I first tried, but now command execution is resulting > > in errors like this, > > > > --- > > ERROR: curl -s ftp://ftp.astron.com/pub/file/ > > --- > > Traceback (most recent call last): > > File "/usr/local/lib/python3.4/site-packages/urlwatch/handler.py", line > > 69, in process > > data = FilterBase.auto_process(self, data) > > File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line > > 73, in auto_process > > if filter_instance.match(): > > File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line > > 115, in match > > result = all(v.match(d.get(k, None)) for k, v in self.MATCH.items()) > > File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line > > 115, in > > result = all(v.match(d.get(k, None)) for k, v in self.MATCH.items()) > > TypeError: expected string or buffer > > --- > > > > With 'urlwatch -v', > > > > 2016-11-01 15:30:21,996 handler INFO: Processing: > > 2016-11-01 15:30:23,553 filters DEBUG: Matching > object at 0x8de58cf6a58> with result: False > > 2016-11-01 15:30:23,553 urlwatch DEBUG: Job finished: > > 2016-11-01 15:30:23,554 handler DEBUG: Got exception while processing > > : expected string > > or buffer > > > > Does anyone have an idea what might be wrong? > > > -- Sebastien Marie
Re: urlwatch update/'TypeError: expected string or buffer' [Re: CVS: cvs.openbsd.org: ports]
I've tried updating to git head and same problem. Also one or two times since the update I've seen what looks like a hang where it sits in state:thrsleep with no activity apparent in ktrace. It's a bit awkward since the database and config has changed completely. But unless anyone has ideas of what might be wrong I think it might be a good idea to revert www/urlwatch and add a new urlwatch2 port for those that want it, what does anyone else think? On 2016/11/01 15:57, Stuart Henderson wrote: > On 2016/11/01 08:20, Robert Peichaer wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: r...@cvs.openbsd.org2016/11/01 08:20:15 > > > > Modified files: > > www/urlwatch : Makefile distinfo > > www/urlwatch/pkg: PLIST > > Removed files: > > www/urlwatch/patches: patch-lib_urlwatch_html2txt_py > > > > Log message: > > Update www/urlwatch to version 2. > > > > This is a major update for urlwatch which is now a python3 program. > > Consider looking at the README.md at https://github.com/thp/urlwatch > > if you are migrating from version 1. > > > > Noteable changes: > > - the urls file is now in PyYaml format and will be auto-convertert > > - watching ftp:// URLs needs a workaround like: > > kind: shell > > command: curl ftp://url/path/ > > - custom hooks are different and need rewriting > > > > Feedback from and OK sthen@ aja@ > > > > It was working when I first tried, but now command execution is resulting > in errors like this, > > --- > ERROR: curl -s ftp://ftp.astron.com/pub/file/ > --- > Traceback (most recent call last): > File "/usr/local/lib/python3.4/site-packages/urlwatch/handler.py", line 69, > in process > data = FilterBase.auto_process(self, data) > File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line 73, > in auto_process > if filter_instance.match(): > File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line > 115, in match > result = all(v.match(d.get(k, None)) for k, v in self.MATCH.items()) > File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line > 115, in > result = all(v.match(d.get(k, None)) for k, v in self.MATCH.items()) > TypeError: expected string or buffer > --- > > With 'urlwatch -v', > > 2016-11-01 15:30:21,996 handler INFO: Processing: > 2016-11-01 15:30:23,553 filters DEBUG: Matching object at 0x8de58cf6a58> with result: False > 2016-11-01 15:30:23,553 urlwatch DEBUG: Job finished: > 2016-11-01 15:30:23,554 handler DEBUG: Got exception while processing command='curl -s ftp://ftp.astron.com/pub/file/'>: expected string or buffer > > Does anyone have an idea what might be wrong? >
urlwatch update/'TypeError: expected string or buffer' [Re: CVS: cvs.openbsd.org: ports]
On 2016/11/01 08:20, Robert Peichaer wrote: > CVSROOT: /cvs > Module name: ports > Changes by: r...@cvs.openbsd.org2016/11/01 08:20:15 > > Modified files: > www/urlwatch : Makefile distinfo > www/urlwatch/pkg: PLIST > Removed files: > www/urlwatch/patches: patch-lib_urlwatch_html2txt_py > > Log message: > Update www/urlwatch to version 2. > > This is a major update for urlwatch which is now a python3 program. > Consider looking at the README.md at https://github.com/thp/urlwatch > if you are migrating from version 1. > > Noteable changes: > - the urls file is now in PyYaml format and will be auto-convertert > - watching ftp:// URLs needs a workaround like: > kind: shell > command: curl ftp://url/path/ > - custom hooks are different and need rewriting > > Feedback from and OK sthen@ aja@ > It was working when I first tried, but now command execution is resulting in errors like this, --- ERROR: curl -s ftp://ftp.astron.com/pub/file/ --- Traceback (most recent call last): File "/usr/local/lib/python3.4/site-packages/urlwatch/handler.py", line 69, in process data = FilterBase.auto_process(self, data) File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line 73, in auto_process if filter_instance.match(): File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line 115, in match result = all(v.match(d.get(k, None)) for k, v in self.MATCH.items()) File "/usr/local/lib/python3.4/site-packages/urlwatch/filters.py", line 115, in result = all(v.match(d.get(k, None)) for k, v in self.MATCH.items()) TypeError: expected string or buffer --- With 'urlwatch -v', 2016-11-01 15:30:21,996 handler INFO: Processing: 2016-11-01 15:30:23,553 filters DEBUG: Matching with result: False 2016-11-01 15:30:23,553 urlwatch DEBUG: Job finished: 2016-11-01 15:30:23,554 handler DEBUG: Got exception while processing : expected string or buffer Does anyone have an idea what might be wrong?
Re: emulators/qemu wxneeded (was: Re: CVS: cvs.openbsd.org: ports)
On Thu, Aug 25, 2016 at 03:48:11PM +0100, Stuart Henderson wrote: > On 2016/08/25 16:35, Christian Weisgerber wrote: > > Jasper Lievisse Adriaanse: > > > > > CVSROOT: /cvs > > > Module name: ports > > > Changes by: jas...@cvs.openbsd.org 2016/08/25 02:56:12 > > > > > > Modified files: > > > emulators/qemu : Makefile > > > > > > Log message: > > > annotate two more ports that were marked as wxneeded with USE_WXNEEDED, > > > even though in both cases it doesn't work yet, at least they're marked > > > so they are indexed by sqlports > > > > How does this fail to work? > > > > I removed -Wl,-z,wxneeded from EXTRA_LDFLAGS, did a test build, and > > the qemu executables all end up with OPENBSD_WXNEEDED in the program > > header. > > > > -- > > Christian "naddy" Weisgerber na...@mips.inka.de > > > > I think that was a gcc4 one. Crikey, you're right. gcc wasn't properly up to date. I'll double check and fix it when it's done building. Thanks, -- jasper
Re: emulators/qemu wxneeded (was: Re: CVS: cvs.openbsd.org: ports)
On 2016/08/25 16:35, Christian Weisgerber wrote: > Jasper Lievisse Adriaanse: > > > CVSROOT:/cvs > > Module name:ports > > Changes by: jas...@cvs.openbsd.org 2016/08/25 02:56:12 > > > > Modified files: > > emulators/qemu : Makefile > > > > Log message: > > annotate two more ports that were marked as wxneeded with USE_WXNEEDED, > > even though in both cases it doesn't work yet, at least they're marked > > so they are indexed by sqlports > > How does this fail to work? > > I removed -Wl,-z,wxneeded from EXTRA_LDFLAGS, did a test build, and > the qemu executables all end up with OPENBSD_WXNEEDED in the program > header. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > I think that was a gcc4 one.
emulators/qemu wxneeded (was: Re: CVS: cvs.openbsd.org: ports)
Jasper Lievisse Adriaanse: > CVSROOT: /cvs > Module name: ports > Changes by: jas...@cvs.openbsd.org 2016/08/25 02:56:12 > > Modified files: > emulators/qemu : Makefile > > Log message: > annotate two more ports that were marked as wxneeded with USE_WXNEEDED, > even though in both cases it doesn't work yet, at least they're marked > so they are indexed by sqlports How does this fail to work? I removed -Wl,-z,wxneeded from EXTRA_LDFLAGS, did a test build, and the qemu executables all end up with OPENBSD_WXNEEDED in the program header. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: CVS: cvs.openbsd.org: ports
On Sat, Jun 11, 2016 at 09:51:29PM +0100, Stuart Henderson wrote:
> On 2016/06/08 22:20, Sebastien Marie wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: sema...@cvs.openbsd.org 2016/06/08 22:20:10
> >
> > Modified files:
> > lang/rust : Makefile distinfo
> > lang/rust/patches: patch-src_librustdoc_test_rs
> >patch-src_libstd_sys_unix_os_rs
> > Added files:
> > lang/rust/patches: patch-mk_main_mk
> >
> > Log message:
> > lang/rust: change bootstrap method
> >
> > OK juanfra@
> >
>
> +DISTFILES += rustc-bootstrap-${MACHINE_ARCH}-${BV}.tar.gz:0
>
> dpb fetching is run on all arches, including ones which are not
> listed in "ONLY_FOR_ARCHS", so whatever makes it into DISTFILES
> needs to be fetchable.
>
> Diff below is probably the easiest way out for now, unless someone
> has a better idea.
ah, I missed that fetching was done on all archs. sorry.
the diff is OK semarie@
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/rust/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile 9 Jun 2016 04:20:10 - 1.24
> +++ Makefile 11 Jun 2016 20:48:33 -
> @@ -38,7 +38,9 @@ MASTER_SITES0 = http://semarie.free.fr/
>
> DIST_SUBDIR =rust
> DISTFILES = ${DISTNAME}${EXTRACT_SUFX}
> +.if "${MACHINE_ARCH}" == "amd64"
> DISTFILES += rustc-bootstrap-${MACHINE_ARCH}-${BV}.tar.gz:0
> +.endif
>
> SUPDISTFILES = rustc-bootstrap-amd64-${BV}.tar.gz:0
>
>
> Also noticed while there..
>
> RUST_HASH !=echo -n ${V} | md5 | cut -c1-8
>
> afaik we try to avoid "!=" in Makefiles unless it's unavoidable..
>
I switched from manually setting the version to this more "automatic"
way. But I could revert to manual way if it is preferable.
--
Sebastien Marie
Re: CVS: cvs.openbsd.org: ports
On 2016/06/08 22:20, Sebastien Marie wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: sema...@cvs.openbsd.org 2016/06/08 22:20:10
>
> Modified files:
> lang/rust : Makefile distinfo
> lang/rust/patches: patch-src_librustdoc_test_rs
> patch-src_libstd_sys_unix_os_rs
> Added files:
> lang/rust/patches: patch-mk_main_mk
>
> Log message:
> lang/rust: change bootstrap method
>
> OK juanfra@
>
+DISTFILES += rustc-bootstrap-${MACHINE_ARCH}-${BV}.tar.gz:0
dpb fetching is run on all arches, including ones which are not
listed in "ONLY_FOR_ARCHS", so whatever makes it into DISTFILES
needs to be fetchable.
Diff below is probably the easiest way out for now, unless someone
has a better idea.
Index: Makefile
===
RCS file: /cvs/ports/lang/rust/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile9 Jun 2016 04:20:10 - 1.24
+++ Makefile11 Jun 2016 20:48:33 -
@@ -38,7 +38,9 @@ MASTER_SITES0 = http://semarie.free.fr/
DIST_SUBDIR = rust
DISTFILES =${DISTNAME}${EXTRACT_SUFX}
+.if "${MACHINE_ARCH}" == "amd64"
DISTFILES += rustc-bootstrap-${MACHINE_ARCH}-${BV}.tar.gz:0
+.endif
SUPDISTFILES = rustc-bootstrap-amd64-${BV}.tar.gz:0
Also noticed while there..
RUST_HASH !=echo -n ${V} | md5 | cut -c1-8
afaik we try to avoid "!=" in Makefiles unless it's unavoidable..
Re: rsyslog [Re: CVS: cvs.openbsd.org: ports]
On 2016/03/13 15:07, Chris Cappuccio wrote: > Stuart Henderson [s...@spacehopper.org] wrote: > > On 2016/03/06 05:18, Antoine Jacoutot wrote: > > > CVSROOT: /cvs > > > Module name: ports > > > Changes by: ajacou...@cvs.openbsd.org 2016/03/06 05:18:31 > > > > > > Modified files: > > > sysutils/rsyslog: Makefile > > > sysutils/rsyslog/patches: patch-runtime_nsd_gtls_c > > > > > > Log message: > > > Fix build with GnuTLS >= 3.4 > > > On a side note, this port could use an update... > > > > > > > chris@ asked about this the other day too. here's a possible diff, > > it builds but I haven't tried running it yet. > > > > also since I don't use this I have no idea if we actually want > > liblogging-stdlog or if it's ok to disable for now. > > > > sample config is from chris. > > > > Just an anecdotal report, this port has been working for me for > logging remote syslog to PostgreSQL. > > Chris > I think it probably makes sense to commit so we can get some wider testing, if people run into problems they can always reply here later. Any objections?
Re: rsyslog [Re: CVS: cvs.openbsd.org: ports]
Stuart Henderson [s...@spacehopper.org] wrote: > On 2016/03/06 05:18, Antoine Jacoutot wrote: > > CVSROOT:/cvs > > Module name:ports > > Changes by: ajacou...@cvs.openbsd.org 2016/03/06 05:18:31 > > > > Modified files: > > sysutils/rsyslog: Makefile > > sysutils/rsyslog/patches: patch-runtime_nsd_gtls_c > > > > Log message: > > Fix build with GnuTLS >= 3.4 > > On a side note, this port could use an update... > > > > chris@ asked about this the other day too. here's a possible diff, > it builds but I haven't tried running it yet. > > also since I don't use this I have no idea if we actually want > liblogging-stdlog or if it's ok to disable for now. > > sample config is from chris. > Just an anecdotal report, this port has been working for me for logging remote syslog to PostgreSQL. Chris
Re: [mail/sendmail] Re: CVS: cvs.openbsd.org: ports
Matthieu Herrb writes: > On Mon, Mar 07, 2016 at 04:27:04AM -0700, Matthieu Herrb wrote: >> CVSROOT: /cvs >> Module name: ports >> Changes by: matth...@cvs.openbsd.org2016/03/07 04:27:04 >> >> Modified files: >> mail/sendmail : Tag: OPENBSD_5_9 Makefile >> mail/sendmail/files/cf: Tag: OPENBSD_5_9 openbsd-submit.mc >> Added files: >> mail/sendmail/patches: Tag: OPENBSD_5_9 patch-cf_feature_msp_m4 >> >> Log message: >> Replace reference to the old smmsp user to the new _smmsp in the >> main shared configuration, so that all generated configuration use it. >> ok and help sthen@, jca@ > > hmm I didn't intend to commit this to -stable. My mistake. > Should I back it out ? I think it should be backed out. While I'm nearly sure that it won't break anything, let's not make exceptions for no good reason. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
[mail/sendmail] Re: CVS: cvs.openbsd.org: ports
On Mon, Mar 07, 2016 at 04:27:04AM -0700, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: ports > Changes by: matth...@cvs.openbsd.org2016/03/07 04:27:04 > > Modified files: > mail/sendmail : Tag: OPENBSD_5_9 Makefile > mail/sendmail/files/cf: Tag: OPENBSD_5_9 openbsd-submit.mc > Added files: > mail/sendmail/patches: Tag: OPENBSD_5_9 patch-cf_feature_msp_m4 > > Log message: > Replace reference to the old smmsp user to the new _smmsp in the > main shared configuration, so that all generated configuration use it. > ok and help sthen@, jca@ hmm I didn't intend to commit this to -stable. My mistake. Should I back it out ? -- Matthieu Herrb pgptur0tFaYcz.pgp Description: PGP signature
Re: rsyslog [Re: CVS: cvs.openbsd.org: ports]
On Sun, Mar 06, 2016 at 12:35:45PM +, Stuart Henderson wrote:
> On 2016/03/06 05:18, Antoine Jacoutot wrote:
> > CVSROOT:/cvs
> > Module name:ports
> > Changes by: ajacou...@cvs.openbsd.org 2016/03/06 05:18:31
> >
> > Modified files:
> > sysutils/rsyslog: Makefile
> > sysutils/rsyslog/patches: patch-runtime_nsd_gtls_c
> >
> > Log message:
> > Fix build with GnuTLS >= 3.4
> > On a side note, this port could use an update...
> >
>
> chris@ asked about this the other day too. here's a possible diff,
> it builds but I haven't tried running it yet.
Ah cool. It'd be nice if people using it could give it a spin.
librelp needs the gettext MODULE.
> also since I don't use this I have no idea if we actually want
> liblogging-stdlog or if it's ok to disable for now.
No clue either.
> sample config is from chris.
>
> I guess we are now going to see missing WANTLIB on idn all
> across the tree ;)
Oh yeah baby :-)
> Index: librelp/Makefile
> ===
> RCS file: /cvs/ports/sysutils/librelp/Makefile,v
> retrieving revision 1.5
> diff -u -p -r1.5 Makefile
> --- librelp/Makefile 16 Mar 2015 18:07:55 - 1.5
> +++ librelp/Makefile 6 Mar 2016 12:34:54 -
> @@ -1,20 +1,28 @@
> -# $OpenBSD: Makefile,v 1.5 2015/03/16 18:07:55 naddy Exp $
> +# $OpenBSD: Makefile.template,v 1.73 2016/01/11 09:17:22 sthen Exp $
>
> COMMENT =reliable event logging protocol library
>
> -DISTNAME = librelp-1.0.1
> +DISTNAME = librelp-1.2.9
> +
> +SHARED_LIBS += relp 1.0 # 1.0
> +
> CATEGORIES = sysutils
> -MASTER_SITES = http://download.rsyslog.com/librelp/
> +
> HOMEPAGE = http://www.librelp.com/
> -REVISION = 0
>
> MAINTAINER = Todd T. Fries
>
> -SHARED_LIBS += relp 0.1 # 0.1
> -
> -# GPLv3
> +# GPLv3+
> PERMIT_PACKAGE_CDROM = Yes
>
> +WANTLIB += ffi gmp gnutls hogweed iconv intl nettle p11-kit pthread
> +WANTLIB += tasn1 z
> +
> +MASTER_SITES = http://download.rsyslog.com/librelp/
> +
> +SEPARATE_BUILD = Yes
> CONFIGURE_STYLE =gnu
> +
> +LIB_DEPENDS =security/gnutls
>
> .include
> Index: librelp/distinfo
> ===
> RCS file: /cvs/ports/sysutils/librelp/distinfo,v
> retrieving revision 1.2
> diff -u -p -r1.2 distinfo
> --- librelp/distinfo 8 Jan 2013 17:36:39 - 1.2
> +++ librelp/distinfo 6 Mar 2016 12:34:54 -
> @@ -1,2 +1,2 @@
> -SHA256 (librelp-1.0.1.tar.gz) = drAQqpFJl2gC2qLl/aesAqiiJ7DIwNEGnuwtKmYpc5o=
> -SIZE (librelp-1.0.1.tar.gz) = 355401
> +SHA256 (librelp-1.2.9.tar.gz) = Ug3nuj3GiNxyxbAU3GHvGR6VKPd9FlHdylX8DBSdmKM=
> +SIZE (librelp-1.2.9.tar.gz) = 415909
> Index: rsyslog/Makefile
> ===
> RCS file: /cvs/ports/sysutils/rsyslog/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- rsyslog/Makefile 6 Mar 2016 12:18:31 - 1.26
> +++ rsyslog/Makefile 6 Mar 2016 12:34:54 -
> @@ -6,39 +6,40 @@ BROKEN-hppa = lack of atomic ops
> SHARED_ONLY =Yes
>
> COMMENT-main = syslog daemon supporting databases, TCP, SSL,
> RELP
> -COMMENT-docs = additional html documentation for rsyslog
> -COMMENT-mysql = mysql plugin for rsyslog
> -COMMENT-pgsql = postgresql plugin for rsyslog
> +COMMENT-mysql = MySQL plugin for rsyslog
> +COMMENT-pgsql = Postgres plugin for rsyslog
>
> -MULTI_PACKAGES = -main -docs -mysql -pgsql
> +MULTI_PACKAGES = -main -mysql -pgsql
>
> -V = 4.6.4
> +V = 8.16.0
> DISTNAME = rsyslog-$V
> PKGNAME-main = rsyslog-$V
> -PKGNAME-docs = rsyslog-docs-$V
> PKGNAME-mysql = rsyslog-mysql-$V
> PKGNAME-pgsql = rsyslog-pgsql-$V
> CATEGORIES = sysutils
>
> -REVISION-main = 8
> -REVISION-docs = 0
> -REVISION-mysql = 6
> -REVISION-pgsql = 3
> -
> HOMEPAGE = http://www.rsyslog.com/
>
> # GPLv3+
> PERMIT_PACKAGE_CDROM = Yes
>
> -MODULES =devel/gettext
> +WANTLIB-main += ${MODGETTEXT_WANTLIB}
> +WANTLIB-main += c estr ffi gcrypt gmp gnutls gpg-error hogweed
> idn
> +WANTLIB-main += json-c nettle p11-kit pthread relp tasn1 uuid z
> +
> +WANTLIB-mysql += crypto m mysqlclient pthread ssl stdc++ z
>
> -WANTLIB-main += c gmp hogweed nettle ffi gnutls pthread p11-kit
> -WANTLIB-main += relp tasn1 z ${MODGETTEXT_WANTLIB}
> -WANTLIB-mysql += crypto m mysqlclient ssl z pthread stdc++
> WANTLIB-pgsql += crypto pq ssl
>
> -LIB_DEPENDS-main = security/gnutls \
> - sysutils/librelp
> +MODULES =devel/gettext
> +
> +LIB_DEPENDS-main = devel/json-c \
> +
rsyslog [Re: CVS: cvs.openbsd.org: ports]
On 2016/03/06 05:18, Antoine Jacoutot wrote:
> CVSROOT: /cvs
> Module name: ports
> Changes by: ajacou...@cvs.openbsd.org 2016/03/06 05:18:31
>
> Modified files:
> sysutils/rsyslog: Makefile
> sysutils/rsyslog/patches: patch-runtime_nsd_gtls_c
>
> Log message:
> Fix build with GnuTLS >= 3.4
> On a side note, this port could use an update...
>
chris@ asked about this the other day too. here's a possible diff,
it builds but I haven't tried running it yet.
also since I don't use this I have no idea if we actually want
liblogging-stdlog or if it's ok to disable for now.
sample config is from chris.
I guess we are now going to see missing WANTLIB on idn all
across the tree ;)
Index: librelp/Makefile
===
RCS file: /cvs/ports/sysutils/librelp/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- librelp/Makefile16 Mar 2015 18:07:55 - 1.5
+++ librelp/Makefile6 Mar 2016 12:34:54 -
@@ -1,20 +1,28 @@
-# $OpenBSD: Makefile,v 1.5 2015/03/16 18:07:55 naddy Exp $
+# $OpenBSD: Makefile.template,v 1.73 2016/01/11 09:17:22 sthen Exp $
COMMENT = reliable event logging protocol library
-DISTNAME = librelp-1.0.1
+DISTNAME = librelp-1.2.9
+
+SHARED_LIBS += relp 1.0 # 1.0
+
CATEGORIES = sysutils
-MASTER_SITES = http://download.rsyslog.com/librelp/
+
HOMEPAGE = http://www.librelp.com/
-REVISION = 0
MAINTAINER = Todd T. Fries
-SHARED_LIBS += relp 0.1 # 0.1
-
-# GPLv3
+# GPLv3+
PERMIT_PACKAGE_CDROM = Yes
+WANTLIB += ffi gmp gnutls hogweed iconv intl nettle p11-kit pthread
+WANTLIB += tasn1 z
+
+MASTER_SITES = http://download.rsyslog.com/librelp/
+
+SEPARATE_BUILD = Yes
CONFIGURE_STYLE = gnu
+
+LIB_DEPENDS = security/gnutls
.include
Index: librelp/distinfo
===
RCS file: /cvs/ports/sysutils/librelp/distinfo,v
retrieving revision 1.2
diff -u -p -r1.2 distinfo
--- librelp/distinfo8 Jan 2013 17:36:39 - 1.2
+++ librelp/distinfo6 Mar 2016 12:34:54 -
@@ -1,2 +1,2 @@
-SHA256 (librelp-1.0.1.tar.gz) = drAQqpFJl2gC2qLl/aesAqiiJ7DIwNEGnuwtKmYpc5o=
-SIZE (librelp-1.0.1.tar.gz) = 355401
+SHA256 (librelp-1.2.9.tar.gz) = Ug3nuj3GiNxyxbAU3GHvGR6VKPd9FlHdylX8DBSdmKM=
+SIZE (librelp-1.2.9.tar.gz) = 415909
Index: rsyslog/Makefile
===
RCS file: /cvs/ports/sysutils/rsyslog/Makefile,v
retrieving revision 1.26
diff -u -p -r1.26 Makefile
--- rsyslog/Makefile6 Mar 2016 12:18:31 - 1.26
+++ rsyslog/Makefile6 Mar 2016 12:34:54 -
@@ -6,39 +6,40 @@ BROKEN-hppa = lack of atomic ops
SHARED_ONLY = Yes
COMMENT-main = syslog daemon supporting databases, TCP, SSL, RELP
-COMMENT-docs = additional html documentation for rsyslog
-COMMENT-mysql =mysql plugin for rsyslog
-COMMENT-pgsql =postgresql plugin for rsyslog
+COMMENT-mysql =MySQL plugin for rsyslog
+COMMENT-pgsql =Postgres plugin for rsyslog
-MULTI_PACKAGES = -main -docs -mysql -pgsql
+MULTI_PACKAGES = -main -mysql -pgsql
-V =4.6.4
+V =8.16.0
DISTNAME = rsyslog-$V
PKGNAME-main = rsyslog-$V
-PKGNAME-docs = rsyslog-docs-$V
PKGNAME-mysql =rsyslog-mysql-$V
PKGNAME-pgsql =rsyslog-pgsql-$V
CATEGORIES = sysutils
-REVISION-main =8
-REVISION-docs =0
-REVISION-mysql = 6
-REVISION-pgsql = 3
-
HOMEPAGE = http://www.rsyslog.com/
# GPLv3+
PERMIT_PACKAGE_CDROM = Yes
-MODULES = devel/gettext
+WANTLIB-main +=${MODGETTEXT_WANTLIB}
+WANTLIB-main +=c estr ffi gcrypt gmp gnutls gpg-error hogweed
idn
+WANTLIB-main +=json-c nettle p11-kit pthread relp tasn1 uuid z
+
+WANTLIB-mysql += crypto m mysqlclient pthread ssl stdc++ z
-WANTLIB-main +=c gmp hogweed nettle ffi gnutls pthread p11-kit
-WANTLIB-main +=relp tasn1 z ${MODGETTEXT_WANTLIB}
-WANTLIB-mysql += crypto m mysqlclient ssl z pthread stdc++
WANTLIB-pgsql += crypto pq ssl
-LIB_DEPENDS-main = security/gnutls \
- sysutils/librelp
+MODULES = devel/gettext
+
+LIB_DEPENDS-main = devel/json-c \
+ devel/libestr>=0.1.2 \
+ security/libgcrypt \
+ security/gnutls \
+ sysutils/librelp>=1.2.9
+# XXX should port to using libc UUID functions
+LIB_DEPENDS-main +=sysutils/e2fsprogs
LIB_DEPENDS-mysql =databases/mariadb
RUN_DEPENDS-mysql =${PKGNAME-main}:${PKGPATH},-main
LIB_DEPENDS-pgsql =databases/postgresql
@@ -47,21 +48,22 @@ RUN_DEPENDS-
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
On Sat, Oct 31, 2015 at 04:20:56PM GMT, Antoine Jacoutot wrote: > > Thanks for sorting that out. However, like I've mentioned in my last > > paragraph - the main issue is still there. > > Fixed. Thanks :^) Raf
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
> Thanks for sorting that out. However, like I've mentioned in my last > paragraph - the main issue is still there. Fixed. -- Antoine
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
On Fri, Oct 30, 2015 at 06:34:22AM GMT, Antoine Jacoutot wrote: > > but doesn't end up in the package itself. > > Fixed, thanks. > > > $ pkg_info -I pinentry > > pinentry-0.9.6p1PIN or passphrase entry dialog (ncurses interface) > > > > $ ls -l /usr/local/bin/pinentry* > > lrwxr-xr-x 1 root wheel 15 Oct 28 21:44 /usr/local/bin/pinentry > > -> pinentry-curses > > -r-xr-xr-x 1 root bin 2844 Oct 25 14:35 > > /usr/local/bin/pinentry-curses > > > > $ file /usr/local/bin/pinentry* > > /usr/local/bin/pinentry:symbolic link to > > '/usr/local/bin/pinentry-curses' > > /usr/local/bin/pinentry-curses: Bourne shell script text executable > > > > In the end, I had renamed the above two files and copied the built > > binary in its place: > > > > $ ls -l /usr/local/bin/pinentry* > > -r-xr-xr-x 1 root bin 2844 Oct 23 15:14 /usr/local/bin/pinentry > > -rwxr-xr-x 1 root wheel 65760 Oct 30 01:06 > > /usr/local/bin/pinentry-curses > > lrwxr-xr-x 1 root wheel 15 Oct 28 04:13 > > /usr/local/bin/pinentry.old -> pinentry-curses > > > > $ file /usr/local/bin/pinentry* > > /usr/local/bin/pinentry:Bourne shell script text executable > > /usr/local/bin/pinentry-curses: ELF 32-bit LSB shared object, Intel > > 80386, version 1 > > /usr/local/bin/pinentry.old:symbolic link to > > '/usr/local/bin/pinentry-curses' > > > > This, however, only "solves" the problem with the package but does *not* > > resolve the issue which I had initially reported - pinentry doesn't > > prompt for password, the terminal stays blank and pinentry-curses eats > > up 100% CPU. > > > > Regards, > > > > Raf > > Hi Antoine, Thanks for sorting that out. However, like I've mentioned in my last paragraph - the main issue is still there. I can recreate it on all 6 of my machines, i386 and amd64, physical and virtual alike, with old or new GnuPG setup. I had just installed the newest snapshot, built and installed pinentry-0.9.6p2.tgz package and without ~/.gnupg directory, ran: $ gpg2 --full-gen-key and after answering the initial questions and confirming them, pinentry-curses CPU usage climbs to 100%, while the console is blank, the only thing that remains is the cursor in the top left corner of the terminal - BTW, I had tested it over SSH, local console and X to no avail. I'm fairly convinced that pinentry, and not gpg2 or gpg-agent, is the culprit here, because using gpg2 without it (with gpg-agent's pinentry loopback mode), works just fine, i.e. with my existing GnuPG keys putting 'allow-loopback-pinentry' into '~/.gnupg/gpg-agent.conf' and using a passphrase file, the below command produces desired output: gpg2 --pinentry-mode loopback --passphrase-file pass -d secret Given the fact that this is a brand new install, no prior GnuPG cruft, I'm pretty sure that it is not me ;^) but there indeed is an issue with pinentry. Regards, Raf
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
> but doesn't end up in the package itself. Fixed, thanks. > $ pkg_info -I pinentry > pinentry-0.9.6p1PIN or passphrase entry dialog (ncurses interface) > > $ ls -l /usr/local/bin/pinentry* > lrwxr-xr-x 1 root wheel 15 Oct 28 21:44 /usr/local/bin/pinentry -> > pinentry-curses > -r-xr-xr-x 1 root bin 2844 Oct 25 14:35 > /usr/local/bin/pinentry-curses > > $ file /usr/local/bin/pinentry* > /usr/local/bin/pinentry:symbolic link to > '/usr/local/bin/pinentry-curses' > /usr/local/bin/pinentry-curses: Bourne shell script text executable > > In the end, I had renamed the above two files and copied the built > binary in its place: > > $ ls -l /usr/local/bin/pinentry* > -r-xr-xr-x 1 root bin 2844 Oct 23 15:14 /usr/local/bin/pinentry > -rwxr-xr-x 1 root wheel 65760 Oct 30 01:06 > /usr/local/bin/pinentry-curses > lrwxr-xr-x 1 root wheel 15 Oct 28 04:13 /usr/local/bin/pinentry.old > -> pinentry-curses > > $ file /usr/local/bin/pinentry* > /usr/local/bin/pinentry:Bourne shell script text executable > /usr/local/bin/pinentry-curses: ELF 32-bit LSB shared object, Intel > 80386, version 1 > /usr/local/bin/pinentry.old:symbolic link to > '/usr/local/bin/pinentry-curses' > > This, however, only "solves" the problem with the package but does *not* > resolve the issue which I had initially reported - pinentry doesn't > prompt for password, the terminal stays blank and pinentry-curses eats > up 100% CPU. > > Regards, > > Raf > -- Antoine
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
On Wed, Oct 28, 2015 at 05:39:39AM GMT, Antoine Jacoutot wrote:
> On Wed, Oct 28, 2015 at 04:35:14AM +, Raf Czlonka wrote:
> > On Sat, Oct 24, 2015 at 08:59:48AM BST, Antoine Jacoutot wrote:
> > > > > Hi Antoine,
> > > > >
> > > > > On a (somewhat), related note - since the last (so it seems) update to
> > > > > pinentry, it doesn't prompt for pass{word,phrase} any more, i.e.
> > > > >
> > > > > gpg2 -d file.gpg
> > > > >
> > > > > starts gpg-agent, which in turn starts pinentry, all I can see is
> > > > > blank tty and after a couple of seconds, pinentry runs at 99% CPU:
> > > > >
> > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME
> > > > > COMMAND
> > > > > rjc 20819 99.0 0.1 1996 5392 ?? R 6:41AM1:25.35
> > > > > pinentry (pinentry-curses)
> > > >
> > > > Hmm that's odd... my initial tests did work.
> > > > I'll have a look this week-end, thanks for the report.
> > >
> > > Can you wait for and try the new ports snapshot when it is there.
> > > I cannot reproduce your issue, pinentry works just fine here.
> >
> > Hi Antoine,
> >
> > The newest i386 package (new amd64 ones haven't been built yet so can't
> > verify) does something really strange:
> >
> > $ file /usr/local/bin/pinentry*
> > /usr/local/bin/pinentry:symbolic link to
> > '/usr/local/bin/pinentry-curses'
> > /usr/local/bin/pinentry-curses: Bourne shell script text executable
> >
> > So, the pinentry is still a symbolic link instead of the intended
> > wrapper script and pinentry-curses is the actual wrapper -
> > pinentry-curses (the binary) is not even a part of the package.
>
> The pkg snapshot is too old I guess.
Nope, something goes wrong during 'make package', as the actual
pinentry-curses (the binary) *is* being built with 'make build':
$ file
/usr/obj/ports/pinentry-0.9.6-no_gtk2-no_gnome3-bootstrap/pinentry-0.9.6/curses/pinentry-curses
/usr/obj/ports/pinentry-0.9.6-no_gtk2-no_gnome3-bootstrap/pinentry-0.9.6/curses/pinentry-curses:
ELF 32-bit LSB shared object, Intel 80386, version 1
but doesn't end up in the package itself.
$ pkg_info -I pinentry
pinentry-0.9.6p1PIN or passphrase entry dialog (ncurses interface)
$ ls -l /usr/local/bin/pinentry*
lrwxr-xr-x 1 root wheel 15 Oct 28 21:44 /usr/local/bin/pinentry ->
pinentry-curses
-r-xr-xr-x 1 root bin 2844 Oct 25 14:35 /usr/local/bin/pinentry-curses
$ file /usr/local/bin/pinentry*
/usr/local/bin/pinentry:symbolic link to
'/usr/local/bin/pinentry-curses'
/usr/local/bin/pinentry-curses: Bourne shell script text executable
In the end, I had renamed the above two files and copied the built
binary in its place:
$ ls -l /usr/local/bin/pinentry*
-r-xr-xr-x 1 root bin 2844 Oct 23 15:14 /usr/local/bin/pinentry
-rwxr-xr-x 1 root wheel 65760 Oct 30 01:06 /usr/local/bin/pinentry-curses
lrwxr-xr-x 1 root wheel 15 Oct 28 04:13 /usr/local/bin/pinentry.old
-> pinentry-curses
$ file /usr/local/bin/pinentry*
/usr/local/bin/pinentry:Bourne shell script text executable
/usr/local/bin/pinentry-curses: ELF 32-bit LSB shared object, Intel 80386,
version 1
/usr/local/bin/pinentry.old:symbolic link to
'/usr/local/bin/pinentry-curses'
This, however, only "solves" the problem with the package but does *not*
resolve the issue which I had initially reported - pinentry doesn't
prompt for password, the terminal stays blank and pinentry-curses eats
up 100% CPU.
Regards,
Raf
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
ajacou...@bsdfrog.org (Antoine Jacoutot), 2015.10.28 (Wed) 06:39 (CET):
> On Wed, Oct 28, 2015 at 04:35:14AM +, Raf Czlonka wrote:
> > On Sat, Oct 24, 2015 at 08:59:48AM BST, Antoine Jacoutot wrote:
> > > > > Hi Antoine,
> > > > >
> > > > > On a (somewhat), related note - since the last (so it seems) update to
> > > > > pinentry, it doesn't prompt for pass{word,phrase} any more, i.e.
> > > > >
> > > > > gpg2 -d file.gpg
> > > > >
> > > > > starts gpg-agent, which in turn starts pinentry, all I can see is
> > > > > blank tty and after a couple of seconds, pinentry runs at 99% CPU:
> > > > >
> > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME
> > > > > COMMAND
> > > > > rjc 20819 99.0 0.1 1996 5392 ?? R 6:41AM1:25.35
> > > > > pinentry (pinentry-curses)
> > > >
> > > > Hmm that's odd... my initial tests did work.
> > > > I'll have a look this week-end, thanks for the report.
> > >
> > > Can you wait for and try the new ports snapshot when it is there.
> > > I cannot reproduce your issue, pinentry works just fine here.
OpenBSD 5.8-current (GENERIC.MP) #1394: Tue Sep 29 20:42:18 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
gpgme-1.5.1p1 libassuan-2.1.1 libgpg-error-1.20 mutt-1.5.24p0v0-gpgme
It might be the same thing that is bugging me for quite some time - just
not enough to report.
Occasionally I have similiar symptoms with mutt+gpgme.
Just found a way to reproduce:
in mutt, make new message, tell mutt you want to sign/crypt, send -
pinentry asks for passphrase. hit ctrl-c now and you have an orphaned
'pinentry --display :0 (pinentry-curses)'
Most of the time it eats lots of cpu but not always (at least two
occasions). Sometimes there's something that looks like a blank xterm
window.
After ctrl-c mutt prompts are broken, too. Lots of asterisks ('*') when
you type text. Not even easy to get out of mutt correctly at that point.
> > The newest i386 package (new amd64 ones haven't been built yet so can't
> > verify) does something really strange:
> >
> > $ file /usr/local/bin/pinentry*
> > /usr/local/bin/pinentry:symbolic link to
> > '/usr/local/bin/pinentry-curses'
> > /usr/local/bin/pinentry-curses: Bourne shell script text executable
I'm a bit behind:
$ file /usr/local/bin/pinentry*
/usr/local/bin/pinentry:symbolic link to
'/usr/local/bin/pinentry-curses'
/usr/local/bin/pinentry-curses: ELF 64-bit LSB shared object,
x86-64, version 1
> > So, the pinentry is still a symbolic link instead of the intended
> > wrapper script and pinentry-curses is the actual wrapper -
> > pinentry-curses (the binary) is not even a part of the package.
>
> The pkg snapshot is too old I guess.
Will try to find time to get me onto real -current.
Bye and thanks for looking at it, Marcus
> !DSPAM:56306053111941282615443!
Re: pinentry eats up nearly 100% CPU [Was: Re: CVS: cvs.openbsd.org: ports]
On Wed, Oct 28, 2015 at 04:35:14AM +, Raf Czlonka wrote:
> On Sat, Oct 24, 2015 at 08:59:48AM BST, Antoine Jacoutot wrote:
> > > > Hi Antoine,
> > > >
> > > > On a (somewhat), related note - since the last (so it seems) update to
> > > > pinentry, it doesn't prompt for pass{word,phrase} any more, i.e.
> > > >
> > > > gpg2 -d file.gpg
> > > >
> > > > starts gpg-agent, which in turn starts pinentry, all I can see is
> > > > blank tty and after a couple of seconds, pinentry runs at 99% CPU:
> > > >
> > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME
> > > > COMMAND
> > > > rjc 20819 99.0 0.1 1996 5392 ?? R 6:41AM1:25.35
> > > > pinentry (pinentry-curses)
> > >
> > > Hmm that's odd... my initial tests did work.
> > > I'll have a look this week-end, thanks for the report.
> >
> > Can you wait for and try the new ports snapshot when it is there.
> > I cannot reproduce your issue, pinentry works just fine here.
>
> Hi Antoine,
>
> The newest i386 package (new amd64 ones haven't been built yet so can't
> verify) does something really strange:
>
> $ file /usr/local/bin/pinentry*
> /usr/local/bin/pinentry:symbolic link to
> '/usr/local/bin/pinentry-curses'
> /usr/local/bin/pinentry-curses: Bourne shell script text executable
>
> So, the pinentry is still a symbolic link instead of the intended
> wrapper script and pinentry-curses is the actual wrapper -
> pinentry-curses (the binary) is not even a part of the package.
The pkg snapshot is too old I guess.
--
Antoine
