connection_id not set for vpc_links

Description
Please provide a clear and concise description of the issue you are encountering, your current setup, and what steps led up to the issue. If you can provide a reproduction, that will help tremendously.
⚠ Note
yes, this has been done
Versions
Terraform v0.15.0
on darwin_amd64

provider registry.terraform.io/cloudflare/cloudflare v2.20.0
provider registry.terraform.io/hashicorp/aws v3.37.0 - Terraform:

Reproduction
 vpc_links = {
    md-vpc = {
      name               = "md"
      security_group_ids = [module.security-group.this_security_group_id]
      subnet_ids         = var.private_subnet_ids
    }
  }

  integrations = {
    "$default" = {
      description        = "md loadbalancer integration"
      connection_type    = "VPC_LINK"
      integration_uri    = aws_lb_listener.md_lb_listener.arn
      integration_type   = "HTTP_PROXY"
      integration_method = "ANY"
    }
  }

Code Snippet to Reproduce
See above
Expected behavior
Vpc connection_id should be added
Actual behavior
added vpcid manually through ui, it will be removed with apply:
 # module.apigw.aws_apigatewayv2_integration.this["$default"] will be updated in-place
  ~ resource "aws_apigatewayv2_integration" "this" {
      - connection_id          = "3sgwo6" -> null
        id                     = "zbdvzrq"
        # (10 unchanged attributes hidden)
    }

Terminal Output Screenshot(s)
See above
Additional context
api gw, integration through internal NLB lb towards vanilla ec2 instances.

Try to set vpc_link argument in the integrations like shown here:
https://github.com/terraform-aws-modules/terraform-aws-apigateway-v2/blob/master/examples/vpc-link-http/main.tf#L69

Thanks - that works!


[FP]: False Positive Nuget Azure.Identity

Package URl
<EMAIL_ADDRESS>CPE
cpe:2.3:a:microsoft:azure_identity_sdk:1.1000.323.51804:::::::*  (Confidence:Low)
CVE
CVE-2023-36415
ODC Integration
{"label"=>"CLI"}
ODC Version
8.3.1
Description
Hi,
we get a false positive for the Azure.Identity nuget package.
File version of the dll is set to: 1.1000.323.51804
Product version to: 1.10.3+a4954......

The vulnerability should be fixed from 1.10.2 and up.
Best regards,
Daniel

We are also facing same false positive vulnerability. When can we expect a solution?

Duplicate of #7000 (and #6999 #6334 and many others)
ODC doesn't understand the language discriminators in CPEs. You have to suppress the individual CVEs yourself for now.
It thinks this is vulnerable because the Javascript library uses 3.x style versioning which is still affected.


Clean up old repositories

The top hits on google are still garbage.

Humm... JACDAC leads to 0 search hits now. Looks like we are out of the index.

Is this good or bad? :smile:
jacdac-ts shows up first for me on bing and google


VSCode extensions that have capital letters seem to not be registered, and get uninstalled

I have a bunch of extensions that are managed using homebrew: https://gist.github.com/vraravam/8c9eae91a3750bed86b81e3a4711f842#file-brewfile-L193-L231
After a recent upgrade of VSCodium Insiders and homebrew, I noticed that while "brew bundle install" will install all the extensions, "brew bundle cleanup" will somehow delete only those extensions that start with capital letters!

The actual/valid extension names (all of the ones marked as "would be deleted") have capital letters somewhere in the extension-id as seen in the above link of the Brewfile, but for some reason they show up with lower-case - and I suspect this marks them for deletion. Please help fix asap.

I've opened a PR: https://github.com/Homebrew/homebrew-bundle/pull/1303

Please help fix asap.

This is a volunteer run open source project. If you need a fix ASAP: you need to open a PR yourself. Do not say things like this in future, please.

Do not say things like this in future, please.

sure - i apologize. It took me some time to understand and diagnose where the problem lies. But, in the future, i will try to get into the source code for a PR as well. Thanks -  <3 for homebrew!


Enable full test pass in MacOS Daily Builds

Hi @bmanikm, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;


Add nightly product functional testing

🗣 Description
Create an initial pipeline that conducts functional testing for one product every weekday night.
💭 Motivation and context
These tests ensure that ScubaGear continues to effectively test positive and negative settings for Sharepoint.  As functional testing can take a long time, they are running nightly to avoid slowly down work.
Closes #652
🧪 Testing
Created new workflow.
Created script that calls the product testing script.
Created a PSON file that provides the input parameters for testing.  This provides a data-driven approach.
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[x] All future TODOs are captured in issues (see #731).

✅ Pre-merge checklist

[ ] Revert dependencies to default branches.
[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a release.

@nanda-katikaneni , This PR is ready for merging.  The 2 Lint Checks are still failing, pending developers complying the checks.


Ensure new Pipeline/Monovertex is receiving data

Summary
This is to solve the following problems:

eliminate the possibility that the new Pipeline/Monovertex is not receiving data due to too few Kafka partitions (no Kafka partitions available)
only transfer data to the new Pipeline/Monovertex after it is showing its in a healthy state (phase=Running, healthy conditions). (note this issue should be done first or in parallel with this one)

As agreed upon with Vigith after presenting Blue/Green: Ensuring new Pipelines/Monovertices have data, we agreed on this possible sequence initially:

New Pipeline/Monovertex created with source.scaling.min=0
wait for it to be in "Running" phase with all healthy Conditions
update source.scaling.min back to what it's supposed to be set to
set original pipeline's source.scaling.min=0 (or pause it?)
confirm that new Pipeline is in "Running" phase with all healthy Conditions after some prescribed waiting time
If new Pipeline fails assessment at any time, set its source.scaling.min back to 0.

Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

moving to future sprint


#0: Add core range iterators

We have CoreRange and CoreRangeSet classes that represent a single rectangle or a set of rectangles on a 2D grid of cores. There is currently no way to iterate over instance of these classes, so instead we iterate over all the device cores and then check whether a core belongs to a core range set. This PR adds the ability to directly iterate over these classes.

Will these be used at model run-time to update run-time args?
Using sets is slow and cache unfriendly
For host speed we should move away from sets and use plain arrays + packed x,y coords

Will these be used at model run-time to update run-time args? Using sets is slow and cache unfriendly
For host speed we should move away from sets and use plain arrays + packed x,y coords

we should hold off on sets, until we design  optimal data structures
@pgkeller has a couple of proposals in the queue to speed up host run-time code

What is the performance of this iterator (especially during runtime args callback) compared to us generating the vector of cores during compile pass, and just iterating over this vector during runtime args callback?

I'm not adding a set, the set is already there. It's a way to iterate over an existing CoreRangeSet without additional allocations.

I'm not adding a set, the set is already there. It's a way to iterate over an existing CoreRangeSet without additional allocations.

I think it's good to have an iterator for functionality, but the comments Davor and I made are about the perf critical path when we set args in the callback.
You've changed some of the callbacks to use this iterator which would iterate over a set, and then calculate the core coords on the fly, as opposed to our previous code which generates the full vector of individual cores in compile pass, and then we just iterate over this vector when in the callback. The vector method would seem more performant?

I think it's good to have an iterator for functionality, but the comments Davor and I made are about the perf critical path when we set args in the callback.
You've changed some of the callbacks to use this iterator which would iterate over a set, and then calculate the core coords on the fly, as opposed to our previous code which generates the full vector of individual cores in compile pass, and then we just iterate over this vector when in the callback. The vector method would seem more performant?

No worries, I'm going to measure the perf implications of my changes, I understand this is a sensitive change. Not going to merge if it affects the perf negatively.


Versioned serialization schemes for types

The problem
When we encounter a problem with our deserializers, such as in #3003, #2965 and  #2444, it can be very difficult to implement a fix. It is difficult because we can only fix such issues during a hard fork, and leading up to the hard fork we must maintain two serializations for the same type in order to not cause unintended network splitting (the problematic version must be used before the hard fork, and the fixed version is used afterwards). This can be especially tricky with the FromCBOR typeclass, since it is not always easy to search for where all the problematic uses are located.
A solution
Create a new typeclass to replace ToCBOR and FromCBOR which depends not only on the type but also on the protocol version. The first instances will all be implemented identically to our current ToCBOR and FromCBOR instances for all protocol versions up to the current one.
Note that this change that will effect the downstream components. We will need to coordinate with consensus and node, and many other teams.

My $0.02.
We have a similar problem in plutus with our serialization for scripts. I think the considerations are the same although t they're slightly different libraries. What we do at the moment is we don't use the typeclass that the library provides, but rather we just use explicit decoder values. For CBOR this would be something like:
-- don't do this
instance Serialise Foo where
  decode :: Decoder s Foo

-- do this
decodeFoo :: ProtocolVersion -> Decoder s Foo

It's a bit clunky, but it works okay. You can also then take a mixed approach: if you need to decode something that isn't version-sensitive (an integer, say), you can just call decode and use the typeclass version.
I guess we could define a typeclass for this, but that does force you to pick an interface for all the decoders to share. And in fact I lied above: we don't just pass the protocol version, in some cases we also pass a predicate that indicates whether particular builtins are allowed. So we do make use of the variability. Something to consider, anyway.

I second @michaelpj 's suggestion — for a slightly different reason.
In cardano-wallet, we always have trouble finding the piece of code that is responsible for serializing/deserializing a specific type, because it's hard to figure out which instance of which type class is selected (this information is inferred from the code, but not written explicitly). So, usually we end up with "Hm, I think it's ok to use toCBOR here, but I'm not quite sure". The "not quite sure part" makes me feel uneasy — it's acceptable for the Show type, but not if I want to explicitly control the format.
Put differently: I think that specifying the format explicitly on the value-level as opposed to implicitly on the type-level would help with whatever issues we have. 🤔

In cardano-wallet, we always have trouble finding the piece of code that is responsible for serializing/deserializing a specific type, because it's hard to figure out which instance of which type class is selected (this information is inferred from the code, but not written explicitly). So, usually we end up with "Hm, I think it's ok to use toCBOR here, but I'm not quite sure". The "not quite sure part" makes me feel uneasy — it's acceptable for the Show type, but not if I want to explicitly control the format.

The reason that you probably cannot always trust the inferred serialization is because when we do find bugs, we cannot easily fix the bug, and have to work around it at an upstream type. My hope for a versionedToCBOR would be that you could always trust it.

The reason that you probably cannot always trust the inferred serialization is because when we do find bugs, we cannot easily fix the bug, and have to work around it at an upstream type. My hope for a versionedToCBOR would be that you could always trust it.

Yes and no. The trouble is that I'm often not sure which type I call toCBOR on — it might not even be the type Tx that I'm interested in. In that sense, serializeTx :: Tx -> ByteString would give me some additional type safety / visibility.

Yes and no. The trouble is that I'm often not sure which type I call toCBOR on — it might not even be the type Tx that I'm interested in. In that sense, serializeTx :: Tx -> ByteString would give me some additional type safety / visibility.

Our types are often too polymorphic for that. Here's a good example that I stole from @lehins :
data AlonzoTx era = AlonzoTx
  { body :: !(Core.TxBody era),
    wits :: !(Core.TxWits era),
    isValid :: !IsValid,
    auxiliaryData :: !(StrictMaybe (AuxiliaryData era))
  }

We need to rely on type classes (or something equivalent) in order to decode body and wits.

@HeinrichApfelmus This a classic argument type classes vs monomorphic function. Some people say you should embrace them, some say they are evil. You can make the same argument for almost any prominent type class in Haskell community. Be it To/FromJSON, Vector and MVector type class, any serialization library (binary, serialize, persist, etc), mtl vs transformers, etc.
My argument is, type classes are strictly superior, because you can always specialize the type class function, but you can't make a specialized function more polymorphic.

The trouble is that I'm often not sure which type I call toCBOR on — it might not even be the type Tx that I'm interested in.

So, to your trouble I can say, restrict the type and you'll know what you are interested in:

toCBOR @(Encoder Tx)

vs serializeTx :: Tx -> ByteString

To expand on the example @JaredCorduan posted above, Core.TxBody era and Core.TxWits era are type families parameterized on era, which means if we were to go the monomorphic route we'd have to write a separate deserializer for AlonzoTx for every era that it is used in (i.e. Alonzo, Babbage, Conway and possibly later ones as well) and for every crypto the era is parameterized on. So all of the sudden instead of one function that does deserialization we end up with six separate, albeit very similar deserializing functions. We have many types like this in ledger codebase, so it will simply not work for ledger. The only reason why monomorphic deserializing functions work well in plutus codebase, is because they aren't parametrized on type arguments.
@michaelpj and @HeinrichApfelmus Thank you for your suggestions though.

I'm not saying that the deserialisers need to be monomorphic! In fact, the Plutus ones are highly polymorphic. Just that having them be functions rather than typeclass methods avoids tying you to an upstream interface, which can be helpful.

@michaelpj Do you mind sharing a link to a few modules in a Plutus repo where there examples of highly polymorphic deserializers. I'd like see some concrete examples of what you mean.

So, to your trouble I can say, restrict the type and you'll know what you are interested in:
toCBOR @Tx or toCBOR :: Tx -> Encoding

Fair enough. 🤔 My trouble is about imposing some type constraint, whether that is done through @ or a name suffix Tx does not matter.
I guess that the specific function from the ledger that made me nervous is toCBORForMempoolSubmission — I don't know if that is equal to, or supposed to be equal to the toCBOR instance unless I look at the source code. The alternative is toCBORForSizeComputation, and I felt that I would be better off using one explicitly rather than hoping that the toCBOR implementation does the right thing for me.

I guess that the specific function from the ledger that made me nervous is toCBORForMempoolSubmission — I don't know if that is equal to, or supposed to be equal to the toCBOR instance unless I look at the source code. The alternative is toCBORForSizeComputation, and I felt that I would be better off using one explicitly rather than hoping that the toCBOR implementation does the right thing for me.

I have no idea why toCBORForMempoolSubmission is even exported, it is an internal detail and toCBOR is always the right choice.

Do you mind sharing a link to a few modules in a Plutus repo where there examples of highly polymorphic deserializers. I'd like see some concrete examples of what you mean.

Ah, I see the issue. We don't have any examples with type families, that does make things tricky because you need to pass around deserializers for the parts, either as explicit values or as typeclass dictionaries, and the typeclass dictionaries sure are more convenient.
In plutus we do indeed use typeclasses for values of the actual types that we are polymorphic over, but usually that's just a few bits deep down. Anyway, here's the file for reference: https://github.com/input-output-hk/plutus/blob/master/plutus-core/untyped-plutus-core/src/UntypedPlutusCore/Core/Instance/Flat.hs


Forbidden words wrong validation

The current license plates forbidden words filter is incorrect, because you strip the dashes before the forbidden words check.
SS/SD/GVD are not allowed, but with dashes they are:
01-GVD-1 is forbidden, but 10-XG-VD is an existing license plate and should be allowed. Is this something you can update?

Thanks for the issue. Will fix this ASAP. 😄

Some clarification: xS-Dx-nn, xS-Sx-nn, nn-xS-Dx and nn-xS-Sx are all blocked but should be (and are) allowed, for example JS-DF-11 and 10-XS-SX.
Also the blocks for abbreviations for political parties have been set after the licence plates have been issued and people started to complain. For example the package blocks the use of VVD but 14-VVD-4 is a valid registration of a VW Transporter.

@brinkie If there are cars that include abbreviations of politcal parties, they should not be in the forbidden word list. Do you agree?

@brinkie @stolktech Could you check out https://github.com/niels-bosman/license-plate/pull/6?

@brinkie @stolktech You can use version 1.5.2, bug is fixed there.


Deprecated submodules

v0.48 deprecated all submodules. All objects are now exposed in the top level griffe module. The recipe should therefore be updated, notably build.entrypoints and tests.imports. The submodules will be removed in v1 so the recipe would fail then ^^

Thank you for the notice! I saw that in 0.48 and will create a local update and ensure it all packages correctly. It’ll take me a day or two to do that. Thanks!

Perfect, thank you! And there is no rush, take all the time you need :slightly_smiling_face:


Fix typo in oci_go_image example

Type of change

Documentation (updates to documentation or READMEs)

Encountered when following the example: no such attribute 'repotags' in 'oci_tarball' rule (did you mean 'repo_tags'?)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Will follow up with something more complete.


Added .gitignore for build folders under customer_app

I had to come up with a small one-liner in bash in order to do this, I'm leaving this here for future reference;
for i in $(ls); do; touch $i/.gitignore; (echo build_out > $i/.gitignore); done;

I believe that this small change will make development significantly less frustrating. All of the Makefile files inherit from include $(BL60X_SDK_PATH)/make_scripts_riscv/project.mk, so although I only tested whether the output directory was the same for bl602_boot2, bl602_boot2_mini, bl602_demo_at and bl602_demo_event (as well as sdk_app_helloworld, just to be sure), the output folder should always be build_out for every app under customer_app.

Add the folder to the global one, there's absolutely no need to place it each and every directory.

Understood.

I just thought that it was more appropriate to do that with every single individual folder, since they concern different codebases and because I didn't want to assume that the output folders are always build_out across the repository, which seemed volatile from my perspective as far as this thing is concerned.

It might be a bit more volatile, but it's a single place to keep track of, updating ten .gitignores on makefile change or when a new example is added is a bit more error-prone and fragile.

@panos Thank you for your pull request. Even the PR was closed, it was still applied, but bit different, so you can apply for the FREE EVB.
For receiving the free PineCone, please sign up at this link.
(If there will be any issues with signing up, please let me know here).

Fair enough, I'll push a few more pull requests and request for it in a bit. @gamelaster
Thanks a lot! :D


C++

[Enter feedback here]

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

ID: 559d48f6-eb99-a0b5-b7fc-9051b23dafd9
Version Independent ID: db20780c-a332-ef6b-1b77-9d3a6fd83342
Content: Install cross-platform mobile development with C++
Content Source: docs/cross-platform/install-visual-cpp-for-cross-platform-mobile-development.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

C++

This feedback doesn't seem actionable. If there's something in the documentation that needs attention, feel free to respond with more details on what you think is missing or incorrect, and I'll reopen the issue.


Make tensorflow optional on windows to adhere to conda-forge policies

xref: https://github.com/conda-forge/conda-forge-ci-setup-feedstock/pull/339
Closes #68
Closes #67
xref: https://github.com/conda-forge/caiman-feedstock/issues/69
Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

I think this would mean that the Windows package would be essentially broken; this isn't a great route forward for us.

I think this would mean that the Windows package would be essentially broken; this isn't a great route forward for us.

Your windows instructions would have to be updated to be
mamba install caiman tensorflow

I know it is not ideal, but maybe it is a helpful step. i'm not sure.

Unfortunately:
A) there are downstream packages (and we're refactoring caiman soon to split the jupyter/bokeh/.. bits out to make it easier to embed so we expect more); making them manually think about our dependencies is not that workable
B) We really don't want users to build a memory of using tensorflow as we're moving to torch soon
C) It's nice to us to really have a siingle package - our package - be the only thing users need to install to get a fully working piece of software.
I get that if the diff discussed elsewhere lands, the package will be broken and unbuildable, but in that case we probably would not be continuing to publish it to conda-forge and would need to explore making a separate channel that  hopefully would let us have dependencies on both defaults and conda-forge.

I think nose is not compatible with python 3.12.
In either case, this is an "idea" that you can you use to get your package building.
Today, your latest packages were not build on windows. So your users don't have 1.11.3

Not true. There is a windows build of Caiman 1.11.3 for python 3.10

Not true. There is a windows build of Caiman 1.11.3 for python 3.10

applogies you are correct.


fix missed order on locking plugin channels

Unlocking an unlocked mutex is applying some issues when the server need to register their plugin channels, like WorldEdit or something else.

Thank you @luiz-otavio!


question

mod version- 1.12-6.340
minecraft version- 1.12.2
forge version - <IP_ADDRESS>59
how can i make docks...everytime my ship gets close to something it is all slow and can't get close to things.
Edit: seems to work when using anchor points but now for some reason when aligning linked anchor points my ship is up above the ground anchor floating in the sky rather than aligning to the side of it like I want.

I wrote a part of the anchoring wiki in 1.7.10 please have a look, if that solve your problem. I had a hard time to figure out how anchoring works, so i wrote down my steps, that worked.
https://github.com/elytra/DavincisVessels/wiki/Blocks---Anchor


Replace stringN type names with string<N>

What is wrong?
The parser will parse string<100> etc as a TypeDesc::Generic, so it's time to retire the old string100 syntax in favor of the const generic style. We should also do bytes<N>, if we're keeping the bytes type. (See #258)
How can it be fixed

Yeah, would be nice to retire the string100 syntax, the (limited, builtin) const generic style of string<100> would be a nice thing to show off on the website :heart_eyes: when it launches soon :upside_down_face:

Lets make this String<N> instead of string<N>.

The complicated part of this is that the generic syntax will have to be allowed in a type constructor call, eg x = String<10>("hello"), which adds ambiguity to expression parsing. String<10>("hello") will currently be parsed as (String < 10) > "hello". We'll run into the same issue if/when generic functions are supported, assuming the type parameters can be specified explicitly. f<T>(10) or (f<map<u8, foo>>(x)) (is it a tuple or a generic fn call?)
This ambiguity is the reason for rust's "turbofish" syntax. However, I think we should take the approach outlined in this RFC: https://github.com/varkor/rfcs/blob/undisambiguated_generics/text/0000-undisambiguated-generics.md Basically, just resolve the ambiguity in favor of generics (and probably disallow chained comparisons while we're at it). This will add complexity to the parser, but I think that's better than adding the ugliness of the turbofish to the language.
Here's a summary of the crazy discussion thread that the rfc spawned: https://github.com/rust-lang/rfcs/pull/2544#issuecomment-453653184
Note that I haven't entirely read either of those links, but I think the general sentiment among the rust lang team was to accept the rfc (before the conversation derailed and was closed), and my inclination is to follow their lead.


init_blocks vs min_blocks

Describe the bug
init_blocks vs min_blocks is not well defined when using the simple strategy:
When a DFK starts and has no tasks, should it have min_blocks blocks or init_blocks blocks?
Should it launch init_blocks blocks? and then immediately scale up/down to min_blocks? After 5 seconds?
The current strategy code does not perform any scaling if an executor has no tasks, which means that min_blocks will not be enforced in a period of no task activity - see this case 1a which explicity allows fewer than min_blocks: https://github.com/Parsl/parsl/blob/6784355ebdcaef4bc97aeebf605d399919d3c2a7/parsl/jobs/strategy.py#L227

Yeah, for active blocks greater than min blocks with no tasks, it scales in to min blocks. Now it maintains the min blocks for the flow, ideally if we are launching init_blocks less than min_blocks, we expect it to scale out (min_blocks - init_blocks) blocks, but it ignores and taking no action. And even for htex_auto_scale, this happens that is not scaling out. Do we have to scale out to maintain the minimum blocks? If yes, why? Dont it be addition of resource for no tasks??


Bugfix: zap Uyuni specific varying parameters

This enables some Uyuni workloads such as channel changes.

Thanks @chiaradiamarcelo, I changed the style a bit to match _immutable, tested this once again and everything works as expected now. Merging!


Add auto discovery for GuzzleClient

Q
A

Bug?
no

New Feature?
yes

Actual Behavior
If you want to use this Adapter, then you have to instantiate the Guzzle Client and pass through the constructor.
Expected Behavior
Use the php-http/discovery package to auto discover the Guzzle Client and create it.
Possible Solutions
Add the php-http/discovery package as requirement.
Add documentation.

Hi @aferrandini,
I am a little bit confused, because it seems to me the constructor parameter is optional: https://github.com/php-http/guzzle6-adapter/blob/master/src/Client.php#L28
Also, there is a little bit of confusion on your side too: the discover layer is meant for clients implementing the HTTPlug interfaces or one of the Message Factory interfaces. We are aiming for zero configuration, hence you can instantiate most of our adapters without constructor parameters.
Are there any concrete errors you met which led you to creating this issue?

Hi @sagikazarmark,
If you want to use the Guzzle Adapter, you have to instantiate Http\Adapter\Guzzle6\Client, but using the discovery package, you only need to call the find method and this will return the Guzzle6 Client instance.
I think the Adapters and Clients should use the discovery package to be able to plug and unplug an adapter or a client without changing anything in the code.
Current usage
$client = new Http\Adapter\Guzzle6\Client();

Expected usage
$client = $httpClient = HttpClientDiscovery::find();

I am sorry, I still don't get your point. Http\Adapter\Guzzle6\Client implements HTTPlug interfaces (and holds an instance of Guzzle 6 internally). HttpClientDiscovery finds implementations of these interfaces. So as I can see, discovery already works as you described it.

Yes, but you have to add the discovery package instead of being a requirement for the adapter package.
Using curl-client you don't need to add the discovery package, because it's included as a requirement.
Curl client composer.json
...
    "require": {
        "php": "^5.5 || ^7.0",
        "ext-curl": "*",
        "php-http/httplug": "^1.0",
        "php-http/message-factory": "^1.0.2",
        "php-http/message": "^1.2",
        "php-http/discovery": "^1.0"
    },
...

Guzzle6 Adapter composer.json
...
    "require": {
        "php": "^5.5 || ^7.0",
        "php-http/httplug": "^1.0",
        "guzzlehttp/guzzle": "^6.0"
    },
...

Okay, now I see.
The Curl client requires the discovery package because it actually uses it: https://github.com/php-http/curl-client/blob/master/src/Client.php#L80-L81
The discovery package is a convenience layer to allow zero configuration, but the recommended way to create clients is dependency injection.
Also, the discovery package is a dependency of your code, not the clients themselves. As such, you have to install it separately. This might be a little bit inconvenient, but it's the proper way: adding discovery as a dependency to each client is not a good idea. Also, you cannot rely on discovery being available by just installing a client. So in the end you have to add it as a requirement anyway.

Okay, I see, so the idea is to remove the discovery and use the client or adapter with DI when possible.
In this case, I'm going to close the issue :)
Thanks so much for the explanation.

No problem.
Generally Discovery is useful for libraries consuming HTTP clients: API clients for example.
See this example:

use Http\Client\HttpClient;
use Http\Discovery\HttpClientDiscovery;

class ApiClient
{
    private $httpClient;

    public function __construct(HttpClient $httpClient = null)
    {
        $this->httpClient = $httpClient ?: HttpClientDiscovery::find();
    }
}

We also try to provide as much framework integrations as possible so that you don't even have to code to configure a client. Symfony bundle is already out, Laravel package is in progress.

This example is perfect, it should be on the documentation ;)
I was asking for adding discovery because we're moving an API client with it's CURL integration to HTTPlug :)
Thanks for all the work

@aferrandini yes, this should definitely be somewhere in the docs. See https://github.com/php-http/documentation/issues/148
If you want to see a better example see this workshop material @dbu and me will present at WebSummerCamp:
https://gitlab.com/dbu/http-client-workshop

Thanks ;)


chore: remove decentraland-rpc and publish scene runtime systems

What?

Remove decentraland-rpc from this repository, it was not part of the CI and it was not included as a direct dependency in any project.
Publish cli.scene.system.js and scene.system.js in the package decentraland-ecs, those will be used by the node debuggers.

Why?
Housekeeping and unlocking remote debugger.

Added to the PR description


New Guids ignore "Remove Dashes" checkbox

On the Guids page, if I check the "Remove Dashes" checkbox the current Guid has its dashes removed, but if I leave the checkbox checked any subsequent Guid I generate still have dashes.

I was hoping nobody would notice yet :p
Need to fix the logic.
Think the “Add braces” is broken too depending on order of clicks.


Translate the Contribute, Help, and About pages to English (English Version)

Translation work only

[x] contribute
[ ] help
[ ] about

/aide/ => /help/
/contact/ => /contact/
/a-propos/ => /about/
/mentions-legales/ => /legal-mentions/
/cgu/ => /tos/
/vitesse-navigation/ => /browser-speed/
/vie-privee/ => /privacy/
/apparition/ => /appear/
/probleme-apparition-bulles/ => /problem-posts-appearing/
/desinstaller/ => /uninstall/
/evolutions/ => /changelog/
/financement/ => /financing/
/comparaison-autres-rs/ => /comparison-other-social-networks/

Hi @gregoirelacoste, please find the site translation file I used here:
https://docs.google.com/spreadsheets/d/15C0iGpPKjOzJu1bL0RyHtgTDG4NHHfKcYnXZC0yeFGE/edit#gid=680384296
Green tabs are translated pages, Red tabs are not. I think we have about 15 pages translated and about 8 remaining. Done this about 6 weeks ago, so this is based on the french copy that was on site 6 weeks ago, dont know if anything changed after that. Better check with Karène. The pages not yet translated are mainly the legal ones. Hope that helps.
I am also suggesting updating the site structure (in French and in English) and EN slugs slightly. I will add this in another ticket and we can discuss.


Associate transitions with approprate action state

whereas currently those are just "dangling" transitions

Awesome. Thanks Dima!


Lazily compute row and column roots when repairing the square

When repairing the square, we are currently generating roots of each column and row even if there is nil data in that row or col. This is a problem because because if the underlying tree doesn't know how to handle nil values, then it has no choice but to panic. While there are quite a few ways to fix this, I think the fastest way would be to only compute the root of columns and rows that have no nil values. In the context of RepairDatasquare, this means having the ability to generate roots of single columns and rows.
This must be fixed before #235 and #232 can be completed.

While there are quite a few ways to fix this, I think the fastest way would be to only compute the root of columns and rows that have no nil values. In the context of RepairDatasquare, this means having the ability to generate roots of single columns and rows.

That sounds good to me. Do you mind drafting a minimal PR (without tests etc) to see how this would look like in code? At least it sounds like a relatively simple change.

I cheated and wrote the code before the issue :smile: #18


Namespace Specific ValidationFailureAction

Closes #410
Signed-off-by: Kumar Mallikarjuna<EMAIL_ADDRESS>

Can we close this out, please?

@chipzoller - Added inline comments to the example YAML. Is this what you meant?


Rephrasing UC4 and UC5 in MG

I wonder if it makes more sense to merge UC4 and UC5 into one UC saying what the goals are. Alternatively, instead of saying "the" goal, these UCs should say "a" goal, since there are more than one. Regardless, the word "another" should be removed; as is it is grammatically incorrect, but even if it was reworded, it doesn't really contribute much.

Ok


flutter doctor can't find android studio when the name is changed

I'm a Android developer. Use Android studio 3.4，Mac OS
But the flutter doctor cannot find my android studio because I had chang it's name to 3.4.
When I read "flutter/packages/flutter_tools/lib/src/android/android_studio.dart", i found doctor depends the software name to check it has installed,can change this to depends “Info.plist” or other fun ?

Reading the Info.plist of every application would be much slower than scanning the file names. lsregister bundle ID checking could work, but that would add a fair amount more complexity to handle this edge case.
Is there a reason you don't just rename it "Android Studio 3.4" (I'm assuming the goal here is to have multiple versions) so that the check still passes?

@stuartmorgan  Yeah,I have multiple versions and when i rename it to "Android Studio 3.4","flutter doctor" also can find it.
But just relying on the file name to determine if it exists is not accurate. It is not friendly to other developers who rename it to other strings that do not start with "Android Studio."

The way we're handling this for the web tools is that we check in specific places and for specific file names, but we also allow you to provide your own via an environment variable (described in the doctor). This lets us handle the 95% of cases automatically while still giving people to customize it.
That seems like a reasonable approach to take here

@Super-Crab you can set a custom Android Studio path via flutter config --android-studio-dir /path/to/android/studio. Closing this issue!


use WebComponentsService.php for getting polyfill / head matter

This will make cdn / publishing targets easier to build

also expand its capabilities to match what elmsln has w/ an array of items added to build

not possible given how much the routine is specific to haxcms. I should update how that library functions to support the new, hit all screens capabilities of haxcms, though its still not generalizable.


Write section container guidance

What is the purpose of the work?
Guidance and code example of ic-section-container needs to be added.
Need design consultation on what should be written and what examples should be included
Why do we need it?
So that users understand how to utilise this component correctly

Written updates section container guidance. It can be found in the internal file share under 'Design work/Guidance/Section Container/..'. Images can be exported from Figma guidance site assets file.


Issue with second level of breadcrumb not using APP_URL

Laravel Version: 5.3.30
Voyager Version: 0.11.7
PHP Version: 5.6.19
Database Driver & Version: MySQL 5.7.11

Description:

Breadcrumbs beyond the first level do not appear to be using env('APP_URL')

Steps To Reproduce:

Visit localhost/path/to/voyager/roles/create

Click on 'Roles' (second level) breadcrumb and the link will be wrong

I don't believe the breadcrumbs should be using APP_URL that way.  I agree that something isn't correct since you're in a subdirectory and the links aren't representing that.  I'm inclined to believe the issue might be in your configuration though.  Unfortunately I don't have a recommendation on how to fix it at the moment.

Should each breadcrumb not be based on its parent? This clearly isn't happening.
Can you tell me what configuration option you believe may be causing the issue?
Here is my Voyager config - perhaps that will give you some insight in order to find a solution to this issue.

The majority of it is straight out the box.

<?php

return [
    /*
    |--------------------------------------------------------------------------
    | User config
    |--------------------------------------------------------------------------
    |
    | Here you can specify voyager user configs
    |
    */

    'user' => [
        'add_default_role_on_register' => true,
        'default_role'                 => 'user',
        'namespace'                    => App\Models\User::class,
        'default_avatar'               => 'users/default.png',
    ],

    /*
    |--------------------------------------------------------------------------
    | Controllers config
    |--------------------------------------------------------------------------
    |
    | Here you can specify voyager controller settings
    |
    */

    'controllers' => [
        'namespace' => 'TCG\\Voyager\\Http\\Controllers',
    ],

    /*
    |--------------------------------------------------------------------------
    | Models config
    |--------------------------------------------------------------------------
    |
    | Here you can specify default model namespace when creating BREAD.
    | Must include trailing backslashes. If not defined the default application
    | namespace will be used.
    |
    */

    'models' => [
        'namespace' => 'App\\Models\\',
    ],

    /*
    |--------------------------------------------------------------------------
    | Path to the Voyager Assets
    |--------------------------------------------------------------------------
    |
    | Here you can specify the location of the voyager assets path
    |
    */

    'assets_path' => env('APP_URL', '//localhost/') . 'vendor/tcg/voyager/assets',

    /*
    |--------------------------------------------------------------------------
    | Storage Config
    |--------------------------------------------------------------------------
    |
    | Here you can specify attributes related to your application file system
    |
    */

    'storage' => [
        'disk' => 'public',
    ],

    /*
    |--------------------------------------------------------------------------
    | Database Config
    |--------------------------------------------------------------------------
    |
    | Here you can specify voyager database settings
    |
    */

    'database' => [
        'tables' => [
            'hidden' => ['migrations', 'data_rows', 'data_types', 'menu_items', 'password_resets', 'permission_role', 'permissions', 'settings'],
        ],
    ],

    /*
    |--------------------------------------------------------------------------
    | Multilingual configuration
    |--------------------------------------------------------------------------
    |
    | Here you can specify if you want Voyager to ship with support for
    | multilingual and what locales are enabled.
    |
    */

    'multilingual' => [
        /*
         * Set whether or not the multilingual is supported by the BREAD input.
         */
        'bread' => false,

        /*
         * Select default language
         */
        'default' => 'en',

        /*
         * Select languages that are supported.
         */
        'locales' => [
            'en',
            //'pt',
        ],
    ],

    /*
    |--------------------------------------------------------------------------
    | Widgets Config
    |--------------------------------------------------------------------------
    |
    | Here you can specify voyager administration settings
    |
    */

    'widgets' => [
        [
            'name'  => 'User',
            'icon'  => 'voyager-group',
            'model' => TCG\Voyager\Models\User::class,
            'url'   => 'admin/users',
            'image' => '/images/widget-backgrounds/02.png',
        ],
        [
            'name'  => 'Post',
            'icon'  => 'voyager-news',
            'model' => TCG\Voyager\Models\Post::class,
            'url'   => 'admin/posts',
            'image' => '/images/widget-backgrounds/03.png',
        ],
        [
            'name'  => 'Page',
            'icon'  => 'voyager-file-text',
            'model' => TCG\Voyager\Models\Page::class,
            'url'   => 'admin/pages',
            'image' => '/images/widget-backgrounds/04.png',
        ],
    ],

    /*
    |--------------------------------------------------------------------------
    | Dashboard config
    |--------------------------------------------------------------------------
    |
    | Here you can modify some aspects of your dashboard
    |
    */

    'dashboard' => [
        // Add custom list items to navbar's dropdown
        'navbar_items' => [
            'Profile' => [
                'route'         => 'voyager.profile',
                'classes'       => 'class-full-of-rum',
                'icon_class'    => 'voyager-person',
            ],
            'Home' => [
                'route'         => '/',
                'icon_class'    => 'voyager-home',
                'target_blank'  => true,
            ],
            'Logout' => [
                'route'      => 'voyager.logout',
                'icon_class' => 'voyager-power',
            ],
        ],
        'data_tables' => [
            'responsive' => true, // Use responsive extension for jQuery dataTables that are not server-side paginated
        ],
        'widgets' => [
            'TCG\\Voyager\\Widgets\\UserDimmer',
            'TCG\\Voyager\\Widgets\\PostDimmer',
            'TCG\\Voyager\\Widgets\\PageDimmer',
        ],
    ],

    'login' => [
        'gradient_a' => '#fff',
        'gradient_b' => '#fff',
    ],

    'primary_color' => '#22a7f0',
];

+1

Laravel Version: 5.4
Voyager Version: 0.11
PHP Version: 5.6
Database Driver & Version: Postgres

I have the same issue too, the second level of breadcrumb not using correct url
Main menu with correct URL

Second level of breadcrumb with incorrect url

@abolinhas, it looks like your laravel installation is set up insecurely.  I recommend reading up on "how to install laravel on shared hosting", as well as the laravel documentation.  For example, if you leave your install as-is, you'll be able to access the .env file through the Web browser.

@fletch3555: that's been a month since I posted my configuration which you believed was the problem and you gave me no reply.
Are there no further suggestions on what the issue might be and possible solutions?
That is now 2 of us seeing the problem!

@u01jmg3, I apologize for the delay, but you have to understand that this is an open source project, and none of us are getting paid to do this.  We all have jobs that we do get paid for and therefore must give preference.
For your issue, you mention localhost/path/to/voyager, so I imagine you have laravel installed in such a way that it would look similar to http://localhost/voyager/public.  As I mentioned in my previous post, this is a very insecure setup, and we can't support it that way.  If this is not the case, please let us know and we can attempt to troubleshoot it.  For faster response, you're welcome to join our slack group (instructions in the readme).
One final note. You mentioned that I said "it was your configuration" and posted your voyager config file.  What I meant by that statement was that it's something with how you have laravel or voyager configured, not necessarily just that one config file.  Web server configuration would also apply, which is why I'm pushing best practices there.

Hi,
I already protect my installation, thanks for the advise.
But I still getting the issue..
A quick fix is adding the missing part of path in navbar.blade.php
Like this
@if($i < count(Request::segments()) & $i > 0)

{{ ucwords(str_replace('-', ' ', str_replace('_', ' ', Request::segment($i)))) }}

I apologize for the delay, but you have to understand that this is an open source project, and none of us are getting paid to do this. We all have jobs that we do get paid for and therefore must give preference.

I do - I too run a busy open source project but try not to leave people hanging for too long without a resolution.

For your issue, you mention localhost/path/to/voyager, so I imagine you have laravel installed in such a way that it would look similar to localhost/voyager/public.

I have not even got as far as deploying to a production environment. I simply have an out of the box Laravel 5.3 install with the latest version of Voyager on my local machine. I followed the instructions on how to configure Voyager and ran into this issue straight off the bat. My setup does mean that I have a URL such as localhost/repositories/project/public/admin/voyager but I assumed Voyager would be able to handle this.

As I mentioned in my previous post, this is a very insecure setup, and we can't support it that way. If this is not the case, please let us know and we can attempt to troubleshoot it. For faster response, you're welcome to join our slack group (instructions in the readme).

What do you suggest instead? Provided routes are guarded by authentication and only necessary files are in public, I do not see how this is 'very insecure'?

One final note. You mentioned that I said "it was your configuration" and posted your voyager config file. What I meant by that statement was that it's something with how you have laravel or voyager configured, not necessarily just that one config file. Web server configuration would also apply, which is why I'm pushing best practices there.

Everything is box standard. Fresh installs of Laravel and Voyager, and WAMP with PHP 5.6.19. The only difference in my setup is Voyager isn't at localhost/voyager.

Looking at the code in navbar.blade.php the fix looks like changing $breadcrumb_url = ''; to be $breadcrumb_url = Request::root();.
Shall I submit a PR?

@u01jmg3 your solution works very well.

I think it is worth adding u01jmg3's solution. I do agree that in production you probably would not run Laravel in a sub-directory, but you may well in development (or when evaluating). And anything that makes the product look broken to anyone evaluating it needs to be addressed.

Will this be fixed? If not, why is this?

This has been fixed in 700e021


ARROW-5393: [R] Add tests and example for read_parquet()

This PR also sets the ARROW_R_WITH_PARQUET feature flag to on for all installation methods.
A future patch should add write_parquet() and align these functions with read/write_feather() and any other file reader/writers.

@nealrichardson Can you use the same parquet files we also use for C++? There is a git submodule that brings them all in.

@xhochy I don't think that's necessary. Here we just want a small file we can use for an end-to-end test and to use in documentation examples. (FWIW, I copied this file from the pyarrow test suite.) The purpose is not to add R integration tests against every funky Parquet file out there--I'll trust that those are covered in the C++ tests, and if parquet-cpp can make an Arrow Table out of a Parquet file, then the R package can handle it because it can work with Arrow Tables.

Hm, we're really trying not to check binary files into the codebase. In the event that a binary file is needed (e.g. to exercise some scenario that we are unable to produce dynamically) then we use either the arrow-testing or parquet-testing repos
The best scenario is to write a new file as part of the unit test

I agree that we should generally avoid adding binary files, but this one is only 4k and already exists (along with others) in https://github.com/apache/arrow/tree/master/python/pyarrow/tests/data/parquet, so it didn't seem like a big deal. write_parquet() doesn't yet exist in R, so I can't write a file and then prove that we can read it back in.
The other reason I included it is for use in an example in the docs. R package documentation is expected to include executable examples (in fact, CRAN will reject packages that have no examples, which we'd probably hear about if we could get past the Linux build issue), and it is customary to include example datasets in packages. I guess the example could write a Parquet file (once that's supported) and read it back, but that's not a very clean example.

I think it's OK in this particular case but we should avoid adding many more files

Roger that. Thanks for the dispensation.


asm-lsp: 0.4.2 -> 0.6.0

Description of changes
Updates asm-lsp from 0.4.2 to 0.6.0
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 275471 run on x86_64-linux 1

1 package built:

asm-lsp


DllNotFoundException during prediction

VS version- 16.10.4
Model builder version- <IP_ADDRESS>.1904
I am using ml.net in xamarin.

@Hrishikesh46779 Sorry you ran into this problem. Can I get some more information?

VS Version
Model Builder version (available via Manage Extension dialog)
Is this a .NET Core or Framework project? Can I get the version.

Thanks!

@Hrishikesh46779 we just shipped a new version. Can you update and try again? https://marketplace.visualstudio.com/items?itemName=MLNET.07

Closing this issue. Please reopen if you're still having problems. Thanks!


probably MTU issue in an IPV6-only environment using BGP to announce externalIPs

Is there an existing issue for this?

[x] I have searched the existing issues

Version
equal or higher than v1.16.0 and lower than v1.17.0
What happened?
I am currently struggling with Cilium 1.16.2/k3s 1.30.5 in an IPv6 only environment. From the observations it looks like a MTU issue.
I was advised in the slack channel #kubernetes open an issue (https://cilium.slack.com/archives/C53TG4J4R/p1729629825447759)
Data dumps and config files are in the text field to reproduce the issue.
Node and CNI Networking generally works.
So node to internet, node to node, pod to internet, pod to svc, pod to pod works.
I have setuped route reflector (using eBGP different ASNs).
I like to annouce externalIPs via BGP. I deployed a SVC which I patched to have the external IP fd64::1. Announcement and traffic routing works as expected. All MTUs on path are 1500.
unfortunatly accessing the service e.g. with curl does not work if the content is "larger".
the tcp connection just stalls.
If I manually apply
mtu 1492 to the route announced like:
fd64::1 via fe80::XXXX dev eth0 mtu 1492

it just works.
Connecting to the services on the node IPs itself does work, too.
Using kubectl/k9s port forwarding it works also.
You can see the packet sizes in a tcpdump:
In a perfect world packet sizes would start low and increase to 1500, during the transfer of the tcp connection.
In the broken case: 1500 is never reached, no packets emitted from the cilium node on the external interface (eth0) of the node anymore.
(-i any does not show packets on other interfaces, too)
If I set MTU 1492 you see the packet size increase  to 1492.
Additionally I tried to patch the cilium-agent DaemonSet to force MTU 1492 with no success:
  ...
  containers:
  - name: cilium-agent
    args:
    - --config-dir=/tmp/cilium/config-map
    - --mtu=1492
    command:
    - cilium-agent
  ...

So I assume from the observations a wrong MTU is selected.
Where can I look to narrow this further down and get it working?
How can we reproduce the issue?
Not a straight reproducer:
Each node of the cluster has only on interface with MTU 1500, only with one ULA and LL address on it.
The cluster has been bootstrapped with:
bgp:
  enabled: false
bgpControlPlane:
  enabled: true
bpf:
  hostLegacyRouting: false
  lbExternalClusterIP: true
  masquerade: false
debug:
  enabled: false
enableIPv4BIGTCP: false
enableIPv4Masquerade: false
enableIPv6BIGTCP: true
enableIPv6Masquerade: false
externalIPs:
  enabled: true
extraConfig:
  enable-ipv6-ndp: 'true'
  ipv6-mcast-device: eth0
  ipv6-service-range: fd64:6443:0:1:5::/112
hostPort:
  enabled: false
ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv6MaskSize: 112
    clusterPoolIPv6PodCIDRList: fd64:6443:0:1:c::/96
ipv4:
  enabled: false
ipv6:
  enabled: true
k8sServiceHost: fd23::314:1
k8sServicePort: 6443
kubeProxyReplacement: true
nodePort:
  enabled: false
operator:
  replicas: 1
routingMode: native

These are the cilium resources for creating peerings per node:
kind: CiliumBGPClusterConfig
metadata:
  name: "bgp-rr"
spec:
  # TODO:
  #  * kubectl label nodes tpn1 cilium.bgp=true
  #  * kubectl annotate node tpn1 --overwrite cilium.io/bgp-virtual-router.65179="router-id=<IP_ADDRESS>"
  #  * kubectl annotate node tpn2 --overwrite cilium.io/bgp-virtual-router.65179="router-id=<IP_ADDRESS>"
 # ...

  nodeSelector:
    matchLabels:
      cilium.bgp-speaker: "True"
  bgpInstances:
  - name: "rr"
    localASN: 65179
    peers:
    - name: "rr"
      peerASN: 64179
      #peerAddress: fd23::314:bc
      peerAddress: fe80::bc%eth0
      peerConfigRef:
        name: "rr"

---
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPPeerConfig
metadata:
  name: "rr"
spec:
  gracefulRestart:
    enabled: true
    restartTimeSeconds: 15
  families:
  - afi: ipv6
    safi: unicast
    advertisements:
      matchLabels:
        advertise: "cilium.bgp-speaker"

---
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
  name: "bgp-advertisements"
  labels:
    advertise: "cilium.bgp-speaker"
spec:
  advertisements:
    - advertisementType: "Service"
      service:
        addresses:
          - ExternalIP
      selector:
        matchExpressions: # []
          - { key: "bgp-advertise", operator: "In", values: [ "True" ] }

Patch/snippet: for a service to assign fd64::1 to an service.
apiVersion: v1
kind: Service
metadata:
  name: argocd-server
  labels:
    bgp-advertise: "True"
spec:
  externalIPs:
  - fd64::1

Cilium Version
root@tpn1 | /opt/cilium > cilium version -n cilium
cilium-cli: v0.16.18 compiled with go1.23.1 on linux/arm64
cilium image (default): v1.16.1
cilium image (stable): v1.16.3
cilium image (running): 1.16.2
Kernel Version
Linux tpn1 6.1.0-1025-rockchip #25-Ubuntu SMP Mon Aug 26 23:01:14 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
...
 Please add yourself to the Users doc

Code of Conduct

[x] I agree to follow this project's Code of Conduct

Update: the same happens with Cilium 1.16.3

If an MTU of 1492 works, then that likely means you are going over a PPPoE tunnel somewhere which is limiting your path from 1500 to 1492.
I am honestly not sure why setting the MTU on the route works, since the TCP handshake happens inside the pod network namespace which is unaware of this route. It might be because the host network namespace acts as a router that it modifies the requested MSS since it itself is also in the path.
Setting the MTU via the Cilium should work. The thing is that in v1.16 you still need to re-create the pods before it starts taking effect, as MTU is only configured when the pod is created. So you might need to give that a try.
Its not entirely clear which packets in which direction are dropped where. Could you explain this a bit furter? Are packets from curl to argocd dropped or reply traffic from argocd to curl? Did you spot any "Packet to big" ICMPv6 messages? Normally, when the MTU is exceeded like this a ICMPv6 is sent back to the sender which is a signal to send smaller packets. Cilium should handle these, though some network admins tend to block these since they don't understand them and are afraid of network attacks, which doesn't help.

Thanks for the hint that setting the MTU in the ds/cilium requires all pods to be restarted.
So I must correct myself:
--mtu 1492 or via Helms values MTU: 1492
Regarding you assumption that there might be pppoe involved: this is not the case:
L3 segment clients has MTU=1500
L3 segment, intermediate has MTU=1500
L3 segment, k3s+cilium cluster has MTU=1500

ICMPv6, Packet to big packages I did not find
I will add more details about network flows/data in a seperate post.


analyzer: own variable not appearing in autocompletion

fixed in https://github.com/vlang/vls/commit/e694bb236093ebc231d68f7af2064bb5faea6826


CLUSTER_REDIR_UNSTABLE error should be retry

We should also try again when the error is CLUSTER_REDIR_UNSTABLE.
https://github.com/redis/redis/blob/380f6048e0bbc762f12fa50b57b73cf29049f967/src/cluster.c#L5838-L5840

Thanks


Exclude folders

Hello,
First, thanks for your middleware it helps me a lot.
I would like to know if it was possible to exclude folders from the transpilation ? I would like to exclude the webapp/test/ forlder.
Regards,
Joseph

Hi Joseph,
I've updated the package now with an exclude option. You can exclude folders here. Just comma separate them if you want to add more.
Do you think a exclude files is needed?
Please pull the latest package and test it out. If you are happy please close the issue.

Very nice, I will test it in the next few days. I will tell you the result.
Thanks for the quick action.
Regards,
Joseph

Did you have any success?

closing this issue


⚠ Processors has degraded performance

In 8f422a5, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 47 ms

Resolved: Processors performance has improved in f5d68eb.


hi issue 5.04 vs 4.74

i have organised a Destiny tournament and the results from 5.04 version isn't the same whith the 4.74
i think the 4.74 is the good results

Which one is which?

I figured it out. I'll be posting the update soon. Thanks for the report!

Fix submitted in 5.0.5. Give it a look and let me know what you think. Note, the decimal values in Ext SoS are slightly different, but the ranking should be correct.

thanks whith the same .sav e file the ranking is good this time !


Ability to save tabs in a project. (Your Collections feature?)

Not sure if this is something that's already been implemented or not but it would be nice to be abe to load a set of tabs or a tab from an existing set of tabs that are associated with a project. I was trying to understand what collections are but the UI doesn't seem very intuitive if that solves my issue.
Here are some example screenshots from Postman as an example of what I'm expecting:

See the "+ New Collection" button?
Also not sure if you support this or not because I haven't been able to create a new collection yet but looks like variables are also project dependent. See this screen shot:

I'm pretty sure the Collections side bar is the solution but I didn't see any way to create a NEW collection, only to import them. I'm expecting a way for me to create a NEW collection with the tabs I have open or be able to save a tab to a collection.

Hey @aarona, yes the collections feature should be what you need.

Thank you for this! I saw this save icon earlier but it didn't register to me.


Replace lists by sequences in Ortac/QCheck-STM tests

Fixes #278
This should also help #277.
I didn't change the tests for the wrapper mode as using sequences would mean supporting models (see #224)

LGTM!
Will :: be a short-hand for Sequence.cons in the revised stdlib, that removes List?
Comparing tuples.add it helps readability, IMO:
- ensures h.contents = match tup with a, b -> (a, b) :: old h.contents
+ ensures h.contents = match tup with a, b -> Sequence.cons (a, b) (old h.contents)

Sadly, I'm not sure.
It is not yet decided whether we will continue to allow importing pure OCaml value in Gospel. If so, :: will be reserved for OCaml lists. Is not, an argument can be make that allowing :: for Gospel sequences can be confusing?
But I agree that the prefix cons is not ideal.
TBH, I'm also a bit sad that we lose pattern matching too.


Make sure we strip refs/heads when exposing branch

we would not be able to use it otherwise.
Fixes #459
Signed-off-by: Chmouel Boudjnah<EMAIL_ADDRESS>
Changes

Submitter Checklist

[ ] ♽  Run make test lint before submitting a PR (ie: via pre-push github hook no need to waste CPU cycle on CI
[ ] 📖 If you are adding a user facing feature or make a change of the behavior, please make sure to document it
[ ] 🧪 100% coverage is not a target but most of the time we would rather have a unit test if you make a code change.
[ ] 🎁 If that's something that is possible to do please make sure to check if we can add a e2e test.
[ ] 🔎 If there is a flakiness in the CI tests then make sure to get the flakyness fixed before merging or if that's not possible there is a good reason to bypass it.

See the developer guide for a bit more details.

merging since we need to fix ci


Seed file + fixes

Coverage increased (+0.6%) to 68.526% when pulling 22b1d4e3ea3f0663ce3ef4e703570b7726125206 on katie7r:master into 60f472994891d52e9b0b9a587cf69f64580cfa54 on cuttlesoft:master.

Coverage increased (+1.04%) to 68.924% when pulling 294220ecd5f7514bd02fd9fa2e0ec340147a1274 on katie7r:master into 60f472994891d52e9b0b9a587cf69f64580cfa54 on cuttlesoft:master.

Coverage increased (+1.04%) to 68.924% when pulling 4bc9acccf8ada16e5cab3edc6b058051528e8b28 on katie7r:master into 60f472994891d52e9b0b9a587cf69f64580cfa54 on cuttlesoft:master.


Checksum algorithm

Currently we use SHA-256. Apparently BLAKE2 is faster and offers a similar
level of security.
Should we switch? If so, BLAKE2b would be the obvious choice (we already
optimise for 64-bit CPUs). This lets us choose the output length; what should
we use? To keep code from getting horribly complicated & much slower we want
the length to be fixed at compile-time (and preferably not via a template
parameter, though this is probably possible).

Done (switched to BLAKE2b).


HSL / HSLA as default color is not working

Describe the bug
When giving a HSL or HSLA string for the color picker it is not correctly parsed.
To Reproduce
Steps to reproduce the behavior:
See the codepen: https://codepen.io/anon/pen/dqVvLG
Expected behavior
The HSL or HSLA string input should work.
Desktop (please complete the following information):

OS: Windows
Browser Chrome
Version 68

@hcomnetworkers
Thanks for your report.
This is a bug.
I will fix this issue.

@hcomnetworkers
it is fixed.
please refer to  v1.9.21


Entity with more than 252 properties

Hi,
As we know, an individual entity from a table can have no more than 252 properties (excluding the mandatory system properties). This is a problem when creating/importing a table with more than 252 columns.
Do you know if Microsoft intends to fix this problem?
Best regards,
Evandro

As far as we know, there are no plans to fix this limitation at this time. If getting this fixed is important to you then we suggest opening feedback via the Portal, on the docs, or via a support request.


fix(build): Remove a blank line in plugin.xml

Fixes #143

Really??? Seems odd to me, but it can't hurt I guess...


feat(tail) add a tail command to follow logs

implements standard 'tail -F ' but waits for (max) 2 minutes initially for the file to appear.
The default file is './servroot/logs/error.log'.

with @eskerda's suggestion, access.log is also logged (which might be useful for non-erroring situations)

standard images do stdout/stderr but the testing framework will override this and set teh prefix to ./servroot and send the files there
Let's leave it at this now, might include access.log later, since that is more complicated as we have to wait for 2 files to appear.

Creating the files instead of waiting for them might be an option too https://github.com/Kong/kong-gojira/blob/72cd4aaebf461983ef1a858df3a23cda0bc41c00/docker/follow-log.sh#L3-L7


error in "conv_filter_visualization.py" when loading h5 file.

when running the example "conv_filter_visualization.py". There are some errors reported:
C:\Anaconda2\python.exe D:/x230/working/AI/keras/snn/examples/conv_filter_visualization.py
Using Theano backend.
Traceback (most recent call last):
File "D:/x230/working/AI/keras/snn/examples/conv_filter_visualization.py", line 98, in
for k in range(f.attrs['nb_layers']):
File "h5py_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (C:\aroot\work\h5py_objects.c:2584)
File "h5py_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (C:\aroot\work\h5py_objects.c:2543)
File "C:\Anaconda2\lib\site-packages\h5py_hl\attrs.py", line 52, in getitem
attr = h5a.open(self._id, self._e(name))
File "h5py_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (C:\aroot\work\h5py_objects.c:2584)
File "h5py_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (C:\aroot\work\h5py_objects.c:2543)
File "h5py\h5a.pyx", line 77, in h5py.h5a.open (C:\aroot\work\h5py\h5a.c:2093)
KeyError: "Can't open attribute (Can't locate attribute: 'nb_layers')"
Process finished with exit code 1
It looks like the hd5 file can not be loaded correctly.

The issue had been closed.  The h5 file includes some layer name that do not defined in network.

Could you explain how did you fixed this error please? I am having the exact same problem. Thanks in advanced.


API documentation not working

What is the Issue
The API documentation is not displaying correctly from the Travis-CI build with the TypeDoc build. There may be another type of documentation builder I can use. I will look into this later
How to duplicate the issue
Check out the docs and just navigate around the site to view the error. Look into different modules and you will see that there is nothing being displayed but if you look at the file tree on Github there are clearly files there.
Screenshots/Console output/Log files
Check the site

Fixed in pull request #12


chore: Bump kube-rbac-proxy version to v0.13.0

This PR
Update the kube-rbac-proxy to v0.13.0. The new version addresses a number of critical CVEs

Codecov Report

Merging #243 (ee88f51) into main (a35cc7e) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head ee88f51 differs from pull request most recent head 548e252. Consider uploading reports for the commit 548e252 to get more accurate results

@@           Coverage Diff           @@
##             main     #243   +/-   ##
=======================================
  Coverage   53.16%   53.16%
=======================================
  Files           3        3
  Lines         363      363
=======================================
  Hits          193      193
  Misses        156      156
  Partials       14       14

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

@AlexsJones @toddbaert could you please review this PR? The current version has a few known CVEs.

This was addressed in a separate PR


Avatar cropped incorrectly in Thorntree

From @chrissysievers on October 26, 2017 13:12
When in Thorntree, users' profile pic in the header is showing inconsistent / strange cropping. This seems to have happened when BiT was added to the global header.
To recreate:

log into your profile.
go to https://www.lonelyplanet.com/thorntree/dashboard

Copied from original issue: lonelyplanet/dotcom-profile#421

Also in https://www.lonelyplanet.com/hotels, so it means that last changes in rizzo-next do not go well with rizzo.
cc @WunderBart @laserchicken

this is actually just a css issue, not cropping - @laserchicken and I are looking at the best place to put the css to force this to display properly

This is caused by different user agent styles. Probably we use different normalize/reset.css sheets. For now it would be safest to just force border: none & padding: 0 in rizzo-next's .avatar class.

All legacy apps updated - should be good now.


Fix Code region remains highlighted when using command Unfold All Lines

Previously the handler for Unfold All Lines command only executed _unhide_all_lines which does not remove the highlighting associated with a code region. This has been replaced with a call to unfold_line for every line, which also removes highlighting along with unhiding the lines.
Fixes #83979

Your commit seems not to be linked to your GitHub account. See: Why are my commits linked to the wrong user? for more info.

Corrected it, thanks for pointing it out!

@kitbdev @tokengamedev based on your discussion in issue #83979 , I think it is sufficient to just visit every line using a loop and unfold it.

Looks like this would need to be handled in set_line_folding_enabled, as it also calls _unhide_all_lines, which would case the same issue.
At that point _unhide_all_lines would also be unused so you could remove it.

@Nirhar Would you be around to address this part? Adding new unit tests would also be good, but not critical to get this merged.


Pivot output data file

I suggest that the hvstat_data.csv file includes columns for “area,” “production,” and “yield” to reduce the size of the table. Additionally, we can consider the following options:
(a) Adding “QC_area,” “QC_production,” and “QC_yield” columns.
(b) Creating the same format but with QC_flag values, such as hvstat_flag.csv.
Personally, I lean towards option (a).

Hi @WestonAnderson, please let me know your opinion 👍

Hmmm, this is a bit of a philosophical question for the QC_flag. I'd lean towards a single QC flag that applies across production, yield, and harvested area (e.g. just a single QC_flag column). Right now we flag yield values only because it's much harder to identify spurious values of production or harvested area. A spike in production may be due to an increase in harvested area due to an economic incentive, for example. But you wouldn't expect anything really leads to significant spikes in yield outside of exceptionally low yielding systems.
But if we're QC_flagging a yield observation, and yield is calculated from area and production, then there is something wrong with one of the other two values as well. So it's probably most appropriate to have a single flag that applies across yield, harvested area, and production even if we identify it using only yield.
What do you think?

We decided to use a single QC_Flag for the current aggregation and QC approaches.
This can be expanded to QC_Area, QC_Production, QC_Yield when QC process is further developed in the future.


Change timestamp/snapshot expiry

Description

Currently, the timestamp expires every 2 weeks. If there is a key compromise, it would take clients at most 2 weeks to pick up the new key material. I propose we lower the expiration to 1 week, and consider lowering it more.
The impact of this change:

Clients need to more frequently go online to fetch the latest timestamp
Slight storage increase, since we'll generate snapshots (which are consistent, and we keep a history of previous snapshots) more frequently
Small network egress increase for the GCS/CDN TUF repo, since clients will request timestamps more frequently

This also requires updating the snapshot/timestamp GHA to run more frequently. It currently runs every week, so we would need to have it run every 3-ish days.
We also should reduce the time that metadata sits in the preprod bucket before being synced to prod. Currently we wait 3 days, then sync to prod. This would mean that a timestamp is generated, sits in the bucket for 3 days, then is valid for only 4 more days. We can reduce this time to 24 hours.
cc @bobcallaway @asraa @kommendorkapten Thoughts?

+1 to the shift to a week. On a first thought, 72 hours feels like a decent tradeoff as a long-term target for the timestamp duration.

sgtm, we meant to reduce eventually to about a day if we were confident about it :) reducing to a week is a good step now.

Would you keep the expiration of the snapshot as is?
Snapshots don't need to be regen'd when timestamps are signed FYI

Yea, I was thinking about that too. I don't think we need to update the expiration of the snapshot, it's just a little more work to split out the GHA.

Yeah, I agree - plus the timestamp files aren't "consistent" so you don't have any added storage if you just reduce the timestamp time and keep snapshot as is

This sounds all good to me, I'm in favour of lowering it to a week now, then consider lower it even more.


Fulcio/Tlog requests not traceable via -d -v

Debug and verbose options in the CLI do not seem to be covering requests made to Rekor or Fulcio.

+1! I think there's a DEBUG=1 flag in go-swagger that might work, but we should absolutely standardize this.


The user [username] was not found exception

I've recently updated my installation of WAMP to 3.0.6 (to get a more up to date version of PHP) and out of the box, the php_curl extension is enabled.
When this extension is enabled, I get an exception that the given username was not found. Disabling the extension stops the exception from occurring.
Is this to do with a conflict with Guzzle?
Laravel 5.4.21
Vinkla/Instagram 6.0

What username are you testing with?

I'm using my username: chrishjohnstone.
I think it might just be something to do with WAMP. I also have a mac development environment with LAMP running natively. Here I have the php_curl extension enabled in my php.ini and it works fine.

@chrisjohnstone yeah, sounds like it could be a problem with your environment. In the next version of this package Guzzle isn't required. We'll use HTTPlug instead to let users decide what HTTP library they want.

Yea, I think it must be.
I'll close this now.

I was still interested in why this error was being thrown. It turns out I hadn't specified the path to curl_cainfo in the php.ini.
I got the bundle from here: http://curl.haxx.se/ca/cacert.pem and saved it in my Wamp directory.

Oh, glad you solved it 👍


ColorPicker version should be same as PT

ColorPicker.exe and ColorPicker.dll versions are reported as <IP_ADDRESS> - they should reflect PT version

Fix merged


java.lang.NullPointerException: Cannot assign field "f_19802_" because "trueEntity" is null

EpicFight-18.3.8.jar
irons_spellbooks-1.18.2-<IP_ADDRESS>.jar
dawncraft-fixes-0.10.1.jar
Tested on Forge 40.1.80 and 40.2.9
Tried the latest update to fix this issue but the error persists. Any ideas?
crash-2023-06-15_20.52.33-server.txt

Ya. I'm trying to fix this issue. But seems not cover all situation

It's another issue. Not realting to the one I try to fix

That's should not happen. How can you reproduce it?

Hit any mob from Iron's spells n' spellbooks or die from them. I'm not sure which condition triggers this crash and if it only happens to mobs from this mod.

reproduce with jar in this zip and find the log line before the crash
dawncraft-fixes-0.11.0.zip

I tried reproducing again with the jar and got this:

com.llamalad7.mixinextras.injector.wrapoperation.IncorrectArgumentCountException: Incorrect number of arguments passed to Operation::call! Expected 1 but got 0.


Remove RepoPassword from kopia common args, use EnvVar instead

Change Overview
This PR removes RepoPassword from common args, and add utility to generate EnvVar instead for Kopia Repository Password.
Pull request type
Please check the type of change your PR introduces:

[ ] :construction: Work in Progress
[ ] :rainbow: Refactoring (no functional changes, no api changes)
[ ] :hamster: Trivial/Minor
[ ] :bug: Bugfix
[ ] :sunflower: Feature
[ ] :world_map: Documentation
[ ] :robot: Test

Issues

fixes #issue-number

Test Plan

[ ] :muscle: Manual
[x] :zap: Unit test
[ ] :green_heart: E2E

Added hold-off-merging label for now until all consumers of the wrappers also implement this change.

@ankitjain235 anything pending on this PR?

This is outdated now. I will raise a PR with more relevant changes.


resource_control: condition compile failpoint test

What is changed and how it works?

Issue Number: Close https://github.com/tikv/tikv/issues/14943
What's Changed:

condition compile failpoint test

Check List
Tests

No code

Release note
None

LGTM. I see many other cases also depend on failpoint but misses the feature gate, could you also add for them too?

LGTM. I see many other cases also depend on failpoint but misses the feature gate, could you also add for them too?

Like which? Other tests in failpoint dir are controlled by custom test runner which enable the failpoint automatically

LGTM. I see many other cases also depend on failpoint but misses the feature gate, could you also add for them too?

Like which? Other tests in failpoint dir are controlled by custom test runner which enable the failpoint automatically

I searched with fail::cfg and found there are somes cases under ther component backup-stream, maybe you can also fix them too

LGTM. I see many other cases also depend on failpoint but misses the feature gate, could you also add for them too?

Like which? Other tests in failpoint dir are controlled by custom test runner which enable the failpoint automatically

Ok, I found other cases are not marked with this feature gate are actually handled in cargo.toml. Never mind.

/merge

/test


Dockerfile: pick local code instead of git's main

That way, feature branches get their image for testing
Signed-off-by: Adrian Moreno<EMAIL_ADDRESS>

Accidentally merged #29, which included this patch, before merging this PR, so closing as it's already in.


Fix slow TestUsedClusterCancel test

Description

Motivation and Context

#1691
How Has This Been Tested?

[x] Covered by existing integration testing
[ ] Added integration testing to cover
[ ] Tested locally
[ ] Have not tested

Types of changes

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

TestUsedClusterCancel still most slow test (took 17.88 seconds). Can we speed up it?

TestUsedClusterCancel still most slow test (took 17.88 seconds). Can we speed up it?

Ok.. it is now 10-12s
https://109811-127937836-gh.circle-artifacts.com/0/home/circleci/junit/unit-tests.xml


New images inserted into DB but EXIF data missing and these new images never appear.

When attempting to add new images to picframe, the application will correctly identify new images to process, but the process appears to fail.
The new images appear in the database with the fname, last_modified, file_id, orientation, and exif_datetime added, but no other information is inserted despite these image files having a large amount of EXIF data.
When imported, and added to the DB, the new images are also never displayed.
The only solution is the delete the DB and have it rebuilt, but then obviously it doesn't display newly added images first, which is what I want.
Ive checked file/folder permissions, file corruption etc.
I suspect the error occurs as a result of the slow network copy operation into the Pictures folder. Watching the tail output of the log, these checks for new images were happening regularly, and thus they were occurring while the file was still copying over from a network location. But I am not sure how to solve this.
Raspberry Pi 4B 4GB
OS and all software (lastest/stable) for this frame was pulled within the last 3 weeks.
Debug log output:
2024-11-11 16:43:36,569 - image_cache.ImageCache - DEBUG - Updating cache
2024-11-11 16:43:36,570 - image_cache.ImageCache - DEBUG - No unprocessed files in memory, checking disk
2024-11-11 16:43:36,715 - image_cache.ImageCache - DEBUG - Found 1 new files on disk
2024-11-11 16:43:36,716 - image_cache.ImageCache - DEBUG - Inserting: /media/usb/Pictures/IMG_5481.JPG
2024-11-11 16:43:36,717 - PIL.Image - DEBUG - Importing BlpImagePlugin
2024-11-11 16:43:36,722 - PIL.Image - DEBUG - Importing BmpImagePlugin
2024-11-11 16:43:36,722 - PIL.Image - DEBUG - Importing BufrStubImagePlugin
2024-11-11 16:43:36,724 - PIL.Image - DEBUG - Importing CurImagePlugin
2024-11-11 16:43:36,726 - PIL.Image - DEBUG - Importing DcxImagePlugin
2024-11-11 16:43:36,729 - PIL.Image - DEBUG - Importing DdsImagePlugin
2024-11-11 16:43:36,741 - PIL.Image - DEBUG - Importing EpsImagePlugin
2024-11-11 16:43:36,745 - PIL.Image - DEBUG - Importing FitsImagePlugin
2024-11-11 16:43:36,750 - PIL.Image - DEBUG - Importing FliImagePlugin
2024-11-11 16:43:36,753 - PIL.Image - DEBUG - Importing FpxImagePlugin
2024-11-11 16:43:36,755 - PIL.Image - DEBUG - Image: failed to import FpxImagePlugin: No module named 'olefile'
2024-11-11 16:43:36,756 - PIL.Image - DEBUG - Importing FtexImagePlugin
2024-11-11 16:43:36,758 - PIL.Image - DEBUG - Importing GbrImagePlugin
2024-11-11 16:43:36,760 - PIL.Image - DEBUG - Importing GifImagePlugin
2024-11-11 16:43:36,760 - PIL.Image - DEBUG - Importing GribStubImagePlugin
2024-11-11 16:43:36,762 - PIL.Image - DEBUG - Importing Hdf5StubImagePlugin
2024-11-11 16:43:36,763 - PIL.Image - DEBUG - Importing IcnsImagePlugin
2024-11-11 16:43:36,767 - PIL.Image - DEBUG - Importing IcoImagePlugin
2024-11-11 16:43:36,772 - PIL.Image - DEBUG - Importing ImImagePlugin
2024-11-11 16:43:36,776 - PIL.Image - DEBUG - Importing ImtImagePlugin
2024-11-11 16:43:36,779 - PIL.Image - DEBUG - Importing IptcImagePlugin
2024-11-11 16:43:36,781 - PIL.Image - DEBUG - Importing JpegImagePlugin
2024-11-11 16:43:36,781 - PIL.Image - DEBUG - Importing Jpeg2KImagePlugin
2024-11-11 16:43:36,781 - PIL.Image - DEBUG - Importing McIdasImagePlugin
2024-11-11 16:43:36,783 - PIL.Image - DEBUG - Importing MicImagePlugin
2024-11-11 16:43:36,786 - PIL.Image - DEBUG - Image: failed to import MicImagePlugin: No module named 'olefile'
2024-11-11 16:43:36,786 - PIL.Image - DEBUG - Importing MpegImagePlugin
2024-11-11 16:43:36,788 - PIL.Image - DEBUG - Importing MpoImagePlugin
2024-11-11 16:43:36,791 - PIL.Image - DEBUG - Importing MspImagePlugin
2024-11-11 16:43:36,794 - PIL.Image - DEBUG - Importing PalmImagePlugin
2024-11-11 16:43:36,798 - PIL.Image - DEBUG - Importing PcdImagePlugin
2024-11-11 16:43:36,800 - PIL.Image - DEBUG - Importing PcxImagePlugin
2024-11-11 16:43:36,801 - PIL.Image - DEBUG - Importing PdfImagePlugin
2024-11-11 16:43:36,827 - PIL.Image - DEBUG - Importing PixarImagePlugin
2024-11-11 16:43:36,829 - PIL.Image - DEBUG - Importing PngImagePlugin
2024-11-11 16:43:36,829 - PIL.Image - DEBUG - Importing PpmImagePlugin
2024-11-11 16:43:36,830 - PIL.Image - DEBUG - Importing PsdImagePlugin
2024-11-11 16:43:36,832 - PIL.Image - DEBUG - Importing QoiImagePlugin
2024-11-11 16:43:36,835 - PIL.Image - DEBUG - Importing SgiImagePlugin
2024-11-11 16:43:36,837 - PIL.Image - DEBUG - Importing SpiderImagePlugin
2024-11-11 16:43:36,841 - PIL.Image - DEBUG - Importing SunImagePlugin
2024-11-11 16:43:36,844 - PIL.Image - DEBUG - Importing TgaImagePlugin
2024-11-11 16:43:36,846 - PIL.Image - DEBUG - Importing TiffImagePlugin
2024-11-11 16:43:36,847 - PIL.Image - DEBUG - Importing WebPImagePlugin
2024-11-11 16:43:36,881 - PIL.Image - DEBUG - Importing WmfImagePlugin
2024-11-11 16:43:36,883 - PIL.Image - DEBUG - Importing XbmImagePlugin
2024-11-11 16:43:36,886 - PIL.Image - DEBUG - Importing XpmImagePlugin
2024-11-11 16:43:36,888 - PIL.Image - DEBUG - Importing XVThumbImagePlugin
2024-11-11 16:43:36,893 - get_image_meta.GetImageMeta - WARNING - Can't open file: "/media/usb/Pictures/IMG_5481.JPG"
2024-11-11 16:43:36,894 - get_image_meta.GetImageMeta - WARNING - Cause: cannot identify image file '/media/usb/Pictures/IMG_5481.JPG'
2024-11-11 16:43:36,895 - get_image_meta.GetImageMeta - WARNING - Can't open file: "/media/usb/Pictures/IMG_5481.JPG"
2024-11-11 16:43:36,896 - get_image_meta.GetImageMeta - WARNING - Cause: cannot identify image file '/media/usb/Pictures/IMG_5481.JPG'
2024-11-11 16:43:36,896 - get_image_meta.GetImageMeta - WARNING - get_size failed on /media/usb/Pictures/IMG_5481.JPG -> 'NoneType' object has no attribute 'size'
2024-11-11 16:43:39,027 - image_cache.ImageCache - DEBUG - Updating cache
2024-11-11 16:43:39,027 - image_cache.ImageCache - DEBUG - No unprocessed files in memory, checking disk
2024-11-11 16:43:39,045 - image_cache.ImageCache - DEBUG - Found 0 new files on disk
2024-11-11 16:43:41,057 - image_cache.ImageCache - DEBUG - Updating cache
2024-11-11 16:43:41,057 - image_cache.ImageCache - DEBUG - No unprocessed files in memory, checking disk
2024-11-11 16:43:41,067 - image_cache.ImageCache - DEBUG - Found 0 new files on disk
2024-11-11 16:43:43,077 - image_cache.ImageCache - DEBUG - Updating cache
2024-11-11 16:43:43,078 - image_cache.ImageCache - DEBUG - No unprocessed files in memory, checking disk
2024-11-11 16:43:43,088 - image_cache.ImageCache - DEBUG - Found 0 new files on disk
2024-11-11 16:43:45,099 - image_cache.ImageCache - DEBUG - Updating cache
2024-11-11 16:43:45,099 - image_cache.ImageCache - DEBUG - No unprocessed files in memory, checking disk
2024-11-11 16:43:45,108 - image_cache.ImageCache - DEBUG - Found 0 new files on disk
2024-11-11 16:43:45,957 - image_cache.ImageCache - DEBUG - Update file stats: Wait for 0 ms and need 0 ms for update

Hm, you could cancel picframe, copy images, resart picframe.
Or you could run 'touch' on the copied filed. If I remember right picframe, will reimport the meta data.
The contents of the file will not be lost, and it won't even be modified. The only thing that happens when you run touch on an already existing file is that the file's access and modification timestamps are updated to the current time.