Not working on Windows 10 Professional (x64) Version 2009 (build 19042.1288)

PC recently updated to Windows 10 Professional (x64) Version 2009 (build 19042.1288)
autoupdate.log (attached) gives error message referencing different version:
NOT found "termsrv.dll" version entry [10.0.19041.1202] in file "C:\Program Files\RDP Wrapper\rdpwrap_new.ini"!
RDPComp says not supported:

What further info do you need?

Just to confirm, because I don't want to mess anything up...
autoupdate.bat currently has the following lines:
set rdpwrap_ini_update_github_1="https://raw.githubusercontent.com/asmtron/rdpwrap/master/res/rdpwrap.ini" set rdpwrap_ini_update_github_2="https://raw.githubusercontent.com/saurav-biswas/rdpwrap-1/patch-1/res/rdpwrap.ini" REM set rdpwrap_ini_update_github_3="https://raw.githubusercontent.com/....Extra.3...."
I'm removing the REM on line 3 and changing the URL to the one provided.
Correct?


1.0.4. Linked to future release of 2023.3

1.0.4 is linked to HA 2023.3
Believe that this should be linked to 2023.2
Rounding of decimals had already been added to 2023.2. Cannot find reason to link to the future release of 2023.3.
Could it be a typo?
If not, please close 😉

...had the same thought

It's a typo indeed, let me fix it

Fixed by https://github.com/kamaradclimber/heishamon-homeassistant/releases/tag/1.0.5

thanks for the report

Thanks kamaradclimber.


Stack overflow after upgrade to 7.0.2

I've been experiencing stack overflow in runtime, I didn't immediately notice this problem as I hadn't run tests for a long time during local development.
After hours of comparing changes, I found out that it happened after an upgrade to 7.0.2. After spending some more time trying to figure out what broke between 7.0.1 and 7.0.2 I found the cause.
The problem turned out to be the following PR https://github.com/async-graphql/async-graphql/pull/1468.
Expected Behavior
Working code as on 7.0.1
Actual Behavior
When calling GraphQL mutation and then executing a database transaction, application crashes
thread 'actix-rt|system:0|arbiter:7' has overflowed its stack
fatal runtime error: stack overflow
fish: Job 1, 'cargo run' terminated by signal SIGABRT (Abort)

Using backtrace-on-stack-overflow I got the following stacktrace.

Stacktrace
Stack Overflow:
   0: backtrace_on_stack_overflow::handle_sigsegv
   1: <unknown>
   2: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) as nom::branch::Alt<Input,Output,Error>>::choice
   3: nom::branch::alt::{{closure}}
   4: <F as nom::internal::Parser<I,O,E>>::parse
   5: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) as nom::branch::Alt<Input,Output,Error>>::choice
   6: nom::branch::alt::{{closure}}
   7: <F as nom::internal::Parser<I,O,E>>::parse
   8: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) as nom::branch::Alt<Input,Output,Error>>::choice
   9: nom::branch::alt::{{closure}}
  10: <F as nom::internal::Parser<I,O,E>>::parse
  11: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) as nom::branch::Alt<Input,Output,Error>>::choice
  12: nom::branch::alt::{{closure}}
  13: <F as nom::internal::Parser<I,O,E>>::parse
  14: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T) as nom::branch::Alt<Input,Output,Error>>::choice
  15: nom::branch::alt::{{closure}}
  16: <F as nom::internal::Parser<I,O,E>>::parse
  17: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) as nom::branch::Alt<Input,Output,Error>>::choice
  18: nom::branch::alt::{{closure}}
  19: <F as nom::internal::Parser<I,O,E>>::parse
  20: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U) as nom::branch::Alt<Input,Output,Error>>::choice
  21: nom::branch::alt::{{closure}}
  22: <F as nom::internal::Parser<I,O,E>>::parse
  23: <(A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T) as nom::branch::Alt<Input,Output,Error>>::choice
  24: nom::branch::alt::{{closure}}
  25: sqlformat::tokenizer::get_plain_reserved_token
  26: core::ops::function::FnMut::call_mut
  27: <F as nom::internal::Parser<I,O,E>>::parse
  28: <(A,B,C,D) as nom::branch::Alt<Input,Output,Error>>::choice
  29: nom::branch::alt::{{closure}}
  30: sqlformat::tokenizer::get_reserved_word_token
  31: sqlformat::tokenizer::get_next_token::{{closure}}
  32: core::result::Result<T,E>::or_else
  33: sqlformat::tokenizer::get_next_token
  34: sqlformat::tokenizer::tokenize
  35: sqlformat::format
  36: sqlx_core::logger::QueryLogger::finish
  37: <sqlx_core::logger::QueryLogger as core::ops::drop::Drop>::drop
  38: core::ptr::drop_in_place<sqlx_core::logger::QueryLogger>
  39: sqlx_postgres::connection::executor::<impl sqlx_postgres::connection::PgConnection>::run::{{closure}}::{{closure}}::{{closure}}
  40: <core::pin::Pin<P> as core::future::future::Future>::poll
  41: <futures_util::future::future::fuse::Fuse<Fut> as core::future::future::Future>::poll
  42: futures_util::future::future::FutureExt::poll_unpin
  43: <sqlx_core::ext::async_stream::TryAsyncStream<T> as futures_core::stream::Stream>::poll_next
  44: <core::pin::Pin<P> as futures_core::stream::Stream>::poll_next
  45: <S as futures_core::stream::TryStream>::try_poll_next
  46: futures_util::stream::try_stream::TryStreamExt::try_poll_next_unpin
  47: <futures_util::stream::try_stream::try_next::TryNext<St> as core::future::future::Future>::poll
  48: sqlx_postgres::connection::executor::<impl sqlx_core::executor::Executor for &mut sqlx_postgres::connection::PgConnection>::fetch_optional::{{closure}}
  49: <core::pin::Pin<P> as core::future::future::Future>::poll
  50: <F as futures_core::future::TryFuture>::try_poll
  51: <futures_util::future::try_future::into_future::IntoFuture<Fut> as core::future::future::Future>::poll
  52: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
  53: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
  54: <futures_util::future::try_future::MapOk<Fut,F> as core::future::future::Future>::poll
  55: <F as futures_core::future::TryFuture>::try_poll
  56: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
  57: <futures_util::future::try_future::TryFlatten<Fut1,Fut2> as core::future::future::Future>::poll
  58: <futures_util::future::try_future::AndThen<Fut1,Fut2,F> as core::future::future::Future>::poll
  59: <core::pin::Pin<P> as core::future::future::Future>::poll
  60: sqlx_core::query::Query<DB,A>::fetch_one::{{closure}}
  61: <sea_orm::database::transaction::DatabaseTransaction as sea_orm::database::connection::ConnectionTrait>::query_one::{{closure}}::{{closure}}
  62: <sea_orm::database::transaction::DatabaseTransaction as sea_orm::database::connection::ConnectionTrait>::query_one::{{closure}}
  63: <core::pin::Pin<P> as core::future::future::Future>::poll
  64: sea_orm::executor::select::SelectorRaw<S>::one::{{closure}}
  65: sea_orm::executor::insert::exec_insert_with_returning::{{closure}}
  66: sea_orm::entity::active_model::ActiveModelTrait::insert::{{closure}}
  67: <core::pin::Pin<P> as core::future::future::Future>::poll
  68: siro_api::graphql::schema::teams::pending_team_project::PendingTeamProjectsMutation::accept_create_team_project::{{closure}}::{{closure}}::{{closure}}
  69: <core::pin::Pin<P> as core::future::future::Future>::poll
  70: sea_orm::database::transaction::DatabaseTransaction::run::{{closure}}::{{closure}}
  71: sea_orm::database::transaction::DatabaseTransaction::run::{{closure}}
  72: sea_orm::driver::sqlx_postgres::SqlxPostgresPoolConnection::transaction::{{closure}}::{{closure}}
  73: sea_orm::driver::sqlx_postgres::SqlxPostgresPoolConnection::transaction::{{closure}}
  74: <sea_orm::database::db_connection::DatabaseConnection as sea_orm::database::connection::TransactionTrait>::transaction::{{closure}}::{{closure}}
  75: <sea_orm::database::db_connection::DatabaseConnection as sea_orm::database::connection::TransactionTrait>::transaction::{{closure}}
  76: <core::pin::Pin<P> as core::future::future::Future>::poll
  77: siro_api::graphql::schema::teams::pending_team_project::PendingTeamProjectsMutation::accept_create_team_project::{{closure}}
  78: siro_api::graphql::schema::teams::pending_team_project::_::<impl siro_api::graphql::schema::teams::pending_team_project::PendingTeamProjectsMutation>::__accept_create_team_project_resolver::{{closure}}::{{closure}}
  79: siro_api::graphql::schema::teams::pending_team_project::_::<impl siro_api::graphql::schema::teams::pending_team_project::PendingTeamProjectsMutation>::__accept_create_team_project_resolver::{{closure}}
  80: siro_api::graphql::schema::teams::pending_team_project::_::<impl async_graphql::resolver_utils::container::ContainerType for siro_api::graphql::schema::teams::pending_team_project::PendingTeamProjectsMutation>::resolve_field::{{closure}}
  81: <&T as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  82: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  83: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  84: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  85: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  86: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  87: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  88: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  89: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  90: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  91: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  92: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  93: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  94: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  95: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  96: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  97: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  98: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
  99: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 100: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 101: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 102: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 103: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 104: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 105: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 106: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 107: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 108: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 109: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 110: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 111: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 112: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 113: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 114: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 115: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 116: <async_graphql::types::merged_object::MergedObject<A,B> as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 117: <siro_api::graphql::schema::MutationRoot as async_graphql::resolver_utils::container::ContainerType>::resolve_field::{{closure}}
 118: <core::pin::Pin<P> as core::future::future::Future>::poll
 119: <&mut F as core::future::future::Future>::poll
 120: async_graphql::extensions::NextResolve::run::{{closure}}
 121: <async_graphql::extensions::apollo_tracing::ApolloTracingExtension as async_graphql::extensions::Extension>::resolve::{{closure}}
 122: <core::pin::Pin<P> as core::future::future::Future>::poll
 123: async_graphql::extensions::NextResolve::run::{{closure}}
 124: async_graphql::extensions::Extension::resolve::{{closure}}
 125: <core::pin::Pin<P> as core::future::future::Future>::poll
 126: async_graphql::extensions::NextResolve::run::{{closure}}
 127: async_graphql::extensions::Extension::resolve::{{closure}}
 128: <core::pin::Pin<P> as core::future::future::Future>::poll
 129: async_graphql::extensions::NextResolve::run::{{closure}}
 130: async_graphql::extensions::Extensions::resolve::{{closure}}
 131: async_graphql::resolver_utils::container::Fields::add_set::{{closure}}
 132: <core::pin::Pin<P> as core::future::future::Future>::poll
 133: async_graphql::resolver_utils::container::resolve_container_inner::{{closure}}
 134: async_graphql::resolver_utils::container::resolve_container_serial::{{closure}}
 135: async_graphql::schema::Schema<Query,Mutation,Subscription>::execute_once::{{closure}}
 136: async_graphql::schema::Schema<Query,Mutation,Subscription>::execute::{{closure}}::{{closure}}::{{closure}}::{{closure}}
 137: <core::pin::Pin<P> as core::future::future::Future>::poll
 138: async_graphql::extensions::NextExecute::internal_run::{{closure}}
 139: async_graphql::extensions::NextExecute::run::{{closure}}
 140: <async_graphql::extensions::apollo_tracing::ApolloTracingExtension as async_graphql::extensions::Extension>::execute::{{closure}}
 141: <core::pin::Pin<P> as core::future::future::Future>::poll
 142: async_graphql::extensions::NextExecute::internal_run::{{closure}}
 143: async_graphql::extensions::NextExecute::run::{{closure}}
 144: async_graphql::extensions::Extension::execute::{{closure}}
 145: <core::pin::Pin<P> as core::future::future::Future>::poll
 146: async_graphql::extensions::NextExecute::internal_run::{{closure}}
 147: async_graphql::extensions::NextExecute::run::{{closure}}
 148: async_graphql::extensions::Extension::execute::{{closure}}
 149: <core::pin::Pin<P> as core::future::future::Future>::poll
 150: async_graphql::extensions::NextExecute::internal_run::{{closure}}
 151: async_graphql::extensions::NextExecute::run::{{closure}}
 152: async_graphql::extensions::Extensions::execute::{{closure}}
 153: async_graphql::schema::Schema<Query,Mutation,Subscription>::execute::{{closure}}::{{closure}}
 154: <core::pin::Pin<P> as core::future::future::Future>::poll
 155: <&mut F as core::future::future::Future>::poll
 156: async_graphql::extensions::NextRequest::run::{{closure}}
 157: async_graphql::extensions::Extension::request::{{closure}}
 158: <core::pin::Pin<P> as core::future::future::Future>::poll
 159: async_graphql::extensions::NextRequest::run::{{closure}}
 160: <async_graphql::extensions::analyzer::AnalyzerExtension as async_graphql::extensions::Extension>::request::{{closure}}
 161: <core::pin::Pin<P> as core::future::future::Future>::poll
 162: async_graphql::extensions::NextRequest::run::{{closure}}
 163: async_graphql::extensions::Extension::request::{{closure}}
 164: <core::pin::Pin<P> as core::future::future::Future>::poll
 165: async_graphql::extensions::NextRequest::run::{{closure}}
 166: async_graphql::extensions::Extensions::request::{{closure}}
 167: async_graphql::schema::Schema<Query,Mutation,Subscription>::execute::{{closure}}
 168: siro_api::server::graphql_index::{{closure}}
 169: actix_web::handler::handler_service::{{closure}}::{{closure}}
 170: <core::pin::Pin<P> as core::future::future::Future>::poll
 171: <actix_web::resource::Resource<T> as actix_web::service::HttpServiceFactory>::register::{{closure}}::{{closure}}
 172: <core::pin::Pin<P> as core::future::future::Future>::poll
 173: <actix_cors::middleware::CorsMiddleware<S> as actix_service::Service<actix_web::service::ServiceRequest>>::call::{{closure}}
 174: <core::pin::Pin<P> as core::future::future::Future>::poll
 175: <opentelemetry::trace::context::WithContext<T> as core::future::future::Future>::poll
 176: <futures_util::future::future::map::Map<Fut,F> as core::future::future::Future>::poll
 177: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
 178: <core::pin::Pin<P> as core::future::future::Future>::poll
 179: <actix_service::map_err::MapErrFuture<A,Req,F,E> as core::future::future::Future>::poll
 180: actix_http::h1::dispatcher::InnerDispatcher<T,S,B,X,U>::poll_response
 181: <actix_http::h1::dispatcher::Dispatcher<T,S,B,X,U> as core::future::future::Future>::poll
 182: <actix_http::service::HttpServiceHandlerResponse<T,S,B,X,U> as core::future::future::Future>::poll
 183: <actix_service::and_then::AndThenServiceResponse<A,B,Req> as core::future::future::Future>::poll
 184: <actix_server::service::StreamService<S,I> as actix_service::Service<(actix_server::worker::WorkerCounterGuard,actix_server::socket::MioStream)>>::call::{{closure}}
 185: tokio::runtime::task::core::Core<T,S>::poll::{{closure}}
 186: tokio::runtime::task::core::Core<T,S>::poll
 187: tokio::runtime::task::harness::poll_future::{{closure}}
 188: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
 189: std::panicking::try::do_call
 190: __rust_try
 191: std::panicking::try
 192: std::panic::catch_unwind
 193: tokio::runtime::task::harness::poll_future
 194: tokio::runtime::task::harness::Harness<T,S>::poll_inner
 195: tokio::runtime::task::harness::Harness<T,S>::poll
 196: tokio::runtime::task::raw::poll
 197: tokio::runtime::task::raw::RawTask::poll
 198: tokio::runtime::task::LocalNotified<S>::run
 199: tokio::task::local::LocalSet::tick::{{closure}}
 200: tokio::task::local::LocalSet::tick
 201: <tokio::task::local::RunUntil<T> as core::future::future::Future>::poll::{{closure}}
 202: tokio::task::local::LocalSet::with::{{closure}}
 203: std::thread::local::LocalKey<T>::try_with
 204: std::thread::local::LocalKey<T>::with
 205: tokio::task::local::LocalSet::with
 206: <tokio::task::local::RunUntil<T> as core::future::future::Future>::poll
 207: tokio::task::local::LocalSet::run_until::{{closure}}
 208: <core::pin::Pin<P> as core::future::future::Future>::poll
 209: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}::{{closure}}::{{closure}}
 210: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}::{{closure}}
 211: tokio::runtime::scheduler::current_thread::Context::enter
 212: tokio::runtime::scheduler::current_thread::CoreGuard::block_on::{{closure}}
 213: tokio::runtime::scheduler::current_thread::CoreGuard::enter::{{closure}}
 214: tokio::runtime::context::scoped::Scoped<T>::set
 215: tokio::runtime::context::set_scheduler::{{closure}}
 216: std::thread::local::LocalKey<T>::try_with
 217: std::thread::local::LocalKey<T>::with
 218: tokio::runtime::context::set_scheduler
 219: tokio::runtime::scheduler::current_thread::CoreGuard::enter
 220: tokio::runtime::scheduler::current_thread::CoreGuard::block_on
 221: tokio::runtime::scheduler::current_thread::CurrentThread::block_on::{{closure}}
 222: tokio::runtime::context::runtime::enter_runtime
 223: tokio::runtime::scheduler::current_thread::CurrentThread::block_on
 224: tokio::runtime::runtime::Runtime::block_on
 225: tokio::task::local::LocalSet::block_on
 226: actix_rt::runtime::Runtime::block_on
 227: actix_rt::arbiter::Arbiter::with_tokio_rt::{{closure}}
 228: std::sys_common::backtrace::__rust_begin_short_backtrace
 229: std::thread::Builder::spawn_unchecked_::{{closure}}::{{closure}}
 230: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
 231: std::panicking::try::do_call
 232: __rust_try
 233: std::panicking::try
 234: std::thread::Builder::spawn_unchecked_::{{closure}}
 235: core::ops::function::FnOnce::call_once{{vtable.shim}}
 236: std::sys::pal::unix::thread::Thread::new::thread_start
 237: <unknown>
 238: <unknown>

//

I don't encounter stack overflow in --release, but that should not be the final solution.
Steps to Reproduce the Problem
I'm not quite sure exactly how to reproduce this.
Specifications

Version: 7.0.2
Platform: WSL 2 Arch Linux
Subsystem: N/A
Rust: 1.77
Features enabled: url, chrono, decimal, dataloader, playground, opentelemetry, apollo_tracing, email-validator, apollo_persisted_queries,

I have a similar problem. I managed to get some queries to work with boxing a lot of the structs, but when the query gets more complex I still get the stack overflow (besides boxing the objects queried). So just boxing everything is not a solution...

Try switching off the ApolloTracingExtension, it has a lot of downsides on the performance and response size.
Also, I have concerns about the MergedObject, as it represents a list of schemas, which in turn could be optimized on the library level. As I see, you have a MutationRoot with 36 entities inside. Can you try splitting them into a tree of some kind? Like Merged Root: { L: [18], R: [18] } or even steeper. Does the stack size decreases?
It would be nice to understand each stack frame's size. Check your own Extensions and field resolvers. Are there any long local arrays or fat enums clippy is warning about?
https://github.com/tokio-rs/tokio/pull/5136#issuecomment-1295472247

For people who have the same problem: I tried to solve this by trying to box things and had some success doing so. Simple queries and mutations work. But more complex queries still lead to a stack overflow, often not even in my code.
In release builds (cargo build --release) everything works for me, even for expensive queries.
For development and tests I just gave up and increased the stack size. Instead of using #[tokio::main] I now use the builder:
    #[cfg(not(debug_assertions))]
    let runtime = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap();

    #[cfg(debug_assertions)]
    let runtime = tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .thread_stack_size(3 * 1024 * 1024)
        .build()
        .unwrap();

    runtime.block_on(async {
        let listen_interface = std::env::var("LISTEN").unwrap_or_else(|_| "<IP_ADDRESS>:8000".to_owned());
        print!("\n🚀 GraphiQL IDE: http://{}/graphql\n\n", listen_interface);

        let listener = TcpListener::bind(listen_interface)
            .await
            .expect("could not create listener");

        axum::serve(
            listener,
            make_app(None, None, true)
                .await
                .into_make_service_with_connect_info::<SocketAddr>(),
        )
        .await
        .unwrap();
    });

Integration tests I run with RUST_MIN_STACK=3145728 cargo test --all.
This works for me.

Related issue https://github.com/async-graphql/async-graphql/issues/1516

I am going to work on a feature flag to revert the removal of async_trait since this was clearly a bad move for a lot of people (myself included).

I started to work on it, but the issue really is that the crate trait-variant which should be now the default instead of async-trait is just not up to the task.

Yes since it uses the same traits

@McleanWorkshield I pushed a PR to restore the old behaviour.
If @sunli829 can review / merge then we will be ok


[WIP] RYA-238  Accumulo Geo Temporal Index

Description
Added new index, makes queries with a time and position much faster.
Tests
A bunch
Links
Jira
Checklist

[ ] Code Review
[ ] Squash Commits

People To Reivew
anyone

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-rya-master-with-optionals-pull-requests/555/Build result: FAILURE[...truncated 2.66 MB...][INFO] Apache Rya Web Projects ............................ SKIPPED[INFO] Apache Rya Web Implementation ...................... SKIPPED[INFO] ------------------------------------------------------------------------[INFO] BUILD FAILURE[INFO] ------------------------------------------------------------------------[INFO] Total time: 27:01 min[INFO] Finished at: 2017-11-22T15:34:51+00:00[INFO] Final Memory: 446M/2957M[INFO] ------------------------------------------------------------------------[ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.11:check (check-licenses) on project rya.geo.geomesa: Too many files with unapproved license: 2 See RAT report in: /home/jenkins/jenkins-slave/workspace/incubator-rya-master-with-optionals-pull-requests/extras/rya.geoindexing/geo.geomesa/target/rat.txt -> [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR]   mvn  -rf :rya.geo.geomesachannel stoppedSetting status of 14a4bcb2a0ac4398d532d6b6d3b2efcb3ce3159c to FAILURE with url https://builds.apache.org/job/incubator-rya-master-with-optionals-pull-requests/555/ and message: 'FAILURE 'Using context: Jenkins: clean package -Pgeoindexing

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-rya-master-with-optionals-pull-requests/560/Build result: FAILURE[...truncated 2.70 MB...][INFO] Apache Rya Spark Support ........................... SKIPPED[INFO] Apache Rya Web Projects ............................ SKIPPED[INFO] Apache Rya Web Implementation ...................... SKIPPED[INFO] ------------------------------------------------------------------------[INFO] BUILD FAILURE[INFO] ------------------------------------------------------------------------[INFO] Total time: 30:25 min[INFO] Finished at: 2017-12-04T21:48:10+00:00[INFO] Final Memory: 409M/3265M[INFO] ------------------------------------------------------------------------[ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.11:check (check-licenses) on project rya.geo.geomesa: Too many files with unapproved license: 2 See RAT report in: /home/jenkins/jenkins-slave/workspace/incubator-rya-master-with-optionals-pull-requests/extras/rya.geoindexing/geo.geomesa/target/rat.txt -> [Help 1][ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.[ERROR] Re-run Maven using the -X switch to enable full debug logging.[ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles:[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException[ERROR] [ERROR] After correcting the problems, you can resume the build with the command[ERROR]   mvn  -rf :rya.geo.geomesachannel stoppedSetting status of ab86f49d65dda3b8abef7be1cdda36b62733fd05 to FAILURE with url https://builds.apache.org/job/incubator-rya-master-with-optionals-pull-requests/560/ and message: 'FAILURE 'Using context: Jenkins: clean package -Pgeoindexing


Upgrade sinatra test app to be compatible with integration test frame…

…work

ahh looks like you need to change the expected output of one of your legacy e2e tests. it's expecting ruby app to come from the sinatra app still.


Optuna page done

Hi @Mmozzanica5, I guess it would be better to have a new folder in https://github.com/lhcb-bicocca/ml-helpers called tutorials and add your code (the one in the README.md?) there. See my comments inline.

Closed since documentation was added to ml-helpers.


Conversion Support for VPS inside Virtuozzo Containers

Hi,
As an active user of Plesk, I have noted the instructions specifying that the conversion process is not supported inside containers, including Virtuozzo containers.
Understanding the importance of this limitation, I would like to express a concern shared by numerous users who predominantly utilize VPS servers instead of dedicated (particularly those within Virtuozzo containers).
It would be highly beneficial if there were plans to extend support for the conversion process within Virtuozzo containers. Is there any ongoing discussions or plans regarding this matter?
Many thanks,
Petru

Please see https://github.com/plesk/centos2alma/issues/87

Just saw it, closing as duplicated.
Thanks

@LazariPetru alright, guess you should also comment on my Ticket #87 so Plesk sees there is more demand than only from our side ;-)


Lua hooks (RegisterHook) can now access the original return value

The second function passed to 'RegisterHook' now takes an additional param after the first param if the function has a return value. The param contains the return value pointer and you can use ':get()' to retrieve the value and ':set()' to set it but the return value of the actual Lua function will take precedence over calling 'set'.
Example:
RegisterHook("/Script/Engine.Character:CanJumpInternal", function()
    -- Some code.
end, function(ParamContext, ParamReturnValue)
    -- This value will be the original return value in the case where the pre-hook didn't modify it.
    -- It will be the modification done by the pre-hook otherwise.
    print(string.format("Return Value: %s\n", ParamReturnValue:get()))
end)

This is ready to be merged.


Update WhitePaper German.md

Updating German WP in accordance with the latest changes. Adding translated graphics.

Conflicts with both the Russian and Ukrainian papers. Please review.

Still conflicts to be resolved. Thanks.

Still many conflicts. Might be due to Anton's Pull Request that updated many of these.


Contact form, styling

can you reduce the spacing between the text field titles and the text field?
in the jobs-form, there ist a stange thing with the checkboxes, maybe the last checkbox just moves to the next line?

#in the jobs-form, there ist a stange thing with the checkboxes, maybe the last checkbox just moves to the next line?

had to align them.


How to add Node's VM like functionality using duktape

Hello Team,
I have one node application which I need to port to ductape. This application has module which creates sand-boxing environment using Node's VM module. To communicate between main context and the VM sandbox, EventEmitter inherited (bridge) class has been used. The object of bride class has been created in main context and the reference is passed to VM sandbox context. When sandbox is done with its task, it is able to call the callback function which was registered from main context
I need to port this functionality using duktape engine. I checked the ducktape APIs to figure out how I can implement this.

Create the separate heap for sandbox and for communication do the serialization. But how the event registration and call backing functionality will work here ?
Create separate context with new global : duk_push_thread_new_globalenv(duk_context *ctx);
Here also how do I refer bridge object created in main thread in VM sandbox ?

Can you please suggest better option to implement this requirement in duktape ?

You can check how low.js does it — it is made on top of DukTape.
Files of interest:

https://github.com/neonious/lowjs/blob/master/lib_js/vm.js
https://github.com/neonious/lowjs/blob/master/src/low_native.cpp
https://github.com/neonious/lowjs/blob/master/src/low_native_aux.cpp

@ganeshnikam18 I'll close this now - please let me know if this wasn't resolved.


Update Torii Fuzzing

Description of the Change
Updates fuzzing sources so they're able to compile

For now we just continuing copy-pasting initialization from application.cpp, since it's a straightforward solution. For further refactoring see: IR-142
Each fuzzing target will be fixed per one pr


Decouple api/monitor and api/v1

Merge #880 first
This PR returns extra information inside of rpc.Status, rather than creating an explicit dependency on the main keytransparency types, somewhat simplifying the relationships between the APIs.

Codecov Report

Merging #881 into master will decrease coverage by 0.33%.
The diff coverage is 3.22%.

@@            Coverage Diff             @@
##           master     #881      +/-   ##
==========================================
- Coverage   48.87%   48.54%   -0.34%
==========================================
  Files          34       34
  Lines        2351     2367      +16
==========================================
  Hits         1149     1149
- Misses        998     1014      +16
  Partials      204      204

Impacted Files
Coverage Δ

core/monitor/verify.go
0% <0%> (ø)
:arrow_up:

core/monitorserver/server.go
29.16% <11.11%> (-2.66%)
:arrow_down:

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 6cf15fa...6a49534. Read the comment docs.


Fix exception handling for execution::seq

Looks like they are now failing:

Looks like I didn't fix it, then ;-)

@sithhell I think this can go ahead now.

The remaining failing tests are unrelated.


 We need to figure out where are they coming from.
[ERROR] [1569826119.454300726, 0.856000000]: Ignoring transform for child_frame_id "fcu" from authority "unknown_publisher" because of an invalid quaternion in the transform (0.000000 0.000000 0.000000 0.000000)

I tried a few things:

happens also with older versions of mavros e.g. 0.30.0
doesn't happen on hardware

Hi @mrivi , have you figured out why it happens in software?

No, I didn't investigate further since they aren't creating any issues. We look further in the future.

Figured out where it comes ffrom https://github.com/PX4/Firmware/issues/13182

Fixed https://github.com/PX4/Firmware/pull/13184


POST comment in a card

Posting comment to a card functionality added. Please have a look.

@joelso  Can this please get merged? Would love to have this functionality included.


test determinism for evm tokens analyzer

It's particularly nice for debugging, run comparisons, test writing etc, if the sql statements are ordered deterministically.
Maybe you can sort staleTokens before this for loop? Or probably even better, make getStaleTokens() return ordered results by adding an ORDER BY token_address to the underlying db query.

Originally posted by @mitjat in https://github.com/oasisprotocol/oasis-indexer/pull/344#discussion_r1127038703

currently the "stale" tokens are maintained in an index so they're probably ordered by runtime, token_address. might as well make this explicit. if this later causes tokens at higher addresses to starve, we'll have to come up with something else.


only deploy the specified service mesh's adapter

Reported by @navendu-pottekkat in https://github.com/layer5io/meshery-smi-conformance-action/pull/32
Current behavior
Currently, the action deploys all the adapters regardless of the service mesh being used because the $service_mesh_adapter is not being read correctly in https://github.com/layer5io/meshery-smi-conformance-action/blob/4a1f84c15dae29250caf33ecc96233a3d856562e/meshery.sh#L40
Desired behavior
Only the desired adapter should be added to ~/.meshery/config.yaml while creating the new context so as to deploy only that adapter and prevent bloat.
Further description
There is an error being thrown when the context is being created which I believe is causing the default config file being created.

The issue is with this one line:
mesheryctl system context create new-context --adapters $service_mesh_adapter --platform docker --url http://localhost:9081 --set --yes

And I believe that it may have to do something with passing the service_mesh_adapter variable.
Maybe changing it to --adapters="$service_mesh_adapter" or something like that to make sure that we are not passing any extra arguments there would help.
This line runs fine locally when run as shown below. So the issue I mentioned above may causing this.

What value were you passing in $service_mesh_adapter?

What value were you passing in $service_mesh_adapter?

@leecalcote meshery-service_mesh_name. In accordance with https://github.com/meshery/meshery/blob/master/docker-compose.yaml#L16-L63
(service mesh name here is not SMP protos friendly)


Abstract editor

Let's abstract editor into its own gem, only using markdown. CMS should include a markdown help page, or redirect to Gruber's site.

We're going to use this library. It's almost exactly what I was looking for -- something that is simple and works, but uses syntax highlighting for the plain text markdown.
I can fork and add some features to it eventually, but for now it'll just be plugged in manually (no gem yet).


added dark, grey, and bright classmethods

I added classmethods for default values for dark, grey, and bright time into MoonIlluminationConstraint

Ok, I changed the way that it is written for increased clarity (hopefully)

Looks good, but needs some basic tests.

Tests have been added.

Thanks @kvyh!


test(ingest/snowflake): Fix tests around host_port

Aims to fix CI, which has been failing since https://github.com/datahub-project/datahub/pull/7787. Not sure why, since https://github.com/datahub-project/datahub/pull/7717 is the change that seems to have induced the failure.
Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

@asikowitz these tests shouldn't have broken, since we still have https://github.com/datahub-project/datahub/blob/905d7fed66c058d6114ac1688c2bf9173ba04082/metadata-ingestion/src/datahub/ingestion/source_config/sql/snowflake.py#L105 in the code.

That would make sense but they are definitely failing. Taken from our most recent commit testQuick workflow:
=========================== short test summary info ============================
FAILED tests/unit/test_snowflake_source.py::test_account_id_is_added_when_host_port_is_present - pydantic.error_wrappers.ValidationError: 2 validation errors for SnowflakeV2Config
account_id
  field required (type=value_error.missing)
host_port
  extra fields not permitted (type=value_error.extra)
FAILED tests/unit/test_snowflake_source.py::test_options_contain_connect_args - pydantic.error_wrappers.ValidationError: 2 validation errors for SnowflakeV2Config
account_id
  field required (type=value_error.missing)
host_port
  extra fields not permitted (type=value_error.extra)
FAILED tests/unit/test_snowflake_source.py::test_snowflake_config_with_no_connect_args_returns_base_connect_args - pydantic.error_wrappers.ValidationError: 2 validation errors for SnowflakeV2Config
account_id
  field required (type=value_error.missing)
host_port
  extra fields not permitted (type=value_error.extra)
FAILED tests/unit/test_snowflake_source.py::test_snowflake_config_with_connect_args_overrides_base_connect_args - pydantic.error_wrappers.ValidationError: 2 validation errors for SnowflakeV2Config
account_id
  field required (type=value_error.missing)
host_port
  extra fields not permitted (type=value_error.extra)

Would rather not invest time into looking into this right now

Updated this PR to fix the tests properly


"Installation package is not supported by this processor type" error when running wsl --update

Version
Microsoft Windows [Version 10.0.19044.1620]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>
Distro Version
Ubuntu 20.04
Other Software
No response
Repro Steps

Simply check for updates
Windows Update reports an update for Windows Subsystem for Linux (kernel <IP_ADDRESS>)

Expected Behavior
The installation should go smoothly (I don't think it would pose a problem)
Actual Behavior
The installation halts with error 0x80070661, and doing wsl --update through Command Line as a workaround yields the "Installation package is not supported by this processor type" message
Diagnostic Logs
No response

I have encountered the same problem when am tring to upgrade WSL on my ryzen laptop. (AMD 5800H cpu).

I also have the same issue attemping the update on an intel processor running Windows 11

Seeing the same issue on my own system running Windows 11 Pro.
Version
cmd.exe /c ver
Microsoft Windows [Version 10.0.22000.556]

WSL Version
wsl -l -v
  NAME      STATE           VERSION
* Ubuntu    Stopped         2

Kernel Version
 wsl.exe --status
Default Distribution: Ubuntu
Default Version: 2

Windows Subsystem for Linux was last updated on 2022-03-11
WSL automatic updates are on.

Kernel version: <IP_ADDRESS>

Repro Steps

Run wsl --update as admin in Windows Terminal.

Expected Behavior
WSL is upgraded to the newest version. Currently this is <IP_ADDRESS> according to Windows Update.
Actual Behavior
 wsl --update
Checking for updates...
Downloading updates...
Installing updates...
This installation package is not supported by this processor type. Contact your product vendor.

Diagnostic Logs

got the same problem with my intel processor laptop with Windows 11

same err this morning...
windows update fail 0x80070661

Here's a quick workaround:

download latest WSL2 release from https://github.com/microsoft/WSL/releases/download/0.56.2/Microsoft.WSL_<IP_ADDRESS>_x64_ARM64.msixbundle
rename file to Microsoft.WSL_<IP_ADDRESS>_x64_ARM64.zip
run Expand-Archive Microsoft.WSL_<IP_ADDRESS>_x64_ARM64.zip
change into Microsoft.WSL_<IP_ADDRESS>_x64_ARM64 folder
run Add-AppPackage Microsoft.WSL_<IP_ADDRESS>_x64.misx
run wsl --status to check the upgrade

It should show WSL version: <IP_ADDRESS> This workaround ...worked on my  Win11 notebook!

Same here... wsl is working fine but the update package fails to install.
It fails both trying to update via Windows Update as well as with:
wsl --update

Also experiencing this:
Win 10 19044.1586
Intel Core i7 1165G7

run Add-AppPackage Microsoft.WSL_<IP_ADDRESS>_x64.misx  should be
run Add-AppPackage Microsoft.WSL_<IP_ADDRESS>_x64.msix

I had the same issue. After I updated Windows to release 22581.1 (Beta Insider channel), the WSL kernel update disappeared from windows update, but "wsl --update" worked again and updated WSL from <IP_ADDRESS> to <IP_ADDRESS>.

I installed the workaround, and wsl --update does tell me that I have the latest. However, Windows update is still showing the error Install error - 0x80070661. I'm hoping this will get fixed on the Microsoft side.

Facing the same issue with my Intel processor laptop with Windows 10.

the issue happens today

Same here... wsl is working fine but the update package fails to install. It fails both trying to update via Windows Update as well as with: wsl --update this is what it looks like:
❯ wsl --update Checking for updates... Downloading updates... Installing updates... This installation package is not supported by this processor type. Contact your product vendor.
and on windows update:

Same here.

I see the same errors and waiting for a fix.

Same here. Windows Update error, Windows 11 Stable, Surface Laptop Studio.

Same for me, Windows 11 Stable:

Same issue on Windows 10 pro with AMD R7 5800H processor.

same on Windows 11

same for me !maybe a mistake of microsoft.

Download latest Windows Subsystem for Linux Update - <IP_ADDRESS> https://www.catalog.update.microsoft.com/Search.aspx?q=wsl
Unpuck xxxxxxxx.cab file
Install wsl_update_x64.msi

Download latest Windows Subsystem for Linux Update - <IP_ADDRESS> https://www.catalog.update.microsoft.com/Search.aspx?q=wsl
Unpuck xxxxxxxx.cab file
Install wsl_update_x64.msi

Confirm that workaround is a valid solution!

As @marcorotondi already confirmed, the workaround provided by @Alexey71 works wonders 🙏
Based on this, we can assume that Windows Update is incorrectly trying to install the ARM64 binary on the X64 platform; that's kind of weird since there should be some sort of check in place to make sure that Windows Update only installs updates for that specific Windows architecture 🤔
Anyway, thanks to @Alexey71 and everyone else who gave a workaround 👏
I could close the issue, but I'm going to wait for someone high above us to give some sort of an explanation to what happened 🤨

@pdrgnclvs who can we git blame 😆 - but in all seriousness thank you guys for finding a quick workaround. Happy Friday!

Also seeing this on a Ryzen 7 5800X running Windows 11. Error code 0x80070661 in Windows Update.
wsl --update
Checking for updates...
Downloading updates...
Installing updates...
This installation package is not supported by this processor type. Contact your product vendor.

Can confirm the workaround above took care of it though. Cheers!

The wsl_update_x64.msi from https://www.catalog.update.microsoft.com/Search.aspx?q=wsl has two files inside, the license and a Linux kernel:
PS C:\Catalog\wsl_update_x64> ls

    Directory: C:\Catalog\wsl_update_x64

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         1/31/2022   8:33 PM          19292 FID_LICENSE
-a----         1/31/2022   8:34 PM       43301584 FID_LXSS_KERNEL

The kernel is version is <IP_ADDRESS>-microsoft-standard-WSL2 #1 SMP Wed Jan 26 22:38:54 UTC 2022 It boots fine, but it's an older kernel.

And now it's doing the same thing with version <IP_ADDRESS>, the most recent, meaning that a new version of the kernel is available but still being incorrectly applied architecture-wise 🤔

Thankfully, repeating @Alexey71's workaround, it gets fixed once again 🙏

Download latest Windows Subsystem for Linux Update - <IP_ADDRESS> https://www.catalog.update.microsoft.com/Search.aspx?q=wsl
Unpuck xxxxxxxx.cab file
Install wsl_update_x64.msi

How do you upack? I try at command line Expand-Archive ("Operation stopped"), and when going inside the .cab file i see the msi file but only get option to "Extract" when right-clicking on the msi file but then destination file does not show anything or just don't know where to extract it to (file- not folder) and I don't get any option to simply extract the contents of the .cab file through the windows Explorer..

How do you upack? I try at command line Expand-Archive ("Operation stopped"), and when going inside the .cab file i see the msi file but only get option to "Extract" when right-clicking on the msi file but then destination file does not show anything or just don't know where to extract it to (file- not folder) and I don't get any option to simply extract the contents of the .cab file through the windows Explorer..

Winrar or 7z no problem. U can rename .cab to .zip and open

The update just now worked, and it didn't downgrade my kernel.

And now it's doing the same thing with version <IP_ADDRESS>, the most recent, meaning that a new version of the kernel is available but still being incorrectly applied architecture-wise 🤔

Can't confirm. The new <IP_ADDRESS> has updated successfully for me through Windows Update on both of my systems.

And now it's doing the same thing with version <IP_ADDRESS>, the most recent, meaning that a new version of the kernel is available but still being incorrectly applied architecture-wise 🤔

Can't confirm. The new <IP_ADDRESS> has updated successfully for me through Windows Update on both of my systems.

Because since my last message and now maybe someone at Microsoft fixed the problem on their side 😉

Thank you. I had tried all the renaming and unpacking options on that .cab file and none worked, and tried changing it to .exe file and windows couldn’t run it. When attempting to unpack, it seemed to show a windowsbase file or something. Lost the screen. I’m running Acer Nitro5 with intel cpu, 32gb ram (crucial), windows 11 pro, 1TB +265 gb ssd storage.
BUT!!
Regular windows update just went through and updated it.
Thank you all for your replies.. people are quick on this stuff lol. Love it.
Get Outlook for iOShttps://aka.ms/o0ukef

From: Dennis Martin Herbers @.>
Sent: Friday, March 25, 2022 10:35:33 AM
To: microsoft/WSL @.>
Cc: eL Squaz @.>; Comment @.>
Subject: Re: [microsoft/WSL] "Installation package is not supported by this processor type" error when running wsl --update (Issue #8184)
And now it's doing the same thing with version <IP_ADDRESS>, the most recent, meaning that a new version of the kernel is available but still being incorrectly applied architecture-wise 🤔
Can't confirm. The new <IP_ADDRESS> has updated successfully for me through Windows Update on both of my systems.
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/WSL/issues/8184#issuecomment-1079252105, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AX52WBZDWYFCRTRLOF5BJVTVBX2OLANCNFSM5RSUJMUA.
You are receiving this because you commented.Message ID: @.***>

I uninstall Windows Subsystem for Linux Update
And try wsl --update. No error, MS fixed poblem

It seems the issue as been corrected. I just refresh windows update and it installed without a issue. I had the same issue couple of hours ego, I didnt apply the workaround, waited for Microsoft fix, so it arrived it seems.
(win 10 10.0.19044.1620)

It seems the bug in the WSL update as been corrected. I just refreshed windows update and the update been downloaded and installed without a problem.
I had the same issue couple of hours ago, I didn't apply the workaround, waited for Microsoft official fix, so it arrived it seems.
(win 10 10.0.19044.1620)

Yes, it's been fixed since around 5PM-6PM (GMT) so it shouldn't pose a problem again 😉

/dupe


release snaps not available for standard install at snapcraft.io

This issue pertains to the following package(s):

[X] GraphQL Playground - Electron App
[ ] GraphQL Playground HTML
[ ] GraphQL Playground
[ ] GraphQL Playground Express Middleware
[ ] GraphQL Playground Hapi Middleware
[ ] GraphQL Playground Koa Middleware
[ ] GraphQL Playground Lambda Middleware

What OS and OS version are you experiencing the issue(s) on?
all
What version of graphql-playground(-electron/-middleware) are you experiencing the issue(s) on?
1.8.2
What is the expected behavior?
release snap is available @ snapcraft for standard snap install
What is the actual behavior?
no snap is published
What steps may we take to reproduce the behavior?
snap search graphql
resolution similar to:
https://github.com/skevy/graphiql-app/pull/105

Hey, thanks for your issue, but currently there is no easy way to do it automatically, so we are waiting for https://github.com/electron-userland/electron-builder/issues/3187 or somebody to implement it. Sorry for your troubles.

@huv1k i see that this blocking task is closed now. But I can't find playground on snapcraft. What need to be done to send snaps that exists in releases on snapcraft?


This plugin generated a warning from the characteristic

[3/22/2021, 11:36:59 AM] [homebridge-fritz-platform] This plugin generated a warning from the characteristic 'Download': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.
[3/22/2021, 11:36:59 AM] [homebridge-fritz-platform] This plugin generated a warning from the characteristic 'Upload': characteristic value expected valid finite number and received "NaN" (number). See https://git.io/JtMGR for more info.

Pls deactivate „Broadband“  in config
restart homebridge
Be sure hat Download/Uplod characteristics are removed
activate broadband again in config
Restart homebridge


Added optional insert animation builder for AnimatedScrollView

Follows https://github.com/flutter/flutter/pull/138376 (sorry I had some VCS problem)
This PR adds the ability to AnimatedScrollView, AnimatedGrid and AnimatedList to add a custom insert animation while inserting an element. This is only done by providing an optional itemBuilder which will be preferred over the default itemBuilder, that is provided by creating the Widget.
closes https://github.com/flutter/flutter/issues/100418
There is no breaking change, however I did write 4 new tests to ensure that this feature is not removed by accident. I did not modify any existing tests.
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I signed the CLA.
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] All existing and new tests are passing.

The API already supports insert animations.
I am confused. Where? Yes, insert animations are supported by default, but I can't change them after I created the ScrollView, can I? With this PR I can customize the insert animation for every item I insert, they can differ how ever you want.

You can insert an item at any time, and define the animation in the AnimatedItemBuilder.

This is only done by providing an optional itemBuilder which will be preferred over the default itemBuilder

How is the default builder insufficient? This is what I still do not understand from the earlier PR. Items are built on demand. If it is not in the list initially, it will not be built until it is inserted. The animation is defined in the item builder, and is called to run when the item is inserted.
To help us understand the issue here, can you share a code sample of an animated list where a certain behavior cannot be achieved with the current API?

Similar to the test this is how it could be:
Basically you want the default (here SizeTransition) to animate the items when the state is initialized. Then you can add two kinds of items, the one kind slides in from the left, the other one slides in from the right.
import 'package:flutter/material.dart';

void main() {
  runApp(
    const MaterialApp(
      home: MyHomePage(),
    ),
  );
}

class MyHomePage extends StatefulWidget {
  const MyHomePage({super.key});

  @override
  State<MyHomePage> createState() => _MyHomePageState();
}

List<String> _list = [];

class _MyHomePageState extends State<MyHomePage> {
  final GlobalKey<AnimatedListState> _listKey = GlobalKey<AnimatedListState>();

  insertSlideFromLeft() {
    _list.add("Item ${_list.length}");
    _listKey.currentState!.insertItem(
      _list.length - 1
      builder: (context, index, animation) {
        return SlideTransition(
          position: Tween<Offset>(
            begin: const Offset(-1, 0),
            end: const Offset(0, 0),
          ).animate(animation),
          child: ListItem(index: index),
        );
      },
    );
  }

  insertSlideFromRight() {
    _list.add("Item ${_list.length}");
    _listKey.currentState!.insertItem(
      _list.length - 1,
      builder: (context, index, animation) {
        return SlideTransition(
          position: Tween<Offset>(
            begin: const Offset(1, 0),
            end: const Offset(0, 0),
          ).animate(animation),
          child: ListItem(index: index),
        );
      },
    );
  }

  @override
  void initState() {
    super.initState();

    _list.add('Item 0');
    WidgetsBinding.instance.addPostFrameCallback((_) {
      _listKey.currentState!.insertItem(0);
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        actions: [
          IconButton(
            icon: const Icon(Icons.add_circle_outline),
            onPressed: () => insertSlideFromLeft(),
          ),
          Expanded(child: Container()),
          IconButton(
            icon: const Icon(Icons.add_circle_outlined),
            onPressed: () => insertSlideFromRight(),
          ),
        ],
      ),
      body: AnimatedList(
        key: _listKey,
        initialItemCount: 0,
        itemBuilder: (context, index, animation) {
          return SizeTransition(
            sizeFactor: animation,
            child: ListItem(index: index),
          );
        },
      ),
    );
  }
}

class ListItem extends StatelessWidget {
  const ListItem({super.key, required this.index});

  final int index;

  @override
  Widget build(BuildContext context) {
    return SizedBox(
      height: 100,
      child: Card(
        color: Colors.primaries[index % Colors.primaries.length],
        child: Center(
          child: Text(_list[index], style: Theme.of(context).textTheme.titleLarge),
        ),
      ),
    );
  }
}

Thanks for providing a sample!
It is possible to achieve that with the current API using the itemBuilder.
Having multiple builders in that sample with all the code duplication makes it hard to tell what is being built and what will or won't be in the list. For these reasons, I feel like this is not an acceptable change to make to the API.
In your own code, you could create an extension SomeExtension on AnimatedItemBuilder to add custom functionality if you like. :)

Sorry, maybe am I missing something but I don't quite get how this should be implemented with an extension on AnimatedItemBuilder. I can't change the actual behaviour of itemBuilder within the AnimatedScrollView, can I?
I guess it could be possible to build a workaround, however it would be quite an awful solution. You must keep track of the items you are inserting in addition to the items itself (more space needed) and distinct between the many different insertAnimations you want to show. You also you need to complicate your itemBuilder, because must check the item your currently building with your list of the inserted items to show a different builder when its needed. Moreover it would be complicated to determine if the item has finished inserting and removing it from your list.
I think the approach in this PR does not very complicate the API. It uses the _ActiveItem system to keep track of the different animations that you would have to do yourself as described above. It does that exact the same as AnimatedRemovedItemBuilder, which is already defined.

I understand you feel strongly about the change, and that you have invested time in working on this. I don't feel that I will change my mind based on the discussions we have had here and in the other PR.  You can certainly seek another reviewer if you would like in the discord. For now, I do not feel we can accept this change.

(triage): I am closing this based on the previous comment.


Update Cargo.toml remove www

the web site redirects anyway

Thank you for the insight.

You are welcome. I am building the rust digger in order to catch such small (and some bigger) things that can be improved.


Deployed at live URL

Deployment: 32%
Satisfies all of the preceding acceptance criteria plus the following:
Application deployed at live URL.

https://shockeyj9.github.io/horiseon-seo-01challenge/


"unable to create impersonator account: error getting service account token: serviceaccounts "cattle-impersonation-system/cattle-impersonation-user-dxx4g" not found - Error seen for Monitoring and Istio v1 charts and when using downloaded kubeconfig

Rancher Server Setup

Rancher version: 2.5.9 -> 2.6.0-rc2 upgrade
Installation option (Docker install/Helm Chart):

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): helm install

Information about the Cluster

Kubernetes version:
Cluster Type (Local/Downstream): downsteram

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider):

Describe the bug

when a user is logged in as admin, all monitoring v1 (v0.2.2) links are not working.
To Reproduce

deploy rancher server v2.5.9
on a downstream cluster, install monitoring (latest version, v0.2.2)

grant a standard user permissions to this cluster i.e. cluster owner before the upgrade (see additional context)
verify that prometheus/grafana links are working

upgrade rancher to v2.6.0-rc2

Result
"status":500,"statusText":"","data":"unable to create impersonator account: error getting service account token: serviceaccounts \"cattle-impersonation-system/cattle-impersonation-user-dxx4g\" not found from both prometheus and grafana.
Expected Result

monitoring v1 should continue to work after an upgrade
Screenshots

Additional context

as a standard user that was created + added to the cluster before the upgrade, I am able to access monitoring v1 apps (prom, grafana) after the upgrade.

I see the same issue while accessing istio jaeger traces and kiali when logged in as admin.

Created a downstream cluster on rancher v2.5.9 as a standard user
installed istio v1.5.901 from cluster --> tools
jaeger traces and kiali  work fine
Upgrade rancher server to v2.6.0-rc2
Access the kiali and jaeger traces as standard user works fine.
Access the kiali and jaeger traces as an admin errors out:

unable to create impersonator account: error getting service account token: serviceaccounts "cattle-impersonation-system/cattle-impersonation-user-dxx4g" not found

@slickwarren @anupama2501 I have not been able to reproduce this, following the upgrade scenarios for both monitoring and istio. Is there any other information about your environments that might be important that you could share? Is this 100% reproducible, or does it only happen sometimes? Is the local cluster k3s, rke, rke2, what version? Is the downstream cluster imported or created, what kind is it?

Moving to test as we need more info from QA here.

Setup provided to @cmurphy in an offline conversation.

I was never able to reproduce this myself, but we've merged a change that will hopefully address the issue. If it doesn't, we also added trace logging so that if the problem is seen again, we can get more information about it.

on v2.5.9 using HA setup for rancher:

provision a downstream cluster (k8s 1.20.9, 3 wk, 1 cp, 1 etcd node)
install monitoring v2 (14.5.100) as a standard user on the cluster
follow the P0 use case for monitoring v2 using alerting-drivers as the notifier
upgrade the cluster to v2.6-head (f811996)
login as admin, and try to access prometheus/grafana

On an upgrade from 2.5.9 to v2.6-head (f811996) HA setup

In the cluster where the issue is seen for monitoring an istio, set  kubeconfig-generate-token = False
Download kubeconfig and access cluster using this kubeconfig
User will be propted to login
After which user sees error: Error from server (InternalError): an error on the server ("unable to create impersonator account: error setting up impersonation for user user-h7dqq: failed to get secret for service account: cattle-impersonation-system/cattle-impersonation-user-h7dqq, error: timed out waiting for the condition") has prevented the request from succeeding

Understanding the issue and PR fix:
I reviewed the PR - the commit message explains the change that resolved this issue:

When the cluster context is set for the proxy server at initialization,
it doesn't always refresh when a new request comes in. This can cause
the cache to become stale and the proxy server handler can fail to
fetch service accounts from it even though they exist in the downstream
cluster. This change pushes the cluster context getter down to the
request handling layer instead of the server creation layer so that it
is refreshed on every request.

I also synced with Colleen to ensure I understand the change. Paraphrasing from what she mentioned to me:
Basically, the problem we were seeing here was that if you created a cluster as a standard user then upgraded Rancher and then tried to access the cluster as the admin user, the mechanism for user impersonation would correctly dynamically create an impersonation service account for the admin user in the cluster, but the cached list of service accounts was not being updated. Basically this causes a stale cache. The object that holds the cache was only being created once at initialization and was NOT getting refreshed when requests were made later, so the code was modified so that this should refresh correctly upon each request.
When testing, I can deploy system charts like Istio and monitoring as mentioned prior. This is one way to test that the issue is fixed. We'll also check that we can log in with kubectl/kubeconfig as this is another way to test effectively the same thing.
My checks PASSED
Reproduction Steps:

Not required. The issue has been reproduced several times by QA - each repro being 100% successful each time before the change (issue was not intermittent).
Validation Environment:

Rancher version: 2.5.9 to v2.6-head b43e4d955 8/24/21
Rancher cluster type: HA, RKE v1.2.11 (this version is recommended for 2.5.9)
Helm version: v3.3.4
Cert Manager version: v1.0.4
Certs: Self-signed
Install command: (Installed via QA Jenkins ha-deploy job)
Downstream cluster type: rke1 (rancher-provisioned with DO node driver)
Downstream K8s version: v1.20.9
Downstream Notes: Created one cluster with admin user and one with standard user. The standard user created cluster should be accessible by the admin user post upgrade now when testing.
Validation steps:

For each downstream cluster created, create with 1 node with the etcd role, 1 node with the control plane role, 3 nodes with the worker role. These downstream clusters I created were with the DO node driver, 2vcpu 4gb for each node.

Install Rancher HA 2.5.9. Create a standard user. Create 1 cluster as the admin user. Create 1 cluster as the standard user.
The admin cluster should have the standard user added as a cluster owner after cluster creation.

As the standard user, deploy monitoring and istio to the two clusters. Monitoring 0.2.2. Istio 1.5.901.
Ensure the standard user can access monitoring grafana and istio links (kiali, jaeger, grafana, prometheus) (to ensure this works before upgrade).

Upgrade HA Rancher to v2.6-head b43e4d955 I did this in QA Jenkins with the ha-upgrade job

Log in as the ADMIN user, ensure the user is able to view details for both clusters. I see monitoring is working. Ensure the user is able to access Monitoring grafana. Ensure the user is able to access Istio links (kiali, jaeger). This works without any issues.
NOTE: There is an error attempting to access Jaeger UI, but this appears to be unrelated to this specific issue.

A bug will be filed for this separate issue. (To be linked here once issue is created)

Go to Global Settings, set kubeconfig-generate-token = false

Attempt to access kubectl client in the browser for both clusters. This works now. I am able to get nodes, list pods, etc.

Additional Info:

Note: Needs a check on one more step again - for the kubectl test we need to actually download the kubeconfig and try to utilize it remotely, NOT within the dashboard UI shell.

Can we expect this fix in 2.6.1? I am getting the same errors in my 2.6.0 cluster.

@andrew-landsverk-win , this should be fixed in 2.6.0 as the issue got validated and closed, see this comment: https://github.com/rancher/rancher/issues/34187#issuecomment-904809285.
If the issue is reproducible for you, could you please share logs and describe your setup?

I get this error "sometimes" when doing a helm 3.6.2 deploy of an app after using the rancher-cli2 to login to my cluster.  It doesn't affect my 2.5.x cluster, only my 2.6.0 cluster. Which container do you want logs from? :)

@andrew-landsverk-win , somehow I've read it as if you have seen these errors in some logs which is not the case.
Do I understand it right that you're installing a custom application using helm install and this error is returned directly by helm install? If that's the case, full (verbose) output of it could be helpful to understand if it's this exact issue or something else.

Yes, helm fails randomly with the following errors, sometimes others I think? To be complete, we run helm from within a docker container from a different server.
error: unable to recognize "/tmp/kubectl_replace_486731274/resource.stdin": an error on the server ("unable to create impersonator account: error setting up impersonation for user u-8j72f: Operation cannot be fulfilled on clusterroles.rbac.authorization.k8s.io \"cattle-impersonation-u-8j72f\": the object has been modified; please apply your changes to the latest version and try again") has prevented the request from succeeding

Error: uninstall: Release not loaded: katana-api-dev: query: failed to query with labels: an error on the server ("unable to create impersonator account: error setting up impersonation for user u-8j72f: Operation cannot be fulfilled on clusterroles.rbac.authorization.k8s.io \"cattle-impersonation-u-8j72f\": the object has been modified; please apply your changes to the latest version and try again") has prevented the request from succeeding (get secrets)

@andrew-landsverk-win , thank you additional details. At a glance this seems to be a separate issue, albeit with a very similar error message. I've created a separate issue https://github.com/rancher/rancher/issues/34671 that we will work on. I would appreciate it if you could add any extra information on your environment or reproduction steps (e.g. helm charts being installed) there.


feat(forge install): add @tag= @branch= @commit= specific refs

Motivation
Closes #5996
Right now is hard to determine what @ is used to delimiter (if org, ref, etc.)
Introduce @tag= @branch= @commit= to specify ref type (and be able to handle / in tag / branch name without changing current behavior)

Solution

In favor of the proposed UX, few small notes


Phase II: Add 3D RF field map

Similar to a solenoid. However, the relevance of this feature is questionable.

Need to extract the required harmonic, and store its coordinates. Phase I - fundamental for TM01 (Ez,Er,Hphi). Phase II - any harmonic, and default mode (?)

The fields must be normalized!

I think that this is not relevant to any observable future plans, and is not really needed.


v2.2.0: Added vercel/og for social preview and refactored projects page

v2.2.0

[x] Remove chrome-aws-lambda and puppeteer-core for @vercel/og. closes #43
[x] Dynamic social preview for non-blog pages.
[ ] Refactor Project pages. closes #44

Added

Added @vercel/og for effecient social preview image generation instead of using chrome-aws-lambda and puppeteer-core

Changed

Bumps notion-compat from 6.12.10 to 6.13.11.
Bumps react-notion-x from 6.12.10 to 6.13.10.
Bumps next from 12.2.5 to 12.3.1.

Removed

Removed chrome-aws-lambda
Removed puppeteer-core

Bumps react-icons from 4.4.0 to 4.6.0.


Invalid Generic Instantiation

OS: [iOS]
Device: [iPhone 11 simulator]
Sdk vervion: [iOS 14.3]
VS for Mac 8.8.5 (build 18)
Xamarin.Forms: [<IP_ADDRESS>4]

Bug: Invalid Instantiation of the LazyView for the tabs in the TabHostView object.
Steps to reproduce the behavior:

Go to https://github.com/cdeck95/BestBet
Clone the repo
Launch the iOS project
See error

See exception/error screenshot below:

See the app.cs file & XAML files here:

If there is anything else you need to know, please let me know.

Hi!
LazyView takes as parameter types that inherit from View not ContentPage :)

Hi!
LazyView takes as parameter types that inherit from View not ContentPage :)

Hi!
LazyView takes as parameter types that inherit from View not ContentPage.
Otherwise I guess I called it LazyPage :)

Thank you for your quick reply! Now that you say that, I did try to change it to ContentView, but got an error that all my variables and "initantiatecompoment() methods were invalid. Let me get a screenshot.

Hi!
LazyView takes as parameter types that inherit from View not ContentPage.
Otherwise I guess I called it LazyPage :)

Thank you for your quick reply! Now that you say that, I did try to change it to ContentView, but got an error that all my variables and "initantiatecompoment() methods were invalid. Let me get a screenshot.

@roubachof see screenshot. Do you know why this might be happening? I have tried everything I can think of, but I know its something simple.

@roubachof see screenshot. Do you know why this might be happening? I have tried everything I can think of, but I know its something simple.

@roubachof I do not want to create a whole new issue for this, but was wondering if you could help. I cannot seem to get my tabs to appear in the lazyview. The page functioned 100% properly before I switched it to appear in a lazyview for the tabs, so I know it is a mistake on my end for the implementation of the lazyview and viewswitcher.
I added a label to appear called "main page" in the grid row to make sure it wasn't a grid issue. The lazyview just appears to be empty.
Simulator Screenshot:

XAML Code for the LazyView Page:

@roubachof I do not want to create a whole new issue for this, but was wondering if you could help. I cannot seem to get my tabs to appear in the lazyview. The page functioned 100% properly before I switched it to appear in a lazyview for the tabs, so I know it is a mistake on my end for the implementation of the lazyview and viewswitcher.
I added a label to appear called "main page" in the grid row to make sure it wasn't a grid issue. The lazyview just appears to be empty.
Simulator Screenshot:

XAML Code for the LazyView Page:


fix issue_6269

What is the purpose of the change
fix #6269
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #6271 into master will decrease coverage by 0.00%.
The diff coverage is 100.00%.

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