rpm: Update virtualization packages

What this PR does / why we need it:
Updates virtualization packages. Specifically:

libvirt 7.6.0-6 → 8.0.0-2
QEMU 6.0.0-33 → 6.2.0-5

The libvirt.org/go/libvirt Go package is also updated to match.
Release note:
This version of KubeVirt includes upgraded virtualization technology based on libvirt 8.0.0 and QEMU 6.2.0.
Each new release of libvirt and QEMU contains numerous improvements and bug fixes.

At least some of the failures look legit.
One is caused by netcat being missing from the image - libvirt used to drag this in, but it no longer does. We could add it back manually, but maybe the test case could be reworked so that doing that is not necessary? Perhaps there are other uses of netcat outside of the testsuite.
I'm unable to reproduce one of the failures locally because
S [SKIPPING] [6.113 seconds]
[rfe_id:393][crit:high][vendor:cnv-qe@redhat.com][level:system][sig-compute] VM Live Migration
tests/migration_test.go:97
  Starting a VirtualMachineInstance
  tests/migration_test.go:360
    live migration cancelation
    tests/migration_test.go:2208
      should be able to cancel a migration
      vendor/github.com/onsi/ginkgo/extensions/table/table.go:92
        [sig-storage][storage-req][test_id:2732] with RWX block disk and virtctl [It]
        vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:41

        Skip test when Block storage is not present

I'm unclear on what I need to do here, advice would be appreciated :)
I'll look into the whole thing more tomorrow.

@andreabolognani I'll have a try but generally if you succeed with the examples, then it is what we expect to work with the setup.

At least some of the failures look legit.
One is caused by netcat being missing from the image - libvirt used to drag this in, but it no longer does. We could add it back manually, but maybe the test case could be reworked so that doing that is not necessary? Perhaps there are other uses of netcat outside of the testsuite.
I'm unable to reproduce one of the failures locally because
S [SKIPPING] [6.113 seconds]
[rfe_id:393][crit:high][vendor:cnv-qe@redhat.com][level:system][sig-compute] VM Live Migration
tests/migration_test.go:97
  Starting a VirtualMachineInstance
  tests/migration_test.go:360
    live migration cancelation
    tests/migration_test.go:2208
      should be able to cancel a migration
      vendor/github.com/onsi/ginkgo/extensions/table/table.go:92
        [sig-storage][storage-req][test_id:2732] with RWX block disk and virtctl [It]
        vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:41

        Skip test when Block storage is not present

I'm unclear on what I need to do here, advice would be appreciated :)
I'll look into the whole thing more tomorrow.

You are missing the storage class that support block storage. In this case ceph, you need to set export KUBEVIRT_STORAGE="rook-ceph-default" before creating the cluster with make cluster-up then it is installed and you can check it with kubectl get sc

Some of the missing packages are:

e2fsprogs-*: this should be fine because we use the tool in the fixed appliance, so no need in the container
dhcp-*: we don't need any network as we are not operating on VMs but only on disks
dnf-*: this is fine because we don't need to install or fetch the dependencies
findutlis: I'll readd this
gdisk: this I'm not sure
genisoimage: this either I'm not sure
squashfs-tools: same as for e2fsprogs
supermin : this is fine as we use a fixed appliance

I'll try to find out in which cases libguestfs uses gdisk and genisoimage

You are missing the storage class that support block storage. In this case ceph, you need to set export KUBEVIRT_STORAGE="rook-ceph-default" before creating the cluster with make cluster-up then it is installed and you can check it with kubectl get sc

@alicefr thanks, I've tried this and it worked as expected. Did you find this documented anywhere, or is it tribal knowledge? Either way, I couldn't reproduce the failure locally so I'm going to assume it was a fluke until proven otherwise.

findutlis: I'll readd this
I'll try to find out in which cases libguestfs uses gdisk and genisoimage
they are listed in the package list for the appliance so I guess they are used there.

So you think that findutils, gdisk and genisoimage should all be added back to the guestfs image? If they're used by libguestfs at runtime even when working with a pre-generated appliance, isn't it a packaging bug that they're not dragged in explicitly? We should discuss this with Rich.
For the time being, I believe I have fixed one of the test failures. More to come next week :)

@andreabolognani I think we should only add findutils as standard tool but gdisk and genisoimage no. I don't think we have a good split for using a fixed appliance in centos 8.
About the env variable, yes I don't think that is documented :/. This script uses some of the variables in KubeVirt CI: https://github.com/kubevirt/kubevirt/blob/main/automation/test.sh

Shouldn't be an issue since a couple of tests are still failing, but just to be on the safe side
/hold

I'm still investigating the issue with booting the Alpine Linux 3.7 image using the RHEL 8.6 machine type, but in the meantime I've brought all images into the current decade :)
/hold cancel

Most of the failures are probably caused by the ongoing CI cluster upgrade, I assume.
@rmohr @vladikr can you please take a look? I think this should be ready to be merged now :)

Most of the failures are probably caused by the ongoing CI cluster upgrade, I assume.

Probably. It looks weird.
/retest

/lgtm
/approve
If CI is happy, I am :) Thanks @andreabolognani
One question: Since you are going through this procedure not the first time, what are the most rough edges where you would think that bazeldnf could support you more? I see for instance that there was a broken symlink added. Did you have to investigate that or would you expect that bazeldnf fails the build if the symlink specified is broken? Other things coming to your mind?

One question: Since you are going through this procedure not the first time, what are the most rough edges where you would think that bazeldnf could support you more? I see for instance that there was a broken symlink added. Did you have to investigate that or would you expect that bazeldnf fails the build if the symlink specified is broken? Other things coming to your mind?

The main points of friction for me are how long it takes for make rpm-deps to complete and how frequently I need to re-run it because of merge conflicts. I have a pretty beefy workstation and each run still takes several minutes, with the CPU cores being severely underutilized the entire time. More parallelism would probably help, but I can't see that happening without a significant rework of how bazeldnf works.
The broken symlinks, I noticed by pure chance. It would have been neat if bazeldnf could have figured that out on its own and reported it.
One thing that is not bazeldnf related but that took me way longer than I would have liked is figuring out the new values that I needed to use in Expect() calls. When the value you have in your test is not the one that's actually produced at runtime, you'll just get a timeout and produced output is not recorded anywhere AFAICT. The way I worked around this was to replace e.g.
[]expect.Batcher{
    &expect.BSnd{S: "echo $var"},
    &expect.BExp{R: console.RetValue("foo")},
}

with
[]expect.Batcher{
    &expect.BSnd{S: "echo $var"},
    &expect.BExp{R: console.PromptExpression},
    &expect.BSnd{S: "echo $var"},
    &expect.BExp{R: console.RetValue("foo")},
}

so that the last interaction would still time out, but in the meantime the first one would have succeeded and its output displayed by make functest. There's probably a better way to do it, but that's what I could come up with :)

The network test is still failing
09:13:29: $ ping kubevirt.io -c 1 -w 5 -s 1452
09:13:29: PING kubevirt.io (<IP_ADDRESS>): 1452 data bytes
09:13:29:
09:13:29: --- kubevirt.io ping statistics ---
09:13:29: 1 packets transmitted, 0 packets received, 100% packet loss

I have no idea what the problem could be. It works fine when I run it locally.

I have no idea what the problem could be. It works fine when I run it locally.

/hold
to stop automatic retesting.

The main points of friction for me are how long it takes for make rpm-deps to complete and how frequently I need to re-run it because of merge conflicts. I have a pretty beefy workstation and each run still takes several minutes, with the CPU cores being severely underutilized the entire time. More parallelism would probably help, but I can't see that happening without a significant rework of how bazeldnf works.

Hm, I could try downloading and reading the XML files in parallel. I think we wait more than 90% of the whole time just on reading the XML files because the built in XML parser is really slow, but I wanted to avoid the need to have XML parsing shared libraries. The more channels/repos we add, the more time passes just on reading the XML files. Will check it out.

I can reproduce at least some of the failures from pull-kubevirt-check-tests-for-flakes locally. Looking into them.

Hm, I could try downloading and reading the XML files in parallel. I think we wait more than 90% of the whole time just on reading the XML files because the built in XML parser is really slow, but I wanted to avoid the need to have XML parsing shared libraries. The more channels/repos we add, the more time passes just on reading the XML files. Will check it out.

Without having actually profiled the tool, I would assume that a limiting factor is that we do repeated invocations of the tool to produce each rpmtree, each with its overhead in terms of startup and data loading, and they're all serialized. To minimize execution time, ideally you'd be able to do something like (simplified)
bazeldnf fetch
bazeldnf rpmtree \
         --name libvirt-devel_x86_64 --arch x86_64 $libvirtdevel_x86_64 \
         --name libvirt-devel_aarch64 --arch aarch64 $libvirtdevel_aarch64 \
         --name launcherbase_x86_64--arch x86_64 $launcherbase_x86_64 \
         --name launcherbase_aarch64 --arch aarch64 $launcherbase_aarch64 \
         ...
bazeldnf prune

so that a lot of the computation can happen as part of a single invocation, with data loaded from disk only once and each rpmtree being calculated at the same time as the others across multiple cores. Even if you had to handle each arch separately, I think the result might still be quite a bit faster.
Another idea, which is actually orthogonal to this one, would be to preprocess the data as part of the fetch step and write to disk a more efficient representation, such as a JSON file that only contains the bare minimum needed for the next steps.

/retest
The network test still fails :(

The network test still fails :(

I think I see the issue: In the CI cluster we have a MTU of 1450.
I see that we try to send
ping kubevirt.io -c 1 -w 5 -s 1452

while we should probably send something like
ping kubevirt.io -c 1 -w 5 -s 1402

Since we anyway check if we can send full frames between VMIs (basically checking if inter-network config is correct), we can probably skip in the internet reach test the MTU check. We would always have to consider the cluster out-bound which is hard to know and I would prefer not setting it "manually".

Since we anyway check if we can send full frames between VMIs (basically checking if inter-network config is correct), we can probably skip in the internet reach test the MTU check. We would always have to consider the outer bound of the cluster which is hard to know and I would prefer not setting it "manually", since it does not really give additional test feedback.

Oh, while I think we should just skip this test, it is probably still worth finding out why we detected before this PR another MTU size ...
@qinqon any ideas?

@rmohr I'll openly admit that networking is far from my strongest suit and your explanation went almost completely above my head :) How do I translate it into a patch that fixes the CI issues? Feel free to just make the change yourself and add it to the PR if that's more convenient than guiding me through it :)

@rmohr I'll openly admit that networking is far from my strongest suit and your explanation went almost completely above my head :) How do I translate it into a patch that fixes the CI issues? Feel free to just make the change yourself and add it to the PR if that's more convenient than guiding me through it :)

I think the smallest possible change would be to simply skip this check at https://github.com/kubevirt/kubevirt/blob/main/tests/network/vmi_networking.go#L188 when vmiRef is nil (which seems to indicate the internet reach scenario).
I would also be open to move the internet reach test out of this table and remove all MTU detection traces from it.

I think the smallest possible change would be to simply skip this check at https://github.com/kubevirt/kubevirt/blob/main/tests/network/vmi_networking.go#L188 when vmiRef is nil (which seems to indicate the internet reach scenario).
I would also be open to move the internet reach test out of this table and remove all MTU detection traces from it.

@rmohr I went for the latter as it seemed cleaner. Hopefully I didn't mess that up too badly :)

@rmohr All tests passed now \o/ If the changes look good, can you please approve? Thanks!

Since we anyway check if we can send full frames between VMIs (basically checking if inter-network config is correct), we can probably skip in the internet reach test the MTU check. We would always have to consider the outer bound of the cluster which is hard to know and I would prefer not setting it "manually", since it does not really give additional test feedback.

Oh, while I think we should just skip this test, it is probably still worth finding out why we detected before this PR another MTU size ...
@qinqon any ideas?

@qinqon @AlonaKaplan @maiqueb could you quickly check what could be different here? I am pretty sure it is ok what we did to work around this, but I am not entirely sure why we seem to detect now different MTU sizes.

Since we anyway check if we can send full frames between VMIs (basically checking if inter-network config is correct), we can probably skip in the internet reach test the MTU check. We would always have to consider the outer bound of the cluster which is hard to know and I would prefer not setting it "manually", since it does not really give additional test feedback.

Oh, while I think we should just skip this test, it is probably still worth finding out why we detected before this PR another MTU size ...
@qinqon any ideas?

@qinqon @AlonaKaplan @maiqueb could you quickly check what could be different here? I am pretty sure it is ok what we did to work around this, but I am not entirely sure why we seem to detect now different MTU sizes.

I think the goal is to check that we correctly configure the MTU for all involved network elements - meaning that you can communicate e2e using different MTUs.
IMO, that makes sense in intra-cluster communication, where we own the network elements. IIUC, the issue was with reaching the internet - where we do not own the network segments - and as such cannot assume we can communicate with different MTUs. Thus, I am OK with your proposed fix @andreabolognani / @rmohr .

IMO, that makes sense in intra-cluster communication, where we own the network elements. IIUC, the issue was with reaching the internet - where we do not own the network segments - and as such cannot assume we can communicate with different MTUs. Thus, I am OK with your proposed fix @andreabolognani / @rmohr .

Thanks for the confirmation!

/unhold
/lgtm

/hold
It indeed makes sense to skip the MTU test when pinging the internet.
But if the reason for the failure is that the destination or some outer switch drops the packet, we should've see it before this PR. Upgrading libvirt/qemu doesn't effect the outer switch behaviour.
I think it worth spending some more time to investigate why upgrading the libvirt/qemu caused the test to start failing.

It indeed makes sense to skip the MTU test when pinging the internet.
But if the reason for the failure is that the destination or some outer switch drops the packet, we should've see it before this PR. Upgrading libvirt/qemu doesn't effect the outer switch behaviour.
I think it worth spending some more time to investigate why upgrading the libvirt/qemu caused the test to start failing.

Good point. I wonder what was discovered before this PR. Because the DIND interface in the CI clusters have 1450 MTU size and something must have changed, which leads to bigger frames in the kubevirtci cluster. It seems like it has to be in the cluster, otherwise the VM-to-VM communication would fail on the tests too ...

It indeed makes sense to skip the MTU test when pinging the internet.
But if the reason for the failure is that the destination or some outer switch drops the packet, we should've see it before this PR. Upgrading libvirt/qemu doesn't effect the outer switch behaviour.
I think it worth spending some more time to investigate why upgrading the libvirt/qemu caused the test to start failing.

Good point. I wonder what was discovered before this PR. Because the DIND interface in the CI clusters have 1450 MTU size and something must have changed, which leads to bigger frames in the kubevirtci cluster. It seems like it has to be in the cluster, otherwise the VM-to-VM communication would fail on the tests too ...

The ping doesn't have -M do, it means fragmentation is allowed. So theoretically, even if the destination MTU is lower that the packet size, the ping should succeed. But I think it depends on the switch, so maybe some outer switch drops the packet.
Maybe the change is that libvirt/qemu adds some extra overhead to the header. I will try to debug it tomorrow.

I will try to debug it tomorrow.

Thanks! :+1:

I will try to debug it tomorrow.

TIA @AlonaKaplan :)

I will try to debug it tomorrow.

@andreabolognani  @rmohr @maiqueb
We have 2 problems in our original tests -

Testing MTU without setting -M do on the ping is useless since fragmentation is allowed and ping to any packet size, even bigger than the allowed MTU, will work.
Testing MTU by pinging to external address is wrong since we don't control the MTU of the outside switches.

The reason the original test works (before this PR) -  is since -M do (prohibit fragmentation) wasn't set on the ping, so even though one of the hops in the way from the VM to kubevirt.io had smaller MTU than the packet size, the packet was fragmented and the ping succeeded.
The reason the test stopped working on this PR - cirros upgrade.
cirros doesn't support -M option, that's why the original test doesn't have it (and doesn't really test the MTU).
I guess the new cirros image has some bug/behaviour change I don't understand, that causes the fragmentation in our case not to be done (if the cirros image is switched to fedora, the test works even without the -M do).
Since it anyway doesn't make sense to test MTU with ping to the internet and the test has to forbid fragmentation, it is not very interesting to understand why fragmentation worked in the old image and stopped working in the new (the new image seems to support local fragmentation).
How I suggest to fix the PR -

Removing the MTU internet test is already done, and I think it is correct.
Use fedora image with -M do specified on the ping instead of cirros.
Test that pinging to packetSize +1 fails.

References to my tests-
Original code
This PR included
This PR includes but cirros update reverted

I've rebased the PR on top of main and picked up a more recent build of edk2 in the process.
@AlonaKaplan thank you for your analysis! What you describe mostly makes sense to me, although as I have mentioned before networking is very far from being my area of expertise O:-)
Since the changes that I have made to the networking tests as part of this PR are okay, do you think it would be possible to merge this as-is and make the other changes as part of a follow-up PR? I could try preparing such a follow-up PR based on your sample code, or you could polish up what you already have and submit it yourself - whatever works best for you.

/retest

Since the changes that I have made to the networking tests as part of this PR are okay, do you think it would be possible to merge this as-is and make the other changes as part of a follow-up PR? I could try preparing such a follow-up PR based on your sample code, or you could polish up what you already have and submit it yourself - whatever works best for you.

We can merge it as is. The network team will work on the follow-up.
/hold cancel

We can merge it as is. The network team will work on the follow-up.

@AlonaKaplan sounds awesome, thanks!
@rmohr can you please re-lgtm this?

Rebased to address a merge conflict.
@rmohr can you please re-lgtm? Thanks!

/lgtm
Thanks!

@andreabolognani sorry for asking you, but could you bump the RPM dependencies again? We did not yet mirror them and some of them are gone already.

/lgtm cancel

@andreabolognani sorry for asking you, but could you bump the RPM dependencies again? We did not yet mirror them and some of them are gone already (parts of the cluster have it still cached, therefore not all lanes are failing).

Weird, I ran make rpm-deps and it didn't generate any changes. To be fair, I haven't compile-tested the branch either because I assumed things were good based on that... Let me give it a closer look this time.

/retest

@andreabolognani let's see if it is temporary.

@rmohr I tried updating all packages again but it didn't pick up any additional changes.
When I tried deploying locally the first time around, I got a bunch of errors like
Error pushing image to localhost:49160/kubevirt/example-cloudinit-hook-sidecar:devel: unable to push image to localhost:49160/kubevirt/example-cloudinit-hook-sidecar:devel: Get "https://localhost:49160/v2/": tls: first record does not look like a TLS handshake; Get "http://localhost:49160/v2/": net/http: HTTP/1.x transport connection broken: malformed HTTP response "SSH-2.0-OpenSSH_8.0"

After I cleaned up everything and tried again, they went away and KubeVirt seems to be working fine based on a very quick test.
Hopefully the CI cluster is not affected by whatever local state shenanigans were happening on my machine :)

/lgtm
/retest
seems like the error went away :)

/test pull-kubevirt-e2e-k8s-1.22-ipv6-sig-network

Rebased on top of main and picked up a few CentOS Stream updates in the process.
I see that PRs have been merged as late as yesterday, so I'm hoping that the CI issues were either temporary or have been addressed separately since last week. I'd really like to get this in :)

/retest
Can be that we have to skip the failing test on ipv6. Will ensure that we have this finally ready today.

/retest

@andreabolognani, @AlonaKaplan  added a skip to the internet test if it is run on ipv6 only clusters.
Regarding vgpu and sriov, we still have issues which started over the weekend on them ... :/

/lgtm

/retest

added a skip to the internet test if it is run on ipv6 only clusters.

Thanks!

Regarding vgpu and sriov, we still have issues which started over the weekend on them ... :/

Fingers crossed then O:-)

@AlonaKaplan , can you please have a look?
The sig-network label was raised, I am not sure if anyone from the sig had a chance to see these changes.

/hold

@AlonaKaplan done. Thanks.

/lgtm

/test all

/retest

The ipv6 test is still not working since we don't have DHCP6 so the VM is not familiar with the DNS IP.
The test should be skipped if the cluster doesn't support IPv4.
Sorry for the noise.

The ipv6 test is still not working since we don't have DHCP6 so the VM is not familiar with the DNS IP.
The test should be skipped if the cluster doesn't support IPv4.
Sorry for the noise.

@AlonaKaplan does the diff below look reasonable to you? I'm preparing a rebase and I can just squash it in.
diff --git a/tests/network/vmi_networking.go b/tests/network/vmi_networking.go
index ebac17309..1b0f30e25 100644
--- a/tests/network/vmi_networking.go
+++ b/tests/network/vmi_networking.go
@@ -300,12 +300,13 @@ var _ = SIGDescribe("[rfe_id:694][crit:medium][vendor:cnv-qe@redhat.com][level:c

        Context("VirtualMachineInstance with default settings", func() {
                It("[test_id:1542]should be able to reach the internet", func() {
+                       libnet.SkipWhenClusterNotSupportIpv4(virtClient)
                        outboundVMI := libvmi.NewCirros(
                                libvmi.WithInterface(libvmi.InterfaceDeviceWithMasqueradeBinding()),
                                libvmi.WithNetwork(v1.DefaultPodNetwork()),
                        )
                        outboundVMI = runVMI(outboundVMI)
-                       Expect(libnet.WithIPv6(console.LoginToCirros)(outboundVMI)).To(Succeed())
+                       tests.WaitUntilVMIReady(outboundVMI, console.LoginToCirros)

                        By("checking the VirtualMachineInstance can fetch via HTTP")
                        err := console.SafeExpectBatch(outboundVMI, []expect.Batcher{

Yes. And the VM should have bridge binding as the original test had.
outboundVMI := libvmi.NewCirros()

Sorry again for my previous misleading request.

Sorry again for my previous misleading request.

No worries, thank you for looking into it and helping out :)

/lgtm

/test pull-kubevirt-e2e-kind-1.22-sriov


ops: add replication configuration

Add a replication configuration to keep a backup of modules in a
different (parameterized) AWS region. A lifecycle policy has been
set on the backup bucket so that objects transition to Glacier
over time to save on storage costs.
Fixes #90

@ry WDYT?


Fix race condition in RecordingHandler when there are concurrent requests

Without the added lock, the new test I added fails every time.

@nisha-bhatia I think this should fix the issue you are running into with the Monitor tests.


Add Tontine Trust Digital Pan-European Pensions

TontineTrust is using applied mathematics, behavioural science & a ruthless obsession with digitisation to disrupt the comatose jurassic era beast that calls itself the pensions industry.

Thanks!


404 error on ARM templates link

Under the components section, the following link fails (404): Azure Resource Manager templates

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

ID: 3bf4b377-2f24-8bcb-0e7a-a353564fb0cb
Version Independent ID: fd0164e3-7acf-8dca-ff63-44d8055919dc
Content: HPC cluster deployed in the cloud - Azure Solution Ideas
Content Source: docs/solution-ideas/articles/hpc-cluster.md
Service: architecture-center
Sub-service: solution-idea
GitHub Login: @adamboeglin
Microsoft Alias: pnp

Thanks for reporting - this issue is under review.  This is a Microsoft Internal DevOps Bug ID AB#241825


springdoc-openapi research and replace springfox if necessary

Although springfox upgrades slowly, it's still good enough to use.
No motivation to replace springfox by springdoc presently.

Currently, springfox is almost dead while springdoc is vital and upgrades frequently.
Considering turms is a long term project, we replace springfox by springdoc for a better maintainability.


missing phpmd.phar for 2.10.2 release

👋  it looks like for the most latest release, the phpmd.phar artifact is missing. Thanks!

Thanks @ kylekatarnls for the quick turn around. :)


Add support for newsletter

The API has the route /newstab.
Add news as a resource and make the Dsbmobile object able to fetch it

It looks like https://mobileapi.dsbcontrol.de/newstab isn't working right now

It seems like it is working with the wrapper, but just not with the Browser


android 6: SecurityException on parsing results (issue in how gson is used - GsonConverter needed)

at com.microsoft.windowsazure.mobileservices.table.serialization.JsonEntityParser.parseResults(JsonEntityParser.java:56)
See this discussion - https://github.com/google/gson/issues/648
This error will happen if a class that is being used for serialization extends some other base class (an ORM Entity, such as https://github.com/pardom/ActiveAndroid, for example).
Essentially, adding gsonBuilder.excludeFieldsWithModifiers(Modifier.FINAL, Modifier.TRANSIENT, Modifier.STATIC); in MobileServiceClient.createMobileServiceGsonBuilder() fixes the problem.
Perhaps, extend framework so that a developer can supply their own GsonBuilder?

Moving over to Mobile Apps repo as there is a workaround. https://github.com/Azure/azure-mobile-apps-android-client/issues/10


Estute/create make file

Description
TE-1768
Separate travis commands into a build script
Notes
I know this may seem a bit redundant, what with gradle and all, but in order to be able to run on both Jenkins and Travis, the set up and repo-specific gradle commands for the app must be CI-agnostic.
Testing

[ ] i18n
[ ] RTL
[ ] safecommit shows 0 violations
[ ] Unit, integration, acceptance tests as appropriate
[ ] Analytics
[ ] Performance
[ ] Database migrations are backwards-compatible

Reviewers
@BenjiLee
@jzoldak @benpatterson for OEP-8 compliance

Current coverage is 18.91% (diff: 100%)

Merging #878 into master will decrease coverage by 0.06%

@@             master       #878   diff @@
==========================================
  Files           470        470
  Lines         19969      19969
  Methods           0          0
  Messages          0          0
  Branches       2920       2920
==========================================
- Hits           3790       3778    -12
- Misses        15728      15742    +14
+ Partials        451        449     -2

Powered by Codecov. Last update d21f65e...2b59afb


Introduce config class

Codecov Report

Merging #11 (f583e4f) into main (2ba9b5f) will increase coverage by 0.37%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main      #11      +/-   ##
============================================
+ Coverage     86.19%   86.57%   +0.37%
+ Complexity      380      361      -19
============================================
  Files            20       22       +2
  Lines          1036     1035       -1
============================================
+ Hits            893      896       +3
+ Misses          143      139       -4

Impacted Files
Coverage Δ

src/Runner/Fixer.php
70.17% <ø> (ø)

src/Runner/Linter.php
57.57% <ø> (+2.50%)
:arrow_up:

src/Sniff/BlankEOFSniff.php
95.23% <ø> (ø)

src/Sniff/DelimiterSpacingSniff.php
100.00% <ø> (ø)

src/Sniff/EmptyLinesSniff.php
100.00% <ø> (ø)

src/Sniff/OperatorSpacingSniff.php
96.87% <ø> (ø)

src/Sniff/PunctuationSpacingSniff.php
100.00% <ø> (ø)

src/Command/TwigCsFixerCommand.php
100.00% <100.00%> (ø)

src/Config/Config.php
100.00% <100.00%> (ø)

src/Ruleset/Ruleset.php
75.00% <100.00%> (+2.27%)
:arrow_up:

... and 8 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 2ba9b5f...f583e4f. Read the comment docs.


Fix s390x Enum load/storeMultiPayloadValue

What's in this pull request?
In PR #2541, we made an endian change in Enum.cpp to load/store Enum payload tag and payload value.
The OpaqueValue that is being referenced in the bytes pointer requires a similar change.
This change is specific to big endian platforms only.
With this change, Interpreter/enum.swift test is now passing in s390x.  No new regression is observed.
Resolved bug number: (SR-)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    All supported platforms     | @swift-ci Please smoke test and merge
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    All supported platforms     | @swift-ci Please test and merge
    OS X platform               | @swift-ci Please test OS X platform
    OS X platform               | @swift-ci Please benchmark
    Linux platform              | @swift-ci Please test Linux platform

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

@swift-ci test

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 1a1a9ac26d713daf0bb17090e58cbf14bf8cf829
Test requested by - @tkremenek

Foundation's NSTimer test is a little too precise right now.
@swift-ci Please test Linux platform

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 1a1a9ac26d713daf0bb17090e58cbf14bf8cf829
Test requested by - @jrose-apple

@swift-ci Please test Linux platform


Export of backup isn't supported for tasks with data from a mounted share

Can't post to the "Discussions" section any more?
That would probably have been more appropriate for this issue / question:
When trying to Export or backup a project, the following error occurs;
Could not backup the project #xx
Error: Request failed with status code 500. "Exception: The task cannot be exported because it does not contain any raw data\n"
This error does not occur when exporting a TASK
What could this be?
This error is new since upgrading to 2.2.0 from 2.1 - we also tried the very latest build with same result.
Thanks

Hi @thomasm2film
The reason for that may be because in the project you have tasks that were created with the shared storage.

If so, for sure, it's a bug. Can you submit or refute the idea?

Any help would be much appreciated - let me know if I can supply further details (and what is needed from us).
Thanks

@thomasm2film
Let me explain.

Error: Request failed with status code 500. "Exception: The task cannot be exported because it does not contain any raw data\n"

The error occurs because you are trying to backup a project which has tasks created from a shared storage.
This is a bug. I believe CVAT should ignore such tasks and just show a notification about some tasks have not been kept.
CVAT does not back up tasks created from the shared storage if raw data was not copied to CVAT instance from the storage.
If you want to copy the data, you can click the corresponding checkbox when creating a task:

In this case you will be able to backup tasks which were created from the shared storage.
This is not a bug. The reason of such solution is that data on the shared storage, in general, can be updated when a user tries to make a backup. So, the raw task data may not exist anymore, they can be changed, etc. So, this is the feature restriction.
If not all of your tasks have been created from the shared storage, in this file cvat/apps/engine/backup.py
In class ProjectExporter, try to change this:
    def _write_tasks(self, zip_object):
        for idx, db_task in enumerate(self._db_project.tasks.all().order_by('id')):
            TaskExporter(db_task.id, self._version).export_to(zip_object, self.TASKNAME_TEMPLATE.format(idx))

By this:
    def _write_tasks(self, zip_object):
        for idx, db_task in enumerate(self._db_project.tasks.all().order_by('id')):
            try:
                TaskExporter(db_task.id, self._version).export_to(zip_object, self.TASKNAME_TEMPLATE.format(idx))
            except:
                pass

And rebuild the CVAT container with .dev.yml file. After that you will be able to backup the project.

@azhavoro
I am correct about the behaviour?

First of all server should not return 500 error in the case. Also probably it is better just try to create backups and generate 400 error in case of any problems.

Is this stil an issue?
@zhiltsov-max Why https://github.com/opencv/cvat/pull/5920 was closed?

@pktiuk, unfortunately, I had no opportunity to continue working on that PR. Yes, the issue is still actual.


getting the above error while i tried installing

./vcpkg install jansson
Computing installation plan...
A suitable version of cmake was not found (required v3.22.2). Downloading portable cmake v3.22.2...
Downloading cmake...
https://github.com/Kitware/CMake/releases/download/v3.22.2/cmake-3.22.2-linux-x86_64.tar.gz -> /home/abhinav/Downloads/vcpkg/downloads/cmake-3.22.2linux-x86_64.tar.gz
Extracting cmake...
The following packages will be built and installed:
jansson[core]:x64-linux -> 2.13.1#2
Detecting compiler hash for triplet x64-linux...
Error: while detecting compiler information:
The log content at /home/abhinav/Downloads/vcpkg/buildtrees/detect_compiler/stdout-x64-linux.log is:
-- Downloading https://github.com/ninja-build/ninja/releases/download/v1.10.2/ninja-linux.zip -> ninja-linux-1.10.2.zip...
-- Configuring x64-linux-rel
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:128 (message):
Command failed: /home/abhinav/Downloads/vcpkg/downloads/tools/cmake-3.22.2-linux/cmake-3.22.2-linux-x86_64/bin/cmake /home/abhinav/Downloads/vcpkg/scripts/detect_compiler -DCMAKE_MAKE_PROGRAM=/home/abhinav/Downloads/vcpkg/downloads/tools/ninja/1.10.2-linux/ninja -DCMAKE_SYSTEM_NAME=Linux -DBUILD_SHARED_LIBS=OFF -DVCPKG_CHAINLOAD_TOOLCHAIN_FILE=/home/abhinav/Downloads/vcpkg/scripts/toolchains/linux.cmake -DVCPKG_TARGET_TRIPLET=x64-linux -DVCPKG_SET_CHARSET_FLAG=ON -DVCPKG_PLATFORM_TOOLSET=external -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP=TRUE -DCMAKE_VERBOSE_MAKEFILE=ON -DVCPKG_APPLOCAL_DEPS=OFF -DCMAKE_TOOLCHAIN_FILE=/home/abhinav/Downloads/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=ON -DVCPKG_CXX_FLAGS= -DVCPKG_CXX_FLAGS_RELEASE= -DVCPKG_CXX_FLAGS_DEBUG= -DVCPKG_C_FLAGS= -DVCPKG_C_FLAGS_RELEASE= -DVCPKG_C_FLAGS_DEBUG= -DVCPKG_CRT_LINKAGE=dynamic -DVCPKG_LINKER_FLAGS= -DVCPKG_LINKER_FLAGS_RELEASE= -DVCPKG_LINKER_FLAGS_DEBUG= -DVCPKG_TARGET_ARCHITECTURE=x64 -DCMAKE_INSTALL_LIBDIR:STRING=lib -DCMAKE_INSTALL_BINDIR:STRING=bin -D_VCPKG_ROOT_DIR=/home/abhinav/Downloads/vcpkg -DZ_VCPKG_ROOT_DIR=/home/abhinav/Downloads/vcpkg -D_VCPKG_INSTALLED_DIR=/home/abhinav/Downloads/vcpkg/installed -DVCPKG_MANIFEST_INSTALL=OFF -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/home/abhinav/Downloads/vcpkg/packages/detect_compiler_x64-linux
Working Directory: /home/abhinav/Downloads/vcpkg/buildtrees/detect_compiler/x64-linux-rel
Error code: 1
See logs for more information:
/home/abhinav/Downloads/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-out.log
/home/abhinav/Downloads/vcpkg/buildtrees/detect_compiler/config-x64-linux-rel-err.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_configure_cmake.cmake:371 (vcpkg_execute_required_process)
scripts/detect_compiler/portfile.cmake:18 (vcpkg_configure_cmake)
scripts/ports.cmake:145 (include)
Error: vcpkg was unable to detect the active compiler's information. See above for the CMake failure output.

Please report vcpkg problems to them


Adding hands on exercises to keras.io Developer guides (and in future for Code Examples)

In general, a new developer getting introduced to keras, used the developer guides to get started with the library. It will be extremely helpful for new comers, if each guide included a hands on exercise section. It will allow the learner to apply the concepts he/she just learnt into an example scenario.
We have (as of now) 16 pages of guides. So adding exercises to each of the guides shouldn't be a difficult task. Later on, probably incrementally, exercises can be added for Code Examples section too.

@Samarendra109 ,
Thanks for the request.IMO this  may not add much value as we have Google Colab which is free to all will better serve this purpose.
Anyways Keras-team will review this request and will take a final call on this. Thanks!

We don't have any plan to support this for now.
Our aim is to help user community about the usage of Keras API with the guides, API usage and to start working on your use case with different APIs together, you can refer to any one of our published examples from different categories to choose from.


Add ktlint to gradle build

Test GitHub actions following a failing run when adding ktlint: https://github.com/partiql/partiql-isl-kotlin/actions/runs/1918543591
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hmm I didn't change anything from the failing build, but GitHub actions succeeded this time.


Add scala-steward to adopters

I feel the same about the projects I'm depending on in my work and for which scala-steward now helps with updates. :-)


[CI] cache sccache binary

Motivation
Cache sccache binary to trim another 1.5 minutes from total workflow time.
sccache size is increased to 4GB to accomodate the dev build which generates larger cache volumne.
The first workflow of the day will miss the cache.  The cache miss costs ~3 minutes due to installing the sccache binary and is absorbed in the first job, prefetch-crates.  The subsequent jobs in the workflow can avoid installing sccache.

Subsequent workflows will hit the cache and can enjoy the saving of sccache install time ~1.5 mintues. Plus extra saving due to increased sccache size.

Test Plan
CI

SG. One more iteration to put sccache in its own cache area.

@bors-libra r=metajack

:pushpin: Commit 75737c6 has been approved by metajack

@bors-libra r-

@bors-libra r=metajack

:pushpin: Commit 084df59 has been approved by metajack

:hourglass: Testing commit 084df593fddc84145e920f6201a991ee2469539e with merge 71bce2446134d75f55a010b770f234f6f2f4f53e...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: metajack
Pushing 71bce2446134d75f55a010b770f234f6f2f4f53e to master...


added explanation on targets

As discussed in issue #2876, the concept of deleting target objects was not quite clear.
In kong 0.11 the /upstreams//targets/active API gives a 'method not allowed'. So I removed it from the documentation too.

Thanks for the suggestion - I believe the intent is clearly aligned our needs here, and that the active endpoint needs to be taken care of differently :)

Oke, I have restored the /targets/active API documentation, and included the trailing /

Thank you!


Bump puma from 3.8.2 to 3.10.0

Bumps puma from 3.8.2 to 3.10.0.

Release notes
Changelog
Commits

Lots of bug fixes, and nothing breaking.  It's totally free, and the more repos it runs on the better its data on compatibility scores will be.

Seems reasonable, thanks for the PR!


Rename dagger-action to something less confusing

Problem
From the point of view of a Github Actions user, "dagger-action" makes perfect sense. But from the point of view of the Dagger community, it is confusing: is it a product called "action" by Dagger? Is it a way to perform an action in Dagger? Is it a clone of Github Actions by Dagger?
Solution
Find a less confusing name :) Easier said than done, I know. A few options below. Please share your opinions or other ideas. Better to measure twice and cut once.

Borrowing from Docker's edition model: dagger-for-github
Another variation on the edition model: dagger-on-github
Minimalist variatin: dagger-github
Same idea but more specific: dagger-gha

My preference right now is option 1: dagger-for-github. Simply because the format of "Docker for Mac", "Github for Mac" (fun fact: this is the inspiration for D4M :) is familiar to many developers.
WDYT?

cc @grouville @crazy-max

dagger-ghaction?

WDYT?

You're totally right. This action provides a way to use dagger in combination with GitHub.
I like the edition model: simple, known and to-the-point. Even though I agree that it sounds a little bit longer than: Docker for Mac (4 syllabus), the benefits far outweigh this little inconvenience
I checked and Vercel follows the same model, let's not reinvent the wheel:

Vercel for Github -> Dagger for Github
Vercel for Gitlab -> Dagger for Gitlab
Vercel for Bitbucket -> Dagger for Bitbucket
Any platform -> Dagger for xxx

dagger-ghaction?

It totally fits for this use case, but I'm having a hard time seing how we would port this model with Gitlab and Bitbucket terminology?

Let's go with dagger-for-github. I updated the top comment. What work needs to be done besides renaming the github repo? @grouville can you track this and let me know when we are clear to rename?
cc @aluzzardi who owns project infra.

After talking with @crazy-max, the renaming part needs to be done by him (more complex than it seems, need Github team interaction). You can assign this issue to him. I will take care of the DX redesign (issue #21)


[Bug] Receptors chart does not contain all the Fingerprint names

steps to reproduce:

Go to: https://interactive-viewer-next.apps-dev.hbp.eu/?templateSelected=MNI+152+ICBM+2009c+Nonlinear+Asymmetric&parcellationSelected=Cytoarchitectonic+Maps+-+v2.4&cRegionsSelected={"ICBM152_V24_RIGHT_NG"%3A"V"}&cNavigation=0.0.0.-W000..2_ZG29.-ASCS.2-8jM2._aAY3..BSR0..gzre.2Ac40~.byIw..1jtG
Expand regional features
Click on: Density measurements of different receptors for Area PFcm (IPL) [human, v1.0]
Scroll down and expand "Receptor density measurement"

expected behavior:
The diagram should contain all the Fingerprint text
actual behavior:
One of the fingerprints text is "Missing superscript or subscript argument"

fixed by https://github.com/FZJ-INM1-BDA/kg-dataset-previewer/commit/678793049801a179da5ed3e401e5d3d79ea4bd99
I will leave the issue open, as this is a data issue, and we need to coordinate with Lyuba (who updated the receptor data), to check if any errors still exist

can no longer reproduce
feel free to reopen if the issue persist


Add DeleteRG action in AzureResourceManagerTemplateDeploymentV3 in documentation.

Listed in this list of  actions in the AzureResourceManagerTemplateDeployment@3 it shows that the delete action is 'Delete Resource Group'.  In the article that is published, (public facing docs) it shows that the action is DeleteRG.  When trying to use the examples, it is unclear which action is used for deleting a resource group in a pipeline.
Public facing docs example
task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: 'Resource Group'
    azureResourceManagerConnection: '<your-resource-manager-connection>'
    subscriptionId: '<your-subscription-id>'
    action: 'DeleteRG'
    resourceGroupName: 'ARMPipelinesLAMP-rg'
    location: ''<your-closest-location>'

GitHub repository for azure-pipeline-tasks microsoft/azure-pipeline-tasks
Action*: If the deployment scope is 'Resource Group', select the action to be performed on the resource group. Following actions are available:

- Create or Update Resource Group: creates a new resource group or to update an existing one (using [Azure Resource Manager templates](https://azure.microsoft.com/en-in/documentation/articles/resource-group-template-deploy/)).
- Delete Resource Group
- Select Resource Group( not supported here - use Version 2.0 for this action ): reads the Resource Group information from Azure and creates an Output Variable with the VMs in the Resource Group
Start, Stop, Deallocate, Restart, Delete Virtual Machines( not supported here - use Version 2.0 for this action )

Looking at this it seems to be that the docs need to be updated to use DeleteRG as the action in that task.

https://github.com/microsoft/azure-pipelines-tasks/pull/15948

This is the PR that will fix this issue.
https://github.com/microsoft/azure-pipelines-tasks/pull/15948


nav bar links fixing

The links for contact and about from the nav bar arnt working. we can add the related information there , please kindly assign this issue to me under JWOC 2024

This issue has already been raised in issue no. #13 . If the assigned mentee does not fix the issue, it will be reassigned to others.

Everyone if you have not joined the Discord server yet, please do so, as I will be sharing instructions on the solve-it! channel under projects.
Link to the server:
https://discord.gg/bcgZ9RZZ8r

@Spandan-Bhattacharya Kindly assign this issue to me under JWoC'24

@thesri I am assigning the creation of the about and Contact pages to you.  In the about page, write about the project, and in the contact details, i will provide you the details.

okay please provide me the details @Spandan-Bhattacharya


Option to add prompt context to each label

This might be a 'future work'-thing. But might it be possible to have a version where I am able to add a sentence or two to each label? Something that allows me to explain what the label is supposed to mean? In all of my other prompting work I have noticed that this can really make a huge difference.

hi @koaning, a model for that should be released soon.

Hi @koaning, a new gliner version has been recently released. It should understand more detailled instruction. There is a demo on hugging face by @Ingvarstep : https://huggingface.co/spaces/knowledgator/GLiNER_HandyLab

you can load the model using the gliner library: knowledgator/gliner-multitask-large-v0.5


Automated Package Upgrade

:tada: This PR is included in version 4.0.45 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Automatically detect stacktrace prefixes

There is a common problem where an app is being built on multiple developers machines, and the stacktrace file names differ due to this, eg:

c:\users\james\myapp.cs
c:\users\simon\myapp.cs

Is there a way to automatically detect the stacktrace prefix for an app? If so that would be awesome.
Alternatively it would be great if we could allow regular expressions in SetFilePrefix.

Looks like TeamCity (and probably most build servers) will auto generate folders using a set pattern e.g. auto-generated build number in the file path. Having regular expressions allow us to cater to these types of builds
+1 regexs

It would be very useful, thanks

This is actually a dup of #8 so closing this one. This is going to form a part of our next .net sprint


fix: policy id shows as domain card description

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/48749
PROPOSAL: https://github.com/Expensify/App/issues/48749#issuecomment-2334988177
Tests

Test case 1 (Use the mock data)

To test this, without having any cards linked, put this useEffect in the WalletPage:

useEffect(() => {
        if (cardList[234523452345]) {
            return;
        }
        // eslint-disable-next-line rulesdir/prefer-actions-set-data
        Onyx.merge(`cardList`, {
<PHONE_NUMBER>341234: {
                key: '1234123412341234',
                cardID:<PHONE_NUMBER>341234,
                state: 3,
                bank: 'Expensify Card',
                availableSpend: 1000000,
                domainName: 'expensify-policy${policyID}.exfy',
                nameValuePairs: {
                    cardTitle: 'Amazon Card(title)',
                    limitType: 'smart',
                    isVirtual: false,
                },
                isVirtual: false,
                fraud: 'none',
                lastFourPAN: '1234',
            },
        });
    }, [cardList]);

Fill the ${policyID} by any existed policyID value.

Go to wallet page.
Verify that policy ID will not be displayed under the card's name for member.

Test case 2

As workspace Admin, go to Workspace settings > Expensify Card
Press Issue card
Issue a card to the member
As workspace member, go to Settings > Wallet

Verify that under Assigned cards section, the card description shows the workspace name

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

https://github.com/user-attachments/assets/0c8bff2c-e5c1-420b-83a1-38ae863adf0b

iOS: Native

https://github.com/user-attachments/assets/79a38355-ed04-4a96-bba3-c84072ee740c

iOS: mWeb Safari

https://github.com/user-attachments/assets/0ef647bd-1b10-43c3-80cb-d4433578422a

MacOS: Chrome / Safari

https://github.com/user-attachments/assets/30769385-79e5-4672-8cfe-65cafb910497

MacOS: Desktop

https://github.com/user-attachments/assets/29b26287-2e3d-4311-8871-96595f0f4db4

@dominictb can we get this in review today, please? Thanks!

Are we ready for a re-review?

@dominictb Please create a physical card instead of mock data
BUG: Your change works with the mock data but fails with the real data because the the letter in policyID is lowercase
https://github.com/user-attachments/assets/0e165d00-5d5e-4fa6-a230-6fbb829ca12d

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[ ] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[ ] I verified that all the inputs inside a form are aligned with each other.
[ ] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/MariaHCD in version: 9.0.34-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/luacmartins in version: 9.0.34-3 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


create sub wallet clients when creating the sub wallet

see: https://github.com/hyperledger-labs/acapy-java-client/issues/51
Signed-off-by: Philipp Etschel<EMAIL_ADDRESS>

@tdiesler based on https://github.com/hyperledger-labs/acapy-java-client/pull/40#issuecomment-1128870207 is this helpful?


Add 3 cards for the three levels

Need to add 3 cards for the three levels on the following screens:

Login
Upgrade
Restore

-Restore is not working so will test after it works.


Loyalty Cards Wont Show

I have 2 cards showing, but the rest wont.

Now resolved, thanks for your help!


how to add flag skip-kinds to kubeval in action

Hi, wondering if k8s-lint supports passing flags, like "skip-kinds" in the github action? Thanks

It doesn't currently support it but we'd welcome any PRs adding that functionality.


How to use constructor in .stories.js?

Proposal
I want to use constructor in .stories.js file like riot.tag method.
Like below.
return {
  tags: [{ content: SimpleTestRaw, boundAs: 'mustBeUniquePlease' }],
  template:
    '<SimpleTest test={ "with a parameter" } value={"value is mapped to riotValue"}></SimpleTest>',
  tagConstructor: function(opts) {
    // tag constructor here
  }
}

Who to contact
@libetl

Hello.

as a workaround what you can do is to use { compileNow } from @storybook/riot, then to mount it with your opts.
for example compileNow('etc...')
and then return {tagName: 'my-tag', opts: { }}
I will think about your proposal and try to find the good way.
Thank you.

In the meantime, I have a better workaround for you @SatoshiKawabata
Why don't you use tag & mount ?
https://storybooks-riot.netlify.com/?selectedKind=Story|How to create a story&selectedStory=built with tag&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Fstories%2Fstories-panel

@libetl  Thank you for your response.
I want to get this of riot tag in .stories.js. This way is also good so we've tried it already. Can you implement it in riot addon? Or can we create PR?

https://github.com/storybooks/storybook/pull/4258/commits


Provide a function to recursively put a directory with subdirectories to HDFS

Right now it is only possible to recursively delete a directory. It would be nice if hdfs3 came with a function out of the box that allows recursively pushing a directory to HDFS.
A naive implementation would be something like:
class cd(object):
    """Context manager for changing the current working directory"""
    def __init__(self, new_path):
        self.new_path = os.path.expanduser(new_path)

    def __enter__(self):
        self.old_path = os.getcwd()
        os.chdir(self.new_path)

    def __exit__(self, etype, value, traceback):
        os.chdir(self.old_path)

def put_dir(hdfs_client, origin_path, destination_path):
    """Recursively push a directory to HDFS

    Args:
        hdfs_client: hdfs client
        origin_path: origin path
        destination_path: destination path on HDFS
    """
    hdfs_client.mkdir(destination_path)
    with cd(origin_path):
        for root, dirs, files in os.walk('./'):
            dest_path = os.path.join(destination_path, root)
            for dir in dirs:
                hdfs_client.mkdir(os.path.join(dest_path, dir))
            for file in files:
                file_path = os.path.join(root, file)
                hdfs_client.put(file_path, os.path.join(dest_path, file))

But this is pretty slow in practice.

This seems like a thing we can certainly do.
I would use os.walk with the origin_path rather than changing the working directory, and I would make this a method on the HDFileSystem rather than a separate function. Would you care to make these changes and submit a PR, with tests? It would be nice to have the reverse method for fetching a set of directories to the local disc.
For further thought: the code would be essentially the same with s3fs or gcsfs, and could be implemented in parallel with dask to make a full distcp-like clone.

@martindurant The only problem is that it is really slow somehow compared to calling hdfs dfs -put mydir*, so I think it's not really a practical solution. For me it was only a short hack to see if it's worth the effort implementing it in hdfs3. Do you know why hdfs is so much faster? I guess they do something like concatenating all the files into one big chunk which reduces the overhead of many small files and lots of calls.

I am surprised that things should be slow for you. Have you set short-circuit operations as here?
Would you mind profiling your code to find out where the slowness is? Could it be that hdfs dfs is using multiple threads/processes (something we could in theory implement).


Relation inserted twice

Hi!
First of all I want to point out that you created a really nice npm package here!
I just have a problem with my fixtures when I try to reference a foreign key  with a fixture that has already been created:
const publicDic = fixture(DepositInsuranceCase, {
  name: 'XXXXX',
  createdAt: new Date(),
  createdBy<EMAIL_ADDRESS>});

const customer = fixture(Customer, {
    depositInsuranceCase: publicDic,
    accountOwner: null,
    phoneNumber: null,
    postCode: 'XXXX',
  });

Those two fixtures are used in my application.
First I create the publicDic with the install method. After that I want to create the Customer that should reference this publicDic. When I call install on the customer object it tries to create the publicDic a second time. How can I prevent this from happening?
Something that might be useful to know: The customer has a foreign Key that references one deposit insurance case. So it is a ManyToOne relation, seen from the customer's perspective.
Thank you and best regards,
Lukas

Hello @lukaswindisch and thanks for your time. At the same time, sorry for my quite late response.
First of all, seen from your code, is any of these fixtures exported? In the best case scenario, you export them all. This will also ensure that each fixture will be correctly "marked as persisted".
In general, the cli will just walk over every fixture and if it finds one that has not been persisted yet, it will run the query and use the resulting id for the relation. It's actually quite simple.
If the problems persists, I would love to have some reproduction code or repository. Some entities and a bundle would be totally fine, even in a single code snippet.


How to handle models generating multiple outputs

Hi,
Is there a way to manage multiple output models?
I am trying to implement this model indeed: https://colab.research.google.com/github/tensorflow/tensorflow/blob/master/tensorflow/lite/g3doc/models/modify/model_maker/audio_classification.ipynb
which is based on Yamnet model and generates 2 outputs: first one from Yamnet model, 2nd one from trained model.
Implementing flutter_tflite_audio only gives me access to first output (and by default ask for labels of 1rst model/output only)
Thank you
Fabrice

hi @tiofabby,
it seems several people  have requested for compatibility with Yamnets. I'll see if i can update the package when i have free time, and will let you know when that is done.

That would be great! Thank you @Caldarie


Property Lists get merged together on Website

In PR #329 a new property "exceptions" was added:
https://github.com/phpmd/phpmd/pull/329/files#diff-79d71ab57c2216abee5b7c50bb4c04f1
It get's merged with the other one, though, on the website:
https://phpmd.org/rules/unusedcode.html#unusedlocalvariable
Same for ShortVariables:
https://phpmd.org/rules/naming.html#shortvariable

I'm looking for the right way to display tables.
We should move on a markdown compiler.

I will probably need to customize the RST parser to handle properly them. But ti will conflicts with #624


ci: add backport.yaml to sync-files.yaml

PR Type

New Feature

Related Links

Description
The backport action is merged at https://github.com/autowarefoundation/autoware/pull/2856.
This PR add backport.yaml to sync-files action.
Review Procedure

Remarks

Pre-Review Checklist for the PR Author
PR Author should check the checkboxes below when creating the PR.

[x] Code follows coding guidelines
[x] Assign PR to reviewer

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[x] Commits are properly organized and messages are according to the guideline
[x] Code follows coding guidelines
[ ] (Optional) Unit tests have been written for new behavior
[x] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets
[ ] Write release notes

CI Checks

Build and test for PR: Required to pass before the merge.
Check spelling: NOT required to pass before the merge. It is up to the reviewer(s). See here if you want to add some words to the spell check dictionary.

@Mergifyio copy awf-latest


sys/poll.h ~> poll.h [POSIX]

Relying on POSIX <poll.h> instead of glibc-specific <sys/poll.h>.

Thanks!


refactor: Waiting for network connection when dns exception

What does this PR do?
fix: #1056
Motivation
默认<IP_ADDRESS>可能会把自定义的dns覆盖，有些地区<IP_ADDRESS>可能不通
Additional Notes

@WaterLemons2k 有空看下


Support mac address login via header field

00-B0-D0-63-C2-AA
X-MAC-Address header

@slavkof i'm not sure what needs to be done for this one, which endpoint is this for? the /api/sensor-events one?

instead of sending user token as the authentication header, you can pass device mac address as a value for X-MAC-Address header. Valid MAC address should be connected to the existing user of our platform.
If this is MAC address from your device (00-B0-D0-63-C2-AA), I see in the database that it is already connected to your user (staging env)

in-development under #32


Release artifacts for release v0.1.7

Description of changes:

release artifacts for release v0.1.7

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.

/lgtm


Remove branch name filter from run ci on PR

Codecov Report

Merging #15 (7828438) into main (9146bc4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #15   +/-   ##
=======================================
  Coverage   98.14%   98.14%
=======================================
  Files           2        2
  Lines          54       54
=======================================
  Hits           53       53
  Misses          1        1

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 9146bc4...7828438. Read the comment docs.


Define Outbound provisioning flows based on the application type

Describe the issue:
Outbound provisioning flows should work based on the application type.
- Tenant specific Applications -
Outbound configuration of the application should be used.
- SaaS Applications -
If the outbound configuration is enabled in the SaaS app, the same config is applicable for other tenants.
eg:

Assume App A a SaaS app created in Tenant carbon.super, and it has been configured for outbound provisioning
User management done via App A in carbon.super tenant will be provisioned to configured external systems
User management done via App A in in Tenant foo will be provisioned to configured external systems
Tenant foo admin can't manage(enable/disable) the outbound provisioning happening through App A

- System applications - (eg: console)
The outbound provisioning configurations of a system app can be overlayed by other tenants.
eg:

Console app  in Tenant carbon.super is considered as  a system app. it has been configured for outbound provisioning
User management done via console in carbon.super tenant will be provisioned to configured external systems based on the configs related to caron.super tenant's console app.
Admin in Tenant foo should be able to configure another set of external systems for outbound provisioning. (i.e outbound provisioning of a system app can be overlayed by other tenants)

Environment information (Please complete the following information; remove  any unnecessary fields) :

Product Version: IS 5.12.0-alpha 10

Consider the changes done in https://github.com/wso2/product-is/issues/12993 when we revise the flow

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


[RESOLVED] IDRAC_83 has been restarted (uptime < 10m)

Problem started at 18:36:27 on 2023.06.08
Problem name: IDRAC_83 has been restarted (uptime < 10m)
Host: IDRAC_83
Severity: Warning
Operational data: 00:04:00
Original problem ID: 23501
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23186&eventid=23501

Problem has been resolved in 6m 1s at 18:42:28 on 2023.06.08
Problem name: IDRAC_83 has been restarted (uptime < 10m)
Host: IDRAC_83
Severity: Warning
Original problem ID: 23501