text:
Document remaining obsolete SSL_OP_NETSCAPE_*_BUG

SSL_OP_NETSCAPE_CA_DN_BUG became obsolete in 3c33c6f6b1086435 and support for SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG was removed by 7a4dadc3a6a487db. The definitions are still listed under "OBSOLETE OPTIONS retained for compatibility" in ssl.h.in, so this commit adds them to the list of obsolete options in doc/man3.
Refs: https://github.com/nodejs/node/pull/46954

Checklist

[x] documentation is added or updated

This pull request is ready to merge

Merged, thanks for the fix.

authors: openssl-machine paulidale tniessen


text:
Configure option 'no-deprecated' means '-DOPENSSL_API_COMPAT=0x10100000L'

(that is, until 1.2.0 comes along)
Since we allow future deprecation (and that shouldn't be affected
by 'no-deprecated'), we need to distinguish what to have deprecated
on the value of OPENSSL_API_COMPAT, not the existence of
OPENSSL_NO_DEPRECATED.
Note that the macro OPENSSL_NO_DEPRECATED still exists, in case
someone still uses it.

There's no need to backport this to 1.1.0, since future deprecation didn't exist there.

#6467 is dependant on this PR - so please ping that one when you merge this.

Merged.
a9091c137bb21a247afa01ecf17bd5c75d9b0e65 Convert our own check of OPENSSL_NO_DEPRECATED
973abf52304b454e8f2220a11aa8b6c6512c44fb Configure option 'no-deprecated' means '-DOPENSSL_API_COMPAT=0x10100000L'

source: gharchive/pull-request

authors: levitte mattcaswell

repo: openssl/openssl

license_type: permissive

license_source: github-api


text:
Shared github workflows and operator-sdk 1.31

This PR switches the operator to use shared build workflows for building operator, bundle, and catalog/index images.
Additionally operator-sdk is bumped to 1.31. (also includes bump to OPM and controller-gen)
Jira: OSP-29146
Jira: OSP-26858

/retest

/test manila-operator-build-deploy-kuttl

/test manila-operator-build-deploy-tempest

/test manila-operator-build-deploy-tempest

/test manila-operator-build-deploy-tempest

/test manila-operator-build-deploy-tempest

/test manila-operator-build-deploy-tempest

authors: dprince fmount gouthampacha


text:
Remove endpoint url and keystone service id from status

These items presented in CR status are not really used. Endpoints can be discovered using Keystone and we have no use case to require service id.
This also removes a separate registerInKeystone function to make the code structure more consistent with the other operators.

@kajinamit: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
Test name 	Commit 	Details 	Required 	Rerun command
ci/prow/octavia-operator-build-deploy-kuttl 	7b966db link 	true 	/test octavia-operator-build-deploy-kuttl
Full PR test history. Your PR dashboard.

The KUTTL tests are having problems here:
logger.go:42: 10:21:46 | octavia_scale/1-deploy-octavia | running command: [sh -c regex="http:\/\/octavia-public-openstack\.apps.*"
        apiEndpoints=$(oc get route -n $NAMESPACE octavia-public -o jsonpath='{.status.ingress[0].host}')
        matches=$(echo $apiEndpoints | sed -e "s?$regex??")
        if [ -z "$matches" ]; then
          exit 0
        else
          exit 1
        fi

I think getting the host from the Route means that there is no longer a pre-pended http://:
$ oc get route -n openstack octavia-public -o jsonpath='{.status.ingress[0].host}'
octavia-public-openstack.apps-crc.testing

So I think the regex needs to change.

I tested this locally and removing http:\/\/ did in fact work.

Oh, yes. Thanks for catching it @abays !

authors: abays kajinamit


text:
we should not default to any iamge form the redhat regeistry as the operators shoudl be deployable without a pull secret

https://github.com/openstack-k8s-operators/openstack-operator/blob/be3d3c851b83ce01e7f0f4cf8a9bf13e764901f1/pkg/openstack/rabbitmq.go#L81
we shoudl not be defaulting to images form the redhat registry for any service images
they should be using the image from tripleo/tcib/quay
this should be using quay.io/tripleozedcentos9/openstack-rabbitmq:current-tripleo
until we swap to using the new tcib images.

the new tcib image is here
quay.io/podified-zed-centos9/openstack-rabbitmq:current-podified

I have actually brought up the idea that we do a lot more of this. As this is mostly a RH project ATM and we only use OpenShift one could take the position that a pull secret is a fine requirement.
That said I'm open to using a new container image for rabbit assuming it matches the downstream requirements (interfaces). @jeckersb is there such an image?
In the meantime, this project isn't tracking things in github issues/aside from Renovatebot. So going to close this and we can follow up with a Jira.

source: gharchive/issue

authors: SeanMooney dprince


text:
adds a place=city_block preset

fix for #5425

Thanks @wvanderp 👍

authors: bhousel wvanderp

repo: openstreetmap/iD

license: ISC


text:
add scheme to replace parking:lane:side=parallel/diagonal/perpendicular

Deprecated OSM Tag(s)
parking:lane:side=parallel/diagonal/perpendicular
Replacement OSM Tag(s)
parking:side=lane; parking:side:orientation=parallel/diagonal/perpendicular
Link to OSM Wiki page
https://wiki.openstreetmap.org/wiki/Street_parking
old scheme: https://wiki.openstreetmap.org/wiki/Key:parking:lane
Further Information
No response

If this is something that would be merged we can add a few others as well.
In the meantime there is https://github.com/osmberlin/osm-tag-updater and the Zlant editor has a updater integration (well hidden behind the 🔄 icon).

The implementation of tag deprecation rules here does not scale up super well if there are many versions of a tag to be considered… I'd say that adding these 9 cases would be fine, but (much) more than that would be a stretch.
@tordans Do you think you could provide the "business logic" part of the @osmberlin/osm-tag-updater as an npm module? Because, then I could quite easily build that completely into iD directly as a dedicated validation module.

So I will now make a PR for the mentioned 9 cases?

But, from a technical standpoint, I have to note that the implementation of tag deprecation rules here does not scale up well if there are many versions of a tag to be considered… I'd say that adding these 9 cases would be still fine, but (much) more than that would be a stretch.

The proposal lists some data at https://wiki.openstreetmap.org/wiki/Proposal:Street_parking_revision#Numbers_of_usage_of_the_current_schema

Currently (as of the end of October 2022), about 260.000 road segments in OSM have "primary" parking lane tagging (parking:lane:both=, parking:lane:left= or parking:lane:right=*), (…)

All other old tags are tags are well below the 50k mark, so I think we should ignore those for deprecation rules.
Following this logic, we could add a deprecation rule for those cases:
Source: https://osmberlin.github.io/osm-tag-updater/#/list
Old tagNew tag (maybe missing fields)Compare typeOptional messageparking:lane:{SIDE}=yesparking:{SIDE}=yestagparking:lane:{SIDE}=separateparking:{SIDE}=separatetagparking:lane:{SIDE}=parallelparking:{SIDE}:orientation=paralleltagparking:lane:{SIDE}=diagonalparking:{SIDE}:orientation=diagonaltagparking:lane:{SIDE}=perpendicularparking:{SIDE}:orientation=perpendiculartagparking:lane:{SIDE}=marked ==> Not this one, too complex[
  "parking:{SIDE}:markings=yes",
  "fixme=Please provide the orientation of parked cars with parking:{SIDE}:orientation=parallel|diagonal|perpendicular"
]{
  "key": "parking:{SIDE}:orientation",
  "values": [
    "parallel",
    "diagonal",
    "perpendicular"
  ],
  "msg": "Please provide the orientation of parked cars. This information was not recorded previously, which is one of the benefits of the new schema."
}tagparking:lane:{SIDE}=noparking:{SIDE}=notagparking:lane:{SIDE}=no_parking[
  "parking:{SIDE}=no",
  "parking:{SIDE}:restriction=no_parking"
]tagparking:lane:{SIDE}=no_standing[
  "parking:{SIDE}=no",
  "parking:{SIDE}:restriction=no_standing"
]tagparking:lane:{SIDE}=no_stopping[
  "parking:{SIDE}=no",
  "parking:{SIDE}:restriction=no_stopping"
]tagparking:lane:{SIDE}=fire_lane[
  "parking:{SIDE}=no",
  "parking:{SIDE}:restriction=no_stopping",
  "parking:{SIDE}:restriction:reason=fire_lane"
]tag

@tordans Do you think you could provide the "business logic" part of the @osmberlin/osm-tag-updater as an npm module? Because, then I could quite easily build that completely into iD directly as a dedicated validation module.

In Theorie, yes. However, the app is not prepared for this (no NPM package) and some functions are not exposed properly, yet (the output is constructed during render ATM). It is not just the input-output-migration, but also warnings and notices that need to be added to the UI to make this a propper integration. The Zlant Editor Integration (https://github.com/zlant/parking-lanes) only does parts of what the  osmberlin/osm-tag-updater does, which is not ideal, since information gets lost… (but still, its great to have it in there, for advanced users…).
The main reason why we did not invest more time in this is, that we assume that those old should be migrated while also manually reviewing the data. And the parking lane layer for StreetComplete (which also understand the most important old tags) can be used to migrate the data quite well.

@tiptoptom:

So I will now make a PR for the mentioned 9 cases?

I general +1. But I think your migration is wrong. Using https://osmberlin.github.io/osm-tag-updater/#/manual I get
INPUT

parking:lane:right=perpendicular
OUTPUG
parking:right:orientation=perpendicular

But your PR suggest

"parking:right": "perpendicular"

@tordans of course you are right. I will add the "orientation" and also "parking:side=lane". And your tags maybe as well?

authors: tiptoptom tordans tyrasd

repo: openstreetmap/id-tagging-schema


text:
[BUG] 编辑器中标签不能正常匹配

描述你的问题（Describe the bug）

复现路径（To Reproduce）

打开一个带有花括号的文件
光标移到花括号上，对应的花括号不会显示

预期表现（Expected behavior）

问题截图（Screenshots）

环境信息（Environment）

OS: Mac
Browser: Electron / Web
OpenSumi Version: 2.20.2

补充信息（Additional context）

https://github.com/opensumi/monaco-editor-core 用这个测试 monaco-core-0.35.x 分支，是有花括号的

repo: opensumi/core

license: MIT


text:
[OSDEV-633] Make it easier to search for groups of related sectors UI part

OSDEV-633 Facility Search. Make it easier to search for groups of related sectors (UI).
Added a nested select to the Sectors filter. The main selection is the group name of related sectors. By pressing the header, a user can select all related sectors from this group. To view the list of related sectors, it's necessary to press the "carrot" icon next to the group heading. This action allows a user to choose a single sector from the grouped list. Additionally, entering text into the search filter displays only the filtered sectors within the opened groups.
Modified the sectors endpoint to return either a list of sectors or sectors grouped by their sector groups, depending on the query parameters passed to the request. Possible parameters include:
- embed (optional): If present, returns a flat list of sectors submitted by a specific contributor.
- contributor (optional): If embed is provided, this parameter must be included to filter sectors submitted by a specific contributor.
- grouped (optional): If present, returns sectors grouped by their sector groups.

Notice: During the implementation, of test cases to cover changed FE components, I faced the same problem that @VadimKovalenkoSNF described https://github.com/opensupplyhub/open-supply-hub/pull/262#issuecomment-2219857805.

Probably we need Frontend tests of components that was implemented. In general all other LGTM

I have tried to cover FE components by tests, but unfortunately faced the same problem that @VadimKovalenkoSNF described https://github.com/opensupplyhub/open-supply-hub/pull/262#issuecomment-2219857805described.
I believe it should be a separate task to investigate how to implement test cases for components that contain ReactSelect.

@mazursasha1990 Shall this sorting be appied on the side filter as well?

@mazursasha1990 Shall this sorting be appied on the side filter as well?

@VadimKovalenkoSNF The sector grouping was implemented to the side search as well. I don't know why you see the different results. Maybe, you forgot to update the page after changing the branch...
Please recheck it.

The sector grouping was implemented to the side search as well.

@mazursasha1990 It's weird, now I see it. Thanks.

repo: opensupplyhub/open-supply-hub


text:
Update HPA mapping

When running the HPA step (18.12) the following messages are output:
2019-01-09 13:26:11,591 - mrtarget.modules.HPA - WARNING - the tissue name abdomen was not found in the mapping
2019-01-09 13:26:11,592 - mrtarget.modules.HPA - WARNING - the tissue code abdomen was not found in the mapping
2019-01-09 13:26:20,586 - mrtarget.modules.HPA - WARNING - the tissue name lactating breast was not found in the mapping
2019-01-09 13:26:20,586 - mrtarget.modules.HPA - WARNING - the tissue code lactating breast was not found in the mapping
2019-01-09 13:26:31,409 - mrtarget.modules.HPA - WARNING - the tissue name thymus was not found in the mapping
2019-01-09 13:26:31,410 - mrtarget.modules.HPA - WARNING - the tissue code thymus was not found in the mapping
2019-01-09 13:28:25,696 - mrtarget.modules.HPA - WARNING - the tissue name choroid plexus was not found in the mapping
2019-01-09 13:28:25,696 - mrtarget.modules.HPA - WARNING - the tissue code choroid plexus was not found in the mapping
2019-01-09 13:32:23,845 - mrtarget.modules.HPA - WARNING - the tissue name sole of foot was not found in the mapping
2019-01-09 13:32:23,845 - mrtarget.modules.HPA - WARNING - the tissue code sole of foot was not found in the mapping
This suggests that the mapping file needs to be updated.

@cmalangone do you know whether these mappings are still missing? If yes, it would be good to figure out how to update the mapping file.

@MichaelaEBI : the mappings are still missing.

@AsierGonzalez
From a previous discussion, the issue appears to be due to a mapping file (list of tissue names) and uberon & cl ontology names codes which were manually curated at the time and may now be out of date. Take a look at page 4 for the HPA mapping files: https://docs.google.com/document/d/1_40Knrsf69bHPVEzTYZVMyHhhabhSEYzO5u7wf1X84M/edit#

As reported by @cmalangone , these are the tissues that are not present in the above-mentioned mapping file:
"cartilage",
  "choroid plexus",
  "dorsal raphe",
  "sole of foot",
  "thymus"

The data team is scoping for 21.11 to review this part of the process.

This is related to baseline expression, still relevant.

Closing due to change of scope of this data. A new schema for baseline expression will be proposed.

authors: MichaelaEBI afaulconbridge cmalangone ireneisdoomed ktsirigos smnorthen

repo: opentargets/issues


text:
Investigate genome browser issue

Further details TBC but initial review notes below:

Could it be an issue with the cttv_gwas, specifically lines 285-286 - are some SNPs dropped and not sent in the ensembl_call_snps API call?
Also worth looking at gwas_updater and common

Upon further review of the targetGenomeBrowser repo, there are two specific issues that have been identified.
Issue 1: Not all variants are shown in the browser
* Note: the browser view is not connected to the data displayed on the data table as they rely on different API calls and the logic that processes the data is different, as noted below
As noted in the NOD2 and IBD example on QA, not all of the variants are visible in the genome browser. This is because not all variants are requested and sent to Ensembl.
The genome browser logic is "target-centric" and it takes all of the genes found within the browser window and makes a call to our /evidence/filter API endpoint for any ot_genetics_portal or phewas_catalog data regardless of disease. The browser then parses this response for the variants and generates a list that it uses to call the Ensembl /variation/human API endpoint. The browser then uses the Ensembl response to generate the variant lollipops and position the tooltips.
For the majority of cases, this logic works fine. But when viewing a dense region of the genome, not all variants are returned from the initial call to our /evidence/filter API endpoint - and therefore, are not included in the call to Ensembl.
So in the NOD2 and IBD example on QA, we send the following 48 gene IDs to our /evidence/filter API endpoint:
0: "ENSG00000205423"
1: "ENSG00000259843"
2: "ENSG00000261835"
3: "ENSG00000273829"
4: "ENSG00000260298"
5: "ENSG00000155393"
6: "ENSG00000279356"
7: "ENSG00000202124"
8: "ENSG00000260381"
9: "ENSG00000287444"
10: "ENSG00000260031"
11: "ENSG00000252526"
12: "ENSG00000121274"
13: "ENSG00000121281"
14: "ENSG00000274969"
15: "ENSG00000166164"
16: "ENSG00000261393"
17: "ENSG00000261092"
18: "ENSG00000260573"
19: "ENSG00000140807"
20: "ENSG00000260029"
21: "ENSG00000278909"
22: "ENSG00000205414"
23: "ENSG00000260249"
24: "ENSG00000167208"
25: "ENSG00000167207"
26: "ENSG00000270120"
27: "ENSG00000261644"
28: "ENSG00000083799"
29: "ENSG00000264947"
30: "ENSG00000260616"
31: "ENSG00000261703"
32: "ENSG00000261241"
33: "ENSG00000260042"
34: "ENSG00000199771"
35: "ENSG00000261637"
36: "ENSG00000260605"
37: "ENSG00000260620"
38: "ENSG00000287718"
39: "ENSG00000261282"
40: "ENSG00000103449"
41: "ENSG00000261238"
42: "ENSG00000285367"
43: "ENSG00000280344"
44: "ENSG00000287256"
45: "ENSG00000261047"
46: "ENSG00000260818"
47: "ENSG00000260850"

The response to this call is capped at 1,000 but the API notes that we have 1,867 records:

If you alter the call and obtain all records, you will find all of the correct variants, including the ones identified by @DSuveges as missing in the browser view.
However, this can cause performance issues as the various API calls are chained together. So if it takes longer to call our /evidence/filter API endpoint and process that data, it delays the call to the Ensembl API - and this call is limited to 200 variants per API call.
Issue 2: Browser not correctly labelling variants
In cases where the browser works as intended and displays the relevant variants, there are examples where the variant lollipops are not correctly coloured red or dark cyan.
For example, in the case of CCND1 and multiple myeloma, rs9344 should be coloured red as multiple myeloma is one of the associated diseases shown in the tooltip.
It looks as though the logic in the foreground_colour function is not properly assigning the colours. In this case, it appears that the gB.gene() === d.target.geneid conditional check on line 271 fails but it passes the d.highlight check on line 273 - hence the dark cyan colour.
I believe that it fails because the variant - rs9344 - has been "assigned" to both CCND1 and LTO1 (the other target visible in the browser on the right-hand side) based on the Open Targets Genetics Locus2Gene scoring pipeline. Because there are entries where the d.target.geneid === CCND1 and d.target.geneid === LTO1, the widget incorrectly assigns the colour when it encounters an entry where d.target.geneid === LTO1.

After reviewing the issue further, I am going to recommend that we do not make any changes to the existing visualisation for 20.04 or 20.06. Long-term, we should do one of the following:

Drop the browser view from the evidence page
Consider another alternative (e.g. locus plot in Genetics Portal but it does not have the rare variant track)
Invest in expanding the browser so that it can account for the differences brought on because of the Open Targets Genetics Portal data while reducing the number of API calls made and potentially the scope of the call (e.g. to just the gene in question rather than all genes in the browser view)

As noted in my comment above, the increase in evidence strings from the Open Targets Genetics Portal means that we will have more cases like NOD2 and IBD where the browser does not load all the variants because not all variants are requested in our API call. While we could increase the call to 2000 evidence strings, this will have unintended performance consequences on the evidence and target profile pages in both the Angular and React applications. And it will make the BRCA2 browser issue more widespread and will also increase the number of targets and evidence pages where the Ensembl calls fails the first time it is made - but then works if the user refreshes the page.
It is also worth noting that increasing the size of the call will not resolve the issue entirely. If we do not have an RSID for the evidence string (e.g. ERLIN1 in lean body mass, the Ensembl API returns no data for that variant and there is no variant lollipop in the browser.
Also, the logic that categorises and colours the variant lollipops does not work as intended because a variant can have multiple assigned genes depending on the L2G pipeline. If the variant only ever has one gene, as was the case with GWAS Catalog data and the closest gene assignment, then the logic would work properly. Rewriting this logic to account for multiple assigned genes for one variant would take considerable time because the application would have to store details about the variant and refer to this as it iterates through the variants returned in the evidence strings.

Issue closed as broader discussion about use case for genome browser would help decide which option to select

repo: opentargets/platform


text:
Bit 578 speed up metagraph storage query

Note: this feature requires using https://github.com/opentensor/subtensor/pull/26 in the subtensor node that you query as the buffer size needs to be changed for the fast sync to work

This PR adds the subtensorapi package to grab live storage from the chain in a faster manner.
The current live-sync takes around ~8m (See #933) using only pure-python.
The subtensorapi package wraps a nodejs binary in python and utilizes the @polkadot/api npm library to sync from the chain.
This sync outputs as JSON to ~/.bittensor/metagraph.json (by default) and then is read into python before being returned to the bittensor package.
Below is a current graph of the performance of subtensorapi (sapi) vs the ipfs sync (current cached-sync).
The results may be worse than average as the request times are very node-dependent. This node is hosted on a cheap contabo VPS with heavy traffic.
I expect request times to be similar to this, if not better.

Further, subtensorapi can be extended to support other storage values. Currently it also supports the subtensorModule.blockAtRegistration map using Subtensor.blockAtRegistration_all_fast()

overall looks LGTM @camfairchild  but we need to work with @eduardogr before merging this yet, since the AWS endpoints need to support this change as well (right now they're missing the  --ws-max-out-buffer-capacity 1024 --rpc-max-payload 1000 flags

overall looks LGTM @camfairchild but we need to work with @eduardogr before merging this yet, since the AWS endpoints need to support this change as well (right now they're missing the  --ws-max-out-buffer-capacity 1024 --rpc-max-payload 1000 flags

Done, in this commit: https://github.com/opentensor/subtensor/commit/f5f2b8523c703b88e0712d2da7f46206a43d5691

What keeps this PR from keeping blocked? Can someone pull and merge master?

What keeps this PR from keeping blocked? Can someone pull and merge master?

Hi @mrseeker, a couple of things here.

We have a scheduled release for the 12th of December and this will may be released then.
And the release process is not just merge into master.

We will keep the community informed about this release.
Thanks for your presence here.

What keeps this PR from keeping blocked? Can someone pull and merge master?

Also keeping this blocked is an update of the rest of our subtensor nodes/chain endpoints with the new flags.

overall looks LGTM @camfairchild but we need to work with @eduardogr before merging this yet, since the AWS endpoints need to support this change as well (right now they're missing the  --ws-max-out-buffer-capacity 1024 --rpc-max-payload 1000 flags

This should be good to go on our infra. Need to work on the migration for users, but most should be able to just use the new compose file.

Closing as planned with new impl for finney

authors: camfairchild eduardogr mrseeker shibshib

repo: opentensor/bittensor


text:
Add/Update logs in MeshForwarder class

This commit contains the following changes:

Adds new logs when a new message is being prepared for indirect tx
to a sleepy child.

Adds new logs when an Ipv6 message being dropped from reassembly list
due to reassembly timeout or missing fragments (in case of MTD).

Codecov Report

Merging #1649 into master will decrease coverage by 1.32%.
The diff coverage is 68.75%.

@@            Coverage Diff             @@
##           master    #1649      +/-   ##
==========================================
- Coverage   69.04%   67.72%   -1.33%
==========================================
  Files         166      167       +1
  Lines       19870    21130    +1260
  Branches     2441     2592     +151
==========================================
+ Hits        13720    14311     +591
- Misses       5294     5911     +617
- Partials      856      908      +52

Impacted Files
Coverage Δ

include/openthread/types.h
100% <ø> (ø)
:arrow_up:

src/core/thread/mesh_forwarder.hpp
66.66% <ø> (ø)
:arrow_up:

src/core/common/logging.cpp
37.5% <0%> (-0.48%)
:arrow_down:

src/core/thread/topology.hpp
89.88% <100%> (+0.86%)
:arrow_up:

src/core/thread/mesh_forwarder.cpp
78.44% <57.14%> (-0.27%)
:arrow_down:

src/core/api/thread_api.cpp
43.13% <0%> (-1.57%)
:arrow_down:

examples/apps/ncp/main.c
100% <0%> (ø)

src/core/mac/mac.cpp
76.57% <0%> (+0.45%)
:arrow_up:

src/core/thread/network_data_leader.cpp
84.26% <0%> (+0.5%)
:arrow_up:

... and 10 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 b83f644...a9a02ea. Read the comment docs.

authors: abtink codecov-io

repo: openthread/openthread


text:
[child] enhance Child::AddressIterator

This commit enhances the iterator Child::AddressIterator which is
used to iterate over IPv6 address list of a Child. The new model
enables range-based for loops to be used. It also enables filtering
addresses based on type (e.g., iterate over multicast addresses only).
The unit test test_child.cpp is also updated to verify the newly
added functionalities of AddressIterator.

Where is the 128B code size increase from ? @abtink

Where is the 128B code size increase from ? @abtink

In short, it's from all the new changes in the PR, i.e., the new type filtering mechanism and the new iterator model.
Some chunk of it is coming from the fact that iterator is a larger (more complex) object and contains an Ip6::Address (we need this for mesh-local address or we go back to model of caller needing to provide the address object for us to copy into which is not idle).  The larger size of Iterator seem to hinder complier optimizing/inlining some the logic.

authors: abtink simonlingoogle


text:
Increase cli rx buffer size

increase cli rx buffer size
The rx buffer is not enough to store the command while doing MGMT_ACTIVE_SET certificate test.
This is not a good solution to solve this, but can help to solve this problem quickly.
I will update it, if we have better ways to solve this.
fix networkname cli

Current coverage is 69.57% (diff: 0.00%)

Merging #710 into master will increase coverage by 0.01%

@@             master       #710   diff @@
==========================================
  Files           101        101
  Lines         15231      15231
  Methods        2074       2074
  Messages          0          0
  Branches       1799       1799
==========================================
+ Hits          10594      10597     +3
+ Misses         4062       4058     -4
- Partials        575        576     +1

Powered by Codecov. Last update dfd5fbd...63ddfaf

I'll approve this for now, but can you post an example of one of the offending CLI commands?

authors: codecov-io jwhui luwannest


text:
No permission dialog for camera and microphone

**Hello, I need to create live video streaming, I am using OutSystem for development, when loaded this plugin in InAppBrowser, it does not ask for Camera and Microphone permissions. But the same works fine in web browser.

@cupidleomanoj Hmm, it looks like the InAppBrowser can't access the Cordova APIs which is what this plugin uses. I'm not sure if this plugin is compatible with InAppBrowser, you can try to use the OpenTok JS SDK with the InAppBrowser and it may work for Android, but not iOS since it doesn't support WebRTC.

repo: opentok/cordova-plugin-opentok


text:
chore(plugin.xml): :sparkles: declare the opentok file in the js-module

It makes the opentok file show up in the cordova_plugin.js file.
It enables the cordova-plugin-injectview plugin to properly detect and inject the opentok files.

Contributing checklist

[ ] Code must follow existing styling conventions
[ ] Added a descriptive commit message

Solves issue(s)

Oops, already exists https://github.com/opentok/cordova-plugin-opentok/pull/200


text:
[WIP] JPA test

Fixes #39

@pavolloffay you are right. Problem in GlogalTracer of jdbc tracing.
I fix it using Reflection as in https://github.com/opentracing/opentracing-java/blob/578d4e74d9b16c18268717e537000a88d7e6779c/opentracing-util/src/test/java/io/opentracing/util/GlobalTracerTest.java#L48_L57

@malafeev thanks it looks great :+1:

authors: malafeev pavolloffay

repo: opentracing-contrib/java-spring-cloud

license_source: bigquery


text:
🛑 [CN] OpenUPM Website Package Detail is down

In 0a81c38, [CN] OpenUPM Website Package Detail (https://openupm.cn/packages/com.littlebigfun.addressable-importer/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Package Detail is back up in 572357c after 7 minutes.

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website Package Detail is down

In 0c1b57e, [CN] OpenUPM Website Package Detail (https://openupm.cn/packages/com.littlebigfun.addressable-importer/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Package Detail is back up in 935addc after 14 minutes.


text:
🛑 [CN] OpenUPM Website Docs is down

In a5ec261, [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 6dd75f0.


text:
🛑 [CN] OpenUPM Website Docs is down

In e03d380, [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 1f0f43a.


text:
🛑 [CN] OpenUPM Website is down

In 0bed1b9, [CN] OpenUPM Website (https://openupm.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in 2604c76.

repo: openupm/upptime


text:
German building parsing issue

Hi!
I was checking out libpostal, and saw something that could be improved.

My country is
Germany

Here's how I'm using libpostal
Have own instance.

Here's what I did
{ 	"query": "charles de gaulle str. geb. 5467" }

Here's what I got
[ 	{ 		"label": "road", 		"value": "charles de gaulle str." 	}, 	{ 		"label": "house_number", 		"value": "geb." 	}, 	{ 		"label": "postcode", 		"value": "5467" 	} ]

Here's what I was expecting
[ 	{ 		"label": "road", 		"value": "charles de gaulle str." 	}, 	{ 		"label": "unit", 		"value": "geb. 5467" 	} ]
like in
{ 	"query": "charles de gaulle str. bldg 5467" }
-->
[ 	{ 		"label": "road", 		"value": "charles de gaulle str." 	}, 	{ 		"label": "unit", 		"value": "bldg 5467" 	} ]
or
[ 	{ 		"label": "road", 		"value": "charles de gaulle str." 	}, 	{ 		"label": "house", 		"value": "geb. 5467" 	} ]
like in
{ 	"query": "Charles de Gaulle Str. 67 Geb. 5467" }
-->
[ 	{ 		"label": "road", 		"value": "charles de gaulle str." 	}, 	{ 		"label": "house_number", 		"value": "67" 	}, 	{ 		"label": "house", 		"value": "geb. 5467" 	} ]

For parsing issues, please answer "yes" or "no" to all that apply.

Does the input address exist in OpenStreetMap?
no

Do all the toponyms exist in OSM (city, state, region names, etc.)?
yes

If the address uses a rare/uncommon format, does changing the order of the fields yield the correct result?
yes
{   "query": "geb. 5467 charles de gaulle str." }
-->
[   {   	"label": "house",   	"value": "geb. 5467"   },   {   	"label": "road",   	"value": "charles de gaulle str."   } ]

If the address does not contain city, region, etc., does adding those fields to the input improve the result?
no (checked with Germany, Berlin, Bonn)

If the address contains apartment/floor/sub-building information or uncommon formatting, does removing that help? Is there any minimum form of the address that gets the right parse?
yes
{   "query": "charles de gaulle str." }
-->
[   {   	"label": "road",   	"value": "charles de gaulle str."   } ]

and
{ 	"query": "geb. 5467" }
-->
[ 	{ 		"label": "house", 		"value": "geb. 5467" 	} ]

Here's what I think could be improved
Don't know what to improve, but responses for splitted request are different than for full request in this case.

Added support for ged/gebäude for German addresses in #392. But even if the PR is accepted, it will take months to re-run the pipeline. For now I suggest you to manually find such cases and remove any occurrences of 'geb.' before sending calling libpostal. I did the same when had problems with Dutch postal code with and without space - 2331SK / 2331 SK.

authors: Aknilam antimirov

repo: openvenues/libpostal

license: mit


text:
Onnx padim output processing in C#

What is the motivation for this task?
I've trained a padim anomaly detector on my own dataset; now I want to deploy it in C#.
I've experience with Microsoft.ML.OnnxRuntime library.
First of all, is it normal that my onnx model is around 600MB? Furthermore I would like to know how to process output from onnx model to obtain the anomaly score; is there a guide or a further documentation to process output feature map from onnx file?
Describe the solution you'd like
I'd like to get a description of the output structure of onnx model after being executed in C# with Microsoft.ML.OnnxRuntime library. I need to know how can i process the output in order to get the final result as happen making an inference in python.
Additional context
No response

Hello. The reason that the model is so big are mean tensor and inverse of covariance matrix inside multivariate Gaussian which can become quite large in dimensions:
https://github.com/openvinotoolkit/anomalib/blob/1f50c952fc65a165884b2b94e178821dcebfbbef/src/anomalib/models/components/stats/multi_variate_gaussian.py#L20-L21
WIth input size of 256x256 they have shape of [100, 4096] and [4096, 100, 100] respectively . With 512x512 they are [100, 16384]  and [16384, 100, 100] respectively.
Now for pre and post-processing you can refer to OpenVInoInferencer code. You will need to handle resizing, normalization and take care of channel order in preprocessing and then normalization and thresholding in post-processing. And for the structure of output, I it should be just a single anomaly map. Again refer to OpenVinoInferencer (and Inferencer base class) for specifics.

repo: openvinotoolkit/anomalib


text:
Core dump problem

When I tried to run the training, the following core dump problem occurred.
$ python tools/train.py --config anomalib/models/padim/config.yaml

2023-01-20 05:10:29,203 - pytorch_lightning.callbacks.model_summary - INFO -
  | Name                  | Type                     | Params
-------------------------------------------------------------------
0 | image_threshold       | AnomalyScoreThreshold    | 0
1 | pixel_threshold       | AnomalyScoreThreshold    | 0
2 | model                 | PadimModel               | 2.8 M
3 | image_metrics         | AnomalibMetricCollection | 0
4 | pixel_metrics         | AnomalibMetricCollection | 0
5 | normalization_metrics | MinMax                   | 0
-------------------------------------------------------------------
2.8 M     Trainable params
0         Non-trainable params
2.8 M     Total params
11.131    Total estimated model params size (MB)
Epoch 0:   0%|                                                                                | 0/10 [00:00<?, ?it/s]/home/ishihara/.local/lib/python3.8/site-packages/pytorch_lightning/loops/optimization/optimizer_loop.py:137: UserWarning: `training_step` returned `None`. If this was on purpose, ignore this warning...
  self.warning_cache.warn("`training_step` returned `None`. If this was on purpose, ignore this warning...")
Epoch 0:  70%|████████████████2023-01-20 05:10:31,739 - anomalib.models.padim.lightning_model - INFO - Aggregating the embedding extracted from the training set.
2023-01-20 05:10:31,779 - anomalib.models.padim.lightning_model - INFO - Fitting a Gaussian to the embedding collected from the training set.
Epoch 0: 100%|█████████████████████████████████████████████████████████████████████| 10/10 [00:08<00:00,  1.16it/s, loss=nan]/home/ishihara/.local/lib/python3.8/site-packages/torchmetrics/utilities/prints.py:36: DeprecationWarning: `torchmetrics.functional.auc` has been move to `torchmetrics.utilities.compute` in v0.10 and will be removed in v0.11.
  warnings.warn(*args, **kwargs)
Epoch 0: 100%|█████████████████████████████| 10/10 [00:09<00:00,  1.01it/s, loss=nan, pixel_F1Score=0.722, pixel_AUROC=0.983]
2023-01-20 05:10:39,229 - anomalib.utils.callbacks.timer - INFO - Training took 10.03 seconds
2023-01-20 05:10:39,229 - anomalib - INFO - Loading the best model weights.
2023-01-20 05:10:39,229 - anomalib - INFO - Testing the model.
2023-01-20 05:10:39,238 - anomalib.data.mvtec - INFO - Found the dataset.
2023-01-20 05:10:39,238 - anomalib.utils.callbacks.model_loader - INFO - Loading the model from /home/ishihara/anomalib/results/padim/mvtec/bottle/run/weights/model.ckpt
2023-01-20 05:10:39,383 - pytorch_lightning.accelerators.gpu - INFO - LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
Testing DataLoader 0:   0%|                                                                            | 0/3 [00:00<?, ?it/s]QObject::moveToThread: Current thread (0x4ef7ab70) is not the object's thread (0x574e2f70).
Cannot move to target thread (0x4ef7ab70)

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/home/ishihara/.local/lib/python3.8/site-packages/cv2/qt/plugins" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl.

Core dump

have you installed the library on a virtual environment?

as a quick solution you could maybe refer to this
https://github.com/NVlabs/instant-ngp/discussions/300#discussioncomment-3179213

Yes, I have installed the library according to the following instruction.
yes | conda create -n anomalib_env python=3.8
conda activate anomalib_env
git clone https://github.com/openvinotoolkit/anomalib.git
cd anomalib
pip install -e .

@Ishihara-Masabumi, can you confirm whether you still have this issue?

Thanks. It's OK.

authors: Ishihara-Masabumi samet-akcay


text:
config: Modify inactivity-probe for DB server and client.

OVN DB has a connection table where we currently define the
port number to listen on for the OVN DB servers.  By default,
every 5 seconds or so, OVN DB server sends a inactivity probe
to test whether the client is still connected.  When there
are hundreds of clients, the server may spend a lot of time
maintaining these inactivity probes and as a result consume
a lot of CPU. It does not make sense for the server to do
this job. It should be the client that tries to maintain
the connection. And if the connection is down, the client
should restart it.
So this commit disables the inactivity_probe for the server
by setting it as zero.
For the clients (ovn-controller in our case), we provide the
option for the user to set it. Shorter time would mean that
a lot of inactivity probes could be sent by al the clients
to the server. A very long time means that events may
not get propogated to the clients soon enough.  This commit
sets the default value as 1 minute. And a user can change it
if he prefers.
Signed-off-by: Gurucharan Shetty guru@ovn.org

This is good for a review. PTAL.

Out of curiosity, why are we using the keepalive probes? I spoke with our ovs/ovn engineer and we were unconvinced of the need.

When a TCP connection goes down, it can take a while for the kernel to figure that out. So a user process may only try to reconnect after some time. Using probes on top of a TCP connection lets you do fast reconnections.

@shettyg OK we are avoiding a small delay in connection after a long period of inactivity. Does this work when the ca,priv key,cert not set up?

OK we are avoiding a small delay in connection after a long period of inactivity. Does this work when the ca,priv key,cert not set up?

Yes. TCP or SSL does not matter. If SSL, then the keys need to be setup.  The keys are setup in the SSL table (not connections table).

Just two small nits.
/LGTM

Thanks. I made edits to the commit to take care of your comments. I will push this in a bit.

authors: pecameron shettyg

repo: openvswitch/ovn-kubernetes


text:
Fix issues with smtp tls ( 25 port )

Golang often refuse to send tokens ( reset password, etc ) via unencrypted connection ( 25 smtp ), It should be utilized to use 587 port of sendgrid.

Hi @streetcrypto7.
I don't think this is related to postmaster, as you can configure smtp by yourself using this environment variables.
| Variable               | Description                          | Required | Default              |
|------------------------|--------------------------------------|----------|----------------------|
| `SMTP_PASSWORD`        | Password used for auth to SMTP       | *yes*    |                      |
| `SMTP_PORT`            | Post of SMTP server                  | *no*     | `25`                 |
| `SMTP_HOST`            | Host of SMTP server                  | *no*     | `smtp.sendgrid.net`  |
| `SMTP_USER`            | User used for auth to SMTP           | *no*     | `apikey`             |
| `SENDER_EMAIL`         | Email address of mail sender         | *yes*    |                      |
| `SENDER_NAME `         | Name of mail sender                  | *no*     | `Postmaster`         |

@sha1
Hello,
Postmaster doesn't work with 25 port if I try to send some sensitive data like password reset or register confirmation.
You should change them to use 587 port if you want to aviod the go library error.
See https://stackoverflow.com/questions/11065913/send-email-through-unencrypted-connection for more information.

repo: openware/postmaster


text:
Create a DAO adapter layer for calls to the datastore

Currently, the gateway is tightly coupled to redis as a requirement. We want to make this pluggable so that all of the lookups are abstracted through a data layer that can abstract away underlying datastore details.
For example, if someone wanted to replace redis with cassandra or memcached or a filesystem, they could write an adapter for their specific use case and then package it into custom build of the gateway. Eventually, we might even provide multiple drivers in the main build.
Another advantage of this approach is that we can tweak characteristics of the underlying driver without affecting the routing logic directly.
The new flow looks something like this:
router -> DAO -> adapter(driver) (where currently, the driver is redis)
General todos:

[ ] Add a config flag defining which driver is in use and the parameters it requires
[ ] Add a DAO layer with functions for things required by routing, subscriptions, etc
[ ] Write a redis driver that implements the DAO contract and makes the required calls to redis
[ ] Init the DAO with the selected adapter on startup

This flame graph shows that redis.init is quite time consuming. Rather than simply work our current redis interaction code to pass an instance around, we want to make a more robust way to interact with the underlying data store.

We should start thinking about what interface the DAO should expose.
What things do we need to deal with?

Tenants
APIs
Resources (operation / path + index)
Subscriptions
Rate limits
OAuth tokens
Other stuff needed by policies?

We can add stuff to the list above, but I think it boils down to an interface like this (super rough first pass--don't hold me to it):
local _M = {}
function _M.upsertTenant()
function _M.deleteTenant()
function _M.getTenant()
function _M.getTenants()

function _M.createAPI()
function _M.updateAPI()
function _M.deleteAPI()
function _M.getAPI()
function _M.getAPIs(tenant)

function _M.createResource()
function _M.updateResource()
function _M.deleteResource()
function _M.findResource()

function _M.validateRateLimit(resource, { shouldIncrement: true })

Rather than splitting things out for oauth tokens and other values that we might need to cache, I think there's probably just a generic cache interface.
function _M.cacheSet(key, value)
function _M.cacheGet(key)
function _M.cacheDelete(key)

// OAuth example:
dao.cacheGet('oauth:providers:facebook:tokens:<accessToken>`)

#198

for some reason I can't tick the boxes on your issue

[x] Add a config flag defining which driver is in use and the parameters it requires
[/] Add a DAO layer with functions for things required by routing, subscriptions, etc
[x] Write a redis driver that implements the DAO contract and makes the required calls to redis
[x] Init the DAO with the selected adapter on startup

authors: mhamann taylorking

repo: openwhisk/openwhisk-apigateway


text:
pip package for wcon missing schema file

The package installed via the command "pip install wcon" (under the conda environment for Python 3.5) appears to be missing the schema file as indicated by this error message for when I try to run the OWAT example "WCON Demo.py"
FileNotFoundError: [Errno 2] No such file or directory: '/home/cheelee/miniconda3/lib/python3.5/site-packages/wcon/wcon_schema.json'
This is easily fixed on my side by merely copying the necessary file from my clone of tracker-commons, but I'm thinking the pip package ought to be fixed to include the file. Thanks!

Thanks for noticing this.  I think I thought anything in the src/Python/wcon folder would get packaged automatically since src/Python/setup.py specifies the package name is wcon.  Instead from http://stackoverflow.com/questions/1612733/ I've learned I should include a line in setup.py:
package_data={'': ['../../wcon_schema.py']},

This actually hopefully means we don't need two copies of wcon_schema.py, since I can specify via relative paths  the path to the schema file in a folder outside of wcon/.  I'll close this issue once I've submitted version 1.1 to PyPI and confirmed that wcon_schema.py is getting packaged.
My commit for this is 592df94b2d93536917b9fc6b666b756da1239214.

authors: MichaelCurrie cheelee

repo: openworm/tracker-commons


text:
Luci topic list overflows

Sorry, not enough context to work with. Where does it appear and most importantly, can you reproduce it using the default bootstrap theme?

It will be worse if there is longer content

Okay, not affecting bootstrap. So yet another material theme bug.

authors: jow- qiuzi

repo: openwrt/luci


text:
[BUG] nftables ports opened by miniupnpd not shown on status page or upnp luci app page

Master build as of ae75541 shows that the miniupnpd ports are correctly opened via fw4 rules.
However, both the Luci status -> overview page’s “Active UPnP Redirects” as well as luci-app-upnp package’s “Active UPnP Redirects” sections are empty.
Expected behaviour is of course for the redirects to appear on these pages when nftables are used for miniupnpd.

I am also seeing this issue on my end. In addition to this, it seems that sometimes port mappings fail to get removed properly, with errors shown in the logs saying as much.

The issue still persists in July.

I've just compiled 22.03.0-rc6 with miniupnpd 2.3.0 (modified the Makefile to download the latest version) and I too am not seeing anything show under 'Active UPnP Redirects' table of LuCI nor am I getting any open ports. I have even applied the patch mentioned in the forum post here whilst compiling the firmware and no difference.

I came here for what I think is this bug... In /usr/libexec/rpcd/luci.upnp (part of the luci-app-upnp package), the get_status method seems to try running iptables, which of course doesn't work with firewall4/nftables. I don't know enough to submit a patch but it seems like this could be part of the problem. I am running 22.03-rc6.

I just checked the master and openwrt-22.03 branches of https://github.com/openwrt/luci/blob/master/applications/luci-app-upnp/root/usr/libexec/rpcd/luci.upnp and it is still broken there. @Ansuel wrote the original code.

Fixed by #5961

authors: edrikk elliotclee firewire10000 jckefan jow- urbenlegend


text:
FW-583. TelosB mote is on for 1ms too long because radio_rxEnable() is called in activity_ri2 rather than activity_ri3.

TelosB mote is on for 1ms too long because radio_rxEnable() is called
in activity_ri2 rather than activity_ri3.

@TimothyClaeys Thanks for fixing this! Cool!

authors: TimothyClaeys changtengfei

repo: openwsn-berkeley/openwsn-fw


text:
RFC - Creating an openxla/dev-tools repo and building automation

I would like to contribute a variant of my in-progress development tools repository to the openxla organization: https://github.com/stellaraccident/openxla-dev-tools. I suggest simply shortening it to dev-tools once brought into the organization-proper.
The above represents a few hours of coding to build the boilerplate tooling that we can use for managing repositories, dependencies, and corresponding automation in the OpenXLA projects, and is a first step to helping us build workflows that bump dependencies and enable release automation.
In consultation with various folks, I concluded that a dedicated tools project was in order, and I chose to make that a cohesive python package that can be installed by anyone with a one liner. In addition, we wanted to make it straight-forward for folks (and CI) to check out individual projects and have a single script to run that would update their deps (without requiring installation of more advanced dev tooling packages like this). That way, we should be able to have a flow where advanced, cross-repo users can use this tools package as their daily driver, while people focused on a single project get exactly what they need (by being able to run sync_deps.py locally and always be up to date).
As an example (not yet completely refactored but to show the idea), here is a draft of the openxla-pjrt-plugin project using this tools package to manage its deps: https://github.com/openxla/openxla-pjrt-plugin/pull/29
Regardless of where we take such dev-tools and automation in the future, it seems that we definitely need a centrally accessible dev-tools project, and I therefore propose that we bootstrap it with the code I have started writing.

Being able to easily setup and use SGTM  This reminds me of the "recent" https://github.com/google/git-mmrepo repo.
Nit: I'd suggest openxla-dev-tools still, org is elided when forking and checking out, that makes origin difficult to see.

Being able to easily setup and use SGTM This reminds me of the "recent" https://github.com/google/git-mmrepo repo.

Yeah, let's say I've learned a few things since then about not trying to do too much or create something too general. This is quite specific to our projects.
I think I've basically gotten this to a point of good utility now. I've overhauled the openxla-pjrt-plugin repo to be managed via this mechanism, and I implemented dep rolling of both the source and binary (python deps).

This workflow now runs at 12:30PM each day to roll all source and binary pinned deps and creates/approves a PR for submission (if tests pass). I need to touch base with Geoffrey next week for some permission and de-hacking stuff but it basically works.
Here is an example of an auto-roll PR that submitted itself.
pjrt-plugin instructions are a lot nicer now that everything is properly pinned.
I implemented what is needed for a continuous bump for main deps but at that frequency, we probably want a centralized dep roller bot to coordinate that vs just having a bunch of random GitHub actions trying to not step on each other. One step at a time.
It shouldn't be too hard to create such a bot since it is mostly just choreographing a few basic commands.

See the current README for the state of what is implemented. I think we can roughly call this ready to promote to a real repo.

Submitting request to include @jpienaar's suggestion (openxla/openxla-dev-tools).

repo: openxla/community


text:
[CPU] Enable masking for '+v9a' Arm CPUs.

SVE is a mandatory feature of v9a Arm CPUs so even if we don't specify +sve in target features (becase we don't want to take the scalable path within IREE), masking is available in the backend so we want to take advantage of this when passing v9a.

We are not adding pipeline tests but happy to add something simple you can think about

I've made a small suggestion, wdyt?

The problem is that we need to pass +v9a or +sve to the LLVM backend while we still generate fixed-length (i.e., Neon) code within IREE. If we mix v9a and sve flag query, we would need another flag to say "disable scalable vectors"... So I'm not sure what is best here.

I've made a small suggestion, wdyt?

The problem is that we need to pass +v9a or +sve to the LLVM backend while we still generate fixed-length (i.e., Neon) code within IREE. If we mix v9a and sve flag query, we would need another flag to say "disable scalable vectors"... So I'm not sure what is best here.

There's also -sve and my suggestion could be updated as:
 return  (hasV9aFeature(targetAttr) && !hasFeauture(targetAttr, "-sve")) || hasFeature(targetAttr, "+sve") || hasFeature(targetAttr, "+sve2");

This way hasAnySVEFeature would return false for +v9a -sve. Is that what you are after?  I'm probably missing something 🤔

We can't use -sve because that would pass -sve to the backend and then mask instructions won't be generated. If we want to put v9a within the SVE flag query, we should then add a flag to disable scalable vectorization (i.e., --iree-llvmcpu-enable-scalable-vectorization) while still using +v9a` feature flag.

authors: banach-space dcaballe

repo: openxla/iree


text:
keep the images of the latest version of each openyurt component consistent

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind documentation
/kind enhancement
/kind good-first-issue
/kind feature
/kind question
/kind design
/sig ai
/sig iot
/sig network
/sig storage

/kind bug
What this PR does / why we need it:
Ensure that the images of the latest version of each openyurt component pulled are always consistent.
Since we post images to dockerhub every day, in the process of deploying openyurt, we often encounter the problem that the
latest versions of these openyurt components are inconsistent, such as issue #940. The main reason may be that the imagePullPolicy of some components is Always, where others are IfNotPresent.

@windydayc Thank you for posting pull request. It's not a good idea to change the imagePullPolicy from IfNotPresent to Always because edge nodes can not pull images successfully if we reboot edge nodes when cloud-edge network is off. so imagePullPolicy is Always, the pods on edge nodes may not heal when restartup.

@windydayc and i will close this pull request manually because we should keep imagePullPolicy as IfNotPresent.

authors: rambohe-ch windydayc

repo: openyurtio/openyurt


text:
Updates to latest docker images, aligning maven version

This uses latest java images, and aligns with the following tools provided by them:

maven:3.9.8
maven-help-plugin:3.4.1
maven-dependency-plugin:3.7.1

To align, we run "mvn wrapper:wrapper -Dtype=bin" to update maven and manually change any pom or script references to share the above plugin versions.
Besides text replacement for current java versions, this also had to switch docker-compose to docker compose as the former is no longer in the base image.
This intentionally doesn't touch anything else, or maven plugins that aren't cached in the java image.

ps this same change needs to happen on zipkin, -aws and -gcp, but testing it here first. (works or you would see failed tests)

repo: openzipkin/brave-example


text:
Empty service name in Zipkin when using brave-opentracing

Description
Empty service name in Zipkin when using brave-opentracing. Please refer to the screenshot below.
How to replicate the issue
public static void main(String[] args) throws InterruptedException {
        OkHttpSender sender = OkHttpSender.create("http://127.0.0.1:9411/api/v1/spans");
        AsyncReporter reporter = AsyncReporter.builder(sender).build();
        Tracing braveTracing = Tracing.newBuilder()
            .localServiceName("my-service")
            .reporter(reporter)
            .build();

        Tracer tracer = BraveTracer.create(braveTracing);
        try ( Span span0 = tracer.buildSpan("span-0")
            .withTag("description", "top level initial span in the original process")
            .start() ) {
            Thread.sleep(500);
            System.out.println("Done. Next step is to visit http://localhost:9411 and check service name.");
        }

        Thread.sleep(2000);
    }

Dependencies used

brave-opentracing:0.20.0
opentracing-api:0.21.0
io.zipkin.brave:brave:4.2.0 (the newest checked as well)
io.zipkin.reporter:zipkin-sender-okhttp3:0.10.0

Zipkin server
For test purposes, Zipkin is executed as follows:
java -jar zipkin-server-1.26.0-exec.jar

Actual result

JSON
[
  {
    "traceId": "7c7f770e7a66b439",
    "id": "7c7f770e7a66b439",
    "name": "span-0",
    "timestamp": 1495620160339364,
    "duration": 502318,
    "binaryAnnotations": [
      {
        "key": "description",
        "value": "top level initial span in the original process",
        "endpoint": {
          "serviceName": "my-service",
          "ipv4": "192.168.56.1"
        }
      }
    ]
  }
]

/trace JSON
{
  "timestamp": 1495637295369,
  "info": {
    "method": "POST",
    "path": "/api/v1/spans",
    "headers": {
      "request": {
        "content-encoding": "gzip",
        "content-type": "application/x-thrift",
        "content-length": "178",
        "host": "127.0.0.1:9411",
        "connection": "Keep-Alive",
        "accept-encoding": "gzip",
        "user-agent": "okhttp/3.8.0"
      },
      "response": {
        "X-Application-Context": "zipkin-server:shared:9411",
        "status": "200"
      }
    },
    "timeTaken": "153"
  }
}

Expected result
I would expect service name "my-service" displayed on a bar.

I found out that if .withTag() is not used, the example above works.
Alternatively, calling .withTag("span.kind", "client") also makes the missing service label appear.
So, despite using of brave.Span#kind is optional, it somehow influences displayed service name.
Having said that, it may be an issue in brave.

Interesting, I'm hoping to have time to look at stuff again starting next week. I'm moving and therefore super busy in and out of work

this is sorted in a recent version of zipkin server (as was a javascript related issue). Upgrade your server and all should work. I verified by posting the span you sent.. excellent detail

authors: adriancole devinsba kangur85

repo: openzipkin/brave-opentracing


text:
Be a bit smarter on transport failures

That we could be a bit better around errors was acknowledged in the initial import of the http transport. What was agreed was that whatever mechanism we add needs to be tested, and since things like this are hard to test, we should layer fanciness on top.
Seems the time has come!
@marcingrzejszczak mentioned some instability in network causing spans to be dropped. Then, @bensigelman mentioned an algo, which happens to be the same one used in htrace, the one @clehene wrote
It goes like this..

(flush() or similar is called)
remove all N records from the queue to be flushed
attempt to send to remote peer / server / whatever

if successful, great
if unsuccessful, add all N records back to the queue while respecting any heuristics about max queue length / total byte size / etc
regardless of success, wait until trying to flush again

wait until trying is the tricky part, of course… if there are expectations about time ordering in the queue the corner cases are subtle. and of course if you hit your max length there’s still the possibility of dropping data
it’s also important that all flushes are serialized, at least if it’s important that records are delivered to the peer in order (otherwise if flush1 is in flight (and will fail) and flush2 succeeds in the interim, bad things happen, etc)

In our implementation, we can do this for sure. Luckily, we can drop corner cases around ordering as there's no expectation of ordering in zipkin's POST endpoint.
One case to call out is HTTP 400, there's no point sending the spans again, as they are malformed. In this case, we can just log a higher level as usually that's a bug.

One more thing... In brave HTTPS span collector we're just ignoring all
errors instead of at least logging them. It's impossible to understand what
was the reason for receiving 400 for example. It would be good to start
logging those things.

Heh scroll down in the desc ;)

As you can see I've already removed the message ;) I have to read those issues after I'm fully awake ;)

this is all handled by zipkin-reporter-java now

authors: adriancole marcingrzejszczak

repo: openzipkin/brave


text:
WIP: Make core types unloadable

This is progress towards making Brave types not interfere with
classloader GC.
See #785

Got a lot of progress but stumped on something.. I'd like to make sure everything is covered test-wise, just one bozo code seems to still be uncollectable even when it appears there are none of our types still hooked up. https://github.com/openzipkin/brave/blob/core-threadlocal-fixies/brave/src/main/java/brave/propagation/ThreadLocalSpan.java#L152

Added a commit that ensures log4j2's log manager doesn't lead anyone in the future to a distracting wander :P

ok got the core code sorted. Later pull requests will ensure instrumentation don't also have similar problems.


text:
Slims down Kafka by removing libs only needed for streams and connect

This takes another 33M off the image (which is half its size over our base image)
openzipkin/zipkin-kafka       test                    3513b24c41c6        6 minutes ago       133MB
openzipkin/zipkin-kafka       latest                  6bf053880509        2 weeks ago         166MB

Thanks for the look @anuraaga and @jeqo!

repo: openzipkin/zipkin


text:
Enable multiplatform builds on Semaphore

@shiroyasha this PR configures Semaphore to run multiplatform builds using QEMU. The docker build, however, fails. You can see the build error here: https://rtx.semaphoreci.com/jobs/c4702f16-966b-4e2e-a160-e832ddaffb92
I've tried the same build command on Docker Desktop running on my macbook and I have the same exact error. Since I'm not familiar with Elixir compilation, I'm not sure how to debug the problem. Not sure if this is caused by emulation, the build order in the Dockerfile or something else. So I leave this partial solution here.
I suggest trying to build the multiplatform image using Docker Desktop first as it's easier to debug and the solution will probably also work on the Linux agent on Semaphore.

I don't have access to the link 😢

I don't have access to the link 😢

Here's the meat of the error:
 > [linux/arm64 builder 10/19] RUN mix deps.compile:
5.479 ==> decimal
5.480 Compiling 4 files (.ex)
9.213 Generated decimal app
9.243 ==> operately
9.246 Error while loading project :custom_base at /app/deps/custom_base
9.251 ** (ArgumentError) could not call Module.put_attribute/3 because the module Decimal.Mixfile is already compiled
9.251     (elixir 1.17.2) lib/module.ex:2365: Module.assert_not_readonly!/2
9.251     (elixir 1.17.2) lib/module.ex:2046: Module.__put_attribute__/5
9.251     /app/deps/custom_base/mix.exs:2: (module)
------
Dockerfile.prod:58
--------------------
  56 |     # to be re-compiled.
  57 |     COPY config/config.exs config/${MIX_ENV}.exs config/
  58 | >>> RUN mix deps.compile
  59 |
  60 |     COPY priv priv
--------------------
ERROR: failed to solve: process "/bin/sh -c mix deps.compile" did not complete successfully: exit code: 1

I don't have a good idea either. It seems that it only fails on arm, while works as expected on Intel, latest successful build from today on Intel: https://operately.semaphoreci.com/jobs/13778424-920e-41a8-b6b3-20c0175e5537.
Can you build it successfully if you are using amd64? Or does it fail for both?

@TomFern how should we proceed? What is our current biggest blocker?

The main blocker is that at least one of the dependencies does not appear to compile in Qemu. It doesn't seem to be a problem with the Linux machine, as I get the same error on Docker Desktop on Mac. Unfortunately, I'm not familiar with debugging Elixir compilation, so I don't have a solution.
One workaround could be using different agents to build the ARM and x86 images. Not ideal since you would end up having two images instead of a multiplatform image.

It doesn't seem to be a problem with the Linux machine, as I get the same error on Docker Desktop on Mac.

This is good input. I've never encountered this problem myself, but maybe @markoa or @Rockyy174 can reproduce it as they are using the same setup. Do you guys also get a compilation problem if you run: make docker.build locally?

I run Operately on Mac localhost with Docker Desktop but never encountered a compiler error. If I can somehow help reproduce more intentionally lmk.

Try to run make docker.build (it is different from make dev.build as it prepares a release image).

Just did, it passed.
$ make docker.build
[+] Building 82.1s (31/31) FINISHED                                           docker:desktop-linux
 => [internal] load build definition from Dockerfile.prod                                     0.0s
 => => transferring dockerfile: 3.20kB                                                        0.0s
 => [internal] load metadata for docker.io/library/debian:bookworm-20240904-slim              2.2s
 => [internal] load metadata for docker.io/hexpm/elixir:1.17.2-erlang-27.0.1-debian-bookworm  2.6s
 => [internal] load .dockerignore                                                             0.0s
 => => transferring context: 1.36kB                                                           0.0s
 => [builder  1/19] FROM docker.io/hexpm/elixir:1.17.2-erlang-27.0.1-debian-bookworm-2024090  3.4s
 => => resolve docker.io/hexpm/elixir:1.17.2-erlang-27.0.1-debian-bookworm-20240904-slim@sha  0.0s
 => => sha256:7dd5d482b2f67459c997f415662da2b907aac9dd411aca976e1303784b8602 1.58kB / 1.58kB  0.0s
 => => sha256:92c3b3500be621c72c7ac6432a9d8f731f145f4a1535361ffd3a304e55f7 29.16MB / 29.16MB  0.9s
 => => sha256:47b940901464ae5b3efa2b7f932661844ab8dca1983c0436a35e86f2e6fb37 3.55MB / 3.55MB  1.3s
 => => sha256:dbaa6f07fd6d61e55fdd901b0caa806145eb3d57fdb7725b1a505bdb8bab 44.16MB / 44.16MB  1.9s
 => => sha256:1122b88d68abdb51231b0be25ad6b06cebfb3574932b597fb070af0229dfae0a 772B / 772B    0.0s
 => => sha256:0a323b748056431e4982e2b17b5876523fc8d2ddc578fae40bc837d79c4969 1.16kB / 1.16kB  0.0s
 => => extracting sha256:92c3b3500be621c72c7ac6432a9d8f731f145f4a1535361ffd3a304e55f7ccda     0.8s
 => => sha256:cca90510ca90d5fd062fb622c48a6367b680f5eaef33e7cbc7fdbf25915f40 5.87MB / 5.87MB  3.3s
 => => extracting sha256:47b940901464ae5b3efa2b7f932661844ab8dca1983c0436a35e86f2e6fb373f     0.1s
 => => extracting sha256:dbaa6f07fd6d61e55fdd901b0caa806145eb3d57fdb7725b1a505bdb8babd301     0.5s
 => => extracting sha256:cca90510ca90d5fd062fb622c48a6367b680f5eaef33e7cbc7fdbf25915f40fd     0.1s
 => [stage-1 1/6] FROM docker.io/library/debian:bookworm-20240904-slim@sha256:a629e796d77a7b  1.7s
 => => resolve docker.io/library/debian:bookworm-20240904-slim@sha256:a629e796d77a7b2ff82186  0.0s
 => => sha256:a629e796d77a7b2ff82186ed15d01a493801c020eed5ce6adaa2704356f15a 1.85kB / 1.85kB  0.0s
 => => sha256:ace984fea4de21d4ad6d0047c3c6ab7ade9fcd9dee3e44c5fe6349d7dd063d86 529B / 529B    0.0s
 => => sha256:4d3492ddbe3a7e0be3e4b21881792a4b576b6f3dcba3878d1c05a5daa3cea2 1.48kB / 1.48kB  0.0s
 => => sha256:92c3b3500be621c72c7ac6432a9d8f731f145f4a1535361ffd3a304e55f7 29.16MB / 29.16MB  0.9s
 => => extracting sha256:92c3b3500be621c72c7ac6432a9d8f731f145f4a1535361ffd3a304e55f7ccda    78.5s
 => [internal] load build context                                                             0.1s
 => => transferring context: 5.24MB                                                           0.1s
 => [stage-1 2/6] RUN apt-get update -y && apt-get install -y libstdc++6 openssl libncurses5  4.6s
 => [builder  2/19] RUN apt-get update -y && apt-get install -y build-essential git curl     10.9s
 => [stage-1 3/6] RUN sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && locale-gen            1.0s
 => [stage-1 4/6] WORKDIR /app                                                                0.0s
 => [stage-1 5/6] RUN chown nobody /app                                                       0.1s
 => [builder  3/19] RUN set -uex     && apt-get update     && apt-get install -y ca-certific  6.0s
 => [builder  4/19] WORKDIR /app                                                              0.0s
 => [builder  5/19] RUN mix local.hex --force &&     mix local.rebar --force                  2.3s
 => [builder  6/19] COPY mix.exs mix.lock ./                                                  0.0s
 => [builder  7/19] RUN mix deps.get --only prod                                              3.0s
 => [builder  8/19] RUN mkdir config                                                          0.1s
 => [builder  9/19] COPY config/config.exs config/prod.exs config/                            0.0s
 => [builder 10/19] RUN mix deps.compile                                                     32.0s
 => [builder 11/19] COPY priv priv                                                            0.0s
 => [builder 12/19] COPY lib lib                                                              0.0s
 => [builder 13/19] COPY assets assets                                                        0.0s
 => [builder 14/19] RUN cd assets && npm install                                              9.8s
 => [builder 15/19] RUN mix assets.deploy                                                     9.8s
 => [builder 16/19] RUN mix compile                                                           0.5s
 => [builder 17/19] COPY config/runtime.exs config/                                           0.0s
 => [builder 18/19] COPY rel rel                                                              0.0s
 => [builder 19/19] RUN mix release                                                           1.0s
 => [stage-1 6/6] COPY --from=builder --chown=nobody:root /app/_build/prod/rel/operately ./   0.1s
 => exporting to image                                                                        0.2s
 => => exporting layers                                                                       0.2s
 => => writing image sha256:4cb5a33cf5b893e1c0aa4bc94f27567f1b8034a66ed51dbe168f26924a41736f  0.0s
 => => naming to docker.io/operately/operately:latest                                         0.0s
 => => naming to docker.io/operately/operately:b8b592de                                       0.0s

What's Next?
  View a summary of image vulnerabilities and recommendations → docker scout quickview

Closing as stale. We'll reopen when we have more info about why some elixir deps are not working in quemu.

authors: TomFern markoa shiroyasha

repo: operately/nightly


text:
Update to Maistra 2.0

Signed-off-by: Brian Avery bavery@redhat.com
Thanks submitting your Operator. Please check below list before you create your Pull Request.

Flat operator directory structure is obsolete from 23-rd of October 2019, only nested directory structure will be accepted.

New Submissions

[ ] Does your operator have nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?

Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/ok-to-test

/lgtm

@knrc Since you are previous contributor. Can you please check these changes if they are ok with you?

authors: brian-avery mvalarh

repo: operator-framework/community-operators


text:
community-operators must-gather-operator (1.0.4)

New Submissions

[ ] Has you operator nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Is your submission signed?

Updates to existing Operators

[x] Is your new CSV pointing to the previous version with the replaces property?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

/test all

/test all

/merge possible


text:
community-operators strimzi-kafka-operator (0.24.0)

This PR adds Strimzi 0.24.0 to Community Operators. It was tested manually on OCP 4.7.
Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

@J0zi @mvalarh Any idea what this error means? From the logs, I can see this.
error: pathspec 'origin/master' did not match any file(s) known to git

So it seems to me like it is not related to the operator.
Thanks

/test all

Retesting it

Hmm, it seems to fail with the same error :-(

Strimzi appears to have changed their primary branch from master to main. There is no longer a master branch, that would explain the error message.

@msfrucht Hmm, we did that change already in March. Do you know why is it trying to pull the Strimzi master branch? There are some old links in the description (which have redirects). But I guess it is not parsing the description. There is also the repository annotation which does not specify any branch. Can I specify the branch somewhere? Or is this a bug in the Operator Framework?

@scholzj My current suspicion based on the report you linked to is the pod's environment variables. The JOB_SPEC variable seems to setting the default branch to 'master', which is likely triggering some part of the pod's code to pull that branch after doing the git clone even though only branch 0.24 is the only one need.
See "base_ref": "master"
JOB_SPEC={"type":"presubmit","job":"pull-ci-operator-framework-community-operators-master-4.7-deploy-operator-on-openshift","buildid":"1410106911335911424","prowjobid":"6c6166bd-d963-11eb-ac6d-0a580a80056d","refs":{"org":"operator-framework","repo":"community-operators","repo_link":"https://github.com/operator-framework/community-operators","base_ref":"master","base_sha":"4ce54a3037ef15802771a97291432c9074356985","base_link":"https://github.com/operator-framework/community-operators/commit/4ce54a3037ef15802771a97291432c9074356985","pulls":[{"number":4148,"author":"scholzj","sha":"e0a394abd4f96b54a93d59a34fc55d5a164c0709","title":"community-operators strimzi-kafka-operator (0.24.0)","link":"https://github.com/operator-framework/community-operators/pull/4148","commit_link":"https://github.com/operator-framework/community-operators/pull/4148/commits/e0a394abd4f96b54a93d59a34fc55d5a164c0709","author_link":"https://github.com/scholzj"}]},"decoration_config":{"timeout":"4h0m0s","grace_period":"1h0m0s","utility_images":{"clonerefs":"gcr.io/k8s-prow/clonerefs:v20210629-a9e981a56e","initupload":"gcr.io/k8s-prow/initupload:v20210629-a9e981a56e","entrypoint":"gcr.io/k8s-prow/entrypoint:v20210629-a9e981a56e","sidecar":"gcr.io/k8s-prow/sidecar:v20210629-a9e981a56e"},"resources":{"clonerefs":{"limits":{"memory":"3Gi"},"requests":{"cpu":"100m","memory":"500Mi"}},"initupload":{"limits":{"memory":"200Mi"},"requests":{"cpu":"100m","memory":"50Mi"}},"place_entrypoint":{"limits":{"memory":"100Mi"},"requests":{"cpu":"100m","memory":"25Mi"}},"sidecar":{"limits":{"memory":"2Gi"},"requests":{"cpu":"100m","memory":"250Mi"}}},"gcs_configuration":{"bucket":"origin-ci-test","path_strategy":"single","default_org":"openshift","default_repo":"origin","mediaTypes":{"log":"text/plain"}},"gcs_credentials_secret":"gce-sa-credentials-gcs-publisher","skip_cloning":true,"censor_secrets":true}}
SIDECAR_OPTIONS={"gcs_options":{"items":["/logs/artifacts"],"bucket":"origin-ci-test","path_strategy":"single","default_org":"openshift","default_repo":"origin","mediaTypes":{"log":"text/plain"},"gcs_credentials_file":"/secrets/gcs/service-account.json","dry_run":false},"entries":[{"args":["ci-operator","--gcs-upload-secret=/secrets/gcs/service-account.json","--image-import-pull-secret=/etc/pull-secret/.dockerconfigjson","--lease-server-credentials-file=/etc/boskos/credentials","--report-credentials-file=/etc/report/credentials","--secret-dir=/secrets/ci-pull-credentials","--secret-dir=/usr/local/deploy-operator-on-openshift-cluster-profile","--target=deploy-operator-on-openshift","--variant=4.7"],"container_name":"test","process_log":"/logs/process-log.txt","marker_file":"/logs/marker-file.txt","metadata_file":"/logs/artifacts/metadata.json"}],"censoring_options":{"secret_directories":["/etc/boskos","/secrets/ci-pull-credentials","/etc/pull-secret","/etc/report"]}}

/test 4.7-deploy-operator-on-openshift

/merge possible

So, I figured out the problem after spending some time and digging through the CI code. It looks like I somehow by mistake pushed the commit which was in the PR into my fork twice. Once into the branch the PR is opened from and once into the master branch (in my fork). And it seems that https://github.com/operator-framework/community-operators/blob/2313f16f73e22ee38e5648885975cd76818af189/scripts/ci/openshift-deploy-core.sh#L81 is searching for the commit by sha checksum and gets reference to two branches instead of one. And that was causing the error.

authors: framework-automation msfrucht mvalarh scholzj


text:
Applying OLM CRDs fails due to last-applied-configuration annotation

Bug Report

What did you do?
A clear and concise description of the steps you took (or insert a code snippet).
Installing OLM CRDs via kubectl apply in the v0.21+ versions of OLM fails due to the size of the last-applied-configuration annotation that gets auto-appended to the object. See #2767 for more information.
What did you expect to see?
A clear and concise description of what you expected to happen (or insert a code snippet).
Successful installation
What did you see instead? Under which circumstances?
A clear and concise description of what you expected to happen (or insert a code snippet).
The CustomResourceDefinition "clusterserviceversions.operators.coreos.com" is invalid: metadata.annotations: Too long: must have at most 262144 bytes

Environment

operator-lifecycle-manager version:
v0.21+

Kubernetes version information:

Kubernetes cluster kind:

Possible Solution

Additional context
Add any other context about the problem here.
Solution requires potentially slimming down the OpenAPI schema that is generated by codegen.

Related, I noticed that operator-sdk olm install from latest version installs without errors, but the clusterserviceversions.operators.coreos.com CRD is not created. olm install uses https://github.com/operator-framework/operator-lifecycle-manager/releases/latest/download/crds.yaml to apply the CRDs, which also has this issue.

I'm going to close this original issue as a duplicate of #2695. Please follow that issue for more updates.

authors: anders-swanson exdx


text:
Corrected etcd CRD URL.

/cc @njhale
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /docs
[ ] Commit messages sensible and descriptive

Thanks for finding and fixing these links!
/lgtm
I'm going to manually merge this since it's doc only.


text:
Bug 1798135: Fix cases where an operator's ready channel may never close.

In at least three error/cancellation scenarios, an operator would
finish running without closing its ready channel. Users (i.e. olm,
catalog, and package-server) block first on <-o.Ready() and then on
<-o.Done(), so if the operator terminates without closing its ready
channel, they will block indefinitely, which prevents recovery via
automatic restarts.
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /docs
[ ] Commit messages sensible and descriptive

This looks great, thanks!
/lgtm

/retest

/hold

/hold cancel

/retest

/lgtm
/retest

/retest

/retest

/retest

/cherry-pick release-4.3
/cherry-pick release-4.2

/cherry-pick release-4.2

authors: benluddy exdx njhale


text:
Add properties and update validation to spec.hive.storage in the MeteringConfig CRD.

This PR adds the spec.storage.hive.sharedPVC.mountpath property, which was undefined previously.
I also needed to update the spec.storage.hive.azure properties to include variables used in the ansible-operator (for developmental purpose), which weren't specified in the documentation.

/lgtm
/approve

repo: operator-framework/operator-metering


text:
Fix type-o in test name.

Description of the change:
Fix type-o in test name.
I've also fixed a few other type-o's and spelling mistakes.
Motivation for the change:
#6085
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

@laxmikantbpandhare after running make test-sanity, I get a) a bunch of files that have been changed - either from make generate, or make fix.  I'm not sure why the changes, because they are all in files I didn't touch.
But the actual "errors" are lint errors.
internal/cmd/ansible-operator/version/cmd_test.go:19:2: SA1019: package io/ioutil is deprecated: As of Go 1.16, the same functionality is now provided by package io or package os, and those implementations should be preferred in new code. See the specific function documentation for details. (staticcheck)
	"io/ioutil"
	^
images/scorecard-test-kuttl/main.go:22:2: SA1019: package io/ioutil is deprecated: As of Go 1.16, the same functionality is now provided by package io or package os, and those implementations should be preferred in new code. See the specific function documentation for details. (staticcheck)
	"io/ioutil"
	^
internal/ansible/watches/watches.go:22:2: SA1019: package io/ioutil is deprecated: As of Go 1.16, the same functionality is now provided by package io or package os, and those implementations should be preferred in new code. See the specific function documentation for details. (staticcheck)
	"io/ioutil"
	^
make: *** [fix] Error 1

After merging master into this branch, and committing a couple of changes from make generate, make test-sanity passes.
@laxmikantbpandhare is it generally OK to push these changes?

@davidlanouette pushing up the merge with master is fine. We updated to Go 1.19 in a PR that got merged earlier today. In Go 1.19 the ioutil package was removed so we had to perform a whole bunch of changes to update our ioutil usage to another package. These are the same changes that you probably saw earlier when running make test-sanity prior to merging master.

After merging master into this branch, and committing a couple of changes from make generate, make test-sanity passes.
@laxmikantbpandhare is it generally OK to push these changes?

that's great. io/ioutil is already fixed as explained by @everettraven. If you did the rebase with master then it will work for sure.

repo: operator-framework/operator-sdk


text:
TOTP password and key separation

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I am convinced that mine is new.

Is your feature request related to a problem? Please describe.
OPNsense offers OTP as a secure additional option for logging on to the web interface. In this case, the password must be supplemented with the OTP key, either appended before or after the password. This causes some difficulties with long passwords and it is not clear for normal Users when to enter the OTP Key
Describe the solution you like
As a feature, I would like to ask if it is possible to have a separate OTP window pop up where the key must be entered. This window should appear after the username and password have been entered. In This way it is clear for every User when to enter the OPT Key and do not make problems with the Password
Describe alternatives you considered
It may also be possible to add an extra input field on the logon page for the OTP Key under the password field
PS
Thanks for your work, it is a grate firewall.

I am a +1 for this; password managers that support OTP are broken when there is no second prompt for the token

FreeNAS (another FreeBSD based appliance project) does a good job with this. When OTP is enabled, the website shows 3 input fields (user, pass, OTP) where the 3rd is optional for users without OTP enabled. Even SSH is configured with separate prompts when using password login:
$ ssh root@freenas
(root@freenas.local) Password for root@freenas.local:
(root@freenas.local) One-time password (OATH) for `root':

For OpenVPN, I think prepending (or appending) the OTP code is about the only option. But local system access could be improved.

@bobpaul  For OpenVPN it's a client setting (https://github.com/opnsense/core/commit/2c2eca7e2f25a46f96458e0d6d924541574cb9d8) https://github.com/opnsense/core/issues/3290

I am also +1 for this, see discussion here: https://forum.opnsense.org/index.php?topic=31478
Also, I have another good reason now for separating the input fields: At least one TOTP app allows for integration in your PC browser, but it empties the OTP input field first. Thus, OpnSense cannot interact with that plugin, regardless of token order,
I refer to "2FAS", which has the benefit of being able to keep the secrets on a separate device (smartphone), but still automating TOTP input, which is quite nice, IMHO. Normally you have to choose between a rock (security by using a separate device) and a hard place (convenience of using a TOTP app on the PC that can auto-fill fields).
I think it should not be too hard to separate the input fields for password and OTP. The tricky question is when to enable the TOTP input field (only when TOTP is an option w/r to selected authentication methods.

+1 from here. We have about 24 opnsense Boxes most of them reachable from the Internet to be remote mangaable. The missing extra field for the TOTP-Code makes our customers man usability problems. They simply forgot that they have to add it to the passoword field. A simple box for the code to be entered, can't be that hard?

authors: AdSchellevis JSuenram andrashorber bobpaul kquinsland meyergru

repo: opnsense/core


text:
security/acme-client: add support for deSEC.io API

Implements deSEC.io API
Took request #2057 as template. Unfortunately not testet, because no test infrastructure available here.
Thanks for merge!

my editor "corrected" wrong idents on AcmeClient.xml, hope this is not a problem?

I have no idea why you (incorrectly) renamed the file again in https://github.com/opnsense/plugins/pull/2120/commits/e26760021b9c9003a74af8845fb4cd03919f2c26, but I'll fix this post-merge ;)

Merged, thanks for your contribution!

@fraenki, I was confused about the whole desec/dedyn thing. Thanks for your help!

authors: bstaeheli fraenki

repo: opnsense/plugins


text:
Fix list item icon position

Summary of changes
The position of icon indicating whether a list item is added manually is fixed for empty list items. Further, the list item is extracted into a separate component.
Context and reason for change
Fix: #1374
How can the changes be tested
Before:

After:

Looks good. Just two minor suggestions:
1. We could prevent adding a new list item if only unsuitable characters are given, e.g., whitespace and dashes.

2. We could rename the new `ListWithAttributesListItem` component to `ListWithAttributesItem`. Having 'list' in the name twice sounds a bit redundant to me.

Regarding the first one, I've implemented it for white spaces. Would not do for "-". We would have to provide an exact requirement for package names instead. E.g. what about "?" or "r-t"?
Regarding the second one, this would clash with the respective type

@vasily-pozdnyakov created #1385

👍

authors: benedikt-richter lennartclaas

repo: opossum-tool/OpossumUI


text:
Add documentation for the --download_combined_frontend_spec_file flag

This PR does the following:

Adds documentation for the --download_combined_frontend_spec_file flad for the run_frontend_tests command to help developers debug errors.

@U8NWXD PTAL

repo: oppia/oppia-web-developer-docs


text:
Changes for Vagrant1.6+ and new vagrant-berkshelf version

Minor fixes to make 'vagrant up' work again with newer versions of Vagrant and vagrant-berkshelf
Thanks!

We're going to double down on test-kitchen and remove the vagrantfile. Thank you though!

authors: fgimenez jtimberman

repo: opscode-cookbooks/chef-server


text:
[COOK-3739] Unable to Configure Many AppPool Settings

Jira : https://tickets.opscode.com/browse/COOK-3739
I have added in a way to provide arbitrary application pool properties as a hash.  The key's and values should match what would be used in the command:
"autoStart" => "true", "recycling.periodicRestart.memory" => "512000"

This works well for me as it is straight forward to merge a hash from a data item over top cookbook defaults before passing along to the resource.

Superceded by #58.

authors: ProTip ksubrama

repo: opscode-cookbooks/iis


text:
Update index.md spelling fix

systen -> system

@dotnet-policy-service agree


text:
Add schema for resource manager

https://docs.cloud.oracle.com/en-us/iaas/Content/ResourceManager/Concepts/terraformconfigresourcemanager.htm

completed in #6


text:
GCC-Toolset images

With the release of Oracle Linux 8.5 we should see provision for the gcc-toolset 11. Previously, I think on 8.4 we had gcc-devtoolset 9. It would be good if there were images available for these tools, as Red Hat provide the following:
rhel8/gcc-toolset-11-toolchain, which includes the GCC compiler, the GDB debugger, and the make automation tool.
rhel8/gcc-toolset-11-perftools, which includes the performance monitoring tools, such as SystemTap and Valgrind.

I'll look into this once 8.5 is out.

@ol-roboro test images are now available via my fork. Would be great if you could take them for a spin before they're merged.

@Djelibeybi I tested a buildah build and podman run of each of toolchain and perftool and confirmed that when I entered the shell GCC was at version: gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1.2.0.1)

authors: Djelibeybi ol-roboro

repo: oracle/docker-images