Question: [🕹] Feedback Fanatic?

/award 150

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

[🕹] Feedback Fanatic
### What side quest or challenge are you solving?

Fill out our feedback survey after the hackathon with suggestions for improvement

### Points

150

### Description

_No response_

### Provide proof that you've completed the task

Screenshot 2024-10-18 121846

whups, you already got points for that review :(

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

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

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

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

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

[🕹] Feedback Fanatic
### What side quest or challenge are you solving?

 Fill out our feedback survey after the hackathon with suggestions for improvement

### Points

150

### Description

_No response_

### Provide proof that you've completed the task

Screenshot from 2024-10-13 12-33-09


Question: Compatibility with JSR?

@sindresorhus Do we want to update anything with the `If*` types, as suggested in URL

I feel more inclined towards this, but `Is*` variants are likely much more common in codebases, so deprecating them could be annoying.

Compatibility with JSR
I love this module and use it in almost every project.

I've recently started using Deno and JSR, and this package can't be used in modules published there for the following reasons:

1. Imports/export strings need to specify the extension (e.g, `export * from 'file.ts'`.
2. `(... arguments: any[])` isn't allowed
3. Module augmentations aren't allowed.

Problems 1 & 2 are potentially solvable, but I don't know if (3) is solvable. Maybe this requires to make two different builds, one for JSR, one for npm?

In the meantime, and for my own needs, I've made a little conversion script, which may be useful to someone else, so I will post it here: ~~build script (it uses this to download and decompress the sources: downloadAndExtractFile)~~ repo is private, posted the files in a comment below.

If you'd rather use my version (no guarantees of updates, only building this for our own internal usage), you'll find it at URL

1. This will be fixed soon with URL
2. URL
3. Does it show where we use that? I think this is the only place: URL

@acrodrig unless I misunderstand how JSR works, you don't need this package being published to JSR to use it in your own jsr-published package; using the `npm:` specifier works just as well. Either `import type {MergeDeep} from 'npm:type-fest'` or in the CLI, `deno add npm:type-fest` and then `import type {MergeDeep} from 'type-fest'`.

v5
- [x] Target TypeScript 5.9
- [x] URL
- [x] `ArrayTail`: Make `preserveReadonly` option true by default.
- [x] Move to ESM
- [x] Target Node.js 20
- [x] Make the `preserveConsecutiveUppercase` option in `CamelCase` `false` by default
- [x] Remove this: URL
- [x] Make `PartialDeep` `allowUndefinedInNonTupleArrays` option `false` by default.
- [x] Make `Split` `strictLiteralChecks` option `true` by default.
- [x] URL
- [x] URL
- [x] `Schema`: Remove `undefined` from `recurseIntoArrays` option.
- [x] Add a constraint of `object` to `T` for `WritableKeysOf` and `ReadonlyKeysOf`
- [x] Remove `strict: false` workaround: URL
- [x] Move `ObservableLike` type to separate export since it mutates global: URL
- [x] Decide on If/Is types.

@som-sm @Emiyaaaaa I'm planning v5 for right after TypeScript 5.9 is out. Probably 2-3 months out.

Please discuss here if there are any other breaking changes we should do that are not mentioned in the issue body.

Cool @sindresorhus, I'll start creating PRs for the tasks listed here.

I think we can skip this for now, it'll required a proper rewrite, we can move it to v6.


Question: Configure the Log Level Colors?

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

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

Configure the Log Level Colors
Hello, I really love this plugin but I am having trouble figuring out how to configure the coloring of various Log Levels. Currently, it seems that INFO logs are colored yellow but none of the other Log Levels are colored. I attempted to look through Intellij's menus for a configuration option regarding this and have had no luck thus far. Is this possible? Thank you!

Not 100% sure, but don't think this is configured in this plugin or in itellij. Check out colorama, I also use structlog (which uses colorama)

@kevin-mark-rn Thank you for using the plugin! You can configure log colors as written here.

oh thanks I didn't know that is what configured them, thanks! Love the plugin

Add settings for changing colors
I'd like to configure my own colors. For example, I would definitely make WARNs yellow, because yellow is the color of warnings usually. Currently the plugin makes INFOs yellow.

Great tool, btw!


Question: [REQ] BTDigg DHT Tracker?

BTDigg is working on Linux/Docker Jackett but not Windows. Unfortunately, the usual solution (spoofing the User-Agent) isn't working. Doesn't matter if I use Linux Jackett UA, a slightly modified one, or my browser's UA.

Using the Windows Jackett UA in browser does not result in a redirect, so while I'm not sure what is causing it, it doesn't seem to be the UA.

I tried adding every request header being used in browser, with and without the UA, no luck. The site doesn't appear to use cookies, so there's nothing to try there.

Using a VPN, rather than Jackett's proxy settings, also doesn't work.

@Woody-Stock if BTDigg is a must for you, the only solution right now would be using Docker on Windows for a Jackett container.

@garfield69 any ideas what else it could be?

[REQ] BTDigg DHT Tracker
Tracker Name : BTDigg
Public tracker
Supports: magnet
Indexer URL : URL
Indexer language : English

 URL

note that both alternate domains are not working. I check the original onion link on a TOR browser and it is not working
check back in a month and drop those alternates if still down.

using the TOR browser to get to the .onion link worked this time, however the certificate is invalid (domain)
but the site was btdigg and searching for 2022 returned results.
however the *.ly and tor2web.to alternate links still do not work on the regular browser, perhaps due to the invalid CA
adding a certificates to the indexer, and switching to http did not help the indexer get results.

onion alternates are not working again, same reason as described in URL

well that did not last long. URL Origin is unreachable Error code 523

URL - ERR_CONNECTION_CLOSED
Only up for 10 of 42 Uptrends checkpoints.

BTDigg has started actively blocking Jackett and Prowlarr traffic from linux platforms.
This follows a period in March URL which went on until August. While windows traffic is a smaller percentage of total Jackett users, linux (via docker or native) is a much larger user base.
There seems little point trying to access this site from Jackett so I shall remove this indexer.

Not down for me at the moment, is there some dark magic going on?

Should leave the indexer in jackett so windows users can use it atleast. I don't see the reason for removing it entirely if it is still working for some users. It may start working again for linux at some point like it was previously with windows.

We're not always able to directly communicate with site owners/admins, and in those cases we take hints that we're not wanted. This is one such case.

Jackett features & user experience should take priority over uncooperative site owners/admins.

If they want to attempt to block jackett traffic entirely then so be it, but if it still working for some users why not just leave it and let the user decide if they want to use it.

Our userbase (and by extension, that too of Prowlarr) is large enough that we have the ability to (accidentally) DDoS sites. If a small site that is useful to the community, but is just being run off a NAS in someone's bedroom, is taken offline due us being wilfully ignorant, that serves no one.

We do not have an adversarial approach to trackers, where possible we want to work with them, improve the experience of their users, and we have made plenty of changes in the past to accommodate their needs.

If there's no easy way to communicate with site owners/admins, and we run into some change that stops Jackett from functioning properly (e.g. blocking our UA or a `latest` page), we will generally try to work around this a few times (as steps like these can often be automated rather than purposeful), but after after several attempts we will take the hint and remove the indexer.

FYI we have the same problem .. you can track it here:

- URL

Exception (btdigg): Got redirected to another domain. Try changing the indexer URL to URL Parse error
### Have you checked our Troubleshooting page for your issue?

- [X] I have checked the Troubleshooting page

### Is there already an issue for your problem?

- [X] I have checked older issues, open and closed

### Have you read our Contributing Guidelines?

- [X] I have read the Contributing Guidelines

### Environment

markdown
Windows 10 x64 22H2 19045.2728
Jackett v0.20.3717 but has been happening for several weeks
Flaresolverr deactivated as it doesn't work with proxies in its latest versions
HTTPS5 proxy activated (the targeted website isn't accessible without it).

### Description

Testing the BTDIGG index returns an error.

### Logged Error Messages

text
Exception (btdigg): Got redirected to another domain. Try changing the indexer URL to URL Parse error

### Screenshots

_No response_

Forgot to add that this seems the same issue as 12601 which was solved at the time.

Working ok here. Try several different proxies/VPN servers if you're still having the issue.

Tried with several different proxies and the result is always the same.
If that helps I'm using Privado proxies.

Using the same proxies, are you able to access URL in browser?

OK thanks for the answer, I will try that but never used Docker, so it will be a learning curve.

none whatso ever ;-(
ever the .onion link which works in a TOR browser does not work with the .ly or web2tor.to proxies.

Yes those TOR links stopped working a while ago but if this can be any indication, I think the regular link ( URL stopped working before that over a proxy (well the ones from Privado at the very least).

It is when those TOR links stopped working that I reverted back to the regular link and saw it didn't work. I always try to use the "real" link over alternate ones, so if I had configured TOR links at the time, it's probably because the original one didn't work for me. I honestly don't remember. I first assumed that this will be fixed in a next release but when it wasn't and saw on here it wasn't flagged I decided to open the issue.

Since then the TOR links were removed from BTDigg's Jackett indexer and not replaced unfortunately.

Just tried changing the UA in BrowserUtil.cs in case it was somehow picking up that the UA was spoofed, but no.

Also tried adding `webclient.EmulateBrowser = false` to Cardigann, didn't help.

Leaving this open for some future bright spark to solve, but I wouldn't hold your breath.

facing the same issue, using windows ver. with Flaresolverr activated; therefore no proxies.

Newly added *.tor2web.link mirror working on Windows Jackett - URL

The TOR link doesn't seem to work anymore so we're back to square one...

So has btdig implented something to detect jacket searches somehow? What is the relation to domflow.it?

Seems to me that btdigg is intentionally redirecting jackett searches to a dummy domain, probably to force people to use their site directly. It's possible that the redirect is happening at the cloudflare level. To fix this will probably require changing the way jackett indexes btdigg to avoid detection.

Can someone point me in the right direction on where in the jackett repository we should be looking in order to modify the code for how jackett uses btdigg? I'd like to take a crack at this. Thanks

Is the following code relevant? In URL

I was trying to skim through the code for jackett to figure out how btdig could be identifying requests coming from jackett. Maybe this will give some clues. I don't think the definitions will be helpful. The core code probably needs to be modified in order to avoid detection for this indexer. Perhaps btdig is able to identify the requests coming from jackett via referer or request type? Or maybe when emulateBrowser is null? Possibly a combination of things including the user-agent.

Hard to say, but the code is a bit steep for me since I am not proficient in CS. I'm curious how the requests coming from jackett look in cloudflare because that's probably where the redirect is coming from. Admins of btdig probably setup some redirect rules to match requests coming from jackett. Someone with more knowledge will have to investigate further.

cs
 protected virtual async Task RequestWithCookiesAsync(
 string url, string cookieOverride = null, RequestType method = RequestType.GET,
 string referer = null, IEnumerable > data = null,
 Dictionary headers = null, string rawbody = null, bool? emulateBrowser = null)
 {
 var request = new WebRequest
 {
 Url = url,
 Type = method,
 Cookies = cookieOverride ?? CookieHeader,
 PostData = data,
 Referer = referer,
 Headers = headers,
 RawBody = rawbody,
 Encoding = Encoding
 };

 if (emulateBrowser.HasValue)
 request.EmulateBrowser = emulateBrowser.Value;
 var result = await webclient.GetResultAsync(request);
 CheckSiteDown(result);
 UpdateCookieHeader(result.Cookies, cookieOverride);
 return result;
 }

I did try playing with UA and `EmulateBrowser` but didn't get anywhere. I assume that's where the issue lies, but 🤷

If this can be any help, I have the exact same error from Prowlarr.
So it seems this comes from BTDigg, rather than Jackett itself.
As someone suggested, it may be on purpose.

Today I noticed this indexer is working again. Can anyone else confirm?

I am getting successful tests in Jackett dashboard and successful searches/downloads in sonarr.


Question: Implementation details for Grad-CAM visualization?

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

Implementation details for Grad-CAM visualization
Thank you for creating and maintaining this wonderful project. I've been working with your codebase and found it very insightful.

I noticed that the project includes Grad-CAM visualizations, but I couldn't find any related packages like `torch grad-cam` in the requirements. I tried to reproduce the visualization part but encountered some difficulties. Would it be possible to share some example code about how the Grad-CAM visualization is implemented in this project?

Thank you very much for your time and consideration. Any guidance would be greatly appreciated!

Hi, did you check #2? It should not involve too many modifications to the original PyTorch grad-cam implementation. We will provide an example soon.

@WuDuidi Could you specify the difficulties you are encountering? I have identified the following common issues:

1. Absence of gradients for generating Grad-CAM – This typically occurs when the model or a specific layer is frozen. To resolve this, it is necessary to explicitly set `requires_grad=True` to allow gradient computation.
2. Incorrect layer selection within the model – In such cases, it is advisable to print the complete architecture of the model to verify that the selected layer exists and is correctly assigned.

I may not recall all potential issues at the moment. However, if you encounter any, please let me know, and I will do my best to assist you.

Grad-CAM Visualization
Hello! For the Grad-CAM visualizations in your paper, did you just use `targets = None` and vanilla GradCAM from the pytorch-grad-cam library? Thanks!


Question: [GAME BUG]: [Debug] memory.cpp:operator():293: Assertion Failed!

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

[GAME BUG]: [Debug] memory.cpp:operator():293: Assertion Failed!
### Checklist (we expect you to perform these steps before opening the issue)

- [X] I have searched for a similar issue in this repository and did not find one.
- [X] I am using an official build obtained from releases or updated one of those builds using its in-app updater.
- [X] I have re-dumped the game and performed a clean install without mods and the issue is still present.
- [X] I have disabled all patches and cheats and the issue is still present.
- [X] I have all the required system modules installed.

### Describe the Bug

After quick search, it seems neither CUSA00076 (The Order 1886) or memory.cpp:operator related issues are opened right now here

### Reproduction Steps

Game crashes on launch with this error:
[Debug] memory.cpp:operator():293: Assertion Failed!

1.00 and 1.02 version of game (without patch) have similar crash.

### Specify OS Version

Windows 10

### CPU

Intel Core i5-10600KF

### GPU

Nvidia Geforce rtx 3070

### Amount of RAM in GB

48

### Amount of VRAM in GB

8

### Log File

shad_log.zip

This issue URL is sort of similar to opened, with exception that "Mapping cannot fit inside free region" part is completely absent, and also not fixed unlike listed games.

Hello, I'm closing this one, this is now tagged with a label and also present in the wiki:
 URL

Thanks you

[Aggregate Issue] Mapping cannot fit inside free region
Separated as aggregate.

Fat princess adventures - CUSA01660

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

Diablo II Resurrected - CUSA28305

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

Resident Evil 2 (2019) - CUSA09171

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

@polybiusproxy Should we move the remaining crash logs from #601 here? All the remaining ones are the same type of error as this. It would make testing easier since we wont need to test on a month old build.

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

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

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

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

Kai No Kieski v1.00 - CUSA49295

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

CUSA32600 - ARMORED CORE™ VI FIRES OF RUBICON™ URL

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

CUSA10525 - Darkest Dungeon URL

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

CUSA12474 - TOKYO GHOUL:re CALL to EXIST URL

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

CUSA00634 - STAR WARS™ Battlefront™ URL

[Debug] memory.cpp:operator():544: Assertion Failed!
Mapping cannot fit inside free region

CUSA40994 - Amnesia: The Bunker URL

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

CUSA13801 - Sekiro™: Shadows Die Twice URL

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

CUSA19264 - 妖怪学園Y ～ワイワイ学園生活～/Yokai Academy Y: Lively School Life URL

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

CUSA18880 ELDEN RING™ Network Test Ver URL

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

CUSA28832 - 那由多之軌跡：改 (Nayuta no Kiseki KAI) URL

[Debug] memory.cpp:operator():415: Assertion Failed!
Mapping cannot fit inside free region

CUSA19640 - Persona 5 Strikers URL

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

CUSA28194 - SONIC FRONTIERS shadps4-emu/shadps4-game-compatibility#388

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

CUSA32600 - ARMORED CORE™ VI FIRES OF RUBICON™ shadps4-emu/shadps4-game-compatibility#1263

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

CUSA18723 - ELDEN RING™ shadps4-emu/shadps4-game-compatibility#1332

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

CUSA11993 - Marvel's Spider-Man shadps4-emu/shadps4-game-compatibility#1353

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

CUSA17776 - Marvel's Spider-Man: Miles Morales shadps4-emu/shadps4-game-compatibility#978

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

CUSA13801 - Sekiro™: Shadows Die Twice shadps4-emu/shadps4-game-compatibility#688

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

CUSA04301 - Dreams™

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

CUSA15325 - Yakuza 3

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

shad_log.txt

@gandalfthewhite19890404 , @StevenMiller123, @kvicken can we close it ?
This URL normally fix it

@Hermiten I agree this should be closed. The main "regression" we were tracking is fixed, and most of the games listed here are confirmed to be fixed.


Question: TypeError: Cannot read properties of undefined (reading 'color')?

I think I was able to fix this. Hope to make a bug fix release tomorrow or on Monday! Sorry for the inconvenience!

TypeError: Cannot read properties of undefined (reading 'color')
### Steps to Reproduce

1. Update the windows app to version 8.0.7
2. In the left pane, select the ellipses next to Today -> Worklog
3. Click on any of the Dates
4. The popup appears.

### Error Log (Desktop only)

### Console Output

### Meta Info
META: SP8.0.7 Browser – en-US – Win32 – Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 Edg/125.0.0.0

### Stacktrace

i0 (webpack:///src/app/features/worklog/worklog.component.html:134:34)
setSelectedIndex (webpack:///node_modules/@angular/core/fesm2015/core.mjs:12112:8)
setBindingIndex (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11975:12)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)
executeCheckHooks (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11999:29)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)
executeCheckHooks (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11999:29)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)
executeCheckHooks (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11999:29)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)

### Actions Before Error

1718188298709: [Task] Add time spent
1718188298712: [Tag] Update Work End for Tag
1718188298714: [Persistence] Save to DB (2)
1718188358710: [Task] Add time spent
1718188358714: [Tag] Update Work End for Tag
1718188358716: [Persistence] Save to DB (2)
1718188418705: [Task] Add time spent
1718188418709: [Tag] Update Work End for Tag
1718188418711: [Persistence] Save to DB (2)
1718188458169: [Task] Add time spent
1718188458172: [Tag] Update Work End for Tag
1718188458174: [Persistence] Save to DB (2)
1718188458415: [Task] Add time spent
1718188458418: [Tag] Update Work End for Tag
1718188458419: [Persistence] Save to DB (2)
1718188459425: [Task] Add time spent
1718188459428: [Tag] Update Work End for Tag
1718188459429: [Persistence] Save to DB (2)
1718188460413: [Task] Add time spent
1718188460415: [Tag] Update Work End for Tag
1718188460416: [Persistence] Save to DB (2)
1718188461422: [Task] Add time spent
1718188461424: [Tag] Update Work End for Tag
1718188461425: [Persistence] Save to DB (2)
1718188462425: [Task] Add time spent
1718188462427: [Tag] Update Work End for Tag
1718188462428: [Persistence] Save to DB (2)
1718188463559: [FocusMode] Set focus session elapsed time
1718188463705: [SP_ALL] Load(import) all data
1718188463708: [SP_ALL] All Data was loaded

Hey there! Thank you very much for reporting this!

It might be that for some reason a bit of your data got into an invalid state that I didn't account for and that I can't reproduce. It would be great if you could share a copy of your data to contact@super-productivity.com, so I can debug this on my computer (and please let me know here, if you send something, as those mails quite often land in the spam folder). You can create an export by navigating to "Settings" and then to "Import/Export" or you can use the "Export data" button from the error Dialog (there is also a button there which will anonymize the data before exporting).

duplicate URL

at least one task of the day must not be assigned to a project.

Hi. Thanks for responding to my email.

I have sent an email (*Subject: Issue #3214 - Data export*) with the copy
of my data.

Regards,
Riyaan

On Thu, Jun 13, 2024 at 9:16 AM Johannes Millan ***@***.***>
wrote:

TypeError: Cannot read properties of undefined (reading 'color')
### Steps to Reproduce
1. Open the "Worklog"
2. Expand a day with some task

### Error Log (Desktop only)

### Console Output

### Meta Info
META: SP8.0.7 Electron – it – Win32 – Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) superProductivity/8.0.7 Chrome/122.0.6261.156 Electron/29.2.0 Safari/537.36

### Stacktrace

i0 (webpack:///src/app/features/worklog/worklog.component.html:134:34)
setSelectedIndex (webpack:///node_modules/@angular/core/fesm2015/core.mjs:12112:8)
setBindingIndex (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11975:12)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)
executeCheckHooks (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11999:29)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)
executeCheckHooks (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11999:29)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)
executeCheckHooks (webpack:///node_modules/@angular/core/fesm2015/core.mjs:11999:29)
viewAttachedToChangeDetector (webpack:///node_modules/@angular/core/fesm2015/core.mjs:13025:16)

### Actions Before Error

1717432546870: [Persistence] Save to DB (2)
1717432547865: [Task] Add time spent
1717432547866: [Tag] Update Work End for Tag
1717432547869: [Persistence] Save to DB (2)
1717432548864: [Task] Add time spent
1717432548866: [Tag] Update Work End for Tag
1717432548867: [Persistence] Save to DB (2)
1717432549400: [Layout] Hide SideBar
1717432549871: [Task] Add time spent
1717432549872: [Tag] Update Work End for Tag
1717432549874: [Persistence] Save to DB (2)
1717432550865: [Task] Add time spent
1717432550867: [Tag] Update Work End for Tag
1717432550868: [Persistence] Save to DB (2)
1717432551026: [Pomodoro] Stop Pomodoro
1717432551027: [Task] UnsetCurrentTask
1717432551029: [Pomodoro] Pause Pomodoro
1717432556824: [Task] Update Task
1717432557072: [Persistence] Save to DB
1717432560045: [Task] SetSelectedTask
1717432560052: [Layout] Hide Notes
1717432563438: [Task] Move to archive
1717432563441: [Persistence] Save to DB (2)
1717432563442: [Task] UnsetCurrentTask
1717432563442: [Pomodoro] Pause Pomodoro
1717432563499: [Persistence] Save to DB
1717486530111: [FocusMode] Set focus session elapsed time
1717486530406: [SP_ALL] Load(import) all data
1717486530410: [Idle] Reset
1717486530411: [SP_ALL] All Data was loaded

I have this problem only in the "Today" worklog. The worklogs of my personal projects work good.

Same here. It crashes when you open a day in worklog view and there is at least one task **without project**. If all tasks have project it works fine.

the same since yesterday app update.
today->worklog causes app error state.


Question: netkit vs route tables?

Hah, okay, thanks for testing and taking a look. I presume NETKIT_SCRUB_NONE generally could be enough as an option anyway and if needed BPF prog could zero the data. I'll finalize and add a BPF selftest (next week) so that this can be submitted & merged then.

netkit vs route tables?
### Is there an existing issue for this?

- [x] I have searched the existing issues

### Version

equal or higher than v1.17.1 and lower than v1.18.0

### What happened?

node have two interface called private and public. both exist in cilium devices list.
public interface by default do not have IP address.
it get ip address when kube-vip discovers a loadbalancer service, then kube-vip assign a public ip.
public ip not enough in this network environment, it also needs a route. since default route already exist in the private link we use SBR, so the system creates a new route table with the gateway for the public address and place an ip rule about if from address is the public ip then use that route table. this is how the node can respond requests on the public interface while still the default route belongs to the private interface.

if the bpf.datapathMode set to veth all ok with cilium networking, all test run.
if the bpf.datapathMode set to netkit every other node ok, but the node who have a public ip + routes goes wrong. in this node what we experienced that the node can't communicate with the pods which running on that node.
if we move the public ip to another node, the node-pod network starts to work, and goes wrong on that node which got the public ip.
This is only reproducable in netkit mode.
Any ideas? How we can debug this further?

### How can we reproduce the issue?

cilium installed with helm:

autoDirectNodeRoutes: true
bandwidthManager:
 enabled: true
bgpControlPlane:
 secretsNamespace:
 create: false
bpf:
 datapathMode: veth
 hostLegacyRouting: false
 lbExternalClusterIP: true
 masquerade: true
cluster:
 id: 1
 name: sg1-kubego-io
clusterDomain: k8s.sg1.example.com
cni:
 exclusive: false
dashboards:
 enabled: true
debug:
 enabled: false
devices: public private wg+
enableIPv4Masquerade: true
enableRuntimeDeviceDetection: true
endpointRoutes:
 enabled: true
envoyConfig:
 secretsNamespace:
 create: false
hostFirewall:
 enabled: true
hostPort:
 enabled: true
ipam:
 mode: multi-pool
 operator:
 autoCreateCiliumPodIPPools:
 default:
 ipv4:
 cidrs:
 - 10.207.0.0/23
 maskSize: 28
 dashboards:
 enabled: true
 namespace: monitoring
 multiPoolPreAllocation: false
 prometheus:
 enabled: true
 labels:
 release: prometheus
 metricRelabelings: null
ipv4NativeRoutingCIDR: 10.207.0.0/19
ipv6:
 enabled: false
k8s:
 requireIPv4PodCIDR: true
 requireIPv6PodCIDR: false
k8sServiceHost: kube-api.example.com
k8sServicePort: 443
kubeProxyReplacement: true
l7Proxy: true
loadBalancer:
 acceleration: best-effort
 algorithm: maglev
 mode: dsr
nodePort:
 enabled: true
operator:
 dashboards:
 enabled: true
 namespace: monitoring
 prometheus:
 enabled: true
 interval: 60s
 labels:
 release: prometheus
 metricRelabelings: null
 replicas: 1
 rollOutPods: true
prometheus:
 enabled: true
 serviceMonitor:
 enabled: true
 interval: 60s
 labels:
 release: prometheus
routing-mode: native
routingMode: native
secretsNamespace:
 create: false
 sync: false
socketLB:
 enabled: true
 hostNamespaceOnly: true

witch config above everything works as expected using public ip that way mentioned above.
if you set this:

bpf:
 datapathMode: netkit

everything works as expected until a node get a public ip and sbr.

### Cilium Version

1.16.x/1.17.x

### Kernel Version

6.8.x

### Kubernetes Version

1.31.x

### Regression

_No response_

### Sysdump

_No response_

### Relevant log output

shell

### Anything else?

_No response_

### Cilium Users Document

- [ ] Are you a user of Cilium? Please add yourself to the Users doc

### Code of Conduct

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

Hi @pasztorl

I have a couple of questions.

Out of curiousity, have you looked into Cilium's L2 announcements feature. I'm not sure if this would work for your use case, but there's some overlap between the functionality that kube-vip, namely the assignment (and reassignment) of a VIPs to nodes for `LoadBalancer` services. My first thought is that if it's possible to use this instead it may be better than trying to mix components that may get in each other's way. As you point out, however, your setup works with veth, so it can't be entirely kube-vip's fault here.

Just to clarify, you're using source-based routing to send traffic whose source IP matches the public IP out through your secondary (public) interface? Do you configure this routing policy on all your nodes at all times or is it only configured for the node that currently holds the public IP?

if the bpf.datapathMode set to netkit every other node ok, but the node who have a public ip + routes goes wrong. in this node what we experienced that the node can't communicate with the pods which running on that node.
if we move the public ip to another node, the node-pod network starts to work, and goes wrong on that node which got the public ip.

Could you clarify what you mean by "the node can't communicate with the pods which running on that node"? Are you unable to talk to pods from within the host namespace of the node in question? Is there a specific command like `curl` that illustrates the issue? What does the output of `cilium-health` say when run on the impacted node?

I see you're using endpoint routes. I would suggest taking a look at some of the links and discussion in URL There were some issues previously using endpoint routes with netkit that were fixed in 1.17. However, this mostly applies when using network policies. I'm not sure if this is true in your case. Also, you'd need to latest kernel fixes for netkit.

It looks like you might be using Ubuntu or something similar? If so, make sure you're using `6.8.0-53-generic` at minimum which was just released. This is the first kernel release with the fixes I mentioned. Again, this may or may not apply to your case, but it's worth trying if it's easy to do so.

One thing that would help get to the bottom of your issue is to capture the output of `cilium-dbg monitor` on the impacted node in both `veth` and `netkit` modes while doing something that fails in netkit mode (e.g. run `curl` from the host namespace or something).

VIP routes only configured on node(s) which have VIP(s).

Is this something kube-vip does by default or do you have a custom script which sets up these routes? Glancing at the `kube-vip` documentation, there seems to be options like `vip_servicesinterface` control which interfaces to bind and address to. I see some vague references to routing, but nothing explicitly mentioning SBR. Could you clarify who is actually setting these routing tables up? It might be helpful to see how you've configured kube-vip if you can provide the details; I'm wondering if this is a problem that is easy to reproduce by just installing kube-vip with some basic configuration.

Ah, ok. So making sure I understand, things work with *both* netkit and veth as long as `bpf.hostLegacyRouting=true` and *both* modes present the same problem when `bpf.hostLegacyRouting=false` or is it only failing with netkit+bpf.hostLegacyRouting=false?

Thanks. From the output provided, it looks like the node with the VIP+routes can't reach the local `cilium-health` endpoint. If possible, could you provide the output with the `--verbose` flag. It should give a little more detail about the request to that endpoint and why it's failing, although my guess is it's a timeout of some sort.

@jrife sorry one more question.. i included a cilium-db monitor output.
This flow is the readiness check for a pod. i think this check need to come from the kubelet internal address but it seems it comming from the configured external ip from the node. i think this is not ok. what do you think?

-> endpoint 954 flow 0xbbd96870 , identity host->92858 state new ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58270 -> 10.96.1.99:5566 tcp SYN
-> endpoint 954 flow 0x880227c6 , identity host->92858 state new ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58284 -> 10.96.1.99:5566 tcp SYN
-> endpoint 954 flow 0xbbd96870 , identity host->92858 state established ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58270 -> 10.96.1.99:5566 tcp ACK
-> endpoint 954 flow 0x880227c6 , identity host->92858 state established ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58284 -> 10.96.1.99:5566 tcp ACK
-> endpoint 954 flow 0xbbd96870 , identity host->92858 state established ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58270 -> 10.96.1.99:5566 tcp ACK
-> endpoint 954 flow 0x880227c6 , identity host->92858 state established ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58284 -> 10.96.1.99:5566 tcp ACK
-> endpoint 954 flow 0x880227c6 , identity host->92858 state established ifindex lxcbe38814d9e9e orig-ip 80.77.122.114: 80.77.122.114:58284 -> 10.96.1.99:5566 tcp ACK, FIN

Hi @pasztorl

Just to check, are you experiencing any connectivity issues or are the readiness probes working?

Netkit does not work with endpoint routes in some cases
This tracks a group of issues related to netkit that share a similar root cause and discussion around it.

- In #34042 a user reported that liveness/readiness probes stopped working after applying `NetworkPolicy` to a `Pod` when using `netkit` and endpoint routes. The same configuration using `veth` did not have this problem. Some investigation turned up that packets coming from the host namespace get misidentified with the `world` identity instead of `host`. With `NetworkPolicies` applied to the endpoint this leads to packets from liveness/readiness probes getting dropped.
- In #33875 a user reported that running `curl -I -s URL from a `Pod` hangs when using `netkit` and endpoint routes after applying a `CiliumNetworkPolicy` which specifies `.spec.egress.toFQDNs`. The same configuration using `veth` or with endpoint routes disabled did not have this problem. Some investigation turned up a similar symptoms, with reply DNS traffic returning from the proxy taking on the `world` identity in `cil_to_container`.

In both cases the root cause looks to be that netkit scrubs packets (clearing `skb->mark`) before executing attached BPF programs. This is evident looking at the source for `netkit_xmit` where `netkit_prep_forward` clears `skb->mark` when crossing network namespaces before `netkit_run()` runs any attached programs.

c
 netkit_prep_forward(skb, !net_eq(dev_net(dev), dev_net(peer)));
 eth_skb_pkt_type(skb, peer);
 skb->dev = peer;
 entry = rcu_dereference(nk->active);
 if (entry)
 ret = netkit_run(entry, skb, ret);

In contrast, when using `veth` TC/TCX hooks are executed *before* the `veth` driver does any packet scrubbing.

#### `netkit` egress processing order
1. `sch_handle_egress` is called but does not execute any hooks, since BPF programs are attached directly to the device in `netkit` mode.
2. `netkit_xmit` begins
3. `netkit_xmit` clears `skb->mark`
4. `netkit_xmit` runs `cil_to_container`
5. `netkit_xmit` passes the packet to the peer device

#### `veth` egress processing order
1. `sch_handle_egress` is called executing `cil_to_container`.
2. `veth_xmit` begins
3. `veth_xmit` clears `skb->mark`
4. `veth_xmit` passes the packet to the peer device

Since `cil_to_container` uses `ctx->mark` for proxy redirection and policy enforcement this can lead to various issues. For now this only seems to be a problem when using endpoint routes, but if `cilium_host` were to be changed to `netkit` (I'm not sure if this is the case already) it may interfere there as well.

Just to confirm that this is indeed the root cause, patching the netkit driver with this hack locally resolves the reported issues in both cases making behavior consistent between `veth` and `netkit` modes (note: this is not a real fix, just something I used to test my observations).

 static void netkit_prep_forward(struct sk_buff *skb, bool xnet)
 {
+ u32 save_mark = skb->mark;
 skb_scrub_packet(skb, xnet);
+ skb->mark = save_mark;
 skb->priority = 0;
 nf_skip_egress(skb, true);
 skb_reset_mac_header(skb);

## Tasks
- [ ] Short term, decide whether or not we should allow netkit to be used with endpoint routes enabled. We could add some checks on startup to block this combination. Cons: this might make things stop working for some users who are already using this combination without issue.
- [ ] Document this as a known issue (#35126)
- [ ] Patch netkit. Talking to @borkmann offline, he mentioned maybe adding a new mode to determine if the scrub happens before or after running BPF. If implemented, this needs some follow up work to make sure this mode is configured.
- [ ] Expand test coverage to include some of these scenarios with netkit+endpoint routes.

CC @julianwiedmann @joestringer who are also involved in the issues mentioned.

Just wanted to add, I'm happy to take a stab at adding a new mode to netkit if it would help.

Hi @jrife I've pushed a patch here which I think could be acceptable. Do you have a chance to help testing whether that looks good on your side? URL I can run this by Martin and Nik in the meantime. Thanks for your help!

We could try asking for stable backport once this lands. I can add a Fixes tag just in case.

Cool, I'll give it a try locally under the two scenarios mentioned.

That would be great. It looks like we'd need to backport a fix to all supported Cilium versions to use `NETKIT_SCRUB_AFTER` if supported by the current kernel. I wonder if there should be any logic in Cilium to block a user from using endpoint routes with netkit on an unpatched kernel? Then again, maybe a known issue is enough since affected users could just switch to `veth` until they update their kernel.

I changed Cilium locally to set `IFLA_NETKIT_SCRUB` to `NETKIT_SCRUB_AFTER`.

* I tested the scenario in #34042 (liveness probes + `NetworkPolicy`) with the kernel patch and it seems to fix the issue. Switching to `NETKIT_SCRUB_BEFORE` this breaks again as expected.
* The scenario in #33875 does not work still unless `NETKIT_SCRUB_NONE` is used. I believe this is related to the fact that `skb->mark` is immediately reset after running `cil_to_container()` which sets it in `__ctx_redirect_to_proxy`.

c
 ctx->mark = MARK_MAGIC_TO_PROXY | proxy_port unknown state unknown ifindex eth0 orig-ip 0.0.0.0: 10.244.0.156:53 -> 10.244.1.246:36813 udp
 -> proxy flow 0x0 , identity 10388->26256 state reply ifindex lxc7b7ce9de2500 orig-ip 10.244.0.156: 10.244.0.156:53 -> 10.244.1.246:36813 udp
 unknown state unknown ifindex eth0 orig-ip 0.0.0.0: 10.244.0.156:53 -> 10.244.1.246:36813 udp
 -> proxy flow 0x0 , identity 10388->26256 state reply ifindex lxc7b7ce9de2500 orig-ip 10.244.0.156: 10.244.0.156:53 -> 10.244.1.246:36813 udp

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

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

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

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

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

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

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

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

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

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


Question: Ferdium won't launch after upgrading Ubuntu to 24.04 (using AppImage)?

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

Ferdium won't launch after upgrading Ubuntu to 24.04 (using AppImage)
### Your issue

Ferdium is not opening anymore after upgrading ubuntu from 23.10 to the unreleased 24.04.

This is what I get. Even the help to get ferdium info is not available anymore.

image

However this is the AppImage I am using.

Ferdium-linux-Portable-6.7.3-nightly.11-x86_64_4a1b12d6d452e18c9051545269e61317.AppImage

Launching it from the command line, this is the message I got.

bash
➜ ./Ferdium-linux-Portable-6.7.3-nightly.11-x86_64_4a1b12d6d452e18c9051545269e61317.AppImage
QSocketNotifier: Can only be used with threads started with QThread
[14565:0416/153718.391657:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_FerdiuAUvtnU/chrome-sandbox is owned by root and has mode 4755.

OS version

~/Applications …
➜ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Noble Numbat (development branch)
Release: 24.04
Codename: noble

Weird that this is the latest version of Ferdi I see on the Releases page `6.7.3-nightly.9` that was released 3 days ago but I have this `6.7.3-nightly.11` instead.

Ferdium-linux-Portable-6.7.3-nightly.9-x86_64.AppImage

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...

@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.

@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.

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

@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.

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

Joplin does not work in Ubuntu 24.04 due to apparmor issue
### Operating system

Linux

### Joplin version

2.11.11

### Desktop version info

_No response_

### Current behaviour

The Joplin appimage does not run in Ubuntu 24.04 due to recent changes in apparmor, which prevents all electron apps from running.

For details, see URL and URL

A temporary fix is described here URL

There is probably nothing the Joplin developers can do until apparmor fixes it, but I still wanted to report the bug to prevent huge confusion when 24.04 is released and thousands of users start using Joplin on it.

### Expected behaviour

_No response_

### Logs

$ ./Joplin.AppImage

[9034:0418/214224.008705:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_Joplin8u3ir2/chrome-sandbox is owned by root and has mode 4755.

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.

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.

`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!

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


Question: Request to Submit Chinese Translation Documentation?

we can't, I believe.

Besides, the speed at which arch wikis get out of date is _far_ slower than hyprland. We've had like at least 3 breaking changes in your config alone since latest release 0.35 like 2-3 weeks ago.

Request to Submit Chinese Translation Documentation
### Description:
I am ar0m(JinDongJie), and I am a big fan of the Hyprland project. I would like to help more Chinese users to better utilize this desktop manager. I plan to contribute by translating the project documentation into Chinese and am willing to dedicate my time and skills to complete this task.

### Plan and Approach:

1. I will translate the original project documentation into Chinese step by step, ensuring accuracy and fluency in the translation.
2. I will create a new branch(or a better way) to submit the translated documentation and will maintain regular updates to keep it synchronized.
3. I will collaborate with the community and maintainers to ensure the quality and accuracy of the translated documentation.
4. I hope that this translated documentation will help more Chinese users to easily utilize the Hyprland project.

### Inquiries:
 I have reviewed the current documentation website, and it seems that there is no language switch feature available. In the future, would it be possible to implement a language selection feature within the project? This feature could allow users to choose their preferred language for the documentation, enhancing accessibility for a wider audience.

### Additional Information:
 If you believe that this translation work is valuable and approve of my contribution, I am eager to contribute to the project. I look forward to working with you to make the Hyprland project more user-friendly and inclusive.
 I have used the translation website weblate.org to translate some other open-source projects that I like. I believe I am capable of handling this task.

Thank you for your time and attention!

Referencing a past issue URL

I believe it can be implemented simply as ` URL with a selector in the navbar.

I'm really excited to hear this news! Should I fork this repository and start translating? Or do you have any better suggestions? I'm eager to start contributing. Perhaps, once Hyprland is more stable, you could consider releasing these documents. @fufexan

We should check in with Vaxry first, as he was against the previous translation attempt.

[Feature] Multilingual support
The content on this wiki website is extensive.

Although I can read English, it is still inconvenient to refer to it frequently.

P.S. @fufexan I saw you said that the website might switch to another hugo theme "lotusdocs".

That's great, because "lotusdocs" support multilingual. It also support content searching using CJK characters.

And if you're really supporting multilingual, I'll contribute in zh-CN translation.

that's not a good idea. Translations will get dangerously out-of-sync.

True, it makes sense.

But, take Arch Wiki as example, it has multilingual support, and on the top of the translated page there is a notice about the last time this page is updated, and also a link to the original language.

If we could implement such warning/notification, will you feel it better?

Wow, this speed is so astonishing.

In such case, I hope multilingual could be implemented some other day in future.

Closing for now.


Question: p384: arithmetic + ECDSA support?

#589 adds `const fn` support to field elements

After that it would be nice to expose `const fn` wrappers for the field arithmetic functions, and then rewrite the various constants back into canonical form, transforming them into Montgomery form at compile time.

And after that, I'm good to ship it!

p384: arithmetic + ECDSA support
Hi,

Is there a way to compute and verify p384 signatures yet?

`p384` has an `ecdsa` feature, but I couldn't get anything done with it.
`ProjectiveArithmetic` is not implemented for `NistP384`. The `arithmetic` feature of the `elliptic_curve` crate isn't set, so I wasn't even able to manually compute a public key.

Is it possible to use it in a similar way as `p256` and `k256`? Or to use it for ECDSA at all? Or is it still a work in progress?

Thanks for your help :)

Nice! I can take a look at merging that into the `p384` crate. It seems to largely follow the same structure.

Interesting... I would like to compare performance of that with the WolfCrypt C implementation...

I'd be happy if we could merge that and therefore remove the `broken-arithmetic-do-not-use` stuff ^^

@jedisct1 I opened a draft PR here: URL

Alternatively if you'd like to open a PR yourself, that works too

An arithmetic implementation derived from `p384-rs` was merged in #565.

Thank you @jedisct1 and @brycx! And vicarious thanks to the fiat-crypto people!

For anyone following this issue, I've opened a tracking issue for a v0.11 release with arithmetic support: #566

p384: v0.11 release tracking issue
This is a tracking ticket for work items it would be nice to have before cutting a final v0.11 release which includes an initial arithmetic implementation.

NOTE: not all of these need to be completed prior to a release and they can be added after-the-fact.

- [x] #573
- [x] Test vectors
 - [x] #567
 - [x] #570
 - [x] #569
 - [x] #574

cc @brycx @jedisct1

@daviddrysdale would you be interested in helping add Wycheproof test vectors?

@jedisct1 did you want to take a look at adding 32-bit support? If not, I probably can in the next few days

#573 implemented (currently untested) 32-bit support except for field and scalar inversions, which presently use a 64-bit only implementation.

Once that has been addressed, we can add `cross` tests for 32-bit targets, and after that I'd say it's ready to release.

Happy to put in something analogous to the P256 test vectors, but it doesn't seem like the various traits (e.g. `SigningKey`, `VerifyingKey`) needed to use `new_wycheproof_test!` are available yet?

@tarcieri Is there anything left blocking the `0.11.0` release? I see you've changed the inversion to work with the 32-bit backend as well :rocket:


Question: SQLalchemy cast to String not working anymore?

In the case of DDL, I get an error if the Integer type is not INT.

I removed table constraints and fixed the INT type handling in the following branches.
 URL
Please check it out.

SQLalchemy cast to String not working anymore?
first of all: I really appreciate this project, it helps me a lot everyday. Thank you @laughingman7743 and other contributors!

I have a question/issue report: with the last realease (v2.5.0) some features changed (probabily this #286) and something that was working very well with version 2.4.0 is not working anymore.

Let's say that I have an integer column '_integer_col_' in the table '_some_table_' in the database '_some_db_'.

with v2.4.0 the SQLalchemy query

python
select(
 some_table.integer_col.cast(String)
)

produces the following SQL

SQL
SELECT CAST("some_db"."some_table"."integer_col" AS VARCHAR)
FROM "some_db"."some_table"

which is perfect.

while with v2.5.0 the same query produces the following SQL

SQL
SELECT CAST("some_db"."some_table"."integer_col" AS STRING)
FROM "some_db"."some_table"

which return the following error in Athena

`SYNTAX_ERROR: line xxx:yyy: Unknown type: string`

As workround I could change the query as follows

python
select(
 some_table.integer_col.cast(VARCHAR(n))
)

which, however, is not very convenient to use since sometimes is not possible to know the length of the string n.

What I am missing?

As you point out, #286 changes the handling of VARCHAR and STRINGS. When I was discussing the change in #279, I made the change to the STRING type if no length is specified, as it is an error if the length is not specified in the VARCHAR when the table is created. However I overlooked that Athena cannot CAST to STRING.
 URL
I would like to consider some way to work around this issue.

A workaround to revert to old behaviour at runtime is to specify:

python
@compiles(String)
 def compile_varchar(element, compiler, **kw):
 if element.length == 'unbounded':
 return "VARCHAR"
 else:
 return compiler.visit_VARCHAR(element, **kw)

and then use it as in:

python
select(
 some_table.integer_col.cast(String('unbounded'))
)

when a cast to VARCHAR is needed.

@laughingman7743 I think that a possible "correct" solution would be specifying two different _TypeCompiler_,s one (with hive mapping) to be used by the _DDLCompiler_ and one (with presto mapping) to be used by the _SQLCompiler_.

It could then be possible to override the attribute _type_compiler_ of the _DDLCompiler_ (which by default maps to the _Dialect_ one) in order to make it use the one with the correct mapping.

Creating tables with SQLAlchemy models supported?
The first issue I encountered:

sqlalchemy.exc.CompileError: You need to specify the storage location for the table using the `awsathena_location` dialect keyword argument

I was able to address this with something like:

Base.metadata.tables['my_table'].dialect_options['awsathena']['location'] = location

There is probably a better solution, but this is all I could come up with so far.

Once I fixed this, I encountered this:

sqlalchemy.exc.DatabaseError: (pyathena.error.DatabaseError) An error occurred (InvalidRequestException) when calling the StartQueryExecution operation: line 1:8: mismatched input 'EXTERNAL'. Expecting: 'OR', 'SCHEMA', 'TABLE', 'VIEW'

I debugged this on the Athena console and determined the issue is the SQL generated has primary key constraints which are not supported by Athena. Removing the primary key constraint in SQLAlchemy gives:

sqlalchemy.exc.ArgumentError: Mapper mapped class Institution->institution could not assemble any primary key columns for mapped table 'my_table'

Am I in unsupported territory or am I doing something wrong?

Without the executed code and the stack trace, I can't examine anything. Please share the code you executed and the stack trace that resulted in the error first.

Here are the tests related to CREATE TABLE in SQLAlchemy.
 URL
Maybe it will help you in some way.

Thanks, this did help me figure out a better way to provide the location:

 __table_args__ = { 'awsathena_location': location }

Great, thanks. I did more poking around and it seems SQLAlchemy requires a primary key. So perhaps in this scenario pyathena would omit this constraint when passing to Athena, since Athena does not support it?

URL
I don't know the detailed implementation of SQLAlchemy, but I don't generate DDLs that specify about the primary key when generating DDLs, though.
 URL

Thanks for the link regarding mapping a table that has no primary key. However, I don't think the solution applies here. It shows how to specify multiple columns to make up a primary key.

Why are you specifying PrimaryKey when Athena doesn't support it in the first place? I don't understand.

URL
This is where the PrimaryKey constraint will be added. This process is probably not necessary in Athena.

Only because SQLAlchemy complains if there is no primary key defined.

We had created an ugly work-around in the meantime by walking the ORM class attributes and generating the CREATE_TABLE SQL. I will try your solution as soon as I can. Thanks!

I've added a simple test case.
 URL
I'm not sure of the use case for this feature. If there is a test case you need, please let me know.

Unfortunately, it didn't work 100%. It looks like the primary key part is working, but there is some issue with the VARCHAR type handling. Athena requires a size to be specified for VARCHAR:

Traceback (most recent call last):
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1803, in _execute_context
 cursor, statement, parameters, context
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/default.py", line 732, in do_execute
 cursor.execute(statement, parameters)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/pyathena/util.py", line 37, in _wrapper
 return wrapped(*args, **kwargs)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/pyathena/cursor.py", line 108, in execute
 raise OperationalError(query_execution.state_change_reason)
pyathena.error.OperationalError: FAILED: ParseException line 2:0 mismatched input ')' expecting ( near 'VARCHAR' in primitive type specification

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
 File "pyathena_test.py", line 35, in
 Base.metadata.tables['mytable'].create(athena_engine)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/sql/schema.py", line 950, in create
 bind._run_ddl_visitor(ddl.SchemaGenerator, self, checkfirst=checkfirst)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 3117, in _run_ddl_visitor
 conn._run_ddl_visitor(visitorcallable, element, **kwargs)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 2113, in _run_ddl_visitor
 visitorcallable(self.dialect, self, **kwargs).traverse_single(element)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/sql/visitors.py", line 524, in traverse_single
 return meth(obj, **kw)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/sql/ddl.py", line 898, in visit_table
 include_foreign_key_constraints, # noqa
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1289, in execute
 return meth(self, multiparams, params, _EMPTY_EXECUTION_OPTS)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/sql/ddl.py", line 81, in _execute_on_connection
 self, multiparams, params, execution_options
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1387, in _execute_ddl
 compiled,
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1846, in _execute_context
 e, statement, parameters, cursor, context
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 2027, in _handle_dbapi_exception
 sqlalchemy_exception, with_traceback=exc_info[2], from_=e
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
 raise exception
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/base.py", line 1803, in _execute_context
 cursor, statement, parameters, context
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/sqlalchemy/engine/default.py", line 732, in do_execute
 cursor.execute(statement, parameters)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/pyathena/util.py", line 37, in _wrapper
 return wrapped(*args, **kwargs)
 File "/home/ec2-user/environment/pyathena_test/pr_virtenv/lib/python3.7/site-packages/pyathena/cursor.py", line 108, in execute
 raise OperationalError(query_execution.state_change_reason)
sqlalchemy.exc.OperationalError: (pyathena.error.OperationalError) FAILED: ParseException line 2:0 mismatched input ')' expecting ( near 'VARCHAR' in primitive type specification
[SQL:
CREATE EXTERNAL TABLE mytable (
 pk INT,
 name VARCHAR
)
STORED AS PARQUET
LOCATION 's3://terry-athena-bucket/mytable/'

Update: I think the issue is that the type mappings from SQLAlchemy to Athena probably were not necessary before if only queries were used. In our work-around we are mapping the SQLAlchemy to Athena for the types we are using so far (not complete):

INTEGER->integer
DATETIME->timestamp
FLOAT->double
VARCHAR->string
BOOLEAN->boolean
BIGINT->bigint

and then the more ugly part:

VARCHAR(40)->varchar(40)

Btw, if I change the test code from:

 name = Column('name', String)

to

 name = Column('name', String(40))

Then PR #281 works.

I'm trying a change in another branch to make it a STRING type when the length is not specified in VARCHAR.
 URL

Mapping VARCHAR with no length to string seems reasonable. It is what we are doing in our work-around.

Sorry, my mistake, I didn't realized it was merged. My original small test now works using pr 281.

Thanks for the confirmation, I'll merge the PR.
I will be releasing the next version 2.5.0 once I have addressed #284.

OK, great! The next step on my side is to try our full application with all our tables and data types.