Re: fixed-slab variant for iosevka font
On 2023-08-06 17:23 -04, Morgan Aldridge wrote:
> On Sun, Aug 6, 2023 at 4:46 PM Edd Barrett wrote:
>
>> On Sun, Aug 06, 2023 at 09:40:18PM +0100, Edd Barrett wrote:
>> > Hi,
>> >
>> > On Sun, Aug 06, 2023 at 05:02:59PM +0200, Florian Obser wrote:
>> > > I recently discovered the iosevka font and I like the Fixed Slab
>> variant
>> > > best.
>> >
>> > First, can I check that "fixed slab" is correct and not just "slab".
>>
>> Arch has a "slab" package, but not a "fixed slab" package:
>> https://archlinux.org/packages/?q=ttc-iosevka
>>
>> Same for fedora:
>> https://copr.fedorainfracloud.org/coprs/peterwu/iosevka/packages/
>>
>> Same for FreeBSD:
>> https://cgit.freebsd.org/ports/tree/x11-fonts/iosevka/Makefile
>>
>> So is slab and fixed-slab the same thing, or?
>>
No, as Morgan explained:
>
> I haven't tested yet, but according to the Iosevka website <
> https://typeof.net/Iosevka/>:
>
> "Terminal emulators have stricter compatibility requirements for fonts.
> Therefore, Iosevka and Iosevka Slab all contain two specialized families,
> Term and Fixed, targeting terminal users.
>
> In these families, the symbols will be narrower to follow terminals’
> ideology of column count. In the Fixed families, the ligation will be
> disabled to ensure better compatibility in certain environments."
>
> So, it might be preferable for this to install both the "term" & "fixed"
> families of Iosevka Slab. Doing so would probably necessitate renaming the
> package to "iosevka-slab" though.
I have no need for ligatures, that's why I went with fixed.
I'm not sure what FreeBSD packages precisely but I suspect it's the
non-fixed / non-term variant.
https://typeof.net/Iosevka/ has a nice overview table about 10% down on
the page.
Upstream currently has 458 assets listed, it's all over the place.
The way the port is currently setup these would all be different ports:
iosevka-slab
iosevka-fixed
iosevka-fixed-slab
iosevka-term
iosevka-term-fixed
I did one port, because that's the one I need.
>
> Morgan
Fixed comment and description:
commit a2587e7df8a07f2a307c74d83c9dcf2c2623b25e
Author: Florian Obser
Date: Sun Aug 6 16:56:36 2023 +0200
update to 26.0.1
diff --git Makefile.inc Makefile.inc
index e02a6f941a9..3358c967f4e 100644
--- Makefile.inc
+++ Makefile.inc
@@ -1,4 +1,4 @@
-V =19.0.1
+V =26.0.1
CATEGORIES = fonts x11
HOMEPAGE = https://github.com/be5invis/Iosevka
MAINTAINER = Edd Barrett
diff --git default/distinfo default/distinfo
index ce9fb8e38ca..48224555407 100644
--- default/distinfo
+++ default/distinfo
@@ -1,2 +1,2 @@
-SHA256 (ttc-iosevka-19.0.1.zip) = dQ2QR33PZ/PBZ7Eu/7YApnCPA+LmJMw4Z00MyeIb5kA=
-SIZE (ttc-iosevka-19.0.1.zip) = 75570917
+SHA256 (ttc-iosevka-26.0.1.zip) = 3h7aeMHkbsTRbbarNkcHT9Ej/o9E9s8XPCb2rdFRImc=
+SIZE (ttc-iosevka-26.0.1.zip) = 97568862
commit ea86fdbae98f91347d0409f377ccf060cd88c597
Author: Florian Obser
Date: Sun Aug 6 16:59:14 2023 +0200
fixed slab variant
diff --git Makefile Makefile
index ac190583d83..b4550370196 100644
--- Makefile
+++ Makefile
@@ -14,5 +14,6 @@
SUBDIR =
SUBDIR += default
+SUBDIR += fixed-slab
.include
diff --git fixed-slab/Makefile fixed-slab/Makefile
new file mode 100644
index 000..b61982a38b9
--- /dev/null
+++ fixed-slab/Makefile
@@ -0,0 +1,9 @@
+COMMENT = slender typeface for code (fixed slab variant)
+PKGNAME = iosevka-fixed-slab-${V}
+DISTFILES =ttc-sgr-iosevka-fixed-slab-${V}${EXTRACT_SUFX}
+
+do-install:
+ ${INSTALL_DATA_DIR} ${FONTDIR}
+ ${INSTALL_DATA} ${WRKDIST}/*.ttc ${FONTDIR}
+
+.include
diff --git fixed-slab/distinfo fixed-slab/distinfo
new file mode 100644
index 000..405a598b40a
--- /dev/null
+++ fixed-slab/distinfo
@@ -0,0 +1,2 @@
+SHA256 (ttc-sgr-iosevka-fixed-slab-26.0.1.zip) =
cqEnSt1I3xyacxTjZUCEmo8M7KFw7MudTY7D7D5UnQM=
+SIZE (ttc-sgr-iosevka-fixed-slab-26.0.1.zip) = 93695504
diff --git fixed-slab/pkg/DESCR fixed-slab/pkg/DESCR
new file mode 100644
index 000..38c61002954
--- /dev/null
+++ fixed-slab/pkg/DESCR
@@ -0,0 +1,3 @@
+Coders' typeface, built from code.
+
+This package is for the fixed slab variant.
diff --git fixed-slab/pkg/PLIST fixed-slab/pkg/PLIST
new file mode 100644
index 000..d0073b0c22f
--- /dev/null
+++ fixed-slab/pkg/PLIST
@@ -0,0 +1,11 @@
+share/fonts/
+@fontdir share/fonts/iosevka/
+share/fonts/iosevka/sgr-iosevka-fixed-slab-bold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-extrabold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-extralight.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-heavy.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-light.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-medium.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-regular.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-semibold.ttc
+share/fonts/iosevka/sgr-iosevka-fixed-slab-thin.ttc
--
In my defence, I have been left unsupervised.
devel/p5-Moose: Update to 2.2206
Hi, ports@: Here is a simple patch for devel/p5-Moose to update to 2.2206. It build and run well on amd64-current system, pass all tests. Update changes is the improvement of TEST, so I did not check the ports depends on it. Regards, wenIndex: Makefile === RCS file: /cvs/ports/devel/p5-Moose/Makefile,v retrieving revision 1.34 diff -u -p -r1.34 Makefile --- Makefile19 Feb 2023 07:47:31 - 1.34 +++ Makefile8 Aug 2023 06:19:57 - @@ -1,7 +1,7 @@ COMMENT = postmodern object system for Perl 5 MODULES = cpan -DISTNAME = Moose-2.2203 +DISTNAME = Moose-2.2206 CATEGORIES = devel # Perl Index: distinfo === RCS file: /cvs/ports/devel/p5-Moose/distinfo,v retrieving revision 1.17 diff -u -p -r1.17 distinfo --- distinfo19 Feb 2023 07:47:31 - 1.17 +++ distinfo8 Aug 2023 06:19:57 - @@ -1,2 +1,2 @@ -SHA256 (Moose-2.2203.tar.gz) = +ngUrPQHP6Q0wUjUA8u/inti9zrTlvqIafMDbW4yQac= -SIZE (Moose-2.2203.tar.gz) = 905536 +SHA256 (Moose-2.2206.tar.gz) = Z5csTivDn72jhRgXevDme7vrVIVi5OxLdZoaelg+UFs= +SIZE (Moose-2.2206.tar.gz) = 906783
aarch64 bulk build report
bulk build on arm64.ports.openbsd.org started on Fri Aug 4 22:27:56 MDT 2023 finished at Tue Aug 8 00:20:12 MDT 2023 lasted 3D01h52m done with kern.version=OpenBSD 7.3-current (GENERIC.MP) #2220: Fri Aug 4 16:45:34 MDT 2023 built packages:11646 Aug 4:1391 Aug 5:2381 Aug 6:2296 Aug 7:3821 Aug 8:1756 critical path missing pkgs: http://build-failures.rhaalovely.net/aarch64/2023-08-04/summary.log build failures: 4 http://build-failures.rhaalovely.net/aarch64/2023-08-04/emulators/mame.log recurrent failures new failures +++ ls-failures Tue Aug 8 00:20:24 2023 +failures/emulators/mame.log resolved failures --- ../old/aarch64/last//ls-failuresThu Aug 3 14:53:51 2023 -failures/games/lwjgl3.log
回复: [Update]devel/p5-Moo: Update to 2.005005
ping ... 发件人: wen heping 发送时间: 2023年7月10日 15:59 收件人: ports@openbsd.org 主题: [Update]devel/p5-Moo: Update to 2.005005 Hi, ports@: Here is a patch for devel/p5-Moo: i) Update to 2.005005 ii) Update RUN_DEPENDS and TEST_DEPENDS iii) Remove devel/p5-strictures from TEST_DEPENDS since it is RUN_DEPENDS It build well and pass all tests on amd64-current system. Many ports (30+) depends on p5-Moo, I tested some of them, no problem meet. Cheers ! wen
Re: [RFC] Split sysutils/u-boot
Just had a quick read through on my phone, I'll try to have another look
tomorrow, generally looks good.
For each of the new PLIST files you need to add "@pkgpath
sysutils/u-boot,old_flavour_name" alongside any existing @pkgpath so that
pkg_add -u accepts it as an update despite the different path.
I'd suggest splitting the build/install steps to the arch Makefiles (either
move completely, or keep the common parts in Makefile.inc by using
do-build/do-install in one file, post-build/post-install for the other) but
probably simpler to do that as a separate step.
--
Sent from a phone, apologies for poor formatting.
On 7 August 2023 22:11:43 Mark Kettenis wrote:
This splits sysutils/u-boot into three different ports instead of
using flavours. The motivation behind this is that the current port
is very hard to update without breaking shit. By turning this into
separate ports we can update them individually. My idea is that we
split this up by SoC family/generation where appropriate. Then we can
test a few boards with that particular SoC and be reasonably sure that
things still work on the other boards. For example I will probably
create a new "sun50i" port with proper support for suspend/resume
(this needs a newer version of u-boot as well as some additional
firmware). Support for older SoCs will probably not be updated at
all.
Since I am fairly clueless regarding ports, please let me know if this
makes sense. The new packages should have the same name as the old
flavours. Does that mean upgrading them will work?
I created a git diff for this since I didn't want to pollute the CVS
repo with new directories yet. This has the benefit that it clearly
shows that the patch files have simply been moved.
Thoughts?
From 3dcb8724513098a710972a3b3f47c7601756cd76 Mon Sep 17 00:00:00 2001
From: Mark Kettenis
Date: Mon, 7 Aug 2023 22:56:47 +0200
Subject: [PATCH] Split u-boot port
---
sysutils/u-boot/Makefile | 248 +---
sysutils/u-boot/Makefile.inc | 143 ++
sysutils/u-boot/aarch64/Makefile | 39 +++
sysutils/u-boot/{ => aarch64}/distinfo| 0
.../patches/patch-arch_arm_dts_Makefile | 0
.../patch-arch_arm_dts_rk3328-nanopi-r2s_dts | 0
.../patch-arch_arm_dts_rk3328-rock64_dts | 0
.../patch-arch_arm_dts_rk3399-nanopi4_dtsi| 0
...patch-arch_arm_dts_rk3399-pinebook-pro_dts | 0
.../patch-arch_arm_dts_rk3399-rock-pi-4_dtsi | 0
.../patch-arch_arm_dts_rk3399-rock960_dts | 0
.../patch-arch_arm_dts_rk3399-rockpro64_dtsi | 0
.../patch-arch_arm_dts_rk3399-u-boot_dtsi | 0
...tch-arch_arm_dts_rk3399pro-rock-pi-n10_dts | 0
...rch_arm_dts_sun50i-h6-pine-h64-model-b_dts | 0
.../patch-configs_firefly-rk3399_defconfig| 0
.../patch-configs_nanopc-t4-rk3399_defconfig | 0
...patch-configs_nanopi-neo4-rk3399_defconfig | 0
.../patch-configs_nanopi-r2s-rk3328_defconfig | 0
.../patch-configs_nanopi-r4s-rk3399_defconfig | 0
.../patch-configs_pine_h64-model-b_defconfig | 0
...atch-configs_pinebook-pro-rk3399_defconfig | 0
.../patch-configs_rock-pi-4-rk3399_defconfig | 0
...ch-configs_rock-pi-n10-rk3399pro_defconfig | 0
.../patch-configs_rock64-rk3328_defconfig | 0
.../patch-configs_rock960-rk3399_defconfig| 0
.../patch-configs_rockpro64-rk3399_defconfig | 0
.../patches/patch-drivers_pci_pcie_brcmstb_c | 0
sysutils/u-boot/aarch64/pkg/DESCR | 8 +
sysutils/u-boot/aarch64/pkg/PLIST | 193 +
sysutils/u-boot/arm/Makefile | 64 +
sysutils/u-boot/arm/distinfo | 2 +
.../patches/patch-configs_rpi_2_defconfig | 0
.../patches/patch-configs_rpi_3_32b_defconfig | 0
.../patches/patch-drivers_pci_pcie_brcmstb_c | 42 +++
sysutils/u-boot/arm/pkg/DESCR | 8 +
sysutils/u-boot/arm/pkg/PLIST | 264 ++
.../patches/patch-configs_rpi_3_defconfig | 28 --
sysutils/u-boot/riscv64/Makefile | 11 +
sysutils/u-boot/riscv64/distinfo | 2 +
.../patches/patch-arch_riscv_Makefile | 0
sysutils/u-boot/riscv64/pkg/DESCR | 8 +
sysutils/u-boot/riscv64/pkg/PLIST | 10 +
43 files changed, 799 insertions(+), 271 deletions(-)
create mode 100644 sysutils/u-boot/Makefile.inc
create mode 100644 sysutils/u-boot/aarch64/Makefile
rename sysutils/u-boot/{ => aarch64}/distinfo (100%)
rename sysutils/u-boot/{ => aarch64}/patches/patch-arch_arm_dts_Makefile (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3328-nanopi-r2s_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3328-rock64_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-nanopi4_dtsi (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-pinebook-pro_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-rock-pi-
[RFC] Split sysutils/u-boot
This splits sysutils/u-boot into three different ports instead of
using flavours. The motivation behind this is that the current port
is very hard to update without breaking shit. By turning this into
separate ports we can update them individually. My idea is that we
split this up by SoC family/generation where appropriate. Then we can
test a few boards with that particular SoC and be reasonably sure that
things still work on the other boards. For example I will probably
create a new "sun50i" port with proper support for suspend/resume
(this needs a newer version of u-boot as well as some additional
firmware). Support for older SoCs will probably not be updated at
all.
Since I am fairly clueless regarding ports, please let me know if this
makes sense. The new packages should have the same name as the old
flavours. Does that mean upgrading them will work?
I created a git diff for this since I didn't want to pollute the CVS
repo with new directories yet. This has the benefit that it clearly
shows that the patch files have simply been moved.
Thoughts?
>From 3dcb8724513098a710972a3b3f47c7601756cd76 Mon Sep 17 00:00:00 2001
From: Mark Kettenis
Date: Mon, 7 Aug 2023 22:56:47 +0200
Subject: [PATCH] Split u-boot port
---
sysutils/u-boot/Makefile | 248 +---
sysutils/u-boot/Makefile.inc | 143 ++
sysutils/u-boot/aarch64/Makefile | 39 +++
sysutils/u-boot/{ => aarch64}/distinfo| 0
.../patches/patch-arch_arm_dts_Makefile | 0
.../patch-arch_arm_dts_rk3328-nanopi-r2s_dts | 0
.../patch-arch_arm_dts_rk3328-rock64_dts | 0
.../patch-arch_arm_dts_rk3399-nanopi4_dtsi| 0
...patch-arch_arm_dts_rk3399-pinebook-pro_dts | 0
.../patch-arch_arm_dts_rk3399-rock-pi-4_dtsi | 0
.../patch-arch_arm_dts_rk3399-rock960_dts | 0
.../patch-arch_arm_dts_rk3399-rockpro64_dtsi | 0
.../patch-arch_arm_dts_rk3399-u-boot_dtsi | 0
...tch-arch_arm_dts_rk3399pro-rock-pi-n10_dts | 0
...rch_arm_dts_sun50i-h6-pine-h64-model-b_dts | 0
.../patch-configs_firefly-rk3399_defconfig| 0
.../patch-configs_nanopc-t4-rk3399_defconfig | 0
...patch-configs_nanopi-neo4-rk3399_defconfig | 0
.../patch-configs_nanopi-r2s-rk3328_defconfig | 0
.../patch-configs_nanopi-r4s-rk3399_defconfig | 0
.../patch-configs_pine_h64-model-b_defconfig | 0
...atch-configs_pinebook-pro-rk3399_defconfig | 0
.../patch-configs_rock-pi-4-rk3399_defconfig | 0
...ch-configs_rock-pi-n10-rk3399pro_defconfig | 0
.../patch-configs_rock64-rk3328_defconfig | 0
.../patch-configs_rock960-rk3399_defconfig| 0
.../patch-configs_rockpro64-rk3399_defconfig | 0
.../patches/patch-drivers_pci_pcie_brcmstb_c | 0
sysutils/u-boot/aarch64/pkg/DESCR | 8 +
sysutils/u-boot/aarch64/pkg/PLIST | 193 +
sysutils/u-boot/arm/Makefile | 64 +
sysutils/u-boot/arm/distinfo | 2 +
.../patches/patch-configs_rpi_2_defconfig | 0
.../patches/patch-configs_rpi_3_32b_defconfig | 0
.../patches/patch-drivers_pci_pcie_brcmstb_c | 42 +++
sysutils/u-boot/arm/pkg/DESCR | 8 +
sysutils/u-boot/arm/pkg/PLIST | 264 ++
.../patches/patch-configs_rpi_3_defconfig | 28 --
sysutils/u-boot/riscv64/Makefile | 11 +
sysutils/u-boot/riscv64/distinfo | 2 +
.../patches/patch-arch_riscv_Makefile | 0
sysutils/u-boot/riscv64/pkg/DESCR | 8 +
sysutils/u-boot/riscv64/pkg/PLIST | 10 +
43 files changed, 799 insertions(+), 271 deletions(-)
create mode 100644 sysutils/u-boot/Makefile.inc
create mode 100644 sysutils/u-boot/aarch64/Makefile
rename sysutils/u-boot/{ => aarch64}/distinfo (100%)
rename sysutils/u-boot/{ => aarch64}/patches/patch-arch_arm_dts_Makefile (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3328-nanopi-r2s_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3328-rock64_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-nanopi4_dtsi (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-pinebook-pro_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-rock-pi-4_dtsi (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-rock960_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-rockpro64_dtsi (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399-u-boot_dtsi (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_rk3399pro-rock-pi-n10_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-arch_arm_dts_sun50i-h6-pine-h64-model-b_dts (100%)
rename sysutils/u-boot/{ =>
aarch64}/patches/patch-configs_firefly-rk3399_defconfig (100%)
rename sysutils/u-boot/{ =>
aarch64}/pa
Re: Update: audio/ffmpeg-normalize
On Sun, Jul 30, 2023 at 11:13:13AM +0100, Laurence Tratt wrote:
And ping on the ffmpeg-normalize update too.
Laurie
> This (slightly involved) mail updates ffmpeg-normalize. To do that we
> also have to:
>
> 1. Update multimedia/py-ffmpeg-progress-yield (ffmpeg-normalize now
> has minimum version requirements).
> 2. Add devel/py-colorlog so that `make test` works with ffmpeg-normalize.
>
> After this, everything seems to work as expected!
>
>
> Laurie
> diff --git multimedia/py-ffmpeg-progress-yield/Makefile
> multimedia/py-ffmpeg-progress-yield/Makefile
> index 3c9bea809fb..3488ce03d20 100644
> --- multimedia/py-ffmpeg-progress-yield/Makefile
> +++ multimedia/py-ffmpeg-progress-yield/Makefile
> @@ -1,6 +1,6 @@
> COMMENT =Python FFmpeg progress wrapper
>
> -MODPY_EGG_VERSION = 0.7.1
> +MODPY_EGG_VERSION = 0.7.8
>
> DISTNAME = ffmpeg-progress-yield-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> diff --git multimedia/py-ffmpeg-progress-yield/distinfo
> multimedia/py-ffmpeg-progress-yield/distinfo
> index 3ebbbcddd47..af157a70487 100644
> --- multimedia/py-ffmpeg-progress-yield/distinfo
> +++ multimedia/py-ffmpeg-progress-yield/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (ffmpeg-progress-yield-0.7.1.tar.gz) =
> wK33h+Qg737hSv+2HF4hvfBDDsJpI+7mGbRgUQvrZb0=
> -SIZE (ffmpeg-progress-yield-0.7.1.tar.gz) = 44371
> +SHA256 (ffmpeg-progress-yield-0.7.8.tar.gz) =
> muauX4Mq58ew9lGPE0H+bu4bqPydNADLocujjy6qRh4=
> +SIZE (ffmpeg-progress-yield-0.7.8.tar.gz) = 45543
> diff --git audio/ffmpeg-normalize/Makefile audio/ffmpeg-normalize/Makefile
> index 038d35c593b..841aee872f7 100644
> --- audio/ffmpeg-normalize/Makefile
> +++ audio/ffmpeg-normalize/Makefile
> @@ -1,7 +1,6 @@
> COMMENT =audio normalization
>
> -MODPY_EGG_VERSION = 1.23.0
> -REVISION = 1
> +MODPY_EGG_VERSION = 1.27.6
> DISTNAME = ffmpeg-normalize-${MODPY_EGG_VERSION}
>
> CATEGORIES = audio multimedia
> @@ -18,8 +17,9 @@ MODPY_PYBUILD = setuptools
> MODPY_PYTEST_ARGS = test/test.py
>
> RUN_DEPENDS =devel/py-colorama${MODPY_FLAVOR} \
> - multimedia/py-ffmpeg-progress-yield${MODPY_FLAVOR} \
> +
> multimedia/py-ffmpeg-progress-yield${MODPY_FLAVOR}>=0.7.4 \
> devel/py-tqdm${MODPY_FLAVOR} \
> graphics/ffmpeg
> +TEST_DEPENDS = devel/py-colorlog
>
> .include
> diff --git audio/ffmpeg-normalize/distinfo audio/ffmpeg-normalize/distinfo
> index 33ff534a35a..7558e34c17f 100644
> --- audio/ffmpeg-normalize/distinfo
> +++ audio/ffmpeg-normalize/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (ffmpeg-normalize-1.23.0.tar.gz) =
> DSBh3m7gGm5fWH47YWALlyhi4x6A2RcVrpuDDpXolSI=
> -SIZE (ffmpeg-normalize-1.23.0.tar.gz) = 1966134
> +SHA256 (ffmpeg-normalize-1.27.6.tar.gz) =
> Nbbg9PuASycWLqqWhyGwickZeMpgiaqTA2KtXdVEKTg=
> +SIZE (ffmpeg-normalize-1.27.6.tar.gz) = 1981355
py-colorlog.tgz
Description: application/tar-gz
Re: [Update] devel/py-tqdm
On Fri, Jul 28, 2023 at 03:20:37PM +0100, Laurence Tratt wrote:
Ping on this update (needed for ffmpeg-normalize).
Laurie
> The patch below updates devel/py-tqdm to the latest version. Lightly
> tested with ffmpeg-normalize.
>
>
> Laurie
>
>
> diff --git devel/py-tqdm/Makefile devel/py-tqdm/Makefile
> index 8de57c1bc08..17226fa83b8 100644
> --- devel/py-tqdm/Makefile
> +++ devel/py-tqdm/Makefile
> @@ -1,9 +1,8 @@
> COMMENT =progress bar for Python
>
> -MODPY_EGG_VERSION = 4.52.0
> +MODPY_EGG_VERSION = 4.65.0
> DISTNAME = tqdm-${MODPY_EGG_VERSION}
> PKGNAME =py-${DISTNAME}
> -REVISION = 2
>
> CATEGORIES = devel
>
> @@ -17,7 +16,7 @@ PERMIT_PACKAGE =Yes
> MODULES =lang/python
>
> MODPY_PI = Yes
> -MODPY_PYBUILD = setuptools
> +MODPY_PYBUILD = setuptools_scm
>
> FLAVORS =python3
> FLAVOR = python3
> diff --git devel/py-tqdm/distinfo devel/py-tqdm/distinfo
> index 99dca5c2bde..a27b592e2e4 100644
> --- devel/py-tqdm/distinfo
> +++ devel/py-tqdm/distinfo
> @@ -1,2 +1,2 @@
> -SHA256 (tqdm-4.52.0.tar.gz) = GNamFa7dCeyEVtlSRInaszCvS9XCoUp26z+aDhRHGv4=
> -SIZE (tqdm-4.52.0.tar.gz) = 180391
> +SHA256 (tqdm-4.65.0.tar.gz) = GHH7aKhrj7O1nKTN09zMvH5tYT7u0x9MMyUxl3uJvrU=
> +SIZE (tqdm-4.65.0.tar.gz) = 167542
> diff --git devel/py-tqdm/pkg/PLIST devel/py-tqdm/pkg/PLIST
> index 2ff96b30cb0..5e85c09ea7c 100644
> --- devel/py-tqdm/pkg/PLIST
> +++ devel/py-tqdm/pkg/PLIST
> @@ -14,6 +14,8 @@
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}__init__.${MODPY_P
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_dist_ver.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
> +lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_dist_ver.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_main.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_main.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_monitor.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
> @@ -28,8 +30,6 @@
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_tqdm_pandas.${MOD
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_tqdm_pandas.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_utils.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_utils.${MODPY_PYC_MAGIC_TAG}pyc
> -lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
> -lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}_version.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}asyncio.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}asyncio.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}auto.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
> @@ -38,16 +38,25 @@
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}autonotebook.${MOD
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}autonotebook.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}cli.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}cli.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}dask.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
> +lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}dask.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}gui.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}gui.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}keras.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}keras.${MODPY_PYC_MAGIC_TAG}pyc
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}notebook.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
>
> lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}notebook.${MODPY_PYC_MAGIC_TAG}pyc
> +lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}rich.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
> +lib/python${MODPY_VERSION}/site-packages/tqdm/${MODPY_PYCACHE}rich.${MODPY_PYC_MA
[maintainer update] textproc/hexyl 13.1
Updates textproc/hexyl to 13.1 https://github.com/sharkdp/hexyl/releases/tag/v0.13.1 It's a rather small fix, bundled with a lot of updated dependencies. Build and runs fine on amd64. ok?Index: Makefile === RCS file: /cvs/ports/textproc/hexyl/Makefile,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile --- Makefile 1 Jul 2023 15:40:47 - 1.1.1.1 +++ Makefile 7 Aug 2023 20:34:20 - @@ -2,7 +2,7 @@ COMMENT = simple console hex viewer GH_ACCOUNT = sharkdp GH_PROJECT = hexyl -GH_TAGNAME = v0.13.0 +GH_TAGNAME = v0.13.1 MAINTAINER = Volker Schlecht Index: crates.inc === RCS file: /cvs/ports/textproc/hexyl/crates.inc,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 crates.inc --- crates.inc 1 Jul 2023 15:40:47 - 1.1.1.1 +++ crates.inc 7 Aug 2023 20:34:20 - @@ -1,70 +1,73 @@ -MODCARGO_CRATES += aho-corasick 0.7.20 # Unlicense OR MIT -MODCARGO_CRATES += anyhow 1.0.66 # MIT OR Apache-2.0 -MODCARGO_CRATES += assert_cmd 2.0.7 # MIT OR Apache-2.0 -MODCARGO_CRATES += atty 0.2.14 # MIT +MODCARGO_CRATES += aho-corasick 1.0.2 # Unlicense OR MIT +MODCARGO_CRATES += anstream 0.3.2 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle 1.0.1 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle-parse 0.2.1 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle-query 1.0.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += anstyle-wincon 1.0.1 # MIT OR Apache-2.0 +MODCARGO_CRATES += anyhow 1.0.72 # MIT OR Apache-2.0 +MODCARGO_CRATES += assert_cmd 2.0.12 # MIT OR Apache-2.0 MODCARGO_CRATES += autocfg 1.1.0 # Apache-2.0 OR MIT MODCARGO_CRATES += bitflags 1.3.2 # MIT/Apache-2.0 -MODCARGO_CRATES += bstr 1.0.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += cc 1.0.77 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap 4.0.29 # MIT OR Apache-2.0 -MODCARGO_CRATES += clap_lex 0.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += const_format 0.2.30 # Zlib -MODCARGO_CRATES += const_format_proc_macros 0.2.29 # Zlib -MODCARGO_CRATES += ctor 0.1.26 # Apache-2.0 OR MIT +MODCARGO_CRATES += bitflags 2.3.3 # MIT OR Apache-2.0 +MODCARGO_CRATES += bstr 1.6.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += cc 1.0.79 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap 4.3.19 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap_builder 4.3.19 # MIT OR Apache-2.0 +MODCARGO_CRATES += clap_lex 0.5.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += colorchoice 1.0.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += const_format 0.2.31 # Zlib +MODCARGO_CRATES += const_format_proc_macros 0.2.31 # Zlib MODCARGO_CRATES += diff 0.1.13 # MIT OR Apache-2.0 MODCARGO_CRATES += difflib 0.4.0 # MIT MODCARGO_CRATES += doc-comment 0.3.3 # MIT -MODCARGO_CRATES += either 1.8.0 # MIT/Apache-2.0 -MODCARGO_CRATES += errno 0.2.8 # MIT/Apache-2.0 +MODCARGO_CRATES += either 1.9.0 # MIT OR Apache-2.0 +MODCARGO_CRATES += errno 0.3.1 # MIT OR Apache-2.0 MODCARGO_CRATES += errno-dragonfly 0.1.2 # MIT MODCARGO_CRATES += float-cmp 0.9.0 # MIT -MODCARGO_CRATES += hermit-abi 0.1.19 # MIT/Apache-2.0 -MODCARGO_CRATES += hermit-abi 0.2.6 # MIT/Apache-2.0 -MODCARGO_CRATES += io-lifetimes 1.0.3 # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT -MODCARGO_CRATES += is-terminal 0.4.1 # MIT +MODCARGO_CRATES += hermit-abi 0.3.2 # MIT OR Apache-2.0 +MODCARGO_CRATES += io-lifetimes 1.0.11 # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT +MODCARGO_CRATES += is-terminal 0.4.9 # MIT MODCARGO_CRATES += is_ci 1.1.1 # ISC MODCARGO_CRATES += itertools 0.10.5 # MIT/Apache-2.0 -MODCARGO_CRATES += libc 0.2.138 # MIT OR Apache-2.0 -MODCARGO_CRATES += linux-raw-sys 0.1.3 # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT +MODCARGO_CRATES += libc 0.2.147 # MIT OR Apache-2.0 +MODCARGO_CRATES += linux-raw-sys 0.3.8 # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT +MODCARGO_CRATES += linux-raw-sys 0.4.3 # Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT MODCARGO_CRATES += memchr 2.5.0 # Unlicense/MIT MODCARGO_CRATES += normalize-line-endings 0.3.0 # Apache-2.0 -MODCARGO_CRATES += num-traits 0.2.15 # MIT OR Apache-2.0 -MODCARGO_CRATES += once_cell 1.16.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += os_str_bytes 6.4.1 # MIT OR Apache-2.0 -MODCARGO_CRATES += output_vt100 0.1.3 # MIT +MODCARGO_CRATES += num-traits 0.2.16 # MIT OR Apache-2.0 +MODCARGO_CRATES += once_cell 1.18.0 # MIT OR Apache-2.0 MODCARGO_CRATES += owo-colors 3.5.0 # MIT -MODCARGO_CRATES += predicates 2.1.4 # MIT OR Apache-2.0 -MODCARGO_CRATES += predicates-core 1.0.5 # MIT OR Apache-2.0 -MODCARGO_CRATES += predicates-tree 1.0.7 # MIT OR Apache-2.0 -MODCARGO_CRATES += pretty_assertions 1.3.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += proc-macro2 1.0.47 # MIT OR Apache-2.0 -MODCARGO_CRATES += quote 1.0.21 # MIT OR Apache-2.0 -MODCARGO_CRATES += regex 1.7.0 # MIT OR Apache-2.0 -MODCARGO_CRATES += regex-automata 0.1.10 # Unlicense/MIT -MODCARGO_CRATES += regex-syntax 0.6.28 # MIT OR Apache-2.0 -MODCARGO_CRATES += rustix 0.36.5 # Apache-2.0 WITH LLV
Re: NEW: misc/libcpucycles
It's only been like 3 days..please have more patience
On 2023/08/07 20:01, Miguel Landaeta wrote:
> Ping?
>
> On Fri, Aug 4, 2023 at 10:44 PM Miguel Landaeta wrote:
> >
> > Thanks for the feedback.
> >
> > I attached a fixed version of the port.
> >
> > On Thu, Aug 3, 2023 at 11:04 PM Stuart Henderson
> > wrote:
> > >
> > > Make sure that you can still produce a package if the 0.0 in
> > > SHARED_LIBRARIES is changed (you probably need to pass
> > > ${LIBcpucycles_VERSION} in to the build).
> >
> > Got it. I was missing this in my first revision. I reworked one of the
> > patches
> > and verified that I can update the library version if/when required.
> >
> > > : MODULES+= lang/python
> > > : BUILD_DEPENDS= lang/python/${MODPY_DEFAULT_VERSION_3}
> > >
> > > BUILD_DEPENDS is automatically set by the python module, this isn't
> > > needed.
> >
> > Fixed.
> >
> > >
> > > > Description:
> > > > libcpucyples provides a simple API to access hardware precise timers
> > > typo ^
> > >
> >
> > Silly typo, fixed.
> >
> > > > +Small adjustments to make library manpage consistent
> > > > +Index: doc/man/cpucycles.3
> > >
> > > Unless necessary to make it work, I'd skip those.
> >
> > Ack. It makes more sense to fix it upstream.
>
> --
> Miguel Landaeta, miguel at miguel.cc
> secure email with PGP 0x6E608B637D8967E9 available at
> http://keyserver.pgp.com/
> "Faith means not wanting to know what is true." -- Nietzsche
>
Re: web-eid-app-chrome: support iridium
07.08.2023 23:01, Marc Espie пишет: > To be fair, most alternates dependencies do conflict, and the bits involved > work just fine with pkg_add -r. > > The *idea* of differing runtime dependencies is actually fairly rare. It surely is, so quite low priority, albeit still nice-to-have, imho.
Re: bsd.port.mk: check wxallowed after extract not patch
On Sun, Aug 06, 2023 at 12:06:22PM +, Klemens Nanni wrote: > On Tue, Aug 01, 2023 at 11:17:48AM +0200, Sebastien Marie wrote: > > On Mon, Jul 31, 2023 at 10:17:05PM +, Klemens Nanni wrote: > > > 'make patch' on a WXNEEDED=Yes port without wxallowed fails after > > > patching and before creating the patch cookie, so subsequent setting > > > of the option and rerunning the target will try to patch again. > > > > > > If the check is done right after extract, rerunning that target usually > > > has higher chances of just working. > > > > > > Is there a reason I'm not aware of that this is done after patch? > > > > > > > > > I just forgot to set wxallowed on /usr/ports/pobj when building > > > ungoogled-chromium where 'make clean && mount ... && make patch' takes > > > considerably longer than 'mount ... && make extract' to recover from > > > forgetting to set wxallowed. > > > > Personally, having it in extract step might be not convenient as extracting > > will > > require 'wxallowed', even if I just want to extract to look at source code. > > Good point. > > > Ideally, I would put such control code at start of 'configure' step. > > Doesn't "gen" also run GNU auto* which potentially needs wxallowed? > That's why I have moved it there now. > > Either way, making the check the first step of a target instead needs > its own target so that PORTS_PRIVSEP=Yes stays in effect. > > post-* or *-finalize where the first diff put it do not need that, as > they're already run as _pbuild. > > Does that still work for everyone's favourite USE_WXNEEDED=Yes workflow > without breaking other stuff, when you forget to set wxallowed? If I recall correctly, adding USE_WXNEEDED predates the gen step by some time, so it might be good there days.
Re: web-eid-app-chrome: support iridium
On Fri, Jul 28, 2023 at 03:16:53PM +, Klemens Nanni wrote: > On Fri, Jul 28, 2023 at 12:18:16PM +, Klemens Nanni wrote: > > On Tue, Jul 25, 2023 at 05:06:35PM +, Klemens Nanni wrote: > > > On Tue, Jul 25, 2023 at 04:42:10PM +, Klemens Nanni wrote: > > > > After one of the recent www/iridum updates, the extension/native host > > > > now > > > > works there just like it does with www/chromium. > > > > > > > > Is this the right way to depend on either chromium or iridium? > > > > The way I understand this: use either iridium-* or chromium-* if > > > > installed, > > > > otherwise install www/chromium to satisfy the runtime dependency. > > espie explained to me that this is how it is intended to work, but... > > > > > > Not in practise, as I can't uninstall chromium when iridium is > > > installed: > > we have no code yet for these uninstall/replace paths, so using variant > dependencies, does not seem useful to me until these bits are implemented. To be fair, most alternates dependencies do conflict, and the bits involved work just fine with pkg_add -r. The *idea* of differing runtime dependencies is actually fairly rare.
Re: NEW: misc/libcpucycles
Ping?
On Fri, Aug 4, 2023 at 10:44 PM Miguel Landaeta wrote:
>
> Thanks for the feedback.
>
> I attached a fixed version of the port.
>
> On Thu, Aug 3, 2023 at 11:04 PM Stuart Henderson wrote:
> >
> > Make sure that you can still produce a package if the 0.0 in
> > SHARED_LIBRARIES is changed (you probably need to pass
> > ${LIBcpucycles_VERSION} in to the build).
>
> Got it. I was missing this in my first revision. I reworked one of the patches
> and verified that I can update the library version if/when required.
>
> > : MODULES+= lang/python
> > : BUILD_DEPENDS= lang/python/${MODPY_DEFAULT_VERSION_3}
> >
> > BUILD_DEPENDS is automatically set by the python module, this isn't
> > needed.
>
> Fixed.
>
> >
> > > Description:
> > > libcpucyples provides a simple API to access hardware precise timers
> > typo ^
> >
>
> Silly typo, fixed.
>
> > > +Small adjustments to make library manpage consistent
> > > +Index: doc/man/cpucycles.3
> >
> > Unless necessary to make it work, I'd skip those.
>
> Ack. It makes more sense to fix it upstream.
--
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche
Re: new www/shiori
On 8/7/23 13:30, Paco Esteban wrote: > Hi ports@, > > This is a new port for shiori: https://github.com/go-shiori/shiori > > from pkg/DESCR: > > Shiori is a simple bookmarks manager written in the Go language. Intended > as > a simple clone of Pocket. You can use it as a command line application or > as > a web application. > > I had to make a bit of a dance to make it work as a system daemon. > The configuration is partly done via command line arguments and > environment variables. In order to be able to use those, I moved the > binary to /usr/local/libexec and created a wrapper script that loads the > variables from a config file (/etc/shiori.conf) if it exists and calls > the actual binary (thank you semarie@ for your help there). Not aimed at shiori in particular but I wanted to talk about how we are loading environment variables in rcctl in general. Until now the recommended approach was to put the variables in the /etc/login.conf.d/ file (like with the step-ca port), while I've also seen daemons who had to write these wrapper like scripts to load environment variables from config files (I did the same for all jitsi ports). Do we want to keep this fragmented approach or try to some up with a different method for loading/setting these variables? While not the ideal model, systemd allows setting environment variables in its unit file or allows setting a file from which to load environment variables (the EnvironmentFile variable) and openrc loads variables from /etc/conf.d/. Best, Aisha > > Problem with this approach is that rcctl stop fails, as the $pexp > argument we pass to pgrep/pkill will never match with the running > processes. Any ideas on how to fix this ? > > Anyway, port attached. It will also need this diff to add a user and > hook it to www: > > diff /usr/ports > commit - fa6409aecca5030e95103349250be29ad6145e00 > path + /usr/ports > blob - 4294460c8486b64663e65e8e8f384a6a9255e9d2 > file + infrastructure/db/user.list > --- infrastructure/db/user.list > +++ infrastructure/db/user.list > @@ -400,3 +400,4 @@ id user group port > 889 _gromox _gromox mail/grommunio/gromox > 890 _grommunio _grommunio mail/grommunio/admin-api > 891 _kiwix-serve _kiwix-servewww/kiwix/kiwix-tools > +892 _shiori _shiori www/shiori > blob - 5f97bc1356340c54242707d468c15bb5a70389bb > file + www/Makefile > --- www/Makefile > +++ www/Makefile > @@ -551,6 +551,7 @@ > SUBDIR += seamonkey-i18n > SUBDIR += selfoss > SUBDIR += sfeed > + SUBDIR += shiori > SUBDIR += slowhttptest > SUBDIR += smarc > SUBDIR += snownews >
new www/shiori
Hi ports@, This is a new port for shiori: https://github.com/go-shiori/shiori from pkg/DESCR: Shiori is a simple bookmarks manager written in the Go language. Intended as a simple clone of Pocket. You can use it as a command line application or as a web application. I had to make a bit of a dance to make it work as a system daemon. The configuration is partly done via command line arguments and environment variables. In order to be able to use those, I moved the binary to /usr/local/libexec and created a wrapper script that loads the variables from a config file (/etc/shiori.conf) if it exists and calls the actual binary (thank you semarie@ for your help there). Problem with this approach is that rcctl stop fails, as the $pexp argument we pass to pgrep/pkill will never match with the running processes. Any ideas on how to fix this ? Anyway, port attached. It will also need this diff to add a user and hook it to www: diff /usr/ports commit - fa6409aecca5030e95103349250be29ad6145e00 path + /usr/ports blob - 4294460c8486b64663e65e8e8f384a6a9255e9d2 file + infrastructure/db/user.list --- infrastructure/db/user.list +++ infrastructure/db/user.list @@ -400,3 +400,4 @@ id usergroup port 889 _gromox_gromox mail/grommunio/gromox 890 _grommunio _grommunio mail/grommunio/admin-api 891 _kiwix-serve _kiwix-servewww/kiwix/kiwix-tools +892 _shiori_shiori www/shiori blob - 5f97bc1356340c54242707d468c15bb5a70389bb file + www/Makefile --- www/Makefile +++ www/Makefile @@ -551,6 +551,7 @@ SUBDIR += seamonkey-i18n SUBDIR += selfoss SUBDIR += sfeed + SUBDIR += shiori SUBDIR += slowhttptest SUBDIR += smarc SUBDIR += snownews -- Paco Esteban. 0x5818130B8A6DBC03 shiori_port.tar.gz Description: application/tar-gz
Re: Firefox toLocaleString displays wrong time on OpenBSD
Le Sat, Aug 05, 2023 at 07:41:12PM -0400, George Koehler a écrit : > On Sat, 5 Aug 2023 08:49:25 +0200 > Landry Breuil wrote: > > > I'm not sure i'll be able to look into it, but i'd rather *not* document > > 'workarounds' for issues until we're sure the issue isnt fixable. Maybe > > it's pledge/unveil related, maybe not. Using ktrace to figure out which > > files the browser tries to access when handling date-related functions > > might help... and if it's not an issue happening only on OpenBSD, then > > dealing with upstream is the way to go. > > I used ktrace. It's unveil. The fix is to add "/etc/localtime r" > to /etc/firefox/unveil.content many thanks george for the time spend of this and this detailed analysis. Definitely ok for me to add `/etc/localtime r` to /etc/firefox/unveil.content, if it doesnt need to unveil the full usr/share/zoneinfo subdir thats even simpler. Landry
