Re: [new] graphics/peek, a simple screencast to mp4/gif recorder
On Fri, Oct 29, 2021 at 10:28:24PM +0200, Landry Breuil wrote: > Hi, > > seems to work in basic testing, either outputting gif or mp4 files, cf > https://github.com/phw/peek/ for the website. it can use > https://gif.ski/ at runtime if found but that isnt port yet, for now it > seems to work fine using ffmpeg. Note: this doesnt record audio, only > the screen :) > > feedback welcome ! > > Landry Tested on amd64 here. Easy to operate, but I've only tested it creating small gif files.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2021/10/29 22:46:05 Modified files: games/stockfish: Makefile distinfo Log message: Update to stockfish-14.1 Announcement: https://stockfishchess.org/blog/2021/stockfish-14-1/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2021/10/29 22:23:02 Modified files: editors/editorconfig-core-c: Makefile distinfo editors/editorconfig-core-c/pkg: PLIST Log message: Update to editorconfig-core-c-0.12.5 Fixes a memory leak: https://github.com/editorconfig/editorconfig-core-c/compare/v0.12.4...v0.12.5
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2021/10/29 22:02:05 Modified files: math/bcal : Makefile distinfo math/bcal/patches: patch-bcal_1 Log message: Update to bcal-2.3 Changelog: https://github.com/jarun/bcal/releases/tag/v2.3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bcal...@cvs.openbsd.org 2021/10/29 21:59:45 Modified files: sysutils/diffoscope: Makefile distinfo sysutils/diffoscope/pkg: PLIST Log message: Update to diffoscope-189
Re: NEW: games/vvvvvv - a retro platformer with gravity-reversal puzzle mechanics
On Mon, Oct 18, 2021 at 09:26:59AM -0600, Thomas Frohwein wrote: > On Sat, Oct 09, 2021 at 04:57:56PM +0200, Stefan Hagen wrote: > [...] > > > My read of the license is that it's zlib license with an addition > > > limiting it to non-commercial use. As there's no CD-ROMs anymore, I > > > don't think that matters for packaging the port. > > > > > > Here is the license for review: > > > > > > https://raw.githubusercontent.com/TerryCavanagh/VV/master/LICENSE.md > > > > After reading the license, I believe as well that we're good to > > redistribute it. > > Thanks, I appreciate the look. Could I get another set of porter eyes > and ok before I commit this with PERMIT_PACKAGE=Yes? *ping* > > However, this part may apply: > > > > - Altered source/binary versions must be plainly marked as such, and > > must not be misrepresented as being the original software. > > > > Once there is a patch, the software is altered. Maybe a single sentence > > in the README about this would cover it. > > > > "This version of VV has been changed to run on OpenBSD." > > This is part of the standard zlib license [1]. As far as I know, we > don't do this for any of the other zlib-licensed ports. There are many, > among others are minizip, sdl*, optipng, sfml, tinyxml, and irrlicht. I > would say the assumption is that it being in ports with a patches/ > directory is marking it clearly enough... > > [1] https://opensource.org/licenses/Zlib >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 18:31:15 Modified files: devel/jdk : Makefile java.port.mk devel/jdk/17 : Makefile devel/jdk/17/pkg: PLIST Log message: * Disconnect devel/jdk/16 from the build * Update java.port.mk to use jdk/17. No ports are marked MODJAVA_VER 16 so nothing needs to be bumped. * Add @pkgpath devel/jdk/16 to jdk/17/pkg/PLIST so that jdk-17 will replace jdk-16 with pkg_add -u. okay sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 18:24:16 Modified files: lang/python/3.9: Makefile lang/python/3.9/files: CHANGES.OpenBSD lang/python/3.9/patches: patch-configure_ac Log message: Python 3.9 needs the same fix as 3.8 in order to build wiht llvm 13. Identical diff sent by jsg
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 18:23:09 Modified files: devel/github-cli: Makefile Log message: Remove accidentially committed TEST_* bits
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 18:13:02 Modified files: devel/git : Makefile Log message: Zap lang/python module usage Disabling the build/run dependency (--with-python=no) also disables it for tests, i.e. the configure check is saved and the test suite does not recheck for python. Since we won't add a dependency on python, the module is of no use any longer and we'll let the tests needing it just skip as before.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 18:08:26 Modified files: devel/github-cli: Makefile Log message: Fix version in ldflags/"gh version" >From Ricardo, thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 18:04:42 Modified files: devel/git : Makefile Log message: Enable 2GB clone test, add comments on tests
Re: UPDATE: devel/github-cli
On Fri, Oct 29, 2021 at 10:31:42PM +, Ricardo wrote:
> On Friday, October 29th, 2021 at 5:51 PM, Stuart Henderson
> wrote:
>
> > On 2021/10/29 16:09, Klemens Nanni wrote:
> >
> > > On Fri, Oct 29, 2021 at 01:07:20PM +, Ricardo wrote:
> > >
> > > > Update to version 2.2.0 released this week.
> > > >
> > > > Tested on amd64. OK?
> > >
> > > Thanks, I committed the update.
>
> Thanks kn@. :)
>
> > >
> > > This ports needs further work, though:
> > >
> > > $ gh version
> > >
> > > gh version DEV
> > >
> > > https://github.com/cli/cli/releases/latest
> > >
> > > This used to print 1.4.0 prior to the update.
> > >
>
> Opps. Forgot to add v2 to MODGO_LDFLAGS. Fixed:
>
> RCS file: /cvs/ports/devel/github-cli/Makefile,v
> retrieving revision 1.4
> diff -u -p -u -p -r1.4 Makefile
> --- Makefile 29 Oct 2021 15:48:02 - 1.4
> +++ Makefile 29 Oct 2021 22:01:45 -
> @@ -8,6 +8,7 @@ MODGO_VERSION = v$V
>
> DISTNAME = cli-${MODGO_VERSION}
> PKGNAME =github-cli-$V
> +REVISION = 1
usually starts at 0 but it is no error as long as the overall package
version/revision/epoch/etc. gets higher.
> -MODGO_LDFLAGS += -X "github.com/cli/cli/internal/build.Version=$V"
> +MODGO_LDFLAGS += -X "github.com/cli/cli/v2/internal/build.Version=$V"
Will commit with ${V:R:R}, thanks.
> > > `make test' creates /tmp/go-build- and executes from there, which
> > > fails on at least my machine where /tmp is mounted with` noexec'.
> > >
> > > That, but also for containment/cleanup, this stuff should land under
> > >
> > > ${WRKDIR}/.
> >
> > Not really bothered about noexec /tmp as it breaks too much to be used
> >
> > on a general purpose system anyway, but it would be nice to stop using
> >
> > /tmp/go-build - it's not just during test, it compiles things there as
> >
> > well.
>
> I agree - WRKDIR/WRKBUILD should be used instead of /tmp/go-build*.
> I tried to set PORTHOME, GOROOT and
>
> cd ${WRKBUILD} && ${MODGO_BUILD_CMD} ./...
>
> under do-build without any success. Go completely ignores it and uses /tmp/
> anyway. :|
Hm.. since `do-test' uses MODGO_TEST_CMD which uses `go test' I checked
the output of `go help test' which showed nothing but referred to the
build command.
`go help build' shows `-work', so `make test MODGO_TEST_FLAGS+=-work'
prints this before failing as before:
WORK=/tmp/go-build513679090
Sadly, go does not seem to have an option to specify that WORK variable.
I added WORK, GOTMPDIR (read about that on the internet) and the ones
you mentioned to TEST_ENV, set to ${WRKDIR}, but with no avail.
Any go porter/hacker that knows how to tweak this?
hlsteam - first full-fat middleware for Steam
Hi, The attached port is minimally modified version of the hlsteam middleware for hashlink. This expands the games that can run by allowing access to API in goldberg_emulator, like achievements, cloud saves, etc (which are all emulated locally unlike the real Steam client does). For a little context, until recently the approach to handle the dependencies of some of the commercial FNA or hashlink games on Steam API has been to use a collection of the stubbed middleware libraries in games/steamworks-nosteam. Those serve usually as a middle layer between the game and libsteam_api.so (on Linux). The stubs basically cut all calls to libsteam_api.so short. This approach has its shortcomings, as not all cases can be handled appropriately. In addition, this means installing and maintaining multiple different library files - at the moment there are 5 in steamworks-nosteam. With goldberg_emulator, the goal is to simplify the situation, that is let libsteam_api.so from goldberg_emulator handle most (all?) API emulation or stubs. At the same time, native middleware libraries can be used largely unmodified from their source. With hlsteam, this allows running several games that couldn't run previously: Northgard (newer versions now with most modes; even GOG version), Darksburg, Evoland Legendary Edition, Nuclear Blaze, and the demo of Wartales. If you have one of these games and want to try it, just remove all *.so* and *.hdll files from the game's directory, then use '$ hl' from the hashlink port to run. Going forward, my plan is to replace the other stubs in steamworks-nosteam with functioning versions where possible, as well as adding libCSteamworks.so which so far is mostly blocked by a stub of Steamworks.NET.dll. This should eventually make steamworks-nosteam unnecessary. I have tested the port with all the above mentioned games. It should even be possible to play over LAN, as that is one of the main purposes of goldberg emulator, but I haven't tested that part. ok? hlsteam.tgz Description: Binary data
Re: CVS: cvs.openbsd.org: ports
So I guess ONLY FOR ARCHS didn’t help here? 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@ >
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 16:05:11 Modified files: devel/git : Makefile Log message: Python is not used during build- or run-time The 2.33.0 update removing the multimail hook obsoleted lang/python usage; a few tests probe for python but fail detection and get skipped gracefully. No PLIST/signature change, so no REVISION bump.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 15:50:29 Modified files: mail/pyzor : Makefile distinfo mail/pyzor/pkg : PLIST Log message: switch pyzor to py3, https homepage, install sample configs, use a git checkout as there are a couple of commits fixing some issues with newer python
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 15:46:31 Modified files: devel/keystone/main: Makefile Log message: drop MODPY_VERSION for keystone/main. not sure this even needs python at build time, but anyway it's happy with py3.
Re: LLVM 13 ports build failures (2021-10-27)
Christian Weisgerber (2021-10-28 00:16 +0200): > databases/sqlcipher I can't reproduce this on jsg's llvm13 snapshot. Can anyone else? The errors seem strange, too. It looks as if sqlite3.c somehow was generated incorrectly. naddy, if you still have the build directory, could you send me that sqlite3.c file? Thanks.
CVS: cvs.openbsd.org: ports
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@
remove gtetrinet, mdbtools, grhino, gbrainy
Hi. I would like to start removing old and unmaintained gnome2 libs. Any objection to drop the following;? devel/ORBit2 x11/gnome/libbonobo x11/gnome/libgnome games/gtetrinet x11/gnome/libbonoboui x11/gnome/libgnomeui databases/mdbtools games/grhino x11/gnome/mono-gnome games/gbrainy -- Antoine
Re: New: textproc/csvquote
On Fri, Oct 29, 2021, at 2:18 PM, Thomas Frohwein wrote: > On Fri, Oct 29, 2021 at 05:40:13PM +0100, Stuart Henderson wrote: > > Thanks - this is ok with me > > committed, thanks Thank you! > > > > On 2021/10/29 13:19, Omar Polo wrote: > > > >> I'm attaching an improved version with: > > > >> > > > >> - changed the version from 1.0 to 0.0.20180328. This way, if upstream > > > >>ever decides to tag a version less than 1.0 we won't have troubles. > > > >> > > > >> - HOMEPAGE is not needed, it already defaults to that value. > > > >> > > > >> - same for EXTRACT_SUFX and MASTER_SITES > > > >> > > > >> - missing license comment before PERMIT_PACKAGE > > > >> > > > >> - we can avoid patching the makefile by tweaking FAKE_FLAGS to > > > >> override > > > >>the makefile' BINDIR. > > > >> > > > >> - indentation Thanks for the improvements, I'm very new to setting up ports so this is educational for me even as a very simple example. Allan
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/10/29 15:07:02 Modified files: games/godot: Makefile distinfo Added files: games/godot/pkg: README Log message: add module GodotSteam into the build. This adds dep on goldberg_emulator. Discussed and okay with maintainer Omar Polo
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2021/10/29 15:02:00 Modified files: graphics : Makefile Log message: Add subdirectory radeontop
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: s...@cvs.openbsd.org2021/10/29 15:00:42 Log message: Import radeontop 1.3.0 View your GPU utilization, both for the total activity percent and individual blocks. The total GPU utilization is also valid for OpenCL loads; the other blocks are only useful in GL loads. Requires access to /dev/dri/cardN files or /dev/mem (root privileges). R600 and up, even Southern Islands should work fine. Tweak: AMD Catalyst driver reference removed from DESCR before commit. Port originally created by thfr@, updated by sdk@ and I'm taking maintainer. ok by thfr@ and solene@ Status: Vendor Tag: sdk Release Tags: sdk_20211029 N ports/graphics/radeontop/Makefile N ports/graphics/radeontop/distinfo N ports/graphics/radeontop/patches/patch-Makefile N ports/graphics/radeontop/patches/patch-translations_Makefile N ports/graphics/radeontop/pkg/DESCR N ports/graphics/radeontop/pkg/PLIST N ports/graphics/radeontop/pkg/README No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 14:59:56 Modified files: devel/arduino-makefile: Makefile Log message: arduino-makefile supports py2+py3 so switch to using py3
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 14:51:31 Modified files: audio/cplay: Makefile distinfo audio/cplay/pkg: DESCR PLIST Removed files: audio/cplay/pkg: MESSAGE Log message: switch cplay to cplay-ng, the original is rather old and hasn't been maintained for some time, this is a rewrite working with python 3 and which is still getting updates.
[new] graphics/peek, a simple screencast to mp4/gif recorder
Hi, seems to work in basic testing, either outputting gif or mp4 files, cf https://github.com/phw/peek/ for the website. it can use https://gif.ski/ at runtime if found but that isnt port yet, for now it seems to work fine using ffmpeg. Note: this doesnt record audio, only the screen :) feedback welcome ! Landry peek-1.5.1.tgz Description: application/tar-gz
[DEL] devel/jdk/16 and related changes
* Disconnect devel/jdk/16 from the build
* Update java.port.mk to use jdk/17. No ports are marked
MODJAVA_VER 16 so nothing needs to be bumped.
* Add @pkgpath devel/jdk/16 to jdk/17/pkg/PLIST so that
jdk-17 will replace jdk-16 with pkg_add -u.
I'll remove devel/jdk/16 after this goes in and the
dust settles. Look okay?
Index: Makefile
===
RCS file: /cvs/ports/devel/jdk/Makefile,v
retrieving revision 1.30
diff -u -p -u -r1.30 Makefile
--- Makefile29 Oct 2021 18:16:18 - 1.30
+++ Makefile29 Oct 2021 20:17:22 -
@@ -3,7 +3,6 @@
SUBDIR =
SUBDIR += 1.8
SUBDIR += 11
-SUBDIR += 16
SUBDIR += 17
.include
Index: java.port.mk
===
RCS file: /cvs/ports/devel/jdk/java.port.mk,v
retrieving revision 1.40
diff -u -p -u -r1.40 java.port.mk
--- java.port.mk15 Jul 2021 10:29:19 - 1.40
+++ java.port.mk29 Oct 2021 20:17:22 -
@@ -1,6 +1,6 @@
# $OpenBSD: java.port.mk,v 1.40 2021/07/15 10:29:19 kurt Exp $
-# Set MODJAVA_VER to 1.8, 11 or 16 based on the version of the jdk needed
+# Set MODJAVA_VER to 1.8, 11 or 17 based on the version of the jdk needed
# for the port. Append a + (e.g., 11+) if any higher version is acceptable.
MODJAVA_VER?=
@@ -24,8 +24,8 @@ MODJAVA_VER?=
#
.if ${MODJAVA_VER:S/+//} != "1.8" && ${MODJAVA_VER:S/+//} != "11" && \
- ${MODJAVA_VER:S/+//} != "16"
-ERRORS+="Fatal: MODJAVA_VER must be one of 1.8, 11 or 16 with an optional
+ suffix."
+ ${MODJAVA_VER:S/+//} != "17"
+ERRORS+="Fatal: MODJAVA_VER must be one of 1.8, 11 or 17 with an optional
+ suffix."
.endif
.if ${MODJAVA_VER:S/+//} == "1.8"
@@ -41,8 +41,8 @@ MODJAVA_VER?=
JAVA_HOME= ${LOCALBASE}/jdk-11
MODJAVA_BUILD_DEPENDS+= jdk->=11v0,<12v0:devel/jdk/11
.else
-JAVA_HOME= ${LOCALBASE}/jdk-16
-MODJAVA_BUILD_DEPENDS+= jdk->=16v0,<17v0:devel/jdk/16
+JAVA_HOME= ${LOCALBASE}/jdk-17
+MODJAVA_BUILD_DEPENDS+= jdk->=17v0,<18v0:devel/jdk/17
.endif
.if ${MODJAVA_VER:M*+}
Index: 17/Makefile
===
RCS file: /cvs/ports/devel/jdk/17/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 Makefile
--- 17/Makefile 29 Oct 2021 18:15:15 - 1.1.1.1
+++ 17/Makefile 29 Oct 2021 20:17:22 -
@@ -13,6 +13,7 @@ PACKAGE_VER= ${BASE_VER}.${PATCH_VER}.${
PKGNAME= jdk-${PACKAGE_VER}
PKGSTEM= jdk-17
EPOCH= 0
+REVISION= 0
DIST_SUBDIR= jdk
DISTNAME= jdk-${VERSION_STR}
Index: 17/pkg/PLIST
===
RCS file: /cvs/ports/devel/jdk/17/pkg/PLIST,v
retrieving revision 1.1.1.1
diff -u -p -u -r1.1.1.1 PLIST
--- 17/pkg/PLIST29 Oct 2021 18:15:16 - 1.1.1.1
+++ 17/pkg/PLIST29 Oct 2021 20:17:23 -
@@ -2,6 +2,7 @@
@option no-default-conflict
@option is-branch
@conflict jdk->=17v0,<18v0
+@pkgpath devel/jdk/16
@pkgpath devel/jdk/17
%%ci%%
jdk-17/
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 14:10:55 Modified files: lang/php/7.3 : Tag: OPENBSD_7_0 Makefile distinfo lang/php/7.3/patches: Tag: OPENBSD_7_0 patch-sapi_fpm_fpm_fpm_children_c Removed files: lang/php/7.3/patches: Tag: OPENBSD_7_0 patch-sapi_fpm_fpm_fpm_request_c patch-sapi_fpm_fpm_fpm_scoreboard_c patch-sapi_fpm_fpm_fpm_scoreboard_h patch-sapi_fpm_fpm_fpm_status_c patch-sapi_fpm_fpm_fpm_worker_pool_c Log message: update to php-7.4.25, including a fix for https://bugs.php.net/bug.php?id=81026 PHP-FPM oob R/W in root process leading to privilege escalation (previously patched locally)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 13:56:22 Modified files: games/amnesia-tdd: Makefile Log message: mark amnesia-tdd BROKEN-i386, SIMD / SSE related build failure
Re: games/godot: proposal to add GodotSteam for broader compatibility
On Mon, Oct 25, 2021 at 06:13:35PM +0200, Omar Polo wrote:
> Sorry for replying this late
>
> Thomas Frohwein writes:
>
> > Hi,
> >
> > I've been experimenting with running commercial games with our Godot
> > port and a substantial number refuse to run because they can't find
> > Steam in Godot's namespace. Those games seem to be built with a module
> > "GodotSteam" added during compile time.
> >
> > This diff below adds said module to the port. It allows running some
> > more (indie) games on OpenBSD. I know of "Nightfall Hacker", "SJ-19
> > Learns to Love!", and "Cruelty Squad" that I've been able to run with
> > this change. There are probably more...
> >
> > This diff just adds it to the existing port, but as it leads to a
> > deviation from "vanilla" Godot, it might be preferrable to make this a
> > flavor, maybe godot-godotsteam? Or 2 separate ports that are based on
> > the same Makefile.inc? Of course, maintenance would likely be easier
> > without adding such complexity...
>
> The additions from the GodotStream API seems to be limited to a single
> namespace, so I'm not opposed to bundling them into the shipped Godot.
> It's a deviation from vanilla Godot for sure, but it's small and done to
> help making more games available.
>
> I'm OK with bundling this in the current Godot port as your (updated)
> diff does, but we should document it somewhere (be it with a message or
> a README) to not lure users into thinking that these are official API.
>
> I'm also fine with a flavor, but given how small the impact of bundling
> this library is, I tend to prefer avoiding splitting in multiple flavors
> or subpackages.
Below an updated diff that includes a README. Does that look ok?
> > You can test that the namespace now exists in Godot by opening a
> > project in the editor and adding a script, then starting to enter
> > something from the Steam namespace like 'Steam.getAchievement' into the
> > code and seeing this show up in the auto completion. All this works
> > through the Goldberg emulator library, so some Steam functionality may
> > be stubbed or not return what you expect if used for actual development.
> >
> > comments or oks?
>
> the updated patch is fine for me :)
>
> (the CVS marker is the updated diff is wrong, as it changes the revision
> from 1.26 to 1.25 when the latest is 1.27, but I don't think it's a
> problem in practice ;-)
>
> I checked that the wantlib is correct and that the APIs exists. Godot
> doesn't crash when calling stuff under Steam.*, but I don't have an
> account anymore so I can't do further runtime testing.
Index: Makefile
===
RCS file: /cvs/ports/games/godot/Makefile,v
retrieving revision 1.27
diff -u -p -r1.27 Makefile
--- Makefile14 Oct 2021 14:33:29 - 1.27
+++ Makefile29 Oct 2021 18:56:57 -
@@ -1,4 +1,4 @@
-# $OpenBSD: Makefile,v 1.27 2021/10/14 14:33:29 thfr Exp $
+# $OpenBSD: Makefile,v 1.25 2021/08/31 11:59:56 kirby Exp $
BROKEN-powerpc = fails at runtime, the UI is totally blank
BROKEN-powerpc64 = Unknown ISA
@@ -8,8 +8,10 @@ BROKEN-mips64 =Unknown ISA
COMMENT = 2D and 3D game engine
V =3.3.4
+GODOTSTEAM_V = g333-s151-g397
DISTNAME = godot-${V}-stable
PKGNAME = godot-${V}
+REVISION = 0
CATEGORIES = games
HOMEPAGE = https://godotengine.org/
MAINTAINER = Omar Polo
@@ -20,14 +22,18 @@ PERMIT_PACKAGE =Yes
WANTLIB += ${COMPILER_LIBCXX}
WANTLIB += GL X11 Xau Xcursor Xdmcp Xext Xfixes Xi Xinerama Xrandr
WANTLIB += Xrender c enet execinfo freetype intl m mbedtls mbedcrypto
-WANTLIB += mbedx509 mpcdec ogg opus opusfile png sndio theora theoradec
-WANTLIB += vorbis vorbisfile webp xcb z pcre2-32 vpx zstd
+WANTLIB += mbedx509 mpcdec ogg opus opusfile png sndio steam_api theora
+WANTLIB += theoradec vorbis vorbisfile webp xcb z pcre2-32 vpx zstd
# C++14
COMPILER = base-clang ports-gcc
MASTER_SITES = https://downloads.tuxfamily.org/godotengine/${V}/
+MASTER_SITES0 =https://github.com/Gramps/GodotSteam/archive/refs/tags/
+DISTFILES = ${DISTNAME}${EXTRACT_SUFX} \
+ ${GODOTSTEAM_V}.tar.gz:0
EXTRACT_SUFX = .tar.xz
+DIST_SUBDIR = ${PKGNAME}
MODULES = devel/scons
# Can't disable builtin_bullet until devel/bullet has been updated to 2.88
@@ -35,7 +41,7 @@ MODULES = devel/scons
# sharedlib_ext in modules/mono/config.py to '.so.1.0'
MODSCONS_FLAGS = CC="${CC}" \
CXX="${CXX}" \
- CFLAGS="${CFLAGS}" \
+ CFLAGS="${CFLAGS}
-I${LOCALBASE}/include/goldberg_emulator/sdk_includes" \
CXXFLAGS="${CXXFLAGS} -Wno-deprecated-register" \
LINKFLAGS="${LDFLAGS} -lintl -lmpcdec" \
builtin_enet=no \
@@ -53,6 +59,7 @@ MODSCONS_FLAGS = CC="${CC}" \
builtin_pcre2=no \
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/10/29 12:35:42 Modified files: geo/gdal : Makefile distinfo Removed files: geo/gdal/patches: patch-autotest_conftest.py Log message: geo/gdal: update to 3.3.3 see https://github.com/OSGeo/gdal/blob/v3.3.3/gdal/NEWS - switch HOMEPAGE and MASTER_SITES to https - add Makefile plumbing to build release candidates - remove patch that's not needed anymore since we have a recent py-test, thanks kmos@ ! (was https://github.com/OSGeo/gdal/issues/1165)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2021/10/29 12:26:41 Modified files: sysutils/upower: Makefile distinfo sysutils/upower/pkg: PLIST Log message: sysutils/upower: update to 0.99.13 upstream doesnt provide release tarballs anymore, so fetch a tarball from a git tag on gitlab, and use autohell. Next release will use meson :) see https://cgit.freedesktop.org/upower/tree/NEWS#n1 for changes ok/requested by ajacoutot@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 12:20:55 Modified files: meta/gnome : Makefile Log message: Welcome GNOME 41.0!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 12:19:47 Modified files: x11/gnome/desktop: Makefile distinfo x11/gnome/desktop/pkg: PLIST Log message: Update to gnome-desktop-41.0.
Re: New: textproc/csvquote
On Fri, Oct 29, 2021 at 05:40:13PM +0100, Stuart Henderson wrote:
> Thanks - this is ok with me
committed, thanks
>
> On 2021/10/29 16:48, Omar Polo wrote:
> >
> > Stuart Henderson writes:
> >
> > > On 2021/10/29 13:19, Omar Polo wrote:
> > >> "Allan Streib" writes:
> > >>
> > >> > This is a little utility that I have found useful when processing CSV
> > >> > files that may contain delimeters or newlines within data fields.
> > >> >
> > >> > https://github.com/dbro/csvquote
> > >> >
> > >> > The project provides no release/tags or man page.
> > >>
> > >> that's sad :/
> > >>
> > >> > I offer the attached port for comments/testing.
> > >> >
> > >> > I have tested only on amd64.
> > >> >
> > >> > Allan
> > >>
> > >> I'm attaching an improved version with:
> > >>
> > >> - changed the version from 1.0 to 0.0.20180328. This way, if upstream
> > >>ever decides to tag a version less than 1.0 we won't have troubles.
> > >>
> > >> - HOMEPAGE is not needed, it already defaults to that value.
> > >>
> > >> - same for EXTRACT_SUFX and MASTER_SITES
> > >>
> > >> - missing license comment before PERMIT_PACKAGE
> > >>
> > >> - we can avoid patching the makefile by tweaking FAKE_FLAGS to override
> > >>the makefile' BINDIR.
> > >>
> > >> - indentation
> > >
> > > those are all ok with me
> > >
> > >> - I don't think installing the project README is useful. The "know
> > >>limitations" part is surely useful, but the rest of the readme not
> > >>that much.
> > >
> > > in the absence of a manual, i do think the readme is useful because
> > > it describes what the tool does. i'm ok to import this with the readme
> > > added back in.
> >
> > sounds fair. Attaching an updated tarball with the readme installed.
> >
> > (also, I forgot to mention that WANTLIB was missing)
> >
> > >> I don't mess with csv files often, but I see why something like this
> > >> could be useful.
> > >>
> > >> btw, it could be possible (and quite easy really) to run cvsquote under
> > >> pledge("stdio rpath", NULL). The code is simple to follow, is a simple
> > >> filter after all :)
> > >>
> > >> Cheers,
> > >>
> > >> Omar Polo
> > >>
> >
>
>
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 12:16:18 Modified files: devel/jdk : Makefile Log message: Connect jdk-17 to build
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 12:15:16 Log message: Import jdk 17.0.0. okay sthen@ ian@ Status: Vendor Tag: kurt Release Tags: kurt_20211029 N ports/devel/jdk/17/Makefile N ports/devel/jdk/17/distinfo N ports/devel/jdk/17/files/cacerts N ports/devel/jdk/17/patches/patch-make_common_NativeCompilation_gmk N ports/devel/jdk/17/patches/patch-src_hotspot_os_cpu_bsd_x86_os_bsd_x86_cpp N ports/devel/jdk/17/patches/patch-make_hotspot_lib_CompileJvm_gmk N ports/devel/jdk/17/patches/patch-make_modules_java_desktop_lib_Awt2dLibraries_gmk N ports/devel/jdk/17/patches/patch-make_autoconf_flags-cflags_m4 N ports/devel/jdk/17/pkg/PFRAG.ci N ports/devel/jdk/17/pkg/DESCR N ports/devel/jdk/17/pkg/PLIST N ports/devel/jdk/17/pkg/README No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/10/29 12:11:11 Modified files: textproc : Makefile Log message: +csvquote
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/10/29 12:10:29 Log message: import textproc/csvquote from Allan Streib (astreib AT fastmail DOT fm) - thanks! testing and changes by Omar Polo (op AT omarpolo DOT com) input and ok sthen@ DESCR: This program can be used at the start and end of a text processing pipeline so that regular unix command line tools can properly handle CSV data that contain commas and newlines inside quoted data fields. Status: Vendor Tag: thfr Release Tags: thfr_20211029 N ports/textproc/csvquote/Makefile N ports/textproc/csvquote/distinfo N ports/textproc/csvquote/pkg/DESCR N ports/textproc/csvquote/pkg/PLIST No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: lan...@cvs.openbsd.org 2021/10/29 12:09:53
Modified files:
meta/tor-browser: Makefile
www/tor-browser: Makefile.inc
www/tor-browser/browser: Makefile distinfo
www/tor-browser/browser/patches: patch-dom_ipc_ContentChild_cpp
Log message:
{meta,www}/tor-browser: update to 10.5.10
see https://blog.torproject.org/new-release-tor-browser-10510
from MAINTAINER Caspar Schutijser
Re: UPDATE: devel/github-cli
On 2021/10/29 16:09, Klemens Nanni wrote:
> On Fri, Oct 29, 2021 at 01:07:20PM +, Ricardo wrote:
> > Update to version 2.2.0 released this week.
> > Tested on amd64. OK?
>
> Thanks, I committed the update.
>
> This ports needs further work, though:
>
> $ gh version
> gh version DEV
> https://github.com/cli/cli/releases/latest
>
> This used to print 1.4.0 prior to the update.
>
> `make test' creates /tmp/go-build- and executes from there,
> which fails on at least my machine where /tmp is mounted with `noexec'.
>
> That, but also for containment/cleanup, this stuff should land under
> ${WRKDIR}/.
Not really bothered about noexec /tmp as it breaks too much to be used
on a general purpose system anyway, but it would be nice to stop using
/tmp/go-build - it's not just during test, it compiles things there as
well.
> Ricardo, do you want to take a look at this?
it's definitely a general thing with go ports rather than specific to
github-cli.
WIP: Tor Browser 11.0a9
Hi,
Below is a diff that updates Tor Browser to 11.0a9. Note that this is
an *alpha* release. It's not meant to be committed. The idea is that
people can test. It's based on the new Firefox ESR (91 instead of 78)
so in that regard there are quite some changes. In my (so far limited)
run-time testing, I didn't encounter any issues.
More information:
https://blog.torproject.org/new-release-tor-browser-110a9
Users, let me know if you have any feedback.
Caspar Schutijser
Index: meta/tor-browser/Makefile
===
RCS file: /cvs/ports/meta/tor-browser/Makefile,v
retrieving revision 1.44
diff -u -p -r1.44 Makefile
--- meta/tor-browser/Makefile 23 Aug 2021 21:25:55 - 1.44
+++ meta/tor-browser/Makefile 29 Oct 2021 16:44:18 -
@@ -4,10 +4,10 @@ COMMENT= Tor Browser meta package
MAINTAINER=Caspar Schutijser
-PKGNAME= tor-browser-10.5.5
+PKGNAME= tor-browser-11.0a9
ONLY_FOR_ARCHS = amd64
-RUN_DEPENDS= www/tor-browser/browser>=10.5.5 \
+RUN_DEPENDS= www/tor-browser/browser>=11.0a9 \
www/tor-browser/noscript>=11.2.11 \
net/tor>=0.4.6.7
Index: www/tor-browser/Makefile.inc
===
RCS file: /cvs/ports/www/tor-browser/Makefile.inc,v
retrieving revision 1.43
diff -u -p -r1.43 Makefile.inc
--- www/tor-browser/Makefile.inc23 Aug 2021 21:25:55 - 1.43
+++ www/tor-browser/Makefile.inc29 Oct 2021 16:44:18 -
@@ -5,7 +5,7 @@ HOMEPAGE ?= https://www.torproject.org
PERMIT_PACKAGE ?= Yes
CATEGORIES = www
BROWSER_NAME = tor-browser
-TB_VERSION = 10.5.5
+TB_VERSION = 11.0a9
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.67
diff -u -p -r1.67 Makefile
--- www/tor-browser/browser/Makefile23 Aug 2021 21:25:55 - 1.67
+++ www/tor-browser/browser/Makefile29 Oct 2021 16:44:18 -
@@ -9,14 +9,14 @@ ONLY_FOR_ARCHS = amd64
MOZILLA_VERSION = ${TB_VERSION}
MOZILLA_PROJECT = ${BROWSER_NAME}
MOZILLA_CODENAME = browser
-TL_VERSION = 0.2.30
+TL_VERSION = 0.2.31
HE_VERSION = 2021.4.15
EXTRACT_SUFX = .tar.xz
PATCHORIG =.pat.orig
PKGNAME = ${TB_PREFIX}-browser-${TB_VERSION}
-DISTNAME = src-firefox-tor-browser-78.13.0esr-10.5-2-build1
+DISTNAME = src-firefox-tor-browser-91.2.0esr-11.0-1-build1
FIX_EXTRACT_PERMISSIONS= Yes
EXTRACT_ONLY +=${DISTNAME}.tar.xz \
@@ -25,7 +25,7 @@ EXTRACT_ONLY += ${DISTNAME}.tar.xz \
DISTFILES =${EXTRACT_ONLY} \
https-everywhere-${HE_VERSION}-eff.xpi:0
-SO_VERSION = 6.0
+SO_VERSION = 7.0
MOZILLA_LIBS = xul clearkey lgpllibs mozavcodec mozavutil mozgtk
MOZILLA_LIBS +=freebl3 nss3 nssckbi
MOZILLA_LIBS +=nssutil3 smime3 softokn3 ssl3
@@ -42,7 +42,7 @@ MODULES = www/mozilla lang/python
MODPY_RUNDEP = No
-COMPILER = base-clang ports-clang
+COMPILER = ports-clang
MODCLANG_ARCHS = amd64 i386
# tor-browser needs built-in nss, sqlite
@@ -51,10 +51,13 @@ MOZILLA_USE_BUNDLED_NSS = Yes
# 63 requires node because why not #1483595
BUILD_DEPENDS += lang/node
# 63 requires cbindgen #1478813
-BUILD_DEPENDS += devel/cbindgen>=0.14.3
+BUILD_DEPENDS += devel/cbindgen>=0.19.0
+#1670807
+BUILD_DEPENDS += devel/m4
# uses pledge()
WANTLIB += X11-xcb Xcursor Xi intl xcb xcb-shm harfbuzz ${COMPILER_LIBCXX}
+WANTLIB += Xcomposite Xdamage Xfixes
# Regression tests are too hard to adapt to run here
NO_TEST = Yes
@@ -62,8 +65,10 @@ NO_TEST =Yes
WRKDIST = ${WRKDIR}/${DISTNAME:S/src-//}
CONFIGURE_STYLE = simple
+CONFIGURE_SCRIPT = ${MODPY_BIN} ${WRKSRC}/configure.py
CONFIGURE_ARGS += --prefix=${PREFIX}
MAKE_ENV +=BUILD_VERBOSE_LOG="1" CARGOFLAGS="-j${MAKE_JOBS}"
+CONFIGURE_ENV += M4=/usr/local/bin/gm4
# app-name etc. for tor-browser
CONFIGURE_ARGS += --with-app-name=${BROWSER_NAME} \
@@ -83,6 +88,7 @@ RUN_DEPENDS +=net/tor>=0.4.6.7
CONFIGURE_ARGS += --enable-release #1386371
CONFIGURE_ARGS += --enable-sandbox
+CONFIGURE_ARGS += --enable-forkserver
CONFIGURE_ARGS += --with-libclang-path=${LOCALBASE}/lib
# XXX badly formed debug in libxul ?
@@ -168,7 +174,7 @@ post-install:
${SUBST_PROGRAM} ${FILESDIR}/${BROWSER_NAME} \
${PREFIX}/bin/${BROWSER_NAME}
-.for f in unveil.content unveil.gpu unveil.main pledge.content
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 10:45:13 Modified files: devel : Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm Removed files: devel/py-backports: Makefile distinfo devel/py-backports/pkg: DESCR PLIST Log message: py-backports no longer needed
Re: New: textproc/csvquote
Thanks - this is ok with me
On 2021/10/29 16:48, Omar Polo wrote:
>
> Stuart Henderson writes:
>
> > On 2021/10/29 13:19, Omar Polo wrote:
> >> "Allan Streib" writes:
> >>
> >> > This is a little utility that I have found useful when processing CSV
> >> > files that may contain delimeters or newlines within data fields.
> >> >
> >> > https://github.com/dbro/csvquote
> >> >
> >> > The project provides no release/tags or man page.
> >>
> >> that's sad :/
> >>
> >> > I offer the attached port for comments/testing.
> >> >
> >> > I have tested only on amd64.
> >> >
> >> > Allan
> >>
> >> I'm attaching an improved version with:
> >>
> >> - changed the version from 1.0 to 0.0.20180328. This way, if upstream
> >>ever decides to tag a version less than 1.0 we won't have troubles.
> >>
> >> - HOMEPAGE is not needed, it already defaults to that value.
> >>
> >> - same for EXTRACT_SUFX and MASTER_SITES
> >>
> >> - missing license comment before PERMIT_PACKAGE
> >>
> >> - we can avoid patching the makefile by tweaking FAKE_FLAGS to override
> >>the makefile' BINDIR.
> >>
> >> - indentation
> >
> > those are all ok with me
> >
> >> - I don't think installing the project README is useful. The "know
> >>limitations" part is surely useful, but the rest of the readme not
> >>that much.
> >
> > in the absence of a manual, i do think the readme is useful because
> > it describes what the tool does. i'm ok to import this with the readme
> > added back in.
>
> sounds fair. Attaching an updated tarball with the readme installed.
>
> (also, I forgot to mention that WANTLIB was missing)
>
> >> I don't mess with csv files often, but I see why something like this
> >> could be useful.
> >>
> >> btw, it could be possible (and quite easy really) to run cvsquote under
> >> pledge("stdio rpath", NULL). The code is simple to follow, is a simple
> >> filter after all :)
> >>
> >> Cheers,
> >>
> >> Omar Polo
> >>
>
Re: [NEW] devel/jdk/17
On 2021/10/29 11:41, Kurt Miller wrote: > Attached please find a port of jdk 17.0.0. jdk 17 is a long > term supported release. After this is committed, I intend > to remove devel/jdk/16 and update java.port.mk. > > Tested on amd64/aarch64/i386. This will fail to build with > llvm 13 in the same way as jdk/16 does but that should be > easy to fix later as it only requires adding > -Wno-unused-but-set-parameter. > > Okay to import? > Not tested but I'm ok with importing. (Sad that nothing has changed with ipv6 support in all this time!)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 10:23:36 Modified files: astro : Makefile audio : Makefile databases : Makefile devel : Makefile math : Makefile multimedia : Makefile net: Makefile security : Makefile sysutils : Makefile textproc : Makefile www: Makefile Log message: add annotations for py-* ports using python 3 without a ,python3 flavour, change some existing annotations, so "grep ' py-' ports/*/Makefile | grep -v python3" does better at finding the py-* things still using py2
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 10:13:17 Modified files: geo/gmapcatcher: Makefile distinfo geo/gmapcatcher/patches: patch-gmapcatcher_mapArgs_py patch-setup_py geo/gmapcatcher/pkg: PLIST Log message: update to gmapcatcher-0.8.2.1 (still no py3 version, and it seems a bit flaky with downloads, probably a candidate for removing from ports)
Re: UPDATE: devel/github-cli
On Fri, Oct 29, 2021 at 01:07:20PM +, Ricardo wrote:
> Update to version 2.2.0 released this week.
> Tested on amd64. OK?
Thanks, I committed the update.
This ports needs further work, though:
$ gh version
gh version DEV
https://github.com/cli/cli/releases/latest
This used to print 1.4.0 prior to the update.
`make test' creates /tmp/go-build- and executes from there,
which fails on at least my machine where /tmp is mounted with `noexec'.
That, but also for containment/cleanup, this stuff should land under
${WRKDIR}/.
Ricardo, do you want to take a look at this?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: k...@cvs.openbsd.org2021/10/29 09:48:02 Modified files: devel/github-cli: Makefile distinfo modules.inc devel/github-cli/pkg: PLIST Log message: Update to github-cli 2.2.0 >From Ricardo , thanks! OK sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 09:45:09 Modified files: x11: Makefile devel/quirks : Makefile devel/quirks/files: Quirks.pm x11/py-xcbgen : Makefile x11/py-xcbgen/pkg: PLIST Log message: robert removed the last py2 user of py-xcbgen while i was working on the last batch
[NEW] devel/jdk/17
Attached please find a port of jdk 17.0.0. jdk 17 is a long term supported release. After this is committed, I intend to remove devel/jdk/16 and update java.port.mk. Tested on amd64/aarch64/i386. This will fail to build with llvm 13 in the same way as jdk/16 does but that should be easy to fix later as it only requires adding -Wno-unused-but-set-parameter. Okay to import? 17.tgz Description: application/compressed-tar
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 09:38:52 Modified files: audio : Makefile audio/py-audio : Makefile audio/py-audio/pkg: PLIST audio/py-discid: Makefile audio/py-discid/pkg: PLIST databases : Makefile databases/py-bsddb3: Makefile databases/py-bsddb3/pkg: PLIST databases/py-odbc: Makefile databases/py-odbc/pkg: PLIST databases/py-peewee: Makefile databases/py-peewee/pkg: PLIST databases/py-pickleshare: Makefile databases/py-pickleshare/pkg: PLIST databases/py-sql: Makefile databases/py-sql/pkg: PLIST devel : Makefile devel/py-ana : Makefile devel/py-ana/pkg: PLIST devel/py-anytree: Makefile devel/py-anytree/pkg: PLIST devel/py-appdirs: Makefile devel/py-appdirs/pkg: PLIST devel/py-argcomplete: Makefile devel/py-argcomplete/pkg: PLIST devel/py-argh : Makefile devel/py-argh/pkg: PLIST devel/py-backcall: Makefile devel/py-backcall/pkg: PLIST devel/py-biplist: Makefile devel/py-biplist/pkg: PLIST devel/py-bitstring: Makefile devel/py-bitstring/pkg: PLIST devel/py-blessings: Makefile devel/py-blessings/pkg: PLIST devel/py-blist : Makefile devel/py-blist/pkg: PLIST devel/py-cairocffi: Makefile devel/py-cairocffi/pkg: PLIST devel/py-cffi : Makefile devel/py-cffi/pkg: PLIST devel/py-characteristic: Makefile devel/py-characteristic/pkg: PLIST devel/py-cheetah: Makefile devel/py-cheetah/pkg: PLIST devel/py-clint : Makefile devel/py-clint/pkg: PLIST devel/py-configobj: Makefile devel/py-configobj/pkg: PLIST devel/py-cooldict: Makefile devel/py-cooldict/pkg: PLIST devel/py-cstruct: Makefile devel/py-cstruct/pkg: PLIST devel/py-decorator: Makefile devel/py-decorator/pkg: PLIST devel/py-dispatcher: Makefile devel/py-dispatcher/pkg: PLIST devel/py-docopt: Makefile devel/py-docopt/pkg: PLIST devel/py-easyprocess: Makefile devel/py-easyprocess/pkg: PLIST devel/py-entrypoints: Makefile devel/py-entrypoints/pkg: PLIST devel/py-filebytes: Makefile devel/py-filebytes/pkg: PLIST devel/py-flaky : Makefile devel/py-flaky/pkg: PLIST devel/py-flexmock: Makefile devel/py-flexmock/pkg: PLIST devel/py-frozendict: Makefile devel/py-frozendict/pkg: PLIST devel/py-gitdb : Makefile devel/py-gitdb/pkg: PLIST devel/py-gitpython: Makefile devel/py-gitpython/pkg: PLIST devel/py-greenlet: Makefile devel/py-greenlet/pkg: PLIST devel/py-ipython_genutils: Makefile devel/py-ipython_genutils/pkg: PLIST devel/py-iso3166: Makefile devel/py-iso3166/pkg: PLIST devel/py-iso639: Makefile devel/py-iso639/pkg: PLIST devel/py-isodate: Makefile devel/py-isodate/pkg: PLIST devel/py-isort : Makefile devel/py-isort/pkg: PLIST devel/py-jmespath: Makefile devel/py-jmespath/pkg: PLIST devel/py-magic : Makefile devel/py-magic/pkg: PLIST devel/py-mccabe: Makefile devel/py-mccabe/pkg: PLIST devel/py-minimock: Makefile devel/py-minimock/pkg: PLIST devel/py-mox3 : Makefile devel/py-mox3/pkg: PLIST devel/py-munch : Makefile devel/py-munch/pkg: PLIST devel/py-nose-warnings-filters: Makefile devel/py-nose-warnings-filters/pkg: PLIST devel/py-nosexcover: Makefile devel/py-nosexcover/pkg: PLIST devel/py-olefile: Makefile devel/py-olefile/pkg: PLIST devel/py-parallel: Makefile devel/py-parallel/pkg: PLIST devel/py-pathlib: Makefile devel/py-pathlib/pkg: PLIST devel/py-pathspec: Makefile devel/py-pathspec/pkg: PLIST devel/py-progress: Makefile devel/py-progress/pkg: PLIST devel/py-progressbar: Makefile devel/py-progressbar/pkg: PLIST devel/py-pyprof2calltree: Makefile devel/py-pyprof2calltree/pkg: PLIST devel/py-pyte : Makefile devel/py-pyte/pkg: PLIST devel/py-rencode: Makefile devel/py-rencode/pkg: PLIST devel/py-rfc6555: Makefile devel/py-rfc6555/pkg: PLIST devel/py-robotframework: Makefile devel/py-robotframework/pkg: PLIST devel/py-send2trash: Makefile devel/py-send2trash/pkg: PLIST devel/py-setuptools_git: Makefile
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 08:56:50 Modified files: mail/neomutt : Makefile distinfo Log message: neomutt: upstream retagged 20211029 to add another commit, set DISTFILES to avoid problems for anyone who already fetched and bump REVISION
Re: New: textproc/csvquote
Stuart Henderson writes:
> On 2021/10/29 13:19, Omar Polo wrote:
>> "Allan Streib" writes:
>>
>> > This is a little utility that I have found useful when processing CSV
>> > files that may contain delimeters or newlines within data fields.
>> >
>> > https://github.com/dbro/csvquote
>> >
>> > The project provides no release/tags or man page.
>>
>> that's sad :/
>>
>> > I offer the attached port for comments/testing.
>> >
>> > I have tested only on amd64.
>> >
>> > Allan
>>
>> I'm attaching an improved version with:
>>
>> - changed the version from 1.0 to 0.0.20180328. This way, if upstream
>>ever decides to tag a version less than 1.0 we won't have troubles.
>>
>> - HOMEPAGE is not needed, it already defaults to that value.
>>
>> - same for EXTRACT_SUFX and MASTER_SITES
>>
>> - missing license comment before PERMIT_PACKAGE
>>
>> - we can avoid patching the makefile by tweaking FAKE_FLAGS to override
>>the makefile' BINDIR.
>>
>> - indentation
>
> those are all ok with me
>
>> - I don't think installing the project README is useful. The "know
>>limitations" part is surely useful, but the rest of the readme not
>>that much.
>
> in the absence of a manual, i do think the readme is useful because
> it describes what the tool does. i'm ok to import this with the readme
> added back in.
sounds fair. Attaching an updated tarball with the readme installed.
(also, I forgot to mention that WANTLIB was missing)
>> I don't mess with csv files often, but I see why something like this
>> could be useful.
>>
>> btw, it could be possible (and quite easy really) to run cvsquote under
>> pledge("stdio rpath", NULL). The code is simple to follow, is a simple
>> filter after all :)
>>
>> Cheers,
>>
>> Omar Polo
>>
csvquote.tar.gz
Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rob...@cvs.openbsd.org 2021/10/29 08:49:43 Modified files: www/iridium: Makefile distinfo www/iridium/files: hid_connection_fido.cc hid_connection_fido.h hid_service_fido.cc hid_service_fido.h sndio_input.cc sndio_input.h unveil.main www/iridium/patches: patch-BUILD_gn patch-apps_ui_views_app_window_frame_view_cc patch-ash_display_mirror_window_controller_cc patch-base_BUILD_gn patch-base_allocator_allocator_gni patch-base_allocator_partition_allocator_address_space_randomization_h patch-base_allocator_partition_allocator_partition_alloc_config_h patch-base_allocator_partition_allocator_spinning_mutex_cc patch-base_atomicops_h patch-base_base_paths_posix_cc patch-base_base_switches_cc patch-base_base_switches_h patch-base_compiler_specific_h patch-base_cpu_h patch-base_debug_debugger_posix_cc patch-base_debug_elf_reader_cc patch-base_debug_proc_maps_linux_cc patch-base_debug_stack_trace_posix_cc patch-base_files_file_path_watcher_bsd_cc patch-base_files_file_path_watcher_kqueue_h patch-base_files_file_util_posix_cc patch-base_files_important_file_writer_cleaner_cc patch-base_files_scoped_file_cc patch-base_i18n_icu_util_cc patch-base_linux_util_cc patch-base_memory_discardable_memory_cc patch-base_memory_discardable_memory_internal_h patch-base_memory_madv_free_discardable_memory_posix_cc patch-base_memory_platform_shared_memory_region_h patch-base_memory_platform_shared_memory_region_posix_cc patch-base_message_loop_message_pump_glib_cc patch-base_native_library_posix_cc patch-base_posix_can_lower_nice_to_cc patch-base_posix_unix_domain_socket_cc patch-base_process_kill_h patch-base_process_kill_posix_cc patch-base_process_launch_h patch-base_process_memory_cc patch-base_process_process_handle_cc patch-base_process_process_handle_h patch-base_process_process_handle_openbsd_cc patch-base_process_process_iterator_openbsd_cc patch-base_process_process_metrics_cc patch-base_process_process_metrics_h patch-base_process_process_metrics_openbsd_cc patch-base_process_process_metrics_posix_cc patch-base_process_process_posix_cc patch-base_rand_util_h patch-base_rand_util_posix_cc patch-base_syslog_logging_cc patch-base_system_sys_info_cc patch-base_system_sys_info_h patch-base_system_sys_info_openbsd_cc patch-base_system_sys_info_posix_cc patch-base_test_launcher_test_launcher_cc patch-base_test_test_file_util_linux_cc patch-base_third_party_libevent_event-config_h patch-base_third_party_libevent_openbsd_config_h patch-base_third_party_libevent_openbsd_event-config_h patch-base_third_party_symbolize_symbolize_cc patch-base_threading_platform_thread_h patch-base_threading_platform_thread_linux_cc patch-base_threading_platform_thread_posix_cc patch-base_trace_event_malloc_dump_provider_cc patch-base_trace_event_memory_dump_manager_cc patch-base_trace_event_process_memory_dump_cc patch-build_config_BUILDCONFIG_gn
Re: NEW: wayland/{wayland,wayland-protocols,wayland-utils,plasma-wayland-protocols}
On Fri Oct 29, 2021 at 04:03:00PM +0200, Frederic Cambus wrote: > On Fri, Oct 15, 2021 at 07:20:00AM +0200, Rafael Sadowski wrote: > > > I could imagine the time is right, so soon after the release. I would > > like to import initial wayland ports and thus also a new category > > "wayland". > > > > I realise that it will take time for wayland to work, but that is not > > important for now. > > > > Example: x11/kde-applications/spectacle > > > > Spectacle needs kwayland/qtwayland as a strong dependency (I can build > > this) to be able to take screenshots under either X11 or wayland. Means > > it is not needed at runtime but we can update it. (Currently stuck at a > > very old version). > > > > Does this make sense to you? Is a new category OK for you? > > > > I would be very happy to receive feedback from all porters. > > Thanks for looking into this. > > I think it would make sense to import them if it makes your work on > KDE easier. Also, being proactive regarding Wayland will allow to start > upstreaming patches and ensure it at least keeps building on OpenBSD, > so I view this as a good thing. Thanks for the feedback. > > The potential downsides I see is that those packages might be auto- > detected at configure time by some of our existing ports, and some ports > might need to be adjusted. Good point. > > Another question is how much time this will > be adding to bulk builds, could you give some information about how long > it takes to build those packages on your machine? The whole Wayland category is quit small and builds really quickly. I was surprised myself how slim the whole thing is. It's pure C without heavy C++. Of course QtWayland/KWayland is a different story but even that is okay and that is my problem ;) > > No strong opinion regarding adding a new category, I noticed the other > BSDs didn't seem to create a new category but this doesn't mean we > shouldn't do it. I think x11 and other categories will benefit form it in the long term. Rafael
Re: NEW: wayland/{wayland,wayland-protocols,wayland-utils,plasma-wayland-protocols}
On Fri, 15 Oct 2021 at 07:20:00 +0200, Rafael Sadowski wrote: > Does this make sense to you? Is a new category OK for you? I'm in favor of importing now, and I think a new wayland category and directory is fine.
Re: NEW: wayland/{wayland,wayland-protocols,wayland-utils,plasma-wayland-protocols}
> On Oct 29, 2021, at 10:12 AM, Frederic Cambus wrote: > > On Fri, Oct 15, 2021 at 07:20:00AM +0200, Rafael Sadowski wrote: > >> I could imagine the time is right, so soon after the release. I would >> like to import initial wayland ports and thus also a new category >> "wayland". >> >> I realise that it will take time for wayland to work, but that is not >> important for now. >> >> Example: x11/kde-applications/spectacle >> >> Spectacle needs kwayland/qtwayland as a strong dependency (I can build >> this) to be able to take screenshots under either X11 or wayland. Means >> it is not needed at runtime but we can update it. (Currently stuck at a >> very old version). >> >> Does this make sense to you? Is a new category OK for you? >> >> I would be very happy to receive feedback from all porters. > > Thanks for looking into this. > > I think it would make sense to import them if it makes your work on > KDE easier. Also, being proactive regarding Wayland will allow to start > upstreaming patches and ensure it at least keeps building on OpenBSD, > so I view this as a good thing. > > The potential downsides I see is that those packages might be auto- > detected at configure time by some of our existing ports, and some ports > might need to be adjusted. Another question is how much time this will > be adding to bulk builds, could you give some information about how long > it takes to build those packages on your machine? > > No strong opinion regarding adding a new category, I noticed the other > BSDs didn't seem to create a new category but this doesn't mean we > shouldn't do it. > Sorry for not replying earlier. I was very happy to see these and would like to play around with wayland so ok daniel@ to import and we can work on in the tree as needed. As for a new category, is it expected to grow beyond a few ports? We have this weird java category which I think is pretty useless for example. Who cares if something is written in Java (we don’t have perl, ruby, python categories). Those ports should be in their functional categories. Personally I would probably lean toward putting wayland under x11 and any wayland ports not part of wayland itself in the right categories for those ports. Unless (and I haven’t looked), the wayland platform ports are expected to be numerous. ps. I agree with comment above on things that might pick up wayland at config time, although probably adding to the tree and getting into bulks could be a good way to find out…
UPDATE: net/syncthing-1.18.3
Hi,
Simple update.
This version appears to have encryption support for untrusted nodes, but I've
not played with that yet.
All tests pass amd64.
OK?
Index: Makefile
===
RCS file: /cvs/ports/net/syncthing/Makefile,v
retrieving revision 1.35
diff -u -p -r1.35 Makefile
--- Makefile15 Jun 2021 09:11:02 - 1.35
+++ Makefile29 Oct 2021 13:53:05 -
@@ -4,7 +4,7 @@ BROKEN-aarch64 =golang.org/x/Sys/cpu pan
COMMENT = open decentralized synchronization utility
-V =1.17.0
+V =1.18.3
DISTNAME = syncthing-${V}
DISTFILES =syncthing-source-v${V}${EXTRACT_SUFX}
Index: distinfo
===
RCS file: /cvs/ports/net/syncthing/distinfo,v
retrieving revision 1.24
diff -u -p -r1.24 distinfo
--- distinfo15 Jun 2021 09:11:02 - 1.24
+++ distinfo29 Oct 2021 13:53:12 -
@@ -1,2 +1,2 @@
-SHA256 (syncthing-source-v1.17.0.tar.gz) =
YlQSmRcX4NRC4kvqyI5LehZUX7yMCv/+676V2+rjvjM=
-SIZE (syncthing-source-v1.17.0.tar.gz) = 12768385
+SHA256 (syncthing-source-v1.18.3.tar.gz) =
MsEaVvRntfmkX/MNo4lTOH2hDXG008tBZDxqb1wHPHo=
+SIZE (syncthing-source-v1.18.3.tar.gz) = 12977000
Index: patches/patch-build_go
===
RCS file: /cvs/ports/net/syncthing/patches/patch-build_go,v
retrieving revision 1.14
diff -u -p -r1.14 patch-build_go
--- patches/patch-build_go 15 Jun 2021 09:11:02 - 1.14
+++ patches/patch-build_go 29 Oct 2021 13:54:09 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-build_go,v 1.14 2021/06/
Index: build.go
--- build.go.orig
+++ build.go
-@@ -526,7 +540,7 @@ func appendParameters(args []string, tags []string, pk
+@@ -540,7 +540,7 @@ func appendParameters(args []string, tags []string, pk
if !debugBinary {
// Regular binaries get version tagged and skip some debug
symbols
--
Best Regards
Edd Barrett
https://www.theunixzoo.co.uk
Re: UPDATE: devel/github-cli
On 2021/10/29 13:07, Ricardo wrote: > Hey ports, > > Update to version 2.2.0 released this week. > Tested on amd64. OK? ok > Obrigado e boa semana. > Ricardo
Re: New: textproc/csvquote
On 2021/10/29 13:19, Omar Polo wrote:
> "Allan Streib" writes:
>
> > This is a little utility that I have found useful when processing CSV
> > files that may contain delimeters or newlines within data fields.
> >
> > https://github.com/dbro/csvquote
> >
> > The project provides no release/tags or man page.
>
> that's sad :/
>
> > I offer the attached port for comments/testing.
> >
> > I have tested only on amd64.
> >
> > Allan
>
> I'm attaching an improved version with:
>
> - changed the version from 1.0 to 0.0.20180328. This way, if upstream
>ever decides to tag a version less than 1.0 we won't have troubles.
>
> - HOMEPAGE is not needed, it already defaults to that value.
>
> - same for EXTRACT_SUFX and MASTER_SITES
>
> - missing license comment before PERMIT_PACKAGE
>
> - we can avoid patching the makefile by tweaking FAKE_FLAGS to override
>the makefile' BINDIR.
>
> - indentation
those are all ok with me
> - I don't think installing the project README is useful. The "know
>limitations" part is surely useful, but the rest of the readme not
>that much.
in the absence of a manual, i do think the readme is useful because
it describes what the tool does. i'm ok to import this with the readme
added back in.
> I don't mess with csv files often, but I see why something like this
> could be useful.
>
> btw, it could be possible (and quite easy really) to run cvsquote under
> pledge("stdio rpath", NULL). The code is simple to follow, is a simple
> filter after all :)
>
> Cheers,
>
> Omar Polo
>
Re: NEW: wayland/{wayland,wayland-protocols,wayland-utils,plasma-wayland-protocols}
On Fri, Oct 15, 2021 at 07:20:00AM +0200, Rafael Sadowski wrote: > I could imagine the time is right, so soon after the release. I would > like to import initial wayland ports and thus also a new category > "wayland". > > I realise that it will take time for wayland to work, but that is not > important for now. > > Example: x11/kde-applications/spectacle > > Spectacle needs kwayland/qtwayland as a strong dependency (I can build > this) to be able to take screenshots under either X11 or wayland. Means > it is not needed at runtime but we can update it. (Currently stuck at a > very old version). > > Does this make sense to you? Is a new category OK for you? > > I would be very happy to receive feedback from all porters. Thanks for looking into this. I think it would make sense to import them if it makes your work on KDE easier. Also, being proactive regarding Wayland will allow to start upstreaming patches and ensure it at least keeps building on OpenBSD, so I view this as a good thing. The potential downsides I see is that those packages might be auto- detected at configure time by some of our existing ports, and some ports might need to be adjusted. Another question is how much time this will be adding to bulk builds, could you give some information about how long it takes to build those packages on your machine? No strong opinion regarding adding a new category, I noticed the other BSDs didn't seem to create a new category but this doesn't mean we shouldn't do it.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 08:00:00 Modified files: mail/roundcubemail: Makefile Added files: mail/roundcubemail/patches: patch-program_actions_mail_index_php patch-program_actions_mail_send_php patch-program_actions_mail_show_php patch-program_actions_settings_index_php patch-program_include_rcmail_attachment_handler_php patch-program_js_app_js patch-program_lib_Roundcube_rcube_addressbook_php patch-program_lib_Roundcube_rcube_charset_php patch-program_lib_Roundcube_rcube_mime_php patch-program_lib_Roundcube_rcube_result_index_php patch-skins_larry_ui_js Log message: roundcube: cherrypick a few fixes from the release-1.5 branch
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2021/10/29 07:52:32 Modified files: textproc/mdbook: Makefile distinfo textproc/mdbook/pkg: PLIST Log message: textproc/mdbook: simple upgrade to v0.4.13.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: tra...@cvs.openbsd.org 2021/10/29 07:17:26 Modified files: devel/py-esptool: Makefile distinfo devel/py-esptool/pkg: PLIST Log message: Update devel/py-esptool to 3.2. ok benoit@
Re: New: textproc/csvquote
"Allan Streib" writes:
> This is a little utility that I have found useful when processing CSV
> files that may contain delimeters or newlines within data fields.
>
> https://github.com/dbro/csvquote
>
> The project provides no release/tags or man page.
that's sad :/
> I offer the attached port for comments/testing.
>
> I have tested only on amd64.
>
> Allan
I'm attaching an improved version with:
- changed the version from 1.0 to 0.0.20180328. This way, if upstream
ever decides to tag a version less than 1.0 we won't have troubles.
- HOMEPAGE is not needed, it already defaults to that value.
- same for EXTRACT_SUFX and MASTER_SITES
- missing license comment before PERMIT_PACKAGE
- we can avoid patching the makefile by tweaking FAKE_FLAGS to override
the makefile' BINDIR.
- indentation
- I don't think installing the project README is useful. The "know
limitations" part is surely useful, but the rest of the readme not
that much.
I don't mess with csv files often, but I see why something like this
could be useful.
btw, it could be possible (and quite easy really) to run cvsquote under
pledge("stdio rpath", NULL). The code is simple to follow, is a simple
filter after all :)
Cheers,
Omar Polo
csvquote.tar.gz
Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: e...@cvs.openbsd.org2021/10/29 07:08:59 Modified files: devel/snare: Makefile distinfo Log message: devel/snare: Update to version 0.4.4. Diff sent in from package author, Laurence Tratt. Thanks!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 06:47:50 Modified files: www/twill : Makefile Log message: set PORTROACH/HOMEPAGE to point at the actively maintained version (this is long overdue an update)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 06:15:32 Modified files: mail/neomutt : Makefile distinfo Log message: update to neomutt-20211029
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: t...@cvs.openbsd.org2021/10/29 06:06:50 Modified files: mail/offlineimap: Makefile Log message: mail/offlineimap: add missing RDEP on py3-distro, ok sthen
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: patr...@cvs.openbsd.org 2021/10/29 05:14:46 Modified files: sysutils/u-boot: Makefile sysutils/u-boot/pkg: PFRAG.aarch64 Added files: sysutils/u-boot/patches: patch-arch_arm_dts_rk3328-nanopi-r2s_dts patch-configs_nanopi-r2s-rk3328_defconfig Log message: Build nanopi-r2s-rk3328 as well. ok jsg@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: patr...@cvs.openbsd.org 2021/10/29 05:13:06 Modified files: sysutils/dtb : Makefile Added files: sysutils/dtb/patches: patch-arch_arm64_boot_dts_rockchip_rk3328-nanopi-r2s_dts Log message: Set the baud rate for the NanoPi R2S like we do for other Rockchip-based SoCs. ok jsg@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: st...@cvs.openbsd.org 2021/10/29 05:12:07
Modified files:
devel/quirks : Makefile
devel/quirks/files: Quirks.pm
www: Makefile
devel : Makefile
Removed files:
devel/py-wsgiutils: Makefile distinfo
devel/py-wsgiutils/patches: patch-runtests_py
devel/py-wsgiutils/pkg: DESCR PLIST
www/py-paste : Makefile distinfo
www/py-paste/pkg: DESCR PLIST
www/py-paste-deploy: Makefile distinfo
www/py-paste-deploy/pkg: DESCR PLIST
www/py-paste-script: Makefile distinfo
www/py-paste-script/patches: patch-setup_py
www/py-paste-script/pkg: DESCR PLIST
Log message:
remove py-paste and related ports and ports only used by them.
the versions in ports are py2-only and old; there are newer releases
but they're still on life support ("please consider using other
options" etc) and were only used by tilecache which was removed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 04:58:26 Modified files: devel/py-zipp : Makefile net/py-portend : Makefile Log message: remove another couple of py-toml used by setuptools_scm
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 04:57:45 Modified files: security/py-keyring: Makefile Log message: remove another py-toml used for setuptools_scm
Re: freshclam doesn't use DNS any more for updates check
On 2021/10/29 07:15, Mikolaj Kucharski wrote: > Hi Stuart, > > Sorry I didn't look deeply into it and not providing a solution. I only > managed open a bug upstream: > > https://github.com/Cisco-Talos/clamav/issues/340 > > It seems, what I didn't know, ClamAV 0.104.0 migrated to cmake. On above > GitHub issue, per comment from @micahsnyder: > > > My guess is that HAVE_RESOLV_H is not defined and that either the new > > CMake build system doesn't know how to find /usr/include/resolv.h or [...] Thanks, I commented on the ticket and have committed a workaround to the port
Re: emulators/fceux: update 2.2.3 -> 2.4.0
"Anthony J. Bentley" writes: > Omar Polo writes: >> "Anthony J. Bentley" writes: >> > - The perl in post-extract should be replaced with FIX_CRLF_FILES. >> >> I did that, but I think that in this specific case the previous way with >> perl was cleaner because almost all the files have CRLF line endings. > > It's not so bad. Actually we aren't currently patching any files with > bad line endings, so I went ahead and committed your diff, but dropping > FIX_CRLF_FILES completely. Ouch, I completely missed that, sorry! > Thanks for the patch! Cheers!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 04:34:08 Modified files: security/clamav: Makefile Added files: security/clamav/patches: patch-CMakeLists_txt Log message: clamav/freshclam: patch resolv.h detection, cmake's check_include_file tries to compile a test file which just #includes resolv.h and doesn't seem to have a way to specify that another header is needed. problem reported by Mikolaj Kucharski, the CDN for freshclam starts refusing connections if you don't do DNS-based checks https://github.com/Cisco-Talos/clamav/issues/340
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 04:32:44 Modified files: mail/evolution-ews: Makefile distinfo Log message: Update to evolution-ews-3.42.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 04:32:23 Modified files: mail/evolution : Makefile distinfo mail/evolution/pkg: PLIST Log message: Update to evolution-3.42.1.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 04:31:58 Modified files: databases/evolution-data-server: Makefile distinfo databases/evolution-data-server/pkg: PLIST Added files: databases/evolution-data-server/patches: patch-src_camel_camel-hostname-utils_c Log message: Update to evolution-data-server-3.42.1.
Re: emulators/fceux: update 2.2.3 -> 2.4.0
Omar Polo writes: > "Anthony J. Bentley" writes: > > - The perl in post-extract should be replaced with FIX_CRLF_FILES. > > I did that, but I think that in this specific case the previous way with > perl was cleaner because almost all the files have CRLF line endings. It's not so bad. Actually we aren't currently patching any files with bad line endings, so I went ahead and committed your diff, but dropping FIX_CRLF_FILES completely. Thanks for the patch!
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2021/10/29 04:26:23 Modified files: emulators/fceux: Makefile Log message: Drop FIX_CRLF_FILES, as it's not currently needed.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bent...@cvs.openbsd.org 2021/10/29 04:13:16 Modified files: emulators/fceux: Makefile distinfo emulators/fceux/patches: patch-fceux_desktop emulators/fceux/pkg: DESCR PLIST Added files: emulators/fceux/patches: patch-scripts_genGitHdr_sh patch-src_CMakeLists_txt patch-src_drivers_Qt_ConsoleWindow_cpp Removed files: emulators/fceux/patches: patch-SConstruct patch-fceux-server_server_cpp patch-src_boards_rt-01_cpp patch-src_cheat_cpp patch-src_utils_xstring_cpp Log message: Update to fceux-2.4.0. >From Omar Polo; thanks!
Re: backport CVE fixes audio/sox
On 2021/10/28 22:36, Nam Nguyen wrote:
> I prepared a release tarball from a checkout:
> install groff for tbl and nroff
> install autoconf-archive, autoconf and automake
> edit src/Makefile.am append "libsox.sym" to EXTRA_DIST (needed to avoid
> compilation error)
> edit configure.ac: 14.4.3git --> 14.4.2pl20210509
> $ AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 autoreconf-2.69 -i
> $ ./configure
> $ gmake dist
I would prefer it if those extra steps were done in the port, either as
a "dist" target to generate the tar, or as steps in the normal build
so that it can use an unmodified archive from git. Alternatively (less
preferred but I would still be ok with it) with comments showing how
to do it. Bsaically so that somebody else wanting to update it doesn't
need to figure it out for themselves.
> Minor bump
> --
> Minor increased because check_sym reports new lsx_* symbols. According
> to the top of ${WRKSRC}/src/sox.h, "lsx_" or "LSX_" are internal use,
> but bump it anyways due their visibility. (sox_* are part of the public
> interface.)
ack.
> check_sym: https://namtsui.com/public/sox_sym.txt
>
> Also, datatypes changed in ${WRKSRC}/src/sox.h.
> See:
> https://sourceforge.net/p/sox/code/ci/3518bcd92416e7cf71ee9a863695a518f3de4e52/
> /usr/src/sys/sys/types.h
> /usr/src/sys/sys/stdint.h
> /usr/src/sys/arch/i386/include/_types.h
> /usr/src/sys/sys/limits.h
>
> Based on this, the only difficult one was long --> long long.
>
> -#if LONG_MAX==9223372036854775807 && LONG_MIN==(-9223372036854775807-1)
> -typedef long sox_int64_t;
> -#elif defined(_MSC_VER)
> -typedef __int64 sox_int64_t;
> -#else
> -typedef long long sox_int64_t;
> -#endif
> +typedef int64_t sox_int64_t;
>
> From this I read sox_int64_t's type definition before --> after:
> amd64: long --> long long
> i386: long long --> long long
>
> Conclusion: Types changed in a compatible way because it goes from a
> smaller to bigger datatype, so no need to major bump. sox_uint64_t also
> falls under this.
Had the types changed to a different size, even from a smaller to a
bigger datatype e.g. 32-bit to 64-bit, that wouldn't be a compatible
change - structs using them would change layout (maybe not on all archs
depending on how the variables are layed out, but there's also little-
vs big-endian to take into account), same for variables passed to
functions.
However these only changed to different types represented by the same
byte format, i.e. on 64-bit arches both long and long long are 64-bit
so there's no actual change to layout, so that doesn't break ABI.
Newer compilers warn about the difference in type rather than the
difference in representation because it can be a problem if you test
something on one arch and don't see a mismatch, but then somebody
goes to build on another and runs into the problem.
> make port-lib-depends still wants to remove opus from WANTLIB, which is
> new behavior. I do not know why. However, it is probably just fine to
> leave it in for clarity. sox uses opusfile, which depends on opus
> anyways.
Could you remove that please - sox doesn't use libopus functions directly,
only uses other libraries which call those functions. This changed because
sox now uses -Wl,--as-needed.
> - --without-amrwb \
> - --without-amrnb \
> + --enable-formats=no \
Though --enable-formats=no stops it from building the amr format
support, I think it would be better to disable it detecting it at all,
i.e.
--without-opencore-amrnb \
--without-opencore-amrwb \
> do-test:
> + @cd ${WRKSRC}/src && env -i ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
"env -i ${MAKE_ENV}" isn't needed, the environment is already setup
enough for this
> # Attempt to avoid SIGILL in gcc.
- which sets an hppa-only thing, and there's also BROKEN-hppa.
The code changed, so I would just remove both of these. If someone
actually does a ports build on hppa we can see how it goes.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/10/29 02:40:18 Modified files: devel/quirks : Makefile devel/quirks/files: Quirks.pm geo: Makefile Removed files: geo/tilecache : Makefile distinfo geo/tilecache/patches: patch-setup_py geo/tilecache/pkg: DESCR PLIST Log message: remove geo/tilecache, ok landry py2-only, no activity upstream in a long time (some newer code at https://github.com/OSGeo/tilecache but even that is from 7 years ago), depends on py-paste which is "on limited life-support", and there are more modern alternatives (mapproxy is in ports, or there are also java applications like geowebcache/geoserver).
Re: getExecutablePath (Was: adb: any users left?)
Are the executables run with their full path for the bootstrap compilers? If so, could it preferentially use that from argv[0] (like sshd does when it needs to know its own path for reexec), and fallback to /usr/local/whatever if there's no / in argv[0]? -- Sent from a phone, apologies for poor formatting. On 29 October 2021 04:48:13 Greg Steuck wrote: "Theo de Raadt" writes: Wind R wrote: 1. OpenBSD doesn't have a syscall that returns the current path to the executable file of the process, which adb and fastboot both use. This system call is impossible. It is not possible to convert an inode to a path cheaply. A variety of systems have this, and it either (very often) or (upon occasion) lies. When it lies, the applications take a variety of bullshit strategies to cope, pretty much all of them wrong. It appears this idea came from Windows, where you can install applications in various directories. Our ports applications are always installed in /usr/include Is that difficult to understand? Should we make this system call and make it always lie or fail, to demonstrate the issue to the community, or can they finally understand that OpenBSD ports are *always installed to the same place*? I ran into this head-on with ghc. The problem here is not the eventual installation, but rather the development builds. These aren't installed into the final destination when building bootstrap compilers. A great answer to this is to pass paths explicitly. Unfortunately the layers of stuff make this into a non-trivial complication and otherwise patient people give up: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6263 This is not immediately actionable, just sharing the kinds of things that get side-tracked. Thanks Greg
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 01:36:24 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.21.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 01:36:08 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.19.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 01:35:57 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.22.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 01:29:37 Modified files: x11/gnome/control-center: Makefile distinfo Log message: Update to gnome-control-center-40.6.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 01:17:39 Modified files: graphics/gthumb: Makefile Log message: Missing LDEP on multimedia/libheif.
freshclam doesn't use DNS any more for updates check
Hi Stuart, Sorry I didn't look deeply into it and not providing a solution. I only managed open a bug upstream: https://github.com/Cisco-Talos/clamav/issues/340 It seems, what I didn't know, ClamAV 0.104.0 migrated to cmake. On above GitHub issue, per comment from @micahsnyder: > My guess is that HAVE_RESOLV_H is not defined and that either the new > CMake build system doesn't know how to find /usr/include/resolv.h or [...] Currently I don't spend almost any time on OpenBSD ports, but wanted to report what I saw so far. -- Regards, Mikolaj
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/10/29 00:56:07 Modified files: x11/gnome/music: Makefile Log message: Needs x11/libhandy.
