Re: Installing a tree of files
Stuart Henderson wrote:
> On 2019/08/11 13:33, Brian Callahan wrote:
> >
> > Sure, but do you mind sweeping the tree for this do-install idiom? It's
> > probably not in too many places these days, but it's certainly in more
> > than just this one port.
>
> If other ports are being touched can we have something that avoids a
> fork for every file please? Some of these have tens of thousands of
> files.
>
> Since ownership isn't important any more (now we build ports as
> non-root) it might be simplest just to cp nowadays.
Inconveniently, find -exec {} + requires that {} go last, not followed by
destination. Maybe some way to sh around that.
aarch64 bulk build report
bulk build on arm64-3.ports.openbsd.org started on Sun Aug 11 09:38:24 MDT 2019 finished at Mon Aug 12 20:03:32 MDT 2019 lasted 02D03h25m done with kern.version=OpenBSD 6.6-beta (GENERIC.MP) #169: Sat Aug 10 08:51:04 MDT 2019 built packages:9882 Aug 11:5157 Aug 12:4724 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2019-08-11/summary.log build failures: 22 http://build-failures.rhaalovely.net/aarch64/2019-08-11/comms/gnuradio.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/comms/lcdproc.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/devel/ocaml-biniou.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/games/frozen-bubble.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/games/puzzles.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/games/vacuum.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/geo/qlandkartegt.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/graphics/ocaml-cairo.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/graphics/openimageio.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/graphics/vulkan-loader.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/lang/pfe.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/mail/kopano/core.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/security/aircrack-ng.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/security/gpgme,,-main.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/security/sn0int.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/x11/e17/elementary.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/x11/gnome/gjs.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/x11/kde-applications/dolphin-plugins.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/x11/kde4/zeroconf-ioslave.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/x11/qt5/docs,-html.log http://build-failures.rhaalovely.net/aarch64/2019-08-11/x11/qt5/qt3d.log recurrent failures failures/comms/gnuradio.log failures/comms/lcdproc.log failures/editors/xwpe.log failures/games/puzzles.log failures/games/vacuum.log failures/geo/qlandkartegt.log failures/graphics/openimageio.log failures/lang/pfe.log failures/mail/kopano/core.log failures/security/aircrack-ng.log failures/security/sn0int.log failures/x11/e17/elementary.log failures/x11/gnome/gjs.log failures/x11/kde4/zeroconf-ioslave.log failures/x11/qt5/docs,-html.log failures/x11/qt5/qt3d.log new failures +++ ls-failures Mon Aug 12 20:03:43 2019 +failures/devel/ocaml-biniou.log +failures/games/frozen-bubble.log +failures/graphics/ocaml-cairo.log +failures/graphics/vulkan-loader.log +failures/security/gpgme,,-main.log +failures/x11/kde-applications/dolphin-plugins.log resolved failures --- ../old/aarch64/last//ls-failuresTue Aug 6 14:22:47 2019 -failures/audio/chromaprint.log -failures/audio/mumble.log -failures/devel/elftoolchain.log -failures/devel/protobuf-c.log -failures/devel/protozero.log -failures/emulators/xnp2.log -failures/games/frozen-bubble,-main.log -failures/games/pokerth.log -failures/math/R.log -failures/net/dnsdist.log -failures/net/litecoin.log -failures/net/mosh.log -failures/net/seafile/libsearpc.log -failures/productivity/vdirsyncer.log -failures/textproc/mupdf.log -failures/x11/gtk+4,-cloudprint.log -failures/x11/kde4/kopete.log -failures/x11/kde4/workspace.log
Netsurf: get rid of xxd
Hello,
I found a little annoying having to install vim to compile
netsurf. If you like you can try this patch, and maybe make it
less ugly, I'm not a make expert.
By the way, I've compiled netsurf on armv7. It works good.
Regards,
adr
$OpenBSD$
Index: content/handlers/javascript/duktape/Makefile
--- content/handlers/javascript/duktape/Makefile.orig
+++ content/handlers/javascript/duktape/Makefile
@@ -9,11 +9,18 @@ content/handlers/javascript/duktape/dukky.c: $(OBJROOT
BINDINGS := $(wildcard content/handlers/javascript/duktape/*.bnd)
# Generator for the C include representing the generics.js
-$(OBJROOT)/duktape/generics.js.inc:
content/handlers/javascript/duktape/generics.js
+GENERICJS := content/handlers/javascript/duktape/generics.js
+NAME != echo $(GENERICJS) | sed s';[/.];_;g'
+ARRAY != hexdump -v -e '/1 "%d,"' $(GENERICJS)
+LEN != echo $(ARRAY) | awk -F"," '{print NF-1}'
+$(OBJROOT)/duktape/generics.js.inc: $(GENERICJS)
$(Q)$(MKDIR) -p $(OBJROOT)/duktape
$(VQ)echo " XXD: $<"
- $(Q)xxd -i $< $@.tmp
+# $(Q)xxd -i $< $@.tmp
+ $(Q)echo "unsigned char $(NAME)[] = { $(ARRAY) };" > $@.tmp
+ $(Q)echo "unsigned int $(NAME)_len = $(LEN);" >> $@.tmp
$(Q)sed -e
's/content_handlers_javascript_duktape_generics_js/generics_js/' $@.tmp > $@
# ensure genbind generates debugging files
GBFLAGS+=-D
~
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: d...@cvs.openbsd.org2019/08/12 18:34:03 Modified files: net/haproxy: Makefile distinfo net/haproxy/patches: patch-doc_haproxy_1 patch-src_ssl_sock_c Log message: Update to haproxy-1.9.10
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/08/12 17:58:50 Modified files: www: Makefile Log message: Hook www/py-soupsieve up to the build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/08/12 17:58:09 Log message: "Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4. It aims to provide selecting, matching, and filtering using modern CSS selectors." Version 1.9.2 It is needed for www/py-beautifulsoup4 4.7.0+ as the CSS Selector implementation in bs4 was replaced with a dependency on soupsieve. ok danj@ Status: Vendor Tag: kmos Release Tags: kmos_20190812 N ports/www/py-soupsieve/Makefile N ports/www/py-soupsieve/distinfo N ports/www/py-soupsieve/pkg/DESCR N ports/www/py-soupsieve/pkg/PLIST No conflicts created by this import
New: mail/opensmtpd-filter-rspamd
Hello ports, Attached is a new port, mail/opensmtpd-filter-rspamd It is a mail filter for opensmtpd (-current and upcoming 6.6.x) which allows it to work with mail/rspamd. It supports greylisting, rewriting subject, adding headers, rejecting as well as DKIM-signing messages. $ cat DESCR filter-rspamd is an opensmtpd filter that passes mail through rspamd to flag or reject spam messages at session time. $ This is my very very first port so let me know if I did something wrong. Thanks to landry@ and semarie@ for providing feedback already and patrick@ for having tested this filter ;-) opensmtpd-filter-rspamd.tar.gz Description: GNU Zip compressed data
Re: Update: www/py-beautifulsoup4 4.6.3 -> 4.7.1
On Thu, 1 Aug 2019 23:35:11 -0400, Kurt Mosiejczuk wrote: > Here is an update for www/py-beautifulsoup4 to the latest, 4.7.1. tl;dr: Please remove maintainer (wait a few days in case he wants to argue otherwise) and ok danj@ for the update (don't forget soupsieve first ;)). Regarding maintainer, he doesn't maintain his ports (look at portroach if you doubt it) and whenever someone cares to update his ports and send a diff on ports@ he barely never answers (look at ports archive history for confirmation, if this thread is not enough). When I sent my maintainer ping back in May, he replied 16 days later (while it was written he had two weeks, which was already quite much) saying "i havent been very active lately" which I think no one is going to disagree with :) Since he admitted he wasn't active I asked him to reconsider keeping maintainership and he simply stopped answering. I think this kind of behaviour is actually hurtful toward people who actually try to maintain the ports so yeah, please remove him. Cheers, Daniel
Re: New: www/py-soupsieve
On Thu, 1 Aug 2019 23:32:19 -0400, Kurt Mosiejczuk wrote: > This is www/py-soupsieve. This lacks a DESCR. With a DESCR added, ok danj@ Cheers, Daniel
Re: Update: textproc/py-xmldiff 0.6.10 -> 2.3
On Mon, 12 Aug 2019 18:32:16 -0400, Kurt Mosiejczuk wrote: > +FLAVORS= python3 > +FLAVOR?= Isn't it just a tool? Maybe it's more meaningful to just provide a py3 version. What's your opinion? Cheers, Daniel
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2019/08/12 15:47:24 Modified files: audio/flac : Makefile distinfo audio/flac/pkg : PLIST Removed files: audio/flac/patches: patch-configure patch-src_libFLAC_cpu_c Log message: update to 1.3.3: no significant user-visible changes
[macppc/ports-gcc] Unbreak benchmarks/wrk
> http://build-failures.rhaalovely.net/powerpc/2019-07-29/benchmarks/wrk.log
It requires a move from __sync to __atomic. Debian did that already [0],
so i've taken their stuff.
While wrk is written in C, the use of __atomic functions requires
estdc++ and ports-gcc (we can't use COMPILER_LANGS=c).
It builds [1] and runs fine on macppc and amd64 with multiple threads.
Comments/feedback are welcome,
Charlène.
[0] https://sources.debian.org/patches/wrk/4.0.2-2/debian-changes/
[1] https://bin.charlenew.xyz/wrk.log
Index: Makefile
===
RCS file: /cvs/ports/benchmarks/wrk/Makefile,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 Makefile
--- Makefile12 Jul 2019 20:43:43 - 1.2
+++ Makefile12 Aug 2019 19:40:01 -
@@ -5,6 +5,7 @@ COMMENT = modern HTTP benchmarking tool
GH_ACCOUNT = wg
GH_PROJECT = wrk
GH_TAGNAME = 4.1.0
+REVISION = 0
CATEGORIES = benchmarks
@@ -15,6 +16,9 @@ PERMIT_PACKAGE = Yes
WANTLIB += c crypto luajit-5.1 m pthread ssl
+# __atomic support (GCC>4.7.4)
+COMPILER = base-clang ports-gcc
+
LIB_DEPENDS = lang/luajit
USE_GMAKE =Yes
@@ -26,6 +30,12 @@ MAKE_ENV = WITH_LUAJIT=${LOCALBASE} WITH
MAKE_ENV +=LIBS=-lc++abi
WANTLIB += c++abi
.endif
+
+.if ${MACHINE_ARCH:Mhppa} || ${MACHINE_ARCH:Mpowerpc}
+MAKE_ENV +=LIBS=-latomic
+WANTLIB += atomic
+.endif
+
NO_TEST = Yes
Index: patches/patch-src_stats_c
===
RCS file: patches/patch-src_stats_c
diff -N patches/patch-src_stats_c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-src_stats_c 12 Aug 2019 19:40:01 -
@@ -0,0 +1,33 @@
+$OpenBSD$
+
+ppc, hppa: we can't use 64-bit __sync operators there
+
+Index: src/stats.c
+--- src/stats.c.orig
src/stats.c
+@@ -21,12 +21,21 @@ void stats_free(stats *stats) {
+
+ int stats_record(stats *stats, uint64_t n) {
+ if (n >= stats->limit) return 0;
+-__sync_fetch_and_add(>data[n], 1);
+-__sync_fetch_and_add(>count, 1);
++__atomic_fetch_add(>data[n], 1, __ATOMIC_SEQ_CST);
++__atomic_fetch_add(>count, 1, __ATOMIC_SEQ_CST);
+ uint64_t min = stats->min;
+ uint64_t max = stats->max;
+-while (n < min) min = __sync_val_compare_and_swap(>min, min, n);
+-while (n > max) max = __sync_val_compare_and_swap(>max, max, n);
++while (n < min) {
++__atomic_compare_exchange(>min, , , false,
++ __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
++min = stats->min;
++}
++while (n > max) {
++__atomic_compare_exchange(>max, , , false,
++ __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST);
++max = stats->max;
++ }
++
+ return 1;
+ }
+
Re: A bunch (35+) of very old ports to look at deleting
On 8/12/19 2:36 PM, Kurt Mosiejczuk wrote: On Thu, Aug 08, 2019 at 12:41:02PM -0400, Kurt Mosiejczuk wrote: After the first couple of ports I nominated for deletion, I went through all the python ports in cvsweb and looked for ones where the distfile's last update was by naddy four years ago: "Drop remaining MD5/RMD160/SHA1 checksums." Any ports with this as their commit message are even older than the four years of that commit. I believe ports hadn't used those old checksums in some time. Any ports that have lots of consumers I left off of this list. Last chance to save any of these ports. I'm oiling my chainsaw. Go for it, Kurt "py-killer" Mosiejczuk. ~Brian --Kurt audio/py-id3 - no consumers - port never updated, imported October 2003 audio/py-tagger - no consumers - port never updated, imported September 2006 chinese/py-zhCodecs - no consumers - port never updated, imported January 2002 converters/py-cjkcodecs - no consumers - port last updated November 2004 converters/py-iconvcodec - no consumers - never updated, imported Dec 2003 databases/py-cdb - no consumers - port never updated, imported October 2004 databases/py-pgsql - only pgworksheet - never updated, imported May 2008 databases/pgworksheet - no consumers - never updated, imported May 2008 devel/py-monthdelta - no consumers - Last release August 2012 devel/py-optik - no consumers - Last release January 2005 devel/py-protocols - only used for py-ruledispatch - Last release before 2007 devel/py-ruledispatch - no consumers - distfile only on ftp.openbsd.org never updated - imported June 2007 devel/py-silc - no consumers - Last release July 2006 devel/py-tpg - no consumers - Port last updated in Sept 2006 - no trace devel/py-unit - no consumers - last release March 2009 - port never updated devel/pybugz - no consumers - port never updated, imported November 2009 math/py-gnuplot - no consumers - last release was October 2009 math/py-probstat - no consumers - last release was October 2002 misc/pymissile - no consumers - port never updated - imported November 2006 net/py-adns - no consumers - never updated, imported April 2008 net/py-flowd - no consumers - port last updated March 2006 - upstream dead net/py-flowtools - no consumers - port last updated May 2010 net/py-medusa - no consumers - port never updated - imported February 2008 security/py-Rijndael - no consumers - port last updated March 2009 security/py-crack - no consumers - port never updated - imported May 2009 security/py-cryptkit - no consumers - port never updated -imported Jan 2002 sysutils/py-daemon - no consumers - port never updated - imported Oct 2010 (could be updated, upstream has release from this year) textproc/py-Chart - no consumers - Port last updated May 2009 Maintainer -> benoit@ (I have emailed him separately on this one) textproc/py-HappyDoc - no consumers - Port last updated October 2002 textproc/py-epydoc - no consumers - port never updated - imported June 2008 textproc/py-jaxml - no consumers - port never updated - imported February 2004 textproc/py-rtf - no consumers - port last updated May 2005 last upstream release May 2005 textproc/py-xmldiff - no consumers - port never updated - imported Sep 2010 www/py-cherrypy2 - no consumers - port never updated - imported May 2007 www/py-clientform - no consumers - port last updated June 2009 Last release on pypi December 2008 www/py-htmltmpl - no consumers - port never updated - imported January 2010 x11/py-osd - no consumers - port never updated - imported October 2006 Homepage gone - distfile only available on ftp.o.o x11/py-kiwi - no conumers - port never updated - imported September 2009 Homepage gone I'm happy to hear anyone saying they still use one of these, otherwise I would like to delete them.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2019/08/12 12:06:41 Modified files: databases/postgresql: Tag: OPENBSD_6_5 Makefile distinfo databases/postgresql/pkg: Tag: OPENBSD_6_5 PLIST-docs Log message: Security update to 11.5 ok jeremy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/08/12 11:47:52 Modified files: emulators/xnp2 : Makefile Added files: emulators/xnp2/patches: patch-x11_compiler_h Log message: xnp2: fix the build with ports-gcc OK bentley@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: p...@cvs.openbsd.org2019/08/12 10:40:40 Modified files: databases/postgresql: Makefile distinfo databases/postgresql/pkg: PLIST-docs Log message: Update to 11.5 ok jeremy@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2019/08/12 09:41:55 Modified files: lang/flang/libpgmath: Makefile distinfo lang/flang/libpgmath/patches: patch-CMakeLists_txt patch-lib_CMakeLists_txt patch-lib_common_CMakeLists_txt patch-lib_common_acos_fma3_CMakeLists_txt patch-lib_common_asin_fma3_CMakeLists_txt patch-lib_common_dispatch_c patch-lib_common_exp_fma3_CMakeLists_txt patch-lib_common_log_fma3_CMakeLists_txt patch-lib_common_pow_fma3_CMakeLists_txt patch-lib_common_powi_CMakeLists_txt patch-lib_common_sincos_CMakeLists_txt patch-lib_x86_64_CMakeLists_txt patch-lib_x86_64_fast_CMakeLists_txt patch-lib_x86_64_libm_amd_h lang/flang/flang: Makefile distinfo lang/flang/flang/patches: patch-runtime_flangrti_x86_64-Linux_dumpregs_c Added files: lang/flang/libpgmath/patches: patch-lib_common_cexp_CMakeLists_txt patch-lib_common_cexpf_CMakeLists_txt patch-lib_common_log10_CMakeLists_txt patch-lib_common_log10f_CMakeLists_txt patch-lib_common_logf_CMakeLists_txt patch-test_CMakeLists_txt patch-test_lit_site_cfg_in Removed files: lang/flang/libpgmath/patches: patch-lib_common_exp_CMakeLists_txt patch-lib_common_log_CMakeLists_txt patch-lib_common_pow_CMakeLists_txt Log message: Update to new flang build system. The build mechanism for libpgmath went through a major rewrite which took some working with upstream to figure out No real change to flang itself.
Re: x264 on ARM
adr wrote: > > And disabling asm is unappealing on an arch which needs as much > > help with speed as it can get. > > Even worst if you have to play video without hw acc. > > I thought that the decision of using --no_unaligned_access was a > security one, but it seems from the thread that is more like a > legacy one. No. It is neither.
Re: x264 on ARM
And disabling asm is unappealing on an arch which needs as much help with speed as it can get. Even worst if you have to play video without hw acc. I thought that the decision of using --no_unaligned_access was a security one, but it seems from the thread that is more like a legacy one. So there is no point to talk to someone to change his/her code to take into account the arm conventions when unalignment access is not permitted, if there is no real reason for doing that. Look, don't get me wrong. I'm not a guy that is been using this OS some days and now he things is a member of the developer core. I didn't want to have this conversation, because I don't have any idea of the things that are being going on. I'm just trying to build my cabin here, without bothering anyone trying to figure out things by myself. The first thing I recommended to the ffmpeg maintainer, I think it was in a private mail, was to talk to some developer of the arm port because I knew that this wasn't an small issue. Regards, adr
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/08/12 09:21:30 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm Log message: Update quirks to reflect removal of textproc/py-Chart OK sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/08/12 09:19:17 Modified files: textproc : Makefile Removed files: textproc/py-Chart: Makefile distinfo textproc/py-Chart/pkg: DESCR PLIST Log message: textproc/py-Chart has no consumers and was last updated May 2009 Time to remove it I checked with maintainer benoit@ who agrees it should go OK benoit@ sthen@
Re: x264 on ARM
On 2019/08/12 08:46, Theo de Raadt wrote: > Stuart Henderson wrote: > > > On 2019/08/12 14:12, adr wrote: > > > > It's not clear to me that assembly code is the culprit here. > > > > > > No, I bet it is their memory managment functions. > > > > > > > I agree with Stuart's statement. It may be terse but I don't find it > > > > pedantic. > > > > > > And I agree too, that's why I found it pedantic. > > > Any way, I'm out of place here. > > > > The problem with changing things in each port is that it will take > > forever (apart from anything else there are very few ports developers > > with armv7 machines) and it's likely a never ending battle. Few port > > maintainers are going to be able to test diffs. And disabling asm is > > unappealing on an arch which needs as much help with speed as it can > > get. > > > > Looking in list archives I see patrick@ mentioned about running in > > strict alignment mode and the ecosystem not being really able to support > > that in reply to your earlier post about x264. And as you can see in the > > thread I linked to earlier there is some appetite and an initial diff > > for changing this. It's likely that such a change will result in the > > most things being fixed for the least effort. > > Let me explain why we've tried to run strict alignment on as many > platforms as possible. > > It is because some architectures are data strict alignment. We could > emulate non-strict on the strict platforms, and make them all non-strict > alignment. That is the direction Linux has been going, and that's why > so much code is written that way now. > > There are a few problems with this: > > Some architectures have a cheap toggle to do non-strict in hardware, or > can be emulated inexpensive. But on other architectures the emulation > is very expensive: read the instruction, decode it, and then emulate the > behaviour, all the time ignoring the lack of atomicity introduced by the > emulation which may cause other problems later in threaded code and > such. > > So let's say we do non-strict on some architectures, but not others? > > Sooner or later, the strict architectures are going to be the only ones > which get burned by a software change which assumes all the world is a vax. > (vax was non-strict) > > Some of the strict-alignment platforms are slower, and due to having a > smaller user base, repair for these issues will take longer. Eventually > support for those architectures becomes extinct. > > And becoming extinct is a bad thing. We are using the breadth of > architecture variety as a "canany in the coalmine" approach towards > identifying bugs which may affect more than just one architecture. > Running on lots of tier2 architectures improves quality for our tier1 > platforms, this is no joke. > > In the end, even amd64 will suffer from the lack of testing diversity. > > We could give up on strict-alignment on arm64, but the consequences is > other architectures will become 'load bearing' for this issue. > > First they came for strict alignment on arm64, but I wasn't arm64 so > I didn't say anything. > I fully understand this. (And that aligned access is faster on !strict arches). With arm64 the machines are fast enough, there's a bit more developer interest, and I think there probably *are* enough in hands of ports devs that we maybe able to cope with this approach. For armv7 that the OP is using, it's going to be hard for ports to cope.
Re: x264 on ARM
Stuart Henderson wrote: > On 2019/08/12 14:12, adr wrote: > > > It's not clear to me that assembly code is the culprit here. > > > > No, I bet it is their memory managment functions. > > > > > I agree with Stuart's statement. It may be terse but I don't find it > > > pedantic. > > > > And I agree too, that's why I found it pedantic. > > Any way, I'm out of place here. > > The problem with changing things in each port is that it will take > forever (apart from anything else there are very few ports developers > with armv7 machines) and it's likely a never ending battle. Few port > maintainers are going to be able to test diffs. And disabling asm is > unappealing on an arch which needs as much help with speed as it can > get. > > Looking in list archives I see patrick@ mentioned about running in > strict alignment mode and the ecosystem not being really able to support > that in reply to your earlier post about x264. And as you can see in the > thread I linked to earlier there is some appetite and an initial diff > for changing this. It's likely that such a change will result in the > most things being fixed for the least effort. Let me explain why we've tried to run strict alignment on as many platforms as possible. It is because some architectures are data strict alignment. We could emulate non-strict on the strict platforms, and make them all non-strict alignment. That is the direction Linux has been going, and that's why so much code is written that way now. There are a few problems with this: Some architectures have a cheap toggle to do non-strict in hardware, or can be emulated inexpensive. But on other architectures the emulation is very expensive: read the instruction, decode it, and then emulate the behaviour, all the time ignoring the lack of atomicity introduced by the emulation which may cause other problems later in threaded code and such. So let's say we do non-strict on some architectures, but not others? Sooner or later, the strict architectures are going to be the only ones which get burned by a software change which assumes all the world is a vax. (vax was non-strict) Some of the strict-alignment platforms are slower, and due to having a smaller user base, repair for these issues will take longer. Eventually support for those architectures becomes extinct. And becoming extinct is a bad thing. We are using the breadth of architecture variety as a "canany in the coalmine" approach towards identifying bugs which may affect more than just one architecture. Running on lots of tier2 architectures improves quality for our tier1 platforms, this is no joke. In the end, even amd64 will suffer from the lack of testing diversity. We could give up on strict-alignment on arm64, but the consequences is other architectures will become 'load bearing' for this issue. First they came for strict alignment on arm64, but I wasn't arm64 so I didn't say anything.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jtur...@cvs.openbsd.org 2019/08/12 08:42:34 Modified files: www/kcgi : Makefile distinfo Log message: Update kcgi to 0.10.11
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: c...@cvs.openbsd.org2019/08/12 08:40:04 Modified files: security/aircrack-ng: Makefile security/aircrack-ng/pkg: PFRAG.ppc Log message: aircrack-ng: allow packaging on macppc POWER8 libaircrack-crypto isn't built on powerpc -- remove them from PFRAG. OK benoit@ (maintainer)
Re: x264 on ARM
On 2019/08/12 14:12, adr wrote: > > It's not clear to me that assembly code is the culprit here. > > No, I bet it is their memory managment functions. > > > I agree with Stuart's statement. It may be terse but I don't find it > > pedantic. > > And I agree too, that's why I found it pedantic. > Any way, I'm out of place here. The problem with changing things in each port is that it will take forever (apart from anything else there are very few ports developers with armv7 machines) and it's likely a never ending battle. Few port maintainers are going to be able to test diffs. And disabling asm is unappealing on an arch which needs as much help with speed as it can get. Looking in list archives I see patrick@ mentioned about running in strict alignment mode and the ecosystem not being really able to support that in reply to your earlier post about x264. And as you can see in the thread I linked to earlier there is some appetite and an initial diff for changing this. It's likely that such a change will result in the most things being fixed for the least effort.
Re: UPDATE: lang/gawk 5.0.0 => 5.0.1
On Sun, 11 Aug 2019 21:57:07 -0400 Brian Callahan wrote: > > > On 7/29/19 9:12 PM, Brian Callahan wrote: > > Hi ports -- > > > > Attached is a simple update to lang/gawk. All tests pass on amd64 > > and macppc. > > There is something in FILESDIR. But removing it seems to have no > > consequence on building the port whatsoever. So let's get rid of it. > > > > Take MAINTAINER because sure why not. > > > > OK? OK cwen@ (i've tested on amd64 only) > > ~Brian > > > > Ping. Diff reattached for convenience. > > ~Brian >
Re: x264 on ARM
It's not clear to me that assembly code is the culprit here. No, I bet it is their memory managment functions. I agree with Stuart's statement. It may be terse but I don't find it pedantic. And I agree too, that's why I found it pedantic. Any way, I'm out of place here.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/08/12 08:09:08 Modified files: devel/re2c : Makefile distinfo devel/re2c/pkg : PLIST Log message: update to re2c-1.2.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2019/08/12 07:58:06 Modified files: databases/freetds: Makefile distinfo Log message: update to freetds-1.1.12
portcheck: whine with default COMPILER and C++ libs
any comments? ok?
Index: mk/bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1475
diff -u -p -r1.1475 bsd.port.mk
--- mk/bsd.port.mk 14 Jul 2019 11:32:05 - 1.1475
+++ mk/bsd.port.mk 12 Aug 2019 13:23:06 -
@@ -304,7 +304,7 @@ _MODULES_DONE =
.endif
# this only happens if we exit modules without having ever gone
-# thru compiler.port.mk
+# thru compiler.port.mk - update portcheck if changing COMPILER default
COMPILER ?= base-clang base-gcc gcc3
COMPILER_LANGS ?= c c++
.if ${PROPERTIES:Mclang}
Index: bin/portcheck
===
RCS file: /cvs/ports/infrastructure/bin/portcheck,v
retrieving revision 1.128
diff -u -p -r1.128 portcheck
--- bin/portcheck 23 Jun 2019 16:06:23 - 1.128
+++ bin/portcheck 12 Aug 2019 13:23:06 -
@@ -844,10 +844,12 @@ sub_checks() {
vars="$vars MODULES"
vars="$vars PKG_ARCH$subpkg $wantlib_var WANTLIB-"
vars="$vars PERMIT_PACKAGE${subpkg%-}"
+ vars="$vars COMPILER"
make "${make_args[@]}" show="$vars" | {
local comment fullpkgname modules pkg_arch
local wantlib permit_package
local arch_independent=false
+ local default_compiler=false
read -r comment
read -r fullpkgname
read -r modules
@@ -856,6 +858,7 @@ sub_checks() {
read -r wantlib
read -r wantlib_ss
read -r permit_package
+ read -r compiler
if [[ $comment == @(a|an|the)" "* ]]; then
err "${portref}no leading articles in" \
@@ -869,7 +872,12 @@ sub_checks() {
fi
fi
- check_wantlib "$portref" "$modules" $wantlib
+ [[ "$compiler" == "base-clang base-gcc gcc3" ]]
\
+ && default_compiler=true
+
+ check_wantlib "$portref" "$modules" \
+ "$default_compiler" $wantlib
+
check_permit_subpkg "$portref" "$subpkg" \
"$permit_package"
@@ -1301,6 +1309,7 @@ check_plist() {
check_wantlib() {
local portref="$1"; shift
local modules="$1"; shift
+ local default_compiler="$1"; shift
local phonon_s_wantlib=false
@@ -1345,6 +1354,15 @@ check_wantlib() {
"in MODULES (check other libs, too!)"
fi
;;
+
+ @(c++|stdc++)?(?('>')=+([0-9])))
+ if $default_compiler; then
+ err "C++ libraries in WANTLIB with default
COMPILER" \
+ "(most ports need 'COMPILER=base-clang
ports-gcc'" \
+ "or 'COMPILER=base-clang ports-gcc
base-gcc')"
+ fi
+ ;;
+
stdc++?(?('>')=+([0-9])))
if $gcc4_module; then
err "$portref$v in WANTLIB when gcc4 is" \
Re: [ports-gcc] Unbreak graphics/vulkan-{tools,validation-layers}
On 2019/08/12 14:48, Charlene Wendling wrote:
> Hi!
>
> > http://build-failures.rhaalovely.net/powerpc/2019-07-29/graphics/vulkan-tools.log
> > http://build-failures.rhaalovely.net/powerpc/2019-07-29/graphics/vulkan-validation-layers.log
> > http://build-failures.rhaalovely.net/sparc64/2019-08-06/graphics/vulkan-tools.log
> > http://build-failures.rhaalovely.net/sparc64/2019-08-06/graphics/vulkan-validation-layers.log
>
> This is C++11 code and as such require ports-gcc, it builds once
> changed [0] [1].
>
> Charlène.
>
>
> [0] https://bin.charlenew.xyz/vulkan-tools.log
> [1] https://bin.charlenew.xyz/vulkan-validation-layers.log
OK.
>
> Index: graphics/vulkan-tools/Makefile
> ===
> RCS file: /cvs/ports/graphics/vulkan-tools/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- graphics/vulkan-tools/Makefile22 Jun 2019 16:51:06 - 1.2
> +++ graphics/vulkan-tools/Makefile12 Aug 2019 09:33:27 -
> @@ -18,6 +18,9 @@ PERMIT_PACKAGE =Yes
>
> WANTLIB += ${COMPILER_LIBCXX} ICE SM X11 Xext c m vulkan xcb
>
> +# C++11
> +COMPILER = base-clang ports-gcc
> +
> MODULES =devel/cmake \
> lang/python
> MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
> Index: graphics/vulkan-validation-layers/Makefile
> ===
> RCS file: /cvs/ports/graphics/vulkan-validation-layers/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- graphics/vulkan-validation-layers/Makefile22 Jun 2019 16:51:06
> - 1.2
> +++ graphics/vulkan-validation-layers/Makefile12 Aug 2019 09:33:27
> -
> @@ -18,6 +18,9 @@ PERMIT_PACKAGE =Yes
>
> WANTLIB += ${COMPILER_LIBCXX} m
>
> +# C++11
> +COMPILER = base-clang ports-gcc
> +
> MODULES =devel/cmake \
> lang/python
> MODPY_VERSION = ${MODPY_DEFAULT_VERSION_3}
>
[ports-gcc] Unbreak graphics/vulkan-{tools,validation-layers}
Hi!
> http://build-failures.rhaalovely.net/powerpc/2019-07-29/graphics/vulkan-tools.log
> http://build-failures.rhaalovely.net/powerpc/2019-07-29/graphics/vulkan-validation-layers.log
> http://build-failures.rhaalovely.net/sparc64/2019-08-06/graphics/vulkan-tools.log
> http://build-failures.rhaalovely.net/sparc64/2019-08-06/graphics/vulkan-validation-layers.log
This is C++11 code and as such require ports-gcc, it builds once
changed [0] [1].
Charlène.
[0] https://bin.charlenew.xyz/vulkan-tools.log
[1] https://bin.charlenew.xyz/vulkan-validation-layers.log
Index: graphics/vulkan-tools/Makefile
===
RCS file: /cvs/ports/graphics/vulkan-tools/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- graphics/vulkan-tools/Makefile 22 Jun 2019 16:51:06 - 1.2
+++ graphics/vulkan-tools/Makefile 12 Aug 2019 09:33:27 -
@@ -18,6 +18,9 @@ PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} ICE SM X11 Xext c m vulkan xcb
+# C++11
+COMPILER = base-clang ports-gcc
+
MODULES = devel/cmake \
lang/python
MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
Index: graphics/vulkan-validation-layers/Makefile
===
RCS file: /cvs/ports/graphics/vulkan-validation-layers/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- graphics/vulkan-validation-layers/Makefile 22 Jun 2019 16:51:06 -
1.2
+++ graphics/vulkan-validation-layers/Makefile 12 Aug 2019 09:33:27 -
@@ -18,6 +18,9 @@ PERMIT_PACKAGE = Yes
WANTLIB += ${COMPILER_LIBCXX} m
+# C++11
+COMPILER = base-clang ports-gcc
+
MODULES = devel/cmake \
lang/python
MODPY_VERSION =${MODPY_DEFAULT_VERSION_3}
Re: x264 on ARM
On 2019/08/11 23:48, adr wrote: > > Switching a bunch of ports to gcc is not the answer. > > The answer is to talk with the developers of each of these ports > and show them the problems they'll find with llvm, so maybe they > re-implement the assembly optimization following the ARM conventions. > That was my advice to the ffmpeg and x264 maintainer. Or study each > of these ports and rewrite yourself the code, if you like. Meanwhile, > the only thing you can do is to disable the assembly if that is > possible, or try to compile it with gcc. That was the case of mupdf. > > If that is for you "Switching a bunch of ports to gcc"... good for you. > > I'm been using OpenBSD for two weeks or so. I'm just reporting > things that I found wrong. If what I receive in response is this > kind of pedantic statements, don't worry, I will not report anything > more. As you are new to OpenBSD I think you may be coming at this without some of th existing knowledge of the situation, OpenBSD/armv7 runs the cpu in strict alignment mode whereas it is fairly common for some software to assume that ARM does not have such a requirement, there has already been some discussion about changing that. https://marc.info/?t=15193363063=1=2
Re: x264 on ARM
On Sun, Aug 11 2019, adr wrote: >> Switching a bunch of ports to gcc is not the answer. > > The answer is to talk with the developers of each of these ports > and show them the problems they'll find with llvm, so maybe they > re-implement the assembly optimization following the ARM conventions. > That was my advice to the ffmpeg and x264 maintainer. Or study each > of these ports and rewrite yourself the code, if you like. > Meanwhile, > the only thing you can do is to disable the assembly if that is > possible, Looks like the sanest alternative indeed. > or try to compile it with gcc. That was the case of mupdf. --8<-- revision 1.89 date: 2019/07/30 15:59:48; author: sthen; state: Exp; lines: +7 -5; commitid: a8XfL4d8h3TFscT1; build MuPDF with gcc on armv7, problem reported by adr at sdf.org in https://marc.info/?l=openbsd-ports=156448467232400=2 - Bus error at runtime - suspect possible alignment issue? -->8-- It's not clear to me that assembly code is the culprit here. > If that is for you "Switching a bunch of ports to gcc"... good for you. > > I'm been using OpenBSD for two weeks or so. I'm just reporting > things that I found wrong. If what I receive in response is this > kind of pedantic statements, don't worry, I will not report anything > more. I agree with Stuart's statement. It may be terse but I don't find it pedantic. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2019/08/12 05:01:26 Modified files: devel/got : Makefile distinfo Log message: Update to got-0.5 - fix blame with single-commit history and with files without \n - fix crashes in tog when blame returns no results on a file (found by otto@) - man page improvements (bentley@)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: o...@cvs.openbsd.org2019/08/12 03:00:30 Modified files: net/powerdns : Makefile distinfo Log message: Update to PDNS server 4.1.13
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2019/08/12 02:17:38 Modified files: games/polymorphable: Makefile Log message: Simplify do-install Install both directories and files while skipping editor files and traversing the source tree just once. OK bcallah
Re: [macppc] unbreak security/aircrack
On 10/08/2019 23:58, Charlene Wendling wrote: ping. On Sat, 27 Jul 2019 23:35:18 +0200 Charlene Wendling wrote: http://build-failures.rhaalovely.net/powerpc/2019-07-14/security/aircrack-ng.log On macppc: - we have AltiVec support - we don't (and won't) have POWER8 instructions The autotools magic works properly here. As such, it's just about removing the PFRAG entries. This indeed packages [0] once done. I can't test the runtime, the bwi(4) wifi card in my PowerBook is known to be almost unusable. REVISION bump is probably gratuitous. Comments/feedback are welcome! Charlène. ok benoit@ [0] https://bin.charlenew.xyz/aircrack-ng.log Index: Makefile === RCS file: /cvs/ports/security/aircrack-ng/Makefile,v retrieving revision 1.26 diff -u -p -u -p -r1.26 Makefile --- Makefile12 Jul 2019 21:02:24 - 1.26 +++ Makefile27 Jul 2019 21:19:34 - @@ -2,7 +2,7 @@ COMMENT= 802.11 WEP and WPA-PSK keys cracking program DISTNAME= aircrack-ng-1.5.2 -REVISION= 1 +REVISION= 2 CATEGORIES= security HOMEPAGE= https://www.aircrack-ng.org/ Index: pkg/PFRAG.ppc === RCS file: /cvs/ports/security/aircrack-ng/pkg/PFRAG.ppc,v retrieving revision 1.1 diff -u -p -u -p -r1.1 PFRAG.ppc --- pkg/PFRAG.ppc 23 Feb 2019 22:23:25 - 1.1 +++ pkg/PFRAG.ppc 27 Jul 2019 21:19:34 - @@ -1,7 +1,4 @@ @comment $OpenBSD: PFRAG.ppc,v 1.1 2019/02/23 22:23:25 sebastia Exp $ -lib/libaircrack-crypto-ppc-power8-1.3.0.so -lib/libaircrack-crypto-ppc-power8.la -lib/libaircrack-crypto-ppc-power8.so lib/libaircrack-crypto-ppc-altivec-1.3.0.so lib/libaircrack-crypto-ppc-altivec.la lib/libaircrack-crypto-ppc-altivec.so
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2019/08/12 00:54:10 Modified files: www/youtube-dl : Makefile Log message: Update homepage.
Re: [MAINTAINER UPDATE] www/sblg to 0.4.29
On Sun, Aug 11, 2019 at 10:20:30AM -0700, Bryan Vyhmeister wrote: > This is another simple maintainer update of sblg from 0.4.28 to 0.4.29. > The changes included in this release are: > > sblg 0.4.29: "Provide the data-sblg-aside attribute like the others > (data-sblg-title, etc.). Also bring up to date with latest oconfigure." > > I did testing on amd64 with no issues. It should work fine everywhere. > If someone could ok and commit, that would be great. Thank you. > > Bryan > > > Index: www/sblg/Makefile > === > RCS file: /cvs/ports/www/sblg/Makefile,v > retrieving revision 1.22 > diff -u -p -r1.22 Makefile > --- www/sblg/Makefile 15 Jul 2019 14:15:18 - 1.22 > +++ www/sblg/Makefile 11 Aug 2019 17:16:29 - > @@ -2,7 +2,7 @@ > > COMMENT =simple off-line blog utility > > -DISTNAME = sblg-0.4.28 > +DISTNAME = sblg-0.4.29 > CATEGORIES = www > > HOMEPAGE = https://kristaps.bsd.lv/sblg/ > Index: www/sblg/distinfo > === > RCS file: /cvs/ports/www/sblg/distinfo,v > retrieving revision 1.20 > diff -u -p -r1.20 distinfo > --- www/sblg/distinfo 15 Jul 2019 14:15:18 - 1.20 > +++ www/sblg/distinfo 11 Aug 2019 17:16:29 - > @@ -1,2 +1,2 @@ > -SHA256 (sblg-0.4.28.tar.gz) = F5DS/3QRITtxLcDAik7MAqhQyaO8+Ote/+MZfKSgcIM= > -SIZE (sblg-0.4.28.tar.gz) = 72518 > +SHA256 (sblg-0.4.29.tar.gz) = PyL6uTsT8Hn6Xt3GPJQJnqS3BblHeBEv0aAp8klvEeA= > +SIZE (sblg-0.4.29.tar.gz) = 73325 > thanks it's committed
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2019/08/12 00:32:33 Modified files: www/sblg : Makefile distinfo Log message: Update to sblg-0.4.29 Update from maintainer Bryan Vyhmeiste
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: gonz...@cvs.openbsd.org 2019/08/12 00:24:00 Modified files: security/sqlmap: Makefile distinfo security/sqlmap/pkg: PLIST Log message: Update SQLMap to 1.3.8
