Sigh command taking 40 minutes on: 'Verifying certificates...' step

New Issue Checklist

[ x ] Updated fastlane to the latest version
[  x ] I read the Contribution Guidelines
[ x ] I read docs.fastlane.tools
[ x ] I searched for existing GitHub issues

Issue Description

Our Jenkins CI build times have increased drastically lately from around 8 minutes to 45 minutes. The problem is that the additional 37 minutes are spent in the 'Verifying certificates...' step of sigh.
I've been able to replicate it on the Mac build machine by only running the following 'certificates' lane:
  desc 'Fetch certificates and provisioning profiles'
  lane :certificates do
    api_key = app_store_connect_api_key(
      key_id: "XXXXXXXXXX",
      issuer_id: "XXXXXXXX",
      key_filepath: ENV["APP_STORE_CONNECT_API_KEY_PATH"],
      duration: 1200, # optional (maximum 1200)
      in_house: false, # optional but may be required if using match/sigh
    )
    cert(api_key: api_key)
    sigh(api_key: api_key)
  end

Output:
fastlane % fastlane ios certificates --verbose

[✔] 🚀
[14:27:29]: fastlane detected a Gemfile in the current directory
[14:27:29]: However, it seems like you didn't use `bundle exec`
[14:27:29]: To launch fastlane faster, please use
[14:27:29]:
[14:27:29]: $ bundle exec fastlane ios certificates --verbose
[14:27:29]:
[14:27:29]: Get started using a Gemfile for fastlane https://docs.fastlane.tools/getting-started/ios/setup/#use-a-gemfile
DEBUG [2023-10-10 14:27:30.09]: Checking if there are any plugins that should be loaded...
Successfully loaded Appfile at path '/Users/Jenkins/Home/workspace/app-react-native-2/fastlane/Appfile'
- package_name: 'REDACTED'
- app_identifier: 'REDACTED'
- apple_id: 'REDACTED'
- team_id: 'REDACTED'
-------
INFO [2023-10-10 14:27:30.25]: ----------------------------------------
INFO [2023-10-10 14:27:30.25]: --- Step: Verifying fastlane version ---
INFO [2023-10-10 14:27:30.25]: ----------------------------------------
INFO [2023-10-10 14:27:30.25]: Your fastlane version 2.216.0 matches the minimum requirement of 2.176.0  ✅
INFO [2023-10-10 14:27:30.25]: Driving the lane 'ios certificates' 🚀
INFO [2023-10-10 14:27:30.25]: ---------------------------------------
INFO [2023-10-10 14:27:30.25]: --- Step: app_store_connect_api_key ---
INFO [2023-10-10 14:27:30.25]: ---------------------------------------
INFO [2023-10-10 14:27:30.25]: ------------------
INFO [2023-10-10 14:27:30.25]: --- Step: cert ---
INFO [2023-10-10 14:27:30.25]: ------------------

+------------------------------------------------------------------------------+
|                           Summary for cert 2.216.0                           |
+-------------------------+----------------------------------------------------+
| api_key                 | ********                                           |
| development             | false                                              |
| force                   | false                                              |
| generate_apple_certs    | true                                               |
| api_key_path            | /Users/Jenkins/app_store_connect_api_key.p8        |
| username                | REDACTED                                 |
| team_id                 | REDACTED                                        |
| keychain_path           | /Users/Jenkins/Library/Keychains/login.keychain-db |
| skip_set_partition_list | false                                              |
| platform                | ios                                                |
+-------------------------+----------------------------------------------------+

INFO [2023-10-10 14:27:30.26]: Creating authorization token for App Store Connect API
INFO [2023-10-10 14:27:34.01]: $ security default-keychain -d user
INFO [2023-10-10 14:27:34.02]: ▸     "/Users/Jenkins/Library/Keychains/login.keychain-db"
INFO [2023-10-10 14:27:34.02]: $ security find-certificate -a -c 'Apple Worldwide Developer Relations' -p /Users/Jenkins/Library/Keychains/login.keychain-db
INFO [2023-10-10 14:27:34.04]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.04]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.04]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.04]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.04]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.04]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.04]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.04]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.04]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.04]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.04]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.04]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.18]: Found the certificate REDACTED (REDACTED COMPANY NAME) which is installed on the local machine. Using this one.
INFO [2023-10-10 14:27:34.18]: $ security default-keychain -d user
INFO [2023-10-10 14:27:34.19]: ▸     "/Users/Jenkins/Library/Keychains/login.keychain-db"
INFO [2023-10-10 14:27:34.19]: $ security find-certificate -a -c 'Apple Worldwide Developer Relations' -p /Users/Jenkins/Library/Keychains/login.keychain-db
INFO [2023-10-10 14:27:34.20]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.20]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.20]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.20]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.20]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.20]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.20]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.20]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.20]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.20]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.20]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:34.20]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:34.35]: Verifying the certificate is properly installed locally...
INFO [2023-10-10 14:27:34.35]: Successfully installed certificate REDACTED
INFO [2023-10-10 14:27:34.35]: Use signing certificate 'REDACTED' from now on!
INFO [2023-10-10 14:27:34.35]: ------------------
INFO [2023-10-10 14:27:34.35]: --- Step: sigh ---
INFO [2023-10-10 14:27:34.35]: ------------------

+-----------------------------------------------------------------------------------+
|                             Summary for sigh 2.216.0                              |
+-------------------------------------+---------------------------------------------+
| api_key                             | ********                                    |
| adhoc                               | false                                       |
| developer_id                        | false                                       |
| development                         | false                                       |
| skip_install                        | false                                       |
| force                               | false                                       |
| include_mac_in_profiles             | false                                       |
| app_identifier                      | REDACTED                      |
| api_key_path                        | /Users/Jenkins/app_store_connect_api_key.p8 |
| username                            | REDACTED                          |
| team_id                             | REDACTED                                  |
| ignore_profiles_with_different_name | false                                       |
| cert_id                             | REDACTED                                |
| skip_fetch_profiles                 | false                                       |
| include_all_certificates            | false                                       |
| skip_certificate_verification       | false                                       |
| platform                            | ios                                         |
| readonly                            | false                                       |
| fail_on_name_taken                  | false                                       |
+-------------------------------------+---------------------------------------------+

INFO [2023-10-10 14:27:34.35]: Creating authorization token for App Store Connect API
INFO [2023-10-10 14:27:34.35]: Fetching profiles...
INFO [2023-10-10 14:27:35.06]: Verifying certificates...
INFO [2023-10-10 14:27:35.06]: $ security default-keychain -d user
INFO [2023-10-10 14:27:35.07]: ▸     "/Users/Jenkins/Library/Keychains/login.keychain-db"
INFO [2023-10-10 14:27:35.07]: $ security find-certificate -a -c 'Apple Worldwide Developer Relations' -p /Users/Jenkins/Library/Keychains/login.keychain-db
INFO [2023-10-10 14:27:35.08]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:35.09]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:35.09]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:35.09]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:35.09]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:35.09]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:35.09]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:35.09]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:35.09]: ▸ -----BEGIN CERTIFICATE-----
---REDACTED---
INFO [2023-10-10 14:27:35.09]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 14:27:35.09]: ▸ -----BEGIN CERTIFICATE-----
--- REDACTED ---
INFO [2023-10-10 14:27:35.09]: ▸ -----END CERTIFICATE-----
INFO [2023-10-10 15:12:22.17]: Found 1 matching profile(s)
WARN [2023-10-10 15:12:22.17]: Downloading provisioning profile...
INFO [2023-10-10 15:12:22.17]: Successfully downloaded provisioning profile...
INFO [2023-10-10 15:12:22.21]: Installing provisioning profile...
/Users/Jenkins/Home/workspace/app-react-native-2/REDACTED.mobileprovision
INFO [2023-10-10 15:12:22.25]: Setting Provisioning Profile type to 'app-store'
INFO [2023-10-10 15:12:22.25]: Successfully generated documentation at path '/Users/Jenkins/Home/workspace/app-react-native-2/fastlane/README.md'

+-------------------------------------------------+
|                fastlane summary                 |
+------+----------------------------+-------------+
| Step | Action                     | Time (in s) |
+------+----------------------------+-------------+
| 1    | Verifying fastlane version | 0           |
| 2    | app_store_connect_api_key  | 0           |
| 3    | cert                       | 4           |
| 4    | sigh                       | 2687        |
+------+----------------------------+-------------+

INFO [2023-10-10 15:12:22.26]: fastlane.tools just saved you 45 minutes! 🎉

Command executed

fastlane ios certificates
Environment

swift-driver version: 1.75.2 ✅ fastlane environment ✅
Stack

Key
Value

OS
13.4.1

Ruby
3.1.4

Bundler?
false

Git
git version 2.41.0

Installation Source
/opt/homebrew/Cellar/fastlane/2.216.0/libexec/bin/fastlane

Host
macOS 13.4.1 ((c))

Ruby Lib Dir
<EMAIL_ADDRESS>

OpenSSL Version
OpenSSL 3.1.0 14 Mar 2023

Is contained
false

Is homebrew
true

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
14.3.1

Swift Version
5.8.1

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE

fastlane files:
`./Fastfile`
# Customise this file, documentation can be found here:
# https://github.com/fastlane/fastlane/tree/master/fastlane/docs
# All available actions: https://docs.fastlane.tools/actions
# can also be listed using the `fastlane actions` command

# Change the syntax highlighting to Ruby
# All lines starting with a # are ignored when running `fastlane`

# If you want to automatically update fastlane if a new version is available:
# update_fastlane

# This is the minimum version number required.
# Update this, if you use features of a newer version
fastlane_version "2.176.0"

platform :ios do

  desc 'Fetch certificates and provisioning profiles'
  lane :certificates do
    api_key = app_store_connect_api_key(
      key_id: "REDACTED",
      issuer_id: "REDACTED",
      key_filepath: ENV["APP_STORE_CONNECT_API_KEY_PATH"],
      duration: 1200, # optional (maximum 1200)
      in_house: false, # optional but may be required if using match/sigh
    )
    cert(api_key: api_key)
    sigh(api_key: api_key)
  end

# More information about multiple platforms in fastlane: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Platforms.md
# All available actions: https://docs.fastlane.tools/actions

# fastlane reports which actions are used
# No personal data is recorded. Learn more at https://github.com/fastlane/enhancer

`./Appfile`
package_name("REDACTED") # Android package name
app_identifier "REDACTED" # The bundle identifier of your app
apple_id "REDACTED" # Your Apple email address

team_id "REDACTED"  # Developer Portal Team ID

# you can even provide different app identifiers, Apple IDs and team names per lane:
# More information: https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Appfile.md

fastlane gems

Gem
Version
Update-Status

fastlane
2.216.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

error_highlight
0.3.0

did_you_mean
1.6.1

public_suffix
5.0.3

addressable
2.8.5

artifactory
3.0.15

jmespath
1.6.2

aws-partitions
1.824.0

aws-eventstream
1.2.0

aws-sigv4
1.6.0

aws-sdk-core
3.181.1

aws-sdk-kms
1.71.0

aws-sdk-s3
1.134.0

babosa
1.0.4

bundler
2.4.10

rexml
3.2.6

CFPropertyList
3.0.6

colored
1.2

highline
2.0.3

commander
4.6.0

dotenv
2.8.1

emoji_regex
3.2.3

excon
0.103.0

faraday-em_http
1.0.0

faraday-em_synchrony
1.0.0

faraday-excon
1.1.0

faraday-httpclient
1.0.1

multipart-post
2.3.0

faraday-multipart
1.0.4

faraday-net_http
1.0.1

faraday-net_http_persistent
1.2.0

faraday-patron
1.0.0

faraday-rack
1.0.0

faraday-retry
1.0.3

ruby2_keywords
0.0.5

faraday
1.10.3

faraday_middleware
1.2.0

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

http-cookie
1.0.5

faraday-cookie_jar
0.0.7

fastimage
2.2.7

gh_inspector
1.1.3

uber
0.1.0

declarative
0.0.20

trailblazer-option
0.1.2

representable
3.2.0

retriable
3.1.2

mini_mime
1.1.5

jwt
2.7.1

multi_json
1.15.0

os
1.1.4

signet
0.18.0

googleauth
1.8.0

httpclient
2.8.3

webrick
1.8.1

google-apis-core
0.11.1

google-apis-androidpublisher_v3
0.49.0

google-apis-playcustomapp_v1
0.13.0

google-cloud-env
1.6.0

google-cloud-errors
1.3.1

google-cloud-core
1.6.0

google-apis-iamcredentials_v1
0.17.0

google-apis-storage_v1
0.19.0

rake
13.0.6

digest-crc
0.6.5

google-cloud-storage
1.44.0

json
2.6.1

mini_magick
4.12.0

naturally
2.2.1

optparse
0.1.1

plist
3.7.0

rubyzip
2.3.2

security
0.1.3

simctl
1.6.10

terminal-notifier
2.0.0

unicode-display_width
2.4.2

terminal-table
3.0.2

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

word_wrap
1.0.0

atomos
0.1.3

claide
1.1.0

colored2
3.1.2

nanaimo
0.3.0

xcodeproj
1.22.0

rouge
2.0.7

xcpretty
0.3.0

xcpretty-travis-formatter
1.0.1

set
1.0.2

forwardable
1.3.2

logger
1.5.0

pathname
0.2.0

shellwords
0.1.0

cgi
0.3.6

date
3.2.2

timeout
0.2.0

stringio
3.0.1

securerandom
0.2.0

uri
0.12.1

openssl
3.0.1

digest
3.1.0

io-nonblock
0.1.0

ipaddr
1.2.4

io-wait
0.2.1

zlib
2.1.1

resolv
0.2.1

time
0.2.2

open-uri
0.2.0

mutex_m
0.1.1

net-http
0.3.0

net-protocol
0.1.2

ostruct
0.5.2

english
0.7.1

erb
2.2.3

strscan
3.0.1

abbrev
0.1.0

io-console
0.5.11

tempfile
0.1.2

delegate
0.2.0

fileutils
1.6.0

tmpdir
0.1.2

base64
0.1.1

singleton
0.1.1

open3
0.1.1

nkf
0.1.1

prettyprint
0.1.1

pp
0.3.0

find
0.1.1

yaml
0.2.0

psych
4.0.4

generated on: 2023-10-10

We noticed that the time keeps increasing every build. No idea what is causing it though... This is a 2022 M2 Pro Mac Mini and it's spending 50 minutes searching for a certificate to build for 3 minutes :cry:

Wonder if it's related to: https://github.com/fastlane/fastlane/issues/9040

An observation I made is that if I cancel the lane manually, I get the following error:
ERROR [2023-10-24 12:09:33.76]: fastlane finished with errors /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane_core/lib/fastlane_core/cert_checker.rb:93:in ``': Interrupt 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane_core/lib/fastlane_core/cert_checker.rb:93:in list_available_identities'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane_core/lib/fastlane_core/cert_checker.rb:57:in installed_identies' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane_core/lib/fastlane_core/cert_checker.rb:42:in installed?'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:146:in block (2 levels) in fetch_profiles' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:140:in each'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:140:in block in fetch_profiles' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:122:in each'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:122:in find_all' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:122:in fetch_profiles'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/runner.rb:38:in run' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/sigh/lib/sigh/manager.rb:8:in start'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/actions/get_provisioning_profile.rb:24:in run' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:263:in block (2 levels) in execute_action'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/actions/actions_helper.rb:69:in execute_action' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:255:in block in execute_action'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:229:in chdir' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:229:in execute_action'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:157:in trigger_action_by_name' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/fast_file.rb:159:in method_missing'
from Fastfile:28:in block (2 levels) in parsing_binding' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/lane.rb:33:in call'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:49:in block in execute' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:45:in chdir'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/runner.rb:45:in execute' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/lane_manager.rb:47:in cruise_lane'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/command_line_handler.rb:36:in handle' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/commands_generator.rb:110:in block (2 levels) in run'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/commander-4.6.0/lib/commander/command.rb:187:in call' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/commander-4.6.0/lib/commander/command.rb:157:in run'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/commander-4.6.0/lib/commander/runner.rb:444:in run_active_command' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:124:in run!'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/commander-4.6.0/lib/commander/delegates.rb:18:in run!' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/commands_generator.rb:354:in run'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/commands_generator.rb:43:in start' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/fastlane/lib/fastlane/cli_tools_distributor.rb:123:in take_off'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/gems/fastlane-2.216.0/bin/fastlane:23:in <top (required)>' 	from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/bin/fastlane:25:in load'
from /opt/homebrew/Cellar/fastlane/2.216.0/libexec/bin/fastlane:25:in `'

We are experiencing exactly the same. I think it's related to the OS. Our CI machine has Ventura yet and sigh takes an incredibly long time, while on my Mac which has Sonoma, sigh command is fast.
Interesting and frustrating at the same time.

I might try upgrading the OS of our CI machine then @gavrillas . It's been driving me nuts!

@ItsNoHax Did upgrading the OS solve the problem?

Negative @gavrillas. That's a real bummer.

@ItsNoHax We managed to figure out that the keychain became corrupted and the following command stucked: security find-identity -p codesigning.
Firstly we'd reseted the keychain, but it didn't solve the issue. We had to completely delete the keychain. After deleting the keychain both security find-identity -p codesigning and fastlane match passed pretty fast.

@gavrillas Thanks for the headsup, I will be giving it a try in the next upcoming days.

@gavrillas , how did you delete the keychain then? I manually went to the Library/keychains/ folder and deleted the login keychain. Recreated it and filled it with our development/distribution certs but it's still taking super long :/

I think I fixed it @gavrillas !! Had to make sure all the files related to the login keychain were deleted, log in with the same user and then finally the command was nearly instant. Thanks a lot for your tip!!

@gavrillas Sorry to bother you again but it seems the issue is coming back again... Did the same happen to you? I really can't be asked nuking the login keychain every 6 months.


Fix for shared library build

Trying to build a shared library in Debian 10 results in the following CMake error:
install TARGETS given no LIBRARY DESTINATION for shared library target
   "E57Format"

This pull request solves this issue.

Thanks José!


Read MIGP config from server by default

Add a new endpoint on the MIGP server for the client to retrieve the
MIGP configuration parameters.
Print a warning if the client's MIGP library version does not match the
server version.

does the version number is the only one that must match, or the other fields on the configuration too?

does the version number is the only one that must match, or the other fields on the configuration too?

Checking only the version number should be sufficient to see if the MIGP library is compatible with the config, but we also do need the client MIGP parameters to match the ones the server uses to encrypt the database or the decryption will fail (which is why we're not retrieving the config from the server).


imp(workflows): use larger runners on time consuming jobs

Motivation
Some jobs take too much time to run, having to wait too much time between commits to confirm everything is working as expected, and making merge queues slower
Fixes: #7180
Closes: #6457
Fixes: #7625
Specifications
https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners
Solution

Add different larger runners to handle these time consuming jobs

Review

Confirm the time has been reduced to acceptable limits

Reviewer Checklist

[ ] Will the PR name make sense to users?

[ ] Does it need extra CHANGELOG info? (new features, breaking changes, large changes)

[ ] Are the PR labels correct?
[ ] Does the code do what the ticket and PR says?

[ ] Does it change concurrent code, unsafe code, or consensus rules?

[ ] How do you know it works? Does it have tests?

Follow Up Work
None

Just copying these post-merge steps from ticket #7180:

[ ] Re-enable the coverage job: ZcashFoundation/zebra/actions/workflows/coverage.yml
[ ] Re-enable the coverage patch job: ZcashFoundation/zebra/actions/workflows/coverage.patch.yml
[ ] Admin: re-enable the coverage job main branch protection rule


Add maintenance state for customer action needed

Which issue this PR addresses:

Fixes https://issues.redhat.com/browse/ARO-4365
What this PR does / why we need it:

If a maintenance operation fails, we may need the customer to take action. We will notify the customer via a resource health check signal.
This PR implements a new signal to tell the customer to take action. This PR implements arrows 11 and 12 in this diagram.
Test plan for issue:

Unit tests
Test in INT

Is there any documentation that needs to be updated for this PR?

See above diagram link

Code Review December 13th:

Verify if we need code to reject transition from customer action needed to maintenance ongoing. This prevents us from accidentally from running maintenance on a cluster that has failed + needs customer action

Reviewed with @bennerv and @SudoBrendan.  We'll not support blocking transition from "customer action needed" to "maintenance ongoing." No code changes needed - code as is supports this.

/azp run ci


[skip ci] Enable user to change the account used for ssh connection

By default cephadm uses root account to connect remotely
to other nodes in the cluster. This change allows to choose
another account.
Signed-off-by: Teoman ONAY<EMAIL_ADDRESS>

Another weird behavior I found happens during the enrolling [1]: looks like the labels are not properly assigned and this is probably related to the gathered facts.
We can investigate this part on a follow-up PR
[1] https://paste.opendev.org/show/812578/
[2] https://github.com/ceph/ceph-ansible/blob/master/infrastructure-playbooks/cephadm-adopt.yml#L309-L330

jenkins test centos-container-cephadm_adopt

jenkins test centos-container-cephadm_adopt


Unable to get search using the wrapper.

Description
Hello,
Using below statement i am fetching the instance of hottable:
let hotInstance = new HotRegisterer().getInstance("hotInstance");
Now in hotInstance i should get property as search and inside that there is a function query(string) which is useful to have search over the grid.
But i cannot find the search property.
Whereas if i do the same during on going/debugging mode i can able to get the desired result.
Below is the code which is workable in debugging mode:
hotInstance.search.query("k")
The error which i am getting is:
users.component.ts (170,23): Property 'search' does not exist on type 'Handsontable'.
Your environment

Wrapper version: 0.34.4
Browser Name and version: Google Chrome v62.0.3202.94
Operating System: Windows 10

Hello,
I'm using the angular wrapper, I tried to follow the example in the link and I find these errors:

NullInjectorError: No provider for HotTableRegisterer!

Can not bind to 'search' since it is not a known property of 'hot-table'.

Thank you.


Error when trying to execute andCall()

I have an error when trying to execute andCall("123456789")
The following error - Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference.
Any idea how to deal with that ?

Hi. I think you need to pass second arg
andCall(number,getSimInfo().simSlotIndex0);

Thanks for respond. I already create my own native Android Dialer 👍


[PLT-865] Quantile calculation methods.

From a discrete sample of a distribution, there several ways to estimate a quantile. Different scenario based VaR methods may use different estimator. In particular, CCPs in their IM methodologies are using different approaches.
This PR created a quantile calculation method hierarchy.
4 estimator versions have been implemented:

discrete: nearest and index above
interpolation: midway and sample points

The methods take as an input the sample as an array. If relevant, the input object could be changed to a time series or a list.
This PR should be ported to Analytics 3.0 after reviewed and merged.

To be replaced by several new PR soon.

GitHub manipulation error. PR still open.


[Experiment] Evaluate the effectiveness of using more fine-grained search tools

What is the problem that this fixes or functionality that this introduces? Does it fix any open issues?
This PR is for running evaluation with ACR's tools integrated, to evaluate the effectiveness of using more search tools. If it proves to be helpful, we can discuss about a full reimplementation.
Currently, I have changed the AST parsing from ast to tree-sitter, to reuse it from the linter and to add more languages in the future.

Give a summary of what the PR does, explaining any non-trivial design decisions

Other references

Cc: @neubig, @xingyaoww, if you folks can help me with the eval! Because we can't merge this PR as the code is licensed, and I think the current code already works for the eval, I'm a bit lazy to merge main and deal with new config changes 😅 If you find it's necessary, let me know and I can do it.

I think the conflict is not hard to resolve - i can help you resolve it if needed? I can look into it later today

That's great, thank you!

FYI: I've start running the evaluation!

Close the PR for now, as adding tools naively doesn't seem to help, especially when LLMs are becoming better! Thanks @xingyaoww and @neubig for helping me with this!


Update README.md

Seems this is a mistake. Should be database name instead of schema.
Working fine on my project 👍

Good catch, thank you for contibution.


Publish: support Unlisted and Scheduled types

Status
:heavy_check_mark: Code complete to start QA, code-review.
☐  Look into URL shortener
Review
Test:  kp test instance
Code:   see commit messages for walkthrough of each change
Submit new QA issue: https://github.com/OdyseeTeam/frontend-qa/issues/new
Board view: https://github.com/orgs/OdyseeTeam/projects/9/views/1

Log issues: https://github.com/orgs/OdyseeTeam/projects/9/views/1

I got into an autoplay loop after playing my own local unlisted publish.
Perhaps in the claim preview context menu of unlisted content owner, the copy link should maybe link to the shareable version?

I got into an autoplay loop after playing my own local unlisted publish.

Is that playing your next own unlisted from the rec, and going back and forth, A-and-B?
If that's the case, the Lighthouse filtering of unlisted items is coming soon, so it won't appear in recommendations.
If that doesn't come, then we'll we'll filter by c:unlisted.  Trying to avoid replicating backend work.
I think applyReleaseTimeUpperLimit can be removed too if the backend is going to do it.

Perhaps in the claim preview context menu of unlisted content owner, the copy link should maybe link to the shareable version?

Ah, missed it.  Thanks.

My published unlisted does not show up on my channel page. Maybe that's ok since I can find it in uploads?

Part of it is in pop out player, it was trying to play markdown files in rapid succession. Could be an unrelated autoplay issue.


Add CurSearch highlight group

They recently merged https://github.com/neovim/neovim/pull/18081 which adds this group for the next release 0.8. I think it should probably not cause problems for people using earlier versions since there are highlights for random plugins people may not have.
I'm not a designer at all, so feel free to pick different colors, but I think these work well.

Thank you!


A.05.IR14.ds.keyword.md

This issue has been extracted from the issue list on:https://ies-svn.jrc.ec.europa.eu/issues/2685
Comment
The purpose is not formulated correctly:
'Purpose: Keyword for datasets. If the resource is a dataset or a dataset series, at least one keyword must originate from the INSPIRE theme of the GEMET Thesaurus'
Proposed Change
Change to:
'Purpose: If the resource is a dataset or a dataset series, it checks that at least one keyword originating from the INSPIRE theme of the GEMET Thesaurus is provided'

Proposed Resolution
Agreed with proposed change


Estimated deaths and death rate for U.S. population

Provide a worst scenario case for estimated number of deaths and death rate by gender & age based on current China's latest death rate applied to the U.S. population gender & age mix.
Coronavirus_ US Population Death by age & gender.xlsx
This does not take into consideration of existing medical conditions as there are no statistics being published regarding increase death rates.
The take-away is that majority of deaths (if US is affected in the same way as China) then people aged 60+ will have the highest death rate which we already know but this helps quantify it a little better.

@acflippo thank you for sharing that with us, somewhat sobering to look at those projections.
@jaryaman @pr3d4t0r inside the excel @acflippo has provided sources and a view into how that graph is put together. what do you guys think about getting something like this on the website?

@kinabalu @acflippo Yep, looks good to me. I will self-assign and add it to my stack.
Shall we integrate into COVIDvu-predict.ipynb for starters, to get a feel for how to visualize? We could simply make the plot in the spreadsheet for a selection of countries in plotly.
And yes, those are grim statistics.

Looking at it now/today.  Thank you!  I'll give it a higher priority.

Yes, the maximum death numbers are sobering so I suggest publishing the mortality rate by gender & age.  That will show how deadly the virus is.

Hmm, looking at this in more detail. The graphical model for variables death (d), age (a), and sex (s) is
s -> d <- a
which means, amongst the deceased, age is not independent of sex due to the explain away effect (see here for example).
So you need p(a,g|d) to evaluate p(d|a,g) with Bayes rule. p(a,g|d) is not equal to p(a|d)p(g|d).
I don't see p(a,g|d) in the primary source only p(a|d) and p(g|d).


Gmdx 162 - MessagingClinet.kt async api should throw more general Exception.

Use MessagingClient.fetchHistory() and MessagingClient.deploymentConfig() will throw Exception::class instead of long list of specific Exceptions.

Usually I run lintKotlin before pushing. This time forgot about that. :(


add InformationStateString to repeated_games

Add InformationStateString method to repeated games and add test
change the names of kDefaultEnableInformationStateTensor flag and enable_info_state_tensor to also control provides_information_state_string in addition to provides_information_state_tensor. Not sure if this is what we want?(not entirely clear on the purpose of the parameter)
fix typo in docstring: num_repititions -> num_repetitions

Nice, thanks!

no problem! Let me know if you want any changes to the behavior of the parameter.

It's fine behavior for that parameter but the info state string must contain the actions taken by all players (I'll fix it during the import).


Getting Marker Key from onPress Event

I am trying to get the key of a map marker when it is pressed. I have tried the onMarkerPress prop from the MapView and the onPress prop in the 'Marker' class. In both cases, the native event is passed into the callback function. However, the native event returned has all null fields which does not give me any indication as to what marker was pressed.
In short, my objective is to determine which marker is pressed when the event is fired.
My questions are:

Should I be using the onMarkerPress prop found in the MapView or the onPress prop in the Marker?
How do I get the ID of the marker?

Right now there is no clear key or id coming back from events. https://github.com/lelandrichardson/react-native-maps/pull/195 has example of how to make an implementation for sending back id, feel free to make a PR for sending back identifier in all events from markers.
Otherwise a workaround solution could be to create a local method per marker onPress={(event) => event.id = "marker1"; this.handleMarkerPress(event)} ( something like that )

It's not a really nice solution but in the event object inside nativeEvent you have the coordinate object, that contains the coordinates of your point, so you can use it to find again your object in your array.
The @jrichardlai solution looks better, but if you want you can do it like above :)

Thanks for the help guys. I ended up using @magrinj solution because it suited my situation better.

Hi, onPress is working, please try  <MapView.Maker onPress={() => {this.setState({selectedMarker: markerId})}}

You can now just use the identifier attribute on the marker element:
<MapView.Maker identifier={"1"} onPress={(event) => this.handleMarkerPress(event)}  />
And in your handleMarkerPress function you'll get the identifier:
handleMarkerPress(event) {
  const markerID = event.nativeEvent.identifier
  console.log(markerID)
}

Thanks @lww !

Would like to edit the answer by @lww . It should be
event.nativeEvent.id
This will give id=1 which can then be used as a key to get the selected marker

The event.nativeEvent object does not contain an id key in my case.. Perhaps it's because I'm using react-native-maps v.0.13.1 instead of v.0.16.3 because it's currently giving me problems. So instead, because I'm rendering multiple markers in a for loop, I was able to just do:
          for ( ... ) {
            markers.push(
              <Marker draggable
                coordinate={{latitude: list[idx].latitude, longitude: list[idx].longitude}}
                onDragEnd={(e) => this._resetTimerCoords(list[idx].index, e.nativeEvent.coordinate)}
                key={list[idx].createdAt} >
              </Marker>
            );
         }

Where the argument list[idx].index refers to the marker that is being dragged. I know this isn't for an onPress event but I think it would work just the same. Just FYI, if you're having the same issue with not having access to identifier.

@lww I get "unknown" for makerID....

I would just like to add this here;
I found my key under in the following location: event._targetInst.return.key
Now, the way I found it was with an object-search method which takes the event object and looks for a given string, which in my case I already knew. This is apparently from the angular.js library, but i found it on stack overflow: https://stackoverflow.com/a/24818761/741850
comparator = function (obj, text) {
    if (obj && text && typeof obj === 'object' && typeof text === 'object') {
      for (var objKey in obj) {
        if (objKey.charAt(0) !== '$' && hasOwnProperty.call(obj, objKey) &&
          this.comparator(obj[objKey], text[objKey])) {
          return true;
        }
      }
      return false;
    }
    text = ('' + text).toLowerCase();
    return ('' + obj).toLowerCase().indexOf(text) > -1;
  };

  search = function (obj, text) {
    if (typeof text == 'string' && text.charAt(0) === '!') {
      return !this.search(obj, text.substr(1));
    }
    switch (typeof obj) {
      case "boolean":
      case "number":
      case "string":
        return this.comparator(obj, text);
      case "object":
        switch (typeof text) {
          case "object":
            return this.comparator(obj, text);
          default:
            for (var objKey in obj) {
              if (objKey.charAt(0) !== '$' && this.search(obj[objKey], text)) {
                console.log("Found key 1:", objKey) // Will essentially trace out the tree structure for you
                return true;
              }
            }
            break;
        }
        return false;
      case "array":
        for (var i = 0; i < obj.length; i++) {
          if (this.search(obj[i], text)) {
            // This is not triggered for the key we are looking for
            console.log("Found Key 2:", i)
            return true;
          }
        }
        return false;
      default:
        return false;
    }
  };

You use it as follows:
myEventHandler = function(event){
  this.search(event, 'myKnownString')
}

The output will be something like:
22:25:05: Found key 1: key
22:25:05: Found key 1: return
22:25:05: Found key 1: _targetInst

Meaning that, in my case, event._targetInst.return.key holds the desired data.
I feel this is highly over-engineered for what I am trying to achieve, which is to get the ID/Key of the thing being pressed, but anyways, this seems to work.

@stephan-nordnes-eriksen thanks! as of today this is still then only way i got it working

I thought I would combine @stephan-nordnes-eriksen and @lww answers with my implementation. Mine is slightly different because I want the user to press not only the marker, but the marker's callout.  Hope this will help anyone that was still confused
  // Inserts markers into an array for easy placement later
  loadLocationsMarkers() {
    markersArray = []
    var markers = require('../testdata/location/nearbyLocationsRequest.json');

    for (var i = 0; i < markers.locations.length; i++) {
      markersArray.push (
        <MapView.Marker
        key = {markers.locations[i].title}   // THIS IS WHAT WILL BE PASSED
        coordinate={{ latitude: markers.locations[i].latitude, longitude: markers.locations[i].longitude}}
        title={markers.locations[i].title}
        description={"Click here!"}
        onCalloutPress={(event) => this.goToLocation(event) }  // THIS WILL GRAB THE KEY
        pinColor= '#E9C46A'/>
      )
    }
  }

  // Navigate to page passing key of selected marker
  goToLocation (event) {
    const markerId = event._targetInst.return.key
    this.props.navigation.navigate('Location',{ name: markerId })
  }

It's not a really nice solution but in the event object inside nativeEvent you have the coordinate object, that contains the coordinates of your point, so you can use it to find again your object in your array.
The @jrichardlai solution looks better, but if you want you can do it like above :)

What if two marker are at same coordinates? can't identify clicked marker with coordinates in all cases.


Adds support for SPFx v1.17.3. Closes #5054

Adds support for SPFx v1.17.3. Closes #5054

Awesome work @Saurabh7019! We'll try to review it ASAP!

Merged manually. Thank you!


Got ValueError when trying to test the model

I got a valueError after I tried to use the train model to generate chair:
ValueError: Variable gen/BatchNorm/beta does not exist, or was not created with tf.get_variable(). Did you mean to set reuse=None in VarScope?

Then i set reuse to None and got it worked.  Would it affect the  performance of the model?

I also got the same error, and I repeated the same thing. Can you tell me if that is a problem?

I have the same problem and how do you solve it?

I guess you are train the file 3dgan_autoencoder.py ,in line 79 and line 112,it has the same value in "with tf.variable_scope("dis", reuse=reuse):", I replace the value"dis" to another for example "eco".beacaue I think the  scope name can not be same in the two different function "def encoder(inputs, phase_train=True, reuse=False):" and "def discriminator(inputs, phase_train=True, reuse=False):".


[9.x] Support AWS SES with IAM Assume Role

On PR https://github.com/laravel/framework/pull/38481, the file https://github.com/laravel/framework/blob/3234a8dfecbb12140e1ce980e415fcd0363f320a/tests/Mail/MailSesTransportTest.php was removed and with it 3 features were lost:

Ability to let SES Assume Role through AWS SDK
Ability to configure SES ConfigurationSet
Ability to define Email tags

This PR addresses point 1. Upon closer look at item 2), it looks quite complex to get that functionality back because it must be configured at Mail Sending time (see https://github.com/symfony/symfony/pull/37897) and during the Mailable build we would end up needing some sort of if (... instanceof Ses).
Item 3) seem to not even be supported by Symfony and is not clearly documented by AsyncAws (see https://async-aws.com/clients/ses.html).

Looks like I can either get it to work on Windows or Linux, but not both 👀

It seems like you are right. Symfony only supports settings these options via the Header:
https://github.com/symfony/amazon-mailer/blob/99a9a86ae5d3475300b63834c91175bf29a7f19d/Transport/SesApiAsyncAwsTransport.php#L92-L94
And the ConfigurationSetName and Tags are not set while creating via the Factory.
There are four possible solutions going forward:

Let the Developer set them using Tags (not ideal)
Make a PR to symfony/amazon-mailer to support it with the DSN-Object (not sure if this goes through)
Make a custom SesTransport which includes the support.
Create a callback which will be called for all E-Mails which are send using SES and set the correct tags.

@driesvints @taylorotwell what are your opinions on that?

I'll have a look at this today. Thanks

This can already be merged to address 1. and I'll have a look at the other two. Thanks @deleugpn!

I took a new approach by re-introducing the old transport. @deleugpn can you try it out? https://github.com/laravel/framework/pull/40696


Link broken / doesn't exist

If you click on "Load Data" -> "Telegraf" -> "Create Configuration" you will see links to the documentation.
The broken link is the "Telegraf Plugins".
Relevant URLs
Telegraf Plugins
What products and version are you using?
Version 2.0.x (a3fa943) @ RaspberryPi 4 4GB Ubuntu 23.10 ARM

This appears to be replaced/fixed in more recent versions of v2 OSS. For example, v2.7.5, I don't see the link text "Telegraf Plugins" or the problem URL.


[ign -> gz] CMake functions

Part of https://github.com/gazebo-tooling/release-tools/issues/719

Windows jenkins errors don't come from this PR


FABN-1656 Publish v2.2.3

Publish v2.2.3 of release-2.2
Signed-off-by: Bret Harrison<EMAIL_ADDRESS>

/azp run


ERROR: Repository not found: MetalMatze/lastfm-api-wrapper

Hi
and thanks for this nice and really time saver piece of code ;-)
The composer install failed on package MetalMatze/lastfm-api-wrapper because "Repository not found":
  - Installing metalmatze/lastfm-api-wrapper (dev-master e331c63)
    Downloading: Connecting...    Failed to download metalmatze/lastfm-api-wrapper from dist: The "https://api.github.com/repos/MetalMatze/lastfm-api-wrapper/zipball/e331c63bcb44017b4fcc1c8c27863ad07bf98ebe" file could not be downloaded (HTTP/1.1 404 Not Found)
    Now trying to download from source
  - Installing metalmatze/lastfm-api-wrapper (dev-master e331c63)
    Cloning e331c63bcb44017b4fcc1c8c27863ad07bf98ebe

  [RuntimeException]
  Failed to clone git@github.com:MetalMatze/lastfm-api-wrapper.git via git, https, ssh protocols,
   aborting.
  - git://github.com/MetalMatze/lastfm-api-wrapper.git
    Cloning into '/home/cyrille/.../laravel-hackathon-starter/vendor/metalmatze/la
  stfm-api-wrapper'...
    fatal: remote error:
      Repository not found.
  - https://github.com/MetalMatze/lastfm-api-wrapper.git
    Cloning into '/home/cyrille/.../laravel-hackathon-starter/vendor/metalmatze/la
  stfm-api-wrapper'...
    remote: Invalid username or password.
    fatal: Authentication failed for 'https://github.com/MetalMatze/lastfm-api-wrapper.git/'
  - git@github.com:MetalMatze/lastfm-api-wrapper.git
    Cloning into '/home/cyrille/.../laravel-hackathon-starter/vendor/metalmatze/la
  stfm-api-wrapper'...
    ERROR: Repository not found.
    fatal: Could not read from remote repository.

    Please make sure you have the correct access rights
    and the repository exists.

This is as a result of authentication issues with composer and github when you try to install some packages sometimes. It should actually download it but if it doesn't you could comment it out in the require section in the composer.json file so that all the other packages can be downloaded, then you can composer require metalmatze/lastfm-api-wrapper on it's own.

Please let me know if this technique worked for you @Cyrille37

@unicodeveloper i had the same issue and indeed removing the "MetalMatze/lastfm-api-wrapper" from the composer.json did the trick.

Great @ghermans . Thanks for the confirmation.

Recent update. I have replaced metalmatze/lastfm-api-wrapper with dandelionmood/lastfm package @ghermans @Cyrille37 . So, it's all good now


Question about function combineReducers with multiple reducer module imports

Hello.
Let's imagine that we have a reducer file like this:
export function something1 (state={}, action) {
  switch (action.type) {
    ...
  }
}

export function something2 (state={}, action) {
  switch (action.type) {
    ...
  }
}

There are also 3 other similar reducer files with multiple exports.
While the document merely gives an example how to use combineReducers with only 1 file with multiple exports - combineReducers | Redux (import * as reducers from './reducers';)
Then how do you use that function with multiple imports like this?
import * as reducers1 from './reducer1';
import * as reducers2 from './reducer2';
...

const reducer = combineReducers(???); // What argument to write. How to turn imports to object?

Thanks!

Imports are object. Just like you'd merge two objects:
import * as reducers1 from './reducer1';
import * as reducers2 from './reducer2';

let allReducers = Object.assign({}, reducers1, reducers2);
const reducer = combineReducers(allReducers);

Thanks, didn't notice that ES6 has added such function. :+1:

@TheDeveloperXYZ
We're actually going to remove import * from documentation and just show vanilla examples because it confuses a lot of people. See https://github.com/rackt/redux/pull/590.

Thanks for such fast reply; didn't notice that ES6 has added such function.

You can use something like Lodash's assign if you don't want to include a polyfill, and already have Lodash or something similar. It's just merging objects; nothing magic. :-)

@gaearon Good idea to remove import *. I'd also recommend at mentioning what destructuring statements and spread operators are in a comment the first time you use them.

Is it possible to multiple call combineReducers?
If I use combineReducers in separate file and then I want to attach one more reducer (actually, it is routerReducer from react-router-redux) is it possible to do?
The main issue that I cannot use spread operator (...reducers, routing: routerReducer) only staged ES6 features.

The main issue that I cannot use spread operator (...reducers, routing: routerReducer) only staged ES6 features.

It just desugars to Object.assign({}, reducers, { routing: routerReducer }). Object.assign() is part of ES6 and you can use a polyfill for it.
You can even write a reasonable approximation by hand:
let finalReducers = {}
Object.keys(reducers).forEach(key => finalReducers[key] = reducers[key])
finalReducers.routing = routerReducer

const reducer = combineReducer(finalReducers)

It’s all just JavaScript!

Thanks for fast response!
I was trying to use Object.assign() declaration before asking this question. In that case before combining I had rootReducer object with property default: function combination() which worked correctly. But after using var reducer = Object.assign({}, rootReducer, { routing: routerReducer }) my variable reducer contained just a property routing: function routerReducer().
After combineReducer(finalReducers) returned a function with routing but without my app reducers.
I guess I was doing something in a wrong way, but I can't understand what exactly.
But thank you very much about your approach with using Object.keys

If you see default means you are importing an ES module with a CommonJS require. This is usually a mistake. Please check out https://medium.com/@kentcdodds/misunderstanding-es6-modules-upgrading-babel-tears-and-a-solution-ad2d5ab93ce0 for some info on this.
If you can publish a project reproducing this I'm happy to take a look.

I do it like this:
mainReducer.js
import {combineReducers} from 'redux'
import {routerReducer} from 'react-router-redux'

// list of reducers
import registerReducer from 'registerReducer'
import homeReducer from 'homeReducer'
import aboutReducer from 'aboutReducer'
import contactUsReducer from 'contactUsReducer'

export const mapStateToProps = (state) => {
	return {
		register: state.register,
		home: state.home,
		about: state.about,
		contact:state.contact
	}
}
export default combineReducers({
	routing: routerReducer,
	register: registerReducer,
	about: aboutReducer,
	contact: contactUsReducer
})

There is function mapStateToProps in there. The reason is because I often forgot to add entry to mapStateToProps function when it is put in other file. So I bring it to my main reducer,and for easy access. Open multiple files to make action and reducer is real pain.


Scala 3 final release

Can we get a Scala 3.0.0 release?
https://repo1.maven.org/maven2/io/d11/ only has
zhttp_3.0.0-RC1
zhttp_3.0.0-RC3

never mind, this is already work in progress
https://github.com/dream11/zio-http/pull/215


chore(remix-dev): fix flaky tests, make CLI more testable

Rather than process.exit(1), throw an error so we don't kill the jest worker. Also increase the timeout for two tests that often go more than 10 seconds (especially on Windows). The CLI entrypoint already exits appropriately if there's an error, it just needs a little tweak to better handle "expected" errors.
Because these tests are slow (running yarn, etc.), they would often time out while jscodeshift was still running, causing the afterEach callbacks to delete things underneath it and transforms to fail. failOnError: true would then cause jscodeshift to call process.exit(1), which would then kill the current process (the jest worker). Depending on the exact timing, you'd see one or more of the following in the test output:

A bunch of lines like:ERR C:/Users/RUNNER~1/AppData/Local/Temp/remix-tests-1179c2p2ev8/replace-remix-imports/app/db.server.ts File error: Error: ENOENT: no such file or directory, open 'C:\Users\RUNNER~1\AppData\Local\Temp\remix-tests-1179c2p2ev8\replace-remix-imports\app\db.server.ts'
ERR C:/Users/RUNNER~1/AppData/Local/Temp/remix-tests-1179c2p2ev8/replace-remix-imports/app/entry.client.tsx File error: Error: ENOENT: no such file or directory, open 'C:\Users\RUNNER~1\AppData\Local\Temp\remix-tests-1179c2p2ev8\replace-remix-imports\app\entry.client.tsx'
ERR C:/Users/RUNNER~1/AppData/Local/Temp/remix-tests-1179c2p2ev8/replace-remix-imports/app/entry.server.tsx File error: Error: ENOENT: no such file or directory, open 'C:\Users\RUNNER~1\AppData\Local\Temp\remix-tests-1179c2p2ev8\replace-remix-imports\app\entry.server.tsx'

A test failure like:    thrown: "Exceeded timeout of 10000 ms for a test.
    Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test."

Jest aborting altogether:  ●  process.exit called with "1"
      45 |
      46 |   try {
    > 47 |     let { error } = await jscodeshift(transformPath, files, options);

This PR focuses solely on the migration code/tests, but it's probably worth moving away from process.exit(1) elsewhere in the CLI.
Testing Strategy:

Broken behavior was diagnosed/debugged and the fix was validated here:
https://github.com/jenseng/remix/actions?query=branch%3Afix-jscodeshift-tests
In particular, test run # 13 shows the directory structure as it gets mutated underneath jscodeshift by the afterEach
Manually validated CLI still works normally and a CliError behaves as expected

@jenseng could you update this PR to fix conflicts? 🙏🏼


Add dos and don'ts for logo usage

Add instructions of how we want people to use the official Fortran-lang insignia (F logo)

This might be useful as page in the community section of the webpage. This repository should only contain raw assets.

Should we consider adding it to communtiy section of the webpage under fortran-lang projects. @awvwgk

Sure that's an option, I was thinking of having it everywhere we allow for logos to be downloaded (webpage, assets, etc.)
That's seems like a good idea , just like media assets or so.


Fix paths when running coverage from root

I'm running coverage from a docker image where my source code is at /.
I couldn't figure out why the paths were all starting with / but not if I moved things in a subfolder (e.g. /subfolder).
With the current implementation, RELATIVE_DIR would be equal to // instead of / because we suffix no matter what.
I tested this change manually in my docker image with<EMAIL_ADDRESS>and coverage==6.0.2.

The simple tests I added are heavily mocked... let me know if you can think of something better!

Thanks.  I see what you mean about the mocking, but i don't see a better way.

This is now released as part of coverage 6.4.3.


feat(style): added shadow on buttons and avatar (#191)

Proposed Changes

Added box-shadow to buttons and avatar with a new env variable DROP_SHADOW. By default their is no shadow and 3 levels are available: light, medium and heavy.
Closes #191

Screenshot (If Applicable)
Light:

Medium:

Heavy:

Checklist

[x] Tested locally

[x] Ran yarn ci to test my code

[x] Did not add any unnecessary changes

[x] All my changes appear after other changes in each file

[x] Included a screenshot (if adding a new button)

[x] 🚀

This is great, thank you!  How about also adding it to the avatar too?

This is great, thank you! How about also adding it to the avatar too?

It is, but I didn't add a screenshot for the avatar :sweat_smile:. I will do it!

The screenshots for the avatar have been added.

Thank you so much!

This is awesome @Choubakawa, thanks for getting this added!


[workflows] reuse marketplace action for vlang

See https://github.com/nocturlab/setup-vlang-action/pull/74

Oups turns out the fix hasn't been released yet


Reference to PeterO.Cbor version which contains a public advisory

Hello,
During a review of the DsInternals code, this advisory was found.  The relevant commit that addresses it is here and is found in versions > 4.5 of the nuget.
Please advise if you would prefer for me to submit a PR with a nuget version bump or otherwise.
Thanks!
Matt

I just noticed that dependabot automatically submitted a PR for the fix, https://github.com/MichaelGrafnetter/DSInternals/pull/138 for reference.

Yes, upgrading to a new version of the library is in my TODO list. On the other hand, it is currently only used for parsing values generated by Microsoft's code in Azure AD, so I don't expect any malicious intent there.


Design versioning for papi

papi needs to be versioned. Functions, data types, import statements, etc. All interaction needs to be versioned. We should probably also define some rules for when to bump versions.
We also should design how to best version the wiki documentation.

FWIW, ChatGPT says:

When it comes to designing versioning for TypeScript and JavaScript modules, there are several best practices you can follow to ensure smooth compatibility and maintainability. Here are some recommendations:

Semantic Versioning (SemVer): Follow the principles of SemVer for versioning your modules. SemVer consists of three parts: MAJOR.MINOR.PATCH. Increment the MAJOR version when you make incompatible changes, the MINOR version when you add functionality in a backwards-compatible manner, and the PATCH version when you make backwards-compatible bug fixes.

Git Version Tagging: Utilize Git tags to mark specific versions of your modules. Whenever you release a new version, create a corresponding Git tag with the version number. This allows you to easily track and reference specific releases in your codebase.

Package Managers: If you are using a package manager like npm (Node Package Manager) or yarn, leverage their versioning features. These tools provide commands to manage module versions, publish new releases, and handle dependencies.

Peer Dependencies: Clearly define and manage your module's dependencies, especially peer dependencies. Peer dependencies indicate the compatibility requirements for other modules that may be used alongside your module. Make sure to specify accurate version ranges for peer dependencies to avoid compatibility issues.

Changelogs: Maintain a detailed changelog for each version of your module. Changelogs provide information about the changes made in each release, including bug fixes, new features, and breaking changes. This helps users understand the impact of upgrading to a new version and allows for easier debugging.

Release Notes and Documentation: Alongside your changelog, provide release notes and updated documentation for each version. Clearly explain any breaking changes and provide migration guides if necessary. This assists developers in understanding the changes and adapting their code accordingly.

Testing and Continuous Integration (CI): Implement a robust testing strategy to ensure the stability and compatibility of your modules across different versions. Automated testing, coupled with continuous integration and deployment (CI/CD) pipelines, can help catch potential issues early and prevent regressions.

Deprecation and Sunset Policy: Clearly communicate your deprecation and sunset policy. When you plan to deprecate or remove certain features or modules, provide advance notice and establish a timeline for the deprecation process. This allows users to plan and adapt their code accordingly.

By following these guidelines, you can create a solid versioning strategy for your TypeScript and JavaScript modules, enabling seamless upgrades and better compatibility for your users.

These all seem pretty good to me.  Item 1 has some good rules for when to bump versions that matches my experience in the past.  Sometimes there is a fourth component which is a build date or date/time that gets used mostly when working with release candidates.
Is there a reason we wouldn't want all of the core repo to carry a unified version?

Versioning a wiki to align with code versioning can be achieved through various approaches. Here are a few common methods:

Git Repository: Store your wiki content in a separate Git repository alongside your codebase. This allows you to leverage the same version control system for both code and documentation. You can create branches, tags, and commits in the wiki repository to correspond with code versions, making it easy to track changes and maintain synchronization.

Documentation as Code: Treat your wiki content as code and version it alongside your codebase within the same repository. Write your documentation using a markup language like Markdown or reStructuredText. By keeping your documentation files in the code repository, you can track changes and version them using the same version control system.

Documentation Branches: Create separate branches in your code repository dedicated to documentation. You can have branches like "master" for the main code and "docs" for the documentation. Each branch can have its own versioning scheme, allowing you to manage and release documentation versions independently.

Release Tags: Use Git tags or release tags to mark specific versions of your codebase, and create corresponding tags for your wiki. This way, you can link each release of your code with a specific version of the wiki. Users can then access the wiki content corresponding to the version of the code they are using.

Documentation Versioning Tools: There are specialized tools available for versioning documentation, such as Read the Docs (https://readthedocs.org/). These tools allow you to create separate versions of your documentation and associate them with specific code versions. They often integrate with popular version control systems like Git and provide a dedicated interface for managing and browsing different versions of your documentation.

Changelog Integration: Include a link to the relevant version of the wiki in your code's changelog or release notes. This ensures that users can easily find the corresponding documentation for each code version.

It's important to choose a method that suits your team's workflow and requirements. Whichever approach you adopt, ensure that your documentation is easily accessible and clearly tied to specific code versions. This enables developers to access the relevant information and helps maintain consistency between the codebase and the accompanying documentation.

This seems a little less obvious to me.  I think @FoolRunning has used https://readthedocs.org/ for some scripture burrito work.

I tried to get more specific with ChatGPT regarding a JavaScript extension API, but I don't think it was really getting it. After some clarifications about what the api isn't, it mostly suggested SEMVER (I guess for the whole entire api) and hard versioning in the specification, but it didn't give any code examples. Maybe they could look something like this:

import papi from 'papi-frontend-1.0.3' or 'papi-frontend-1.x.x' or something like that
import papi from 'papi-frontend' (and track which version of the papi it wants based on what's listed in the manifest.json or maybe package.json)
In use: papi.v1.dataProvider.get
In use: papi.dataProvider.get.v1 or papi.dataProvider.v1.get or papi.dataProvider.getV1 or something

Seems like they might all have pretty similar complexity in terms of avoiding code duplication, but 1-3 would probably have most/all of the duplication elimination code in the papi service, whereas 4 would probably put it on the service. Would be interesting to contemplate this and figure out a good solution. I like the feel of 2 right now, but I feel like 4 would probably be easiest to implement and understand.

This seems a little less obvious to me. I think @FoolRunning has used https://readthedocs.org/ for some scripture burrito work.

@lyonsil, Yes, that is correct. It does work well for versioning documentation. You can see it in use for Burrido.Bible (version selector is on the bottom-left).


Supporting both old & new architectures

Hi,
Currently this component supports only the new architecture.
Can you please add old architecture support as well?
As I can see it shouldn't be a big deal...you can read more about here.

@tamas-toth Due to my busy schedule, I currently lack the time to address these issues. If you discover any solutions, kindly submit a pull request. Thank you for your understanding.


Major-open semver range does not properly unify with closed semver ranges

Problem
If a dependency's version is constrained to cover multiple semver-incompatible releases, the version selected does not unify with more specific restrictions from elsewhere in the build graph. E.g. a requirement for >=0.0.0, <0.9.0 and a requirement for ^0.4.0 results in both version 0.4.x and 0.8.y being pulled in (or 0.4.x and 0.1.0 with -Zminimal-versions), rather than unifying both versions to just 0.4.x.
Manually adjusting the lockfile to use 0.4.x in both cases works as expected; this is just an issue with the "find the best solution" codepath, not the "check the lockfile satisfies" codepath.
Originally reported by @MaximilianKoestler on URLO: https://users.rust-lang.org/t/crate-interoperability-and-3rd-party-types-in-interfaces/53431
Steps
Repro from @MaximilianKoestler : https://github.com/MaximilianKoestler/crate-version-testing
Using the rgb crate as our target, this is exemplified using just the three packages:
[package]
name = "lib_a"

[dependencies]
rgb = ">=0.4.0, <0.5.0"

[package]
name = "lib_b"

[dependencies]
rgb = ">=0.0.0, <0.9.0"

[package]
name = "bin_c"

[dependencies]
lib_a = { path = "../lib_a" }
lib_b = { path = "../lib_b" }

The generated lockfile:
# irrelevant parts removed and reordered
[[package]]
name = "lib_a"
dependencies = [
 "rgb 0.4.0",
]

[[package]]
name = "lib_b"
dependencies = [
 "rgb 0.8.25",
]

[[package]]
name = "bin_c"
dependencies = [
 "lib_a",
 "lib_b",
]

[[package]]
name = "rgb"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"

[[package]]
name = "rgb"
version = "0.8.25"
source = "registry+https://github.com/rust-lang/crates.io-index"

Possible Solution(s)
Ideally, if all constraints overlap, only a single version should be selected. Otherwise, maintaining support for old semver-incompatible versions of public dependencies (when the subset you're using didn't change) is almost meaningless, as cargo won't unify the dependency off of the most recent semver-compatible range (or first with -Zminimal-versions).
Notes
Output of cargo version: cargo 1.50.0-nightly (75d5d8cff 2020-12-22) (also occurs on stable)

Thank you for the clear description and reproducible example!
Cargos resolver (with in the one-per-major constraints) attempts to optimize for "getting everyone the most recent they can use" and does not optimize for "have the fewest versions".
I can not think of how to make the current resolver flexible over this optimization target. If pubgrub gets incorporated into Cargo things may be more flexible.
It may be possible to make an iterative optimization procedure.

Cargos resolver (with in the one-per-major constraints) attempts to optimize for "getting everyone the most recent they can use" and does not optimize for "have the fewest versions".

Understandable, and almost certainly the correct target for private dependencies. Just very unfortunate for public dependencies, where it's not so much wanting to "have the fewest versions" as wanting not to "expected type rgb::RGBA, found type rgb::RGBA".
Perhaps this is another thing that could/should be tied to public/private dependencies. Currently, marking the dependencies as public panics on unimplemented ConflictReason::PublicDependency.

Yes, public/private dependencies would be a good more general solution for this problem. If you hit that panic then there is not solution for those constraints or there is a bug in resolving public/private dependencies ( which would not be surprising, there is a reason it is unstable).

Definitely some bugs remaining; manually creating a lockfile with just rgb:0.4.0 works just fine.

I wonder if this issue could be addressed by extending the [patch] feature of Cargo.
Maybe something like this? (for the example above)
[patch.crates.io]
lib_a.dependencies.rgb = "=0.4.0"
lib_b.dependencies.rgb = "=0.4.0"

This would patch the rgb dependency in the lib_a crate to say "force the version to 0.4.0".  Similar for lib_b's dependency on rgb.  I like this approach because it is clear that the programmer is patching something that has already been published, and therefore the programmer is taking responsibility for ensuring that the lib_a and lib_b crates function properly in her/his application.

Perhaps this should be a different issue, but the Dependency Resolver section of the Cargo Book doesn't mention this aspect of the current resolver, which led me to be very confused about another instance of the behavior described here. Since it seems like this behavior will continue to happen for a while, it "would be nice"™ if the book discussed it.

As the one who was just looking for this information, and having trouble finding it, you are in the best position to guide us on how to improve the documentation.
Where would you expect this section to go? What would you expect it to say?
If you have the time, documentation PR's are always welcome.

PR submitted as #11604.


haskellPackages.postgresql-simple-url: mark unbroken

Motivation for this change
I'm new to nix, and want to use this package in my projects.
It builds on the haskell-updates branch with:
nix-build --no-out-link -A haskellPackages.postgresql-simple-url --arg config '{ allowBroken = true; }'

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @

I've tested that this does work.
Thanks @donatello!


Question: Do Events work?

https://github.com/ethereum/wiki/wiki/JavaScript-API#contract-events
I registered a contract event in my aepp. Works in MetaMask but not in ID-Manager. The callback is just never called. Is that maybe a Infura Issue?

probably an infura issue
I'll look at it again

looks like you need a websocket connection to the node, which the IDM od id.manager-provider does not provide


Test Explorer Jumps Too Much When Running VS Code Test Suite

This scrolling doesn't provide any value in this situation and looks broken.
Please add a (higher?) debounce and limit scrolling distance.

This came in with other improvements necessary for snapshot tests


unify nomenclature for incidence-angle

within the code, the use of  theta_0 , theta_i and mu_0
is not fully consistent, evident from definitions such as:

theta_i = np.arccos(mu_0)
def thetap(self, thetai, thetas, phii, phis, a=[-1.,1.,1.])
which is actually defined to represent thetap with zenith-angle arguments (theta_0, theta_s)

-> this needs to be corrected in order to be able to write a consistent documentation

new nomenclature introduced in unified_nomenclature branch.

tests and examples adapted and working

branch was merged


i2c-tools: 4.1 -> 4.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/i2c-tools/versions.
meta.description for i2c-tools is: "Set of I2C tools for Linux"
meta.homepage for i2c-tools is: "https://i2c.wiki.kernel.org/index.php/I2C_Tools"
meta.changelog for i2c-tools is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 4.2 with grep in /nix/store/f19alf8kib2v8xg8hyl9vxs3ms5b1swb-i2c-tools-4.2

directory tree listing: https://gist.github.com/4ff1671e27689ae84d339ac078d158ca

du listing: https://gist.github.com/84caab52995b0e63d0d0a9cf6843a0a0

Rebuild report (if merged into master) (click to expand)

33 total rebuild path(s)

11 package rebuild(s)

11 x86_64-linux rebuild(s)
11 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
11 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
clight
clightd
ddcui
ddcutil
enlightenment.enlightenment
i2c-tools
libsForQt5.powerdevil
libsForQt512.powerdevil
libsForQt514.powerdevil
libsForQt515.powerdevil
plasma5.powerdevil

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/f19alf8kib2v8xg8hyl9vxs3ms5b1swb-i2c-tools-4.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A i2c-tools https://github.com/r-ryantm/nixpkgs/archive/d1c2b7efa07f60a5ac3ca83a67e154437b84c7d2.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/f19alf8kib2v8xg8hyl9vxs3ms5b1swb-i2c-tools-4.2
ls -la /nix/store/f19alf8kib2v8xg8hyl9vxs3ms5b1swb-i2c-tools-4.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review 1

9 packages built:

clight
clightd
ddcui
ddcutil
enlightenment.enlightenment
i2c-tools
powerdevil (plasma5.powerdevil)
libsForQt512.powerdevil
libsForQt514.powerdevil

Maintainer pings
cc @dezgeg for testing.

Result of nixpkgs-review pr 102460 1

9 packages built:

clight
clightd
ddcui
ddcutil
enlightenment.enlightenment
i2c-tools
plasma5.powerdevil (libsForQt5.powerdevil)
libsForQt512.powerdevil
libsForQt514.powerdevil


RUSTSEC-2021-0059: aesni has been merged into the aes crate

aesni has been merged into the aes crate

Details

Status
unmaintained

Package
aesni

Version
0.10.0

URL
https://github.com/RustCrypto/block-ciphers/pull/200

Date
2021-04-29

Please use the aes crate going forward. The new repository location is at:
<https://github.com/RustCrypto/block-ciphers/tree/master/aes>
AES-NI is now autodetected at runtime on i686/x86-64 platforms.
If AES-NI is not present, the aes crate will fallback to a constant-time
portable software implementation.
To prevent this fallback (and have absence of AES-NI result in an illegal
instruction crash instead), continue to pass the same RUSTFLAGS which were
previously required for the aesni crate to compile:
RUSTFLAGS=-Ctarget-feature=+aes,+ssse3

See advisory page for additional details.

fixed


⚠ Consejo de Estado has degraded performance

In 9bcff68, Consejo de Estado (https://consejodeestado.gov.co/) experienced degraded performance:

HTTP code: 200
Response time: 9197 ms

Resolved: Consejo de Estado performance has improved in f586cc0.


Added over zoom effect feature

https://user-images.githubusercontent.com/36570577/145881283-5a0a051a-811e-4733-8276-4b7bef0e8a6f.mp4

Seems that you are not allowing edits to the PR so merged in #5.


Replace fan in T430

https://www.youtube.com/watch?v=ABv5EpsrCLI walks through which screws to remove in what order

Done. All parts accounted for. Replacement fan is a bit noisier at idle than I'd expected, but a vast improvement.


UI: Added Hero Component and Course Detail Page

Issue Number
fixes #3

Describe the changes you've made
Added responsive Hero component for the Course Detail page. Also added a new CourseDetail page on route /course/:id

Describe if there is any unusual behavior (Any Warning) of your code(Write NA if there isn't)
Getting problems with Scroll Behaviour after recent pull, anything after the viewport width is unreachable. It probably has to do with some other commit in Layout component as I have tested this on several pages and got the same issue but it was working fine prior to the pull changes.

Getting problems with Scroll Behaviour after recent pull, anything after the viewport width is unreachable. It probably has to do with some other commit in Layout component as I have tested this on several pages and got the same issue but it was working fine prior to the pull changes.

Fixed with https://github.com/codeforcauseorg/edu-client/commit/44c916fa4fe8eeeea6b2eaebe08aa036fc01e1c6 rebase your changes

@Abhishek-kumar09 Okay, I will do it. Does the UI looks good ?

@Abhishek-kumar09 rebasing is causing issues as I have already pushed changes to my fork. Instead of force pushng I have merged the changes. If we need a single commit then I would have to force push on my fork.

First squash all your commits into one and then rebase, You will have no conflicts then

Please resolve conflicts.

@KeenWarrior Done.


CdsSelect has !important inline CSS that disallows setting the padding on it,

Describe the bug
The CdsSelect element will make select tags to render with inline CSS styles that place padding-left and padding-right with an !important tag, making impossible (or at least difficult) to change the X-axis padding on the select element.
How to reproduce
Implement any CdsSelect as per instructions in the documentation
Steps to reproduce the behavior:

Create a CSS file to alter the style on the cds-select tag
Use --padding and set it to 0 30px
Check the styles being applied using the development console inspection

Expected behavior
It should be possible to change the padding on the X-axis on the CdsSelect element.
Versions
Clarity project:

[x] Clarity Core
[ ] Clarity Angular/UI

Clarity version:

[ ] v5.x
[x] v6.x

Framework:

[ ] Angular
[ ] React
[ ] Vue
[x] Other: This happens in core

Framework version:
N/A
Device:

Type: Dell laptop
OS: Windows 11
Browser Chrome (but most likely all browsers)
Version latest

Additional notes
Please note that this behavior overrides the internally set --padding value too.

Plink


queries:run endpoint truncates data in response

The queries:run endpoint is only returning the first 100 results of a query
Query:
{
"find": "omics_processing_set",
"filter": {"part_of": "nmdc:sty-11-aygzgv51"}
}
Response:
response_1704828951248.json
Note at the end of the response JSON that it claims partialResultsReturned: null

Proposed Fix:

refactor to not rely on the queries:run POST endpoint; Use the nmdcschema/{collection_name} GET endpoint instead
Simplify / refactor API client to be GET only w/o authentication / token etc.


Suggest a project

Project
Syndicate
Description
Transaction APIs and L3 rollups to to power onchain applications.
Please provide the project scope.
Safe Apps
Select a primary category of your project.
Infrastructure
Select secondary categories of your project.
Tooling, Infrastructure, Gaming
Project logo

Value proposition
Our modular end-to-end infrastructure abstracts the complexity of sending onchain transactions and decreases development time — making it easier, cheaper and faster for developers to build, launch and grow onchain products at any scale.
Contact
<EMAIL_ADDRESS>Project URL
https://syndicate.io
Github / Dev Docs
https://docs.syndicate.io
Twitter
https://twitter.com/syndicateio
Primary integration
No response
Packages
No response
Modules / Guards
No response
Smart Accounts
No response
Networks
Base, Ethereum, BNB, Gnosis Chain, Polygon, Optimism, Arbitrum
Can you create a Safe via the interface?
No
Can you import an existing Safe via the interface?
No

Transferred to Notion @debbchiasafe 👍


fix: corrected relative links to getting-started/products

replaced /yearn-finance/ with /getting-started/products/

This PR doesn't make sense anymore


[Question] Release 1.0.0

Question
Hi! 👋
I've personally happily used your tool, thanks a lot. For a bigger project however, the objection came up that the tool is not on a stable version yet.
Are there any plans for public API changes in the near future? If no, would it be possible to release 1.0.0?
Many thanks!

I would consider the regctl and regsync commands relatively stable at this point, and changes are mainly in the form of new functionality that doesn't impact existing features.
The Go API is still considered under development. Adding the 1.0.0 designation would handcuff the ability to make future changes to the project and rapidly iterate support for specs that are not yet GA upstream. That said, the core methods to list tags, push and pull manifests and blobs, and copy images, are not expected to change. Most of the changes are in features like image mutation and artifact management.

thanks for the quick reply!


Publish first release on Pypi

Publish 1.0.0 release (#4) in Pypi.

Roadmap undefined. That is no sense to keep this issue opened


compiling error. rror: ‘EVP_PKEY_cmp’ is deprecated

facing this error! anyone?
In function ‘mg_uri_to_local_path’,
inlined from ‘mg_serve_http’ at util/src/mongoose.c:8415:7:
util/src/mongoose.c:518:7: warning: ‘%.*s’ directive argument is null [-Wformat-overflow=]
518 |       cs_log_printf x;
|       ^
util/src/mongoose.c:8167:3: note: in expansion of macro ‘LOG’
8167 |   LOG(LL_DEBUG,
|   ^~~
util/src/mongoose.c: In function ‘mg_serve_http’:
util/src/mongoose.c:8168:27: note: format string is defined here
8168 |       ("'%.*s' -> '%s' + '%.*s'", (int) hm->uri.len, hm->uri.p,
|                           ^~~~
CC       src/stir_shaken.lo
src/stir_shaken.c: In function ‘stir_shaken_is_key_trusted’:
src/stir_shaken.c:726:9: error: ‘EVP_PKEY_cmp’ is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
726 |         if (!EVP_PKEY_cmp(pkey, candidate_pkey)) {
|         ^~
In file included from /usr/include/openssl/x509.h:29,
from /usr/include/openssl/ssl.h:31,
from /usr/include/libks/ks_ssl.h:25,
from /usr/include/libks/ks.h:79,
from include/stir_shaken.h:15,
from src/stir_shaken.c:1:
/usr/include/openssl/evp.h:1418:5: note: declared here
1418 | int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b);
|     ^~~~~~~~~~~~
src/stir_shaken.c: At top level:
cc1: note: unrecognized command-line option ‘-Wno-gnu-zero-variadic-macro-arguments’ may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make: *** [Makefile:1336: src/stir_shaken.lo] Error 1
root@test-Latitude-5490:/libstirshaken#

I also face this error. how can solve it?

I have the same problem.
config.status: creating Makefile
config.status: creating build/stirshaken.pc
config.status: executing depfiles commands
config.status: executing libtool commands
CC       src/stir_shaken.lo
src/stir_shaken.c: In function 'stir_shaken_is_key_trusted':
src/stir_shaken.c:726:9: error: 'EVP_PKEY_cmp' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
726 |         if (!EVP_PKEY_cmp(pkey, candidate_pkey)) {
|         ^~
In file included from /usr/include/openssl/x509.h:29,
from /usr/include/openssl/ssl.h:31,
from /usr/include/libks2/libks/ks_ssl.h:25,
from /usr/include/libks2/libks/ks.h:80,
from include/stir_shaken.h:15,
from src/stir_shaken.c:1:
/usr/include/openssl/evp.h:1418:5: note: declared here
1418 | int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b);
|     ^~~~~~~~~~~~
At top level:
cc1: note: unrecognized command-line option '-Wno-gnu-zero-variadic-macro-arguments' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make: *** [Makefile:1337: src/stir_shaken.lo] Error 1
CC       src/stir_shaken.lo
src/stir_shaken.c: In function 'stir_shaken_is_key_trusted':
src/stir_shaken.c:726:9: error: 'EVP_PKEY_cmp' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
726 |         if (!EVP_PKEY_cmp(pkey, candidate_pkey)) {
|         ^~
In file included from /usr/include/openssl/x509.h:29,
from /usr/include/openssl/ssl.h:31,
from /usr/include/libks2/libks/ks_ssl.h:25,
from /usr/include/libks2/libks/ks.h:80,
from include/stir_shaken.h:15,
from src/stir_shaken.c:1:
/usr/include/openssl/evp.h:1418:5: note: declared here
1418 | int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b);
|     ^~~~~~~~~~~~
At top level:
cc1: note: unrecognized command-line option '-Wno-gnu-zero-variadic-macro-arguments' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make: *** [Makefile:1337: src/stir_shaken.lo] Error 1
CC       src/stir_shaken.lo
src/stir_shaken.c: In function 'stir_shaken_is_key_trusted':
src/stir_shaken.c:726:9: error: 'EVP_PKEY_cmp' is deprecated: Since OpenSSL 3.0 [-Werror=deprecated-declarations]
726 |         if (!EVP_PKEY_cmp(pkey, candidate_pkey)) {
|         ^~
In file included from /usr/include/openssl/x509.h:29,
from /usr/include/openssl/ssl.h:31,
from /usr/include/libks2/libks/ks_ssl.h:25,
from /usr/include/libks2/libks/ks.h:80,
from include/stir_shaken.h:15,
from src/stir_shaken.c:1:
/usr/include/openssl/evp.h:1418:5: note: declared here
1418 | int EVP_PKEY_cmp(const EVP_PKEY *a, const EVP_PKEY *b);
|     ^~~~~~~~~~~~
At top level:
cc1: note: unrecognized command-line option '-Wno-gnu-zero-variadic-macro-arguments' may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
make: *** [Makefile:1337: src/stir_shaken.lo] Error 1

Same here, but on RHEL 9.2.
Managed to install dependencies, ./configure  works ok ... but make install fails with :


Clinical significance options (edit evidence) should change depending on Evidence type

I believe we decided that the user should only be presented with certain clinical significance options depending on evidence type when creating/editing evidence:
Diagnostic: Positive/Negative
Prognostic: Better/Worse
Predictive: Sensitivity/Resistance

Yeah, I am going to implement the these reactive form fields after I get editing collections working properly.

Done.


Add image_transport plugins for compressed + more

Also sort alphabetically the list of docker apt deps

@GreatAlexander Do you think this branch is ready? I would like to install all autoware_msgs but i think is better to do so after merging this branch :)


Inline snapshot are broken when using latest prettier (2.1.0)

🐛 Bug Report
When using expect.toMatchInlineSnapshot using prettier 2.1.0, jest throws the following error:
 FAIL  src/App.test.tsx
  ● Test suite failed to run

    TypeError: Cannot read property 'start' of undefined

      at CallExpression (node_modules/jest-snapshot/build/inline_snapshots.js:217:57)

Test Suites: 1 failed, 1 total
Tests:       0 total
Snapshots:   0 total
Time:        4.224s
Ran all test suites related to changed files.

Watch Usage: Press w to show more.

To Reproduce
Steps to reproduce the behavior:

Create react app with typescript template (this is my env but I haven't tested without typescript)

yarn create react-app --template typescript

Write a test that generates a snapshot

// App.test.tsx
test('matches snapshot', () => {
  const { container } = render(<App />);
  expect(container).toMatchInlineSnapshot();
});

Add<EMAIL_ADDRESS>and run test : it works

yarn add<EMAIL_ADDRESS>-D
yarn test

Remove snasphot, add<EMAIL_ADDRESS>and run test : it throws an error

yarn add<EMAIL_ADDRESS>-D
yarn test

Expected behavior
Test should write a new snapshot like at step 3.
Link to repl or repo (highly encouraged)
https://www.github.com/iwazaru/jest-inline-snapshot-bug
envinfo
  System:
    OS: macOS 10.15.6
    CPU: (4) x64 Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.7 - ~/.nvm/versions/node/v12.18.3/bin/npm

I've bisected prettier, and the regression was introduced in https://github.com/prettier/prettier/pull/8678. Probably worth opening an issue in the prettier repo?
/cc @fisker @evilebottnawi @thorn0
Happy to change something here if our current implementation is buggy, of course
https://github.com/facebook/jest/blob/326b165642a6c87c6ebfcbb10544389aac5412bb/packages/jest-snapshot/src/inline_snapshots.ts#L197-L238

I don't know we use loc, sorry! I'll check how can you get that location info.

@SimenB I had a quick look, seems it's not only babel used, we don't use any location info inside Prettier, but we have range info parsers[inferredParser].locStart(node) and parsers[inferredParser].locEnd(node). Do you think it's better to calculate the location info here?
/cc @fisker @evilebottnawi @thorn0

I'm afraid what we've done the breaking change, because it was a part of public API (and jest uses it)

AST property is not the part of API. That's why I propose use locStart and locEnd, they are.

I'm happy to change here to use some other API (PR very much welcome!), but it might be best to reintroduce the loc field for now anyways as we won't be patching older versions of Jest

The only loc I removed from https://github.com/prettier/prettier/pull/8678 is for typescript parser, so for a quick fix, we may just need add this line back
Some other part in Prettier updates the range, so the location info still not "real", but it works that way before too.

Reintroducing that line sounds good, and we can possibly migrate Jest over to use locStart and locEnd helpers so it can be removed from prettier in the future?

I'll add it back, and we might won't remove it(not too much cost), but as I said before

not all parsers has location info

So, we still better refactor in Jest.

One thing to note is that CRA currently uses Jest 24. Upgrading to Jest 26 still fails though (and the linked fix in Prettier fixes it) due to the missing loc field. #10254 added a guard which makes the error be Jest: Couldn't locate all inline snapshots. rather than failing with a TypeError

2.1.1 is released and updating fixes the reproduction in the OP. Thanks!