I guess this is pretty disappointing as methods with the same name and signature in 2 differently named `object`s in the same package are always allowed including standard `main` methods like `def main(args: Array[String]): Unit = ???`. Adding the `@main` to these and changing the signature to `String*` doesn't work. This doesn't pass the least surprise test and the user walks away wondering what synthetic code is generated.


+1 to this general perspective. Developers will generally maintain enough free disk space that they don't need to be right at the limit all the time. As such, Bazel doesn't need to go overboard on the disk space limit, whenever it cuts into other desiderata.


To expand a bit on the behavior I saw in the second scenario for posterity,

1. Used `NETKIT_SCRUB_AFTER`
2. The coredns Pod sends a UDP packet back to the curl Pod.
3. `netkit_xmit()` starts and runs `netkit_run()` triggering `cil_from_container` for the coredns Pod.
4. `cil_from_container` calls `ipv4_local_delivery()` which tail calls to `handle_policy()` for the curl Pod.
5. Eventually this hits `ctx_redirect_to_proxy4()` which sets `ctx->mark` to `MARK_MAGIC_TO_PROXY`.
6. `netkit_run()` returns with `skb->mark` now set to `MARK_MAGIC_TO_PROXY`.
7. `netkit_xnet(skb)` immediately clears the mark before sending it on to the peer device and host namespace.

I think this then messes up routing to the proxy. Going from `NETKIT_SCRUB_BEFORE` -> `NETKIT_SCRUB_AFTER` basically swaps one problem for another. In the `veth` case `cil_from_container` runs on the ingress side after passing the packet to the primary device so any mark is preserved. I guess this is true for redirects as well. A program could mark a packet then call `bpf_redirect()`. If the redirect target expects the mark to be set, they'd be in for a surprise.

Ack. `NETKIT_SCRUB_NONE` does seem to have the least surprising behavior when compared to `veth`. Hopefully there's no corner case where a container could set a mark to bypass ingress or egress policies.


Is this only fixed when using tailscaled, for users not using tailscaled, they should apply the workaround mentioned ? Is this really a good solution for new users?


@AkechiShiro have you observed this without using Tailscale?

As far as I understand the issue is tied down to the combination of Tailscale firing up before NetworkManager and depending on it being online, ending up in a deadlock essentially


The same issue happened to me with wireguard in the past. I'll try the suggested fix


Mind posting your configuration.nix in a gist?
We should be able to create a minimal flake and reproduce this with build-vm. Maybe cut out the VM's network access on purpose.

We should reopen this issue then if this happens outside of just Tailscale & NM


I do use Wireguard yes, so it could be I have the same issue as @pinpox


Can anyone confirm whether they still experience this issue without using tailscaled?


I am not sure if it is related; but l7 functionnality isnt working either. Using netkit (+BBR ba,dwith manager and native routing) and running a `cilium connectivity test` shows errors in all l7 related tests.
The same config but switching to veth makes those same tests pass.


@Anghille but this is with per-endpoint-routes config, right?


This issue has not been updated in over 1 year, and should be re-triaged.

You can:
- Confirm that this issue is still relevant with `/triage accepted` (org members only)
- Close this issue with `/close`

For more details on the triage process, see URL

/remove-triage accepted


It is with endpoint-routes disabled. Traffic flow by the cilium interface directly


I think that at least a good errormessage or warning should be given when problems arise. @mbovel Perhaps re-open this issue and rename it to something related to "improved error messages and warnings" ? There could be help included in the message how to cover the use cases outlined by @ekrich


Questo uno dei file derivati da screenshot e che ora va in errore proprio.
anscval-int anpr interno it_serviziCittadino_privacy (29)


I agree that within the ICA framework, one is likely able to mess stuff up different ways (after characterizing the evoked and spectral aspects id IC). I also agree (as discussed on line) that often the pipeline will be something like 'can want to see if the pipeline can detect X', so the feature of interest needs somehow to be present.

- one could play with the weight matrix ?? maybe as a way to 'remove' known sensitive attributes (not something I'd do by default, but if a data control right holder indicates an aspect that needs nullifying, this can be a way)
- specific IC could be made noisier adding pink noise or a sin where evoked response is (say found IC with spectral / evoked response, ie increase energy following events anytime from 50 to 1000ms, no need to be specific IMO -then add, it exist tools for simulations I used that can be leveraged for that)
- total randomness, chunk time courses based on autocorrelation size (to keep main spectral, autocorrelation) and exchange within/between IC and remix

not sure all makes sense, but putting some ideas down ...


Buongiorno @steps88,
il problema è dovuto alla presenza del carattere "." nel nome del file che può stare solo prima dell'estensione ".png". Pensiamao di aggiungere una frase nella form del tipo "Nel nome del file non sono ammessi i caratteri punto ..."


va bene, meglio ancora se si può aggiungere un controllo del nome una volta caricato il file, e nel messaggio d'errore


As recently as two years ago, I had this issue without knowingly using tailscaled. (Posted to #59603.)
Since then, I'm using the workaround from the OP and have lived happily ever since.

The problem is perhaps that tailscaled is not *the only* service that activates `NetworkManager-wait-online.service`, so it doesn't make sense to fix this issue in tailscaled.

Perhaps this issue has since been fixed by an unrelated patch upstream (however that would happen), but I'm not optimistic. Let me try to get rid of the workaround and see if it is still an issue.


Thanks @sgraf812 I may try to reach out to systemd/udev maintainers about issue #182449 hopefully we can nail this issue down once and for all


We did receive an answer from Poettering but I don't know how to properly answer back, if anyone more experienced could pitch in : URL


You could try URL to find all the objects. If you don't get your device, your problem might be related to URL


Ok thank you. I just installed bacpypes on my machine and downloaded ReadObjectList.py.
Now the following arguments are required: device_id, device_addr
How, or where can i set this arguments?
device_addr should look like "192.0.0.1:47808" for example?
and what's the device_id?


@Anghille `cilium connectivity test` runs regularly as part of CI against netkit-enabled clusters. Can you share a bit of info about your configuration as well as the errors you encountered while running? What arguments did you use with `cilium connectivity test`? What does `cilium status` show?


Thank you jurkov.
With bacpypes I can access all the data. And sorry for my stupid questions, but I`m not a bacnet-specialist :)
But my Bacnet-Device is only responding to "Confirmed-REQ"-messages:
python samples/ReadObjectList.py --ini BACpypes.ini 2XXXXX5 10.XXX.XXXX.1
grafik

When I send "Unconfirmed-REQ who-Is" (as thingsboard-gateway does), I get no answer:
grafik

So I need to make thingsboard to send Confirmed-REQ-messages to the bacnet-device?
How can I do this?
How to specify the device-ID for bacnet-device in thingsboard?


I believe we can close URL in favour of URL and wait for new RPC provider integration 🤞


i would suggest to check proxy logic since the issue was not on the router side, but on proxy. So querying Infura directly was just fine. Replacing provider wont help in this specific case. There is an explanation in URL @churik


There is no actually one conclusion (as it was checked with disabled both grove and proxy(, and the discussion moved there, but yeah, seems that the issue might be on both sides - grove and proxy.
Thanks for the comment. I'll bring this issue today on wallet sync, thank you


How would you improve the error message? It currently says:

// error: main is already defined as class main

Would you special case it for `@main` methods?

// error: main is already defined as @main method main

I guess we could re-purpose this issue, or open a new one.


@StevenMiller123 I close the other one and let you report every games you tested with this error here. Thanks you :)


I also ran a bisect:

searched nightlies: from nightly-2024-07-01 to nightly-2024-10-02
regressed nightly: nightly-2024-08-01
searched commit range: URL
regressed commit: URL


WG-prioritization assigning priority (Zulip discussion).

I can also reproduce on current beta so tagging accordingly

@rustbot label -I-prioritize +P-medium +regression-from-stable-to-beta


minimized, zero deps -> URL

[dirbaio@mars defmt-repro]$ rustc --version
rustc 1.83.0-nightly (06bb8364a 2024-10-01)
[dirbaio@mars defmt-repro]$ cargo build
 Compiling radio_app v0.0.0 (/home/dirbaio/defmt-repro)
error: linking with `rust-lld` failed: exit status: 1
 |
 = note: LC_ALL="C" PATH="/home/dirb(snip)47a" "--gc-sections" "-Tlol.x"
 = note: rust-lld: error: lol.x:1: symbol not found: __defmt_default_panic
 rust-lld: error: lol.x:1: symbol not found: __defmt_default_panic
 rust-lld: error: lol.x:1: symbol not found: __defmt_default_panic

error: could not compile `radio_app` (bin "radio_app") due to 1 previous error
[dirbaio@mars defmt-repro]$ rustc +stable --version
rustc 1.81.0 (eeb90cda1 2024-09-04)
[dirbaio@mars defmt-repro]$ cargo +stable build
 Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.06s


Any updates along these lines? I started seeing this error in the last 4-5 days.


Sorry for the delay of syncing up. With discussion of the team, we think the current behavior is expected and there is no plan to make a change for it currently.

I am closing this issue due to the conclusion. Thanks for the report and your understanding.


Hi Kabi, the LINC documentation site can't be opened @kabilar


@dkashyn-sfdc Correct. I experimented with speeding up filesystem scans by using a sqlite database as an index, but it's very tricky to do while observing all of the constraints I mentioned above, and in the end I felt that it had an unfavorable complexity/utility ratio (so it will ship without an index, just a parallelized filesystem scan).


Thanks @jingjingwu1225. Sounds great. Will we be creating Webknossos datasets that are comprised of a histology image plus the previous generated annotations from Vaanathi's work that are now in the Zarr format?


Hi @kabilar, thanks for the reminder. Yes, after we got the updated groundtruth annotations from Vaanathi's work I'll upload them to lincbrain and add both datasets itself and masks to webknossos in one dataset, and delete the current one. The annotations will be saved separately with the dataset but added as layers in webknossos.


Hi @kabilar, after discussion, we agreed on adding initials of annotator after label desc and a suffix of _dseg to represent it's discrete segmentations. For a dataset with name of sub-MR243_sample-slice0000slice0004_stain-LY_DF on webknossos, its corresponding annotations will have name of sub-MR243_sample-slice0000slice0004_stain-LY_DF_desc-JW_dseg. We're working on adding the naming scheme on LINC docs. Thanks!


It seems to all depend on the linker version, not the compiler itself. Using ldd from beta/nightly with a stable compiler triggers this issue. Using ldd from stable on a beta/nightly compiler doesn't.

So I compiled lld from llvm myself, and can confirm: With lld built from commit `ebb326a51fec37b5a47e5702e8ea157cd4f835cd` the build of Dirbaio's minimized example fails, whereas with `b6dfaf4c291ee186481f6c1dcab03874d931c307` it succeeds.

Specifically, it seems to be this change: URL

If I revert that change (by simply changeing the if condition to `if (false && activeProvideSym)`) the example also succeeds to build again.


Hi @fabianjozsa, I tried to used sticky header many time, however always opted at the end for a stack, reason being was that annoying jiggling effect that the header has when you scroll the list below (even when setting fixed hardcoded height and width sizes). Have you find a solution for that? Do you get that jiggling jumping like weird thing it does when scrolling?


I mean this one:

 URL

Anyone from support knows how to fix that header moving so to be "sticky" without moving and shaking?


You may have to create a feature request or create the feature by yourself. It is possible to create a custom uplink and downlink converter. See URL

I added my BacNET devices based on URL line 12 and line 14.


Call of Duty®: Advanced Warfare v1.00 - CUSA00803

[Debug] memory.cpp:operator():640: Assertion Failed!
Mapping cannot fit inside free region: size = 0x80000000

Crash™ Team Racing Nitro-Fueled v1.00 - CUSA13795

[Debug] memory.cpp:operator():640: Assertion Failed!
Mapping cannot fit inside free region: size = 0x20000000


Hello!

I attempted to replicate the issue but was unable to do so.

Here are the steps I followed:

1. Created a new blank project.
2. Set the Column on the default page as Scrollable.
3. Added a StickyHeader.
4. Added two buttons to toggle the value of an AppState variable.
5. Filled the list with multiple containers to enable scrolling.
6. Ran the project in Test Mode.
7. Scrolled to the bottom and tapped the button.

Could you confirm if there’s anything I might have missed in these steps? I’m happy to investigate further!

Looking forward to your feedback. Public Project you can clone to test and modify: URL


I can open a new ticket to avoid polluting this one with all informations necessary if you want :)


Hi @paulmure, I've been trying to review a few times, but each time I end up wondering if that's the right thing to do.

I agree with you, the view API is restrictive: it imposes a common view on naming for every backend.
But I suspect most of the backend will have the same needs.
I don't want the backends to re-implement, over and over, name translation.

Could you give me some examples of a custom naming scheme you would like to have, and that would be too specific to your use case to be mainlined?
Clearly, for something like prefixes, we could make it parametric (as you say)


Here I think I have the same concerns as #793: this kind of thing should be used for naming scheme only, what kind of things do you need for local idents?


It’s been a while since I looked at this. IIRC, we needed to inspect the kind to see if a local variable is a const generic (which we treat differently than other local vars).


Controlling the prefix is definitely a priority right now. But we think it would also be useful to control how much of the fully qualified path is used based on what’s currently imported. But this may be easily implemented by allowing the view API to export a list of path items.

The reason why I suggested exporting the entire type is because it seems like this sort of fine-grained tweaking can easily lead to a messy and unprincipled view API. But there’s definitely a lot of room for design choices and I’m not entirely certain what’s the best solution here.


Mmh, I see, looks like a legitimate use to me, I can see phases needing such info. Let's merge that PR (finally... I'm sorry --again-- for how long that took...)


Yeah. I see what you mean. Indeed, we may end up with a messy and complicated API...

The implementation itself is already quite messy and complicated, actually 😅 I would like to revisit it at some point...

I think we should maybe brainstorm and figure out what kind of naming transformations one could want, and then decide whether a unified API is possible. I wonder what would be the best way of doing that: maybe a GH discussion?

I think a unified API & unified transformation "engine" would be great. Having a declarative description of what a specific backend needs in terms of naming scheme, and then invoking the name transformation mechanism seems the right think to do to me. The concrete_ident module has invariants, and it's easy to break them, so doing something uniformly would be great.


I experience this error whenever I try to transfer funds, such as buying a Status ENS domain or trying wallet-to-wallet transaction. The origin Status Wallet has 21 USD, and I can't transfer any amount of money to the destination Wallet on the Ethereum mainnet. The error is always the same in both Simple and Advanced modes:

`WPP-028 - status-proxy-O.error: failed with 50130704 gas: insufficient f unds for gas * price + value: address 0×925Bd[...]2917E have 0 want 4025019521328142`

This is using my Status account on mainnet, not a test account on testnet (Status desktop 2.30.0).

I'm far from an expert here, but I don't think this error is expected, @saledjenic (CC/ @virginiabalducci )

I hope this helps!

Image


Hi @jorge-campo you're right it should not be like that when buying ens name. There are 2 potential reasons for that:
- you should confirm that your account (the one you're using for sending the tx) has enough ETH to pay for the tx execution besides having 10 SNT for the ens name (in the screenshot I see that the selected token is ETH and you're trying to send 10 ETH actually). So that's most likely the reason. If you want to buy an ens name, go to Settings/Ens usernames section
- we're still using grove provider and the error that you're experiencing is coming from it and it can be unreliable in some cases and should not be there after we switch to nodefleet, that supposed to be very soon, these days. But based on the screenshot, that's not the case there.


Thanks, @saledjenic !

The screenshot is unrelated to the ENS name purchase; it's a direct wallet-to-wallet transaction of ETH on Ethereum mainnet. I have 21 USD in my wallet, and I can't send 10, 5, or 2 USD with the "insufficient gas fee" error.

I am happy to hear that the switch to Nodefleet will happen soon! 👍


the next stable release is in 9 days, at which point I believe the Ferrous Systems Embedded Rust exercises will stop compiling.


Sure. Since you don't have endpoint routes enabled it sounds like this could be something different. If you have an easy way to reproduce your use case (preferably in a kind cluster) that would help as well.


You can try manually modifying the registry to add LocalSend's sending function to the main context menu of the right-click.


I have tried to modify the registration expression to put the send directive in the context menu, you can try to create a txt document type the following (if you localsend is the default installation address) and change the txt suffix to reg.
:Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\LocalSend]
@="Send with LocalSend"
"Icon"="C:\\Program Files\\LocalSend\\localsend_app.exe"

[HKEY_CLASSES_ROOT\*\shell\LocalSend\command]
@="\"C:\\Program Files\\LocalSend\\localsend_app.exe\" \"%1\""

[HKEY_CLASSES_ROOT\Directory\shell\LocalSend]
@="Send with LocalSend"
"Icon"="C:\\Program Files\\LocalSend\\localsend_app.exe"

[HKEY_CLASSES_ROOT\Directory\shell\LocalSend\command]
@="\"C:\\Program Files\\LocalSend\\localsend_app.exe\" \"%V\""

[HKEY_CLASSES_ROOT\Directory\Background\shell\LocalSend]
@="Send with LocalSend"
"Icon"="C:\\Program Files\\LocalSend\\localsend_app.exe"

[HKEY_CLASSES_ROOT\Directory\Background\shell\LocalSend\command]
@="\"C:\\Program Files\\LocalSend\\localsend_app.exe\" \"%V\""


Domluva na schůzce 8.10.2024: zavíráme, budeme zakládat issues na jednotlivé požadavky úpravy chování stromu.


Is anyone aware of a workaround we could apply for defmt? We would like to avoid defmt being broken on stable with the release next week.

I tried marking the `defmt::default_panic` function as `pub`, but this does not make a difference.

Is there something we can add to the linker script? Something along the lines of `PLEASE_DONT_GARBAGE_COLLECT(__defmt_default_panic)`.

Or can we pretend that this function is in fact used?


Note that while the exercises are relatively small impact (as they are under our control), `defmt` is a widely popular solution in the embedded space.


Closing this one as it has been concluded this is related to network issues and not from the app itself


I have read the related code, maybe we need to add this symbol to the symbol table. Or change the code like this:

diff
diff --git a/lld/ELF/ScriptParser.cpp b/lld/ELF/ScriptParser.cpp
index 3febcfb87da4..44185c282ad7 100644
--- a/lld/ELF/ScriptParser.cpp
+++ b/lld/ELF/ScriptParser.cpp
@@ -1660,10 +1660,11 @@ Expr ScriptParser::readPrimary() {
 tok = unquote(tok);
 else if (!isValidSymbolName(tok))
 setError("malformed number: " + tok);
- if (activeProvideSym)
+ if (activeProvideSym) {
 ctx.script->provideMap[*activeProvideSym].push_back(tok);
- else
- ctx.script->referencedSymbols.push_back(tok);
+ return [] { return 0; };
+ }
+ ctx.script->referencedSymbols.push_back(tok);
 return [=, s = ctx.script] { return s->getSymbolValue(tok, location); };
 }

However, I'm not familiar with this part of the code.

In any case, I believe the upstream backport is likely to miss our backport process. I'm reverting this commit to our fork LLVM.


@DianQK said:

Would this mean this issue will not land on stable? That would be great, then we do not need to find a workaround for defmt.


Impact of the regression is this breaks all projects that
- Use defmt
- and do define a `#[defmt::panic_handler]`
- and don't ever use `defmt::panic!()` or the other macros that panic (assert, todo, unreachable, etc.)

A possible workaround defmt could do is adding `EXTERN(_defmt_panic)` to the linker script. The side effect is it'd prevent the panic handler from being optimized out when it's truly unused, I think.


Sorry, I mistakenly deleted the definition of `foo`. I may have forgotten to run the `llvm-mc` command to verify after the deletion. I have now fixed this description.


👍 sounds good to me that we’d have the button consistently teal. As you say the banner is already doing a good job warning users, and the button text is different as well. Also agree re keeping the indigo background in the light theme.

Will leave it with @laymonage to figure out where to place the "Delete" buttons we occasionally have in forms, that could either go in a "footer actions" dropdown, or in a "slim header" falafel actions menu 👀


In case the fix ( URL does not make it into the next stable I'd think this is an okay compromise to make until it does get fixed. But let's hope it won't be necessary.


Can you detect if a FLOAT or Primitive node is connected to a "cfg" input ?
And also apply the settings to these sliders.

If so, Step 3 ( the global slider table ) may not be necessary.

cfg


I have submitted PR #131448. I apologize that I may have misspoken. I can't guarantee that this issue won't land on stable, and even reverting this change carries some risk. :)


Would it be possible to provide any actual project? :3 I think this will be helpful in determining whether to backport.


4.6.2 still has this issue "There was a problem starting D:\Program ... The specified module could not be found."


Also reproducible in Godot 4.0.4

I am going to try to fix it


Funny fact. It doesn't strip BBcode if it is printed into Godot Console but it is stripped when it is printed into OS console
screen-1728545875


It is not only not stripped away but also isn't considered as fallback to white text which affects following text...

screen-1728546548

The os console still shows correct results:
screen-1728546564


Most concrete projects of `defmt` are not public, but it has 415 reverse dependencies. URL


The editor Output panel uses the BBCode implementation from RichTextLabel to display it, while terminal output uses a custom BBCode-to-ANSI conversion routine that only supports a subset of BBCode and behaves differently. See URL

I wouldn't say it's correct behavior, it's just that the BBCode-to-ANSI conversion routine *always* replaces `[/color]` with a "reset color" tag, even if `[color]` was never opened.


Likely not intended behaviour, the code inside that custom parser explicitly tries to replace `[/color]`.

if (p_string_ansi.contains("[color")) {
 p_string_ansi = p_string_ansi.replace("[color=black]", "\u001b[30m");
 ...
 p_string_ansi = p_string_ansi.replace("[/color]", "\u001b[39m"); // On this line
}


While auto-close behavior is "correct" for single color print, it isn't correct in multi color print like in my example because user will expect to see white printed in white color.


The minimal reproduction is as follows:

`main.rs`:

rust
#![no_main]
#![no_std]

#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
 loop {}
}

#[no_mangle]
fn foo() {}

#[no_mangle]
fn bar() {}

`script.t`:

PROVIDE(foo = bar);

sh
$ rustc +beta main.rs --target thumbv7em-none-eabihf -Clink-arg=-Tscript.t
error: linking with `rust-lld` failed: exit status: 1
 ...
 = note: rust-lld: error: script.t:1: symbol not found: bar
 rust-lld: error: script.t:1: symbol not found: bar
 rust-lld: error: script.t:1: symbol not found: bar
error: aborting due to 1 previous error

With small modifications, it can also be reproduced on x86.

@rustbot label +S-has-mcve +A-linkage


Looks like it is intended. As I understand the line you pointed resets color to default when sees closing tag so it is likely normal because if color is already default nothing changes


Please watch this video that shows the issue in action:

 URL


Didn't mean to close the issue. Please watch the video.

 URL


Update:

The tests are passing now, but a release of Paraglide JS 2.0 is postponed until we have lix 1.0, which powers Paraglide JS. That's likely in January or February.

- PRs for fixed or improvements will be reviewed and accepted
- Read more here URL

 URL


I just meant that it looks like it's trying to replace the closing tag, but somehow the closing tag is still showing in the output.


The code that prints to os terminal is different from code that prints to godot console. And here you are viewing the code that prints to os terminal. If you will comment the line of code you commented, your is terminal will print the same result as in godot console. `"\u001b[39m"` is an escape code for terminals


@llvm/issue-subscribers-lld-elf

Author: DianQK (DianQK)

I tried the following code. I expect lld to link successful while also removing unused symbols, but it reports `symbol not found: bar`.

a.s:

asm
.global _start
_start:
 nop
.section .text.foo,"ax",@ progbits
.global foo
foo:
 nop
.section .text.bar,"ax",@ progbits
.global bar
bar:
 nop

script.t:

PROVIDE(foo = bar);

commands:

bash
llvm-mc -filetype=obj -triple=x86_64 a.s -o a.o
ld.lld -o a_gc a.o --gc-sections -T script.t

output:

ld.lld: error: script.t:1: symbol not found: bar
ld.lld: error: script.t:1: symbol not found: bar
ld.lld: error: script.t:1: symbol not found: bar

cc @ MaskRay ebb326a51fec37b5a47e5702e8ea157cd4f835cd


I have verified that #111945 has fixed the build error in URL

I’d like to ask for your advice on the backport. I reverted the related changes in URL What do you think is better, revert or cherry-pick the new patch?


so I have same issue I use latest version of jellyfin and I cant see that preview button in player (web)/desktop


Hey, the error message looks like you would use Jellyfin 10.10.0 (from the unstable) release.
If so, you need to wait for the official 10.10.0 release which is tomorrow as far as i know


**Hello,**

Thank you for the video. I was able to replicate the issue on my end. However, I'm still not certain whether this is a Flutter-specific problem or something that FlutterFlow can address. I'll forward this to our engineering team for further investigation.


I just found out this is a known issue with the package ( URL I'll add this as evidence to see if the engineer team may apply a solution


This sounds a little bit unexpected from user perspective. However, since the sidecar is always in either Terminated state or starting, and not started yet, this is exactly the expected behavior. It will be the same when init container is failing to start. We will keep restarting the Init container untill it completed with `0` exit code. in this case, the condition we are waiting is for sidecar to be started so we can proceed to the next init container or to the main container.


I think what we need here:

1. Update docs to mention this behavior: URL
2. Add an e2e test that will effectively codify this behavior as expected


Some interesting issues that we need to cover:

1. If a sidecar never had a chance to execute the startup probe, it will prevent the main container from even starting: URL
2. Sidecar implemented as a built-in type always starts before the container. So it will block the main container start before the sidecar's image is pulled. See URL The best practice here is to postpone all heavy operations to as late as possible.


Environment variables used by your front end application at runtime cannot be reliably projected. They are required to be bundled into the code. Sensitive variables should be stored on your server/backend for example.

Please see related issue and discussion URL


Failed to cherry-pick: 1c6688ae3449da9c8fee1e1c12c892223496fb4c

 URL

Please manually backport the fix and push it to your github fork. Once this is done, please create a pull request


Just heard that the official 10.10 release is delayed by ~2 weeks.
I will add a pre-release sometime this day, which could be manually installed


oh! thank you for the tip and yes it would be good. so it works on day one when it get released


I don't think I can get it to work directly on release.
I need to add my github release to the manifest.json you guys are using
and if I do that beforehand, it will automatically update for everyone, even if they're still on 10.9.
So I guess I'll have to do it manually first, but it's usually done the same day.


I think you can specific version for each one if I'm not mistake but yeah i can do the manual way no issue


Oh yeah i think you are right. I never worked with these but maybe i will try it out


here are other manifests i saw, URL and URL and URL so with help of chatgpt and me being patient zero im sure you can manage it so gl!

worst case, host new manifest on different url till it get officially released?


/award 150

thanks for playing :) keep collecting points to increase your chances of winning!


I have added a new section to the readme. URL

Obfuscation is something I would be happy to consider along as it's clear to the users of this and any frontend env lib that the bundled keys can be extracted and people don't have a false sense of security and therefore store sensitive info.


I was no longer able to reproduce this issue, so I'm going to close it as resolved. I believe it was likely fixed by the work done in URL If you are still able to reproduce this issue, please let us know and we can investigate further.


Thanks @jingjingwu1225. How would you name these Webknossos datasets with multiple layers? I presume that this would be a case where this is not a 1-1 mapping between the naming on lincbrain.org and on Webknossos.


This issue has been mentioned on **NixOS Discourse**. There might be relevant details there:

 URL


Thank you, @jingjingwu1225 @jssyq. I have left some suggestions in URL


I think this can be now closed, since #131448 has been backported and should have made it to the stable 1.82 release of tomorrrow.

Am I right @jonathanpallant ? Can you check if we're all good here? thanks :)


I can confirm nightly-2024-10-13 fixes it. nightly-2024-10-12 is the last one failing.

Beta works as well.


Upstream LLVM will not backport the relevant fixes, so I will add a test case.


Hi,
Thanks for the feedback. As you can see it is an open-source app, we just started the development in August. A developer account costs $99/yr. I know, there are open-source apps that are signed, but note that their development team (contributors) includes an individual that has a dev account because of work or etc. Homebrew requires all the casks to be signed. We are planning to enroll and sign it, but please be more understanding.


Also, this topic clearly does not belong in the issues section. Feel free to join our Discord server if you have further questions.


Do you think there is a chance that this "bug" will come back to us? We are currently evaluating if we should apply a fix/safeguard in defmt.


No. The main branch of LLVM has fixed. The next major update will include it.


@Atemu ran into it as well, but already had a running system with tailscale up. Manually shut down tailscale, and rebuild succeeded (and tailscale was back up). Tested with several rebuilds and restarts, works ok so far


An idea I had on this is that we could perhaps hack around this using a systemd unit that `Conflicts` the units which appear to block nm-online.target such as tailscaled. It'd be `Require`d by the nm-online target and we'd then have another target which wants all those units and is wanted by the network-online target but `After` the nm-online target.


Also tried with the stable prerelease from URL Problem is solved.


Kai No Kieski v1.00 - CUSA49295

[Debug] memory.cpp:operator():644: Assertion Failed!
Mapping cannot fit inside free region: size = 0x24000000


Hey everyone. Some good discussion on this thread.

I've appended a section to the readme to be more explicit about the concern. See URL

It's worth mentioning we could add obfuscation to this package to achieve making it harder to extract keys but it would come at a concern of giving the package consumers a false sense of security.

Related issues raised are
 URL
 URL
 URL

I am going to close the issues for now but if someone would like to discuss if there is value in obfuscation or has another better idea please feel free to open or re open!


Thanks for raising the issue!

Related issues raised are
 URL
 URL
 URL

I am going to close the issues for now but if someone would like to discuss if there is value in obfuscation or has another better idea please feel free to open or re open!


Did you install Visual Code via the Launcher or manually? The reason I ask is because the Launcher allows you to download Visual Code with the current version of Renpy Extension (which had been changed recently). If you did not do it through the Launcher:

Try uninstalling Visual Code completely, restarting, and loading the Launcher again. If it works after that point, try going to Preferences in the Launcher, then Text Editor, and click on Visual Code. It will download and install both Visual Code and the current version of the Renpy extension.

Another thing you can try if uninstalling Visual Code does not fix it, try on another User account for your system. User Profiles (especially Windows) can cause strange behaviors if something happens (yes, that is vague, but there is a lot of things that occurs with a User Profile). If that fails and you have access to another system, check to see if the same behavior happens on that.


You can also try:

 URL

Select a build from the Ren'Py 8 Fix column. These are nightly fixes that fix issues found in Renpy that might not be in 8.3.2 whereas Renpy 8 Development meant for developing the next version (in this case, 8.4) of Ren'Py. This way fixes could be released sooner without waiting for Renpy 8.4 to come out.:)


This sounds like URL - did you per chance move the Launcher's window to a secondary monitor, and close it there the last time that it was working properly?

If so, try creating a new .rpy file in your `renpy-8.3.2-sdk/launcher/game/` folder, and write the following inside it:

py
init 999 python:
 preferences.restore_window_position = False

See if that indeed fixes the issue.


Fixed it by adding a new file in renpy-8.3.2-sdk/launcher/game/

named the file fix.rpy, and adding the following code

init 999 python:
 preferences.restore_window_position = False


Sorry for opening up this issue again, but I have this exact issue for some reason while using the latest version. Any tips?


I think it's the lack of a slider editing system, that keeps sliders from being added to ComfyUI.

Because, apparently, you can already add a slider to a specific widget, if you change the code, and add the slider parameters:
 URL ( but your changes will be lost, the next time you update ComfyUI ).

If ComfyUI adds sliders, the Controller could use the same slider Settings.
But have no idea if/when they will add sliders ( or if they plan an editing system ).
At least they've moved my slider feature request to the litegraph issues ( URL )


It looks like the latest cusolver has an implementation for non-symmetric matrices. Is it possible to revisit this request? (Looks like it was added in cuSOLVER: Release 12.6 Update 2)
 URL


@chrisgoringe In the documentation I suggest adding that the range you set on the controller slider will also be applied on the node widget.


Both RFC8410 (EdDSA in X.509) and RFC8419 (EdDSA in CMS) say explicitly that the context string is not used. Since currently X.509 and CMS do not use the context string of EdDSA, then the most backwards compatible thing is to maintain that behaviour for the EdDSA component.


What are the versions of `java-debug-adapter`, `java-test`, `jdtls` you see in Mason?


You can also tryout following with docker & devcontainer and compare your local setup to figure out what's wrong.
 URL


I have the new edit GUI.
But the new step size is not applied to the slider.

The step size is not saved.
When open the edit GUI again, it shows the old step value.

stp


I think there is a problem with the cfg, I can change all the other sliders except for cfg ones...

 URL


It's working for me.

Maybe that's a custom node ?

The `shift` key as another function on one of my custom nodes ( URL )


I found another issue. When you set a min/max range, it becomes difficult to change values on the widget using the arrows; many clicks to just change of 1 step

 URL


@JorgeR81 It can't be since the problem only occurs on CFG sliders.

This is a frontend function.


It doesn't work even in always mode, to it's not due to shift key


Could it be related to the default step size of 0.01?

step_size

(I tried scrolling as much as I can but it doesn't change a single value...)


I'll look at it. My guess is that there is a clash between step size and rounding (if it's rounded to 1 decimal place, but taking steps of 0.01).


To close the loop: in addition to shipping in 8.0.0, this feature has also been cherry-picked into 7.4.0, and the documentation has been updated accordingly.


The new slider steps are being used in the slider.

But I still can't use the arrows in the node widgets, once the step is changed.


OK, I can see what's the issue.

I have the slider step size at 0.05, but the arrows change at 0.01 steps, so the resulting value is not allowed.

When I click down in the arrow it goes from 0.35 to 0.36
But on click up, it returns to 0.35


Yup. There is a weird interplay between precision, round, and step. I think I've got it working...


After this fix, the other 2 issues I had are also fixed !

 URL
 URL


Ah, but now there is a different problem:

When dragging the slider, the new step interval is not used. It's only used with scroll.


All the issues described above seem solved with the latest update.


Now I'm able to save step the slider settings. And they are kept when switching workflows.
And I can also use the widget arrows.

---

But I now have other issues: URL

I tried mostly with min (0), max (1) and step (0.05)


@JorgeR81 Have you tried saving step to 1 and then lowering to 0.1? Because I got the problem in the video


Yes, with Apply ControlNet I can use `min (0), max (1) and step (1)`, I had not issues

But with `min (0), max (1) and step (0.1)` the rounding is broken.

cn


Cfg now it's working, but they are all 2 decimal digits instead of 1


@JorgeR81 Watch my video here URL I always had 1 decimal digit


Yeah

If you don't set the precision in the main comfy controls, cfg has a precision of 0.1, but a step size of 0.01, which makes no sense at all.


This with the latest update:

- When dragging the slider, the new step interval ( 0.05 ) is not used. - **NOT FIXED**

- The widget arrows, in the node, don't use the new step interval. - FIXED


If you set step to 1, it gets confused into thinking the widget is an integer! I'll raise a new issue.

Not sure what's happened with the rounding.


Why does it have to be a separate receiver? I think this should be an extension providing an interface that _any_ receiver can connect to check if it's a leader (have to do the work) or not (do nothing).


Everything seems to work:
- I can apply the new step size to multiple nodes.
- The new step size is applied, when scrolling and dragging sliders or using the widget arrows.
- The new min / max are applied to the widgets


Maybe this would help? (I closed because earlier I thought it was obsolete)

And I've made a small flake version for testing purpose: URL

At least last time I used this, I didn't have to `systemd stop tailscaled` beforehand when tailscale was updated.


As Scott says elsewhere, 'belt and suspenders` but this is belt and suspenders and superglue.


@sguerra issue completata, non posso cambiare lo stato "In stage" con questo utente
ncapozzi


Sounds a little similar to the issue I put in #1088. I have the full on laserbear kit though.


I can try testing with it.
Think the repro steps are:
1. Have a system with Tailscale and NM-wait-online
2. Disable nm-wait-online with the hack above
3. Put nm-wait-online back in

On the next rebuild it should get stuck. I'll try this later today and report back if it reproduces consistently. Note: the Tailscale fix was backported to 24.05 so need to pin nixpkgs to a commit prior to that


I reported this issue and others related to Sticky Header, you can check it here:

 URL


My first thought is what if the signer doesn't have access to the public key? My second thought is this works great to obtain what you want for ML-DSA or other component algorithms that take a context, but not at all for the ones that don't (which is RSA and most EC combinations except the Edwards ones). So at best in the context of the current draft it would give us separation for 1 of the components, but not the others, which would foil our security claim of EUF-CMA as long as one of them is EUF-CMA. My third thought is that we had thought about this property a few years ago (For instance, it would work with multiple independent certs as well), and there probably are lots of interesting use cases where keys could be joined to make a composite signature. After lots of discussions it seems this property wasn't desired in lieu of the security implications it brought to composite.

Perhaps for combinations where a context string is used in BOTH algorithms this could make sense... We had talked about using context strings for other components that could support it. See URL but it was mostly decided against because the most compatible way is to use no context String...

So in summary for cases where both components take contexts, I would say it is interesting. For cases where some components don't take a context String, i don't think we want to go there.


Mate that issue was opened in Jan 25, we are now in October, maybe would be good to merge them all into one and push them back up top. @Alezanello what do you think?


Edit: I have followed the MundoYakara method actually, maybe that is the reason I have these issues?
 URL


Based on our production experince with the NFS CSI driver over the past month, this is not necessary in my opinion.


Closing this issue because ownership of Critters has moved to the Nuxt team, who will be maintaining the project going forward. This repo is archived and won't receive any future updates.

If the issue is still relevant, please re-post it to the actively-maintained fork at URL


Hey @dmitryax! Thanks so much for your response! We’d be happy to contribute such a component. I don’t have much experience with extensions—would this mean that every receiver needing this functionality would require code modifications? Implementing it as a delegating receiver, similar to receiver-creator, could avoid it.


@hmaarrfk what was the aarch64 issue you were having specifically? I couldn't really tell from a glance over the issue. Are you still having them?


""PyTorch was compiled without NumPy support" error when running on Linux aarch64 + CUDA (on NVIDIA GH200) using the conda-forge build of PyTorch 2.4.0."
was it this?


Thanks. We heard about pytorch dropping their conda package builds. How's the support for win and triton at the moment? as I understand you don't have either, we can help with that if you need.


You can find a list of issues URL

I've tagged them all. I mean its all volunteer led. Comment on the appriopriate one, make a PR if you want to see it improve.

So help where you can. To companies that are interested in windows support, I simply suggest volunteering to build things. It goes a long way.


Modifying code is fine - better than having two similar receivers. It's better to write some code, but keep the user interface clean. Restricting it to receiver_creator, we won't be able to use leader election for receivers that don't work with receiver creator, for example URL or don't need to use it all, e.g. collecting data from a static endpoint. Also, future of receiver_creator is unclear. We might take a different approach to discovery and consolidate all scraping receivers in one, see URL


ClickHouse seems to attach `X-ClickHouse-Exception-Code` header, which can be used to detect the problem. see URL and URL


Oh, the conda-forge CI can't handle the pytorch build for windows? hmm ok.


it would be nice to also implement something like that in v2


whups, you already got points for that review :(

sorry, we have a 0% tolerance for cheating......


@jobenjada I remember I had done secret side quest and it was one of them but Feedback fanatic is a separate task. If you want I can do any other task for the point you awarded to me.


Thanks for the response! We'll explore the idea of implementing leader election as an extension instead of a receiver and will get back to you.


I was about to open an issue on this, then I realized it was already done. Please change this standard behaviour: it does not happen for other extensions!


I was tried to add this to Homebrew, but there is no dedicated version naming and it is not easy to match the version with the file name.


You can't add it due to the lack of paid Apple dev account. I have already set up the homebrew cask, I just cannot publish it.


Crossposting the discussion with the BIDS team on using the `desc` entity: URL


After discussion with the team, we decided that these annotations will be performed on a single layer, so I updated the initial comment.


@jingjingwu1225 @jssyq @elissabell Thanks for the discussion last week. We decided that Webknossos datasets with multiple layers are currently needed in order to visualize the previously generated annotations. So these Webknossos datasets will be named as described in #20 with Vaanathi Sundaresan's initials.


I will close this issue, it works now on at least 2 machines ;) Feel free to open a new issue if sso problems persist


I think its pretty clear that this is a different task, isn't it?

<img width="750" alt="image" src=" URL


@jobenjada by the time I was doing it the survey form was not available so I searched it a little and came across #3614, Now that you have shared the form I will open an issue and do it for 0 points


I currently plan to use the rust-gptman crate for this, as it is packaged in Fedora 41 and actually has things like test suites. It can be backported to older distros by bundling it.


I tried reproducing the problem and with provided `deno.json` and running `deno add npm:debug` I don't get any error. @silverbucket could you please provide more information about your project?


@bartlomieju Sure what would you like to see? To answer your question, there is no package.json.

bash
$ ls -al
total 40
drwxr-xr-x@ 9 njenning staff 288 Oct 31 01:26 .
drwxr-xr-x@ 15 njenning staff 480 Aug 26 23:06 ..
-rw-r--r--@ 1 njenning staff 1077 Aug 26 23:06 LICENSE
-rw-r--r--@ 1 njenning staff 271 Aug 29 14:54 README.md
drwxr-xr-x@ 2 njenning staff 64 Oct 31 01:24 coverage
-rw-r--r--@ 1 njenning staff 823 Oct 31 01:26 deno.json
-rw-r--r--@ 1 njenning staff 5814 Aug 27 17:53 deno.lock
drwxr-xr-x@ 4 njenning staff 128 Aug 27 17:44 scripts
drwxr-xr-x@ 12 njenning staff 384 Oct 31 01:23 src

$ deno add npm:debug
Add npm:debug@4.3.7
error: Failed to install from package.json

Caused by:
 0: Invalid version requirement
 1: Unexpected character.
 ^
 ~

It might be worth mentioning that this is a mono-repo, however I've never had issues converting packages one at a time with deno 1.45, it was only upgrading to 2.0.x that I started getting issues like this.


We should improve this error message to say the file the error occurs in. Probably there's a package.json in the workspace in this case.


Absolute paths are now supported like GitHub again, per URL
For arbitrary websites, so not markdown files on GitHub/Gitlab/Bitbucket, use `remark-lint-no-dead-urls`


Please add this, has been a pain for a while. Much appreciated!


Plugin is working on the browser but not on JMP, from the logs I see this error:
`[ERR] [33] Namo.Plugin.InPlayerEpisodePreview.Api.InPlayerPreviewController: InPlayerEpisodePreviewPlugin: "Namo.Plugin.InPlayerEpisodePreview.Web.InPlayerPreview.js"
`
I already modified my nativeshell.js as instructed in the readme, it used to work fine but not anymore, any ideas?


Here is someone trying to combine separate keys using the composite signature construct. Check out IPSECME on Monday to see/influence how that goes.
 URL

Regarding your second thought, yes it protects ML-DSA but not the trad key. My point is if someone is going to end up doing this anyways, better to protect only the ML-DSA key than neither key.


Hey, the way of modifing something for JMP is deprecated.
JMP is using the frontend from the server now.
If you can't see the button. Check if you have the newest version of JMP 1.11.1 and this plugin


Even though the button is displayed and working on the web browser, I can see an error on the console:
image

The amount of time this plugin takes to troubleshoot with every jellyfin update is not worth it for me anymore, all other plugins just migrate smoothly with every jellyfin update except this one, nothing have changed from the last time this plugin was working except for the jellyfin version.


I cloned Kickstart yesterday, applied the changes on these 3 commits and got the same error.


Do we have a release plan for a fix? As of today I still experience this issue. It would be great to let the developer choose to flip or not.
Updating the UI or editing the file afterwards is not a valid solution as the Camera will show a preview of the flipped photo for confirmation, leading to incoherent user experience.
If you know how to alter the confirmation preview with the current version of the package, please let me know.


Update - I closed URL as it was not able to be reviewed and was painful to keep rebasing.

Happy to re-raise this PR again if there is capacity to review.


Hey, I was able to get the `main.log` artifact after the Workflow and Pods were deleted with latest version from `kubeflow/manifests` `v1.9.1` which uses the Kubeflow Pipelines version `2.3.0`.

I only had to put those two env variables for the `ml-pipeline-ui` Deployment and all works:

yaml
- name: ARGO_ARCHIVE_LOGS
 value: "true"
- name: DISABLE_GKE_METADATA
 value: "true"

Though still a workaround in code, it works.

Are there any plans for the proper solution that registers the `main.log` as artifact?


I do have a workaround. Not a fix, but a temporary solution to deal with this.

if you open the camera package itself, inside the .pub-cache folder, and find the camera_avfoundation-{version}
go to the ios folder then camera_avfoundation/Sources/FLTCam.m

Inside the file, find the line with

swift
connection.videoMirrored = Yes;

Change it to No and save it.

When you build using this dependency in future, your output video will be recorded without mirroring. Unfortunately your preview also becomes unmirrored, but I find its easier to apply a conditional horizontal flip with a transform widget to correct thiis.

I feel like the ideal solution in future would be to have the package be able to pass and update this property through the CameraController, then auto-apply corrections to the preview. Also keep in mind, any time replacing the dependency. ie with a new version, this property will have to be updated again.


I started working on turning the outputs into proper artifacts. There are a lot of complex design obstacles. There's no simple way to do it that preserves backend agnosticism. We have to decide if we want to rely on AWF to archive the logs and just record the relationship between the execution and the log files in MLMD, which is extremely backend-specific, or just have the launcher capture and publish logs directly, which is kind of reinventing something that AWF already does, and also doesn't account for driver logs. Bandwidth permitting, I may author a design doc. Maybe we can discuss it in the community call.


Hi all, for those who are following this thread, I started benchmarking current performance for guided decoding in vLLM here #10046


Looks like _both_ `gptman` and `gpt` have the same bug: neither includes necessary calls to `fsync()`, and so both risk leaving the system unbootable in the event of power loss!


After a long wait, a few of the folks here are still not members of the OpenTelemetry organization. Unfortunately, it is time to move you to emeritus. See URL

If you have any problem with this approach, please get in touch.


Hey @dmitryax,

We're exploring a specific use case and wanted to get your thoughts. The scenario involves multiple receivers within a single running collector instance that may need to operate in singleton mode, using leader election. To support this, each receiver might need its own lease, allowing each to be managed by a different leader.

We're considering two possible approaches:

1. Embedding the lease configuration directly within each interested receiver’s configuration.
2. Creating multiple instances of a new extension, like `singleton/foo` and `singleton/bar`, each referenced by its respective receiver.

The second approach seems simpler to implement. However, from what I’ve seen, there aren’t any examples in the wild of multiple instances of extensions being registered. Do you think this approach would be feasible?


Closing as this is not an issue, and making the full rescan reimport all timestamps is being handled in #2709


@marmarek: can the tool that converts from 512 to 4K and back be provided with the previous sector size (perhaps from metadata somewhere), or does it need to guess the previous sector size? The latter could be problematic if there are multiple GPTs on the disk.


You can get the current sector size (from sysfs?) and check if the current GPT matches. If not, do the conversion.


Yes, we just use `targets = None` and vanilla GradCAM from the pytorch-grad-cam library ( URL


Code is done now. I just added a new field, because this was the last thing that Kingfisher Process extracted.

The Publication (Collection) also has a publication policy field now. If empty, it will be populated by the job's publication policy from Kingfisher Process. Otherwise, we can provide a manual value that will never be overridden.

Assigning to @yolile to populate whenever (if desired, we could do `scrapy pluck --package-pointer /publicationPolicy` to see which jobs will get a value next time they run).


I would like to move forward with Option 2:

* Dual build 1.14.3 and 1.14.4/5/6

while this gets resolved upstream.

This isn't too different than what we've done in the past with HDF5 updates. HDF5 updates often take time, and the libraries that consume them can be quite old (due to the strong history of HDF5) and makes it difficult for packages to migrate.

I feel like 1.14.4/5 is actually quite disruptive to the ecosystem as a whole, while the UTF-8 issue isn't resolved.

Thoughts are welcome.

I've rebuilt 1.14.3 with the new features that have been contributed.

If an other maintainer agrees I have a checklist of the next steps outlined in URL


I've updated some, but I think it would be easier to wait for the auto-update and then change or add the missings


Hi @atoulme,

Thank you very much for your understanding. I need one more sponsor. How should I proceed?


Hi @atoulme,

Thank you very much for your understanding. I need one more sponsor. I am trying to find a sponsor.

 URL


@metaruslan Thank you for using the plugin and submitting feedbacks! You can configure log colors from the **Settings > Editor > Color Scheme > Console Colors > Log console**. I also wonder why JetBrains uses white instead of yellow as the default warning color.

<img width="1094" alt="image" src=" URL


I'm actually going to reopen this and we can close it once #2709 is merged and officially released. That way the author can get notified of the fix being available.


Being able to use alternate encodings would be nice. In my project I need to build an index of all tag data (title/artist/genre/etc). I'm guessing these files are in UTF16 so I'm having the same issue.

They are able to be read in KDE Elisa. I think that project uses taglib though.


Do your files have other tags? In the case of the file provided in this issue, it has both a RIFF INFO and an ID3v2 tag. Elisa ends up just using the data from the ID3v2 tag and logs UTF-8 errors for the RIFF INFO tag.


I added metadata to several .wav files with musicbrainz picard. I think picard adds ID3v2 tags and RIFF Info tags to wavs by default. How would I check the tag types?

Running `ffprobe` against it shows the metadata with a warning simlar to: `[json @ 0x5664cd0010c0] 1 invalid UTF-8 sequence(s) found in string 'Example�s', replaced with '�'`. The missing character should be an apostrophe.

I have another file with the ellipses character. It also fails in lofty. No errors in ffprobe or elisa.

I have other files with non-english characters. They play in Elisa and I can view the metadata correctly there. When I pass the files into lofty, I get the following error: `FileDecoding(Wav: "Failed to read RIFF INFO item value")`


That's probably it. Most serious music players will check all tags to fill in any missing fields. Trying to load a non UTF-8 RIFF INFO tag with Elisa will log errors, and it will fallback to the info it can get from the ID3v2 tag. Elisa just depends on `KFileMetaData` which uses TagLib, and as far as I can tell they don't set a `StringHandler`.

I will say, a hard error shouldn't be the case outside of `ParsingMode::Strict`. That's something I can fix (just ignore it and log a warning, like TagLib).

I use kid3 to see what tags a file has. It uses TagLib, and with the asset provided in the issue, it ignores any field in the RIFF INFO tag that it can't parse as UTF-8.


I downloaded the kid3 program. The files that failed to read in lofy had an ID3 **and** a RIFF tag. Some also had extra tags, but it didn't list a type or any info.

I noticed some files display the data correctly in the ID3 tag, but show an empty entry in the RIFF tag. For example, the file with the invalid UTF8 warning when inspected with ffprobe had an apostrophe in the title. It is visible in the ID3 tag, but the RIFF tag shows the title as empty (key exists, no value). Other values were replaced instead. ID3 has a - (dash) in the artist entry while RIFF has a ? (question mark).


Kid3 puts markers to show that you can add another tag to the file, not necessarily that it's present, BTW.

Yeah, I haven't actually seen anyone make use of TagLib's `StringHandler`. I imagine in most cases no errors are noticed since Picard (and likely other tools) add an ID3v2 tag for compatibility. The real issue here is that in Lofty it's a hard error, rather than a discard & warn.


Using deno `2.0.6` I'm getting another variation of this bug. Same repo I mentioned about, this time it's not with the `package.json` at the root of the repository, but a different pacakge at the same level as the `schemas` package.

bash
project-root/packages/schemas $ deno install
error: Failed to install '@sockethub/client'
 at file:///project-root/packages/examples/package.json

Caused by:
 0: Invalid version requirement
 1: Unexpected character.
 ^
 ~


From above, I think in the future, `ParsingMode::Strict = false` will cause `read_from` to log Err instead of returning Err when encountering a tag that cannot be parsed correctly. If at least one tag is parsed properly, read_from will still return OK. Otherwise, the Err will be returned.


FYI, our latest recommendation is URL and if you need custom equality function, `use-sync-external-store` would do:

js
import {
 createContext as createContextOrig,
 useContext as useContextOrig,
 useRef,
} from 'react';
import { useSyncExternalStoreWithSelector } from 'use-sync-external-store/with-selector';

export const createContext = (defaultValue) => {
 const context = createContextOrig();
 const ProviderOrig = context.Provider;
 context.Provider = ({ value, children }) => {
 const storeRef = useRef();
 let store = storeRef.current;
 if (!store) {
 const listeners = new Set();
 store = {
 value,
 subscribe: (l) => { listeners.add(l); return () => listeners.delete(l); },
 notify: () => listeners.forEach((l) => l()),
 }
 storeRef.current = store;
 }
 useEffect(() => {
 if (!Object.is(store.value, value)) {
 store.value = value;
 store.notify();
 }
 });
 return {children}
 };
 return context;
}

export const useContextSelector = (context, selector, equalityFn) => {
 const store = useContextOrig(context);
 return useSyncExternalStoreWithSelector(
 store.subscribe,
 () => selector(store.value),
 undefined,
 equalityFn
 );
};

With that, let's close this.


Yes! The new routine was meant for CuPy and other projects to implement `eig` and `eigvals`.


Not sure if this is the right place to discuss implementation details, but I wanted to ask if the output makes sense.

shell
$pwd
/Users/rustin/code/rs-scripts

$ls
sql.rs sql1.rs sql2.rs sql3.rs sql4.rs sql5.rs sql6.rs sql7.rs sql8.rs sql9.rs

$cargo pkgid sql2.rs
path+file:///Users/rustin/code/rs-scripts/sql2.rs#embedded


@Rustin170506 I feel like there might be enough discussion on that that maybe we should create a dedicated issue?


Interesting! I've never heard of this app, but I think it will be helpful for my project. I was using picard to inspect metadata but this one seems better for what I need.


@nathanwhit Should I create a new ticket? Or can you re-open this one?


Hi! As I know for pod metrics to work you should have prometheus installed inside your k8s cluster


Is this a headlamp requirement? Since pod metrics generally works fine without it as per my snapshot in earlier post above


It would be great to be able to change Data Summary panel behavior in Settings similar to enabling/disabling Column Insight.


Yes, headlamp use prometheus plugin for rendering metrics, it search for a prometheus instance inside of the k8s cluster and grab metrics from it.


Same here:

log
Nov 13 21:19:50 sisyphus .cosmic-comp-wrapped[2139]: thread 'main' panicked at 'called `Option::unwrap()` on a `None` value': src/shell/mod.rs:974
 0: ::default
 1: log_panics::Config::install_panic_hook::{{closure}}
 2: std::panicking::rust_panic_with_hook
 3: std::panicking::begin_panic_handler::{{closure}}
 4: std::sys::backtrace::__rust_end_short_backtrace
 5: rust_begin_unwind
 6: core::panicking::panic_fmt
 7: core::panicking::panic
 8: core::option::unwrap_failed
 9: cosmic_comp::shell::Workspaces::active
 10: cosmic_comp::input:: ::surface_under
 11: cosmic_comp::shell::focus:: ::refresh_focus
 12: calloop::loop_logic::EventLoop ::run
 13: cosmic_comp::main
 14: std::sys::backtrace::__rust_begin_short_backtrace
 15: main
 16: __libc_start_call_main
 17: __libc_start_main_alias_2
 18: _start
Nov 13 21:19:50 sisyphus .cosmic-comp-wrapped[2139]: thread 'surface-DP-1' panicked at 'called `Result::unwrap()` on an `Err` value: PoisonError { .. }': src/backend/kms/surface/mod.rs:1124
 0: ::default
 1: log_panics::Config::install_panic_hook::{{closure}}
 2: std::panicking::rust_panic_with_hook
 3: std::panicking::begin_panic_handler::{{closure}}
 4: std::sys::backtrace::__rust_end_short_backtrace
 5: rust_begin_unwind
 6: core::panicking::panic_fmt
 7: core::result::unwrap_failed
 8: cosmic_comp::backend::kms::surface::SurfaceThreadState::redraw
 9: > as calloop::sources::EventDispatcher >::process_events
 10: cosmic_comp::backend::kms::surface::surface_thread
 11: std::sys::backtrace::__rust_begin_short_backtrace
 12: core::ops::function::FnOnce::call_once{{vtable.shim}}
 13: std::sys::pal::unix::thread::Thread::new::thread_start
 14: start_thread
 15: __GI___clone3
Nov 13 21:19:50 sisyphus .xdg-desktop-po[2723]: Error reading events from display: Broken pipe
Nov 13 21:19:50 sisyphus cosmic-session[2122]: Io error: Broken pipe (os error 32)
Nov 13 21:19:50 sisyphus systemd[2100]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
Nov 13 21:19:50 sisyphus systemd[2100]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
Nov 13 21:19:50 sisyphus cosmic-session[2122]: process ' COSMIC_SESSION_SOCK=12 cosmic-comp ' failed with code 101
Nov 13 21:19:50 sisyphus pipewire[2382]: mod.x11-bell: X11 I/O error handler called on display :1
Nov 13 21:19:50 sisyphus pipewire[2382]: mod.x11-bell: X11 display (:1) has encountered a fatal I/O error
Nov 13 21:19:50 sisyphus systemd[2100]: cosmic-launcher.scope: Consumed 41min 35.720s CPU time, 653.5M memory peak.
Nov 13 21:19:50 sisyphus systemd[2100]: app-cosmic-google-chrome-30911.scope: Consumed 3min 23.597s CPU time, 1.4G memory peak.
Nov 13 21:19:50 sisyphus cosmic-session[2122]: cosmic-comp exited with error code 101


Hi @manju-rn you can try installing prometheus in Headlamp app by selecting the Apps page from the sidebar. Please check prometheus plugins for more information.


Hmm we're putting the dependency in the correct file now, but we error out because we validate all of the `package.json` files in the workspace when we cache the dependencies, and one of them has a version requirement (`workspace:^`) that we don't support.

I feel like maybe we should make `workspace:^` not a hard error? Or at least not a parsing error


I think this is a duplicate of #679, which might trace back to #57. This is also being tracked in pop-os/cosmic-epoch#84.


Interesting. Somehow we are calling an action in home assistant which is not allowed for this cover. Did it work before?

Can you set the log level to debug and then try again? It will then log the exact action it is trying to call.


I saw some issue with covers. Mostly some were reversed. Was showing they were open while closed, and up/down command was inverted.
Funny thing, I have 4 x covers which are the same brand devices , 2 of them were ok but 2 others were working inverted on GH.

On HA side they were having the same data, this looked a bit non sense.

I'll track this down and get some debug data.


Updated to the alpha. 32 and my smart blinds reversed direction in Google home. Before they worked normally but now the open and close direction and state is the opposite in Google home

 Open is closed and closed is open. Also 26% open in home assistant is now 74% open in Google home.


FWIW, I was seeing this error when I had the latest jdtls installed (1.41), upon adding `github:nvim-java/mason-registry` to mason registries it installed the ver.1.37 for me which fixed the issue.


I'm also getting the same issue, I can provide details:

### Versions
**Neovim version**
v0.10.2

**Operating system/version**
MacOS Version 15.1

**`java-debug-adapter` version**
0.58.0

**`java-test` version**
 0.40.1
note: this version seems to be locked, since everytime I try to update it will reinstall this exact version

**`jdtls` version**
v1.37.0

**JDK version**
openjdk version "17.0.12" 2024-07-16
OpenJDK Runtime Environment JBR-17.0.12+1-1087.25-jcef (build 17.0.12+1-b1087.25)
OpenJDK 64-Bit Server VM JBR-17.0.12+1-1087.25-jcef (build 17.0.12+1-b1087.25, mixed mode)

I use kickstart.nvim, with similar setup as above but simpler:

 {
 'nvim-java/nvim-java',
 config = function()
 require('java').setup {
 java_debug_adapter = {
 enable = false,
 },
 }
 end,
 },
 {
 'neovim/nvim-lspconfig',
 config = function()
 local servers = {
 jdtls = {},
 }

 require('mason').setup()

 local ensure_installed = vim.tbl_keys(servers or {})
 vim.list_extend(ensure_installed, {
 'stylua', -- Used to format lua code
 })
 require('mason-tool-installer').setup { ensure_installed = ensure_installed }

 require('mason-lspconfig').setup {
 handlers = {
 function(server_name)
 local server = servers[server_name] or {}
 server.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {})
 require('lspconfig')[server_name].setup(server)
 end,
 },
 }
 end
 }

I got this error on opening a java file, even though I already disabled the DAP

# result from :messages
Error executing vim.schedule lua callback: ...al/share/nvim/lazy/nvim-java/lua/java/handlers/error.lua:28:
dap configuration failed
RPC[Error] code_name = MethodNotFound, message = "No delegateCommandHandler for vscode.java.resolveMainClass"
stack traceback:
 ...al/share/nvim/lazy/nvim-java/lua/java/handlers/error.lua:18: in function 'error_handler'
 ...e/nvim/lazy/nvim-java-core/lua/java-core/utils/async.lua:32: in function 'callback'
 ...nvim-java-core/lua/java-core/ls/clients/jdtls-client.lua:72: in function 'handler'
 ...eovim/0.10.2_1/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
 vim/_editor.lua: in function

Hope this clarifies.


So first things first:
- Matter specifies 0% as "open" and 100% as "closed".
- Home Assistant specifies 100% as "open" and 0% as "closed".

So I needed to reverse covers in general. To indicate that it's reversed, i used the `configStatus.liftMovementReversed` flag (this is what has changed) - maybe it was wrong doing both.

I'll remove that property to test it.


I did some digging into this and here's what I found:
1. Handling of `workspace:` specifiers in `package.json` is done here: URL
2. The `workspace:` prefix is stripped and the remainder is passed to `VersionReq::parse_from_npm` from `deno_semver`: URL
3. `*` or `x.y.z` are valid ranges in this context, but `~` and `^` are not
4. It appears that simply stripping `workspace:` is not good enough here and we should have a dedicated functionality in `deno_semver` to handle `workspace:` version constraints that will accept `~` and `^`, otherwise we'd have to alter the current parsing which would break other stuff, because `"mypackage": "^"` is not a valid range, but `"mypackage": "workspace:^"` is.

@dsherret do you agree here?


Not sure it will be sufficient, as not all my covers here looks inverted. Some are reporting open when opened, I have one coming from HomeKit and this one is always inverted.

I've tryed to set configStatus.liftMovementReversed to false, and then the working ones actions are working in reverse ( Opening close, and closing open.. But state looks eratic. Sometime it says it's open when close, and sometime it reports the correct state. I'm trying to find a logic behind that.


Does your cover support positions, or does it only support open and close?
After calling the `set_cover_position` it shows an error, that this service call is not supported.

Can you try calling that service manually from the home assistant dev tools?
- Service: `cover.set_cover_position`
- Target: `{"entity_id":"cover.ratgdo_door"}`
- Data: `{"position":100}'


Yeah, I get the same error in dev tools: `Failed to perform the action cover.set_cover_position. Entity cover.ratgdo_door does not support this service.`

This cover if for a garage door and it only supports open/close/stop.


Okay, can you post a screenshot of the attributes of this entity?
(HA -> Dev Tools -> State -> search for your entity)

Is there any indication where i can detect if it supports position awareness?


okay got it. actually i hoped that i dont need to parse `supported_features` since its deprecated for other domains. 😀


I have a cover with supported_feature 3. It only has up/down and state open/close, and probably stop.
Actually matter bridge only expose up down button but no state.


I've added support for "not position aware".

Also i reverted one change, which COULD be related to the missing percentage in GH. Just let me know.


still the same here, all covers have only up down buttons and no feedback/state.
Will try to catch some data tomorrow.


Just on thing I can give for now, Garage door now crash the bridge at startup:

Behaviors have errors
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/endpoint/properties/Behaviors.js:128:21
 at all (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/general/dist/esm/util/Construction.js:375:17)
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/general/dist/esm/util/Construction.js:365:11
 Cause #0: Error initializing 435459ea97854796829ca31284021754.aggregator.cover_porte_garage.windowCovering
 at crash (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/internal/BehaviorBacking.js:48:13)
 Caused by: Validating 435459ea97854796829ca31284021754.aggregator.cover_porte_garage.windowCovering.state: Conformance "LF & PA_LF": Matter does not allow you to set this attribute (128)
 at disallowValue (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/validation/conformance-compiler.js:305:13)
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/validation/conformance.js:13:15
 at file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/managed/values/StructManager.js:135:13
 at Object.change (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/managed/Datasource.js:172:7)
 at WindowCovering$State.set [as currentPositionLiftPercent100ths] (file:///usr/local/lib/node_modules/home-assistant-matter-hub/node_modules/@matter/node/dist/esm/behavior/state/managed/values/StructManager.js:105:32)
 at Function.assign ( )
 at applyPatchState (file:///usr/local/lib/node_modules/home-assistant-matter-hub/dist/backend/cli.js:888:14)
 at WindowCoveringServer.update (file:///usr/local/lib/node_modules/home-assistant-matter-hub/dist/backend/cli.js:1618:5)
 at WindowCoveringServer.initialize (file:///usr/local/lib/node_modules/home-assistant-matter-hub/dist/backend/cli.js:1609:10)


Also here are the data of one of my cover that only displays the up/down buttons and no state/position percent since alpha 33:

{
 "entityId": "cover.stores_buanderie",
 "endpointCode": "202",
 "endpointType": "WindowCovering",
 "state": {
 "identify": {
 "isIdentifying": false,
 "clusterRevision": 4,
 "identifyTime": 0,
 "identifyType": 0,
 "featureMap": {

 },
 "attributeList": [0, 1, 65533, 65532, 65531, 65529, 65528],
 "eventList": [],
 "acceptedCommandList": [0],
 "generatedCommandList": []
 },
 "bridgedDeviceBasicInformation": {
 "clusterRevision": 3,
 "vendorName": "t0bst4r",
 "vendorId": 65521,
 "productName": "MatterHub",
 "nodeLabel": "Stores Buanderie",
 "hardwareVersion": 2024,
 "softwareVersion": 2024,
 "productLabel": "Home Assistant Matter Hub",
 "reachable": true,
 "featureMap": {

 },
 "attributeList": [1, 2, 3, 5, 7, 9, 14, 17, 65533, 65532, 65531, 65529, 65528],
 "eventList": [],
 "acceptedCommandList": [],
 "generatedCommandList": []
 },
 "windowCovering": {
 "supportsCalibration": false,
 "supportsMaintenanceMode": true,
 "clusterRevision": 5,
 "featureMap": {
 "lift": true,
 "tilt": false,
 "positionAwareLift": true,
 "absolutePosition": true,
 "positionAwareTilt": false
 },
 "type": 0,
 "currentPositionLift": 10000,
 "configStatus": {
 "operational": true,
 "onlineReserved": false,
 "liftMovementReversed": true,
 "liftPositionAware": true,
 "tiltPositionAware": false,
 "liftEncoderControlled": false,
 "tiltEncoderControlled": false
 },
 "currentPositionLiftPercentage": 100,
 "operationalStatus": {
 "global": 0,
 "lift": 0
 },
 "targetPositionLiftPercent100ths": 10000,
 "endProductType": 0,
 "currentPositionLiftPercent100ths": 10000,
 "installedOpenLimitLift": 0,
 "installedClosedLimitLift": 10000,
 "mode": {
 "motorDirectionReversed": false,
 "calibrationMode": false,
 "maintenanceMode": false,
 "ledFeedback": false
 },
 "attributeList": [0, 7, 10, 13, 23, 65533, 65532, 65531, 65529, 65528, 16, 17, 11, 14],
 "eventList": [],
 "acceptedCommandList": [0, 1, 2, 5, 4],
 "generatedCommandList": []
 },
 "descriptor": {
 "clusterRevision": 2,
 "featureMap": {
 "tagList": false
 },
 "deviceTypeList": [
 {
 "deviceType": 514,
 "revision": 3
 },
 {
 "deviceType": 19,
 "revision": 2
 }
 ],
 "serverList": [3, 57, 258, 29],
 "clientList": [],
 "partsList": [],
 "attributeList": [0, 1, 2, 3, 65533, 65532, 65531, 65529, 65528],
 "eventList": [],
 "acceptedCommandList": [],
 "generatedCommandList": []
 }
 }
 },

image


The crash during startup should be fixed.

The attributes don't look wrong tbh. I'll validate them tomorrow.


I've made some test with previous version.

With alpha-32 I still have the cover position + closed/opened state on GH.
image

Starting with alpha-33, only up/down button withtout state/position feedback.
image

The only differences I see from the dev tools log is "targetPositionLiftPercent100ths": 5000 with latest alpha, and "targetPositionLiftPercent100ths": 100, with alpha-32 working one


Hm. i was suspecting the `targetPositionLiftPercent100ths` to cause it, but that's why i reverted my change in `alpha.34`:

 URL

Here is the diff between `alpha.32` and `alpha.36`:
 URL

In the end, i am always setting it if your cover is position aware.


This issue is being closed due to a lack of discussion or resolution for over 12 months. Should we decide to revisit this issue in the future, it can be reopened.


`targetPositionLiftPercent100ths` is not in percent. It’s `percent * 100`.
So 100 is 1% and 5000 is 50%.


I see. It shouldn't be at 50% as it's open, and 32 reports 1% at the same time.


Can you describe what exactly is not working?
Can you share the attributes (Home Assistant -> dev tools -> state -> search for the entity) of the generic cover) ?
Are there any error logs in the addon?


image

Nothing works. In smartthings I have 3 buttons, open, close and stop and one position from 0 to 100%
Position is made by a sensor. When reach it's close.

` volet_bureau:
 friendly_name: "Volet Bureau 2"
 unique_id: VWoQmdAes2Y8wZ0fsM13
 position_template: "{{ (states('binary_sensor.lumi_lumi_sensor_magnet_aq2_opening_21') == 'off')|int * 100 }}"
 open_cover:
 service: cover.open_cover
 data:
 entity_id: cover.volet_bureau
 close_cover:
 service: cover.close_cover
 data:
 entity_id: cover.volet_bureau
 stop_cover:
 service: cover.stop_cover
 data:
 entity_id: cover.volet_bureau`


You don't need to fake the position attribute with a template on HA. Just keeping the open/closed state is sufficient.

"supported_feature" will be 3 then.

Because if you add position, then HA will add the set position command too.


- Do you see the cover in the matter web ui?
- If yes, do you **see** the cover in google home after pairing?
- If yes, what buttons do you see? What happens when you press them?

 Please answer **all** of the above questions, and attach the addon logs and your bridge configuration from within the matter web ui.


@t0bst4r , do you prefer I create a separated issue for this ?


For those coming to this issue, if the device supports going back to 512 bytes then you can apply the commands in URL as a temporary solution until this is fixed (currently using it myself and don't notice any performance issues, so far it has been even faster than 4k and btrfs)


Please visit #444 also.

Speaking of improvements, I'd like infallible (and preferably non-panicking) store functions; they seem more optimal. They could be implemented as in URL


I get a similar error when trying to "wake up" my computer after sleep.

Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: Failed to destroy old mode property blob: No such file or directory (os error 2)
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: Failed to set new config.
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: failed to create signaled syncobj
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:53 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:54 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:54 .cosmic-comp-wrapped[1514]: ignoring requested context priority, EGL_IMG_context_priority not supported
Nov 18 16:36:59 .cosmic-comp-wrapped[1514]: Failed to destroy old mode property blob: No such file or directory (os error 2)
Nov 18 16:36:59 .cosmic-comp-wrapped[1514]: thread 'surface-HDMI-A-1' panicked at 'internal error: entered unreachable code': src/backend/kms/surface/mod.rs:780
 0: ::default
 1: log_panics::Config::install_panic_hook::{{closure}}
 2: std::panicking::rust_panic_with_hook
 3: std::panicking::begin_panic_handler::{{closure}}
 4: std::sys::backtrace::__rust_end_short_backtrace
 5: rust_begin_unwind
 6: core::panicking::panic_fmt
 7: core::panicking::panic
 8: > as calloop::sources::EventDispatcher >::process_events::{{closure}}
 9: > as calloop::sources::EventDispatcher >::process_events
 10: cosmic_comp::backend::kms::surface::surface_thread
 11: std::sys::backtrace::__rust_begin_short_backtrace
 12: core::ops::function::FnOnce::call_once{{vtable.shim}}
 13: std::sys::pal::unix::thread::Thread::new::thread_start
 14: start_thread
 15: clone3

System is NixOs using the stable branch. Cosmic versions are

cosmic-applets-1.0.0-alpha.2-unstable-2024-10-21
cosmic-applibrary-1.0.0-alpha.2-unstable-2024-10-24
cosmic-bg-1.0.0-alpha.2-unstable-2024-10-09
cosmic-comp-1.0.0-alpha.2-unstable-2024-10-25
cosmic-edit-1.0.0-alpha.2-unstable-2024-10-29
cosmic-files-1.0.0-alpha.2-unstable-2024-10-29
cosmic-greeter-1.0.0-alpha.2-unstable-2024-10-14
cosmic-icons-1.0.0-alpha.2-unstable-2024-10-02
cosmic-idle-0-unstable-2024-10-30
cosmic-launcher-1.0.0-alpha.2-unstable-2024-10-29
cosmic-notifications-1.0.0-alpha.2-unstable-2024-10-24
cosmic-osd-1.0.0-alpha.2-unstable-2024-10-09
cosmic-panel-1.0.0-alpha.2-unstable-2024-10-22
cosmic-randr-1.0.0-alpha.2-unstable-2024-10-24
cosmic-screenshot-1.0.0-alpha.2-unstable-2024-07-25
cosmic-session-1.0.0-alpha.2-unstable-2024-10-30
cosmic-settings-1.0.0-alpha.2-unstable-2024-10-30
cosmic-settings-daemon-1.0.0-alpha.2-unstable-2024-09-26
cosmic-term-1.0.0-alpha.2-unstable-2024-10-30
cosmic-wallpapers-1.0.0-alpha.2-unstable-2024-09-27
cosmic-workspaces-epoch-1.0.0-alpha.2-unstable-2024-08-07
xdg-desktop-portal-cosmic-1.0.0-alpha.2-unstable-2024-10-10


It looks good, but I think we probably dont' need any changes in deno_semver. Probably it could just be handled in deno_package_json (I'm not sure though)


This issue has been automatically closed due to a lack of discussion or resolution for over 12 months.
Should we decide to revisit this issue in the future, it can be reopened.


Yes but without a template i can't keep position when using cover trigger.


Yes
image

Yes
All button are grey. I can't interact with them. When using google home cloud integration it's ok


Smart blinds for me now show up only as UP and DOWN. In earlier versions I could set them at a specific height just like in home assistant.
I could even use google assistant to specify the exact number between 0 and 100 to state how much I wanted the blinds to be open.
Now there are just two options - fully open or fully closed.
Previously was better I think.


_From @rolfbjarne on Fri, 15 Nov 2024 19:29:01 GMT_

Could you get an MSBuild binlog and attach it here? Thanks!


_From @bwinklesky on Fri, 15 Nov 2024 19:52:13 GMT_

msbuild.binlog.zip

Let me know if this doesn't work


_From @rolfbjarne on Mon, 18 Nov 2024 08:13:11 GMT_

Unfortunately that didn't give me many clues.

Is there any chance we could get access to your project to compile it ourselves?


_From @bwinklesky on Mon, 18 Nov 2024 19:06:13 GMT_

@rolfbjarne I created a respository and gave you access. WasatchBackcountryAlliance is the app to build.

I ask that you destroy the source code after you've diagnosed the issue.


_From @rolfbjarne on Tue, 19 Nov 2024 12:28:31 GMT_

I confirm I can reproduce the problem; I'll see if I can figure out where to route the bug and create a smaller test project that doesn't involve any of your code.


_From @formerlymisterhenson on Tue, 19 Nov 2024 13:27:19 GMT_

Well this error occured in my project as well, I went with:

 True
 -all,System.Private.Windows.Core


Just to let you know that I have this problem also - exactly as described above. I gave the solution from @formerlymisterhenson a shot and my build has now completed OK. However, not sure whether

 True
 -all,System.Private.Windows.Core

 is going to have any adverse effects?


Hi folks! Thank you very much for your patience and for providing great feedback on this issue.

We've just added a setting to disable the automatic panel behaviour in pre-release version 1.13.3. The following setting needs to be disabled to prevent the panels from appearing on startup and on tab focus:
Image

Please feel free to give this a try and let us know if you have any additional feedback. Thanks!


Hi folks! Just wanted to let you know that there is now an option to not automatically reveal the panels (both on startup and on tab switch) in pre-release version 1.13.3.

For more details, please see: URL

Will close this issue for now since this setting should address the pain points mentioned here, but please feel free to reopen if you have additional feedback. Thanks!


This is a very interesting feature, and many of the plugins in otel col contrib are currently restricted to running on a single instance.


Finally! :) Thanks a lot. I can confirm it is indeed working on the pre-release version


This is my quick'n'dirty implementation:
PIF N64Digital fix
IMG_5688


@marcokreeft87 I think I'll create a seperate docker monitoring module that pulls these metrics and have it as an option in the integration setup / configuration. Just in case no one else wants to see this type of metrics and extra sensors.

 - version
 - containers_running
 - containers_paused
 - containers_stopped
 - containers_cpu_percentage
 - containers_memory_percentage
 - cpu_percentage
 - health
 - uptime
 - memory
 - memory_percentage
 - network_speed_up
 - network_speed_down


@BrzVlad could you please repro from Rolf's repro and get a real callstack - the one in the crash report is probably without symbols. That should help us triage this better.


no let's just do it here. 👍
I'm currently looking into it again.


I just see no difference at all. With Alexa I get the level control, too.

Can you please try pairing a whole new bridge?
Maybe there is some kind of caching in place.


Damn it. Do you still have your test-setup running? I just don't understand, that it's working for me with Alexa.
Can you _again_ share the json from dev tools from both versions, 32 and current - for the SAME cover and with no changes to the cover in between of course 😁

I am not sure which attribute to use here.
To be honest: to "know" if its open or closed is already position aware, isn't it?

---

i just checked the matter specification and found that it is not recommended to use the "AbsolutePosition" feature. So I'll remove that, but keep the "PositionAwareLift" as it is for now.


So something strange. I've just opened GH app, and see my covers have now the correct slider with position.

Seems my GH speaker has updated to preview fw 444798.

However, if I move the cover position from HA, it doesn't update the state on GH side .


We did some investigation and agree that implementing leader election as an extension is indeed a cleaner solution. We will provide a PR with the implementation soon.


Thank you for your submission. After careful review, we regret to inform you that we cannot proceed with your application at this time, as a Rust SDK has already been implemented as part of the Bounty program (see bounty #182).


I'm on the Matter specs now, I'm also surprised there's no dedicated cluster for open/close state.
I think then it has to be simulated for devices with no position feedback by jumping CurrentPositionLiftPercentage to 100% when HA cover state is "closed" or 0% when "open".

Not totally related, but I also saw this endpoint for moving state:

- 5.3.5.3. OperationalStatusBitmap Type
This endpoint display opening/closing/not moving state

I see a problem on current implementation as this value comes from another ha entity.
Cover devices have cover entity , + can have additional sensors entities:
- moving state : STOP, UP, DOWN
- open/close binary sensor ( ie garage doors have this separated , I had to create a cover template to add this sensor as the cover state value )

Dunno on an entity based bridge how can it be implemented.
Device based bridge is probably needed for this ( this is how it's implemented on zigbee2mqtt matter bridge )


Note to self: if we ever put something on the EFI partition of the template's root volume, create filesystem there with 4k block size.


🤦

Can you confirm that google home is always in sync with "target position" instead of "current position" ?
We don't have target position in home assistant, right? At least I don't have it. So i could sync target position with current position, but doesn't really make sense...

For ALL covers? As I mentioned earlier:
Matter open = 0% and close = 100%
HA open = 100% and close = 0%

Therefore I am inverting. Can you test using "open cover" command (without percentage) to verify that it's REALLY inverted?

Yes, but users could be confused by it, when trying to set the position to 30% in GH 😀

But isn't that a problem of the integration. If the cover supports it, shouldn't it be part of the cover entity?
Anyway I am already using/used it for covers. I just need to re-add it for non-position-aware covers.

To make it clear:
I don't have a problem with device based bridge, it's just a matter of effort vs. available time at the moment 😀


One more thing I'd like to test:
at the moment, position aware covers get the following features: "Lift", "PositionAwareLift" and "AbsolutePosition".
As per matter specification "Absolute Position" should not be used anymore:

for new implementations.

So I'll remove it, so maybe thiings get better with that.


I'm not sure how to check that. If I move a cover from HA, then it doesn't update on GH. Seems like GH is keeping its own states for whatever reason.
 Commands are only inverted when states are not in synch, like closed in HA and Open in GH.

This could be related to Absolute Positioning so let's try without.

I have not much time this week end but I'll try to gather some data about what's happening.


I have already released it to `alpha.38`, so give it a try.

---

Anyway i am now even more confused regarding inversion:

Alexa: open = 0% and close = 100%

Alexa shows as a title for the percentage: `Öffnungsgrad` (translates to `Degree of openness`)
As of my understanding `degree of openness` of `0%` would mean closed, but it's not 😀

So when Asking it to "close", it sets the position to 100% - as specified.
But from a natural language perspective it is counter-intuitive. 😀


Just tested, you won't like it ^^

- Now all position aware covers have only 2 buttons, but with state:
image
That's the UI the garage door should have then, but it still have the 2 buttons without state:
image
- State follows on HA when cover is triggered from GH But on the other way, when triggered from HA, states follows when achieving close or open, thereafter it switch back to the other state ( i.e. Cover is open, I close it from HA, I see cover state as closed when closed, then a sec after, it switch back to open state.
- after upgrading to 38, all devices were recognised as new devices, I had to remap them to each room. Btw, not really important in alpha stage. Got this on log at startup for each device:
` [ 2024-11-23T13:32:20.373Z ] [ WARN ] [ matter.js / EndpointStoreService ]: Stored number 42 is already allocated to another endpoint, ignoring
`


Same here.
2024-11-24 01:25:55,693 - INFO - stderr: File "/usr/lib64/python2.7/multiprocessing/managers.py", line 625, in _finalize_manager
2024-11-24 01:25:55,693 - INFO - stderr: process.terminate()
2024-11-24 01:25:55,882 - INFO - stderr: File "/usr/lib64/python2.7/multiprocessing/process.py", line 137, in terminate
2024-11-24 01:25:55,882 - INFO - stderr: self._popen.terminate()
2024-11-24 01:25:55,882 - INFO - stderr: File "/usr/lib64/python2.7/multiprocessing/forking.py", line 171, in terminate
2024-11-24 01:25:55,882 - INFO - stderr: os.kill(self.pid, signal.SIGTERM)
2024-11-24 01:25:56,206 - INFO - stdout: Creates the upgrade initramfs
2024-11-24 01:25:56,206 - INFO - stderr: OSError: [Errno 3] No such process
2024-11-24 01:25:56,207 - ERROR - Command ['/usr/bin/leapp', 'upgrade'] failed with return code 1
2024-11-24 01:25:56,207 - ERROR - Failed: doing the conversion. The reason: Command '['/usr/bin/leapp', 'upgrade']' returned non-zero exit status 1.


@marcokreeft87 I created a docker insights module for the integration.

The following sensors gets created

1. Container CPU Usage
2. Container Memory Usage
3. Container Network Download / Upload
4. Total Containers
5. Running Containers
6. Paused Containers

Feel free to checkout the experimental feature and let me know what you think

You will need to copy the unraid folder from experiment/docker-insights branch to your home assistant instance.

You can only enable docker insights after the initial configuration setup and it takes about a minute to initialise and create the sensors.

Screenshot 2024-11-24 at 4 53 54 pm

You will see 2 device entries after initialisation

Screenshot 2024-11-24 at 4 55 05 pm

I'll look if its possible to get docker uptime data


Just installed it. But first issue I see is I have all new entities now for the old values:

image

And some are not working anymore:

image


I made updates to the code to fix a unique ID issue with sensors and it also now gets the unraid hostname to use with naming convention of sensors. This allows you to add multiple unraid servers without issues.

Unfortunately the update doesn't migrate existing entities to new ones.

Best is to remove the integration and start fresh. Sorry about that


Hello @gokhand,
I cannot find a specific reason for the failure of the preupgrade. Is it possible that there was a lack of available RAM, and the process was terminated by the OOM killer, for example?
Could you please run `leapp preupgrade` manually and share the results with me? Please include the return code


Hi,

This topic sounds quite interesting to me. Is there anyone already working on this? If not I would like to work on this (and #3255 as well) :)

BR


There appears to be an issue with your /etc/fstab configuration that is preventing conversion. Could you please share the file?
I will add a pre-checker to verify the `/etc/fstab` file on our end. However, I believe we will not be able to automatically fix these types of problems (nor should we, as it might be unexpected for users).


Automatically fix maybe not easy to do, but better to have suggestion could be helpful.

Here is the fstab contents:

`proc /proc proc defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/md/0 none swap sw 0 0
/dev/md/1 /boot ext3 defaults 0 0
/dev/md/2 / ext4 defaults 0 0
`


This problem is usually handled by centos2alma. Therefore, I suggest you try using centos2alma itself now to perform the conversion


An update, I connected with KVM and it turns out the mounting process was messed up. It was in dracut emergency shell.

`Warning: /dev/md/2 does not exist
Generating "/run/initramfs/rdsosreport.txt
Entering emergency mode. Exit the shell to continue.
Type "journalctI" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report.
dracut:/#`

so when I check, I saw instead of md/2 - > md125 main raid (there is also md126, md127) exist on the system. I don't know centos2alma made these changes/ I temporarily mounted it and saw that everything was in there but I don't know why the md's names are changed. When I temporarily mounted I saw fstab file still md/2 . And tried to change it md125 and reboot it but at the end the issue still persists.

This is really bad situation that I am in right now, and trying to find a solution for this. If you have any idea how we can resolve it that will be awesome.


The issue seems to occur because the new kernel version changes the names of the RAID devices in the system.

We haven't encountered this issue previously, so I suggest manually setting the names of the RAID devices via the command line in the kernel. Alternatively, you could use the UUID of the RAID devices in the /etc/fstab file, which I believe is more reliable (as explained by Jeff Geerling, for example). Here’s how you can do it:
1. Find out the UUID of the RAID device using the command `blkid /dev/md/125`.
2. Replace `/dev/md/125` with the UUID in the `/etc/fstab` file.

It might also be a good idea to revert to a system snapshot taken before the conversion and modify the `/etc/fstab` before starting the conversion process.


I updated the sensors to look like this. 1 sensor per container with attributes.

Screenshot 2024-11-26 at 5 26 02 pm

I updated the code to use dockersocket container as it provides better results so you need to have dockersocket container running on unraid.
Screenshot 2024-11-26 at 5 29 51 pm


Hey @AlfSandoval

Thank you for providing the detailed report. The team will take a look into it.
It seems, that this is caused because of focus handling.


I stumbled into this error too, after adding svelte-preprocess to a newly initialized site.


I should probably mention that, when switching, the 60Hz monitor takes a bit longer to connect than the 144Hz. Maybe that has something to do with this?


the faq needs to be updated with your example as it took a lot of time to understand and configure the solution as it is NOT mentioned in faq - URL


I agree, I have a WIP to update various bits of documentation but haven't pushed a PR yet.