[Basfa] (forw) All's Well That Ends Well ??? Silicon Valley Shakespeare

[Rick Moen via Basfa]

Relevant to discussion last night.

June 7–23, 2024

Thursdays–Sundays at 7:00 PM
Willow Street Frank Bramhall Park
San Jose, CA
FREE

Special Themed ➕ Accessibility Nights

Thursday, June 13th
Renaissance Dress-up Night*

Saturday, June 15th
ASL-interpreted Performance


- Forwarded message from Duncan MacKinnon  -

Date: Mon, 10 Jun 2024 20:23:33 -0700
From: Duncan MacKinnon 
To: Duncan MacKinnon 
Cc: Rick Moen 
Subject: All's Well That Ends Well ??? Silicon Valley Shakespeare

https://www.svshakespeare.org/endswell

- End forwarded message -
___
Basfa mailing list
Basfa@lists.basfa.org
http://lists.basfa.org/listinfo.cgi/basfa-basfa.org

[Basfa] (forw) Rebel Moon 3: Zack Snyder's Confirmation, Story & Everything We Know

[Rick Moen via Basfa]

Relevant to discussion last night.

- Forwarded message from Duncan MacKinnon  -

Date: Mon, 10 Jun 2024 20:22:14 -0700
From: Duncan MacKinnon 
To: Duncan MacKinnon 
Cc: Rick Moen 
Subject: Rebel Moon 3: Zack Snyder's Confirmation, Story & Everything We Know

https://screenrant.com/rebel-moon-3-zack-snyder-confirmed-updates/

- End forwarded message -
- Forwarded message from Duncan MacKinnon  -

Date: Mon, 10 Jun 2024 20:21:16 -0700
From: Duncan MacKinnon 
To: Duncan MacKinnon 
Cc: Rick Moen 
Subject: Rebel Moon - Wikipedia

https://en.wikipedia.org/wiki/Rebel_Moon

- End forwarded message -
___
Basfa mailing list
Basfa@lists.basfa.org
http://lists.basfa.org/listinfo.cgi/basfa-basfa.org

[Basfa] (forw) REVIEW: The Road to Roswell by Connie Willis

[Rick Moen via Basfa]

Relevant to discussion last night.

- Forwarded message from Duncan MacKinnon  -

Date: Mon, 10 Jun 2024 20:26:06 -0700
From: Duncan MacKinnon 
To: Duncan MacKinnon 
Cc: Rick Moen 
Subject: REVIEW: The Road to Roswell by Connie Willis
X-Spam-Status: No, score=-1.8 required=4.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,MPART_ALT_DIFF,RCVD_IN_DNSWL_NONE,
T_SCC_BODY_TEXT_LINE autolearn=no version=3.3.1

https://dearauthor.com/book-reviews/overall-b-reviews/b-plus-reviews/review-the-road-to-roswell-by-connie-willis/

- End forwarded message -
- Forwarded message from Duncan MacKinnon  -

Date: Mon, 10 Jun 2024 20:24:48 -0700
From: Duncan MacKinnon 
To: Duncan MacKinnon 
Cc: Rick Moen 
Subject: The Road to Roswell by Connie Willis | Goodreads
X-Spam-Status: No, score=0.2 required=4.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,HTML_OBFUSCATE_20_30,MPART_ALT_DIFF,
RCVD_IN_DNSWL_NONE,T_SCC_BODY_TEXT_LINE autolearn=no version=3.3.1

https://www.goodreads.com/book/show/58775691-the-road-to-roswell

- End forwarded message -
___
Basfa mailing list
Basfa@lists.basfa.org
http://lists.basfa.org/listinfo.cgi/basfa-basfa.org

[gentoo-commits] repo/gentoo:master commit in: app-misc/hivex/

[Rick Farina]

commit: b7920ed364e05594c25aff6adc16768c37104b29
Author: Rick Farina  gentoo  org>
AuthorDate: Mon Jun 10 22:55:10 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue Jun 11 10:13:23 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b7920ed3

app-misc/hivex: enable py3.12

Signed-off-by: Rick Farina  gentoo.org>
Closes: https://bugs.gentoo.org/929333

 app-misc/hivex/hivex-1.3.23-r1.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/app-misc/hivex/hivex-1.3.23-r1.ebuild 
b/app-misc/hivex/hivex-1.3.23-r1.ebuild
index 91e11388b727..1c759d7ee93b 100644
--- a/app-misc/hivex/hivex-1.3.23-r1.ebuild
+++ b/app-misc/hivex/hivex-1.3.23-r1.ebuild
@@ -5,7 +5,7 @@ EAPI=8
 
 USE_RUBY="ruby31 ruby32"
 RUBY_OPTIONAL=yes
-PYTHON_COMPAT=( python3_{10..11} )
+PYTHON_COMPAT=( python3_{10..12} )
 inherit perl-module ruby-ng python-single-r1 strip-linguas
 
 DESCRIPTION="Library for reading and writing Windows Registry 'hive' binary 
files"

[gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-ieee802154/

[Rick Farina]

commit: dd4740135c8fd9139d8722a96ee9d5715f1547f7
Author: Rick Farina  gentoo  org>
AuthorDate: Tue Jun 11 10:13:02 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue Jun 11 10:13:28 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dd474013

net-wireless/gr-ieee802154: enable py3.12

Signed-off-by: Rick Farina  gentoo.org>

 net-wireless/gr-ieee802154/gr-ieee802154-0.0_p20210719-r3.ebuild | 4 ++--
 net-wireless/gr-ieee802154/gr-ieee802154-.ebuild | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net-wireless/gr-ieee802154/gr-ieee802154-0.0_p20210719-r3.ebuild 
b/net-wireless/gr-ieee802154/gr-ieee802154-0.0_p20210719-r3.ebuild
index 3965c4c7a1e3..e1b48bb9f238 100644
--- a/net-wireless/gr-ieee802154/gr-ieee802154-0.0_p20210719-r3.ebuild
+++ b/net-wireless/gr-ieee802154/gr-ieee802154-0.0_p20210719-r3.ebuild
@@ -1,8 +1,8 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
-PYTHON_COMPAT=( python3_{9..11} )
+PYTHON_COMPAT=( python3_{9..12} )
 
 inherit cmake python-single-r1
 

diff --git a/net-wireless/gr-ieee802154/gr-ieee802154-.ebuild 
b/net-wireless/gr-ieee802154/gr-ieee802154-.ebuild
index 3f784616f50d..fbf88104daa3 100644
--- a/net-wireless/gr-ieee802154/gr-ieee802154-.ebuild
+++ b/net-wireless/gr-ieee802154/gr-ieee802154-.ebuild
@@ -1,8 +1,8 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
-PYTHON_COMPAT=( python3_{9..11} )
+PYTHON_COMPAT=( python3_{9..12} )
 
 inherit cmake python-single-r1
 

Re: JDK 23 Feature Freeze / New Loom EA builds

[Rick Hillegas]

Thanks for the heads-up, David. Derby builds and tests cleanly with Open 
JDK build 23-ea+26-2269.  See 
https://issues.apache.org/jira/browse/DERBY-7163


On 6/10/24 12:31 AM, David Delabassee wrote:

Welcome to the latest OpenJDK Quality Outreach update!

JDK 23, scheduled for General Availability on September 17, 2024, is now in 
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is 
frozen (see the final list of JEPs integrated into JDK 23 below) and only 
low-risk enhancements might still be considered. The coming weeks should be 
leveraged to identify and resolve as many issues as possible, i.e. before JDK 
23 enters the Release Candidates phase in early August [2]. We count on you to 
test your projects and help us make JDK 23 another solid release!

This time, we are covering several heads-up related to JDK 23 : Deprecate the 
Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation 
processing policy change. Also, make sure to check the new Loom early-access 
builds which have an improved Java monitors implementation to work better with 
virtual threads.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html
[2] https://openjdk.org/projects/jdk/23/


## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe 
for Removal

As mentioned in a previous communication [3], there’s a plan to ultimately 
remove the sun.misc.Unsafe memory-access methods as the platform offers safer 
alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe 
for Removal) [4] outlines in more detail this plan including the initial step 
which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access 
methods are now marked as deprecated for removal. This will cause, in JDK 23, 
compile-time deprecation warnings for code that refers to these methods, 
alerting library developers to their forthcoming removal. A new command-line 
option also enables application developers and users to receive runtime 
warnings when those methods are used.

Developers relying on those sun.misc.Unsafe APIs for access memory are strongly 
encouraged to start, if they haven't done so yet, the migration from the 
sun.misc.Unsafe APIs to supported replacements. For more details, make sure to 
read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for 
Removal).

[3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html
[4] https://openjdk.org/jeps/471


## Heads-Up - JDK 23: Changes Default Annotation Processing Policy

Annotation processing is a compile-time feature, where javac scans the 
to-be-compiled source files for annotations and then the class path for 
matching annotation processors, so they can generate source code. Up to JDK 22, 
this feature is enabled by default, which may have been reasonable when it was 
introduced in JDK 6 circa 2006, but from a current perspective, in the interest 
of making build output more robust against annotation processors being placed 
on the class path unintentionally, this is much less reasonable. Hence, 
starting with JDK 23, javac requires an additional command-line option to 
enable annotation processing.

### New `-proc` Value
To that end, the pre-existing option `-proc:$policy` was extended, where 
`$policy` can now have the following values:
- `none`: compilation _without_ annotation processing, this policy exists since 
JDK 6
- `only`: annotation processing _without_ compilation, this policy exists since 
JDK 6
- `full`: annotation processing followed by compilation, this policy is the 
default in JDK ≤22 but the value itself is new (see next section for versions 
that support it)

Up to and including JDK 22, code bases that require annotation processing 
before compilation could rely on javac's default behavior to process 
annotations but that is no longer the case. Starting with JDK 23, at least one 
annotation-processing command line option needs to be present. If neither 
`-processor`, `--processor-path`, now `--processor-module-path` is used, 
`-proc:only` or `-proc:full` has to be provided. In other words, absent other 
command line options, `-proc:none` is the default on JDK 23.

### Migration to `-proc:full`

Several measures were undertaken to help projects prepare for the switch to 
`-proc:full`:
- As of the April 2024 JDK security updates, support for `-proc:full` has been 
backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK 
distributions. Additionally, Oracle's 8u release (8u411) also supports 
`-proc:full`.
- Starting in JDK 21, javac prints an informative message if implicit usage of 
annotation processing under the default policy is detected.

With `-proc:full` backported, it is possible to configure a build that will 
work the same before and after the change in javac's default policy.

Additional details can be found in the original proposal [5].

[5] 

[MBZ] One For The Michigan Folks

[Rick Knoble via Mercedes]

https://swmi.craigslist.org/cto/d/saint-joseph-1984-mercedes-benz-300d/7755437149.html

Rick

Get Outlook for Android<https://aka.ms/AAb9ysg>
___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

[CMS-PIPELINES] pervasive plumbing and past projects

[Rick Troth]

hello gang --

I've been trying to gather a list of pipelines implementations apart
from CMS/TSO.
Specifically, I know about NetRexx Java Pipes, and I think there was
another Java implementation. I also found an implementation in Swift.
Are there others? This is my current question.

I'm scheduled to present at the VM Workshop on "Pervasive Plumbing -
Pipelines for Everyone". My own attempt has finally borne fruit. So many
stages to write. So little time. I want to make sure that the talk
covers sufficient ground and gives credit to the other developers.

thanks!


--
-- R; <><

Re: [MBZ] Tires for my 1980 300SD

[Rick Knoble via Mercedes]

I can second all of those choices. All the tires.

Rick

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Mercedes  on behalf of Kaleb Striplin via 
Mercedes 
Sent: Saturday, June 8, 2024 4:29:24 PM
To: Mercedes Discussion List 
Cc: Kaleb Striplin 
Subject: Re: [MBZ] Tires for my 1980 300SD

General Alimax, Hankook, I have also had good luck with GT Radial

Sent from my iPhone

> On Jun 8, 2024, at 3:37 PM, Craig via Mercedes  wrote:
>
> So I had the car up on four jackstands to bleed the brakes and had the
> thought of looking for the date code on the tires. I had trouble finding
> the information because it doesn't look like the examples I saw on-line.
>
> I finally decided the information in the first attached picture has the
> date code at its end.
>
> And to think I have been driving all over the middle part of this
> country ...
>
> The tires look new, though, as the second and third pictures show.
>
> I will need to get new tires for my W116 300SD (including the spare,
> which is worse than the road tires).
>
> Does anyone have any recommendations / experiences?
>
> Thanks,
>
>
> Craig
> 
> 
> 
> ___
> http://www.okiebenz.com
>
> To search list archives http://www.okiebenz.com/archive/
>
> To Unsubscribe or change delivery options go to:
> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
>


___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

git: 13a51233e4c7 - main - nfsd: Delete an unused VNET global variable

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=13a51233e4c7d6cff04043c38845b1ec1af38680

commit 13a51233e4c7d6cff04043c38845b1ec1af38680
Author: Rick Macklem 
AuthorDate: 2024-06-08 23:40:52 +
Commit: Rick Macklem 
CommitDate: 2024-06-08 23:40:52 +

nfsd: Delete an unused VNET global variable

During code inspection, I noticed that
NFSD_VNET_DEFINE(nfsrv_dontlisthead)
is unused, so delete it.

MFC after:  2 weeks
---
 sys/fs/nfsserver/nfs_nfsdsubs.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sys/fs/nfsserver/nfs_nfsdsubs.c b/sys/fs/nfsserver/nfs_nfsdsubs.c
index 0d7e4c73fe69..d80826993f23 100644
--- a/sys/fs/nfsserver/nfs_nfsdsubs.c
+++ b/sys/fs/nfsserver/nfs_nfsdsubs.c
@@ -57,9 +57,6 @@ NFSD_VNET_DECLARE(int, nfs_rootfhset);
 NFSD_VNET_DECLARE(uid_t, nfsrv_defaultuid);
 NFSD_VNET_DECLARE(gid_t, nfsrv_defaultgid);
 
-NFSD_VNET_DEFINE(struct nfsdontlisthead, nfsrv_dontlisthead);
-
-
 char nfs_v2pubfh[NFSX_V2FH];
 struct nfsdontlisthead nfsrv_dontlisthead;
 struct nfslayouthead nfsrv_recalllisthead;

git: 13a51233e4c7 - main - nfsd: Delete an unused VNET global variable

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=13a51233e4c7d6cff04043c38845b1ec1af38680

commit 13a51233e4c7d6cff04043c38845b1ec1af38680
Author: Rick Macklem 
AuthorDate: 2024-06-08 23:40:52 +
Commit: Rick Macklem 
CommitDate: 2024-06-08 23:40:52 +

nfsd: Delete an unused VNET global variable

During code inspection, I noticed that
NFSD_VNET_DEFINE(nfsrv_dontlisthead)
is unused, so delete it.

MFC after:  2 weeks
---
 sys/fs/nfsserver/nfs_nfsdsubs.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sys/fs/nfsserver/nfs_nfsdsubs.c b/sys/fs/nfsserver/nfs_nfsdsubs.c
index 0d7e4c73fe69..d80826993f23 100644
--- a/sys/fs/nfsserver/nfs_nfsdsubs.c
+++ b/sys/fs/nfsserver/nfs_nfsdsubs.c
@@ -57,9 +57,6 @@ NFSD_VNET_DECLARE(int, nfs_rootfhset);
 NFSD_VNET_DECLARE(uid_t, nfsrv_defaultuid);
 NFSD_VNET_DECLARE(gid_t, nfsrv_defaultgid);
 
-NFSD_VNET_DEFINE(struct nfsdontlisthead, nfsrv_dontlisthead);
-
-
 char nfs_v2pubfh[NFSX_V2FH];
 struct nfsdontlisthead nfsrv_dontlisthead;
 struct nfslayouthead nfsrv_recalllisthead;

Re: [MBZ] Samstag

[Rick Knoble via Mercedes]

> More, or less, expensive than the Klann KL-025?

Same one. Same price. Now manufactured by Gedore.

Rick

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

Re: [MBZ] Samstag

[Rick Knoble via Mercedes]

A spring compressor and a ball joint press.
Very, very pricey. Then again, my life, limbs, and health are worth it. I have 
six cars to remove springs from.

Rick


Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Mercedes  on behalf of Craig via Mercedes 

Sent: Friday, June 7, 2024 4:40:45 PM
To: Mercedes Discussion List 
Cc: Craig 
Subject: Re: [MBZ] Samstag

On Fri, 7 Jun 2024 21:25:45 +0000 Rick Knoble via Mercedes
 wrote:

> Just placed an order with Samstag for a few specialty tools, and I must
> say their customer service is the absolute best I have ever
> encountered. Ever.

Thank you for pointing them out.

What tools did you order?


Craig

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

[MBZ] Samstag

[Rick Knoble via Mercedes]

Just placed an order with Samstag for a few specialty tools, and I must say 
their customer service is the absolute best I have ever encountered. Ever.

Rick

Get Outlook for Android<https://aka.ms/AAb9ysg>
___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

Re: [BVARC] ham radio dinner TONIGHT

[Rick Hiller via BVARC]

Web site says 6 pmSent from my i-ThingamajigOn Jun 7, 2024, at 10:29 AM, Eddie Runner via BVARC  wrote:
no, just show up!!  Separate tickets!!Eddie





On Friday, June 7, 2024 at 10:16:35 AM CDT, Joe Vaught via BVARC  wrote:





Do I need to register?JoeKJ5EPN7134943320Sent from my iPhoneOn Jun 7, 2024, at 10:02 AM, Eddie Runner via BVARC  wrote: Los Tios Mexican Resturant6:30 9:00pm 9527 Westheimer Rd. (near Gessner)Houston TX 77063Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ 

Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ 
Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

[gentoo-commits] repo/gentoo:master commit in: app-misc/liquidctl/, app-misc/liquidctl/files/

[Rick Farina]

commit: f47fa22bdc6b6fe8e134cd72f26654038d1ad4dd
Author: Rick Farina  gentoo  org>
AuthorDate: Thu Jun  6 12:51:58 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Thu Jun  6 12:52:42 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f47fa22b

app-misc/liquidctl: fix some test failures

Signed-off-by: Rick Farina  gentoo.org>

 app-misc/liquidctl/files/709.patch | 32 ++
 app-misc/liquidctl/liquidctl-1.13.0.ebuild |  3 +++
 2 files changed, 35 insertions(+)

diff --git a/app-misc/liquidctl/files/709.patch 
b/app-misc/liquidctl/files/709.patch
new file mode 100644
index ..dd0d6420a9da
--- /dev/null
+++ b/app-misc/liquidctl/files/709.patch
@@ -0,0 +1,32 @@
+From 470b159fddbf595ccbf6995b4f9e6a1462e97c65 Mon Sep 17 00:00:00 2001
+From: Jonas Malaco 
+Date: Tue, 21 May 2024 15:53:40 -0300
+Subject: [PATCH] test_cli: don't change the type of sys.argv when
+ monkeypatching it
+
+When setting up for the CLI tests, we inadvertently change the type of
+sys.argv from list to tuple. That worked with OG docopt, but breaks
+docopt-ng. More importantly, the Python docs say sys.argv is a _list_.
+
+So even though docopt was able to handle it being a tuple, and docopt-ng
+seems (from a cursory look at its source) to still handle it being a
+string, let's use the correct type.
+
+Fixes: #708
+---
+ tests/test_cli.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tests/test_cli.py b/tests/test_cli.py
+index aa577ffc0..76791e896 100644
+--- a/tests/test_cli.py
 b/tests/test_cli.py
+@@ -11,7 +11,7 @@
+ def main(monkeypatch, capsys):
+ """Return a function f(*args) to run main with `args` as `sys.argv`."""
+ def call_with_args(*args):
+-monkeypatch.setattr(sys, 'argv', args)
++monkeypatch.setattr(sys, 'argv', list(args))
+ try:
+ liquidctl.cli.main()
+ except SystemExit as exit:

diff --git a/app-misc/liquidctl/liquidctl-1.13.0.ebuild 
b/app-misc/liquidctl/liquidctl-1.13.0.ebuild
index a2eb2e0132a7..6cec41aae631 100644
--- a/app-misc/liquidctl/liquidctl-1.13.0.ebuild
+++ b/app-misc/liquidctl/liquidctl-1.13.0.ebuild
@@ -28,6 +28,9 @@ BDEPEND="
dev-python/setuptools-scm[${PYTHON_USEDEP}]
 "
 
+# This is a merged PR, remove it on bump
+PATCHES=( "${FILESDIR}/709.patch" )
+
 distutils_enable_tests pytest
 
 src_test() {

Re: [RFC PATCH v5 00/29] TDX KVM selftests

[Edgecombe, Rick P]

On Wed, 2024-06-05 at 16:34 -0500, Sagi Shahar wrote:
> > We don't currently have plans to post a whole ~130 patch series. Instead we
> > plan
> > to post subsections out of the series as they slowly move into a maintainer
> > branch.
> 
> So this means that we won't be able to post an updated version of the
> selftests for a while unless we lock it to the V19 patchset which is
> based on v6.8-rc5
> Do you have an estimate on when the TDX patches get to the point where
> they could support the basic lifecycle selftest?

I don't understand. The MMU prep series postings come with a full branch in
github that can boot a TD. What is different if we post the other commits as
patches vs just linking to them in github? The selftests won't be upstreamed
ahead of the base TDX support anyway, right?

> > 
> > We are trying to use the selftests as part of the development of the base
> > TDX
> > base series. So we need to be able to run them on development branches to
> > catch
> > regressions and such. For this purpose, we wouldn't need updates to be
> > posted to
> > the mailing list. It probably needs either some sort of co-development, or
> > otherwise we will need to maintain an internal fork of the selftests.
> > 
> > We also need to add some specific tests that can cover gaps in our current
> > testing. Probably we could contribute those back to the series.
> > 
> > What do you think?
> 
> I will take a look at rebasing the selftests on top of the Intel
> development branch and I can post it on our github branch. We can talk
> about co-development offline. We already have some code that was
> suggested by Isaku as part of our tests.

That would be great, thanks.

Re: [RFC PATCH v5 00/29] TDX KVM selftests

[Edgecombe, Rick P]

On Wed, 2024-06-05 at 15:42 -0500, Sagi Shahar wrote:
> > > Hm you're right, I was looking more narrowly because of the kvm-coco-
> > > queue conflicts, for some of which even v19 might be too old. The MMU
> > > prep series uses a much more recent kvm-coco-queue baseline.
> > > 
> > > Rick, can we post a branch with /everything/ on this MMU prep baseline
> > > for this selftest refresh?
> > 
> > Actually I see the branch below does contain everything, not just the
> > MMU prep patches. Sagi, is this fine for a baseline?
> > 
> Maybe for internal development but I don't think I can post an
> upstream patchset based on an internal Intel development branch.
> Do you know if there's a plan to post a patch series based on that branch
> soon?

We don't currently have plans to post a whole ~130 patch series. Instead we plan
to post subsections out of the series as they slowly move into a maintainer
branch.

We are trying to use the selftests as part of the development of the base TDX
base series. So we need to be able to run them on development branches to catch
regressions and such. For this purpose, we wouldn't need updates to be posted to
the mailing list. It probably needs either some sort of co-development, or
otherwise we will need to maintain an internal fork of the selftests.

We also need to add some specific tests that can cover gaps in our current
testing. Probably we could contribute those back to the series.

What do you think?

git: dbe7ff254e6c - main - nfsd: Update a file missed by commit e2c9fad2e0ae

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=dbe7ff254e6c87a851a75caa7250b8fbcab90c9f

commit dbe7ff254e6c87a851a75caa7250b8fbcab90c9f
Author: Rick Macklem 
AuthorDate: 2024-06-05 01:54:15 +
Commit: Rick Macklem 
CommitDate: 2024-06-05 01:54:15 +

nfsd: Update a file missed by commit e2c9fad2e0ae

MFC after:  1 month
---
 sys/fs/nfs/nfsproto.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sys/fs/nfs/nfsproto.h b/sys/fs/nfs/nfsproto.h
index cef886755d5a..ca9c732b6a43 100644
--- a/sys/fs/nfs/nfsproto.h
+++ b/sys/fs/nfs/nfsproto.h
@@ -619,6 +619,8 @@
 #defineNFSV4OPEN_WDCONTENTION  0x0010
 #defineNFSV4OPEN_WDNOTWANTED   0x0020
 #defineNFSV4OPEN_WDSUPPFTYPE   0x0040
+#defineNFSV4OPEN_WDNOTSUPPDOWNGRADE0x0080
+#defineNFSV4OPEN_WDNOTSUPPUPGRADE  0x0100
 
 /*
  * NFS V4 File Handle types

git: dbe7ff254e6c - main - nfsd: Update a file missed by commit e2c9fad2e0ae

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=dbe7ff254e6c87a851a75caa7250b8fbcab90c9f

commit dbe7ff254e6c87a851a75caa7250b8fbcab90c9f
Author: Rick Macklem 
AuthorDate: 2024-06-05 01:54:15 +
Commit: Rick Macklem 
CommitDate: 2024-06-05 01:54:15 +

nfsd: Update a file missed by commit e2c9fad2e0ae

MFC after:  1 month
---
 sys/fs/nfs/nfsproto.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sys/fs/nfs/nfsproto.h b/sys/fs/nfs/nfsproto.h
index cef886755d5a..ca9c732b6a43 100644
--- a/sys/fs/nfs/nfsproto.h
+++ b/sys/fs/nfs/nfsproto.h
@@ -619,6 +619,8 @@
 #defineNFSV4OPEN_WDCONTENTION  0x0010
 #defineNFSV4OPEN_WDNOTWANTED   0x0020
 #defineNFSV4OPEN_WDSUPPFTYPE   0x0040
+#defineNFSV4OPEN_WDNOTSUPPDOWNGRADE0x0080
+#defineNFSV4OPEN_WDNOTSUPPUPGRADE  0x0100
 
 /*
  * NFS V4 File Handle types

More Paris Pix

[Rick Womer]

For some reason, Smugmug insisted on organizing them =its= way, so the new and 
old are somewhat mixed.

Lyon photos next.

https://rickwomer.smugmug.com/2023/Paris-Oct-23

Compliments and criticisms equally welcome.

Rick
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[Basfa] Godzilla Minus One: review by Camestros Felapton

[Rick Moen via Basfa]

(Since this was reviewed at the meeting, yesterday.)

This was posted to my acquaintance Camestros Felapton's blog at
https://camestrosfelapton.wordpress.com/2024/06/05/godzilla-minus-one/ :


I’d heard that this was a good film but it was nigh on impossible to see
when it was in cinemas. Luckily, it is now available on Netflix and wow,
it is exactly as good as people led me to believe. I don’t mean “it is
good for a Godzilla film”, I mean this is a good film in its own right
AND it absolutely is also a good Godzilla film.

So firstly, if you are a fan of kaiju stomping and chomping their way
through populated cities and military forces who foolishly think their
puny weapons can stop the rampaging monster then this film absolutely
delivers. Godzilla bites through warships, stomps on buildings and
blasts all and sundry with atomic breath. Have no worries in this
regard, if that is what you want from a Godzilla film, you should be
satisfied. If you want Godzilla to be the misunderstood hero who battles
a much worse kaiju, then no, you won’t get that but otherwise this is a
solid entry in kaiju mayhem.

Meanwhile, we get a film of surprising depth built around Godzilla’s
thunderous actions.

Shikishima is a young man trained to be a kamikaze pilot in the final
weeks of World War 2. On his first mission he pretends his plane has a
fault and lands on a remote island airstrip for “repairs”. Unfortunately
for him and the aircraft enigneers, this island has an infamous monster
known to the native islanders as (you guessed it) Godzilla.

That night, a relatively small (by Godzilla standards i.e. it’s huge but
not ginormous) dinosaur-like beast attacks the airstrip. The engineers
beg Shikishima to use the gun in his aircraft to kill the monster but he
panics and runs away. In the morning he is one of only a few survivors.

Returning home, he finds his family are dead and his home in ruins. He
is scolded by other civilian survivors for being a supposed kamikaze who
was still alive. In the ruins of a city he encounters a woman stealing
food for a baby. The woman, Nokiro, has also been left without family.
The baby she carries is not hers but yet another abandoned soul.
Together, the three of the form a kind of ramshackle family in a
ramshackle house barely surviving amid the ruins and with Shikishima
plagued with guilt and nightmares.

Meanwhile…the USA is conducting nuclear tests in the Pacific…

War, disaster and survivors guilt play out as major themes amid the
chaos of an unstoppable force of nature. With Japan in ruins, it now
must face a kind of inhuman punishment that people struggle to make
sense of. For Shikishima the monster offers a way to make atonement but
his guilt and obsession act as a barrier to truly connecting to the
family that he found almost by accident.

The idea of Godzilla films in general representing Japanese post-war
cultural trauma from both defeat, the brutal impact of Allied
conventional bombing and the added horror of the nuclear attacks, is a
common one. Here, that connection is both more literal and as a kind of
contrast. Godzilla smashes and kills and then, every so often, inflicts
a nuclear blast on Japan. However, Godzilla offers no reason for its
actions, it acts because that is what it is.

It is not a flawless film. I was struck by an important speech late in
the film where a key character contrasts the war with the current
conflict with Godzilla. He addresses how cheaply the war had treated
human lives and how people were expected to sacrifice themselves without
meaning. In contrast, the volunteers who set out to stop Godzilla
killing more people are doing so understanding the danger and for a
clearer cause. Additionally, they are working together to avoid people
suffering. Even so, this speech focuses on how Japanese lives were
treated cheaply by the Japanese government, with no recognition of even
greater human toll inflected on people in China, Korea and beyond. True,
this is undoubtedly how somebody in 1946 Japan would frame things but I
doubt we’d see a film set in 1946 Germany that didn’t acknowledge how
appalling the Nazis were.

Events lead to a big climax with a scheme to defeat the monster and some
great moments. I did get a bit teary at the end.

Cheaply made by Hollywood standards but overall, visually very
effective, this is not a complicated story but is still one that manages
to deliver on multiple layers.



[It's a blog, so y'all can comment, there.]
___
Basfa mailing list
Basfa@lists.basfa.org
http://lists.basfa.org/listinfo.cgi/basfa-basfa.org

git: e2c9fad2e0ae - main - nfsd: Fix delegation handled for atomic upgrade

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e2c9fad2e0ae3f7049831bf7f2be1a3573363cdc

commit e2c9fad2e0ae3f7049831bf7f2be1a3573363cdc
Author: Rick Macklem 
AuthorDate: 2024-06-05 01:46:41 +
Commit: Rick Macklem 
CommitDate: 2024-06-05 01:46:41 +

nfsd: Fix delegation handled for atomic upgrade

For NFSv4.1/4.2, an atomic upgrade of a delegation from a
read delegation to a write delegation is allowed and can
result in signoficantly improved performance.

This patch adds support for this atomic upgrade, plus fixes
a couple of other delegation related bugs.  Since there were
three cases where delegations were being issued, the patch
factors this out into a separate function called
nfsrv_issuedelegations().

This patch should only affect the NFSv4.1/4.2 behaviour
when delegations are enabled, which is not the default.

MFC after:  1 month
---
 sys/fs/nfsserver/nfs_nfsdserv.c  |   7 +
 sys/fs/nfsserver/nfs_nfsdstate.c | 297 ++-
 2 files changed, 141 insertions(+), 163 deletions(-)

diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c b/sys/fs/nfsserver/nfs_nfsdserv.c
index 0c8bda6dc6a6..47e3a20390f4 100644
--- a/sys/fs/nfsserver/nfs_nfsdserv.c
+++ b/sys/fs/nfsserver/nfs_nfsdserv.c
@@ -3244,6 +3244,13 @@ nfsrvd_open(struct nfsrv_descript *nd, __unused int 
isdgram,
NFSM_BUILD(tl, u_int32_t *, 2 * NFSX_UNSIGNED);
*tl++ = txdr_unsigned(NFSV4OPEN_RESOURCE);
*tl = newnfs_false;
+   } else if ((rflags &
+   NFSV4OPEN_WDNOTSUPPDOWNGRADE) != 0) {
+   NFSM_BUILD(tl, uint32_t *, NFSX_UNSIGNED);
+   *tl = txdr_unsigned(NFSV4OPEN_NOTSUPPDOWNGRADE);
+   } else if ((rflags & NFSV4OPEN_WDNOTSUPPUPGRADE) != 0) {
+   NFSM_BUILD(tl, uint32_t *, NFSX_UNSIGNED);
+   *tl = txdr_unsigned(NFSV4OPEN_NOTSUPPUPGRADE);
} else {
NFSM_BUILD(tl, u_int32_t *, NFSX_UNSIGNED);
*tl = txdr_unsigned(NFSV4OPEN_NOTWANTED);
diff --git a/sys/fs/nfsserver/nfs_nfsdstate.c b/sys/fs/nfsserver/nfs_nfsdstate.c
index c73840277022..ce3f3481f04a 100644
--- a/sys/fs/nfsserver/nfs_nfsdstate.c
+++ b/sys/fs/nfsserver/nfs_nfsdstate.c
@@ -240,6 +240,11 @@ static int nfsrv_createdsfile(vnode_t vp, fhandle_t *fhp, 
struct pnfsdsfile *pf,
 static struct nfsdevice *nfsrv_findmirroredds(struct nfsmount *nmp);
 static int nfsrv_checkmachcred(int op, struct nfsrv_descript *nd,
 struct nfsclient *clp);
+static void nfsrv_issuedelegation(struct vnode *vp, struct nfsclient *clp,
+struct nfsrv_descript *nd, int delegate, int writedeleg, int readonly,
+u_quad_t filerev, uint64_t rdonly, struct nfsstate **new_delegp,
+struct nfsstate *new_stp, struct nfslockfile *lfp, uint32_t *rflagsp,
+nfsv4stateid_t *delegstateidp);
 
 /*
  * Scan the client list for a match and either return the current one,
@@ -442,7 +447,8 @@ nfsrv_setclient(struct nfsrv_descript *nd, struct nfsclient 
**new_clpp,
/*
 * If the verifier has changed, the client has rebooted
 * and a new client id is issued. The old state info
-* can be thrown away once the SETCLIENTID_CONFIRM occurs.
+* can be thrown away once the SetClientID_Confirm or
+* Create_Session that confirms the clientid occurs.
 */
LIST_REMOVE(clp, lc_hash);
 
@@ -2648,6 +2654,8 @@ tryagain:
 *considered a conflict since the client with a read delegation
 *could have done an Open with ReadAccess and WriteDeny
 *locally and then not have checked for the WriteDeny.)
+*The exception is a NFSv4.1/4.2 client that has requested
+*an atomic upgrade to a write delegation.
 * Don't check for a Reclaim, since that will be dealt with
 * by nfsrv_openctrl().
 */
@@ -2657,9 +2665,10 @@ tryagain:
while (stp != LIST_END(>lf_deleg)) {
nstp = LIST_NEXT(stp, ls_file);
if ((readonly && stp->ls_clp != clp &&
-  (stp->ls_flags & NFSLCK_DELEGWRITE)) ||
+(stp->ls_flags & NFSLCK_DELEGWRITE) != 0) ||
(!readonly && (stp->ls_clp != clp ||
-(stp->ls_flags & NFSLCK_DELEGREAD {
+((stp->ls_flags & NFSLCK_DELEGREAD) != 0 &&
+ (new_stp->ls_flags & NFSLCK_WANTWDELEG) == 0 {
ret = nfsrv_delegconflict(stp, , p, vp);
if (ret) {
   

git: e2c9fad2e0ae - main - nfsd: Fix delegation handled for atomic upgrade

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=e2c9fad2e0ae3f7049831bf7f2be1a3573363cdc

commit e2c9fad2e0ae3f7049831bf7f2be1a3573363cdc
Author: Rick Macklem 
AuthorDate: 2024-06-05 01:46:41 +
Commit: Rick Macklem 
CommitDate: 2024-06-05 01:46:41 +

nfsd: Fix delegation handled for atomic upgrade

For NFSv4.1/4.2, an atomic upgrade of a delegation from a
read delegation to a write delegation is allowed and can
result in signoficantly improved performance.

This patch adds support for this atomic upgrade, plus fixes
a couple of other delegation related bugs.  Since there were
three cases where delegations were being issued, the patch
factors this out into a separate function called
nfsrv_issuedelegations().

This patch should only affect the NFSv4.1/4.2 behaviour
when delegations are enabled, which is not the default.

MFC after:  1 month
---
 sys/fs/nfsserver/nfs_nfsdserv.c  |   7 +
 sys/fs/nfsserver/nfs_nfsdstate.c | 297 ++-
 2 files changed, 141 insertions(+), 163 deletions(-)

diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c b/sys/fs/nfsserver/nfs_nfsdserv.c
index 0c8bda6dc6a6..47e3a20390f4 100644
--- a/sys/fs/nfsserver/nfs_nfsdserv.c
+++ b/sys/fs/nfsserver/nfs_nfsdserv.c
@@ -3244,6 +3244,13 @@ nfsrvd_open(struct nfsrv_descript *nd, __unused int 
isdgram,
NFSM_BUILD(tl, u_int32_t *, 2 * NFSX_UNSIGNED);
*tl++ = txdr_unsigned(NFSV4OPEN_RESOURCE);
*tl = newnfs_false;
+   } else if ((rflags &
+   NFSV4OPEN_WDNOTSUPPDOWNGRADE) != 0) {
+   NFSM_BUILD(tl, uint32_t *, NFSX_UNSIGNED);
+   *tl = txdr_unsigned(NFSV4OPEN_NOTSUPPDOWNGRADE);
+   } else if ((rflags & NFSV4OPEN_WDNOTSUPPUPGRADE) != 0) {
+   NFSM_BUILD(tl, uint32_t *, NFSX_UNSIGNED);
+   *tl = txdr_unsigned(NFSV4OPEN_NOTSUPPUPGRADE);
} else {
NFSM_BUILD(tl, u_int32_t *, NFSX_UNSIGNED);
*tl = txdr_unsigned(NFSV4OPEN_NOTWANTED);
diff --git a/sys/fs/nfsserver/nfs_nfsdstate.c b/sys/fs/nfsserver/nfs_nfsdstate.c
index c73840277022..ce3f3481f04a 100644
--- a/sys/fs/nfsserver/nfs_nfsdstate.c
+++ b/sys/fs/nfsserver/nfs_nfsdstate.c
@@ -240,6 +240,11 @@ static int nfsrv_createdsfile(vnode_t vp, fhandle_t *fhp, 
struct pnfsdsfile *pf,
 static struct nfsdevice *nfsrv_findmirroredds(struct nfsmount *nmp);
 static int nfsrv_checkmachcred(int op, struct nfsrv_descript *nd,
 struct nfsclient *clp);
+static void nfsrv_issuedelegation(struct vnode *vp, struct nfsclient *clp,
+struct nfsrv_descript *nd, int delegate, int writedeleg, int readonly,
+u_quad_t filerev, uint64_t rdonly, struct nfsstate **new_delegp,
+struct nfsstate *new_stp, struct nfslockfile *lfp, uint32_t *rflagsp,
+nfsv4stateid_t *delegstateidp);
 
 /*
  * Scan the client list for a match and either return the current one,
@@ -442,7 +447,8 @@ nfsrv_setclient(struct nfsrv_descript *nd, struct nfsclient 
**new_clpp,
/*
 * If the verifier has changed, the client has rebooted
 * and a new client id is issued. The old state info
-* can be thrown away once the SETCLIENTID_CONFIRM occurs.
+* can be thrown away once the SetClientID_Confirm or
+* Create_Session that confirms the clientid occurs.
 */
LIST_REMOVE(clp, lc_hash);
 
@@ -2648,6 +2654,8 @@ tryagain:
 *considered a conflict since the client with a read delegation
 *could have done an Open with ReadAccess and WriteDeny
 *locally and then not have checked for the WriteDeny.)
+*The exception is a NFSv4.1/4.2 client that has requested
+*an atomic upgrade to a write delegation.
 * Don't check for a Reclaim, since that will be dealt with
 * by nfsrv_openctrl().
 */
@@ -2657,9 +2665,10 @@ tryagain:
while (stp != LIST_END(>lf_deleg)) {
nstp = LIST_NEXT(stp, ls_file);
if ((readonly && stp->ls_clp != clp &&
-  (stp->ls_flags & NFSLCK_DELEGWRITE)) ||
+(stp->ls_flags & NFSLCK_DELEGWRITE) != 0) ||
(!readonly && (stp->ls_clp != clp ||
-(stp->ls_flags & NFSLCK_DELEGREAD {
+((stp->ls_flags & NFSLCK_DELEGREAD) != 0 &&
+ (new_stp->ls_flags & NFSLCK_WANTWDELEG) == 0 {
ret = nfsrv_delegconflict(stp, , p, vp);
if (ret) {
   

Re: Deprecating smbfs(5) and removing it before FreeBSD 14

[Rick Macklem]

On Tue, Jun 4, 2024 at 5:18 PM Alan Somers  wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do 
> not click links or open attachments unless you recognize the sender and know 
> the content is safe. If in doubt, forward suspicious emails to 
> ith...@uoguelph.ca.
>
>
> On Tue, Jun 4, 2024 at 3:52 PM John Hixson  wrote:
> >
> > On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote:
> > > On 16/06/2022 15:56, Rick Macklem wrote:
> > > > Miroslav Lachman <000.f...@quip.cz> wrote:
> > > > > On 24/01/2022 16:13, Rick Macklem wrote:
> > > > >
> > > > [...]
> > > > >
> > > > > > So, I think Mark and Yuri are correct and looking at up to date
> > > > > > Illumos sources is the next step.
> > > > > > (As I mentioned, porting the Apple sources is beyond what I am
> > > > > >willing to attempt.)
> > > > > >
> > > > > > rick
> > > > >
> > > > > Hello Rick,
> > > > > I would like to ask you I there is some progress with porting newer
> > > > > SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a
> > > > > possibility where to start porting?
> > > > Yes. I have the stuff off Illumos-gate, which I think is pretty 
> > > > up-to-date
> > > > and I agree that it should be easier than the Apple stuff to port into
> > > > FreeBSD.  I don't think it is "straightforward" as someone involved
> > > > with Illumos said, due to the big differences in VFS/locking, but...
> > > >
> > > > Having said the above, I have not done much yet. I've been cleaning up
> > > > NFS stuff, although I am nearly done with that now.
> > > > I do plan on starting to work on it soon, but have no idea if/when I
> > > > will have something that might be useful for others.
> > >
> > > I'm glad to hear that.
> > >
> > > > > We have more and more problems with current state of mount_smbfs. I
> > > > > would be really glad if "somebody" can do the heroic work of
> > > > > implementing SMBv2 in FreeBSD.
> > > > > Maybe it's time to start some fundraising for sponsoring this work?
> > > > Well, funding isn't an issue for me (I'm just a retired guy who does 
> > > > this
> > > > stuff as a hobby). However, if there is someone else who is capable of
> > > > doing it if they are funded, I have no problem with that.
> > > > I could either help them, or simply stick with working on NFS and leave
> > > > SMBv23 to them.
> > > >
> > > > Sorry, but I cannot report real progress on this as yet, rick
> > >
> > > No need to sorry. I really appreciate your endless work on NFS and that 
> > > you
> > > still have kind of interest to try porting SMBv2/3.
> > > Unfortunately I don't know anybody else trying to do this tremendous work.
> > >
> >
> > I am working on a from scratch implementation of smbfs. I do not have
> > any kind of time estimate since it is in my spare time. I chose this
> > route after spending considerable time looking at Apple and Solaris
> > implementations and wanting something without all of the legacy 1.0
> > crap. I do have a very minimal working FUSE version at this point, but
> > there is much to do, and even more to abide by the various
> > specifications.
> >
> > I just thought I'd share in case anyone is interested.
Best of luck with it. I never got far into porting the Illumos code.

rick

> >
> > - John
>
> I am indeed interested.  smbfs is an important feature to have.  Let
> me know if you need help with the fuse parts.
> -Alan

Southwest Fox 2024: Registration opens!

[Rick Schummer]

We have officially opened registration for Southwest Fox 2024! The highly 
acclaimed developer conference is September
26-29, 2024. 

Southwest Fox is a hybrid conference: in-person and virtual. The in-person 
event will be held at the Hampton Inn &
Suites Phoenix-Scottsdale, the same location as last year, in the Phoenix 
suburb of Scottsdale. The virtual event will
use the RingCentral platform (the same platform we use for Virtual Fox Fest). 
All sessions will be presented in a single
room and will be streamed to the virtual event and recorded. This year we plan 
to add a second screen so people can see
the presentations easier from the back of the room.

The in-person conference room is small, so we have to limit registrations for 
the in-person event to the first 40 people
who register. Those who are not in the first 40 will be added to a wait list or 
can decide to register for the virtual
event. The virtual side of Southwest Fox can handle an unlimited number of 
attendees. If you really want to attend
in-person, we suggest you register as soon as practical. 

Super-Saver Registration for in-person, which saves you $200 (or $100 for 
virtual), is available only through June 30th,
so don't wait. Head over to the registration Web site today: 
https://geekgatherings.com/Registration. You'll have to
select either the in-person event or the virtual event.

Registration fees start at $599 for in-person and $349 for virtual. More 
details are available on the conference's
registration page.

Important hotel details:
We have a limited number of rooms at the hotel for those attending in-person. 
We will send you the link once we process
your registration. 

Flights
Please do NOT book your flights yet. Our hotel contract gives us some 
flexibility to see how registration is going
before we're absolutely committed. We'll let you know when it's time to book.

Here is what you can expect from Southwest Fox:
* Terrific selection of sessions from great presenters.
* A total of 15 regular conference topics to pack your days with learning 
opportunities and inspiration.
* Half-days on Thursday and Sunday for a more relaxed schedule and to make it 
easier for the virtual attendees.
* Lunch Friday and Saturday for all in-person attendees.

The conference website has been updated with this year's information and 
includes:
* News about the sessions and speakers.
* The general schedule.
* Specifics about the conference hotel.
* The conference blog where you can find our thoughts and perspectives.
* The link to our X (Twitter) feed.
* Opportunities for conference sponsorship.
* Ways you can help us promote the conference.

Contact Us
* Interested in being a sponsor? Contact our sponsor representative: 
spons...@geekgatherings.com
* If you have ideas or suggestions for this year's Southwest Fox, please email 
them to: i...@geekgatherings.com.
* If you have a friend who wants to be on our mailing list, please tell them to 
go to the conference home page and sign
up: https://swfox.net 

Make sure to share the news about the conference to all your developer friends. 
We appreciate any help with marketing
and word of mouth is one of the best ways to spread the news about our 
conference.

Rick Schummer
White Light Computing, Inc.




___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message: 
https://leafe.com/archives/byMID/022d01dab6d7$2ba94b70$82fbe250$@whitelightcomputing.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

[jira] [Commented] (HADOOP-18583) hadoop checknative fails to load openssl 3.x

[Rick Weber (Jira)]

[ 
https://issues.apache.org/jira/browse/HADOOP-18583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852190#comment-17852190
 ] 

Rick Weber commented on HADOOP-18583:
-

This may turn into a bit more of a security headache (ala Log4j'ish 1.x) in 
that the only "working" library that Hadoop can link against is now an obsolete 
library.  This has the potential to raise the hackles of security folks 
scanning where Hadoop is being implemented.

A quick scan of where OpenSSL is referenced suggests that:
 * OpenSSL is optional
 * It's part of an experimental feature for S3A acceleration
 * It's used to help accelerate the HDFS Encryption layer.

I'm not familiar with the code at all, but I do see the references to WildFly, 
and wonder if a reasonable path forward would be to incorporate updated 
libraries in as a solution to get better acceleration out of OpenSSL vs JSSE?

> hadoop checknative fails to load openssl 3.x
> 
>
> Key: HADOOP-18583
> URL: https://issues.apache.org/jira/browse/HADOOP-18583
> Project: Hadoop Common
>  Issue Type: Bug
>  Components: native
>Affects Versions: 3.3.4
>Reporter: Sebastian Klemke
>Priority: Major
>  Labels: pull-request-available
> Attachments: 100-hadoop-3.3.4-openssl-3.patch
>
>
> After building Hadoop 3.3.4 from source on Ubuntu 22.04, `hadoop checknative` 
> reports
> {code:java}
> $ hadoop checknative
> 2022-12-21 22:12:02,106 INFO bzip2.Bzip2Factory: Successfully loaded & 
> initialized native-bzip2 library system-native
> 2022-12-21 22:12:02,107 INFO zlib.ZlibFactory: Successfully loaded & 
> initialized native-zlib library
> 2022-12-21 22:12:02,130 INFO nativeio.NativeIO: The native code was built 
> without PMDK support.
> Native library checking:
> hadoop:  true /hadoop/lib/native/libhadoop.so.1.0.0
> zlib:    true /lib/x86_64-linux-gnu/libz.so.1
> zstd  :  true /lib/x86_64-linux-gnu/libzstd.so.1
> bzip2:   true /lib/x86_64-linux-gnu/libbz2.so.1
> openssl: false EVP_CIPHER_CTX_block_size
> ISA-L:   true /lib/x86_64-linux-gnu/libisal.so.2
> PMDK:    false The native code was built without PMDK support.{code}
> The issue seems to be at least two symbols that were removed from ABI in 
> OpenSSL 3.x releases:
>  * EVP_CIPHER_CTX_block_size (new name: EVP_CIPHER_CTX_get_block_size)
>  * EVP_CIPHER_CTX_encrypting (new name: EVP_CIPHER_CTX_is_encrypting)
> The attached patch [^100-hadoop-3.3.4-openssl-3.patch] works around the issue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org

[Bug 2068018] [NEW] Dist upgrade from Ubuntu 23.10 to 24.04 does not work

[Rick Gruber-Riemer]

Public bug reported:

A popup window states "Could not calculate the upgrade. An unresolvable
problem occured while calculating the upgrade. If none of this applies,
then please report this bug using ...

* It does not matter whether I am using the UI dist-upgrade or command line 
tool.
* First time I ran it the error message included stuff about ppa. I have 
removed both the packages of external ppa's and the sources.
* I did restart the computer
* Kubuntu 23.10

ProblemType: Bug
DistroRelease: Ubuntu 23.10
Package: ubuntu-release-upgrader-core 1:23.10.14
ProcVersionSignature: Ubuntu 6.5.0-35.35-generic 6.5.13
Uname: Linux 6.5.0-35-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.27.0-0ubuntu5
Architecture: amd64
CasperMD5CheckResult: unknown
CrashDB: ubuntu
CurrentDesktop: KDE
Date: Tue Jun  4 13:10:38 2024
InstallationDate: Installed on 2023-11-24 (193 days ago)
InstallationMedia: Kubuntu 23.10 "Mantic Minotaur" - Release amd64 (20231010)
PackageArchitecture: all
SourcePackage: ubuntu-release-upgrader
UpgradeStatus: Upgraded to mantic on 2024-06-04 (0 days ago)

** Affects: ubuntu-release-upgrader (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug dist-upgrade mantic

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2068018

Title:
  Dist upgrade from Ubuntu 23.10 to 24.04 does not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2068018/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[RE-wrenches] IRS Audit

[rick--- via RE-wrenches]

Wrenches,Has anyone had a customer that was being audited and requesting a manufacturers’ certification statement for their PV equipment?  The only manufacturer that has been able to provide a statement has been REC. I’m attaching a copy for reference. Is there an assumption that most equipment qualifies? The IRS definition for “qualified solar electric property” is pretty vague - "Qualified solar electric property expenditure. The term "qualified solar electric property expenditure" means an expenditure for property which uses solar energy to generate electricity for use in a dwelling unit located in the United States and used as a residence by the taxpayer."Thanks,,

Manufacturers Certification Statement April 2024.pdf
Description: Adobe PDF document
	
rick brownSolShine Energy Alternatives, LLCElectrical & Solar Contracting Serviceswww.SolShineEnergy.comRoanoke, VAOffice: 540.235.3095Mobile: 540.808.9502VA Class A Contractor Lic# 2705147660VA Master Electrician Lic# 2710062762VA Alternative Energy Systems Installer  NABCEP Certified PV Installation Professional 110112-21CONFIDENTIALITY NOTICE -- This email is intended only for the person(s) named inthe message header. Unless otherwise indicated, it contains information that isconfidential, privileged and/or exempt from disclosure under applicable law. If you havereceived this message in error, please notify the sender of the error and delete themessage. Thank you.”


___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try the other:
https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org

Re: [Oorexx-devel] Another question

[Rick McGuire]

The CLASS methods are the instance methods of the class object, so you
would use the instanceMethods() method to retrieve them.

Rick

On Mon, Jun 3, 2024 at 3:17 PM Gilbert Barmwater 
wrote:

> Let's say there is a class defined via ::class myClass.  It has numerous
> methods, both instance methods and class methods. If I want to enumerate
> the instance methods, supp = .myClass~methods will give me a supplier
> that will do so.  If I specify supp = .myClass~methods(.nil), the
> supplied list will only be the methods specific to myClass and not
> include any inherited ones.  Is there a way to enumerate the CLASS
> methods of myClass,  preferably those specific to myClass?
>
> --
> Gil Barmwater
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[BVARC] DX Summit Listings for Museum Ships

[Rick Hiller via BVARC]

http://www.k1usn.com/index.html


DXSUMMIT link for MSW ships


GL5RH

Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

[cctalk] Re: Experience using an Altair 8800 ("Personal computer" from 70s)

[Rick Bensene via cctalk]

 that used 74S181 high-speed ALU slices, 
and a microcoded architecture.  The cool thing is that the microcode store was 
writable!  It had up to 2M (256K minimum) of 64-bit wide RAM (with a 16-bit 
bus), and a built-in 12MB or 24MB hard disk drive and an 8" floppy drive. It 
also had a 768x1024 bitmapped monochrome (portrait) display, and a graphics 
tablet.   It cost somewhere between $20,000 and $27,500 in base form, with the 
variance being uncertainties in prices due to varying configurations that have 
price information available, but not much in the way of actual configuration.   

Yes, that's a bit much for someone to buy as a personal computer, but it's 
certainly possible for a person of substantial means.   It wasn't a multi-user 
system, it was intended to be used by a single person sitting at the machine.   
It plugged into a regular wall outlet.   It actually had a GUI, perhaps one of 
the earliest to exist, and was something that did not exist for the 
storage-tube Tektronix machines or most certainly not for an HP 9830.

I'm absolutely not arguing with Liam's point.
 
I do believe that the microprocessor was the driving force in making possible a 
device that fits the full definition of a computer, that an average person 
could buy, take home and unpack and set up in fairly short order, and be up and 
running with their TV as a display, running BASIC, and a cassette tape recorder 
for storing and loading programs.
A true personal computer, no doubt.

I think that in a general sense, it certainly fits that a personal computer is 
more commonly a microcomputer, and thus, has a microprocessor (perhaps more 
than one) as its main processing element.  

With that said, any time that generalities are used, there always seem to be 
exceptions that sneak their way in and cloud any general definition of a term.  
 I believer that as  time goes on, the definition is going to get more and more 
difficult.

With technology advancing as fast as it is, it seems feasible that a small 
device could be  implanted in one's brain that utilizes generation of neural 
impulses to generate imagery that appears as it is being seen by the eyes, and 
similarly with sound, and communicates at least initially by recognizing spoken 
commands (and likely later, just thinking about what you want done), that is 
connected to (whatever the Internet becomes) full time, with full AI 
capabilities embedded as part of its operation.  I believe one of Elon Musk's 
companies is working on that and has been for some time.Perhaps that device 
may well redefine the meaning of a "personal" computer.

Perhaps more appropriately the "computer personal" (the computer first, the 
person secondary).   

Would I want one?  Hell no.

-Rick
--
Rick Bensene
The Old Calculator Museum
https://oldcalculatormuseum.com
Beavercreek, Oregon   USA

git: 4c136aad80e6 - stable/14 - svc.c: Check for a non-NULL xp_socket

[Rick Macklem]

The branch stable/14 has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=4c136aad80e6da1c9aa99de863642fe64a54f9a8

commit 4c136aad80e6da1c9aa99de863642fe64a54f9a8
Author: Rick Macklem 
AuthorDate: 2024-05-28 02:22:04 +
Commit: Rick Macklem 
CommitDate: 2024-05-31 22:35:18 +

svc.c: Check for a non-NULL xp_socket

Commit a16ff32f04b5 added support to the kernel RPC to set
TCP_USE_DDP.
However, for the unusual case of a NFSv4.1/4.2 non-NULL callback,
the xp_socket field of SVCXPRT is NULL, since it uses the same
socket as the client->server connection.

This patch adds the check for this to avoid crashes.

This only affects NFSv4.1/4.2 mounts where either pNFS or
delegations are in use.

(cherry picked from commit 6c9170e0afc4ebec81ba88a6370ebf6cb55520ba)
---
 sys/rpc/svc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sys/rpc/svc.c b/sys/rpc/svc.c
index 6d19a0b1ea7d..1e0e02c23cc1 100644
--- a/sys/rpc/svc.c
+++ b/sys/rpc/svc.c
@@ -1000,6 +1000,7 @@ svc_getreq(SVCXPRT *xprt, struct svc_req **rqstp_ret)
 * enable TLS offload first.
 */
if (xprt->xp_doneddp == 0 && r->rq_proc != NULLPROC &&
+   xprt->xp_socket != NULL &&
atomic_cmpset_int(>xp_doneddp, 0, 1)) {
if (xprt->xp_socket->so_proto->pr_protocol ==
IPPROTO_TCP) {

Re: [Oorexx-devel] Clarification on .package~new

[Rick McGuire]

Then the docs need to be fixed. In general, a package object does all of
it's required initialization on its creation. This includes fully doing all
initializations required by the class objects.

Rick

On Fri, May 31, 2024 at 3:00 PM Gilbert Barmwater 
wrote:

> I've been experimenting with the .package class and have run into
> somewhat puzzling behavior.  I am trying to create a .package object
> from a file which, according to the documentation, should look like this:
>
> thePkg=.package~new(fileName)
>
> When I do this I DO get a package in thePkg, BUT the package also gets
> loaded(executed) as if I had issued a
> .context~package~loadPackage(fileName).
>
> The docs do not indicate that this is to be expected.  Help!
>
> --
> Gil Barmwater
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: Status Update K-3 repairs and OT photos

[Rick Womer]

Nice pic!  The colors and composition are nice, and I really like the contrast 
between the motion-blurred truck and the permanently-stationary tractor.

Rick

> On May 31, 2024, at 3:47 AM, Ralf R Radermacher  wrote:
> 
> Am 31.05.24 um 08:17 schrieb Larry Colen:
>> https://www.flickr.com/photos/ellarsee/53755809787/in/album-72177720317430356/
> 
> Interesting and well done.
> 
> Ralf
> 
> -- 
> Ralf R. Radermacher  -  Köln/Cologne, Germany
> Blog  :http://the-real-fotoralf.blogspot.com
> Audio :http://aporee.org/maps/projects/fotoralf
> Fotos :https://www.fotocommunity.de/user_photos/770012
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
> the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: Upgrade by cutting a wire?

[Rick Troth]

This kind of thing is so common. Maybe it was majic in the 1980s. But 
now, everything is digital and pre-programmed at the factory.


I have a shiny new Icom IC-7300 transceiver. (That's ham radio talk.) It 
has a general coverage receiver, all modes from like 0 to somewhere past 
54MHz. But it will only *transmit* on frequencies legal to US radio 
amateurs ... at the time of manufacture.
I'VE BEEN TOLD that there is a diode I can clip or remove that will 
negate the transmit lockout.


Legally, I'm not supposed to transmit on (e.g.) 870KHz broadcast AM, and 
I'm not interested in setting up a pirate station. But hams are into 
disaster preparedness. In a crisis, I might *need* to transmit on radio 
frequencies that I'm not normally authorized for. (Not to mention that I 
hate the whole nanny thing.) So ... yeah ... I might "upgrade by cutting 
a wire" soonish.


Not mainframe, but kinda related. And your fault for making me think of 
it. *:-)*



-- R; <><


On 5/31/24 9:49 AM, Phil Smith III wrote:

I remember hearing that some Amdahl 370 clone was upgradable by cutting a wire. 
Anyone else ever hear this? Can't find a cite on the web.

Just curiosity, no real point to this...! (But it is Friday.)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [PATCHv6 bpf-next 1/9] x86/shstk: Make return uprobe work with shadow stack

[Edgecombe, Rick P]

On Tue, 2024-05-21 at 12:48 +0200, Jiri Olsa wrote:
> Currently the application with enabled shadow stack will crash
> if it sets up return uprobe. The reason is the uretprobe kernel
> code changes the user space task's stack, but does not update
> shadow stack accordingly.
> 
> Adding new functions to update values on shadow stack and using
> them in uprobe code to keep shadow stack in sync with uretprobe
> changes to user stack.
> 
> Fixes: 8b1c23543436 ("x86/shstk: Add return uprobe support")
> Signed-off-by: Jiri Olsa 
> ---
Acked-by: Rick Edgecombe 

Re: [MBZ] OT: RR (not Mercedes) content

[Rick Knoble via Mercedes]

For $6k I'd rather have this.
https://m.facebook.com/marketplace/item/926483832496420/?ref=search

Get Outlook for Android

From: Mercedes  on behalf of Andrew Strasfogel 
via Mercedes 
Sent: Thursday, May 30, 2024 10:50:15 AM
To: Mercedes Discussion List 
Cc: Andrew Strasfogel 
Subject: [MBZ] OT: RR (not Mercedes) content

Not even Kaleb has one of these.  Seems very affordable...
https://carsandbids.com/auctions/rkeYE4Rg/1986-elmco-royal-ride-golf-cart?
___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

Re: [BVARC] Field Day Kick-Off Meeting

[Rick Hiller via BVARC]

Same time as GHHF meeting…..right?
RH
Sent from my i-Thingamajig

> On May 29, 2024, at 9:09 AM, Jeff Greer via BVARC  wrote:
> 
> 
> BVARC Admin is inviting you to a scheduled Zoom meeting.
> 
> Topic: Field Day Kick Off Meeting
> Time: May 30, 2024 07:00 PM Central Time (US and Canada)
> 
> Join Zoom Meeting
> https://us02web.zoom.us/j/82210720754?pwd=NJknaYVJqSEceRdGq3W0MT8Z1e6Epo.1
> 
> Meeting ID: 822 1072 0754
> Passcode: 827744
> 
> ---
> 
> One tap mobile
> +13462487799,,82210720754#*827744# US (Houston)
> +12532158782,,82210720754#*827744# US (Tacoma)
> 
> ---
> 
> Dial by your location
> • +1 346 248 7799 US (Houston)
> • +1 253 215 8782 US (Tacoma)
> • +1 669 444 9171 US
> • +1 669 900 9128 US (San Jose)
> • +1 719 359 4580 US
> • +1 253 205 0468 US
> • +1 312 626 6799 US (Chicago)
> • +1 360 209 5623 US
> • +1 386 347 5053 US
> • +1 507 473 4847 US
> • +1 564 217 2000 US
> • +1 646 558 8656 US (New York)
> • +1 646 931 3860 US
> • +1 689 278 1000 US
> • +1 301 715 8592 US (Washington DC)
> • +1 305 224 1968 US
> • +1 309 205 3325 US
> 
> Meeting ID: 822 1072 0754
> Passcode: 827744
> 
> Find your local number: https://us02web.zoom.us/u/kws6daRi1
> 
> 
> Brazos Valley Amateur Radio Club
> 
> BVARC mailing list
> BVARC@bvarc.org
> http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
> Publicly available archives are available here: 
> https://www.mail-archive.com/bvarc@bvarc.org/

Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

Re: [BVARC] Mobile antenna tuning question

[Rick Hiller via BVARC]

Since the meter is new to you……put a 50 ohm resistor across the uhf port to see if it measures properly……. to check calibration.   I keep  an assortment of resistors in my MFJ analyzer box to check calibration.  25, 50, 75, 100 and 200.   Used to ensure the darn thing is working, as it is easily affected by stray RF.    Just like the O, S, L calibration on a vna.   Gl. 73.  Rick.  W5RHSent from my i-ThingamajigOn May 28, 2024, at 9:39 PM, Robert Polinski via BVARC  wrote:Terry, first I would put a swr watt meter (Bird) in line and see what the SWR is. Many of the low price meters do poorly on UHF. Having installed 1000s of UHF ant on commercial vehicles. They like to be in direct contact with a ground plane. If the antenna will detach from its base ( mon or UHF mount) try it on a mag mount on the roof and take another reading. I have a headache rack on my truck and the UHF antennas did poorly on them, I moved them to the roof and all worked great. If you do not have access to a Bird wattmeter I can bring mine to the next meeting. Robert KD5YVQ  From: BVARC  On Behalf Of terry leatherland via BVARCSent: Tuesday, May 28, 2024 4:57 PMTo: Eddie Runner ; BRAZOS VALLEY AMATEUR RADIO CLUB Cc: terry leatherland Subject: Re: [BVARC] Mobile antenna tuning question That wasn’t it.  I used the uhf connector port and it’s still swr off the chart. Sent from Yahoo Mail for iPhone On Tuesday, May 28, 2024, 10:23 AM, Eddie Runner <eddie.run...@yahoo.com> wrote:I would call COMET and see if this is normal...Eddie (NU5K) On Monday, May 27, 2024 at 06:34:01 PM CDT, terry leatherland via BVARC <bvarc@bvarc.org> wrote:   I'm sure someone knows about Mobile antennas. Our friends at River Oaks Car Stereo for sure. Anthony?Here is my dilemma , or something I am doing wrong.  I bought this antenna to mount on my new truck. I have a brand new Comet analyzer. The antenna is hood lip mounted with a comet Hood mount. When I analyze the raw antenna thru its one piece of coax, it is perfect 1.5 or less on 2Meters @ 50ohms. But when I dial up  to 440 Mhz, the swr and Ohms is off the chart.My radio is my old reliable Kenwood TMV71 of which I have 3 identical. Shouldn't I be able to just change the band knob to 430 and it read good SWR?  Do I have to find the resonant point of the upper band and start trimming the top length down to 440 good swr?I'm perplexed or doing something dumb.  Terry  Terry Leatherland, K5PGF281-455-8090Sugar Land, Tx Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ 
Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

Re: [MBZ] OT - Ultrasonic Cleaners

[Rick Knoble via Mercedes]

Yep. He recommended a Branson. They are on eBay.

Rick

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Mercedes  on behalf of Craig via Mercedes 

Sent: Tuesday, May 28, 2024 9:13:09 PM
To: Mercedes Discussion List 
Cc: Craig 
Subject: Re: [MBZ] OT - Ultrasonic Cleaners

On Tue, 28 May 2024 21:41:22 -0400 Allan Streib via Mercedes
 wrote:

> Keep an eye on govdeals.com for university surplus. I don’t see any at
> the moment but would guess they are available from time to time.

Try asking Jamie, too. We had a discussion about ultrasonic cleaners in
the past.


Craig

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

Re: EBCDIC/ASCII - FTP

[Rick Troth]

Bingo!

I remember that pain well.
But I was on CMS and could do a pair of 'SET OUTPUT' commands to get 
proper behavior with a 3279. (And matching 'SET INPUT' commands.)
If you're on ISPF then I don't know what to tell ya. But if you find a 
fix, do share!


Hang in there Tronguy.


-- R; <><


On 5/28/24 8:46 AM, Jay Maynard wrote:

As it happens, I'm dealing with this...have a small task to do some C, and
discovered the hard way that the 3279, while having the square brackets in
its normal character set, doesn't have them at the same code points as
later IBM OSes expect. tn3270 shows them fine, though.

On Tue, May 28, 2024 at 7:43 AM Rick Troth <
058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> wrote:


Hi Tom --

You're not wrong.
The musical code pages have led to multiplied complexities.

Living in the US, I've had it easier than some, and in most cases I can
(and do) treat "EBCDIC" as CP1047 (with an exception around not and
circumflex). CP37 came first, and was "close" but got the square
brackets wrong (as most US installations used them). But with "CP37v2"
there is a one-for-one mapping with ISO-8859-1, and that's the A/E table
from which I start. It's not just me, many official implementations
(witness Dignus) use the same A/E mapping as their default.

EBCDIC representations like "CP 37 version 2" were drummed-up by
customers. In the early 1990s, there was a concerted effort (including a
SHARE project) to solidify a standard. IBM took the requirements to
heart, thus we have CP1047 (which is "CP37v2" except for logical not
versus circumflex). But this all remains an 8-bit solution.

The ASCII world also had multiple code pages (such as ISO-8859-1) but
then embraced Unicode and such encodings as UTF-8.
But mapping EBCDIC of any code page into UTF-8 is more than I know how
to do (reliably, unless I had source to the FTP client and hacked it
appropriately).
So to the original question, best practice is to have the z/OS side
handle the translation. ISO-8859-1 is most closely covered by CP819, so
the "*10470819*" mapping is what you want.
On the ASCII side, ISO-8859-1 *might* be usable as-is, but if not then
it can be easily converted to UTF-8. But that's a question for the ASCII
consumers of the data.

-- R; <><




On 5/8/24 12:45 PM, Tom Marchant wrote:

"This" is the link that Gil provided in the email that I replied to, at

the bottom of the post. The assertion was that IBM erred in not making the
System/360 ASCII only.

The availability of multiple EBCDIC code pages seems to me to make

Beemer's assertion that there is a 1 to 1 correspondence between ASCII and
EBCDIC even more dubious.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Rick Troth]

Hi Tom --

You're not wrong.
The musical code pages have led to multiplied complexities.

Living in the US, I've had it easier than some, and in most cases I can 
(and do) treat "EBCDIC" as CP1047 (with an exception around not and 
circumflex). CP37 came first, and was "close" but got the square 
brackets wrong (as most US installations used them). But with "CP37v2" 
there is a one-for-one mapping with ISO-8859-1, and that's the A/E table 
from which I start. It's not just me, many official implementations 
(witness Dignus) use the same A/E mapping as their default.


EBCDIC representations like "CP 37 version 2" were drummed-up by 
customers. In the early 1990s, there was a concerted effort (including a 
SHARE project) to solidify a standard. IBM took the requirements to 
heart, thus we have CP1047 (which is "CP37v2" except for logical not 
versus circumflex). But this all remains an 8-bit solution.


The ASCII world also had multiple code pages (such as ISO-8859-1) but 
then embraced Unicode and such encodings as UTF-8.
But mapping EBCDIC of any code page into UTF-8 is more than I know how 
to do (reliably, unless I had source to the FTP client and hacked it 
appropriately).
So to the original question, best practice is to have the z/OS side 
handle the translation. ISO-8859-1 is most closely covered by CP819, so 
the "*10470819*" mapping is what you want.
On the ASCII side, ISO-8859-1 *might* be usable as-is, but if not then 
it can be easily converted to UTF-8. But that's a question for the ASCII 
consumers of the data.


-- R; <><




On 5/8/24 12:45 PM, Tom Marchant wrote:

"This" is the link that Gil provided in the email that I replied to, at the 
bottom of the post. The assertion was that IBM erred in not making the System/360 ASCII 
only.

The availability of multiple EBCDIC code pages seems to me to make Beemer's 
assertion that there is a 1 to 1 correspondence between ASCII and EBCDIC even 
more dubious.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

git: 6c9170e0afc4 - main - svc.c: Check for a non-NULL xp_socket

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=6c9170e0afc4ebec81ba88a6370ebf6cb55520ba

commit 6c9170e0afc4ebec81ba88a6370ebf6cb55520ba
Author: Rick Macklem 
AuthorDate: 2024-05-28 02:22:04 +
Commit: Rick Macklem 
CommitDate: 2024-05-28 02:22:04 +

svc.c: Check for a non-NULL xp_socket

Commit a16ff32f04b5 added support to the kernel RPC to set
TCP_USE_DDP.
However, for the unusual case of a NFSv4.1/4.2 non-NULL callback,
the xp_socket field of SVCXPRT is NULL, since it uses the same
socket as the client->server connection.

This patch adds the check for this to avoid crashes.

This only affects NFSv4.1/4.2 mounts where either pNFS or
delegations are in use.

MFC after:  3 days
---
 sys/rpc/svc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sys/rpc/svc.c b/sys/rpc/svc.c
index 99678f693a3e..f94e744d40f4 100644
--- a/sys/rpc/svc.c
+++ b/sys/rpc/svc.c
@@ -996,6 +996,7 @@ svc_getreq(SVCXPRT *xprt, struct svc_req **rqstp_ret)
 * enable TLS offload first.
 */
if (xprt->xp_doneddp == 0 && r->rq_proc != NULLPROC &&
+   xprt->xp_socket != NULL &&
atomic_cmpset_int(>xp_doneddp, 0, 1)) {
if (xprt->xp_socket->so_proto->pr_protocol ==
IPPROTO_TCP) {

git: 6c9170e0afc4 - main - svc.c: Check for a non-NULL xp_socket

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=6c9170e0afc4ebec81ba88a6370ebf6cb55520ba

commit 6c9170e0afc4ebec81ba88a6370ebf6cb55520ba
Author: Rick Macklem 
AuthorDate: 2024-05-28 02:22:04 +
Commit: Rick Macklem 
CommitDate: 2024-05-28 02:22:04 +

svc.c: Check for a non-NULL xp_socket

Commit a16ff32f04b5 added support to the kernel RPC to set
TCP_USE_DDP.
However, for the unusual case of a NFSv4.1/4.2 non-NULL callback,
the xp_socket field of SVCXPRT is NULL, since it uses the same
socket as the client->server connection.

This patch adds the check for this to avoid crashes.

This only affects NFSv4.1/4.2 mounts where either pNFS or
delegations are in use.

MFC after:  3 days
---
 sys/rpc/svc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sys/rpc/svc.c b/sys/rpc/svc.c
index 99678f693a3e..f94e744d40f4 100644
--- a/sys/rpc/svc.c
+++ b/sys/rpc/svc.c
@@ -996,6 +996,7 @@ svc_getreq(SVCXPRT *xprt, struct svc_req **rqstp_ret)
 * enable TLS offload first.
 */
if (xprt->xp_doneddp == 0 && r->rq_proc != NULLPROC &&
+   xprt->xp_socket != NULL &&
atomic_cmpset_int(>xp_doneddp, 0, 1)) {
if (xprt->xp_socket->so_proto->pr_protocol ==
IPPROTO_TCP) {

Re: [Kea-users] Advice for reconfigured reservations when implementing VLANs

[Rick Frey]

Ad David suggested, getting a packet capture will help you determine if the 
discover packets are reaching your Kea DHCP server when not using a DHCP relay 
on your pFsense firewall.  On the surface it would appear that your Kea host is 
not seeing the broadcast packets on the three VLANs since you mention Kea 
“somewhat” works when using your DHCP relay.

The most recent version of pfsense also includes the latest stable Kea 2.4.1 
version.  Not sure of your requirements, but you may want to consider using the 
Kea DHCP server on your pfsense gateway/firewall to simplify setup.  Note that 
pfsense has not implemented means to to configure all Kea features yet, but if 
you’re not using things such as DDNS updates from Kea, the pfsense version may 
suit your needs (and it’s more current than version you’re currently running).

-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Re: [MBZ] I picked up the 95k mile 1 owner e300

[Rick Knoble via Mercedes]

Sell it to John Woods and let him make a few bucks. Or sell it to Dean Laumbach 
and watch him flip it for $50k.

Rick

Get Outlook for Android<https://aka.ms/AAb9ysg>

From: Mercedes  on behalf of dan penoff.com via 
Mercedes 
Sent: Saturday, May 25, 2024 8:43:21 PM
To: Okie Benz 
Cc: dan penoff.com 
Subject: Re: [MBZ] I picked up the 95k mile 1 owner e300

Nope. Let it go to the Back 40 where everything else ends up.

-D

> On May 25, 2024, at 6:40 PM, Buggered Benzmail via Mercedes 
>  wrote:
>
> Sell it to Poos
>
> --FT
> Sent from iFōn
>
>> On May 25, 2024, at 8:52 PM, Kaleb Striplin via Mercedes 
>>  wrote:
>>
>> I will probably dump it off in the back 40 for a few years. It definitely 
>> needs some Martha love.
>>
>>
>> Sent from my iPhone
>>
>>> On May 25, 2024, at 7:42 PM, Buggered Benzmail via Mercedes 
>>>  wrote:
>>>
>>> Nice!  Keep us posted on how it comes back to life
>>>
>>> --FT
>>> Sent from iFōn
>>>
>>>>> On May 25, 2024, at 7:26 PM, Kaleb Striplin via Mercedes 
>>>>>  wrote:
>>>>
>>>> Car is nice, will clean up. Currently the throttle linkage is sticky from 
>>>> sitting and has no brakes.  Original owner was Michael Doucet, supposedly 
>>>> a famous musician. I have never heard of him. Anyway, if he really is a 
>>>> big deal, just was at his house today.
>>>>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>
>>>> Sent from my iPhone___
>>>> http://www.okiebenz.com
>>>>
>>>> To search list archives http://www.okiebenz.com/archive/
>>>>
>>>> To Unsubscribe or change delivery options go to:
>>>> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
>>>>
>>>
>>> ___
>>> http://www.okiebenz.com
>>>
>>> To search list archives http://www.okiebenz.com/archive/
>>>
>>> To Unsubscribe or change delivery options go to:
>>> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
>>>
>>
>>
>> ___
>> http://www.okiebenz.com
>>
>> To search list archives http://www.okiebenz.com/archive/
>>
>> To Unsubscribe or change delivery options go to:
>> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
>>
>
> ___
> http://www.okiebenz.com
>
> To search list archives http://www.okiebenz.com/archive/
>
> To Unsubscribe or change delivery options go to:
> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
>

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

[cctalk] Re: terminology [was: First Personal Computer]

[Rick Bensene via cctalk]

Mike Katz wrote:

> I'm sorry but you are misinformed about the HP-41C Calculator.

> The HP-41 was the first calculator that had Alpha-Numerics.

That is not true.  

Technically, out of the box, it was the HP 9830.  Yes, it wasn't a handheld 
calculator, and it didn't run on batteries(it was big and quite heavy and 
required standard 115V AC power), but it had an alpha-numeric display(and 
optionally a printer) that could be programmatically written to, and the 
machine could accept alpha-numeric input and process it as such.

The HP 9820 had an alphanumeric display, and could be programmed to generate 
alphanumeric prompts on the display, but I don't believe (off the top of my 
head, I could be wrong) it had the capability to accept and process 
alpha-numerics out of the box.

The HP 9820 and 9830 were introduced in June of 1972.  Seven years before the 
HP-41.

-Rick
--
Rick Bensene
The Old Calculator Museum
https://oldcalculatormuseum.com
Beavercreek, OR  USA

[cctalk] Re: terminology [was: First Personal Computer]

[Rick Bensene via cctalk]

Carey S. writes:

> If it only manipulates numeric data, it is a calculator.  It must be able to 
> search, 
> rearrange look up, compare, and display characters.  I would have thought 
> that to be
> obvious.   ...if it cannot give a text description of the answer, it is 
> a 
> calculator.

> Also something about arbitrary branches to any location (ok, any executable 
> location if 
> something has separate code and data memory).

So, are the HP 9820, HP 9830, Tektronix 31, Tektronix 4051, and the Texas 
Instruments 
SR-60 calculators or computers?

All of them were at least initially marketed as calculators(except perhaps the 
4051, but it could definitely serve as a calculator, though massive overkill).

This was because if someone submitted a capital equipment request for a 
"computer", bean counters would immediately reject it, while calculators would 
sail right through.   

Why?   

Because computers were big complicated machines that required expensive, brainy 
people to support, and they needed all kinds of "extras" like special power, 
air conditioning, storage systems,  printers, terminals, maintenance contracts, 
installation fees, and other stuff that cost even more money.  At least, that 
was the mentality, be it right or wrong.  It has been historically documented 
as such in numerous books written about that period in time.

Calculators... well, you just took 'em out of the box, set them on the desk, 
plugged them in and off you go.  Didn’t really matter if it was a four-banger, 
or something like an HP 9830(if all you wanted to do was calculate with it).

With machines like this, engineers and scientists could get themselves a 
"computer" without the fuss of having to say it was a computer on their 
equipment request.

All of the above devices could be programmed to manipulate and display and/or 
print alpha-numeric and special characters, They could be programmed to search, 
compare, find, re-arrange, sort, combine, and manipulate numerical and 
non-numerical data.

They all also had the ability to branch to an arbitrary location within a 
program, though off the top of my head, I think that all of the machines except 
the 4051(EXEC) (and maybe  the HP 9830, I can't remember off the top of my head 
- it may have required a special ROM module to be added in order to do that) 
didn't have the ability to branch to arbitrary data in memory and execute it.

All of the named machines certainly could qualify as a computer, right?
  
At the same time, each of them could have a mathematical expression (some even 
with variables) entered as it would be written on paper, without any 
programming, and they would display/print the numeric result after pressing a 
single key to terminate the entry.  These expressions could include functions 
such as logarithms, trig, roots, exponentials, etc., just like a calculator.  

Perhaps that really does make them calculators?

Why did Digital Equipment Corporation brand their computers as "PDP"?  It was 
an acronym for "Programmed Data Processor".  A "PDP" isn't a computer for all 
bean counters might know. The point of this designation (which was only the PDP 
part, not its expansion) was to allow capital requests to get through the 
approval process without the fussy "computer" word in the request.  

You'd just write down "PDP 11/70" on the request.   As long as the money was in 
your budget, the worst that might happen is someone from finance may ring you 
up and ask you "What's a PDP 11/70?", and you could say, "Oh, it's a really 
fancy calculator" (not a lie), and they'd go away happy, and your request would 
be granted, even if it amounted to tens of thousands (or more) dollars.  

Weeks later, you'd have an really powerful Programmed Data Processor show up at 
the loading dock, no one really the wiser.

This is probably exaggerating the reality a bit, but the true point of the PDP 
designation was to make it easier for engineers, scientists, and anyone else 
that needed a real computer but had a bureaucracy to go through before they 
could get one.

Perhaps the distinction noted isn't quite as clear cut as indicated.

-Rick

PS: Carey, I am working on a response to your message from yesterday, it's just 
taking a while, hopefully it'll arrive to you later today or tomorrow sometime.
--
Rick Bensene
The Old Calculator Museum
https://oldcalculatormuseum.com

Re: Paris

[Rick Womer]

Stan, I now have a surge protector / uninterruptible power supply for my 
computer, and a surge protector for our mini split AC/heating system (whose 
board also got toasted). Alas our electrician fell ill and went out of 
business, and we haven’t identified another one yet to put in a surge protector 
for the rest of the house.

Rick

> On May 24, 2024, at 8:53 PM, Stan Halpin  wrote:
> 
> A long delayed OT comment re your power surge and related computer issues…
> 
> Several years ago our trusted local electrician installed a whole-house surge 
> protector. A relatively small attachment on the main panel. I think it has 
> worked properly, we’ve had no issues even when neighbors were having storm 
> surge problems.
> 
> Stan
> 
> Sent from my iPad
> 
>> On May 24, 2024, at 4:21 PM, Rick Womer  wrote:
>> 
>> It’s -only- been five months since our autumn trip to France, and I’m 
>> finally getting around to posting some pics. (My photo computer and hard 
>> drives took a hit from a nasty power surge, which took a long time to sort 
>> out).
>> 
>> Paris was our first stop, so more are coming.
>> 
>> https://rickwomer.smugmug.com/2023/Paris-Oct-23
>> 
>> Comments always appreciated!
>> 
>> Rick
>> --
>> %(real_name)s Pentax-Discuss Mail List
>> To unsubscribe send an email to pdml-le...@pdml.net
>> to UNSUBSCRIBE from the PDML, please visit the link directly above and 
>> follow the directions.
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
> the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

git: c68db4608ef6 - main - Revert "nfscl: Do not do readahead for directories"

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=c68db4608ef63534a001b55de80995e1c3442d2a

commit c68db4608ef63534a001b55de80995e1c3442d2a
Author: Rick Macklem 
AuthorDate: 2024-05-26 15:02:30 +
Commit: Rick Macklem 
CommitDate: 2024-05-26 15:02:30 +

Revert "nfscl: Do not do readahead for directories"

The PR reported hangs that were avoided when this commit was
reverted.  Since it was only a cleanup, revert it.
The LORs in the PR need further investigation, since I think
readahead only hides the problem.

PR: 279138
This reverts commit fbe965591f8a0a32c805a279a2505d4c20d22d26.
---
 sys/fs/nfsclient/nfs_clbio.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
index fe2ed0dff0dd..e181bf593e23 100644
--- a/sys/fs/nfsclient/nfs_clbio.c
+++ b/sys/fs/nfsclient/nfs_clbio.c
@@ -679,6 +679,36 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int ioflag, 
struct ucred *cred)
goto out;
}
 
+   /*
+* If not eof and read aheads are enabled, start one.
+* (You need the current block first, so that you have the
+*  directory offset cookie of the next block.)
+*/
+   NFSLOCKNODE(np);
+   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
+   (bp->b_flags & B_INVAL) == 0 &&
+   (np->n_direofoffset == 0 ||
+   (lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
+   incore(>v_bufobj, lbn + 1) == NULL) {
+   NFSUNLOCKNODE(np);
+   rabp = nfs_getcacheblk(vp, lbn + 1, NFS_DIRBLKSIZ, td);
+   if (rabp) {
+   if ((rabp->b_flags & (B_CACHE|B_DELWRI)) == 0) {
+   rabp->b_flags |= B_ASYNC;
+   rabp->b_iocmd = BIO_READ;
+   vfs_busy_pages(rabp, 0);
+   if (ncl_asyncio(nmp, rabp, cred, td)) {
+   rabp->b_flags |= B_INVAL;
+   rabp->b_ioflags |= BIO_ERROR;
+   vfs_unbusy_pages(rabp);
+   brelse(rabp);
+   }
+   } else {
+   brelse(rabp);
+   }
+   }
+   NFSLOCKNODE(np);
+   }
/*
 * Unlike VREG files, whos buffer size ( bp->b_bcount ) is
 * chopped for the EOF condition, we cannot tell how large
@@ -691,7 +721,6 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int ioflag, 
struct ucred *cred)
 * in np->n_direofoffset and chop it off as an extra step
 * right here.
 */
-   NFSLOCKNODE(np);
n = lmin(uio->uio_resid, NFS_DIRBLKSIZ - bp->b_resid - on);
if (np->n_direofoffset && n > np->n_direofoffset - 
uio->uio_offset)
n = np->n_direofoffset - uio->uio_offset;

git: c68db4608ef6 - main - Revert "nfscl: Do not do readahead for directories"

[Rick Macklem]

The branch main has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=c68db4608ef63534a001b55de80995e1c3442d2a

commit c68db4608ef63534a001b55de80995e1c3442d2a
Author: Rick Macklem 
AuthorDate: 2024-05-26 15:02:30 +
Commit: Rick Macklem 
CommitDate: 2024-05-26 15:02:30 +

Revert "nfscl: Do not do readahead for directories"

The PR reported hangs that were avoided when this commit was
reverted.  Since it was only a cleanup, revert it.
The LORs in the PR need further investigation, since I think
readahead only hides the problem.

PR: 279138
This reverts commit fbe965591f8a0a32c805a279a2505d4c20d22d26.
---
 sys/fs/nfsclient/nfs_clbio.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/sys/fs/nfsclient/nfs_clbio.c b/sys/fs/nfsclient/nfs_clbio.c
index fe2ed0dff0dd..e181bf593e23 100644
--- a/sys/fs/nfsclient/nfs_clbio.c
+++ b/sys/fs/nfsclient/nfs_clbio.c
@@ -679,6 +679,36 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int ioflag, 
struct ucred *cred)
goto out;
}
 
+   /*
+* If not eof and read aheads are enabled, start one.
+* (You need the current block first, so that you have the
+*  directory offset cookie of the next block.)
+*/
+   NFSLOCKNODE(np);
+   if (nmp->nm_readahead > 0 && ncl_bioread_dora(vp) &&
+   (bp->b_flags & B_INVAL) == 0 &&
+   (np->n_direofoffset == 0 ||
+   (lbn + 1) * NFS_DIRBLKSIZ < np->n_direofoffset) &&
+   incore(>v_bufobj, lbn + 1) == NULL) {
+   NFSUNLOCKNODE(np);
+   rabp = nfs_getcacheblk(vp, lbn + 1, NFS_DIRBLKSIZ, td);
+   if (rabp) {
+   if ((rabp->b_flags & (B_CACHE|B_DELWRI)) == 0) {
+   rabp->b_flags |= B_ASYNC;
+   rabp->b_iocmd = BIO_READ;
+   vfs_busy_pages(rabp, 0);
+   if (ncl_asyncio(nmp, rabp, cred, td)) {
+   rabp->b_flags |= B_INVAL;
+   rabp->b_ioflags |= BIO_ERROR;
+   vfs_unbusy_pages(rabp);
+   brelse(rabp);
+   }
+   } else {
+   brelse(rabp);
+   }
+   }
+   NFSLOCKNODE(np);
+   }
/*
 * Unlike VREG files, whos buffer size ( bp->b_bcount ) is
 * chopped for the EOF condition, we cannot tell how large
@@ -691,7 +721,6 @@ ncl_bioread(struct vnode *vp, struct uio *uio, int ioflag, 
struct ucred *cred)
 * in np->n_direofoffset and chop it off as an extra step
 * right here.
 */
-   NFSLOCKNODE(np);
n = lmin(uio->uio_resid, NFS_DIRBLKSIZ - bp->b_resid - on);
if (np->n_direofoffset && n > np->n_direofoffset - 
uio->uio_offset)
n = np->n_direofoffset - uio->uio_offset;

Re: [MBZ] Michael Doucet

[RICK HAWKINS via Mercedes]

Folks

He’s famous for The band Beau Soleil … Cajun music …. I saw him a bunch of 
times at the New Orleans Jazzfest and even chatted with him a few times in the 
old days

Great musician

Xxxrick


> Car is nice, will clean up. Currently the throttle linkage is sticky from 
> sitting and has no brakes.  Original owner was Michael Doucet, supposedly a 
> famous musician. I have never heard of him. Anyway, if he really is a big 
> deal, just was at his house today. 
> 
> 
> Sent from my iPhone
> Car is nice, will clean up. Currently the throttle linkage is sticky from 
> sitting and has no brakes.  Original owner was Michael Doucet, supposedly a 
> famous musician. I have never heard of him. Anyway, if he really is a big 
> deal, just was at his house today. 
> 
> 
> Sent from my iPhone
___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

Re: [MBZ] Mercedes Benz 300D - $14,500 (SAINT SIMONS ISLAND)

[Rick Knoble via Mercedes]

> Any person who Buyes the home
   must submit to a background Check before signing the lot Lease.

> Strange.

It's a trailer in a trailer park, but they don't want trailer park people 
living there.

Rick
___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

[cctalk] Re: First Personal Computer

[Rick Bensene via cctalk]

While the LGP-30(vacuum tube/drum), G-15(vacuum tube/drum), and 
PB-250(transistor/delay lines) predated it, the ground-breaking Olivetti 
Programma 101(transistor/delay line) programmable desktop calculator was 
officially called a "personal computer" in some of its advertising and sales 
literature.  It was introduced in October of 1965.   

Late in the game as far as single-user, standard AC-line-powered computing 
devices compared to those machines and probably others, but those machines, 
AFAIK, were not advertised nor specified as "personal computers".
  
That said, I am much more aware of electronic calculator history than computer 
history, so I could be entirely biased here.  Also, the Programma 101, as I've 
stated here before, only scratches the definition of a true computer in that it 
is not capable of handling any data type but floating point binary-coded 
decimal numbers, has very limited data storage capability, and had no 
peripheral interfacing capability.

There were quite a number of single-user computing devices made and sold that 
ran on standard AC power, and were vastly more capable than the Programma 101, 
and predated it, but, AFAIK, were not advertised or particularly marketed as 
"personal computers".

One that comes to mind is the Monroe Monrobot III(vacuum tube/drum), introduced 
in February, 1955.

Another is the IBM 610 "Auto Point"(vacuum tube/drum) computer, introduced in 
1957.
It was originally named the "Personal Automatic Computer" (PAC) by its designer.

I'm sure that there are quite a few other machines developed in the mid-to-late 
1950's that would qualify as personal computing devices, but these two are the 
ones that I'm aware of that seem to fit the bill.   Some of these may actually 
have been capable of manipulating data types other than decimal numbers.

In 1962, Casio introduced its AL-1 programmable (up to 360 steps) relay-based 
electric calculator.  It was definitely intended as a personal computing 
device, and calculations could be performed manually from a keyboard much like 
a regular calculator, but also automatically via plastic toothed gears that 
would have teeth broken off of them to encode program steps.  The gears would 
be electrically read by the machine and directed the machine to perform 
computer-like operations.

I'm not arguing that any of these, including the Programma 101, are the first 
"personal computers" by any means.   I'm just adding some thoughts to the 
discussion.

Rick Bensene
The Old Calculator Museum
https://oldcalculatormuseum.com

[cctalk] Re: ANITA ((was: Experience using an Altair 8800 ("Personal computer" from 70s)

[Rick Bensene via cctalk]

Christian Corti wrote:

> The Anita electronic desktop calculators are a perfect example for the usage 
> of 
> selenium rectifiers in logic gates.

..and anyone who has restored one knows that the vast majority of the 
back-to-back selenium  diode packages have to be replaced with something else 
as they no longer function properly.  Ambient moisture kills Selenium as a 
semiconductor, and even though these devices were packaged to avoid that to 
some degree, after 60 years, stuff happens.

Many restorers resort to de-soldering the dual-diode packages from the circuit 
boards, hollowing out the package (removing the Selenium rectifiers and the 
potting material used) and installing back-to-back conventional Silicon diodes 
that are rated for the appropriate voltages involved in these machines, potting 
the diodes in place with some kind of material (epoxy?), and re-soldering the 
package to the circuit board.  These calculators used gas-discharge active 
logic elements (e.g., thyratrons and dekatrons) and used (relatively speaking) 
high voltages for their logic levels.  Fortunately, these gas-discharge devices 
seem to fare quite well with time, and though some do fail due to atomic-level 
outgassing or simple breakage, the majority of them work just as well the day 
the machine came off the assembly line.

Such practice with the Selenium rectifier modules makes the calculator look 
original if done carefully, and allows it to function when operation was 
impossible with the original devices.   It is an extremely tedious and 
time-consuming process, as there are a great many of these devices used in the 
first-generation Sumlock/ANITA calculators.  

I applaud anyone with the courage and patience to perform such surgery on these 
unusual artifacts. Fortunately, the circuit boards are quite robustly made, and 
the traces are large and well adhered to the base material of the circuit board 
(unlike many later calculators), making such an operation feasible. 

I am not brave enough to try this with the museum's ANITA Mk8.  After 25+ years 
of owning this artifact, I have not even tried to apply power to it in any 
fashion, and probably never will.  It is one of the very few calculators in the 
museum that is probably not in operational condition, as I strive for all of 
the exhibited machines to be operable and available for visitors to the 
physical museum to play with if they desire.  I'm content to leave it as it is 
for a display machine, as it is in very nice original condition.

Interesting to note that many ANITA Mk8 machines have a single transistor in 
them.  It's in the power supply.   The designers were comfortable enough using 
these relatively fussy gas-discharge logic devices as digital devices(they had 
developed machines like Colossus using this technology considerably before 
transistors were a thing, so there was certainly historical precedent), but the 
transistor was just fine for an analog purpose in the power supply.   

Boy, did they ever get it backwards (in terms of the longevity of gas-discharge 
logic elements in electronic calculators and what became the ubiquitous use to 
transistors)!  

Not intended at all to slight the accomplishment of Sumlock Comptometer in the 
development of these calculators.   They set the stage for the explosion of 
what was to become a many hundreds of million dollar market by the end of the 
decade, not to mention setting the electronic calculator up to be the driving 
force behind integrated circuit development for a consumer-oriented device.   

ICs before their development for use in calculators were only for big mainframe 
computers, military weapons systems, the spooks at places like the NSA, and the 
space program.  For that matter, the ANITA Mk7/8  could be said to be the 
progenitors for the development of the CPU on a chip, and by extension, the 
personal computer.   

Notice I didn't specify any machine, or say "first".  Slippery slope there.

Rick Bensene
The Old Calculator Museum
https://oldcalculatormuseum.com

Re: Devil's Punchbowl

[Rick Womer]

Larry, there are some really nice photos here.

For me, though, the many near-duplicate images dilutes the impact of the whole 
set—for example, were 11 similar shots of the raven and 8 of the eagle really 
necessary to post?


Rick


> On Apr 26, 2021, at 8:59 AM, Daniel J. Matyola  wrote:
> 
> Those are two very well-done galleries.  Thanks for sharing.
> 
> Dan Matyola
> *https://tinyurl.com/DJM-Pentax-Gallery
> <https://tinyurl.com/DJM-Pentax-Gallery>*
> 
> 
> 
> On Sun, Apr 25, 2021 at 10:06 PM Larry Colen  wrote:
> 
>> It’s been a few years since I discovered Otter Rock between Newport and
>> Depoe Bay.  Somehow on previous visits I totally missed Devil’s Punchbowl
>> (not to be confused with Devil’s churn in Perpetua).
>> 
>> At high tide, flushing the punchbowl:
>> 
>> https://www.flickr.com/photos/ellarsee/51139487905/in/album-72157719023434163/
>> 
>> A couple days later, closer to low tide when you can get into the
>> punchbowl:
>> 
>> https://www.flickr.com/photos/ellarsee/51138604123/in/album-72157719023434163/
>> 
>> The big challenge at low tide is trying to get photos with the crowds of
>> other people who also want to check it out.
>> 
>> Another lesson learned is to not only bring something to dry splashes off
>> the lens, but to actually check it for splashes
>> 
>> Full set:
>> https://www.flickr.com/photos/ellarsee/sets/72157719023434163/
>> 
>> and while I’m at it, some other photos from around Otter Rock
>> https://www.flickr.com/photos/ellarsee/sets/72157719023495363/
>> 
>> --
>> Larry Colen
>> l...@red4est.com
>> 
>> 
>> --
>> %(real_name)s Pentax-Discuss Mail List
>> To unsubscribe send an email to pdml-le...@pdml.net
>> to UNSUBSCRIBE from the PDML, please visit the link directly above and
>> follow the directions.
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
> the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Paris

[Rick Womer]

It’s -only- been five months since our autumn trip to France, and I’m finally 
getting around to posting some pics. (My photo computer and hard drives took a 
hit from a nasty power surge, which took a long time to sort out).

Paris was our first stop, so more are coming.

https://rickwomer.smugmug.com/2023/Paris-Oct-23

Comments always appreciated!

Rick
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

hints and tips and help for Git and GitHub for mainframers

[Rick Troth]

howdy folks ...

I was asked this week for help with Git. The target audience is 
mainframe people. (But I don't expect to be presenting.)


I had previously helped this particular group get on-board using Git and 
GitHub, but that was several months ago. They're again looking at it, so 
their leader asked me for whatever material I might have.

But I got nuthin. I don't see a PowerPoint deck in any of my stuff.

Therefore, does anyone here have a PPT deck or a SHARE PDF for a 
Git/GitHub how-to for mainframers?



thanks


-- R; <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PESO, not shot with a Pentax.

[Rick Womer]

A spoon resting on your dog’s back? On an unusual tablecloth?

Rick

> On May 22, 2024, at 5:57 PM, Bill  wrote:
> 
> I'm slowly coming out of hibernation and took the X-T5 out for a ride today.
> 
> I didn't do much, but I did this:
> 
> https://flic.kr/p/2pSJ7Ko
> 
> Enjoy
> 
> bill
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
> the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Spring at The Woodlands

[Rick Womer]

The Woodlands is a nearby park that also hosts a cemetery (they are corporately 
distinct).  It has been a particularly colorful one.

https://rickwomer.smugmug.com/2024/April-2024/Woodlands-in-Bloom


Rick
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[Bug 2066457] Re: Ubuntu 24.10 Oracular accented vowels does not work in Italian keyboard

[Rick S]

I don't use it much but since corradoventu went to the trouble it
affects me as well.

"PRETTY_NAME="Ubuntu Oracular Oriole (development branch)"
NAME="Ubuntu"
VERSION_ID="24.10"
VERSION="24.10 (Oracular Oriole)"
VERSION_CODENAME=oracular
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/;
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy;
UBUNTU_CODENAME=oracular
LOGO=ubuntu-logo
"

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066457

Title:
  Ubuntu 24.10 Oracular accented vowels does not work in Italian
  keyboard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fontconfig/+bug/2066457/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[cctalk] Re: Thirties techies and computing history

[Rick Bensene via cctalk]

On 5/20/24 10:25, Bill Degnan via cctalk wrote:

>>> American Computer Museum
>>> Computer History Museum
>>> Computer Museum of America
>>> Large Scale Systems Museum
>>> Rhode Island Computer Museum
>>> System Source Computer Museum

Of course, there's the Living Computer Museum--oh, wait

...and wait...and wait...and

[BVARC] Current HF Propagation ???

[Rick Hiller via BVARC]

Can anyone comment on the current HF prop?  I can't even get W1AW
Bulletins on CW.   40, 20, 30 are usually best but today NOT even a
squeek.  I have not been on the air so I don' t know what's up.

Tnx...Rick  W5RH

Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

[gentoo-commits] repo/gentoo:master commit in: app-misc/liquidctl/

[Rick Farina]

commit: dc14f98578b7c8d30b767f3ed35ac0805009c189
Author: Rick Farina  gentoo  org>
AuthorDate: Tue May 21 17:32:41 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue May 21 17:36:25 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc14f985

app-misc/liquidctl: add 1.13.0

This does not fix the known bug in the tests, but upstream indicated
it's not a problem, and this isn't a regression.
Bug: https://bugs.gentoo.org/928971
Bug: https://github.com/liquidctl/liquidctl/issues/661
Signed-off-by: Rick Farina  gentoo.org>

 app-misc/liquidctl/Manifest|  1 +
 app-misc/liquidctl/liquidctl-1.13.0.ebuild | 53 ++
 2 files changed, 54 insertions(+)

diff --git a/app-misc/liquidctl/Manifest b/app-misc/liquidctl/Manifest
index 6f7dedb2be43..ebf4e35af3aa 100644
--- a/app-misc/liquidctl/Manifest
+++ b/app-misc/liquidctl/Manifest
@@ -1,2 +1,3 @@
 DIST liquidctl-1.11.1.tar.gz 1836371 BLAKE2B 
e302251855b48405d811287061df3593f0549f02d8d369ae0c0178c27722b69e3c589763de5a963e2b2a37d88f3213e649da9e6f74db59a36f9b803d33d2b038
 SHA512 
06c11eb0bb258ec4111e885d5ed2bf89842fc0a9bfbc57aee6c86d405808d9bd9582fa137beac7250949448454412d03ade0bc3ee16cd3bd8de3fff66a0cc1bf
 DIST liquidctl-1.12.1.tar.gz 1842721 BLAKE2B 
b3732d4192fef2a2dfcb8edd42a3fb0d5c2f9b32c43a8950561e302a122fe4c993338035d3b779929e625257f4f59576550bfbf8a334c1b1fbba868ed0abc562
 SHA512 
37e81f29516d051603fb50f9fd5e6b6646a02d2aea1dc1d4247b2286a9649f79b85c4d856ab5f1df04ae2f3eecc2ebc4f865e08b28be85c2915be9723854cf7a
+DIST liquidctl-1.13.0.tar.gz 1844095 BLAKE2B 
066fe154fc8ea55a1163bcf5403cf4602c10bcd4b24c3a808dc11d9324bb41395b685856e546d8ea10f3e464e5cf20e45b8f98a46cc388052130f4e9e3537bf4
 SHA512 
12a7fe58e35367684efa4f6db68bcd09aa2f485bfc52b50136013c9275a1295bc9bc1e0d3c940097b0b3154c1d24a1792e6a894395a6826a27f9e6ea6a8e3893

diff --git a/app-misc/liquidctl/liquidctl-1.13.0.ebuild 
b/app-misc/liquidctl/liquidctl-1.13.0.ebuild
new file mode 100644
index ..a2eb2e0132a7
--- /dev/null
+++ b/app-misc/liquidctl/liquidctl-1.13.0.ebuild
@@ -0,0 +1,53 @@
+# Copyright 2022-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+PYTHON_COMPAT=( python3_{9..12} )
+DISTUTILS_USE_PEP517=setuptools
+
+inherit distutils-r1 udev
+
+DESCRIPTION="Cross-platform tool and drivers for liquid coolers and other 
devices"
+HOMEPAGE="https://github.com/liquidctl/liquidctl;
+SRC_URI="https://github.com/liquidctl/liquidctl/releases/download/v${PV}/${P}.tar.gz;
+LICENSE="GPL-3+"
+SLOT="0"
+KEYWORDS="~amd64"
+
+RDEPEND="
+   dev-python/colorlog[${PYTHON_USEDEP}]
+   dev-python/crcmod[${PYTHON_USEDEP}]
+   dev-python/docopt[${PYTHON_USEDEP}]
+   dev-python/hidapi[${PYTHON_USEDEP}]
+   dev-python/pillow[${PYTHON_USEDEP}]
+   dev-python/pyusb[${PYTHON_USEDEP}]
+   sys-apps/i2c-tools[${PYTHON_USEDEP},python]
+"
+
+BDEPEND="
+   dev-python/setuptools-scm[${PYTHON_USEDEP}]
+"
+
+distutils_enable_tests pytest
+
+src_test() {
+   # Without this variable, it attempts to write to /var/run and fails
+   XDG_RUNTIME_DIR="${T}/xdg" distutils-r1_src_test || die
+}
+
+python_install_all() {
+   distutils-r1_python_install_all
+
+   dodoc docs/*.md
+   dodoc -r docs/linux/
+
+   udev_dorules extra/linux/71-liquidctl.rules
+}
+
+pkg_postinst() {
+   udev_reload
+}
+
+pkg_postrm() {
+   udev_reload
+}

Re: [MBZ] I bought an EV

[RICK HAWKINS via Mercedes]

I think that would be an insane amount of work but it would be cool … I have 4 snappers …. Let’s see if I resurrect any … 3 were working in the last year or twoStill haven’t tested the ryobi but will shortly … grass is 8 inchesXx rickOn May 21, 2024, at 8:52 AM, Curt Raymond  wrote:I'm sorta half shopping for another old Snapper rider mower to convert to electric. I want to do a 2 motor swap, one for propulsion, the other for cutting. Use 2x (maybe 4x) 18v Makita tool batteries to power it.For the average homeowner electric is a better choice than grass, especially on a 1/4 acre or smaller lot.CurtYahoo Mail: Search, Organize, ConquerOn Mon, May 20, 2024 at 11:28 PM, RICK HAWKINS via Mercedes wrote:   So, folks,I drove over to Bluffton SC and bought an EV and carried it back to tybee on my rollback.Actually it’s a Ryobi zero turn 30 inch cut LiH battery powered lawnmower.It is pretty odd … it runs and steers with a right hand joystick and the only conventional control is a foot brake.I’ll take it off the truck tomorrow …. I think they cost $3k and this one is like new with tags … guy said he to it discounted from Home Depot .  I paid $2k and figure if it sucks I can probably sell it on.Mercedes content … I’d have moved it in the sprinter but I have a press in it . I drove up to Oakton VA last week and moved a couple of presses for a bunch of $$. I have to take them to Summerville, sc but I’ll do it next week. The rusty sprinter with 390,xxx miles performed flawlessly and I think I got about 20 mpg dragging a trailer all the way and with 2500 lbs of presses coming home .Xx rick___http://www.okiebenz.comTo search list archives http://www.okiebenz.com/archive/To Unsubscribe or change delivery options go to:http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com  ___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

[gentoo-commits] repo/gentoo:master commit in: app-editors/qhexedit2/

[Rick Farina]

commit: fe029d81be70f53dbec34063a1bde04ebde37670
Author: Rick Farina  gentoo  org>
AuthorDate: Tue May 21 16:19:33 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue May 21 16:19:33 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fe029d81

app-editors/qhexedit2: add missing dep

x86_64-pc-linux-gnu-g++ -Wl,-O1 -Wl,--as-needed 
-Wl,--defsym=__gentoo_check_ldflags__=0 -shared -Wl,-soname,libqhexedit.so.4 -o 
libqhexedit.so.4.2.0 qhexedit.o chunks.o commands.o moc_qhexedit.o moc_chunks.o 
moc_commands.o  /usr/lib64/libQt5Widgets.so /usr/lib64/libQt5Gui.so 
/usr/lib64/libQt5Core.so -lGL -pthread
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: 
cannot find -lGL: No such file or directory

Signed-off-by: Rick Farina  gentoo.org>

 app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild 
b/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
index 50466687246c..5a8f47ea5c48 100644
--- a/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
+++ b/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
@@ -28,6 +28,7 @@ RDEPEND="
dev-qt/qtcore:5
dev-qt/qtgui:5
dev-qt/qtwidgets:5
+   media-libs/libglvnd
python? (
${PYTHON_DEPS}
$(python_gen_cond_dep '

[gentoo-commits] repo/gentoo:master commit in: app-editors/qhexedit2/

[Rick Farina]

commit: dc53ff4ef0aeb155aefccc9e230575d0deb871c6
Author: Rick Farina  gentoo  org>
AuthorDate: Tue May 21 16:20:31 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue May 21 16:20:31 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc53ff4e

app-editors/qhexedit2: reorder variables for pkgcheck

Signed-off-by: Rick Farina  gentoo.org>

 app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild 
b/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
index 5a8f47ea5c48..8d04bc22466a 100644
--- a/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
+++ b/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
@@ -11,6 +11,7 @@ DESCRIPTION="Hex editor library, Qt application written in 
C++ with Python bindi
 HOMEPAGE="https://github.com/Simsys/qhexedit2/;
 SRC_URI="https://github.com/Simsys/${PN}/archive/${EGIT_COMMIT}.tar.gz -> 
${P}.tar.gz"
 
+S="${WORKDIR}/${PN}-${EGIT_COMMIT}"
 LICENSE="GPL-2"
 SLOT="0"
 KEYWORDS="amd64 ~riscv x86"
@@ -46,8 +47,6 @@ BDEPEND="
)
 "
 
-S="${WORKDIR}/${PN}-${EGIT_COMMIT}"
-
 src_prepare() {
default
sed -i -e '/^unix:DESTDIR/ d' -e "\$atarget.path = /usr/$(get_libdir)" \

[gentoo-commits] repo/gentoo:master commit in: app-editors/qhexedit2/

[Rick Farina]

commit: 58be6cb833ca6d35c779211be637931df6a0557d
Author: Huang Rui  gmail  com>
AuthorDate: Tue Apr 16 02:20:53 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue May 21 16:15:27 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=58be6cb8

app-editors/qhexedit2: upgrade to Python 3.12

Bug: https://bugs.gentoo.org/921826
Closes: https://bugs.gentoo.org/929299
Closes: https://github.com/gentoo/gentoo/pull/36275
Signed-off-by: Huang Rui  gmail.com>
Signed-off-by: Rick Farina  gentoo.org>

 ...-0.8.9_p20210525-r2.ebuild => qhexedit2-0.8.9_p20210525-r3.ebuild} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r2.ebuild 
b/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
similarity index 96%
rename from app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r2.ebuild
rename to app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
index 34d3906f4682..50466687246c 100644
--- a/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r2.ebuild
+++ b/app-editors/qhexedit2/qhexedit2-0.8.9_p20210525-r3.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
 
-PYTHON_COMPAT=( python3_{9..11} )
+PYTHON_COMPAT=( python3_{10..12} )
 inherit python-r1 qmake-utils
 
 EGIT_COMMIT="541139125be034b90b6811a84faa1413e357fd94"

[gentoo-commits] repo/gentoo:master commit in: x11-misc/mozo/

[Rick Farina]

commit: 85ca9c95795a50c17cfa8b0cd559c85846354bd0
Author: Rick Farina  gentoo  org>
AuthorDate: Tue May 21 16:09:48 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue May 21 16:09:48 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85ca9c95

x11-misc/mozo: add python 3.12

tests pass
remove KEYWORDS="" to please pkgcheck

Closes: https://bugs.gentoo.org/929888
Signed-off-by: Rick Farina  gentoo.org>

 x11-misc/mozo/mozo-1.26.2.ebuild | 6 +++---
 x11-misc/mozo/mozo-1.28.0.ebuild | 4 +---
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/x11-misc/mozo/mozo-1.26.2.ebuild b/x11-misc/mozo/mozo-1.26.2.ebuild
index 29f50e52fa7b..bd10ba1423a0 100644
--- a/x11-misc/mozo/mozo-1.26.2.ebuild
+++ b/x11-misc/mozo/mozo-1.26.2.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
-EAPI=7
+EAPI=8
 
-PYTHON_COMPAT=( python3_{10..11} )
+PYTHON_COMPAT=( python3_{10..12} )
 PYTHON_REQ_USE="xml(+)"
 
 inherit mate python-r1

diff --git a/x11-misc/mozo/mozo-1.28.0.ebuild b/x11-misc/mozo/mozo-1.28.0.ebuild
index 6496e4d89d96..55d608812889 100644
--- a/x11-misc/mozo/mozo-1.28.0.ebuild
+++ b/x11-misc/mozo/mozo-1.28.0.ebuild
@@ -3,7 +3,7 @@
 
 EAPI=8
 
-PYTHON_COMPAT=( python3_{10..11} )
+PYTHON_COMPAT=( python3_{10..12} )
 PYTHON_REQ_USE="xml(+)"
 
 inherit mate python-r1
@@ -14,8 +14,6 @@ LICENSE="GPL-2+ GPL-3+ LGPL-2+ LGPL-2.1+"
 MINOR=$(($(ver_cut 2) % 2))
 if [[ ${MINOR} -eq 0 ]]; then
KEYWORDS="~amd64 ~arm ~arm64 ~loong ~riscv ~x86"
-else
-   KEYWORDS=""
 fi
 
 SLOT="0"

[gentoo-commits] repo/gentoo:master commit in: x11-terms/terminator/

[Rick Farina]

commit: 85a231ab68b580752834753b96f604f6544053c8
Author: Alexey Sokolov  asokolov  org>
AuthorDate: Tue Apr  2 21:06:27 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Tue May 21 16:01:28 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85a231ab

x11-terms/terminator: add py 3.12

Closes: https://bugs.gentoo.org/929894
Closes: https://github.com/gentoo/gentoo/pull/36067
Signed-off-by: Alexey Sokolov  asokolov.org>
Signed-off-by: Rick Farina  gentoo.org>

 x11-terms/terminator/terminator-2.1.3.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/x11-terms/terminator/terminator-2.1.3.ebuild 
b/x11-terms/terminator/terminator-2.1.3.ebuild
index 53ae6c2db591..226c52856375 100644
--- a/x11-terms/terminator/terminator-2.1.3.ebuild
+++ b/x11-terms/terminator/terminator-2.1.3.ebuild
@@ -4,7 +4,7 @@
 EAPI=8
 
 DISTUTILS_USE_PEP517=setuptools
-PYTHON_COMPAT=( python3_{9..11} )
+PYTHON_COMPAT=( python3_{9..12} )
 inherit distutils-r1 optfeature verify-sig virtualx xdg
 
 DESCRIPTION="Multiple GNOME terminals in one window"

[Framers] Are you seeing my posts

[rick]

Hi All,



Checking this for a member of the list.



Rick

___

This message is from the Framers mailing list

Send messages to framers@lists.frameusers.com
Visit the list's homepage at  http://www.frameusers.com
Archives located at http://www.mail-archive.com/framers%40lists.frameusers.com/
Subscribe and unsubscribe at 
http://lists.frameusers.com/listinfo.cgi/framers-frameusers.com
Send administrative questions to listad...@frameusers.com

[MBZ] I bought an EV

[RICK HAWKINS via Mercedes]

So, folks,

I drove over to Bluffton SC and bought an EV and carried it back to tybee on my 
rollback.

Actually it’s a Ryobi zero turn 30 inch cut LiH battery powered lawnmower.

It is pretty odd … it runs and steers with a right hand joystick and the only 
conventional control is a foot brake.

I’ll take it off the truck tomorrow …. I think they cost $3k and this one is 
like new with tags … guy said he to it discounted from Home Depot .  I paid $2k 
and figure if it sucks I can probably sell it on.

Mercedes content … I’d have moved it in the sprinter but I have a press in it . 
I drove up to Oakton VA last week and moved a couple of presses for a bunch of 
$$. I have to take them to Summerville, sc but I’ll do it next week. The rusty 
sprinter with 390,xxx miles performed flawlessly and I think I got about 20 mpg 
dragging a trailer all the way and with 2500 lbs of presses coming home .

Xx rick

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

[Edgecombe, Rick P]

On Mon, 2024-05-20 at 00:18 +0200, Jiri Olsa wrote:
> anyway I think we can fix that in another way by using the optimized
> trampoline,
> but returning to the user space through iret when shadow stack is detected
> (as I did in the first version, before you adjusted it to the sysret path).
> 
> we need to update the return address on stack only when returning through the
> trampoline, but we can jump to original return address directly from syscall
> through iret.. which is slower, but with shadow stack we don't care
> 
> basically the only change is adding the shstk_is_enabled check to the
> following condition in SYSCALL_DEFINE0(uretprobe):
> 
> if (regs->sp != sp || shstk_is_enabled())
> return regs->ax;

On the surface it sounds reasonable. Thanks.

And then I guess if tradeoffs are seen differently in the future, and we want to
enable the fast path for shadow stack we can go with your other solution. So
this just simply fixes things functionally without much code.

[gentoo-commits] repo/gentoo:master commit in: net-wireless/urh/files/, net-wireless/urh/

[Rick Farina]

commit: bd3493ceb54e81958ec407febf85855ad60c8753
Author: Rick Farina  gentoo  org>
AuthorDate: Mon May 20 19:48:11 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Mon May 20 19:50:22 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bd3493ce

net-wireless/urh: add 2.9.6_p20240428

Bumping a little past the last release because this version actually
passes tests :-)

Signed-off-by: Rick Farina  gentoo.org>

 net-wireless/urh/Manifest   |  1 +
 net-wireless/urh/files/urh-2.9.7-no-numpy-setup.patch   | 11 +++
 .../urh/{urh-.ebuild => urh-2.9.6_p20240428.ebuild} | 13 -
 net-wireless/urh/urh-.ebuild|  4 ++--
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/net-wireless/urh/Manifest b/net-wireless/urh/Manifest
index 95d76c41da5c..debae21374f9 100644
--- a/net-wireless/urh/Manifest
+++ b/net-wireless/urh/Manifest
@@ -1,2 +1,3 @@
 DIST urh-2.9.4.tar.gz 13415656 BLAKE2B 
504cb073540f614eea070a7aaa83ac62f81c6a115a01f935cfc39baec37bc1deb5b56035100700825f41b21ec0937d6014f0d0b73debcbf9ca951e238805d64b
 SHA512 
a888c20a4d2f349960e41defdb5cce6590d4523f8a1a655e21e4caaf7dd98a6f51936fa5a038787cb5935bc42e8863d2940059130dc9982caeea4b80e431aeeb
 DIST urh-2.9.5.tar.gz 13414599 BLAKE2B 
efe075e78dd7b289d21d93675be420e8e5e69293eb1f5e61025a9b0a7db60f4e2cae29d94af03fa9e42a6941edda9667a935b201a8838c0204e61008d2883b56
 SHA512 
7f04f041963103aab4a67fd5fd8f874339cad04da846236b0ec4584553ae6b4a6469c2505cec7c67f72d848d0eb90a4996753802c65535914e70a943d40e6970
+DIST urh-2.9.6_p20240428.gh.tar.gz 13439550 BLAKE2B 
ad71275f2a3d0c5a680bac361949a70d1eb9a0fe496d720bbc831ef1e34b40ed187106825a295e421bf9e224de5f65cc4ed2791839307bbb75f900ba4f05aa61
 SHA512 
a278d4b5fcd09cf61cc63341545604882591b6732009ca61b41aa58c71666410175d7b75106c56f43dfd538db287a38f14288cc3d2dbde0260caef370850af03

diff --git a/net-wireless/urh/files/urh-2.9.7-no-numpy-setup.patch 
b/net-wireless/urh/files/urh-2.9.7-no-numpy-setup.patch
new file mode 100644
index ..c60b2c766197
--- /dev/null
+++ b/net-wireless/urh/files/urh-2.9.7-no-numpy-setup.patch
@@ -0,0 +1,11 @@
+diff -Naur urh-2.9.4-orig/setup.py urh-2.9.4/setup.py
+--- urh-2.9.4-orig/setup.py2023-08-20 20:31:45.067321480 -0400
 urh-2.9.4/setup.py 2023-08-20 20:31:55.088320822 -0400
+@@ -50,7 +50,6 @@
+ print("Finalizing options")
+ _build_ext.finalize_options(self)
+ # Prevent numpy from thinking it is still in its setup process:
+-set_builtin("__NUMPY_SETUP__", False)
+ import numpy
+
+ self.include_dirs.append(numpy.get_include())

diff --git a/net-wireless/urh/urh-.ebuild 
b/net-wireless/urh/urh-2.9.6_p20240428.ebuild
similarity index 86%
copy from net-wireless/urh/urh-.ebuild
copy to net-wireless/urh/urh-2.9.6_p20240428.ebuild
index ed1d620f7de7..dc4f6ce3bf49 100644
--- a/net-wireless/urh/urh-.ebuild
+++ b/net-wireless/urh/urh-2.9.6_p20240428.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
 
-PYTHON_COMPAT=( python3_{10..11} )
+PYTHON_COMPAT=( python3_{10..12} )
 DISTUTILS_EXT=1
 DISTUTILS_USE_PEP517=setuptools
 inherit distutils-r1 virtualx
@@ -15,7 +15,10 @@ if [ "${PV}" = "" ]; then
inherit git-r3
EGIT_REPO_URI="https://github.com/jopohl/urh.git;
 else
-   SRC_URI="https://github.com/jopohl/${PN}/archive/v${PV}.tar.gz -> 
${P}.tar.gz"
+   COMMIT="544efd35ac4e0105cb63a31f2dc209c3834bc7bd"
+   SRC_URI="https://github.com/jopohl/urh/archive/${COMMIT}.tar.gz -> 
${P}.gh.tar.gz"
+   S="${WORKDIR}/${PN}-${COMMIT}"
+   #SRC_URI="https://github.com/jopohl/${PN}/archive/v${PV}.tar.gz -> 
${P}.gh.tar.gz"
KEYWORDS="~amd64 ~x86"
 fi
 
@@ -44,9 +47,9 @@ RDEPEND="${DEPEND}
 
 distutils_enable_tests pytest
 
+PATCHES=( "${FILESDIR}/${PN}-2.9.7-no-numpy-setup.patch" )
+
 python_configure_all() {
-   # Using sed in the live ebuild to avoid patch failure
-   sed -i '/__NUMPY_SETUP__/d' setup.py || die
DISTUTILS_ARGS=(
$(use_with airspy)
$(use_with bladerf)

diff --git a/net-wireless/urh/urh-.ebuild b/net-wireless/urh/urh-.ebuild
index ed1d620f7de7..ea6072eaa290 100644
--- a/net-wireless/urh/urh-.ebuild
+++ b/net-wireless/urh/urh-.ebuild
@@ -1,9 +1,9 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 EAPI=8
 
-PYTHON_COMPAT=( python3_{10..11} )
+PYTHON_COMPAT=( python3_{10..12} )
 DISTUTILS_EXT=1
 DISTUTILS_USE_PEP517=setuptools
 inherit distutils-r1 virtualx

[gentoo-commits] repo/gentoo:master commit in: net-wireless/urh/

[Rick Farina]

commit: 824b4851a7d5ea1ffb69d4813e43d414d56a78c7
Author: Rick Farina  gentoo  org>
AuthorDate: Mon May 20 19:49:07 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Mon May 20 19:50:28 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=824b4851

net-wireless/urh: drop 2.9.4

Signed-off-by: Rick Farina  gentoo.org>

 net-wireless/urh/Manifest |  1 -
 net-wireless/urh/urh-2.9.4.ebuild | 81 ---
 2 files changed, 82 deletions(-)

diff --git a/net-wireless/urh/Manifest b/net-wireless/urh/Manifest
index debae21374f9..36f73818b9a8 100644
--- a/net-wireless/urh/Manifest
+++ b/net-wireless/urh/Manifest
@@ -1,3 +1,2 @@
-DIST urh-2.9.4.tar.gz 13415656 BLAKE2B 
504cb073540f614eea070a7aaa83ac62f81c6a115a01f935cfc39baec37bc1deb5b56035100700825f41b21ec0937d6014f0d0b73debcbf9ca951e238805d64b
 SHA512 
a888c20a4d2f349960e41defdb5cce6590d4523f8a1a655e21e4caaf7dd98a6f51936fa5a038787cb5935bc42e8863d2940059130dc9982caeea4b80e431aeeb
 DIST urh-2.9.5.tar.gz 13414599 BLAKE2B 
efe075e78dd7b289d21d93675be420e8e5e69293eb1f5e61025a9b0a7db60f4e2cae29d94af03fa9e42a6941edda9667a935b201a8838c0204e61008d2883b56
 SHA512 
7f04f041963103aab4a67fd5fd8f874339cad04da846236b0ec4584553ae6b4a6469c2505cec7c67f72d848d0eb90a4996753802c65535914e70a943d40e6970
 DIST urh-2.9.6_p20240428.gh.tar.gz 13439550 BLAKE2B 
ad71275f2a3d0c5a680bac361949a70d1eb9a0fe496d720bbc831ef1e34b40ed187106825a295e421bf9e224de5f65cc4ed2791839307bbb75f900ba4f05aa61
 SHA512 
a278d4b5fcd09cf61cc63341545604882591b6732009ca61b41aa58c71666410175d7b75106c56f43dfd538db287a38f14288cc3d2dbde0260caef370850af03

diff --git a/net-wireless/urh/urh-2.9.4.ebuild 
b/net-wireless/urh/urh-2.9.4.ebuild
deleted file mode 100644
index fbf539dbce42..
--- a/net-wireless/urh/urh-2.9.4.ebuild
+++ /dev/null
@@ -1,81 +0,0 @@
-# Copyright 1999-2023 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=8
-
-PYTHON_COMPAT=( python3_{10..11} )
-DISTUTILS_EXT=1
-DISTUTILS_USE_PEP517=setuptools
-inherit distutils-r1 virtualx
-
-DESCRIPTION="Universal Radio Hacker: investigate wireless protocols like a 
boss"
-HOMEPAGE="https://github.com/jopohl/urh;
-
-if [ "${PV}" = "" ]; then
-   inherit git-r3
-   EGIT_REPO_URI="https://github.com/jopohl/urh.git;
-else
-   SRC_URI="https://github.com/jopohl/${PN}/archive/v${PV}.tar.gz -> 
${P}.tar.gz"
-   KEYWORDS="~amd64 ~x86"
-fi
-
-LICENSE="Apache-2.0"
-SLOT="0"
-IUSE="airspy audio bladerf hackrf limesdr plutosdr rtlsdr sdrplay uhd"
-
-DEPEND="${PYTHON_DEPS}
-   net-wireless/gnuradio[zeromq]
-   dev-python/numpy[${PYTHON_USEDEP}]
-   dev-python/psutil[${PYTHON_USEDEP}]
-   dev-python/pyzmq[${PYTHON_USEDEP}]
-   dev-python/cython[${PYTHON_USEDEP}]
-   airspy? ( net-wireless/airspy:= )
-   audio? ( dev-python/pyaudio[${PYTHON_USEDEP}] )
-   bladerf? ( net-wireless/bladerf:= )
-   hackrf? ( net-libs/libhackrf:= )
-   limesdr? ( net-wireless/limesuite )
-   plutosdr? ( net-libs/libiio:= )
-   rtlsdr? ( net-wireless/rtl-sdr )
-   sdrplay? ( 

[gentoo-commits] repo/gentoo:master commit in: net-wireless/urh/files/, net-wireless/urh/

[Rick Farina]

commit: 8d7f51177546c65aa48617a7a4d499a6b67bb9a6
Author: Rick Farina  gentoo  org>
AuthorDate: Mon May 20 19:50:00 2024 +
Commit:     Rick Farina  gentoo  org>
CommitDate: Mon May 20 19:50:32 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8d7f5117

net-wireless/urh: drop 2.9.5

Signed-off-by: Rick Farina  gentoo.org>

 net-wireless/urh/Manifest  |  1 -
 .../urh/files/urh-2.9.4-no-numpy-setup.patch   | 11 ---
 net-wireless/urh/urh-2.9.5.ebuild  | 81 --
 3 files changed, 93 deletions(-)

diff --git a/net-wireless/urh/Manifest b/net-wireless/urh/Manifest
index 36f73818b9a8..53c9535a3d2d 100644
--- a/net-wireless/urh/Manifest
+++ b/net-wireless/urh/Manifest
@@ -1,2 +1 @@
-DIST urh-2.9.5.tar.gz 13414599 BLAKE2B 
efe075e78dd7b289d21d93675be420e8e5e69293eb1f5e61025a9b0a7db60f4e2cae29d94af03fa9e42a6941edda9667a935b201a8838c0204e61008d2883b56
 SHA512 
7f04f041963103aab4a67fd5fd8f874339cad04da846236b0ec4584553ae6b4a6469c2505cec7c67f72d848d0eb90a4996753802c65535914e70a943d40e6970
 DIST urh-2.9.6_p20240428.gh.tar.gz 13439550 BLAKE2B 
ad71275f2a3d0c5a680bac361949a70d1eb9a0fe496d720bbc831ef1e34b40ed187106825a295e421bf9e224de5f65cc4ed2791839307bbb75f900ba4f05aa61
 SHA512 
a278d4b5fcd09cf61cc63341545604882591b6732009ca61b41aa58c71666410175d7b75106c56f43dfd538db287a38f14288cc3d2dbde0260caef370850af03

diff --git a/net-wireless/urh/files/urh-2.9.4-no-numpy-setup.patch 
b/net-wireless/urh/files/urh-2.9.4-no-numpy-setup.patch
deleted file mode 100644
index 4beca0eed64f..
--- a/net-wireless/urh/files/urh-2.9.4-no-numpy-setup.patch
+++ /dev/null
@@ -1,11 +0,0 @@
-diff -Naur urh-2.9.4-orig/setup.py urh-2.9.4/setup.py
 urh-2.9.4-orig/setup.py2023-08-20 20:31:45.067321480 -0400
-+++ urh-2.9.4/setup.py 2023-08-20 20:31:55.088320822 -0400
-@@ -50,7 +50,6 @@
- print("Finalizing options")
- _build_ext.finalize_options(self)
- # Prevent numpy from thinking it is still in its setup process:
--__builtins__.__NUMPY_SETUP__ = False
- import numpy
- self.include_dirs.append(numpy.get_include())
- 

diff --git a/net-wireless/urh/urh-2.9.5.ebuild 
b/net-wireless/urh/urh-2.9.5.ebuild
deleted file mode 100644
index 656c0488c09c..
--- a/net-wireless/urh/urh-2.9.5.ebuild
+++ /dev/null
@@ -1,81 +0,0 @@
-# Copyright 1999-2023 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=8
-
-PYTHON_COMPAT=( python3_{10..11} )
-DISTUTILS_EXT=1
-DISTUTILS_USE_PEP517=setuptools
-inherit distutils-r1 virtualx
-
-DESCRIPTION="Universal Radio Hacker: investigate wireless protocols like a 
boss"
-HOMEPAGE="https://github.com/jopohl/urh;
-
-if [ "${PV}" = "" ]; then
-   inherit git-r3
-   EGIT_REPO_URI="https://github.com/jopohl/urh.git;
-else
-   SRC_URI="https://github.com/jopohl/${PN}/archive/v${PV}.tar.gz -> 
${P}.tar.gz"
-   KEYWORDS="~amd64 ~x86"
-fi
-
-LICENSE="Apache-2.0"
-SLOT="0"
-IUSE="airspy audio bladerf hackrf limesdr plutosdr rtlsdr sdrplay uhd"
-
-DEPEND="${PYTHON_DEPS}
-   net-wireless/gnuradio[zeromq]
-   dev-python/numpy[${PYTHON_USEDEP}]
-   dev-python/psutil[${PYTHON_USEDEP}]
-   dev-python/pyzmq[${PYTHON_USEDEP}]
-   dev-python/cython[${PYTHON_USEDEP}]
-   airspy? ( net-wireless/airspy:= )
-   audio? ( dev-python/pyaudio[${PYTHON_USEDEP}] )
-   bladerf? ( net-wireless/bladerf:= )
-   hackrf? ( net-libs/libhackrf:= )
-   limesdr? ( net-wireless/limesuite )
-   plutosdr? ( net-libs/libiio:= )
-   rtlsdr? ( net-wireless/rtl-sdr )
-   sdrplay? ( 

Re: fall down followup

[Rick Womer]

Ouch!

You might look into insurance. I have a “rider” on our homeowner’s policy that 
covers my cameras and lenses. It wasn’t expensive.

Rick

> On May 18, 2024, at 9:11 PM, Larry Colen  wrote:
> 
> I mentioned that a few weeks ago I helped a woman catch her dog, in the 
> process, with the heavy camera in the handlebar bag the bike fell over.  
> Shortly thereafter I noticed some issues with the lens focusing, but they 
> seemed to correlate with low contrast situations, the camera wouldn't solidly 
> lock focus on mountains through the haze.  A couple days later I noticed the 
> smart function dial on the K-3 III was broken.  
> 
> I took the camera and lens to the local repair shop today, I hadn't noticed 
> that the barrel of the lens was actually broken:
> https://photos.app.goo.gl/rW86kLCAo8vWTRKa9
> 
> The estimates were something like $450 for the lens (which I can buy used for 
> half of that), and $700 (even more than precision) for the camera body.
> 
> Sigh.  I think that for now I'll replace the lens with an 18-135, much less 
> expensive, water resistant, smaller, and I think sharper at least within its 
> range.
> 
> When I have some time, I may try taking the lens apart and doing a kluge fix 
> myself.  In any case, if anyone has either an 18-135 or 18-270 they're 
> looking to offload, let me know.  I'm also beginning to think that I should 
> just pony up the dineros and send the K-3 III to precision in case there is 
> anything else I missed.
> 
> --
> Larry Colen
> l...@red4est.com.   sent from Mirkwood
> 
> 
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
> the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: [Oorexx-devel] Status of RxFTP

[Rick McGuire]

On Sat, May 18, 2024 at 12:19 PM Mike Cowlishaw  wrote:

> [Wow, your memory of elap is impressive!!]
>

except I forgot it was called elap!

>
> But no, the command is called from MemoWiki which is started from a
> Chrome browser icon which in turn talks to a goserve HTTP server which runs
> a Rexx program to effect the wiki.  That Rexx program is continually
> running -- so that is likely the underlying cause.
>
> And indeed the publishpage simply does a:
>
>call webPublish ftpserver'/'path,,
>   ftpuser':'ftppassword,,
>   textTypes, ignoretypes, binarytypes,,
>   'memowiki' args, filesdir
>
> rather than running it in a separate process.
>
> So I should restart the server, which is faster than rebooting Windows
> :-), but is still a bit tedious.
>
> Is there a simpler way to force reload of the .cls?
>

The package manager uses a weak reference for loaded packages, so if there
are no references pointing into that package it will get garbage collected
eventually. A bit tricking to control and there's always the issue of
unexpected references locking it down. Restarting the server is probably
the best solution.

Rick



>
> Mike
>
>
>
> --
> *From:* Rick McGuire [mailto:object.r...@gmail.com]
> *Sent:* 18 May 2024 17:02
> *To:* Open Object Rexx Developer Mailing List
> *Subject:* Re: [Oorexx-devel] Status of RxFTP
>
> are you calling the program using your custom command shell? I suspect
> that might be the problem. Otherwise it should be picking up the change
> every time the program is run, assuming it runs in a new process.
>
> Rick
>
> On Sat, May 18, 2024 at 11:55 AM Mike Cowlishaw 
> wrote:
>
>>
>>
>>
>>
>> With a bit more info from the ISP .. I think I can solve this; so for
>> now, no need for anyone else to spend time on this!
>>
>>
>>
>> Well, I was wrong, but am homing in on the problem using a modified
>> rxftp.cls (rxftpx.cls).
>>
>> A quick question: how do I 'refresh' a class .. that is, have ooRexx use
>> a modified version after I have made an experimental change?
>>
>> At present, if I edit the .cls file the next time I use the Rexx program
>> that requires it the old version continues to be used (until I reboot
>> Windows, in which case the change takes effect).
>>
>> Q:  So .. *how do I get ooRexx to use the modified .cls file without
>> rebooting Windows*?
>>
>> Mike
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Status of RxFTP

[Rick McGuire]

are you calling the program using your custom command shell? I suspect that
might be the problem. Otherwise it should be picking up the change every
time the program is run, assuming it runs in a new process.

Rick

On Sat, May 18, 2024 at 11:55 AM Mike Cowlishaw  wrote:

>
>
>
>
> With a bit more info from the ISP .. I think I can solve this; so for now,
> no need for anyone else to spend time on this!
>
>
>
> Well, I was wrong, but am homing in on the problem using a modified
> rxftp.cls (rxftpx.cls).
>
> A quick question: how do I 'refresh' a class .. that is, have ooRexx use a
> modified version after I have made an experimental change?
>
> At present, if I edit the .cls file the next time I use the Rexx program
> that requires it the old version continues to be used (until I reboot
> Windows, in which case the change takes effect).
>
> Q:  So .. *how do I get ooRexx to use the modified .cls file without
> rebooting Windows*?
>
> Mike
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: Hierarchy of needs

[Rick Womer]

Not to mention:

Better computers, larger monitors, bigger & faster hard drives, comfortable
desk and chair for using them…

Rick

On Fri, May 17, 2024 at 19:22 Larry Colen  wrote:

> I posted on facebook asking about camera bags, and came up with the
> photographer gear acquisition syndrom (GAS) hierarchy of needs:
> Lenses
> Camera Bodies
> Tripods
> Camera Bags
>
>
> --
> Larry Colen
> l...@red4est.com  sent from ret13est
>
>
>
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and
> follow the directions.
>
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Stus-List Re: Traveler sheet suggestions

[Rick Brass via CnC-List]

My 38 has a 6:1 bridge deck traveler arrangement pretty similar to what you 
have. I also use a double braid line which might be either 5/16ths or 3/8ths 
(I'm getting older and forget stuff). But what I have was purchased from Cajun 
Trading. Pretty similar to Sta-Set, but with a softer, sort of fuzzy, texture 
that is easier on the hand and not as slippery. I forget what they call that 
particular line. (See comment about aging above.)

On the 25, all of the sheets are the fuzzy braid from Cajun Trading. The boat 
has been used only for recreational daysails for some time, and the softer 
lines are a lot easier on the hands of inexperienced guests while high 
performance is not real critical for the use we do.

Rick Brass
Imzadi (CC 38 mkll)
La Belle Aurore (CC 25 mk1)

Please show your appreciation for this list and the Photo Album site and help 
me pay the associated bills.  Make a contribution at:
https://www.paypal.me/stumurray
Thanks for your help.
Stu

Re: [RE-wrenches] REC modules - review?

[rick--- via RE-wrenches]

David,We’ve been installing REC since 2009 and have always had a great experience. Never had to put in for a warranty claim. If you install per REC’s Installation Manual you’ll unlikely have to file a claim. Rick BrownSolshine Energy Solar Electric Contracting Services www.solshineenergy.comRoanoke, VAOffice: 540.235.3095Mobile: 540.808.9502






CONFIDENTIALITY NOTICE -- This email is intended only for the person(s) named in
the message header. Unless otherwise indicated, it contains information that is
confidential, privileged and/or exempt from disclosure under applicable law. If you have
received this message in error, please notify the sender of the error and delete the
message. Thank you.On May 17, 2024, at 12:54 PM, david quattro via RE-wrenches  wrote:Hi everyone,  Does anyone have positive or negative experience with REC modules?Specifically failure rate, and how the company acts when an RMA is necessary. Thank youDavid QuattroCA License # 
954020. C-10, C-46ph (415) 312-2661www.quattrosolar.com
___List sponsored by Redwood AlliancePay optional member dues here: http://re-wrenches.orgList Address: RE-wrenches@lists.re-wrenches.orgChange listserver email address & settings:http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.orgThere are two list archives for searching. When one doesn't work, try the other:https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.orgList rules & etiquette:http://www.re-wrenches.org/etiquette.htmCheck out or update participant bios:http://www.members.re-wrenches.org___
List sponsored by Redwood Alliance

Pay optional member dues here: http://re-wrenches.org

List Address: RE-wrenches@lists.re-wrenches.org

Change listserver email address & settings:
http://lists.re-wrenches.org/options.cgi/re-wrenches-re-wrenches.org

There are two list archives for searching. When one doesn't work, try the other:
https://www.mail-archive.com/re-wrenches@lists.re-wrenches.org/
http://lists.re-wrenches.org/pipermail/re-wrenches-re-wrenches.org

List rules & etiquette:
http://www.re-wrenches.org/etiquette.htm

Check out or update participant bios:
http://www.members.re-wrenches.org

Importers for Japan financial institutions

[Rick Lan]

Dear all,

I have been an user for some time. I have not found importers for Japan 
financial institutions so I wrote my own. I have been using them for my own 
ledger with a couple years of data. I've clean up the code and publish them 
on Github: https://github.com/rlan/beancount-multitool

The main contribution is how to ingest CSV files from Japan banks and 
credit card. The transaction categorization is not yet published, but I use 
regular expressions.

Best Regards,
Rick

Introduction:

Beancount Multitool is a collection of command-line Python scripts that 
reads financial data from financial institutions and converts them to 
Beancount files.

The following banks are supported:

   - Japan
  - JA Bank <https://www.jabank.jp/>
  - Rakuten Card <https://www.rakuten-card.co.jp/>
  - Rakuten Bank <https://www.rakuten-bank.co.jp/>
  - SBI Shinsei Bank <https://www.sbishinseibank.co.jp/>
   
What these scripts *can* do:

   - Read raw CSV files downloaded from each institution's website.
   - Label debit and credit transactions to respective account types.
  - Debit: Expenses:JP:Unknown:NameOfInstitution
  - Credit: Income:JP:Unknown:NameOfInstitution
   
What these scripts *can not* (yet) do:

   - Label transactions with different sub-accounts, e.g., 
   Expenses:JP:Food:Grocery or Expenses:JP:Food:Restaurant.

How to use these scripts in my workflow?

   1. Download the raw CSV files from a financial institutions.
   2. Run the matching script.
   3. Include the output.bean file in my ledger.
   4. Manually edit that Beancount file to my needs.


-- 
You received this message because you are subscribed to the Google Groups 
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beancount/c534c264-dcbf-4c68-8c7e-e556eb3e18fcn%40googlegroups.com.

Re: [BVARC] Dayton Hamvention?

[Rick Hiller via BVARC]

Saw Steve and Rick at CTU yesterday.  Light rain is falling, but will go away before Dayton opens this AM.   So should be a great day.  73.  RHSent from my i-ThingamajigOn May 13, 2024, at 3:45 PM, Keith Dutson via BVARC  wrote:
Look for me at Contest University Thursday.  Also, I will be manning the CWops booth at Hamvention Friday at 1PM.73, Keith NM5G





On Monday, May 13, 2024 at 09:52:26 AM CDT, Steve Clark via BVARC  wrote:





I’ll be arriving Wednesday evening to attend Contest University, and then Hamvention on Friday and Saturday.  Hope to meet you all there.  Steve,KG5ICR  From: BVARC  On Behalf Of Chris Medlin via BVARCSent: Saturday, May 11, 2024 11:17 AMTo: BRAZOS VALLEY AMATEUR RADIO CLUB Cc: Chris Medlin Subject: Re: [BVARC] Dayton Hamvention?  For those who cannot make the trip to Dayton (or have wondered what it’s like there), you can get a bit of the experience Saturday by way of mobile video rovers who will be live broadcasting through W5KUB.com (and W5KUB on YouTube).  Tom (W5KUB) has attended Dayton every year for the last 43 years and has livestreamed on the internet for over 20 years. This year he isn’t going to make the 500-mile trip up (age 76) but has scheduled many volunteers who will be sending live video back to his command center in Memphis TN to stream out.   Also, as usual, he will continue to randomly draw for prizes in his live chatroom during Saturday, via HamBot, his application that manages all the aspects of his prize awardings. For more detailed information and a list of the prizes can be found here:hamvention 2024 (ham-tv.com)73/Chris/AC5CM  From: BVARC <bvarc-boun...@bvarc.org> On Behalf Of Richard Cary via BVARCSent: Friday, May 10, 2024 9:58 PMTo: BRAZOS VALLEY AMATEUR RADIO CLUB <bvarc@bvarc.org>Cc: Richard Cary <rick.c...@att.net>Subject: Re: [BVARC] Dayton Hamvention?  I will be arriving Wednesday to attend Contest University and then Hamvention on Friday and Saturday. I have to fly back Saturday evening.Rick CaryK5RBCFrom: BVARC <bvarc-boun...@bvarc.org> on behalf of Wes Harris via BVARC <bvarc@bvarc.org>Sent: Friday, May 10, 2024 6:16 PMTo: BRAZOS VALLEY AMATEUR RADIO CLUB <bvarc@bvarc.org>Cc: Wes Harris <wesloc...@gmail.com>; Scott Medbury <kd5...@gmail.com>; Rick Hiller <rickhille...@gmail.com>Subject: Re: [BVARC] Dayton Hamvention?  I plan on going.  Hope to see you Rick.     De W5WES Wes    Sent from my iPhone  On May 10, 2024, at 6:10 PM, Scott Medbury via BVARC <bvarc@bvarc.org> wrote: I wish I could..   73... Scott KD5FBA   On Fri, May 10, 2024, 3:18 PM Rick Hiller via BVARC <bvarc@bvarc.org> wrote:Any BVARC'ers going to Dayton Hamvention next week?  Rick  W5RH  Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ 

Brazos Valley Amateur Radio ClubBVARC mailing listBVARC@bvarc.orghttp://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.orgPublicly available archives are available here: https://www.mail-archive.com/bvarc@bvarc.org/ 
Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

bug#70940: You found a bug: the program derivation

[Rick Huijzer]

Authenticating channel 'guix', commits 9edb3f6 to 6e86089 (6 new commits)...
Building from these channels:
  brandhout-packageshttps://github.com/brandhout/guix_channel.git 5fe3961
  nonguix   https://gitlab.com/nonguix/nonguix.git 7081518
  guix  https://git.savannah.gnu.org/git/guix.git 6e86089
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...
100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building
/gnu/store/zjw8b0v33zd45n3bg9g59f5zdpzi8hfk-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... \Backtrace:
  14 (primitive-load
"/gnu/store/13bvpk5dqjmdzspb276qzs24jcj3jjhh-compute-guix-derivation")
In ice-9/eval.scm:
155:9 13 (_ _)
159:9 12 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?)
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 11 (with-fluid* _ _ _)
152:2 10 (with-fluid* _ _ _)
In ./guix/store.scm:
  2205:24  9 (run-with-store #
# ?)
   2033:8  8 (_ #)
In ./guix/gexp.scm:
   299:22  7 (_ #)
   1205:2  6 (_ #)
   1072:2  5 (_ #)
913:4  4 (_ #)
In ./guix/store.scm:
  2090:12  3 (_ #)
   1428:5  2 (map/accumulate-builds # # ?)
  1444:15  1 (_ #
("/gnu/store/hszgl65h1d3vnsifb35l4zvdvk03hqdv-guix-daem?" ?) ?)
  1444:15  0 (loop #f)

./guix/store.scm:1444:15: In procedure loop:
ERROR:
  1. :
  message:
"`/gnu/store/8dzvn0qr62a8l2ad3hx1xhjdvxifc7hn-guix-1.4.0-18.4c94b9e/bin/guix
substitute' died unexpectedly"
  status: 1
guix pull: error: You found a bug: the program
'/gnu/store/13bvpk5dqjmdzspb276qzs24jcj3jjhh-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"6e86089d563ccb67ae04cd941ca7b66c1777831f"; system: "x86_64-linux";
host version: "a682ddd70846d488cfbd82d65e8566ec6739813c"; pull-version: 1).
Please report the COMPLETE output above by email to .

This seems like a really low effort bug report, but I'm following
instructions and don't know what to include further.

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

[Edgecombe, Rick P]

On Wed, 2024-05-15 at 17:26 +0200, Oleg Nesterov wrote:
> > I think it will crash, there's explanation in the comment in
> > tools/testing/selftests/x86/test_shadow_stack.c test
> 
> OK, thanks...
> 
> But test_shadow_stack.c doesn't do ARCH_PRCTL(ARCH_SHSTK_DISABLE) if
> all the tests succeed ? Confused but nevermind.

The last test disables shadow stack as part of the test. So if it succeeds it
doesn't need to disable the shadow stack to prevent underflow.

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

[Edgecombe, Rick P]

On Wed, 2024-05-15 at 08:36 -0600, Jiri Olsa wrote:
> > 
> > Let me ask a couple of really stupid questions. What if the shadow stack
> > is "shorter" than the normal stack? I mean,

The shadow stack could overflow if it is not big enough. However since the
normal stack has return addresses and data, and shadow stack has the smaller
amount data of only return addresses, we can mostly avoid this by picking a
large size for the shadow stack.

For underflow, you can't return from the point where you enable shadow stack.
Almost all uses will enable it very early. Glibc loader does it before main is
reached, for example. The shadow stack selftest is not a typical usage in this
respect.

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

[Edgecombe, Rick P]

On Wed, 2024-05-15 at 13:35 +0200, Oleg Nesterov wrote:
> Let me repeat I know nothing about shadow stacks, only tried to
> read Documentation/arch/x86/shstk.rst few minutes ago ;)
> 
> On 05/13, Jiri Olsa wrote:
> > 
> > 1) current uretprobe which are not working at the moment and we change
> >     the top value of shadow stack with shstk_push_frame
> > 2) optimized uretprobe which needs to push new frame on shadow stack
> >     with shstk_update_last_frame
> > 
> > I think we should do 1) and have current uretprobe working with shadow
> > stack, which is broken at the moment
> 
> Agreed,
> 
> > I'm ok with not using optimized uretprobe when shadow stack is detected
> > as enabled and we go with current uretprobe in that case
> 
> But how can we detect it? Again, suppose userspace does

the rdssp instruction returns the value of the shadow stack pointer. On non-
shadow stack it is a nop. So you could check if the SSP is non-zero to find if
shadow stack is enabled. This would catch most cases, but I guess there is the
possibility of it getting enabled in a signal that hit between checking and the
rest of operation. Is this uretprobe stuff signal safe in general?

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

[Edgecombe, Rick P]

On Mon, 2024-05-13 at 15:23 -0600, Jiri Olsa wrote:
> so at the moment the patch 6 changes shadow stack for
> 
> 1) current uretprobe which are not working at the moment and we change
>    the top value of shadow stack with shstk_push_frame
> 2) optimized uretprobe which needs to push new frame on shadow stack
>    with shstk_update_last_frame
> 
> I think we should do 1) and have current uretprobe working with shadow
> stack, which is broken at the moment
> 
> I'm ok with not using optimized uretprobe when shadow stack is detected
> as enabled and we go with current uretprobe in that case
> 
> would this work for you?

Sorry for the delay. It seems reasonable to me due to 1 being at a fixed address
where 2 was arbitrary address. But Peterz might have felt the opposite earlier.
Not sure.

I'd also love to get some second opinions from broonie (arm shadow stack) and
Deepak (riscv shadow stack).

Deepak, even if riscv has a special instruction that pushes to the shadow stack,
will it be ok if there is a callable operation that does the same thing? Like,
aren't you relying on endbranches or the compiler or something such that
arbitrary data can't be pushed via that instruction?

BTW Jiri, thanks for considering shadow stack in your work.

RE: SOLR 8.11.1 SSL Enable Failing

[Hodder, Rick (Property and Casualty CIO)]

Hi Gora,

I looked at the logs, but there is nothing about ssl, or bad file (I assume you 
mean that maybe it cannot find the key file) just 
2024-05-07 22:24:01.400 INFO  (main) [   ] o.a.s.u.c.SSLConfigurations Setting 
javax.net.ssl.keyStorePassword
2024-05-07 22:24:01.400 INFO  (main) [   ] o.a.s.u.c.SSLConfigurations Setting 
javax.net.ssl.trustStorePassword


Thanks,

RICK HODDER
Staff Software Engineer
Global Specialty

The Hartford
83 Wooster Heights Rd. | 2nd floor
Danbury, CT, 06810
W: 475-329-6251
Email: richard.hod...@thehartford.com
www.thehartford.com
www.facebook.com/thehartford
twitter.com/thehartford
 



-Original Message-
From: Gora Mohanty  
Sent: Saturday, May 11, 2024 12:38 AM
To: users@solr.apache.org
Cc: solr-u...@lucene.apache.org
Subject: Re: SOLR 8.11.1 SSL Enable Failing

CAUTION:  This email originated from outside the organization.  Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Dear Rick,

Have no familiarity with setting up Solr on Windows, but your oaths look like 
they might be missing a slash at the beginning, e.g.,
   set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.p12
maybe should be
   set SOLR_SSL_KEY_STORE=/etc/solr-ssl.keystore.p12

Also, please check the Solr startup logs, which should have error messages if 
the path is incorrect.

Regards,
Gora

On Sat, 11 May 2024 at 00:40, Hodder, Rick (Property and Casualty CIO) 
 wrote:

> I’ve asked this twice on here, and on stack overflow, with no answers.
>
>
>
> Is there another site that could give me guidance?
>
>
>
>
>
> Thanks,
>
>
>
> *RICK HODDER*
> Staff Software Engineer
> Global Specialty
>
> [image: The Hartford] <https://www.thehartford.com/>
>
> The Hartford
> 83 Wooster Heights Rd. | 2nd floor
> Danbury, CT, 06810
> W: 475-329-6251
>
> Email: richard.hod...@thehartford.com
>
> http://www.thehartford.com
> https://urldefense.com/v3/__http://www.facebook.com/thehartford__;!!PZ
> 0xAML5PpHLxYfxmvfEjrhN5g!Wvga97XR_9P2V5aJG5fMy7ap7w-mxe_LfFVkzSTTsb0xa
> nckRl9gdHGzBW7BxvPQ63bY9OCPfEfk3VpG647BVg$
> https://urldefense.com/v3/__http://twitter.com/thehartford__;!!PZ0xAML
> 5PpHLxYfxmvfEjrhN5g!Wvga97XR_9P2V5aJG5fMy7ap7w-mxe_LfFVkzSTTsb0xanckRl
> 9gdHGzBW7BxvPQ63bY9OCPfEfk3VozKIHyYg$
>
>
>
>
>
>
>
> *From:* Hodder, Rick (Property and Casualty CIO)
> *Sent:* Tuesday, May 7, 2024 6:40 PM
> *To:* 'solr-u...@lucene.apache.org' 
> *Subject:* SOLR 8.11.1 SSL Enable Failing
>
>
>
> I’m trying to enable SSL on SOLR 8.11.1
>
>
>
> My network team purchased a certificate Imported into JDK into a file 
> cacerts I copied that file to etc/solr-ssl.keystore.p12
>
>
>
> I uncommented the SOLR SSL changed solr.in.cmd and set them as follows:
>
>
>
> REM Enables HTTPS. It is implictly true if you set SOLR_SSL_KEY_STORE. 
> Use this config
>
> REM to enable https module with custom jetty configuration.
>
> set SOLR_SSL_ENABLED=true
>
> REM Uncomment to set SSL-related system properties
>
> REM Be sure to update the paths to the correct keystore for your 
> environment
>
> set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.p12
>
> set SOLR_SSL_KEY_STORE_PASSWORD=-
>
> set SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.p12
>
> set SOLR_SSL_TRUST_STORE_PASSWORD=-
>
> REM Require clients to authenticate
>
> set SOLR_SSL_NEED_CLIENT_AUTH=false
>
> REM Enable clients to authenticate (but not require)
>
> set SOLR_SSL_WANT_CLIENT_AUTH=false
>
> REM Verify client hostname during SSL handshake
>
> set SOLR_SSL_CLIENT_HOSTNAME_VERIFICATION=false
>
> REM SSL Certificates contain host/ip "peer name" information that is 
> validated by default. Setting
>
> REM this to false can be useful to disable these checks when re-using 
> a certificate on many hosts
>
> set SOLR_SSL_CHECK_PEER_NAME=true
>
> REM Override Key/Trust Store types if necessary
>
> REM set SOLR_SSL_KEY_STORE_TYPE=PKCS12
>
> REM set SOLR_SSL_TRUST_STORE_TYPE=PKCS12
>
> I thin started solr from the command line, and this is what I saw:
>
>
>
> E:\ApacheSolr8_11_1>bin\solr.cmd start -p 8983
>
> Java HotSpot(TM) 64-Bit Server VM warning: JVM cannot use large page 
> memory because it does not have enough privilege to lock pages in memory.
>
> INFO  - 2024-05-06 17:05:17.952;
> org.apache.solr.util.configuration.SSLConfigurations; Setting 
> javax.net.ssl.keyStorePassword
>
> INFO  - 2024-05-06 17:05:17.967;
> org.apache.solr.util.configuration.SSLConfigurations; Setting 
> javax.net.ssl.trustStorePassword
>
> Waiting up to 30 to see Solr running on port 8983
>
> INFO  - 2024-05-06 17:05:27.966; 
> org.apac

RE: SOLR 8.11.1 SSL Enable Failing

[Hodder, Rick (Property and Casualty CIO)]

Hi Joe,

Sorry for the delay in responding.

Thanks for looking at this.

>> Some of the googling I did related to the "established connection aborted" 
>> seems to indicate that it could be related to issues in the network path 
>> from your command line to your localhost:8983.

I'll look into this, but if I turn off the ssl feature, I'm able to run solr at 
localhost:8983.


Thanks,

RICK HODDER
Staff Software Engineer
Global Specialty

The Hartford
83 Wooster Heights Rd. | 2nd floor
Danbury, CT, 06810
W: 475-329-6251
Email: richard.hod...@thehartford.com
www.thehartford.com
www.facebook.com/thehartford
twitter.com/thehartford
 



-Original Message-
From: Gilvary, Joseph  
Sent: Friday, May 10, 2024 4:58 PM
To: users@solr.apache.org
Subject: Re: SOLR 8.11.1 SSL Enable Failing

CAUTION:  This email originated from outside the organization.  Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Good evening, Rick, and Happy Friday,

I'm not an expert, especially running on Windows.

Some of the googling I did related to the "established connection aborted" 
seems to indicate that it could be related to issues in the network path from 
your command line to your localhost:8983. It doesn't seem specific to Java, 
based on the posts I saw. Several posters sought help debugging it in other 
scenarios on Windows. (That part of the text seems to be a Windows error 
message that gets copied into the Java exception error text.) So I wonder: if 
the JVM doesn't have privileges to lock pages in memory, do you know that it 
has privileges to connect to localhost:8983?

 HTH. Stay safe, stay healthy,

 Joe

____
From: Hodder, Rick (Property and Casualty CIO) 

Sent: Friday, May 10, 2024 3:08 PM
To: 'solr-u...@lucene.apache.org' 
Subject: RE: SOLR 8.11.1 SSL Enable Failing

CAUTION: This email has originated from a source outside of USPTO. PLEASE 
CONSIDER THE SOURCE before responding, clicking on links, or opening 
attachments.


I've asked this twice on here, and on stack overflow, with no answers.



Is there another site that could give me guidance?





Thanks,



RICK HODDER
Staff Software Engineer
Global Specialty

[The Hartford]<https://www.thehartford.com/>

The Hartford
83 Wooster Heights Rd. | 2nd floor
Danbury, CT, 06810
W: 475-329-6251

Email: richard.hod...@thehartford.com<mailto:richard.hod...@thehartford.com>

http://www.thehartford.com<https://www.thehartford.com/>
https://urldefense.com/v3/__http://www.facebook.com/thehartford__;!!PZ0xAML5PpHLxYfxmvfEjrhN5g!V9gdzOrQSBCtx9ANJww4Lx4do8ZYVLLFpsTAUC94HoY1Y2IehGLjzGZLoQ0AwqUoP5Vyz9s9n1KbNFQH7OsBaGLUmZre6p-kiPKAD6oNRQ$
 
<https://urldefense.com/v3/__https://www.facebook.com/thehartford__;!!PZ0xAML5PpHLxYfxmvfEjrhN5g!V9gdzOrQSBCtx9ANJww4Lx4do8ZYVLLFpsTAUC94HoY1Y2IehGLjzGZLoQ0AwqUoP5Vyz9s9n1KbNFQH7OsBaGLUmZre6p-kiPJ4bd_Hnw$
 > 
https://urldefense.com/v3/__http://twitter.com/thehartford__;!!PZ0xAML5PpHLxYfxmvfEjrhN5g!V9gdzOrQSBCtx9ANJww4Lx4do8ZYVLLFpsTAUC94HoY1Y2IehGLjzGZLoQ0AwqUoP5Vyz9s9n1KbNFQH7OsBaGLUmZre6p-kiPJiBz91xA$
 
<https://urldefense.com/v3/__https://twitter.com/thehartford__;!!PZ0xAML5PpHLxYfxmvfEjrhN5g!V9gdzOrQSBCtx9ANJww4Lx4do8ZYVLLFpsTAUC94HoY1Y2IehGLjzGZLoQ0AwqUoP5Vyz9s9n1KbNFQH7OsBaGLUmZre6p-kiPJfJ_84bw$
 >







From: Hodder, Rick (Property and Casualty CIO)
Sent: Tuesday, May 7, 2024 6:40 PM
To: 'solr-u...@lucene.apache.org' 
Subject: SOLR 8.11.1 SSL Enable Failing



I'm trying to enable SSL on SOLR 8.11.1



My network team purchased a certificate Imported into JDK into a file cacerts I 
copied that file to etc/solr-ssl.keystore.p12



I uncommented the SOLR SSL changed solr.in.cmd and set them as follows:



REM Enables HTTPS. It is implictly true if you set SOLR_SSL_KEY_STORE. Use this 
config

REM to enable https module with custom jetty configuration.

set SOLR_SSL_ENABLED=true

REM Uncomment to set SSL-related system properties

REM Be sure to update the paths to the correct keystore for your environment

set SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.p12

set SOLR_SSL_KEY_STORE_PASSWORD=-

set SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.p12

set SOLR_SSL_TRUST_STORE_PASSWORD=-

REM Require clients to authenticate

set SOLR_SSL_NEED_CLIENT_AUTH=false

REM Enable clients to authenticate (but not require)

set SOLR_SSL_WANT_CLIENT_AUTH=false

REM Verify client hostname during SSL handshake

set SOLR_SSL_CLIENT_HOSTNAME_VERIFICATION=false

REM SSL Certificates contain host/ip "peer name" information that is validated 
by default. Setting

REM this to false can be useful to disable these checks when re-using a 
certificate on many hosts

set SOLR_SSL_CHECK_PEER_NAME=true

REM Override Key/Trust Store types if necessary

REM set SOLR_SSL_KEY_STORE_TYPE=PKCS12

REM set SOLR_SSL_TRUST_STORE_TYPE=PKCS12

I thin started solr from the command line, a

Re: [BVARC] Downsizing Continues

[Rick Hiller via BVARC]

Sent from my i-Thingamajig

> On May 14, 2024, at 9:39 AM, Scott Medbury via BVARC  wrote:
> 
> 
> I have 3 All Terrain bicycles that I need to sell as we try to consolidate 
> our spaces.
> 
> $40 or best offer for each
> 
> 1 -24" Huffy Girls/women's 
> 
> 1 -26" Huffy Women's 18 speed
> 
> 1- 26" Huffy Men's 18 speed 
> 
> Pictures upon request.
> 
> If interested, please respond off the reflector. 
> 
> 73 ... Scott KD5FBA 
> 
> Brazos Valley Amateur Radio Club
> 
> BVARC mailing list
> BVARC@bvarc.org
> http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
> Publicly available archives are available here: 
> https://www.mail-archive.com/bvarc@bvarc.org/


Brazos Valley Amateur Radio Club

BVARC mailing list
BVARC@bvarc.org
http://mail.bvarc.org/mailman/listinfo/bvarc_bvarc.org
Publicly available archives are available here: 
https://www.mail-archive.com/bvarc@bvarc.org/ 

Pittsburgh

[Rick Womer]

We took a short trip to Pittsburgh last month, and were able to enjoy this 
pleasant city in beautiful weather. 

The city is where the Allegheny and Monongahela rivers join to form the Ohio 
River, which flows west to the Mississippi River.  My family had driven through 
Pittsburgh when I was a child, and I remember smoke and steel mills. Now only 
one steel mill remains, the smoke is gone, and the city is prosperous.

The views are excellent from Mount Washington, an escarpment south of the 
downtown area, served by two pairs of antique funicular rail cars (we went up 
and down the Duquesne Incline; the other (Monangahela Incline, about a mile 
away) was closed.

The visible bridges are among 446 in Pittsburgh, the most of any city in the 
world (and 3x the number in Venice).

The bronze figure on the bench, “Sidewalk Judge,” is by Seward Johnson, an heir 
to the Johnson & Johnson fortune and an artist. 

https://rickwomer.smugmug.com/2024/April-2024/Pittsburgh-Apr-24

Comments and critiques eagerly anticipated.

Rick




--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

[Sprinklerforum] Re: Cannabis growing

[Rick Matsuda]

Maybe they can install solid vertical bulkheads along the length of the tables 
spaced at 10 to 12-feet between the bulkheads. 
These would slow the progression of any fire along the length of the tables and 
force the heat out from under the tables to activate the overhead sprinklers 
quicker. 
Rick Matsuda 

> On May 13, 2024, at 6:40 AM, Steve Leyton  wrote:
> 
> 
> All:
> 
> I was just approved by NFPA Standards Council to represent AFSA on the 420.   
> I do not yet have a copy of the first draft (it’s not available on the 420 
> web page or through free access), but I’ve requested and will look over the 
> fire protection systems design criteria, which I believe consists of nothing 
> tangible at this moment.  
>  
> Since my firm is located in SoCal, we’ve done several grows and each one has 
> been different.   We’ve designed for an open warehouse with fixed lighting 
> mounts that simply go up and down.  We’ve had to contend with a fixture 
> that’s about 4’ wide and can be moved up/down/left/right.   We’ve done 
> two-tier grows and three-tier grows and we’ve also dealt with the pre-fab 
> grow rooms.   Within those grow rooms we’ve seen fixed tables and the sliding 
> ones alluded to in this thread.   To say it’s the Wild West out here is an 
> understatement. 
>  
> Especially in CA, many fire officials have simply hit the HPS button and 
> called it a 24’ (three tiers of mature plants) of Class 3 or 4 on racks in 
> the open rooms, but I have issues with that since mature plants are 85% 
> water.   The growing medium that is fast becoming industry standard is Class 
> A material (rock wool), it’s kept wet, and doesn’t require a container, so 
> the commodity ISN’T that hazardous.   What complicates things is the presence 
> of the solid shelving, and that gets even more complicated by the sliding 
> fixtures that can be nested up to four across, which is a 16’ wide solid 
> obstruction in some grow rooms, and sometimes there are two or three of those 
> shelving levels.  
>  
> I don’t have any specific answers right now but I am hopeful that we can 
> point the code development conversation down a reality-based path, that being 
> the fact that this commodity isn’t all that hazardous (well, if the munchies 
> aren’t considered a hazard), and the shelving (which is plastic or polymer 
> composite) makes up a very small percentage of the overall volume of the 
> storage space.   Yes, there are obstructions to sprinkler discharge, but we 
> have that in other storage arrays as well, so absent any clearer 
> prescription, it’s hard to argue with the shielded fire load approach and use 
> EH2.  But if it’s only a single tier, then I’m probably back in the OH2 camp, 
> although as I said before, it almost seems like there are no two growing 
> facilities that are alike and the system designer is going to have to flex to 
> what the AHJ is requiring and what the specific conditions of that particular 
> facility would dictate.
>  
>  
> The foregoing is my opinion only and does not represent NFPA or the NFPA 420 
> Technical Committee, nor intended to serve as an interpretation of the 
> standard.
>  
> Protection Design and Consulting
> Steve Leyton, President
> T  |  619.255.8964 x 102  |  www.protectiondesign.com 
> 2851 Camino Del Rio South  |  Suite 210  |  San Diego, CA  92108
> Fire Protection System Design | Consulting | Planning | Training
>  
>  
>  
>  
>  
>  
>  
> From: Fpdcdesign  
> Sent: Monday, May 13, 2024 8:52 AM
> To: Discussion list on issues relating to automatic fire sprinklers 
> 
> Subject: [Sprinklerforum] Re: Cannabis growing
>  
> The array of tables are about 1000 sqft each
>  
> Todd G Williams, PE
> Fire Protection Design/Consulting
> Stonington, CT
> 860-535-2080 (ofc)
> 860-554-7054  (fax)
> 860-608-4559 (cell)
> 
> 
> 
> On May 13, 2024 at 10:42 AM,  wrote:
> 
> I’m in the 2019 edition, but sections 9.5.5.3.1.5 and 9.5.5.3.2 may help 
> provide guidance.  They do not up the hazard level due to an obstruction in 
> place, I like the idea of taking into effect a shielded fire, especially with 
> the size of some of these grow ops these days, but there are certain 
> provisions that would suggest otherwise….
>  
> Spencer Tomlinson, PE
> Owner, Fire Protection Engineer
>  
> 
>Cell: 620-955-7293
>  
> From: Fpdcdesign  
> Sent: Monday, May 13, 2024 9:32 AM
> To: Discussion list on issues relating to automatic fire sprinklers 
> 
> Subject: [Sprinklerforum] Re: Cannabis growing
>  
> Travis, The definition of EH2 and section 19.3.3.1.5 both deal with 
> protection where there are unprotected spaces adjacent or within. The big 
> difference is the word “extensive

Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support

[Edgecombe, Rick P]

On Mon, 2024-05-13 at 18:50 +0900, Masami Hiramatsu wrote:
> > I guess it's doable, we'd need to keep both trampolines around, because
> > shadow stack is enabled by app dynamically and use one based on the
> > state of shadow stack when uretprobe is installed
> > 
> > so you're worried the optimized syscall path could be somehow exploited
> > to add data on shadow stack?

Shadow stack allows for modification to the shadow stack only through a few
limited ways (call, ret, etc). The kernel has the ability to write through
shadow stack protections (for example when pushing and popping signal frames),
but the ways in which it does this are limited in order to try to prevent
providing extra capabilities to attackers wanting to craft their own shadow
stacks.

But the HW features have optional abilities to allow extra patterns of shadow
stack modification for userspace as well. This can facilitate unusual patterns
of stack modification (like in this series). For, x86 there is the ability to
allow an instruction (called WRSS) such that userspace can also write arbitrary
data to the shadow stack. Arm has something likes that, plus an instruction to
push to the shadow stack.

There was some debate about whether to use these features, as glibc could not
perfectly match compatibility for features that play with the stack like
longjmp(). As in, without using those extra HW capabilities, some apps would
require modifications to work with shadow stack.

There has been a lot of design tension between security, performance and
compatibility in figuring out how to fit this feature into existing software. In
the end the consensus was to not use these extra HW capabilities, and lean
towards security in the implementation. To try to summarize the debate, this was
because we could get pretty close to compatibility without enabling these extra
features.

So since this solution does something like enabling these extra capabilities in
software that were purposely disabled in HW, it raises eyebrows. Glibc has some
operations that now have extra steps because of shadow stack. So if we could do
something that was still functional, but slower and more secure, then it seems
roughly in line with the tradeoffs we have gone with so far.

But shadow stack is not in widespread use yet, so whether we have the final
tradeoffs settled is still open I think. For example, other libcs have expressed
interest in using WRSS.

I'm also not clear on the typical use of uretprobes (debugging vs production).
And whether shadow stack + debugging + production will happen seems pretty
unknown.

> 
> Good point. For the security concerning (e.g. leaking sensitive information
> from secure process which uses shadow stack), we need another limitation
> which prohibits probing such process even for debugging. But I think that
> needs another series of patches. We also need to discuss when it should be
> prohibited and how (e.g. audit interface? SELinux?).
> But I think this series is just optimizing currently available uprobes with
> a new syscall. I don't think it changes such security concerning.

Patch 6 adds support for shadow stack for uretprobes. Currently there is no
support.

Peterz had asked that the new solution consider shadow stack support, so I think
that is how this series grew kind of two goals: new faster uretprobes and
initial shadow stack support.

git: 2c65656b29fb - releng/14.1 - nfsd: Fix Link conformance with RFC8881 for delegations

[Rick Macklem]

The branch releng/14.1 has been updated by rmacklem:

URL: 
https://cgit.FreeBSD.org/src/commit/?id=2c65656b29fb803edeeda931c6771c7c22c9efac

commit 2c65656b29fb803edeeda931c6771c7c22c9efac
Author: Rick Macklem 
AuthorDate: 2024-05-04 21:30:07 +
Commit: Rick Macklem 
CommitDate: 2024-05-13 04:49:04 +

nfsd: Fix Link conformance with RFC8881 for delegations

RFC8881 specifies that, when a Link operation occurs on an
NFSv4, that file delegations issued to other clients must
be recalled.  Discovered during a recent discussion on nf...@ietf.org.

Although I have not observed a problem caused by not doing
the required delegation recall, it is definitely required
by the RFC, so this patch makes the server do the recall.

Tested during a recent NFSv4 IETF Bakeathon event.

Approved by:re (cperciva)

(cherry picked from commit 3f65000b6b1460a7a23cd83014bb41a68d1a8a19)
(cherry picked from commit 3c414a8c2fb37ca37de454aaa145e7bcaefcaa05)
---
 sys/fs/nfs/nfs_var.h|  2 +-
 sys/fs/nfsserver/nfs_nfsdport.c | 12 +++-
 sys/fs/nfsserver/nfs_nfsdserv.c | 11 +--
 3 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/sys/fs/nfs/nfs_var.h b/sys/fs/nfs/nfs_var.h
index 578fb3ce1340..950e0c097457 100644
--- a/sys/fs/nfs/nfs_var.h
+++ b/sys/fs/nfs/nfs_var.h
@@ -713,7 +713,7 @@ int nfsvno_rmdirsub(struct nameidata *, int, struct ucred 
*, NFSPROC_T *,
 struct nfsexstuff *);
 int nfsvno_rename(struct nameidata *, struct nameidata *, u_int32_t,
 u_int32_t, struct ucred *, NFSPROC_T *);
-int nfsvno_link(struct nameidata *, vnode_t, struct ucred *,
+int nfsvno_link(struct nameidata *, vnode_t, nfsquad_t, struct ucred *,
 NFSPROC_T *, struct nfsexstuff *);
 int nfsvno_fsync(vnode_t, u_int64_t, int, struct ucred *, NFSPROC_T *);
 int nfsvno_statfs(vnode_t, struct statfs *);
diff --git a/sys/fs/nfsserver/nfs_nfsdport.c b/sys/fs/nfsserver/nfs_nfsdport.c
index f8c2ddfd2a59..f4679309657b 100644
--- a/sys/fs/nfsserver/nfs_nfsdport.c
+++ b/sys/fs/nfsserver/nfs_nfsdport.c
@@ -1656,8 +1656,8 @@ out1:
  * Link vnode op.
  */
 int
-nfsvno_link(struct nameidata *ndp, struct vnode *vp, struct ucred *cred,
-struct thread *p, struct nfsexstuff *exp)
+nfsvno_link(struct nameidata *ndp, struct vnode *vp, nfsquad_t clientid,
+struct ucred *cred, struct thread *p, struct nfsexstuff *exp)
 {
struct vnode *xp;
int error = 0;
@@ -1672,9 +1672,11 @@ nfsvno_link(struct nameidata *ndp, struct vnode *vp, 
struct ucred *cred,
}
if (!error) {
NFSVOPLOCK(vp, LK_EXCLUSIVE | LK_RETRY);
-   if (!VN_IS_DOOMED(vp))
-   error = VOP_LINK(ndp->ni_dvp, vp, >ni_cnd);
-   else
+   if (!VN_IS_DOOMED(vp)) {
+   error = nfsrv_checkremove(vp, 0, NULL, clientid, p);
+   if (error == 0)
+   error = VOP_LINK(ndp->ni_dvp, vp, >ni_cnd);
+   } else
error = EPERM;
if (ndp->ni_dvp == vp) {
vrele(ndp->ni_dvp);
diff --git a/sys/fs/nfsserver/nfs_nfsdserv.c b/sys/fs/nfsserver/nfs_nfsdserv.c
index 8141ee6cbdb6..0c8bda6dc6a6 100644
--- a/sys/fs/nfsserver/nfs_nfsdserv.c
+++ b/sys/fs/nfsserver/nfs_nfsdserv.c
@@ -1797,6 +1797,7 @@ nfsrvd_link(struct nfsrv_descript *nd, int isdgram,
char *bufp;
u_long *hashp;
struct thread *p = curthread;
+   nfsquad_t clientid;
 
if (nd->nd_repstat) {
nfsrv_postopattr(nd, getret, );
@@ -1858,8 +1859,14 @@ nfsrvd_link(struct nfsrv_descript *nd, int isdgram,
NULL);
}
}
-   if (!nd->nd_repstat)
-   nd->nd_repstat = nfsvno_link(, vp, nd->nd_cred, p, exp);
+   if (!nd->nd_repstat) {
+   clientid.qval = 0;
+   if ((nd->nd_flag & (ND_IMPLIEDCLID | ND_NFSV41)) ==
+   (ND_IMPLIEDCLID | ND_NFSV41))
+   clientid.qval = nd->nd_clientid.qval;
+   nd->nd_repstat = nfsvno_link(, vp, clientid, nd->nd_cred,
+   p, exp);
+   }
if (nd->nd_flag & ND_NFSV3)
getret = nfsvno_getattr(vp, , nd, p, 0, NULL);
if (dirp) {

Re: Did anyone get Aurora photos?

[Rick Womer]

Philly is a bit far south, and it was cloudy and wet (and still is).

Rick

On Sun, May 12, 2024 at 4:32 PM Steve Cottrell  wrote:

> Zillions of pics on Twitter, and of course I was in the land of Nod when
> it all happened :-)
>
> Saturday night I was driving home from some work at a football match, and
> too zonked to stop and stare at the sky.
>
> What annoys me is that there’s loads of photos by people who say ‘ooh yeah
> you have to use a long exposure on a camera to really see it well, can be
> tricky with the naked eye…’ well I wanna see it blaring at me with my own
> eyeballs so sod that!!
>
> :-)
>
> Cotty
>
> > On 12 May 2024, at 01:06, Larry Colen  wrote:
> >
> > I’m afraid that even if they’re visible this far south, I can’t get to
> anyplace dark enough
>
>
> --
> %(real_name)s Pentax-Discuss Mail List
> To unsubscribe send an email to pdml-le...@pdml.net
> to UNSUBSCRIBE from the PDML, please visit the link directly above and
> follow the directions.
--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: [MBZ] Current show at Okie Acres

[Rick Knoble via Mercedes]

Pretty far South for the Northern lights. Quite incredible.

Get Outlook for Android

From: Mercedes  on behalf of Buggered Benzmail 
via Mercedes 
Sent: Friday, May 10, 2024 10:16:01 PM
To: Mercedes Discussion List 
Cc: Buggered Benzmail 
Subject: Re: [MBZ] Current show at Okie Acres

WOW!!!

--FT
Sent from iFōn

> On May 10, 2024, at 11:12 PM, Kaleb Striplin via Mercedes 
>  wrote:
>
> 
> 
> 
> 
> 
> 
>
> Sent from my iPhone___
> http://www.okiebenz.com
>
> To search list archives http://www.okiebenz.com/archive/
>
> To Unsubscribe or change delivery options go to:
> http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com
>

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

___
http://www.okiebenz.com

To search list archives http://www.okiebenz.com/archive/

To Unsubscribe or change delivery options go to:
http://mail.okiebenz.com/mailman/listinfo/mercedes_okiebenz.com

[Sprinklerforum] Re: Standpipe NFPA14 2019

[Rick Matsuda]

Gosh, 73-feet is a long distance to drag fire hose from the valve at the exit 
door along the length of the rated exit passageway. 
If there’s no occupancy openings in the length of the exit passageway, then 
maybe you could ask the AHJ if he wants a hose valve at the inside end of the 
exit passageway. 
If that’s the case, then I don’t think you need to add the additional 250-gpm. 
Just use 500 plus 250.
Just my opinion.
Rick Matsuda 

> On May 10, 2024, at 3:30 PM, Steve Leyton  wrote:
> 
> 
> Do you have a hose connection on the 1st floor landing of the remote 
> standpipe stairwell in addition to the one at the exit passageway door?   And 
> is there access to occupiable areas on the first floor from the passageway or 
> stairwell? 
>  
> Obviously, two or more hose connections supplied by a feed main on a single 
> floor is a horizontal standpipe by definition, but it would seem to me that 
> in this type of egress system that would be redundant or not of value 
> depending on where a firefighter would be going with the water after 
> connection to one or the other hose connection.
>  
> The foregoing does not represent any opinion or interpretation of the 
> standard on behalf of NFPA or the NFPA 14 Technical Committee.
>  
> 
> Steve Leyton, President 
> T  |  619.255.8964 x 102  |  www.protectiondesign.com 
> 2851 Camino Del Rio South  |  Suite 210  |  San Diego, CA  92108
> Fire Protection System Design | Consulting | Planning | Training
>  
>  
>  
> From: Chris Wilson [mailto:chr...@tvfpinc.com] 
> Sent: Friday, May 10, 2024 7:42 AM
> To: sprinklerforum@lists.firesprinkler.org
> Subject: [Sprinklerforum] Standpipe NFPA14 2019
>  
>  
> To all,
> I have a 4 story building with 2 exit stairways I am installing a class I 
> manual wet standpipe combination sprinkler system. The remote stair is on the 
> interior of the building and has a rated exit passageway  on the first floor 
> that is 73’ long. I am placing all hose valves on the main floor landings and 
> one a the exit door of the exit passage way.
>  
> I am planning on calculating 500 gpm from the remote stand pipe and 250 for 
> the 2nd standpipe. The exit passage way hose connection will be fed by a  
> 2/12 lateral pipe fed from the  4” horizontal supply to the remote standpipe 
> as it pass by the exit passageway.
>  
> Do I need to include an additional 250 gpm in my calcs at the hose valve at 
> the exit passageway?
>  
> Thanks
> Christopher S. Wilson SET
> Project Design Manager
> Treasure Valley Fire Protection
> 2731 S. Saturn Way
> Boise, ID 83709
> Phone:  208-362-1888
> Fax: 208-362-2207
>  
> please note all TVFP email
> addresses have changed
> new email below
>  
> chr...@tvfpinc.com
>  
> 
> _
> SprinklerForum mailing list:
> https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
> To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org

_
SprinklerForum mailing list:
https://lists.firesprinkler.org/list/sprinklerforum.lists.firesprinkler.org
To unsubscribe send an email to sprinklerforum-le...@lists.firesprinkler.org