Update lychee (#4683)

fragment checking was fixed

---------

Co-authored-by: Carlos Alberto Cortez <[email protected]>

Author: zeitlinger

.lychee.toml

@@ -2,11 +2,24 @@ include_fragments = true
 
 accept = ["200..=299", "403"]
 
+remap = [
+  # workaround for https://github.com/lycheeverse/lychee/issues/1729
+  'https://github.com/(.*?)/(.*?)/blob/(.*?)/(.*#.*)$ https://raw.githubusercontent.com/$1/$2/$3/$4',
+  'https://docs.oracle.com/(.*)#.*$ https://docs.oracle.com/$1'
+]
+
 exclude = [
-    # excluding links to pull requests and issues is done for performance
-    "^https://github.com/open-telemetry/opentelemetry-specification/(issues|pull)/\\d+$",
-    # TODO (trask) look into this
-    "^https://docs.google.com/document/d/1d0afxe3J6bQT-I6UbRXeIYNcTIyBQv4axfjKF4yvAPA/edit"
+  # workaround for https://github.com/lycheeverse/lychee/issues/1729
+  '^https://github.com/.*/(pull|issues|commit|compare)/.*#.*$',
+  '.*decision-log.md#L0-L1',
+  # excluding links to pull requests and issues is done for performance
+  '^https://github.com/open-telemetry/opentelemetry-specification/(issues|pull)/\d+$',
+  # TODO (trask) look into this
+  '^https://docs.google.com/.*/edit.*$',
+  'https://semver.org/#spec-item-11',
+  'https://w3c.github.io/trace-context/#trace-id',
+  'https://facebook.github.io/zstd/#small-data',
+  'https://javadoc.io/doc/org.apache.logging.log4j/log4j-api/latest/org.apache.logging.log4j/org/apache/logging/log4j/Logger.html'
 ]
 
 # better to be safe and avoid failures

CONTRIBUTING.md

@@ -289,7 +289,7 @@ on each other), the owner should try to get people aligned by:
 
 If none of the above worked and the PR has been stuck for more than 2 weeks, the
 owner should bring it to the [OpenTelemetry Specification SIG
-meeting](https://github.com/open-telemetry/community#cross-language-specification).
+meeting](https://github.com/open-telemetry/community/blob/main/README.md#specification-sigs).
 
 [nvm]: https://github.com/nvm-sh/nvm/blob/master/README.md#installing-and-updating
 

Makefile

@@ -29,7 +29,7 @@ misspell-correction:	$(MISSPELL)
 markdown-link-check:
 	docker run --rm \
 		--mount 'type=bind,source=$(PWD),target=/home/repo' \
-		lycheeverse/lychee:sha-2aa22f8@sha256:2e3786630482c41f9f2dd081e06d7da1c36d66996e8cf6573409b8bc418d48c4 \
+		lycheeverse/lychee:sha-8222559@sha256:6f49010cc46543af3b765f19d5319c0cdd4e8415d7596e1b401d5b4cec29c799 \
 		--config home/repo/.lychee.toml \
 		--root-dir /home/repo \
 		-v \
@@ -39,7 +39,7 @@ markdown-link-check:
     # see https://github.com/open-telemetry/opentelemetry-specification/pull/4554
 	docker run --rm \
 		--mount 'type=bind,source=$(PWD),target=/home/repo' \
-		lycheeverse/lychee:sha-2aa22f8@sha256:2e3786630482c41f9f2dd081e06d7da1c36d66996e8cf6573409b8bc418d48c4 \
+		lycheeverse/lychee:sha-8222559@sha256:6f49010cc46543af3b765f19d5319c0cdd4e8415d7596e1b401d5b4cec29c799 \
 		--config home/repo/.lychee.toml \
 		--root-dir /home/repo \
 		--max-redirects 0 \

README.md

@@ -29,7 +29,7 @@ APAC timezone friendly meetings are held on request. See
 [OpenTelemetry calendar](https://github.com/open-telemetry/community#calendar).
 
 Escalations to technical committee may be made over the
-[e-mail](https://github.com/open-telemetry/community#tc-technical-committee).
+[e-mail](https://github.com/open-telemetry/community/blob/main/README.md#mailing-lists).
 Technical committee holds regular meetings, notes are held
 [here](https://docs.google.com/document/d/1hOHPCu5TGenqTeWPB9qQB_qd33uITZBcvK1FnWxYJAw/edit?usp=sharing).
 

issue-management.md

@@ -11,7 +11,7 @@
 - Reviewer:
   - Person whose Approval is needed to merge the PR.
 - Sponsor:
-  - The [specification sponsors](https://github.com/open-telemetry/community/blob/main/community-membership.md#specification-sponsor), identified as the assignee of the issue, is responsible for the completion of the issue.
+  - The [specification sponsors](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#specification-sponsor), identified as the assignee of the issue, is responsible for the completion of the issue.
 - Triager:
   - This person is responsible for applying appropriate labels as outlined below,
     following up on issues to ensure they are complete,

oteps/0001-telemetry-without-manual-instrumentation.md

@@ -89,7 +89,7 @@ There are some languages that will have OpenTelemetry support before they have D
 
 ### Governance of the auto-instrumentation libraries
 
-Each `auto-instr-foo` repository must have at least one [Maintainer](https://github.com/open-telemetry/community/blob/main/community-membership.md#maintainer) in common with the main `opentelemetry-foo` language repository. There are no other requirements or constraints about the set of maintainers/approvers for the main language repository and the respective auto-instrumentation repository; in particular, there may be maintainers/approvers of the main language repository that are not maintainers/approvers for the auto-instrumentation repository, and vice versa.
+Each `auto-instr-foo` repository must have at least one [Maintainer](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer) in common with the main `opentelemetry-foo` language repository. There are no other requirements or constraints about the set of maintainers/approvers for the main language repository and the respective auto-instrumentation repository; in particular, there may be maintainers/approvers of the main language repository that are not maintainers/approvers for the auto-instrumentation repository, and vice versa.
 
 ### Mini-FAQ about this proposal
 

oteps/0007-no-out-of-band-reporting.md

@@ -57,5 +57,5 @@ instance configured with it's own `Resource`.
 * [opentelemetry-specification/62](https://github.com/open-telemetry/opentelemetry-specification/issues/62)
 * [opentelemetry-specification/61](https://github.com/open-telemetry/opentelemetry-specification/issues/61)
 
-[otelsvc-receiver]: https://github.com/open-telemetry/opentelemetry-collector#config-receivers
-[create-metric]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#create-metric
+[otelsvc-receiver]: https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/README.md
+[create-metric]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/api.md#get-a-meter

oteps/0035-opentelemetry-protocol.md

@@ -93,7 +93,7 @@ When an error is returned by the server it falls into 2 broad categories: retrya
 
 - Not-retryable errors indicate that processing of telemetry data failed and the client MUST NOT retry sending the same telemetry data. The telemetry data MUST be dropped. This can happen, for example, when the request contains bad data and cannot be deserialized or otherwise processed by the server. The client SHOULD maintain a counter of such dropped data.
 
-When using gRPC transport the server SHOULD indicate retryable errors using code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status.WithDetails) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40) containing 0 value of RetryDelay. Here is a sample Go code to illustrate:
+When using gRPC transport the server SHOULD indicate retryable errors using code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40) containing 0 value of RetryDelay. Here is a sample Go code to illustrate:
 
 ```go
   // Do this on server side.
@@ -106,7 +106,7 @@ When using gRPC transport the server SHOULD indicate retryable errors using code
   return st.Err()
 ```
 
-To indicate not-retryable errors the server is recommended to use code [InvalidArgument](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status.WithDetails) using [BadRequest](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L119). Other gRPC status code may be used if it is more appropriate. Here is a sample Go code to illustrate:
+To indicate not-retryable errors the server is recommended to use code [InvalidArgument](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status) using [BadRequest](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L119). Other gRPC status code may be used if it is more appropriate. Here is a sample Go code to illustrate:
 
 ```go
   // Do this on server side.
@@ -148,7 +148,7 @@ OTLP allows backpressure signalling.
 
 If the server is unable to keep up with the pace of data it receives from the client then it SHOULD signal that fact to the client. The client MUST then throttle itself to avoid overwhelming the server.
 
-To signal backpressure when using gRPC transport, the server SHOULD return an error with code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status.WithDetails) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). Here is a sample Go code to illustrate:
+To signal backpressure when using gRPC transport, the server SHOULD return an error with code [Unavailable](https://pkg.go.dev/google.golang.org/grpc/codes) and MAY supply additional [details via status](https://pkg.go.dev/google.golang.org/grpc/status#Status) using [RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). Here is a sample Go code to illustrate:
 
 ```go
   // Do this on server side.
@@ -265,7 +265,7 @@ Both FlatBuffers and Capnproto are worth to be re-evaluated for future versions
 
 It is also worth researching transports other than gRPC. Other transports are not included in this RFC due to time limitations.
 
-Experimental implementation of OTLP over WebSockets exists and was researched as an alternate. WebSockets were not chosen as the primary transport for OTLP due to lack or immaturity of certain capabilities (such as [lack of universal support](https://github.com/gorilla/websocket#gorilla-websocket-compared-with-other-packages) for [RFC 7692](https://datatracker.ietf.org/doc/html/rfc7692) message compression extension). Despite limitations the experimental implementation demonstrated good performance and WebSocket transport will be considered for inclusion in a future OTLP Extensions RFC.
+Experimental implementation of OTLP over WebSockets exists and was researched as an alternate. WebSockets were not chosen as the primary transport for OTLP due to lack or immaturity of certain capabilities (such as [lack of universal support](https://github.com/gorilla/websocket/blob/v1.4.2/README.md#gorilla-websocket-compared-with-other-packages) for [RFC 7692](https://datatracker.ietf.org/doc/html/rfc7692) message compression extension). Despite limitations the experimental implementation demonstrated good performance and WebSocket transport will be considered for inclusion in a future OTLP Extensions RFC.
 
 ## Open Questions
 

oteps/0155-external-modules.md

@@ -52,7 +52,7 @@ In fact, these repositories often calls for other set of skills and customer's u
 On contrib repository creation, new set of approvers and maintainers can be added as we do for any new repository, without time/contribution requirements.
 Repository maintainers are also encouraged to promote contributors to approver/maintainer role in this repository
 based on targeted contributions and expertise of the contrib repository rather than overall SIG scope.
-It is important to keep the process fair and inclusive by following the formal guidance published [here](https://github.com/open-telemetry/community/blob/main/community-membership.md#maintainer).
+It is important to keep the process fair and inclusive by following the formal guidance published [here](https://github.com/open-telemetry/community/blob/main/guides/contributor/membership.md#maintainer).
 A contrib repository may leverage the CODEOWNERS functionality of GitHub to assign maintainers to individual packages
 even if this means granting write permissions to the whole repo.
 The goal should be to distribute the load of reviewing PRs and accepting changes as much as possible, while keeping reliability and overall quality of components and fair governance.

oteps/0156-columnar-encoding.md

@@ -804,7 +804,7 @@ dictionary and schema information.  This remains an area for study.
 ### Further-integrated compression techniques
 
 ZSTD offers a training mode, which can be used to tune the algorithm for a selected type of data. The result of this
-training is a dictionary that can be used to compress the data. Using this [dictionary](http://facebook.github.io/zstd/#small-data)
+training is a dictionary that can be used to compress the data. Using this [dictionary](https://facebook.github.io/zstd/#small-data)
 can dramatically improve the compression rate for small batches. This future development will build on both the gRPC
 stream approach used in this proposal and the ability to send a ZSTD dictionary over the OTel Arrow stateful protocol,
 allowing us to train the ZSTD algorithm on the first batches and then update the configuration of the ZSTD