Calling for volunteers for adding new metrics!

Dear community,
We are excited to introduce our new evaluation library: MMEval, a unified evaluation library for multiple machine learning libraries.
With the release of MMEval, we have some metrics from the OpenMMLab algorithm library that have not yet been added. We list the metrics below and call for community help.
If you are interested, you can claim a metric by replying to this issue in the following format:
Metric No. : <The Metric No. you claim>
Status :  Apply | Submit
Links : The repo links you fork (Apply status) / The PR links you open (Submit status)

No.
Metric
Algorithm library
Level of Difficulty
Assigned to
Status / PR

1
CityScapesMetric
mmdet / mmseg
⭐⭐⭐
@Muyun99
Apply

2
CocoPanopticMetric
mmdet
⭐⭐⭐
@Even-ok
Apply

3
LVISMetric
mmdet
⭐⭐
@dmucby
Apply

4
CrowdHumanMetric
mmdet
⭐⭐
@tianleiSHI
Apply

5
DOTAMetric
mmrotate
⭐⭐
@YanxingLiu
#65

6
RotatedCocoMetric
mmrotate
⭐⭐

7
IndoorMetric
mmdet3d
⭐⭐⭐

8
InstanceSegMetric
mmdet3d
⭐⭐⭐
@Pzzzzz5142
Apply

9
KittiMetric
mmdet3d
⭐⭐⭐

10
LyftMetric
mmdet3d
⭐⭐⭐

11
NuScenesMetric
mmdet3d
⭐⭐⭐

12
WaymoMetric
mmdet3d
⭐⭐⭐

13
OneMinusNEDMetric
mmocr
⭐⭐

14
WordMetric
mmocr
⭐⭐

15
CharMetric
mmocr
⭐⭐

16
CocoWholeBodyMetric
mmpose
⭐⭐

17
NME
mmpose
⭐⭐

18
AUC
mmpose
⭐⭐

19
EPE
mmpose
⭐⭐

20
PoseTrack18Metric
mmpose
⭐⭐

21
ANetMetric
mmaction2
⭐⭐

22
AccMetric
mmaction2
⭐⭐

23
FlowOutliers
mmflow
⭐⭐
@fengsxy
Apply

24
MOTChallengeMetrics
mmtracking
⭐⭐

25
ReIDMetrics
mmtracking
⭐⭐

26
SOTMetric
mmtracking
⭐⭐

27
TAOMetric
mmtracking
⭐⭐

28
YouTubeVISMetric
mmtracking
⭐⭐
@qianlian-mozi
Apply

29
MultiScaleStructureSimilarity
mmediting
⭐⭐

30
FrechetInceptionDistance & TransFID
mmediting
⭐⭐

31
InceptionScore & TransIS
mmediting
⭐⭐

32
SAD
mmediting
⭐⭐
@xuan07472
#76

33
MattingMSE
mmediting
⭐⭐
@xuan07472
#71

34
ConnectivityError
mmediting
⭐⭐
@xuan07472
Apply

35
GradientError
mmediting
⭐⭐
@xuan07472
#78

36
PerceptualPathLength
mmediting
⭐⭐

37
PrecisionAndRecall
mmediting
⭐⭐

38
SlicedWassersteinDistance
mmediting
⭐⭐

39
NIQE
mmediting
⭐⭐

40
Equivariance
mmediting
⭐⭐

NOTES:

Documents of MMEval can be found at: https://mmeval.readthedocs.io/en/latest/
The contributing guides can be found at: https://github.com/open-mmlab/mmeval/blob/main/CONTRIBUTING.md

Examples:
We provide some examples showing how to add Metric from the OpenMMLab algorithm library to MMEval

mmeval.Accuracy from mmcsl

PR in mmeval: https://github.com/open-mmlab/mmeval/pull/6
PR in mmcls: https://github.com/open-mmlab/mmclassification/pull/1046

mmeval.MeanIoU from mmseg

PR in mmeval: https://github.com/open-mmlab/mmeval/pull/7
PR in mmseg: https://github.com/open-mmlab/mmsegmentation/pull/2003

mmeval.VOCMeanAP from mmdet

PR in mmeval: https://github.com/open-mmlab/mmeval/pull/8
PR in mmdet: https://github.com/open-mmlab/mmdetection/pull/8897

mmeval.COCODetectionMetric from mmdet

PR in mmeval: https://github.com/open-mmlab/mmeval/pull/23
PR in mmdet: https://github.com/open-mmlab/mmdetection/pull/9079

Submitted Content:

The PR in MMEval that adds the new metric (with complete documentation and testing)
The PR in original algorithm library that uses the new metric  (with evaluation comparison between using MMEval and before)

No1. CityScapesMetric

Add the CityScapesMetric from mmdet / mmseg to MMEval, and use the MMEval's CityScapesMetric in mmdet / mmseg.
Technical Tags: Python; Object detection; Semantic segmentation;
The original CityScapesMetric in mmdet
The original CityScapesMetric in mmseg

No2. CocoPanopticMetric

Add the CocoPanopticMetric from mmdet to MMEval, and use the MMEval's CocoPanopticMetric in mmdet.
Technical Tags: Python; Object detection; Panoptic segmentation;
The original CocoPanopticMetric in mmdet

No3. LVISMetric

Add the LVISMetric from mmdet to MMEval, and use the MMEval's LVISMetric in mmdet.
Technical Tags: Python; Object detection;
The original LVISMetric in mmdet

No4. CrowdHumanMetric

Add the CrowdHumanMetric from mmdet to MMEval, and use the MMEval's CrowdHumanMetric in mmdet.
Technical Tags: Python; Object detection;
The original CrowdHumanMetric in mmdet

No5. DOTAMetric

Add the DOTAMetric from mmrotate to MMEval, and use the MMEval's DOTAMetric in mmrotate.
Technical Tags: Python; Rotated object detection;
The original DOTAMetric in mmrotate

No6. RotatedCocoMetric

Add the RotatedCocoMetric from mmrotate to MMEval, and use the MMEval's RotatedCocoMetric in mmrotate.
Technical Tags: Python; Rotated object detection;
The original RotatedCocoMetric in mmrotate

No7. IndoorMetric

Add the IndoorMetric from mmdet3d to MMEval, and use the MMEval's IndoorMetric in mmdet3d.
Technical Tags: Python; 3D object detection;
The original IndoorMetric in mmdet3d

No8. InstanceSegMetric

Add the InstanceSegMetric from mmdet3d to MMEval, and use the MMEval's InstanceSegMetric in mmdet3d.
Technical Tags: Python; 3D instance segmentation;
The original InstanceSegMetric in mmdet3d

No9. KittiMetric

Add the KittiMetric from mmdet3d to MMEval, and use the MMEval's KittiMetric in mmdet3d.
Technical Tags: Python; 3D object detection;
The original KittiMetric in mmdet3d

No10. LyftMetric

Add the LyftMetric from mmdet3d to MMEval, and use the MMEval's LyftMetric in mmdet3d.
Technical Tags: Python; 3D object detection;
The original LyftMetric in mmdet3d

No11. NuScenesMetric

Add the NuScenesMetric from mmdet3d to MMEval, and use the MMEval's NuScenesMetric in mmdet3d.
Technical Tags: Python; 3D object detection;
The original NuScenesMetric in mmdet3d

No12. WaymoMetric

Add the WaymoMetric from mmdet3d to MMEval, and use the MMEval's WaymoMetric in mmdet3d.
Technical Tags: Python; 3D object detection;
The original WaymoMetric in mmdet3d

No13. OneMinusNEDMetric

Add the OneMinusNEDMetric from mmocr to MMEval, and use the MMEval's OneMinusNEDMetric in mmocr.
Technical Tags: Python; OCR;
The original OneMinusNEDMetric in mmocr

No14. WordMetric

Add the WordMetric from mmocr to MMEval, and use the MMEval's WordMetric in mmocr.
Technical Tags: Python; OCR;
The original WordMetric in mmocr

No15. CharMetric

Add the CharMetric from mmocr to MMEval, and use the MMEval's CharMetric in mmocr.
Technical Tags: Python; OCR;
The original CharMetric in mmocr

No16. CocoWholeBodyMetric

Add the CocoWholeBodyMetric from mmpose to MMEval, and use the MMEval's CocoWholeBodyMetric in mmpose.
Technical Tags: Python; Pose estimation;
The original CocoWholeBodyMetric in mmpose

No17. NME

Add the NME from mmpose to MMEval, and use the MMEval's NME in mmpose.
Technical Tags: Python; Pose estimation;
The original NME in mmpose

No18. AUC

Add the AUC from mmpose to MMEval, and use the MMEval's AUC in mmpose.
Technical Tags: Python; Pose estimation;
The original AUC in mmpose

No19. EPE

Add the EPE from mmpose to MMEval, and use the MMEval's EPE in mmpose.
Technical Tags: Python; Pose estimation;
The original EPE in mmpose

No20. PoseTrack18Metric

Add the PoseTrack18Metric from mmpose to MMEval, and use the MMEval's PoseTrack18Metric in mmpose.
Technical Tags: Python; Pose estimation;
The original PoseTrack18Metric in mmpose

No21. ANetMetric

Add the ANetMetric from mmaction2 to MMEval, and use the MMEval's ANetMetric in mmaction2.
Technical Tags: Python; Video understanding;
The original ANetMetric in mmaction2

No22. AccMetric

Add the AccMetric from mmaction2 to MMEval, and use the MMEval's AccMetric in mmaction2.
Technical Tags: Python; Video understanding;
The original AccMetric in mmaction2

No23. FlowOutliers

Add the FlowOutliers from mmflow to MMEval, and use the MMEval's FlowOutliers in mmflow.
Technical Tags: Python; Optical flow;
The original FlowOutliers in mmflow

No24. MOTChallengeMetrics

Add the MOTChallengeMetrics from mmtracking to MMEval, and use the MMEval's MOTChallengeMetrics in mmtracking.
Technical Tags: Python; Multiple object tracking;
The original MOTChallengeMetrics in mmtracking

No25. ReIDMetrics

Add the ReIDMetrics from mmtracking to MMEval, and use the MMEval's ReIDMetrics in mmtracking.
Technical Tags: Python; Re-identification;
The original ReIDMetrics in mmtracking

No26. SOTMetric

Add the SOTMetric from mmtracking to MMEval, and use the MMEval's SOTMetric in mmtracking.
Technical Tags: Python; Single object tracking;
The original SOTMetric in mmtracking

No27. TAOMetric

Add the TAOMetric from mmtracking to MMEval, and use the MMEval's TAOMetric in mmtracking.
Technical Tags: Python; Object tracking;
The original TAOMetric in mmtracking

No28. YouTubeVISMetric

Add the YouTubeVISMetric from mmtracking to MMEval, and use the MMEval's YouTubeVISMetric in mmtracking.
Technical Tags: Python; Video instance segmentation;
The original YouTubeVISMetric in mmtracking

No29. MultiScaleStructureSimilarity

Add the MultiScaleStructureSimilarity from mmediting to MMEval, and use the MMEval's MultiScaleStructureSimilarity in mmediting.
Technical Tags: Python; GAN;
The original MultiScaleStructureSimilarity in mmediting

No30. FrechetInceptionDistance & TransFID

Add the FrechetInceptionDistance and TransFID from mmediting to MMEval, and use the MMEval's FrechetInceptionDistance and TransFID in mmediting.
Technical Tags: Python; GAN;
The original FrechetInceptionDistance in mmediting
The original TransFID in mmediting

No31. InceptionScore & TransIS

Add the InceptionScore and TransIS from mmediting to MMEval, and use the MMEval's  InceptionScore and TransIS in mmediting.
Technical Tags: Python; GAN;
The original InceptionScore in mmediting
The original TransIS in mmediting

No32. SAD

Add the SAD from mmediting to MMEval, and use the MMEval's SAD in mmediting.
Technical Tags: Python; GAN;
The original SAD in mmediting

No33. MattingMSE

Add the MattingMSE from mmediting to MMEval, and use the MMEval's MattingMSE in mmediting.
Technical Tags: Python; Matting;
The original MattingMSE in mmediting

No34. ConnectivityError

Add the ConnectivityError from mmediting to MMEval, and use the MMEval's ConnectivityError in mmediting.
Technical Tags: Python; Matting;
The original ConnectivityError in mmediting

No35. GradientError

Add the GradientError from mmediting to MMEval, and use the MMEval's GradientError in mmediting.
Technical Tags: Python; Matting;
The original GradientError in mmediting

No36. PerceptualPathLength

Add the PerceptualPathLength from mmediting to MMEval, and use the MMEval's PerceptualPathLength in mmediting.
Technical Tags: Python; GAN;
The original PerceptualPathLength in mmediting

No37. PrecisionAndRecall

Add the PrecisionAndRecall from mmediting to MMEval, and use the MMEval's PrecisionAndRecall in mmediting.
Technical Tags: Python; GAN;
The original PrecisionAndRecall in mmediting

No38. SlicedWassersteinDistance

Add the SlicedWassersteinDistance from mmediting to MMEval, and use the MMEval's SlicedWassersteinDistance in mmediting.
Technical Tags: Python; GAN;
The original SlicedWassersteinDistance in mmediting

No39. NIQE

Add the NIQE from mmediting to MMEval, and use the MMEval's NIQE in mmediting.
Technical Tags: Python; GAN;
The original NIQE in mmediting

No40. Equivariance

Add the Equivariance from mmediting to MMEval, and use the MMEval's Equivariance in mmediting.
Technical Tags: Python; GAN;
The original Equivariance in mmediting

Metric No.5 https://github.com/open-mmlab/mmeval/issues/50#DOTAMetric
Status : Apply
Links : https://github.com/YanxingLiu/mmeval.git

Metric No.3 LVISMetric
Status : Apply
Links : https://github.com/dmucby/mmeval

Metric No33. MattingMSE
Status :  Apply
Links : https://github.com/xuan07472/mmeval

Metric No.4 CrowdHumanMetric
Status: Apply
Links: https://github.com/tianleiSHI/mmeval

Metric No.8 InstanceSegMetric
Status: Apply
Links: https://github.com/Pzzzzz5142/mmeval

Metric No.32 SAD
Status :  Apply
Links : https://github.com/xuan07472/mmeval

Metric No.33 MattingMSE
Status :  Submit
Links : https://github.com/open-mmlab/mmeval/pull/71#issue-1514344586

Metric No.32 SAD
Status :  Submit
Links : https://github.com/open-mmlab/mmeval/pull/76

Metric No.5 https://github.com/open-mmlab/mmeval/issues/50#DOTAMetric
Status : Submit
Links : https://github.com/YanxingLiu/mmeval.git

Metric No.28 :
Status :  Apply
Links : https://github.com/qianlian-mozi/mmeval

Metric No.35 GradientError
Status :  Apply
Links : https://github.com/xuan07472/mmeval

Metric No.35 GradientError
Status :  Submit
Links : https://github.com/open-mmlab/mmeval/pull/78

Metric No.35 ConnectivityError
Status :  Apply
Links : https://github.com/xuan07472/mmeval

Metric No.34 ConnectivityError
Status :  Submit
Links : https://github.com/open-mmlab/mmediting/pull/1600

Metric No.6 RotatedCocoMetric
Satus: Apply
Links: https://github.com/YanxingLiu/mmeval.git


Corrected documentation on /tables/{tableName} controller API

The method also fetches table config, not just enable/disable/drop a table.

Codecov Report

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

@@            Coverage Diff            @@
##           master   #2586      +/-   ##
=========================================
+ Coverage   69.37%   69.4%   +0.03%
=========================================
  Files         861     861
  Lines       39918   39918
  Branches     5360    5360
=========================================
+ Hits        27693   27706      +13
+ Misses      10415   10404      -11
+ Partials     1810    1808       -2

Impacted Files
Coverage Δ

...oller/api/resources/PinotTableRestletResource.java
39.87% <ø> (ø)
:arrow_up:

...e/impl/dictionary/LongOnHeapMutableDictionary.java
82.22% <0%> (-13.34%)
:arrow_down:

...impl/dictionary/DoubleOnHeapMutableDictionary.java
75.55% <0%> (-6.67%)
:arrow_down:

...e/operator/dociditerators/SortedDocIdIterator.java
58.33% <0%> (-5.56%)
:arrow_down:

...not/core/query/pruner/DataSchemaSegmentPruner.java
53.65% <0%> (-4.88%)
:arrow_down:

...inot/core/operator/docidsets/AndBlockDocIdSet.java
57.93% <0%> (-1.38%)
:arrow_down:

.../pinot/core/common/datatable/DataTableBuilder.java
91.06% <0%> (-1.12%)
:arrow_down:

...pby/NoDictionarySingleColumnGroupKeyGenerator.java
91.91% <0%> (-1.02%)
:arrow_down:

...regation/function/customobject/QuantileDigest.java
49.14% <0%> (-0.43%)
:arrow_down:

.../broker/routing/HelixExternalViewBasedRouting.java
90.81% <0%> (-0.36%)
:arrow_down:

... and 11 more

Continue to review full report at Codecov.

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


E2E-test 24.05

As team,
I want to execute the E2E-tests,
so that our aplication is thoroughly tested.
Hints / Details

Test plans:

https://jira.catena-x.net/browse/TEST-1887
https://jira.catena-x.net/browse/TEST-1892
https://jira.catena-x.net/browse/TEST-1888

Additionally the data sovereignty team will assign tests to Trace-X. These must be tested as well.
The E2E-test period is from 19.04.2024 - 10.05.2024
Acceptance Criteria

All tests are executed and any findings documented

Tasks:

Test Scenario Policy not okay -> IRS shows tombstone in trace-x.

Following bugs have been found during the E2E-tests:
https://github.com/eclipse-tractusx/traceability-foss/issues/956
https://github.com/eclipse-tractusx/traceability-foss/issues/957
https://github.com/eclipse-tractusx/traceability-foss/issues/958

PO acceptance in behalf of @jzbmw as all test executions done successfully.


add clarifying instructions where I got stuck

Hi,
Thank you for your suggestions, I had committed some changes on top of what you suggested, so I had to edit it a bit. Please let me know if you have other changes.

Hi again,
Added some of your changes manually, as turned out to be rather difficult to rebase your commit with the current version. Thank you again.


raise exception on any non-zero exit code from subprocesses

This pull request causes most streamparse subprocesses to raise exceptions when they return nonzero exit codes. Combined with https://github.com/Parsely/fabric/pull/4, this causes streamparse-based topology deployments to exit when the virtualenv installation fails on one or more hosts.

@emmett9001 streamparse==4.1.2 is now published on PyPI!


store_in support for embed relations

Allow embedded relations to specify the name of the attribute they are persisted into.

Yup, that's a good idea. I suggest the stored_as or embedded_as option to be added to the embedded macro.


Menu animations work only on first time

Describe the bug
Hello. It seems that animation in Menu works only on first use.
Example code:
<Menu
    x:Name="MenuBar"
    Grid.Column="1"
    Margin="0,2.5,0,0"
    hc:MenuAttach.AnimationMode="Top2BottomWithFade"
    hc:MenuAttach.IsEnabledAnimation="True"
    Background="Transparent"
    FontFamily="Open Sans Medium"
    IsMainMenu="True">
    <MenuItem x:Name="File_MenuItem" Header="File">
        <MenuItem
            Header="File" />
</Menu>

Steps to reproduce the bug

Create Menu
Enable animations
Try it

Expected behavior
No response
Screenshots
No response
NuGet package version
HandyControls (Custom version) 3.4.0
IDE
Visual Studio 2022
Framework type
.Net 6.0
Windows version
Windows 11 (22000)
Additional context
No response

This is a bug of unofficial version.


Don't work GriefDefender

https://hastebin.com/fericokete.css
full logs

version 1.2.6

Jar wasn't built properly.


Added visibility in the different storage implementation

added visilibty in the different storage implementation
added UTs

fixed documentation for tryCall() method
fixed documentation in README exemple

Si tu veux continuer d'améliorer la lib, il faut push la branche V2. C'est celle-là qui est en prod, car la V1 avait un problème de concurrence (et on a changé quelques inferfaces en tre les deux).

If you have questions concerning the lib, feel free to contact me via email @MCoulombe727.
I worked a lot on the lib and @GuiSim can also help since he created it in the first place.
To modify the interface of the lib, you have to bump the major. Thats why we started the V2.
When you judge that the interface is stable enough (maybe in a month or something), please release it on maven central. Ask @pastjean for more information about that. Be careful if you release a preview version on coveo's internal maven server since the current preview version is used by many teams (not ideal I agree).

Can you at least give some justification as to why you're making this change? I can make an educated guess, but I find that reading a quick explanation from the author helps a lot in better reviewing the PR.

It lets you have distributed expirable metrics of the resource you want to limit the rate on. For more lengthy buckets where reading the current count won't be a performance issue (lets say you can perform an operation 10 times per hour per user on a given resource), it lets you give useful feedback to your user or use thresholds as triggers for proactive actions.

You did not merge ? @MCoulombe727

No I moved it to the V2 branch in another PR since we use the alpha-1 version in the platform.


Tree gets collapsed when you checkout

ext version: 1.7.1
Repro:

Checkout branch a
Checkout branch b

I'd prefer nothing to be collapsed but it certainly shouldn't collapse the PR being checked out. I'm guessing this is related to checking the text content of the tree.
Before:

After:

Duplicate of https://github.com/microsoft/vscode-pull-request-github/issues/238


Need to determine thresholds and algorithm for selection of docs for preference judging

Linh Nhi has code written for this, but Charlie says he wants to see pools.  Can we make sure the code is ready and parameterized correctly to accommodate Charlie?  Charlie and Linh Nhi should discuss.
Email background:
Hi Mahsa, Linh Nhi, Dake, and Amir,
We need to do some testing with the pref judging system to make sure it works as designed.
We need to see that we can go from qrels that Ian sends us, to loading a topic and docs, to collection of correct prefs, to output of collected data, to final qrels file.
You should construct a couple of testing scenarios that take us through the complete process and then do the testing to make sure the system works for the whole workflow.
@Charlie Clarke , we've decided to collect top-k prefs for correct docs.  What should we set k to?  I am concerned, based on looking at rankings produced by Dake and Amir, that we will have lots of results with near-duplicate content for many of the topics.  Assuming assessors find these to be "equal", how would a big equivalence class of docs be counted in our top-k?  What should k be?  I was thinking we'd like to know the top 10-20 prefs, but I'd want these to be in general, preference levels and not total docs, especially given near duplicate content.
@Charlie Clarke We also have decided that we want to only judge documents that are correct unless the number of such documents is below a threshold, and then we'll include "unclear" docs.  What is our threshold?  I don't think we'll ever meet this threshold for many of our topics this year.
Mark
Charlie wrote:
I would love to see pool sizes before we pick k. If I had to pick something without seeing them, I would pick k = 10. To pick the threshold, I'd also like to see the pools. If you want me to pick something in advance, I'd write a script that picks the threshold from the pools and the estimated available judgments available.
Note that we continue until we get a "tier" or "level" so that the total number of items is >= k. If that makes sense.

I have the code uploaded here:
The code still need some testing checks added as discussed today, but based on using the testing qrels and topics used for the trec2021 derived qrels before, it works as intended.
I am unsure what you mean by the pools? Did you mean the set of documents generated by the script that would be fed into judgo?


Billing metric update to zookeeper store

Implementation of org.apache.pulsar.broker.loadbalance.impl.ModularLoadManagerImpl#ModularLoadManagerImpl(org.apache.pulsar.broker.PulsarService)
which allows the extra metrics to be published on the /loadbalance/billing-data

What is the motivation of this change?


Microsoft Defender for Endpoint for Servers Licensing No Longer Available for Purchase

Under the section "Options for onboarding servers", one of the options listed is "Microsoft Defender for Endpoint for Servers".
Our CDW account manager and their internal Microsoft resource are saying that this license was discontinued by Microsoft in September 2022. If this is correct, it should be removed from the documentation.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ec57328d-4b17-abe6-001e-c5ecb2f00746
Version Independent ID: be98599a-b690-a3e6-c610-8da71fd80d76
Content: Compare Microsoft endpoint security plans
Content Source: microsoft-365/security/defender-endpoint/defender-endpoint-plan-1-2.md
Service: microsoft-365-security
Sub-service: mde
GitHub Login: @denisebmsft
Microsoft Alias: deniseb

Hello @hh-trj and thank you for the feedback. I've updated the article and the changes should be live later today. https://github.com/MicrosoftDocs/microsoft-365-docs-pr/pull/18848


Fix dynamic fee transactions display in Blockscout

Description
The PR sets gasPrice field for all the transactions, that are retrieved by the JSON RPC layer, because it is required by the Blockscout block explorer.
Changes include

[x] Bugfix (non-breaking change that solves an issue)
[ ] Hotfix (change that solves an urgent issue, and requires immediate attention)
[ ] New feature (non-breaking change that adds functionality)
[ ] Breaking change (change that is not backwards-compatible and/or changes current functionality)

Breaking changes
Please complete this section if any breaking changes have been made, otherwise delete it
Checklist

[ ] I have assigned this PR to myself
[ ] I have added at least 1 reviewer
[ ] I have added the relevant labels
[ ] I have updated the official documentation
[ ] I have added sufficient documentation in code

Testing

[ ] I have tested this code with the official test suite
[ ] I have tested this code manually

Manual tests
Please complete this section if you ran manual tests for this functionality, otherwise delete it
Documentation update
Please link the documentation update PR in this section if it's present, otherwise delete it
Additional comments
Please post additional comments in this section if you have them, otherwise delete it

Awesome! We tested it on our devnet, and now Blockscout can display dynamic fee transactions 👏🏻


Aurora crashing randomly

What are you experiencing an issue with?

[x] Aurora
[ ] Aurora supported game, (Fill in the game)
[ ] Aurora Wrapper
[ ] Aurora Profile
[ ] Aurora supported device, (Fill in problematic devices)
[ ] Aurora Scripts
[ ] Aurora Updater
[ ] Aurora Lighting issue
[ ] Other, (Fill in another issue here)

What kind of an issue is it?

[x] Crash
[ ] Performance problems
[ ] Visual bug
[ ] Localization issue
[ ] Enhancement suggestion
[ ] Device issue
[ ] Other, (Fill in another type of issue here)

Expected behavior:
Not crashing randomly.
Actual behavior:
Every so often when I have Aurora open for a random amount of minutes (completely random, sometimes 30 mins, sometimes 10) it pops up with a crash report, but the program keeps running perfectly fine until I hit ok, where it then freezes for a minute and proceeds to crash. The problem is that it opens up another crash report every couple of minutes. So I cant just leave it open cause my computer would slow down pretty badly. I only have a Steelseries Rival 110 connected in case that helps.
How often does this problem occur?
This problem occurs every time I have aurora open for a random amount of time.
Please describe the steps to reproduce this issue:
The issue can be reproduced by doing following steps:

Opening Aurora.
Leaving it open for 10 mins or so.

What is the version of Aurora you are experiencing this issue with?
My version is beta v0.6.1-dev4.
Does the previous version of Aurora have this issue?
Never used another version.
Please include any logs, screenshots, or files that are related to this issue:
I don't seem to have a logs folder but I have a snapshot of the crash report popup.
Snapshot:
https://imgur.com/a/ambRyqq

This issue has come up multiple times before, I thought it had been fixed in the dev branch (which you can get running through the bleeding edge builds in the readme) but according to #1129 it's not fully fixed, please look there


[nnbd] child != null "A null value was passed into a non-nullable parameter child" for AnimatedBuilder's

Have been running Flutter using NNBD for about a month now and never encountered any runtime null issues.
Master changes from today or yesterday have introduced this issue, which appears for almost every widget (I cannot further trace it, at least on Flutter Web it only shows framework traces):
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 213:49  throw_
dart-sdk/lib/_internal/js_dev_runtime/private/ddc_runtime/errors.dart 32:5    nullFailed
internal
packages/flutter/src/widgets/transitions.dart 1182:19                         build
packages/flutter/src/widgets/transitions.dart 181:48                          build

The AnimatedBuilders are set up normally:
AnimatedBuilder(
  animation: animation,
  builder: (context, child) {
    return Container();
  },
)

So this happens on latest master Flutter 1.20.0-8.0.pre.125. I am guessing that it was either of the two following commits that introduced this:

#61188 by @a14n
#61114 by @jonahwilliams

Before, running with --enable-experiment=non-nullable --no-sound-null-safety worked fine. Is there anything I need to do differently now?

perhaps we have a bug in some code that is using animated builder? @creativecreatorormaybenot could you attach a runnable example that repros this?

@jonahwilliams Well, it happens with any AnimatedBuilder.
I will try to be more detailed:
void main() {
  runApp(MaterialApp(
    home: AnimatedBuilder(
      animation: ValueNotifier(0),
      builder: (context, child) {
        return Container();
      },
    ),
  ));
}

This throws the error (flutter run -d chrome --enable-experiment=non-nullable --no-sound-null-safety):

Changing (context, child) to (context, Widget? child) fixes it. (Flutter 1.20.0-8.0.pre.125)

I would say it is not related to the foundation migration to null safety. Could you try with the previous commit : 0a64b5b2713ae50c36821da7f97a9262f127968b and see if the failure happen?

It may also be related to cb7770b3a52288d10fe6d5c78a7fa878dc39acce (the commit after 0a64b5b). It could be worth to test against this commit.

@a14n Checking out 0a64b5b fixes it. So I think it might be that Widget extends DiagnosticableTree and that is what you changed.
So Widget* does not work when the super type is a no-star type, rough guess.

@a14n Checking out 0a64b5b fixes it. So I think it might be that Widget extends DiagnosticableTree and that is what you changed.
So Widget* does not work when the super type is a no-star type, rough guess.

@a14n Still there with cb7770b, so the assert change creates the error. --no-null-assertions fixes it.

I do not see how to disable these null assertions. I guessed --no-null-assertions, however, that does not exist an an option 🤔

Thanks for your help. It doestn't seem possible to disable null assertions so you need to stay on 0a64b5b or revert locally cb7770b.

To be clear - we're not going to disable --null-assertions, or support disabling it. This is either a bug in our code or a bug in null assertions that needs to be fixed

I cannot reproduce this on the latest master. @creativecreatorormaybenot can you provide a complete example?

Oh, I see - you've opted into null safety?

The fix is
AnimatedBuilder(
  animation: animation,
  builder: (context, Widget? child) {
    return Container();
  },
)

The child parameter is inferred as Widget, which fails when the null opted out library passes a null value. This is a super weird edge case

@jonahwilliams Yes, I was aware of this the whole time. Was it not clear from what I wrote? 😶
But why do you close the issue - do you think this is a good way forward? There is no way to detect this issue before runtime; so I would call it a bug, at least somewhere. And also the inference is wrong, right?

@creativecreatorormaybenot this is a bug in your code. You are declaring a closure that must accept a non-nullable widget, and passing it to a place where a callback can provide you null.
this is an odd edge case, and you really should not be opting into null safety before flutter has migrated!. I cannot make that clear enough - you are going to constantly hit this edge cases because all of the migration logic and safe guards are designed around in order migration - that is non-null safe code depending on null-safe code, not the other way around.

@jonahwilliams Right, I see. You are saying that this issue will disappear when the framework code is migrated, right?
I have no problem with edge cases like this - I was just not sure that this was really expected behavior.

Yes, once the AnimatedBuilder is migrated, the closure would be declared as providing Widget?. The type inference in the closure would then be correct, and the assert wouldn't be tripped.


AC-340 use published version of zigzag

removes install of py-result-uploader directly from github
uses published version of zigzag (formerly py-result-uploader) from PyPI

Issue: AC-340

recheck_cit_xenial_no_artifacts_swift_deploy


No Home page button is availible to reurn to the previous page .

✨ I want to add a button ( arrow on top of navigation bar) to get return to the previous page
Add a Arrow button

No button is availible to go to home page

This is the issue i arrised :

Proposed Solution

Alternatives Considered

Additional Context

Are you participating in GSSoC?

[x] Yes
[ ] No

@Piyushsahu99 webssite in progresss that will be add while making pages . i think this issue should be hold for a while. thankyou


[Feat] RPCScan

AIM
An RPCScan
Features
A python tool to automate all the efforts that you put on finding the xmlrpc.php file on all of your targets subdomains and then finding the vulnerable methods and then finding the reports on hackerone and medium writeups.
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

/assign


Can't drag software Trio Enterprise to one of the FanzyZones

Microsoft PowerToys version
0.67.1
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
FancyZones
Steps to reproduce
Software Trio Enterprise can't be dragged to one of the FancyZones. Every other windows I have up can be dragged to the FancyZones but not Trio Enterprise. It have been working before in a older version of PowerToys, don't know which version.
✔ Expected Behavior
Expected to be able to drag Trio Enterprise to on of the FancyZones.
❌ Actual Behavior
Software Trio Enterprise can't be dragged to one of the FancyZones.
Other Software
Trio Enterprise. Version: TE <IP_ADDRESS>7.

Hi @Desinna, just to be sure, can you please confirm that PowerToys is running as administrator? This is the most common reason why the app is ignored by FancyZones. Also, these settings also could help in some cases. Please enable one of them (or both) to check if it helps to resolve the issue.
/needinfo

Thank you! I works now! :)


Add HAL withdrawal notification integration

Hello @matteoscurati could you edit the description and give a brief explanation of what you're doing here for everyone to see, please?

Sorry @ebirbe it wasn't to be merged now.
This will be closed and we open a new one with an explanation and the resolution of your comment.
Thanks 🙏


[native_assets_builder] Building form path package name fails with non-local depencies

I have written a library that I am importing into a larger project via git and the asset being built is using something like '-' when it should just be using the package name. I understand that this https://github.com/dart-lang/native/blob/be4aaf7b849a64d67756c95b6270b9bfe47f3c7d/pkgs/native_assets_builder/lib/src/build_runner/build_runner.dart#L473 works in tests since everything is local. Are native builds currently restricted to local directories? Is there a way to access the proper package name through BuildConfig's internal config?

Hi @j4qfrost!
I don't think I fully understand your question. Can you elaborate on your problem?
What do you mean with a non-local directory?
What you can do is do a git-checkout inside your build.dart script. The downside is that you'll do a new checkout for every target architecture.
(To aid with this, we could consider adding something like the path to <root-package>/.dart_tool/<your-package> so that things can be cached there. So if your package is "foo", and someone uses your package in bar "bar", you'd get access to the path "the/path/to/bar/.dart_tool/foo/", and you can cache the git checkout in there.)

Sorry for the ambiguity, I think you do understand my problem. I didn't provide my full process. So I am able to create the .so file successfully by doing something like this
/* If I don't use the last path segment then I get this error:
package:wireguard-linux-dart-882f1353c4531a2e4b5b25dcb06bcf465d82cf04`
declares the following assets which do not start with
`package:wireguard-linux-dart-882f1353c4531a2e4b5b25dcb06bcf465d82cf04/`:
package:wireguard_linux/native/native_wireguard_library.dart  */
  final packageName = buildConfig.packageRoot.pathSegments.lastWhere((e) => e.isNotEmpty);
  final cbuilder = CBuilder.library(
    name: packageName,
    assetId: 'package:$packageName/native/native_wireguard_library.dart',
    sources: [
      'src/wireguard.c',
    ],
    pic: Platform.isLinux,
  );

but because it is named using the last path segment instead of the package name, I don't think that the ffigen code is finding the .so file properly. A couple hours after posting I do have a possible workaround in mind. I'll hack it out and close the issue tonight hopefully.

Let me know what solution you come up with. 👍
This package is still under development, so maybe we can learn something from your approach that should be added to this package (or to the examples in this repo).

I think native_assets_builder should not assume that the directory that contains a package always ends in the name of the package.
I'm working on a package with the name libvips, but the repository is named dart_libvips so during development the directory containing the package ends in dart_libvips. Once installed from pub.dev the assumption native_assets_builder currently makes holds.
For example, I'm running in the following error, when running dart test:
`package:dart_libvips` declares the following assets which do not start with `package:dart_libvips/`: package:libvips/src/bindings.dart.
Error: Compiling native assets failed.

I think native_assets_builder should not assume that the directory that contains a package always ends in the name of the package.
I'm working on a package with the name libvips, but the repository is named dart_libvips so during development the directory containing the package ends in dart_libvips. Once installed from pub.dev the assumption native_assets_builder currently makes holds.
For example, I'm running in the following error, when running dart test:
`package:dart_libvips` declares the following assets which do not start with `package:dart_libvips/`: package:libvips/src/bindings.dart.
Error: Compiling native assets failed.

This is essentially the crux of the issue. The furthest I've gotten getting my project to work is manually changing the asset id in the output config after building the project. I've tried rewriting the config via the build.dart script for both the root and dependency but the change doesn't propagate up to the root project's .dart_tool/native_assets.yaml unless the build happens from cache.
I think the only way to get the proper package name is to read it from the package config. I'm not sure why path resolution is being used in the first place, I've never run into the situation where I'm building two different versions of the same dependency in the same project.

Thanks for reporting!
The native_assets_cli needs to have the package name in the BuildConfig. And then native_assets_builder needs to pass it in.
(The field needs to be required, and the package versions need to be bumped to 0.3. This will temporarily break the Dart SDK test on this repo. And this will require bumping the deps in the Flutter experiment.)


[GLUTEN-3695][VL] Support building 3rd-party libs on Arm64

What changes were proposed in this pull request?
In some scenarios, we need to build our own thirdparty-lib jar on Arm64 when spark.gluten.loadLibFromJar=true
How was this patch tested?
Build package:
./dev/package.sh
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_3807_time.csv
log/native_master_11_26_2023_f456a7e86_time.csv
difference
percentage

q1
33.09
34.38
1.288
103.89%

q2
25.40
24.62
-0.779
96.93%

q3
39.18
37.74
-1.432
96.34%

q4
37.98
36.67
-1.311
96.55%

q5
72.14
68.82
-3.320
95.40%

q6
7.19
7.12
-0.071
99.02%

q7
83.70
82.01
-1.685
97.99%

q8
87.42
87.72
0.308
100.35%

q9
124.66
120.79
-3.865
96.90%

q10
44.40
44.22
-0.185
99.58%

q11
21.63
19.96
-1.670
92.28%

q12
23.91
28.56
4.650
119.45%

q13
46.43
46.61
0.175
100.38%

q14
18.64
14.35
-4.290
76.98%

q15
29.24
29.15
-0.090
99.69%

q16
15.47
15.41
-0.065
99.58%

q17
104.91
100.98
-3.930
96.25%

q18
149.97
145.61
-4.364
97.09%

q19
13.06
12.88
-0.176
98.65%

q20
27.21
27.79
0.581
102.13%

q21
223.68
223.56
-0.120
99.95%

q22
13.81
13.03
-0.781
94.34%

total
1243.12
1221.98
-21.133
98.30%


Stop allowing invalid manifest lists which include blobs in their list in version 3.0.0

This issue exists to document the maintainers' vote or objections on making this change, please reply with your 👍 .
Since v2.3.0 (underlying bug existed since v2.1.1), distribution incorrectly allows OCI manifest lists and fat manifests to be uploaded which reference digests uploaded as blobs rather than only those uploaded as manifests. The buildx client has made use of this oversight to upload binary build caches as blobs and then reference them in an OCI manifest list. This works in distribution registries because of a workaround set to be removed in #3365, but some of those registries will still GC the blob.
We want to merge #3365 to fix a separate 500 error on a bad request where users try to get a manifest using the digest of a blob. It was discussed what to about this knowing about this buildx behaviour on the 6th July 2021 weekly call and we think that this should be included in v3.0.0. A distribution registry upgrading to this version will break the build pipelines of its users who:

are using a version of buildx which makes these invalid lists.
have chosen to keep their build cache.
have chosen to keep that build cache in a registry.
use a registry that allows it (is distribution and dosn't already GC the blobs).

We think targeting v3.0.0 is appropriate because:

It is a breaking change, so should not go in v2.7.2.
v3.0.0 ~will~should come with OCI artefact support, which would be the correct way for buildx to store the cache blobs.
v2 already has an alternative, but still not correct, method that buildx can use in the meantime to store these caches; link the blob in an OCI manifest.
Leaving the bug in distribution for longer than necessary invites other clients to follow the same invalid pattern. This is of particular concern given that buildx is a docker tool and could be seen as exemplary code.

v3.0.0 will come with OCI artefact support, which would be the correct way for buildx to store the cache blobs.

I think "will" is probably a bit strong here, https://github.com/opencontainers/artifacts/discussions/41 is still in discussion and I don't believe there's an issue/PR in this project for supporting this yet. I believe this should be our intent though.

I don't think thats a sufficient transition - just saying v3.0.0 will have OCI artefact support doesn't give all the users (not just buildx it seems) sufficient time to adapt to something that has worked for many years. Saying that "there are alternatives" doesn't give users time to write and test code, for users to upgrade and so on. It would also be good if OCI could clarify the spec.

It would also be good if OCI could clarify the spec.

This is something I would personally like to be strongly pushing for before any action is taken. This isn't the only "ambiguity" we have had to deal with when it comes to OCI spec.
Someone who got involved in this [and other] project(s) later than the spec had been discussed does not have the context of the original intentions and frankly, getting it by endless browsing of the [closed] issues and PRs solves nothing.
Getting the OCI spec clarified is the best step forward before we break more things for people than we fix.

I don't think thats a sufficient transition - just saying v3.0.0 will have OCI artefact support doesn't give all the users (not just buildx it seems) sufficient time to adapt to something that has worked for many years.

v3.0.0 should introduce breaking changes. I don't want to discourage adoption with dramatic changes by any means, but @joaodrp has done some investigation on support for this and out of DockerHub, ACR (Azure), GHCR (GitHub), ECR (Amazon), Artifactory, Quay, and GCR (Google), and GitLab, only DockerHub, ACR, and GHCR, and GitLab allow these cache images to be pushed. So these images are already something without broad support.

@brackendawson, thanks for creating this issue.
I want to share my opinion on a few things:

It's important to note that while it's currently possible to upload lists/indexes that reference blobs (things uploaded through the blobs endpoint and not the manifests endpoint) instead of manifests, this is not due to the intent behind the workaround to be reverted in https://github.com/distribution/distribution/pull/3365 but rather an unwanted side effect of that workaround (at least that's my perception). And this side effect went unnoticed until now;

Although OCI artifacts may be the ultimate answer to some of these more relaxed use cases, we shouldn't hold on to that to fix this link/validation bug. Besides the time to finalize the spec, it may take a long time for it to be adopted by most providers. Meanwhile, we should do the best we can with what we have (enforcing the Docker schema 2 and OCI Image specs) IMO;

If some clients can't cope with the current specs and validations because they are not a good fit for them, I think it would be better if they did not use the Docker and/or OCI manifest media types. Otherwise, they trick registries into thinking they are dealing with a given format when they're not;

We're referring to the buildkit cache images specifically, but there might be other use cases that we don't know. If we keep this behavior (link/validation bug) indefinitely, the problem will only worsen. Besides the technical challenges these may pose to providers, this affects the UX (different behaviors across different providers).

Regarding the buildkit/buildx issue, I've been having a long conversation about that in https://github.com/docker/buildx/issues/173, starting at https://github.com/docker/buildx/issues/173#issuecomment-873152302, so I won't extend myself too much on that.
I'd like to know if the backward compatible change that I proposed in https://github.com/docker/buildx/issues/173#issuecomment-873944787 is viable or not though. I'm approaching this in a constructive way, not pointing fingers or trying to blame anyone.

It would also be good if OCI could clarify the spec

With regard to what an OCI Image Index should contain within the manifests array, I think this is clear enough to mean that these should be manifests — it links to the OCI Image Manifest Specification when it says this and it doesn't mention other kinds of objects that could be included.
I think this is reasonably narrow, it shouldn't be necessary to enumerate everything you shouldn't put there. It doesn't restrict the mediatypes of those manifests, but that does not mean this array is open to all types of objects which could possibly be associated with a descriptor.

I voted 👎 since the goal of this implementation was always to be the superset of what is supported by OCI with stricter behavior gated by configuration. The supported types in OCI uses MUST support at least and unknown/unexpected should be gracefully handled. The returning 500 is a bug since it violates the principle of gracefully handling unknown/unexpected content, not because the content was accepted in the first place.

The supported types in OCI uses MUST support at least and unknown/unexpected should be gracefully handled.

The "unknown" vs. "unexpected" distinction is key here. "unexpected" does not appear in the current OCI Image Index spec. In regards to "unknown", I believe this is related to the following paragraph:

Image indexes concerned with portability SHOULD use one of the above media types. Future versions of the spec MAY use a different media type (i.e., a new versioned format). An encountered mediaType that is unknown to the implementation MUST be ignored.

So registries should not refuse index references with media types that they don't know. However, using the buildkit indexes as an example (that's the only one I know):
{
    "schemaVersion": 2,
    "mediaType": "application/vnd.oci.image.index.v1+json",
    "manifests": [
        {
            "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
            "digest": "sha256:136482bf81d1fa351b424ebb8c7e34d15f2c5ed3fc0b66b544b8312bda3d52d9",
            "size": 2427917,
            "annotations": {
                "buildkit/createdat": "2021-07-02T17:08:09.095229615Z",
                "containerd.io/uncompressed": "sha256:3461705ddf3646694bec0ac1cc70d5d39631ca2f4317b451c01d0f0fd0580c90"
            }
        },
        ...
        {
            "mediaType": "application/vnd.buildkit.cacheconfig.v0",
            "digest": "sha256:7aa23086ec6b7e0603a4dc72773ee13acf22cdd760613076ea53b1028d7a22d8",
            "size": 1654
        }
    ]
}

In this case, the manifests elements have a media type of application/vnd.oci.image.layer.v1.tar+gzip. This is not an unknown media type for OCI registries. It's well known, and it's used to describe an OCI layer, not a manifest.
So, the fact that we find these references within manifests is totally unexpected. But "unexpected" is not part of the spec (nor I think it should, cause providers want and need some level of predictability, and so do users if they want a consistent experience).
Nevertheless, reading the spec, we stop way before any mentions to "unknown" media types, on the first line, when it says:

The image index is a higher-level manifest which points to specific image manifests

So if an index references anything besides manifests, it's not compliant. We don't even need to get to the point where we look or not at media types.
In this case (buildkit), this is not about the OCI spec, though.  Before the OCI indexes were adopted, Docker manifest lists were being used, and their spec is even more strict:

The MIME type of the referenced object. This will generally be application/vnd.docker.distribution.manifest.v2+json, but it could also be application/vnd.docker.distribution.manifest.v1+json if the manifest list references a legacy schema-1 manifest.

So this was already a non-conformance issue before the OCI media types adoption.

What is the migration plan for clients with an immediate cutover on 3.0 (assuming artifact-spec gets approved and implemented)? Do clients need to support both and automatically detect which registry they are talking to? What about content in the registry that was already pushed as an OCI index? Will there be a migration plan for content between 2.x and 3.x registries? As a user I'd like to see a migration plan that doesn't break workflows during the migration.
Also my reading of the image-spec seems to be different from many of the distribution maintainers. I feel the OCI index entries with a media type that is not a known manifest should just be ignored. There seems to be a desire for the registry to do something with every entry in the index, which is counter to the image spec:

An encountered mediaType that is unknown to the implementation MUST be ignored.

Criticisms I've heard of my suggestion seem to fall into:

The mediaType is known. I'd suggest it's not a known manifest media type, so anything processing expecting a manifest should not be expected to handle that descriptor.
The blobs will get deleted by GC since they aren't referenced by a valid manifest. I see this as a problem for the client to deal with, and I say that as someone that works on client software. It's my responsibility to know what needs to be done to avoid having a blob get GC'd.

The knowledge that GC can and should happen on those blobs should be encouragement for many to avoid depending on this for their own "data storage in a registry" solutions. That should help prevent this behavior from sprawling to other registry client projects.

The blobs will get deleted by GC since they aren't referenced by a valid manifest. I see this as a problem for the client to deal with, and I say that as someone that works on client software. It's my responsibility to know what needs to be done to avoid having a blob get GC'd.

This strikes me as very strange. Allowing these OCI Image Indexes to be pushed up and returning a success status, then (possibly) deleting all of the referenced objects out from under it at some unknown point in the future, is really strange to me. Currently, the garbage collector doesn't delete unknown mediatypes, and I don't believe that we should update it to do so.

An encountered mediaType that is unknown to the implementation MUST be ignored.

application/vnd.oci.image.layer.v1.tar+gzip is a known mediatype, and it's reasonable to enforce the validity of OCI Image Indexes. We know this mediatype, we know the mediatype for OCI Image Indexes, and we know that mediatypes that indicate layers or config blobs should not be contained within the manifests array of an OCI Index according to the spec. Whether we do that via actually inspecting the mediatype is not relevant.
It's reasonable to expect a manifest list to be a list of manifests, and it's reasonable for us to enforce than moving forward with v3.0.0. We perform validation on manifest pushes, so there's clearly some intent in the design of distribution to reject manifests which are invalid.

What is the migration plan for clients with an immediate cutover on 3.0 (assuming artifact-spec gets approved and implemented)?

We'd need to determine all the breaking changes we're going to in 3.0.0 before we can really talk about migration plans. Personally, I think we need to deal with the existing manifests lists with layer references, regardless of whether we allow pushes of this nature in the future.

This strikes me as very strange. Allowing these OCI Image Indexes to be pushed up and returning a success status, then (possibly) deleting all of the referenced objects out from under it at some unknown point in the future, is really strange to me. Currently, the garbage collector doesn't delete unknown mediatypes, and I don't believe that we should update it to do so.

It's the same behavior that already exists today if we upload a blob and don't upload an associated manifest. The blob upload succeeds, but the GC can remove that blob in the future. It's my responsibility as a client to ensure that blob has a valid reference to avoid the GC. To me this is an expected behavior.
I also hesitate to use GC behavior as a leading reason to decide what to accept for push since GC doesn't run automatically in distribution/distribution. Without any GC, this ugly hack just works.

application/vnd.oci.image.layer.v1.tar+gzip is a known mediatype

It is, but it's not known to the tooling that is looking for manifests. My concern with enforcing validity on the mediaType field of an index entry is that we may be breaking future use cases in ways the spec described as a point of extensibility.
I'd also like to see this fixed with artifact-spec first, rather than focusing on blocking the existing use cases first. Otherwise we are saying "don't do that" without a better option of what should be done.

I'd also like to see this fixed with artifact-spec first, rather than focusing on blocking the existing use cases first. Otherwise we are saying "don't do that" without a better option of what should be done.

I don't think this is the case. Let's look at a few examples.
Helm
{
  "schemaVersion": 2,
  "manifests": [
    {
      "mediaType": "application/vnd.oci.image.manifest.v1+json",
      "digest": "sha256:31fb454efb3c69fafe53672598006790122269a1b3b458607dbe106aba7059ef",
      "size": 354,
      "annotations": {
        "org.opencontainers.image.ref.name": "localhost:5000/myrepo/mychart:2.7.0"
      }
    }
  ]
}

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.cncf.helm.config.v1+json",
    "digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111",
    "size": 117
  },
  "layers": [
    {
      "mediaType": "application/tar+gzip",
      "digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617",
      "size": 2487
    }
  ]
}

WASM
{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.wasm.config.v1+json",
    "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
    "size": 2
  },
  "layers": [
    {
      "mediaType": "application/vnd.wasm.content.layer.v1+wasm",
      "digest": "sha256:4c7915b4c1f9b0c13f962998e4199ceb00db39a4a7fa4554f40ae0bed83d9510",
      "size": 1624962
    }
  ]
}

Homebrew
{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "digest": "sha256:6324fea418ad479592ef3c21dafa2a6ffc3188d92426420f6257f5b32a7c0841",
    "size": 225
  },
  "layers": [
    {
      "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
      "digest": "sha256:4f6bf2e51a4952f4cc83760c1c732a5b0742ab693e977ae88df71f655b9dee7a",
      "size": 16236572,
      "annotations": {
        "org.opencontainers.image.title": "rclone--1.55.1.catalina.bottle.tar.gz"
      }
    }
  ],
  "annotations": {
    ...
  }
}

None of these are container images or had to wait for an artifacts spec, and none are using an index to aggregate non-manifest references. I think we'd really like to understand why others can't do the same and the technical reasons behind it.

None of these are container images or had to wait for an artifacts spec, and none are using an index to aggregate non-manifest references. I think we'd really like to understand why others can't do the same and the technical reasons behind it.

The examples there are all for a single layer. It sounds like the concerns from the buildx maintainers were that they would violate the manifest definition of layers with a multi-layer manifest:

The array MUST have the base layer at index 0. Subsequent layers MUST then follow in stack order (i.e. from layers[0] to layers[len(layers)-1]). The final filesystem layout MUST match the result of applying the layers to an empty directory.

I think sorting this one out will be best handled on the OCI side by clarifying the specs, and then distribution/distribution can follow the result. Today's OCI call discussed it, and it's included on their agenda for next week to give more people time to review the issue and attend. Some key discussion points were:

How do they define a "manifest" in the index definition? They don't want to link to a single example like the OCI image manifest. The definition should include a variety of possible manifest types and need to handle future compatibility. (This does not mean that every registry is expected to support every manifest media type.) For example, note the application/xml mediaType in the index example.
When using a descriptor, how does a client know when to use the manifest or the blob API paths to the registry? Is each client expected to maintain a list of valid media types for manifests and use blob APIs for everything else? This is the same question a registry faces when performing GC.
When words like "must be ignored" are used, is that a direction to clients/runtimes, the registry server, or both?

I raised an issue to discuss the Buildkit use case: https://github.com/moby/buildkit/issues/2251

I'm a 👍 to solve this in a more consistent way, such as (https://github.com/moby/buildkit/issues/2251). That said, those that run instances of this project shouldn't be blocked, so I'm torn in not wanting to suggest gitlab or others running distribution instances shouldn't find a way to meet their customers needs and driving a consistent solution.
In all fairness, ACR did enable buildx support, not because we agreed with the approach. Rather, our ACR Tasks BuildX support started breaking as the cache layers were being GCd and customers opened support tickets.
Had I realized the issue at the time, I would have engaged the buildx team to see how we could solve it then.
It just so happens our ACR eng team is super customer focused, so they just "fixed it" and it was a passive comment that I'm only now realizing the implication.

I'm a 👍 to solve this in a more consistent way, such as (https://github.com/moby/buildkit/issues/2251). That said, those that run instances of this project shouldn't be blocked, so I'm torn in not wanting to suggest gitlab or others running distribution instances shouldn't find a way to meet their customers needs and driving a consistent solution.
In all fairness, ACR did enable buildx support, not because we agreed with the approach. Rather, our ACR Tasks BuildX support started breaking as the cache layers were being GCd and customers opened support tickets.
Had I realized the issue at the time, I would have engaged the buildx team to see how we could solve it then.
It just so happens our ACR eng team is super customer focused, so they just "fixed it" and it was a passive comment that I'm only now realizing the implication.


Use interface to interact precompile instead of low call

https://github.com/darwinia-network/darwinia-bridge-sol/blob/1a9b67755e7f44f97a1c0545b59454a1b5f25f78/contracts/mapping-token/contracts/darwinia/Sub2SubMappingTokenFactory.sol#L63

right now we cannot fix this issue because the dvm does not support calling precompile contract by interface. see https://github.com/darwinia-network/darwinia-common/issues/916
and we add interface of the precompile contract to tell developers how to use it. https://github.com/darwinia-network/darwinia-bridge-sol/pull/88


Fix update method

Update method gets a callback that is called when the widget is ready. On order to prevent dom issues, we only need to call this callback when the map is loaded (so the dom element is already there).

Fixed in https://github.com/mendix/GoogleMapsWidget/commit/f759ea842650993fdbf741c9fa0d485e3e9213e3


Dynamic mode can't work

@YuvalAvra Y
IIUC, the dynamic mode should work even if the runc has fixed CVE-2019-5736.
However, It don't work in my Ubuntu 20.04 host.
What's your test environment? The test runc has fixed CVE-2019-5736?
Thanks

Hi @terenceli,
The dynamic mode only works for dynamically linked runtimes. You can run ldd <runtime> to check if it's dynamically linked.

@YuvalAvra
Yes, ldd /usr/sbin/runc shows as following:
root@ubuntu:/home/test/whoc# ldd /usr/sbin/runc
linux-vdso.so.1 (0x00007fff6f3a9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f58c8e50000)
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007f58c8dfd000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f58c8c0b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f58c8e86000)
So I think it should work in dynamic mode.

Hi @terenceli,
The dynamic mode only works for dynamically linked runtimes. You can run ldd <runtime> to check if it's dynamically linked.

Tested with ubuntu 20.04, works on my GCP VM.
Can you try using my whoc image instead?
First shell:
./util/fileserver.py

Second shell:
docker run --rm --net=host -it yuvalavra/whoc:latest <IP_ADDRESS>

If that doesn't work, can you share the output of the docker run command?

Tested with ubuntu 20.04, works on my GCP VM.

Useful information!

Can you try using my whoc image instead?

I totally uses the command in this repo.

First shell:
./util/fileserver.py

Second shell:
docker run --rm --net=host -it yuvalavra/whoc:latest <IP_ADDRESS>

If that doesn't work, can you share the output of the docker run command?

The same as yours.
I successfully run it in ubuntu 18.04 host.
My environment is Ubuntu 20.04.2 iso and install it locally.
I think there maybe do some tweak for poc.
Anyway, I will try to debug it more.
Thanks.

Got it, let me know if you find a bug. Could help to check whether the wait-for-exec mode works:
First shell:
./util/fileserver.py

Second shell:
docker run --rm --net=host --name whoc_test -it yuvalavra/whoc:waitforexec <IP_ADDRESS>

Third shell:
docker exec -it whoc_test /proc/self/exe

Hello @YuvalAvra
When in Ubuntu 20.04
I have following output.
root@ubuntu:/home/test/whoc/test# uname -a
Linux ubuntu 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:/home/test/whoc/test# docker run --rm -it --net=host whoc:latest <IP_ADDRESS>
root@ubuntu:/home/test/whoc/test# dmesg
[ 8229.345569] 19309 (entrypoint): Uhuuh, elf segment at<PHONE_NUMBER>400000 requested but the memory is mapped already

Maybe related with the musl-gcc or kernel? need more debug.
BYW: the wait-for-exec works as expected.
Thanks,

I have changed the 'upload_runtime.c' to build as a so(uses the 'gcc' instead of 'musl-gcc') and replace the '/lib/x86_64-linux-gnu/libseccomp.so.2'.
Finally it works.

Nice workaround!
I do want whoc to work with any runtime regardless of the libraries it uses, so I'll be looking into this bug in the future

Hi @terenceli, can you please check whether yuvalavra/whoc:ldfix works?

Hi @terenceli, can you please check whether yuvalavra/whoc:ldfix works?

@YuvalAvra
It works in my ubuntu 20.04 host!
What's the root cause?
Thanks

What's the root cause?

@terenceli

Up until now whoc's dynamic linker was an executable, and the kernel would map it on top of the process executable. I'm not actually 100% sure how this worked in retrospect, but it did.
This Linux commit introduced MAP_FIXED_NOREPLACE, which doesn't allow overlapping mapping in certain scenarios, one of them is an executable dynamic linker. This is the root cause for the issue.
The fix is to make whoc's dynamic linker a shared library. This introduced an issue with relocations - they were simply not happening. I believe that's because the dynamic linker is expected to handle it's own relocations.
To handle the relocation issue I decided to create a dedicated, minimal dynamic linker. It's compiled without libc and without a plt section, so no relocations are needed. It opens /proc/self/exe and then executes upload_runtime. upload_runtime can then read the runtime from /proc/self/fd/3/ and continue like before.

This new implementation is bulkier but less susceptible to issues from kernel changes. I'm sure there's an easier solution, but finding it is quite the rabbit hole. If anyone has more experience with linkers you're welcomed to have a go at this issue.

@terenceli can you verify the latest version works for you? It's at yuvalavra/whoc:latest

@terenceli can you verify the latest version works for you? It's at yuvalavra/whoc:latest

@YuvalAvra It also works!
Thanks


[Snyk] Upgrade @aws-sdk/client-sns from 3.623.0 to 3.624.0

Snyk has created this PR to upgrade @aws-sdk/client-sns from 3.623.0 to 3.624.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.

The recommended version was released on 23 days ago.

Release notes

Package name: @aws-sdk/client-sns

3.624.0 - 2024-08-053.624.0(2024-08-05)
Chores

id-auth-sra:  S3 Express compatibility with ID & Auth SRA (#6346) (253d329e)
codegen:  make hasEventStreamInput utilities public (#6351) (7bf2e59e)

Documentation Changes

client-pi:  Added a description for the Dimension db.sql.tokenized_id on the DimensionGroup data type page. (4078ba5a)

New Features

clients:  update client endpoints as of 2024-08-05 (7cd8b7cf)
client-datazone:  This releases Data Product feature. Data Products allow grouping data assets into cohesive, self-contained units for ease of publishing for data producers, and ease of finding and accessing for data consumers. (91b25612)
client-kinesis-video-webrtc-storage:  Add JoinStorageSessionAsViewer API (36c7cddb)
client-ecr:  Released two new APIs along with documentation updates. The GetAccountSetting API is used to view the current basic scan type version setting for your registry, while the PutAccountSetting API is used to update the basic scan type version for your registry. (6da42523)

Tests

karma-credential-loader:  set credential expiration as date (#6353) (80cb0547)

For list of updated packages, view updated-packages.md in assets-3.624.0.zip

3.623.0 - 2024-08-023.623.0(2024-08-02)
Chores

id-auth-sra:  sigv4a compatibility for id-auth sra (#6342) (9836a09e)
lib-dynamodb:  use pagination factory from core (#6345) (922292b6)

New Features

client-ivschat:  updates cloudtrail event source for SDKs (deeea907)
client-ecs:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (21bdf2a9)
client-cloudwatch:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (51a8423c)
client-glue:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (be78cf63)
client-route-53:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (39096d9a)
client-ivs-realtime:  updates cloudtrail event source for SDKs (6e9c35b3)
client-ssm:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (ae83e779)
client-kinesis:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (86c28e0e)
client-waf-regional:  Add v2 smoke tests and smithy smokeTests trait for SDK testing. (52b9cf43)
client-resiliencehub:  Customers are presented with the grouping recommendations and can determine if the recommendations are accurate and apply to their case. This feature simplifies onboarding by organizing resources into appropriate AppComponents. (b8d8c647)
client-ivs:  updates cloudtrail event source for SDKs (00374d58)

Bug Fixes

client-transcribe-streaming:  add plugin only for operations with streaming trait (#6349) (6043d799)

For list of updated packages, view updated-packages.md in assets-3.623.0.zip

    from @aws-sdk/client-sns GitHub release notes

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:

🧐 View latest project report
📜 Customise PR templates
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

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

Project coverage is 100.00%. Comparing base (b8e89e9) to head (afd5042).

Additional details and impacted files
@@            Coverage Diff            @@
##              main       #33   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           58        58
=========================================
  Hits            58        58

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


Create a table after drop, the colocate group information is not deleted

Steps to reproduce the behavior (Required)

CREATE TABLE t_1 (
id int(18),
value varchar(20)
)
ENGINE=OLAP
DUPLICATE KEY(id)
COMMENT "OLAP"
DISTRIBUTED BY HASH(id) BUCKETS 3
PROPERTIES (
"replication_num" = "1",
"storage_format" = "v2",
"colocate_with" = "group1"
);
DROP TABLE t_1;
CREATE TABLE t_1 (
id int(18),
value varchar(20)
)
ENGINE=OLAP
DUPLICATE KEY(id)
COMMENT "OLAP"
DISTRIBUTED BY HASH(id) BUCKETS 3
PROPERTIES (
"replication_num" = "1",
"storage_format" = "v2",
"colocate_with" = "group1"
);
SHOW PROC '/colocation_group';

Expected behavior (Required)
there is 1 tableID in group1
Real behavior (Required)
there are 2 tableIDs in group1
StarRocks version (Required)

You can get the StarRocks version by executing SQL select current_version()
2.0

@gengjun-git Can you handle it?


Create a dashboard to track contribution from community

Description
As we join the ASF, community growth become our highest priority, this is also true for every single project inside Apache Incubator. In order to support community growth, we need some kind of dashboard to help us monitoring  contribution from community
Describe the solution you'd like

Create a panel to show current month added_lines/deleted_lines/dev_eq for community contributors
Create a panel to show the monthly changes added_lines/deleted_lines/dev_eq for  community contributors

Has the Feature been Requested Before?
No

move to #1995


:bug: Remove sender attribute propagation from sequence

This was ill-conceived - see #71

Closes #71


Not compatible with utf8 script

Steps to reproduce
icm -sess xx utf8.ps1

Expected behavior
ok

Actual behavior
error

Environment data

linux ps7.1 to win 7.1

It recognizes the code as ascii,Errors with non-ascii characters will occur.

Close as stale issue without clean repro steps.

Close as stale issue without clean repro steps.


Google maps animation frame drops on iOS

Details
google maps is causing frame drop when the maps being animated on iOS but it's fine on android. However I don't have any iphone so I can't test it in profile mode.
here is my code to try https://github.com/watery-desert/car_rental_ronas_it

Target Platform:
iOS
Target OS version/browser:
iOS 14.5
Devices:
iOS Simulator

Logs

[✓] Flutter (Channel stable, 2.2.1, on macOS 11.2.3 20D91 darwin-x64, locale
en-GB)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.2)
[✓] VS Code (version 1.56.2)
[✓] Connected device (2 available)

here is the video link https://youtu.be/rX62rmLVlw0 I was trying to upload a video but I failed many times, sorry for the delay.

Hi @pavel-birdy
Thanks for filing the issue, I tried your project, it is failing to lunch, can you please provide a code sample to reproduce the issue without a provider or other third-party packages. I got physical devices, i can confirm the test for you
Thank you

@TahaTesser I don't know what's wrong that you failed to run the project I am using normal flutter widgets to animate. I didn't have many dependencies, anyway I removed FontAwesomeIcons and updated the repo. Make sure you have to add google maps api key.

Hi @pavel-birdy
I was getting an iOS deployment issue so deleted localKeys in your project, the problem went away
Tested on iOS and Android in debug and release modes
iOS
Debug
https://user-images.githubusercontent.com/48603081/121142666-e88fc680-c844-11eb-9c2f-16fd2a86f2ad.MP4
iOS
https://user-images.githubusercontent.com/48603081/121142691-f04f6b00-c844-11eb-9717-c71372e9d957.MP4
Android
Debug
https://user-images.githubusercontent.com/48603081/121142819-0a894900-c845-11eb-9d49-a9ee65fc024f.mp4
Release
https://user-images.githubusercontent.com/48603081/121142848-11b05700-c845-11eb-8ae3-a4d283a878e2.mp4
As you can on iOS, result, I don't see any frame drop (in your case, the issue might be with simulator rendering)
There seems to be different bug with sheet animation on Android, unrelated to Google maps

flutter doctor -v
[✓] Flutter (Channel stable, 2.2.1, on macOS 11.4 20F71 darwin-x64, locale
    en-GB)
    • Flutter version 2.2.1 at /Users/tahatesser/Code/flutter_stable
    • Framework revision 02c026b03c (12 days ago), 2021-05-27 12:24:44 -0700
    • Engine revision 0fdb562ac8
    • Dart version 2.13.1

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Volumes/Extreme/SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = /Volumes/Extreme/SDK
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Volumes/Extreme/Xcode-beta.app/Contents/Developer
    • Xcode 13.0, Build version 13A5154h
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] VS Code (version 1.56.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.23.0

[✓] Connected device (3 available)
    • IN2011 (mobile) • c9d8ee0c • android-arm64  • Android 11 (API 30)
    • macOS (desktop) • macos    • darwin-x64     • macOS 11.4 20F71 darwin-x64
    • Chrome (web)    • chrome   • web-javascript • Google Chrome 91.0.4472.77

• No issues found!

@TahaTesser thank you so much. Yes, it looks like the frame drop is only on the simulator. I appreciate your help. Now there is no issue.


Update dependabot.yml

I want to add the feature automatically merging dependency versioned a minor update.

@tani
As for the production dependency, why don't we make the patch version only auto-merge, since it will be auto-merged without noticing the new features of latex-utensils?

I see, the minor version update of latex-utensils means adding a few new node types.
I will update it. Thanks.

I got bad news. https://stackoverflow.com/questions/64116781/how-do-i-automerge-dependabot-updates-config-version-2
We cannot make auto-merging facilities with this.

Oh, my God……From the discussion, it may be doubtful that automerge of GitHub-native dependabot will be enabled in the future.
We have three options:

Use Renovate instead.

Renovate has auto-merge feature.

Make the update frequency once a month instead.

This will reduce our efforts. Once a week was too much for us.

Do nothing.

I thought 1 or 2 would be better. What do you think?

First, I consider continuing to use dependabot with https://github.com/fastify/github-action-merge-dependabot but it looks hard to deploy because of this post. I have no experience to use Renovate. It, however, is attractive. Could you do it?

I tried to install Renovate (GitHub App) to this repo, however, it does not appear in the integrations page of the settings page of this repo.
Why......
I also try to install renovate-approve (This is required to merge PRs automatically. It will approve PRs from Renovate), and it succeeded.

I'm not sure, but it seems to have worked.
https://github.com/textlint/textlint-plugin-latex2e/pull/129

Thanks. I also cannot see it at `integrations, but it looks working well.
There is no problem because we cannot see them even if dependabot.

Closed by #129


nz-select not clear after we clear form reset

Reproduction link
https://stackblitz.com/edit/nz700?file=src%2Fapp%2Fapp.component.html
Steps to reproduce

select "Item 1" from list
let check the "Result", it shows "1"
click "Reset" button
select same previous one "Item 1" again from list
let check the "Result", it show nothing
But if we choose other beside "Item 1", the "Result" shows correctly

What is expected?
I expect like the previous version (7.0.0-RC3), it works fine
What is actually happening?
It comes from latest version 7.0.0

Environment
Info

ng-zorro-antd
7.0.0

Browser
Latest Chrome

Hello admin,
Did you fix it already?
Thanks

@lkhuoch will be fixed in 7.0.1, the code has been submitted.


[RTD-9] Add base structure

Description

This PR propose the base structure of the microservice.
Spring Boot is used as framework.
List of Changes

base directory structure and files.

Motivation and Context

We needed a starting point for our applicative development.
How Has This Been Tested?

[ ] Unit Test Suite
[ ] Integration Test Suite
[ ] Api Tests
[ ] Load Tests

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Sounds fine, good work.


Consult how to realize Sim.

Thanks for your open source, your method is so elegant.I want try to recurrent it.
Follow your step, I have complete the job of install and compile.
Could you give me a more detailed way to sim this paper.
Thank you very much!

Now the problem looks like it's missing a environment variable.
root@lsy:/home/catkin_ws/src/upright/dsl__projects__tray_balance/upright_sim/src/upright_sim# python3 simulation.py --config ../../../upright_cmd/config/simulation.yaml
pybullet build time: Nov 28 2023 23:51:11
Traceback (most recent call last):
  File "simulation.py", line 7, in <module>
    from mobile_manipulation_central.simulation import BulletSimulation
  File "/home/catkin_ws/devel/lib/python3/dist-packages/mobile_manipulation_central/__init__.py", line 34, in <module>
    exec(__fh.read())
  File "<string>", line 45, in <module>
  File "/usr/lib/python3.8/os.py", line 675, in __getitem__
    raise KeyError(key) from None
KeyError: 'MOBILE_MANIPULATION_CENTRAL_BAG_DIR'

When I use command
home/catkin_ws/src/upright/dsl__projects__tray_balance/upright_cmd/scripts/simulations# python3 mpc_sim.py --config ../../../upright_cmd/config/playground/ur10_demo.yaml

it error like
FileNotFoundError: [Errno 2] No such file or directory: '/home/catkin_ws/src/upright/dsl__projects__tray_balance/upright_assets/thing/xacro/cartesian_base_joints.urdf.xacro'

I check zhe pr, the file seems do not exist.

Some of the instructions and files are outdated. Thanks for pointing this out! I will get back to you shortly with some updates.

When I use command
home/catkin_ws/src/upright/dsl__projects__tray_balance/upright_cmd/scripts/simulations# python3 mpc_sim.py --config ../../../upright_cmd/config/playground/ur10_demo.yaml

it error like
FileNotFoundError: [Errno 2] No such file or directory: '/home/catkin_ws/src/upright/dsl__projects__tray_balance/upright_assets/thing/xacro/cartesian_base_joints.urdf.xacro'

I check zhe pr, the file seems do not exist.

These missing file such as .xacro and .urdf  are located at  https://github.com/utiasDSL/mobile_manipulation_central.

Some of the instructions and files are outdated. Thanks for pointing this out! I will get back to you shortly with some updates.

Some of the instructions and files are outdated. Thanks for pointing this out! I will get back to you shortly with some updates.

Looking forward to seeing new instructions, especially those related to simulation!

I pushed a commit that cleans up the upright_cmd/config/playground/*_demo.yaml simulations, and also added a bit more information to the Simulation section of the README; I would suggest trying either thing_demo.yaml or ur10_demo.yaml. I am hoping to clean up this project a bit more substantially in the coming months (including better documentation), but this will take some time.

Thanks it did work! Looking forward to a more complete work！

Great, I'm glad it's working for you!

Could you please give us a docker for this repo


Fix #41 - Notify followers of the Requackers instead of author's

This PR fix #41 issue.

Thanks
Integrate in last version (scala/v2.2)


[BUG][NOWEB] - LABELS

Hi,
The tests were done from Swagger directly with version 2024.8.1
The labels store is with MongoDB.
I'm trying to use labels with the NOWEB API but the following happens:

In the api:
https://domain.com/api/9cb44700-591c-4054-b852-63e5bd0c7936/labels

In the first query it correctly showed me the labels of the account, but when editing the name of a label from the cell phone it is not updated when I consult the api again.

In the api:
https://domain.com/api/9cb44700-591c-4054-b852-63e5bd0c7936/labels/chats/123456789

In the first query it worked well for me but when editing the labels from the cell phone it does not show the query correctly and if I remove all the labels from the cell phone it shows me the labels from the first query.

In the api:
https://domain.com/api/9cb44700-591c-4054-b852-63e5bd0c7936/labels/chats/123456789

When I run the api it tells me that everything went well but it does not make any changes to the labels whether I consult from the api or from the cell phone directly.
Please help with these errors.

Hi!
Do you use the local folder to save data (-v .sessions:/app/.sessions) or MongoDB (-e WHATSAPP_SESSIONS_MONGO_URL=mongodb://user:password@host:port)?
I'll double check both anyway

The labels store is with MongoDB.

Nevermind, I see it, thank you for such detailed issue :+1:

@graficar Hi!
Just tested it with mongodb, worked fine for me.

Could you send us logs in<EMAIL_ADDRESS>when you're performing the steps:

Run the container
Run a new session with debug: True enabled (via dashboard or API)
Add a new label
API call to show all labels
Rename the label
API call to show all labels
Add a new label to contact
API call to show labels for contacts
Remove the label
API call to show labels for contacts

That would help us understand what is going on :pray:

Hi,
I just sent you an email with the subject header of this report.
What I did was enable the logs and when I updated the name of a label an error was displayed in the log:
[devlikeapro-whatsapp-http-api-pl] [2024-08-07 17:16:30]     error: "Error: tried remove, but no previous op\n    at Object.mix (/app/node_modules/@adiwajshing/baileys/lib/Utils/chat-utils.js:58:27)\n    at decodeSyncdMutations (/app/node_modules/@adiwajshing/baileys/lib/Utils/chat-utils.js:181:21)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async decodeSyncdPatch (/app/node_modules/@adiwajshing/baileys/lib/Utils/chat-utils.js:212:20)\n    at async decodePatches (/app/node_modules/@adiwajshing/baileys/lib/Utils/chat-utils.js:320:30)\n    at async /app/node_modules/@adiwajshing/baileys/lib/Socket/chats.js:401:70\n    at async Object.transaction (/app/node_modules/@adiwajshing/baileys/lib/Utils/auth-utils.js:136:26)\n    at async /app/node_modules/@adiwajshing/baileys/lib/Socket/chats.js:337:9\n    at async /app/node_modules/@adiwajshing/baileys/lib/Utils/event-buffer.js:105:36\n    at async processNotification (/app/node_modules/@adiwajshing/baileys/lib/Socket/messages-recv.js:350:21)"

hi! Could you attach the full logs in https://gist.github.com/ :pray: The email cut the long text :(

If you could find a time and give the full logs, it'd be really helpful! :pray:
labels working fine on both file and mongodb storage in our cases :(


Improve Security of site + EJS work + few QoL updates

*TLDR: *
Added a few response headers to improve csp, update package.json to include a bit more information, install express-ejs-layouts to massively reduce repeated code, added Wall of Fame to the widescreen navbar, added 2 JS files from https://hyprland.org which were not present in this repo
Long Explanation of changes

First thing I did was update package.json to include a few more details (the node version to run on, description, prevent accidental publishing to npmjs.com, OS it is meant to be run on, etc). I moved nodemon to dev dependencies as well.
Continuing on from the last change, I added a start and dev script where start was for production and dev was for running in development
I installed expressjs' compression package to add basic resource compression to the site. This commit also changes the 404 handler to match expressjs' guide (7bb0ca842b2cf6fb5162659ce84a6380ba9f2576)
I converted the index.js to index.mjs to utilize ES6 modules
Added response headers to the site. The most important part here is the Content Security Policy which will help mitigate some attacks should they happen. (This isn't too big of an issue but its good to have in case)  (218510d239b51b8719bb0f0fb2e6a7d909b06550)
I added express-ejs-layouts in order to reduce duplicated code. This included the creation layout.ejs and a components folder which held reusable pieces such as the head meta tags, footer, etc. Now pages like the 404 handler can be reduced to 7 lines. Adding any new pages will be much more simple and will not require much if any boilerplate. Refer to 9e82f56e413bc834d0ccdf6ccad9c6521534e526
I removed the swiperjs files from the 404 and rices page because they weren't being used. it is pretty simple to include by includeing the component in ejs.
A few quality of life updates such as making the urls relative (the hyprland logo linked to https://hyprland.org but now it links to /). I also added the Wall of Fame nav bar element which was already present in the mobile nav but not in the widescreen nav. Last change was to use github's nodejs gitignore template as it will cover most everything nodejs wise. I am not sure why package-lock.json was originally part of the gitignore but it should be committed to a repository if it exists. Additionally, the 404 page's button did not go to cursor: pointer; on hover, so I quickly added that.
In the current site, there are two JS files files which exist, smooth-view.js and play-vid-on-focus.js. However, currently in the folder, it does not exist. I simply copied these files from the website and added them here.

Obviously, I have no information on the server you are running this on but if there are any changes would would like me to make, let me know. Thanks again for developing and maintaining Hyprland :)

woops
SyntaxError: Cannot use import statement outside a module
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1031:15)
    at Module._compile (node:internal/modules/cjs/loader:1065:27)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at startApplication (/usr/local/lsws/fcgi-bin/lsnode.js:48:15)
    at Object.<anonymous> (/usr/local/lsws/fcgi-bin/lsnode.js:16:1)
/home/so248/hyprland.org/index.js:1
import express from "express";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1031:15)
    at Module._compile (node:internal/modules/cjs/loader:1065:27)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at startApplication (/usr/local/lsws/fcgi-bin/lsnode.js:48:15)
    at Object.<anonymous> (/usr/local/lsws/fcgi-bin/lsnode.js:16:1)
node:internal/modules/cjs/loader:979
    throw new ERR_REQUIRE_ESM(filename, true);
    ^

Error [ERR_REQUIRE_ESM]: require() of ES Module /home/so248/hyprland.org/index.mjs not supported.
Instead change the require of /home/so248/hyprland.org/index.mjs to a dynamic import() which is available in all CommonJS modules.
    at startApplication (/usr/local/lsws/fcgi-bin/lsnode.js:48:15)
    at Object.<anonymous> (/usr/local/lsws/fcgi-bin/lsnode.js:16:1) {
  code: 'ERR_REQUIRE_ESM'
}

I've reverted the changes to the website - but I am waiting for another PR of yours to fix this one