CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2021/01/08 18:57:26 Modified files: net/p5-BSD-Socket-Splice: Makefile distinfo Log message: update p5-BSD-Socket-Splice to 0.09
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: mes...@cvs.openbsd.org 2021/01/08 18:28:03 Modified files: www/youtube-dl : Makefile distinfo www/youtube-dl/pkg: PLIST Log message: update to 2021.01.08
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2021/01/08 17:14:40 ports/net/p5-Net-Patricia/patches Update of /cvs/ports/net/p5-Net-Patricia/patches In directory cvs.openbsd.org:/tmp/cvs-serv74040/patches Log Message: Directory /cvs/ports/net/p5-Net-Patricia/patches added to the repository
[update] archivers/gtar 1.32 -> 1.33
Hi,
Today I was presenting the OpenBSD ports and packages system to my local
Unix User Group. I was asked how to update a port and showed this at the
simple example of archives/gtar.
Maintainer on CC.
Changes in gtar:
* POSIX extended format headers do not include PID by default.
* --delay-directory-restore works for archives with reversed member ordering.
* Fix extraction of a symbolic link hardlinked to another symbolic link.
* Wildcards in exclude-vcs-ignore mode don't match slash.
* Fix the --no-overwrite-dir option.
* Fix handling of chained renames in incremental backups.
* Link counting works for file names supplied with -T.
* Accept only position-sensitive (file-selection) options in file list files.
Port changes:
* removed REVISION
* bumped version
portcheck, make port-lib-depends-check: ok
make test:
amd64 - up to test 165 all good, then I ran out of disk space
sparc64 - passed
OK?
Best Regards,
Stefan
Index: archivers/gtar/Makefile
===
RCS file: /cvs/ports/archivers/gtar/Makefile,v
retrieving revision 1.85
diff -u -p -u -p -r1.85 Makefile
--- archivers/gtar/Makefile 16 Jul 2019 21:29:41 - 1.85
+++ archivers/gtar/Makefile 8 Jan 2021 23:07:49 -
@@ -2,9 +2,8 @@
COMMENT= GNU version of the traditional tape archiver
-DISTNAME= tar-1.32
+DISTNAME= tar-1.33
PKGNAME= g${DISTNAME}
-REVISION= 1
CATEGORIES=archivers
HOMEPAGE= https://www.gnu.org/software/tar/
Index: archivers/gtar/distinfo
===
RCS file: /cvs/ports/archivers/gtar/distinfo,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 distinfo
--- archivers/gtar/distinfo 25 Feb 2019 21:01:58 - 1.26
+++ archivers/gtar/distinfo 8 Jan 2021 23:07:49 -
@@ -1,2 +1,2 @@
-SHA256 (tar-1.32.tar.xz) = 0NOuB/EDMjvoCbw+rA3MOG1SxSYkmf4FURrEeIrx/dg=
-SIZE (tar-1.32.tar.xz) = 2103348
+SHA256 (tar-1.33.tar.xz) = Zqg0Sx3IOkEdMRvRVH4BduVswxHyjulKMPhNr7PZBn4=
+SIZE (tar-1.33.tar.xz) = 2224824
Index: archivers/gtar/patches/patch-configure
===
RCS file: /cvs/ports/archivers/gtar/patches/patch-configure,v
retrieving revision 1.18
diff -u -p -u -p -r1.18 patch-configure
--- archivers/gtar/patches/patch-configure 13 Jan 2019 15:34:55 -
1.18
+++ archivers/gtar/patches/patch-configure 8 Jan 2021 23:07:49 -
@@ -2,7 +2,7 @@ $OpenBSD: patch-configure,v 1.18 2019/01
Index: configure
--- configure.orig
+++ configure
-@@ -36944,7 +36944,7 @@ fi
+@@ -40537,7 +40537,7 @@ fi
$as_echo "$acl_cv_rpath" >&6; }
wl="$acl_cv_wl"
acl_libext="$acl_cv_libext"
Re: [new] sysutils/obsdpkgup - tools for creating and using a package index
[moved misc@ to ports@] > > Between those two it could cause problems because the user may try to > > update a too-small subset of packages. The first problem is obvious. > > The second problem, if a library is bumped after the index is generated, > > the required updates won't show up. For both if people use it and then > > run into problems it's likely the bug reports will end up with openbsd > > rather than pkgup. This makes me not want to add it to packages yet > > (adding it could easily be seen as an endorsement of using it). > > This would be less of a problem if it at least tries to detect outdated > > caches and prints a clear warning. > > > > I hope that my above two fixes rectify this situation in your mind. This definitely helps a lot. > I would like this as well. The problem is that pkg_info -qS is slow. It takes > orders of magnitude more time to run than my current signature generation > code. > I can currently build a complete index from a remote mirror in less than ten > minutes. If I switched to using pkg_info, it would take several hours by my > math. In addition, I would like to keep genpkgup able to be run on any OS that > Go supports instead of only OpenBSD machines. I went ahead and > sorta-implemented your suggestion though by matching OpenBSD's current > signature format. No more hashes. I was torn on this before, but I actually > like your approach better because A: it's easier to debug when things go wrong > and B: it's much less CPU-intensive not having to do sha256 stuff. So again, > thank you for the recommendation. If the signature format changes in the > future, I will gladly update my code to match, or revisit the problem if > necessary. For the place where I think it makes most sense to generate index files, the requirements are pretty much the opposite - OpenBSD tools and simple scripts are ok but Go (or indeed anything from ports) is not wanted. So I've bodged together a shell script to generate a new style index using pkg_info -qPS from local tgz files and given it a run on the brand new amd64 pkg snap (at the time I generated it wasn't on cdn/mirrors, it may be on some now but may need a bit longer to feed out). I don't know how that will go for pkg_add over the network but with local files it's not too bad; about 6 minutes. Could do with comparing with the results of your genpkgup with mine when the files are on the mirrors, copy of my generated file at junkpile.org/index.pkgup.amd64-20210108.gz (it is deliberately missing entries for all the packages which use "@option always-update" i.e. quirks/sqlports/etc because pkg_info -S is not quite working as expected for them ;) The following two paragraphs might relate to my different genpkgup but I don't _think_ they do; I ran the pkg_add command generated by obsdpkgup followed by a normal pkg_add -u; the normal one picked up a few more packages (some of them definitely in need of an update because the installed packages still linked against old libc++). I haven't got proper logs from the run (I used pkg_add -vv but forgot to run it in script and ran out of scrollback..) but the packages picked up by pkg_add -u included ansible+deps, audacity, boehm-gc, jack, distcc/distcc-gtk, graphviz, pulseaudio, powerdns. I would expect any discrepancy in how the signature is generated to result in a possibly unneeded update, rather than missing one, which is why I think this is probably not on the gen side. Another minor thing I spotted; the displayed pkg_add command has full paths after %, pkg_add accepts this but the canonical format is just the last part i.e. openssl%1.0.2 rather than openssl%security/openssl/1.0.2. https://github.com/neutralinsomniac/obsdpkgup/commit/36ff10dd2f67b666b219b72de80bf5efd69a4027 ouch! I didn't realise they had an hex sha256 of each 64K block. I suppose overall it's not _huge_ in modern disk space terms (about 50MB for the full amd64 package build) but more than I expected. > Again, thank you for taking the time to look at my tool! pkg_add tries to make as good a job as it can from an partially updated pkg mirror and has some overhead due to that (it intentionally doesn't use an index file because it doesn't want to trust that it reflects the actual contents of the mirror). I'm not convinced this flexibility is useful in many cases - certainly if I notice that a mirror is not fully synced my usual course of action is to look for another mirror or postpone the update because continuing will often result in a mess of installed packages built against conflicting library versions. So I think there is use for a tool that takes a different approach on this and I'm definitely interested to see how update times compare when using this to pre-calculate things, as long as it's able to find all the packages that do need an update :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: j...@cvs.openbsd.org2021/01/08 16:58:29 Modified files: games/eduke32 : Makefile distinfo games/eduke32/patches: patch-Common_mak patch-GNUmakefile patch-source_audiolib_src_multivoc_cpp patch-source_audiolib_src_xmp_cpp patch-source_duke3d_src_game_cpp Removed files: games/eduke32/patches: patch-source_duke3d_src_gamevars_h Log message: update eduke32 to 9297-2bb6cbcae ok mestre@ Ryan Freeman (MAINTAINER)
Re: update eduke32 to 9297-2bb6cbcae
Nice, thanks for this. Tested on amd64 just fine against the shareware
data and atomic edition data, played through the first level ok.
OK from me.
-ryan
On Tue, Jan 05, 2021 at 09:21:18PM +1100, Jonathan Gray wrote:
> Tested with Duke3D and Ion Fury.
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/games/eduke32/Makefile,v
> retrieving revision 1.26
> diff -u -p -r1.26 Makefile
> --- Makefile 10 Apr 2020 14:59:48 - 1.26
> +++ Makefile 5 Jan 2021 08:36:16 -
> @@ -1,11 +1,10 @@
> # $OpenBSD: Makefile,v 1.26 2020/04/10 14:59:48 cwen Exp $
>
> COMMENT =Enhanced Duke Nukem 3D engine
> -RDATE = 20191222
> -RTAG = 8494
> +RDATE = 20201221
> +RTAG = 9297-2bb6cbcae
> DISTNAME = eduke32_src_${RDATE}-${RTAG}
> -PKGNAME =eduke32-2.0.0.${RTAG}
> -REVISION = 0
> +PKGNAME =eduke32-2.0.0.${RTAG:C/-.*$//}
> EXTRACT_SUFX = .tar.xz
> CATEGORIES = games x11
>
> Index: distinfo
> ===
> RCS file: /cvs/ports/games/eduke32/distinfo,v
> retrieving revision 1.5
> diff -u -p -r1.5 distinfo
> --- distinfo 30 Dec 2019 08:32:46 - 1.5
> +++ distinfo 5 Jan 2021 08:36:16 -
> @@ -1,2 +1,2 @@
> -SHA256 (eduke32_src_20191222-8494.tar.xz) =
> RaI1M725fVdITdOus9lSZQQspn1R/PfxFpUugWTOcww=
> -SIZE (eduke32_src_20191222-8494.tar.xz) = 15951736
> +SHA256 (eduke32_src_20201221-9297-2bb6cbcae.tar.xz) =
> QkVw0E3G1pdUymv9y1OeAUh/Hci308htJQFATOOvUpQ=
> +SIZE (eduke32_src_20201221-9297-2bb6cbcae.tar.xz) = 19943652
> Index: patches/patch-Common_mak
> ===
> RCS file: /cvs/ports/games/eduke32/patches/patch-Common_mak,v
> retrieving revision 1.2
> diff -u -p -r1.2 patch-Common_mak
> --- patches/patch-Common_mak 30 Dec 2019 08:32:46 - 1.2
> +++ patches/patch-Common_mak 5 Jan 2021 08:36:16 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-Common_mak,v 1.2 2019/12
> Index: Common.mak
> --- Common.mak.orig
> +++ Common.mak
> -@@ -710,7 +710,7 @@ ifeq (0,$(RELEASE))
> +@@ -693,7 +693,7 @@ ifeq (0,$(RELEASE))
> F_NO_STACK_PROTECTOR :=
> else
> ifeq (0,$(CLANG))
> @@ -12,3 +12,13 @@ Index: Common.mak
> endif
>
> ifeq (0,$(FORCEDEBUG))
> +@@ -1017,7 +1017,8 @@ ifeq (,$(VC_HASH))
> + VC_HASH := $(shell git rev-parse --short=9 HEAD 2>&1)
> + endif
> + ifeq (,$(VC_BRANCH))
> +-VC_BRANCH := $(shell git rev-parse --abbrev-ref HEAD 2>&1)
> ++#VC_BRANCH := $(shell git rev-parse --abbrev-ref HEAD 2>&1)
> ++VC_BRANCH := master
> + ifneq (master,$(VC_BRANCH))
> + VC_REV := $(VC_REV)[$(VC_BRANCH)]
> + endif
> Index: patches/patch-GNUmakefile
> ===
> RCS file: /cvs/ports/games/eduke32/patches/patch-GNUmakefile,v
> retrieving revision 1.3
> diff -u -p -r1.3 patch-GNUmakefile
> --- patches/patch-GNUmakefile 30 Dec 2019 08:32:46 - 1.3
> +++ patches/patch-GNUmakefile 5 Jan 2021 08:36:16 -
> @@ -3,7 +3,7 @@ $OpenBSD: patch-GNUmakefile,v 1.3 2019/1
> Index: GNUmakefile
> --- GNUmakefile.orig
> +++ GNUmakefile
> -@@ -240,7 +240,6 @@ engine_objs := \
> +@@ -222,7 +222,6 @@ engine_objs := \
> hightile.cpp \
> klzw.cpp \
> kplib.cpp \
> @@ -11,7 +11,7 @@ Index: GNUmakefile
> md4.cpp \
> mhk.cpp \
> miniz.c \
> -@@ -403,8 +402,8 @@ ifeq ($(RENDERTYPE),SDL)
> +@@ -387,8 +386,8 @@ ifeq ($(RENDERTYPE),SDL)
> endif
>
> ifneq (0,$(HAVE_XMP))
> @@ -22,7 +22,7 @@ Index: GNUmakefile
> endif
>
>
> -@@ -684,7 +683,7 @@ ifeq ($(SUBPLATFORM),LINUX)
> +@@ -587,7 +586,7 @@ ifeq ($(SUBPLATFORM),LINUX)
> endif
>
> ifeq ($(PLATFORM),BSD)
> @@ -31,7 +31,7 @@ Index: GNUmakefile
> endif
>
> ifeq ($(PLATFORM),DARWIN)
> -@@ -851,13 +850,14 @@ endif
> +@@ -760,13 +759,14 @@ endif
>
> Final setup
>
> @@ -47,11 +47,3 @@ Index: GNUmakefile
>
> ifneq (0,$(USE_PHYSFS))
> COMPILERFLAGS += -I$(physfs_inc) -DUSE_PHYSFS
> -@@ -875,7 +875,6 @@ libraries := \
> - audiolib \
> - engine \
> - glad \
> --libxmplite \
> - lpeg \
> - mact \
> - voidwrap \
> Index: patches/patch-source_audiolib_src_multivoc_cpp
> ===
> RCS file:
> /cvs/ports/games/eduke32/patches/patch-source_audiolib_src_multivoc_cpp,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-source_audiolib_src_multivoc_cpp
> --- patches/patch-source_audiolib_src_multivoc_cpp30 Dec 2019 08:32:46
> - 1.1
> +++ patches/patch-source_audiolib_src_multivoc_cpp5 Jan 2021 08:36:16
> -
> @@ -13,5 +13,5 @@ Index: source/audiolib/src/multivoc.cpp
> -# include "libxmp-lite/xmp.h"
> +# include
>
> - int MV_XMPInterpolation = XMP_INTERP_SPLINE;
> + int MV_XMPInterpolation = XMP_INTERP_NEAREST;
> #endif
> Index:
Re: Using Packages to add a ports dependencies
On 2021/01/08 14:49, Steve Williams wrote: > Hi, > > I have rebuilt my development system to get a nice clean starting point. > I'm following -current on amd64. > > I want to work on a port that is a pet project (guacamole/xfreerdp). There > are a bunch of dependencies on the port and I was wondering if there is an > easy way to either > >1) Tell the ports system to use packages to fulfill any dependencies >2) generate a list of dependencies that can be fed to pkg_add > > > I have been manually adding the packages based on the dependencies in the > ports Makefile, but after doing this manual process a bunch of times (yes, I > finally made a shell script), I was wondering if there was an easier way. > > Thanks, > Steve W. > "make prepare FETCH_PACKAGES=" Right now, pkg_add may run into problems with C++ library dependencies; a new set of packages has just been built following library bumps in base and should show up at mirrors over the next few hours
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/08 15:18:25 Modified files: devel/subversion: Makefile Log message: repair PKGNAME-python; I was relying on python.port.mk doing s/py-/py3-/ but that doesn't actually apply in case of multipackages
Re: comms/amtterm: add support for ssl and digest auth
On Fri, Jan 08, 2021 at 12:21:00PM +0100, Stefan Sperling wrote: > This adds a patch which makes amtterm work against a machine running > Intel ME version 12. > > This should really be upstream code, but it looks like upstream is inactive. > And without this patch amtterm is entirely useless against current machines. > So I think in this case it is worth patching it ourselves. I hope that if > upstream becomes active again a future update will make these patches > unnecessary. OK kn
Using Packages to add a ports dependencies
Hi, I have rebuilt my development system to get a nice clean starting point. I'm following -current on amd64. I want to work on a port that is a pet project (guacamole/xfreerdp). There are a bunch of dependencies on the port and I was wondering if there is an easy way to either 1) Tell the ports system to use packages to fulfill any dependencies 2) generate a list of dependencies that can be fed to pkg_add I have been manually adding the packages based on the dependencies in the ports Makefile, but after doing this manual process a bunch of times (yes, I finally made a shell script), I was wondering if there was an easier way. Thanks, Steve W.
Re: update arm-trusted-firmware to 2.4
On Fri, 2021-01-08 at 11:48 -0500, Kurt Miller wrote: > On Fri, 2021-01-08 at 10:27 +1100, Jonathan Gray wrote: > > > > On Thu, Jan 07, 2021 at 04:29:35PM -0500, Kurt Miller wrote: > > > > > > > > > On Thu, 2020-12-31 at 19:24 +1100, Jonathan Gray wrote: > > > > > > > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-2-4 > > > > > > > > Tests welcome as I don't have rk3328/rk3399/sun50i_a64 hardware. > > > This update appears ok on rk3328 and rk3399, however my rockpro64 > > > will not boot with u-boot 2020.10: > > > > > > Rock64 Gen3 w/ v2020.10 u-boot and atf 2.4 works > > > Rockpro64 w/2020.10 u-boot and atf 2.4 and 2.3 fails > > > Rockpro64 w/2020.07 u-boot and atf 2.4 and 2.3 works > > > > > > With 2020.10 u-boot the rockpro64 freezes just after attempting to > > > boot the kernel. Here's a diff of v2020.07 with atf 2.3 that works > > > against v2020.10 with atf 2.3 that freezes: > > > > > > rocky$ diff -u v2020.07.boot v2020-10.boot > > > --- v2020.07.boot Thu Jan 7 16:20:58 2021 > > > +++ v2020-10.boot Thu Jan 7 16:10:27 2021 > > > @@ -1,19 +1,18 @@ > > > -U-Boot TPL 2020.07 (Jul 07 2020 - 19:02:53) > > > +U-Boot TPL 2020.10 (Jan 02 2021 - 11:16:03) > > > Channel 0: LPDDR4, 50MHz > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > > Channel 1: LPDDR4, 50MHz > > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > > 256B stride > > > -256B stride > > > lpddr4_set_rate: change freq to 4 mhz 0, 1 > > > lpddr4_set_rate: change freq to 8 mhz 1, 0 > > > Trying to boot from BOOTROM > > > Returning to boot ROM... > > > > > > -U-Boot SPL 2020.07 (Jul 07 2020 - 19:02:53 -0600) > > > +U-Boot SPL 2020.10 (Jan 02 2021 - 11:16:03 -0700) > > > Trying to boot from MMC1 > > > NOTICE: BL31: v2.3():2.3 > > > -NOTICE: BL31: Built : 18:41:43, Jul 7 2020 > > > +NOTICE: BL31: Built : 10:45:12, Jan 2 2021 > > > INFO:GICv3 with legacy support detected. > > > INFO:ARM GICv3 driver initialized in EL3 > > > INFO:plat_rockchip_pmu_init(1624): pd status 3e > > > @@ -24,7 +23,7 @@ > > > INFO:SPSR = 0x3c9 > > > > > > > > > -U-Boot 2020.07 (Jul 07 2020 - 19:02:53 -0600) > > > +U-Boot 2020.10 (Jan 02 2021 - 11:16:03 -0700) > > > > > > SoC: Rockchip rk3399 > > > Reset cause: RST > > > @@ -32,14 +31,29 @@ > > > DRAM: 3.9 GiB > > > PMIC: RK808 > > > MMC: mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0 > > > -Loading Environment from SPI Flash... SF: Detected gd25q128 with page > > > size 256 Bytes, erase size 4 KiB, total 16 > > > MiB > > > -*** Warning - bad CRC, using default environment > > > +Loading Environment from SPIFlash... Invalid bus 0 (err=-19) > > > +*** Warning - spi_flash_probe_bus_cs() failed, using default environment > > > > > > In:serial > > > Out: serial > > > Err: serial > > > Model: Pine64 RockPro64 v2.1 > > > Net: eth0: ethernet@fe30 > > > +starting USB... > > > +Bus usb@fe38: USB EHCI 1.00 > > > +Bus usb@fe3a: USB OHCI 1.0 > > > +Bus usb@fe3c: USB EHCI 1.00 > > > +Bus usb@fe3e: USB OHCI 1.0 > > > +Bus dwc3: usb maximum-speed not found > > > +Register 2000140 NbrPorts 2 > > > +Starting the controller > > > +USB XHCI 1.10 > > > +scanning bus usb@fe38 for devices... 1 USB Device(s) found > > > +scanning bus usb@fe3a for devices... 1 USB Device(s) found > > > +scanning bus usb@fe3c for devices... 1 USB Device(s) found > > > +scanning bus usb@fe3e for devices... 1 USB Device(s) found > > > +scanning bus dwc3 for devices... 1 USB Device(s) found > > > + scanning usb for storage devices... 0 Storage Device(s) found > > > Hit any key to stop autoboot: 0 > > > Card did not respond to voltage select! > > > switch to partitions #0, OK > > > @@ -56,11 +70,14 @@ > > > Scanning disk sd...@fe33.blk... > > > Disk sd...@fe33.blk not ready > > > Found 3 disks > > > +No EFI system partition > > > BootOrder not defined > > > EFI boot manager: Cannot load any image > > > -168728 bytes read in 14 ms (11.5 MiB/s) > > > +168728 bytes read in 13 ms (12.4 MiB/s) > > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > > +Booting /efi\boot\bootaa64.efi > > > disks: sd0* > > > >> OpenBSD/arm64 BOOTAA64 1.3 > > > boot> > > > -booting sd0a:/bsd: 8657572+1775464+561576+826224 > > > [629354+109+1059720+622048]=0xf87520 > > > +booting sd0a:/bsd: 8663848+1773392+563520+828336 > > > [629656+109+1059720+621958]=0xf885c8 > > > > > > v2020.07 u-boot continues from here, v2020.10 u-boot freezes. > > > > > > Ideas? > > Can you try build the latest U-Boot git? I think you'll have to bisect. > Bisecting shows this commit is the culprit: > > commit 3ae64582fb8ceead4fc464cd2055eb3eaef78ccc (refs/bisect/bad) > Author: Jagan Teki > Date: Mon Jul 20 14:53:09 2020 +0530 > > rockchip: rockpro64: Enable USB3.0 Host > > Enable USB3.0 Host support for RockPro64 boards. > > Signed-off-by: Jagan Teki
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Thu Jan 7 12:55:19 MST 2021 finished at Fri Jan 8 13:22:09 MST 2021 lasted 1D00h26m done with kern.version=OpenBSD 6.8-current (GENERIC.MP) #965: Thu Jan 7 03:24:36 MST 2021 built packages:8234 Jan 7:3117 Jan 8:5116 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2021-01-07/summary.log build failures: 13 http://build-failures.rhaalovely.net/aarch64/2021-01-07/devel/glog.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/devel/sqlc.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/editors/xwpe.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/emulators/vbam.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/emulators/vice.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/games/shockolate.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/print/py-pikepdf,python3.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/security/age.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/security/py-cryptodome,python3.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/sysutils/nomad.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/sysutils/telegraf.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/sysutils/terragrunt.log http://build-failures.rhaalovely.net/aarch64/2021-01-07/textproc/ruby-rdiscount,ruby26.log recurrent failures failures/devel/glog.log failures/devel/sqlc.log failures/editors/xwpe.log failures/emulators/vice.log failures/games/shockolate.log failures/security/age.log failures/sysutils/nomad.log failures/sysutils/telegraf.log failures/sysutils/terragrunt.log new failures +++ ls-failures Fri Jan 8 13:22:20 2021 +failures/emulators/vbam.log +failures/print/py-pikepdf,python3.log +failures/security/py-cryptodome,python3.log +failures/textproc/ruby-rdiscount,ruby26.log resolved failures --- ../old/aarch64/last//ls-failuresSun Jan 3 14:57:24 2021 -failures/cad/opensta.log -failures/comms/gnuradio.log -failures/converters/wv2.log -failures/editors/calligra.log -failures/sysutils/docker-cli.log -failures/www/chromium.log -failures/x11/e17/elementary.log
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/08 13:17:28 Modified files: devel/ddd : Makefile Log message: fix build on powerpc64
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2021/01/08 12:53:47 Modified files: games/stockfish: Makefile Log message: fix build on powerpc64 ok bcallah@ (MAINTAINER)
Re: NEW: sysutils/open-vm-tools
On Fri, Jan 08, 2021 at 12:58:45PM +0100, Giovanni Bechis wrote: > Can't put into any plist (no applicable prefix): > /etc/pam.d > /etc/pam.d/vmtoolsd > /etc/vmware-tools > /etc/vmware-tools/tools.conf.example > /sbin/mount.vmblock > > /etc/pam.d should be @commented, tools.conf.example should go into > $PREFIX/share/examples/vmware-tools. > For mount.vmblock I do not know if it's of any use. I looked into adjusting configure and/or fake to do the right thing but with no avail, so here's an updated port with a simple post-install that removed pam.d, move the example and removes the symlink from /sbin/ to /usr/local/bin/, therefore fixing all warnings. Updated DESCR as well: Information for inst:open-vm-tools-11.2.0 Comment: Open VMware tools for VMware guests Description: open-vm-tools is a set of services and modules that enable several features in VMware products for better management of, and seamless user interactions with, guests. Among other, open-vm-tools enables the following features in VMware products: - The ability to perform virtual machine power operations gracefully. - Periodic collection of network, disk, and memory usage information from the guest. Maintainer: Klemens Nanni WWW: https://github.com/vmware/open-vm-tools Feedback? OK? open-vm-tools.tgz Description: application/tar-gz
phonetics on OpenBSD: Praat
Is there anyone doing phonetics on OpenBSD? Is there an alternative to Praat, to be run on OpenBSD? (At this stage of phonetics studies, I imagine Praat is the one tool everyone is using.) There is a FreeBSD port, so I installed FreeBSD on a spare laptop and instralled praat on it, but couldn't get it to work (basicaly, it just crashes on anything, including opening a wav file). Is anyone working on a port of Praat? Or some other "equivalent"? What do you use? Thank you Jan PS: I am sending this to ports@ as this is probably too far from base, as oppposed to a XKB layout for an IPA kayboard and X fonts having the glyphs, which I sent to misc@. Please correct me it that's a bad choice.
Re: print/py-pikepdf,python3 build failure
On 2021/01/08 18:13, Stuart Henderson wrote:
> On 2021/01/08 15:48, Christian Weisgerber wrote:
> > In my latest amd64 package bulk build, print/py-pikepdf,python3 failed
> > to build.
> >
> > Specifically, page.o couldn't be compiled:
> >
> > src/qpdf/page.cpp:82:10: error: no matching member function for call to
> > 'def'
> > .def("externalize_inline_images",
> > ::externalizeInlineImages,
> > ~^~~
> >
> > This didn't happen in recent builds and I don't see any immediately
> > suspicious change. Here's the full log:
>
> qpdf was updated.
pikepdf 2.3.0 should work with this version of qpdf, but wants a few
other ports updating;
setuptools >= 50
setuptools_scm >= 4.1
wheel >= 0.35
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: na...@cvs.openbsd.org 2021/01/08 11:43:38 Modified files: games/dangerdeep/patches: patch-src_coastmap_h patch-src_game_h Log message: fix games/dangerdeep build with libc++ 10.0, adapted from FreeBSD ok patrick@
Re: NEW: sysutils/open-vm-tools
On Fri, Jan 08, 2021 at 06:05:04PM +, Mike Larkin wrote: > Does vmtoolsd populate all the values (IP addresses, etc) when vmt(4) is > also running? To clarify and have that info on ports@: open-vm-tools works fine with vmt(4) running; If the driver is enabled (default), one does not have even have to start vmtoolsd. With the driver disabled, using vmware-rpctool requires starting vmtoolsd such that RPC calls make it to the host and vice versa.
Re: print/py-pikepdf,python3 build failure
On 2021/01/08 15:48, Christian Weisgerber wrote:
> In my latest amd64 package bulk build, print/py-pikepdf,python3 failed
> to build.
>
> Specifically, page.o couldn't be compiled:
>
> src/qpdf/page.cpp:82:10: error: no matching member function for call to 'def'
> .def("externalize_inline_images",
> ::externalizeInlineImages,
> ~^~~
>
> This didn't happen in recent builds and I don't see any immediately
> suspicious change. Here's the full log:
qpdf was updated.
>
> >>> Building on amd64-1 under print/py-pikepdf,python3
>BDEPENDS =
> [lang/python/3.8;devel/py-pybind11,python3;devel/py-setuptools_scm_git_archive,python3;devel/py-setuptools_scm,python3;devel/py-setuptools,python3;print/qpdf]
>DIST = [print/py-pikepdf,python3:pikepdf-1.19.3.tar.gz]
>FULLPKGNAME = py3-pikepdf-1.19.3p0
>RDEPENDS =
> [textproc/py-lxml,python3;print/qpdf;devel/py-setuptools,python3;graphics/py-Pillow,python3;lang/python/3.8]
> (Junk lock obtained for amd64-1 at 1610068891.86)
> >>> Running depends in print/py-pikepdf,python3 at 1610068891.93
>last junk was in textproc/ruby-fast-stemmer,ruby26
> /usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
> py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
> qpdf-10.1.0
> was: /usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1
> py3-setuptools-44.1.1v0 py3-setuptools_scm-3.3.3p0
> py3-setuptools_scm_git_archive-1.0p2 python-3.8.7 qpdf-10.1.0
> /usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
> py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
> qpdf-10.1.0
> >>> Running show-prepare-results in print/py-pikepdf,python3 at 1610068894.52
> ===> print/py-pikepdf,python3
> ===> py3-pikepdf-1.19.3p0 depends on: py3-pybind11-* -> py3-pybind11-2.6.1
> ===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools_scm_git_archive-* ->
> py3-setuptools_scm_git_archive-1.0p2
> ===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools_scm-* ->
> py3-setuptools_scm-3.3.3p0
> ===> py3-pikepdf-1.19.3p0 depends on: python->=3.8,<3.9 -> python-3.8.7
> ===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools->=39.0.1v0 ->
> py3-setuptools-44.1.1v0
> ===> py3-pikepdf-1.19.3p0 depends on: qpdf-* -> qpdf-10.1.0
> ===> Verifying specs: c++ c++abi pthread m qpdf
> ===> found c++.6.0 c++abi.4.0 pthread.26.1 m.10.1 qpdf.8.1
> py3-pybind11-2.6.1
> py3-setuptools-44.1.1v0
> py3-setuptools_scm-3.3.3p0
> py3-setuptools_scm_git_archive-1.0p2
> python-3.8.7
> qpdf-10.1.0
> Don't run junk because nojunk in x11/qt5/qtbase
> (Junk lock released for amd64-1 at 1610068895.49)
> distfiles size=2360826
> >>> Running build in print/py-pikepdf,python3 at 1610068895.54
> ===> print/py-pikepdf,python3
> ===> Checking files for py3-pikepdf-1.19.3p0
> `/usr/ports/distfiles/pikepdf-1.19.3.tar.gz' is up to date.
> >> (SHA256) pikepdf-1.19.3.tar.gz: OK
> ===> Extracting for py3-pikepdf-1.19.3p0
> ===> Patching for py3-pikepdf-1.19.3p0
> ===> Compiler link: clang -> /usr/bin/clang
> ===> Compiler link: clang++ -> /usr/bin/clang++
> ===> Compiler link: cc -> /usr/bin/cc
> ===> Compiler link: c++ -> /usr/bin/c++
> ===> Generating configure for py3-pikepdf-1.19.3p0
> ===> Configuring for py3-pikepdf-1.19.3p0
> ===> Building for py3-pikepdf-1.19.3p0
> running egg_info
> writing src/pikepdf.egg-info/PKG-INFO
> writing dependency_links to src/pikepdf.egg-info/dependency_links.txt
> writing requirements to src/pikepdf.egg-info/requires.txt
> writing top-level names to src/pikepdf.egg-info/top_level.txt
> reading manifest file 'src/pikepdf.egg-info/SOURCES.txt'
> writing manifest file 'src/pikepdf.egg-info/SOURCES.txt'
> running build
> running build_py
> creating
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8
> creating
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/__init__.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/_cpphelpers.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/_methods.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/_version.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/codec.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/jbig2.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> copying src/pikepdf/objects.py ->
> /usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
> creating
>
Re: NEW: sysutils/open-vm-tools
On Fri, Jan 08, 2021 at 06:05:04PM +, Mike Larkin wrote: > On Fri, Jan 08, 2021 at 10:50:23AM +0100, Klemens Nanni wrote: > > This is a straight forward port that I've tested against ESXi 7.0U1: > > > > Information for inst:open-vm-tools-11.2.0 > > > > Comment: > > Open VMware tools for VMware guests > > > > Description: > > open-vm-tools is a set of services and modules that enable several > > features in > > VMware products for better management of, and seamless user > > interactions with, > > guests. It includes kernel modules for enhancing the performance of > > virtual > > machines running Linux or other VMware supported Unix like guest > > operating > > systems. > > > > Maintainer: Klemens Nanni > > > > WWW: https://github.com/vmware/open-vm-tools > > > > With vmt(4) enabled (default), it is enough to do set basic values with > > `vmware-rpctool "info-set ..."', i.e. `vmtoolsd' does not have to run. > > > > With vm(4) disabled (`boot -c ; disable vmt ; exit') is it enough to > > start the daemon in order to populate all relevant guestinfo values > > including the IP addresses which vmt(4) currently does not work for > > anymore. > > > > I turned off basically all optional functionality for now to ease > > initial porting, but that still leaves users the complete RPC client and > > various features I could not test (yet). > > > > All of the 39 patches consist of small hunks that basically add > > a preprocessor check for OpenBSD in every place where FreeBSD already > > has one - besides minor differences that were equally simple to adapt. > > > > Those hunks that merely check for OpenBSD such that it bulds can be > > upstreamed as is, the minority which change or implement behaviour > > should get more looks and tests before trying to upstream them. > > > > Select features such as the Wiper (wipe virtual disk via RPC) are > > effectively NOOPs for now in so far as their init routines always return > > false (for OpenBSD). > > > > Once this is tested and in-tree, we can test and add more features one > > by one; X and therefore clipboard support for example seem handy. > > > > > > Feedback? OK? > > > > Does vmtoolsd populate all the values (IP addresses, etc) when vmt(4) is > also running? > > -ml > NM, saw the later reply on bugs@.
Re: NEW: sysutils/open-vm-tools
On Fri, Jan 08, 2021 at 10:50:23AM +0100, Klemens Nanni wrote: > This is a straight forward port that I've tested against ESXi 7.0U1: > > Information for inst:open-vm-tools-11.2.0 > > Comment: > Open VMware tools for VMware guests > > Description: > open-vm-tools is a set of services and modules that enable several > features in > VMware products for better management of, and seamless user > interactions with, > guests. It includes kernel modules for enhancing the performance of > virtual > machines running Linux or other VMware supported Unix like guest > operating > systems. > > Maintainer: Klemens Nanni > > WWW: https://github.com/vmware/open-vm-tools > > With vmt(4) enabled (default), it is enough to do set basic values with > `vmware-rpctool "info-set ..."', i.e. `vmtoolsd' does not have to run. > > With vm(4) disabled (`boot -c ; disable vmt ; exit') is it enough to > start the daemon in order to populate all relevant guestinfo values > including the IP addresses which vmt(4) currently does not work for > anymore. > > I turned off basically all optional functionality for now to ease > initial porting, but that still leaves users the complete RPC client and > various features I could not test (yet). > > All of the 39 patches consist of small hunks that basically add > a preprocessor check for OpenBSD in every place where FreeBSD already > has one - besides minor differences that were equally simple to adapt. > > Those hunks that merely check for OpenBSD such that it bulds can be > upstreamed as is, the minority which change or implement behaviour > should get more looks and tests before trying to upstream them. > > Select features such as the Wiper (wipe virtual disk via RPC) are > effectively NOOPs for now in so far as their init routines always return > false (for OpenBSD). > > Once this is tested and in-tree, we can test and add more features one > by one; X and therefore clipboard support for example seem handy. > > > Feedback? OK? Does vmtoolsd populate all the values (IP addresses, etc) when vmt(4) is also running? -ml
Re: update arm-trusted-firmware to 2.4
On Fri, 2021-01-08 at 10:27 +1100, Jonathan Gray wrote: > On Thu, Jan 07, 2021 at 04:29:35PM -0500, Kurt Miller wrote: > > > > On Thu, 2020-12-31 at 19:24 +1100, Jonathan Gray wrote: > > > > > > https://trustedfirmware-a.readthedocs.io/en/latest/change-log.html#version-2-4 > > > > > > Tests welcome as I don't have rk3328/rk3399/sun50i_a64 hardware. > > This update appears ok on rk3328 and rk3399, however my rockpro64 > > will not boot with u-boot 2020.10: > > > > Rock64 Gen3 w/ v2020.10 u-boot and atf 2.4 works > > Rockpro64 w/2020.10 u-boot and atf 2.4 and 2.3 fails > > Rockpro64 w/2020.07 u-boot and atf 2.4 and 2.3 works > > > > With 2020.10 u-boot the rockpro64 freezes just after attempting to > > boot the kernel. Here's a diff of v2020.07 with atf 2.3 that works > > against v2020.10 with atf 2.3 that freezes: > > > > rocky$ diff -u v2020.07.boot v2020-10.boot > > --- v2020.07.boot Thu Jan 7 16:20:58 2021 > > +++ v2020-10.boot Thu Jan 7 16:10:27 2021 > > @@ -1,19 +1,18 @@ > > -U-Boot TPL 2020.07 (Jul 07 2020 - 19:02:53) > > +U-Boot TPL 2020.10 (Jan 02 2021 - 11:16:03) > > Channel 0: LPDDR4, 50MHz > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > Channel 1: LPDDR4, 50MHz > > BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB > > 256B stride > > -256B stride > > lpddr4_set_rate: change freq to 4 mhz 0, 1 > > lpddr4_set_rate: change freq to 8 mhz 1, 0 > > Trying to boot from BOOTROM > > Returning to boot ROM... > > > > -U-Boot SPL 2020.07 (Jul 07 2020 - 19:02:53 -0600) > > +U-Boot SPL 2020.10 (Jan 02 2021 - 11:16:03 -0700) > > Trying to boot from MMC1 > > NOTICE: BL31: v2.3():2.3 > > -NOTICE: BL31: Built : 18:41:43, Jul 7 2020 > > +NOTICE: BL31: Built : 10:45:12, Jan 2 2021 > > INFO:GICv3 with legacy support detected. > > INFO:ARM GICv3 driver initialized in EL3 > > INFO:plat_rockchip_pmu_init(1624): pd status 3e > > @@ -24,7 +23,7 @@ > > INFO:SPSR = 0x3c9 > > > > > > -U-Boot 2020.07 (Jul 07 2020 - 19:02:53 -0600) > > +U-Boot 2020.10 (Jan 02 2021 - 11:16:03 -0700) > > > > SoC: Rockchip rk3399 > > Reset cause: RST > > @@ -32,14 +31,29 @@ > > DRAM: 3.9 GiB > > PMIC: RK808 > > MMC: mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0 > > -Loading Environment from SPI Flash... SF: Detected gd25q128 with page size > > 256 Bytes, erase size 4 KiB, total 16 > > MiB > > -*** Warning - bad CRC, using default environment > > +Loading Environment from SPIFlash... Invalid bus 0 (err=-19) > > +*** Warning - spi_flash_probe_bus_cs() failed, using default environment > > > > In:serial > > Out: serial > > Err: serial > > Model: Pine64 RockPro64 v2.1 > > Net: eth0: ethernet@fe30 > > +starting USB... > > +Bus usb@fe38: USB EHCI 1.00 > > +Bus usb@fe3a: USB OHCI 1.0 > > +Bus usb@fe3c: USB EHCI 1.00 > > +Bus usb@fe3e: USB OHCI 1.0 > > +Bus dwc3: usb maximum-speed not found > > +Register 2000140 NbrPorts 2 > > +Starting the controller > > +USB XHCI 1.10 > > +scanning bus usb@fe38 for devices... 1 USB Device(s) found > > +scanning bus usb@fe3a for devices... 1 USB Device(s) found > > +scanning bus usb@fe3c for devices... 1 USB Device(s) found > > +scanning bus usb@fe3e for devices... 1 USB Device(s) found > > +scanning bus dwc3 for devices... 1 USB Device(s) found > > + scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > Card did not respond to voltage select! > > switch to partitions #0, OK > > @@ -56,11 +70,14 @@ > > Scanning disk sd...@fe33.blk... > > Disk sd...@fe33.blk not ready > > Found 3 disks > > +No EFI system partition > > BootOrder not defined > > EFI boot manager: Cannot load any image > > -168728 bytes read in 14 ms (11.5 MiB/s) > > +168728 bytes read in 13 ms (12.4 MiB/s) > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > +Booting /efi\boot\bootaa64.efi > > disks: sd0* > > >> OpenBSD/arm64 BOOTAA64 1.3 > > boot> > > -booting sd0a:/bsd: 8657572+1775464+561576+826224 > > [629354+109+1059720+622048]=0xf87520 > > +booting sd0a:/bsd: 8663848+1773392+563520+828336 > > [629656+109+1059720+621958]=0xf885c8 > > > > v2020.07 u-boot continues from here, v2020.10 u-boot freezes. > > > > Ideas? > Can you try build the latest U-Boot git? I think you'll have to bisect. Bisecting shows this commit is the culprit: commit 3ae64582fb8ceead4fc464cd2055eb3eaef78ccc (refs/bisect/bad) Author: Jagan Teki Date: Mon Jul 20 14:53:09 2020 +0530 rockchip: rockpro64: Enable USB3.0 Host Enable USB3.0 Host support for RockPro64 boards. Signed-off-by: Jagan Teki Reviewed-by: Kever Yang diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index 31b3ee2aa4..25cf5c781c 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -49,6 +49,8 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/08 08:53:33 Modified files: x11/fvwm2 : Makefile x11/fvwm2/pkg : PLIST Log message: x11/fvwm2: add missing @conflict @pkgpath from https://marc.info/?l=openbsd-ports=160701270301094=2 (I missed them when I committed the update before)
Re: [new] sysutils/obsdpkgup - tools for creating and using a package index
Jeremy O'Brien writes: >> On 2021/01/06 12:03, Stuart Henderson wrote: >> Looking at this it's better than I thought it would be, there are some >> problems though - >> > > Hey thanks! > >> - The version number comparison using mcuadros/go-version is wrong, >> it doesn't match packages-specs(5). >> > > I took the time to learn some perl yesterday, and holy moly my version > comparison code was *very* wrong. Thanks for taking the time to point that > out. > As a result, I went through and mirrored the perl code as closely as I could > to > ensure that it matches what OpenBSD does. > >> - There doesn't seem to be a way to validate that index.pkgup.gz is done >> against the current available package build. For this I would suggest >> recording the timestamp of the @digital-signature on the quirks package >> in the index, and verifying when the update is run. (grep out of >> "PKG_DBDIR=/var/empty PKG_PATH=$whatever pkg_info -f quirks" will do >> the trick). >> > > Added. I'm parsing the signify block in pure Go (instead of shelling out to > pkg_info) because I want to be able to use the index generation code on any > Go-supported platform. My own mirror (and from what I understand, some of > OpenBSD's own mirrors) aren't necessarily running OpenBSD. > >> Between those two it could cause problems because the user may try to >> update a too-small subset of packages. The first problem is obvious. >> The second problem, if a library is bumped after the index is generated, >> the required updates won't show up. For both if people use it and then >> run into problems it's likely the bug reports will end up with openbsd >> rather than pkgup. This makes me not want to add it to packages yet >> (adding it could easily be seen as an endorsement of using it). >> This would be less of a problem if it at least tries to detect outdated >> caches and prints a clear warning. >> > > I hope that my above two fixes rectify this situation in your mind. > >> Less important but I'd be happier if it used the signature from pkg_info >> -qS rather than its own version using grep on +CONTENTS, to guard >> against possible future changes to things that pkg_add considers when >> deciding whether to update (also I think it would make sense to include >> the whole string rather than a hash of the signature, there's no need to >> hide that), as long as the full url/filename is used pkg_add will fetch >> the file directly without grabbing the index first. i.e. >> PKG_DBDIR=/var/empty pkg_info -qS >> http://mirror/pub/OpenBSD/snapshots/packages/amd64/moo-1.5p0.tgz >> > > I would like this as well. The problem is that pkg_info -qS is slow. It takes > orders of magnitude more time to run than my current signature generation > code. > I can currently build a complete index from a remote mirror in less than ten > minutes. If I switched to using pkg_info, it would take several hours by my > math. In addition, I would like to keep genpkgup able to be run on any OS that > Go supports instead of only OpenBSD machines. I went ahead and > sorta-implemented your suggestion though by matching OpenBSD's current > signature format. No more hashes. I was torn on this before, but I actually > like your approach better because A: it's easier to debug when things go wrong > and B: it's much less CPU-intensive not having to do sha256 stuff. So again, > thank you for the recommendation. If the signature format changes in the > future, I will gladly update my code to match, or revisit the problem if > necessary. > > Again, thank you for taking the time to look at my tool! Here is an updated (0.2.2) version! obsdpkgup.tgz Description: Binary data
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 08:09:22 Modified files: mail/evolution-ews: Makefile distinfo Log message: Update to evolution-ews-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 08:09:05 Modified files: mail/evolution : Makefile distinfo Log message: Update to evolution-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 08:08:55 Modified files: databases/evolution-data-server: Makefile distinfo Log message: Update to evolution-data-server-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: sol...@cvs.openbsd.org 2021/01/08 08:01:14 Modified files: x11/fvwm2 : Makefile distinfo x11/fvwm2/patches: patch-default-config_Makefile_in x11/fvwm2/pkg : PLIST Log message: Update to fvwm2-2.6.9 >From maintainer Michael ok thfr@ @pkgpath fix from espie@ , thanks for the explanations upgrade should work from previous fvwm2 versions now
Re: UPDATE: x11/fvwm2 to 2.6.9
On Fri, Jan 08, 2021 at 01:16:09PM +0100, Michael wrote:
> Ping.
I'm fine with this update. Have been running as daily driver with it
for about a week without issues. ok thfr@. Will give another day or so
to see if any objections come up... Otherwise will update this weekend.
>
> On Fri, Jan 01, 2021 at 10:12:37PM +0100, Michael wrote:
> > Hello ports,
> >
> > after talking to upstream why fvwm 2.6.7 is still marked as the stable
> > version [0] for the 2.x branch instead of 2.6.9 I was told to always use
> > the latest 2.x release now. Therefore here is an update to 2.6.9.
> >
> > No notable changes, tested on amd64.
> >
> >
> > [0] https://github.com/fvwmorg/fvwm#releases
> >
> >
> > Index: Makefile
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/Makefile,v
> > retrieving revision 1.68
> > diff -u -p -u -p -r1.68 Makefile
> > --- Makefile13 Dec 2020 21:17:02 - 1.68
> > +++ Makefile1 Jan 2021 20:52:33 -
> > @@ -2,7 +2,7 @@
> >
> > COMMENT= multiple virtual desktop window manager
> >
> > -VERSION= 2.6.7
> > +VERSION= 2.6.9
> > DISTNAME= fvwm-${VERSION}
> > PKGNAME= fvwm2-${VERSION}
> >
> > @@ -39,7 +39,8 @@ SUBST_VARS= VERSION
> >
> > SEPARATE_BUILD=Yes
> > CONFIGURE_STYLE= gnu
> > -CONFIGURE_ARGS+= --disable-bidi \
> > +CONFIGURE_ARGS+= --enable-mandoc \
> > + --disable-bidi \
> > --disable-gtk \
> > --without-gnome \
> > --without-rplay-library \
> > Index: distinfo
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/distinfo,v
> > retrieving revision 1.15
> > diff -u -p -u -p -r1.15 distinfo
> > --- distinfo13 Dec 2020 21:17:02 - 1.15
> > +++ distinfo1 Jan 2021 20:52:33 -
> > @@ -1,2 +1,2 @@
> > -SHA256 (fvwm-2.6.7.tar.gz) = AWVNWr3N5trBMcrpvv5c9vAfn3Uk0JfDsPMW45+E73M=
> > -SIZE (fvwm-2.6.7.tar.gz) = 3934327
> > +SHA256 (fvwm-2.6.9.tar.gz) = G8ZM88zQBzAIdYFoMnqCZbgFne+bI5tFHWufqyzDka4=
> > +SIZE (fvwm-2.6.9.tar.gz) = 3942859
> > Index: patches/patch-default-config_Makefile_in
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/patches/patch-default-config_Makefile_in,v
> > retrieving revision 1.1
> > diff -u -p -u -p -r1.1 patch-default-config_Makefile_in
> > --- patches/patch-default-config_Makefile_in13 Dec 2020 21:17:02
> > - 1.1
> > +++ patches/patch-default-config_Makefile_in1 Jan 2021 20:52:33
> > -
> > @@ -1,19 +1,18 @@
> > -$OpenBSD: patch-default-config_Makefile_in,v 1.1 2020/12/13 21:17:02 sthen
> > Exp $
> > +$OpenBSD$
> >
> > Index: default-config/Makefile.in
> > --- default-config/Makefile.in.orig
> > +++ default-config/Makefile.in
> > -@@ -597,9 +597,10 @@ uninstall-am: uninstall-configDATA
> > +@@ -602,9 +602,9 @@ uninstall-am: uninstall-configDATA
> >
> > install-data-hook:
> > cp -r $(srcdir)/images $(inst_location)
> > -- ln -sf $(inst_location)/FvwmScript-DateTime $(inst_location)/..
> > -- ln -sf $(inst_location)/FvwmScript-ConfirmQuit $(inst_location)/..
> > -- ln -sf $(inst_location)/FvwmScript-ConfirmCopyConfig $(inst_location)/..
> > +- ln -sf default-config/FvwmScript-DateTime $(inst_location)/..
> > +- ln -sf default-config/FvwmScript-ConfirmQuit $(inst_location)/..
> > +- ln -sf default-config/FvwmScript-ConfirmCopyConfig $(inst_location)/..
> > + mv $(inst_location)/FvwmScript-DateTime $(inst_location)/..
> > + mv $(inst_location)/FvwmScript-ConfirmQuit $(inst_location)/..
> > + mv $(inst_location)/FvwmScript-ConfirmCopyConfig $(inst_location)/..
> > -+
> >
> > uninstall-hook:
> > rm -fr $(DESTDIR)/$(configdir)
> > Index: pkg/PLIST
> > ===
> > RCS file: /cvs/ports/x11/fvwm2/pkg/PLIST,v
> > retrieving revision 1.16
> > diff -u -p -u -p -r1.16 PLIST
> > --- pkg/PLIST 13 Dec 2020 21:17:02 - 1.16
> > +++ pkg/PLIST 1 Jan 2021 20:52:33 -
> > @@ -152,6 +152,8 @@ share/fvwm/perllib/General/FileSystem.pm
> > share/fvwm/perllib/General/Parse.pm
> > share/locale/ar/LC_MESSAGES/FvwmScript.mo
> > share/locale/ar/LC_MESSAGES/fvwm.mo
> > +share/locale/da/LC_MESSAGES/FvwmScript.mo
> > +share/locale/da/LC_MESSAGES/fvwm.mo
> > share/locale/de/LC_MESSAGES/FvwmScript.mo
> > share/locale/de/LC_MESSAGES/fvwm.mo
> > share/locale/es/LC_MESSAGES/FvwmScript.mo
> >
>
print/py-pikepdf,python3 build failure
In my latest amd64 package bulk build, print/py-pikepdf,python3 failed
to build.
Specifically, page.o couldn't be compiled:
src/qpdf/page.cpp:82:10: error: no matching member function for call to 'def'
.def("externalize_inline_images",
::externalizeInlineImages,
~^~~
This didn't happen in recent builds and I don't see any immediately
suspicious change. Here's the full log:
>>> Building on amd64-1 under print/py-pikepdf,python3
BDEPENDS =
[lang/python/3.8;devel/py-pybind11,python3;devel/py-setuptools_scm_git_archive,python3;devel/py-setuptools_scm,python3;devel/py-setuptools,python3;print/qpdf]
DIST = [print/py-pikepdf,python3:pikepdf-1.19.3.tar.gz]
FULLPKGNAME = py3-pikepdf-1.19.3p0
RDEPENDS =
[textproc/py-lxml,python3;print/qpdf;devel/py-setuptools,python3;graphics/py-Pillow,python3;lang/python/3.8]
(Junk lock obtained for amd64-1 at 1610068891.86)
>>> Running depends in print/py-pikepdf,python3 at 1610068891.93
last junk was in textproc/ruby-fast-stemmer,ruby26
/usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
qpdf-10.1.0
was: /usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
qpdf-10.1.0
/usr/sbin/pkg_add -aI -Drepair py3-pybind11-2.6.1 py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0 py3-setuptools_scm_git_archive-1.0p2 python-3.8.7
qpdf-10.1.0
>>> Running show-prepare-results in print/py-pikepdf,python3 at 1610068894.52
===> print/py-pikepdf,python3
===> py3-pikepdf-1.19.3p0 depends on: py3-pybind11-* -> py3-pybind11-2.6.1
===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools_scm_git_archive-* ->
py3-setuptools_scm_git_archive-1.0p2
===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools_scm-* ->
py3-setuptools_scm-3.3.3p0
===> py3-pikepdf-1.19.3p0 depends on: python->=3.8,<3.9 -> python-3.8.7
===> py3-pikepdf-1.19.3p0 depends on: py3-setuptools->=39.0.1v0 ->
py3-setuptools-44.1.1v0
===> py3-pikepdf-1.19.3p0 depends on: qpdf-* -> qpdf-10.1.0
===> Verifying specs: c++ c++abi pthread m qpdf
===> found c++.6.0 c++abi.4.0 pthread.26.1 m.10.1 qpdf.8.1
py3-pybind11-2.6.1
py3-setuptools-44.1.1v0
py3-setuptools_scm-3.3.3p0
py3-setuptools_scm_git_archive-1.0p2
python-3.8.7
qpdf-10.1.0
Don't run junk because nojunk in x11/qt5/qtbase
(Junk lock released for amd64-1 at 1610068895.49)
distfiles size=2360826
>>> Running build in print/py-pikepdf,python3 at 1610068895.54
===> print/py-pikepdf,python3
===> Checking files for py3-pikepdf-1.19.3p0
`/usr/ports/distfiles/pikepdf-1.19.3.tar.gz' is up to date.
>> (SHA256) pikepdf-1.19.3.tar.gz: OK
===> Extracting for py3-pikepdf-1.19.3p0
===> Patching for py3-pikepdf-1.19.3p0
===> Compiler link: clang -> /usr/bin/clang
===> Compiler link: clang++ -> /usr/bin/clang++
===> Compiler link: cc -> /usr/bin/cc
===> Compiler link: c++ -> /usr/bin/c++
===> Generating configure for py3-pikepdf-1.19.3p0
===> Configuring for py3-pikepdf-1.19.3p0
===> Building for py3-pikepdf-1.19.3p0
running egg_info
writing src/pikepdf.egg-info/PKG-INFO
writing dependency_links to src/pikepdf.egg-info/dependency_links.txt
writing requirements to src/pikepdf.egg-info/requires.txt
writing top-level names to src/pikepdf.egg-info/top_level.txt
reading manifest file 'src/pikepdf.egg-info/SOURCES.txt'
writing manifest file 'src/pikepdf.egg-info/SOURCES.txt'
running build
running build_py
creating
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8
creating
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/__init__.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/_cpphelpers.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/_methods.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/_version.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/codec.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/jbig2.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
copying src/pikepdf/objects.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf
creating
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf/models
copying src/pikepdf/models/__init__.py ->
/usr/obj/ports/py-pikepdf-1.19.3-python3/pikepdf-1.19.3/lib.openbsd-6.8-amd64-3.8/pikepdf/models
copying src/pikepdf/models/encryption.py ->
Re: NEW: sysutils/open-vm-tools
On 1/8/21 10:50 AM, Klemens Nanni wrote: > This is a straight forward port that I've tested against ESXi 7.0U1: > > Information for inst:open-vm-tools-11.2.0 > > Comment: > Open VMware tools for VMware guests > > Description: > open-vm-tools is a set of services and modules that enable several > features in > VMware products for better management of, and seamless user > interactions with, > guests. It includes kernel modules for enhancing the performance of > virtual > machines running Linux or other VMware supported Unix like guest > operating > systems. > > Maintainer: Klemens Nanni > > WWW: https://github.com/vmware/open-vm-tools > > With vmt(4) enabled (default), it is enough to do set basic values with > `vmware-rpctool "info-set ..."', i.e. `vmtoolsd' does not have to run. > > With vm(4) disabled (`boot -c ; disable vmt ; exit') is it enough to > start the daemon in order to populate all relevant guestinfo values > including the IP addresses which vmt(4) currently does not work for > anymore. > > I turned off basically all optional functionality for now to ease > initial porting, but that still leaves users the complete RPC client and > various features I could not test (yet). > > All of the 39 patches consist of small hunks that basically add > a preprocessor check for OpenBSD in every place where FreeBSD already > has one - besides minor differences that were equally simple to adapt. > > Those hunks that merely check for OpenBSD such that it bulds can be > upstreamed as is, the minority which change or implement behaviour > should get more looks and tests before trying to upstream them. > > Select features such as the Wiper (wipe virtual disk via RPC) are > effectively NOOPs for now in so far as their init routines always return > false (for OpenBSD). > > Once this is tested and in-tree, we can test and add more features one > by one; X and therefore clipboard support for example seem handy. > > > Feedback? OK? > Can't put into any plist (no applicable prefix): /etc/pam.d /etc/pam.d/vmtoolsd /etc/vmware-tools /etc/vmware-tools/tools.conf.example /sbin/mount.vmblock /etc/pam.d should be @commented, tools.conf.example should go into $PREFIX/share/examples/vmware-tools. For mount.vmblock I do not know if it's of any use. Giovanni
Re: Dependency on specific PHP version
Thanks Stuart! That was very helpful. I must have missed that part of the pkg_add man page ;-) -- Mike Fischer > Am 08.01.2021 um 12:08 schrieb Stuart Henderson : > > "Instead I have to specify the full version, e.g. pkg_add php-7.4.14" - > that's not needed, you can use "pkg_add php%7.4". This applies to other > packages where multiple versions exist too but the exact version format > varies - some use e.g. "stable" instead of a number - see pkg_info -z to > check from installed packages.
Re: Dependency on specific PHP version
Hi Paul! Thanks! Yes, I guess I’ll live with the extra packages. -- Mike Fischer > Am 08.01.2021 um 11:00 schrieb Paul de Weerd : > > Short version: it's complicated. I decided to let php-7.3 getting > installed not bother me :)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2021/01/08 06:32:57 Modified files: comms/amtterm : Makefile comms/amtterm/patches: patch-parseconfig_c Added files: comms/amtterm/patches: patch-GNUmakefile patch-amtterm_c patch-amtterm_man patch-auth_c patch-auth_h patch-gamt_c patch-redir_c patch-redir_h patch-ssl_c patch-ssl_h Log message: comms/amtterm: add SSL/auth code from https://github.com/Openwsman/wsmancli/issues/10#issuecomment-751253133 ok/similar diff from stsp@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 06:16:43 Modified files: x11/gnome/control-center: Makefile distinfo Log message: Update to gnome-control-center-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 05:50:51 Modified files: x11/gnome/initial-setup: Makefile distinfo Log message: Update to gnome-initial-setup-3.38.3.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 05:46:26 Modified files: sysutils/awscli: Makefile distinfo Log message: Update to awscli-1.18.211.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 05:46:11 Modified files: net/py-boto3 : Makefile distinfo Log message: Update to py3-boto3-1.16.51.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 05:46:01 Modified files: net/py-botocore: Makefile distinfo Log message: Update to py3-botocore-1.19.51.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 05:37:37 Modified files: print/cups-filters: Makefile distinfo Log message: Update to cups-filters-1.28.7.
Re: UPDATE: x11/fvwm2 to 2.6.9
Ping.
On Fri, Jan 01, 2021 at 10:12:37PM +0100, Michael wrote:
> Hello ports,
>
> after talking to upstream why fvwm 2.6.7 is still marked as the stable
> version [0] for the 2.x branch instead of 2.6.9 I was told to always use
> the latest 2.x release now. Therefore here is an update to 2.6.9.
>
> No notable changes, tested on amd64.
>
>
> [0] https://github.com/fvwmorg/fvwm#releases
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/fvwm2/Makefile,v
> retrieving revision 1.68
> diff -u -p -u -p -r1.68 Makefile
> --- Makefile 13 Dec 2020 21:17:02 - 1.68
> +++ Makefile 1 Jan 2021 20:52:33 -
> @@ -2,7 +2,7 @@
>
> COMMENT= multiple virtual desktop window manager
>
> -VERSION= 2.6.7
> +VERSION= 2.6.9
> DISTNAME=fvwm-${VERSION}
> PKGNAME= fvwm2-${VERSION}
>
> @@ -39,7 +39,8 @@ SUBST_VARS= VERSION
>
> SEPARATE_BUILD= Yes
> CONFIGURE_STYLE= gnu
> -CONFIGURE_ARGS+= --disable-bidi \
> +CONFIGURE_ARGS+= --enable-mandoc \
> + --disable-bidi \
> --disable-gtk \
> --without-gnome \
> --without-rplay-library \
> Index: distinfo
> ===
> RCS file: /cvs/ports/x11/fvwm2/distinfo,v
> retrieving revision 1.15
> diff -u -p -u -p -r1.15 distinfo
> --- distinfo 13 Dec 2020 21:17:02 - 1.15
> +++ distinfo 1 Jan 2021 20:52:33 -
> @@ -1,2 +1,2 @@
> -SHA256 (fvwm-2.6.7.tar.gz) = AWVNWr3N5trBMcrpvv5c9vAfn3Uk0JfDsPMW45+E73M=
> -SIZE (fvwm-2.6.7.tar.gz) = 3934327
> +SHA256 (fvwm-2.6.9.tar.gz) = G8ZM88zQBzAIdYFoMnqCZbgFne+bI5tFHWufqyzDka4=
> +SIZE (fvwm-2.6.9.tar.gz) = 3942859
> Index: patches/patch-default-config_Makefile_in
> ===
> RCS file: /cvs/ports/x11/fvwm2/patches/patch-default-config_Makefile_in,v
> retrieving revision 1.1
> diff -u -p -u -p -r1.1 patch-default-config_Makefile_in
> --- patches/patch-default-config_Makefile_in 13 Dec 2020 21:17:02 -
> 1.1
> +++ patches/patch-default-config_Makefile_in 1 Jan 2021 20:52:33 -
> @@ -1,19 +1,18 @@
> -$OpenBSD: patch-default-config_Makefile_in,v 1.1 2020/12/13 21:17:02 sthen
> Exp $
> +$OpenBSD$
>
> Index: default-config/Makefile.in
> --- default-config/Makefile.in.orig
> +++ default-config/Makefile.in
> -@@ -597,9 +597,10 @@ uninstall-am: uninstall-configDATA
> +@@ -602,9 +602,9 @@ uninstall-am: uninstall-configDATA
>
> install-data-hook:
> cp -r $(srcdir)/images $(inst_location)
> --ln -sf $(inst_location)/FvwmScript-DateTime $(inst_location)/..
> --ln -sf $(inst_location)/FvwmScript-ConfirmQuit $(inst_location)/..
> --ln -sf $(inst_location)/FvwmScript-ConfirmCopyConfig $(inst_location)/..
> +-ln -sf default-config/FvwmScript-DateTime $(inst_location)/..
> +-ln -sf default-config/FvwmScript-ConfirmQuit $(inst_location)/..
> +-ln -sf default-config/FvwmScript-ConfirmCopyConfig $(inst_location)/..
> +mv $(inst_location)/FvwmScript-DateTime $(inst_location)/..
> +mv $(inst_location)/FvwmScript-ConfirmQuit $(inst_location)/..
> +mv $(inst_location)/FvwmScript-ConfirmCopyConfig $(inst_location)/..
> -+
>
> uninstall-hook:
> rm -fr $(DESTDIR)/$(configdir)
> Index: pkg/PLIST
> ===
> RCS file: /cvs/ports/x11/fvwm2/pkg/PLIST,v
> retrieving revision 1.16
> diff -u -p -u -p -r1.16 PLIST
> --- pkg/PLIST 13 Dec 2020 21:17:02 - 1.16
> +++ pkg/PLIST 1 Jan 2021 20:52:33 -
> @@ -152,6 +152,8 @@ share/fvwm/perllib/General/FileSystem.pm
> share/fvwm/perllib/General/Parse.pm
> share/locale/ar/LC_MESSAGES/FvwmScript.mo
> share/locale/ar/LC_MESSAGES/fvwm.mo
> +share/locale/da/LC_MESSAGES/FvwmScript.mo
> +share/locale/da/LC_MESSAGES/fvwm.mo
> share/locale/de/LC_MESSAGES/FvwmScript.mo
> share/locale/de/LC_MESSAGES/fvwm.mo
> share/locale/es/LC_MESSAGES/FvwmScript.mo
>
Re: update editors/TeXmacs 1.99.14
Nam Nguyen writes:
> Nam Nguyen writes:
>
>> This is an update for editors/TeXmacs-1.99.14, released November 5,
>> 2020.
>
> Here is a diff for 1.99.15, which was just released on November 13,
> 2020.
Here is a diff for 1.99.18. This fresh diff additionally:
- removes the patch for the TeXmacs interface to R
- updates README with R instructions
This removed patch actually started an R session (like typing `r' at the
command line). It fails to start the actual interface, which allows you
to do things like call v() to embed graphics. Instead of carrying a
patch, I updated README instructions to describe changing permissions of
${TRUEPREFIX}/lib/R/library/ to give a group running TeXmacs write
permissions. This allows the R package to be built at run-time and it
works as described in the tutorial, including embedded graphics with
v().
OK?
>
>>
>> Changelog: https://texmacs.org/tmweb/about/changes.en.html
>>
>> Ports changes:
>> - reverts back to DISTNAME and PKGNAME as in revision 1.15 now that
>> distfile extracts to -src again.
>> - notes in README that octave plugin requires gnuplot.
>
> This fresh diff additionally:
> - compileall.py for a portcheck warning
>
> I used net/konversation as an example of compileall.py.
>
> It still complains about texmacs_reedit.py, but it is not worth a patch
> for the its strange combination of tabs and spaces.
>
> "Python module without compiled version, consider using ${MODPY_BIN}
> ${MODPY_LIBDIR}/compileall.py:
> share/TeXmacs/misc/inkscape_extension/texmacs_reedit.py"
>
>>
>> I tested with all plugins and it works. Feedback and tests are welcome.
>>
>
> It still works in brief testing of all plugins.
Index: Makefile
===
RCS file: /cvs/ports/editors/TeXmacs/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile1 Aug 2020 11:00:31 - 1.18
+++ Makefile8 Jan 2021 11:26:21 -
@@ -2,8 +2,8 @@
COMMENT= wysiwyw (what you see is what you want) editing platform
-DISTNAME= TeXmacs-1.99.13
-EXTRACT_SUFX= -src.tar.gz
+DISTNAME= TeXmacs-1.99.18-src
+PKGNAME= ${DISTNAME:S/-src//}
CATEGORIES=editors print x11
HOMEPAGE= https://texmacs.org/
@@ -42,5 +42,9 @@ CXXFLAGS+=-Wno-deprecated-register
post-extract:
rm -f ${WRKDIST}/plugins/mathematica/bin/realpath.py
+
+post-install:
+ ${MODPY_BIN} ${MODPY_LIBDIR}/compileall.py \
+ ${PREFIX}/share/TeXmacs/plugins/tmpy
.include
Index: distinfo
===
RCS file: /cvs/ports/editors/TeXmacs/distinfo,v
retrieving revision 1.4
diff -u -p -r1.4 distinfo
--- distinfo1 Aug 2020 11:00:31 - 1.4
+++ distinfo8 Jan 2021 11:26:21 -
@@ -1,2 +1,2 @@
-SHA256 (TeXmacs-1.99.13-src.tar.gz) =
Aq0cS47QqmFQHelxRjANeJlgXCXagnYRykpAq7wHqbQ=
-SIZE (TeXmacs-1.99.13-src.tar.gz) = 37181886
+SHA256 (TeXmacs-1.99.18-src.tar.gz) =
sYgjPUiTFlgVLk+sNdZb1Ew+oZ/ocZCkCoIAwR93g0Y=
+SIZE (TeXmacs-1.99.18-src.tar.gz) = 37178348
Index: patches/patch-CMakeLists_txt
===
RCS file: /cvs/ports/editors/TeXmacs/patches/patch-CMakeLists_txt,v
retrieving revision 1.3
diff -u -p -r1.3 patch-CMakeLists_txt
--- patches/patch-CMakeLists_txt1 Aug 2020 11:00:31 - 1.3
+++ patches/patch-CMakeLists_txt8 Jan 2021 11:26:21 -
@@ -3,7 +3,7 @@ $OpenBSD: patch-CMakeLists_txt,v 1.3 202
Index: CMakeLists.txt
--- CMakeLists.txt.orig
+++ CMakeLists.txt
-@@ -586,7 +586,7 @@ if (TEXMACS_GUI MATCHES "Qt.*")
+@@ -603,7 +603,7 @@ if (TEXMACS_GUI MATCHES "Qt.*")
set (TeXmacs_All_SRCS ${TeXmacs_All_SRCS} ${TeXmacs_Qt_SRCS}
${TeXmacs_Qt_Moc_HDRS})
set (TeXmacs_Include_Dirs ${TeXmacs_Include_Dirs} ${QT_INCLUDES})
Index: patches/patch-plugins_r_src_tm_r_c
===
RCS file: patches/patch-plugins_r_src_tm_r_c
diff -N patches/patch-plugins_r_src_tm_r_c
--- patches/patch-plugins_r_src_tm_r_c 1 Aug 2020 11:00:31 - 1.2
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,29 +0,0 @@
-$OpenBSD: patch-plugins_r_src_tm_r_c,v 1.2 2020/08/01 11:00:31 sthen Exp $
-
-do not build TeXmacs-R interface at runtime. attempting to do so
-prevents interface from starting.
-
-Index: plugins/r/src/tm_r.c
plugins/r/src/tm_r.c.orig
-+++ plugins/r/src/tm_r.c
-@@ -103,7 +103,7 @@ jmp_buf error_return_env ;
-
- int N_data_begins = 0 ;
-
--char *DEFAULT_TEXMACS_SEND =
"source(paste(Sys.getenv(\"TEXMACS_PATH\"),\"/plugins/r/texmacs.r\",sep=\"\"))\n";
-+char *DEFAULT_TEXMACS_SEND = "";
-
-
- // Add one more DATA_BEGIN, i.e. open bracket.
-@@ -852,11 +852,6 @@ int main(int argc, char *argv[])
- snprintf( TEXMACS_HOME_PATH, 4096, "%s/.TeXmacs",HOME) ;
- }
-
-- /* Lazy installing the TeXmacs package */
-- TEXMACS_LIB = (char *)malloc(4096);
--
comms/amtterm: add support for ssl and digest auth
This adds a patch which makes amtterm work against a machine running
Intel ME version 12.
This should really be upstream code, but it looks like upstream is inactive.
And without this patch amtterm is entirely useless against current machines.
So I think in this case it is worth patching it ourselves. I hope that if
upstream becomes active again a future update will make these patches
unnecessary.
ok?
diff 333077bd2bf861f2cff72b5e1058978bec71e982 /usr/ports
blob - 3e7ac289fa3294a3e6319c96ac84d0e7d9f6a73f
file + comms/amtterm/Makefile
--- comms/amtterm/Makefile
+++ comms/amtterm/Makefile
@@ -4,6 +4,7 @@ COMMENT-term= cli client for Intel AMT serial-over-lan
COMMENT-main= client and tools for Intel AMT serial-over-lan
V= 1.6
+REVISION= 0
DISTNAME= amtterm-$V
PKGNAME-main= amtterm-$V
PKGNAME-term= amtterm-cli-$V
@@ -16,10 +17,10 @@ HOMEPAGE= https://www.kraxel.org/blog/linux/amtterm/
# GPLv2+
PERMIT_PACKAGE=Yes
-WANTLIB-term += c
-WANTLIB += atk-1.0 c cairo cairo-gobject gdk-3 gdk_pixbuf-2.0
+WANTLIB-term += c crypto ssl
+WANTLIB += atk-1.0 c cairo cairo-gobject crypto gdk-3 gdk_pixbuf-2.0
WANTLIB += gio-2.0 glib-2.0 gobject-2.0 gtk-3 harfbuzz intl pango-1.0
-WANTLIB += pangocairo-1.0 vte-2.91
+WANTLIB += pangocairo-1.0 ssl vte-2.91
MASTER_SITES= https://www.kraxel.org/releases/amtterm/
blob - /dev/null
file + comms/amtterm/patches/patch-GNUmakefile
--- /dev/null
+++ comms/amtterm/patches/patch-GNUmakefile
@@ -0,0 +1,42 @@
+$OpenBSD$
+Add support for SSL and digest auth required by newer versions of Intel ME.
+via https://github.com/Openwsman/wsmancli/issues/10#issuecomment-751253133
+Index: GNUmakefile
+--- GNUmakefile.orig
GNUmakefile
+@@ -1,11 +1,24 @@
+ # config
++USE_OPENSSL=1
++#USE_GNUTLS=1
+ srcdir= .
+ VPATH = $(srcdir)
+ -include Make.config
+ include $(srcdir)/mk/Variables.mk
+
++ifdef USE_OPENSSL
++SSL_DEFS=-DUSE_OPENSSL
++pkglst+=openssl
++endif
++
++ifdef USE_GNUTLS
++SSL_DEFS=-DUSE_GNUTLS
++pkglst+=gnutls
++endif
++
+ CFLAGS+= -Wall -Wno-pointer-sign
+ CFLAGS+= -DVERSION='"$(VERSION)"'
++CFLAGS += $(SSL_DEFS)
+
+ TARGETS := amtterm
+ DESKTOP := $(wildcard *.desktop)
+@@ -60,8 +73,8 @@ distclean: clean
+
+ #
+
+-amtterm: amtterm.o redir.o tcp.o
+-gamt: gamt.o redir.o tcp.o parseconfig.o
++amtterm: amtterm.o redir.o tcp.o auth.o ssl.o
++gamt: gamt.o redir.o tcp.o parseconfig.o auth.o ssl.o
+
+ #
+
blob - /dev/null
file + comms/amtterm/patches/patch-amtterm_c
--- /dev/null
+++ comms/amtterm/patches/patch-amtterm_c
@@ -0,0 +1,49 @@
+$OpenBSD$
+Add support for SSL and digest auth required by newer versions of Intel ME.
+via https://github.com/Openwsman/wsmancli/issues/10#issuecomment-751253133
+Index: amtterm.c
+--- amtterm.c.orig
amtterm.c
+@@ -179,10 +179,18 @@ static void usage(FILE *fp)
+ " -hprint this text\n"
+ " -vverbose (default)\n"
+ " -qquiet\n"
++" -Luse legacy authentication\n"
++#if defined(USE_OPENSSL) || defined(USE_GNUTLS)
++" -C cacert enable SSL and use PEM cacert file\n"
++#endif
+ " -u user username (default: admin)\n"
+ " -p pass password (default: $AMT_PASSWORD)\n"
+ "\n"
++#if defined(USE_OPENSSL) || defined(USE_GNUTLS)
++"By default port 16994 (SSL: 16995) is used.\n"
++#else
+ "By default port 16994 is used.\n"
++#endif
+ "If no password is given " APPNAME " will ask for one.\n"
+ "\n"
+ "-- \n"
+@@ -209,7 +217,7 @@ int main(int argc, char *argv[])
+ snprintf(r.pass, sizeof(r.pass), "%s", h);
+
+ for (;;) {
+-if (-1 == (c = getopt(argc, argv, "hvqu:p:")))
++if (-1 == (c = getopt(argc, argv, "hvqu:p:LC:")))
+ break;
+ switch (c) {
+ case 'v':
+@@ -225,6 +233,14 @@ int main(int argc, char *argv[])
+ snprintf(r.pass, sizeof(r.pass), "%s", optarg);
+ memset(optarg,'*',strlen(optarg)); /* rm passwd from ps list */
+ break;
++ case 'L':
++ r.legacy = 1;
++ break;
++#if defined(USE_OPENSSL) || defined(USE_GNUTLS)
++ case 'C':
++ r.cacert = optarg;
++ break;
++#endif
+
+ case 'h':
+ usage(stdout);
blob - /dev/null
file + comms/amtterm/patches/patch-auth_c
--- /dev/null
+++ comms/amtterm/patches/patch-auth_c
@@ -0,0 +1,833 @@
+$OpenBSD$
+Add support for SSL and digest auth required by newer versions of Intel ME.
+via https://github.com/Openwsman/wsmancli/issues/10#issuecomment-751253133
+Index: auth.c
+--- auth.c.orig
auth.c
+@@ -0,0 +1,826 @@
++/*
++ * Authentication helper functions.
++ *
++ * Copyright (C) 2014 Andreas Steinmetz
++ *
++ * This program is free
Re: [Update] net/wget : Update to 1.21
wen heping writes:
> Hi,
>
> Here is a patch for net/wget to update to 1.21, it build
> well and run well on amd64-6.8 system.
>
>
> wen
Thank you for this update. It looks good to me. I can commit this if I
can get an OK.
solene@: Should it be backported to -stable?
${WRKSRC}/ChangeLog reports fixed memory leak, use of uninitialized
stack mem and stack memory leak found by Coverity, and other memory
leaks and a read buffer overflow.
`make test' passes, skipping some. I tested by downloading an openbsd
ISO. I tested against the pending devel/pcre2 update, which I will
commit soon.
Details on `make test'
==
Here are some notes on `make test' explaining why they are skipped.
1. SKIP: Test-stdouterr.px
This test tries writing to /dev/full and expects an exit status of 3,
indicating a File I/O error (per wget(1)). /dev/full does not exist on
OpenBSD.
unless(-e "/dev/full") {
exit 77; # skip
}
2. SKIP: Test-no_proxy-env
This is the only new unit test that appears to be skipped. Other tests
are skipped as in the previous release, 1.20.3.
Test-no_proxy-env.log:1:SKIP Test-no_proxy-env.py (exit status: 77)
This test, along with other tests, are skipped for the same
reason. gethostbyname fails and returns an error. This is to be expected
because _pbuild doesn't have network access. I confirmed this with a
minimal python3 reproducer that works when run as a user but fails when
using doas -u _pbuild.
import socket
try:
ip = socket.gethostbyname("www.working2.localhost")
except socket.gaierror as _:
print("error");
print("works " + ip);
The other tests that fail for the same reason:
SKIP: Test-https-selfsigned.px
SKIP: Test-https-weboftrust.px
SKIP: Test-https-tlsv1x.px
SKIP: Test-https-clientcert.px
SKIP: Test-https-tlsv1.px
SKIP: Test-https-pfs.px
SKIP: Test-https-crl.px
SKIP: Test-https-badcerts.px
Re: Dependency on specific PHP version
"Instead I have to specify the full version, e.g. pkg_add php-7.4.14" - that's not needed, you can use "pkg_add php%7.4". This applies to other packages where multiple versions exist too but the exact version format varies - some use e.g. "stable" instead of a number - see pkg_info -z to check from installed packages. A request to maintainers of PHP-based ports: I intend to switch the default MODPHP_VERSION to 7.4 but this may break some software. If you're aware that your ports require 7.3 please would you specifically set MODPHP_VERSION=7.3 for them. -- Sent from a phone, apologies for poor formatting. On 8 January 2021 10:00:24 Paul de Weerd wrote: Hi Mike, As I was looking into exactly this not too long ago, let me share the answer I got from Stuart: Ports can allow alternative versions with a default version (e.g. "RUN_DEPENDS = php->=7.3,<7.5:lang/php/7.3") but it doesn't have a way to say "php-7.3+php-pspell-7.3+php-zip-7.3 OR php-7.4+php-pspell-7.4+php-zip-7.4" without allowing a broken mixture (php-7.3+php-pspell-7.4+php-zip-7.4). Unless ports infrastructure/package tools are changed the only viable option is to pick some version or other and set that, Short version: it's complicated. I decided to let php-7.3 getting installed not bother me :) Cheers, Paul On Fri, Jan 08, 2021 at 10:15:25AM +0100, Mike Fischer wrote: | Hi! | | I am posting this question to the list with CC to the relevant maintainers because it involves a number of packages. | | On a few of OpenBSD 6.8 amd64 instances using stable we are using php-7.4.x with apache-httpd and with the OpenBSD httpd as well as on the command line. Everything is kept up to date regularly. | | We are also using the following packages: | dokuwiki-2020.07.29 | pear-utils-1.10.9 | phpMyAdmin-4.9.5 | wp-cli-2.4.0 | | Each of these has a dependency on php-7.3.x which means the older version of PHP is also installed even though it is not used. | | # pkg_info -R php-7.3.26 | Information for inst:php-7.3.26 | | Required by: | dokuwiki-2020.07.29 | pear-utils-1.10.9 | php-gd-7.3.26 | php-mysqli-7.3.26 | phpMyAdmin-4.9.5 | wp-cli-2.4.0 | | | # | | A similar issue exists for php-gd-7.3.26: | # pkg_info -R php-gd-7.3.26 | Information for inst:php-gd-7.3.26 | | Required by: | dokuwiki-2020.07.29 | phpMyAdmin-4.9.5 | | | # | | And for php-mysqli-7.3.26: | # pkg_info -R php-mysqli-7.3.26 | Information for inst:php-mysqli-7.3.26 | | Required by: | phpMyAdmin-4.9.5 | | | # | | Using these packages with php-7.4.x seems to work fine. But pulling in the older PHP version just to satisfy the dependency seems somewhat wasteful. I’d love to be able get rid of the unnecessary php-7.3.x packages to save space and to save time during updates. | | Is there a way to make the dependencies more general so they will accept the php-7.4.x versions to satisfy the requirement? | | Maybe there is a way to specify a minimum required version in the packages? | | | @Stuart: | Possibly the basic issue is with the way the PHP packages are built. PHP generally makes major changes that might affect compatibility with a x.x version bump and reserves the x.x.x bumps to bug fixes. So should the PHP packages use a flavor mechanism to differentiate between x.x versions? | | A related issue I found is that with PHP, unlike other packages, I can’t just pkg_add php or pkg_add php-x.x to install the latest version. Instead I have to specify the full version, e.g. pkg_add php-7.4.14. This is somewhat cumbersome when wanting to just install the latest version because I would need to do a pkg_info -Q php first to figure out which exact version to get. Is this intentional or is there a better way to do a generic install? | | | Note: I am a complete noob when it comes to the internals of the OpenBSD packaging system. So Im asking from the perspective of an admin using the system. | | | Thanks! | -- | Mike Fischer | | -- [<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Dependency on specific PHP version
Hi Mike, As I was looking into exactly this not too long ago, let me share the answer I got from Stuart: > Ports can allow alternative versions with a default version > (e.g. "RUN_DEPENDS = php->=7.3,<7.5:lang/php/7.3") but it doesn't > have a way to say "php-7.3+php-pspell-7.3+php-zip-7.3 OR > php-7.4+php-pspell-7.4+php-zip-7.4" without allowing a broken > mixture (php-7.3+php-pspell-7.4+php-zip-7.4). > > Unless ports infrastructure/package tools are changed the only > viable option is to pick some version or other and set that, Short version: it's complicated. I decided to let php-7.3 getting installed not bother me :) Cheers, Paul On Fri, Jan 08, 2021 at 10:15:25AM +0100, Mike Fischer wrote: | Hi! | | I am posting this question to the list with CC to the relevant maintainers because it involves a number of packages. | | On a few of OpenBSD 6.8 amd64 instances using stable we are using php-7.4.x with apache-httpd and with the OpenBSD httpd as well as on the command line. Everything is kept up to date regularly. | | We are also using the following packages: | dokuwiki-2020.07.29 | pear-utils-1.10.9 | phpMyAdmin-4.9.5 | wp-cli-2.4.0 | | Each of these has a dependency on php-7.3.x which means the older version of PHP is also installed even though it is not used. | | # pkg_info -R php-7.3.26 | Information for inst:php-7.3.26 | | Required by: | dokuwiki-2020.07.29 | pear-utils-1.10.9 | php-gd-7.3.26 | php-mysqli-7.3.26 | phpMyAdmin-4.9.5 | wp-cli-2.4.0 | | | # | | A similar issue exists for php-gd-7.3.26: | # pkg_info -R php-gd-7.3.26 | Information for inst:php-gd-7.3.26 | | Required by: | dokuwiki-2020.07.29 | phpMyAdmin-4.9.5 | | | # | | And for php-mysqli-7.3.26: | # pkg_info -R php-mysqli-7.3.26 | Information for inst:php-mysqli-7.3.26 | | Required by: | phpMyAdmin-4.9.5 | | | # | | Using these packages with php-7.4.x seems to work fine. But pulling in the older PHP version just to satisfy the dependency seems somewhat wasteful. I’d love to be able get rid of the unnecessary php-7.3.x packages to save space and to save time during updates. | | Is there a way to make the dependencies more general so they will accept the php-7.4.x versions to satisfy the requirement? | | Maybe there is a way to specify a minimum required version in the packages? | | | @Stuart: | Possibly the basic issue is with the way the PHP packages are built. PHP generally makes major changes that might affect compatibility with a x.x version bump and reserves the x.x.x bumps to bug fixes. So should the PHP packages use a flavor mechanism to differentiate between x.x versions? | | A related issue I found is that with PHP, unlike other packages, I can’t just pkg_add php or pkg_add php-x.x to install the latest version. Instead I have to specify the full version, e.g. pkg_add php-7.4.14. This is somewhat cumbersome when wanting to just install the latest version because I would need to do a pkg_info -Q php first to figure out which exact version to get. Is this intentional or is there a better way to do a generic install? | | | Note: I am a complete noob when it comes to the internals of the OpenBSD packaging system. So Im asking from the perspective of an admin using the system. | | | Thanks! | -- | Mike Fischer | | -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
NEW: sysutils/open-vm-tools
This is a straight forward port that I've tested against ESXi 7.0U1: Information for inst:open-vm-tools-11.2.0 Comment: Open VMware tools for VMware guests Description: open-vm-tools is a set of services and modules that enable several features in VMware products for better management of, and seamless user interactions with, guests. It includes kernel modules for enhancing the performance of virtual machines running Linux or other VMware supported Unix like guest operating systems. Maintainer: Klemens Nanni WWW: https://github.com/vmware/open-vm-tools With vmt(4) enabled (default), it is enough to do set basic values with `vmware-rpctool "info-set ..."', i.e. `vmtoolsd' does not have to run. With vm(4) disabled (`boot -c ; disable vmt ; exit') is it enough to start the daemon in order to populate all relevant guestinfo values including the IP addresses which vmt(4) currently does not work for anymore. I turned off basically all optional functionality for now to ease initial porting, but that still leaves users the complete RPC client and various features I could not test (yet). All of the 39 patches consist of small hunks that basically add a preprocessor check for OpenBSD in every place where FreeBSD already has one - besides minor differences that were equally simple to adapt. Those hunks that merely check for OpenBSD such that it bulds can be upstreamed as is, the minority which change or implement behaviour should get more looks and tests before trying to upstream them. Select features such as the Wiper (wipe virtual disk via RPC) are effectively NOOPs for now in so far as their init routines always return false (for OpenBSD). Once this is tested and in-tree, we can test and add more features one by one; X and therefore clipboard support for example seem handy. Feedback? OK? open-vm-tools.tgz Description: application/tar-gz
Dependency on specific PHP version
Hi! I am posting this question to the list with CC to the relevant maintainers because it involves a number of packages. On a few of OpenBSD 6.8 amd64 instances using stable we are using php-7.4.x with apache-httpd and with the OpenBSD httpd as well as on the command line. Everything is kept up to date regularly. We are also using the following packages: dokuwiki-2020.07.29 pear-utils-1.10.9 phpMyAdmin-4.9.5 wp-cli-2.4.0 Each of these has a dependency on php-7.3.x which means the older version of PHP is also installed even though it is not used. # pkg_info -R php-7.3.26 Information for inst:php-7.3.26 Required by: dokuwiki-2020.07.29 pear-utils-1.10.9 php-gd-7.3.26 php-mysqli-7.3.26 phpMyAdmin-4.9.5 wp-cli-2.4.0 # A similar issue exists for php-gd-7.3.26: # pkg_info -R php-gd-7.3.26 Information for inst:php-gd-7.3.26 Required by: dokuwiki-2020.07.29 phpMyAdmin-4.9.5 # And for php-mysqli-7.3.26: # pkg_info -R php-mysqli-7.3.26 Information for inst:php-mysqli-7.3.26 Required by: phpMyAdmin-4.9.5 # Using these packages with php-7.4.x seems to work fine. But pulling in the older PHP version just to satisfy the dependency seems somewhat wasteful. I’d love to be able get rid of the unnecessary php-7.3.x packages to save space and to save time during updates. Is there a way to make the dependencies more general so they will accept the php-7.4.x versions to satisfy the requirement? Maybe there is a way to specify a minimum required version in the packages? @Stuart: Possibly the basic issue is with the way the PHP packages are built. PHP generally makes major changes that might affect compatibility with a x.x version bump and reserves the x.x.x bumps to bug fixes. So should the PHP packages use a flavor mechanism to differentiate between x.x versions? A related issue I found is that with PHP, unlike other packages, I can’t just pkg_add php or pkg_add php-x.x to install the latest version. Instead I have to specify the full version, e.g. pkg_add php-7.4.14. This is somewhat cumbersome when wanting to just install the latest version because I would need to do a pkg_info -Q php first to figure out which exact version to get. Is this intentional or is there a better way to do a generic install? Note: I am a complete noob when it comes to the internals of the OpenBSD packaging system. So Im asking from the perspective of an admin using the system. Thanks! -- Mike Fischer
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2021/01/08 02:06:39 Modified files: meta/gnome : Makefile meta/gnome/pkg : README-main Log message: Instruct to create a "gdm" login class and expand it from xenodm to prevent running out of file descriptors.
