Hello, there is a Thief , 66.3 Solana stolen from me out of my Sollet wallet

Hello please help, this address that I'm posting has stolen 66.3 Solana from me Somehow,my address is
HAYFD2u1wjQAGf4APKF1NUsbTGLT7HdxHSj5ahpn9Lag
The address that stole my funds is
7r8N7h4fMShFNgmeBHmym7UmaBKpBzEojuanRf22pUxz
Please , the signature on Solana exploer is 2cNetUNSuSyeKKUBs4MFvrT8uVAXhkRGXxpMvPZBLvPCLmGwf5gUVYoGf2upUpppq3NkBj13UDRiW8HBmxSnS5LM

Sir, can you please tell me if this is an address associated with the Serum
DeX or Raydium?
On Sat, May 8, 2021, 9:43 PM Armani Ferrante @.***>
wrote:

Closed #233 https://github.com/project-serum/spl-token-wallet/issues/233
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/project-serum/spl-token-wallet/issues/233#event-4709437100,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATDQXYNTSN5ZPYUBURFWV4TTMXSC7ANCNFSM44ODOXQQ
.


[Bug]: Cookie Table header doesn't span full width

Expected Behavior
The header displayed when using the caption option for the cookieTable should span the whole width of the container in bar or bar wide layouts. In box layout, the header looks correct:

Current Behavior
In bar or bar wide layout, the header is crammed to the left side, and the border doesn't span the whole width:

Steps to reproduce
Use bar layout for the preferencesModal and add a cookieTable with a caption.
Proposed fix or additional info.
No response
Version
3.0.0-rc.15
On which browser do you see the issue?
Firefox

Nice catch!


Middlware should not impact transactions

At the moment a normal tx can not be send when the mdw is down (can be reproduced by changing the mdw url in the settings to a broken one). The middleware should not impact our wallet like this.

It looks like the wallet is trying to calculate the transaction fee, which can not be retrieved and because of the missing data the transaction can not be executed. In case of not responding MDW the fee if possible should be retrieved from the node, otherwise omitted.

The current version of the wallet is capable of sending transactions when the mdw is unavailable or if it does not respond.


Is Visual Basic VB supported for notebooks?

Question
I opened visual studio code and installed .NET 5 and the .NET Interactive Notebooks in visual studio code.  I saw that c# needs #!csharp and it worked with C#.  #!js worked with node js.  #!fsharp works with f#.  Is there support for VB?  I tried #!vb #!basic #!visualbasic  all with no luck.

Visual Basic is not supported because there's no interactive dialect for it.

Any idea when will there be an "interactive dialect" for Visual Basic .Net?
Why is Microsoft leaving Visual Basic so much behind?
The lack of this "interactive dialect" for Visual Basic was an issue two years ago and, it seems, nothing has been done since.
Are there technical roadblocks for Microsoft to create this?
Not sure why this was closed so hastily: https://github.com/dotnet/roslyn/issues/51062
Historically, BASIC and Visual Basic provided an "interactive" experience for programmers, before C# was even born. And VB.Net is still highly popular to this day.
Big fan of Notebooks! … But why were F# and PowerShell supported before Visual Basic .Net? The later is more popular than the former two together.
It seems so misleading to name it ".Net Interactive" and support PowerShell but not Visual Basic .Net …


Mobile - Unified account - Bug related to Address book

Describe the bug

[x] Show incorrect list account on address book
Actual: Show account does not support
https://github.com/user-attachments/assets/23d932ab-fbda-410f-9696-9aec35205161
Expect: Filter account by token

[x] Do not save address TON
Actual: Show message Invalid contact address

Expect: Allow input address TON

[x] Show incorrect account when filter
Actual: Show incorrect tag
https://github.com/user-attachments/assets/4278020d-f474-4c6a-a611-d994d561ba7b
Expect: Show correct account

Version test: SubWallet v1.1.84(440)b-v11
Device test: Samsung S20
Validation passed:

Correctly displayed account list on address book

https://github.com/user-attachments/assets/6ce620b9-f501-4526-a30f-a2dd3563352e

Allow input address TON when add contact address

https://github.com/user-attachments/assets/d61eea26-7b6f-473c-8a95-1027db2ecbf3

Show correct account when filter

https://github.com/user-attachments/assets/c35ba94f-ee6d-498c-b4d1-ce7cf0f0ff97


Failed to start Prometheus Unbound Exporter

Hello,
The prometheus unbound exporter service fails to start, and it claims the Start request repeated too quickly. Can you please tell me how to fix it?
Permissions are all correctly set
Thanks!

Hello,
next step actually shows the probable root cause of the error. GLIBC_2.34 and GLIBC_2.32 are needed.

Latest version of bullseyw is installed in this raspberry pi , which only supports 2.31.

How did you run unbound-exporter in a raspberrypi?
Thanks!

Issue fixed after upgarding to debian bookworm!

Glad you figured it out. Current supported OS version is mentioned in the readme under Specs:

As a reference you can compile unbound-exporter on non-supportive OS. Compilation is straight forward and the process is explained in the unbound-exporter repo:
https://github.com/ar51an/unbound-exporter


How to apply proxy url with headless chrome enabled

Chrome supports the same command line options when being used with --headless. Simply pass whatever --proxy CLI options are provided. Please see this handy table of available CLI options: https://peter.sh/experiments/chromium-command-line-switches/
Please note you use this in conjunction with either WithRunnerOptions or by invoking your own Chrome headless process and connecting the chromedp.CDP type to it.


Copy crawled documents into ksr-data-manuals

@jmartin-sul  Should we get rid of the repo and close this since we have an alternative now?


Typo fixing in RelationStrings.xml

Fixed a typo in a summary message of ProjectionMappingCountMismatch: inclued -> included

This repo does not accept community PRs for API docs changes since they are auto-generated. API docs should be updated in source code at https://github.com/dotnet/efcore/


Update autoware to 2024.3 version

Issue to be solved:

After launching autoware,  it has to take about two minutes for 'auto' to work.
'Common_ground_filter' node in the perception module seems to be the root cause, as it is not loaded in the first two minutes. 'Common_ground_filter' node -> ... -> '/perception/obstacle_segmentation/pointcloud' topic -> 'behavior_velocity_planner' node in the planning module -> planning function doesn't work well -> can not 'auto'.

Check the difference between centerpoint and centerpoint_tiny

Things that have be done:
Update autoware to 2024.3 version. You can check the details in commit messages.

These days, the period of compiling will fail

Hello @YangXianqi!
In which part you encounter the compiling error?

Hello @YangXianqi! In which part you encounter the compiling error?

Hy @habby1012 !

During compiling the autoware, the commit ids of core/autoware_internal_msgs and core/autoware_adapi_msgs seem to not be valid.

During compiling the bridge, make prepare_bridge will report “configure: error: cannot compute suffix of object files:  compile"

Hello @YangXianqi !

Are you using the "update autoware" branch or other branch?
Did you follow this page to build the environment?

You can provide more information about how you proceeded, so i can try to reproduce and help you find the problem. Thank you!

Hello @YangXianqi !

Are you using the "update autoware" branch or other branch?
Did you follow this page to build the environment?

You can provide more information about how you proceeded, so i can try to reproduce and help you find the problem. Thank you!

Thanks @habby1012 ！

I am using the "update autoware" branch" to compoile the project

During compiling the bridge， when make prepare_bridge is used, the error will occur:

During compiling the autoware, the commid id seems to be invalid:

Hi @YangXianqi !
The log of compiling the Autoware you show seems like the Autoware version is not compatible.
Since i have updated the Autoware version to 2024.6 these days, i am not sure whether this is the cause or not. Maybe you can check this first.

Hi @YangXianqi !
The log of compiling the Autoware you show seems like the Autoware version is not compatible. Since i have updated the Autoware version to 2024.6 these days, i am not sure whether this is the cause or not. Maybe you can check this first.

Thanks @habby1012 ！
I have checked the repo of the projects with mistakes, the corresponding commit id, such as ed9bd6535347214a8139df32f6b321265067690e in autoware_adapi_msgs and autoware_internal_msgs seems to be invalid. On the other hand, have you met the occured error in compiling the bridge?

Hi @YangXianqi !
About the compiling problem of Autoware, are you using the 2024.6 Autoware docker image, or is your image still the older version such as 2024.3?
Regarding the occured error in compiling the bridge, i didn't meet such error.
I think you can try using 'docker images' command and check if you are using the right docker image first. If your docker image is still the old version, you should use 'git pull' to update the autoware_carla_launch repo and try to build it again.
Hope this is useful to you!

Thanke @habby1012 ！
I have rebuilt the image based on ghcr.io/autowarefoundation/autoware:20240603-prebuilt-cuda-amd64.

But when i use the command make prepare_bridge, the error occured again:

In addition, the autoware image i used is 2024.6.

Hi @YangXianqi
Sorry for the late reply. I'm off from the office for about ten days starting from today, but I will still try to help.
Can you show the content of the file /tmp/python-build* showed in the yellow error log for me? You can upload the file, and I will take a look.
I guess it may be something like the permission issue.

Hi @YangXianqi Sorry for the late reply. I'm off from the office for about ten days starting from today, but I will still try to help.
Can you show the content of the file /tmp/python-build* showed in the yellow error log for me? You can upload the file, and I will take a look. I guess it may be something like the permission issue.

Thanks a lot. I found the error is caused by permission. When i update the permission by sudo chmod 777 /var/tmp/ccache, the compilation is  successful. In addition, in order to compile the autoware successfully, the reference id of core/autoware_adapi_msgs in autoware.repos is updated to fe1ba2901fe019c7b023c6f2f17c6af7cb0551a4. But when i launch the autoware, there is the error:

Have u met the error? And can u help me to fix the problem.

Hi @YangXianqi Sorry for the late reply. I'm off from the office for about ten days starting from today, but I will still try to help.
Can you show the content of the file /tmp/python-build* showed in the yellow error log for me? You can upload the file, and I will take a look. I guess it may be something like the permission issue.

Thanks a lot! I have fixed this problem. It is caused by permission problem

Hi @YangXianqi, Sorry for the late reply again!
Have you solved this issue? Did it happen when you try to build autoware?

Close the PR since it's replaced by https://github.com/evshary/autoware_carla_launch/pull/130


crashing on welcome to bullworth

hi!
I downloaded the latest silentpatch, but unfortunately my game crashes at the Welcome to Bullworth title.
I turned on v-sync also but nothing helps.
Thanks in advance.

Try moving your game to your C: Drive if it's not already in there.

Try moving your game to your C: Drive if it's not already in there.

FWIW that never made a difference to me, my game is installed on H: and I tried moving it across different drives to try and replicate this exact issue.

Try moving your game to your C: Drive if it's not already in there.

FWIW that never made a difference to me, my game is installed on H: and I tried moving it across different drives to try and replicate this exact issue. No success.

It's a solution to a couple people, i've helped around 3 people who have had it work for them, and i think 2 who said it didn't work for them, keeping in mind they all have this exact same issue.


Azure Keyvault RBAC and Kubernetes

Hi all,
Apologies if this may have been asked before.  I am looking to setup up an RBAC enabled K8s cluster to read keys from an RBAC enabled Keyvault. I have ensured that I do not Kubenet and use Azure as the network plugin and policy for my cluster.  I have also setup a managed user identity, assigned the appropriate roles and managed to create secrets.
However, my main issue with the Pod identity.  I can't to get the pod identity to be set up correctly and no matter what I try, this seems to keep failing.  I am also using Terraform to build all this.
resource "kubernetes_namespace" "csi_store" {
  metadata {
    name = "csi-secrets-store"
  }
}

resource "random_string" "unique" {
  length  = 6
  special = false
  upper   = false
}

resource "helm_release" "compcomm-csi" {
  name       = "compcommcsi"
  repository = "https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts"
  chart      = "csi-secrets-store-provider-azure"
  namespace  = kubernetes_namespace.csi_store.metadata.0.name

  timeout = 1800
}

data "azurerm_resource_group" "aks_node_rg" {
  name = azurerm_kubernetes_cluster.compcomm-k8s.node_resource_group
}

//# Following roles are required by AAD Pod Identity and must be assigned to the Kubelet Identity
//# https://github.com/Azure/aad-pod-identity/blob/master/docs/readmes/README.msi.md#pre-requisites---role-assignments
resource "azurerm_role_assignment" "vm_contributor" {
  scope                            = data.azurerm_resource_group.aks_node_rg.id
  role_definition_name             = "Virtual Machine Contributor"
  // principal_id         = azurerm_kubernetes_cluster.compcomm-k8s.kubelet_identity.0.object_id
  principal_id                     = data.azurerm_client_config.current.object_id
  skip_service_principal_aad_check = true
}

resource "azurerm_role_assignment" "all_mi_operator" {
  scope                            = data.azurerm_resource_group.aks_node_rg.id
  role_definition_name             = "Managed Identity Operator"
  // principal_id         = azurerm_kubernetes_cluster.compcomm-k8s.kubelet_identity.0.object_id
  principal_id                     = data.azurerm_client_config.current.object_id
  skip_service_principal_aad_check = true
}

resource "azurerm_role_assignment" "mi_operator" {
  scope                            = azurerm_user_assigned_identity.mi.id
  role_definition_name             = "Managed Identity Operator"
  // principal_id         = azurerm_kubernetes_cluster.compcomm-k8s.kubelet_identity.0.object_id
  principal_id                     = data.azurerm_client_config.current.object_id
  skip_service_principal_aad_check = true
}

resource "helm_release" "aad_pod_id" {
  name             = "aad-pod-identity"
  repository       = "https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts"
  chart            = "aad-pod-identity"
  #version          = "2.0.2"
  namespace        = var.aad_pod_id_ns
  create_namespace = true

  values = [
    <<-EOF
    azureIdentities:
    - name: "${azurerm_user_assigned_identity.mi.name}"
      resourceID: "${azurerm_user_assigned_identity.mi.id}"
      clientID: "${azurerm_user_assigned_identity.mi.client_id}"
      binding:
        name: "${azurerm_user_assigned_identity.mi.name}-identity-binding"
        selector: "${var.aad_pod_id_binding_selector}"
    EOF
  ]
}

So my question is, will the above example work when using Azure RBAC or is the only way to stick with manually setting required policies?
Any assisstance would be really helpful.
Thanks
Emmanuel

@grafikkaos Thank you for opening the issue. Could you share the actual yaml files created in the cluster for the AzureIdentity and AzureIdentityBinding? Also, did you check the aad-pod-identity MIC and NMI pod logs for the error?
This is the pod identity troubleshooting guide: https://azure.github.io/aad-pod-identity/docs/troubleshooting/


Fix #4102: Add Semaphore and use it in IOThrottler.

Completing @yilinwei's work from #4308.

Completing @yilinwei's work from #4308.

Updated. I think I have addressed all comments.

Updated. I think I have addressed all comments.


erlang error: {:not_supported, [:ES512]}

Just updated all my libraries and ended up with this error
[error] #PID<0.865.0> running MosaicApi.Endpoint terminated
Server: localhost:4000 (http)
Request: POST /sessions
** (exit) an exception was raised:
    ** (ErlangError) erlang error: {:not_supported, [:ES512]}
        (jose) src/jose_jwk_kty_oct.erl:191: :jose_jwk_kty_oct.jws_alg_to_digest_type/1
        (jose) src/jose_jwk_kty_oct.erl:122: :jose_jwk_kty_oct.sign/3
        (jose) src/jose_jws.erl:311: :jose_jws.sign/4
        (jose) src/jose_jwt.erl:171: :jose_jwt.sign/3
        lib/guardian.ex:303: Guardian.encode_claims/1
        lib/guardian.ex:94: Guardian.encode_from_hooked/1
        lib/guardian/plug.ex:179: Guardian.Plug.api_sign_in/4
        (api) web/controllers/session_controller.ex:57: Api.SessionController.create/2

I quick google search suggested there might be others in a similar situation See also https://github.com/potatosalad/erlang-jose/issues/24

Ok, so I had copied allowed_algos: ["ES512"] into my config at some stage, and it should now be allowed_algos: ["HS512"]


PY_CPPFLAGS = "-IObjects -IInclude -IPython -I. -I/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python/Include -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -arch arm64"
	PY_FORMAT_SIZE_T = ""z""
	PY_LDFLAGS = "-Wl,-headerpad,0x1000"
	PY_LDFLAGS_NODIST = ""
	PY_SSL_DEFAULT_CIPHERS = "1"
	PY_SSL_DEFAULT_CIPHER_STRING = "0"
	PY_STDMODULE_CFLAGS = "-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -arch arm64 -arch x86_64 -Werror=implicit-function-declaration -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration  -I/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python/Include/internal -IObjects -IInclude -IPython -I. -I/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python/Include -iwithsysroot/System/Library/Frameworks/System.framework/PrivateHeaders -iwithsysroot/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/Headers -arch arm64 -fvisibility=hidden -DPy_BUILD_SHARED"
	Py_DEBUG = "0"
	Py_ENABLE_SHARED = "0"
	Py_HASH_ALGORITHM = "0"
	Py_TRACE_REFS = "0"
	QUICKTESTOPTS = "-x test_subprocess test_io test_lib2to3 \"
	READELF = ":"
	RESSRCDIR = "Mac/Resources/framework"
	RETSIGTYPE = "void"
	RUNSHARED = "DYLD_FRAMEWORK_PATH=/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects/host:/AppleInternal/XBS/Bundles/XBS.bundle/Contents/Frameworks DYLD_LIBRARY_PATH=/libressl/ssl/.libs:/libressl/crypto/.libs"
	SCRIPTDIR = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib"
	SDKROOT = "/AppleInternal/BuildRoot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.Internal.sdk"
	SETPGRP_HAVE_ARG = "0"
	SGI_ABI = "@SGI_ABI@"
	SHELL = "/bin/sh"
	SHLIBS = "-ldl -lSystem  -framework CoreFoundation"
	SHLIB_SUFFIX = ".so"
	SHM_NEEDS_LIBRT = "0"
	SIGNED_RIGHT_SHIFT_ZERO_FILLS = "1"
	SITEPATH = ""
	SIZEOF_DOUBLE = "8"
	SIZEOF_FLOAT = "4"
	SIZEOF_FPOS_T = "8"
	SIZEOF_INT = "4"
	SIZEOF_LONG = "8"
	SIZEOF_LONG_DOUBLE = "16"
	SIZEOF_LONG_LONG = "8"
	SIZEOF_OFF_T = "8"
	SIZEOF_PID_T = "4"
	SIZEOF_PTHREAD_KEY_T = "8"
	SIZEOF_PTHREAD_T = "8"
	SIZEOF_SHORT = "2"
	SIZEOF_SIZE_T = "8"
	SIZEOF_TIME_T = "8"
	SIZEOF_UINTPTR_T = "8"
	SIZEOF_VOID_P = "8"
	SIZEOF_WCHAR_T = "4"
	SIZEOF__BOOL = "1"
	SO = ".cpython-38-darwin.so"
	SOABI = "cpython-38-darwin"
	SRCDIRS = "Parser Objects Python Modules Modules/_io Programs"
	SRC_GDB_HOOKS = "/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python/Tools/gdb/libpython.py"
	STDC_HEADERS = "1"
	STRICT_SYSV_CURSES = "/* Don't use ncurses extensions */"
	STRIPFLAG = "-s"
	SUBDIRS = ""
	SUBDIRSTOO = "Include Lib Misc"
	SYSLIBS = ""
	SYS_SELECT_WITH_SYS_TIME = "1"
	TARGET_OS_EMBEDDED = "0"
	TCLTK_INCLUDES = ""
	TCLTK_LIBS = ""
	TESTOPTS = ""
	TESTPATH = ""
	TESTPYTHON = "DYLD_FRAMEWORK_PATH=/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects/host:/AppleInternal/XBS/Bundles/XBS.bundle/Contents/Frameworks DYLD_LIBRARY_PATH=/libressl/ssl/.libs:/libressl/crypto/.libs ./python.exe"
	TESTPYTHONOPTS = ""
	TESTRUNNER = "DYLD_FRAMEWORK_PATH=/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects/host:/AppleInternal/XBS/Bundles/XBS.bundle/Contents/Frameworks DYLD_LIBRARY_PATH=/libressl/ssl/.libs:/libressl/crypto/.libs ./python.exe /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python/Tools/scripts/run_tests.py"
	TESTTIMEOUT = "1200"
	TIMEMODULE_LIB = "0"
	TIME_WITH_SYS_TIME = "1"
	TM_IN_SYS_TIME = "0"
	TRAIN_STYLE = "DT"
	TRAIN_STYLE_DT = "1"
	TVOS_DEPLOYMENT_TARGET = ""
	UNICODE_DEPS = "\"
	UNIVERSALSDK = ""
	UPDATE_FILE = "python3.8 /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python/Tools/scripts/update_file.py"
	USE_COMPUTED_GOTOS = "0"
	VERSION = "3.8"
	VPATH = "/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python"
	WATCHOS_DEPLOYMENT_TARGET = ""
	WINDOW_HAS_FLAGS = "1"
	WITH_DOC_STRINGS = "1"
	WITH_DTRACE = "0"
	WITH_DYLD = "1"
	WITH_LIBINTL = "0"
	WITH_NEXT_FRAMEWORK = "1"
	WITH_PYMALLOC = "1"
	WITH_VALGRIND = "0"
	X87_DOUBLE_ROUNDING = "0"
	XMLLIBSUBDIRS = "xml xml/dom xml/etree xml/parsers xml/sax"
	ZIPSTDLIB = "no"
	abiflags = ""
	abs_builddir = "/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Binaries/python3/install/TempContent/Objects/host"
	abs_srcdir = "/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/python3/python3-73.100.20/Python"
	base = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8"
	datarootdir = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/share"
	exec_prefix = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8"
	installed_base = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8"
	installed_platbase = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8"
	platbase = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8"
	prefix = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8"
	projectbase = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin"
	py_version = "3.8.2"
	py_version_nodot = "38"
	py_version_short = "3.8"
	srcdir = "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/config-3.8-darwin"
	userbase = "/Users/n8henrie/Library/Python/3.8"

Yep, so running with LD_LIBRARY_PATH=/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib will probably resolve issues with your system Python.

it should be present at runtime as well. Right?

Yes, but the error we've been seeing with pyenv is that it can't find the library to link (the wrong LIB_DIR is being detected by pyo3 to add to the linker search paths), and so LD_LIBRARY_PATH helping to load the library at runtime never comes into play.
Looking at your pyenv sysconfig, I think that pyenv should really have LIBDIR set to /Users/n8henrie/.pyenv/versions/3.9.6/Python.framework/Versions/3.9/lib/? It could be worth reporting this upstream with pyenv and see whether they agree it's a bug.
In the meanwhile, you can probably workaround this by using PYO3_PRINT_CONFIG to get the current pyenv configuration, save that to a file, replace the lib_dir to be set to that directory above, and then use PYO3_CONFIG_FILE environment variable to point pyo3 at that custom lib dir.

Yep, so running with LD_LIBRARY_PATH=/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/lib will probably resolve issues with your system Python.

Thanks for all the suggestions. Still getting this with the system python; will need to take a closer look later. Thanks again for your time!
dyld: Library not loaded: @rpath/Python3.framework/Versions/3.8/Python3
  Referenced from: /private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.k5WtRXDrBb/foo/target/debug/deps/foo-1c4d5e927fcdf368
  Reason: image not found

LIBDIR set to /Users/n8henrie/.pyenv/versions/3.9.6/Python.framework/Versions/3.9/lib
In the meanwhile, you can probably workaround this by using PYO3_PRINT_CONFIG to get the current pyenv configuration, save that to a file, replace the lib_dir to be set to that directory above, and then use PYO3_CONFIG_FILE environment variable to point pyo3 at that custom lib dir.

This worked for pyenv. I would not have figured that out.

It could be worth reporting this upstream with pyenv and see whether they agree it's a bug.

I'll see if I can put something coherent together.

Still getting this with the system python; will need to take a closer look later. Thanks again for your time!

Right, sorry, I'm misreading. If I understand https://blog.krzyzanowskim.com/2018/12/05/rpath-what/ correctly, we need to ensure that the RPATH in the final binary contains this framework dir.
Maybe something like this could work, to add the Xcode frameworks dir to the binary?
install_name_tool -add_rpath /Applications/Xcode.app/Contents/Developer/Library/Frameworks /private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.k5WtRXDrBb/foo/target/debug/deps/foo-1c4d5e927fcdf368

This worked for pyenv. I would not have figured that out. Thank you!

🎉

Well, more weird findings.
With both the system python and pyenv, I can run the same e.g. BASE_PYTHON=/path/to/pyenv/python tryagain.sh script from above, and it fails with the same error as above.
However, if I take a line from the end of the error output and cd into the tmpdir it is using, e.g. /private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.RpYiD4RYF0/foo/target/debug/deps/foo-52886a903c6e12a4 -> cd /private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.RpYiD4RYF0/foo and then cargo test --no-default-features from there -- it works.
Which doesn't make sense to me, because I am executing the command from that directory in the script (pushd there). (To be sure, I changed the pushd to cd, and it still fails.)
Homebrew python continues to work without having to manually cd to the tmpdir.
Why would that be?
Even worse, my actual project still fails with the same error I started with, even with running from that directory: note: ld: library not found for -lpython3.9 -- but it works if I clone into a tmpdir, cd there, and then run there. I've tried cargo clean, rm -r .venv, opening a new shell to make sure no ghost envvars are hanging out, even mving the old directory and re-cloning. I'm sure this is something simple I'm overlooking, but I'm pretty bewildered. Why would it fail when run from the tmpdir in the script, succeed when run from the tmpdir interactively, and fail when run from ~/git, where I keep all my projects?
$ cat tryagain.sh
#!/bin/bash

set -Eeuf -o pipefail

cd $(mktemp -d)

git clone --depth=1 https://github.com/n8henrie/knapsack
pushd knapsack

"${BASE_PYTHON}" -m venv .venv
. ./.venv/bin/activate
pip install --upgrade maturin
maturin develop
cargo test --no-default-features
$ BASE_PYTHON=~/.pyenv/versions/3.9.6/bin/python ./tryagain.sh
Cloning into 'knapsack'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 35 (delta 3), reused 33 (delta 3), pack-reused 0
Receiving objects: 100% (35/35), 87.93 KiB | 91.00 KiB/s, done.
Resolving deltas: 100% (3/3), done.
/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack /var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7
Looking in links: /Users/n8henrie/.dotfiles/pip/wheel-cache
Collecting maturin
  Using cached maturin-0.11.2-py3-none-macosx_10_9_x86_64.macosx_11_0_arm64.macosx_10_9_universal2.whl (10.5 MB)
Collecting toml~=0.10.2
  Using cached toml-0.10.2-py2.py3-none-any.whl (16 kB)
Installing collected packages: toml, maturin
Successfully installed maturin-0.11.2 toml-0.10.2
WARNING: You are using pip version 21.1.3; however, version 21.2.4 is available.
You should consider upgrading via the '/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/.venv/bin/python -m pip install --upgrade pip' command.
🔗 Found pyo3 bindings
🐍 Found CPython 3.9 at python
   Compiling proc-macro2 v1.0.28
   Compiling unicode-xid v0.2.2
   Compiling proc-macro-hack v0.5.19
   Compiling syn v1.0.74
   Compiling pyo3-build-config v0.14.2
   Compiling once_cell v1.8.0
   Compiling libc v0.2.99
   Compiling cfg-if v1.0.0
   Compiling smallvec v1.6.1
   Compiling unindent v0.1.7
   Compiling scopeguard v1.1.0
   Compiling instant v0.1.10
   Compiling lock_api v0.4.4
   Compiling parking_lot_core v0.8.3
   Compiling quote v1.0.9
   Compiling parking_lot v0.11.1
   Compiling paste-impl v0.1.18
   Compiling pyo3 v0.14.2
   Compiling paste v0.1.18
   Compiling pyo3-macros-backend v0.14.2
   Compiling indoc-impl v0.3.6
   Compiling indoc v0.3.6
   Compiling pyo3-macros v0.14.2
   Compiling knapsack v0.1.0 (/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack)
    Finished dev [unoptimized + debuginfo] target(s) in 6.63s
   Compiling pyo3-build-config v0.14.2
   Compiling pyo3-macros-backend v0.14.2
   Compiling pyo3 v0.14.2
   Compiling pyo3-macros v0.14.2
   Compiling knapsack v0.1.0 (/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack)
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-arch" "arm64" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.10l8tr4cdb3duggs.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.12u1obghg6fx7x41.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.12zy9jzt3yomn4s6.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.139rbnqpsl8uh5up.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.141vzqvztnhgqatz.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.15jsljqknksnescz.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.17fp2oa431753m10.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.17xoc7ycr2r0nznj.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.194umr8i1ob7x6gp.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.19uus0aynpj0h33k.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1b20achr2urx8642.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1bkna28gfk6wpsfn.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1bl7dg4iur2pe182.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1emrbbkykbadnb3n.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1eua5tzyhep87c7y.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1fh41li7hlr1nxx3.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1hry3n6tfed02rr7.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1q9rcr65w7lxuwn4.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1r41p9vvzeepregh.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1rwj6f2eipqvey8a.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1u70ihjrsmric33v.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1vgwbks186c1rz6x.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1wb88wx9ujawqfhm.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1zdlmrkf8ygpphna.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1zgocbhu8dwn5890.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.1zvuxz5jhyseyrew.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2755j642l10sfbl7.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2aeb0q64wuig12m2.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2c6lfpmtgh2uuk5u.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2ewc4jc1h6emrcbu.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2fop1e60ujju39lh.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2jy9yd0zdulga0qh.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2k9qlazy02yd1qk7.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2kdzluorfrij4816.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2kl35yc31xpmf4dd.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2pdly0z8myv8sxac.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2tevfluvuzwg8zd2.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2tlpj5dk326oxmax.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2xdrtlb1kzxosu4k.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2ywl7yrjf9j2tp93.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.2zsjmfz468nd1gn6.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.33w6n0ezgjhyvj7g.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.341pzzoyjjjxqt86.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.37di7mwn788ehxq2.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.37vb8rhs5utxmdci.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.39nr2hjsfzqtcvhi.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3ccye8iwzfsicjip.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3d4pzoumo01av5ku.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3gsqe4nb40lpzh6i.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3gxv8yby63rzzfz5.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3j9gwa2vegxfvcm7.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3jgm5xr16f1j9jxu.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3kd3nf53q3r13kwb.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3n4wvjpb2h9wrhwi.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3p946nxgcx0iqd83.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3pab1343tw0phur9.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3rs9645bg87j3xf3.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3s1we1oe8ptyuoyc.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3twmkzmnbeinwef2.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3v1r44n4it8k48ms.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3v7t27bho5bby24w.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3z5s1iltckeefdu3.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.3ztvukfmzmcpojbz.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4037ioclmr4bwz57.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.44inf1y1ediwv8hf.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4908lr7mgqhbqjpz.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4aps40jzbzkbshsb.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4c92f52l4egk0t1v.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4cs3a983pjvvzdu9.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4dljzuxm2gbswq5o.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4elv4rz86yeadu0b.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4f9akjzw2fbd89m9.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4frnioyvekloyy2y.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4h43skjltwu5hrg7.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4hnp5i4dv5803vs7.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4insgi0urlkpd7pu.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4l6vvarue55ay8c5.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4mkz4iqofnxxz0rr.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4nid8mbh5hs2if0q.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4oax8bpuktp1f3ze.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4ttrhygknd807i62.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4v13y3415brvw7mp.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4xr7yt4mkohbmon6.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.4zszb8hc98z2pycc.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.51k5ie9g63lhpso2.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.55y51pbgi1r6bjlf.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.57rkylbi71nrkfke.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.5c8c9hqcskwhdoop.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.5cezp99ftar47jiy.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.5f8kclkwhza28pvg.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.7w10wtwa1x9bd8t.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.9oxoopzlikumocy.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.afjjibydkv7rwux.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.bvqxf5ouos48n75.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.bxwqzmzuid0lj9h.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.c0nvl2ryn3w6s0q.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.cwfvrxvsilb2yu6.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.f475gqkoel1lqo0.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.f71004jk3lfabi4.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.fxmxsv5xah2ja8a.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.glk7oue6c0fd0.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.hwrdb55fmk3u4hx.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.ibdng3oafdtv07.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.kcqkntrjd43ma1o.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.lc88rycbterghrg.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.nthx98tigmfdu2.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.qmx20e10d6kspun.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.rjdyl2k8ycvphhi.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.ruq7k3tpj5gbg9h.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.vofbqzl2yjmmy4z.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.w3tn8cmmc54uvkt.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.xsl4a6cnk5lcpg9.rcgu.o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d.27h887fkaazor3d4.rcgu.o" "-L" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps" "-L" "/Users/n8henrie/.pyenv/versions/3.9.6/lib" "-L" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libtest-06ff11d645105e2b.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libterm-f05ecaeca66814e6.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgetopts-6ad0d034fc8e15c7.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunicode_width-c4beacdc35405cb8.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_std-fc0f4647def297a8.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libpyo3-44857f8da2fa9343.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libparking_lot-3d6f176468cb3e55.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libparking_lot_core-1a66328f5320fcf8.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libsmallvec-b1d3333bf059e064.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/liblock_api-09ae7dbe1cd82c80.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libscopeguard-62e7a6d9289eec1f.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libinstant-4e05ab198a32da16.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libcfg_if-254a4227ea494762.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/liblibc-2d65d84e2d4e9c71.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libunindent-dda6001dcdbb754c.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libpaste-61320a4b949429d0.rlib" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/libindoc-758ee8d2665c486a.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd-000cdec9267bfd7b.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libpanic_unwind-2669f3cbce8358f4.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libobject-86461a1c60728ccb.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libaddr2line-f17574752cb5ddba.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libgimli-3bb606c936cc0d28.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libstd_detect-8139a4b0cda20184.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_demangle-ea0823eca3e9abf9.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-4f19e1259f6028e7.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_alloc-435daca85b8e10b5.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libunwind-d73085abefd284c6.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcfg_if-e6a09ca0044b34e5.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liblibc-e07333f48f53c71e.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/liballoc-2a49b0d9fbc7a459.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/librustc_std_workspace_core-b66dda66aafe36c9.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcore-34d0b58da984bf31.rlib" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libcompiler_builtins-01275baa20724171.rlib" "-lpython3.9" "-liconv" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" "-L" "/Users/n8henrie/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d" "-Wl,-dead_strip" "-nodefaultlibs"
  = note: ld: library not found for -lpython3.9
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

error: could not compile `knapsack`

To learn more, run the command again with --verbose.
$ cd /private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack
$ cargo test --no-default-features
   Compiling pyo3-build-config v0.14.2
   Compiling pyo3-macros-backend v0.14.2
   Compiling pyo3 v0.14.2
   Compiling pyo3-macros v0.14.2
   Compiling knapsack v0.1.0 (/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.CtEqZ4H3V7/knapsack)
    Finished test [unoptimized + debuginfo] target(s) in 3.80s
     Running unittests (target/debug/deps/knapsack-e3891c9eeee3976d)

running 3 tests
test tests::test_parse ... ok
test tests::test_display_solution ... ok
test tests::test_solve ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

This sounds like it's definitely an environment issue. Are you using direnv or something similar which automatically loads python environments as you switch directories by any chance?

However, if I take a line from the end of the error output and cd into the tmpdir it is using,

It doesn't look like you're selecting a python interpreter when you do this, so the subsequent cargo test probably ends up recompiling with homebrew python, which we know works well.

my actual project still fails with the same error I started with, even with running from that directory

Which python is that with? Presumably we now expect it to work with homebrew python and require manual environment overrides if you use system / pyenv.

It doesn't look like you're selecting a python interpreter when you do this

Doh! That was it. Sourcing the venv after cd and it fails as expected. It wasn't obvious to me (though should have been from your patient replies in this thread) that running cargo test --no-default-features would be pulling in runtime information from my python venv -- I figured that all happened during a python command like maturin develop.
I'd really prefer to use pyenv for development, since it pins the python version (i.e. when 3.10 comes out soon and homebrew updates it might hose any of my venvs that are based on homebrew python). For the time being, exporting the PyO3 config, manually editing the config file to fix the LIBDIR issue, then running the below to automatically export PYO3_CONFIG_FILE upon venv activation seems workable.
$ echo "export PYO3_CONFIG_FILE=\"$PWD/pyenv-config.txt\"" >> ./.venv/bin/activate

Maybe something like this could work, to add the Xcode frameworks dir to the binary?

Using /usr/bin/python3 for venv, install_name_tool does the trick:
$ source ./.venv/bin/activate
$ readlink -f $(which python3)
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3.8
$ cargo test --no-default-features
    Finished test [unoptimized + debuginfo] target(s) in 0.07s
     Running unittests (target/debug/deps/knapsack-e3891c9eeee3976d)
dyld: Library not loaded: @rpath/Python3.framework/Versions/3.8/Python3
  Referenced from: /private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.w2HVR48SEE/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d
  Reason: image not found
error: test failed, to rerun pass '--lib'

Caused by:
  process didn't exit successfully: `/private/var/folders/kb/tw_lp_xd2_bbv0hqk4m0bvt80000gn/T/tmp.w2HVR48SEE/knapsack/target/debug/deps/knapsack-e3891c9eeee3976d` (signal: 6, SIGABRT: process abort signal)
$ install_name_tool -add_rpath /Applications/Xcode.app/Contents/Developer/Library/Frameworks ./target/debug/deps/knapsack-e3891c9eeee3976d
$ cargo test --no-default-features
    Finished test [unoptimized + debuginfo] target(s) in 0.08s
     Running unittests (target/debug/deps/knapsack-e3891c9eeee3976d)

running 3 tests
test tests::test_display_solution ... ok
test tests::test_parse ... ok
test tests::test_solve ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

🎉!

😅 does this mean we now solved all the cases? 🚀

I'm not sure I'd consider the system python case fully resolved -- yes, it seems like the pyenv case is an upstream issue.
For the MacOS system python3, the general process above was a little clunky:

Copy a dynamic library path to python3, surprisingly buried somewhere in Xcode
search for a dynamically named binary towards the end of a bunch of error output
running a somewhat obscure tool to change the @rpath
profit

I'm still doing some reading and found a few posts like this, I wonder if I can add some linker args to Cargo.toml to make this process smoother for other MacOS users (with a planned documentation PR).  Or perhaps some build.rs magic. Or perhaps another option to help this be a little smoother before I'd consider the issue solved.
I am profoundly grateful for your time on this issue so far!

Somehow I missed this section in the docs: https://pyo3.rs/v0.14.4/building_and_distribution.html#macos
It doesn't seem like pyo3_build_config::add_extension_module_link_args() makes any difference for /usr/bin/python3 in my case, which makes sense since it says that maturin should be doing this for me.

Good new: with some help from the pyenv team, I found a different way of approaching the framework install that seems to have things working without any extra steps (build.rs, linker flags, etc.).
The short of it is that CONFIGURE_OPTS, which is what I was using, is working differently than PYTHON_CONFIGURE_OPTS (https://github.com/pyenv/pyenv/issues/2081). With PYTHON_CONFIGURE_OPTS, the --enable-framework build flag is working and seems to be properly setting prefix, so while LIBDIR is unchanged, rust is finding everything as expected.
https://github.com/pyenv/pyenv/issues/2038#issuecomment-931728391
So I think only the system MacOS installation remains an issue, and it certainly seems buggy based on the above.

I hit the problem with m1 Mac when trying to publish a crate original built fine on intel-based machines.
I was able to resolve the issue by adding --no-default-features flag.

this helped me:
https://pyo3.rs/v0.14.2/building_and_distribution.html#macos

This issue is present on android termux as well as macos.

@xloem if you're able to share a repro in a separate issue we might be able to understand why the lib name is missing and perhaps avoid the need for you to have a custom config eventually.


Scala3: Improve exclusion rules and DRY pprint dependency

Problem
The quill-util misses some classes which makes it unusable standalone with Scala 3 without providing the missing dependencies.
Solution
Manually add the Scala 3 version of the excluded libraries.
Also adds the pprint dependency only where used so it's not added to all modules
@getquill/maintainers

@guizmaii This PR is a follow-up to #2834 to clean up the dependencies of pprint and scalafmt-core, especially when used from Scala 3.

Thanks for your work @lolgab! ❤


Remove link to book.

Coverage remained the same at 93.124% when pulling ccbbea048ef31779eef7defb10746da9297eba8f on remove-book into 6bde29095c1537d06a243f352ff3997d59515dfa on master.


Add Missing Methods for Integrations

Some endpoints of the following section can't be hit from this SDK.
We would like to ensure that all endpoints can be hit. For this issue, we would like to build out the Integrations
Some of these methods may already exist.
If so no need to change/update them, just point out that they already exist and we will close the issue.

This is just to bring every SDK we have on par with all the methods available.
Check all the endpoints here and add the missing ones.

@Cliftonz I would like to work on this please assign me

@king-11 assigning this to you now.


Typocorrection in slides

Corrected the typo "kenenlernen".

Could you please open a new pull request where you request to merge onto master directly from your patch branch buepas-patch-1 (https://github.com/buepas/software-engineering/tree/buepas-patch-1)?
That way we avoid an unneeded merge commit (29b81d659c30134d8b8abc0295544da3fbc306df) in the repository.


Allow config for config_split module?

Can we include a generic template for enabling config_split module?
https://github.com/wodby/drupal-php/blob/master/7/templates/drupal8.settings.php.tpl
This could allow for configuring config split options without too much pain.
$wodby['config_split_env'] = '{{ getenv "ENV" "" }}';
...
...

if (!empty($wodby['config_split_env'])) {
  $config['config_split.config_split.' . $wodby['config_split_env']]['status'] = TRUE;
}

I don't see this module as very popular or de-facto standard to include it in the template (I can be mistaken). This settings file designed to be included in the original settings.php where you can add anything you want after the include.

HI @csandanov
Thanks for your thoughts, I ended up implementing my own init step in a custom bash file like so:
#!/usr/bin/env bash

set -e
settings_php="/var/www/html/web/sites/default/settings.php"
disclaimer="\n// MY Specific Settings."
environment='$config["drupal_env"] = "'${ENVIRONMENT}'"; \n'

if [[ $( grep -ic "my.settings.php" "${settings_php}" ) -eq 0 ]]; then
    chmod 644 "${settings_php}"
    echo -e "${disclaimer}" >> "${settings_php}"
    echo -e "${environment}" >> "${settings_php}"

    echo -e 'if (file_exists($app_root . "/" . $site_path . "/my.settings.php")) {
      include $app_root . "/" . $site_path . "/my.settings.php";
    }' >> "${settings_php}"

fi

and then in my my.settings.php, I can do:
if ($config['drupal_env']) {
  $config['config_split.config_split.' . $config['drupal_env']]['status'] = TRUE;
}
else {
  $config['config_split.config_split.local']['status'] = TRUE;
}


Initial suggestions for plugin release

Hey @kaggrwal, thanks for creating this exciting new plugin.
The basic structure and results look good so far. While using the plugin, we did come up with a few suggestions based on our best practices:

The name of the repository should be steampipe-plugin-bitfinex.
README.md suggestions:

It is missing the links to the hub documentation and the slack community. For instance, the README section usually begins in the following manner:

# PagerDuty Plugin for Steampipe

Use SQL to query infrastructure services, teams, escalation policies and more from your PagerDuty account.

- **[Get started →](https://hub.steampipe.io/plugins/turbot/pagerduty)**
- Documentation: [Table definitions & examples](https://hub.steampipe.io/plugins/turbot/pagerduty/tables)
- Community: [Slack Channel](https://steampipe.io/community/join)
- Get involved: [Issues](https://github.com/turbot/steampipe-plugin-pagerduty/issues)

steampipe plugin install bitfinex should be replaced by steampipe plugin install kaggrwal/bitfinex.
Could you please add the missing Contributing section?

For the above points, you could refer https://raw.githubusercontent.com/turbot/steampipe-plugin-pagerduty/main/README.md for additional information.

docs/index.md suggestions:

organization should be kaggrwal.
display_name should be Bitfinex instead of BITFINEX. Is there any specific reason why BITFINEX has been used?
name placeholder should be updated to short_name.
All references to BITFINEX should be replaced with Bitfinex.
The example query used in the README and the docs/index.md files should be the same. I personally prefer the one used in the docs/index.md file.
The install section needs to be updated in the following manner:

Now
  steampipe plugin install bitfinex

Suggested
  steampipe plugin install kaggrwal/bitfinex

The configuration section should be updated as follows:

  connection "bitfinex" {
  plugin = "kaggrwal/bitfinex"
}

For the above points, you could refer https://raw.githubusercontent.com/francois2metz/steampipe-plugin-gandi/main/docs/index.md for help

The config/bitfinex.spc file should use plugin = "kaggrwal/bitfinex" instead of plugin = "bitfinex".

The description section, of the table column data, is missing the period . at its end.

The table docs look a bit light and need not include result sets and implementation notes. When the plugin is released to the hub the inspect data would automatically show up, for instance, https://hub.steampipe.io/plugins/francois2metz/gandi/tables/gandi_domain#inspect.

Could we add 2-3 more examples for the table docs?
Overall the plugin looks great. The changes that need to be made are very minor. Please let us know in case you have any questions.
Looking forward to releasing the plugin to the hub 👍 .

Thanks @kaggrwal for making the changes per the above suggestions 👍 .
I feel the following few points still need some attention:

The table columns are still missing a period . at the end of the description. (https://github.com/kaggrwal/steampipe-plugin-bitfinex/blob/main/bitfinex/table_bitfinex_currency.go#L26)
We usually don't include query outputs in the table docs, they can be safely removed (For instance https://raw.githubusercontent.com/kaggrwal/steampipe-plugin-bitfinex/main/docs/tables/bitfinex_currency.md)
Could you please make updates to the README file as suggested above?

I think we are really close to releasing the plugin, once the review comments are addressed, we can push for a release 👍 .
Thank you for your contribution once again 😄 .

Apologies for the delay @kaggrwal and thanks for making the changes so quickly 👍 .
One last suggestion before we push for release would be to update the icon_url  and og_image  place holder of the docs/index.md file to use "/images/plugins/kaggrwal/bitfinex.svg" and "/images/plugins/kaggrwal/bitfinex-social-graphic.png" respectively.
I have also raised a request for creating social graphics for this plugin. Thanks for the contribution 👍 .


push ra

Tested Version
v0.0
Description
Push is not recognized.
Steps
Compile and run assembler.exe.
Create a file named example.asm containing: push ra.
cmdline: assembler.exe example.asm example.bin.
Context
This test was done on 02/23/24 before the project deadline.
Actual Result (optional screenshot)
//
Security Criteria
3
Discovery/Resolve Date
02/23/24
Expected Result
It assembles without any errors.
Possible Solution
//
Other
//

This was handled on a previous commit before the merge and the pull request of dev to main.


Find References for declared types

Adds the 'Find All References' feature for declared type.
I think the new service can most likely be simplified but I looked way too many times at it and can't see where to improve it anymore...
Grammar
grammar test hidden(WS)

entry Model: value=RuleA;

interface A {
    name: string
}

interface B extends A {
    assignmentB: string
}

type C = A | B;

RuleA returns A: name=ID;

RuleB returns B: name=ID assignmentB=ID;

RuleC returns C: name=ID assignmentB=ID;

ActionRule: {A} 'A' name=ID | {B} name=ID assignmentB=ID | {C} name=ID assignmentB=ID;

terminal ID: /\\w+/;
terminal WS: /\\s+/;

Behavior

Calling 'Find All References' from interface property should find all references in parser rules returning the type or one of its children types
Calling 'Find All References' from an assignment in a parser rule returning a declared interface should find the property in return type (or one of its super types) and all assignments
Calling 'Find All References' from an assignment in a parser rule returning a union type should find the property in atom type (or one of its super types) and all assignments
Calling 'Find All References' from an assignment in an Action should find the property in the Action type (or super type) and all assignments

Side effects

It is now possible to rename a property in an interface and propagate the renaming to all references in assignments. Do not work with renaming from assignment in parser rules (not implemented).

Other

ParserHelper method in langium-test.tsnow adds parsed document to LangiumDocuments service
New method CleanUpTestDocuments in langium-test.ts to remove documents from the workspace during tests.
Refactored test in domainmodel example to comply with new ParserHelper method.

I added a different grammar for each example, this way I hope it is easier to follow what each individual test is addressing


[proxy-uid] [MAISTRA-551] Run sidecars with dynamically-determined user IDs (#230)

Squashed commit, incorporates changes from:

MAISTRA-551 Run sidecar with a dynamically-determined runAsUser ID

MAISTRA-611 Partial injection of just the annotation and runAsUser id

MAISTRA-668 Fix expected output of webhook injection

The sidecar injector now sets the securityContext.runAsUser field
regardless if it is specified in the sidecar template or not. This is
to allow the sidecar template to not include the field, which is
required to ensure that istioctl kube-inject outputs manifests that
pass the SCC admission controller (if the runAsUser is specified, the
SCC controller will reject the pod, as the uid won't be in the proper
range). The sidecar injector then injects the correct runAsUser id even
if it isn't specified in the template.

MAISTRA-1751: Set securityContext.fsGroup to comply with restricted SCC (#256)

This is a rewrite of 46f0f4a819 for the Maistra 2.1 / Istio 1.8 rebase.

MAISTRA-2452 Apply dynamically-determined user ID to the istio-validation init container

Co-authored-by: Marko Lukša<EMAIL_ADDRESS>Co-authored-by: Brad Ison<EMAIL_ADDRESS>

/test all


[Bug]: Escape characters for full text search syntax

Is there an existing issue for the same bug?

[X] I have checked the existing issues.

Version or Commit ID
d7d042b62a076b03e3f262ae43227f1c8da57a49
Other environment information
No response
Actual behavior and How to reproduce it
Given query
电影《厕所:一个爱的故事》改编自什么故事？

厕所 is interpreted as column name due to the colon in the query, which should be escaped.
Similar builtin characters should also be escaped for robust full text search.
Expected behavior
No response
Additional information
No response

You can add {"operator": "or"} in fulltext query option, for example:
https://github.com/infiniflow/infinity/blob/000fcb77d34878019a97a97a47159293fe3e012c/python/test_pysdk/test_knn.py#L707


feature #3403 : Added --s2i flag for 'odo create' command

What type of PR is this?
/kind feature
What does does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #3403
How to test changes / Special notes to the reviewer:
Use the --s2i flag when using odo create to force S2i component over a namesake devfile component type.

@dev-gaur I tried it working well, in two cases i have faced problem

Interactive mode doing odo create --s2i listing devfile components
(edge case) If a devfile.yaml is present in current directory and i still wants to create odo create nodejs --s2i then it is taking devfile giving error  ✗  Cannot select this component with --s2i flag.

we use fixes to link the corresponding github issue, no need to mention it in PR heading feature #3403 : Added --s2i flag for 'odo create' command, it could be simply  Added --s2i flag for 'odo create' command

@dev-gaur I tried it working well, in two cases i have faced problem

Interactive mode doing odo create --s2i listing devfile components

Explained in above comments.

(edge case) If a devfile.yaml is present in current directory and i still wants to create odo create nodejs --s2i then it is taking devfile giving error  ✗  Cannot select this component with --s2i flag.

Was that a nodejs component? If yes, then the behaviour is expected. Else, I'll make the changes.

we use fixes to link the corresponding github issue, no need to mention it in PR heading  feature #3403 : Added --s2i flag for 'odo create' command, it could be simply Add --s2i flag for 'odo create' command

Noted. Its an old habit from the jkube team :sweat_smile:

@dev-gaur I think we can disable --s2i flag for interactive mode, @kadel @girishramnani WDYT?

will take a look at this in the evening

@dev-gaur I think we can disable --s2i flag for interactive mode, @kadel @girishramnani WDYT?

I mean cant we ask the user if you want to use legacy component type or something?

@dev-gaur I think we can disable --s2i flag for interactive mode, @kadel @girishramnani WDYT?

I don't see how this would be hard to implement. For interactive mode, it'd just check to see if --s2i has been passed in? We could do it so that interactive mode is either Devfile with odo create or s2i with odo create --s2i

@dev-gaur I think we can disable --s2i flag for interactive mode, @kadel @girishramnani WDYT?

I don't see how this would be hard to implement. For interactive mode, it'd just check to see if --s2i has been passed in? We could do it so that interactive mode is either Devfile with odo create or s2i with odo create --s2i

ofcourse its not hard to implement. I just wanted to discuss if this should be done. And if yes, should --s2i be disabled in the favour of interactive mode or should interactive mode be disabled in favour of --s2i flag.
And now I got my answer from the above comments, the former option.

@cdrage sorry i have not explained myself clearly. It is not about skipping interactive mode for s2i, it is about interactive mode support with the flag odo create --s2i, as it looks confusing. There could be two ways of doing that:

odo create --s2i would be the interactive mode for s2i,
cons: with interactive mode we don't specify a single flag, so this is against odo consistency.

odo create in interactive mode should we ask s2i or devfile?
cons: we do not want to give first hand support for s2i components.
In this case we could print deprecation warning if user selects s2i.

IMO approach 2 is better,

odo create --s2i would be the interactive mode for s2i,
cons: with interactive mode we don't specify a single flag, so this is against odo consistency.

Can't we make an exception for experimental mode here? The mode is called "experimental" for a reason :wink:
This approach feels neat to me, IMO

can we just ignore the --s2i flag on interactive mode and then have a follow up?

can we just ignore the --s2i flag on interactive mode and then have a follow up?

I'm not sure what do you mean by 'follow up' here.
If you mean we let the user select the devfile component type in the interactive mode and if --s2i flag is enabled, then check for conflicting names and act in favour of s2i type , then this is the current approach I adopted.

odo create --s2i would be the interactive mode for s2i,
cons: with interactive mode we don't specify a single flag, so this is against odo consistency.

+1

@cdrage sorry i have not explained myself clearly. It is not about skipping interactive mode for s2i, it is about interactive mode support with the flag odo create --s2i, as it looks confusing. There could be two ways of doing that:

agreed on this +1

/approve

odo create --s2i would be the interactive mode for s2i,
cons: with interactive mode we don't specify a single flag, so this is against odo consistency.

+1

triple agree on this.
Having it inside of odo create to pick between Devfile / S2I seems like it'd only be in odo temporarily since we're encouraging the use of Devfile.

/retest

@devang working well now, good to go from my side with address @cdrage comments addressed, and update the flag description.
Two things i have observed that could be taken care of in a followup PR, I am able to specify token and starter flags that are devfile specific, so you can print error message from them also as you did with registry flag.
odo create nodejs --s2i --token kdlkad
odo create nodejs --s2i --starter myproject

changes made.

/retest

/retest

/retest

New changes are detected. LGTM label has been removed.

adding lgtm back after rebase
/lgtm

/retest

Changes lgtm
/lgtm

/retest

/retest

/retest

some real failures
[Fail] odo devfile create command tests When executing odo create with component type argument and --s2i flag [It] should fail the create command as --now flag, which is specific to s2i component creation, is used without --s2i flag
/home/travis/gopath/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:214
[Fail] odo devfile create command tests When executing odo create with devfile component type argument and --registry flag [It] should fail to create the devfile component if specified registry is invalid
/home/travis/gopath/src/github.com/openshift/odo/tests/helper/helper_generic.go:67
[Fail] odo devfile create command tests When executing odo create with component type argument and --s2i flag [It] should fail the create command as --git flag, which is specific to s2i component creation, is used without --s2i flag
/home/travis/gopath/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:201
[Fail] odo devfile create command tests When executing odo create with component type argument and --s2i flag [It] should fail the create command as --binary flag, which is specific to s2i component creation, is used without --s2i flag
/home/travis/gopath/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:208

holding it until tests are not resolved, @dev-gaur remove /hold once you fix the tests.
/hold

Looks like a flake.
So going to
/retest

/hold cancel

some real failures
[Fail] odo devfile create command tests When executing odo create with component type argument and --s2i flag [It] should fail the create command as --now flag, which is specific to s2i component creation, is used without --s2i flag
/home/travis/gopath/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:214
[Fail] odo devfile create command tests When executing odo create with devfile component type argument and --registry flag [It] should fail to create the devfile component if specified registry is invalid
/home/travis/gopath/src/github.com/openshift/odo/tests/helper/helper_generic.go:67
[Fail] odo devfile create command tests When executing odo create with component type argument and --s2i flag [It] should fail the create command as --git flag, which is specific to s2i component creation, is used without --s2i flag
/home/travis/gopath/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:201
[Fail] odo devfile create command tests When executing odo create with component type argument and --s2i flag [It] should fail the create command as --binary flag, which is specific to s2i component creation, is used without --s2i flag
/home/travis/gopath/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:208

holding it until tests are not resolved, @dev-gaur remove /hold once you fix the tests.
/hold

I ran the "odo devfile create command tests" suite and it is passing locally :confused:

@dev-gaur There is a extra string coming in CI, not matching with your expected output
• Failure [3.130 seconds]
odo devfile create command tests
/go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:16
  When executing odo create with component type argument and --s2i flag
  /go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:133
    should fail the create command as --git flag, which is specific to s2i component creation, is used without --s2i flag [It]
    /go/src/github.com/openshift/odo/tests/integration/devfile/cmd_devfile_create_test.go:199
    Expected

        <string>: I0803 10:42:03.604022    9039 preference.go:196] The path for preference file is /tmp/384490129/config.yaml
         ✗  flag --git, requires --s2i flag to be set true, when in experimental mode.

    to contain substring
        <string>: flag --git, requires --s2i flag to be set, when in experimental mode.

Not sure If my changes were leading to this failure.
Nevertheless I have modified this test case in https://github.com/openshift/odo/pull/3545/commits/4a9691e20ccb9fe358ef1596074eb7aa1f33b1d1

Tests pass on OpenShift CI
/lgtm
:+1:

@dev-gaur why does this PR show the old clusters?

@prietyc123 please report this to the ci platform team


No Vagrant file provided in the test folder

There is no vagrant file in the test folder.
Please add file as referenced in the readme

Sorry somehow it was in the .gitignore file, has been added at https://github.com/jborean93/ansible-role-win_openssh/blob/master/tests/Vagrantfile.

thank you!


x/tools/gopls: test cleanup errors during shutdown with ERROR_SHARING_VIOLATION on Windows

Following the recent change to await proper shutdown of the regtest environment (CL 416594), we get one new flake on windows:
--- FAIL: TestRegenerateCgo (7.42s)
    --- FAIL: TestRegenerateCgo/experimental (4.02s)
        runner.go:322: closing the sandbox: error(s) cleaning sandbox: cleaning modcache: <nil>; removing files: remove C:\Users\gopher\AppData\Local\Temp\gopls-regtest-2462642078\TestRegenerateCgo\experimental\work: The process cannot access the file because it is being used by another process.

https://build.golang.org/log/27834526d9f9152f3bc200e902c97d8a73d55452
https://build.golang.org/log/b4e52dbee66f77feae2f7fa17e2981087e7fbbcb
If we've learned anything from investigating these flakes, it is that they are often (if not usually) actual races in gopls. Unfortunately the goroutine dump at test failure point does not show anything interesting. It is possible that problematic goroutines had exited before the dump.

Note that Windows in particular seems to produce this error spuriously (compare #51442), or at least for reasons we haven't yet been able to diagnose (see also #25965).
In the testing package in the standard library, we're currently working around it with a retry loop:
https://cs.opensource.google/go/go/+/master:src/testing/testing.go;l=1115-1143;drc=de9805c702bcc19bcf3c783d1c2e43fdf4e1d30e
Would it be possible for gopls to use the testing package to create and clean up its sandbox directories? If not, you might consider copying the testing retry loop into the gopls test harness.

Thank you @bcmills! I was about to ping you to ask, because I seemed to recall the exact context you have just produced :)
I'll copy the removeAll logic.

Note that these failures still persist after CL 417117. 🤔

My investigation into the persistent errors suggested that the new problem is simply that the server did not have enough time to shut down: not that there is a bug in shutdown itself, or that the retry logic doesn't work.
This seems to have been fixed by https://go.dev/cl/417583.

Note: this seems to have gone away so I will close this issue with a CL to improve/remove the shutdown timeout, as suggested by @bcmills in a follow-up comment on https://go.dev/cl/417583.


bos telegram systemd service broken in v1.10.0 - rm working dir

Thank you for your contribution to RaspiBlitz. Before submitting this PR, please make sure:

[x] That its based against the dev branch - not the default release branch.

bos telegram systemd service broken in v1.10.0 - rm working dir fixes issue.
dir balanceofsatoshis no longer exists.

Thank you for catching this, merging with the correction.


updated javascript to pull movie plot descrption and critic rating scores

code looks good and clean!

Great work on getting the movie poster to load.


[Kubectl] Update installation docs for Ubuntu Jammy

TL & DR
The changes here impacts the documents in english version.
I just updated the part of the documentation instructs the installation for Linux Ubuntu via apt add repository method, where actually is to Xenial Ubuntu release: 3. Add the Kubernetes apt repository.
I've include a new 3.1 passing the instructions for Ubuntu Jammy 22.04 LTS.
And how I found this solution?
Simple I just browse through the Packages Cloud Google. until /apt/dists/ubuntu-jammy-mirror/main.
Results
APT Update

Kubernetes List file
$ cat /etc/apt/sources.list.d/kubernetes.list
deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ ubuntu-jammy-mirror main

/hold
This is suggesting an install from (Google's mirror of) Ubuntu. That's not what readers who use Debian would expect.

Please see the email thread - https://groups.google.com/a/kubernetes.io/g/dev/c/gR5xDzzIcW8/m/SK5ARWkGAQAJ
Also see workaroung in the thread or here - https://github.com/kubernetes/k8s.io/pull/4837#issuecomment-1446426585


Question: Class definition for HttpConcurrentServer

Hello James,
you have exported the methods for the class HttpConcurrentServer (/src/HttpConcurrentServer.gs), but i can't find any Class definition in the /src/WebGs.gs file or any hints in the *.sh files.
Did i overlook somethink, is it a default class in GemStone64Bit3.6.6?
Regards
Peter

That sounds like I removed the class from the image and when it filed out it wasn't in WebGS.file but the method file remained (Jade files out a dictionary but doesn't delete from the directory). I'll investigate further...

The file was added on 13-Jul-2021 but the class was not added to WebGS.gs, so was never used (it appears to be an attempt at concurrency that was ultimately implemented with LoadBalancer.gs). I've removed the file.

Thanx for your fast responds.


Add au-label to fix labels with descenders obscured on:focus

Add au-label to fix labels with descenders obscured on:focus
fixing #556

nice work @KiriHoy !
We probably need to do the same for our select boxes as well:

looks good @KiriHoy merge!


Update Italian Translation

Wow. You are alive and on time! Hope tomorrow I'll release 5.3.1, the final release in this god damned year.

Correct?
È stata saltata la creazione di un collegamento simbolico

I have some work commitments, as soon as I can I give my contribution.
Congratulations on the work you are doing, I wish you a Merry Christmas


🎁 IOTSTOOL2039 - Foundation support for filters

Codecov Report

Merging #261 into beta will decrease coverage by 6.88%.
The diff coverage is 24.33%.

@@            Coverage Diff            @@
##             beta    #261      +/-   ##
=========================================
- Coverage   51.59%   44.7%   -6.89%
=========================================
  Files         154     166      +12
  Lines        6208    6361     +153
  Branches     1010    1027      +17
=========================================
- Hits         3203    2844     -359
- Misses       2647    3208     +561
+ Partials      358     309      -49

Impacted Files
Coverage Δ

src/Legacy/Bootstrap/Api/BootstrapApi.cs
65.06% <ø> (ø)
:arrow_up:

src/Legacy/Certificates/Api/CertificatesApi.cs
72.97% <ø> (ø)
:arrow_up:

src/Legacy/Update/Api/UpdateApi.Campaign.cs
35.35% <ø> (ø)
:arrow_up:

.../Legacy/Connect/Api/ConnectApi.ConnectedDevices.cs
43.4% <ø> (+2.19%)
:arrow_up:

src/Legacy/Billing/Api/BillingApi.cs
75% <ø> (ø)
:arrow_up:

...cy/DeviceDirectory/Api/DeviceDirectoryApi.Query.cs
56.66% <ø> (ø)
:arrow_up:

.../DeviceDirectory/Api/DeviceDirectoryApi.Logging.cs
0% <ø> (ø)
:arrow_up:

.../DeviceDirectory/Api/DeviceDirectoryApi.Devices.cs
56.45% <ø> (ø)
:arrow_up:

...AccountManagement/Api/AccountManagementApi.User.cs
58.33% <ø> (ø)
:arrow_up:

src/Legacy/Update/Api/UpdateApi.FirmwareImage.cs
54.71% <ø> (ø)
:arrow_up:

... and 71 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 05ed439...d3c7a56. Read the comment docs.


Turn off Paredit and Aggressive Indentation on merge conflicts

To productively resolve merge conflicts in Lisps, one simply must turn off both Paredit and Aggressive Indentation. It would be nice if this were done automatically. (It would be even better if they were turned back on after you were finished.) Regardless of whether Magit is added as per #4, it would be nice to have this behavior when using git from the command line.

This could be hooked into smerge-mode, for example.

Aggressive Indent was removed in https://github.com/raxod502/radian/commit/e008f4df06ffae839eaeb35d45eae8d6e6f2abfe. You can just turn off Smartparens manually, I think.


sysutils/node_exporter: Allow setting IPv6 address as Listen Address

Hi all,
I noticed that the Node Exporter Plugin does currently not allow an IPv6 address to be set as a Listen Address, even though that is well supported by Node Exporter itself and is something I need for my setup.
I made the necessary changes to accommodate both address types, plus a little improvement on the port field.
Changes I did:

Change address from TextField to NetworkField and remove old validation regex
Change port from IntegerField to PortField
Add if to template to check for an IPv6 address and surround it with square brackets, as that's what is required by the Node Exporter config. IPv4 addresses are used directly as before.

I have tested these changes on my OPNsense and they seem to work fine.
Node Exporter picks up the changes and runs as expected.

Anything else I need to do to get this merged? I'd really like to use this change on multiple machines, and currently modifying them manually is not that nice.

Not the maintainer, but looks ok to me. Thanks!


Add base class for camera settings providers

This change adds a base class to handle the required properties and methods defined in the IMixedRealityCameraSettingsProvider interface.
The experimental UnityAR provider has been updated (with some other small changes) to use the base class.

/azp run

/azp run


Iris having trouble with very similar latitude coordinates

I was helping @mattiarighi to debug the derivation of lwcre, in particular an exception that was fired  in this line
 lwcre = rlutcs_cube - rlut_cube

ValueError: This operation cannot be performed as there are differing coordinates (latitude) remaining which cannot be ignored.
This is because there are very small differences in the latitude coordinate between both cubes, in the order of 10^-6. Iris is too strict there. Is there a way to tell Iris an acceptable difference for this, @bjlittle?
If we can not solve this at iris level, we need to decide what to do here. Maybe we can detect the error, checkthe differences and if, they are small, (below 10^-3) assign the values from rlut to rlutcs. What do you think?

The problem affects the CCSM4. I can provide the data for testing.

@jvegasbsc I've stepped through the Iris code from cube subtraction down to the point of Coord.__eq__, which leans on iris.util.arrray_equal to determine the equality of coordinate values.
This is essentially using NumPy equality, so it's not Iris that is being too strict - we are merely providing the same numeric array equality that NumPy defines.
So it's your data that's the problem, otherwise you're really looking for a different operation that says "subtract these cubes, even if the metadata defining the cubes are kinda the same". Can't see how we could easily implement that within Iris and allow the user to control the tolerance (absolute or relative) of accuracy and restrict that tolerance to coordinate values.
Is there a practical workaround here?
Is the data for the coordinates on each cube coming from a different data source? Hence the difference in accuracy? ... would it be sensible to apply a pre-processing step that equalises the number of significant digits of the coordinates across the cubes?

Indeed this is an error in the coordinate of this particular model, which uses very slightly different latitude arrays for different variables (rlut and rlucs in our example, but there are other cases).
Ideally, this should be fixed via model-specific fix-file, but it's not so straightforward since we apply this check on a per-variable basis and there is no clear "correct latitude" to use as a reference for fixing the error.
Another option would be to arbitrarily choose one of the two latitude coordinates this model uses and set it as the correct one, hard-coding it in the fix-file, but it's quite inelegant... :grin:
Better ideas?

I think these kind of differences are more likely to be due to the nature of float variables than to any other reason.

Another option would be to arbitrarily choose one of the two latitude coordinates this model uses and set it as the correct one, hard-coding it in the fix-file, but it's quite inelegant...

For this fixes we can use the fix_metadata step, which is almost not costly in computing time. We can check other variables and use the most common one

This is essentially using NumPy equality, so it's not Iris that is being too strict - we are merely providing the same numeric array equality that NumPy defines.

Numpy also provides the numpy.allclose() for equality with tolerance. Anyway, it will probably be to costly in computing power to be useful within Iris as a general comparison

For this fixes we can use the fix_metadata step, which is almost not costly in computing time. We can check other variables and use the most common one

Where should we implement this fix?
Only in _derive.py for lwcre or at a more general level?
I've tested swcre and it goes through without problems, toz also combines different variables without problems, so it seems to be quite specific to lwcre.

Sound good!

Feel free to use my branch REFACTORING_lwcre for that.

The data type of the coordinates is always double and this is checked by the CMORcheck module.
The problem arises due to slightly different latitude coordinates in the CCSM4 model between two variables (rlutcs and rlut) which are subtracted to calculate a derived variable (lwcre).
The two coordinates look like this:
-90  -90
-89.05759429931641  -89.0575916230366
-88.11518096923828  -88.1151832460733
-87.17277526855469  -87.1727748691099
-86.23036956787109  -86.2303664921466
-85.28795623779297  -85.2879581151832
-84.34555053710938  -84.3455497382199

I don't know if this problem occurs also for other models/variables.
In any case, this is not critical as long as we deal with only 1 variable (most common case), but only when 2 variables are combined.
Hope this helps.

What is the status here? Is the bugfix implemented?
It would be good to close this before the workshop.

I would like to report another issue I encountered with this kind of variable derivation (using cubes):
lwcre = rlutcs_cube - rlut_cube
The new cube "lwcre" does not contain any of the attributes from the source cubes (rlutcs_cube, rlut_cube). The backend will correctly write the results (lwcre) to a netcdf file (preproc), but the corresponding model is missing in the <variable>_info.ncl file and thus not visible to ncl diagnostics.

@axel-lauer Could you please open a separate issue for this? I do not think this is related to this issue.

Just opened a new issue for that: #371

@mattiarighi @jvegasbsc I reckon a standard solution if we perform cube subtractions/sums/... would be to regrid one on another (if there is no regridding done at all), that way we ensure consistency between spatial coordinates

Regridding looks a bit overkill for this case, I would still prefer the fix in the coordinate.
It is a cleaner solution since it does not modify the original variable data, but only the coordinates. This can be a relevant issue, in particular if the user explicitly sets regridding: none in the namelist.

@mattiarighi regrid: none and different MxN grid dimensions will result in complete failure of intercube operations; regrid: none with identical MxN grid dimensions will still be potentially problematic if the grid centers are not identical -- something that may cause (lat, lon) points to differ order dgrees and not only 1e-6 degrees, hence my suggestion to regrid to a common grid, for sanity, when doing any intercube operation

True, but this would also slightly change that variable data, even when this is just a numerical error in the coordinates (as the case I mentioned above).
Maybe the results will be similar in the end, but conceptually I believe that the coordinate should be fixed without changing the variable data.

OK, agreed, it's a case of balancing an error introduced by interpolation vs an error introduced by tweaking a grid point and keeping fixed the variable value attached to that grid point -- can we set a threshold e.g. if the delta((lat1, lon1) - (lat2, lon2)) is smaller than say double precision then we tweak the grid or not, we regrid?

If the coordinate system of two variable from the same model/exp/mip/ensemble differ, it is always an error, independently of the delta.
A specific fix for each case is the right solution, in my opinion, also because such cases are not very common I think.