text:
Removed custom patch since the upstream pr has been merged

The mentioned upstream PR https://github.com/openshift-metal3/dev-scripts/pull/1607 has been merged, so this patch shouldn't be needed anymore.
Thx to @rabi for reporting it.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running

Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/2133

/hold needs testing downstream

recheck

/unhold
ds test are fine

recheck

recheck
Added Depends-On

authors: raukadah rebtoor


text:
Add new target for checking modified zuul files

Add new target for checking modified zuul files (Moved from https://github.com/openshift/release/pull/42730). It will re-generate the zuul.d/molecule.yaml and zuul.d/projects.yaml files, if they're not in commit phase or if they have been modified manually then the target will fail.
Add check_zuul_files target in pre-comit-config file

If it's passing:
[2023-08-29 16:16:04] {afuscoar@afuscoar} (~/.Redhat/Projects/github/ci-framework) (feature/target-zuul-jobs-check)$ -> pre-commit run --all-files;
make-check-zuul-files....................................................Passed
...

If it's not:
[2023-08-29 16:25:51] {afuscoar@afuscoar} (~/.Redhat/Projects/github/ci-framework) (feature/target-zuul-jobs-check)$ -> pre-commit run --all-files;
make-check-zuul-files....................................................Failed
- hook id: make-check-zuul-files
- files were modified by this hook
...

[x] Added description in new target

/lgtm

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
devsetup - Standalone ironic - Clean "metadata"

Set IronicCleaningDiskErase to "metadata" in the Standalone deployment. The default "erase" takes a lot longer, and there is no need to use full erase in an adoption test env.

recheck
Due to a CI Blocker

/test install-yamls-deploy

authors: hjensas lewisdenny


text:
Add validation to bins downloaded in root image

This patch adds a validation on binaries that are download during root image build.

/lgtm
Recently, we hit an issue where instead of binary the content of  /usr/local/bin/operator-sdk was a http error and not the binary.
cat /usr/local/bin/operator-sdk
<?xml version="1.0" encoding="utf-8"?><Error>ServerBusy<Message>Egress is over the account limit.

This patch adds the validation that takes care of that.


text:
Street level imagery: Limit maximum viewer size

URL
No response
How to reproduce the issue?
Limit the maximum viewer size to stay inside the interactable frame, at least in height.
While the resize button can still -barely- be interacted with at this size, the viewer itself gets cut off vertically.
Alternatively, the viewer could be visible through the top toolbar UI (as it is already transparent), but this is likely not desirable.
Chrome 131.0.6778.86 on Windows 10
Screenshot(s) or anything else?

Which deployed environments do you see the issue in?
Released version at openstreetmap.org/edit, Development version at ideditor.netlify.app
What version numbers does this issue effect?
2.30.4, 2.31.0-dev
Which browsers are you seeing this problem on?
Chrome

@danieldegroot2 i will do this issue

@danieldegroot2 i have make PR of this issue as https://github.com/openstreetmap/iD/pull/10563

source: gharchive/issue

repo: openstreetmap/iD

license: ISC


text:
Allow cancelling of changeset uploading

Today I made the mistake to upload a changeset with bad internet connection. In the middle of the uploading progress, the connection collapsed and the uploading progress spinner kept spinning for quite a while. I realised what had happened, but of course there was no way to cancel uploading. So I was forced to close the tab and when I reopened it with better connection all mapping was lost. iD couldn't restore my changes, because another tab with changes was open in the background.
Maybe we could implement a way to cancel changeset uploading. JOSM also has such a feature. Would it be possible to add something like this to iD as well?

The changeset upload redesign I mentioned in January is now available for testing, see my blog post for details: https://www.openstreetmap.org/user/mmd/diary/44318

authors: hikemaniac mmd-osm


text:
Read photo id from query string for street-level imagery

Example:
https://www.openstreetmap.org/edit?editor=id#map=18/39.93450741752976/-105.0910279993947?photo_overlay=mapillary&photo=o6y6pgnHjz7vdEbjY7YCtg
This link, for example, would make sure the Mapillary photo overlay is turned on, and then initiate the MapillaryJS viewer and execute moveToKey('o6y6pgnHjz7vdEbjY7YCtg') which would open that specific image, so a user can start editing right away.

This is a great suggestion. I find the Mapillary explorer pretty powerful to navigate through various imagery/filters and would love to jump to iD from a specific Mapillary image and retain context of what i wanted to edit.

Yes if we can get this working then we'll link directly from Mapillary's website to open the same current photo in iD, ready to edit :)

This would be  very helpful... has any progress been made on this ?

has any progress been made on this ?

@EuropeanWaterProject Not yet…

@nickplesha implemented this for Mapillary photos in #7885!
I'm going to work on achieving parity for OpenStreetCam and Bing Streetside. As part of supporting multiple services, I prefixed the format like photo=mapillary-eZxLgJ9sHstg0ySKE3plLw. We can't rely on photo_overlay=mapillary since that key supports multiple layers, e.g. photo_overlay=streetside;mapillary;openstreetcam. Plus this lets iD open the correct layer automatically if photo_overlay is left off.

@quincylvania I know I am late to the party, just a quick though: Reading photo=mapillary-eZxLgJ9sHstg0ySKE3plLw makes me think of an ID that is actually mapillary-eZxLgJ9sHstg0ySKE3plLw. But reading your comment, its more of a identifier/category+ID which IMO could be shown a bit better by something like photo=mapillary/eZxLgJ9sHstg0ySKE3plLw or photo=mapillary;eZxLgJ9sHstg0ySKE3plLw or photo=mapillary+eZxLgJ9sHstg0ySKE3plLw.

@tordans Hmm, that's a good point. The slash might work better. We can easily change this since we haven't released it yet.

authors: EuropeanWaterProject cbeddow planemad quincylvania tordans


text:
Could you add new presets disused:craft and disused:highway ?

OSM Tag(s)
disused:craft, disused:highway
How would you like this tag to see supported?
As a Preset
Label
disused craft, disused road
Aliases
No response
Terms
No response
Link to OSM Wiki page
https://wiki.openstreetmap.org/wiki/Key:disused:craft, https://wiki.openstreetmap.org/wiki/Key%3Adisused%3Ahighway
Status of the Tag
In Use
Usage of the tag
787, 35 879
Replaces other Tag?
no
Regional Tag?
no
Further Information
Currently there are disused:shop (78 159 usages), disused:amenity (72 111 usages) and disused:railway (90 449 usages) presets.
A craft is like a shop except that people create the items inside the "shop". Even though it is not used as much as disused:shop, disused:craft is still relevant.
With 35 879 usages, disused:highway seems missing.

@Mahabarata It is much better to create separate issues for separate raised issues

I think we should think about those presets as unsearchable. The goal should be to make data visible once clicked so users understand it better in the editor. — I would not make those presets searchable because they will be very hard to understand and clutter the results. The Usecase is more "I have a shop… and want to mark them disused". There are issues in the iD Repo on this topic. Quincy started working on it a while back but this work was not finished AFAIR.
I think a good next step would be to create separate PRs for the presets and plan fields, description and such on those. Please use the tips in https://github.com/openstreetmap/id-tagging-schema/pull/1239/files to create good PR.

authors: Mahabarata matkoniecz tordans

repo: openstreetmap/id-tagging-schema


text:
place=square vs highway=pedestrian + area=yes is confusing

Maybe using place=locality icon would make more clear its distinction from pedestrian area? Technically, #41 would be still the same - but would make the important distinction more clear
here confusion is likely and any help would be nice:

I used the generic maker icon (for place=*) for now.

authors: matkoniecz tyrasd


text:
Add parking:orientation key and field

I would like to request to add the key parking:orientation=* key with its corresponding field in the parking preset.
https://wiki.openstreetmap.org/wiki/Key:parking:orientation

#73 had already added this field to the "street side parking" preset, which is where the parking:orientation is used most often.
According to the osm wiki page, the tag could also be used with parking=lane (albeit to a limited extent, since mostly only the value parallel would be applicable). But iD doesn't have a special preset for parking lanes, and I guess that's not particularly a bad thing, since that tag competes with mapping lane-parking as an attribute of roads, which is also not yet supported by iD.

authors: AntMadeira tyrasd


text:
文件系统点击新建的 + 号能否中途弹出弹窗，进行配置再去新建

业务场景需要配置一些资源后再创建文件，请问现有的文件系统是否支持上述所说的场景

@andy00614 文件树场景下的新建文件不具备该定制能力，建议通过自定义命令的方式往文件树上注册响应的菜单命令，代码位置在：file-tree-contribution.ts#L1101
如这里可以插件一个新的 NEW_FILE_WITH_DIALOG 类似的命令，同时实现上可以基于自己实现的逻辑结合 FileService 能力去创建文件，文件树将会自动响应外部的文件变化
尝试一下，该问题暂时先关闭了

repo: opensumi/core

license: MIT


text:
A couple of output fixes for sous build and sous deploy

sous build now reports the output of docker build (and docker push) on a
Linewise basis.
sous deploy emits a couple of lines to explain the ~20 second delay.

Codecov Report

Merging #329 into master will decrease coverage by -0.03%.
The diff coverage is 65%.

@@            Coverage Diff             @@
##           master     #329      +/-   ##
==========================================
- Coverage   60.69%   60.67%   -0.03%
==========================================
  Files         161      161
  Lines        8640     8650      +10
==========================================
+ Hits         5244     5248       +4
- Misses       2964     2970       +6
  Partials      432      432

Impacted Files
Coverage Δ

cli/sous_deploy.go
54.16% <ø> (-2.36%)
:x:

cli/sous_update.go
82.97% <ø> (ø)
:white_check_mark:

util/shell/sh.go
77.77% <100%> (+0.63%)
:white_check_mark:

graph/graph.go
87.94% <100%> (+0.08%)
:white_check_mark:

ext/docker/dockerfile_buildpack.go
32.55% <100%> (+3.28%)
:white_check_mark:

util/shell/command.go
71.79% <37.5%> (-1.89%)
:x:

lib/auto_resolver.go
88.05% <ø> (-1.5%)
:x:

Continue to review full report at Codecov.

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

authors: codecov-io nyarly

repo: opentable/sous

license: mit

license_source: bigquery


text:
No option to add custom logo next to open targets genetics title

I need to add an organization logo to the left from the open targets genetics titles everywhere in the application. The logo's height has to be adjusted with respect to the title font size.

Closing as PRs were discussed and closed. Please raise if there is something I'm missing.

repo: opentargets/issues


text:
feat: include normalised label labelN into the matches dataframe so…

… it can be used for further analyses
Closes https://github.com/opentargets/platform/issues/1741

Solves https://github.com/opentargets/platform/issues/1741

repo: opentargets/platform-etl-literature


text:
Validator should exit with non-zero status on errors

Currently, the JSON validator only exits with a non-zero exit code in case of invalid arguments or an internal exception. If it finds errors in the JSON, but otherwise completes, then it exits with a zero exit code. This makes it hard to integrate into a wider pipeline.
It should be changed to return exit code 2 if it completes, but JSON that does not match the schema has been detected.

Version 0.4.0 has been released to PyPI which fixes this issue.

repo: opentargets/platform


text:
Bug when visualizing targets associated to a disease for the first time

Problem description
I have installed Open Targets and when I select a disease for the first time, I see a page with no information regarding its associated targets:

If I look at the console, I see a failing request to api/v3/platform/public/association/filter which responds with this message: "Too many requests. Please look at the "X-Usage-Limit-Wait" header for the time to wait for an other call."
If I refresh the page then it renders correctly.
Information about the installation
Docker setup with 3 containers:

container for Elasticsearch, with an image based on Elasticsearch 5.6.13 but with the X-Pack plugin uninstalled.
container for the open targets api, using the following image: quay.io/opentargets/rest_api:18.12.0
container for the open targets app, using the following image: quay.io/opentargets/webapp:v3.10

Hi Oleguer,
I just had a chat about this with @mkarmona. There had been some code updates in regards to the X-Usage-Limit-Wait and the version you're using is probably prior to this.
We suggest you try running the latest 18.12 version, which is 18.12.6.
Do let us know how it goes.
Kind regards,
Luca

Hi Luca,
I have tested the version 18.12.6 and it does not seem to have the bug anymore.
Thanks for the quick reply and the help. I will close this issue.
Regards,
Oleguer

authors: LucaFumis oplantalech


text:
Should we have an allowlist for kases?

Allowlists protect against malicious files -- someone could edit the KAO in the manifest to point to a malicious kas url. The sdk would pass an access token to that url that could possibly be used maliciously to decrypt tdfs.
Allowlists require the client/pep to know and provide all possible kases on initialization -- With key splits this can get tedious as there could be many kases and possibly kases that are unknown/hidden to the user.

Moving risk discussion to Jira: https://virtru.atlassian.net/browse/VULN-35

authors: elizabethhealy jentfoo

repo: opentdf/client-web


text:
The setup script failed

I used the latest code, but the script always failed and show the following log:
...
Connection 'BorderRouter-AP' (9e68a65d-ba48-437b-9630-90d75916baba) successfully added.
...
Connection 'BorderRouter-Eth' (e20bda30-0d90-442d-abaf-70eb6d4b4316) successfully added.
Error: Timeout 90 sec expired.

Hi, could you please give more details on the environment? For example, the hardware platform, the OS and so on?

Hi, bukepo
I used the Raspi 3B and Raspbian Stretch Lite, version: 2017-09-07
I've run script "./script/bootstrap" from "borderrouter" directory, it worked fine. But it always failed when I run script "./script/setup" and show the above timeout error.
I found there was something wrong after "create_eth_connection" in the script "./script/_network_manager":
network_manager_install()
{...
create_eth_connection
    sudo systemctl daemon-reload
    sudo systemctl restart NetworkManager
    sleep 15
    if [ $PLATFORM = raspbian ]; then
        sudo nmcli c up ${AP_CONN}
    fi
    sudo nmcli c up ${ETH_CONN}
}

Did I miss something?

Hi, bukepo
I've sloved this problem just now. Thanks for your reply!
I found the network-manager will setup a wifi AP named "BorderRouter-AP" and I can access the web UI. Well, what should I do next? Do I still need to configure the Pi step by step following the official document: Wi-Fi Access Point Setup for OpenThread Border Router
In addition, I found the Border Router with NCP(Nordic nRF52840) is not able to talk with my Thread Nodes(Synopsys EMSK, Nordic nRF52840 and my custom board). No matter who create a Thread Network, the NCP or the Thread Nodes, there is nothing after I executing the command "scan". But it works fine between the Thread Nodes.
What's more, I've tried that only install wpantund on the Pi, and everything is OK using the wpanctl, such as "scan", "join" and so on. But I use the wpantund(Tags: full/latest-release Version: 0.07.01 (0.07.01-2-g6993264; Dec 11 2017 14:03:19)) at that time. Does the different version of wpantund make difference?

pi@raspberrypi:~ $ sudo wpanctl status
wpan0 => [
"NCP:State" => "offline"
"Daemon:Enabled" => true
"NCP:Version" => "OPENTHREAD/0.01.00; ARM Mbed; Dec 18 2017 18:55:32"
"Daemon:Version" => "0.08.00d (/120ef3e; Dec 18 2017 10:17:31)"
"Config:NCP:DriverName" => "spinel"
"NCP:HardwareAddress" => [0050C2FFFE1D3000]
]

pi@raspberrypi:~ $ sudo wpanctl -I wpan0 scan
| Joinable | NetworkName        | PAN ID | Ch | XPanID           | HWAddr           | RSSI
---+----------+--------------------+--------+----+------------------+------------------+------

pi@raspberrypi:~ $ ifconfig
nat64: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
inet 192.168.255.1  netmask 255.255.255.255  destination 192.168.255.1
inet6 fdaa:bb:1::1  prefixlen 128  scopeid 0x0
inet6 fe80::25b2:fb31:9d61:8a1b  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4  bytes 304 (304.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.42.0.1  netmask 255.255.255.0  broadcast 10.42.0.255
inet6 fe80::ba27:ebff:fea2:7b3  prefixlen 64  scopeid 0x20
ether b8:27:eb:a2:07:b3  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 31  bytes 5354 (5.2 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4  bytes 384 (384.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Could you please write the steps to reproduce this issue? And please also attach the syslog of your respberry pi.
I’m wondering if the NCP is working normally.

I'm experiencing same problem as OP. I've followed the instruction:
https://openthread.io/guides/border_router/raspberry_pi_3b
I'm using RPI3 and running Raspbian Stretch Lite OS image. Any fix for this?

@HendraWijaya, are you still having issues with this?
I just tested and the scripts seem to work for me.
Hardware version:
$ cat /proc/cpuinfo
...
Revision        : a22082

Linux is Raspbian Stretch Lite 2018-03-13.
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

@jwhui I tried again and it works now. I connect the pi through eth. It didn't work before because I connected through wlan.

@XiangcaiHuang
Hi!
I am also facing same Timeout error issue. Can you please mention how you resolved it.

@tarunsmalviya
Hi, I'm sorry for the late reply. Have you solved the problem?
I was just trying to run the script at different times of the day, then it finally work. So it maybe the reason for the network connection but I'm not sure.

authors: HendraWijaya XiangcaiHuang bukepo jwhui tarunsmalviya

repo: openthread/borderrouter


text:
otbr-agent crash during/right-after "NetDataPublshr: DNS/SRP service (state:Adding)"

Describe the bug The otbr-agent crash with SIGSEV right-after "NetDataPublshr: DNS/SRP service (state:Adding)" gets printed. I can't reproduce constantly but another hint I found is that only happens after the "Slaac---------: Adding address" & when NetDataPublshr finds "preferred:1" (It does not happen with preferred:0).
12-13 10:35:00.602  5248  5248 I otbr-agent: [I] Settings------: Read SlaacIidSecretKey
12-13 10:35:00.602  5248  5248 I otbr-agent: [I] Slaac---------: Adding address fde0:3d41:cdd5:1:5baf:941f:6bb1:9e71
12-13 10:35:00.602  5248  5248 I otbr-agent: [I] Platform------: [netif] Sent request#4 to add fde0:3d41:cdd5:1:5baf:941f:6bb1:9e71/64
12-13 10:35:00.603  5248  5248 I otbr-agent: [I] BorderRouter--: Start evaluating routing policy, scheduled in 3227 milliseconds
12-13 10:35:00.603  5248  5248 I otbr-agent: [I] NetDataPublshr: DNS/SRP service (state:Adding) in netdata - total:1, preferred:1, desired:2

FULL LOGS here:
16.02.22.22_G2A1EF052126043J_logcat.txt
I am still investigating. I will update this ticket when I find new information.

@AlanLCollins , thanks for reporting this issue.
Can you indicate the git commit you are using? We've recently fixed some bugs related to format strings when logging. One example:

https://github.com/openthread/openthread/pull/8338

@jwhui
I got good initial results. Our QA team is running stress & longevity tests to confirm the crashes are gone. I will keep you posted on the results. Thanks !

@jwhui I got good initial results. Our QA team is running stress & longevity tests to confirm the crashes are gone. I will keep you posted on the results. Thanks !

Great, thanks for the update!

authors: AlanLCollins jwhui

repo: openthread/openthread


text:
[cli] return error from 'Process{Cmd}()' methods, adding 'OT_ERROR_PENDING'

This commit changes the CLI Process{Cmd}() handler methods to return
an otError (instead of outputting the result). This helps harmonize
the Process{Cmd}() handlers in different CLI modules. It also
enables the result of CLI command to be outputted from ProcessLine()
after the command is looked up in the table and the corresponding
Process{Cmd}() handler is invoked.
This commit also adds a new error code OT_ERROR_PENDING. This
special error code indicates the success or error status of an
operation is not yet known and is pending. This is then used by some
of the CLI Process{Cmd}() methods which perform an async operation,
e.g., ProcessDiscover() returns OT_ERROR_PENDING if the discover
scan starts successfully, and later the final result is outputted from
scan callback. The OutputResult(aError) method is changed to output
nothing if the error is OT_ERROR_PENDING.

Beyond the scope of this PR, I think this PR actually bring us one step closer to implement synchronized commands.
By synchronized commands, I mean OT CLI only execute one outstanding command at any time, and no subsequent command will be executed before the previous command output result (i.e. Done or Error ...).
I think this is helpful for programs to interact with OT CLI and parse command outputs. Currently, when multiple async commands are running, it's impossible to tell which Done / Error ... is of which command.
There should be two ways to achieve this:

Block other commands if there is an async command pending. This is now easier to implement base on this PR.
All commands should output Done / Error ... immediately and other async events (e.g. ping result, scan result) is emitted asynchronously, but they are not seen as part of the command output.

Approach 1 is easier to use if the async operations finished within a short period of time. But if a command blocks for a long duration (e.g. waiting for COAP retransmissions and timeout), no other commands can be issued and OT CLI is less responsive in such situation.
Approach 2 is easy to implement but OT CLI users needs to be able to extract and handle async events from CLI output.
Personally I prefer approach 2 because I think it's more scalable.
As OT CLI becomes more widely used, I think it's more of an public OpenThread interface rather than some code example for invoking OpenThread APIs. From such point, we should make the OT CLI output more consistent (no mixed output of multiple commands).
Thoughts? @abtink @bukepo @jwhui

@simonlingoogle , in general having one outstanding command being executed at each point sound reasonable to me. The main thing is how to block a next command: we either need a queue of commands or a mechanism to not allow user to issue next command if one is ongoing.

@simonlingoogle , in general having one outstanding command being executed at each point sound reasonable to me. The main thing is how to block a next command: we either need a queue of commands or a mechanism to not allow user to issue next command if one is ongoing.

Yes. And the pending command queue can be indefinitely long. One solution might be ignoring the next command if one is ongoing and relying on  CLI users to always send next command when the previous command is done.
This is a reason why I prefers Approach 2 of https://github.com/openthread/openthread/pull/5540#issuecomment-693777489

This commit also adds a new error code OT_ERROR_PENDING. This
special error code indicates the success or error status of an
operation is not yet known and is pending. This is then used by some
of the CLI Process{Cmd}() methods which perform an async operation,
e.g., ProcessDiscover() returns OT_ERROR_PENDING if the discover
scan starts successfully, and later the final result is outputted from
scan callback. The OutputResult(aError) method is changed to output
nothing if the error is OT_ERROR_PENDING.

@abtink This makes me feel that we should rename OT_ERROR_XXX to OT_STATUS_XXX.
BesidesOT_ERROR_PENDING, OT_STATUS_OK also looks better than OT_ERROR_NONE to me.

@abtink This makes me feel that we should rename OT_ERROR_XXX to OT_STATUS_XXX.
BesidesOT_ERROR_PENDING, OT_STATUS_OK also looks better than OT_ERROR_NONE to me.

While I agree renaming makes these two cases read semantically better, changing the OT_ERROR_XXX -> OT_STATUS_XXX would not only require a lot of changes inside the core module, but since otError definition is part of public definition of OpenThread and is used by a lot of public APIs, it would also impact the users and platform provides of OpenThread (all the code/modules where OT APIs are being used and/or all OT platform layer implementation need to be updated, e.g. I know internally we do have a lot of modules which would be impacted, also I expect a lot of third party code needs to be changed).
This would be rather disruptive change and I think we should consider it only if/when there are very good justifications/reasons for it.  In my view, having some error cases sound/read better semantically may not be a good enough justification for such a big/disruptive change.
In general since OT is being used/integrated in more user's code, we should aim to keep OT public definitions and API remain untouched (as much as possible) to ensure higher level of backward compatibility with user's existing code.

@abtink This makes me feel that we should rename OT_ERROR_XXX to OT_STATUS_XXX.
BesidesOT_ERROR_PENDING, OT_STATUS_OK also looks better than OT_ERROR_NONE to me.

While I agree renaming makes these two cases read semantically better, changing the OT_ERROR_XXX -> OT_STATUS_XXX would not only require a lot of changes inside the core module, but since otError definition is part of public definition of OpenThread and is used by a lot of public APIs, it would also impact the users and platform providers of OpenThread (all the code/modules where OT APIs are being used and/or all OT platform layer implementation need to be updated, e.g. I know internally we do have a lot of modules which would be impacted, also I expect a lot of third party code needs to be changed).
This would be rather disruptive change and I think we should consider it only if/when there are very good justifications/reasons for it. In my view, having some error cases sound/read better semantically may not be a good enough justification for such a big/disruptive change.
In general since OT is being used/integrated in more user's code, we should aim to keep OT public definitions and API remain untouched (as much as possible) to ensure higher level of backward compatibility with user's existing code.

@abtink Totally agree with you. Just feeling that otStatus could be a better name :)

Besides OT_ERROR_PENDING, OT_STATUS_OK also looks better than OT_ERROR_NONE to me.

@abtink Totally agree with you. Just feeling that otStatus could be a better name :)

Agree with @abtink that reading semantically better is not a strong enough reason to change public APIs in such a large scale.
Furthermore, I think it's arguable whether or not OT_STATUS_OK is better than OT_ERROR_NONE. Neither does IgnoreStatus read semantically better than IgnoreError.
OT_STATUS_PENDING does read better than OT_ERROR_PENDING, but that's simply because OT_ERROR_PENDING is not a true error. I thought about suggesting not to introduce OT_ERROR_PENDING in this PR but a second thought was that it's just simpler to implement with OT_ERROR_PENDING.

authors: abtink simonlingoogle wgtdkp


text:
[grpc] add gRPC API for running CLI commands

This PR enhances gRPC service of OTNS to run CLI commands.
Since this RPC can be used to add/delete/move nodes, other gRPC calls (e.g. CtrlAddNode, CtrlDeleteNode, CtrlSetTitle) will be removed in the future PRs. @ctan-g

Why prefer unstructured calls to structured ones? Versioning and type checking will be a bit harder.

Why prefer unstructured calls to structured ones? Versioning and type checking will be a bit harder.

That's a good question indeed.
The short answer is that it automatically brings all functionalities of OTNS CLI to gRPC service.
Currently, there are more OTNS CLI commands than gRPC RPCs. For example, there is no RPC for setting packet loss ratio.
Since OTNS CLI can also run OpenThread CLI commands for nodes, now we can also run CLI commands on nodes by gRPC.
We simply don't have the manpower to implement RPCs for all commands.
For type checking. We simply don't have type checking on the Javascript side anyway. For the server side, we already have type checking for all CLI commands.
Now that we are going to have this Command RPC, I tend to remove other CtrlXxxx RPCs so that we have only one way to do something.

Thanks for the explanation, I think it makes more sense now.

authors: ctan-g simonlingoogle

repo: openthread/ot-ns


text:
🐛 [Bug]: modify [TinyButtonGroup]'s data code, then got messed component frontend.

Environment
edge 120.0.2210.61 windows 64bit
Version
v16.15.0
Version
yes
Link to minimal reproduction
https://github.com/opentiny/tiny-engine
Step to reproduce
to exercise by reproducing every compnent into my empty div, step by step of the original demo from https://opentiny.design/tiny-engine#/tiny-engine-editor  ,when in the '计费模式', modify the first button's text , bug occur
What is expected
No response
What is actually happening
No response
Any additional comments (optional)

官网demo mock数据存在问题，近期内修复

@kerneltravel 已修复

very good,  thanks! @yaoyun8

authors: kerneltravel wenmine yaoyun8

repo: opentiny/tiny-engine


text:
Provider Key: LaunchDarkly

Provider Namespace
launchdarkly
Provider Name (Optional)
launchdarkly
Public Membership

[X] I have made my membership public

Provider GPG Key
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBF8i5TMBEADE7tsXUJFbwiVWpA/Dk5dFVUoHvQKHHoSjmm7+r2WpYz371Bsf
0bRKZS+KVfK5eBIzC3ACa2HB2ZQfeAaA7aGmrK2R6LCevLxjixPk1ANmU4ERsGkG
V66+nsRMRHetpMQQoZMdmRZopgQc44IA9OCus4BWYtE9SOfVSMnV+iXKAs14qB84
kXzT3FHb2uB/vFZJtWqqJxMTb0zg7RyBIQpC6byXaI6xt9bNaopLxoLwpkVZwnPZ
BkT3n6gPGcPpNmenn4cMEn0Z22GhHlUxJ1l8+WjA3mfdnHAPLqLhdUkSHXyS7zUP
E5gZvfs2ODQyyB6MuZRXhfm7kdqiSY4KlKWLNnW4oWk1JnNbJQ5H+uuw33mSwSro
UWexv3Mpoug2gtoJKKOeQzacapFIImyJDZJ1lCJ2mDQmgV7sURvhjFbsCJFrQgoq
SUb3psnhBGm9CJeAAjLHUU9nk5GHewTt/gG6gKMFus7zhhxSgEKIPk3d/92B6lsE
u03PFLdXUq4eIzmEKHTJCINDabCXavjRhwNENRFL+sAUAoYKZv01A441Wq5ieMWf
p+SzQ+py+lOCE/CrDGa2XLdheUqWFZJLkwDG+8f5gvckjnH8Wz+zfsGE93LpPJvT
E0chzomoKJWmsatzw0qCaldmnYbzzn7OiXyJ3dv8krgEb+/i+F4BElA0pQARAQAB
tFdIZW5yeSBCYXJyb3cgKEdQRyBnZW5lcmF0ZWQgZm9yIFRlcnJhZm9ybSBwcm92
aWRlciB0cmFuc2ZlcikgPGhiYXJyb3dAbGF1bmNoZGFya2x5LmNvbT6JAk4EEwEI
ADgWIQTuPo25/pg6DM2oyzlZAtT80Dg3hgUCXyLlMwIbAwULCQgHAgYVCgkICwIE
FgIDAQIeAQIXgAAKCRBZAtT80Dg3hrFcD/9gaT+SoY5EBcFYdRQDmkNgw8n38Fd3
amJhT7UEv6lZiSgf9TqNaXzW0s5AEaCQFmtHDGwQjBcoQ2KDA9PmtUJvQ6mzs2Yu
L9peG72NUPfKxZL1vTE243XEa4X/5fuSXOeRY6ynvzITSmrKGHoqTMwW5Ek4x2Ly
RyuG1ZorHd616fhoFLg1sKdtTU/ZQjV0HBHISJF/JfFE3xf/h7njn3WkkKpr9WFL
ORdMYZAVQEO2QMRJA138oTgqUTX7lx2bW2Dpy0hclaKDkQFKvwFlF/0o16X+5hrR
LPBBgw71+QFabX5X2qewYZsUsni7pVDuwtF4cy+87GybAUH+RWIWoEXN3mXnFsmw
cAWNvBEI16lPKkRnl6bHKPWluSWOodedNzF/UoKl1FkAxdPdrmiaRRr1bfaw4Bkl
RJQdU+s2l2Q7eZ+KiJdmZFv3D9yClKvs2ffr3pJJXOAbhShpmKeWKd+SPuZa5W5/
edwIMmoj/2sjBhbqTTRLS4Z9frY54BWWDapn52U12aa88ocbLpxteXxiMNoTV7/o
w3RreiWAaHafvNdhsV+AMf56cHYtNQqLRHilh/Q9vGrd9iDX+EsAekUs9vukSg+m
j7LjtnmHCZdcGspavO+FXct4ROM9M3UUqH8qR3qA1u4Yvig3XDYoCUPkEFPi/9js
jcr3T5waFkOGB7kCDQRfIuUzARAA4X/u1S/bVxdJOQB+IF5xuF2GZfc/JgBXqQg3
kOolk/VjBeSQDJ6QIBfZCmx5rJ7VkTtspk1k5la4EI5iNSZUqeQJH5IZ/dC3Blbz
dPc8+9tQox5QGBmFPbuGUswjRJ57vwklazzfBjVa8Rc/pJR6Uwdeh+i7k51pVLUe
MbOpSJFrWZphohjJi/c4G73ppwXtjTD0/e/21dMiGBZx0vpqXQtRDYOso9HWrBOz
3Pc+RqAA37G5G1dSdc533XKWmIqrmWL3IBwvfCH6sEMX8B56BxBYWeUHnngSqqjc
AtUz/DvmtufQdRcPc3ihxGNpKlm+b7L5uyQLznLUNyHPYh3ZV02fNCHMAzFX1nXV
tdtKwCQazb69JIQMebiqBCLLn9YAFPNiOhba777PxROd1yPKu3D8GxDgMhtgWmu9
gcEHRhh6TfP0ZlIkWvBACF0P9seoZl36l9PAcq5IOltpyslew6WYSvcNqrwe6GHv
vrZB+OanKOlwB8sftIJezzC/ySgIl5bnVbPxOVaLPXiPUsHlLmqwk499wUqUnst6
YJCtFPsEkMV/FAtpsXA/cZGmWiyB2W1AXATvZEqJXZbwNnPHqmZ8zQGZPkcTTpCI
+pidlbqWTrChAlBHBiUP7rUe02fE33mf9er382dwaba0sOYS4ObvHZWH8QY4Ysdc
VZuc1ZkAEQEAAYkCNgQYAQgAIBYhBO4+jbn+mDoMzajLOVkC1PzQODeGBQJfIuUz
AhsMAAoJEFkC1PzQODeGLsMP/0fI5ecTH6WdMXQ/dFylTkiMrvHZXoMvoaA6K1lg
SlVYLQl5y/IQvUIUrhkIgMGevu20mGQ+COM149njSWbD6DVc/HAf0rI3qRdPdBcj
YibaKbjJI2t9isYmiCTSNCdeiqSfiu5mmRadNw6S25wixOQRuDbHz/6BivI4/fqz
ve9Ed2KnJvxMaNXAJMni5Xjfa7mFI4AxwC1fgqiBsw2u0ZGfbYP0XZnTQ+yKIYJo
f92iecZXA8/bELfyprG1QH58vyoIfPYJKdVDuxOhywN5rE5N+EcjnsV1uNNCGM8n
5SFUTVrcW+tEbvsVsBKAyFxHLaesCY6g0dQL051ZZ/TlvSmNuJZ3QyTsYy/TfQmY
4sJ+6cS6VPn9KgVFalMD2z9TbPZz2eSKBgV3VsbOgJfmdOCC9/3KCODzIQWwhKEd
sMbH7uY97EHAr1yCQKsLEUdmW02r5Gj7YCSi4YRRU4tFDpwxWgYyKxkszFehdDPc
UbAmox8JYT6L7DVhAmOyDufGHJ8c8EDfCdrqyciuXeZJdPoCVUZZZTJOiJc+0D0R
g4dwdeoYEk/GdcUZGccYf6i0hrt+YMAn3D49zmnp3iNLvXaakE9daqHtrIjBNlUb
h3tDHYJYH1ejsOx//9FzJQnNex/9uMZ1KwCG/HxdEMTTGo1UTZoxTeyNv1kX+HbP
3xJS
=Wdis
-----END PGP PUBLIC KEY BLOCK-----

This was re-applied when the additional key was submitted

repo: opentofu/registry


text:
test on travis

cheap & easy testing. If all the adapter tests still pass there is little risk

let's see...

repo: opentok/snoop


text:
DIsplay TEI without CETEIcean

Get rid of CETEIcean:

generate HTML files with embedded TEI;
transform select TEI element to HTML;
keep TEI element in the TEI namespace;
keep TEI element names;
assign XHTML namespace to the transformed elements;
restrict TEI CSS to TEI namespace;
restrict other CSS to XHTML namespace;
use the transformation on the parts of the facsimile files;
do not write augmented TEI and HTML wrappers like now;
save/restore window position;
remove CETEicean;

Blog (include parts of the xml README):

TEI Boilerplate;
CETEIcean;
broken development process;
static/dynamic;
official XSLT;
pre-generation;
pretty-printing;
Scala Tags;

merged into #169

repo: opentorah/opentorah


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

In ea476f6, [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 dc3f7c3 after 7 minutes.

repo: openupm/upptime-openupmcn


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

In 63a3f18, [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 6a8b38b after 28 minutes.


text:
🛑 [CN] OpenUPM Website Packages is down

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

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Packages is back up in 7371d9f after 8 minutes.


text:
🛑 [CN] OpenUPM Website is down

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

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in 0ecaa46 after 9 minutes.


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

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

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Registry /-/all is back up in e00f3f2 after 18 minutes.


text:
🛑 [CN] OpenUPM Website Docs is down

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

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in 73af487.

repo: openupm/upptime


text:
error on nonframeshift deletion

Dear all,
we are experiencing this error on a non-frameshift deletion, ending with a stopgain (quite rare):
protein change: p.V340_*358del
varcode definition:
vv = Variant(contig=16, start=30128111, ref='CTGGGGTGGTAGAGACAGCAAGGCTCAGGCCTGGCATGGGGGATGCCTACGTGCCCCCCTGCTCCCCTGCCCCCAGCCCCACTGCTGCTGGGGACTGGCCCAC', alt='', ensembl='GRCh37')

vv.effects()
INFO:varcode.effects.effect_prediction:Mutation in variant Variant(contig='16', start=30128112, ref='CTGGGGTGGTAGAGACAGCAAGGCTCAGGCCTGGCATGGGGGATGCCTACGTGCCCCCCTGCTCCCCTGCCCCCAGCCCCACTGCTGCTGGGGACTG', alt='', reference_name='GRCh37') starts before exon Exon(exon_id='ENSE00001520895', gene_id='ENSG00000102882', gene_name='MAPK3', contig='16', start=30128158, end=30128324, strand='-')
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/varcode/variant.py", line 452, in effects
variant=self, raise_on_error=raise_on_error)
File "/usr/local/lib/python2.7/dist-packages/varcode/effects/effect_prediction.py", line 96, in predict_variant_effects
transcript=transcript)
File "/usr/local/lib/python2.7/dist-packages/varcode/effects/effect_prediction.py", line 215, in predict_variant_effect_on_transcript
variant, exon, exon_number, transcript)
File "/usr/local/lib/python2.7/dist-packages/varcode/effects/effect_prediction.py", line 392, in exonic_transcript_effect
transcript_offset=transcript_offset)
File "/usr/local/lib/python2.7/dist-packages/varcode/effects/effect_prediction_coding.py", line 122, in predict_variant_coding_effect_on_transcript
sequence_from_start_codon=sequence_from_start_codon)
File "/usr/local/lib/python2.7/dist-packages/varcode/effects/effect_prediction_coding_in_frame.py", line 239, in predict_in_frame_coding_effect
aa_alt=aa_alt)
File "/usr/local/lib/python2.7/dist-packages/varcode/effects/effect_classes.py", line 670, in init
"If no amino acids added by StopLoss then it should be Silent")
ValueError: If no amino acids added by StopLoss then it should be Silent

Seems to instantiate a StopLoss object and it raises error from there.

any updates on this? thank you!

repo: openvax/varcode


text:
Fix memory issue in TextStreamer

This PR aim to fix potential memory issue in TextStreamer used in greedy_causal_lm.cpp.
Here is problem description:
https://github.com/openvinotoolkit/openvino.genai/blob/c3c3173715a578ab2a49ecd58de1f45c48bdcfd8/text_generation/causal_lm/cpp/greedy_causal_lm.cpp#L30-L45
During the text generation, for each text_streamer{std::move(detokenizer)} call, token_cache, text.size() and print_len will increased by 1.
However when \n generated, token_cache will be clear, print_len=0 inside if condition, but print_len will be override with text.size() again (which is some value >0, depends on generated token_cache, say 120).
https://github.com/openvinotoolkit/openvino.genai/blob/c3c3173715a578ab2a49ecd58de1f45c48bdcfd8/text_generation/causal_lm/cpp/greedy_causal_lm.cpp#L44
Then for next token, we have len(token_cache)=1, text.size()=1, but print_length=120, then program hang in following line because invalid memory access:
https://github.com/openvinotoolkit/openvino.genai/blob/c3c3173715a578ab2a49ecd58de1f45c48bdcfd8/text_generation/causal_lm/cpp/greedy_causal_lm.cpp#L43
This PR add return in if condition to avoid unexpected print_len assignment.

@Wovchena, could you please have a check?

Thank you. Please retarget to releases/2023/3. I will merge releases/2023/3 into master later. Or you can submit a separate PR for releases/2023/3

Re-target to releases/2023/3

I'll merge https://github.com/openvinotoolkit/openvino.genai/pull/201 instead


text:
ONNX Post-Training Quantization（semantic segmentation task）

nncf is a very useful tool. But I didn't find any example about segmentation of quantized onnx after training, can you provide some examples of semantic segmentation? Such as VOC dataset, Cityspace dataset.

i have also same issue how to use nncf direct no ui based system.

Hello,
You can find notebook to quantize segmentation model here: https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/110-ct-segmentation-quantize
I highly recommend using OpenVINO model to obtain quantized model with the best performance in OpenVINO.

Hello,
You can find notebook to quantize segmentation model here: https://github.com/openvinotoolkit/openvino_notebooks/tree/main/notebooks/110-ct-segmentation-quantize
I highly recommend using OpenVINO model to obtain quantized model with the best performance in OpenVINO.

Thank for the reply, I will try it.

It works on a local Linux. I used mint and an AMD processor. If you take the segmentation documentation steps from the project, this works local no issues. I would  check out yolo8 seg demo docs

Closing this, I hope previous responses were sufficient to help you proceed. Feel free to reopen and ask additional questions related to this topic.

i have also same issue how to use nncf direct no ui based system.

import nncf
import openvino.runtime as ov
import torch
from torchvision import datasets, transforms
import openvino.runtime as ov
model = ov.Core().read_model("./model4/end2end.xml")
train_transforms = transforms.Compose([
transforms.Resize((512, 512)),
transforms.RandomCrop((512, 512)),
transforms.RandomHorizontalFlip(),
transforms.ColorJitter(brightness=0.2, contrast=0.2, saturation=0.2, hue=0.1),
transforms.ToTensor(),
transforms.Normalize(mean=[0.47, 0.45, 0.44], std=[0.37, 0.35, 0.34]),
])
#calibration_dataset = ImageFolder("./calibration_dataset", transform=train_transforms)
val_dataset = datasets.ImageFolder("./FNDataSet", transform=train_transforms )
dataset_loader = torch.utils.data.DataLoader(val_dataset, batch_size=1)
def transform_fn(data_item):
images, _ = data_item
return images
calibration_dataset = nncf.Dataset(dataset_loader, transform_fn)
quantized_model = nncf.quantize(model, calibration_dataset)
ov.serialize(quantized_model, "./model4/INT8_FN.xml")
I hope it can help you


text:
The red-pajama model crashes when it attempts to compile on the CPU in 254-llm-chatbot.ipynb

Describe the bug
In commit #1475 the red-pajama model crashes when it attempts to compile on the CPU in 254-llm-chatbot.ipynb.
It is likely this is due to the set of installed packages I have in my enviroment, I have been unable to find a set of packages and notebook commit which works for all the models in 254-llm-chatbot.ipynb.
Expected behavior
I would not expect the red-pajama model to crash when executing the notebook.
Screenshots

** Environment information **
Packages installed in my environment:
about-time==4.2.1
absl-py==2.0.0
accelerate==0.24.1
addict==2.4.0
aiofiles==22.1.0
aiohttp==3.8.6
aiosignal==1.3.1
aiosqlite==0.19.0
alive-progress==3.1.5
altair==5.1.2
annotated-types==0.6.0
anyio==3.7.1
argon2-cffi==23.1.0
argon2-cffi-bindings==21.2.0
arrow==1.3.0
asttokens==2.4.1
astunparse==1.6.3
async-timeout==4.0.3
attrs==23.1.0
autograd==1.6.2
Babel==2.13.1
beautifulsoup4==4.12.2
bleach==6.1.0
cachetools==5.3.2
certifi==2023.7.22
cffi==1.16.0
charset-normalizer==3.3.2
click==8.1.7
cma==3.2.2
coloredlogs==15.0.1
comm==0.2.0
controlnet-aux==0.0.7
cycler==0.12.1
datasets==2.14.6
debugpy==1.8.0
decorator==5.1.1
defusedxml==0.7.1
Deprecated==1.2.14
diffusers==0.23.0
dill==0.3.7
einops==0.7.0
entrypoints==0.4
exceptiongroup==1.1.3
executing==2.0.1
fastapi==0.104.1
fastjsonschema==2.18.1
ffmpy==0.3.1
filelock==3.13.1
flatbuffers==23.5.26
fonttools==4.44.0
fqdn==1.5.1
frozenlist==1.4.0
fsspec==2023.10.0
future==0.18.3
gast==0.5.4
google-auth==2.23.4
google-auth-oauthlib==1.0.0
google-pasta==0.2.0
gradio==3.47.1
gradio_client==0.6.0
grapheme==0.6.0
grpcio==1.59.2
h11==0.14.0
h5py==3.10.0
httpcore==1.0.1
httpx==0.25.1
huggingface-hub==0.17.3
humanfriendly==10.0
idna==3.4
imageio==2.32.0
importlib-metadata==6.8.0
importlib-resources==6.1.1
ipykernel==6.26.0
ipython==8.17.2
ipython-genutils==0.2.0
ipywidgets==7.7.0
isoduration==20.11.0
jedi==0.19.1
Jinja2==3.1.2
joblib==1.3.2
json5==0.9.14
jsonpointer==2.4
jsonschema==4.19.2
jsonschema-specifications==2023.7.1
jstyleson==0.0.2
jupyter-events==0.9.0
jupyter-ydoc==0.2.5
jupyter_client==7.4.9
jupyter_core==5.5.0
jupyter_server==2.10.0
jupyter_server_fileid==0.9.0
jupyter_server_terminals==0.4.4
jupyter_server_ydoc==0.8.0
jupyterlab==3.6.3
jupyterlab-pygments==0.2.2
jupyterlab-widgets==1.1.0
jupyterlab_server==2.25.1
keras==2.14.0
kiwisolver==1.4.5
lazy_loader==0.3
libclang==16.0.6
Markdown==3.5.1
markdown-it-py==3.0.0
MarkupSafe==2.1.3
matplotlib==3.5.2
matplotlib-inline==0.1.6
mdurl==0.1.2
mistune==3.0.2
ml-dtypes==0.2.0
mpmath==1.3.0
multidict==6.0.4
multiprocess==0.70.15
natsort==8.4.0
nbclassic==1.0.0
nbclient==0.9.0
nbconvert==7.11.0
nbformat==5.9.2
nest-asyncio==1.5.8
networkx==2.8.2
ninja==1.10.2.4
nncf @ git+https://github.com/openvinotoolkit/nncf.git@b6910ea3e5e30125dee714da9318b642d8cba7d5
notebook==6.5.6
notebook_shim==0.2.3
numpy==1.24.4
oauthlib==3.2.2
onnx==1.15.0
onnxruntime==1.16.2
opencv-python==4.8.1.78
openvino==2023.2.0
openvino-nightly==2023.3.0.dev20231116
openvino-telemetry==2023.2.1
opt-einsum==3.3.0
optimum==1.14.0
optimum-intel @ git+https://github.com/huggingface/optimum-intel.git@f248835b16ce4ec054d6d4d629dff4213fe94157
orjson==3.9.10
overrides==7.4.0
packaging==23.2
pandas==2.0.3
pandocfilters==1.5.0
parso==0.8.3
pexpect==4.8.0
Pillow==10.0.1
pipfile==0.0.2
platformdirs==3.11.0
prometheus-client==0.18.0
prompt-toolkit==3.0.39
protobuf==4.25.0
psutil==5.9.6
ptyprocess==0.7.0
pure-eval==0.2.2
pyarrow==14.0.1
pyasn1==0.5.0
pyasn1-modules==0.3.0
pycparser==2.21
pydantic==2.4.2
pydantic_core==2.10.1
pydot==1.4.2
pydub==0.25.1
Pygments==2.16.1
pymoo==0.6.0.1
pyparsing==2.4.7
python-dateutil==2.8.2
python-json-logger==2.0.7
python-multipart==0.0.6
pytz==2023.3.post1
PyYAML==6.0.1
pyzmq==24.0.1
referencing==0.30.2
regex==2023.10.3
requests==2.31.0
requests-oauthlib==1.3.1
rfc3339-validator==0.1.4
rfc3986-validator==0.1.1
rich==13.6.0
rpds-py==0.12.0
rsa==4.9
safetensors==0.4.0
scikit-image==0.22.0
scikit-learn==1.3.2
scipy==1.10.1
semantic-version==2.10.0
Send2Trash==1.8.2
sentencepiece==0.1.99
six==1.16.0
sniffio==1.3.0
soupsieve==2.5
stack-data==0.6.3
starlette==0.27.0
sympy==1.12
tensorboard==2.14.1
tensorboard-data-server==0.7.2
tensorflow==2.14.0
tensorflow-estimator==2.14.0
tensorflow-io-gcs-filesystem==0.34.0
termcolor==2.3.0
terminado==0.17.1
texttable==1.7.0
threadpoolctl==3.2.0
tifffile==2023.9.26
tiktoken==0.5.1
timm==0.9.10
tinycss2==1.2.1
tokenizers==0.14.1
toml==0.10.2
tomli==2.0.1
toolz==0.12.0
torch==2.1.0+cpu
torchaudio==2.1.0+cpu
torchvision==0.16.0+cpu
tornado==6.3.3
tqdm==4.66.1
traitlets==5.13.0
transformers==4.34.1
transformers-stream-generator==0.0.4
types-python-dateutil==2.8.19.14
typing_extensions==4.8.0
tzdata==2023.3
uri-template==1.3.0
urllib3==1.26.15
uvicorn==0.24.0.post1
wcwidth==0.2.9
webcolors==1.13
webencodings==0.5.1
websocket-client==1.6.4
websockets==11.0.3
Werkzeug==3.0.1
widgetsnbextension==3.6.0
wrapt==1.14.1
xxhash==3.4.1
y-py==0.6.2
yarl==1.9.2
ypy-websocket==0.8.4
zipp==3.17.0

PR with fix https://github.com/openvinotoolkit/openvino_notebooks/pull/1492


text:
daemonset: miscellaneous fixes to get daemonset to work

No need for KUBECONFIG file within the POD to access cluster
out-of-band (without using service IP). Use the 'ovn' serviceaccount
token and ca.crt instead. Require user to specify K8S_APISERVER
parameter through ovn-k8s ConfigMap like we had before.
Remove all the /etc/origin/node mountpath since we don't need the
kubeconfig file anymore.
Add bind9-host debian package which provides `host' command that was
being used in ovnkube.sh
Signed-off-by: Girish Moodalbail gmoodalbail@nvidia.com

@pecameron @dcbw @shettyg PTAL. Thanks.

@girishmg We explicitly removed K8S_APISERVER from the config map to reduce the information that that needs to be configured at install. All that is left it the service cidr and cluster cidr list. Kubernetes must install a kubeconfig on each node (maybe /etc/kubernetes/kublet.kubeconfig?) which can be mounted into containers. Openshift just gives it a different name.
I am not comfortable with this change.
@squeed, could you comment on this?

@pecameron at the cost of simplifying not setting one extra key in Config Map we are complicating the whole deployment of K8s cluster.
All we need from the Node Kubeconfig file is the external K8s API server IP. For that we need to now mount the host directory into the POD and provide the POD access to the Node Kubeconfig file. This is a security issue as well. With that  kubeconfig file you can control the whole K8s cluster from within the OVN daemonset pods. That is not right.
If you need access to K8s API server out-of-band, then you will need to provide the K8s API server as a configuration variable. We don't need to mount the whole kubeconfig file.

IMO, if it is just a K8S API server IP, and it avoids a deployment config of bind mounting a directory in every node, we should go for it.

We discussed this in our standup today too. The goal is to get ovn-kubernetes the apiserver address with as little configuration as possible on the user's part. Since in OpenShift we're configuring it all with the cluster-network-operator and that already knows the apiserver URL, I think we can just stuff that into the config map that the CNO will make for ovn-kube.
So I think I'm in favor of this change and I think the patch is OK except for the comment about hostname -> IP lookup.

/lgtm

@pecameron
Would you mind rebuilding and pushing a new image?

On 02/12/2019 04:08 PM, Gurucharan Shetty wrote:

@pecameron https://github.com/pecameron
Would you mind rebuilding and pushing a new image?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openvswitch/ovn-kubernetes/pull/605#issuecomment-462935495,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANUgemYeC0Jd5hwnhaSysAriLkJq55u0ks5vMy1SgaJpZM4akb0L.

Done.

@shettyg Built and pushed.

authors: dcbw girishmg pecameron shettyg

repo: openvswitch/ovn-kubernetes


text:
No error code send to verifier during exception while decrypting request

Notes:
with reference to the following bug https://github.com/google/identity-credential/issues/115 the fix provided is not correct and still we get the exception due to
try{
ensureSessionEncryption(data);
}catch(IllegalStateExceptione){
mTransport.sendMessage(SessionEncryptionDevice.encodeStatusToReader(
Constants.SESSION_DATA_STATUS_ERROR_SESSION_ENCRYPTION));
mTransport.close();
reportError(newError("ErrordecodingEReaderKeyinSessionEstablishment",e));
return;
}
The above code is not capturing all exception the method throws. Internal logics of method "ensureSessionEncryption()" throws "IllegalArgumentException" as well which is however not cached in catch block. This cause the app to crash still.
Specifications

Version:  Android 10(Quince Tart)
Platform: Android

closing this since it appears to be fixed with #332

authors: suzannajiwani vaimut


text:
Project: HTTPArchive

Participate in the HTTPArchive project

[ ] Review Performance 2022 https://github.com/HTTPArchive/almanac.httparchive.org/issues/2890
[ ] Review Accessibility 2022 https://github.com/HTTPArchive/almanac.httparchive.org/issues/2889
[ ] Review Privacy 2022 https://github.com/HTTPArchive/almanac.httparchive.org/issues/2891
[ ] Review CSS 2022 https://github.com/HTTPArchive/almanac.httparchive.org/issues/2879

Any other ones? Privacy? JS? APIS? Fonts? Markup? See https://github.com/HTTPArchive/almanac.httparchive.org/issues?q=is%3Aissue+is%3Aopen+2022+label%3A"2022+chapter"

Thanks for filing this OWD project proposal!
I'm not familiar with the HTTPArchive project but the linked issues all have a publication date of September 26 ...
Can you elaborate a bit what our involvement should be (or has been) until then?
If there hasn't been any involvement from our side, I guess we should reconsider this project in the next year and close here for now.

Closing this. Deadline is too soon.

repo: openwebdocs/project


text:
[models] Owner field

This is another field we have added but we are not using in the code nor we are planning to use it right now.
I don't like this sort of dead useless code, imagine other people will come after us to maintain this project, they will think: what does this thing do? Can I use it somehow? Should I remove it? Should I reimplement it?
I think that we should either define what's the purpose of this or remove it.
@hispanico @anurag-ks

I think we can reimplement this field later on, as we are not using it specifically anywhere else, in my latest PR #25, I have removed the field.

authors: anurag-ks nemesisdesign

repo: openwisp/django-ipam


text:
luci-app-attendedsysupgrade: use remote revision for version code

With 8860ca069c04e3dbd3f107f1526f2901f1085902 the check against the version_code parameter was implemented but was incorrectly set to the current revision instead of the latest available remote revision.
This resulted in not being able to upgrade due to the version_code parameter never matched the newer remote revision on the sysupgrade server.
To clarify the problem, r26637-05aec66d53 is the current running revision, and r26679-70088a7e4c is the latest remote revision (which we want to upgrade to) at time of writing this.
See https://github.com/openwrt/luci/pull/7163#issuecomment-2176678529
Without fix:

With fix:

[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: (x86/64, SNAPSHOT r26637-05aec66d53, Firefox) :white_check_mark:
[X] ( Preferred ) Mention: @ the original code author for feedback @aparcar
[ ] ( Preferred ) Screenshot or mp4 of changes:
[ ] ( Optional ) Closes: e.g. openwrt/luci#issue-number
[ ] ( Optional ) Depends on: e.g. openwrt/packages#pr-number in sister repo
[X] Description: (describe the changes proposed in this PR)

We should if possible wait for @aparcar to verify this but seeing how firmware selector works as described in https://github.com/openwrt/luci/pull/7163#issuecomment-2176770355 I'm very sure this is how it's supposed to be implemented, with the latest remote revision being supplied as the version_code parameter.

Could you create a PR to revert this? And also is anyone interested in taking over maintainer ship of the app?

Could you create a PR to revert this?

https://github.com/openwrt/luci/pull/7168

So what's the consensus on this? It goes on with some modification?

So what's the consensus on this? It goes on with some modification?

That's the goal, the gist is that the LuCI app has the ability to flash the current running version again (it's part of the "Advanced options"), which breaks if you are running a SNAPSHOT and supply the version_code parameter to the API as you can't re-flash a SNAPSHOT since the image builders for that version are long gone by then. There needs to be some code to remove the version_code parameter only if not running on a stable branch (23.05, 22.03 etc.) if this case happens without breaking existing functionality.

Got it. OK, is that achievable?
Snapshot just needs to take current snapshot but there's no trivial way to do so?

It should be, I just haven't had time to look into into (work ya know :P). The one thing I can't wrap my head around right now is if the LuCI app actually supports to re-flash the existing SNAPSHOT version you have installed, which I think is no (due to the above reasons in the previous comment). However, it's still presented as a valid option at the moment to do this, which, if this is kept, will break when adding the version_code parameter as the image builders for SNAPSHOT:s doesn't accept "old" version codes.
So, my guess right now (I haven't had time to investigate it tho) is that the behavior that the LuCI app allowed you to re-flash the same installed SNAPSHOT has never been a valid configuration, and it would then instead just flash the newest available image from the image builders instead of the one you actually requested. Adding the version_code parameter exposed this existing, invalid configuration, which is why it wasn't as trivial to solve that I thought it would be, as the correct way to fix this then would be to disallow the re-flash of the already installed SNAPSHOT version by hiding it in the dropdown or any similar solution.

Is this changed any by your new PR #7203 ?

Is this changed any by your new PR #7203 ?

No, it's two completely different issues. In #7203, all the existing code already used the versioned endpoints except for /api/overview, so the /api/v1/build endpoint that accepts the version_code parameter wasn't touched at all in that PR.

authors: aparcar dannil systemcrash

repo: openwrt/luci


text:
The import package in the project's go file has the problem of irregular sorting.

What happened:
The project's go file import package sort is not standardized.
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

OpenYurt version:
Kubernetes version (use kubectl version):
OS (e.g: cat /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

others
/kind question

@yanyhui  Thank you for raising issue.
Would you can add some golang official links about package import definitions?

Standard answer:
Standard library - > project internal package - > internal third party - > external third party package.

Standard answer: Standard library - > project internal package - > internal third party - > external third party package.

@yanyhui Thank you for your feedback. would you be able to add some urls for import standard?

authors: rambohe-ch yanyhui

repo: openyurtio/openyurt


text:
Fix: update package dependencies

update GHSA-vvpx-j8f3-3w6h and upgrade thought about dependencies

update GHSA-vvpx-j8f3-3w6h and upgrade thought about dependencies

I saw that golang.org/x/net@v0.7.0 is invulnerable to such security problem. Did you use go get -u golang.org/x/net@v0.7.0 to upgrade it?
I find it seems to contain more changes than using go get -u golang.org/x/net@v0.7.0 .

Directly modify the  golang.org/x/net version of go.mod

Well, here's my result
	go.uber.org/atomic v1.9.0 // indirect
	go.uber.org/multierr v1.6.0 // indirect
	go.uber.org/zap v1.19.0 // indirect
	golang.org/x/crypto v0.0.0-20210921155107-089bfa567519 // indirect
-	golang.org/x/net v0.0.0-20220225172249-27dd8689420f // indirect
+	golang.org/x/net v0.7.0 // indirect
	golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b // indirect
	golang.org/x/sync v0.0.0-20220601150217-0de741cfad7f // indirect
-	golang.org/x/term v0.0.0-20210927222741-03fcf44c2211 // indirect
-	golang.org/x/text v0.3.7 // indirect
+	golang.org/x/term v0.5.0 // indirect
+	golang.org/x/text v0.7.0 // indirect
	golang.org/x/time v0.0.0-20210723032227-1f47c861a9ac // indirect

It seems not introduce so many changes.

Update the cve vulnerabilities of these dependent packages

/approve

authors: Congrool fengshunli rambohe-ch


text:
Re-Introducing dnsmasq option in ziti-edge-tunnel specially for OPENWRT supported devices

The following shall be done:

Re-introduced dnsmasq option
Fixed an issue where routes added for individual services weren’t getting deleted after removal of service from the endpoint/identity/edge-tunnel ip route table,
Fixed an issue where, removal of the files created in dnsmasq path (again they also weren’t deleted post removal of service from the endpoint/identity/edge-tunnel.
Then added support of creation of tun interface with any name (which isn’t available with openziti code). This is required for teltonika boxes as it tun interface creation and in past we have observed that they have create issues in the box.

Hi Sameer.
My apologies if there was some confusion.
I helped you along with the previous issue to get you going quickly, because you had the code most of the way there except for the one missing line, but I should have been more clear that we don't intend to re-add the dnsmasq options to ziti-edge-tunnel.
I was suggesting that we make a plan to go forward with current releases of ziti-edge-tunnel and learn how to configure dnsmasq so that it works with the new capabilities of the DNS resolver in ziti-edge-tunnel.

@dariuszSki I think you mentioned you've gotten set to work with dnsmasq on openwrt?

Yes, not fully vetted though since I have lost connection to my remote test bed. Will provided the details here if Sameer can test it. I also asked another customer to try it out and waiting for a reply back.

uci add_list dhcp.@dnsmasq[0].server="100.64.0.2"
uci set dhcp.@dnsmasq[0].strictorder="true"
uci commit dhcp
/etc/init.d/dnsmasq restart
uci show |grep dns
...
dhcp.@dnsmasq[0]=dnsmasq
dhcp.@dnsmasq[0].domainneeded='1'
dhcp.@dnsmasq[0].boguspriv='1'
dhcp.@dnsmasq[0].filterwin2k='0'
dhcp.@dnsmasq[0].localise_queries='1'
dhcp.@dnsmasq[0].rebind_protection='1'
dhcp.@dnsmasq[0].rebind_localhost='1'
dhcp.@dnsmasq[0].local='/lan/'
dhcp.@dnsmasq[0].domain='lan'
dhcp.@dnsmasq[0].expandhosts='1'
dhcp.@dnsmasq[0].nonegcache='0'
dhcp.@dnsmasq[0].authoritative='1'
dhcp.@dnsmasq[0].readethers='1'
dhcp.@dnsmasq[0].leasefile='/tmp/dhcp.leases'
dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
dhcp.@dnsmasq[0].dhcpscript='/usr/sbin/dhcpinfo.sh'

dhcp.@dnsmasq[0].server='100.64.0.2'
dhcp.@dnsmasq[0].strictorder='true'
...

then ran the ziti-edge tunnel with u option
./ziti-edge-tunnel run -i identity.json -u 1.1.1.1

In my testing, the client on the lan would be set to send dns request to GW IP of the Lan., i.e. net 192.168.1.0/24, GW IP 192.168.1.1. Requests would be sent to 192.168.1.1, and then they should be forwarded to 100.64.0.2.

authors: dariuszSki sameersarkar-tcl scareything

repo: openziti/ziti-tunnel-sdk-c


text:
No longer have "Add To Opera" button in Chrome Web Store

There's now only "Available On Chrome" button which takes to the Chrome browser download page. Tried enable/disable and reinstall "Install Chrome Extensions" a few times but that didn't help.

If you are logged in to the chrome store with your gmail account try logging out, then installing the plugin

repo: operasoftware/chrome-webstore-extension