PlayerNotificationManager pixelated image

Version
Media3 1.2.1
More version details
Followed the migration, but I still want to manually control for some use cases the PlayerNotificationManager manually.
Now, when I return a high quality image from PlayerNotificationManager
override fun getCurrentLargeIcon(
      player: Player,
      callback: PlayerNotificationManager.BitmapCallback,
 )

The image is pixelated like below.

The issue seems to be fixed if I set the artworkUri on the MediaItem, but sadly there is no functionality available where I can set the HTTPS Headers for that Uri therefore that approach doesnt work for me.
Devices that reproduce the issue
Samsung A52s 5G
Android 14
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Not tested
Reproduction steps
playerNotificationManager.setMediaSessionToken(mediaSession.sessionCompatToken)
playerNotificationManager.setPlayer(player)

return a high quality image from the overriden method
override fun getCurrentLargeIcon(
    player: Player,
    callback: PlayerNotificationManager.BitmapCallback,
): Bitmap? = highQualityImage

Expected result
The largeImage on notification should not be pixelated
Actual result
The largeImage is pixelated
Media

Bug Report

[ ] You will email the zip file produced by adb bugreport to<EMAIL_ADDRESS>after filing this issue.

The issue seems to be fixed if I set the artworkUri on the MediaItem, but sadly there
is no functionality available where I can set the HTTPS Headers for that Uri therefore that approach doesnt work for me.

I think you can implement your own BitmapLoader and set it when building the session.

The issue seems to be fixed if I set the artworkUri on the MediaItem, but sadly there
is no functionality available where I can set the HTTPS Headers for that Uri therefore that approach doesnt work for me.

I think you can implement your own BitmapLoader and set it when building the session.

@marcbaechinger thanks for your reply. This looks promising.
I will try to use this loader for now. I think it would be more flexible if we get the MediaItem itself on the callback instead of just the Uri. That way we dont have to do a lookup to find the headers for the received Uri

my issue was resolved after updating the version to 1.3.1 and using exoplayer.mediaMetaData.artworkUri to load image using glide.
`
override fun getCurrentLargeIcon(
player: Player,
callback: PlayerNotificationManager.BitmapCallback,
): Bitmap? {
Glide
.with(context)
.asBitmap()
.load(exoPlayer.mediaMetadata.artworkUri)
.format(DecodeFormat.PREFER_ARGB_8888)
.diskCacheStrategy(DiskCacheStrategy.ALL).override(
Target.SIZE_ORIGINAL, Target.SIZE_ORIGINAL
)
.into(
object : CustomTarget() {
override fun onResourceReady(
resource: Bitmap,
transition: Transition?,
) {
val compressedBitmap = compressBitmap(
resource, 100
)
callback.onBitmap(compressedBitmap)
}
                        override fun onLoadCleared(placeholder: Drawable?) = Unit
                    }
                )
            return null
        }

    private fun compressBitmap(bitmap: Bitmap, quality: Int): Bitmap {
    val stream = ByteArrayOutputStream()
    bitmap.compress(Bitmap.CompressFormat.JPEG, quality, stream)
    return BitmapFactory.decodeStream(ByteArrayInputStream(stream.toByteArray()))
}

`


move pulling omnisharp into another script so that it doesn't run whe…

…n just compiling

Hi @jrieken, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Johannes Rieken). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

:100:


Test Work Flow not working

Okay, we need to fix it

Ok

We need to clex

Hello
/deploy

/deploy


feat: trigger repository lookup on count update

Reduce the seek cycles to be triggered only when there's a repo count update

summary: repo's are cached in process memory, and this makes it so when the count changes we will get a refresh of that cache


Adding history-based scalar target alignment

Adds history-based (running mean) alignment function for scalar targets.  Added only to oracle ADM for now.

LGTM


Void tags like img are rendered with invalid closing tag

img is a void tag and is invalid and not supported in some contexts if it is rendered with a closing tag.
https://html.spec.whatwg.org/multipage/syntax.html#void-elements
This StackOverflow answer describes it a little bit more.
This W3C HTML validator, for example, gives an error with the following input:
<!DOCTYPE html>

	<meta charset="UTF-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge">
	<meta name="viewport" content="width=device-width, initial-scale=1.0">
	<title>Document</title>

Error: Stray end tag img.

If you remove the closing  (and optionally do a self-closing img tag), the error goes away.
I've been using this library for testing some output in my elm-markdown end-to-end tests and realized that a few test cases are failing because it isn't recognizing the HTML output as equal because of these void elements rendering with closing tags.

Alright, I narrowed down the issue a bit more and this package is rendering valid output. Sorry for the noise!
I confirmed that this library is giving correct output here and added a test case in case you'd like to include it for future reference: https://github.com/zwilias/elm-html-string/pull/13.

This may have something to do with nesting, because it does appear the output of Html.String.toString 0 does include closing void tags, like , in some cases. I pushed this workaround in my test runner, so it's not an issue for me:
https://github.com/dillonkearns/elm-markdown/commit/0174a83072ba94e566e27c40a2d7246c4fbcfe86
Just wanted to share for reference.


iosevka: 3.2.2 -> 3.7.1

Motivation for this change
Both packages were outdated and out of sync with one another.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Made some changes:

centralized version number and hashes in srcs.nix
filtered package.json to keep only name, version, and dependencies
added an update script

Updated to 3.7.0.
@ryantm what's the current procedure for updating node-packages.nix? I've removed the update from this PR but I'm guessing it'll break the ofborg CI run (as well as the automated update once I stop calling generate.sh from the update script).

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/call-for-nodepackages-maintainers/9176/28

The latest commits are a significant rework based on @doronbehar's suggestion, at the expense of keeping the packages unsynchronized as they are today.
iosevka-bin can be updated with genericUpdater, but it needs a src attribute pointing to itself for that to work, because of
https://github.com/NixOS/nixpkgs/blob/242441fea2a8981dccf5800288c7ca02a1c31cac/pkgs/common-updater/scripts/update-source-version#L82-L83
iosevka's update script now only needs to change a URL in node-packages.json, but that update isn't propagated to the iosevka package until node-packages.nix is regenerated.
Since the two packages are again separated, this may be better off as two separate PRs. I'm marking this up as a draft so it doesn't get merged until at least I've cleaned up the commits.

@doronbehar since #101132 took care of iosevka-bin, I removed the changes that dealt with it (but I moved its update script to make clear what package it is updating).
Should I drop the last commit (that updates node-packages.nix) even if it breaks iosevka on master in the meantime?

OK. It took me a while to grab my head around the changes. It looks good, although it's a bit of a mess. The problem is that many users are probably happy with iosevka-bin since it's easier to compile an override of it if one wishes only to get different / certain variants. Hence it's not suitable to discard the prebuild derivation for the sake of the source build derivation.
Unrelated, for iosevka, it's good to put it's deps in node-packages.json (as it used to be, only previously it was a manually downloaded package.json) so it will (hopefully) get updated frequently by the node packages maintainers (which we currently lack officially).
I was considering maybe suggesting to put the update script of the source build derivation in node-packages' ./generate.sh but that seems like too much to me, and inappropriate though I'm open to argue about it.
I have a few nitpicks left though (appropriate to put in separate commits in this PR):
diff --git i/pkgs/data/fonts/iosevka/bin.nix w/pkgs/data/fonts/iosevka/bin.nix
index c3b7767bccc..853c338e184 100644
--- i/pkgs/data/fonts/iosevka/bin.nix
+++ w/pkgs/data/fonts/iosevka/bin.nix
@@ -1,4 +1,4 @@
-{ stdenv, lib, fetchurl, unzip
+{ stdenv, lib, fetchurl, unzip, iosevka # Only for it's meta
 , variant ? ""
 }:

@@ -29,15 +29,7 @@ in stdenv.mkDerivation rec {
     unzip -d $out/share/fonts/truetype $src
   '';

-  meta = with lib; {
-    homepage = "https://be5invis.github.io/Iosevka/";
-    downloadPage = "https://github.com/be5invis/Iosevka/releases";
-    description = ''
-      Slender monospace sans-serif and slab-serif typeface inspired by Pragmata
-      Pro, M+ and PF DIN Mono, designed to be the ideal font for programming.
-    '';
-    license = licenses.ofl;
-    platforms = platforms.all;
+  meta = iosevka.meta // {
     maintainers = [ maintainers.cstrahan ];
   };

diff --git i/pkgs/data/fonts/iosevka/default.nix w/pkgs/data/fonts/iosevka/default.nix
index 9ef751688db..ef2df780e83 100644
--- i/pkgs/data/fonts/iosevka/default.nix
+++ w/pkgs/data/fonts/iosevka/default.nix
@@ -75,7 +75,7 @@ stdenv.mkDerivation rec {

   buildPhase = ''
     runHook preBuild
-    npm run build --no-update-notifier -- --jCmd=$NIX_BUILD_CORES ttf::$pname >/dev/null
+    npm run build --no-update-notifier -- --jCmd=$NIX_BUILD_CORES ttf::$pname
     runHook postBuild
   '';

Don't silence the output of npm run build - it's interesting IMO.
Don't repeat yourself (meta information).

Should I drop the last commit (that updates node-packages.nix) even if it breaks iosevka on master in the meantime?

No, we can't break it directly on master. If there was an upcoming nodePackages ./generate.sh update, it would have been appropriate to tell the updater to grab the commits from here and we'd close this PR.

Don't silence the output of npm run build - it's interesting IMO.

As far as I can tell there is no way to get a useful log without getting progress spam in the way, and any redirects just shut down all logging:
><EMAIL_ADDRESS>build /build/Iosevka-3.7.1
> verda -f verdafile.js "--jCmd=2" "--verbosity=6" "ttf::iosevka"
⢀⠀ ● Note Invalidating build journal due to self-tracking.
⡀⠀  | CPU:000% - RAM:000%⡀⠀ Complete 04 - Executing 2 - Pending 59 (06%) | CPU:000% - RAM:000%⠄⠀ Complete 004 - Executing 0 - Pending 110 (03%) | CPU:000% - RAM:000%⢂⠀ Complete 059 - Executing 2 - Pending 109 (34%) | CPU:000% - RAM:000%⡂⠀ Complete 062 - Executing 2 - Pending 161 (27%) | CPU:000% - RAM:000%⠅⠀ Complete 063 - Executing 0 - Pending 167 (27%) | CPU:000% - RAM:000%♦ node ./node_modules/patel/bin/patel-c --strict font-src/kits/boole-kit.ptl -o
⢃⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:000% - RAM:000%♦ node ./node_modules/patel/bin/patel-c --strict font-src/kits/spiro-kit.ptl -o
⢃⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:000% - RAM:000%⢃⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:000% - RAM:000%⡃⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:000% - RAM:000%⠍⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:000% - RAM:000%⢋⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:051% - RAM:053%⡋⠀ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:051% - RAM:054%⠍⠁ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:051% - RAM:054%⢋⠁ Complete 068 - Executing 2 - Pending 199 (25%) | CPU:051% - RAM:054%♦ node ./node_modules/patel/bin/patel-c --strict font-src/meta/aesthetics.ptl
^C

Even if I reduce verbosity, it'll keep saving the progress bar updates for printing later.
><EMAIL_ADDRESS>build /build/Iosevka-3.7.1
> verda -f verdafile.js "--jCmd=2" "--verbosity=5" "ttf::iosevka"

⢀⠀ ● Note Invalidating build journal due to self-tracking.

When that build finished, it produced 7200 lines of the following:

Sharing meta seems like it'll mess up with iosevka-bin's update script, as it locates the file to update with
https://github.com/NixOS/nixpkgs/blob/f28c4a120f5cacdad318782ccdd5b3599cea7e65/pkgs/data/fonts/iosevka/update.sh#L16
and what I get when doing meta = iosevka.meta // ... is
nix-repl> iosevka-bin.meta.position
"/home/aasg/nix/nixpkgs/iosevka/pkgs/data/fonts/iosevka/default.nix:98"

@deviant is there a problem if I replace that line with the following, or similar (I see you also write to variants.nix further down)?
file=$(dirname "${BASH_SOURCE[0]}")/bin.nix

Meanwhile, I removed otfcc from the dependencies, added myself as maintainer, and updated the nodePackages update.

Sharing meta seems like it'll mess up with iosevka-bin's update script, as it locates the file to update with
https://github.com/NixOS/nixpkgs/blob/f28c4a120f5cacdad318782ccdd5b3599cea7e65/pkgs/data/fonts/iosevka/update.sh#L16
@deviant is there a problem if I replace that line with the following, or similar (I see you also write to variants.nix further down)?
file=$(dirname "${BASH_SOURCE[0]}")/bin.nix

Not by me. I pretty much just copied that out of the common updater script. Perhaps it would be good to move iosevka-bin into a directory of its own, however? That way the file names can be more normal.

Perhaps it would be good to move iosevka-bin into a directory of its own, however? That way the file names can be more normal.

Possibly. The packages have little in common by now and we already do that with e.g. Firefox.

Sharing the meta should not be blocked by the design of the update script. You can put the version in a separate file and not use nix-instantiate or whatever it is.
@AluisioASG I'm sorry this got held up, but now we have a merge conflict...
If you could please change the update script to not rely on meta.position and use a safer way to increment the version, it'd be great.

As for the merge conflict, I don't know what to do. It's indeed frustrating. We need to coordinate runs of node's ./generate.sh... (cc @cideM).

We could also (after the version increment issue will be solved) kindly ask @cideM to grab the commits from here (and perhaps along this commit please :pray:) and then put them both in a separate PR and then run ./generate.sh.

I changed the update script, updating nodePackages now, should be done within the hour.

You'll note that the nerdfonts update script you mentioned does not actually cd into its directory.


More realistic animation with facebook/pop

How would it be possible to use https://github.com/facebook/pop to make the show/dismiss animation more realistic? (see in the Messenger app)

That's nice idea!! thank you ❤


New Cards/Update Help

How do I update YGOmaster to have access to the new Eternal Partners cards/packs (Yubel/Centur-Ion)
Please and thank you!

#130 please do not talk about update.

My fault i didn't know


Add support for semVerLevel query parameter to V2 endpoints

This PR is about adding support for the new semVerLevel query parameter on the V2, V2-curatedfeed and V2 AutoComplete endpoints, as per the design.
This PR changes V2 OData feed projections to always use normalized versions in navigation links.
It is a follow-up on https://github.com/NuGet/NuGetGallery/issues/3686 (filter SemVer2 package versions by default).

What are we deploying at the end of this sprint? This code, or this: #3686 (filter SemVer2 package versions by default).

@skofman1 we can combine both in the same deployment, as functionally they are the same currently: they'll return the same results until we unlock SemVer2 push support (and validation fixes).

@xavierdecoster , the scenario I'm concerned about is this:
We deployed SemVer 2.0 support and turned on  SemVer 2.0 package push. Suddenly ⚡ we discover a bug, and have to rollback. What should be the version we rollback to? It should be the version that filters out SemVer 2.0 by default. Meaning, no matter what parameters the client passes, the behavior is identical to the old Gallery, without SemVer 2.0 support.
That's why I think this PR shouldn't be merged to dev until #3686 is deployed.
So the deployments will be as following:

Deploy #3686
Deploy full SemVer support (including push)

and in case of an issue with (2), we just rollback using VIP swap, and back to safety.
Thoughts?

... no matter what parameters the client passes, the behavior is identical to the old Gallery, without SemVer 2.0 support.

That's exactly still the behavior of this PR as long as we didn't enable semver2 push support.
So, when discovering a bug after push, we can disable it again (feature toggle?) or rollback to this version, or the previous PR. Both should have the same outcome. Either way, I'm fine with a more granular, staged approach too :-)

@xavierdecoster I think the idea is, we want to be able to rollback to a state where a) semver2 packages can exist in the database and b) semver2 packages are not visible. The problem is, however, this PR still allows users to see semver2 packages--it just doesn't allow people to upload them. If we don't upload #3686 before this PR, we can't safely rollback before the deployment containing this PR because it has no knowledge of semver2 at all, which could put those semver2 packages in a bad state. A feature flag is another option but I think having another deployment is probably easier and more foolproof.


Swift does not respect required keyword

When reading a struct type, if a field is marked 'required' the reader should throw a protocol exception if a value for the field was not read.

+1
still presented

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

+1


(375) "Health needs" task: "Learning difficulties and neurodiversity" page

Trello 375

 Health subsection - Learning difficulties and Neurodiversity


scan QR code to find a new PFI

scan a Barcode, the url is the did, and display name is the name to add a new PFI.
QR code with content like this:
{
  "id": "exampleId123",
  "name": "Example PFI",
  "didUri": "did:example:123456789abcdefghi"
}

ok - have updated, but may need thoughts from @wesbillman as to why flutter hash and lastupdated versions are different (I am pretty sure I have the right version of flutter - it is from hermit). Maybe it is my xcode version? It certainly works both in simulator and on my actual iphone (I did have to rebuild things to get it to work on iphone - like the actual device I have it working on).


Feature Gate: Update to burn revoked feature lamports

Problem
As we get ready to migrate built-in (native) programs to BPF, we'll likely start with the Feature Gate program, a program that does not currently exist at Feature111111.... In this repository is the proposed new Feature Gate program with one single instruction: RevokePendingActivation.
This instruction is designed to defund the feature account of its lamports and send them to some designated destination. In order to add additional protection against spam, it may make more sense to instead burn these lamports.
Solution
If so desired, update the program to do so!
cc @joncinque - we should have some discussion on this beforehand, but I wanted to set a reminder here.

In order to add additional protection against spam, it may make more sense to instead burn these lamports.

I think I'm missing something, how does burning the lamports protect against spam?

In order to add additional protection against spam, it may make more sense to instead burn these lamports.

I think I'm missing something, how does burning the lamports protect against spam?

It's not a full solution but it at least helps disincentivize people from spam-creating feature accounts.

People can do that with all sorts of programs, like the stake program or spl-token. The solution is probably to create protocol-level fee for allocating accounts, but I would consider that out of scope for this issue.

People can do that with all sorts of programs, like the stake program or spl-token. The solution is probably to create protocol-level fee for allocating accounts, but I would consider that out of scope for this issue.

True, but there aren't limits per se to the number of stake accounts or spl-token accounts that can exist; there's no real malicious motivation for someone to create and then empty short-lived accounts (aside from using validator resources, etc). Whereas the feature process we are considering has a low hard limit to the number of features to be considered each epoch.
I do agree that requiring some higher deposit or fee is probably the way to go, but burning the lamports at least prevents someone from griefing us for free.

Ah right, sorry, I knew I was missing something! I read back through the proposal to refresh my memory, and it says activation is gated by a multisig: https://github.com/solana-foundation/solana-improvement-documents/pull/72/files#diff-b798a8c9dca99c07b780074b5abdc2c8d81722af0a57dcdde447fbe96bbc8ad1R88-R95, which means that the multisig would need grief the system, no?
And separately, what would happen if someone just created thousands of feature accounts and left them there?

I read back through the proposal to refresh my memory, and it says activation is gated by a multisig

Yeah, I added this after the bunch of us spoke offline, but I think that SIMD still needs another update and more discussion.

And separately, what would happen if someone just created thousands of feature accounts and left them there?

Garbage collection! IMO these should get cleared and lamports burnt on epoch rollover.


feat(pod-identity): add option for pod-identity

Description of your changes

add new spec.credentials.source PodIdentity
implemented a test environment based on: https://github.com/upbound/configuration-aws-eks here: https://github.com/haarchri/configuration-aws-eks-uxp-podidentity which added a UXP Release, Provider IAM Role, Pod Identity and a DeploymentRuntimeConfig https://github.com/haarchri/configuration-aws-eks-uxp-podidentity/blob/main/apis/pat/composition.yaml#L430-L526

Fixes #1249 #1254
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[x] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested
spin up a Network + EKS Cluster:
kubectl apply -f examples/pat/network-xr.yaml
kubectl apply -f examples/pat/eks-xr.yaml

connect to your EKS Cluster:
aws sso login --profile login
aws eks update-kubeconfig --region us-west-2 --name  configuration-aws-eks-v2lbr --profile AdministratorAccess-12345678910

apply the following resources:
kubectl apply -f examples/provider.yaml
kubectl apply -f examples/providerconfig.yaml
kubectl apply -f examples/vpc.yaml

kubectl get providerconfig.aws -o yaml
apiVersion: v1
items:
- apiVersion: aws.upbound.io/v1beta1
  kind: ProviderConfig
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"aws.upbound.io/v1beta1","kind":"ProviderConfig","metadata":{"annotations":{},"name":"default"},"spec":{"credentials":{"source":"PodIdentity"}}}
    creationTimestamp: "2024-08-13T15:07:56Z"
    finalizers:
    - in-use.crossplane.io
    generation: 1
    name: default
    resourceVersion: "11161"
    uid: e6eb0224-8300-4568-b617-68aa6ee35b82
  spec:
    credentials:
      source: PodIdentity
  status:
    users: 1
kind: List
metadata:
  resourceVersion: ""

kubectl get vpc -o yaml
apiVersion: v1
items:
- apiVersion: ec2.aws.upbound.io/v1beta1
  kind: VPC
  metadata:
    annotations:
      crossplane.io/external-create-pending: "2024-08-13T15:07:58Z"
      crossplane.io/external-create-succeeded: "2024-08-13T15:07:58Z"
      crossplane.io/external-name: vpc-0e424d8d4ab0015db
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"ec2.aws.upbound.io/v1beta1","kind":"VPC","metadata":{"annotations":{},"name":"vpc"},"spec":{"forProvider":{"cidrBlock":"<IP_ADDRESS>/16","region":"eu-west-1"}}}
    creationTimestamp: "2024-08-13T15:07:56Z"
    finalizers:
    - finalizer.managedresource.crossplane.io
    generation: 3
    name: vpc
    resourceVersion: "11202"
    uid: 08785497-5747-481a-b81d-9af709abf679
  spec:
    deletionPolicy: Delete
    forProvider:
      cidrBlock: <IP_ADDRESS>/16
      enableDnsSupport: true
      instanceTenancy: default
      region: eu-west-1
      tags:
        crossplane-kind: vpc.ec2.aws.upbound.io
        crossplane-name: vpc
        crossplane-providerconfig: default
    initProvider: {}
    managementPolicies:
    - '*'
    providerConfigRef:
      name: default
  status:
    atProvider:
      arn: arn:aws:ec2:eu-west-1:123456789101:vpc/vpc-0e424d8d4ab0015db
      assignGeneratedIpv6CidrBlock: false
      cidrBlock: <IP_ADDRESS>/16
      defaultNetworkAclId: acl-0b90aeb9eae7d1855
      defaultRouteTableId: rtb-0166e1e7e0903e59a
      defaultSecurityGroupId: sg-0408394cac0e658b6
      dhcpOptionsId: dopt-77034211
      enableDnsHostnames: false
      enableDnsSupport: true
      enableNetworkAddressUsageMetrics: false
      id: vpc-0e424d8d4ab0015db
      instanceTenancy: default
      ipv6AssociationId: ""
      ipv6CidrBlock: ""
      ipv6CidrBlockNetworkBorderGroup: ""
      ipv6IpamPoolId: ""
      ipv6NetmaskLength: 0
      mainRouteTableId: rtb-0166e1e7e0903e59a
      ownerId: "123456789101"
      tags:
        crossplane-kind: vpc.ec2.aws.upbound.io
        crossplane-name: vpc
        crossplane-providerconfig: default
      tagsAll:
        crossplane-kind: vpc.ec2.aws.upbound.io
        crossplane-name: vpc
        crossplane-providerconfig: default
    conditions:
    - lastTransitionTime: "2024-08-13T15:07:58Z"
      reason: ReconcileSuccess
      status: "True"
      type: Synced
    - lastTransitionTime: "2024-08-13T15:08:04Z"
      reason: Available
      status: "True"
      type: Ready
    - lastTransitionTime: "2024-08-13T15:08:00Z"
      reason: Success
      status: "True"
      type: LastAsyncOperation
kind: List
metadata:
  resourceVersion: ""

to use this you need some prerequisites which are implemented here: https://github.com/haarchri/configuration-aws-eks-uxp-podidentity
you need to run deploy an EKS AddOn like:
apiVersion: eks.aws.upbound.io/v1beta1
kind: Addon
spec:
  forProvider:
    addonName: eks-pod-identity-agent
    clusterNameSelector:
      matchControllerRef: true

prepare the IAM Role + PodIdentity:
apiVersion: iam.aws.upbound.io/v1beta1
kind: Role
metadata:
  labels:
    role: provider
spec:
  forProvider:
    forceDetachPolicies: true
    managedPolicyArns:
      - arn:aws:iam::aws:policy/AdministratorAccess
    assumeRolePolicy: |
      {
        "Version":"2012-10-17",
        "Statement":[
          {
            "Effect":"Allow",
            "Principal":{
              "Service":"pods.eks.amazonaws.com"
            },
            "Action":[
              "sts:AssumeRole",
              "sts:TagSession"
            ]
          }
        ]
      }

apiVersion: eks.aws.upbound.io/v1beta1
kind: PodIdentityAssociation
spec:
  forProvider:
    clusterNameSelector:
      matchControllerRef: true
    namespace: upbound-system
    serviceAccount: provider-aws
    roleArnSelector:
      matchLabels:
        role: provider

that the provider can use the PodIdentity feature you need a DeploymentRuntimeConfig like:
apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
  name: upbound-provider-aws
spec:
  serviceAccountTemplate:
    metadata:
      name: provider-aws
  deploymentTemplate: {}

when you install the providers you need to reference the DeploymentRuntimeConfig:
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-ec2
spec:
  package: index.docker.io/haarchri/provider-aws-ec2:v0.18.0-1847.g5ae95a12e
  skipDependencyResolution: true
  runtimeConfigRef:
    name: upbound-provider-aws

and then create simple a ProviderConfig:
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: PodIdentity

exchange the projected token for temporary IAM credentials, which are then made available to the pod.

does the projected volume (or some other directory) include the resulting temporary credentials? In other words, is the exchange is handled outside provider code?
or the exchange for a temp credential is done by the providerconfig code via the aws client?

If 1, I think we are good. If 2, that seems like the IRSA case where AWS injects a similar token for exchanging, and we do the exchange at each reconcile. In that case, we need to "cache the credentials cache" so that we do not lose them between reconciles.
If you have some setup already, it would be nice to check the contents of the projected volume and possibly check CloudTrail logs for AssumeRoleForPodIdentity  operations after triggering several manual reconciles.
Also realized some UX edge cases, IRSA and PodIdentity should be mutually exclusive. The code loads the default AWS client config for both IRSA and PodIdentity, which leaves the config resolution to the AWS code.

https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html
so what we get injected in the Container is the following:
...
AWS_CONTAINER_CREDENTIALS_FULL_URI=http://<IP_ADDRESS>/v1/credentials
AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE=/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
...

Kubernetes selects which node to run the pod on. Then, the Amazon EKS Pod Identity Agent on the node uses the AssumeRoleForPodIdentity action to retrieve temporary credentials from the EKS Auth API.
The EKS Pod Identity Agent makes these credentials available for the AWS SDKs that you run inside your containers.
means we calling in every loop the EKS Pod Identity Agent and the caching for Credentials happening in this agent - nothing need to take care in my point of view
the agent which is running inside EKS Cluster is located here: https://github.com/aws/eks-pod-identity-agent/


AgGrid issue with lazy loading of images in chrome 75

Your OS : Ubuntu 18.10
Node.js version : 11.10.1
Vuesax version : 3.8.75
Browser version : chrome 75
Which package manager did you use for the install? npm

Hello,
there is a issue when we enable the lazy loading feature of chrome 75 (in chrome://flags),
The checkboxes of the ag-grid are not displayed correctly on the demo page of the admin template. When selecting, the checkbox disappear. it seems that the background image is not loaded.
It's working correclty on ag-grid demo, so perhaps it's related to the customization done by the vuesax admin template.
thanks.

Hello,
This is github repo of vuesax framework. Please raise ticket at Template's support portal.
Support Portal
Note: Vuesax Admin Template is not created by creators of vuesax framework. Please close this issue and raise support ticket at their portal
~ Regards

Ok, honestly i will not. I report issues on github or i don't report them.


ValidationErrors are raised before Permission errors [Low Priority]

Hi,
So it seems like request data is validated before permission errors. Not a big deal.. mostly ran into it via automated testing, but I think it makes most sense to raise the permission error in a case where someone isn't allowed to do something.
A potential strange use case would be:

someone fills out a form for an action they aren't permitted to do
someone submits a form without required fields (like a text field)
only after do they correct the form errors, are they notified if they aren't permitted to do the action

If you're already checking this preeptively on the frontend, not really an issue...  but i'm sure it'll trip someone up :)

@bmwirth09 yes that true. Permissions are executed after Django Ninja has parsed the requested data. But I am thinking right now that permissions should be executed before request validation.
I will look into this and see if there is something blocking it from not happening

Awesome. Thanks so much for all your hard work @eadwinCode, django ninja extra is great and really sold me to use django ninja at all! :)

You are welcome @bmwirth09. I am glad the library is servicing it's purpose

@bmwirth09 I have looked at this and coupled with the ninja execution pattern, it is quite difficult to run the permission before route parameter validation.
The permission execution requires the instance of the controller created and to create the controller object we need to create the RequestContext which requires request parameters and to get that route parameters validation is executed

I see.
Would it be possible to run the permission checks even in the case of validation failure? And prioritize the permission errors?

Sorry for replying late... If the validation fails, the permission will not be executed because validation error will be raised

This issue has been resolved


Delicate Face Presets broken

Describe the bug
All of the Delicate face preset are various degrees of broken
To Reproduce
Steps to reproduce the behavior:

Start a new game
Change to female
Choose any of the delicate face presets

Expected behavior
A nice looking preset should appear
Screenshots

Modlist version
3.0

Check the change log for 3.1

Version 3.0 and 3.1 doesnt exist, removed in the next update


Support other databases for prod

It should be possible to use different databases, possibly mongodb as well

This is an interesting project.  What do you think about a mode where no edits in the tool were allowed & the tool was driven off of either a static config file or something similar?
I'm asking because I'm interested in exploring the use of a descriptor file in the deployment repo that describes many of the fields you are displaying and ideally a few more.  The idea is to put the data next to the IAC so that it can easily be updated by the teams who own the deployment.

This is an interesting project.  What do you think about a mode where no edits in the tool were allowed & the tool was driven off of either a static config file or something similar?
I'm asking because I'm interested in exploring the use of a descriptor file in the deployment repo that describes many of the fields you are displaying and ideally a few more.  The idea is to put the data next to the IAC so that it can easily be updated by the teams who own the deployment.

Hi @schmidtw, thanks for the idea. Yes, read-only mode based on roles is absolutely necessary and there is even ticket for this: #92
Initially I wanted to store all service descriptors inside git repo and use spring cloud config (https://cloud.spring.io/spring-cloud-config/reference/html/) to retrieve those descriptors. Then to the sake of speed I decided to use database instead.
You can grant permissions to this repo for particular people or teams so they can add / modify service descriptors and git will bring to us historical capabilities (e.g. who, when, why changed something)
The idea is to put the data next to the IAC so that it can easily be updated by the teams who own the deployment.
Do you want one descriptor per service in it's own git repo (e.g. parsing readme.md or service.descr) or what do you mean?

Hi @schmidtw, thanks for the idea. Yes, read-only mode based on roles is absolutely necessary and there is even ticket for this: #92
Initially I wanted to store all service descriptors inside git repo and use spring cloud config (https://cloud.spring.io/spring-cloud-config/reference/html/) to retrieve those descriptors. Then to the sake of speed I decided to use database instead.
You can grant permissions to this repo for particular people or teams so they can add / modify service descriptors and git will bring to us historical capabilities (e.g. who, when, why changed something)
The idea is to put the data next to the IAC so that it can easily be updated by the teams who own the deployment.
Do you want one descriptor per service in it's own git repo (e.g. parsing readme.md or service.descr) or what do you mean?

Makes sense.  I missed #92 as well.  You got to a pretty cool demo state pretty fast so I can appreciate adding things like this later.
On the descriptor per service topic, yes that was what I was thinking.  Instead of allowing any editing of the service descriptions/etc via this tool, those would be solely based on what is in a set of git repos.  I have lots of teams managing several different services & we're generally finding that if we can put all the information about that service in the one repo that covers deployment then it's easier to keep track of what's going on for the humans involved.  It also enables the potential for CI plugin that could do preflight checking/analysis (prevent circular dependencies for example).  microservice-catalog would help us view what's going on & also help with discover-ability & failure/outage modelling.
I think it is also reasonable to simplify & just have a single file & format that microservice-catalog uses (and reloads via a trigger or time). By having this interface defined it becomes easy to add a complementary scraping tool that deals with all the complexity of auth/locations/etc that are just friction & depends largely on internal infrastructure (Github vs. Gitlab is one example).  With one or two JSON schema we can separate concerns and enable other components to spring up & help while keeping core value in the catalog tool.

Makes sense.  I missed #92 as well.  You got to a pretty cool demo state pretty fast so I can appreciate adding things like this later.
On the descriptor per service topic, yes that was what I was thinking.  Instead of allowing any editing of the service descriptions/etc via this tool, those would be solely based on what is in a set of git repos.  I have lots of teams managing several different services & we're generally finding that if we can put all the information about that service in the one repo that covers deployment then it's easier to keep track of what's going on for the humans involved.  It also enables the potential for CI plugin that could do preflight checking/analysis (prevent circular dependencies for example).  microservice-catalog would help us view what's going on & also help with discover-ability & failure/outage modelling.
I think it is also reasonable to simplify & just have a single file & format that microservice-catalog uses (and reloads via a trigger or time). By having this interface defined it becomes easy to add a complementary scraping tool that deals with all the complexity of auth/locations/etc that are just friction & depends largely on internal infrastructure (Github vs. Gitlab is one example).  With one or two JSON schema we can separate concerns and enable other components to spring up & help while keeping core value in the catalog tool.

Great ideas @schmidtw makes absolutely sense. I'm now thinking what can be the best method downloading this descriptor from git repos without prior knowledge about these repos. I have currently giturl field for each microservice, but it is something user / admin must provide.
Let's say you have 10 services in 10 git repos. If there is no service available / preconfigured in catalog, then I don't have any clue where should I get / download descriptors.
Do you have any ideas?

Great ideas @schmidtw makes absolutely sense. I'm now thinking what can be the best method downloading this descriptor from git repos without prior knowledge about these repos. I have currently giturl field for each microservice, but it is something user / admin must provide.
Let's say you have 10 services in 10 git repos. If there is no service available / preconfigured in catalog, then I don't have any clue where should I get / download descriptors.
Do you have any ideas?

Good question.  I put a new issue in (#124) describing what I've been thinking about as a possibility.  I put it in a different issue so it might be easier to throw away in the event that you want to go a different route.  In that path, we'd configure the tool to basically not store or accept input from the user, but it would be a presentation and analysis engine that serves to connect documents, and the like together.  To me it seems very similar to being a DB import that just doesn't change & is refreshed.
On how to solve the aggregation problem - I think the answer will depend on how an organization operates.  For github based organization, there will likely be a scraper that either walks a list of know locations, or all locations and finds these files.  Possibly as a github app that are added to orgs.  I imagine Gitlab would be very similar.  If you are a gerrit shop, the answer may be a bit different.
I think the key to my proposal working is that these scrapers need to be pretty simple to lift/copy/produce since they will live in the "internal company magic" space & will often not be shared back out.
Another other reason I think it's worth trying to avoid making the scraper in microservice-catalog is a security safeguard.  If it can scrape all this data, if mistakes happens internally, this tool could become a super powerful way to spider into other systems.  Without the ability to access the other system repos this kind of concern goes way down.

Good question.  I put a new issue in (#124) describing what I've been thinking about as a possibility.  I put it in a different issue so it might be easier to throw away in the event that you want to go a different route.  In that path, we'd configure the tool to basically not store or accept input from the user, but it would be a presentation and analysis engine that serves to connect documents, and the like together.  To me it seems very similar to being a DB import that just doesn't change & is refreshed.
On how to solve the aggregation problem - I think the answer will depend on how an organization operates.  For github based organization, there will likely be a scraper that either walks a list of know locations, or all locations and finds these files.  Possibly as a github app that are added to orgs.  I imagine Gitlab would be very similar.  If you are a gerrit shop, the answer may be a bit different.
I think the key to my proposal working is that these scrapers need to be pretty simple to lift/copy/produce since they will live in the "internal company magic" space & will often not be shared back out.
Another other reason I think it's worth trying to avoid making the scraper in microservice-catalog is a security safeguard.  If it can scrape all this data, if mistakes happens internally, this tool could become a super powerful way to spider into other systems.  Without the ability to access the other system repos this kind of concern goes way down.

Agreed. Let scraper do the scraper work and and push the data into microservice-catalog.

Agreed. Let scraper do the scraper work and and push the data into microservice-catalog.


@conda-forge-admin,please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/pyadi-iio-feedstock#3.


Add rendering tests

Currently large parts of our rendering code lack tests. This PR aims to close these gaps by providing an infrastructure for rendering tests. The idea is that the canvas of a rendered map is compared with a reference image using Resemble.js.
For being able to run the tests for the canvas and WebGL renderer on Travis, SlimerJS is used instead of PhantomJS, that is used for the current unit tests.
Like with the current unit tests, the rendering tests can be run in a browser or from the command-line (./build.py test-rendering). If a test fails, that is a mismatch factor between the reference image and the rendered map exceeds a certain threshold, an image showing the difference can be displayed.

Still to do:

[x] Write more tests (for different layer types).
[ ] Make sure no window is opened when running the tests from the command line.

Closes #2923

This PR would now be ready to review. For sure, the new tests do no cover everything of our rendering logic, but it's a start.
There is one open issue that I wasn't able to resolve: When running the tests locally with ./build.py test-rendering, SlimerJS opens a window. It should be possible to run the tests headless with xvfb (like it is done on Travis). But I wasn't able to enable WebGL for xvfb on my machine. So for now you'll see the SlimerJS window when running the tests. I don't know if others consider this as a blocker?

Looks very good to me.

I don't consider it a blocker
Thanks for this great achievement.
Sent from my iPhone

On 4 apr. 2015, at 17:40, Tobias Sauerwein<EMAIL_ADDRESS>wrote:
This PR would now be ready to review. For sure, the new tests do no cover everything of our rendering logic, but it's a start.
There is one open issue that I wasn't able to resolve: When running the tests locally with ./build.py test-rendering, SlimerJS opens a window. It should be possible to run the tests headless with xvfb (like it is done on Travis). But I wasn't able to enable WebGL for xvfb on my machine. So for now you'll see the SlimerJS window when running the tests. I don't know if others consider this as a blocker?
—
Reply to this email directly or view it on GitHub.

I don't consider it a blocker

Yeah, me neither.

With me it's three :smile: I am very happy once this is in.
:+1: for merging

This is so cool.  Thanks for all the great work on this @tsauerwein.  One minor question/comment above, but I also think this looks good to merge.

Thanks for your feedback, merging.

coverage/coveralls — Coverage increased (+4.23%)

Gold star for @tsauerwein!

wow we are now at 72% should we increase our threshold to 70% already ;-) ?

I wonder why adding rendering tests increased the code coverage. Can someone please explain?

Looking at https://coveralls.io/builds/2272184 I also can't find a very logical explanation @marcjansen any ideas?

The +4.23% do not come from the rendering tests. They are not included in the coverage.
I made a change to tasks/server.js, maybe it's related to that.

I made a change to tasks/server.js, maybe it's related to that.

Which would be strange, right?

Ah so maybe we should limit coverage to the src directory?

Ah so maybe we should limit coverage to the src directory?

Would make sense to me.

Strange indeed. It may be that the increase is due to the previous commit in that pr (which failed the testsuite)... I am not sure though
Coverage is only relevant to files in the src directory.

It may also be that the new lib entries for the closure manager already raise the bar. Also it may be that we reach different code paths now that we run xvfb and have DISPLAY on travis. I'll see if I find time to understand more...

The coveralls report for this pr says: 14072 OF 19484 RELEVANT LINES COVERED, and 215 files covered.
The previous one has: 14706 OF 21630 RELEVANT LINES COVERED, and 248 files covered.
So we lost some covered files/lines, which raises the percentage.
Not sure wat caused this.

I was just realizing the same. One file that disappeared is  /src/ol/control/fullscreencontrol.js:
https://coveralls.io/builds/2272123/source?filename=src%2Fol%2Fcontrol%2Ffullscreencontrol.js#L29
And it seems like there is no test for this file.

I am on my mobile, and cannot dig deeper, sorry...

Before, the loader server returned all src files. Now it only returns the src files that are actually referenced by a test. And it seems like Istanbul does not include the files, that were not loaded during the test run. Though they should be instrumented?!

That's it, nice @tsauerwein!
Every source is instrumented, but when an instrumented file isn't loaded when testing, istanbul does not include a coverage point in the data it sends to coveralls.
We might want to unconditionally load every source prior toactually testing, so that the baseline is correct.

Even better would be if we had testfiles for every source, even if they weren't actually testing sth. for now.
It should be doable though to have tests for 'can be constructed' or sth.

@tsauerwein: Awarding you the silver medal in debugging coverages, in addition to zhe gold thingy @tschaub gave you


Add Help for Large Files should be above all files

Move the green help area above the all the file upload on the Files tab


Implement std::error::Error for Error

Fixes #456.
Would it be possible to get a patch release when this lands? I have an upcoming project that would want to use the new impl. cc @KizzyCode

👍


fix: Fix to enable health check on admin port from operator deployment

Containers deployed by the wildfly operator need to respond to health checks on port 9090, to do this the admin interface needs to be configured to accept connections from ips other than localhost.

Thanks for the PR. Can you please sign off the commit (https://github.com/konveyor/move2kube/pull/917/checks?check_run_id=9756286624) and then we can merge this PR.

Containers deployed by the wildfly operator need to respond to health checks on port 9090, to do this the admin interface needs to be configured to accept connections from ips other than localhost.

connections from ips other than localhost.

My understanding is that this is to prevent attacks from outside the cluster. Usually you create a proxy pod inside the cluster and access the admin console via that.

Containers deployed by the wildfly operator need to respond to health checks on port 9090, to do this the admin interface needs to be configured to accept connections from ips other than localhost.

We can go ahead with this if you find it fits with the conventions.

When we build EAP images for OpenShift using S2I the admin console is disabled, the reason being that configuration changes should be performed by script rather than via the cli or admin console.  https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html-single/getting_started_with_jboss_eap_for_openshift_container_platform/index

https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html-single/getting_started_with_jboss_eap_for_openshift_container_platform/index

@deewhyweb Is this fix still required? If so, can you please fix the DCO (you will need to signoff the commit), and then we can merge.

I'm away from my machine for the next few hours, will fix the DCO when I get back online.

Not sure why this check is still failing, as far as I can see the commit has been signed

Not sure why this check is still failing, as far as I can see the commit has been signed

Have manually set DCO to pass. Thanks!


Shield: Unit Test SOQL queries in HEDA are limiting the ability for certain fields to be encrypted

There are a number of HEDA unit tests with SOQL queries that break (hinder) platform encryption. As a general rule, if a field is to be encrypted using Shield, the field cannot be used as a filter in a WHERE clause nor can it be used in an ORDER BY clause. Since these queries are in TEST classes, it should be fairly easy to modify the queries to eliminate use of those fields.
The affected fields and test classes are:
Standard fields

Account.Name

ADDR_HouseholdAcc_TEST, line 2181

ADDR_OtherAcc_TEST, line 107, 111, 154, 159

AFFL_ContactAccChange_TEST, line 71, 107, 125, 126, 150, 151, 176

AFFL_MultiRecordType_TEST, line 284

Contact.Name

ADDR_Contact_TEST, line 980, 984, 1026, 1031

AFFL_ContactAccChange_TEST, line 74, 75, 106, 124, 148, 175

CON_Preferred_TEST, line 57, 99

Contact.Email

CON_Email_TEST, line 105

HEDA Fields

Address.MailingStreet is referenced  in SOQL queries in HEDA unit test code

ADDR_HouseholdAcc_TEST

Course.Description is referenced  in SOQL queries in HEDA unit test code

COUR_DescriptionCopy_TEST

STG_Courses_TEST

Course_Offering.SectionID is in SOQL queries in HEDA unit test code

TERM_CourseOff_TEST, line 94

**lurch: add

Tracking W-028915

@kevinswiggum -- I found all of the instances you point out except for two:
--COUR_DescriptionCopy_Test & STD_Courses_Test do not seem to have the Description being used in the query as a filter or order by. In the former, Description is indeed part of query but not being used as a filter or order by. In the latter, there aren't even any SOQL queries. Was there another class you were referring to perhaps, or should I be looking into classes referenced by that class.
Similarly in ADDR_HouseholdAcc_TEST I was only able to locate one line where it was used as a filter or order by.
Lastly was there some sort of tool you ran that I can run this through to ensure we got em all, or was this a manual investigation on your part?

Modified unit tests which were using potentially encryptable fields in SOQL filters and order by statements. In most cases they were being used to ensure a specific order was returned. This was mitigated by using a map and then retrieving the records by name. (Since they're unit tests, we can get away with this). This ensures that we can retrieve the objects in a specific order from the map.
In other cases the ORDER BY clause(s) were not being leveraged by the test code in any manner. In that scenario, the clause was simply removed
Modified one batch to remove the filter on Description that was checking to see if it Course Description was null. We perform this check in the logic so the filter was redundant.

Included in beta release 1.66 (Beta 2)

Included in production release 1.66


[type:refactor] refactor apidoc_dubbo get dubbo version

Make sure that:

[ ] You have read the contribution guidelines.
[ ] You submit test cases (unit or integration tests) that back your changes.
[ ] Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true.

Codecov Report

Merging #4320 (7c89a82) into master (015c9ce) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

:exclamation: Current head 7c89a82 differs from pull request most recent head 4341c68. Consider uploading reports for the commit 4341c68 to get more accurate results

@@             Coverage Diff              @@
##             master    #4320      +/-   ##
============================================
- Coverage     68.00%   67.97%   -0.04%
- Complexity     7462     7463       +1
============================================
  Files          1015     1015
  Lines         28745    28757      +12
  Branches       2575     2576       +1
============================================
- Hits          19548    19547       -1
- Misses         7670     7682      +12
- Partials       1527     1528       +1

Impacted Files
Coverage Δ

...client/brpc/BrpcContextRefreshedEventListener.java
68.57% <ø> (-1.43%)
:arrow_down:

...alibaba/dubbo/AlibabaDubboServiceBeanListener.java
0.00% <0.00%> (ø)

...t/apache/dubbo/ApacheDubboServiceBeanListener.java
0.00% <0.00%> (ø)

...ringcloud/init/SpringCloudClientEventListener.java
70.47% <ø> (ø)

...t/springmvc/init/SpringMvcClientEventListener.java
76.76% <ø> (ø)

...enyu/client/tars/TarsServiceBeanEventListener.java
79.54% <ø> (ø)

...a/org/apache/shenyu/common/utils/VersionUtils.java
21.27% <0.00%> (-6.39%)
:arrow_down:

...rg/apache/shenyu/plugin/rewrite/RewritePlugin.java
66.66% <0.00%> (-5.56%)
:arrow_down:

...in/response/strategy/NettyClientMessageWriter.java
71.42% <0.00%> (-3.58%)
:arrow_down:

...a/org/apache/shenyu/plugin/mock/util/MockUtil.java
77.55% <0.00%> (-2.05%)
:arrow_down:

... and 4 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

pls resolve conflicts

resolve

resolved


fix: upgrade to version 3.0.478

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign rajdavies
You can assign the PR to them by writing /assign @rajdavies in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
2e082e89f43ac67516fcfc2357b509eb040005f6
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.


Fix the Missing a Javadoc comment problem during compilation

fix problem during compilation :
Error: java: JavadocType: Missing a Javadoc comment.
The solution is to add comment to the class

Thanks. I have addressed this.


Get rid of python 3.7, since it is not supported

Naturally, this pull and the "fix 3.7" pull are both hinting at the same issue.


Do not use a single alias as escalation contact

Maybe it make sense to replace the single alias contact with a group alias.
Do not use mailto links to avoid any collection by web crawlers.

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

ID: 01b5e292-66fa-d3aa-a2ca-2f270723baee
Version Independent ID: 11e34cf9-7a6e-05a1-3536-f6951f2966c7
Content: Lifecycle of apps and extensions FAQ - Business Central
Content Source: dev-itpro/developer/devenv-update-app-life-cycle-faq.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: rweigel

Thanks for the feedback. You have a good point. This is, however, the process at this point in time. But we will take your feedback into consideration. Thanks.


Fix ddsgen server

Doesn't have any effect on the farm where the tool is actually in /usr/bin so no CI job.

+1


Fix the XNNPACK dep build issue on s390x CI

Recent commit 49b8647 introduced the  XNNPACK dep to tensorflow/lite/kernels/transpose.cc. Since XNNPACK is not supported by s390x yet, it caused the master build on s390x CI (https://ibmz-ci.osuosl.org/job/TensorFlow_IBMZ_CI/) to fail.
Commit c8f169e added a condition to tensorflow/lite/core/c/BUILD so that the dep @XNNPACK//:xnnpack_for_tflite won't be included when the flag --define=tflite_with_xnnpack=false is used in the build. However, since the macro identifier TFLITE_KERNEL_USE_XNNPACK will be defined whether this flag is used or not, the build still fails on s390x. Here is the error log:
Error: /home/alfred/jenkins/workspace/TensorFlow_IBMZ_CI/tensorflow/tensorflow/lite/kernels/BUILD:745:11: Compiling tensorflow/lite/kernels/transpose.cc failed: (Exit 1): gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 110 arguments skipped)
tensorflow/lite/kernels/transpose.cc:20:10: fatal error: xnnpack.h: No such file or directory
   20 | #include "xnnpack.h"  // from @XNNPACK
      |          ^~~~~~~~~~~
compilation terminated.

This PR is to add a condition to the tflite_kernel_use_xnnpack_optional target so that identifier TFLITE_KERNEL_USE_XNNPACK won't be defined when flag --define=tflite_with_xnnpack=false is used. Thus the build on s390x will succeed.
The bazel command used to build the master branch on s390x CI is as follows:
bazel --host_jvm_args="-Xms1024m" --host_jvm_args="-Xmx2048m" build --define=tensorflow_mkldnn_contraction_kernel=0 --define tflite_with_xnnpack=false //tensorflow/tools/pip_package:build_pip_package

Closing this PR since commit https://github.com/tensorflow/tensorflow/commit/828e7e6b89428c553621366a5c7ac7722e157409 has addressed the same issue.


Remove coupling logic from iMOD Python

In GitLab by @Hofer-Julian on Nov 29, 2023, 10:58
The coupling logic has been moved to primod, and the docs to the iMOD Suite Documentation.
Remove:

https://gitlab.com/deltares/imod/imod-python/-/tree/master/imod/couplers?ref_type=heads

now at https://github.com/Deltares/imod_coupler/tree/main/pre-processing/primod

https://gitlab.com/deltares/imod/imod-python/-/tree/master/imod/tests/test_couplers?ref_type=heads

now at https://github.com/Deltares/imod_coupler/tree/main/tests/test_primod

https://gitlab.com/deltares/imod/imod-python/-/blob/master/examples/metaswap/metaswap_example.py?ref_type=heads

now at https://deltares.github.io/iMOD-Documentation/coupler_metamod_example.html

In GitLab by @JoerivanEngelen on Dec 5, 2023, 14:55
Thanks for migrating the example to the Quarto docs! I think we should add a link in our docs to the new location of the example:
https://deltares.github.io/iMOD-Documentation/coupler_metamod_example.html


Bump rules_go and gazelle

I tried to bump rules_go and gazelle to the most recent versions but I could not build it because of a toolchain issue.
I think it's because of my Mac M1.
This is the error I see but it might be working on your machine or CI:
➜  bazel-remote git:(bump-tooling) docker/push_to_dockerhub
INFO: Build option --incompatible_enable_cc_toolchain_resolution has changed, discarding analysis cache.
ERROR: /private/var/tmp/_bazel_fmangione/5371a928ee6ff673886a72c10660bfcb/external/io_bazel_rules_go/BUILD.bazel:86:17: While resolving toolchains for target @io_bazel_rules_go//:cgo_context_data: No matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
ERROR: Analysis of target '//:push_to_dockerhub_amd64' failed; build aborted:
INFO: Elapsed time: 0.975s
INFO: 0 processes.

    Fetching @com_github_pkg_errors; Restarting.
    Fetching @bazel_gazelle_go_repository_config; Restarting.
    Fetching @local_config_cc; Building xcode-locator
    Fetching @bazel_gazelle_go_repository_tools; fetching
    Fetching @com_github_slok_go_http_metrics; Restarting.
    Fetching @com_github_grpc_ecosystem_go_grpc_prometheus; Restarting.
    Fetching @com_github_prometheus_client_golang; Restarting. ... (12 fetches)

It seems to be fine on the PR CI build

Thanks- I don't think this will change the distroless base image, but the upgrade itself is fine. Rebased and landed on the tip of master.


Header Overlaping

Description
Header and body overlaping
Screenshots

I'll be happy to help, assign this issue to me under Gssoc'23

@avneet-singh843 It is not overlapping, kindly check

"A community of learners" is missing at Mobile dimensions small and medium, working properly for mobile large


Forced handshake required in some instances to get a new token

Assumptions
I noticed that getTokenSilently() returns the same token in many instances. It appears that as long as a service worker is awake the same token will be returned and I assume it just returns the in-memory token instead of doing another handshake for the token. A handshake and new token are only created after the service worker goes to sleep and wakes up again. I am basing this on  Paul's blog post (great post, thanks for making it).
"...the nice thing is that on subsequent calls to getTokenSilently, we can pull from the in-memory cache meaning that it consistently takes less than 1ms to get a token."
https://pjhul.com/blog/auth0-web-extension
Our issue
Our issue is that some cases, we need to force a handshake and get a new token instead of using the in-memory cached token.
For us when users sign up without 3rd party auth0 (sign in with google, etc.), we require email verification via users clicking confirm email in their inbox. The user navigates to Gmail to confirm and the auth0-web-extension process is completed before confirming the email. A token is saved with emailVerified  as false. After the user confirms their email and goes to a website to use the extension functionality the service worker is still awake and has the old token with emailVerified as false. The API calls fail because we require it true.
Possible solution
I was thinking we could update getTokenSilently() with an argument to optionally force a new handshake. I am open to other ideas and interested in contributing to the repository to improve it.
Thanks!

Hey Josh, thanks for posting an issue!
If I remember correctly, the getTokenSilently() method has an option that you can pass called ignoreCache that will bypass the cache check and go straight to grabbing a new token. I took a quick look and it looks like we implement that option. so try giving that a try and let me know if that works for you!
Also, it's been a little while since I've taken a look at this library, but I'm getting back to a point in my own development where I'm going to be using this library again and so I'm planning on getting back to actively developing it. I know you mentioned you were interested in contributing, would you like if I went and opened up a couple issues with things to work on?

Hey Paul,
Great, you were right about ignoreCache. It fixed our issue, thanks! I think we discussed ignoreCache at one point but I forgot.
Also yes, I think it makes sense to open up some issues to work on. We are relying on this repository for our extension which is gaining users so we are interested in helping improve it. I don't think I can say precisely when we will work on issues, but if we open some issues then our team can monitor and prioritize helping out.
I think Matt B. and I found another issue as well, so I'll create a post for it. In general, this code is scaling well for us with our extension.
Thanks!


dashboard: bugs prematurely closed as fixed

The following situation seems to have occurred on syzbot:

A bug was fixed and syzbot was told about the fix commit.
The fix reached some managers, but some other managers failed to update to the new kernel revision (due to a kernel build breakage).
For some reason, the bug still received PatchedOn from those managers with failed builds.
The bug was closed by the dashboard.
Since some managers could not really upgrade to the new kernel revision, the bug was re-discovered and re-reported.

I've taken a look at the source code and I have the following theory.

In Manager.pollCommits(), we query the presence of pending commits by looking at the log available from the current HEAD, even though the buildCommit is passed to the function.
https://github.com/google/syzkaller/blob/89298aad70c7bd5d018a868dc31bc6ff4dca7f27/syz-ci/manager.go#L728-L729
pollCommits() is called via Manager.uploadBuild(), which does not change the current git revision.
Manager.uploadBuild() is called from Manager.restartManager(), which doesn't do any git checkouts.

The only place when we actually do git checkout is  https://github.com/google/syzkaller/blob/89298aad70c7bd5d018a868dc31bc6ff4dca7f27/syz-ci/manager.go#L259-L262
So even if it the build failed, we will still detect the fix commit and report it to the dashboard.
I guess, the proper fix here is to make GetCommitsByTitles() (as well as the corresponding git.fetchCommits() function) only consider the commits reachable from a specific commit, not the current HEAD.

I guess, the proper fix here is to make GetCommitsByTitles() (as well as the corresponding git.fetchCommits() function) only consider the commits reachable from a specific commit, not the current HEAD.

Or checkout the build commit before calling these.
Or we can do mgr.pollCommits only after a successful build (not after syz-ci restart). But this looks like a more risky change.

Using an outdated kernel checkout may also cause a different problem.
https://github.com/google/syzkaller/blob/89298aad70c7bd5d018a868dc31bc6ff4dca7f27/syz-ci/manager.go#L620
If the kernel build failed, we end up with a syzkaller instance whose vmlinux is not in sync with kernel source files. It may cause problems for coverage reports and during scripts/get_maintainer.pl calls.
So checking out the last successfully built kernel commit sounds better indeed.


add text control

Add text control for strings

Hi, it seems that the authors of this library have moved on; you might want to have a look at my fork, in particular I have a branch called ImageButton where I've been generally adding any new stuff I wanted, including a text box with some basic virtual keyboard input that you might find useful.


[Extensions] Catalog: Invalid content count in filters and chart

Current Behavior
Both of these encircled components are missing data.

Contributor Guides and Handbook

📚 Meshery Build and Release Strategy
🎨 UI Design For Meshery Extensions Figma in Figma (open invite)
📚 Meshery Extensibility Providers
⌨ Meshery API Docs
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

This issue is fixed now


Post by email attachments are added to the wrong message

Use PBE to reply to a topic and attaching a message to the email, ends up with the file attached to the post the user is replying to.
I think the problem is in Emailpost.subs.php, in particular:
'post' => !empty($email_message->message_id) ? $email_message->message_id : 0,

because, as far as I can see, message_id is filled in EmailParse.class.php in _load_key_details with:
$this->message_id = (int) $match[4];

that, should contain the id of the message found in the email, so the one the user is replying to.
I think the fix is simply to assume in Emailpost.subs.php that we don't have a message id and fill it with 0.
@Spuds what do you think?

So there are two things here ... One is what you identified, that the post id should be set to zero so they are processed but not owned by any existing message.  Then on successful new message/reply creation, we need to call bindMessageAttachments to have the new message own the new attachments.  I have it fixed on my local.

https://github.com/Spuds/Elkarte/commit/197cb93594b586509416b7b03a9499cc3edb6617 should clear it up


Consider removing the OpenID module from the built-in SaaS recipe

It's not clear to me why the OpenID module is enabled by default for the SaaS recipe.
@sebastienros @jersiovic is there any particular reason for this?

There is not an strong reason. It was a decissión taken for not hiding to new comers a relevant feature of Orchard for their apps.

I think I already removed it in dev ... will have to check though

I'm tempted to say no, assuming this sort of things is still configured in the recipe.json files: https://github.com/OrchardCMS/Orchard2/blob/dev/src/OrchardCore.Cms.Web/Recipes/saas.recipe.json#L26

Done by @sebastienros: https://github.com/OrchardCMS/Orchard2/commit/8d78c6761297d2198c7a101b4179e28fe67f3651.


Suggestion: add a navbot feature

I think Fedoraware should have a navbot feature that other cheats have.
And about the navmesh files i think those are in the maps folder so i think downloading them should not be needed.

Thanks for this. We will not consider your suggestion. :)


lag with huge form using FieldArray in v6 alpha 14

V6 Alpha 14 have sloved lots of problems with huge efforts you guys put on. Bravo!!!
But I was trying FieldArray to make a huge 'Table' form and for some reason it lagged as v5 did. That seemed unexpected.
Here is what my code looks like:
const renderTextField = props => (
	<TableRowColumn key={props.name+props.index}>
	<TextField errorText={props.error} {...props} /></TableRowColumn>)

const renderArray = props => {
	return(
		<Table selectable={false}>
        <TableHeader key="th" displaySelectAll={false} adjustForCheckbox={false}>
	        <TableRow>
	          <TableHeaderColumn key="1">FieldA</TableHeaderColumn>
	           <TableHeaderColumn key="2">FieldB</TableHeaderColumn>
	           <TableHeaderColumn key="3">FieldC</TableHeaderColumn>
	           <TableHeaderColumn key="4">FieldD</TableHeaderColumn>
			   ...
	        </TableRow>
	     </TableHeader>
	     <TableBody displayRowCheckbox={false} deselectOnClickaway={false}>

      {props.map((eachRel, index) =>
        <TableRow>
        <Field name={`${eachRel}.fieldA`} component={renderTextField} index={index}
        	disabled={props.disabled}/>
        <Field name={`${eachRel}.fieldB`} component={renderTextField} index={index}
        	disabled={props.disabled}/>
        <Field name={`${eachRel}.fieldC`} component={renderTextField} index={index}
        	disabled={props.disabled} />
        <Field name={`${eachRel}.fieldD`} component={renderTextField} index={index}
        	disabled={props.disabled}/>
		...
        </TableRow>)}
		   </TableBody>
		</Table>
	)
}

<form  onSubmit={handleSubmit(this.handleSubmit)}>
  <FieldArray  name="contents" disabled={fieldDisabled} component={renderArray}/>
</form>

...
reduxform(...)
{initilValue:data}

Does <TableRow key={index}> help? That's the only weird thing I see.
If you could whip up a JSBin, or even an example project, demonstrating this, that would go a long way to helping me diagnose the problem.

@erikras  sorry for not making a JSBin.
just try http://redux-form.com/6.0.0-alpha.14/examples/fieldArrays/
when you add about 100 members, the lagging appears.


sysstat: 12.6.0 -> 12.6.1

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

https://nvd.nist.gov/vuln/detail/CVE-2022-39377

I think it's been patched in 12.6.1.

It has, yes.

Oh I meant to add the security label too, not sure what happened.


ask questions?

could you please tell me how to run this program (I have already installed the requirements.)? thank you!

Hi,
Sure! Unfortunately, I have not had time to create documentation on how to run the program yet. But that will come. I will also do some clean up so it gets easier to start using this software. However, you should be able to run it if you download the whole repository locally to your PC. In the Multipath_analysis folder you will find a file called Running_multipath_analysis_example.py. You should be able to run it directly, based on the path to the different test files in TestData folder. If it does not work, try to replace  the path to some of the test files with the path locally on your computer. As for instance:
from GNSS_MultipathAnalysis import GNSS_MultipathAnalysis
rinex_obs_file = r'C:\Users\XXX\TestData\ObservationFiles\OPEC00NOR_S_20220010000_01D_30S_MO_3.04.rnx'
sp3_file = r'C:\Users\XXX\TestData\SP3\test1.eph'
analysisResults = GNSS_MultipathAnalysis(rinex_obs_file,
desiredGNSSsystems=['G'],
sp3NavFilename_1=sp3_file)
Please let me know if you don't get it to work.
Best regards,
Per Helge

Thank you for your relpy！ According to your tips, I encountered the following error，I hope you help me solve the problem, my python is worse,thank you sincerely！
`Currently processing all available bands for GPS:   0%|          | (0/3)D:\PythonProject\GNSS_Multipath_Analysis_Software-master\Multipath_analysis\computeDelayStats.py:366: RuntimeWarning: invalid value encountered in cast
combined_slip_epoch_elevation_angles = current_sat_elevation_angles[combined_slip_epochs, i+1].astype(int)
Traceback (most recent call last):
File "D:\Python38\lib\site-packages\matplotlib\texmanager.py", line 255, in _run_checked_subprocess
report = subprocess.check_output(
File "D:\Python38\lib\subprocess.py", line 415, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "D:\Python38\lib\subprocess.py", line 493, in run
with Popen(*popenargs, **kwargs) as process:
File "D:\Python38\lib\subprocess.py", line 858, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "D:\Python38\lib\subprocess.py", line 1311, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] 系统找不到指定的文件。
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "D:/PythonProject/GNSS_Multipath_Analysis_Software-master/Multipath_analysis/test.py", line 6, in
analysisResults = GNSS_MultipathAnalysis(rinex_obs_file,
File "D:\PythonProject\GNSS_Multipath_Analysis_Software-master\Multipath_analysis\GNSS_MultipathAnalysis.py", line 573, in GNSS_MultipathAnalysis
plotResults(current_code_dict['ion_delay_phase1'], current_code_dict['multipath_range1'],
File "D:\PythonProject\GNSS_Multipath_Analysis_Software-master\Multipath_analysis\plotResults.py", line 315, in plotResults
fig5.savefig(graphDir + "/" +  filename2, dpi=300)
File "D:\Python38\lib\site-packages\matplotlib\figure.py", line 3328, in savefig
self.canvas.print_figure(fname, **kwargs)
File "D:\Python38\lib\site-packages\matplotlib\backend_bases.py", line 2362, in print_figure
result = print_method(
File "D:\Python38\lib\site-packages\matplotlib\backend_bases.py", line 2228, in
print_method = functools.wraps(meth)(lambda *args, **kwargs: meth(
File "D:\Python38\lib\site-packages\matplotlib\backends\backend_agg.py", line 509, in print_png
self._print_pil(filename_or_obj, "png", pil_kwargs, metadata)
File "D:\Python38\lib\site-packages\matplotlib\backends\backend_agg.py", line 457, in _print_pil
FigureCanvasAgg.draw(self)
File "D:\Python38\lib\site-packages\matplotlib\backends\backend_agg.py", line 400, in draw
self.figure.draw(self.renderer)
File "D:\Python38\lib\site-packages\matplotlib\artist.py", line 95, in draw_wrapper
result = draw(artist, renderer, *args, **kwargs)
File "D:\Python38\lib\site-packages\matplotlib\artist.py", line 72, in draw_wrapper
return draw(artist, renderer)
File "D:\Python38\lib\site-packages\matplotlib\figure.py", line 3125, in draw
mimage._draw_list_compositing_images(
File "D:\Python38\lib\site-packages\matplotlib\image.py", line 131, in _draw_list_compositing_images
a.draw(renderer)
File "D:\Python38\lib\site-packages\matplotlib\artist.py", line 72, in draw_wrapper
return draw(artist, renderer)
File "D:\Python38\lib\site-packages\matplotlib\axes_base.py", line 3030, in draw
self._update_title_position(renderer)
File "D:\Python38\lib\site-packages\matplotlib\axes_base.py", line 2974, in _update_title_position
ax.yaxis.get_tightbbox(renderer)  # update offsetText
File "D:\Python38\lib\site-packages\matplotlib\axis.py", line 1320, in get_tightbbox
self._update_label_position(renderer)
File "D:\Python38\lib\site-packages\matplotlib\axis.py", line 2569, in _update_label_position
bboxes, bboxes2 = self._get_tick_boxes_siblings(renderer=renderer)
File "D:\Python38\lib\site-packages\matplotlib\axis.py", line 2104, in _get_tick_boxes_siblings
tlb, tlb2 = axis._get_ticklabel_bboxes(ticks_to_draw, renderer)
File "D:\Python38\lib\site-packages\matplotlib\axis.py", line 1299, in _get_ticklabel_bboxes
return ([tick.label1.get_window_extent(renderer)
File "D:\Python38\lib\site-packages\matplotlib\axis.py", line 1299, in
return ([tick.label1.get_window_extent(renderer)
File "D:\Python38\lib\site-packages\matplotlib\text.py", line 959, in get_window_extent
bbox, info, descent = self._get_layout(self._renderer)
File "D:\Python38\lib\site-packages\matplotlib\text.py", line 378, in _get_layout
_, lp_h, lp_d = _get_text_metrics_with_cache(
File "D:\Python38\lib\site-packages\matplotlib\text.py", line 97, in _get_text_metrics_with_cache
return _get_text_metrics_with_cache_impl(
File "D:\Python38\lib\site-packages\matplotlib\text.py", line 105, in _get_text_metrics_with_cache_impl
return renderer_ref().get_text_width_height_descent(text, fontprop, ismath)
File "D:\Python38\lib\site-packages\matplotlib\backends\backend_agg.py", line 226, in get_text_width_height_descent
return super().get_text_width_height_descent(s, prop, ismath)
File "D:\Python38\lib\site-packages\matplotlib\backend_bases.py", line 641, in get_text_width_height_descent
return self.get_texmanager().get_text_width_height_descent(
File "D:\Python38\lib\site-packages\matplotlib\texmanager.py", line 368, in get_text_width_height_descent
dvifile = cls.make_dvi(tex, fontsize)
File "D:\Python38\lib\site-packages\matplotlib\texmanager.py", line 300, in make_dvi
cls._run_checked_subprocess(
File "D:\Python38\lib\site-packages\matplotlib\texmanager.py", line 259, in _run_checked_subprocess
raise RuntimeError(
RuntimeError: Failed to process string with tex because latex could not be found
`

Thanks for letting me know. Do you run the software on own RINEX data now, or are you testing it in the files in TestData?
It seems to be a problem with the plotting and use of TEX as a interpreter. Do you have LaTex/Tex installed on your computer? Because I am using that in the plots to get prettier text formatting. But if this causes problem for user that don't have LaTex on their computer, I have to consider to not to use it. Please test
to set plotEstimates=False and plotEstimates=False in the function arguments. Like this for instance:
analysisResults = GNSS_MultipathAnalysis(rinex_obs_file,
desiredGNSSsystems=['G'],
sp3NavFilename_1=sp3_file,
plotEstimates=False,
plot_polarplot=False)
With these parameters, the software will not create any plots. And if it runs with these arguments, the software failed earlier due to lack of LaTex support on your computer. If that's the case, I will provide a new code for you.

Thanks for letting me know. Do you run the software on own RINEX data now, or are you testing it in the files in TestData?
It seems to be a problem with the plotting and use of TEX as a interpreter. Do you have LaTex/Tex installed on your computer? Because I am using that in the plots to get prettier text formatting. But if this causes problem for user that don't have LaTex on their computer, I have to consider to not to use it. Please test
to set plotEstimates=False and plotEstimates=False in the function arguments. Like this for instance:
analysisResults = GNSS_MultipathAnalysis(rinex_obs_file,
desiredGNSSsystems=['G'],
sp3NavFilename_1=sp3_file,
plotEstimates=False,
plot_polarplot=False)
With these parameters, the software will not create any plots. And if it runs with these arguments, the software failed earlier due to lack of LaTex support on your computer. If that's the case, I will provide a new code for you.

Thank you again for your guidance，it's ok!

No problem! Are you able to run it without any errors now?


Lazy intialize the Docker client.

Fixes #116

has this been released?  it seems metaparticle_pkg 0.6.6 still has this issue


chore: configuring new finance year and adding latest data

new year new config
making sure 2023 has latest info
latest january/february data added

/rtm


Columns customize

Category

Feature

Overview

Add option to customize torrent widget columns

Issue Number

Related issue: #1471

Screenshot

add an option to customize their size too


LaTeX code support in Windows Terminal

Description of the new feature/enhancement

The ultimate tool for displaying fractions and many mathematical characters is LaTeX. LaTeX or TeX is a notation for mathematical characters, a so-called typesetting system. The input is done with the keyboard. Formatting and mathematical characters are entered in text form and then converted.

LaTeX code example:

\frac{a}{b}

Proposed technical implementation details (optional)

Okay so I'm not sure what you're really looking for here - Do you want LaTeX rendering directly within the Terminal? A LaTeX shell application?

Hello @zadjii-msft ,

A LaTeX shell application?

Yes, would that be possible?

With kind regards

Michael

I mean, there's https://github.com/nilqed/latex2sixel
Which would depend on the Terminal supporting sixel graphics, #448

Would it be possible for the Microsoft team to release their own version which is always checked for errors?
With kind regards

Michael


Added new flag icons and relevant css for flag tags

Since we probably don't want all those flags as tags in the css I put the coordinates in a separate file for now. But who knows, maybe there will be a top OW team from North Korea soon...

Haha. Those flag icons look much cleaner though, and of course 2x too(!) 😃
You're definitely right on not including all of them – looks like there are 265 vs 67 currently.
Can I ask what the source is for the images? Just wondering whether there's a license attached to them.

They are actually completely free to use, I was pretty stoked to find these. Great stuff by the author:
Source on github

Oh brilliant! I remember seeing that project a while ago.
Seeing as they're MIT licensed though, I guess we better make a small wiki page on the sub with credit/license still.

I used the same fork for both of my pull-requests. I just synced it by pulling from this repository.

Oh sweet, my bad! 😬


Livewire v3 + README updates

Just noticed some changed are from my formatter lmao, sorry about that @joshhanley (:
Changed also the readme to include an example of the add new event we talked about several months ago (better late than never ;) )
I'm glad contributing to open source as I'm getting confident with the Laravel ecosystem!!

@Edgarborras94 Thanks! I've triggered the tests to run. Not sure if they will though as I'll probably need to update then to suit v3.
Re styling, generally it's better to remove style changes as it's harder for maintainers to review the code you actually changed (vs code format changes). So if it's not too hard, can you reset the styling?
Also thanks for updating the readme! Will have a good look in the next couple of days 🙂
Yeah it's always nice to be able to contribute 😁

I've removed the reformatted code I think. Also noticed I removed the package "joshhanley/livewire-dusk-testbench": "^0.1.0" because it's still not v3 compatible (I think)
I will keep an eye on this topic so tell me anything you need
Cheers!

@Edgarborras94 thanks for the PR! Sorry it took me a while to get to it.
Removing the joshhanley/livewire-dusk-testbench meant I couldn't confirm everything was working correctly, as no tests would run, hence why I delayed until I had time to dig in.
I've got tests running now without it, using a fork of Livewire which exposes some of it's dusk testing internals, which I hope to get merged into Livewire core so package maintainers can use it. If that doesn't work, then I will update joshhanley/livewire-dusk-testbench with the V3 code.
Thanks again for your help! 😁


[cluster-test] Update grafana link

Motivation
Cluster test template has been updated.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
http://grafana.ct-0-k8s-testnet.aws.hlw3truzy4ls.com/d/performance/performance?orgId=1
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/developers.libra.org, and link to your PR here.)

thx for updating this

/land


[Feature] Add interactive diffusers model merger

This PR adds scripts/merge_fe.py, which will merge any 2-3 diffusers models registered in InvokeAI's models.yaml, producing a new merged model that will be registered as well.
Currently this script will only work if all models to be merged are known by their repo_ids. Local models, including those converted from ckpt files, will cause a crash due to a bug in the diffusers checkpoint_merger.py code. I have made a PR against huggingface/diffusers which fixes this: https://github.com/huggingface/diffusers/pull/2060
I still need to create a command line version of this and documentation. Hence it is draft at the current time.

As I work with this more I'm finding various bugs in the diffusers checkpoint_merge functionality. In particular, safetensors are not supported. I will make a PR against diffusers in the near future.

@damian0815 Already got conversion from ckpt to diffusers straight to the pipeline (without needing to save the file) working. It would be nice if this could get the same treatment, so that we could do experimental merges without using a bunch of disk space. https://github.com/invoke-ai/InvokeAI/issues/1587

All that needs to be done is not to save the merged model at the very end, but to keep it memory. However, this will require additional support by the CLI and WebGUI to expose the commands to do it, and is unlikely to be ready in time for 2.3.


rpcserver: startTime defaults to the unix epoch

Closes https://github.com/lightningnetwork/lnd/issues/3357.  When
start_time isn't specified, its default value is 0.  This meant when
users explicitly specified a start_time of 0, we would incorrectly set
start_time to 24 hours in the past.  Now, n0 means n0.
Pull Request Checklist

[X] If this is your first time contributing, we recommend you read the Code
Contribution Guidelines
[X] All changes are Go version 1.12 compliant
[X] The code being submitted is commented according to Code Documentation and Commenting
[X] For new code: Code is accompanied by tests which exercise both
the positive and negative (error paths) conditions (if applicable)
[X] For bug fixes: Code is accompanied by new tests which trigger
the bug being fixed to prevent regressions
[X] Any new logging statements use an appropriate subsystem and
logging level
[X] Code has been formatted with go fmt
[X] For code and documentation: lines are wrapped at 80 characters
(the tab character should be counted as 8 characters, not 4, as some IDEs do
per default)
[X] Running make check does not fail any tests
[X] Running go vet does not report any issues
[X] Running make lint does not report any new issues that did not
already exist
[X] All commits build properly and pass tests. Only in exceptional
cases it can be justifiable to violate this condition. In that case, the
reason should be stated in the commit message.
[X] Commits have a logical structure according to Ideal Git Commit Structure

If we push this out to the CLI, does that mean we make some or all parameters mandatory, since we won't be applying any default-setting logic to them?  I agree with the premise behind validating user input at the CLI level, I just want to consider other consumers of the RPC that might be expecting some fields to have default values if left unset.

I would say interpret 0 as unix epoch at RPC level, then set the default to 24 hours in the past on the CLI level.

0 will be default for protos.


Add statusgraph

@moolen are you still working on it? Anything you might want to add?

hey @bonndan thanks for adding statusgraph here :heart:! I'm not actively working on it but may get back into it. I think the text is fine how it is, i'll update the information and status in the statusgraph README if it changes, thank you!

hey @bonndan thanks for adding statusgraph here :heart:! I'm not actively working on it but may get back into it. I think the text is fine how it is, i'll update the information and status in the statusgraph README if it changes, thank you!


Refactor nwdl and other code to remove the 'all_' prefix as it is misleading post-seasonizing

We used to have season_ and all_. Now we only have all_ (and week and month for homepage card charts only) but the all_ stuff persists. It should be ripped out to avoid confusion.

This got zapped at some point (preaggregation?) Hurrah.


Solve #237, Refine units in Rule expression

Codecov Report

Merging #238 into trunk will increase coverage by 0.11%.
The diff coverage is 80%.

@@            Coverage Diff             @@
##            trunk     #238      +/-   ##
==========================================
+ Coverage   58.22%   58.33%   +0.11%
==========================================
  Files         101      101
  Lines        4354     4354
  Branches      652      652
==========================================
+ Hits         2535     2540       +5
+ Misses       1579     1577       -2
+ Partials      240      237       -3


Update caches systems references to be actual caches and not an additional 0(n) lookup

Overview
The Service registry is effectively a 0n lookup system using a dictionary, the dictionary is used primarily to ensure fast 0n lookup and also provide unique adherence to the single service principle of dependency injection.
This change resolves an issue whereby the current "CoreServices" systems lookups are actually not caching / improving lookup performance by adding an additional 0n lookup on top of / in replacement of the original 0n lookup.
Simply put, this provides direct references to the the instantiated services in the service registry rather than looking them up, potentially every update frame.
I have left in the updated cache table, although it is likely redundant.
Changes
Simply adds direct reference caches for each of the core systems identified in the "Core Systems" cache.
Verification

This optional section is a place where you can detail the specific type of verification
you want from reviewers. For example, if you want reviewers to checkout the PR locally
and validate the functionality of specific scenarios, provide instructions
on the specific scenarios and what you want verified.
If there are specific areas of concern or question feel free to highlight them here so
that reviewers can watch out for those issues.
As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):
git fetch origin pull/{PR_ID}/head:name_of_local_branch
git checkout name_of_local_branch

/azp run

/azp run

Thanks for this change!