Same issue happens with this verison `Ferdium-linux-Portable-6.7.3-nightly.9-x86_64_cdca802a7cee1d127f07bebdefeb5ef2.AppImage`


Version 6.7.3-nigthly.11 was released today and had a bug that is reported here: URL

Unfortunately I think you made the Ubuntu upgrade and, at the same time, the Ferdium upgrade... Which caused the black screen you are seeing.

It is weird that nightly.9 is not working tho...


What firmware are you running, and do you have obstruction sensors attached? Does the `Toggle` command work to close the door rather than the discrete `Close` command?


Thanks for the reply, seems like it is a known issue with certain GDO's that don't have obstruction sensors attached as they are optional.
Yes toggle command works.
Looks to be a couple of solutions, buy obstructions sensors or potentially wait to see if it can be bypassed. Going to close the issue as I forgot to check the main ratgdo page first and its already reported under URL


Yup, that's about the sum of it.

It seemed that at least one person was able to make it work, but for most, it's either add obstruction sensors, or you could use a workaround like the MQTT code where you toggle the door conditionally on whether it is open when you need to specifically close it. Of course, that requires that the RATGDO or RAT-RATGDO always have accurate statuses, so it is a little sketchy sometimes.


I tried to install the onecta intgration.
Did the onecta integration in HACS via extra repositories,
after restart downloaded the integration in HACS,
after another restart tried to add integration.
Than the daikin site is started, password asked.
When loged in I have to accept something, and set the link to the application.
Then click on 'link account'.
Then only a white screen on the daikin site and in HA on the integration site one option: 'close'

<img width="484" alt="Schermafbeelding 2024-04-16 om 22 22 13" src=" URL

No asking for any token at all.


Hi! Here another user trying to get this integration in my HA.
I saw in the API documentation that by Spring 2024 the given clientId and token will be deprecated, so this should have happen already or it will be happening in a few days...
Anyway I could not get further than the integration asking me the name, clientid and token (which I copied from the API documentation right away). I get redirected to a url which tells me that something went wrong with the authentication (maybe I did not understand the "Using config flow" or maybe the clientid and token are already outdated).
Also I did not see anywhere a form to ask for my clientId and token... I did subscribe for the onecta developer site but nothing is there but the documentation how to user their API.
Thanks anyway for the effort, this integration looks promising!


Thanks for the update. Although I don't have iPhone 13 pro max, I tried the code sample on iPhone 6s with which using camera and gallery, both times, the images was shown as expected using front camera.

<img width="339" alt="Screenshot 2024-04-17 at 11 47 52 AM" src=" URL
<img width="341" alt="Screenshot 2024-04-17 at 11 47 58 AM" src=" URL

I tried on latest stable version.


Try to remove the daikin credentials under Settings/Devices and the three dots in the upper right corner and try to add it again


URL

You can see clearly that I have used the official image_picker example in 13 pro max and used only front camera to reproduce it. I have iPhone 7 plus and 13 pro max, and in both this issue occurs. Kindly capture image from only front camera in this example app.


I did, no better result.

What I found as a probable reason: On the developer.cloud.daikineurope site, there is 1 product and that is the onecta cloud api.
But when I look at 'myapss' on that site, there is no connected app. And it's a;so not possible to add one, the site says:
------------
_You cannot create an application as this developer portal has no available application auth strategies. Please contact a developer portal admin.__
------------

I don't know if that a sort of reason and if yes how to solve it. Can anyone help with this?

Another possibility:
When I click on the onecta icloud api (on the developer site) I come on another page where I can click on authorize, the system asks for a 'Access token retrieved from token endpoint'. Where do I find that?


Check the getting started page at the developer website, there is a client id/secret which everyone has to use at this moment


to make it even more fun:

sh
❯ mise use java@sapmachine-17.0.11
...
OpenJDK Runtime Environment SapMachine (build 17.0.11+9-LTS)
OpenJDK 64-Bit Server VM SapMachine (build 17.0.11+9-LTS, mixed mode, sharing)
mise java@sapmachine-17.0.11 ✓ installed
mise ~/foo/.mise.toml tools: java@sapmachine-17.0.11

❯ mise use java@sapmachine-17
mise ~/foo/.mise.toml tools: java@sapmachine-17.0.11


I humbly suggest to nnormalilze all versions when ingesting data for URL


I used front camera while using your example app with which I didn't get the reported behavior on iphone I tried.
I am wondering since this is occuring using camera which is being used underlying in image_picker package, whether you are hitting this URL


@leoheck can you check if you can upgrade to the latest nightly and if this issue is fixed?


Yeah the version

Version: 6.7.3-nightly.12
Server: Ferdium Server
Electron: 30.0.0
Chrome: 124.0.6367.49
Node.js: 20.11.1
Platform: Linux 6.8
Arch: x64
Build date: Wed Apr 17 2024 09:24:46 GMT-0300 (Brasilia Standard Time)
Git SHA: deba94e5
Git branch: nightly

Works again, actually while downloading it, version `6.7.3-nightly.9` started to work... maybe ubuntu upgraded something.


I think this could be related to the fix introduced in #4231. The valyala/fastjson library has some pretty poor memory usage characteristics:

If there is a spike to the number of pods running on the kubelet, the pods response might be quite large. On a 64-bit platform, the size of fastjson.Value is 80 bytes. Even if we assume a 500KiB response, that is 40MiB. This is a per-attestation cost (we don't share the kubelet output, yet).

Further, fastjson has an outstanding bug that causes memory to be held onto a little longer, meaning that if you are undergoing many attestations at once, the GC might not be able to release memory fast enough. There is a PR open but fastjson may not be actively maintained ( URL Hard to know if/when this PR would land.

We've considered moving to another, more frequently maintained library...


It looks like the workaround was only enabled for the 23.10 version of Ubuntu:

 URL

This line likely needs to be changed to include 23.10 and **all later versions**.


unfortunately Joplin is only shipped as an appimage for Linux. Which means we can not ship a profile for it by default that will allow it to use capabilities within the unprivileged user namespace that the electron embedded browser is attempting to use.

This means that the user is required to intervene to enable an electron based appimage so that it can be run. Unfortunately for 24.04 this means some manual command line based intervention, instead of using a GUI like on MacOS when a user needs to enable an application downloaded from the internet.

If you look in the kernel logs, (or dmesg) you will find an message an apparmor message similar to below showing what is causing your issue.

$ sudo dmesg | grep "apparmor=\"AUDIT"

[ 85.468352] audit: type=1400 audit(1713509122.843:224): apparmor="AUDIT" operation="userns_create" class="namespace" info="Userns create - transitioning profile" profile="unconfined" pid=3058 comm="@joplinapp-desk" requested="userns_create" target="unprivileged_userns"

and

$ sudo dmesg | grep DENIED

[ 85.469966] audit: type=1400 audit(1713509122.847:225): apparmor="DENIED" operation="capable" class="cap" profile="unprivileged_userns" pid=3065 comm="@joplinapp-desk" capability=21 capname="sys_admin"

Unfortunately unprivileged user namespaces are using privileged kernel interfaces (above protected by capabiity sys_admin) that have now been restricted to known applications because they have been used in a lot of exploit chains.

you can add a profile for the application by copying the profile from below into /etc/apparmor.d/ and then updating by replacing
/home/jj/Downloads/Joplin-2.14.20.AppImage
 with the location you are running your joplin appimage from.

# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

abi ,
include

profile joplin /home/jj/Downloads/Joplin-2.14.20.AppImage flags=(unconfined) {
 userns,

 # Site-specific additions and overrides. See local/README for details.
 include if exists
}

Once that is done you can do

$ sudo apparmor_parser -r /etc/apparmor.d/joplin

that will allow you to run joplin without having to reboot. Having the jplin profile in /etc/apparmor.d/ will ensure it is reloaded if you reboot.


@darshankawar this issue persists across every iOS device I've. I've tested on the following devices: iPhone 7 Plus, iPhone 12 Mini, iPhone 13, and iPhone 13 Pro Max

To get the reported behavior in iPhone 6s, as you said it works fine on 6s, I've arranged it and checked using the example app from image_picker, where this issue also occurs. In the below video, you can see the behavior clearly, and in the end of the video, you can see the device info too.

 URL


Thank you for the suggestion!

I have a few concerns about this:
- It means that the installer will require root access.
- Overwriting `/path/to/Joplin-2.14.20.AppImage` could give an attacker access to unprivileged user namespaces.
 - This would mean, however, that an attacker would already need to be able to write files and run code as a user with Joplin installed.
- Uninstalling Joplin becomes a bit more complicated, particularly if multiple users on a computer have Joplin installed. In this case, the AppArmor profile also needs to be removed, but only if all users have uninstalled Joplin.
 - One solution could be to use a flag `--full-uninstall`.
 - Another solution could be to install the AppImage to a globally-accessible location (e.g. in `/usr`).

See also
 URL


actually --no-sandbox should work as well. Ubuntu isn't going so far as requiring a profile for all downloaded applications. Only those that use unprivileged user namespaces and try to use system capabilities within the user namespace. Since --no-sandbox will stop chrome from creating the unprivileged user namespace, that should be enough to get it to work without creating a profile.


@SpecialAro the new `nightly.13` is not working anymore.

image


Can could you reopen this issue? I cannot see the button for that.


I can reopen, but I don't think it is related to the same issue. I see that you can not open the app at all


That's true when launching from the command line. When using the launcher it shows the icon on tray.


However the issue here is that it is not launching. So I think it is still related to the report.


`no-sandbox` should work, it's been tested before. It'd be ideal if Chromium/Electron had a less binary flag for it, but unfortunately that's not the case we're in. It might change in the future though, Ubuntu isn't the only one who've started restricting access to it and even Linus Torvalds himself has called it a mistake that they're stuck with.

I'd not honestly expect a resolution for this in the "it just runs" manner. I know Ubuntu has been working on permissions prompting for snaps like how Android/iOs have it ("Joplin is trying to access ./SSH, would you like to allow" kind of prompts), and as I casually read through Launchpad, it seems there's an apetite for making user namespaces work the same way even outside of snaps, but it'd be unlikely to get backported into 24.04 which will persist for years.

From what I've read, the Electron Flatpaks have a trick they use called Zypak that allows the Chromium sandbox to work without SETUID bits and potentially usernamespaces, it could be possibly replicated in the AppImage and provide better sandboxing than nothing.

But as far as Ubuntu the project goes, they'd likely say the answer needs to be a PPA (more maintenace effort), a snap (Which already exists), or for it to be submitted to the Universe repository (which is less than ideal because the package would become stale and eventually become incompatible for syncing with the latest clients).

Even in the snap, `--no-sandbox` is still used, snapd itself sets up apparmor permissions and seccomp and BPF and all that stuff so that Chromium doesn't have to, only big vendors like Mozilla or Brave or etc would be allowed to use unprivileged user namespaces, even in a snap!


Crossreferencing URL and URL here which seem to be suffering from the same issue.


So make it just runs is problematic. The goal is to stop unknown code from being able to use unprivileged user namespaces to attack the kernel. There are a few ways we can get safely get the "make it just run" behavior, like shipping profiles for known applications in locations that regular userspace code can't write. Or signed code with a valid integrity hash. Both of these exist. Unfortunately we can't do that for code that a user can just down load and run from their home dir in locations that attack code code write to gain privilege. If we enabled that, attack code would just have to add a simple step to the exploit chain.

Its not that we don't want users to be able to run these applications. Its just an unfortunate reality of how unprivileged user name space exploits work.

So we need some privileged way that a user can enable new applications. Currently that is adding a profile or signed code that can be verified by the integrity architecture. With snapd there is the opportunity for a third way via prompting the user. Unfortunately atm it is experimental and not integrated with the unprivileged user namespace yet.

Like I said unfortunately the user experience in 24.04 isn't good when failure happens. The goal is to improve the experience, and that includes 24.04. On the snap side, snapd and snaps get updated separate from the base so you will see improvements there coming back to 24.04. Some of them might depend on an HWE kernel, but if needed some changes might get backported, to older kernels (this has been done for other features).

The apparmor side we are looking to looking at the possibility of bringing new versions back to older releases to better support the HWE kernels.

Zypak is interesting, and it should be possible to get it working, at least with the caveat that the launched application won't have access/need access to privileged kernel interfaces. I haven't looked into it yet, but its on the list of things to look at.

So from a support hat side of things that does make things easier, but we do want to make the user experience for electron and appimages. The current situation really isn't acceptable for the average user.

Its entirely possible to create a full apparmor profile for the application, that allows it to also use unprivileged user namespaces. The unconfined profile stub is just trying to make it easier for the user, and yes t is not easy enough atm. As for snapd there is a new interface that allows access to unprivileged user nameapces, and any snap can request it. The goal is not to stop applications from using them, but to stop exp


@Kleidukos what kind of a format resolution besides personal statements from CLC members are you looking for if any?


@Bodigrim A note in Impact Assessments would be the end goal, so that the opinion of the CLC doesn't get lost in this ticket when it is closed.


Given that the function is deprecated for a decade, I don’t see a reason not to delete it. We are way far away from Haskell Report to bother about it.


@Kleidukos would you like to suggest a specific wording? How about the following?

"Note that additional or new warnings and deprecations are not classified as breaking changes. We assume that users who enable `-Werror` make a conscious and informed choice to break their builds as early and as fatal as possible."

Such wording still allows CLC members to have individual opinions whether a given warning / deprecation is worth the trouble. It's not like anyone can incur as many warnings as they like, but they do not count towards breakage and do not require a proposer to write patches to fix them.


@tomjaguarpaw @mixphix @hasufell @angerman @parsonsmatt @velveteer any more opinions about `Foreign.Marshal.Error.void`?


I would like a base that conforms to the spec or an update to the spec.

Do we know why the deprecation was introduced?

I don't see base in the 7.6 tree URL


I don't have a strong opinion between the three options (no change, replace with general version, remove it).


It was deprecated by @simonmar in URL Apr 2012, but there is no explanation or discussion attached.


Given the deprecation message I guess the reason was that the more general version of `void` should be preferred!

{-# DEPRECATED void "use Control.Monad.void instead" #-}


Hi @Santa0727
We checked compatibility with expo 50 and found no problems. In issue #1176 ( URL is an example using expo 50.


I tried on iPhone 13 pro max simulator running iOS 15.3 version but wasn't able to replicate.

 URL

Also, as previously stated, tried on iphone 6s device on which as well, I wasn't able to replicate the reported behavior.

Based on the report, it seems to be device + OS specific, so labeling it for team's input / tracking.


We found that even if Spire v1.8.7 is much better than the older releases spire-agent got OOMKilled after a while. So, the spike is still there. Thus, I made a patched version with the parser from valyala/fastjson#101 and tested it. It seems to be working without issues. So, unfortunately it is not enough to upgrade to Spire v1.8.7 or later release.


That's what I suspected. Unfortunately, fastjson seems to no longer be actively maintained. It's probably to the benefit of the project to move to a different json parsing library that is actively maintained.


I had forgotten about this one! :)

It is a _little_ weird that someone might write...

java
interface Foo { @Nullable String passThrough(@Nullable String s); }
interface Bar { String passThrough(String s); }
interface Qux extends Foo, Bar {}

...and end up as if `Qux` had a signature like `String passThrough(@Nullable String s)`, which is presumably unsound.

In #67, I'd cited URL which appears to match kevinb9n's results. It's similar to our rule in that it picks the most specific return type.

But we go further by trying to perform a full on glb/lub of multiple types. For example, the JLS wouldn't "merge" `Iterable ` and `List ` into `List `, but we're effectively trying to do that. But we can make that happen because we know that the base types match—well, _mostly_.

Arguably a more JLS-like approach would be pick one of the _n_ signatures. Maybe it would make sense to pick the one with the more specific return type (since that's the part that the JLS allows to vary). Granted, even "more specific return type" isn't a well-defined concept: If we inherit both `@Nullable List ` and `List `, then neither is strictly more specific than the other. So we're back to glb/lub and possibly even unspecified nullness.

(Maybe ideally a checker that analyzes _that class_ would produce an error to get the programmer to resolve the conflict. But programmers can avoid any such error by suppressing or at least by not running a checker in the first place. So there's no getting around defining behavior for a checker that analyzes _usages_ of such a method.)


(I'm here because @kevinb9n just pointed out to me in chat that there's a related but separable issue: If `Qux` _declares_ some `passThrough(String)` method, then checkers should probably check it against _both_ of the supertypes' methods _separately_. The question of _this_ issue is what happens when there is no such declaration in `Qux`.)


Hmm, URL has me thinking more about unspecified nullness.

I've read the description there, and I'm not sure if it adds behavior beyond what glb/lub already does. I may be misunderstanding, though.

One possible goal could be to prefer to _ignore_ unspecified when we have "better" information:

java
@NullMarked
interface Foo {
 void use(String s);
}

@NullUnmarked
interface Bar {
 void use(String s);
}

interface Qux extends Foo, Bar {}

There, the unspec rule from above and the glb/lub rule give us `void use(String*)`, I think? But we could instead say that the type is `void use(String!)`, since we have an affirmatively non-nullable type from `Foo`. Of course, someone could in the future annotate `Bar` with `@Nullable String`, in which case the type would become `String*` again because of the conflict. But maybe that's overall a better user experience, since the type probably is meant to be `String!`.

This spec-unspec mix may well be the most common kind of "conflict" that we'd see in practice, so we might want to err on the side of doing the "right" thing for it.


@tjgq are there any updates on this? It is still not listed as 7.2.0 deliverable according to URL


@ItsArsalanAziz, please take a moment to read out see our code of conduct, which requires kind and actively welcoming behavior. Your last comment was neither.


interesting, I have the same problem with duckdb under linux

what worked in the end:

1. write tmp credential to env: `$(AWS_PROFILE=dev-sso aws configure export-credentials --format env)`
2. start duckdb
3. load credential: `CALL load_aws_credentials();`
4. set the region: `SET s3_region = 'eu-central-1';`
5. select data: `SELECT * FROM 's3://bucket/path/file.parquet';`

Using the CONFIG storage above, it returns "success" but does not store any secret:

D CREATE SECRET (
 TYPE S3,
 PROVIDER CREDENTIAL_CHAIN,
 REGION 'eu-central-1',
 PROFILE 'dev-sso',
 ENDPOINT 's3.eu-central-1.amazonaws.com'
 );
100% ▕████████████████████████████████████████████████████████████▏
┌─────────┐
│ Success │
│ boolean │
├─────────┤
│ true │
└─────────┘

D SELECT secret_string FROM duckdb_secrets();
┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ secret_string │
│ varchar │
├────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ name=__default_s3;type=s3;provider=credential_chain;serializable=true;scope=s3://,s3n://,s3a://;endpoint=s3.eu-central-1.amazonaws.com;region=eu-central-1 │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘


@jmagman apologies for the kind of behavior but look into the matter as I clearly mentioned the issue that is not device-specific but platform-specific. I have checked in more than 6 different IOS physical devices and it generates in every device. @darshankawar marked it as a device-specific issue which is hard to understand.


@ItsArsalanAziz
You are correct. It doesn't seem to be device specific so I will remove that label. I was finally able to replicate this on iPhone 6s device with front camera as shown below:

 URL

I compared it with native iOS camera with which same behavior occurs using front camera:

 URL

In both videos, you can observe that when we open front camera, the cupboard is to the right, when we take picture, in preview you'll see it on left which is same behavior in native iOS and Flutter.

This indicates it is how native iOS front camera works that you can check on the range of devices you mentioned and compare with Flutter's image_picker or camera.


I also solved this problem by re-logging in, thank you very much!


@darshankawar thank you, will there be any fix for this in Flutter's image_picker in upcoming release?


Daikin reported that they have implemented a fix, see URL When you have this problem within 12 hours from now please re-initiate the authentication. When you have this problem again after 24 hours from now please let us and Daikin know!

Hopefully we can close this issue after the weekend!


The current behavior is in sync with native iOS, so I am not sure if the fix is in scope for the plugin to be made.
Since image_picker under the hood uses camera, I suggest you to follow-up in URL which is similar as your request.
Closing for now. If you disagree, write in comments and I'll reopen it.


This isn't actually a duplicate of #27650, since `camera` and `image_picker` have fundamentally different code. `camera` is a wrapper around the low-level OS camera APIs, and does not involve any system UI. There's a lot more opportunity to customize behaviors at that level.

`image_picker` is a wrapper around a very high-level system-provide UI control. The only things the plugin can change about the resulting UI are those that the OS specifically provides (which is basically this). I don't see any way to control the behavior of the camera UI in that configuration, which means that the functionality requested here cannot be implemented in this plugin.

Given that, removing the duplicate label, but leaving the issue closed. Clients who need to customize the capture experience would need to build their own UI around `camera` or a similar plugin, rather than using `image_picker`.


`image_picker` does not depend on the `camera` package; the camera UI that is available through `image_picker` is provided entirely by the OS.


@parsonsmatt @angerman @velveteer any more opinion on the preferred course of actions here?


OK, let's vote on this.

Dear CLC members, the proposal is to extend Impact Assessments section of `PROPOSALS.md` with a paragraph

@angerman @hasufell @tomjaguarpaw @parsonsmatt @velveteer @mixphix

----

+1 from me, see my comment above.


What @stuartmorgan said.

When taking a picture with the front camera, iOS automatically mirrors it. This is built into Apple's `UIImagePickerController` API. The preview of the image (the view where it says "Retake" and "Use Photo" is also part of `UIImagePickerController`). You may also notice that when you use the native iOS camera app, this behavior also occurs. In conclusion, this is not an issue with `image_picker` or Flutter but the expected behavior.


Another point to consider: A fair number of packages have `import Foreign hiding ( void )` which will trigger a `-Wdodgy-imports` warning if `void` is completely removed from `Foreign.Marshal.Error`. That's not a big deal: there are several acceptable ways of dealing with this warning, including silencing it. But it does probably create busy-work for the relevant maintainers, which could be avoided by replacing `Foreign.Marshal.Error.void` with a re-export of `Data.Functor.void`.

But I won't sleep any less soundly if the committee still prefers to delete the function instead.


@clyring we don't consider warnings breaking changes: URL

Werror users get what they asked for.


@jmagman this might be the default behavior you are right, but it works fine in other platforms. As in my case, this behavior is a glitch which is the reason why I opened this issue.


I've bought some cheap obstruction sensors but struggling to get them wired correctly. 2 wires from each, white/black and white. What terminals would you connect these to? Assuming the black wire stays in terminal 3?


Interestingly this does not happen if `sapmachine-17` is already installed.

bash
 ❯ mise i java@sapmachine-17

 ❯ mise use java@sapmachine-17.0.11
...
OpenJDK Runtime Environment SapMachine (build 17.0.11+9-LTS)
OpenJDK 64-Bit Server VM SapMachine (build 17.0.11+9-LTS, mixed mode, sharing)
mise java@sapmachine-17.0.11 ✓ installed
mise ~/foo/.mise.toml tools: java@sapmachine-17.0.11

 ❯ mise use java@sapmachine-17
mise ~/foo/.mise.toml tools: java@sapmachine-17


@dkashyn-sfdc I added it to the milestone just now - there is some progress and we expect to land a first usable version by the 7.2 release the latest.


@leoheck Do you know if the problem is also happening when installing Ferdium through the `.deb` file? I am also on Ubuntu 23.10 at the moment, and might update soon to 24.04, and we will need to see if we can provide a patch for that before those jumping from the previous LTS get this problem.


The final release 6.0.0 is out and strip light dimming can be disabled with it.
 URL

This issue will be closed as solved now.

Michele Moramarco
Prusa Research


What terminals do you have? What model GDO? What does it look like?

This might work for your GDO URL

1. Strip 7/16-inch of insulation from each of the two wires on each sensor—each sensor has two wires, a solid white one and one white with a black stripe, for a total of four wires.
2. Twist together the two white-with-black-stripe wires from both sensors.
3. Twist together the two white solid wires from both sensors.
4. Connect the two white-with-black-stripe wires in the gray terminal on the motor unit.
5. Connect the two white solid wires in the white terminal next to the gray on the motor unit.


Thanks all, that's enough votes to approve. I'll implement the change in a moment.


I think we all agree that `Foreign.Marshal.Error` is not a right place for `void :: Functor f => f a -> f ()`, it's just that CLC members may have different appetite when it comes to breakage.

As noted in the proposal, replacing `void :: IO a -> IO ()` with `void :: Functor f => f a -> f ()` is also a breaking change, because it can potentially make type checking ambiguous. So it would require an impact assessment, same as just removing it. So I guess it's a question which impact assessment (and patches) @clyring is motivated enough to perform.

If we go for re-export, let's *deprecate* it, so that we do not close the door to the eventual removal of the function.


Hey @Alphrag , I am on Ubuntu 24.04 (not a clean install) it was upgraded when it was still to be released. It was released yesterday. However, it has been updating a bunch of things daily since when I upgraded it. It may have eventually improved/fixed something.

Now, talking about the Ferdium, it is currently working. There are no problems anymore.
But I am not sure about the .deb version of it.

I am running this version

Version: 6.7.3-nightly.15
Server: Ferdium Server
Electron: 30.0.1
Chrome: 124.0.6367.60
Node.js: 20.11.1
Platform: Linux 6.8
Arch: x64
Build date: Sat Apr 20 2024 21:50:37 GMT-0300 (Brasilia Standard Time)
Git SHA: fe61e6ba
Git branch: nightly


Same as him and also I'm seeing that the plugin is still stuck on version 1.0.0.0 in extensions tabs but won't download the 1.0.1.0 and also by forcing it and doing it manually it's still marked as 1.0.0.0


We can also add an admin filter to check for future "to" dates (and/or early "from" dates).


How about this:

Instead of making the version resolution logic more complicated, normalize the input data.

If java versions where consistent (major.minor.patch) across all vemdors in rtx-java-metadata, all of this would go away and you could even drop the secret sauce to make `java@21` work as expected.

Happy to help if that's the route you want to take.


@mpern Agree that this might be a better solution but i assume this will be quite some effort. I'm not familiar with the java-metadata repo in detail but historic metadata would need to be updated manually as it is not updated automatically (only new versions are added AFAIK).

@jdx What is your take on this?


As of 2024/04/30:

$ githubgen
2024/04/30 10:50:08 codeowners are not members: Caleb-Hurshman, MaxKsyunz, MitchellGale, YANG-DB, adcharre, am-kinetica, asaharn, cheempz, driverpt, emreyalvac, jcreixell, jerrytfleung, rlankfo, shaochengwang, swar8080, thmshmm, yiyang5055, zpzhuSplunk


Okey, i'm clearly in favour of having a consistent solution by normalizing the versions in rtx-java-metadata.


I've opened #5109 and #5111 to track potential mitigations. I believe #5109 should be done no matter what, considering valyala/json is not actively maintained. If that isn't enough, we could consider #5111, though it is more complicated.


This bugs me 😅

@dominik-czupryna-withintent Do you think it can somehow added anyways?

I was able to successfully make a build 10 days ago with `"expo": "~50.0.4",`

When I want to build my app (`"expo": "~50.0.17",`) with `eas`, I encounter this error URL

Error: [ios.dangerous]: withIosDangerousBaseMod: Unrecognised filter type - 127

CleanShot 2024-05-01 at 09 52 26@2x

`npx expo prebuild` runs fine on my local machine.

Here are my investigations with `yarn why @expo/config-plugins`

yarn why @expo/config-plugins
yarn why v1.22.21
[1/4] 🤔 Why do we have the module "@expo/config-plugins"...?
[2/4] 🚚 Initialising dependency graph...
[3/4] 🔍 Finding dependency...
[4/4] 🚡 Calculating file sizes...
=> Found "@expo/config-plugins@7.9.1"
info Has been hoisted to "@expo/config-plugins"
info Reasons this module exists
 - Hoisted from "expo#@expo#config-plugins"
 - Hoisted from "react-native-ble-plx#@expo#config-plugins" Found "expo-updates#@expo/config-plugins@7.8.4"
info This module exists because "expo-updates" depends on it.
info Disk size without dependencies: "1.73MB"
info Disk size with unique dependencies: "3.82MB"
info Disk size with transitive dependencies: "8.32MB"
info Number of shared dependencies: 60
✨ Done in 0.24s.

On my `app.config.ts` I added this

typescript
plugins: [
 "expo-router",
 [
 "react-native-ble-plx",
 {
 isBackgroundEnabled: true,
 modes: ["peripheral", "central"],
 bluetoothAlwaysPermission:
 "Allow $(PRODUCT_NAME) to detect your bluetooth device"
 }
 ],

@Santa0727
Can you please let us know if `eas build --platform=ios` is working on your side?


Hi @flexbox,
Thank you for your response.
The build command works on my side, and it builds ipa file.

I've used expo managed workflow on my local. Is it impossible to use without ejecting expo?


This is a bit complicated issue.
EC:1.6.1.1 NAD(P)(+) transhydrogenase (Si-specific) has other name NAD(P)(+) transhydrogenase (B-specific) RHEA:11692
EC:1.6.1.2 NAD(P)+ transhydrogenase (Re/Si-specific) is transferred to
EC 7.1.1.1 proton-translocating NAD(P)(+) transhydrogenase RHEA:47992
EC:1.6.1.3 NAD(P)(+) transhydrogenase RHEA:11692

GO:0008746 NAD(P)+ transhydrogenase activity XREF to EC:1.6.1.1/EC:1.6.1.2/RHEA:11692

... GO:0008750 NAD(P)+ transhydrogenase (AB-specific) activity XREF to EC:1.6.1.2. Also XREF MetaCyc:PYRNUTRANSHYDROGEN-RXN suggests it is about EC:1.6.1.1 and EC:1.6.1.3
... GO:0003957 NAD(P)+ transhydrogenase (B-specific) activity XREF to EC:1.6.1.1 (NOT RHEA:11692)


oh, interesting. This is the solr query:

 URL

Notice that `+ ` is translated ` ` (double space). This is because the `+` is a URL encoding of a space. The solution is to use the right URL escaping when constructing the SOLR urls. We should also check other characters that typically get encoded, e.g. `:`.


Experiencing the same issue with the Close button on HA with my Merlin MS65MYQ. No obstruction sensors, and black RATGDO wire is disconnected from the door opener.


**For GO:0008746 NAD(P)+ transhydrogenase activity** XREF to EC:1.6.1.1/EC:1.6.1.2/RHEA:11692
- [ ] Obsolete ; this is the general case that corresponds to URL which states "This entry stands for enzymes whose stereo-specificity with respect to NADPH is not known"; this is associated with the same RHEA as 1.6.1.1 and has no genes associated with it. It seems like the stereospecificity is always known.

**Child GO:0008750 NAD(P)+ transhydrogenase (AB-specific) activity** :
- [ ] Change general cross references to EC 7.1.1.1 proton-translocating NAD(P)(+) transhydrogenase and RHEA:47992
- [ ] Change definition to match RHEA
- [ ] Change definition cross reference to RHEA:47992
- [ ] remove the link to "pubs.acs...." in the def xref that (dead link)

**Child GO:0003957 NAD(P)+ transhydrogenase (B-specific) activity** XREF to EC:1.6.1.1
- [ ] Xrefs should be to EC:1.6.1.1 and RHEA:11692
- [ ] Definition should be adjusted to match RHEA's.

Does that seem right ?

Thanks, Pascale


How is this supposed to work on Windows?

Will rustup extend `PATHEXT` upon installation and associate `.rs` files with `cargo`?

In this case all Rust source files would become executable, which is confusing, especially when using Windows Explorer.

I think it might be better to use a separate extension, for example `.rsc` for Rust SCript, to ensure that the experience on Windows will not lack behind.


How does python handle this on Windows? They don't use a separate extension for executable and non-executable files either.


True, but it doesn't mean we have to follow them if we can do better.


All `*.py` files are executable, scripts *and modules* alike. So I would be hesitant to suggest taking inspiration from Py, but I'm unsure if there's a better alternative than simply using a different file-ext.

MS should definitely add shebang (and magic-numbers) support to Windows! It's overdue since many years ago


I wonder if it could be related to this error regarding `generated-autoload-file` being redefined as dynamic?

% emacs --batch --eval '(let ((generated-autoload-file "autoloads.el")) (update-directory-autoloads "builds/vertico
"))'

Error: error ("Defining as dynamic an already lexical var" generated-autoload-file)
 (defvar generated-autoload-file nil "File into which to write autoload definitions.\nA Lisp file can set this in its local variables section to make\nits autoloads go somewhere else.\n\nIf this is a relative file name, the directory is determined as\nfollows:\n - If a Lisp file defined `generated-autoload-file' as a\n file-local variable, use its containing directory.\n - Otherwise use the \"lisp\" subdirectory of `source-directory'.\n\nThe autoload file is assumed to contain a trailer starting with a\nFormFeed character.")
 require(loaddefs-gen)
 byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\207" [require lisp-mode lisp-mnt cl-lib loaddefs-gen] 2)
 (update-directory-autoloads "builds/vertico")
 (let ((generated-autoload-file "autoloads.el")) (update-directory-autoloads "builds/vertico"))
 eval((let ((generated-autoload-file "autoloads.el")) (update-directory-autoloads "builds/vertico")) t)
 command-line-1(("--eval" "(let ((generated-autoload-file \"autoloads.el\")) (update-directory-autoloads \"builds/vertico\"))"))
 command-line()
 normal-top-level()
Defining as dynamic an already lexical var: generated-autoload-file

whereas this version without the `let` binding works for me:

% emacs --batch --eval '(progn (setq generated-autoload-file "autoloads.el") (update-directory-autoloads "builds/ve
rtico"))'
Package autoload is deprecated
 INFO Scraping files for autoloads.el...
 INFO Scraping files for autoloads.el...done

It looks to me like elpaca's `elpaca-generate-autoloads` uses the let-binding method, so maybe that's causing it but the error is suppressed, or it could be something else. Note that I am using a bleeding-edge emacs built from source.


Thanks for taking the time to fill out a support ticket.

Yes. That does look like a circular dependency.
I've squashed that bug several times, so perhaps there's a case I missed.

Maybe they're related.
You can prevent the "too many open file" error by setting the `elpaca-queue-limit` option prior to processing any queues. e.g.

 emacs-lisp
(setq elpaca-queue-limit 30)

If you search the issue tracker there are other Windows users who have hit this limit.
I don't recall exactly where they ended up with that value, but I think it was closer to 12-20. Allegedly there are ways to allow more open file handles at the OS level, but I don't use Windows enough to give any advice on how to do it.

I would try:

1. saving `(setq elpaca-queue-limit 12)` in you init file just after the elpaca installer.
2. `M-x restart-emacs`

Then, in a fresh Emacs session, try another `elpaca-update-all` and see if the issue persists.


They won't do that because it does not make sense on Windows, since the interpreter can be in an installation-dependent place and is not necessarily found in `PATH`. The Windows mechanism is not inherently bad, just different from UNIX.


I was going to try and update, but can't build this project. I can't seem to find any developer docs. Are they somewhere other than this repo?


Looks like this the top level block

 Types of property 'action' are incompatible.
 Type 'boolean | ActionFunction ' is not assignable to type '(...args: any[]) => any'.
 Type 'boolean' is not assignable to type '(...args: any[]) => any'.


I rolled back to react-router-dom 6.6.2 and still the types don't match. Looking thru the code in this repo there no test or example that uses `withFaroRouterInstrumentation`. Is it possible that this never worked? The type `ActionFunction` has been in the react-router-dom from before this PR was created.


I'm not 100% certain but doing this in my shell after the first elpaca pass with all the autoload failures seems to help:

garyo@tower1 (~/.config/emacs/elpaca/builds [main]) 4:38PM 4200=>
% for d in *(/); do emacs --batch --eval "(loaddefs-generate \"$d\" \"$d/$d-autoloads.el\")"; done
 INFO Scraping files for loaddefs...
 INFO Scraping files for loaddefs...done
 INFO Scraping files for loaddefs...
 INFO Scraping files for loaddefs...done
...

then I restart emacs and things seem to go better.


Supported is a strong term, after deeper investigation as a part of #96, it seems fragments cannot be supported as delimiters.


As mentioned in #96

After attempting to solve this, I was confused as to why the correct path could not be found.

The `http.Request.URL.Fragment` was always missing when making a curl request or via postman etc. I was unable to perform any kind of lookup when a fragment was used, because any request made to wiretap using a fragment was just missing the fragment each time.

So then I looked a little deeper. I found this:

 URL

Fragments are never sent in HTTP. They're purely a local browser concept.

There is no way for me determine which path is being requested when the OpenAPI specification uses a fragment as a delimiter. The fragment is never picked up by the standard library.

Which pulls into question the legitimacy of using fragments at all in OpenAPI specs. They are quite useless it seems and should not be used as delimiters for paths.

Marking this as a wontfix, because there is nothing I can do to make it work.


(based on UniProt catalytic activity)
GO:0008746 NAD(P)+ transhydrogenase activity, there are 6 experimental annotations. I reported an AmiGO bug URL Of those 6, there is a mixture of Rhea:47992, Rhea:11692, and Rhea:10824 (incorrect GO annotation?).
GO:0003957 NAD(P)+ transhydrogenase (B-specific) activity The only annotation PntAA is actually of Rhea:47992.

Since GO doesn't have EC:1.6.1.3, this issue may not be relevant. This comment "This entry stands for enzymes whose stereo-specificity with respect to NADPH is not known", I interpret it to mean that EC:1.6.1.3 is different from EC:1.6.1.1 rather than EC:1.6.1.1 is a subclass.


@zilinfg I appreciate you work on this. This grouping step is one of the new features and I'm under pressure to get it out so we can have the UI reviewed, so I picked it up.


well, magic number support can look for a file starting with `#!/usr/bin/env cargo` and send that to wherever cargo is installed, no shebang support needed


Sorry about that.
The entry is logged just after the process is kicked off.
In this case, the error beats the log to the punch.
That should be fixed on the master branch now.

Do you get the same error with a very simple configuration using `elpaca-test`?

How to run this test?

emacs-lisp
(elpaca-test
 :init (elpaca (vertico :wait t))
 (elpaca-test-log "#unique"))

Yes, it should be defvar'd in elpaca.el.

That may or may not work. When a package's build-dir is already on disk, Elpaca takes an optimistic path to reduce startup time. In that case only `elpaca--pre-built-steps` are run.
So it may just be skipping the issue. You could try a different operation like ` lpaca-rebuild`, which should attempt to regenerate the autoloads, after a restart to see if you hit the same error.


@daveshanley a strategy we are seeing people using to deal with this is it effectively becomes a join of the two operations, on their servers the two routes or directed to the same handler but they are determining the operation based on the inputs, so it is effectively a `oneOf` between the request bodies/response bodies etc.

Totally understand if you want to keep this as wontfix, we can find some other way to deal with this but it is theoretically possible


As mentioned in this comment it could be technically possible to handle ie treat it as deserializing a oneOf of the two request bodies as an example URL


Hey @barrykaplan we tested it with our Faro demo app and everything worked well.
There's a playground branch available.

I'll reopen this issue.


@barrykaplan I can not reproduce the type issue.

What router are you using?

I tested all data routers again but it's working as expected.

createHashRouter,
createMemoryRouter,
createBrowserRouter
createMemoryRouter

Faro's `withFaroRouterInstrumentation` only subcribes to router events and returns the provided router.

example:

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

Router version: `"react-router-dom": "6.6.2",`


In this case, the error beats the log to the punch.
That should be fixed on the master branch now.

Hmm, no difference in the logs with elpaca 06ee3a6. Just "End of file during parsing" after "Generating autoloads".

Wow, I love your test harness!!! Here's the results:

 Test Case

How to run this test?

emacs-lisp
(elpaca-test
 :init (elpaca (vertico :wait t))
 (elpaca-test-log "#unique"))

 Host Env

 elpaca 06ee3a6 grafted, HEAD -> master, origin/master, origin/HEAD
 installer 0.7
 emacs GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-04-08
 git git version 2.44.0.windows.1

 Output

emacs-lisp

Error: end-of-file nil

 command-line-1(("--eval" "(setq debug-on-error t after-init-time nil)" "--eval" "(setq user-emacs-directory \"d:/tmp/elpaca.K94MA9) --eval (run-hooks" "'before-init-hook) -l ./init.el --eval (setq" "after-init-time" "(current-time)) --eval (run-hooks" "'after-init-hook) --eval (run-hooks" "'emacs-startup-hook) --eval (message" "\n" "Test" "Env\n) --eval (elpaca-version" "'message)"))

 command-line()

 normal-top-level()

End of file during parsing

From that output, I can see there's a missing escaped close-quote after the tmpdir. But I don't think it's getting to the point of trying to install vertico (or any of the other packages that fail -- about 50 fail for me, so it's not about the package itself). Also note this only happens on Windows. Maybe it's a path thing due to something like the "d:/" drive name?

The command seems to be OK (properly quoted) in `elpaca-test--make-process` :

("d:/emacs/emacs/bin/emacs" "--debug-init" "--batch" "-Q" #1="--eval" "(setq debug-on-error t after-init-time nil)" #1# "(setq user-emacs-directory \"d:/tmp/elpaca.iShFzl\")" "--eval" "(run-hooks 'before-init-hook)" "-l" "./init.el" "--eval" "(setq after-init-time (current-time))" "--eval" "(run-hooks 'after-init-hook)" "--eval" "(run-hooks 'emacs-startup-hook)" "--eval" "(message \"\n Test Env\n\")" "--eval" "(elpaca-version 'message)")

so I don't yet see where the trailing quote in the tmpdir is getting stripped off. (If that is indeed the problem.)


I think this strategy is a little bit odd to be honest, it means parsing the body to determine the schema, in order to figure out which fragment to use - which to me feels like a considerable hack. It feels like it's going against the spirit of the standard, in order to make it work.


I would be willing to make the fragment work as a delimiter, if it wasn't just a browser concept (I never really gave it much thought to be honest). However because it is just a browser concept and isn't actually part of HTTP or even OpenAPI in any meaningful way, I think I am going to keep this as a wontfix for now,

Happy to accept a contribution however.


So technically yes it does look like the OpenAPI initiative has decided to not make this official URL but in the wild it is getting used to differentiate APIs that share a path but can accept different request bodies, we have come across a few cases of this and various tooling does seem to support it (including ours)


Ah, it was actually being over-written in the log due to me not accounting for DOS/Linux line ending differences in `elpaca--process-filter`. Should be fixed (for real this time) on master. I'm seeing the commands in the log in my Win10 VM now.

Thank you. It's been very handy for working out bugs.

Interesting! Indeed, I get the same error in my VM. I'm not sure what's causing that, but at least we've gotten to what seems like the root of the issue.

Here's my hypothesis:
Windows file-path separator is being interpreted as an escape character "\" in the printed command.
It escapes the closing quote for that string.
That seems to make sense with what we're observing.


Here's a test independent of Elpaca:

emacs-lisp
(make-process
 :name "*test*"
 :filter (lambda (process output) (message "%S" output))
 :sentinel (lambda (process event) (message "%S" event))
 :command (list (elpaca--emacs-path)
 "--batch" "--eval" (format "(print %S)" user-emacs-directory)))

On my Linux machine I get:

#
"
\"~/.emacs.d/\"
"
"finished
"

On Windows I get the error we're seeing.
So it's either a bug with how Emacs handles command line args,
or perhaps there's a better way to format the command string.
I'll try reporting upstream tomorrow and see if anyone has any insight.


Noting this here:

 URL

I noticed you've changed default-process-coding-system in your config.
However, I still get the same error with `emacs -q` on Windows.
Still unsure whether this is Elpaca's or Emacs's bug.


@flexbox
I mean you shouldn't install URL because react-native-ble-plx is shipped with an Expo config plugin on its own.

@Santa0727
You don't need to eject expo, you just need to prebuild the native code because without using native code this package won't work.


Apologies, must've not been running the test in the instance I thought I was last night.
With `emacs -q` I no longer get the error.


Hi @raymond91125
Is my suggestion above not working What do you propose to do?

Thanks, Pascale


Hi @riboher the tab got auto closed.
Please let us know if you still tun into any problems.


Hey @codecapitano - I encountered this issue while your release was still going through the pipeline. Talk about responsive support! :)

But unless I'm mistaken, this does not seem to have fixed the issue, I'm still seeing it with 1.7.1:

`TS2322: Type '(children: ReactNode, parentPath?: number[] | undefined) => RouteObject[]' is not assignable to type 'ReactRouterV6CreateRoutesFromChildren'.
 Type 'RouteObject[]' is not assignable to type 'ReactRouterV6RouteObject[]'.
 Type 'RouteObject' is not assignable to type 'ReactRouterV6RouteObject'.
 Type 'IndexRouteObject' is not assignable to type 'ReactRouterV6RouteObject'.
 Type 'IndexRouteObject' is not assignable to type 'ReactRouterV6BaseRouteObject & { children?: undefined; index: true; }'.
 Type 'IndexRouteObject' is not assignable to type 'ReactRouterV6BaseRouteObject'.
 Types of property 'action' are incompatible.
 Type 'boolean | ActionFunction | undefined' is not assignable to type '((...args: any[]) => any) | undefined'.
 Type 'boolean' is not assignable to type '(...args: any[]) => any'.`


Hi @riboher thansk a lot for the quick testing. I can confirm the issue.
we fixed a problem in regards to data routers which were also having type issues.
I'll see hat `createRoutesFromChildren`as causing problems as well.

We'll fix it.


One question:
Do you use data routers or standard routers?

Asking because if you use data routers you don't need provide `createRoutesFromChildrenas`.

ts
import { matchRoutes } from 'react-router-dom';

import { getWebInstrumentations, initializeFaro, ReactIntegration, ReactRouterVersion } from '@grafana/faro-react';

initializeFaro({
 // ...

 instrumentations: [
 // Load the default Web instrumentations
 ...getWebInstrumentations(),

 new ReactIntegration({
 router: {
 version: ReactRouterVersion.V6_data_router,
 dependencies: {
 matchRoutes,
 },
 },
 }),
 ],
});


Hi @codecapitano! I think you tagged me by mistake 😅 . Let me try the new fix and I'll let you know if at least I run into any issues. Thanks for the quick solution!


@riboher

Oh that's awesome thank you so much ❤

I added the link to the PR so that you are aware we are working on it.


Hi @codecapitano, unfortunately the error still shows up 😞 . Let me show you my faro initialization code as well as the use of `withFaroRouterInstrumentation`

init({
 apiKey,
 app: {
 environment: config.appEnv,
 name: 'app-name',
 version: config.appVersion,
 },
 ignoreErrors: [],
 instrumentations: [
 ...getWebInstrumentations(),
 // Enable this back again once this issue is resolved URL
 // new TracingInstrumentation(),
 new ReactIntegration({
 router: {
 dependencies: {
 matchRoutes,
 },
 version: ReactRouterVersion.V6_data_router,
 },
 }),
 ],
 url,
 });

const routes = getRoutes({ query: { client: queryClient } });
const router = createBrowserRouter(routes, { basename });
const browserRouter = withFaroRouterInstrumentation(router);

const AppRoot = withFaroProfiler(() => {
 return (

 );
});

 Same error as before

 Types of property 'routes' are incompatible.
 Type 'AgnosticDataRouteObject[]' is not assignable to type 'ReactRouterV6RouteObject[]'.
 Type 'AgnosticDataRouteObject' is not assignable to type 'ReactRouterV6RouteObject'.
 Type 'AgnosticDataIndexRouteObject' is not assignable to type 'ReactRouterV6RouteObject'.
 Type 'AgnosticDataIndexRouteObject' is not assignable to type 'ReactRouterV6BaseRouteObject & { children?: undefined; index: true; }'.
 Type 'AgnosticDataIndexRouteObject' is not assignable to type 'ReactRouterV6BaseRouteObject'.
 Types of property 'action' are incompatible.
 Type 'boolean | ActionFunction | undefined' is not assignable to type '((...args: any[]) => any) | undefined'.
 Type 'boolean' is not assignable to type '(...args: any[]) => any'.ts(2345)


Thanks so much for your help @riboher 🙏

It seems that for some reason it's still pulling the old `ReactRouterV6RouteObject`

With 1.7.1 `withFaroRouterInstrumentation` uses `RouteObjectV6DataRouter[]` [[1]]( URL

Which is referencing the Index/NonIndex routers [[2]]( URL


That definitely fixed the issue @codecapitano! Thanks a lot for the suggestion. What a rookie mistake 😅 . You can close the issue if you want, everything seems fine on my side. Thank you again!


Perfect glad it's working now.
Then I can release the second fix.

Thanks again for reporting and testing 🙏


Have you found a solution to this problem?
We will close this issue once, but if the issue is still not resolved, please reopen it or post a new issue.


Hi @azdagron I am interested in helping out here. I am looking around to find code base where this caching needs to be done and I have found this `/pkg/agent/plugin/workloadattestor/k8s` package I hope this is where I should start looking.

Also about caching part you plan it to be in-memory thing ?


I've made that edit, with some small changes.

1. I removed the reference to a distinct category, since we haven't formalized anything about that.
2. I moved the point about _direct_ supermethods into the main paragraph, and made the second paragraph only about analyzing calls to such methods.


Hi all,

I'm reaching out with a couple ideas/options for the Seal of Approval process, to see if we can find one that everyone agrees on.

**On this repository:**

@jangorecki expressed some concern with a list on this repository's ReadMe, because it implies some kind of closed community, instead of data.table being accessible to anyone.

I propose that we simply at a `Seal-of-Approval.md` file in this repo that contains a simple list of packages that have gotten approval. Then, we can link to this md at the bottom the ReadMe, in the Community section, and reserve all additional details for blog posts on the raft instead of them clogging up this repo.

**Approval process:**

At first, @TysonStanley had suggested that approval was initialized with a PR to this repo, and @MichaelChirico was wondering about the expectations from maintainers for reviewing.

I want to suggest a reverse-order:
* Folks seeking Seal of Approval would submit by PR to The Raft.
* Here is a sample draft for what would be submitted.
* I would act as a first screen, and then if the proposal seems reasonable, I would PR this repo with the relevant information.
* I could also, if desired, tag reviewer(s) in my PR.

This would be kind of a mini "journal-style" process that would maybe take some of the burden off the maintainers.

**Longevity:**

Michael also asked about whether this approval is granted in perpetuity or not. I think just workload wise, we wouldn't commit to periodic re-reviews. However, if someone were to alert us to an issue with a package - say, it's no longer actively maintained - we'd take it off the list at maintainer's discretion.

**Type of SoA Packages:**

I've come up with four types of packages that might merit approval; in principle, a submitter would have to justify the package falling in one or more of these categories. I'd love feedback if anything seems amiss:

- [ ] **An extension package:** Adds to the internal functionality of `data.table`

- [ ] **An application package:** Uses `data.table` to accomplish a particular task or analysis.

- [ ] **A bridge package:** Translates `data.table` syntax to different syntax or provides helper functions for transitioning between `data.table` and another object type.

- [ ] **A partner package:** Not necessarily directly connected to `data.table`, but deliberately follows the core philosophies of `data.table`.

---

So, tl;dr, in this proposal:
* Someone submits info on their package to The Raft
* I review it, then PR this repo adding the package name to a simple .md list, and supply relevant info for maintainters
* Maintainers merge PR at their discretion
* Package is then published as a blog post to The Raft

Let me know if this sounds workable to you, or if you have other suggestions! :)


I am closing this issue, since ll issues errors with dynamic backend tests (on CPU) are fixed. Thanks!


Hi @lilgreenbird
Thanks for fixing. May I know when a stable release (12.7.0) for this be available ?


The "distinct category" has been the whole point, so I'm a firm thumbs-down for now.


Inherited classes should not access `private` members. Removing the type is/was necessary for compatibility/implementation-hiding reasons: URL

This is somewhat a duplicate of #51489.


I concur, your non-elpaca test works for me with `emacs -Q`. I tried setting `(setq default-process-coding-system '(utf-8-unix . utf-8-unix))` before running the test in `emacs -Q` and it still succeeds.

There is some very hairy quoting code in emacs's `w32proc.c` but at the moment I can't debug into that.


We're adding SSR to our legacy Angular project after upgrading to Angular v17.3.6, and it's now crashing the server-side node app due to looping selector errors (both with Vite dev server and express production app builds). The CSS styles are Telerik's, which may be hard to mitigate:

Angular is running in development mode.
7 rules skipped due to selector errors:
 .k-input-label:dir(rtl) -> Unknown pseudo-class :dir

Besides the "inlineCritical" workaround, which doesn't seem(?) to work initially, I saw that the Angular team commented on maybe finding a temporary solution that involves pinning a working Critters version... can anyone here indicate what version that should be, as well as whether this is targeted for a near-term fix?


@MartinJohns

Alright, after reviewing the information you provided, I understand the complexity of this issue.

There are indeed several ways to address this problem, such as using `protected` or using a symbol to retain the type.

typescript
const xxx: unique symbol = Symbol()
class MyClass1 {
 declare [xxx]: A
 private a: A;
 constructor(a: A) {
 this.a = a
 }
}

However, one concern is that I test my code in ProjectA, everything works fine, but only after compiling, publishing, and then importing into ProjectB do I encounter the issue. This situation is troublesome because I have to go back and modify ProjectA.

Ideally, if such coding practices are not allowed, I would prefer to be notified of errors while writing ProjectA.

I expect consistency in behavior before and after code compilation.


Good idea. I'll try and isolate a minimal reproduction case.

Once we have a solid reproduction case, if I'm confident it's not something on Elpaca's end, I'll open a bug report upstream.
Eli uses Windows, so he may have some knowledge of the inner workings there.

Good catch and sorry about that!
I refactored `elpaca-info` to make it easier to use in tests, and as you've noticed, missed that call site in `elpaca-ui-info`.
Should be fixed on master now.

You can add the "#verbosity" search tag to your search query to temporarily set `elpaca-verbosity` to a maximum in the log buffer.
The `elpaca-info` buffer should normally display the whole log, too.

I recently refactored `elpaca-log` to make it easier to use from lisp programs as well.
The following should write the full log to a file:

 emacs-lisp
(with-temp-buffer
 (insert (elpaca-log ".*"))
 (write-file "/tmp/test.log"))


So even though the property is private, it has observable structural implications that are lost in the generated typings.

Would the ideal be that private properties be hidden from inference machinery so that code like `type X2 = MyClass2Sub extends MyClass2 ? x : never` would always yield `never`?


I seem to have a fix for this issue! Since forever (maybe 15 or 20 years anyway), I've had this in my init file: `(setq w32-quote-process-args ?\")`
If I remove that, my elpaca setup runs to completion.
I have no idea why I had to have that, all those years ago; I expect the default value of `t` is fine.
I also can't explain why you *can* repro it, unless you have the same setting.


Aha! I figured it might've been a user option.

I was running your config on Windows :).


Thank you!
Let me know if that also takes care of URL for you.


This specific issue seems to be gone now since I applied a user fix (see #303) but I'm still getting an issue with transient; magit-commit requires a very recent version of transient (>=20240421) but elpaca doesn't install that, so the magit-commit install fails.
The log is:

git-commit [MELPA|NonGNU-devel ELPA]
Edit Git commit messages.

source: MELPA
url: URL
menu item recipe:
( :package "git-commit"
 :fetcher github
 :repo "magit/magit"
 :files ("lisp/git-commit.el" "lisp/git-commit-pkg.el")
 :old-names (git-commit-mode)
 :source "MELPA")
full recipe:
( :package "git-commit"
 ;; Inherited from elpaca-order-functions.
 :depth 1
 :inherit t
 :protocol https
 ;; Inherited from elpaca-menu-item.
 :source "MELPA"
 :old-names (git-commit-mode)
 :files ("lisp/git-commit.el" "lisp/git-commit-pkg.el")
 :repo "magit/magit"
 :fetcher github)
dependencies:
 emacs >= 26.1
 compat >= 29.1.4.5
 transient >= 20240421
 with-editor >= 20240415
dependents:
 magit
installed version: 3.3.0.50-git f7cba11
statuses:
 (failed unblocked blocked continued-dep queued)
files:
 $REPOS/magit/lisp/git-commit-pkg.el ! $BUILDS/git-commit/git-commit-pkg.el
 $REPOS/magit/lisp/git-commit.el ! $BUILDS/git-commit/git-commit.el
log:
 [2024-05-08 12:20:41] Package queued
 [2024-05-08 12:20:41] Continued by: elpaca--continue-dependency
 [2024-05-08 12:20:41] Continued by: elpaca--dispatch-build-commands
 [2024-05-08 12:20:41] Queueing Dependencies
 [2024-05-08 12:20:44] Continued by: elpaca--check-status
 [2024-05-08 12:20:44] Unblocked by: with-editor
 [2024-05-08 12:20:44] Checking dependency versions
 [2024-05-08 12:20:44] transient installed version (20240408) lower than min required 20240421
 [2024-05-08 12:20:44] Continued by: elpaca--check-version

If I do `(use-package transient)` before `(use-package magit)` it works, but I don't think I should need to do that -- maybe it's due to the older version of transient being built-in, so elpaca doesn't want to silently override it on my behalf?


I have taken "category" to be a well-defined concept _in the conformance tests_ (not that we have a system fully fleshed out, but I think we understand what a different category _means_ there), but there is some ambiguity as to whether we're also talking about things like `@SuppressWarnings` strings. (Presumably we can all agree that we're _not_ saying that a tool has to decide either (a) to report to users every finding of a particular "category" or (b) to not report to users every finding of a particular "category.")


@raymond91125
See @amandamackie 's input in the annotation ticket: URL

GO:0003957 NAD(P)+ transhydrogenase (B-specific) activity 's definition and the parent ''proton transmembrane transporter activity'' should be removed.

Thanks, Pascale


The 12.7 preview release is available. The next stable release to include this will either be the 12.6.2 hotfix and/or the 12.8 GA release. We have not finalized a date for the hotfix, but the GA can be expected at the end of July (July 31).


@vedhavyas is the issue not fixed between #2568 and #2651 by setting up bundle weight limits that in turn limit extrinsics?


Glad to hear it.

You're correct. Currently, Elpaca will not install a built-in package unless you explicitly request it.
There's a feature request for automatically updating built-in packages and some previous discussion here: URL

What's specifically happening in this situation is:

git-commit requires transient with a "YYYYMMDD" timestamp version (which MELPA introduced, and very few package authors use to declare dependencies).
Since transient is built-in, we have no reliable way of getting the exact date it was last modified.
Elpaca's compromise is to maintain an alist of Emacs release dates for stable versions and fall back to `emacs-build-time` for unstable versions when available.
That value is stored in `elpaca-core-date` which is used as the timestamp version for any built-in package.
My hunch is that your `elpaca-core-date` is "20240408" considering:

emacs-version: GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-04-08

Rebuilding Emacs should bump that value and transient will pass the version check.
It's also possible to work around the issue by lying to Elpaca about the version date (via the `:version` recipe keyword), or disabling the check altogether, but that may lead to breakage.


if it just about UI

dart
Transform.flip(
 flipX: true,
 child: Image.file(
 File(selfieImagePath!),
 ),
 )


This was closed as 'completed' in Nov 2023, but seems to still be an issue. It's frustrating having to work around this issue with `-Verbose:($PSBoundParameters['Verbose'] -eq $true)` everywhere.


Thanks for your feedback. To use 2 picoScan lidars under ROS-1, start sick_scan_xd twice with different ip addresses and topics in two ros nodes. See the FAQ for an example configuration.

sick_scan_xd publishes PointCloud2 and LaserScan messages, SLAM and navigation using two lidars is a bit beyond the scope of the driver. See slam.md and #206 for more information or use run_linux_ros1_simu_slam_mrs1xxx.bash resp. test_200_slam_ros1_hector.launch as an example.


Hi @LittleFatHero . Would you be able to try out the various versions (including prerelease versions) between 1.89 and 1.20.5, to isolate which version seems to introduce the performance regression?


How far are we from getting this done? rc1 is scheduled for next Monday, but judging by the urgency and remaining work, we can push it out a bit.


I've opened URL to fix this specific issue.

I am aware that this is still labeled as `needs discussion` but I am hoping that showing the actual change illustrates the issue better and that we can move forward with this.

If this is not a change we want to make at this time, then that is fine aswel :)

--------------

Deprecating `ignoreSelectors` and adding `ignoreFunctionalPseudoClasses` can be separate issues?


If you fill them/it remember to add a task to #7396.

Is this the only rule affected?
`no-descending-specificity` has one test that uses `:global()`.


Ill repurpose this ticket so that it can be accepted.
i.e. updating the tests is just a simple refactor and doesn't require a changeset


I have repurposed this ticket in light of URL
The intended usage needs to be explicit.


It seems like it worked as expected, because that an internal windows installer behavior.

Windows Installer mostly does nothing on reinstaller. To restore an installation, you have to force a repair mode.

with

msiexec.exe /fa "windows_exporter-0.26.0-amd64.msi" /qn

the service is getting restored. I tested that on a windows server. Sadly, we are unable to change the windows installer behavior here.


Reassigning to Lang as this requires compiler changes in how we import builtins. There's not much the library itself can do short of providing a smaller transitive closure set of builtins/prelude.


I fixed the impossible dates by limiting Kingfisher Process's metadata endpoint to > Unix epoch and <= today.

This issue could remain open for this reason, but ...

That's too much overhead. So, we can just make a note in the quality issues.

FWIW, Vialidad seems to not have the issue anymore: URL


Hey guys,

I made some changes for the new Jellyfin version.
Would be nice if you guys could give me an update on the appearnce of the button for the new version.

If you are still unable to see the button please check inside the browser console if you can see some messages with the prefix `[InPlayerEpisodePreview]`


after testing the new update on 10.9 on docker, i finally see the the boutton and the console logs of docker show me this

chrome_jy859TINZm
chrome_PWk0Hn55rf

but nothing in the chrome 124 console logs


Ha that is weird that you don't have anything in the chrome logs.
Well glad it works for you now 👍


No luck for me. Chrome still doesn't show logs or button on the latest 10.9


You can check your log files in jellyfin under Home -> Dashboard -> Logs
Have a look if anything comes up if you search for `Loaded assembly "Namo.Plugin.InPlayerEpisodePreview, Version=1.1.0.0`


Damn here I see the issue

Namo.Plugin.InPlayerEpisodePreview.InPlayerEpisodePreviewPlugin: Attempting to inject preview script code in "C:\Program Files\Jellyfin\Server\jellyfin-web\index.html"
[2024-05-13 00:19:08.336 +05:30] [ERR] [104] Namo.Plugin.InPlayerEpisodePreview.InPlayerEpisodePreviewPlugin: Encountered exception while writing to "C:\Program Files\Jellyfin\Server\jellyfin-web\index.html": "System.UnauthorizedAccessException: Access to the path 'C:\Program Files\Jellyfin\Server\jellyfin-web\index.html' is denied.


Here as well

2024-05-13 00:42:49.440 +05:30] [INF] [1] Emby.Server.Implementations.Plugins.PluginManager: Loaded assembly "Namo.Plugin.InPlayerEpisodePreview, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null" from "C:\ProgramData\Jellyfin\Server\plugins\InPlayerEpisodePreview_1.1.0.0\Namo.Plugin.InPlayerEpisodePreview.dll


Okay yeah seems like the script doesn't have the right permissions.
What you could try to do is editing the index.html yourself.

Check your jellyfin installation for the file.
Inside the file look for a section where ` `

If that doesn't work you may have to find a solution for the write permissions to the file on your system.
I don't think i can change anything about that on the plugin side


I think the crash is pretty clear. In fact it is crystal clear. MMKV is NOT initiated correctly.

What is your problem?


Uploading Screenshot 2024-05-13 at 10.23.01.png…
Cheers ! Sorry that I forgot to mention that I have initialize the mmkv by calling this function.


Uploading Screenshot 2024-05-13 at 10.26.49.png…
I'm not sure that if you could open the screenshot or not. So I upload it again and with the paste of the snippet

class AppDelegate: UIResponder, UIApplicationDelegate {

 var window: UIWindow?

 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
 // Override point for customization after application launch.
 window = UIWindow(frame: UIScreen.main.bounds);
 window?.backgroundColor = UIColor.white;

 MMKV.initialize();


I'm not buying it. Please provide the full logs of mmkv, starting from App launch.


You should make mmkv initialize the first line of your didFinishLaunch, not the third line.


No, that is the crash stack. I'm taking about logs from console.


To be clear, add a line of log before you call MMKV.initialize(). And if there's no log, then mmkv is not initiated.


And if that's the case, move it to your main() function or create a constructor function for your AppDelegate.

swift
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
 init() {
 MMKV.initialize()

 super.init()
 }
……
}


A solution that works for me is to add `WidgetsBindingObserver` mixin to the widget encapsulating the list view, add it as an observer to `WidgetsBinding.instance` and implement `didChangeMetrics` as follows:

dart
@override
 void didChangeMetrics() {
 super.didChangeMetrics();
 setState(() {});
 }

hope this helps


Hmm well, they are not setting it to the current date but the dates are still incorrect.


Does anyone else have known incorrect dates (between 1970 and today)?


Unfortunately, I ran into some difficulties and this is not ready yet. I'm aiming to build up to a minimally useful implementation within the next few days.

If this FR is the only reason we would delay rc1, it would be fine to get it out today, under the (not so unreasonable?) assumption that there will be an rc2 that the remaining changes can still make it into.


With the updated query in Kingfisher Process their dates will be in a reasonable range (see above commit). Will they have incorrect dates even within that range?


I think your fix will work (the files will still be segmented by all the available years though, right?)


Yeah, the exporter worker reads directly from Kingfisher Process without applying similar conditions/filters.


It also happens in Paraguay Hacienda URL but they are not updating their data anymore anyway so I think we can leave the issue closed


/reopen

Is readding this feature to v2 planned for future releases? It would be very helpful.


I'm a bit unfamiliar with the v1 version of this, did this come from argo's archive logging feature?

In v2 kfp aims to be agnostic to the backing engine, so if this is an argo specific feature, we may need to consider a separate feature/proposal on how to handle persistent logging in general for kfp.


Yes, Argo Workflows stores the logs separately and given only kfp metadata, there currently seems to be no way to obtain the logs' locations. You'd need to access the Argo Workflow object directly to obtain the info.

Including this feature right into kfp would make sense and imo is much needed, as otherwise, users aren't able to view logs after the step's pod has been deleted.


[2024-05-14 22:45:48.931 +05:30] [INF] [24] Emby.Server.Implementations.Plugins.PluginManager: Loaded assembly "Namo.Plugin.InPlayerEpisodePreview, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null" from "C:\ProgramData\Jellyfin\Server\plugins\InPlayerEpisodePreview_1.1.0.0\Namo.Plugin.InPlayerEpisodePreview.dll"

Did as suggested. Even disabled the custom css, thinking it might be creating issues. No help


@SteveL-MSFT this is a bot-closed issue that is still active and should be reopened.


Yes, @Rishikesh01. That is the correct package for the Kubernetes workload attestor code.


@jakoblell
For substrate based chains, we ensure the total weight of all transactions in a given Bundle are at most BundleWeightLimit. More here - URL
This should not allow FP storage proofs to blow up since the all the reads are accounted in individual tx_weight.

One thing note here is that if the txn weights are outdated or wrong, this would be a problem since actual execution weight could be completely different. This may not be a problem for Runtimes we provide like EVM or AutoID but poses a bigger issue if and when we allow custom domain runtimes where they could completely give wrong weight for a given transaction.
In such case, this issue will come back where honest operator wont be able to submit a FP.

Ideal solution would be to get the actual execution weight for a given transaction and then use it in BundleWeightLimit. But getting such a would require us to execute the txn, collect the actual weight. This would be in-efficient but necessary unfortunately.

This might not be necessary if we get the actual execution weight but simply limiting the proof size will not solve the issue since proof sizes can go over anyway and fraud proof will not submitted due to size limits


I have added the lines at the beginning of the code.
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

 var window: UIWindow?

 override init(){
 print(Thread.current)

 MMKV.initialize()

 super.init()
 }

 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

 // Override point for customization after application launch.
 window = UIWindow(frame: UIScreen.main.bounds);
 window?.backgroundColor = UIColor.white;

Here is my backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
 frame #0: 0x0000000105ec49ec libsystem_kernel.dylib`__pthread_kill + 8
 frame #1: 0x0000000104e6f1d0 libsystem_pthread.dylib`pthread_kill + 256
 frame #2: 0x00000001801655c0 libsystem_c.dylib`abort + 104
 frame #3: 0x00000001802a7798 libc++abi.dylib`abort_message + 128
 frame #4: 0x0000000180298eec libc++abi.dylib`demangling_terminate_handler() + 300
 frame #5: 0x0000000180063498 libobjc.A.dylib`_objc_terminate() + 124
 frame #6: 0x00000001802a6c70 libc++abi.dylib`std::__terminate(void (*)()) + 12
 frame #7: 0x00000001802a9acc libc++abi.dylib`__cxa_rethrow + 144
 frame #8: 0x0000000180087f48 libobjc.A.dylib`objc_exception_rethrow + 40
 frame #9: 0x00000001804085c4 CoreFoundation`CFRunLoopRunSpecific + 748
 frame #10: 0x000000018ef06ae4 GraphicsServices`GSEventRunModal + 160
 frame #11: 0x00000001853e8040 UIKitCore`-[UIApplication _run] + 868
 frame #12: 0x00000001853ebcc8 UIKitCore`UIApplicationMain + 124
 * frame #13: 0x0000000104c92724 moment`main at AppDelegate.swift:13:7
 frame #14: 0x0000000105439544 dyld_sim`start_sim + 20
 frame #15: 0x0000000104f360e0 dyld`start + 2360

Also, I have upgraded the UIKit to the latest version. This issue is still unfixed.


What are the logs from the console?
Is it so hard to understand?


Have you checked again if you see anything in the chrome logs (Press F12 -> Go to console, and then start an episode)


Okay, when you are watching a video, could you right click and select "View Page Source".
Then search with Ctrl+F for `/InPlayerPreview/ClientScript`.

In theory you should finde the line you added to your index.html


So normally that line should download the scriptfile from the plugin.
Next thing you could try would be:
- uninstall the plugin (just to be sure)
- download the web-client-script
- copy the js file inside into the folder where your index.html is
- replace the old script line from the plugin with this one:

html

If that isn't working try this line:

html

Remember to restart your jellyfin server in between


I guess mine is an isolated issue. Tried both lines, after uninstalling and multiple restarts. Could'nt get it to show up.

image
image


I have created a plugin which goes into this direction but I'm still testing it internal so consider it alpha.
 URL


I talked a little with @pkalita-lbl about proximate places to look for the issue. While adding a fix (encoding/decoding), there may also be consequences in the UI filters and bookmarking, in addition to the "main" issue of the query to the Solr server.

There are some oddities that have slipped into the code over the years in response to years of LBL testing (e.g. URL the bug may be a consequence of that (or just a regular "oops" on my part). Either way, a fix should be XSS-safe.

The problem code is probably in the `bbop-manager-golr` package, at URL . A possible place to start might be URL which uses `encodeURI()`. One way to approach this would be by the tests in that package, although that may practically be a slow way forward.


The JS code is old, baroque, and quirky (ooo--`prototype`!). If any problems or confusions come up, it's probably faster to drag me in than directly wrestle with whatever was in my head at the time.


You know what, I'm tired of repeating to ask the same question. Why don't you upload a reproducible demo?


Sorry for causing you any trouble. I'm still learning as a beginner. Here is the repository of the project: URL


hi! thanks a lot for creating this extension and also for sharing this writeup.

i completely understand your concern, and totally agree with points raised. i also was feelng the same regarding quoted part.
so, would u mind sharing a recommendation for any such site which's supported by competitive-companion?

i tried codeforces, but that doesn't really fit (or say i don't know how to tune it to) the problems that leetcode offer. it gives abstract names to problems - which works if doing things recreationally, but not when using it as a guided syllabus.

i also tried hackerrank too, but similar problem as above.


The problem is that you have called the wrong initialize method.

swift
// MMKV.initialize();
MMKV.initialize(rootDir: nil);

Change it as the code above and you should have no problem.

The `initialize()` method is inherited from NSObject and is useless. I should make it hidden later.


Ich habe ein älteres Ticket gefunden, dass sehr ähnlich klingt: #516
Kann eins davon zu?


Cheers! I think I couldn't find the log from console even though I tried many times across the Internet. Could you please tell me how to do it? Many Thanks!


@codecapitano Sorry for the late reply, but thanks for looking into this. Anything you need from me at this point?


Hi @barrykaplan We released an update which fixed the issues with the typings (v1.7.2).
See this issue.

Do you still have this problem?


Here is my workaround.

sh
find /path/to/bazel-cache -amin +1440 -delete 2>/dev/null || true

The command searches for files in the /path/to/bazel-cache directory that have not been accessed in the last 1440 minutes (24 hours) and deletes them.


It won't help you to "trim to size" if you need to fit cache below a certain threshold of disk space.


@peaceiris I don't know for certain, but our experience strongly suggests that *any* process that deletes files directly from the cache like that is doomed to cause strange failures sooner or later. It may depend on specifically what tasks bazel runs; we've found that code coverage jobs are especially brittle.


Yes, I think that's right. So we're looking forward to implementing this feature in Bazel.


@Namo2 finally got an error log in the console, hoping this can be a help. BTW the plugin works awesome in the JMP

image


Quickly patched this up.

The dll is the complete plugin. You would need to go in your jellyfin folder then to plugins and open "InPlayerEpisodePreview_1.1.0.0". Just replace the dll inside there with the one from the zip.

If that works hit me up. I would make the changes public then

inPlayerEpisodePreview-1.1.1.0-beta-server.zip


Just a query. Even though on your suggestion, I am using JMP, but some of my users use phone to watch my library. Is changing episode from the prompt on web (since the Android app is a web wrapper) totally not possible and is a code limitation, out just currently not implemented?


I will check how hard it would be to implement but my main focus for the future will be to get this feature/plugin into the official jellyfin version


URL

To me it looks like this is just in the domain block/bundle production code used by honest domain operators - but this weight limit isn't actually enforced on chain. A malicious domain operator can trivially patch out this check and submit an invalid and overweight domain block. This can lead to a situation where a fraud proof cannot be submitted due to the size of the required storage proof.

In order to prevent that, the domain runtime should directly reject blocks exceeding a reasonable weight limit (including a proof size weight). Enforcing a block weight limit on a substrate-based chain is typically implemented via `frame_system::CheckWeight` based on the `BlockWeights` configuration, which is currently still configured to `u64::MAX`:

* URL
* URL
* URL

Well there may be some gaps/inaccuracies in the proof size weighting but in theory it should be sufficient to limit the required size for the storage proof required in a fraud proof. In practice there should be some safety factor between the allowable domain block proof size weight and the consensus chain block length limit so that a fraud proof will always fit into the limit.


The original commit here URL was supposed to enable `WebpackCompressionPlugin`. However `WebpackCompressionPlugin` seems to be broken and does not play well with `HtmlWebpackPlugin` when `deleteOriginalAssets: true`.

I have filed two related bugs here:

 URL

 URL


I have temporarily fixed this by reverting the original commit, here: URL leaving open for investigation how to properly implement gzip + delete


Unfortunately we won't have enough time for this in 7.2.0; postponing to 7.3.0


In Player 1.28.3 habe ich den gegenteiligen Wunsch implementiert!
Seid ihr sicher, dass ihr wieder zurück wollt?


Hi, I am not sure now, where should we add these configurations ?
{
 isBackgroundEnabled: true,
 modes: ["peripheral", "central"],
 bluetoothAlwaysPermission:
 "Allow $(PRODUCT_NAME) to detect your bluetooth device"
}


[Triage] Closing as a duplicate of URL Even though this issue was logged first, URL has more detail.


@kennyyen
in your `app.json` or `app.config.js` URL

json
{
 "expo": {
 "plugins":
 [
 "react-native-ble-plx", // URL
 {
 isBackgroundEnabled: true,
 modes: ["peripheral", "central"],
 bluetoothAlwaysPermission: "Allow $(PRODUCT_NAME) to detect your controller with bluetooth"
 }
 ],
 }
}


Thank you for the response, I did tried to put them in my app.json, and when I do
`npx expo install react-native-ble-plx`
I get this

Skipping config plugin check: Plugin is an unexpected type: object


Thank you for the clarification ! It works just fine as before !


I would really appreciate this as well, since I find it incredibly annoying to have to close it again and again every time I just want to have a look at my data and don't need to see the basic Data Summary.


Hey @joaomoreno, this issue might need further attention.

@degtiaan, you can help us out by closing this issue if the problem no longer exists, or adding more information.


Does something to combine this PR and your plugin would be possibly cause to button for something similar would really make the UI messy and too much I think.


Thanks for mentioning it.
The plan is to open a discussion for this feature anyway but before i want to rewrite the core of it, so it would be ready for merging. Changes for the UI etc can be discussed then


@mpern with PR URL merged, this should be resolved now. After `mise cache clear` the command `mise ls-remote java` should show no more semantically incorrect versions.


Is the problem that `nm-online` with `-s` on an already-up system hangs (what this thread seems to think)?

Is the problem that `NetworkManager-wait-online.service` _should_ not have `-s` (what upstream seems to think)?


I do not see any confusion about this from the upstream side; they did not claim that distros should not use `-s` at any point in the thread you linked.

We want a flag that does what `-s` is currently documented to supposedly do:

 -s | --wait-for-startup
 Wait for NetworkManager startup to complete, rather than waiting for network connectivity specifically. Startup is considered complete once NetworkManager has activated (or
 attempted to activate) every auto-activate connection which is available given the current network state. This corresponds to the moment when NetworkManager logs "startup
 complete". This mode is generally only useful at boot time. After startup has completed, nm-online -s will just return immediately, regardless of the current network state.

 There are various ways to affect when startup complete is reached. For details see NetworkManager-wait-online.service(8).

The manual even explicitly clarifies behaviour after bootup is complete.

This is precisely what we want but `nm-online` simply does not work as documented. Instead of returning immediately, it blocks indefinitely under certain conditions.


Hello,

Thank you for providing such a detailed description and information about the issue. This helps reduce the number of interactions needed, which is greatly appreciated by open source maintainers.

Before addressing your question, I have a side note. What prompted you to modify the placeholder for `Tai-e Log` in our _New Issue Template_? We intend it to provide runtime information originally, such as `Tai-e Commit: d610a880a2c05968c9e60400f2041f281dee809f` and `java.runtime.version: 17.0.6+10`, among other details. This is not a complaint, just a user study. 😆

---

My Intuition: In this points-to set, a _%this_ variable of type `org.example.User` points to a `String`, which doesn't follow the type system. You should mock another `TaintObj` with the same type as _%this_.

You mentioned "Any", so it is temporarily not achievable directly in the current Tai-e. Because _Writing taint configuration programmatically is our future plan. It's being incubated._

But if you are in urgent need, I provide a simple idea below for your customized implementation: monitor all changes in the points-to set of all InstanceFields. If a `TaintObj` appears, mock a TaintObj which pointed to by the InstanceField's Instance's var.


According to URL URL should have fixed it. Do you still have issues?


Hi @HumairAK What do you think about this ?
Points:
- DS engineer would be interesting to see logs as artifact, as part of models producer investigation
- logs can have different retention against artifacts: user can clean them to reduce space usage
- it is better to have interactive logs

Thoughts:
- in launcher POD: use extra container for waiting logs and publish or use other approaches: fluentd.... it is up to user how to collect logs and put logs. But by default we will do by sidecar container. For this we should disable argoworflow logs.
- during run we subscribe real container logs stream (this logic already implemented)
- allow launcher use separate bucket for logs or use the same as artifact
- in sdk we should be able disable logs


I agree persisted logging is very important, but we should clarify if we need them as artifacts, or do users just want to see logs after pods have been removed?

For example, if we have persisted logs, the log viewer could instead fetch the logs from the persisted location instead of pods (I believe this is the logic currently present in ui, though it may not be utilized in v2). Could it be confusing to see 2 different locations where logs are being shown?

Not disagreeing, but could you elaborate on specifics?

I like the idea of decoupling implementation to existing solutions (or at least giving the user the option to, if we opt to natively implement),

I think we should also allow users to disable/enable not only in the SDK, but via api & ui as well.


Why engineers may interesting in this:
- some frameworks for ML logging kind of metrics
image
- kubeflow run is snapshot of inputs/intermediate/code/config which can help to reproduce or compare, so for the same combinations of inputs/intermediate/code/config, it is possible to have different logs due to different conditions in cluster: gpu, cpu, drivers.... that is why logs is part of this snapshot

v1 version was implemented correctly from concept view, because it combine logs interaction during run (life time stream from pod) and logs persistent for long term.


I still have the issue with KFP 2.2.0, which includes #10568 - does not look like the UI was updated to retrieve the S3 log artifacts stored by Argo. I have a fix in my fork that shows what is needed for the UI to work with the archived logs - URL


I found my `tai-e.log` is always empty :(. In case some information are needed:

commit: 47bdb8b2361083151a44ba76ee2f9f2dbd363b40
java: Java(TM) SE Runtime Environment (build 17.0.11+7-LTS-207)

 Thanks for your help. I wrote another transfer to do this:

public class ThisTransfer implements Transfer {
 HeapModel heap;

 public ThisTransfer(HeapModel heap) {
 this.heap = heap;
 }

 @Override
 public PointsToSet apply(PointerFlowEdge edge, PointsToSet input) {
 if (edge.target() instanceof CSVar && ((CSVar) edge.target()).getVar().toString() == "%this") {
 List append = new ArrayList<>();
 input.forEach(o -> {
 if (o.getObject() instanceof MockObj mo && mo.toString().startsWith("TaintObj")) {
 if (mo.getType() != edge.target().getType()) {
 append.add(new CSObj(heap.getMockObj(mo.getDescriptor(), mo.getAllocation(),
 edge.target().getType(), mo.getContainerMethod().orElse(null), mo.isFunctional()), o.getContext(), o.getIndex()));
 }
 }
 });
 append.forEach(input::addObject);
 }
 return input;
 }
}

and invoke in the plugin

solver.addPFGEdge(new PointerFlowEdge(FlowKind.LOCAL_ASSIGN, from, to), new ThisTransfer(solver.getHeapModel()));

[]: /name -> [[]:MergedObj{ }, []:TaintObj{alloc= /0,type=java.lang.String}]

From the log I can ensure the callee %this is tainted with correct type, however, the call site is

There is still no tainted object here. How can I notify or add the taint object to this? I think this should be handled by Tai-e automatically but something must be wrong.


What you do is `User.setName/%this /$r0 -> [NewObj]
 /%this -> [NewObj, TaintObj]

`$r0` and `%this` are two variables in different methods' IR. The `$r0` will propagate to `%this`; it is because `[2@L9] invokevirtual $r0. (r1);` create a PFG Edge from `Main.process/$r0` to `User.setName/%this`. However, `%this` will not backpropagate to `$r0`.


Is this related to kernel/firmware upgrade? This problem just occurred on my machine after a `nixos-rebuild switch`, manually invoking `nm-online -s` also waited 30s and timed out, but after a reboot I can no longer reproduce this, even with another `nixos-rebuild switch`. I updated my kernel and firmware in the first `nixos-rebuild switch`, updating from linux 6.8 to 6.9.


I noted that `tailscaled.service` is restarted before `NetworkManager.service` and `NetworkManager-wait-online.service`.

restarting the following units: home-manager-inme.service, home-manager-root.service, nix-daemon.service, polkit.service, systemd-journald.service, tailscaled.service
starting the following units: NetworkManager-wait-online.service, NetworkManager.service, audit.service, bluetooth.service, kmod-static-nodes.service, logrotate-checkconf.service, mount-pstore.service, network-local-commands.service, network-setup.service, persist-\x27-nix-persist-etc-machine\x2did\x27.service, persist-\x27-nix-persist-home-inme-.bash_history\x27.service, persist-\x27-nix-persist-home-inme-.gitconfig\x27.service, persist-\x27-nix-persist-home-inme-.repo_.gitconfig.json\x27.service, power-profiles-daemon.service, resolvconf.service, rtkit-daemon.service, systemd-hostnamed.service, systemd-modules-load.service, systemd-oomd.socket, systemd-sysctl.service, systemd-timesyncd.service, systemd-udevd-control.socket, systemd-udevd-kernel.socket, systemd-update-done.service, systemd-vconsole-setup.service, waydroid-container.service, wpa_supplicant.service, xray.service

Also confirmed in journalctl:

May 28 07:26:58 thinkbook-16-plus-nixos systemd[1]: Started Tailscale node agent.
░░ Subject: A start job for unit tailscaled.service has finished successfully
░░ Defined-By: systemd
░░ Support: URL
░░
░░ A start job for unit tailscaled.service has finished successfully.
░░
░░ The job identifier is 3587.
...
May 28 07:26:58 thinkbook-16-plus-nixos systemd[1]: Starting Network Manager...
░░ Subject: A start job for unit NetworkManager.service has begun execution
░░ Defined-By: systemd
░░ Support: URL
░░
░░ A start job for unit NetworkManager.service has begun execution.
░░
░░ The job identifier is 3744.
...
May 28 07:26:58 thinkbook-16-plus-nixos systemd[1]: Starting Network Manager Wait Online...
░░ Subject: A start job for unit NetworkManager-wait-online.service has begun execution
░░ Defined-By: systemd
░░ Support: URL
░░
░░ A start job for unit NetworkManager-wait-online.service has begun execution.
░░
░░ The job identifier is 3743.

And if I `systemctl stop tailscaled` before `nixos-rebuild switch`, `tailscaled.service` will be started after `NetworkManager.service` is started, and then `NetworkManager-wait-online.service` will exit gracefully.


Big if true.

That feels like something that should be solvable using a few systemd Before/After directives in the right places.

Though tailscaled.service already contains

After=network-pre.target NetworkManager.service systemd-resolved.service

IIRC `After` should be applied in reverse when stopping/restarting.


Correct. This should be handled with this Fraud proof - URL

We have set the Max limit for the Domain block because we have seen ExhaustResources during the Domain block import. Ideally, we want to ensure all the domain transactions in Consensus bundles should be executed on Domain. We are okay if the domain block import is slower but nonetheless executed. In order to avoid the excessive size coming from each extrinsics, we have introduced the POV size for EVM specifically and then we introduced MAX_BUNDLE_WEIGHT on consensus chain. One regression introduced with MAX domain Block limit is max extrinsic weight. We have an issue to fix the max_extrinsic_weight on domains while keeping the MAX domain block weight.

Once this above issue is fixed, there is reduced weight for each extrinsic and operators use that to calculate Domain Bundle weight. If the malicious operator do skip it, fraud proof will come into picture to slash that specific operator.

Let me know if that make sense @jakoblell