Set stream_idle_timeout to 0s for xDS listener in pilot sidecar config

Envoy's default value for stream_idle_timeout is 5 minutes. Pilot expects to kill connections every 30 minutes to promote even connection balancing, but the lower default idle timeout can cause connections to be killed more rapidly than expected. This change disables the idle timeout entirely, giving control back to Pilot regarding when the connections are killed.

Hi @joeyb. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Do we send keep alive packets? Can/should we?

@howardjohn - afaik, we don't send keep alives right now, but I think that would be another valid way to handle this. I haven't tested it yet for solving this particular problem, but here's some prior art from a related envoy issue: https://github.com/envoyproxy/envoy/issues/5173#issuecomment-471224265. Configuring the keep alives is a bit different because it would be done on the client side (i.e. in the xds-grpc cluster config) rather than on the server side listener.

Seems like this change makes us more vulnerable to half closed connections , and keep alive may be more useful. Outside of my expertise though, so would be good if someone else could weigh in

Yup, makes sense. I’ll run some tests to confirm that keep alives resolve this particular issue. If so, I’m fine with either approach.

Even if we set keep alives, which we already do here, https://github.com/istio/istio/blob/master/tools/packaging/common/envoy_bootstrap_v2.json#L403, as mentioned by @joeyb , the server side (ingress listener) runs in to stream idle timeout and it resets the connection to local cluster which will force pilot to disconnect the Envoy, IIRC. I think we need to avoid that part - But will wait for @joeyb to confirm though.

is the problem the keep alive time is 5min and the idle timeout is also 5min so there is a race? or if envoy is sending the keep alive packets it will still consider itself idle?

Is stream_idle_timeout set to 0s in release 1.4? If so, in my env the period is still 30min.
 So its only 5min if there is no config sent at all, otherwise it would be 30min

My cluster is silent, I believe it is the grpc keep alive that makes it alive.

Was the grpc keep alive added recently?  If not, you may see a different behaviour. Here is what we see - it disconnects every 5 mins
"message":"[2019-11-19 16:09:31.676][138][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
"message":"[2019-11-19 16:04:31.584][138][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
"message":"[2019-11-19 15:59:31.252][138][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,
"message":"[2019-11-19 15:54:30.854][138][warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13,

Weird， I installed by kubectl apply -f istio-demo.yaml from release-1.4

The TCP client (at TCP layer) doesn't reset the GRPC layer stream timeout, so even we set TCP keep alive the Envoy in front of pilot may kill the stream (not the connection) for the idle timeout.
/ok-to-test

@joeyb: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio
fb6dd1286d2e977a56b7f39d9f9d52d2472f5894
link
/test integ-mixer-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-tests_istio
fb6dd1286d2e977a56b7f39d9f9d52d2472f5894
link
/test integ-mixer-k8s-tests_istio

pilot-multicluster-e2e_istio
fb6dd1286d2e977a56b7f39d9f9d52d2472f5894
link
/test pilot-multicluster-e2e_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@joeyb: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

pilot-multicluster-e2e_istio
fb6dd1286d2e977a56b7f39d9f9d52d2472f5894
link
/test pilot-multicluster-e2e_istio

integ-mixer-k8s-tests_istio
fb6dd1286d2e977a56b7f39d9f9d52d2472f5894
link
/test integ-mixer-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I ran some tests locally and confirmed that setting the tcp keepalive alone is not enough to reset the timeout. @hzxuzhonghu - like Rama mentioned, I suspect that maybe you don't have envoy running next to your pilot instance? Unless I'm missing it somewhere, I don't think we have gRPC keepalives configured.
Setting stream_idle_timeout=0 seems like the most straightforward way to solve this for now, but it seems reasonable to create a follow-up issue to look into whether or not gRPC keepalives do a better job of solving the problem.
Assuming we go with this approach, we'll also need a corresponding PR in the installer repo since it configures the pilot envoy bootstrap via a configmap rather than using the template included in the docker image.

root@beast-02:~/istio-1.4.0# kubectl get pod -n istio-system |grep pilot
istio-pilot-5dc796c7cc-mbkm5              2/2     Running     2          42h

I did have. I remmember we have grpc keep-alive enabled on pilot side, the period is 30s by default. I think this is related.
func (s *Server) grpcServerOptions(options *istiokeepalive.Options) []grpc.ServerOption {
	interceptors := []grpc.UnaryServerInterceptor{
		// setup server prometheus monitoring (as final interceptor in chain)
		prometheus.UnaryServerInterceptor,
	}

	// Temp setting, default should be enough for most supported environments. Can be used for testing
	// envoy with lower values.
	maxStreams := features.MaxConcurrentStreams

	grpcOptions := []grpc.ServerOption{
		grpc.UnaryInterceptor(middleware.ChainUnaryServer(interceptors...)),
		grpc.MaxConcurrentStreams(uint32(maxStreams)),
		grpc.KeepaliveParams(keepalive.ServerParameters{
			Time:                  options.Time,
			Timeout:               options.Timeout,
			MaxConnectionAge:      options.MaxServerConnectionAge,
			MaxConnectionAgeGrace: options.MaxServerConnectionAgeGrace,
		}),
	}

	return grpcOptions
}

@hzxuzhonghu I think this keep alive config are for connection right? The connection may still be alive but the stream (ads stream with Envoy) might still get timed out for 5 mins if it is idle, because Envoy's stream timeout are per stream https://www.envoyproxy.io/docs/envoy/latest/faq/configuration/timeouts#stream-timeouts


Ability to deactivate parameter validation in serializer through config

The natural follow-up to #797 - exposing parameter validation as an option at serialization time when configuring the client!! :)

Feature seems reasonable to me.  Any concerns, @kyleknap @JordonPhillips?

Yeah I am fine with it.

I'm good with it, though I do think the caveats should be mentioned.

Ok, I'll rebase the commits and merge.

Merged.  Thanks for the pull request.


Add constructors for MetaInlines and MetaList

I've had to hack the metadata on the fly (which is bad)...
https://github.com/HE-Arc/slides-devweb/pull/21

I probably doesn't make sense now as pandoc 2 is out. I couldn't manage to hack the meta using a filter anymore.


Upgrading to v5?

Hexi is such an awesome game engine! But there are some errors when I work with Pixi v5. Do you have  any plans on upading it?

Thank You! I love using it too. I don't yet have any plans to upgrade to Pixi 5, but would love. It all depends on time - it's a month's full time work to do it, which I don't yet have. However, if there are any community volunteers out there who could help, please let us know!
kk.


Test TartanAir visual SLAM challenge

When using the original code and given the droid.pth model, the result of the MH004 sequence of TartanAir visual SLAM monocular challenge is very different from the paper. May I ask that the test parameters of the TartanAir visual SLAM challenge are the same as the ”validate_tartanair.py“ script? (because you did not provide the TartanAir visual SLAM challenge script).
The following is the specific result:
xf.peng@labhpc75:~/code/DROID-SLAM$ CUDA_VISIBLE_DEVICES=2 ~/anaconda3/envs/droidenvnew/bin/python evaluation_scripts/test_tartanair_challenge.py --datapath=/home/xf.peng/dataset/TartanAirChallenge/ --weights=droid.pth
Performing evaluation on mono/MH004
droid.pth
100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 662/662 [02:01<00:00,  5.44it/s]
KFs: 372
################################
Global BA Iteration #1
Global BA Iteration #2
Global BA Iteration #3
Global BA Iteration #4
Global BA Iteration #5
Global BA Iteration #6
Global BA Iteration #7
################################
Global BA Iteration #1
Global BA Iteration #2
Global BA Iteration #3
Global BA Iteration #4
Global BA Iteration #5
Global BA Iteration #6
Global BA Iteration #7
Global BA Iteration #8
Global BA Iteration #9
Global BA Iteration #10
Global BA Iteration #11
Global BA Iteration #12
ATE scale: 0.965949975203637
{'ate_score': 3.7281677627737584, 'rpe_score': (0.9659354892992258, 4.380713634900417), 'kitti_score': (1.7173907932760222, 0.20961711203211916)}

Hi, I meet the same problem. Have u found the reason?

Guys I do not think there is any loop closure implemented...

Guys I do not think there is any loop closure implemented...

Guys I do not think there is any loop closure implemented...

What does that mean? DROID actually does not include loop closure.

@ckLibra Does not include loop closure?

Guys I do not think there is any loop closure implemented...

What does that mean? DROID actually does not include loop closure.

hey, the paper says DROID has loop closure~ Have you checked it?

Guys I do not think there is any loop closure implemented...

What does that mean? DROID actually does not include loop closure.

Sorry guys. I apologize for my mistakes. DROID indeed claims the loop clousure in their paper. But in my understanding, there are no explicit loop clousure in current implementation. Maybe the impicit one can be found in backend, just like

Usually front-end is responsible for marking loop closure edges but in case of Droid SLAM's front-end, I can confirm it detects no loop closure on my custom dataset. Also, there is no implementation for loop closure detection. Factors(edges) are added in these methods: add_factors, add_neighborhood_factors and add_proximity_factors and none of them actually looks for loop closure! So, not sure how exactly this is implemented.
Does someone know how is this implemented as quoted in the paper?


A proposed implementation for passing imagery layers data to Fragment Shaders

A proposed implementation for passing imagery layers raster data to a globe material vertex shader for further processing. A current limitation is the way the layers are being iterated in GlobeFS.glsl before setting values to the czm_materialInput->layerColor array. This induces long shader compilation times and requires to set a fixed number of processed layers (set as the GLSL constant layerColorNumber)

Thanks again for your contribution @xtassin!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

I haven't given up on this feature and am still in the process of evaluating performance from a live implementation. Handling the number of layers dynamically is still very much an issue that need to be addressed in a acceptable manner.

Thanks again for your contribution @xtassin!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @xtassin!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @xtassin!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @xtassin!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.


failed to build and run locally

SECURITY NOTICE: If you have found a security problem in the UAA, please do not file a public github issue. Instead, please send an email to<EMAIL_ADDRESS>Thanks for taking the time to file an issue. You'll minimize back and forth and help us help you more effectively by answering all of the following questions as specifically and completely as you can.
What version of UAA are you running?

I downloaded the master branch yesterday

What output do you see from curl <YOUR_UAA>/info -H'Accept: application/json'

curl -H "Accept: application/json" localhost:8080/uaa/login
I saw nothing

How are you deploying the UAA?
I am deploying the UAA

locally only using gradlew

What did you do?
generate a self-signed certificate by following：
openssl genrsa -aes256 -out server.key 1024
openssl rsa -in server.key -out server.key
openssl req -x509 -sha256 -new -key server.key -out server.csr
openssl x509 -sha256 -days 365 -in server.csr -signkey server.key -out selfsigned.crt

and replace the keys serviceProviderKey,serviceProviderCertificate,signingKey in uaa/src/main/resources/required_configuration.yml
my uaa/src/main/resources/required_configuration.yml  now:
login:
  serviceProviderKey: |
    -----BEGIN RSA PRIVATE KEY-----
    MIICXAIBAAKBgQDJnR0kKw5YoDVHZziWQTclLtzaiZCqe3wKkp5Ayd7LVrKAScb9
    f6UayPaFw9xMcsx0jzlGnElrs0XgnYcjFws8gffW57ZfB9w6yvcfA1ED/doiCOuD
    87URbUYhBuwCUXxXvWTDWasnIXX5elgdiU5sr3dt8zkLENyTxWncjzAgTwIDAQAB
    AoGBAMGdgXPPaWqRCDl3Fi+tl2C8/VldjLE7/yZEIXgEpVHPA4MR1uhxIcR0Q9K4
    AiLkiBZTyORXiGbGdg+8GCAJrD4MleKKPZ3lD0JA2Pr0HmY/M+pliriyMM4Ekt2B
    kP2NJgfWuKEdFPj0Jj8xsGILxOfv2y3L1joJvhphvuQQKuehAkEA9sfUsxVjg8Cj
    QraDNM05CEgMeC+F2BJkVGtSdCZ241Vqyo5S05hE9grbHEI1FYtnLlUOSoHduyMY
    6qX4WfH//wJBANElUIJ5IMOV4sovwvgAow3WSFa/KhIL0lzOzqtQNAWdCALVXcs1
    sH7+Z0+zSXuzrgtzf50dYQzI04gzZW8h37ECQE/+ntgeSs/elg1+FDH9hEtG76PV
    49ESxSsITwYPoeI3QhK+5+JnLZOEGVqjq4l8UsoWEDfeuP18dws5GbQuWgkCQDOM
    Z+iQpFOwqMI+vWZU+dtaOmAvI9Zo1YOMcYHl9byAdM4F+uUwKX1ThPEu9min47js
    0cJO0HHPOdvzFwgqKDECQANbqjg3TrTprWMXDHL5n5KoKsLy2XMEpiAZf5lM9WZO
    p200ANCCd8QbJe492IDPA/+tmoqccjsm2UkoXAXBROE=
    -----END RSA PRIVATE KEY-----
  serviceProviderKeyPassword: 123456
  serviceProviderCertificate: |
    -----BEGIN CERTIFICATE-----
    MIICxDCCAi2gAwIBAgIJAKkutcXY6BJxMA0GCSqGSIb3DQEBCwUAMHsxCzAJBgNV
    BAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRUwEwYDVQQHDAxEZWZhdWx0IENpdHkx
    HDAaBgNVBAoME0RlZmF1bHQgQ29tcGFueSBMdGQxJTAjBgkqhkiG9w0BCQEWFmdh
    cmVuZmVhdGhlckBnbWFpbC5jb20wHhcNMTgwMzAxMTg1NDE0WhcNMTgwMzMxMTg1
    NDE0WjB7MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTEVMBMGA1UEBwwM
    RGVmYXVsdCBDaXR5MRwwGgYDVQQKDBNEZWZhdWx0IENvbXBhbnkgTHRkMSUwIwYJ
    KoZIhvcNAQkBFhZnYXJlbmZlYXRoZXJAZ21haWwuY29tMIGfMA0GCSqGSIb3DQEB
    AQUAA4GNADCBiQKBgQDJnR0kKw5YoDVHZziWQTclLtzaiZCqe3wKkp5Ayd7LVrKA
    Scb9f6UayPaFw9xMcsx0jzlGnElrs0XgnYcjFws8gffW57ZfB9w6yvcfA1ED/doi
    COuD87URbUYhBuwCUXxXvWTDWasnIXX5elgdiU5sr3dt8zkLENyTxWncjzAgTwID
    AQABo1AwTjAdBgNVHQ4EFgQU4SQKDauCCCR5u7YCgcMVC0ZP7/8wHwYDVR0jBBgw
    FoAU4SQKDauCCCR5u7YCgcMVC0ZP7/8wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
    AQsFAAOBgQAo8HE74SZIK9vM+SwaJHvNQHvpSMRZ2BXzaW+YvmkyPwSHpBnROvOk
    Umh1bvqPcG/6XFVdPSgVUfYshJgr01OaGgPmKGNCQeMD7WpOHlxIpiqbDOkVMNwL
    nyl0aMJ9jKHf+ZAfPj2qe8qwqUl3xg7wBSehZe6Rk/xdrq1pn1dsXw==
    -----END CERTIFICATE-----

#The secret that an external login server will use to authenticate to the uaa using the id `login`
LOGIN_SECRET: loginsecret

jwt:
  policy:
    activeKeyId: key-id-1
    keys:
      key-id-1:
        signingKey: |
          -----BEGIN RSA PRIVATE KEY-----
          MIICXAIBAAKBgQDJnR0kKw5YoDVHZziWQTclLtzaiZCqe3wKkp5Ayd7LVrKAScb9
          f6UayPaFw9xMcsx0jzlGnElrs0XgnYcjFws8gffW57ZfB9w6yvcfA1ED/doiCOuD
          87URbUYhBuwCUXxXvWTDWasnIXX5elgdiU5sr3dt8zkLENyTxWncjzAgTwIDAQAB
          AoGBAMGdgXPPaWqRCDl3Fi+tl2C8/VldjLE7/yZEIXgEpVHPA4MR1uhxIcR0Q9K4
          AiLkiBZTyORXiGbGdg+8GCAJrD4MleKKPZ3lD0JA2Pr0HmY/M+pliriyMM4Ekt2B
          kP2NJgfWuKEdFPj0Jj8xsGILxOfv2y3L1joJvhphvuQQKuehAkEA9sfUsxVjg8Cj
          QraDNM05CEgMeC+F2BJkVGtSdCZ241Vqyo5S05hE9grbHEI1FYtnLlUOSoHduyMY
          6qX4WfH//wJBANElUIJ5IMOV4sovwvgAow3WSFa/KhIL0lzOzqtQNAWdCALVXcs1
          sH7+Z0+zSXuzrgtzf50dYQzI04gzZW8h37ECQE/+ntgeSs/elg1+FDH9hEtG76PV
          49ESxSsITwYPoeI3QhK+5+JnLZOEGVqjq4l8UsoWEDfeuP18dws5GbQuWgkCQDOM
          Z+iQpFOwqMI+vWZU+dtaOmAvI9Zo1YOMcYHl9byAdM4F+uUwKX1ThPEu9min47js
          0cJO0HHPOdvzFwgqKDECQANbqjg3TrTprWMXDHL5n5KoKsLy2XMEpiAZf5lM9WZO
          p200ANCCd8QbJe492IDPA/+tmoqccjsm2UkoXAXBROE=
          -----END RSA PRIVATE KEY-----

What did you expect to see? What goal are you trying to achieve with the UAA?

see
{
"timestamp":"2012-03-28T18:25:49+0100",
"app" : {"version":"1.8.3"},
"commit_id":"cba0958",
"prompts":{"username":["text","Email"],
"password":["password","Password"]
}
}

create my admin user and enable diego_docker flag for creating a docker app in my development space

What did you see instead?
no response, and I got an error like this after ./gradlew run
cargoRunLocal FAILED
org.codehaus.cargo.container.ContainerException: Deployable [http://localhost:8080/cargocpc/index.html] failed to finish deploying within the timeout period [120000]. The Deployable state is thus unknown.
:cargoRunLocal took 173966ms

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':cargoRunLocal'.
> org.codehaus.cargo.container.ContainerException: Deployable [http://localhost:8080/cargocpc/index.html] failed to finish deploying within the timeout period [120000]. The Deployable state is thus unknown.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 6m 27s
52 actionable tasks: 20 executed, 32 up-to-date
Task timings:
    757ms  :cloudfoundry-identity-model:compileJava
    911ms  :cloudfoundry-identity-model:jar
  30596ms  :cloudfoundry-identity-model:javadoc
  10853ms  :cloudfoundry-identity-client-lib:javadoc
    818ms  :cloudfoundry-identity-model:javadocJar
   3412ms  :cloudfoundry-identity-server:compileJava
  67933ms  :cloudfoundry-identity-server:javadoc
   3167ms  :cloudfoundry-identity-server:javadocJar
   4676ms  :cloudfoundry-identity-statsd:compileJava
   3839ms  :cloudfoundry-identity-statsd:war
   1527ms  :cloudfoundry-identity-statsd:bootRepackage
  13386ms  :cloudfoundry-identity-uaa:war
  11782ms  :cloudfoundry-identity-samples:cloudfoundry-identity-api:javadoc
  11457ms  :cloudfoundry-identity-samples:cloudfoundry-identity-api:war
  19567ms  :cloudfoundry-identity-samples:cloudfoundry-identity-app:javadoc
    978ms  :cloudfoundry-identity-samples:cloudfoundry-identity-app:javadocJar
  11179ms  :cloudfoundry-identity-samples:cloudfoundry-identity-app:war
 173966ms  :cargoRunLocal
Test timings:

@GARENFEATHER We tried using the required_configuration.yml provided and are unable to reproduce this problem. Can you please provide the uaa.log file.
It gets written to a temp location. To find it, please try using:
lsof | grep uaa.log | awk '{print $9}'

@DennisDenuto https://github.com/GARENFEATHER/forBugReporting/blob/master/uaa.log
Sent from my PRO 6 using FastHub

Thanks for uploading the uaa log file. It looks like uaa started up successfully. This is confusing, because according to your gradlew output, it looks like it didn't start up properly.
Can you verify that you don't have anything else listening on the port uaa listens on. i.e. does lsof -i -n | grep http-alt return anything?
Can you confirm that you can run uaa when checking out from master (without any config changes)?

Friendly Ping @GARENFEATHER


Add Cell Count - humanUrineCells

Make sure Cell Count is both in Ingest and Staging area
Add cell count and export
https://contribute.data.humancellatlas.org/projects/detail?uuid=4af795f7-3e1d-4341-b867-4ac0982b9efd
Acceptance criteria for the task:
Cell count is present in ingest and the staging area

[ ] Ingest
[ ] Staging area

Closing as UCSC is already looking into it


Nuclear water generating in world

Steps to recreate issue

Generate a world with a large amount of water, specifically islands.
Some islands will have a small amount of crater water nuclear-deep-fill generated around the edge
Map exchange string that demonstrates issue is below.

I did a bit of debugging and fighting with poorly documented world generation stuff and it seems to be related to allowed_neighbors. When the mod copies the table from data.raw["tile"]["water"], it doesn't change the property. It's unclear to me what exactly allowed_neighbors is used for, but it seems to be used in world generation to create (in-world, not graphical) transitions between tiles. I created a tiny debug mod that simply sets data.raw["tile"]["nuclear-deep-fill"].allowed_neighbors = {}, and it seems to fix the issue. Why this only occurs with deep-fill and not the other water tiles is beyond me though.
Map exchange string
Issue occurs at around [315, -170] (and many other places)
>>>eNpjZGBksGUAgwZ7BoYDDhwsyfmJORAeBHMl5xcUpBbp5helIgtz
JheVpqTq5meiKk7NS82t1E1KLEZRzJFZlJ+HbgJrcUl+HqpISVFqajG
yCHdpUWJeZmkuul4GRvPJa5obWuQYQPh/PYPC//8gDGQ9APoFhBkYGy
AqgWIwwJqck5mWxsCg4AjETiBpRkbGapF17g+rptgzQtToOUAZH6AiB
5JgIp4whp8DTikVGMMEyRxjMPiMxIBYWgK0AqqKwwHBgEi2gCQZGXvf
bl3w/dgFO8Y/Kz9e8k1KsGc0dBV598FonR1Qkh3kTyY4MWsmCOyEeYU
BZuYDe6jUTXvGs2dA4I09IytIhwiIcLAAEge8mRkYBfiArAU9QEJBhg
HmNDuYMSIOjGlg8A3mk8cwxmV7dH8AA8IGZLgciDgBIsAWwl3GCGE69
DswOsjDZCURSoD6jRiQ3ZCC8OFJmLWHkexHcwhmRCD7A01ExQFLNHCB
LEyBEy+Y4a4BhucFdhjPYb4DIzOIAVL1BSgG4YFkYEZBaAEHcHAzMyA
AMG0UqElKAAD0Y6B5<<<

Hi, thanks for the bug report.
I wasn't really sure how to make the graphical transitions work, so there may be... spandrels of the process, and that may be one of them - I originally set it to something different, in the hopes that it would help, then gave up on it when it didn't seem to do anything.
On those grounds, I have no problem at all with adding code to do this.
However, in the interests of solving the bug, I tried to find the crater in the world you gave, and I couldn't. See if that lines up with what you see in the map.

Since we seem to be getting different results, what other mods were you using at the time, and what version of the mod, and Factorio, were you using?

My apologies, I managed to give you the wrong coordinate from my list of coordinates to check. [314, -170] should be the correct one.
For copy/paste:
game.player.print(game.player.surface.get_tile{314, -170}.name)
The nuclear fill actually looks identical to water, only becoming obvious when used with Alien Biomes, where transitions were not properly generated (this is on the Alien Biomes, side, do not worry). This caused me to believe it was a minor conflict between Alien Biomes and True Nukes. However, I was able to verify that the nuclear-deep-fill does generate in worlds without Alien Biomes. My full mod list is
base @ 1.1.61
Delete-Chunk-Tool @ 1.0.1
test_mod @ 0.0.0
True-Nukes @ 0.2.10
True-Nukes-Graphics @ 0.0.1

test_mod is the aforementioned debug mod that executed the allowed_neighbors fix.
When locating the tiles, I used the Map Editor Tiles > Variations functionality to highlight the tiles, the results of which are below.

Yeah, I've got that now. It turns out that I was messing with the allowed_neighbors it's just I was doing it badly in so many ways, and I didn't know what it did.
Anyway, I'll fix it in the next release.

Check the new version, that should fix everything.


Fix FNM countdown to say that it's sponsored by Cardhoarder

Fixes PennyDreadfulMTG/Penny-Dreadful-Tools#7607


Added New Push Button [GSSoC'23]

Added New Push Button [GSSoC'23]
Fixes Issue #1717
Closes #issue_number

Changes proposed
Added new button

Screenshots

Checklist

[X] You've linked this PR to the correct issue.
[X] You have checked that the code is working correctly.
[X] You ⭐ the repository!

Note to reviewers

@Spyware007 Sir can you please check and merge it ?

🎉 The GSSOC'23 program has reached its conclusion, prompting us to officially close all pull requests (PRs) and issues. We extend a heartfelt thank you for your amazing contributions! 🙌 Keep the coding spirit alive with the same enthusiasm, and may luck 🍀 favor you in all your future coding adventures!


(just curious) Where did that name Pororo come from?

I think README should contain the derivation :)

We just updated README explaining our project acronym. Thanks!


[SPARK-24075][MESOS] Option to limit number of retries for a supervised driver

What changes were proposed in this pull request?

Spark drivers run on mesos with supervise enabled will try the driver indefinitely on failures. This PR is to optionally limit the number of retries to a configurable number.
Introducing sparkConf "spark.mesos.driver.supervise.maxRetries" which limits the number of times the driver can be retried. The default behavior is for the driver to be retried indefinitely.
When the check is made to see if supervise is enabled and the job has to be retried, an additional check is made to see if the allowable retries have been exceeded.
Added unit tests for method hasDriverExceededRetries.
Added documentation for "spark.mesos.driver.supervise.maxRetries".

How was this patch tested?
Added unit tests
Built spark package, dockerized it and deployed it as a service on Mesos. Once spark service was running on mesos, a series of drivers were submitted

With supervise disabled, ran a successful driver
With supervise disabled, ran a failure driver
With supervise enabled, ran a successful driver
With supervise enabled and without setting "spark.mesos.driver.supervise.maxRetries", ran failure driver
With supervise enabled and setting "spark.mesos.driver.supervise.maxRetries=1", ran a failure driver
With supervise enabled and setting "spark.mesos.driver.supervise.maxRetries=3", ran a failure driver

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

@tnachen

Test build #92797 has started for PR 21150 at commit 0a93f57.

Test build #92797 has finished for PR 21150 at commit 0a93f57.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92797/
Test FAILed.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

ok to test

Can one of the admins verify this patch?


Fix typo in mmdet.datasets.pipelines.formating

Motivation
"formating" in mmdet.datasets.pipelines is not an appropriate word.
formatting is correct.
Modification
So I changed its name and added a deprecated warning as in mmseg

Hi, please change the import  in mmdet/datasets/pipelines/__init__.py

@RangiLyu  I updated it. Thank you.

Is there any reason that checks was cancelled?
Something I have to update?
I already checked lint.


Downport issue: CL_OO_CLASS_SECTION_SOURCE - short dump on creation due to unknown parameter

The class CL_OO_CLASS_SECTION_SOURCE is used with parameters which are not present in 7.30 SP18.
In 7.30 SP18 the constructor has the parameters:

SLSKEY
EXPOSURE
STATE

Abapgit uses also

source
suppress_constrctr_generation

Found here: https://github.com/larshp/abapGit/blob/de40ef670295078dc37766293fdb7e811f83b099/src/objects/zcl_abapgit_oo_class_new.clas.abap#L237

hmm, perhaps the easiest solution is to fall back to the old approach for if SAP_BASIS < 740

guess this is fixed with https://github.com/larshp/abapGit/commit/00f94d3f2e47a64c30e6b2ccded3cc044b59be81
@testitorleaveit try again

Hi,
same issue on SAP_BASIS 702 SP 20 with version 1.74.0

Retest with version 1.77.0 works fine.

thanks, closing


[FR] Create a new simulator

⌘N should roll down a sheet where you can select a device type, a runtime, and enter a name to create a simulator.
simctl create <name> <device type id> [<runtime id>]

Current progress:

Fixed


fix(v1): check repoUrl before using on users.js

Motivation

Fixes #2275
Minor fix in siteConfig to remove extra whitespace in code comment

Have you read the Contributing Guidelines on pull requests?
Yes.
Test Plan
I first reproduced the issue locally following the instructions in the issue. After that, I implemented the change they suggested in that local docusaurus project and it fixed the issue.

Related PRs
N/A

Separate PR opened for the doc change: #2333

@jsjoeio thank you! :smiley:

@lex111 Thank YOU for the code suggestions! 😃


Parsing plain year numbers like "2024" with "PREFER..."-settings set to "last" returns wrong date. 1 day missing...

print(dateparser.parse(
date_string="2024",
settings={"STRICT_PARSING": False,
"PREFER_DAY_OF_MONTH": "last",
"PREFER_MONTH_OF_YEAR": "last",
"PREFER_DATES_FROM": "past"}))
2024-12-30 00:00:00

It seems you're skipping a day. It should be 2024-12-31 00:00:00
...running on Macbook Air M2, Python 3.11 with

import locale
print(locale.getlocale())
(None, 'UTF-8')

Same problem here on windows, using only
settings={
"PREFER_DAY_OF_MONTH": "last",
"PREFER_MONTH_OF_YEAR": "last"
}

I am also experiencing this with the following minimal code on dateparser version is 1.2.0:
import dateparser
dateparser_settings = {
    "PREFER_MONTH_OF_YEAR": (
        "last"
    ),
    "PREFER_DAY_OF_MONTH": (
        "last"
    ),
    "PARSERS": ["absolute-time"],
}

value = "2024"
parsed_date = dateparser.parse(
    value, settings=dateparser_settings
) # output: datetime.datetime(2024, 12, 30, 0, 0)

Investigating a bit more and testing it with time_machine library. I've been able to check that the output seems to depend on the month when you are executing the code:
Code:
import time_machine

for month in range(1,13):
    travel_date = f"2024-{month}-15"
    with time_machine.travel(travel_date):
        import dateparser
        dateparser_settings = {
            "PREFER_MONTH_OF_YEAR": (
                "last"
            ),
            "PREFER_DAY_OF_MONTH": (
                "last"
            ),
            "PARSERS": ["absolute-time"],
        }

        value = "2024"
        parsed_date = dateparser.parse(
            value, settings=dateparser_settings
        )
        print(f"Current date: {travel_date}. Last year date: {parsed_date}")

Output:
Current date: 2024-1-15. Last year date: 2024-12-31 00:00:00
Current date: 2024-2-15. Last year date: 2024-12-29 00:00:00
Current date: 2024-3-15. Last year date: 2024-12-31 00:00:00
Current date: 2024-4-15. Last year date: 2024-12-30 00:00:00
Current date: 2024-5-15. Last year date: 2024-12-31 00:00:00
Current date: 2024-6-15. Last year date: 2024-12-30 00:00:00
Current date: 2024-7-15. Last year date: 2024-12-31 00:00:00
Current date: 2024-8-15. Last year date: 2024-12-31 00:00:00
Current date: 2024-9-15. Last year date: 2024-12-30 00:00:00
Current date: 2024-10-15. Last year date: 2024-12-31 00:00:00
Current date: 2024-11-15. Last year date: 2024-12-30 00:00:00
Current date: 2024-12-15. Last year date: 2024-12-31 00:00:00
```

@lluissalord : That's a perfect proof for a funny bug! Thx


Hexadecimal HTML entities are not rendered

According to standard Markdown, HTML entities are to be recognized and rendered correctly (https://daringfireball.net/projects/markdown/syntax#autoescape). Up to v2.6.11, Python-Markdown has been able to do so, but with v3 it does not work any longer.
A hex HTML entity is not recognized. The leading ampersand is rendered as "&", and in HTML, the entity consequently reads as the entity itself, like, for example ■ instead of the intended ■.

git bisect tells me that this has been broken by #670 (commit 59406c41e7c3548d1c95a2091e2d676323494f62).


Twitter Cover Photo ugly on project page, but no obvious way to change it :-(

Related to #815 and #768
https://stakes.social/0xFa38Fc50e055CBE88Bd569eddCcE057999B2BC9C
BOOOOO!
 I assumed the picture was from twitter so we changed our cover photo there... but it didn't change :-(
maybe you can help ?
I added the example of our new twitter cover pic... It would be awesome if i could just upload it myself... but i can't find a way.

The Commons Stack is more aligned with your vision than you can dream... once we have this bug fixed... We will be shilling your system all over the place!

FIXED! Thank you!! :-D

FIXED! Thank you!! :-D

then worth closing?

A while ago, it became possible to edit property information if you are the author, so you can change the cover image yourself.
This issue is closed.
edit button:


SortableElement not using provided style

Hi,
i'm trying to follow the solution of the z-index issue (https://github.com/clauderic/react-sortable-hoc/issues/87#issuecomment-260335983)
and i have the following component:
const SortableItem = SortableElement(({value}) =>
{value}
)
const Sortable = SortableContainer(({items}) => {
  return <List className="list">
    {
      items.map((item, index) => <SortableItem key={item} index={index} value={item}
                                               style={{zIndex: 1000000}}/>)
    }
  </List>
})

and this is the generated html

it seems as if the SortableElement is creating another div that is created w/o the provided style.
am I missing anything?
Thanks.

You're not passing the style attribute down to the div itself.
const SortableItem = SortableElement(({value, style}) =>

{value}

)

weird, setting the helperClass didn't work before so i tried the z-index solution.
but it did now..
thanks!

Yeah I found inline style to be easiest to persist css during drag.
{num +1})
    {value}


Automated cherry pick of #859: 不同类型的tag使用对应的参数进行过滤

Cherry pick of #859 on release/2.9.0.
#859: 不同类型的tag使用对应的参数进行过滤

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.9.0@5fec676). Click here to learn what that means.
The diff coverage is 3.7%.

@@               Coverage Diff               @@
##             release/2.9.0    #863   +/-   ##
===============================================
  Coverage                 ?   7.56%
===============================================
  Files                    ?     342
  Lines                    ?   53500
  Branches                 ?       0
===============================================
  Hits                     ?    4048
  Misses                   ?   49072
  Partials                 ?     380

Flag
Coverage Δ

#aFlag
7.56% <3.7%> (?)

Impacted Files
Coverage Δ

pkg/mcclient/options/base.go
48.52% <3.7%> (ø)

Continue to review full report at Codecov.

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

/approve
/lgtm


Error 404 in like_and_follow_last_user_media_likers.py

I keep getting "Request return 404 error!" response.
Apparently the error is somewhere in the function searchUsername() in the file api_search.py
line 18: query = self.SendRequest('users/' + str(usernameName) + '/usernameinfo/')
Maybe Instgram changed something in the API and the request needs to be formed in a different way.
Other scripts (follow_user_followers.py, like_user_followers.py) works fine with the same usernames. I just can't get the usernames of users who liked the last media of given user.
Can anybody look at this code? Or maybe someone knows the solution to this problem?
Thank you.

This pull request fixes it.


Update docs/kubectl.md

Run hack/run-gendocs.sh

Person #3 to hit this. The docs are correct at head. Run make clean then `hack/verify-gendocs. Our build script is not clever enough to know it should pick up changes from bumping godeps dependencies. https://github.com/GoogleCloudPlatform/kubernetes/pull/4355

Got it.


update method get xls

Coverage decreased (-0.001%) to 63.736% when pulling ed7c7aaaa6b3363674492c72fb2e7cf31449d286 on indriHutabalian:dev into 7d81a51613b83f7a22e377df115aa73fbc44fefc on danliris:dev.

Coverage decreased (-0.001%) to 63.736% when pulling f78b158996187866140d934713c8b770381c2bb0 on indriHutabalian:dev into 7d81a51613b83f7a22e377df115aa73fbc44fefc on danliris:dev.


Garbage collection for deletion is handled on the server side?

[Enter feedback here]
When deleteasync is called on a file/ folder, the path is marked for deletion. But does this depend on the client for garbage collection? as in if the client crashes down the line will it end up not cleaning it up or is it done on the server side by adls on a separate thread?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 648562f1-4bc4-97c6-303e-8793ad4b7bf7
Version Independent ID: f1db63f3-e097-fb7f-08ec-8c0993979c5c
Content: DataLakeFileClient.DeleteAsync(DataLakeRequestConditions, CancellationToken) Method (Azure.Storage.Files.DataLake) - Azure for .NET Developers
Content Source: xml/Azure.Storage.Files.DataLake/DataLakeFileClient.xml
Service: azure
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

@Kandhan-Sekar Apologies for the late reply. The DeleteAsync(DataLakeRequestConditions, CancellationToken) operation marks the specified path deletion. The path is later deleted during garbage collection which could take several minutes.

After the storage account or blob container is deleted, it is queued to be recycled and collected by the garbage collector. The system can then free up space for reuse. The deleted storage account or blob container may be restored if the garbage collector has not yet run and the storage space is not yet cleaned up. This is handled by the Storage service in the background.
The time at which the garbage collector is run varies depending on many factors, such as workloads on the storage scale unit, the number of available storage spaces, and so on. On average, the garbage collection of storage accounts occurs 14 days after deletion. Typically the data is unrecoverable by Microsoft. It is recommended to enabled soft delete for blobs that allow you to recover blob data after it has been deleted.

Refer: https://docs.microsoft.com/en-us/troubleshoot/azure/general/data-restore-storage
Please let me know if you have any further queries on this.


App key separate from script file: Hassle free updates (=overwrites) and detection of credential file from earlier installs

Precondition
You already had get_dropbox_link.py installed and had ran the initialization:

You created an app key on the Dropbox website and filled int into APP_KEY = in the script file get_dropbox_link.py
As a result the script (or the dropbox python module, I dunno exactly) created ~/.get_dropbox_link_conf.json

Problem
Now when you update a newer get_dropbox_link.py file over your old one, you have 2 problems:

You need to fill APP_KEY again in get_dropbox_link.py or it fails.
Also after you filled the APP_KEY again with a new generated app key, that fails, as the old ~/.get_dropbox_link_conf.json gets not overwritten by the new app key, but instead remains untouched and hence remains the old one and hence there's a mismatch/contradiction.

Proposed Improvements

The app key gets set not in get_dropbox_link.py but elsewhere, e.g.

a) sibling file get_dropbox_link_app_key.conf
b) passed only once during init via argument like --init-app-key="XXX" and then anyhow is not needed in variable APP_KEY but persisted in ~/.get_dropbox_link_conf.json (I'm speculating, not knowing)

If you had get_dropbox_link.py once on your system, but removed it, and later add it again, but you still have the credentials in get_dropbox_link_app_key.conf, it's clever enough and just uses them.

I've also moved the APP_KEY and ACCOUNT_TYPE variables into the config file to simplify upgrading.

👍 Per se great! 👉 But it yet misses documentation. Please amend!

The README.md does not mention the config file ~/.get_dropbox_link_conf.json at all.

The following should be addressed there:

How the config file gets into existence?

Is it created by the script automatically on the first run? Must the user create it?
If auto-created, where must the credentials be filled? (I think this is currently outdated, still assumes writing into main script file).

What must be in the config file (mandatory)? What can be in the config file (optionally)?
Ideally you try out the process on an entirely fresh Mac user account (fresh copied script, no config file) possibly also with a Dropbox account which is fresh too or an existing one but with a freshly created App-Key (although for the same purpose), to describe the installation/upgrade procedure as complete and realistically as possible (= NOT on your parametrized environment). That way the documentation ensures to be up to date. And if you would be willing to set up a fresh "Try for free" Dropbox account, you possibly already could get the new style links returned then. Important: Don't forget to cancel within the 30 days before they charge!

In particular please describe the "upgrade path" for users like me, whose ~/.get_dropbox_link_conf.json until before the recent Dropbox New Link API adaptations (after 2023-08-09) was like:

{"refresh_token": "XXX", "access_token": "YYY", "access_token_expiration": "YYYY-MM-DDThh:mm:ss.nnnnnn"}

Intermediary update:

After updating the script file, invoking your hotkey, which invoked Automator, which invokes the script fails, as the script needs to re-configure its config file.

Go to Terminal and invoke get_dropbox_link.py and it will guide you through it

$ get_dropbox_link.py ~/Dropbox/Public/some-file.png
=>Please provide your app's App Key. This is NOT an OAuth2 token.
Find the App Key in the App Console. See the README.
App Key: ••••••••••••••••••••••••

=> Which kind of Dropbox account is this App Key associated with?
[p]ersonal or [b]usiness? p
https://www.dropbox.com/s/xxxxxxxx/some-file.png?dl=0

After this ~/.get_dropbox_link_conf.json will have changed to this:
{"app_key": "XXX",
"refresh_token": "XXX",
"account_type": "PERSONAL",
"access_token": "XXX", // Note: Changed when script re-configured now.
"access_token_expiration": "YYYY-MM-DDThh:mm:ss.nnnnnn8" // Note: Changed to timestamp of re-configuration.
}


[BUG] code scanning alert - Incomplete regular expression for hostnames

Tracking issue for:

[ ] https://github.com/Accenture/sfmc-devtools/security/code-scanning/2

was closed by pr #153


Updates to jupyter notebook and ghtorrent

I completed some examples using ghtorrent.py file and added that to the visualization in BaseRepoActivityCard and also added some more examples for the jupyter notebooks

@howderek : It looks like the failing issue is probably a rate limit on the GitHub API. Could you look into this so we know what's up with the failing dev build. I don't think its just this pull request.

Hi @kmn5409, I cannot accept these changes


sonobuoy images command error

What steps did you take and what happened:
exec sonobuoy images --level trace
get this error log:

[root@RqiNodeUat08 kbuser]# sonobuoy images --level trace
TRAC[0000] Invoked command images with args [] and flags [level=trace]
INFO[0000] e2e image to be used: k8s.gcr.io/conformance:v1.23.0
DEBU[0000] Running: /bin/docker [docker inspect --type=image k8s.gcr.io/conformance:v1.23.0]
DEBU[0000] Image: k8s.gcr.io/conformance:v1.23.0 present locally
DEBU[0000] Running: /bin/docker [docker run --rm k8s.gcr.io/conformance:v1.23.0 e2e.test --list-images]
ERRO[0001] unable to collect images of plugins: failed to gather test images from e2e image: exit status 1  trace="exit status 1\nfailed to gather test images from e2e image\ngithub.com/vmware-tanzu/sonobuoy/cmd/sonobuoy/app.collectPluginsImages\n\t/home/runner/work/sonobuoy/sonobuoy/cmd/sonobuoy/app/images.go:426\ngithub.com/vmware-tanzu/sonobuoy/cmd/sonobuoy/app.listImages\n\t/home/runner/work/sonobuoy/sonobuoy/cmd/sonobuoy/app/images.go:257\ngithub.com/vmware-tanzu/sonobuoy/cmd/sonobuoy/app.NewCmdImages.func1\n\t/home/runner/work/sonobuoy/sonobuoy/cmd/sonobuoy/app/images.go:73\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:830\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864\nmain.main\n\t/home/runner/work/sonobuoy/sonobuoy/main.go:27\nruntime.main\n\t/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/proc.go:225\nruntime.goexit\n\t/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/asm_amd64.s:1371\nunable to collect images of plugins\ngithub.com/vmware-tanzu/sonobuoy/cmd/sonobuoy/app.listImages\n\t/home/runner/work/sonobuoy/sonobuoy/cmd/sonobuoy/app/images.go:259\ngithub.com/vmware-tanzu/sonobuoy/cmd/sonobuoy/app.NewCmdImages.func1\n\t/home/runner/work/sonobuoy/sonobuoy/cmd/sonobuoy/app/images.go:73\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:830\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864\nmain.main\n\t/home/runner/work/sonobuoy/sonobuoy/main.go:27\nruntime.main\n\t/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/proc.go:225\nruntime.goexit\n\t/opt/hostedtoolcache/go/1.16.10/x64/src/runtime/asm_amd64.s:1371"

What did you expect to happen:
list the e2e test images
Anything else you would like to add:
Environment:

Sonobuoy version: v0.55.1
Kubernetes version: (use kubectl version): v1.23.0
Kubernetes installer & version: kubeadm v1.23.0
Cloud provider or hardware configuration:
OS (e.g. from /etc/os-release): centos7
Sonobuoy tarball (which contains * below)

➜   sonobuoy images --kubernetes-version v1.23.0
INFO[0000] e2e image to be used: k8s.gcr.io/conformance:v1.23.0
INFO[0000] Pulling image: k8s.gcr.io/conformance:v1.23.0 ...
ERRO[0007] unable to collect images of plugins: failed to gather test images from e2e image: exit status 1
➜  sonobuoy images --kubernetes-version v1.22.0
INFO[0000] e2e image to be used: k8s.gcr.io/conformance:v1.22.0
INFO[0000] Pulling image: k8s.gcr.io/conformance:v1.22.0 ...
ERRO[0009] unable to collect images of plugins: failed to gather test images from e2e image: exit status 1
➜  sonobuoy images --kubernetes-version v1.21.0
INFO[0000] e2e image to be used: k8s.gcr.io/conformance:v1.21.0
INFO[0000] Pulling image: k8s.gcr.io/conformance:v1.21.0 ...
gcr.io/authenticated-image-pulling/alpine:3.7
gcr.io/authenticated-image-pulling/windows-nanoserver:v1
...
...

Seems to be an issue starting with v1.22.0; I'll investigate.

When debugging I get that the conformance image returned:
2021/12/15 17:01:00 failed to create log file /tmp/results/e2e.log: open /tmp/results/e2e.log: no such file or directory

It shouldn't be trying to do that at all since its just trying to output the images.
This seems related to an upstream PR about this though; someone was trying to run the conformance image just in docker rather than via sonobuoy and it assumed it had that results directory mounted (but it wasnt mounted the way they invoked it).
A fix just went in for that but we need to mitigate that here; will have to see what changed from v1.21 and v1.22 to cause it though.

I modified the code to mount the pwd there and see what happens: it looks like they changed the way the image works and now kubeconformance is invoked and the entire test suite is trying to run:
➜  ~ docker ps
CONTAINER ID   IMAGE                            COMMAND                  CREATED              STATUS              PORTS                       NAMES
8b3163fe566d   k8s.gcr.io/conformance:v1.23.0   "kubeconformance e2e…"   About a minute ago   Up About a minute                               objective_elgamal
➜  ~ docker logs 8b3163fe566d
2021/12/15 17:15:28 Running command:
Command env: []
Run from directory:
Executable path: /usr/local/bin/ginkgo
Args (comma-delimited): /usr/local/bin/ginkgo,--focus=\[Conformance\],--skip=,--noColor=true,/usr/local/bin/e2e.test,--,--disable-log-dump,--repo-root=/kubernetes,--provider=local,--report-dir=/tmp/results,--kubeconfig=
2021/12/15 17:15:28 Now listening for interrupts

You can see that the --list-images flag isn't visible at all in the args.

Fix incoming. By setting the entrypoint I was able to get the images from v1.22 and v1.23.

Thanks for this bug report @zzzkl !

Glad to see the fix here,  is there anyway to workaround this for now?

If you need an official release you'll just have to wait for the next one (probably just after the new year with the holidays).
If you just need it for yourself, I'd just grab main and run go install to use the latest version from the main branch.

If you need an official release you'll just have to wait for the next one (probably just after the new year with the holidays).
If you just need it for yourself, I'd just grab main and run go install to use the latest version from the main branch.

Aha, never mind, I’ll try to build locally, thanks for the reply


Can't add AnnotationPage to a Canvas items by reference

Per https://iiif.io/api/presentation/3.0/#53-canvas,  "Referenced, external Annotation Pages must have the id and type properties."
This suggests to me that AnnotationPages appearing in items can be done so by reference.
The AnnotationPageRef class has been added to the skeleton, and we can update https://github.com/iiif-prezi/iiif-prezi3/blob/main/iiif_prezi3/helpers/to_reference.py to make sure the class is used correctly when .to_reference() is called on an AnnotationPage object (done in https://github.com/iiif-prezi/iiif-prezi3/pull/185)
However, even with this, whilst you can successfully call the .to_reference() function and receive the AnnotationPageRef object, when you try to add it to a Canvas object, it gets coerced back to an AnnotationPage object due to the fact that the referenced type is not permitted in the skeleton: https://github.com/iiif-prezi/iiif-prezi3/blob/main/iiif_prezi3/skeleton.py#L328
We should clarify the intent of the spec, and then update this if appropriate.

Need to fix the schema to allow AnnotationPage ref in the items in canvas:
https://github.com/IIIF/presentation-validator/blob/b602feb7cbdf8b7922dfa8200dfe21597566898e/schema/iiif_3_0.json#L655


Compilation error

GFX version: newest from github
GPU: Intel HD 4500
OS: Arch Linux x64
So, when I'm compiling gfx I got this:
error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/std.rs:55:6
   |
55 | impl SeedableRng for StdRng {
   |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_isaac::IsaacRng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:50:6
   |
50 | impl SeedableRng for IsaacRng {
   |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::IsaacRng`

error[E0277]: the trait bound `rand_isaac::Isaac64Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:96:6
   |
96 | impl SeedableRng for Isaac64Rng {
   |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::Isaac64Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:198:6
    |
198 | impl SeedableRng for Hc128Rng {
    |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_xorshift::XorShiftRng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:239:6
    |
239 | impl SeedableRng for XorShiftRng {
    |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_xorshift::XorShiftRng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:279:6
    |
279 | impl SeedableRng for StdRng {
    |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:73:5
   |
73 |     rng: *mut ReseedingRng<Hc128Core, EntropyRng>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:73:5
   |
73 |     rng: *mut ReseedingRng<Hc128Core, EntropyRng>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/std.rs:56:5
   |
56 |     type Seed = <Hc128Rng as SeedableRng>::Seed;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/std.rs:58:5
   |
58 | /     fn from_seed(seed: Self::Seed) -> Self {
59 | |         StdRng(Hc128Rng::from_seed(seed))
60 | |     }
   | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_isaac::IsaacRng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:51:5
   |
51 |     type Seed = <rand_isaac::IsaacRng as SeedableRng>::Seed;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::IsaacRng`

error[E0277]: the trait bound `rand_isaac::IsaacRng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:53:5
   |
53 | /     fn from_seed(seed: Self::Seed) -> Self {
54 | |         IsaacRng(rand_isaac::IsaacRng::from_seed(seed))
55 | |     }
   | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::IsaacRng`

error[E0277]: the trait bound `rand_isaac::Isaac64Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:97:5
   |
97 |     type Seed = <rand_isaac::Isaac64Rng as SeedableRng>::Seed;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::Isaac64Rng`

error[E0277]: the trait bound `rand_isaac::Isaac64Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:99:5
    |
99  | /     fn from_seed(seed: Self::Seed) -> Self {
100 | |         Isaac64Rng(rand_isaac::Isaac64Rng::from_seed(seed))
101 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::Isaac64Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:199:5
    |
199 |     type Seed = <rand_hc::Hc128Rng as SeedableRng>::Seed;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:201:5
    |
201 | /     fn from_seed(seed: Self::Seed) -> Self {
202 | |         Hc128Rng(rand_hc::Hc128Rng::from_seed(seed))
203 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_xorshift::XorShiftRng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:240:5
    |
240 |     type Seed = <::rand_xorshift::XorShiftRng as SeedableRng>::Seed;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_xorshift::XorShiftRng`

error[E0277]: the trait bound `rand_xorshift::XorShiftRng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:242:5
    |
242 | /     fn from_seed(seed: Self::Seed) -> Self {
243 | |         XorShiftRng(::rand_xorshift::XorShiftRng::from_seed(seed))
244 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_xorshift::XorShiftRng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:280:5
    |
280 |     type Seed = <rngs::StdRng as SeedableRng>::Seed;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:282:5
    |
282 | /     fn from_seed(seed: Self::Seed) -> Self {
283 | |         StdRng(rngs::StdRng::from_seed(seed))
284 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error: aborting due to 28 previous errors

For more information about this error, try `rustc --explain E0277`.
error: Could not compile `rand`.

To learn more, run the command again with --verbose.
[duckerman@duckerman browsy]$ cargo r
   Compiling rand v0.6.5
error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/std.rs:55:6
   |
55 | impl SeedableRng for StdRng {
   |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_isaac::IsaacRng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:50:6
   |
50 | impl SeedableRng for IsaacRng {
   |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::IsaacRng`

error[E0277]: the trait bound `rand_isaac::Isaac64Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:96:6
   |
96 | impl SeedableRng for Isaac64Rng {
   |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::Isaac64Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:198:6
    |
198 | impl SeedableRng for Hc128Rng {
    |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_xorshift::XorShiftRng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:239:6
    |
239 | impl SeedableRng for XorShiftRng {
    |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_xorshift::XorShiftRng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:279:6
    |
279 | impl SeedableRng for StdRng {
    |      ^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:73:5
   |
73 |     rng: *mut ReseedingRng<Hc128Core, EntropyRng>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:73:5
   |
73 |     rng: *mut ReseedingRng<Hc128Core, EntropyRng>,
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::block::BlockRngCore` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::block::BlockRngCore` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Core: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/thread.rs:76:1
   |
76 | / thread_local!(
77 | |     static THREAD_RNG_KEY: UnsafeCell<ReseedingRng<Hc128Core, EntropyRng>> = {
78 | |         let mut entropy_source = EntropyRng::new();
79 | |         let r = Hc128Core::from_rng(&mut entropy_source).unwrap_or_else(|err|
...  |
85 | |     }
86 | | );
   | |__^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Core`
   |
note: required by `rngs::adapter::reseeding::ReseedingRng`
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/adapter/reseeding.rs:88:1
   |
88 | / pub struct ReseedingRng<R, Rsdr>(BlockRng<ReseedingCore<R, Rsdr>>)
89 | | where R: BlockRngCore + SeedableRng,
90 | |       Rsdr: RngCore;
   | |____________________^
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/std.rs:56:5
   |
56 |     type Seed = <Hc128Rng as SeedableRng>::Seed;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/rngs/std.rs:58:5
   |
58 | /     fn from_seed(seed: Self::Seed) -> Self {
59 | |         StdRng(Hc128Rng::from_seed(seed))
60 | |     }
   | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_isaac::IsaacRng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:51:5
   |
51 |     type Seed = <rand_isaac::IsaacRng as SeedableRng>::Seed;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::IsaacRng`

error[E0277]: the trait bound `rand_isaac::IsaacRng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:53:5
   |
53 | /     fn from_seed(seed: Self::Seed) -> Self {
54 | |         IsaacRng(rand_isaac::IsaacRng::from_seed(seed))
55 | |     }
   | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::IsaacRng`

error[E0277]: the trait bound `rand_isaac::Isaac64Rng: rand_core::SeedableRng` is not satisfied
  --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:97:5
   |
97 |     type Seed = <rand_isaac::Isaac64Rng as SeedableRng>::Seed;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::Isaac64Rng`

error[E0277]: the trait bound `rand_isaac::Isaac64Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:99:5
    |
99  | /     fn from_seed(seed: Self::Seed) -> Self {
100 | |         Isaac64Rng(rand_isaac::Isaac64Rng::from_seed(seed))
101 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_isaac::Isaac64Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:199:5
    |
199 |     type Seed = <rand_hc::Hc128Rng as SeedableRng>::Seed;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:201:5
    |
201 | /     fn from_seed(seed: Self::Seed) -> Self {
202 | |         Hc128Rng(rand_hc::Hc128Rng::from_seed(seed))
203 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_xorshift::XorShiftRng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:240:5
    |
240 |     type Seed = <::rand_xorshift::XorShiftRng as SeedableRng>::Seed;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_xorshift::XorShiftRng`

error[E0277]: the trait bound `rand_xorshift::XorShiftRng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:242:5
    |
242 | /     fn from_seed(seed: Self::Seed) -> Self {
243 | |         XorShiftRng(::rand_xorshift::XorShiftRng::from_seed(seed))
244 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_xorshift::XorShiftRng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:280:5
    |
280 |     type Seed = <rngs::StdRng as SeedableRng>::Seed;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error[E0277]: the trait bound `rand_hc::Hc128Rng: rand_core::SeedableRng` is not satisfied
   --> /home/duckerman/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.5/src/deprecated.rs:282:5
    |
282 | /     fn from_seed(seed: Self::Seed) -> Self {
283 | |         StdRng(rngs::StdRng::from_seed(seed))
284 | |     }
    | |_____^ the trait `rand_core::SeedableRng` is not implemented for `rand_hc::Hc128Rng`

error: aborting due to 28 previous errors

For more information about this error, try `rustc --explain E0277`.
error: Could not compile `rand`.

To learn more, run the command again with --verbose.

Ooops, It's not your crate


Add the CRF model wrapper

Description
Brief Description of the PR:
Add the CRF model wrapper.
It can be used like following:
tag_num = ... # number of tags
base_model = build_base_model(...)
model = CRFModelWraper(base_model, tag_num)

# CRFModelWraper is a subclass of tf.keras.Model
# so we can compile / fit / evaluate as normal model

# NOTE: CRF loss is computed inside the model, so we do not specific the loss for crf
model.compile(...)
model.fit(...)

Fixes # (issue)
Type of change

[ ] Bug fix
[ ] New Tutorial
[ ] Updated or additional documentation
[ ] Additional Testing
[ ] New Activation and the changes conform to the activation contribution guidelines
[ ] New Callback and the changes conform to the callback contribution guidelines
[ ] New Image addition and the changes conform to the image op contribution guidelines
[ ] New Layer and the changes conform to the layer contribution guidelines
[ ] New Loss and the changes conform to the loss contribution guidelines
[ ] New Metric and the changes conform to the metric contribution guidelines
[ ] New Optimizer and the changes conform to the optimizer contribution guidelines
[ ] New RNN Cell and the changes conform to the rnn contribution guidelines
[ ] New Seq2seq addition and the changes conform to the seq2seq contribution guidelines
[ ] New Text addition and the changes conform to the text op contribution guidelines

Checklist:

[ ] I've properly formatted my code according to the guidelines

[ ] By running Black + Flake8
[ ] By running pre-commit hooks

[ ] This PR addresses an already submitted issue for TensorFlow Addons
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] This PR contains modifications to C++ custom-ops

How Has This Been Tested?
If you're adding a bugfix or new feature please describe the tests that you ran to verify your changes:
*

@gabrieldemarmiesse You are one of the most suitable reviewers for this PR. So please take a look. Thank you!

@gabrieldemarmiesse You are one of the most suitable reviewers for this PR. So please take a look. Thank you!

I don't think he is still active in the project.

@bhack Thank you for your kindly remind. Do you have any reviewer to recommend for this PR? Or could it possible to grant write permission to me? So, I can merge it to the repo. There are a few CRF related PRs still waiting for review for more than two weeks but no one response yet. If I have the write permission, I can merge them too. Of course, I am the codeower of those CRF related features, so I will continuously bugfix and improve them.
/cc @seanpmorgan