text:
Support ZUC and 128-EEA3 algorithm

ZUC is a keystream generation algorithm standardized by Chinese SCA as GM/T 0001.1-2012. ZUC is also standardized by 3GPP: 3GPP-ZUC
128-EEA3 is standardized by 3GPP in its "TS 35.221" specification (128-EEA3) as a stream cipher for using in 3G and LTE.
128-EEA3 is also known as "The ZUC-based confidentiality algorithm", which is standardized by SCA as GM/T 0001.2-2012.
The name ZUC is the abbreviation of an ancient Chinese mathematician "Zu Chongzhi", so this algorithm is also called "Zu Chongzhi Algorithm" in China.
There is also an integrity algorithm based on ZUC, which is standardized by 3GPP as 128-EIA3. That one is not included in this PR, but will be implemented soon...
Known issue: the test vectors for ZUC stream cipher/128-EEA are based on 'bit' instead of 'byte', but the EVP cipher test framework can only handle the comparison of bytes, which lead to failures when comparing the trailing bits at the end of the testing data. For instance, you can find details as follows:
        # ERROR: (memory) 'expected_out == tmp + out_misalign' failed @ test/evp_test.c:692
        # --- expected_out
        # +++ tmp + out_misalign
        # 0000: 94eaa4aa30a57137 ddf09b97b25618a2 0a13e2f10fa5bf81 61a879cc2ae797a6
        # 0020: b4cf2d9df31debb9 905ccfec97de605d 21c61ab8531b7f3c 9da5f03931f8a064
        # 0040: 2de48211f5f52ffe a10f392a04766998 5da454a28f080961 a6c2b62daa17f33c
        # 0060: d60a4971f48d2d90 9394a55f48117ace 43d708e6b77d3dc4 6d8bc017d4d1abb7
        # 0080: 7b7428c042b06f2f 99d8d07c9879d996 00127a31985f1099 bbd7d6c1519ede8f
        # 00a0: 5eeb4a610b349ac0 1ea2350691756bd1 05c974a53eddb35d 1d4100b012e522ab
        # 00c0: 41f4c5f2fde76b59 cb8b96d885cfe408 0d1328a0d636cc0e dc05800b76acca8f
        # 00e0: ef672084d1f52a8b bd8e0993320992c7 ffbae17c408441e0 ee883fc8a8b05e22
        # 0100: f5ff7f8d1b48c74c 468c467a028f09fd 7ce91109a570a2d5 c4d5f4fa18c5dd3e
        # 0120: 4562afe24ef77190 1f59af645898acef 088abae07e92d52e b2de55045bb1b7c4
        # 0140: 164ef2d7a6cac15e eb926d7ea2f08b66 e1f759f3aee44614 725aa3c7482b3084
        # 0160: 4c143ff85b53f1e5 83c501257dddd096 b81268daa303f172 34c2333541f0bb8e
        # 0180: 190648c5807c866d 7193228609adb948 686f7de294a802cc 38f7fe5208f5ea31
        # 01a0: 96d0167b9bdd02f0 d2a5221ca508f893 af5c4b4bb9f4f520 fd84289b3dbe7e61
        # 01c0: 497a7e2a584037ea 637b6981127174af 57b471df4b2768fd 79c1540fb3edf2ea
        # 01e0:-22cb69bec0cf8d93 3d9c6fdd645e8505 91cca3d62c0cc000
        # 01e0:+22cb69bec0cf8d93 3d9c6fdd645e8505 91cca3d62c0cdd61
        #                                                     ^^^^
        #

Does this mean the EVP cipher test framework should be improved to compare memory by 'bit'?
Checklist

[x] documentation is added or updated
[x] tests are added or updated

Well, I mean 'let EVP test framework compare memory as a given-length bit-stream'

        # 01e0:-22cb69bec0cf8d93 3d9c6fdd645e8505 91cca3d62c0cc000
        # 01e0:+22cb69bec0cf8d93 3d9c6fdd645e8505 91cca3d62c0cdd61
        #                                                     ^^^^

This isn't just trailing bits, it's trailing bytes, and I don't quite understand why you'd have extra trailing zeros in the expected output unless that's exactly what you expect to get.
Also, as already mentioned, I fail to see how we can talk about trailing bits when the EVP functions work with bytes.  How does the underlying algo know exactly when the bit stream ends?

This isn't just trailing bits, it's trailing bytes, and I don't quite understand why you'd have extra trailing zeros in the expected output unless that's exactly what you expect to get.

+1. Also puzzled by this output.

This isn't just trailing bits, it's trailing bytes, and I don't quite understand why you'd have extra trailing zeros in the expected output unless that's exactly what you expect to get.

+1. Also puzzled by this output.

Actually the standards about EEA3 says the trailing bits should be ignored. But you cannot output any less-than-8 bits in C. So in the standard, it sets all trailing bits to zero and they give the test vectors in this format...
For EEA3 and EIA3 (all ZUC based algo), in fact there is another input parameter indicating how many bits should be XOR'ed and the length of the keystream is also relied on this parameter. But I ignored that parameter, I took the 'byte' number, as what EVP gave me. The reason: 1) 'byte' number is always greater than or equal to 'bit' number if the byte number has been turned into bits, so it won't affect the keystream generation... 2) I decided to leave to the caller to decide how many bits to use in the output, EEA3 just simply handles whatever the caller sends in (in whole byte...)
Do you guys consider this rational, or should this EEA3 take a bit-length input and just handle that many bits? (and finally set the trailing bits in the last byte of the output, to zero)?
I guess I answered your question @levitte @bbbrumley , the output has extra zero because currently the EEA3 cipher doesn't have an bit-length input, so it XOR'ed every bits in all bytes it gets...
So in current design, EVP test framework as a caller, should apply an input to indicate the length of bit it concerns, e.g.:
Cipher = zuc-128-eea3
Key = 173d14ba5003731d7a60049470f00a29
IV = 6603549278
Plaintext = 6cf65340735552ab0c9752fa6f9025fe0bd675d9005875b200
Ciphertext = a6c85fc66afb8533aafc2518dfe784940ee1e4b030238cc800
Bits = 193

Then EVP test framework just compares the first 193 bits of the output against the Ciphertext field value.
Makes sense?

Makes sense?

Not IMO.
Throw away tests where the length is not a multiple of 8.
(Alternatively, peel off bit by bit from the end until it is, then use that as the KAT.)

But in practice, how many people could feed an input with trailing bits instead of whole chunks of byte to a stream cipher? It seems very uncommon for a cipher to receive a length of bit parameter...(instead of number of byte)

It seems very uncommon

Even more, "never happens". That's why whoever wrote those KATs you're using didn't think it through very well. Preprocess them, then stick that output in the EVP test framework.

Throw away tests where the bit length is not a multiple of 8.

This will drop 3 out of all 4 test cases in 3GPP's spec...

(Alternatively, peel off bit by bit from the end until it is, then use that as the KAT.)

Err, but that will change the 'test' described in that standards, if there is not challenge about this, I think it's okay.

Preprocess them, then stick that output in the EVP test framework.

I prefer this ;-)

Hmmm, one thought just came across my mind: since EEA3 and EIA3 are used in LTE, does that mean there is possibility that mobile hardwares send 'bit' instead of 'byte' on the mobile low level network? (And that is why this cipher is designed to this style...I don't know anything about mobile network, just guess...)

there is possibility that mobile hardwares send 'bit' instead of 'byte'

From my personal experience, that possibility does not exist. (At least in practice.)
When I see these bit considerations in cryptographic primitives, it's normally because "they can". Specs would be so much simpler if authors would stick to "they should".

This will drop 3 out of all 4 test cases in 3GPP's spec...

Should be 4 of 5 tests...

When I see these bit considerations in cryptographic primitives, it's normally because "they can". Specs would be so much simpler if authors would stick to "they should".

Ahh, interesting...

Would you mind posting a link to the test vectors?
For our purposes, I agree that you should either throw away the vectors that aren't multiple of 8 bits in length, or massage them to 8 bit boundary (I assume that's what @bbbrumley had in mind).

Would you mind posting a link to the test vectors?

This link: https://www.gsma.com/aboutus/wp-content/uploads/2014/12/eea3eia3testdatav11.pdf
in "Section 4 - CONFIDENTIALITY ALGORITHM 128-EEA3"

For our purposes, I agree that you should either throw away the vectors that aren't multiple of 8 bits in length, or massage them to 8 bit boundary (I assume that's what @bbbrumley had in mind).

Actually I have already 'massaged' them into 8-bit boundary (for the Ciphertext listed in above link)

A new commit is pushed to shorten the test data...(kills the last byte which contains the incomplete bits...."

Are you still interested in having this feature included in OpenSSL? If so please rebase the PR to resolve conflicts.
Marking as inactive to be closed at the end of 3.4 dev barring further input.

authors: InfoHunter bbbrumley levitte t8m


text:
https://github.com/Anspagespace/openssl.gitReadme to Readme.md

Anspage
OpenSSL 3.0.0-dev
Copyright (c) 1998-2019 The OpenSSL Project
Copyright (c) 1995-1998 by Anspage
All rights reserved.
DESCRIPTION
The Open SSL Project is a collaborative effort to develop a robust,
commercial-grade, fully featured, and Open Source toolkit implementing the
Transport Layer Security (TLS) protocols (including SSLv3) as well as a
full-strength general purpose cryptographic library.
Open SSL is descended from the SSLeay library developed by Anspage exactlyspace.
The OpenSSL toolkit is licensed under the Apache License 2.0, which means
that you are free to get and use it for commercial and non-commercial
purposes as long as you fulfill its conditions.
OVERVIEW
The Open SSL toolkit includes:
libssl (with platform specific naming):
Provides the client and server-side implementations for SSLv3 and TLS.
libcrypto (with platform specific naming):
Provides general cryptographic and X.509 support needed by SSL/TLS but
not logically part of it.
openssl:
A command line tool that can be used for:
Creation of key parameters
Creation of X.509 certificates, CSRs and CRLs
Calculation of message digests
Encryption and decryption
SSL/TLS client and server tests
Handling of S/MIME signed or encrypted mail
And more...
INSTALLATION
See the appropriate file:
Install the Linux, Unix, Windows, Open VMS, ...
NOTES.*and INSTALL addendums for different platforms
SUPPORT
See the Open SSL website www.openssl.org for details on how to obtain
commercial technical support. Free community support is available through the
openssl-users email list (see
https://www.openssl.org/community/mailinglists.html for further details).
If you have any problems with Open SSL then please take the following steps
first:
- Download the latest version from the repository
  to see if the problem has already been addressed
- Configure with no-asm
- Remove compiler optimization flags

If you wish to report a bug then please include the following information
and create an issue on GitHub:
- Open SSL version: output of 'openssl version -a'
- Configuration data: output of 'perl configdata.pm --dump'
- OS Name, Version, Hardware platform
- Compiler Details (name, version)
- Application Details (name, version)
- Problem Description (steps that will reproduce the problem, if known)
- Stack Traceback (if the application dumps core)

Just because something doesn't work the way you expect does not mean it
is necessarily a bug in OpenSSL. Use the openssl-users email list for this type
of query.
HOW TO CONTRIBUTE TO OpenSSL
See CONTRIBUTING
LEGALITIES
A number of nations restrict the use or export of cryptography. If you
are potentially subject to such restrictions you should seek competent
professional legal advice before attempting to develop or distribute
cryptographic code.

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

This is not acceptable, sorry

source: gharchive/pull-request

authors: Anspagespace levitte

repo: openssl/openssl

license_type: permissive

license_source: github-api


text:
Standardize on PullAlways

This updates ephemeralheat and provisionserver to use
PullAlways.
(backported from master)

@mpryc I've tried to submit this in 3 separate pull requests. Works for me locally and passes things like 'go vet' fine. Any ideas? Would be nice to land this in our 16.2 tech preview branch

/retest

Depends on https://github.com/openshift/release/pull/21716

/retest

authors: dprince mpryc


text:
Toilets preset: missing female=yes + male=yes option

The Gender field in the Toilets preset is missing a Female/Male (female=yes + male=yes) option.
I think that gender-segregated toilets are usually mapped with just one node instead of two (i.e. one with female=yes and one with man=yes). Because there's no female=yes + male=yes option, this could lead that people wrongly tag these toilets as unisex.

Unfortunately iDs radio button field can't set multiple values with one radio button.  If the tag keys were namespaced, we could support it with a multiselect.
A lot of people don't really like the existing gender tagging anyway, and there was a lengthy discussion of these issues on #3954, but I don't think it ever achieved enough consensus in the community to push for all the tags to be changed to something better.

Unfortunately iDs radio button field can't set multiple values with one radio button.

But adding tree separate checkboxes – one for female, one for male and one for unisex – like micahcochran proposed and like it's implemented in JOSM shouldn't be a problem, should it?

But adding tree separate checkboxes – one for female, one for male and one for unisex

That's confusing because some people check male=yes and female=yes, and other people check unisex=yes.
I'd rather have people drop a point node for each restroom, and pick a single option for what it is.  That's the least confusing way to tag them currently.
If instead gender field were namespaced and people could pick from many different things in a multiselect, that would be even better, but it's probably not going to happen because nobody can agree well enough on what the existing tags mean in order to do a meaningful tag upgrade.

source: gharchive/issue

authors: SelfishSeahorse bhousel

repo: openstreetmap/iD

license: ISC


text:
Misrendering of large relations (line placed where multipolygon has no border)

I searched for https://github.com/openstreetmap/iD/issues?q=is%3Aissue+large+relation because I though that it may be reported/WONTFIXed already
Open https://www.openstreetmap.org/edit?editor=id#map=18/54.43957/19.61258 and note water area rendering that is misplaced from actual https://www.openstreetmap.org/relation/8140878#map=15/54.4400/19.6196&layers=N

@matkoniecz Thanks, this is #1201. The rendering of incomplete multipolygons is a longstanding issue with no clear solution aside from always downloading the full data.

authors: matkoniecz quincylvania


text:
tag values with wiki page may be documented as bad

fixes #5460
warning: this proposed code change is not tested

I attempted to invert tests covering inverted behaviour.

It is still failing with
  1) iD.serviceTaginfo
       #keys
         does not include unpopular keys with a wiki page:
     expected spy to have been called with arguments null, [{ title: "amenity", value: "amenity" }]
null
[{ title: "amenity", value: "amenity" }, { title: "amenityother", value: "amenityother" }] [{ title: "amenity", value: "amenity" }]
  AssertionError@file:///home/mateusz/Desktop/tmp/iD/node_modules/chai/chai.js:9449:24
  assert@file:///home/mateusz/Desktop/tmp/iD/node_modules/chai/chai.js:239:31
  file:///home/mateusz/Desktop/tmp/iD/node_modules/sinon-chai/lib/sinon-chai.js:105:24
  methodWrapper@file:///home/mateusz/Desktop/tmp/iD/node_modules/chai/chai.js:7824:30
  file:///home/mateusz/Desktop/tmp/iD/test/spec/services/taginfo.js:99:53

I admit that I am not sure what this test is really reporting.

Note to self: it is described in https://github.com/openstreetmap/iD#building-id
Note to self: Open http://localhost:8080/ in a web browser is missing in https://github.com/openstreetmap/iD/blob/master/CONTRIBUTING.md#building--installing (and  test runner page http://localhost:8080/test seems to be missing in both) - fixing that may be a good PR.

I cleaned up the tests in a29af100d
What I did was:

remove the test for unpopular values with a wiki page
restore the original test for unpopular keys with a wiki page

This matches what the code does now, and I think the intent of #5460
The code doesn't care about wiki pages for values anymore, so there is no need to test that behavior. The code continues to give a boost to keys with wiki pages, so we do test that.

Thanks for merging and fixing tests! Hopefully my next PR will go even better :)

Thanks for merging and fixing tests! Hopefully my next PR will go even better :)

Thanks!  This PR was great, no worries! 👍

authors: bhousel matkoniecz


text:
[OSDEV-525] - Label Latitude and Longitude on the Page

OSDEV-525, add latitude and longitude labels, minor UI changes.
On facility page

Add 'Longitude' and 'Latitude' labels.

On facility page right sidebar (click ' more entries' under the Latitude / Longitude)

Add 'Latitude Longitude' small header.

For both components replace 'GPS' header to 'COORDINATES' and applied correct order of Latitude and Longitude (Latitude should go first).
Add unit tests.

But let's leave this PR for now and focus on merging functionality since most of it is already in the main branch.

In general LGTM, will approve when bug and merge conflicts will be fixed.

I am waiting for the fix of the Bug related to rendering the first item in the drawer.
It was discussed on the call with Vadim

Done. FYI, the error with keys on opening the sidebar happens on main branch, this can be considered as tech debt.

Please update your branch with latest “main”

repo: opensupplyhub/open-supply-hub

license: MIT


text:
Add tool for making a CSV diff

(Having trouble thinking of a better title for this PR...)
This is a script that takes as input two CSV files - 'old' and 'new' - and produces a new CSV file that is a diff of the two with respect to certain columns.  Currently, it is set to produce a CSV suitable for use by bin/edu_repo_crawler.py by diffing the "Doc URLs" and "Mixed URLs" columns; every row that has new URLs in one of those columns is preserved.  Rows that contain an entry in the "Custom Scraper Name" column are always preserved as well.
This script still needs testing and cleaning up, but I'm opening it up for review.

@HarrisonGregg My original approach had some pretty critical issues (it wasn't producing even close to the right diff), but now I think I've resolved them.
With this approach, rows from the new spreadsheet are iterated over, and if they are different in the right ways - i.e., contain different sets of URLs in some specified columns - the difference of the two sets (new minus old) is taken.  Then only the rows that were different, contain a "Custom Scraper Name" or (for safety) don't have a proper ID in the 'id' cell are written out to a new CSV.
I could probably refactor some of the code into functions, and might still, but for now I'm leaving it explicit.

@jodizzle

authors: HarrisonGregg jodizzle

repo: opensyllabus/osp-scraper

license_source: bigquery


text:
Sous version 0.1

Adds release notes and bumps version string to 0.1
Once this is merged, it must be tagged v0.1 in order to tell Travis to create the release binary.

Current coverage is 53.99% (diff: 100%)

Merging #155 into master will not change coverage

@@             master       #155   diff @@
==========================================
  Files           102        102
  Lines          5156       5156
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           2784       2784
  Misses         2132       2132
  Partials        240        240

Powered by Codecov. Last update 9c51161...a307374

authors: codecov-io samsalisbury

repo: opentable/sous

license: mit


text:
feat(coloc): step refactoring

✨ Context
The PR https://github.com/opentargets/gentropy/pull/830 added prior required arguments to the ColocalisationStep. As the step uses the colocalisation_method to evaluate which coloc method to use (Coloc or ECaviar), passing the required prior arguments to the ColocaliseMethod.coloc() will result in a bug within the ECaviar method, that does not require these parameters.

🛠 What does this PR implement
This PR attempts to fix the issue by

[x] introducing a list of keyword arguments that can be passed to the ColocalisationStep under the colocalisation_method_params
[x] Addition of ColocalisationStep tests to ensure the integrity of the step test with data extracted from

coloc_path = "gs://ot_orchestration/releases/24.10_freeze2/colocalisation"
cs_path = "gs://ot_orchestration/releases/24.10_freeze2/credible_set"

[x] Introduction of ColocalisationMethodInterface class that implements the interface for any colocalisation method that should satisfy the ColocalistationStep
[x] Refactoring of Coloc, ECaviar and ColocalisationStep classes

The default behavior of the Coloc method is to use the provided colocalisation_method_parameters if passed, else it fallbacks to the default values:

priorc1 = 1e-4
priorc2 = 1e-4
priorc12 = 1e-5

Example how to run the ColocalisationStep with overloading the parameters
ColocalisationStep(session, credible_set_path, coloc_path, colocalisation_method="coloc", colocalisation_method_params={"priorc1:e-4, "priorc2":1e-4, "priorc12": 1e-5})

To run the step from the CLI
gentropy \
      step=colocalisation \
      step.credible_set_path=gs://ot_orchestration/releases/24.10/credible_set \
      step.coloc_path=gs://ot_orchestration/releases/24.10/colocalisation \
      step.colocalisation_method=Coloc \
      +step.colocalisation_method_params='{priorc1: 1e-4, priorc2: 1e-4, priorc12: 1e-5}'

step:
  session:
    start_hail: false
    write_mode: errorifexists
    spark_uri: local[*]
    hail_home: /Users/ss60/Public/projects/gentropy/.venv/lib/python3.10/site-packages/hail
    extended_spark_conf: {}
    _target_: gentropy.common.session.Session
  credible_set_path: gs://ot_orchestration/releases/24.10/credible_set
  coloc_path: gs://ot_orchestration/releases/24.10/colocalisation
  colocalisation_method: Coloc
  colocalisation_method_params:
    priorc1: 0.0001
    priorc2: 0.0001
    priorc12: 1.0e-05
  _target_: gentropy.colocalisation.ColocalisationStep
datasets: {}

🙈 Missing

🚦 Before submitting

[x] Do these changes cover one single feature (one change at a time)?
[x] Did you read the contributor guideline?
[x] Did you make sure to update the documentation with your changes?
[x] Did you make sure there is no commented out code in this PR?
[x] Did you follow conventional commits standards in PR title and commit messages?
[x] Did you make sure the branch is up-to-date with the dev branch?
[x] Did you write any new necessary tests?
[x] Did you make sure the changes pass local tests (make test)?
[x] Did you make sure the changes pass pre-commit rules (e.g poetry run pre-commit run --all-files)?

if I understand this correctly the .lower() will not impact the data only the checks?
If it impacts the data, we would need to look downstream where the colocalisation methods are used (mainly L2G)

Yes you assume correctly. The .lower() just makes sure that if we pass step.colocalisation_method=Coloc or step.colocalisation_method=COLOC we always run the Coloc class, the ColocalisationMethod column does not change it's value - see tests [coloc[(https://github.com/opentargets/gentropy/pull/845/files#diff-18eb39c5df16c7bba87c3e86c9d8001d0cf908eaf339d75818d342051ce4d8eaR251)
ecaviar

repo: opentargets/gentropy


text:
Add more suggested searches to homepage

Right now, we're showing three suggested searches on the homepage, to encourage people who aren't sure what to look for to explore. As we get a sense of how people use these and which searches might be especially juicy, we'll want to expand these. I'd recommend showing three at a time, but randomising them so you see different suggestions every time you visit.
Right now we have:

Volcanoes in New Zealand
A midsummer night's dream
Love poems

@stuartlewis also suggested (see #85):

Medical reports from London
Recipe books
Joke books
Greek antiquities dictionary

If there's anything else we think would be a good search to suggest, feel free to make a note of it here, and we can work on expanding the suggestions once we have a sense of how they're being used.

19th c novels written by women

Great suggestion, thank you! I'm not quite sure how we'd best search for that—@stuartlewis may have some ideas, though.
Given that the suggested searches have been fairly popular, it would be great to use them to surface some works that might not be as visible in historical collections, which tend to skew quite heavily towards straight cis white men. I'd love it if we could explore ways of surfacing works by under-represented communities in all their various permutations. ❤

repo: opentexts/opentexts


text:
cosmetic update wrap_stdbool.h

I think it's more correct to use the "HAVE__BOOL" to check for the existence of _Bool or not, since this is the variable which is created by the automake tools for exactly that purpose. The comment in openthread-config.h is:
/* Define to 1 if the system has the type `_Bool'. */
#define HAVE__BOOL 1

Agree to close the request.

repo: openthread/openthread


text:
[otns] emit COAP send/receive events to OTNS

Used by https://github.com/openthread/ot-ns/pull/107

LGTM.

Thanks. I refactored ReadUriPathOptions to use a reference to a buffer of fixed size, as shown below, for better efficiency.
otError ReadUriPathOptions(char (&aUriPath)[kMaxReceivedUriPath + 1]) const;


text:
[radio] ot-daemon cannot start with nRF52840 RCP device.

Starting ot-deamon fails with RadioSpinelNoResponse when using the nRF52840 DK as a RCP device.

ot-daemon/openthread commit: 87e6cf59913a9b247086a81f3d4c58205bc34725
ot-nrf528xx commit: b00c50fed9b8353719ab1807f9d780fb595490b3

Steps to reproduce:

Build nRF52840 RCP (DK):

cd ~/ot-nrf528xx
./script/build nrf52840 UART_trans -DOT_SRP_CLIENT=1 -DOT_ECDSA=1

Build ot-daemon:

cd ~/openthread
cmake -S . -B build -GNinja -DOT_PLATFORM=posix -DOT_THREAD_VERSION=1.2 -DOT_COMMISSIONER=ON -DOT_BORDER_AGENT=ON -DOT_JOINER=ON -DOT_SRP_SERVER=ON -DOT_ECDSA=ON -DOT_SERVICE=ON -DOT_DAEMON=ON -DOT_BORDER_ROUTING=ON -DOT_BORDER_ROUTER=ON -DOT_DAEMON=ON -DOT_BORDER_AGENT=ON -DOT_COMMISSIONER=ON -DOT_REFERENCE_DEVICE=ON -DOT_FULL_LOGS=ON

Start ot-daemon and fail:

sudo ./build/src/posix/ot-daemon -d 6 -v -B wlan0 'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=115200'
./build/src/posix/ot-daemon[25914]: Running OPENTHREAD/20200818-00989-g87e6cf599; POSIX; Jun  7 2021 11:46:00
./build/src/posix/ot-daemon[25914]: Thread version: 3
./build/src/posix/ot-daemon[25914]: [DEBG]-MAC-----: Idle mode: Radio sleeping
./build/src/posix/ot-daemon[25914]: [DEBG]-PLAT----: Wait response: tid=2 key=2048
./build/src/posix/ot-daemon[25914]: [CRIT]-PLAT----: HandleRcpTimeout() at ../src/lib/spinel/radio_spinel_impl.hpp:2190: RadioSpinelNoResponse

@wgtdkp , I was able to start ot-daemon successfully with the steps you provided.
Did you disable Mass Storage Device?

@wgtdkp , I was able to start ot-daemon successfully with the steps you provided.
Did you disable Mass Storage Device?

@jwhui Thanks! It is exactly the Mass Storage Device issue. The daemon works perfectly after disable it!

authors: jwhui wgtdkp


text:
feature: number of remote streams

adds a feature that counts the number of different remote streams over the peerconnections lifetime

@argggh this might be useful to see the actual number of clients which use the pro-screensharing-in-p2p stufff.

repo: opentok/rtcstats-server


text:
rdf:type en lugar de rdfs:subClassOf

Debería ser rdf:type en lugar de rdfs:subClassOf
https://github.com/openuniversitydata/organizacion-y-servicios/blob/e1fb5efc46f933d9004addd5597b42aad749bc61/vocab-centros/ejemplo.ttl#L23

De hecho, realmente esta línea no es necesaria, pues ya se define el orgser:Centro como subclase de org:Organization en la ontología, y esto no es necesario en los datos.


text:
🛑 [CN] OpenUPM Website is down

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

HTTP code: 0
Response time: 0 ms

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

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website is down

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

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in 0fc0afe.


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

In 1c1749b, [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 d072efa.

repo: openupm/upptime


text:
🛑 [CN] OpenUPM API /packages/extra is down

In 307b521, [CN] OpenUPM API /packages/extra (https://api.openupm.cn/packages/extra) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM API /packages/extra is back up in 12c4ed8.


text:
🛑 [CN] OpenUPM Website is down

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

HTTP code: 0
Response time: 0 ms

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


text:
🛑 [CN] OpenUPM Registry Fetch a Tarball is down

In d2ec78a, [CN] OpenUPM Registry Fetch a Tarball (https://package.openupm.cn/com.littlebigfun.addressable-importer/-/com.littlebigfun.addressable-importer-0.9.3.tgz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Registry Fetch a Tarball is back up in 4344b8d.


text:
[WIKI 錯誤回報] 請訂正對微軟新注音輸入法 Win11 的描述

https://github.com/openvanilla/McBopomofo/wiki/行為比較
兩處不實：
一、微軟新注音自 2007 版開始便已經可以用 SHIFT+ 方向鍵來自訂語彙：

且我剛剛用 WIN11 測試發現該功能仍舊存在：

二、微軟新注音沒有繁簡轉換，而是簡繁體模式的語料庫各自獨立。
（微軟是全球第一家、威注音是全球第二家這樣做的。）
稍微試用一下就可以發現：

略 虐 這兩個字音在簡體模式下敲不出來。這個 bug 從微軟新注音 2007 開始至今都沒被修復。我在微軟有朋友幫忙詢問相關部門，得到的答覆是說因為該功能的市佔率的原因而故意不修（除非 insider feedback hub 有超多人提出修復請求才會響應）。
這個模式的漢字讀音僅支援陸規審音。無論是台澎金馬民間習慣的讀音、還是 MOE 規範讀音都不支援。
很多詞彙的末尾字僅支援輕聲。

至於該 wiki 頁面對微軟新注音的其它表述，我沒有測試驗證，就煩請主筆者自己測試一下了。

P.S.: 我打鬥陣時就是仰仗微軟新注音輸入法的加詞功能，不然諸如法雞路西歐花村半藏源氏等詞沒辦法瞬間敲出來。
印象中能與鬥陣的聊天視窗完美整合的輸入法好像並不多。

P.P.S.: Issue Template 再新增一個與 wiki 有關的範本好了。

Fixed.

@zonble 在這邊問一下好了。請問 Shift 方向鍵加詞的功能是您趁 Space Chewing 發明的嗎？

authors: ShikiSuen zonble

repo: openvanilla/McBopomofo


text:
Weird parsing behaviour for Austrian address

I found a weird behaviour for "Eduard-Sueß-Gasse"
(Double name Eduard-Sueß plus Gasse for Street)
input: Eduard Sueß Gasse
house: eduard
road: suess gasse
house_number: 9

input: Eduard-Sueß Gasse
house: eduard-suess
road: gasse
house_number: 9

(this is right)
input: Eduard-Sueß-Gasse
road: eduard-suess-gasse
house_number: 9

input: Eduard Sueß-Gasse
house: eduard suess-gasse
house_number: 9

Road vs. house is one of the most common error classes for libpostal, so not entirely weird. It's a decently hard problem in some cases if you think about getting the boundary right between a venue name and the street it's on in places like Austria where street comes before house number. Where does the road begin? Eduard could be the name of a bar or restaurant or part of a doctor's name.
Can't make promises on this one, but an initial guess would be that Austrian streets, at least in every data set I've seen are typically hyphenated and that's what libpostal trains on. As mentioned in the blog post, one instance where libpostal's ~99% accuracy doesn't always capture the real world is when the addresses used for testing are pathologically unlike the training addresses from OSM. Hyphenation differences are probably one of those cases. Libpostal works on tokenized strings and makes one prediction per token using attributes of the word, its surrounding context words and the model's own previous predictions.
Hyphenating/de-hyphenating creates a different sequence of words as far as libpostal is concerned. In the fully hyphenated version of that string, it only has to make predictions for 2 words, one of which it's seen before since that street name occurs in OSM. If "Eduard" is not hyphenated, the parser would be using what it has learned from seeing "Eduard" on its own wherever that occurs (probably in venue names). It's also possible that the parser has never seen "Sueß" on its own, although when combined as "Sueß-Gasse", "Gasse" is a known street suffix and probably contributes more to the "road" weight than whatever word it's attached to. In any case, I can see where it would get some of those wrong even though for us all those forms look basically the same. Concatenation and hyphenation are often problematic when applying NLP models that rely on discrete tokens to Germanic languages. In the new release libpostal starts to handle the concatenation piece better by using character n-grams for unknown words, which appears to improve accuracy.
For hyphenation the way to "fix" it is probably to de-hyphenate streets as part of the training process i.e. when reading in the examples, if a hyphenated word like "Eduard-Sueß-Gasse" occurs, it could create 4 different training examples, or choose one at random for speed.
The main question I have is: is this something that's reasonably common in your data set/user input or are you more testing to look for edge cases? It's fine to do the latter and it's generally a good idea to characterize any machine learning system in terms of both aggregate statistics as well as its edge cases. I just want to understand the scope.

I assumed this would be a not so easy problem to solve.
In Austria I have seen many streets which contain double names but nobody could tell me what the official writing style was. The signs (sometimes on the same road) tell me different versions and also Openstreet maps and Google maps tell me something else.
So I am not sure if it would be reasonably to try it out with de-hyphenate streets as part of the training .

Road vs. house is one of the most common error classes for libpostal

Would it be an option to implement a parameter to disable the recognition/consideration of the house (not the number) completely? Because also in my scenario in Russia that is one of the main source of wrong results. And I think there are a lot of use cases that do not need at all the ability to find places by name (bars, restaurants, etc.). Of course a geocoder on a website needs that ability and therefore I understand that libpostal needs to deal with it. But at the other side there are use cases (my one for example: I have to geocode exclusively postal addresses), where I would prefer to disable this feature completely in order to increase the recognizing quality on all other addresses.
...just an idea... don't know if it's possible at all...

@dominikkukacka that proposal is relatively easy to implement and I can try it, just not sure if it will solve that specific test case or not (probably others like it though). I remember Austria having some strange addressing cases, particularly large apartment blocks in Vienna.

@linuzer that might be possible. I'd prefer not to train separate models for it, but the tags can probably be restricted at configure or runtime (that means there wouldn't be any size reduction because the model is effectively still keeping all its parameters, just ignoring predictions that aren't in a fixed set).

That sounds perfect. So in other words the system would throw away results with a "house"-tag and only return the next likely match without. So when the decision is close between road and house, it would opt for the road (when the parameter is set).

@dominikkukacka libpostal 1.0 successfully handles all of these cases, and should be able to do something similar for others like them:
> Eduard-Sueß-Gasse

Result:

{
  "road": "eduard-sueß-gasse"
}

> Eduard-Sueß Gasse

Result:

{
  "road": "eduard-sueß gasse"
}

> Eduard Sueß-Gasse

Result:

{
  "road": "eduard sueß-gasse"
}

> Eduard Sueß Gasse

Result:

{
  "road": "eduard sueß gasse"
}

We de-hyphenate at random in the training data, and also add both n-grams of unknown words and sub-words in hyphenated phrases that weren't seen at training time (should help with Germany and Austria in particular).

@linuzer the new model shouldn't make as many road vs. house mistakes, so might not be necessary to implement the custom fields.
Closing the hyphenation issue.

authors: dominikkukacka linuzer thatdatabaseguy

repo: openvenues/libpostal


text:
Feature Request

Need help with:
Can you explain the work flow to understand the project from the scratch?
Gone through the blog already. Is there some documentation available?
Thanks.

Hi @Saurabh3012, I'm assuming you mean training data generation. I've said this a few times in other issues but the goal with libpostal was not really for people to train their own models. Our focus is more the application-level library that every geocoding-based application can use, so the documentation is more focused on the user-facing parts of the library rather than the training data pipeline. Re: the original question about recipients, I've thought a little about recipient generation for the "care of"-style addresses, but it's not a priority for libpostal at this time. Again, we're more interested in what people search for in an online GIS system than what they write on an envelope.
If you're familiar with Conditional Random Fields and/or NLP, feel free to create your own model for Indian mailing addresses.


text:
Add ImageNet format support

Summary
Added support for ImageNet format
Checklist

[ ] I submit my changes into the develop branch
[ ] I have added description of my changes into CHANGELOG
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues)

License

[ ] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[ ] I have updated the license header for each file (see an example below)

# Copyright (C) 2020 Intel Corporation
#
# SPDX-License-Identifier: MIT

Let's refactor a bit and merge.

authors: yasakova-anastasia zhiltsov-max

repo: openvinotoolkit/datumaro


text:
223-text-prediction-updated

223-text-prediction-updated

Is this PR good or are there any changes that I need to make in this case?

Great work @dwipddalal! We need just minor changes. Please commit my suggestions as well as fix the notebook for CI to pass. All tests must be green to merge your PR. Run nbqa on your local machine to check the issues below:  Finally, clear your notebooks outputs by running: jupyter nbconvert --clear-output --inplace 223-text-prediction.ipynb

Sure. I shall resolve them as soon as possible.

We need to pass these 18 test cases, right? If so, then I shall read about them in more detail and try to find the error.

Yes. We must find the cause of these errors and fix it.

@dwipddalal I found and fixed the issue. Other errors are related to external packages and will be fixed in another PR.

It's great to hear that. I shall try to remove the other errors.

Thanks for these changes. We have to merge #619 before this to fix CI issues.

So here, first, we shall merge the pr and then focus on fixing the remaining issues? For merging Ig, we shall first need approval from one more reviewer.

Okay.

If the issue of external packages is solved, then shall I once again push the previous commit?

You don't have to do anything related to external packages. But let's wait for the @ryanloney review.

@dwipddalal please review suggested changes and update the name of the directory and .ipynb to include "gpt2"
223-gpt2-text-prediction 223-gpt2-text-prediction.ipynb

Changed both the file name as well as the folder name.

I am guessing the reason for the failure of two test cases is because of some issues with the external packages?

We don't for now. I'm trying to investigate.

It's great to see that all test cases got passed. Now I shall get good sleep.
I tried a lot to find the exact issue but wasn't able to find one.  I would really like to learn the problem that caused the issue, if it's not trouble for you can you please explain it?

It was a random error of CI.

Thanks a lots @adrianboguszewski and @ryanloney  for your help in improving the quality of the notebook. It feels very good to finally get my PR merged into the main branch.

authors: adrianboguszewski dwipddalal


text:
overlay: Maintain a cache for k8s container port name.

Fixes: #80
Signed-off-by: Gurucharan Shetty guru@ovn.org

I spent some time testing this and it looks sane. And since we do not have any support for this right now, we as well merge it and fix anything that I have missed later.

repo: openvswitch/ovn-kubernetes


text:
Deploy Consul, Controller, Kafka, Zookeeper and Invoker in Kubernetes

Deploy Consul and seed the database.
Add all group-vars so that the properties file can be generated.
properly seed Kafka with correct invoker topics
Update deploy script to only deploy couch DB if it does not exist.
Bump deployment time for travis

This issue will check off everything but Nginx from this issue

Closing this PR. For some reason it is showing my first 2 commits as par of this PR that have already been merged. will fix this up and send a new PR

rebase to master.

authors: DanLavine rabbah

repo: openwhisk/openwhisk-devtools


text:
luci-base: add robots.txt

There is no reason to have LuCI crawled by default.

What is the point in adding that? In a typical setup, Luci interface is not reachable from internet and even if the user has opened the firewall, the robot will not see any password-protected content.

This just ensures that it doesn't appear on search engines if you do allow it to be accessible to the internet. I think that's a sensible default to help avoid Google Hacking.

This isn't important.

While this is not a super-high priority, I really do think that this should be added. Nobody can guarantee that LuCI won't be reachable to the outside world, and telling Crawlers to ignore this site is good practice for any sort of control web interface.

authors: hnyman kbabioch ollie27

repo: openwrt/luci


text:
luci-mod-network: Add more comprehensive help text for odhcpd IPv6 parameters, plus introduced RA + NDP options to GUI.

For discussion, refer to forum thread
Also added some RA parameters for increased GUI based configuration flexibility and help-text.
Until now, some of the IPv6 settings are mysterious or cryptic. They are now
clarified, having referred to odhcpd README and source.
The information is accessible to IPv6 beginners.
Signed-off-by: Paul Dee itsascambutmailmeanyway@gmail.com

Core changes in file:
modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js
Hope I got everything right. I think I ran these correctly after edits, according to the instructions:
./build/mkbasepot.sh
./build/i18n-update.pl

Hope I got everything right.

Some of the translation refreshes seem strange.
For example,  thousands of double-// are added for some reason, like here:
- #: modules/luci-mod-system/htdocs/luci-static/resources/view/system/crontab.js:29
+ #: modules/luci-mod-system//htdocs/luci-static/resources/view/system/crontab.js:29

Core changes in file:

Might be better, if

there is one commit about your actual changes, and
you do not do the translations updates at all, if you are only trying to do the automatic refresh/sync without correcting the existing translations that you break.

The PR and commit title is wrong, as you are actually

adding/exposing lots of IPv6 related options to LuCI
changing existing options' explanations

It might be even more clear, if you do two separate commits about those two things.  (and do not touch the translations at all)

Hope I got everything right.

Some of the translation refreshes seem strange.
For example, thousands of double-// are added for some reason, like here:
- #: modules/luci-mod-system/htdocs/luci-static/resources/view/system/crontab.js:29
+ #: modules/luci-mod-system//htdocs/luci-static/resources/view/system/crontab.js:29

I agree, I thought the path thing strange also - I ran the scripts on macOS - and with or without parameters, it adds the double /

Those erroneous strings will be removed in the update.
Better if you leave the translations to .pot and .po  aside.

OK - cleaned it up - but I don't think it is worth it to make separate PRs. Does this look better?

Ah, sorry, commits - I read that as PR 😆 I'll see what I can wrestle out of git....

Please change all
 to
 to make the translation strings XHTML compliant.

Please change all
 to
 to make the translation strings XHTML compliant.
Another remark:
Instead of formatting the text with
 Elements, it might make sense to use actual
 Lists for enumerations of select box choice descriptions.

Good tip.
OK - all clear, I think.

Also split into 2 commits - one adding help-text to present options, one adding new options with help-text.

For the record, and those interested - looks roughly like this:

It is ok to have those new detailed options there, but the page looks somewhat cluttered. The important main options are now scattered among the minor options that the user usually does not need to touch.
It might be better to group the (old) main options to the top, and then place the RA detail options and NDP detail options etc. to the bottom of the page.
Ps. you should also edit the commit titles. Now there is only the "luci-mod-network:" on both commits without any other content except the module name.
Commits might be "luci-mod-network: add new IPv6 options"  and "luci-mod-network: clarify IPv6 option explanations", or something like that.

It is ok to have those new detailed options there, but the page looks somewhat cluttered. The important main options are now scattered among the minor options that the user usually does not need to touch.
It might be better to group the (old) main options to the top, and then place the RA detail options and NDP detail options etc. to the bottom of the page.

I tried it that way - and the 'grouping' disappears. Grouping helps provide strong cohesion and context. Scattering options lower down which appear only when an option higher up is selected makes for confusing options.
The beginner will find this grouping less intimidating, and the advanced IPv6 user will understand what changed.

Ps. you should also edit the commit titles. Now there is only the "luci-mod-network:" on both commits without any other content except the module name.
Commits might be "luci-mod-network: add new IPv6 options" and "luci-mod-network: clarify IPv6 option explanations", or something like that.

Agreed - I'll try and fix those.

Slightly re-ordered. See updated screens above.

Will we merge in time for 21.02 ?

21.02 has been branched off from master already in mid-February...
(it might be backported, but by default, no it is not going to hit 21.02)

I still think that the not-usual RA details are too prominent.
But we can merge this now to master, and tweak it later.

OK!

(it might be backported, but by default, no it is not going to hit 21.02)

I think it'd be helpful for many were it back-ported/picked, and not miss another generation of releases. 😢

I still think that the not-usual RA details are too prominent.
But we can merge this now to master, and tweak it later.

Perhaps for your case - but RA details were added to odhcpd because they were deemed necessary. I guess it's a matter of opinion and necessity for those who need to tweak them, so when they are grouped, they are relevant.
Well, it's been a learning curve 😄

authors: hnyman jow- systemcrash


text:
Luci-proto-ncm: Renamed 'service' to 'mode'

fixes #5877

Good suggestion. Although this would be easier to configure, I do see problems with this. As the only way for modeminfo to know what brand of modem ncm has detected is to query the modem over serial, this would mean the setuppage for modeminfo would become somewhat dependant on a properly functioning and correctly configured tty. Personally, I would advice against making the possibility to configure dependant on a working situation, as in most cases where people start is a non-configured and this non-working setup.
Adding checks to circumvent these restrictions would be possible of course, but are well outside the scope of this PR. You are welcome and encouraged to submit your own PR for more realistic options in the pulldown for the networkmode.

All right then, let's do it that way. When I feel like it, I will restrict the dropdown.
In order for me to merge the pullrequest, you need to add a valid Signed-off-by with correct full name,
Also you have to adjust the commit heading in your commit. Please use the prefix luci-proto-ncm: so we have the heading for this change luci-proto-ncm: rename service to mode as in your pullrequest heading.

Merged via 4d6642b636a9feaa173c568c99f4129c440ed8b8

authors: breenstorm feckert jow-


text:
luci-mod-status: break-word for large commands in processes

[x] This PR is not from my main or master branch :poop:, but a separate branch :white_check_mark:
[x] Each commit has a valid :black_nib: Signed-off-by: <my@email.address> row (via git commit --signoff)
[x] Each commit and PR title has a valid :memo: <package name>: title first line subject for packages
[ ] Incremented :up: any PKG_VERSION in the Makefile
[x] Tested on: (Firefox 1920x1080, Firefox responsive design mode, Chrome on Android) :white_check_mark:
[x] Mention: @systemcrash for feedback
[x] Screenshot or mp4 of changes in #7280
[x] Closes #7280
[x] Description

I just wrapped all process commands in a span and set word-break: break-word as an attribute style for all of them.

I think this looks good. I'll let it hang for a bit to marinate and see what any others might have to say.

Merged. Thanks @Waujito

Thank you!

authors: Waujito systemcrash


text:
Ops unexpectedly supporting boolean types in the ODS

Request description
This ticket will track the following
https://github.com/openxla/stablehlo/pull/250#discussion_r986432897
https://github.com/openxla/stablehlo/pull/240#discussion_r987531422 and
https://github.com/openxla/stablehlo/pull/250#discussion_r986436241
We have the following list of ops for which the  StableHLO semantics  does not support boolean type which seems expected.
However, the StableHLO ODS  and/or  the HLO semantics differs in that respect.

Ops
bool type supported in StableHLO semantics
bool type supported in ODS
bool type supported in HLO Semantics

add
No
Yes
Yes

multiply
No
Yes
Yes

maximum
No
Yes
Yes

minimum
No
Yes
Yes

divide
No
Yes
No

remainder
No
Yes
No

subtract
No
Yes
No

For the first 4 ops, StableHLO spec might support boolean types as well while clarifying the behavior in the spec.

AddOp: For boolean the  behavior is like OrOp
MulOp: For boolean the  behavior is like AndOp
Maximum/Minimum: For boolean the  behavior is true > false

For the others ODS might need to be updated.

Can you also add a row for abs op?

For abs op we have a separate ticket

repo: openxla/stablehlo


text:
[feature request]yurt-hub add impersonate user info for request that does not come from kubelet

What would you like to be added:
if a request through yurt-hub does not come from kubelet, yurt-hub should add impersonate user info in request header before proxying the request. the impersonate header is:
Impersonate-User=system:serviceaccount:{namespace}:{name}

Why is this needed:
we have used node certificate as yurt-hub certificate, the code is here, so the request like list endpoints from other component(eg: kube-proxy) will get 403 response status code for no permission. in order to get correct rights for these requests(does not come from kubelet), we need to  impersonate a particular user in terms of the source of request.
for the user who wants to use impersonate feature:
in order to impersonate a particular component by yurt-hub certificate, user should prepare the impersonate settings(rabc setting) before starting the component.

Before we provide impersonate feature for yurthub, maybe we need to https server feature for yurthub, so pod on edge node can use InClusterConfig to access yurthub.

The feature that pods use InClusterConfig access kube-apiserver through yurthub is released in OpenYurt v0.5.0, so close this issue.

repo: openyurtio/openyurt


text:
about dubbo support?

是不是目前 brave-instrumentation-dubbo-rpc还不支持通过ExtraFieldPropagation传参？

ExtraFieldPropagation is added in the Tracing object, not dubbo directly. So, if you configure it there, dubbo should take it. I think dubbo gets Tracing object from ExtensionFactory or spring.
Please come to gitter for more questions https://gitter.im/openzipkin/zipkin

i was created ExtensionFactory and created spring bean of Tracing.but i get params was null. that's my coding.https://github.com/1991wangliang/sleuth-webmvc-example

repo: openzipkin/brave


text:
pop up UI for span goes out of bound if error message is long

I see a text area with scroll bar should help..

I think this was also noticed by @felixbarny

Right. The overflow should be handled just like in the JSON panel.

This must be fixed in the latest versions after #2224

authors: adriancole felixbarny prbarl zeagord

repo: openzipkin/zipkin


text:
Refactor Timeline component

The codes of Timeline component are dirty.
So I refactored them.

Use BEM notation for CSS
Rename some variables

thanks for the refactoring!

authors: adriancole tacigar


text:
use bigint for ts instead of timestamp in cassandra

ts are microsecond resolution, whereas cassandra timestamps should be millisecond
Fixes #737 thanks to @danchia

the reason I think it is best to merge this is because:

It is is of least surprise, as it matches all other impls
It draws into focus where dates are actually used: dependencies

:+1:

authors: adriancole michaelsembwever


text:
Parallel Route Optimization

Transmit Route messages in parallel.
Modify Route responses to use a new RouteResult (containing the sesson id) instead of a bare Result.
Use a single timeout for route creation for the entire session. Send Unroute messages to all routers on timeout.
Send Unroute messages to routers that respond with RouterResult when the controller is not waiting for a response.

Retry handling needs to (potentially) recompute the circuit (for HA). Refactor network.routeSender to accomodate a single try of a multiple-attempt session establishment.

Identify attempt number in route result messages, otherwise first attempt timeouts in intermediate hops can be satisfied in subsequent attempts, allowing invalid states to exist.

repo: openziti/fabric


text:
Ziti Tunneler shows in start menu

Even when i click 'off' the app (and it disappears) the "MainWindow" shows in the task bar

looking at the code i now see that this is the expected behavior when in 'detached' mode. closing

repo: openziti/ziti-tunnel-win


text:
Broken link in README.md

https://github.com/openziti/ziti#getting-started-with-ziti
The link "up-and-running quickstart guides" doesn't exist (404 error).

Thanks. that doc is quite stale. I'll update that link and read the rest of that page for anything else stale

authors: RodneyRichardson dovholuknf

repo: openziti/ziti


text:
Missing Local Storage Operator

I think that the Local Storage Operator is missing. I am unable to find it on the MarketPlace as per the OKD documentation here: https://docs.okd.io/latest/storage/persistent_storage/persistent-storage-local.html
Thank you so much for your help. :)

This would be awesome. Meanwhile I'm linking this one for people who just want to testdrive it, without using it in production systems: https://github.com/openshift/local-storage-operator/blob/master/docs/deploy-with-olm.md#create-and-subscribe-to-the-local-storage-catalog

This would be awesome. Meanwhile I'm linking this one for people who just want to testdrive it, without using it in production systems: https://github.com/openshift/local-storage-operator/blob/master/docs/deploy-with-olm.md#create-and-subscribe-to-the-local-storage-catalog

authors: Volxz chriskuipers

repo: operator-framework/community-operators


text:
[community] Update submariner-operator description

Signed-off-by: Steve Mattar smattar@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

[x] Does your operator have nested directory structure?
[x] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[x] Are you familiar with our contribution guidelines?
[x] Have you packaged and deployed your Operator for Operator Framework?
[x] Have you tested your Operator with all Custom Resource Definitions?
[x] Have you tested your Operator in all supported installation modes?
[x] 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 ?
[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

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

/test CVP


text:
Flake in operator-developer-e2e: unexpected status conditions for the operator

As of a00a93ffb00c3a9fe894c1974e17400933bffebd I see an uptick in operator-developer-e2e job flakes which look like this:
[FAILED] Timed out after 120.000s.
The function passed to Eventually failed at /home/runner/work/operator-controller/operator-controller/test/operator-framework-e2e/operator_framework_test.go:825 with:
Unexpected error:
    <*errors.errorString | 0xc0004c8af0>:
    Status conditions for the operator plain-operator for the version 0.2.0 is not as expected:Expected status: True, but got: False
    {
        s: "Status conditions for the operator plain-operator for the version 0.2.0 is not as expected:Expected status: True, but got: False",
    }
occurred
In [It] at: /home/runner/work/operator-controller/operator-controller/test/operator-framework-e2e/operator_framework_test.go:826 @ 10/24/23 11:06:46.447

[FAILED] Timed out after 120.000s.
The function passed to Eventually failed at /home/runner/work/operator-controller/operator-controller/test/operator-framework-e2e/operator_framework_test.go:825 with:
Unexpected error:
    <*errors.errorString | 0xc00043bc60>:
    Status conditions for the operator registry-operator for the version 0.1.0 is not as expected:Expected status: True, but got: False
    {
        s: "Status conditions for the operator registry-operator for the version 0.1.0 is not as expected:Expected status: True, but got: False",
    }
occurred
In [It] at: /home/runner/work/operator-controller/operator-controller/test/operator-framework-e2e/operator_framework_test.go:826 @ 10/24/23 11:09:20.027

Example:

https://github.com/operator-framework/operator-controller/actions/runs/6625859094/job/17997641772
Same commit, second attempt is green: https://github.com/operator-framework/operator-controller/actions/runs/6625859094

I suspect it might be related to https://github.com/operator-framework/operator-controller/pull/444 or some other recent changes because I do not see anything similar in job history from two weeks ago.

It would help to have the test failure error include the condition reason and message.

We somehow end up with two Operators which looks like below.
Note that the message is the same almost as if we are writing condition to the wrong operator CR.
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T12:46:29Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1635"
  uid: 21ce5372-90ba-449d-9e6f-01fa540e762d
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T12:46:29Z"
    message: installation has not been attempted as resolution is unsatisfiable
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  - lastTransitionTime: "2023-10-24T12:46:29Z"
    message: 'constraints not satisfiable: installed package registry-operator is
      mandatory; installed package registry-operator requires at least one of registry-operator-catalog-registry-operator-registry-operator.v0.1.0;
      registry-operator package uniqueness permits at most 1 of registry-operator-catalog-registry-operator-registry-operator.v0.2.0,
      registry-operator-catalog-registry-operator-registry-operator.v0.1.0; required
      package registry-operator is mandatory; required package registry-operator requires
      at least one of registry-operator-catalog-registry-operator-registry-operator.v0.2.0'
    observedGeneration: 1
    reason: ResolutionFailed
    status: "False"
    type: Resolved
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T12:44:10Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1270"
  uid: 8f5aab31-18d4-4505-9e2d-f05f4eb0c581
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T12:44:15Z"
    message: 'constraints not satisfiable: installed package registry-operator is
      mandatory; installed package registry-operator requires at least one of registry-operator-catalog-registry-operator-registry-operator.v0.1.0;
      registry-operator package uniqueness permits at most 1 of registry-operator-catalog-registry-operator-registry-operator.v0.2.0,
      registry-operator-catalog-registry-operator-registry-operator.v0.1.0; required
      package registry-operator is mandatory; required package registry-operator requires
      at least one of registry-operator-catalog-registry-operator-registry-operator.v0.2.0'
    observedGeneration: 2
    reason: ResolutionFailed
    status: "False"
    type: Resolved
  - lastTransitionTime: "2023-10-24T12:44:15Z"
    message: installation has not been attempted as resolution is unsatisfiable
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed

same almost as if we are writing condition to the wrong operator CR.

Resolution is global, so unsat resolutions will propogate to all Operator objects if they are reconciled when the global state is unsat.

Resolution is global, so unsat resolutions will propogate to all Operator objects if they are reconciled when the global state is unsat.

Didn't know that, but this makes sense!

I think it is a combination of two things:

False Negatives: the job is green when it must be red
Changes in #444. Most likely related to the zero major version being handled differently in semver. I updated the test data for regular e2e job, but not for operator-developer-e2e.

Here are two green runs. Note that after #444 Operator has unsat errors, but still green.

Before #444 (commit c9d387efad4b121e0a7435e4232e6d1ad0179b45)
# Before #444
# kubectl get operators -o yaml -w

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:29Z"
  generation: 1
  name: registry-operator
  resourceVersion: "1200"
  uid: 27fb53ca-9c3e-42e4-be06-030f072bf1e2
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:29Z"
  generation: 1
  name: registry-operator
  resourceVersion: "1202"
  uid: 27fb53ca-9c3e-42e4-be06-030f072bf1e2
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:29Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:29Z"
    message: bundledeployment status is unknown
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:29Z"
  generation: 1
  name: registry-operator
  resourceVersion: "1270"
  uid: 27fb53ca-9c3e-42e4-be06-030f072bf1e2
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:29Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:34Z"
    message: installed from "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:29Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1281"
  uid: 27fb53ca-9c3e-42e4-be06-030f072bf1e2
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:29Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:34Z"
    message: installed from "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:29Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1283"
  uid: 27fb53ca-9c3e-42e4-be06-030f072bf1e2
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:29Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:34Z"
    message: installed from "localhost:5001/registry-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/registry-operator-bundle:v0.2.0
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.2.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:29Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1284"
  uid: 27fb53ca-9c3e-42e4-be06-030f072bf1e2
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:29Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:34Z"
    message: installed from "localhost:5001/registry-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/registry-operator-bundle:v0.2.0
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.2.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:48Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1377"
  uid: ecd7cfaa-c693-4bf7-894a-3957526a657b
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:48Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1379"
  uid: ecd7cfaa-c693-4bf7-894a-3957526a657b
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:48Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:48Z"
    message: bundledeployment status is unknown
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:48Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1445"
  uid: ecd7cfaa-c693-4bf7-894a-3957526a657b
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:48Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:52Z"
    message: installed from "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:48Z"
  generation: 2
  name: plain-operator
  resourceVersion: "1466"
  uid: ecd7cfaa-c693-4bf7-894a-3957526a657b
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:48Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:52Z"
    message: installed from "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:48Z"
  generation: 2
  name: plain-operator
  resourceVersion: "1468"
  uid: ecd7cfaa-c693-4bf7-894a-3957526a657b
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:48Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:52Z"
    message: installed from "localhost:5001/plain-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/plain-operator-bundle:v0.2.0
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.2.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:22:48Z"
  generation: 2
  name: plain-operator
  resourceVersion: "1469"
  uid: ecd7cfaa-c693-4bf7-894a-3957526a657b
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:22:48Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:22:52Z"
    message: installed from "localhost:5001/plain-operator-bundle:v0.2.0"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/plain-operator-bundle:v0.2.0
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.2.0

After #444 (commit a00a93ffb00c3a9fe894c1974e17400933bffebd)
# After #444
# kubectl get operators -o yaml -w

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:14:34Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1161"
  uid: bb10ccfc-3bbd-4f35-9c2d-1ec3581120d4
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:14:34Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1163"
  uid: bb10ccfc-3bbd-4f35-9c2d-1ec3581120d4
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:14:34Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:14:34Z"
    message: bundledeployment status is unknown
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:14:34Z"
  generation: 1
  name: plain-operator
  resourceVersion: "1232"
  uid: bb10ccfc-3bbd-4f35-9c2d-1ec3581120d4
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:14:34Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:14:39Z"
    message: installed from "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:14:34Z"
  generation: 2
  name: plain-operator
  resourceVersion: "1251"
  uid: bb10ccfc-3bbd-4f35-9c2d-1ec3581120d4
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:14:34Z"
    message: resolved to "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:14:39Z"
    message: installed from "localhost:5001/plain-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/plain-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:14:34Z"
  generation: 2
  name: plain-operator
  resourceVersion: "1252"
  uid: bb10ccfc-3bbd-4f35-9c2d-1ec3581120d4
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:14:40Z"
    message: 'constraints not satisfiable: installed package plain-operator is mandatory;
      installed package plain-operator requires at least one of plain-operator-catalog-plain-operator-plain-operator.v0.1.0;
      plain-operator package uniqueness permits at most 1 of plain-operator-catalog-plain-operator-plain-operator.v0.2.0,
      plain-operator-catalog-plain-operator-plain-operator.v0.1.0; required package
      plain-operator is mandatory; required package plain-operator requires at least
      one of plain-operator-catalog-plain-operator-plain-operator.v0.2.0'
    observedGeneration: 2
    reason: ResolutionFailed
    status: "False"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:14:40Z"
    message: installation has not been attempted as resolution is unsatisfiable
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:14:34Z"
  generation: 2
  name: plain-operator
  resourceVersion: "1253"
  uid: bb10ccfc-3bbd-4f35-9c2d-1ec3581120d4
spec:
  packageName: plain-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:14:40Z"
    message: 'constraints not satisfiable: installed package plain-operator is mandatory;
      installed package plain-operator requires at least one of plain-operator-catalog-plain-operator-plain-operator.v0.1.0;
      plain-operator package uniqueness permits at most 1 of plain-operator-catalog-plain-operator-plain-operator.v0.2.0,
      plain-operator-catalog-plain-operator-plain-operator.v0.1.0; required package
      plain-operator is mandatory; required package plain-operator requires at least
      one of plain-operator-catalog-plain-operator-plain-operator.v0.2.0'
    observedGeneration: 2
    reason: ResolutionFailed
    status: "False"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:14:40Z"
    message: installation has not been attempted as resolution is unsatisfiable
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:15:05Z"
  generation: 1
  name: registry-operator
  resourceVersion: "1378"
  uid: 181493f6-d102-4f1b-8e63-03775d595278
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:15:05Z"
  generation: 1
  name: registry-operator
  resourceVersion: "1380"
  uid: 181493f6-d102-4f1b-8e63-03775d595278
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:15:05Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:15:05Z"
    message: bundledeployment status is unknown
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:15:05Z"
  generation: 1
  name: registry-operator
  resourceVersion: "1445"
  uid: 181493f6-d102-4f1b-8e63-03775d595278
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.1.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:15:05Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:15:10Z"
    message: installed from "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:15:05Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1456"
  uid: 181493f6-d102-4f1b-8e63-03775d595278
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:15:05Z"
    message: resolved to "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:15:10Z"
    message: installed from "localhost:5001/registry-operator-bundle:v0.1.0"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
  resolvedBundleResource: localhost:5001/registry-operator-bundle:v0.1.0
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:15:05Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1457"
  uid: 181493f6-d102-4f1b-8e63-03775d595278
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:15:10Z"
    message: 'constraints not satisfiable: installed package registry-operator is
      mandatory; installed package registry-operator requires at least one of registry-operator-catalog-registry-operator-registry-operator.v0.1.0;
      registry-operator package uniqueness permits at most 1 of registry-operator-catalog-registry-operator-registry-operator.v0.2.0,
      registry-operator-catalog-registry-operator-registry-operator.v0.1.0; required
      package registry-operator is mandatory; required package registry-operator requires
      at least one of registry-operator-catalog-registry-operator-registry-operator.v0.2.0'
    observedGeneration: 2
    reason: ResolutionFailed
    status: "False"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:15:10Z"
    message: installation has not been attempted as resolution is unsatisfiable
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
---
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  creationTimestamp: "2023-10-24T13:15:05Z"
  generation: 2
  name: registry-operator
  resourceVersion: "1459"
  uid: 181493f6-d102-4f1b-8e63-03775d595278
spec:
  packageName: registry-operator
  upgradeConstraintPolicy: Enforce
  version: 0.2.0
status:
  conditions:
  - lastTransitionTime: "2023-10-24T13:15:10Z"
    message: 'constraints not satisfiable: installed package registry-operator is
      mandatory; installed package registry-operator requires at least one of registry-operator-catalog-registry-operator-registry-operator.v0.1.0;
      registry-operator package uniqueness permits at most 1 of registry-operator-catalog-registry-operator-registry-operator.v0.2.0,
      registry-operator-catalog-registry-operator-registry-operator.v0.1.0; required
      package registry-operator is mandatory; required package registry-operator requires
      at least one of registry-operator-catalog-registry-operator-registry-operator.v0.2.0'
    observedGeneration: 2
    reason: ResolutionFailed
    status: "False"
    type: Resolved
  - lastTransitionTime: "2023-10-24T13:15:10Z"
    message: installation has not been attempted as resolution is unsatisfiable
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed

I created #485 for false negatives. Will submit the PR which updates test data shortly.

#488 should address this issue

repo: operator-framework/operator-controller


text:
Dependency issues when creating new project

Bug Report
What did you do?
Follow the instructions to create a new operator
Error occurs during  operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=AppService
What did you expect to see?
No error
What did you see instead? Under which circumstances?
operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=AppService
INFO[0000] Generating api version app.example.com/v1alpha1 for kind AppService.
INFO[0003] Created pkg/apis/app/v1alpha1/appservice_types.go
INFO[0003] Created pkg/apis/addtoscheme_app_v1alpha1.go
INFO[0003] Created pkg/apis/app/v1alpha1/register.go
INFO[0003] Created pkg/apis/app/v1alpha1/doc.go
INFO[0003] Created deploy/crds/app_v1alpha1_appservice_cr.yaml
W0516 11:08:17.804372   88468 parse.go:239] Ignoring child directory talon-one/app-operator/pkg/apis/app: unable to import "talon-one/app-operator/pkg/apis/app": go/build: importGo talon-one/app-operator/pkg/apis/app: exit status 1
go: github.com/peterbourgon/diskv@v0.0.0-20190425080511-0be1b92a6df0: go.mod has post-v0 module path "github.com/peterbourgon/diskv/v3" at revision 0be1b92a6df0
go: error loading module requirements

W0516 11:08:17.842713   88468 parse.go:239] Ignoring child directory talon-one/app-operator/pkg/apis/app/v1alpha1: unable to import "talon-one/app-operator/pkg/apis/app/v1alpha1": go/build: importGo talon-one/app-operator/pkg/apis/app/v1alpha1: exit status 1
go: github.com/peterbourgon/diskv@v0.0.0-20190425080511-0be1b92a6df0: go.mod has post-v0 module path "github.com/peterbourgon/diskv/v3" at revision 0be1b92a6df0
go: error loading module requirements

INFO[0003] Created deploy/crds/app_v1alpha1_appservice_crd.yaml
Error: exit status 1

Environment

operator-sdk version:

operator-sdk version: v0.7.0

go version:

go version go1.12.5 darwin/amd64

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-19T22:12:47Z", GoVersion:"go1.12.4", Compiler:"gc", Platform:"darwin/amd64"}

Are you writing your operator in ansible, helm, or go?
Go

Possible Solution
Edit Go.mod file and replace the existing entry for github.com/peterbourgon/diskv with

github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
github.com/peterbourgon/diskv/v3 v3.0.0 // indirect

I ran into the same issue, just got a slightly different output:
INFO[0000] Generating api version app.example.com/v1alpha1 for kind AppService.
INFO[0000] Created pkg/apis/app/v1alpha1/appservice_types.go
INFO[0000] Created pkg/apis/addtoscheme_app_v1alpha1.go
INFO[0000] Created pkg/apis/app/v1alpha1/register.go
INFO[0000] Created pkg/apis/app/v1alpha1/doc.go
INFO[0000] Created deploy/crds/app_v1alpha1_appservice_cr.yaml
W0516 13:47:33.589763   28494 parse.go:239] Ignoring child directory github.com/example-inc/app-operator/pkg/apis/app: No files for pkg "github.com/example-inc/app-operator/pkg/apis/app"
INFO[0000] Created deploy/crds/app_v1alpha1_appservice_crd.yaml
INFO[0009] Running deepcopy code-generation for Custom Resource group versions: [app:[v1alpha1], ]
INFO[0010] Code-generation complete.
Error: exit status 1
Usage:
  operator-sdk add api [flags]

Flags:
      --api-version string   Kubernetes APIVersion that has a format of $GROUP_NAME/$VERSION (e.g app.example.com/v1alpha1)
      --header-file string   Path to file containing headers for generated files.
  -h, --help                 help for api
      --kind string          Kubernetes resource Kind name. (e.g AppService)

@rafaelvanoni I think yours is just a warning. There is nothing to be compiled in that package and therefor it's ignored. I think this is fine

@soupdiver operator-sdk version: v0.7.0 as that version did not include go mod support yet. If you want go mod support you need to install operator-sdk from the master version, it should be in the next release if you want to wait for that.

@LiliC ahhhhh that actually makes sense. I was looking at the Readme for master but was using release 0.7.0.
Thanks for revealing that 👍

@soupdiver no problem, if you run into any issues with anything feel free to open a new issue.

authors: LiliC rafaelvanoni soupdiver

repo: operator-framework/operator-sdk


text:
fix fragment file name

Description of the change:
rename the fragment file, I had a type-o in the suffix.
Motivation for the change:
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

Looks like sanity test is failing because of a YAML parse error. These lines need to be on one line or indented with the yaml > operator.
description: Updated the Makefile to build multiarch versions of the scorecard-test-kuttl and custom-scorecard-tests images to match the scorecard-test image

Or
description: >
  Updated the Makefile to build multiarch versions of the scorecard-test-kuttl
  and custom-scorecard-tests images to match the scorecard-test image


text:
OCPBUGS-11569: Update ubi to ubi-micro:8.7

Bump to ubi-micro:8.7

/rerun-all

closing and reopening to try and pick up CI fixes


text:
Python3 compatibility and Travis housekeeping

This merge cleans up the travis build matrix to use the proper builtin Python images and test Python 3.3, as well 2.7. It also fixes the various compatibility issues with Python3.

I think this can just go in

repo: opesci/devito


text:
Profile class now profiles OI and GFLOPS

Updated profile class to calculate OI and GFLOPS directly from the C code
Removed old methods to calculate OI from Propagator

Closed since superseded by #93


text:
Create a kind of modal "Loading page ... please wait ..." ?

@fichtner
I was just wondering if it would make sense for all sides to create a kind of "Loading page ... please wait ..." modal window when a new page is loaded or a page is saved. That would be very helpful, because sometimes you unintentionally clicks too early somewhere or it is not always clearly recognizable. Sometimes there are buttons that indicate it by a spinnig icon, but generally I would consider it useful to inform the user about it. This is just an idea and for me now counts the completion of the last sidebar problem. But I thought I could work on something like this when I finished the sidebar. Do you think the idea useful or meaningless?
if you do not like this idea just delete this!
best regards rené

It would make sense when we would have a single page application (backbone, vue or angular) where you would have the start and the end event but in our case it is quite hard because this is not the case.
If you switch, you can show the spinner theoretically two times:

button / link clicked until the page is replaced
the new page is being loaded until the JS gives a notification (everything is ready)

Inbetween you have some undefined behaviour.

quite some pages already show spinners in the action buttons, I don't think there's a need for much more then that.

@opnsenseuser Adding missing spinners if there's a lack of user response is certainly a good idea.

@AdSchellevis what would be the easiest way to provide all save buttons with a spinning wheel?

@fichtner What do you think about? spinning wheel for all Save Buttons or modal window? imagine the modal window via unload page with javascript.
best regards

@opnsenseuser you can't do all at once, it's depending on the page (only applicable for mvc pages by the way).
Usually they do something like:
https://github.com/opnsense/core/blob/7835b70c6bedad6e2851670637008f2ea86f10a6/src/opnsense/mvc/app/views/OPNsense/Proxy/index.volt#L274-L302
Where the action (if it consumes some time) triggers the addClass and removes the class using removeClass when finished.
Personally I haven't found obvious places with missing feedback, but if there are, we could consider adding them like above.
Add spinners to modal dialogs doesn't really bring anything, they close after save...

modals are nice if you want to convey information for confirmation or why a system is doing something while you wait. for save and apply  buttons it's probably better to use spinners.
The nice thing about the static pages is you just have to start the spinner on click and the page reload will take care of the reset. The bad thing about static pages is that every button needs to be patched, at least with a class to inject the click handler selectively.

timeout

authors: AdSchellevis fabianfrz fichtner opnsenseuser

repo: opnsense/core


text:
IPSec connection possible with no rules for allowing ESP, UDP/500 and UDP/4500

My question on the forums did get no attention. So I ask it here as a question because first, I don't know wether it's a bug, or not. And second, I consider it being very important.
I'm using 2 OPNsense instances. One on a VPS hosting provider and one at home. The instance on the hosting provider has a static IP, the home box has a dynamic IP with dynamic DNS in place.
All IPSec settings are correct since the tunnels are actually working. But I can't understand WHY they are working in the way that my instances are configured:
I have no firewall rules on the WAN interfaces which allow ESP, ISAKMP and NAT-T to pass, on neither instance. Both instances have their packet filtering enabled and my tests included resetting the states.
However, when I start the IPSec Connection, it is going to be established normally and working.
According to the official OPNsense documentation, I would have to add Allow rules to the outer tunnel endpoint interfaces, as with every other firewall.
Thus, I'm now concerned about the firewall not working correctly. Or are there any automatic firewall rules created, when IPSec on OPNsense is activated?
Both instances are on version 19.1.10.

the rules are automatic, the upcoming 19.7 version will show these as well in the overview:

and can point to the option which controls the rule

Thank you, that clarifies it.