R: Update CRAN and bioconductor packages

Motivation for this change
Update R package set
Things done
Ran nix-build test-evaluation.nix --dry-run

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Notify maintainers
cc @peti

Test builds of 064aebf2bb5c2dace7128e528e6f8a2211f6a146 are running at https://hydra.nixos.org/jobset/nixpkgs/r-updates.

There are 2000+ newly broken packages after this update. :-(
I added aedf9aa6ccbdc0ef8efc11c8e1468f36820f4526 to the r-updates branch. That should fix some of them. But it's probably a good idea to fix some more pivotal packages before we merge.

0537d3cdbe96524d53de856d5933bac99a07fd8f should improve matters some more ...

Thanks. Looks like between those two commits we're back up to about the same numbers as before.

Merged to master.


Incremental DOM vs. Closure Library

Out of curiosity, what value does Incremental DOM offer over Closure Library? It seems to do the same thing as goog.dom.createDom() and the newer goog.html.SafeHtml.create().
This might be good information to include in your Medium post and the Why Incremental DOM? section of your docs.

I think the about section is probably a better place for it. It does mention:

Incremental DOM is a library for expressing and applying updates to DOM trees.

(emphasis added). In contrast, the Closure library functionality allows you to express DOM trees, but provides no functionality for applying updates. It does also mention virtual dom and how the diff operation differs. Perhaps we could do something to make it a bit more clear?

Ok I think I have a better understanding of what this framework is trying to accomplish now. Thank you for answering my question.


[SPARK-47332][SS][Connect] Remove not needed logic in PythonStreamingRunner

What changes were proposed in this pull request?

Follow up of the discussion here: https://github.com/apache/spark/pull/45023#discussion_r1516609093
Clean up the logic in PythonStreamingRunner. workerFactory.createSimpleWorker already creates a non-daemon python process, so there is no need to set and reset the Spark Conf.
Why are the changes needed?

Code logic clean up.
Does this PR introduce any user-facing change?

No
How was this patch tested?

Existing tests should do their job
Was this patch authored or co-authored using generative AI tooling?

No

Pending CI

seems the test failure is related

Closing this since https://github.com/apache/spark/pull/45468 has the same change


I accepted higher fare button is not working

When I tap on "I accepted higher fare" button then a request is fired. After receiving response, nothing is happing and I am remaining on same UI.

Hello! A couple questions to clarify here:

Would you be able to take a screenshot of the UI that you are stuck on after the request is fired?
Do you have Configuration.setSandboxEnabled(true) in your AppDelegate?
What device and OS version are you using?

This information will help in identifying your issue.

Would you be able to take a screenshot of the UI that you are stuck on after the request is fired?
----I am stuck on same attached UI. Not navigating to any screen.

Do you have Configuration.setSandboxEnabled(true) in your AppDelegate?
--- We are setting NO for sandbox enabled.

What device and OS version are you using?
iOS 9 and 10 Beta, iPhone 6

@govindprasadguptacool
Have you configured the SURGE_CONFIRMATION_REDIRECT_URI on the app dashboard?
Please refer to here for more details.

Yes, please make sure you set the surge confirmation redirect uri on the app dashboard.
https://developer.uber.com/dashboard/


CMake: Don't build _CSwiftSyntax module

SwiftSyntax module now doesn't have the dependency to _CSwiftSyntax anymore. It's not needed for CMake builds.

@swift-ci Please test

superseded by https://github.com/apple/swift-syntax/pull/664


Unable to get SonarQube reviewer from Stash: java.util.concurrent.ExecutionException: java.net.ConnectException: https://agit.***.be:6088

When trying to get info from my BitBucket instance I get the following stack trace when running maven in debug mode.
[INFO] ANALYSIS SUCCESSFUL
[DEBUG] Post-jobs : org.******.plugins.stash.StashIssueReportingPostJob@79235a62
[INFO] Executing post-job org.******.plugins.stash.StashIssueReportingPostJob
[DEBUG] Trying to recover from failing to connect channel [id: 0x41d34189, /<IP_ADDRESS>:36896 :> agit.***.be/<IP_ADDRESS>:6088] with a retry value of true
[DEBUG] Trying to recover request DefaultHttpRequest(chunked: false)
GET /rest/api/1.0/users/*** HTTP/1.1
Content-Type: application/json
Connection: keep-alive
Host: agit.***.be:6088
Authorization: Basic ***wNjIwNTp5SGZPME42MEpocllTM0MxSHJKcw==
Accept: */*
User-Agent: AHC/1.0

[DEBUG] Channel Closed: [id: 0x41d34189, /<IP_ADDRESS>:36896 :> agit.***.be/<IP_ADDRESS>:6088] with attribute null
[DEBUG] Trying to recover from failing to connect channel [id: 0x3663691b, /<IP_ADDRESS>:36897 :> agit.***.be/<IP_ADDRESS>:6088] with a retry value of true
[DEBUG] Trying to recover request DefaultHttpRequest(chunked: false)
GET /rest/api/1.0/users/*** HTTP/1.1
Content-Type: application/json
Connection: keep-alive
Host: agit.***.be:6088
Authorization: Basic ***wNjIwNTp5SGZPME42MEpocllTM0MxSHJKcw==
Accept: */*
User-Agent: AHC/1.0

[DEBUG] Channel Closed: [id: 0x3663691b, /<IP_ADDRESS>:36897 :> agit.***.be/<IP_ADDRESS>:6088] with attribute null
[DEBUG] Trying to recover from failing to connect channel [id: 0xea7b0e95, /<IP_ADDRESS>:36898 :> agit.***.be/<IP_ADDRESS>:6088] with a retry value of true
[DEBUG] Unable to recover future NettyResponseFuture{currentRetry=6,
  isDone=false,
  isCancelled=false,
  asyncHandler=com.ning.http.client.AsyncCompletionHandlerBase@418eef65,
  nettyRequest=com.ning.http.client.providers.netty.request.NettyRequest@45b1738c,
  content=null,
  uri=https://agit.***.be:6088/rest/api/1.0/users/***,
  keepAlive=true,
  httpHeaders=null,
  exEx=null,
  redirectCount=0,
  timeoutsHolder=null,
  inAuth=false,
  statusReceived=false,
  touch=866670679}

[DEBUG] Failed to recover from connect exception: java.nio.channels.ClosedChannelException with channel [id: 0xea7b0e95, /<IP_ADDRESS>:36898 :> agit.***.be/<IP_ADDRESS>:6088]
[DEBUG] https://agit.***.be:6088
[DEBUG] Channel Closed: [id: 0xea7b0e95, /<IP_ADDRESS>:36898 :> agit.***.be/<IP_ADDRESS>:6088] with attribute null
[ERROR] Unable to get SonarQube reviewer from Stash: java.util.concurrent.ExecutionException: java.net.ConnectException: https://agit.***.be:6088
[DEBUG] Exception stack trace
[ERROR] Process stopped: no SonarQube reviewer identified to publish to Stash the SQ analysis

Hello Barry,

Have you defined the SonarQube user in Bitbucket?
Which permissions with this user?
Which Bitbucket version have you deployed?
Could you please make manually the rest call to " https://agit..be:6088/rest/api/1.0/users/ "?

Cheers,
Antoine

Hi,
I tried all options u described already. The user was defined and was a valid git user with read-write permissions. The BitBucket version was 4.4, which should be compatible and if a performed the call using curl the operation succeeded.
Seems there is a bug in the AsyncHttpClient. The SSL context throws an error but only for very specific certificates, due to security reasons and company policy I can't share the certificate which was signed by a trusted authority. If I patch the source code to use the default SSL context then everything goes well like in the snippet here:
Builder configBuilder = new Builder();
configBuilder.setSSLContext(SSLContext.getDefault());
this.httpClient = new AsyncHttpClient(configBuilder.build());

The StashClient itself was patched as follows
@@ -411,7 +420,14 @@ public class StashClient {
     requestBuilder.setRealm(realm);
   }

-  AsyncHttpClient createHttpClient(){
-    return new AsyncHttpClient();
+  AsyncHttpClient createHttpClient() {
+    Builder configBuilder = new Builder();
+    try {
+      configBuilder.setSSLContext(SSLContext.getDefault());
+    }
+    catch (NoSuchAlgorithmException e) {
+      LOGGER.error(e.getMessage());
+    }
+    return new AsyncHttpClient(configBuilder.build());
   }
 }

Maybe it has something to do with the fact that the server used a SHA1 certificate which expired on 1 january 2017, I tried with a similar certificate that expires one day before and that one does get accepted.

If I use the async-http-client artifact from org.asynchttpclient, then it works! Is it possible for me to create a pull request or will you guys update the implementation?

@acopet can you or somebody else please provide some feedback on my previous comment? the error was clearly not a configuration error and with another library it did work without tweaking the code (except a few lines for API compatibility)

Hello Barry,
Sorry for the delay, please go ahead with your contribution through a Pull Request.
Cheers,
Mathieu

@mathieusimon is it possible to merge @bdhoine branch ?

I'm facing the same issue here... It would be awesome to get this merged in.

Any update on this? I'm having the same issue.

We could handle similar issue by incrementing client's version up to 1.9.32:
<dependency>
  <groupId>com.ning</groupId>
  <artifactId>async-http-client</artifactId>
  <version>1.9.32</version>
</dependency>

No changes except pom.xml required.


Feat support acorn options sourceType and ecmaVersion

Hi,
can we add support for the acorn options sourceType and ecmaVersion?

sourceType: Indicate the mode the code should be parsed in. Can be either "script" or "module". This influences global strict mode and parsing of import and export declarations.
ecmaVersion
Indicates the ECMAScript version to parse. Must be either 3, 5, 6 (2015), 7 (2016), or 8 (2017). This influences support for strict mode, the set of reserved words, and support for new syntax features. Default is 7. [acorn]

This would allow us to annotate code with es6 modules like in the following snippet:
var AppController = (function () {
    function AppController($scope) {
        "ngInject";
        this.$scope = $scope;
        this.title = 'AppController';
    }
    AppController.prototype.$onInit = function () {
        console.log(this.$scope);
    };
    return AppController;
}());
export { AppController };

Currently if only need sourcetype: "module" but i thought it would be a good idea to support ecmaversion too. What do you think?
Cheers,
Fabian
CC @loxy

Closing as per #245 #253. May be available in a replacement project, or could otherwise be contributed there.
Thanks


Crash when destroying BrickDataManager

There is an intermittent exception happening when fragments are destroyed
Fatal Exception: java.lang.IllegalStateException
Observer androidx.recyclerview.widget.RecyclerView$x@2e03f6b was not registered.
android.database.Observable.unregisterObserver (Observable.java:69)

androidx.recyclerview.widget.RecyclerView.setAdapter (RecyclerView.java:1194)
com.wayfair.brickkit.BrickDataManager.onDestroyView (BrickDataManager.kt:399)

the issue appears to be right here.
https://github.com/wayfair/brickkit-android/blob/131ebd3c0e7a85e847e11d3559dd6229dc997396/BrickKit/bricks/src/main/java/com/wayfair/brickkit/BrickDataManager.kt#L399
Since this is a destroy step anyways, the best course of action might be to just catch the exception.

Agreed, looks like it'll be painful to get to the bottom of, and might be an Android specific change? The few versions of recyclerView.setAdapter that I checked weren't even calling unregisterObserver

Betting this is a Samsung issue :>


MessageBox Target fails if message written while splashscreen active

In a WPF project: (.NET 4.0, NLog 3.0.0)

Set an Image in project as a Splash-Screen
Provide a messageBox target
Log a message while in App constructor

MessageBox blinks and then disappears together with the Splash-Screen without giving the user a chance to read the message. App hangs, MainWindow never opens.

Feel free to reopen when we have more info.


Excessive Gate Checks against Tenants in Tenant Menu

Package
filament/filament
Package Version
v3.2.91
Laravel Version
10.48.12
Livewire Version
3.5.0
PHP Version
8.3.8
Problem description
When enabling tenancy and the tenancy menu, the gate checks multiply by the amount of tenants + 1 additional tenant. In that the loaded tenants are being tested for what resources that tenant can access. To replicate, just add a policy against any resource and that policy is checked against every tenant in the tenant menu. In my instance, I've gone from 66 gate checks to 3306 gate checks by enabling the tenancy.
Expected behavior
The tenant gate checks should only be happening against the current active tenant, we have returned the results of tenants already which are limited to the current user and as such the resource checks should not be done of the tenants in the tenant menu.
Steps to reproduce
Add tenancy, add a Policy to a model, this will show X checks, add a tenant and you'll see the checks multiply, add another tenant and they increase again.
Reproduction repository (issue will be closed if this is not valid)
https://github.com/tonypartridge/filament-demo/tree/main
Relevant log output
No response

Donate 💰 to fund this issue

You can donate funding to this issue. We receive the money once the issue is completed & confirmed by you.
100% of the funding will be distributed between the Filament core team to run all aspects of the project.
Thank you in advance for helping us make maintenance sustainable!

Issue is down to the tenant-menu.blade.php calling getUrl(). We need a new tenancy method 'getHomeUrl' or 'getTenantUrl' which returns the standard path generated for urls of the current tenant to avoid the excessive checks and the routing can be done on accessing the panel.


[Issue] - Health Checker HTML report doesn't appear

Provide Version Number
Exchange Health Checker v<IP_ADDRESS>0
Describe the issue
An error appears when opening the HTML report.
When you go to the page: https://microsoft.github.io/CSS-Exchange/Diagnostics/HealthChecker/, you will see one of the commands:
PS C:> Get-ExchangeServer | ?{$_.AdminDisplayVersion -Match "^Version 15"} | .\HealthChecker.ps1; .\HealthChecker.ps1 -BuildHtmlServersReport; .\ExchangeAllServersReport.html
The above command always worked. But there has been a change where the report now adds a date behind it. So it's not generic "ExchangeAllServersReport.html".
Expected behavior
The HTML report needs to open.
Script Output
HTML Report Location: .\ExchangeAllServersReport-20240329084414.html
.\ExchangeAllServersReport.html : The term '.\ExchangeAllServersReport.html' is not recognized as the name of a
cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.
At line:1 char:137

... hChecker.ps1 -BuildHtmlServersReport; .\ExchangeAllServersReport.html

                                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

CategoryInfo          : ObjectNotFound: (.\ExchangeAllServersReport.html:String) [], CommandNotFoundException
FullyQualifiedErrorId : CommandNotFoundException

Additional context
Change the command to a new one, where it will know what name is been given to the report, so it will open the correct report after it finishes.

Hi @worldsdream. You’re correct - the new html report contains a timestamp which is by design as we received multiple requests from customers to make the name unique. If you want to keep the old name, just run the script like this:
.\HealthChecker.ps1 -BuildHtmlServersReport -HtmlReportFile “ExchangeAllServersReport.html"

Hi Lukes,
Thanks for the information you provided.
When you run the command (see screenshot below):

The error appears:

So the command needs to change in that page, right?

@worldsdream yep, you're correct. The documentation is wrong. I will update it to reflect the latest changes in HealthChecker. Thanks for pointing this out!


Add new chains for CSUR

Related to #261
Deployments shown below are mock deployments and demonstration of contract verification process.
bsquared docs
OwnableCallForwarder 0xef455205966486F52f7951ba4C3517239B036835 has been verified on Etherscan.
AccessControlRegistry 0xcD7Df573B0F0bb4F2f8dFFF6650cDe8C77431730 has been verified on Etherscan.
Api3ServerV1 0x3ee097B82E270d82f829e5742cC16B7686247Ff2 has been verified on Etherscan.
bsquared-testnet
API N/A
lukso docs
OwnableCallForwarder 0xef455205966486F52f7951ba4C3517239B036835 has been verified on Etherscan.
AccessControlRegistry 0xcD7Df573B0F0bb4F2f8dFFF6650cDe8C77431730 has been verified on Etherscan.
Api3ServerV1 0x3ee097B82E270d82f829e5742cC16B7686247Ff2 has been verified on Etherscan.
lukso-testnet docs
OwnableCallForwarder 0xef455205966486F52f7951ba4C3517239B036835 has been verified on Etherscan.
AccessControlRegistry 0xcD7Df573B0F0bb4F2f8dFFF6650cDe8C77431730 has been verified on Etherscan.
Api3ServerV1 0x3ee097B82E270d82f829e5742cC16B7686247Ff2 has been verified on Etherscan.
polygon-sepolia-testnet docs
OwnableCallForwarder at 0xef455205966486F52f7951ba4C3517239B036835
AccessControlRegistry at 0xcD7Df573B0F0bb4F2f8dFFF6650cDe8C77431730
Api3ServerV1 at 0x3ee097B82E270d82f829e5742cC16B7686247Ff2
sei-evm-testnet docs
Although sei-evm-testnet utilizes contract verification, API3 contracts verification couldn't be verified.
Successfully verified contract Contract5 on the block explorer.
https://seitrace.com/address/0x1B127098D19A3D6A0417560fD7df2b927FafD933#code
taiko-hekla-testnet docs
OwnableCallForwarder 0xef455205966486F52f7951ba4C3517239B036835 has been verified on Etherscan.
AccessControlRegistry 0xcD7Df573B0F0bb4F2f8dFFF6650cDe8C77431730 has been verified on Etherscan.
Api3ServerV1 0x3ee097B82E270d82f829e5742cC16B7686247Ff2 has already been verified on Etherscan.

Changes have been made 👍


test: fix tcp_oob test flakiness

EAGAIN is an acceptable return value for read() and the test was not
taking it into account.
Fixes: https://github.com/libuv/libuv/issues/1602

This was reported a while ago but forgot to create a PR for it.

Landed https://github.com/libuv/libuv/commit/3db809682ba99b54db08dcea82142d2541f9e0d3. Thanks

Forgot to add the reviewer. Landed again in https://github.com/libuv/libuv/commit/d6dadc0739760fbe40ca56c96525ca301ae34be7.


JsonUtility doesn't support serialization of ScriptableObject

The following error is raised at ScriptableObjectSaveLoadTest.cs.
ScriptableObjectSaveLoadTest (0.059s)
---
System.ArgumentException : Cannot deserialize JSON to new instances of type 'SampleScriptableEntity.'
---
at (wrapper managed-to-native) UnityEngine.JsonUtility.FromJson(string,System.Type)
  at UnityEngine.JsonUtility.FromJson[T] (System.String json) [0x0000c] in /Users/builduser/buildslave/unity/build/artifacts/generated/bindings_old/common/JSONSerialize/JsonUtilityBindings.gen.cs:25
  at CAFU.KeyValueStore.Utility.JsonUtilitySerializer.Deserialize[TValue] (System.String text) [0x00002] in /Users/shu/Documents/Works/KidsStar/cafu_kvs/Assets/Scripts/Utility/JsonUtilitySerializer.cs:14
  at CAFU.KeyValueStore.Data.DataStore.KeyValueDataStore.GetEntity[TEntity] (System.String key) [0x00033] in /Users/shu/Documents/Works/KidsStar/cafu_kvs/Assets/Scripts/Data/DataStore/IKeyValueDataStore.cs:106
  at CAFU.KeyValueStore.Data.DataStore.KeyValueDataStoreTest.ScriptableObjectSaveLoadTest () [0x0005a] in /Users/shu/Documents/Works/KidsStar/cafu_kvs/Assets/Tests/EditMode/Scripts/Data/KeyValueDataStoreTest.cs:96
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] in <f826c2584fc94ec19a48a6576640bdc5>:0

According to the source code, JsonUtility seems not to support serialization of ScriptableObject.
https://github.com/Unity-Technologies/UnityCsReference/blob/master/Modules/JSONSerialize/Public/JsonUtility.bindings.cs

Sorry, I forgot to removing the ScriptableObject serialization test.
It was created for the other project's json serialization, but now the problem was solved by using pure c# object (eliminating the reference of ScriptableObject).
So there is no problem to removing the code.
Thanks!

Can we remove JsonConvertSerializer and dependency on umm@json_net?

Thanks! No problem!


Running as root / administrator

I know this is a corner case, but our app uses raw-sockets so needs to run as root. We can launch it manually from the shell using eg sudo, but would like participation from non-technical users. Are there any cross-platform suggestions on how to get this working? Thanks!

That sounds like something an installer (#33) would handle.


knowledge: Add taxonomy for banking_FM

If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

The user will ask if the given scenario adheres to Banking Industry Architecture Network(BIAN) Corpus.
Answer that based on the BIAN Corpus.
Provide the reasoning behind it and respond with relevant citation to answer the given question.

Input given at the prompt

   Which asset type is explained as "A portfolio holding financial instruments and cash and related number or amount, related to one or more customer investment portfolio agreements."?

Response from the original model

  The term "customer investment portfolio" refers to a collection of financial instruments, such as stocks, bonds, mutual funds, or other investment vehicles, that are held by a customer in an investment account. The asset type associated with this concept is likely "Investment Portfolio," which represents the total value of the customer's investments, including both financial instruments and cash. This asset type is typically managed by a financial institution, such as a bank or brokerage firm, on behalf of the customer. By maintaining an accurate and up-to-date Investment Portfolio, financial institutions can provide their customers with valuable insights and advice about their investments, help them manage risk, and achieve their financial goals.

Response from the fine-tuned model

  The asset type you're asking about is likely a "customer account". A customer account refers to a record kept by a financial institution or service provider to track, manage, and fulfill specific requests or services for individual customers. These accounts are often used to maintain relationships with customers, provide personalized service experiences, and ensure seamless transaction processing. By managing customer accounts effectively, businesses can enhance customer satisfaction, reduce operational costs, and promote long-term growth. "A portfolio holding financial instruments and cash and related number or amount, related to one or more customer investment portfolio agreements" refers to an investment portfolio that has agreed upon terms with its customers regarding their investments. This portfolio contains financial instruments that have been approved by the customers and is now being managed under the parameters set forth in those agreements. The term "number or amount" likely refers to the amount of money committed to be invested in the portfolio, which is now being managed and controlled as part of this investment agreement. The asset type "portfolio" itself represents the collection of financial instruments that make up the customer's investment strategy.

Contribution checklist

[x] The contribution was tested with ilab generate
[x] No errors or warnings were produced by ilab generate
[x] All commits are signed off (DCO)
[x] The qna.yaml file contains at least 5 seed_examples
[x] The qna.yaml file was linted and prettified (yaml-validator can do both)
[x] An attribution.txt file in the same folder as the qna.yaml file
[ ] Content does not include PII or otherwise sensitive or confidential information
[ ] Content does not include anything documented in the project's Avoid these Topics guidelines

@instructlab-bot precheck

Hi!
Thanks so much for the work you've done here. Unfortunately, there are a lot of internal specific IBM terminology links and possible knowledge here that we can't accept upstream. (not to mention the markdowns are not public and/or aren't from approved locations for knowledge submissions)
It looks like you meant to push this into an IBM downstream project for InstructLab. I would contact @joesepi or me (@awesome on Slack), and we can help submit this to the correct project.
Thanks again for all this work, but this isn't scoped for our upstream InstructLab Project.


Push gem to rubygems?

Hey there!
Don't think I have access anymore. Could you push the sidekiq4 version to rubygems?
Thaaanks guys

Done, Sir :wink:


Deescalate ovn-controller to hostmount-anyuid

This is not ready - need to understand how to overcome selinux violations that stop the pods from seeing into hostPath mounts from /home.

SELinux violations I get:
type=AVC msg=audit(1702658022.489:2857): avc:  denied  { write } for  pid=347668 comm="ovs-vsctl" name="db.sock" dev="vda4" ino=126157125 scontext=system_u:system_r:container_t:s0:c5,c26 tcontext=system_u:object_r:user_home_t:s0 tclass=sock_file permissive=0

I don't know of a way to overcome the SELinux violations on HostPath volumes while running as a scc!=privileged pod. The proper path forward to remove privileges would not involve any HostPath volumes at all. This would require a switch of ovsdb-server database to PVCs though. I'm abandoning this interim anyuid-hostmount PR.


fix(build): Set version without requiring sed

This change is part of the following stack:

#24

#25

#26

#27 ◀

#28

Change managed by git-spice.


Issue 1636 ens proxy

Fixes # .
Changes proposed in this PR:

this is supposed to be its own project, we can't integrate this here as we have a mix of Vercel & Netlify deployments.


Batch - an update?

Hi!
I was hoping for some insight into Batching.  If it's a committed upcoming feature (looks to be!) and when it'll be public (it's internal right now).
We started using it with 3.2.0-preview before you hid it under "internal" flags.  It's awesome!  We previously had our own custom workaround solution where we deployed a server-side javascript stored procedure in order to do batch operations.  But we don't need it any more, thanks to built-in batching.  Of course, we're stuck on 3.2.0-preview...…….. But that's okay, assuming it's still coming sooner or later?

The current plan is to make Batch part of the next SDK release which should happen sometime next week. It might get delayed if some major issue discovered before then.

Thanks for the speedy answer.
The answer itself couldn't have been more awesome, too.  Thanks!
Will leave this issue open until the release just so others can see your answer.

Please take a look at this PR.

Fantastic.  We've migrated to using the new TransactionalBatch (previously called Batch), and everything seem good.  Thanks!


getting 500 error code

Hi When I test this, im getting 500 error code, pasted the details below- pls help
Request: /api/info
Status: 200
Latency: 50 ms
Response Body:
{
"headers": {},
"statusCode": 500,
"isBase64Encoded": false
}
Response Headers:
{"X-Amzn-Trace-Id":"Root=1-586fb0b8-7c2ede09b684af111f360486","Content-Type":"application/json"}
Logs:
Execution log for request test-request
Fri Jan 06 14:59:04 UTC 2017 : Starting execution for request: test-invoke-request
Fri Jan 06 14:59:04 UTC 2017 : HTTP Method: GET, Resource Path: /api/info
Fri Jan 06 14:59:04 UTC 2017 : Method request path: {}
Fri Jan 06 14:59:04 UTC 2017 : Method request query string: {}
Fri Jan 06 14:59:04 UTC 2017 : Method request headers: {}
Fri Jan 06 14:59:04 UTC 2017 : Method request body before transformations:
Fri Jan 06 14:59:04 UTC 2017 : Endpoint request URI: https://lambda.eu-central-1.amazonaws.com/2015-03-31/functions/arn:aws:lambda:eu-central-1:768229625101:function:aws-gateway-usage-example-service-dev-sample/invocations
Fri Jan 06 14:59:04 UTC 2017 : Endpoint request headers: {x-amzn-lambda-integration-tag=test-request, Authorization=*********************************************************************************************************************************************************************************************************************************************************************************************************ec4362, X-Amz-Date=20170106T145904Z, x-amzn-apigateway-api-id=xkk2wzkyhl, X-Amz-Source-Arn=arn:aws:execute-api:eu-central-1:768229625101:xkk2wzkyhl/null/GET/api/info, Accept=application/json, User-Agent=AmazonAPIGateway_xkk2wzkyhl, X-Amz-Security-Token=FQoDYXdzEBcaDBszwWn6Sz39/mSgFiK9A1HMHqfaCgRikrCgXjo0OPIT9jlox2x67UbZ/ih7pfuFyix8Ai9ywjAvxyOhrM/gmaMpqQqmBC5vPtThMFNCDYITVf6rCkMCPrjPQQr6gLBtN9JTwF5QksnbYVanfW/dM1tVkD6WDj5MPjrzFclD4NV2QPnpvvLm1typgiJvHtkIITLaTdfEy6Kfg+/d/jjBxRbeBgvEEk4L6AbSDy6wDiP7z0LcjycqusLksZT5jYqvKiY5xD15+PYgHJB6r4fqo3iwL5JUgM8anvwnxRJb5luptuyIe5XTvLgU8aoFeCG3lhNGqvcnxwaAVPUYtkRSDnBOtiRFIgMXN6avOdJEdzKx3LNuN0F26iD0/ [TRUNCATED]
Fri Jan 06 14:59:04 UTC 2017 : Endpoint request body after transformations:
Fri Jan 06 14:59:04 UTC 2017 : Endpoint response body before transformations: {"headers":{},"statusCode":500,"isBase64Encoded":false}
Fri Jan 06 14:59:04 UTC 2017 : Endpoint response headers: {x-amzn-Remapped-Content-Length=0, x-amzn-RequestId=aa66bb66-d420-11e6-b89c-13ecea9fd739, Connection=keep-alive, Content-Length=55, Date=Fri, 06 Jan 2017 14:59:04 GMT, Content-Type=application/json}
Fri Jan 06 14:59:04 UTC 2017 : Method response body after transformations: {"headers":{},"statusCode":500,"isBase64Encoded":false}
Fri Jan 06 14:59:04 UTC 2017 : Method response headers: {X-Amzn-Trace-Id=Root=1-586fb0b8-7c2ede09b684af111f360486, Content-Type=application/json}
Fri Jan 06 14:59:04 UTC 2017 : Successfully completed execution
Fri Jan 06 14:59:04 UTC 2017 : Method completed with status: 200

Hi @vikasveerapur
Hard to say from the  logs and I can look into it in more detail Sunday night earliest, sorry.
A few things until then:

you deployed the gateway-usage-example, right? This does not have the endpoint "/api/info" but "/sample/health" - this however should not result in a 500 but a 404
how did you invoke the function? With "curl"? Can you try passing an accept header like this curl -H "Accept: application/json" ....
do you see the same issue when using the gateway-showcase example? Or rather can you try that one since it provides some additional logging.
how did you deploy? Or rather with version of serverless are you using?
did you use Gradle or Maven to build?

Hi @vikasveerapur
So I quickly tried the example and it's working as expected. I really think the problem is that you deployed to a different region and you need to adjust the region in the code. In jrestless-examples/aws/service/aws-service-usage-example-client/src/main/java/com/jrestless/aws/examples/BackendServiceFactory.java replace
private static final Regions BACKEND_SERVICE_REGION = Regions.EU_CENTRAL_1;

By
private static final Regions BACKEND_SERVICE_REGION = Regions.US_WEST_2;

I also assume you added the endpoint "/api/info" manually. I suggest you remove that again since it uses the integration type "LAMBDA" but it must use "LAMBDA_PROXY".
The full session after you changed the region and removed the manually added endpoint:
~$ cd jrestless-examples
~$ ./gradlew clean build
~$ cd aws/service/aws-service-usage-example
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading service .zip file to S3 (5.72 MB)...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.....
Serverless: Stack update finished...
Service Information
service: aws-service-usage-example
stage: dev
region: <REGION>
api keys:
  None
endpoints:
  None
functions:
  aws-service-usage-example-dev-api: arn:aws:lambda:<REGION>:<UID>:function:aws-service-usage-example-dev-api
~$ serverless deploy
~$ cd ../aws-service-usage-example-client
~$ serverless deploy
Serverless: Creating Stack...
Serverless: Checking Stack create progress...
.....
Serverless: Stack create finished...
Serverless: Uploading CloudFormation file to S3...
Serverless: Uploading service .zip file to S3 (8.99 MB)...
Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.................................
Serverless: Stack update finished...
Service Information
service: aws-service-usage-example-client
stage: dev
region: <REGION>
api keys:
  None
endpoints:
  ANY - https://<API_ID>.execute-api.<REGION>.amazonaws.com/dev/api/{proxy+}
functions:
  aws-service-usage-example-client-dev-api: arn:aws:lambda:<REGION>:<UID>:function:aws-service-usage-example-client-dev-api
~$ curl https://<API_ID>.execute-api.<REGION>.amazonaws.com/dev/api/info
{"value":"up\nand\nrunning"}

For completeness: AWS APIGW console should look like this after deploying with serverless:

If you test via APIGW console:

I hope this works, for you.
Thanks for reporting! I will improve logging and documentation, here, soon!.

assuming fixed => closing (please re-open if you still have any issues)

thanks a lot for your help. Good to close


can cargo-bisect-rustc respect the .cargo/config.toml?

can cargo-bisect-rustc respect the .cargo/config.toml?  (Should it already be doing so?)
As part of dissecting https://github.com/rust-lang/rust/issues/111888, I was looking into adding a linker flag to the rustc invocations via a .cargo/config.toml file, as described here: https://doc.rust-lang.org/cargo/reference/config.html#buildrustflags
But it seems from my local experiments that while my manual invocations of cargo are pulling in the config settings, the invocations that cargo-bisect-rustc emits do not seem to be including the rustflags specified there.

It should be working.  Can you share your exact .cargo/config.toml file?  Is your .cargo/config.toml in the project directory where you are running cargo-bisect-rustc? What is the output of cargo-bisect-rustc -vv -- build --verbose? Are you sure there aren't any environment variables (like RUSTFLAGS) that would take precedence over your config file?

Since this involves a bunch of files, let me see if I can put it into a repo for the repro.

(Hmm, I am now seeing evidence that it is doing something with the config file. Namely, when I added build.rustflags = "-Zwhoa" via the config file, all the builds fail, and when I remove it, then I see some builds succeed. So there must be something about the specific build flag I was trying to use, namely `rustflags="-Clink-arg=-Wl,--no-undefined-version", that was behaving in an unexpected fashion. That, or it was user error on my part. I'll figure out which case I'm in.)

Here's the repository I'm using for reproduction of the problem I'm seeing: https://github.com/pnkfelix/cbr-issue-284-demo
When I run cargo bisect rustc, it ends up flagging a regression in nightly-2023-03-12 (and then tracks the problem down further from there). The problem is that the flagging of the regression there only happens if you are not passing the rustflags that I have requested. And I have confirmed that manually invoking cargo build for the nightlies in question, with that .cargo/config.toml in place, does show the regression continuing to earlier than 2023-03-12.
transcript
cbr-issue-284-demo$ cargo bisect-rustc --preserve --start 1.63.0 --end 1.71.0 --access github
translating --start=1.63.0 to 2022-06-24
translating --end=1.71.0 to 2023-05-27
checking the start range to find a passing nightly
installing nightly-2022-06-24
testing...
RESULT: nightly-2022-06-24, ===> No

checking the end range to verify it does not pass
installing nightly-2023-05-27
testing...
RESULT: nightly-2023-05-27, ===> Yes

169 versions remaining to test after this (roughly 7 steps)
installing nightly-2022-12-09
testing...
RESULT: nightly-2022-12-09, ===> No

85 versions remaining to test after this (roughly 6 steps)
installing nightly-2023-03-03
testing...
RESULT: nightly-2023-03-03, ===> No

43 versions remaining to test after this (roughly 6 steps)
installing nightly-2023-04-14
testing...
RESULT: nightly-2023-04-14, ===> Yes

21 versions remaining to test after this (roughly 5 steps)
installing nightly-2023-03-24
testing...
RESULT: nightly-2023-03-24, ===> Yes

11 versions remaining to test after this (roughly 4 steps)
installing nightly-2023-03-13
testing...
RESULT: nightly-2023-03-13, ===> Yes

5 versions remaining to test after this (roughly 3 steps)
installing nightly-2023-03-08
testing...
RESULT: nightly-2023-03-08, ===> No

3 versions remaining to test after this (roughly 2 steps)
installing nightly-2023-03-10
testing...
RESULT: nightly-2023-03-10, ===> No

2 versions remaining to test after this (roughly 1 steps)
installing nightly-2023-03-11
testing...
RESULT: nightly-2023-03-11, ===> No

1 versions remaining to test after this (roughly 1 steps)
installing nightly-2023-03-12
testing...
RESULT: nightly-2023-03-12, ===> Yes

searched toolchains nightly-2022-06-24 through nightly-2023-05-27

********************************************************************************
Regression in nightly-2023-03-12
********************************************************************************

fetching https://static.rust-lang.org/dist/2023-03-11/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2023-03-11: 40 B / 40 B [=====================================================================================] 100.00 % 533.26 KB/s converted 2023-03-11 to ff4b772f805ec1e1c1bd7e189ab8d5a4e3a6ef13
fetching https://static.rust-lang.org/dist/2023-03-12/channel-rust-nightly-git-commit-hash.txt
nightly manifest 2023-03-12: 40 B / 40 B [=======================================================================================] 100.00 % 1.56 MB/s converted 2023-03-12 to 8a73f50d875840b8077b8ec080fa41881d7ce40d
looking for regression commit between 2023-03-11 and 2023-03-12
fetching (via remote github) commits from max(ff4b772f805ec1e1c1bd7e189ab8d5a4e3a6ef13, 2023-03-09) to 8a73f50d875840b8077b8ec080fa41881d7ce40d
ending github query because we found starting sha: ff4b772f805ec1e1c1bd7e189ab8d5a4e3a6ef13
get_commits_between returning commits, len: 6
  commit[0] 2023-03-10: Auto merge of #108974 - flip1995:clippyup, r=Manishearth
  commit[1] 2023-03-11: Auto merge of #104527 - ferrocene:pa-more-licenses, r=pnkfelix
  commit[2] 2023-03-11: Auto merge of #108998 - matthiaskrgr:rollup-sxbdulg, r=matthiaskrgr
  commit[3] 2023-03-11: Auto merge of #109001 - matthiaskrgr:rollup-a3agnwp, r=matthiaskrgr
  commit[4] 2023-03-11: Auto merge of #109015 - matthiaskrgr:rollup-xu2s31g, r=matthiaskrgr
  commit[5] 2023-03-11: Auto merge of #109019 - matthiaskrgr:rollup-ihjntil, r=matthiaskrgr
validated commits found, specifying toolchains

checking the start range to verify it passes
installing ff4b772f805ec1e1c1bd7e189ab8d5a4e3a6ef13
testing...
RESULT: ff4b772f805ec1e1c1bd7e189ab8d5a4e3a6ef13, ===> No

checking the end range to verify it does not pass
installing 8a73f50d875840b8077b8ec080fa41881d7ce40d
testing...
RESULT: 8a73f50d875840b8077b8ec080fa41881d7ce40d, ===> Yes

3 versions remaining to test after this (roughly 2 steps)
installing 19c53768af6e48514238e4224b5bf5ecd51bc7b1
testing...
RESULT: 19c53768af6e48514238e4224b5bf5ecd51bc7b1, ===> No

2 versions remaining to test after this (roughly 1 steps)
installing e350fe4e608b653da47e8012d13ef701613e717b
testing...
RESULT: e350fe4e608b653da47e8012d13ef701613e717b, ===> Yes

searched toolchains ff4b772f805ec1e1c1bd7e189ab8d5a4e3a6ef13 through 8a73f50d875840b8077b8ec080fa41881d7ce40d

********************************************************************************
Regression in e350fe4e608b653da47e8012d13ef701613e717b
********************************************************************************
[...]

The problem with all of the above is that when I manually run the same bisector builds directly, it does respect the rustflags I've fed in via the .cargo/config.toml, and thus I do not get the same bisection at all, as shown below.
cbr-issue-284-demo$ cargo +bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu build
   Compiling ext_lib v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/ext_lib)
   Compiling pm v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/pm)
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/ubuntu/.local/bin:/home/ubuntu/bin:/home/ubuntu/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/\
usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" VSLANG="1033" "cc" "-Wl,--version-script=/tmp/rustczrLCXw/list" "-Wl,--no-undefined-version" "-m64" "/tmp/rustczrLCXw/symbols.o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-2\
84-demo/target/debug/deps/pm-a6fdaa95ba624adc.25m1du48ofwx9t78.rcgu.o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.aueuwdyf59ve1jf.rcgu.rmeta" "/home/ubuntu/Dev/Rust/Linking/issue_11188\
8/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.whh49e3mqtk71q7.rcgu.o" "-Wl,--as-needed" "-L" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps" "-L" "/home/ubuntu/.rustup/toolchain\
s/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-f3e505f\
6e0fe495a.rlib" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/libext_lib-35abe9072087b085.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknow\
n-linux-gnu/lib/libstd-8c5537594e196f18.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-62f45bff484152d4.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightl\
y-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-05da49d3cca73bff.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-616c9bd2710\
f0982.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-d9df84ec1a8a7a8f.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu\
/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-0242ef3eea1e9db2.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-127f477a16f3f8f8.rlib" "/home/ubuntu/.rus\
tup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-18a1148b43c51528.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-l\
inux-gnu/lib/libhashbrown-c5f20f2274212453.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-4483c8bc4648568f.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nigh\
tly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-94da6a76998341a3.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspa\
ce_alloc-22a9646e8f27a6e4.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-c9ee17ad302be816.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-\
unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-323da837c64ef472.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-c165d64169f217c3.rlib" "/home/ubu\
ntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-8212dcd77adfe144.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknow\
n-linux-gnu/lib/librustc_std_workspace_core-522518611024dce5.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-05898138a596088a.rlib" "/home/ubuntu/.rustup/toolchains/bi\
sector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-b78d27aa9e5e005b.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/ho\
me/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-12-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/libpm-a6fdaa95ba624adc.so" "-Wl,\
--gc-sections" "-shared" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-Wl,--no-undefined-version"
  = note: /usr/bin/ld: add: undefined version:
          /usr/bin/ld: failed to set dynamic section sizes: bad value
          collect2: error: ld returned 1 exit status

error: could not compile `pm` (lib) due to previous error

cbr-issue-284-demo$ cargo +bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu build
   Compiling ext_lib v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/ext_lib)
   Compiling pm v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/pm)
error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin:/home/ubuntu/.local/bin:/home/ubuntu/bin:/home/ubuntu/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/\
usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" VSLANG="1033" "cc" "-Wl,--version-script=/tmp/rustcoyzLtU/list" "-m64" "/tmp/rustcoyzLtU/symbols.o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-\
a6fdaa95ba624adc.5al9jrduxl99wxw2.rcgu.o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.nwsywfpb33y4i23.rcgu.rmeta" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue\
-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.2dygysboqzzg2ryy.rcgu.o" "-Wl,--as-needed" "-L" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps" "-L" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-1\
1-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-f3e505f6e0fe495a.rlib" "/home/ubunt\
u/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/libext_lib-35abe9072087b085.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-8c553\
7594e196f18.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-62f45bff484152d4.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-\
linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-05da49d3cca73bff.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-616c9bd2710f0982.rlib" "/home/ubuntu/.r\
ustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-d9df84ec1a8a7a8f.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-\
linux-gnu/lib/libgimli-0242ef3eea1e9db2.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-127f477a16f3f8f8.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nigh\
tly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_detect-18a1148b43c51528.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-c5\
f20f2274212453.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-4483c8bc4648568f.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknow\
n-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-94da6a76998341a3.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-22a9646e8f27a6e4.rl\
ib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-c9ee17ad302be816.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustli\
b/x86_64-unknown-linux-gnu/lib/libcfg_if-323da837c64ef472.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-c165d64169f217c3.rlib" "/home/ubuntu/.rustup/toolchains/bisec\
tor-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-8212dcd77adfe144.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std\
_workspace_core-522518611024dce5.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-05898138a596088a.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2023-03-11-x8\
6_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-b78d27aa9e5e005b.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/ubuntu/.rustup/toolchains\
/bisector-nightly-2023-03-11-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/libpm-a6fdaa95ba624adc.so" "-Wl,--gc-sections" "-shared" "-W\
l,-z,relro,-z,now" "-nodefaultlibs" "-Wl,--no-undefined-version"
  = note: /usr/bin/ld: add: undefined version:
          /usr/bin/ld: failed to set dynamic section sizes: bad value
          collect2: error: ld returned 1 exit status

error: could not compile `pm` (lib) due to previous error

cbr-issue-284-demo$ cargo +bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu build
   Compiling ext_lib v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/ext_lib)
   Compiling pm v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/pm)
error: linking with `cc` failed: exit status: 1
  |
  = note: "cc" "-Wl,--version-script=/tmp/rustct0Ej9z/list" "-m64" "/tmp/rustct0Ej9z/symbols.o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.h78a8sw74ecqtbw.rcgu.o" "/home/ubuntu/Dev/Rus\
t/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.42b2doemlinbp6pa.rcgu.rmeta" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/pm-a6fdaa95ba624adc.5b382f78u2k6xo\
v6.rcgu.o" "-Wl,--as-needed" "-L" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps" "-L" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gn\
u/lib" "-Wl,-Bstatic" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libproc_macro-b92aa700084b5bc9.rlib" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-28\
4-demo/target/debug/deps/libext_lib-35abe9072087b085.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-5edc694ff0621ed8.rlib" "/home/ubuntu/.rustup/toolchains/bisector-ni\
ghtly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-1118a539d55d2733.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libobject-1\
e16815c933606a0.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libmemchr-7dda930da173cd7f.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-li\
nux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libaddr2line-7deef5f688bf2cd5.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libgimli-a1f236732a050fbb.rlib" "/home/ubuntu/.r\
ustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-2d0ddbffdb30be11.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unk\
nown-linux-gnu/lib/libstd_detect-681566937bcf15b7.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-d8b255130cf77303.rlib" "/home/ubuntu/.rustup/toolchains/bisector\
-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libminiz_oxide-e79cc122e409037d.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libadler-\
6918a62ad5cae6e0.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-7737bd6c876aa5d1.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-\
09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-5b1d741435bd8321.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-cb9ee6e5722842ca.rlib\
" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6d46d38f739892fe.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x8\
6_64-unknown-linux-gnu/lib/liballoc-92ba89a1b07f23b1.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-522518611024dce5.rlib" "/home/ubuntu/.rustup/t\
oolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-05898138a596088a.rlib" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/li\
b/libcompiler_builtins-bc012bb1dd8faba2.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L" "/home/ubuntu/.rustup/toolchains/bisector-nightly-2022-12-09-x86_64-unknown-linux-gnu/lib/rustl\
ib/x86_64-unknown-linux-gnu/lib" "-o" "/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/target/debug/deps/libpm-a6fdaa95ba624adc.so" "-Wl,--gc-sections" "-shared" "-Wl,-zrelro,-znow" "-nodefaultlibs" "-Wl,--no-undefined-version"
  = note: /usr/bin/ld: add: undefined version:
          /usr/bin/ld: failed to set dynamic section sizes: bad value
          collect2: error: ld returned 1 exit status

error: could not compile `pm` due to previous error

cbr-issue-284-demo$ cargo +bisector-nightly-2022-06-24-x86_64-unknown-linux-gnu build
   Compiling ext_lib v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/ext_lib)
   Compiling pm v0.1.0 (/home/ubuntu/Dev/Rust/Linking/issue_111888/demo_bisect_issue/cbr-issue-284-demo/pm)
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s

To be clear: At this point I am forced to acknowledge that something must be happening with the .cargo/config.toml, because when I put in nonsense as the rustflags setting, it causes the build to fail reliably.
So there must be some really weird interaction with the specific rustflags setting I happen to be using? It is goofy.

The reason you are seeing different behavior when running manually is because you are not passing the --target flag. When you don't pass the --target flag, rustflags are passed to all rustc invocations. When you do pass the --target flag, rustflags are not passed to host invocations (proc-macros, build scripts, and their dependencies). cargo-bisect-rustc always passes --target.
This happens because cargo tries to share dependencies when --target is not specified to reduce build times.

BTW, if you need to pass rustflags to proc-macros even when --target is used, you can do something like this:
[target.'x86_64-unknown-linux-gnu']
rustflags="-Clink-arg=-Wl,--no-undefined-version"
[host]
rustflags="-Clink-arg=-Wl,--no-undefined-version"

And pass the -Zhost-config -Ztarget-applies-to-host flags.

Hmm, okay. I can totally understand how this arises now.
I'm trying to figure out what is the best way to address overall issue here.
In particular:

I didn't realize that cargo-bisect-rustc always passes --target
I don't think the cargo-bisect-rustc doc ever says that it always passed --target
Even if the docs did say that, I doubt I would have been able to figure out this from that.
So, I'd like to try to fix that. I don't want users to have to file issues or hop onto zulip in order to learn about details like this.

Here's the heart of my complaint: The usage model that I think we try to promote is: "If you're doing cargo build, you can just do cargo-bisect-rustc build to bisect the same experience.
I can absolutely understand there being deviations between what actually happens versus the illusion we are trying to present to users.
... Maybe all I want here is some section of the doc where we spell out ways in which cargo CMD may deviate from cargo-bisect-rustc CMD ? Even as an FAQ entry or something?

I think at least documenting it would be good. One place I forgot to mention this is in https://rust-lang.github.io/cargo-bisect-rustc/usage.html#scripting, where it should be mentioned that scripts don't need to specify --target because CARGO_BUILD_TARGET is set (similar to how the toolchain also doesn't need to be specified).  If you want to add an FAQ, that would be good, too. I'm not sure how likely that is to help the general case, since I assume almost nobody is going to read the entire documentation and retain every nuance.
It seems a little strange to me that it unconditionally sets the target, but it looks like that was done in part for https://github.com/cross-rs/cross/issues/699, where cross would break because rustup does not support components for custom toolchains, and would error when cross ran rustup target list. That seems like a bit of a convoluted issue involving several other tools. I could see a reasonable alternative would be to stop unconditionally setting CARGO_BUILD_TARGET when --target is not specified, and document that cross users need to set it in a script (there could be another "Example" chapter on using cross). How does that sound?

I'm not sure how likely that is to help the general case, since I assume almost nobody is going to read the entire documentation and retain every nuance.

I agree with this point. That is, we should adjust the documentation to reflect what the tool does (though that might itself change, as you outline in your second paragraph), but we cannot rely on people to read the docs.
However, that does lead me to this question: Is there any verbosity level at which cargo bisect rustc will print out the contextual parameters it is setting (i.e. what environment variables it is setting and what command line switches it is passing)? I think that could have helped me track this down, if I had thought to use it, but as far as I can tell no matter how many levels of --verbose I pass along, I don't get feedback about this --target/CARGO_BUILD_TARGET business...

I could see a reasonable alternative would be to stop unconditionally setting CARGO_BUILD_TARGET when --target is not specified, and document that cross users need to set it in a script (there could be another "Example" chapter on using cross).

I'll have to think about this. It sounds plausible on its surface. What's the migration path for helping current users deal with the changes here, it is just a matter of including it in the release notes for the new version, or are there more direct ways to give useful feedback to the people relying on the current behavior?

However, that does lead me to this question: Is there any verbosity level at which cargo bisect rustc will print out the contextual parameters it is setting

I don't think so. Improving that also seems good to me.

What's the migration path for helping current users deal with the changes here, it is just a matter of including it in the release notes for the new version, or are there more direct ways to give useful feedback to the people relying on the current behavior?

I'm not sure. I don't have a sense of how often people are depending on the current behavior. I can't think of anything besides cross that would be affected, but I was surprised to see that it was affected.


v2.ODataListBinding: Operation Mode "Client" Doesn't Consider Server-side Paging

URL (minimal example if possible)
https://jsbin.com/tomajef/edit?js,output
Steps to reproduce the problem:

Open: https://services.odata.org/V2/Northwind/Northwind.svc/Customers?$format=json
See that the service didn't return all entities but appends the property "__next" for the client to get the next batch of entities.
Open the minimal example. The sample has the defaultOperationMode: "Client".
Observe that the list binding doesn't load this many items.

What is the expected result?
Even with the operation mode "Client", the ODataListBinding (V2 as well as V4*) checks whether there are more entities to fetch ("__next" / "@odata.nextLink").
* Currently doesn't support the "Client" operation mode.
What happens instead?
Client mode ignores server-side paging.
Any other information? (attach screenshot if possible)
Once the line defaultOperationMode: "Client" is removed, you can see that the list binding fetches more and more entities.
However, in the client operation mode, the bLengthFinal is immediately set to true without checking if there is "__next".
https://github.com/SAP/openui5/blob/00a454ef142f77d33c42d80a78e6dff766acc753/src/sap.ui.core/src/sap/ui/model/odata/v2/ODataListBinding.js#L615-L627

Hello boghyon,
Thank you for sharing this finding. I've created an internal incident<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards,
Iliana

Hello boghyon,
The v2.ODataListBinding does not support __next links and there are no plans to support them in the near feature.
The back-end needs to respond all entries at once in the client mode.
Best regards,
Sven

Hi boghyon, thanks for your input. As has been commented, we recommend the "server" mode for such scenarios and don't expect to enhance the "client" mode for server-side paging.


Can't Create New Amplify Apps via Terraform or Console - BadRequestException: Rate exceeded while calling CreateApp

Before opening, please confirm:

[X] I have checked to see if my question is addressed in the FAQ.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

App Id
NEW_APP
AWS Region
us-east-2
Amplify Hosting feature
Console, Deployments
Frontend framework
Angular
Next.js version
N/A
Next.js router
N/A
Describe the bug
Since a few days ago I am no longer able to create new Amplify apps either via my CI/CD process (terraform) or via the AWS console. Every time I try to create it I get the following error:
Error: creating Amplify App (frontend): BadRequestException: Rate exceeded while calling CreateApp, please slow down or try again later.
I even deleted and re-created an existing working app to make sure that it wasn't something weird with my repo.
Expected behavior
I should be able to create new amplify apps.
Reproduction steps

Go to the amplify app space in the AWS console and click create new app
Follow the app creation wizard using GitLab and an existing repo as the code source.
Leave all settings at their defaults.
Click Save and Deploy
Error: Rate exceeded while calling CreateApp, please slow down or try again later.

Build Settings
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: dist
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

Log output

# Put your logs below this line
# This is the output from terraform

Plan: 1 to add, 0 to change, 0 to destroy.
aws_amplify_app.frontend: Creating...
╷
│ Error: creating Amplify App (frontend): BadRequestException: Rate exceeded while calling CreateApp, please slow down or try again later.
│
│   with aws_amplify_app.frontend,
│   on main.tf line 15, in resource "aws_amplify_app" "frontend":
│   15: resource "aws_amplify_app" "frontend" {
│
╵

# This is the output from the AWS console:
Houston, there's a problem
Rate exceeded while calling CreateApp, please slow down or try again later.

Additional information
No response

Does Amplify have a really aggressive rate limit that I missed somewhere? I just tried to deploy it again since it's been a couple of days and it worked both through the AWS Console & through Terraform to create one of my two apps. The 2nd app failed to be created due to the same error.

Hi @ckchessmaster 👋 , thanks for raising this!
We have a default rate limit on the apps creation of 25 per hour as stated here: https://docs.aws.amazon.com/general/latest/gr/amplify.html#service-quotas-amplify.
Based on the information provided, it looks like you are only trying to deploy 2 apps using Terraform? Can you share your AWS Account ID privately via a DM on our community discord server? My username is Jay Raval.

Okay yeah, so today I created an app via the AWS console, deleted it then created it again via Terraform, and then couldn't create my second app. So unless Terraform is doing something strange I am definitely under the 25/day limit. I DMed you on discord thanks!

@ckchessmaster As discussed on discord, in order to further troubleshoot your issue please reach out to the AWS Support team: https://aws.amazon.com/support for additional assistance. Thank you.


Update README

@nolimits4web it may help some users that you add a reference to the last 2.x.x release and the Swiper2 branch in the current README.
There are lots of projects supporting old platforms and Swiper2 is still really one of the best existing.
and as always thank 4 u work, always awesome.

Sure, will add it tomorrow

And please make the API doc for 2.x.x available. I'm currently in a project with version 2.x.x and need that docs.

@tpinne they are here https://github.com/nolimits4web/Swiper/blob/Swiper2/API.md

Information about Swiper 2 added


fix filesystem issues after instance reboot

fixes #114 .
was caused by fstab records being overwritten when writing the /mnt/efs.
changed to append the new record.

Thanks @florpor! It didn't occur to me reading the code that fstab should have important stuff on it that we didn't want to override 🤦♂ nice catch!


Add fedora spec for packaging

Addresses #121 (in relation to Fedora)
Adds a .spec file that can be used to compile the latest git version of Lapce for Fedora in copr.
I need to do some testing and add possibly it to my copr repository which I mentioned in #121
Corresponding package for master builds can be found here: https://copr.fedorainfracloud.org/coprs/titaniumtown/lapce/package/lapce-git/

Think this should've been squashed and merged, but that works too haha


Fix compatibility issue on flutter dev/master channel

Changes
Add the unimplemented method in raw_editor.dart,
It should fix issue #161 .

No to master branch.
As I mentioned, please maintain another branch

check https://github.com/singerdmx/flutter-quill/pull/136

Please use branch dev
See https://github.com/singerdmx/flutter-quill/commits/dev


CtCarrier deprecated on iOS 16

CTTelephonyNetworkInfo().serviceSubscriberCellularProviders is deprecated and has no replacement (see here).
It is now being stubbed with a value of '--' (see this).
Is there anything that can be done about this?
This is what I am doing as a workaround
String? deviceCountryCode = await DeviceRegion.getSIMCountryCode();
if (deviceCountryCode == null) return null;

if (deviceCountryCode == '--') {
  deviceCountryCode = WidgetsBinding.instance.platformDispatcher.locale.countryCode;
}

Hello @Maatteogekko. Thank you for the update.
I'm little busy these days, I can check this part later this week. Will let you know.

@Maatteogekko there is no chance to obtain sim country code from iOS 16.0. I've updated package to return Locale.current.region.identifier.


Fix to allow library to work with Python3

Any update here? Would be great to use this on Python 3.

This hasn't been updated in years, so I don't know if the original programmer is actually maintaining it anymore :)

That's unfortunate. I'd be happy to help maintain the library if @seme0021 is interested.

Sorry, have not been getting notifications for this project!


fix(publish): display headings pleasantly when containing non-textonly content types

will fix

[[dendron://incubator/task.2022.08.07.code-in-heading-breaks-the-formatting]]
[[dendron://private/task.2022.08.29.revisit-headings-whitespace]]

Pull Request Checklist
If you are a community contributor, copy and paste the PR template from Dendron Community PR Checklist and add it to the body of the pull request.
If you are a team member, copy and paste the template from Dendron Extended PR Checklist.
To copy the template, click on the Raw button on the gist to copy the plaintext version of the template to this PR.

for the ui changes, can we also add playwright tests when this is ready?

looks like snapshot tests are failing

looks like playwright test are failing?

looks like playwright test are failing?

The error https://github.com/dendronhq/dendron/actions/runs/3089152419/jobs/4996433156#step:10:32 gets resolved when I revert https://github.com/dendronhq/dendron/commit/27662dc9de#diff-48c116cf8058e55ab46b8ace6daf7fad4141f3f1e1d1c089b8458ec0135547a3L52-R56. The actuall error happens in DendronTOC and possibly conflicts by having antd using 17.x @types/react and DendonTOC 18.x.
What was the reason we upgraded @types/react ?

we can either upgrade antd or downgrade types/react in nextjs. either option works, we might run into subtle differences in rendering if upgrading antd

There are quite a few minor releases we are jumping up, and I see a lot of deprecations in their releases. Bumping antd up in this PR might be a bit of a scope creep as we don't know what will break yet.
One vote from me for downgrading the types and revisiting it later in a separate task 🙆🏼

@kevinslin @hikchoi I decided to adress this in a seperate PR https://github.com/dendronhq/dendron/pull/3561.


[turbopack] Node process executed without process environment variables set

What version of Turbopack are you using?
turbopack-230213.2
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Describe the Bug
process.env has no shell variables when next.config.js is loaded inside next-dev.
I'm using turbopack from Next.js.
Expected Behavior
process.env should have variables given from the shell.
To Reproduce

Clone the repository.
pnpm i && pnpm dev:turbo
Open http://localhost:3000/client-side and you'll see the hydration error.
Set kNextConfigCheckIfEnvIsDefined to true in next.config.js and restart the server.
Open http://localhost:3000 and you'll see the server crash.

These errors do not occur in the normal next dev.
I made a workaround for this but I'm not sure if this is safe (as execute() is called in many places).
https://github.com/3c1u/turbo/tree/fix-process-env-turbopack-node
With this patch, those errors will disappear.
Reproduction Repo
https://github.com/3c1u/nextjs-env-injection

Hi @3c1u! We're aware of this, but haven't fixed it yet (tracking as WEB-517, but it's internal so you won't be able to read it). You're fix is nearly correct, but the actual fix requires a lot of plumbing of an ProcessEnvVc from https://github.com/vercel/turbo/blob/cda81f62564e0b57347d1f4010848be1add618f3/crates/next-core/src/page_source.rs#L225 down to the get_renderer_pool calls.

Thank you for the details! Looks like there are a lot of things to do 🤔
Is there any plan to fix this? I'm willing to help solving this issue!

Is there any plan to fix this? I'm willing to help solving this issue!

Yes, we definitely want to fix, but it just hadn't been prioritized yet. I'd love it if you fixed it!
We have 2 starting points:

https://github.com/vercel/turbo/blob/cda81f62564e0b57347d1f4010848be1add618f3/crates/next-core/src/page_source.rs#L225
https://github.com/vercel/turbo/blob/cda81f62564e0b57347d1f4010848be1add618f3/crates/next-core/src/app_source.rs#L308

We'll need that env_for_js returned ProcessEnvVc as variable. We'll need to pass that variable through function calls to the create_node_rendered_source in both of those files. From there, we can update create_node_rendered_source's returned NodeRenderContentSource to hold onto the ProcessEnvVc, and pass it to the render_static call. From there, pass it to get_renderer_pool. And finally, we can env.await?, and pass that to the NodeJsPool::new.

Hey @3c1u, didn't see you're willing to help out, fixed it myself because I needed it for another problem.
Hope you didn't start working on it so far :/

@ForsakenHarmony, thank you for fixing this issue! Luckily, I haven't worked on it yet.
@jridgewell, thanks for the explanation! (Sorry for the late response!)


Ports silently snap to 90-degree angles

Describe the bug
A gf.Port created with an orientation that is not a multiple of 90 will automatically set its orientation to the next lower multiple of 90. This does not raise an error or produce a warning message.
(Context: I'm trying to set up all-angle routing for my project's gdsfactory integration. It's not immediately clear whether we'll need this behavior, but we used it before switching to gdsfactory.)
To Reproduce
p=gf.Port(name="foo", orientation=359, center=(0, 0), width=5, layer=(1, 1))
print(p.orientation)
# 270.0

Expected behavior
Off-angle ports should either be fully supported or generate an error/warning when created.
Suggested fix
Based on recent kfactory changes, it seems like this could be supported with a "virtual port" concept? Otherwise raising an error for invalid port orientations would be very helpful for debugging.
Environment (please complete the following information):

[x] I have reviewed the documentation, discussions and issues and found no relevant solution.

This page warns against non-manhattan rotations and suggests that the feature exists, but doesn't actually indicate how to use it.

[x] I understand that this is an open-source project, and maintainers may not have the resources to address every issue. I am prepared to contribute by fixing the issue myself or hiring someone to do so, if needed, and accept that the issue may not be resolved otherwise.
[x] I am using the latest version of GDSFactory, with Python 3.10, 3.11, or 3.12.

Please provide the output for the following code:
Output
>>> import sys
>>> print(sys.version)
3.12.2 (main, Feb 10 2024, 20:26:15) [GCC 12.2.0]
>>> print(sys.executable)
/usr/local/google/home/martinop/.virtualenvs/pyle-gf8/bin/python
>>> import gdsfactory as gf_plugins()
>>> gf.config.print_version_plugins()
                 Modules
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━┓
┃    Package ┃ version     ┃        Path ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━┩
│     python │ 3.12.2      │ [REDACTED]  │
│            │ (main, Feb  │             │
│            │ 10 2024,    │             │
│            │ 20:26:15)   │             │
│            │ [GCC        │             │
│            │ 12.2.0]     │             │
│ gdsfactory │ 8.17.0      │ [REDACTED]  │
│   gplugins │ not         │             │
│            │ installed   │             │
│        ray │ not         │             │
│            │ installed   │             │
│    femwell │ not         │             │
│            │ installed   │             │
│     devsim │ not         │             │
│            │ installed   │             │
│     tidy3d │ not         │             │
│            │ installed   │             │
│       meep │ not         │             │
│            │ installed   │             │
│       meow │ not         │             │
│            │ installed   │             │
│     lumapi │ not         │             │
│            │ installed   │             │
│        sax │ not         │             │
│            │ installed   │             │
└────────────┴─────────────┴─────────────┘

Culprit is here:
https://github.com/gdsfactory/gdsfactory/blob/7b209cd9d36190aef02825e528d6302996522a94/gdsfactory/port.py#L158
This snaps it because it uses trans and not dcplx_trans. If it uses dcplx_trans, it also needs to use dwidth as a kwarg

Thank you for reporting this Orion,
See fix here
https://github.com/gdsfactory/gdsfactory/pull/3386


[bug] Removed node breaks network graph

Version
Build/Run method

[x] Docker
[ ] PKG
[ ] Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: v1.0.0-alpha.2
Describe the bug
A removed node (node id 5 was excluded) breaks the network graph. Seems to be similar to the closed issue #87.
Frontend console throws this exception:
vue.esm.js:1897 Error: missing: 5
    at D (vue-d3-network.umd.js:5313)
    at d (vue-d3-network.umd.js:5363)
    at Function.B.u.initialize (vue-d3-network.umd.js:5394)
    at f (vue-d3-network.umd.js:5727)
    at Object.force (vue-d3-network.umd.js:5769)
    at o.simulate (vue-d3-network.umd.js:7753)
    at o.animate (vue-d3-network.umd.js:7785)
    at o.reset (vue-d3-network.umd.js:7789)
    at o.netLinks (vue-d3-network.umd.js:7633)
    at pn.run (vue.esm.js:4577)

To Reproduce
Exclude a node from the network.
Expected behavior
Graph should still be working.
Additional context
Replicated in :latest and :dev tags.

A network heal and then restart of the Docker container brought back the network graph and made the exception go away.

A network heal and then restart of the Docker container brought back the network graph and made the exception go away.

@AlCalzone I have a feeling that this is caused by node neighbors not updated when a node is removed

@AlCalzone I have a feeling that this is caused by node neighbors not updated when a node is removed

Yeah basically we would have to tell all nodes to update their neighbors when a node is added or removed

Yeah basically we would have to tell all nodes to update their neighbors when a node is added or removed

I already have created an issue to track this

I already have created an issue to track this


PP-4976 Use controller errors on the edit merchant details page

The 'errors' object returned by the post controller now contains error messages as the values, where previously there was just a boolean to indicate there was an error.
Use these error messages in the template rather than the existing static text.
This modifies some of the error messages, but makes them more consistent with the design system.

It only lists the address once in the summary box. The summary box behaviour is unchanged from what it was previously. Although previously it wasn't highlighting the address line 2 input if the contents failed validation 😕


Followed Users functionality broken

The list of followed users is populated but expanding a user node does not do anything.
Expected: show the list of public gists for that particular user.
Quick investigation: element is a proper type for every case except this one, where is it an unresolved Promise:
267:     async getChildren(element?: ContentNode): Promise<any[]> {
268:
269:         this.refreshing = true;
270:         let sort = true;
271:
272:         if (element) {   // <== unresolved promise
273:             let childNodes: any[] = [];
274:
275:             if (element instanceof GistNode) {

src/Tree/nodes.ts:267~275

2f758085d44c851c48d0ca285700b021b7ec1cbd


Leftover TODO from New Core

TODO:

isStreamWindowed in Stream/Stream
condenseStreams in Program/Condense
tracking bubblegum in Core evaluator
Distinct could be simplified to store (Map key ()) of whether given key has been seen and update accumulator in-place
Core->Avalanche conversion ignores KeepFactInHistory/bubblegum and windows
Core->Avalanche does not allow fold initialisers to refer to previous fold initialisers but should
...
actually implement scan

I could help with something easy like (4)?

4 would be good, 2 is probably most important, and for scan I think we'll need something that "pulls out" the pre- and postcomputations. need to think about this still

I have done 2. the other things are relatively low priority for now, I think

I ended up doing 4 because it was the easiest way to thread the fact ids into latest for distincts

scan still isn't implemented, but the rest is. see #216.


Changelog of selected game not shown

The changelog tab is currently empty but should include the changelog for the selected game the user wants to download or start.
How to reproduce:

Start the launcher from most recent develop branch
Select an arbitrary release type and a game
See that the "Changelog" tab is empty

This is related to the changes done in #452, in particular commenting calls to updateGui().
However, just calling updateGui doesn't fix the changelog tab, it stays empty.

Related to #462


Update Package.swift

Increase minimum deployment targets to iOS 12.0, watchOS 5.0, macOS 10.14, tvOS 12.0 same as in Nuke 10.10.0

Forgot to update it. Thanks!


Lack of quotation marks for an ssh_password in the connectivity check

Hi,
The ssh_password variable is non-quoted in this line.
https://github.com/nuagenetworks/nuage-metroae/blob/df748b21c453d7cfdacd3193ccd19a6075dfbeeb/src/roles/common/tasks/wait-for-ssh-port.yml#L19
So the check fails in case of using special characters like &, ; etc. in a password.

JIRA ticket has been filed. Thank you for the heads up.


Add alternative format email for orgs

https://trello.com/c/OcuVomSb/820-determine-the-alternative-format-email-address-for-an-attachment
This adds a new field to store an email that specifies how a user can
request an alternative format from the organisation e.g. for an
attachment.

Nice one 👍


2.0.0-RC2 release

release plan
date : 2020-01-07

release note
https://github.com/naver/pinpoint/releases/tag/v2.0.0-RC2

I missed changing some setting in RC2.
If you want to run quickstart with RC2, change the value of quickstart.version setting in $PINPOINT_HOME/quickstart/conf/quickstart.properties to 2.0.0-RC2.


Status filter negation

I have implemented a few approaches to address #130:
A. Separate --not flag
Pros:

Flexible and adds only one new flag
Short flag support: guild runs list -Snc is equivalent to guild runs list --not --completed

Cons:

The flag is not positional, so commands like guild runs list --running --not work as well. Further, repeated --not flags are ignored and behave the same as a single flag. This might not be a huge issue, but it does mean that it's not immediately clear that --not applies only to status flags. For example, it could be confusing that a command like guild runs list --not --marked --running ends up showing runs that are marked and not running (rather than runs that are not marked and running)
The --not flag could be required to come before a status filter flag, but this is probably not worth the added complexity
Short negated flags with multiple filters (e.g. -Sncr) are very misleading – see note

B. Explicit boolean value options (e.g. --running=true)
Pros:

Doesn't add any new flags
Very clear which option is being negated
Negating a single short flag works (e.g. -Sc=false)

Cons:

Breaks old behavior (e.g. --running by itself no longer works)

C. Boolean flags (e.g. --running/--not-running)
Pros:

Very clear which option is being negated
Preserves old behavior

Cons:

Doubles the number of flags (though they are nicely paired in the generated help text)
No single-character option for negation

Overall, I think I prefer option C. There are plenty of other ways to achieve this or to combine elements from the different approaches, so I'm happy to discuss further.
The additional --skip-running flag for rm is probably not necessary, since all of the implementations support guild runs rm <flag(s) to negate running>. That said, it might still be a handy alias if used often enough.
Note:
Across all implementations, there is the potential for confusing behavior when multiple negated filters are specified; in these cases, all runs will be returned. This is because status filters use OR behavior (match any filter), and status != flag_a || status != flag_b is a tautology whenever flag_a and flag_b are distinct.
Potential fixes include:

Disable multiple negated status filters (for example, in implementation A, I added an error if the user tries to apply multiple status flags when --not is present)
Add a command-line warning when multiple negated filters are present
Ignore, but explicitly note this behavior in the documentation
Keep OR behavior for normal status filters, but use AND for negated status filters (probably extra confusing, though it would match the average use case)

As an aside, it might be neat to add new flags --match-all/--match-any for filtering operations in other contexts (this would address #439). Probably not overly useful or worth the complexity here, given that it would only be useful in the rare case of multiple negated status filters.

This is an excellent example of a good contribution! I appreciate the enumeration of different options, evaluating the pros and cons of each. I agree that Option C is one standing (the others have fatal flaws, which you've pointed out). I've merged the change and will confirm that it's doing what we want.
I'll update and add tests as needed. Guild's test scheme is a bit idiosyncratic, but I think in a good way! When you see the tests you should have a good idea of the approach Guild takes and can use that for future work, if you like!
Btw, Guild recently added support for a general purpose -F, --filter option, which takes a filter-spec. It supports formats like:
guild runs -F 'status != completed'
guild runs -F 'status not in [completed,terminated]'

That said, I still like having these --not-<status> options because they're intuitive and you don't need to recall a query syntax to use them.
Thanks again for the great work!

Thank you! I'm glad I could help out.

I'll update and add tests as needed. Guild's test scheme is a bit idiosyncratic, but I think in a good way! When you see the tests you should have a good idea of the approach Guild takes and can use that for future work, if you like!

I'm willing to try and write those tests too! Might be a good introduction to the format.

Btw, Guild recently added support for a general purpose -F, --filter option, which takes a filter-spec

Very useful!


SCB-879 Added the aspectjweaver.jar into the docker image with perf profile

Coverage remained the same at 93.687% when pulling 57c4ff1da30e4122ab0d3626e9d7e1f919673cce on SCB-879 into aa7cb9d59b297c5de934c09dd7d93fd751c0c187 on master.