Docker-Compose fails with old versions

Documenting here until I update the documentation to list the dependency on newer docker-compose. Compose < 1.26.0 (which ships natively on Ubuntu 20.04, the Docker snap, etc) has a bug related to processing env_files that contain values with quotes. For example:
WAIT_HOSTS="postgres:5432,redis:6379"

In reality becomes:
WAIT_HOSTS="\"postgres:5432,redis:6379\""

And blows stuff up. This appears in the bug fixes for 1.26.0 and is confirmed to be working in 1.28.6 (current Fedora 34 package).

This was documented in https://github.com/challfry/swiftarr/commit/1bd93e418847c4f50d1f28c51987fd61261ac780


Updates to support bugsnag/bugsnag ^3.4

Update composer dependency, interfaces and tests to be compatible w/v3.4 of BugSnag client.

Hi @pdbreen thanks for this :+1: It looks good. Do you mind doing a few small tweaks so CI passes? Then I'll merge and release this.

Sorry - never looped back around to check after travis finished.  All set now.  Also, note the discussion on this thread - https://github.com/bugsnag/bugsnag-laravel/issues/204.  In the end, I personally wound up creating a logging trait instead of the monolog handler, but it still may be useful for others.  Another possible enhancement would be setting log level for breadcrumb generation independent of log level for error reporting.


Added 2 OpenCV projects

Organized in Folder

Please merge @risingstar-bit

@risingstar-bit It is organised now.Please merge


Lc 55 be user api

edit profile and user profile page
u can edit the users info and their info will display
i didnt have the newest navbar so i wasnt sure to link it yet to avoid some conflicts

theres no time to fix this
the changes that someone else did to the login/signup page is goin to make the whole useEffect give that error


Rebase UNOList.insert_utxo against upstream

This fixes a bug where Electrum-NMC would crash on launch.

Will merge if Travis passes.

The Travis fail is Android-specific, and this PR only touches the Qt GUI, which isn't used in Android.  So I'm pretty confident that the fail is noise, not signal.  Merging.


Fix up 'serviceacccount' example

Changes
Update example to use .spec.taskSpec.steps
/kind documentation

Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[ ] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[ ] Commit messages follow commit message best practices
[ ] Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
(https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#backwards-compatible-changes-first).
Release Notes

NONE

thanks @sbose78 please include the suggested changes so that we can merge this 🙏

Sure, doing it asap!
On Fri, Jun 4, 2021, 14:17 Priti Desai @.***> wrote:

thanks @sbose78 https://github.com/sbose78 please include the suggested
changes so that we can merge this 🙏
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/tektoncd/pipeline/pull/3829#issuecomment-854916229,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEFEAGKQOCH5QSCSDYTQGTTREKDHANCNFSM4ZEUBG2A
.

pulled in this commit and updated it in https://github.com/tektoncd/pipeline/pull/4274
thanks @sbose78!


Update 'subset' from 'union' in Tests

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] All the files I changed are in the same world language (for example: only English changes, or only Chinese changes, etc.)
[x] My changes do not use shortened URLs or affiliate links.

Closes #XXXXX

Thank you @Manish-Giri  :smile:


Typo "**Note: "→"Note: "

https://docs.microsoft.com/en-us/windows/win32/win_cert/certification-requirements-for-windows-desktop-apps-v3-3

@hyoshioka0128 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Alternatively, you could insert an empty line (two newlines) between the </dl> and the note.


Add user_agent for link checker

This might fix the link-checker
Step 4: Check links
./make_help_scripts/check_links _build
make[1]: *** [Makefile:122: linkcheck] Error 1
(           index: line   49) broken    https://robotics.stackexchange.com/ - 403 Client Error: Forbidden for url: https://robotics.stackexchange.com/
Broken links found: 1

https://github.com/ros-controls/control.ros.org/actions/runs/8107023192/job/22157854574#step:8:2685
https://stackoverflow.com/questions/38489386/how-to-fix-403-forbidden-errors-when-calling-apis-using-python-requests
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-user_agent

This issue solved itself :man_shrugging:


Update operators.rakudoc

The problem
Example in code will cause an error in RakuAST, redeclaration of 'my $a'
Solution provided
remove second 'my'

@coke bringing this to your attention. The new highlighter @lizmat is developing will require error free examples.
The problem here is simple to fix and is unlikely to be the only one in the documentation suite
Each code section (between =begin code and =end code or in an indented section without blanks lines) will need to compile correctly in order to highlight

Notes:

Only partial code is provided in many cases. If the example is meant to compile, a preamble is preprended to the code that is NOT intended to be visible to the author. Until now this preamble has only been used for the
There are several examples where code is shown as a deliberate bad example where it is not intended to compile.
Unless there's a tag on the code block, we compile it during 'make xtest' and this snippet should fail as is if it doesn't compile. (items from #2 are excluded from this compilation)
This code compiles successfully and passes xt/examples_compilation.rakutest before your change. (So I think @lizmat is correct that this is a difference in rakuAST processing, not that the code is invalid.) (It emits "potential difficulties" but runs sucessfully)

@finanalyst If the highlighting results in an execution error, I suggest we skip highlighting for that particular piece of code, altogether for now. And that we collect these cases, as issues rakudo/rakudo marked RakuAST specific?

Could we add this to the error-report page?


Consider reverting split into individual module jars

Not only is the current setup harder to maintain for you, but it is also hard for users to integrate. Just give us one single jar. Nice and simple. The modules are ultra-small anyway so a few K of overhead in the main jar are well worth it when one factors in the simplicity gains.

Hi @axelfontaine,
Thanks for your feedback!
Actually, the reason for it wasn't the size. We did the repository split because of:

3rd party modules
commercial integrations
overall CI time

Does it cause some issues to you? Or maybe you just want to see something like testcontainers-all with all the dependencies? (or maybe something like groovy-all, fat jar-like)

Here is my pom.xml so far:
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>postgresql</artifactId>
    <version>${version.testcontainers}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>mysql</artifactId>
    <version>${version.testcontainers}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>mariadb</artifactId>
    <version>1.3.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>oracle-xe</artifactId>
    <version>1.2.1</version>
    <scope>test</scope>
</dependency>

What do we have here:

a long list of dependencies which will only get longer as more specialized types of containers are added
version numbers of individual modules that drift apart and in turn different versions of their transitive dependencies being resolved causing both high maintenance and potential conflicts

The fact that the version numbers started to drift is a clear indication that your current structure makes releasing too hard and ends up making life for end-users harder than it should be.
Alternatives:

Revert split and have a single jar from single project.
Use Maven modules instead of separate repos to make releasing easier, ensure consistent version numbers and compatibility between latest module and core versions. Optionally combine this with a Maven BOM.

Neither of these has an impact on the ability to create 3rd party or commercial modules. The same classes from core are still extendable and once can still create their own specialized containers. The only consequence would be potentially longer CI times which can most likely be largely alleviated with test parallelization.

@axelfontaine,
We're in the middle of the split process, this is why some deps are not aligned with core.
But I get your point.
We were also thinking to crowdsource CI environment because CI times are critical for us ATM and Travis doesn't allow more than 5 executors per project for OSS. Windows / Mac OS X is another topic when we talk about CI :)

Apache Camel is a good example of mega project, which is why all plugins are aligned.
Dropwizard is a bad example as lots extensions have drifted making upgrading dropwizard very hard.
I favor Axel suggestion

I think Spring project as a similar problem, with lots of different modules and repos and they've solved it in Spring-Boot with the Spring-Boot-Parents and BOMs I think?


praat: 6.3.07 -> 6.3.08

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/praat/praat/releases.
meta.description for praat is: Doing phonetics by computer
meta.homepage for praat is: https://www.fon.hum.uva.nl/praat/
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 6.3.08 with grep in /nix/store/99ks42y0g2q1ax31i6n1znq5ahjy88ni-praat-6.3.08
found 6.3.08 in filename of file in /nix/store/99ks42y0g2q1ax31i6n1znq5ahjy88ni-praat-6.3.08

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
praat

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/99ks42y0g2q1ax31i6n1znq5ahjy88ni-praat-6.3.08 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A praat https://github.com/r-ryantm/nixpkgs/archive/c578f3f84432df11a67f76b3011a6e6ead90f54c.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/99ks42y0g2q1ax31i6n1znq5ahjy88ni-praat-6.3.08
ls -la /nix/store/99ks42y0g2q1ax31i6n1znq5ahjy88ni-praat-6.3.08/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

praat

Maintainer pings
cc @orivej for testing.

Result of nixpkgs-review pr 216522 run on aarch64-linux 1

1 package built:

praat


Update description inside Footer

Summary
Briefly Summarize the purpose of this PR.
Description
Explain in detail what this PR is all about. This should include the problem you're solving, the approach taken, and any technical details that reviewers need to know.
Images
Include any relevant images or diagrams that can help reviewers visualize the changes, if applicable
Issue(s) Addressed
Enter the issue number of the bug(s) that this PR fixes

Template should be strictly Closes <issue_number>
Example: Closes #1

Prerequisites

[ ] Have you followed all the CONTRIBUTING GUIDELINES?

Thank you for submitting your pull request! 🙌 We'll review it as soon as possible. In the meantime, please ensure that your changes align with our CONTRIBUTING.md. If there are any specific instructions or feedback regarding your PR, we'll provide them here. Thanks again for your contribution! 😊


L-BFGS-B error message always reports 20 line search iterations

If the L-BFGS-B minimization method terminates abnormally due to the maximum number of line search iterations, it displays this message:
 Line search cannot locate an adequate point after 20 function
  and gradient evaluations.  Previous x, f and g restored.
 Possible causes: 1 error in function or gradient evaluation;
                  2 rounding error dominate computation.

I want to note that it says "after 20 function...evaluations" regardless of how many evaluations it did. 20 is the default value of maxls, but if you change it to something else, say 40, the message still says 20, which is confusing. Ideally, it would display "after 40 function...evaluations", but displaying "after maxls function...evaluations" would also be fine if string interpolation in Fortran is hard.
Here is the line that needs to be changed.

@drhagen Please specify Sample code to reproduce the problem.

Here's an example:
import numpy as np
from scipy.optimize import minimize

def func(x):
    return x + np.exp(-10*x)

result = minimize(func, x0=10, method='L-BFGS-B',
                  options={'maxls': 5, 'disp': 1})

Output:
RUNNING THE L-BFGS-B CODE

           * * *

Machine precision = 2.220D-16
 N =            1     M =           10
 This problem is unconstrained.

At X0         0 variables are exactly at the bounds

At iterate    0    f=  1.00000D+01    |proj g|=  1.00000D+00

           * * *

Tit   = total number of iterations
Tnf   = total number of function evaluations
Tnint = total number of segments explored during Cauchy searches
Skip  = number of BFGS updates skipped
Nact  = number of active bounds at final generalized Cauchy point
Projg = norm of the final projected gradient
F     = final function value

           * * *

   N    Tit     Tnf  Tnint  Skip  Nact     Projg        F
    1      1      6      1     0     0   1.000D+00   1.000D+01
  F =   10.000000000000000

ABNORMAL_TERMINATION_IN_LNSRCH

 Line search cannot locate an adequate point after 20 function
  and gradient evaluations.  Previous x, f and g restored.
 Possible causes: 1 error in function or gradient evaluation;
                  2 rounding error dominate computation.

 Cauchy                time 0.000E+00 seconds.
 Subspace minimization time 0.000E+00 seconds.
 Line search           time 0.000E+00 seconds.

 Total User time 0.000E+00 seconds.

Ideally, it would display "after 40 function...evaluations", but displaying "after maxls function...evaluations" would also be fine if string interpolation in Fortran is hard.

Even better would be for it to display both the name (maxls) and the value that it was set to by the user.

@maryhzd, the max number of line searches specified by maxls seems to work. However, when that limit is reached it will always say 'Line search cannot locate an adequate point after 20 function .... Basically the error message is wrong.
I have no idea how to do string interpolation in fortran. The quick fix would be to follow @drhagen suggestion.


Skip ErrorIcon and DefaultIcon while resizing the dictionary

Summary of the Pull Request
Resolves this exception which occurs after the dictionary is resized and app_error or app.png was removed.

Detailed Description of the Pull Request / Additional comments

While resizing we skip the key if it matches either ErrorIcon or DefaultIcon.

Validation Steps Performed
Manually validated that the exception isnt hit in a repro scenario.

This may be https://github.com/microsoft/PowerToys/issues/2820

This may be #2820

I don't think so, since the change is made on a code path introduced in #4433, so the error in #2820 wouldn't have been occurring due to this reason


The link for the config.txt is not working... could you just copy/paste the content here?

the link https://drive.google.com/open?id=0BzJAGHWBJ_5sZjFaZ25Cc3o3VHM doesn't work. Could someone just copy/paste the contents here?
There's another issue reporting this back in August where the guy says he went ahead with the original config.txt. But he doesn't specify if it worked or not.
anyhow, would be nice to have the contents of those config.txt files here so people can just create then!
I don't have it! :(

Just seen this, I'll help you out with this. File content:a=wiiu/apps/homebrew_launcher/homebrew_launcher.elf default=sysmenu


OrganoiDL class should exist and be able to add new shapes layers w/o model run

init OrganoiDL on init of widget

load model checkpoint later with new function

on shapes layer dropped add new entry in OrganoiDL  dict

see pull request #17


How long will it take? is the project likely to close?

I need the new cloudflarebypass very urgently, how much time is left?

I'm really in need too :)


[Flogo Web] - Can't rename activities

Current behavior (how does the issue manifest):
Renaming activities don't save at the moment on Flogo Web v0.5.5-hf1
Expected behavior:
Ability to rename activities like in previous versions.
Minimal steps to reproduce the problem (not required if feature enhancement):
Create an activity. Rename. Create another activity, go back to the old activity, the rename didnt save.
Please tell us about your environment (Operating system, docker version, browser & web ui version, etc):
Chrome, MacOS, Flogo web v0.5.5-hf1
Flogo version (CLI & contrib/lib. If unknown, leave empty or state unknown): 0.X.X
Additional information you deem important (e.g. issue happens only occasionally):

Hi @crmadrig, with the latest version of the Flogo Web UI (0.5.6) this is fixed 😄 You can rename activities from the updated "configure" screen (just go to the configure screen and click on the name of the activity. A text box will appear where you can alter the name). Please do let us know if that fixes your issue!


add .bazelversion & .bazelignore

Fixes #IssueNumber
Changes proposed:

[x] Add
[ ] Delete
[ ] Fix
[ ] Prepare

I'm wondering if it wouldn't be better to create specific variants of the icon for that. Maybe a different color would suffice.


404 when using fullPath in Aliases and CORS

We are using moleculer-web 0.9.1 for an API service. We use a lot of custom APIs with fullPath and autoalias. We have noticed that the API-GW cors code doesn't match the route when the path doesn't start with the routes path.  In this case the cors preflight doesn't work, it returns a 404.
To show you the issue, we have managed to reproduce it in the API-GW by using the aliases:
		routes: [
			{
				path: "/api",

				aliases: {
					"welcome": {
						method: "POST",
						fullPath: "/welcome",
						action: "greeters.welcome"
					}
				},
			}
		],

[2021-08-30T16:57:58.361Z] INFO  spectrex360-34464/API: Register route to '/api'
[2021-08-30T16:57:58.362Z] INFO  spectrex360-34464/API:     POST /welcome => greeters.welcome
[2021-08-30T16:58:12.621Z] DEBUG spectrex360-34464/API: undefined
[2021-08-30T16:58:12.622Z] INFO  spectrex360-34464/API: <= 404 OPTIONS /welcome [+1.032 ms]

if the fullPath starts with the route path, the cors is correctly set:

			aliases: {
				"welcome": {
					method: "POST",
					fullPath: "/api/welcome",
					action: "greeters.welcome"
				}
			},

[2021-08-30T16:56:46.501Z] INFO  spectrex360-34464/API: Register route to '/api'
[2021-08-30T16:56:46.505Z] INFO  spectrex360-34464/API:     POST /api/welcome => greeters.welcome
[2021-08-30T16:57:21.114Z] INFO  spectrex360-34464/API: => OPTIONS /welcome
[2021-08-30T16:57:21.115Z] INFO  spectrex360-34464/API: <= 204 OPTIONS /api/welcome [+1.492 ms]

Confirmed on version 0.10.0

How can I reproduce?

The problem is that, there is no registered handler for the path with OPTIONS method.
Here is a workaround:

It can solve it, but I don't know it doesn't cause other issues...e.g It can find a GET alias and not the POST

Fixed.


Parallel Routes

Describe the problem
We have a quite a large app with about ~400 svelte components and ~300 routes.
Some of the pages have a lot of logic and try to handle "one too many things". For example our analytics page has five fetch requests in one +page.ts (think about showing five different graph visualizations with separate data sets for each one of them). When we change a resolution of one graph the whole logic in +page.ts logic falls short (due to the nature if you calling invalidate it invalidates all 5 fetch requests). Due to that we only use +page.ts load function to receive initial data and escape the "SvelteKit way" where you separate data fetching from UI and actually write custom logic to handle loading more data.
Describe the proposed solution
I find elegant what NextJS does with parallel routes and it solves the problem for us and hopefully does for others as well. I also understand that lot of people don't hit this problem unless they have a rather larger app and handle lot of edge cases. Question would come how the design in SvelteKit would look like and I would take an inspiration from NextJS again.
export default function Layout(props: {
  children: React.ReactNode
  analytics: React.ReactNode
  team: React.ReactNode
}) {
  return (
    <>
      {props.children}
      {props.team}
      {props.analytics}
    </>
  )
}

V1 +layout.svelte
<script>
  export let data;
</script>

<slot />
<slot name="team" />
<slot name="analytics" />

V2 +layout.svelte
<script>
  export let data;
  export let analytics;
  export let team;
</script>

<slot />
<svelte:component this={team} />
<svelte:component this={analytics} />

V1 feels like a great ergonomics but I'm not sure how would the parser be able to handle that since I don't know the internals of SvelteKit and how that plays.
Appreciate your time reading this.
Alternatives considered
No response
Importance
would make my life easier
Additional Information
No response

I think parallel routes would be the wrong solution to this problem. What you want is more fine-grained control over which things rerun, for which #6294 or a way to define multiple load functions would be better suited. Closing this as duplicate of #10848


Missing eu12 region

Issue description
Hi,
I was looking for ip addresses for region eu12 (for API Endpoint: https://api.cf.eu12.hana.ondemand.com/) and it is not on this page at all. The last update to the page seems to be january of last year - would it be possible to update this page to include this region?
Thanks!
Feedback Type (Optional)
None
Page Title on SAP Help Portal (prefilled)
Regions and API Endpoints Available for the Cloud Foundry Environment
Page URL on SAP Help Portal (prefilled)
https://help.sap.com/docs/btp/sap-business-technology-platform/regions-and-api-endpoints-available-for-cloud-foundry-environment?q=Regions and API Endpoints Available for the neo

There's been no activity on this issue for a while, so we're closing it. If you've further information to provide, please comment below and add that information. We'll review it and reopen the conversation if necessary. Until next time, thanks!


Cursor plugin: option to flip time element by default

Since #1776, the time element is flipped to the left of the cursor when close to the right edge of the waveform element. I'd like to have the option to reverse this behavior (always keep the time element to the left of the cursor unless close to the left edge of the waveform element). I've been using this patch for now which works fine for me, but a togglable option would be useful:
diff --git a/node_modules/wavesurfer.js/dist/plugin/wavesurfer.cursor.js b/node_modules/wavesurfer.js/dist/plugin/wavesurfer.cursor.js
index 2c9af8f..609d5a0 100644
--- a/node_modules/wavesurfer.js/dist/plugin/wavesurfer.cursor.js
+++ b/node_modules/wavesurfer.js/dist/plugin/wavesurfer.cursor.js
@@ -229,7 +229,7 @@ var CursorPlugin = /*#__PURE__*/function () {
       var y = 0;
       var x = e.clientX - bbox.left;

-      var flip = bbox.right < e.clientX + _this.outerWidth(_this.displayTime);
+      var flip = bbox.left < e.clientX - _this.outerWidth(_this.displayTime);

       if (_this.params.showTime && _this.params.followCursorY) {
         // follow y-position of the mouse

sounds good, please open a pull request for that new option.


Question: Is there a way to use predefined default value for the certain filter?

i think Filter Default Values on Nova docs might help you. you could define your default filter values as:
/**
 * The default value of the filter.
 *
 * @var string
 */
public function default()
{
    return true;
}

While a default does update the filter for the main panel- it does not change the metric card.  Defaults are ignored.

While a default does update the filter for the main panel- it does not change the metric card.  Defaults are ignored.

This issue will be fixed in next release.


refactor: simplify wehbook configuration controller handlers

Description

Fix #XXX

Test

To test this pull request, you can run the following commands:

Additional Information
Tradeoff

Potential improvement

Thanks an interesting approach. Are there consequences caused by using a field indexer?

I don't think so. However I'd like to proceed with the name, namespace approach  for simplicty.


making fault

Hello, I hope you are doing well. I want to create several faults, including blade and mooring faults, by modifying the source code of OpenFAST version 3.3.0. I would like to know if there is any resource or structure available for this task? If possible, please guide me.
Also, I have read these conversation, but I need some guidance on how to start from scratch.

Dear @dorsamgh,
I don't think I can provide much guidance on blade and mooring faults beyond on blade and mooring faults what is already discussed in the forum post you cross-referenced.  Do you have a specific question as to what is discussed in that forum post?
If you question is how to change the source code and recompile OpenFAST, I refer you to the OpenFAST documentation: https://openfast.readthedocs.io/en/main/source/install/index.html#compile-from-source.
Best regards,

Dear @jjonkman,
Thank you for your response. Actually, I want to create some faults on  IEA-15-240-RWT-UMaineSemi using OpenFAST. I know how to compile the .exe file from the source code and have been able to compile a normal .exe file. Now, my question might seem simple, To simulate a specific fault such as a seized blade, should I modify the files related to the OpenFAST source code or the modules related to the 15 MW wind turbine such as servodyn ?
thanks again.

Dear @dorsamgh,
For a fault related to blade seizure (the blade pitch actuator not responding to the pitch controller), you can use the override pitch maneuver settings available directly through the ServoDyn input file, with no source code change or recompile required.  This topic has also been discussed on our forum, e.g., see: https://forums.nrel.gov/t/how-to-create-a-actuator-and-sensor-fault-in-open-fast/5577.
Best regards,

Dear @jjonkman,
Hello. Thank you for your response and I apologize for the late reply to this message. Based on the parameters of the ServoDyn module, I created a fault related to blade seizure. Additionally, using the same method, I created a fault related to yaw angle change by altering NacYawF at the desired time. Now, my question is how can I create this fault in an intermittent manner? Is it possible to do this by changing the module parameters, or do I need to modify the source code?

Dear @dorsamgh,
If by "intermittent" you mean the fault coming and going, that is not possible through the simple override maneuvers available in ServoDyn.  You would need to modify the source code for such a condition.
Best regards,

Dear @jjonkman
thank you for your response, to modify the source code of ServoDyn, should i continue along to the "openfast-3.3.0\modules\servodyn\src\ServoDyn.f90" path and apply my changes in the .dat file and then compile the FAST ("openfast-3.3.0\vs-build\FAST\FAST.sln")?

Yes, that sounds correct.

Thank you. I have two more questions. To modifying the source code of ServoDyn, should the yaw angle be defined in radians or degrees? And finally, after obtaining the exe file, should I set the YCMode value to 3? The function I defined in the source code is as follows:

Dear @dorsamgh,
The internal unit for yaw angle within OpenFAST is radians.
It doesn't look like you've edited the placeholder SUBROUTINEUserYawCont(), but you should select YCMode = 3 if you place your user-defined yaw-control logic in this routine.
Best regards,

Dear @jjonkman
I created a subroutine called CustomUserYawCont(), and as shown in the images, I called it in the (ControlMode_USER) state. Should I name the function UserYawCont() and define this subroutine?

Dear @dorsamgh,
By setting TYawManS to 0, the yaw maneuver will override the yaw controller already at the beginning of the simulation.  If you want to use your UserYawCont() logic throughout the simulation, set TYawManS > TMax.
Best regards,

Dear @jjonkman
thank you, that was exactly the problem. and now by adjusting this parameter, i have achieved the desired result. thank you for your response and guidance.


created new theme postman

Description
Created a new theme POSTMAN
Type of change
changes are done in the themes.ts and THEMES.md

You can also check out the theme preview at the https://github.com/rahulkumarpahwa
Please mark it as hacktoberfest-accepted.

Hello,
Thanks for adding the theme.
How should I mark it as hacktoberfest-accepted?

yes, please.


Document how to install nginx ingress controller

Please describe what should be documented
Link to steps to install nginx ingress controller
Please suggest where in the repo the document should be located
https://github.com/openservicemesh/osm/blob/main/docs/content/docs/tasks_usage/ingress.md

Additional documentation
Troubleshooting Guide:

[ ] Check Ingress resource for correctness and annotations (point to Nginx ingress controller docs for this)
[ ] Does the Ingress resource reference an existing Service?
[ ] Does the Service referenced by the Ingress resource have Pods backing it - list the Endpoints
[ ] Check Envoy configuration of one/all of the Endpoints referenced in the Ingress - to these Envoys have an HTTP ingress inbound opened?

The ingress documentation has a sample demo that uses Kubernetes Nginx Ingress https://docs.openservicemesh.io/docs/tasks_usage/traffic_management/ingress/#sample-demo.
It has a link to the Nginx installation guide which the user can follow based on their environment and preferences for installing:


Implement dry-run test in the CI

          A bit OT, but I did not know where to write this. One way to catch automatically this kind of regression in the future may be:

Modify yarprobotinterface --dryrun option to also check (or have a separate option for that) if the mentioned device exist, even without opening them (so we can run this check in CI without any robot).
Add the yarprobotinterface --dryrun CI check for each directory of this repo

Note that we can already do the second step, even if it would not have helped in this specific case.
Originally posted by @traversaro in https://github.com/robotology/robots-configuration/issues/462#issuecomment-1486732271

I've started off with the development in https://github.com/robotology/robots-configuration/tree/466-implement-dry-run-test-in-the-ci.
In the CI, for the moment, I'm sticking to manually checking out the development branches. I'll have to manage the correct versioning among the dependencies (e.g., yarp, icub-main...) and robots-configuration smartly later on.
Only the ETH robots can be verified via a dry-run. We need to come back to this later as well.
To enable the dry run on a ETH robot, it suffices to follow these instructions[^1]:

https://github.com/robotology/robots-configuration/pull/321#issuecomment-1024217618

This is an example of the dry-run executed on iCubGenova11 via
>> yarprobotinterface > log.txt 2>&1

whose output is log.txt.
The return code is:
>> echo $?
134

Therefore, it may be better to parse the content of the log, in search of keywords like "unknown plugin" and the like.
Finally, the idea is to create a suite of cmake tests to automatize this check for all the ETH robots installed.
[^1]: Setting skipCalibration to true is not required, actually.

The return code is:
>> echo $?
134

Therefore, it may be better to parse the content of the log, in search of keywords like "unknown plugin" and the like.

Note that at the moment the dryrun do not check the existing of the plugin mentioned in the xml, at least this is what I understood, but I may be wrong. However, it seems that the yarprobotinterface is crashing:
[ERROR] yarprobotinterface intercepted a segmentation fault caused by a faulty plugin:
[ERROR] /workspace/install/bin/../lib/libYARP_os.so.3(_ZN4yarp2os6BottleD2Ev+0x67) [0x7f416934a397]
Trace requested at /workspace/yarp/src/yarprobotinterface/Module.cpp:77 by code called from:
/workspace/install/bin/../lib/libYARP_os.so.3(_Z16yarp_print_traceP8_IO_FILEPKcj+0x3b) [0x7f416935733b]
yarprobotinterface(+0x9c84) [0x5625654d0c84]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f4168e8b520]
/workspace/install/bin/../lib/libYARP_os.so.3(_ZN4yarp2os6BottleD2Ev+0x67) [0x7f416934a397]
/workspace/install/bin/../lib/libYARP_os.so.3(+0xc2c4a) [0x7f416938ac4a]
/workspace/install/bin/../lib/libYARP_os.so.3(+0xc2c10) [0x7f416938ac10]
/workspace/install/bin/../lib/libYARP_os.so.3(_ZN4yarp2os8PropertyD2Ev+0x75) [0x7f416938ad05]
/workspace/install/bin/../lib/libYARP_dev.so.3(+0xa98e6) [0x7f4168de98e6]
/workspace/install/bin/../lib/libYARP_dev.so.3(_ZN4yarp3dev10PolyDriver5closeEv+0x4c) [0x7f4168de74fc]
/workspace/install/bin/../lib/libYARP_robotinterface.so.3(_ZN4yarp14robotinterface6Device5closeEv+0x48) [0x7f41694cb898]
/workspace/install/bin/../lib/libYARP_robotinterface.so.3(_ZN4yarp14robotinterface5Robot7Private12closeDevicesEv+0x2fa) [0x7f41694d9f4a]
/workspace/install/bin/../lib/libYARP_robotinterface.so.3(_ZN4yarp14robotinterface5Robot10enterPhaseENS0_11ActionPhaseE+0x29a4) [0x7f41694e2c24]
yarprobotinterface(+0xbcbd) [0x5625654d2cbd]
/workspace/install/bin/../lib/libYARP_os.so.3(_ZN4yarp2os8RFModule9runModuleERNS0_14ResourceFinderE+0xf7) [0x7f41693b47c7]
yarprobotinterface(+0x8dbf) [0x5625654cfdbf]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f4168e72d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f4168e72e40]
yarprobotinterface(+0x8e85) [0x5625654cfe85]

So probably if the yarprobotinterface did not crash the output would be 0?

Therefore, it may be better to parse the content of the log, in search of keywords like "unknown plugin" and the like.

I was more referring to any kind of generic error currently handled by the yarprobotinterface. A better example is plugin found but could not open.
For the failure you're right, although yarprobotinterface seg-faults upon closure are not rare in my experience. I'll have a look at it.

The failure upon closure is due to cartesian/right_arm-cartesian.xml, whereas cartesian/left_arm-cartesian.xml is just fine.
However, even when yarprobotinterface shuts down gracefully, its return code is 1.

Things to do:

Create the ctest infrastructure.
Parse the output of yarprobotinterface.
Manage CAN vs. ETH robots.
Manager in the CI the correct versions of the deps wrt robots-configuration.

Today, I've reached a status where I can handle CAN vs. ETH robots via the ctest infrastructure.
The output of the dry-run is not parsed yet.
In the meantime, I've realized that iCubErzelli03 just hangs up: need for investigating.

I've realized that iCubErzelli03 just hangs up: investigation is needed here.

Actually, iCubErzelli03 was running just fine. The calibration was taking up some time, hence I had to disable it, eventually[^1]. Thus, yarprobotinterface was running happily and I had to modify the test to manage the graceful shutdown.
After all, it turned out that for many ETH robots the dry-run doesn't execute flawlessly as it happens for iCubErzelli03 or iCubHamburg01[^2], for instance.
[^1]: Therefore, I stopped relying on sed and switched to xmlstarlet for editing XML files.
[^2]: These robots do have the head only.

Manage in the CI the correct versions of the deps wrt robots-configuration.

To keep things simple, I went for:

Sticking to icub-main@devel and configure ycm, yarp, icub-firmware-shared versions accordingly.
Running the Dry-Run once per week.

Let's see how it goes this way to then refine the dry-run further, if required.
I need to merge the PR to make the new CI available for testing purposes.
Last thing to address is the parsing of yarprobotinterface output.

I stumbled upon the following error during a dry-run:
[DEBUG] |yarp.dev.PolyDriver|head-inertial| Parameters are (comport "/dev/ttyUSB0") (device imuBosch_BNO055) (id head-inertial) (robotName icub)
[ERROR] |yarp.device.imuBosch_BNO055| Can't open /dev/ttyUSB0, No such file or directory
[ERROR] |yarp.dev.PolyDriver|head-inertial| Driver <imuBosch_BNO055> was found but could not open

I'm using a gitpod-based sandbox to simulate the CI environment.
Does anyone have experience with running the Bosch in dry-run?
cc @davidetome @traversaro @Nicogene @marcoaccame

Just aligned F2F w/ @davidetome.
The dry-run is meaningful only for the embObj devices. Thus, I'll disable the inertial.

The dry-run is meaningful only for the embObj devices. Thus, I'll disable the inertial.

Do you have any idea why? I tought the dry-run was not actually running the devices, so I am a bit surprised that a device is actually being run, but probably I actually misunderstood what dry-run is doing.

Aligned F2F with @traversaro too.
There are 2 dry-run:

yarprobotinterface --dryrun.
the dry-run of the embObj devices, which is the one I've been focusing so far.

Once fixed the inertial (see #476), I managed to narrow down the failures:
Test project /workspace/build
      Start  1: dry-run_R1SN000
 1/77 Test  #1: dry-run_R1SN000 ..................***Failed    0.07 sec
      Start  2: dry-run_R1SN001
 2/77 Test  #2: dry-run_R1SN001 ..................***Failed    4.24 sec
      Start  3: dry-run_R1SN002
 3/77 Test  #3: dry-run_R1SN002 ..................***Failed    0.16 sec
      Start  4: dry-run_R1SN003
 4/77 Test  #4: dry-run_R1SN003 ..................***Failed    4.23 sec
      Start  5: dry-run_SkinFingertipDemo
 5/77 Test  #5: dry-run_SkinFingertipDemo ........   Passed    0.02 sec
      Start  6: dry-run_SkinTableTop
 6/77 Test  #6: dry-run_SkinTableTop .............   Passed    0.02 sec
      Start  7: dry-run_ergoCubSN000
 7/77 Test  #7: dry-run_ergoCubSN000 .............***Failed    3.20 sec
      Start  8: dry-run_iCubAberystwyth01
 8/77 Test  #8: dry-run_iCubAberystwyth01 ........   Passed    0.02 sec
      Start  9: dry-run_iCubAbuDhabi01
 9/77 Test  #9: dry-run_iCubAbuDhabi01 ...........   Passed    0.01 sec
      Start 10: dry-run_iCubAnkara01
10/77 Test #10: dry-run_iCubAnkara01 .............   Passed    0.02 sec
      Start 11: dry-run_iCubBarcelona01
11/77 Test #11: dry-run_iCubBarcelona01 ..........   Passed    0.02 sec
      Start 12: dry-run_iCubBielefeld01
12/77 Test #12: dry-run_iCubBielefeld01 ..........   Passed    0.21 sec
      Start 13: dry-run_iCubBielefeld02
13/77 Test #13: dry-run_iCubBielefeld02 ..........   Passed    0.21 sec
      Start 14: dry-run_iCubBielefeld03
14/77 Test #14: dry-run_iCubBielefeld03 ..........   Passed    0.21 sec
      Start 15: dry-run_iCubChemnitz01
15/77 Test #15: dry-run_iCubChemnitz01 ...........***Failed    4.23 sec
      Start 16: dry-run_iCubDarmstadt01
16/77 Test #16: dry-run_iCubDarmstadt01 ..........***Failed   11.32 sec
      Start 17: dry-run_iCubDijon01
17/77 Test #17: dry-run_iCubDijon01 ..............   Passed    0.02 sec
      Start 18: dry-run_iCubEdinburgh01
18/77 Test #18: dry-run_iCubEdinburgh01 ..........   Passed   11.35 sec
      Start 19: dry-run_iCubErzelli01
19/77 Test #19: dry-run_iCubErzelli01 ............   Passed   11.35 sec
      Start 20: dry-run_iCubErzelli02
20/77 Test #20: dry-run_iCubErzelli02 ............   Passed   11.38 sec
      Start 21: dry-run_iCubErzelli03
21/77 Test #21: dry-run_iCubErzelli03 ............   Passed    1.22 sec
      Start 22: dry-run_iCubFrankfurt01
22/77 Test #22: dry-run_iCubFrankfurt01 ..........   Passed    0.31 sec
      Start 23: dry-run_iCubGenova01
23/77 Test #23: dry-run_iCubGenova01 .............   Passed    0.03 sec
      Start 24: dry-run_iCubGenova02
24/77 Test #24: dry-run_iCubGenova02 .............   Passed   11.43 sec
      Start 25: dry-run_iCubGenova03
25/77 Test #25: dry-run_iCubGenova03 .............   Passed    0.03 sec
      Start 26: dry-run_iCubGenova04
26/77 Test #26: dry-run_iCubGenova04 .............***Failed   11.42 sec
      Start 27: dry-run_iCubGenova06
27/77 Test #27: dry-run_iCubGenova06 .............   Passed    0.03 sec
      Start 28: dry-run_iCubGenova07
28/77 Test #28: dry-run_iCubGenova07 .............   Passed   11.47 sec
      Start 29: dry-run_iCubGenova08
29/77 Test #29: dry-run_iCubGenova08 .............   Passed    5.40 sec
      Start 30: dry-run_iCubGenova09
30/77 Test #30: dry-run_iCubGenova09 .............***Failed    5.34 sec
      Start 31: dry-run_iCubGenova10
31/77 Test #31: dry-run_iCubGenova10 .............***Failed   12.43 sec
      Start 32: dry-run_iCubGenova11
32/77 Test #32: dry-run_iCubGenova11 .............***Failed    7.34 sec
      Start 33: dry-run_iCubGrenoble01
33/77 Test #33: dry-run_iCubGrenoble01 ...........   Passed    0.03 sec
      Start 34: dry-run_iCubHamburg01
34/77 Test #34: dry-run_iCubHamburg01 ............   Passed    1.13 sec
      Start 35: dry-run_iCubHeidelberg01
35/77 Test #35: dry-run_iCubHeidelberg01 .........***Failed    6.30 sec
      Start 36: dry-run_iCubHertfordshire01
36/77 Test #36: dry-run_iCubHertfordshire01 ......   Passed    0.03 sec
      Start 37: dry-run_iCubHertfordshire02
37/77 Test #37: dry-run_iCubHertfordshire02 ......   Passed    0.02 sec
      Start 38: dry-run_iCubHongKong01
38/77 Test #38: dry-run_iCubHongKong01 ...........   Passed   11.41 sec
      Start 39: dry-run_iCubKarlsruhe01
39/77 Test #39: dry-run_iCubKarlsruhe01 ..........   Passed    0.27 sec
      Start 40: dry-run_iCubLausanne01
40/77 Test #40: dry-run_iCubLausanne01 ...........   Passed    0.02 sec
      Start 41: dry-run_iCubLausanne02
41/77 Test #41: dry-run_iCubLausanne02 ...........   Passed   11.38 sec
      Start 42: dry-run_iCubLethbridge01
42/77 Test #42: dry-run_iCubLethbridge01 .........   Passed    0.03 sec
      Start 43: dry-run_iCubLisboa01
43/77 Test #43: dry-run_iCubLisboa01 .............***Failed    7.30 sec
      Start 44: dry-run_iCubLisboa02
44/77 Test #44: dry-run_iCubLisboa02 .............   Passed    0.25 sec
      Start 45: dry-run_iCubLondon01
45/77 Test #45: dry-run_iCubLondon01 .............   Passed    0.03 sec
      Start 46: dry-run_iCubLugano01
46/77 Test #46: dry-run_iCubLugano01 .............   Passed    0.03 sec
      Start 47: dry-run_iCubManchester01
47/77 Test #47: dry-run_iCubManchester01 .........   Passed    0.03 sec
      Start 48: dry-run_iCubMoscow01
48/77 Test #48: dry-run_iCubMoscow01 .............***Failed   12.41 sec
      Start 49: dry-run_iCubMunich01
49/77 Test #49: dry-run_iCubMunich01 .............   Passed    0.03 sec
      Start 50: dry-run_iCubNancy01
50/77 Test #50: dry-run_iCubNancy01 ..............***Failed   11.39 sec
      Start 51: dry-run_iCubNottingham01
51/77 Test #51: dry-run_iCubNottingham01 .........***Failed   11.39 sec
      Start 52: dry-run_iCubOffenbach01
52/77 Test #52: dry-run_iCubOffenbach01 ..........   Passed    0.24 sec
      Start 53: dry-run_iCubOffenbach02
53/77 Test #53: dry-run_iCubOffenbach02 ..........   Passed    0.23 sec
      Start 54: dry-run_iCubParis01
54/77 Test #54: dry-run_iCubParis01 ..............   Passed    0.03 sec
      Start 55: dry-run_iCubParis02
55/77 Test #55: dry-run_iCubParis02 ..............   Passed    0.02 sec
      Start 56: dry-run_iCubPisa01
56/77 Test #56: dry-run_iCubPisa01 ...............   Passed    0.02 sec
      Start 57: dry-run_iCubPlymouth01
57/77 Test #57: dry-run_iCubPlymouth01 ...........   Passed    0.02 sec
      Start 58: dry-run_iCubPlymouth02
58/77 Test #58: dry-run_iCubPlymouth02 ...........   Passed    0.03 sec
      Start 59: dry-run_iCubPrague01
59/77 Test #59: dry-run_iCubPrague01 .............***Failed   12.44 sec
      Start 60: dry-run_iCubPrototype01
60/77 Test #60: dry-run_iCubPrototype01 ..........   Passed    0.24 sec
      Start 61: dry-run_iCubRome02
61/77 Test #61: dry-run_iCubRome02 ...............   Passed    0.03 sec
      Start 62: dry-run_iCubSeoul01
62/77 Test #62: dry-run_iCubSeoul01 ..............   Passed    0.03 sec
      Start 63: dry-run_iCubShanghai01
63/77 Test #63: dry-run_iCubShanghai01 ...........***Failed   12.39 sec
      Start 64: dry-run_iCubSheffield01
64/77 Test #64: dry-run_iCubSheffield01 ..........***Failed    6.33 sec
      Start 65: dry-run_iCubShenzhen01
65/77 Test #65: dry-run_iCubShenzhen01 ...........***Failed   12.49 sec
      Start 66: dry-run_iCubSingapore01
66/77 Test #66: dry-run_iCubSingapore01 ..........   Passed   11.28 sec
      Start 67: dry-run_iCubTokyo01
67/77 Test #67: dry-run_iCubTokyo01 ..............   Passed    0.02 sec
      Start 68: dry-run_iCubTwente01
68/77 Test #68: dry-run_iCubTwente01 .............***Failed   11.35 sec
      Start 69: dry-run_iCubUrbana01
69/77 Test #69: dry-run_iCubUrbana01 .............   Passed    0.24 sec
      Start 70: dry-run_iCubValparaiso01
70/77 Test #70: dry-run_iCubValparaiso01 .........***Failed   12.40 sec
      Start 71: dry-run_iCubWaterloo01
71/77 Test #71: dry-run_iCubWaterloo01 ...........***Failed   12.29 sec
      Start 72: dry-run_iCubZagreb01
72/77 Test #72: dry-run_iCubZagreb01 .............***Failed   12.43 sec
      Start 73: dry-run_iCubZurich01
73/77 Test #73: dry-run_iCubZurich01 .............   Passed    0.24 sec
      Start 74: dry-run_iRonCub-Mk1
74/77 Test #74: dry-run_iRonCub-Mk1 ..............***Failed    8.31 sec
      Start 75: dry-run_iiwaBoston01
75/77 Test #75: dry-run_iiwaBoston01 .............   Passed    0.02 sec
      Start 76: dry-run_naoPrague01
76/77 Test #76: dry-run_naoPrague01 ..............   Passed    0.02 sec
      Start 77: dry-run_vizzy
77/77 Test #77: dry-run_vizzy ....................   Passed    0.03 sec

68% tests passed, 25 tests failed out of 77

Total Test time (real) = 315.42 sec

The following tests FAILED:
          1 - dry-run_R1SN000 (Failed)
          2 - dry-run_R1SN001 (Failed)
          3 - dry-run_R1SN002 (Failed)
          4 - dry-run_R1SN003 (Failed)
          7 - dry-run_ergoCubSN000 (Failed)
         15 - dry-run_iCubChemnitz01 (Failed)
         16 - dry-run_iCubDarmstadt01 (Failed)
         26 - dry-run_iCubGenova04 (Failed)
         30 - dry-run_iCubGenova09 (Failed)
         31 - dry-run_iCubGenova10 (Failed)
         32 - dry-run_iCubGenova11 (Failed)
         35 - dry-run_iCubHeidelberg01 (Failed)
         43 - dry-run_iCubLisboa01 (Failed)
         48 - dry-run_iCubMoscow01 (Failed)
         50 - dry-run_iCubNancy01 (Failed)
         51 - dry-run_iCubNottingham01 (Failed)
         59 - dry-run_iCubPrague01 (Failed)
         63 - dry-run_iCubShanghai01 (Failed)
         64 - dry-run_iCubSheffield01 (Failed)
         65 - dry-run_iCubShenzhen01 (Failed)
         68 - dry-run_iCubTwente01 (Failed)
         70 - dry-run_iCubValparaiso01 (Failed)
         71 - dry-run_iCubWaterloo01 (Failed)
         72 - dry-run_iCubZagreb01 (Failed)
         74 - dry-run_iRonCub-Mk1 (Failed)

Still need to look at those remaining failures and the implementation of yarprobotinterface --dryrun.

With the latest changes, I managed to further narrow down the failures to:
The following tests FAILED:
          1 - dry-run_R1SN000 (Failed)
          2 - dry-run_R1SN001 (Failed)
          3 - dry-run_R1SN002 (Failed)
          4 - dry-run_R1SN003 (Failed)
         26 - dry-run_iCubGenova04 (Failed)
         30 - dry-run_iCubGenova09 (Failed)
         35 - dry-run_iCubHeidelberg01 (Failed)
         43 - dry-run_iCubLisboa01 (Failed)
         48 - dry-run_iCubMoscow01 (Failed)
         63 - dry-run_iCubShanghai01 (Failed)
         74 - dry-run_iRonCub-Mk1 (Failed)

In detail, I had to:

disable ros and ros2 devices.
disable wholebodydynamic device.
tweak some XML files missing the xmlns:xi="http://www.w3.org/2001/XInclude" attribute.

There are references to batteryWrapper in some robot XML files, which I suppose has been deprecated (and removed in yarp-3.8.0) in favor of battery_nws_yarp. Thereby, we need to patch some robot files.

R1SN000 removed as it is no longer maintained, and no one uses it (it still relies on controlboardwrapper2). This robot will be still accessible through the git history.
Latest status:
The following tests FAILED:
         25 - dry-run_iCubGenova04 (Failed)
         29 - dry-run_iCubGenova09 (Failed)
         34 - dry-run_iCubHeidelberg01 (Failed)
         42 - dry-run_iCubLisboa01 (Failed)
         47 - dry-run_iCubMoscow01 (Failed)
         62 - dry-run_iCubShanghai01 (Failed)
         73 - dry-run_iRonCub-Mk1 (Failed)

I've added also the option for the native yarprobointerface --dryrun, discovering several errors due to missing files.
Concerning the check related to the devices, there are still errors due to the use of batteryWrapper (see #477), some missing remapper/wrapper and finally some errors related to iRonCub-Mk1 because of the deprecated controlboardwrapper2.
We will need to address the whole bunch of these errors relying on the CI in the upcoming days.

As agreed with @traversaro, iRonCub-Mk1 has been removed via https://github.com/robotology/robots-configuration/commit/b7c437a3a07dc2de1b77d0645ce6b2f3c795e895.

I finally managed to make the CI run flawlessly.
Of course, we do still have errors to fix in the XML files: we'll do that incrementally starting the next sprint.
The state of play:
The following tests FAILED:
	  3 - dry-run_R1SN002_xml (Failed)
	 13 - dry-run_iCubAberystwyth01_xml (Failed)
	 15 - dry-run_iCubAbuDhabi01_xml (Failed)
	 17 - dry-run_iCubAnkara01_xml (Failed)
	 21 - dry-run_iCubBielefeld01_xml (Failed)
	 23 - dry-run_iCubBielefeld02_xml (Failed)
	 25 - dry-run_iCubBielefeld03_xml (Failed)
	 41 - dry-run_iCubFrankfurt01_xml (Failed)
	 49 - dry-run_iCubGenova04_xml (Failed)
	 50 - dry-run_iCubGenova04_dev (Failed)
	 58 - dry-run_iCubGenova09_dev (Failed)
	 63 - dry-run_iCubGrenoble01_xml (Failed)
	 67 - dry-run_iCubHeidelberg01_xml (Failed)
	 68 - dry-run_iCubHeidelberg01_dev (Failed)
	 69 - dry-run_iCubHertfordshire01_xml (Failed)
	 71 - dry-run_iCubHertfordshire02_xml (Failed)
	 75 - dry-run_iCubKarlsruhe01_xml (Failed)
	 77 - dry-run_iCubLausanne01_xml (Failed)
	 81 - dry-run_iCubLethbridge01_xml (Failed)
	 83 - dry-run_iCubLisboa01_xml (Failed)
	 84 - dry-run_iCubLisboa01_dev (Failed)
	 85 - dry-run_iCubLisboa02_xml (Failed)
	 94 - dry-run_iCubMoscow01_dev (Failed)
	 95 - dry-run_iCubMunich01_xml (Failed)
	101 - dry-run_iCubOffenbach01_xml (Failed)
	103 - dry-run_iCubOffenbach02_xml (Failed)
	105 - dry-run_iCubParis01_xml (Failed)
	107 - dry-run_iCubParis02_xml (Failed)
	109 - dry-run_iCubPisa01_xml (Failed)
	111 - dry-run_iCubPlymouth01_xml (Failed)
	113 - dry-run_iCubPlymouth02_xml (Failed)
	117 - dry-run_iCubPrototype01_xml (Failed)
	119 - dry-run_iCubRome02_xml (Failed)
	124 - dry-run_iCubShanghai01_dev (Failed)
	131 - dry-run_iCubTokyo01_xml (Failed)
	135 - dry-run_iCubUrbana01_xml (Failed)
	143 - dry-run_iCubZurich01_xml (Failed)
	149 - dry-run_vizzy_xml (Failed)

The dry-run logs are available as an artificial to download from the workspace.
In the upcoming days, I'll see how to improve the CI in order to:

attach it to PR's;
use the YARP_NO_DEPRECATED cmake flag;
address the building of some yarp-device-* repos;


Rank channel not work

Good evening,
When you choose a channel, it does not go to the channel in question, but to the channel where the message was sent.

Still not sending messages

Did you setup your database correctly?

yes, I installed it correctly the information is uploaded to the db but the bot does not send now I remember it doesn't send logs either

Does the bot has correct perms

have admin perms

Ok when i get home ill help you

When I approved this, it worked great

Can you send your code of that file in a https://sourceb.in

https://sourceb.in/KRk9KC4T8D here

Why is there this massive and statement

relooking at it, it's correct, it works for me on multiple bots


SVM should_panic tests are now failing

See build #249 on Travis.

Turns out this one was not actually not all that hard to fix, just foreign object damage from 9951c75a56b7d5ced37148a6ce09e9dc6dd9ce77. I am not altogether that smart.


Transaction strategy configured with symbol(connection name) does not work

(I will post my suggestion next to this report.)
Summary
When we add another database to a cleaner by specifying a symbol (connection name) with the :transaction strategy, it does not open a transaction.
Look at the reproduction below. Even though the cleaner is configured to clean :db => :bar with the transaction strategy, the transaction is not opened*.
(*In fact, a transaction is opened on ActiveRecord::Base.connection instead.)
Reproduction
#!/usr/bin/env ruby

require "bundler/inline"

gemfile(true) do
  source 'https://rubygems.org'
  gem 'rails', '~> 7.0.0'
  gem 'sqlite3'
  gem 'rspec'
  gem 'database_cleaner-active_record', git: "https://github.com/DatabaseCleaner/database_cleaner-active_record.git", ref: "aafa5b2"
end

require "yaml"

ActiveRecord::Base.configurations = YAML.load(<<~YAML)
  foo:
    adapter: sqlite3
    database: ":memory:"
  bar:
    adapter: sqlite3
    database: ":memory:"
YAML

RSpec.describe do
  before do
    ActiveRecord::Base.establish_connection :foo

    class Bar < ActiveRecord::Base
      establish_connection :bar
    end
  end

  it "should open a transaction on Bar" do
    cleaner = DatabaseCleaner::Cleaners.new
    cleaner[:active_record, :db => :bar].strategy = :transaction
    cleaner.cleaning do
      # expected: true
      #      got: false
      expect(Bar.connection.transaction_open?).to eq(true)
    end
  end

  it "should not open a transaction on ActiveRecord::Base where we removed it from cleaner" do
    cleaner = DatabaseCleaner::Cleaners.new
    cleaner[:active_record].strategy = nil
    cleaner[:active_record, :db => :bar].strategy = :transaction
    cleaner.cleaning do
      # expected: false
      #      got: true
      expect(ActiveRecord::Base.connection.transaction_open?).to eq(false)
    end
  end
end

Suggested Solution
In the reproduction above, try replacing all the :db => :bar with :db => Bar. The test passes.
Looking into the database_cleaner/active_record/base.rb, it is managing to obtain the ActiveRecord class from a given connection name.
It makes the code have too much responsibility and very complex. That is, it is reading ActiveRecord::Base.configurations, reading config/database.yml, and searching through connection pools and ActiveRecord classes.
This complexity can easily bring bugs such as #10, #18 and #97.
Though it is a breaking change... if we make the cleaner only accept an ActiveRecord class object as a value for :db option, doesn't database_cleaner/active_record/base.rb become far simpler and reduce the possibility of bugs so much?


[F-25]: update meteor desktop

https://yt.sharekey.com/agiles/110-34/current?issue=F-25
What was done:

merged branch with electron-update from (https://github.com/Meteor-Community-Packages/meteor-desktop/pull/8)
fix issue with single instance: syntax was changed in the newer version of electron.

@marozartsem9 would you be willing to push your fixes upstream?

@marozartsem9 would you be willing to push your fixes upstream?

@StorytellerCZ , Hi!
https://github.com/Meteor-Community-Packages/meteor-desktop/pull/10


Font

check it out in the adaptation full grid

There is the new plasma mutation card in there.
Can you just remove it and generate the grid again?
Other than that looks good.

Accidentally opened new branch from the mutation branch instead of master. Hope this works now?

Now there is no plasma mutation left, so the cards cant be generated.


fix broken hyperlink for LUD-16

https://blog.getalby.com/create-your-neutral-300ning-address/ is now 404 as witnessed in https://archive.ph/Z3q8A.
This PR updates the definition of lud16Url
FROM: https://blog.getalby.com/create-your-neutral-300ning-address/
TO: https://github.com/lnurl/luds/blob/luds/16.md.

Thanks for the heads-up, fixed.


THRIFT-5580: refactor kotlin cross test to use proper cli framework, add more transport/protocol cases

[x] Did you create an Apache Jira ticket?  (not required for trivial changes)
[x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
[ ] Did you squash your changes to a single commit?  (not required, but preferred)
[x] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

Is this part of an existing JIRA issue?

i've just created one here: https://issues.apache.org/jira/browse/THRIFT-5580

@Jimexist Are the cross tests running during the CI checks? If so, can you point me to it? There's been a lot of changes lately (you've been very productive!) and I just want to make sure I didn't overlook it. Ideally, I'd be able to rely on the GH Actions CI checks to verify that the tests are passing (I don't know what Travis and Appveyor are doing, but they are horrendeously slow to run, sitting in the queue for hours).

@Jimexist Are the cross tests running during the CI checks? If so, can you point me to it? There's been a lot of changes lately (you've been very productive!) and I just want to make sure I didn't overlook it. Ideally, I'd be able to rely on the GH Actions CI checks to verify that the tests are passing (I don't know what Travis and Appveyor are doing, but they are horrendeously slow to run, sitting in the queue for hours).

They are run during Travis take this link for example you can search in log for kotlin and other language pairs: https://app.travis-ci.com/github/apache/thrift/jobs/569447392
I plan to migrate cross tests to GitHub action but I need to add a few more languages first. For now they only cover unit tests.

@Jimexist Are the cross tests running during the CI checks? If so, can you point me to it? There's been a lot of changes lately (you've been very productive!) and I just want to make sure I didn't overlook it. Ideally, I'd be able to rely on the GH Actions CI checks to verify that the tests are passing (I don't know what Travis and Appveyor are doing, but they are horrendeously slow to run, sitting in the queue for hours).

They are run during Travis take this link for example you can search in log for kotlin and other language pairs: https://app.travis-ci.com/github/apache/thrift/jobs/569447392
I plan to migrate cross tests to GitHub action but I need to add a few more languages first. For now they only cover unit tests.

One dependency is https://github.com/apache/thrift/pull/2596

CTest (concurrency_test) is flaky in Appveyor CI (timed out), but that's unrelated to these changes.


Refine the logic of getUnqualifiedRole() in ResourceGroupMgr

Enhancement

Currently, when getting roles for current user to match existed resource groups, we get all roles granted to the user except the built-in ones, and use the first one to match resource group, this logic can be refined in the following ways:

get the default roles not all the granted roles
any default role matching the existed resource group should be a candidate

fixed by #18207


mccortex clean's help output

Running mccortex clean without any option prints help output, which says If neither -T or -U specified, just saves output statistics. However, the default behaviour seems to be to automatically apply -T and -U options with computed values.

Thanks @yeban I've corrected the help text. Thank you for all your feedback, apologies for the delay in getting to it.


Contract Verification in Hedera

Hello, I have a question. I don't know if this is the right place.
Is there any contract verification in Hedera?
I have managed to deploy a contract using the FileAppendTransaction() function.
But in the block explorer I see something that is unintelligible for me...
https://testnet.dragonglass.me/transactions/00460501151656320700698270653
Thank you!

Hi!
What do you mean by contract verification?
Do you want to verify the bytecode and the source code of the deployed contract?
Or verify that your contract was deployed to the network?

Linking https://github.com/hashgraph/hedera-mirror-node-explorer/issues/71 and closing for now. If you have any questions, please feel free to open the issue again.


When running 'exit;' through a script in console this returns status code 1 (error)

OrientDB Version: 3.0.0
Java Version: /
OS: OrientDB Docker
Expected behavior
When running ./console.sh test.txt with the test.txt having contents: exit; (how you would exit after a script) this should return a clean exit code aka '0'.
Actual behavior
The actual return code is 1
Steps to reproduce
See expected behaviour. For me this was the following command:
docker run --rm -t -v /orientdb/databases:/orientdb/databases -v /orientdb/backup:/orientdb/bin/backup orient3temp /orientdb/bin/console.sh /orientdb/bin/backup/backup.txt with backup.txt containing exit;
running echo $? afterwards shows me exit code 1.

Hi @33Fraise33,
I think this is an issue of the exit operation in batch mode (batch mode is when you run a script), you can work around it removing the exit command, in batch mode the console will exit as soon as all the script are executed.
Regarads

Hello,
Thanks for the reply. This solved my issue indeed.


Having issue with themes

@Manny878 Some details about the issue you are having will help us figure out what's happening.

So sorry I thought I deleted my post. I really didn't have an issue just and update prob. Sorry new to GitHub.

@Manny878 no problem! :)


Affordance to define per-initiative questions on upload

Admins need to be able to define multiple-choice style questions that users need to answer when uploading a file to an initiative. @AlexAxthelm to confirm this is only for initiative-specific uploads.

In some cases they can be identical between initiatives (e.g., the 2022 and 2024 instance of the same project) but I don't expect there to be a baseline or widely shared set of questions.
They only get set once when an initiative gets set up (and maybe fixed for typos or so afterwards).
Given how rarely they get set (a few initiatives per year, some will have questions), this could absolutely be with developer intervention.

SGTM


vector-<IP_ADDRESS>

vector-<IP_ADDRESS> is out of bounds for:

[ ] Chart-1.8.1 (>=0.9 && < 0.12). No maintainer. @timbod7. Used by: library
[x] JuicyPixels-3.2.8 (>=0.10 && < 0.12). Vincent Berthoux<EMAIL_ADDRESS>@Twinside. @Twinside. Used by: library
[ ] ListLike-4.5 (>=0.5 && < 0.12). No maintainer. @JohnLato. Used by: library, test-suite
[x] aeson-compat-0.3.6 (>=0.10 && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @phadej. Used by: library, test-suite
[x] aeson-extra-<IP_ADDRESS> (>=0.10 && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @phadej. Used by: library, test-suite
[x] avers-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Tomas Carnecky @wereHamster. @wereHamster. Used by: library, test-suite
[x] avers-api-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Tomas Carnecky @wereHamster. @wereHamster. Used by: library
[x] binary-orphans-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @phadej. Used by: library, test-suite
[ ] binary-tagged-<IP_ADDRESS> (>=0.10 && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @phadej. Used by: library, test-suite, benchmark
[ ] bloodhound-<IP_ADDRESS> (>=0.10.9 && < 0.12). Chris Allen<EMAIL_ADDRESS>bitemyapp. @bitemyapp. Used by: library, test-suite
[ ] cassava-<IP_ADDRESS> (< 0.12). Michael Snoyman<EMAIL_ADDRESS>@snoyberg. @hvr. Used by: library, test-suite, benchmark
[x] cassava-megaparsec-0.1.0 (==0.11.*). Stack Builders<EMAIL_ADDRESS>@stackbuilders. @jsantos17 @jsl @mrkkrp @sestrella. Used by: library, test-suite
[x] cayley-client-0.3.1 (>=<IP_ADDRESS> && < 0.12). Michel Boucey<EMAIL_ADDRESS>@MichelBoucey. @MichelBoucey. Used by: library
[x] compactmap-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Simon Marechal<EMAIL_ADDRESS>@bartavelle.. Used by: library
[ ] darcs-2.12.4 (>=<IP_ADDRESS> && < 0.12). Simon Michael<EMAIL_ADDRESS>@simonmichael.. Used by: library
[x] dawg-ord-<IP_ADDRESS> (>=0.10 && < 0.12). Jakub Waszczuk<EMAIL_ADDRESS>@kawu. @kawu. Used by: library
[ ] diagrams-cairo-1.4 (>=0.10.0 && < 0.12). Brent Yorgey<EMAIL_ADDRESS>@byorgey. @bergey @byorgey @fryguybob @jeffreyrosenbluth. Used by: library
[x] fay-<IP_ADDRESS> (< 0.12). Adam Bergmark<EMAIL_ADDRESS>@bergmark. @bergmark. Used by: library
[x] flac-0.1.1 (>=0.10 && < 0.12). Mark Karpov<EMAIL_ADDRESS>@mrkkrp. @mrkkrp. Used by: library, test-suite
[x] foldl-1.2.2 (>=0.7 && < 0.12). Gabriel Gonzalez<EMAIL_ADDRESS>@Gabriel439. @Gabriel439. Used by: library
[x] foldl-statistics-<IP_ADDRESS> (==0.11.*). Alex Mason<EMAIL_ADDRESS>@Axman6. @Data61. Used by: test-suite, benchmark
[x] generic-aeson-<IP_ADDRESS> (>=0.10 && < 0.12). Silk<EMAIL_ADDRESS>@bergmark @hesselink. Used by: library
[x] gipeda-<IP_ADDRESS> (>=0.10 && < 0.12). Joachim Breitner<EMAIL_ADDRESS>@nomeata. @nomeata. Used by: executable
[x] github-0.15.0 (>=<IP_ADDRESS> && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @phadej. Used by: library, test-suite
[ ] hakyll-<IP_ADDRESS> (==0.11.*). Jasper Van der Jeugt @jaspervdj. @jaspervdj. Used by: library, test-suite
[ ] hashtables-<IP_ADDRESS> (>=0.7 && < 0.12). Gregory Collins<EMAIL_ADDRESS>@gregorycollins. @gregorycollins. Used by: library
[ ] hasql-<IP_ADDRESS> (>=0.10 && < 0.12). Nikita Volkov<EMAIL_ADDRESS>@nikita-volkov. @nikita-volkov. Used by: library, benchmark
[ ] haxl-<IP_ADDRESS> (>=0.10 && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @facebook. Used by: library
[ ] heist-<IP_ADDRESS> (>=0.9 && < 0.12). No maintainer. @mightybyte. Used by: library, test-suite, benchmark
[x] hjsonpointer-<IP_ADDRESS> (>=0.10 && < 0.12). Ian Grant Jeffries<EMAIL_ADDRESS>@seagreen. @seagreen. Used by: library, test-suite
[x] hjsonschema-<IP_ADDRESS> (>=0.10 && < 0.12). Ian Grant Jeffries<EMAIL_ADDRESS>@seagreen. @seagreen. Used by: library, test-suite
[x] hquantlib-<IP_ADDRESS> (>=<IP_ADDRESS> && < <IP_ADDRESS>). Pavel Ryzhov<EMAIL_ADDRESS>@paulrzcz. @paulrzcz. Used by: library
[x] hybrid-vectors-0.2.1 (>=0.10 && < 0.12). Michael Snoyman<EMAIL_ADDRESS>@snoyberg. @ekmett. Used by: library
[x] inline-r-<IP_ADDRESS> (>=0.10 && < 0.12). Mateusz Kowalczyk<EMAIL_ADDRESS>@Fuuzetsu. @tweag. Used by: library, test-suite, benchmark
[ ] io-streams-<IP_ADDRESS> (>=0.7 && < 0.12). Gregory Collins<EMAIL_ADDRESS>@gregorycollins. @mightybyte. Used by: library, test-suite
[x] json-schema-<IP_ADDRESS> (>=0.10 && < 0.12). Silk<EMAIL_ADDRESS>@bergmark @hesselink. Used by: library, test-suite
[x] lens-aeson-<IP_ADDRESS> (>=0.9 && < 0.12). Edward Kmett<EMAIL_ADDRESS>@ekmett. @lens. Used by: library
[x] libsystemd-journal-1.4.1 (>=0.4 && < 0.12). Oliver Charles<EMAIL_ADDRESS>@ocharles. @ocharles. Used by: library
[x] linear-1.20.5 (>=0.10 && < 0.12). Edward Kmett<EMAIL_ADDRESS>@ekmett. @ekmett. Used by: library
[x] log-domain-<IP_ADDRESS> (>=0.9 && < 0.12). Edward Kmett<EMAIL_ADDRESS>@ekmett. @ekmett. Used by: library
[ ] luminance-<IP_ADDRESS> (==0.11.*). Dimitri Sabadie<EMAIL_ADDRESS>@phaazon. @phaazon. Used by: library
[x] microlens-aeson-<IP_ADDRESS> (>=0.9 && < 0.12). Colin Woodbury<EMAIL_ADDRESS>@fosskers. @fosskers. Used by: library, test-suite
[x] microlens-platform-<IP_ADDRESS> (>=0.9 && < 0.12). Artyom<EMAIL_ADDRESS>@neongreen. @aelve. Used by: library
[x] monoid-subclasses-0.4.3 (>=0.9 && < 0.12). Mario Blazevic<EMAIL_ADDRESS>@blamario. @blamario. Used by: library, test-suite
[x] network-carbon-1.0.7 (>=0.10 && < 0.12). Oliver Charles<EMAIL_ADDRESS>@ocharles. @ocharles. Used by: library
[ ] pandoc-1.19.1 (>=0.10 && < 0.12). John MacFarlane<EMAIL_ADDRESS>@jgm. @jgm. Used by: library
[x] picedit-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Mahdi Dibaiee<EMAIL_ADDRESS>@mdibaiee. Used by: library
[x] pinboard-<IP_ADDRESS> (>=0.10.9 && < 0.12). Jon Schoning<EMAIL_ADDRESS>@jonschoning. @jonschoning. Used by: library
[ ] pinch-<IP_ADDRESS> (>=0.10 && < 0.12). Abhinav Gupta<EMAIL_ADDRESS>@abhinav. @abhinav. Used by: library, test-suite
[x] pipes-random-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
[ ] postgresql-binary-<IP_ADDRESS> (>=0.10 && < 0.12). Nikita Volkov<EMAIL_ADDRESS>@nikita-volkov. @nikita-volkov. Used by: library
[ ] profiteur-<IP_ADDRESS> (>=0.10 && < 0.12). Jasper Van der Jeugt @jaspervdj. @jaspervdj. Used by: executable
[x] quickcheck-instances-0.3.12 (>=0.9 && < 0.12). No maintainer. @aslatter. Used by: library
[x] rattletrap-2.1.3 (==0.11.*). Taylor Fausak<EMAIL_ADDRESS>@tfausak. @tfausak. Used by: library
[ ] rebase-1.0.6 (>=0.10 && < 0.12). No maintainer. @nikita-volkov. Used by: library
[ ] reedsolomon-<IP_ADDRESS> (>=0.10 && < 0.12). Nicolas Trangez<EMAIL_ADDRESS>@NicolasT. @NicolasT. Used by: library, test-suite, benchmark
[ ] repa-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
[ ] repa-algorithms-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
[ ] repa-io-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
[x] rest-gen-<IP_ADDRESS> (>=0.10 && < 0.12). Silk<EMAIL_ADDRESS>@bergmark @hesselink. Used by: library
[ ] rethinkdb-<IP_ADDRESS> (>=0.10 && < 0.12). Brandon Martin<EMAIL_ADDRESS>@codedmart. @atnnn. Used by: library
[ ] riak-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Tim McGilchrist<EMAIL_ADDRESS>@tmcgilchrist. @markhibberd. Used by: library
[ ] safecopy-0.9.2 (>=0.10 && < 0.12). No maintainer. @acid-state. Used by: library, test-suite
[ ] sampling-0.3.1 (==0.11.*). Jared Tobin<EMAIL_ADDRESS>@jtobin. @jtobin. Used by: library
[ ] sdl2-2.1.3 (>=<IP_ADDRESS> && < 0.12). Gabríel Arthúr Pétursson<EMAIL_ADDRESS>@polarina. @ocharles. Used by: library
[x] sibe-<IP_ADDRESS> (==<IP_ADDRESS>). Mahdi Dibaiee<EMAIL_ADDRESS>@mdibaiee. Used by: library, executable
[ ] smoothie-<IP_ADDRESS> (>=0.10 && < 0.12). Dimitri Sabadie<EMAIL_ADDRESS>@phaazon. @phaazon. Used by: library
[ ] snap-core-<IP_ADDRESS> (>=0.6 && < 0.12). No maintainer. @mightybyte. Used by: library, test-suite
[ ] snap-server-<IP_ADDRESS> (>=0.7 && < 0.12). No maintainer. @mightybyte. Used by: library, executable, test-suite, benchmark
[x] stache-0.2.0 (==0.11.*). Stack Builders<EMAIL_ADDRESS>@stackbuilders. @jsantos17 @jsl @mrkkrp @sestrella. Used by: library
[ ] stb-image-redux-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Alexis Williams<EMAIL_ADDRESS>@sasinestro. @sasinestro. Used by: library, test-suite
[x] these-0.7.3 (>=0.4 && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @isomorphism. Used by: library, test-suite
[x] tttool-<IP_ADDRESS> (>=0.10 && < 0.12). Joachim Breitner<EMAIL_ADDRESS>@nomeata. @entropia. Used by: executable
[ ] tz-<IP_ADDRESS> (>=0.9 && < 0.12). Mihaly Barasz<EMAIL_ADDRESS>@klao. @nilcons. Used by: library
[ ] tzdata-0.1.20160614.0 (>=0.9 && < 0.12). Mihaly Barasz<EMAIL_ADDRESS>@klao. @nilcons. Used by: library
[x] vector-algorithms-<IP_ADDRESS> (>=0.6 && < 0.12). No maintainer.. Used by: library, executable, test-suite
[x] vector-binary-instances-<IP_ADDRESS> (>=0.6 && < 0.12). No maintainer. @bos. Used by: library, test-suite, benchmark
[ ] vector-fftw-<IP_ADDRESS> (>=0.9 && < 0.12). Ben Gamari<EMAIL_ADDRESS>@bgamari. @bgamari. Used by: library
[x] vector-instances-3.3.1 (>=0.9 && < 0.12). Edward Kmett<EMAIL_ADDRESS>@ekmett. @ekmett. Used by: library
[ ] vector-sized-<IP_ADDRESS> (==0.11.*). Justin Le<EMAIL_ADDRESS>@mstksg. @expipiplus1. Used by: library
[ ] vector-split-<IP_ADDRESS> (>=0.10 && < 0.12). Florian Hofmann<EMAIL_ADDRESS>@fhaust. @fhaust. Used by: library, test-suite
[ ] vectortiles-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers. @fosskers. Used by: library, test-suite
[ ] wavefront-<IP_ADDRESS> (==0.11.*). Dimitri Sabadie<EMAIL_ADDRESS>@phaazon. @phaazon. Used by: library
[ ] wordpass-<IP_ADDRESS> (>=0.10 && < 0.12). Michal J. Gajda<EMAIL_ADDRESS>@mgajda. @mgajda. Used by: library, executable
[x] yesod-core-1.4.30 (>=0.9 && < 0.12). No maintainer. @snoyberg. Used by: library

Due to the large number of packages initially affected, there is no need to post update comments at this stage.

foldl-1.2.3 is fixed

Due to the large number of packages initially affected, there is no need to post update comments at this stage.

Since Stackage doesn't seem to record this info: the maintainer of vector-algorithms is @dolio. And since vector-algorithms doesn't use git: I have a patch which revises the upper version bounds on vector here.

(Having said that, personally as maintianer I find the update comments really useful, but of course many people will get notified via github.)

@juhp No, at least I can't. AFAIK only collaborators can edit/update comments.
Now that I have a comment: sibe-<IP_ADDRESS> is fixed. Waiting on JuicyPixels to fix picedit.

@juhp Correct. Not sure if it's possible to allow others to update the description of the issue without making them members of the project sadly.
I believe I've made the necessary changes in foldl-statistics-<IP_ADDRESS>, and given Gabriel's update to foldl, I think these should both be fixed now. (Thanks @Gabriel439 for the quick fix)

@mdibaiee I've updated JuicyPixels' bounds on hackage (no need to make a new release), it compiles with Vector 0.12

cayley-client fixed.

Since we comment anyway: cassava-megaparsec, flac and stache fixed.

Thank you for all the Hackage updates: I have refreshed the initial comment.

hquantlib fixed but it requires packages scientific and integer-logarithms to bump their versions too.

@paulrzcz AFAIK neither scientific or integer-logarithms depend on vector? Maybe you are missinterpretting something (they depend thru criterion, which depends on cassava).
Generally, I hope that people actually test that their package is compiled against vector-0.12, e.g. there is no way to compile cassava-megaparsec against vector-0.12 without using --allow-never. Hopefully @mrkkrp did so. (cassava in fact seems to compile fine with vector-0.12).

@phadej After raising the vector version to <IP_ADDRESS> in extra-deps of stack.yaml and rebuilding the project with stack against Stackage LTS 7.15, I've got:
Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for scientific-<IP_ADDRESS>:
    vector-<IP_ADDRESS> must match >=0.7 && <0.12 (latest applicable is <IP_ADDRESS>)
needed due to hquantlib-<IP_ADDRESS> -> scientific-<IP_ADDRESS>

In the dependencies for vector-binary-instances-<IP_ADDRESS>:
    vector-<IP_ADDRESS> must match >=0.6 && <0.12 (latest applicable is <IP_ADDRESS>)
needed due to hquantlib-<IP_ADDRESS> -> vector-binary-instances-<IP_ADDRESS>

Plan construction failed.

Bumping of scientific to version <IP_ADDRESS> came up with integer-logarithm:
In the dependencies for scientific-<IP_ADDRESS>:
    integer-logarithms must match >=1 && <1.1, but the stack configuration has no specified version
                       (latest applicable is 1)
needed due to hquantlib-<IP_ADDRESS> -> scientific-<IP_ADDRESS>

The next step is to add interger-logarithms-1. So now hquantlib is buildable and has got extra-deps:
extra-deps:
 - vector-<IP_ADDRESS>
 - vector-binary-instances-<IP_ADDRESS>
 - scientific-<IP_ADDRESS>
 - integer-logarithms-1

Studying the full dependency graph shows that scientific come from aeson-<IP_ADDRESS> package and takes integer-logarithms with it. vector-binary-instances are direct dep of statistics.
Though, it builds without additional version bumps against Stackage nightly-2017-01-10 that already includes those versions of packages, except vector-<IP_ADDRESS>.

@paulrzcz few things: use solver, e.g. stack solver, or cabal
hquantlib-<IP_ADDRESS> master % git diff
diff --git a/hquantlib.cabal b/hquantlib.cabal
index a9deb2d..3885d56 100644
--- a/hquantlib.cabal
+++ b/hquantlib.cabal
@@ -72,7 +72,7 @@ library
                         parallel        >= <IP_ADDRESS>      && < <IP_ADDRESS>,
                         mersenne-random >= <IP_ADDRESS>      && < <IP_ADDRESS>,
                         statistics      >= <IP_ADDRESS>     && < <IP_ADDRESS>,
-                        vector          >= <IP_ADDRESS>     && < <IP_ADDRESS>,
+                        vector          >= <IP_ADDRESS>     && < <IP_ADDRESS>,
                         vector-algorithms >= <IP_ADDRESS>    && < <IP_ADDRESS>

         hs-source-dirs: src
[FL973] ~/mess/hquantlib-<IP_ADDRESS> master % cabal new-build --only-dependencies --dry-run --constraint vector==<IP_ADDRESS> --enable-tests|tail
 - storable-complex-0.2.2 (lib:storable-complex) (requires download & build)
 - vector-algorithms-<IP_ADDRESS> (lib) (requires build)
 - vector-th-unbox-<IP_ADDRESS> (lib) (requires build)
 - monad-par-extras-0.3.3 (lib) (requires build)
 - hmatrix-<IP_ADDRESS> (lib) (requires download & build)
 - math-functions-<IP_ADDRESS> (lib) (requires download & build)
 - monad-par-<IP_ADDRESS> (lib) (requires build)
 - hmatrix-gsl-<IP_ADDRESS> (lib) +onlygsl (requires download & build)
 - statistics-<IP_ADDRESS> (lib) (requires build)
 - hmatrix-special-<IP_ADDRESS> (lib:hmatrix-special) (requires download & build)

It's not visible in the output, but for vector-0.12 one need to pick scientific-<IP_ADDRESS> and vector-binary-instances-<IP_ADDRESS>, and maybe some other ripples.

Another thing, I noticed in hquantlib:
mersenne-random >= <IP_ADDRESS>      && < <IP_ADDRESS>

But 2.0 < <IP_ADDRESS> holds. It's unfortunate legacy quirk (and hopefully cabal check will say about it, cc @hvr)

vectortiles updated.

smoothie updated.

New entry:

folds-0.7.1 (>=0.10 && < 0.12). Oleg Grenrus<EMAIL_ADDRESS>@phadej. @ekmett. Used by: library

folds bound relaxed

These mentions were originally truncated: @NicolasT @codedmart @tmcgilchrist @acid-state @jtobin @polarina @isomorphism @klao @nilcons @bgmari @mstksg @expipiplusx @fhaust @mgajda

@bgamari *

these is updated though already ;) (the isomorphism's ping)

vector-split updated

sdl2 has been updated.

Whilst my package compiles nicely with vector-<IP_ADDRESS>, a change of behaviour in the vector package causes breakage. I hope this can be resolved within vector (as I wouldn't be surprised other code could be broken because of this change as well): https://github.com/haskell/vector/issues/152

sampling-0.3.2 is fixed.

tz and tzdata updated.

vector-sized with fix pushed to hackage

LTS 8 will be released soon, probably with vector-<IP_ADDRESS>.
After the LTS 8.0 release, the packages listed below (and any that depend on them) will continue to be included in LTS 8 builds, but will be dropped from nightly builds until a release compatible with vector-<IP_ADDRESS> is made available.

Chart-1.8.1 (>=0.9 && < 0.12). No maintainer. @timbod7. Used by: library
bloodhound-<IP_ADDRESS> (>=0.10.9 && < 0.12). Chris Allen<EMAIL_ADDRESS>@bitemyapp. @bitemyapp. Used by: library, test-suite
cassava-<IP_ADDRESS> (< 0.12). Michael Snoyman<EMAIL_ADDRESS>@snoyberg. @hvr. Used by: library, test-suite, benchmark
diagrams-cairo-1.4 (>=0.10.0 && < 0.12). Brent Yorgey<EMAIL_ADDRESS>@byorgey. @bergey @byorgey @fryguybob @jeffreyrosenbluth. Used by: library
hashtables-<IP_ADDRESS> (>=0.7 && < 0.12). Gregory Collins<EMAIL_ADDRESS>@gregorycollins. @gregorycollins. Used by: library
reedsolomon-<IP_ADDRESS> (>=0.10 && < 0.12). Nicolas Trangez<EMAIL_ADDRESS>@NicolasT. @NicolasT. Used by: library, test-suite, benchmark
repa-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
repa-algorithms-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
repa-io-<IP_ADDRESS> (==0.11.*). Colin Woodbury<EMAIL_ADDRESS>@fosskers.. Used by: library
rethinkdb-<IP_ADDRESS> (>=0.10 && < 0.12). Brandon Martin<EMAIL_ADDRESS>@codedmart. @atnnn. Used by: library
riak-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Tim McGilchrist<EMAIL_ADDRESS>@tmcgilchrist. @markhibberd. Used by: library
safecopy-0.9.2 (>=0.10 && < 0.12). No maintainer. @acid-state. Used by: library, test-suite
stb-image-redux-<IP_ADDRESS> (>=<IP_ADDRESS> && < 0.12). Alexis Williams<EMAIL_ADDRESS>@typedrat. @sasinestro. Used by: library, test-suite
vector-fftw-<IP_ADDRESS> (>=0.9 && < 0.12). Ben Gamari<EMAIL_ADDRESS>@bgamari. @bgamari. Used by: library
wavefront-<IP_ADDRESS> (==0.11.*). Dimitri Sabadie<EMAIL_ADDRESS>@phaazon. @phaazon. Used by: library
wordpass-<IP_ADDRESS> (>=0.10 && < 0.12). Michal J. Gajda<EMAIL_ADDRESS>@mgajda. @mgajda. Used by: library, executable

@DanBurton we've got a release coming soon that already fixes the vector bump and can easily fix the hspec bump, we're just doing some house cleaning before-hand because it's a big change for unrelated-to-Stackage reasons.

Chart-1.8.2 uploaded.

I’m updating wavefront. Is that too late? :D

bloodhound-<IP_ADDRESS> is released with vector-<IP_ADDRESS> compatibility.

stb-image-redux is now vector-<IP_ADDRESS> compatible.

I just pinged @gregorycollins again and he made a new release of hashtables that supports vector-0.12.  I think this may unblock a large number of packages that are currently excluded.  @DanBurton ?
(Also, I updated diagrams-cairo which was blocked on hashtables.)

Thanks a lot, @byorgey, for the update!  Very helpful


pilot builds fails with "The URL path is not valid"

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description

When I try to invoke pilot builds command with App Store Connect API, I get an error with 'The URL path is not valid'.
It might be the same issue #17283, but since it is the different API, I've posted a new issue.
Command executed
$ fastlane pilot builds --api_key_path ***

Complete output when running fastlane, including the stack trace and command used

Traceback (most recent call last):
	17: from ~/.anyenv/envs/rbenv/versions/2.7.2/bin/fastlane:23:in `<main>'
	16: from ~/.anyenv/envs/rbenv/versions/2.7.2/bin/fastlane:23:in `load'
	15: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/bin/fastlane:23:in `<top (required)>'
	14: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/fastlane/lib/fastlane/cli_tools_distributor.rb:111:in `take_off'
	13: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/commands_generator.rb:18:in `start'
	12: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/commands_generator.rb:166:in `run'
	11: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/delegates.rb:15:in `run!'
	10: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in `run!'
	 9: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:476:in `run_active_command'
	 8: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:153:in `run'
	 7: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:178:in `call'
	 6: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/commands_generator.rb:90:in `block (2 levels) in run'
	 5: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/build_manager.rb:183:in `list'
	 4: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/models/app.rb:360:in `get_build_deliveries'
	 3: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_build_deliveries'
	 2: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/testflight/testflight.rb:374:in `get_build_deliveries'
	 1: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/api_client.rb:193:in `handle_response': The URL path is not valid - The resource 'buildDeliveries' does not exist (Spaceship::UnexpectedResponse)
	17: from ~/.anyenv/envs/rbenv/versions/2.7.2/bin/fastlane:23:in `<main>'
	16: from ~/.anyenv/envs/rbenv/versions/2.7.2/bin/fastlane:23:in `load'
	15: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/bin/fastlane:23:in `<top (required)>'
	14: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/fastlane/lib/fastlane/cli_tools_distributor.rb:111:in `take_off'
	13: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/commands_generator.rb:18:in `start'
	12: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/commands_generator.rb:166:in `run'
	11: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/delegates.rb:15:in `run!'
	10: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in `run!'
	 9: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:476:in `run_active_command'
	 8: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:153:in `run'
	 7: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:178:in `call'
	 6: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/commands_generator.rb:90:in `block (2 levels) in run'
	 5: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/pilot/lib/pilot/build_manager.rb:183:in `list'
	 4: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/models/app.rb:360:in `get_build_deliveries'
	 3: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/2.7.0/forwardable.rb:235:in `get_build_deliveries'
	 2: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/testflight/testflight.rb:374:in `get_build_deliveries'
	 1: from ~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/api_client.rb:113:in `get'
~/.anyenv/envs/rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/fastlane-2.170.0/spaceship/lib/spaceship/connect_api/api_client.rb:193:in `handle_response': \e[31m[!] The URL path is not valid - The resource 'buildDeliveries' does not exist\e[0m (Spaceship::UnexpectedResponse)

Environment

✅ fastlane environment ✅
Stack

Key
Value

OS
10.15.6

Ruby
2.7.2

Bundler?
false

Git
git version 2.24.3 (Apple Git-128)

Installation Source
~/.anyenv/envs/rbenv/versions/2.7.2/bin/fastlane

Host
Mac OS X 10.15.6 (19G2021)

Ruby Lib Dir
~/.anyenv/envs/rbenv/versions/2.7.2/lib

OpenSSL Version
OpenSSL 1.1.1i  8 Dec 2020

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
12.3

System Locale

Variable
Value

LANG
ja_JP.UTF-8
✅

LC_ALL

LANGUAGE

fastlane gems

Gem
Version
Update-Status

fastlane
2.170.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

did_you_mean
1.4.0

slack-notifier
2.3.2

atomos
0.1.3

CFPropertyList
3.0.3

claide
1.0.3

colored2
3.1.2

nanaimo
0.3.0

xcodeproj
1.19.0

rouge
2.0.7

xcpretty
0.3.0

terminal-notifier
2.0.0

unicode-display_width
1.7.0

terminal-table
1.8.0

plist
3.5.0

public_suffix
4.0.6

addressable
2.7.0

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

babosa
1.0.4

colored
1.2

highline
1.7.10

commander-fastlane
4.4.6

excon
0.78.1

ruby2_keywords
0.0.2

faraday
1.1.0

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

http-cookie
1.0.3

faraday-cookie_jar
0.0.7

faraday_middleware
1.0.0

fastimage
2.2.0

gh_inspector
1.1.3

json
2.3.0

mini_magick
4.11.0

rubyzip
2.3.0

security
0.1.3

xcpretty-travis-formatter
1.0.0

dotenv
2.7.6

bundler
2.1.4

naturally
2.2.0

simctl
1.6.8

jwt
2.2.2

uber
0.1.0

declarative
0.0.20

declarative-option
0.1.0

representable
3.0.4

retriable
3.1.2

mini_mime
1.0.2

multi_json
1.15.0

signet
0.14.0

memoist
0.16.2

os
1.1.1

googleauth
0.14.0

httpclient
2.8.3

google-api-client
0.38.0

google-cloud-env
1.4.0

google-cloud-errors
1.0.1

google-cloud-core
1.5.0

rake
12.3.3

digest-crc
0.6.2

google-cloud-storage
1.29.2

emoji_regex
3.2.1

jmespath
1.4.0

aws-partitions
1.408.0

aws-eventstream
1.1.0

aws-sigv4
1.2.2

aws-sdk-core
3.110.0

aws-sdk-kms
1.39.0

aws-sdk-s3
1.86.2

uri
0.10.0

forwardable
1.3.1

logger
1.4.2

cgi
0.1.0

timeout
0.1.0

stringio
0.1.0

ipaddr
1.2.2

openssl
2.1.2

ostruct
0.2.0

strscan
1.0.3

date
3.0.0

delegate
0.1.0

fileutils
1.4.1

io-console
0.5.6

zlib
1.1.0

singleton
0.1.0

rexml
3.2.3

open3
0.1.0

yaml
0.1.0

psych
3.1.0

mutex_m
0.1.0

I am having the same issue but am using asdf to manage ruby versions. Upvoting for visibility.

I am having the same issue but am using asdf to manage ruby versions. Upvoting for visibility.

Any movement on the issue?

Any movement on the issue?

I had the same issue using the App Store Connect API credentials, but switching back to using plain Apple ID authentication worked.

I had the same issue using the App Store Connect API credentials, but switching back to using plain Apple ID authentication worked.

We are having the same problem and switching back to username+password is no longer an options since Apple enforced 2FA for all accounts.


refactor: Use react-native-test-app to manage our test app

Overview

This PR replaces the test app in the repo with one managed by React Native Test App. This is mainly inspired by my want to add macOS support, which is currently blocked by / tracked at #141. Still, setting up the template test app now will make standing up the macOS portion of the test app trivial come time.
"React Native Test App" provides test apps for all platforms as a package. It handles the native bits, allowing you the developer to focus on the JS. There are a few advantages to using this package:

It makes RN version updates easier, as it will handle the proper native code changes
It makes targeting new platforms (like macOS or Windows) easier, since it has a template to configure each platform's test app.

Steps
I tried to document my steps well with my individual commit messages. In essence:
mv example/ example2 # Move the existing test app out of the way for a bit
yarn add -D react-native-test-app
yarn init-test-app
# The options I chose
# ✔ What is the name of your test app? … MenuExample
# ✔ Which platforms do you need test apps for? › Android, iOS
# ✔ Where should we create the new project? … example
cd example

After this I did a few extra things:

Added generated lock files after running yarn / pod install in the new example test app folder

cd example && yarn && pod install --project-directory:ios
git add yarn.lock ios/Podfile.lock

Ran yarn lint --fix to fix lint errors in the generated test app (mostly double quotes vs single quotes)
Added a .gitignore file that wasn't included in the template test app.
Modified the example test app's package.json to include the following dependency so we can actually test menu:

"@react-native-menu/menu": "../"

Then finally, I copied over the JS source from the old test app, and deleted the old test app
rm example/index.js example/App.js
mv example2/index.tsx example.index.tsx
mv example2/src/App.tsx example/src/App.tsx
rm -rf example2/

Open Issues

run-ios doesn't work (building from Xcode does though). This is due to a react-native-communinty/cli issue.

Issue to track fixing that here: https://github.com/microsoft/react-native-test-app/issues/375

The example test app didn't include a .gitignore, so I copied over the one in the RNTA (react-native-test-app) repo.

Issue to track having that automatic here:  Issue to have that automatic: https://github.com/microsoft/react-native-test-app/issues/374

Test Plan

Locally ran the iOS and Android test apps. Once open issues are addressed, will also make sure run-android and run-ios work as expected.

Since I couldn't add you as reviewers..
@tido64 who maintains react-native-test-app
@Naturalclar who maintains react-native menu
Alas, I couldn't add macOS support because react-native-macos isn't on 0.64 yet :(. I decided to go forward with moving the test app anyway to make it easier to add macOS support in the fut
Keeping this as a draft at the moment because run-ios doesn't work. If that's not a blocker, I can make it a full PR. Working on filing the right bugs in the cli now =)

@Naturalclar This should be ready for review! It should also make updating to RN 0.65 very simple, I just didn't want to bundle that in the same review. Thanks @tido64 for helping fix upstream CLI issues!

Alas, I couldn't add macOS support because react-native-macos isn't on 0.64 yet :(.

Btw, the first 0.64 versions of react-native-macos is quite usable now ;)

Alas, I couldn't add macOS support because react-native-macos isn't on 0.64 yet :(.

Btw, the first 0.64 versions of react-native-macos is quite usable now ;)

Yep! I have a working menu component I wrote for macOS elsewhere that I can port here once I get the chance!


Feature Request - Support objects

Supports/support fixity could be confusing for users. There should be a specific fixity object that handles this, istead of the a list of fixities in each DOF.:

closed in #11


Add a Resource Page to the Documentation

When starting with Slinky it was hard to find examples, talks etc..
Is it possible to add a page to the documentation, that contains:

Blog Articles
Talks
Blog Articles
Cheat Sheet
Sample Projects
Projects using Slinky

I took it from here (A great example):
https://zio.dev/docs/resources/resources
I would be happy to create the first version of such a page.

This is a great idea! A PR to add an initial version of a resources page would definitely be welcome!


[Bug]: Icon search goes black when searching specific terms

Search for "plane" or "lane"
(seems like this was working with Carbon v1.56)
https://github.com/carbon-design-system/carbon-website/assets/2753488/ad66b117-3bda-4ca3-a39c-e7e18ab07f97
error in local dev environment

Error seems to be coming from the KubernetesControlPlaneNode icon

still broken


Bumping avro due to security issues

According to dependency-check, avro uses jackson-databind and is susceptible to the following vulnerabilities:

CVE-2019-14540
CVE-2019-14892
CVE-2019-14893
CVE-2019-16335
CVE-2019-16942
CVE-2019-16943
CVE-2019-17267
CVE-2019-17531
CVE-2019-20330
CVE-2020-10672
CVE-2020-10673
CVE-2020-10968
CVE-2020-10969
CVE-2020-11111
CVE-2020-11112
CVE-2020-11113
CVE-2020-11619
CVE-2020-11620
CVE-2020-14060
CVE-2020-14061
CVE-2020-14062
CVE-2020-14195
CVE-2020-24616
CVE-2020-24750
CVE-2020-25649
CVE-2020-8840
CVE-2020-9546
CVE-2020-9547
CVE-2020-9548

This bump will fix these security issues.

One thing I'm not sure of is what is the deploy process for this, but one thing that's perhaps missing is you need to bump the version in project.clj?

One thing I'm not sure of is what is the deploy process for this, but one thing that's perhaps missing is you need to bump the version in project.clj?

Yes! Sorry for the late response, but I've opened other PR that changed the version 🙇


Add --reckless flag for using mainnet

This would probably just be annoying. Docs and warnings as in #716 should be enough.


cephalin-core is wrong. <server-name> is right.

@Soichi-Fukasawa commented 18 hours ago
At "Create connection string"
az sql db show-connection-string --client ado.net --server cephalin-core --name coreDB
Probably, cephalin-core is come from @cephalin .
Please change cephalin-core to .

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

ID: 00961883-36eb-f736-b906-73d4c35e69b0
Version Independent ID: 3a2fd493-9682-eedf-fad1-571b9391cd46
Content: Tutorial: ASP.NET Core with SQL Database - Azure App Service
Content Source: articles/app-service/app-service-web-tutorial-dotnetcore-sqldb.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@v-radelg, @Soichi-Fukasawa, Thanks for taking time to share your valuable feedback. We are making the appropriate changes in the document and it should reflect within 24 hours.

@Soichi-Fukasawa, The requested changes have been merged. The document will reflect the changes within 24 hours.  We will close this out, but if you feel you need more information please just let us know. Thanks again for your feedback.

It is still "cephalin-core" in <az sql db show-connection-string --client ado.net --server cephalin-core --name coreDB>


how to adjust the width of the second column?

Hi, thanks for the amazing theme.
How can I change the width of the second column of this two-column style theme. For example, I wanna enlarge the width of the blog list so that each line can show more words?
Thank you for your help.

You'll need to adjust the theme's CSS on .archive and .page. If you remove the right padding it should give you the effect you want.

Related: #623, #384, #74

Thanks.

See #2093