Re: new: lang/polyml
On 2022/01/11 23:06, Philip Guenther wrote: > On Tue, Jan 11, 2022 at 4:09 PM Daniel Dickman wrote: > > > On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack wrote: > > > > > > i386 > > > > > > > > > > > with this diff I was able to install includes, rebuild ld.so and > > ctfconv. I've not managed to build a release yet. > > ... > > Umm, with what diff? There was no diff in nor attached to that message. > :-/ https://marc.info/?l=openbsd-tech&m=164186375804139&w=2 > (That was a lot of lines of output. I don't know about ports@, but my > expectation would be there would be *zero* reviewers of anything before, > say, the last 50 lines of output before the switch to actual compilation. > Standard "make lots of noise so when a failure occurs we can see the > leadup, but we'll ignore it otherwise" style of output, like a base build. > You read the lead up to the warnings and errors only. ) The output from configure scripts and previous build stages is often quite important when figuring out a build problem (especially if something works on some machines and fails on others). To my eyes the key bit is probably Created structure Motif **Writing object code** Segmentation fault (core dumped) *** Error 139 in . (Makefile:1158 'polyexport.o') but somebody else might notice something different
Re: Fwd: [SECURITY] [UPDATE] lang/node to 16.13.2
On 2022/01/12 02:03, Volker Schlecht wrote: > On 1/11/22 16:15, Stuart Henderson wrote: > > > here are a few cleanups > Thanks, I updated that in the attached archive. > > > I see do-extract is now new, but ugh, that's not the way that ports > > are normally unpacked.. > > I won't use it as a reference if I should ever maintain another port ;-) > > > have you tested with any of the ports that depend on it? > > Firefox 96.0 builds without issue, and I managed to build Chromium > 97.0.4692.71 as well, but when running the build on 24 cores, I did > (presumably) hit some resource limit of my _pbuild user, resulting in > seemingly random EAGAIN errors during the bundling of devtools, looking a > lot like this issue here: > > https://github.com/rollup/rollup/issues/4223 > > I'm not sure if that ever occurred on a portbuilder? I haven't seen it on i386. Generally the main port build machines don't run builds on anything like that many cores.
Re: PostgreSQL 14.1 (plus dependencies)
www/kore,pgsql:
cc -O2 -pipe -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare
-Iinclude/kore -Iobj -std=c99 -pedantic -DPREFIX='"/usr/local"'
-fstack-protector-all -I/usr/local/include/postgresql -DKORE_USE_PGSQL
-DPGSQL_INCLUDE_PATH="\"/usr/local/include/postgresql\"" -DKORE_USE_TASKS -c
src/pgsql.c -o obj/pgsql.o
src/pgsql.c:774:10: error: enumeration values 'PGRES_PIPELINE_SYNC' and
'PGRES_PIPELINE_ABORTED' not handled in switch [-Werror,-Wswitch]
switch (PQresultStatus(pgsql->result)) {
^
1 error generated.
gmake: *** [Makefile:251: obj/pgsql.o] Error 1
Re: Update sysutils/bat
On Sun, 9 Jan 2022 07:57:20 +0100, Rafael Sadowski wrote:
> Feedback, ok?
I have some issue to build bat v0.19.0 port on OpenBSD 7.0 / amd64 :
failed when build of libgit2-sys crate.
$ cd /usr/ports/sysutils/bat
Update sources from CVS for v0.19.0 version
$ make build
(...)
Running `/usr/obj/ports/bat-0.19.0/build-amd64/target/release/build/
libgit2-sys-ec0536975269a131/build-script-
build`
error: failed to run custom build command for `libgit2-sys v0.12.26+1.3.0`
Caused by:
process didn't exit successfully: `/usr/obj/ports/bat-0.19.0/build-
amd64/target/release/build/libgit2-sys-ec0536975269a131/build-script-
build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=LIBGIT2_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-openbsd
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_openbsd
cargo:rerun-if-env-changed=HOST_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=LIBGIT2_STATIC
cargo:rerun-if-env-changed=LIBGIT2_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-openbsd
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_openbsd
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-openbsd
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_openbsd
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-openbsd
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_openbsd
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
cargo:rustc-cfg=libgit2_vendored
--- stderr
fatal: not a git repository (or any parent up to mount point /usr)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
set).
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
Os { code: 2, kind: NotFound, message: "No such file or directory" }', /
usr/obj/ports/bat-0.19.0/bat-0.19.0/modcargo-crates/libgit2-
sys-0.12.26+1.3.0/build.rs:198:39
note: run with `RUST_BACKTRACE=1` environment variable to display a
backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed===>] 133/152:
ansi_colours(build)
*** Error 101 in . (/usr/ports/devel/cargo/cargo.port.mk:304 'do-build':
@cd /usr/obj/ports/bat-0.19.0/bat-0.19.0 && /usr/bin/env -i PORTSDI...)
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2952 '/usr/obj/
ports/bat-0.19.0/build-amd64/.build_done': @cd /usr/ports/sysutils...)
*** Error 2 in /usr/ports/sysutils/bat (/usr/ports/infrastructure/mk/
bsd.port.mk:2602 'build': @lock=bat-0.19.0; export _LOCKS_HELD="
bat-0...)
Laurent
Re: Fwd: [SECURITY] [UPDATE] lang/node to 16.13.2
On 1/12/22 10:52, Stuart Henderson wrote: Firefox 96.0 builds without issue, and I managed to build Chromium 97.0.4692.71 as well, but when running the build on 24 cores, I did (presumably) hit some resource limit of my _pbuild user, resulting in seemingly random EAGAIN errors during the bundling of devtools, looking a lot like this issue here: https://github.com/rollup/rollup/issues/4223 I'm not sure if that ever occurred on a portbuilder? I haven't seen it on i386. Generally the main port build machines don't run builds on anything like that many cores So ... how do I turn that into an OK and a commit? ;-)
回复: www/p5-CGI-Simple: Update to 1.26
Here is revised patch: i) Update to 1.280, thank upstream. ii) Keep the previous comments iii) Update DEPENDS wen 发件人: Andrew Hewus Fresh 发送时间: 2022年1月11日 10:47 收件人: Alexander Bluhm 抄送: wen heping; ports@openbsd.org 主题: Re: www/p5-CGI-Simple: Update to 1.26 On Tue, Jan 11, 2022 at 12:44:30AM +0100, Alexander Bluhm wrote: > On Tue, Jan 04, 2022 at 08:32:50AM +, Stuart Henderson wrote: > > > MODULES =cpan > > > PKG_ARCH = * > > > -DISTNAME = CGI-Simple-1.115 > > > +DISTNAME = CGI-Simple-1.26 > > > > this results in the version number (as understood by ports) going > > backwards so will need an EPOCH bump > > Some Perl modules have crazy ideas about version numbers. Instead > of increasing EPOCH each time something stupid happens, some 0 can > be inserted into package name. This makes it more likely that the > numbers increase monotonically. Unfortunately I have to share this regularly at work too. https://xdg.me/version-numbers-should-be-boring/ > Look at http://matrix.cpantesters.org/?dist=CGI-Simple "Other > versions" how they jump around. > > I think p5-CGI-Simple-1.260 package name should be used in this > case. That is how perl thinks of the version internally, not sure if there's a way to handle that automatically in the ports system though as perl will think of `v1.26` as `1.026`. That leading "v" is significant. The fact that perl "5.32" and "v5.32" are the same, but a module's "1.26" and "v1.26" are not is quite annoying. > wen heping: Please speak with upstream and try to convince them to > use continous three digit version numbers like 1.270 in the future. > It is not only the OpenBSD package manager which has trouble with > inconsistent numbers. That above page might help convince them to switch to something better. I know MANWAR has a fair number of dists so convincing him would probably help a lot. Index: Makefile === RCS file: /cvs/ports/www/p5-CGI-Simple/Makefile,v retrieving revision 1.23 diff -u -p -r1.23 Makefile --- Makefile3 Jul 2020 21:45:56 - 1.23 +++ Makefile12 Jan 2022 12:04:20 - @@ -4,14 +4,14 @@ COMMENT = drop-in object-oriented CGI.pm MODULES = cpan PKG_ARCH = * -DISTNAME = CGI-Simple-1.115 +DISTNAME = CGI-Simple-1.280 CATEGORIES = www -REVISION = 0 # Perl PERMIT_PACKAGE = Yes -RUN_DEPENDS = devel/p5-IO-stringy -TEST_DEPENDS = www/p5-libwww +TEST_DEPENDS = devel/p5-Test-Exception \ + devel/p5-Test-NoWarnings \ + www/p5-libwww .include Index: distinfo === RCS file: /cvs/ports/www/p5-CGI-Simple/distinfo,v retrieving revision 1.12 diff -u -p -r1.12 distinfo --- distinfo26 Nov 2015 14:07:31 - 1.12 +++ distinfo12 Jan 2022 12:04:20 - @@ -1,2 +1,2 @@ -SHA256 (CGI-Simple-1.115.tar.gz) = T4c7ydBVr7eyE2hLW8ItMFpFb0PGUTd9PySXF2pYfto= -SIZE (CGI-Simple-1.115.tar.gz) = 85165 +SHA256 (CGI-Simple-1.280.tar.gz) = GOAen/uBTl5O6neshImyBp/oNlGFUPN/bCIT61Wcar8= +SIZE (CGI-Simple-1.280.tar.gz) = 86718
devel/p5-MooseX-Getopt: Update to 0.75
Hi, ports@: Here is a simple patch for devel/p5-MooseX-Getopt to update to 0.75. It fix the test failure in current version 0.74. Now it build well and pass all tests on openbsd-current system. Cheers ! wenIndex: Makefile === RCS file: /cvs/ports/devel/p5-MooseX-Getopt/Makefile,v retrieving revision 1.14 diff -u -p -r1.14 Makefile --- Makefile26 Aug 2020 01:49:51 - 1.14 +++ Makefile12 Jan 2022 12:42:52 - @@ -4,7 +4,7 @@ COMMENT=Moose role for processing comm MODULES= cpan PKG_ARCH= * -DISTNAME= MooseX-Getopt-0.74 +DISTNAME= MooseX-Getopt-0.75 CATEGORIES=devel FIX_EXTRACT_PERMISSIONS=Yes Index: distinfo === RCS file: /cvs/ports/devel/p5-MooseX-Getopt/distinfo,v retrieving revision 1.4 diff -u -p -r1.4 distinfo --- distinfo26 Aug 2020 01:49:51 - 1.4 +++ distinfo12 Jan 2022 12:42:52 - @@ -1,2 +1,2 @@ -SHA256 (MooseX-Getopt-0.74.tar.gz) = HeDfO0Mevp81Y730Vp6s1+B+hlqDl/KpkNDLV9TLLCQ= -SIZE (MooseX-Getopt-0.74.tar.gz) = 58129 +SHA256 (MooseX-Getopt-0.75.tar.gz) = Y/O+W7K8OB6eSLW5XAMw8hcYtmVuj/sZyZ0u4KwU68g= +SIZE (MooseX-Getopt-0.75.tar.gz) = 59084
Question regarding print/ghostscript/gnu
Hi, is there a policy decision (licensing?) for sticking with ghostscript 9.07 from 2013 in ports, or is the port just hard to maintain / is there a lack of time and interest in it? regards, Volker
ansible run dep on netaddr python module
Hi, I had fresh install of OpenBSD-current with ansible added via packages: pkg_add -i ansible Running it on some of my playbooks failed with AnsibleFilterError: The reduce_on_network filter requires python's netaddr be installed on the ansible controller Via pkg_add py3-netaddr problem was fixed. I was wondering, could net/py-netaddr be added to ansible/ansible-core package? -- Regards, Mikolaj
Re: PostgreSQL 14.1 (plus dependencies)
On 01/12 09:58, Stuart Henderson wrote:
> www/kore,pgsql:
>
> cc -O2 -pipe -Wall -Werror -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-qual -Wsign-compare
> -Iinclude/kore -Iobj -std=c99 -pedantic -DPREFIX='"/usr/local"'
> -fstack-protector-all -I/usr/local/include/postgresql -DKORE_USE_PGSQL
> -DPGSQL_INCLUDE_PATH="\"/usr/local/include/postgresql\"" -DKORE_USE_TASKS -c
> src/pgsql.c -o obj/pgsql.o
> src/pgsql.c:774:10: error: enumeration values 'PGRES_PIPELINE_SYNC' and
> 'PGRES_PIPELINE_ABORTED' not handled in switch [-Werror,-Wswitch]
> switch (PQresultStatus(pgsql->result)) {
> ^
> 1 error generated.
> gmake: *** [Makefile:251: obj/pgsql.o] Error 1
>
This patch should allow kore,pgsql to build (taken from a couple
different upstream patches).
Thanks,
Jeremy
Index: Makefile
===
RCS file: /cvs/ports/www/kore/Makefile,v
retrieving revision 1.29
diff -u -p -r1.29 Makefile
--- Makefile2 Nov 2021 00:02:51 - 1.29
+++ Makefile12 Jan 2022 15:28:34 -
@@ -3,7 +3,7 @@
COMMENT = web application framework for writing scalable web APIs in C
DISTNAME = kore-4.1.0
-REVISION = 1
+REVISION = 2
CATEGORIES = www
Index: patches/patch-src_pgsql_c
===
RCS file: patches/patch-src_pgsql_c
diff -N patches/patch-src_pgsql_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_pgsql_c 12 Jan 2022 15:25:47 -
@@ -0,0 +1,18 @@
+$OpenBSD$
+
+Work with PostgreSQL 14.
+
+Index: src/pgsql.c
+--- src/pgsql.c.orig
src/pgsql.c
+@@ -772,6 +772,10 @@ pgsql_read_result(struct kore_pgsql *pgsql)
+ }
+
+ switch (PQresultStatus(pgsql->result)) {
++#if PG_VERSION_NUM >= 14
++ case PGRES_PIPELINE_SYNC:
++ case PGRES_PIPELINE_ABORTED:
++#endif
+ case PGRES_COPY_OUT:
+ case PGRES_COPY_IN:
+ case PGRES_NONFATAL_ERROR:
Re: Update LDC bootstrap
On 1/8/2022 10:09 AM, Brian Callahan wrote: > Hi ports -- > > LDC needs a new bootstrap since the move to LLVM 13 in ports. Right now, > it'll build but the resulting compiler won't work. > > Here's the diff to update the bootstrap. > > While here, LDC doesn't need LLVM as an RDEP. > > OK? > > ~Brian Ping. LDC is broken and will remain broken until this goes in. Or can I just go ahead and update the LDC bootstrap when needed? ~Brian
Re: new: lang/polyml
> On Jan 12, 2022, at 2:06 AM, Philip Guenther wrote: > > >> On Tue, Jan 11, 2022 at 4:09 PM Daniel Dickman wrote: > >> On Mon, Jan 10, 2022 at 8:12 PM Leo Larnack wrote: >> > >> > i386 >> > >> >> >> >> with this diff I was able to install includes, rebuild ld.so and >> ctfconv. I've not managed to build a release yet. > ... > > Umm, with what diff? There was no diff in nor attached to that message. :-/ I see sthen already sent you the link. Leo was asked to split his diff by architecture. I did the testing for the i386 diff he proposed. > > (That was a lot of lines of output. I don't know about ports@, but my > expectation would be there would be *zero* reviewers of anything before, say, > the last 50 lines of output before the switch to actual compilation. > Standard "make lots of noise so when a failure occurs we can see the leadup, > but we'll ignore it otherwise" style of output, like a base build. You read > the lead up to the warnings and errors only. ) Yeah. No this is very bad advice. I’m going to have to *strongly* disagree with you here Philip. I don’t expect most people to be setting up i386 boxes to test this so providing the full logs would be helpful to compare against amd64 which is obviously working for Leo. I think Stuart was making the same point. If I tested on amd64 then I’d expect most people would be able to check it themselves. > > > Philip Guenther >
textproc/lowdown: update to 0.10.0
Hello ports@, Here is a diff to update lowdown to 0.10.0 First submission here. Hope I did it the right way. Index: Makefile === RCS file: /cvs/ports/textproc/lowdown/Makefile,v retrieving revision 1.27 diff -u -p -r1.27 Makefile --- Makefile27 Oct 2021 21:55:07 - 1.27 +++ Makefile12 Jan 2022 20:18:27 - @@ -1,7 +1,7 @@ -# $OpenBSD: Makefile,v 1.27 2021/10/27 21:55:07 fcambus Exp $ +# $OpenBSD: Makefile,v 1.28 2022/01/09 10:40:32 jbz Exp $ COMMENT = simple markdown translator -DISTNAME = lowdown-0.9.2 +DISTNAME = lowdown-0.10.0 CATEGORIES = textproc HOMEPAGE = https://kristaps.bsd.lv/lowdown/ Index: distinfo === RCS file: /cvs/ports/textproc/lowdown/distinfo,v retrieving revision 1.24 diff -u -p -r1.24 distinfo --- distinfo27 Oct 2021 21:55:07 - 1.24 +++ distinfo12 Jan 2022 20:18:27 - @@ -1,2 +1,2 @@ -SHA256 (lowdown-0.9.2.tar.gz) = XDVdHbIHGRaxrW54kgjeZkvjeBvRfdi2sJsXB6KDqYg= -SIZE (lowdown-0.9.2.tar.gz) = 217279 +SHA256 (lowdown-0.10.0.tar.gz) = t1ytJbEPpy0sRzACDq31Y0WGCWT0Jmu8sYNj58icYpc= +SIZE (lowdown-0.10.0.tar.gz) = 229928
UPDATE: Tor Browser 11.0.4
Hi,
Here is an update to 11.0.4. Tested on amd64. More information here:
https://blog.torproject.org/new-release-tor-browser-1104/
I also tweaked various DESCR files to match reality (torbutton and
tor-launcher are not separate Firefox add-ons anymore, for example).
Caspar Schutijser
Index: meta/tor-browser/Makefile
===
RCS file: /cvs/ports/meta/tor-browser/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- meta/tor-browser/Makefile 24 Dec 2021 14:25:40 - 1.48
+++ meta/tor-browser/Makefile 12 Jan 2022 20:55:01 -
@@ -4,11 +4,11 @@ COMMENT= Tor Browser meta package
MAINTAINER=Caspar Schutijser
-PKGNAME= tor-browser-11.0.3
+PKGNAME= tor-browser-11.0.4
ONLY_FOR_ARCHS = amd64
-RUN_DEPENDS= www/tor-browser/browser>=11.0.3 \
- www/tor-browser/noscript>=11.2.11 \
+RUN_DEPENDS= www/tor-browser/browser>=11.0.4 \
+ www/tor-browser/noscript>=11.2.14 \
net/tor>=0.4.6.9
.include
Index: meta/tor-browser/pkg/DESCR
===
RCS file: /cvs/ports/meta/tor-browser/pkg/DESCR,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 DESCR
--- meta/tor-browser/pkg/DESCR 13 Nov 2016 21:18:48 - 1.1.1.1
+++ meta/tor-browser/pkg/DESCR 12 Jan 2022 20:55:01 -
@@ -4,14 +4,9 @@ network. In addition to obscuring the cl
mitigates browser fingerprinting attacks and patches the Mozilla code
in other ways to prevent privacy leaks.
-Tor Browser includes the patched version of Firefox ESR and four
+Tor Browser includes the patched version of Firefox ESR and these
Firefox add-ons:
-* torbutton: an add-on from the Tor project that provides a configuration
- GUI in the browser (the onion button);
-* tor-launcher: another add-on from the Tor project that allows Tor
- Browser to control and interface with a private instance of the tor
- daemon used by Tor Browser;
* noscript: a well-known add-on for Firefox that allows flexible blocking
of JS. The version in the Tor Browser ports is specifically configured
for use in Tor Browser by the Tor project and is not for use with other
Index: www/tor-browser/Makefile.inc
===
RCS file: /cvs/ports/www/tor-browser/Makefile.inc,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile.inc
--- www/tor-browser/Makefile.inc24 Dec 2021 14:25:40 - 1.46
+++ www/tor-browser/Makefile.inc12 Jan 2022 20:55:01 -
@@ -5,7 +5,7 @@ HOMEPAGE ?= https://www.torproject.org
PERMIT_PACKAGE ?= Yes
CATEGORIES = www
BROWSER_NAME = tor-browser
-TB_VERSION = 11.0.3
+TB_VERSION = 11.0.4
TB_PREFIX =tb
SUBST_VARS += BROWSER_NAME TB_VERSION
Index: www/tor-browser/browser/Makefile
===
RCS file: /cvs/ports/www/tor-browser/browser/Makefile,v
retrieving revision 1.71
diff -u -p -r1.71 Makefile
--- www/tor-browser/browser/Makefile24 Dec 2021 14:25:40 - 1.71
+++ www/tor-browser/browser/Makefile12 Jan 2022 20:55:01 -
@@ -16,7 +16,7 @@ EXTRACT_SUFX =.tar.xz
PATCHORIG =.pat.orig
PKGNAME = ${TB_PREFIX}-browser-${TB_VERSION}
-DISTNAME = src-firefox-tor-browser-91.4.1esr-11.0-1-build1
+DISTNAME = src-firefox-tor-browser-91.5.0esr-11.0-1-build1
FIX_EXTRACT_PERMISSIONS= Yes
EXTRACT_ONLY +=${DISTNAME}.tar.xz \
Index: www/tor-browser/browser/distinfo
===
RCS file: /cvs/ports/www/tor-browser/browser/distinfo,v
retrieving revision 1.45
diff -u -p -r1.45 distinfo
--- www/tor-browser/browser/distinfo24 Dec 2021 14:25:40 - 1.45
+++ www/tor-browser/browser/distinfo12 Jan 2022 20:55:01 -
@@ -1,8 +1,8 @@
SHA256 (mozilla/https-everywhere-2021.4.15-eff.xpi) =
fl9ygI6hSL7M1BbsvfM+oevEOkMuTnhbXl4TObeitwg=
-SHA256 (mozilla/src-firefox-tor-browser-91.4.1esr-11.0-1-build1.tar.xz) =
Jghm176evWq2NRBaQ9YcSbvVPdI4cMmNG3jrcKxPCQU=
+SHA256 (mozilla/src-firefox-tor-browser-91.5.0esr-11.0-1-build1.tar.xz) =
Zka3pHcacI+ZB4ZRDRsPjVcmInAX/R61Ux2fbMA=
SHA256 (mozilla/src-tor-launcher-0.2.32.tar.xz) =
WYvM6cGDVH9NFkLK0oBZ0JxYBI3sEuqMNUp/SHVFa3g=
-SHA256 (mozilla/tor-browser-linux64-11.0.3_en-US.tar.xz) =
ZdyTB9qfPhvGW6pZiP6OZPOVnuhY9r7ARfOFJ2vvVqg=
+SHA256 (mozilla/tor-browser-linux64-11.0.4_en-US.tar.xz) =
BaX9bWM8qEwzu9Pi+P/KLS+iEFAypDCwfTwM8GLZ4V8=
SIZE (mozilla/https-everywhere-2021.4.15-eff.xpi) = 1746434
-SIZE (mozilla/src-firefox-tor-browser-91.4.1esr-11.0-1-build1.tar.xz) =
413497744
+SIZE (mozilla/src-firefox-tor-browser-91.5.0esr-11.0-1-build1.tar.xz) =
413390404
SIZE (mozilla/src-tor-launcher-0.2.32.tar.xz) = 228884
-SIZE (mozilla/tor-browser-linux64-11.0.
Re: Question regarding print/ghostscript/gnu
Hi, On Wed, Jan 12, 2022 at 02:48:14PM +0100, Volker Schlecht wrote: > is there a policy decision (licensing?) for sticking with ghostscript 9.07 > from 2013 in ports, or is the port just hard to maintain / is there a lack > of time and interest in it? It's hard to maintain *and* i don't have much time. In case anyone want's to step in: it's probably best to start over mostly from scratch and let it build all dependencies bundled in the source tarball instead of trying to convince the broken make system using system libraries and libraries from other ports. Ciao, Kili
Re: textproc/lowdown: update to 0.10.0
On 2022/01/12 21:31, Justin Berthault wrote: > Hello ports@, > > > Here is a diff to update lowdown to 0.10.0 > > > First submission here. Hope I did it the right way. CC'ing the port maintainer for other comments, > > Index: Makefile > > === > > RCS file: /cvs/ports/textproc/lowdown/Makefile,v > retrieving revision 1.27 > diff -u -p -r1.27 Makefile > --- Makefile27 Oct 2021 21:55:07 - 1.27 > +++ Makefile12 Jan 2022 20:18:27 - > @@ -1,7 +1,7 @@ > -# $OpenBSD: Makefile,v 1.27 2021/10/27 21:55:07 fcambus Exp $ > +# $OpenBSD: Makefile,v 1.28 2022/01/09 10:40:32 jbz Exp $ Please leave that line alone, it is managed by cvs. > COMMENT = simple markdown translator > -DISTNAME = lowdown-0.9.2 > +DISTNAME = lowdown-0.10.0 > CATEGORIES = textproc > > HOMEPAGE = https://kristaps.bsd.lv/lowdown/ > Index: distinfo > === > RCS file: /cvs/ports/textproc/lowdown/distinfo,v > retrieving revision 1.24 > diff -u -p -r1.24 distinfo > --- distinfo27 Oct 2021 21:55:07 - 1.24 > +++ distinfo12 Jan 2022 20:18:27 - > @@ -1,2 +1,2 @@ > -SHA256 (lowdown-0.9.2.tar.gz) = > XDVdHbIHGRaxrW54kgjeZkvjeBvRfdi2sJsXB6KDqYg= > -SIZE (lowdown-0.9.2.tar.gz) = 217279 > +SHA256 (lowdown-0.10.0.tar.gz) = > t1ytJbEPpy0sRzACDq31Y0WGCWT0Jmu8sYNj58icYpc= > +SIZE (lowdown-0.10.0.tar.gz) = 229928 PLIST needs updating as well, there are additional manpages. Run "make plist".
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Mon Jan 10 15:41:03 MST 2022 finished at Wed Jan 12 21:18:23 MST 2022 lasted 2D05h37m done with kern.version=OpenBSD 7.0-current (GENERIC.MP) #1486: Mon Jan 10 13:14:45 MST 2022 built packages:11069 Jan 10:3018 Jan 11:1503 Jan 12:6547 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2022-01-10/summary.log build failures: 7 http://build-failures.rhaalovely.net/aarch64/2022-01-10/games/irrlamb.log http://build-failures.rhaalovely.net/aarch64/2022-01-10/net/termshark.log http://build-failures.rhaalovely.net/aarch64/2022-01-10/sysutils/gitlab-runner.log http://build-failures.rhaalovely.net/aarch64/2022-01-10/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2022-01-10/textproc/p5-SWISH-API.log http://build-failures.rhaalovely.net/aarch64/2022-01-10/www/pear.log http://build-failures.rhaalovely.net/aarch64/2022-01-10/www/seamonkey,-lightning.log recurrent failures failures/games/irrlamb.log failures/net/termshark.log failures/sysutils/gitlab-runner.log failures/sysutils/telegraf.log failures/textproc/p5-SWISH-API.log failures/www/seamonkey,-lightning.log new failures +++ ls-failures Wed Jan 12 21:18:35 2022 +failures/www/pear.log resolved failures --- ../old/aarch64/last//ls-failuresFri Jan 7 22:34:56 2022 -failures/databases/db/v4,no_java,no_tcl.log -failures/devel/jdk/17.log -failures/games/jbrickshooter.log -failures/games/lwjgl.log -failures/games/mars.log -failures/graphics/opencv.log -failures/java/jBCrypt.log -failures/java/jna.log -failures/java/tanukiwrapper.log -failures/lang/abcl.log -failures/lang/kawa.log -failures/misc/posixtestsuite.log -failures/net/i2p.log -failures/net/openfire.log -failures/sysutils/rundeck.log -failures/textproc/pdftk.log -failures/www/chromium.log -failures/www/icedtea-web.log
Re: net/epic4 update
On Mon, Oct 4, 2021 at 6:35 AM Mikhail wrote: > > On Thu, Sep 16, 2021 at 12:18:36PM +0300, Mikhail wrote: > > On Wed, Sep 15, 2021 at 11:48:18PM -0400, Daniel Dickman wrote: > > > On Tue, Sep 14, 2021 at 6:39 AM Mikhail wrote: > > > > > > > > On Mon, Sep 13, 2021 at 09:34:54PM +0300, Mikhail wrote: > > > > > Hello, this is update for net/epic4 port from 2.10.5 to 2.10.10. > > > > > > > > > > patch-include_irc_h and patch-source_irc_c were incorporated upstream > > > > > and should be rm'ed > > > > > > > > > > > > > On IRC I was advised to remove REVISION, new patch is inline. > > > > > > > > The maintainer has been contacted, seem he ignores the updates. > > > > > > sometimes people take vacations or life comes up. I'd say wait at > > > least a week or two to see if they will reply. > > > > > > If no reply in a week or two, they could be removed. > > > > He was contacted in 2019, he replied in 2020 and the reply was that he > > would update the port, but he never did. > > > > Today the mail server reports that there is no such email address. > > > > New patch with MAINTAINER removed. > > ping > I looked at doing this update again, but reading INSTALL it says the following: You must not try to compile epic with "gcc -O2" because -O2 will generate bad code that leads to random crashes. When you use -O2, gcc assumes the source is conformant to ISO C99's requirements about alias-safety, and EPIC, being a C90 program, does not conform, so the result is undefined behavior (which means it crashes randomly.) This is not a bug in EPIC. You must only compile epic with -O. The current port *does* build with -O2 although the warning seems a bit... concerning? Doing the update may be no worse than the current situation. Still, it might be good to verify if the comment is stale and -O2 is ok, or whether we should switch to using -O. Also looking at WANTLIB following the update, is pthread still needed? For now, I've dropped MAINTAINER as we haven't heard from them in a few months.
Re: [NEW] misc/jrnlc
Weekly bump. * Matthias Schmidt wrote: > Hi Stefan, > > * Stefan Hagen wrote: > > Matthias Schmidt wrote: > > > Hi, > > > > > > weekly ping with a fresh tarball attached. > > > > I remember that I used this tool long ago. > > > > The port should go into category "productivity". > > We have other journaling tools there. > > Fine with me. Attached a new tarball with category changed as > requested. > > > ok sdk@ with category change > > > > Best Regards, > > Stefan > > Cheers > > Matthias
