text:
Design & create the SettingsEntity table & BinaryEntity table in the SQlite DB

Feature context

We are downloading a couple of resources and config settings to the app.
We would like to have a table that would help us easily map and reference the different downloaded resources.
These tables would be named SettingsEntity & BinaryEntity

SettingsEntitiy -- Holds the settings that cannot be mapped to a resource or binary e.g the composition_id
BinaryEntity -- Holds the files that are attached to a binary resource.

Feature implementation details
Table Structures

[ ] Create the tables named SettingsEntity & BinaryEntity, make sure we add them using migrations.

SettingsEntity
CREATE TABLE SettingsEntity (
    [id]       VARCHAR PRIMARY KEY,
    value       BLOB,
    type        TEXT
);

BinaryEntity
CREATE TABLE BinaryEntity (
    [id]       VARCHAR PRIMARY KEY,
    file       BLOB,
    resourceId     TEXT,
    resourcetype        TEXT
);

Could we store these in a Parameters instead of these tables?

Could we store these in a Parameters instead of these tables?

I think the Parameters can be used for the JSON configs. We could use the valueset strings to store them

Application Workflow parameters
Current JSON design.
[
  {
    "appId": "covax",
    "title": "EIR Covax app workflow",
    "mapping": [
      {
        "workflowPoint": "registration",
        "resource": "RegisterViewConfiguration",
        "classification": "patient_register",
        "description": "Configurations for patient register"
      },
      {
        "workflowPoint": "immunization_profile_view",
        "resource": "ImmunizationProfileViewConfiguration",
        "classification": "immunization_profile",
        "description": "Configurations for immunization profile "
      },
      {
        "workflowPoint": "login",
        "resource": "LoginViewConfiguration",
        "classification": "login",
        "description": "Configurations for login"
      }
    ]
  }
]

Parameter resource proposal
{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "appId",
      "valueString": "covax",
      "part": [
        {
          "name": "title",
          "valueString": "EIR Covax app workflow"
        },
        {
          "name": "mapping",
          "part": [
            {
              "name": "workflowPoint",
              "valueString": "registration",
              "part": [
                {
                  "name": "resource",
                  "valueString": "RegisterViewConfiguration"
                },
                {
                  "name": "classification",
                  "valueString": "patient_register"
                },
                {
                  "name": "description",
                  "valueString": "Configurations for patient register"
                }
              ]
            },
            {
              "name": "workflowPoint",
              "valueString": "immunization_profile_view",
              "part": [
                {
                  "name": "resource",
                  "valueString": "ImmunizationProfileViewConfiguration"
                },
                {
                  "name": "classification",
                  "valueString": "immunization_profile"
                },
                {
                  "name": "description",
                  "valueString": "Configurations for immunization profile"
                }
              ]
            },
            {
              "name": "workflowPoint",
              "valueString": "login",
              "part": [
                {
                  "name": "resource",
                  "valueString": "LoginViewConfiguration"
                },
                {
                  "name": "classification",
                  "valueString": "login"
                },
                {
                  "name": "description",
                  "valueString": "Configurations for login"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Form Configurations parameters
Current JSON design.
[
  {
    "appId": "covax",
    "form": "patient-registration",
    "title": "Add Patient",
    "identifier": "207"
  },
  {
    "appId": "covax",
    "form": "record-vaccine",
    "title": "Record Vaccine",
    "identifier": "800"
  },
  {
    "appId": "jnj",
    "form": "patient-registration",
    "title": "Add Patient",
    "identifier": "754"
  },
  {
    "appId": "jnj",
    "form": "record-vaccine",
    "title": "Record Vaccine",
    "identifier": "800"
  },
  {
    "appId": "jnj",
    "form": "adverse-event",
    "title": "Adverse Event",
    "identifier": "1568"
  }
]

Parameter resource proposal
{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "appId",
      "valueString": "covax",
      "part": [
        {
          "name": "mapping",
          "part": [
            {
              "name": "form",
              "valueString": "patient-registration",
              "part": [
                {
                  "name": "title",
                  "valueString": "Add Patient"
                },
                {
                  "name": "identifier",
                  "valueString": "207"
                }
              ]
            },
            {
              "name": "form",
              "valueString": "record-vaccine",
              "part": [
                {
                  "name": "title",
                  "valueString": "Record Vaccine"
                },
                {
                  "name": "identifier",
                  "valueString": "800"
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "name": "appId",
      "valueString": "jnj",
      "part": [
        {
          "name": "mapping",
          "part": [
            {
              "name": "form",
              "valueString": "patient-registration",
              "part": [
                {
                  "name": "title",
                  "valueString": "Add Patient"
                },
                {
                  "name": "identifier",
                  "valueString": "754"
                }
              ]
            },
            {
              "name": "form",
              "valueString": "record-vaccine",
              "part": [
                {
                  "name": "title",
                  "valueString": "Record Vaccine"
                },
                {
                  "name": "identifier",
                  "valueString": "800"
                }
              ]
            },
            {
              "name": "form",
              "valueString": "adverse-event",
              "part": [
                {
                  "name": "title",
                  "valueString": "Adverse Event"
                },
                {
                  "name": "identifier",
                  "valueString": "1568"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

This shows the composition with Parameters Resource instead of Binary Resource

Using Parameters Resource is fine. We will then need to write some custom logic to parse the resource into our  current configuration model (data classes) instead of using them directly.

@dubdabasoduba What would be the benefit of using Parameters resource. Just wondering if that extra step for mapping the resource to a configuration model is necessary.

@dubdabasoduba What would be the benefit of using Parameters resource. Just wondering if that extra step for mapping the resource to a configuration model is necessary.

The benefit is that we leverage FHIR resources and do not have to define our own schemas. This makes it easier for us to do the following

Write documentation on how to configure the FHIR core.
Make sure the configurations are standard and anyone with a good understanding of FHIR resources can write them.

Can we close this issue if we're using the Parameter resource?

authors: dubdabasoduba ellykits pld


text:
Name of passphrase encoding manpage

The file doc/man7/passphrase-encoding.pod has a space in the name, making it impossible to actually get that manpage.
There is also password vs passphrase.
Reported by lintian

Will fix

source: gharchive/issue

authors: kroeckx levitte

repo: openssl/openssl

license_type: permissive

license_source: github-api


text:
Cross Compile Failed

Version Openssl 1.1.1d
System: Debian stretch
Complie tool: mingw-w64
configure: ./Configure mingw64 --cross-compile-prefix=x86_64-w64-mingw32- --prefix=/usr/x86_64-w64-mingw32 shared
result: make passed but make install failed.
log:
make depend && make _build_libs
make depend && make _build_engines
make depend && make _build_programs
created directory `C:'
created directory `C:/Program'
created directory `Files'
created directory `Files/Common'
make[1]: Entering directory '/tmp/openssl'
created directory `Files/SSL'
created directory `Files/SSL/certs'
make[1]: Entering directory '/tmp/openssl'
created directory `Files/SSL/private'
created directory `Files/SSL/misc'
make[1]: Entering directory '/tmp/openssl'
install ./apps/CA.pl -> C:/Program Files/Common Files/SSL/misc/CA.pl
cp: target 'Files/SSL/misc/CA.pl.new' is not a directory
Makefile:297: recipe for target 'install_ssldirs' failed
make: *** [install_ssldirs] Error 1
make: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/tmp/openssl'
make[1]: Leaving directory '/tmp/openssl'
make[1]: Leaving directory '/tmp/openssl'
make[1]: Entering directory '/tmp/openssl'
make[1]: Nothing to be done for '_build_libs'.
make[1]: Leaving directory '/tmp/openssl'
make[1]: Entering directory '/tmp/openssl'
make[1]: Nothing to be done for '_build_engines'.
make[1]: Leaving directory '/tmp/openssl'
make[1]: Entering directory '/tmp/openssl'
make[1]: Nothing to be done for '_build_programs'.
make[1]: Leaving directory '/tmp/openssl'

Yup, there's work going on in #9864 to fix this.

As an update, this is kinda sorta the issue that is worked on in #9864, if you do installation in a mingw environment...  however, that's not what you're doing, and that got me a little by surprise.
The expected action was that installation would be done on the target system.  That being said, I see your prefix configuration option, and wonder why it was so completely ignored.
Will revisit this tomorrow.

Just to note that #9864 wasn't noticed/tested in a Windows mingw environment (it should be a largely similar case though), but debian:testing (← docker ← Ubuntu ← AppVeyor) and macOS (Homebrew).

Theoretically your --prefix should be where the files are located at the target:
 ./Configure mingw64 --cross-compile-prefix=x86_64-w64-mingw32- --prefix="C:/Program Files" shared
and you install using DESTDIR= where you mount the target file system:
make install DESTDIR=/mnt/target

As an update, this is kinda sorta the issue that is worked on in #9864, if you do installation in a mingw environment... however, that's not what you're doing, and that got me a little by surprise.
The expected action was that installation would be done on the target system. That being said, I see your prefix configuration option, and wonder why it was so completely ignored.
Will revisit this tomorrow.

The 1.1.1c edition is ok, but 1.1.1d is illed.
I want to compile aria2c for windows X64 with the mingw64 tool.
Openssl is a dependence for aria2c.

Theoretically your --prefix should be where the files are located at the target:
 ./Configure mingw64 --cross-compile-prefix=x86_64-w64-mingw32- --prefix="C:/Program Files" shared
and you install using DESTDIR= where you mount the target file system:
make install DESTDIR=/mnt/target
I use Debian for cross compiling, the parameter --prefix="C:/Program Files" is wrong.

How did you configure your 1.1.1c ?

How did you configure your 1.1.1c ?

configure: ./Configure mingw64 --cross-compile-prefix=x86_64-w64-mingw32- --prefix=/usr/x86_64-w64-mingw32 shared
It is same.

I use Debian for cross compiling, the parameter --prefix="C:/Program Files" is wrong.

NO!!!!  This way your target openssl will have security issues.
It will try to load config and engines from /usr/x86_64-w64-migw32 but have no drive letter.
So it will load rougue files it they are installed there.

For cross compiling, prefix has to be where the program will be installed at the target.
The path is compiled into the .DLL. if your target uses drive letters, you better specify them.

I use Debian for cross compiling, the parameter --prefix="C:/Program Files" is wrong.

NO!!!! This way your target openssl will have security issues.
It will try to load config and engines from /usr/x86_64-w64-migw32 but have no drive letter.
So it will load rougue files it they are installed there.

Does you regard "C:" or "D:" as a drive letter?
But does debian has a drive letter? Are you sure?
And what does "rougue" meaning?
My cross compilation is on a Debian machine not windows.

I mean "rogue" i.e. infected with viruses.

Ah, I was wondering if an intermediate Unix side staging area was involved in the problem.
This isn't very well supported, it's true...

There is still an issue, we should be able to configure --prefix="C:/Program Files"
maybe with CONFIGURE_INSIST for cross-compiling.

Ah, I was wondering if an intermediate Unix side staging area was involved in the problem.
This isn't very well supported, it's true...

I am confused why my parameter "--prefix=/usr/x86_64-w64-mingw32" is not useful .
And 1.1.1c is ok.
Because the official document of aria2c told me the openssl can be used to compile aria2c.
I have successfully finished the aria2c compilation with openssl-1.1.1c

There is still an issue, we should be able to configure --prefix="C:/Program Files"
maybe with CONFIGURE_INSIST for cross-compiling.

My debian does not have a "C:/Program Files" directory

Yes, that is a cross compilation, the path name "C:/Program Files" still need to be known
to the compiled files, which execute on the target, wehre C:/Program Files" exist
and have admin-only access rights.

@SKIYET, CHANGES gives a quick summery, the rest can be read in the security advisory

But I use mingw on debian...do you ask me creat a windows folder and then the point the prefix to this folder？
I cannot understand.

You do not override the mingw prefix and create a sys-root folder on your linux system
and point DESTDIR= to that folder while make install.
Then you copy the files from the sys-root folder to your mingw system, which should
have C:\Windows, and C:\Program Files and windows O/S

You do not override the mingw prefix and create a sys-root folder on your linux system
and point DESTDIR= to that folder while make install.
Then you copy the files from the sys-root folder to your mingw system, which should
have C:\Windows, and C:\Program Files and windows O/S

Does you mean create a folder whose owner is root
And use ./Configure mingw64 --cross-compile-prefix=x86_64-w64-mingw32- --prefix="C:/Program Files" shared
make
make DESTDIR="sys-root folder".
I use ./Configure mingw64 --cross-compile-prefix=x86_64-w64-mingw32- --prefix="C:/Program Files" shared, but failed. The log is as follow.
Failure!  build file wasn't produced.
Please read INSTALL and associated NOTES files.  You may also have to look over
your available compiler tool chain or change your configuration.
Directory given with --prefix MUST be absolute

That's why this issue is not closed.
You should remove the --prefix= and let the configure use the default prefix.

That's why this issue is not closed.
You should remove the --prefix= and let the configure use the default prefix.

I think It is difficult to use openssl if I want cross compile a software with linux...
I only want use openssl to compile aria2...

could you please tell me what should I do if I want create a sys-root folder?

Hi SKIYET,
SKIYET wrote:

There is still an issue, we should be able to configure --prefix="C:/Program Files"
maybe with CONFIGURE_INSIST for cross-compiling.
My debian does not have a "C:/Program Files" directory

Ignore all kinds of such suggestions.
Use what you want to build/create package, i.e. prefix is not so
important for binaries.
Read above as later on package installation time to use save location to
install binaries
Remark: of course do not hard code any drive letter and path as
suggested! Usually package manager(PM) are able to extract them from
system settings. Use PM functionality to get them.
After installation on user system binaries may search for configuration
in "" but this is another story and ... (depend from installed
environment).
Regards,
Roumen Petrov

Hi SKIYET, SKIYET wrote:

There is still an issue, we should be able to configure --prefix="C:/Program Files" > maybe with CONFIGURE_INSIST for cross-compiling. My debian does not have a "C:/Program Files" directory
Ignore all kinds of such suggestions. Use what you want to build/create package, i.e. prefix is not so important for binaries. Read above as later on package installation time to use save location to install binaries Remark: of course do not hard code any drive letter and path as suggested! Usually package manager(PM) are able to extract them from system settings. Use PM functionality to get them. After installation on user system binaries may search for configuration in "" but this is another story and ... (depend from installed environment). Regards, Roumen Petrov

Dear
But seemed like there is no openssl-mingw64 in debian if I use APT tool to install openssl.
Thanks
And @levitte ,What shoud I do now?

I think my case is a little different, I ran into same issue cross-building to static lib with mingw:
$ LDFLAGS="-static -static-libgcc" ./Configure --cross-compile-prefix=i686-w64-mingw32- no-shared no-zlib no-asm --prefix="$HOME/openssl/install" -static mingw
The problem is the same, it fails on install step. But on a static build, PATH should be irrelevant, since it is only used to search for .a libs when building other dependent binaries.

More on this: I have succesfully built some binary against static openssl-1.1.1d, even with failed install step. It seems all libs and includes are in place on specified prefix and the failed message is some cosmetic issue. Not sure this is also the case for shared build, I recommend testing.

More on this: I have succesfully built some binary against static openssl-1.1.1d, even with failed install step. It seems all libs and includes are in place on specified prefix and the failed message is some cosmetic issue. Not sure this is also the case for shared build, I recommend testing.

I am sorry but failed.
Due to the configuration progress of aria2 will check whether openssl was installed or not.

@levitte what can I do now ?
I want to clone the commit to "84eba0d57d22884a81ceda34db108b3d9be8f9c4" mentioned in  #9864 with the command “git checkout 84eba0d57d22884a81ceda34db108b3d9be8f9c4”，it failed.
log is as follow
git checkout 84eba0d57d22884a81ceda34db108b3d9be8f9c4
fatal: reference is not a tree: 84eba0d57d22884a81ceda34db108b3d9be8f9c4

More on this: I have succesfully built some binary against static openssl-1.1.1d, even with failed install step. It seems all libs and includes are in place on specified prefix and the failed message is some cosmetic issue. Not sure this is also the case for shared build, I recommend testing.

Dear
could you please tell me the the influence of parameter "no-zlib"?

Marking as inactive, to be closed at the end of 3.4 dev barring further input

authors: SKIYET bernd-edlinger levitte nhorman petrovr pkreuzt vszakats


text:
Property: fix memory leak.

Coverity 1456008.

The tests need to be looked at.  A job for tomorrow.

I must have had selective blindness writing the first version of this fix 😢

Merged to master.  Thanks.

source: gharchive/pull-request


text:
ci: Add GitHub token permissions for workflows

This PR adds minimum token permissions for the GITHUB_TOKEN using https://github.com/step-security/secure-workflows.
GitHub recommends defining minimum GITHUB_TOKEN permissions for securing GitHub Actions workflows

https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token
The Open Source Security Foundation (OpenSSF) Scorecards treats not setting token permissions as a high-risk issue

This project is part of the top 100 critical projects as per OpenSSF (https://github.com/ossf/wg-securing-critical-projects), so fixing the token permissions to improve security.
Signed-off-by: Varun Sharma varunsh@stepsecurity.io

We would need a CLA to be signed to be able to merge this. I am afraid this is outside of what we allow for CLA: trivial contributions.
https://www.openssl.org/policies/cla.html

We would need a CLA to be signed to be able to merge this. I am afraid this is outside of what we allow for CLA: trivial contributions.
https://www.openssl.org/policies/cla.html

I have printed, signed, and emailed a scanned copy of the ICLA.

After signing the ICLA, I got an email to close and re-open open PRs for the CLA hold to go away.

I assume 111 has the same issue?

It will do, yes.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged to 1.1.1, 3.0 and master.  3.0 and 1.1.1 had fewer files but otherwise cherry-picked okay.
Thanks for the fixes.

authors: openssl-machine paulidale slontis t8m varunsh-coder


text:
read lock store on ossl_method_store_do_all

Theres a data race between ossl_method_store_insert and ossl_method_store_do_all, as the latter doesn't take the property lock before iterating.
However, we can't lock in do_all, as the call stack in several cases later attempts to take the write lock.
The choices to fix it are I think:

add an argument to indicate to ossl_method_store_do_all weather to
take the read or write lock when doing iterations, and add an
is_locked api to the ossl_property_[read|write] lock family so that
subsequent callers can determine if they need to take a lock or not

Clone the algs sparse array in ossl_method_store_do_all and use the
clone to iterate with no lock held, ensuring that updates to the
parent copy of the sparse array are left untoucheTheres a data race
between ossl_method_store_insert and ossl_method_store_do_all, as the
latter doesn't take the property lock before iterating.

I think method (2), while being a bit more expensive, is probably the far less invasive way to go here
Fixes #24672

A thought: would using a stack for the temporary copy make sense?  It would avoid some of the inefficiencies of the sparse array.

A thought: would using a stack for the temporary copy make sense? It would avoid some of the inefficiencies of the sparse array.

Yeah, we should use that.

Please also note there is a duplicated text in the commit message.

fixups made to use a stack rather than a sparse array, fix nits, and correct commit message

This pull request is ready to merge

Merged to all the active branches. Thank you.

authors: nhorman openssl-machine paulidale t8m


text:
Replumbing: re-implement error reporting for providers

The idea is that providers should only have to report a reason code.
The library code is considered to be libcrypto internal, and are
allocated dynamically and automatically for providers on creation.
We reserve the upper 8 bits of the reason code for internal OpenSSL
use.  This allows our own providers to report errors in form of a
packed number that includes library number, function number and
reason number.
With this, a provider can potentially use any reason number it wants
from 1 to 16777216, although the current error semantics really only
allow 1 to 4095 (because only the lower 12 bits are currently
considered an actual reason code by the ERR subsystem).
A provider can provide a reason string table in form of an array of
ERR_STRING_DATA, with each item containing just the reason code and
the associated string, with the dispatch function numbered
OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type
OSSL_provider_get_reason_strings_fn.
If available, libcrypto will call that function on provider
activation.

Also added the FIPS module adaptation.

Note that this seems to conflict with #8887, but only partially.  The change of semantics for ERR_add_error_data there is fine, but the provider adaptation isn't.

Argh, too early approval...  I realised that we need to add a string for the lib code (prov->error_lib).  I need to go away for a little bit, so that won't happen for one or two hours yet.

Now added the code I intended.

... and hopefully cleared the last Travis issue

A rebase may make Travis happier...

Ping

Ping

Merged.
6592ab81d21fc01e05a01cd5b96c84b069bf8acf FIPS module: adapt for the changed error reporting methods
6ebc2f56f04ac2738d3b9bfc732063ad8f51e75d Replumbing: re-implement error reporting for providers


text:
Fix SSL_check_chain()

The function SSL_check_chain() can be used by applications to check that
a cert and chain is compatible with the negotiated parameters. This could
be useful (for example) from the certificate callback. Unfortunately this
function was applying TLSv1.2 sig algs rules and did not work correctly if
TLSv1.3 was negotiated.
We refactor tls_choose_sigalg to split it up and create a new function
find_sig_alg which can (optionally) take a certificate and key as
parameters and find an appropriate sig alg if one exists. If the cert and
key are not supplied then we try to find a cert and key from the ones we
have available that matches the shared sig algs.
This PR also fixes "no_tls1_2-method" which started failing recently. This was mainly due to new tests that called SSL_check_chain() and ran into the bug above. There were also a couple of other minor issues which I fixed along the way.
I will create a separate PR for 1.1.1 since this one won't cherry-pick cleanly.

See #9443 for the 1.1.1 backport. Please review this PR first!

This introduced a memory leak?

Fixup pushed to address memory leak.

Rebased to resolve a conflict with master.
Ping?

Ping?

There was a non-trivial conflict with master (in the sslapitest code) which I've now resolved. I also fixed your comment nit.
@t8m please could you reconfirm?

Approved again.

Pushed to master. Thanks. I'll update the 1.1.1 PR equivalent of this shortly.

Reopening this PR even though its already been merged, to make sure we don't forget about @kaduk's comments.

I think this can be closed again, now that we have #9672.

authors: kroeckx mattcaswell t8m


text:
Get notified in the glanceAPI controller

This patch is a follow up of PR#181.
If the Glance top level CR changes (e.g. an extraMount is updated), we should watch it and `trigger the reconcile loop (which means we should be notified as long as this event occur).

@fmount Shall we close this one since we merged #191 ?

@fmount Shall we close this one since we merged #191 ?

Sure, thanks. Looks like #191 is the approach we're going to use in the other operators as well.

authors: abays fmount


text:
Conflict dialog shows incorrect conflicting user

I just conflicted with another user while editing way 10576362. The changeset that I'm in conflict with is changeset 32686501. It is nothing more than a change to the name=* tag by user j03lar50n. I edited the geometry and added other things in the area as well as changing the name tag. However here is what iD is showing me:

woodpeck_fixbot hasn't opened a changeset in 3 years and has never touched this particular way at all so I'm not sure how that user name ended up in the conflict dialog.

Yeah I have seen the occasional conflict with woodpeck_fixbot too when I was testing and never could figure out why until now.
It's because of how we lump all the childnode changes together when a parent way is changed.   In this case, the parent way had the conflict, but we need to check all the childnodes also.  You must have moved a childnode that had not been moved since woodpeck_fixbot, and this code noticed the difference and flagged it incorrectly as a conflict.
By the way, if if weren't for this bug, iD probably would have just let the change though safely without a warning.  If two users happen to change a way to the same name, there is really no tag conflict and iD considers it a 'safe' merge.

Fixed in 4c6b75a, thanks @ToeBee!

authors: ToeBee bhousel

repo: openstreetmap/iD

license: ISC


text:
Tutorial: Sometimes things to click are outside of marked area

I managed this by zooming in and out and moving the map around...

oh yeah, this is already tracked on #2386

authors: bhousel rugk


text:
Wikidata field should autocomplete labels

#5500 implemented a Wikidata field that contains a plain text Identifier box for the QID of a Wikidata item. As a Wikidata contributor, I would find this field to be much more intuitive if it behaves like the claim text boxes on Wikidata. I think it would also be more intuitive to mappers who are unfamiliar with Wikidata and wouldn’t know how to come up with a QID on their own (since the Wikipedia field doesn’t automatically appear when you show the Wikidata field).
On Wikidata, you can type in a label and autocompletion suggestions appear, similar to the Wikipedia field’s title box:

But you can also paste in a QID and a matching item appears:

Either way, once you select the suggestion, the label ends up in the text box:

Even though Wikidata is built atop QIDs, the QIDs are treated like a machine-readable implementation detail and deemphasized as much as possible in UI.
So I’d suggest rearranging the Identifier, Label, and Description boxes, so that once you select an item, the Label box at the top contains the label, the read-only Description box follows, and the read-only Identifier box contains the QID at the bottom.

This would be particularly good when used for the Architect, Species/Animal, Operator, Network, Brand, Artist, Name Etymology and Subject fields.
So when typing out, for example, in an architect field "Santiago Calatrava", a Wikidata dropdown menu would appear, and upon selection we'd automatically set architect=Santiago Calatrava and wikidata:architect=Q168482.

So when typing out, for example, in an architect field "Santiago Calatrava", a Wikidata dropdown menu would appear, and upon selection we'd automatically set architect=Santiago Calatrava and wikidata:architect=Q168482.

I think people are generally in favor of the idea except for the "automatically" part  👍

@bhousel if we know that the fields architect and wikidata:architect are exact equivalents, what's the risk?

Here’s an example Wikidata API query that would be kicked off after typing in “Junction City” when iD is set to the Vietnamese locale. Notice how the labels and descriptions are in English as a fallback.
Note that this issue is specifically about the behavior of the existing wikidata field type, which is currently only used for the Wikidata field (corresponding to the wikidata tag). #5484 is about adopting that field type for the Operator field (operator:wikidata). I do think this issue would need to be addressed before Wikidata functionality could be added to any other fields, because there isn’t a straightforward mapping from taginfo autocompletion results to Wikidata QIDs.

I did this.

authors: 1ec5 bhousel picsi quincylvania


text:
Naming rule check

On the wiki page for names there is a section called Name is the Name Only, which says that names   should be restricted to the name of the item only and not contain the official name such as categories, types, or descriptions of the objects. It also says not to invent names if the object doesn't have one.
As it currently stands there a bunch of objects in the database that contain descriptive names. Some examples include name=park (2436 uses), name=school (2538 uses), name=shop (1635 uses),  name=parking (1635 uses). There's many others. Along with things containing category names, like name=public_toilet (395 uses). Although its to a lesser degree.
given the amount of miss naming going on, would it be possible to have iD Edior do a check when someone saves their work to see if the key of the object matches the key of the name tag or something? If  that doesn't work, it would be good to at least  mention the naming rule when someone clicks on the more information button in the name preset or somewhere else before they add a value to it. So they know what the proper tagging is and don't just add a name because they think it needs one. I've talked to some new editors about it. All of them didn't know the rule existed and just wanted to put something in the name field since it was there. Even if the object didn't have a proper name. So, its obviously an issue for new mappers.

Hmm we probably could create a validation for this
We actually have a pretty solid noiseword regex over in name-suggestion-index to filter out generic names.
https://github.com/osmlab/name-suggestion-index/blob/master/config/filters.json#L44

It's worth mentioning that we do sort of tell users how to use the Name field in the walkthrough.  I don't want to overload new users with a bunch of complicated rules - I think the short explanation here is ok.

I don't blame you for not wanting to overload new users with complicated rules. They wouldn't necessarily follow it anyway. So a validation thing would be my preferred solution if its possible. I was actually thinking about something like or related to the name-suggestion-index when I created the issue.


text:
Alt-G crashes iD

While in editing mode, pressing Alt+G crashes iD (not the browser).
Hot to reproduce:

choose new line or area feature
create first point
press Alt+G
iD crashes (freeze)

Well I am not sure if this is related but ever since Chrome browser did it's last update, it has crashed to desktop for me several times while editing with iD. Another user on discord reports the same.

This is a dup of #6584

authors: Thorwynn bhousel famo


text:
Do not add healthcare=pharmacy to amenity=pharmacy and similar common amenity values

PR #4329 helpfully added a number of missing healthcare-related features and property tags, after a short discussion in #3589
However, it also added a unusual rule to always add duplicate tags of the form healthcare=pharmacy to features with amenity=pharmacy. At the time of the PR, healthcare=pharmacy was used under 500 times, compared to 220,000 amenity=pharmacy features at that time. Though it had been mentioned in a proposal back in 2010, it had never become popular.
Since then it has only be used along with amenity=pharmacy (99.7% of the time),  most likely added mostly by this preset. (https://taginfo.openstreetmap.org/tags/healthcare=pharmacy#combinations)
The situation is similar for:

amenity=hospital / healthcare=hospital
amenity=clinic / healthcare=clinic
amenity=doctors / healthcare=doctor
amenity=dentist / healthcare=dentist

During the discussion in issue #3589 a maintainer and several contributors mentioned that the amenity tags should not be deprecated (see https://github.com/openstreetmap/iD/issues/3589#issuecomment-260979736) so it is unclear why the uncommon healthcare=* versions of these tags were added.
I recommend changing the presets and validation rules for these 5 features to just use the common amenity=* tags in these cases, to avoid tag fragmentation and duplicate tagging.

They were approved

The tag healthcare=pharmacy was not approved, and consensus is that this tag is not needed: amenity=pharmacy is the tag supported by other editors and all database users.
See the history on the tag page:
"Multiple healthcare=* tags were introduced by healthcare proposal. This tag duplicating amenity=pharmacy was not introduced by this proposal. Author of the healthcare proposal wanted to deprecate amenity=pharmacy and replace it with shop=pharmacy, but due to strong opposition to deprecating amenity=pharmacy this was abandoned."
https://wiki.openstreetmap.org/wiki/Tag:healthcare%3Dpharmacy - the relevant text was added by another user (See https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahealthcare%3Dpharmacy&type=revision&diff=1951994&oldid=1951250)


text:
Excluded area is shown as a part of multipolygon area

This national park has several excluded parts. Let's look at the top-middle part which excludes this town, called Ķaunata.

The excluded town is marked by red circle:

THE BUG. Why does iD displays the excluded city as if this park is inside this city? And the border band (that show difference between a line and an area), should be outside of the border. Isn't it?

Hi and welcome, @soshial.
This is a longstanding issue we've been tracking at #1201. For efficiency, iD only downloads the relation members in view. In your example, no outer members are downloaded so SVG renders the inner part as an outer part. You can manually download more parts in the Members section of the inspector and watch the rendering update.
#6656 would address this problem, but we're waiting for an OSM API endpoint that returns many full entities in a performant manner. See https://github.com/openstreetmap/openstreetmap-website/issues/2348.

Thanks for the profound explanation.

authors: quincylvania soshial


text:
Calculate and warn if lanes:forward + lanes:backward != lanes

Description
Is it a good idea to be proposed here?
Screenshots
No response

The validator would be capable of warning about this situation. To be accurate, the validation rule would also need to factor in other subkeys such as lanes:both_ways and lanes:reversible.
Unfortunately, the warning message would have to tell the user to muck around with raw keys, because there’s no field for directional subkeys of lane: #8630 #387. Validator warnings are normally for things the UI can help the user with.


text:
set the locale of the login popup

Closes #3595
We now send the locale code that iD is using to the OAuth popup, so that the user always sees their preferred language. Same idea as #9501
This will have no effect until https://github.com/osmlab/osm-auth/pull/130 is merged and released

https://github.com/openstreetmap/iD/labels/waitfor-upstream can be removed , see #10223


text:
Remove accidental mismatch of "PAMAP"

https://www.openstreetmap.org/way/166528135 would no longer be flagged by this change, although it's still incompatible data.
Adding more tests in https://github.com/openstreetmap/iD/blob/develop/test/spec/validations/incompatible_source.js might be good.

I don’t know anything about Europe so I can’t help here. As far as I can see it’s a regression introduced by a patch to warn about proprietary Chinese data.

authors: cicku mmd-osm


text:
[BUG] 点击 Diff 视图中的编辑器标签页，该编辑器没有在文件树中定位

在 SCM 界面点击某个文件
切换到其他编辑器 tab
此时再点之前那个 diff 的标签，该标签不会在文件树中定位

目前在 Diff 文件下点击是不会触发文件树上的定位的，这个是 ByDesign，有需要可以后续实现一下

repo: opensumi/core

license: MIT


text:
feat: a global hook for OpenSumi DevTools to communicate with

This PR will resolve #1098. You are welcomed to visit the issue to review the whole process of how the devtools developed.
Types

[x] 🎉 New Features

Background or solution
A global hook

Q: How opensumi/core and opensumi-devtools communicate with each other?
A: A global hook! That is the key.

Step 1. opensumi/core exposes a global hook window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__ = {} when ClientApp starts
Step 2. opensumi-devtools tries to detect the existence of the hook, if the hook exists it will run
Step 3. if user click "startCapture" button in the devtools, a few variables and functions will be injected to the hook by the API chrome.devtools.inspectedWindow.eval().
Step 4. when messages are received and sended in proxy.ts, opensumi/core will try to access to window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__.capture, if accessible, it will call the injected global capture function and then put messages to window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__.messages.
Step 5. opensumi-devtools get new messages from window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__.messages every 1 second and set the message array to empty after getting all new messages.
Step 6. opensumi-devtools present the messages with a good UI.
Step 7. if user click "stopCapture" button, window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__ will be set to {} so no capture function can be accessed and opensumi/core will stop sharing its messages.
A contribution point

Q: As an extension, how opensumi-devtools get network latency from opensumi/core?
A: In the same way as how messages are captured.

Step 1. by leveraging opensumi's lifecycle contribution, a timer is set in initialize phase.
Step 2. Each second, opensumi/core will query the states(like capturing state, from the global hook) of opensumi-devtools then behaves accordingly. Currently we only focus on the capturing state, if the devtools is in capturing, opensumi/core will start to test rtt and put the value to window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__.latency.
Step 3. opensumi-devtools will get latency value from the hook and presents it in UI.
Changelog
a global hook and a contribution point for OpenSumi DevTools to communicate with.

@yantze @erha19 @bytemain
Hi guys! Please take minutes to review the code, thanks!

对于Web端，只要浏览器安装了opensumi devtools插件即可生效；对于Electron端，需要等该插件上架到chrome webstore后再利用electron-devtools-installer进行集成（见此issue）。
所以不想分好几个PR的话，可以等到插件发布上架后再合并这个PR。


text:
chore: update READEME with new logo

Types

[x] 🧹 Chores

Background or solution
Changelog
update READEME with new logo


text:
[Feature] Electron IPC messages capturing and presenting

初步调查
假设我是一个opensumi/core的集成方，如果要做electron应用，那么一定会使用到@opensumi/ide-core-electron-main模块。于是，如果ipc捕获功能需要opensumi/core配合的话，我就应该着眼于修改ide-core-electron-main模块。
ide-electron项目是一个示范项目，指导集成方如何基于opensumi/core打造electron应用。
opensumi/core的tools/electron类似于ide-electron，但是更加简单一点。
@yantze老师，请问我的上面3个理解对吗？

查看代码时的想到的问题：
https://github.com/opensumi/core/blob/main/packages/core-common/src/mocks/electron/ipcRenderer.ts
@yantze 老师，请问这个MockedElectronIpcRenderer是做什么用的？只是为了测试用吗？

马克一下：
https://github.com/opensumi/core/pull/1560 中，在core-browser/src/bootstrap/app.ts的构造函数中向window全局变量插上HOOK。
如果是electron app的形式，那么会先启动electron的main thread，main thread再启动browser window，所以这里有个时间先后关系，要留心一下。

外挂式和侵入式的选择
Devtron的做法是在loadExtension的时候（应该是比较初始的时间点），就对ipcRenderer的方法做个代理，这样后面用到ipcRenderer的各个方法时，被改造过的方法都会把消息给捕捉了。
browserNodeIntegrated是集成方控制的一个配置项，如ide-connection设置为true，但是core中的electron是设置为false的。
若browserNodeIntegrated为true，那么opensumi-devtools可以像Devtron那样，直接require('electron').ipcRenderer和require('electron').ipcMain来改造，是完全外挂式的。但是，若browserNodeIntegrated为false，那么opensumi-devtools中无法访问模块，只能采用捕获ws messages那样的方法，即需要opensumi/core进行配合。
我个人更倾向于侵入式的方式，@yantze老师怎么看？

与Electron IPC相关的API一共有多少？
官网介绍的有若干个；electron.d.ts中还有其他官网没提到的。
只处理官网介绍的那几个API是否足够？@yantze

初步调查
假设我是一个opensumi/core的集成方，如果要做electron应用，那么一定会使用到@opensumi/ide-core-electron-main模块。于是，如果ipc捕获功能需要opensumi/core配合的话，我就应该着眼于修改ide-core-electron-main模块。
ide-electron项目是一个示范项目，指导集成方如何基于opensumi/core打造electron应用。
opensumi/core的tools/electron类似于ide-electron，但是更加简单一点。
@yantze老师，请问我的上面3个理解对吗？

对的，如果有相关的修改，最好是 ide-core-electron-main

查看代码时的想到的问题：
https://github.com/opensumi/core/blob/main/packages/core-common/src/mocks/electron/ipcRenderer.ts
@yantze 老师，请问这个MockedElectronIpcRenderer是做什么用的？只是为了测试用吗？

对的

外挂式和侵入式的选择
Devtron的做法是在loadExtension的时候（应该是比较初始的时间点），就对ipcRenderer的方法做个代理，这样后面用到ipcRenderer的各个方法时，被改造过的方法都会把消息给捕捉了。
browserNodeIntegrated是集成方控制的一个配置项，如ide-connection设置为true，但是core中的electron是设置为false的。
若browserNodeIntegrated为true，那么opensumi-devtools可以像Devtron那样，直接require('electron').ipcRenderer和require('electron').ipcMain来改造，是完全外挂式的。但是，若browserNodeIntegrated为false，那么opensumi-devtools中无法访问模块，只能采用捕获ws messages那样的方法，即需要opensumi/core进行配合。
我个人更倾向于侵入式的方式，@yantze老师怎么看？

外挂的方式应该也可以， devtools 自身其实也是一个 renderer

与Electron IPC相关的API一共有多少？
官网介绍的有若干个；electron.d.ts中还有其他官网没提到的。
只处理官网介绍的那几个API是否足够？@yantze

其它的暂时应该用不到的

UI设计上，我打算这么做：

将目前的toolbar往右移动一点，左边腾出来加一个新按钮“RPC/IPC”用于切换两种消息列表。RPC目前的toolbar以蓝色为主，IPC的toolbar可以以橙色为主，这样容易区别。
另外，切换RPC/IPC不会重新渲染，也就是说当从RPC切到IPC，再切回RPC，RPC的内容在期间是一直“持续”着的，不会清零。

外挂的方式应该也可以， devtools 自身其实也是一个 renderer，你可以直接获取到 devtools 的窗口 id，然后 main 进程发送给 devtools

@yantze 老师，这个能不能更具体点点？我还打算和RPC的捕获方式保持一致呢，就是用window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK.ipcMessages做中介。

外挂的方式应该也可以， devtools 自身其实也是一个 renderer，你可以直接获取到 devtools 的窗口 id，然后 main 进程发送给 devtools

@yantze 老师，这个能不能更具体点点？我还打算和RPC的捕获方式保持一致呢，就是用window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK.ipcMessages做中介。

保持一致也可以，那就不需要 devtools 的窗口 id

OK，先用类似的方法来做。以后有更好的方法可以重构~

外挂式不大行

先解释一下我说的“外挂式”和“侵入式”是指什么。“外挂式”是指基本不需要动opensumi/core的代码，只要在devtools里写代码就能达到目的的方式；“侵入式”指必须要改opensumi/core的代码才能达到目的的方式。

经过一番摸索，我认为外挂式不行，理由如下：

外挂式需要Electron开启browserNodeIntegrated，而开启此选项被认为是有安全风险的，一般不推荐开启
即使该选项开启了，在browser中require('electron').ipcMain得到undefined，但是ipcRenderer能够access的。这意味着在外挂式的条件下，devtools只能改造ipcRenderer而不能改造ipcMain。事实上，DevTron改造的就只有ipcRenderer。

侵入式的摸索
比如说要改造ipcMain.on这个方法。
首先，这个改造时间点要尽早，要在所有用到ipcMain.on的时间之前。此外，要运行在main进程的范围中。因此，我挑选core-electron-main/src/bootstrap/app.ts的import语句后的位置。
对于on类的方法，不像send类每次有消息要发送都会执行一次，on类只会在注册的时候执行一次，因此要考虑代理参数中的handler，我是这么做的：
const originalOn = ipcMain.on;
ipcMain.on = function (channel: any, handler: any) {
  const proxyHandler = (event: any, ...args: any) => {
    // capture(channel, event, args);
    handler(event, ...args);
  };
  return originalOn.call(ipcMain, channel, proxyHandler);
};

上面这个方法是可以成功的，我在测试的时候还加了几句console.log，可以在本地shell中看到。
对于其他ipcMain.xxx和ipcRenderer.xxx，我打算在core-electron-main合适的位置中改造。@Yantze老师觉得这样可以吗？

2. devtools只能改造ipcRenderer而不能改造ipcMain

类比到rpc的前端和后端，我突然发现ipcMain就是Electron app的后端。rpc的后端我们是不捕获的，那么Electron app的后端也不用捕获吗？

先用侵入式这种方式，提供原始数据吧，这种不确定会不会对性能产生影响，如果有明显的影响，可能需要后面添加开关实现。

devtools只能改造ipcRenderer而不能改造ipcMain

类比到rpc的前端和后端，我突然发现ipcMain就是Electron app的后端。rpc的后端我们是不捕获的，那么Electron app的后端也不用捕获吗？

main 进程是广播式，所以监听 main 进程的消息是有必要的，不过可以放到后面做也行

ok

外挂的方式应该也可以， devtools 自身其实也是一个 renderer，你可以直接获取到 devtools 的窗口 id，然后 main 进程发送给 devtools

保持一致也可以，那就不需要 devtools 的窗口 id

Too young too naive，我天真的想着从main进程里用window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__.captureIpc把消息放到window.__OPENSUMI_DEVTOOLS_GLOBAL_HOOK__.ipcMessages中，完全忽略了main进程里面根本没有window。
所以就像@Yantze老师给的建议那样，涉及到ipcMain的消息捕获本身就需要利用IPC通信才能间接/直接传给devtools。
至于是main -> browser -> devtools还是main -> devtools，我得摸索后才能确定。

@yantze 老师，opensumi devtools要判断是在Web还是Electron中打开。刚才我是在core-browser/src/bootstrap/app.ts中加了一段：

但现在我发现core-electron-main/browser-preload/index.js中已经有electronEnv暴露给global也就是window对象了，您觉得用哪个好？

用 electronEnv 就行了，避免过多的 DevTools 的逻辑

opensumi/core对捕获IPC消息的支持刚刚提了个Draft PR。
devtools这边，IPC消息列表的columns我打算这么设计：

ID
Time
IPC Method
Channel
Arguments

如果Arguments普遍不复杂的话，也许可以不用JSON View，而是像DevTron这样直接当一个普通单元格：

另外，@yantze 老师，怎么能多触发一些Electron IPC API，像ipcRenderer.send这种，我粗粗看了下，代码里用到的很少，都不好测试:joy:。亲测通过UI可以触发的有：缩放移动窗口，点击菜单栏中的选项。

repo: opensumi/devtools


text:
[4.x] properly define function aliasses

Digging in extension reflection, I notice:
    Method [ <internal:openswoole> public method swoole_timer_list ] {

      - Parameters [0] {
      }
      - Return [ <D9>' ]

1/ this is obviously not a method
2/ return type is corrupted
Looking its code, it seems SW_FUNCTION_ALIAS does wrong things.
This PR drop most usage and use standard API call.
NOTICE: some usages are still there, perhaps have to be cleaned later:
./ext-src/php_swoole.cc:        SW_FUNCTION_ALIAS(CG(function_table), "swoole_coroutine_create", CG(function_table), "go");
./ext-src/php_swoole.cc:        SW_FUNCTION_ALIAS(CG(function_table), "swoole_coroutine_defer", CG(function_table), "defer");

./ext-src/swoole_server.cc:    SW_FUNCTION_ALIAS(&swoole_timer_ce->function_table, "after", &swoole_server_ce->function_table, "after");
./ext-src/swoole_server.cc:    SW_FUNCTION_ALIAS(&swoole_timer_ce->function_table, "tick", &swoole_server_ce->function_table, "tick");
./ext-src/swoole_server.cc:    SW_FUNCTION_ALIAS(&swoole_timer_ce->function_table, "clear", &swoole_server_ce->function_table, "clearTimer");
./ext-src/swoole_server.cc:    SW_FUNCTION_ALIAS(&swoole_event_ce->function_table, "defer", &swoole_server_ce->function_table, "defer");

Reflection change with this PR
--- /tmp/old	2022-12-21 16:09:14.757429893 +0100
+++ /tmp/new	2022-12-21 16:34:08.664112546 +0100
@@ -1,4 +1,4 @@
-Extension [ <persistent> extension #120 openswoole version 4.12.1 ] {
+Extension [ <persistent> extension #19 openswoole version 4.12.1 ] {

   - Dependencies {
     Dependency [ swoole (Conflicts) ]
@@ -635,7 +635,7 @@
         Parameter #0 [ <required> callable $callback ]
       }
     }
-    Method [ <internal:openswoole> public method swoole_event_add ] {
+    Function [ <internal:openswoole> function swoole_event_add ] {

       - Parameters [4] {
         Parameter #0 [ <required> mixed $sock ]
@@ -645,14 +645,14 @@
       }
       - Return [ int|bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_del ] {
+    Function [ <internal:openswoole> function swoole_event_del ] {

       - Parameters [1] {
         Parameter #0 [ <required> mixed $sock ]
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_set ] {
+    Function [ <internal:openswoole> function swoole_event_set ] {

       - Parameters [4] {
         Parameter #0 [ <required> mixed $sock ]
@@ -662,7 +662,7 @@
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_isset ] {
+    Function [ <internal:openswoole> function swoole_event_isset ] {

       - Parameters [2] {
         Parameter #0 [ <required> mixed $sock ]
@@ -670,20 +670,20 @@
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_dispatch ] {
+    Function [ <internal:openswoole> function swoole_event_dispatch ] {

       - Parameters [0] {
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_defer ] {
+    Function [ <internal:openswoole> function swoole_event_defer ] {

       - Parameters [1] {
         Parameter #0 [ <required> callable $callback ]
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_cycle ] {
+    Function [ <internal:openswoole> function swoole_event_cycle ] {

       - Parameters [2] {
         Parameter #0 [ <required> callable $callback ]
@@ -691,7 +691,7 @@
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_write ] {
+    Function [ <internal:openswoole> function swoole_event_write ] {

       - Parameters [2] {
         Parameter #0 [ <required> mixed $sock ]
@@ -699,72 +699,74 @@
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_event_wait ] {
+    Function [ <internal:openswoole> function swoole_event_wait ] {

       - Parameters [0] {
       }
       - Return [ void ]
     }
-    Method [ <internal:openswoole> public method swoole_event_exit ] {
+    Function [ <internal:openswoole> function swoole_event_exit ] {

       - Parameters [0] {
       }
       - Return [ void ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_set ] {
+    Function [ <internal, deprecated:openswoole> function swoole_timer_set ] {

       - Parameters [1] {
         Parameter #0 [ <required> array $settings ]
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_after ] {
+    Function [ <internal:openswoole> function swoole_timer_after ] {

-      - Parameters [2] {
+      - Parameters [3] {
         Parameter #0 [ <required> int $ms ]
         Parameter #1 [ <required> callable $callback ]
+        Parameter #2 [ <optional> mixed ...$params ]
       }
       - Return [ int|bool ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_tick ] {
+    Function [ <internal:openswoole> function swoole_timer_tick ] {

-      - Parameters [2] {
+      - Parameters [3] {
         Parameter #0 [ <required> int $ms ]
         Parameter #1 [ <required> callable $callback ]
+        Parameter #2 [ <optional> mixed ...$params ]
       }
       - Return [ int|bool ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_exists ] {
+    Function [ <internal:openswoole> function swoole_timer_exists ] {

       - Parameters [0] {
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_info ] {
+    Function [ <internal:openswoole> function swoole_timer_info ] {

       - Parameters [0] {
       }
       - Return [ array|bool ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_stats ] {
+    Function [ <internal:openswoole> function swoole_timer_stats ] {

       - Parameters [0] {
       }
       - Return [ array ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_list ] {
+    Function [ <internal:openswoole> function swoole_timer_list ] {

       - Parameters [0] {
       }
-      - Return [ Ù' ]
+      - Return [ Swoole\Timer\Iterator ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_clear ] {
+    Function [ <internal:openswoole> function swoole_timer_clear ] {

       - Parameters [0] {
       }
       - Return [ bool ]
     }
-    Method [ <internal:openswoole> public method swoole_timer_clear_all ] {
+    Function [ <internal:openswoole> function swoole_timer_clear_all ] {

       - Parameters [0] {
       }

The second commit switches to MINIT standard API (for missing type arg), only for swooole_timer and swoole_event, but can obviously be used for all the sub-init

Notice: same issue affects new version 22.0.0
    Method [ <internal:openswoole> public method swoole_timer_list ] {

      - Parameters [0] {
      }
      - Return [ ^A ]
    }

repo: openswoole/swoole-src


text:
.travis.yml: publish gh releases only once

Was trying to run 'deploy' step after every vector in the matrix.
Now runs deploy step after 'make test-unit' only, so we get basic
checks and quick binary release.

LGTM!
No errors, no warnings. :shipit:

  Generated by :no_entry_sign: Danger

Codecov Report

Merging #802 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #802   +/-   ##
=======================================
  Coverage   52.67%   52.67%
=======================================
  Files         277      277
  Lines       16474    16474
=======================================
  Hits         8677     8677
  Misses       7102     7102
  Partials      695      695

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 6c4089d...c589e23. Read the comment docs.

don't know enough about travis config to see how this will change the publishing of the binary. Will mention @nyarly in that case and see if he has an opinion on it.

@samsalisbury I think all the things now go into the jobs: key, so that the stages can be sequenced reliably. No docs at all about what the order of non-staged work is...

@nyarly many of the documentation examples for jobs/stages use the top-level config followed by the jobs: spec, and run the top-level config first. The top-level stage gets the automatic name "Test", and we can deduce from this documentation that that Test stage is run first by default: https://docs.travis-ci.com/user/build-stages/#specifying-stage-order-and-conditions:

You can specify the order for stages in the section stages: [code example removed for brevity]
This is mostly useful in order to “prepend” a stage to the test stage that jobs resulting from the matrix expansion will be assigned to.

Since Travis documentation is mostly example based and light on explicit specifications, taking the above quote along with empirical evidence seems like a reasonable approach.
We can see empirically that this updated .travis.yml works as expected consistently on this branch, and on all the other open PRs that include these changes. See https://docs.travis-ci.com/user/build-stages/matrix-expansion/ for further example of documentation that shows the default top-level 'test' stage being run first. I don't see explicit mention that this is the case (travis docs are low on precise specs), but since it follows many of the examples in Travis, it seems like a reasonable change, even if it could potentially be improved upon in a future pull request. (We have already discussed improvements like grouping fast tests together in their own stage to fail the build quicker if those tests fail. During that change would be a good time to make the .travis.yml stages config more explicit.)
Since this has been sitting around for a while, and other work touching .travis.yml now sits on top of it, updating this branch prior to merging with master means resolving merge conflicts for little gain (most likely zero behavioural change). Therefore I would rather open a follow-up PR to make stage order more explicit rather than have to deal with these conflicts.

Further delving into the docs suggests the test matrix has to be defined at top-level, so the best we might ultimately be able to achieve is explicit ordering of implicitly named "test" stage; see https://docs.travis-ci.com/user/build-stages/#build-stages-and-build-matrix-expansion

authors: codecov-io lachlanh nyarly samsalisbury sous-machine-account

repo: opentable/sous

license: mit

license_source: bigquery


text:
Create mockups for Mendelian randomisation (MR) data

Mockups required:

[x] Trait page
[x] Gene page

Low fidelity mockups for the trait and gene page with MR data have been created in Balsamiq and are available on the team Google Drive

repo: opentargets/genetics


text:
chore: harmonizing finngen configuration

This is a small PR with the updated configuration for finngen. More details on the paths: #3193

Codecov Report
Attention: 178 lines in your changes are missing coverage. Please review.

Comparison is base (42b366c) 85.67% compared to head (ee37f0d) 86.00%.
Report is 96 commits behind head on dev.

:exclamation: Current head ee37f0d differs from pull request most recent head 26677a0. Consider uploading reports for the commit 26677a0 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #454      +/-   ##
==========================================
+ Coverage   85.67%   86.00%   +0.32%
==========================================
  Files          89       96       +7
  Lines        2101     2629     +528
==========================================
+ Hits         1800     2261     +461
- Misses        301      368      +67

Files
Coverage Δ

src/airflow/dags/common_airflow.py
90.38% <100.00%> (ø)

src/airflow/dags/dag_preprocess.py
100.00% <ø> (ø)

src/airflow/dags/finngen_preprocess.py
100.00% <100.00%> (ø)

src/airflow/dags/gwas_curation_update.py
100.00% <100.00%> (ø)

src/gentropy/__init__.py
100.00% <ø> (ø)

src/gentropy/assets/__init__.py
100.00% <ø> (ø)

src/gentropy/assets/data/__init__.py
100.00% <ø> (ø)

src/gentropy/assets/schemas/__init__.py
100.00% <ø> (ø)

src/gentropy/cli.py
91.66% <100.00%> (ø)

src/gentropy/common/Liftover.py
80.64% <ø> (ø)

... and 81 more

... and 10 files with indirect coverage changes

authors: DSuveges codecov-commenter

repo: opentargets/gentropy


text:
Server side UI framework POC

As the OpenTargets development team, we want to explore the benefits and cons of server-side rendering (SSR) because of our need to improve page loading and SEO capabilities.
Background
We are currently building our UIs using client-side rendering with a standard ViteJS bundler as a single-page application. This technique has some downsides:

Not Search Engine Optimization (SEO)
Initial page load takes quite extra time because JavaScript handles most web page lifecycle-related tasks.

Task
To explore different options for implementing SSR, I encourage you to build a study case using one of our pages platform (either Drug or Disease) and rebuild it using React server-side frameworks. NextJS is a good start since it has been growing fast in the front-end ecosystem.
Note: Be careful with NextJS 13, at the moment, is an unstable version.
Another interesting framework to test is Remix.
References

React rendering techniques: https://dev.to/sjsouvik/rendering-strategies-csr-ssr-ssg-isr-4c5k
NextJS

NextJS Getting stater: https://nextjs.org/docs/getting-started
React Tutorial - Build A Blog With GraphQL and NextJS: https://www.youtube.com/watch?v=Dc7LAgqy1_E

Remix

https://remix.run/docs/en/v1
Why Remix over other React frameworks? https://kentcdodds.com/calls/01/22/why-remix-over-other-react-frameworks

I'll be documenting the process here: https://docs.google.com/document/d/1Ztrcbz7ShgizC8zrnPsYffselKAT2rLNeXWoWO-zRng/

authors: LucaFumis carcruz

repo: opentargets/issues


text:
Creating RDS Instance returns error

command line is:
(venv) [linux@centos-jiangchenxin-troubleshooting ~]$ openstack rds instance create --size 40 --users rdsuser:xxxxx --network_id 34572667-8b21-433d-838d-3f00037331b3  test_rds_jiangchenxin d8661205-929d-a263-6bca-e1100a64fa66
Error message:
'Proxy' object has no attribute 'find_flavor'
I found the find_flavor method is commented here:  https://github.com/OpenTelekomCloud/python-otcextensions/blob/master/otcextensions/sdk/rds/v1/_proxy.py

Sorry for our late response,
Please use API version 3. There you can query the flavor list by using the recommended command
CLI: openstack rds flavor list <db_type> <db_version>
or in SDK
flavors = conn.rds.flavors(datastore_name, version_name)
for flavor in flavors:
    print(flavor)

authors: jcxxin tischrei

repo: opentelekomcloud/python-otcextensions


text:
init bittensor-lm

Adds bittensor-lm (BTLM) to openminers.

As discussed on discord, we will need to modify the process_history here

repo: opentensor/miners


text:
[time-sync] new devices joining a partition can cause the whole partition to lose synchronisation with the leader

Describe the bug
Device(s) holding a higher time sync sequence ID joins a partition. For example, the existing devices have just been been seeded by the leader with a time sync sequence of 10, and the new device(s) are seeding with a sequence ID of 136 as a relic from the previous partition. The existing devices, aside from the leader, accept and distribute the time synchronisation sequence, because they all consider it to be newer (int8_t)(136 - 10) > 0 (see time_sync_service.cpp HandleTimeSyncMessage()). Take the case where the leader on the existing partition remains the same: none of the device(s) that just joined the partition are leaders. Now all devices aside from the leader have a time synchronisation based on the epoch of the previous partition, until the current leader seeds a time synchronisation with a time sequence ID greater than 136. In this case, with a time sync period of 30s, it will take 126 * 30 secs, i.e. 63 minutes before all the devices are in sync with the leader again. In the mean time, all devices aside from the leader will report RESYNC_NEEDED because nobody is actively seeding time sync with the epoch from the previous partition.
To Reproduce
Create a partition consisting of a few devices, their leader will begin seeding a time sync sequence from 0. In the mean time, configure another device and set mTimeSyncSeq in time_sync_service.cpp to be up to 127 greater than the current time sync sequence (use a dev board). This device will attach to the existing partition because it is bigger than the partition of the standalone device, so the leader shall remain the same. Observe the result.
Expected behavior
Perhaps upon joining a new partition, devices should reset their internal copy of mTimeSyncSeq to allow the leader on the partition they are joining to to seed them in all cases instead.

Another, more common scenario, is a recently booted device (therefore with a low sequence number i.e. 3) coming in range of a network currently seeding with a high sequence number (i.e. 131). The fresh device joins and all devices apart from the leader sync to the new device. Synchronisation to the leader is lost again for up to 63 minutes.

@josephn123, thank you for raising this issue.
I agree that a device attaching to a new partition should adopt whatever time sync sequence the partition has.
I also think it might be worthwhile for the Leader to reassert its authority by advancing its time sync sequence if it receives one that is ahead.
Thoughts?
/cc @chshu

@josephn123 Thanks for reporting the issue. And I agree with you and Jonathon's suggestions, following changes may fix the issue:

Once a device attach a new partition, reset its mTimeSyncSeq to OT_TIME_SYNC_INVALID_SEQ (0), then it will accept any time sync sequence from the network.
If the Leader receives a newer time sync sequence (X), Leader updates it's mTimeSyncSeq to be (X + 1), so to keep Leader's time sync sequence always the newest. But keep the network time continuous (without jump).

@josephn123 Would you like to submit the fix?

Thank you both for the feedback and the suggestions. I will work on a corresponding fix.

authors: chshu josephn123 jwhui

repo: openthread/openthread


text:
MbedTls sets Global Allocation Buffers

In the pursuit of getting OpenThread running multiple instances in parallel, I have found a fairly big issue with mbedtls. Take this code for example:
MbedTls::MbedTls(void)
{
    mbedtls_memory_buffer_alloc_init(mMemory, sizeof(mMemory));
}

That sets some global variables to use this class's private memory buffer. When you have multiple instances, they all end up calling this same code. If you happen to bring up a new instance in the middle of the previous one's operation, you completely reset that instance's buffer. Best case, if you bring up all instances at the same time and shut them down at the same time (which is what we do for python cert tests) you now only have 1 buffer's worth of memory to use for all instances, not to mention that you now have two separate threads accessing the same buffer, with no locks. At the current size of 2048 * sizeof(void*) that isn't enough to pass the basic commissioning tests (though upping it to 2500 seems to fix it).
I have looked at mbedtls's code and it is infeasible to change it to support instancing. The only other option I could think of would be somehow correct OpenThread's usage of mbedtls use one global, static buffer or implement the alloc/free functions themselves.
Any thoughts?

I think it makes sense for OpenThread to offer a build option that allows the platform to provide its own implementations of calloc() and free() to mbedtls.  I don't think OpenThread should provide its own alternative implementation of calloc() and free(), unless we can do much better (i.e. significantly reduce memory overhead) than the mbedtls allocator in the single-instance case.

authors: jwhui nibanks


text:
Let platforms specify linker section for version string

PLATFORM_VERSION_ATTR_PREFIX and PLATFORM_VERSION_ATTR_SUFFIX are intended to be used to specify compiler directives to indicate what linker section the platform version string should be stored.
This is useful for specifying an exact location of where the version string will be located so that it can be easily retrieved from the raw firmware image.
If PLATFORM_VERSION_ATTR_PREFIX is unspecified, the keyword static is used instead.
If both are unspecified, the location of the string in the firmware image will be undefined and may change.

Codecov Report

Merging #1334 into master will increase coverage by 1.66%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1334      +/-   ##
==========================================
+ Coverage   68.93%   70.59%   +1.66%
==========================================
  Files         171      171
  Lines       26790    25549    -1241
  Branches     3365     3212     -153
==========================================
- Hits        18467    18036     -431
+ Misses       6910     6162     -748
+ Partials     1413     1351      -62

Impacted Files
Coverage Δ

src/core/openthread.cpp
46.08% <ø> (+8.28%)
:white_check_mark:

src/ncp/ncp_base.cpp
25.6% <ø> (-12.86%)
:x:

...d_party/mbedtls/repo/library/memory_buffer_alloc.c
60.64% <ø> (-1.94%)
:x:

src/core/thread/mesh_forwarder.cpp
75.7% <ø> (-0.36%)
:x:

third_party/mbedtls/repo/library/bignum.c
51.09% <ø> (+0.13%)
:white_check_mark:

src/core/thread/network_data_leader_ftd.cpp
68.24% <ø> (+0.23%)
:white_check_mark:

src/core/thread/mle_router.cpp
79.97% <ø> (+0.43%)
:white_check_mark:

src/core/mac/mac.cpp
79.2% <ø> (+0.45%)
:white_check_mark:

src/core/thread/lowpan.cpp
93.72% <ø> (+0.71%)
:white_check_mark:

src/core/thread/mle.cpp
81.22% <ø> (+0.71%)
:white_check_mark:

... and 3 more

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 87bbf4a...07b6ae8. Read the comment docs.

authors: codecov-io darconeous


text:
[OpenWRT] Update the Makefile and init scripts

Some modifications to make ot-br-posix working with OpenWRT.
Note that it is also compatible with Matter (tested on TE9)
This pull request is related to this issue: https://github.com/openthread/ot-br-posix/issues/1250

Using ot-br-posix on OpenWRT
This document describe how to setup ot-br-posix on OpenWRT. For the example we are using a WRT3200ACM router.
Install OpenWRT on WRT3200ACM
Go to the OpenWRT wiki page about this router and execute the instructions. click here
This example use the release 21.02.3 but you can use a more recent.
SDK Setup

Go to the download page of OpenWRT for the target: https://downloads.openwrt.org/releases/21.02.3/targets/mvebu/cortexa9/.
Download the SDK openwrt-sdk-21.02.3-mvebu-cortexa9_gcc-8.4.0_musl_eabi.Linux-x86_64.tar.xz.
Extract the archive into a folder sdk.
Copy feeds.conf.default to feeds.conf.
Add a new line in feeds.conf: src-link openthread /media/mathieu/data/Projects/ot-br-posix/etc/openwrt.
Update the feeds and install openthread-br:

./scripts/feeds update -a
./scripts/feeds install openthread-br
./scripts/feeds install iptables-mod-extra ipset

NOTE: ipset is required for the firewall feature and iptables-mod-extra is required to get the iptable match pkttype.
7. Configure the SDK (optional):
make menuconfig
# Disable: Global build settings > Cryptographically sign package lists
# Disable: Advanced configuration options (for developers) > Automatic rebuild of packages
# Disable: Advanced configuration options (for developers) > Automatic removal of build directories

Build:

make defconfig
make -j

On the OpenWRT router, create a temporary folder to store the generated packages: mkdir /tmp/pkg.
Transfer the required packages to the router:

scp \
bin/packages/arm_cortex-a9_vfpv3-d16/openthread/openthread-br_1.0-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/libdbus_1.13.12-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/dbus_1.13.12-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/libdaemon_0.14-5_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/libexpat_2.2.10-2_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/libavahi-dbus-support_0.8-7_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/avahi-dbus-daemon_0.8-7_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/packages/libavahi-client_0.8-7_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/base/ipset_7.6-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/base/libmnl0_1.0.4-2_arm_cortex-a9_vfpv3-d16.ipk \
bin/packages/arm_cortex-a9_vfpv3-d16/base/libipset13_7.6-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/librt_1.1.24-3_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/libstdcpp6_8.4.0-3_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/iptables-mod-extra_1.8.7-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/kmod-usb-acm_5.4.188-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/kmod-tun_5.4.188-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/kmod-ipt-extra_5.4.188-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/kmod-ipt-ipset_5.4.188-1_arm_cortex-a9_vfpv3-d16.ipk \
bin/targets/mvebu/cortexa9/packages/kmod-nfnetlink_5.4.188-1_arm_cortex-a9_vfpv3-d16.ipk \
root@192.168.2.1:/tmp/pkg

Install the packages:

opkg install /tmp/pkg/*

The otbr-agent and otbr-firewall serviced are automatically started after install and when the system boot.
Test with Thread client

On the router, create the thread network:

ot-ctl dataset init new
ot-ctl dataset commit active
ot-ctl prefix add fd11:22::/64 pasor
ot-ctl ifconfig up
ot-ctl thread start
ot-ctl netdata register
ot-ctl dataset active -x

On a thread device with ot-cli firmware, Configure it to join the thread network:

dataset set active 0e080000000000010000000300001335060004001fffe00208528351a158b36e550708fd372f9a2edde39e0510730eeb4d8bcf632e2b17c46329f0b394030f4f70656e5468726561642d616662630102afbc0410e5c6daa09b2eb053fa563b6a3db002b00c0402a0f7f8
ifconfig up
thread start
ipaddr

Make sure you can ping the fd11: IP of the thread device from the router.
Make sure you can ping the fd11: IP of the router from the thread device.
Make sure you can ping the fd11: IP of the thread device from your computer (the computer must be connected to a LAN port of the router).

In case of failure at the point #5, use wireshark to check if your computer receive a ICMPv6 message with router advertisement when the thread network is created and make sure your computer accept it.
Test with Matter device
For the test I am using a ǹRF52840 DK with lighting-app example on TE9 tag.

Build and flash the firmware on the device according the the README of the example here.
Commission the device using chip-tool:

./chip-tool pairing qrcode-thread 10 hex:0e080000000000010000000300001335060004001fffe00208528351a158b36e550708fd372f9a2edde39e0510730eeb4d8bcf632e2b17c46329f0b394030f4f70656e5468726561642d616662630102afbc0410e5c6daa09b2eb053fa563b6a3db002b00c0402a0f7f8 MT:6FCJ142C00KA0648G00

Control the device using chip-tool:

./chip-tool onoff toggle 10 1

Update

As suggested by @bukepo : The INFRA_IF_NAME is now configurable by uci
I also made configurable the THREAD_IF_NAME by uci as it is used by two scripts (/etc/init.d/otbr-agent and /etc/init.d/otbr-firewall)

Notes:

At this point it is also possible to make the RADIO_URL configurable through uci.
The file ot-br-posix/src/openwrt/otbr-agent.init.in has executable flag. It is not realy required because during IPK creation the  executable flag is added to the file. This is made by the makefile (ot-br-posix/etc/openwrt/openthread-br/Makefile) when we do $(INSTALL_BIN) (...the file...) (...destination...). I don't change it as I don't know if it's wanted or not. If it's wanted, then otbr-firewall.init.in should have the same flag.
It is also possible to make all uci parameters configurable by web page. (need some work and UI design)

This is how to interact with uci
root@OpenWrt:~# uci show
...
otbr-agent.service=otbr-agent
otbr-agent.service.infra_if_name='br-lan'
otbr-agent.service.thread_if_name='wpan0'
...
root@OpenWrt:~# service otbr-firewall stop
root@OpenWrt:~# service otbr-agent stop
root@OpenWrt:~# uci set otbr-agent.service.thread_if_name=wpan1
root@OpenWrt:~# uci commit otbr-agent
root@OpenWrt:~# service otbr-firewall start
root@OpenWrt:~# service otbr-agent start

Notes:

When uci settings are changed, otbr-agent and otbr-firewall must be restarted for the new settings to take effect.
If you change otbr-agent.service.thread_if_name in uci while otbr-firewall is in execution, then when the process otbr-firewall is stopped it will not be able to cleanup the iptables rules. So it's important to stop the service before changing the uci settings or just reboot. (iptables are cleaned on each boot)

global notes
-- Currently the make-pretty return errors in lot of files that are not impacted by this PR.

Apologies for the bump. Are there any blockers for these changes?
There is an ongoing effort to get otbr properly added to the OpenWRT distro: https://github.com/openwrt/packages/pull/19218
It'd be great to get this PR in, so the downstream package author can rebase their package onto these changes before it lands in OpenWRT.

Currently with my changes there is still some points to check:

I made INFRA_IF_NAME configurable through UCI based on @bukepo suggestion. And I think it should be nice now if it’s also configurable from web ui. But i don’t really know where and how (need ui design ideas/instructions or someone to do it)
I also made configurable THREAD_IF_NAME but i’m not sure if it’s really good because of firewall script issue* and also because in the web ui there are references to “wpan0” statically, so it’s probably not supposed to be configurable. (In such case, I can revert changes about THREAD_IF_NAME). And we can do the same remark as before, it should be good if it’s also configurable from web page..

(*)  The issue with firewall script:

If you change otbr-agent.service.thread_if_name in uci while otbr-firewall is in execution, then when the process otbr-firewall is stopped it will not be able to cleanup the iptables rules. So it's important to stop the service before changing the uci settings or just reboot. (iptables are cleaned on each boot)

I don’t really know if it’s a problem;

The firewall script is supposed to be launched when the system starts to configure iptables. It’s not really supposed to be stopped (like otbr-agent service)
But, if we want there are solutions to fix it, for exemple when the firewall script is started we get the THREAD_IF_NAME info from uci, then we set firewall based on this interface name and we store the interface name in /tmp/(some_file). And when the service is stopped, it will simply read the THREAD_IF_NAME from the file in /tmp instead of uci. This is to prevent problems if user change THREAD_IF_NAME from uci while openthread is running.

I’m going to fix the issue of firewall script soon, but i need some ideas for the points that i mentioned before.

Note that it is also possible to put the content of otbr-firewall script in otbr-agent startup script.
i use two scripts just to keep the same philosophy as what is made for ubuntu/debian

At this point:

INFRA_IF_NAME is configurable with UCI
THREAD_IF_NAME is configurable with UCI
The script otbr-firewall is fixed (in case of THREAD_IF_NAME changes while the script is running, we can still stop it and remove ipset rules)

Remaining work:

(optionnal) : Make INFRA_IF_NAME and THREAD_IF_NAME also configurable from the web page. (need ui design ideas/instructions or someone to do it)
In the web page there are references to "wpan0" statically (src/openwrt/view/admin_thread/thread_overview.htm), it should be good to display the correct interface name, depending on the interface used by otbr-agent. This point is not necessary related to this PR.

authors: LorbusChris caipiblack

repo: openthread/ot-br-posix


text:
chore: remove header-list and toolbar-tip internal dependencies

PR
PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our Commit Message Guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] Build related changes
[ ] CI related changes
[x] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information
请先合并 #176 以保证此 pr 没有冲突
内部存在两处硬编码(搜索TODO可查看)，之后可再寻找其他解决方案

Summary by CodeRabbit
Based on the comprehensive changes across multiple files, here are the release notes:

Documentation

Replaced 'Header List' documentation with 'Other Modules' documentation
Added documentation for new modules: quill-header-list and quill-toolbar-tip

New Features

Introduced enhanced internationalization (i18n) module
Added support for new toolbar tip and header list functionalities

Dependencies

Removed quill package
Added quill-header-list and quill-toolbar-tip packages

Refactoring

Restructured language handling in editor configuration
Updated event handling mechanisms
Simplified toolbar and language configuration

Chores

Updated package dependencies
Cleaned up unused imports and modules

@zzxming 这个PR包含了 PR #176 中的提交，PR #176 已合入，应该移除这部分。

@zzxming 其实我觉得这两个模块demo可以平铺出来，不用移除之前的demo，使用者一般只关注功能，我们的demo只需要把功能演示清楚即可。
后续可以再做一个 API 文档，用来呈现全部的 API 和模块说明等。

两个模块demo可以平铺出来，不用移除之前的demo，使用者一般只关注功能，我们的demo只需要把功能演示清楚即可。

保留了之前的 demo，新增一个 demo 用于演示 toolbat-tip 功能

authors: kagol zzxming

repo: opentiny/fluent-editor


text:
🐛 [Bug]:  lowcodewrap 多余的参数

Environment
windwos11
Version
16
Version
最新
Link to minimal reproduction

Step to reproduce

What is expected
No response
What is actually happening
No response
Any additional comments (optional)
No response

@yaoyun8 帮忙看一下

@ArtisanQ 1. lowcodeWrap第三个为多余参数，待修改；2. stores为全局状态，在调用wrap({ stores })后，可以在warp返回的函数中使用this.stores

authors: ArtisanQ wenmine yaoyun8

repo: opentiny/tiny-engine


text:
✨ [Feature]: 需要在工具类方法中能够存取stores的变量

What problem does this feature solve
如题， 在公用方法中能存取公用变量。
What does the proposed API look like
如上

@stwflyfox 已收录，回头内部梳理一下优先级排期，若是你感兴趣的话也欢迎参与共建呀~

authors: stwflyfox wenmine


text:
Cycloid company - Signing manifesto

Signing manifesto on behalf of Cycloid company

Added in https://github.com/opentofu/manifesto/pull/1137

authors: Seraf flavius-dinu

repo: opentofu/manifesto


text:
Hystrix uses RxJava

Because Hystrix internally uses RxJava it introduce some problems.
If RxJava instrumentation is enabled (via auto configuration) then Hystrix (and feign-hystrix) traces include RxJava spans.
All hystrix-feign tests fails because instead of one finished spans there tens of finished spans.

I think we can discuss this on #7. In sleuth there is an option which disables tracing of specific threads.

authors: malafeev pavolloffay

repo: opentracing-contrib/java-spring-cloud


text:
C API wrapper proposal

Motivation covered in #26. Similar to LevelDB C API wrapper.

Thanks @isaachier. You might also want to post it to the opentracing-cpp gitter channel.
One question I have: If someone wanted to use tracers that were completely written in C as opposed to using this as a bride to the C++11 API, does this still give them a way to customize the tracer used?

@rnburn that is a much more difficult proposal. It would probably need another project opentracing-c. If anything, the C++ API should implement/extend the C API if that were the goal.

What I'd really like to see for C and C-derived OT APIs is a specification for dlopening tracers, so that we can get e.g. nginx (C) to buy-in just once to OT, and then not have to rebuild it to use different tracer implementations. Perhaps the C++ bindings already permit that.

@rbtcollins There's another issue (#28) to discuss just that.
The current instrumentation for nginx doesn't require you to rebuild nginx for each tracer as it uses nginx's dynamic modules, but there is some configuration overhead that we're trying to remove with dlopen conventions for tracers.

I would say there is at least a hint to this issue in the C API I proposed here. When it comes to initializing a global tracer, there is no way to specify this properly in C. That is why I left it as TODO. The dlopen solution would potentially resolve this.

For those looking for a true C implementation of the OpenTracing model, I would say gRPC's Census library comes pretty close to the specification (if not completely fulfills it). Take a look here: https://github.com/grpc/grpc/tree/master/src/core/ext/census.

The difficulty with wrapping the API stems from a few issues relating to ownership. One difficulty is that I cannot copy any of the classes because there is no clone method for me to use. I'm starting to wonder what a pure C API would look like. It seems the main consumers of pure C would much rather have the implementation be pure C as well.

I think you could fix most of the ownership issues by just changing opentracing_tracer_t to
struct opentracing_tracer_t {
     std::shared_ptr<opentracing::Tracer> impl_;
 };

Hey @heyleke, @jcchavezs -- you guys have asked about a C API before. Would something like this work for you?

Maybe... I'll get back to this soon enough. Thank you for reviewing it.

I am in!

@jcchavezs Could you describe your use case? I'm curious what types of projects would benefit from this API.

@jcchavezs I am also curious to hear. Meanwhile, what motivated me was to ease the process of wrapping/binding other languages to a C/C++ implementation. That way, an implementation need only follow the opentracing-cpp specification, and benefit from a version in Python, Ruby, JavaScript, etc. with no additional code (or minimal code for each).

@rnburn  I'm following this with great interest. Although this approach will probably not solve the biggest issue in our use case: C++11 support in toolchain is still required. But having a start towards a C api to start with is already something, I also read about the census implementation which could be useful to create a pure C implementation if we can't solve the C++11 support.
So, the main use case are:

pure C applications, but linking to C++ is still possible in that case
environments lacking C++ or C++11 support.
(although I have to admit in 2017 you should be capable of doing C++11 in your toolchains ;-) )

Already alot of thx to @isaachier for bringing this on the table. I hope to become more active in this area in the near future.
Btw, if there one day would be a pure c implementation, I would call it opentracing-C99 if it would be pure C99 (e.g.)
And the C 'wrapper' would reside in the opentracing-cpp(11) repo.
Are there any pure C tracers that this would be testable with (with some modifications)? lightstep?

I just submitted a new version in pure C. As of now uses C11, although that
is just for the single atomic pointer used to store the global tracer.
On Oct 27, 2017 5:48 AM, "Jan Heylen" notifications@github.com wrote:
@rnburn https://github.com/rnburn I'm following this with great interest.
Although this approach will probably not solve the biggest issue in our use
case: C++11 support in toolchain is still required. But having a start
towards a C api to start with is already something, I also read about the
census implementation which could be useful to create a pure C
implementation if we can't solve the C++11 support.
So, the main use case are:

pure C applications, but linking to C++ is still possible in that case
environments lacking C++ or C++11 support.
(although I have to admit in 2017 you should be capable of doing C++11
in your toolchains ;-) )

Already alot of thx to @isaachier https://github.com/isaachier for
bringing this on the table. I hope to become more active in this area in
the near future.
Btw, if there one day would be a pure c implementation, I would call it
opentracing-C99 if it would be pure C99 (e.g.)
And the C 'wrapper' would reside in the opentracing-cpp(11) repo.
Are there any pure C tracers that this would be testable with (with some
modifications)? lightstep?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opentracing/opentracing-cpp/pull/27#issuecomment-339926446,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACdXeWWf1WyxQLENgubMhV_O_CgChI2jks5swabagaJpZM4QE4BJ
.

@heyleke - Could you use a C API wrapper if the C++11 tracer and opentracing libraries were cross compiled and distributed as binaries?

If I understand correctly, the answer would be no. Certain platforms just don't have good support for C++11 (in my experience AIX and Solaris).

The native compilers for those OSs might have somewhat flaky C++11 support, but GCC/Clang support cross compiling to most of the widely used architectures/environments.
I believe he has an embedded target. I'm wondering if packages build with something like ellcc might solve the problem.

Any idea what to do with this issue or should I just close it?

I'd like to have more input from stakeholders and some example project instrumentations before going forward with something for C.
I expect there are some projects that would need a C API, but I don't think there's that many. The major C projects that I've looked at so far (NGINX, Varnish, HAProxy) can all be instrumented with the C++ API by just providing some extern "C" hooks.

Ya that's my feeling. The C problem is interesting but might be a separate project.

authors: heyleke isaachier jcchavezs rbtcollins rnburn

repo: opentracing/opentracing-cpp


text:
[SECURITY] Use HTTPS to resolve dependencies in Maven Build

Want to take over the Java ecosystem? All you need is a MITM!
Update: Want to take over the Java ecosystem? All you need is a MITM!

This is a security fix for a  vulnerability in your Apache Maven pom.xml file(s).
The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS.
This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.
This vulnerability has a CVSS v3.0 Base Score of 8.1/10.
POC code has existed since 2014 to maliciously compromise a JAR file in-flight.
MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.
This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.
Detecting this and Future Vulnerabilities
This vulnerability was automatically detected by LGTM.com using this CodeQL Query.
As of September 2019 LGTM.com and Semmle are officially a part of GitHub.
You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.
I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.
Source
Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.
The source code that generated and submitted this PR can be found here:
JLLeitschuh/bulk-security-pr-generator
Opting-Out
If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called
.github/GH-ROBOTS.txt to your repository with the line:
User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.
Alternatively, if this project is no longer actively maintained, consider archiving the repository.
CLA Requirements
This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.
It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin
(see https://developercertificate.org/ for more information).
- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.
Tracking
All PR's generated as part of this fix are tracked here:
https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2

Coverage remained the same at 76.586% when pulling 798b9787af935ae4f4417ac12863c6d09213b966 on JLLeitschuh:fix/JLL/use_https_to_resolve_dependencies into d74e4675a1822c2549ba26c6d67c9fa033e1813b on opentracing:master.

authors: JLLeitschuh coveralls

repo: opentracing/opentracing-java


text:
🛑 [CN] OpenUPM Registry /-/all is down

In 30c613f, [CN] OpenUPM Registry /-/all (https://package.openupm.cn/-/all) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Registry /-/all is back up in 4e23134 after 9 minutes.

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website Docs is down

In 9726899, [CN] OpenUPM Website Docs (https://openupm.cn/docs/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in 25e8232.


text:
🛑 [CN] OpenUPM API /feeds/updates/rss is down

In 3947d9a, [CN] OpenUPM API /feeds/updates/rss (https://api.openupm.cn/feeds/updates/rss) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM API /feeds/updates/rss is back up in a6577ff.

repo: openupm/upptime


text:
[NVIDIA] Add ov::Exception wrapper

Add ov::Exception wrapper to access its protected constructor.

build_jenkins

Blocks https://github.com/openvinotoolkit/openvino/pull/22680

authors: p-durandin t-jankowski


text:
[81845] Erase Environments files

OpenVINO Deep Learning Workbench Pull Request
All Submissions:

[x] Create a meaningful name of the PR with reference to JIRA. Example: [43714] [NIGHTLY] Take correct tag for snyk scans
[x] JIRA tickets:

81845

[x] Set assignee to the PR.
[x] Add corresponding labels to the PR.
[x] Set appropriate milestone to the PR.
[x] Added tests for new functionality (unit / e2e)
[x] Followed code style guidelines:

Code covered with typings
No debug printing in production code
No commented blocks of code in production code

Available commands in pull request comments

/bump:client - bump to latest master branch in client submodule
/bump:client:releases/2021/4 - bump to latest releases/2021/4 branch in client submodule
/bump:client:yatarkan:feature/yt/feature-name - bump to latest feature/yt/feature-name branch from yatarkan remote fork in client submodule
/update - merge base (target) branch into target branch and push changes

NOTE:
For more details, please visit the DEVELOPER.md

Was merged as a part of #11

repo: openvinotoolkit/workbench


text:
rename ovn-node container to ovnkube-node

The container for the ovnkube in master mode is called ovnkube-master, however the ovnkube in node mode is called ovn-node. I think it should be ovnkube-node. Using this name is not only consistent with how we name the master node but also clearly says that it is nothing to do with the OVN components from openvswitch.org (ovn-controller, ovn-northd, ovn-ctl and so on). It clearly indicates that it is OVN K8s CNI artifact.

@pecameron @dcbw @rajatchopra any comments on this?

@girishmg I picked the name somewhat randomly. ovnkube-node makes sense to me for reasons you articulate.

Included among changes in PR 559

authors: girishmg pecameron

repo: openvswitch/ovn-kubernetes


text:
Failed to install the app

Recently while testing wallet app, I encounter an error while "yarn run android" command. Following is the error i am getting, please let me know if anyone know the solution for the same.:
error Failed to install the app. Command failed with exit code 1: gradlew.bat tasks
Exception in thread "main" javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:349) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:292) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:287) at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1356) at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1231) at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1174) at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443) at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:182) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:171) at
How can this error be resolved?

Make sure you have the right version of Java, check the GitHub action workflows in the .github folder for the exact version of Java to use.

repo: openwallet-foundation/bifold-wallet


text:
update download links

Some of the links are 404.
Command Line Tools for Linux
GNU tool chain for Linux.
Havent checked Mac.

Fixed in commit 0b6bcaff73416ce9fd4fb742ce7384a395210dfa


text:
Invoke  just hangs

I have a very simple hello world action. I can attach to it, but nothing happens when I try to invoke it:

Scotts-MacBook-Pro:openwisk scottchapman$ wskdb MyTest
Welcome to the OpenWhisk Debugger
Attaching to MyTest
Creating action trampoline
ok
(wskdb) invoke MyTest

I was going to take a gander at it tomorrow but I think it is out of my wheelhouse. This something you can address?

There are two references that need to change:
https://github.com/openwhisk/openwhisk-debugger/blob/master/invoker/owdbg-invoker.js#L42
https://github.com/openwhisk/openwhisk-debugger/blob/master/invoker/owdbg-invoker.js#L72
whisk.getAuthKey should be changed to process.env.$__OW_AUTH_KEY.

I made both those changes to my locally installed version and it didn't have any effect.
I do see two actions get created; both are named "debug ..." so I think the credential handling looks OK.

authors: ScottChapman rabbah

repo: openwhisk/openwhisk-debugger


text:
Remove whisk object from node.js

The global object whisk had been deprecated and will now be removed.
migrate your nodejs actions to use altenative methods. For the functions whisk.invoke() and whisk.trigger() use the already installed client library openwhisk. For the whisk.getAuthKey() you can get the API key value from the environment variable __OW_API_KEY. For the whisk.error() you can return a rejected Promise (i.e. Promise.reject).

pg2#1076

pg3 282

pg2#1080

authors: bjustin-ibm jasonpet

repo: openwhisk/openwhisk