bug: eas preview build instantly crashes on launch

Provide environment information
System:
    OS: macOS 13.0
    CPU: (8) arm64 Apple M1
    Memory: 189.45 MB / 8.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 19.6.0 - /opt/homebrew/bin/node
    npm: 9.4.0 - /opt/homebrew/bin/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman

Describe the bug
On a fresh install of create-t3-turbo, eas build -p ios --profile preview creates and installs a build into iOS Simulator but crashes instantly. Running turbo run dev --filter=expo successfully launches the app.
Expected: App to launch successfully
Link to reproduction
https://github.com/t3-oss/create-t3-turbo
To reproduce

Clone t3-oss/create-t3-turbo then follow installation process
Using EAS, run eas build -p ios --profile preview then wait to finish
Select yes upon prompt "Install and run the iOS build on a simulator? … yes"
App is installed and launched on the selected simulator
App crashes immediately; Same happens when re-opening the app (like in the video below)

Additional information
https://user-images.githubusercontent.com/12537973/225820569-2a6ec6f3-8a05-4eca-ad33-86d74250b6bd.mov

Error logs from ~/Library/Logs/DiagnosticReports/createt3turbo-2023-03-17**.ips
{"app_name":"createt3turbo","timestamp":"2023-03-17 13:28:18.00 +0800","app_version":"1.0.0","slice_uuid":"f79f2b68-4188-3ab0-9b21-7cc999da15d4","build_version":"1","platform":7,"bundleID":"your.bundle.identifier","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 13.0 (22A380)","roots_installed":0,"name":"createt3turbo","incident_id":"6A9C1542-6F4E-4FE9-B2A6-BCB0A3CA6CF7"}
{
  "uptime" : 35000,
  "procRole" : "Foreground",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "MacBookAir10,1",
  "coalitionID" : 24711,
  "osVersion" : {
    "train" : "macOS 13.0",
    "build" : "22A380",
    "releaseType" : "User"
  },
  "captureTime" : "2023-03-17 13:28:16.7099 +0800",
  "incident" : "6A9C1542-6F4E-4FE9-B2A6-BCB0A3CA6CF7",
  "pid" : 64234,
  "translated" : false,
  "cpuType" : "ARM-64",
  "roots_installed" : 0,
  "bug_type" : "309",
  "procLaunch" : "2023-03-17 13:28:15.9476 +0800",
  "procStartAbsTime" :<PHONE_NUMBER>29,
  "procExitAbsTime" :<PHONE_NUMBER>12,
  "procName" : "createt3turbo",
  "procPath" : "\/Users\/USER\/Library\/Developer\/CoreSimulator\/Devices\/99599CC0-CF2B-46D8-9766-DB593EED4EC2\/data\/Containers\/Bundle\/Application\/7F7E1AC0-B6A7-4AD2-83D9-8E8095D2BA28\/createt3turbo.app\/createt3turbo",
  "bundleInfo" : {"CFBundleShortVersionString":"1.0.0","CFBundleVersion":"1","CFBundleIdentifier":"your.bundle.identifier"},
  "storeInfo" : {"deviceIdentifierForVendor":"8DCB6EF4-5811-5212-AA86-BADDB3BF6E99","thirdParty":true},
  "parentProc" : "launchd_sim",
  "parentPid" : 54301,
  "coalitionName" : "com.apple.CoreSimulator.SimDevice.99599CC0-CF2B-46D8-9766-DB593EED4EC2",
  "crashReporterKey" : "7EC063EE-E764-C659-3CAD-B450F03A38C4",
  "responsiblePid" : 673,
  "responsibleProc" : "SimulatorTrampoline",
  "wakeTime" : 5631,
  "sleepWakeUUID" : "46720C36-E7CF-455F-A94E-5CF3700453DA",
  "sip" : "enabled",
  "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"},
  "ktriageinfo" : "VM - pmap_enter retried due to resource shortage\n",
  "asiBacktraces" : ["0   CoreFoundation                      0x00000001803f3d70 __exceptionPreprocess + 236\n1   libobjc.A.dylib                     0x000000018019814c objc_exception_throw + 56\n2   createt3turbo                       0x00000001005f2000 RCTFormatError + 0\n3   createt3turbo                       0x0000000100664014 -[RCTExceptionsManager reportFatal:stack:exceptionId:extraDataAsJSON:] + 476\n4   createt3turbo                       0x0000000100664858 -[RCTExceptionsManager reportException:] + 1292\n5   CoreFoundation                      0x00000001803fa230 __invoking___ + 144\n6   CoreFoundation                      0x00000001803f7754 -[NSInvocation invoke] + 300\n7   CoreFoundation                      0x00000001803f7a14 -[NSInvocation invokeWithTarget:] + 76\n8   createt3turbo                       0x000000010062166c -[RCTModuleMethod invokeWithBridge:module:arguments:] + 388\n9   createt3turbo                       0x0000000100623850 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicEiN12_GLOBAL__N_117SchedulingContextE + 452\n10  createt3turbo                       0x00000001006234d8 ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 112\n11  libdispatch.dylib                   0x000000018010d244 _dispatch_call_block_and_release + 24\n12  libdispatch.dylib                   0x000000018010ea98 _dispatch_client_callout + 16\n13  libdispatch.dylib                   0x0000000180115acc _dispatch_lane_serial_drain + 652\n14  libdispatch.dylib                   0x0000000180116648 _dispatch_lane_invoke + 400\n15  libdispatch.dylib                   0x0000000180120e10 _dispatch_workloop_worker_thread + 736\n16  libsystem_pthread.dylib             0x00000001cc0af8fc _pthread_wqthread + 284\n17  libsystem_pthread.dylib             0x00000001cc0ae6c0 start_wqthread + 8"],
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "lastExceptionBacktrace" : [{"imageOffset":1146204,"symbol":"__exceptionPreprocess","symbolLocation":216,"imageIndex":1},{"imageOffset":139596,"symbol":"objc_exception_throw","symbolLocation":56,"imageIndex":10},{"imageOffset":811008,"symbol":"RCTFormatError","symbolLocation":0,"imageIndex":4},{"imageOffset":1277972,"symbol":"-[RCTExceptionsManager reportFatal:stack:exceptionId:extraDataAsJSON:]","symbolLocation":476,"imageIndex":4},{"imageOffset":1280088,"symbol":"-[RCTExceptionsManager reportException:]","symbolLocation":1292,"imageIndex":4},{"imageOffset":1172016,"symbol":"__invoking___","symbolLocation":144,"imageIndex":1},{"imageOffset":1161044,"symbol":"-[NSInvocation invoke]","symbolLocation":300,"imageIndex":1},{"imageOffset":1161748,"symbol":"-[NSInvocation invokeWithTarget:]","symbolLocation":76,"imageIndex":1},{"imageOffset":1005164,"symbol":"-[RCTModuleMethod invokeWithBridge:module:arguments:]","symbolLocation":388,"imageIndex":4},{"imageOffset":1013840,"symbol":"facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext)","symbolLocation":452,"imageIndex":4},{"imageOffset":1012952,"symbol":"invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int)","symbolLocation":112,"imageIndex":4},{"imageOffset":8772,"symbol":"_dispatch_call_block_and_release","symbolLocation":24,"imageIndex":11},{"imageOffset":15000,"symbol":"_dispatch_client_callout","symbolLocation":16,"imageIndex":11},{"imageOffset":43724,"symbol":"_dispatch_lane_serial_drain","symbolLocation":652,"imageIndex":11},{"imageOffset":46664,"symbol":"_dispatch_lane_invoke","symbolLocation":400,"imageIndex":11},{"imageOffset":89616,"symbol":"_dispatch_workloop_worker_thread","symbolLocation":736,"imageIndex":11},{"imageOffset":14588,"symbol":"_pthread_wqthread","symbolLocation":284,"imageIndex":7},{"imageOffset":9920,"symbol":"start_wqthread","symbolLocation":8,"imageIndex":7}],
  "faultingThread" : 3,
  "threads" : [{"id":561515,"queue":"com.apple.main-thread","frames":[{"imageOffset":4876,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":0},{"imageOffset":74092,"symbol":"mach_msg2_internal","symbolLocation":76,"imageIndex":0},{"imageOffset":38156,"symbol":"mach_msg_overwrite","symbolLocation":536,"imageIndex":0},{"imageOffset":5756,"symbol":"mach_msg","symbolLocation":20,"imageIndex":0},{"imageOffset":546668,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":368,"imageIndex":1},{"imageOffset":523128,"symbol":"__CFRunLoopRun","symbolLocation":1096,"imageIndex":1},{"imageOffset":520728,"symbol":"CFRunLoopRunSpecific","symbolLocation":572,"imageIndex":1},{"imageOffset":13836,"symbol":"GSEventRunModal","symbolLocation":160,"imageIndex":2},{"imageOffset":12638872,"symbol":"-[UIApplication _run]","symbolLocation":992,"imageIndex":3},{"imageOffset":12658228,"symbol":"UIApplicationMain","symbolLocation":112,"imageIndex":3},{"imageOffset":10668,"symbol":"main","symbolLocation":80,"imageIndex":4},{"imageOffset":7384,"symbol":"start_sim","symbolLocation":20,"imageIndex":5},{"imageOffset":24144,"symbol":"start","symbolLocation":2544,"imageIndex":6}]},{"id":561532,"frames":[{"imageOffset":9912,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":7}]},{"id":561533,"frames":[{"imageOffset":9912,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":7}]},{"triggered":true,"id":561534,"threadState":{"x":[{"value":0},{"value":0},{"value":0},{"value":0},{"value":6444822577},{"value":6168192016},{"value":110},{"value":18446744069414586112},{"value":6168195072},{"value":4432940169323021183},{"value":512},{"value":11},{"value":0},{"value":736333824},{"value":16},{"value":0},{"value":328},{"value":2},{"value":0},{"value":6},{"value":6168195072},{"value":4355},{"value":6168195296},{"value":4351},{"value":0},{"value":4},{"value":0},{"value":0},{"value":105553146947712}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7718253032},"cpsr":{"value":1073745920},"fp":{"value":6168191872},"sp":{"value":6168191840},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":7717904672,"matchesCrashFrame":1},"far":{"value":5703288144}},"queue":"com.facebook.react.ExceptionsManagerQueue","frames":[{"imageOffset":37152,"symbol":"__pthread_kill","symbolLocation":8,"imageIndex":0},{"imageOffset":29160,"symbol":"pthread_kill","symbolLocation":256,"imageIndex":7},{"imageOffset":480244,"symbol":"abort","symbolLocation":124,"imageIndex":8},{"imageOffset":69300,"symbol":"abort_message","symbolLocation":128,"imageIndex":9},{"imageOffset":5740,"symbol":"demangling_terminate_handler()","symbolLocation":300,"imageIndex":9},{"imageOffset":20128,"symbol":"_objc_terminate()","symbolLocation":124,"imageIndex":10},{"imageOffset":66404,"symbol":"std::__terminate(void (*)())","symbolLocation":16,"imageIndex":9},{"imageOffset":66316,"symbol":"std::terminate()","symbolLocation":60,"imageIndex":9},{"imageOffset":15020,"symbol":"_dispatch_client_callout","symbolLocation":36,"imageIndex":11},{"imageOffset":43724,"symbol":"_dispatch_lane_serial_drain","symbolLocation":652,"imageIndex":11},{"imageOffset":46664,"symbol":"_dispatch_lane_invoke","symbolLocation":400,"imageIndex":11},{"imageOffset":89616,"symbol":"_dispatch_workloop_worker_thread","symbolLocation":736,"imageIndex":11},{"imageOffset":14588,"symbol":"_pthread_wqthread","symbolLocation":284,"imageIndex":7},{"imageOffset":9920,"symbol":"start_wqthread","symbolLocation":8,"imageIndex":7}]},{"id":561535,"name":"com.apple.uikit.eventfetch-thread","frames":[{"imageOffset":4876,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":0},{"imageOffset":74092,"symbol":"mach_msg2_internal","symbolLocation":76,"imageIndex":0},{"imageOffset":38156,"symbol":"mach_msg_overwrite","symbolLocation":536,"imageIndex":0},{"imageOffset":5756,"symbol":"mach_msg","symbolLocation":20,"imageIndex":0},{"imageOffset":546668,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":368,"imageIndex":1},{"imageOffset":523128,"symbol":"__CFRunLoopRun","symbolLocation":1096,"imageIndex":1},{"imageOffset":520728,"symbol":"CFRunLoopRunSpecific","symbolLocation":572,"imageIndex":1},{"imageOffset":1210408,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":232,"imageIndex":12},{"imageOffset":1211104,"symbol":"-[NSRunLoop(NSRunLoop) runUntilDate:]","symbolLocation":88,"imageIndex":12},{"imageOffset":13385756,"symbol":"-[UIEventFetcher threadMain]","symbolLocation":472,"imageIndex":3},{"imageOffset":1381752,"symbol":"__NSThread__start__","symbolLocation":792,"imageIndex":12},{"imageOffset":29924,"symbol":"_pthread_start","symbolLocation":116,"imageIndex":7},{"imageOffset":9932,"symbol":"thread_start","symbolLocation":8,"imageIndex":7}]},{"id":561536,"frames":[{"imageOffset":9912,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":7}]},{"id":561537,"frames":[{"imageOffset":9912,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":7}]},{"id":561538,"frames":[{"imageOffset":9912,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":7}]},{"id":561551,"name":"com.facebook.react.JavaScript","frames":[{"imageOffset":4876,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":0},{"imageOffset":74092,"symbol":"mach_msg2_internal","symbolLocation":76,"imageIndex":0},{"imageOffset":38156,"symbol":"mach_msg_overwrite","symbolLocation":536,"imageIndex":0},{"imageOffset":5756,"symbol":"mach_msg","symbolLocation":20,"imageIndex":0},{"imageOffset":546668,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":368,"imageIndex":1},{"imageOffset":523128,"symbol":"__CFRunLoopRun","symbolLocation":1096,"imageIndex":1},{"imageOffset":520728,"symbol":"CFRunLoopRunSpecific","symbolLocation":572,"imageIndex":1},{"imageOffset":884344,"symbol":"+[RCTCxxBridge runRunLoop]","symbolLocation":212,"imageIndex":4},{"imageOffset":1381752,"symbol":"__NSThread__start__","symbolLocation":792,"imageIndex":12},{"imageOffset":29924,"symbol":"_pthread_start","symbolLocation":116,"imageIndex":7},{"imageOffset":9932,"symbol":"thread_start","symbolLocation":8,"imageIndex":7}]},{"id":561552,"name":"hades","frames":[{"imageOffset":18448,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":0},{"imageOffset":31392,"symbol":"_pthread_cond_wait","symbolLocation":1220,"imageIndex":7},{"imageOffset":49548,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&)","symbolLocation":24,"imageIndex":13},{"imageOffset":1163624,"imageIndex":14},{"imageOffset":1163036,"imageIndex":14},{"imageOffset":29924,"symbol":"_pthread_start","symbolLocation":116,"imageIndex":7},{"imageOffset":9932,"symbol":"thread_start","symbolLocation":8,"imageIndex":7}]},{"id":561553,"name":"hermes-chrome-inspector-conn","frames":[{"imageOffset":18448,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":0},{"imageOffset":31392,"symbol":"_pthread_cond_wait","symbolLocation":1220,"imageIndex":7},{"imageOffset":49548,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&)","symbolLocation":24,"imageIndex":13},{"imageOffset":1966004,"symbol":"facebook::hermes::inspector::detail::SerialExecutor::runLoop()","symbolLocation":120,"imageIndex":4},{"imageOffset":1674928,"symbol":"void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::function<void ()>), std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::function<void ()> > >(void*)","symbolLocation":116,"imageIndex":4},{"imageOffset":29924,"symbol":"_pthread_start","symbolLocation":116,"imageIndex":7},{"imageOffset":9932,"symbol":"thread_start","symbolLocation":8,"imageIndex":7}]},{"id":561554,"name":"hermes-inspector","frames":[{"imageOffset":18448,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":0},{"imageOffset":31392,"symbol":"_pthread_cond_wait","symbolLocation":1220,"imageIndex":7},{"imageOffset":49548,"symbol":"std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&)","symbolLocation":24,"imageIndex":13},{"imageOffset":1966004,"symbol":"facebook::hermes::inspector::detail::SerialExecutor::runLoop()","symbolLocation":120,"imageIndex":4},{"imageOffset":1674928,"symbol":"void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::function<void ()>), std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::function<void ()> > >(void*)","symbolLocation":116,"imageIndex":4},{"imageOffset":29924,"symbol":"_pthread_start","symbolLocation":116,"imageIndex":7},{"imageOffset":9932,"symbol":"thread_start","symbolLocation":8,"imageIndex":7}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 229376,
    "uuid" : "99ef4d89-bf00-3860-a076-24f05834886c",
    "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
    "name" : "libsystem_kernel.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.CoreFoundation",
    "size" : 3866624,
    "uuid" : "673c8a21-98bf-38f0-a038-55ab0de23142",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/System\/Library\/Frameworks\/CoreFoundation.framework\/CoreFoundation",
    "name" : "CoreFoundation",
    "CFBundleVersion" : "1863"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "CFBundleShortVersionString" : "1.0",
    "CFBundleIdentifier" : "com.apple.GraphicsServices",
    "size" : 36864,
    "uuid" : "9334a354-2177-30b1-b919-4fecf59fef22",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/System\/Library\/PrivateFrameworks\/GraphicsServices.framework\/GraphicsServices",
    "name" : "GraphicsServices",
    "CFBundleVersion" : "1.0"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "CFBundleShortVersionString" : "1.0",
    "CFBundleIdentifier" : "com.apple.UIKitCore",
    "size" : 21573632,
    "uuid" : "7bbc9f13-df06-3c47-9a63-8483442bdfcb",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/System\/Library\/PrivateFrameworks\/UIKitCore.framework\/UIKitCore",
    "name" : "UIKitCore",
    "CFBundleVersion" : "5612"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "CFBundleShortVersionString" : "1.0.0",
    "CFBundleIdentifier" : "your.bundle.identifier",
    "size" : 2965504,
    "uuid" : "f79f2b68-4188-3ab0-9b21-7cc999da15d4",
    "path" : "\/Users\/USER\/Library\/Developer\/CoreSimulator\/Devices\/99599CC0-CF2B-46D8-9766-DB593EED4EC2\/data\/Containers\/Bundle\/Application\/7F7E1AC0-B6A7-4AD2-83D9-8E8095D2BA28\/createt3turbo.app\/createt3turbo",
    "name" : "createt3turbo",
    "CFBundleVersion" : "1"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 245760,
    "uuid" : "67298116-bb18-3438-b22e-8d2b9d4618e9",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/usr\/lib\/dyld_sim",
    "name" : "dyld_sim"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" :<PHONE_NUMBER>,
    "size" : 573440,
    "uuid" : "1f56ab4e-f398-3a9c-bfba-fbbd17808963",
    "path" : "\/usr\/lib\/dyld",
    "name" : "dyld"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 53248,
    "uuid" : "030d2641-514f-373f-9688-582d9d3b369a",
    "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
    "name" : "libsystem_pthread.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 516096,
    "uuid" : "d02ea88f-ad2d-354c-85eb-14cf4b6b1bb6",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/usr\/lib\/system\/libsystem_c.dylib",
    "name" : "libsystem_c.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 94208,
    "uuid" : "60908b1e-a8d3-3ecb-b51f-5ba5ca88d367",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/usr\/lib\/libc++abi.dylib",
    "name" : "libc++abi.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 204800,
    "uuid" : "925dbcc5-c31e-336d-aede-6fbce41d5415",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/usr\/lib\/libobjc.A.dylib",
    "name" : "libobjc.A.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 274432,
    "uuid" : "a06c95dc-09e7-3a87-afb6-7e1b0bec1287",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/usr\/lib\/system\/libdispatch.dylib",
    "name" : "libdispatch.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.Foundation",
    "size" : 2899968,
    "uuid" : "ded71e05-af0a-3172-b09e-7f070ec7d4aa",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/System\/Library\/Frameworks\/Foundation.framework\/Foundation",
    "name" : "Foundation",
    "CFBundleVersion" : "1863"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "size" : 376832,
    "uuid" : "03a5f91e-2bc5-3d4f-b91f-729633a08579",
    "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/Runtimes\/iOS.simruntime\/Contents\/Resources\/RuntimeRoot\/usr\/lib\/libc++.1.dylib",
    "name" : "libc++.1.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" :<PHONE_NUMBER>,
    "CFBundleShortVersionString" : "0.12.0",
    "CFBundleIdentifier" : "dev.hermesengine.iphonesimulator",
    "size" : 2981888,
    "uuid" : "dd8fec13-4cd7-34e2-aa9f-24aaa9550681",
    "path" : "\/Users\/USER\/Library\/Developer\/CoreSimulator\/Devices\/99599CC0-CF2B-46D8-9766-DB593EED4EC2\/data\/Containers\/Bundle\/Application\/7F7E1AC0-B6A7-4AD2-83D9-8E8095D2BA28\/createt3turbo.app\/Frameworks\/hermes.framework\/hermes",
    "name" : "hermes",
    "CFBundleVersion" : "0.12.0"
  }
],
  "sharedCache" : {
  "base" :<PHONE_NUMBER>,
  "size" :<PHONE_NUMBER>,
  "uuid" : "5b1b5894-31e5-3364-8135-7be20300b458"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=877.8M resident=0K(0%) swapped_out_or_unallocated=877.8M(100%)\nWritable regions: Total=624.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=624.3M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nActivity Tracing                   256K        1 \nColorSync                          128K        4 \nFoundation                          16K        1 \nIOSurface                          416K        2 \nKernel Alloc Once                   32K        1 \nMALLOC                           216.5M       45 \nMALLOC guard page                  128K        8 \nMALLOC_NANO (reserved)           384.0M        1         reserved VM address space (unallocated)\nSTACK GUARD                       56.2M       12 \nStack                             13.8M       12 \nVM_ALLOCATE                       8688K        8 \n__DATA                            12.9M      388 \n__DATA_CONST                      32.0M      386 \n__DATA_DIRTY                        50K        9 \n__FONT_DATA                          4K        1 \n__LINKEDIT                       523.1M        7 \n__OBJC_RO                         63.1M        1 \n__OBJC_RW                         3168K        1 \n__TEXT                           354.8M      394 \n__UNICODE                          592K        1 \ndyld private memory               1536K        3 \nmapped file                       37.4M        7 \nshared memory                       16K        1 \n===========                     =======  ======= \nTOTAL                              1.7G     1294 \nTOTAL, minus reserved VM space     1.3G     1294 \n",
  "legacyInfo" : {
  "threadTriggered" : {
    "queue" : "com.facebook.react.ExceptionsManagerQueue"
  }
},
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "60186475825c62000ccf5450",
      "factorPackIds" : {

      },
      "deploymentId" : 240000026
    },
    {
      "rolloutId" : "60f8ddccefea4203d95cbeef",
      "factorPackIds" : {

      },
      "deploymentId" : 240000025
    }
  ],
  "experiments" : [

  ]
}
}

Noticed this too - assumed it was just me as noone had reported any issues. I don't have an Apple Dev account so not sure if it works when built outside preview? What could the issue be?

For me it turned out that I just didn't set up the base url for trpc https://github.com/t3-oss/create-t3-turbo/blob/main/apps/expo/src/utils/api.tsx#L26-L32 🤦
The same problem was referenced in here https://github.com/t3-oss/create-t3-turbo/pull/168/files. I think we should put this in README somehow since debugging at this point was a big headache

For me it turned out that I just didn't set up the base url for trpc https://github.com/t3-oss/create-t3-turbo/blob/main/apps/expo/src/utils/api.tsx#L26-L32 🤦
The same problem was referenced in here https://github.com/t3-oss/create-t3-turbo/pull/168/files. I think we should put this in README somehow since debugging at this point was a big headache

Oh right... Yea there's no debugger host when launching the built app...
Yea we can add that to the readme i guess.


Turn Off is not working

Describe the bug
The adapter connects with the tv. I can turn on the tv with the adapter.
To Reproduce
Steps to reproduce the behavior:
many commands are working fine:
setState('lgtv.0.states.launch', 'youtube');
setState('lgtv.0.states.power', true);
or volume change.
but it is not possible to switch off the tv with one of the following commands:
setState('lgtv.0.states.turnOff', true);
or
setState('lgtv.0.states.power', false);
Expected behavior
Switch off the TV
Screenshots & Logfiles
If applicable, add screenshots and logfiles to help explain your problem.
`

lgtv.0
2023-10-15 13:15:07.853
debug
Sending turn OFF command to WebOS TV: <IP_ADDRESS>

lgtv.0
2023-10-15 13:15:07.853
debug
State change "states.power" - VALUE: false

lgtv.0
2023-10-15 13:11:45.370
debug
Sending turn OFF command to WebOS TV: <IP_ADDRESS>

lgtv.0
2023-10-15 13:11:45.370
debug
State change "states.power" - VALUE: false

lgtv.0
2023-10-15 13:11:40.499
debug
Send WOL to MAC: {a8:23:fe:69:16:8a} OK

lgtv.0
2023-10-15 13:11:40.498
debug
GetState mac: {"val":"xyz","ack":true,"ts":1697368259326,"q":0,"from":"system.adapter.lgtv.0","user":"system.user.admin","lc":1697367337007}

lgtv.0
2023-10-15 13:11:40.497
debug
State change "states.power" - VALUE: true`

Versions:

Adapter version: 2.1.1
JS-Controller version:   5.0.13
Node version:   18.17.1
Operating system:  Debian

Additional context

Looks like tv is switched off but restarted by WOL.
@basty2
Did you see any such sequence (tv seitching off but on again) at your system?

no I have not recognized. For example, the screen saver was on (fireworks), but it just stays as it is, does not turn off.
By the way, the model is OLED55C8LLA

@basty2
Please retest with 2.1.2 (available at latest tomorrow)
@agross
If you have any input in regard to this issue please let us know.

no more comment, no feedback for test with 2.1.2
So lets close here
Please open a new issue if problem stiull exists.


Yaml edit

#615
#608
use js-yaml to create a yaml from resource proxy objects in order to:

map _type to type
hide 'stringData' field on secrets
skip 'resourceVersion' field when cloning as yaml
skip 'state' field when cloning as yaml

The YAML you see to edit/clone from the view/rioview link is not necessarily the same as converting the JSON of the model to YAML.
In particular, the rioview links return stringified versions of complex objects like ports, so that you see/edit the flattened syntax you can use on the CLI:
  ports:
  - 8089:80,hostport,web

Instead of the raw actual type:
  ports:
  - hostport: true
    name: web
    port: 8089
    targetPort: 80

(rioview links are only in the proto-Steve kubecon Rio API right now, but will be going into regular Steve soon because we're working on fixing up Rancher+Dashboard+Rio)


Q: Wildcards in pyproj file to avoid manually adding files to solution?

Hello. I have a large Python project that is developed by a team that mostly uses PyCharm and vim.  I would like to support Visual Studio as a viable option. I'm testing this with VS 2017 Community.
My problem is that it wants to list each Python source file in the .pyproj file. As files are added or deleted by developers who aren't using VS (most of them) they aren't going to be maintaining the VS project. So it looks like new files won't show up there automatically, and .pyproj is also littered with deleted files.
Is there a way to configure the .pyproj file to see all Python files automatically in certain designated directories? I've tried something like the example below and it doesn't work. VS Solution Explorer shows the named folders but none of the Python files inside.
The problem is most acute for my Python files but a similar problem applies to my static web resources folder where I don't want to have to list out the files there either.
In this example, wtlib is a folder in my PYTHONPATH that contains .py files plus package folders. In PyCharm I can just designate that folder as a "source folder" in the settings and all is well.
  <ItemGroup>
    <Content Include="wtp\htdocs\**" />
  </ItemGroup>
  <ItemGroup>
     <Compile Include="wtp\wtlib\*.py" />
     <Compile Include="wtp\wtlib\**\*.py" />
  </ItemGroup>
  <ItemGroup>
    <Folder Include="wtp\wtlib\" />
    <Folder Include="wtp\wtlib\**" />
  </ItemGroup>

Any thoughts would be greatly appreciated.

Right now, there is no great way to do this :( The wildcards should work, but will quickly break down if you modify any files in the project (we'll convert them to full lists of files). Manually keeping the project up to date ("Show all files" and the Include in Project/Exclude from project commands are very useful for this).
What we're working on longer-term is full support for "Open Folder". This will let you use all the functionality of VS without having to create a project file. Right now, there is some basic debugging and Intellisense support when you use Open Folder, which may be sufficient for you (it's roughly at parity with the Python support in VS Code), but as more updates are released you should see it start to improve.
See #1556 for the main issue where we are tracking work on Open Folder.


Create Readme

A readme that will also be nicely displayed on pub.dev

@Goddchen  Can you share a brief description of What the package does?, it will be helpful writing README.md

Hey, thanks for your interest in the project 😎
Sure. I have already startet to write something in the feature/readme  branch. Is this already enough info for you to continue? Feel to free to create a PR out of this branch when it's finished.


Builder: support jobs to automatically change stages

For example: when close submission is at night programate a job to execute the close submmission automatically.

Before we create jobs like this, we should fully implement the logic of all the various "date" fields in the invitation, note, and group objects. Doing this would solve many (but not necessarily all) of the timing-related issues. For example:

Create comment invitations in advance, but with cdate set to a time in the future when commenting is enabled.
Create revision invitation in advance with cdate set to the end of the review period (in this example, authors are allowed to revise papers after they've been reviewed).
Create two homepage groups A and B, with cdate-to-ddate periods that abut one another (e.g. group A has cdate=0 and ddate=10, group B has cdate=10 and ddate=20, etc.). Group A would have a webfield for the submission stage, and group B would have a webfield for the post-submission stage.


Documentation: configure resource restrictions for systemd

Fixes #2940

LGTM

being a Documentation change I am skipping CI.


Custom Nav: (Feature Request) Allow shifting right to provide better Octotree compatibility

Hey @Mottie Rob!
For those using Octotree, the pinned left content bar almost completely overlaps the GH search box in the custom NAV bar, even when used with the very handy GH Fixed Header style.
Would it be possible to, either via a new static option or a custom CSS option, to have the custom NAV style/userscript provide the mechanism to right-shift the entire custom nav bar items (up to the right-most options button) into the vast space present on most wide displays between that options button and the default GH notification bell and avatar menu?
This would be an awesome addition and I'm sure very welcomed as the Octotree extension is gaining more and more traction and otherwise seems to work very well with every other GH style/script of yours I've used!  Thanks!

Hi @CollinChaffin!
Hmm, I have Octotree installed, but I'm not seeing the overlap you're describing (while pinned).

I did see that with GitHub Dark turned off, all of the svg icons were too dark. GitHub changed all their nav class names a while back. I'll get that fixed in the next update.

Ok, I found the issue you're describing. It's a bit complicated. Octotree is adding a padding-left to the header when the side panel is pinned and resized; but it completely removes that padding once the side panel width equals the margin left value (GitHub sets the margin to auto). Because of this, the fixed header (applied by the GitHub-FixedHeader user style) jumps back to the left when Octotree removes the padding-left value. I hope that makes sense.
A solution would not involve changing the fixed header style since we can't use dynamic values in CSS.
Using the custom navigation userscript to modify the header padding would work, but only for this one userscript. I guess I could write a separate userscript to patch the GitHub-FixedHeader issue...
The ideal solution would be to have Octotree not remove the padding.

Try this userscript, for now:
// ==UserScript==
// @name        GitHub FixHeader Adjust
// @version     0.1.0
// @description A userscript that adjusts the header position for Octotree & GitHub-FixedHeader
// @license     MIT
// @author      Rob Garrison
// @namespace   https://github.com/Mottie
// @include     https://github.com/*
// @include     https://gist.github.com/*
// @run-at      document-idle
// @grant       none
// @icon        https://github.githubassets.com/pinned-octocat.svg
// ==/UserScript==
(() => {
	"use strict";

	const html = $("html");

	function checkOctotreeWidth() {
		if (html.classList.contains("octotree-show")) {
			const size = html.style.marginLeft || 0;
			$(".Header").style.marginLeft = (size ? size : "");
		}
	}

	function $(selector, el) {
		return (el || document).querySelector(selector);
	}

	if (html.classList.contains("octotree")) {
		new MutationObserver(checkOctotreeWidth).observe(html, { attributes: true });
	}
})();

Hey @Mottie Rob!
This is awesome I'll work to test it now - thanks!  I should have known better and added that this is also with the Github-Wide userscript in use (along with GH dark you mentioned and most of yours).  I recently had to do several fixes and still have a PR open with GH wide due to Octotree overlap issues when using that script (which I no longer suffer from) and I believe their last update made attempts (unneeded, IMO to fix the overlap issue) to also change that padding-left.  So, let me try this new script and also do a bit more testing since now that I think about it, this whole issue very well is again probably an issue with the GH wide script. :)
Thanks!

Quick update I think my terminology was off the "shifting" is working perfectly albeit I have to scroll a bit to see the shift occur.  But, the shift then loses the right-hand avatar/etc.  "Squeezing" to reduce the middle blank space is a more accurate description of what is needed.
I have confirmed my last guess is correct - 100% of this is actually again due to that GH wide userscript.  Without any checking, it applies the "wide" to the top nav bar (along with other elements) and even I force it to apply after this new script you provided, it simply stretches the dimensions (now offscreen) due to the lack of any logic.  This is about the sixth major issue caused by it recently so I apologize for not checking it sooner.
After experiencing a bit of questionable interaction with the GH wide developer myself I already wound up just forking it and having to apply several recent fixes myself and I think in the end I just need to work on rewriting much of it from the ground up.  It's not my 1st choice CSS is not really my strength but I'll try to figure it out.
I'm surprised that you being by far the top GH site pro have written enhancements for just about everything else but not a "wide" one.  Either a new proper "wide" style/uscript in your collection, or even as a new added "wide" option in the larger GH Dark would of course be the utopia option. :wink: :wink:

LOL, I never bothered making a "wide" style because there were already so many... that, and I kinda like keeping the width of the content fixed - at least for GitHub. I can look into it when I get a chance.

I have yet to see a GH wide style that actually works well despite all the commonly used styles and extensions other than your styles/scripts which, even with just about all of them together plus octotree/refinedGH/others, work well without issues.  Even if you ever get a few min to evaluate Octotree (since they still do have an open-source offering) to try to assist that project on the best ways specific to GH to do certain things - like that expanding left bar - I'm certain would be vastly welcomed from anyone familiar with all your GH experience.

Let me know what you think of this userscript... it slides all content to the right when the Octotree side panel opens. I did this in case someone with a narrow screen  still wanted to see the content which would normally end up under the side panel.
// ==UserScript==
// @name        GitHub Octotree Slide
// @version     0.1.0
// @description A userscript that slides content to the right when Octotree's sidepanel opens
// @license     MIT
// @author      Rob Garrison
// @namespace   https://github.com/Mottie
// @include     https://github.com/*
// @include     https://gist.github.com/*
// @run-at      document-idle
// @grant       none
// @icon        https://github.githubassets.com/pinned-octocat.svg
// ==/UserScript==
(() => {
	"use strict";

	const html = document.querySelector("html");
	const style = document.createElement("style");
	const octotreeNav = document.querySelector(".octotree-sidebar");

	if (html.classList.contains("octotree")) {
		document.body.appendChild(style);
		[html, octotreeNav].forEach(el => {
			new MutationObserver(checkOctotreeWidth).observe(el, {
				attributes: true
			});
		});
	}

	function checkOctotreeWidth() {
		const offset = octotreeNav.style.width;
		style.textContent = `
			html body > div:not(.js-header-wrapper),
			.Header {
				transform: translate3d(0px, 0px, 0px);
				transition: transform 0.2s ease 0.1s;
			}
			html.octotree-show body > div:not(.js-header-wrapper),
			html.octotree-show .Header:not([style]) {
				transform: translate3d(${offset}, 0px, 0px);
			}`;
	}
})();


Logs SDK - Batching LogRecordProcessor

Implement a batching LogRecordProcessor for the Logs SDK.
Batching processor: https://opentelemetry.io/docs/specs/otel/logs/sdk/#batching-processor
Needs the following:

[ ] OnEmit: https://opentelemetry.io/docs/specs/otel/logs/sdk/#onemit
[ ] ShutDown: https://opentelemetry.io/docs/specs/otel/logs/sdk/#onemit
[ ] Force Flush: https://opentelemetry.io/docs/specs/otel/logs/sdk/#forceflush-1

WIP, unreviewed code for this issue, along with other parts of the logs SDK, can be found in https://github.com/kaylareopelle/opentelemetry-ruby/pull/6


Emulation.setTouchEmulationEnabled effects disappear after navigating to another page.

Environment

Component
Version

Node.js
v14.17.5

Client (Chrome/Chromium/...)
Chrome

OS running Node.js
Win 10

OS running the client
Win 10

chrome-remote-interface
0.31.1

Is the client running in a container? NO
Description

Trying to use the dev tools device emulation features from the cdp I found that the Emulation.setTouchEmulationEnabled command seems to reset after clicking any link and changing the page.
To demostrate the issue:

Launch chrome with --remote-debugging-port=9222
Run the node code from the example (github.com will open in chrome)
Open dev tools and run "ontouchstart" in window on the console (it returns true)
Click any link on the page
Go back to the dev tools and run "ontouchstart" in window again (now it returns false)

When using a normal chrome with dev tool's device toolbar "ontouchstart" in window always returns true:

Launch a normal chrome and open the dev tools
Click the Toggle Device Toolbar icon at the top left (or press Ctrl+Shift+M)
Navigate to any website
Run "ontouchstart" in window on the console (it returns true)
Click any link on the page
Go back to the dev tools and run "ontouchstart" in window again (still returns true)

Is this a bug or am I doing something wrong?
Example

const CDP = require('chrome-remote-interface');
async function start() {
    client = await CDP({ host: 'localhost', port: 9222 });
    const {Page, Emulation} = client;
    await Emulation.setDeviceMetricsOverride({ width: 800, height: 800, deviceScaleFactor: 2, mobile: true });
    await Emulation.setTouchEmulationEnabled({ enabled: true, maxTouchPoints: 1 });
    await Emulation.setEmitTouchEventsForMouse({ enabled: true, configuration: "mobile" });
    await Page.navigate({ url: 'https://github.com' });
}
start();

@cyrus-and @markpatx Why did you write wrong here? How to fix the same issue


HDFS-17053. Optimize method BlockInfoStriped#findSlot to reduce time complexity.

Description of PR
Please see HDFS-17053.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 54s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 15s

trunk passed

+1 :green_heart:
compile
1m 24s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
compile
1m 16s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
checkstyle
1m 17s

trunk passed

+1 :green_heart:
mvnsite
1m 25s

trunk passed

+1 :green_heart:
javadoc
1m 14s

trunk passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 34s

trunk passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
3m 37s

trunk passed

+1 :green_heart:
shadedclient
26m 51s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 13s

the patch passed

+1 :green_heart:
compile
1m 17s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javac
1m 17s

the patch passed

+1 :green_heart:
compile
1m  9s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
javac
1m  9s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m  1s

the patch passed

+1 :green_heart:
mvnsite
1m 15s

the patch passed

+1 :green_heart:
javadoc
0m 56s

the patch passed with JDK Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1

+1 :green_heart:
javadoc
1m 26s

the patch passed with JDK Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

+1 :green_heart:
spotbugs
3m 22s

the patch passed

+1 :green_heart:
shadedclient
26m 24s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
234m 38s

hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 49s

The patch does not generate ASF License warnings.

351m 53s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5757/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5757

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 357d71ea1add 4.15.0-206-generic #217-Ubuntu SMP Fri Feb 3 19:10:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / dc84781b7aaba2dcf6b68e15eece218a992871a2

Default Java
Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu120.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~20.04-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5757/1/testReport/

Max. process+thread count
2412 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5757/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@ayushtkn  Hi, sir. could you please help me review this minor changes when you have time?  Thanks a lot~.

@ayushtkn Sir, thanks a lot for your reviewing and merging~


adding vue.js storefront client example

Created a Vue.js example for integrating with Shopify's Storefront API through graphql.

This is great! Thank you!
However, all of our examples useca shared css file and a common html layout. Are you able to adapt to follow suit?
Thank you!

Yes, I can do that. I'll update you when I find some time 👍


Build fails on OpenSuSE Leap 15.2 with openjdk-16

After upgrading my OpenSuSE Leap 15 (x86_64) system to openjdk 16 (default in OpenSuSE is 11) and downloading RText, running ./gradlew build installDist fails with 'Could not resolve com.fifesoft.rtext:fife.common:3.1.1.'
I have attached debugging output.
gradlewBuild.log

You may have just pulled at a bad time when fife.common and RText were out of sync.  There were fairly recent changes for gradle's concepts of a Java library vs. app, as well as migrating from Java 11 to 14 as the minimum runtime.  RText's latest now pulls FifeCommon 4.0.0; could you pull the latest and try again?

Sorry for the delay; I bricked my machine trying to isolate a new GPU card over the weekend, and just got it rebuilt.
I decided to jump from my distro's default of openjdk-11 right to jdk-16.0.1 (the latest); it might have something to do with my results. :-)
I was able to build the program successfully, but there are run-time errors, and what got built is unusable because the menu doesn't seem to want to work.  I'll attach a screen-shot and an error log.
RText.log.tar.gz
RTextScreen1

Thanks. The most recent release was in Java 14 so there may be issues with 16.  I'll have to take a look. As a shot on the dark, what happens if you delete the ~/.rtrxt folder and restart to take the default for all options?

Renaming ~/.rtext had no effect.  I should add that the menu items and icons below them are invisible until I run my cursor over them; the close button, though invisible, does work.
Now that I know how Oracle's jdks install into my distro (they end up in an entirely different place than where the distro's jdks go), I can try it with jdk-14 as well (if I can remember how update-alternatives works :-) ).

Right now I'm having fun with update-alternatives and gradle, which don't seem to be getting along.  I've installed JDK-14 alongside JDK-16, and I'm able to switch between them with update-alternatives --config java, but I'm getting
ERROR: JAVA_HOME is set to an invalid directory: /usr/java/jdk-14.0.2/bin/java
when I run ./gradlew build installDist.
Might I mention that I already had Gradle installed from my distro's repositories, but your installer insists on installing its own?  Why is that?

Possibly this is the root of the gradle problem:
https://stackoverflow.com/questions/22307516/gradle-finds-wrong-java-home-even-though-its-correctly-set

Re: grade being downloaded, that's the way the gradle wrapper works. It's designed that way so the build always uses the same version of gradle (it gets downloaded and cached).
That's unfortunately the second issue I've read about now where gradle has Java issues. The last one was older versions of grade not working with Java 14 when it was new (I think) due to heavy jvm structural changes on Oracle's part.

Closing this as we now require Java 17 and Gradle 7.6 to build, and builds appear to be working across all environments.


Adding po to cause_base may affect pre-existing memory model without proxies

Hi, we encountered a potential issue while examining the update that adding the program-order relation into the base-causality-order relation in the PTX memory model. It appears that the update has an impact on the pre-existing memory model without proxies, which is in contrast to the claim made in the ISCA'22 paper. To illustrate this concern, we have prepared a litmus test counter example:
.global x;
.global f1;
.global f2;

d0.b0.t0 {
  st.weak [x], 1;
  st.release.sys [f1], 1;
}

d0.b1.t0 {
  st.release.gpu [x], 2;
  ld.weak r0, [x];
  st.release.sys [f2], 1;
}
d0.b2.t0 {
  ld.acquire.sys r1, [f2];
  ld.acquire.sys r2, [f2];
  ld.weak r3, [x];
}

permit (r0 == 0 && r1 == 1 && r2 == 1 && r3 == 2) as my_test;

Could you take a look into this matter? thanks!

That is a big litmus test, and I'm not 100% sure what it's trying to show...  Is it the minimal counterexample?  Did you modify the Alloy model to capture the "before" vs. "after"?
For one thing, the thread 0 store to x and the thread 1 accesses of x are racy, so it's hard to draw a lot of intuition about what synchronization pattern this is supposed to represent.
For another, P1:r0==0 should be illegal both before and after, since it's a CoWR violation, independent of what the other threads do.  Does the "before" model somehow permit it?  If so, then I think the "before" model might just have a bug...

This was our original example
PTX Test1
{
x=0;
P1:r1=0;
}
 P0@cta 0,gpu 0         | P1@cta 1,gpu 0          ;
 st.weak x, 1           | st.release.gpu x, 2     ;
                        | ld.weak r1, x           ;
exists
(x == 2 /\ P1:r1 == 0)

We added the extra thread and the flag variables f1,f2 to cope with the fact that the alloy tool does not allow to refer to locations in the final assertion.
The problem might indeed be related to the fact that the code has a data race, because we still get different results in this test
PTX Test2
{
x=0;
P1:r1=0;
}
 P0@cta 0,gpu 0         | P1@cta 1,gpu 0          ;
 st.release.gpu x, 1    | st.release.gpu x, 2     ;
                        | ld.weak r1, x           ;
exists
(x == 2 /\ P1:r1 == 0)

but not with this one
PTX Test3
{
x=0;
P1:r1=0;
}
 P0@cta 0,gpu 0         | P1@cta 1,gpu 0          ;
 st.release.gpu x, 1    | st.release.gpu x, 2     ;
                        | ld.acquire.gpu r1, x    ;
exists
(x == 2 /\ P1:r1 == 0)

Is there a formal way to add the data race definition to the model, like in lkmm?

OK, the use of the flags makes sense now, thank you.
However, I still don't follow what you mean by "get different results".  Can you please elaborate?  AFAICT the proposed outcome should still be disallowed in all cases, i.e., there should be no valid execution (in a proxy-less model) where a load is fr-before an earlier store in the same thread.

We update the cause_base to be:
fun cause_base : Op->Op {
 *po.^((sc + sync).*po)
}

which we think is consistent with the proxy-less model way. And below is the whole output of the test with this change:
// NVLitmus is a research prototype, and comes with no guarantees of completeness, correctness, or authoritativeness.  Please see https://github.com/NVlabs/mixedproxy for more information.
Test:
.global x;
.global f1;
.global f2;

d0.b0.t0 {
  st.release.sys [x], 1;
  st.release.sys [f1], 1;
}

d0.b1.t0 {
  st.release.gpu [x], 2;
  ld.acquire.sys r0, [x];
  st.release.sys [f2], 1;
}
d0.b2.t0 {
  ld.acquire.sys r1, [f2];
  ld.acquire.sys r2, [f2];
  ld.acquire.sys r3, [x];
}

permit (r0 == 0 && r1 == 1 && r2 == 1 && r3 == 2) as my_test;

Launching Alloy...
my_test: SAT, outcome permitted, matches expectation

As a comparison, in the ptx-proxy with cause_base containing the ^po which is
fun cause_base : Op->Op {
  ^po + *po.^((sc + sync).*po)
}

The output we got from the same test is:
// NVLitmus is a research prototype, and comes with no guarantees of completeness, correctness, or authoritativeness.  Please see https://github.com/NVlabs/mixedproxy for more information.
Test:
.global x;
.global f1;
.global f2;

d0.b0.t0 {
  st.release.sys [x], 1;
  st.release.sys [f1], 1;
}

d0.b1.t0 {
  st.release.gpu [x], 2;
  ld.acquire.sys r0, [x];
  st.release.sys [f2], 1;
}
d0.b2.t0 {
  ld.acquire.sys r1, [f2];
  ld.acquire.sys r2, [f2];
  ld.acquire.sys r3, [x];
}

permit (r0 == 0 && r1 == 1 && r2 == 1 && r3 == 2) as my_test;

Launching Alloy...
my_test: UNSAT, outcome not permitted, breaks expectation
        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Alloy exited with code 10
// Alloy exited with non-zero return code

Just to avoid confusion: @tonghaining is showing the result of Test3. Hopefully, this should be enough to understand why the alloy model allows this behavior.
As I mentioned above, our tool+models says this behavior is not allowed when there are not weak accesses. The difference between the tools is probably due to some other small changes we did to our models to follow closer the documentation.

We found the reason why both tools return different results on Test3: the original PTX model has this axiom
acyclic ((morally-strong & (rf | co | fr)) | po-loc) as axiom-ScPerLocation

which is not part of the model in this repo (but we have it in our proxy-less model). Thus if we want to use the tool to reason about the old model, we need to add that axiom.
Is it the case that the axiom becomes trivially satisfied by adding po to cause_base and thus not included in the proxy model?
However, the initial issue that the claim

"The only change required was to add program order to the list below. This change by itself has no effect in the pre-existing memory
model without proxies"

might not hold, still remains (as witnessed by Test1 and Test2).

The litmus test we showed actually had a typo (the last thread was reading twice the f2 flag). Sorry for the spam.
We did some more testing and ATM we are not aware of any litmus test showing differences between both models, so this issue can be closed.

Thanks, feel free to reopen or create a new issue if you do find a test that shows the difference.

@hernanponcedeleon thanks for the report.  The cycle looks like a pretty standard ISA2 litmus test, and so the outcome should be forbidden under both models.  The accesses to f appear to be extraneous.  Am I misinterpreting anything there?  Are you suggesting that the new model considers this a permitted outcome?  What part of the wording would suggest that?

I can even show the problem on a simple MP test.
While this version returns the correct result
Test:
.global x;
.global g;

d0.b0.t0 {
  st.weak [x], 1;
  st.release.gpu [g], 1;
}

d0.b1.t0 {
  ld.acquire.gpu r2, [g];
  ld.weak r4, [x];
}

assert (r2 != 1 || r4 == 1) as diff;
Launching Alloy...
diff: UNSAT, assertion confirmed, matches expectation

this one does not
Test:
.global x;
.global g;

d0.b0.t0 {
  st.weak [x], 1;
  fence.acq_rel.gpu;
  st.relaxed.gpu [g], 1;
}

d0.b1.t0 {
  ld.acquire.gpu r2, [g];
  ld.weak r4, [x];
}

assert (r2 != 1 || r4 == 1) as diff;
Launching Alloy...
diff: SAT, assertion violated, breaks expectation
        !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
        value={i3$0->1, i4$0->0, i0$0->1, i2$0->1}
Alloy exited with code 10
// Alloy exited with non-zero return code

I think @tonghaining found the reason. The notion of morally-strong in v7.5 requires both operations to be on the same proxy, and it seems that this is failing for the fence. In the violation witness from my previous msg, we do have the release-acquire pattern between E3 and E8, but they are not morally strong and thus they do not contribute to sw.
In the alloy model, I don't see anything about fences having / being part of the same-proxy relation.

@daniellustig I took a closer look to the wording of the ISA and this section says the following about the MP below
T1
W1: st.global.u32 [data], 1;
F1: fence.sys;
W2: st.global.relaxed.sys.u32 [flag], 1;

T2
R1: ld.global.relaxed.sys.u32 %r0, [flag];
F2: fence.sys;
R2: ld.global.u32 %r1, [data];

Thread T1 first writes to a data variable and then to a flag variable while a second thread T2 first reads from the flag variable and then from the data variable. The operations on the flag are morally strong and the memory operations in each thread are separated by a fence, and these fences are morally strong.

However, the definition of morally strong clearly states (point 2) that "Both operations are performed via the same proxy" and I could not find anything in the wording saying anything about normal fence operations (i.e., not fence.proxy) and proxies.

I agree that making the fences part of the morally-strong definition (not only F * F, but also F * strongMem and strongMem * F) should fix the problem.
There are a few alternatives to make this. I think any of these would work, but none look to clean to me

(F * F | F * strongMem | strongMem * F) subsetof proxy // This sounds kind of artifitial
new-morally-strong = old-morally-strong | F * F | F * strongMem | strongMem * F // Adding a large disjuction to a definition that is a large conjuction doesn't seem to clean either

@daniellustig another (cleaner IMO) solution is to tag non-proxy fences by GenericProxy. It definitely solves this problem, and hopefully it does not introduce others.
However, this change would break this test which @tonghaining and I added a while back. At that point, our claim was that the outcome was observable because

"the first operation of the release pattern and the last operation of the acquire pattern should be morally strong to make the two patterns synchronized"

and we believed the release store and the fence were not morally strong. However, I am pretty sure the outcome is not allowed by v6.0 and according to your last msg, I should neither be allowed by v7.5.


unable to scrape steamdb.info

Before creating an issue, first upgrade cfscrape with pip install -U cfscrape and see if you're still experiencing the problem.
Version number
Run pip show cfscrape and paste the output below:
2.0.7

Code snippet experiencing the issue
SSL/TLS error
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

Complete exception and traceback
(If the problem doesn't involve an exception being raised, leave this blank)

URL of the Cloudflare-protected page
https://steamdb.info/app/896960/graphs/
https://steamdb.info/api/GetGraph/?type=concurrent_week&appid=896960
URL of Pastebin/Gist with HTML source of protected page
[LINK GOES HERE]

The error is from Curl and is not related to python or this project.


rethink VIC's continuous integration

We've been having all sorts of problems with Travis is recent months (e.g. #318), mostly with the image driver and getting easy installs of the dependencies required to build.  There are other CI options that we could use that use containers (e.g. docker images) to build, test, and even distribute software.  These all sync up with github in the same way as Travis and could be complementary or replace our current CI.
CI using docker images

http://wercker.com/
https://circleci.com/
https://codeship.com

Automated docker image builds

https://hub.docker.com/

At a minimum, I'd like to suggest we setup a standard docker image that includes all the dependencies to run VIC and its sample datasets. This should go along with #50 and #79.  This would also create a very portable way for users to test out VIC, even on windows machines using docker.
This issue is more concerned with being able to test the image driver build.  So if I can't get #318 fixed, we may consider moving to one of these solutions.

I like this idea. Are there any that are compatible with Travis so that we can still leverage the builds we did there?
Once we have a fully working test case for image mode it would be interesting to do some timing test with and without using DOcker.

We can use them together. Github will integrate with both of them and our pull requests will report status from both of them. The nice thing about werker is that we don't have to install the dependencies and we can specify everything, so in theory, the builds should be even faster.


pkgs.vagrant: Out-of-date 2.2.19 -> 2.3.0.

Checklist

[x] Checked the nixpkgs master branch
[x] Checked the nixpkgs pull requests

Project name
nix search name: vagrant
current version: 2.2.19
desired version: 2.3.0
Notify maintainers
maintainers: @Ma27

I've tried to update vagrant as described in the default.nix with not only adjusting the version but also try to re-bundle the vagrant and vagrant-libvirt dependencies via bundix where I encountered different problems:

The hashes of different dependencies like google-protobuf, grpc, ... (only a few) are reported wrong while building. Changing them solves the problem. It doesn't matter if I use "-l", "-m "-dm" or no parameters for bundix.
After that it seems that dependencies are missing/recognized or I did something wrong:

 these 30 derivations will be built:
   /nix/store/ixkjl1kv2rqdlgfnc199dj3fw0aj9f7x-ruby2.7.6-ffi-1.15.5.drv
   /nix/store/08nb65r9nywl1alw7bji1mdd1i9h8ny1-ruby2.7.6-gssapi-1.3.1.drv
   /nix/store/pf68h7h7f3ixgknhg7gy0al8s8x1x1l4-ruby2.7.6-google-protobuf-3.21.5.drv
   /nix/store/wakm86zdp1n4rjx1ry9skczvinpkj582-ruby2.7.6-googleapis-common-protos-types-1.3.2.drv
   /nix/store/a60by6zfy8asgfwrl6fqzifp5lcm5ay9-ruby2.7.6-grpc-1.48.0.drv
   /nix/store/awir1rhx15q4w2hpkxih7ydr4qc66lir-ruby2.7.6-winrm-2.3.6.drv
   /nix/store/63savqc8d3c9h8cg17xr5vb2xy7zz6s3-ruby2.7.6-rb-inotify-0.10.1.drv
   /nix/store/b3jy4p3306gshrvhcwwznrgq19hgc6fi-ruby2.7.6-listen-3.7.1.drv
   /nix/store/v54zh2xm5mc71srfaqag35zmkm255aab-ruby2.7.6-winrm-fs-1.3.5.drv
   /nix/store/rc2gmg0a6fmcsjybpqvwwismi96s2grq-ruby2.7.6-winrm-elevated-1.2.3.drv
   /nix/store/x5sfpk8m624b8xg979x7mrbs18d443c4-ruby2.7.6-rb-kqueue-0.2.8.drv
   /nix/store/09wlp885dxds6f5p70nn1kpkypqgjfdy-ruby2.7.6-vagrant-2.3.1.dev.drv
   /nix/store/5938lbg8h3hahc3kl9wmdx3hfrg2ns9d-ruby2.7.6-nokogiri-1.13.8.drv
   /nix/store/8wfmnx31447992nzhpr4jaz90cph00sr-ruby2.7.6-fog-xml-0.1.4.drv
   /nix/store/rvf0arv4kc3ax5s2vk7n60qfrcyvv1ii-ruby2.7.6-vagrant-spec-0.0.1.drv
   /nix/store/zgcccryd4swp0z1cf19f39qwxds7llf8-ruby2.7.6-ruby-libvirt-0.8.0.drv
   /nix/store/yzy05cswn161ivvzq3ng1byh0w348zwq-ruby2.7.6-fog-libvirt-0.9.0.drv
   /nix/store/bbk02jdp4lwx2qpi7bpj040jwafm5k61-vagrant-2.3.0.drv
   /nix/store/kdanpyprlgabxcilwl7wkq9jmm00vphq-vagrant-2.3.0.drv
   /nix/store/2kr174b3jabq1awi5iwkxjw20rpg9w51-system-path.drv
   /nix/store/hx3iw1r87hvpnympyni56j896i5d7xvc-unit-systemd-fsck-.service.drv
   /nix/store/wchxkmjvkl2qxf0r22yh6lqdz3sz3ja5-dbus-1.drv
   /nix/store/lzfwc94qpqkcgdkwg512cihiv921a2qh-unit-dbus.service.drv
   /nix/store/nz16xim4ykvwpwl9kv69kkhy9jx69fs4-unit-accounts-daemon.service.drv
   /nix/store/pg3cfdi6mqmdw57xdlvvhvch7vsly0ja-unit-polkit.service.drv
   /nix/store/hl8wfs8givkczknzl329s41jqrar8y2w-system-units.drv
   /nix/store/nis70jwpbw4z7sl6phpdi8dy5v1wb0w2-unit-dbus.service.drv
   /nix/store/wyxsbwvm7cym2rcnh5995wyff1msd7c1-user-units.drv
   /nix/store/lg8vv5mj2q41973s4g4qb83wkhrx9wsl-etc.drv
   /nix/store/ydg1ifqp88059vmxkpcl6953dfcfvskk-nixos-system-XXXXXX-22.11pre-git.drv
 building '/nix/store/ixkjl1kv2rqdlgfnc199dj3fw0aj9f7x-ruby2.7.6-ffi-1.15.5.drv'...
 building '/nix/store/pf68h7h7f3ixgknhg7gy0al8s8x1x1l4-ruby2.7.6-google-protobuf-3.21.5.drv'...
 building '/nix/store/5938lbg8h3hahc3kl9wmdx3hfrg2ns9d-ruby2.7.6-nokogiri-1.13.8.drv'...
 building '/nix/store/zgcccryd4swp0z1cf19f39qwxds7llf8-ruby2.7.6-ruby-libvirt-0.8.0.drv'...
 building '/nix/store/rvf0arv4kc3ax5s2vk7n60qfrcyvv1ii-ruby2.7.6-vagrant-spec-0.0.1.drv'...
 unpacking sources
 unpacking sources
 patching sources
 patching sources
 configuring
 configuring
 unpacking sources
 no configure script, doing nothing
 no configure script, doing nothing
 installing
 patching sources
 installing
 buildFlags:
 configuring
 buildFlags:
 no configure script, doing nothing
 installing
 buildFlags: --use-system-libraries --with-zlib-lib=/nix/store/z18zgvspmxi88ipmk3f3nicvasfq3199-zlib-1.2.12/lib --with-zlib-include=/nix/store/py1w6vgg66qyjal27g6yzhaa2mp3rg3g-zlib-1.2.12-dev/include --with-xml2-lib=/nix/store/rqg79h5w8lzrw1a774z2fdkyakyjnr8n-libxml2-2.9.14/lib --with-xml2-include=/nix/store/036fl56k5xqbsqi9sm7ik3l6dbra4n45-libxml2-2.9.14-dev/include/libxml2 --with-xslt-lib=/nix/store/x1aqrbn4qxxkrhg2lwdj6w951c3j7ydf-libxslt-1.1.35/lib --with-xslt-include=/nix/store/8kpap8pd9g5cas277nxivh7pwhzxd48z-libxslt-1.1.35-dev/include --with-exslt-lib=/nix/store/x1aqrbn4qxxkrhg2lwdj6w951c3j7ydf-libxslt-1.1.35/lib --with-exslt-include=/nix/store/8kpap8pd9g5cas277nxivh7pwhzxd48z-libxslt-1.1.35-dev/include
 unpacking sources
 patching sources
 configuring
 no configure script, doing nothing
 installing
 buildFlags: --with-libvirt-include=/nix/store/riw4a9ffy9v75dk43386rrbn873b6pzn-libvirt-8.5.0/include --with-libvirt-lib=/nix/store/riw4a9ffy9v75dk43386rrbn873b6pzn-libvirt-8.5.0/lib
 unpacking sources
 unpacking source archive /nix/store/g2z7hb2vwfh5bd390zfpd8mp01v95gzf-vagrant-spec-a88825f
 source root is vagrant-spec-a88825f
 patching sources
 configuring
 no configure script, doing nothing
 building
 hint: Using 'master' as the name for the initial branch. This default branch name
 hint: is subject to change. To configure the initial branch name to use in all
 hint: of your new repositories, which will suppress this warning, call:
 hint:
 hint:   git config --global init.defaultBranch <name>
 hint:
 hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
 hint: 'development'. The just-created branch can be renamed via this command:
 hint:
 hint:   git branch -m <name>
 Initialized empty Git repository in /build/vagrant-spec-a88825f/.git/
 installing
 buildFlags:
 WARNING:  You build with buildroot.
   Build root: /
   Bin dir: /nix/store/609rr7inzf5jggqx19bpf3da1whz6laa-ruby2.7.6-google-protobuf-3.21.5/lib/ruby/gems/2.7.0/bin
   Gem home: /nix/store/609rr7inzf5jggqx19bpf3da1whz6laa-ruby2.7.6-google-protobuf-3.21.5/lib/ruby/gems/2.7.0
   Plugins dir: /nix/store/609rr7inzf5jggqx19bpf3da1whz6laa-ruby2.7.6-google-protobuf-3.21.5/lib/ruby/gems/2.7.0/plugins
 WARNING:  You build with buildroot.
   Build root: /
   Bin dir: /nix/store/8cxzf4y0mslkj7i4q2320gidxnqz9caz-ruby2.7.6-ffi-1.15.5/lib/ruby/gems/2.7.0/bin
   Gem home: /nix/store/8cxzf4y0mslkj7i4q2320gidxnqz9caz-ruby2.7.6-ffi-1.15.5/lib/ruby/gems/2.7.0
   Plugins dir: /nix/store/8cxzf4y0mslkj7i4q2320gidxnqz9caz-ruby2.7.6-ffi-1.15.5/lib/ruby/gems/2.7.0/plugins
 Building native extensions. This could take a while...
 WARNING:  You build with buildroot.
   Build root: /
   Bin dir: /nix/store/0z4d2lbr595qk0nlb4gjgxgr7yaw33v1-ruby2.7.6-ruby-libvirt-0.8.0/lib/ruby/gems/2.7.0/bin
   Gem home: /nix/store/0z4d2lbr595qk0nlb4gjgxgr7yaw33v1-ruby2.7.6-ruby-libvirt-0.8.0/lib/ruby/gems/2.7.0
   Plugins dir: /nix/store/0z4d2lbr595qk0nlb4gjgxgr7yaw33v1-ruby2.7.6-ruby-libvirt-0.8.0/lib/ruby/gems/2.7.0/plugins
 WARNING:  You build with buildroot.
   Build root: /
   Bin dir: /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/bin
   Gem home: /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0
   Plugins dir: /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/plugins
 Building native extensions with: '--with-libvirt-include=/nix/store/riw4a9ffy9v75dk43386rrbn873b6pzn-libvirt-8.5.0/include --with-libvirt-lib=/nix/store/riw4a9ffy9v75dk43386rrbn873b6pzn-libvirt-8.5.0/lib'
 This could take a while...
 Building native extensions with: '--use-system-libraries --with-zlib-lib=/nix/store/z18zgvspmxi88ipmk3f3nicvasfq3199-zlib-1.2.12/lib --with-zlib-include=/nix/store/py1w6vgg66qyjal27g6yzhaa2mp3rg3g-zlib-1.2.12-dev/include --with-xml2-lib=/nix/store/rqg79h5w8lzrw1a774z2fdkyakyjnr8n-libxml2-2.9.14/lib --with-xml2-include=/nix/store/036fl56k5xqbsqi9sm7ik3l6dbra4n45-libxml2-2.9.14-dev/include/libxml2 --with-xslt-lib=/nix/store/x1aqrbn4qxxkrhg2lwdj6w951c3j7ydf-libxslt-1.1.35/lib --with-xslt-include=/nix/store/8kpap8pd9g5cas277nxivh7pwhzxd48z-libxslt-1.1.35-dev/include --with-exslt-lib=/nix/store/x1aqrbn4qxxkrhg2lwdj6w951c3j7ydf-libxslt-1.1.35/lib --with-exslt-include=/nix/store/8kpap8pd9g5cas277nxivh7pwhzxd48z-libxslt-1.1.35-dev/include'
 This could take a while...
 Using vagrant-spec 0.0.1 from https://github.com/hashicorp/vagrant-spec (at a88825f@a88825f)
 Building native extensions. This could take a while...
 post-installation fixup
 shrinking RPATHs of ELF executables and libraries in /nix/store/lm4xiv6md2xaaa1zsqw99zbcqkg7bg61-ruby2.7.6-vagrant-spec-0.0.1
 rewriting symlink /nix/store/lm4xiv6md2xaaa1zsqw99zbcqkg7bg61-ruby2.7.6-vagrant-spec-0.0.1/nix-support/gem-meta/spec to be relative to /nix/store/lm4xiv6md2xaaa1zsqw99zbcqkg7bg61-ruby2.7.6-vagrant-spec-0.0.1
 strip is /nix/store/kia8xygy2r9iblwbjrl163j4bpz84wz7-gcc-wrapper-11.3.0/bin/strip
 stripping (with command strip and flags -S) in /nix/store/lm4xiv6md2xaaa1zsqw99zbcqkg7bg61-ruby2.7.6-vagrant-spec-0.0.1/lib  /nix/store/lm4xiv6md2xaaa1zsqw99zbcqkg7bg61-ruby2.7.6-vagrant-spec-0.0.1/bin
 ERROR:  Error installing /nix/store/96w491sd9rcc2k6ridkai5qr982bndss-nokogiri-1.13.8.gem:
         ERROR: Failed to build gem native extension.

     current directory: /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/gems/nokogiri-1.13.8/ext/nokogiri
 /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/bin/ruby -I /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/2.7.0 -r ./siteconf20220816-18-up9nlq.rb extconf.rb --use-system-libraries --with-zlib-lib\=/nix/store/z18zgvspmxi88ipmk3f3nicvasfq3199-zlib-1.2.12/lib --with-zlib-include\=/nix/store/py1w6vgg66qyjal27g6yzhaa2mp3rg3g-zlib-1.2.12-dev/include --with-xml2-lib\=/nix/store/rqg79h5w8lzrw1a774z2fdkyakyjnr8n-libxml2-2.9.14/lib --with-xml2-include\=/nix/store/036fl56k5xqbsqi9sm7ik3l6dbra4n45-libxml2-2.9.14-dev/include/libxml2 --with-xslt-lib\=/nix/store/x1aqrbn4qxxkrhg2lwdj6w951c3j7ydf-libxslt-1.1.35/lib --with-xslt-include\=/nix/store/8kpap8pd9g5cas277nxivh7pwhzxd48z-libxslt-1.1.35-dev/include --with-exslt-lib\=/nix/store/x1aqrbn4qxxkrhg2lwdj6w951c3j7ydf-libxslt-1.1.35/lib --with-exslt-include\=/nix/store/8kpap8pd9g5cas277nxivh7pwhzxd48z-libxslt-1.1.35-dev/include
 checking for whether -std=c99 is accepted as CFLAGS... yes
 checking for whether -Wno-declaration-after-statement is accepted as CFLAGS... yes
 checking for whether -g is accepted as CFLAGS... yes
 checking for whether -Winline is accepted as CFLAGS... yes
 checking for whether -Wmissing-noreturn is accepted as CFLAGS... yes
 Building nokogiri using system libraries.
 checking for gzdopen() in -lz... yes
 checking for xmlParseDoc() in -lxml2... yes
 checking for xsltParseStylesheetDoc() in -lxslt... yes
 checking for exsltFuncRegister() in -lexslt... yes
 *** extconf.rb failed ***
 Could not create Makefile due to some reason, probably lack of necessary
 libraries and/or headers.  Check the mkmf.log file for more details.  You may
 need configuration options.

 Provided configuration options:
         --with-opt-dir
         --without-opt-dir
         --with-opt-include
         --without-opt-include=${opt-dir}/include
         --with-opt-lib
         --without-opt-lib=${opt-dir}/lib
         --with-make-prog
         --without-make-prog
         --srcdir=.
         --curdir
         --ruby=/nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/bin/$(RUBY_BASE_NAME)
         --help
         --clean
         --prevent-strip
         --enable-system-libraries
         --disable-system-libraries
         --use-system-libraries
         --enable-system-libraries
         --disable-system-libraries
         --use-system-libraries
         --with-zlib-dir
         --without-zlib-dir
         --with-zlib-include=${zlib-dir}/include
         --with-zlib-lib=${zlib-dir}/lib
         --with-z-dir
         --without-z-dir
         --with-z-include
         --without-z-include=${z-dir}/include
         --with-z-lib
         --without-z-lib=${z-dir}/lib
         --with-zlib
         --without-zlib
         --with-xml2-dir
         --without-xml2-dir
         --with-xml2-include=${xml2-dir}/include
         --with-xml2-lib=${xml2-dir}/lib
         --with-xml2lib
         --without-xml2lib
         --with-xslt-dir
         --without-xslt-dir
         --with-xslt-include=${xslt-dir}/include
         --with-xslt-lib=${xslt-dir}/lib
         --with-xsltlib
         --without-xsltlib
         --with-exslt-dir
         --without-exslt-dir
         --with-exslt-include=${exslt-dir}/include
         --with-exslt-lib=${exslt-dir}/lib
         --with-exsltlib
         --without-exsltlib
 /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/2.7.0/rubygems/dependency.rb:311:in `to_specs': Could not find 'mini_portile2' (~> 2.8.0) among 56 total gem(s) (Gem::MissingSpecError)
 Checked in 'GEM_PATH=/nix/store/lyds5d5r7rwv0kiw6y9aq0m7q74wyhi8-ruby2.7.6-racc-1.6.0/lib/ruby/gems/2.7.0:/nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/gems/2.7.0:/nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0' , execute `gem env` for more information
         from /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
         from /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
         from extconf.rb:420:in `process_recipe'
         from extconf.rb:920:in `<main>'

 To see why this extension failed to compile, please check the mkmf.log which can be found here:

   /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/extensions/x86_64-linux/2.7.0/nokogiri-1.13.8/mkmf.log

 extconf failed, exit code 1

 Gem files will remain installed in /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/gems/nokogiri-1.13.8 for inspection.
 Results logged to /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/extensions/x86_64-linux/2.7.0/nokogiri-1.13.8/gem_make.out
 error: builder for '/nix/store/5938lbg8h3hahc3kl9wmdx3hfrg2ns9d-ruby2.7.6-nokogiri-1.13.8.drv' failed with exit code 1
 error: 1 dependencies of derivation '/nix/store/bbk02jdp4lwx2qpi7bpj040jwafm5k61-vagrant-2.3.0.drv' failed to build
 error: 1 dependencies of derivation '/nix/store/kdanpyprlgabxcilwl7wkq9jmm00vphq-vagrant-2.3.0.drv' failed to build
 error: 1 dependencies of derivation '/nix/store/2kr174b3jabq1awi5iwkxjw20rpg9w51-system-path.drv' failed to build
 error: 1 dependencies of derivation '/nix/store/ydg1ifqp88059vmxkpcl6953dfcfvskk-nixos-system-XXXXXX-22.11pre-git.drv' failed to build
 Build failed: Child process exited with error code: 100
       | Failed: Child process exited with error code: 100
[ERROR] Failed to complete requested operation - Last 1 lines of logs:
[ERROR]  failure) Child process exited with error code: 100
[ERROR] Failed to build XXXXXX - Last 20 lines of logs:
[ERROR]   stderr) Checked in 'GEM_PATH=/nix/store/lyds5d5r7rwv0kiw6y9aq0m7q74wyhi8-ruby2.7.6-racc-1.6.0/lib/ruby/gems/2.7.0:/nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/gems/2.7.0:/nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0' , execute `gem env` for more information
[ERROR]   stderr)         from /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/2.7.0/rubygems/dependency.rb:323:in `to_spec'
[ERROR]   stderr)         from /nix/store/31171zm830653xgdn3ckwxlg6shpxc70-ruby-2.7.6/lib/ruby/2.7.0/rubygems/core_ext/kernel_gem.rb:62:in `gem'
[ERROR]   stderr)         from extconf.rb:420:in `process_recipe'
[ERROR]   stderr)         from extconf.rb:920:in `<main>'
[ERROR]   stderr)
[ERROR]   stderr) To see why this extension failed to compile, please check the mkmf.log which can be found here:
[ERROR]   stderr)
[ERROR]   stderr)   /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/extensions/x86_64-linux/2.7.0/nokogiri-1.13.8/mkmf.log
[ERROR]   stderr)
[ERROR]   stderr) extconf failed, exit code 1
[ERROR]   stderr)
[ERROR]   stderr) Gem files will remain installed in /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/gems/nokogiri-1.13.8 for inspection.
[ERROR]   stderr) Results logged to /nix/store/39ajl6ln1dd5czasdhr3i3f97wkhhqcl-ruby2.7.6-nokogiri-1.13.8/lib/ruby/gems/2.7.0/extensions/x86_64-linux/2.7.0/nokogiri-1.13.8/gem_make.out
[ERROR]   stderr) error: builder for '/nix/store/5938lbg8h3hahc3kl9wmdx3hfrg2ns9d-ruby2.7.6-nokogiri-1.13.8.drv' failed with exit code 1
[ERROR]   stderr) error: 1 dependencies of derivation '/nix/store/bbk02jdp4lwx2qpi7bpj040jwafm5k61-vagrant-2.3.0.drv' failed to build
[ERROR]   stderr) error: 1 dependencies of derivation '/nix/store/kdanpyprlgabxcilwl7wkq9jmm00vphq-vagrant-2.3.0.drv' failed to build
[ERROR]   stderr) error: 1 dependencies of derivation '/nix/store/2kr174b3jabq1awi5iwkxjw20rpg9w51-system-path.drv' failed to build
[ERROR]   stderr) error: 1 dependencies of derivation '/nix/store/ydg1ifqp88059vmxkpcl6953dfcfvskk-nixos-system-XXXXXX-22.11pre-git.drv' failed to build
[ERROR]  failure) Child process exited with error code: 100
[ERROR] -----
[ERROR] Operation failed with error: Child process exited with error code: 100

I've also used https://github.com/NixOS/nixpkgs/pull/65800 an bundix docs as reference. You can find my current state with manual adjusted hashes here: https://github.com/SebTM/nixpkgs/tree/update/vagrant230_dev

The current version would be 2.3.3 btw.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/what-is-the-best-way-to-upgrade-a-package-in-nixpkgs/23657/1

Closed by https://github.com/NixOS/nixpkgs/pull/225136.


Intermittent Powershell Direct crashes - fault bucket<PHONE_NUMBER>781546140

Steps to reproduce
Have host OS of Windows 10, with guest Windows Server 2019 (script assumes that VM name starts with your user name)
Both have latest release PowerShell core (7.1.3)
Both domain joined in my case, I'm admin on both, running as admin on the host.
Run 3 or more instances of below script.
It looks complicated, but all it does is executes remote command in a loop, over and over. The complexity is to make it easier to detect different messages.
while($true)
{
    if(!$global:cred) { $global:cred = Get-Credential}
    try
    {
        Start-Process -Credential $global:cred -FilePath "cmd.exe" -ArgumentList "/c ECHO Hi"
        Write-Host "Credentials Ok"
        break;
    }
    catch
    {
        Write-Host "Credentials didn't work"
        Write-Host $_
        Start-Sleep -seconds 1
        $global:cred = $null
    }
    Write-Host "Will try to get credentials again"
}

[string] $state0 = "";
[string] $state = "StartingExecution";
$stateChange = Get-Date
while($true)
{
    if($state0 -ne $state)
    {
        [datetime]$now = Get-Date
        $duration = new-timespan -Start $stateChange -End $now

        Write-Host "$($now.ToString('HH:mm:ss.fff')) duration: $($duration.ToString())"
        Write-Host "$($now.ToString('HH:mm:ss.fff')) state: $state"
        $stateChange = Get-Date
        $state0 = $state
    }
    else
    {
        Start-Sleep -Milliseconds 200
    }

    $VmName = (Get-VM | Where {$_.Name.StartsWith($env:UserName)} | select -First 1 -ExpandProperty Name)
    if(-not $VmName)
    {
        $state = "No VM"
        continue;
    }

    try
    {
        #$result = Invoke-Command -ConfigurationName powershell.7 -ErrorAction Stop -ComputerName $VmName -Credential $cred { Write-Output ('Connected, powershell is '+ $PSVersionTable.PSVersion.ToString()) }
        $result = Invoke-Command -ConfigurationName powershell.7 -ErrorAction Stop -VMName $VmName -Credential $cred { Write-Output ('connected, powershell is '+ $PSVersionTable.PSVersion.ToString()) }
        $state = "VM $($VmName) $($result.ToString())"
    }
    catch
    {
        $lastError = $_
        $exceptionMessage = $lastError.Exception.Message
        $state = "VM $($VmName) $exceptionMessage"
    }
}

Expected behavior
PS C:\Users\ayeltsov> &"C:\Users\ayeltsov\OneDrive - Microsoft\Documents\ConnectToVm.ps1"

PowerShell credential request
Enter your credentials.
User: redmond\ayeltsov
Password for user redmond\ayeltsov: **********

Credentials Ok
16:04:12.137 duration: 00:00:00.0002203
16:04:12.137 state: StartingExecution
16:04:14.132 duration: 00:00:01.9818751
16:04:14.132 state: VM ayeltsov-051724 connected, powershell is 7.1.3
<and it should stay like this>

Actual behavior
After some time, one of the scripts will fail with:
The background process reported an error with the following message: "The Hyper-V socket target process has ended.".
Note: the crash is also occurring when VM has Powershell 5, so could be something in lower level (WinRm) or some long existing code.

Credentials Ok
16:03:27.474 duration: 00:00:00
16:03:27.474 state: StartingExecution
16:03:28.704 duration: 00:00:01.2269826
16:03:28.704 state: VM ayeltsov-051724 connected, powershell is 7.1.3
16:16:08.226 duration: 00:12:39.5190498
16:16:08.226 state: VM ayeltsov-051724 The background process reported an error with the following message: "The Hyper-V socket target process has ended.".
16:16:11.507 duration: 00:00:03.2769891
16:16:11.507 state: VM ayeltsov-051724 connected, powershell is 7.1.3
16:18:52.589 duration: 00:02:41.0766050
16:18:52.589 state: VM ayeltsov-051724 The background process reported an error with the following message: "The Hyper-V socket target process has ended.".
16:18:55.341 duration: 00:00:02.7475448
16:18:55.341 state: VM ayeltsov-051724 connected, powershell is 7.1.3

The "some time" can be minutes, and it can be hours.
I had a series of about 5 reproes in , then slightly modifies script for cleaner output (without changing the essence of what it's doing), and it's been running clean for last 30 minutes as I'm filling out this bug.

The guest will have following crash:

Fault bucket<PHONE_NUMBER>781546140, type 5
Event Name: PowerShell
Response: Not available
Cab Id: 0

Problem signature:
P1: powershell.exe
P2: 10.0.17763.1490
P3: System.Net.Sockets.SocketException
P4: Management.Automation.PSInvalidOperation
P5: ion.Remoting.RemoteSessionHyperVSocketServer..ctor
P6: ion.Remoting.RemoteSessionHyperVSocketServer..ctor
P7: Consol.. main thread
P8:
P9:
P10:

Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA679.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA6E7.tmp.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA783.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERA7E3.tmp.txt

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_powershell.exe_25fa62dbcb2fadf8e7c922c50a5cd95febfecc_00000000_82acab6a

Analysis symbol:
Rechecking for solution: 0
Report Id: b48f5802-8028-4d0e-a557-58a86ca64994
Report Status: 268435456
Hashed bucket: 034647c2e9c19e6b3d3782aca1eb7a9c
Cab Guid: 0

Environment data

Host:

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Guest:

PS C:\Windows\System32> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.3
PSEdition                      Core
GitCommitId                    7.1.3
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Impact
SQL Server team has internal tool to run tests in a semi-disposable VM (they live for a few hours to a few days), and overall, we see this error a few times a week.
While not a frequent error, it's difficult to harden the tool to expect this error for every interaction with VM and make every step idempotent. This is what we see in telemetry:
... | where Message contains "The Hyper-V socket target process has ended"
| summarize count() by bin(EventInfo_Time, 1d)
| order by EventInfo_Time desc ;

EventInfo_Time	count_
2021-03-23 00:00:00.0000000	2
2021-03-22 00:00:00.0000000	2
2021-03-11 00:00:00.0000000	1
2021-03-09 00:00:00.0000000	1
2021-03-03 00:00:00.0000000	2
2021-03-01 00:00:00.0000000	1
2021-02-26 00:00:00.0000000	1
2021-02-25 00:00:00.0000000	1
2021-02-24 00:00:00.0000000	2
2021-02-22 00:00:00.0000000	1
2021-02-19 00:00:00.0000000	2
2021-02-18 00:00:00.0000000	2

Since you have a crush dump you could internally communicate with PowerShell team.

What version and edition is the host os?


Introducing Docker compose

This is a starting point for using docker-compose instead (or in addition) to the example scripts. If we are happy with it, I can also update the readme to give the option to run the example using docker-compose -f docker-compose-3Silos-1Client.yml up and so on
Example with 3 Silos 1 Client:

Example with 2 Silos 1 Client:

This is great, thank you so much. Let me (as you proposed) test it locally and if it works fine, I'll probably propose that we remove all those shell scripts that do the same thing today.


Add elements hidden example with video, youtube, and ads to amp-lightbox-gallery

Add an example to <amp-lightbox-gallery> that includes <amp-youtube>, <amp-video> and <amp-ad>.

Thanks!


Problems with UTF8 characters on folders

Hi,
When my folder have portuguese characters like "coração grandão" if don't work and generate 404 error.
Can you solve support for utf8 characters?
Thanks.

It should work, see for example the test gallery:
https://github.com/saimn/sigal/blob/main/tests/sample/pictures/accentué/hélicoïde.jpg
Please provide more details.


drivers: serial: uart low power device control

All the PM_Device states of the stm32 UART are handled in a coherent way,. When the Device is going to suspend or Low Power, the uart must have finished its Transmission.

PM_DEVICE_ACTION_LOW_POWER:
PM_DEVICE_ACTION_SUSPEND:
In any other PM Device state, nothing special to do, but the PM_DEVICE_ACTION action should not be handled as an error.

Fixes https://github.com/zephyrproject-rtos/zephyr/issues/38382
Signed-off-by: Francois Ramu<EMAIL_ADDRESS>

The PM_DEVICE_ACTION_LOW_POWER should be handled like the PM_DEVICE_ACTION_SUSPEND : waiting for the Tx completion. Then the uart device is left unchanged, like for other PM_DEVICE_ACTION_   states.
In case of the PM_DEVICE_ACTION_FORCE_SUSPEND, the device has not to wait for the end of Tx.

As far as I can see the pm_device_busy APIs would not be sufficient to solve this case, since it seems that if UART is busy, then some system PM states can't be used, right? Could you provide some more details?

In the uart_stm32_pm_control,
the PM_DEVICE_ACTION_LOW_POWER requires the handling like the PM_DEVICE_ACTION_SUSPEND
Indeed, case PM_DEVICE_ACTION_RESUME is expecting a return 0
other PM_DEVICE_ACTION_TURN_OFF and PM_DEVICE_ACTION_FORCE_SUSPEND could be left as "ENOTSUP"

In the uart_stm32_pm_control,
the PM_DEVICE_ACTION_LOW_POWER requires the handling like the PM_DEVICE_ACTION_SUSPEND
Indeed, case PM_DEVICE_ACTION_RESUME is expecting a return 0
other PM_DEVICE_ACTION_TURN_OFF and PM_DEVICE_ACTION_FORCE_SUSPEND could be left as "ENOTSUP"

In theory, power_consumption(LOW_POWER) > power_consumption(SUSPENDED), so you need to take at least slightly different actions. What is happening here sounds like a workaround for an issue within the PM subsys, this is why I'd like to better understand the problem.

This is more than a WA, because the PM_DEVICE_ACTION_LOW_POWER  and PM_DEVICE_ACTION_RESUME were not handled. Now, returning 0, means that PM device is done.
For other  PM_DEVICE_ACTION  driver does not support until now.

What is happening here sounds like a workaround for an issue within the PM subsys, this is why I'd like to better understand the problem.

Here is the back trace:
#0  uart_stm32_pm_control (dev=0x8005a5c <__device_dts_ord_53>, action=PM_DEVICE_ACTION_LOW_POWER)
    at /local/mcu/zephyrproject/zephyr/drivers/serial/uart_stm32.c:1457
#1  0x0800539c in pm_device_state_set (dev=dev@entry=0x8005a5c <__device_dts_ord_53>,
    state=state@entry=PM_DEVICE_STATE_LOW_POWER) at /local/mcu/zephyrproject/zephyr/subsys/pm/device.c:145
#2  0x080012c0 in _pm_devices (state=state@entry=PM_DEVICE_STATE_LOW_POWER)
    at /local/mcu/zephyrproject/zephyr/subsys/pm/device.c:40
#3  0x0800541a in pm_low_power_devices () at /local/mcu/zephyrproject/zephyr/subsys/pm/device.c:64
#4  0x080011b6 in pm_system_suspend (ticks=<optimized out>) at /local/mcu/zephyrproject/zephyr/subsys/pm/power.c:225
#5  0x0800376c in pm_save_idle () at /local/mcu/zephyrproject/zephyr/kernel/idle.c:45

What is not clear to me is why we're receiving PM_DEVICE_ACTION_LOW_POWER as suspend request.
This case is not handled in none of the drivers today, so we're returning -ENOTSUP.
And for some unclear reason, as a consequence, test case is failed when run through twister.

@dcpleung Would you mind reviewing again as the new proposal has an impact on contract with API.

The PR  #38432  is a better solution to fix the problem

Closing as the PR #38432 is now merged and issue https://github.com/zephyrproject-rtos/zephyr/issues/38452 is closed too


Add net/if_utun.h and linux/if_tun.h constants for macos and linux platform

Add net/if_utun.h constants for macos platform.
Add linux/if_tun.h constants for linux platform.

@bors: r+

:pushpin: Commit 348bda9 has been approved by alexcrichton

:hourglass: Testing commit 348bda94107cfc4bffa94b186a442ab8d475772b with merge a58ce987c1202d8b99bae323494b0b7c3777192f...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing a58ce987c1202d8b99bae323494b0b7c3777192f to master...


Lambda support for Python servers

This PR exposes app.run_lambda() function to allow Python servers to run on Lambda. Closes https://github.com/awslabs/smithy-rs/issues/1750.
Why we use custom Rust runtime
We could also use builtin Python runtime, I decided to use custom Rust runtime because there was some performance overheads.
If you use Python runtime:

Receive requests with Python (Python)
Pass requests to Rust (Rust)
You basically receive a JSON object in API Gateway schema and you need to convert it to Hyper Request, this is handled by lambda_http crate but it is not designed to be reusable and requires some modification/copying (Rust)
Call Python handler to get result (Python)
Convert that result to Http response (Rust)
Pass that result to Python  (Python)
Finally return response to Lambda runtime to complete (Python)

If you use Rust runtime:

Receive Hyper Request with Rust (Conversion from JSON object to Hyper Request is already handled by lambda_http crate) (Rust)
Call Python handler to get result (Python)
Convert that result to Http response (Rust)
Finally return response to Lambda runtime to complete (Rust)

Testing
It can be tested with a Dockerfile similar to this:
FROM public.ecr.aws/lambda/python:3.8-x86_64

COPY app.py ${LAMBDA_TASK_ROOT}
# Shared library should be on the same folder with application code, so it can be imported
COPY lib_pokemon_service_server_sdk.so ${LAMBDA_TASK_ROOT}

RUN ln -s ${LAMBDA_TASK_ROOT}/app.py /app.py

# override `ENTRYPOINT` to not call Python runtime, so we can use Rust runtime
ENTRYPOINT [ "/var/lang/bin/python3.8" ]
CMD [ "/app.py" ]

This looks good and I am very happy to see we can use this from the pure python lambda context! Are you planning to add an example of the Python code here?

By example code you mean like having Lambda example of Pokemon service? If so, I think there is no need for that because only code change is changing app.run() to app.run_lambda(). What do you think?


Add unknown collations for MySQL 8 and MariaDB

Laravel 11 will change the default collations for MySQL 8 and MariaDB including a new database configuration entry for MariaDB (see https://github.com/laravel/framework/pull/48455)
MySQL 8: utf8mb4_0900_ai_ci (not supported by MariaDB and MySQL 5.7)
MariaDB: utf8mb4_uca1400_ai_ci (not supported by MySQL 8 and MySQL 5.7)
This PR informs Developers of this change so that they can mitigate the issue themself.

Is something blocking this PR or will this only be merged shortly before/after Laravel 11 release? @freekmurze

@freekmurze as Laravel 11 was released yesterday, I think it would be great to have this merged / reviewed.

Thanks!


Plugin closes when using "Copy as PNG" or "Copy as SVG"

Describe the bug
Both Copy as PNG and Copy as SVG functions (from menu or keyboard shortcut) seem to crash the plugin. Other copy actions work as expected. On version 116.6.3 of Figma and 134 of Tokens Studio.
To Reproduce

Select anything in a given file with the plugin running
Open the menu and select Copy/Paste as
Select either Copy as PNG or Copy as SVG form the menu
Plugin closes and displays a "Saving in progress" tooltip w/ option to open Console

Expected behavior
The plugin wouldn't be impacted by either copy function.
Screenshots or Screencasts
This is in a test account without the plugin actually hooked up. Same behavior happens in my actual account when logged in.
https://user-images.githubusercontent.com/117752829/219490859-38c0bf59-bf23-4f26-b4bf-5140165e819e.mov

This is unfortunately a bug that affects all Figma plugins and was reported to Figma a few months back.


chore: update comments for ClientIP function

What type of PR is this?

Check the PR title.

[x] This PR title match the format: <type>(optional scope): <description>
[x] The description of this PR title is user-oriented and clear enough for others to understand.
[ ] Attach the PR updating the user documentation if the current PR requires user awareness at the usage level. User docs repo

(Optional) Translate the PR title into Chinese.
更新RequestContext#ClientIP的代码注释
(Optional) More detailed description for this PR(en: English/zh: Chinese).

zh(optional): 更新RequestContext#ClientIP的代码注释，使其更加符合代码实现，减少误解
(Optional) Which issue(s) this PR fixes:

#1209
(Optional) The PR that updates user documentation:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.