Index: Makefile
===================================================================
RCS file: /cvs/ports/net/synapse/Makefile,v
diff -u -p -r1.90 Makefile
--- Makefile 27 Nov 2024 14:30:04 -0000 1.90
+++ Makefile 4 Dec 2024 07:37:43 -0000
@@ -1,7 +1,6 @@
COMMENT = open network for secure, decentralized communication
-MODPY_EGG_VERSION = 1.120.0
-REVISION = 0
+MODPY_EGG_VERSION = 1.120.2
GH_ACCOUNT = element-hq
GH_PROJECT = synapse
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/synapse/distinfo,v
diff -u -p -r1.67 distinfo
--- distinfo 27 Nov 2024 09:12:27 -0000 1.67
+++ distinfo 4 Dec 2024 07:37:43 -0000
@@ -84,7 +84,7 @@ SHA256 (cargo/windows_i686_msvc-0.52.5.t
SHA256 (cargo/windows_x86_64_gnu-0.52.5.tar.gz) = TkJG92ve/wnrSIdaD9Pir2qtp51AnTMBGIbT4VgVF9k=
SHA256 (cargo/windows_x86_64_gnullvm-0.52.5.tar.gz) = hSKY5ILNZ8NW3dlXA4bihitWc8hb1fiN+atoArM0xZY=
SHA256 (cargo/windows_x86_64_msvc-0.52.5.tar.gz) = vsR+W/0b/w7q9ti0hcwQdIkaGXq0Il1QTLehq4iwK/A=
-SHA256 (synapse-1.120.0.tar.gz) = 9YM6nK/jDDiaWpA+tenpFUyK4sRDQ8X8Q+M+J1C9ZEI=
+SHA256 (synapse-1.120.2.tar.gz) = eR9qYL4mNQ9L3nKw1LfCL3XWvhgnbB8YGSoNQTcMIes=
SIZE (cargo/aho-corasick-1.1.3.tar.gz) = 183311
SIZE (cargo/anyhow-1.0.93.tar.gz) = 47490
SIZE (cargo/arc-swap-1.7.1.tar.gz) = 68512
@@ -171,4 +171,4 @@ SIZE (cargo/windows_i686_msvc-0.52.5.tar
SIZE (cargo/windows_x86_64_gnu-0.52.5.tar.gz) = 831539
SIZE (cargo/windows_x86_64_gnullvm-0.52.5.tar.gz) = 433246
SIZE (cargo/windows_x86_64_msvc-0.52.5.tar.gz) = 827905
-SIZE (synapse-1.120.0.tar.gz) = 8819007
+SIZE (synapse-1.120.2.tar.gz) = 8821285
Index: Makefile
===================================================================
RCS file: /cvs/ports/net/synapse/Makefile,v
diff -u -p -r1.84 Makefile
--- Makefile 5 Sep 2024 14:09:06 -0000 1.84
+++ Makefile 4 Dec 2024 07:43:38 -0000
@@ -1,6 +1,6 @@
COMMENT = open network for secure, decentralized communication
-MODPY_EGG_VERSION = 1.114.0
+MODPY_EGG_VERSION = 1.120.2
GH_ACCOUNT = element-hq
GH_PROJECT = synapse
Index: distinfo
===================================================================
RCS file: /cvs/ports/net/synapse/distinfo,v
diff -u -p -r1.63 distinfo
--- distinfo 5 Sep 2024 14:09:06 -0000 1.63
+++ distinfo 4 Dec 2024 07:43:38 -0000
@@ -1,5 +1,5 @@
SHA256 (cargo/aho-corasick-1.1.3.tar.gz) = jmDTQw06aUeK0Jk/GSONLfl8UHAJpSs8EK3c1/a8uRY=
-SHA256 (cargo/anyhow-1.0.86.tar.gz) = s9HQRiOJkLnPW83iKj+zWE7lz2X7J2X0VO1CjHoAY9o=
+SHA256 (cargo/anyhow-1.0.93.tar.gz) = TJXBC6CwCgJjYji4FJRkCLEyLVrEdgMm5vuOyVbYV3U=
SHA256 (cargo/arc-swap-1.7.1.tar.gz) = aff4w5BrYrdUzVMmBHiUMWAh3P5aGUyOpSvdlJNKNFc=
SHA256 (cargo/autocfg-1.3.0.tar.gz) = DEtNC9Jb0LdGgcCtIUl2EM4bfJGxAizSHIDG+92UdrA=
SHA256 (cargo/base64-0.21.7.tar.gz) = nSl96xkluJ8szBPXY1+gcU8SyHrc4cdTVrOcqbcXhWc=
@@ -7,7 +7,7 @@ SHA256 (cargo/bitflags-2.5.0.tar.gz) = z
SHA256 (cargo/blake2-0.10.6.tar.gz) = RlAq1FjJpStp1NTTJ3XHiLehuF6LydSC2SJQ/A4/jv4=
SHA256 (cargo/block-buffer-0.10.4.tar.gz) = MHjHYpti0/BDlRf6OUmWrKzFy8kcWiDYxljner1QOnE=
SHA256 (cargo/bumpalo-3.16.0.tar.gz) = eSlnFhcYgJQ7hHC1+NA6pV6y5kWkh0vbsorbSRYuASw=
-SHA256 (cargo/bytes-1.7.1.tar.gz) = gxilPbB7s/jcqRpgBGa9s/Lqre7f288C4azLrZJxulA=
+SHA256 (cargo/bytes-1.8.0.tar.gz) = msAVDKoq5lylvYPyXH3hg96njU02ZGnxSENeKs+60No=
SHA256 (cargo/cfg-if-1.0.0.tar.gz) = uvHeQzl2FYi8Bhnjy8ASDuWC67dLU7Tvv3kRe9LaQP0=
SHA256 (cargo/cpufeatures-0.2.12.tar.gz) = U/5eJv8beu+LypxggFIM+42TM8dWjhgpzvGRqXI+VQQ=
SHA256 (cargo/crypto-common-0.1.6.tar.gz) = G/sSUC8/xGzKG7Uawo351hjYE83D0vJbn+d1o0rya7M=
@@ -36,7 +36,7 @@ SHA256 (cargo/parking_lot-0.12.2.tar.gz)
SHA256 (cargo/parking_lot_core-0.9.10.tar.gz) = HkAfl3qzhcnk46swYn1vJtAOLHPu8xdJPE7G1GhybPg=
SHA256 (cargo/portable-atomic-1.6.0.tar.gz) = cXDvmYi8FpuhbdNqf6BB5cTL62o1t21MA9re03Hq58A=
SHA256 (cargo/ppv-lite86-0.2.17.tar.gz) = W0CvgFsxIf6rijwp8E2K0mL6jgVhiD52U+AkrkR55t4=
-SHA256 (cargo/proc-macro2-1.0.82.tar.gz) = itPUmrlRoB+6r+NPLsdBIpQv4Yo/mBTDJo8btyBCExs=
+SHA256 (cargo/proc-macro2-1.0.89.tar.gz) = 8TmwZi3ghZFtH7Z9K0Fp0a3d3aGRnmlvMlK3QLYpmG4=
SHA256 (cargo/pyo3-0.21.2.tar.gz) = peALlqUhcY4I4DsaYi8ByKjetQcZM13j9gs7OVDwadg=
SHA256 (cargo/pyo3-build-config-0.21.2.tar.gz) = eIPfWDX6/a2HwNiIsmbI7A9MnKSKW+1ru1kuje3uG1A=
SHA256 (cargo/pyo3-ffi-0.21.2.tar.gz) = Ab5YQ9xguRarTa0dym0gubTm3cjhX1DEf+bYXx+5dAM=
@@ -49,19 +49,19 @@ SHA256 (cargo/rand-0.8.5.tar.gz) = NK+NG
SHA256 (cargo/rand_chacha-0.3.1.tar.gz) = 5sEKY6D6MiUr5J0h53CdTUuvjSMcLbzh6qgUG5sSfYg=
SHA256 (cargo/rand_core-0.6.4.tar.gz) = 7AvkeV4vaigGm+wLX/PirJuvyZ5qmn3DVHmWxcgWkiw=
SHA256 (cargo/redox_syscall-0.5.1.tar.gz) = RpBSiU3LVTQh5IPkIJ7lgaRRANMbQBjeA+WnrYY3Sn4=
-SHA256 (cargo/regex-1.10.6.tar.gz) = QhnXTGtno2VKn768S0GeIhJtE9LzxKB+4Mth/3mnlhk=
-SHA256 (cargo/regex-automata-0.4.6.tar.gz) = hrg7i5hH+b+V72ivsLjmzbgPSYRC9ReaKfrUSPzB6uo=
-SHA256 (cargo/regex-syntax-0.8.3.tar.gz) = ra1E4p5MgGEZSRp/BvA95NGvIsOmgN1H8ebheUOdH1Y=
+SHA256 (cargo/regex-1.11.1.tar.gz) = tUTvG06sXcLbM+pjYGrp/8+sJsFBaigGrgv19WsgEZE=
+SHA256 (cargo/regex-automata-0.4.8.tar.gz) = NodY8jJ0cStQSEjp1abwEERcyLh6fNtNfL7mZsEojaM=
+SHA256 (cargo/regex-syntax-0.8.5.tar.gz) = KxXEMYa+Z6T9Y77lDQMDr//O84FJLr4sXYfzJOG4gVw=
SHA256 (cargo/ryu-1.0.18.tar.gz) = 88tboNxDJCzhfemcGA6W25CyNbip/clUPJbSIJEWvZ8=
SHA256 (cargo/scopeguard-1.2.0.tar.gz) = lBQ/N3JRCfksJi7Sz15ZvOdJjAG8wVAte5r+Q5pOn0k=
-SHA256 (cargo/serde-1.0.209.tar.gz) = mfzg/+cxB2HKa/n69RFa+8GWiO3QAXHYGxuxsRbGPgk=
-SHA256 (cargo/serde_derive-1.0.209.tar.gz) = pYMbl5/XtUOWN68XUtU1/0n0hgwPNB0brrb68PQkIXA=
-SHA256 (cargo/serde_json-1.0.127.tar.gz) = gEPAbZ+CvXJxNh7WT0Ff5eEqd/21Llc+fwalFt6jKa0=
+SHA256 (cargo/serde-1.0.215.tar.gz) = ZRPBrQsRqTdtqIjj4LqgB38a7VXBf1DnsjlxNhKfuI8=
+SHA256 (cargo/serde_derive-1.0.215.tar.gz) = rR6Gb4ZpI/JS8FyImYeZMUT7dOciQDRopOvXDDzXVsA=
+SHA256 (cargo/serde_json-1.0.132.tar.gz) = 1ya/r/SzICZtOViYkF0OugNFquI7VK7jpzfiYP1G2wM=
SHA256 (cargo/sha1-0.10.6.tar.gz) = 47+Cmi1Rq0pd3xNS2EcMFAytyDAbKuF4nbAj8Bzt1ro=
SHA256 (cargo/sha2-0.10.8.tar.gz) = eT23WtK8r8P/p8aLIV/uJo9TeYLNkB0TL4nGND86Pcg=
SHA256 (cargo/smallvec-1.13.2.tar.gz) = PF4ammRtNsNZnNFzpBKC2vR8RFg602e45oNyVZUuXGc=
SHA256 (cargo/subtle-2.5.0.tar.gz) = gc3WTTErrttY4hM2sxvAQ7d+AcyZAzznbvU5946WXrw=
-SHA256 (cargo/syn-2.0.61.tar.gz) = yZPtjMulauhWNjsYRdpyZqfLeOHRRsijLVS0WouDH8k=
+SHA256 (cargo/syn-2.0.85.tar.gz) = UCMWLfzRTvjzIDTYvNTMXdxh73okfAJKM+JOHyTSG1Y=
SHA256 (cargo/target-lexicon-0.12.14.tar.gz) = 4fxAOJGiG8+3w3g0umalR6j0AhRuunJltabYgFnJ/y8=
SHA256 (cargo/typenum-1.17.0.tar.gz) = Qv8L8MZrgjjG87V43zfQt4SOVd+Fd7P3T5KmmszuuCU=
SHA256 (cargo/ulid-1.1.3.tar.gz) = BPkD8pPRHzHAwp5BSPbcDQM6f4DOvAKCvqFHYRZn0ok=
@@ -84,9 +84,9 @@ SHA256 (cargo/windows_i686_msvc-0.52.5.t
SHA256 (cargo/windows_x86_64_gnu-0.52.5.tar.gz) = TkJG92ve/wnrSIdaD9Pir2qtp51AnTMBGIbT4VgVF9k=
SHA256 (cargo/windows_x86_64_gnullvm-0.52.5.tar.gz) = hSKY5ILNZ8NW3dlXA4bihitWc8hb1fiN+atoArM0xZY=
SHA256 (cargo/windows_x86_64_msvc-0.52.5.tar.gz) = vsR+W/0b/w7q9ti0hcwQdIkaGXq0Il1QTLehq4iwK/A=
-SHA256 (synapse-1.114.0.tar.gz) = rncyHGFKaEt6+v/x/5VC+0tEd95amyXCMjdRTdKObig=
+SHA256 (synapse-1.120.2.tar.gz) = eR9qYL4mNQ9L3nKw1LfCL3XWvhgnbB8YGSoNQTcMIes=
SIZE (cargo/aho-corasick-1.1.3.tar.gz) = 183311
-SIZE (cargo/anyhow-1.0.86.tar.gz) = 46741
+SIZE (cargo/anyhow-1.0.93.tar.gz) = 47490
SIZE (cargo/arc-swap-1.7.1.tar.gz) = 68512
SIZE (cargo/autocfg-1.3.0.tar.gz) = 16524
SIZE (cargo/base64-0.21.7.tar.gz) = 82576
@@ -94,7 +94,7 @@ SIZE (cargo/bitflags-2.5.0.tar.gz) = 438
SIZE (cargo/blake2-0.10.6.tar.gz) = 47234
SIZE (cargo/block-buffer-0.10.4.tar.gz) = 10538
SIZE (cargo/bumpalo-3.16.0.tar.gz) = 85677
-SIZE (cargo/bytes-1.7.1.tar.gz) = 63623
+SIZE (cargo/bytes-1.8.0.tar.gz) = 64824
SIZE (cargo/cfg-if-1.0.0.tar.gz) = 7934
SIZE (cargo/cpufeatures-0.2.12.tar.gz) = 12837
SIZE (cargo/crypto-common-0.1.6.tar.gz) = 8760
@@ -123,7 +123,7 @@ SIZE (cargo/parking_lot-0.12.2.tar.gz) =
SIZE (cargo/parking_lot_core-0.9.10.tar.gz) = 32406
SIZE (cargo/portable-atomic-1.6.0.tar.gz) = 140689
SIZE (cargo/ppv-lite86-0.2.17.tar.gz) = 22242
-SIZE (cargo/proc-macro2-1.0.82.tar.gz) = 48452
+SIZE (cargo/proc-macro2-1.0.89.tar.gz) = 49446
SIZE (cargo/pyo3-0.21.2.tar.gz) = 504574
SIZE (cargo/pyo3-build-config-0.21.2.tar.gz) = 30581
SIZE (cargo/pyo3-ffi-0.21.2.tar.gz) = 66160
@@ -136,19 +136,19 @@ SIZE (cargo/rand-0.8.5.tar.gz) = 87113
SIZE (cargo/rand_chacha-0.3.1.tar.gz) = 15251
SIZE (cargo/rand_core-0.6.4.tar.gz) = 22666
SIZE (cargo/redox_syscall-0.5.1.tar.gz) = 22536
-SIZE (cargo/regex-1.10.6.tar.gz) = 253894
-SIZE (cargo/regex-automata-0.4.6.tar.gz) = 617565
-SIZE (cargo/regex-syntax-0.8.3.tar.gz) = 347497
+SIZE (cargo/regex-1.11.1.tar.gz) = 254170
+SIZE (cargo/regex-automata-0.4.8.tar.gz) = 617784
+SIZE (cargo/regex-syntax-0.8.5.tar.gz) = 357541
SIZE (cargo/ryu-1.0.18.tar.gz) = 47713
SIZE (cargo/scopeguard-1.2.0.tar.gz) = 11619
-SIZE (cargo/serde-1.0.209.tar.gz) = 78364
-SIZE (cargo/serde_derive-1.0.209.tar.gz) = 56023
-SIZE (cargo/serde_json-1.0.127.tar.gz) = 149465
+SIZE (cargo/serde-1.0.215.tar.gz) = 78527
+SIZE (cargo/serde_derive-1.0.215.tar.gz) = 57092
+SIZE (cargo/serde_json-1.0.132.tar.gz) = 150549
SIZE (cargo/sha1-0.10.6.tar.gz) = 13517
SIZE (cargo/sha2-0.10.8.tar.gz) = 26357
SIZE (cargo/smallvec-1.13.2.tar.gz) = 35216
SIZE (cargo/subtle-2.5.0.tar.gz) = 13909
-SIZE (cargo/syn-2.0.61.tar.gz) = 257199
+SIZE (cargo/syn-2.0.85.tar.gz) = 275231
SIZE (cargo/target-lexicon-0.12.14.tar.gz) = 25508
SIZE (cargo/typenum-1.17.0.tar.gz) = 42849
SIZE (cargo/ulid-1.1.3.tar.gz) = 11596
@@ -171,4 +171,4 @@ SIZE (cargo/windows_i686_msvc-0.52.5.tar
SIZE (cargo/windows_x86_64_gnu-0.52.5.tar.gz) = 831539
SIZE (cargo/windows_x86_64_gnullvm-0.52.5.tar.gz) = 433246
SIZE (cargo/windows_x86_64_msvc-0.52.5.tar.gz) = 827905
-SIZE (synapse-1.114.0.tar.gz) = 8697736
+SIZE (synapse-1.120.2.tar.gz) = 8821285
Index: modules.inc
===================================================================
RCS file: /cvs/ports/net/synapse/modules.inc,v
diff -u -p -r1.30 modules.inc
--- modules.inc 5 Sep 2024 14:09:06 -0000 1.30
+++ modules.inc 4 Dec 2024 07:43:38 -0000
@@ -1,5 +1,5 @@
MODCARGO_CRATES += aho-corasick 1.1.3 # Unlicense OR MIT
-MODCARGO_CRATES += anyhow 1.0.86 # MIT OR Apache-2.0
+MODCARGO_CRATES += anyhow 1.0.93 # MIT OR Apache-2.0
MODCARGO_CRATES += arc-swap 1.7.1 # MIT OR Apache-2.0
MODCARGO_CRATES += autocfg 1.3.0 # Apache-2.0 OR MIT
MODCARGO_CRATES += base64 0.21.7 # MIT OR Apache-2.0
@@ -7,7 +7,7 @@ MODCARGO_CRATES += bitflags 2.5.0 # MIT
MODCARGO_CRATES += blake2 0.10.6 # MIT OR Apache-2.0
MODCARGO_CRATES += block-buffer 0.10.4 # MIT OR Apache-2.0
MODCARGO_CRATES += bumpalo 3.16.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += bytes 1.7.1 # MIT
+MODCARGO_CRATES += bytes 1.8.0 # MIT
MODCARGO_CRATES += cfg-if 1.0.0 # MIT/Apache-2.0
MODCARGO_CRATES += cpufeatures 0.2.12 # MIT OR Apache-2.0
MODCARGO_CRATES += crypto-common 0.1.6 # MIT OR Apache-2.0
@@ -36,7 +36,7 @@ MODCARGO_CRATES += parking_lot 0.12.2 #
MODCARGO_CRATES += parking_lot_core 0.9.10 # MIT OR Apache-2.0
MODCARGO_CRATES += portable-atomic 1.6.0 # Apache-2.0 OR MIT
MODCARGO_CRATES += ppv-lite86 0.2.17 # MIT/Apache-2.0
-MODCARGO_CRATES += proc-macro2 1.0.82 # MIT OR Apache-2.0
+MODCARGO_CRATES += proc-macro2 1.0.89 # MIT OR Apache-2.0
MODCARGO_CRATES += pyo3 0.21.2 # MIT OR Apache-2.0
MODCARGO_CRATES += pyo3-build-config 0.21.2 # MIT OR Apache-2.0
MODCARGO_CRATES += pyo3-ffi 0.21.2 # MIT OR Apache-2.0
@@ -49,19 +49,19 @@ MODCARGO_CRATES += rand 0.8.5 # MIT OR A
MODCARGO_CRATES += rand_chacha 0.3.1 # MIT OR Apache-2.0
MODCARGO_CRATES += rand_core 0.6.4 # MIT OR Apache-2.0
MODCARGO_CRATES += redox_syscall 0.5.1 # MIT
-MODCARGO_CRATES += regex 1.10.6 # MIT OR Apache-2.0
-MODCARGO_CRATES += regex-automata 0.4.6 # MIT OR Apache-2.0
-MODCARGO_CRATES += regex-syntax 0.8.3 # MIT OR Apache-2.0
+MODCARGO_CRATES += regex 1.11.1 # MIT OR Apache-2.0
+MODCARGO_CRATES += regex-automata 0.4.8 # MIT OR Apache-2.0
+MODCARGO_CRATES += regex-syntax 0.8.5 # MIT OR Apache-2.0
MODCARGO_CRATES += ryu 1.0.18 # Apache-2.0 OR BSL-1.0
MODCARGO_CRATES += scopeguard 1.2.0 # MIT OR Apache-2.0
-MODCARGO_CRATES += serde 1.0.209 # MIT OR Apache-2.0
-MODCARGO_CRATES += serde_derive 1.0.209 # MIT OR Apache-2.0
-MODCARGO_CRATES += serde_json 1.0.127 # MIT OR Apache-2.0
+MODCARGO_CRATES += serde 1.0.215 # MIT OR Apache-2.0
+MODCARGO_CRATES += serde_derive 1.0.215 # MIT OR Apache-2.0
+MODCARGO_CRATES += serde_json 1.0.132 # MIT OR Apache-2.0
MODCARGO_CRATES += sha1 0.10.6 # MIT OR Apache-2.0
MODCARGO_CRATES += sha2 0.10.8 # MIT OR Apache-2.0
MODCARGO_CRATES += smallvec 1.13.2 # MIT OR Apache-2.0
MODCARGO_CRATES += subtle 2.5.0 # BSD-3-Clause
-MODCARGO_CRATES += syn 2.0.61 # MIT OR Apache-2.0
+MODCARGO_CRATES += syn 2.0.85 # MIT OR Apache-2.0
MODCARGO_CRATES += target-lexicon 0.12.14 # Apache-2.0 WITH LLVM-exception
MODCARGO_CRATES += typenum 1.17.0 # MIT OR Apache-2.0
MODCARGO_CRATES += ulid 1.1.3 # MIT
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/net/synapse/pkg/PLIST,v
diff -u -p -r1.54 PLIST
--- pkg/PLIST 5 Sep 2024 14:09:06 -0000 1.54
+++ pkg/PLIST 4 Dec 2024 07:43:38 -0000
@@ -440,6 +440,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}cas.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}deactivate_account.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}deactivate_account.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}device.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}device.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/${MODPY_PYCACHE}devicemessage.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -526,6 +528,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/auth.py
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/cas.py
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/deactivate_account.py
+lib/python${MODPY_VERSION}/site-packages/synapse/handlers/delayed_events.py
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/device.py
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/devicemessage.py
lib/python${MODPY_VERSION}/site-packages/synapse/handlers/directory.py
@@ -802,6 +805,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}_base.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}account_data.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}account_data.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}devices.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}devices.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}federation.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -826,6 +831,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/${MODPY_PYCACHE}streams.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/_base.py
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/account_data.py
+lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/delayed_events.py
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/devices.py
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/federation.py
lib/python${MODPY_VERSION}/site-packages/synapse/replication/http/login.py
@@ -1009,6 +1015,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}auth_issuer.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}capabilities.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}capabilities.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}devices.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}devices.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/${MODPY_PYCACHE}directory.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -1091,6 +1099,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/auth.py
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/auth_issuer.py
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/capabilities.py
+lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/delayed_events.py
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/devices.py
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/directory.py
lib/python${MODPY_VERSION}/site-packages/synapse/rest/client/events.py
@@ -1361,6 +1370,8 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}censor_events.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}client_ips.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}client_ips.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}delayed_events.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}deviceinbox.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}deviceinbox.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/${MODPY_PYCACHE}devices.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
@@ -1454,6 +1465,7 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/cache.py
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/censor_events.py
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/client_ips.py
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/delayed_events.py
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/deviceinbox.py
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/devices.py
lib/python${MODPY_VERSION}/site-packages/synapse/storage/databases/main/directory.py
@@ -2100,7 +2112,17 @@ lib/python${MODPY_VERSION}/site-packages
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/86/01_authenticate_media.sql
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/86/02_receipts_event_id_index.sql
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/87/
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/87/01_sliding_sync_memberships.sql
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/87/02_per_connection_state.sql
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/87/03_current_state_index.sql
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/01_add_delayed_events.sql
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/02_fix_sliding_sync_membership_snapshots_forgotten_column.sql
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/03_add_otk_ts_added_index.sql
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/04_current_state_delta_index.sql
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/05_drop_old_otks.sql.postgres
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/05_drop_old_otks.sql.sqlite
+lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/delta/88/05_sliding_sync_room_config_index.sql
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/full_schemas/
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/full_schemas/72/
lib/python${MODPY_VERSION}/site-packages/synapse/storage/schema/main/full_schemas/72/full.sql.postgres
@@ -2189,6 +2211,11 @@ ${MODPY_COMMENT}lib/python${MODPY_VERSIO
lib/python${MODPY_VERSION}/site-packages/synapse/types/rest/client/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/synapse/types/rest/client/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/types/state.py
+lib/python${MODPY_VERSION}/site-packages/synapse/types/storage/
+lib/python${MODPY_VERSION}/site-packages/synapse/types/storage/__init__.py
+${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/synapse/types/storage/${MODPY_PYCACHE}/
+lib/python${MODPY_VERSION}/site-packages/synapse/types/storage/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/synapse/types/storage/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/synapse/util/
lib/python${MODPY_VERSION}/site-packages/synapse/util/__init__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/synapse/util/${MODPY_PYCACHE}/
Hello,
Here is a patch for net/synapse-1.120.2. It fixes 6 security issues
which can be seen here:
https://github.com/element-hq/synapse/releases/tag/v1.120.2
All prior versions of synapse are affected.
I attached 2 diffs, the -stable one is for 7.6-stable (tested on amd64)
The other one is for -current (tested on amd64)
Best Regards
Tuesday, December 03, 2024
Re: new devel/llvm-openmp
Hi blum,
I'm using OpenBSD 7.6 RELEASE on amd64 box. I installed cmake and ninja
from the binary package and compiled llvm-openmp successfully. I also
ran `make test' on /usr/ports/devel/llvm-openmp and I got the following
result:
$ make test
===> Regression tests for llvm-openmp-16.0.6
UpdateCTestConfiguration from
:/usr/ports/pobj/llvm-openmp-16.0.6/build-amd64/DartConfiguration.tcl
UpdateCTestConfiguration from
:/usr/ports/pobj/llvm-openmp-16.0.6/build-amd64/DartConfiguration.tcl
Test project /usr/ports/pobj/llvm-openmp-16.0.6/build-amd64
Constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
No tests were found!!!
Could you teach me how to test OpenMP?
Thank you.
--
ASOU Masato
On Wed, Dec 4, 2024 at 7:34 AM Alexander Bluhm <bluhm@openbsd.org> wrote:
>
> Hi,
>
> I need OpenMP for some other port I am working on. It is an extension
> for gcc or clang. Currently I only need it for base clang, so I
> build it from llvm 16.0.6 sources.
>
> Comment:
> LLVM OpenMP libraries
>
> Description:
> The OpenMP API supports multi-platform shared-memory parallel
> programming in C/C++ and Fortran. The OpenMP API defines a portable,
> scalable model with a simple and flexible interface for developing
> parallel applications on platforms from the desktop to the
> supercomputer.
>
> ok to import?
>
> bluhm
I'm using OpenBSD 7.6 RELEASE on amd64 box. I installed cmake and ninja
from the binary package and compiled llvm-openmp successfully. I also
ran `make test' on /usr/ports/devel/llvm-openmp and I got the following
result:
$ make test
===> Regression tests for llvm-openmp-16.0.6
UpdateCTestConfiguration from
:/usr/ports/pobj/llvm-openmp-16.0.6/build-amd64/DartConfiguration.tcl
UpdateCTestConfiguration from
:/usr/ports/pobj/llvm-openmp-16.0.6/build-amd64/DartConfiguration.tcl
Test project /usr/ports/pobj/llvm-openmp-16.0.6/build-amd64
Constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
No tests were found!!!
Could you teach me how to test OpenMP?
Thank you.
--
ASOU Masato
On Wed, Dec 4, 2024 at 7:34 AM Alexander Bluhm <bluhm@openbsd.org> wrote:
>
> Hi,
>
> I need OpenMP for some other port I am working on. It is an extension
> for gcc or clang. Currently I only need it for base clang, so I
> build it from llvm 16.0.6 sources.
>
> Comment:
> LLVM OpenMP libraries
>
> Description:
> The OpenMP API supports multi-platform shared-memory parallel
> programming in C/C++ and Fortran. The OpenMP API defines a portable,
> scalable model with a simple and flexible interface for developing
> parallel applications on platforms from the desktop to the
> supercomputer.
>
> ok to import?
>
> bluhm
lang/sbcl-2.4.11: breaks x11/stumpwm
Sebastien, ports@
I had discovered that x11/stumpwm can't be compiled anymore since the update
of sbcl to 2.4.11. I've tried both 23.11 and 24.11 versions of stumpwm and
it fails.
I was able to determine the commit that introduced the issue:
https://github.com/sbcl/sbcl/commit/55c0a64954972bd64114aacc6769a42056b71cf3
and had an open issue upstream: https://bugs.launchpad.net/sbcl/+bug/2090967
Not sure that the right move here: revert that commit? revert to
sbcl-2.4.10? Something else?
--
wbr, Kirill
I had discovered that x11/stumpwm can't be compiled anymore since the update
of sbcl to 2.4.11. I've tried both 23.11 and 24.11 versions of stumpwm and
it fails.
I was able to determine the commit that introduced the issue:
https://github.com/sbcl/sbcl/commit/55c0a64954972bd64114aacc6769a42056b71cf3
and had an open issue upstream: https://bugs.launchpad.net/sbcl/+bug/2090967
Not sure that the right move here: revert that commit? revert to
sbcl-2.4.10? Something else?
--
wbr, Kirill
Re: [fixing scipy 1/2] Update py-beniget to 0.4.2.post1
On 2024/12/04 01:51, James Cook wrote:
> Currently when I run "make" in math/py-scypi, I see something like this:
>
> * Getting build dependencies for wheel...
>
> ERROR Missing dependencies:
> pythran<0.16.0,>=0.14.0
> gast~=0.5.0
> pythran<0.16.0,>=0.14.0
> beniget~=0.4.0 -> gast~=0.5.0
>
> It seems both pythran and beniget have gast=~0.5.0 in requirements.txt,
> which is violated by a recent update.
>
> This patch updates py-beniget to a version with a looser requirement
> for gast. I hope the "post1" is allowed in MODPY_EGG_VERSION; at
> least, it is working for me.
.post1 is definitely correct for MODPY_EGG_VERSION.
It is ok for PKGNAME as long as it doesn't go above .post9 (which is
unlikely to happen) - play with pkg_check-version to see why.
On 2024/12/04 01:58, James Cook wrote:
> This is the second thing I needed to change before I could install
> the scipy port.
Both committed. I thought I had already tested building scipy with
the previous changes, but my "make update" failed after a previous
attempt to update pythran (which built ok itself but scipy didn't
like it) leaving me with a PLIST_DB file that stopped the older
numbered version from packaging, but I didn't notice it before
going on to build scipy.
> Currently when I run "make" in math/py-scypi, I see something like this:
>
> * Getting build dependencies for wheel...
>
> ERROR Missing dependencies:
> pythran<0.16.0,>=0.14.0
> gast~=0.5.0
> pythran<0.16.0,>=0.14.0
> beniget~=0.4.0 -> gast~=0.5.0
>
> It seems both pythran and beniget have gast=~0.5.0 in requirements.txt,
> which is violated by a recent update.
>
> This patch updates py-beniget to a version with a looser requirement
> for gast. I hope the "post1" is allowed in MODPY_EGG_VERSION; at
> least, it is working for me.
.post1 is definitely correct for MODPY_EGG_VERSION.
It is ok for PKGNAME as long as it doesn't go above .post9 (which is
unlikely to happen) - play with pkg_check-version to see why.
On 2024/12/04 01:58, James Cook wrote:
> This is the second thing I needed to change before I could install
> the scipy port.
Both committed. I thought I had already tested building scipy with
the previous changes, but my "make update" failed after a previous
attempt to update pythran (which built ok itself but scipy didn't
like it) leaving me with a PLIST_DB file that stopped the older
numbered version from packaging, but I didn't notice it before
going on to build scipy.
sparc64 bulk build report
Bulk build on sparc64-0a.ports.openbsd.org
Started : Sat Nov 30 21:37:27 MST 2024
Finished: Tue Dec 3 19:24:41 MST 2024
Duration: 2 Days 21 hours 47 minutes
Built using OpenBSD 7.6-current (GENERIC.MP) #2344: Sat Nov 30 02:49:15 MST 2024
Built 8925 packages
Number of packages built each day:
Nov 30: 3626
Dec 1: 3669
Dec 2: 1155
Dec 3: 475
Critical path missing pkgs:
http://cranky.work/sparc64/2024-11-30/summary.log
Build failures: 75
http://cranky.work/sparc64/2024-11-30/astro/wmglobe.log
http://cranky.work/sparc64/2024-11-30/audio/libcanberra.log
http://cranky.work/sparc64/2024-11-30/audio/mpdscribble.log
http://cranky.work/sparc64/2024-11-30/audio/ncmpc.log
http://cranky.work/sparc64/2024-11-30/audio/xmms2.log
http://cranky.work/sparc64/2024-11-30/cad/horizon-eda.log
http://cranky.work/sparc64/2024-11-30/databases/arrow/cpp.log
http://cranky.work/sparc64/2024-11-30/devel/abseil-cpp.log
http://cranky.work/sparc64/2024-11-30/devel/avr/gcc.log
http://cranky.work/sparc64/2024-11-30/devel/difftastic.log
http://cranky.work/sparc64/2024-11-30/devel/libbgcode.log
http://cranky.work/sparc64/2024-11-30/devel/rgbds.log
http://cranky.work/sparc64/2024-11-30/devel/shapelib.log
http://cranky.work/sparc64/2024-11-30/devel/vim-command-t.log
http://cranky.work/sparc64/2024-11-30/devel/woboq_codebrowser.log
http://cranky.work/sparc64/2024-11-30/devel/yder.log
http://cranky.work/sparc64/2024-11-30/emulators/dosbox-x.log
http://cranky.work/sparc64/2024-11-30/emulators/libretro-pcsx-rearmed.log
http://cranky.work/sparc64/2024-11-30/games/bugdom.log
http://cranky.work/sparc64/2024-11-30/games/bugdom2.log
http://cranky.work/sparc64/2024-11-30/games/cdogs-sdl.log
http://cranky.work/sparc64/2024-11-30/games/choria.log
http://cranky.work/sparc64/2024-11-30/games/colobot/colobot.log
http://cranky.work/sparc64/2024-11-30/games/cromagrally.log
http://cranky.work/sparc64/2024-11-30/games/devilutionx.log
http://cranky.work/sparc64/2024-11-30/games/ezquake.log
http://cranky.work/sparc64/2024-11-30/games/fheroes2.log
http://cranky.work/sparc64/2024-11-30/games/gnukem.log
http://cranky.work/sparc64/2024-11-30/games/lwjgl3.log
http://cranky.work/sparc64/2024-11-30/games/nblood.log
http://cranky.work/sparc64/2024-11-30/games/ottomatic.log
http://cranky.work/sparc64/2024-11-30/games/py-unitypy,python3.log
http://cranky.work/sparc64/2024-11-30/games/widelands.log
http://cranky.work/sparc64/2024-11-30/games/wrath.log
http://cranky.work/sparc64/2024-11-30/geo/osm2pgrouting.log
http://cranky.work/sparc64/2024-11-30/geo/spatialindex.log
http://cranky.work/sparc64/2024-11-30/graphics/decker.log
http://cranky.work/sparc64/2024-11-30/graphics/openexr,-doc.log
http://cranky.work/sparc64/2024-11-30/graphics/opensubdiv.log
http://cranky.work/sparc64/2024-11-30/graphics/openvdb.log
http://cranky.work/sparc64/2024-11-30/graphics/rawstudio.log
http://cranky.work/sparc64/2024-11-30/graphics/tesseract/tesseract.log
http://cranky.work/sparc64/2024-11-30/inputmethods/ibus.log
http://cranky.work/sparc64/2024-11-30/lang/wabt.log
http://cranky.work/sparc64/2024-11-30/mail/cyrus-imapd.log
http://cranky.work/sparc64/2024-11-30/mail/dovecot-fts-xapian.log
http://cranky.work/sparc64/2024-11-30/mail/grommunio/index.log
http://cranky.work/sparc64/2024-11-30/mail/rspamd.log
http://cranky.work/sparc64/2024-11-30/math/openfst.log
http://cranky.work/sparc64/2024-11-30/math/py-scikit-image,python3.log
http://cranky.work/sparc64/2024-11-30/math/py-scipy,python3.log
http://cranky.work/sparc64/2024-11-30/print/texlive/texmf,-buildset.log
http://cranky.work/sparc64/2024-11-30/sysutils/libvirt.log
http://cranky.work/sparc64/2024-11-30/sysutils/mangl.log
http://cranky.work/sparc64/2024-11-30/sysutils/nix.log
http://cranky.work/sparc64/2024-11-30/sysutils/opam.log
http://cranky.work/sparc64/2024-11-30/sysutils/u-boot-asahi.log
http://cranky.work/sparc64/2024-11-30/sysutils/virt-manager.log
http://cranky.work/sparc64/2024-11-30/telephony/baresip/baresip,-gtk.log
http://cranky.work/sparc64/2024-11-30/textproc/libmarisa,-main.log
http://cranky.work/sparc64/2024-11-30/textproc/link-grammar,,-main.log
http://cranky.work/sparc64/2024-11-30/textproc/redland-bindings,-main.log
http://cranky.work/sparc64/2024-11-30/textproc/sword.log
http://cranky.work/sparc64/2024-11-30/textproc/xerces-c.log
http://cranky.work/sparc64/2024-11-30/wayland/gtk-layer-shell.log
http://cranky.work/sparc64/2024-11-30/wayland/gtk4-layer-shell.log
http://cranky.work/sparc64/2024-11-30/wayland/wlroots.log
http://cranky.work/sparc64/2024-11-30/www/unit/unit-perl.log
http://cranky.work/sparc64/2024-11-30/www/unit/unit-python.log
http://cranky.work/sparc64/2024-11-30/www/webkitgtk4,webkitgtk41.log
http://cranky.work/sparc64/2024-11-30/x11/gnome/gjs.log
http://cranky.work/sparc64/2024-11-30/x11/nitrogen.log
http://cranky.work/sparc64/2024-11-30/x11/polybar.log
http://cranky.work/sparc64/2024-11-30/x11/qt5/qtbase.log
http://cranky.work/sparc64/2024-11-30/x11/qt6/qtbase.log
Recurrent failures:
failures/audio/xmms2.log
failures/cad/horizon-eda.log
failures/databases/arrow/cpp.log
failures/devel/abseil-cpp.log
failures/devel/avr/gcc.log
failures/devel/difftastic.log
failures/devel/libbgcode.log
failures/devel/rgbds.log
failures/devel/shapelib.log
failures/devel/vim-command-t.log
failures/games/ezquake.log
failures/games/fheroes2.log
failures/games/gnukem.log
failures/games/nblood.log
failures/games/ottomatic.log
failures/games/py-unitypy,python3.log
failures/geo/osm2pgrouting.log
failures/geo/spatialindex.log
failures/graphics/decker.log
failures/graphics/openvdb.log
failures/graphics/rawstudio.log
failures/graphics/tesseract/tesseract.log
failures/inputmethods/ibus.log
failures/lang/wabt.log
failures/mail/cyrus-imapd.log
failures/mail/dovecot-fts-xapian.log
failures/mail/grommunio/index.log
failures/math/openfst.log
failures/sysutils/libvirt.log
failures/sysutils/nix.log
failures/sysutils/opam.log
failures/sysutils/u-boot-asahi.log
failures/sysutils/virt-manager.log
failures/telephony/baresip/baresip,-gtk.log
failures/textproc/link-grammar,,-main.log
failures/textproc/redland-bindings,-main.log
failures/textproc/sword.log
failures/wayland/gtk-layer-shell.log
failures/wayland/gtk4-layer-shell.log
failures/wayland/wlroots.log
failures/www/unit/unit-perl.log
failures/www/unit/unit-python.log
failures/www/webkitgtk4,webkitgtk41.log
failures/x11/polybar.log
failures/x11/qt5/qtbase.log
failures/x11/qt6/qtbase.log
New failures:
+failures/games/lwjgl3.log
+failures/graphics/openexr,-doc.log
+failures/graphics/opensubdiv.log
+failures/mail/rspamd.log
+failures/math/py-scikit-image,python3.log
+failures/math/py-scipy,python3.log
+failures/print/texlive/texmf,-buildset.log
+failures/sysutils/mangl.log
+failures/textproc/libmarisa,-main.log
Resolved failures:
-failures/databases/sqlports.log
-failures/devel/arm-none-eabi/gdb.log
-failures/devel/gettext-tools.log
-failures/devel/immer.log
-failures/devel/libwnck3.log
-failures/devel/llvm/18.log
-failures/devel/log4cplus.log
-failures/devel/py-test-localserver,python3.log
-failures/graphics/glfw.log
-failures/graphics/openexr.log
-failures/graphics/xpm-pixbuf.log
-failures/mail/courier-unicode.log
-failures/mail/rspamd,hyperscan.log
-failures/math/py-netcdf4,python3.log
-failures/net/toxic,no_x11.log
-failures/textproc/libmarisa,,-main.log
-failures/textproc/libspelling.log
-failures/www/nginx,-cache_purge.log
-failures/x11/worker.log
Packages newly built:
+audio/moc
+comms/cc2538-bsl
+comms/py-serial-asyncio,python3
+databases/pkglocatedb
+databases/ports-readmes
+databases/ports-readmes-dancer
+databases/sqlports
+databases/sqlports,-list
+databases/sqlports,-main
+devel/arm-none-eabi/gdb
+devel/bamf
+devel/immer
+devel/lager
+devel/libwnck3
+devel/llvm/18
+devel/llvm/18,-main
+devel/llvm/18,-python
+devel/log4cplus
+devel/pecl-xdebug,php84
+devel/py-asynctest,python3
+devel/py-crccheck,python3
+devel/py-setuptools-git-versioning,python3
+devel/py-test-localserver,python3
+graphics/glfw
+graphics/xpm-pixbuf
+mail/courier-authlib
+mail/courier-authlib,
+mail/courier-authlib,,-ldap
+mail/courier-authlib,,-main
+mail/courier-authlib,,-mysql
+mail/courier-authlib,,-pgsql
+mail/courier-authlib,,-userdb
+mail/courier-authlib,-ldap
+mail/courier-authlib,-main
+mail/courier-authlib,-mysql
+mail/courier-authlib,-pgsql
+mail/courier-authlib,-userdb
+mail/courier-imap
+mail/courier-imap,-main
+mail/courier-imap,-pop3
+mail/courier-unicode
+mail/maildrop
+mail/maildrop,-main
+mail/maildrop,-utils
+mail/maildrop,postfix
+mail/maildrop,postfix,-main
+mail/maildrop,postfix,-utils
+math/py-netcdf4,python3
+misc/portroach
+net/kea
+net/kea,mysql
+net/kea,postgresql
+net/toxic
+net/toxic,no_x11
+sysutils/pkg_mgr
+textproc/libspelling
+www/nginx
+www/nginx,-cache_purge
+www/nginx,-geoip2
+www/nginx,-headers_more
+www/nginx,-image_filter
+www/nginx,-ldap_auth
+www/nginx,-lua
+www/nginx,-mailproxy
+www/nginx,-main
+www/nginx,-naxsi
+www/nginx,-njs
+www/nginx,-perl
+www/nginx,-rtmp
+www/nginx,-securelink
+www/nginx,-stream
+www/nginx,-xslt
+x11/elementary/dock
+x11/worker
Packages not built this time:
-astro/py-astropy,python3
-games/numptyphysics
-graphics/py-seaborn,python3
-math/py-ecos,python3
-math/py-osqp,python3
-math/py-scikit-image,python3
-math/py-scikit-learn,python3
-math/py-scipy,python3
-net/rpki-data
-print/texlive/texmf,-buildset
Started : Sat Nov 30 21:37:27 MST 2024
Finished: Tue Dec 3 19:24:41 MST 2024
Duration: 2 Days 21 hours 47 minutes
Built using OpenBSD 7.6-current (GENERIC.MP) #2344: Sat Nov 30 02:49:15 MST 2024
Built 8925 packages
Number of packages built each day:
Nov 30: 3626
Dec 1: 3669
Dec 2: 1155
Dec 3: 475
Critical path missing pkgs:
http://cranky.work/sparc64/2024-11-30/summary.log
Build failures: 75
http://cranky.work/sparc64/2024-11-30/astro/wmglobe.log
http://cranky.work/sparc64/2024-11-30/audio/libcanberra.log
http://cranky.work/sparc64/2024-11-30/audio/mpdscribble.log
http://cranky.work/sparc64/2024-11-30/audio/ncmpc.log
http://cranky.work/sparc64/2024-11-30/audio/xmms2.log
http://cranky.work/sparc64/2024-11-30/cad/horizon-eda.log
http://cranky.work/sparc64/2024-11-30/databases/arrow/cpp.log
http://cranky.work/sparc64/2024-11-30/devel/abseil-cpp.log
http://cranky.work/sparc64/2024-11-30/devel/avr/gcc.log
http://cranky.work/sparc64/2024-11-30/devel/difftastic.log
http://cranky.work/sparc64/2024-11-30/devel/libbgcode.log
http://cranky.work/sparc64/2024-11-30/devel/rgbds.log
http://cranky.work/sparc64/2024-11-30/devel/shapelib.log
http://cranky.work/sparc64/2024-11-30/devel/vim-command-t.log
http://cranky.work/sparc64/2024-11-30/devel/woboq_codebrowser.log
http://cranky.work/sparc64/2024-11-30/devel/yder.log
http://cranky.work/sparc64/2024-11-30/emulators/dosbox-x.log
http://cranky.work/sparc64/2024-11-30/emulators/libretro-pcsx-rearmed.log
http://cranky.work/sparc64/2024-11-30/games/bugdom.log
http://cranky.work/sparc64/2024-11-30/games/bugdom2.log
http://cranky.work/sparc64/2024-11-30/games/cdogs-sdl.log
http://cranky.work/sparc64/2024-11-30/games/choria.log
http://cranky.work/sparc64/2024-11-30/games/colobot/colobot.log
http://cranky.work/sparc64/2024-11-30/games/cromagrally.log
http://cranky.work/sparc64/2024-11-30/games/devilutionx.log
http://cranky.work/sparc64/2024-11-30/games/ezquake.log
http://cranky.work/sparc64/2024-11-30/games/fheroes2.log
http://cranky.work/sparc64/2024-11-30/games/gnukem.log
http://cranky.work/sparc64/2024-11-30/games/lwjgl3.log
http://cranky.work/sparc64/2024-11-30/games/nblood.log
http://cranky.work/sparc64/2024-11-30/games/ottomatic.log
http://cranky.work/sparc64/2024-11-30/games/py-unitypy,python3.log
http://cranky.work/sparc64/2024-11-30/games/widelands.log
http://cranky.work/sparc64/2024-11-30/games/wrath.log
http://cranky.work/sparc64/2024-11-30/geo/osm2pgrouting.log
http://cranky.work/sparc64/2024-11-30/geo/spatialindex.log
http://cranky.work/sparc64/2024-11-30/graphics/decker.log
http://cranky.work/sparc64/2024-11-30/graphics/openexr,-doc.log
http://cranky.work/sparc64/2024-11-30/graphics/opensubdiv.log
http://cranky.work/sparc64/2024-11-30/graphics/openvdb.log
http://cranky.work/sparc64/2024-11-30/graphics/rawstudio.log
http://cranky.work/sparc64/2024-11-30/graphics/tesseract/tesseract.log
http://cranky.work/sparc64/2024-11-30/inputmethods/ibus.log
http://cranky.work/sparc64/2024-11-30/lang/wabt.log
http://cranky.work/sparc64/2024-11-30/mail/cyrus-imapd.log
http://cranky.work/sparc64/2024-11-30/mail/dovecot-fts-xapian.log
http://cranky.work/sparc64/2024-11-30/mail/grommunio/index.log
http://cranky.work/sparc64/2024-11-30/mail/rspamd.log
http://cranky.work/sparc64/2024-11-30/math/openfst.log
http://cranky.work/sparc64/2024-11-30/math/py-scikit-image,python3.log
http://cranky.work/sparc64/2024-11-30/math/py-scipy,python3.log
http://cranky.work/sparc64/2024-11-30/print/texlive/texmf,-buildset.log
http://cranky.work/sparc64/2024-11-30/sysutils/libvirt.log
http://cranky.work/sparc64/2024-11-30/sysutils/mangl.log
http://cranky.work/sparc64/2024-11-30/sysutils/nix.log
http://cranky.work/sparc64/2024-11-30/sysutils/opam.log
http://cranky.work/sparc64/2024-11-30/sysutils/u-boot-asahi.log
http://cranky.work/sparc64/2024-11-30/sysutils/virt-manager.log
http://cranky.work/sparc64/2024-11-30/telephony/baresip/baresip,-gtk.log
http://cranky.work/sparc64/2024-11-30/textproc/libmarisa,-main.log
http://cranky.work/sparc64/2024-11-30/textproc/link-grammar,,-main.log
http://cranky.work/sparc64/2024-11-30/textproc/redland-bindings,-main.log
http://cranky.work/sparc64/2024-11-30/textproc/sword.log
http://cranky.work/sparc64/2024-11-30/textproc/xerces-c.log
http://cranky.work/sparc64/2024-11-30/wayland/gtk-layer-shell.log
http://cranky.work/sparc64/2024-11-30/wayland/gtk4-layer-shell.log
http://cranky.work/sparc64/2024-11-30/wayland/wlroots.log
http://cranky.work/sparc64/2024-11-30/www/unit/unit-perl.log
http://cranky.work/sparc64/2024-11-30/www/unit/unit-python.log
http://cranky.work/sparc64/2024-11-30/www/webkitgtk4,webkitgtk41.log
http://cranky.work/sparc64/2024-11-30/x11/gnome/gjs.log
http://cranky.work/sparc64/2024-11-30/x11/nitrogen.log
http://cranky.work/sparc64/2024-11-30/x11/polybar.log
http://cranky.work/sparc64/2024-11-30/x11/qt5/qtbase.log
http://cranky.work/sparc64/2024-11-30/x11/qt6/qtbase.log
Recurrent failures:
failures/audio/xmms2.log
failures/cad/horizon-eda.log
failures/databases/arrow/cpp.log
failures/devel/abseil-cpp.log
failures/devel/avr/gcc.log
failures/devel/difftastic.log
failures/devel/libbgcode.log
failures/devel/rgbds.log
failures/devel/shapelib.log
failures/devel/vim-command-t.log
failures/games/ezquake.log
failures/games/fheroes2.log
failures/games/gnukem.log
failures/games/nblood.log
failures/games/ottomatic.log
failures/games/py-unitypy,python3.log
failures/geo/osm2pgrouting.log
failures/geo/spatialindex.log
failures/graphics/decker.log
failures/graphics/openvdb.log
failures/graphics/rawstudio.log
failures/graphics/tesseract/tesseract.log
failures/inputmethods/ibus.log
failures/lang/wabt.log
failures/mail/cyrus-imapd.log
failures/mail/dovecot-fts-xapian.log
failures/mail/grommunio/index.log
failures/math/openfst.log
failures/sysutils/libvirt.log
failures/sysutils/nix.log
failures/sysutils/opam.log
failures/sysutils/u-boot-asahi.log
failures/sysutils/virt-manager.log
failures/telephony/baresip/baresip,-gtk.log
failures/textproc/link-grammar,,-main.log
failures/textproc/redland-bindings,-main.log
failures/textproc/sword.log
failures/wayland/gtk-layer-shell.log
failures/wayland/gtk4-layer-shell.log
failures/wayland/wlroots.log
failures/www/unit/unit-perl.log
failures/www/unit/unit-python.log
failures/www/webkitgtk4,webkitgtk41.log
failures/x11/polybar.log
failures/x11/qt5/qtbase.log
failures/x11/qt6/qtbase.log
New failures:
+failures/games/lwjgl3.log
+failures/graphics/openexr,-doc.log
+failures/graphics/opensubdiv.log
+failures/mail/rspamd.log
+failures/math/py-scikit-image,python3.log
+failures/math/py-scipy,python3.log
+failures/print/texlive/texmf,-buildset.log
+failures/sysutils/mangl.log
+failures/textproc/libmarisa,-main.log
Resolved failures:
-failures/databases/sqlports.log
-failures/devel/arm-none-eabi/gdb.log
-failures/devel/gettext-tools.log
-failures/devel/immer.log
-failures/devel/libwnck3.log
-failures/devel/llvm/18.log
-failures/devel/log4cplus.log
-failures/devel/py-test-localserver,python3.log
-failures/graphics/glfw.log
-failures/graphics/openexr.log
-failures/graphics/xpm-pixbuf.log
-failures/mail/courier-unicode.log
-failures/mail/rspamd,hyperscan.log
-failures/math/py-netcdf4,python3.log
-failures/net/toxic,no_x11.log
-failures/textproc/libmarisa,,-main.log
-failures/textproc/libspelling.log
-failures/www/nginx,-cache_purge.log
-failures/x11/worker.log
Packages newly built:
+audio/moc
+comms/cc2538-bsl
+comms/py-serial-asyncio,python3
+databases/pkglocatedb
+databases/ports-readmes
+databases/ports-readmes-dancer
+databases/sqlports
+databases/sqlports,-list
+databases/sqlports,-main
+devel/arm-none-eabi/gdb
+devel/bamf
+devel/immer
+devel/lager
+devel/libwnck3
+devel/llvm/18
+devel/llvm/18,-main
+devel/llvm/18,-python
+devel/log4cplus
+devel/pecl-xdebug,php84
+devel/py-asynctest,python3
+devel/py-crccheck,python3
+devel/py-setuptools-git-versioning,python3
+devel/py-test-localserver,python3
+graphics/glfw
+graphics/xpm-pixbuf
+mail/courier-authlib
+mail/courier-authlib,
+mail/courier-authlib,,-ldap
+mail/courier-authlib,,-main
+mail/courier-authlib,,-mysql
+mail/courier-authlib,,-pgsql
+mail/courier-authlib,,-userdb
+mail/courier-authlib,-ldap
+mail/courier-authlib,-main
+mail/courier-authlib,-mysql
+mail/courier-authlib,-pgsql
+mail/courier-authlib,-userdb
+mail/courier-imap
+mail/courier-imap,-main
+mail/courier-imap,-pop3
+mail/courier-unicode
+mail/maildrop
+mail/maildrop,-main
+mail/maildrop,-utils
+mail/maildrop,postfix
+mail/maildrop,postfix,-main
+mail/maildrop,postfix,-utils
+math/py-netcdf4,python3
+misc/portroach
+net/kea
+net/kea,mysql
+net/kea,postgresql
+net/toxic
+net/toxic,no_x11
+sysutils/pkg_mgr
+textproc/libspelling
+www/nginx
+www/nginx,-cache_purge
+www/nginx,-geoip2
+www/nginx,-headers_more
+www/nginx,-image_filter
+www/nginx,-ldap_auth
+www/nginx,-lua
+www/nginx,-mailproxy
+www/nginx,-main
+www/nginx,-naxsi
+www/nginx,-njs
+www/nginx,-perl
+www/nginx,-rtmp
+www/nginx,-securelink
+www/nginx,-stream
+www/nginx,-xslt
+x11/elementary/dock
+x11/worker
Packages not built this time:
-astro/py-astropy,python3
-games/numptyphysics
-graphics/py-seaborn,python3
-math/py-ecos,python3
-math/py-osqp,python3
-math/py-scikit-image,python3
-math/py-scikit-learn,python3
-math/py-scipy,python3
-net/rpki-data
-print/texlive/texmf,-buildset
[fixing scipy 2/2] pythran: allow gast > 0.5
This is the second thing I needed to change before I could install
the scipy port.
I see some change was recently made to pythran's Makefile to allow
a more recent gast, but I wasn't able to install scipy until I also
updated pythran's requirements.txt. Patch below.
I don't know anything about pythran or gast but since this is in
the same spirit as the previous change, hopefully this is okay.
(ccing people who have touched these ports recently. I meant to
do that in my previous email too.)
--
James
diff /usr/ports
commit - d7c1d75e5fd33e47d5264aedbe792406a70d3bb6
path + /usr/ports
blob - 69e0cf448e660790fe826f76a0b9660fa5de50c4
file + lang/pythran/Makefile
--- lang/pythran/Makefile
+++ lang/pythran/Makefile
@@ -4,7 +4,7 @@ COMMENT = ahead of time compiler for numeric kernels
MODPY_EGG_VERSION = 0.15.0
DISTNAME = pythran-${MODPY_EGG_VERSION}
-REVISION = 1
+REVISION = 2
CATEGORIES = lang
blob - /dev/null
file + lang/pythran/patches/patch-requirements_txt (mode 644)
--- /dev/null
+++ lang/pythran/patches/patch-requirements_txt
@@ -0,0 +1,10 @@
+Index: requirements.txt
+--- requirements.txt.orig
++++ requirements.txt
+@@ -1,5 +1,5 @@
+ ply>=3.4
+ setuptools
+-gast~=0.5.0
++gast>=0.5.0
+ numpy
+ beniget~=0.4.0
the scipy port.
I see some change was recently made to pythran's Makefile to allow
a more recent gast, but I wasn't able to install scipy until I also
updated pythran's requirements.txt. Patch below.
I don't know anything about pythran or gast but since this is in
the same spirit as the previous change, hopefully this is okay.
(ccing people who have touched these ports recently. I meant to
do that in my previous email too.)
--
James
diff /usr/ports
commit - d7c1d75e5fd33e47d5264aedbe792406a70d3bb6
path + /usr/ports
blob - 69e0cf448e660790fe826f76a0b9660fa5de50c4
file + lang/pythran/Makefile
--- lang/pythran/Makefile
+++ lang/pythran/Makefile
@@ -4,7 +4,7 @@ COMMENT = ahead of time compiler for numeric kernels
MODPY_EGG_VERSION = 0.15.0
DISTNAME = pythran-${MODPY_EGG_VERSION}
-REVISION = 1
+REVISION = 2
CATEGORIES = lang
blob - /dev/null
file + lang/pythran/patches/patch-requirements_txt (mode 644)
--- /dev/null
+++ lang/pythran/patches/patch-requirements_txt
@@ -0,0 +1,10 @@
+Index: requirements.txt
+--- requirements.txt.orig
++++ requirements.txt
+@@ -1,5 +1,5 @@
+ ply>=3.4
+ setuptools
+-gast~=0.5.0
++gast>=0.5.0
+ numpy
+ beniget~=0.4.0
[fixing scipy 1/2] Update py-beniget to 0.4.2.post1
Currently when I run "make" in math/py-scypi, I see something like this:
* Getting build dependencies for wheel...
ERROR Missing dependencies:
pythran<0.16.0,>=0.14.0
gast~=0.5.0
pythran<0.16.0,>=0.14.0
beniget~=0.4.0 -> gast~=0.5.0
It seems both pythran and beniget have gast=~0.5.0 in requirements.txt,
which is violated by a recent update.
This patch updates py-beniget to a version with a looser requirement
for gast. I hope the "post1" is allowed in MODPY_EGG_VERSION; at
least, it is working for me.
--
James
diff /usr/ports
commit - d7c1d75e5fd33e47d5264aedbe792406a70d3bb6
path + /usr/ports
blob - f02fb9179314ed97bd1ea1fb098f14b792f68a78
file + devel/py-beniget/Makefile
--- devel/py-beniget/Makefile
+++ devel/py-beniget/Makefile
@@ -1,10 +1,9 @@
COMMENT = extract semantic information about static Python code
-MODPY_EGG_VERSION = 0.4.1
+MODPY_EGG_VERSION = 0.4.2.post1
DISTNAME = beniget-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 2
CATEGORIES = devel
blob - c76e2fe24fc56c2ff74b96104d574b657d6d2c60
file + devel/py-beniget/distinfo
--- devel/py-beniget/distinfo
+++ devel/py-beniget/distinfo
@@ -1,2 +1,2 @@
-SHA256 (beniget-0.4.1.tar.gz) = dVVLO4rQVTzi9gdifa09lcYMRBGJh1uY4JdSj44jrAw=
-SIZE (beniget-0.4.1.tar.gz) = 16277
+SHA256 (beniget-0.4.2.post1.tar.gz) = oCWFN+ZefhTsM6hoAvhlpmf5Sbtsc2RtVeQvfEWgUq4=
+SIZE (beniget-0.4.2.post1.tar.gz) = 32274
blob - bff6fd1fc7806d97803ef91413193bc659a8d580
file + devel/py-beniget/pkg/PLIST
--- devel/py-beniget/pkg/PLIST
+++ devel/py-beniget/pkg/PLIST
@@ -6,9 +6,18 @@ lib/python${MODPY_VERSION}/site-packages/beniget-${MOD
lib/python${MODPY_VERSION}/site-packages/beniget-${MODPY_EGG_VERSION}.dist-info/WHEEL
lib/python${MODPY_VERSION}/site-packages/beniget-${MODPY_EGG_VERSION}.dist-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/beniget/__init__.py
+lib/python${MODPY_VERSION}/site-packages/beniget/__main__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}beniget.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}beniget.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}ordered_set.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}ordered_set.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}version.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}version.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/beniget/beniget.py
+lib/python${MODPY_VERSION}/site-packages/beniget/ordered_set.py
+lib/python${MODPY_VERSION}/site-packages/beniget/version.py
* Getting build dependencies for wheel...
ERROR Missing dependencies:
pythran<0.16.0,>=0.14.0
gast~=0.5.0
pythran<0.16.0,>=0.14.0
beniget~=0.4.0 -> gast~=0.5.0
It seems both pythran and beniget have gast=~0.5.0 in requirements.txt,
which is violated by a recent update.
This patch updates py-beniget to a version with a looser requirement
for gast. I hope the "post1" is allowed in MODPY_EGG_VERSION; at
least, it is working for me.
--
James
diff /usr/ports
commit - d7c1d75e5fd33e47d5264aedbe792406a70d3bb6
path + /usr/ports
blob - f02fb9179314ed97bd1ea1fb098f14b792f68a78
file + devel/py-beniget/Makefile
--- devel/py-beniget/Makefile
+++ devel/py-beniget/Makefile
@@ -1,10 +1,9 @@
COMMENT = extract semantic information about static Python code
-MODPY_EGG_VERSION = 0.4.1
+MODPY_EGG_VERSION = 0.4.2.post1
DISTNAME = beniget-${MODPY_EGG_VERSION}
PKGNAME = py-${DISTNAME}
-REVISION = 2
CATEGORIES = devel
blob - c76e2fe24fc56c2ff74b96104d574b657d6d2c60
file + devel/py-beniget/distinfo
--- devel/py-beniget/distinfo
+++ devel/py-beniget/distinfo
@@ -1,2 +1,2 @@
-SHA256 (beniget-0.4.1.tar.gz) = dVVLO4rQVTzi9gdifa09lcYMRBGJh1uY4JdSj44jrAw=
-SIZE (beniget-0.4.1.tar.gz) = 16277
+SHA256 (beniget-0.4.2.post1.tar.gz) = oCWFN+ZefhTsM6hoAvhlpmf5Sbtsc2RtVeQvfEWgUq4=
+SIZE (beniget-0.4.2.post1.tar.gz) = 32274
blob - bff6fd1fc7806d97803ef91413193bc659a8d580
file + devel/py-beniget/pkg/PLIST
--- devel/py-beniget/pkg/PLIST
+++ devel/py-beniget/pkg/PLIST
@@ -6,9 +6,18 @@ lib/python${MODPY_VERSION}/site-packages/beniget-${MOD
lib/python${MODPY_VERSION}/site-packages/beniget-${MODPY_EGG_VERSION}.dist-info/WHEEL
lib/python${MODPY_VERSION}/site-packages/beniget-${MODPY_EGG_VERSION}.dist-info/top_level.txt
lib/python${MODPY_VERSION}/site-packages/beniget/__init__.py
+lib/python${MODPY_VERSION}/site-packages/beniget/__main__.py
${MODPY_COMMENT}lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}/
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__init__.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}__main__.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}beniget.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}beniget.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}ordered_set.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}ordered_set.${MODPY_PYC_MAGIC_TAG}pyc
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}version.${MODPY_PYC_MAGIC_TAG}${MODPY_PYOEXTENSION}
+lib/python${MODPY_VERSION}/site-packages/beniget/${MODPY_PYCACHE}version.${MODPY_PYC_MAGIC_TAG}pyc
lib/python${MODPY_VERSION}/site-packages/beniget/beniget.py
+lib/python${MODPY_VERSION}/site-packages/beniget/ordered_set.py
+lib/python${MODPY_VERSION}/site-packages/beniget/version.py
Re: Upgrade lang/ghc to 9.8.3 - now with arm64
James Turner <james@calminferno.net> writes:
> Also 9.8.4 was release :P
Thanks. My reading of the changelog indicates the changes aren't
important for us.
> Also 9.8.4 was release :P
Thanks. My reading of the changelog indicates the changes aren't
important for us.
new devel/llvm-openmp
Hi,
I need OpenMP for some other port I am working on. It is an extension
for gcc or clang. Currently I only need it for base clang, so I
build it from llvm 16.0.6 sources.
Comment:
LLVM OpenMP libraries
Description:
The OpenMP API supports multi-platform shared-memory parallel
programming in C/C++ and Fortran. The OpenMP API defines a portable,
scalable model with a simple and flexible interface for developing
parallel applications on platforms from the desktop to the
supercomputer.
ok to import?
bluhm
I need OpenMP for some other port I am working on. It is an extension
for gcc or clang. Currently I only need it for base clang, so I
build it from llvm 16.0.6 sources.
Comment:
LLVM OpenMP libraries
Description:
The OpenMP API supports multi-platform shared-memory parallel
programming in C/C++ and Fortran. The OpenMP API defines a portable,
scalable model with a simple and flexible interface for developing
parallel applications on platforms from the desktop to the
supercomputer.
ok to import?
bluhm
Re: PPPoE passthrough with "GigaHub" is very slow
I received an error for if_ethersubr.c and if_pppoe.c. The rest of the patches were successful.
router$ patch < pppoe_rx.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_ethersubr.c
|===================================================================
|RCS file: /cvs/src/sys/net/if_ethersubr.c,v
|diff -u -p -r1.293 if_ethersubr.c
|--- if_ethersubr.c 14 Feb 2024 22:41:48 -0000 1.293
|+++ if_ethersubr.c 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_ethersubr.c
Patching file ./sys/net/if_ethersubr.c using Plan A...
Hunk #1 failed at 561.
1 out of 1 hunks failed--saving rejects to ./sys/net/if_ethersubr.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_pppoe.c
|===================================================================
|RCS file: /cvs/src/sys/net/if_pppoe.c,v
|diff -u -p -r1.84 if_pppoe.c
|--- if_pppoe.c 26 Jun 2024 01:40:49 -0000 1.84
|+++ if_pppoe.c 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_pppoe.c
Patching file ./sys/net/if_pppoe.c using Plan A...
Hunk #1 succeeded at 42.
Hunk #2 failed at 126.
Hunk #3 succeeded at 179 with fuzz 1.
Hunk #4 failed at 214.
Hunk #5 failed at 245.
Hunk #6 failed at 260.
Hunk #7 failed at 294.
Hunk #8 failed at 310.
Hunk #9 succeeded at 341 with fuzz 1.
Hunk #10 failed at 648.
Hunk #11 failed at 661.
Hunk #12 failed at 684.
Hunk #13 succeeded at 726 with fuzz 1.
Hunk #14 failed at 882.
Hunk #15 failed at 1078.
Hunk #16 failed at 1116.
Hunk #17 failed at 1288.
Hunk #18 failed at 1331.
Hunk #19 failed at 1363.
Hunk #20 failed at 1391.
Hunk #21 failed at 1537.
Hunk #22 failed at 1569.
18 out of 22 hunks failed--saving rejects to ./sys/net/if_pppoe.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_pppoe.h
|===================================================================
|RCS file: /cvs/src/sys/net/if_pppoe.h,v
|diff -u -p -r1.8 if_pppoe.h
|--- if_pppoe.h 29 Jun 2022 09:08:07 -0000 1.8
|+++ if_pppoe.h 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_pppoe.h
Patching file ./sys/net/if_pppoe.h using Plan A...
Hunk #1 succeeded at 69.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_sppp.h
|===================================================================
|RCS file: /cvs/src/sys/net/if_sppp.h,v
|diff -u -p -r1.30 if_sppp.h
|--- if_sppp.h 17 Nov 2021 18:00:24 -0000 1.30
|+++ if_sppp.h 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_sppp.h
Patching file ./sys/net/if_sppp.h using Plan A...
Hunk #1 succeeded at 232.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_spppsubr.c
|===================================================================
|RCS file: /cvs/src/sys/net/if_spppsubr.c,v
|diff -u -p -r1.194 if_spppsubr.c
|--- if_spppsubr.c 22 Jun 2024 10:22:29 -0000 1.194
|+++ if_spppsubr.c 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_spppsubr.c
Patching file ./sys/net/if_spppsubr.c using Plan A...
Hunk #1 succeeded at 415.
done
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_ethersubr.c
|===================================================================
|RCS file: /cvs/src/sys/net/if_ethersubr.c,v
|diff -u -p -r1.293 if_ethersubr.c
|--- if_ethersubr.c 14 Feb 2024 22:41:48 -0000 1.293
|+++ if_ethersubr.c 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_ethersubr.c
Patching file ./sys/net/if_ethersubr.c using Plan A...
Hunk #1 failed at 561.
1 out of 1 hunks failed--saving rejects to ./sys/net/if_ethersubr.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_pppoe.c
|===================================================================
|RCS file: /cvs/src/sys/net/if_pppoe.c,v
|diff -u -p -r1.84 if_pppoe.c
|--- if_pppoe.c 26 Jun 2024 01:40:49 -0000 1.84
|+++ if_pppoe.c 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_pppoe.c
Patching file ./sys/net/if_pppoe.c using Plan A...
Hunk #1 succeeded at 42.
Hunk #2 failed at 126.
Hunk #3 succeeded at 179 with fuzz 1.
Hunk #4 failed at 214.
Hunk #5 failed at 245.
Hunk #6 failed at 260.
Hunk #7 failed at 294.
Hunk #8 failed at 310.
Hunk #9 succeeded at 341 with fuzz 1.
Hunk #10 failed at 648.
Hunk #11 failed at 661.
Hunk #12 failed at 684.
Hunk #13 succeeded at 726 with fuzz 1.
Hunk #14 failed at 882.
Hunk #15 failed at 1078.
Hunk #16 failed at 1116.
Hunk #17 failed at 1288.
Hunk #18 failed at 1331.
Hunk #19 failed at 1363.
Hunk #20 failed at 1391.
Hunk #21 failed at 1537.
Hunk #22 failed at 1569.
18 out of 22 hunks failed--saving rejects to ./sys/net/if_pppoe.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_pppoe.h
|===================================================================
|RCS file: /cvs/src/sys/net/if_pppoe.h,v
|diff -u -p -r1.8 if_pppoe.h
|--- if_pppoe.h 29 Jun 2022 09:08:07 -0000 1.8
|+++ if_pppoe.h 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_pppoe.h
Patching file ./sys/net/if_pppoe.h using Plan A...
Hunk #1 succeeded at 69.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_sppp.h
|===================================================================
|RCS file: /cvs/src/sys/net/if_sppp.h,v
|diff -u -p -r1.30 if_sppp.h
|--- if_sppp.h 17 Nov 2021 18:00:24 -0000 1.30
|+++ if_sppp.h 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_sppp.h
Patching file ./sys/net/if_sppp.h using Plan A...
Hunk #1 succeeded at 232.
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: if_spppsubr.c
|===================================================================
|RCS file: /cvs/src/sys/net/if_spppsubr.c,v
|diff -u -p -r1.194 if_spppsubr.c
|--- if_spppsubr.c 22 Jun 2024 10:22:29 -0000 1.194
|+++ if_spppsubr.c 30 Nov 2024 06:29:47 -0000
--------------------------
File to patch: ./sys/net/if_spppsubr.c
Patching file ./sys/net/if_spppsubr.c using Plan A...
Hunk #1 succeeded at 415.
done
On Mon, 2 Dec 2024 at 11:24, Brodey Dover <doverosx@gmail.com> wrote:
Thank you very much.
I'll look at applying the diff but it's been a while since I've done it.BrodeyOn Sun, 1 Dec 2024 at 17:48, David Gwynne <david@gwynne.id.au> wrote:On Wed, Nov 27, 2024 at 09:14:19AM -0500, Brodey Dover wrote:
> Thanks. The MTU is auto negotiated to 1492. max-mss is 1440 in pf.
>
> I don't think OpenBSD has netisr or an equivalent since I don't see
> anything in the sysctl list, but it was implemented in FreeBSD and has
> allowed a number of people to fully saturate the mutli-gig symmetrical
> connections offered by newer ISPs using PPPoE. I should add *ON
> mutli-core/slower speed CPUs".
the diff below might improve pppoe rx performance.
> On Wed, 27 Nov 2024 at 03:03, Christer Solskogen <
> christer.solskogen@gmail.com> wrote:
>
> > On Tue, Nov 26, 2024 at 10:59???PM Brodey Dover <doverosx@gmail.com> wrote:
> > >
> > > So my modem is too buggy to do any DMZ work, thank you ISP.
> > >
> > > But the modem does pull 2375/2375. That???s down/up, which is why I was
> > thinking there was a serious bottleneck on the OBSD side.
> > >
> >
> > It's at least 20 years since I used PPPoE, but I seem to remember that
> > I had to lower the MTU to get the full speed. 1492 if I remember
> > correctly.
> >
> > --
> > chs
Index: if_ethersubr.c
===================================================================
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
diff -u -p -r1.293 if_ethersubr.c
--- if_ethersubr.c 14 Feb 2024 22:41:48 -0000 1.293
+++ if_ethersubr.c 30 Nov 2024 06:29:47 -0000
@@ -561,7 +561,8 @@ ether_input(struct ifnet *ifp, struct mb
if (mq_enqueue(&pppoediscinq, m) == 0)
schednetisr(NETISR_PPPOE);
} else {
- if (mq_enqueue(&pppoeinq, m) == 0)
+ m = pppoe_vinput(ifp, m);
+ if (m != NULL && mq_enqueue(&pppoeinq, m) == 0)
schednetisr(NETISR_PPPOE);
}
return;
Index: if_pppoe.c
===================================================================
RCS file: /cvs/src/sys/net/if_pppoe.c,v
diff -u -p -r1.84 if_pppoe.c
--- if_pppoe.c 26 Jun 2024 01:40:49 -0000 1.84
+++ if_pppoe.c 30 Nov 2024 06:29:47 -0000
@@ -42,6 +42,8 @@
#include <sys/socket.h>
#include <sys/syslog.h>
#include <sys/ioctl.h>
+#include <sys/smr.h>
+#include <sys/percpu.h>
#include <net/if.h>
#include <net/if_var.h>
#include <net/if_types.h>
@@ -124,7 +126,9 @@ struct pppoe_softc {
struct sppp sc_sppp; /* contains a struct ifnet as first element */
LIST_ENTRY(pppoe_softc) sc_list;/* [K] */
unsigned int sc_eth_ifidx; /* [K] */
+ caddr_t sc_bpf;
+ SMR_LIST_ENTRY(pppoe_softc) sc_session_entry; /* [K] */
int sc_state; /* [K] discovery phase or session connected */
struct ether_addr sc_dest; /* [K] hardware address of concentrator */
u_int16_t sc_session; /* [K] PPPoE session id */
@@ -175,6 +179,7 @@ static struct pppoe_softc *pppoe_find_so
static struct mbuf *pppoe_get_mbuf(size_t len);
LIST_HEAD(pppoe_softc_head, pppoe_softc) pppoe_softc_list;
+SMR_LIST_HEAD(pppoe_softc_sessions, pppoe_softc) pppoe_sessions; /* [K] */
/* interface cloning */
int pppoe_clone_create(struct if_clone *, int);
@@ -209,9 +214,19 @@ void
pppoeattach(int count)
{
LIST_INIT(&pppoe_softc_list);
+ SMR_LIST_INIT(&pppoe_sessions);
if_clone_attach(&pppoe_cloner);
}
+static void
+pppoe_set_state(struct pppoe_softc *sc, int state)
+{
+ KERNEL_ASSERT_LOCKED();
+ if (sc->sc_state == PPPOE_STATE_SESSION)
+ SMR_LIST_REMOVE_LOCKED(sc, sc_session_entry);
+ sc->sc_state = state;
+}
+
/* Create a new interface. */
int
pppoe_clone_create(struct if_clone *ifc, int unit)
@@ -230,6 +245,8 @@ pppoe_clone_create(struct if_clone *ifc,
sc->sc_sppp.pp_if.if_hdrlen = sizeof(struct ether_header) + PPPOE_HEADERLEN;
sc->sc_sppp.pp_flags |= PP_KEEPALIVE; /* use LCP keepalive */
sc->sc_sppp.pp_framebytes = PPPOE_HEADERLEN; /* framing added to ppp packets */
+ sc->sc_sppp.pp_if.if_input = p2p_input;
+ sc->sc_sppp.pp_if.if_bpf_mtap = p2p_bpf_mtap;
sc->sc_sppp.pp_if.if_ioctl = pppoe_ioctl;
sc->sc_sppp.pp_if.if_start = pppoe_start;
sc->sc_sppp.pp_if.if_rtrequest = p2p_rtrequest;
@@ -243,11 +260,14 @@ pppoe_clone_create(struct if_clone *ifc,
/* init timer for interface watchdog */
timeout_set_proc(&sc->sc_timeout, pppoe_timeout, sc);
+ if_counters_alloc(&sc->sc_sppp.pp_if);
if_attach(&sc->sc_sppp.pp_if);
if_alloc_sadl(&sc->sc_sppp.pp_if);
sppp_attach(&sc->sc_sppp.pp_if);
#if NBPFILTER > 0
- bpfattach(&sc->sc_sppp.pp_if.if_bpf, &sc->sc_sppp.pp_if, DLT_PPP_ETHER, 0);
+ bpfattach(&sc->sc_bpf, &sc->sc_sppp.pp_if, DLT_PPP_ETHER, 0);
+ bpfattach(&sc->sc_sppp.pp_if.if_bpf, &sc->sc_sppp.pp_if,
+ DLT_LOOP, sizeof(uint32_t));
Re: Quick question regarding puffy
Hello,
Although this is offtopic I will respond to it quickly.
I wouldn't say protonmail is a good idea, in my opinion everything they
stand for is a lie. Firstly, email is not secure, some email servers
still do not use TLS, so a "privacy focused" mail server isn't always
beneficial. Secondly, if you don't use GPG proton can still read your
emails, you have their promise they won't (Google promises it doesn't
abuse your data either), and their GPG encryption requires you to give
their client your GPG private key, not secure or private in the
slightest (IMO). So you go to use your own client, and GPG encryp... oh
they block IMAP/SMTP unless you pay for it.
IMO, pick any mail provider which gives you a free email, has good spam
rating, and gives your IMAP/SMTP access, and then use GPG to encrypt
emails. If you want to be truly paranoid you can use something
like https://posteo.de/en (note: I have never used them, just heard good things from others about them, they are also paid).
As for self hosting (like I do), it is rather painful. Setup is
annoying enough, but the worst part is being filtered into spam by
every major email provider despite having spf, dkim, dmarc and rDNS with
good IP reputation, simply because you are a small mail server and not
one of the whitelisted big mail servers, its a headache.
Hope this helps.
Take care,
--
Polarian
GPG signature: 0770E5312238C760
Jabber/XMPP: polarian@icebound.dev
Although this is offtopic I will respond to it quickly.
I wouldn't say protonmail is a good idea, in my opinion everything they
stand for is a lie. Firstly, email is not secure, some email servers
still do not use TLS, so a "privacy focused" mail server isn't always
beneficial. Secondly, if you don't use GPG proton can still read your
emails, you have their promise they won't (Google promises it doesn't
abuse your data either), and their GPG encryption requires you to give
their client your GPG private key, not secure or private in the
slightest (IMO). So you go to use your own client, and GPG encryp... oh
they block IMAP/SMTP unless you pay for it.
IMO, pick any mail provider which gives you a free email, has good spam
rating, and gives your IMAP/SMTP access, and then use GPG to encrypt
emails. If you want to be truly paranoid you can use something
like https://posteo.de/en (note: I have never used them, just heard good things from others about them, they are also paid).
As for self hosting (like I do), it is rather painful. Setup is
annoying enough, but the worst part is being filtered into spam by
every major email provider despite having spf, dkim, dmarc and rDNS with
good IP reputation, simply because you are a small mail server and not
one of the whitelisted big mail servers, its a headache.
Hope this helps.
Take care,
--
Polarian
GPG signature: 0770E5312238C760
Jabber/XMPP: polarian@icebound.dev
Re: qBittorrent torrents stall after awhile
BUMP!
qBittorrent is still broken in -current.
Again, to repeat: it has been tested on multiple machines, on multiple
ISPs/internet networks, on multiple trackers, etc.
TL;DR: qBittorrent stalls - stops torrenting, after some time, on most if not
all torrents.
If I recall correctly some do not even start.
Peers seems to just drop off until 0.
Works perfectly fine on FreeBSD but FreeBSD sucks but also no I2P support on
it.
The rest of details is in the thread (read arhive, below is incomplete).
I do not command anyone to do anything, it is just sad to see this decent
project - program, not work on OpenBSD.
I am in no health condition do jack sh1!t about it, sadly.
All I can do is try and help in finding the problem.
We still do not know if it is a qBittorrent issue or a OpenBSD issue.
Does OpenBSD have some throttling for openfiles or something like that unless
like ran as root? IDK
Thanks
On Thu, Oct 24, 2024 at 06:14:15PM +0000, Anon Loli wrote:
> On Sat, Oct 19, 2024 at 12:46:00PM +0000, Anon Loli wrote:
> > On Wed, Oct 09, 2024 at 04:57:26PM +0000, Anon Loli wrote:
> > > On Wed, Oct 09, 2024 at 12:08:53AM +0000, Lucas Gabriel Vuotto wrote:
> > > > On Tue, Oct 08, 2024 at 09:17:43PM GMT, Anon Loli wrote:
> > > > > Interesting question!
> > > > > For the clearnet torrenting I tried the default /etc/pf.conf before, and it
> > > > > exhibits said behavior.. no idea if the rtables have anything to do with this
> > > > > and if they somehow change >> by default <<, but I will give it a try!
> > > >
> > > > Then it's most surely not the case. Creating and using a different
> > > > rtable(4) is an admin decision. If this your own platform and not a
> > > > shared host, then most likely you're using rtable 0.
> > > >
> > > > This doubt can be easily cleared by sharing the full output of `netstat
> > > > -R` and `id -R`. They look something like this:
> > > >
> > > > $ netstat -R
> > > > Rdomain 0
> > > > Interfaces: lo0 enc0 sec0 tap0 tap1 veb0 vport0 pflog0
> > > > Routing table: 0
> > > >
> > > > Rdomain 1
> > > > Interfaces: iwx0 em0 lo1
> > > > Routing table: 1
> > > >
> > > > Rdomain 2
> > > > Interfaces: wg2 lo2
> > > > Routing table: 2
> > > >
> > > > $ id -R
> > > > 0
> > > >
> > > >
> > > > > I will be testing the setup with what the manual for rtable(4) provides:
> > > > > > route -T0 exec /usr/local/bin/qbittorrent
> > > >
> > > > In most scenarios and setups, rtable 0 is the default and that command
> > > > has no effect. As said, `id -R` will clear this up.
> > >
> > > Well... fuck.
> > > There goes my hope, out of the window. Can you see it?
> > >
> > > What now?
> > > I got a littel bit more info on this main bug.
> > >
> > > After some time, if there have even be any peers, they disconnect, seemingly
> > > all at once.
> > > This happens from after 10 minuts, up to like 1 hour sometimes.
> > > I think that peers drop off slowly until all of my torrents are dead.
> > > Slow in this case would be 1 every few dozen seconds.
> > > By "drop", I mean drop off the Peers list.
> > >
> > > But then, also seemingly... a little bit of traffic comes back for a short and
> > > slow while, then also disapears.
> > >
> > > Here's a stupid graph that I manually made attached as "qb-bug".
> >
> > I not only tested on another computer, but also on a new drive.
> >
> > The BOTH issues persist.
> > The restarting downloaded progress might be just from using (p)kill on
> > qbittorrent and that somehow makes it unstable.
> >
> > The issue of poor variable or non-existent speed might also be there for other
> > networking-heavy programs, meaning it might not even be qbittorrent-specific.
> > Again, everything points to something on OpenBSD...
> > I have tried on:
> > - different computers
> > - different disks
> > - different network
> > - different ways to access the network: wired/wireless
> >
> > *it has to be* something in OpenBSD.
> > What the fu can do that, since OpenBSD aims to be very good when it comes to
> > networking - some ISPs use OpenBSD for networking.
> >
> > I do not mean to shit on OpenBSD or developers, but everything points to this..
> > What else can it be? What user error?
> > Actually maybe I'm onto something... it might even be user error after all?
> >
> > Perhps it could be this:
> > both of the computer I tested on were low-end, and I tried increasing the max
> > number of connections which seemingly decreased the time before the big
> > no-speed bug occured, meaning it occured way faster.
> >
> > Perhaps it's something related to some limit like openfiles?
> > I did have openfiles increased on both machines.
> > And if I recall correctly, I was warned of increasing the limit and also
> > arguing as to why the limit is that low by default and wether or not a
> > automatic utility for extracting the maximum limit for openfiles and similar.
> >
> > Again, time will tell, I will decrease the limit to what I think was the
> > original one shown at-boot.
> >
> > While I'm at it: I forgot where I can find the information printed at-boot
> > that's similar to dmesg?
> > I tried grepping the entire /var/ for openfiles, but I can't find it...
> > I'd like to know.
>
>
> Nope... the default 7030 seems to not change anything, really.
> I am out of ideas and it sucks that there is no --verbose option!
>
> Why do peers keep on expiring?
> Do they become unreachable? HOW
>
> I also tried changing the port, it did nothing.
> What's interesting is that it like opens up a liiiiiiiittle bit and then closes
> back up... what the bug can make for that behavior?
--
Anon Loli
#########
This mortal strives for omnisciency. Some tags: perfectionist, minimalist,
researcher, scientist, philosopher, developer, autist, anarchist, data hoarder,
99 other tags and interests.
I am always up for conversing as long as you meet these requirements:
1. Use PGP encryption for all data shared,
2. Use a open source operating system, NOT Windows, NOT MacOS,
3. Have a open mind - are ready to let go of any and all imperfect views on
anything, if they are.
Let's change this world for the better, one action at a time
########################
PGP fingerprint: AE35FC867EAB1A7450E5CCA27630FFBD6BB466B8
AE35 FC86 7EAB 1A74 50E5 CCA2 7630 FFBD 6BB4 66B8
<anonloli@autistici.org>
qBittorrent is still broken in -current.
Again, to repeat: it has been tested on multiple machines, on multiple
ISPs/internet networks, on multiple trackers, etc.
TL;DR: qBittorrent stalls - stops torrenting, after some time, on most if not
all torrents.
If I recall correctly some do not even start.
Peers seems to just drop off until 0.
Works perfectly fine on FreeBSD but FreeBSD sucks but also no I2P support on
it.
The rest of details is in the thread (read arhive, below is incomplete).
I do not command anyone to do anything, it is just sad to see this decent
project - program, not work on OpenBSD.
I am in no health condition do jack sh1!t about it, sadly.
All I can do is try and help in finding the problem.
We still do not know if it is a qBittorrent issue or a OpenBSD issue.
Does OpenBSD have some throttling for openfiles or something like that unless
like ran as root? IDK
Thanks
On Thu, Oct 24, 2024 at 06:14:15PM +0000, Anon Loli wrote:
> On Sat, Oct 19, 2024 at 12:46:00PM +0000, Anon Loli wrote:
> > On Wed, Oct 09, 2024 at 04:57:26PM +0000, Anon Loli wrote:
> > > On Wed, Oct 09, 2024 at 12:08:53AM +0000, Lucas Gabriel Vuotto wrote:
> > > > On Tue, Oct 08, 2024 at 09:17:43PM GMT, Anon Loli wrote:
> > > > > Interesting question!
> > > > > For the clearnet torrenting I tried the default /etc/pf.conf before, and it
> > > > > exhibits said behavior.. no idea if the rtables have anything to do with this
> > > > > and if they somehow change >> by default <<, but I will give it a try!
> > > >
> > > > Then it's most surely not the case. Creating and using a different
> > > > rtable(4) is an admin decision. If this your own platform and not a
> > > > shared host, then most likely you're using rtable 0.
> > > >
> > > > This doubt can be easily cleared by sharing the full output of `netstat
> > > > -R` and `id -R`. They look something like this:
> > > >
> > > > $ netstat -R
> > > > Rdomain 0
> > > > Interfaces: lo0 enc0 sec0 tap0 tap1 veb0 vport0 pflog0
> > > > Routing table: 0
> > > >
> > > > Rdomain 1
> > > > Interfaces: iwx0 em0 lo1
> > > > Routing table: 1
> > > >
> > > > Rdomain 2
> > > > Interfaces: wg2 lo2
> > > > Routing table: 2
> > > >
> > > > $ id -R
> > > > 0
> > > >
> > > >
> > > > > I will be testing the setup with what the manual for rtable(4) provides:
> > > > > > route -T0 exec /usr/local/bin/qbittorrent
> > > >
> > > > In most scenarios and setups, rtable 0 is the default and that command
> > > > has no effect. As said, `id -R` will clear this up.
> > >
> > > Well... fuck.
> > > There goes my hope, out of the window. Can you see it?
> > >
> > > What now?
> > > I got a littel bit more info on this main bug.
> > >
> > > After some time, if there have even be any peers, they disconnect, seemingly
> > > all at once.
> > > This happens from after 10 minuts, up to like 1 hour sometimes.
> > > I think that peers drop off slowly until all of my torrents are dead.
> > > Slow in this case would be 1 every few dozen seconds.
> > > By "drop", I mean drop off the Peers list.
> > >
> > > But then, also seemingly... a little bit of traffic comes back for a short and
> > > slow while, then also disapears.
> > >
> > > Here's a stupid graph that I manually made attached as "qb-bug".
> >
> > I not only tested on another computer, but also on a new drive.
> >
> > The BOTH issues persist.
> > The restarting downloaded progress might be just from using (p)kill on
> > qbittorrent and that somehow makes it unstable.
> >
> > The issue of poor variable or non-existent speed might also be there for other
> > networking-heavy programs, meaning it might not even be qbittorrent-specific.
> > Again, everything points to something on OpenBSD...
> > I have tried on:
> > - different computers
> > - different disks
> > - different network
> > - different ways to access the network: wired/wireless
> >
> > *it has to be* something in OpenBSD.
> > What the fu can do that, since OpenBSD aims to be very good when it comes to
> > networking - some ISPs use OpenBSD for networking.
> >
> > I do not mean to shit on OpenBSD or developers, but everything points to this..
> > What else can it be? What user error?
> > Actually maybe I'm onto something... it might even be user error after all?
> >
> > Perhps it could be this:
> > both of the computer I tested on were low-end, and I tried increasing the max
> > number of connections which seemingly decreased the time before the big
> > no-speed bug occured, meaning it occured way faster.
> >
> > Perhaps it's something related to some limit like openfiles?
> > I did have openfiles increased on both machines.
> > And if I recall correctly, I was warned of increasing the limit and also
> > arguing as to why the limit is that low by default and wether or not a
> > automatic utility for extracting the maximum limit for openfiles and similar.
> >
> > Again, time will tell, I will decrease the limit to what I think was the
> > original one shown at-boot.
> >
> > While I'm at it: I forgot where I can find the information printed at-boot
> > that's similar to dmesg?
> > I tried grepping the entire /var/ for openfiles, but I can't find it...
> > I'd like to know.
>
>
> Nope... the default 7030 seems to not change anything, really.
> I am out of ideas and it sucks that there is no --verbose option!
>
> Why do peers keep on expiring?
> Do they become unreachable? HOW
>
> I also tried changing the port, it did nothing.
> What's interesting is that it like opens up a liiiiiiiittle bit and then closes
> back up... what the bug can make for that behavior?
--
Anon Loli
#########
This mortal strives for omnisciency. Some tags: perfectionist, minimalist,
researcher, scientist, philosopher, developer, autist, anarchist, data hoarder,
99 other tags and interests.
I am always up for conversing as long as you meet these requirements:
1. Use PGP encryption for all data shared,
2. Use a open source operating system, NOT Windows, NOT MacOS,
3. Have a open mind - are ready to let go of any and all imperfect views on
anything, if they are.
Let's change this world for the better, one action at a time
########################
PGP fingerprint: AE35FC867EAB1A7450E5CCA27630FFBD6BB466B8
AE35 FC86 7EAB 1A74 50E5 CCA2 7630 FFBD 6BB4 66B8
<anonloli@autistici.org>
Re: Quick question regarding puffy
On Tue, Dec 03, 2024 at 05:37:00PM +0000, Rubén Llorente wrote:
> John wrote:
> Honestly I am a bit pissed off because we are discussing this subject which
> does not mean anything for the project and meanwhile we have unattended port
> submissions timing out in ports@.
True that..
Qbittorrent is still broken (tested on multiple machines, multiple
ISPs/internets, multiple torrents, multiple trackers, multiple fuxing
everything :( ).
Works very well on FreeBSD.
I'll re-bump the thread.
--
Anon Loli
#########
This mortal strives for omnisciency. Some tags: perfectionist, minimalist,
researcher, scientist, philosopher, developer, autist, anarchist, data hoarder,
99 other tags and interests.
I am always up for conversing as long as you meet these requirements:
1. Use PGP encryption for all data shared,
2. Use a open source operating system, NOT Windows, NOT MacOS,
3. Have a open mind - are ready to let go of any and all imperfect views on
anything, if they are.
Let's change this world for the better, one action at a time
########################
PGP fingerprint: AE35FC867EAB1A7450E5CCA27630FFBD6BB466B8
AE35 FC86 7EAB 1A74 50E5 CCA2 7630 FFBD 6BB4 66B8
<anonloli@autistici.org>
> John wrote:
> Honestly I am a bit pissed off because we are discussing this subject which
> does not mean anything for the project and meanwhile we have unattended port
> submissions timing out in ports@.
True that..
Qbittorrent is still broken (tested on multiple machines, multiple
ISPs/internets, multiple torrents, multiple trackers, multiple fuxing
everything :( ).
Works very well on FreeBSD.
I'll re-bump the thread.
--
Anon Loli
#########
This mortal strives for omnisciency. Some tags: perfectionist, minimalist,
researcher, scientist, philosopher, developer, autist, anarchist, data hoarder,
99 other tags and interests.
I am always up for conversing as long as you meet these requirements:
1. Use PGP encryption for all data shared,
2. Use a open source operating system, NOT Windows, NOT MacOS,
3. Have a open mind - are ready to let go of any and all imperfect views on
anything, if they are.
Let's change this world for the better, one action at a time
########################
PGP fingerprint: AE35FC867EAB1A7450E5CCA27630FFBD6BB466B8
AE35 FC86 7EAB 1A74 50E5 CCA2 7630 FFBD 6BB4 66B8
<anonloli@autistici.org>
Re: NEW: net/ergo
Ping, re-attached a new tarball with the GH_* way of specifying standard
GitHub archives, that wasn't particularly clear in the FAQ but I might
have missed something
On Sun Nov 24, 2024 at 05:10 CET, Brian Callahan wrote:
> On 11/23/2024 10:43 PM, Lydia Sobot wrote:
> > Hi,
> >
> > Attached is an up-to-date version of net/oragono, now called ergo
> > (https://ergo.chat), tested on arm64 for a little while and no apparent
> > issues. I can take up maintainership if it is desirable. I am not
> > entirely sure how to best shuffle around the configuration files and
> > examples in order to fit in with OpenBSD's layout, so please feel free
> > to edit the corresponding patches. Ok?
>
> This is something I ported quite a long time ago but I don't think ever
> got committed: https://marc.info/?l=openbsd-ports&m=156557936229322&w=2
>
> I'm guessing you got it from here:
> https://github.com/ibara/openbsd-ports-wip/tree/master/net/oragono
>
> By all means, take maintainer of it; anything in that repo should be
> taken, updated, and submitted by anyone interested--take maintainer of
> it, claim you wrote the port yourself, I'm good with all of that.
>
> ~Brian
GitHub archives, that wasn't particularly clear in the FAQ but I might
have missed something
On Sun Nov 24, 2024 at 05:10 CET, Brian Callahan wrote:
> On 11/23/2024 10:43 PM, Lydia Sobot wrote:
> > Hi,
> >
> > Attached is an up-to-date version of net/oragono, now called ergo
> > (https://ergo.chat), tested on arm64 for a little while and no apparent
> > issues. I can take up maintainership if it is desirable. I am not
> > entirely sure how to best shuffle around the configuration files and
> > examples in order to fit in with OpenBSD's layout, so please feel free
> > to edit the corresponding patches. Ok?
>
> This is something I ported quite a long time ago but I don't think ever
> got committed: https://marc.info/?l=openbsd-ports&m=156557936229322&w=2
>
> I'm guessing you got it from here:
> https://github.com/ibara/openbsd-ports-wip/tree/master/net/oragono
>
> By all means, take maintainer of it; anything in that repo should be
> taken, updated, and submitted by anyone interested--take maintainer of
> it, claim you wrote the port yourself, I'm good with all of that.
>
> ~Brian
Re: Quick question regarding puffy
OK, this is a good point, I was thinking lately
about getting a protonmail, but they do not
offer IMAP for free and now I know that they
encode everything in base64 my decision
not to pursue this is final.
On 03/12/2024 18:07, Stuart Henderson wrote:
> On 2024-12-03, Peter N. M. Hansteen <peter@bsdly.net> wrote:
>> It is worth keeping in mind, though, for the archives if nothing else, that
>> some frequent posters here also have a habit of activating auto-ignore mechanisms
>> in order to avoid seeing posts by users with high off-topic content.
> Fortunately a lot of these posters hide the contents themselves from
> some of us, by posting from some crappy "privacy" mail provider that
> b64encodes everything.
>
about getting a protonmail, but they do not
offer IMAP for free and now I know that they
encode everything in base64 my decision
not to pursue this is final.
On 03/12/2024 18:07, Stuart Henderson wrote:
> On 2024-12-03, Peter N. M. Hansteen <peter@bsdly.net> wrote:
>> It is worth keeping in mind, though, for the archives if nothing else, that
>> some frequent posters here also have a habit of activating auto-ignore mechanisms
>> in order to avoid seeing posts by users with high off-topic content.
> Fortunately a lot of these posters hide the contents themselves from
> some of us, by posting from some crappy "privacy" mail provider that
> b64encodes everything.
>
Re: Quick question regarding puffy
On Tue, Dec 03, 2024 at 07:03:23PM +0000, Polarian wrote:
> Hansteen:
>
> > some frequent posters here also have a habit of activating
> > auto-ignore mechanisms
>
> There is an auto-ignore mechanism? How do you trigger said mechanism?
> Is there any documentation on said mechanism?
>
> I haven't heard of it until now, and I have been subscribed to the list
> for a few years now :/
I am not an admin of any of the openbsd.org lists, so would not have
access to measures such as removing subscribers. The somewhat obscure
sentence is more of a pointer to the various local filtering features
we have at the client end. I must admit I have a (fortunately short)
list of senders whose messages I will not see unless I take specific
steps to do so.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
> Hansteen:
>
> > some frequent posters here also have a habit of activating
> > auto-ignore mechanisms
>
> There is an auto-ignore mechanism? How do you trigger said mechanism?
> Is there any documentation on said mechanism?
>
> I haven't heard of it until now, and I have been subscribed to the list
> for a few years now :/
I am not an admin of any of the openbsd.org lists, so would not have
access to measures such as removing subscribers. The somewhat obscure
sentence is more of a pointer to the various local filtering features
we have at the client end. I must admit I have a (fortunately short)
list of senders whose messages I will not see unless I take specific
steps to do so.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Quick question regarding puffy
Hello,
Firstly, sorry for breaking the threads, I see multiple different
threads coming off the original email but I would like to respond to
all of them at once so I am replying to the most recent email.
Secondly, I was originally not going to respond to this, as I am unable
to provide any advice (not an OpenBSD dev nor contributor) and usually
just lurk on the mailing list, however seen as nobody has responded to
the disruption with a good enough response (in my opinion), I want to
respond.
Gwen:
The logo looks cool, and seems to be very well made, congrats!
I personally believe it is important to make groups where people can fit
into better, we are all drawn to different groups so it is beneficial to
have more groups, so more people are drawn to OpenBSD.
You spotted an issue of lack of LGBTQ+ OpenBSD pubnix's and you have
attempted to solve that issue. I personally don't benefit from this in
any way (however I am sure if non-LGBTQ+ people were interested you
would let them join too?), but for those who would benefit, thank you
for your contribution to grow the OpenBSD community.
tux2bsd:
> Most BSD/GNU people are hard-line leftists
This is bullshit. I would agree with that it is the norm for GNU, but
for BSD I completely disagree and you are disregarding so many people
with this naive comment.
For decades, ISPs and hosting providers have built around OpenBSD, many
people on this list if you paid attention have their own businesses,
they might not be right, but they sure aren't "hard-line leftists".
What you are doing here is assuming that someones economic views
translate to their views on social issues, which is wrong, and
offtopic. By bringing up politics all you will do is alienate people.
> The ideology that has a hold over you demands the denial of reality.
> It strongly encourages the chemical and physical mutilation of
> children, young adults, and adults.
You have the freedom to believe whatever you like, and you are free to
oppose, however there's no excuse for blatant transphobic comments. You
had no reason to respond, you don't agree with it, you couldn't help
Gwen with their query, you should have simply not responded.
If you feel the need to make offensive remarks in the future, I
recommend you pipe it to /dev/null, you would be doing the entire list
a favour.
> Kind of related. The guy called "Solene", another they/them, was quite
> a fan of OpenBSD but felt it necessary to broadcast why he moved on:
> https://www.osnews.com/story/141170/
There's a different between general transphobia, and directly attacking
a member of the OpenBSD community. The former might be possible to
brush off as simply expression of your views (even if it is
offensive), the latter is a clear attack on a member and is
discrimination. If you are unable to be kind and respectful to everyone
within the community, then I advice you start looking for a different
community, I am sure the list agrees with me here, and you probably
have already been moderated.
Also maybe brush up on how you are expected to conduct yourself. [1]
Brodie:
> Apart from below info you are hitting trigger right here:
>
> https://www.openbsd.org/goals.html
>
> in particular line:
>
> Be as politics-free as possible; solutions should be decided on the
> basis of technical merit.
In defence of Gwen, this isn't something political. They did not come
to the list to express their political views or in any sort of
activism, they came to enquire about potential licencing issues because
they are forming a pubnix.
Its no different than a group of Germans coming together and forming a
German pubnix. Why should LGBTQ+ groups be treated any differently?
They aren't holding a gun to your head telling you that you must join
their pubnix and agree with their beliefs are they?
If someone came along and started asking about licencing issues because
they run a corporation and want to use OpenBSD within it, I doubt a
single person would have kicked up a fuss, despite it having
capitalistic intent.
Katherine:
> I am wondering about OpenBSD and Harry Potter: would these be
> complimentary or non-offending (to each other, probably very
> offensive generally) "perceived cults"? I find it interesting that
> people that discuss cults tend to have no formal training in the
> humanities. Anyway, I ask because I was thinking of wearing my
> Ravenclaw robe to an OpenBSD event and don't want to seem like I'm
> representing the wrong community/ideology.
Very good example. Do you actually have a Ravenclaw robe?
Hansteen:
> some frequent posters here also have a habit of activating
> auto-ignore mechanisms
There is an auto-ignore mechanism? How do you trigger said mechanism?
Is there any documentation on said mechanism?
I haven't heard of it until now, and I have been subscribed to the list
for a few years now :/
Izzy:
> Like others have mentioned- this could technically be considered
> "political".
>
> However, thats the least of my concerns as social science is not
> political science. I would only consider this "politicised" in recent
> times, rather than "political".
See my response to Brodie, and I believe Katherine was making the same
point too, just with a much better analogy than me.
John:
> If the OpenBSD Foundation want to avoid 'party political' - sure,
> understandable. But 'anything' political? Impossible.
To build on this point, I was actually thinking about this just
yesterday. It seems to be impossible to share your views on anything
without some hint of your political opinions coming through.
For example, say someone supports self hosting and decentralisation, you
can usually infer that they sit somewhere in the Libertarian spectrum,
then if they complain about corporate decentralised software and
advocate for community led decentralised projects, you could quite
reliably place them within the left-libertarian wing of politics, even
though they were only discussing tech-related content, their political
views seep through.
The aim of the policy, I would assume, is it limit/eliminate DIRECT
political discussions, not eliminate anything which could have some
indirect political motive. Gwen was simply seeking licencing advice for
one of their projects, just because that project could potentially have
a political nature doesn't mean the intent was political.
> Good luck with the project, Gwen.
+1
> In my opinion, a gay event has the same political weight a Muslim
> event or a Christian event has. I'd argue there is a lot of Muslim
> and Christian political activity which is not partisan either, but
> only people with an agenda would argue they have no political goals.
And if Muslims/Christians come together and form a BSD pubnix, who the
fuck would care?
Gatekeeping the community on what they can and can't do with OpenBSD is
the complete opposite of freedom.
The majority of the emails on this thread were redundant, most of them
were in response to tux2bsd's offensive remarks, which shows just how
one off topic, offensive comment can cause a thread to spiral off
topic. If you have something unproductive, or offensive to say, best to
leave the email in your drafts.
> Honestly I am a bit pissed off because we are discussing this subject
> which does not mean anything for the project and meanwhile we have
> unattended port submissions timing out in ports@.
Please clarify what you are pissed off at, the redundant responses
caused by an offensive comment? Or the fact someone seeked advice for
one of their projects?
If it was the former, then I agree, "shut up and hack", if it was the
latter, then I disagree, Gwen's outreach is just as important,
pointless developing an operating system and porting software without a
community to use it and contribute.
I apologise for the rather long email, however it pissed me off that
someone who was simply trying to form a pubnix was being attacked for
trying to solve an issue they discovered. Outreach is just as important
as development, Gwens efforts to bring more people to OpenBSD should be
congratulated, not insulted! Have some respect for your peers.
Good luck Gwen, I hope you get the answers you need from someone who is
actually able to help, and good luck with the pubnix.
Take care all,
--
Polarian
GPG signature: 0770E5312238C760
Jabber/XMPP: polarian@icebound.dev
[1] https://www.openbsd.org/mail.html
Firstly, sorry for breaking the threads, I see multiple different
threads coming off the original email but I would like to respond to
all of them at once so I am replying to the most recent email.
Secondly, I was originally not going to respond to this, as I am unable
to provide any advice (not an OpenBSD dev nor contributor) and usually
just lurk on the mailing list, however seen as nobody has responded to
the disruption with a good enough response (in my opinion), I want to
respond.
Gwen:
The logo looks cool, and seems to be very well made, congrats!
I personally believe it is important to make groups where people can fit
into better, we are all drawn to different groups so it is beneficial to
have more groups, so more people are drawn to OpenBSD.
You spotted an issue of lack of LGBTQ+ OpenBSD pubnix's and you have
attempted to solve that issue. I personally don't benefit from this in
any way (however I am sure if non-LGBTQ+ people were interested you
would let them join too?), but for those who would benefit, thank you
for your contribution to grow the OpenBSD community.
tux2bsd:
> Most BSD/GNU people are hard-line leftists
This is bullshit. I would agree with that it is the norm for GNU, but
for BSD I completely disagree and you are disregarding so many people
with this naive comment.
For decades, ISPs and hosting providers have built around OpenBSD, many
people on this list if you paid attention have their own businesses,
they might not be right, but they sure aren't "hard-line leftists".
What you are doing here is assuming that someones economic views
translate to their views on social issues, which is wrong, and
offtopic. By bringing up politics all you will do is alienate people.
> The ideology that has a hold over you demands the denial of reality.
> It strongly encourages the chemical and physical mutilation of
> children, young adults, and adults.
You have the freedom to believe whatever you like, and you are free to
oppose, however there's no excuse for blatant transphobic comments. You
had no reason to respond, you don't agree with it, you couldn't help
Gwen with their query, you should have simply not responded.
If you feel the need to make offensive remarks in the future, I
recommend you pipe it to /dev/null, you would be doing the entire list
a favour.
> Kind of related. The guy called "Solene", another they/them, was quite
> a fan of OpenBSD but felt it necessary to broadcast why he moved on:
> https://www.osnews.com/story/141170/
There's a different between general transphobia, and directly attacking
a member of the OpenBSD community. The former might be possible to
brush off as simply expression of your views (even if it is
offensive), the latter is a clear attack on a member and is
discrimination. If you are unable to be kind and respectful to everyone
within the community, then I advice you start looking for a different
community, I am sure the list agrees with me here, and you probably
have already been moderated.
Also maybe brush up on how you are expected to conduct yourself. [1]
Brodie:
> Apart from below info you are hitting trigger right here:
>
> https://www.openbsd.org/goals.html
>
> in particular line:
>
> Be as politics-free as possible; solutions should be decided on the
> basis of technical merit.
In defence of Gwen, this isn't something political. They did not come
to the list to express their political views or in any sort of
activism, they came to enquire about potential licencing issues because
they are forming a pubnix.
Its no different than a group of Germans coming together and forming a
German pubnix. Why should LGBTQ+ groups be treated any differently?
They aren't holding a gun to your head telling you that you must join
their pubnix and agree with their beliefs are they?
If someone came along and started asking about licencing issues because
they run a corporation and want to use OpenBSD within it, I doubt a
single person would have kicked up a fuss, despite it having
capitalistic intent.
Katherine:
> I am wondering about OpenBSD and Harry Potter: would these be
> complimentary or non-offending (to each other, probably very
> offensive generally) "perceived cults"? I find it interesting that
> people that discuss cults tend to have no formal training in the
> humanities. Anyway, I ask because I was thinking of wearing my
> Ravenclaw robe to an OpenBSD event and don't want to seem like I'm
> representing the wrong community/ideology.
Very good example. Do you actually have a Ravenclaw robe?
Hansteen:
> some frequent posters here also have a habit of activating
> auto-ignore mechanisms
There is an auto-ignore mechanism? How do you trigger said mechanism?
Is there any documentation on said mechanism?
I haven't heard of it until now, and I have been subscribed to the list
for a few years now :/
Izzy:
> Like others have mentioned- this could technically be considered
> "political".
>
> However, thats the least of my concerns as social science is not
> political science. I would only consider this "politicised" in recent
> times, rather than "political".
See my response to Brodie, and I believe Katherine was making the same
point too, just with a much better analogy than me.
John:
> If the OpenBSD Foundation want to avoid 'party political' - sure,
> understandable. But 'anything' political? Impossible.
To build on this point, I was actually thinking about this just
yesterday. It seems to be impossible to share your views on anything
without some hint of your political opinions coming through.
For example, say someone supports self hosting and decentralisation, you
can usually infer that they sit somewhere in the Libertarian spectrum,
then if they complain about corporate decentralised software and
advocate for community led decentralised projects, you could quite
reliably place them within the left-libertarian wing of politics, even
though they were only discussing tech-related content, their political
views seep through.
The aim of the policy, I would assume, is it limit/eliminate DIRECT
political discussions, not eliminate anything which could have some
indirect political motive. Gwen was simply seeking licencing advice for
one of their projects, just because that project could potentially have
a political nature doesn't mean the intent was political.
> Good luck with the project, Gwen.
+1
> In my opinion, a gay event has the same political weight a Muslim
> event or a Christian event has. I'd argue there is a lot of Muslim
> and Christian political activity which is not partisan either, but
> only people with an agenda would argue they have no political goals.
And if Muslims/Christians come together and form a BSD pubnix, who the
fuck would care?
Gatekeeping the community on what they can and can't do with OpenBSD is
the complete opposite of freedom.
The majority of the emails on this thread were redundant, most of them
were in response to tux2bsd's offensive remarks, which shows just how
one off topic, offensive comment can cause a thread to spiral off
topic. If you have something unproductive, or offensive to say, best to
leave the email in your drafts.
> Honestly I am a bit pissed off because we are discussing this subject
> which does not mean anything for the project and meanwhile we have
> unattended port submissions timing out in ports@.
Please clarify what you are pissed off at, the redundant responses
caused by an offensive comment? Or the fact someone seeked advice for
one of their projects?
If it was the former, then I agree, "shut up and hack", if it was the
latter, then I disagree, Gwen's outreach is just as important,
pointless developing an operating system and porting software without a
community to use it and contribute.
I apologise for the rather long email, however it pissed me off that
someone who was simply trying to form a pubnix was being attacked for
trying to solve an issue they discovered. Outreach is just as important
as development, Gwens efforts to bring more people to OpenBSD should be
congratulated, not insulted! Have some respect for your peers.
Good luck Gwen, I hope you get the answers you need from someone who is
actually able to help, and good luck with the pubnix.
Take care all,
--
Polarian
GPG signature: 0770E5312238C760
Jabber/XMPP: polarian@icebound.dev
[1] https://www.openbsd.org/mail.html
Re: Upgrade lang/ghc to 9.8.3 - now with arm64
On Tue, Dec 03, 2024 at 09:20:07AM -0800, Greg Steuck wrote:
> Matthias Kilian <kili@outback.escape.de> writes:
>
> >> I had to repack the amd64 bootstraps because I previously had the wrong
> >> date inside the archive. Matthias, would you mind picking up the new
> >> tarballs from my cvs dir?
> >
> > Done. Checksums for all files (still the old hadrian-sources, I hope
> > that's ok):
> >
> > SHA256 (ghc-9.8.3.20241111-aarch64.tar.xz) = xsS7rBvdK4Mll7L+4nrGG0PlOUbNfuZ1iszYX6SBgsM=
> > SHA256 (ghc-9.8.3.20241111-amd64.tar.xz) = hu2fWQxl241tXZHQ0ZUIDEKMj8MMeLZU42OvXE2Azj0=
> > SHA256 (ghc-9.8.3.20241111-shlibs-aarch64.tar.gz) = HyB7YP0jVa69Ec9hG/SjO/p80I/usZ0DozKv/nyl8JE=
> > SHA256 (ghc-9.8.3.20241111-shlibs-amd64.tar.gz) = f8ngJzFpzjeCvlFaLptKVKFpUJMlzbvZ0Rqz14CRUvs=
> > SHA256 (hadrian-sources-9.8.3.20241111.tar.gz) = c/bii6wxSimhWh4eq/FI7+3FS/DjTkJDd7RilEPDKJE=
>
> Thanks, these are all good. I rebuilt the dependency universe of ghc on
> amd64 and arm64 now. Even tested xmonad on arm64. Should we make this
> available to the rest of the world now?
>
> OK? Also need an OK on git-annex update.
>
> Thanks
> Greg
>
ok jturner@
Also 9.8.4 was release :P
> Matthias Kilian <kili@outback.escape.de> writes:
>
> >> I had to repack the amd64 bootstraps because I previously had the wrong
> >> date inside the archive. Matthias, would you mind picking up the new
> >> tarballs from my cvs dir?
> >
> > Done. Checksums for all files (still the old hadrian-sources, I hope
> > that's ok):
> >
> > SHA256 (ghc-9.8.3.20241111-aarch64.tar.xz) = xsS7rBvdK4Mll7L+4nrGG0PlOUbNfuZ1iszYX6SBgsM=
> > SHA256 (ghc-9.8.3.20241111-amd64.tar.xz) = hu2fWQxl241tXZHQ0ZUIDEKMj8MMeLZU42OvXE2Azj0=
> > SHA256 (ghc-9.8.3.20241111-shlibs-aarch64.tar.gz) = HyB7YP0jVa69Ec9hG/SjO/p80I/usZ0DozKv/nyl8JE=
> > SHA256 (ghc-9.8.3.20241111-shlibs-amd64.tar.gz) = f8ngJzFpzjeCvlFaLptKVKFpUJMlzbvZ0Rqz14CRUvs=
> > SHA256 (hadrian-sources-9.8.3.20241111.tar.gz) = c/bii6wxSimhWh4eq/FI7+3FS/DjTkJDd7RilEPDKJE=
>
> Thanks, these are all good. I rebuilt the dependency universe of ghc on
> amd64 and arm64 now. Even tested xmonad on arm64. Should we make this
> available to the rest of the world now?
>
> OK? Also need an OK on git-annex update.
>
> Thanks
> Greg
>
ok jturner@
Also 9.8.4 was release :P
Re: Dell SB522A USB audio device not working
Hi,
On Tue, Dec 03, 2024 at 08:59:29AM GMT, Alexandre Ratchov wrote:
> Hi,
>
> Could you do this quick test please: make sure no program will try to
> open /dev/audio1 (ex. stop sndiod), plug the device and try to dump
> the mixer controls:
>
> doas mixerctl -f /dev/audioctl1 -v
>
> then, try to set one for the controls. Does it work?
This works without dmesg outputs.
$ doas mixerctl -f /dev/audioctl1 -v
outputs.dac=255
outputs.dac_mute=off [ off on ]
inputs.record=255
inputs.record_mute=off [ off on ]
record.enable=sysctl [ off on sysctl ]
$ doas mixerctl -f /dev/audioctl1 -v outputs.dac=128
outputs.dac: 255 -> 128
$ doas mixerctl -f /dev/audioctl1 -v
outputs.dac=128
outputs.dac_mute=off [ off on ]
inputs.record=255
inputs.record_mute=off [ off on ]
record.enable=sysctl [ off on sysctl ]
>
> If it does, play few samples (silence):
>
> doas dd of=/dev/audio1 </dev/zero
>
> Do you get the same error in dmesg? If so, unplug and plug the device
> and retry. Still get the error?
While running dd, I got no dmesg messages.
$ doas dd of=/dev/audio1 </dev/zero
^C8551+0 records in
8550+0 records out
4377600 bytes transferred in 27.775 secs (157609 bytes/sec)
But since I ^C the dd command, I get an error.
uaudio0: can't reset interface
Same error happens if I unplug and plug back the device.
>
> If so does the mixer still works (try above mixerctl commands)?
>
Since the error happens, mixerctl command fail after a couple of
seconds:
$ doas mixerctl -f /dev/audioctl1 -v
mixerctl: AUDIO_MIXER_READ: Input/output error
Thanks,
Joel C.
> This is to see if a mixer request could be the cause of the error.
>
> Thank you
>
> On Tue, Dec 03, 2024 at 12:13:14AM +0100, Joel Carnat wrote:
> > Hi,
> >
> > I just got a Dell Slim (USB) Soundbar SB522A and it seems to not be
> > functionnal on OpenBSD 7.6 (and latest snapshot available tonight). I
> > have tested in on Windows 11 and FreeBSD 14.1 and it works as expected.
> >
> > Here's what dmesg says when I plug it in:
> > umodem0 at uhub1 port 7 configuration 1 interface 0 "DELL DELL Slim Soundbar SB522A" rev 2.00/0.00 addr 5
> > umodem0: data interface 1, has no CM over data, has no break
> > umodem0: status change notification available
> > ucom0 at umodem0: usb1.0.00007.1
> > uaudio0 at uhub1 port 7 configuration 1 interface 3 "DELL DELL Slim Soundbar SB522A" rev 2.00/0.00 addr 5
> > uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 4 ctls
> > audio1 at uaudio0
> > uhidev0 at uhub1 port 7 configuration 1 interface 5 "DELL DELL Slim Soundbar SB522A" rev 2.00/0.00 addr 5
> > uhidev0: iclass 3/0, 185 report ids
> > ucc0 at uhidev0 reportid 1: 3 usages, 3 keys, enum
> > wskbd1 at ucc0 mux 1
> > wskbd1: connecting to wsdisplay0
> > uhid0 at uhidev0 reportid 5: input=1, output=1, feature=0
> > uhid1 at uhidev0 reportid 154: input=0, output=0, feature=63
> > uhid2 at uhidev0 reportid 155: input=2, output=0, feature=0
> > uhid3 at uhidev0 reportid 184: input=63, output=0, feature=0
> > uhid4 at uhidev0 reportid 185: input=0, output=63, feature=0
> >
> > Reading the Multimedia FAQ, I did:
> > $ doas rcctl set sndiod flags -f rsnd/0 -F rsnd/1
> > $ doas rcctl restart sndiod
> >
> > Then using mpv to play a video, it freezes a few seconds before
> > starting, the sound gets out of the laptop speaker (and not the USB
> > soundbar). dmesg adds:
> > uaudio0: can't reset interface
> > uaudio0: can't reset interface
> >
> > sndioctl also takes a few seconds to output things:
> > $ sndioctl -v
> > output.level=1.000
> > server.device=1
> > app/mpv0.level=1.000
> > $ sndioctl -d
> > 013:output.level=0..127 (127)
> > 011:server.device=0(azalia0)
> > 012:server.device=1
> > 001:mpv0.level=0..127 (127)
> >
> > Here's a few more outputs:
> > $ doas mixerctl -v
> > inputs.dac-2:3=128,128
> > inputs.dac-0:1=128,128
> > record.adc-0:1_mute=off [ off on ]
> > record.adc-0:1=192,192
> > record.adc-2:3_mute=off [ off on ]
> > record.adc-2:3=192,192
> > outputs.spkr_source=dac-2:3 [ dac-2:3 ]
> > outputs.spkr_mute=off [ off on ]
> > outputs.spkr_eapd=on [ off on ]
> > outputs.spkr2_source=dac-2:3 [ dac-2:3 dac-0:1 adc-0:1 ]
> > outputs.spkr2_mute=off [ off on ]
> > outputs.spkr2_boost=off [ off on ]
> > inputs.mic=170,170
> > outputs.mic_dir=input-vr80 [ none input input-vr0 input-vr50 input-vr80 input-vr100 ]
> > outputs.hp_source=dac-0:1 [ dac-2:3 dac-0:1 ]
> > outputs.hp_mute=off [ off on ]
> > outputs.hp_boost=off [ off on ]
> > outputs.hp_eapd=on [ off on ]
> > record.adc-2:3_source=mic { mic }
> > record.adc-0:1_source=mic { mic }
> > outputs.mic_sense=unplugged [ unplugged plugged ]
> > outputs.hp_sense=unplugged [ unplugged plugged ]
> > outputs.spkr_muters=hp { hp }
> > outputs.master=128,128
> > outputs.master.mute=off [ off on ]
> > outputs.master.slaves=dac-2:3,dac-0:1,spkr,spkr2,hp { dac-2:3 dac-0:1 spkr spkr2 hp }
> > record.volume=192,192
> > record.volume.mute=off [ off on ]
> > record.volume.slaves=adc-0:1,adc-2:3 { adc-0:1 adc-2:3 mic }
> > record.enable=sysctl [ off on sysctl ]
> > $ doas usbdevs
> > Controller /dev/usb0:
> > addr 01: 8086:0000 Intel, xHCI root hub
> > Controller /dev/usb1:
> > addr 01: 8086:0000 Intel, xHCI root hub
> > addr 02: 06cb:00fc Synaptics, product 0x00fc
> > addr 03: 174f:1813 , Integrated Camera
> > addr 04: 8087:0033 Intel, Bluetooth
> > addr 05: 413c:8204 DELL, DELL Slim Soundbar SB522A
> > $ doas usbdevs -v -a 05
> > addr 05: 413c:8204 DELL, DELL Slim Soundbar SB522A
> > full speed, power 500 mA, config 1, rev 0.00, iSerial 0
> > driver: umodem0
> > driver: uaudio0
> > driver: uhidev0
> >
> > Am I missing something?
> >
> > Thanks,
> > Joel C.
> >
> >
>
--
Bonne journée,
Joel C.
On Tue, Dec 03, 2024 at 08:59:29AM GMT, Alexandre Ratchov wrote:
> Hi,
>
> Could you do this quick test please: make sure no program will try to
> open /dev/audio1 (ex. stop sndiod), plug the device and try to dump
> the mixer controls:
>
> doas mixerctl -f /dev/audioctl1 -v
>
> then, try to set one for the controls. Does it work?
This works without dmesg outputs.
$ doas mixerctl -f /dev/audioctl1 -v
outputs.dac=255
outputs.dac_mute=off [ off on ]
inputs.record=255
inputs.record_mute=off [ off on ]
record.enable=sysctl [ off on sysctl ]
$ doas mixerctl -f /dev/audioctl1 -v outputs.dac=128
outputs.dac: 255 -> 128
$ doas mixerctl -f /dev/audioctl1 -v
outputs.dac=128
outputs.dac_mute=off [ off on ]
inputs.record=255
inputs.record_mute=off [ off on ]
record.enable=sysctl [ off on sysctl ]
>
> If it does, play few samples (silence):
>
> doas dd of=/dev/audio1 </dev/zero
>
> Do you get the same error in dmesg? If so, unplug and plug the device
> and retry. Still get the error?
While running dd, I got no dmesg messages.
$ doas dd of=/dev/audio1 </dev/zero
^C8551+0 records in
8550+0 records out
4377600 bytes transferred in 27.775 secs (157609 bytes/sec)
But since I ^C the dd command, I get an error.
uaudio0: can't reset interface
Same error happens if I unplug and plug back the device.
>
> If so does the mixer still works (try above mixerctl commands)?
>
Since the error happens, mixerctl command fail after a couple of
seconds:
$ doas mixerctl -f /dev/audioctl1 -v
mixerctl: AUDIO_MIXER_READ: Input/output error
Thanks,
Joel C.
> This is to see if a mixer request could be the cause of the error.
>
> Thank you
>
> On Tue, Dec 03, 2024 at 12:13:14AM +0100, Joel Carnat wrote:
> > Hi,
> >
> > I just got a Dell Slim (USB) Soundbar SB522A and it seems to not be
> > functionnal on OpenBSD 7.6 (and latest snapshot available tonight). I
> > have tested in on Windows 11 and FreeBSD 14.1 and it works as expected.
> >
> > Here's what dmesg says when I plug it in:
> > umodem0 at uhub1 port 7 configuration 1 interface 0 "DELL DELL Slim Soundbar SB522A" rev 2.00/0.00 addr 5
> > umodem0: data interface 1, has no CM over data, has no break
> > umodem0: status change notification available
> > ucom0 at umodem0: usb1.0.00007.1
> > uaudio0 at uhub1 port 7 configuration 1 interface 3 "DELL DELL Slim Soundbar SB522A" rev 2.00/0.00 addr 5
> > uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 4 ctls
> > audio1 at uaudio0
> > uhidev0 at uhub1 port 7 configuration 1 interface 5 "DELL DELL Slim Soundbar SB522A" rev 2.00/0.00 addr 5
> > uhidev0: iclass 3/0, 185 report ids
> > ucc0 at uhidev0 reportid 1: 3 usages, 3 keys, enum
> > wskbd1 at ucc0 mux 1
> > wskbd1: connecting to wsdisplay0
> > uhid0 at uhidev0 reportid 5: input=1, output=1, feature=0
> > uhid1 at uhidev0 reportid 154: input=0, output=0, feature=63
> > uhid2 at uhidev0 reportid 155: input=2, output=0, feature=0
> > uhid3 at uhidev0 reportid 184: input=63, output=0, feature=0
> > uhid4 at uhidev0 reportid 185: input=0, output=63, feature=0
> >
> > Reading the Multimedia FAQ, I did:
> > $ doas rcctl set sndiod flags -f rsnd/0 -F rsnd/1
> > $ doas rcctl restart sndiod
> >
> > Then using mpv to play a video, it freezes a few seconds before
> > starting, the sound gets out of the laptop speaker (and not the USB
> > soundbar). dmesg adds:
> > uaudio0: can't reset interface
> > uaudio0: can't reset interface
> >
> > sndioctl also takes a few seconds to output things:
> > $ sndioctl -v
> > output.level=1.000
> > server.device=1
> > app/mpv0.level=1.000
> > $ sndioctl -d
> > 013:output.level=0..127 (127)
> > 011:server.device=0(azalia0)
> > 012:server.device=1
> > 001:mpv0.level=0..127 (127)
> >
> > Here's a few more outputs:
> > $ doas mixerctl -v
> > inputs.dac-2:3=128,128
> > inputs.dac-0:1=128,128
> > record.adc-0:1_mute=off [ off on ]
> > record.adc-0:1=192,192
> > record.adc-2:3_mute=off [ off on ]
> > record.adc-2:3=192,192
> > outputs.spkr_source=dac-2:3 [ dac-2:3 ]
> > outputs.spkr_mute=off [ off on ]
> > outputs.spkr_eapd=on [ off on ]
> > outputs.spkr2_source=dac-2:3 [ dac-2:3 dac-0:1 adc-0:1 ]
> > outputs.spkr2_mute=off [ off on ]
> > outputs.spkr2_boost=off [ off on ]
> > inputs.mic=170,170
> > outputs.mic_dir=input-vr80 [ none input input-vr0 input-vr50 input-vr80 input-vr100 ]
> > outputs.hp_source=dac-0:1 [ dac-2:3 dac-0:1 ]
> > outputs.hp_mute=off [ off on ]
> > outputs.hp_boost=off [ off on ]
> > outputs.hp_eapd=on [ off on ]
> > record.adc-2:3_source=mic { mic }
> > record.adc-0:1_source=mic { mic }
> > outputs.mic_sense=unplugged [ unplugged plugged ]
> > outputs.hp_sense=unplugged [ unplugged plugged ]
> > outputs.spkr_muters=hp { hp }
> > outputs.master=128,128
> > outputs.master.mute=off [ off on ]
> > outputs.master.slaves=dac-2:3,dac-0:1,spkr,spkr2,hp { dac-2:3 dac-0:1 spkr spkr2 hp }
> > record.volume=192,192
> > record.volume.mute=off [ off on ]
> > record.volume.slaves=adc-0:1,adc-2:3 { adc-0:1 adc-2:3 mic }
> > record.enable=sysctl [ off on sysctl ]
> > $ doas usbdevs
> > Controller /dev/usb0:
> > addr 01: 8086:0000 Intel, xHCI root hub
> > Controller /dev/usb1:
> > addr 01: 8086:0000 Intel, xHCI root hub
> > addr 02: 06cb:00fc Synaptics, product 0x00fc
> > addr 03: 174f:1813 , Integrated Camera
> > addr 04: 8087:0033 Intel, Bluetooth
> > addr 05: 413c:8204 DELL, DELL Slim Soundbar SB522A
> > $ doas usbdevs -v -a 05
> > addr 05: 413c:8204 DELL, DELL Slim Soundbar SB522A
> > full speed, power 500 mA, config 1, rev 0.00, iSerial 0
> > driver: umodem0
> > driver: uaudio0
> > driver: uhidev0
> >
> > Am I missing something?
> >
> > Thanks,
> > Joel C.
> >
> >
>
--
Bonne journée,
Joel C.
Re: Quick question regarding puffy
John wrote:
> On the wider 'it could be considered political' point - it's time
> everyone in or near tech understand that pretty much everything is
> political, including technology.
>
> If the OpenBSD Foundation want to avoid 'party political' - sure,
> understandable. But 'anything' political? Impossible.
>
> Good luck with the project, Gwen.
>
> John
>
The fact something is not partisan does not mean it is apolitical. In
fact, as of late, I am seeing a lot of non-partisan political activism.
Most of the times you dig a bit underneath and it turns the non-partisan
activism actually has partisan ties. Who would have thought.
In my opinion, a gay event has the same political weight a Muslim event
or a Christian event has. I'd argue there is a lot of Muslim and
Christian political activity which is not partisan either, but only
people with an agenda would argue they have no political goals.
Besides, even if a particular group is not activist in nature, showing
support to it is in itself a political action.
Honestly I am a bit pissed off because we are discussing this subject
which does not mean anything for the project and meanwhile we have
unattended port submissions timing out in ports@.
> On the wider 'it could be considered political' point - it's time
> everyone in or near tech understand that pretty much everything is
> political, including technology.
>
> If the OpenBSD Foundation want to avoid 'party political' - sure,
> understandable. But 'anything' political? Impossible.
>
> Good luck with the project, Gwen.
>
> John
>
The fact something is not partisan does not mean it is apolitical. In
fact, as of late, I am seeing a lot of non-partisan political activism.
Most of the times you dig a bit underneath and it turns the non-partisan
activism actually has partisan ties. Who would have thought.
In my opinion, a gay event has the same political weight a Muslim event
or a Christian event has. I'd argue there is a lot of Muslim and
Christian political activity which is not partisan either, but only
people with an agenda would argue they have no political goals.
Besides, even if a particular group is not activist in nature, showing
support to it is in itself a political action.
Honestly I am a bit pissed off because we are discussing this subject
which does not mean anything for the project and meanwhile we have
unattended port submissions timing out in ports@.
Re: Upgrade lang/ghc to 9.8.3 - now with arm64
Matthias Kilian <kili@outback.escape.de> writes:
>> I had to repack the amd64 bootstraps because I previously had the wrong
>> date inside the archive. Matthias, would you mind picking up the new
>> tarballs from my cvs dir?
>
> Done. Checksums for all files (still the old hadrian-sources, I hope
> that's ok):
>
> SHA256 (ghc-9.8.3.20241111-aarch64.tar.xz) = xsS7rBvdK4Mll7L+4nrGG0PlOUbNfuZ1iszYX6SBgsM=
> SHA256 (ghc-9.8.3.20241111-amd64.tar.xz) = hu2fWQxl241tXZHQ0ZUIDEKMj8MMeLZU42OvXE2Azj0=
> SHA256 (ghc-9.8.3.20241111-shlibs-aarch64.tar.gz) = HyB7YP0jVa69Ec9hG/SjO/p80I/usZ0DozKv/nyl8JE=
> SHA256 (ghc-9.8.3.20241111-shlibs-amd64.tar.gz) = f8ngJzFpzjeCvlFaLptKVKFpUJMlzbvZ0Rqz14CRUvs=
> SHA256 (hadrian-sources-9.8.3.20241111.tar.gz) = c/bii6wxSimhWh4eq/FI7+3FS/DjTkJDd7RilEPDKJE=
Thanks, these are all good. I rebuilt the dependency universe of ghc on
amd64 and arm64 now. Even tested xmonad on arm64. Should we make this
available to the rest of the world now?
OK? Also need an OK on git-annex update.
Thanks
Greg
>> I had to repack the amd64 bootstraps because I previously had the wrong
>> date inside the archive. Matthias, would you mind picking up the new
>> tarballs from my cvs dir?
>
> Done. Checksums for all files (still the old hadrian-sources, I hope
> that's ok):
>
> SHA256 (ghc-9.8.3.20241111-aarch64.tar.xz) = xsS7rBvdK4Mll7L+4nrGG0PlOUbNfuZ1iszYX6SBgsM=
> SHA256 (ghc-9.8.3.20241111-amd64.tar.xz) = hu2fWQxl241tXZHQ0ZUIDEKMj8MMeLZU42OvXE2Azj0=
> SHA256 (ghc-9.8.3.20241111-shlibs-aarch64.tar.gz) = HyB7YP0jVa69Ec9hG/SjO/p80I/usZ0DozKv/nyl8JE=
> SHA256 (ghc-9.8.3.20241111-shlibs-amd64.tar.gz) = f8ngJzFpzjeCvlFaLptKVKFpUJMlzbvZ0Rqz14CRUvs=
> SHA256 (hadrian-sources-9.8.3.20241111.tar.gz) = c/bii6wxSimhWh4eq/FI7+3FS/DjTkJDd7RilEPDKJE=
Thanks, these are all good. I rebuilt the dependency universe of ghc on
amd64 and arm64 now. Even tested xmonad on arm64. Should we make this
available to the rest of the world now?
OK? Also need an OK on git-annex update.
Thanks
Greg
Re: Quick question regarding puffy
On the wider 'it could be considered political' point - it's time everyone in or near tech understand that pretty much everything is political, including technology.
If the OpenBSD Foundation want to avoid 'party political' - sure, understandable. But 'anything' political? Impossible.
Good luck with the project, Gwen.
John
On 12/3/24 16:49, izzy Meyer wrote:
Hi Gwen
Like others have mentioned- this could technically be considered "political".
However, thats the least of my concerns as social science is not political science. I would only consider this "politicised" in recent times, rather than "political".
I say you should be fine, although I carry no authority on the art or copyright or goals of the project.
Also- all this image appears to be intended to do is have puffy holding a progress flag. This would be a rather simple GIMP job, especially cos both of these pieces of art are fairly easy to come by online. (could be as simple as drag and drop and a mask over the fin). You don't really need to generate any new images, just compose two images together.
But- for some reason there is a strange glow on the puffy art (despite looking very similar to the official art), and the lines are sorta fuzzy and messy.
I can't help but infer this was made by a GAN, and if so, *that* would be your legal pitfall. Please make this in GIMP so at the very least you don't get accused of AI-art and copyright abuse.
Appreciated-
On December 2, 2024 7:06:55 PM CST, Gwen Nelson <gwen@gwennelson.co.uk> wrote:Hi
I'm setting up a pubnix server for LGBT people running the best OS (OpenBSD of course) and was wondering if it'd be acceptable to display puffy holding a pride flag on the project's website as a logo.
See attached - I'm not sure if the puffy artwork is licensed to allow this kind of modification.
I promise it's for a good cause and in good taste, the server has rules against people doing illegal stuff and being abusive etc, it's also invite-only and I'll ban anyone who's an asshole. The main purpose of the project is to build a community, similar to services such as sdf.org or the tildeverse - I've found most people tend to default to Linux or NetBSD and felt OpenBSD is the superior option for my project.
Naturally I'll give appropriate attribution too.
I'm not subscribed to the list and looking for an official response, so also sending this to Theo.
You guys have my utmost respect for creating such a beautiful clean yet functional and secure OS.
Should there be any issues with this, please advise - as I said, the project and all involved have my utmost respect.
Best regards
Subscribe to:
Posts (Atom)