Race condition on github actions for publishing packanges (gcds-tokens, gcds-components etc)

Github actions "Publish " which publishes our packages to npm sometimes fails after merge. It seems to be a race condition of the package not existing yet right after the workflow is triggered.

Fixed by:

https://github.com/cds-snc/gcds-tokens/pull/189
https://github.com/cds-snc/gcds-components/pull/329

gcds-utility doesn’t need the fix since it’s using the local dist files and doesn’t do an npm install:
https://github.com/cds-snc/gcds-utility/blob/main/.github/workflows/publish.yml#L47-L48


improved UI

Hey @iampavangandhi I have made some UI design changes that were most important. detailed information of what and why the changes are made is in the pdf here

@sairaj2119 pdf is not accessible. showing 404 error

@sairaj2119 pdf is not accessible. showing 404 error

check it now again

@sairaj2119 great work :+1: but there are still some UI issues in the contact form (in mobile layout as well as web layout) can you improve that also. You can also experiment in that if you want.

Sorry dude I am a little busy with freelancing I will definitely contribute
I find some play time
On Thu, Oct 1, 2020, 12:49 Pavan Gandhi<EMAIL_ADDRESS>wrote:

@sairaj2119 https://github.com/sairaj2119 great work 👍 but there are
still some UI issues in the contact form (in mobile layout as well as web
layout) can you improve that also. You can also experiment in that if you
want.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iampavangandhi/iampavangandhi.github.io/pull/4#issuecomment-701941157,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN2PE6LHRNSJL4XFZ7X4Y4DSIQUQ5ANCNFSM4SAA3TEQ
.


Support checking uv.lock aligns with latest changes to pyproject.toml

Request for a feature to check that no (relevant) changes to pyproject.toml have been made since uv.lock was last updated.
For reference, this is implemented in Poetry via the command poetry check --lock (previously under poetry lock --check).

Does uv lock --locked work for you?

We might want to add an alias for --locked in the uv lock command — --locked exists to match the rest of the commands but it's non-obvious what it means.

I think everything you've outlined there is also true of uv lock --locked.

Yeah similarly:
❯ uv lock --locked --offline
Resolved 1 package in 2ms

❯ uv add anyio --frozen

❯ uv lock --locked --offline
Resolved 4 packages in 5ms
error: The lockfile at `uv.lock` needs to be updated, but `--locked` was provided. To update the lockfile, run `uv lock`.

Thank you :) will use uv lock --locked --offline in that case
Reading the command description ("Assert that the uv.lock will remain unchanged"), I didn't pick up that this was the intended usage... if it's outlined in the docs then I missed it

I'll follow up with some improvements here.

If I set a constraint on a dependency, like dependencies = [ 'exceptiongroup>=1.0.0; python_version < "3.11"',], then running uv lock --locked --offline results in an error:
Using CPython 3.12.6 interpreter at: /opt/hostedtoolcache/Python/3.12.6/x64/bin/python
  × No solution found when resolving dependencies:
  ╰─▶ Because only exceptiongroup{python_full_version < '3.11'}<1.0.0 is
      available and your project depends on exceptiongroup{python_full_version
      < '3.11'}>=1.0.0, we can conclude that your project's requirements are
      unsatisfiable.

We presume we can't query the index to discover more versions of exceptiongroup — it sounds correct that we fail there?

Do I need to query / build the index somehow before running the --locked --offline command, then?

@danyeaw what's your goal? If the lockfile is up to date, I don't think we'll query the index and the command should succeed. If not, it'll fail.

@zanieb I have one extra dependency for my project that is only applicable for older versions of Python. I want to then check the lock file integrity in CI, and it fails with the error above. The lock file is up to date.


Export ForcedType and AMQPArray

Sorry for the blitz of issues. I was working through a long scenario and wanted to make sure it worked end-to-end before raising issues for the things I needed to get it working 😄
I am trying to send a message whose body is an AMQP value with the following format:
{
    "lock-tokens": ["ec59a901-4643-4980-8aae-62db992610c8"/*uuid*/]
}

The problem is that the service I'm talking to specifically expects a map with an array as the value for key "lock-tokens" and uuids as entries in the array. the default encoding from JSON will produce a map, but arrays get turned into lists by default and strings are turned into strings, not uuids.
While I could specify a custom encoder to perform the correct encoding for the body, it seems more straightforward to make use of the type classes that are already available in node-amqp10. Would it be reasonable to export these classes so that I can send something like this instead and guarantee the encoding of my body is what I'm expecting?
new ForcedType("map", {
    "lock-tokens": new AMQPArray(["ec59a901-4643-4980-8aae-62db992610c8"], 0x98)
})

@princjef could something like this help here: https://github.com/noodlefrenzy/node-amqp10/blob/master/lib/index.js#L37, you should be able to define types like:
[ 'map', { some: 'map' } ]

or
[ 'map', [ 'symbol', 'Key 1' ], [ 'ulong', 1 ], [ 'symbol', 'Key 2' ], [ 'boolean', false ] ]

I'd really prefer to figure out how to make this thing more natural, and complete than expose the internal classes if possible.

@mbroadst Yeah that's reasonable. I had seen node-amqp-encoder but not the translator.
I'll play around with it a bit and see if I can get it to work. At the very least extending that would probably be preferable to exporting the classes

@princjef yeah I mean, if you have the time it would be really appreciated. I'd like to make that (or whatever replaces it) the default method for explicit typing, so if we can think up a great interface together that would be fantastic.

@princjef for instance, I kind of like the idea of exporting something like translator as type instead, maybe with properties for each type. e.g.:
const type = require('amqp10').type;
let message = type.map({ some: type.array([10, 20, 30]) });

just spitballing

@mbroadst yeah something like that would be incredibly useful. I should have some time here and there and would be happy to do some brainstorming/coding. A good explicit type format would be very helpful in resolving some of the encoding issues people have.
I do like wrapping values with a type because it still keeps the general structure, just with some extra annotations. The big question with that approach is whether having it be serializable to JSON is important (which is the main benefit of the node-amqp-encoder format to me).
As for the specific use case from this issue, I ran into a couple of problems with the array logic:

uuid is not included in node-amqp-encoder, so it fails when the results are encoded. I can submit a PR there to fix that
Even if the type is one of the supported values, it doesn't work. The processor expects the type to be specified as a string, but AMQPArray expects the type as a number. If a string is specified, an extra 0x00 byte is inserted where the code should be (since it's trying to put a string into a byte) and the code is added onto the beginning of each entry. Seems like arrayBuilder needs a string mode.

@princjef sorry I let this one get away from me. Can you provide a small example of how the translator is failing you here? It actually occurs to me that the biggest gap in our code coverage is around the translator, so I'd like to get some unit tests in there for that 😄

@mbroadst no worries. I had actually given some thought to a new translation/type API like you mentioned but haven't had time to do much with it.
If I remember correctly, it was anything involving an array. I think it was something like this, but you should run into the same problem for any array filled with anything (uuid won't work because of a gap in node-amqp-encoder):
['map',
    ['string', 'lock-tokens'], ['array', 'uuid', '88f54527-e090-4315-a3d3-88649300ca78', 'eafaa684-b7d5-49e5-ba3d-80f07321694e']
]


Use the term source

Follow-up to https://github.com/knative/eventing/pull/1882
Proposed Changes

Use the term source.

Release Note

the release artifact kafka-importer.yaml is renamed to kafka-source.yaml

/lgtm

/retest


Display better error message for people who have version for an app in nitro.yaml instead of php_version

Description
Right now, if you still have version for an app, you get:

Error: unable to create the container, Error response from daemon: invalid reference format

Should display a more helpful error message with steps to fix.

Nitro version: 3
Nitro version: 3
Docker version: 4

Hi, we are closing this issue as we have decided to retire Nitro, so no additional work will occur on this project. You can read the official blog post here https://craftcms.com/blog/retiring-craft-nitro. We appreciate everyones feedback and involvement and we look forward to refocusing our efforts on Cloud!
If you're looking for a new local development environment, we recommend DDEV and have a knowledge base article to help you with the transition: https://craftcms.com/knowledge-base/migrating-from-craft-nitro-to-ddev.


Update use-harness-cloud-build-infrastructure.md

new macOS image

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65ae9040bb7760200e3332e3--harness-developer.netlify.app


Allow k8s API clients to watch a subset of resources

In this branch I'm updating k8s.NewAPI to accept a list of resource types to watch when configuring a new API client. This will allow clients to only watch the resource types that they require, resulting in fewer API calls overall. It will also allow us to more tightly scope RBAC configurations for these components when they're running under different service accounts.
As part of this change, I'm also adding a config map resource type, which is required for #675.
Fixes #1114.

Thanks! 🚢


Subsequent DCCs: Matching of persons - which fields are used how?

Avoid duplicates

[x] Question is not already answered in the FAQ
[x] Question is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository - iOS may handle it differently
[x] Question has not already been asked in another issue -  I think so.

Your Question
I found this in Google Play Store reviews today:

Mein Nachname wurde auf dem Impfzertifikat 1.Impfung in kleinen Buchstaben und im Zertifikat der 2. Impfung mit grossem Anfangsbuchstaben geschrieben. Die App liefert eine Fehlermeldung beim Scan der 2.Impfung und akzeotiert dessen Zertifikat nicht. Was soll ich machen?

In case the error message results from a mismatch of different capitalization of the person's name throughout the issuing of the DCCs:
I was looking to a PR that was associated with person identifiers for certificate matching recently. For some reason I can't find it anymore. But when I was looking into the code, I was very certain that matching for the name is performed with standardized name, which means, the compared strings are all big caps and free of any non-Latin characters. I think @chiljamgossow was working on it, but I'm not sure. So, this user reported problem should not have happend.
Is matching with standardized name introduced in a later release (>=2.4.x)? Or did something else went wrong?
A kind of flexible matching of certifcates (with regard to persons' names) becomes crucial at the moment, when people take (further) vaccinations/tests in other countries as their home countries. Often medical staff in other countries can't use/type the special characters (like 'ä') used in persons' names on their keyboards when issuing certificates, so relying on the standardized name is important.
Edit: I found another, similar report:

Leider erhalte ich beim Scan des elektr, 2.  Sie können in der App nur Zertifikate einer Person registrieten". Die Zertifikate wurden offiziell durch d.Apotheke ausgegeben. Die App CovPass ordnet beide fehlerfrei für meine 1.und 2. Impfung zu. Nachtrag: Danke für.d.schnelle Hilfe; d.Namensdarstellung war tats. fehlerhaft. (Kleinschrift)

DCCs are matched/grouped based on date of birth and first+lastname (standardized).
https://github.com/corona-warn-app/cwa-app-android/blob/c87daaa408abdcb0296fbc1b1a4933918746b2bf/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/covidcertificate/common/certificate/CertificatePersonIdentifier.kt#L10
https://github.com/corona-warn-app/cwa-app-android/blob/c87daaa408abdcb0296fbc1b1a4933918746b2bf/Corona-Warn-App/src/test/java/de/rki/coronawarnapp/covidcertificate/common/CertificatePersonIdentifierTest.kt#L14

@d4rken
Hi Matthias, thanks for your answers!
Your pointers are referencing the code that I was thinking about when writing:

I was looking to a PR that was associated with person identifiers for certificate matching recently. For some reason I can't find it anymore. But when I was looking into the code, I was very certain that matching for the name is performed with standardized name, which means, the compared strings are all big caps and free of any non-Latin characters.

Meanwhile we saw that successful matching certificates depends on how TSI & IBM/Ubirch beside other 3rd parties implement entry/generation of ICAO conformant names. And this is not optimal yet:
https://github.com/corona-warn-app/cwa-app-android/issues/3670
https://github.com/corona-warn-app/cwa-quick-test-frontend/issues/185
As the questions are answered, I'm closing here.
Have a nice day!


Making geocoder point label go away

Sorry if this has come up somewhere before, but when a location search brings us to a point and labels it, we can clear the point  itself by clicking the x at the right end of the search bar. But the label sticks around — any way to axe?

ugh yeah this is annoying, i'm not sure why it hides the marker but not the label, they're all part of the same component.
will take a look though...

i got this to work but there are a lot of scenarios around it (nothing new, same as before, just more apparent now that the clear works better). for example, how long should the marker and label stay around? like if i go to another view/panel/route, should it close? should opening the Search popout from a non-Home clear it?
nuclear and heavy-handed are the easy approaches and i don't want to go down any other roads since this isn't a new problem, but one thing to make life easier is if i just use a popup instead. hard to explain why but does this work for you?

its X doesn't clear the geocoder, but at least it gets the popup out of the way and leaves geocoder intact.
and i guess i could make it clear the popup on any map click instead of on route change? feels fine to me now that the X is there. marker didn't have it.

closeable popup seems good. and maybe clearing the popup on map click, your call


Fix getting duplicated date from the same instance

Previously, when same instance send statistic more than one time per day - it stored in different records in database.
We propose update record when we already have statistic for this day for avoid dublication.

Codecov Report

Merging #81 into fix_multistatistic_per_day will decrease coverage by 0.03%.
The diff coverage is 100%.

@@                      Coverage Diff                       @@
##           fix_multistatistic_per_day      #81      +/-   ##
==============================================================
- Coverage                       99.11%   99.08%   -0.04%
==============================================================
  Files                              33       33
  Lines                             908      872      -36
==============================================================
- Hits                              900      864      -36
  Misses                              8        8

Impacted Files
Coverage Δ

web/olga/analytics/models.py
100% <100%> (ø)
:arrow_up:

web/olga/analytics/views.py
94.79% <100%> (-0.26%)
:arrow_down:

web/olga/analytics/tests/test_views.py
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Update package.json

Background
MSUXF's postinstall script runs bower, and bower may not be installed
Changes done
Bump msuxf version to 1.2.3 to include bower as a dependency instead of a devDependency, to make sure it gets installed before runing msuxf's postinstall script (which does a bower install)
Pending to be done
N/A
Notes
N/A


Wallet won't detect spends constructed outside of federation's wallet

Credit to @justinmoon for highlighting the problem out-of-band.
Problem
The federation's wallet will only recognize spends that were inserted in the db as PendingTransactions (code path). If funds are spent using a transaction constructed outside of the federation's wallet, the wallet will not detect the spend.
Scenario
The recovery tool allows guardians to construct, sign, and broadcast a transaction that will move funds. The docs for the recovery tool explicitly warn the tool should only be used if the federation has halted and will never be turned on again, however if the federation starts the wallet will not detect the spend.
Potential Solutions

Add logic in wallet to monitor all known UTXOs
Add logic in recovery tool that will make it difficult to start the federation if tool is used
No action - assume users will understand the implications of using the recovery tool
Other?

I have not yet verified the behavior of using the recovery tool, moving funds, then restarting the federation but plan to do so as part of https://github.com/fedimint/fedimint/issues/3664.

The easiest thing to do would be to check our UTXO set on startup using gettxout and panic/warn+shutdown if one is missing.

That's a great idea! I think at a minimum it'd be worth adding this sanity check on startup.

I'm not sure if we should also keep checking while the federation is running. What would be do if we detected a missing UTXO?

Yeah, this is a prickly situation. I'm not suggesting we introduce this complexity, but as a user of a mint I'd like to ensure that I can't send additional funds to the federation while also being able to withdraw if the wallet has any remaining UTXOs.
If we continue checking while the federation is running and simply recognize the spend, the audit would trigger a panic/shutdown due to negative net assets. This will at least prevent further deposits to the federation.
https://github.com/fedimint/fedimint/blob/664aa751a14c6f2b898eaaaa90c2ae8d47fc94b8/fedimint-server/src/consensus/server.rs#L622-L624

In general I agree that if such an invariant is broken we should just shut down, the problem compared to the audit mechanism is that we would rely on an external service. One subtle misinterpretation of the bitcoin rpc API or faulty retry logic could crash federations. Even given that I'm on the fence.
Maybe we can introduce an error log+API endpoint first and monitor how it goes with live federations. Next step would be introducing local configuration that controls if we should shut down if this happens. Last step would be turning this on by default for new federations.


Feature Request: JSON alternatives?

Hello I have successfully used Charge in my website. Mainly for displayed projects using json data.
Some alternatives (supersets) of JSON could be used to ease the data creation.
https://github.com/hjson/hjson-js
https://github.com/json5/json5
But maybe a simple js file that exports an object could work for data too.
It would be helpful specially for multiline strings.
Thanks for this awesome project 👍

Hey!  I’m constantly trying to comment out lines and/or having to fiddle with trailing commas as I add or remove data, which is super annoying.
I’m tangentially aware of the idea behind JSON supersets but I’ve never used one directly. Conceptually I love the idea, it’s just in practice I feel like it opens up a whole can of worms. Do I choose one superset or support all of them? Which is more/less confusing, supporting the superset under the .json extension or with a different extension? Will people get confused as to what a superset is and why something does or does not work for them in different extensions? It feels like it could be quite confusing for some people.
Allowing JS files that export an object as data files is interesting though… aside from the better ergonomics of working with a JavaScript object, it sort of dovetails into #864. It could be a nice way for people to do dynamic data fetching 🤔


Change bookmarks implementation symmetric with history

I was going to move this sometime to be imported and saved at the same time as history so it supports multiple views, but wanted to check if it works properly. Is bookmarks a functional feature right now?

Last I checked bookmarks functioned, but the experience using them is poor.
I was hoping to make F2 goto next bookmark, shift+F2 goto prior bookmark, ctrl+F2 to set bookmark, and alt+F2 to clear bookmark. I haven't worked out how to make ctrl+F2 and alt+F2 work reliably. So that left bookmarks in a less than ideal place. e.g. to set a bookmark, press ctrl+e to enter the command prompt and type bm to create a bookmark ( is carriage return).

Working on this. Should have a working implementation done sometime this week.

What do you think about making bookmarks part of history? I'm thinking that it will be saved when user history is saved (so when the user saves the file with CTRL+S) and it's simply another entry in the fileHistory dictionary. We could get rid of bookmarks.py since I implemented all the bookmark functions inside text_buffer.py.


meddler.Insert: DB error in Exec: UNIQUE constraint failed: config.config_hash, config.config_repo_id

As per our chatroom discussion
When two hooks are received at the same time, with the same yaml, and drone tries to insert both at the same time, the following exception occurs:
Jul 24 22:20:13 coreos0 docker: time="2017-07-24T20:20:12Z" level=error msg="failure to persist config for ____GITHUB_ORG/GITHUB_PROJECT_______. meddler.Insert: DB error in Exec: UNIQUE constraint failed: config.config_hash, config.config_repo_id"
Jul 24 22:20:13 coreos0 docker: time="2017-07-24T20:20:12Z" level=error msg="Error #01: meddler.Insert: DB error in Exec: UNIQUE constraint failed: config.config_hash, config.config_repo_id\n" ip=<IP_ADDRESS> latency=1.71155372s method=POST path="/hook" status=500 time="2017-07-24T20:20:12Z" user-agent="GitHub-Hookshot/62709df"

Redelivering the payload via GitHub GUI solves the problem.
andreas@coreos0 ~ $ docker images
REPOSITORY                               TAG                  IMAGE ID            CREATED             SIZE
drone/agent                              0.8                  230e966bc666        4 days ago          12.98 MB
drone/drone                              0.8                  185b47a4268a        4 days ago          27.26 MB

fixed by https://github.com/drone/drone/pull/2142


[AIRFLOW-686] Match auth backend config section

Dear Airflow Maintainers,
Please accept this PR that addresses the following issues:

https://issues.apache.org/jira/browse/AIRFLOW-686

This commit makes that refers the same configuration when using
ldapgroup owner mode with ldap auth.

Current coverage is 66.55% (diff: 100%)

Merging #1930 into master will decrease coverage by <.01%

@@             master      #1930   diff @@
==========================================
  Files           135        135
  Lines         10133      10133
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           6745       6744     -1
- Misses         3388       3389     +1
  Partials          0          0

Powered by Codecov. Last update b674656...9a83bef


[Profiling/Build] Add crashtracking feature for windows (event it's not ready yet)

What does this PR do?
Since https://github.com/DataDog/libdatadog/pull/551, crashtracker has its own header crashtracker.h. This header is not part of the nuget package and prevent compilation on windows.
Motivation
Make sure we can compile in Visual Studio.
Additional Notes
Waiting for https://github.com/DataDog/libdatadog/pull/611
Anything else we should know when reviewing?
How to test the change?
Downloaded the nuget package (from the gitlab job) and checked that :

crashtracker.h is present
ddog_crasht_demangle symbol is present

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 72.66%. Comparing base (c48d94b) to head (58a3bc0).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #613      +/-   ##
==========================================
+ Coverage   72.63%   72.66%   +0.02%
==========================================
  Files         246      246
  Lines       34964    34971       +7
==========================================
+ Hits        25396    25411      +15
+ Misses       9568     9560       -8

Components
Coverage Δ

crashtracker
20.44% <ø> (+0.05%)
:arrow_up:

datadog-alloc
98.73% <ø> (ø)

data-pipeline
90.12% <ø> (ø)

data-pipeline-ffi
0.00% <ø> (ø)

ddcommon
82.82% <ø> (ø)

ddcommon-ffi
68.11% <ø> (ø)

ddtelemetry
59.02% <ø> (ø)

ipc
83.61% <ø> (ø)

profiling
84.26% <ø> (ø)

profiling-ffi
77.42% <ø> (ø)

serverless
0.00% <ø> (ø)

sidecar
40.13% <ø> (ø)

sidecar-ffi
0.00% <ø> (ø)

spawn-worker
50.36% <ø> (ø)

tinybytes
91.66% <ø> (ø)

trace-mini-agent
70.88% <ø> (ø)

trace-normalization
98.25% <ø> (ø)

trace-obfuscation
95.73% <ø> (ø)

trace-protobuf
77.67% <ø> (ø)

trace-utils
92.83% <ø> (-0.18%)
:arrow_down:

It's hard for most of us to try this out without access to a windows machine, but on the other hand the change does look reasonable + it has a really tiny blast radius, so I see no reason not to merge it :)

The package is run on every PR in Gitlab. At least, if files were missing or the names have changed, it would have failed.
But yeah, in my case, I downloaded the nuget package, updated the project with it and built the project.


gNMI and path with both origin and YANG namespaces

Hi @akarneliuk ,
I need to generate paths that have both an origin, and a YANG namespace in the top-level element (and in fact, in subsequent elements too). Those paths look like the second example in https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1610/b_1610_programmability_cg/gnmi_protocol.html#id_84819:
path {
  origin: "rfc7951"
  elem {
    name: "openconfig-interface:interfaces"
  }
  elem {
    name: "interface"
    key {
      key: "name"
      value: "Loopback111"
    }
  }
}

The current code in pygnmi can't generate the path above, due to the way it parses path elements that contain :.
Unfortunately, Schema path encoding conventions for gNMI doesn't specify how to encode the origin of the path. One possible way to do this is to look at the first path element only, and if that element contains a :, then set the origin from that. The XPATH for the path I quoted above would look like: rfc7951:openconfig-interfaces:interfaces/interface[name=Loopback111], or (maybe more explicit): rfc7951:/openconfig-interfaces:interfaces/interface[name=Loopback111]. I have some code that does just that, see the draft PR #41  I'm opening at the same time. The problem with that approach is that this doesn't quite conform to XPATH specification.
Another possible way is to add an extra optional argument to get, subscribe, etc., that specifies the origin. If that argument is unset, then guess the origin from the XPATH (ie. current behaviour). If that argument is set, then it is used for the gNMI path, and : in the path elements is not treated specially. Ie. to get the path I quoted above, you would have to call gnmi_path_generator("/openconfig-interfaces:interfaces/interface[name=Loopback111]", origin="rfc7951"). The downside of this approach is that it requires more changes and the API becomes a bit more complex. I haven't tried to write that approach yet Draft of that second approach: https://github.com/fperrin/pygnmi/commits/fp-gnmi-path-origin
What do you think?

Hello @fperrin ,
sorry,  was extremely busy past 3 weeks and really didn't have time to look into that earlier. What you say is an interesting point. So we build the origin as we build in accordance to gNMI specification: https://github.com/openconfig/reference/blob/master/rpc/gnmi/mixed-schema.md
I'm a little bit uneasy about adding extra arguments, as the idea to keep pygnmi as simple and as close the gNMI specification as possible. Moreover, I've read the mentioned RFC 7951 (https://datatracker.ietf.org/doc/html/rfc7951), and I don't see there any mentioning about origin at all.
having said that, is there a problem to use pygnmi with Cisco IOS as it requires the module name to be the top level key? If yes, would it mean that in all the path for Cisco IOS we need to include the module? If that is the case, probably, we can thing to add a variable to gNMIclient, which could be rfc7951 and which then alters the gnmi_path_genetator, as you explained in the second case.
Best,
Anton

Hi @akarneliuk ,
Point taken about adding extra arguments, I'll not use that approach.
I'm using pygnmi with a device (that's not released yet) that expects paths of the form described there (ie. I'm quoting that Cisco document because the device I'm using has paths of the same format, not because I'm using a Cisco device) :

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1610/b_1610_programmability_cg/gnmi_protocol.html#id_84819
An RFC 7951-specified namespace prefixing also uses the YANG module name. For example, the openconfig path to a loopback interface will be /openconfig-interfaces:interfaces/interface[name=Loopback111]/
The following example shows a gNMI path with RFC7951 namespacing:

path {
  origin: "rfc7951"
  elem {
    name: "openconfig-interface:interfaces"
  }
  elem {
    name: "interface"
    key {
      key: "name"
      value: "Loopback111"
    }
  }
}

The important points are that there is a non-default origin, and some of the path elements still have : in the name. In fact, elements besides the first one can have : in the name.
The more I think about it, the more I think this all means we can get away with a very simple change: only treat : specially in the first element to set the origin, and ignore it otherwise. I'll give that a go and update #41 accordingly.
That'd mean you can generate the path above from the string rfc7951:openconfig-interfaces:interfaces/interface[name=Loopback111].
I'm not sure about the extra variable to gNMIclient, because then it means all requests will have to use the same origin, and the document you linked hints at devices that have different parts of their tree addressed differently (I do not know of devices that require that, I certainly don't have devices that require that, but it's a possibility).


es2015 support

Running the component in legacy browsers that don't support ES6, the component failed to render.

Issue addressed and merged


Pull to refresh in List component.

I have used List component and it's very handy to use. But I want to use list component for pull to refresh and infinite scrolling.
Can you please give me some solution?

i also want to pull-to-refresh list

Will be supporting this in the future versions

Which versions approximately? (So I can take a look at it then, of course I do not need a date, just an estimation, will it be weeks/months?) Thanks.

@gala132 NativeBase List is just a wrapper around React Native's ListView, so the way you implement it for React Native, it should be no different.
@himanshu-satija @sankhadeeproy007 Right?

Added RefreshControl to List. Already works for Content

Not working on android 6
Rows are displayed, but no refresh control
Here's my code

<Container>
            <Content>
                <List

                    refreshControl={
                        <RefreshControl refreshing={this.state.isRefreshing}
                            onRefresh={this.refreshList.bind(this)}
                            />
                    }

                    dataArray={this.props.contacts}
                    renderRow={(row) => <Row row={row} />}
                    >

                </List>
            </Content>
        </Container >

Which version of NativeBase are you using?

"native-base": "^0.5.20",

@priyesh9875 The List cannot go in a Content if you want pull to refresh, change Content to View (import from nativebase)

I found that if I use View instead of Content, the last ListItem will be clipped off but displayed if use Content instead of View.
I'm using 0.42

@seymores I continue to have issues with using  instead of . I have seen in several issues to use  instead of  when using lists, but it breaks my layouts every time I attempt it. When I use , the page lays out perfectly. Also have heard using  in  is a performance problem, but I haven't seen another way to get it to work and still have the header, content, footer layout style rendering work properly.

@seymores Add style {flex: 1} to , problem solved.
<View style={{flex: 1}}> <List> ... <List> </View>

I found a new solution!
Add refreshControl prop to "Content".
<Content refreshControl={ <RefreshControl ... /> }>
  <List></List>
</Content>

@axsann - thanks, works perfectly!

Thanks @axsann, <View style={{flex: 1}}> works... But I'm still confused why this workaround is even needed in the first place. NativeBase recommends using Content for anatomy but then it breaks....

I think this needs to be added to the docs on how to "Pull to Refresh"

Thanks for sharing @axsann

can someone share code for refreshing?

can someone share code for refreshing?

Below is what I did
`<ScrollView
refreshControl={
<RefreshControl
refreshing={this.state.isRefreshing}
onRefresh={() => {
this.setState({isRefreshing: true}) //You need to set true so the refreshing icon can be displayed
this.fetchFeeds()
this.setState({isRefreshing: false}) //Hide the refreshing icon
}}
/>
}
>

{
<List
dataArray={this.state.newsList}
keyExtractor={(item, index) => 'key'+index}
renderRow={ item => this.renderNews(item)}
        />
      }
    </Content>
  </ScrollView>`

You can see that my List is in a Content which is inside a ScrollView. It is working perfectly.

@ikeliec will try this out. Though, new to RN, so a bit confusing. I basically need to display data from an API. the UI looks like this. bottom part needs to be infinite scroll.


Auto reconnect fails

Is there a way to implement some sort of auto reconnect for the client? I'm finding that the client sometimes loses the connection to the jump server, but the process is still alive when I re connect with another process. It would be awesome if the client would sense that the connection is lost, and re-connect.

Sure. I'm doing a Hack The Box lab, and I've deployed the client to a machine. That machine seems to have a spotty connection, and so the client keeps disconnecting. when I start a new client process, or use ps aux through the command injection vuln that got me in in the first place, it shows the original client processes are still active (/proc/self/exe --foreground <IP>:<PORT>).
If it changes anything, the victim that the client runs on is a docker container, but I dont think that should make a difference.

It doesn't come back at all.
I cant find a version number, but Im pretty sure I downloaded Dec 22 2023
How would I get the logs?

You can find the version by using the version command.
You should try using the latest version just in case. I did make some changes regarding some out and reconnection in 1.0.15

Unless I get some more information/logs on this Im going to close the issue. If you want, feel free to open it again. Or I may open it if I have similar issues :)


Developer Consople CPU consumption

From Matthieu:
"Speaking of the dashboard, it seems to use quite a bit of CPU (40-50% on my machine). Not a big deal, especially at this stage, but Chrome already killed the page a couple times due to freezes."
https://support.neurosity.co/hc/en-us/community/posts/360055931631-First-thoughts-on-Notion-DK1

Here is a screenshot showing the CPU activity reported by Chromium, even with no metric recording.

High CPU was coming from the metric timeline. I've changed the chart to update once a second (in sync with the data from the device, which is streamed once a second), and this reduced CPU usage quite a bit. Less than 10% on my machine where it was previously over 25%.


TensorFlow Keras API not importing properly

System information

Have I written custom code: No
OS Platform and Distribution: Linux Ubuntu 18.0
TensorFlow installed from (source or binary): binary (from pip)
TensorFlow version: I've tried 1.5, 1.10, 1.14 & 2.0 tensorflow and tensorflow-gpu binaries
Python version: 3.6.8
GPU model and memory: GTX 1060 3GB

Describe the current behavior
When I try to import tf.keras or tf.python.keras, I get AttributeError: module 'tensorflow' has no attribute 'keras'. I have tried various versions of tensorflow and tensorflow-gpu installed via pip. Using version 1.14 of tensorflow-gpu, it worked, however none of the submodules were available; I checked using dir(keras) and the module was completely empty.
Describe the expected behavior
It should import fine, I've copied code directly from the official tensorflow keras getting started guides.
Code to reproduce the issue
# works fine
import tensorflow as tf
# none of the following work; they all produce variants of the aforementioned error
from tensorflow.keras import layers
from tensorflow import keras
from tensorflow.python.keras import layers
from tensorflow.python.keras.layers import Dense
from tensorflow.python import keras

Running in a docker container with py3 and tf 1.14.0 everything looks right:
eduardofv@ttmagpie:~$ sudo docker run -it --rm tensorflow/tensorflow:latest-py3

________                               _______________
___  __/__________________________________  ____/__  /________      __
__  /  _  _ \_  __ \_  ___/  __ \_  ___/_  /_   __  /_  __ \_ | /| / /
_  /   /  __/  / / /(__  )/ /_/ /  /   _  __/   _  / / /_/ /_ |/ |/ /
/_/    \___//_/ /_//____/ \____//_/    /_/      /_/  \____/____/|__/

WARNING: You are running this container as root, which can cause new files in
mounted volumes to be created as the root user on your host machine.

To avoid this, run the container by specifying your user's userid:

$ docker run -u $(id -u):$(id -g) args...

root@e29cb559d2b0:/# python
Python 3.6.8 (default, Jan 14 2019, 11:02:34)
[GCC 8.0.1 20180414 (experimental) [trunk revision 259383]] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
>>> tf.__version__
'1.14.0'
>>> from tensorflow import keras
>>> from tensorflow.keras import layers
>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit
>>>
root@e29cb559d2b0:/# uname -a
Linux e29cb559d2b0 4.18.0-21-generic #22~18.04.1-Ubuntu SMP Thu May 16 15:07:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

That's really strange, it's a problem with my Ubuntu/python3/pip3 installation then I guess...
I've looked into it more and for some reason all of my tensorflow installations are totally empty. dir(tf) just has __name__ etc, no actual modules. Before I upgraded to Ubuntu 18.04 from 16.04 TF worked fine, so it must have been a software issue. No idea how this has happened though.
Anyway, I've installed conda for python3 and installed tensorflow-gpu 1.13 with cuda-toolkit 9.0 through that, and it seems to work fine (at least, I can import tf modules!).


-[NSString containsString:] was added in iOS 8

Since ObjectiveSugar doesn't use method prefixes, what would we like to do here?
I suggest renaming ObjectiveSugar's method to containsCaseInsensitiveString:.

How's this?
https://github.com/supermarin/ObjectiveSugar/pull/112


Implement 'scrolloff' option.

From VIM:
                                                *'scrolloff'* *'so'*
'scrolloff' 'so'        number  (default 0)
                        global
                        {not in Vi}
        Minimal number of screen lines to keep above and below the cursor.
        This will make some context visible around where you are working.  If
        you set it to a very large value (999) the cursor line will always be
        in the middle of the window (except at the start or end of the file or
        when long lines wrap).
        For scrolling horizontally see 'sidescrolloff'.
        NOTE: This option is set to 0 when 'compatible' is set.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/5467810-implement-scrolloff-option?utm_campaign=plugin&utm_content=tracker%2F252770&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F252770&utm_medium=issues&utm_source=github).

For anyone who just wants to keep their cursor in the center of screen (scrolloff 10000 in vim).
A workaround like this might be a good solution for now :-)
nnoremap j jzz
nnoremap k kzz
nnoremap o o<ESC>zzi
nnoremap O O<ESC>zzi
inoremap <ESC> <ESC>zz
inoremap <CR> <CR>zz
nnoremap dd ddzz
vnoremap d dzz


Disallow missing key prop in JSX elements that likely require a key prop (react/jsx-key)

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-key.md
This rule caught a ton of instances where I forgot key in bitmidi.com, where I use Preact and the development tools don't seem to warn about this.

Warn if an element that likely requires a key prop--namely, one present in an
array literal or an arrow function expression.
Rule Details
The following patterns are considered warnings:
[<Hello />, <Hello />, <Hello />];

data.map(x => <Hello>{x}</Hello>);

<Hello {...{ key: id, id, caption }} />

In the last example the key is being spread, which is currently possible, but discouraged in favor of the statically provided key.
The following patterns are not considered warnings:
[<Hello key="first" />, <Hello key="second" />, <Hello key="third" />];

data.map((x, i) => <Hello key={i}>{x}</Hello>);

<Hello key={id} {...{ id, caption }} />

Shipping in standard 14.


Update traefik.yaml to pull the latest version of traefik

This will match with the documentation
https://github.com/mspnp/aks-secure-baseline/blob/main/08-secret-management-and-ingress-controller.md

Wow, good catch.  @magrande, can you confirm that you missed that file when doing the Traefik update?
@scaswell-hirez, you'll need to sign the CLA if you would like this contribution committed.

@scaswell-hirez -- can you rebase your branch?  This change that you proposed for the Traefik version has already been made.  The other comment though didn't.  Maybe you can rebase and reopen the PR with the updated title/description to match.  Thanks.

Thanks for the rebase.  If you want to update the title and description now to match the contents of this PR, that would be helpful.

I merged in the latest changes before seeing your rebase request.  If a rebase is still needed I'll close this one and open a new PR for the comment change.


LDAPs?

Hi. This works well with haproxy; thank you. I needed to amend the unauthorized backend a bit to make it work but it is good.
Haproxy is in our DMZ so I would like to use LDAPs against our directory - but I can't figure how to form the ldap url or port to use ldaps, perhaps it isn't supported?
Thanks
Andy

Hello @frankerooney , if your ldap server is configured with TLS you can simply provide the ldaps:// schema in the LDAP URL provided as an argument to the agent and it should work. If it does not please report the problem here.


Support for Messenger Platform 1.1 features

Coverage decreased (-25.6%) to 74.39% when pulling 5bc3b895d57bae03db3e76f7a3de6d94c82f2ae5 on eXeDK:master into 1ac973abb2adff88e5a38c3cf94b41375f4a1db9 on remixz:master.

@remixz Can you merge this pleaes?

please merge @remixz

Please merge @remixz

Please Merge

Would be useful to add: https://developers.facebook.com/docs/messenger-platform/thread-settings/greeting-text
To show an initial greeting :smile:

Coverage decreased (-25.6%) to 74.39% when pulling 5bc3b89 on eXeDK:master into 1ac973a on remixz:master.

Why are there no tests included? I think it is quite important to add some tests, before this will be merged.

Bump

@eXeDK Hey! Thanks for your contribution 😄, sorry I'm so late. I'll agree with @iMicknl that tests should be included for 100% coverage, plus we'd probably want documentation as well. However, I'm gonna add you as a contributor to this repo now, since you've been super helpful in other issues, which I really appreciate. If you want to merge this just to get things started, and work on tests later, go for it. I'll make sure to keep an eye on things, and do a release once everything's good.

It should be if ... else if ... else instead of a whole bunch of if's. It's a waste of execution time to keep checking falsy conditions, since calbacks types are muatually exclusive. For better performance use switch (Writting Efficient Javascript).
Plus, I would handle unknown events:
if (event.oneCallbackType) {
    ... handle it ...
} else if (event.othercallbackType) {
    ... handle it ...
} else if {    // as many as needed
    ... handle these too ...
} else {
    console.error('Webhook received an unknown messaging event: ', JSON.stringify(event))
}

Coverage decreased (-7.5%) to 92.473% when pulling f36ecca85cec2f70379a3abb67ad334f130e4705 on eXeDK:master into 1ac973abb2adff88e5a38c3cf94b41375f4a1db9 on remixz:master.

I went ahead and finished this PR with full test coverage and documentation. Thank you for your hard work on this! Released as 2.4.0.


Overlapping divs on slideToggle

My subheader can be collapsed / expanded and works with jQuery's slideToggle function:
$('#toggle-subhead').click(function() {
        $('.subhead-collapsed').slideToggle();
        $('.subhead-expanded').slideToggle();
});

The collapsed version uses Slick, but the div containers are overlapping until the first slide:

Did you figure out a solution yet?
Same problem here when using materialize collapsible.

Hey, I'm going to close this because there's no test case, per the contributing guidelines, but it seems like an interesting issue so if you want to whip it up in a fiddle, might be able to take a look.

Hey, sorry, nearly forgot about this issue. Here's the fiddle: https://jsfiddle.net/4rrmz07b/

Cool. I added the setPosition method which looks like it caught the positioning up.
fiddle

Thanks. That solves it.

Solved it on desktop, yes, but mobile still behaves weird.


NTR: ER-plasma membrane adaptor  activity

Please provide as much information as you can:

Suggested term label:

Endoplasmic Reticulum-plasma membrane adaptor

Definition (free text)

Reference, in format PMID:#######

PMID:23041194
PMID:39239853

Gene product name and ID to be annotated to this term

VAP family proteins like
https://www.pombase.org/gene/SPBC16G5.05c

Parent term(s)
GO:0043495    JSON
protein-membrane adaptor activity

Synonyms (please specify, EXACT, BROAD, NARROW or RELATED)

Any other information

The ER transmembrane VAMP-associated proteins (VAPs) Scs2 and Scs22 are integral to ER-PM connections (D. Zhang et al., 2012). Cells lacking VAPs have many fewer physical links between the ER and the PM resulting in defects in cellular trafficking, lipid homeostasis and cell division site positioning (D. Zhang et al., 2012; D. Zhang & See, 2022).
PMID:23041194
At the time I annotated these to
GO:0061817
endoplasmic reticulum-plasma membrane tethering

+[Term]
+id: GO:0160214
+name: endoplasmic reticulum-plasma membrane adaptor activity
+namespace: molecular_function
+def: "The binding activity of a molecule that brings together a plasma membrane with an endoplasmic reticulum membrane, via membrane lipid binding, to establish membrane contact sites and mediate exchange and communication." [PMID:23041194, PMID:39239853]
+is_a: GO:0043495 ! protein-membrane adaptor activity
+property_value: term_tracker_item "https://github.com/geneontology/go-ontology/issues/28899" xsd:anyURI
+created_by: rynl
+creation_date: 2024-09-12T20:22:40Z


OUTPUT_DIRECTORY and linking against a corrosion-produced library

I was using corrosion (a fairly recent version) in a subproject to build a thin wrapper around the oxipng API, and was then trying to dynamically link my main c++ project against it. I was trying to do it this way vs statically linking because my main app and test executables are pretty small, whereas oxipng is pretty large. I set LIBRARY_OUTPUT_DIRECTORY to ${CMAKE_BINARY_DIR}/lib which caused the library to be put in the correct place but produced the make error No rule to make target 'vendor/oxipng/oxipng_encoder.dylib', needed by 'app'. Stop. (despite the dylib now being in lib/)
I created a minimal replication here: https://github.com/corrosion-rs/corrosion/compare/master...mnutt:corrosion:output-directory-linking
which just creates a consumer executable and links the corrosion-produced library. It produces the error:
[ 50%] Building CXX object CMakeFiles/consumer.dir/consumer.cpp.o
gmake[2]: *** No rule to make target 'librust_lib.a', needed by 'consumer'.  Stop.
gmake[1]: *** [CMakeFiles/Makefile2:374: CMakeFiles/consumer.dir/all] Error 2
gmake: *** [Makefile:91: all] Error 2
CMake Error at ./corrosion/test/ConfigureAndBuild.cmake:103 (message):
  Build step failed.  Exit code: `2`

I tried with ninja just to see what would happen and got a very similar error. I observed it on both mac/clang and linux/gcc. Apologies if I'm just using it incorrectly or if what I'm trying to do shouldn't be possible, but I'm guessing the dependency resolution step is somehow happening prior to the output_directory move? FWIW the workaround I eventually used was to statically link the corrosion-produced target against an intermediate SHARED target (along with some -force_load/--whole-archive stuff) and link that to my main app, which worked ok.

Thanks for reporting this and providing a test case!
It looks like the code responsible for setting IMPORTED_LOCATION needs to be tweaked. It needs to set the imported location for the <target_name>-static and -shared CMake targets, but as a side effect also looks for the OUTPUT_DIRECTORY properties on these targets instead of the main target_name target.


Added setdiff1d using stl interface

Thanks for implementing this!
Last change is doc only, all builds were fine before, no need to wait.


TypeScript Example

Hello, thanks for this beautiful library. I'm facing type errors while preparing the routes. Can you add some TypeScript examples with nested routes, parameterized routes, and preload? Maybe I'm declaring the things wrong.
// routes.ts

import { RoutesConfig } from 'yarr';
import { loadQuery } from 'react-relay';

import environment from './relay/environment';
import TasksQueryGraphql from './routes/Tasks/__generated__/TasksQuery.graphql';

const routes: RoutesConfig = [
 {
   path: '/tasks/:companySlug/:slug',
   component: async () => {
     const module = await import('./routes/Tasks/Tasks');
     return module.Tasks;
   },
   preload: ({ companySlug, slug }) => ({
     query: loadQuery(environment, TasksQueryGraphql, { companySlug, slug }),
   }),
 },
];

export default routes;

// Tasks.tsx

import { PreparedRouteEntryProps } from 'yarr';
import { graphql, PreloadedQuery, usePreloadedQuery } from 'react-relay';

import { TasksQuery } from './__generated__/TasksQuery.graphql';

interface TasksProps extends PreparedRouteEntryProps {
  query: PreloadedQuery<TasksQuery>;
}

export function Tasks({ query }: TasksProps): JSX.Element {
  const { task } = usePreloadedQuery(
    graphql`
      query TasksQuery($companySlug: String!, $slug: String!) {
        task(companySlug: $companySlug, slug: $slug) {
          title
        }
      }
    `,
    query,
  );

  if (!task) {
    return Task not found;
  }

  return {task.title};
}

Everything works as expected, only problem is about type errors. When I run tsc --noEmit, it gives the following;
src/routes.ts:10:5 - error TS2322: Type '() => Promise<({ query }: TasksProps) => JSX.Element>' is not assignable to type '() => Promise<ComponentType<{ params: {}; search: {}; }>>'.
  Type 'Promise<({ query }: TasksProps) => Element>' is not assignable to type 'Promise<ComponentType<{ params: {}; search: {}; }>>'.
    Type '({ query }: TasksProps) => Element' is not assignable to type 'ComponentType<{ params: {}; search: {}; }>'.
      Type '({ query }: TasksProps) => Element' is not assignable to type 'FunctionComponent<{ params: {}; search: {}; }>'.
        Types of parameters '__0' and 'props' are incompatible.
          Property 'query' is missing in type 'PropsWithChildren<{ params: {}; search: {}; }>' but required in type 'TasksProps'.

10     component: async () => {
       ~~~~~~~~~

  src/routes/Tasks/Tasks.tsx:7:3
    7   query: PreloadedQuery<TasksQuery>;
        ~~~~~
    'query' is declared here.
  node_modules/yarr/dist/esm/types.d.ts:64:5
    64     component: () => Promise<ComponentType<Props>>;
           ~~~~~~~~~
    The expected type comes from property 'component' which is declared here on type 'RouteConfig<string, string, { params: {}; search: {}; }, boolean>'

src/routes.ts:14:17 - error TS2339: Property 'companySlug' does not exist on type 'RouteParameters<string>'.

14     preload: ({ companySlug, slug }) => ({
                   ~~~~~~~~~~~

src/routes.ts:14:30 - error TS2339: Property 'slug' does not exist on type 'RouteParameters<string>'.

14     preload: ({ companySlug, slug }) => ({
                                ~~~~

Can you help on this?

The value type of the UnassistedPreloadData type in types.ts has unknown. I temporarily declared PreloadQueryRouteProps type that has preloaded: any property to forcibly cast the type. To solve this fundamentally, I think it is better to change to type UnassistedPreloadData = Record<string, any> in the library code.
import { loadQuery } from "react-relay";
import { RouteConfig, RouteParameters, RouteProps, RoutesConfig } from "yarr";

export interface PreloadQueryRouteProps extends RouteProps<string> {
  preloaded: any;
}

export const routes = (<RouteConfig<string, string, PreloadQueryRouteProps>[]>[
  {
    path: '/tasks/:companySlug/:slug',
    component: async () => {
      const module = await import('./routes/Tasks/Tasks');
      return module.Tasks;
    },
    preload: ({companySlug, slug}: RouteParameters<'/tasks/:companySlug/:slug'>) => ({
      query: loadQuery(environment, TasksQueryGraphql, { companySlug, slug }),
    }),
  },
]) as unknown as RoutesConfig;

Thanks for reaching out. Typing of the routes config is something that is on our list to improve and get working fully since our v1 to v2 rewrite.
Essentially what this looks like in the future will be to add back in utility functions for creating strongly typed routes, and combining routes into a strongly typed route config.
Additionally this will allow us to bring back support for typed to function (and useRoutes) that could automatically give you route helpers that map directly to your config (which is something we had in v1).
ie
<Link to={(routes) => routes.profile({ id: 'erictaylor' })}>To my profile</Link>


Mein Hähnchenfilet-Rezept

Leckeres Hähnchenfilet

Thanks for the PR @JuCaHeWi, I am looking forward to your contribution.
It looks like you used the template file but it does not contain your recipe, yet.
Could you update the PR with your recipe by adding and committing more changes to the same branch in your forked repository and pushing them to GitHub? This should update this PR.
Thanks!

Thanks @JuCaHeWi for the update.
I have a few requests for further improvement:

[ ] Could you please structure the recipe like the other recipes?

You can find a template here or view one of the existing recipes here.
Specifically, could you please update the YAML header of the Quarto file? Thank you!

Thanks for the additional changes @JuCaHeWi! Ready to merge! 🚀

@allcontributors please add @JuCaHeWi for bug, content, code


Go through all MySQL passwordless migration guide/quickstart/tutorial to make sure by following them can work

Since most of the passwordless docs are ready, we should follow instructions of each doc to make sure all of them can work correctly. The docs included:

[x] #30346
PR: https://github.com/MicrosoftDocs/azure-docs-pr/pull/208242
[x] #30340
PR: https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3434
[x] #29783
PR: https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3419
[ ] #29224
PR: https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3423
[x] #29221
PR: https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3463

close in:

https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3653
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3639
https://github.com/MicrosoftDocs/azure-docs-pr/pull/212473
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3630
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3617
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3607
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3594
https://github.com/MicrosoftDocs/azure-docs-pr/pull/211129
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3564
https://github.com/hui1110/azure-dev-docs-pr/pull/14
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3553
https://github.com/MicrosoftDocs/azure-dev-docs-pr/pull/3548


Draft: Manually parse JSON input

It looks like the driver is not setting reasonable content-type headers for requests to external solvers. This leads to issues with fastapi which doesn't "parse" (not sure if this is the correct term) the JSON body into the BatchAuctionModel class.
To work around this, manually parse the JSON into a batch auction model.
This PR is currently a draft as I'm exploring other options to make this work.

Hey @nlordell - I think this recent PR bumping the version of fastapi may be the cause of issue here:
https://github.com/cowprotocol/solver-template-py/pull/7
I wonder if this is a bug on the fastapi side or if we should maybe roll back the package update. I may try and look a little closer at the "breaking changes" (although I wouldn't expect such breakage on a minor version bump).

I wouldn't expect such breakage on a minor version bump

Note that in SemVer versioning standard, breaking changes are allowed from 0.x to 0.y (this isn't considered a minor version bump because of the 0. major version):

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Whatever you want to call it, it shouldn't have broken this, but it did.

You mean anything starting with 0. Can just be broken any time?

Yes.

edit: I tried configuring the route parameters so that it accepts bodies without application/json content type, but AFAICT is not possible.
I also found where the issue was introduced:
https://github.com/tiangolo/fastapi/commit/fa7e3c996edf2d5482fff8f9d890ac2390dede4d
Note that it has since been fixed here:
https://github.com/tiangolo/fastapi/commit/edf6b2d61ff2645d8fcde30e60421ee9d8f2a4be
This means that this PR shouldn't be needed if we upgrade the fastapi version.
Regarding:

I think this recent PR bumping the version of fastapi may be the cause of issue here:

We probably need to setup sufficient CI in order to validate that this continues to work as requirement versions get bumped. Also, have you considered using a different library (Flask comes to mind) that has a slightly more stable API?

Also created this PR in the services repo which would make this no longer necessary: https://github.com/cowprotocol/services/pull/201


Error on phosh: Embedder did not return a valid render target.

Describe the bug
When launching app normally, it can't render:
** (localsend_app:12829): CRITICAL **: 17:41:02.543: Failed to determine valid GL format for Flutter rendering
[ERROR:flutter/shell/platform/embedder/embedder.cc(780)] Could not wrap embedder supplied frame-buffer.
[ERROR:flutter/shell/platform/embedder/embedder.cc(1161)] Could not create a surface from an embedder provided render target.
[ERROR:flutter/shell/platform/embedder/embedder_external_view_embedder.cc(180)] Embedder did not return a valid render target.

To reproduce

Install LocalSend
Open it

Expected behavior
App launches normally
Screenshots
What happens when app launches with .desktop file or via localsend_app or flatpak run org.localsend.localsend_app:

However, when I launched it from GNOME Software:

It launches normally:

Desktop (please complete the following information)

OS: Droidian, wayland only, phosh as DE (mobile Debian on Xiaomi Redmi Note 9S)

Smartphone (please complete the following information)
N/A
Additional context
It really bothers me that I can't replicate what GNOME Software does differently.
Tried versions 1.14.0 from flathub, and 1.14.0, 1.13.0 from Github deb releases
Logs from stdout:
out.txt
stderr:
out2.txt

Removing the library libgtk6216workaround.so from LD_PRELOAD while launching localsend or any flutter app will fix the problem in phosh droidian


Async functions can't return Void type

My code:
  @async private function myAsyncFuncReturningVoid(): Void {
    // do something
    // line 244 is here
  }

  @async private function test() {
      @await this.myAsyncFuncReturningVoid(); // line 264 is here
  }

Compiler output:
ex.hx:244: characters 5-38 : Dynamic should be Void
ex.hx:244: characters 5-38 : Dynamic should be Void
ex.hx:264: characters 14-33 : Void should be hxasync.Awaitable<Void>
ex.hx:264: characters 14-33 : ... For function argument 'arg'

This is a known limitation of Haxe, which I did not find a way to workaround.
I will not close the issue, but you should not expect a fix anytime soon :)


Sync HttpClient->sendRequest() create alot of process/thread and do not close after finished

You guys can see htop tab bellow

The source code:
                auto ev = std::make_shared<trantor::EventLoopThread>();
                LOG_INFO << ev->getLoop() << 1;
                ev->run();
                auto cli = drogon::HttpClient::newHttpClient("http://google.com", ev->getLoop());
                auto r = drogon::HttpRequest::newHttpRequest();
                cli->sendRequest(
                    r, [ev](auto a, auto b)
                    {
                        LOG_INFO << ev->getLoop() << 2.5;
                    },
                    20);
                LOG_INFO << ev->getLoop() << 2.6;

@HadesD Thanks for the report. In your code. You wrote auto ev = std::make_shared<trantor::EventLoopThread>(); to spawn new threads. Thus a lot of the threads are created. But you also  You can use the main thread provided by drogon to avoid this issue. Or create a EventLoopTHread (or EventLoopThreadPool if you need an array of them).
auto cli = drogon::HttpClient::newHttpClient("http://google.com", app().getLoop());
auto r = drogon::HttpRequest::newHttpRequest();
cli->sendRequest(
    r, [ev](auto a, auto b)
    {
        LOG_INFO << ev->getLoop() << 2.5;
    },
    20);
LOG_INFO << ev->getLoop() << 2.6;

We recommend to use coroutines if you can use C++20 in your project. (Visual Studio 2019/2022 or GCC >= 11).
auto cli = drogon::HttpClient::newHttpClient("http://google.com", app().getLoop());
auto r = drogon::HttpRequest::newHttpRequest();
auto client_resp co_await = cli->sendRequestCoro(r, 20);

Furthermore we recommend reusing the client so it can take advantage of HTTP keepalive.

The internal dns resolver will also create some threads.

@HadesD Thanks for the report. In your code. You wrote auto ev = std::make_shared<trantor::EventLoopThread>(); to spawn new threads. Thus a lot of the threads are created. You can use the main thread provided by drogon to avoid this issue. Or create a EventLoopTHread (or EventLoopThreadPool if you need an array of them). Also, you are using the async interface instead of the sync one. Causing the client to destruct before requests could be sent back if you didn't manually manage the lifetime.

I 've change to that code, but it still create alot of thread, without clean after completed request

Currently I have to use libcurl and std::thread, and it only spawn 1 thread to do background job, then auto remove then

Would you please make a complete repo of this, so that I can reproduce the issue locally.

May you make a minimal example? It's difficult for us to figure is out just by staring at it.
My best guess is those are worker and DB threads that have been created either via the config file or setThreadNum(). Sometimes the functionality of each thread is showed in htop if htop is configured to read the thread name and the OS supports it.
Screenshot from a production system enables and supports it:

And one from not supported:

@marty1885
Image bellow is thread name of them

all are Dns Queue and do not dis-spawn after requested.
@an-tao
You can see image above, if you still need a source code, I will make it then

Did you install the c-ares library? please run drogon_ctl -v to check that.
the Dns Queue is used in NormalResolver when no lib c-ares was installed, I'll figure it out and fix it.

Did you install the c-ares library? please run drogon_ctl -v to check that.

BTW, did you create a lot of HttpClient?

No, just one HttpClient

the Dns Queue is used in NormalResolver when the lib c-ares was not installed, I'll figure it out and fix it.

I 've install libc-ares-dev (ubuntu) and it fixed the issue
Another question:

Does drogon block new connection when HttpClient use drogon::app().getLoop() and sync ->sendRequest ?

This issue will still open until you have time to fix it. Thanks

Does drogon block new connection (new connection have to wait) when HttpClient use drogon::app().getLoop() and sync ->sendRequest ?

You want to refer to the threading model document for answer, Ignoring the nuisances:
1, The HTTP client's connection won't be blocked (as long as there's nothing else blocking on the main loop).
2. Make sure you are not on the main loop when you called the sync sendRequest. Otherwise it'll deadlock
3. The code you show is in fact async, It has non of the problem above.<-- Important
4. We recommend using coroutines whenever possible. In production, I've been using GCC11 on Ubuntu 20.04/Debian 11

@HadesD We did some investigation. NormalResolver is intended to create that amount of threads to handle sudden, large bursts of name lookups. NormalResolver internally uses getaddrinfo (which is available on all OSs, but is a blocking function) to retrieve address. And the DNS threads are very lightweight. They shouldn't cause issue whatsoever.
If dependency and performance of resolution is a concern for you. I can add a new resolver using the GNU extension getaddrinfo_a. But I doubt it's any faster than c-ares. The other resolver libraries are just extra dependencies and doesn't provide upsides over c-ares.

@marty1885
ATM, I'm using c-ares, so it is not problem anymore, but I think it better if we can implement the way that make framework faster.

I'm closing this issue since large amount of resolver threads are expected when using the system resolver. And we intend that to happen. Feel free to reopen if anyone thinks actions could be taken.


CLI 8.3.0 printing Received event args [object Object] on amplify push

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

How did you install the Amplify CLI?
pnpm
If applicable, what version of Node.js are you using?
v16.14.2
Amplify CLI Version
8.3.0
What operating system are you using?
mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
no
Amplify Categories
Not applicable
Amplify Commands
push
Describe the bug
running amplify push produces unexpected messaging Received event args [object Object]
Expected behavior
no unexpected messaging
Reproduction steps

run amplify push in a project

GraphQL schema(s)

# Put schemas below this line

Log output

# Put your logs below this line

Additional information
No response

Closing as this is no longer a valid bug.


[Vis Builder] Updates tests to visBuilder key

Signed-off-by: Ashwin Pc<EMAIL_ADDRESS>Description
The existing VisBuilder tests use the wizard key that has now been updated to visBuilder. This Pr updates the keys and the tests associated.
Screen recordings
https://user-images.githubusercontent.com/20453492/199457058-330d997d-f5a5-4db8-96c0-c54d61a16fd4.mp4
https://user-images.githubusercontent.com/20453492/199457295-eb3545d0-a196-4c6b-8c96-f0d0938b62c0.mp4
https://user-images.githubusercontent.com/20453492/199457310-d054d1ea-488a-4103-80c0-18921245f56e.mp4
Vis Types
https://user-images.githubusercontent.com/20453492/199457372-a8f0fa99-db14-4db3-9754-e382cd61ed1f.mp4
https://user-images.githubusercontent.com/20453492/199457384-6a872e5b-49c3-4b03-b15c-6bb99166bfdf.mp4
https://user-images.githubusercontent.com/20453492/199457394-6e48c43d-dba2-45f1-8aa8-189b0e357c1d.mp4
https://user-images.githubusercontent.com/20453492/199457406-1ec234a0-9978-4694-9506-0053bcaa2bc1.mp4

Issues Resolved
related to https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1706
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

The OSD build seems to be failing due to other issues. Can we merge this in given the screenshots attached and I can fix any followup issues in a followup PR

Currently it has label for 2.x backport. Does it need 2.4 backport as well since we already have 2.4 branch?

The OSD build seems to be failing due to other issues. Can we merge this in given the screenshots attached and I can fix any followup issues in a followup PR

Sure

Currently it has label for 2.x backport. Does it need 2.4 backport as well since we already have 2.4 branch?

Yes it does! thank you!

I will manually take it to 2.x and try to backport to 2.4 from there.


Actions

Removes a large directory to allow intel dockerfile to run

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 94.66%. Comparing base (0c23465) to head (00e2f29).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #427   +/-   ##
=======================================
  Coverage   94.66%   94.66%
=======================================
  Files          38       38
  Lines        3057     3057
=======================================
  Hits         2894     2894
  Misses        163      163

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


feat: Add a bigger (perhaps customized) value to 'per page'

I have a lot of jobs inside a queue, and sometimes i need to investigate an error or retry more than 75 itens.
My suggestion is to add a bigger value (like mysql uses 500), or a input field to enter a custom amount of itens per page

@saade i added more "per page" options(up to 500) in 1.2.0. performance will be poor though


Memory usage bugfix

MEMORY USAGE BUGFIX
Fixed issue where too many dates were kept in memory. Now only unique dates are kept in memory.
Small style updates.
Bumped from version 7.0.3 => 7.0.4 PATCH for bugfix

Good stuff indeed :)


Add additional files to the chefignore file

Ignore more commonly included files that shouldn't be stored on the server

LGTM :+1:

:+1:


github token printed in verbose mode

Describe the bug
When printing out configuration via verbose mode it prints out the github token. If you're attempting to debug an issue on public CI this'll expose credentials to the public.
To Reproduce
Run auto shipit --very-verbose
Expected behavior
The github token should be sanitized or removed.

Screenshots

(this token was invalidated)

Is that with these changes? https://github.com/intuit/auto-release/pull/130?
I'm thinking it's probably this line where it gets printed https://github.com/intuit/auto-release/blob/master/src/github-release.ts#L169
I can make a PR for this tomorrow it'll just be copying the code for now. I am working on a slight rewrite that will get rid of the branching in the constructor https://github.com/intuit/auto-release/pull/131/files#diff-50f0d7708b5c1cb25e0811ab4004421fR134.
Sorry for the leaked key!

Yep, this is a dupe of #130


chore: add jx-cli chart

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign rawlingsj
You can assign the PR to them by writing /assign @rawlingsj in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: rawlingsj
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [rawlingsj]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

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

Test name
Commit
Details
Rerun command

gsm
05640cdcbd985dc06f8284efe7458ed14bef7775
link
/test gsm

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

/test gsm


BIP39 support

Implements BIP39 (Mnemonic code for generating deterministic keys).
I have added a dependency to lazy_static in order to load the wordlist into a constant. I am sure someone more experienced in rust can figure a way to avoid it if necessary.

Is this redundant with https://github.com/rust-bitcoin/rust-wallet/blob/master/src/mnemonic.rs ?

@mcdallas The rust-bitcoin library is about consensus relevant stuff, mostly serialization. Please see the rust-wallet project. I think it covers this.

@tamasblummer ok, closing.


React Native 0.60 Support for Android X

Issue Description
React Native 0.60 support for Android X
Steps to Reproduce / Code Snippets / Screenshots
Feature Request

Environment

React Native Navigation version: 2.x
React Native version: 0.60
Platform(s) (iOS, Android, or both?): Android
Device info (Simulator/Device? OS version? Debug/Release?): NA

I have successfully integrated the library on RN 0.60 for Android X using Jetifier https://github.com/mikehardy/jetifier
you need to manually replaced the library with androidX ones first:
https://itnext.io/react-native-how-to-handle-an-app-with-both-pre-androidx-and-androidx-dependencies-rn60-bf4df7ea0dd2
one key step is change all rncamerakit to react-native-camera-kit in your settings.gradle and app/build.gradle as follows:
change
include ':rncamerakit'
project(':rncamerakit').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-camera-kit/android/')

into
include ':react-native-camera-kit'
project(':react-native-camera-kit').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-camera-kit/android/')

and
change
compile project(":rncamerakit")
into
implementation project(':react-native-camera-kit')
also under buildscript in build.gradle, I change the version to 3.3.2
dependencies {
        // classpath 'com.android.tools.build:gradle:3.4.1'
        classpath 'com.android.tools.build:gradle:3.3.2'
 }

Thanks @lawrencehui

@lawrencehui
would you be helpful enough to create a guide replacing the library with androidX until the library is fixed to support anroidX. because some of us doesn't know much about android specifics.


Darken-blur background not working on exported versions

The darkening-blur background is not working on the exported version for some reason (works from editor):

Shader parameters appear to not be set on export releases, not sure if this is a bug on the engine.

This is actually happening globally on any exported variable, as default values on theme nodes are not used. This should be investigated better, as it definitely is a Godot bug.

#377 and #376 will be merged soon, and it seems to be related to this. This should be tested to check if it remains an issue then.

Sadly these new PRs haven't fixed it either (#379). Definitely needs to be investigated for what's going on.


Allow nix to compile on android

Fixes #313

So there's another symbol that's apparently missing from android : __errno_location. Instead, it stores it in tread local storage, and has a function to retrieve a pointer to it called __errno : https://github.com/LineageOS/android_bionic/blob/cm-14.1/libc/bionic/__errno.cpp
errno is simply defined as dereferencing the symbol there : https://github.com/LineageOS/android_bionic/blob/cm-14.1/libc/include/errno.h#L44
When we try to compile something for android, we get a linker error saying that __errno_location is undefined.
Now, because the bionic __errno is defined as volatile in bionic, I don't know if it's a good idea to simply make __errno_location return it ? I'm pretty illiterate when it comes to what volatile does.

More problems, this time for the target aarch64-linux-android. For some reason, libc::SO_PASSCRED, libc::SO_PEERCRED, libc::SO_SNDBUFFORCE are not defined on android in libc (in addition to being undefined on linux arm). I believe this is a bug, so I'm pushing it upstream. In the meantime, I'll also #cfg them out.
https://github.com/nix-rust/nix/blob/master/src/sys/socket/consts.rs#L43 is marked as not(target_arch="arm").

It should now be possible to compile binaries using nix for both arm-linux-androideabi and aarch64-linux-android.
Should I document every #[cfg(not(target_os = "android"))] ? I'm not too sure what I'm supposed to put in there :/.

@roblabla There are basically two categories of things here you're asking about, one is things that currently fail when testing on Android that shouldn't and things that shouldn't be tested on Android. I'd prefer to wait until upstream is fixed so that we only have cases of the latter. Those don't need to be documented. If we have things that can't currently be tested because they're blocking on upstream, those need to be documented. But like I said, I'd rather wait until upstream is fixed to merge this PR so that we only have "good" fixes here.

The only change that'll ever be fixed by libc is the use of 'as' in the bitflags though, along with missing symbols.
I'll try digging what symbols are missing in libc compared to the most recent version of android, so we have a clearer picture of the situation.
On June 29, 2017 6:29:12 AM GMT+02:00, Susurrus<EMAIL_ADDRESS>wrote:

@roblabla There are basically two categories of things here you're
asking about, one is things that currently fail when testing on Android
that shouldn't and things that shouldn't be tested on Android. I'd
prefer to wait until upstream is fixed so that we only have cases of
the latter. Those don't need to be documented. If we have things that
can't currently be tested because they're blocking on upstream, those
need to be documented. But like I said, I'd rather wait until upstream
is fixed to merge this PR so that we only have "good" fixes here.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/nix-rust/nix/pull/631#issuecomment-311859521

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Yes, well libc isn't going to add symbols that don't exist on Android. For things that don't exist on Android, cfg-ing them out of tests and builds is correct and doesn't need explicit documentation.

Linking https://github.com/rust-lang/libc/issues/632 since it seems to contain some items of interest.

@roblabla We now have all android targets being built in CI, so if you rebase this you can see how well things will compile on those targets. Probably not worth doing so until rust-lang/libc#632 settles down, however.

@roblabla  rust-lang/libc#632 is fixed, we could remove some of the #cfg[] in the first commit now :)

With https://github.com/rust-lang/libc/pull/634 now merged, most of the constants are now defined. The only ones left are :

SO_PASSCRED
SO_PEERCRED
SO_SNDBUFFORCE

They should be defined though, as a quick grep -R reveals they are in the unified headers, under asm-generic. Time for a second libc PR I guess

@roblabla I added those constants in rust-lang/libc#639 already as I saw they were needed for Android and I was already adding socket constants as part of #636.

So give this thing a rebase and remove some of those cfgs and we'll see what happens!

https://github.com/rust-lang/libc/pull/642 is necessary now

I'd also like to move Android builds to Tier 2 as part of this. Could you modify the README and also .travis.yml to do that as well?

Should be fine now

Could you better document your changes to the libc_bitflags macro? munch an ident isn't very helpful to someone who doesn't use the macro system in Rust. It'd be better if you described exactly what it allowed, especially if you added an example use-case. The module comment at the top could use some additions for the two use cases you added as well.
I'd also prefer your changes to macros.rs be removed into a separate commit before the others if you're comfortable with git rebase, otherwise it's not a big deal.

Is this better ?

Right, so this change caused the build to fail on arm because libc doesn't define those flags on arm. https://github.com/rust-lang/libc/pull/644 will fix this failure.
 Which is surprising because there isn't much in the arch-specific files of libc (https://github.com/rust-lang/libc/blob/master/src/unix/notbsd/android/b32/arm.rs). I'll investigate.

The failures on Android 64 bits are due because the test case is using rustc 1.13 which has no support at all for x86_64-linux-android and for which std was broken for i686-linux-android (see fix), this fix was introduced in version 1.18 of rust.
So the explanation was that std::os::raw::c_char returned from CStr::as_ptr is different than libc::c_char for older stdlib.
I think x86_64-linux-android is not considered stable yet, libc still use the beta channel for testing it.
We should consider using at least rustc 1.18 for testing i686-linux-android.
I could also advise you to test (at least the build phase) locally on your machine with the latest rustc for the different targets. You won't have to commit just to test and you'd have seen that difference.

Ah I see. So I bumped the minimum version to 1.18 for i686/x86_64. I also updated the libc PR to also define MAP_32BIT on x86/x86_64 android targets.
I think this should be everything necessary.

@roblabla Love the separate macro commit, thanks for that.
This is pretty close to being mergeable:

The requirement for Rust 1.18 for the x86 Android targets needs to be documented. I suggest adding it to the README like (requires Rust >= 1.18) to the end of the lines stating they have Tier 2 support.
We need some CHANGELOG entries. Under Changed add that Android is now a Tier 2 target and under Fixed bind and errno_location now work correctly on Android.

Please add those CHANGELOG entries in with the corresponding commits.
If you're feeling particularly diligent, you could also reorder the 2 last commits. I like to have commits ordered such that building things will always succeed. This means fixing the errors and then requiring builds to pass for the fixed target.

@Susurrus actually, the commits are in the right order. Github interface is just confused, probably because of all the rebase and push --force ? https://github.com/roblabla/nix/commits/feature-androidWorks

Done.

LGTM, thanks for all your hard work!
bors r+


Error in console

Hello. Thanks for your work ;)
I have this error in my project and exists in your demo too:
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'report-sample' 'nonce-7hAmZwC6wdd7wq1Q9QLt7g' 'unsafe-inline' 'strict-dynamic' https: http: 'unsafe-eval'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.
gview:9 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'report-sample' 'nonce-7hAmZwC6wdd7wq1Q9QLt7g' 'unsafe-inline' 'strict-dynamic' https: http: 'unsafe-eval'". Note that 'unsafe-inline' is ignored if either a hash or nonce value is present in the source list.
{
"result": {
"error": {
"code": -1,
"message": "A network error occurred, and the request could not be completed."
}
},
"body": "{"error":{"code":-1,"message":"A network error occurred, and the request could not be completed."}}",
"headers": {},
"status": null,
"statusText": null
}
For example, try with:  https://www.africau.edu/images/default/sample.pdf

Hi @leocharrua I'm going to clean up older issues so I'm closing it, I'm sorry for not responding I was too busy with other projects. I'm not sure what causes this I looks like some error from the google viewer. If you still having troubles here I'll can have a closer look if I have time. In that case I'll reopen the issue.

Hello @Marcelh1983, the issue still exists.

Hi @Marcelh1983 , I am also facing this issue.


Restyle 'add' button in top menu bar

Users cannot identify the (+) symbol as a button to add new tasks or supplies. More so, it sometimes get squished by the browser in the layout.
We need to replace it with a more intuitive control to add new items to the system.

Instead of

we should go for a better approach:

Have a square button with the word '+  New...'
Have a drop down menu with radio button which items to add (Task or Supply)
Have an action button with 'Create...' or 'Cancel'

@anvarik Maybe following on the success of the user restyling, you want to look at this challenge? Bit more involved but not much more than the user name nenu we already have...thoughts?

I think it is better ti just havea drop dien menu like under the username and not have check boxes and a create/ca cel buttons. Let's keep it simple...

Hmmmm, re-reading it, this is what is left for mvp1. I guess I had bigger plans at some point, but for now it would be:

in the top bar offer a nicely styled square orange button saying [(+) New...]    so a plus icon (little smaller and the text 'New...'
then this simply drops down the menu as is today...

I don't have too much styling mojo right now, but we need to make it more intuitive for users to find the 'add'.

@kristysnet : Here is a screenshots of the button in IE11:

Note it is on the right side of the leftnav divider line and also doesn't scale to the text there...sorry if this is fiddly but we need it to be properly scalable...can you take a look?

@kristysnet / @phil-monroe I was playing around with this new button layout more and have a few thoughts:

The real label should be 'Add', not 'New'. Sadly, this without a dispute translates in German into the ugly 'Hinzufügen' (we can thank Microsoft for the terminology).
If the label gets so long, it overlaps the circle name on the left. We cannot move the button to the right of the line between the left nav and the main area since we show the 'Back to...' message there and plan to use it for the search box. Therefore we could experiment with putting it in the left nav above the first 'My Tasks' item. It could look somewhat like this example:

The style still looks clunky to me and not crisp. How about we try using the word 'Add' first and then the plus icon in a white circle just like in the screenshot.

@dottorer Restyled the add button in branch feature/add_button_rev2. Please have a look and let me know if you want me to make further changes.

Hi Kristy, here is what I see right now:

This has the restyled button, but the location is still the same. I was thinking more along the lines of:

And in this case, we could use the exact same font strength as the leftnav items such as 'My Tasks' (just in white). Can we try this?

Having said that, I am not sure how the drop down menu will look if we place it there as it might overlap the leftnav items in a weird way.
Adding @phillipoertel for thoughts. Boy do we need a UX guy to do the pretty picture for us :-)

@kristysnet : Alternatively and likely easier and quicker for now is the following option:

This would required the following:

do not show add button when we display a single task or supply. This is when we show 'Back to all tasks' in that spot.
do not show when we display the helper list.
only show when we are either on the circle dashboard or on the work group dashboard. This is likely where people will take action and really 'Add' something new.

It is likely not ideal that buttons come and go when navigating, but this might be a good compromise for right now.
Note that we should still improve the font by making it the same as the leftnav fonts (in white) and also ensure that the little plus icon is in a circle, not an oval.
What do you think?

@dottorer sorry about that, i misunderstood before and thought you wanted to try the restyle/text change first before trying to move location. No worries though, I think your latest idea is better for mvp1 anyway. I will implement this this afternoon.

@dottorer feature/add_button_rev2 should now show the add button in the back button area. Also, the font should be the same as the side nav items.


Fees are excessively high sometimes

Context
Sometimes when you want to estimate fees, you can get weird result;

Information
-

Version
2020.8.3 (git revision: b5b292b5a9f0ddccc0fc5d9e98bf3bf80f1a9d13)

Platform
Linux

Installation
From Hydra

Steps to Reproduce

Try to estimate fees when payments + expected_fees_for_this_payments >= payments amount
...
PROFIT!1

Expected behavior
Fees for this transaction even if there is not enough money for it. I just want to know estimated fees for transaction like this. It works well for migrations, but there is a problem https://github.com/input-output-hk/cardano-wallet/issues/2061, so I can't use migrations instead.
Actual behavior
Your fees are about 1.8446744062438E+19

Comment
Yep, I can handle it by myself with some nasty solutions, and I will, but would be nice if I have not to do this.

Looks like a proper under/over flow in the fee estimation.

I've been able to reproduce with an integration test scenario by trying to estimate fee for a wallet using the total balance (available UTxO + rewards). This indeed reaches an edge case of the fee estimation where fees are too big and some extra computation is done to calculate the estimated amount.

QA

Added an extra integration test scenario illustrating the problem (fee calculation fallback with withdrawal) (https://github.com/input-output-hk/cardano-wallet/commit/f6e74dca19d77b05a3d3b1838badc538b7d00e93)

Also added an invariant in-code to make sure that this does not happen by accident. The invariant checks that fee are within an acceptable bound and crashes the server otherwise.

lgtm.


[ERROR] Failed to execute 'appendBuffer' on 'SourceBuffer': The SourceBuffer is full, and cannot free space to append additional buffers.

Web App
You can remove this section if your issue isn't related to the Web App
System Details

Operating System: Windows
Web Browser name and version: Chrome & Firefox, both an latest versions

Plex Media Server details

Version: <IP_ADDRESS>02
Operating System (Windows/Linux/Mac): Linux
Running in Docker? (Yes/No): No
Location (Local/Remote): Remote
Remote Access Enabled (Yes/No)?: Yes

Plex Client details

Name: Synclounge Web
Version: Synclounge Web  latest version
Network connection (Wired/Wifi): Wifi
Platform: Synclounge Web

Self-Hosting
You can remove this section if your issue isn't related to Self-Hosting
System Details

Operating System: Linux

SyncLounge Details

Running in Docker? (Yes/No): No
Using a Reverse Proxy (Yes/No): Yes
If Yes, which Reverse Proxy (Nginx, Apache, Caddy, etc.): Nginx

Issue information
To Reproduce
Steps to reproduce the behavior:

Set up a room.
Play a video file from a library.
Wait and see error message appear on screen.

Describe your bug/issue
Chrome keeps showing this error Failed to execute 'appendBuffer' on 'SourceBuffer': The SourceBuffer is full, and cannot free space to append additional buffers. on some items being played like a minute in to the video.
Firefox also keeps showing The quota has been exceeded.
Everything works well when watching things through Plex Web, so it's not connection.

Hitting this too. Setting a transcode option to a lower bitrate was a workaround for me.

It’s a known issue with the video player we use. We’re working on a fix but no eta

The issue is not fixed with latest videojs versions, but the developers are aware of it and may fix it in later releases.

I hit this problem quite often as well, and always on media where the plex web player has no problem with it.  Is there a reason that synclounge can't use the same browser video player that plex does?

We have been working on vastly improving the synclounge web player and in a future release, it should be on par with the Plex web player.

Yeah I guess I just don't understand why "the synclounge player" isn't the exact same component as the plex web player so that anything that plays in plex is guaranteed to play properly in synclounge.
Is the plex player really proprietary in a way that isn't reusable?

Plex isn't open source. The Plex player is not distributed under an open source license.

I understand, I just assumed that something as basic as playing a video stream was technology that has been worked out for a long time and was an open source component that everybody used because Netflix, prime video, YouTube, Plex, Facebook, etc are all pretty stable.
Is it really the case that all of those sites use custom closed source components to play streaming video in a browser?

This issue is fixed in #220


Stuck on queued, nothing shows up in the log despite being enabled

Please follow the guide below

You will be asked some questions and requested to provide some information, please read them carefully and answer honestly
Put an x into all the boxes [ ] relevant to your issue (like that [x])
Use Preview tab to see how your issue will actually look like

WARNING
All invalid issues will be rejected!!

Before going further

If your problem is a bug with youtube-dl or a request for new site support please report it here

Make sure you are using the latest yt-dlg version (Click the Settings icon and then About to view the current version)

Make sure you are using the latest youtube-dl version (Click the Settings icon and then Update to update to the latest youtube-dl version)

Make sure you searched the bugtracker for similar issues including closed ones

Make sure to read the FAQs file

[ ] I think my problem is NOT with youtube-dl
[ ] I've verified and i assure that I'm running yt-dlg 1.X.Y
[ ] I assure that i am using the latest version of youtube-dl
[ ] Searched bugtracker
[ ] I've read the FAQs file

What is the purpose of your issue?

[ X ] Bug report
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

Please remove any sections between (---) if they are not related to your issue

Bug report
If the problem occurs when downloading a URL please provide the full verbose output as follows:

Restart yt-dlg
Go to Options > Extra tab
Enable Debug youtube-dl
Go to Options > Advanced tab and Clear your log content
Try to download the URL
Copy the whole log content and insert it between the ``` part below

//this is left intentionally blank, as that is what is in the log
What operating system do you use ?
windows 10
List of actions to perform to reproduce the problem:

have yt-dlg installed for a while
it works perfectly fine for that whole time
change nothing
???
downloads no longer work

What is the expected behaviour ?
videos are downloaded
What happens instead ?
Links are stuck on queued, the process cannot be stopped, and the only way to close the program is with task manager.

Downloads are stucked on queued with no errors given

Are you using the latest yt-dlg 1.8.5 version, and after opening it, have you gone to the "Setting" icon and selected "Update" to update everything to the latest version? It should say "Downloading latest CLI Backend. Please wait...", then "Successfully downloaded CLl Backend." in the bottom left corner of yt-dlg's screen if everything updated successfully. I know that's a pretty simple and obvious solution, but hopefully it helps. Otherwise, I don't know how to fix it, except to maybe try uninstalling yt-dlg, deleting all yt-dlg folders on your computer, and try reinstalling it.